Map the workflow before you automate.
Follow one piece of work from request to completion. Record its decisions, handoffs, systems, and exceptions to identify what an improvement must actually change.
Choose a boundary people can recognize.
Select one repeatable piece of work, such as approving a supplier request or preparing an operating report. State its trigger and completed outcome. Identify the team that requests it, the team that does it, and the person who relies on the result.
Keep related variations visible. A complete request and an incomplete request may follow different paths. Decide which variations belong in this first map and record what remains outside it. A narrow map is useful when its limits are explicit.
Observe the process people actually follow.
Walk through recent cases with the people doing the work. Compare their account with available records. Include a typical case, an exception, and a case returned for correction. Record work performed in email or spreadsheets as well as the official system.
Separate handling time from elapsed time. A ten-minute check may sit in a queue for a day. Record when responsibility changes, what signals the handoff, and whether the next person receives enough information. Measure rework once, where it occurs, so it is not counted again as a separate saving.
The Lean Enterprise Institute describes value-stream mapping as a way to examine material and information flow, starting with the current condition and then a future state. The worksheet below adapts that observation-first approach to an enterprise information workflow.
A worksheet for the working session.
Print this worksheet and complete it with the people responsible for each step. Use an approved internal record for actual cases and sensitive information. Record uncertainties as questions to resolve rather than filling them with estimates that look measured.
| Record | Question to answer | Working notes |
|---|---|---|
| Boundary | What triggers the work, and what counts as complete? | |
| Inputs | What information arrives, from whom, and in what form? | |
| Steps | What happens in sequence, including checks and corrections? | |
| Systems | Where is information read, copied, recorded, or changed? | |
| Decisions | What rule or judgment determines the next action? | |
| Handoffs | Who receives the work, and how do they know it is ready? | |
| Exceptions | What happens when information is missing or a system fails? | |
| Ownership | Who can resolve a blockage, approve a change, or stop the process? | |
| Timing | How much time is hands-on work, and how much is waiting? | |
| Rework | What returns for correction, and where was the problem introduced? | |
| Evidence | Which cases and measurement period support this map? |
What the map can reveal.
Hypothetical example. A request moves from an intake form to an operations coordinator, then to a department owner for approval. The coordinator copies information into a tracker. Missing cost-center details send the request back to the requester, while complete requests wait in an approval inbox.
The map distinguishes three possible changes: validate the cost center at intake, reduce repeated entry, and clarify approval ownership. Automating the copy step may reduce handling effort while leaving the approval delay intact. Each change needs its own measure.
If the team measures twenty minutes of handling and two days of elapsed time, it should retain both figures. The first describes staff effort; the second describes the requester's wait. Neither can substitute for evidence about the cause of the delay.
Describe the target process before selecting tools.
For each proposed change, specify the owner, required information, system action, approval, and exception route. Preserve checks that serve a real operating purpose. Identify which existing system capabilities can support the change before introducing another tool.
Test how the target process behaves when a request is incomplete, an approver is unavailable, a connection fails, or a retry occurs. Define how work returns to a safe queue and who resolves it. Have the receiving team confirm that the completed output is usable.
Choose a change the team can evaluate.
Prioritize the constraint that affects the outcome, considering effort, dependencies, risk, and ownership. Use the business-case calculator for a directional comparison of capacity, cash savings, implementation cost, and ongoing effort. Keep those assumptions separate from the measured baseline.
If AI is a candidate, use the enterprise AI pilot checklist to define a bounded test. When the operating problem spans several teams or systems, an enterprise diagnostic provides a structured way to establish the scope and implementation priorities.