S O T A R V II: Tate F HE RT Eport Olume

STATE OF THE ART REPORT
VOLUME II
CASE STUDIES ON E UROPEAN ELECTRONIC

P UBLIC PROCUREMENT P ROJECTS
JULY 2004
Public eProcurement European Commission
Produced by EUROPEAN DYNAMICS S.A.
on behalf of the EUROPEAN COMMISSION
Disclaimer
The views expressed in this document are purely those of the writer and may not, in any circumstances,
be interpreted as stating an official position of the European Commission.
The European Commission does not guarantee the accuracy of the information included in this study,
nor does it accept any responsibility for any use thereof.
Reference herein to any specific products, specifications, process, or service by trade name, trademark,
manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation,
or favouring by the European Commission.
All care has been taken by the author to ensure that he has obtained, where necessary, permission to use
any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights
already exist from the titular holder(s) of such rights or from his or their legal representative.
© European Communities 2004 State of the Art Volume II Page 2 of 109

Abbreviations / Acronyms
Abbreviation
Term
or Acronym
AGM Agency of Government Management (Danish administration)
API Application Program Interface
APM Agency of Public Procurement (Swedish administration)
CA Certification Authority
CPP Centralised Public Procurement (Hungarian administration)
CPV Common Procurement Vocabulary
cXML Commerce XML
DFPS Department of Finance and Public Administration (Basque administration)
DOC Microsoft MS Word document (.doc)
DPS Dynamic Purchasing Systems
EC European Commission
EDI Electronic Data Interchange
EU European Union
FAQ Frequently Asked Questions
FedICT Federal Public Services of Information and Communication Technologies
GAS Government Administration Services (Norwegian administration)
GPC Government Procurement Card
GUI Graphical User Interface
HTTP / HTTPS HyperText Transfer Protocol / Secure HyperText Transfer Protocol
ICT Information and Communication Technology
IDA Interchange of Data between Administrations
IT Information Technology
ITT Invitation to Tender
MEAT Most Economically Advantageous Tender
MINDEF Ministry of Defence (French administration)
MoD Service Public Fédéral of the Ministry of Defence (Belgian administration)
MS Member States
OGC Office of Government Commerce (UK administration)
OJEU Official Journal of the European Union
OSS Open Source Software
PDF Portable Document Format
PIN Prior Information Notice
PQQ Pre-Qualification Questionnaire
Q&A Questions & Answers
RFP Request for Proposal
RFQ Request for Quotation
RTF Rich Text Format
SLA Service Level Agreement
SME Small-Medium Enterprises
SMTP Simple Mail Transfer Protocol
SSL Secure Sockets Layer
UN/SPSC Universal Standard Products and Services Code
VPN Virtual Private Network
XLS Microsoft MS Excel spreadsheet (.xls)
XML eXtensible Markup Language

Glossary
Term Description
Advanced Electronic Means an electronic signature which meets the following requirements:
Signature (a) it is uniquely linked to the signatory
(b) it is capable of identifying the signatory
(c) it is created using means that the signatory can maintain under his sole control
(d) it is linked to the data to which it relates in such a manner that any subsequent
change of the data is detectable
Authentication Proving a user’s identity. To be able to access a Website or resource, a user must provide
authentication via a password or some combination of tokens, biometrics and passwords.
Authorisation The act of granting approval. Authorisation to resources or information within an
application can be based on simple or complex access control methods.
Basic Internet Security Typically employed in low value, low sensitivity applications using Secure Sockets
Layer (SSL) for confidentiality, with the possible addition of UserID and Passwords for
user authentication.
Browser Based This term describes software that does not require any client software to be installed or
configured on users' systems, except of the commercially supported Web-browsers (IE,
NS, Mozila and Opera). Unlike a browser plug-in, browser based applications do not
require manual download and execution of an installation program prior to Web site
access; Unlike an ActiveX control or some Java applets, browser based applications do
not force the user to agree to potentially confusing security warning dialogs. Unlike other
client applications, browser based applications do not have a noticeable download time.
In fact, download is transparent to the end-user.
Certificate An electronic "passport". A certificate is a secure electronic identity conforming to the
X.509 standard. Certificates typically contain a user's name and public key. A CA
authorises certificates by signing the contents using its CA signing private key.
Certificate validation The process of checking the trustworthiness of a certificate. Certificate validation
involves checking that the certificate has not been tampered with, has not expired, is not
revoked and was issued by a CA you trust.
Certification The system responsible for issuing secure electronic identities to users in the form of
Authority (CA) certificates.
Cryptography The science to convert plain language into coded text and in reverse.
Decrypt To decrypt a protected file is to restore it to its original, unprotected state.
Electronic signature Data in electronic form which are attached to or logically associated with other electronic
data and which serve as a method of authentication
Encryption To encrypt a file is to apply a mathematical function that transforms character(s) in the
file into some other character(s). Encryption renders the file unreadable. This means no
one, including the actor, can read the file until it is decrypted. Only authorised recipients
can decrypt the file.
Encryption key pair This consists of the encryption public key and decryption private key. The public key
portion of an encryption key pair is used to encrypt data which can be decrypted by the
matching decryption private key.
Enhanced Internet This is the required level of security needed for applications that deal with higher value
Security and higher sensitivity transactions and information. This consists of enhanced levels of
identification, entitlements, verification, privacy and security management.
Identification see Authentication
National Refers to the public authority responsible for the eProcurement programme of a country,
eProcurement as well as, for compliant with the legislation operation of the offered systems. The
Authorities information analysed in the current report has all been obtained by the National
eProcurement Authorities of the participating countries.
Private key The portion of a key pair that is kept secret by the owner of the key pair. Private keys
sign or decrypt data.
Public key The portion of a key pair that is available publicly.

Public Key A system that provides the basis for establishing and maintaining a trustworthy
Infrastructure (PKI) networking environment through the generation and distribution of keys and certificates.
This is also the foundation technology for providing enhanced Internet security.
Secure Sockets Layer A secure session protocol used to maintain data confidentiality only bet ween Web-
(SSL) browsers and Web servers. This is a fundamental component of basic Internet security.
Security Management The act of effectively and efficiently managing identification, entitlements, verification
and privacy such that there is less burden of administration for end users and
administrators regardless of application or platform.
Security policy An organisation's security policy governs the use of the appropriate infrastructure in the
organisation to achieve security objectives.
Time Stamping The validity of storing the official date and time a business transaction has occurred.
Web Portal A Web portal is a single doorway for employees, customers and partners to access an
organisation's content, data and services online. Also known as Enterprise portals, Web
portals make it possible to establish online relationships by providing personalised
content to different individuals and entities. Organisations are building portals not only
to increase loyalty, but also to create competitive advantage, strengthen relationships,
speed access to services and satisfy regulatory requirements. Portals also make it
possible to increase revenue, efficiencies and cost savings by moving business processes
online.
XML XML is the standard messaging format for business communication, allowing companies
to connect their business systems with those of customers and partners using the existing
Internet infrastructure. Similar to HTML, XML uses tags (words bracketed by '<' and '>')
and attributes (of the form name="value") to help place structured data into text files.
XML is different from HTML in that it is a meta-language (a language for describing
languages) and, therefore, does not define specific tags and attributes.

Table of Contents
Abbreviations / Acronyms ............................................................................................................................................. 3
Glossary............................................................................................................................................................................. 4
Table of Contents............................................................................................................................................................. 6
1 Introduction .................................................................................................................................................................10
1.1 Document structure ...........................................................................................................................................10
2 Evaluation methodology ...........................................................................................................................................11
2.1 Evaluation methodology topics.......................................................................................................................11
2.1.1 Analysis of the status of eProcurement in reviewed countries..........................................................12
2.1.2 Analysis of eProcurement systems.........................................................................................................12
2.1.3 Analysis of eProcurement Practices .......................................................................................................14
2.2 Support activity ..................................................................................................................................................15
3 Reviewed countries....................................................................................................................................................17
3.1 Belgium...............................................................................................................................................................17
3.2 Denmark..............................................................................................................................................................18
3.3 France...................................................................................................................................................................19
3.4 Italy.......................................................................................................................................................................21
3.5 Norway ................................................................................................................................................................22
3.6 Spain (Basque country).....................................................................................................................................23
3.7 United Kingdom.................................................................................................................................................24
3.8 United Kingdom (Scotland) .............................................................................................................................25
3.9 Other Countries ..................................................................................................................................................26
3.9.1 Finland ........................................................................................................................................................26
3.9.2 Hungary ......................................................................................................................................................27
3.9.3 Sweden........................................................................................................................................................27
4 Electronic Procurement Systems .............................................................................................................................30
4.1 Individual Contracts..........................................................................................................................................30
4.1.1 DTC – Scottish Executive (UK/Scotland) ............................................................................................32
4.1.2 DPSM – Ministry of Defence (FRANCE) ............................................................................................36
4.1.3 JEPP – Federal Government Ministry of Defence (BELGIUM) ......................................................42
4.1.4 EPSS – CORDIS (EUROPEAN UNION) ............................................................................................46
4.1.5 SYSLOG Market – DG ADMIN (EUROPEAN UNION) ................................................................49
4.1.6 eSourcing Service – Office of Government Commerce (UK) ..........................................................53
4.1.7 eContratacion eTendering–Department of Finance & Public Administration (SPAIN/Bas que) 55
4.1.8 ehandel eSourcing – Government Administration Services (NORWAY) ......................................57
4.2 Repetitive Purchasing Systems........................................................................................................................59
4.2.1 PECOS – Scottish Executive (UK/Scotland).......................................................................................60
4.2.2 Lotto 2 – Consip (ITALY).......................................................................................................................63
4.2.3 DOIP/DOIPEI – Agency of Government Management (DENMARK)...........................................66
4.2.4 ehandel eOrdering – Government Administration Services (NORWAY) ......................................69
4.2.5 DPSM eCatalogues – Ministry of Defence (FRANCE) .....................................................................72
4.3 eAuctions systems .............................................................................................................................................75
4.3.1 eAuction services – Office of Government Commerce (UK) ...........................................................77
4.3.2 Lotto 1 – Consip (ITALY).......................................................................................................................79
4.3.3 DOIP eAuction – Agency of Government Management (DENMARK).........................................82
4.3.4 ehandel eAuctions – Government Administration Services (NORWAY) ......................................85
4.3.5 DPSM eAuctions – Ministry of Defence (FRANCE).........................................................................87
4.4 eProcurement supplementary systems ...........................................................................................................90
4.4.1 Supplier Adoption Database – Scottish Executive (UK/Scotland)...................................................91
4.4.2 eCatalogue Converter – Scottish Executive (UK/Scotland)..............................................................92
4.4.3 Eureka Search – Interchange of Data between Administrations (EU).............................................93

5 ANNEX A: Structured Communication .................................................................................................................95

6 ANNEX B: Contact information from participating public administrations.................................................109

List of Tables
Table 1: Reviewed public administration eProcurement approach..................................................................12
Table 2: [Name of eProcurement system] system overview .............................................................................13
Table 3: [Name of eProcurement system] coverage of the new legislative framework on eProcurement 14
Table 4: [Name of eProcurement system] functionality overview...................................................................14
Table 5: Coverage of the EU legislation principles by the [Name of the category] eProcurement
Practices...........................................................................................................................................................15
Table 6: Belgian Federal eProcurement approach..............................................................................................18
Table 7: Danish AGM eProcurement approach..................................................................................................19
Table 8: French MINDEF (DGA) eProcurement approach ..............................................................................20
Table 9: Italian Consip eProcurement approach.................................................................................................21
Table 10: Norwegian GAS eProcurement approach ..........................................................................................22
Table 11: Basque government eProcurement approach.....................................................................................23
Table 12: UK – OGC eProcurement approach....................................................................................................24
Table 13: Scottish Executive eProcurement approach.......................................................................................25
Table 14: Swedish eProcurement approach.........................................................................................................29
Table 15: Features that establish the uniformity of an Individual Contract system with the new
legislative framework on public procurement ..........................................................................................31
Table 16: DTC system overview ...........................................................................................................................33
Table 17: DTC coverage of the new legislative framework on eProcurement..............................................35
Table 18: DTC functionality overview .................................................................................................................36
Table 19: DPSM system overview........................................................................................................................38
Table 20: DPSM coverage of the new legislative framework on eProcurement...........................................40
Table 21: DPSM functionality overview..............................................................................................................42
Table 22: JEPP platform overview........................................................................................................................44
Table 23: JEPP coverage of the new legislative framework on eProcurement..............................................45
Table 24: JEPP functionality overview ................................................................................................................46
Table 25: EPSS system overview..........................................................................................................................47
Table 26: EPSS coverage of the new legislative framework on eProcurement.............................................49
Table 27: EPSS functionality overview................................................................................................................49
Table 28: SYSLOG Market system overview .....................................................................................................50
Table 29: SYSLOG Market coverage of the new legislative framework on eProcurement........................52
Table 30: SYSLOG Market functionality overview...........................................................................................52
Table 31: eSourcing service overview..................................................................................................................54
Table 32: eContratacion eTendering system overview......................................................................................56
Table 33: ehandel eSourcing system overview ...................................................................................................58
Table 34: Features that establish the uniformity of a Repetitive Purchasing System with the new
legislative framework on eProcurement ....................................................................................................60
Table 35: PECOS system overview ......................................................................................................................61
Table 36: PECOS coverage of the new legislative framework on eProcurement.........................................62
Table 37: PECOS functionality overview............................................................................................................63
Table 38: Lotto 2 system overview .......................................................................................................................64
Table 39: Lotto 2 coverage of the new legislative framework on eProcurement..........................................65
Table 40: Lotto 2 functionality overview.............................................................................................................65
Table 41: DOIP/DOIPEI system overview..........................................................................................................67
Table 42: DOIP/DOIPEI coverage of the new legislative framework on eProcurement.............................68
Table 43: DOIP/DOIPEI functionality overview................................................................................................69
Table 44: ehandel eOrdering system overview ...................................................................................................70
Table 45: ehandel eOrdering coverage of the new legislative framework on eProcurement......................71
Table 46: ehandel eOrdering functionality overview.........................................................................................72
Table 47: DPSM eCatalogues system overview .................................................................................................73
Table 48: DPSM eCatalogues coverage of the new legislative framework on eProcurement....................74
Table 49: DPSM eCatalogues functionality overview.......................................................................................75
Table 50: Features that establish the uniformity of an eAuction system with the new legislative
framework on eProcurement........................................................................................................................76

Table 51: UK eAuctions services system overview ...........................................................................................77

Table 52: UK eAuctions services coverage of the new legislative framework on eProcurement..............79
Table 53: UK eAuctions functionality overview ................................................................................................79
Table 54: Lotto 1 system overview .......................................................................................................................80
Table 55: Lotto 1 coverage of the new legislative framework on eProcurement..........................................81
Table 56: Lotto 1 functionality overview.............................................................................................................82
Table 57: DOIP eAuctions system overview.......................................................................................................83
Table 58: DOIP eAuctions coverage of the new legislative framework on eProcurement .........................84
Table 59: DOIP eAuctions functionality overview............................................................................................85
Table 60: ehandel eAuctions system overview ...................................................................................................86
Table 61: ehandel eAuctions functionality overview.........................................................................................87
Table 62: DPSM eAuctions system overview .....................................................................................................88
Table 63: DPSM eAuctions coverage of the new legislative framework on eProcurement........................89
Table 64: DPSM eAuctions functionality overview...........................................................................................90
Table 65: Contact information from participating public administrations...................................................109

1 Introduction
The current document provides the background analys is of the information gathered from various
Member States that eventually led to interesting eProcurement Practices (presented in Volume I).
The study considered 21 systems from 8 European countries (including 3 EC systems ). The
analysis of the Member States eProcurement programmes and their existing systems is performed
through an established evaluation methodology, which standardises the way they are examined.
The evaluation methodology used for the assessment of the reviewed systems is also presented in
this document, with a view to provide a method for administrations evaluating the quality of their
systems, or any proposals received from technology suppliers, for the development of
components, tools, or complete eProcurement systems.
1.1 Document structure

The current document is structured in the following manner:
• Section 2 - Evaluation methodology: presents the methodology used for reviewing the
eProcurement systems from the participating administrations. The purpose of the Evaluation
Methodology is not to benchmark the analysed systems, but rather to provide a standardised
mechanism in order to assess them and result in common conclusions. The Evaluation
Methodology can be utilised by MS in order to objectively evaluate their own systems and/or
contractor proposals for future developments.
• Section 3 - Reviewed countries : presents information related to the administrative structure
of the official government bodies involved with the development of public eProcurement in
each reviewed country. Furthermore, there is a high-level overview of existing and future
eProcurement programmes and systems of the reviewed administrations.
• Section 4 - Electronic Procurement Systems : provides an analysis of the reviewed
eProcurement systems. Systems are grouped into four main categories, depending on their
functionality. The identified categories are:
o Individual Contract systems: covering procurement of one-off contracts, through the
open, restricted, or negotiated procedures
o Repetitive Purchasing systems: covering systems employing electronic catalogues,
through DPS or framework agreements
o eAuction systems: covering eAuctions
o Supplementary systems: enhancing functionality of existing eProcurement systems ,
without directly covering an eProcurement type or phase

2 Evaluation methodology
In order to analyse all reviewed eProcurement systems, the contractor has established an
Evaluation Methodology; a structured procedure for assessing the procedural and technical
capabilities of all eProcurement programmes and systems reviewed. The Methodology is utilised
in order to evaluate the system functionality, compare it to the new EU public procurement
legislation and identify eProcurement Practices; ideas that can be included in a State-of-the-Art
programme/system.
The purpose for establishing the Evaluation Methodology is twofold. The first objective is to
identify and collect the necessary information in order to understand the policy followed by the
reviewed public administrations and analyse the ir eProcurement systems. The second objective is
to apply a formalised analysis procedure, in order to identify interesting eProcurement Practices
and recommend their implementation. The execution of the Evaluation Methodology requires a
wide range of information for all systems, which was not always available to the contractor
during the current analysis.
The established methodology can be used for analysing eProcurement systems, but it is not
destined for evaluating and benchmarking systems. Benchmarking is not the purpose of this
report and therefore reviewed systems are not compared one against the other with an intention to
conclude the systems that are the “best-of-breed” .
2.1 Evaluation methodology topics

The Evaluation Methodology is presented in the following sections, detailing the way the
reviewed system were analysed. Interested parties can utilise this methodology for identif ying
“weak” areas that need improvement. Moreover, this methodology can be used for evaluating
contractor’s proposals for creating eProcurement systems, as well as, for further enhancing
existing systems.
The analysis, based on the Evaluation Methodology, is carried out in three phases, each one
focusing on a separate area of review. The three phases are executed in a sequential manner, in
order to conclude concrete results. During the first phase there is an analysis of the policy
followed by the reviewed administrations. In the second phase there is an analysis of the reviewed
eProcurement systems. Finally, in the last phase there is a presentation of identified eProcurement
Practices and a conclus ion of the overall analysis. The following sections provide details for each
phase, allowing the reader to better understand the analysis approach used according to the
established methodology.
The contractor has also established a contingency plan in order to face possible disruptions during
the collection of information by the various participating public administrations. This plan is
presented at the end of this section.

2.1.1 Analysis of the status of eProcurement in reviewed countries

The first phase of the analysis considers the status of eProcurement in the reviewed
administrations . There is a brief outline of the national legislative structure and a presentation of
the most important bodies that define the eProcurement national environment in a country. This
phase focuses on the analysis of the policies followed by the reviewed public administrations.
There is a presentation of the current and ongoing eProcurement projects and an overview of the
reviewed systems. The results of the analysis are summarised in a table with the following
structure.
Feature Description
Administration involved Name of reviewed public administration
Project(s) Name of eProcurement project(s)
Objectives:
o Objective 1
o Objective 2
o etc.
Technology Provider Name of technology provider(s)
System(s) Name of reviewed eProcurement system and year it was launched
o Characteristic 1
o Characteristic 2
o Characteristic 3
o etc.
Step Forward Further developments comprise:
o Target 1
o Target 2
o etc.
Table 1: Reviewed public administration eProcurement approach
2.1.2 Analysis of eProcurement systems

The second phase of the analysis, constituting a study of the reviewed eProcurement systems, is
carried out in three stages. The first stage provides an overall picture of the eProcurement system
under review, in the second stage there is a comparison of the system functionality with the new
EU public procurement legislation and state-of-the-art aspects and the last stage presents the
system functionality.
The first stage of the eProcurement system analysis provides an overview of the system in a form
of a table . The first three rows of the table provide an overview of the functionality (row 1),
presentation of the exploitation model (row 2) and description of the types of actors (row 3). The
rest of the table grows depending on the system under review, as it lists the most interesting
characteristics of the system. This obviously varies from system to system, although some
characteristics are common to a number of them. Characteristics include technical, as well as,
procedural and operational aspects. The table of the system overview can be used in order to
quickly acquire a complete picture of the system under review. The structure of the table that
provides the system overview is presented hereafter.

System feature System implementation details

Functionality overview - Functionality 1
- Functionality 2
- Functionality 3
- etc.
Exploitation model - Financial policy
- Contracting authorities:
o Cost for joining the platform
- Suppliers:
o Cost for joining the platform
Actors - Actor 1: responsible for the:
o Role 1
o Role 2
o etc.
- Actor 1: responsible for the:
o Role 1
o Role 2
o etc.
Characteristic 1 - Description
Interesting system
characteristics
etc. -
Table 2: [Name of eProcurement system] system overview

The second stage of this phase performs a comparison of the system under review with the
guidelines of the new EU public procurement legislation, as well as, other state-of-the-art aspects
as identified during the analysis. The comparison is presented in a form of a table. A separate
table is used for each one of the three identified eProcurement system categories (individual
contracts, repetitive purchasing and eAuctions). There is no such analysis for the “secondary
systems” category.
These tables consider two aspects of analysis, the coverage of the different eProcurement phases
(upper part of the table) and the coverage of certain legal principles (lower part of the table). In
the following chapters of this report, during the introduction of each eProcurement system
category, there is a presentation of the table template that will be used for the comparison. This
table explains the conditions that must be satisfied in order to conclude that the system supports a
particular functionality. A typical example of a table is presented here.

eProcurement lifecycle Required Functional Details System Implementation Details

eProcurement phase 1 û Functionality 1 • Reasons for not supporting the functionality
support •
ü Functionality 2 • Reasons for supporting the functionality
•
û Functionality 3 • Reasons for not supporting the functionality
eProcurement phase 2 û Functionality 1 • Reasons for not supporting the functionality
support ü Functionality 2 • Reasons for supporting the functionality
Legislative principles Required Functional Details System Implementation Details
Principle 1 ü Functionality 1 • Reasons for supporting the functionality
•
ü Functionality 2 • Reasons for supporting the functionality
•
Table 3: [Name of eProcurement system] coverage of the new legislative framework on eProcurement
The last stage of this phase provides a description of the system functionality. This is performed
using a table that presents the list of the main system functionality. Each functionality is
described by the name of the underlying system activity, the actor, and the description of the
activity. This table has the following layout.
Activity Actor Description

Activity 1 Actor 1 • Details of the actions performed by the actor
Table 4: [Name of eProcurement system] functionality overview
2.1.3 Analysis of eProcurement Practices

The third phase of the analysis considers the eProcurement Practices that have been identified
during the previous two phases and provides recommendations. There is a categorisation of the
eProcurement Practices into four groups: organisational, procedural, technical and operational.
The results of the analysis are provided at the end of the presentation of each category and
following the same model. This analysis is performed and presented in Volume I of the State of
the Art report.
For the coverage of the legal requirements of the new European public procurement directives,
compliance with the following principles has been examined:
− Tenderers receive an equal amount of information at the same time (equality of
treatment)
− Contracting authorit ies respect the confidential nature of information (confidentiality)
− Mechanisms are supported, in order to record all system events and user activities, as
well as, attempts to gain access to sensitive information (transparency)
− Operation of the system improves competition conditions for the users (effectiveness)
− Use of interoperable (compatible) electronic means, generally available on the market or
broadly used in MS, thus avoiding the use of country-specific or otherwise discriminatory
technologies that restrict access to tendering procedures (interoperability).
− Use of technologies to ensure the secure communication of information and its storage in
system data repositories (security)

− Use of technologies which are widely available and at low cost, as well as, mechanisms
ensuring continuous operation of the system (general availability)
Each Good Practice is presented in the following way.
Description Brief description of the Good Practice

