A POST-MORTEM ON THE UNSUCCESSFUL MES PROJECT YOU ARE ABOUT TO START: Part 3
- Matthew Swope
- 12 hours ago
- 10 min read
Introduction
This is the third paper in this series as I continue to highlight aspects of an MES project that can greatly impact success. Remember, it is not my intent to paint Digital Factory projects in a negative light but rather to guide you through common pitfalls I’ve observed over the years. While you may read this series and reflect on how obvious most of these aspects appear, the success of the project is dependent on the execution and adherence. This part addresses three important areas of consideration, the type of project (new, migration, or upgrade), integration of other systems, and complexity of project execution. The general theme here is the contributing factors that should be evaluated at the planning stage of the project to determine the best execution path to a successful implementation.
About the Author
I’m currently the Director of Product Development at Global Process Automation (GPA). With over 30 years in factory automation including 20 years as an independent consultant/contractor, my career spans from PLC programming to working up the Purdue Model until reaching the MES/Enterprise layer roughly a decade ago. I have worked with systems such as Inductive Automation Ignition and Sepasoft MES modules. My experience in Digital Manufacturing dates back to the early 90s—long before the term “Industry 4.0” was coined. One of my earliest projects involved a SCADA system that interfaced with a mainframe ERP system to monitor production on 100 wire weaving machines for a screen mesh manufacturer. While I do not claim to have all the answers, this broad experience enables me to share valuable lessons from past projects and to help you avoid common missteps.
PROJECT TYPE: NEW, FIXER UPPER, OR DEMOLITION TIME
The first factor to consider is project type. This refers to whether your MES
initiative is a new installation, a migration, or an upgrade. Each option has
unique risks, benefits, and cost implications.
If you do not currently have an MES or only have a limited proof of concept, your path is clear: a new implementation. Even so, the insights in this section will still help you plan and prioritize for future growth.
Let’s briefly review each type:
New Implementation
A new MES implementation is often the least risky choice, provided it is well planned and follows sound software development and project management practices. These projects are flexible and free from legacy constraints, making it easier to modernize manufacturing processes.
Although initial costs can be higher, long-term value often outweighs them. In Greenfield environments, integration with plant-floor devices and enterprise systems requires detailed planning, but this preparation establishes a strong foundation for scalability and improvement.
Migration
A migration, which replaces one MES platform with another, introduces added complexity. The goal is often to replicate existing functionality, which can limit innovation. Without revisiting requirements based on current and future needs, the project risks becoming a one-to-one swap rather than a meaningful improvement.
Users who are accustomed to the old system may resist change. While a migration may cost less upfront than a new build, the long-term benefits are often lower if future needs are not addressed. In cases where platform support is ending or costs have become unsustainable, a migration may be necessary, but it should include a feature-by-feature review to confirm each function’s value.
Upgrade
A major upgrade, particularly across multiple versions or platform changes, is typically the most risky option. Smaller revisions are routine, but large version jumps often introduce changes to data structures, scripting, and functionality.
Upgrades that attempt to replicate the old system exactly may fail to leverage new capabilities. Conducting a feature analysis helps determine what should be retained, modified, or redesigned.
Expect longer development and testing cycles, especially if the code was poorly documented or written by team members who are no longer available. Even when vendors provide migration tools, manual rework is often necessary, especially for systems more than three to four years old.
Key Considerations:
System Performance and Future Needs
Evaluate how well your current MES supports business requirements and emerging technologies such as artificial intelligence and machine learning. If it cannot deliver or transport data effectively, replacement may be necessary. Work with a trusted integrator to assess underperforming features and determine whether improvement or replacement is more practical.
Age and Cost
The age of the system affects stakeholder sentiment. For MES platforms under five years old, expect resistance to replacement. Support decisions with detailed performance data and cost-benefit analysis. MES projects can range from one hundred thousand dollars to over one million depending on scope, complexity, and features. Seek complete and transparent estimates and avoid open-ended contracts. Time and materials agreements are common but request a good faith estimate to manage risk.
Time Frame
Upgrades are often completed more quickly, but version differences and platform shifts can extend schedules significantly. Invest in a code evaluation project before committing. In some cases, starting fresh can be more efficient than rewriting legacy code.
Team Expertise
Partner with a vendor that has experience with both your current and target platforms. Their insight can prevent costly misunderstandings, particularly with integration points.
Risk Tolerance
Each path carries trade-offs.
Upgrade: Lower user disruption but higher technical risk.
Migration: Moderate risk and moderate flexibility.
New Implementation: Highest initial investment but greatest long-term reward.
Understanding your organization’s comfort with risk will guide the best choice. The strategies in this white paper series are designed to reduce technical risk and help you execute with confidence.
MES Integrations: Its Superpower and Sometimes Kryptonite
The current technology available to most MES software and other modern enterprise systems is a powerful tool in the effort to align with Industry 4.0 philosophy. The ability to speak a common interface language between multiple dissimilar systems provides a mechanism for MES to pull a wide variety of data. Some examples of this are:
IT Integrated Systems
ERP (Enterprise Resource Planning) – This is the most common integrated system as the ERP system handles production orders, material master data, and other critical information used within the MES layer.
PLM (Product Lifecycle Management)
WMS (Warehouse Management System)
CMMS (Computerized Maintenance Management System)
Personnel Management Systems – Training and Skills, Clock Information, etc.
LIMS (Laboratory Information Management System)
OT Integrated Systems
Plant Floor Devices – PLCs, CNCs, etc.
DCS (Distributed Control Systems)
SCADA (Supervisory Control Alarm Data Acquisition) – Yes, I know “Alarm” is traditionally “And”, but I’ve always thought it important enough to include explicitly.
In-process Quality Measurement Systems
Though the data itself is valuable and contributes greatly to the benefits a company can achieve through the implementation of an MES solution, connecting to and processing this data can present significant challenges. As with any MES strategy, preparation and execution are critical to success. I have been involved in integration efforts where the following statement was made:
“We want to integrate the XYZ system, but we don’t know what transactions or transaction data are available, or how to connect to it.”
While this kind of self-reflection is valuable during the planning phase, it must be addressed quickly to avoid project delays.
In some projects, I have seen other systems implemented in parallel with the MES solution and identified as critical for integration. This approach can be effective, but without proper communication between teams and clearly documented requirements, it can easily waste both time and money. In fairness, some unknowns can be anticipated and planned for, particularly when integrating systems that are frequently connected with MES, such as SAP. Because many design decisions depend on a complete understanding of the integration solution, it is essential to conduct workshops that bring together all necessary teams to resolve open questions.
To support this process, I recommend developing a structured document that captures key integration details and responsibilities. The document structure I prefer to use includes the following:
Integration Overview
“Integration with SAP system will open bidirectional data flow related to production orders, material data, and other contextual data maintained within SAP…”
Integration Method
API (most commonly used, especially for newer applications)
Shared Database Tables
File Transfer
MQTT – Getting there
Transaction Definitions - Critical for alignment between teams
Transaction Function
Business rules describing
When the transaction would expect to be executed
Which system initiates the transaction
The handshaking to take place to complete the transaction
Data Mapping
Show what data points will be part of the transaction and data types
Representational data examples
Exception Handling
If the transaction isn’t successfully completed, what actions should be taken?
What validation should be undertaken to ensure data integrity?
In addition to planning and developing requirements documentation, another important consideration is the availability of a proper test environment. Just as development, quality assurance, and production environments are essential for MES implementation and maintenance, having similar environments for integrated systems makes the overall integration effort more efficient and reduces risk. If an integration only involves data retrieval with no data modification, such as document retrieval, this requirement can be optional.
It is also important to note that nonproduction environments lose their value if configuration and data are outdated. If these environments are more than a few weeks behind the production system, they can no longer provide accurate testing results, especially when recent changes have occurred in production. To avoid this, a migration or refresh plan from production to nonproduction environments should be carried out regularly, especially during the early stages of development.
As will be discussed later in this paper, limiting the number of concurrent integrations during a development iteration can set the team up for success. The most common integration for MES is with the ERP system. Because ERP data is essential for order planning and execution, which are core MES functions, this system should be one of the first to address, along with plant floor lines for production data. Once these critical integrations are in place, the remaining systems should be prioritized according to development iterations. This allows teams to focus on fewer active elements at a time, improving overall efficiency and reducing confusion.
Project Execution Complexity: Minimizing the Number of Spinning Plates
When discussing project execution complexity, I often use an analogy I call “Minimizing the Number of Spinning Plates.” This image, inspired by variety shows from my youth, provides a useful visual comparison. A performer balances a dozen poles, each with a spinning plate on top. As more plates are added, the performer must run back and forth to keep them all spinning. Eventually, one slows, another falls, and soon broken plates cover the stage. The same principle applies to MES projects. When a team attempts to implement too many features at once, constant context switching begins to harm efficiency and effectiveness.
This point does not criticize the final MES solution, which may successfully include many features such as OEE, Product Genealogy, and Quality Management. The concept instead applies to the implementation strategy used to reach that point. Whether the team completes one large project with incremental development or several smaller projects with similar strategies, dividing the solution into smaller, manageable parts is the most practical plan. My preferred approach is to structure the work as a series of smaller projects that create clear and distinct milestones in the overall timeline.
Although I encourage incremental development, I still recommend that the complete solution requirements be well documented before development begins. Requirements may evolve during the process, but having a defined overall strategy ensures that the team maintains forward momentum and continues to discuss how changes may affect the direction and schedule.
Breaking the overall solution into smaller iterations that focus on one or two features at a time provides several advantages. Concentrating on a specific feature, such as order management and execution, reduces the number of variables that must be managed. With fewer requirements and stakeholders, coordination and communication become simpler. Early wins help establish a solid foundation, encourage user confidence, and deliver a usable system sooner. This approach also supports the concept of a Minimum Viable Product, allowing the customer to begin realizing benefits earlier in the process.
Iterative implementation also reduces risk compared to large waterfall projects. Integration testing becomes more efficient because fewer changes are included in each testing cycle. If a problem appears in production, it is easier to isolate and resolve since there are fewer modifications to review. Each iteration allows flexibility for adjustments based on user feedback, with minor enhancements added to future cycles for faster deployment. In addition, the financial impact of the full MES solution can be distributed across multiple smaller projects over time, improving budget management.
Despite these advantages, iterative approaches have potential challenges. They require discipline to maintain focus and avoid extended implementations that increase cost. Scope changes must be evaluated carefully based on their value and effect on the schedule. I have developed a method to quantify this effect, though that discussion is beyond the scope of this paper. Continuous evaluation, however, is essential to keeping the project on course.
Depending on how many new features are introduced during implementation, the final solution may become more complex than originally expected. While this is not necessarily a negative outcome, it can increase the effort required for long-term support and maintenance. Iterative development also requires more frequent communication between customer and vendor teams. Although this uses more resources, I view it as a positive factor because it strengthens collaboration and improves the likelihood of project success. Change management must also be emphasized, as iterative rollouts usually occur more often than in a traditional waterfall project.
The core principle of the iterative approach to MES implementation is the division of requirements into smaller, semi-independent units called iterations. Drawing from Agile methodologies, each iteration is divided into sprints that break development into smaller stories and tasks. Depending on how closely Agile principles are followed, each sprint may result in a production release that adds new functionality. MES implementations vary widely, so the specific cadence and structure should be adapted to the organization’s goals and available resources.
The mechanism for incremental implementation is fairly straightforward. The first step is to prioritize the desired features and align their requirements between the stakeholders and the vendor. You then plan the iteration and development strategies identifying scope, timeline, stakeholders, development and other resources.
Within the development phase the following steps are typically cycled:
Create/update feature user stories and task backlog
Execute Agile Sprints based on user story priorities
Test the incremental changes
When appropriate, deploy updates based on CI/CD (Continuous Integration, Continuous Deployment) best practices
Gather feedback from users on existing and new feature functionality
Determine how they will be addressed
Rolled into current feature iterations
Pushed to future feature effort
Pushed to a future phase
Although incremental implementation requires structure and discipline, the resulting improvements in efficiency, flexibility, adherence to documented requirements, and reduction of deployment-related issues make it a more effective and sustainable approach overall. Organizations that adopt this methodology often achieve faster results, stronger collaboration between teams, and a smoother path toward continuous improvement.
Conclusion
The success of an MES project depends on structure, communication, and strategic execution. Whether you are starting a new implementation, migrating an existing platform, or upgrading a legacy system, approaching the project with an incremental mindset allows your team to adapt as needs evolve while minimizing risk. A well-executed iterative strategy encourages early wins, promotes long-term engagement, and creates a foundation for measurable success.
Digital transformation is not a single milestone or one-time event. It is a living and evolving process that grows with your organization. By maintaining focus, communication, and adaptability, your MES implementation can continue to deliver value long after the initial launch.
Coming Next: Part 4
In Part 4 of this series, we will explore how project billing models and scheduling strategies influence MES project outcomes. The discussion will include comparisons between fixed price, time and materials, and milestone-based billing methods, as well as insights on how strategic scheduling affects project execution. Understanding these factors is essential for aligning financial structures and timelines with sound implementation practices, ensuring both technical success and stakeholder satisfaction.
