How do you map your SAP business processes when nobody documented them?

Why the documentation is always wrong

Every ECC estate has a folder of process documentation. It was written during the original implementation, it was accurate for about six months, and then it was overtaken by a decade of change requests that nobody backported into the diagrams. The blueprint says orders route through a credit block; the system says the block was disabled for two of the five sales organizations in 2017 and a custom exit now approves them automatically under a threshold.

This is not negligence. Documentation decays because it is a copy of the truth rather than the truth itself. The system is the only artifact that cannot drift from what the business actually does, because it is what the business actually does.

Three ways to reconstruct a process map

The three approaches are not competitors so much as different instruments. Knowing what each one can and cannot see keeps you from paying for the wrong one.

• Workshops. You put the order-management team in a room and draw the process on a whiteboard. Fast, cheap, and it captures intent and pain — which matter. But it produces the process as remembered, and it systematically misses the exceptions and the automation that people stopped noticing years ago.
• Process mining. You extract event logs and let the tool infer the graph and its variants. Strong on cycle time, rework loops and conformance. Weaker on the why: it can show that 18 percent of orders take a detour, but it will not tell you that the detour exists because of a user exit implementing a pricing rule that S/4HANA now delivers as standard condition technique.
• System-evidence discovery. You read the live system directly — document flow between business documents, the configuration behind each step, and the custom objects attached to the transactions in that step. Slower to build, but it is the only route that ends with a process map and a customization inventory that reference each other.

What the system will tell you if you ask it

For order-to-cash, the backbone is document flow: the chain that links a sales order to its delivery, goods issue, billing document and accounting entry. Walk that chain across a representative window of business documents and the real process shape emerges — including the branches nobody mentions, like the orders that skip delivery entirely, or the credit memos that originate outside the standard flow.

On our reference estate — a live ECC system we use for demonstrations, not a customer's system; a customer's numbers come from their own system — that chain covers roughly 8,360 sales orders and the associated custom-object inventory runs to about 356 objects. Those two data sets are only useful together. The document flow tells you which stages carry volume; the object inventory tells you what has been bolted onto each stage. A stage with heavy volume and heavy customization is where your migration risk and your simplification opportunity both live.

The configuration layer is the third leg. Pricing procedures, output determination, copy control, credit management settings and partner determination are, in effect, the process rules written down in a form that cannot lie. Reading them alongside the flow is how you separate a genuine business requirement from a workaround somebody built because a setting was wrong.

The attribution rule that keeps the map honest

The failure mode in automated process mapping is the tidy picture. It is trivially easy to produce a diagram where every custom object is assigned to some stage and every stage looks well understood. It is also misleading, because a large share of objects in any real estate cannot be attributed to a single stage on the available evidence.

The rule we hold to is single-stage attribution with an honest remainder: an object is placed on a stage only when there is evidence tying it there — it references the documents of that stage, or it is an enhancement point in that transaction. Everything else goes into an unattributed bucket that is displayed, counted, and left visible. An unattributed bucket of 30 percent is not a defect in the map; it is a true statement about how much of the estate has not yet been traced, and it tells the project exactly where the next hour of analysis should go.

What you do with the map once you have it

A process map built from system evidence is not a documentation deliverable. It is a scoping instrument. Once each stage carries its volume, its configuration and its custom objects, three decisions get much cheaper: which processes to convert as-is, which to redesign toward standard, and which custom objects can be retired because the rule inside them is now delivered natively in S/4HANA.

It also survives the project. The map is regenerated from the system rather than maintained by hand, so it does not decay the way the original blueprint did — which is the whole point of reading the truth instead of copying it.