Functionality to Functionality that has to be supported in order to establish the Good
be supported Practice
Implementation Implementation steps that are necessary for the provision of the
approach to follow functionality
System Module eProcurement module that provides the functionality (eNotification,
eTendering, eAwarding, eInvoicing, ePayment)
Principles (Equal Treatment, Transparency, Effectiveness,
satisfied Interoperability, Security , General Availability, Confidentiality )
Risks Principles that may be in risk by the implementation of the Good
Practice
Input from Public administrations or eProcurement systems that gave input for this
idea
Number and Title of the Good Practice
At the end of the presentation of each Good Practice category, there is a discussion of the
deduced results. This discussion focuses on the coverage of the EU principles by the respective
eProcurement Practices of the category. A typical example of is presented hereafter.
General availability
Equal Treatment
Interoperability
Confidentiality
Transparency
Effectiveness
Security
No
[Name of the category] eProcurement
Practices
1 Title of the Good Practice ü

ü ü ü
2 Title of the Good Practice ?
3 Title of the Good Practice ü ü ?
4 Title of the Good Practice ü ? ü
Table 5: Coverage of the EU legislation principles by the [Name of the category] eProcurement
Practices
Separate symbols indicate which EU principles are satisfied by the eProcurement Practices (ü)
and which are in risk (? ). This presentation helps the reader to understand the main EU rules that
are covered by the eProcurement Practices in each category.
2.2 Support activity

As mentioned in section 1, the execution of the Evaluation Methodology requires a wide variety
of information for the reviewed systems. Furthermore, from the beginning of the analysis, it was
considered very difficult for all participating countries to be in a position to supply the contractor
with the full documentation requested. Therefore, the contractor has established a contingency

plan for achieving the aims of the report, even if some countries would not be in a position to
provide the minimum amount of information for conducting the analysis.
Before detailing the contingency plan, it should be noted that the contractor established two
mitigating activities, which are believed to have minimised the risk of introducing complications
during the collection of information for the analysis.
• Assistance by the EC: The cooperation between the contractor and the reviewed
administrations was achieved with the help of the EC. The contractor was introduced to all
MS during the 4th IDA eProcurement Working Group meeting on 20/01/2004, where an
opportunity was given to the contractor to give a presentation to all participants and explain
the objectives of the current project and report. Furthermore, it was possible for participants
to ask for any clarifications, as well as, volunteer in contributing to the analysis for the
current report.
• Structured communication: The communication with the reviewed administrations was
attempted to be as structured as possible, avoiding ad-hoc communications and requests to
contributors. A complete of list of required documents and a questionnaire were provided to
administrations, minimising the disruption contributors had to undergo, in order to contribute
to the current project. For completeness, the complete list of the requested documentation and
the questionnaire are presented in ANNEX A: Structured Communication (page 95).
The aforementioned mitigating activities were put in place in order to minimise the risks for
complications during the collection of information. Nevertheless, when a complication arose with
regard to the lack of information for a reviewed system, the contractor adopted the following
contingency plan, as demonstrated in Figure 1.
Request from
Complication Is the complication Is there another
YES YES EC to change
with a system early in the process? similar EU system?
systems
NO
NO
Raise problem
with EC and EC accepts
The adhoc evaluation will be NO
completed according to the request change?
assistance
information available during
that phase of the project and
may:
- exclude evaluation criteria Complication

from the established resolved? YES
methodology
- include new criteria, which
can be applied in the
investigated system (and NO YES
potentially all other systems)
Continue
Perform adhoc evaluation with
Switch system
evaluation current
methodology
Figure 1: EU Evaluation contingency plan

3 Reviewed countries
This section provides an analysis of the public eProcurement programmes of the reviewed
countries. The participating public administrations volunteered to explain the national
procurement legislative framework in their countries, demonstrate the capabilities of their
eProcurement systems during missions organised for this purpose, as well as, to provide technical
documentation and complete a detailed questionnaire (Annex A, page 95).
The main purpose of the review was to present the various approaches followed in each country,
in order to introduce eProcurement in the public sector. A lot of attention is given in
understanding the reasons that led to the development of systems that support certain phases of
eProcurement, the implementation strategy and the available funding of the project. This section
presents a general overview of the findings in the areas of local legislation and eProcurement
projects in each country.
3.1 Belgium
The Federal Public Services of Information and Communication Technologies (FedICT) is the
Belgian public organisation responsible for defining the eProcurement federal recommendations .
These recommendations are applicable in all three economically autonomous regions of the
country (Brussels-Capital Region, Flemish Region, and the Walloon Region). In particular, the
role of FedICT is summarised below:
• develop a common Belgian strategy for eGovernment projects
• establish uniform IT standards, including technical architecture and implementation
methodology
• assist federal public departments to implement the strategy
• monitor the execution of eGovernment projects and services
Drawing on the laws and regulations sponsored by the FedICT, the Service Public Fédéral (SPF)
of the Ministry of Defence (MoD) took the lead for the initial development and deployment of the
first building bricks of the federal e-tendering initiative. This resulted in the deployment of a total
of three portals. The first portal is operated by the Belgian MoD , whereas the second is
implemented for all Pouvoirs Adjudicateurs du Niveau Fédéral (amongst other SPFs and
equivalent federal bodies) under a wide FedICT’s sponsorship. The third portal comes under the
Bulletin of the Adjudications (BDA), a federal entity responsible for the publication of RFPs for
all Belgian public entities, has a special role for hosting and providing an e-meeting place for all
federal eNotifications. Currently, there is a common distributed government-wide portal named
JEPP based on the integrated JEPP application.
In the context of this report, the approach to eProcurement followed by the Belgian MoD was
reviewed and an analysis of the JEPP system was carried out. This was based on technical
documentation and filled questionnaire provided by the Belgian MoD. Furthermore, an on-line
demonstration of the platform was attended during a mission to the Belgian MoD, where
discussion was carried out about its technical capabilities, the experiences gained through its
operation, and the steps forward.
The JEPP platform provides a standardised toolbox for developing and hosting organisation-
specific eProcurement portals. Through this platform, public organisations are enabled to
establish a gateway to eProcurement, without significant upfront investments (software and/or
hardware costs) using a “buy a little, test a little, yield a little” iterative strategy.

Feature Description
Administration involved Ministry of Defence (MoD)
Project(s) JEPP
Objectives:
o Replace paper-based public purchasing procedures
o Accelerate the traditional procurement processes
Technology Provider Unisys Consulting
System(s) JEPP launched during the last quarter of 2002
o Common platform capable of hosting several eNotification portals
o FedICT, MoD and BDA portals currently hosted
o Web-based approach
o Microsoft Technologies utilised
o Current version supports:
− electronic publication of notices and invitations to tenderers
− re-organisation of back-office processes
o Electronic submission of tenders
o Secure opening, evaluation and ranking of tenders
o eCatalogues
o ePayment (referred as “ePayable”)
Table 6: Belgian Federal eProcurement approach
3.2 Denmark
The Danish government bodies responsible for the development and expansion of eProcurement
in Denmark comprise:
• The National Procurement Ltd (SKI), a limited company, partially owned by the Ministry of
Finance (55% of ownership) and several local administrations, with main roles:
o To define public procurement procedures and perform procurement competitions for
individual contracts and framework agreements, on behalf of the Danish public
sector.
o To develop and maintain an eProcurement system (ETHICS), covering the full cycle
of the classic procedures.
• The Agency of Government Management (AGM) under the Ministry of Finance. The primary
objective of AGM is to develop systems and procedures for eAuctions and repetitive
purchasing. The currently establish eProcurement platform accommodates purchases from
suppliers that have framework agreements with Danish government.
• The National Audit Office of Denmark that is responsible for frequent auditing of
procurement competitions and purchases within the Danish public sector.
According to a study made by AGM, Danish government agencies spend about $4 billion
annually on public procurement.
In the context of the current work, the DOIP system (Den Offentlige Indkøbsportal, i.e. the Public
Procurement Portal), developed and provided by gaterade.net Ltd for AGM, was considered and
further analysed, for identifying interesting eProcurement Practices . DOIP supports electronic
auctions and purchasing through electronic catalogues from suppliers that are under framework
agreement with the Danish government. A recent extension to the system, called DOIPEI,
provides advanced integration capabilities, facilitating the exchange of information between
DOIP/DOIPEI and other governmental or supplier systems. DOIPEI is also developed and
provided by gaterade.net Ltd.

Feature Description
Administrations involved Agency of Government Management (AGM)
Project DOIP
Objectives:
o Model internal recurring procurement procedure workflows
o Integrate with governmental and supplier legacy systems
o Achieve savings of around $20-50 million annually
Technology Provider gatetrade.net Ltd.
System(s) DOIP/DOIPEI launched during2002
o Web-based system
o Oracle exchange software
o Current version supports:
− electronic auctions
− electronic catalogues
− integration with back-office systems
− payment and logistics functionality
Step Forward Further developments:
o Integrate with ETHICS (an eTendering system)
Table 7: Danish AGM eProcurement approach
3.3 France
The government of France has set the target to modernise its public procurement mechanisms ,
through the enforcement of eProcurement throughout the whole French public sector. In this
respect, the French parliament approved (in 2002) the New Code for the Public Procurement
(NCMP), which came into force in January 2004. Furthermore, in March 2004, the French
Ministry of Finance announced the creation of a Central Purchasing Body, aiming to assist
contracting authorities for electronically purchasing their commodities (stationary, IT equipment,
furniture, etc.), under centrally arranged framework contracts (initially effective only for the
French Ministry of Finance).
According to the NCMP, all contracting authorities must be able to accept tenders submitted
electronically by 1st January 2005. The NCMP defines four types of contract awarding
procedures:
• Calls for tenders, foreseeing an open or restricted procedure
• Negotiated procedure, through competition with or without notification
• Simplified competitive dialogue, where the procurement agency specifies its needs with
the aid of selected suppliers, before creating a competition
• Contracts without prior formalities, for low-cost standard recurring purchases for
common frequent commodities
In the context of the current work, the e-achat platform was studied. e-achat is developed and
operated by the General Delegation for the Armament (DGA), of the French Ministry of Defence
(MINDEF). DGA is the most important purchasing authority in France, with a large volume of
operations for 2002 (73 armament programmes, €11.8 billion of purchases, €7.2 billion of
payments, and €905 million of intervention fees). Following significant re-structuring during the
last three years , due to the re-engineering of their internal business processes with the adoption of
eProcurement, DGA currently employs 18,000 personnel. The following table provides an
overview of the platform.

Feature Description
Administration involved General Delegation for the Armament (DGA)
Project e-achat launched in 2000
Objectives:
o Provide a fully operational electronic procurement platform, for the 200
procurement agencies of MINDEF (initially used by the 40 agencies that are
directly attached to DGA)
o Reduce administrative and bureaucracy costs
o Reform internal procurement procedures, by automating their paper-based
processes
o Improve transparency of public procurement
o Secure exchanges between suppliers and procurement agencies
Estimated gains:
o €10 billion from the costs of the armament programmes
o 31% reduction of the intervention fees
Technology Provider Consortium led by:
o Capgemini France
o France Telecom
System(s) The Defence Public Sector Marketplace (D PSM) which integrated two armament
portals was launched in 2003, facilitating the organisation of competitions, the
publishing of call for tenders notifications, and the submission of tenders:
o ixarm.com: used for the procurement of arms, ammunition and other combat
related supplies
o achats.defense.gouv.fr: covering the remaining defence procurement needs
(furniture, construction works, fuel, medical equipment, etc)
There exists support for private network establishment, between all involved parties,
for secure repetitive purchases (e.g. parts of Rafale fighting aircraft)
eAuction and eCatalogues services are currently offered through a third party platform
(Answork)
o Further promote the efficient use of eCatalogues services, by purchasing
agencies
o Entice more suppliers to participat e in eAuctions
o Implement eAwarding and eOrdering/eInvoicing functionality
o Create interfaces with internal back-office systems
Table 8: French MINDEF (DGA) eProcurement approach
The purchasing policy of MINDEF is based on open and fair competition. To enforce this
principle for the procurement of defence equipment, there is a tendency for MINDEF selecting
prime contractors without competition and assigning them responsibilities to organise a
competitive tendering procedure on behalf of MINDEF. In such cases, the MINDEF negotia tes
with prime contractor the certain conditions, under which the competition will be organised
between sub-contractors. This process aims at securing equality of treatment between all
MINDEF sub-contactors.
During the last year, the use of the two eProcurement portals has been spread among the different
procurement agencies of MINDEF. In this respect, e-achat platform has been recently proposed
by the French Prime Minister services, as a global government-wide solution, to be used by the
French pubic sector.

3.4 Italy
The body responsible for the development of eProcurement in Italy is an independent agency
called Consip (Concessionaria Servizi Informativi Pubblici - Public Information Services
Agency). Consip is a limited joint-stock company owned by the Italian Ministry of Economy and
Finance that provides consultancy and IT solution management in the field of eProcurment.
Consip’s primary objectives comprise:
• Provide assistance in the development and optimisation of IT eProcurement solutions, for
becoming available to all central and local contracting authorities in Italy
• Modernise the procurement procedures of the Italian public sector
• Renovate the internal IT systems of the Ministry of Economy and Finance
The 2000 Finance Act adopted by the Italian government presented opportunities for the Italian
contracting authorities, by service level agreements with suppliers, by simplifying/automating
their internal business processes. The Act introduced new procurement procedures for the Italian
public sector and required the functionality to be supported for the electronic supply of goods and
services by government contracting authorities. It formed the legal basis for the appointment of
Consip (in February 2000) as the responsible body for the implementation of eProcurement
systems for the Italian public sector. All central government agencies in Italy are obliged to use
Consip’s systems, whereas other public bodies (municipalities, hospitals, universities, etc.) are
also offered the opportunity to utilise them.
An overview of the Italian eProcurement approach developed by Consip (based on the 2000
Finance Act and the DPR 101/2002 Act that regulates online auctions and eMarketplace systems )
is presented below.
Feature Description
Administration involved Consip (Concessionaria Servizi Informativi Pubblici)
Project eProcurement launched in 2000 with an initial investment of €25 million
Main objective: to ensure “best value for money” for contracting authorities, through
open and fair competitions
Over 40,911 registered contracting authorities

Orders handled between August 2002 and December 2003 exceed 91.200 for a value
of €3,2 billion
Estimated gains (cumulative savings at December 2003 ):

o 36% average savings when buying online
o €1,5 billion savings on administrative costs
Technology Providers o EDS
o IBM
System(s) Lotto 1 (Lottery 1) launched in 2000
o Electronic Auctions
o Oracle Exchange
o Supports automatic evaluation of bids
Lotto 2 (Lottery 2) launched in 2000

o Repetitive p urchas es system
o Oracle Exchange
o Supporting purchases through electronic catalogues, for contract values below
EU threshold
o Support s Requests for Quot ation (RFQs)
Step Forward Further development of eProcurement systems to ensure that by 2005, half of total
public procurement of goods and services is carried out electronically
Table 9: Italian Consip eProcurement approach

3.5 Norway
The Norwegian procurement legislation favours decentralised public procurements, with the
largest volume of framework agreements procured solely by public sector entities, at local or
regional level. Centrally procured framework agreements are applicable only under special
circumstances. The underlying reasoning for this regulation is to enhance the procurement of
goods and services from SMEs, since centrally procured framework agreements commonly
include large product/service volumes that can be fulfille d only by large corporations.
The Norwegian Ministries of Labour and Government Administration (MLGA) and of Trade and
Industry (MTI) are responsible for implementing public sector purchasing polic ies and
developing/operating eProcurement systems for the public sector.
In the context of the current European State-of-the-Art report, the eProcurement project of the
Government Administration Services (GAS) was analysed. GAS is an underlying entity of
MLGA responsible for the definition and execution of the “Programme for Electronic Commerce
in the Norwegian Public Sector”. The main objective of this Programme is to introduce
eCommerce into all governmental organisations. The main project launched under this
Programme was the eMarketplace ehandel.no (launched in 2001), which is summarised in the
table below.
Feature Description
Administration involved Government Administration Services (GAS)
Project eMarketplace ehandel.no (ehandel) launched in 2001
Limited initial investment of €1.9 million over five years
Objectives:
o Provide public sector entities and their suppliers with easy access to an
affordable and easy to use eProcurement solution
o Develop a modular application to be the cornerstone for any future extension
o Achieve self-funding operation due to limited budget
Technology Provider Integrated Business Exchange (IBX)
System(s) ehandel - eOrdering system became operational in 2002:
o Repetitive p urchas es system
o CommerceOne , SAP, Poet and others
o Currently supports
− purchases of goods and services under existing framework agreements
or by free text search in catalogues and using round trip
− advanced reporting capabilities
− datawarehouse solutions
Step Forward Further developments comprise customisation and pilots for eSourcing and
eAuctions system supporting:
o eProcurement under individual contracts
o Supplier identification/sourcing
o RFIs, RFPs and RFQs (request for Invitations, Proposals and Quotations)
o eAuctions
o Framework agreements and dynamic purchasing system (DPS)
o Contract management
Table 10: Norwegian GAS eProcurement approach

3.6 Spain (Basque country)

The Basque Country is an autonomous community (2.100.000 habitants) of Spain, with its own
regional government , which exercises several authorities including public finance, education,
culture, health, security, industry, etc. The Basque Government has an annual budget of €2.25
billion for public procurement, which represents a 33% of the government budget (€1.9 billion of
operational costs and €350 million of real investment).
The Royal Decree Law 2/2000 establishes the environment for public procurement in Spain.
Three types of intermediaries are involved in the administrative procedure of public procurement
of the Basque Government:
• Government Procurement Bodies (about 150): responsible for defining global
government procurement needs for the Departments of the Basque government and
decide on issues related to them
• Markets Commissions (about 100): responsible for assisting Government Procurement
Bodies on legal issues
• Technical services (as many as the government departments and agencies): responsible
for defining needs and consulting the previous two on technical issues
For all public procurement above a certain threshold the responsible market commission is the
Central Commission for Public Procurement (CCPP) of the Department of Finance and Public
Administration. Furthermore, the Consultative Council for public procurement administrative
procedures acts as a central counselling body.
In 2000, the Department of Finance and Public Administration of the Basque Government
launched the eContratacion (eContracting) project with prime objective to provide Basque
contracting authorities with all necessary services for electronically performing their procurement
activitie s. The following table presents an overview of the eContratacion project.
Feature Description
Administration involved Department of Finance and Public Administration (DFPA)
Project eContratacion launched in 2000
Objectives:
o Improve performance of public procurement and minimise administration
costs
o Improve level of public services
o Standardise public procurement methods
o Encourage competition in an open and efficient environment
o Promote eCommerce and the use of di gital signatures
Technology Provider o EJIE (Basque Government Information Society)
System(s) - eContratacion eTendering
Currently supports contract notification and procurement of individual contracts
- eContratacion eMarketplace
A repetitive p urchas es system that currently supports purchases under framework
agreements through supplier eCatalogues
- Suppliers Registry
Database of fiscal and juridical information about registered enterprises
- Procurement Procedure and Documentation File Manager
Tendering procedure management system
o Contracts Registry
o Application for tracking online proposals status by tenderers
Table 11: Basque government eProcurement approach

3.7 United Kingdom

The UK public eProcurement rules, guidelines, and standards are primarily introduced by the
Office of Government Commerce (OGC), an independent Office of the Treasury. The OGC was
formed in 1999 , with an aim to improve the efficiency of public procurement in the UK. The
main activities of OGC comprise the following:
• Development of government market in UK following an efficient and transparent approach,

for attracting both local and oversees suppliers
• Definition of guidelines and establishing of standards from existin g eProcurement Practices,
resulting in eProcurement platforms for the public sector, adopting the principles of equal
treatment and openness
• Provision of efficient IT services for supporting the procurement business of contracting
authorities
• Offering assistance to public administrations for developing their eProcurement systems in
compliance with UK procurement legislation
In the context of the current work, the UK eProcurement policy and systems adopted by OGC
have been examined, as summarised in the table below:
Feature Description
Administration involved Office of Government Commerce (OGC)
OGCbuying.solutions agency created in 2000

o Providing legal and organisational support to contracting authorities
o Purchasing IT services from 3rd party companies
o Defining set-up and subscription fees for participating contracting authorities
o Ensuring that services offered follow UK government standards, with regard
to security and interoperability
o Estimated gains: 20-25% average savings, when buying online through
eProcurement service
Project eProcurement Strategy launched in October 2002
Three streams identified:

o eProcurement Tools: use of Commercial Off The Shelf (COTS) tools
− enable procurement and sourcing processes
− purchase IT service from providers to cover functionality needs
o Zanzibar (eHUB/Purchase-to-Pay)
− establish the Purchase-to-Pay system (eCatalogues system)
− develop transactional hub for system-to-system integration
o Change Management
− establish government supplier adoption programme
− develop the eProcurement Assessment Tool (ePAT) to conclude the
status of eProcurement in the UK public sector
Technology Provider N/A
System(s) 5 different 3rd party eAuctions services:
- Currently supporting electronic auctions
- Project for establishing eSourcing service, covering the procurement of individual
contracts, following the same strategy of the existing eAuction services
Table 12: UK – OGC eProcurement approach

3.8 United Kingdom (Scotland)

Acting as the administrative arm of the Government of Scotland since its establishment, in 1999,
the Scottish Executive is involved in different public sector management activitie s, compris ing
health, justice, education, rural affairs, and transport. The Ministry for Finance and Public
Services of the Scottish Executive is responsible for the public spending in Scotland, as well as,
for establishing the procurement policy applied for all public sector procurement.
In November 2001, the Scottish Executive launched the eProcurement Scotland (ePS) project,
with main objective to provide contracting authorities with all necessary services for performing
electronically their procurement activities. The following table presents an overview of the ePS
project.
Feature Description
Administration involved Scottish Executive
Project ePS launched in 2001
Objectives:
o Develop an open eProcurement platform accessible to all public sector buyers
and suppliers
o Cover all the phases of eProcurement lifecycle
Supports a Supplier Adoption initiative: a methodology to assist suppliers convert

their business procurement operations to electronic processes
Applies set-up and subscription costs for participating contracting authorities

Technology Provider o Cap Gemini Ernst & Young
o Elcom
System(s) Dynamic Trade Centre (DTC)
Currently supports procurement of individual contracts
PECOS
A repetitive p urchas es system that currently supports purchases under framework
agreements
Supplier Adoption Database

An application for assisting the adoption of suppliers to eProcurement following an
established methodology
eCatalogues converter
An application used for transforming electronic catalogues maintained by suppliers
into PECOS format
Step Forward Further enhance the functionality supported by DTC:
− p reparation of PINs
− Web Forms for PQQ and bid submission
− Automated scoring
Table 13: Scottish Executive eProcurement approach

3.9 Other Countries

This section summarises interesting eProcurement implementation approaches adopted in
Finland, Hungary, and Sweden. These countries provided information in the context of the
current State-of-the-Art review; however no systems were offered for further analysis and
identification of eProcurement Practices. The details presented in this section are based on
information transmitted by the reviewed administrations. Due to the limited information, the
sections related to Finland and Hungary do not contain table s describing their current status.
3.9.1 Finland
The Trading House Hansel, a government-owned company, is responsible for the development of
the Sentteri eProcurement system, which is based on the principles and procedures described in
the Finish Public Procurement Act. Sentteri covers the complete procurement lifecycle.
Approximately five thousand contracting authorities issue calls for tenders through Sentteri
system, settling more than two hundred tenders per year and creating an annual total purchasing
value of €168 million.
The system is developed in distinct module s. The two most important modules comprise:
• Tenderi: it fully supports the eTendering phase of eProcurement. It provides assistance to
contracting authorities for preparing their tenders and sends automatic notification to
suppliers, containing information about tenders matching their profile. Potential suppliers can
also receive tendering forms electronically and submit their tenders using web-forms. The
system automates procedures related with assessment and evaluation of tenders, produces
administrative reports, and creates the necessary documents associated with contract
awarding.
• Merkaattori: it is an electronic ordering system based on eCatalogues that facilitates the
purchasing of goods and services under framework agreements, by Finnish public sector.
The main features of Sentteri are summarised below:

− Provides to suppliers access to call for tenders notices
− Facilitates contracting authorities to enter their notifications online
− Employs weighting factors and tendering criteria for evaluation of tenders
− Supports the online submission of tenders and their locking until the pre-defined tender
opening time
− Facilitates the electronic opening of tenders only by an authorised person
− Creates all necessary administrative documents for the awarding authority
− Facilitates the automatic forwarding of the appropriate documents to recipients, including the
selected and unsuccessful tenderers.
The use of the system does not impose any fees to suppliers, while contracting authorities pay
fees only in case they require custom-made implementations (the “out of the box” operation of
the system is offered at no cost to contracting authorities).
Even though the system was initially developed to serve the needs of public procurement in
Finland, foreign suppliers expressed their interest to participate in public contests. This can be
enabled by the fact that the system currently supports the English language; although at the
moment the contracting authorities do not use this feature.

