Choosing an Automation Integrator: 5 Criteria That Truly Determine Safety and the Total Project Cost

Choosing an automation integrator is rarely a decision based on technical factors alone. In practice, it is a decision about when project risk will surface: during the concept and alignment stage, or only after installation, when the line is expected to return to production. From the plant’s perspective, the most expensive problems are usually not isolated programming errors, but flawed initial assumptions: an unclear scope of changes, overlooked interfaces with the existing installation, no agreed test plan, weak documentation, and responsibility shifted to the end user.

That is why the quoted price should be only one part of the evaluation. The real cost of a project is usually determined by the questions the integrator asks before the order is placed, how commissioning is managed, and the quality of the project record left behind after the work is completed. This is exactly where safety and cost stop being separate issues, including the hidden project and CE certification costs that often emerge only later.

The integration price is not the project cost

The easiest thing to compare is the quoted price, but that is usually the weakest selection criterion. The cost of buying the service is only part of the cost of the overall project decision. What determines the outcome of the investment more often are the problems that appear after commissioning: rework on guards, changes to safety logic, conflict between the required performance and the actual conditions for safe operation, gaps in the documentation needed for acceptance, and delays caused by restarting the installation. For this reason, the cheapest quote rarely turns out to be the cheapest option over the full life cycle of the solution.

In retrofit projects, the difference between a contractor and a project partner becomes visible very early. A contractor delivers what is written in the specification. A project partner first checks whether the specification itself contains assumptions that will later become a source of cost or liability for the plant. They can identify project boundaries, interfaces with the existing line, dependencies between mechanics, controls, and safety, as well as the impact of changes on the machine’s status after the retrofit and the conformity assessment. This is not a matter of working style, but of the ability to manage risk from the start of the project.

Most costly workarounds are usually created at the concept stage. A common scenario looks much the same: the project assumes a simple controls replacement, but without analysing the impact on the operating sequence, service access, and safety functions. After commissioning, it turns out that the operator has to perform additional manual operations, the maintenance department needs procedures to compensate for a weak design, and performance drops because safe access to work zones was not properly resolved. That is when corrections not included in the quote begin: mechanical changes, additional guarding, rebuilding safety circuits, updating documentation, and repeated acceptance activities. At that point, the controller program itself may be the smallest part of the problem.

That is why an integrator’s quote should be read not only through the lens of capital expenditure, but also through the lens of post-commissioning costs and the questions asked at the outset. A good sign is a precise description of boundary assumptions, identification of risks at the interface with the existing installation, reservations about missing input data, and a willingness to challenge the investor’s incorrect expectations. A weak sign is a promise of fast delivery without interface analysis, no reference to the documentation of the existing machine, omission of acceptance conditions, and silence on responsibility for safety after the changes. Against this background, it becomes clear that safety and hidden project and CE certification costs are not an add-on written in at the end, but a boundary condition for the entire retrofit.

Five criteria that filter out false savings

The most expensive projects are often not those where the integrator had a higher entry price, but those where the buyer purchased the illusion of simplicity. That is why contractor selection should be based on five criteria that can be verified before the contract is signed. They work equally well in a technical discussion, a request for quotation, or a bid evaluation matrix.

The first criterion is project maturity in the area of safety. A reliable integrator can describe not only the control architecture, but also the method for hazard identification, boundary assumptions, the allocation of responsibilities between the parties, and the logic behind the selection of protective measures. If the discussion ends with the choice of controller, light curtain, or interlock, and does not lead to the question of who is responsible for the risk assessment after the changes, what the operating modes are, and which deviations from normal operation need to be taken into account, then the project is being handled too superficially.

The second criterion concerns the ability to work across disciplines. Real safety problems rarely result from a single electrical error. They arise at the interfaces: between mechanical movement and guarding, between the control sequence and pneumatics, between system reset and visibility of the hazardous zone, and between operator ergonomics and changeover organisation. An integrator who does not see these dependencies usually pushes their cost into the commissioning stage.

