Procurement is something that the RefARK IoT working group does not have specialist knowledge of. However, the working group has discussed how the principles and requirements developed in the work can be used as support during procurements.

NOTE: The material developed within RefARK IoT cannot be used directly in a procurement in its raw form.

NOTE: It is assumed that the procurer has the necessary knowledge and experience to actually carry out a procurement.

NOTE: Each organisation needs to add their own organisation’s specific operational and IT requirements.

Open

RefARK IoT provides for part of the total set of requirements the procurer needs to draw up.

Basic principle for using RefARK IoT in procurement

RefARK IoT provides a structure that enables procurers to evaluate requirements fulfilment, based on the description provided by the supplier. The basic idea is illustrated in the figure below:

Open

The following could be a work process for procurement:

1. The procurer assigns a weight to each of the 10 principles, e.g. based on 100%. Example material on how procurers can think about this is available here. The weighting should be clear and transparent already at the call for tenders.

2. The procurer reviews the requirements can does the following:

   1. Decides which requirements are relevant to their organisation; each requirement is given a specific maximum possible score. The maximum score is summed per principle, based on the “Contributes to principle” column of the requirements list.

   2. Adds requirements specific to their own organisation. These can be both operational and IT requirements.

   3. The procurer defines how the submitted description will be evaluated. This can be done, for example, based on a scale of 1–5, where:

      1. 1 = “The solution description provides very unclear description of the intended solution and/or very low added value for the procurer.”

      2. 2 = “The solution description provides an unclear description of the intended solution and/or low added value for the procurer.”

      3. 3 = “The solution description provides an acceptable description of the intended solution and/or some added value for the procurer.”

      4. 4 = “The solution description provides a clear description of the intended solution and/or good added value for the procurer.”

      5. 5 = “The solution description provides a very clear description of the intended solution and/or very high added value for the procurer.”

   4. Consider describing in the tender documents how a supplier can provide a “very clear” description and “good added value”. This could be, for example

      1. “very clear description” includes all evaluation points of the respective requirement

      2. “very high added value” clearly indicates how delivery of the requirement is included in the solution. Indicate here how the supplier can obtain this assessment by clearly describing what is included in the solution, what is additional, what requirements manual work, etc.

3. The procurer goes through what “shall” requirements need to be drawn up for the solution. RefARK IoT only provides support in assessing a supplier’s solution. The evaluation criteria for the respective requirement can be a starting point for which requirements the procurer may need to convert into “shall” requirements.

4. During actual evaluation of the solution, it may be useful to have one or more persons/working groups performing the evaluation. In such case, remember to document each individual assessment, as well as to describe in the procurement documents how the assessment will be performed, e.g. average of x persons’ assessment or consensus from a group discussion. The aim of this is to create clear transparency in the work, and to have a clear and objective description of the assessment process in case any supplier appeals the decision.

Contract for procurement with RefARK IoT

The procurer needs to develop appropriate contracts for the procurement. Keep in mind that the contract needs to cover all phases of the contract period, the implementation phase, the management phase, and the concluding phase. There are often different contract designs for projects, management and consultancy hours. The contract needs to address all these aspects. For IoT systems, more flexibility in the contractual situation may be required as there are often multiple suppliers in the whole IoT system. It is good practice for the contract text to be sent out with the procurement documents.

Something the RefARK IoT working group advocates is to note in the contract and procurement texts that the answers to various questions provided by the supplier in their tender should become part of the contract. For example, if the supplier states in the description that some component is included or works in a certain way, this makes it possible to define it as part of the supplier’s delivery and thus the contract.

RefARK IoT in functional procurement

In functional procurement using IoT, the procurer needs to follow steps 1–4 above. The procurer also needs to define the relationship between price and each quality requirement. Keep in mind that “shall” requirements cannot be evaluated. In addition, the procurer needs to develop appropriate contracts for the procurement.

RefARK IoT in negotiated procedure

In a negotiated procedure, RefARK IoT can be used as the basis for the negotiation, i.e. the supplier must describe its solution in the negotiations and then detail how it works.

How to build good procurement requirements

How a good procurement requirement is built depends very much on the type of procurement chosen for the procurement in question.

A good requirement meets, for example, the following:

• It is clear what the supplier is to deliver, and in what way

• It is clear how the procurer can/will verify that delivery has taken place

• It is clear who will be able to perform the function in question

• The procurer has a clear picture of what and how the supplier will deliver