01 — Theory
From a diagram to findings someone will act on
Five questions separate an analysis that gets decided on from one that gets filed.
Which lenses do you use: pain points, controls, compliance, figures, systems?
All of them, one at a time, on every step. The pain-point lens asks what goes wrong at this step, why, and what it costs. The control lens asks where a check happens, who owns it and what evidence it leaves. The compliance lens asks which requirement the step serves and whether the evidence would satisfy whoever asks for it; as general orientation, not legal advice. The quantitative lens asks how long the step takes, how long the case waits before it, how often it happens and how much of it a system already does. The systems lens asks which system each step touches and where data is typed twice. Reading step by step is what makes the lenses useful: a finding that points to a step can be acted on, a finding about "the process" cannot. The process documentation page describes what each analysis per step contains.
How do you get from a symptom to a root cause?
Follow the case backwards through the diagram. The symptom is where the pain is felt, usually at the end of a chain: the customer who waits, the report that is late. The cause is upstream, at the step where the time went or the information was lost, and the diagram shows the path between the two. Ask "why" at each step on that path until the answer is a rule, a priority or a missing piece of information, and stop there; those can be changed. "People are slow" is never a root cause. Check the cause against a second case: if the same path explains it, you have a cause; if not, you have two.
How do you put numbers on a process when the data is poor?
Most processes have no clean timestamps, and waiting for the perfect extract is a way of never analysing. Ask the people who run each step for three estimates: how long the step itself takes, how long a case typically waits before it, and how often the step happens in a month. Write them on the step, mark them as estimates with the name of the person who gave them, and let the diagram add them up along the path. The sum is wrong in detail and right in proportion, which is what a decision needs: it shows which step carries the waiting and which carries the work. Where a system does have a timestamp, use it to check the estimate, not to replace the conversation.
How do you rank findings, and who should do the ranking?
Rate every finding on three things: the effect on what the project set out to improve, the effort to fix it, and the risk of changing it, with controls and anything a regulator looks at rated high by default. Then rank by effect first, effort second, and let risk decide what gets a second look rather than what gets dropped. The analyst proposes the ranking; the process owner and the people who run the process do the ranking, in one session, with the diagram on the wall. A ranking the process owner has not agreed to will be reopened in the steering committee, and that is where analyses go to die.
How do you turn a finding into a "so what" for a decision-maker?
One finding, one sentence, three parts: what happens at which step, what it costs in time or risk, and what the decision is. "Returned parts wait at the Returns Desk because outgoing deliveries come first; that wait is the largest share of the complaint lead time; the decision is whether Logistics gets a daily slot for returns." A decision-maker can say yes or no to that. A list of observations, however accurate, gets a request for a presentation instead.
02 — Better with patchley
Analyses written from the diagram and the conversation
The lenses become analyses per step, written from what was said and what the diagram shows, and they follow the diagram when it changes.
Analyses are written by hand, step by step, in separate documents that drift apart.
With patchleypatchley writes the analysis for every step and every lens, pain points, controls, compliance, figures, from what was said in the capture and what the diagram shows.
Your own questionnaire is filled in again for each process, by hand.
With patchleyYour template is answered step by step. The questions your organisation asks about every process are asked once, in the template, and answered for each step.
When the process changes, the analysis is out of date and nobody knows which parts.
With patchleyChange the diagram and the analyses follow. What you wrote by hand stays, and the figures leave as XLSX for your own calculation.
Judging the findings and ranking them. The analyses say what the people said and what the diagram shows; which of it matters, and in what order, is the team's call.
03 — The running case
Where a Tannhof complaint really waits
Tannhof Armaturen GmbH is fictional and every figure is invented; the people interviewed gave estimates, and the analyses say so. The excerpts below are taken from the pain-point analysis of the signed-off As-Is, trimmed but not reworded.
Where the complaint waits, and why
Everybody at Tannhof blamed the Lab. The interviews put the returned part at the Returns Desk in Logistics for about eight working days before anyone passes it to the Lab, because outgoing deliveries come first and a returned part is nobody's priority. The Lab then tests it in about two working days. In the diagram the wait is a timer event between "Book part in SAP ERP" and "Pass part to Lab", and once it is drawn, the analysis per step lands on the right lane.
The finding that looked biggest and was not
The approval of every 8D report by the head of Quality, about three working days per report, looked like the obvious bottleneck: a single person, a mandatory control, a queue. It is a real finding, and it stays on the list, but it affects only justified complaints after testing, while the wait at the Returns Desk affects every complaint that involves a returned part. Rated by effect, the Returns Desk comes first; rated by risk, the approval is the one that needs the control owner in the room before anything changes.
Estimating waiting time without system data
SAP ERP records when the part is booked in, and the CAQ system records when the test report is written; neither records the hand-over between them. The team took the estimates from the two interviews, wrote them on the steps as estimates in the quantitative analysis, and read them off along the path. The sum does not need to be exact to show that the wait at the Returns Desk is several times the testing time.
"Parts wait an average of 8 working days at the Returns Desk before being passed to the Lab. This is a significant bottleneck in the process, as Logistics prioritizes outgoing deliveries over returned parts."
Cause: "No dedicated resources or SLAs for handling returned parts. Misplaced blame on the Lab, while the delay occurs at the Returns Desk."
Pain-point analysis of the fictional case, priority high. Figures are estimates by the people interviewed."The Lab is often blamed for delays, but the actual bottleneck is the waiting time at the Returns Desk. Testing itself takes about two working days, which is reasonable."
Risk: "If the Lab is unfairly blamed, it may lead to morale issues or misallocation of resources to address the wrong problem. The root cause (Returns Desk delay) remains unaddressed."
Pain-point analysis of the fictional case, priority medium."Small complaints (credit under 500 euros) are settled without notifying Quality, leading to no recording in the CAQ system. This results in recurring faults going unnoticed and no data for root cause analysis."
Pain-point analysis of the fictional case, priority high. The branch itself came from the interview in step 6."The approval of 8D reports by the head of Quality is a mandatory control that takes about 3 working days, creating a bottleneck in the complaint resolution process."
Cause: "The head of Quality is the sole approver for all 8D reports, which can lead to delays if they are unavailable, overloaded, or if multiple reports are pending approval simultaneously."
Pain-point analysis of the fictional case, priority high. A control step: any change needs the control owner.04 — Helper tool
Findings prioritiser
Three questions this tool answers: what are our top three, what is quick to fix and what needs a project, and what should we deliberately leave alone. Rate each finding on effect, effort and risk and the tool ranks them and draws the matrix. It starts with the Tannhof findings as marked examples; replace them with your own. Everything stays on this page and nothing is stored.
Effect is the effect on what the project set out to improve. Effort is what it takes to fix. Risk is what could go wrong when you change it; rate controls and anything a regulator looks at high.
05 — Best-practice outcome
Prioritised findings, step by step
A ranked list where every entry points at a step in the signed-off diagram. Three checks tell you whether it is done.
Analysis is done when the process owner can say which three things to change, why, and what each would cost, and can point at the diagram while saying it.
06 — Common traps
Where analysis goes wrong
Three ways an accurate analysis leads to no decision.
Eighty findings, no decisions
A long list is a sign that nothing was ranked. Decision-makers do not read eighty findings; they ask for a summary, and the summary is where the ranking should have been. Three findings with evidence get decided; eighty get postponed.
Findings that read as blame
"The Lab is slow" is blame, and the Lab will spend the steering committee defending itself. "Returned parts wait before they reach the Lab, because deliveries come first" is a finding about a priority, and Logistics can change a priority. Write findings about steps and rules, never about people or units.
Analysis that goes on too long
When the next week of analysis would change the ranking of the top three, keep going. When it would only add to the list, stop. The As-Is is a baseline, not a monument, and the To-Be in step 8 will raise the questions that are still worth answering.
07 — Ready to move on?
Two questions before step 8
The To-Be design starts from the ranked findings and from the baseline. Both have to be agreed, not just written.
Has the process owner accepted the findings?
Not "received": accepted, with the top three in their own words. Where they disagree, the disagreement is recorded with the evidence on both sides, and the To-Be will have to resolve it.
Is the baseline from step 2 confirmed or corrected?
The business case in step 2 rested on assumptions about where the time and the cost sit. The figures on the steps now show whether those assumptions held. Confirm the baseline, or correct it and say by how much; the To-Be will be measured against it.