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

GPA's A Post-Mortem on the Unsuccessful Project You are About to Start Pt 1.pdf

Download PDF • 4.68MB

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. 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. A workshop once intended to align project expectations was derailed when a single stakeholder dominated 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. Presenting a potential solution along with any identified problem can transform how the issue is received and addressed. Effective leadership is not just about highlighting problems but 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 was envisioned. Similarly, detailed requirements are essential. “Sufficient detail” does not 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. This approach is often less desirable in manufacturing, where fixed revenue capacity and ROI are critical. Even Agile projects require discipline and a clear focus on delivering defined features. A hybrid model is often more effective—defining and estimating the project upfront while maintaining a contingency fund to address new, valuable features. This strategy mitigates risk while preserving some of Agile’s flexibility.