Production, assets and the warehouse: the systems that run the physical world

This article is also available in Russian: Russian version.

The four domains in this article share one thing: they manage physical objects, not documents. The machine cutting a part. The pump about to fail. The batch to be rejected. The pallet that must be in one specific location. Everything else in a company's IT landscape works with records about reality — these four work with reality itself.

Hence their defining property: they do not forgive lies in the data. An accounting system survives a messy reference book — the report comes out crooked, the system stands. A warehouse where locations do not match the shelves stops on day one. Predictive maintenance built on work orders closed retroactively predicts exactly that fiction. Machine vision trained on a batch with no defects confidently passes bad product.

The second thing they share is people. The user here is not at a desk — they are standing at a machine, walking the shop floor with a tablet, working in a cold store. A project done top-down without supervisors, maintenance engineers and storekeepers meets quiet sabotage rather than argument, and on the plant floor that costs more than in the office.

Below: what each domain does, who needs it, what has to exist before it. At the end — how they connect, the vendors you will meet, and a shared selection checklist.

What is in this article

• Production: MES, SCADA and process control — from the sensor to the shift schedule

• Assets and maintenance: EAM and CMMS — equipment as something you manage, not a ledger line

• Quality, safety and environment: QMS and EHS — non-conformances, the laboratory, industrial safety

• Warehouse and supply chain: WMS, TMS and SCM — location storage, picking, delivery, inventory

• How the four domains connect — the shared foundation and the order of moves

• Where AI fits — what works, what has to exist first, where the boundary is

• Vendors you will actually meet — common products by subclass

• Typical mistakes and a selection checklist — what to check before you buy

Production: MES, SCADA and process control

If ERP answers "what is our margin", the production stack answers "what is happening on the shop floor right now — and how do we load the next shift". This is the foundation of the IT systems pyramid, the model by which a manufacturer's landscape is built from the bottom up. Production data is born here, at sensor and machine level, and everything above — ERP, analytics, AI — is exactly as trustworthy as this layer. Below: what the stack consists of, why it comes before ERP, and where AI already earns its keep.

What the stack does — and what it does not do

The production stack covers everything between the physical equipment and the volume plan coming down from ERP: it collects sensor data, shows the process to the operator, builds schedules and manages execution on a horizon of a minute to ten days.

What it does not do: count money or replace the accounting core. It will show the cost of a shift, not the profitability of the business. That is ERP's job. The boundary between the two is the most common point of confusion, and we covered it in the article on money, planning and analytics.

Subclasses: what the stack is made of

SCADA — supervisory control and data acquisition in real time. The lowest, most technical layer: process visualisation, alarms, trends.

Effect: the operator sees the process and reacts before an incident; history accumulates by itself.

Drawback: SCADA on its own is eyes, not a brain. Data is collected; the decisions still live in the head of the person on shift.

MES — manufacturing execution: capacity loading, staffing the shift, shift-level cost, reacting to deviations before they turn critical. Horizon: a shift to ten days.

Effect: the shop-floor plan stops living in the supervisor's spreadsheet, and actuals are captured without manual entry.

Drawback: effectively a digital twin of production, and if the model is built wrong the cost of the error is severe — you can wreck equipment and lose control of the floor. Tested the hard way.

APS — scheduling of equipment across the whole plant, accounting for the dependencies between every stage.

Effect: a plan that can be executed instead of a plan that is merely wanted.

Drawback: demanding about the accuracy of standards and the maturity of planning; on imprecise data the plan slides right day after day. In our experience APS is more often viable as an ERP or MES module than as a standalone system.

IIoT platforms — connecting equipment, collecting and pre-processing the data coming off it.

Effect: data from the metal reaches every system above without anyone writing numbers down.

Drawback: sensors and networks are capital expenditure that pays back only if somebody uses the data.

BMS/BAS — building management: ventilation, energy, lifts, climate. A relative of SCADA for real estate; relevant to developers, property managers and large facilities. LIMS — laboratory information management; for the production stack an adjacent data source, and the class itself is covered under quality and safety below.

