01 · Purpose and boundaries
Purpose and boundaries
Process flow concerns the movement of work through activities and handoffs. Process logic concerns the conditions that route, authorize, hold, repeat, or terminate that work. A process can have a clear physical route yet ambiguous decision rules, or correct software rules yet long physical queues. Improvement requires both views.
Define the customer outcome and the start and finish conditions. Identify the unit moving through the process: an order, parcel, pallet, return, or information request. Establish roles, statuses, and required evidence. Include exceptions and rework. A diagram that only describes a successful order omits much of the operating design needed for reliability.
02 · How the method works
How the method works
Observe real cases and map the activities, queues, transfers, and decision points. Distinguish processing time from waiting time. Record why work waits and what event permits movement. A box labeled “approval” should identify the responsible role, required information, response rule, and outcome.
For each decision, specify mutually understandable conditions and the possible routes. “Order complete” may mean all lines picked, all documents present, or all charges approved; choose the exact definition. Include handling of missing, contradictory, and duplicate information. Define rework entry and exit so a corrected item rejoins at the appropriate point rather than repeating every completed step.
Simplify unnecessary handoffs, combine compatible checks, and place decisions near the information source. Preserve segregation, traceability, and required independent verification. Establish visible queue rules and a clear completion event. Test representative normal and abnormal cases before changing system configuration or physical routing.
03 · Worked logistics example
Worked logistics example
Fictional Driftwood Returns handles 100 returns per day. The current route is receive, inspect, await approval, repack, and return to stock. Direct work takes 4 + 6 + 5 + 2 = 17 minutes; approval waiting averages 180 minutes, giving about 197 minutes of elapsed time under the illustrative sequential assumption.
The team discovers that all returns wait for a supervisor although 70 are unopened items with valid purchase records and an approved return reason. The new logic permits these 70 to follow a defined standard acceptance route. Twenty damaged items go to technical assessment, and ten with missing identity go to quarantine. The rules are explicit and approved; staff do not guess from appearance.
For standard items, approval waiting falls to 15 minutes and total elapsed time to about 32 minutes. The 30 exceptions retain appropriate controls. A test identifies a duplicate return identifier; the system now holds that case before stock release rather than treating the second receipt as new inventory.
04 · Interpretation and decisions
Interpretation and decisions
The change reduces delay for the standard class, but the overall average depends on exception times. If exceptions average 240 minutes, the weighted illustrative average is 0.70 × 32 + 0.30 × 240 = 94.4 minutes. Reporting only 32 minutes would misrepresent the whole process.
Review throughput, correct stock release, unresolved cases, and service by route. A fast standard path that leaves quarantine permanently understaffed creates another problem. Verify that decision conditions match the information actually available at the step. If staff frequently use “other,” the logic may be incomplete or the upstream data inadequate.
05 · Common misapplications
Common misapplications
Drawing a tidy flowchart without observing work can institutionalize assumptions. Do not use arrows to conceal handoff ownership or missing information. A yes/no branch needs an operationally testable question. Vague conditions such as “acceptable?” produce inconsistent routing.
Avoid making every exception restart the whole process or allowing rework to bypass necessary checks. Parallel activities need a defined join condition; otherwise one branch may release work while another remains incomplete. Digital status changes should correspond to actual physical events. A parcel marked dispatched while still waiting on the dock creates false visibility and unreliable customer information.
06 · Advanced adaptation
Advanced adaptation
For digital workflows, model states and transitions alongside the activity map. Define which transitions are permitted, who can perform them, and what evidence is required. Consider retries, duplicate messages, cancellation, partial completion, and recovery after system failure. Exactly-once business outcomes often require identity and idempotency controls even when messages arrive more than once.
For mixed physical-information flows, show where data precedes material and where they must meet. Use time-stamped event records to distinguish queues from processing, but validate records against observation. Where flow cannot be continuous, use controlled buffers or pull rather than hiding waiting. Review logic after product, customer, or compliance requirements change.
07 · Implementing and sustaining the change
Implementing and sustaining the change
Introduce process flow and process logic within a clearly named operating boundary. Identify the product family, shift, equipment, and handoffs affected; record what happens immediately before and after that boundary. A change that improves one task while exporting its delay to another department has not established an improvement. Agree who can stop the trial, who handles exceptions, and which customer commitment takes priority when the normal rule cannot be followed.
Establish a baseline from actual work rather than a single demonstration. Include normal variation in order mix, replenishment timing, staffing, and workload. Keep the denominator visible: minutes per order, defects per shipment, or completed lines per available hour answer different questions. Record the workload and conditions alongside each observation so that a quiet trial period cannot masquerade as better performance. Observe the process with the people who do it; their explanation of interruptions often changes the proposed design.
Start with a reversible pilot large enough to expose handoff problems. Explain the expected mechanism before launch: which action changes, which delay or failure it removes, and which result should respond. Train all affected shifts and support roles using the same operating definition. During the pilot, capture exceptions as information about the design. Do not conceal them through unofficial stock, unrecorded overtime, or a specialist who quietly repairs every failure.
Review customer service, safety, quality, work content, and inventory together. A faster average with more severe late orders may be unacceptable; a lower inventory level with repeated emergency deliveries may have displaced the cost. Investigate variation before declaring success. If the expected mechanism does not appear, revise the design or return to the baseline rather than defending the idea. A promising observation is a reason to test more conditions, not proof that every operating context will behave identically.
After a successful trial, make the new rule part of daily work. Give an accountable owner responsibility for the operating standard, change control, training, and periodic review. Specify the abnormal condition that requires escalation and the person who responds. Check whether the improvement remains effective when a trained colleague is absent or demand changes. Sustain the mechanism through routine management and learning; documentation is useful only when it describes the process people actually follow.
Connections
Related methods and phase use
Placed under Improve because of the outcome it supports. Use the method in other phases when its purpose and assumptions fit the work; the phase list is a guide to selection, not a compulsory sequence.
Sources
Professional foundations and further reading
The explanation and fictional teaching examples are written for LeanTrainingLab. Linked primary sources provide professional foundations; example values and local conventions are stated in the guide. The accepted toolset draws on Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). No book text or examples are reproduced here.