The third criterion is the quality of the documentation and the decision trail. At the quotation stage, it should be clear whether the contractor includes a safety concept, schematics, an I/O list, a functional description, a test plan, a change log, and acceptance conditions. Missing documentation almost always shifts the cost to the plant: maintenance loses time reconstructing the operating logic, further modifications are made without confidence in their effects, and conformity assessment after modernization becomes more difficult because it is unclear what assumptions were adopted and what was actually changed. Good documentation is not an administrative add-on, but a tool for controlling technical risk.

The fourth criterion is how commissioning and acceptance are handled. For the plant, what matters is not only whether the machine starts up, but whether commissioning is planned so that compliance with functional and safety requirements can be confirmed objectively. The integrator should define in advance the test scenarios, acceptance criteria, conditions for handover to operation, and the procedure for handling non-conformities. If acceptance is based solely on starting production and fixing issues on the fly, the investor takes on the risk of scope disputes, delays, and costly corrections after downtime.

The fifth criterion is serviceability and durability of the solution. A program may work correctly on the day of commissioning and still be written in an unreadable way, without meaningful diagnostics, without version control, and without preparation for future changes. In that case, every failure, expansion, or component replacement becomes a high-risk operation. A well-prepared solution makes it possible to restore the program version, identify the cause of a stoppage, verify safety parameters, and implement modifications without reducing the level of protection.

These criteria can be checked quickly with a few questions:

• How will hazard identification, the scope of changes, and the division of responsibilities between the integrator and the user be described?
• Which documents will be required for acceptance: schematics, functional description, test plan, protocols, change log, program backups, and safety versions?
• How will functional tests and safety-related tests be carried out, and who approves non-conformities and deviations?
• How will the solution be serviced after one year and after the next modernization: diagnostics, access to parts, program clarity, version recovery?

If the answers are vague, the problem is not communication style but process maturity. From a cost and compliance perspective, that is exactly when the risk increases that the plant will take over responsibilities that were included neither in the budget nor in the schedule.

Where the integrator creates cost or eliminates it

The cost of an integrator’s work is best judged by the stage of the project at which problems come to light. If difficult decisions emerge only during commissioning, the cost is almost always shifted to the plant: in the form of additional downtime, changes made under production pressure, and unclear responsibility for what was actually modified. In a well-managed project, these costs are eliminated earlier. Any conflict between the required cycle time, operator access, service access, and protective measures should be identified at the concept stage, not on the shop floor after installation.

This is where it becomes easiest to distinguish a contractor who simply “replaces the controls” from an integrator responsible for the consistency of the overall solution. Modernizing an existing machine or part of a line rarely comes down to a simple replacement of the controller and a few drives. A change in operating logic usually affects the entire chain of dependencies: the motion sequence changes, reaction times change, and a different type of access may be needed for changeovers, cleaning, or clearing jams. If the integrator does not analyze this before the design is frozen, the controls may work correctly and the system still may not be ready for safe operation.

A typical example is straightforward. A plant plans to modernize a packing station during a short service window. The initial assumption seems reasonable: replace the outdated controls, tidy up the drives, make a few corrections to the sequence, with no mechanical changes. After start-up, however, it turns out that the new logic requires the operator to enter the material feed zone more often, while the existing guards and layout of protective devices make every intervention take unacceptably long from the production standpoint. Maintenance starts looking for workarounds, the health and safety team questions the access method, production pushes to restore the required cycle time, and the integrator points out that the program works in line with the agreed function. The next step is to modify the guards, rebuild the intervention acknowledgment method, refine the changeover procedure, and update the instructions for operators and service personnel.

Each of these changes may look minor on its own, but together they create a cascade of costs: more days when the station is unavailable, additional non-conformities at acceptance, further interventions after production start, and a dispute over whether the issue that surfaced was a scope change or the result of a flawed concept. The same case, handled properly, looks different several weeks earlier. The integrator shows that the required cycle time and the expected method of operation conflict with the current guard arrangement and service access. Instead of hiding the problem behind “we’ll sort it out during commissioning,” they present the options and their consequences for the process, safety, and later acceptance.

That is the point at which the plant can make an informed decision: carry out a full upgrade, or phase the work with an incomplete definition of requirements, but with a clearly described boundary of responsibility for changes identified during commissioning. In practice, it is worth asking not only about declarations, but also about how previous projects actually ran: how many changes were introduced after the design was frozen, how many non-conformities were found at acceptance, how many interventions were needed after start-up, and what the actual workstation downtime was. These questions quickly show whether you are dealing with a standard commissioning issue or a design error.

