Source: EURLEX
Language: en
Format: md

*|*

# 52013SC0224

**COMMISSION STAFF WORKING DOCUMENT Guide for the procurement of standards-based ICT — Elements of Good Practice Accompanying the document COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS Against lock-in: building open ICT systems by making better use of standards in public procurement /\* SWD/2013/0224 final \*/**

  

COMMISSION STAFF WORKING DOCUMENT

Guide for the procurement of
standards-based ICT — Elements of Good Practice

Accompanying the document

COMMUNICATION FROM THE COMMISSION
TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL
COMMITTEE AND THE COMMITTEE OF THE REGIONS

Against lock-in: building open ICT
systems by making better use of standards in public procurement

TABLE OF CONTENTS

1........... Introduction. 4

1.1........ The
purpose of this Guide. 4

1.2........ Definition
of standards. 5

1.3........ Procuring
ICT that is based on standards and other technical specifications — Action 23
of the Digital Agenda  5

1.3.1..... Procurement
practices. 6

1.4........ Structure
of the Guide. 7

2........... Assessing
standards. 9

2.1........ The
benefits of standards and other technical specifications. 9

2.2........ What
to look out for 9

2.3........ What
to do. 11

2.3.1..... Develop
and maintain expertise on standards and other technical specifications relevant
to each area of ICT  11

2.3.2..... Competence
centre on standards and ICT technical specifications. 12

3........... Developing
an ICT strategy. 13

3.1........ What
to do?. 13

3.1.1..... ICT
strategy. 13

4........... Engaging
with the market and evaluation of products. 15

4.1........ What
to do. 15

4.1.1..... Find
out what standards and other technical specifications are supported by the
market 16

4.1.2..... Work
with the market to develop suitable solutions. 16

4.1.3..... Use
information from the engagement process to develop technology-neutral
specifications. 16

4.1.4..... Undertake
periodic evaluation of ICT products and publish this information. 16

5........... Developing
practical advice. 17

5.1........ What
to do. 17

5.1.1..... Develop
lists of recommended standards and other technical specifications as part of an
ICT strategy  17

5.1.2..... Develop
templates and ready texts to refer to standards and other technical
specifications. 18

5.1.3..... Develop templates for IPR
provisions in procurement documents. 18

5.1.4..... Provide
training on ICT public procurement 19

5.1.5..... Monitor
calls for tenders for ICT procurements to detect recurrent problems and
identify ways to resolve these problems. 19

6........... Understanding
ICT needs. 20

6.1........ What
to do?. 20

6.1.1..... Understand
the need for interoperability. 20

6.1.2..... Understand
your legacy systems and try to change the parts that are causing lock-in. 21

6.1.3..... Consider
the need for the use of the data generated or stored by the new purchase. 21

6.1.4..... Consider
the need for public access by businesses or citizens. 22

6.1.5..... Consider
the need to change suppliers or products in the future. 22

7........... Long-term
business appraisal 23

7.1........ What
to do?. 23

7.1.1..... Plan
ahead. 23

7.1.2..... Develop
options. 24

7.1.3..... Conduct
a business appraisal of the options. 24

8........... Long-term
budgetary planning. 26

8.1........ What
to do?. 26

8.1.1..... Accurately
account for future costs and benefits. 26

8.1.2..... Communicate
budgetary needs. 26

9........... Write
procurement documents. 28

9.1........ What
to do?. 28

9.1.1..... Be
aware of the legal framework. 28

9.1.2..... Avoid
unnecessary use of brand names and proprietary technical specifications but
reference the appropriate standards or other technical specifications. 28

9.1.3..... Include
all necessary requests for openness to avoid lock-in. 29

10......... Evaluation
and feedback. 30

10.1...... What
to do?. 30

10.1.1... Write
up case studies of procurement exercises to share best practice. 30

10.1.2... Learn
from experience and adapt centralised and local advice accordingly. 31

11......... Conclusions. 32

Appendix 1: Example texts. 33

Appendix 2: Sources of information. 36

Appendix 3: Costs of implementing the measures proposed
in this Guide. 40

1.           Introduction

The Digital Agenda is Europe’s strategy for
a flourishing digital economy by 2020.[1]
It outlines policies and actions to maximise the benefits of information and communications
technology (ICT) for all. Several actions are devoted to improving
standard-setting procedures and increasing interoperability. Europe must ensure
that, as far as possible, new IT devices, applications, data repositories and
services interact seamlessly everywhere. The guidelines presented in this
document are the result of one of these actions of the Digital Agenda, namely
Action 23, which aims to ensure, through guidance, the appropriate use of
standards in ICT public procurement to alleviate lock-in.[2]

1.1.        The purpose of this Guide

This Guide is designed for use by procurement
officials, IT managers, strategists and architects within public organisations,
and policy makers at a wider government level.

It is intended to help those actors who are
responsible for both planning and purchasing ICT systems and services under the
EU procurement directives to ensure fully effective competition following best
procurement practice, in particular by

·
Minimising the risk of becoming locked in to
particular suppliers for unduly long periods, and

·
Making the best use of ICT standards.

The Guide does not give a list of
recommended standards for use by public authorities when planning and procuring
ICT goods and services. This would not be possible since the standards most
relevant to each awarding authority will vary according to particular
functional needs and the wider set of systems the procured system has to
interact with. However, the Guide does:

·
Offer recommendations on elements of best
practice in ICT procurement, with practical examples.

·
Suggest some concrete ways in which procurement
documents and contracts for ICT might be expressed. The selection process and the
acceptance of results are not covered, however.

·
Give references to sources of more detailed
procurement guidance and information.

This Guide
is intended to help public authorities procure ICT goods and services, and is
not intended as legal advice. Those responsible for procurement should ensure
that all recommended stages comply with national and EU legal requirements, and
seek legal support wherever necessary.

1.2.        Definition of standards

EU Regulation 1025/2012 (amending Directive
98/34)[3]
(the Standardisation Regulation) defines a ‘standard’ as ‘a technical
specification adopted by a recognised standardisation body, for repeated or
continuous application, with which compliance is not compulsory, and which is
one of the following:

·
“international standard” means a standard
adopted by an international standardisation body,[4]

·
“European standard” means a standard adopted by
a European standardisation organisation,[5]

·
“harmonised standard” means a European standard
adopted on the basis of a request made by the Commission for the application of
Union harmonisation legislation;

·
“national standard” means a standard adopted by
a national standardisation body;’.

Standards may be referenced in procurement
documents in accordance with the Public Procurement Directive (see article 23
of Directive 2004/18/EC).[6]
However, Articles 13 and 14 of the Standardisation Regulation also allows ICT
technical specifications (see Article 13) to be referenced in public
procurement that meet the requirements set out in Annex II  to the Regulation
(market acceptance, no conflicts with European standards, process used to
develop standard was open and transparent, and the standard is maintained,
available, and IPR licensed under FRAND). Those ICT specifications are
identified by the Commission after consultation of the European Multi-Stakeholder
Platform on ICT standardisation .

.

1.3.        Procuring ICT that is based
on standards and other technical specifications — Action 23[7] of the Digital Agenda

Under Directive 2004/18/EC, the technical
specifications that
shall be set out in the contract
documentation, such as contract notices, contract documents or additional
documents, must afford equal access of economic operators
to the procurement procedure and shall not have the effect of creating
unjustified obstacles to the opening up of public procurement to competition.
To this end, these technical specifications shall be formulated either in terms of performance or functional requirements
or by reference
to technical specifications defined in Annex VI of the Directive which are, in
order of preference, national standards transposing European standards,
European technical approvals, common technical specifications (including ICT
technical specifications under Article 13 of the standardisation Regulation),
international standards, other technical reference systems established by the
European standardisation bodies or — when these do not exist — to national
standards, national technical approvals or national technical specifications
relating to the design, calculation and execution of the works and use of the
products.

When a public authority is overly dependent
on a single vendor for its ICT systems, there will be a lack of competition for
the provision of these systems and value for money might not be achieved in the
long term. Symptoms of possible lock-in include excessive use of specific brand
names of products in procurement documents, and requests for backward compatibility
with proprietary systems of which only a few suppliers have knowledge. Usually
this also means that procurement documents need to make use of the paragraph 8
in Article 23 of Directive 2004/18/EC: "Unless justified by the
subject-matter of the contract, technical specifications shall not refer to a
specific make or source, or a particular process, or to trade marks, patents,
types or a specific origin or production with the effect of favouring or
eliminating certain undertakings or certain products. Such reference shall be
permitted on an exceptional basis, where a sufficiently precise and
intelligible description of the subject-matter of the contract pursuant to
paragraphs 3 and 4 (of Article 23) is not possible; such reference shall be
accompanied by the words 'or equivalent'. It is one of the aims of this Guide
to prevent the use of Article 8 as much as possible.

Evidence from a survey of procuring
authorities[8]
carried out to prepare this Guide shows that at least 40 per cent of
respondents perceive some degree of lock-in arising from either a lack of
interoperability and compatibility between existing and new systems or
solutions, or from a lack of transferability of data and information between
old and new systems.[9]
These perceptions of lock-in were supported by suppliers, 26 per cent of whom
reported evidence of lock-in in public sector ICT calls for tenders, or felt
that the calls they had seen would serve to perpetuate existing lock-in.[10]

1.3.1.     Procurement practices

The existence of
lock-in and excessive influence of legacy systems can lead public procurers to
engage in poor procurement practices that restrict the ability of suppliers to
participate in calls for tenders. These difficulties have been highlighted in
recent research.[11],[12] They include:

·
Problems in using standards and other technical
specifications appropriately in procurement documents.

·
The use of brand names and proprietary technical
specifications to identify products and systems that only certain vendors or
suppliers can provide.

·
Requirements for the new ICT purchase to be
compatible with previously purchased products or systems, which can favour the
original suppliers and thus restrict competition, while increasing the risk of
vendor lock-in.

In
the context of Action 23 of the Digital Agenda, the European Commission has
collected best practices on how to use standards and other technical
specifications in the procurement of ICT, since their appropriate use will help
alleviate lock-in. The resulting guidance is provided in this document.

1.4.        Structure of the Guide

The Guide follows
the structure shown in Figure 1. It distinguishes three different organisation
levels important for procuring ICT systems based on standards or other technical
specifications and removing lock-in.

·
At centralised level general applicable
knowledge is developed and agreements are developed that are important for all
public authorities. This knowledge and agreements will be made accessible
through an ICT strategy and architecture, lists of recommended standards and
technical specifications, assessments of standards and technical specifications
and products that implement them, templates and ready texts to use when writing
public procurement documents and training on ICT procurement.

·
The local level represents the activities
of one particular public authority that needs to plan several procurements. The
outcomes of these activities will result in a description of the ICT needs,
long term evolution plan of ICT systems and services, and budgetary choices
which are necessary to be done before an individual procurement can take place.

·
The individual level is the level of one
particular public procurement. The activities done at centralised level and
local level should help to make it easier for civil servants to write
procurement documents in a manner that will lead to more competition and
choice. The outcome will be the procurement documents and feedback on the
centralised and local activities.

Each of the activities will be described in
a separate chapter.

Figure
1: The activities involved in procuring ICT systems based on standards and
other technical specifications

2.           Assessing
standards

2.1.        The benefits of standards and
other technical specifications

A key benefit of standards and other technical
specifications in ICT is their role in facilitating interoperability. They
define the minimum specifications of a technology, which, if faithfully implemented,
can enable products, systems and services developed by different suppliers to
communicate and transfer data. Procuring a product from one supplier that is
based on standard technology should help to ensure that future purchases are
not limited to the original supplier, as others are also able to implement the
technology.

2.2.        What to look out for

The standardisation landscape is very
diverse and choosing the right standards or other technical specifications can
be complicated. Procurers should be aware that:

·
Standards and technical specifications can be
implemented in different ways. Standards and technical specifications are often
presented in natural language (and supplemented with some representation of the
specification in a formal and/or semi-formal language). The team implementing
this technical specification needs to interpret this and encode it in a software
system. It is not uncommon that different people may interpret a given
specification in a different way because some specific details in the
specification are not sufficiently precise described, or the inherent
complexity of the specification. Example: SQL (Structured Query Language) is
a database querying language created in the seventies, and standardised by ISO
in 1987 (ISO 9075). However, interoperability problems between major products
still exist due to different interpretations of the standard, due to room for
interpretation and the complexity of the standard. There remains the
possibility of lock-in for suppliers using this standard[13].

It is therefore
important that a standard or technical specification also provides a reference
implementation or a conformance test, so that claims of software providers
regarding the extent to which they implement a standard or technical
specification can be neutrally assessed, and there will be less risk for
lock-in.

·
Almost all standard-setting organisations produce
both effective and widely implemented standards, and some that never achieve
market-place acceptance. It is therefore not possible to judge the value of a
standard simply by virtue of it being a formal standard. Example: the IETF
TCP/IP specification became much more widely implemented than the ISO OSI
standard, despite the fact that ISO has produced many other very successful ICT
standards.

·
Furthermore, while standards set by formal
standard-setting organisations go through a formal development process, they
may not contain all information needed for general implementation. Example: ISO/IEC
29500, ISO/IEC 26300 and ISO 32000 for document formats reference information
that is not accessible by all parties (references to proprietary technology and
brand names, incomplete scope or dead web links). This can have an effect on
the interoperability of products implementing the standard, if the missing
information cannot be found outside of the standard.

·
On the other hand, specifications developed by
industry that have not been through a standard-setting process can be made
available on an open and non-discriminatory basis and implemented across the
market. Example: Universal Serial Bus (USB) is a technical specification
developed by an industry consortium. A not-for-profit organisation was set up:
USB Implementers Forum (USB-IF). Free access to published specifications and
licensing (on royalty-free terms for core specifications) is publicly available
for adopters. USB-IF membership provides additional benefits including free
compliance/interoperability testing, a USB vendor ID and use of the logo.
Interestingly, following an initiative of the European Commission in 2009, one
of the several plug formats (Micro-USB) has been chosen as the standard plug
for mobile phone chargers sold in the European Union due to the broad market
implementation of USB.

·
There are technologies and specifications that
appear to be widely implemented but have not passed through a standard-setting
process (i.e. through a standard-setting organisation or an established
alternative forum or consortium) and in reality could be implemented by only a
few suppliers. These are not considered technical specifications within the
meaning of Article 23.1.a) of the Procurement Directive. Procuring products
that implement these increase the risk of being locked into a limited number of
suppliers or vendors.

·
The intellectual property rights (such as
patents) essential for implementing technical specifications can be made
available to implementers through a range of models. Many technical
specifications are made available on fair, reasonable and non-discriminatory
(FRAND) conditions, which may or may not entail royalty payments. Some technical
specifications are made available on a strictly royalty-free basis under other
licensing conditions. The way in which a technical specification is licensed
may affect the use of products or solutions that implement it, and procurers
should take account of this in the specific context of each ICT purchase to
ensure the licence meets their ICT needs. As an example, FRAND licenses create
barriers for Open Source projects to implement the technical specification.[14] .

·
There are a large number of standards and technical
specifications that overlap. Selecting ICT products implementing only certain technical
specifications may exclude alternative products implementing different technical
specifications that may better support functional needs.

·
The costs of accessing the standard or technical
specification: corresponding documentation can generally be made available
either without charge or for a small fee. This will depend on the standard-setting
organisation’s business model. High access costs can deter some providers from
accessing and using the technical specification.

·
The cost and practicality of implementing the technical
specification: Market demand: a technical specification’s value will be higher
in terms of interoperability and avoiding dependence on a single supplier if it
is mature and widely supported by the market.

·
The development of the technical specification:
if all stakeholders have the same possibility of contributing to its further
development, and public review is part of the decision-making process, then it
is more likely that it will not favour certain suppliers.

·
In general, standards and other technical
specifications are of varying quality and are always liable to change.

However, the benefits of using standards
and other technical specifications are numerous and public authorities should
use them as fully as possible when specifying procurement documents. In order
to do this the following steps are recommended.

2.3.        What
to do

What to do?

Develop and maintain expertise on standards and other technical
specifications relevant to each area of ICT

Who should act?

For efficiency reasons, it is beneficial to maintain knowledge of standards
and other technical specifications centrally within a country or region, and to
make it easily accessible to all procuring authorities. The most suitable organisation
would be the one that also represents the country in the European Multi-Stakeholder
Platform on ICT Standardisation.

2.3.1.     Develop and maintain expertise
on standards and other technical specifications relevant to each area of ICT

Expertise on standards and other technical
specifications relevant to different areas of ICT should be developed and
maintained. This should include information on the various products and
suppliers that implement a technical specification and the effects of this
implementation. Technical specifications can be assessed using the Common
Assessment Method Standards and Specifications (CAMSS).[15] Using this methodology will
ensure that knowledge of technical specifications can be easily shared with
others. In general, cooperation with IT managers from other organisations is
recommended in order to share experiences and expertise.

There are a number of useful sources to
consider in keeping up to date with the development of standards and other technical
specifications. First of all, there is the work done in a number of Member
States to publish lists and catalogues of standards and other technical
specifications with recommendations as to their quality and openness. However, these
are often developed within a particular national context and may not be
applicable to every public organisation.

Also, different ICT domains have already
developed a great deal of knowledge about technical specifications, for
instance in areas such as eHealth, transport, eAccessiblity and eProcurement.
Information and links to all these sources are included in the Appendix.

In this context, it is also important to
understand that only standards from a formal standardisation organisation or a
technical specification that has been identified by the Commission after examination
by the European Multi-Stakeholder Platform for ICT Standardisation may be used
in public procurements. The European Multi-Stakeholder Platform will assess the
process used to develop the standard against certain criteria, e.g. that the
process was open and transparent. The assessment by the Multi-Stakeholder Platform
is not as wide-ranging as that proposed in the CAMSS methodology.  An important
difference is that CAMSS takes into account the specific business needs of the
authority doing the assessment, while this is not the case in the assessment of
the Multi-Stakeholder Platform

On the other hand, if the assessment of a
technical specification produced by a forum or consortium has led to the
conclusion that this specification would be good to use for certain
procurements, but has not yet been assessed by the Multi-Stakeholder Platform,
then the Multi-Stakeholder Platform should be informed that this is a candidate
for assessment. Once approved by the Commission, this ICT technical specification
can be used in the future in public procurement.

2.3.2.     Competence centre on standards
and ICT technical specifications

Some countries, regions and sectors have
set up competence centres on standards and other technical specifications, providing
information on issues associated with the use of these specifications. Examples
include Single Face to Industry[16]
in Sweden and the Standardisation Forum in Norway.[17] These centres can give advice
upon request, but also maintain catalogues of technical specifications to be
used in specific procurement documents. Procurers and IT managers should access
these centres for information and advice where they exist. However, each
country/region/sector should organise knowledge on standards and other technical
specifications in a manner that fits best their organisation.

3.           Developing
an ICT strategy

The second activity shown in Figure 1 is to
define an ICT strategy. It will define the strategic direction of the
authority’s main ICT components and their interfaces and the actions required
to ensure that all ICT systems fit within this strategy. Sometimes this is also
called ICT architecture, or reference architecture. Standards and other
technical specification will play a role in the description of the interfaces.

Having an ICT strategy can be a good way of
coordinating ICT decisions across organisations and governments. This is
important given the need to involve many parts of public organisations in
purchasing decisions early enough to understand the full implications of the
procurement and address any risks. These include legal departments, IT managers
and chief information officers (CIOs), procurers and wider public sector
strategists, as well as those users directly affected by the ICT to be
procured.

ICT procurement decisions taken within the
context of a strategy are likely to result in purchases that meet the needs of
the authority as a whole, rather than only those of individual departments.
This is particularly relevant when migrating to new systems or solutions where
the move is most cost-effective if undertaken on a wide scale. The development
of ICT strategies can also lead to further rationalisation of ICT
infrastructure in departments, limiting duplication and promoting sharing and
reuse of services while allowing flexibility.

3.1.        What to do?

What to do?

Develop an ICT strategy that defines the strategic direction of the
authority’s main ICT components and their interfaces and the actions required
to ensure that all ICT systems fit within this strategy

Select which standards and other technical specifications support
the ICT strategy

Who should act?

The definition of ICT strategies should be considered by CIOs and
leaders with a clear view of the needs of the organisation or sector. However,
all others involved (IT managers, procurement officials and end users) should
be aware of the strategy and how they contribute to and are affected by it.

3.1.1.     ICT strategy

The development of an ICT strategy can be
one way of coordinating ICT systems across organisations and governments, not
only to agree on which standards and technical specifications will be used, but
also to agree on principles which the authority considers important for the
delivery of its ICT services, such as:

·
All citizens should input their data only once;
if another government service needs the same data then they should be retrieved
automatically.

·
A standard format is used for interaction with
citizens.  .

·
Increased interoperability between public sector
ICT systems is necessary.

·
If there is lock-in, a plan has to be developed
to resolve it.

·
Public sector information should be made
available according to certain standards or other technical specifications, in
order to make it easier for organisations/citizens to use this information to
develop services.

·
Documents that have to be archived for a long
period should be stored in a standard format[18].

All these principles may be implemented by
making proper use of standards or other technical specifications.

Example ICT strategies and architectures
are provided in Appendix 2. The procurement of ICT, including the standards and
other technical specifications used, would be carried out so as to realise
these goals.

4.           Engaging with the market and evaluation
of products

This is an important step in the procurement
process, as it enables public authorities to consult the market and to examine
alternative solutions in the market place. Transparent market engagement can
encourage the participation of a wide range of firms, and can help the procurer
develop options that are feasible and best meet ICT needs. In addition, market
engagement is an important step in assessing what are the best standards and
other technical specifications in terms of market support and quality.

It should be noted that any initial consultation
of the market, e.g. technical dialogue, would have to be on condition that the
seeking or accepting of advice does not have the effect of precluding or
distorting competition.

Finding out what the market can provide may
be an iterative process that both draws on and feeds into other steps such as
defining needs or deciding on what standards and other technical specifications
to use. The need for market engagement should therefore be considered in
procurement planning from the beginning. It should be pursued both at
centralised level, for general needs, and at local level, for specific needs.

4.1.        What to do

What to do?

Find out what standards and other technical specifications are
supported by the market

Work with the market to develop suitable solutions

Use information from the engagement process to develop
technology-neutral specifications

Undertake periodic evaluation of ICT products

Who should act?

Finding out what the market can provide would be the task of IT
managers and CIOs, depending on the level at which the procurement decision is taken.
If an ICT strategy is being developed, the market engagement will need to be at
a high level, e.g. led by the CIO.

As an example of guidance on how to
effectively and transparently engage with market participants, we refer
procurers to DETE Ireland’s Buying Innovation: the 10 step guide to smart
procurement and SME access to public contracts.[19] Important steps to highlight
are:

4.1.1.     Find out what standards and
other technical specifications are supported by the market

Procurers and IT managers should consult
with suppliers and supplier bodies, for example at suppliers’ conferences, to
enable suppliers to help select relevant standards and other technical
specifications, provide feedback on their feasibility and affordability, and
gear up to respond to future procurements that will reference the technical
specifications selected.

Understanding the market, the companies
within it and their ability to meet the technical specifications is an
important step in encouraging supplier innovation. Care should be taken when
the market is dominated by a few large players, as this may influence the
selection of standards or other technical specifications.

Different types of technical specifications
(e.g. based on their licensing regimes) will have different effects on market
entry depending on the nature of the ICT domain.

When considering specifications that have
not been developed by a recognised body and/or are not publicly available, the
relevant intellectual property rights must be checked in order to avoid de
facto discrimination, which may result in only a single bid, or very few
bids, being received.

4.1.2.     Work with the market to
develop suitable solutions

It may be useful to communicate long-term
ICT procurement plans to the market to give suppliers time to react and develop
solutions meeting the organisation’s needs. This is particularly important for
solutions that require currently unavailable levels of interoperability. This
will include informing the market of particular standards and other technical
specifications that have been adopted by the organisation, or the ones that
will not be accepted.

4.1.3.     Use information from the
engagement process to develop technology-neutral specifications

Care should be taken to ensure that the
development of procurement options, and the accompanying technical
specifications used in procurement documents, is not unduly influenced by the
suppliers that have been involved in discussions.

4.1.4.     Undertake periodic evaluation
of ICT products and publish this information

Objective evaluation of ICT products
implementing standards and other technical specifications should be undertaken on
a regular basis, in order to be able to take into account new and unknown
products that could satisfy the ICT needs of public authorities. Information
about evaluated ICT products should be made available to all public
authorities, so that evaluations are not duplicated.

Additional information sources for engaging
with the market are provided in the Appendix.

5.           Developing
practical advice

ICT strategies and architectures and the
knowledge gained through the assessment of standards and other technical
specifications and engagement with the market should lead to practical advice
on which standard or other technical specification can be used in which
situation.

5.1.        What to do

What to do?

Develop lists of recommended standards and other technical
specifications as part of the ICT strategy

Develop templates and ready texts to refer to standards and other technical
specifications

Develop
templates for IPR provisions in procurement documents

Provide training on ICT public procurement

Monitor calls for tenders for ICT procurements to detect recurrent
problems and identify ways to resolve these problems

Who should act?

This type of advice should be developed by CIOs and leaders with a
clear view of the needs of the organisation or sector. However, all others
involved (IT managers, procurement officials and end users) should contribute
by sharing best practices.

5.1.1.     Develop lists of recommended standards
and other technical specifications as part of an ICT strategy

One type of practical advice can take the
form of lists of recommended standards and other technical specifications from
which public authorities can choose for their specific situation.

However, Article 23 of Directive 2004/18/EC
states that technical specifications can be requested by name in procurement
documents but must be followed by the clause ‘or equivalent’ to ensure the
principle of non-discrimination. Hence,  the ‘or equivalent’ clause will allow suppliers
to offer products based on equivalent technical specifications. Contracting
authorities cannot reject the tender on the ground that this is not the
technical specification to which it has referred. It is for the supplier to
prove the equivalence, through appropriate means (by a technical dossier of the
manufacturer or a test report from a recognised body).

This obligation is
particularly relevant in the context of a diverse and rapidly changing ICT
landscape –– public authorities should give equal consideration to newly
developed technologies to meet new technological needs.

5.1.2.     Develop templates and ready
texts to refer to standards and other technical specifications

For common ICT needs, where branded
products are often used, descriptions of the products in performance-related
and non-proprietary terms would make it easier for procurers to avoid the
inappropriate use of brand names. These templates or ready
texts would be particularly valuable for (small) procuring departments
with limited access to IT expertise but responsible for procuring common ICT
products.

5.1.3.     Develop templates
for IPR provisions in procurement documents

5.1.3.1.  Licensing for sharing and re-use

Another type of advice to be developed concerns
IPR. If the system to be procured should be re-used by other public authorities
or redistributed in any other way it is important to include the right IPR
provisions in the procurement documents. This can be an important consideration
for public authorities in the interest of making the best use of public funds,[20] but it should also be noted that such openness will make the price
of the system itself higher.

When an ICT application developed or put
together to meet the needs of a public authority could be distributed, re-used,
improved, modified, translated into another language or localised for another
country, public authorities should require their ICT suppliers to grant them the
licensing conditions to do so.

It is important that opportunities for
re-use or sharing are identified before the procurement process; this applies
to sharing or re-using both existing and future assets. In this way, the
necessary licence conditions can be identified and incorporated into the
procurement process.

If the supplier does not write the whole
application source code, but combines or adapts existing components covered by
various copyright licences, the supplier should confirm that these licences allow
the public authority to distribute the application. An example of how such
licence conditions could be requested in procurement documents is provided in
the Appendix: Example text 1.

Because different solutions will include
different IPR licensing models (based on the type of technical specifications
and components used), public authorities should be aware that requesting
certain licence conditions to meet their needs may limit the range of solutions
that can be offered. For example, requesting the ability to re-use software may
restrict solutions incorporating proprietary software.

5.1.3.2.  Other
IPR considerations

Licensing models relating to individual standards
or technical specifications should also be checked, as they will affect the
specification's use under different business models. As an example, some
FRAND-licensed technical specifications are not compatible with some Open
Source Software licences. Therefore, the authority needs to check that the standards
and other technical specifications they request will not unintentionally limit
the types of solutions that can be provided.

Public authorities should also be aware of
the IPR relating to all other parts of the solution provided by the supplier to
ensure that they can use the results of the contract as they wish. An example
text that could be used in contracts to specify the ownership of IPR is
provided in the Appendix: Example text 2.

5.1.3.3.  Indemnity

Public authorities should be aware of the need
for the supplier to indemnify the authority against possible IPR infringements
relating to the supplier’s solution. Such indemnification may be different
under different business models (for example, provisions relating to open
source software may be different to those relating to proprietary software) and
the authority must consider this when requesting indemnification in the
contract, as this may affect the type of solution offered. An example of the
way in which indemnity could be requested is presented in the Appendix: Example
text 3.

5.1.4.     Provide training on ICT public
procurement

In order to create sufficient awareness of the
risks and disadvantages of lock-in situations and how procurement of ICT can be
done in a more open way by using standards and other technical specifications,
the organisations developing the ICT strategy, assessing standards and other technical
specifications and developing practical advice should also provide training
courses for local public authorities and individual procurers.

5.1.5.     Monitor calls for tenders for
ICT procurements to detect recurrent problems and identify ways to resolve
these problems

The demand for (and therefore value of) ICT
procurement advice will be influenced by the awareness of the need to procure
ICT based on standards or other technical specifications. The monitoring
of calls for tenders for ICT procurements is an effective way of
raising awareness of the need for advice. As an example, the advice centre set
up under the Dutch NOiV programme[21]
attached a great perceived advantage to its role of monitoring public sector
calls for tender and providing unsolicited feedback and advice to the public
authorities involved. This included cautions to the authorities on the use of
brand names or other restrictive mechanisms, or the failure to reference
recommended standards or other technical specifications where appropriate.[22] Experience from the programme suggests that public authorities
would not actively seek advice on the use of standards and other technical
specifications in ICT procurement if they did not see any problems with the way
the procurement documents were drawn up. In most cases, it was only after a
public authority had been challenged on procurement documents that it sought
further advice on how to make the procurement process more open and
competitive.

Also, suppliers can report poor procurement
practices to the central service offering such advice, with the hope of
challenging the public authority concerned before the tender process is over
(and thus avoiding costly legal fees). In the Dutch experience, a number of
small suppliers sought the help of the advice centre.

6.           Understanding ICT needs

The activities described in chapters 2, 3,
4 and 5 are all carried out at centralised level. However, understanding ICT
needs should be addressed at the local level of the public authority needing to
procure new ICT systems or services.

It is important to ensure that the ICT
purchase meets the requirements of individual users, the organisation and the wider
public service. The objectives of the purchase (e.g. creating, recording or
storing data, connection with other systems, use by internal staff; interaction
with citizens, etc.) will influence the appropriate standards and other technical
specifications to be used.

6.1.        What to do?

What to do?

Understand the need for interoperability

Understand your legacy systems

Consider the need for the use of the
data generated or stored by the new purchase

Consider the need
for public access by businesses or citizens

Consider the need
to change suppliers or products

Who should act?

This activity
should be undertaken by the department that will use the ICT solution to be
procured to ensure that it is fit for purpose. This must be done together with
IT managers to ensure that the ICT needs are correctly translated into
technical specifications (within the meaning of Article 23.1 of the procurement
Directive), and together with legal and procurement experts to ensure that the
ICT procured can be used as required by the public authority.

6.1.1.     Understand the need for
interoperability

If the ICT purchase is intended to connect
to other systems within an organisation or across government, procurers should
be aware of any common standard or other technical specification that the
purchase should implement to achieve the required interoperability. This will
be particularly important for information transfer (e.g. data, file formats),
to ensure that information can be exchanged across the public sector. The ICT strategy
described in chapter 3 should provide further guidance on specific choices to be
made.

6.1.2.     Understand your legacy systems
and try to change the parts that are causing lock-in

Legacy systems, such as those built over
time through continuous addition of proprietary products and modules or renewal
of licences, can constrain current and future ICT purchases if compatibility
with, or knowledge of, the existing proprietary system is required. This may
have the effect of favouring a limited number of vendors, suppliers or
providers of such products or services. Legacy systems pose even more of a
problem when new additions have to be produced or can only be licensed by
the same vendor due to lack of standardisation in the original system. This can
lead to technical reliance on the original vendor or service provider beyond
the timeframe of the initial contract, thus limiting future competition.

Therefore, public authorities should
consider moving away from current systems causing lock-in to ones that are more
open and based on standards or other technical specifications and that will
facilitate the use of products and services from multiple vendors or service
providers.

The cost of ‘breaking the locks’ of legacy
systems can be significant in the short term, but should be considered
alongside the future benefits of more open systems within the business
appraisal. A long-term plan will be needed.

6.1.3.     Consider the need for the use
of the data generated or stored by the new purchase

Consideration should be given to how the
information received, generated or stored by the new ICT purchase will be used
both now and in the future (in some cases, access to data may be needed for a
very long time). The inputs and outputs of the system or application should be preferably
be in a file format according to a standard or other technical specification, or
otherwise in an open file format specification to enable them to be accessed
and used without reliance on the original application that created them. This
is extremely important if data are to be archived for a long period. Public
authorities have in the past archived data in proprietary formats that after a
number of years are no longer supported by vendors, making their documents
unreadable.[23]
In order to prevent this, some governments require information to be created
and exchanged in formats such as ODF[24] 
and HTML[25].

In addition, governments are increasingly
making their data available to anyone who would like to use these data, since public
sector information has great economic potential and may lead to innovative new
services.[26]
This can also lead to requirements on the format of the data, since if they are
made available to third parties according to standards or other technical
specifications, it will be easier for innovators to build new services.

6.1.4.     Consider the need for public
access by businesses or citizens

It is important that citizens and
businesses wishing to access public sector ICT are not restricted to using
certain branded products or applications, and are allowed to use their
preferred system to access eGovernment services.

An important consideration here is the
accessibility of public ICT websites for people with disabilities, for example
blind and partially sighted people, many of whom need assistive technologies to
access websites (which must be interoperable). Public authorities should be
aware of the possibility of discriminating against people with disabilities,
and should take web accessibility into account in designing their websites.[27]

It is recommended that, where possible,
organisations test such applications for interoperability with a range of
interfaces and data formats. A number of online tools are available to website
developers to test the accessibility of websites on multiple browsers. These
typically create screenshots of a website as viewed in several popular browsers.[28]

Even when there are no technical
specifications for interoperability (for example in the case of innovative,
custom-made applications), a requirement to ensure maximum public access for
citizens may be included as an option and the costs of providing this taken
into account within the business appraisal.

6.1.5.     Consider the need to change
suppliers or products in the future

It is important that procurement decisions
do not lead to organisations being unintentionally tied to certain products or
suppliers. The ability to change products or suppliers should be included in
one of the procurement options (as this requirement may have cost implications
for the solutions procured).

This is particularly important for
contracts for ICT services (e.g. for the development and/or maintenance of IT
systems). Suppliers, such as system integrators, who develop and manage
custom-made systems can retain all the information about the system and make it
very difficult to migrate to another supplier in future to maintain or upgrade
the system.

It should therefore be avoided, where
possible, to commission excessively bespoke and complex solutions, as these are
both very costly and increase the risk of supplier lock-in.

Procurement documents should always provide
for knowledge handover at the end of the contract period. Example texts that
could be included in procurement documents to avoid lock-in with regard to data
and services are provided in the Appendix: Example text 4 and Example text 5.

7.           Long-term business appraisal

Once the ICT needs have been identified,
there will be several options for meeting these needs with new procurements. A
business appraisal should be conducted to consider the full costs and benefits
of a number of options so as to avoid unnecessary expenditure and choose the
option offering the greatest value for money over the long term.

7.1.        What to do?

What to do?

Plan ahead

Develop options

Conduct a business appraisal of the
options

Who should act?

This activity should be undertaken by
the department that will use the ICT solution to be procured. For developing the
options, it can work together with IT managers.

7.1.1.     Plan ahead

ICT purchases should be planned ahead to
allow time for proper identification of needs. Purchases that need to be done
in a hurry (for example, near the end of a contract or licence period) carry the
risk of an existing contract being renewed without full consideration of
alternative options.

In order to move away from legacy systems
that cause lock-in, a long-term implementation plan may be required. This could
include engagement with the market to identify the most feasible solution,
which might require the procurement of services to modify the existing system,
or the procurement over time of elements that are compatible with both the
existing system and the standards or other technical specifications that the
public authority would like to use for its ICT systems.

Coordination with other public sector
organisations is important to ensure that the new system is interoperable with
those with which connections are required. In the case of legacy systems that
extend across organisations, a higher level of coordination will be needed (through
the ICT strategy) to ensure that change happens at all levels. The use of a
formal change management process may help, taking into account both the
technical and non-technical elements of moving away from legacy systems
creating lock-in.[29]

7.1.2.     Develop options

Depending on ICT needs there may be a
number of options to consider for procurement. These will vary significantly
according to whether ICT hardware, software, services or the development of
bespoke systems are being procured.

In order to minimise the risk of long-term
dependence on a single supplier or service provider, options should include the
adequate level of openness of the product or service. This could be achieved
by:

·
Requiring the purchase to implement certain standards
or other technical specifications (as mentioned in the discussion above, these
should be open for access and implementation by all interested parties).

·
Including in the options a requirement for the
supplier or service provider to ensure the desired openness in the absence of
suitable standards or other technical specifications. This could include requiring
the data produced by the system to be available in an open format; or requiring
the developer of a system to bear the costs of handing over the necessary
documentation to another developer at the end of the contract (thus including
'exit costs' in the price of the contract).

When considering different options, it must
be noted that supplier or service provider dependence can occur in many
situations, even when the ICT system is not physically acquired, but rather an
ICT service is procured (e.g. through outsourcing or moving to the cloud).
Provision for openness must therefore be considered in all types of ICT
procurement.

7.1.3.     Conduct a business appraisal
of the options

A business appraisal should be carried out
taking into account as far as possible all the costs arising from needs and
user requirements. There are likely to be trade-offs between different needs
and requirements, so a number of options should be developed and their relative
costs and benefits assessed. Clear and useful guidance on how to conduct a
business appraisal is provided by the UK Treasury’s Business Case Guidance
website and Green Book.[30]

Important
components of an appraisal include:

·
Consideration of the whole life costs of the ICT
options. These include costs of maintenance, operation, changes and upgrades
over the life of the purchase (and not just the life of the initial procurement
contract). With a view to avoiding lock-in, exit costs are very important.
These refer to the costs likely to be incurred in moving to another supplier or
product in the future. As an example, the up-front costs of an option using,
say, non-standard proprietary technology that cannot be implemented by other
suppliers may be lower than a more open solution, but when exit costs are taken
into account the more open solution may provide better value for money. On the
other hand, non-proprietary products that are relatively cheap to purchase may
incur substantial operational costs over their lifetime.

·
Other costs of change. These could include
training and support of staff (particularly with systems that have bespoke user
interfaces), overcoming managerial inertia and coordinating with other
departments or public sector organisations.

·
The timeframe for the contract. The use of a
specific vendor should not be implied after the timeframe provided for in the
contract. Awareness of the likelihood of being tied to the vendor should be
taken into account and reflected in the contract timeframe. Constraining future
purchases to be compatible with existing products is likely to favour the
original vendor and restrict competition.

·
Consideration of the risk profile of the
organisation. Some options may seem more risky than others (for example,
choosing a smaller supplier instead of a large well-known one, or a less widely
implemented standard). This should be acknowledged and appropriate weights attached
to the costs of the options to adjust for the risk. That an option appears
riskier than others does not imply that it should be dismissed without
assessment of all other factors.

·
Benchmarking of costs. Comparing the costs of
different options may not be straightforward, particularly with more complex
purchases. Wherever possible, examples of similar purchases should be obtained
from other public organisations, the private sector and other Member States in
order to inform cost assessments. Of particular importance will be examples of
exit costs incurred in the past, when organisations have migrated systems.

The Appendix includes an example of an
investment appraisal undertaken by the Swedish National Police in order to
decide on what ICT infrastructure to procure.

8.           Long-term budgetary planning

Many public sector organisations now
operate under more limited budgets. They are also pre-planning their
expenditures in various ways. During the ICT procurement planning phase, it is
thus important to consider and communicate the budgetary needs. This is
particularly important if the upfront costs of the procurement are likely to
appear greater than the short-term benefits.

8.1.        What to do?

What to do?

Accurately account
for future costs and benefits

Communicate
budgetary needs

Who should act?

Long-term
budgetary planning should be undertaken by those involved in the planning of
the ICT procurement. They could include end users, IT managers and procurement
officers.

8.1.1.     Accurately account for future
costs and benefits

Within the business appraisal, evaluators
should consider the short- and long-term costs of all options and discount
future costs and benefits to present values to enable an equal comparison.

When comparing new options against existing
systems, information will need to be collected on the current and expected future
costs of existing systems.

Benchmarking exercises or information
sharing with other organisations may help inform assessment of the costs of
being locked in and the costs and benefits of moving to more open systems.

8.1.2.     Communicate budgetary needs

Particularly in situations where large
upfront costs need to be incurred to bring long-term benefits, it is important
to communicate the rationale behind the decision clearly to those responsible
for organisational finances. The costs of breaking the locks of legacy systems
may seem high in comparison with leaving the system as it is, even though
future benefits may outweigh the costs in the long term. An appraisal of the
options, taking into account all future costs (including exit costs) and
benefits, therefore may well be an important tool in obtaining budgetary
approval.

The existence of an overarching ICT strategy
may be helpful here in providing additional support when setting out the case
for a particular ICT purchase.

In organisations that work within annual
budgets, the need for large upfront investment will have to be communicated
well in advance.

9.           Write procurement documents

This advice addresses individual procurers,
as represented in the lowest level of Figure 1.

In writing the procurement documents for
the ICT to be purchased, all the elements of best practices that have been
developed in activities at the centralised and local level should be used and
will come together.

9.1.        What to do?

What to do?

Be aware of the legal
framework

Avoid unnecessary
use of brand names and proprietary technical specifications but reference the appropriate
standards or other technical specifications

Include all
necessary requests for openness to avoid lock-in

Communicate
budgetary needs

Who should act?

The drafting of calls
for tender could be a collaborative approach involving different actors at
different stages. For example, IT managers may draw up technical
specifications, procurement officers can address the general aspects of the
tender documents and legal experts can advise on legal aspects.

9.1.1.     Be aware of the legal
framework

Procurers must be aware of the legal
framework that governs the referencing of standards in procurement documents.
For a discussion on how to refer to standards, see also sections 1.2 and 5.1.1.

9.1.2.     Avoid unnecessary use of brand
names and proprietary technical specifications but reference the appropriate
standards or other technical specifications

Where possible, use templates to help describe
the ICT product or system in technology-neutral terms. There are templates for
certain products that can be used. Examples include Germany’s BITKOM guides on
wording procurement documents in a non-proprietary manner for desktop PCs,
notebooks and servers.[31]

And, although they deal primarily with open
source software, the OSOR guidelines also contain suggested model texts for the
inclusion of standards or other technical specifications in procurement
documents.[32]

9.1.3.     Include all necessary requests
for openness to avoid lock-in

Other requests for openness may be made in
the procurement documents (in addition to requiring the new ICT purchase to implement
or be interoperable with certain technical specifications). These can be included
in the award criteria or functional requirements of the technical
specifications.

Bidders may be requested to indicate the
costs required to make the solution open to alternative suppliers after the end
of the contract period. Example texts are provided in the Appendix.

Care should be taken when assigning weights
to different cost categories in the procurement documents, as these could
encourage distortions in the way costs are reflected.

10.         Evaluation and feedback

It is important to draw lessons for future
procurement from each procurement process and to share best practice and
lessons learned. The effect of using certain standards or other technical
specifications can be assessed, as well as the accuracy of any cost
benchmarking exercises. This evaluation can also be used to assess suppliers in
the market in terms of the extent to which they have met required technical
specifications in their products or solutions.

Part of the evaluation process could be to
assess how the outcome of the procurement exercise meets the wider ICT strategy
of the organisation (e.g. how successful was it in enhancing interoperability;
or ensuring accessibility?).

A further useful role of evaluation could
be in planning future procurement exercises, for example drawing up a timetable
of upgrades and contract renewals to fit in with other procurement exercises,
or to identify likely break points where new standards or other technical
specifications might impact decisions to buy, upgrade or renew.

Another useful evaluation parameter could
be the number of procurement procedures (if any) having been the subject of
litigation, arbitration or complaints.

Finally, the feedback provided by those
cases, together with the result of the benchmarking exercises, should be
integrated in procurement training actions and in the adaptation of practical
advice.

10.1.      What to do?

What to do?

Write up case
studies of procurement exercises to share best practice

Learn from
experience and adapt centralised and local advice accordingly

Who should act?

The drafting of
tenders could be a collaborative approach involving different actors at
different stages. For example, IT managers may draw up technical specifications,
procurement officers can address the general aspects of the tender documents
and legal experts can advise on legal aspects.

10.1.1.   Write up case studies of
procurement exercises to share best practice

Case studies could include the following
elements:

·
What standards or other technical specifications
were used and what effect this use had.

·
How well the procured product or solution was
designed and delivered.

·
How the overall costs of the procurement compare
to the initial benchmarking exercise, and what adjustments need to be made to
future benchmarking exercises.

It may be appropriate to disseminate best
practice to other public organisations, including those in other Member States.

10.1.2.   Learn from experience and adapt
centralised and local advice accordingly

The experience gained with individual
procurements should be fed back to all other activities at centralised level,
especially the ‘develop practical advice’ activity, in order to improve it and
keep it up to date.

11.         Conclusions

Lock-in is a complex problem to address,
which cannot be dealt with only by public procurement. The advice given in
these guidelines promote long-term change, providing a strategy on how public
authorities, over time, can overcome their lock-in situation without
jeopardising business continuity. It requires a long-term commitment at all
levels of decision making to make this happen. In Figure 1, we illustrate that
by identifying activities that have to be carried out at different levels of the
organisation. The need for this commitment at all levels was clearly stated in
presentations by experts in the field during a workshop on this topic at the
Digital Assembly of 2011.[33]
Also required is the development of an extensive amount of knowledge on ICT
strategies and standards and other technical specifications, which is an
activity that needs continuous work in order to keep up to date with
developments in the (fast-moving) ICT market.

The advice given here is just the beginning
of a process. Member States that read this will be encouraged to develop
specific versions of the guidelines to reflect the choices they make in order
to have an efficient and flexible basis for their ICT systems. However, in
developing their own guidelines, Member States should consider the value of a common
approach across the EU and wherever possible encourage the use of the same
standards and technical specifications, in order to come closer to a digital
single market.

Appendix
1: Example texts

This Appendix includes examples of text
that could be used in procurement documents to achieve various aims. We
emphasise that the examples provided are for illustrative purposes only.
Readers of this document are recommended to seek legal advice where necessary.

Example text 1: Requesting licences for
sharing

“The supplier will grant that the purchasing authority
has the right to distribute the delivered application under the European Union
Public Licence (EUPLv1.1 or later) or any licence(s) providing the rights
stated in the Article 2 of the EUPL.”

Example text 2: General IPR conditions

The ownership of all copyright, trademarks, trade names,
patents, and all other intellectual property rights (“IPR”) subsisting in the
graphics, website layout, surface content, logos and devices, and the rights to
the domain name(s), manuals, training materials or presentations shall vest and
shall remain vested in the Commissioners absolutely.

The Commissioners, or the acknowledged owner, shall be
and remain the sole owners of all IPR in all data, material, documentation or
information inputted, loaded or placed onto the System in any manner, reports
generated by or from the System, material or documentation placed on the
System, outputs, and end-products.

The successful Tenderer will be required to  indemnify
the Commissioners against third- party claims relating to the Commissioners’
use of any software, hardware or intellectual property.

All pre-existing IPR shall remain the sole property of
the Party who owned, acquired or developed such IPR.

Bespoke, custom-built and fully managed
eTendering system for a government website

Example text 3: Requesting indemnity

The Contractor shall
ensure that any necessary consents and/or licences for any software,
instrument, modality or methodology are obtained and in place before use for
the purposes of this Agreement (to include but not be limited to ensuring that
the Client is vested with all necessary rights so as to enable the Client to
enjoy the benefit of the Services for its business purposes). The Contractor
hereby indemnifies the Client and shall keep and hold the Client harmless from
and in respect of all and any liability, loss, damages, claims, costs or
expenses which arise by reason of any breach of third-party Intellectual
Property Rights in so far as any such rights are used for the purposes of this
Agreement.

Services
procurement template from Ireland
eTendershttp://www.etenders.gov.ie/guides/Guide\_Download.aspx?id=3364

Example text 4: For software systems where
the data need to be migrated to future systems from a different provider

In order to ensure that a competitive tender can be used
to select another potential provider after the lifetime of the solution supplied
under this tender, an anti-lock-in requirement must be met. All technical
specifications, interfaces, protocols or formats implemented by the supplied
solution and required for the full use of all data created or maintained using
the supplied solution during its lifetime must be made available to providers
of equivalent technologies who may be awarded a subsequent contract, with no
additional costs. Any costs required for migration of data must be borne by the
supplier of the supplied solution. Such costs may be minimised by ensuring that
the supplied solution uses only , interfaces, protocols or formats that:

1. are implementable by all potential providers of
equivalent technologies

2. are developed through an open and transparent process

3. have no restrictions on re-use, and require no
payments for re-use

Example text 5: For systems where the
system itself needs to be maintainable by a different provider

In order to ensure that a competitive tender can be used
to select another potential provider after the lifetime of the solution to be supplied
under this tender, an anti-lock-in requirement must be met. All interfaces,
protocols or formats implemented by the supplied solution and required for the
full use of all data created or maintained using the supplied solution during its
lifetime must be made available to providers of equivalent technologies who may
be awarded a subsequent contract, with no additional costs. Any costs required
for migration of data shall be borne by the supplier of the supplied solution.
Such costs may be minimised by ensuring that the supplied solution uses only
interfaces, protocols or formats that:

1. are implementable by all potential providers of
equivalent technologies

2. are developed through an open and transparent process

3. have no restrictions on re-use, and require no
payments for re-use

Furthermore, all documentation needed in order to
provide full support for the supplied solution must be made available to any
subsequent provider. Any costs of preparing such documentation shall be borne
by the provider of the supplied solution.

More examples for sharing
and reuse may be found in Deliverable 2.1 Standard "Sharing and re-using" clauses for contracts[34], developed in the context of
ISA Action 4.2.5. Sharing and re-use strategy.

Appendix
2: Sources of information

This Appendix
lists useful sources of information to complement the text of the Guide.

General procurement guidelines

Other
references to procurement best practice. At EU level, these include:

·
European Commission (2007) ‘Guide to dealing
with innovative solutions in public procurement: 10 elements of good practice’,[35] Commission staff working
document SEC(2007) 280

·
DETE Ireland’s Buying Innovation: the 10 step
guide to smart procurement and SME access to public contracts.[36]

Sources of information for the assessment
of standards and other technical specifications

The Common Assessment Method Standards and
Specifications (CAMSS)[37]
has been developed under the Interoperability Solutions for European Public
Administrations (ISA) programme run by the European Commission. CAMSS enables
assessments of standards and other technical specifications for ICT
interoperability to be shared across Member States

CAMSS offers a neutral method to assist
Member States in their assessment of the technical specifications needed to
develop interoperable national and cross-border eGovernment services. CAMSS
aims to ensure that public administrations can assess and select the most
relevant standards and technical ICT specifications for their needs. CAMSS
comprises 1) a process, 2) a set of criteria and 3) an assessment library. The
CAMSS process describes how to complete an assessment from start to finish
using CAMSS criteria. Completed assessments are to be made available in an
assessment library to help Member States share and re-use assessments.

Examples of organisations publishing lists
that may be of wider interest include:

·
The Netherlands Standardisation Forum, which
maintains lists of mandatory and recommended open standards.[38]

·
The Danish OIO Committee, which maintains a list
of open technical specifications and recommendations on their applicability and
usefulness.[39]

·
The Norwegian Agency for Public Management and
eGovernment (Difi), which maintains the Standardisation Forum, a body that provides
information on mandatory and recommended technical specifications for the Norwegian
public sector. The technical specifications are available from an online
catalogue.[40]

·
The French RGI (Référentiel Général
d’Interopérabilité), which references standards and other technical
specifications that are recognised and supported by standards bodies, and recommended
for use by French public authorities. All technical specifications are
available online.[41]

·
The Malta Information Technology Agency (MITA),
which includes the specifications and technologies that have been adopted, or
are being considered for adoption, by the Government of Malta in an Adopted
Specifications List. This is available on MITA’s website.[42]

·
The catalogue of ICT standards of Spain[43].

Development of standards in specific
domains

Below are listed some areas of work for which
specific standards are currently being developed:

·
The 2010-2013 ICT Standardisation Work
Programme, provides an overview of ongoing standardisation work.[44]

·
Work in the area of eAccessibility under
European Commission Mandate 376, which aims to develop a toolkit of recommended
technical specifications and templates for procurers to include in procurement
documents.[45]

·
CEN provides a number of documents that are
likely to be relevant to procurers in this respect, mainly in the form of CEN
Workshop Agreements (CWAs).[46]
These include documents covering:

·
Electronic invoicing.[47]

·
Electronic procurement.[48]

·
Electronic catalogues, and links to classifications
used for private and public procurement.[49]

·
The PEPPOL project provides information about
standards and other technical specifications used for electronic procurement
(e-Procurement).[50]

·
In the transport domain:

·
Open traffic systems: Urban Traffic Management
and Control (UTMC) specification in the UK. It  provides technical
specifications for shared data (i.e. data communicated between applications of
a UTMC system, or between a UTMC system and an external system)[51]

·
Open Communication Interface for Road Traffic
Control Systems (OCIT) in Germany, Austria and Switzerland, which provides
technical specifications for communication between systems[52]

·
Smartcard systems: ITSO standard owned by the UK
government to avoid proprietary smartcard systems in UK cities. ITSO is a
government-backed non-profit organisation which sets a common technical
standard to enable interoperable travel[53]

·
There is a similar standard called Calypso in
other countries of Europe. Calypso is the international electronic ticketing
standard for contactless smart cards, originally designed by a group of
European transit operators. It ensures multiple sources of compatible products,
and enables interoperability between operators[54]

ICT strategies and architectures

The Smartcities’
guide to ICT architectures is another useful source and provides case studies
of architectures in the Netherlands, Sweden and Norway.[55]

In addition, the
work of the ISA programme on National Interoperability Frameworks[56] is highly relevant.

Engaging with the market

The Netherlands Open in Connection website
has guidance on communicating with suppliers on the use of open standards, and
includes a template manifesto letter to suppliers.[57]

The Netherlands Open in Connection website
provides additional guidance on evaluating suppliers.[58]

Migrating
from a lock-in situation

The case study below provides an example of
a public authority undertaking a full business appraisal to move away from a
proprietary system.

A 2009 study by OSOR.eu investigated the
overhaul of the Swedish National Police ICT server infrastructure to move from
proprietary to open source software and hardware. The overhaul concerned (i)
the application server, (ii) the database, (iii) the operating system of the
servers and (iv) the CPUs of the servers. The changeover was the result of a
comprehensive case study made in 2006 following realisation that the use of
proprietary products created lock-in and was expensive. The study found that
using open source products would reduce lock-in and consequently the total cost
of ownership from € 40 m to € 21 m over 2006-2011, in
addition to improving performance.

As the migration was on a large scale, the
changeover process was carefully planned. The first phase, the ‘implementation
project’ (2007), involved the procurement of X86 standard hardware and support
for the MySQL database and the Linux operating systems, as well as the development
and installation of appropriate solutions. The second phase, the ‘migration
project’ (2009 onwards), involved the actual migration of 33 legacy systems to
the new ICT platform over a two-year period. This phase has required
interaction with various stakeholders to convince them of the merits of the new
infrastructure. Interaction with experts to devise the optimal migration
procedure is also recommended in each instance.[59]

Appendix
3: Costs of implementing the measures proposed in this Guide

The costs of complying with this Guide
include the costs of setting up an organisation to develop ICT strategies, to
assess technical specifications and develop recommended lists, to develop
templates and ready texts and to provide other forms of advice, including
training. The upper bound to these costs, extrapolated from numbers received
from public authorities already procuring ICT systems based on standards and
other technical specifications, and estimated for all Member States together,
is some € 53 million.[60]

Using the results of the Commission study
estimating the benefits of the procurement directives,[61] it is estimated that doubling
the number of bidders could result in a 9 % decrease in contract values in
EU public procurement. Given that the total annual value of EU ICT public
procurement is some € 78 billion and the maximum total cost of applying this
Guide is € 53 million, the number of bidders need be increased by only 0.7 %
in order to achieve an offsetting reduction in contract value. Feedback from
the 2012 Survey[62]
and interviews suggest that this would not be unreasonable, with the majority
of respondents indicating that increased use of standards and other technical
specifications in public procurement would increase the ability of firms to
participate in calls for tender.

[1]               COM/2010/0245, see           
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52010DC0245R(01):EN:NOT.

[2]               http://ec.europa.eu/digital-agenda/en/pillar-ii-interoperability-standards/action-23-provide-guidance-ict-standardisation-and-public.

[3]               OJ L 316, 14.11.2012, p. 12–33

[4]               These are ISO, IEC and ITU.

[5]               ETSI, CEN and CENELEC.

[6]               OJ L 134, 30.4.2004, p. 114–240 .

[7]               http://ec.europa.eu/digital-agenda/en/pillar-ii-interoperability-standards/action-23-provide-guidance-ict-standardisation-and-public.

[8]               http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/study44-survey1results.pdf.

[9]               Although not directly related to the issue of
standards, lock-in arising from institutional factors (e.g. staff familiarity
with existing products) was noted by 25 per cent of respondents; and lock-in
arising from service providers was noted by just under 20 per cent of
respondents.

[10]             ‘D2 — Overview of Procurement Practices’. A report by
Europe Economics for the European Commission, see
http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d2-finalreport-29feb2012.pdf.

[11]             Research
based on a review of relevant literature, a survey of procurers and ICT
suppliers across the EU and an analysis of a selection of tenders. See Europe
Economics (2011) ‘Guidelines for Public Procurement of ICT Goods and Services;
D2 — Overview of Procurement Practices’,
http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d2-finalreport-29feb2012.pdf.

[12]             http://kkv.se/upload/Filer/Trycksaker/Rapporter/uppdragsforskning/forsk\_rap\_2013-2.pdf
(report of the Swedish Competition Authorities in Swedish, English summary:
pages 10-12)

[13]             These examples are illustrations only and do not imply
any recommendations to readers.

[14]
http://ec.europa.eu/enterprise/sectors/ict/files/ict-policies/report-from-frand-os-conference-22nov12\_en.pdf

[15]             https://webgate.ec.europa.eu/fpfis/mwikis/idabc-camss/.

[16]             http://www.sfti.se/sftistartsida/in\_english\_1.

[17]             http://standard.difi.no/english.

[18] In case a document is stored in a format that is only known by a
specific  product, it can happen that future versions of this same product will
not be able to read the format in which the document was stored, making the
stored document unreadable.

[19]             Department
of Enterprise, Trade and Employment (2011) ‘Buying Innovation: the 10 step
guide to smart procurement and SME access to public contracts’, see
http://etenders.gov.ie/Media/Default/SiteContent/LegislationGuides/25.%20Buying%20Innovation%2010 %20Step%20Guide.pdf.

[20]             JOINUP.eu
is dedicated to supporting the sharing of software, semantic assets and open
data

[21]             Netherlands Open in Connection, the programme
implemented to encourage the adoption of open standards and open source
software among the public sector in the Netherlands, see
https://www.ictu.nl/archief/noiv.nl/index.html.

[22]             Based on an interview with the head of the advice
centre.

[23]             Gamalielsson, J. and Lundell, B. (2011) Open Source
communities for long-term maintenance of digital assets: what is offered for
ODF & OOXML?, In Hammouda, I. and Lundell, B. (Eds.) Proceedings of SOS
2011:Towards Sustainable Open Source, University of Technology, Tampere, ISBN
978-952-15-2411-0, ISSN 1797-836X, see
http://tutopen.cs.tut.fi/sos11/papers/cr6.pdf.

[24]             http://www.iso.org/iso/iso\_catalogue/catalogue\_tc/catalogue\_detail.htm?csnumber=59302.

[25]             http://www.w3.org/TR/1999/REC-html401-19991224/.

[26]           http://ec.europa.eu/information\_society/policy/psi/docs/pdfs/report/psi\_final\_version\_formatted.docx

[27]             COM(2012) 721, see,           
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0721:FIN:EN:PDF
and    
http://ec.europa.eu/digital-agenda/en/news/proposal-directive-european-parliament-and-council-accessibility-public-sector-bodies-websites.

[28]             Examples
include BrowserShots (http://browsershots.org/),
BrowserCam (http://www.browsercam.com/),
NetMechanic Browser Photo (http://www.netmechanic.com/products/browser-index.shtml),
Litmus (http://litmus.com/) and AnyBrowser (http://www.anybrowser.com/index.html).

[29]             For example, the ADKAR Change Management Model:
http://www.strategies-for-managing-change.com/adkar.html. Please note that this
is an example only and many other models exist.

[30]             HM
Treasury ‘Business Case Guidance’ http://www.hm-treasury.gov.uk/data\_greenbook\_business.htm
and HM Treasury ‘The Green Book’ http://www.hm-treasury.gov.uk/d/green\_book\_complete.pdf
Chapter 5 deals with options appraisal.

[31]             ITK-beschaffung:
http://www.itk-beschaffung.de/en/introduction.html.

[32]             OSOR
guidelines on public procurement of open source software IDABC European
eGovernment Services (June 2010),
https://joinup.ec.europa.eu/sites/default/files/studies/OSS-procurement-guideline-public-final-June2010-EUPL-FINAL.pdf.

[33]             http://ec.europa.eu/information\_society/events/cf/daa11/document.cfm?doc\_id=18502.

[34] https://joinup.ec.europa.eu/sites/default/files/ISA\_Share\_Reuse\_D\_2%201%20Standard%20Sharing%20and%20re-using%20clauses%20for%20contracts\_final%20version.pdf

[35]             http://www.proinno-europe.eu/admin/uploaded\_documents/procurement\_manuscript.pdf.

[36]             Department of Enterprise, Trade and Employment (2011)
‘Buying Innovation: the 10 step guide to smart procurement and SME access to
public contracts’, see
http://etenders.gov.ie/Media/Default/SiteContent/LegislationGuides/25.%20Buying%20Innovation%2010 %20Step%20Guide.pdf.

[37]             https://webgate.ec.europa.eu/fpfis/mwikis/idabc-camss/.

[38]             Standardisation
Forum, Assessment Procedure and Criteria for Lists of Open Standards, www.forumstandaardisatie.nl.

[39]             http://en.itst.dk/it-architecture-standards/standardisation/open-specifications/the-oio-catalogue.

[40]             http://standard.difi.no/english.

[41]             www.references.modernisation.gouv.fr/rgi-interoperabilite.

[42]             https://www.mita.gov.mt/MediaCenter/PDFs/1\_GMICT\_S\_0071\_Adopted\_Technologies.pdf.

[43]           
http://administracionelectronica.gob.es/recursos/pae\_000022681.pdf

[44]             See
http://ec.europa.eu/enterprise/sectors/ict/standards/work-programme/index\_en.htm.

[45]             CEN,
CENELEC, ETSTI, AENOR, Online Procurement Toolkit for accessible ICT products
and services, p. 29, http://www.mandate376.eu/.

[46]             The
European Committee for Standardisation (CEN) is a major provider of European standards
and technical specifications. It is the only recognised European organisation under
Directive 98/34/EC for the planning, drafting and adoption of European standards
in all areas of economic activity, with the exception of electrotechnology (CENELEC) and
telecommunications (ETSI).

[47]             http://www.cen.eu/cen/Sectors/Sectors/ISSS/Activity/Pages/eInvoicing\_2.aspx.

[48]             ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eProc/cwa15236-00-2005-Feb.pdf.

[49]             http://www.cen.eu/cen/Sectors/Sectors/ISSS/Workshops/Pages/eCAT.aspx.

[50]             http://www.peppol.eu/.

[51]             http://www.utmc.uk.com/index.php.

[52]             http://www.ocit.org/indexE.htm.

[53]             http://www.itso.org.uk/.

[54]             http://www.calypsotechnology.net/).

[55]             Smart
Cities ‘Creating Municipal ICT Architectures (2011):
http://www.smartcities.info/files/Creating%20Municipal%20ICT%20Architectures%20-%20Smart%20Cities.pdf.

[56]             http://joinup.ec.europa.eu/elibrary/factsheet/national-interoperability-framework-observatory-nifo-factsheets-2012.

[57]             https://noiv.nl/leveranciersmanifest/.

[58]             http://http://noiv.nl/.

[59]             http://joinup.ec.europa.eu/elibrary/document/swedish-national-police-how-avoid-locking-yourself-while-saving-money-pdf.

[60]             http://cordis.europa.eu/fp7/ict/ssai/docs/study-action23/d4-impact-assessment-prep.pdf.

[61]             The work centred on econometric analysis of the MAPPs
database in order to quantify more precisely the benefits of good practice in
procurement. This was part of the study carried out for DG MARKT ‘Estimating
the Benefits from the Procurement Directives’. http://ec.europa.eu/internal\_market/publicprocurement/docs/modernising\_rules/estimating-benefits-procurement-directives\_en.pdf.

[62]             http://cordis.europa.eu/fp7/ict/ssai/docs/study44-survey2results.pdf.

[Top](#document1)