MES Challenges in Multi-Tool Manufacturing

𝗜𝘀 “𝗠𝗘𝗦 𝗘𝗿𝗿𝗼𝗿” 𝘁𝗵𝗲 𝗥𝗲𝗮𝗹 𝗥𝗼𝗼𝘁 𝗖𝗮𝘂𝘀𝗲 𝗶𝗻 𝗠𝗮𝗻𝘂𝗳𝗮𝗰𝘁𝘂𝗿𝗶𝗻𝗴? When a line stops, data disappears, or production delays occur on the shop floor, the first reaction is often the same —  many investigations quickly conclude:  “It’s an MES error.” It’s a quick answer. It closes the ticket. But it rarely fixes the system. In truth, most “MES errors” are signals, not causes. They reveal weak links in how data, logic, and people connect across IT + OT + QA,Maintenance 𝑾𝒉𝒂𝒕’𝒔 𝒓𝒆𝒂𝒍𝒍𝒚 𝒉𝒂𝒑𝒑𝒆𝒏𝒊𝒏𝒈 𝒃𝒆𝒉𝒊𝒏𝒅 𝒕𝒉𝒆 𝒔𝒐-𝒄𝒂𝒍𝒍𝒆𝒅 “𝑴𝑬𝑺 𝑬𝒓𝒓𝒐𝒓”? 𝙤 PLC-MES mapping isn’t aligned — signals miss triggers or duplicate events. 𝙤 Integration logic handles happy paths only; exception flows break 40% of the time. 𝙤 Process states aren’t clearly defined; interlocks behave differently by shift. 𝙤 Network spikes, database overloads, or missed synchronization delay data updates. 𝙤 VIN, BIN, or Tyre/TIN generation starts before barcode data flow — MES only sees half the story. 𝙤 Alarms exist, but priority and classification aren’t consistent — no one knows which matters most. 𝙤 OK/NOK booking counts vary between MES, SAP, QA, and operations — no shared truth. 𝙤 Change requests happen daily, but no change-management trail links them to the live environment. 𝙤 Machines go live before commissioning is complete; half their signals are still “test tags.” 𝙤 One new station or logic update breaks previous flows because dependencies were never mapped. 𝙤 Everyone asks how to bypass logic, not how to strengthen it. 𝙤 Excel and manual trackers still drive key decisions when supplier or robot data arrives late. 𝙤 Development often starts using admin DB accounts; later, access rules change — and transactions fail. 𝙤 There’s no negative MES checklist — everything is tested for success, not for failure. 𝙤 During downtime, no one knows who’s free to respond — visibility of resources is missing. 𝙤 Process teams don’t know routine vs. loop logic — MES sees “activity,” not “intent.” 𝙤 𝑯𝒐𝒘 𝒎𝒂𝒏𝒚 𝒂𝒑𝒑𝒔 𝒔𝒉𝒐𝒖𝒍𝒅 𝒃𝒆 𝒃𝒖𝒊𝒍𝒕 & System slowness and hang out The outcome :- A plant running at 30% capacity isn’t broken. It’s just waiting for someone to ask the right question. The smarter path forward :- ⚙️ Map data ownership — ERP → MES → PLC → QA+Maintenance. ⚙️ Build logic for both normal and exception flows ⚙️ Test in live-like conditions, not just labs ⚙️ Define governance for architecture, maintenance, and surge handling ⚙️ Train people on workflows, not just screens ⚙️ Create visibility on who owns, fixes, and improves each process Each “MES issue” is often a signal — not a failure. When teams stop asking “Who made the MES mistake?” and start asking “What in our system design allowed this to happen?”, that’s when reliability, traceability, and performance truly scale. 

