Prasanna Pokhrel

Pareto principle is an effective root cause analysis (RCA) tool which help us separate the vital few factors from the trivial many without having to conduct deep research into each of causes of key factors, however, if not applied well, we may run into oversimplification of critical factors which may not resolve the issues or take us in a different direction from the real factors which actually affect the business outcomes. There are some inherent limitations of Pareto principle and if these are not taken into account wrong conclusions may be drawn while applying the principle: Historical Data: Based on historical data & does not account for the changed dynamics of the present. If for example 20% of the customers currently contribute to 80% of revenue, incorrectly applied Pareto conclusions may lead the business to ignore the others which may have greater untapped revenue potential. Does not take into account the future possibilities : Pareto Principle is descriptive & not prescriptive, so it will be a mistake to use it for forecasting future patterns. May not apply to all business phenomena: In some cases it is entirely possible to have evenly distributed causal factors or may have only one significant cause with others being more or less equally distributed. e.g. 80% of system downtime may not be directly linked to in 20% of the computers. Based on quantitative data only & ignores human factors which may have considerable influence on the outcomes. E.g. in a ten member team, while there may be significant productivity variations, it is unlikely that 2 people will contribute to 80% of the work. Data independence: While we take care to have mutually exclusive & collectively exhaustive (MECE)data as far as possible, interrelationships between the causal factors may not be ruled out as in real life, they may not be totally independent of each other. Pareto works well on a large data sample & may not apply well in those with few samples & causal factors Short period data may be lopsided & may not reflect the true behavior of the process when observed for a long period & this may lead to incorrect conclusions Very long period data may not account for changes in the nature or attributes of the causal factors over the time period. E.g. while looking at response times, the fact that information processing system may have undergone key upgrades and changes over time may be overlooked. Data collected from unstable processes or outlier events may lead us to draw incorrect conclusions 80 & 20 do not necessarily equal to 100: the 80% & 20% do not refer to the same elements & hence do not necessarily total to 100%. The 80% represents the result / outcome or Y whereas 20% represents the causal factor/ input or X. It is not correct to take them together for making a 100% as may be mistakenly done. Mistaking the 20% drivers for root causes: The 20 % causal factors are only the categories that contribute to the 80% of out outcome, these are NOT the root causes, which will need to be understood further by conducting further analysis. The mistake here is to stop at the vital few identified & not go deep into the looking at the root causes. Not reviewing the "Others" category: Typically we tend t ignore the "others" category while looking at Pareto, however, if this category has key drivers, it would not be a wise decision to ignore them completely as there could be significant business implications , especially if business environment & other factors change.

Some of the common challenges in conducting severity rating in PFMEA are listed below along with some thoughts on how these could be mitigated. 1. Understanding the ordinal rating scale: Interpretation of ordinal rating scale may be different from the interpretation of ratio scales and there might be the risk of drawing incorrect assumption. For example if the rating scale gives 3 likely and 6 very likely , in the rating, the impact may be significantly different from that of 2 & 4 and not exactly double the rate (as is the ratio in both the cases). The range, however, may be considered as such if the rating scale is not well explained. The solution is to have detailed discussion on the assessment mechanism including the rating scale. 2. Different rating scale for different industry: The severity rating scale may have very different implications for example, the rating scale used for healthcare industry will have very different scaling parameters and levels vs insurance industry or automobile industry. This challenge can be addressed by working with the actual team members & the respective functional leaders to design a rating scale which is relevant to the organization. 3. Difference in interpretations: Even in case of the same rating scale being provided, there could be difference in interpretation of the severity & impact of a possible risk based upon the personal experiences of the person conducting the assessment. The solution in such a situation is to have calibration meetings to ensure that every one is on the same page. 4. Cognitive Biases: The challenge in using rating scales and not statistical data in arriving at severity rating is that it may be subject to cognitive biases as follows: a. Only takes in to account "known -unknowns" & does not plan and design suitable response mechanisms for black swan events & "Unknown-Unknowns) b. Availability : People will typically ignore statistical evidence and base their estimates on their memories, which favor the most recent, emotional and unusual events which have a significant impact on them. c. Gambler’s Fallacy: People make the assumption that individual random events are influenced by previous random events which might be spurious correlations and may not have causal relationships. d. Optimism bias: People overestimate the probability that positive events will occur for them, in comparison with the probability that these events will occur for other people. e. Confirmation bias: People seek to confirm their preconceived notions while gathering information or deriving conclusions. f. Majority: People may go with the assessment of majority to conform with the group at the cost of their objective opinion which may be truer representation but different from the group opinion. g. Self-serving bias: People have a propensity to assign to themselves more responsibility for successes than failures. h. Anchoring: People tend to base their estimates on previously derived/ used quantities, even when the two quantities are not related. i. Overconfidence: People consistently overestimate the certainty of their forecasts. j. Inconsistency: When asked to evaluate the same item on separate occasions, people tend to provide different estimates, despite the fact that the information has not changed. Solution in this case is to screen out whether the ratings have been influenced by these biases and inform the participants in advance to consider whether the ratings may have been influenced by such biases. Other mitigation measures could be blind peer rating or benchmark comparison with industry ratings for similar processes. 5. Interdependence between causal factors and failure modes: FMEA assumes that each risk is an independent event, whereas there may be a high degree of interdependence between factors which could influence risk rating significantly. Understanding and articulating such interrelationship could be challenging & not considering such impact could mean that the assessment is not representative of the possible risks & the resulting impacts. The way to mitigate this is to have a detailed discussion with all the relevant stakeholders & the process expert in a well-designed structure to ensure that all the risk and their interrelationships are well understood and documented. 6. Challenge in considering the effect on both the customer or the process (assembly/ manufacturing unit). As against DFMEA(Design FMEA) where we look at the effects on the customer , in process FMEA, we will need to consider the impact & hence the severity rating of the failure mode if it impacts both the process & the customers. This is because, the impact of the failure mode in this case will mean the impact on the process or the customer in both the cases. This leads to more complications in having to consider multiple scenarios. This challenge can be mitigated by taking the higher of the severity rating of the failure modes for other the process or the customer as the severity rating for the causal factor/ failure mode. 7. Challenge in deconstructing the impact of Root cause vs. assessing failure mode. Though there is a perspective that in some cases Root Cause and Failure Modes can be used interchangeably, however, if we drill down further, it is evident that root cause analysis is typically conducted post facto (after the event) whereas Failure modes identification happens proactively and will take into account various other factors apart from the proximate cause. The challenge is to ensure that this understanding percolates to the team creating the FMEA document. 8. Challenge in ensuring the risk assessment as an ongoing process vs as a single time activity - Risk assessment (including identification & severity assessment) has to be an ongoing process & not a single point in time activity ( as the severity and impact may show material change in cases where there have been significant changes in either internal or external drivers, process dynamics or in key the environmental factors). The challenge is ensure that the rigor of assessment is maintained & updated with any relevant changes. The solution in this case is to have a monitoring / governance mechanism which will ensure that FMEA is kept as a live document with relevant updates to ensure correct risk rating. 9. Challenge in considering the impact due to timescale: E.g. the impact of a risk manifesting immediately may be significantly different from that which may manifest after some time. The solution would be to conduct time-scale analysis of such risk factors to take into consideration the impacts of recent events and see whether the severity rating could change in such cases.

