Choosing a partner

How to choose an industrial system integrator, without trusting the quote alone.

Every automation supplier says the same things and shows the same brand logos. The difference shows up after the order, when the line stops and someone has to work out whose problem it is. This guide lists the criteria that actually shift risk, the questions worth asking at the first meeting, and the signals that justify slowing down.

Written by Stefano Brachet Contol — CTO & Founder, IOMA

Published
11 min read
The problem

The market is opaque by construction, not by bad faith.

Open five industrial integrators' websites and you'll find the same list: Siemens PLCs, robotics, MES, SCADA, Industry 4.0, and the logos of the same brands everyone works with, because they are the same brands. That isn't dishonesty: expertise in this field is proven on the floor and doesn't fit on a web page. The result is that a buyer has very little to distinguish someone who has already solved their problem from someone who will meet it for the first time at their expense.

The second reason is that a quote is a poor comparison tool. Two offers for the same line can differ by 40% because one includes commissioning with the operator, documentation updated to what was actually installed, and six months of post-startup support, while the other stops at «it works on my bench». The lowest figure wins the tender and loses the project: the rest arrives later, as a variation order.

The third reason is the most expensive one. An automated plant isn't a purchase, it's a relationship that lasts as long as the line does — ten or fifteen years. You are choosing who you'll call in three years when the format changes, in five when the PLC goes end-of-support, and at two in the morning when the line stops and the truck leaves at six.

The criterion that matters isn't «who is cheapest» or «who knows the most»: it's who stays reachable and accountable when the project meets its first surprise.
Criteria

Seven criteria that shift risk, ordered by how much getting them wrong costs.

They aren't ordered by theoretical importance but by practical damage: the first three are the ones that, when missing, get paid for once the project is already running and can't be recovered by negotiating.

  • A single point of accountability for the outcome

    A typical project involves the machine builder, the panel shop, whoever programs the PLC, whoever installs the network, and whoever writes the supervisory software. If none of them answers for the overall result, every malfunction becomes an argument about whose fault it is while the line stands still. Ask explicitly who signs off on the whole, not on the parts.

    Our answerHow IOMA holds the chain together, from machine to decision

  • Expertise in your process, not just in your PLC

    Programming an S7-1500 is a widely available skill. Knowing why your stator line loses eight minutes on every format change, or why your lot traceability won't survive an audit, is process expertise. The first can be bought; the second accumulates by working in that sector. Ask which processes they have already seen, not which brands they carry.

  • What happens when the line stops at night

    It's the question nobody asks during the offer stage and the one that determines the real cost of the following three years. You need precise answers: who picks up the phone, within how long, with what remote access rights, and what changes between an in-hours intervention and one at two in the morning. A supplier who is vague about this in negotiation will be vague in an emergency too.

  • Who owns the code, and who owns the data

    Two separate questions. The PLC program and the supervisory logic must stay readable and modifiable by someone other than their author, or you've bought a constraint rather than a plant. And production data must remain yours and exportable: if it only lives inside a system you can't query, your next decision gets made with somebody else's numbers.

    Our answerARIA: public price list, data on your own server, no opaque licensing

  • Verifiable references, not a wall of logos

    A logo on a website doesn't tell you whether the project went well, how long it took, or whether the customer would choose the same supplier again. Ask for two or three cases in your sector with the real scope — how many stations, how long the startup took, what went wrong — and ask to speak to someone who was there. A supplier who can't put you in touch with anyone is telling you something.

    Our answerIOMA projects in production, with the scope stated

  • The ability to work on what already exists

    A greenfield plant is the easy case: no constraints, no legacy. Most real projects are interventions on a line that is running, with a ten-year-old PLC, partial documentation, and a two-day shutdown window at Christmas. Ask how many brownfield projects they've done, and how they handled the part that wasn't documented.

  • Real distance and real response times

    It matters less than people think for software and far more than people admit for fieldwork. For a physical intervention on a stopped line, the difference between two and six hours of travel is the difference between a lost shift and a lost day. Ask where the people who would actually come are based, not where the company is registered.

