A business calls a development company and says: we need a system. What follows is almost always a conversation about technology — which stack, how many screens, how long, how much. It is a comfortable conversation for both sides, and it skips the only question that determines whether the project works.
That question is: what is the process you are actually running, and why does it look like that?
Software makes processes permanent
A manual process is flexible in a way that hides its cost. If a step is redundant, someone quietly skips it. If a form is wrong, someone corrects it in the margin. The organisation absorbs the inefficiency and stops noticing it.
Software removes that flexibility. Once a step is encoded, it happens every time, exactly as written. This is the whole point — consistency is the benefit you are buying. But it means that digitizing an unexamined process does not just preserve the waste, it institutionalises it. And it is now expensive to change, because changing it requires a developer.
The most expensive line item in a digitization project is usually the process step that should have been deleted before anyone wrote code for it.
What examining the process actually looks like
It is not a workshop. It is sitting with the people who do the work and watching them do it. In practice, a few patterns come up almost every time:
- A step exists because a system that no longer runs used to require it.
- Data is entered twice because two departments do not trust each other's copy.
- An approval exists because of one incident several years ago, and now applies to everything.
- A report is produced monthly and read by nobody.
- The real process and the documented process are different, and the real one is better.
Each of these has a different correct response. Some steps should be deleted. Some should be merged. Some should be automated exactly as they are. Some should be kept manual on purpose, because they require judgement and a form field would only create the appearance of a decision.
The order that works
Understand the process. Decide what should exist. Then build software for that — not for the process you found.
This sounds slower and usually is not, because the scope shrinks. In most operational systems we have built, the honest examination removed more from the specification than it added. Fewer modules, fewer screens, fewer edge cases to handle, less to maintain in year two.
A useful test before you commission anything
Pick the process you most want to digitize. Ask three people who perform it to describe it independently. If you get three different descriptions, you do not have a technology problem yet. You have a definition problem, and software will make it permanent.
Resolve the definition first. The technology part is genuinely the easier half.