Who needs it, who is too early — and what comes first

You need it if you run production with shift planning: the plan lives in a spreadsheet, actuals are collected by hand at the end of the shift, cost is known once a month. Symptoms: supervisors spending an hour of every shift on reporting; downtime data appearing after the fact; the ERP plan and shop-floor reality diverging systematically.

Too early or not needed: non-manufacturing companies do not need this stack at all. Small-batch production without shift work often gets by on SCADA and recording discipline — a full MES does not pay back at that scale.

Dependencies and sequencing. This is the foundation of the pyramid: you cannot reach the upper floors without working the lower ones. The stack comes before ERP or alongside it, never after. An ERP dropped on an unworked production layer feeds on manual entry: the data cannot be trusted, and headcount grows to include the people typing it in. On top of production actuals sits the quality and safety domain — you can only manage the quality of a process you measure. Upward, the stack feeds ERP, BI and EAM; its input is a digitised process definition, which for your own products comes from PLM, PDM and BIM rather than a process engineer's head: the product model is normally upstream of manufacturing.

What the stack gives the business — and its typical drawbacks

Effect. Trustworthy production actuals without manual entry — the base for calculating cost, finding bottlenecks, making decisions. Deviations answered at the pace of a shift, not of a monthly report. And discipline: the digitised process definition stops drifting from the paper one.

Drawbacks people talk about less. The stack is demanding about IT infrastructure: a lot of data, processing time matters, and that is visible capital expenditure. The cost of a modelling error is high (see MES above). And most common of all: resistance from the shop floor. To supervisors it looks like surveillance, and without work on the people side the project bogs down. Half the outcome here is change management, not software.

The 2026 context

No single regulatory deadline hangs over the production stack, which does not mean there is time to spare. Two forces push it up the agenda. The installed base is old: control systems commissioned fifteen or twenty years ago are losing vendor support, and the specialists who know them are retiring. And security regulation has caught up with operational technology — frameworks such as NIS2 in the EU put plant-floor systems in the same risk conversation as corporate IT, so the OT estate has to be inventoried, segmented and owned by name. That requires knowing what is connected down there, which most companies discover they do not.

A sense of scale. There is no useful headline number, because the software is not the cost driver. What drives it: how many sites, how many machines have to be connected, how much of the shop floor has usable network coverage, how old the equipment is. Sensors, terminals at the machines and industrial networking are separate budget lines, and on old equipment they routinely cost more than the system itself. A whole-site project runs from roughly half a year to a year and a half. Get it costed after a survey, not from a price list.

Assets and maintenance: EAM and CMMS

There are two ways to learn that a pump has failed: from a system, a week before it happens, or from a 3 a.m. phone call together with a stopped line. The difference is asset management. EAM answers "what condition is our equipment in", "what do we service and when", "what does each asset cost us". Below: what the domain consists of, why it starts with a register rather than sensors, and where predictive analytics works and where it stays a slide deck.

What EAM does — and what it does not do

EAM (Enterprise Asset Management) runs the full life cycle of physical assets: from the equipment record and maintenance schedule to the economics of "repair again or replace". Inside it lives maintenance management: defect reports, preventive work, work orders, spares. In the mid-market the common term is CMMS; for real estate and offices, IWMS/CAFM.

What the class does not do: manage production or run company finance. Shift loading and the process definition belong to the production stack; the maintenance budget and spares purchasing in money terms are consolidated in ERP. EAM sits between them: it takes equipment operating data from below and passes costs and procurement demand upward.

Subclasses and modules: what the class is made of

Asset register and equipment records. A single hierarchy — site → line → unit → component — with records, documentation and the history of every item. The foundation of the class.

Effect: one source of truth about the assets; without it maintenance is planned from one engineer's memory.

Drawback: a register alone is bookkeeping, not management, and without the discipline of keeping it current it goes stale within a year.

CMMS — requests and maintenance planning. Defect lists, preventive work, work orders, labour hours.