Only against that background does the role of documentation, testing, and conformity assessment after a modernization become clear. They are not a bureaucratic add-on to a finished machine. They are the outcome of a sound design process that combines control logic with safety, operator ergonomics, and maintenance needs. If these elements are not developed in parallel, the plant takes on the risk at the worst possible moment: after installation, under pressure to resume production, and without certainty as to whether the scope of changes creates further obligations for the end user.

How to buy responsibly before the problem appears

A good purchasing decision in automation starts not with comparing prices, but with the quality of the input data provided to the integrator. If the inquiry describes only the expected production outcome, the contractor will define the project boundaries, operating method, service conditions, and assumptions about the existing line for themselves. In most cases, that means the cheapest offer is only the cheapest because it leaves out cost-driving elements that become visible only during commissioning.

That is why the plant should describe not only the function of the machine or modernization, but also process constraints, operating requirements, interfaces with systems and equipment already in operation, the expected service mode, shutdown conditions, and the scope of documentation needed for maintenance, training, and later changes. At this stage, it is also necessary to decide whether the mechanical and automation scopes will be handled together or separately, and who is responsible for cross-disciplinary interfaces. The more precise the input data, the lower the risk that the offer will hide costs pushed to a later stage. This is also the point at which choosing the right project partner and ensuring safety compliance becomes a practical purchasing issue rather than a formality.

The evaluation of offers should reward not the promise “we will do it comprehensively,” but what can be verified before the order is placed. A good offer shows the work plan, the list of assumptions used for pricing, the identified risks, the required input data on the plant side, the division of responsibilities, and the testing approach before delivery and during commissioning. It should also clearly describe the acceptance conditions: what is a mandatory condition for acceptance, and what can go onto an open-points list to be closed after start-up. If the integrator cannot name the risks, define the acceptance criteria, or identify missing information, the problem will not disappear after the order is signed. It will simply be transferred to the shutdown schedule and the change budget.

Most misunderstandings arise later not because of the technology itself, but because of an imprecise contract. The commercial document should define not only the deadline and price, but also the change management process, rights to the source code, design, and documentation, the parties’ obligations during commissioning, the acceptance criteria, and the complete list of materials to be handed over at acceptance. This includes controller and panel programs, backup copies, schematics, signal lists, settings, instructions, test results, and documents needed for further operation and any subsequent conformity assessment path. A good practice is to make final acceptance and the last payment conditional on complete documentation and completion of the agreed tests, because that is when the integrator’s actual level of preparedness becomes clear. Where documentation is part of the handover, machine operating manuals should also be prepared with the same level of discipline.

• in the inquiry: function, process constraints, interfaces, service mode, expected documentation, project boundaries
• in the offer: assumptions, risks, test plan, responsibilities of the parties, acceptance conditions
• in the contract and at acceptance: change rules, rights to code and documents, completeness of handover, acceptance criteria

Reference to formal requirements should close the decision, not replace it. References alone to machine safety and CE marking, conformity assessment, technical documentation, instructions, or safety function verification will not fix a poorly defined scope or an unclear division of responsibilities. If the project concerns a new machine or a modernization that may be regarded as a substantial modification, this must be identified early enough, before the order is placed and before the delivery model is accepted. Otherwise, the end user may be left with obligations that were not included in the quotation or the schedule. In such cases, it is also necessary to consider the impact of changes on the machine’s status after modernization.

The practical conclusion is simple: it is cheaper to spend more time preparing the inquiry, verifying the integrator, and reviewing safety before production start-up than to pay for corrections once the line is already down and the parties’ responsibilities remain unclear. When choosing an automation integrator, safety is not an incidental cost. It is the shortest path to reducing the costs that arise when a project is poorly defined from the outset. In practice, this is also supported by well-organized collaboration between the integrator and the maintenance department and by properly preparing the plant for production automation. Where responsibilities after delivery are unclear, the risk may extend beyond project overruns to management liability in accidents involving non-compliant machinery.