MES project execution: 3 mistakes to avoid
For those of you who have had the opportunity to work on a manufacturing execution system (MES) implementation project, you know they can be very large and complex. Consequently, there are many things that can go wrong if not properly executed.
An MES project, in addition to its project specific functionality, provides the link between plant floor control systems and corporate level business systems. I have seen a very simple transaction manager with limited capability, as well as complex multi-location MES installations. Both were called MES. The exact boundaries of the MES will most likely depend on the customer and the current systems they have in place. An MES installation can be custom developed, or “off-the-shelf” MES software packages can be purchased from many different suppliers. When selecting a product, be careful of “out-of-the-box” solutions. Even out-of-the-box software packages will mostly likely require substantial configuration and custom coding in order to fit specific functional requirements.
A typical MES installation will interface to just about every job function and department within the manufacturing operations, including scheduling, warehousing, maintenance, operations management, controls, and production team members, just to name a few. When implementing an MES project, it is very important to understand everyone and every system that will be affected by the implementation.
Mistake 1: Not having the right people on the team from the start. A critical step in the project planning process is for the project manager and project sponsor to identify and assign representatives from each of the affected departments to the project team. These key people will need to have an understanding of the scope and be involved from the beginning. Throughout the project, the MES team will be relying on their expertise. Not having this expertise will result in failure when it comes time to go live. The project sponsor needs to provide the support for resources to be involved from the beginning. Getting involved in the middle is too late.
Now that you have all of the right people in the room, it’s time to get to work on the definition. The definition phase is where most of the processes will be defined and the functional specifications will be developed.
Mistake 2: Not enough time spent understanding the processes with which the MES will integrate. During the definition phase, it is easy to get side tracked with features of a particular package or details of implementation, but the critical step is to make sure that the processes MES will interface to are well defined. Using flowcharts is a good way to layout these processes. You may have defined the interface points, but it is essential to understand the process with which the MES application will be integrating. Live time is not when you want to hear that the production floor “process doesn’t work like that”. Take the time to understand not just the interfaces, but also the processes to which they will integrate and impact the operation.
Mistake 3: Using traditional waterfall project execution methods and assumptions. The MES project is different from a traditional control project that would normally have a very detailed scope and exact details of current system. The size and scope of the MES will require a more flexible approach to development. In a typical control system project, once the design is completed, the system and functional requirements would not be changed significantly. As with most IT systems and the case of MES, they are changed and updated more frequently. This constant change can create problems if part of the design is based on something that has changed. The traditional waterfall method of complete project definition, then detail design, and then development would require going back to the start and working through the process each time the system or functionality has been changed.
One method to overcome this problem is to use an Agile programming technique. Agile programming techniques allow for flexibility by developing small pieces of functionality during specific timebox periods, called sprints. Each sprint starts with prioritizing the functionality requirements for development. The requirement is then designed and developed during the sprint. Any backlog or incomplete functional requirement will again be prioritized before the next sprint and finished accordingly. These smaller development sprints, essentially allow for development to take place dynamically, give the project team flexibility to adapt to system and functional requirement changes that have taken place since the definition phase of the project.
I hope these tips will make your next MES project a success. As always, please feel free to share your experiences and comments!
This post was written by William Zupon. William is project manager, automation solutions at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.