The system is implemented using Microsoft ASP technology. Special care was given to the
development of security, aspects and in particular to the support of an enhanced auditing
mechanism for all eProcurement activities.
3.9.2 Hungary
Comments of the Hungarian administration focuses in particular to product categorisation and the
use of CPV codes. The Republic of Hungary introduced their current public procurement
legislation in 1995. Drawing on this legislative framework, the government established the
institute of Centralised Public Procurement (CPP) for supporting centralised procurement
activities for all public entities that are directly dependent on government budget. In order for
CPP to aggregate the volume of public procurement, all public entities are obliged to provide
notices on their procurement requirements for CPP launching of procurement procedures.
During the preparation phase for the introduction of electronic procurement to the public sector,
the Hungarian government realised that the lack of a clear classification hierarchy for goods and
services prohibits the preparation of quality product catalogues and creates obstacles to the
systematic statistical analysis of government spending. The technology provider of the Hungarian
government attempted to utilise UN/SPSC classification schema; however the problem of
combining products with existing contracts under a common classification schema remained
unsolved.
Following this failed attempt, CPP decided to introduce a new classification hierarchy, which
relies on the current structure and relevant practices followed in the Hungarian market, and
correlates product categorisation codes with product attributes. This hierarchy is dynamic and
display cross-references to other similar hierarchies (UN/SPSC, CPV, E-CLASS, etc). According
to this, each product will be associated with product attributes, which will be used for classifying
the products into 3 or 4 categories.
3.9.3 Sweden
Public procurement in Sweden is decentralised. At central level, the Swedish Agency for Public
Management (Statskontoret) is charged by government to coordinate public procurement. County
councils and municipalities, however, have an independent status and are generally free to
organise procurement within their respective area of competence. They often act on their own, or
sometimes they collaborate locally/regionally or through the national Associations/Federations.
When initiating the first large-scale public eProcurement project in Sweden, involving
representatives for state counties and municipalities, it was recognised that one common system
would not fit the Swedish procurement practice. Instead, the project set focus on the development
of common specifications and engaged some IT suppliers to develop systems and services to
compete on the market.
When the project terminated, the results were taken over by a Committee, representing all three
levels of government, and the work has since then been carried on under the name of Single Face
to Industry (SFTI). Its programme of work covers activities like awareness and promotion of
eProcurement, identification of common requirements, development of standards and working
practices and encouragement to IT suppliers to develop of systems and services supporting the
specifications. The official web site is http://www.eh.svekom.se/.

Several IT suppliers developed additional or even alternative solutions based on their market
expectations. One conclusion is that interoperability and integration issues have to be high on the
SFTI agenda. Statskontoret’s user questionnaires show that the SFTI organisation has achieved
the best result, in terms of eProcurement implementations, at the local and regional levels
According to a survey in May, 2003, 73 local authorities/municipalities out of 290 (250 answered
the survey) had initiated eProcurement initiatives (mostly ordering-invoice process). Further 50
had taken a decision to begin with eProcurement and 70 others could consider beginning within
the next few years. Many municipalities and county councils have also initiated eProcurement
projects (e-tendering and e-awarding phases).
The SFTI (Single Face to Industry) initiative recently adopted standards for "simple" electronic
invoicing targeting, among others, SMEs and other users that so far have been reluctant to engage
in EDI. SFTI is not a "system", but support to systems. One of the cornerstones of the
specification is a basic transport profile, the SFTI transport profile Bas.
The specification is based on the ebXML Message Service Specification and parts of the ebXML
Business Process Specification Schema. Although developed for the "simple" e-invoicing
purpose, it may be used for any kind of message as long as it is defined by a formatted
specification schema.
The specification has intentionally been kept at the basic level, so that it has a potential for wide-
spread implementation with limited resources on heterogeneous systems and based on knowledge
and technology that is commonly available. Users, who require additional features, for example
regarding security, can upgrade within the ebXML framework from this profile.
SFTI so far has given priority to the post-contract phases of eProcurement compared to the early
ones. The argument for this decision is simply that they are transaction-intensive with only small
variations in the data exchanged.
With regard to publication of notices, service providers already offer competitive solutions to
contracting authorities, including significant electronic communication with OJEU. For invitation
to tender and bidding, an in-depth SFTI study was carried out but not over implementation,
pending the implications of new public procurement directives. Nevertheless, a couple of
software suppliers offer tendering platforms based on vital parts of the concepts. The case of
Ekerö municipality and the University of Lund can serve as an example of this type of
developments. The system that is used by the University of Lund and other universities has
functionality for electronic submission of tenders as well as automatic evaluation of tenders. The
report from the study can be obtained from http://www.eh.svekom.se/english/reports.htm.
In Sweden framework agreements are common. The core of developments by SFTI relates to a
scenario of interrelated transactions for price lists, orders, order responses, delivery advices and
invoices exchanged under such framework agreements. Two approaches are supported: a) the use
of a central catalogue/price list operated either by the buyer or a third party b) supplier-
maintained catalogues. In the latter case orders can be placed directly on a supplier’s web site or
via a punch-out mechanism.
Another main scenario profile covers periodic invoicing of bills (energy, telephone, etc.).

In the initial work the emphasis was put on interface specifications, while in later work systems
internal requirements and functionality has been given more attention. A general conclusion has
been that establishing electronic data exchange itself is not enough; in order to tap the benefits of
electronic public procurement, system functions and routines may need to be reviewed.
Another experience is the fact that the heterogeneous group of suppliers can not be expected to fit
into one common way of working, with the same degree of automation – the incentives for
switching over to eProcurement differ. The electronic scenarios that were first drawn up take care
of high-volume relations but they are not cost-effective for the low -volume ones. In a recent
development SFTI has developed a simple electronic invoice for use in such relations. It is based
on XML technology and the plan is to encourage IT suppliers to implement it in their standard
applications so that parties to trade can start invoicing in new relations with minimal set-up
efforts.
Information about the IT solutions that are based on the SFTI standard for public sector and their
suppliers are available at http://www.eh.svekom.se/.
One example from Sweden regarding the use of electronic signatures in the eProcurement phase
is ChamberSign. ChamberSign is an international organisation with presence and associations
with local Chambers in many countries within the EU. ChamberSign has created a secure
international environment where certified enterprises can carry out online procurement. In
Sweden the municipality of Ekero and the Third National Pension Fund (AP 3) are already using
ChamberSign´s solution for eTendering.
The following table presents an overview of the Swedish eProcurement approach.
Feature Description
Administration involved The Association of Local Authorities, The Federation of County Councils and The
Swedish Agency for Public Management
Project SFTI – Single Face To Industry
Objectives:
o Development of common eProcurement specifications
o Promotion / encouragement of the use of eProcuremnet in Sweden
Technology Provider Several IT suppliers; each contracting agency/public buyer decides on its own
eProcurement solution
System(s) Joint SFTI specifications,
current versions support
- electronic catalogues under framework agreement
- interaction with back-office systems
- invoicing.
Initiative by individual authorities or operators offer additional eProcurement features

Step Forward Further SFTI developments comprise:
− Involvement of more buyers and suppliers
− New technology and simplified start-up processes
Table 14: Swedish eProcurement approach

4 Electronic Procurement Systems

This section provides an in-depth analysis of the selected eProcurement systems, summarising
their main functional capabilities and noteworthy technical features, as well as, examining their
level of compliance with the new legislative framework. For presentation purposes, the systems
are classified under four different categories, according to the eProcurement procedures they
support:
• Individual Contracts: systems that support the notif ication, submission, and/or awarding
phases of eProcurement, under the open, restricted, or negotiated procedures.
• Repetitive Purchasing : systems that support procurement through framework agreements,
eCatalogues, or marketplaces resembling the DPS mechanism. Main attributes of such
systems presented include among others the order approval workflows, the integration with
legacy systems of suppliers, eInvoicing, and ePayments.
• eAuctions: systems that support eAuctions, featuring the preparation of competitio n criteria,
the definition of bid evaluation functions, the support for online bid submission, and the
automated ranking of bids.
• Supplementary systems: they comprise peripheral systems that enhance the existing
functionality of operational eProcurement systems; however, without modelling any specific
eProcurement activities.
4.1 Individual Contracts

According to the new public procurement legislation, individual contracts can be awarded
through the following procedures:
• Open: all interested suppliers can participate in an open procedure competition.
• Restricted: all interested supplier can request to participate in a restricted procedure
competition. Only the ones invited by the contract authority may submit a tender.
• Negotiated: the procedure whereby contracting authorities consult the Economic Operators
of their choice (three or more) to negotiate the terms of the contract. The negotiated
procedure may be followed in exceptional circumstances, detailed in the EU public
procurement directives.
The foreseen phases under the procurement of individual contracts comprise:
• eNotification: concerns the preparation and publication of tender documentation (including
the definition of the tender evaluation criteria).
• eTendering : concerns the publication of Additional documents (Questions & Answers
session), publication of corrigenda, supplier short-listing, safe and authenticated submission
of tenders, and secure tender-locking until a pre-defined opening time.
• eAwarding : concerns the tender opening procedure, the subseque nt evaluation based on per-
defined criteria, and the publication of the contract award notice.
Table 15 summarises state -of-the-art functional features to be offered by an eProcurement system

supporting individual contracts. The following notation is followed:
• First column displays the main phases of eProcurement life-cycle and primary principles to
be satisfied. This column is common for all systems.
• Second column lists the required functionality associated with each phase or principle. This
column is common for all systems under the same category. It also contains boxes to tick, in
case the specific functionality is supported.

• Third column provides a description on how the reviewed system addresses the required
eProcurement functionality. In the following table, the information available in the third
column explains the functionality required under the new legislative framework.
eNotification support ? Documentation preparation • Online preparation of tender documentation
? Contract Notification • Call for tenders notification publication
? Integration to OJEU • Automated publication of call for tenders
notification to the OJEU
eTendering support ? Request to participate • Online Expression of Interest (EOI)
? Short listing of tenderers • Online supplier qualification
? Invitation to tender • Online response to the EOI
? Tender submission • Online submission of tenders
? Updating of tenders • Online updating of submitted tenders
? Locking of tenders • Automated secure locking of submitted tenders,
until predefined opening time
eAwarding support ? Tender opening • Secure opening of submitted tenders
? Tender evaluation • Online evaluation of tenders
? eAuct ions • eAuction competition
? Contract Award • Online process for awarding contracts
? Award Notification • Publication of contract award notification
Back Office support ? Pre-defined reports • Reporting capability
? Monitoring of logs • Analysis of system logs (audit trailing logs)
? Statistical analysis • Sophisticated statistical capability
Equal amount of ? Automated notification • Automated user alerting for important events
information ? Questions & Answers • Online execution of Q&A sessions
Pan-European standards ? International Coding • Categorisation according to international
hierarchical coding systems (CPV, UN/SPSC, etc.)
? Document standards • Standard document file formats
Unrestricted access to ? Full competition documentation • Publication of details for complete procurement
information process
Interoperability ? System accessibility • Ease of access to the system
? No software/hardware • No cost-related software/hardware prerequisites to
requirements access system
? Multilingualism support • Multiple character sets
? Localisation parameterisation • GUI parameterisation (currency, date/time format,
units of measure, etc.)
Confidential nature of ? User profiles • Restricted access to data according to user profile
data
Restrict access to tenders ? Locking of supplier tenders • Instant locking of submitted tenders
? Encryption of stored tenders • Secure storage of submitted tender
Four eyes principle ? Two officials to open tenders • Opening of tenders by simultaneous action of at
least two physical persons
Authentication ? Authentication of tenderers • Proof of user identity
Call for Tenders ? Tenders compliant with call for • Acceptance of tenders which conform to the call
specifications tender specification for tenders specification
Security ? Usage of SSL • Minimum security level for data transmission
? Data encryption • Secure storage of all sensitive information
? Digital Signatures • Application of digital certificates
Audit Trail / Traceability ? All user actions recorded in • Automated storage of all system event details
system logs
? Detection of tampering attempts • Mechanism for monitoring infiltration attempts
Time-stamping ? Official time • Integration to 3rd party, for official guarantee
Table 15: Features that establish the uniformity of an Individual Contract system with the new
legislative framework on public procurement

4.1.1 DTC – Scottish Executive (UK/Scotland)

The Dynamic Trade Centre (DTC) offered by the Scottish Executive is an eProcurement system
currently covering the phases of eNotification and eTendering. DTC fully supports the processes
of negotiated competitions with/without notification, the submission, and the opening of tenders
for individual contracts. DTC is an “off-the-shelf” system (Elcom’s eRFx), configured according
to the workflows of the Scottish regulations on eProcurement. The system offers built-in
functionality for automatically evaluating tenders and organising eAuctions. However, this
functionality is not activated at the moment. The following table presents an overview of the most
important features of the DTC system.

Functionality overview - Negotiated with/without notification competitions
- Submission of tenders
- Opening of tenders
- Online evaluation of tenders (not currently activat ed)
- eAuctions (not currently activated)
Exploitation model - Subscription fees for contracting authorities
o Set-up fee of about £80.000
o Annual subscription is £60.000 in the first year, gradually reduced to
£45.000 for the sixth year
o Fees include analysis of estimating expected savings , due to the
utilisation of the system
o Fees also include the usage of PECOS and other ePS secondary
applications
- Suppliers:
o No cost
Actors - Buyer: responsible for the:
o Creation of tender documentation
o Notification of supplier base for upcoming competition
o Answering to supplier questions
- Supplier: responsible for the:
o Downloading of the Pre-Qualification Questionnaire (PQQ) and
Invitation to Tender (ITT)
o Uploading of the completed PQQ and bidding documentation
Technology used - Hosted service developed based on Java technologies
Security policy - Authentication is performed through the use of user credentials (username
Interesting system characteristics
and password)
- Use of SSL for secure communication
- No use of digital signatures
Means of - Email is the primary communication medium used for:
communication o Reporting the stage of each competition (i.e. updated documents, new
questions and/or answers, etc), but not for exchanging documents with
sensitive information
- Each supplier has a functional “inbox” within the system, allowing for the:
o trailing of all previous communications
o monitoring email communications that have not been read
Documents - System treats documents as attachments, which can be of any type
- Call documentation and tenders are prepared offline utilising commercial
programs
- No technical solutions for virus infected or corrupted offers

Tender box - Submitted tenders are stored in a “tender box”, which is used for the:
o Secure locking of tenders
o Denial of access to users, until pre-defined tender opening time
o Tenders are not encrypted while locked by the tender box
o Automatic opening of tenders
- Stored tender documents are not encrypted
- Tenders open automatically, not following the four eye principle
Offline activities - Both online and offline activities are supported during the tendering period
- Suppliers can chose to download the call documentation online and then
submit the tender offline, and vice-versa
Multilingualism - Uploaded call documentation can be in any language
- The GUI of the system is provided only in English
Table 16: DTC system overview
4.1.1.1 DTC state-of-the -art features assessment

The following table presents an assessment of DTC features against the state-of-the-art, as
required by the new legislative framework, or identified during the analysis of the current project.
The upper part of the table presents all functional aspects in terms of the eProcurement lifecycle,
while the lower part demonstrates overall technical qualities of the system.

eNotification support û Documentation preparation • Documents prepared offline
• No workflow support
• Document templates assist users to
compose the PIN
ü Contract Notification • Suppliers are notified via email
• Suppliers can download the tender
documentation from the relevant section
• No build-in publication board
û Integration to OJEU • No automated publication to OJEU
eTendering support ü Request to participate • Suppliers can prepare an RTP offline and
then upload it on the designated upload
section
û Short listing of tenderers • Short-listing is performed offline
• The system can support automated
evaluation of Web Forms, which is in the
future plans of enrolment
ü Invitation to tender • Achieved via email
ü Tender submission • Suppliers can prepare tender documentation
offline and then upload it on the designated
upload section
ü Updating of tenders • Suppliers can update their tender
documentation offline and then upload it on
the designated upload section. The previous
version of the tender documentation is
automatically deleted
ü Locking of tenders • “Tender box” functionality locks the tenders
• Tenders remain inaccessible by system
users, until the tender opening time
• Tenders are not encrypted - they can be
accessed only by system administrators

eAwarding support ü Tender opening • “Tender box” functionality opens tenders

automatically, when the tender opening
time arrives
• Tender opening time can be modified by the
buyer
• The Four Eyes Principle is not supported.
• The opening of technical and financial
offers in two phases is not supported
û Tender evaluation • Evaluation is performed offline
• The system can support automated
evaluation if Web Forms are used, which is
in the future plans of enrolment
û eAuctions • Not supported
û Contract Award • Not supported
ü Award Notification • Performed manually and published on the
bulletin board
Back Office support ü Pre-defined reports • Can produce reports for a competition
û Monitoring of logs • Cannot create reports from system logs
û Statistical analysis • Does not support statistical analysis of data
Equal amount of ü Automated notification • Achieved through email
information ü Questions & Answers • System supports a bulletin board for Q&A
sessions
Pan-European standards ü International Coding • Notifications abide to CPV standards
û Document standards • Does not support specific document
standards
• Tender documents are treated as
attachments, which can be of any type
• There is no virus protection mechanism
Unrestricted access to ü Full competition documentation • Competition details are published in the
information eNotification phase
• Training and user manuals are available for
educating suppliers on how to use the
system
Interoperability ü System accessibility • Web-based system
ü No software/hardware • Only an Internet-enabled PC is required
requirements
û Multilingualism support • System is only in English
• Call documentation and tenders can be in
any language (currently in English)
û Localisation parameterisation • Does not support localisation of GUI
Confidential nature of ü User profiles • User authentication is performed through
data the use of username and password
• User profiles define the data that each user
has access to
Restrict access to tenders ü Locking of supplier tenders • “Tender box” locks tenders as soon as they
are uploaded by suppliers
û Encryption when tenders are stored • Tenders are not encrypted
Four eyes principle û Two officials to open tenders • Tenders are unlocked automatically when
the tender opening time is reached
Authentication ü Authentication of tenderers • Through the use of credentials
Call for Tenders û Tenders compliant with call for • Tenders are free-text documents and there is
specifications tenders specification no automated mechanism to ensure
compliance with call for tenders
specifications
Security ü Usage of SSL • Enabled
û Data encryption • Not supported
û Digital Signatures • Not supported

Audit Trail / Traceability ü All user actions recorded in • Enabled

system logs
û Detection of tamp ering attempts • No mechanism to detect infringements
Time-stamping û Official time • Not supported
Table 17: DTC coverage of the new legislati ve framework on eProcurement
4.1.1.2 Analysis of DTC system functionality

This section presents in a systematic manner the functionality supported by DTC. The
functionality is presented under a workflow of activities, from the creation of call documentation
to tender opening, for the Buyer and the Supplier actors supported by the system.

Creation of call Buyer • Call documentation is currently created offline, usually in PDF files
documentation and then uploaded onto the system
• No workflow support for assisting the user to create the required
documentation
• No workflow for the hierarchical approval of documentation
• Pre-defined templates can guide the buyer into completing the
required notification documents
• DTC supports the online creation of call documentation and tenders,
utilising customisable Web Forms (not currently used)
• Web Forms will be considered as a future enhancement and will
occur in a phased approach
• Web Forms will allow the automated evaluation of tenders and Pre-
qualification questionnaires (PQQs)
Notification for Buyer • Notification of suppliers achieved via email
Negotiated with • Buyer needs to input all email addresses of the required suppliers
advertisement • System emails the selected suppliers with details on how to register
Procedure
Registration Supplier • Once receiving an email, a supplier can register into the system
• Registration does not require any complicated information on behalf
of the supplier.
• No costs are involved
Browsing Questions Supplier • System supports Q&A sessions by providing the functionality of a
and Answers / Posting standardised bulletin board, moderated by staff of the buyers
Questions • Supplier can browse through the Q&A session and gain access to all
published questions and answers
• Supplier can post a question to the bulleting board
• All questions are moderated by the buyer (if a question is not
approved by the buyer, it is not accessible by suppliers)
Answering Questions Buyer • Buyer needs to validate (approve or modify) a question, as posed by
a supplier before providing an answer (for ensuring confidentiality)
• As soon as a question is replied by the buyer, it is visible by all
suppliers, thus ensuring equal treatment
Updating call Buyer • When call documentation is modified, all participating suppliers are
documentation notified via email, as the system is aware of all suppliers that
downloaded previous versions
Tender submission Suppliers • Tenders are prepared offline and then uploaded to the system
• Tender documentation is usually prepared in PDF format but system
can accept any file format
• Once a tender is uploaded onto the system, it is locked and
inaccessible until the tender submission deadline and the opening of
tenders
Updating tender Supplier • Tender documentation can be updated by the supplier any time
documentation before the tender submission deadline
• System automatically disregards previous versions of tenders and
considers the latest version as the only valid one

considers the latest version as the only valid one

Tender submission Buyer • Tender submission deadline can be extended by the buyer at any
deadline extension time, during the submission period
• All participating suppliers are automatically notified via email for
any extension of submission deadline, as their email addresses are
available to the system
Tender opening System • Uploaded tenders are locked into the system and are inaccessible
until the tender submission deadline is reached
• When the tender submission deadline is reached, all tenders are
opened automatically and made available to the contracting
authorities staff
• The system allows for the setting of different times for tender
submission deadline and tender opening date/time, the former being
the deadline for system accepting tenders and the latter being the
exact time when all tenders are opened (this functionality is not
currently activated)
Table 18: DTC functionality overview
A small number of interoperability aspects with regards to Web-browser compliance are currently
addressed, whereas an analysis of eAuctions is performed, in order for the associated module to
be activated. Furthermore, Capgemini assists Scottish Executive to define the specifications for
utilising the built-in Web Forms functionality, thus facilitating the more efficient and controlled
collection of tenders. The use of Web Forms will facilitate automated validation for submitted
tenders. Hence only tenders that are compliant with the call specification will be acceptable . On
top of this, the use of Web Forms for submitting tenders will facilitate their automated evaluation.
4.1.2 DPSM – Ministry of Defence (FRANCE)

The French Ministry of Defence (MINDEF) has realised the e-achat project led by the Directorate
for Programs and Procurement Methods (DPM), of the Directorate General for Armament
(DGA). The initial achievement of the e-achat project was the development of an eProcurement
platform, called the Defence Public Service Marketplace (DPSM).
Currently, DPSM is endorsing two eProcurement portals, dedicated to the electronic procurement
of the defence public sector. ixarm.com, is used for the procurement of defence systems, and
achats.defense.gouv.fr, is used for other procurements within MINDEF (infrastructure, gas,
health, support, etc).
The following table provides an overview of the most important features of the DPSM system.

Functionality overview - Public area: by providing their company name, family name, and a valid
personal e-mail address, visitors gain access to:
o Defence news
o Public notices of MINDEF
o Download facilities for calls documentation
- Tendering room: registered suppliers have access to published calls for tender.
They can download call documentation and respond, by submitting their
tenders electronically. Three types of procurement procedures are supported
o open (anyone can participate)
o restricted (only invited suppliers can participate)
o negotiated (with or without notification)
- e-Auctions room: registered suppliers can participate in electronic auctions
- e-Catalogues room: buyers can purchase from electronic catalogues, published
by suppliers

- eBilling/invoicing: suppliers can invoice the contracting authority and buyers

can fulfil their payment obligations electronically (not currently operational)
- SMEs can make unsolicited proposals for the acquisition and maintenance of
defence equipment , based on innovative ideas with defence flavour, and/or be
given the opportunity to win contracts
Exploitation model - Contracting authorities:
o No cost
- Suppliers:
o No cost
o Only companies registered in EU Member States are accepted
o Applications must be authorised by MINDEF. This process takes up to
three working days
Actors - Administrator: responsible for attributing roles to users of a procurement
agency (one person for each one of the 203 MINDEF procurement agencies)
- Procurement officer: responsible for creating a public notification for a call for
tenders and for organising electronically submitted bids
- President of the awarding committee: responsible for the electronic opening of
the submitted tenders
- Supplier: any SME operating in the area of defence systems can be registered
at the DPSM database of defence suppliers. An administrator has to be
assigned for each SME
Technology used - The two portals share the same toolbox
o Broadvision software package used for the development of the web
portals
o Trace and Capgemini developed the eTendering module
o CommerceOne software was used for the eAuctions and eCatalogues
modules
o Portals are optimised for Microsoft Internet Explorer 5.0 or greater
and Netscape 6.1 or greater or any other compatible Web browser
o Some pages need Flash player 5.0
o JavaTM 2 Runtime Environment, Standard Edition 1.4.1 is necessary
for the electronic submission of tenders
- All necessary tools are available for downloading
- All contracts between M INDEF and its contractors concerning the
eProcurement platform are expiring at the end of 2004. The next phase will
keep the core of the platform intact and transform the portals in OSS
technology
Security policy - Time-stamping of the tenders
- Use of digital signatures for the encryption (HTTPS)
o Acquisition of a certificate that is recognised by MINDEF (actually
Certinomis – Socieposte or Credit Lyonnais – Authentys)
o Average time for obtaining a certificate is two to three weeks
o Electronic tools used for the signing of tenders are downloaded when
a tender is submitted for the first time
o Sup plier signs the tender before submission
o Tenders must be transmitted at least 24 hours after they have been
signed
- Use of SSL for secure communication
- Tenders are locked, encrypted, and checked for virus up on reception
o If a virus is detected, an email is sent to the supplier, requesting for the
virus to be removed and the document to be resubmitted
- Decryption of tenders made via key that becomes available only to the
president of the contract awarding committee, after tender submission deadline
Alerting mechanism - Available mechanism for creating alerts to inform suppliers by email for any
new suitable business opportunities that come up and satisfy their pre-selected
criteria and profile
o Customisation of supplier’s home page and filtering of news and
available call for tenders notifications
o Q&A sessions operating via email

