Conceptual Modeling of a Procurement Process: Case study of RFP for Public Key Infrastructure

Procurement refers to a process resulting in delivery of goods or services within a set time period. The process includes aspects of purchasing, specifications to be met, and solicitation notifications as in the case of Request For Proposals (RFPs). Typically such an RFP is described in a verbal ad hoc fashion, in English, with tables and graphs, resulting in imprecise specifications of requirements. It has been proposed that BPMN diagrams be used to specify requirements to be included in RFP. This paper is a merger of three topics: (i) Procurement development with a focus on operational specification of RFP, (ii) Public key infrastructure (PKI) as an RFP subject, and (iii) Conceptual modeling that produces a diagram as a supplement to an RFP to clarify requirements more precisely than traditional tools such as natural language, tables, and ad hoc graphs.

💡 Research Summary

The paper addresses the persistent problem that traditional Request for Proposals (RFPs) are usually written in free‑form natural language, supplemented by ad‑hoc tables and simple graphs. Such unstructured specifications often lead to ambiguous requirements, duplicated or missing clauses, and costly misunderstandings between procurement officials and technical suppliers. To remedy this, the authors propose a concept‑driven approach that uses Business Process Model and Notation (BPMN) diagrams as a formal supplement to the RFP document.

The study is organized around three intertwined themes. First, it outlines the typical procurement lifecycle—requirement elicitation, RFP authoring, supplier evaluation, and contract award—and highlights the points where imprecision most often causes trouble. Second, it selects Public Key Infrastructure (PKI) as a concrete, technically complex subject for an RFP, because PKI projects involve a mixture of functional elements (certificate issuance, revocation, key rollover, trust‑chain validation) and non‑functional constraints (availability, scalability, regulatory compliance such as FIPS or eIDAS). Third, it demonstrates how a BPMN model can capture both the procedural flow and the data artifacts that constitute a PKI deployment.

In the modeling phase, the authors first extract a comprehensive list of PKI requirements through literature review and interviews with security architects. Functional requirements are mapped to BPMN tasks (e.g., “Receive certificate request”, “Validate request”, “Generate certificate”), while decision points become exclusive gateways that split the flow into normal and exception branches (e.g., “Request valid?”). Data objects such as “Certificate”, “Key Pair”, and “Audit Log” are attached to tasks, making the information exchange explicit. Time‑based events model periodic activities like key rollover, and error events capture scenarios such as “Certificate revocation failure” or “Key compromise detection”. The resulting diagram is not merely a visual aid; it can be exported to executable specifications (BPEL, XML, JSON) that feed directly into automated compliance checking tools.

Key insights emerging from this exercise include: (1) BPMN provides a shared, semi‑formal language that bridges the gap between business‑oriented procurement staff and technically oriented vendors; (2) embedding exception flows in the model forces the RFP author to anticipate and document edge cases that are usually omitted in narrative text; (3) the explicit representation of data objects enables the generation of a standardized annex that can be referenced verbatim in the contract, reducing the risk of divergent interpretations; and (4) the visual nature of the diagram supports rapid stakeholder review, allowing non‑technical participants to grasp complex security processes at a glance.

The authors also acknowledge limitations. BPMN excels at describing process logic but does not capture low‑level architectural details such as protocol stacks, API signatures, or cryptographic algorithm parameters. For those aspects, supplementary UML sequence or component diagrams are recommended. Moreover, the initial effort to train staff, acquire modeling tools, and produce the BPMN artifacts represents an upfront cost. However, the paper argues that this investment is offset by downstream savings: fewer contract amendments, reduced legal disputes, shorter evaluation cycles, and higher quality deliverables.

In conclusion, the paper demonstrates that a BPMN‑based conceptual model, when attached to an RFP for a PKI solution, significantly improves requirement clarity, verification capability, and overall procurement efficiency. The approach aligns with broader trends toward digitizing and standardizing procurement workflows and is readily extensible to other complex IT services beyond PKI.