Agile 101 for MES
I’ve been talking Agile PLM for some time now, but always avoided the discussion around Agile in the context of MES/MOM, generally because I’d not encountered anyone prepared to “go there”. At long last I found someone!
Super bright, super personable and an expert that doesn’t stop hunting for that very best “open” solution. Sung Kim, the CTO from iBASEt has much to explain and show about his and iBASEt’s approach to Agile MES.
Today however, rather than steal his future thunder, as we’ll get chance to do that in January when we meet again.
In the interim, I wanted to open the door to that Agile MES agnostic world as a pre-cursor to the weeks ahead, during which I plan to unlock the complex sector of Smarter Manufacturing.
In my opinion, it doesn’t get much tougher in terms of “people change” than that of an Engineer on the ‘line’. He/she’s been doing things in a certain way for years and is generally skeptical of some new technology application/guy suggesting things could be done better.
However, the reality today is the environment in which modern manufacturing organizations exist is rife with changes. These changes appear in the way markets are disrupted and evolving. Products are being manufactured more and more in line with customer preferences and these mean multiple changes. The resulting changes in manufacturing processes, in almost every industry segment, are occurring at a much faster pace than before. Technology, both in manufacturing and information, is evolving rapidly and changing the way in which manufacturers design and deploy products to satisfy their customers.
To respond to these turbulent demands, manufacturers need processes, technology and of course their people to enable and adapt. It’s happening directly on the line, through evolved MOM processes and MES Applications, integrated back’n’forth with the essential PLM and thereafter across the ecosystem.
Most of the major manufacturers have implemented or are thinking of implementing manufacturing execution systems. There are many manufacturing companies who have not formally implemented MES, but they are still implementing, embedding, or capturing MES functionality each day.
Everyone processes orders, manages materials, and tracks personnel in many non-standard ways in their supervisory control and data acquisition/human-machine interface (SCADA/HMI) systems or even in manual logs.
Many Enterprise Application projects fail, go through budget overruns, or do not meet expectations. The Reasons for these are quite varied but typically include a poorly defined scope/objectives, people change, and the wrong selection of technology, software or integrator.
The manufacturing operations are complex and follow distinct operations in every industry and even company to company. As a result, it’s not unusual to see custom-built with limited options to interface with other applications, which is of course key to the future integration for customer-centric delivery. And then occasionally, someone adds to the list and decides they’re so unique, they’d like to build from scratch their own MES.
Some of the most common reasons for MES failure include:
1. Lack of commitment from the senior management/C-Suite for the MES development.
2. Unsuitably qualified/experienced program team
3. Poorly thought through and defined business processes/workflows
4. Wrong MES software
5. Poor existing IT infrastructure
6. 11th hour scope creep
7. Wrong production line/unit selection for pilot testing the MES application
8. Lack of initial and ongoing user training
9. Lack of business, process and cultural change modeling
I’m a big believer in moving fast, making the mistakes, learning and therefore getting ahead of those who wait around, constantly seeking opinions, waiting for others to make the mistakes first and therefore always destined to follow. We must always remain fluid, given the rapid advancement in customer thinking and resulting products in the 4IR.
Having chosen your Application Solution, and Integrator, both of which we’ll start to consider in another article, we move to an Agile approach in introducing the MES layer (assuming your software vendor can “handle it”).
Successful MES implementations require an Agile project management style, rather than traditional project management. Managing process improvements, MES functionality and people change in “sprints” is more effective for these long-term, high-risk projects.
While today we’re seeing an ever-increasing choice of MES/MOM Applications in the market, a project based on these always requires a significant amount of design and customization. This is because the main purpose of such a system is to support the business processes upon which operations are based, bridging the gap between production and strategic management. Those processes are different from company to company and highly variable because of the company’s needs to adapt itself to ever evolving/Engineering-to-Order market demands.
An MES or MOM project typically takes a considerable length of time to implement, with significant costs and a high inherent risk, since it impacts operations and production capacity, especially during the implementation phase while users are learning to use the new system. Mitigating the risk and economic impact of these projects requires careful attention to project management and a well-defined process of software development lifecycle management (SDLC).
Getting Started, the “Old Way”
It starts and it ends with people, culture and moving both toward the future. Stepping back for one moment, I think that one of the reasons why this lasting change takes so much time is that there is an enormous pressure in our human psyche to maintain the status quo. Our mind is like a rubber band; you can easily stretch it temporarily, but it snaps back to its resting position. We resist change.
We crave the familiar; we take refuge in what we know. There is a basic principle in the deep layers of our unconscious that sameness is safety and change is danger. This is why it so hard to break a habit, even if we know it is not good for us.
So, the work of change requires us to overcome this misconception — believing that we need the very thing we are trying to give up. We can only detach from them, piece by piece, as we find a better reality to attach to — also, piece by piece.
Back to the program: As a result, gathering a comprehensive list of requirements assumes the business has already changes made in its mind, which of course doesn’t come easily for us. Therefore, gathering requirements starts with the user who is generally unprepared to assess the impact that the adoption of an MES system will have on its organizational arrangements and therefore tend to define the user requirements based on past experience. The mindset change occurs over time.
This leaves a traditional approach to project management fraught with unrealistic expectations. Involving blocks of activity; closing one, opening another as we move through General, User Requirement, Functional Requirements and Detailed Design Specifications.
Thereafter, between drafting the initial specifications and the time when the client starts to use what has been made, some time passes. This implies that any possible error of assessment in the initial stages has a heavy impact when it is detected.
Fast & Flexible
In contrast to theses traditional methods, agile methods are far more iterative and incremental in nature, where development of software is an ongoing continuous activity. The emphasis in this approach has shifted from excessive documentation to presenting actual and functional code to the customer. It demands participation of self-organizing, cross-functional teams, which perform adaptive planning and work towards evolutionary development. The time-boxed iterative nature of this method makes it faster and more agile, and thereby more effective for environmental conditions characterized by constant change.
A dramatic shift is under way in manufacturers’ expectations for MES capabilities:
· Deliver accelerated results, with reduced total cost of ownership.
· Holistic, quality implementation focused on quick time-to-value.
· Early and frequent confirmation of the delivery of benefits.
· Demonstrate capability to solve customer pain points early in the deployment.
The agile approach however has some limitations. Its fragmentation can lead an organization to proceed without a clear vision of the objectives / the bigger picture, sometimes forgetting what it has previously learnt and losing the organic vision of what is made. The best approach appears to be an agile, non-standard approach, in which the first two phases (General Specification and User Requirements Specifications) of the SDLC process are broadly maintained, keeping in mind these will change, followed by the implementation phase conducted in sprints.
This ensures that the project is addressed with an overall view of objectives, needs and expectations of the user that can provide a guideline throughout the implementation phase. The User Requirements Specs (URS) are broken up into sections corresponding to the modules, organized on the basis of shared priorities with the client that then will be realized through specific sprints. Each section contains the “as-is” processes mapping, the “to-be” mapping, and the description of the functional specification to achieve.
This allows the beginning of each sprint process to include an analysis of the URS specific to the sprint, considering if what has been achieved up to that point has affected the requirements in any way that would require some adaptation. Only then do you proceed to the drafting of functional specifications of the module along with the realization phases, test and implementation.
An implementation approach for MES
There are various approaches to Agile, however my favorite and the one that makes the most sense is SCRUM. The backbone of SCRUM is continuous face-to-face communication, incremental progress through new functionality via developing and testing the product simultaneously. On each release, the client feedback is therefore quick, allowing for ongoing adjustments through the proceeding sprints.
The great thing about SCRUM, is it should combine the key elements for a successful transformation to the new MES solution:
· Product Owner — the voice of the business & their priorities
· Development Team — develops a potentially usable product
· Scrum Master — responsible for facilitating the practice of scrum, chair meetings, maintain flow, ensure collaboration and most importantly removes impediments in the way of delivering the final product
What makes Scrum so effective is the way in which stakeholders are constantly involved in the deployment process and generates a product that is needed rather than what was planned years ago.
Agile Scrum for me makes complete sense as it doesn’t rely on upfront requirements gathering. Furthermore, with MES an application that’s deemed requiring plentiful customization to fit the uniqueness of each manufacturer, allowing for macro requirements with micro adjustments throughout the sprints is the ideal approach.
Incorporating flexibility in the process itself is what makes these agile techniques more desirable and more sensible. MES applications are practically useless if they are unable to model the ever-changing flows of manufacturing plants.
The applications and the deployment must be agile, collaborative and faster than ever before. Both should be set up to enable and entertain change, which will make the manufacturing operation more proactive and more Agile.
Rounding it off
The manufacturing business of the future needs to be lean and needs to engage the intelligence of the MES layer that can then be overlaid with Smart Factory 4.0 Technologies and integrated to the PLM and ERP.
Next time around, let’s delve much deeper into the Agile Deployment of MES