Document treatment - Use of the EU’s CPV standard

- All document formats are accepted
- Complete call documentation package sent in an archived and compressed
format
Online help - Help documentation, user manuals, glossary, and a FAQs are available online
- Online ni formation for the MINDEF’s procurement agencies, the current
legislation in force, and explanation of the procedures for public procurement
Offline activities - Both online and offline activities are supported during the tendering period
- Supplier can chose to download the call documentation online and then submit
a tender offline and vice-versa
- Procurement officers use an offline workflow tool for organising the
procurement procedure and templates for creating call documentation. In
future, these tools will be integrated with the eProcurement platform.
Reporting capabilities - Provision of a robust reporting mechanism for statistical analysis, regarding the
use of the platform by procurement agencies (upload of tenders), the use of the
system by suppliers (downloads from members and non-members), etc.
Table 19: DPSM system overview

During the first year of platform’s operation, all 203 procurement agencies of MINDEF have
been integrated into the system, thus accounting for more than 600 users. About 2,300 suppliers
have become members of the two armament portals. Currently, 150 to 200 new solicitations are
available electronically every month. Especially for the last quarter of 2003, the percentage of
electronic procurement processes reached 50% . There have been about 1,400 downloads of
electronic documentation, 80% of which coming from unregistered suppliers, with an average of
11 downloads per call documentation. During the first two months of 2004, the number of call
documentation put online increased (from 140 at the end of December 2003 to 320 at the end of
February 2004). During the same period, the number of downloads increased from 1400 to 2200.
As there is still an 80% of call documentation downloads , which are initiated from unregistered
tenderers that eventually submit their tenders offline, the next challenge for MINDEF is to
encourage these tenderers to use the electronic platform. Furthermore, a next phase of the project
will focus on the other end of the eProcurement pipeline, namely the eInvoicing and ePayments.
The objective will be to automate the invoicing and payment processes from a single -point of
access, i.e. the armament portal. This has already been achieved through the private network of
the MINDEF only for some specific procurement needs (section 3.3).
4.1.2.1 DPSM state -of-the -art features assessment

The following table presents an assessment of DPSM features against the state -of-the-art, as


eNotification support û Documentation preparation • Documents prepared offline
• Form fill and workflow support from external
tools
ü Contract Notification • Publication of call for tenders notices, after
their official publication to OJEU
û Integration to OJEU • No automated publication to OJEU
• Currently under development
eTendering support ü Request to participate • Suppliers can submit a RTP
û Short listing of tenderers • Short-listing is performed offline manually
ü Invitation to tender • Achieved via email
ü Tender submission • Suppliers can prepare a tender offline and then
upload it in the designated section
ü Updating of tenders • Suppliers can update their tender
documentation offline and then upload it in
the designated section (previous version is
also maintained)
ü Locking of tenders • Tenders are locked
• Tenders are encrypted and become
inaccessible by system users, until tender
submission deadline
eAwarding support ü Tender opening • Tenders are unlocked when tender opening
time is reached
• Tender opening time can be modified by buyer
• Tenders are opened in two phases (technical
offers first and financial offers later)
û Tender evaluation • Evaluation is performed offline manually
ü eAuctions • Registered members have access to the
electronic auctions room
û Contract Award • Not supported
ü Award Notification • Performed manually and published on a
designated area of the portal
Back Office support ü Pre-defined reports • Pre-defined reports available for monitoring
purposes
ü Monitoring of logs • Logs from all user actions are stored and used
for producing reports
ü Statistical analysis • Statistical analysis on the use of the system is
performed by administrators
Equal amount of ü Automated notification • Supported via email
information ü Questions & Answers • Supported via email
Pan-European standards ü International Coding • Support of CPV standards
û Document standards • No specific document standards are supported
• Tender documentation treated as attachments,
which can be of any format
Unrestricted access to ü Full competition • Competition details are published in the
information documentation eNotification phase
• Tutorials and user manuals are available for
educating suppliers on how to use the system
requirements • Every tool that is necessary for the good
functioning of the system can be downloaded
û Multilingualism support • System supports only French and English
û Localisation parameterisation • Localisation of the GUI is not supported
Confidential nature of ü User profiles • All users need to use their credentials in order
data to be authenticated

• User profiles define what data each user has

access to
Restrict access to tenders ü Locking of supplier tenders • Tenders are locked when uploaded
ü Encryption when tenders are • Tenders are encrypted when uploaded
stored
Four eyes principle û Two officials to open tenders • Tenders are unlocked automatically when the
tender opening time is reached
• Only the president of the awarding committee
can decrypt tenders
Authentication ü Authentication of tenderers • Through the use of digital certificates
Call for Tenders û Tenders compliant with call • Tenders do not always conform to the call for
specifications for tenders specification tenders specifications, as they are free-text
documents
ü Data encryption • Supported
ü Digital Signatures • Supported
system logs
ü Detection of tampering • No mechanism to detect infringements
attempts
Time-stamping ü Official time • Enabled
Table 20: DPSM coverage of the new legislative framework on eProcurement
4.1.2.2 Description of DPSM system functionality

The DPSM portal contains notices published by the MINDEF, covering all levels of publication
(European, national, regional, or local). The portal operates as a complement to BOAMP
(Bulletin Officiel des Annonces de Marchés Publics), the official publications mechanism for
France. European notices are also published on the OJEU and TED.
The following types of notices are published in the ixarm portal:

• Invitation To Tender (ITT): contains the characteristics of the contract (type, schedule,
work packaging, special conditions, etc.) and of the contract award procedure (person
responsible for the contract-PRM, awarding authority, point of contact for additional
information, etc.). Publication is mandatory above €90K.
• Non-Official Notices: When it is not required from the MINDEF to publish an ITT (i.e.
below the threshold of €90K), a Non-Official Notice is published. These notices are
equivalent to ITT for the non-formalised and negotiated procedures.
• Prior Information Notices (PIN): in accordance with the New Code for the Public
Procurement (NCMP), a PIN must be published to the S supplement of OJEU for
contracts above the threshold of €750K (tax not included) for supply of goods and €5M
for services. Their purpose is to inform companies as early as possible with the essential
characteristics of the contract: the PRM, the awarding authority, the type of procedure,
forecast key dates, service characteristics, cost forecasts, possible work packages and
similar information.
• Contract Award Notices: when the award procedure comes to an end, a notice on the
outcome of the competition is published. An Award Notice is published when the
contract is awarded to a supplier. A “Non-Award” Notice is published if no action is
taken and the procedure is declared adjourned, by decision of the PRM.
The following table gives an overview of the DPSM system’s functionality, by presenting the
different activities performed by users (actors) of the system, during the classic procedure.


Creation of call Procurement • Call documentation created offline, using a form filling tool (it will
documentation Officer soon be interconnected with the eProcurement platform)
• The procurement officer uploads the documentation onto the portal
the same day it is published on the OJEU
Notification System • Notification is performed with the use of email
• Suppliers are also informed for tender invitations through their
personalised home page
Registration Supplier • Suppliers must be companies registered in a European country
• Registration does not require any complicated information from the
supplier, no costs involved
• After validation and approval of candidate suppliers details, user
credentials are forwarded to them
• Suppliers are obliged to acquire a digital signature, (software or
hardware) 1
Browsing Questions Supplier • Suppliers can post their questions by email
and Answers / Posting • Suppliers can see every answer provided by the procurement agency
Questions concerning a call, as it is sent by email to all candidates that
downloaded call documentation
Answering Questions Procurement • Answer supplier questions by an email sent to the person who posted
Officer the question, as well as, all the other tenderers who have downloaded
the associated call documentation
Updating call Procurement • Modifications of call documentation are uploaded onto the portal,
documentation Officer under the appropriate call documentation area
• All participating suppliers are automatically notified via email
Tender submission Supplier • Tenders are prepared offline and then uploaded onto the system
• Before their uploading, tenders have to be signed digitally
• Tender documentation is composed of two documents (candidature
with administrative information and offer), both signed by tenderers
• For volume capacity considerations, suppliers first submit the digital
signing on the documents and later the documents themselves. The
timeframe between the two actions is 24 hours2
• Automated emails are sent to suppliers, confirming the receipt of
their tenders
• When a tender is uploaded onto the system, it is locked, time-
stamped, and encrypted
Updating tender Supplier • Tender documentation can be updated by suppliers any time before
documentation the tender submission deadline
• Previous versions of the tender documentation are kept for reasons of
proof in a case of dispute
Collection of tender Procurement • Can see the number of tenders that have been uploaded into the
documentation Officer system
• Must accept tenders first and then download them locally
Closing of tender Procurement • Receive an email when eTendering deadline is reached
submission period Officer • Downloading locally all non-downloaded tenders
• Close the tender submission period manually
• Any offers received after the deadline are considered non-valid, as
their time-stamp refers to a later date
Tender opening President of • Tenders are unlocked
awarding • Obtain decryption keys after authentication to the system (one key-
committee set for decrypting candidature documents from all different suppliers
1
In order to avoid making the use of digital signatures a serious constraint in the use of the system, the DGA accepts
the same format to the ones utilised for the online tax declaration, which is compulsory in France. Potentially, this
forms a restriction for non-French suppliers.
2
The reason for this two-phased approach is because tenderers usually submit their bids just before the closing of the
eTendering phase, thus creating system overloading and increasing the risk for system failures. Therefore, the bidding
documentation, which is the most voluminous, can be sent after the closing deadline is passed.

committee set for decrypting candidature documents from all different suppliers
and a different key-set for the offer documents for each supplier)
• Decrypt and open all candidature documents. The awarding
committee will decide which tenderers qualify for submitting an
offer.
• Decrypt and open the offer documents of the tenderers that qualified
Table 21: DPSM functionality overview
4.1.3 JEPP – Federal Government Ministry of Defence (BELGIUM)

The Belgian Federal Government has created the Joint Electronic Public Procurement (JEPP)
platform, which forms a web-based parametric environment supporting the processes of the
eNotification phase. JEPP supports the creation of a portal hierarchy and is based on
Microsoft.NET technologies. Initially, the Belgian government portal has been created and hosted
on JEPP platform. This portal is administrated by the Bulletin of the Adjudications (BDA), a
federal entity responsible for the publication of RFPs for all national entities, as well as, for the
creation and maintenance of other portals to be hosted on JEPP system. BDA portal constitutes
the root structure of the portal hierarchy and all other portals are integrated with it.
Initial coordination process is on-going between Federal Government and the Wallonne Region
aiming at interconnecting the region's deployed eNotification system with the federal JEPP
system. A similar approach is under consideration with the Brussels Region. Currently, there are
two portals created within JEPP and integrated under BDA portal, one for the Belgian MoD and
another for all Pouvoirs Adjudicateurs du Niveau Fédéral under the FedICT’s umbrella . Different
approaches have been explored for the creation and hosting of the above two portals:
- MoD initially installed JEPP platform on its own infrastructure and the platforms were
maintained/hosted by MoD. To increase synergies with the other JEPP platforms, the MoD
decided to host this service together with the other SPF platforms
- FedICT outsourced the creation and maintenance/hosting of its portal to Unisys Consulting
- BDA outsourced the creation and maintenance/hosting of its portal to Unisys Consulting
Furthermore, smaller federal agencies are offered the opportunity to group together and use the
eProcurement facilities of the FedICT portal, for publishing their RFPs on an one-off basis.

The following table provides an overview of the most important features of the JEPP platform.

Functionality overview - Tools for online preparation and publication of call for tenders notices
- Publication of call for tenders notices and periodical schedules of
procurement needs
- Management of the terms of references and other related documents (e.g.
answers to particular questions received by fax or email)
Exploitation model - Hosted service
- Contracting authorities: two models:
o Hosted Application Service Provider (ASP):
- Portal hosted by Unisys Consulting’s facilities and infrastructure
- Based on an annual subscription and maintenance fee
- Fees may be related to the utilisation of the system resources
provided by the hosting authority
- For small administrations p ublishing very few tenders per year, the
possibility of paying per publication could be offered
- This model was chosen by the FedICT
o Self-supporting ASP:
- Portal hosted under the contracting authority’s own facilities and
infrastructure
- Administrations are responsible for hardware and software costs,
the licensing and maintenance of the application
- This model was chosen and explored by the MoD
- Suppliers:
o No cost
Actors - Procurement officer (UA): accredited users
- Supplier (NUA): not accredited users
- Local management cell (CP): responsible for the management of local users
- System management cell (CPP): responsible for the management of every
possible federal contracting authority
- Statistical users: responsible for eNotification statistics
Technology used - Microsoft .NET technology utilised
- XML could be used as the communication interface between the BDA portal
and the different public sector portals (ministries, regi onal, and municipal
governments)
- JEPP portals uses mainly Microsoft Windows 2000 and Microsoft SQL
Server 2000
Security policy - Authentication is performed through the use of user credentials (username
and password)
- A central user authentication module associates users with roles and

access/privilege rights
- Only authorised users can gain access to restricted system resources , based
on their role/access rights
Means of - Exchange of information between the different portals and the common
communication portal is achieved using SQL synchronisation mechanism
- Email is the primary communication mean between the system and the
suppliers (building on Extended SMTP protocol)
- XML on ESMTP will be the main data exchange mean between OJEU,
BDA and the JEPP system.
- All users have access to a notification engine, for retrieving existing or new
opportunities, either within a single portal or across all portals. This could be
done through web-browsing or through tailored e-mail notification with
appropriate URL links
Document treatment - System supports mainly two document standards: Microsoft Office Suite
and PDF
- Call documentation is published in the two official languages of Belgium
- Support s CPV and NUTS (Nomenclature des Unités Territoriales
Statistiques)

Interface with external - Interface with external legacy systems utilising the built-in XML integration
systems capabilities
- MoD portal is studying the integration of the ILIAS back-office system
(Integrated Logistic and Information Automated System) with JEPP system
Advanced search - It supports search based on the type of publication, CPV code, NUTS code,
capabilities and on free text
Multilingualism and - Current version supports Dutch, French, English, and German
localisation - Multilingual aspects for supporting all European languages are incorporated
- Customisation of the logo of each administration is possible
Table 22: JEPP platfor m overview
4.1.3.1 JEPP state-of-the-art features assessment

The following table presents an assessment of JEPP features against the state-of-the-art, as

eNotification support üDocumentation preparation • Tool for preparing call documentation
online
ü Contract Notification • Suppliers can download published call
documentation
û Integration to OJEU • Automated publication to OJEU (ongoing)
eTendering support ü Request to participate • Through email provided by supplier for
downloading tender documentation
û Short listing of tenderers
û Invitation to tender
û Tender submission
û Updating of tenders
û Locking of tenders
eAwarding support û Tender opening • Not currently supported
û Tender evaluation
û eAuctions
û Contract Award
û Award Notification
Back Office support ü Pre-defined reports • Pre-defined reports for a competition
ü Monitoring of logs • Create reports using system logs
ü Statistical analysis • Performed through statistical user profile
information û Questions & Answers • Answers provided within call supported
documentation
Pan-European standards ü International Coding • Use of CPV and NUTS standards
üDocument standards • MS Office and PDF formats currently used
Unrestricted access to ü Full competition documentation • Competition details are included in the
information published notices
requirements
ü Multilingualism support • System is in Dutch, French, English and
German
• Support for all European languages

û Localisation parameterisation • Only customisation of logo

• Parameterisation is supported by the
system, but currently not used
• User profiles define what data each user has
access to
Res trict access to tenders N/A Locking of supplier tenders
N/A Encryption when tenders are
stored
Four eyes principle N/A Two officials to open tenders • eTendering phase not currently supported
Authentication N/A Authentication of tenderers
Call for Tenders N/A Tenders compliant with call
specifications for tenders specification
system logs
ûDetection of tampering attempts • Not fully supported
• Deployment of Firewalls, Proxies, IDS andr
AntiVirus applications
Table 23: JEPP coverage of the new legislative framework on eProcurement
4.1.3.2 Description of JEPP platform functionality

The following table summarises the functionality supported by JEPP system.

Creation of call for Procurement • Online preparation of call documentation using a form filling tool
tenders notice officer • Online forms compatible with the definition provided by OJEU
• Notices created in French and Dutch (Belgium’s official languages)
Terms of Reference & Procurement • Uploaded in the two official languages by authorised users
other call related officer • Documents uploaded in two formats DOC and PDF
documents
Publishing of a call for Local • Call documentation can be scheduled for publication by authorised
tenders notice management users using the scheduler tool
cell
Notification during call System • Supplier defines a set of multiple criteria (e.g. market activities and
publication preferences)
• An algorithm matches published business opportunities (i.e. calls)
with criteria pre-defined by suppliers
Browsing call for Supplier • Perform quick or advanced search on a specific JEPP portal or on all
tenders notices & available JEPP portals
Downloading terms of • For calls of tenders under the open procedure, documentation is
reference available to all users (public and registered). Provision of email
allows for the downloading of call documentation.
• For calls under the restricted procedure, a secret code is
communicated to participating suppliers, to be used for downloading
tender documentation
• System facilitates the use of notifications, in case of modifications
on call documentation
Updating call Procurement • Published notices and documentation is locked by the system
documentation officer • Call documentation can only be modified by authorised users only
by use of a corrective notice
• Suppliers that have selected the automated notification option are
notified by email

notified by email
Registration of Procurement • Performed by BDA’s CPP personnel
Procurement Agency officer
Supplier Registration & Supplier • Required information comprises login name, family name, company
User Preferences name, preferred market activities, and industrial preferences/
specialities
• User profile stored on common portal
Procurement Officer Procurement • Authorisation performed at the portal level, authentication is
Authentication & officer performed at the application level
Authorisation • Access to resources is granted based on user identity (access rights)
Supplier Authentication Supplier • Optional central authorisation and authentication performed at the
& Authorisation common portal (application level)
• Suppliers can access all JEPP portals freely and at no-cost
Table 24: JEPP functionality overview
4.1.4 EPSS – CORDIS (EUROPEAN UNION)

The EPSS (Electronic Proposal Submission System) is an eSubmission system developed to
support the preparation and submission of proposals for RTD and associated activities. The
development of the system was aimed to cover the needs of the 6th Framework Programme 2002-
2006, the research and technology development programme of the European Commission.
There is a wide the range of research areas, activities and themes that are addressed. Potential
“Proposers” can view FP6 calls for proposals and download all the relevant documentation in
order to prepare their proposal. Proposers can be individuals or legal entities such as companies,
consortia, and universities. The following table presents an overview of the main features of the
EPSS.


Functionality overview - Tool for online preparation and submission of a proposal
- Tool for offline preparation of a proposal
o No cost
- Suppliers:
o No cost
Actors - Coordinator:
o register for a specific call for proposals
o define the participants of the proposal
o edit electronic forms
o send usernames and passwords to partners
o upload files/annexes and submit proposal
- Partner: receive usernames and passwords for a specific call for proposals
from the coordinator, edit the forms and send their annexes to the coordinator
- System operator: responsible for creating calls for p roposals documentation
and publishing them on the CORDIS-FP6 website
Offline activities - System support s both online and offline activities. Offline or online
preparation of proposals and electronic or hard copy submission
- Part A contains high-level information, including company details, partners
involved and financial offer.
- Part B is the technical proposal, including documentation and annexes to
fully define the offer of the partners
- EPT (Electronic Proposal Tool) allows the coordinator to define Part A and
Part B of a proposal and validate the complete package before uploading
Security policy - User authentication performed using credentials
- Credentials sent to users via the post. Only exceptionally and following a
request by the user, transmission is made via email.

- SSL is enabled
- Submitted proposals are locked by the system and remain inaccessible until
the proposal opening deadline
- Coordinator may resubmit a revised version using the same credentials, the
last version is regarded as valid
Means of - Automated email alerting mechanism
communication - Users specify areas of interest and receive emails notifying for published
calls for proposals
Document treatment - Two document type standards are accepted: Rich Text Format (RTF) and
PDF
- Supported by the majority of platforms, and are rarely related to virus attacks
Online help - Online help to complete proposals
- Complete user guide explains in detail the GUI of both the online and offline
functionality
Multilingualism - Website in English
- System support s multilingualism
- Uploaded documents, and Calls can be in any of the 11 official languages of
the EU
Interoperability - The web application is browser independent and the Offline Tool is platform
independent
Table 25: EPSS system overview

4.1.4.1 EPSS state-of-the-art features assessment

The following table presents an assessment of EPSS features against the state-of-the-art, as
while the lower part demonstrates overall technical qualities of the system. Although EPSS is not
an eProcurement system as such, the following table provides an overall view of the uniformity of
EPSS to the EU guidelines.

eNotification support ü Documentation preparation • Web forms for preparing a proposal online
• Offline tool for preparing a proposal
ü Contract Notification • Carried out via CORDIS web-site
ü Integration to OJEU • Via CORDIS
eTendering support ü Request to participate • Proposers can express their intention to
participate to a competition
û Short listing of tenderers • This process is performed offline
ü Invitation to tender • Achieved via email alerting mechanism
ü Tender submission • Online submission of proposals
ü Updating of tenders • Online updating of proposals
ü Locking of tenders • Submitted proposals are locked
eAwarding support û Tender opening
• This phase is not currently supported
û eAuctions
û Contract Award
ü Award Notification • Carried out via CORDIS web-site
Back Office support û Pre-defined reports • Not supported
û Monitoring of logs • Not supported
û Statistical analysis • Not supported
information ü Questions & Answers • Achieved through email
Pan-European standards û International Coding • Not supported
ü Document standards • RTF and PDF format currently accepted
Unrestricted access to ü Full competition documentation • Complete competition details are included
information in the published notices
requirements
ü Multilingualism support • System is in English
û Localisation parameterisation • Not supported
Restrict access to tenders ü Locking of supplier tenders • Submitted proposals are locked until call for
proposals deadline
û Encryption when tenders are • Not supported
stored
Four eyes principle û Two officials to open tenders • Not supported
Authentication üAuthentication of tenderers • User credential and specific code foe
participating to a call for proposals
Call for Tenders û Tenders compliant with call for • No automatic filtering of proposals
specifications tenders specification according to pre-defined criteria


system logs
û Detection of tampering attempts • No mechanism to detect infringements
Table 26: EPSS coverage of the new legislative framework on eProcurement
4.1.4.2 Description of EPSS system functionality

The following table provides an overview of the EPSS functionality by presenting the different
activities performed by its users (actors) during the classic procedure.

Notification of Coordinator • Send notification of intention to submit a proposal, either
intention to submit a electronically or on paper
proposal • Receive a unique reference number, to use for the proposal
Registration Coordinator • Proceed to registration procedure, in order to be able to participate to
each call
• Provide company details of coordinator and partners
• Receive credentials (login/password) sent by post or email/fax (if
requested)
• Password can be changed by the Coordinator after the first use.
Credentials can be used for the whole period of a specific call
Questions and Answers Coordinator/ • Suppliers can submit questions by e-mail
session Partner / • Operator responds by email
Operator
Proposal submission Coordinator • Offline submission: download call for proposals package (including
relevant documents), prepare offer using the EPT, upload proposal
• Online submission: complete offer online through web forms and
automatically submit proposal
Updating proposal Coordinator • After a proposal has been submitted, an automatic eligibility check is
documentation performed by the system, in order to validate whether all uploaded
documentation has been received correctly
• If the check is negative, coordinator is automatically informed via
the web page or email
• Proposal documentation can be updated at anytime before the
deadline of the call for proposals
Acknowledgement of System • Acknowledgement of receipt of a proposal is performed via a web
receipt page or email which informs the coordinator of the unique identifier
number of the proposal, the time of submission and a check sum
which guarantees the correct reception of the proposal package
Table 27: EPSS functionality overview

