Business Process Documentation
Business process documentation at OMAV is written from your configured system and observed transactions, not from a workshop whiteboard. Documentation produced from what people remember describes a process nobody actually runs.
What the system does, not what people remember
Ask five people how an order gets approved and you will get five answers, all sincere and none complete. Workshop-derived documentation captures the process people believe exists, which is the process as designed plus whatever each participant remembers of the exceptions.
We interview people too, and then reconcile what they say against what the system shows. The gap between the two is consistently the most valuable finding in the engagement, because it is where controls are being bypassed, where the workaround has become the process, and where an auditor will eventually look.
The output is editable source you own, in your own tooling — not a PDF that is accurate on the day it is issued and stale a month later.
What the engagement covers
Six workstreams. The reconciliation is where the value concentrates.
Process capture from the system
Configuration, transaction data and system logs examined to establish what actually happens, including the steps people do not mention because they have stopped noticing them.
Interviews and reconciliation
Practitioners interviewed, then their account compared against the system evidence, with every divergence recorded as a finding rather than smoothed over.
Level 1 to 3 process maps
Documentation to an agreed depth — value chain, process, and procedure level — with owners named at each level so the maps have somebody accountable for currency.
Exception paths
The unhappy paths documented explicitly: rejections, returns, credit blocks, manual overrides. These are the majority of support volume and the minority of most documentation.
Controls and thresholds
Approval limits, segregation-of-duty points and control steps recorded, because these are what audit asks about and what nobody can reconstruct three years later.
Version control and review cycle
Documentation held under version control with a named owner and a review date, since undated documentation cannot be trusted or defended.
How the engagement runs
Scope the depth
Which processes, to which level, and which are explicitly not worth documenting — because documenting everything equally is how the budget is exhausted on the trivial.
Capture from the system
Configuration and transaction evidence gathered first, so interviews test the evidence rather than replacing it.
Interview and reconcile
Practitioners interviewed and their accounts compared against the evidence, with divergences recorded as findings.
Document
Maps and procedures written to the agreed levels, including exception paths and control points, with owners named.
Hand over
Editable source delivered in your tooling under version control, with review dates set and a walkthrough for the owners.
Documentation sources compared
Why the source determines the value.
| Source | Captures | Misses | Effort |
|---|---|---|---|
| Workshops only | The process as designed | Workarounds and exceptions | Low |
| Existing documentation | A past state | Everything since | Very low |
| System configuration | What is possible | What people actually do | Moderate |
| Transaction data | What actually happens | The reasoning behind it | Moderate |
| All of the above, reconciled | Actual process and the gaps | Little of consequence | Higher |
What we will tell you
Not every process is worth documenting to the same depth. A process performed twice a year by one person who is not leaving does not repay level-three documentation. We will name the processes we think should be out of scope, which reduces our own engagement, because a budget spent evenly across everything leaves the important processes shallow.
Documentation also cannot resolve a disagreement about how a process should work. Where two departments hold different views on who approves what, we will document both positions and the divergence, and then stop and ask for a decision. Writing one version down does not settle it; it just gives one side a document.
- Reconcile interviews against system evidence; the gap is the most valuable finding.
- Document the exception paths — they are most of the support volume.
- Record approval thresholds and control points; audit will ask.
- Deliver editable source under version control, with owners and review dates.
Questions buyers ask about this
Why not just run workshops?
We do interview people, but workshops alone capture the process as remembered, which is the design plus a partial account of the exceptions. Reconciling that against configuration and transaction evidence produces the divergences — where controls are bypassed and where a workaround became the process — and those are consistently the findings clients act on.
What format do we get?
Editable source you own, in your tooling — Visio, Lucid, Confluence, BPMN, or whatever your team already uses. Not a PDF. A PDF is accurate on the day it is issued and cannot be maintained, which means the documentation decays from the week we leave.
How long does it take?
Four to fourteen weeks depending on process count, depth level and how much we can read directly from the system. Estates where the system evidence is accessible move considerably faster, because interviews become verification rather than discovery.
Can the documentation be reused for audit and training?
Yes, and it should be. The same captured process feeds the process map, the SOP and the training material, which is a substantial part of why we deliver editable source rather than a finished document. Producing three separate artefacts from three separate exercises is how organisations end up with three versions that disagree.
Do you document non-SAP processes?
Yes. The method is system-agnostic: capture from whatever system of record exists, reconcile against practitioner accounts, record the divergences. SAP estates are common in our work because that is where the configuration evidence is richest, not because the approach requires it.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.