In June, I translated a Petrobras RFI from Portuguese. O-PAS appeared throughout the document in specification and conformance requirements.
One question kept coming to mind as I read it:
If this landed on an EPC estimator’s desk tomorrow, could the team price it with confidence?
For many EPC organisations, I think the answer would be difficult.
Estimating a conventional DCS project is familiar territory. The team understands the controller count, I/O, engineering hours, cabinets, graphics, FAT, commissioning and supplier services. Decades of projects have created estimating models around that scope.
O-PAS changes some of those boundaries.
A specification may require application portability, O-PAS conformance, multiple suppliers and defined integration responsibilities. Each requirement sounds manageable on its own. The estimating problem appears when nobody has converted those words into engineering work.
Who integrates the components? Who proves conformance? Which party owns the runtime? What must be demonstrated during FAT? What happens when applications from one supplier execute in an environment provided by another?
If those answers are unclear, the EPC still has to submit a number.
The uncertainty usually ends up in the price.
The estimator adds contingency, includes specialist subcontract support, makes assumptions that later become exclusions, or decides the opportunity carries more risk than the organisation wants to accept. The owner may then conclude that open architecture is expensive when part of the premium is simply the cost of unclear scope.
There is a straightforward test for any EPC that expects to bid O-PAS work.
Take one requirement from an RFQ and force the estimating team to translate it into four columns:
Scope | Responsibility | Evidence | Cost
For example, if the requirement says that a control application must be portable, what engineering work is included? Who is accountable for demonstrating portability? What evidence is required at FAT? How many engineering and test hours belong in the estimate?
Do the same for conformance, integration and lifecycle replacement.
Any requirement that cannot move cleanly through those four columns is an estimating risk.
A mature O-PAS bid should look different. The estimator can trace each requirement to a defined activity, accountable party, acceptance test and cost allowance. The FAT plan reflects the architecture before the purchase order is issued. Suppliers understand their boundaries, and the EPC knows where integration effort belongs.
That is when an O-PAS project becomes commercially manageable.
Owner-operators also have a role here. An RFQ filled with broad requirements but weak acceptance criteria simply transfers uncertainty downstream. The EPC will price that uncertainty, and the owner will eventually pay for it.
For teams building this capability, the free Introduction to Open Process Automation course provides a practical introduction to the architecture and terminology before those requirements reach an estimator.
If an O-PAS RFQ arrived at your organisation tomorrow, where would the biggest estimating gap appear: scope definition, integration responsibility, conformance evidence, or FAT planning?
Send me one of the four through the Contact page and I’ll tell you the first question I would ask before putting a price against it.