Digital Manufacturing: From Buzzword to Execution

What is digital manufacturing?

Digital manufacturing — sometimes called smart manufacturing (the US-flavoured variant), digital factory, or the operational side of Industry 4.0 — is the ongoing discipline of using connected data, software and automation to run factories more productively than analogue operations can. It is not a project, not a technology, not a product category. It is the day-to-day practice of treating a manufacturing operation as a software-instrumented system rather than a collection of machines with clipboards between them. The distinction matters because most organisations conflate digital manufacturing with Industry 4.0 and expect it to arrive as a finished state. It doesn't. It is executed one machine, one data stream, one integration at a time — and that execution is where roughly nine out of ten programmes fail.

I have spent the last twelve years building the platform that does this at scale. Joined SYMESTIC in 2014 as a software developer directly out of my Bachelor's in Business Informatics at SRH Hochschule Heidelberg; CTO since 2020. My job today is to make sure machine data from every plant in our installed base — modern and brownfield, OPC UA and digital I/O, greenfield automation and presses from 1995 — arrives reliably, securely and in near-real-time in the cloud. Across 15,000+ connected machines in 18 countries on four continents, the platform processes around 50,000 data points per second with 99.9 % availability. Those numbers are relevant to the discussion because they mean I can't afford to treat "digital manufacturing" as a marketing concept. It has to actually work, at scale, on heterogeneous equipment, under real network conditions, every shift.

Digital manufacturing vs Industry 4.0 vs smart factory — the terms are not synonyms

The single most widespread source of confusion in this space is the treatment of four distinct terms as interchangeable. They are not, and the distinction is not academic — each of them implies a different scope, different responsibilities, and different success criteria. Getting the terms right is the first step toward not wasting budget on the wrong programme.

The practical consequence: an "Industry 4.0 programme" owned by a corporate strategy function typically produces PowerPoint and roadmaps. A "smart factory project" owned by plant engineering typically produces a capital expenditure proposal. A digital manufacturing initiative owned by operations produces actual integrated machines, measurable OEE gains, and a data foundation that keeps producing value after the consultants leave. Companies that don't separate these levels tend to buy the wrong thing from the wrong vendor and measure the wrong outcome.

Why most digital manufacturing programmes fail — and it is not the software

My strongest and most consistently-validated observation from running the engineering side of SYMESTIC for the past twelve years: digital manufacturing programmes almost never fail because of the software. They fail at implementation. Too long, too complex, too expensive. The ratio I see is roughly 8:2 — eight out of ten failed programmes fail for execution reasons (scope, connectivity, integration, change management), and two out of ten fail because the chosen software genuinely could not do the job. The industry discourse is dominated by the 20 % case, which means most buyers focus their selection process on the wrong variable.

The architectural decision that changed SYMESTIC's trajectory. Mid-2010s, the company faced a choice most enterprise software vendors of the time got wrong: lift and shift the existing on-premise MES into a cloud-hosted deployment, or rebuild from scratch as cloud-native. Lift-and-shift is faster to ship and preserves feature parity with the on-premise product. We chose rebuild. Every architectural decision — microservices on Microsoft Azure, API-first, stateless services behind a managed ingress, time-series database for cycle-level telemetry, event-driven messaging between services, IoT gateways as the only OT-facing component — was made for scalability, real-time capability, and operational maintainability. It took longer to ship the first production version. It also meant that when a customer later asked to connect 200 machines at once, the platform auto-scaled and handled it; when a different customer asked to deploy in China with local data residency, the architecture accommodated it without a redesign. A lift-and-shift deployment would have required a migration project for each of those scenarios. This is the difference that "cloud-native" actually makes in practice, and it is invisible until the first time your architecture is tested against a real demand it was never specifically designed for.

The failure modes that dominate the 80 % implementation-failure category are predictable and repeat across industries. The table below is drawn from my own post-mortems of projects where the initial deployment went sideways, both our own and competitors' that customers subsequently asked us to replace.

None of these failures are software defects. All of them are execution failures that a well-chosen platform can reduce but cannot eliminate on its own. The buyer's job during platform selection is to evaluate not the feature list but the execution characteristics: time-to-first-value, brownfield compatibility, integration ergonomics, operational simplicity. The vendor scorecard industry tends to reward the opposite.

The 5-layer cloud manufacturing architecture

