2 of 18

Data publishing challenges - We wanted a better understanding of how organisations go about publishing open contracting data whether in OCDS or not and the challenges they face.
Decisions making process - We wanted a deeper understanding of why publishers make specific decisions around how they publish data i.e. what fields, which formats, etc.
Improve support for all publishers - Our support was very tailored to OCDS publishers. The insights for this study would help us to support all publishers and potentially deepen our collaboration with them.

Why this study?

3 of 18

What is the implementation journey to openly publish public sector contracting data?

Data published could be OCDS, non-OCDS or still be work in progress
What are the technical and operational aspects of publishing, i.e. what did these organisations do?
How do publishers deal with the complexity of the data?
How do these organisations publish data sustainably and ensure it is of good quality?

What are these publishers goals and aspirations?

What are the internal and external goals that publishers have?
How is public sector contracting data published for end users?
How were the decisions to publish contracting data made, and why?

Research questions in this study

4 of 18

40 to 60-minute interviews - Conducted with publishing organisations, consultants and civil society organisations that worked to openly publish public sector contracting data. Publishers were based in the USA, Latin America, Africa, Europe and in multiple countries across Asia.
Open conversations - 13 interviews, which followed a semi-structured format, and screen shares, which allowed for observation of specific tasks, were recorded, re-watched and turned into detailed notes.
Thematic analysis - The qualitative data was analysed to find common themes and to answer the research questions.

Research highlights - what we did

5 of 18

What is the implementation journey?

6 of 18

Publishing data is part of a much larger and complicated process

1. Digitisation of “paper” procurement processes

2. Improved processes & IT systems

3. Change to data schema in database(s)

4. Data extraction for use or publishing

7 of 18

1. Digitisation of “paper” procurement processes

Organisations looked at off the shelf options but were frustrated with what was available.

“Poor” or “terrible UX”
“Did not meet specific needs”
“Did not match our organisation's processes”

Most organisations had purchased an e-Procurement system or built one in-house.

In reality there was often more than one system for different parts of the contracting process.
Reason for building in-house was to meet very specific needs of the publisher that off the shelf systems were unable to.

How to use the data in most cases had not been considered. Exceptions existed where:

One organisation had a clear goal to support small businesses.
One country followed a “Design Thinking” process to decide what data different use groups wanted.

Organisations not at the point of publishing were struggling with what do do.

Publishing data was a small part of the overall requirements they were trying to find a system to meet.
Hard to how how to acquire/build a system that will be sustainable.

8 of 18

2. Improved processes & IT systems

Process evolution

New legal requirement

Evolving IT systems

Change management

Improved processes through Iteration and learning from experience

Changes to a country’s laws resulting in changes to data being collected

Updated systems i.e. new functionality and/or increased flexibility

Earlier processes and IT systems were a temporary step to help staff to adapt

Leads to changes in procurement data over time and data quality issues

9 of 18

3. Change to data schema in database(s)

Data quality

Problems with data quality don’t originate at publishing stage
Data validation not happening in systems upstream

Staff change leading to information loss
Data is stored but not used, so why update documentation?

Documentation

Updates to systems

Changes to fields and tables over time
Definitions for what fields mean can change
Changes accumulate over years

10 of 18

4. Data extraction for use or publishing

	Process	Output(s)	OCP tool or support used	Advantages	Disadvantages
1	Identify and map fields in system(s) to OCDS for publishing JSON and CSV	Publish data in JSON / CSV / visualisation	Field mapping template OCDS documentation API structure example	Data is in OCDS	Can end up being a box ticking exercise Publishers not thinking about use cases
2	Extract all procurement data for publishing via API in JSON	API where data can be converted to CSV or used to feed visualisations	OCDS documentation API structure example	Data may similar to OCDS but not forced fit All possible data published	Publishers lose out on OCP help with specific issues
2	SQL database queries for extracting fields and writing to JSON/CSV	JSON or CSV data can be shared via API or FTP	None	Simple process Sustainable for IT teams with fewer resources	Small number of fields Not use case focused
4	Data generated and extracted based on identified user needs	Develop visualisations / BI tools / CSV	Questions to helpdesk	Publishers focused on stakeholders needs Wide range of use cases - in/external	Can end up with something very different to OCDS

11 of 18

Why some publishers choose not to publish in OCDS?

Legal requirement

To publish all procurement data. This can also mean publishing it in the original form rather than using a data standard.

Internal decision

Internal decision to do it their own way i.e. using a design process to generate requirements for procurement system and what to publish or if they don’t like releases and records.

OCDS not valued

Publisher thinks comparing data with other countries is: (a) not really possible, (b) an overrated benefit and/or (c) not worth the additional effort.

Reluctant to change

Publisher already has a system and they don’t want to change it. Might already be very similar to OCDS.

12 of 18

What challenges remain with publishing data?

13 of 18

Non-OCDS data publication challenges

Lack of sustainability

Having a system that outputs data for publishing that can be easily maintained by IT staff.

Using the data

Mostly just storing and publishing, not using internally to improve.

Architecture decisions

Building and maintaining a data warehouse to securely store data.

Unsupportive eGP systems�These systems need to support the procurement process rather than being about data entry.

Inconsistent schemas

How to manage multiple changes to database schemas over time?

Checking data quality

Cannot use the Data Review Tool. Would at least like to do data validation.

14 of 18

Lack of focus on use cases

25%

Internal use case focus

50%

External use case focus

Those publishing OCDS did not think about specific use cases for what to publish data on - assumption that if they publish in OCDS then it would all be taken care of?

Very little sign of publishers getting end user feedback on the data.

Publishers would agree with use cases e.g. who bought what from who? How competitive are tenders, but they didn’t know if the data addressed those questions.

Internal use cases were rarely thought about, publishers needed a lot of prodding.

Only a couple of publishers were starting to think about this i.e. building BI dashboards for internal monitoring or using algorithms to identify unusual behaviour.

Connecting up more systems was desired by a few organisations e.g. linking certification systems to procurement or linking procurement to customs to better understand supply chains.

Publishers acknowledge that having solid use cases is best for getting stakeholder buy-in

15 of 18

Data quality issues are caused upstream

Value to internal staff

eGP systems and processes are not designed in a way that makes staff see it as more than just “data entry”. Leads to them doing the job poorly.

Poor UX & Validation

eGP systems are poorly designed and at best don’t prevent data validation issues and may in fact encourage them.

No quality checking tools

The Data Review Tool does not support non-OCDS publishers. Even just data validation such as checking format errors would be helpful.

Inconsistent schemas

Some publishers find inconsistent schemas hard to manage, especially if there are large numbers of edge cases.

16 of 18

What Next

How to use these insights?

17 of 18

Understand how data quality issues arise - By understanding how governments make changes to laws, procurement processes and therefore the data that is generated, you can understand how data quality issues arise.
Discover opportunities - Publishers of data and governments in particular are only starting to look at how to use open contracting data. They also don’t think current eGP systems are great. Can you help?
Potential for more data - Not all data in eGP systems get’s published. There may be opportunities to work with publishers to make more data available.

How can you use these insights?

1 of 18