Digital Transformation Pilots: Choosing One Process to Change First
Most digital transformation projects fail for a predictable reason: they start with a technology choice rather than a process problem. A founder hears about a new platform, a team buys it, and months later the business has a new system layered over the old habits. A more reliable approach is to pick one process, measure how it currently works, and change it deliberately. This article walks through how UK founders and operators can select that first process, set a meaningful baseline, and decide whether a pilot has earned the right to expand. The guidance here is general and applies across sectors, so adapt the specifics to your own operating reality.
Start with a process that hurts in a measurable way
The best candidate for a first pilot is a process that is repeated often, involves more than one person, and produces visible friction. Quote-to-cash, customer onboarding, supplier invoice approval, and monthly reporting are common examples. Avoid choosing something sensitive, legally complex, or dependent on a single person's judgement, because a pilot in those areas will be hard to evaluate cleanly.
Ask people who run the process to describe the last three times it went wrong. Listen for delays, re-keying of data, chasing for approvals, and workarounds stored in personal spreadsheets. These stories tell you where time and error actually accumulate, which is more useful than a feature list from any vendor.
Map the process before touching any tool
Draw the process as it really happens, not as the policy document describes it. Record each step, who performs it, what inputs it needs, where the information is stored, and how long the handoff takes. Mark every point where someone copies data from one place to another, because those points are both a time cost and a common source of errors.
This map becomes your baseline. Without it, you cannot tell whether a change helped. Keep it short, perhaps one page, and review it with the people who do the work. Corrections from them will be more accurate than anything an assumption-driven workshop produces.
Define success before the pilot starts
Choose two or three measures that you can capture with the data you already have. Typical measures include elapsed time from request to completion, number of manual corrections per week, number of follow-up messages needed to close a task, and the share of records that are complete at first submission. Write down the current figure for each measure before any change is made.
Also define what would make you stop. A pilot should have a clear end date and a rule for deciding whether to continue, adjust, or abandon. Without this, pilots drift into permanent experiments that nobody owns.
A practical checklist before you commit
Before approving a pilot, work through these questions in plain terms. Who owns the process end to end, and will that person be accountable for the result? Where does the data originate, who can edit it, and what happens to it when the pilot ends? What is the simplest change that could remove the largest friction point, and can it be tested without a long procurement cycle? Which people will need training, and how much of their working week will the pilot consume? What existing tool or spreadsheet will be retired if the pilot succeeds, and who will confirm that retirement?
Put the answers in a single document. If you cannot answer one of these questions, the pilot is not ready. Delay it until the gap is closed rather than discovering the problem halfway through.
Decide on expansion with evidence, not enthusiasm
At the end of the pilot period, compare the results against your baseline. Consider not only the measures but also the qualitative picture: did the people doing the work find it easier, or did they simply move the friction somewhere else? Look for new failure modes, such as data that now sits in two places or approvals that have become invisible.
If the evidence is positive, expand to the next adjacent process and repeat the cycle. If the evidence is mixed, adjust one variable and run a shorter second pilot. If the results are poor, record why and move on. A documented failure is a useful asset for the next decision, whereas an unexamined one tends to resurface as a vague belief that the business 'tried that once and it didn't work'.
Digital transformation is cumulative. Each well-scoped pilot teaches you something about your data, your people, and your tolerance for change. Choosing one process, measuring it honestly, and expanding only on evidence will serve a UK business far better than a single ambitious programme that promises to change everything at once.