Workflow Rerouting¶
Process redesign — instantiates Relation Rewiring
Implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems.
Workflow Rerouting redesigns the path that work itself travels among actors and systems — the sequence of handoffs a case, request, or approval flows through — by redirecting the flow onto a new route and then decommissioning the old one so work cannot slip back onto it. Its signature, and the thing that separates it from a mere reassignment or a config tweak, is that closing the abandoned path is a first-class step: a reroute that leaves the old shortcut open is not a reroute, because people keep using it. It moves the trajectory of the work, protects the items already in flight during the switch, and is done when the new path is the only path.
Example¶
An insurer's claims all flow straight to general adjusters, who lack fraud tooling, so suspicious claims leak through and get paid before anyone notices. Workflow Rerouting inserts a new route: claims scored high-risk are redirected to a specialist fraud-triage lane before they reach an adjuster. Crucially, the team then closes the old direct path for flagged claims — adjusters can no longer pull a flagged claim straight from the queue, which had been the informal shortcut that kept the leak alive. Claims already mid-adjudication get a defined cutover so none are stranded. The setup is "high-risk claims go to triage first"; the outcome is that fraud is caught upstream and stays caught, because the shortcut that used to reopen the leak is gone.
How it works¶
- Map the current flow — trace where work actually goes, including the informal shortcuts.
- Redirect the path — insert, remove, or reroute handoffs so work follows the new route.
- Decommission the old route — the distinguishing step: remove or gate the abandoned path so work cannot revert to it.
- Carry in-flight work across — a cutover plan migrates items already in process without dropping or duplicating them.
The middle two steps are what make it this mechanism: it does not just add a better path, it closes the worse one and protects continuity across the switch.
Tuning parameters¶
- Routing criteria — what triggers the new path (a score, a flag, a case type); broader criteria reroute more work but risk over-routing.
- Reroute scope — all work versus a subset; a narrow reroute is safer but leaves more on the old path.
- Cutover style — hard switch versus parallel-run; parallel is safer but doubles handling during the overlap.
- Old-path closure completeness — fully removed versus gated with exceptions; full removal prevents reversion but eliminates the safety valve.
When it helps, and when it misleads¶
Its strength is fixing the case where work chronically ends up on the wrong path — the leak that persists because the shortcut is still there. By closing the old route it makes the new pattern stick where a pure "please use the new process" never would.
Its honest failure mode is that rerouting relocates the bottleneck rather than removing it: relieve one constrained handoff and the constraint reappears at the next tightest step, exactly as the Theory of Constraints predicts.[n1] The classic misuse is rerouting without closing the old path, so the reroute exists on paper while people quietly keep using the shortcut — churn with no behavior change. The guarding discipline is a cutover check (a one-time verification, not standing telemetry): confirm at switchover that the old path is genuinely closed and that no in-flight case was orphaned.
How it implements the components¶
edge_change_set— the redirection of handoffs is the concrete set of work-path edge changes (added, removed, redirected).bypass_path_closure— decommissioning the old direct route so work cannot revert to the shortcut.transition_and_continuity_plan— the cutover that carries in-flight cases across the switch without stranding them.
It does NOT implement mediating_relation or post_rewiring_monitoring — those belong to Routing Table or Rule Update, which re-parameterizes an already-standing router and watches its queues rather than redesigning the process path and retiring the old one.
Related¶
- Instantiates: Relation Rewiring — Workflow Rerouting is the flow-focused mechanism that moves the path work travels.
- Consumes: Network Intervention Pilot can de-risk a reroute by testing it at limited scope before the full switch.
- Sibling mechanisms: Organizational Redesign · Stakeholder Realignment Workshop · Communication Channel Redesign · Partnership Restructuring · Dependency Injection or Adapter Substitution · Routing Table or Rule Update · Network Intervention Pilot
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: Workflow Rerouting operates as a direct treatment or transformation applied to a target to change its state or condition because it implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems.
Independent corroboration: The frozen evidence defines Workflow Rerouting as 'Implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems', so its operative form is Intervention, Treatment & Transformation.
Nearest alternative: Protocol, Workflow & Routine — Workflow Rerouting includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a direct treatment or transformation applied to a target to change its state or condition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Changing which actor or system receives a case, request, approval, or information item is business-process routing. BPMN formalizes sequence flows, gateways, lanes, and message flows among participants; logistics and computing independently contribute physical routing and runtime dispatch, making the portable mechanism convergent.
Related originating lineages:
- Architecture & Urban Planning — Planning's spatial access, work environments, and territorial design tradition supplies an independent formative lineage for the mechanism's workflow rerouting logic.
- Computer Science & Software Engineering — Computer science and software-engineering practice has a distinct contributing or parallel lineage for the mechanism's defining operation: implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems.
- Logistics & Supply Chain Management — logistics_supply_chain contributes logistics, inventory, and supply-chain operations to this mechanism's defining operation—Implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems—without displacing the selected primary historical lineage.
- Operations Research — Operations research, optimization, and queueing analysis has a distinct contributing or parallel lineage for the mechanism's defining operation: implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics has a distinct contributing or parallel lineage for the mechanism's defining operation: implements the archetype by changing the path that work, cases, requests, approvals, or information follow among actors or systems.
Review resolution: The blind reviewers disagree on primary lineage (logistics_supply_chain versus organizational_management). Authoritative or primary research supports organizational_management as the best historical origin: Changing which actor or system receives a case, request, approval, or information item is business-process routing. BPMN formalizes sequence flows, gateways, lanes, and message flows among participants; logistics and computing independently contribute physical routing and runtime dispatch, making the portable mechanism convergent. The cited Object Management Group, Business Process Model and Notation 2.0 directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=convergent records lineage, while domain_reach=universal records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Theory of Constraints (Eliyahu Goldratt) — a system's throughput is set by its single tightest constraint; relieving one bottleneck typically moves the binding constraint to the next step, so a reroute must be re-checked against where the new constraint lands. ↩