Every business system has two prices. The one on the quote, and the one paid in hours by your own people while the system is being set up. The second is larger, it is never on the quote, and it lands on exactly the people you can least spare — the ones who know how the business actually works.
No statistics here. This is what the work consists of, so you can plan for it.
Where your hours actually go
Deciding how things should work. Any configurable system asks questions the vendor cannot answer: what statuses a project can have, who approves a discount, what happens when an order is partly delivered. These are decisions about your business, and they take meetings with people who have opinions.
Cleaning up data. Every migration exposes the same thing: duplicate customers, three spellings of the same supplier, records with missing fields nobody noticed because nobody looked. Cleaning is unglamorous, it cannot be delegated to the vendor (only you know which of the three is right), and it is the task most likely to be underestimated.
Testing with real cases. Not “does the button work”. Does your strangest recurring case go through the system correctly? Every business has half a dozen of them, and they are usually the reason the old process had a manual step.
Learning it. Not a training session: the fortnight afterwards, when everybody is slower because they are thinking about the tool as well as the work.
Running two systems. During the changeover you are keeping the old thing alive as well as the new one. Plan for it and it’s an inconvenience; don’t and it’s a crisis.
Who pays it
The heaviest hours fall on the person who understands the current process best. That is usually someone senior in operations or finance, already fully occupied, and the one whose absence from normal work is most visible.
The practical consequence: if nobody’s normal workload is reduced for the duration, the implementation will be done in the gaps, and it will take much longer than planned. Not because the software is hard, but because the people are busy.
How to make it smaller
Narrow the first phase. One process, live, with real data, beats a comprehensive configuration nobody has tested.
Decide your defaults before the project starts. The decisions above are yours regardless of vendor. Making them early removes the most common cause of delay.
Clean data before you migrate, not during. The migration is when errors get multiplied.
Name one person to decide. Implementations stall on unmade decisions more than on technical problems. Someone needs the authority to settle a question in a day.
Ask the vendor what they need from you, in hours. A supplier who has done this before can tell you roughly how many hours of your team’s time each phase takes. One who says “very little” either hasn’t done it or isn’t telling you.
The question to ask before signing
Not “how long will this take you?” but “how many hours of my people’s time will this take, from whom, and in which weeks?” The answer changes the plan, and the willingness to answer tells you what kind of supplier you are dealing with.
If you’re planning one: implementation and deployment.