Production Software: Stack, Layers & Choices

What is production software?

Production software is the layered stack of digital systems that plans, executes, monitors and analyses manufacturing operations — from the ERP system that releases the production order down to the PLC that moves the actuator. The textbook answer lists the components: ERP, MES, SCADA, PLC, PPS, QMS, CMMS. The honest answer is that "production software" is not one thing and was never supposed to be. It is a stack of five distinct layers, each with a specific job, each with its own vendor landscape, each with its own lifecycle. Most manufacturing software projects that disappoint do so not because any individual component was bad, but because someone tried to make one layer do another layer's job and the mathematics of the stack would not allow it.

I have spent 35 years building and selling production software — starting as a consultant at SAS in 1989, running the industrial division at STERIA for process-control and MES projects in food and beverage, and founding SYMESTIC in 1995. For the first 20 years we built classical on-premise MES — server rooms, customized deployments, 12-to-18-month rollouts. In the mid-2010s we threw that codebase away and rebuilt the platform cloud-native from scratch. That decision, made uncomfortably and with no guarantee of success, turned out to be the most important strategic call of the company's history. This article is the view from someone who has built production software across both eras — and has opinions, based on what actually happens when a mittelständisch plant tries to buy it.

The ISA-95 stack — the only framework that matters

The serious way to think about production software is the ISA-95 layer model. It is an international standard, it has been stable for more than two decades, and it describes the functional separation between systems in a way that survives almost every vendor's marketing claim. If a vendor cannot tell you which ISA-95 level their product lives in, that is useful information — it usually means the product has drifted across levels and accumulated scope it cannot defend. The five levels are not optional categories; they correspond to genuinely different time horizons, data granularities and organisational responsibilities.

The practical rule that falls out of this framework: each level should do its own job and talk cleanly to its neighbours. An ERP should not try to schedule a shift on a bottleneck press; that is a Level-3 job and the ERP does not have the data. An MES should not try to be a SCADA system; that is Level 2 and the required latency is two orders of magnitude tighter. A PLC should not try to store six months of production history; that is Level 3 and the PLC has no storage model for it. Almost every dysfunctional production-software landscape I have seen in 35 years has at least one of these level violations at its root.

The four strategic options — and the tradeoffs that actually matter

When a mittelständisch plant decides it needs more production software, there are four strategic options on the table. They are not equally good; they are good for different situations, and confusing the situations is where most procurement mistakes are made.

The option that burns the most money in the mid-market is the "best-of-breed stack" approach, because the integration cost between five specialist tools always looks smaller on the proposal than it turns out to be in practice. The option that delivers the most disappointment is the "ERP extension" path, because ERP vendors have been promising real-time shop-floor capability for two decades and it still is not their core competence. The option that works for roughly 80 % of the mittelstand — and I say this having sold every category including the first two — is a dedicated MES suite, cloud-native, modular enough to extend without a new project, deep enough to cover the real Level-3 scope. That is a positioning statement, not a neutral analysis. I stand behind it because the data from 15,000+ connected machines across 18 countries keeps confirming it.

On-premise vs. cloud-native — the strategic shift of our generation

The most important change in production software in the last decade has nothing to do with AI, Industry 4.0 or any of the other narratives the industry prefers to talk about. The most important change is that the architecture of production software itself shifted from on-premise monoliths to cloud-native services — and this change rendered most of what the industry "knew" about implementation timelines, costs and scalability obsolete. I can say this with some confidence because we lived through the transition at SYMESTIC and bet the company on it.

Personal perspective on the mid-2010s architecture decision: in 2014 we had a working on-premise MES product with paying customers. It was installed in server rooms across Germany, it did what it was supposed to do, and every new customer took us six to twelve months to roll out because that was the physics of the architecture. We had a choice: lift-and-shift the code to a cloud VM and call it "cloud MES" (what most of our competitors did), or throw the codebase away and rebuild cloud-native from scratch on Azure with microservices, API-first and a real multi-tenant data model. We chose the second path. It was expensive, it took years, and there were nights when it looked like the wrong call. By 2019 the new platform was carrying customers live. By 2024 it was running in 18 countries with 15,000+ connected machines and a zero-churn year. The lift-and-shift competitors have spent the same decade slowly bolting cloud-ish features onto on-premise DNA and are now trying to catch up. The lesson I took from that period: cloud-native is not a deployment choice, it is an architectural choice, and the difference shows up in implementation timelines, scalability behaviour and total cost of ownership for the next twenty years.

The integration tax — the line item nobody talks about

