Software can make a process more visible and consistent, but it cannot decide what the business has not agreed. When responsibility is unclear or a rule changes depending on who is asked, a new interface may simply reproduce that confusion. Before building, test whether a small process change addresses part of the problem.
Identify the source of the delay
A hypothetical Dubbo commercial furniture supplier might blame its order tracker for slow approvals. Reviewing recent jobs could reveal that requests reach the approver without dimensions, or that nobody knows who can approve a substitution. These problems suggest different responses from a tracker that cannot show a completed decision. Observe a few actual cases and separate missing information, unclear authority, capacity constraints and tool limitations. Avoid making the software responsible for every difficulty in the surrounding operation.
Try a small process experiment
The supplier could introduce a short approval checklist and one named decision owner for a limited set of jobs. Observe whether requests become easier to resolve and what work remains awkward. This does not require abandoning a future software project. It can make the software brief more precise by revealing which rules are stable and where a tool would add useful support. Keep the experiment bounded so it does not create a permanent parallel process without review.
Avoid romanticising manual work
A process experiment can clarify needs, but asking staff to keep compensating indefinitely may be impractical. If the agreed process still involves repeated copying, difficult coordination or an unmanageable volume of records, software may be appropriate. The tradeoff is between learning cheaply and postponing a necessary improvement. Judge the experiment against the task it was meant to clarify, and record both the parts that improved and the limitations that remain.
Build around the revised understanding
Use the tested process as evidence, not as an unquestionable specification. A digital workflow may support a better arrangement than a paper checklist, provided the business meaning is preserved. Your next scoping step is a before-and-after process note showing the initial problem, the experiment, observed results and remaining tool needs. Give that note to suppliers alongside representative examples. It helps them propose a focused solution rather than faithfully automate steps your team no longer needs.
Planning checklist
- Separate authority, information and tool problems.
- Run a bounded process experiment.
- Scope the remaining need using observed results.