Once you know why digitalisation projects fail, the next question follows: fine, but where do we start?
It isn't a trivial question. A large financial institution typically has 50-200 identifiable processes that "could be digitalised". Every department head considers their own process the most important. IT capacity is finite. Budget is finite. So is patience.
The wrong order doesn't just cost money - it costs credibility. If the first digitalisation project fails or doesn't deliver the expected results, it becomes much harder to win internal support for the next one.
That is why sequencing is a strategic decision - not an administrative one.
The four factors to weigh
Over 25 years I have developed a simple framework that makes this decision manageable. I assess processes against four factors:
Pain intensity - how much does the current state hurt? If the process is slow, error-prone and expensive, and everyone complains about it, pain intensity is high.
Feasibility - how complicated is it to digitalise? The depth of legacy integration, compliance sensitivity and process complexity all play a part.
Business impact - how much value does success bring? It must deliver a measurable result in customer numbers, revenue, cost savings or risk reduction.
Visibility - who sees the change? The first digitalisation project also builds political capital: if the change is visible to senior management and customers, the mandate for the next project is easier to win.
The decision matrix
Simplifying the four factors into two dimensions gives a 2×2 matrix:
High pain + high feasibility = start here. The ideal first project: a serious problem that is relatively simple to solve.
High pain + low feasibility = strategic project. Necessary - but not first. The foundations must be built first (mapping legacy systems, architecture decisions).
Low pain + high feasibility = quick win. If the first project's role is to build trust, this is a good choice too. But don't expect it to bring organisational change.
Low pain + low feasibility = avoid. At least at the beginning.
Three concrete examples from financial services
At an insurer: claims notification vs. quotation
At an insurer, digitalising both processes was on the table. Claims notification: high pain intensity (a critical point for customer satisfaction), but integration with the core claims system is complex. Quotation: moderate pain, but the existing systems' APIs are available and documented.
The decision: start with quotation. A faster success, and the experience can be used to design the claims notification architecture. Six months later quotation had been digitalised - and the team had the experience needed for the claims integration.
At a bank: customer identification vs. internal credit applications
At a bank, digitalising customer identification was the "shiny" project - everyone wanted it, and it was the visible customer experience improvement. The internal credit application process, however, was paper-based, with 15 hand-filled documents, and took weeks.
For staff, the pain intensity of internal credit applications was enormous - but senior management didn't see it. Customer identification was visible, but integrating the back-end systems was complex.
The decision: run them in parallel - but with different priorities. Credit applications with a smaller team, quickly. Customer identification as the "flagship" project, with a longer time frame. This let the internal team feel a fast result while the visible project also progressed.
At a leasing company: contract lifecycle vs. the sales process
At an operating lease company, contract lifecycle management was entirely manual - every step from vehicle return to remarketing ran on email and Excel. Pain intensity was extremely high. But six different internal systems were involved in the process.
The sales process, by contrast, had a simpler architecture. The decision: start with the first phase of the sales process, with CRM integration. That creates the data foundation on which contract lifecycle digitalisation can build.
The three most common decision mistakes
"Let's start with the most complex - that shows we're serious."
That is political logic, not business logic. The most complex project is the longest and riskiest - and if it fails, everyone will be afraid of digitalisation. Start with one that can succeed, and learn from its success.
"Let's digitalise whatever affects the most people first."
The number of users doesn't equal impact. Digitalising the process of a five-person back-office team with a 40% efficiency gain can bring more business value than digitalising a low-pain process in a 200-person department.
"Let's do whatever the consultant recommends."
The consultant doesn't know the internal politics, the real state of the legacy systems or the organisation's capacity for change. These can only be known from the inside - and they determine real feasibility.
How we do it at FrontX
Before every digitalisation project, we carry out a short process mapping and prioritisation phase, typically one to three weeks. During it:
We map the processes that could be digitalised with the department heads concerned and with IT. We examine the integration capability of existing systems and the legacy constraints. We assess pain intensity, feasibility, business impact and visibility. We recommend a sequence - and explain why.
This doesn't slow the project down - it is what stops digitalisation in the wrong order getting stuck halfway.
If you are planning a digitalisation project and don't know where to start, we are happy to help with prioritisation: frontx.hu/en/company/contact
Frequently asked questions
Which process should be digitalised first? The best first digitalisation project is usually one with high pain intensity - a serious problem everyone complains about - that is relatively simple to deliver within the existing system landscape. This ensures a quick success and learning that later, more complex projects can build on.
How do we decide which process matters most? Assess processes against four factors: pain intensity (how much the current state hurts), feasibility (how complex digitalisation is), business impact (how much value success creates) and visibility (who sees the change). Together, these four factors give a prioritisation matrix.
How long should process prioritisation take? One to three weeks is usually enough - if process mapping is done by experienced business analysts who know the sector. The goal isn't a full BPM project, but enough understanding to make a well-founded sequencing decision.
Is it worth digitalising several processes in parallel? Generally not at the start. Parallel projects split attention, capacity and change management energy. The exception: a low-complexity "quick win" and a longer "flagship" project can run in parallel with different teams.
What should the success criteria for the first digitalisation project be? Business metrics: the process's lead time, reduced working hours, a lower error rate or a change in customer satisfaction. A technology success metric (it went live, it closed on time) is not enough on its own.
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services.
