Before you configure anything: mapping a process your team will recognise

Every implementation methodology starts with “map the current process”. Very few explain how to do it in a way that survives contact with the people who do the work.

This is the method I use. It is not sophisticated. It is just done carefully.

Start with the document, not the diagram

Before any meeting, collect the artefacts the process actually produces: the invoice, the payment certificate, the approval email, the spreadsheet that gets circulated. Physical evidence, not descriptions.

Documents do not have opinions about how things should work. They record how things did work. If the approval form has a signature box nobody uses, that tells you more than an hour of interviews.

Interview the doer, not the owner

Ask the head of department how the process runs and you will get the intended process. Ask the person who runs it and you get the real one — usually with an apology attached, because they assume the workaround they invented is a personal failing rather than a design gap.

Three questions do most of the work:

“Show me the last one you did.” Not a hypothetical — the actual last transaction, on their screen.
“What do you do when it goes wrong?” The exception path is where the real complexity lives, and it is almost never in the documentation.
“What do you check before you trust this number?” Whatever they name is a control the system will need to reproduce, or the trust does not transfer.

Write it as sentences before you draw it

Diagrams look authoritative, which makes them dangerous early. A box labelled “Approve” hides the question of who approves, on what basis, within what time, and what happens on rejection.

So write the process out in ordinary sentences first, one line per step, naming the role and the trigger:

When the site engineer marks work complete, the QS raises a payment certificate. The project accountant checks it against the contract and the previous certificate. If the cumulative value exceeds the contract sum, it goes back to the QS rather than to the project manager.

That paragraph is uglier than a flowchart and about ten times more useful, because every ambiguity is visible. Draw the diagram afterwards, for the people who need the overview.

Read it back and wait for the correction

This is the step that matters and the step most often skipped. Send the written process to the team and ask one question: “Is this true?”

Not “do you approve”, not “any comments”. Is it true.

You are looking for the correction that starts with “well, mostly, except when…”. That exception is usually the reason the previous system failed. If nobody corrects anything, either the process is genuinely simple, or you have not talked to the right person yet. In my experience it is usually the second.

Separate three things before designing anything

Once the as-is map is agreed, sort every step into three buckets before you design the to-be:

Value — the step exists because the business needs the outcome. Keep it, automate it if you can.

Control — the step exists to catch an error or prevent a fraud. Keep it, but ask whether the system can enforce it structurally instead of asking a human to remember. A validation rule is a better control than a checklist.

Scar tissue — the step exists because of something that happened once. Ask what it is protecting against, and whether that risk still exists. Some scar tissue is load-bearing; a lot of it is not. This is the bucket where implementations find their real savings.

The temptation is to automate all three. The value of the exercise is in deleting the third.

What you should have at the end

A discovery is finished when you can hand over three things:

An as-is description the team has confirmed is true, exceptions included.
A to-be design showing what changes, what is deleted, and who is affected.
A configuration plan and a fixed price, with the customisations that are genuinely necessary named and justified.

Everything after that is execution. Everything before it is guessing — and guessing is what makes ERP projects expensive.