After the closure of a Call, all valid submitted proposals are transferred to the Commission’s
Evaluation Service Provider, where they are evaluated by EU experts.
4.1.5 SYSLOG Market – DG ADMIN (EUROPEAN UNION)

The Informatics Directorate (DI) of the Personnel and Administration DG (DG ADMIN) of the
European Commission is responsible for the management and co-ordination of Information
Technology and telecommunications services for the EC. The DI’s mission is to identify,
formulate and realise a modern and dynamic Information Technology vision and strategy for the
EC.

The DI has developed corporate information systems in order to support the administrative
processes of the EC. SYSLOG is a set of business applic ations comprising three main areas:
Training, Logistics and Credit Management. A part of the third area is the SYSLOG Market
module, which is dealing with the administration of Calls for tenders.
The system was set operational in October 2003. It was implemented by ADMIN-DI.4 PFD
(Information Systems Support: Planning, Financial management, Documents management) which
is also responsible for the technical support. The system is an intranet application and therefore
operating only inside the EC’s secure infrastructure. Tenderers may view Notices, Q&As
published on the DI’s website but they do not interact with the system online. The following table
presents an overview of the most important features of the system.

Functionality overview - Management and planning of tendering procedures
- Complete workflow from the creation of a business need definition, until the
call for tenders notification is published
- Cover procurement procedures for open, restricted and negotiated individual
contracts, as well as, framework contracts
o No cost
- Suppliers:
o No cost
Actors - Tenderer: can view call notices at the DI’s website and participate in calls for
tenders after being registered
- Technical administrator: can express a business need, which must be
supported with the relevant tender documentation
- Juridical officer: is responsible for the detailed planning of the procurement
procedures, primarily focusing on the organisation of the relations and
contacts with suppliers
- Juridical manager: responsible for the global planning of the procurement
procedures, mainly focusing on the identification of new needs and the
assignment of tasks to juridical officers
Technology used - Web-based application developed using ColdFusion
- Back-office environment based on Oracle database server
- Operates on both MS Windows and UNIX platforms
- DI currently recommends only Internet Explorer browser

Customisation - Customisation/modification of workflows according to internal DI
procedures
- Customisation of particular fields of the application in order to have a
different behaviour depending on the user profile
Security policy - System operates on the secure EU infrastructure
- Utilisation of LDAP authentication using database security to restrict user
access rights based on user roles
Advanced reporting - Complete monitoring facility offered to authorised DI personnel
mechanism - Dedicated Oracle tables used to log errors and system events
- Full audit trailing facility
- Statistical analysis of all competitions
- Automated alerting in case of system failures.
Document treatment - Document standards supported include MS Office documents, PDF, HTML
and XML
Table 28: S YSLOG Market system overview

4.1.5.1 SYSLOG Market state-of-the-art features assessment

The following table presents an assessment of SYSLOG Market features against the state-of-the-
art, as required by the new legislative framework, or identified during the analysis of the current
project. The upper part of the table presents all functional aspects in terms of the eProcurement
lifecycle, while the lower part demonstrates overall technical qualities of the system.

eNotification support ü Documentation preparation • Web forms for preparing a call online
• Offline tool for preparing call
documentation
ü Contract Notification • Suppliers can download published call
documentation from DG ADMIN’s website
ü Integration to OJEU • Automated publication to OJEU
eTendering support û Request to participate
û Short listing of tenderers
û Invitation to tender
û Tender submission
û Updating of tenders
û Locking of tenders • This phase is not currently supported
eAwarding support û Tender opening
û eAuctions
û Contract Award
ü Award Notification • Publication to OJEU
Back Office support ü Pre-defined reports • Pre-defined set of reports is available
• Users can create their own reports
ü Monitoring of logs • Monitoring of logs mechanism
ü Statistical analysis • Advanced statistical analysis functionality
Equal amount of û Automated notification • Achieved through email
information ü Questions & Answers • Q&As are published on DG ADMIN’s
website
• Corrigenda are also published online
Pan-European standards û International Coding • Not supported
ü Document standards • Tender documentation is in RTF and PDF
formats
Unrestricted access to ü Full competition documentation • Complete competition details are included
information in the published notices
requirements
ü Multilingualism support • System is in English
Restrict access to tenders N/A Locking of supplier tenders • eTendering phase is not currently supported
N/A Encryption when tenders are
stored
Four eyes principle N/A Two officials to open tenders • eAwarding phase is not currently supported
Authentication N/A Authentication of tenderers • eTendering phase is not currently supported
Call for Tenders N/A Tenders compliant with call
specifications for tenders specification


system logs
û Detection of tampering attempts • No mechanism to detect infringements.
Table 29: SYSLOG Market coverage of the new legislati ve framework on eProcurement
4.1.5.2 Description of SYSLOG Market system functionality

The following table provides an overview of the SYSLOG Market functionality by presenting the
different activities performed by its users (actors) during the classic procedure.

Publication of PIN Juridical • The first quarter of each year, two global PINs are published on the
Manager OJEU, one for goods and one for services
• PINs represent the FCLs3 global annual planning of needs
• PINs do not correspond to specific call notices
Expression of need Technical • Call specification is finalised by the technical unit in charge of the
Administrator procurement procedure
• A Technical Administrator is appointed responsible for the
following up of the eventual call for tenders
• Publish contract notice on the OJEU, and create a hyperlink to it at
DG ADMIN’s website
Approve a need Juridical • Create a procedure plan for the call for tenders of expressed need
Manager • Procurement has to be approved by the authorising officer of
ADMIN-DI-FCL representing the contracting authority
Request execution Juridical • Initiate procedure plan by requesting its execution
Manager
Edit action planning Juridical • Edit actions of procedure plan
Officer • In some cases it may be necessary to brake down initial plan to
more than one phases
Validate action Juridical • Validate procedure plan and attributes a Gamma Identifier (DI’s
planning Officer internal codification of contracts)
• Publishing contract notice to OJEU
Register for a Call for Tenderer • Download call documentation from DG ADMIN’s website
Tenders • It is recommended to register on-line in order to be able to submit
a tender for a specific call
Request clarifications Tenderer • Questions are submitted offline
Provide Answers Technical • Answers and corrigenda sent on paper via private courier to all
Administrator/ tenderers that have expressed interest and published on the website
Juridical
Officer
Complete GAMA Juridical • Follow up the execution of the planning and generate a Gamma
Report Officer report at the end for the Direction
Generate global reports Juridical • Generate reports for needs, actions by need, markets overview
Manager
Table 30: S YSLOG Market functionality overview

The remaining phases for the completion of the procurement procedure are executed outside of
the system. For completeness, the following list describes the activities performed for awarding
the contract:
3
ADMIN-DI-FCL (IT Finances, Contracts and Logistics) is the responsible body of the EC for the
procurement procedures related to Informatics and Telecommunications.

• Submit Tender: Tenderers submit their tenders to FCL via the post. Tenders are received at
the Central mail office of the EC in order to have the packages scanned for security reasons.
The Central mail office issues receipts to tenderers in case of delivery by hand as proof of
compliance with the deadline date for submission
• Open Tenders: Tenders are forwarded to the contract section of FCL, where they are locked
in a safe room, until the opening session of the specific procurement procedure
• Exclusion of Tenderers: The selection of tenderers is performed by both the Technical
Administrator in charge (technical capacity) and the Juridical Officer (financial and economic
capacity) and according to the competition pre-qualification criteria.
• Evaluation of Te nderers: The evaluation of the technical part of the proposal is assigned to
the Technical Administrator. The evaluation criteria are communicated in the notification of
the call for tenders. The technical administrator usually assigns weighting factors and a
minimum threshold for each criterion and/or on the technical evaluation criteria as a whole.
The financial evaluation is a responsibility of the Juridical Officer, who either evaluates on
the global cost of the offer over the whole duration of the contract, or on a pre-defined
scenario representing a significant part of the total cost. FCL mainly uses the “most
economically advantageous tender” method and applies a 50/50 quality/price ratio.
• Award Contract: The contract is awarded by the Juridical Manager. When the contract is
signed, a contract award notice is published on the OJEU. Furthermore, this contract award
notice is added on the DG ADMIN’s website in the “Closed calls for tenders” section.
4.1.6 eSourcing Service – Office of Government Commerce (UK)

The Office of Government Commerce (OGC) has recently published the contract notice for the
eSourcing project; a project in order to purchase a service which will support the procurement of
individual contracts for the UK public sector. The objective of the OGC is to establish a solution
which will be compliant with the new EU public procurement legislation, conform to the UK
laws and regulations for eProcurement and capable of satisfying the UK IT technology standards.
The OGC, like in the case of the eAuctions (section 4.3.1), is opting for an off-the-shelf IT
service, which will be configurable to meet the needs of each contracting authority, but offered
via a service provider who will also be responsible for the hosting and maintenance.
The eSourcing service is not currently operational; therefore this section only describes a number
of implementation decisions of OGC, which can provide some valuable input for the current
project. The following table presents an overview of the features the new system will have.


Functionality overview - Submission of tenders
- Q&A sessions
- Collaborative environment
- Tender evaluation
- Advanced online library tool for templates
Exploitation model - Expected to operate as a hosted service
o Annual fee expected to be between £20.000 and £100.000
o Select preferred functionality
o Major implementation options will include workflow customisation
- Suppliers:
o No cost
Actors - Various user types/roles will exist for contracting authorities personnel
Security policy - Use of username and password for user authentication
- Use of digital signatures is investigated at the moment
Means of - Changes to published documentation will be communicated through the use
communication of automated alerts
- Configurable automated email notifications
- Mobile Short Message Service (SMS) notifications

- Q&A sessions through the use of a bulletin board functionality
Document treatment - Compliant with IT standards of the UK government (eGIF guidelines and the
UKGOV XML)
- Support of the EU’s CPV standard
Interface with external - Integration to OJEU
systems - Integration to other UK publication sites
- Interface with the UK archiving system (under development)
Tender box - Creation of mechanism where tenders are locked until the tender opening
time
- At tender opening time, tenders will be automatically unlocked
- Support of the Four Eyes principle is investigated
Statistical analysis - Data management and analysis
- Historical data
- Full auditing mechanism for all operations
- Document version control
Table 31: eSourcing service overview
4.1.6.1 eSourcing Service state-of-the-art features assessment

As this service is not currently operational, the analysis for the current report did not assess its
current state-of-the-art features . According to the OGC, a lot of attention will be given on the
conformity of the system to the new EU public procurement legislation.

4.1.6.2 Description of the eSourcing Service functionality

The analysis of the functionality of the new service cannot be completed as the system is not
currently operational. Therefore this section only provide s a list of intended functionality to be
developed:
• tendering (i.e. support for all phases of Individual Contracts)
• online tender evaluation
• contract management
• collaborative environment (i.e. workflow for preparation of tender documentation)
• integration with OJEU
• Interface with the Purchase-to-Pay (repetitive purchasing system) via the contract
management solution and reception of data concerning the transactional activity
4.1.7 eContratacion eTendering–Department of Finance & Public Administration

(SPAIN/Basque)
The Department of Finance and Public Administration (DFPA) of the Basque country developed
their eProcurement system in the context of the eContratacion project which aims at the
modernisation of the public procurement procedures. The system is compliant with the Basque
and Spanish legislation for public procurement, while significant focus has been given in
conforming also to the new EU public procurement legislation. Furthermore, significant effort has
been devoted for guaranteeing security, using electronic signatures as described in the EU
directive 1999/93/EC.
The DFPA assigned the development and hosting of the system to EJIE (Basque Government
Information Society). The eTendering system is currently in the last testing phases and is planned
to be deployed into production in the next few months. The legal regulations for establishing the
system as the official electronic notification system of Basque Government have been approved
by the Bureau for the Basque Public Service Modernisation (DOMA). As, the system is not
currently operational, it is not fully analysed here, however the following table provides some
interesting aspects.


Functionality overview - Publication of call for tenders notices of governmental procurement needs
- Coverage of individual contracts for open, restricted and negotiated (with
or without advertisement) procurement procedures and framework
agreements
- Submission of tenders by suppliers
- Management of tendering procedure
Exploitation model - Contracting authorities :
o No cost
- Suppliers:
o No cost
Actors - Purchasing officer: manages the administrative process workflow,
publishes call notices
- Tenderer: submits tenders, tracks status, checks notifications in a provided
mailbox
Technology used - Web-based application developed using Java
- Back-office environment based on Oracle database server
- Application server is based on WebLogic
- OCSP (Online Certificate Status Protocol) is the communication protocol
with the certification authority server for signing and time-stamping
documents
Security policy - Strong authentication mechanism through the use of digital signatures
(supported by IZENPE the Basques Administrations Certification
authority)
Public Key - An electronic contracting board is set up previous to the publication of a

Infrastructure call for tenders
- Board member public keys are included in the publication, as well as the
minimum number of members that have to take part at the opening of
tenders
- Tenderer electronically signs tender file which is fragmented in several
blocks (as many as board members). Each block is encoded with the
corresponding public key
- During the opening of tenders there is a verification of the date. Blocks are
distributed to the relevant board members. Each member decodes his own
block using his private key
- The tender file can be only reconstructed with the simultaneous use of
electronic signatures by the legal number of board members
Central registry of - All necessary legal administrative information (fiscal and juridical) about
suppliers registered companies is stored in a central repository which is
interconnected to several applications including the eTendering system
- Registered tenderers are not obliged to submit administrative information
about their company when submitting a tender
Procurement - An independent application is acting as a file manager for procurement
Procedure and procedures and their related documentation
Documentation File - A future web-based application will allow suppliers to track online the
Manager status of their tenders
Table 32: e Contratacion eTendering system overview
4.1.7.1 eContratacion eTenderi ng state-of-the-art features assessment

current state-of-the-art features. According to the system specifications the eContratacion
eTendering system will be fully compliant with new EU public procurement legislation.

4.1.7.2 Description of eContratacion eTendering system functionality

The analysis of the functionality provided by eContratacion eTendering was not fully analysed as
the system is not currently operational. However the following list provides a general view of the
intended functionality:
• Preparation and publication of call for tenders notices

• Fragmentation and encryption of tenders by suppliers
• Submission of tenders
• Decryption, reconstruction and opening of tenders by the awarding board
• Management of procurement procedures and relevant documentation
• Classification of enterprises
• Registration of supplier administrative details
• Electronic signatures of contracts
• Virtual assistance to Procurement Board
• On-line publication of notifications
• On-line tracking of proposals status
4.1.8 ehandel eSourcing – Government Administration Services (NORWAY)

The Governme nt Administration Services (GAS) of Norway, with the assistance of its service
provider, is currently finalising the parameterisations of the new eSourcing functionality to be
provided as part of the eMarketplace ehandel.no (ehandel) services. This new functionality will
support both the creation of individual contracts and repetitive purchasing such as eAuctions,
framework agreements and DPS. The system is sought to be compliant with the new EU public
procurement legislation and the forthcoming national legislation. In this section, the ehandel
eSourcing functionality is analysed for the procurement of individual contracts.
The ehandel eSourcing system is based on the Negotiations software of Emptoris, which is
parameterised according to the GAS requirements, based on the national and EU procurement
legislation. The software is purchased by IBX, who will offer it as an additional service to users
of the ehandel. The system is not currently operational and therefore is not fully analysed in this
report, however the following table provides some interesting aspects of the system.


Functionality overview - Configuration of procurement procedures
- Collaborative environment
Exploitation model - Expected to operate as a hosted service provided by the GAS service provider
o Annual fee (subject to final decision)
o Fees based on usage (subject to final decision)
- Suppliers:
o No fees for basic use of the service (subject to final decision)
Actors - Various types (roles) of system users will be available
Parameterisation of - A competition is defined as a “Project”. Project coordinator configures the
procurement project by adding “tasks” in order to complete the procurement lifecycle
Interesting system
procedures - Tasks include: RFx, Submission, Evaluation, eAuctions and Contracting

characteristics
- Tasks are also configurable (actors, task details, document templates)

- Definition of Project templates which can have pre-defined tasks
- Open, restricted and negotiated procedure for procurement of ni dividual
contracts can be modelled this way
Security policy - Simple authentication mechanism through user credentials
- No use of digital signatures (supported by Emptoris software)
- Usage of PKI is under preparation (time-plan for implementation is subject to
final decision)
Table 33: ehandel eSourcing system overview

The Norwegian government has developed a centralised eNotification system as part of the
National Gazette services. The National Gazette is an eSender to OJEU sending almost all
Norwegian notices electronically. As an extension of the eNotification service provided by the
National Gazette, a national database for public procurements – DOFFIN – has been established,
which publish all public business opportunities in Norway above the national thresholds of
€25.000. The National Gazette system provides users with the possibility to create notices online
via document templates. Moreover the National Gazette eNotification system fulfils the
requirements of the Norwegian and EU public procurement legislation. The existence of the
National Gazette eNotification system prompted the Norwegian government not to develop this
functionality into the eSourcing system.
4.1.8.1 ehandel eSourcing state-of-the art features assessment

current state -of-the-art features.
4.1.8.2 Description of ehandel eSourcing s ystem functionality

The full analysis of the functionality provided by ehandel eSourcing cannot be completed as the
system is not currently operational. However the following list provides a general view of the
intended supported functionality:
• Preparation of awarding criteria
• Request for Information (pre-qualification)
• Request for Quotation/Proposal
• Submission of tenders
• Automated opening of tender
• eAuctions (section 4.3.4)
• Tender evaluation
• Contracting
• Collaborative environment

4.2 Repetitive Purchasing Systems

This category includes all systems that support the repetitive purchasing of specific contracts
within Framework Agreements or Dynamic Purchasing Systems (DPS), commonly implemented
as electronic catalogues, as defined in the new EU public procurement legislation. According to
these procurement methods, contracts can take the form of electronic catalogues that conform to
standards of the contracting authority and include the categorisation of goods and services
according to an international coding scheme (like CPV or UN/SPSC), as well as, the technical
implementation usually utilising the flexible advantages of XML.
In order for a contracting authority to set up a Framework Agreement, a competition must be

carried out first utilising the open, restricted or negotiated procedure for the procurement of
individual contracts. After the awarding phase the contracting authority can include in the
Framework Agreement the selected suppliers. A DPS on the other hand can be established by a
contracting authority with the publication of contract notice, specifying details of the specific
contracts to be created within the DPS, and also specifying the qualification criteria.
Electronic catalogues are not simplified electronic versions of paper based catalogues. Instead,
eCatalogues may offer various benefits, taking advantage of their electronic nature. Therefore,
multilingualism, multi-currency, pictorial descriptions, Internet links to products/services details,
advanced search facilities and interoperability capabilities for maintenance can be foreseen. In
particular for interoperability, an eCatalogue system can assist suppliers to create and maintain
their catalogues with minimal effort, potentially through the integration with their websites,
ERP/back office systems, or other supplier sources.
The following table considers all functional features to be supported by a Repetitive Purchasing
system according to the new EU public procurement legislation. It is assumed that the pre-
selection of suppliers to be included in the system can be done through a system that supports the
procurement of individual contracts. The first column presents the main phases of eProcurement,
as well as, the primary principles as deduced from the legislation. The next column lists the
necessary functionality of each phase or principle. The last column describes in more detail the
corresponding functionality.
This table is used in the subsequent sections of the reviewed repetitive purchasing systems, for
comparing their supported functionality against state-of-the-art features for such systems, as
concluded by the analysis of the public procurement legislative framework. The first two columns
of these tables are uniform, while the third column explains how each reviewed system addresses
the considered functionalit y.


eOrdering support ? eCatalogues • Online maintenance of electronic supplier
catalogues
? Request for Quotation (RFQ) • Ability to request for an RFQ from a
number of suppliers
? Place order • Advanced searching of eCatalogues and
placement of orders
? Approval Path • Workflow for online order approval
? Order fulfilment • Reception of goods/services
eInvoicing / ePayment ? Order invoice • Online creation of invoices or integration
support with supplier billing system
? Order payment • Online secure payment execution
Back Office support ? Accounting • Integration with legacy financial system
? Pre-defined reports • Reporting capability
Legislative pri nciples Required Functional Details System Implementation Details
hierarchical coding systems (CPV,
UN/SPSC, NUTS, etc.)
? No software/hardware • No cost-related software/hardware
requirements prerequisites to access system
? Localisation parameterisation • GUI parameterisation (currency, date/time
format, units of measure, etc.)
? Integration to other systems • Interfaces with legacy systems (buyer,
supplier, 3rd party)
Confidential nature of ? User profiles • Restricted access to data according to user
data profile
Security ? Usage of SSL • Minimum security level for data
transmission
Audit Trail / Traceability ? All user actions recorded in • Automated storage of all system event
system logs details
? Detection of tampering attempts • Mechanism for monitoring infiltration
attempts
Time-stamping ? Official time • Integration to 3rd party authority for official
guarantee
Table 34: Features that establish the uniformity of a Repetitive Purchasing System with the new
legislative framework on eProcurement
4.2.1 PECOS – Scottish Executive (UK/Scotland)

PECOS is an eCatalogues and workflow management system offered by the Scottish Executive.
PECOS is used by contracting authorities for purchasing goods and services from suppliers that
are in framework agreement with the Scottish public sector. It is an off-the-shelf system which
provides several methods for uploading and maintaining data in the system.
The following table provides a general overview of the most interesting aspects of the PECOS
system.


Functionality overview - Purchasing from supplier catalogues
- Definition of several procurement procedures (different approval paths)
- “Punch-out” data from supplier website
- Update supplier catalogues
- Advanced audit trailing and reporting mechanisms
Exploitation model - Hosted service (same model as DTC)
- Contracting authorities
o Subscribed contracting authorities to the ePS Programme have access
to both PECOS and DTC
o Optional advanced integration (charged) services with supplier systems
including warehousing and financial applications
Actors - Buyer: responsible for
o Placing orders and following purchasing approval paths until an order
is sent to the supplier
o Updating the system when products or services are received
o Approving and uploading supplier catalogues
- Definition of unlimited number of buyer user types, with customisable
privileges which can ensure confidentiality of sensitive information
Technology used - PECOS is an “out-of-the-box” system, utilising cXML eCatalogues
- Support s product names, descriptions, images and prices per supplier
- Products are classified according to the UN/SPSC hierarchical categorisation
model and can by searched in a variety of ways
Customisation of - Purchasing of customised products and services through the use of online
services Web Forms
- Customisable commodities like catering services, or business cards, can
easily be ordered through the system
Reporting mechanism - Reports on purchasing history, usage, performance, order status, etc.
- Reports can be generated per cost centre, supplier, product, etc.

- Statistical analysis and generation of graphs
- Full audit trailing facility, recording all performed actions in text -based files
Use of GPC - Government procurement cards (GPC) define the upper limit of allowed
purchases for each public sector employee, similar to a common credit card
- System allows the ordering, automated approval and payment of goods and
services
Interface with external - Integration with ERP systems
systems - Support for outbound and inbound EDI (Electronic Data Interchange
standard), FAX, email and XML
Advanced search - Quick search through free-text fields
capabilities - Searching of synonyms
- Automated spell-checking facilities
- Advanced parameterised searching on specific fields
- Users can review the complete eCatalogue of a supplier through a “tree
explorer view”
Alerting mechanism - Users are notified through an internal message box or “inbox”
- When connected, users are presented with their pending tasks
(review/approval of a non-approved order, update catalogues, accept/reject
delivered goods or services)
- Email is used as the outbound communication medium
Table 35: PECOS system overview
4.2.1.1 PECOS state-of-the-art features assessment

The following table presents an assessment of PECOS features against the state-of-the-art, as


eOrdering support ü eCatalogues • Maintenance of eCatalogues is performed
online
û Request for Quotation (RFQ) • Not supported
ü Place order • Advanced searching of eCatalogues and
possibility of placing orders
ü Approval Path • Approval of an order following online
workflow
ü Order fulfilment • Reception of goods/services online
eInvoicing / ePayment ü Order invoice • Online creation of invoices and integration
support with supplier financial system
ü Order payment • Online payment execution through GPCs
Back Office support ü Accounting • Integration with billing system
ü Pre-defined reports • Advanced reporting mechanism
û Monitoring of logs • No automatic creation of reports from
stored system logs
ü Statistical analysis • Advanced reports for statistical analysis
Pan-European standards ü International Coding • Products are classified according to the
UN/SPSC hierarchical categorisation model
Interoperability ü System accessibility • Web-based application
requirements
û Multilingualism support • Not supported
ü Integration to other systems • Use of XML, cXML, EDI and capability to
integrate with ERP and other systems
û Data encryption • Stored data is not encrypted
• For procurement of specific commodities
/services where personal information is
required, transmitted data is encrypted
system logs
Table 36: PECOS coverage of the new legislati ve framework on eProcurement
4.2.1.2 Description of PECOS system functionality

