Open timgdavies opened 7 years ago
Thanks a lot for the exhaustive overview. I don't have an opinion on the modeling options above (yet?), but please find below a few thoughts.
Concerning:
OCDS is a standard for transparent publication of contracting information: the core standard is not intended to capture the full business logic of specific contracting processes (although it may be extended, or building blocks re-used, in this way);
This is crucial. What do do we really need for transparent publication, and what can we ignore?
What definitely needs to be covered is what you need for submitting bids (i.e. the first round) and the results. What is between is a trade-off between more information for transparency and added complexity. In the EU, talking about multiple stage procedures, we do not really cover any of the intermediary steps - only the first stage and the result. (This could be phrased as an Option 0 above - we simply don't model this, because it's too complex.)
I'm not sure how much should be covered in general, but for example in case of competitive dialogues, I don't think that modeling all the intermediate stages adds much.
Concerning:
"We believe that relatedProcess still has a role in some forms of framework, particularly cases where one agency establishes the framework, and other agencies are then running their own independent contracting processes to buy from that framework."
and
Based on the discussion in 310 we believe that it remains appropriate in some cases to have competitive call-offs from a framework modelled using separate contracting processes and relatedProcess.
1) Besides disagreeing for the general reasons mentioned in #371, I think there is in fact a threat of inconsistency if you applied the multiple process approach only to frameworks.
For example, a restricted procedure with five lots is modeled as a single process. However, an open procedure with a framework agreement and five competitive call offs is, I would argue, quite similar, but would be modeled as 6 processes. The similarities: in both instances we start with a stage of "selecting a limited number of candidates" (even though the criteria differ); followed by five instances of "companies compete on award criteria for a "real" contract"; and, in both cases, there can be the same or different companies in each lot/call-off. Essentially, to make a brave analogy, I would argue that competitive call-offs are like lots (for call-offs you compete for the delivery of one thing at five different times, for lots you compete for five different things at one time), and so should involve the same number of processes.
2) I wouldn't mix up the two reasons for multiple processes that you mention above ("other agencies" and "competitive call offs").
Concerning other agencies, in EU procurement legislation, there are two different approaches to contracts (and in particular framework agreements) awarded by central purchasing bodies (a type of purchase by another agency). One is that buyers use framework agreements etc. established by central purchasing bodies (CPBs). The other one is that a CPB buys something and then transfers it to other public buyers.
In general, I would say the first option could be met by having the "buyer" section specified in the "contract" section (perhaps if it is different than the one in the buyer section). In other words, the procuringEntity runs the procedure, the Buyer is then per contract.
For the second option, in the EU, this is generally not public procurement. They are simply contracts (?) between public bodies. Is this type of relationship in the scope of OCDS?
Concerning:
Applications will use the contents of the award block to analyse firms in receipt of contracts, and the value of those contracts;
If we are thinking long-term, this may change - e.g. contractor could be moved to the contract section, not award, as discussed in #249
Finally, to add a twist, we've discussed this whole issue with @isarosa and, in fact, the Portuguese BASE models two stage procedures, call-offs etc. as separate (parent-child) processes - possibly similarly to what you proposed originally. The main reason is that while planning and implementation stages are not applicable for both of these processes (and winner and value for the contract stage mean something a bit different), the majority of e-procurement stages are the same: eNotification, eAccess, eSubmission, eEvaluation, eAward, (partially Contract). Going more into the actual experience of BASE could help resolve this issue.
(...perhaps both approaches can work, and it's mainly a question of which terminology is more intuitive - while ensuring consistency...)
Relevant to EU forms.
Relevant comments in #371 start from: https://github.com/open-contracting/standard/issues/371#issuecomment-292117603
Note: https://github.com/eForms/eForms/issues/251#issuecomment-473663395
In eForms, the procedure/lot that "uses" a framework [to award contracts] is the same one that "establishes" it (only at a different time, i.e. in a later notice)
The OCDS 1.1 guidance models the establishment of the framework agreement as one procedure (one OCID) and each mini-competition as a new procedure (new OCID). However, mini-competitions are part of the same procedure as the establishment of the framework agreement, in EU law and elsewhere. We therefore need a solution that represents these under one OCID, to respect the definition of 'contracting process' #866.
This issue (below) and issue #906 discuss specific proposals.
Additional problems with the OCDS 1.1 guidance are that:
contracts
. This seems bizarre, especially if the framework agreement promises a minimum volume of orders.tender
block to describe the items to be procured. This block has the semantics of the 'first stage' of a procedure, but mini-competitions occur in a second stage. As such, the semantics are incorrect.Responding to the above, now that I'm looking at the EU forms yet again, I think:
- Two-stage processes pre-qualification shorlisting, and then a full invitation to tender
I don't see a problem with option 2 (new block adjacent to tender
). Regarding:
applications will need to look in
qualification
as well astender
to find opportunities to communicate to users
To clarify, the issue with the proposed model is that qualification
is the block that describes the request to participate, which is the first stage and therefore of interest for finding opportunities.
The issue is easily resolved if the definition of tender
is adjusted to mean "first stage" in all cases. Right now the tender
field is described as:
The activities undertaken in order to enter into a contract.
This gives sufficient latitude to adjust semantics. The Tender
definition is described as:
Data regarding tender process - publicly inviting prospective contractors to submit bids for evaluation and selecting a winner or winners.
This gives less latitude. However, these semantics are already widely ignored if interpreted strictly, such as for framework agreements.
If tender
means "first stage," it remains the single place for finding opportunities (in this case, the request to participate), eliminating one of two complaints with this approach (the other is addressed below). We can then use a secondStage
block for the request for tender.
- Competitive dialogues - which may have repeated rounds
I have yet to see data about these rounds. For now, we can pursue @JachymHercher's option 0. In future, I don't see an issue with secondStage
as above being an array to contain each round.
- Processes where the initial tender does not lead to an award, and so a second call for proposals is made
Some contexts consider this scenario to be one contracting process, others consider it to be two. For OCDS to be consistent, we ought to choose one model. My preference is two.
This is also consistent with the concept that tender
means "first stage". If you have a second call for proposals as in the example, you are having a "first stage" for a second time.
- Framework contracts with mini-competitions
It seems consistent with the above to use the proposed secondStage
array. Having a different model simply because a framework agreement reopens competition seems arbitrary. Having a contracting process (framework agreement set-up) with no possibility of containing contracts
seems bizarre. Having a "first stage" (in a mini-competition) that is in fact a second stage and that is closed to competition (even though it is technically a 'selective' procedure) seems to deeply break the desirable semantics of OCDS.
My recommendation would be to work on a proposal for a secondStage
extension, which would likely be merged into OCDS, considering only open procedures and direct awards have one stage.
We would need to:
framework
code in relatedProcess.csv
This proposal, in short, is like option 1 (changing tender
into an array). However, option 1 loses the distinction between first and second stage. Preserving the distinction is important, as it prevents implementers from accidentally putting multiple first stages into an array.
@JachymHercher's 'brave analogy' between lots and call-offs seems appropriate: lots are the way to multiply components of a first stage. Having a secondStage
array would allow OCDS to multiply components of a second stage (dialogue rounds, mini-competitions, etc.).
Second Stage extension drafted here https://gitlab.com/dncp-opendata/ocds_secondStage_extension
And some comments from discussions/retreats:
cc @jpmckinney
@PaulBoroday The extension above is the proposal for OCDS 1.2 (i.e. backwards-compatible with OCDS 1.1). In short, it adds a secondStage
object, which has fields for the candidates
who were qualified to advance to the second stage, and for the invitations
(e.g. requests for tender) that occur at the second stage. The Invitation
object is very similar to the Tender
object with only a few differences. The extension is intended to support any two-stage procedure, including framework agreements. (You can ignore some of the Paraguay-specific fields in the extension like simultaneousSupply
; these fields are not relevant to the modelling for framework agreements.)
Adding resources to review/consider:
Hi @jpmckinney ! How it is now considering that we have secondStage in the EU extension with a bit different logic?
The EU extension is just about describing the second-stage from the perspective of the first stage (e.g. min/max candidates): https://extensions.open-contracting.org/en/extensions/secondStageDescription/master/ The EU legislation / process doesn't describe the second-stage itself (the specific invitations to bid); it only announces the awards from any mini-competitions.
The DNCP extension above is instead about modelling the second-stage itself (the invitations, the bidders, etc.).
UNCITRAL glossary defines:
ID | Term | Definition | Reference |
---|---|---|---|
74 | Second-stage competition | A stage in closed framework agreements with more than one supplier or contractor and in open framework agreements through which certain terms and conditions of the procurement that cannot be established with sufficient precision when the framework agreement is concluded are established or refined through a competition between or among suppliers or contractors parties to the framework agreement. For the explanation of the terms “closed framework agreement”, “open framework agreement”, “procurement” and “framework agreement”, see ## 10, 48, 58 and 31 above. For the explanation of the term “supplier or contractor”, see # 85 below. | N/A |
88 | Two-stage tendering | A method of procurement and one of the forms of tendering, which main distinct feature is two-stage process: - the first stage involves the discussion between the procuring entity and suppliers or contractors of various aspects of their initial tenders excluding price, in order to refine aspects of the description of the subject matter of the procurement and to formulate them with the detail required under article 10 of the Model Law; and - the second stage involves submission of final tenders with price in response to the revised set of terms and conditions of the procurement, examination and evaluation of final tenders and award of the procurement contract. For the explanation of the terms “method of procurement”, “procuring entity”, “supplier or contractor”, “initial tenders”, “description of the subject matter of the procurement”, “procurement”, “examination”, “evaluation” and “award of a procurement contract”, see ## 44, 62, 85, 40, 18, 58, 29, 27 and 5 above. | two-stage bidding procedure (the World Bank procurement guidelines) |
EBRD glossary lists:
UNCITRAL Model Law Terms | Description Notes | Others in use or similar Terms |
---|---|---|
Second stage competition | Competition to award contracts under a framework agreement | Call off (EU) |
The World Bank recently published a Guidebook for Setting-up and Operating Framework Agreements. From a quick scan, it mostly references familiar sources: the EU Directives, the UNCITRAL model law and The Law and Economics of Framework Agreements book. However, it contains seven country case-studies which may be of interest.
This issue builds on the review comments in #371, and discussions with the technical team and implementers, to set out an approach for OCDS 1.1 for handling multi-stage contracting processes, and sets a direction towards 2.0.
Current situation
The concept of a contracting process is central to OCDS. By bringing together multiple releases of data and information related to a single contracting process, OCDS enables citizens, companies and governments to get a clearer view of contracting activities.
The standard defines a contracting process as:
Each contracting process is identified by an Open Contracting ID (
ocid
).The standard currently contains a single
tender
block, and then arrays of one or moreaward
andcontract
(and nested within contract,implementation
) blocks.This pattern, of a single
tender
block, was developed to avoid publication mistakes where tenders from different contracting processes could end up mixed together under the sameocid
.Limitations
The current model has major limitations in the case of contracting processes where multiple tender notices or solicitations are issued. This includes:
Initial proposal and review
In proposals for OCDS 1.1, we sought to address this by creating a
relatedProcess
block that could link two or more contracting processes. This would allow, for example, one contracting process to contain the pre-qualification tender, and award onto a shorlist, and a second, related process, to contain the invitation to qualified bidders and the final award of the contract.However, peer-review feedback noted that this breaks the idea of bringing together all information about a contracting process under a single
ocid
.The reviewer rejected the introduction of
relatedProcess
to deal with cases of frameworks, pre-qualification, competitive dialogue and other multi-stage processes.We agree with the reviewer that the handling of pre-qualification and other multi-stage processes requires attention.
We believe that
relatedProcess
still has a role in some forms of framework, particularly cases where one agency establishes the framework, and other agencies are then running their own independent contracting processes to buy from that framework.Alternative models and their implications
In this section we scope out alternative approaches to allow us to represent multi-stage contracting processes. This is guided by:
And based on a number of assumptions:
tender
block to advertise available opportunities;award
block to analyse firms in receipt of contracts, and the value of those contracts;tender
block, many applications will not be release-aware, and so will only look at the latest state of thetender
.tender
block of a contracting process to, at one time represent the 'qualification stage' of a process, and then at a later time, to change to represent the 'tender stage' of the process.Option (1): Convert tender into an array
Tender could become an array: possibly renamed to 'initiation' or 'solicitation', but using the same structure as the current
Tender
object. In this case:Tender
object in the array would have atype
to indicate whether it is a 'preQualification', 'tender' or some other solicitation as part of a single contracting process;Award
andBid
(where the bid extesion is used) would need to have atenderID
property in order to make it clear which tender they related to (e.g. to distinguish awarding a supplier a place on the shortlist, from awarding them the contract); orawards
), and 'qualification' block based onbids
would need to be introduced for qualified suppliers to be listedrelatedProcess
cross-reference would need to be able to point to specifictender.id
This approach would not be backwards compatible, and so would need to be included in version 2.0, rather than 1.1.
Option (2): Create a distinct property for qualification
An additional
qualification
property could be added parallel totender
re-using theTender
object to represent the pre-qualification call, withtender
then used for the call for proposals.This approach does not change the semantics or structure of existing properties, so could be included in 1.1.
It works for two-stage processes, but does not work for processes with more than two stages.
It means that applications will need to look in
qualification
as well astender
to find opportunities to communicate to users.The separate
qualification
object approach is taken in the PPP Implementation Profile of OCDS, although in this case, there is a lesser requirement that applications be able to advertise thequalification
opportunity - as PPPs are lower volume - and the use-cases for the PPP Implementation Profile do not cover advertising opportunities.Option (3): Re-use tender block for each stage
We would not change the schema, but would instead provide guidance that the
tender
object should be updated to reflect the most recent solicitation, wheter that was a qualification related notice, a tender, or a mini-competition.The history of past states would be available from the versionedRelease and by looking at past releases.
However, this approach would:
(a) Make it difficult to see all the stages of a contracting process at once; (b) Risk creating a confused 'record' - as if the first qualification entry in a tender contains, for example, a set of items which are later removed from the full tender, and the subsequent tender does not 'null' these to remove them - the record will show a tender that included these items;
For this reason - we cannot recommend this option.
Related process for frameworks with competition
Based on the discussion in 310 we believe that it remains appropriate in some cases to have competitive call-offs from a framework modelled using separate contracting processes and
relatedProcess
.This is summarised in the table below:
tender/status
should be active for the lifetime of the dynamic purchasing system withtender/tenderPeriod
andtender/awardPeriod
reflecting that suppliers can join the DPS at any time. Multiple selective or limited processes to represent competitions between suppliers on the DPS for individual contracts, linked to the DPS via relatedProcess (see #371 ).In the event that option (1) above is adopted, it would be possible for the mini-competitions that form part of a framework to be represented as part of a single contracting process.
However, there are cases where this is not appropriate (for example, when the framework is set up by a national agency, and assigned a process identifier in their national systems; and the competitive call-offs are carried out by local agencies, given distincy process identifiers in the local systems): so a choice would need to be made about whether to allow competitive frameworks to be modelled in those two different ways, or to restrict modelling of competitive framework call offs to the
relatedProcess
model.Suggested actions
relatedProcess
codelist;Tender
objects, rather than a singletender
entry;relatedProcess
to specifically reference a tender.id;