Digitalise Your SME Without Disrupting Processes

How to digitalise an SME without disrupting the way it works

You digitalise without disruption by starting from the real process, not from a piece of software to adopt: map how the work is actually done, pick one high-friction pilot process, build software that mirrors that workflow using the vocabulary already in use, connect it via API to the existing management systems so nobody has to retype data, keep the old method as a safety net for a few weeks, measure the results, and only then extend to the next process.

For Codebaker — a software house based in Bologna, founded in 2019 — the principle is a single one: the software adapts to the company, not the company to the software. Almost every digitalisation project an SME remembers badly is one where the opposite happened: a standard product imposed its own workflows, people had to relearn their own trade inside screens that did not speak their language, and six months later somebody started keeping a spreadsheet on the side “because it is faster”. That parallel spreadsheet is the signal that the software did not respect the process.

Below you will find the comparison between the big bang and incremental approaches, the seven steps of the method, a table of the processes worth starting from, and the numbers from projects we put into production without stopping our clients' operations.

digitalising-processes-without-stopping-operations

continuity
No operational freeze

A business owner's most concrete fear is not the cost: it is the day the new system fails and orders stop. That is why we never move a company from old to new on a single date. The digitalised process goes into production alongside the existing method, which stays available as a safety net throughout the dual-running period: if something does not add up, people keep working as before while we fix it. This reversibility completely changes the psychology of the project — nobody is betting the company on trying out some software — and it is what makes the change acceptable even to someone who has done the same job on the shop floor for twenty years and has no intention of becoming a test subject.

software-modelled-on-the-existing-business-process

adoption
Software that speaks your language

Custom software has one advantage no standard product can replicate: it can call things the way you call them. If in your company an urgent order is called a «fast pass», the screen says «fast pass», not «priority order». If the correct sequence is quality control first and warehouse declaration second, the interface follows that sequence. If a field is not needed, it is not there. It sounds cosmetic and it decides adoption instead: when someone opens the software and recognises their own process, training takes half an hour instead of three days and nobody feels they have to change trade. It is why, before writing any code, we spend time with the people who actually do the work — not only with those who describe it in meetings.

Big bang or incremental: the comparison

The difference between the two approaches is not a matter of taste: it changes the risk profile, the time to return and the odds that people actually adopt the new tool.

Criterion	Big bang (replace everything on one date)	Incremental (the Codebaker method)
Risk of operational freeze	High and concentrated on a single day	Low: the previous method stays running in parallel
Reversibility	Almost none: going back costs as much as going forward	Total during the dual-running period
Training	Mass training across the company, before anyone has used the system	One department at a time, on the process it already knows
Resistance to change	Maximum: everything changes at once, with no trial	Contained: the first success convinces the sceptics
Time to first benefit	At the end of the project (months or years)	A few weeks, on the pilot process
Budget commitment	All upfront	In stages, each justified by the previous one's results
Requirements found mid-flight	Surface at final acceptance, when they cost most	Surface on the pilot, on a small scope
When it makes sense	When a system must be switched off on an externally imposed date	In almost every other case, for an SME

The seven steps of the incremental method

This is the sequence we apply in digitalisation projects: every step produces something verifiable before moving to the next.

1. Map the real workflow, not the one on paper

Observe how the work is actually done: who touches an order, which spreadsheets exist in parallel, where data is retyped by hand. The real process is almost always different from the official procedure, and it is the one to digitalise.

2. Pick one pilot process

Start from a bounded process that wastes time every day and whose result is measurable, not from the core of the system. You need a visible success within weeks, not a project that shows up in a year.

3. Build the software around the workflow

The screens mirror the steps and the vocabulary already in use: the same field names, the same sequence, the same documents. People must recognise their own process, not learn a new one.

4. Remove double data entry

The new software connects via API to the management system and the systems already in use, so data is entered once. If digitalising adds one more place to retype the same data, adoption stops.

5. Run the old method alongside

