Automation embeds process rules in a system. When those rules are not documented, developers reconstruct them from conflicting explanations and employees expect different behaviour. The result may work technically while failing the actual business.
Good documentation does not always require a complex modelling notation. For many small and medium-sized businesses, one clear map and a rules table are enough if they cover the main flow, decisions and exceptions.
Define the process boundary first
“Order processing” is too broad. For one employee it starts with an enquiry, for another with payment, and for the warehouse with a picking list. Define four boundaries:
- Trigger: the event that creates a new process instance.
- Input: the data and documents required to start.
- Outcome: the verifiable state that means the process is complete.
- Owner: the role accountable for the overall outcome, not one task.
Example: the process starts when the website submits a confirmed order. It ends when the warehouse receives a correct picking task with stock reserved. Delivery and returns are outside the first boundary.
The minimum process profile
| Field | What to record | Example |
|---|---|---|
| Purpose | Business outcome, not a software action | Give the warehouse a complete verified order |
| Start | A specific event | Website creates a confirmed order |
| Finish | A verifiable state | Stock is reserved and the picking task exists |
| Owner | Accountable for the outcome | Head of sales |
| Participants | Roles rather than names | Sales, warehouse, accounts |
| Systems | Data sources and recipients | Website, accounting, delivery service |
| Measures | Time, quality and cost | Time to reserve, correction rate |
Complete the profile before drawing detailed steps. It prevents silent scope growth and gives everyone the same definition of completion.
Document the current AS-IS process
Do not begin with the desired software. Record how work happens now, including spreadsheets, chats, telephone checks and manual workarounds. Otherwise, an important dependency will emerge only after launch.
For every step, record:
- number and short name;
- performing role;
- trigger or preceding outcome;
- input data;
- action;
- output and new status;
- normal time limit;
- possible error or exception.
| Step | Role | Input | Action | Outcome | Exception |
|---|---|---|---|---|---|
| 1. Receive | Sales | Website order | Check contact details and lines | Order accepted | Telephone number or address missing |
| 2. Check stock | Sales | Products and quantities | Check available stock | Availability confirmed | Shortage or another customer's reservation |
| 3. Confirm terms | Sales | Price, payment, delivery | Check standard terms | Terms approved | Exceptional discount |
| 4. Reserve | System or sales | Confirmed order | Create reservation | Stock cannot be allocated elsewhere | Availability changes |
| 5. Send to warehouse | Sales | Reserved order | Create picking task | Warehouse sees current version | Order changes after transfer |
Separate actions from decisions
A step called “check the order” hides several decisions. The system needs precise conditions:
- which fields are mandatory;
- which quantity is considered available;
- when cash on delivery is permitted;
- which discount needs no approval;
- what happens when only part of the order is available;
- who may change an order after reservation;
- when the warehouse task must be replaced.
Write a rule as “if — then — otherwise” and identify its data source. For example: if every line is available, the amount is within the cash-on-delivery limit and the address passes validation, reserve automatically; otherwise, send the order to sales with the reason.
Create an exception register
Do not hide exceptions or attempt to automate all of them in the first release. For each exception, define how it is detected, what data is shown, who decides, the permitted time, how the process returns to the main flow and what audit record remains.
| Exception | Detection | Owner | Decision | Return to flow |
|---|---|---|---|---|
| Insufficient stock | Available quantity is below order | Sales | Substitute, wait or part-dispatch | Update lines and reserve again |
| Exceptional discount | Role limit exceeded | Head of sales | Approve or reject | Save price and continue checks |
| Change after transfer | Order version is newer than task | Warehouse and sales | Stop old task | Create a new current version |
Design TO-BE only after AS-IS
The future process should not digitally copy every manual action. For each step ask whether it is necessary for the result or risk control, whether data can be obtained without re-entry, whether the rule can run automatically, whether checks can be combined, whether a person genuinely decides and which events require an audit trail.
In the example, sales no longer re-enters the order or checks standard cases. The system creates the document, validates fields, reserves stock and sends the task. Sales handles only the exception queue.
Define data and the source of truth
For each key field, specify the source, format, owner and update moment. Pay particular attention to price, available stock, reservations, payment status, customer contacts and order version.
If the website and warehouse show different availability, automation will only accelerate the conflict. Decide which system is authoritative and how other systems receive updates.
Add permissions and an event log
The map must answer not only “what happens” but also “who is allowed”. Define who may change a price, cancel a reservation, move a process backwards and close an exception. For significant actions, retain the actor, time, old value, new value and reason.
Write acceptance criteria
- A standard order receives a reservation automatically within one minute.
- An order missing a mandatory field does not reach the warehouse and shows a clear reason.
- A quantity change after reservation creates a new task version.
- Sales sees one deadline-controlled exception queue.
- Every discount decision appears in the history.
- Before-and-after measures use the same definitions.
“It must be convenient” and “everything should be fast” are not acceptance criteria.
Common documentation mistakes
- Only the happy path is recorded. The first exception stops operations.
- People's names replace roles. The process breaks after a staffing change.
- Steps are too broad. Decisions remain hidden without rules.
- AS-IS is replaced by the desired picture. Real dependencies disappear.
- No source of truth is defined. Systems show different states.
- The process has no version. Testing becomes ambiguous after a change.
- No measures are set. Automation results cannot be proved.
What should exist before development
The team should have a process profile, AS-IS map, TO-BE map, rules table, exception register, data-source list, permission matrix and acceptance criteria. For a focused process, this may fit into a few pages and one diagram.
The process owner, key participants and technical owner approve it. Approval does not freeze the document forever: a version number and change log keep updates controlled.
Processes in Business Reactor
Business Reactor connects roles, statuses, documents, products and operations in one environment. The process map does not remain an isolated presentation; its rules can be matched to actual permissions, events and system data.
After documentation, test the economic case: what current work costs, which losses will actually disappear and how long implementation will take to repay.
Conclusion
Good process documentation starts with a boundary and a business outcome. Record current steps, decisions, data and exceptions before designing the future flow. This removes ambiguity and produces testable requirements.
The next step is to turn time, errors and delay into a financial model and calculate the payback of automation. Business Reactor Core.
