The work that decides whether the software succeeds.
Process mapping, requirements definition and ERP selection — done before implementation, so the implementation has something solid to build on.
Most failed ERP projects were lost before anyone opened the system
They failed in the requirements phase, when nobody wrote down what the business actually does — or when what got written down was what people said they do rather than what happens on a Tuesday afternoon when the usual person is away.
This is the work that happens before implementation. Done properly, it is the reason the implementation goes to plan.
What we are usually asked to do
Process mapping
Documenting how work actually flows through your business — including the workarounds, the spreadsheets and the steps that exist because of something that happened in 2019.
Requirements definition
A Business Requirements Document specific enough that any vendor could quote against it, and that you could hold them to afterwards.
ERP selection
Vendor-neutral evaluation. We implement Odoo and say so — but if the answer is a different system, that is what the report will say.
Gap analysis
What your current system does, what the business needs, and the honest distance between them.
Business case
The numbers and argument you need to get a decision out of a board or an owner.
Post-implementation review
What was delivered against what was scoped, what is being used, and where the value actually landed.
How we run it
Talk to the people doing the work
Not just department heads. The person who processes the invoices knows things the finance director does not.
Document what happens, not what should
The gap between the two is usually where the problems live.
Quantify the pain
Hours lost, errors made, decisions delayed. Without numbers, priorities become opinions.
Design the target state
How it should work, expressed in process terms rather than software features.
Write it down properly
A document you can act on, hand to a vendor, or use to hold one to account.
We will tell you not to proceed. Some businesses are not ready — the processes are too unsettled, the data too poor, or the organisation too stretched to absorb the change. Saying so costs us an implementation and saves you a failed one.
On being both advisor and implementer
How we keep it honest
- Advisory sits in a separate division from delivery
- Selection work is priced and delivered as its own engagement
- The output is yours — take it to any vendor
- We have recommended against Odoo where it did not fit
What you should still do
- Ask us directly whether we benefit from the recommendation
- Take the requirements document to at least one other vendor
- Ask to speak to a client we advised but did not implement for
- Judge the document on whether it is specific enough to quote against
Questions about the advisory work
You implement Odoo. How can your selection advice be neutral?
A fair challenge. Advisory sits in a separate division from delivery, selection work is priced and delivered as its own engagement, and the output document is yours to take to any vendor. We have recommended against Odoo where it did not fit. You should still take the requirements to at least one other vendor — we would.
How long does a requirements engagement take?
Two to four weeks for a typical mid-sized business, depending on how many departments are involved and how available your people are. The constraint is usually calendar time for workshops rather than our effort.
What do we actually receive?
A Business Requirements Document specific enough that any vendor could quote against it, and that you could hold them to afterwards. Process maps, a prioritised requirements list, and where relevant a gap analysis against your current system.
Can you help build the business case for our board?
Yes. Quantified current-state cost, expected benefit, realistic implementation cost and timeline, and the risks stated honestly. Boards respond better to a case that names the risks than one that pretends there are none.
What if you conclude we should not proceed?
Then that is what the report says. Some businesses have processes too unsettled, data too poor, or too little internal capacity to absorb the change. Saying so costs us an implementation and saves you a failed one.
Not sure whether you are ready?
A thirty-minute conversation about where your processes actually stand, and whether an ERP project is the right next move.
Book a discovery call