S/4HANA-Transformation: das wichtigste Tool fehlt meist

Der Werkzeugkasten einer S/4HANA-Transformation ist beeindruckend: Projektmanagement, Testmanagement, Migrationscockpits, Datenwerkzeuge, Schulungsplattformen. Für fast jede Phase des Projekts gibt es ein Spezialtool.

Nur für die erste und wichtigste Aufgabe nicht: den Kunden kennenzulernen.

Die Discovery-Phase läuft in den meisten Projekten wie vor zwanzig Jahren — Interviews, Workshops, Fragebögen, Systemdemos. Wochen bis Monate Aufwand, getragen von den teuersten Leuten auf beiden Seiten. Und das Ergebnis hängt am Ende an dem, woran sich die Key User erinnern.

Der unbequeme Befund: Der Kunde kennt sich selbst nicht

Das ist keine Kritik am Kunden — es ist der Normalzustand gewachsener Systeme. Die Dokumentation ist veraltet, die Wissensträger von damals sind weg, und was wirklich genutzt wird, hat nie jemand gemessen. Drei Fragen genügen als Test:

1. Welche der real existierenden Prozessvarianten tragen das Volumen — und welche sind vergessene Sonderwege?
2. Welche der tausenden Eigenentwicklungen führt überhaupt noch jemand aus?
3. Wie weit sind die gelebten Prozesse tatsächlich vom Standard entfernt?

Niemand im Unternehmen hat diese Antworten im Kopf. Sie stehen nur an einem Ort: in den Belegdaten des Systems.

„Besser kennen als der Kunde sich selbst” ist die Jobbeschreibung

Genau deshalb ist der Anspruch keine Anmaßung, sondern der Kern der Beraterrolle. Scope-Schnitt, Fit-to-Standard-Entscheidungen und Custom-Code-Triage stehen und fallen mit einem Ist-Bild, das der Kunde selbst nicht liefern kann. Wer es nicht hat, plant auf Treibsand — und jede übersehene Variante, jedes vergessene Z-Programm kommt später als Change Request und Nacharbeit zurück.

Das fehlende Tool ist also eines, das dieses Ist-Bild aus den echten Systemdaten baut: die realen End-to-End-Prozesse aus den Belegflüssen, eine Feature Map von Implementiertem und Genutztem, die Eigenentwicklungen mit ihrem fachlichen Kontext und ihrer Nutzung. Aus Extrakten des Systems, und sobald die vorliegen, steht das Bild am nächsten Werktag — nicht in Wochen.

Was sich damit für Berater ändert

• Workshops werden Validierung statt Erhebung. Statt „Erzählen Sie mal, wie Ihr P2P-Prozess läuft” heißt die Frage: „So läuft er laut Ihren Belegen — stimmt das Bild, und warum gibt es diese Variante?” Das ist ein anderes Gespräch, mit anderem Tempo und anderer Tiefe.
• Der Kickoff beginnt mit Wissen. Wer dem Kunden in der ersten Woche Fakten über sein eigenes System zeigt, die dort niemand kannte, hat den stärksten Vertrauensbeweis erbracht, den es in diesem Geschäft gibt.
• Empfehlungen werden belegbar. Scope, Aufwände und Standardisierungspotenziale stehen auf Zahlen statt auf Einschätzungen — das nimmt den unvermeidlichen politischen Debatten die Angriffsfläche.

Zur Ehrlichkeit gehört: Ein solches Tool ersetzt keine Gespräche. Es macht sie substanziell. Die knappe Zeit der Key User fließt in Entscheidungen statt in Bestandsaufnahme — und der Berater diskutiert auf Augenhöhe mit einem System, das er nachweislich verstanden hat.

---

Genau dieses Tool ist Conjola: eine Feature Map mit der realen Nutzung je Buchungskreis, Eigenentwicklungen, die die KI fachlich beschreibt und einordnet, und eine Wissensbasis für Fachkonzepte — alles aus Extrakten, ohne Zugriff auf Ihr System. Dazu die Prozesse aus echten Belegketten, beginnend mit Order-to-Cash. Für Beratungshäuser ist Conjola multi-mandantenfähig gebaut: jeder Kunde in einem eigenen, strikt getrennten Mandanten, dieselbe Methodik bei jedem. Lernen Sie den Kunden kennen, bevor der erste Workshop beginnt.