Business Process Documentation: Maps and SOPs

Short answer: Business process documentation means recording who performs each process, in what order, with which documents and rules, as a process map and a written procedure. It is the mandatory step before automation: automate undocumented chaos and you get chaos that runs faster. In a Panorama Consulting study, 63% of organisations struggled to adapt to new business processes after implementing ERP.

In many companies, processes live only in people's heads. How an order is processed, who approves a discount, when goods are received into stock: only one experienced employee knows. When that person goes on leave or quits, work stops. Implementing ERP in that situation is hard, because when the consultant asks "how does this process work?", every department gives a different answer. This article explains what business process documentation is, how to build as-is and to-be maps, the basics of BPMN, RACI and written procedures, and how to turn a process map into ERP workflows.

What is business process documentation?

Business process documentation is a clear record of where a process starts and ends, its steps, the people involved, the documents used and the decision points, in the form of a diagram, a written procedure or a simple list.

It answers three questions:

What is done? The sequence of steps: take the order, check payment, pick, ship.
Who does it? A specific role or department for each step.
Under which rules? Discount limits, credit limits, approval conditions, deadlines.

We gave general advice on where to begin automation in business process automation: where to start. This article covers the step that comes even earlier.

Why can't you automate chaos?

Software enforces rules. If there are no rules, the system either blocks people or they find ways around it. International evidence puts numbers on this:

In Panorama Consulting's report on ERP and business processes, 100% of respondents had a material operational disruption at go-live, and the article links most of these to poorly defined business processes (Panorama Consulting, 2014).
In the same report, 60% of disruptions lasted a month or longer, 63% of organisations had trouble adapting to new business processes, and only 47% changed their processes to take advantage of the new ERP's functionality (Panorama Consulting, 2014).

Put simply, implementing ERP without a process map is like building a house without a blueprint. We list the most common mistakes in 7 mistakes in ERP implementation.

How do you build as-is and to-be process maps?

An as-is map shows how a process really works today; a to-be map shows how it should work after automation.

How to build an as-is map:

Pick one process and define its start and end (for example, "from the customer's call to payment received").
Talk to each participant separately and ask what they actually do, not what "should" happen.
Record every step, every document (an Excel file, paper, a Telegram message) and every wait.
Flag the pain points: double data entry, manual calculations, waiting for someone's approval, lost information.

On the to-be map, unnecessary steps disappear, decision rules are written down explicitly, and each step is tied to a document in the system. One important rule: draw the to-be map with the ERP's standard features in mind, or you will spend a lot on customisations you do not need.

BPMN and RACI: which tools do you need?

For a small company, a plain list or a whiteboard sketch is enough. When there are many complex processes, standard notations help.

BPMN (Business Process Model and Notation). The international standard for process diagrams. OMG formally adopted BPMN 2.0 in December 2010 (OMG), and BPMN 2.0.1 was published as the ISO/IEC 19510:2013 standard (ISO). Its core elements are events (start and end), tasks, gateways (decision points) and swimlanes, one lane per participant.
RACI matrix. For each task, it records who does the work (Responsible), who owns the outcome (Accountable), who is consulted (Consulted) and who is kept informed (Informed). RACI ends the "who was supposed to do this?" arguments.

For quality and process improvement methods, see what Six Sigma is and how to implement it.

What is a standard operating procedure and how do you write one?

A standard operating procedure (SOP) is an internal document that sets out how a process is carried out, its deadlines, the people responsible and the control points.

A good SOP is short and practical. It includes:

The process name, purpose, start point and end point.
Participants and their roles (based on RACI).
The sequence of steps and the deadline for each.
Rules: discount limits, approval conditions, credit limits.
Control metrics, for example order dispatch time or stock discrepancies.
What to do in exceptional cases.

An SOP that stays on paper is forgotten within months. So the next step is to build it into the system. Then people do not need to remember the rule, because the system simply will not let them take the wrong step.

How do you turn a process map into ERP workflows?

In an ERP such as Odoo, every element of the to-be map becomes a specific setting:

Steps become document stages: quotation → order → picking → delivery → invoice.
Decision points become approval rules: for example, a discount above a set percentage cannot go through without a manager's approval.
RACI becomes access rights: the storekeeper cannot change prices and the sales manager cannot edit stock.
Deadlines become reminders and automatic activities.
Control metrics become reports and dashboards.

The SOP stops being just a document: the system enforces it in every transaction. We cover the stages of an Odoo rollout in our Odoo ERP implementation guide.

What changes after automation: in numbers

When process and technology change together: companies that rewrote standard operating procedures around new technology were more than twice as likely to succeed in digital transformation (McKinsey, 2018).
When roles are clear: redefining roles to match transformation goals made success 1.5 times as likely (McKinsey, 2018).
When processes are reworked: in Panorama's report, 87% of organisations improved either their key business processes or all of them during the ERP project (Panorama Consulting, 2014).
When people are prepared: 88% of projects with excellent change management met or exceeded objectives, versus 13% with poor change management (Prosci).
When a standard process is built into the system: at Timsoll, the time to set up a new product fell from 6–8 months to 2–3 days (Timsoll case).

How does Deep Vision document processes?

The team of Deep Vision founder Amon Olimov starts every Odoo project with process diagnostics. A pattern we see often: the owner describes a process one way, while staff actually work another way. That is why we build the as-is map together with employees, at their real workstations.

We are an official Odoo Gold Partner; according to our partner page on Odoo, we have 7 certified experts, 24 client references and 89% customer retention (Odoo).
We draw the to-be map around Odoo's standard features, which keeps custom development to a minimum.
A typical rollout takes 2–6 months; standard Sales and Inventory often go live in 6–8 weeks.
We have ready-made modules for local processes: Didox e-invoices and Asl Belgisi marking.
The system runs in Uzbek (our team translated Odoo), so the procedures and the interface speak the same language.

To document your processes and start automating, fill in the brief or see our Odoo implementation service.

Frequently asked questions

Which process should we document first?

The one that moves the most money or produces the most errors, usually the chain from order to payment.

Do we have to learn BPMN?

No. A small company can manage with a list of steps and a RACI matrix. BPMN helps when processes are many and complex.

How long does it take to document one process?

Usually a few sessions: interviews with staff, drawing the map and agreeing on it. Complex processes take longer.

Who should write the procedure?

The process owner (Accountable) is responsible, but it should be written together with the people who do the work, or it will not hold up in practice.

Should we fix the process first or install the software first?

Document the process first and agree on the to-be version. A system configured after that will lock the new order in place.

Sources

To bring order to your processes, fill in the brief or call +998 77 093 00 07.

Back to blog