Effect: maintenance moves out of firefighting into planning — and planned work costs a fraction of an unplanned stoppage.

Drawback: the main risk is turning the system into formal reporting: work closed retroactively, data that stops reflecting the plant.

Mobile rounds and inspections. Checklists on a phone or rugged terminal, photo evidence of defects, tags on equipment.

Effect: data is born at the moment of inspection, at the asset — not in a logbook that evening from memory.

Drawback: without motivating the inspectors it becomes checklist-clicking; controlling the form is no substitute for interest in the content.

Predictive diagnostics and APM. Condition analytics from sensor data — vibration, temperature, current — and failure prediction.

Effect: maintenance by condition instead of by calendar: fewer stoppages and fewer needless interventions in healthy equipment.

Drawback: the most expensive subclass. It needs sensors, infrastructure and accumulated failure history; without those it is a good-looking presentation.

Spares and the MRO store. Usually a maintenance module tied to ERP purchasing: safety-stock levels, reservation against work orders.

Effect: the repair does not wait weeks for a part, and the store is not frozen "just in case".

Drawback: it works exactly as well as your consumption norms are accurate.

IWMS/CAFM. The related subclass for buildings and offices: facility maintenance, floor space, tenants. Relevant to developers and property managers; an industrial company rarely needs it.

Who needs it, who is too early — and what comes first

You need it if you own a fleet where downtime is expensive: manufacturing, energy, transport, utilities, large real estate. Symptoms: maintenance mostly reactive; the defect log a spreadsheet or paper; spares bought by feel; nobody able to name the cost of ownership of a specific machine.

Too early or not needed: companies without a meaningful fleet; small sites where servicing is outsourced. Skipping the register and the work-order process to start with predictive maintenance is a bad idea for everyone: it is the top floor of the class, and there is no entrance up there.

Dependencies and sequencing. The entrance is the asset register: without one, maintenance management stays a spreadsheet with a licence fee. For equipment you designed yourself, records and component structure come from PLM, PDM and BIM — re-keying them creates a second master. EAM takes operating data from the production stack (SCADA, IIoT), which is why on the pyramid this class is worked in parallel with MES. Equipment condition also flows into quality and industrial safety: a faulty unit is both a defect source and a risk to people. Upward, EAM passes costs to ERP and indicators to analytics. Putting asset economics on unworked record-keeping means calculating cost of ownership from invented data.

What the class gives the business — and its typical drawbacks

Effect. The share of planned maintenance rises, and both downtime and servicing cost fall: a breakdown that stops a line always costs more than planned work. The economics of each asset become visible — repair again or replace. And equipment history stops walking out of the door with the engineer who resigns.

Drawbacks people talk about less. The main traps here are not technical. First, resistance: to maintenance crews the system looks like surveillance, and without work on the people side the project bogs down. Second, formal reporting — indicators for the tick-box rather than the real state of the plant; management discipline cures that, the system does not. Third, this class feeds on manual entry more than its neighbours — inspections, defects, running hours — and data quality rests on the motivation of the people doing the work.

The 2026 context

The class has no deadline of its own, but it lives in lockstep with the production stack, and the questions asked of it keep getting harder. Boards and auditors increasingly want asset management described in the vocabulary of ISO 55000: a register, a criticality assessment, a documented policy — not a maintenance department's private habits. Safety management under ISO 45001 reaches into the same data: permits to work, isolation, competence of the person doing the job. And insurers ask about equipment condition in evidence, not assurances.

A sense of scale. The cost drivers: how many sites, how large and how messy the asset register is, how much of the plant has connectivity for mobile work. Mobile terminals for rounds and shop-floor coverage are a separate budget line that surfaces after the software is chosen. A single-site project usually runs from a few months to a year. Vendors publish licence prices; the implementation work is normally the larger half. Have it costed after a survey.

Quality, safety and environment: QMS and EHS

The class almost every manufacturer has on paper and almost nobody runs. A certificate on the wall, procedures in a cupboard, non-conformances discussed at the morning meeting and forgotten there. The cause is not laziness: quality is managed through data, not documents — and the data has to come from somewhere. Below: what this domain consists of, what has to exist before it, and why these projects usually fail on something other than technology.

