11.2 Recommendations
11.2.2 Specific recommendations for implementing the scenarios
ID Recommendation 1
1 Define expert committee as quickly as possible
1.1 Consider whether necessary to include an expert from each Member State, to ensure an even input from all the stakeholders concerned, or select experts independent of Member States (e.g. outside EU – S. Korea, USA, Australia).
1.2 Consider the involvement of other groups of stakeholders, apart from the Member States e.g. developers, lawyers, groups already involved in development of requirements. 1.3 Look at getting guidance and best practice from other areas for actions that have been
undertaken by other groups.
1.4 Review opportunities to evaluate the benefits of each action as they occur – this will increase the efficiency of the process.
1.5 Invest time and effort in convincing that Member States that the process will have tangible benefits.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 2
2 Quickly identify and classify standards currently available
2.1 Independently of the scheme chosen, consider contacting standards entities and proactively involving the Member States in standards development.
2.2 Ask all Member States to put forward standards of choice that are currently in use in their national situation.
2.3 Identify most re-usable standards. Although this will be carried out by the standards bodies, it will be beneficial to obtain the input of the national stakeholders in this regard.
Page 114 of 349 2.4 With regard to scenario 3, mandates should be defined as quickly as possible to involve the
European standards bodies.
2.5 Involve internationally specialised Internet development organizations and existing specialized workshops from the start, regardless of the scenario adopted. This would include:
Workshops:
• CEN/ISSS Focus Group on eGovernment
• CEN/ISSS Workshop on eInvoicing Phase 2
• CEN/ISSS Workshop on Business Interoperability Interfaces for public procurement in Europe
• Northern European Subset (NES) of the Universal Business Language (UBL); the requirements and final specifications of which will be input into UN/CEFACT. Specialised Internet development organizations:
e.g. WS-I, IETF, W3C, OASIS
• WS-I (Web Services Interoperability Organisation17) is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages.
• IETF (Internet Engineering Task Force18) develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standard bodies; and dealing in particular with standards of the TCP/IP and Internet protocol suite.
• W3C (World Wide Web consortium19) develops interoperable technologies, (specifications, guidelines, software, and tools), and
• OASIS (Organisation for the Advancement of Structured Information Standards20) produces standards for security, e-business, and is involved in standardisation efforts in the public sector and for application-specific markets.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 3
3 Define code of conduct as quickly as possible
3.1 The code of conduct should be as generic as possible, as it should be potentially applicable to all three scenarios, with minor alterations as necessary. It should a simple and concise document, written with the agreement of all parties.
3.2 The code of conduct should not deal with technical matters, but more with the ethical side of compliance verification.
3.3 Procedures resulting from a violation of the code of conduct should be clear and concise, avoiding legal ambiguity. The exact procedures themselves will vary between scenarios, and may be detailed in annexes.
3.4 The responsibilities of the Member States, the EC, and all other stakeholders should be clearly defined. Any indistinct roles of any stakeholders should be avoided.
Benefits/costs High Medium Low
17WSI
, 401 Edgewater Place, Suite 600 Wakefield, MA 01889 USA 18IETF
, c/o NeuStar, Inc.Corporate Headquarters, 46000 Center Oak Plaza, Sterling, VA 20166, Canada 19W3C
Benelux Office, Centre for Mathematics and Computer Science (CWI), Kruislaan 413, Amsterdam, 1098SJ, The Netherlands
20OASIS
Page 115 of 349 Benefits X
Effort X
ID Recommendation 4
4 Technical requirements must be clear and concise
4.1 The technical requirements pertain to the technical aspects that a system must fulfill, such as performance-related issues, reliability issues, and availability issues. These should be clarified during the expert committee meetings.
4.2 The requirements should detail all functional and non-functional aspects, as defined by previous e-procurement studies and the current study.
4.3 Requirements already detailing certain aspects are already available. The re-use of already existing frameworks and standards should be strongly encouraged (e.g. eGIF, SAGA).
4.4 An effort should be made to minimize the number of purely technical requirements. Technology changes quickly and often requirements based on technology change just as quickly.
4.5 For all requirements, try to determine the real underlying business needs being expressed. 4.6 All existing technical development must be taken into account. Forcing developers to
change from a perfectly functioning system or module, just because it does not meet a technical requirement which has not been proven to be better, will not improve the popularity of the scheme.
4.7 Interoperability should be made the key to the requirements process. Any technical solution which permits a sufficient degree of interoperability between systems at a European level should be encouraged. On the other hand, proprietary systems which are not interoperable should be phased out.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 5
5 Obtain quick consensus about scheme type
5.1 In the mixed schemes, those aspects of compliance verification to be made mandatory (and consequently those which should be left voluntary) must be quickly identified, as obligation will require subsequent regulatory mechanisms to be defined.
5.2 Within a mixed scheme, the number of mandatory aspects should be minimised as this raises the effort and complexity of the scheme to be administered. The issues central to compliance verification should be clarified.
5.3 Within a purely voluntary scheme, the benefits must be highlighted to the Member States to convince them to take part.
5.4 In the case of a mandatory scheme, a “carrot & stick” method may be adopted where although penalties for non-compliance are made clear, it must be evident that the benefits far outweigh the penalties.
5.5 In the voluntary scheme, to ensure success, the tangible benefits of compliance must be made clear. In this case it may be necessary to provide acknowledgement of effort based on an award scheme.
Page 116 of 349
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 6
6 Funding
6.1 This will be an important issue. Based on the issue at hand, and the restrictions already defined by the Member States, full funding of verification processes for national bodies by the EU should be carefully considered.
6.2 Alternative co-financing schemes should also be considered where possible. Identify possible co-financing partners in Member States. Co-financing can facilitate the movement towards a sector wide strategic approach. This considerably increases the probability that the activity will yield sustainable improvements.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 7
7 Define verification model to be used.
7.1 Based on this study, it is clear that a verification model which adopts a process of verifying compliance of individual modules is preferred. This model should be put forward as the first choice. This will affect the definition of the technical requirements.
7.2 Where possible, electronic and online tools should be made available and their use encouraged, particularly where verification is voluntary. Where aspects of verification are mandatory, tools can be useful for self-assessment purposes before full certification, and indeed may help to lower costs (e.g. discover weak points before full certification). 7.3 Verification could also be carried out following the model already in place in many Member
States, where compliance is measured against the contractual specifications. 7.4 A definition of acceptable Service Level Agreements should be defined. This contract
model is very common, and defines the levels of service to be provided in various non- functional characteristics. These levels should also be standardised at European level. 7.5 The verification mechanism must incorporate other strategies for those Member States
which do not want to invest funds in the creation of a full system, but prefer a process for homologising tools from external suppliers to be accessed from a simple central platform.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 8
8 Initiate a feasibility study for the development of an EU agency for e-government &
Page 117 of 349 8.1 Rapidly changing technologies necessitate the creation of a body at EU level which is
constantly observing development in the international area, and can act as an information point for the Member States.
8.2 An agency should be used to encourage research and development in e-government, e- procurement and e-commerce in general at an EU level.
8.3 To minimise costs, contact should be made with existing agencies in order to see if these can take up the responsibilities. Any existing agency would have to be provided with regulatory powers to oversee compliance in e-procurement and be able to act accordingly against non-compliance.
8.4 If no existing agency has the capacity to carry out such work, the potential for creating a new agency should be given serious consideration.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 9
9 Involve national e-procurement authorities in constant dialogue
9.1 It is essential to include the national authorities from the start as they are the hub of the three scenarios, as their inclusion will help relieve the controlling body at EU level of some of the burden of coordination.
9.2 The capacity of national authorities to take on the coordination work involved in all
scenarios (but particularly 2 & 3) should be carefully analysed before the implementation of the compliance mechanisms at a European level. Financial backing may be necessary. 9.3 Create an online forum for all national e-procurement authorities where issues and
considerations at a European level may be aired. This online forum could be part of the EU agency’s activities.
Benefits/costs High Medium Low
Benefits X
Effort X
ID Recommendation 10
10 Identify two candidates for running two tiered test model
10.1 A candidate Member State at the upper level with advanced e-procurement systems / platforms and with an already well defined verification strategy should be approached to test the upper tier of the verification process (Austria, Norway, UK, Italy, Lithuania). 10.2 At the lower level, a candidate from those countries which have not yet developed a
complete verification mechanism should be approached for testing the first tier verification process (Luxembourg, Finland, Poland, Ireland, Hungary).
Benefits/costs High Medium Low
Benefits X
Page 118 of 349