Every production-software conversation eventually arrives at cost, and the cost conversation is almost always wrong in the same direction. The discussion focuses on licence fees, implementation services and hardware. It ignores — or badly underestimates — the single biggest line item in the total cost of a production software landscape: integration. Integration is the work of connecting the Level-3 system to the ERP above it, to the Level-1/2 systems below it, to the quality system beside it, to the maintenance system alongside it, and to the CAD, PLM, WMS and whatever else the plant already runs. In mid-market production software, integration is typically 40–60 % of the total implementation effort, and it is the single most common place where projects run late and over budget.

The honest way to reason about the integration tax is per interface, and per protocol. An ERP-to-MES bidirectional interface to SAP R/3 via ABAP IDoc is a specific piece of work with a specific cost profile; a file-based interface to a Navision system is a different piece of work with a different profile; an OPC UA connection to a modern CNC is different again. The integration architecture — hub-and-spoke, point-to-point, event-driven — determines whether the cost scales linearly or quadratically as interfaces are added. Cloud-native platforms with a canonical data model and REST/OPC UA as the native integration layer typically land on linear scaling. Legacy integration built point-to-point typically lands on quadratic, and the cost of the eleventh interface is several times the cost of the first.

What this looks like for a real customer

The best way to make this concrete is to look at what a cloud-native production-software rollout actually delivers across the real installed base. Across SYMESTIC's 15,000+ connected machines in 18 countries, the pattern is consistent: production-metrics coverage live in under one month for a typical 10-machine line, full MES scope live in under six months, bidirectional ERP integration (SAP R/3 via ABAP IDoc is the most common) as a standard work package rather than a custom project, and a modular catalogue that lets the customer extend to new machines, new plants and new use cases without re-engaging the vendor for every addition.

The named references tell the same story from different industries. Meleghy (automotive body-in-white, six plants across Germany, Spain, Czech Republic and Hungary) rolled out enterprise MES across all six sites in six months with bidirectional SAP IDoc integration and saw 10 % fewer stoppages, 7 % higher output and 5 % higher availability. Brita (FMCG) instrumented highly automated assembly lines in Germany and the UK without a pre-PoC, surfaced previously invisible stops through digital signal capture, and now extends coverage self-service through the modular catalogue. Carcoustics (automotive injection moulding and stamping) replaced an incumbent MES in Poland and Haldensleben and scaled to 500+ machines across the group in six months via MQTT and Azure. Kamps (food) connected bakery lines via OPC UA to Rademaker and König equipment. Klocke (pharma, non-validated processes) instrumented packaging lines via digital I/O gateways with no LAN dependency and saw 12 % output improvement within three weeks. Five different industries, five different integration profiles, one platform — that is what the cloud-native architecture makes possible, and it is why the architectural decision of the mid-2010s was worth the risk.

FAQ

What is production software?
Production software is the layered stack of digital systems that plans, executes, monitors and analyses manufacturing operations. It spans five ISA-95 levels from ERP at the top (business planning, days-to-months horizon) down through MES (manufacturing operations, shifts-to-hours), SCADA (supervisory control, seconds-to-minutes), PLC (real-time machine control, milliseconds) and the physical process itself. Each level has a specific job, a specific time horizon and a specific vendor landscape. Most dysfunctional manufacturing-software landscapes I have seen stem from one level trying to do another level's job.

What is the difference between ERP, MES and SCADA?
ERP is Level 4 — business planning, order management, finance. Its time horizon is days to months. MES is Level 3 — operational manufacturing: order execution on the shop floor, performance tracking, quality, traceability, maintenance. Its horizon is shifts to hours. SCADA is Level 2 — supervisory control of the process, operator HMIs, batch execution. Its horizon is seconds to minutes. They are not interchangeable and they are not optional alternatives; they serve different decisions at different cadences and a well-run plant has all three working in their own lanes.

Can an ERP system replace an MES?
In narrow circumstances yes, in most real discrete-manufacturing environments no. ERP vendors have been promising to cover Level 3 for two decades, and the shop-floor modules they offer can work for simple discrete manufacturing with low automation. For plants with heterogeneous machine parks, high automation, real-time performance requirements or cycle-level data capture, the ERP extension consistently underdelivers. The mathematics of the ERP data model — batch-oriented, order-centric, latency-tolerant — does not match the physics of real-time shop-floor operations. An ERP is the right tool at Level 4. Forcing it down into Level 3 is the most common root cause of disappointing manufacturing-IT projects.