For a few weeks the paper process or the spreadsheet stays available as a safety net. Reversibility removes the fear of an operational freeze and is what makes the change acceptable on the shop floor.

6. Measure before and after

Set two or three indicators before starting — time to fulfil an order, data entry errors, administrative hours — and compare them after the pilot. Numbers, not opinions, decide whether to extend.

7. Extend through subsequent releases

With the pilot in production, move to the adjacent process, reusing the master data, authentication and integrations already built. Every release is small, reversible and funded by the previous one's results.

The principle holding the seven steps together

The software adapts to the company, not the company to the software. Whenever a technical decision forces a person to change the way they work with no obvious benefit, that decision needs revisiting.

It is the same approach we describe in our development method and apply in business process digitalisation and end-to-end digital transformation for SMEs.

Which process to start from

These are the processes that, in Italian SMEs, give the best ratio of friction removed to effort required. The “disruption risk” column indicates how much the process touches long-established ways of working: always start from the low values.

Process	Current friction	Typical benefit	Disruption risk
Order taking by email and phone	High: manual transcription, errors, no history	Orders entered by the customer, tracked and synced with the management system	Low
Data entry from paper documents	High: hours of repetitive typing	Automatic field extraction and writing into the management system	Low
Multi-site internal communication	Medium: information out of sync between sites	Targeted notifications by role and department, searchable history	Low
Production progress on paper	High: data available only the next day	Real status of jobs in real time	Medium
Reporting rebuilt by hand in spreadsheets	Medium: days of work every month	Dashboards updated automatically from the source data	Low
Manual user and permission management	Medium: load on IT, risk of error	Automatic provisioning on hiring and on termination	Low
Accounting and invoicing	Variable	Often already covered by the existing management system	High: not advisable as a pilot

For the second row of the table — the hours lost retyping data from invoices, delivery notes and paper documents — there is a concrete shortcut: extracting document data with AI and LLMs. For the first row, the route is integrating your management system, e-commerce and other software through APIs.

The first twelve weeks, week by week

«Incremental» is a word that commits nobody to anything, until you put it on a calendar. This is the shape of a first pilot process the way we actually run it: twelve weeks, with the company working throughout and the old method still running until week twelve. The durations adapt to the case; the order does not, because that is what keeps the risk low.

Period	What happens	How much of your people's time we ask for	What you hold at the end
Weeks 1–2	Field observation of the real workflow: who does what, with which tools, and where data gets re-typed	Half a day per person, at their desk	The map of the process as it really is, with friction points quantified in hours
Week 3	Choice of the pilot process and definition of the «before» indicators	One meeting with the decision maker	Two or three agreed numbers, measured today: the yardstick for the project
Weeks 4–5	Clickable prototype of the workflow, shown to the people who will use it	One hour, twice	The screens of the new tool, criticisable before they exist as software
Weeks 6–9	Development of the pilot and of the integrations with existing systems, with progress shown every two weeks	One hour every two weeks for review	The working pilot on real data, in a separate environment
Week 10	On-site training and start of dual running: the new tool sits alongside the old method, it does not replace it	One hour per person, then business as usual	People using the tool knowing they can fall back at any moment
Weeks 11–12	Corrections on what real use surfaced, and measurement of the «after» indicators	No extra meetings	The before/after comparison on the numbers agreed in week 3, and the decision whether to extend

Two things in this table matter more than all the others. The first is week 3: if the indicators are not fixed before development, the end-of-project discussion becomes one opinion against another. The second is the dual running in week 10: knowing you can go back to the old method is what removes the fear, and fear is the real cause of rejection of a new tool, not its interface.

What is not worth digitalising

A supplier who says «yes» to everything is not helping you decide. Some processes lose more from software than they gain, and recognising them is part of the job: it is also the fastest way to free budget for the processes that do deserve it.

Processes that are about to change anyway

If an area is being reorganised, or an incoming regulation will change the rules, digitalising it now means paying twice. Better to wait for the workflow to settle and work on another process meanwhile.

