Automation vendor selection in Australia. Integrator or OEM-direct, and how to choose well.

Integrator or OEM-direct.

Have you ever bought a piece of equipment expecting plug-and-play and ended up paying for integration twice?

OEM-direct works when the project is mostly the OEM's equipment with minimal integration to the rest of the plant: a standalone packaging cell, a single new line from one supplier, a turnkey skid where the OEM owns the full scope. The OEM has every incentive to make their own equipment look good and a straightforward technical model: deliver, commission, train, walk away.

Integrator-delivered works when the project requires platform-independent integration across multiple OEM contributions, when the customer wants a single accountable party for the controls and integration scope, or when the project is a brownfield modification touching multiple existing systems. The integrator's job is to make the whole work, not to sell the equipment. The same incentive structure applies; the scope of "the whole" is larger.

The decision is rarely cost-driven. On equivalent scope, the two models often land within a single-digit percentage of each other. The decision is accountability: who is responsible when the wrapper, the labeller, and the case packer do not agree on a state transition at 02:00. OEM-direct deals with this through finger-pointing between OEMs; integrator-delivered deals with this through a single contract that owns the seam.

Writing a fair RFP.

An RFP is fair when every responder can read it and arrive at a comparable quote. Quotes that arrive vary by ten to thirty percent are responding to different RFPs in their heads.

Four parts that consistently work.

• A scope statement bounded by what is in and out. Specific about the equipment, the integration handshakes, the existing systems that must continue to operate, the commissioning expectations, and the warranty period. The single most-revised section during the RFP draft cycle.
• Functional requirements that specify what the system must do, not how. "The system shall reject any pack with a date code grade below C" is functional. "The system shall use a Cognex DataMan 380 with strobed LED ring lighting" is implementation. The former invites competing approaches; the latter forecloses them.
• Constraints that name the existing platforms and standards the response must respect. The plant runs Ignition, the PLC standard is ControlLogix 5580, the integration must comply with the corporate ISA-88 standard. Constraints let responders shape their proposals to the customer's actual environment rather than guess.
• A response format that forces apples-to-apples comparison. Same commercial structure, same schedule format, same key-resources list, same handover-pack definition. Responses that creatively reformat the requested structure are responses that should be sent back for re-do.

What an unfair RFP looks like.

An unfair RFP over-specifies implementation choices (the integrator either pads the price to absorb the misalignment or politely declines), leaves the scope boundary loose (every responder draws the boundary slightly differently and the quotes are not comparable), or buries the constraints in an appendix nobody reads. Unfair RFPs are usually a sign that the customer has not done the scoping work, and the result is an unfair selection process where the winning quote was the most optimistic about what the loose scope actually meant.

The parallel-scope pattern.

For projects above a certain scale, the RFP-and-fixed-price model produces less useful comparisons than a paid-scoping pattern.

How it works.

Two (occasionally three) integrators are paid a small scoping fee — typically two to four weeks of consultancy effort per vendor — to develop their proposed approach in parallel. Each integrator walks the site, talks to the operations and engineering teams, reviews the existing platforms, and develops a proposal grounded in the project's actual engineering reality. At the end of the parallel-scoping period, the customer has two real proposals from vendors who have engaged seriously, rather than two desk-based responses to a paper RFP.

When it works.

The parallel-scope pattern works when the project is large enough that the parallel-scope cost is small relative to the build cost (a five-figure scoping fee on a seven-figure project is acceptable; the same fee on a six-figure project is not). It also works when the customer has the technical depth to evaluate both approaches honestly, including the depth to ignore the option that confirms their existing bias.

When it does not work.

On small projects the model is uneconomic. On capex committee cycles that demand fixed quotes by a hard deadline the model adds time the schedule cannot absorb. And on projects where the customer already knows which vendor they will choose for non-technical reasons (corporate parent dictate, long-standing relationship), the parallel scope is theatre rather than evaluation.

The parallel-scope conversation, when entered honestly, produces better projects than the RFP-and-quote model. Where it can be afforded, it is the model worth choosing.

Reference checks that actually work.

Most reference checks are formality. The ones that matter are the unprompted phone calls.

References that count.

