Who is to blame when a defect occurs? Is it the supplier who was contracted to produce a key component or supply materials, or is it the customer organization that created the specs and produced the final product? As more companies outsource parts of production and develop closer partnerships with key suppliers, finding blame can topple the delicate balance in even the best customer-supplier relationship.
While a strong customer relationship provides long-term stability for the customer and supplier, the customer’s need for quick delivery, low cost, and high quality can challenge a supplier’s bottom line. When quality problems arise, supply chains and profits are threatened, and, too often, finger-pointing begins.
In organizations worldwide, systematic problem analysis is becoming the tool of choice for preserving customer-supplier partnerships. When a quality problem surfaces, following a systematic process provides a transparent, logical tool for finding cause and resolving issues. The same process can be used proactively to prevent future problems and plan contingencies before problems arise. The following cases illustrate the value that problem analysis delivers to customers and suppliers.
A defense industry contractor had a problem with a product that had only one supplier. This supplier was getting bad press due to issues with its administration system. The defense contractor understandably concluded that the supplier must be the cause of the problem, given the recent negative publicity.
Problem Analysis Application
Hoping to help the supplier work out the problem, the defense contractor invited a supplier team to work through the issue with his employees, using problem analysis. While the supplier agreed to attend, the team members who were sent worried that their company had already been tried and convicted as the cause of the problem. Despite two very different viewpoints and a lot of apprehension on the part of the supplier team, troubleshooters from each company were able to work together using systematic problem analysis.
The joint team quickly developed a problem statement and began gathering facts to specify what we call the “IS” — the what, where, when and extent of the problem. These facts were paired with “IS NOT” statements, each describing a fact about the what, where, when and extent of the deviation that might have existed, but did not. Comparing the IS and IS NOT of a deviation yields valuable information. For example, if the rubber gaskets in a machine have begun to wear out faster than usual, you’d want to check identical machines to see if their gaskets were also showing increased wear. If a conveyor belt keeps jamming on the first shift, you’d naturally investigate whether or not the same belt was jamming on the second and third shifts. The IS NOT facts help to narrow the search for cause, enabling the team to eliminate any causes that do not account for all the facts.
At this stage of the analysis, the group did not have all the required information; they made plans to gather the missing data. But the information they did have about “when” in the production life cycle the problem occurred was crucial. It indicated that the supplier could not possibly have caused the problem.
The customer stopped blaming the supplier and focused on finding cause. No longer on the defensive, the supplier was eager to provide suggestions about how to collect data and test ideas, and the team members soon found the data they needed to solve the problem.
The problem analysis process didn’t just provide an effective troubleshooting method; it actually strengthened the relationship between the two companies, as they developed a sense of partnership and confidence in their ability to jointly resolve any future issues.
A large consumer products company was having problems with its packaging. The company suspected that the supplier had quality problems that it was not divulging. The difficulties that the packaging problem created for the company’s line operators almost resulted in grievances being filed by their union. This prompted the company to sponsor a joint meeting between the line operators and the supplier’s production experts to address the problem. While planning the session, organizers actually worried that a fist fight would break out between the two groups.
Problem Analysis Application
The customer-supplier team carried out a standard problem analysis, beginning with a problem statement. Unexpectedly, while developing the statement, the team identified that the problem actually consisted of three, unrelated deviations. The group used problem analysis to develop detailed a detailed specification and then identify possible causes for each. While considering the possible causes, they realized that the supplier did indeed have quality problems — and so did the customer.
The customer and supplier worked together to develop ways to identify the most probable causes. The group established a schedule of meetings to report progress and keep the lines of communication open. The customer also realized that they needed to invite the packaging equipment supplier to work with them on identifying and resolving other problems.
A manufacturing company had a problem with the coating on its cabinets. When the customer reported the problem to its supplier, the supplier offered suggestions about what the customer might have done to cause the problem and how to investigate these causes. Given the supplier’s long-standing commitment to Six Sigma, the customer welcomed the advice and began to investigate these causes. None of them proved to be the cause of the coating problem.
Problem Analysis Application
The customer decided to conduct a problem analysis to find cause and invited the supplier to participate. The supplier declined, convinced that his operation could not be part of the cause. The customer’s problem-solving team developed a problem specification and uncovered several possible causes. All of the possible causes indicated that the supplier’s manufacturing process was creating the coating problem.
The customer met with the supplier to present the data and identify ways to confirm the true cause. The data made it clear to the supplier that, despite their good methodology, their process was not 100 percent in control. The supplier agreed to help the customer repair the coating problem. Both the customer and supplier agreed that problem analysis had allowed the issue be resolved despite preconceived ideas about who was responsible and without creating ill will.
Conclusion: Avoid the Blame Game
Problem Analysis focuses on gathering and organizing data to find cause, eliminating the finger-pointing that frequently occurs between customers and suppliers. Replacing the inefficient blame-game approach with the logical, systematic approach of problem analysis builds communication, strengthens the supply chain, and not only repairs—but often improves—customer-supplier relationships.
About the author:
Dan Kowalski, practice leader with Kepner-Tregoe’s North American Operations, specializes in applying process thinking to quickly learn client information, assess the environment and develop action plans to obtain results. He can be reached by e-mail to firstname.lastname@example.org.