Process mapping and automation scope worksheet

Use one copy for one process. Record what is known, label estimates and write "unresolved" where a decision still needs an owner. The aim is a useful brief for technical discovery. Completing the form does not establish that the proposed automation is feasible or ready to release.

Use fictional or suitably redacted examples. Record access requirements and the person who manages them; do not put passwords, access tokens or personal records in this worksheet.

A. Current process and baseline

Process name: ______________________________

Purpose: what does the recipient need at the end? ______________________________

Process owner: who can settle rules and accept changes? ______________________________

People who walked through the work: ______________________________

Trigger and starting state: ______________________________

Finish and receiving person/system: ______________________________

Work outside this investigation: ______________________________

Map the current steps

Add rows or attach a simple drawing. Show decisions and waiting points, including the handoff to the next person. Keep proposed changes separate from the observed process.

Step	Person/system	Input and required fields	What happens now	Decision rule and its source	Output, handoff or wait
Start


Finish

Workarounds, disagreements or steps that may be unnecessary: ______________________________

Follow the different paths

Input condition	Actual example or known gap	Current response and owner
Ordinary, valid and on time
Missing required information
Incorrect or conflicting information
Duplicate or corrected submission
Late or stale input
Unavailable record, system or permission
Other case needing a person's decision

Record the evidence

Observation dates and operational cycle covered: ______________________________

Record/sample source and number of items examined: ______________________________

Measure	Definition and unit	Observed value or labelled estimate	Method and limitation
Volume	Items entering the chosen boundary
Handling time	Active human effort
Elapsed time	Start to finish, including waits
Exceptions	Define records affected or error events
Rework	Define repeat work and whether included in handling time
Incomplete cases	Define when a case counts as unfinished
Output quality	Approved rule/source used to check correctness

Peak periods, case types or work this evidence misses: ______________________________

What still needs measuring, by whom? ______________________________

B. Proposed automation scope

Decision: keep the current approach / improve the process / configure existing software / investigate automation / unresolved

Reason and supporting evidence: ______________________________

Write short decisions below. Attach the map, detailed rules and test records when they need more space.

Scope field	Decision to complete
Goal	What outcome is this change intended to achieve?
Accountable owner	Who settles business rules and accepts the result?
Start trigger	Which observable event starts the work?
Finish condition	Which checked output/state ends automated responsibility?
Exclusions	Which actions, cases, systems and decisions remain outside scope?
Inputs and authority	Which fields are required? Which source supplies each, and who resolves conflicts?
Systems and access	What may be read or changed? Who approves and maintains access? What interface still needs checking?
Rules and human checkpoints	Which written rules apply? Which decisions need a named person's approval?
Duplicate and correction handling	How is an event identified? How is a corrected version distinguished? What prevents a second business action?
Exceptions	Where does unfinished work wait? Who receives it, with which reason, source reference and attempted-action details?
Recovery	What happens after an outage or uncertain update? Who reconciles completed work and authorises a retry or manual action?
Acceptance	Which cases below must pass, what evidence is kept, and who accepts it?
Monitoring and support	Who checks failures/backlogs, maintains the integration, supports users and covers absence?
Changes and handover	Who approves changed rules? Which instructions, access and records are handed over?
Baseline reference	Where are the observation dates, definitions and limitations recorded?

Acceptance record

Set the expected outcome before testing. Use agreed test records and an authorised test environment. Add cases that matter to this process; do not mark an unperformed test as passed.

Case	Expected business result	Evidence to inspect	Actual result and issue	Acceptance owner
Valid input			Not tested
Missing/invalid input			Not tested
Late input			Not tested
Duplicate event			Not tested
Corrected source version			Not tested
Missing permission			Not tested
Dependent system unavailable			Not tested
Update accepted but confirmation lost			Not tested
Partly completed or unsafe change			Not tested

Reconciliation method: how will expected inputs be matched to outputs and exceptions? ______________________________

Unresolved question / owner / evidence needed / decision due: ______________________________

Decision after technical discovery and testing: ______________________________

Actual approval record, to complete only when it occurs: ______________________________

C. Completed example for reference

WORKED EXAMPLE - HYPOTHETICAL

This is an invented example of preparing approved timesheets for payroll review. It describes proposed behaviour, not a completed implementation or an MSD result. It contains no measured baseline or assumed saving.

Current process and proposed boundary

An approved timesheet arrives. A payroll administrator checks the worker and assignment, checks whether it has already been entered, prepares a draft and passes it to the payroll reviewer. Missing information is referred back for correction. The process owner needs to confirm whether all corrections and repeat submissions are currently recorded.

Baseline: not yet measured. Observe the relevant processing cycle and record workload, active effort, waits, repeat handling and incomplete cases. Seasonal variations and correction cases must be identified before choosing the sample. No benefit estimate has been completed.

Scope field	Hypothetical decision
Goal	Prepare traceable draft records for payroll review.
Owner	Payroll reviewer; appoint the actual person and absence cover before proceeding.
Start / finish	Start when an approved timesheet is available. Finish when its draft, source reference and reconciliation status are ready for human review.
Exclusions	Submitting payroll, approving payments, changing pay rules or deciding an unidentified worker's identity.
Inputs	Source identifier, version, worker identifier, assignment, processing period, approved hours and approval status. The organisation must confirm the required fields and sources.
Access	Read approved timesheets and agreed reference records; create drafts in the review system. Draft creation and permitted access remain feasibility questions.
Rules	Check required values and processing period against approved sources. Missing or conflicting identifiers require a person's decision.
Duplicates / corrections	The same source version must not create another draft. A changed version is held for review under a separately agreed correction rule.
Exceptions	Hold the affected item with its source reference, reason, attempted action and known result. Send it to the appointed reviewer.
Recovery	After an uncertain write, compare the source with the target draft before authorising further action. Prevent automatic and manual recovery from processing the item concurrently.
Monitoring / support	The process owner appoints people to check waiting work, repair access and maintain the integration. Responsibilities and review cadence remain to be agreed.

Example acceptance cases

These are expected outcomes only. None of the tests below has been run.

Case	Expected result	Evidence to inspect
Valid approved timesheet	A correct draft is prepared for review.	Source and draft identifiers, required field values and draft status.
Missing worker identifier	No draft is created; the reviewer receives the reason.	Target contains no draft for the item; exception record identifies the missing field.
Same event received again	No additional draft is created.	Source version maps to the existing draft; repeat receipt is identifiable.
Corrected timesheet	Correction is held for the defined review, without silently adding another draft.	Version history and reviewer decision record.
Draft accepted, confirmation lost	Further action waits until the target state is established.	Existing draft, attempted update and authorisation to resume are reconciled.
Access removed	The workflow makes no unauthorised change and informs the access owner.	Failed operation and notice to the appointed owner.

To use the example, replace its assumptions with your organisation's approved rules, add the relevant failure cases and complete the acceptance record after actual testing.