Digital transformation without the chaos
The chaos around transformation is not in the change but in the big-bang cutover, and in handing the work to IT as if it were a server swap. A phased approach spreads the risk instead of piling it onto one weekend.
- Published
- Author
- Konis Software
“Digital transformation” is a phrase that unsettles anyone who has survived one. Not because of the software, but because of the memory: the old system switched off on a Friday, the new one live on Monday, and a whole month stuck because a single migrated balance would not sit right. The chaos they remember is not a property of the change — it is a property of the method used to force it.
The second source of chaos is quieter and more expensive. Transformation is handed to IT as if it were a server swap. IT ships a system, trains a handful of people and closes the project — while the business carries on as before, in parallel spreadsheets nobody officially admits to. The system is “in”, and nothing has transformed except where the same mess is now kept.
This piece is about getting the change done without that weekend and without those spreadsheets: in phases rather than one cut, with a single source of truth as the first goal, a deliberate order of processes, and a measure of progress that does not flatter. None of it is new — it is just rarely done, because it is harder than buying licences.
The chaos is in the big-bang, not in the change
A big-bang cutover demands that everything be correct at the same instant: master data cleaned, opening balances carried over, integrations wired, people trained, tax mappings set, open items reconciled. Each of these can fail on its own without much harm. When they all have to land on the same day, the first failure takes the whole monthly close hostage — and the deadline for a VAT return does not move because a migration did not settle.
- Master data: an item catalogue, counterparties with correct tax IDs, a chart of accounts free of duplicates.
- Opening balances: open receivables and payables, stock by location and by lot, unmatched advance payments.
- Tax mappings: the link between accounts and VAT-ledger boxes, rates by effective date, the treatment of non-deductible costs.
- People: an accountant who knows where the button is on the first morning a statement arrives — not after training that ended before the real cases appeared.
Why ‘transformation’ fails as an IT project
A project has an end date; a business does not. Run transformation as an IT delivery and success gets measured by whether the system works, not by whether the work changed. The system goes live, the project closes, and only a quarter later does it show that accounting still keeps the numbers that matter in a spreadsheet on the side — because it does not trust the system, or cannot yet drive it.
Symptoms of a hijacked transformation
- A parallel spreadsheet where the state is “really” kept, with the system topped up afterwards so the report looks tidy.
- Whoever decides what counts as “done” does not do the posting — so done means installed, not used.
- Training was a one-off event before go-live rather than support through the first two or three closing periods, when the awkward cases surface.
- Change requests pile up with IT because the process was never described before it was configured — so the system bends around a misunderstanding.
The owner is the process, not the system
A transformation that holds has an owner in the business, not in IT: someone accountable for the invoice actually being posted in the system, the statement actually being matched there, the VAT return being built from postings rather than from a spreadsheet. IT makes the tool work; whether the tool is used is a business decision, measured in the business. Without that owner, every hard case ends up as an exception done “for now” by hand — and “for now” is the most permanent state in any company.
A system that runs perfectly and that nobody uses for real work is not a successful transformation — it is an expensive place to keep a copy of data that still lives somewhere else.
A single source of truth is the first result, not the last
Before automation, and before anything called AI, the real payload of a transformation is mundane: every number has one place where it lives. Stock is not read from three spreadsheets that drift apart; a customer's balance is the same in sales and in finance; the VAT figure for the return comes out of the postings, not from a separate calculation nobody can reproduce next month. A parallel spreadsheet is the most reliable sign that this source is missing — it grows not out of stubbornness but out of mistrust, so it is retired not by banning it but by removing the reason for it.
In the Serbian setting, part of that source is already imposed from outside, and that helps. The e-invoicing system (SEF) is the one official registry for invoices, so an inbound or outbound invoice is not kept in two places — the system takes it from there. The VAT records (POPDV) and the return (PP PDV) are assembled from those same postings rather than re-keyed. Where the state mandates one registry, transformation has less to do; the trouble is the numbers nobody holds from outside — stock, margins, advances — and that is exactly where parallel spreadsheets multiply.
Which processes first, and which deliberately last
The order is not a matter of taste. First should be a process with high volume and few exceptions, a clear owner and a measurable outcome — it earns trust quickly and teaches the team on easy cases. The hardest process, the one the company argues about, goes last: not because it does not matter, but because failing at it early destroys confidence in the whole undertaking. Starting with the process that “hurts most” is the classic trap — it hurts most because it is the most complex and the most contested, which makes it the worst place to teach a new system and a new team.
| Process | When | Why in that order |
|---|---|---|
| Supplier invoices and posting | First | High volume, a clear rule, and the outcome shows up at once in the ledger |
| Bank statement matching | Early | Structured input (the model 97 reference) builds trust in automation fast |
| Sales and collection | Middle | Leans on the customer opening balances carried over first |
| Inventory and warehouse | Middle | Needs a clean catalogue and lots before it is worth switching on |
| Production costing and complex calculations | Last | The most exceptions and human agreements — the highest risk to carry at the start |
Measuring progress so the measure does not lie
The progress of a transformation is not measured by the percentage of modules installed, but by how much work actually lives in the system. The most honest indicator is the most prosaic: the count of parallel spreadsheets falling toward zero, and the share of documents that enter the system as their first home rather than being re-keyed from another source. A list of exceptions done ‘for now’ by hand that never shrinks is not a list — it has quietly become a process.
A practical order of steps
- 1
Describe the process before you configure it
Write down how the work goes today: who enters, who approves, where it stalls. The system is set up against a described process; a process first defined through the act of configuring the system always ends up as somebody's assumption.
- 2
Clean the master data before migrating
Duplicate counterparties, wrong tax IDs and dead items do not become correct by crossing into a new system — they just move. Cleaning before migration is the dullest and most profitable step.
- 3
Carry balances over, then run in parallel for one period
Instead of a cut, let the new and old systems run side by side for one closing period on the chosen process. A discrepancy that surfaces there is cheap; the same discrepancy after the old system is gone is an investigation.
- 4
Release one process, stabilise it, then the next
The next process does not start until the previous one runs without daily hand-holding. Two processes in flux at once produce chaos that cannot be attributed to any single cause.
- 5
Retire the parallel spreadsheet on purpose
A spreadsheet is not retired by decree but when the number in the system stops differing from it. The date the spreadsheet is switched off is the real date that part of the transformation is done.
- 6
Keep the business owner to the end
The project closes; the process remains. Someone from the business has to go on being accountable for new exceptions being solved by a rule in the system, not by a new spreadsheet.
How NG One approaches it
NG One is built so that a phased approach is the default rather than the exception. Spaces are meant to come online one at a time — finance and compliance before production costing — while the core is shared, so statement matching and posting do not wait for the whole system to be “finished”. A single source of truth is designed into the data model: balance, stock and VAT records are read from the same postings rather than from parallel views, so there is no place where two numbers can drift apart. SEF, POPDV and PP PDV are assembled from those postings, which means part of the single source of truth arrives from the legal framework itself.
The conclusion is not that transformation should be slow. A phased approach is no slower than a big-bang cut — it only spreads the risk so that no single failure brings the whole thing down. A company that starts with one process, gains one source of truth and switches off its first parallel spreadsheet has transformed more than a company that “installed a system” and went on living in the spreadsheets beside it.