Multi-site standards have to be economically viable, but Operational Value of standards is the driver vs IT requirement

While flexibility allows us to deal with the plant floor reality, it also comes at a cost and thus requires governance. This is typically where the IT and Engineering perspectives tend to clash:

1. Standardization (what Corporate IT desires): How to deploy “out-of-the-box” or packaged solutions that reduce risk and time-to-value in implementation across the plant sites? Increasingly Operational value is driving standards and platforms.
2. Flexibility (what Engineering desires): How to support the various customizations to accommodate the heterogeneous nature of the process within a plant site?

But with the growing demand for agility and ability to absorb new production plans, new product introduction with minimal impact to day to day operations. Combine this the ability to “accommodate variability” in automation systems often from different vendors across multiple plants, or equipment, as well variety in team skills, and experience. The implementation of platforms combined with standards provide the necessary abstraction to “accommodate” this variation. So move to standards is growing driven more from the operational continuity drive than IT (which drove it based upon cost of implementation and sustainability).

To solve the above two seemingly opposable expectations, large enterprise users of a platform use a Center of Excellence approach to centrally manage the template library while helping orchestrate each of the plant’s technology roadmap in a way that is aligned to their Continuous Improvement journey.

The illustration below maps (at a high-level) the governance process of how templates are created, maintained, and modified to support the rollout across a multi-plant standardization effort.

Many of the most successful companies driving standards, are now seeing the rewards and return through agility to absorb new plants into their organization, yet leverage the existing unique automation, plant floor systems.

But so many of them comment to that they learnt the hard way the need for governance, yet site collaboration to make the standards effective and adoption successful. Too many state building standards from the corporate center out seems logical, but in reality so much knowledge is in the field and the need for capturing that experience back into standards is key. Plus the shift with standards away from a project DNA to more of “product” life-cycle DNA is key.

The important learning is that standards are part of a program, they part of learning, but return is significant now not just IT point of view but from an “Operational side” and this is where the significant economical returns are seen through operational consistency, and agility. Understand that standards is a program, clear understand the required governance to succeed long term, and investment up front with the field so the standards will be adopted. Combine this with clear kpis to understand the reason why your implementation a platform and standards so the value can be measured for the long term, as this is a long term initiative that must enable sustainable innovation.

The Industrial Software space continues to outgrow its labels!!!!

As the 2014 draws to a close, I seem to be sitting in a growing amount of long term strategic meetings both within Schneider-Electric and within customers and discussing the landscape of 2020 -2025. What immediately happens is the labels we have used for years for products, spaces, and roles no longer mean the same thing. We rapidly find ourselves setting up a glossary of labels and what they will mean in 2020-25 in order to gain alignment.

Putting a label on this space has been challenging because it has evolved over the last 20 years and will continue to change as many technologies converge towards an integrated industrial software platform strategy.

1990 - 2010: The label “MES” was first introduced in 1990 to refer to a point application at a single site (typically Quality Management). Over the next 20 years, more functionality was added to MES to keep pace with Automation trends.

2010-2015: In recognizing its evolution, some industry analysts have offered new acronyms like MOM (LNS Research), while others have redefined MES as follows:

“For many, MES is no longer a point application, but a platform that serves a dual purpose: integrating multiple business processes within a site and across the manufacturing network, and creating an enterprise manufacturing execution capability.”

-          Gartner Group, Vendor Guide for MES 2012

Today/Tomorrow: As the industrial computing paradigm shifts to the internet, the platform is now being leveraged for other assets distributed across the interconnected value chain while extending the rich optimization functionality via new applications to get more productivity in areas outside of manufacturing. This platform maybe on premise but is rapidly growing to been a hybrid of on premise and “off premise” (cloud) solutions that enabled the shift to “managed Solutions” with standards. Required to gain consistency, and transparency across the value generating assets.

We started to see this transformation in early 2000s when a simple activity such as Performance /OEE on a packaging line became dramatically more complex. A different solution when it went from one line to many lines on a plant, and then the same standards, downtime reasons across 100s of lines over multiple plants. It was then that I realized in the meetings internally I could not use the word MES generically and needed to become specific.

Another area we finding this is around the HMI (human machine interface) traditionally it was a window into my process/ PLC and that is what InTouch was famous for. Again in internal meetings and with customers I struggle when they use the term as we have completely different functions in the operational experience been referred too. The diagram below shows the landscape we face in Operational Experiences today in a typical industrial company; they are all often referred to as HMI.

Just last we in a design meeting we were defining the strategy for certain notifications to brought to attention. The architectural suggestion was to have the advanced asset application send events to platform alarm and event system; this will expose them across the enterprise. This is the correct answer, but people struggled with it as they had in their mind HMI/ Supervisory, yet when defining the approach I was not thinking supervisory. I was thinking roles and that operational planning, asset planning roles require these notifications. By putting them on the common event bus, they could be picked up their interface which is filtered for these events, or by workflow so that procedure who notify them.

Again it was simple case of labels and peoples understanding of labels, when we ended up on the white board it all became clear.  

  

In the diagram above a Process HMI is a basic screen with alarms typical of InTouch, this very different to Site based system which requires process awareness, alarms, but operational data such as asset state, production schedule, log books etc.

 It is much easier to avoid labels and define the situation. scenario / role, and start the meeting or strategy session laying out the landscape for discussion, gain alignment on the “desired outcome” and destination first, it makes it easier!!!!