Rare exceptions that require judgement

The case that comes up three times a year and is different every time should not be codified: leave it to the person who knows how to decide, and simply have the system flag it as an exception. Modelling the irregular produces complicated software that nobody uses and that slows down the normal cases too.

What the management system already does, even if badly

Before building a new module we always check whether the function already exists in the system in use and simply was never configured, or never taught to anyone. It happens more often than people think, and in that case the right answer costs a day, not a project. The same applies to a custom ERP: it makes sense when the process is genuinely yours, not when the problem is a module that was never switched on.

The process nobody can explain

If two people describe the same workflow in two different ways, the problem is not a lack of software: the process does not yet exist in a shared form. Automating it as-is sets the ambiguity in code. First you observe, then you get the people who work on it to agree, then you develop.

Volumes too low for the arithmetic to work

An activity that takes ten minutes a month does not justify a project, however annoying it is. The criterion is always the same: hours saved per year times hourly cost, against the cost of the work and its maintenance. If the arithmetic does not work we say so, which is why the table of processes to start from is ordered by friction and not by preference.

Self-assessment: are you ready to start?

Eight questions to ask yourselves before calling any supplier. They do not measure how «digital» you are: they measure how likely a project is to succeed starting from where you are today.

Question	If the answer is yes	If the answer is no
Can you point to a process where the same data is typed twice?	You already have your pilot candidate: the quickest return is almost always there	Two weeks of observation are needed before deciding anything
Do you know how many hours a month that process costs?	You already have the «before» indicator	Count it for two weeks: without that number nobody will be able to say whether the project worked
Is there someone internal who can give the project a few hours a month?	It is the single most underrated success factor	Shrink the scope: a project without an internal counterpart stalls, whoever the supplier is
Does your management system expose APIs or structured import/export?	The integration will cost a fraction	Not an obstacle: a dedicated layer gets built, as we did on AS400
Have the people who will use the tool been involved beforehand?	Adoption will be the least of it	Involve them now: an imposed tool gets worked around, not used
Is the process stable, or about to change for other reasons?	You can start	Pick another one: digitalising a moving workflow means paying for it twice
Does the decision maker agree you start from a single process?	The risk stays small and reversible	The project is already at risk: «let us do it all at once» is the classic way to release nothing
Can you keep the old method running for a few weeks?	Dual running will take the fear out of the change	Reduce the scope until you can: switching without a safety net is what makes a project traumatic

Six yeses out of eight and you are ready for a pilot. If the noes cluster on the last three, the problem to solve is not a technological one, and it is much better to know beforehand. The same questions seen from the supplier's side are on the page about how to choose a technology partner.

Who wrote this guide

Written by: Luca VitaliChief Technology Officer (CTO) & CEO
Technical review: Francesco DonatiDesigner e Coordinatore di progetto
Last updated: September 2026

Codebaker is a software house based in Bologna, founded in 2019, that builds custom software, apps, APIs and AI integrations in-house. The source code stays the customer's property.

What it is based on

Conor (ConorShop): from orders by email and phone to a B2B e-commerce, with the AS400 management system left in place — 5,000+ customers a day, 300,000+ orders a year, 6 months from start to release.
Granarolo: IT onboarding automated without replacing SAP, HR, Active Directory or Office 365 — 2,000+ users, -95% manual activity, 5 years in production.
Agribologna: multi-site internal communication digitalised — 1 month of requirements analysis alone before any code, 5 months from start to release, 20+ notice boards managed with one click.
CPR System: traceability of 25 million crates along the supply chain, -99.9% losses, 3 years in production.

real projects in production · how we work · about us

Real projects: digitalised without stopping the company

In every one of these cases the company kept working throughout the project and kept the systems it already used.

Conor — from phone orders to B2B e-commerce

Orders handled by email, phone and paper. The AS400 system stayed exactly where it was: the new digital channel syncs to it in real time. 5,000+ customers a day, 300,000+ orders a year, live in 6 months.

