Are Your MES/MOM Skills Recognized?

Plant floor systems used to be simpler things: relay-driven machine logic, counters and gages that human operators could read and record values on their clipboards, control panels with numerous indicator lights showing what was happening at any given time.  But automation has evolved from those roots: industrial controllers have replaced relays, graphical HMIs with touch screens have replaced the lighted panels, and networks now exchange information between production equipment and enterprise systems – eliminating the need for a human with a clipboard, but also enabling new capabilities throughout the entire value chain.  This evolution has led to the development of a new body of knowledge, often referred to as Manufacturing Operations Management, or MOM. Many of today's industry initiatives – such as "smart manufacturing", "digital thread", "real-time enterprise", "connected enterprise", and "Industrie 4.0" – are deeply rooted in MOM.

What does this mean for leaders in the manufacturing space? In the current environment, executives need to ensure that both their internal people and external consultants are familiar with this evolving body of knowledge.  Just as with certifications such as Project Management Professional or Certified Business Analyst, hiring managers should be able to request candidates that are recognized by a professional body with extensive understanding of manufacturing operations management. Until recently, there haven't been good options available for identifying individuals with a solid understanding of MOM.  But on May 6^th 2015, MESA International announced a practitioner recognition program to do just that. MESA-recognized practitioners are members of the MESA organization who have not only completed an intensive MOM training program but who also regularly contribute to the ongoing growth of the body of knowledge through participation in MESA's committees and working groups.

So what are some of the things a MESA-recognized practitioner knows? Here's just a partial list:

• Manufacturing operations standards and relationships to strategic initiatives
• Adaptive manufacturing architecture
• The relationship of MES/MOM to continuous improvement and supply chain initiatives
• Transformation strategy including maturity and road mapping models
• MES/MOM implementation and governance
• Metrics frameworks
• MES/MOM justification
• MES/MOM project management techniques

Note these knowledge areas are different from what a typical controls engineer faces daily, but a MOM practitioner must have a working comprehension of the controls environment, continuous improvement practices, business processes (particularly in the areas of quality, safety, and maintenance) as well as an understanding of the IT landscape.

For a consultant (like myself), being a MESA-recognized practitioner will provide additional credibility beyond personal experience.  A MESA recognition carries a lot of weight; for those unfamiliar, MESA International is an association of manufacturing companies, solution providers, integrators, and consultants focused on delivering business results from manufacturing information technology. MESA is a recognized authority in this field; its white papers and other publications are frequently cited in trade publications, by industry analysts, and by a variety of consulting organizations. Their MES/MOM training is a comprehensive overview of the existing body of knowledge, and their committees and working groups are involved in the development and expansion of this knowledge.

The MESA-recognized practitioner program will establish an industry baseline for excellence in manufacturing operations management systems.  It will not only ensure that practitioners have been tested in the MES/MOM body of knowledge, but that they are also actively participating in the growth of that body. And that, in the long run, will be a very good thing for the industry.

An IIoT Nucleus - The Industrial Internet Reference Architecture

I just finished reading the Industrial Internet Consortium's (IIC) "Industrial Internet Reference Architecture" (or IIRA) document – all 101 pages – and it was much more than I expected. For those interested, IIC is a collaboration of solution providers, academics, and governments focused on meeting the needs of the industrial internet marketplace, particularly as related to the interoperability of components which make up current and future industrial internet systems. IIC is managed by the Object Management Group (OMG).

What is the IIRA?

When I first opened the IIRA document, I was anticipating something akin to the ISA99 reference model or Rockwell's "Reference Architectures for Manufacturing" – something that a manufacturer could customize and implement within their own enterprise. Instead, the IIC has put together an architecture targeting the entire industrial internet of things (IIoT) marketplace – both manufacturers and solution providers. This document establishes a common language and framework which – in their words – "transcend(s) today's available technologies" to create a shared understanding of how future technologies can interact with the industrial infrastructure. Instead of a Purdue-type model, think conventions, principles and practices for establishing an IIoT framework. Note that you will find models similar to Purdue and a tiered infrastructure within the reference architecture, so mapping between the existing body of knowledge (such as provided by MESA International's Global Education Program) and the IIRA will not be difficult.

