The final step in the risk analysis process is enabling the manufacturing teams to man-age risk mitigation via standard tools. The goal of the tool is to help manufacturing teams reduce risk impact to zero. A learning curve framework was implemented to produce a theoretical risk reduction path as units produced increased. A program level version of the tool can be used to track the cost of producing an entire engine given the aggregated risk impact of the individual parts showing the theoretical re-duction in risk after each additional engine is produced. Discussed in Section 3.4, the learning curve takes a log-linear form, and in this case the exact form is displayed in the following equation,
π = πΎππ (5.3)
where,
π is the target cost at MRL 10,
πΎ is current total cost to produce a unit,
π is number of Engines produced at MRL 10, π is the learning index defined by π = πππ2πΏ, and
πΏ is the learning rate of the process with industry rate, 85% [10]
Alongside the theoretical learning curve, actual data collected from the risk dash-board can be entered into the tool to track performance against theoretical learning.
While the learning curve captures manufacturing improvements associated with rep-etition and streamlining of operations, the purpose of risk assessment analysis is to determine prioritization for implementation of risk mitigation efforts. The risk mit-igation tool allows for input of discrete action plans with forecasted step effects on engine cost. Interfacing with the risk assessment portion of the process, the miti-gation tool tracks theoretical, actual, and expected costs taking into account each teamβs individual action plan. The output allows manufacturing teams to estimate costs and compare their performance to industry standard learning.
The next chapter will discuss the results of each phase of this thesis after imple-menting the methodology laid out in this chapter.
Chapter 6
Results and Discussion
This chapter discusses the results of the three phases of this project: developing an Ops-BOM, building a risk assessment system, and implementing risk mitigation tools.
The combined result of the three phases is a risk assessment and mitigation process that can be used by anyone in the production chain. Consider performing a quanti-tative risk assessment for an entire engine program. Developing a list of critical parts can be done by generating an Ops-BOM for the program. Since the original BOM hierarchy is still embedded within the output, all parts remain accessible. Inputting the critical part-list into the risk assessment dashboard begins an automated process of collecting operations data about the subject parts, and computing a risk impact value. After reviewing aggregated risk of the program, the risk mitigation tool is implemented to track progress of program wide risk reduction benchmarked against the industry standard learning curve.
While management implements this process at a high level, manufacturing teams can be conducting their own risk assessment and mitigation efforts at a module, assembly, or even detailed part level. Centralized data sources, and quick processing time means teams can conduct several assessments in parallel. The quantitative process shown in this chapter ties together the different risk frameworks laid out in Chapter 3 to produce a new method of risk management.
6.1 Operations BOM
The purpose of this phase in the risk assessment process was to develop a method for reducing the global BOM into a manageable list of parts critical to understanding the risk of producing the engine. Chapter 5 discussed the methods by which rules for determining the Ops-BOM were chosen, and the data driving those decisions.
The Ops-BOM rules were integrated into an automated tool that receives a raw global BOM as input and outputs the list of parts comprising the Ops-BOM. Figure 6-1 shows the user interface for the Ops-BOM tool with Pratt & Whitney proprietary information omitted.
Figure 6-1: Automated tool interface for generating Ops-BOM. EBOM hierarchy is represented using collapsible and expandable rows. An assignment button automat-ically generates the right-most column indicating which parts have been selected for the BOM. "1" indicates selection while "0" indicates omission from the Ops-BOM.
Beginning on the far left of Figure 6-1 is the hierarchical grouping of all the parts in the global BOM. In this case, all hierarchies are expanded, allowing visibility into ev-ery part of the engine program. These assemblies and subassemblies can be collapsed to only display the Ops-BOM parts for ease of conducting high level assessments.
The main method of interfacing with this tool is the button by which the Ops-BOM
assignment is generated.
After engaging the button, the Ops-BOM assignment column is created on the far right, and a new sheet only containing Ops-BOM values is also created as shown in Figure 6-2.
Figure 6-2: Tabular output of Ops-BOM tool. All Ops-BOM selected parts are collated into a single display. EBOM unique IDs are carried over in the left-most column to maintain ability to drill down into sub-assemblies and details.
The Ops-BOM rules developed earlier exist within the automated spreadsheet.
The ideal user interaction is pasting a copy of the global BOM directly from central system, clicking the button to generate the Ops-BOM assignment, and receiving the Ops-BOM list in hierarchical form and simple tabular form. The whole process takes roughly 2 minutes which is a sharp decrease in required processing time. Before implementation of the above interface, BOM creation required a large amount of time as teams had to consider each part in a global BOM using qualitative judgements to sort those parts into the new BOM. Although general rules make the process slightly faster, BOM creation is often treated as an activity to be done once in the lifecycle of a program due to the amount of resources necessary. Moreover, this tool benefits other manual BOM creation processes, because it creates a more manageable starting point than beginning with the global BOM. While this tool is the result of research
Figure 6-3: Progression of reduction of BOM after implementation of each rule in Program K. After implementing all four rules, the resulting Ops-BOM is 84% smaller than the original EBOM.
into the MRL teamβs needs, the built in rules can be changed and modified as the needs of the team change.
Aside from resource benefits and reduction in processing time, the ultimate value of the Ops-BOM is to reduce a list of 8000 parts as much as possible, without com-promising visibility of overall health of the engine. Therefore, the metric of usefulness is the amount of reduction from the original BOM, assuming that research has been conducted to verify the BOM has not been over-pruned.
Figures 6-3 and 6-4 show part reductions as percentages of the total number of parts for Programs K and F, respectively plotted against progression of rule imple-mentation. For reference, the Ops-BOM rules are:
0. Start with full EBOM
1. Remove all parts that do not roll up to NMA (non-machined assemblies) 2. Remove all NMAs
3. Remove all parts of type: AN, AS, MS, ST, NAS, and DS 4. Remove all duplicate part numbers
The Ops-BOM tool reduced the BOM size by 86% in Program K and 88% in Program F. Since the Ops-BOM process is specifically designed to target assembly-ready parts, the reduction in BOM size does not reduce visibility into the BOM.
Achieving such a large reduction with only four rules kept this phase of the risk as-sessment process easy to use and easily transferable between teams in the Operations organization.