Digital manufacturing platforms that work at scale share a common architectural shape, regardless of vendor branding. The SYMESTIC architecture is organised in five layers, each with a specific responsibility, specific failure modes, and specific integration points. Understanding the layering is the fastest way to separate genuine digital-manufacturing platforms from monoliths with a cloud sticker on them.

The architectural test that separates real platforms from marketing: can layer 5 be updated, versioned, and scaled independently of layers 1–4? In a monolithic lift-and-shift MES, the answer is usually no — changing the analytics layer means redeploying the whole stack, which creates migration pain for every customer every release. In a properly cloud-native platform, each layer has its own lifecycle. That is the architectural difference that makes the operational difference between a platform that auto-scales when you add 200 machines and a platform that requires a 4-week upgrade project to do the same.

Connectivity — what actually works, machine by machine

The single most over-simplified discussion in digital manufacturing is connectivity. Vendor marketing says "we support OPC UA." Real factories contain mixed fleets where half the machines predate OPC UA by decades. A digital-manufacturing platform that only works on greenfield equipment is not a platform, it is a demo. The table below is the actual decision matrix my team applies when scoping a new customer's plant — not the theoretical one.

The phrase "without PLC modification" in column 4 is load-bearing. Customers who have been quoted traditional MES connectivity are used to hearing that bringing a machine online means programmers in the controller for several days — which triggers revalidation, change control, and production shutdowns. Modern connectivity architectures do not require this. A digital I/O gateway reads signals that are already being produced by the machine; an OPC UA bridge reads from the controller's native interfaces. Neither approach modifies the machine's behaviour or requires production downtime beyond the physical mounting of the gateway. When someone tells you their digital-manufacturing project needs a 6-month machine-retrofit phase before any data starts flowing, what they actually need is a different connectivity approach.

IT/OT convergence — the organisational problem that kills more projects than the technical one

The most expensive recurring pattern in digital-manufacturing programmes is not a technology failure. It is the organisational stalemate between the IT department, which owns the corporate network and the cloud tenancy, and the OT department (Operational Technology — plant engineering, maintenance, automation), which owns the machines and the production network. Historically these two groups operated separately with minimal overlap. Digital manufacturing forces them to operate the same integrated system, and the political, procedural, and cultural friction that creates is — in my experience — the single largest consumer of project calendar time.

The specific friction points are consistent across industries. IT wants every machine on the corporate network for security and patchability; OT can't allow that because half the machines run unsupported operating systems and cannot be patched without revalidation. IT wants change control with 4-week lead times; OT needs changes applied in the next shift or the line stops. IT's security team flags every outbound data connection from the plant; OT's data must flow to the cloud in real time for the platform to work. These are not unsolvable problems, but they are not technology problems — they require explicit governance, clear ownership of the bridge layer, and usually a new role (often titled "manufacturing IT" or "digitalisation lead") that reports into neither pure IT nor pure OT. Programmes that don't create this role or its equivalent tend to stall in month three, which is roughly when the first real integration decision requires both sides to agree.

Digital twin, AI, predictive maintenance — separating operational reality from vendor slideware

The buzzword layer of the digital-manufacturing discussion deserves its own skeptical treatment. Digital twins, machine learning, AI-driven predictive maintenance and autonomous optimisation are real technologies with real applications. They are also wildly oversold, and the gap between what they do in production and what they do in vendor demos is significant enough that buyers are regularly disappointed.

My strong operational view: buy the base data layer before you buy anything on this list. A plant that has real-time OEE, automated downtime capture, and integrated alarm correlation is in a position to benefit from predictive maintenance or AI optimisation layered on top. A plant that still logs downtime on paper is not going to get value from a digital twin, no matter how good the vendor demo looks. The failure mode of buying the top of this list before building the bottom is what my failure-mode table above calls "cargo-cult architecture" — the fourth row of that table is specifically this mistake. Every buzzword on this list is real and valuable in the right context. None of them is a shortcut past the unglamorous work of getting clean data out of your machines in the first place.

What digital manufacturing looks like at operational scale

Across the SYMESTIC installed base, the pattern of what "digital manufacturing" actually looks like when it is delivering value is consistent enough to describe concretely. Modern controls connect via OPC UA in 1–2 hours per machine; brownfield equipment connects via digital I/O gateways in 2–4 hours, with no PLC modification and no production interruption. Data flows to Microsoft Azure through an IoT gateway layer with local buffering for network interruptions and end-to-end TLS. The analytics layer — dashboards, reports, KPIs — updates in near-real-time rather than by batch export. Integrations to ERP (SAP, Dynamics, proAlpha, Infor), quality systems (CASQ-it, LIMS), MES-adjacent tools (WMS, APS) use REST APIs on the cloud side rather than point-to-point connectors.

