This is the third blog post on the SAP ME Reset Window blog series, written by João Roque, architect and advocate for automation and connectivity at Critical Manufacturing.
There is a question I have been asking manufacturing leaders in every conversation for the past year. Not about their current MES. Not about their migration timeline. A deeper question.
If you had to build your manufacturing execution platform from scratch today, unshackled from what you have, what would you build?
Most people pause when they hear this. Not because they don’t have an answer. Because they have never been in a position to ask. The existing manufacturing system was always there. The switching cost was always too high. The risk of an MES transition always outweighed the benefit. The question stayed theoretical.
It is no longer theoretical.
For hundreds of manufacturers running SAP ME, the option of staying has been removed. SAP has confirmed end-of-life. There is no upgrade path to SAP DM.
The transition is a full MES reimplementation regardless of destination. For the first time in a decade, the blank sheet is not a thought experiment. It is the actual starting point.
The question deserves a serious answer. What should a manufacturing execution platform look like if you were designing it today?
The Lessons from What Came Before
Every platform generation teaches the next one. SAP ME’s success and cross-industry penetration taught us several things.
It taught us that flexibility through code is a double-edged sword. Activity Hooks gave developers the power to intercept any transaction and inject any logic, and this was an amazing piece of technology. The side-effect, ten or fifteen years later, are systems where the business logic lives in compiled Java classes that nobody can fully inventory. The flexibility that was a strength in 2010 became the primary obstacle to change in 2025. The lesson is not that extensibility is bad. The lesson is that extensibility through code creates coupling, and coupling creates obfuscation and inertia.
It taught us that middleware as a separate layer is a tax. SAP MII existed because SAP ME could not connect to equipment, integrate with ERP, or orchestrate workflows on its own. A three-product stack (ME + MII + PCo) was required to do what could have been one platform’s job. Every additional product in the stack added cost, complexity, integration points, and failure modes. The lesson is that connectivity and integration should be native to the execution platform, not bolted on.
It taught us that an object model designed for simplicity eventually becomes a model that forces customization. SAP ME’s flat SFC tracking entity, its lack of native dispatching, its absence of hierarchical resource modeling, its dependence on custom data fields for workflow state: these are all symptoms of a data model that was built for a narrower problem than the one manufacturers actually have. When the model does not match the operational reality, the gap gets filled with custom code. The lesson is that the depth of the data model determines how much customization you will need, and customization determines your long-term cost of ownership.
Seven Principles for the Next Platform
The next generation of manufacturing execution should be built on the following principles. These are not feature requests. They are architectural commitments that determine whether a platform will serve you well for the next decade or become the next system you need to leave.
1. Configuration, Not Customization
The single most important architectural decision in a manufacturing execution platform is how it handles variation.
- Every factory is different
- Every product has unique requirements
- Every process has exceptions, alternates, and edge cases.
The question is whether the platform accommodates this variation through configuration (declarative, governed, inspectable, upgrade-safe) or through customization (code, compiled, deployed, version-coupled).
I have seen the consequences of choosing customization. Fifteen years of Activity Hooks, BLS transactions, and custom data fields that nobody can fully map. A platform that resists change because every change risks breaking something that was built by someone who is no longer around.
The alternative is a system where business logic is expressed through visual, no-code tools. Where workflow changes are made by process engineers, not Java developers. Where every configuration change is metadata-driven, versioned, auditable, and guaranteed to survive the next platform upgrade. This is not a luxury. It is the only way to avoid recreating the current technical debt cycle.
2. An Object Model That Matches Manufacturing Reality
A manufacturing execution platform should natively represent the entities that actually exist on a factory floor: materials that have hierarchies (sub-assemblies, sub-materials, parent-child relationships), containers that have their own lifecycles (FOUPs, carriers, trays with usage tracking and maintenance schedules), resources that form clusters and hierarchies (multi-chamber equipment, nested sub-resources with positions and states), and services as explicit capabilities that connect what equipment can do to what materials need done.
When these entities are native to the platform, you configure their behavior. When they are absent, you build custom code to simulate them. The depth of the object model is the single best predictor of how much customization a given implementation will require. A system should model your reality. If your reality has to bend to fit the system, you’re not configuring it, you’re customizing it.
Context resolution is the mechanism that ties this together. Instead of hard-linking every recipe, BOM, data collection definition, and work instruction to every product at every step, a rule-based engine should dynamically resolve which entities apply based on the manufacturing context: the product, the step, the resource, the material type. This dramatically reduces the master data burden and eliminates an entire category of customization that legacy platforms demanded.
3. Execution Authority Outside of ERP
ERP is essential. But it should never run the factory.
Too many manufacturing architectures place ERP at the center, with MES acting as a subordinate layer that executes what ERP dictates. This creates a governance bottleneck: every shop floor change must align with ERP data models, ERP approval cycles, and ERP release schedules. Manufacturing adapts at the speed of operations. ERP adapts at the speed of IT governance. When execution authority lives inside ERP’s orbit, the factory slows to match.
The right architecture places execution authority in the MES and synchronizes with ERP. Orders flow in. Completions and consumption flow out. Master data is shared. But the operational decisions, the routing logic, the dispatching rules, the quality enforcement, the equipment orchestration: these belong in the execution layer, where they can change at the speed the factory requires.
4. One Platform, Not a Stack
Execution, equipment connectivity, and intelligence should be built on the same platform, sharing the same data model, the same security model, and the same configuration framework. Not three products stitched together by middleware. Not an MES plus a separate IoT platform plus a separate analytics layer plus a separate integration bus. Like every patchwork, each new piece is stitched on to solve a local problem. Eventually, the seams become the system.
Every product boundary in a manufacturing technology stack is a point of friction: a data transformation, an integration to maintain, a versioning dependency to manage, a potential failure point. The fewer product boundaries, the lower the total effort. A unified platform is not just simpler. It is structurally cheaper to own, operate, and evolve.
5. Deployment Flexibility Is Non-Negotiable
The right deployment model for a manufacturing execution platform is the one that fits your factory, your IT policy, and your regulatory constraints. Not the one that fits your vendor’s business model.
Some factories need on-premises deployment for data residency, latency, or air-gap security reasons. Some factories are ready for cloud. Many need a hybrid model where execution runs close to the shop floor and analytics live in the cloud. Forcing every manufacturer into a SaaS-only model is an architectural compromise that the customer pays for.
A platform built for manufacturing should support all three models with the same codebase, the same capabilities, and the same extensibility. Deployment should be a configuration choice, not an architecture fork.
6. You Control When You Update
Mandatory quarterly updates sound progressive until you run a validated manufacturing environment. Every update that changes system behavior triggers a testing cycle. In regulated industries, that testing cycle includes formal re-validation: documented, approved, auditable. When you do not control the update schedule, you are permanently running to keep up with your vendor’s release cadence rather than your own operational priorities.
The alternative is a platform where updates are available on a regular cadence but applied on your schedule. Where the update process is designed to be safe: upgrade-compatible configuration, automated regression testing, and clear separation between platform updates and customer configuration. You choose when to move forward. You are never forced to.
7. The Data Model Is the AI Foundation
I’m going to make a prediction that, in three years, will feel self-evident: the manufacturing execution platforms that succeed with AI will be the ones with the best operational data models. Not the best algorithms. Not the best partnerships with AI companies. The best data. They will be systems that silently collected and orchestrated everything that happened in your shop-floor in a coherent structure.
AI in manufacturing is only as good as the data it operates on.
- If the data is fragmented across separate MES, IoT, and analytics tools, AI cannot reason about the full operational context
- If the data model is shallow (flat tracking entities, loose custom fields, unstructured integration payloads), AI cannot generate reliable insights
- If the data is not captured at execution time with the right granularity and the right structure, no amount of post-processing will recover what was lost.
A canonical operational data model, one that captures materials, resources, processes, quality, and equipment state in a single, consistent, structured representation, is not just good MES architecture. It is the prerequisite for manufacturing AI that actually works in production. Structure first. Intelligence follows.
The Real Question
I started this post with a question: what would you build if you started from a blank sheet?
The answer is a platform that treats configuration as the primary mechanism for handling change. That maps manufacturing reality at the depth it actually requires. That places execution authority where it belongs: on the factory floor, not in ERP. That unifies execution, connectivity, and intelligence on one data model. That lets you deploy where you need to and update when you choose to. And that gives AI the structured, semantic, trustworthy data foundation it needs to deliver compounding results, not just demos.
None of this is theoretical. These are design choices that can be made today. Some platforms have already made them. Some have not.
The SAP ME end-of-life has removed the option of staying where you are. The only question left is whether you use this moment to build the factory you actually want, or whether you recreate the constraints of the system you are leaving.
I know which one I would choose. I’ve spent my career helping manufacturers build it.
