The Analyze Phase
You have defined the problem and measured the baseline. Now comes the question that determines whether your improvement effort will succeed or fail: why is the process producing defects?
The Analyze phase is about moving from symptoms to root causes. It is tempting to act on the first plausible explanation — "the system is old," "we need more staff," "the vendor is slow" — but these are often surface-level observations, not true root causes. The tools in this module help you dig deeper, structure your thinking, and ultimately verify your hypotheses with data before committing to solutions.
A root cause is the fundamental reason a problem exists. If you fix the root cause, the problem goes away. If you only address symptoms, the problem returns.
Fishbone (Ishikawa) Diagrams
The Fishbone diagram — also called an Ishikawa diagram or cause-and-effect diagram — is the most widely used brainstorming tool in Six Sigma. It provides a structured way to organize potential causes of a problem into logical categories, ensuring the team considers all possible contributing factors rather than fixating on the most obvious ones.
The traditional 6M categories, adapted for banking operations, are:
- Manpower (People) — Training gaps, staff turnover, inconsistent skill levels, cognitive overload from high case volumes, over-reliance on tribal knowledge held by a few experienced analysts.
- Methods (Process) — Manual steps that should be automated, excessive handoffs between teams, unclear or outdated standard operating procedures, lack of clear escalation paths.
- Machines (Systems) — Legacy technology platforms, lack of integration between systems (requiring manual data re-entry), batch processing delays, system downtime during critical windows.
- Materials (Data/Inputs) — Poor data quality from upstream feeds, missing reference data, inconsistent formats across counterparties, incomplete documentation from clients.
- Measurements — Tracking the wrong KPIs, metrics that incentivize the wrong behaviour (e.g., measuring case closure volume instead of quality), lack of real-time visibility into process performance.
- Mother Nature (Environment) — Regulatory changes that alter requirements mid-process, market volatility driving transaction spikes, time zone differences in global operations, end-of-quarter volume surges.
Banking Example: High False Positive Rate in Transaction Monitoring
Let us build a Fishbone diagram for a common AML operations problem — the transaction monitoring system generates too many false positives, overwhelming the investigations team.
Under People: Analysts are not trained on the latest typologies. High turnover means new hires lack the experience to close alerts efficiently.
Under Process: Every alert goes through the same three-level review regardless of risk, creating a bottleneck. There is no triage mechanism to fast-track obviously benign alerts.
Under Systems: The transaction monitoring platform uses static, rule-based thresholds that have not been recalibrated since implementation. The system cannot dynamically weight risk based on customer behaviour history.
Under Data: Customer profile data is incomplete — missing industry codes, outdated expected transaction volumes, and inconsistent country-of-risk mapping. The system flags normal activity as suspicious because it lacks the context to assess it.
Under Measurements: The team measures "alerts cleared per day" rather than "quality of SAR decisions," incentivizing speed over accuracy and discouraging thorough investigation.
Under Environment: Recent regulatory enforcement actions have made the compliance leadership risk-averse, resulting in deliberately over-sensitive alert thresholds ("we would rather over-report than miss something").
The Fishbone diagram does not tell you which cause is the most important — it ensures you have a comprehensive inventory of potential causes to investigate.
The 5 Whys
The 5 Whys technique is deceptively simple: start with the problem and repeatedly ask "why" until you reach a root cause. The number five is a guideline, not a rule — some root causes emerge after three iterations, others require seven.
The key discipline is to follow one causal chain at a time and resist the urge to branch off into multiple explanations simultaneously. Here is a banking example:
Problem: SARs (Suspicious Activity Reports) are taking too long to file.
- Why? Because analysts spend too much time investigating each alert before deciding whether to file.
- Why? Because the majority of alerts are false positives, and analysts must still perform a full investigation on each one.
- Why? Because the detection rules generate alerts based on static dollar thresholds that do not account for customer behaviour.
- Why? Because the transaction monitoring rules have not been recalibrated since the system was implemented in 2019.
- Why? Because there is no defined process or schedule for periodic rule tuning, and no one owns the responsibility.
Root Cause: The bank lacks a governance process for periodic recalibration of transaction monitoring rules.
Notice how the root cause is fundamentally different from the original symptom. Hiring more analysts (addressing the symptom) would be expensive and would not solve the underlying problem. Establishing a rule governance process (addressing the root cause) would reduce false positive volume, which in turn reduces investigation time, which in turn accelerates SAR filing.
Pareto Analysis
The Pareto principle (also known as the 80/20 rule) states that roughly 80% of effects come from 20% of causes. In process improvement, this means a small number of root causes typically drive the majority of your defects.
A Pareto chart is a bar chart that ranks causes by frequency (or impact) in descending order, with a cumulative percentage line overlaid. It answers the critical question: where should we focus our effort for maximum impact?
Banking Example: Reconciliation Break Types
Suppose the Measure phase identified 4,200 reconciliation breaks over 6 months, classified into 15 break categories. A Pareto analysis reveals:
- Pricing discrepancy — 1,428 breaks (34.0%)
- Missing trade / unmatched item — 1,092 breaks (26.0%)
- Timing difference (settlement date mismatch) — 924 breaks (22.0%)
- Currency conversion error — 294 breaks (7.0%)
- Incorrect counterparty — 168 breaks (4.0%)
- All other categories combined — 294 breaks (7.0%)
The top three break types account for 82% of all breaks. This is the "vital few." If the project team can reduce pricing discrepancies, missing trades, and timing differences, they will eliminate the vast majority of reconciliation effort — without needing to address all 15 categories.
This focus is essential in banking, where resources are finite and improvement projects must demonstrate clear return on investment. A Pareto chart gives you the evidence to justify targeted action.
Data-Driven Validation
Brainstorming tools like the Fishbone and 5 Whys generate hypotheses about root causes. But hypotheses are not facts. Before moving to the Improve phase, you must validate your suspected root causes with data.
At the Yellow Belt level, validation focuses on visual and descriptive analysis rather than advanced statistics:
- Stratification — Split your data by suspected cause and compare. Do breaks take longer to resolve when assigned to junior analysts versus senior analysts? Does the false positive rate differ by customer segment? If the data shows a clear pattern, the hypothesis gains strength.
- Scatter plots — Plot two variables against each other to see if a relationship exists. For example, plot alert investigation time (Y-axis) against analyst tenure in months (X-axis). If you see a clear downward trend (more experienced analysts are faster), you have evidence supporting the "training gap" hypothesis.
- Time series analysis — Plot your metric over time. Did the defect rate spike after a specific system change, staff rotation, or regulatory update? Temporal correlation can be powerful evidence.
- Comparison charts — Bar charts or box plots comparing performance across categories (teams, branches, products, time periods). If one branch consistently outperforms others, understanding what they do differently can reveal both root causes and potential solutions.
The standard of proof at this stage is not academic rigour — it is sufficient evidence to justify investing in a solution. If your Fishbone identified "outdated monitoring rules" as a potential root cause, and your data shows that 73% of false positives are triggered by just 4 rules that have not been updated in 5 years, that is strong enough validation to act.
In the next module, we will move to the Improve phase, where validated root causes are translated into tested, implementable solutions.