The End of Monolithic MES—and the Rise of Flexible Manufacturing Stacks
Welcome to DX Brief - Manufacturing, where every week, we interview practitioners and distill industry podcasts and conferences into what you need to know
In today's issue:
The death of MES, and how a decentralized, best-of-breed ecosystem approach that gets to value faster is replacing it
How process manufacturers navigate bottlenecks in AI adoption without replacing legacy systems
Stop chasing "future-proof" and start building flexibility into your manufacturing tech stack
1. The death of MES, and how a decentralized, best-of-breed ecosystem approach that gets to value faster is replacing it
IIoT World panel, The Death of MES A New Vision For The Factory Software Stack (Feb 13, 2026)
Background: When over 5,800 manufacturing professionals were asked how satisfied they were with their current ERP and MES implementations, only 2% said "very satisfied." In a separate room of manufacturers in Utah, not a single hand was raised when asked if anyone was happy with their systems. Meanwhile, an estimated 2.1 million manufacturing positions may prove difficult to fill by 2030. The old model of monolithic, multi-year ERP implementations is breaking under the weight of workforce shortages, supply chain volatility, and the need for business agility. The emerging alternative? A decentralized, best-of-breed ecosystem approach that gets to value faster.
TLDR:
Conway's Law applies to ERP: when you implement a static, monolithic system, you inherit its communication architecture and business processes, forcing your business to adapt to software rather than the reverse.
The decentralized approach works because you don't have to boil the ocean: address your biggest gap first (machine monitoring, maintenance, quality), prove value, then expand, rather than undergoing a multi-year rip-and-replace project.
Pilot purgatory kills transformation programs. 70% of enterprise asset management deployments fail to deliver positive ROI because of people, process, and technology issues. Get to value as fast as possible with a scale plan in place before you start.
Monolithic systems force you into an impossible dance. The fundamental problem with traditional ERP and MES implementations is what Sunny Han, CEO of Fulcrum, calls Conway's Law applied to manufacturing software: the communication architecture of the software company that built your system dictates the communication architecture your business must adopt.
The probability that your unique business just happens to fit that architecture is extremely low. This creates constant tension between customizing the software and adapting your business.
Both should be adaptable simultaneously but monolithic systems make that nearly impossible. The result is either years of costly customization or workers creating shadow systems and workarounds.
Best-of-breed means you can start small and prove value. Bill Bither, CEO of MachineMetrics, outlines the practical advantage of the decentralized approach:
If you already have an ERP but struggle with manual data entry at end of shift, you can deploy a machine monitoring solution to automate that data flow.
If you have a maintenance management gap, add a CMMS.
If quality is your pain point, bring in a quality management system.
You're not ripping out your entire stack – you're plugging gaps one at a time. For smaller manufacturers still on spreadsheets, you can automate data flow into those spreadsheets first, then build from there.
Escape pilot purgatory by demanding value from day one. Ryan Chan, CEO of UpKeep, is blunt: pilots don't add value. The real issue isn't whether you like your MES – it's whether you're getting value from it.
His team sees 70% of enterprise asset management deployments fail to deliver positive ROI because of three factors: people, process, and technology.
The solution isn't longer pilots with more features. It's getting to value as soon as possible. Don't do big bang implementations; do slow releases that generate value at each stage.
The unified namespace is emerging as a key architecture pattern. Multiple panelists pointed to an emerging concept for managing best-of-breed complexity: the unified namespace.
Rather than point-to-point integrations between every system, the unified namespace provides one place to publish and consume data, with modern BI tools like Tableau, Looker, or Power BI sitting on top to enable cross-functional analysis.
This approach – best-of-breed vertical solutions with open APIs, connected through a unified data layer – is where the panelists believe manufacturing operations is headed.
What to do about this:
→ Identify your single biggest operational gap and solve that first. Rather than evaluating all-in-one platforms, diagnose whether your primary pain point is machine visibility, maintenance management, quality tracking, or something else. Select a best-of-breed solution for that specific problem and prove ROI before expanding.
→ Never start a pilot without a scale plan. Before kicking off any technology pilot, document exactly how you will expand a successful pilot across your operation. If you can't articulate the scale path, you're setting yourself up for pilot purgatory.
→ Explore unified namespace architecture. If you're managing multiple systems, investigate MQTT brokers and unified namespace concepts as a way to create a single source of truth for your operational data without ripping and replacing your existing investments.
2. How process manufacturers navigate bottlenecks in AI adoption without replacing legacy systems
The Future of PLM podcast, Transforming Process Industries with AI! MontBlancAI and Acceleer! (Feb 10, 2026)
Background: Davy Demeyer spent 20 years integrating industrial automation systems across food, pharma, and chemicals, then got frustrated with how manual everything remained. Markus Guerster studied machine learning before it was cool, returned to dairy production where he interned at 15, and found nothing had changed in data and dashboarding. Both founded startups to fix this. Their insight: AI in process manufacturing isn't about replacing legacy systems – it's about building layers on top of them. And the biggest competitor to their software? Excel.
TLDR:
AI agents now write gigantic features faster than humans can review them. The bottleneck has shifted from coding speed to human context windows and code maintainability.
Process manufacturers don't lack data – but it's locked in PLCs and DCS systems. The foundation for AI isn't new data collection. It's making existing high-quality PLC data accessible.
The human context window is now the bottleneck. Marcus describes a fundamental shift in software development: "The context windows of the models exceeds the context windows of us as humans."
AI agents can write entire features, and they work, rarely introducing bugs. But who reviews them? Who maintains that codebase going forward? The challenge isn't getting AI to produce code; it's maintaining human understanding of what's been produced.
Davy's solution: smaller features at higher velocity. Rather than elaborate PRDs that generate massive code outputs, he requests individual features, tests them immediately, and maintains a tight feedback loop. The result is a lean, agile workflow where requested features are often ready and tested the next day.
Git becomes your control mechanism for agentic coding. The breakthrough in agentic coding isn't a fancy IDE, it's version control. Start from a clean commit, give the agent instructions, review changes in git.
Davy even experiments with storing agent chat transcripts alongside commits, preserving the reasoning and design intent that led to each code change. When a new session starts and the agent has no memory of previous work, you have both the code changes and the conversation that produced them.
AI needs deterministic foundations to work in process industries. Manufacturing requires precision: exact quantities, temperatures, pressures. AI is probabilistic. How do these coexist?
Markus explains the architecture: first, a deterministic statistics and machine learning layer that crunches huge data volumes the LLM can't directly process. Then the agent interacts with that synthesized data. The co-pilot view is visible to users, but agents also run in the background, generating "nudges" – alerts about process anomalies, impending machine failures, or relevant documentation updates.
You don't need to sunset legacy; you just need to unlock it. The common fear: adopting AI means replacing 20-year-old equipment. Markus pushes back: "That equipment is 20 years old and why would you change it if it's running?" MontBlancAI connects to legacy systems without touching them, replacing paper, Excel spreadsheets, PowerBI dashboards, and the 20 different screens pulled up in 8am production meetings; not the underlying industrial control systems.
Davy adds a nuance for automation: while you don't need to replace hardware, AI requires open access to data and code. Major DCS systems lock code inside proprietary applications. For truly agentic engineering, manufacturers will eventually need to migrate to next-generation development environments from Siemens, Beckhoff, Rockwell, and others.
What to do about this:
→ Make existing PLC data accessible before chasing new sensors. Your PLCs contain the highest-quality data in your operation – 100% accurate, or close to it. Prioritize data liberation from existing systems over new IoT deployments. This is the foundation AI needs to be grounded and useful.
→ Use AI for design collaboration, not code review. Asking agents to help write functional specifications in human-readable format is less cognitively demanding than reviewing generated code line by line. Let deterministic code generation flow from AI-assisted design.
→ Accept that Excel is your real competitor. Davy's biggest competitor isn't another software vendor, it's Excel. Focus on onboarding simplicity and developer experience. If your AI-enhanced system is harder to use than a spreadsheet, you've already lost.
3. Stop chasing "future-proof" and start building flexibility into your manufacturing tech stack
Digital Transformation with Eric Kimberling podcast, Industry 4.0 Reality Check: What’s Working, What’s Not, and What’s Next (Feb 10, 2026)
Background: Eric runs an independent consulting firm where 60-70% of revenue comes from manufacturing clients. His take on Industry 4.0? Stop listening to vendors promising "future-proof" solutions – that concept doesn't exist. The real challenge facing manufacturers is that cloud solutions are pushing standardization while your operations are becoming more complex, more global, and more customized.
TLDR:
Cloud ERP contracts create more vendor lock-in than ever before. The first wave of manufacturers who outgrow their cloud solutions and need to switch is coming in 5-15 years, and it will be painful.
Software vendors benefit from standardization, whereas manufacturers differentiate through complexity. These are fundamentally opposing forces, and no vendor will tell you this.
Platform-as-a-Service integration tools like Boomi and Mulesoft let you modernize incrementally rather than betting everything on a big-bang implementation.
The flexibility-standardization trade-off is getting worse, not better. Cloud solutions from SAP, Oracle, and Microsoft are gaining AI capabilities and agentic automation, but they're simultaneously losing the deep, detailed workflows and exception handling that on-premise systems like SAP ECC once had. No two manufacturers Kimberly has ever seen operate similarly enough to use the same solution off-the-shelf without material customization.
The vendor pitch is seductive: eliminate technical debt, future-proof your business, get on a modern platform. What they don't mention is that you're trading one set of problems for another.
When you sign a long-term cloud contract with escalating costs, you lose control over how that functionality evolves. Upgrades happen whether you want them or not, and they don't always align with your business needs.
The emerging middle ground is platform-as-a-service integration. Rather than going all-in on one vendor's ecosystem, manufacturers are using iPaaS tools to connect best-of-breed solutions. The practical benefit: you can implement a new MES system while keeping your legacy finance system, integrating them through a platform layer rather than forcing a simultaneous big-bang replacement.
This approach also handles the IT-OT integration challenge. When someone asks how a factory with legacy systems should handle IT-OT integration, the answer isn't rip-and-replace. It's creating integration layers that allow incremental modernization. You keep running your business while evolving your technology stack piece by piece.
Frontline workers get shafted in most transformation projects. Back-office people run implementations, so they think myopically about their world and their peers' needs. Shop floor workers – the people who actually do the work – get the short end of the stick on adoption and training.
In manufacturing, this problem is worse than in any other industry because you're dealing with skills-based training, multiple generations (Boomers through Gen Z), and workers who may not have traditional technology exposure.
The solution isn't to force faster adoption. If you're a conservative organization – maybe family-owned, maybe in a rural area, maybe just not fast-moving by nature – acknowledge that reality. Build a roadmap that makes sense for who you actually are rather than who a vendor wants you to be.
What to do about this:
→ Audit your vendor lock-in exposure. Map every system where the vendor controls upgrade timing, data portability, and integration APIs. Score each on a 1-5 scale for switching difficulty.
→ Evaluate iPaaS tools for your next integration project. Before your next system implementation, run a proof-of-concept with Boomi, Mulesoft, or a comparable platform to understand how integration-first architecture could give you flexibility.
→ Create a frontline-specific adoption plan. Don't just train frontline workers – involve them in requirements gathering. Schedule 3-5 sessions with shop floor teams before you finalize any demo script or RFP.
Frontline workers get shafted in most transformation projects. Back-office people run implementations, so they think myopically about their world and their peers' needs. Shop floor workers – the people who actually do the work – get the short end of the stick on adoption and training.
In manufacturing, this problem is worse than in any other industry because you're dealing with skills-based training, multiple generations (Boomers through Gen Z), and workers who may not have traditional technology exposure.
The solution isn't to force faster adoption. If you're a conservative organization – maybe family-owned, maybe in a rural area, maybe just not fast-moving by nature – acknowledge that reality. Build a roadmap that makes sense for who you actually are rather than who a vendor wants you to be.
What to do about this:
→ Audit your vendor lock-in exposure. Map every system where the vendor controls upgrade timing, data portability, and integration APIs. Score each on a 1-5 scale for switching difficulty.
→ Evaluate iPaaS tools for your next integration project. Before your next system implementation, run a proof-of-concept with Boomi, Mulesoft, or a comparable platform to understand how integration-first architecture could give you flexibility.
→ Create a frontline-specific adoption plan. Don't just train frontline workers – involve them in requirements gathering. Schedule 3-5 sessions with shop floor teams before you finalize any demo script or RFP.
Disclaimer
This newsletter is for informational purposes only and summarizes public sources and podcast discussions at a high level. It is not legal, financial, tax, security, or implementation advice, and it does not endorse any product, vendor, or approach. Manufacturing environments, laws, and technologies change quickly; details may be incomplete or out of date. Always validate requirements, security, data protection, labor, and accessibility implications for your organization, and consult qualified advisors before making decisions or changes. All trademarks and brands are the property of their respective owners.
