“Some people love to make things complicated. The key is to make things simple.”
(As recounted by Michikazu Tanaka in The Birth of Lean)
In the previous three posts (see Table of Contents), I highlighted Toyota’s Taiichi Ohno’s fascination with bringing simplicity into their production system. But Ohno fully realized that bringing simplicity into an already complex system required a lot of hard work. I emphasized the word “lot” on purpose. It is not easy to make things simple when all the forces in the universe are trying to make things more complex. That’s why I spent some time outlining the basic tenets of what is now called “complexity theory” in the previous posts. If you have not already done so, I would highly recommend that you read Part 2 and Part 3 of this series on complexity before proceeding further. (But that’s just me, read on if that suits your inclinations).
I had previously mentioned that many of the famous “tools” developed by Ohno and his compatriots (i.e., Just-in-time, Kanban, Jidoka, Heijunka, Kaizen, 5S, Standard Work, Material and Information Flow Diagrams, Visual Management, Teamwork, Respect for People, etc., etc.) had at least one thing in common – they all helped simplify a complex system. I threw this thought out there, but I did not explain “how” they simplified that complexity. I think that’s called a “teaser”. But now it’s time to deliver on that tease. Wish me luck!
Before jumping into Toyota’s simplification methods, let me put up Jim Rickards’ list of the attributes of a complex adaptive system that I introduced in my last post. I will refer back to this as I go through Toyota’s simplifications:
Complex systems begin with individual components called autonomous agents, which make decisions and produce results in the system. To be complex, a system:
- Requires diversity in the types of agents. If they are diverse, they will respond differently to various inputs, producing more varied results.
- Requires connectedness. …The agents must have a way to contact one another.
- Requires interdependence, which means that the agents influence one another.
- Requires adaptation. In complex systems, adaptation means more than change; rather it refers specifically to learning.
It is hard to imagine a production system that does not contain these four individual attributes. (Remember, a “production system” does not necessarily mean “manufacturing” – see link). I think even simple “Mom and Pop Shops” are blessed with all of these attributes to some degree. After all, suppliers and customers fall within the walls comprising a production system.
And remember also, the degree of complexity is defined by the amount of energy (labor, time, money, etc,) required to cope with each of these attributes. It’s not how much “connectedness” you have that defines the complexity of that attribute, but how much energy and effort you have to expend to deal with the “connectedness” that exists within the system. Simplification of a complex system simply means reducing the amount of energy required to successfully operate within that system. The individual attributes may increase, or they may decrease, but the energy expenditure required to try to manage these attributes decreases.
Now, back to Toyota.
I think a good place to start is probably Toyota’s most famous innovation – Kanban. As quoted in The Birth of Lean, Ohno stated:
“A big reason for adopting kanban was our desire to reduce the administrative burden of running a factory.”
In today’s vast compilation of Lean literature, I don’t recall seeing this reason popping up very often as the reason to adopt Kanban. Maybe I just missed it.
“Kanban automated production control. With kanban, people in the workplace issue production instructions automatically. They don’t need to think about writing up any special directions or about finding ways to convey those directions. With kanban, you don’t need a computer.”
In a previous post, “What We Should Do – Not What We Can Do”, I contrasted Toyota’s method of simplifying the Production Control function, i.e., Kanban, with the West’s approach of inventing a computerized MRP system.
Toyota’s method involved much more than just Kanban cards, they also decided to only schedule a single process center, usually one closest to the customer. The traveling Kanban cards then sent real-time demand requirements to all of the upstream processes – automatically and immediately. Demand was pulled from upstream processes. And as a result, demand requirements were always in sync through the entire process flow. And yes, there was flow – the new system created it.
MRP, of course, still sent scheduling requirements to all process centers individually, it just happened much faster than with paper schedules. But there was always a delay when demand changes occurred, and schedules had to be changed. And the process center schedules, being based on a push system, were rarely in sync with each other. Ever wonder why a lot of manufacturing floor department heads and/or supervisors hold daily mid-morning meetings to figure out what they need to produce that day? “Firefighting” continued as before, but faster and more frequently – because the computer facilitated it. But flow was basically impossible!
So which new system did a better job of simplifying a complex system? You already know my opinion just based on what I’ve said so far, but let’s just formalize it by using Rickards’ four attributes of complexity.
Remember, we are looking at how much energy each attribute consumes, not how much of each attribute there is. A score of 1 indicates bare minimum energy levels – and total boredom. A score of 10 indicates extreme, maximum energy levels – and total chaos.
First Toyota and the Kanban system. To be clear, I am only considering the Kanban or “pull” sub-component of JIT in this analysis. I am not considering the related sub-components of Takt time or Heijunka even though they greatly facilitate the effectiveness of Kanban. I’m just trying to keep it simple. I am also assuming the reader has a general understanding of how a Kanban system works.
[Note: I am also assuming that separate process centers remain separate. Therefore, traveling Kanban cards/signals must be used to communicate between these process centers. We all know that in real life, when Lean/TPS is implemented, we try to merge process centers whenever possible to create flow, e.g., manufacturing cells, flow lines, etc. In these situations, the need for formal traveling Kanban cards/signals is significantly reduced. Empty/full spaces, containers, shelves, etc., as well as a multitude of other visual signals can substitute for a formal Kanban system. But I have not considered this option in this comparison. To do so would decrease system complexity even further. And that would be cheating?]
- Diversity in the types of agents. The total number of agents went down since Production Control (PC) now had to schedule only one process center. Prior to Kanban, the PC group were the primary decision makers for all process centers. But with Kanban, the people running the various process centers stayed the same, but, with the exception of the one PC controlled process center, they were now the primary decision makers. With Kanban signals, the complexity of the decision making was much reduced. Diversity of decision making agents went up, but the diversity of decisions and the energy level needed to make those decisions and operate the system went down. My score: 4.
- Connectedness. Top level connections were reduced but lower level connections increased. Prior to Kanban, PC had to tell every process center what to produce and then the process centers had to tell PC what was actually produced. Now this only occurred with a single process center. But the various process centers were now connected – via Kanban. They had been completely isolated before. But these connections were simple and direct. Was the correct product (or service) delivered to the right place at the right time – Yes or No? If Yes, flow continues. If No, flow stopped and problem solving was initiated.in real time – not at the next day’s staff meeting. (“No” is Jidoka and problem solving is Kaizen). Information flow was streamlined and now in sync with product flow – via Kanban. My score: 4. (The score really depends on the number and frequency of “No” outcomes. In the beginning, I expect that “chaos” was experienced fairly frequently.
- Interdependence. Interdependence continued as before but became constructive rather than destructive. The process centers now interacted with each other in real-time, rather than after the fact. And consciously, not unconsciously as before. The process centers had always influenced one another but only in negative ways – flow stoppages/interruptions, flow surges, wrong product, etc. Either too much product, not enough product or the wrong product. The vagaries of a “push” system. Material flow was visible within a process center, but not across process centers. Information flow was severely hampered both within and across process centers. Problem solving was difficult and not in real-time. The “why” was hard to uncover. High energy requirements to cope – firefighting But with the Kanban “pull” system, decision making was simple and binary – Yes or No. Yes, the right product was delivered on time, in the correct quantity, in the right place or No, it wasn’t. And the “No” was seen in real-time and the “why” was much easier to uncover. Both material and information flow were visible and direct, i.e., simple. My score: 3.
- Adaptation. This is where the Kanban system really excelled. Kanban is one of the key active components of the all-important JIT/Jidoka relationship. This relationship is the focal point for “process learning” in the TPS system. JIT creates flow and Jidoka notifies you when that flow stops. And it notifies you in “real-time” (sorry to keep using that phrase over and over again, but it is a dominate feature of the process/human adaptation inherent in TPS). Jidoka is the GPS device to show you where to do Kaizen. And Kaizen is the TPS tool for continuous “process learning”. And Kanban, being the primary sub-component of JIT that creates flow, is also a primary player in making the JIT/Jidoka relationship work. Basically, a Kanban is a signal to produce, and if a Kanban is not present, production stops. And when production stops, Jidoka is triggered and Kaizen is initiated – on the spot, in “real-time”. Learning takes place in “real-time”. You learn the “why” much more easily when you problem solve “now” rather than “later”. Before Kanban, “later” was the universal norm. My score: 4. (On the energy level scale, the Kanban system only ranks a 1. The other 3 points are due to the urgent requirement for immediate problem solving).
I will have to admit that I have only scratched the surface in my analysis. I could write several pages on each of these 4 attributes if I wanted to be more thorough – but I don’t. These are the high points from my perspective. I’m sure many of you would come to different conclusions since this is such a broad “complex” subject. I welcome alternative viewpoints in the comments section. I am still learning.
Now on to MRP. According to Wikipedia, MRP was actually invented in response to the Toyota Production System by Joseph Orlicky back in 1964. (That was somewhat of a surprise to me. I didn’t think many people outside of Japan were aware of TPS in 1964. I will research this at a later time). I will only consider the original version of MRP (Material Requirements Planning). MRP ll, ERP, DDMRP, etc. were developed much later and are outside the scope of this simple comparison.
- Diversity in the types of agents. The number and diversity of agents increased substantially. The primary agent became the computer and its very expensive software. Most decision making was delegated to the computer. Production Control (PC) was also a primary agent in that they had to input the parameters that allowed the computer to make decisions. Determining what the proper parameters should be was a trial and error exercise in itself. New agents had to be created to run the computer – thus the advent of a large IT department. The largest number of new agents were the software users. This group increased dramatically since the software was available to anyone who took the time to learn how to use it. The old paper system was harder to distribute among potential users. But the MRP users were no longer decision makers. Their job was to do what the system told them to do (see connectedness). Setting this system up in an organization was a high energy (money and time) enterprise. Maintenance of the system by IT was also a high energy component. My score: 7 (Going from a 9 during set-up to a 6 once the learning curve was overcome).
- Connectedness. The number of connections increased exponentially. The quality of those connections went downhill dramatically. Instead of agents talking to agents we devolved to agents talking to the computer – and the conversation was one-way, computer to user (except, of course, the PC guys setting the parameters and the IT guys fixing the bugs). The old paper system required constant direct interaction between the PC decision makers and the production users. With MRP, both types of agents talked to the computer, not to each other – except when there were problems – and there were always problems. Connections were not well defined. Agent to agent connectedness tended to be of the high energy, never-ending, “firefighting” variety. All eyes were on the computer, not on the gemba. My score: 8
- Interdependence. Interdependence also increased dramatically due to the dramatic increase in the number of agents and connections. But because these agent connections were not well defined, interactions between agents tended to be indirect, unpredictable, haphazard and time consuming. The computer was supposed to hold all the answers but frequently did not. For MRP software to be effective, 99% data integrity was required. 99% data integrity was seldom achieved. Lead times, capacity and inventory levels were assumed to be a fixed constant by the MRP system. In real life this is impossible to achieve. MRP was the genesis of the terms GIGO (garbage in – garbage out) and the “bullwhip effect”. MRP was intended to solve the interdependence problem by allowing all agents to be dependent on the computer system. Unfortunately, the “law of unintended consequences” won the day. My score: 8.
- Adaptation. The advent of MRP initiated the largest adaptation effort ever experienced by the modern business world to date. Unfortunately, this gargantuan effort wasn’t aimed at learning how to improve our “production systems” but was aimed entirely at improving our “computer systems”. MRP evolved to MRP ll and then to ERP, ERP ll, DDMRP, etc., etc., etc. IT investments have become the largest category of capital expenditure in United States based businesses over the past decade. But what about MRP driven adaptation/learning within our “production systems” themselves? Well, a lot of effort has gone into learning how to use computer spreadsheets to download MRP data and make it more useful for a given facet of a production system. And if a given production plan doesn’t work as intended (and it never does), it is now very easy to just run another production plan – and another, and another, and another. That’s what computer systems are for, right? The product always gets out the door – eventually. My score: 9
OK, my analysis may not be completely scientific. And with respect to my treatment of MRP, I did get my tongue stuck in my cheek a little more often than I should. Don’t get me wrong, I love computers. I started using personal computers in my production departments in 1980 – Radio Shack TRS80 with BASIC software and DOS operating system. Not many old timers can say that! I used PCs because they appeared to make life easier for everyone – and I mean everyone. But it just helped us to do the “wrong things righter” – and faster. It did very little to help us learn to do the “right things”. In retrospect, MRP falls into the same category.
But back to the matter of “complexity”. I don’t think anyone can argue that Kanban did not simplify a complex adaptive system. I gave it complexity scores of 3-4. And I don’t think anyone can argue that MRP did anything to reduce complexity. It increased it. It just made doing the wrong things seem easier and faster. But the system and its attributes grew exponentially, as did the energy and money to manage it. I gave MRP complexity scores of 7-9 (chaos?).
But there is a simpler way to compare the two production control methodologies. Just compare the results. Typical MRP production operations experience lead time of weeks to months and inventory turns of 2-6. Typical Kanban based operations experience lead times in days to hours and inventory turns of 10-20 in the initial stages and may exceed 100 once all that Kaizen “learning” kicks in.
Just based on those two metrics, which of the two operation modes is more complex? Which one needs a computer to manage that increased complexity?
And remember, MRP has undergone continual major revisions and upgrades for the last 40 years and still continues. And if I have my facts right, those upgrades aren’t free. In contrast, Toyota’s Kanban system has remained basically unchanged for those same 40 years. Granted, those cardboard and sheet metal Kanban cards do wear out over time – but replacing them is quick and cheap. Which one do you think works best?
I will dig a little deeper into the structure of Toyota’s simplifications in the next post. And I will use the writings of a Harvard Business School Ph.D. to help me do it. I know, I haven’t been too complimentary about academics in past posts, but this guy actually got his hands dirty working in the trenches at Toyota both in Japan and in the U.S. I wish I could say the same. Gotta listen!