EPI: Process Analysis and Redesign

Process Analysis and Redesign tests whether you can move from a messy as-is process to a justified future state. Expect questions on scope, process maps, value stream analysis, waste, root cause, capacity, cycle time, handoffs, and control design.

Core rules and concepts

• Set scope first: start and end events, customer, trigger, outputs, and interfaces. A map with no boundary becomes an enterprise diagram that nobody can improve.
• Use a hierarchy: value stream, process group, process, subprocess, activity, task. Match the map detail to the decision being made.
• Use SIPOC to clarify suppliers, inputs, process, outputs, and customers before mapping flow. Use BPMN for precise flow, gateways, events, and roles; use value stream maps for flow, wait time, and waste.
• Measure before redesigning: process time, wait time, cycle time, throughput, rework, defect rate, and cost. Separate touch time from elapsed time.
• Find the constraint. Improving a non-bottleneck step usually adds inventory or waiting, not throughput.
• Apply redesign principles: eliminate non-value work, simplify, combine, sequence differently, automate only after simplification, reduce handoffs, and design controls for failure modes.

Worked example

A claims process has 120 cases in work-in-process and completes 20 cases per day. Little's Law gives cycle time = WIP / throughput = 120 / 20 = 6 days. The target is 3 days. Options are to halve WIP to 60 at the same throughput, or double throughput to 40 cases per day, or combine both. The reasoning is to locate the bottleneck first: if the bottleneck can only handle 25 cases per day, raising throughput to 40 is impossible without capacity change. Reducing WIP may cut waiting, but if the constraint remains, the queue will rebuild. A credible future state states the constraint, the intended WIP cap, the capacity change, and the control that keeps WIP from creeping back.

Traps that cost marks

• Mapping symptoms and opinions without measuring wait, rework, or variation.
• Confusing process time with cycle time, or ignoring queue time entirely.
• Jumping to automation before eliminating unnecessary steps and handoffs.
• Improving a non-bottleneck and claiming throughput gains.
• Designing a future state with no owner, no controls, and no measurement plan.