What the domain does — and what it does not do

The domain turns requirements — from standards, regulators or the customer — into a working cycle: measure, detect the deviation, find the cause, fix it, verify it did not recur. Same with risks to people and the environment: identify the hazard, reduce it, control it, report on it.

What it does not do: produce quality. The system records and organises, but defects arise in the process, not in the software — if the process definition is not followed, a QMS will honestly show you that and change nothing. And it does not replace production record-keeping: without shop-floor data it works with whatever was typed in by hand, which is a version of events rather than the events.

Subclasses: what the domain is made of

Quality management system (QMS). Documentation, processes, non-conformances, corrective and preventive actions, internal and external audits.

Effect: a non-conformance stops being an episode at a meeting and becomes a record with a cause, a deadline and an owner.

Drawback: the class degrades easily into paperwork for a certificate — at which point it costs money and delivers nothing.

Laboratory and quality control (LIMS). Samples, tests, protocols, instrument calibration, incoming and outgoing inspection.

Effect: test results become data instead of a notebook, tied to a specific batch.

Drawback: adoption runs into laboratory discipline and instrument integration — moving results by hand reduces the effect to zero.

Occupational health and industrial safety (EHS). Risk assessment, briefings and authorisations, permits to work, incidents and investigations, protective equipment, medicals.

Effect: obligations are met and evidenced, and incidents get analysed, not just logged.

Drawback: the domain accumulates formal signatures faster than real practice: a signature in a register is not a briefing that happened.

Environment and reporting. Emissions, waste and water accounting, mandatory reporting, sustainability indicators.

Effect: reporting is assembled from recorded data, not reconstructed the week before the deadline.

Drawback: requirements change, and configuring the forms becomes ongoing work, not a one-off project.

Training and authorisations. Health, safety and quality training, knowledge checks, the matrix of who may do which work.

Effect: you see who is authorised to do what today, not according to last year's order.

Drawback: without a link to the HR domain and the knowledge base you get a third list of employees that disagrees with the first two.

Who needs it, who is too early — and what comes first

You need it in manufacturing, and in regulated industries it is not optional: food, pharmaceuticals, chemicals, energy, transport. Symptoms: complaints investigated from memory; half of an audit spent looking for documents; the same non-conformance recurring a third time with nobody able to show what was done the previous two.

Too early or not needed: before basic production record-keeping exists there is nothing to feed this domain. You can only manage the quality of a process you measure — if production actuals are not in a system, quality gets described in words.

Dependencies and sequencing. The domain is normally layered on basic production record-keeping, resting on the lower levels of the IT systems pyramid — Dzhimsher Chelidze's model, in which the landscape is built from the bottom up. Inputs: data from the production stack, laboratory results, equipment condition from EAM. Outputs: audits, reporting, and back into the process. Product requirements come from PLM: what you inspect has to be what the documentation specifies, not what the inspector remembers.

What the domain gives the business — and its typical drawbacks

Effect. Lower cost of defects and complaints — the one metric both the CFO and the shop floor understand. Readiness for an inspection any day instead of a scramble before the audit. Traceability: from a batch number you see what it was made from, who inspected it, what the tests showed. And fewer injuries — rarely quantified, though one serious incident costs more than the system.

Drawbacks people talk about less. The domain increases the visible count of non-conformances — there are not more of them, they have become visible, and the first year looks like deterioration. It takes time from people already loaded: the supervisor, the inspector, the safety engineer. And it is painfully sensitive to culture: where reporting a problem is punished, the system receives clean data about a flawless operation.

Why these projects fail on something other than technology

The most common script: IT picks a system, configures the processes to its own understanding, goes live — and meets polite rejection. Formally everything works; in practice the quality department keeps a parallel record in spreadsheets, because in the system "it is not how the methodology requires".

In Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation" this is the second of the seven sins of digitalisation — the IT team lacks the competencies, and not only technical ones: good at infrastructure, weak at business requirements and change management. The consequence is stated briefly: a technically correct solution the business does not accept. The remedy from the same source: cross-functional teams — IT plus business plus analytics.

For this class the translation is literal. The project owner must be the quality or safety function, not IT. The team needs somebody who knows how an audit works and what an inspector will ask. And configuration starts from the real non-conformance investigation — how it happens today, awkward details included — not from how the procedure describes it.

The 2026 context

Requirements for traceability and reporting keep rising, and inspections lean on data more than on the folders you hand over. The management-system standards are the common language: ISO 9001, ISO 14001, ISO 45001. In regulated industries the bar is higher — GxP practice and FDA 21 CFR Part 11 make demands on electronic records and signatures that are an architecture question, not a policy-document one. GS1 standards carry batch and serial traceability; in the EU, CSRD pulls environmental data into the same evidence regime as financial data. Meanwhile machine vision has become cheap enough that in-line inspection is no longer a privilege of large plants.

I give no specific deadlines or article numbers here: requirements differ by industry and jurisdiction, and they change. An unverified reference is worse than none. Check what applies to you at the moment you read this.

A sense of scale. A single module such as occupational safety is a fast project — a couple of months. A cross-functional domain with a laboratory and a live link to production record-keeping is a different order of magnitude, six to eighteen months, and in regulated industries validation alone is a big share of that. Cost drivers: number of sites, number of regulated processes, instruments to integrate, and whether the solution has already been configured for your standards. Have it costed after a survey.

Warehouse and supply chain: WMS, TMS and SCM

The goods are in the warehouse — but only one person can find them, because "they are where they always are". A new hire picks an order in forty minutes instead of five, a quarterly stock count halts work for two days, half the dead stock is found when it has already expired. This is not a people problem but the absence of a system in which every pallet has an address. Below: what the logistics domain consists of, why it needs a clean item master before location-based storage, and where AI works here.

What the domain does — and what it does not do

The logistics domain owns the physical movement of goods: where they are, how fast they are found and picked, how they reach the customer. And how much to buy so that you neither run out nor freeze cash in stock.

What it does not do: replace accounting. Book balances and cost are consolidated in ERP; WMS owns the physics of the warehouse, not the money. And it does not clean up your item master: if the same product is entered three times, the system will faithfully put it in three locations.

Subclasses: what the domain is made of

WMS — warehouse management. Location-based storage, receiving, put-away, picking, shipping, stock counts without shutting the site.

Effect: any employee finds the goods with a terminal instead of from memory; picking speed rises several times over and the stock count stops being an emergency.

Drawback: WMS demands discipline on every operation — scanning always, not when convenient. A warehouse where terminals get left on a shelf ends up with an expensive system and the same chaos.

TMS — transport management. Routes, tariffs, carrier selection, delivery tracking, trip documents.

Effect: you see the real cost of delivery by lane and by customer, not "logistics on average".

Drawback: the effect depends on data about your own fleet and contractors — without it the system is an electronic trip log.

SCM and inventory planning. The chain end to end: demand forecast, stock norms, replenishment, supplier management.

Effect: less stockout and less cash frozen on the shelves — two errors that usually travel together.

Drawback: inventory planning lives on the quality of sales history; on six months of gappy data the forecast will be confident and wrong.

Labelling and traceability. Batch and serial control, expiry dates, working with traceability schemes.

Effect: a recall is surgical instead of "everything that looks similar", and requirements are met without hand-built registers.

Drawback: for many product groups this is a mandatory ongoing load — budget it as a running cost, not a project.

Yard management and dock slots. Gates, receiving windows, the vehicle queue.

Effect: trucks do not queue for four hours, and receiving is spread evenly across the day.

Drawback: it works only if suppliers play by your slot rules — a negotiation, not a configuration setting.

Who needs it, who is too early — and what comes first

You need it from roughly a thousand square metres upward, with your own logistics, or when working with labelling and expiry dates. Symptoms that it is time: picking depends on who is on shift; stock-count discrepancies cannot be explained; dead stock and expired goods are found after the fact; customers complain about wrong items.

