What discovery should produce before anyone configures Odoo

The process described in a management meeting and the process running on the counter are rarely the same. The gap between them is where implementations fail, and it is only visible if you talk to whoever is actually holding the operation together — usually one person everybody quietly asks.

That person's workarounds are not noise to be tidied away. They are the requirements nobody wrote down.

People: who does this work, and who do they ask when it goes wrong. Process: how it really runs, shortcuts included. Data: which number is trusted, and where it gets retyped. Tools: what is already in use, and what stays after go-live. Bottlenecks: where the work stops and waits for one person.

Bottlenecks matter most, because they are what the client feels. Everything else is context for them.

A process map, so everyone is arguing about the same picture rather than their own memory of it. A gap analysis, saying where the current way and the intended way diverge — and which of those gaps are worth closing with software at all. And acceptance criteria, written before configuration begins.

If discovery produces none of these, there is nothing to check the build against later, and no way to tell scope creep from a misunderstanding.

A good discovery is as much about what stays out. Some processes are better left in the tool that already works; some are so specific that configuring them into a standard module produces something nobody can maintain.

Saying that out loud early is cheaper than discovering it during UAT, and it is usually the moment a client starts trusting the process.