Practitioners sometimes encounter potential sponsors and Champions who seem not to be able to point to the real “pain” in their organization. Inputs are either very general (“boil the ocean”-type projects) or fuzzy, leaving the final project definition to the Black Belt – and risking missing the real issue intended by the Champion. This results in assignments to “look into this area” and “figure out what is really the problem,” instead of a clear cut, data- and finance-driven description that can quickly move from recognize to DMAIC (Define, Measure, Analyze, Improve, Control). During the Recognize and Define phases of potential projects, the application of another method, theory of constraints (TOC), provides useful insights and helps to sort out project targets. TOC tools – such as bottleneck analysis and current reality trees – used in conjunction with Lean Six Sigma can help to better identify problem areas.
Two TOC Tools
TOC and various derived tools, such as reality trees, critical chain and conflict resolution strategies, are based on the work of E.M Goldratt. Besides standing on its own merit, TOC offers two key tools to cut through the fuzziness of problem statements encountered by Lean Six Sigma practitioners:
- Bottleneck analysis, used to find the core issue in a well established process environment
- Current reality tree, used to sort a set of symptoms and work out the core issues behind a perceived reality
Both tools can be driven by a practitioner in the Recognize phase (no major team or resources required) and will help the Champion and sponsor to sort out the pains and issues with a process. The presentation of a bottleneck analysis can lead to a more productive discussion with the deciders and drive the selection of relevant improvement projects. Bottleneck Analysis This tool is used to find the one, main performance-impacting bottleneck in a system or process. While this seems simplistic in manufacturing-oriented setups, finding the bottleneck in a transactional environment can be challenging. TOC bases the bottleneck on money-based performance indicators (throughput, inventory and operational cost). In transactional processes those measurements may not be obvious or easy to locate. A short example is provided later in this article to show the complexity of identifying the relevant operational parameters for a transactional process. Current Reality Tree A current reality tree is a construct based on a list of undesired effects (UDE) or symptoms of a system or process. The tree must be constructed to connect all UDEs through a logical sequence of ‘If … Then’ dependencies using all symptoms and intermediate steps to get to a fully connected system. This is a complex task, but can be accomplished by a practitioner without a large drain on the organization’s resources. Once the tree is established, it will highlight key causes for the UDEs described. A sample tree will be shown later in this article.
TOC and Financial Indicators
A critical requirement for looking a process or system from a TOC perspective is to establish the key operational parameters. Those parameters are:
- Throughput – Earnings through actual sales
- Inventory – Investments in purchasing things that an organization intends to sell
- Operational cost – Money spent on the process to make the product
Experienced Lean practitioners will bring up the point that the typical Lean project also looks for bottlenecks and explores takt time. While this is true with the flow at shop floor level, typically high-level systems and performance indicators (money) are not explored. The focus on money in all three TOC indicators sets it apart from Lean techniques, helping practitioners to see the whole system and avoid local optimizations that would not benefit the overall process.
Case Study: Semiconductor Chip Design
Improvements made to a semiconductor chip design illustrate this use of TOC. In this case, designers were not aware of all the steps involved in the process. Therefore, to analyze the product design cycle it was necessary to develop a detailed process map, including added work buffers to highlight process steps where work might accumulate. As is often the case with transactional processes in design, all inventory is essentially a result of virtual work packages based on designers’ ideas and the resulting circuits. Therefore, the inventory is the actual headcount cost and resources used to generate the basic outline of the product implementation. Circuit optimization and fine-tuning is considered operational cost. Establishing and following through on this separation proved crucial for the bottleneck analysis. In this case parts sold to the customer, or at least successful design “wins,” could be counted as throughput. An internal product qualification was not a relevant measure for throughput. This is contrary to the usual key performance indicators used for a design organization. Sorting out the inventory, operational cost and throughput and providing measurements and data proved difficult and time consuming. However, going through the full exercise provided insight into the processes and a much better handle on where to start an improvement project.
Mapping the Process
After practitioners conducted the designer interviews, they mapped the steps for chip design (Figure 1). The map showed the detailed flow of work as a specification is transformed by a large team of engineers into a fully assembled virtual chip. This type of design is based on semi-custom methods requiring substantial hands-on work by a multitude of experts.
As shown in Figure 1, incoming money from the sale of the manufactured chip is being split into inventory (headcount and infrastructure to generate initial design schematic) and operational expenses. The latter are mainly encountered during physical layout of the chip and the simulation and adaptation of the blocks. Breaking down the process flow into the lowest level of chip design shows the work buffers (Figure 2). Those were added to reflect the flow of work packages through the design, layout and verification steps.
The detailed analysis showed work piling up in front of design as well as layout; however, the designer has to work on multiple implementations of the same design, generating inventory in the initial design phase while encountering operational cost during the optimization and simulation steps. Design was identified as a bottleneck, contrary to the common organizational wisdom where layout was considered the bottleneck. This helped steer Lean Six Sigma projects toward the design stage. To demonstrate the use of current reality trees, the following example is based on typical symptoms of chip design projects. Six exemplary symptoms were collected as undesired outcomes of projects (Table 1).
|Table 1: Undesired Effects for Example Chip Design Process
|Chip designs often finish late with little early warning about the delay. Problems always seem to come up late.
|Designers often are overloaded and work late hours and weekends on a regular basis.
|There seems to be infighting between the electrical/circuit design and the physical implementation (layout).
|IT resources (CPU, disc space, licenses) seem to slow down the project progress.
|Resources from finished projects often are not released (or released too slowly) for the follower projects, thus delaying the start.
|Critical technical know how seems to be tied to certain experts; it seems difficult to manage progress in cases of overload or sudden absences.
The current reality tree in Figure 3 connects all UDEs. Accomplishing this required the help of various injections, which made the logical “if … then” dependencies work.
The tree highlights a few levers that could be flipped to break the negative reinforcement:
- Change the project planning to include a buffer for late availability of resources and introduce a review for potential resource requirements (critical chain planning)
- Find a creative way around the expert bottlenecks (e.g., look at the bottleneck analysis from above)
Based on this (rather incomplete) list of UDEs and the resulting current reality tree, a project to analyze the planning process at project start as well as the short-term team planning (expert availability vs. issues in queue) was proposed. Although setting up a current reality tree may involve a few iterations to get the logic chain crisp and comprehensive, the tree provides clarity and results in an accelerated pre-project definition phase with the process owners and the sponsor to provide a decision guide for the Champion.
Finding Real Pains
Lean Six Sigma excels at process optimization and leads to comprehensive data-based solutions. Projects can be run methodically and smoothly once they have been kicked-off in the right direction and with the right goal. However, finding the right direction and describing the correct goal for projects can be difficult, in particular with transactional processes and systems, where causes and issues are often hard to pin-point. Theory of Constraints provides a creative approach to find and define the real pain ailing an organization, and enables a better alignment of Lean Six Sigma projects and resources. This leads to a clear focus during the Define phase and ensures that the project will be started in the right direction and with the right ultimate goal to address the core issues of the problem.