The customer outcomes are consistent with the architectural shape. Meleghy Automotive (body-in-white forming and joining, six plants across Germany, Spain, Czech Republic and Hungary) landed a full rollout in six months, with bidirectional SAP R3 integration via ABAP IDoc, 10 % reduction in downtime, 7 % higher output. Carcoustics (acoustic and thermal solutions, 500+ machines across seven countries including Poland, Slovakia, Mexico, USA, China) connected via IXON IoT devices and MQTT to Azure, replacing a previous solution, producing 8 % availability improvement and 3 % higher output. Klocke (pharma packaging under GMP, Weingarten) scaled in three weeks from a pilot line to all lines at the site using digital I/O gateways without any LAN retrofit, gaining seven additional production hours per week. Neoperl (water-flow products, Müllheim) used PLC alarm correlation with downtime and quality data as its digital-manufacturing foundation, producing 15 % less scrap and 15 % higher productivity. In each case the architectural pattern is the same — cloud-native platform, layered connectivity matched to machine class, IT/OT bridge as an explicit service, incremental scope expansion. The variable that differs is the customer's process; the constant is the architecture.

FAQ

What is digital manufacturing?
Digital manufacturing is the ongoing discipline of using connected data, software and automation to run factories more productively than analogue operations can. It is the operational execution of the Industry 4.0 vision — not a product, not a project, not a state of completion, but a day-to-day practice of treating manufacturing as a software-instrumented system. The enabling technologies include IIoT, cloud platforms, edge computing, digital twins, AI/ML, and integrated MES/ERP/PLM/APS/QMS stacks, but the discipline is bigger than any of those technologies individually.

What is the difference between digital manufacturing and Industry 4.0?
Industry 4.0 is the vision/policy framework, originally launched as a German federal initiative in 2011. It describes a future state of interconnected, data-driven manufacturing. Digital manufacturing is the ongoing operational discipline of executing that vision in actual factories. Industry 4.0 is what is promised in policy documents and industry association white papers; digital manufacturing is what happens on Monday morning when you actually have to connect a press from 1995 to a cloud MES. Conflating the two is how companies end up with impressive-looking roadmaps and zero measured OEE improvement.

What is the difference between digital manufacturing and smart manufacturing?
Largely the same discipline under different regional branding. "Smart manufacturing" is the more common US term, particularly associated with the Smart Manufacturing Leadership Coalition and the Clean Energy Smart Manufacturing Innovation Institute. "Digital manufacturing" is the more common European term, particularly in the German-speaking manufacturing industry where it sits in direct relationship to the Industrie 4.0 framework. The content and techniques are essentially identical; the labelling reflects regional industry bodies rather than methodological differences.

What is the difference between digital manufacturing and a smart factory?
Digital manufacturing is the ongoing discipline — how a plant operates today and how it evolves. A smart factory is the target architectural end-state — what a plant looks like when its digital manufacturing programme has matured. The distinction matters operationally: digital manufacturing is what you do every shift, smart factory is what you build over three to five years. A "smart factory project" without an underlying digital manufacturing discipline tends to produce an impressive building with the same paper-based downtime logs as before.

Why do most digital manufacturing programmes fail?
Implementation, not software. In my experience running the engineering side of a platform with 15,000+ connected machines, roughly 80 % of failed programmes fail at execution — scope overreach, connectivity assumptions that don't survive first contact with brownfield equipment, IT/OT political stalemates, cargo-cult architecture (buying advanced capabilities before base signals are flowing), and lack of a sustainment plan to scale successful pilots. Only about 20 % fail because the chosen platform genuinely could not do the job. The industry discourse focuses on the 20 % case, which is why most buyers over-index on feature comparisons during selection and under-index on execution characteristics.