Too early or not needed: a small warehouse with a hundred SKUs gets by with the accounting system's warehouse module and some discipline. A full SCM is excessive while purchasing fits in one person's head.

If you sell online, the e-commerce storefront becomes a second source of orders — and stock accuracy matters more there than in wholesale.

Dependencies and sequencing. This domain comes after the accounting one: the warehouse needs a clean item master and a flow of orders, both born in ERP and the reference data. A WMS on an untidied item master arranges the same mess by address. Inputs: orders and items from ERP and from MDM and PIM — MDM the master record, PIM the attributes, without which you build neither the storefront nor the storage rules (dimensions, temperature regime, shelf life). Output: actual movements into ERP and indicators into analytics.

What the domain gives the business — and its typical drawbacks

Effect. Speed and accuracy: orders picked faster and without mis-picks, so fewer returns and claims. Money: stock stops being a dump — you see what lies dead and what is perpetually short. Independence from individuals: warehouse knowledge lives in the system, not in the head of the storekeeper with twenty years of service.

Drawbacks people talk about less. The domain is hardware-hungry: terminals, network coverage across the whole floor, sometimes re-racking — capital costs that surface after the software is chosen. Implementation happens on a working warehouse that cannot be stopped, and the transition is always painful. And resistance: to an experienced storekeeper the system looks like distrust of their memory — which is a real asset the system has to absorb rather than devalue.

The 2026 context

Traceability keeps spreading into new product groups, and GS1 batch and serial identification is becoming a default expectation, not a differentiator — the logistics domain has moved from "when we grow into it" to mandatory for a lot of companies. E-commerce pushes from the other side: a customer who sees stock levels on a website will not accept "we thought we had it". And where the chain crosses borders, buyers ask suppliers for movement data rather than a confirmation email.

A sense of scale. A single-warehouse implementation typically runs three to eight months. Cost is driven by floor area, number of SKUs, how many pick faces and dock doors, how many shifts need terminals. What is never in the software price: data-collection terminals for every shift, industrial Wi-Fi across the whole area, label printers and servers. On a mid-sized warehouse that hardware is comparable to the system itself. Have it costed after a site survey.

How the four domains connect

These classes are rarely bought as one project, because each has a different internal sponsor: MES from production, EAM from the maintenance director, QMS from quality, WMS from logistics. That is exactly why they drift apart: four systems, four equipment registers, four versions of what happened on the shop floor.

The shared foundation is digitised actuals. All four answer one question: what is happening to a physical object right now. As long as actuals are captured by hand and reach the system at the end of the shift, any of them becomes a reporting system instead of a management system. That is the bottom level of the pyramid, without which the upper floors feed on manual entry.

The order of moves. The production stack is worked before ERP or alongside it, not after. Asset management goes in parallel: EAM takes equipment operating data from SCADA and IIoT, and without an asset register it does not start at all. The quality domain sits on top of production record-keeping. The warehouse goes the other way, after the accounting domain: it needs the item master and order flow born in ERP and the reference data.

Where they exchange data. The production stack passes actuals upward — to ERP, analytics and EAM. EAM sends equipment condition back down: a faulty unit is both a defect source and a risk to people, so quality and industrial safety both need it. Quality sends results into audits, into reporting and back into the process. The warehouse sends actual movements into ERP. If the product is your own design, the process definition and its requirements come from the engineering domain — from product data, not a process engineer's memory.

One set of reference data for four systems. The most expensive divergence here is reference data, not integration. Equipment, items, sites, departments have to be the same across all four. Entering them afresh in each means four masters, which is the same as none. Reference data work is therefore not a preparatory stage of one project but a precondition for all four; it is covered in the article on data and documents.

What happens when the order is broken. A company installs predictive diagnostics on a reactive maintenance culture. Buys a WMS on an untidied item master. Implements a quality system for the certificate, before production record-keeping exists. In all three the technology works exactly as the vendor promised and there is no result — because what got automated was the disorder, and now it reproduces quickly and reliably.

