← All expertise

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.

How we work
  1. Site visitWe stay on site and watch the work where it happens, not as it is told in a meeting
  2. As-is mapWho does what, with which document, where data stops or gets typed twice
  3. Friction pointsDouble entry, waiting, missing checks and checks that serve nobody
  4. To-be designWhat changes, in which order, and what stays manual on purpose
  5. ProceduresWritten in the language of the people using them, with the edge cases that really happen
  6. 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.

What we take away from a site visit

Not minutes. A map of the process as it is, with real timings for each step, the points where data is typed a second time, and the list of exceptions somebody handles from memory. The exceptions are the most valuable part: they are what software later gets wrong.

Along with the map we take the numbers: how many times a day something happens, how long it takes, how often it goes wrong. Without numbers every later discussion is a contest of opinions, and the loudest one wins.

And we take people's sentences away with us. "I do it this way because once it happened that…" nearly always contains a requirement no specification would have written.

The uncomfortable part: saying what not to do

A serious analysis also produces a list of things not to do. Automations that would cost more than they return, features requested by one person only, integrations that would solve a problem about to disappear by itself.

It is the part that makes us sell less and get called back. A supplier who says yes to everything is choosing their revenue over your result — and the difference shows after two years, not two months.

Who we involve, and why it matters

We talk to whoever decides, but we spend our time with whoever executes. They are two different accounts of the same process, and both are true: management knows the intentions, the counter knows the exceptions.

Involving the future users early has a second, less obvious effect: by the time change arrives, those people have already discussed it. Adoption starts during analysis, not at training.

How we do it, and with what

Most of it is method, not technology. The tools exist to make the result reusable rather than locked in a report nobody will reopen.

  • Observation

    • on-site observation
    • short interviews
    • timing
    • collecting real documents

    A process is studied where it happens. Interviews are kept short and repeated: half an hour with five people says more than two hours with one, and the second half hour corrects what the first misunderstood.

  • Mapping

    • as-is and to-be maps
    • flow diagrams
    • role and permission matrix
    • exception register

    The drawing exists to align people who thought they were talking about the same thing. The exception register in particular is the document that saves the project during development.

  • Measurement

    • volumes and frequencies
    • time per step
    • error rate
    • annual cost per activity

    Every later proposal is judged against these numbers. It is also the only way to prove, six months on, whether the work actually helped.

  • Deliverables

    • operating procedures
    • written decisions (ADR)
    • priorities with expected return
    • training material

    The output is not a presentation: it is documents somebody will use. Important decisions stay written with their reasoning, so in three years you can change your mind knowing what breaks.

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