First meeting

Eight questions that separate a supplier from a partner.

These have verifiable answers: they tell you whether you're talking to someone who has done this work before or someone learning on your plant. Vague answers aren't automatically a no, but they're worth noting.

  • «Who signs off on the whole system?»

    If the answer is a list of suppliers, you don't have anyone accountable. If it's a name, ask what happens if that person leaves.

  • «Show me the documentation from a closed project»

    Not a sales brochure: the network diagram, the node list, the commented program. It's the fastest way to understand how they actually work.

  • «Who answers in two years, and on what number?»

    Support has to be defined up front, with times and channels. A structured supplier has it in writing; one who improvises answers «we're always around».

  • «What is not included in this quote?»

    The most useful question of all, and the one that makes two offers with different figures comparable. Ask explicitly about commissioning, training, documentation, and post-startup support.

  • «How do you integrate with what I already run?»

    This applies to the ERP as much as to an existing SCADA or MES. Look for answers that name protocols and methods — OPC UA, S7, Modbus, a documented API — not «we do everything».

  • «What happens if I decide to change supplier?»

    A calm answer is an excellent sign. A supplier confident in their work has no need to make leaving difficult.

  • «Who will actually work on my plant?»

    The person who sells the project and the person who delivers it are often not the same. Ask to meet the second one.

  • «What went wrong on your last project?»

    No industrial project runs smoothly. Anyone answering «nothing» either has no memory or no experience; anyone who describes a problem and how they closed it is showing you how they work under pressure.

Red flags

Six signals worth slowing down for.

None of these disqualifies a supplier on its own. Two or three together do.

  • The quote is far lower than the others

    In 90% of cases that isn't efficiency, it's a narrower scope. Before celebrating, put the two offers side by side and look for what's missing from the cheaper one.

  • No questions about your process

    A supplier who quotes without asking how many SKUs you run, how many format changes a day, and where the line stops today is quoting a generic plant.

  • Everything is «proprietary»

    Proprietary software isn't a flaw. Proprietary closed software, with no data export and no access to the logic, is a constraint you'll pay for at the first change.

  • Support isn't in writing

    If response times and intervention methods aren't in the contract, they don't exist. «We're always available» is not a commitment.

  • References can't be contacted

    A list of logos with nobody to talk to is worth little. Confidentiality reasons are legitimate, but if they apply to every single customer, that's a signal.

  • Buzzwords instead of answers

    If the answer to «how do you read data from my PLC» talks about digital transformation instead of protocols, you're talking to someone who sells, not someone who implements.

The decision upstream

Before choosing which integrator, decide whether you need an integrator.

This is the question that almost always gets skipped, and sometimes the answer is no. It's worth asking properly, because the three routes carry very different costs and risks.

  • You have an in-house automation team and the work is self-contained

    If the job sits inside one machine, the team knows that PLC, and the impact on the rest of the line is nil, doing it in-house is almost always right: nobody knows your process better than the people inside it, and reaction time is immediate. The only risk worth watching is documentation, which in-house work tends to leave unwritten.

  • The work sits inside a machine you are buying

    Ask the builder, at order stage. Whoever designed the machine knows its mechanics and its timing better than anyone, and integrating during supply costs a fraction of doing it afterwards. The limit appears when that machine has to talk to the others: there the OEM stops at its own scope, and rightly so.

  • The project crosses several machines, suppliers, or layers

    This is where an integrator earns its place, and not for technical capability: for accountability. When data has to travel from the PLC up to supervision, then to the MES, then to the ERP, the problem is none of the individual pieces — it's that nobody answers for the chain. An integrator is exactly what you buy that for: one counterpart accountable for the end-to-end result.

    Our answerIOMA services, by layer and by problem solved

  • You don't yet know what you need

    This happens more often than people admit, and it's a legitimate position: «our production data isn't reliable» is a symptom, not a specification. Here the thing to buy isn't a plant but a few days of analysis, with someone who looks at the line and tells you what's worth doing — even if the answer is «less than you thought».

    Our answerLet's talk about your case before quoting
