Choose a repeatable problem with a named owner
Start with a task that happens frequently, follows reasonably stable rules, and has an owner who can explain the exceptions. A request-routing step or a missing-field check is often easier to bound than an entire order-to-cash process. The goal is a pilot you can evaluate, not the largest possible project.
Write a one-sentence definition: when this event occurs, these records are checked, this output is produced, and this person handles anything the workflow cannot resolve. If that sentence is difficult to complete, spend more time mapping the process before selecting software.
Use a simple selection checklist
Compare candidates against the same criteria. High volume alone does not make a task a good first project.
- Stable inputs: the required data exists and has a clear source.
- Clear rules: a person can describe the expected result.
- Bounded impact: a mistake can be detected and reversed.
- Visible exceptions: unusual cases can go to a named reviewer.
- Measurable baseline: touches, elapsed time, and corrections can be counted.
- Supportable access: the ERP provides an approved way to perform the task.
Measure the whole workflow
Count the time required to prepare inputs, review results, and repair failures, not just the automated step. For an illustrative comparison, a task that takes five minutes to run but twenty minutes to clean up is not necessarily better than a ten-minute manual process. These numbers are an example, not an OpsFoundry customer result.
Keep transaction types and measurement windows comparable. Record how many cases required manual intervention and why. That exception log can be more valuable than an average time saving because it reveals the next process problem to solve.
Test failure before increasing volume
Try missing fields, duplicate inputs, unavailable systems, and rejected approvals. Make sure a retry does not create a second transaction. Ask the process owner to walk through the manual fallback without help from the developer.
Expand only after the acceptance criteria are met and support responsibility is clear. If the rules keep changing, pause expansion and stabilize the process rather than hiding uncertainty behind more automation.