How to implement an ERP without stopping the business
Moving to a new system does not have to be an event with a date and a knot in the stomach. It can be a rehearsal repeated until it runs clean — and only then does it become the move.
- Published
- Author
- Konis Software
ERP implementation is usually described as a jump: there is a date, before it the old system is used, after it the new one. That description is also the source of most of the unease, because a jump by definition has only two outcomes.
Serious implementations are not run that way. The cutover is repeated as a rehearsal — at full data volume, several times — and becomes the real cutover only once the rehearsal passes without surprises. What follows describes how that is reached, and what a company can prepare before it even picks a vendor.
Five phases that are not skipped
- 1
An inventory of processes, not of wishes
The first step is not a feature list but a list of what the company actually does — who starts what, who approves, where things wait. The system is chosen against that, not against the module count in a brochure. A company can do this alone, before any vendor meeting, and it is the most useful hour of work in the whole project.
- 2
Configuration over real data
Configuration done against invented examples looks fine and falls over on the first real case. Code lists, price lists and posting rules are set up over a copy of the company's actual data.
- 3
Migration reconciled to the last unit
Partners, items, opening balances and open items are transferred, then balances in the new system are compared with the old — exactly, not approximately. A discrepancy left unresolved now gets resolved later, when it costs more.
- 4
Trial cutover
The team does its real work in the new system, on real data, while the old one still runs. This is where what no analysis catches comes out: the steps nobody mentioned because they are taken for granted.
- 5
Go-live
Once the rehearsal passes without surprises, the cutover is an administrative act rather than an event. The date is chosen by the business calendar — never mid-close and never at a seasonal peak.
What a company can prepare in advance
These are jobs nobody but the company can do, and they shorten a project more than anything else. They are worth doing even if the vendor decision is six months away.
- **Clean the partner list.** Duplicates, dissolved companies and three spellings of the same name are the most expensive data to migrate, because every merge decision has to be made by hand.
- **Tidy items and units of measure.** The same item under two codes, and conversions that exist only in someone's head, will stop a migration.
- **Close what can be closed.** Open items from years ago that nobody will ever collect travel as ballast and confuse reconciliation.
- **Write down the rules everyone assumes.** Who may approve a discount above the threshold, when an order counts as confirmed, what happens to a complaint — if it is not written down, the system will have to assume.
- **Name a project owner.** One person with the authority to decide. Projects without one do not fail — they stall.
Risks and their counter-measures
| Risk | How it shows early | Counter-measure |
|---|---|---|
| Scope grows as you go | Every week brings one more requirement | A written scope with a list of what is NOT in it, and changes treated as decisions with a price |
| The data is not ready | Migration slips a second time | Reconciliation to the last unit as a condition for the next phase, not a formality |
| Key people have no time | Meetings move, decisions wait | The team's time planned up front as a project item, not as goodwill |
| The team stops using the system after go-live | The spreadsheet still gets opened for the same job | Role-based training on real data, and switching the old flow off on a date |
| Cutover at the wrong moment | The date lands in a close or a season | The calendar is chosen before everything else |
Parallel running: how long and why
The period of working in both systems is the most expensive part of the project in hours and the cheapest insurance available. There is no universal length — one full business cycle is a reasonable minimum, because only at period close does it become clear whether the postings really produce what they did before.
What is universal: parallel running must have an exit criterion written in advance. Without one it either ends too early out of fatigue, or drags on for months because nobody dares declare it finished.
What implementation cannot fix
It is fair to say this too, because most disappointment is born of an expectation no system meets. Implementation does not fix a process the company has not agreed on. If two departments understand differently when a job is finished, the new system will only make that difference faster and more visible.
That is in fact the benefit, only an uncomfortable one: an ERP is the best diagnostic tool a company can buy, but it still has to accept the diagnosis itself.