Manufacturing vs. Social Media

Manufacturing and the social media are two of the greatest innovations in our human history.

In general, manufacturing and the social media are very different.  Manufacturing truly took off with the Industrial Revolution, while the social media is a recent phenomenon catalyzed by the advent of the Internet.  Manufacturing is hardware; social media is software.  Manufacturing is capital intensive, social media is not.

However, one interesting common feature about manufacturing and the social media is that they both heavily depend on scale, but for different reasons.  Manufacturing needs scale to reduce its overhead costs, while the social media needs scale to make its main function -- social -- work.  For manufacturing, without scale, individual manufactured goods would still work, but would be too expensive to make manufacturing sustainable.  For the social media, without scale, the services it provides would simply not work at all, since they all require social interactions.

TBP vs Systems Thinking

Toyota's famous problem solving technique is called the TBP, or Toyota Business Practice.  It encompasses several very practical and exhaustive steps to solve problems.  The principles behind it are very similar to the McKinsey's method (MECE).  One thing to note is: You can tell from the name that ultimately, the goal is to improve the business.

The key to TBP is step2 of the process: breaking down the problem.  Without clearly understanding the characteristics of your problem, the process will lead you to the wrong path.  After the nature of the problem and its Point of Occurrence have been identified, step4, the Root Cause Analysis (the "Whys?") will help determine the real reason causing your problem, and then step5 of Developing the countermeasures will help eliminate the root cause.

As you can see, the principle of TBP is to try to discover the real cause-and-effect relationship between the problem (effect) and root cause (cause).  In TBP, there is the belief that there is always a cause inducing an effect. 

I have to admit I am a fond admirer of this problem solving technique.  Since I've started applying it daily at work and at home, I've found that it has really provided me a very clean framework to deal with problems I encounter.  The key I found is that it forces me to not jump to fixing a problem before really understand the nature of the problem.  In addition, it has provided a very structured, concise, and easy-to-follow way of explaining my ideas to people.  

My admiration to TBP grows as I continue to be an Advisor to various QC Circle groups in the company.

However, recently, I've had several instances when I started to feel some uneasiness of the results I get from using TBP.  For example, we were troubleshooting a problem related to an oven, and found that the wear and tear from normal usage of a very long chain is the root cause of the jamming problem we were seeing.  The countermeasure developed was to replaced this chain on a regular interval.  This has eliminated the problem since.  However, 2 months later, when the department budget was reviewed, we were stunned at how much we were over-budgeted.  

Two things I've observed from this case: 1) although chain wear (cause) has been addressed to fix the jamming problem (effect),  however, the countermeasure of replacing the chain has become ANOTHER cause that has created ANOTHER effect: over-budget! 2) we did not see this actual effect immediately, i.e. there is a DELAY in the effect!

This prompted me to consider whether there is actually some limitations to TBP.  And immediately, the 2 observations above triggered me think whether Systems Thinking is a better problem solving technique than TBP, when the problem is more complex.  At least, should we be using Systems Thinking at the end of a TBP process, so that we do not get too detailed into one specific aspect of the whole problem, without zooming out to examine how a countermeasure could have an effect on the overall bigger picture of the problem?  I need to think about this more deeply!

The Standard

"What have you done to my machine!?"

The production manager was furious about the breakage of a degas rotor.  It is a piece of ceramic rudder that rotates in molten metal to purge impurities before the metal is used for casting.  My team member was called to the machine to troubleshoot why the degas rotor was not turning when auto cycle started.  What he found was there was a parameter that was different than the Standard posted.  After changing the parameter back to Standard, he wanted to test the rotor in manual outside of the molten metal.  He did not want to test it inside the molten metal because 1) he could not see it in operation, 2) if something happened, the splashing of the molten metal would dangerous.

When he started the rotor in manual, the rotor began rotating immediately at a very high speed, and within several seconds, the rotor shaft vibrated violently, and snapped.

The production manager, without fully knowing the reasoning behind this, immediately told my team member, "you should have tested the rotor INSIDE the molten metal, so that the metal will prevent the rotor from spinning too fast and breaking!"

After talking to my team member to find out about the background information, I went to talk to the production manager.  I told him, the key is this: regardless of whether he should have tested it inside or outside of the molten metal, the fact is, there is NO STANDARD to do the test.  Without such a Standard, it is unfair to the team member doing the troubleshooting to be blamed for breaking the rotor. It is management's problem to not provide the Standard to allow the team member to perform their work in confidence -- a basic requirement for JKK.

This case study shows that a Standard is not only important in allowing the team member to perform consistent work, but also as a way to handle any conflict at work in the fairest, most objective way.

It has been awhile since my last post.

Since then, there has been many changes to Toyota, my work capacity and of course, my TPS journey.

For Toyota, it has gone through the recall, the earthquake, and the Tsunami.

For me, I have been promoted from a Specialist (Engineer) to a Senior Specialist, and then to a Supervisor in Maintenance.  Because of this, I've been able to learn more about TPS from a more systems level.  The experiences have been both eye-opening, and frustrating.

I'm eager to share all these experience one by one.