Business Cases
Part of Business process automation strategy
Defining business outcomes before selecting technology
Write an observable business outcome, choose measures and use them to assess process changes before selecting automation technology.
Define the business outcome as a change in the result people receive, then decide how to measure it. “Install a workflow tool” describes an activity; “help valid requests reach the right decision with fewer returns” describes an outcome that can guide a process change and a later technology choice.
Write the outcome in the recipient's terms
Identify who needs the result: a customer, employee, supplier or team receiving the work. State what they should be able to do when the process finishes, and keep the outcome separate from the proposed method.
A useful statement names the recipient, process boundary, desired result and a condition that must be preserved. For example: “Customers who submit a complete service request receive a usable decision sooner, while disputed requests remain available for review.” This is an illustrative objective, not a claim about a real service.
Check the wording with people who do the work and people who use its output. A manager may want faster handling, while the receiving team needs fewer incomplete cases; both perspectives belong in the outcome discussion.
Turn the statement into observable measures
Choose a measure of the intended result and one or two measures that might reveal a trade-off. Define each measure before changing the process:
| Measure | Definition to settle |
|---|---|
| Time to decision | Which event starts the clock, and which decision ends it? |
| Returned requests | What counts as a return for missing or unusable information? |
| Correction work | Who performs the correction, and how is it recorded? |
| Unresolved cases | When is a case still open, even if a task was marked complete? |
Use the same unit, start event and end event for the baseline and later review. Separate an initial submission from a valid submission if intake corrections are part of the problem. Record withdrawals and exceptions rather than quietly removing them from view.
A metric cannot explain every cause, so inspect representative cases when the result changes.
Set a target that reflects local needs and evidence. No universal number of minutes or percentage improvement makes automation worthwhile. If the organisation has no reliable baseline, establish one before claiming improvement.
Key Measures for Assessing Process Improvement
- Time to Decision
- From valid submission to final decision
- Returned Requests
- Requests with missing or unusable information
- Correction Work
- Work required to fix incomplete submissions
- Unresolved Cases
- Cases still open despite task completion
Use the outcome to test proposed solutions
Compare possible changes. Could a clearer form prevent returns, or a duplicate approval be removed to shorten the path while preserving a necessary decision? Would automated routing help once the request is valid? Ask what each option might change in the outcome measure and what new work it might create.
When technology is needed, turn the outcome into selection requirements. Specify the trigger, information needed, authorised decisions, exception route, completion evidence and reporting data. Compare tools against those requirements and their total ownership costs. A fast demonstration alone cannot show whether the business result will occur.
Agree before launch what would count as success, an unacceptable side effect and a reason to revise the approach. After implementation, compare actual cases with the baseline and ask affected teams whether the result is useful.
