A practical guide
Start with one workflow worth improving.
Choose a repeated problem with a clear owner, accessible inputs, and a result you can measure. A useful first application creates a foundation for the next one.
Find the right first problem.
Look for work that is frequent enough to matter and bounded enough to understand. An existing packaged tool may be sufficient when the process is standard; custom software becomes useful when the workflow needs to fit your business.
Name the owner and task
Who does the work, who is accountable for the outcome, and where does the process begin and end? Write down the current steps and the exceptions.
Establish a baseline
Record task volume, time per task, delays, and rework over a representative period. Use observations from the people doing the work.
Check the inputs
Identify the systems, data quality, permissions, and integrations needed. Involve the owners who can approve access and review the result.
Define a useful first release
Choose the smallest complete workflow people can use. Agree acceptance criteria, representative tests, and how users will review the application.
Plan for daily use
Name the operating owner, agree maintenance and support, and plan training and feedback. Launch is the start of measuring adoption.
Measure the result, not just the build.
Agree the measure before delivery and compare the same task and population after rollout. Separate observed results from estimates.
Time and throughput
Compare completion time, waiting time, and tasks completed. Time returned creates capacity; it is not automatically a cash saving.
See operational applicationsQuality and adoption
Track corrections, exceptions, and how often intended users complete the workflow in the application. Faster work is useful when the result is reliable.
Explore customer storiesTotal operating effort
Include implementation, platform usage, infrastructure, model/API costs, maintenance, and support when estimating the business case.
Review platform plansBring a short brief to the conversation.
You do not need a finished specification. A concrete example of today's process gives us somewhere useful to start.
- The problem
- What task is difficult today, for whom, and how often does it happen?
- The starting point
- What systems, documents, and people are involved? What does a typical example look like?
- The intended result
- What would improve, and how would you know? Include constraints and a business owner.
- The operating plan
- Where should it run, who will use it, and who will maintain it?