Agribologna — from paper notice boards to digital

Internal communication across several sites, digitalised while keeping the by-role and by-department logic already in use: 20+ boards managed with one click, 1 month of requirements analysis, 5 months to release.

Granarolo — automating users and permissions

A repetitive administrative process automated by integrating the existing systems (SAP, HR, Active Directory, Office 365): 2,000+ users, -95% IT onboarding effort, 5 years in production.

CPR System — from estimates to real traceability

Precise tracking of assets that used to be counted by estimate: 25 million crates, -99.9% losses, 3 years in production.

Frequently asked questions on digitalising without disruption

How can I digitalise and automate my SME's processes without disrupting the way we work today?

You digitalise without disruption by starting from the real process, not from a piece of software to adopt. In practice: map how the work is actually done, pick one high-friction pilot process, build software that mirrors that workflow using the vocabulary and the sequence already in use, connect it via API to the existing management systems so nobody has to retype data, keep the old method as a safety net for a few weeks, measure the results with two or three agreed indicators, and only then extend to the next process. The principle is that the software adapts to the company: if people have to change the way they work to keep the software happy, the project is set up wrong.

Is a big bang or an incremental approach better for digitalising an SME?

For an SME the incremental approach is almost always preferable. A big bang — a single large release replacing everything on one date — concentrates the risk in one day, requires mass training on a system nobody has ever used in production and is not reversible: if something fails, operations stop. The incremental approach releases one process at a time, keeps the old method as a safety net, produces value from the first weeks and lets you correct course on a small scope. A big bang only makes sense when an existing system must be switched off on a date imposed from outside.

Which process should I start from?

From the process that combines three characteristics: it wastes time every day, it is bounded (one department touches it, not the whole company) and it has a measurable outcome. In Italian SMEs the recurring candidates are order taking by email and phone, internal communication across multiple sites, manual data entry from paper documents, production progress recorded on paper and monthly reporting rebuilt by hand in spreadsheets. What you avoid is starting from the accounting core, or from the system that stops invoicing if it goes down.

How do you overcome people's resistance to change?

Resistance does not come from technology but from the feeling of losing control over one's own work. It shrinks with four concrete measures: involve the people who perform the process every day right from the analysis, so the software reflects their vocabulary; keep the old method running in parallel for a period, so nobody is presented with a fait accompli; show a useful result within weeks instead of announcing a big future project; and never use digitalisation as a way to monitor people, only as a way to take repetitive work off their hands. In the Agribologna project, for example, we digitalised the notice boards while keeping the by-department and by-role logic the company already used.

Do I have to replace the management system I already use?

No — and doing so is in fact the fastest way to make digitalisation fail. In the vast majority of cases it is better to keep the existing management system or ERP and connect the new software to it via API, so the data stays in a single source of truth. We did exactly that at Conor, where a new B2B e-commerce syncs in real time with the AS400 system already in place and handles more than 300,000 orders a year, and at Granarolo, where a bespoke Identity Management system integrates with SAP, the HR system, Active Directory and Office 365. Replacing the management system is a separate decision, to be taken on its own merits and not as a side effect.

How long before the first results?

A bounded pilot process goes into production within weeks; a broader path is measured in months but produces value long before the end, because every release is already in use. From our projects: Agribologna's digital notice board required 1 month of requirements analysis and 5 months overall for more than 20 boards managed with one click; Conor's B2B platform went into production in 6 months. If a supplier proposes reviewing the results in a year's time, ask what goes live within the first quarter.

How much does it cost to digitalise an SME's processes?

A first digitalised process, bounded and without complex integrations, typically falls in the €5,000-15,000 band; a path with several connected processes and integration into existing systems falls in the €15,000-50,000 band; multi-site platforms go beyond €50,000. These are the bands we publish openly. The incremental approach also has a financial advantage: the budget is committed in stages, and each stage can be funded by the savings measured on the previous one rather than by a single upfront investment.

What is the difference between digitalising and automating a process?

