Where does digital transformation begin? A 5-step roadmap

First, what digital transformation is NOT

When most companies hear "digital transformation," the first thing that comes to mind is buying new software or moving the old system to the cloud. Why is this approach wrong?

You migrate your system to the cloud but your processes still run on old habits. You install an expensive CRM and two months later the team is back on Excel. Digital transformation is not a tool change — it is a process change. The tool is only the visible part of the change; the real transformation is in how you make decisions, how data flows, and how people work.

A real problem facing SMEs in Turkey: extracting a personal data inventory for KVKK compliance, redesigning processes for the e-invoice transition, or integrating MERSIS data into the sales pipeline — all of these are part of digital transformation. But all of them require process clarity before you buy any tool.

Another misconception: transformation is for large companies. In fact, a small or mid-sized business can change far faster than a large holding with its delayed decision-making. The advantage is waiting for you — the only condition is knowing where to start.

The 5-step starter roadmap

Step 1 — Audit. List your current processes and tools. How long does each process take, how many people touch it, what is the error rate? Mark data flows that fall under personal data regulations, electronic invoice integration points, and steps that require manual intervention. This list reveals not what to change, but what to prioritize.

Step 2 — Map. Draw the chosen process end to end: input, processing, output, exception. Even on paper, skipping this step becomes the biggest cost later. In most SMEs there are processes "held in someone's head"; making them visible is the most valuable step of the transformation.

Step 3 — Prioritize. Which process causes the most time loss or errors? Processes that are frequently repeated, have well-defined inputs and outputs, and have manageable risk are the best starting points. Build a prioritization matrix: effort × impact. High impact, low effort = first target.

Step 4 — Pilot. Start with a single process. Work on a small dataset, observe the outputs, review with the process owner. The goal of the pilot is not zero errors — it is learning. Setviva's method: we build a 2-week proof of concept, work on real data and measure the effect on the business process.

Step 5 — Measure. Define baseline metrics before you start: processing time, error count, frequency of human intervention. After the pilot, measure the same metrics again. If the numbers improved, scale; if not, redesign the process — not the money. These five steps work in every industry, at every scale. What makes the difference is not speed but a systematic approach.

What you can't measure is not transformation

The vast majority of digital transformation projects either start without defining measurement or measure the wrong thing. "Feels much better" is not a transformation metric.

A correct measurement system answers three questions: What was my baseline before I started? What changed after the pilot? Is that change holding once I move to scale? To answer these three questions, choose operational metrics — processing time, in-process error rate, cost per human intervention. These can be collected every day, compared, and fed into decisions.

A common trap: seeing transformation as a one-time goal. Processes don't stay still; legal requirements, business growth and organisational changes affect them. A measurement system makes these shifts visible and forces you to look inward before looking outward.

The ritual Setviva builds with clients: after every pilot we prepare a "health card" — five metrics, before and after, target and actual. This card does not only show success; it also shows what did not work. Because honest measurement is always more valuable than a half-finished transformation.

Who actually owns the change?

A roadmap and a measurement system are necessary but not sufficient. The step most founders skip is deciding, in writing, who owns the transformation — not as a title on an org chart, but as the person who chases the pilot owner every week, defends the budget next quarter, and takes the blame if the first attempt stalls. Without a named owner, transformation quietly becomes "everyone's project," which in practice means no one's.

The owner doesn't have to be the founder, but they need enough authority to pull people out of their daily routine for the pilot, and enough proximity to the process to notice when the team is quietly sliding back to the old way. IT alone rarely works as the owner — it optimizes the system, not the workflow. A purely bottom-up champion rarely works either — their authority runs out the moment the pilot needs a budget line or a policy exception.

The bigger risk isn't budget, it's silent resistance. People rarely say "I don't want this" out loud; they say "I'm too busy this week" for three months in a row. That's usually not a scheduling problem — it's a sign that the pilot threatens how someone's performance gets measured, or that nobody explained what happens to their role once the manual step disappears. Naming that risk early, and being honest that some roles will change, prevents more damage than any amount of extra training.

A practical rule of thumb: before you touch a tool, write two names next to the process you picked in step 2 — who owns the outcome, and who owns the day-to-day. If you can't fill in both blanks, you don't have a pilot yet, you have an idea.