Where AI fits in the production stack

Of the six parts of this series, this is where AI has the longest history and the most honest results. Machine vision and predictive diagnostics have worked in industry for years — which is precisely why it is easiest to see here what makes them fail.

What AI already solves. In production, three scenarios. Machine vision on quality control: defects caught on the line, not in the finished-goods warehouse. Prediction of process deviations: the model notices parameters drifting before the operator. And a control-room assistant that triages alarms and suggests a probable cause from history. In assets: predictive maintenance from sensor data, prioritising work requests against a limited crew, parsing free-text defect descriptions. In quality: visual inspection of surface, completeness and labelling, classification of complaints by theme and cause, checking protective equipment on video. In logistics: demand forecasting — the most mature AI application there is — optimisation of picking and delivery routes, recognition of goods and documents at receiving, prediction of late deliveries from a supplier's history.

What is coming (a forecast, not a fact). Agents proposing a re-planned shift after a breakdown. Assistants drafting a maintenance schedule against spares and crew load. Prediction of defects from process parameters before the defect appears. Replenishment agents preparing a supplier order for a human to confirm.

Conditions without which nothing takes off. Data first: labelled history — defects, downtime, parameters, failures over two or three years — and a clean item master. On a paper-based site there is nothing to build from, and a model trained on work orders closed retroactively predicts fiction. Processes: a stable process definition and recording discipline before any AI — a model trained on chaos predicts chaos. People and safety: a named owner for every scenario; the model's recommendation is an input to a human decision, not a command to equipment; the control system network stays a separate security zone with minimal rights into it. Video needs its own note: what is filmed, who watches it and why are agreed with people before the cameras go on, or the system collects resistance instead of data.

Three ways to waste the money. Described in Dzhimsher Chelidze's book "Artificial Intelligence. A Practical Guide to Implementation", and all three occur here more often than anywhere else.

The first is data quality (trap No. 5, "data quality is ignored"). A machine vision pilot without proper lighting or labelling: three months later the conclusion is "AI does not work", when what failed was the preparation. One special case is particularly treacherous: the model is trained on a batch with almost no defects, because production is good. It learns that everything is fine, shows excellent accuracy on the test set, and misses exactly the rare defects it was installed to catch.

The second is no scaling plan (trap No. 6). Here the failure looks like success: the pilot worked. The model optimised picking in one warehouse, showed attractive percentages — and stayed a pilot forever, because nobody thought about roll-out: no integrations, no owner, no support budget. The remedy from the same source: design the scaling during the pilot, not after.

The third is the unexplainable decision. Among the mandatory checks before industrial go-live the book names an explainability crash test: can you explain the system's decision if you have to defend it. Here that is not a formality. A reject decision affects a shipment, a claim and occasionally a court case. A model that says "defect" without saying what and where is a generator of arguments, not a quality tool.

The honest boundary. AI here replaces neither SCADA, nor MES, nor the asset register, nor WMS. It is a layer on their data. The top floor does not get built without a foundation: predictive maintenance without failure history, and vision without labelling, is sponsorship of a vendor's presentation, not a project.

Vendors you will actually meet

Names you will run into on projects here, grouped by the same subclasses. No market shares, no prices, no rankings. Availability, implementation partners and industry configurations differ a lot between the EU, the US, the Gulf and Southeast Asia, so treat this as a starting vocabulary.

• MES and manufacturing execution — Siemens Opcenter · AVEVA · Rockwell Automation · GE Vernova Proficy · Honeywell

• SCADA and HMI — AVEVA · Ignition by Inductive Automation · Rockwell Automation · GE Vernova Proficy

• IIoT and industrial platforms — PTC ThingWorx · AVEVA · GE Vernova Proficy

• EAM and maintenance management — IBM Maximo · Hexagon EAM (formerly Infor EAM) · SAP PM/EAM · Fiix and UpKeep in the mid-market

• Laboratory and quality control — LabWare · LabVantage

