The problem ERP solves
In an organization without a single database, the same supplier exists under three different spellings, the contract value in legal does not match the one in finance, and no one can say, without building a spreadsheet, how much was spent in a cost center last month.
This is not a failure of discipline, it is a consequence of architecture: when each area has its own records, diverging is the system's natural behavior. ERP goes after the cause, turning shared information into a single record, not a copy synchronized every now and then.
The sign that the time has come
It is not the size of the organization, it is the cost of reconciliation. Some concrete signs:
- A month-end close that takes days of skilled people's time pulling numbers together from different systems.
- Decisions that wait for a report, instead of looking at a dashboard.
- Audits where most of the effort goes into proving where the data came from, not explaining the decision.
- A critical spreadsheet that has become a system, with a single owner no one knows how to replace.
- A process that stalls because a piece of information is in a system the next area cannot access.
When two or three of these show up together, the cost of not integrating is already being paid, just in a diffuse way.
The mistake that sinks the project
It is almost always the same: treating the rollout as a technology project. The system goes in, the data is migrated, and the processes stay the same, now on a different screen. Six months later, the spreadsheets are back, because the process that generated them was never reviewed.
ERP changes who does what, in what order and with what information. If that conversation does not happen beforehand, it happens afterward, in the middle of the operation, and then it costs much more.
Big bang or in stages
Going live with everything at once is appealing, because it shortens the period when systems run side by side. In practice, it concentrates all the risk on a single day and requires the entire organization to learn at the same time.
A staged rollout coexists with the legacy for longer, and that takes work, but it allows the design to be corrected in the second module with what was learned in the first. For most organizations, the second option costs less overall, even if it looks slower on the schedule.
Data is the most underestimated part
Migrating dirty records to a new system produces a new system with dirty records, and also burns the organization's trust in the tool right at launch. Duplicate suppliers, cost centers that no longer exist, closed contracts still active: all of this needs to be dealt with beforehand, and it is work no one likes to budget for.
It is worth setting aside explicit effort for it in the plan. A project that treats migration as a technical task at the end of the schedule usually discovers the size of the problem when there is no time left.
How to measure whether it was worth it
Modules deployed measure nothing. What does:
- Month-end close time, before and after.
- Hours spent on reconciliation between areas.
- Time from need to fulfilled order, in the purchasing cycle.
- The percentage of decisions made with data from the system, instead of a parallel spreadsheet.
- Audit effort to trace a transaction end to end.
If parallel spreadsheets still exist after the rollout, they are the most honest indicator: the process was not solved, it was worked around.
FAQ
What is an ERP?
It is the system that unifies the organization's support processes, such as purchasing, contracts, finance, assets and people, in a single database. The value is not in having every module, but in no longer reconciling information that should be the same across different areas.
When is it worth implementing an ERP?
The criterion is not the size of the organization, it is the cost of reconciliation. A close that takes days pulling numbers from different systems, decisions that wait for a report, audits spent proving where data came from and a critical spreadsheet with a single owner are signs that the cost of not integrating is already being paid, just in a diffuse way.
Why do ERP projects often fail?
Because they are treated as technology projects. The system goes in, the data is migrated and the processes stay the same, now on a different screen. Six months later the spreadsheets are back, because the process that generated them was never reviewed. ERP changes who does what and in what order, and that conversation happens either beforehand or afterward, in the middle of the operation and at a higher cost.
Is it better to implement everything at once or in stages?
Going live with everything concentrates the risk on a single day and requires the entire organization to learn at the same time. A staged approach means more work running alongside the legacy, but it allows the design to be corrected in the second module with what was learned in the first. For most organizations, it is cheaper overall, even if it looks slower on the schedule.
What gets in the way most when migrating to an ERP?
Data quality. Migrating dirty records produces a new system with dirty records and burns trust in the tool right at launch: duplicate suppliers, defunct cost centers, closed contracts still active. This needs explicit effort in the plan, not a technical task at the end of the schedule.
Ready to raise your operational maturity?
Discover the CITSmart platform and how Central IT helps run technology, services and business with governance.