Antifragility and Plant Floor Systems

Few words strike fear in manufacturing operations executives as do "enterprise system software upgrade".  Once uttered, there is an almost instantaneous demand to IT for assurances that all existing processes will still function after the upgrade has been completed.  In many cases, the existing platform has been customized, tweaked, interfaced, and personalized beyond anyone's ability to fully know.  Clearly, the current state of enterprise-level systems is "fragile".

In his thought-provoking and frequently irreverent book "Antifragile: Things That Gain From Disorder" (Random House, 2012), Nassim Nicholas Taleb introduces the concept of antifragility.  Antifragile systems thrive when exposed to volatility and change.  The very nature of continuous improvement is constant change, which begs the question: "How can our plant floor and enterprise systems keep up?"  With practices such as kaizen and DMAIC becoming ubiquitous in manufacturing, there needs to be some thought given to making systems such as MES/MOM, ERP, SCM, and PLM not just robust (indifferent to volatility), but antifragile.

This is particularly challenging to information technology professionals.  In a traditional waterfall life cycle, requirements gathering takes place early in the project.  In the iterative, agile approaches the requirements are refreshed incrementally.  Neither approach addresses the issue of requirements that change after the software has been delivered; a new project cycle must be initiated to deal with such "problems".  Unfortunately, change is the very nature of manufacturing and engineering systems.  This leads to IT project backlogs, self-developed applications (such as complex Excel spreadsheets or Access databases), demands for commercial off-the-shelf point solutions, and other forms of duct tape and chewing gum patches.  Then come additional requests to IT to propagate, integrate, and maintain these patches.  Finally, managers spend precious time prioritizing requests, allocating resources, and determining value, and it is because deployed systems are fragile.

Making manufacturing systems antifragile, in my view, requires two elements: a modular enterprise architecture that takes axiomatic design principles into account and effective business process management.  Axiomatic design has found a home in design for six-sigma processes, but needs to be extended into the IT world as well.  It is based on two fundamental axioms:  the independence of functional requirements must be maintained, and the information content of the design must be minimized.  Such an architecture would share common master data, provide domain knowledge modules with well-defined interfaces.  It would provide a common user interface layer independent of any of the specific domain modules, and BPM would bind the platform together to deliver dynamic work processes which could change as instantly as needed based on a kaizen or value stream mapping event.

There is current thinking in line with this approach.  In their 2006 book "Enterprise Architecture As Strategy", authors Ross, Weill, and Robertson of MIT/Sloan's Center for Information Systems Research recommend a maturity growth model which leads to the kind of modular architecture previously discussed.

CISR Enterprise System Maturity Growth

Michael McClellan of Collaboration Synergies Inc. has proposed a similar approach in his white paper "Manufacturing Enterprise 3.0: The New Information Management Paradigm Built on Process".  In both cases, the approach is strategic and incremental.  It does not require a "rip-and-replace" mindset.  Some suppliers are moving in this direction; we've recently seen Dassault purchasing BPM supplier Apriso and PTC buying ThingWorx in the PLM space.  SAP is offering BPM solutions, and there are other cross-vendor integration BPM solutions (such as WinShuttle) available.

We need to move away from the fragility of our current information technology and create antifragile systems which embrace change to support a culture of continuous improvement.  I would love to hear other thoughts on how this can be achieved.

BPM vs. Big Data

I recently went to a local "meet-up" on Big Data.  This event was very well attended, with a great deal of "buzz" on the subject.  I listened to several presenters discuss Hadoop, architecture, network requirements, and other subjects around large data sets.  My interest is from a plant-floor perspective: is this technology something anyone would implement in manufacturing?  What kinds of applications would be appropriate?  There is a tremendous amount of hype surrounding big data, and I noticed there were a lot of young, bright IT people participating in the event so apparently there is a great deal of expectation around Big Data becoming the next "big thing".  But nothing really caught my imagination regarding the applicability of Big Data to the manufacturing problem domain.  I left wondering if there is more flash than substance in Big Data.

