Two automation suppliers offer similar controller and SCADA platforms, but their proposals allocate integration, testing and lifecycle support differently. One excludes site interfaces and source-code handover; the other includes them but assumes that the owner will supply approved recipes and test data. Comparing only the quoted total can conceal the responsibilities that determine whether the project succeeds.
Selecting a GMP automation and digital systems supplier requires a common technical scope, credible evidence of capability and transparent lifecycle assumptions. The evaluation should remain vendor-neutral and process-led, with procurement, engineering, operations, maintenance, IT and quality aligned on what the site is buying.
Prepare the buying decision before issuing the RFP
Define intended use, equipment boundaries, interfaces and operational constraints. Identify whether the procurement concerns a packaged machine, a control platform, a system integration project, MES, historian services or a combination. A supplier cannot price an undefined boundary consistently, and ambiguities usually return as change orders or unresolved site work.
Separate essential requirements from preferences and future options. Establish acceptance criteria for consequential functions and define the evidence expected from bidders. Provide relevant baseline information about installed systems and site standards while identifying uncertainties that require investigation.
[GUIDEGXP RECOMMENDATION] Include a responsibility matrix in the request for proposal. Cover process design, automation specification, infrastructure, interfaces, master data, cybersecurity, testing, qualification support, training and operational handover. Require bidders to identify exclusions and assumptions against the same matrix.
Evaluate process knowledge and integration capability
Pharmaceutical references are useful only when their relevance is understood. Ask what the supplier actually delivered, which process functions it engineered and which responsibilities remained with others. Experience installing a familiar platform is not necessarily experience designing batch recovery, material genealogy or an integrated manufacturing record.
Assess the proposed team, including key disciplines and subcontractors. Confirm who will make process-control decisions, own interfaces, manage configuration and support commissioning. Review continuity arrangements if named personnel change. A strong corporate portfolio does not establish the capability of the team assigned to this project.
Use focused technical discussions around the site's scenarios. Ask how the supplier would handle interrupted recipe transfer, historian loss, conflicting master data or recovery after a server failure. The objective is to assess engineering reasoning and ownership, not to reward a polished presentation detached from the actual process.
Normalize architecture and functional scope
Require each proposal to explain functional allocation across PLC or DCS, SCADA, historian, MES and supporting infrastructure. Identify authoritative record sources and interfaces to LIMS, ERP, warehouse or equipment systems where relevant. Confirm that the architecture meets the site's operating and recovery needs.
Compare complete configurations: hardware, licences, modules, engineering tools, databases, infrastructure services and connectivity. Ask which capabilities are standard, configured or custom developed. Clarify whether quoted limits concern tags, users, equipment, transactions, interfaces or storage, and what happens when the site expands.
Evaluate dependency and exit options. Open protocols can help interoperability while application models and proprietary libraries still create vendor dependence. Determine what the owner can export, maintain and transfer to another qualified party. A promised “open system” needs concrete deliverables and usable rights.
Review coding, configuration and documentation practices
Ask how the supplier controls source, configuration, reusable libraries and releases. Evaluate naming conventions, error handling, diagnostics, version comparison and the relationship between online code and archived baselines. The site needs to identify what is running and restore it reliably.
For standard libraries, clarify ownership, supported versions, known limitations and the process for corrections. Reuse can improve consistency, but a library defect can affect several installations. Require a method to identify affected applications and assess updates.
Define documentation as operationally useful information: architecture, functional design, interfaces, configuration, installation, testing, recovery and maintenance. Document volume is not a quality metric. A concise, accurate delivered-state package is more useful than a large generic set that does not describe the installed system.
Specify FAT, SAT and assurance support precisely
Agree what will be demonstrated before delivery and what requires the installed site environment. Define test prerequisites, representative data, expected outcomes, witness arrangements and record requirements. Include abnormal conditions and recovery where consequential, not only routine screen navigation.
Clarify who writes, reviews and approves specifications and test records, and who resolves deviations. Supplier commissioning evidence may support qualification after assessment of its quality and applicability. It should neither be rejected merely because of its title nor accepted automatically because it carries a signature.
[REGULATORY REQUIREMENT] The site remains responsible for applying the relevant GMP framework to intended use and release. Supplier claims of “GMP compliance” or “Part 11 readiness” should be translated into specific capabilities, configuration responsibilities and evidence. No platform feature removes the need to assess the delivered workflow.
Make cybersecurity and remote support contractual
Require clear responsibilities for secure configuration, supported components, vulnerability notification, patch compatibility and incident cooperation. Identify who supports operating systems, databases and third-party software. Gaps between supplier and infrastructure contracts can leave essential components without accountable maintenance.
Define the permitted remote-support model, authorization process, access scope and closure. Confirm how supplier and subcontractor identities are controlled and how consequential changes are recorded. Avoid a contract that assumes permanent unrestricted access as the only support route.
Ask how security changes will be tested and coordinated with production and quality requirements. [GUIDANCE / STANDARD] NIST SP 800-82 and relevant ISA/IEC 62443 parts can support the discussion, but a generic reference to a standard is not equivalent to evidence that the offered configuration meets the site's assessed security needs.
Clarify source-code, configuration and licence rights
List the deliverables the owner will receive: application source, controller programs, configuration databases, scripts, reports, graphics, interface definitions and build or deployment instructions as applicable. Distinguish ownership from a licence to use or modify. Procurement and legal specialists should assess the contractual rights appropriate to the project.
Identify tools and licences required to maintain the delivered system. A source-code handover is of limited value if the owner lacks the engineering environment, library dependencies or permitted access needed to use it. Define password, certificate and key handover through secure procedures without embedding secrets in general documentation.
Consider supplier failure or contract termination. Establish practical access to configurations, records and necessary support information. Escrow or other arrangements may be useful in some contexts, but their suitability depends on the software, rights and recovery needs; they are not universal requirements for every automation purchase.
Compare support by operational outcome
Distinguish response time from restoration time. A supplier can acknowledge a ticket quickly while lacking the person, spare part or authorization needed to restore service. Define support coverage, escalation, access, language, time-zone and on-site arrangements according to the plant's operating needs.
Assess spare hardware, replacement lead times and obsolescence management. Clarify which components the site should hold and how spare configurations remain compatible. A spare controller without the correct program, firmware or installation procedure may not provide the expected recovery capability.
Require notice and planning for end of support. Review upgrade paths, compatibility responsibilities and the treatment of custom code. The legacy migration article explains why lifecycle changes require functional and record assessment rather than an assumption of automatic equivalence.
Build a transparent total-cost comparison
Compare costs over an agreed planning horizon with visible assumptions. Include acquisition, engineering, integration, testing, qualification support, training, infrastructure, recurring licences, service, cybersecurity maintenance, spares and planned upgrades. Separate committed prices from estimates and optional scope.
Model credible changes such as an additional unit, a new interface, a supported platform upgrade and recovery from a significant failure. Identify the commercial triggers for additional licences or specialist services. Avoid presenting uncertain downtime estimates as precise financial facts.
Distinguish CAPEX and OPEX according to the organization's accounting approach, while keeping the engineering scope consistent. A lower initial quotation may move work into internal effort or future service charges. A higher quotation may include unnecessary functions. The comparison should expose those differences so that decision-makers can judge value rather than simply rank totals.
Use a bid matrix with gates and evidence
| Evaluation area | Evidence requested | Typical unresolved risk |
|---|---|---|
| Process and architecture fit | Reviewed scenarios, boundaries and functional allocation | Generic platform proposal without process ownership |
| Integration and records | Interface contracts, record ownership and recovery demonstration | Unassigned cross-system failures |
| Engineering lifecycle | Configuration control, delivered-state documentation and handover | Owner unable to maintain the application |
| Assurance support | Representative test records and clear FAT/SAT responsibilities | Missing evidence discovered after delivery |
| Security and service | Access model, support scope and vulnerability process | Uncontrolled remote access or unsupported dependencies |
| Commercial completeness | Itemized assumptions, exclusions and lifecycle scenarios | Low price based on omitted essential work |
Use mandatory gates for requirements that cannot be traded away. Weight other criteria according to the site's priorities and document the rationale. A high overall score should not conceal failure of an essential requirement. This matrix is an original evaluation aid, not a universal scoring system.
Run a focused technical demonstration
Provide the same bounded scenario and acceptance questions to shortlisted bidders. Include a normal operation, a relevant failure and recovery. Ask the proposed delivery team to explain the configuration, dependencies and maintenance implications. Distinguish demonstrated capability from promised future development.
Observe how much custom work is needed and whether the result can be supported by site personnel. Ask for the configuration identity and a record of findings. Demonstrations inform selection; they do not replace verification of the delivered system.
Review findings across disciplines. Operators may identify ambiguous recovery instructions, maintenance may identify unavailable diagnostics, and quality may identify incomplete records. Convert consequential findings into clarified requirements, deliverables or acceptance conditions before final commercial negotiation.
Worked example: comparing two integration proposals
An illustrative site needs a common SCADA and historian connection for several vendor skids. Bidder A offers a lower initial price but excludes interface reconciliation, master-data alignment and delivered-source handover. Bidder B includes these functions but assumes that the site supplies a verified inventory of skid versions and tags.
The team aligns both proposals against the responsibility matrix and asks each bidder to demonstrate recovery from an interrupted exchange. It prices the missing work and evaluates the site's ability to provide the assumed baseline. The comparison changes because the original totals represented different projects.
The award decision records technical strengths, accepted limitations, commercial assumptions and closure conditions. The contract assigns interface ownership and defines evidence for acceptance. This method does not predetermine which bidder should win; it makes the decision defensible against the actual scope and lifecycle needs.
Resolve exclusions before they become delivery gaps
Review phrases such as “standard documentation,” “customer network,” “validation by others” and “remote support included” against concrete deliverables. Each can hide substantial differences in scope. Ask who supplies the test environment, approved master data, infrastructure configuration and access needed to complete the work.
Clarify travel, site attendance, repeat testing after supplier defects, software renewals and support for custom interfaces. Establish how assumptions will be confirmed early and how a discovered difference will be assessed. The goal is a shared baseline that permits legitimate change while preventing foreseeable scope gaps from being treated as surprises.
Keep technical acceptance linked to usable outcomes. A delivered file set should be complete, current and accessible to the owner; a training session should cover the released configuration; a recovery deliverable should include demonstrated prerequisites. Procurement should preserve these expectations through negotiation so that commercial simplification does not remove the evidence needed for operational readiness.
Convert the award into a controlled delivery baseline
Reconcile the final contract with the technical evaluation. Ensure that negotiated exclusions have not removed essential functions and that accepted clarifications appear in the deliverables. Define how substitutions and changes will be assessed, including changes to key personnel, software versions and architecture.
Establish stage reviews, acceptance responsibilities and operational handover conditions. Confirm that training, recovery evidence, support access and configuration deliverables are available before final acceptance. Maintain unresolved items with owners and closure criteria rather than allowing them to disappear between procurement and project execution.
Begin with the automation URS and architecture method. Use the Pharma Engineering landing for the relevant equipment context and the Automation & Digital Systems hub for the complete area.
Primary references and status
Reviewed 23 September 2026: EudraLex Volume 4, including Annex 11 and Annex 15; ICH Q10; NIST SP 800-82 Revision 3; ISA/IEC 62443 series; ASTM E2500-25. Regulatory applicability, industry guidance and engineering standards remain distinct. The RFP structure, bid matrix and commercial scenarios are GuideGxP recommendations, not prescribed regulatory procurement rules.
