Quality Management Systems for Enhanced Treaceability
Issues appear during the production process and once the issue gets assigned to a problem solver, he or she goes through the process of finding the root cause(s), finding solution(s), validating the solution(s), implementing a solution and then getting feedback from the field. However, this is not a discussion on the problem solving process, but how the information flows from the person discovering the issues to the problem solver. In an ideal world, we would see information flow as shown below:
In this scenario, the problem flows from the issue identifier either directly or through a coordinator to the Problem Solver, who works through the problem solving process and provides the solution. However, many problems do not pass directly from the issue identifier directly to the problem solver and the situation is often acerbated during a product launch because deadlines created by corporate announcements of the launch of the new product. There is often an urgency to work through the problem solving process created by the deadlines.
The key to a successful launch often boils down to getting the problem solving process closer to the ideal state described, by solving issues early and quickly
Most companies are required to freshen up their product lines every few to keep up with the competition resulting in cosmetic changes to completely new products to major overhauls. During the new product design phase, the manufacturer or the software developer is trying to out-think the competition in terms of what they might offer in their next generation product and incorporate all the features that can be added to the product to make the customer find the new offering alluring.. The manufacturers often pay attention to the features currently offered by the competition, teardowns of the competitors product, problems with the current product though surveys and warranty work, anticipating what features the next generation competitor product might offer in designing the next generation product. Many problems are identified and resolved before going into the prototype manufacturing stage.
The problems and issues start cropping when the prototype manufacturing begins and the testing of the product and its features begin. In a perfect world, the product design will have all the characteristics expected by the customer and the components are built and they go together as expected and they go through the testing cycles and the production lines can rapidly move into production at full line rates and the products ship to market. But the reality is that a number of problems are identified with the design, the supplier quality and process issues and these have to be resolved in a “limited timeframe” to enable success in the market place.
In the real world and typically in large companies, often the process of getting a problem in the hands of the problem solver is often bogged down by an information flow structure that often looks like the picture shown below:
The information often flows directly to the manager of the issue identifier instead of the coordinator who has to get the issue assigned to the problem solver, based on the manager requesting a report out to him and the information keeps going the ladder in the organization where the issue was identified through the director, executive director and even to the VP. The problem at some stage gets transferred over to the problem solving organization to their respective peers and then it take the reverse journey to finally get to the problem solvers, resulting in considerable lost time to solve the problem. So a build problem in the body shop results in the problem going up the ladder in the body shop organization while the problem does not reach the stamping manufacturer organization and the problem solvers are not working on the problem at hand.
The consequences of the circuitous path are often more serious than the lost time in problem solving as:
Defeats the purpose of the launch process and the desire to solve problems earlier—when problems take a longer path than desired the time wasted cannot be recovered.
Causes problems that moved up and down priority scale higher than a real problem, that must be solved prior to launching the product. For e.g., A minor surface defect on sheet metal that moved up the list, since it was escalated to the VPs causing the issue to be on their radar.
Causes problems beyond the scope of the technical specifications to be added to the list that cannot be achieved, causing considerable waste of resources attempting to resolve problems beyond the scope of the original product—e.g. a particular road condition in China not comprehended causing the transmission to overheat.
Last but not the least, the cost of the launch increases significantly since certain allocated resources have higher priority and need to be addressed.
While management definitely plays a role in prioritizing work when multiple priorities occur by allocating additional resources or defining the sequence of the problem solving process, more often than not, the more direct the path of the problem identifier to the problem solver, greater efficiencies are achieved in creating a successful launch. During a launch process and the prototype build, problems are occurring all over the floor and if the system is dependent on flowing the information from the people taking notes, carrying the issue into a spreadsheet, followed by a distribution of the problem through the process, results in delays in problem solving and added cost and in many cases retiming the launch. Most information systems are easily configurable for systems in steady state, when production processes are stable and in control, but most tracking systems are often not configured to handle the vagaries of launch, where significantly greater number of problems that are often not well defined. The key to a successful launch often boils down to getting the problem solving process closer to the ideal state described, by solving issues early and quickly, so the issue identifier communicates directly to the problem solver, instead of taking the issue through a path that delays the problem resolution.