Overall, the PECOS system supports the functionality of an advanced eCommerce shop, with the
additional element of user profile s and workflow execution for the approval of orders. The
following table describes the functionality provided by PECOS in more detail. The first column
lists the different activities listed in a logic sequence, the second column is the actor (in this case
it is always the buyer) and the third column provides a description of the activity.


Model a procurement Buyer • Define approval paths
procedure • Approval process at contracting authority level (i.e. all purchases
need to be reviewed/approved by the same individuals)
• Approval process at commodity level (i.e. the purchasing of IT-
related goods and services requires approval from an IT resource,
while the purchasing of stationary requires approval from the
Financial department)
Upload new Buyer • Review and approve eCatalaogue (check compliance with the terms
eCatalogues and conditions of the corresponding framework agreement)
• Use eCatalogues tool to convert incorrectly formatted catalogues to
XML or XLS format
• Compare old and new prices of products and services of a supplier
Integrate to supplier Buyer • Apply “punch-out” (“pull”) mechanism b y connecting to supplier
Website Website, selecting products and automatically transferring relevant
data to PECOS
• Follow normal approval process in order to place an order
Table 37: PECOS functionality overview
4.2.2 Lotto 2 – Consip (ITALY)

Lotto 2 is the eCatalogue s system of the Italian government, facilitating the purchasing (below
threshold) of goods and services. The system is open to all suppliers, including those that do not
have framework agreements with the Italian public sector. The system is available to all Italian
public sector organisations. Buyers are provided with the functionality to purchase goods and
services directly from suppliers, or issue a Request for Quotation (RFQ) first.
The system is maintained by Consip, who are responsible for attracting buyers and suppliers in
using the system, as well as, uploading supplier catalogues onto the system. Supplier catalogues
can be updated at any time, although manual intervention from Consip is necessary.
The following table presents an overview of the main aspects of the Lotto 2 system.
- Issuing RFQs
- Suppliers update theirs catalogues online, modify prices and perform
catalogue’s lines deletion
- Full audit trailing
o No cost
o Free training
- Suppliers:
o No cost
o Upload eCatalogues for free
Actors - Standard User: responsible for browsing through supplier catalogues,
comparing commodities, adding commodities to a shopping cart and placing
orders and prepare RFQ Draft s which require approval
- Super User: can perform direct purchasing, place RFQs and approve pending
orders
- Administrator: responsible for uploading catalogues, reviewing logs ,
performing general maintenance of the database records
- Supplier: upload catalogues and update, modify a catalogue’s lines

Technology used - Based on the Oracle Exchange software modified to some extend in order to
comply with the Italian public procurement legislation (DPR 101 Act of
2002)
- Oracle Database is utilised for the back-end
- Oracle Portal is used for the front-end software
Security policy - Limited use of digital signatures by suppliers outside the system in order to
prepare their catalogues

- Orders are digitally signed before sent to suppliers by email
- Signed documents are also available in the Document Management System
that is linked to Oracle Exchange)
Uploading and updating - Catalogue templates for all types of products in MS Excel format including
of eCatalogues technical and economic attributes
- Suppliers complete their eCatalogues and send via email to Consip
- Validation by Consip administrator and conversion into XML format (for
uploading on the system) and PDF (for sending confirmation to supplier)
- Maintenance/updating of catalogues is performed in a similar process
- Single catalogue entries can be changed online
Version control - Document Management service used for safe-storage of supplier catalogues
- Version control allows for the storage of current and previous versions of a
supplier eCatalogue, useful for conflict resolutions
Audit trailing / - Recording of all system activities in logs
reporting mechanism - Generate standard reports
- “Supplier Intelligent Reporting” facility generates customised reports
Table 38: Lotto 2 system overview
4.2.2.1 Lotto 2 state-of-the -art features assessment

The following table presents an assessment of Lotto 2 features against the state-of-the-art, as

eOrdering support ü eCatalogues • The maintenance of supplier eCatalaogues
is performed manually
ü Request for Quotation (RFQ) • Buyers can issue RFQs online
online placement of orders
ü Approval Path • Workflows for online approval of placed
orders
û Order fulfilment • Not supported online
eInvoicing / ePayment û Order invoice • Not supported online
support û Order payment • Not supported online
Back Office support û Accounting • No integration with billing system
û Monitoring of logs • No analysis of system logs
ü Statistical analysis • Advanced reports for statistical analysis
Pan-European standards ü International Coding • Supports CPV coding
Interoperability û System accessibility • Web based application
• Suppliers must acquire software digital
signatures
û No software/hardware • Suppliers must acquire software digital
requirements signatures
û Integration to other systems • Currently not supported


ü Digital Signatures • Supplier eCatalogues are digitally signed
before entering the system
system logs
Time-stamping ü Official time • Use of official time from 3rd party authority
Table 39: Lotto 2 coverage of the new legislative framework on eProcurement
4.2.2.2 Description of Lotto 2 system functionality

The functionality of Lotto 2 can be separated into two main operations: purchasing from an
eCatalogue and issuing an RFQ. The following table presents the list of activities involved in both
operations along with the actors and a detailed description of each activity.

Search eCatalogues Standard • Search by keywords, favourite items
User / • Perform a complete catalogue search in a tree-exploring manner
Super User
Compare Products Standard • Select two or more products from the same or different suppliers and
User / compare them
Super User • System presents all attribut es of the selected products in a form of a
table
Place an order Standard • Place one or more products into the shopping cart and define the
User / necessary quantity
Super User • System automatically checks whether the actor is a Standard
(approval steps need to be followed) or Super user (the order is
directly send to the corresponding supplier via email after being
digitally signed)
Approve an order Super User • If an order is placed by a Standard User, a Super User is required to
approve the purchase
• Once approved, the order is automatically sent to the corresponding
supplier via email (needs to be digitally signed first)
Define RFQ Standard • Name of the RFQ, whether the RFQ will be visible to the public or
User / not, the ranking criteria, etc.
Super User
Invoicing/Delivery Standard • Specify invoice and delivery addresses, delivery details, relevant
Details User / notes
Super User • Upload any relevant attachments
Definition of attributes Standard • Defined attributes cover both technical characteristics of the desired
User / product and financial offer itself
Super User
Invitation of suppliers Standard • Participation invitation must be sent to at least 5 suppliers
User / • Select from suppliers that are defined in the system, or invite
Super User suppliers to register in the system before participating
Execution definition Standard • Define start and end date of the RFQ and delivery date
User /
Super User
Submit Super User • Confirm details and submit
• All relevant emails are sent to suppliers for their notification
Table 40: Lotto 2 functionality overview

4.2.3 DOIP/DOIPEI – Agency of Government Management (DENMARK)

In Denmark there are two governmental organisations responsible for promoting and developing
eProcurement in the country. The National Procurement Ltd (focused in developing the methods
for procuring Classic Procedures) and the Agency of Government Management (AGM) focused
in developing the methods for repetitive purchases. In their scope for eProcurement, AGM have
developed the DOIP/D OIPEI system, an application intended to assist both buying and supplying
entities in efficiently conducting their eProcurement business through advanced integration
capabilities to their existing systems. DOIP/DOIPEI is used by governmental bodies and
suppliers that are in framework agreement.
The DOIP/DOIPEI system was developed primarily for resolving issues with regards to the
bureaucracy of public sector purchasing, as well as, automating ordering, invoicing and payment
of government supplies. The benefits of the current system are not realised only by the buyers
(i.e. the public sector), but also the suppliers, as a wide range of integration capabilities is
provided for straight-through processing of the placed orders. The following table presents the
most important aspects of the DOIP/DOIPEI system.
It is interesting to mention that other MS governments have also identified the benefits of a
generic transactional system, like the BTS of Denmark. The UK government for instance, in
March 2004 launched a Prior Information Notice for the realisation of the Zanzibar project; a
project which is intended to create a platform similar to BTS, with the ability to allow for the easy
integration of several systems. The new eProcurement system of the UK public sector will be
based on OSS technologies and will utilise the recently established UKGOV XML schema,
however the high-level functionality will be similar to the Danish BTS service.

Functionality overview - Automated uploading of catalogues
- Purchasing from supplier catalogues
- Issue of invoices
- Online payment
- Integration with external systems
- Customisable procurement procedures (approval paths)
- Updat ing of supplier catalogues
- Full audit trailing
o Joining fee of €1.200 includes access to eCatalogues, ePurchasing,
eInvoicing and eAuctions
o Annual maintenance fee of €150 per user
o Advanced integration functionality with supplier systems (financial,
ERP, HR, etc.) require additional costs
o Fees paid per transaction
- Suppliers:
o Fees paid per transaction
- Fees include support/consultancy services by AGM’s technology provider
Actors - Buy er: workflows (approval paths) and personnel hierarchy of contracting
authorities and application of different user roles with different access rights
- Supplier: upload and maintain eCatalogues, issue invoices
Technology used - DOIP is based on the Oracle Exchange
characteri
Interestin
g system
- DOIPEI extension is based on the Officient eProcurement System and Open

Source technologies
- Business Transaction Service (BTS) is based on the MS BizTalk Server
- Back-office database uses MS SQL Server

Security policy - Private network infrastructure linking all government institutions

- Secure integration of DOIP/DOIPEI with the governmental financial system
and other public sector applications
- Suppliers can connect to the system through Virtual Private Networks (VPN)
- Disaster Recovery (DR) plan, in order to handle significant failures of the
system, featuring the main hosting environment and data replication to a “hot
standby” data centre
- Use of (software-based) digital signatures for performing significant
activities (e.g. place or approve an order)
Business Transaction - Identified issues involved in interconnecting multiple systems without a pre-
Service (BTS) agreed standard of communication led to the creation of BTS
- BTS can perform
o Data format conversion from one format to another (including HTML,
XML, EDI, plain text, spreadsheet, etc.) using the OIOXML UBL 0.7
standard
o Data routing, receiving data in a number of ways (including FTP,
HTTP, HTTPS, SMTP, etc.) and distributing it according to message
header. Transaction queues ensure the guaranteed delivery of the
transmitted data
- BTS transaction hub is a module that satisfies most of the interoperability
objectives of the EU public procurement legislation
Modular approach of - Suppliers can select one or more modules from eAuctions, eCatalogues
system development eInvoicing
- More advanced features include:
o Invoice scanning service: issuing invoices
o Invoice service: automating matching of orders to invoices
o Complete integration: automated eCatalogue uploading and
transactional capabilities
Multilingualism / - Support of multiple languages
localisation - Can support multiple currencies and units of measurement of products
- Utilisation of the UN/SPSC hierarchical codification
Offline activities - Suppliers can submit their catalogues in paper format . AGM upload them
into the system
- Invoices can be sent through the Danish Post Office in order to be converted
to electronic format
Table 41: DOIP/DOIPEI system overview
4.2.3.1 DOIP/DOIPEI state-of-the-art features assessment

The following table presents an assessment of DOIP/DOIP EI features against the state-of-the-art,
as required by the new legislative framework, or identified during the analysis of the current

eOrdering support ü eCatalogues • Uploading and online maintenance of
supplier eCatalogues
ü Request for Quotation (RFQ) • Buyers can issue RFQs online
placement of orders
ü Approval Path • Workflows for online approval paths of
placed orders
ü Order fulfilment • Online storage of acceptance of received
goods/services
support with supplier legacy systems
ü Order payment • Online payment of executed orders
Back Office support ü Accounting • Integration with billing system


ü Monitoring of logs • Audit trailing mechanism and analysis of
system logs
ü Statistical analysis • Statistical analysis from reports
Interoperability ü System accessibility • Web-based application (ASP)
• Use of software digital signatures for
critical system actions only (outbound
documents)
û No software/hardware • Users must acquire software digital
requirements certificates
ü Multilingualism support • Currently supports in Danish, Swedish,
English and German.
ü Localisation parameterisation • Currency, units of measure configuration
ü Integration to other systems • Multiple integration solutions and use of
BTS transaction hub module for integration
with external public systems
û Data encryption • Not Supported
ü Digital Signatures • Use of digital signature for significant
activities (e.g. placement, approval of an
order)
system logs
ü Detection of tampering attempts • User accounts are deactivated for 10
minutes after 3 consecutive failed login
attempts
• Intrusion Detection Systems
Time-stamping ü Official time • Guarantee of official time from 3rd party
authority
Table 42: DOIP/DOIPEI coverage of the new legislati ve framework on eProcurement
4.2.3.2 Description of DOIP/DOIPEI system functionality

The DOIP/DOIPEI system is offering the possibility of customis ing workflows and user profiles.
Depending on a contracting administration’s exact needs , the functionality of the system can
vary. However, the high-level functionality supported by the system allows for the full
automation of the purchasing process. This obviously depends on the integration level of a
supplier. The following table presents the high level functionality features of DOIP/DOIPEI.


Upload and maintain Supplier • Automated updating of eCatalogues when there is a modification in
eCatalogues the supplier’s system through direct links
Send order Buyer • Electronic transmission of order information to supplier system
Create invoice Supplier • Creation of invoices in suppliers system (FakturaService.net) or
online and transmission to buyer’s billing system
Execute payment Buyer • Online execution of a payment after confirmation of goods/services
acceptance
Compare orders, Buyer • Automatic matching of orders and invoices, immediately
invoices, payments highlighting inconsistencies between a placed order and a non-
matching invoice
Break down of orders Buyer • Break an order to more than one sub-order (when more than one
suppliers are required)
• Match multiple invoices to orders, allowing for the partial fulfilment
of purchasing orders
Table 43: DOIP/DOIPEI functionality overview
4.2.4 ehandel eOrdering – Government Administration Services (NORWAY)

The Government Administration Service (GAS) of Norway has followed a similar approach to
the Danish AGM, focus ing on the repetitive purchases from suppliers through framework
agreements. However, as analysed in section 3.5 and in contrast to most of the other reviewed
countries, the Norwegian administration had to face the additional complication of implementing
a system which could deal with the decentralised procurement policy of Norway.
GAS realised the ehandel eOrdering system, which can integrate to supplier and buyer systems
and through its customisable workflows can support the internal recurring purchasing processes
of the public sector. The following table presents the most important aspects of eHandel
eOrdering.

Functionality overview - Online maintenance of eCatalogues
- Purchasing from supplier catalogues
- Definition of customisable user roles
- Issuing of invoices
- Online payments
- Integration with buyer and supplier legacy systems
- Customise procurement procedures (approval paths)
- Full audit trailing functionality and stat istical analysis
- Participating organisation (contracting authority or supplier):
o Joining fee
o Subscription fees based on
- Usage: number of users using the system (size of the organisation)
- Annual volume of transaction:
- For example 250 users and volume of transaction
(purchasing/selling) of €20m will be subject to an annual fee of
about €20.000
o Entities grouped into four categories (smaller, lesser, medium and
large ). Connection fees vary from no-cost to about €46.000
Actors - Buy er: default roles for a buyer include:
o Requisitioner: responsible for searching through eCatalogues, selecting
goods/services to be purchased, creating orders. Orders must follow
internal approval paths before being authorised and submitted to
supplier
o Approver: responsible for reviewing, modifying appropriately and
approving/disapproving orders
approving/disapproving orders
o Procurement Manager: responsible for maintaining eCatalogues
o System Administrator: responsible for maintaining contracting
authority’s data (users, user roles, workflows, etc.)
- Supplier: default roles for a supplier include:
o Order Approver: responsible for receiving and approving/disapproving
an order placed by a contracting authority
o Invoice Sender: responsible for processing received orders, generating
and submitting electronic invoices
o System Administrator: responsible for maintaining supplier data in the
system (users, user roles, workflows, etc.)
Technology used - Based on CommerceOne, SAP and Poet technologies
- Configuration and development according to an implementation model,
developed by PWC, GAS and IBX, of process, technology, supplier
activation and change management
- Interconnections with other systems achieved by employing xCBL 3.0
- Open Catalogue Interface from SAP is utilised
Quality assurance - IBX performs a catalogue quality check on behalf of the buyers at least twice
a year
- Review details of all supplier catalogues in terms of product categorisation,
use of images, product name, product description and product attributes
- Assist suppliers to better demonstrate their products (badly described
products are identified and can be improved)
Integration with other - Interconnection between buyer and supplier financial systems
systems - Interface with supplementary applications (e.g. supplier warehousing

systems, supply chain management systems , etc.)
- Fully documented APIs
Flexibility in approval - Pre-defined approval paths for specific users, business units, product types,
paths definition price thresholds, etc.
- User can review approval path and add reviewers/approvers
- User can specify a time limit for selected approvers to approve an order.
Upon expiration of time limit, the system automatically transfers the approval
task to the superior of the selected approver, escalating the task for resolution
- Reviewers/approvers are notified of a pending order and can modify, approve
or disapprove it
Use of charge cards - Charge cards are not in common use in the Norwegian public sector as a
main method for payment of goods and services. However, if requested by an
individual public sector entity, Procurement Cards (PC) can be supported. In
that case:
o Public sector employees can place orders using a PC
o According to the configuration, an approval process might still be
required for products purchased through a PC
Audit trailing - All user activities are recorded in securely stored system logs
mechanism / statistical - System log files are “append only”
analysis - A log processing and reporting tool can analyse system logs and generate
reports on historical user activity
- A statistical analyser permits for the analysis of historical data in the system
(details and rates of the procurement spending)
Table 44: ehandel eOrdering system overview
4.2.4.1 ehandel eOrdering state-of-the -art features assessment

The following table presents an assessment of ehandel eOrdering features against the state-of-the-


eOrdering support ü eCatalogues • Online maintenance of supplier eCatalogues
ü Request for Quotation (RFQ) • Will be supported from June 2004
placement of orders online
ü Approval Path • Configure user roles
• Workflows for online approval paths of
placed orders
• Workflows can be modified real-time
ü Order fulfilment • Online storage of acceptance of received
goods/services
support with supplier legacy systems
ü Order payment • Online payment of executed orders through
integration with buyer legacy systems
Back Office support ü Accounting • Integration with buyer billing system
ü Monitoring of logs • Audit trailing mechanism and analysis of
system logs
ü Statistical analysis • Advanced reports used for statistical
analysis
ü No software/hardware • Only a PC with internet connection is
requirements needed
ü Multilingualism support • Support for any language
ü Integration to other systems • Integration with buyer and supplier legacy
systems
• A project using PKI for authentication of
users will be completed in June 2004.
system logs
other than virus check and recording of
unauthorized attempts to login
Table 45: ehandel eOrdering coverage of the new legislative framework on eProcurement
4.2.4.2 Description of ehandel eOrdering system functionality

This section provides an analysis of the main functionality of the eHandel eOrdering system. The
following table lists the main activities as performed by the corresponding actor, as well as a
description of each activity.


Search products Requisitioner • Search through available eCatalogues, identify commodities to
/ Approver purchase
• A search can be done by free text or in a tree-exploring manner
Shopping cart Requisitioner • Identified products/services are added into a shopping cart
/ Approver • Specify required quantity, provide notes regarding the exact
requirements
• A shopping cart can be automatically populated by user pre-defined
templates (i.e. usual commodities purchased by a user)
Placing the order Requisitioner • Specify delivery address, payment method (can include purchasing
/ Approver using a GPC)
• Before submitting order, review approval path and add approvers if
required
Approving an order Approver • Notified by email or view personal homepage in the system
• Approve order and escalate to the next person in the approval chain
• Can check order status at any point
Submission of an order System • Approved orders are automatically submitted to the identified
suppliers
• A notification is send via email and also appears at the supplier’s
homepage in the system
Order Acceptance Order • Review transmitted order and accept/reject it
Approver • If approved, the order is passed to the Invoice Sender, otherwise an
order rejection notification may be sent
Electronic Invoice Invoice • Prepare invoice and send it electronically
Sender • System match invoice to initial order and inform relevant users
Table 46: ehandel eOrdering functionality overvi e w

The aforementioned supplier functionality is available for the so called “integrated suppliers”.
However, ehandel eOrdering also allows for “hosted suppliers”. The hosted suppliers do not have
a real time connection to the system. The orders placed by contracting authorities are stored in the
system and suppliers are required to access ehandel eOrdering in order to see them.
4.2.5 DPSM eCatalogues – Ministry of Defence (FRANCE)

The eProcurement portals of the DPSM of the French MINDEF, ixarm.com and
achats.defense.gouv.fr, offer an eCatalogues module for the purchasing of goods and services
from suppliers that are in framework agreement with the MINDEF. A framework agreement is
valid for 3 to 5 years normally and contains specific products or services. Currently, about 50
electronic catalogues are available, but they concern small procurement areas and few orders are
placed online. The service is hosted by the MINDEF’s technology provider Answork. The
available eCatalogues can be Answork’s public catalogues or MINDEF’s specific private
catalogues.

The following table presents the most important aspects of the MINDEF eCatalogues system.

- Approval workflows
- Issue invoices
- Match order with invoice details
- Update supplier catalogues
- Full audit trailing functionality and statistical analysis
o No cost
Actors - Buy er: possibility of defining several user roles, responsible for updating,
approving and uploading supplier eCatalogues
Technology used - Based on CommerceOne software developed and adapted for the needs of the
MINDEF by Answork
- A link at the DPSM eCatalogues home page directs to Answork website
where the dedicated space for the MINDEF’s eCatalogues resides
- Back-office database is a dedicated Microsoft SQL Server called EBO
MINDEF (Enterprise Buying Organisation) containing information about the
organisational structure of MINDEF, the catalogue data and the transactional
data (purchase requests, purchase orders, history of transactions etc.)
Security policy - Purchase orders are time-stamped.

- It is impossible to create purchase orders manually. Purchase orders are
created automatically after validation of a purchase request
- Authentication to the system is done through the use of user credentials
Notification mechanism - Users are informed about pending tasks (validation of an order, modification
of a eCatalogue, review of an order sent to another officer for approval) when
connecting to their homepage on the system
International - Use of XML eCatalogues in the norm xCbl CommerceOne containing
codification standards product attributes (product name, description, product image, price etc)
- UN/SPSC is used as the codification system of all catalogues
- Nato code is also used in the private eCatalogues of the EBO
- MINDEF has also its own classification of products which will be
incorporated in the system
Reporting mechanism / - Reports concerning purchasing orders, purchasing requests, deliveries,
statistical analysis product categories, suppliers’ classification, etc.
- Statistical analysis and generation of graphs
- Administrators may monitor user actions
Advanced search - Quick search based on a free-text field
mechanism - Advanced search by setting several criteria
- Browse complete eCatalogue in a tree-exploring manner
Table 47: DPSM eCatalogues system overview

The next phase of further development of the eCatalogue module is its interconnection with
external systems, especially supplier ERP systems, which will enable users to have their
eCatalogues automatically updated.
4.2.5.1 DPSM eCatalogues state-of-the-art features assessment

The following table presents an assessment of DPSM eCatalogues features against the state-of-
the-art, as required by the new legislative framework, or identified during the analysis of the
current project. The upper part of the table presents all functional aspects in terms of the
eProcurement lifecycle, while the lower part demonstrates overall technical qualities of the
system.


eOrdering support ü eCatalogues • Online maintenance of supplier eCatalogues
û Request for Quotation (RFQ) • Not supported
placement of orders online
ü Approval Path • Workflows for online approval paths
ü Order fulfilment • Online acceptance of received
goods/services
eInvoicing / ePayment ü Order invoice • Online creation of invoices
support û Order payment • Not supported
Back Office support û Accounting • Currently no integration with billing system
û Monitoring of logs • No further analysis of system logs
ü Statistical analysis • Advanced reports used for statistical
analysis
• Nato code is used
ü No software/hardware • Only a PC with internet connection is
requirements needed
ü Multilingualism support • Support for any language
û Integration to other systems • Partial integration with supplier back-office
systems for issuing invoices
system logs
Table 48: DPSM eCatalogues coverage of the new legislative framework on eProcurement
4.2.5.2 Description of DPSM eCatalogues system functionality

This section provides a presentation of the DPSM eCatalogues functionality. The following table
shows the activities performed by the actors (in this case the buyer is considered as the actor)
along with a description for each activity.


Generate purchase Buyer • Browse private or public eCatalogues
request • Quoted prices in public eCatalogues are not modifiable
• Submit purchase request for validation by the appropriate authority
• Track an order in real-time
Create purchase order Buyer • Approve/reject request, create purchase order and submit it to
supplier
Update eCatalogue System • Suppliers submit their eCatalogues in XLS format
administrator • Answork super-administrator is responsible for uploading public
eCatalogues
• MINDEF private eCatalogues must be approved before a MINDEF
administrator uploads them
• The format of eCatalogues is CUP (Commerce One similar to MS
Access)
Execute purchase order Supplier • Suppliers have also access to the service using the SupplyOrder
module. This module allows the management of the supplier’s
private space. Suppliers can view and proceed to the execution of
purchasing orders destined to them
Table 49: DPSM eCatalogues functionality overview
4.3 eAuctions systems