Rules to determine how much detail to be used in process mapping: Purpose : Identify the purpose as to why the As- Is process map is being created and at what stage of the DMAIC project is it being created This will help identify which type of map to use : Presenting a Macro View : If we are looking to understand the overall picture or the end to end wing span of process and what it does at high level without getting into details of how the steps are being performed we will select L1 process maps Presenting a Process level View : If we are looking at the end to end process map & identifying the flow of goods, inventory, the cycle time & the process times , in order to depict VA/ NVA steps, throughput rates along with the bottlenecks we will use Value Stream Maps Presenting a Micro View: If we are trying to understand how the process is being performed, what sub processes are involved, which different functions, departments, roles are involved, how are these related, what are the hand offs between these processes & departments, what is the sequence & flow in which the steps are mapped in the process in order to identify any failures , wastes and also depict decisions and alternate actions being performed we will use swim lane diagrams (L-3 process maps) Presenting a step level view: If even more detailed understanding of individual process steps are required including what are the activities within each step of the process are being performed (L-4/ 5) Intended audience : If higher authorities, organizational leaders are using for approval & decision making, L-2/ L-2 process maps should be used highlighting the key observations, defects and possible areas of improvement typically VSM will be the best option to use in these situations (process view) If tactical members (supervisors/ SMEs) are using the map then L-3 process maps should be used as they will need to have clear understanding of what is being done (activity / transactional view) If the end users / doers are using the map then even more detailed process maps may be required , especially if there are no existing SOPs or step level instructions. In such cases the level of detail could even be at L-4 / L-5 (Screen/click level) Rule of thumb: Although there are no official guidelines relating the level of detail to be added in a process map, following could be used. Process / activity , activity & end should be clearly depicted and visible and the activities should not be left open ended Process boundaries should be clearly depicted Related upstream, downstream processes, hand-offs ( for L-2 and down) decision points should be clearly visible Standard protocol should be used for direction, flows, symbols & connectors The L-1 process map should Legibly fit in a A-4 sheet Should have no more than 5-7 steps and no decision point Should give the overall view of the process with input, process & output clearly defined (without getting into the steps) along with any key indicators or metrics L-2 process map should: Legibly fit in a A-4 sheet Should have 15-20 steps Should give the overall view of the process with input, process & output of different p clearly defined with some dependencies In case of VSMs, the details should mention the customer, suppliers, volume , key processes, Information and material flow. Data boxes should typically be filled with the details of the Cycle Time/ Lead time/TAKT time, Throughput, Inventory, accuracy levels, set up times & should be mentioned In case of L-3 & down it may not be possible to fit all the relevant steps In a single view & we could use the right connectors and multiple pages to fully describe the process How can you gauge whether you are including too much or too little detail? If too much detail is being used, it will typically create a busy/ crowded process map and the steps will look complicated for the level of detailing required. For such cases the solution will be to go back & re-look at the purpose and the audience. If unavoidable, then we should drill the map down to the next level of detail. In case of too little detail, if the map does not give the intended answer to the why ( for L-1) , what for L2 process maps and how the process is being performed ( L-3 & Downwards), then the details will need to be enhanced.