Process Discovery
Part of Scaling process automation
Standardising a process before copying an automation
Compare eligibility, decisions, handoffs and results before copying an automation, while retaining justified local variations.
Before copying an automation to another team, check that both teams define an eligible case, an authorised decision and a completed result the same way. Keep local differences that serve a clear purpose. A copied sequence of steps can otherwise produce the wrong business outcome.
Compare one case type across teams
Use recent ordinary, returned and unresolved cases from the original and receiving teams. Ask each team what actually happened, then compare answers with its written procedure. This comparison tests whether an existing automation can travel; it is narrower than mapping a process from scratch.
| Element | Question to settle |
|---|---|
| Trigger and eligibility | What starts the case, and which cases may enter this route? |
| Required input | What must be present before the next action? |
| Decision | Which rule applies, and who may approve a departure? |
| Handoff | Who receives the item, and what shows they accepted it? |
| Result | What evidence shows the business case is complete? |
| Exception | Where does a case wait when the routine route cannot finish it? |
A label such as “approved request” is insufficient if one team means manager consent and another means a completed specialist check. Agree on the meaning before turning the label into configuration.
Key Elements to Compare When Copying an Automation Across Teams
- Trigger and eligibility
- What starts the case, and which cases may enter this route?
- Required input
- What must be present before the next action?
- Decision
- Which rule applies, and who may approve a departure?
- Handoff
- Who receives the item, and what shows they accepted it?
- Result
- What evidence shows the business case is complete?
- Exception
- Where does a case wait when the routine route cannot finish it?
Classify the differences
For each variation, record its reason and owner:
- Common rule:Both teams need the same input, decision and result. Include it in the shared process definition.
- Controlled local value:The rule is shared but a named value, such as the authorised recipient, differs. Define who maintains that value.
- Necessary local branch:An additional decision or handoff has an explained purpose. Preserve it and check its effect on the result.
- Unresolved rule:Staff cannot explain which route is authorised, or the proposed exception has no owner. Pause that part of the copy for a process-owner decision.
Keep a local variation only while its stated requirement still applies; have its owner confirm that condition before reusing or changing the branch.
Classifying Process Differences Before Automation Copy
- Common ruleBoth teams need the same input, decision and result. Include in shared process definition.
- Controlled local valueShared rule with differing named values (e.g., authorised recipient). Define maintenance owner.
- Necessary local branchAdditional decision or handoff with documented purpose. Preserve and validate impact.
- Unresolved ruleStaff can’t explain authorised route or exception has no owner. Pause copy until decision made.
Decide what to reuse
A configuration change may be enough when eligibility, decisions and result checks are shared and only controlled values vary. A separate branch may be clearer when a local decision changes the route. A separate automation may be appropriate when the trigger or result differs materially, or when a shared component would make changes difficult to assess. Validate the choice against the process and platform in use.
For example, two teams might both require recorded approval before creating a destination record, but use different authorised approvers. They could share an approval-evidence pattern while keeping the approver assignment local. If one team proposes proceeding without that approval, the owners must settle the rule before sharing the route.
Check a bounded copy
Start with a defined set of eligible cases in the receiving team. Set expected outcomes for an ordinary case, a local branch, missing information and an uncertain destination result. Confirm who owns each held case and what evidence the receiving team needs. These are checks to plan, not completed product tests.
Inspect destination results, corrections and support work alongside workflow status. Record approved differences with a maintainer. If the rollout needs repeated undocumented changes, revisit whether the supposed common process is truly shared before copying it further.
Steps to Validate a Bounded Copy of Automation
- Define eligible casesStart with a set of ordinary, returned and unresolved cases from the receiving team.
- Set expected outcomesFor ordinary case, local branch, missing information, and uncertain result.
- Confirm ownershipIdentify who owns each held case and what evidence is needed for completion.
- Inspect results and correctionsReview destination outcomes, corrections, and support work alongside workflow status.
- Record approved differencesDocument variations with a maintainer. Reassess if repeated undocumented changes occur.
