Discovery before code: mapping a multi-department operation.
An ERP that does not match how the work actually moves will be abandoned, quietly, within a year. Discovery is how you avoid building that.
Every failed ERP we have been asked to look at failed the same way. Not with an outage — with a spreadsheet. Somebody in operations needed to do something the system made hard, so they did it in Excel instead, and told one colleague, who told two more. Eighteen months later the ERP holds the official version of the business and the spreadsheets hold the real one.
That failure is decided long before anyone writes code. It is decided in the weeks when nobody asked operations how they actually work.
What we do first
We sit with every department. Not a kickoff workshop with department heads in one room — separate sessions, with the people who do the work, at the place where they do it.
- We ask them to walk us through a real case from last week, start to finish, naming every person and system it touched.
- We ask what they do when it goes wrong, because the exception path is where most of the real process lives.
- We ask what they keep outside the official system, and why. This question produces the most valuable answers and requires the most trust.
- We ask what they would stop doing tomorrow if allowed. Some of it is genuinely dead process nobody has the authority to kill.
The thing you are actually looking for
Departments do not disagree about facts. They disagree about definitions. Sales and operations will both tell you confidently what a “confirmed booking” is, and they will mean different things, and the whole business has been absorbing that mismatch through human effort for years without naming it.
Half of ERP design is not workflow. It is getting four departments to agree on what a word means.
Finding those mismatches is the single highest-value output of discovery. Each one you find before the build is a design decision. Each one you miss becomes a data migration, an argument, and a workaround.
What we produce
Discovery ends with artefacts, not impressions:
- A workflow map per department, drawn as the work actually happens, with the exception paths marked.
- A shared glossary — the agreed definition of every contested term, signed off by the people who contested it.
- A role and permission matrix, which is usually the first time anyone has written down who is allowed to approve what.
- A ranked list of what the system must do, what it should do, and what everyone would like but is not paying for.
That last list is what protects the budget. Scope does not explode because clients are unreasonable; it explodes because nobody wrote down what was out.
Why it is worth the weeks
Discovery looks expensive because it produces documents rather than screens, and screens are what people want to see. But the alternative is discovering the same information later, in the form of rework — and rework arrives after the architecture has hardened around a wrong assumption.
When we built the ERP behind a multi-department expedition operation, the mapping came first, department by department, before a line of code. That system now runs the operation. The version we would have built in month one, without the mapping, would have been abandoned by month twelve — politely, and with a spreadsheet.