In contrast, later that week I attended a vendor-sponsored event where clients discussed success stories around BPM-based solutions.  The crowd for this meeting was smaller, and consisted more of seasoned IT and management professionals.  The cases discussed were immediately relevant to manufacturing and business value was obvious.  Yet this strategic initiative (it's really much more than "technology") doesn't seem to have all the gilding and hoopla that I observed with the Big Data crowd.  As I pondered this, I started to think about which would have a greater impact on the future, and to me the answer is obvious – BPM, hands down.  Here's why.

Organizations go through a maturation process in systems architecture.  MESA International models this as beginning at an application-centric thinking level – everything fits a business silo, and there are many point solutions which IT is left to integrate.  The next level of maturity is data-centric thinking; standardized data sets (master data) shared between applications with appropriate centralized governance.  The third level is interface-centric thinking, where interfaces are defined which allow applications to interact in real time.  At the apex of this maturity model is process-centric thinking, where multiple applications cooperate to implement end-to-end business processes.

Clearly, BPM is at the top of the strategic food chain; Big Data is somewhere around level 2.  Big Data is an answer in search of a problem, but BPM is all about getting things done in the least-waste way.  One common question that arises in the plant environment is "What are you going to do with the data?"  That's a question Big Data cannot answer, but BPM can.  Big Data does nothing for the mechanic on the plant floor who needs to learn the ERP, the CMMS, the Maintenance Dispatch system, the MES, the PLM, and other systems to do his job.  BPM can knit all these systems together to form a "blended application" specific to that particular mechanic – and without getting IT involved.  Big Data may be all the rage now, but if you're investing for the long term I would recommend BPM.​

MES/MOM As Strategy

Recently I have been seeing quite a bit of discussion regarding ROI for MES/MOM. MESA International released a strategic guidebook on the topic in May. ISA debated the topic “MES Does Not Deliver A Return on Investment” (Youtube:https://www.youtube.com/watch?v=p_O9Wlw69gU) at its MES Conference in Cork, Ireland in March. There have been some recent blogs on the topic posted to some MES/MOM-related groups on LinkedIn as well. I don’t want to diminish the importance of ROI for MES/MOM, but focusing solely on ROI is a mistake. The problem is that measuring the impact of MES/MOM is quite difficult, because the value comes from improved processes and increased velocity of resolving issues rather than from the technology itself. Yes, we need to answer the ROI questions, but we also need to move the discussion into a higher plane as well. We need to start talking about MES/MOM in strategic terms.

There are tons of books and articles on strategy, but it isn’t really that difficult a concept to wrap your arms around. Strategy is simply the context in which decisions are made. Why does an army go around an obstacle instead of taking the most direct route? Why does a billiard player choose one shot over another? Why does a chess player choose to sacrifice a rook to move a pawn? Why does a business choose cost leadership instead of differentiation? In each case, the situational dynamics allow a number of choices to be made, but the best choice is always made in context of the desired goal. In the absence of strategy, the default choice will nearly always be the path of least resistance.

How does this relate to MES/MOM? What you will find in a majority of manufacturers is a plethora of point solutions. These manifest themselves as spreadsheets, stand-alone applications (Microsoft Access, for example), and “siloed” systems (SPC, CMMS, Maintenance Dispatch, etc.) – often developed internally or purchased without consideration of a bigger picture. Frequently (I want to write “always”, but there are exceptions) these point solutions are incompatible with each other, making aggregating information difficult or impossible. But solving plant-floor problems almost always requires combining information from multiple sources, forcing someone – typically at the engineering level – to become a data integrator and to make connections between these systems. Point solutions represent the path of least resistance (and if you can avoid getting IT involved, there is even less resistance), and are indicative of decision-making which occurs outside a strategic framework. The hidden cost of an ineffective plant-floor IT strategy is the reduced speed of problem-solving.

An example will help illustrate this. Improving equipment effectiveness (OEE) requires an in-depth knowledge of downtime causes, quality defects, and equipment speed. It also requires an understanding of responsiveness to downtime causes, reliability improvement efforts, machine maintenance history, and replacement part availability. All this information is distributed between the ERP, the CMMS, the QMS, maintenance log books, kaizen newspapers, and engineering notes. Gathering the information from each of these systems and creating a coherent understanding is time consuming, which means solutions are delayed and someone is getting paid to put the picture together instead of implementing the solution. These costs may not be quantifiable but never the less impact the bottom line.

In addition to ROI discussions with management, there needs to be a very strong emphasis on strategy regarding MES/MOM implementations. This is where maturity growth models (not to be confused with capability maturity models) are helpful. There are two models that I am aware of: one from MESA International (as taught in their Global Education Program), and one from MIT/Sloan Center for Information Systems Research (CISR) as presented in the book “Enterprise Architecture as Strategy” (Harvard Press, 2006). This is also where standards such as ISA-95 start to become important. MES/MOM implementation needs to be the core of a manufacturing IT strategy, a strategy which needs to be embraced by the organization’s leadership. Solution providers (bless them – they’re doing God’s own work!) cannot drive strategy – that must be done internally. Ultimately, it is strategy which will define the success or failure of an MES/MOM implementation.​