Why Question a Process Before Digitizing It?

Imagine a manufacturer whose production line stops because a sensor has failed. A technician knows which replacement part is needed. To order it, they must fill in a paper request and collect several signatures. The company wants to cut the wait, so it commissions an app for electronic purchase requests.

At first, the assignment sounds clear: build a form, send it to approvers, and show the request’s status. But if the entire paper procedure is copied into the app without question, the line will still wait for the same decisions. Only the way it waits will change.

The paper disappears. What changes in the process? #

Suppose the request has twenty fields. The technician enters the machine and part identifiers, but also a supplier, estimated price, and cost center. The form then travels in sequence through the maintenance manager, a budget owner, a purchaser, and another approver.

A digital copy can replace the paper, notify the next person, and show where the request is stuck. That may help. But it can also enforce fields the technician cannot yet know during a breakdown, along with signatures for which nobody can identify a separate decision.

Before designing screens, it is worth walking through several real requests. Who fills in each detail today? When does the next person need it? What happens if it is missing? The answers may show that some information belongs in the initial report, other details belong at the purchasing stage, and some can come from an existing record. Necessary data is not being discarded; it is being collected at the right point in the process.

Each signature needs a reason #

The request’s route deserves the same scrutiny. A maintenance manager may confirm that the part is needed. A budget owner may authorize the expense. A purchaser may check availability and place the order. Those are different jobs, but they do not automatically require everyone to approve every request in the same sequence.

Perhaps the manager already confirmed the need when the fault was reported. Perhaps financial approval is required only for certain types or values of purchase. And perhaps the last signature serves a good purpose that did not come up in the first conversation. The number of signatures alone does not tell us which ones to remove.

But if we create four mandatory states, four sets of notifications, and a rule that the request cannot move without every confirmation, a habit becomes a feature of the software. Changing it later affects more than the form: permissions, history, notifications, and the way people have learned to work.

An urgent case reveals the missing rule #

For routine purchases, people may follow the paper procedure. When a line is down, however, the technician calls the manager, who speaks to the purchaser, and the signatures are added later. That may not be ideal. It is valuable evidence that the official rule offers no workable route for an urgent case.

If the app allows only the standard route, people may start entering requests after the fact or handling the purchase outside the app. The system will hold tidy records, but those records will not faithfully show when a decision was made or on what basis.

The answer is not automatically an “urgent” button that skips every control. First, the company must decide what qualifies for the faster route, who may authorize the purchase, what must be recorded immediately, and what can be checked afterwards. Those rules depend on its operations and responsibilities. Software can then support them without forcing people to pretend every request followed the same path.

Only then should we design the app #

The result does not require a sweeping reform or months of analysis. It is enough to examine a few routine and urgent cases, asking at each step:

• Who knows this information, and when is it actually needed?
• Who makes a decision here, and what exactly do they approve?
• When do people bypass today’s procedure, and why?
• Which control must remain even if the route becomes faster?

The answers determine which fields, states, and permissions the app needs. The technical solution may be simple or complex; what matters is that it supports the real process rather than merely reproducing its paper version.

The next time the line stops, the technician does not need a prettier form. They need a clear path from identifying the fault to an authorized purchase of the part. That path is worth designing before the first request becomes code.