In my posting today, we are privileged to have Bruce Nelson writing for us. In this posting Bruce discusses the concept of change….and maybe more correctly, necessary change.
Is Change Really Necessary?
I guess the honest answer to that question is: “it depends.” It depends if the change you are making is really necessary, or are you just changing things because you can? It depends if the change is associated with a systems constraint, or is the change a non-constraint?
Let’s talk about “unnecessary change” first. Sometimes change just for the sake of change can have destructive outcomes no matter how good the intentions are. Unnecessary change is most commonly associated with organizations that are working in isolation of each other with no real “focus” on the overall goal of the company. Each individual organization has determined some pre-defined goal(s) that they want to accomplish and they set out to do so. Sometimes they do this without any real understanding of the overall systems affects that the proposed change might have on another organization. As an example, suppose a sales organization wants to increase sales without a concrete understanding of the internal capacity of the manufacturing organization. More sales without the necessary capacity will be very destructive to the manufacturing organization. There will be increased late orders, longer lead times and unhappy customers. So, an improvement in one organization can have a very destructive effect on another organization. What started out with good intentions quickly became a big problem for the entire company.
Now let’s talk about necessary change. Any change that can move the company closer to its overall goal (make money) is probably a very good change to make. Any recommended changes brought forward can be evaluated with a quick and effective litmus test. Ask yourself, “If I make this change will throughput (T) go up?” You can also ask “Will operating expense (OE) stay the same, or go down?” Or, “Will inventory/investment stay the same or go down?” If the answer to any of these questions is “NO”, then it is probably not a good or necessary change make and should be shelved until another time.
However, making necessary changes does require some accurate information. First, you must know where the systems constraint currently resides. Second, is accurate (probable) information about where the constraint will move next? If the system constraint limits the system output, then any improvement of the constraint will improve throughput through the system. The first litmus test has been passed! If you spend your time and resources “focused” on anything except the constraint, you will miss the opportunity for maximum “leverage.”
If you also have a good idea where the constraint will move next, then the necessary planning can be undertaken to deal with the next constraint. This sequence of finding and fixing is exactly the same as the “Piping Diagram” that has been referred to so many times on this blog. Find and fix the first constraint and move to the next one. This sequence allows you to make the necessary improvement because you “must” and not just because you “can.”
I want to thank Bruce for writing this thought provoking piece. In our next posting Bruce will write a follow-up segment on change buy-in.