← Back to the blog

S/4HANA transformations: the most important tool is usually missing

· Conjola

The toolbox of an S/4HANA transformation is impressive: project management, test management, migration cockpits, data tools, training platforms. There is a specialized tool for almost every phase of the project.

Except for the first and most important task: getting to know the client.

In most projects, the discovery phase runs the way it did twenty years ago — interviews, workshops, questionnaires, system demos. Weeks to months of effort, carried by the most expensive people on both sides. And in the end, the result depends on what the key users happen to remember.

The uncomfortable finding: the client doesn’t know themselves

That is not a criticism of the client — it is the normal state of a grown system. The documentation is outdated, the knowledge carriers of the early days are gone, and what is actually used has never been measured. Three questions suffice as a test:

  1. Which of the process variants that really exist carry the volume — and which are forgotten side paths?
  2. Which of the thousands of custom developments does anyone still execute?
  3. How far are the lived processes actually from standard?

Nobody in the company has these answers in their head. They live in exactly one place: the system’s document data.

”Knowing the client better than they know themselves” is the job description

Which is why the ambition is not presumptuous — it is the core of the consultant’s role. Scope cuts, fit-to-standard decisions and custom-code triage stand or fall with an as-is picture the client cannot deliver themselves. Without it, you plan on quicksand — and every overlooked variant, every forgotten Z-program comes back later as a change request and rework.

The missing tool, then, is one that builds this as-is picture from the system’s real data: the actual end-to-end processes from the document flows, a feature map of what is implemented versus what is used, the custom developments with their business context and usage. From one document extract, in about 24 hours — not in weeks.

What that changes for consultants

  • Workshops become validation instead of discovery. Instead of “walk me through your P2P process”, the question becomes: “this is how it runs according to your documents — is this picture right, and why does this variant exist?” That is a different conversation, at a different pace and depth.
  • The kickoff starts with knowledge. Showing the client facts about their own system in week one — facts nobody there knew — is the strongest proof of trust this business has to offer.
  • Recommendations become defensible. Scope, effort and standardization potential rest on numbers instead of estimates — which takes the attack surface out of the inevitable political debates.

In fairness: such a tool does not replace conversations. It gives them substance. The key users’ scarce time flows into decisions instead of stocktaking — and the consultant debates at eye level with a system they have demonstrably understood.


That tool is exactly what Conjola is: processes from real document flows, feature map and custom-code analysis from a single extract — and built multi-tenant for consulting firms, so the same methodology runs identically at every client. Get to know the client before the first workshop starts.