Digital transformation is not a technology problem
Many digital projects begin with a tool: a new website, a management system or a dashboard. But if the business problem is not clear before choosing the tool, it may simply add another layer of cost without improving the process. Imagine customer requests being recorded without anyone being responsible for following them up. A new form alone will not resolve that ambiguity.
Digital transformation is really a change in how work is done: which decisions need to be faster, which repetitive tasks should disappear, and which data should be available at the moment of decision. Technology is the means, not the change itself. Before discussing software features, write the problem in one sentence, such as: ‘Neither the customer nor the person handling the request can clearly see its status.’
The starting point: process and cost
The first step is to document one process from start to finish — not as the manual describes it, but as it actually happens. For each stage, identify the input, responsible person, output and place where information is recorded. Then ask where time is lost, where errors repeat and which steps genuinely create value.
Talk to the people doing the work and review a few real requests without exposing personal information. Record waiting time, duplicate data entry and work returned for correction to separate assumptions from evidence. Cost is not just the purchase price of a tool: staff time, training, data migration and maintenance also belong in the decision.
- Which tasks are repeated too often?
- Which information arrives too late for decisions?
- Which errors create the most cost?
- Which step creates the longest wait for customers?
A minimum, executable roadmap
Once bottlenecks are clear, you do not need to solve everything at once. A minimum roadmap identifies two or three priorities based on expected impact, required effort and dependencies. Start with an action that has a limited scope and an outcome you can assess — for example, clarifying who owns each request and its status before automating the entire process.
A general approach can move from understanding the business and identifying opportunities to design, development, integration, optimisation and support. These are areas of work, not a fixed recipe for every organisation. Revisit assumptions at each stage. Give the pilot a clear owner, role-appropriate access, user training and a way to return to the previous process if problems arise. Make expansion depend on the pilot results, not just on the software being ready.
How do we know the path is working?
Define indicators before execution. A good indicator connects process and business outcome: request cycle time, data-entry error rate, or the share of requests resolved without a follow-up call. Record the baseline, data source and calculation method so that before-and-after comparisons of similar requests are meaningful. Do not assess speed separately from response quality and the team's workload.
Digital transformation is not a destination; it is a way to learn about the business. After the pilot, consider the data alongside staff and customer feedback. If there is no improvement, look at the process, data quality and how the tool is used rather than immediately buying another tool. Use the evidence to decide whether to revise, expand or stop the solution.
Getting started: a checklist before choosing tools
Before requesting a technical proposal, bring these items together on one page:
- Write down the problem, the process boundaries and its owner.
- Document one bottleneck with real examples, excluding personal information.
- Define an indicator, its baseline and criteria for continuing or stopping the pilot.
- Set the pilot scope, budget, training, access permissions and rollback plan.
- Set a review point and assign someone to summarise the data and feedback.