Everything that follows in an ERP project depends on the quality of the requirements workshops. A good workshop produces a description of the process that everyone recognises, a list of the exceptions that will otherwise appear at go live, and a set of decisions that the configuration can follow. A poor one produces a wish list. Here is how we run them.
Before the workshop
We ask for three things in advance. A description of the process in a few lines, from whoever owns it. Examples of the documents it produces: a quotation, an order, a delivery note, an invoice, a report. And the volumes: how many of each per month, how many exceptions, how many people involved.
We also ask who will attend. The rule is that the people who do the work must be in the room, alongside the manager who owns the process. A workshop with managers only produces the theory. A workshop with doers only produces the practice without the intent. You need both.
Who attends
For a sales process, that means a salesperson, whoever prepares quotations, whoever enters orders, and the sales manager. For accounts payable, it means whoever receives invoices, whoever matches them, whoever approves and pays, and the finance lead. Four to six people is the right size. More than eight and the quiet ones stop speaking.
From our side, a consultant who leads and a second person who writes. The writer matters. The output of the workshop is the written record, and it cannot be produced from memory afterwards.
The agenda
A half day per process area is the usual length. The structure is the same every time.
Walk the happy path
Start with a real, recent example and follow it from trigger to completion. Who does what, in which system, with which document. Draw it as you go.
Find the exceptions
For each step, ask what happens when it goes wrong. The customer changes the order. The supplier short ships. The payment does not match. These are the requirements that matter most and that managers rarely mention.
Identify the workarounds
Ask where the spreadsheets, shared inboxes and paper forms are. Each one marks a place where the current system does not fit the business.
Separate must from should
For each requirement, ask whether the business would change the process to fit standard software. The answers divide requirements into those that drive configuration and those that drive customisation.
Show Odoo
Where the process is clear, we run it in a demo database on the spot. Seeing the standard flow prompts questions that a description never would.
Agree the open points
List what could not be decided in the room, who will decide it and by when.
What we write down
The record from each workshop has the same shape. The process as described, step by step, with roles and systems. The exceptions and how they are handled today. The workarounds. The requirements, numbered, each marked as fit, partial fit or gap against standard Odoo, with a proposed approach. The decisions taken. The open points with owners and dates.
The record goes to every attendee within two days, and they correct it. A requirement that survives that review is one the business has agreed to, which is a different thing from one a consultant heard.
Common mistakes
Letting the workshop become a demonstration of Odoo before the process is understood. Allowing one voice to describe the process for everyone. Accepting "it depends" without asking what it depends on. Writing requirements as features rather than as outcomes: "we need a field for X" rather than "we need to know X at the moment we decide Y". And skipping the exceptions because the happy path took all the time.
Why this matters more for Odoo
Odoo can be configured in many ways to achieve the same result. The workshop is where the right way for your business is chosen. Spend the time here and the configuration is quick. Skip it and the configuration is quick too, and then it is redone.
We run these workshops as the first phase of ERP consulting and of every implementation. If you would like to see how one would work for your business, ask us.
Frequently asked questions
What is the difference between ERP consulting and Odoo implementation?
Consulting decides what the system should do and how the project should be structured. Implementation builds it. Consulting produces requirements, a gap analysis, a concept and a roadmap with an estimate. Implementation produces a configured, tested, live system. Consulting can stand alone, for instance when you are still choosing a system; when we implement, it forms the first phase of the project.
Will you recommend Odoo even if it is not the right fit?
No. If your requirements point to a different system or to keeping what you have, we say so. Our consulting fee does not depend on a subsequent implementation, and the recommendation reflects that.
How long does the consulting phase take?
For a single company with a handful of processes, a few weeks from first workshop to roadmap. For groups with several entities and many processes, two to three months. The length is driven by the number of business areas and how quickly your team can attend workshops and review documents.
What do we need to provide?
Time from the people who do the work, in half day workshops per business area, and a few hours per week from a project lead who can make or obtain decisions. Examples of your documents and reports, and access to your current systems or exports from them. The more of this is ready before we start, the faster the phase runs.
What do we receive at the end?
A requirements document per business area, a gap analysis against standard Odoo with a recommended approach for each gap, a target concept your team has validated in a demo database, and a phased roadmap with an estimate and the internal resources each phase needs. These documents are yours whether or not we go on to implement.
