I found a great article about the Toyota Production Systems (TPS) terminology. TPS is also known as Lean and is the basis of The Goal, The Phoenix Project and DevOps. I’ll be using the terminology a lot in the future, so take a moment to read up on the terms. A shared language helps ensure effective communication. We’ve already discussed Kanban, here are some other terms to focus on:
“Question everything!” You’ve heard this a million times. You probably try to do it, sometimes, too. The underlying tenants of The Goal, the Theory of Constraints, Lean, and other methodologies relies on questioning assumptions. It’s important, but what exactly does it mean, and what do you do afterward?
First off, it’s not a license to literally ask questions about every business decision at every opportunity. Many questions can be answered in your own head before you open your mouth, so there’s no need to bother others with those questions. For the rest, go back to the theory of constraints and ask yourself if it’s a bottleneck first. If not, the answer might not matter. Above all, always be courteous and understanding of the situation before speaking. If you do literally question everything, you will be treated like an a-hole of the first degree and your message will be lost. There’s a time and place for everything. Continuing on…
In the right context, “Hey, wait a minute, why exactly are we doing that?” is a good question. Sometimes there is a good answer, but other times the answer is simply, “because.” That’s not a good answer. For example, someone who lives in SoCal suggested I salt my car’s tires in the winter. Though I have lived in the north, I had never heard of doing that. I asked where they learned to do that. Many years ago, the person went to college in Pittsburgh and saw buckets of salt near parking areas. They saw someone else pour salt around their car’s tires, so they assumed that is what it was intended for. Turns out it was for the sidewalks.
You might find what that person did humorous, but before you snicker, look around your business – are you sure you’re not doing something simply because your colleague or predecessor did it? A long time ago, I found out I had been swapping backup tapes every morning on a system that had been decommissioned but not powered off. Whoops! This is cargo cult behavior, and we all participate in it at some point in our lives. Businesses do it A LOT. The important thing is that we come to understand what we are doing and correct the behavior.
When you do find some broken assumption, you must be smart in how you address it. Again, make sure it’s a constraint. A little salt around the tires won’t really hurt anything, but putting salt in the gas tank certainly would. Focus the efforts on the constraints. Figure out what is wrong with the assumption and how to make it right. When you find these broken assumptions, there’s no need to blame or ridicule someone. You fixed a problem, everyone should be happy! Once you make some correction, take a look at the other assumptions in your system and see if they were affected. Decisions in the fundamental parts of the system tend to have cascading effects further down the line.
This is an iterative process. If you question an assumption this year and there’s a good reason for it, you will eventually want to revisit it, maybe next year or in 5 years. Change is perpetual and you should embrace it, not flee from it.
One of the most important concepts of The Goal is to increase throughput. Throughput is the rate at which the system generates money through sales. That is, when your company takes raw materials, processes them into a finished good, and sells it, the measured rate of that activity is your throughput. Severe emphasis on sales. Throughput is not the same as efficiency. Today, we will look at throughput vs. efficiency and how these concepts apply to IT.
Though we are focusing on throughput, we must state the descriptions of the two other measurements. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput. I list the three definitions together because the definitions are precise and interconnected. Changing even a single word in one requires the other two be adjusted as well.
Another important concept in throughput is that it measures the entire system, not a locality. Whether you work in your garage or in a giant auto plant, you can not measure throughput locally, it must be measured over the entire system. This conflicts with most companies’ measurements of local efficiency. Employers naturally want to keep all their employees busy and employees like to see their coworkers pull their own weight. Why should Jane get to twiddle her thumbs at the Fob machine when Jill is busy pushing pallets of Fob parts around the floor? Is it fair to George to watch Jeff read the newspaper while he has to investigate hundreds of parts for quality control? And shouldn’t Jane and Jeff be worried that they might be reprimanded or fired for not being efficient, or draw the ire of their coworkers?
If you’ve been paying attention in the IT world at all in the last few years, you’ve heard of this thing called DevOps. You’ve probably also heard of The Phoenix Project, an excellent DevOps novel by Gene Kim and others. Phoenix builds upon the foundation of an earlier novel, The Goal: A Process of Ongoing Improvement, by Eli Goldratt in 1984. The Goal is a revolutionary novel that changed the manufacturing world but hasn’t quite had the same effect on the rest of the world. It’s important to understand history and those that came before us. I decided to really dive in and explore our history.
If you’re curious about what I thought of this book, I’ll save you some time – buy a copy right now and start reading. By teaching in the Socratic Method, it makes high-level concepts easily relate-able by giving us real life examples of how those concepts work. Specifically, I read the 30th anniversary edition that included Standing on the Shoulders of Giants, some extra material that I think really matters. If you already have an older edition, it’s worth the $16 for this extra piece.
So what does a book about manufacturing have to do with DevOps? Nothing – and everything. Phoenix continually shows how lessons learned from the manufacturing world can help us in IT. On the other hand, IT is very different and blindly applying these lessons could actually be harmful. Thankfully, The Goal focuses on two primary components that guide us in applying our new knowledge. The novel is also the foundation of the Theory of Constraints. Let’s take a look at the two components first.
The first component of The Goal is… The Goal. Yep, it is that simple. So, what is the goal? It’s universal – the goal of any company is to make money. It doesn’t matter what industry you’re in, that’s just common sense, right? Take a look at your current job and see if you agree. The Goal attacks this assumption and challenges us to view things differently. Eli, through the character of Jonah, defines the goal in the context of a manufacturing plant.
These three fundamentals describe the goal in simple to understand terms that can be easily measured. Throughput is taking what you consume and selling it – whether it’s metal into faucets and fixtures that are sold or words and ideas into a blog post that is published. If the consumables lie around far too long, like faucets in a warehouse or a blog post that’s perpetually in draft status, your inventory costs go up instead of down. Operational expenses vary, but your personnel and other operational costs need to trend downward. These concepts are investigated in far more detail. These three concepts turn all of our assumptions on our head.
The second part of the story is about the process. Once you’ve come around to a new way of thinking, you don’t just suddenly fix everything. You have to implement change in how you’re doing things to meet the goal. Once you do, you get closer to the goal. You start to decrease the inventory that’s waiting around and throughput goes up. Those initial changes have visible immediate effects, but they may also have hidden long-term effects. Inventory may be decreased enough to deal with the current backlog, but once the backlog is out of the way, do you maintain your throughput? If the inventory is too high or low, new issues may arise. Hence, ongoing improvements.
This is addressed by measuring your throughput, inventory, and operational expenses. However, you need to measure with the goal in mind. Adhering to the previous metrics won’t suffice, as they aren’t aligned with the goal. By getting a better approximation of what is happening in a manufacturing plant, more information is available to drive the ongoing improvements.
Together, these two sections combine to give us the Theory of Constraints. The theory stipulates that there are constraints in your plant and that your effort is best focused on the constraints. Finding these bottlenecks and addressing their limitations (exploiting the constraint) will go the furthest toward increasing your throughput and decreasing inventory and operational expenses. Everything else is subordinated to elevating these constraints. Then, you repeat the process – find a constraint, exploit it, subordinate everything else, elevate it. One additional key is to prevent inertia from becoming a constraint. Don’t do things because that’s how you do them – continue to challenge your assumptions and make whatever changes are required to increase throughput, decrease inventory, and decrease operational expenses.
This bonus story in the 30th anniversary edition describes Toyota’s Lean production system (you may know it as Just-In-Time Production) and its strengths and weaknesses. It’s very short, but mostly importantly it documents that three stability requirements to implement Lean fully, and how unstable businesses can leverage certain parts of Lean to still benefit. A great example is Hitachi Tool Engineering. HTE attempted for years to implement Lean without success, because they did not enjoy the stability required to implement it. Finally, after only attempting to leverage the appropriate processes of Lean, HTE grew their profit ratio before taxes from 7.2% in 2002 to 21.9% in 2007. What company wouldn’t want to do that? Knowing when to not do something is just as important as knowing when to do something.
Obviously, The Goal struck a chord with me. I think it presents a fabulous theory on how to treat business, whether you’re in manufacturing or not. You’ll see some more posts from me in the future related to The Goal and how we can use the Theory of Constraints and the throughput/inventory/operational expenses in many ways, not just directly in our IT industry. I’ll present some of my own theories and attempt to prove them out by implementing them myself. I hope you take the time to read this book and that you will join me on this journey.
rnelson0 