Wednesday, November 26, 2014

Mind the Gap

"Mind the gap" is a phrase that originated in the Lon​​​don Underground (subway system).  It is intended to warn riders of a potential hazard that exists between the railcar and the platform.  People unaware of this hazard can stumble, trip, and be injured.  The phrase has also become the title of a popular BBC America blog that warns of the differences between the British and American cultures.
There is a gap in most manufacturing operations of which we should be aware as well.  Continuous improvement strategies such as Lean and Six Sigma have done much to increase the effectiveness of manufacturing operations.  However, there remains a gap that practitioners of these techniques frequently overlook: the power and capabilities of available technology is not reflected in the implemented processes.

The Gap

Many manufacturing processes have been implemented with an incomplete understanding of the capabilities of existing technology.  The term "process" here is used broadly: it refers not only to the value-adding steps of transforming incoming materials to outgoing products, but all the interactions of people to make this transformation happen.  In his book "Competitive Advantage", Michael Porter introduced the concept of the "value chain", which describes how an organization delivers value.  Porter's chain is similar in concept to other lifecycle models, tracing value from origin (inbound logistics) to termination (product service). Each link in the chain has its own internal "chains" (or "value streams" in Lean terminology), and each of these have their own set of processes.  Undergirding all of these processes are foundational services provided by organizational infrastructure, HR management, and technology.
Value Chain.jpg
Figure 2: The value chain ("Competitive Advantage", Michael Porter, 1985)
Typical kaizen and DMAIC approaches will involve people whose upstream or downstream processes intersect with the "as-is" or "to-be" state (the horizontal axis of Porter's value chain), but frequently do not include people from the enterprise systems in the discussion (the vertical axis).  This eventually leads to disconnection between process and technology – the "gap".

An Example

Every manufacturing plant has some form of maintenance, repairs and operations (MRO) inventory.  Responsibility for this inventory is usually given to the Plant Maintenance department, or sometimes to Engineering.  Initial stocking levels are determined using processes such as "reliability-centered maintenance" (RCM) analysis, but on-going stock levels are determined based on experience and governed by simple rules such as "never run out of critical parts".  Maintenance and engineering people are not usually trained in inventory management techniques, so concepts such as "safety stock" and "service level" are foreign.  Rules around when to re-order and order quantities may be tribal knowledge, and those rules may not take into account changes in lead time or material consumption patterns over time.  This inevitably leads to excess inventory.  Other areas of the business usually have implemented consumption-based planning and have materials resource planning (MRP) technology readily available which could be used in MRO, but the people responsible for MRO do not know the full capabilities of the technology.  There's the gap, and the plant leaks money – almost unnoticed - in terms of unneeded inventory and carrying costs through that gap.  This gap can be closed with simple training and modifications to the existing processes (and perhaps bulk updates to the material master records in the ERP to take advantage of the MRP technology.)
This is just one of many examples of the process/technology gap; many more exist.  Some gaps, when closed, have the capability to totally transform the organization.  Examples of this may be found in strategic initiatives such as Product Lifecycle Management (PLM), Manufacturing Operations Management (MOM), and Business Process Management (BPM).  Others, such as the MRO example, simply require knowledge-sharing and minor process tweaks.

Closing the Gap

Like the riders of the London subway system who intuitively (or perhaps from an unfortunate experience) know to step over the gap, it can be very difficult for those immersed in the day-to-day activities that surround a process/technology gap to even recognize the gap exists.  They have adapted to processes and found ways to make things work.  They may be aware that processes are sub-optimal, but cannot place any priority on improving things because they work well enough to keep production running.  This applies to internal analysts as well as managers: they are just too close to the situation to see the process/technology gap.  It has become part of the fabric of operating the business – the way things get done.

Awareness

The key to closing a gap and recovering business value is to recognize that a gap is real, even though those within the organization may not see it.  Most manufacturing executives have a vague sense that something is missing and that technology can help, but until a situation changes from a perceived minor annoyance to an actual pain-point they cannot assign priority to investigate improved methods.

Networking

There are many organizations which can help identify gaps and recommend strategies to prevent future gaps from forming.  Some are manufacturing industry peer networks (IPNs) where non-competing organizations interact to share best practices; according to an MIT/Sloan Management Review research article (Winter 2006), these IPNs help address issues categorized as myopia and inertia – the underlying causes of the process/technology gap.  Other forms of networking include professional organizations such as MESA International, IEEE, and ISA.

Consultants

An outside consultant can be an extremely valuable asset.  A good consultant brings value that exceeds the cost of his or her services by at least a factor of ten. He or she brings a different perspective than can be found by those enmeshed in the daily workings which include the unwritten business rules that allow processes to operate.
Too Busy to Improve.png

Tuesday, November 11, 2014

Control Engineering - The Next Level

While I have not investigated university-level engineering curricula recently, I have the impression that most engineers that work with industrial controls graduate with some level of competence in computer programming. I don't want to diminish the value of the skills these engineers possess, but I do want to make and observation: an engineer who writes software is not the same thing as a software engineer.  This observation comes not just from personal experience working with industrial control developers for many years, but from conversations with other professionals with similar experiences.
Some comparisons:
  • An engineer who writes software believes the current revision of the source code is what is currently running on the controller; anything on a PC or network storage is a snapshot of the current version and should not be relied upon to function in the same way as the version running on the controller.  A software engineer believes the current revision of the code resides in a version control repository with official release records.  If what is running on the controller varies from the official version, it is considered an illegitimate release.
  • An engineer who writes software is highly pragmatic; the goal is to make a process or machine work.  A software engineer accepts the goal of making the process/machine work as one of numerous requirements to ensure optimal business value.
  • An engineer who writes software sees each project as a unique problem set requiring a unique solution.  A software engineer looks for design patterns and implements reusable objects/modules to not only provide a solution for the current problem set, but to reduce the cost of future solutions as well.
  • As long as production and regulations are not impacted, an engineer who writes software may not be constrained by existing standards.  A software engineer embraces standards because they improve code maintainability, reusability, improve enterprise integration, and reduce the life cycle costs of the solution.

Why it Matters

Before the proliferation of PLC-based controls, production equipment was driven by relay logic.  After the introduction of microprocessor-based controllers, ladder logic was implemented to provide a familiar "relay emulation" approach to control programming.  In the relay-driven world, getting the machine to function correctly was the main requirement - this did not change with the introduction of the PLC.  But PLCs have vastly more capabilities than the relay-driven control systems, and ladder logic evolved into the IEC-61131 standard which provides for higher-level programming capabilities.  Then came graphical user interfaces and a variety of SCADA tools to provide even greater capabilities, but with added layers of complexity as well.  With complexity comes cost and the need for management.

Controlling Costs

Accounting practices vary from organization to organization, but source code (whether for industrial control or any other function) can be considered a capital asset.  Studies have shown that the initial cost of development is 20% or less of the total life cycle cost.  This has implications for everyone developing software: find ways to optimize your organization's software development practices to reduce the long-term costs associated with maintenance.

Risk Management

In addition to maintenance costs, business risks must also be taken into consideration.  Relay-driven equipment is not threatened by internet viruses, but nearly every PLC or PAC being sold today has an Ethernet connection, and the number of controllers being connected to the enterprise network grows daily.  There are also downtime risks associated with controller failure; if the "current software release" is only available on the controller on the plant floor (as opposed to a version control repository), it will take much longer to get production going again after a controller failure. 
There are also risks associated with system upgrades.  Many modern control platforms have a server-based footprint in addition to the controllers on the plant floor.  Not only do control engineers need to be concerned with firmware revision management on the plant-floor controllers, but must also be concerned with operating system patches in the server room.

Enterprise Integration

Controllers are becoming a bigger part of the manufacturing business, because they contain valuable production information, including production history, machine health, asset effectiveness, parameter change history, and more.

In Summary…


All of these factors point to the need for controls engineers to become proficient software engineers rather than engineers who write software.  It would be easy to place the accountability for this transition on management, but this really is more a leadership challenge than one of management.  Control system professionals cannot simply accept status quo, but must actively seek to improve and they should not wait for management to direct them.  If anything, they should be teaching management what changes are necessary to meet the business demands.  Standards (such as ISA-88, ISA-95, and ISA-99) exist that help establish the necessary disciplines; it's time for software engineers to step up in industrial controls!