Process engineering

Get your processes straight
before you buy software

Software installed on a vague organisation does not clarify it: it sets it in stone. I lay out what actually happens, design the target with you, and hand it over to your teams. Choosing the tool comes afterwards — if it comes at all.

Describe your situation → What you get

The starting point

The symptom is always the same

Two people hold the real knowledge of the chain, and nobody has written it down. Orders go through a shared file that someone created one day. The quote gets redone by hand because the tool ‘can't do that’. The same information is entered three times, in three places, with three different spellings.

The usual reaction is to look for software. It is often the right instinct at the wrong time: a tool only makes executable what was decided before it. Until the decision is made, the tool puts it off — and charges you for the delay.

Process engineering is precisely that work. Deciding before tooling.

Workarounds are the raw material of the diagnosis, not a flaw to be hidden.

How it runs

Three stages, then we decide

01 · Interviews and real documents

Current-state diagnosis

I talk to the people who do the work, and I look at the files they actually use — including the unofficial ones. The double entries, the export redone every Monday, the spreadsheet that should no longer exist: that is where the real process is, not in the procedure.

02 · The core of the engagement

Target design

Who does what, in which order, with which data, and who answers for it. The business rules are written down in black and white, exceptions included — they are what derails tools, because they are never in the requirements.

03 · Through to self-sufficiency

Handover

Whatever I deliver, your teams must be able to keep it running without me. Documentation and handover are part of the engagement, not an option. A process that only the consultant understands does not exist.

Deliverables

What you get,
and what you keep

Documents you can show to any vendor, and that keep their value if you no longer work with me.

The workflows
A map of the workflows, from the customer's request to payment received, with the breaking points ranked by cost and by effort. You can see what costs a lot and is quick to fix, and what costs a lot and will take time.
The rules
The business rules, written down and binding, exceptions included. It is the document people pull out when two departments disagree about who approves what.
The reference data
What a customer, a product or a site actually is, in your organisation. Without that definition, any report produced later will be disputed — and rightly so.
The responsibilities
Who holds which role, with no grey areas. A step without a named owner is a step that will not happen.
The specification
A tooling document you can take to any vendor, sorting what needs to be tooled, what can stay manual, and what should simply disappear. Plus a frank opinion when the answer is ‘you do not need software’.

And if the tooling turns out to be Odoo

I implement it myself: functional configuration, no-code automations, day-to-day administration. See the Odoo page →

Fit

Who it is really for

This is for you if

  • You have grown faster than your organisation.
  • You are considering business software and want to know what to ask of it.
  • A previous tooling project failed, and you do not know exactly why.
  • A key function rests on a single person.
  • A takeover, a sale of the business or a new partner coming in is approaching.

This is not for you if

  • You are looking for validation of a decision already made.
  • You want a certification: that is not what I do.
  • The real issue is a human disagreement that no process will resolve.
  • You are a private individual. Businesses and organisations only.

Questions

What people ask me about processes

No, quite the opposite. A tool only makes executable what was decided before it; until the decision is made, it puts it off and charges you for the delay. The specification I produce is there precisely so that you can consult several vendors on a like-for-like basis — and sometimes to conclude that no software is needed.
Both, but not at the same time. The diagnosis is done with the people who do the work, because the real process lies in their workarounds. The trade-offs are settled with the people who can decide. Mixing up the two stages produces either a flattering picture of the current state, or a target nobody will apply.
It depends on how many people there are to listen to and on the state of the existing documents. What is fixed is the order: I propose nothing before I have spoken to the people who keep the business running and looked at the files they actually use, including the unofficial ones.
Then no process will solve it, and I say so before starting rather than at delivery. A disagreement between two people who do not want to work together is not resolved by a flowchart. Writing down business rules can make the disagreement visible; it does not settle it.
No, that is not what I do. I design processes so that they work and can be tooled, not to satisfy a certification standard. The two often overlap, but aiming for compliance as the goal produces documentation nobody opens.

On the blog, in French

Further reading

Why ERP projects fail — and how to avoid it

7 min

IT architecture for a construction engineering consultancy: no ERP, for €20 a month

10 min

Odoo ERP project: start with the IT architecture, not the tool

13 min

Tell me about your situation

A few lines are enough to see whether there is something to work on. I reply within 48 hours with an initial view, including when bringing me in would not be useful to you.

Describe your situation →