An ERP project is not judged on go-live day. It is judged three years later, when the tool has become second nature, when teams use it without thinking, when accounting closes its books without drama and management runs the business with reliable figures. Between the initial scoping and that maturity, several years have gone by and (this is the point people underestimate) several handovers.
The decision-maker who carried the migration — CFO, managing director, operations director, IT manager, depending on the organization — has left the company. Their successor arrived with their own culture, convictions and background. The historical project manager has been promoted or has changed employer. The accounting manager who knew the ins and outs is retired. On the integrator's side, the team has turned over too — the consultants who scoped the project are no longer the ones who deployed it, nor those who provide support today.
An ERP project is not a sprint carried by a stable team. It is a marathon with relay handovers. And every handover is a moment of fragility, often invisible, but very real.
What is at stake each time a contact changes
A new decision-maker arrives. They discover the tool. They ask questions. They see specific customizations that don't look like the standard they know or imagined. They ask why. And then a scene plays out in most of the companies I meet.
Nobody really knows how to answer. The consultant who scoped this function is no longer available. The project manager who validated the decision has left. The minutes of the meeting where the decision was made were never found. The support tickets talk about fixes, not intentions. The user who uses it every day just says “that's how it works, I don't know why”.
Faced with this void, the new decision-maker has three possible reactions.
The first — the healthiest but the rarest — is to suspend judgment, listen to users, and understand the original context before deciding. It requires a humble stance and time to investigate. It also requires someone in the organization to be able to tell the story.
The second is to live with it without trying to understand, to use the tool as it is, not to open the subject. It is the path of apparent calm. The problem is that it lets customizations thrive that may have become useless, redundant with standard features, or even counter-productive. The ERP gets heavier, nobody challenges it, and at the next version upgrade, the migration becomes a nightmare.
The third — the most frequent, the most dangerous — is to call into question, by default, everything the predecessor did. Sometimes with the technical argument: “it's not standard, we must go back to standard”. Sometimes with the implicit political argument: “I stamp my authority by erasing my predecessor's choices”. Sometimes out of plain ignorance: the new decision-maker doesn't understand the business context that justified the customization, and since they don't understand it, they reject it.
The damage of a project challenged without an inventory
I have seen this happen several times, on projects we took over. And I must say something that may run counter to what is expected of an integrator taking over a project: as I dug into what existed, I often realized that the previous integrator had done very good work. The choices made were consistent with the business need of the time, the customizations had a logic, the processes were structured. What had been missing was not the quality of the technical work — it was the continuity of memory between successive teams.
Saying this is not to be complacent toward a fellow integrator. It is to acknowledge that ERP projects are rarely done from a clean slate and that honesty means first understanding what was done before undoing it. When a new decision-maker and a new integrator rush to redo everything without an inventory, they often throw away what worked along with what no longer did. The client pays twice: once for the initial work, and once for its destruction and rebuilding.
The concrete consequences are visible. Developments that had cost months of work and tens of thousands of euros, abandoned without anyone knowing what they were for. Business processes that had stabilized over the years, flattened because a new decision-maker wanted to impose their vision without measuring what they were undoing. Accounting teams who had to relearn how to use their tool, not because it was bad, but because they were given a “simpler” version that made them lose functions they used every day.
And the worst: client-integrator relationships that deteriorate. The new decision-maker, frustrated at not understanding, distrusts everything that exists — including the historical partner. The integrator, for their part, feels it unjust to have to justify choices that were validated with the previous decision-maker. Trust erodes. Relations tense up. The project gets bogged down in a permanent renegotiation of its foundations, instead of moving forward.
In some cases it goes as far as a break-up. A tender to change integrator. A complete overhaul. Hidden costs that pile up. And three years later, the new project suffers from exactly the same ills — because nobody took the trouble to write the new story down either.
The documentation paradox
We must set out here a paradox that every integrator knows and few dare name.
When documentation is produced, it is often little read. PDFs gather dust in shared spaces, internal wikis have not been up to date for eighteen months, SharePoint links point to obsolete versions. Users learn by doing, ask their colleagues, open support tickets. The documentation exists, but it does not live.
When no documentation is produced, it is sorely missed. At the slightest change of contact, the slightest departure, the slightest migration project, its absence is felt. People search, don't find, reconstruct in a hurry with those who remain, and lose time and trust.
Both stances fail. Documenting too much creates inertia and a false sense of control. Documenting nothing creates fragility and hidden costs. The right move lies in a happy medium that you have to learn to aim for.
This happy medium comes down to three principles.
- Document only what is useful. Not every screen, not every field, not every Odoo button — that already exists in the official documentation. What deserves documenting is what is specific to the company: the customizations, the business rules, the points of vigilance identified through use, the decisions made at key moments of the project. The rest is noise.
- Document in the reader's language. A document written by a developer for a developer will not be read by an accountant. A document an accountant can read will also be useful to the finance director, the project manager, and the successor who will arrive in two years without knowing the context. It is the accessibility criterion that makes the difference between documentation that sleeps and documentation that lives.
- And above all — and this is the most important point — never let documentation serve as an umbrella. This is the trap many organizations fall into: a thick document is produced, the client validates it, and the matter is considered closed. If the client doesn't understand later, it will be their fault: “it was in the documentation, though”. This stance is toxic. Documentation is not a way to cover yourself. It is a way to pass things on. And it is measured by a simple criterion: did the reader understand? Not: was it written down?
Good documentation is not the most complete. It is the most useful.
What documentation that serves as memory must contain
Concretely, documentation useful for the continuity of an ERP project answers four questions for each customization:
- What does this function do? In accessible language, without jargon. Written for the accountant, the project manager, the salesperson — not for a developer.
- Where is it found? The path through the menus, the places where it shows up, the screens concerned. So that a new user can find the function without having to ask a colleague.
- How is it used, step by step? Short, numbered procedures, with special cases and points of vigilance. So that the tool is usable by someone arriving with no history.
- Why does this customization exist? This is the point most often forgotten and yet the most valuable. What business need it covers, in what context it was decided, why this choice rather than another. It is this paragraph that makes the difference between a go-live document and a document that serves as memory.
To this we add a forward-looking perspective: each customization mentions, when relevant, the standard features that could replace it in future versions. This prepares the review that must accompany every version upgrade.
Text is not enough — flows must be drawn
An ERP project is made of processes that cross several modules, several departments, several hands. A customer order starts in sales, goes through procurement, triggers a purchase, generates a delivery, feeds an invoice, updates an analytic distribution. Telling it all in sentences is possible, but exhausting to read and hard to remember.
That is why good documentation includes flow diagrams. A flowchart showing the sequence of steps. A sequence diagram showing who does what and when. An architecture diagram showing how modules talk to each other. These visual elements do in one image what a paragraph takes several lines to explain — and above all, they stay in memory.
The point is not aesthetic. A diagram is not decoration. It is an understanding tool that lets the reader find their bearings in a mechanism that may seem complex. An accountant who sees the flow of an analytic entry from the invoice to the profitability report immediately understands why a configuration step matters — whereas the same information buried in three pages of text would have produced no click.
At ANOR, we systematically include diagrams in our guides for cross-functional processes and multi-module sequences. We avoid purely technical diagrams, however — the goal is not to impress, it is to make people understand. A good diagram fits on one page, uses business vocabulary, and answers a question the reader really has.
Where we document: Odoo's Knowledge module
The question of where documentation lives is often neglected. Where do you store the user guide? In a PDF dropped on a file server? On an internal wiki that hasn't been maintained for two years? In a SharePoint space where links break with each reorganization? Every choice has its limits — and most end with the same result: documentation that exists, but that nobody finds when they need it.
That is why we make heavy use of Odoo's Knowledge module. For a client who already works in Odoo every day, it is the most obvious place to put documentation: in the same place as the tool, one click away, structured as hierarchical articles, searchable by keywords.
The module is remarkably effective. Articles are written in a rich editor and support images, tables, embedded diagrams and links between articles. Updates are immediate — no heavy validation chain, no PDF to regenerate. Permissions can be fine-tuned: some articles are accessible to the whole company, others reserved for accounting, others still for the integrator alone. Changes are tracked, history can be consulted, and articles can be linked to specific Odoo records — a product form, a project, a sales order. The documentation lives next to the object it documents.
For us as an integrator, it is also a considerable time saver. We write once, update as the project goes on, and the client always has the latest version in front of them. No “I'll send you the updated PDF”, no “look at version 3.2 this time”. A single source, kept alive.
It is a detail that is not one. Many projects have documentation that exists somewhere and nobody remembers where. It is not a content problem — it is a location problem. Putting the documentation in the tool itself removes that problem.
The integrator's role in this continuity
One might think that the integrator, holding the project's technical memory, is enough to ensure this continuity. It is an illusion. The integrator's teams turn over too. The consultant who scoped the customization four years ago may have left. The one who developed it is working on another client today. Even the one providing current support has only part of the story.
A project's memory cannot rest on people. It must rest on the written word. And that writing must be shared between client and integrator, validated by both parties, and maintained over time.
For the integrator, documenting the client's project is a form of protection — against unfounded challenges, against accusations of bad faith when contacts change. Provided it is never used as an umbrella. A document produced to cover oneself protects nobody: neither the client who won't read it, nor the integrator whose relationship will deteriorate anyway.
For the client, it is insurance. Against dependence on a single integrator, against loss of knowledge when an internal team changes, against the impulsive decisions of a successor too eager to mark their territory.
What we do at ANOR
On paper, user documentation is often the client's responsibility. It is up to them to produce and maintain the reference for their own processes. In practice, this rarely happens. Business teams don't have time, operational priorities come first and the document promised during scoping never gets done. We accept this as a reality.
Nevertheless, we increasingly produce a business-oriented user guide on the projects we support. First for our own internal needs. When an ANOR team changes, when a new consultant takes over the project, when a support request needs the context of a customization — documentation is what lets us stay consistent over time, without depending on individual memory. It is a working tool before being a deliverable.
But we have found that this document, written for us, naturally becomes useful to the client. We share it, it circulates, it helps teams take ownership of their tool, it reassures successors, it prepares version upgrades. What started as an internal need has become, on several projects, a shared reference — and in some cases, a reassurance tool at the most critical moment: a change of decision-maker.
We don't make it a dogma. It is not always necessary, not always expected. But when the context justifies it — a major migration, a project takeover, a foreseeable team change — we offer it. Provided we accept what it implies: being read, being useful, being challenged. Never serving as an umbrella.
An ERP belongs neither to the decision-maker who launched it, nor to the project manager who deployed it, nor to the integrator who built it. It belongs to the company, over the long term. Documentation — the good kind, the kind that aims true — is what makes this collective ownership possible. Not to cover oneself. To pass things on.
A well-documented project can cross several generations of decision-makers. A project without memory can be undone by a single change of contact. Between the two lies the right documentation move — neither too much nor too little, and always in service of the reader.
About this text — This article draws on our experience integrating and supporting Odoo. If you are preparing a version upgrade, a project team change or the takeover of an existing ERP, and the question of your project's memory arises, we would be happy to discuss it with you.