This section includes all systems which support the eAuction functionality, as described in the
new EU public procurement legislation. According to the legislation, the eAuction is a new step
of the eAwarding phase, where selected tenders are given the opportunity to participate in an
electronic auction event.
The award of a contract can be based either on the best economic value, or on the Most
Advantageous Economic Tender (MEAT), which can be concluded by a number of evaluation
factors. The evaluation criteria which will be used in an eAuction, as well as, the fact that an
eAuction event may take place during the eAwarding phase of the procurement are all elements
that need to be included in the notification of the contract. The EU public procurement legislation
also allows the contracting authorities not to award the contract to the winner of the eAuction,
providing clear and specific justification.
The following table presents state-of-the-art for eAuction systems, derived from requirements of
new EU public procurement legislation and their further analysis. These are used in the
subsequent sections, for analysing the reviewed EU eAuctions systems. The upper part of the
table contains functionalit y concerning the eProcurement lifecycle. The lower part contains
functionality concerning legal aspects.


eNotification support ? Tenderers invitation • Automated notification to qualified
tenderers
? Definition of parameters • Definition of the procedure, criteria and
evaluation function
eTendering support ? Bid preparation • Online preparation of bids
? Bid submission • Online submission of bids
eAwarding support ? Bid evaluation and ranking • Automated evaluation and ranking using the
evaluation function
Back Office support ? Pre-defined reports • Reporting capability
Equal amount of ? Automated notification • Automated user alerting of important events
information ? Questions & Answers • Online execution of Q&A sessions
hierarchical coding systems (CPV,
UN/SPSC, NUTS, etc.)
? Document standards • Standard document file formats
Unrestricted access to ? Full competition documentation • Publication of details of the full
information procurement process
? No software/hardware • No cost-related software/hardware
requirements prerequisites to access system
? Localisation parameterisation • GUI parameterisation (currency, date/time
format, units of measure, etc.)
Confidential nature of ? User profiles • Restricted access to data according to user
data profile
? Classification notification • Restricted publication of ranking
information (i.e. not divulgation of bidders’
identities)
Restrict access to tenders ? Locking of supplier bids • Locking of bids, in case of not-instant bid
evaluation and ranking
? Encryption when bids are stored • Secure storage of submitted bids
Four eyes principle ? Two officials to open bids • Opening of bids by at least two physical
persons, in case of not -instant bid
evaluation and ranking
Authentication ? Authentication of tenderers • Proof of user identity
Call for Tenders ? Bids compliant with call for • Acceptance of bids which conform to the
specifications tenders sp ecification call for tenders specification
Security ? Usage of SSL • Minimum security level for data
transmission
Audit Trail / Traceability ? All user actions recorded in • Automated storage of all system event
system logs details
? Detection of tampering attempts • Mechanism for monitoring infiltration
attempts
Time-stamping ? Official time • Integration to 3rd party authority for official
guarantee
Table 50: Features that establish the uniformity of an eAuction system with the new legislati ve
framework on eProcurement

4.3.1 eAuction services – Office of Government Commerce (UK)

The OGC has opted for the provision of five different eAuction service providers, offering a wide
range of potential functionality for the various contracting authorities. The OGC conducted the
procurement to put in place a framework to allow contracting authorities to use the services. Each
contracting authority that wishes to utilise the services establishes a contract with the provider.
The five eAuctions service providers that have been employed for this purpose comprise:
• Achilles
• British Telecom
• BravoSolution
• Trading Partners
• Wipro
Significant effort has been given to support functionality in accordance to the UK procurement
laws, as well as, the EU public procurement legislative framework. The following table provides
the main aspects of the UK eAuctions services.

Functionality overview - Submission of bids via online Web Forms
- Define eAuction space (type of event, bidding fields, evaluation function,
etc.)
- Automatic evaluation of bids and ranking of bidders in real-time
o Three “related” services for setting-up an eAuction competition:
- Market Sourcing: obtain in-depth information regarding specific
goods/services, define bidding fields for eAuctions, define
formula to be used for automated evaluation
- Marketing: utilise various means for notifying suppliers of the
planned auction event
- Training: train participants (contracting authorities personnel and
suppliers) on the functionality of the system
o Basic fee for organising an eAuction is between £3.000 and £7.000
depending on which “related” services are bought
o Possibility for bulk purchase of eAuctions for reducing costs
Actors - Procurement officer: responsible for the creation of the eAuction space,
definition of the evaluation criteria and format, answering to suppliers’
questions
- Supplier: responsible for placing bids, utilising online Web Forms
Technology used - The services are hosted by five different technology providers according to
OGC’s technical specifications and their SLAs
Security policy - Security based on SSL

- Bids are submitted via online Web Forms
- User authentication is performed through the use of user credentials
Awarding procedure - Automatic opening and immediate evaluation of bids allowing for real-time
sorting of all bids according to either lowest price or the most economically
advantageous tender (concluded based on more complex evaluation criteria)
Technical support - Operation of a helpdesk for both online and offline bidding
- In case of technical problems which prevent the placement of bids, the
helpdesk can place the bid instead of the supplier
- A different helpdesk operator is made available for each supplier
- Helpdesk operators under pre-specified procedures can pause, terminate
and/or cancel the bidding process
Table 51: UK eAuctions services system overview

4.3.1.1 UK eAuctions services state-of-the-art features assessment

The following table presents an assessment of UK eAuctions services features against the state -
of-the-art, as required by the new legislative framework, or identified during the analysis of the
current project. The upper part of the table presents all functional aspects in terms of the
eProcurement lifecycle, while the lower part demonstrates overall technical qualities of the
system.

eNotification support ü Tenderers invitation • Automated notification to qualified
tenderers via email
ü Definition of parameters • Definition of the bidding fields, bidding
procedure, criteria and evaluation function
eTendering support ü Bid preparation • Online preparation of bids via Web Forms
ü Bid submission • Online submission of bids
eAwarding support ü Bid evaluation and ranking • Automated evaluation of bids using the
evaluation function and immediate ranking
Back Office support ü Pre-defined reports • Service providers offer standard reports
• Buyers can also define their own reports
ü Monitoring of logs • Logs are fully audible and available to
authorised personnel
ü Statistical analysis • Buyers are assisted by service providers to
perform statistical analysis
Equal amount of ü Automated notification • Automated user alerting via email
information ü Questions & Answers • Online execution of Q&A sessions via
email
Pan-European standards ü International Coding • Product categorisation according to the
UN/SPSC international hierarchical coding
system
N/A Document standards • No files are transmitted as the bidding
process is performed via the utilisation of
Web Forms
Unrestricted access to ü Full competition documentation • Publication of full details of the eAuction
information process
Interoperability ü System accessibility • Web-based systems
ü No software/hardware • An PC with internet connection
requirements • Digital signatures are not utilised
ü Multilingualism support • Offered by some service providers
ü Localisation parameterisation • Offered by some service providers
Confidential nature of ü User profiles • Restricted access to data according to user
data profile
ü Classification notification • Selection of information to be visible by
bidders
Restrict access to tenders N/A Locking of supplier bids • Bids are automatically opened, evaluated
and ranked immediately after receipt
N/A Encryption when bids are • Bids are automatically opened, evaluated
stored and ranked immediately after receipt
Four eyes principle N/A Two officials to open bids • Bids are automatically opened, evaluated
and ranked immediately after receipt
Authentication ü Authentication of tenderers • User authentication using user credentials
Call for Tenders ü Bids compliant with call for • Acceptance of bids according to eAuction
specifications tenders specification event specifications

Audit Trail / Traceability ü All user actions recorded in • Automated storage of system events in logs
system logs
û Detection of tampering attempts • Not supported
Table 52: UK eAuctions services coverage of the new legislative framework on eProcurement
4.3.1.2 Description of UK eAuctions systems functionality

As the OGC offers five different service providers with varied functionality, this section
demonstrates high-level functionality , common for all services.

Definition of eAuction Buyer • Specify various parameters for defining the exact details of the
space auction event regarding the type and rules of the auction (i.e.
number of rounds or real-time, auctioning with time limits,
supporting documentation, etc.)
• Set up the way confidentiality will be preserved (i.e. what
information will buyers and suppliers be able to see during the
bidding phase)
Creation of bidding Buyer • Define fields to bid upon
fields • Group fields into offer types (economic offer and technical offer
fields)
• Create Web Form and relevant field validation rules to be used by
suppliers for placing a bid
Define evaluation Buyer • Define evaluation formula to be used for the automatic assessment
formula of bids
• OGC offers consultancy services to assist buyers in constructing the
most appropriate formula for achieving the best possible results
from the eAuction
Communication of Buyer • Communicate eAuction details (including evaluation formula) to all
eAuction details participating suppliers
• Question and Answers session is utilised to clarify all suppliers’
questions
eAuction event Supplier • Submit bids through online Web Forms
• Submit a question
• Contact helpdesk to report potential technical problems
Table 53: UK eAuctions functionality overview
4.3.2 Lotto 1 – Consip (ITALY)

Lotto 1 is an eAuctions system based on the Italian laws and regulations which mainly promote
the principles of flexibility and customisation. Unlike the new EU public procurement legislation,
the Italian legislation permits an eAuction to constitute a complete and stand-alone eProcurement
procedure. Therefore, Lotto 1 is used for procurement of Individual Contracts without a full
initial evaluation. The system is hosted by the Consip’s technology provider, IBM.
The following table presents the main aspects of the Lotto 1 eAuctions system.


- Define eAuction space (type of event, bidding fields, evaluation function etc.)
o No cost
- Suppliers:
o No cost
o Cost-free training on eAuctions events
Actors - Administrator: responsible for defining the eAuction space, according to the
contracting authority requirements, admitting/invit ing participating tenderers
- Supplier: responsible for submitting bids during the eAuction event
Technology used - Oracle Exchange
Security policy - User authentication utilising smart cards and digital signatures issued from an
Italian certificate authority

- Submission of bids does not require a digital signature but only a 5-digit
Personal Identification Number (PIN)
- At the closure of the eAuction, a PDF document with the winner bid details is
sent to the winner in order to be digitally signed, returned and stored
- Authentication of submitted bids is guaranteed by supplier’s digital signature
Evaluation function - Possibility to include unlimited number of parameters and weights
- Utilisation of Web Forms for the definition of eAuctions bidding fields
- Definition of call specifications according (acceptable minimum/maximum
numbers for each bidding field)
Supplier Intelligent - Obtaining information of previous eAuctions, generated savings, supplier
Reporting participation
- Currently no automated methods for analysing system logs, it can be
implemented
Table 54: Lotto 1 system overview
4.3.2.1 Lotto 1 state-of-the -art features assessment

The following table presents an assessment of Lotto 1 features against the state-of-the-art, as


tenderers via email
evaluation function
Back Office support ü Pre-defined reports • Capability of producing pre-define reports
ü Statistical analysis • Advanced reporting mechanism used for
statistical analysis
information û Questions & Answers • Not supported
UN/SPSC hierarchical coding system
Web Forms
information process
Interoperability û System accessibility • Web-based system
• Users must have smart cards with digital
signatures
û No software/hardware • Users must have smart cards with digital
requirements signatures and smart card reader
Confidential nature of ü User profiles • User profile based access to data
data ü Classification notification • Information to be visible by bidders
Restrict access to tenders ü Locking of supplier bids • Bids are locked when rec eived
• At the end of each auction round the system
performs automatic evaluation and ranking
û Encryption when bids are stored • Bids are not encrypted when received
• At the end of each auction round the system
performs automatic evaluation and ranking
• System will be upgraded to Oracle
Exchange 6.2.4 to support bid encryption
Four eyes principle û Two officials to open bids • Not supported
Authentication ü Authentication of tenderers • User authentication using digital signatures
and PINs
• System will be upgraded to Oracle
Exchange 6.2.4 to support bid encryption
ü Digital Signatures • Enabled
system logs
Time-stamping ü Official time • Guarantee of official time by 3rd party
authority
Table 55: Lotto 1 coverage of the new legislative framework on eProcurement

4.3.2.2 Description of Lotto 1 system functionality

This section provides an analysis of the basic system functionality. The following table presents a
list of activities with information about the actor and a more detailed description of the activity.

Creation of eAuction Buyer • Select type of auction, define parameters, (e.g. single or multiple
space rounds eAuction, conditions for closing a round, time period
between rounds, etc.)
Definition of bidding Buyer • Define bidding fields
fields • Define call specifications (i.e. validation rules of bidding fields for
maximum/minimum values)
Definition of the Buyer • Define evaluation formula for determining the ranking of bids
evaluation function • Two types of evaluation formulae supported:
o Economic Evaluation + Technical Evaluation
o Technical Evaluation / Economic Evaluation
• Economic and Technical Evaluations are defined using an unlimited
number of variables and weights
Invitation of suppliers Buyer • Select suppliers to be invited to the eAuction
Place bids Supplier • Submit a bid utilising online Web Forms
• Set the figures for all mandatory fields
Ranking of bids System • Automatically rank bids based on the evaluation function
• No manual intervention is allowed
Closing a round Buyer • A round is closed, either automatically by a pre-set deadline or by
manual intervention from the buyer if all participating suppliers
have successfully submitted their bids
Closing of the auction System • The auction event is automatically terminated when the number of
event pre-set rounds is reached
• No manual intervention is allowed
Table 56: Lotto 1 functionality overview
4.3.3 DOIP eAuction – Agency of Government Management (DENMARK)

The DOIP eAuction system is a module of the initial DOIP system, abiding to the rules and
regulations of the Danish legislation. The DOIP eAuction, as mentioned in section 3.2, is based
on the “out-of-the-box” Oracle Exchange product. Furthermore, it has similar functionality to the
Italian Lotto 1 system (section 4.3.2), which is also based on the same software package.
The following table presents the main aspects of the DOIP eAuctions system.


- Definition of eAuction space (type of event, bidding fields, evaluation
function etc.)
- Automatic evaluation and ranking of bids in real-time
- The exploitation model for the eAuction module is included on the overall
DOIP/DOIPEI exploitation model as discussed in section 4.2.3
Actors - Administrator: responsible for defining eAuctions spaces according to the
contracting authority’s requirements
- Supplier: responsible for the submission of bids during the eAuction
Technology used - gatetrade have sub-contracted the hosting of the system to a specialised
hosting organisation, which apart from their obligations as defined by the

AGM , accommodate also a Business Continuity Plan (BCP) through a “hot -
standby” data-centre
Security policy - User authentication is performed through the use of usernames and password
- On submission of a bid, the Supplier ID, User ID and time-stamp are stored
in the bid
Evaluation function - Support for advanced flexibilit y in the definition the evaluation function
- Support the use of Web Forms based on customisable bidding fields for the
submission of bids
Supplier Intelligent - Possibility to analyse competitions through the “Supplier Intelligent
Reporting Reporting” module of the Oracle Exchange Server
- Deduce information on previous auction events, savings generated by
eAuctions, participation figures, etc.
Table 57: DOIP eAuctions system overview
4.3.3.1 DOIP eAuctions state-of-the -art features assessment

The following table presents an assessment of DOIP eAuctions features against the state-of-the-


tenderers via email
evaluation function
ü Monitoring of logs • Available functionality
information ü Questions & Answers • All questions are handled and answers are
distributed online to all bidders
system
Web Forms
information process
ü No software/hardware • Users must have software digital signature
requirements
ü Multilingualism support • Currently operates in Danish, Swedish,
English and German languages .
ü Localisation parameterisation • Currency, units of measure configuration
data profile
bidders (including questions and answers)
Restrict access to tenders û Locking of supplier bids • Opening and evaluation of bids is
û Encryption when bids are stored performed automatically on receipt
Four eyes principle û Two officials to open bids • For “closed auction”, access to and the bids
evaluation is done at the auction closing
specifications tenders specification event specifications (i.e. pre-defined
validation criteria based on Web Forms)
ü Digital Signatures • Enabled
system logs
ü Detection of tampering attempts • User accounts are deactivated for 10
minutes after 3 consecutive failed login
attempts
• Intrusion Detection Systems
Time-stamping ü Official time • Guarantee of official time by 3rd party
authority
Table 58: DOIP eAuctions coverage of the new legislative framework on eProcurement

4.3.3.2 Description of DOIP eAuctions system functionality

The functionality presented in the section is very similar to the functionality of the Italian Lotto 1
system (section 4.3.2), as both systems are based on the same software package. The following
table presents a list of activities with information about the actor and a more detailed description
of the activity.

Creation of an auction Buyer • Select the type and define exact parameters of the eAuction (e.g.
event conditions for closing a round, time period between rounds, etc.)
Definition of bidding Buyer • Define bidding fields
fields • Define bidding fields specifications (i.e. validation rules on
minimum/maximum figures for each field)
Definition of the Buyer • Define precise evaluation formula for determining bid ranking
evaluation function according to the requirements of each eAuction
• Define technical and financial evaluation mechanisms utilising an
unlimited number of variables and weights
Invitation of suppliers Buyer • Select suppliers to be invited in the eAuction
Place bids Supplier • A bid is placed online, utilising online Web Forms
• Set figures of their offer for all mandatory fields and submit the bid
Ranking of bids System • Automatic ranking of bids based on the evaluation function
Closing of the auction System • Automatic termination of the eAuction
event
Table 59: DOIP eAuctions functionality overview
4.3.4 ehandel eAuctions – Government Administration Services (NORWAY)

As analysed in section 4.1.8, the ehandel eSourcing service supports the execution of electronic
auctions. The functionality of the eAuctions module is the “out-of-the-box” functionality of the
Emptoris eSourcing module.
The eAuctions module of the ehandel eSourcing service is not currently operational and therefore
is not fully analysed in this report. However, the following table provides some interesting
aspects of the module.


- Definition of eAuction space (type of event, bidding fields, evaluation
function, etc.)
Exploitation model - Exact exploitation model not currently finalised
- Some information regarding this model can be found in the exploitation
model of the main eSourcing service (section 4.1.8)
Actors - Buyer: responsible for the creation of eAuction spaces, definition of
evaluation criteria and format, answering to supplier questions. During the
eAuction, buyers can review statistics on the bidding history and pause or
cancel the event
- Supplier: responsible for the placing of bids utilising online Web Forms
Security policy - Access to system via the Internet using SSL encryption
- User authentication is performed using user credentials
Interesting system
- Usage of PKI based authentication, signatures etc. is under

characteristics
Multilingualism / - Possibility of defining multiple currencies and languages

localisation - Definition of data to be visible by users during eAuctions, the duration of the
event, rules for extension, etc.
Statistical analysis - Advanced statistical analysis can be performed in real-time
- Comparison of bids from different suppliers and identification of differences
- Comparison of historical bids of a supplier and identification of reactions to
bids from other suppliers
- Generation of exportable statistics and graphs
Table 60: ehandel eAuctions system overview
4.3.4.1 ehandel eAuctions state-of-the -art features assessment

current state -of-the-art features.
4.3.4.2 Description of ehandel eAuctions system functionality

Although the system is not fully operational yet the main functionality has been decided. The
following table presents a list of the most important user activities, the actors and the details of
each activity.


Creation of an auction Buyer • Select type of eAuction (Standard Reverse Auction Module or
Advanced Reverse Auction Module for multi-item procurement)
Definition of bidding Buyer • Define items to be procured: bidding fields and bidding field
fields specifications (minimum and maximum allowed values)
• Define non-mandatory bidding fields: assisting buyers to further
understand suppliers’ offer
Definition of the Buyer • Define evaluation formula
evaluation function • Bids are automatically ranked based either on lowest price or on
MEAT
Invitation of suppliers Buyer • Invite suppliers to take part in the eAuction
Place bids Supplier • Bids are placed online, utilising online Web Forms
• Set figures on all mandatory fields and submit bid
• A bid does not have to be placed for the complete business
opportunity. For competitions that include more than one “item
lines” (i.e. printers, cables and paper), a supplier can place a bid for
only one “item line”
Ranking of bids System • Bids are automatically ranked based on the evaluation formula,
including Best Total Offer (best offer for all “item lines”) and Best
Item Line (best offer for each “item line”)
Statistical Analysis Buyer • Perform statistical analysis in real-time
• Compare details of each bid in terms of bidding fields (i.e. quantity,
quality, cost, etc)
• Review bidding history and generate real-time graphs
Table 61: ehandel eAuctions functionality overview
4.3.5 DPSM eAuctio ns – Ministry of Defence (FRANCE)

The two French armament portals offer access to an eAuctions service where inverse auctions for
the defence sector can take place. The so-called “Reverse Auctions room” (SEI) is a service that
allows MINDEF procurement officers to conduct real-time electronic auctions with suppliers, in
accordance to the New Code for the Public Procurement (NCMP). The NCMP allows the use of
reverse auctioning for choosing a supplier for routine low-value purchases.
The service is hosted by the MINDEF’s technical provider Answork. Currently the system is
operational but not very utilised yet. A few “simulations” of eAuctions have been conducted by
certain purchasing entities of the MINDEF. The primary objective of these events is to train
MINDEF suppliers, as well as, validate the operation of the service. The following table presents
the most interesting features of the DPSM eAuctions service.


- Define eAuction space (type of event, bidding fields, evaluation function etc.)
o No cost
- Buying administrations:
o No cost
o Free training
Actors - Administrator: responsible for the complete management of the SEI
(attribution of user roles, configuration of SEI, system monitoring, etc.). This
role is assumed by Answork personnel
- Promoter: responsible for the configuration of eAuctions, selection of bidders
according to the procurement agency requirements, sending of messages to
participants and generation of reports
- Auctioneer: responsible for submitting bids during the eAuctions
Technology used - Based on CommerceOne software, developed and adapted for the needs of
the MINDEF
- Hosted by MINDEF’s technology provider Answork, a link at DPSM
eAuction home page redirects users to Answork’s website, where the

dedicated space for the MINDEF’s eAuctions resides
Security policy - User authentication is performed through the use of specific user credentials
for a particular eAuction
- No use of digital certficates
Evaluation function - Use of the “handicaps” mechanism for eAuctions with one criterion (price).
All other criteria are transformed into price “handicaps” before the start of
the eAuction
- Algebraic formula is used for multi-criteria eAuctions
Reporting mechanism - Generation of reports on past eAuctions, including information on
participation of auctioneers, history of bids, SEI categories, etc.
- Maintenance of logs for every user action
Multilingualism - Support of French, English, Portuguese, Italian, Spanish and German
language
- Other languages can be also added
Table 62: DPSM e Auctions system overview
4.3.5.1 DPSM eAuctions state-of-the-art features assessment

The following table presents an assessment of DPSM eAuctions features against the state-of-the-


tenderers via email
evaluation function
information ü Questions & Answers • Suppliers can post questions via screen
messages to buyer
• Buyer decides which information will be
available to suppliers
system
Web Forms
information process
• Users must have digital signature
ü No software/hardware • Users must have software digital signature
requirements
ü Multilingualism support • Not supported
data profile
bidders
Restrict access to tenders N/A Locking of supplier bids • No files are transmitted as the bidding
N/A Encryption when bids are process is performed via the utilisation of
stored Web Forms
Four eyes principle N/A Two officials to open bids
system logs
Table 63: DPSM eAuctions coverage of the new legislati ve framework on eProcurement

4.3.5.2 Description of DPSM eAuctions system functionality

This section provides an analysis of the functionality supported by the DPSM eAuctions service.
The following table presents a list of the most important user activities described by actor and
activity details.

Configuration of the Administrator • Set category and sub-category, currency to be used, number of
eAuction decimal digits to be shown, language, maximum period and the
maximum number of extensions to be allowed
• Define type of eAuctions (standard, multi-lot or multi-criteria)
Configure standard Promoter • Define starting price, desired quantity, bid price step (minimum
reverse auction price change) and reserved price (minimum bid price defined in
order to avoid very low biffing prices that can lead the auction to a
dead-end)
• Auctioneers are competing on price only and the lowest price is the
winner of the auction
• Decide which information will be communicated to the
participating auctioneers
• During the eAuction, each candidate can view the bids made by
other candidates, though their identity is not revealed
Configure multi-lot Promoter • Define lots by segregating global market of the eAuction
reverse auction • eAuction (mono or multi-criteria) lot phase will run for each lot of
the market
• Decide which auctioneers are able to participate in each lot phase
• Possibility to assign a phase for the global market
• Lot phases may run simultaneously or one after the other
• Auctioneer may decide to bid for the global market or for just a
particular lot
Configure multi- Promoter • Define criteria to be used and create bidding fields for the Web
criteria reverse auction Forms
• Define evaluation function
Table 64: DPSMeAuctions functionality overview
4.4 eProcurement supplementary systems

