Your as-is documentation is already in your SAP system

In almost every SAP estate, and through no fault of the team, current documentation of how a core process actually runs today is hard to find. SAP landscapes evolve for years, and documentation ages the moment it is written. So the real picture usually lives in a project deck that is three years stale, in the heads of the few people who set things up, and in a good deal that was never written down at all.

This is fine, right up until it is not. A migration to S/4HANA. An audit. Offshoring the support. A handoff to a new partner. A new CIO who wants to know what they actually have. Suddenly the thing nobody wrote down is the thing everything depends on, and teams spend weeks, sometimes months, in workshops trying to reconstruct how the business really runs.

Here is the good news, and the reason this does not have to be slow. The answer is not lost. Your live SAP system is the most accurate record you will ever have of how your business runs today. It holds the configuration, the custom code, the document types, and quietly, what is actually being used and what is not. The as-is is sitting right there. The only real question is how you read it.

The tempting shortcut

If the truth is in the system, and we now have very capable AI, the obvious move is this: connect a frontier model to the live SAP, ask it to document the process, and let it write the as-is for you.

It is a fair instinct. And it will give you something that reads beautifully. It will also quietly miss the things that matter most.

Why a model on its own misses things

A language model answers what you ask. Discovery is the opposite job. It is about finding what you did not know to ask. That gap is where the trouble lives.

A model has no systematic way to go hunting for everything a process actually contains: the variants that run differently from the textbook flow, the custom enhancements bolted onto standard transactions, the custom objects, the configuration, the master-data dependencies. None of that shows up reliably from a single prompt, because a prompt does not know those things exist until you tell it to look.

And coverage is inconsistent. Run the same request twice and you will miss different things each time. There is no checklist, no guarantee that every area was actually examined. So the output looks complete, reads well, and has holes. And the holes are exactly what break the project later.

Let me show you what that looks like in real SAP terms.

A real example: Order-to-Cash

Take Order-to-Cash. Ask a frontier model to document O2C and it will confidently give you the textbook flow: Sales Order (VA01) into Delivery (VL01N) into Goods Issue (VL02N) into Billing (VF01). Clean, correct, and quietly incomplete.

Because that one flow is not your Order-to-Cash. A real O2C estate runs dozens of variants, most of them starting from the same VA01 but behaving completely differently: returns, credit and debit memos, rush orders, free-of-charge deliveries, make-to-order, third-party sales, intercompany, scheduling agreements, rebates, and consignment in four flavours. Each has its own document type, its own configuration, and often its own custom objects. In one illustrative discovery, a single Order-to-Cash process area held 37 distinct variants, not one.

And the ones that bite are the ones a prompt would never think to ask about. A consignment process for a pharma business carried eight scenario variants, each needing 21 CFR Part 11 electronic-signature compliance. Country-specific flows like India GST and Brazil Nota Fiscal ran their own way, with their own configuration. Ask a prompt to document "the sales order process" and all of that is simply absent, until a migration or a Clean Core exercise runs straight into it mid-build.

The half of Order-to-Cash that does not look like the textbook was invisible, because nobody asked the system to list every variant, only to describe the main one.

That example is illustrative, not a specific customer. But it is exactly the kind of thing that hides in a real estate.

The real lesson: a model is not a method

This is the difference between asking a smart model and running a method. The model reads well. What actually protects you is a structured method that checks every area, every time, whether or not the model happened to think of it.

If you are documenting an as-is, at a minimum your method has to force answers to all of these, for every process area:

• Org structure: which company codes, sales orgs and plants actually transact.
• Master data: quality, ownership, and the dependencies that will bite in a migration.
• Process variants: every real way the process runs, not the one on the slide.
• Configuration: what is actually set up, including pricing and output determination.
• Enhancements: the user exits and BAdIs quietly changing standard behaviour.
• Integrations: every interface and third-party system the process touches.
• Custom objects: what exists, what is used, and what can go.

If your approach does not force each of these, it will miss something. And in SAP, the thing it misses is usually the expensive one, or the regulated one.

How we approached it

This is why we built the C16 Discovery Accelerator around a gated, SME-validated framework rather than a single prompt. C16 reads your live SAP, read-only, and produces a structured as-is of a process area across exactly those areas, so the variants, the custom objects and the configuration are listed from the system rather than remembered. Your experts then validate pre-filled findings instead of assembling them from a blank page. It runs on ECC and on S/4HANA. Nothing changes in your system. It is read-only, and every finding is yours to confirm.

The point is not that AI cannot help with discovery. It is that AI plus a method is a different thing from AI plus a prompt.

The takeaway

Your as-is is not missing. It is in the system that runs your business every day. A frontier model can read that system. Only a method makes sure it reads all of it.

See it for yourself. If you want to know what your own as-is actually looks like, there is a live demo on real SAP at C16.ai. Ask it something like "how many order-to-cash variants does my system really run", and see what comes back.

The Order-to-Cash example and all figures in this post are illustrative and do not represent any specific customer system.