A Post-Mortem on the Unsuccessful MES Project You Are About to Start: Part 1

Post Mortem Part 1.pdf

Download PDF • 7.61MB

A few weeks ago, the idea for this white paper series took shape. It is not meant to paint Digital Factory projects in a negative light but rather to guide you through common pitfalls I’ve observed over the years. While some of my observations may seem obvious, I’ve witnessed firsthand how neglecting these factors can derail a project. My hope is that sharing these experiences will spark valuable discussions as you plan or continue your MES journey. Initially, I intended to write a single comprehensive paper, but I soon realized that breaking it into a multi-part series would improve readability. I plan to release a new part every one to two weeks.

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.

Over the last few years, I have adopted a proactive approach to the topics discussed in this series. I even developed a “Success Assessment” chart that evaluates project success based on 34 contributing factors grouped into four categories. While this tool is not a crystal ball—a low score doesn’t doom a project, nor does a high score guarantee success—it helps identify critical areas that need attention at the project’s outset.

Philosophy and Approach

A robust MES installation is a complex undertaking. Serving as a bridge between the IT and OT worlds and integrating disparate systems demands more design considerations than a typical software solution. Adding the human element only deepens the challenge. This paper is not meant to sound overly pessimistic but rather to underscore the significant effort required. In my experience, a plug-and-play MES solution is rare—perhaps only about 5% of the time—and even plants within the same company can have vastly different processes and expectations.

Collaboration is key. Success comes not only from a strong partnership between the customer and the vendor but also from cohesive internal teamwork. In projects where stakeholders operate in a partnership mode, outcomes improve significantly. I once held a workshop intended to align project expectations. However, a single stakeholder hijacked the discussion, wasting valuable time and setting an adversarial tone that persisted throughout the project. In contrast, when customers approach the project as true partners, the results are demonstrably better. I learned early on that presenting a potential solution along with any identified problem can transform how the issue is received and addressed. Effective leadership isn’t just about highlighting problems—it’s about guiding the team through them.

Documented Requirements: The Cornerstone of Success

The first and most critical contributor to project success is well-documented requirements. Consider the process of buying a car—nobody simply says, “I want a blue car,” and ends up with exactly what they envisioned. Similarly, detailed requirements are essential. “Sufficient detail” doesn’t mean every feature must be designed before development; rather, each feature should be documented well enough to support a reliable effort estimation.

Step 0 involves the customer clearly defining what they need or want to achieve with the MES solution. This step typically includes input from Subject Matter Experts (SMEs) across departments—Production Engineers, Plant Floor Users, Plant Managers, and more. For instance, Production Supervisors and Operators can provide crucial insights into designing a user-friendly interface and ensuring operational success. Although not every requirement will be finalized in this initial phase, conducting on-site workshops to thoroughly understand the production process is highly recommended. Such sessions often uncover previously unconsidered needs that can be addressed by the MES.

Once requirements are gathered, they must be documented—focusing on the “what” rather than the “how.” The document should be platform-agnostic at this stage, with specific technologies introduced only during the proposal phase. Objectives for this document include outlining the current process from materials receiving to finished goods, describing how orders are generated and processed, and detailing each operation in terms of:

• Information Flow

• Process and Production Data

• Materials Utilized

• Equipment

• Operator Involvement

The document should also define the targeted opportunities, linking them to ROI considerations. For example, statements like “Our output is 70% of expectation, and we want to understand the root causes” or “We are scrapping 25% of production at certain operations” make clear the issues at hand. However, caution is advised: chasing new technology without addressing an identified problem is rarely a solid foundation for an MES solution, although future-proofing can be a valid objective.

Types of Documentation

There are three common document types for requirements:

1. User Requirements Specification (URS):

   • Converts requirements into user stories from the end-user’s perspective.

   • Typically 15–20 pages, with basic diagrams.

   • Best suited for straightforward production systems with limited complexity.

     
     

2. Functional Requirements Document (FRD):

   • Provides detailed descriptions of how the software should operate, including behavior and data interactions.

   • Organized by features and operations; includes diagrams such as UML interaction diagrams, transaction data tables, screen wire diagrams, and architectural considerations.

   • Typically spans 40–75 pages, making it ideal for larger, more complex solutions.

     
     

3. Functional Design Document (FDD):

   • Focuses on implementation details and is often broken down into DevOps stories and tasks.

   • This document is usually developed during the design phase and will not be covered in depth here.

     
     

Once the requirements are documented, it is crucial for all customer stakeholders to review and refine the document. A superficial review does a disservice to the effort invested. A thorough examination helps align project expectations and minimizes the risk of conflicts later on. Early revisions are the least costly and disruptive—neglected changes at this stage may lead to costly change orders or reduced scope during later phases.

Agile vs. Traditional Approaches

Some MES projects are executed using an Agile methodology with Time and Material billing, where requirements evolve during development. I find this approach less desirable in manufacturing, where fixed revenue capacity and ROI are critical. Even Agile projects require discipline and focus on delivering project features. I prefer a hybrid model: define and estimate the project upfront while maintaining a contingency fund to address new, valuable features. This strategy mitigates risk while preserving some of Agile’s flexibility.