01
Process analysis
We come to your company and write down how you actually work, before writing any software
Almost no ERP project fails for technical reasons. It fails because someone automated a process nobody had ever written down end to end, and the gaps show up in production.
- Site visitWe stay on site and watch the work where it happens, not as it is told in a meeting
- As-is mapWho does what, with which document, where data stops or gets typed twice
- Friction pointsDouble entry, waiting, missing checks and checks that serve nobody
- To-be designWhat changes, in which order, and what stays manual on purpose
- ProceduresWritten in the language of the people using them, with the edge cases that really happen
- SoftwareOnly where needed, and not before: sometimes moving one check is enough
Look first, design after
The first step is reconstructing the process as it really is, not as the manual describes it: who does what, with which document, where data gets typed a second time, where people wait for someone else. It takes being on site and watching, because the version told in a meeting and the one happening at the counter never quite match.
From there you design the to-be — and above all decide what not to automate. A manual step that exists to make someone stop and check is worth more than a perfect flow nobody looks at.
Procedures written for the people who will use them
The output is not a document for a drawer: it is operating procedures written in the language of the people doing the work, covering the edge cases that actually happen — the supplier who sends the wrong delivery note, the client who changes their mind halfway, the order that arrives on a Saturday.
Every structural choice leaves its reasoning on record. That is what lets you change your mind three years later knowing exactly what you are breaking.
Then the software, not before
Only now do you decide what is really needed: sometimes an ERP module, sometimes half a day of automation, sometimes nothing — moving one check or removing one step is enough. Software costs money and must be maintained: if the process can be simplified without it, that is the better answer.
Portfolio
What we did on this, project by project.
ASC Buildings
Construction site access management for a building company
- Analysis of the site process before writing a single line: who records what, when, and what must reach the back office for the data to be worth anything.
- Result: access records captured on site flow into the ERP and attach to the job's analytical accounting, instead of stopping on a sheet of paper and being re-keyed at month end.
- Odoo
- Flutter
- analytical accounting
CocoonServer
Odoo environment management for multiple client companies
- Mapping of a client environment's lifecycle — create, start, upgrade, clone, decommission — with explicit semantics for every destructive operation.
- Then the software: a console governing that lifecycle instead of a collection of remembered commands, with a record of who did what.
- Odoo
- Kubernetes
- operation audit
SOS Bollette
A network of agencies sharing one platform
- Modelling the boundary between head office, partner agencies and people: which tools each one sees and who may change what.
- Privilege became data — readable, revocable and enforceable by the database — instead of exceptions scattered through the code.
- role analysis
- PostgreSQL
- procedures
Need this?
Tell us the problem and we'll tell you how we would tackle it — and if it isn't worth doing, we'll tell you that too.
Let's talk