Business diagnostics before digitalisation

Why should technology not come first?

Because the same symptom can have several different causes.

If order processing takes too long, for example, the cause may be:

• manual data entry;
• incomplete information;
• parallel records;
• unclear responsibility;
• an unnecessary approval step;
• a poorly designed process;
• insufficient capacity;
• a system limitation;
• or a combination of these.

Without knowing the cause, a technology investment may address only the symptom.

A new application can accelerate data entry while the business process still waits at the same point.

Automation can remove a manual step while incorrect data continues through the process.

A new ERP can replace the old system while leaving the operational problem untouched.

Digitalisation alone is not operational improvement.

It becomes improvement when it provides a measurably better solution to an understood business problem.

What is a pre-digitalisation business diagnosis?

A business diagnosis is a structured investigation of current operations.

It examines more than the software the company uses.

You also need to understand:

• how processes progress;
• how information flows;
• where decisions are made;
• how responsibilities are allocated;
• where manual work takes place;
• which solutions have developed outside the system;
• where delays, errors or rework arise;
• and which problems have root causes outside technology.

The aim is not to produce the longest possible problem list.

It is to distinguish symptoms, causes and possible interventions.

1. Define the business outcome first

“We want to digitalise” is not a business objective.

“More efficient operations” is not specific enough either.

Define what should change in an observable or measurable way.

For example:

• shorter order processing times;
• fewer stock discrepancies;
• less repeated data entry;
• faster quotations;
• fewer manual errors;
• better visibility of order status;
• less time spent preparing information for management decisions;
• less operational dependence on individual employees.

The technology decision can later be assessed against this outcome.

The first question is which business outcome the system must produce, rather than what features it offers.

2. Uncover current operations

Next, understand how the work actually gets done.

Do not examine only how policies or the business system describe the process.

Real operations often differ.

Compare:

• the documented process;
• employees' accounts of the work;
• actual work practices;
• data and events recorded in systems;
• and work outside those systems.

Pay particular attention to points where employees have created their own solutions.

These may include:

• an Excel spreadsheet;
• a manual list;
• personal records;
• email coordination;
• notes;
• a parallel database;
• data exported from a system and processed manually;
• or a rule that exists in an employee's head.

These often indicate that a gap has developed between the official system and actual business operations.

3. Examine information flow

A common digitalisation problem lies in information rather than the process itself.

For every critical piece of data, examine:

• where it originates;
• who records it;
• which system holds it;
• who uses it;
• who may change it;
• when it is updated;
• how it reaches the next participant;
• and which source is authoritative.

If three spreadsheets give three different answers to the same question, the problem may not be a shortage of software.

There may already be too many disconnected information sources.

Clarifying what data means, where it comes from and which version is valid is a basic prerequisite for digitalisation.

4. Identify waiting, rework and workarounds

Points where work stops or repeats are particularly valuable in understanding actual operations.

These may include:

• waiting for management approval;
• requesting missing information;
• entering the same data several times;
• correcting incorrect data;
• exporting from a system and then processing in Excel;
• manually copying between systems;
• checking back by phone or email;
• workarounds created because of system restrictions.

Some of these problems can be eliminated through digitalisation.

Others cannot.

The next step is therefore to distinguish their causes.

5. Separate the symptom from the root cause

The same operational problem can have several origins.

Kyntrax's diagnostic approach examines at least the following areas separately:

Process

Does the workflow design cause the problem?

Information and data

Is the cause incomplete, late, inaccurate or conflicting information?

Responsibility

Is it unclear who decides, who executes and who is accountable?

Rules

Is a business decision rule missing or ambiguous?

Capacity

Is the process fundamentally sound but lacking the capacity to carry it out?

Technology

Is the current system genuinely unable to support the required operations?

Integration

Are the systems individually suitable but failing to exchange information correctly?

These are different problems.

They require different solutions.

Why does this matter?

The diagnosis may show that the company:

does not need a new system.

The appropriate intervention may be:

• simplifying a process;
• clarifying responsibility;
• changing a decision rule;
• organising data structures;
• configuring the existing system properly;
• integrating two systems;
• automating part of a process;
• introducing an application;
• improving ERP;
• replacing ERP;
• or adding AI support later.

Technology neutrality matters here.

The diagnosis does not exist to justify a preselected solution.

Its purpose is to identify which intervention is justified by actual operations.

Which evidence should you rely on?

Operational diagnosis involves more than interviews.

An interview reveals how participants understand the process.

Operational records can reveal what actually happens.

The purpose of evidence is not employee surveillance.

It is to understand how the operational system behaves in practice.

Illustrative example

Suppose every sales order in a company waits for management approval.

The apparent problem is simple:

approval is slow.

A technology solution is easy to find.

For example, a digital approval form or an automatic notification.

But first examine:

• Why does every order require approval?
• Do the same rules apply to every order?
• Which risk is the manager checking?
• Could some orders be decided automatically?
• Is the right information available for the decision?
• What happens while approval is pending?

A new system may send approval requests faster while leaving the real bottleneck unchanged.

A faster route into a queue is still a queue.

How do you decide what to digitalise?

Not every manual process is bad.

Nor is every automatable process worth automating.

An intervention may be justified when you can clearly define:

• which problem it resolves;
• the root cause;
• which business outcomes are expected;
• how the result can be measured;
• which other processes it affects;
• which new risks it creates;
• which data it needs;
• and how much change it entails.

Priorities should therefore reflect more than technical feasibility.

They must also account for business impact, risk, dependencies and deliverability.

When is a pre-digitalisation diagnosis useful?

When the company can move beyond general descriptions of problems.

Instead of saying:

“there is too much manual work”

it can show:

• where it occurs;
• why it occurs;
• what triggers it;
• who is affected;
• what consequences it has;
• which information is involved;
• and what a better result would look like.

The same applies to improvement objectives.

Instead of saying:

“we want more efficient operations”

it can define:

• the current state;
• the desired state;
• the gap between them;
• the most important problems;
• and how subsequent change can be checked.

Can a company digitalise without ERP?

Yes.

Digitalisation is not synonymous with ERP implementation.

A company's operations may improve through:

• process changes;
• better use of an existing system;
• system integration;
• automation;
• better data management;
• a new digital service;
• a focused application;
• improving ERP;
• replacing ERP;
• or AI support.

ERP is one possible tool.

It is not digitalisation itself.

When should you consider AI?

AI is subject to the same operations-first approach.

Before introducing an AI assistant, agent or automated decision support, understand:

• which process it will operate within;
• which data it will use;
• which information is authoritative;
• which decision or task it will support;
• where human responsibility remains;
• which result is expected;
• and how its operation can be checked.

AI makes operational diagnosis more important, not redundant.

If business logic, data or responsibilities are unclear, AI can inherit and accelerate these problems, consuming available capital faster.

The Kyntrax approach

Kyntrax does not treat digitalisation as technology procurement.

The starting point is the company's actual operations.

The Kyntrax Mirror reveals:

• processes;
• information flows;
• roles and responsibilities;
• decision points;
• exceptions;
• work outside the system;
• and critical operational blind spots.

The Kyntrax Compass builds on these findings to define the desired direction, priorities and justified next steps.

Only then can an informed decision be made about whether change requires process improvement, integration, automation, ERP, AI or a combination.

We do not start with which technology can be introduced.

We start with which operations are worth creating.