Documenting SAP properly: connecting processes and functions
What’s the best way to document an SAP system? In practice there are two camps — and they rarely talk to each other.
One camp documents solution capabilities: which features are implemented, which modules run, what is standard and what was custom-built. The other camp documents business processes: the end-to-end flow from purchase order to invoice, with all its variants and ownership.
Both views are correct on their own. And both are incomplete on their own.
Implemented features and functions — standard or custom, active or unused.
End-to-end flows across documents and steps — including every real-world variant.
They can be connected
Here’s the key point: these two layers aren’t separate worlds. They’re two views of the same system.
Behind every process step sit concrete functions that get used. If you know the process, you can derive the functions used from there — and vice versa. Two lists become one connected model.
A process without the functions behind it is a story. Functions without the process are an inventory. Only together do they form a picture you can base decisions on.
What the connection makes visible
Once process steps and functions are linked, a set of questions that used to stay open becomes answerable:
- Standard or custom? For every function used, you can show whether it’s SAP standard or a custom development — and which extensions hook in at which point in the process.
- Where is customization happening? At the process level it becomes clear which steps deviate from the standard — and whether anyone still uses that deviation.
- How far from standard? The process can be mirrored against references like SAP Best Practices. That reveals which customizations are keeping you from standardizing — and which are negligible.
Why this matters for a transformation
That third question is exactly what drives the effort and risk of any S/4HANA migration. As long as functions and processes are documented separately, it stays a gut feeling. Connect the two and it becomes fact: per process, you see which custom development blocks a standard — and you can decide deliberately whether it’s worth it.
This is exactly where Conjola comes in: we bring the feature layer (what’s implemented, standard vs. custom) and the process layer (how it actually runs) together — from the system’s real data. Not two documentations side by side, but one that connects both viewpoints.