Customers in the same sub-sector, in the same state or near-equivalent location, who used the same controls platform mix as the project under consideration. Generic references ("we have done food and beverage projects in Australia") are less useful than specific ones ("we delivered a multi-line MES rollout at a dairy plant in Victoria using Ignition with SQL backing"). The more specific the match, the more transferable the reference.

The two questions worth asking.

How did the integrator handle the worst surprise during the project? — The answer tells you whether the integrator has a culture of solving problems or escalating them. Real projects always have surprises; what differs is how they get handled.

Would you hire them again? — A one-question summary of everything else. Nobody hedges this question well. Watch for the pause before the answer.

The references that don't appear on the slide deck.

Worth asking the integrator for a reference from a project that did not go perfectly. Every integrator has them; the ones who can name one and describe what they learned are the ones who have improved. The integrator who insists every project went smoothly is either inexperienced or selectively remembering.

Commercial terms worth pushing on.

The contract is where most projects either succeed or quietly fail. The commercial terms that matter are not the headline price.

• Payment milestones tied to deliverables, not dates. 20% on PO, 30% on FAT pass, 30% on SAT pass, 15% on go-live, 5% on warranty expiry. Date-based milestones reward sticking to a schedule even when the work is not done; deliverable-based milestones reward doing the work.
• Named warranty period and what it covers. Twelve months is industry standard. What is covered (defects and fault rectification) and what is not (operator-induced damage, third-party modifications) needs to be explicit. A warranty clause that promises everything covers nothing.
• Post-go-live support pricing. Day rate? SLA-backed retainer? Per-incident? If the customer will need ongoing support, the pricing model has to be defined before the contract is signed, not at the moment a fault occurs.
• Handover pack contents. Source code, drawings, runbooks, login credentials, AOP files, third-party licence transfers. Explicit list. A handover pack defined as "all engineering documentation" is a handover pack the integrator can interpret narrowly.
• IP ownership. Customer owns the deliverable code. Integrator retains rights to reusable library elements they brought to the project. Common, clean split; worth getting in writing.
• Variation procedure. How changes are scoped, priced, and approved during the project. The variation procedure is the document that gets used most often once the project is in flight.

Named resources, not company logos.

The integrator's company brand matters less than the specific engineer who will run the project.

The questions that surface the truth:

• Who is the named project engineer? Not the sales engineer, not the project manager, not "a senior member of our team." A specific person, with a CV, with prior projects we can call references on.
• What is their other workload during our project? An engineer fronting three projects at once is fronting yours one-third of the time. Better to know this before contract than during commissioning.
• What is the seniority of the team behind them? The named engineer might be excellent. If they are supported by graduates the customer's project is paying to train, that is also worth knowing.
• Who is on site for commissioning, and for how long after go-live? The integrator who answers "the project engineer plus a senior commissioning engineer, on site through cutover and the first week of production" is delivering a different service from the integrator who answers "we will deploy the team that fits the schedule."

The named-resources answer is the closest thing to a guarantee of project outcome the customer can obtain. The integrator who is willing to put a senior engineer's name on the contract, with their reputation tied to delivery, is the integrator who has done this before and intends to do it again. The integrator who hedges on names is hedging on outcome.

Pac Technologies' consultancy practice supports customers through the vendor-selection process either as an independent consultancy (preparing the RFP, evaluating responses, running the parallel-scope process) or as a responder where the customer wants to consider us alongside other integrators. The two roles are clearly delineated; we do not act as both on the same project.

Common questions.

Further reading.

Related Pac Technologies resources and adjacent industry references.

• Pac Technologies. Consultancy services. /services/consultancy.html
• Pac Technologies. Programming services. /services/programming.html
• Standards Australia / Standards Australia. AS ISO 10845 — Construction procurement. (Industry reference for procurement procedure design that applies analogously to automation procurement.)
• Pac Technologies. Brownfield PLC Upgrade Pillar. /resources/brownfield-upgrade.html (integrator-selection section)

This article sits under Pac Technologies' consultancy service. For the pre-selection scoping work that produces the RFP, see the feasibility study article. For the ROI workings most RFPs need attached, see the ROI calculator article.