Avoid the current state tar pit!

“Current physical tar pit” is an expression I first heard when I got involved with the design of information systems for manufacturing in the 1980s. It is a special case of analysis paralysis brought on by digging so deep into the details of existing operations so you cannot extricate yourself from it, and are caught like dinosaurs in a tar pit. The phenomenon was first described by Frederick Brooks in his classic The Mythical Man-Month about software engineering.

The key issues are:

• Current, Ideal and Future States in Manufacturing and Software
• Mapping in Manufacturing versus Software Engineering
• Mapping the Current State: How Far Should You Go?

Current, Ideal and Future States in Manufacturing and Software

In setting the requirements for a new system, analyzing the existing one was the first step, and you were supposed to start with the way it physically worked — that is, follow the data from the computer screens, bar code readers, sensors, or paper forms with which it was collected, to the databases in which it was stored, the programs that transformed it, and finally the output produced, whether it was machine controls or instructions and reports for humans.

The next step was to abstract the underlying logic behind the current physical system. Regardless of technology, what was the meaning of what was being done? What information was input and output? What was the system trying to accomplish? What were the concepts? If the system was dysfunctional, was it due to the limitations of its hardware or flaws in its logic? The answers to these questions were the key, first to designing the logic of a new, better system, and then to selecting hardware on which to implement it, with the understanding that all sorts of trade-offs would be needed to keep it affordable and its development time short enough for users not to lose patience.

This was similar in spirit to the current, ideal and future state mapping stages that are commonly recommended with Materials and Information Flow Analysis (MIFA), also known as Value-Stream Mapping (VSM). It should also be noted that, while the mapping of information flows is key is systems analysis for software, it is by no means the only tool. In 2013, you have a kit called Unified Modeling Language (UML), which also includes tools to map database structures and the state transitions of resources like machines, vehicles, materials, or containers.

Mapping in Manufacturing versus Software Engineering

Whether for information systems or for factories, the approach is intellectually attractive and its rationale unassailable. Practicing it, however, whether in designing software systems or production plants, has been challenging. In manufacturing, at least, the software systems introduced over the past 30 years have been mostly perpetuating old approaches with new technology, and have been more often an obstacle to improvement than a driver of it.

Let us consider a couple of actual examples:

1. You have machining centers used to carve batches of identical parts and you want to switch them to making instead sets of mating parts going into the same assembly. This is a typical step in the conversion of a plant to Lean, but I have seen it not done on the grounds that the planning system did not support this mode of operation. In other words, a job could be defined as multiple units of one item, but not multiple items drawn from the bill of materials of an assembled product. It is clearly a case of the tail wagging the dog. Technically, it is not a show stopper in that, given management will, a manual workaround is technically feasible, but it is an embarrassment with a system that has been recently implemented at great expense.
2. You bought an automatic storage and retrieval system (AS/RS) for pallets of materials. But, rather than pallet-loads, Production needs parts delivered in bins picked from pallets, and you discover that the AS/RS control system does not support the logic of retrieving a pallet, picking a bin from it, and storing it back with a lower quantity. Since the cost of upgrading the control system for this purpose being prohibitive, you set up a manual warehouse for partial pallets.

When you encounter such situations, it is a clear sign that the analysis process described above has been executed poorly, if at all. It is rarely done well, because is requires a mix of software engineering skills and manufacturing knowledge that is both rare and under-appreciated.

Mapping the Current State: How Far Should You Go?

The current state analysis has the following two purposes:

1. To let the analysts understand the reality of the starting situation and thereby ensure that proposed ideal and future states solve its problems in a way that is realistic, both from a technical and a human point of view.
2. To communicate the need for change inside the organization. Its members are tied up in daily operations and have not had the opportunity to step back and consider the system as a whole.

The analysis should be deep enough to achieve these goals, but no deeper, lest the analysts fall into the current state tar pit. Current state flows are usually convoluted and informal, involving things like favor banks between individuals, and you can spend your entire career getting to the bottom of it without ever making any improvement.

For example, once you have established that the dispatch lists from ERP are not followed on the production floor, you don’t need to figure out the details of what is being used instead. You know you have a scheduling system that doesn’t work and you can focus on figuring out what you should use instead.

Of course, the real current state is more functional than the dispatch lists, and it involves having scheduling decisions made by production supervisors, team leaders, or even operators. The real question is not whether particular individuals do a good job of it, but whether it is a job they should have to do at all. However scheduling is done, whether manually or electronically, it should not require shop floor people to make judgement calls. It should unambiguously tell them what to work on, in such a way that the materials, machines, tools, specs, process programs, and people are available to actually do it.

It would be useful to know all the details of the current state, but it is often impractical because it would take too long and the end result would be an unintelligible tangle of flows. In addition, if you insist on digging too deep, you may end up like the anthropologists to whom tribesmen lie about their culture. It’s like the spaghetti mapping of physical flows. Once you have established in one location how awful it is, and management recognizes it, the team can move on to designing how the flow should be, and not just in the area where it has drawn the map.

If you can dig deeper, and do it quickly, more power to you. What I am cautioning against is getting bogged down. In every organization, there are opponents to change who will be happy to see you stuck. While you are struggling to extricate yourself from the current state tar pit, they can blithely go on with business as usual and wait you out.