Digital Transformation Starts with Better Decisions

Start with a decision that matters

Digital transformation can reshape products, services and entire business models. Within day-to-day operations, a useful starting point is a recurring decision that has a meaningful effect on performance.

A purchasing team may need to decide when to reorder. A maintenance manager may need to prioritise work across several buildings. A sales team may need to determine which enquiries require immediate attention. Each decision has different information requirements and consequences.

Returning to the material order, the practical objective could be to give the approver a current view of available stock, outstanding orders, the required delivery date and the budget position. That is a clear brief against which a proposed system can be assessed.

Beginning this way also helps control scope. Features earn their place by helping people complete an important task or make a sound judgement.

Clarify who can decide

A digital approval process needs a clear allocation of authority. Who confirms the technical requirement? Who checks the commercial terms? Who can authorise the commitment, and what happens if the request exceeds their limit?

These questions deserve agreement before the workflow is configured. Otherwise, a request may simply move electronically between people who remain unsure whether they can act.

In the purchasing example, a sensible design would identify the checks required for each type of order, the person responsible for each check and the route for resolving exceptions. Routine requests and unusual commitments may need different levels of review.

The record should also preserve the reason for a significant exception. When a supplier is selected for delivery reliability despite a higher price, recording that judgement gives future reviewers context and helps the business learn from the outcome.

Make the information dependable

The UK Government’s Data Quality Framework assesses data in relation to its intended use. That principle is equally useful in business: information must be sufficiently reliable for the decision it supports.

A stock figure may be accurate as of yesterday and unsuitable for a purchase decision this afternoon. A supplier may appear twice under different names. A project report may use a cost category that another department interprets differently.

Addressing these problems requires shared definitions, responsibility for maintaining records and checks at the point where information enters the system. Employees should know how to report an error and who will correct it. Moving records into a common database is only one part of establishing that discipline.

Follow the work across departments

The value of an enterprise resource planning system, or ERP, becomes clearer when we follow a transaction through the business.

A material request may become an approved order, then a delivery record, a supplier invoice and a payment. Linking these stages allows the relevant teams to inspect the same transaction history. The records must still represent what actually happened: a partial delivery should remain distinguishable from a completed order.

This is why a software demonstration should include realistic exceptions. Ask what happens when a supplier delivers the wrong quantity, when an approved order changes or when an invoice does not match the receipt. These cases reveal how the system handles everyday complexity.

Microsoft’s implementation guidance emphasises business ownership of process design and collaboration with IT. I would apply that principle by bringing the people who request, purchase, receive and account for materials into the same process review.

An integrated ERP may suit the business, or specialist applications may need to connect with it. The choice should follow operational requirements, with clear responsibility for keeping information consistent between systems.

Help people use the system well

The OECD identifies skills gaps as a continuing barrier to digital adoption among smaller businesses. Training therefore deserves a place in the operating plan, with time and support allocated to it.

For a purchasing workflow, useful training would involve completing an actual type of request, checking its progress and resolving a missing detail. An employee should understand how their entry affects the person receiving it.

Managers also need to use the agreed records in their reviews. If staff enter information into a system but every meeting still depends on a separately rebuilt spreadsheet, the organisation should examine why. The report may be missing something, the data may be unreliable or people may need further support.

That feedback is valuable. It helps distinguish a training issue from a process problem or a genuine gap in the software.

Measure what improves

Before changing the workflow, establish a baseline. For the material-order example, useful measures could include the time from a complete request to approval, the proportion of requests returned for missing information and the share of orders arriving by the agreed date.

These measures answer different questions. A shorter approval cycle shows that a request moves through the business more quickly. Fewer returned requests suggest that the information is becoming more usable. Delivery performance helps show whether the wider process is meeting operational needs.

Read the measures together. Faster approval is of limited value if errors or urgent replacement orders increase. Equally, a change in delivery performance may reflect supplier capacity or order mix as well as the new system.

Regular review should lead to a specific response: remove an unnecessary step, correct a recurring data problem or revise an unclear responsibility. That gives reporting a practical purpose.

Give AI a defined role

AI adds another way to support these decisions. It can be used to summarise records, help compare quotations or flag transactions for review, provided the chosen tool is tested for the task and has appropriate access to the underlying information.

The business should specify what the tool may do, which records it may access and when a person must review or authorise an action. A draft summary and a supplier payment have very different consequences.

The voluntary NIST AI Risk Management Framework emphasises clear accountability and defined human oversight, with risk management proportionate to the context. In practice, teams need to be able to check supporting records, identify mistakes and intervene when the system’s output is unsuitable.

Begin with a manageable process

A practical first step is to select one important workflow, give it an accountable owner and document where decisions currently stall. Agree on the information and authority each step requires, then test the proposed approach with the people who will use it. Include exceptions before extending it more widely.

That creates a concrete basis for evaluating technology and learning from implementation. It also gives management a way to judge progress through everyday work.

The real achievement is visible when a manager can approve an order with confidence, a colleague can understand the reasoning and the next team can act without reconstructing the whole story. When that becomes a dependable way of working, technology is contributing to a stronger business.