{"id":24447,"date":"2015-09-05T14:22:00","date_gmt":"2015-09-05T14:22:00","guid":{"rendered":"https:\/\/kepner-tregoe.com\/enhanced-troubleshooting-kt-and-six-sigma\/"},"modified":"2025-07-10T14:39:18","modified_gmt":"2025-07-10T14:39:18","slug":"enhanced-troubleshooting-kt-and-six-sigma","status":"publish","type":"post","link":"https:\/\/kepner-tregoe.com\/zh-hans\/blogs\/enhanced-troubleshooting-kt-and-six-sigma\/","title":{"rendered":"Enhanced Troubleshooting: KT and Six Sigma"},"content":{"rendered":"

KT and Six Sigma \u2013 Complementary or Competitive?<\/h4>\n

We often run into discussions with clients about whether the Kepner-Tregoe problem analysis process fits in with the Six Sigma<\/a> work they are doing. Their questions are usually posed to cast the two techniques as being in competition with one another; it\u2019s almost as if they feel they only have the capacity to use one tool, so which one should it be?<\/p>\n

In our mind, this is a false contrast. KT Problem Analysis and Six Sigma tools like Ishikawa Fishbone Diagrams<\/a> were designed to accomplish entirely different ends. Six Sigma is about \u201cCommon Cause\u201d problems, where factors inherent to the product or the process cause deviations over time. Think of any machine\u2014all machines produce heat and all machines vibrate. And over time, that heat will eventually dry out and crack the seals and gaskets, and the vibration will eventually work all the bolts loose. This is just in the nature of things\u2014inherent variation. Six Sigma attempts to isolate those inherent sources of variation, and to reduce them.<\/p>\n

KT Problem Analysis was designed to attack \u201cSpecial Cause\u201d problems, in which something has changed or is different and causes a problem: a change in settings; a new operator; a difference in raw material suppliers; a sudden anomaly in environmental conditions\u2014any or all of these, separately or in combination, can cause problems.<\/p>\n

This shows up in the first question KT uses to qualify whether a particular problem fits the KT process: \u201cDo we have a deviation?\u201d If the answer is, \u201cNo, it\u2019s always been this way,\u201d then you are probably talking about Common Cause.<\/p>\n

Even within Special Cause problems, the Ishikawa technique can work brilliantly, if used correctly and in the proper sequence. If mis-used, blending them together can be a disaster.<\/p>\n

For example, I recently visited a client who tried to marry the two together, intuitively, and did it precisely wrong. They had a group of Subject Matter Experts who had not been trained in KT and were somewhat resistant to it\u2014they wanted to do Fishbones. Fishbones were intuitive, they relied on experience and knowledge, not on specific data. They gave the Experts a chance to use their expertise. The company also had KT-trained facilitators who wanted to use KT\u2019s Is \/ Is Not technique, where we begin by specifying the symptoms of the problem. Their compromise was to start by doing Fishbones, and then doing an Is \/ Is Not based on the Fishbone variables they found most persuasive.<\/p>\n

You can see what\u2019s wrong with this picture \u2013 they were starting with causes and then looking at symptoms. It was precisely backwards, a closed loop system. The result was that all the causes they identified, problem after problem, were \u201cthe usual suspects,\u201d vague culprits like \u201cinadequate cleaning procedures,\u201d or \u201cbelow standard inspection vigilance,\u201d or the dreaded \u201coperator error.\u201d They threw some procedural fixes at the problems . . . and they recurred. It had gotten so bad by the time KT arrived on the scene that they were ready for some additional help.<\/p>\n

Within Special Cause problems we prefer to use Ishikawa diagrams after the symptoms of the problem have been specified. We already know which Batches were affected, and which were not, which clients complained and which did not, and maybe even which days of the week the problematic product was made on, and which days it was not. At this point, we\u2019re asking what about that product, that deviation, that time, that location, that amount is distinctive, odd, curious, or different. And we often use the Ishikawa categories as prompts to elicit this data:<\/p>\n

What is unique about Model 200 in terms of crewing?<\/p>\n