What is the difference between cloud-native and lift-and-shift MES?
A cloud-native platform is designed for cloud deployment from the ground up — microservices, stateless services, API-first, event-driven, auto-scaling, multi-tenant by default. A lift-and-shift MES is an on-premise product that has been deployed in a cloud environment without architectural rework — monolithic, stateful, typically single-tenant per instance, does not auto-scale. Both can be called "cloud MES" in marketing materials. The operational difference appears when you need to scale (cloud-native does, lift-and-shift requires migration projects), update (cloud-native rolls out continuously, lift-and-shift requires customer-side upgrade windows), or deploy globally (cloud-native accommodates regional residency by design, lift-and-shift needs per-region deployments). The architectural rebuild that SYMESTIC did in the mid-2010s was specifically to produce a cloud-native platform rather than a cloud-hosted monolith.

How do you connect legacy machines to a digital manufacturing platform?
Four approaches by machine class. Modern PLCs (post-2010) connect via their native OPC UA server in 1–2 hours per machine. Mid-era PLCs with Ethernet but without OPC UA connect through an OPC UA bridge that translates to S7, Modbus TCP, Ethernet/IP etc. in 2–4 hours. Legacy PLCs without network capability connect through digital I/O gateways that read cycle, state, and alarm signals directly from the wiring in 2–4 hours. Machines with no digital controls at all connect through retrofit sensors (proximity, vibration, current draw) feeding a digital I/O gateway in 4–8 hours. Crucially, none of these approaches require PLC modification, revalidation, or production downtime beyond the physical mounting of the gateway — the persistent claim that legacy machines require a multi-month retrofit project to participate in digital manufacturing is a decade out of date.

What is IT/OT convergence and why does it matter?
IT/OT convergence is the merging of traditionally separate Information Technology (corporate network, cloud tenancy, IT security, change control) and Operational Technology (plant network, machine controllers, automation, maintenance) into a single integrated system. It matters because digital manufacturing requires both domains to operate together — machine data flows from OT into IT-managed cloud platforms and back. In practice, the IT/OT organisational stalemate is the single largest consumer of project calendar time in digital manufacturing programmes, substantially larger than any technical challenge. Programmes that succeed typically create an explicit bridge function, often titled "manufacturing IT" or "digitalisation lead," that owns the integration layer and reports into neither pure IT nor pure OT.

What role does digital twin actually play?
Smaller than the vendor slides suggest, larger than skeptics claim. In production runtime, "digital twin" is often effectively a data-structure term for "the current state of a machine as represented in the platform" — not an active real-time simulation. The real active-simulation applications of digital twin are primarily at process design, commissioning, and scenario planning rather than at runtime control. This is not a criticism of digital twin as a technology; it is a caution about buying it expecting the demo-video use case when the practical use case is substantially narrower. The data foundation underneath a useful digital twin is the same data foundation you need for basic OEE measurement, which is why the sensible purchase order is the base layer first and the twin on top later.

How does SYMESTIC approach digital manufacturing?
Cloud-native architecture on Microsoft Azure, microservices, API-first, built ground-up rather than lifted and shifted. Connectivity matched to machine class — OPC UA for modern controls (1–2 hours), OPC UA gateway for mid-era Ethernet PLCs (2–4 hours), digital I/O gateways for legacy and unnetworked equipment (2–4 hours), retrofit sensors for entirely non-digital machines (4–8 hours) — never requiring PLC modification or production downtime. Real-time data processing at around 50,000 data points per second across the installed base, 99.9 % platform availability, auto-scaling for customer growth, multi-region deployment for data-residency constraints. Incremental scope expansion rather than big-bang rollout — customers typically start with a pilot line, scale to site within weeks, scale to enterprise within months. See SYMESTIC Production Metrics.

Related: MES · Cloud MES · Industry 4.0 · Smart Factory · IIoT · OPC UA · Edge Computing · Digital Twin · ISA-95 · Machine Data Acquisition · SYMESTIC Production Metrics

About the author

Mark Kobbert

CTO of SYMESTIC GmbH since 2020, at the company since 2014. Architect of the cloud-native SYMESTIC MES platform on Microsoft Azure — 15,000+ connected machines in 18 countries on four continents, around 50,000 data points per second, 99.9 % platform availability. Built the platform from the ground up as a cloud-native rebuild rather than a lift-and-shift from on-premise. B.Sc. Business Informatics, SRH Hochschule Heidelberg. Areas of expertise: cloud-native MES architecture, Microsoft Azure, microservices, OPC UA, MQTT, IoT gateway development, edge computing, ISA-95 integration, brownfield machine connectivity, REST APIs, IT/OT convergence. ·
LinkedIn