I've discussed #MES/#MOM project difficulties with hundreds of people. Here's my take on the challenges that crop up time and time again: 1. 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻𝘀: Getting master data across systems (like ERP) to be at the right level of detail, or to be abstracted to be relevant for MES/MOM. Connecting to legacy equipment and databases. A lack of standardisation or contextual information in file formats. 2. 𝗖𝗵𝗮𝗻𝗴𝗲 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁: Operators and supervisors resist new processes. Without proper training and buy-in from the shop floor, even the best #MES system becomes unused. Onus is on leadership to set the vision and align teams. 3. 𝗨𝗻𝗿𝗲𝗮𝗹𝗶𝘀𝘁𝗶𝗰 𝗘𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀: Companies expect immediate ROI and perfect data from day one. Manufacturing transformation takes time, and data quality improves gradually as processes mature and people use the system more effectively. 4. 𝗜𝗻𝗮𝗱𝗲𝗾𝘂𝗮𝘁𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀: Underestimating the internal resources needed. IT teams are stretched thin, and manufacturing engineers often lack the bandwidth to support implementation properly. Often the people needed are already the busiest people, and sometimes the relevant resources don't exist in the business at all, so hiring them and getting them up to speed is a bottleneck. 5. 𝗦𝗰𝗼𝗽𝗲 𝗖𝗿𝗲𝗲𝗽: Lack of strong leadership and governance can lead to a mentality of trying to implement every suggestion - this leads to complexity that overwhelms teams and dilutes project focus. This is worst when trying to replicate functionality from old or homegrown systems. The successful projects I've observed share common traits: they build strong teams with a clear vision, invest heavily in training, set realistic timelines, and maintain strong executive sponsorship throughout. Most importantly, they treat MES implementation as a business transformation project, not just a technology deployment 💪 What's been your biggest challenge when implementing manufacturing systems? I'd love to hear your experiences in the comments. p.s. I know about the typos - but I just loved the image so much so went with it 😂

My recent post on hybrid project methodology triggered good discussion about the roles IT and OT should play. Here’s what we’ve seen work—and what doesn’t. MES projects create more friction than any other industrial technology deployment because it’s the only system that straddles both worlds—IT and OT. IT’s World: Infrastructure, security, scalability, enterprise integrations (ERP, PLM, quality systems), data governance, vendor management, and budget accountability. A poorly architected MES creates security vulnerabilities, integration nightmares, and compounding technical debt. OT’s World: Shop floor operations, equipment integration, real-time production decisions, operator usability, and manufacturing process expertise. An MES that doesn’t work for operations becomes expensive shelfware, no matter how well it integrates with ERP. The Problem: When IT leads alone → You get a system that checks enterprise boxes but doesn’t work on the floor When OT leads alone → You get a system that works locally but creates enterprise integration and security problems Why MES is Different: Every other industrial technology sits clearly on one side: SCADA/HMI and PLCs are OT domain. ERP and identity management are IT domain. But MES collects real-time data from PLCs while posting to ERP. It manages shop floor workflows while enforcing enterprise compliance. It makes split-second production decisions while maintaining audit trails for regulators. It needs both perspectives from day one. What we’ve seen work: - IT defining architecture, security, and integration standards - OT defining workflows, usability, and operational requirements - Both collaborating on vendor selection and implementation - Clear accountability: IT owns infrastructure and enterprise integration, OT owns operational outcomes The worst deployments? One side decides, the other lives with it. The Challenge: In many organizations, IT reports to Finance, driving consolidation, standardization, and cost reduction. But manufacturing is about managing variability, responding to real-time conditions, and continuous improvement. MES sits at the intersection. It fails when we pretend it belongs to just one world. Less than 10% of manufacturers globally have achieved true MES maturity. The gap isn’t technology capability—it’s that IT purchased an off-the-shelf “configurable” MES without understanding operational requirements, or OT built something that can’t scale or integrate. When IT alone selects MES, they often buy a solution that reduces operational efficiency rather than enhancing it. MES success requires both IT rigor and OT expertise working together from requirements through deployment.

