Lean for business: start with one workflow

What does Lean mean in practice?

The Lean Enterprise Institute connects Lean with customer value, people’s work and continuous experimentation. It is not a software product or an instruction to work faster.

Ask what outcome the customer needs and what prevents it. A shop may need predictable dispatch; an internal team may need reliable data on time. Start with the outcome rather than a decision to remove every activity.

Choose an observable problem

“The warehouse performs badly” gives you no investigation boundary. A more useful hypothesis is: “Confirmed orders wait for picking because reservation information is missing.” This is an illustrative hypothesis, not a diagnosis or client case.

• Where does the workflow begin and end?
• Who receives its output?
• What waits, repeats or returns for rework?
• Which records and observations could test the hypothesis?

Observe how work actually happens

Follow the process with the person doing it. Record calls, approvals, searches and re-entered data, not just ERP actions. Investigate the process without looking for someone to blame.

VSM considers material and information flows together. A simple sketch can support an initial review; a full value-stream map needs agreed boundaries and data. Not every list of steps is a VSM.

Separate necessary controls from avoidable work

A repeated check may be unnecessary or may control a real risk. Understand why it exists and the consequences of failure before removing it. Involve responsible specialists before changing mandatory controls.

Illustrative example: two people manually verify a status because CRM updates are late. A possible change is to establish status ownership and failure notifications. Removing the second check without fixing the exchange may hide the problem.

Test a limited change with PDCA

ASQ describes PDCA as a repeated cycle of planning, testing, reviewing and acting on the findings. Apply it to a limited area before changing the whole workflow.

• Plan: record the hypothesis, expected effect and risks.
• Test: agree on scope, participants, duration and stop conditions.
• Review: compare expectations with actual results, allowing for workload changes.
• Decide: retain, revise or reject the change. Update instructions when the decision is supported.

What should you measure, and when should you automate?

Choose a measure tied to the problem: time from confirmation to dispatch readiness, repeated requests or unfinished operations. Compare equivalent orders and workloads, not two arbitrary days. Check quality too: a faster process with more errors is not necessarily better.

Consider automation once rules, exceptions and ownership are understood. Some problems need workflow changes; others need configuration or integration. One process and a description of the difficulty are enough for an initial Routio conversation, without customer data.

What should you read next?

Start with the Lean Enterprise Institute’s What is Lean?, then explore VSM and PDCA. The library also links to EPA’s 5S overview, LEI’s standardized-work definition and Toyota’s own TPS explanation. These are public publisher pages, not a certification course or full book translations.