Workflow Archaeology: Review the Reasons Behind a Process

Reviewed and updated October 8, 2026.

A workflow step should earn its place through the problem it solves today. Before removing an old approval or automating a manual check, find out why it exists, who relies on it and what could fail without it. Age alone is not evidence that a control is wasteful.

Workflow archaeology is a practical review heuristic: trace the origins of a process, then test its current purpose. It is not a validated research method or a promise of a particular saving. Its value is the evidence it helps a team gather before changing work.

Trace one actual transaction

Choose a completed transaction with a clear start and finish, such as a supplier bank-detail change. Walk through the records with the people who performed it. Record the handoffs, systems, decisions, waiting time and rework. Compare the documented procedure with what people actually did, including exceptions and workarounds.

Ask when each disputed step was added. Look for a policy revision, audit finding, incident record or system limitation. Interviews can suggest an explanation, but record an uncertain recollection as uncertain. If no one remembers the rationale, the next task is to identify the present risk, not to assume there is none.

A filled-in review record

The following is an illustrative example, not a client case or measured outcome. An accounts-payable team wants to remove a duplicate approval from supplier-detail changes.

• Step: a department manager approves a change after finance has already checked it.
• Original rationale: an old procedure says the department confirms that the supplier is still active; no incident record has yet been found.
• Current owner and risk: finance owns payment integrity. A fraudulent change could redirect a payment; the department still knows whether the supplier relationship is active.
• Dependency: the payment batch uses the approved supplier record. A purchasing report also consumes its status.
• Baseline to collect: time spent actively checking, time waiting for approval, rejected changes, corrections and any payment exceptions, separated by change type.
• Proposed change: keep independent verification of payment details; replace the second full review with a specific active-supplier confirmation where that information is needed.
• Approval: finance, purchasing and the control owner agree on the new responsibilities before the trial.
• Reversible trial: use a limited set of eligible changes, keep an audit trail and preserve the previous procedure as the fallback.
• Checks: examine misdirected or blocked payments, missing confirmations, rework and total completion time before expanding.

That record exposes a useful distinction. Two people may appear to duplicate work while checking different risks. A redesign can reduce repeated data handling while preserving independent verification.

Make the trial answer a question

Write the hypothesis in operational terms: “Replacing the duplicate full review will reduce waiting without increasing missing supplier confirmations.” Specify which cases qualify, which remain on the old path, who can stop the trial and how quickly the team can restore the procedure. Do not test a control change on transactions whose consequences the team cannot contain.

ASQ describes Plan-Do-Check-Act as an iterative change model that includes a small-scale test and review. Here, the review should consider the quality of the work as well as speed. A quicker process that shifts repair work to another team has not demonstrated a net improvement.

Keep a reason with the revised procedure

After the trial, record the decision, supporting evidence and unresolved questions. Update the procedure with the control's purpose and owner, not just its sequence of clicks. Revisit it when the system, risk or dependency changes. This gives the next reviewer a usable history instead of another unexplained rule.

Bring the decision into a project review

Bring one disputed approval, its original rationale and the systems that depend on it. Those details let the review focus on a change that can be tested safely. Explore ALLTIPLY AI roadmap and enablement, or request a project review with the workflow, systems and constraints you need to assess.