• Quality management and compliance — Sparta Systems TrackWise · ETQ

• EHS and environment — Intelex · Cority · ETQ

• WMS — Manhattan Associates · Blue Yonder · Körber · SAP EWM · Oracle WMS

• TMS, supply chain planning and visibility — Blue Yonder · Manhattan Associates · project44

For three segments no short honest list exists, and it is worth knowing that in advance. Building management (BMS/BAS): wide and fragmented; what fits your facility is checked against references in your own building type. Mobile rounds and predictive diagnostics: usually EAM modules, or separate products tied to the sensor estate you already have. Quality and safety: strongly industry-specific; the choice turns on which standards a solution has already been configured against — proven in pharmaceuticals is not automatically right for metals.

The general rule for all four domains: the choice depends far more on the physics of your plant than on the brand. Mechanised, manual, cold-store and location-managed warehouses each need different logic. Discrete and continuous production need different MES. Start by describing your operations, not by comparing feature tables.

Typical mistakes and a selection checklist

The mistakes in these four domains repeat almost word for word, so here they are in one list.

1. Automating before digitising the actuals. MES executes a model of the process; with no model there is nothing to execute. A WMS arranges the same mess by address, only now you have paid for it. A quality domain installed before production record-keeping manages something unmeasured.

2. Maintenance management without an asset register. Nothing to attach the work requests to — the system hangs over an empty catalogue.

3. Digitising reactive chaos. If maintenance lives in firefighting mode, the system puts the fire on a regular schedule.

4. Saving on infrastructure. Terminals, network, servers, sensors, sometimes racking — a separate budget line, not "implementation sundries". Slow response sends people back to spreadsheets.

5. Implementing without the shop floor, the warehouse and the maintenance crews. A top-down project without supervisors, engineers and storekeepers meets quiet sabotage rather than an argument. There will be data, and it will not be trustworthy.

6. Quality for the certificate. A domain configured for the audit instead of the process produces paperwork and no fall in defects.

7. Mistaking indicators for reality. Full completion of preventive maintenance alongside rising downtime signals formal reporting, not order.

8. Punishing people for reporting problems. The system starts receiving clean data about a flawless operation. And separately: a rise in recorded non-conformances in the first year is not deterioration. There are not more of them, they have become visible.

9. Planning inventory on averages. A forecast without seasonality and promotions delivers stockouts and dead stock at once.

10. Starting with AI and skipping the foundation. Vision and prediction are layers on top. And separately: leaving a successful pilot as a pilot, with no roll-out plan, wastes the same money with a nicer report.

Checklist before choosing a system

1. Your own operations are described — process definition, maintenance cycle, non-conformance investigation, receiving and picking. Before comparing systems, not during the project.

2. Reference data is in order: assets, items, sites, departments. Its quality decides the outcome more than the choice of system — I would start there.

3. The pilot is assigned to one area, shop or warehouse zone, with a measurable criterion: accuracy of actuals capture, share of planned maintenance, picking time, mis-pick rate, before and after.

4. Infrastructure is costed as its own line: network coverage, terminals, servers, sensors, training for every shift.

5. Integrations tested on live data: downward to SCADA and instruments, upward to ERP, the MRO store and analytics.

6. Mobile workplaces in the base package: three of the four domains live in the field, not at a control-room desk.

7. A business owner named, by name: production, the maintenance director, quality, logistics. Not IT.

8. There is a transition plan for a live site: what happens during changeover, who is on call, how you roll back. You cannot stop a warehouse or a shop floor for a weekend.

9. There is a plan for working with people — training, motivation, explaining why — as part of the project, not an appendix.

What next

The overall map of classes is in Types of enterprise IT systems. Other parts of the series: Customers and sales · Money, planning and analytics · Data and documents · Routine automation and AI · People and the IT function · IT infrastructure.

To go deeper: Dzhimsher Chelidze's books "Digital Transformation for Directors and Owners" and "Artificial Intelligence. Freefall" — free download — and "Artificial Intelligence. A Practical Guide to Implementation", quoted above.