A Post-Mortem on the Unsuccessful MES Project You Are About to Start: Part 5
- GPA
- Nov 12
- 10 min read
Updated: Nov 18
Access to Customer Systems: Two Tin Cans and a String Doesn’t Cut It
In the modern world, there are seemingly an endless supply of bad actors who want to hack systems for fun, profit, or other nefarious reasons. That said, most projects require at least some direct access to site servers and production devices during development and commissioning. Going back to an automobile analogy, a car needs to be serviced and the service station informs the customer they can fit it in two days from now. The customer responds, “Great, I’ll bring my car in 6 weeks from now!” That doesn’t work so well, does it? Though a bit flippant, a similar scenario has played out many times over the years. Obtaining access to the internal network often turns into a roadblock for project momentum, halting testing for months in some cases. In one instance, commissioning was originally planned within two weeks of access approval but had to be postponed after a three-month delay. Even if an existing system is in place, live, read-only connections to production equipment are valuable, if not critical, in designing and testing new code.
Depending on the company and the industry they work in, implemented security
can vary, but in most cases, there is still some means of secure access from external systems. Standard security systems use basic firewalls to limit access from the outside world and can usually be accessed using a VPN connection after applying customer-supplied settings. More secure systems have DMZs using multiple firewall layers with limited access from the outside, sometimes restricted to company-supplied secure laptops. Finally, for critical industries such as utilities, only on-site system access is achievable. Though more difficult to implement in this case, knowledge of this limitation at the beginning of the project allows proper planning.
Planning is key in eliminating or reducing the risk associated with system access and should start before the project even begins. The first step is to identify what access level is required for the different phases of the project. The customer should work with their IT or Security team to verify the required access level is achievable. If not already, the procedural steps to grant access should be documented. The worst-case timeline—often the typical one—between access request and implementation should be identified. Proper priority should be given to access requests for MES projects. This also ties into the section discussing stakeholders, as having someone in IT responsible for the project helps ensure responsiveness to these requests.
One last point on this topic is RDP access. The default limit is two users when accessing a server through RDP. This usually isn’t an issue unless someone logs on and doesn’t log off when finished. It is recommended that when leaving a desk for more than 10 minutes or at the end of the day, users log off. Doing so helps minimize the impact on accessibility and ensures smoother project collaboration.
Technology / Platform: The Right Tools for the Job
Over the years, it is common to accumulate a sizeable collection of hand and power tools in a garage. For most of them, the purchase occurs in preparation for a project, as many people prefer to handle home maintenance tasks themselves when it can be done safely and effectively. This approach reflects a simple philosophy: use the right tool for the job. Though more complex, the same principle applies when selecting an MES solution. There are several important considerations when determining the best direction to take.
First, the evaluated platform should accomplish the organization’s current digital factory goals while supporting potential future growth. If an MES solution must be replaced in five years because a site adds a quality department or new production testing needs arise, it becomes difficult to justify the investment.
The next consideration is the cost of ownership. This figure can be difficult to calculate fully but typically includes licensing fees, customization costs (since few installations are completely out of the box), and maintenance fees. It is advisable to estimate the total costs over a five- to ten-year period for comparison between possible platforms. Some MES licenses are based on equipment or seat counts, so it is important to consider future growth that could impact these costs. Additional expenses may arise from licensing in multiple environments. At minimum, a QA or staging environment should exist to test releases before migration to production. Depending on internal resources, there may also be a development environment for continuous work. These additional servers and environments should be included in cost-of-ownership calculations.
Another factor to consider is what can be referred to as the “black box effect.” As a strategy to protect intellectual property, many MES software companies compile their code and use hardware or software keys to control access to specific features. This practice can improve efficiency, simplify maintenance, and reduce cost since users pay only for the features they use. However, this structure can become problematic if the code does not function perfectly. Few systems are released entirely free of defects, even with thorough quality checks and regression testing. If an installation is affected by such a defect, it is important to understand in advance what level of support to expect. Reading online discussions and user forums about the software can help gauge the frequency of issues and the vendor’s responsiveness. While these discussions often emphasize problems, they still provide valuable insight into potential risks.
When meeting with representatives of companies proposing MES solutions, the experience can vary widely. Some sales representatives focus on promoting high-margin options rather than those best suited to customer needs.
One of the most critical steps to a successful MES project is first defining what success means for the organization.
Except in the simplest cases or with highly experienced customers, a series of workshops with key stakeholders is strongly recommended to capture and document requirements in detail. Only after this step can a solution be planned that satisfies those requirements. It is beneficial to evaluate current operations and identify potential improvements that can be implemented alongside the new MES application, but the organization should avoid scenarios where business processes must change to fit the software without meaningful benefit.
Integration capabilities are another vital consideration. The chosen software must communicate effectively with both enterprise-level applications and plant-floor devices. Platforms supporting OPC, MQTT, and API protocols can address a large portion of integration needs. Many also include built-in connectivity for mainstream vendors such as Allen-Bradley, Siemens, and Modicon. When such built-in support is not available, bridge software like Kepware can serve as a reliable intermediary. Another frequently overlooked integration point is database connectivity. Some MES platforms are developed for specific databases such as SQL Server, which can be advantageous for companies standardized on that system or supporting multiple engines. However, organizations relying on other platforms, such as Oracle, may find their internal support effectiveness reduced.
For nearly three decades, the modern consumer digital age—marked by widespread internet and mobile access—has transformed expectations for technology interfaces. Gone are the days of purely Unix-style user interfaces. Earlier MES systems required proprietary client installations to display operator screens, but today many provide HTML-based designs compatible with mainstream browsers across multiple devices. During system evaluation, the range of supported devices should be considered, from large displays to smartphones and everything in between. While responsive design allows layouts to adapt across screen sizes, caution is necessary, as significant differences in size often require distinct layouts to maintain optimal usability and visibility.
To close this section, below is a list of MES features commonly offered as part of a solution. These features can serve as discussion points with stakeholders during system evaluation and planning sessions.
Order Execution
Personnel Security / Operation Assignment
Overall Equipment Effectiveness (OEE) & Downtime
Production Sequencing / Scheduling
Material Genealogy
Quality Management System (QMS)
Analytics
Recipe Management
Documents Management
Inventory Management
Enterprise Data Management
Maintenance Management
Tool Lifecycle Management
Andon Messaging
Environmental Monitoring
Compliance
Batch Processing
Most projects look for multiple features to be implemented as part of the solution. This is one of the contributors to the complexity of the project but can be well managed with the appropriate execution methodology.
Project Execution Methodology: The Path to the Finish Line
As previously stated, MES solutions can be complex, with many moving parts and the need for coordination between stakeholders and implementation teams. The foundation of any solution begins with a solid platform but still requires at least some customization to meet specific or unique requirements. Due to this complexity, the development methodology used by the solution provider can significantly influence project success.
In the past decade, OT development has become increasingly aligned with tools and practices traditionally associated with IT disciplines. The degree of alignment depends on the software platform. Many MES platforms include proprietary scripting and UI development environments that can be difficult to integrate with productivity tools such as GitHub. The ultimate objective is
for project objects to achieve compatibility with these tools in the same way applications are developed and versioned in environments like Visual Studio. This compatibility allows objects to be version-controlled and deployed automatically through DevOps-style pipelines. Some platforms have already achieved this level of maturity—for example, Ignition offers a GitHub add-on that streamlines the development workflow. Even though many MES platforms have not yet reached the same degree of sophistication in their editors, developers can still apply proven development approaches and best practices established through decades of IT experience.
Various methodologies can be followed during project execution, but two of the most common are Waterfall and Agile, each with distinct advantages and disadvantages. The purpose here is not to restate the extensive documentation already available on these methods but to provide a concise overview for understanding their philosophical differences. The main distinction lies in approach: Waterfall follows a sequential development structure, while Agile emphasizes iterative processes and incremental progress. The Waterfall development process can be described in the following steps:
Requirements Definition - Documenting the project's goals and needs
Solution Design - Design the final project based on the documented requirements
Development - Building the product based on the design
Testing - Verifying the product satisfies the requirements without issues
Deployment - Migrate the solution to the customer's environment
Maintenance - Ongoing fixes and improvements after deployment, usually as a support agreement or new project
Waterfall development is a linear and sequential methodology, with each phase flowing naturally into the next—hence the name. There are several advantages to this approach:
Less coordination as all requirements are documented at the start of the project
Easier to identify dependencies
The full project budget is easier to estimate as all requirements are detailed
Better focus on documentation
More detail in design of the solution
As well as disadvantages:
More difficult to break up work with stricter phases
Time delays and extra communication during phase transitions
Doesn't make good use of cross-functional teams
Product ownership and engagement not as focused as large work units
The Waterfall approach tends to be rigorous and structured. Because it is designed to operate in a single direction, it requires more detailed documentation and upfront planning. This structure also means it has limited flexibility—once a phase is completed, it is not intended to be revisited (otherwise it might be more appropriately called the Whirlpool method).
A variation of the Waterfall approach that can make projects more manageable is known as Waterfall by Feature. As the name suggests, this version applies the Waterfall methodology to individual features. For example, the OEE feature would progress through each defined phase, and once completed, the next feature would follow the same sequence. Though not truly iterative, this method simplifies project execution by breaking it into smaller, more manageable units of work. It is less rigid than traditional Waterfall and allows incremental process improvements with each successive feature—essentially moving development closer to the Agile mindset.
The Agile methodology, by contrast, focuses on iterative software development. In this approach, the project is divided into manageable artifacts that the development team can address in short, repeatable cycles. Agile development ensures the final solution includes all the planned features as well as additional capabilities that emerge through the development process. There are multiple variations of Agile hierarchy depending on the project type and internal practices, but a common structure includes the following:
Project - overall goal or achievement
An MES solution for our injection molding and assembly plant
Epic - Feature that is part of project
Order scheduling and execution for orders from ERP
Stories - Collections of tasks that are usually achievable within a sprint
Build a page to display and execute production orders
Tasks - Small pieces of development that contribute to the story
Create a database table to store production order information
The same structure can apply to other aspects of the project, such as site preparation and bug fixes / enhancements. The actionable tasks form a backlog which is ordered by feature sequence and priority. One of the important characteristics of a task is that an effort estimate is assigned in hours. Based on the length of the sprint (typically one to four weeks) and developer availability, an appropriate number of tasks are pulled into the sprint to be developed. There are phases of a sprint as follows:
Sprint Planning - what backlog items are to be worked on
Daily Stand-ups - short meetings every day or few days to report progress and any roadblocks
Sprint Review - what was accomplished during sprint and if ready for release
Sprint Retrospective - what went well, what didn’t, ways to improve
The structure of the development team is also different under Agile (admittedly, similar functional analogs exist under Waterfall):
Product Owner - manages task backlog and requirements
Scrum Master - scrum process facilitator, helps resolve development roadblocks
Developers - responsible for building and developing releases
As with Waterfall, there are some advantages to developing in an Agile style:
Faster feedback from end users which can be acted upon
Issues are identified early in the development process
Flexibility helps with customer satisfaction
Improved efficiency
More transparency
Efficient use of developer power
Focused on delivering value
Some of the disadvantages in this approach are:
Requirements may not be as well defined as waterfall initially
Team transition to this methodology involves a learning curve and initial inefficiency
When employing CI/CD (Continuous Integration / Continuous Delivery or Deployment), there is additional technical debt incurred
Full Agile methodology works to maintain continuous integration and continuous delivery (CI/CD) with incremental releases after each sprint. In MES development, maintaining this pace can be challenging unless sprint durations are extended beyond the typical two-week cycle. For that reason, a more flexible release schedule based on feature completion is often more effective. Releases may occur after one to three sprints, allowing teams to retain the core philosophy and advantages of Agile—just not at the same frequency as full CI/CD cycles.
Final Thoughts
This concludes the white paper “A Post-Mortem on the Unsuccessful MES Project You Are About to Start.” The intent of this series is to share key lessons and considerations for achieving greater success in MES projects. Industrial automation and factory systems are vital to modern manufacturing, and careful planning, collaboration, and disciplined execution are essential to realizing their full potential.
The purpose of this paper is not to discourage or criticize but to provide guidance drawn from extensive industry experience. As the saying goes, “The journey of a thousand miles begins with a single step.” Digital transformation should be viewed as an ongoing partnership between the customer and the solution provider—not merely a series of disconnected projects.
A methodical approach grounded in preparation, planning, and the principles discussed throughout this series will not guarantee success but will certainly put organizations on the right path. May these insights serve as a resource for teams embarking on their next, or first, MES journey.
Future discussions on MES implementation and digital transformation best practices will continue to build upon these foundations—encouraging safe, thoughtful, and effective execution as the industry evolves.
