When a mid-market company actually needs an ERP
An ERP introduction is not an end in itself. Many mid-sized companies notice only late that their grown IT landscape is slowing them down: isolated tools that do not talk to each other, spreadsheets acting as a shadow database, duplicate master data across CRM, inventory and accounting. The right ERP software for mid-market companies consolidates these processes into one system with a single source of truth. Clear signs that it is time to introduce an ERP: staff maintain the same record in several places; the monthly close drags because figures are pulled from several sources; quotes, orders and invoices are not linked end to end; or growth, new sites and regulatory demands can no longer be handled cleanly with the existing tools.
An honest pre-check matters: not every pain point justifies a new ERP. Sometimes it is enough to define one process cleanly or integrate two existing systems. An ERP project ties up money, people and attention for months, that investment must be justified by a real bottleneck, not by the feeling that you ought to modernise.
The phases of an ERP project
A solid ERP project runs through traceable phases. Each delivers a result the next one builds on:
- As-is analysis & goals: How do today's processes run, where do they break, and what should the ERP measurably improve? Without clear, prioritised goals, every later detail becomes a point of contention.
- Requirements & selection: Functional and non-functional requirements are documented and weighted. The software is chosen on that basis, ideally against real scenarios, not vendor feature lists.
- Concept & customizing: The target concept takes shape. The key decision falls here: which processes do we adapt to the software (use the standard), and which do we adapt to the company through customizing?
- Data migration: Master and transactional data are cleansed, mapped and transferred. This phase is almost always underestimated.
- Testing & training: Key users test against real business cases, defects are fixed, and staff are trained on their actual workplace, concretely, on their daily workflows.
- Go-live: The production start, cleanly planned with a cut-off date, clear responsibilities and a fallback scenario.
- Hypercare: The first weeks after go-live with heightened support, fast bug fixing and close guidance for users.
Big bang or phased?
In a big bang, the entire ERP goes live on a single cut-off date. That is fast and avoids drawn-out parallel operation, but it concentrates all the risk on one day, if something goes wrong, the whole company is affected. A phased rollout introduces modules or sites one after another. That lowers the risk per step and allows lessons to be applied, but it extends the project timeline and forces temporary dual maintenance and interfaces between old and new systems.
There is no blanket recommendation. For a compact organisation with clear processes, the big bang can be the more pragmatic route; with many sites, complex workflows or limited internal IT capacity, the phased variant is usually the more robust choice. What decides it is an honest assessment of your own risk tolerance and ability to absorb disruption.
Cost drivers and why projects fail
Licence or subscription fees are rarely the biggest item. The real cost drivers of an ERP introduction are customizing, data migration, training and ongoing operation (hosting, maintenance, further development). Budgeting only for the licence plans the project wrong. Customizing in particular is treacherous: every special case raises not just the rollout cost but the burden on every future update.
The most common reasons for failure are, in our experience, organisational rather than technical:
- No process owner: Nobody decides bindingly how a process will run in future. Without that accountability, every discussion peters out.
- Poor master data: Duplicates, gaps and inconsistent formats from the legacy system are taken over unchecked and poison the new ERP from day one.
- Scope creep: The functional scope grows uncontrollably as every department adds one more requirement. Timeline and budget overrun, and focus is lost.
- Too much custom instead of standard: Rather than adopting proven standard processes, the software is bent to every historical habit. That is expensive, error-prone and makes later updates hard.
Why Odoo is often a pragmatic base
For many mid-market companies, Odoo is a pragmatic starting point. Its modular design lets you start small, say with sales, purchasing and accounting, and add areas like inventory, projects or manufacturing later without switching systems. The broad standard scope covers many processes without coding from the outset, and its adaptability allows targeted customizing exactly where the company genuinely differs from the norm. As an open-source platform, Odoo can also run on your own infrastructure where data sovereignty is required, the same stance with which we run AI systems on our own servers in Germany. In ERP development, it has proven wise to respect the standard as the baseline and to build out only the real differentiators individually.
For German requirements, accounting with a DATEV interface is central: tax advisers expect data in a format their practice software can process. Odoo ships a DATEV export through its German localization, but it has to be set up properly and configured for your own chart-of-accounts logic (for example SKR03/SKR04); depending on requirements, additional modules may be needed. An ERP that fails to bridge this reliably creates permanent manual overhead. Whether the chosen format and posting logic meet your tax adviser's expectations and the GoBD rules is something you should always confirm with the practice, we deliberately make no blanket compliance guarantee.
Change management, realistic timelines and outlook
An ERP changes how people work every day, which is why change management is not a soft add-on but mission-critical. Early involvement of key users, transparent communication about the why, and training on concrete workflows decide whether the system is adopted or quietly worked around. The realistic duration of a rollout depends heavily on scope, data quality and the depth of customizing; a focused project that sticks to the standard goes live noticeably faster than one that maps every special requirement individually. The honest answer here is not a blanket figure but an estimate calibrated to your own processes.
In the medium term, the focus shifts from the rollout itself to continuous evolution: a modern ERP is not a one-off project but a platform that grows with the company, and increasingly offers entry points for automation and AI on your own data, without that data ever having to leave the house.