This section provides an overview of systems that although do not directly support any
procedures or phases of eProcurement, they can significantly assist contracting authorities and
suppliers in conducting eProcurement.
The growth of eProcurement and the benefits it can offer, heavily depend on how both public
administrations and suppliers are able to adapt to the new environment of public procurement.
The procedures that both types of organisations must exercise for utilising eProcurement are
somewhat different to their current procedures. Therefore education and training to eProcurement
procedures, change management, IT familiarisation and similar aspects may be considered by all
Member States.

4.4.1 Supplier Adoption Database – Scottish Executive (UK/Scotland)

One area that the Scottish Executive has focused is that of assisting suppliers throughout the
country to participate in electronic competitions. A significant hurdle in order for eProcurement
to become efficient and fair , is that of supplier participation in electronic procurement. Therefore,
assisting suppliers to utilise eProcurement solutions is of paramount importance.
Using eProcurement usually means that supplying organisations need to change their way they
conduct their business with the public sector, which in turn involves costs in restructuring internal
procedures, defining new roles and responsibilities to support the new procedures, as well as,
educate their personnel in the new procurement methods. Therefore, suppliers and particularly
SMEs, are sceptical in adopting eProcurement.
To overcome this hurdle, Scottish Executive has developed a methodology by which all public
sector administrations joining their eProcurement programme, are immediately responsible for
assisting their usual suppliers to understand the way they will be required from now on to conduct
business with the Scottish public sector. Contracting authorities are also responsible for assisting
suppliers to understand the considerable benefits from the use of eProcurement.
The methodology includes the following steps:

• Validation of suppliers: Each contracting authority selects eight suppliers, which best fit
their roll out plan. Then, the central ePS team in conjunction with the buyer focus on
executing the supplier adoption programme to these selected suppliers
• Communication: Scottish Executive contacts the selected suppliers through a “warm up
call” in order to arrange for a meeting. Furthermore, suppliers are provided with a briefing of
the concepts of electronic procurement, as well as, are given a “capability questionnaire” to
complete. Through these questionnaires, Scottish Executive can decide on the details which
will be presented to the supplier during their meeting (e.g. the next step in the Supplier
Adoption Programme)
• Conference: During this meeting, Scottish Executive and the buyer introduc e the supplier to
the ePS eProcurement systems, as well as, the new methods they will be conducting their
business in the future. Suppliers are requested to involve commercial/sales personnel,
IT/technical resources, as well as, decision makers who can understand the new procedures
and decide how eProcurement can best fit their organisation
• Channel: At another meeting between all parties, Scottish Executive and the buyer can
present to the supplier various organisational aspects they can adapt, following their analysis
from the previous step (e.g. the information they have been providing with during the
Conference step)
• Connect: During this phase, the technical integration implementation takes place, where the
supplier is provided access to the ePS eProcurement systems
• Post Implementation / Supplier Development: Scottish Executive and the contracting
authority assist the selected suppliers in resolving any post-implementation technical or other
issues. Furthermore, they can assist suppliers to further develop their implementation in order
to achieve the most out of the ePS systems

To assist the supplier adoption programme, Scottish Executive has furthermore developed a
simple but very informative Supplier Adoption Database, which allows at any time its users to
find out at which step of the adoption methodology a supplier is. Furthermore, users can find out
which public administration is responsible for introducing a supplier to eProcurement, which
ensures that a supplier will be approached and introduced to the Scottish systems only by one
administration rather than all administrations that conduct business with them. Therefore,
duplication of effort is eliminated.
The Supplier Adoption Database does not directly support any phases of eProcurement, however
it can assist administrations to make the Scottish eProcurement systems more appealing to
suppliers, helping them to use and benefit from electronic procurement. Furthermore, it can
provide a medium for Scottish Executive to evaluate how successful their provided services are,
as this database can easily demonstrate how many suppliers are using the Scottish systems against
the number of suppliers that have been through the adoption methodology.
4.4.2 eCatalogue Converter – Scottish Executive (UK/Scotland)

Another supplementary application used by the Scottish Executive, is the eCatalogues Converter,
which functions in a similar way to the “converter functionality” of the BTS transactional hub of
the Danish implementation (section 4.2.3). The PECOS system (section 4.2.1) is heavily based on
the use of electronic catalogues. Despite its advanced integration capabilities with a variety of
data sources for importing/generating supplier catalogues, the system still requires suppliers to
submit their catalogues in pre-defined formats. This can in turn translate to costs for suppliers
(especially SMEs that do not necessarily have in-house IT expertise). In order for no supplier to
be discriminated by being enforced to modify their applications in order to integrate to PECOS,
Scottish Executive realised the eCatalogue Converter.
The eCatalogue Converter, developed by Reqio, a sub-contractor of the CGEY, provides the
online ability to ePS systems to accept supplier ele ctronic catalogues in many formats and
automatically convert them to the format required by the PECOS application (or any other
format). Furthermore, this application is used as a “staging area”, where buyers can review the
products and prices of a new supplier catalogue against the old details, before accepting it in the
PECOS system. The purpose of the “staging area” is to ensure that only catalogues that are in
compliance with the framework agreements between the buyers and suppliers are uploaded in the
PECOS application. The eCatalogue Converter can accept catalogues in various formats,
including:
• eXtended Markup Language (XML)
• Microsoft Excel Spreadsheets (XLS)
• Electronic Data Interchange (EDI)
• Comma-separated values (CSV)
• HyperText Markup Language (HTML)
The import/export flexibility provided by the application can be utilised in future modifications of
the ePS systems, without necessitating changes to the suppliers systems. Furthermore, such
application can be further elaborated to an Open Source Software (OSS) tool, which can work as
an add-on to most eProcurement systems that support eCatalogues.

4.4.3 Eureka Search – Interchange of Data between Administrations (EU)

Eureka is a search engine operating in a web-based environment, suitable for Internet/Intranet
portals. The application is developed based on the mnoGoSearch search engine, an open source
software covered by the GNU General Public License. Eureka is one of the tools of the IDA
Common Tools set. It can be used with the Unix or Linux operating systems, however it is not
freely available for MS Windows platforms, as this software is offered on Windows only under a
commercial software licensing agreement.
Eureka was implemented by TRASYS, who aimed at offering a central point of reference for the
search of information in any of the EU’s Internet websites, irrespectively of the physical location
of this information. The application comprises three main parts:
• Indexer: The primary functionality of the Indexer is to recursively search through HTTP
servers, FTP servers, local files, etc. and capture all document information. Such information
can be keywords and document meta-data (i.e. information describing the document).
Following this operation, the Indexer stores the captured information in a database
• Search facility: This facility allows users to search all collected information from the Indexer
through an easy-to-use web interface. There are two types of search available: the simple
search, based on a simple string-based searches and the advanced search, incorporating
searches using multiple search criteria (i.e. keyword, date, etc.)
• Administration Interface: Through this interface the system administrator or content
manager can obtain statistics about the use of the application. Furthermore, the system
administrator can obtain access to the index storage database allowing for alterations in the
index configuration
The indexing priority is configurable. The priority that is assigned for certain attributes of a
document such as the body, title, description, keywords, etc. by the Indexer can be modified by
an authorised user (e.g. content manager). However basic authorisation must be applied for
indexing password protected areas (usually by the system administrator). Another important
feature of Eureka is the support of a wide range of character sets and languages. The character set
and the language of documents allows for 70 character set/language combinations. It also
includes 11 official languages of the EU, as well as, languages of candidate countries. The
supported META tags by default are “keywords” and “description”. However the application
allows users to define their own META tags (i.e. category, classification, etc.). There is a “Re-
entry capability”, meaning that more than one Indexer and searching processes can be executed at
the same time. This allows a big volume of data to be processed in a short time. The indexing
depth can be limited depending on the user’s needs and the volume of the indexed documents.
Finally, the application supports boolean queries and fuzzy search (search by different word
forms, synonyms, substrings).
Some of the most interesting technical features of Eureka are:

• Supports of single and multi-byte character sets including UTF8
• Support of HTTP/1.0, FTP and HTTP Proxy indexing, as well as, local file system indexing
• Support of different SQL databases for the backend including MySQL, Oracle, Sybase, MS
SQL, IBM DB2 and others
• Capability of implementing a distributed database environment using several machines
• Support of several types of document types including HTML, plain text files, PDF, XLS,
DOC and others

Eureka can be a useful tool for indexing eTendering systems which contain a lot of documents.
An efficient search facility is necessary for allowing users to have quick access to the interesting
information. Most of the current eTendering and eNotification systems provide a search based on
the title of the call, the date, the department and other high-level information. However, it is
important for suppliers to locate documents not only through searching the META data of a
document, but on its contents as well. Therefore, Eureka can be a very positive add-on to such
systems.

5 ANNEX A: Structured Communication

This section presents the document sent to all participating Member State administrations,
requesting system documentation about their eProcurement initiative. Furthermore, the
questionnaire utilised for obtaining the preliminary information from MS is presented in this
Annex.
System Documentation
• System architecture
• Functional and technical design of system components and modules
• Documentation on any open source and proprietary software used
• Supported hardware and software platforms
• Information on Security aspects
• Operational Guide and User Manual
• Online Access to the system.
Questionnaire
Section A: Contact Information
In the following, please provide contact information for the person responsible to complete this
questionnaire and contact for any adhoc queries.
A1. Name: ______________________________________________
A2. Position: ______________________________________________
A3. Organisation: ________________________________________
A4. E-Mail/Telephone/Fax: _________________________________
Section B: Organisation Information

In the following, please provide information about your organisation.
B1. Sector the organisation belongs to:
• Federal Government
• State Government
• County/ Municipal Authority
• Other, please specify: ____ ____________

B2. Type of goods that are procured in the system and provision of an indicative list of them:
• Products ________________________
• Services ________________________
• Works ________________________
• Other, please specify: _______________
B3. Contract types supported (please circle appropriately):

• Individual Contracts YES / NO
• Framework Agreement Contracts YES / NO
• Dynamic Purchasing System YES / NO
• eCatalogues YES / NO
• eAuctions YES / NO
B4. Procurement procedures supported:

• Open Procedure YES / NO
• Restricted Procedure YES / NO
• Negotiated Procedure YES / NO
B5. Further details about the organisation and the unit:

______________________________________________________________
______________________________________________________________
Section C: System Description

In the following, please describe in b rief the functionality supported by the system.
C1. System Identification
• System name ______________________________
• URL of operational system ______________________________
• URL for online information ______________________________

C2. Key Actors, Roles and Responsibilities

Please provide information on the key actors involved in your system (officers, agencies,
suppliers, committees, etc), clearly presenting their roles and responsibilities.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C3. Pre–Conditions
Please specify any conditions that need to be satisfied before procurement can commence.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C4. Notification
Please describe the workflow of your call notification process, including the actors involved and
the interactive procedure for Questions and Answers sessions. Furthermore, please mention other
online, publicly -accessible systems that notices are published.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C5. Tendering / Submission

Please describe the workflow of your tender reception process, including information on
administering materials received.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________

C6. Evaluation / Awarding

Please describe the workflow of your evaluation process and the procedures followed for the
qualification and ranking of the different bids. In this context, please specify the relevant
selection criteria and their corresponding weights, as well as, the ranking mechanisms involved
(lowest price, most economically advantageous tender, etc).
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C7. Invitation to Participate in Tendering

a) In case you are automating the restricted procurement procedure, please describe the workflow
followed for inviting suppliers to express their interest in participating to calls for tenders.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
b) Please, describe the workflow followed for the preliminary selection of candidates, providing
information on the selection criteria.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C8. Invitation to Negotiate in Tendering

In case you are automating the negotiated proc urement procedure, please describe the workflow
followed for inviting suppliers to participate in the negotiation process.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________

C9. Framework Agreements

In case you are automating the procurement procedure under framework agreement, please
describe all steps followed for awarding an individual contract within such framework.
______________________________________________________________
______________________________________________________________
______________________________________________________________
C10. Electronic Auctions
In case you are supporting the procurement procedure of electronic auctions, please describe all
steps followed for the submission and awarding of the procedure.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C11. Monitoring
Please describe the monitoring mechanisms used, providing information for internal reporting, as
well as, for reporting to the European Commission or other monitoring bodies. Please elaborate
on the content of such reports (e.g. information, history, statistics, etc).
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
C12. Legal framework

Please provide information on the legal framework according to which the system is operating.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________

C13. Additional information

Please feel free to provide any further relevant information concerning the procurement
procedures of the system.
______________________________________________________________
______________________________________________________________
______________________________________________________________
Section D: System Implementation

In the following, please provide information about the organisation that technically implemented
the eProcurement system and your feedback for its performance in accommodating your needs.
D1. System Operation
Please provide information on the date that the system was set operational and describe in brief
any major software releases that have taken place since then, the new functionality of each release
and their corresponding dates.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
D2. System Implementers
Please provide information on the organisation that technically implemented the system, clearly
presenting the organisation name and website, as well as, the number of employees involved in
the project (if known), the duration from the system conception to its realisation and any
deviations from the original plan in terms of time and/or costs.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
D3. Support services
Please provide information on the support services the implementing organisation is offering,
explaining in brief the response times to critical software defects and its capability to support
your eProcurement business.
______________________________________________________________
______________________________________________________________
______________________________________________________________
D4. Please provide any additional information you believe will be useful for evaluating the
implementer’s capacity to offer high standards of service to your organisation.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
Section E: Technical information

In the following, please provide some technical information about the system.
E1. Technologies used
Please describe the technologies used for the implementation of the system.
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
E2. Legacy Sys tems

Please describe the external dependencies of the system and any necessary interconnections with
legacy systems. For each of these systems, briefly describe the underlining technology in terms of
hardware, software and networking facilities supported (EC databases, Email system, Web site,
supplier and administrative databases, financial systems, etc).
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
E3. Standardisation
Please describe any eProcurement or technical standards used within your organisation (e.g.
Common Procurement Vocabulary, XML Schemas, etc). Furthermore, please elaborate on
capabilities of the system to support multiple languages, as well as, globalisation parameterisation
(i.e. currency, date/time format, etc.)
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
E4. Electronic Documents

Please provide information on the type of electronic documents used within your organisation for
supporting eProcurement procedures (MS Office, Postscript Documents (PDF), HTML, XML,
etc).
______________________________________________________________
______________________________________________________________
______________________________________________________________
E5. Software adaptability

Please provide information on the flexibility of the software to be adjusted to your organisation’s
needs, as redefined since its operation by users’ feedback.
______________________________________________________________
______________________________________________________________
______________________________________________________________
E6. Software stability

Please provide information on how often in the last 6 months the software changed and to what
degree, in order to support your procurement procedures and organisation hierarchy. Please
characterise all software changes by a Mission Critical, High, Intermediate or Low level. (Please
provide a separate document if there are many changes to be reported).
______________________________________________________________
______________________________________________________________
______________________________________________________________
E7. Software reliability

Please provide information on how often in the last 2 months there have been problems with the
application, causing inconveniences or complete system failures. Please characterise all software
reliability issues by a Mission Critical, High, Intermediate or Low level. (Please provide a
separate document if there are many changes to be reported).
______________________________________________________________
______________________________________________________________
______________________________________________________________
E8. Volume Capacity / Service Disruption

Please provide information on how the system handles capacity failures and in particular during
the submission of tenders. Furthermore, please explain the procedures followed in the occurrence
of service disruptions, focusing on the submission of tenders.
______________________________________________________________
______________________________________________________________
______________________________________________________________
E9. Costs
Please provide information on the necessary costs for the licensing and maintenance of the
software, as well as, hardware components of the system.
______________________________________________________________
______________________________________________________________
______________________________________________________________
Section F: Security
In the following, please provide information in terms of the security setup used in the production
environment of the system.
F1. Electronic Signature Devices
Please provide information concerning the use of electronic signature in the system.
______________________________________________________________
______________________________________________________________
______________________________________________________________
F2. Security Infrastructure

Please provide information on the use of any security technologies within your administration
(e.g. Firewall, SSL, Encryption, Digital Certificates, etc).
______________________________________________________________
______________________________________________________________
______________________________________________________________
F3. Virus detection / Document corruption

Please provide any information on mechanisms for virus detection during the submission of
tenders. Please elaborate on the procedures followed for virus infected or corrupted offers and in
particular their validity during the awarding phase.
______________________________________________________________
______________________________________________________________
______________________________________________________________
F4. Traceability / Logging of events

Please provide any information related to the mechanisms used for tracing events in the system
and in particular when a tender is being opened.
______________________________________________________________
______________________________________________________________
______________________________________________________________
F5. Economic Operator Security Prerequisites

Please explain any hardware/software components an economic operator must have and configure
appropriately, in order to view and/or participate in a call.
______________________________________________________________
______________________________________________________________
______________________________________________________________
F6. Additional Information

Please provide any information you think might be useful in order to appreciate the security
capability of the system.
______________________________________________________________
______________________________________________________________
Section G. Comparison to EU principles

Please provide information about the ability of the system to satisfy various legal requirements of
the new EU public procurement legislation (circle where appropriate).
G1. Equal Amount of Information: Tenderers receive an equal amount of information at the same
time.
YES / NO / PARTIALLY (if partially, please give details)
______________________________________________________________
______________________________________________________________
G2. Pan-European Standards: Authorities are required to use European standards in order not to
favour domestic suppliers.
______________________________________________________________
______________________________________________________________
G3. Unrestricted Access to Information: Participating companies must be furnished throughout

the process with precise information concerning the conduct of the entire procedure.
______________________________________________________________
______________________________________________________________
G4. Non-Discriminatory Electronic Communication: The tools to be used for communicating by

electronic means, as well as, their technical characteristics, must not result in a discrimination of
bidders. They must be generally available and interoperable, with the information and
communication technology products in general use.
______________________________________________________________
______________________________________________________________
G5. Interoperability: Use of electronic means that are interoperable (interchangeable) with
electronic means generally available on the market or generally used in other Member States,
without using country-specific or otherwise discriminatory technologies capable of restricting
economic operators' access to the tendering procedure.
______________________________________________________________
______________________________________________________________
G6. Confidential Nature of Data: Tenderers have the right to require a contracting authority to
respect the confidential nature of information which they make available
______________________________________________________________
______________________________________________________________
G7. Electronic Signatures: Tenders, requests to participate and the forwarding of plans and
projects must comply with national provisions adopted pursuant to directive 1999/93/EC;
______________________________________________________________
______________________________________________________________
G8. Restrict Access to Tenders: Contracting authoritie s must not be able to examine the content
of requests to participate and tenders before the deadline for their submission has expired. If that
access prohibition is infringed, then the electronic device for the receipt of tenders or requests to
participate should detect the infringement. Also, only authorised persons may set or change the
dates for opening the data received.
______________________________________________________________
______________________________________________________________
G9. Four-Eye Principle : During the different stages of the contract award procedure, access to all
data submitted must be possible only through simultaneous action by authorised persons.
Simultaneous action by authorised persons must give access to data transmitted only after the
defined date and the data received and opened in accordance with these requirements must remain
accessible only to persons authorised to acquaint themselves therewith.
YES / NO / P ARTIALLY (if partially, please give details)
______________________________________________________________
______________________________________________________________
G10. Authenticate Tenders: The requirement of ensuring the integrity of data entails the
obligation for contracting authorities and suppliers to sign all submitted documents of requests to
participate and tenders. This will provide the necessary authentication of the call, by validating
the sender and its contents. If document contents are changed at any time, then the electronic
device for the receipt of tenders or requests to participate should detect the infringement.
______________________________________________________________
______________________________________________________________
G11. Publish Notices: Individual contracts are publicised as early as possible in a medium equally
accessible to all interested parties (the Community’s Official Journal).
______________________________________________________________
______________________________________________________________
G12. Objective Criteria : Procurement procedures should be formalised and transparent to the
participants, by employing objective selection and award criteria.
______________________________________________________________
______________________________________________________________
G13. Call Specifications: All offers to be considered during the selection stages of the award
procedure should be in conformity with the call specifications.
______________________________________________________________
______________________________________________________________
G14. Pre-Stated Criteria : The contracting authority shall state all the criteria intended to apply to
the award in the contract documents or in the call notice.
______________________________________________________________
______________________________________________________________
Section H. Questions about this questionnaire

For clarifications in completing this questionnaire, please contact European Dynamics on +30
210 8094500. Thank you for your help……
6 ANNEX B: Contact information from participating public administrations
Country Public Administration Contact person

Belgium Ministry of Defence Service Michel de Prijck
Public Fédéral [email protected]
Denmark AGM Thomas Pedersen
[email protected]
France Ministry of Defence (DGA) Michel Cadic
[email protected]
Romain Berline
[email protected]
Italy Consip Stefano Tremolanti
[email protected]
Luca Mastrogregori
[email protected]
Alessandra Paccoi
[email protected]
Norway GAS Andre Hoddevik
[email protected]
Peder Bentsen
[email protected]
Ministry of Labour and Sidsel Tonnessen
Governmental Administration [email protected]
Spain (Basque country) Department of Finance and Jaime Domiguez Macaya
Public Administration [email protected]
United Kingdom OGC Amabel Grant
[email protected]
Andrew Filer
[email protected]
United Kingdom (Scotland) Scottish Executive Steve Murray
[email protected]
Neil Stewart
[email protected]
European Commission DG ADMIN Dimitrios Athanassiadis
[email protected]
Table 65: Contact information from participating public administrations

S O T A R V II: Tate F HE RT Eport Olume

Uploaded by

Copyright:

Available Formats

S O T A R V II: Tate F HE RT Eport Olume

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S O T A R V II: Tate F HE RT Eport Olume

Uploaded by

Copyright:

Available Formats

STATE OF THE ART REPORT

CASE STUDIES ON E UROPEAN ELECTRONIC

Produced by EUROPEAN DYNAMICS S.A.

on behalf of the EUROPEAN COMMISSION

© European Communities 2004 State of the Art Volume II Page 2 of 109

© European Communities 2004 State of the Art Volume II Page 3 of 109

© European Communities 2004 State of the Art Volume II Page 4 of 109

© European Communities 2004 State of the Art Volume II Page 5 of 109

© European Communities 2004 State of the Art Volume II Page 6 of 109

5 ANNEX A: Structured Communication .................................................................................................................95

© European Communities 2004 State of the Art Volume II Page 7 of 109

© European Communities 2004 State of the Art Volume II Page 8 of 109

Table 51: UK eAuctions services system overview ...........................................................................................77

© European Communities 2004 State of the Art Volume II Page 9 of 109

1.1 Document structure

© European Communities 2004 State of the Art Volume II Page 10 of 109

2.1 Evaluation methodology topics

© European Communities 2004 State of the Art Volume II Page 11 of 109

2.1.1 Analysis of the status of eProcurement in reviewed countries

2.1.2 Analysis of eProcurement systems

© European Communities 2004 State of the Art Volume II Page 12 of 109

System feature System implementation details

Table 2: [Name of eProcurement system] system overview

© European Communities 2004 State of the Art Volume II Page 13 of 109

eProcurement lifecycle Required Functional Details System Implementation Details

Activity Actor Description

2.1.3 Analysis of eProcurement Practices

© European Communities 2004 State of the Art Volume II Page 14 of 109

Each Good Practice is presented in the following way.

Description Brief description of the Good Practice

1 Title of the Good Practice ü

2.2 Support activity

© European Communities 2004 State of the Art Volume II Page 15 of 109

- exclude evaluation criteria Complication

© European Communities 2004 State of the Art Volume II Page 16 of 109

© European Communities 2004 State of the Art Volume II Page 17 of 109

Table 6: Belgian Federal eProcurement approach

© European Communities 2004 State of the Art Volume II Page 18 of 109

Table 7: Danish AGM eProcurement approach

© European Communities 2004 State of the Art Volume II Page 19 of 109

Table 8: French MINDEF (DGA) eProcurement approach

© European Communities 2004 State of the Art Volume II Page 20 of 109

Over 40,911 registered contracting authorities

Estimated gains (cumulative savings at December 2003 ):

Lotto 2 (Lottery 2) launched in 2000

Table 9: Italian Consip eProcurement approach

© European Communities 2004 State of the Art Volume II Page 21 of 109

Limited initial investment of €1.9 million over five years

Table 10: Norwegian GAS eProcurement approach

© European Communities 2004 State of the Art Volume II Page 22 of 109

3.6 Spain (Basque country)

Table 11: Basque government eProcurement approach

© European Communities 2004 State of the Art Volume II Page 23 of 109

3.7 United Kingdom

• Development of government market in UK following an efficient and transparent approach,

OGCbuying.solutions agency created in 2000

Three streams identified:

Table 12: UK – OGC eProcurement approach

© European Communities 2004 State of the Art Volume II Page 24 of 109