Before digitising, look at the real process

The perfect workflow follows a procedure that no longer exists

This retrospective analysis concerns 2019 and was written in 2026. The narrative is fictional, its data educational, and no result is attributed to a client or to CYTIZEN. Its subject is the framing of a business and IT transformation: observing work to decide what should be simplified, controlled or automated.

Sophie, the procurement manager, shows the project team a procedure with six approvals. The future tool must route every request in that order. Karim, the project manager, then accompanies a buyer through ten cases. In four, the approver calls the requester before clicking. In two others, a director agrees by email and an assistant subsequently enters a justification. A third control merely checks data already entered by finance.

The procedure is not wrong because people are working badly. It has become an incomplete representation: new requirements, missing information, urgent exceptions and inherited controls have accumulated over time. Digitising that representation without examining it automates some queues while leaving workarounds outside the system.

Define the result before drawing the target

Sophie wants to reduce the time from request to order while retaining control over commitments. Both objectives need to be broken down. Which request category? From which event? Up to what evidence of an order? Scoping distinguishes recurring purchases, supplier creation, capital expenditure and maintenance emergencies. An average mixing these categories would make simplification decisions arbitrary.

The initial scope covers recurring purchases below an illustrative €5,000, with an existing approved supplier. Investments and urgent purchases are studied separately. This does not mean they are less important: their controls and responsibilities differ. The process owner confirms entry criteria and explains which cases will remain outside the future standard route.

The team also specifies what it cannot decide alone. Required segregation of duties, a financial control or a quality requirement does not disappear because its box lengthens the diagram. Relevant functions must identify the evidence needed and whether another mechanism can produce it. The programme facilitates review; it does not adjudicate an obligation solely on the basis of time saved.

Follow cases rather than merely holding a workshop

Karim prepares a sample including completed, abandoned, urgent and reworked requests. Each case retains its identifier, date, amount, location, type and outcome. He observes events: creation, waiting, correction, approval, transmission and receipt. Interviews explain causes, but timestamps provide different information. Someone may spend ten minutes working on a case that waits four days in their queue.

The record combines actual work and waiting. It identifies re-entry, missing information and controls performed outside the tool. Where event data are imperfect, the team combines observation with existing records and describes the limitations. It does not manufacture second-by-second precision from memories. Participants know why they are being observed; the exercise aims to improve the process rather than secretly rank their productivity.

A workshop then compares accounts. Why does the director approve by email? Because the tool does not contain the information they need. Why does the buyer re-enter the justification? Because reporting cannot use the original message. These answers suggest changing data and evidence rather than adding another automated notification.

The record that changes the discussion

Every control must explain its purpose

Sophie and finance examine the six approvals. For each, they specify the risk covered, data used and authorised person. Two stages check the same amount using the same information. Redundancy can be useful if it provides real independence; it may be useless if both participants automatically trust the same spreadsheet. The number of stages alone cannot settle the question.

A proposed removal identifies the replacement mechanism and cases where it is insufficient. In the example, the approved supplier is checked at source, while a change of account details triggers a specific control. The record retains decisions by procurement, finance and the relevant risk function. Drawing a new arrow is not enough to change a responsibility.

Thresholds are examined too. An amount below €5,000 may appear small, but twenty split purchases represent a different exposure. The process must address plausible exceptions and repeated transactions. The programme does not promise an automated control until the data needed to perform it are available and sufficiently reliable.

Describe the target as an operating agreement

The standard route specifies who enters the request, required information, necessary approvals and when the case can move to the ERP. Rules are explicit: a missing supplier or changed data triggers a particular branch. An error does not simply return the requester to the first stage; it explains the problem, its owner and the correction mechanism.

Karim asks business representatives to rerun three cases against the target on paper before development begins. The standard case works. The emergency reveals that the approver is not always available. The team therefore defines an authorised substitute and an audit trail. The incorrect-cost-centre case shows that support must be able to arrange correction at source without authorising expenditure itself. These discoveries cost little before configuration and much more after rollout.

The automation scope follows: a stable rule, controlled data, a routable exception and responsibility for handling it. The tool must retain decision history and relevant changes. If a supplier offers an attractive feature that does not cover the urgent journey, the programme estimates the gap rather than treating the demonstration as proof of suitability.

Calculate gains without making work disappear

End-to-end lead time runs from an admissible request to a transmitted order. Working time adds together genuinely necessary interventions. The distinction avoids selling three days saved as three days of released human effort. Returns for correction and operations outside the tool remain in the measurement.

In the scenario, a recurring request falls from 18 to 12 minutes of work, at a theoretical volume of 800 requests per month. The gross gain is 800 times six minutes, or 80 hours. Exception checks, additional support and data maintenance must be deducted. The remaining capacity is not an automatic financial saving: the manager explains how it can be used or whether it avoids future workload.

Volumes are tested using cautious assumptions. If one quarter of requests leave the standard route, handling them may absorb the expected gain. The business case therefore includes sensitivity to the exception rate. A shorter lead time without reduced workload can still benefit the business, but must be presented as such.

Test the new rule before expanding it

The pilot covers one location and one purchase category, with an available business owner. Support has recovery procedures, procurement observes exceptions and finance checks an agreed sample. Users identify information they still seek in emails or local files. These practices are not ignored merely because they sit outside the target process.

The team compares cases from the same category before and after, stating sample sizes. It tracks median lead time, exceptionally long cases, return rates and exceptions. In this case, an exception rate above 20% would trigger a review of entry criteria. The threshold is educational; the organisation must choose its own according to volumes and risks.

Expansion requires corrections to be incorporated into rules, data and support. If the pilot works because Karim and Sophie are permanently present, the target is not yet a sustainable service. Regular operators must be able to execute the journey without their assistance.

Sector adaptation depends on exceptions

In pharmaceuticals, a purchase may concern equipment or a component with specific quality requirements. The target must preserve relevant approvals and traceability. A fast route reserved for routine expenditure cannot become an implicit way to bypass qualification.

In manufacturing, maintenance emergencies require a procedure that works when the usual approver is absent and production risks stopping. Authorisation, receipt and reconciliation after intervention must remain explicit. In banking, segregation of duties and payment permissions may prevent one person from creating the supplier and authorising the commitment without an appropriate control.

In a service organisation, purchasing services sometimes requires a description of the outcome and verification that the service was performed, which matter more than physical receipt. A standard diagram cannot cover these differences. Analysis must decide which branches to share and which to retain, including their operating costs.

Sources and method

The references provide official guidance on governance, measurement and data quality, consulted in 2026. The Government Data Quality Framework, published in 2020, provides current context and is not presented as a source available in 2019. The observation protocol, calculations and case decisions are original. They constitute neither a statistical study nor a guarantee of gains.

• GOV.UK — Governance principles for agile service delivery
• GOV.UK — How to set performance metrics for your service
• GOV.UK — Government Data Quality Framework, published in 2020, supplementary current guidance

Links verified on 4 October 2026. The scenarios and thresholds proposed in this dossier are educational; they describe neither a client engagement nor a result achieved by CYTIZEN.