01 / Section
Start with the outcome, not the application
An application is a setting, not a process. The same business task may move through email, a browser, a document, a shared drive, and a specialist system. Looking at each application separately can produce a list of activity without showing what the work was trying to accomplish.
A completed task is a more useful discovery unit because it gives the investigation a clear boundary: what outcome was attempted, what evidence is connected to it, and where the path began and ended. This does not prove how much time the task took or that every step was recorded. It simply creates a more meaningful object for examining the work.
02 / Section
Reconstruct the attempt from linked evidence
For each task, collect the captured batch of records that can be linked to the outcome. These might include a request, an input file, a decision record, a resulting document, or a handoff. Keep the recorded evidence separate from the interpretation drawn from it.
A citation establishes provenance: it shows where a fact or artifact came from. It does not establish that the task was completed perfectly, that the sequence was necessary, or that the evidence is complete. Use cautious language when the record has gaps. Say that an action is evidenced or suggested, rather than treating the citation as proof of the whole process.
- Recorded evidence: the artifacts, references, and captured sequence associated with the task.
- Interpretation: the likely relationship between those records and the business outcome.
- Planning assumption: a proposed change or test that still needs confirmation.
03 / Section
Compare distinct attempts to find the recurring pattern
One task can be unusual. Compare several distinct attempts at the same kind of outcome, keeping each attempt separate before looking for commonality. This makes it easier to distinguish a repeated workflow pattern from a one-off workaround or an artifact of incomplete capture.
Look for recurring handoffs, repeated inputs, decision points, rework, and evidence produced at the end. The aim is not to rank people or infer individual performance. It is to understand how the work is structured and where the process may be clarified, simplified, or better supported.
- Group attempts by business outcome, not by the application in which a record was found.
- Mark differences between attempts instead of forcing them into one idealized sequence.
- Treat missing records as uncertainty, not as evidence that a step did not occur.
04 / Section
Use app and site sequences as discovery signals
App and site sequences can help locate possible transitions or moments worth investigating. They may show that a task moved between systems or that a particular tool often appeared near a handoff. They are useful clues, but they are not the process itself.
Keep those sequences separate from the evidence map for the task. Do not use them to claim verified working time, automatic execution, productivity, or savings. Instead, use them to form a question: which business outcome was being pursued, what evidence supports the connection, and what should be checked with the people who perform or own the process?
05 / Section
Turn the map into a bounded improvement plan
Once recurring patterns are visible, choose one narrow improvement to test. Define the expected business outcome, the evidence that would show whether the change helped, and the assumptions that remain open. A plan might clarify an intake requirement, reduce an avoidable handoff, or make the final record easier to find.
Keep the proposed change distinct from the reconstructed past. The evidence map describes what the captured records support; the plan describes what operations leaders want to try next. That separation makes the discussion more credible and gives the next review a clear basis for learning.