Common requirement set
Use the same owner specification, O-PAS basis, clarifications and accepted interpretations.
Home › O-PAS Supplier Bid Evaluation and Technical Comparison
Bid Evaluation · Technical Comparison · Product Evidence · Integration Risk · Award Basis
O-PAS supplier bid evaluation and technical comparison Compare the delivered system, not just the product list
A practical guide for owner and EPC teams normalizing and evaluating competing O-PAS supplier bids across product evidence, architecture fit, applications, interfaces, integration, verification, lifecycle support and commercial scope.
The short answer
An O-PAS supplier evaluation should compare each offer against the same project requirements and delivery boundaries before comparing price.
Verify the exact products and versions offered, applicable product conformance evidence, architecture-role fit, IEC 61131 application and runtime implications, interface maturity, proprietary dependencies, integration effort, cybersecurity, lifecycle support, exceptions, supplier test commitments and correction obligations. Product conformance supports product selection; it does not by itself prove system interoperability or project acceptance.
01 · Evaluation basis
Freeze the comparison basis before scoring suppliers
Every bidder should be evaluated against the same dated project requirements, architecture assumptions, quantities, interfaces, application basis, verification scope and lifecycle obligations.
Common role definition
Compare products against the same required architecture roles and project boundaries.
Common scope quantities
Normalize products, interfaces, applications, licenses, supplier services and test attendance.
Common evidence basis
Apply the same product, interoperability and project acceptance expectations.
Common operating horizon
Compare support, updates, replacement, tools, rights and engineering assets over the required lifecycle.
Common disposition method
Record deviations, assumptions and alternatives rather than hiding them inside scores.
Evaluation stop condition: suppliers are being ranked on total price before the team has normalized what each supplier actually included, excluded, assumed and committed to prove.
02 · Compliance matrix
Evaluate requirement by requirement
A useful matrix records evidence and residual project work, not simply compliant/noncompliant.
| Field | What to record |
|---|---|
| Requirement ID | Traceable owner specification, O-PAS or project requirement. |
| Supplier response | Comply, partial, exception, alternative, not applicable or clarification required. |
| Offered item | Exact product, version, service, application or deliverable satisfying the requirement. |
| Evidence | Certificate/register record, data sheet, design response, demonstration, test or contractual commitment. |
| Limitation | Conditions, dependencies, proprietary elements, exclusions and unresolved interpretation. |
| Project gap | Remaining configuration, integration, engineering, test or lifecycle work. |
| Disposition | Accept, clarify, condition award, reject, price adjustment or project action. |
Use the O-PAS Procurement Specification Checklist as the upstream requirement structure.
03 · Product conformance evidence
Verify the exact offered product, version and scope
Do not score a supplier on a family-level statement when the project will purchase a specific product and version.
Exact product
Manufacturer, product, version, edition/profile basis and offered configuration.
Authoritative record
Certificate or register identifier, status, date and scope where applicable.
Certified boundary
Optional functions, exclusions, dependencies and project requirements outside evaluated scope.
Lifecycle position
Support term, update path and effect of future versions on the evidence basis.
Required companions
Hardware, software, services, tools, libraries and licenses needed for the offered capability.
Remaining proof
Integration, configuration, interoperability, functional and project acceptance work still required.
Use the CSI O-PAS Conformance Certification Tracker and verify final claims against authoritative certification records.
04 · Architecture fit
Evaluate the product in the role the project needs
A conformant product can still be a poor fit if it introduces dependencies, limits owner control or shifts integration work elsewhere.
| Dimension | Evaluation questions |
|---|---|
| Role fit | Does the offer satisfy the required architecture role, capacity, environment and failure behavior? |
| Boundary fit | Does it expose the information, commands, state, quality and diagnostics the project requires? |
| System services | How does it participate in identity, time, monitoring, configuration, backup and recovery? |
| Owner control | What tools, licenses, configuration, source and documentation remain under owner control? |
| Replacement boundary | Can the product later be substituted without reconstructing undocumented dependencies? |
| Proprietary dependencies | Which required capabilities depend on supplier-specific tools, services or companion products? |
Use the O-PAS Architecture and Component Roles Guide for the project role definition.
05 · IEC 61131 application implications
Compare what each offer means for owner control applications
Execution basis
Supported IEC 61131 features, runtime versions, resource assumptions and application allocation.
Dependencies
Required libraries, supplier-specific functions, versions and source availability.
Toolchain
Build, configuration, deployment, licensing and owner access requirements.
Existing applications
Conversion, re-engineering, functional equivalence and regression implications.
Future movement
What can be redeployed, what requires adaptation and what evidence supports the claim?
Owner assets
Source, libraries, documentation, build instructions, deployment packages and test records.
Use the O-PAS Application Portability Guide to evaluate application and runtime dependencies consistently.
06 · Interface maturity
Compare integration evidence, not interface claims
| Position | Evidence to seek | Project consequence |
|---|---|---|
| Established | Same or materially similar supplier combination previously integrated with repeatable test evidence. | Lower discovery and correction allowance. |
| Configured | Known capability requiring project information mapping, security or configuration. | Normal engineering and project verification. |
| First-of-kind | No representative evidence for the offered combination or use case. | Prototype, supplier participation, additional correction and schedule risk. |
| Legacy-dependent | Requires gateway or retained-system behavior outside the offered product scope. | Discovery, mapping and site validation exposure. |
“Supports the interface” is not an integration estimate
Record the exact boundary, prior evidence, configuration work, supplier participation, test method and correction obligation.
Use the Interface Definition and Boundary Management Guide →07 · Integration effort
Normalize the engineering work each supplier leaves to the project
A lower product price can create a higher installed cost if more architecture, configuration, cross-supplier diagnosis or verification remains with the EPC or owner.
| Work | Supplier A/B comparison should identify |
|---|---|
| Configuration | Included engineering, required owner/EPC inputs, tools and deliverables. |
| Interface engineering | Definition, mapping, configuration, diagnostic and documentation responsibilities. |
| Environment support | Supplier attendance, remote support, setup, releases and troubleshooting. |
| Correction | Response obligation, root-cause support, remediation ownership and included retest cycles. |
| Project controls | Submittals, meetings, technical queries, schedule inputs and change support. |
| Handover | Source, configuration, documentation, training, support records and lifecycle evidence. |
08 · Cybersecurity and lifecycle
Compare the operating burden after startup
Identity and hardening
Configuration, certificate, access, logging and owner integration requirements.
Patch position
Notification, qualification, compatibility, rollback and support obligations.
Service model
Coverage, response, escalation, diagnostics and cross-supplier cooperation.
Continuity
Replacement availability, configuration readiness and replenishment.
Lifecycle horizon
Support term, withdrawal notice and technology-refresh path.
Owner independence
Data, configuration, source, license and cooperation required to change supplier later.
Use the O-PAS Multi-Vendor Operations and Support Model Guide to compare day-two supplier obligations.
09 · Test and correction commitments
Evaluate what the supplier commits to prove
| Commitment | Comparison basis |
|---|---|
| Product evidence | Exact records supplied and any gaps requiring project demonstration. |
| Integration environment | Attendance, equipment, licenses, diagnostics and release support. |
| Interoperability tests | Scenarios supported, expected behavior and supplier witness obligations. |
| Failure/recovery | Participation in loss, degraded operation, restart, restoration and resilience scenarios. |
| Correction | Included cycles, response time, remediation obligation and retest support. |
| Site acceptance | Site attendance, correction, stabilization and final evidence support. |
Use the O-PAS FAT and Interoperability Testing Guide to normalize verification commitments.
10 · Exceptions and deviations
Do not let a score hide a material exception
Technical exceptions should remain visible through evaluation, negotiation and award. A weighted score is a summary, not a substitute for disposition.
State the gap
Identify the exact requirement and supplier position.
Assess project effect
Architecture, integration, application, test, lifecycle, cost and schedule consequences.
Close explicitly
Accept, reject, negotiate alternative, condition award or transfer work to another party.
Use the O-PAS Bid Clarifications and Technical Exceptions Guide to maintain traceable bidder positions.
11 · Commercial normalization
Compare evaluated cost, not quoted total
Add or identify the project work required to place each offer on the same scope basis.
| Normalize | Typical adjustment |
|---|---|
| Missing engineering | Add EPC/owner effort for configuration, interfaces, applications or documentation excluded by the supplier. |
| Tools and licenses | Add required engineering, runtime, development, support and renewal costs. |
| Integration support | Add supplier attendance, travel, remote support and diagnostic participation. |
| Test/correction | Add uncovered test cycles, remediation, retest and schedule exposure. |
| Lifecycle | Identify support, spares, updates, training and replacement obligations not included. |
| Exceptions | Price accepted project work created by supplier deviations where practical. |
Commercial rule: do not convert a material technical uncertainty into a hidden arithmetic adjustment. Keep unresolved risk visible alongside the normalized cost.
12 · Scoring and evidence
Score only after the evidence is visible
If the project uses weighted scoring, define the criteria and evidence standard before opening commercial bids. Keep pass/fail requirements and material exceptions outside any averaging mechanism that could conceal them.
| Criterion | Evidence-based evaluation |
|---|---|
| Requirements | Degree of compliance plus quality and traceability of supporting evidence. |
| Architecture | Fit to required role and effect on owner control, dependencies and replacement boundaries. |
| Integration | Demonstrated maturity, remaining project effort and correction commitments. |
| Applications | IEC 61131 runtime, toolchain, portability, migration and owner-asset implications. |
| Lifecycle | Support, updates, spares, obsolescence, replacement and exit position. |
| Commercial | Normalized scope and cost after technical evaluation, not raw quoted total. |
13 · Award recommendation
Document why the selected offer fits the project
Confirm mandatory requirements
Identify pass/fail requirements and any approved deviations.
Verify offered evidence
Record exact products, versions, product evidence and remaining project gaps.
Reconcile technical scope
Normalize architecture, applications, interfaces, integration, test and lifecycle obligations.
Resolve material exceptions
Close or condition deviations before they disappear into contract language.
Normalize commercial scope
Compare evaluated cost and identify residual cost/schedule risk separately.
Record award conditions
Carry clarifications, commitments, evidence and open obligations into the contract.
Final evaluation question: could the project team reconstruct why this supplier was selected and exactly which technical commitments, evidence, exceptions and lifecycle obligations were part of the award? If not, the evaluation record is incomplete.
14 · Connected guidance
Connect supplier evaluation to the complete procurement chain
RFQ
Procurement Specification
Define comparable requirements before bids arrive.
ClarifyBid Clarifications
Resolve ambiguity and preserve bidder exceptions.
EvidenceCertification Tracker
Check exact product evidence.
ScopeResponsibility Matrix
Normalize delivery and correction accountability.
CostProject Estimating
Price project work left outside supplier scope.
ExecutionO-PAS for EPCs
Connect award decisions to project execution.
Frequently asked questions
O-PAS supplier bid evaluation questions
How should O-PAS supplier bids be compared?
Evaluate every offer against the same project requirements, architecture roles, quantities, application basis, interface definitions, verification requirements and lifecycle obligations, then normalize excluded project work before comparing commercial scope.
Does O-PAS product conformance make two products technically equivalent?
No. Product conformance evidence addresses the evaluated requirements and scope. Products can differ in architecture fit, dependencies, interfaces, IEC 61131 application implications, engineering workflow, lifecycle support and project integration effort.
How should proprietary dependencies affect evaluation?
Identify required supplier-specific tools, libraries, services, companion products, licenses and support dependencies, then assess their effect on owner control, integration, lifecycle cost and future replacement.
Should technical and commercial evaluation be separated?
Technical scope should be normalized before raw price is treated as comparable. Commercial evaluation should then account for missing engineering, tools, integration support, testing, lifecycle scope and accepted technical exceptions.
Can a weighted score hide an important technical gap?
Yes. Mandatory requirements and material exceptions should remain explicit rather than being averaged away by strong scores elsewhere. Scoring should summarize evidence, not replace technical disposition.
How does CSI support O-PAS supplier evaluation?
CSI helps owners and EPCs build evaluation matrices, verify product evidence, compare architecture and application implications, normalize interface and integration scope, assess lifecycle obligations and document technical award recommendations.
Before quoted price becomes the comparison
Normalize the technical scope behind every O-PAS bid
CSI can help owner and EPC teams verify product evidence, compare architecture and integration implications, normalize supplier scope and document a defensible technical award basis.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a procurement and project-planning aid and does not imply endorsement by The Open Group. The applicable owner specification, bidder submissions, clarifications, negotiated contract, current O-PAS Standard and current certification records govern the project.