What are the four strategic options for production software?
ERP extension (shop-floor module of the existing ERP), dedicated MES suite (purpose-built Level-3 system), best-of-breed stack (specialist tools integrated by the customer), and custom build (in-house development). ERP extensions fit simple discrete manufacturing but break under heterogeneous machine parks. Dedicated MES suites fit roughly 80 % of mittelständisch discrete and batch manufacturing — the mainstream right answer. Best-of-breed stacks fit large enterprises with strong internal integration capability; they consume more than they save in the mid-market. Custom builds make sense only for truly unique processes with strong internal IT and a clear five-year TCO case.

Cloud-native or on-premise — which is better for production software?
Cloud-native is the right default for over 90 % of manufacturing companies in 2026. Implementation times are an order of magnitude shorter (days to weeks for production metrics vs. 6–18 months for classical on-premise), there is no customer infrastructure to operate, updates are continuous rather than biennial upgrade projects, and per-site scaling is days instead of months. On-premise still makes sense in regulated environments with explicit data-residency mandates that cloud cannot satisfy, plants with no viable internet connectivity, and defence-adjacent production. Those categories shrink every year. The crucial distinction is between cloud-native (built for the cloud from the architecture up) and lift-and-shift cloud-ish (on-premise software running in a cloud VM) — the second category looks like cloud on the invoice and behaves like on-premise in every other respect.

What is the integration tax in production software?
Integration is the work of connecting the production-software stack to everything around it — ERP above, machines and SCADA below, quality system beside it, maintenance system alongside, plus CAD, PLM, WMS and whatever else the plant runs. In mid-market production software, integration is typically 40–60 % of the total implementation effort and the single most common place where projects run late and over budget. The integration tax is almost always understated in procurement documents and almost always underestimated by buyers. The scale depends on the integration architecture — cloud-native platforms with a canonical data model and REST/OPC UA as the native integration layer typically scale linearly; legacy point-to-point integration scales quadratically as interfaces are added.

How long does a production-software implementation take?
It depends almost entirely on the architecture and the scope, not on the size of the plant. For cloud-native production metrics on a 10-machine line, under one month to go-live is the SYMESTIC standard; for full MES scope across a site, under six months. Classical on-premise MES averages 6–18 months per site because each deployment is effectively a separate project. The multi-site rollout pattern tells the same story: Meleghy went from single-plant pilot to six-plant enterprise rollout in six months on cloud-native; the same scope on a classical on-premise codebase would have been a 3–4-year programme.

Why do production-software projects fail?
The failures I have watched across 35 years cluster into three patterns. First, level violations — trying to make an ERP do Level 3 or an MES do Level 2. Second, underestimating the integration tax — starting the project with a realistic view of the product cost and a fantasy view of the integration cost. Third, choosing architecture by vendor familiarity rather than by fit — picking the tool the IT department already knows rather than the tool the manufacturing organisation needs. These three together explain the overwhelming majority of manufacturing-software disappointments I have personally seen. The software itself is rarely the problem; the decision about which software to use for which job almost always is.

How does SYMESTIC fit in the production-software stack?
Cloud-native Level-3 MES — purpose-built for manufacturing operations, covering order execution, performance metrics, quality, maintenance, energy, traceability and process data in a modular catalogue. Integrates upward to ERP via SAP ABAP IDoc, Navision, proAlpha, Infor and REST for the rest. Integrates downward to machines via OPC UA for modern controls and digital I/O gateways for brownfield equipment with no native digital interface. Implementation in days to weeks for production metrics, under six months for full MES. 15,000+ connected machines in 18 countries, zero customer churn in 2024, and around 150 % SaaS growth that same year — the honest numbers that the architectural decision of the mid-2010s enabled. See SYMESTIC Production Metrics.

Related: MES · Cloud MES · MES Software · ISA-95 · SCADA · ERP-MES Integration · OPC UA · SYMESTIC Production Metrics

About the author

Uwe Kobbert

Founder and CEO of SYMESTIC GmbH. 35+ years in manufacturing software — consultant at SAS from 1989, industrial division lead at STERIA for process-control and MES projects in food and beverage, founder of SYMESTIC in 1995 in Dossenheim near Heidelberg. Led the mid-2010s decision to discard the on-premise codebase and rebuild the platform cloud-native on Microsoft Azure — the architectural call that now carries 15,000+ connected machines in 18 countries with zero customer churn in 2024. Nominated for the Großer Preis des Mittelstandes. Dipl.-Ing. Communications Engineering/Electronics. Self-financed, no external investors. · LinkedIn