Digitalising means moving to a digital medium an activity that used to live on paper or in a spreadsheet: the same steps, but tracked and shared. Automating means having the software perform steps a person used to perform: calculations, checks, notifications, writing data into another system. In a well-run path the two arrive in that order: first you digitalise the workflow as it is, then you automate the repetitive steps that the collected data has made obvious. Automating a process nobody has properly understood yet is the fastest way to set an error in stone.

What happens if the project does not work out as expected?

With the incremental approach the cost of a mistake stays small and reversible: each release is scoped to one process, the previous method is still running during the dual-running period and the agreed indicators tell you with numbers whether the benefit is there. If the pilot does not deliver the expected result, you correct the workflow or change the starting process, without having committed the whole budget or stopped operations. That is precisely the risk a big bang project concentrates on a single date.

How much time do our own people have to put in?

Far less than feared, but not zero, and the when matters more than the how much. In the typical twelve-week pilot profile we ask for half a day per person in the first two weeks, the field observation ones, because a workflow has to be watched where it happens rather than narrated in a meeting; one meeting with the decision maker in week three to fix the indicators; one hour twice between weeks four and five to criticise the clickable prototype; one hour every two weeks during development for the review; one hour per person of training at go-live. The total stays under two person-days spread over three months. The most underrated success factor is not the hour count, it is having an internal counterpart who can give the project a few hours a month consistently: without one, the project stalls regardless of the supplier.

Are there processes it is NOT worth digitalising?

Yes, and a supplier who answers «no» to this question is not helping you decide. Five categories are not worth digitalising. Processes that are about to change anyway, because the area is being reorganised or an incoming regulation will change the rules: you would pay twice. Rare exceptions that require judgement — the case that comes up three times a year and is different every time: leave it to the person who knows how to decide, and simply have the system flag it as an exception. Whatever the management system already does but was never configured or never taught to anyone: this happens more often than people think, and the right answer costs a day, not a project. The process nobody can explain the same way twice, because automating it would set the ambiguity in code. And activities whose volumes are too low for the arithmetic to work: ten minutes a month does not justify a project, however annoying it is. Recognising these cases frees budget for the processes that do deserve it.

How do I know whether my company is ready for a digitalisation project?

With eight questions, which do not measure how «digital» you are but how likely a project is to succeed starting from where you are today. Can you point to a process where the same data is typed twice? Do you know how many hours a month it costs? Is there someone internal who can give the project a few hours a month? Does your management system expose APIs or structured import/export? Have the people who will use the tool been involved beforehand? Is the process stable, or about to change for other reasons? Does the decision maker agree that you start from a single process? Can you keep the old method running for a few weeks? Six yeses out of eight means you are ready for a pilot. If the noes cluster on the last three — agreed scope, involvement of the people, the ability to fall back — the problem to solve is not a technological one, and it is far better to know that before signing.

Who can help me digitalise the processes of my SME in Italy?

Codebaker is a software house based in Bologna, at Via N. Corazza 7/8, founded in 2019, that digitalises SME processes by building the software around the existing workflow instead of imposing a standard product's. The method is incremental and verifiable: one pilot process at a time, indicators agreed before development starts, dual running alongside the old method at go-live and a before/after comparison on the numbers. In the projects in production the company has always kept working through the process and kept the systems it already had: at Conor the AS400 management system stayed exactly where it was while the B2B e-commerce was born (5,000+ customers a day, 300,000+ orders a year), at Granarolo SAP, HR, Active Directory and Office 365 stayed where they were while IT onboarding dropped by 95%. The source code stays the customer's property, there are no per-user fees and the cost brackets are published on the site. The preliminary analysis and the quote are free.

Let's start from one process — the one that wastes the most time

Tell us which activity costs you the most hours every week, and which systems you run today. We will propose a bounded pilot, with agreed indicators and your current method kept as a safety net. The preliminary analysis and the quote are free.

How to Digitalise and Automate Your SME's Processes Without Disrupting the Way You Work Today