How to decide which process to digitise first: a matrix for sound prioritisation

When an organisation accumulates spreadsheets, emails, manual approvals and tools that do not connect, the question is not whether it should digitise. The relevant question is which process it should address first. Choosing poorly can consume technical capacity, frustrate teams and reinforce the idea that digital transformation does not work. Choosing well creates an improvement that is visible, sustainable and useful for deciding the next step.

The decision is often influenced by unreliable factors: the process a senior manager complains about most, the one with the greatest customer visibility or the one that appears easiest to automate. None of these is enough. The first initiative must combine business value, operational feasibility and a reasonable likelihood of adoption. Digitisation is not about moving a manual workflow onto a screen: it is about redesigning how a decision is made, recorded, executed and monitored.

What it means to digitise first

Prioritising processes for digitisation is not about making a technology wish list. It means selecting a specific intervention whose outcome the organisation can operate after launch. This requires distinguishing between process, tool, information and accountability problems.

A process is a good initial candidate when it has a recognisable outcome, accountable people, an identifiable start and end, and enough frequency to support learning. For example, order management may be a priority if data is duplicated across channels, availability errors occur or the team spends time each day confirming information. By contrast, an internal approval with only a few requests each month may not deserve to be the first initiative, even if it is frustrating.

Do not automatically choose the most visible process or the one that is technically easiest. The most visible one may require deep changes to policies, roles and systems. The easiest one may save very little time or create an isolated solution that nobody maintains. The initial goal is to create value without opening up a greater dependency than the business can manage.

The seven-criteria prioritisation matrix

Build a list of five to ten candidate processes. Then score each one on a simple scale from 1 to 5. The scale is not intended to create false precision; it is intended to make assumptions explicit and require alternatives to be compared using the same language.

• Business impact: expected effect on revenue, costs, delivery time, customer experience, control or compliance with internal commitments.
• Frequency and volume: how often it is performed and how many people are involved. A process repeated every day will usually offer more learning and return than one carried out quarterly.
• Cost of error: the consequences of incorrect data, a delay, lost traceability or a poorly recorded decision. Include rework, incidents and reputational risk.
• Urgency: the need to act because of a current bottleneck, an imminent operational change or an opportunity with a limited window. Do not confuse urgency with hierarchical pressure.
• Operational stability: the extent to which rules, steps and exceptions are defined. A changing process may first need simplification and agreement.
• Data availability and quality: the existence of accessible data, clear owners and minimum quality criteria. Without reliable data, automation will only spread errors faster.
• Dependencies: the number of teams, applications, external approvals or policy changes required. Fewer dependencies increase the likelihood of delivering and learning quickly.

You can add the scores together if all criteria have similar weight. If the business has an explicit priority, assign extra weight to impact, cost of error or urgency. However, keep the model understandable: a complex formula often conceals discussions that should take place openly.

indicative priority = impact + frequency + cost of error + urgency + stability + data - dependencies

This formula is a guide, not an automatic decision. A high score with low stability is a signal to redesign first. A medium score with a very high cost of error may require immediate attention, even if its frequency is low.

Signals that reduce priority before investment

Some conditions do more than lower a score: they may temporarily invalidate an initiative. Identifying them early prevents a tool from becoming an additional layer of confusion.

• The team does not share a definition of the final outcome or the minimum steps in the process.
• Exceptions occur more often than the normal flow, and nobody can explain when they apply.
• Accountability is divided ambiguously: several people make decisions, but no one is responsible for the result.
• The solution depends on data entered late, duplicated or lacking a source of record.
• No person or team can operate, correct and evolve the solution after the pilot.
• The improvement requires changing too many systems, contracts, policies or customer behaviours at the same time.

The answer is not always to discard the process. It is often better to carry out a preliminary phase: map the actual flow, remove steps that add no value, decide who is accountable and define exception rules. Standardise enough first; then automate what is repeatable.

How to compare processes without pretending to be precise

Imagine three candidates: order management, internal purchasing approval and sales follow-up. Order management may score highly for frequency, impact and cost of error, but poorly for dependencies if it requires connecting several inventory sources. Purchasing approval may be highly stable and simple, while having low frequency and limited impact. Sales follow-up may create value, but it will be a poor first initiative if the team has not agreed what constitutes an opportunity, which data to record or when to close an action.

In a short session with business, operations and technology, ask for evidence behind every score. Instead of asking, “Is it important?”, ask verifiable questions:

1. What happens today when the process fails, and who detects it?
2. How many times does it occur in a week or month?
3. Which decision, data point or system blocks the flow?
4. Which rule must be the same in every case, and which exceptions are necessary?
5. Who will be responsible for resolving incidents once it has been digitised?

Document disagreements. If operations scores the cost of error as a 5 and technology rates it as a 2, the difference reveals useful information: perhaps rework has not been quantified, or perhaps the risk has been interpreted differently.

Include effort, adoption and maintenance

A value matrix is not enough. After identifying attractive candidates, assess their cost to deliver and operate. This is not only about development hours. Include configuration, integration, data migration or cleansing, testing, training, support, security and rule maintenance.

Compare four possible routes before deciding on the solution:

• Improve the manual process: appropriate when the main problem is ambiguity rather than a lack of software. It may include templates, a single source of information and explicit accountability.
• Configure an existing tool: recommended if the flow is standard, the organisation already uses a suitable platform and the change can be maintained without ongoing development.
• Integrate systems: useful when the problem is duplicated or delayed data between applications. It requires defining data owners, error handling and monitoring.
• Develop a bespoke solution: reserve this option for differentiating rules, needs that are not reasonably covered or an experience that is strategic. It requires accepting responsibility for maintenance and evolution.

Adoption risk deserves specific analysis. A solution can be technically sound and still fail because it adds steps for the sales team, reduces operational autonomy or does not fit the pace of work. Involve real users in the design, but do not delegate the decision solely to individual preferences. Assess whether the change visibly reduces work, errors or uncertainty.

Define a pilot with success and stop conditions

The first initiative should not attempt to solve every variation from day one. Design a pilot with a clear scope: one order type, one team, one location or one specific part of the flow. A limited scope makes it possible to learn without committing the entire operation.

Before starting, document the following:

• The problem to be reduced and the exact process included.
• The accountable business person and the technical or operational lead.
• A baseline: cycle time, errors, manual tasks, incidents or delays observed before the change.
• The rules included in the pilot and the exceptions that will continue to be handled manually.
• The support approach, incident review process and data ownership.
• The conditions for expanding, changing or stopping the initiative.

A good initial decision produces evidence, not just a delivery. If the pilot reduces errors but creates a disproportionate support burden, do not scale it yet: review the rules, data or integration. If users return to their spreadsheet, investigate which need the new flow does not meet. If the process works only with the constant involvement of one experienced person, operational capacity is not yet sufficient.

Final checklist for approving the first initiative

• Does the process create significant value or prevent a costly error?
• Does it occur frequently enough to justify the change and generate rapid learning?
• Is there a stable baseline flow that can be explained and measured?
• Do critical data elements have an identifiable source and owner?
• Are the dependencies limited and manageable?
• Have you consciously chosen between improving, configuring, integrating or developing?
• Is someone responsible for operating the solution after launch?
• Does the pilot have clear metrics, scope and stop criteria?

Prioritising processes for digitisation is a product and operations decision, not a competition to introduce technology. Start with a flow that has value, sufficiently stable rules and an organisation capable of sustaining the change. This approach reduces the risk of automating chaos and turns the first delivery into a genuine foundation for the next one.