/services/business-consulting
Process work that survives contact with your P&L.
Discovery, current-state mapping and a phased roadmap — for operational problems that may or may not turn out to be software problems.
- 180+ operations examined
- 14 countries
- 0 obligation to implement anything
Facts. - 180+ · operations examined - 14 · countries - 0 · obligation to implement anything
/the-problem
Most process problems are described as system problems.
The request arrives as software. We need better reporting. We need to replace the ERP. We need a dashboard the board can see. Underneath, roughly half the time, is something else — a handover between two departments that nobody owns, a control that exists because of an incident in 2019, or a number that three people calculate differently and nobody has reconciled.
Buying software for that is expensive in a particular way: it works. The new system faithfully automates the confused process, and now the confusion runs faster and is harder to see.
So we look at the operation before the software. What actually happens, where the time goes, where the same data gets entered twice, and which controls are earning their cost. Sometimes the answer is an ERP. Sometimes it's three decisions and a changed handover.
/what-it-produces
What it produces
- Discovery workshops with the people doing the work
- Current-state process mapping, end to end across departments
- Bottleneck and rework analysis — where time and margin actually go
- Data flow review — what's entered more than once, and why
- Control review — which checks are earning their cost
- A phased roadmap with sequencing and dependencies
- An executive readout to the people who can act on it
- A written description of how your operation actually runs
- The bottlenecks named, ranked and costed
- Changes separated into process, people and system
- A sequence, so change lands in an order that holds
- A view on whether software is part of the answer at all
- Something to hand a new operations hire on day one
/how-we-run-it
Four stages. Three to six weeks.
Scope is set by how many functions are in play, not by company size. A single department in a large group is a shorter engagement than three functions in a small one.
-
01
Framing
What problem you're actually solving, and how you'd know it was solved.
0.5 day
-
02
Discovery
Workshops and observation with the people doing the work. Including the parts held together informally.
1–2 weeks
-
03
Analysis
Bottlenecks, rework, duplicate entry and controls — mapped and ranked by cost.
1–2 weeks
-
04
Roadmap & readout
Sequenced recommendations, walked through with the people who can act.
1 week
/what-you-get
Four artefacts you keep.
None of these commit you to a system, a vendor or us.
Current-state process map
how the operation actually runs, cross-department. Clients tell us this is worth the engagement on its own.
/02Bottleneck analysis
where the time and margin go, ranked.
/03Roadmap
recommendations split into process, people and system, in sequence.
/04Executive readout
the version for people who won't read the map.
/where-this-fits
What comes before this, and what comes after.
This is upstream of everything technical. If the roadmap says a system is part of the answer, Odoo consulting picks it up from there. If it doesn't, the engagement is complete.
/questions
Asked on every first call.
-
It's the right question. Our incentive is real and we don't pretend otherwise. What we do about it: recommendations are split into process, people and system, in that order, and where a recommendation benefits us we say so in the document. Several of these engagements have ended with no system work at all.
-
Odoo consulting starts from "should this be Odoo, and how". This starts from "what's actually wrong", and software may not feature. If you already know you're implementing an ERP, you want the other page.
-
Usually not in detail. We need to understand volumes, where time goes and what things cost you in effort — which is different from wanting your P&L. Where a number matters to a recommendation, we'll ask for that number specifically.
-
The people doing the work, for discovery — and that means the people who actually do it, not their managers describing it. Plus a sponsor senior enough to act on the roadmap. Engagements that stall almost always stall on the second one.
-
Then you have a written description of your own operation and a disagreement worth having. The map is useful regardless of whether you accept the roadmap, and it's yours either way.
/next
Describe the problem, not the system you think you need.
Thirty minutes, no slides. We will tell you straight if Odoo is not the answer.