Process Documentation

Why document processes before an eCommerce or ERP project

Whoever implements an online store, an ERP or an integration configures what is described to them. If nobody tells them that certain customers have special project-specific prices, that a product family is sold in part pallets or that urgent orders are picked ahead of the queue, those exceptions surface on go-live day, when they are most expensive to fix.

Documenting before you start reduces that surprise and also protects the company from something common: the knowledge of how a critical process works being in one person's head.

Documenting also forces decisions that would otherwise be put off: which price list prevails when a customer has two, who can authorise a credit note, or what happens to an order that arrives with no stock. Settling them on paper is far cheaper than settling them on a system that's already configured.

Documenting the current state: how work is really done

To document the current state we talk to the people who do the work, not just those who manage it, and we follow real documents: an order, a return, a new product setup. We record each step, who does it, with which tool and at which points they wait for someone else.

We also record what doesn't appear in any system: auxiliary spreadsheets, emails used as alerts, data retyped from one program to another and the workarounds the team has come up with over time. That is the most valuable information for any project that follows.

At this stage we neither judge nor correct: the goal is to reflect reality as it is. If the current state is polished up, the project ends up designed for a company that doesn't exist. We also note the approximate volume of each activity, because a manual step done twice a month doesn't deserve the same attention as one repeated hundreds of times.

Documenting the future state and who owns each step

With the current state on the table, we design the target process: which steps disappear, which move to the store or portal, which system is the reference for each piece of data and who is responsible for each decision. We use a responsibility matrix so that no step is left without an owner and no step has two.

The difference between the current and future state is, in practice, the scope of the project. That's why this documentation works directly as the basis for requesting quotes from an implementer or for choosing a tool.

For each step in the future state we indicate what data it needs, which system it comes from and what happens if it's missing, which is exactly what whoever designs the integrations between the store, the ERP and the other tools will need later. When the same process is done in several ways, for example across branches or brands, the future state decides which becomes the standard and which differences are justified.

Process documentation that stays alive

Documentation that nobody updates becomes obsolete within a few months. We deliver the diagrams in an editable format using the tools your company already has, assign an owner to each process and agree when it is reviewed: at the very least, whenever the system or the way of working changes.

When the technical team needs it, we use standard BPMN notation; for the rest of the organisation, simple diagrams that can be understood without prior training. What matters is that the people doing the work consult it, not just those who audit it.

It's worth keeping previous versions of each diagram. When a process starts causing problems, comparing how it was before with how it is now usually points straight to the change that caused it.

If the documentation is done ahead of a project, we update it when the project ends so it reflects how work is done with the new systems rather than how it was done before.