The IIRA is multi-dimensional; it considers the architecture from four different points of view (business, usage, functional, and implementation) across a variety of concerns, including security, business context, automation/control, operations, and information management.

The document itself is clearly the work of many hands. The discussion of industrial internet system resilience has a distinct military influence, while the system composition discussion is definitely academic in nature. There are sections within the document regarding information security that bear the DNA of major players in the networking and IT industry, and discussions on control which come from companies with real-time automation experience. (It's geeky - I know - but I had fun guessing who wrote what.)

Why is the IIRA important?

The IIRA is not a specification, nor does it contain a list of applicable standards. Instead, it provides guidance for those designing solutions and establishing standards for the connected enterprise. Most importantly, it provides a common set of principles around which standards, requirements, specifications, and designs may be formed. Given the nature of the multi-vendor components which typically comprise a plant floor system, it's important to move beyond the discussion of physical characteristics (i.e. "Is it DIN-mountable?", "Does it have a RJ45 connection?", etc.) to the cyber characteristics ("Is the communication secure?", "Does it support Publish-Subscribe?", "Where does it reside in a 3-tier architecture?", etc.)  Pre-IIRA, implementers would be responsible for making components from multiple providers – if they needed to collaborate – work together through custom integration. IIRA creates an expectation that custom integration can be minimized or even eliminated by defining integrability, interoperability, and composability. 

Who should read it?

The Industrial Internet Reference Architecture is not something you're going to be able to digest in 10 to 15 minutes – it takes a fair commitment of time to read and comprehend (note to IIC – an executive overview PowerPoint might be in order). IIC's target audience includes component providers, system providers, and system implementers. I think the list should probably be a little broader, so here are my thoughts:

IIoT device OEMs: New devices, from industrial controllers to sensors to servo motors and everything in-between will be expected to collaborate with the larger industrial internet (or intranet for those excessively risk-averse) system.

Industrial Controls Providers: IIRA anticipates a transition from insular controls which currently dominate the market in discrete manufacturing to high-speed distributed controls.  This may indicate the need to enhance IEC 61131 or perhaps add IEC 61499 capabilities to existing automation controllers.

System Integrators: While the Purdue model is still valid, IIRA extends it and adds new perspectives – particularly in the area of security where the document stresses the need to include security by design instead of an afterthought.

Manufacturing System Consultants: Consultants need to be able to help guide manufacturers into this new industrial revolution and make the connections between the business perspectives and operations perspectives.

Control Engineers/Manufacturing Engineering Managers: Company executives are going to expect their engineering groups to be up-to-speed on the changing technology, and to interact with the marketplace to implement effective solutions.

IT analysts and managers: The convergence of information technology and operations technology that must take place for effect Industrial Internet Systems will require collaboration between the controls engineer on the plant floor and IT personnel. A shared understanding of the IIRA will help facilitate that collaboration.

Conclusion

The IIRA is – in my opinion – a much-needed addition to the overall body of knowledge in manufacturing operations management.  It will be a great help as principles and practices are developed around smart manufacturing concepts. I do hope though that there is enough interaction between groups such as MESA, SMLC, OMG/IIC, ISA, ISO and others to ensure a long-term consistent perspective is maintained.

An IIoT Wishlist

The Industrial Internet of Things (IIoT) is becoming a topic if interest among manufacturers, solution providers, and industry press.  According to an Accenture report ("IIoT: Unleashing the Potential of Connected Products and Services", January 2015), the opportunities for IIoT include:

• Long-term revenue growth
• Operational efficiency
• Connected ecosystems
• Collaboration between humans and machines

To me, there is one glaring omission from the ongoing discussions.  It seems the predominant focus is on what the technology can do to benefit the business, but there should also be some thought given to how the technology will benefit the people doing the work.  Fundamentally, technology is about enhancing the lives of humans by extending their capabilities and relieving their burdens; making more money should be a byproduct of enabling people to be more effective.

If you've been in manufacturing for any length of time, you have no doubt seen this happen: a new IT solution gets implemented with promises of improved productivity, but it ends up creating additional tasks for the person doing the actual work.  For example, a maintenance system which improves breakdown analysis and preventive maintenance capabilities requires technicians to find a near-by keyboard and monitor, log into the system, navigate a menu of potential causes, understand how to locate production assets and repair materials, keep track of work orders, and also type out the results of their investigations.  The technology has not enhanced their lives or extended their capability to get things done, it has just become an additional hurdle to being successful in their work.

IIoT has got to be about more than "smarter sensors" and "M2M communication"; the guiding principle in my IIoT wish list is that technology should be truly utilized for making the lives of workers better and extending their capabilities; this should become the primary focus of the new breed of industrial devices. The other benefits will flow naturally when people view the technology as real tools that help them do their job, rather than "stuff you gotta do to make the supervisor happy".

So here's my wish list for the IIoT:

• The time has come to get rid of keyboards on the plant floor.  Devices should provide information directly to systems without the need for human interaction.  Most of the information an operator or mechanic needs to input via keyboard comes from a source that can provide the same information through some digital means: for example, production and scrap counts can be provided directly from the machine controller, as can downtime symptoms.

• Make information available where the worker is instead of making the worker go to where the information is available.  This goes for HMIs, dashboards, SPC charts, work orders, MRO access, or any other reason they currently go to a fixed location to obtain the information.
• Devices should understand the context of the information they provide.  If, for example, a scale is taking a weight, it should "know" which sample it is weighing, what batch it belongs to, and what the acceptable weight limits are for the sample.  This requires systems be able to "talk" to the devices.
• There should be devices that can augment reality to assist people in doing their work; a mechanic, for example, should have access to an exploded view of a machine sub-section and instructional videos while he/she is repairing that component.
• Finally, smart devices must obey Asimov's Laws of Robotics.  I'm sure organizations like OSHA and IEEE would probably want a say in the matter as well.

I doubt this list is all-inclusive, so I'll call it my preliminary list for now.  I'm hoping others will contribute to my list; please feel free to share your own thoughts.  What do you think IIoT should do?

Strategy, Culture, and Breakfast

​​"Culture eats strategy for breakfast."  

In spite of all the Internet attributions of this quote to management guru Peter Drucker, there is some question as to whether he actually said it.  Although the phrase doesn't seem to appear in Drucker's books, one source traces it to Mark Fields of Ford Motor Company where it's said the quote hangs in the company war room.  Regardless of whether Drucker actually uttered these words, understanding the context of the idea is critical because it can be easily misinterpreted.

Imagine two armies preparing to battle each other. One army is very good at executing strategy, the other army relies on its culture.  You have a choice on which army to join; will you choose the army whose strength is strategy, or the one whose strength is culture?  If you believe culture trumps strategy, the choice is easy.  When you understand the relationship between culture and strategy, you will choose very differently.

Both culture and strategy provide a unique framework for decision-making.  Strategy is forward-looking; what is the organization trying to achieve?  Culture is inward-looking; what are the values the organization holds dear?  When these two frameworks are at odds within an organization, culture always wins because it embodies the organization's shared beliefs and sense of community.  Achieving a future state that is in conflict with culture is difficult at best.  But what about outside the walls of the organization, where other organizations compete?  This is where strategy is needed for long-term success.  It's also where culture can become a hindrance to achieving success, which is the original context of "culture eats strategy for breakfast".

Various studies have shown that only 5% to 15% of strategic initiatives (think Lean/Six Sigma/ToC, PLM, MES/MOM, SCM, etc.) are completely effective.  Frequently those inside the organization cite root causes as "lack of planning", "poor communication", "not having the right people involved", "poor requirements", or "unrealistic goals/lack of buy-in", but that's exactly what strategy/culture conflicts look like from within.  When "what we want to achieve" is in alignment with "who we are and how we do things", then planning, communication, buy-in, and requirements flow naturally.  When they're not aligned, it takes organizational energy to force things to move in the same direction, and frequently something gets missed.

I recently had the opportunity to hear Jodi Berg, President and CEO of Vita-Mix Corporation, talk about her efforts to turn around a lackluster business. The process did not begin with a strategic plan – it began with an effort by the executive team to understand then define the Vita-Mix culture, using a process called "appreciative inquiry" (which essentially means "understand what the organization does well, then do more of it.")  Vita-Mix makes sure every colleague knows the company's "edge", its mission, its values, its guiding principles, vision and objectives.  Everything else in the company can be changed, but only in alignment with the established culture.  As a result, Vita-Mix has become an iconic brand, their products highly prized by foodies globally.

"Culture eats strategy for breakfast" is not intended to express superiority of culture over strategy, rather to serve as a warning that strategy can easily be derailed by culture.  Businesses that take the time to understand both are more likely to find success in the marketplace.

Now, enjoy your breakfast.​

In Memory of Ziggy: A cautionary tale for smart manufacturing

The late 90's were heady times in the battery industry.  The Sony Walkman cassette players that had been all the rage were giving way to CD and other digital technologies. Digital cameras were supplanting 35mm as the consumer choice for photography. New and innovative battery-driven products were appearing daily.  Energizer and Duracell were in a continuous battle for who could produce the longest-lasting portable power solutions to keep these devices going.  The long-term prospects for the battery industry were for constant growth – and constant change.

One of the many challenges manufacturers face in such market conditions is designing manufacturing equipment capable of adapting quickly to change: how can you make continuous improvements to product on machines that were designed over a decade earlier?  To solve this problem, Energizer worked with local universities and NASA contractors to develop an advanced manufacturing platform called Ziggy. (The origin of the name is rooted in Energizer culture, and would be difficult to explain to outsiders.)  The concept we developed was a modular design based on SMED principles; as new product designs were developed, new "process modules" could be developed in parallel for the common transport backbone and could be dropped in place quickly as the process changes were released to manufacturing.  (Those interested in the details of this platform can see the patent here:http://www.google.com/patents/US6325198.)

In addition to a novel approach to manufacturing equipment, this concept required the development of a next-generation control platform as well.  Energizer had long before chosen to bypass the PLC industry in favor of internally developed controls based on the Z80 and Intel x86 architectures.  But Ziggy would require something different; modular components would need to communicate with each other over a network to form a collaborative system.  The selection of TCP/IP over standard Ethernet was a bold choice for time period, as was the use of C++ and intelligent agents. (Seehttp://www.google.com/patents/US6615091 for details on the control system.)

Between 1997 and 2000, a team of mechanical, electrical, and software engineers designed and built this new manufacturing concept (see the first two batteries being produced using this equipment on YouTube:https://youtu.be/NGieCKghakk).  A full three-chassis line was then built and implemented in Energizer's North Carolina battery facility, where it produced millions of double-A batteries.

But Ziggy died.  The reasons were not technological, although there were still technology issues to overcome.  By 2003, Energizer had been spun off from parent Ralston Purina to form a stand-alone company.  Management perspectives were changing, and principle champions of Ziggy had left the organization.  The competitive environment was changing as well; digital devices did not require as much power as the older analog technology, blunting the "longer-lasting" competition and nearly eliminating the need for major product changes.  Additionally, many of these devices incorporated rechargeable technology, reducing the long-term outlook for growth in the primary battery market.  Ziggy was seen as overly complex in comparison to the available alternatives, and was abandoned.  The production line sat idle in the plant until it was finally written off the books and dismantled.

In many ways, Ziggy presaged the current "internet of things" and smart manufacturing principles being espoused by groups such as SMLC and Europe's Industrie 4.0.  The lesson here is that smart manufacturing is about more than just technology; there must be real business drivers and organizational commitment for smart manufacturing to find long-term success.  Without these, the current, familiar technologies used every day will not give way to the new challengers.​

Who Drives Change?

Lately I've been thinking about change initiatives within an organization, particularly about who owns these initiatives and harnesses them to achieve true value.  Whether it's Lean, Theory of Constraints, Product Lifecycle Management, Business Process Management, Manufacturing Operations Management, Supply Chain Management, Resource Consumption Accounting, or even Project Management, someone must champion the initiative from conception to integration.  There is, of course, a whole management consulting industry around organizational change, and I think that's a valid approach for assisting change.  However, consultants do not have ownership of the initiative; they can sell and support, but only the owner can derive business value.

So who's responsible for change within an organization?  The answer cannot be "everyone" – when everyone is responsible, then no one is accountable. "Management" also seems to be too vague as an answer; who in management will decide which initiative to pursue?  Responding with "It depends on the initiative" seems to fall flat – the kinds of transformational initiatives previously mentioned have organization-wide impact, and pigeon-holing one into a business silo seems to be the oft-cited cause of failure.  What's left seems to be the executive team, but given their other responsibilities for running the organization, driving change initiatives often falls into lower-tier priority levels.

One approach that has gained a foothold is the creation of "Offices" or "Centers of Excellence".  Project Management and Lean tend toward the "office" moniker (PMO, Lean Office), while BPM, PLM, and MOM frequently utilize the "CoE" tag.  No matter the name, these are changes to the organizational structure that can work between business siloes to achieve the strategic initiative.  These have the advantage of being focused on the success of an initiative – resources are allocated and the team/group/department is accountable for specific results. People can look at the organizational structure and say "this group is responsible for driving change related to this initiative."  Depending on organizational precedence though, even these sub-structures are at risk of being siloed.  For example, Lean is typically "owned" by Operations, and other parts of the organization are often free to choose whether or not they want to participate in the initiative.

Change is as certain as taxes

I think the change to organizational structure is the right approach, but must be divorced from existing business sub-structures.  There needs to be a C-level executive responsible for organizational change, not only change management but leadership as well.  The fact that organizations have CFOs, CIOs, COOs, and heads of HR and Marketing is an acknowledgement that specialized focus is necessary in these areas; I'm arguing that the same can be said for organizational change.  The "Chief Change Officer" would lead a team of business architects, analysts, internal consultants, and change facilitators to:

• establish standards and practices
• institute governance
• assure alignment between organizational entities
• make changes to existing organizational structures as new technology permits new capabilities
• engage and involve the organization in change
• provide measures to the executive team demonstrating the value of change as it is implemented

Perhaps this could be called the "Office of Strategic Change Leadership (OSCL)" or "Change Leadership CoE (CLCoE)".  All the existing CoE's would become subsets of the CLCoE, creating a clear line of accountability throughout the organization for successfully adapting to change.

Some studies have shown that organizational change efforts account for between 25% and 35% of every project budget.  Other studies have shown that transformational change initiatives are unsuccessful over 40% of the time, with only 5% being completely successful.  With these kinds of numbers, it's clear that organizations need to become better at adapting to change.  It's axiomatic that when Management wants to make something happen, they change the organizational structure to ensure it does.  It's time this same logic is applied to change itself.

The Real Skills Gap

There's been a great deal of discussion in industry press about a growing skills gap – typically focused on technical skills but occasionally on leadership skills as well.  The March 16^th issue of Crain's Cleveland Business had a front page article on manufacturing leaders nearing retirement; "Who", they ask, "will run the manufacturing industry when the generation in charge eventually walks away?"  The US Chamber of Commerce Foundation published a 2014 white paper entitled "Managing the Talent Pipeline: A New Approach to Closing the Skills Gap" which paints a dire picture of talent systems that are not keeping pace with economic requirements, and manufacturers who struggle to find the skills they need in the job market as talent nears retirement.

Peter Cappelli of The Wharton School skewers the current understanding of "Skills Gap".  His 2012 book "Why Good People Can't Get Jobs: The Skills Gap and What Companies Can Do About It" debunks the mythology of technical skills gaps, and states the problem really lies within the systems used to acquire talent.  The April 2014 issue of Inc magazine contains an article entitled "Why the Skills Gap 'Crisis' Is Overblown", offering further evidence that the skills gap isn't as great as we've been led to believe.  Interestingly, both sides of this argument focus on management systems to resolve the issues around acquiring needed skills.

To me, this suggests a very different kind of skills gap – the skills around strategic planning and management.  I recently attended the Siemens/Electro-matic "Manufacturing in America" Symposium where one of the seminars was focused on acquiring and maintaining technical expertise.  A slide shown during this session depicted one company's skills gap analysis, with large deficiencies over a broad range of skills. This left me wondering if the company's leadership had a clear understanding of the skills required to operate their business.  But acquiring people for skilled trades and keeping skills current is just one symptom.  On March 13^th, iBASEt's Conrad Leiva posted a blog noting a disconnect between Manufacturing Operations Management strategy and challenges.  He cited a recent LNS Research study,  and observed a mismatch between respondent's stated objectives and the business challenges they are experiencing – and recommends a realignment of objectives to address challenges rather than a myopic focus on cost & quality.

In his book "Good to Great", Jim Collins notes that Level 5 leaders "look out the window to apportion credit…they look in the mirror to apportion responsibility"; perhaps it's time for corporate leaders to look in the mirror to address the skills gap they may find there.