After signing

How to recognise a well-run project while it's still running.

An integrator's quality shows up at three moments, and none of them is the contract signature.

**The analysis.** Before a line of code is written, someone must have watched the line running, timed it for real, read the existing program, and said clearly what is out of scope. An analysis that confirms everything you hoped for is an analysis that wasn't done.

**The startup.** This is where the project meets reality: the line behaving differently than on the bench, the operator using the interface in a way nobody anticipated, the sensor that gets dirty. A good startup is attended, not delivered: someone stays on the floor until the shift runs without help.

**The handover.** Documentation updated to what was installed — not to the original design — a commented program, and training given to the actual operators rather than only to the manager. It's the part that gets cut first when a project runs late, and the part you pay for over ten years.

If after startup nobody in your company can explain how the thing you bought works, the project isn't finished: it has only been delivered.

Let's talk about your plant

Write to us

A 30-minute call with the people who would do the work, not with a salesperson. If the answer is that you don't need us, we'll say so.

Based in Turin · projects across Italy and abroad

FAQ

Frequently asked questions

Questions Plant Managers ask before starting an MES/SCADA project.

How much does an industrial system integrator cost?

There is no comparable industry rate, because scope changes everything: a retrofit on one machine and the integration of a nine-station line are projects an order of magnitude apart. What you can demand is transparency on the structure of the cost — analysis, development, startup, documentation, support — and on what is NOT included. For the software part, some suppliers publish a price list: that's the fastest way to calibrate expectations before asking for a quote.

Is a large or a small integrator better?

It depends on what worries you more. A larger organisation gives continuity if one person leaves and can carry multi-site projects; a smaller one gives direct access to the people actually working on your plant and faster decisions. The useful question isn't size but: how many people know my plant well enough to intervene? If the answer is one, the risk is identical in both cases.

How do I assess technical competence without being an engineer?

You don't need to review code: three questions are enough, because a competent supplier answers them precisely and an improviser answers them vaguely. How do you read data from the PLC (expect a protocol: OPC UA, S7, Modbus); what happens if the network drops halfway through a batch; how do you handle an update on a line that can't stop. Then ask to see the documentation from a closed project — it's the most honest indicator of method.

Should the integrator be geographically close?

For software it matters little: development, updates, and most diagnostics happen remotely over an agreed connection. For fieldwork it matters a lot: if the line is down and a physical presence is needed, the difference between two and six hours of travel is the difference between a shift and a day. The right question isn't where the company is registered, but where the people who would come are based and how fast they get there.

How many suppliers should I compare?

Three is usually enough, provided they quote the same scope: two offers on different scopes aren't comparable, and the lowest wins by construction. It's worth investing time in the request document rather than in the number of bidders — a clear specification makes offers comparable and quickly reveals who read it and who answered with a template.

How do I avoid getting locked in?

Put three things in the contract before signing: the PLC program stays readable and modifiable, production data is exportable in an open format, and delivered documentation matches what was installed. None of that prevents staying with the same supplier for years — most industrial relationships last because they work — but it makes it a choice rather than an obligation.
Go deeper

Pages usually opened after this guide.

Services · Automation and integration

What we do, organised by layer and by problem solved: PLC, robotics, MES/SCADA, IT/OT integration, OT cybersecurity.

Portfolio

Projects in production with the scope stated: starting situation, complexity, intervention, result.

About us

Who is behind this: history, skills, how we work, and why there is only one office.

Resources · What MES/SCADA software costs

If the choice also involves software: pricing models, 2026 market ranges, and two worked examples.

→All the guides on industrial automation and software
Let's talk

Got a project in mind?

Tell us about your idea or your operational challenge. Our team is ready to listen and propose the right technology fit.

Let's talk about your project

Or:book an ARIA demohey@ioma.ai