Many manufacturers today have invested heavily in data infrastructure: PLCs, SCADA, MES, historians, dashboards. Yet when you dig into the architecture, especially on high-speed or complex lines, a common gap emerges. Critical short-duration events are not being captured accurately or with enough context to drive actionable insights. This is not due to lack of technology. Modern PLCs, edge devices, and platforms are more than capable. The problem is architectural. Many plants still rely on SCADA and MES systems that poll PLCs at relatively slow intervals, typically 1000 milliseconds. That polling interval creates a blind spot. Meanwhile, PLC scan cycles typically run between 3 and 5 milliseconds. In high-speed lines, servo-based systems, robotics, and motion applications, critical events happen on sub-second timescales. Operator inputs, cascading alarms, motion faults, and intermittent product jams often occur and resolve in less than a second. If these events are not buffered properly at the PLC layer or edge, they are simply lost to higher-level systems. This leads to a familiar pattern. • OEE reports that do not explain why downtime occurred • Fault logs that fail to show which fault triggered first • Product loss and yield issues that cannot be traced to specific machine behaviors • Maintenance teams spending hours reviewing PLC logic and guesswork post-mortems The bigger risk is that leadership decisions get made on incomplete data. Continuous improvement efforts stall. Predictive maintenance strategies fail to get off the ground. McKinsey & Company data suggests that manufacturers who close this gap and build modern data architectures can reduce unplanned downtime by up to 50% and improve productivity by 10 to 20%. But this requires capturing data with the right fidelity, at the right layer, and with the right context. From my experience, this is true not only on high-speed systems where products are moving faster than the eye can see and $100,000 high-speed cameras are used to diagnose failures. It is equally true on slower lines where operators and engineers struggle to explain recurring issues because key data is missing. If you are running below 60 percent OEE, you likely have more foundational work to do first. But if your goal is to move from reactive to proactive operations, to reduce variability, and to enable next-generation capabilities like advanced analytics and machine learning, this is an architectural conversation that needs to happen. I work with manufacturers who want to modernize these architectures and close this visibility gap. If you are looking at these challenges or want to benchmark your current architecture against best practices, feel free to reach out. I would be happy to share insights and lessons learned.

The MES should fit your plant model - avoid a $2-3M mistake. We saw a MES product selection and implementation failure recently. Maybe $2-3M wasted...product was abandoned after 2 plants. Why? Poor requirements definition process for how the plants operated and needed relative to the MES product selected. Core to the poor requirements definition process was not considering the plant's operational model versus the plant model the MES effectively contains inside it (i.e., it's data models that make it a good fit for one type of manufacturing vs another). When selecting MES too often a manufacturer is focused on features and benefits (downtime Pareto, OEE, scheduling, ...) expressed by the MES product vendors. They might've even considered their process type (discrete, batch, continuous) and industry vertical of their plant relative to the MES product. But, did the manufacturer consider the plant's operating model? Probably not. Not considering the MES product's plant model best-fit may not show up on day 1 after the implementation. However, 3-6 months down the road when they want to extend the capabilities, turn on another module they may find the product doesn't work exactly as it should. Then it’s the deadly cycle of kludgy work arounds and customizations trying to get the square peg of a MES into the round hole that is their plant's operational model. So, "what is a plant model?" you might ask. It is the definition of how you make things in your plants, how your equipment is organized, how your resources interact. That information is translated into code and data tables in the MES software product. Have a mismatch and that's like trying to build a machine with both Imperial and Metric measurement systems. How to prevent this mismatch? Know what your plant model is before evaluating vendors, then map your model against vendor products, ID gaps, and then figure out best fit for your near term and longer term plans. How do you figure out what your plant model is? Learn ISA-95 and use its approach as a way to define the model; such as equipment hierarchy, activities in the 4 domains of your plant, and map the resources. (We will write another post with more details) Why do all of that work? You could potentially save yourself from wasting $500K - $5M on a failed MES implementation. Are you looking at a MES? If so, document your plant model and use it in the selection process. Our Unified Ops Assessment can define the plant model, so you can buy the right fit, not the best demo.