Was Berater wirklich tun: ein realistischer Blick

SAP-Berater konfigurieren, bauen, testen und stabilisieren SAP für ein Unternehmen. In der Praxis liefern sie den größten Teil ihres Werts mitten im Programm. Sie klären Umfang, der abgedriftet ist, führen die Walkthroughs durch, die niemand durchgeführt hat, triagieren UAT-Fehler und stabilisieren den Betrieb nach dem Go-live. Funktionale Berater verantworten die Modulkonfiguration, technische Berater Erweiterungen und Integrationen, Programm- und Change-Berater Umsetzung und Akzeptanz. Dieser Beitrag richtet sich an Führungskräfte, die entscheiden, ob sie externe Hilfe holen, und an Menschen, die Beratung als Karriere abwägen. Wenn Sie Führungskraft sind, zeigt Ihnen die Signaltabelle unten, wann Sie anrufen sollten. Wenn Sie Berater sind, zeigen die Abschnitte zum Arbeitsalltag, was der Job wirklich umfasst.

Die Frage taucht jedes Mal auf, wenn jemand externe Unterstützung abwägt: Was genau macht ein Berater, was wir nicht selbst können?

Die ehrliche Antwort schmeichelt der Beratungsbranche nicht besonders. Der Großteil des Werts entsteht dadurch, Dinge zu reparieren, die nicht hätten kaputtgehen sollen. Fragen zu stellen, die längst hätten gestellt werden müssen. Und Kapazität und Klarheit zu liefern, genau dann, wenn dem internen Team beides ausgeht.

Das ist keine Kritik an internen Teams. So laufen SAP-Programme eben häufig. Das interne Team ist überlastet. Der Systemintegrator hat eigene Prioritäten. Entscheidungen stauen sich, der Umfang driftet. Sechs Monate in einem zwölfmonatigen Programm öffnet jemand das Issue-Log und findet zwanzig Einträge mit dem Vermerk „zu klären“, die dort seit Woche drei liegen.

Meist kommt der Anruf genau dann.

Manche Berater werden schon im Blueprint oder in der Planung geholt. Viele bekommen den Anruf mitten im Projekt, oft nach zwei oder drei Monaten schleppenden Fortschritts oder verpasster Übergaben. Die Berichte an den Lenkungsausschuss stehen auf Orange. Das Team arbeitet hart. Der Fortschritt ist langsam, und niemand kann genau sagen, warum.

1. ExploreWorkshops und LückenFit-to-Standard-Workshops, Lücken dokumentiert
2. RealizeAufbau und WalkthroughsKonfiguration und Erweiterungen. Mitten im Projekt kommen meist die Sanierungsanrufe
3. DeployUAT-Triage und CutoverKonfigurations-, Prozess- oder Schulungslücke? Die Triage entscheidet
4. HypercareStabilisierungDer erste Monatsabschluss und die Warteschlange offener Probleme

Die typischen Einstiegspunkte:

1. Der Umfang ist abgedriftet. Was in Explore abgenommen wurde, deckt sich nicht mehr mit dem, woran das Umsetzungsteam arbeitet. Anforderungen kamen informell in Workshops hinzu, das Änderungsprotokoll wurde nicht gepflegt, und niemand hat eine verbindliche Umfangsliste.
2. Ein kritischer Arbeitsstrang steht still. Die Datenmigration hängt seit Wochen bei derselben Fehlerquote fest, ohne Plan zur Verbesserung. Im UAT werden mehr Fehler geöffnet als geschlossen.
3. Der Go-live-Termin steht fest, und der Plan trägt ihn nicht. Der Vorstand hat den Termin gesetzt. Der Plan wurde nicht mit dem tatsächlichen Fortschritt abgeglichen. Der Programmleiter weiß, dass der Verlauf den Termin verfehlt, hat aber noch nicht eskaliert.

In jedem dieser Fälle besteht die Aufgabe nicht darin, dem bestehenden Plan weitere Leute hinzuzufügen. Sie besteht darin, hinzusehen, was tatsächlich passiert, das Problem klar zu benennen und einen Weg nach vorn zu erarbeiten. Diese Sanierungsabfolge beschreibt mein Leitfaden SAP-Projekte wieder auf Kurs bringen.

Klärung von Umfang und Prozessen

Manchmal stimmt die Konfiguration, aber der Prozess drumherum ist kaputt. Ein häufiges Muster: Das Team hat gegen ein Fit-to-Standard-Dokument aus Explore konfiguriert, und die Fachanwender haben die Konfiguration seit der Abnahme nicht gesehen. Man hat ihnen erzählt, was gebaut wird, aber es ihnen nicht gezeigt.

Die Lösung ist nicht technisch. Es ist eine Gesprächslücke. Aufgabe ist, die Fachanwender vor dem UAT durch die Konfiguration zu führen und eine klare Änderungsliste zu erstellen, bevor das Testen beginnt.

Glamourös ist das nicht. So sieht die Arbeit aus.

Übersetzen zwischen Technik und Fachbereich

SAP-Programme liefern regelmäßig etwas technisch Korrektes, das der Fachbereich nicht nutzen kann. Eine Preisfindung, die in 90 % der Fälle funktioniert und bei Exportaufträgen bricht. Eine Warenbewegung, die korrekt bucht, aber einen Finanzbeleg erzeugt, den das Abstimmungsteam nicht wiedererkennt.

Die funktionale Beratung schließt diese Lücke. Nicht als die technisch stärkste Person im Raum, sondern durch ein Verständnis von Systemverhalten und geschäftlichen Auswirkungen, das ausreicht, damit die richtigen Leute die richtige Entscheidung treffen können.

UAT-Begleitung

Im Benutzerabnahmetest (UAT) zeigt sich, ob die angesammelten Entscheidungen eines Programms tragen oder zusammenbrechen. Jede Abkürzung in Explore, jede informelle Umfangserweiterung und jeder auf Überblicksebene geschriebene Testfall taucht hier auf.

Gute UAT-Begleitung heißt, Fehler richtig zu triagieren und Konfigurationslücken von Prozesslücken und Schulungslücken zu trennen. Sie heißt auch, die Stimmung zu steuern, wenn Fachanwender auf eine Serie von Fehlern stoßen, die ihr Vertrauen in das ganze Programm erschüttert. Ohne das wird jeder Fehler in einer UAT-Sitzung zum Anlass, den Go-live infrage zu stellen, meist weil die Triage schwach war und niemand definiert hatte, was „Go-live-bereit“ bedeutet.

Stabilisierung nach dem Go-live

Die unglamouröseste Arbeit in der SAP-Beratung ist die Hypercare. Der Go-live ist geschafft, die Jubelmails sind verschickt, das Einführungsteam beginnt abzuziehen. Dann kommt der erste Monatsabschluss. Buchungen passen nicht zum Abstimmungsformat. Fertigungsaufträge werden abgeschlossen, aber nicht abgerechnet. Der Helpdesk füllt sich mit Anwendern, die geschult, aber nicht auf Sonderfälle vorbereitet wurden.

Hier entsteht ein Großteil des echten Werts, und hier sind die meisten Programme unterbesetzt. Das Hypercare-Team arbeitet die Warteschlange systematisch ab, trennt systemische Probleme von Einzelfehlern und baut das Vertrauen in das System wieder auf.

Die Struktur der Arbeit hat sich nicht verändert. Die Zeitaufteilung schon.

Dokumentation entwirft sich weitgehend selbst. SAP Joule for Consultants, seit 2025 allgemein verfügbar, beantwortet Konfigurationsfragen aus SAPs eigener Wissensbasis, einschließlich SAP-Hinweisen, und erklärt ABAP-Code. Joule-basierte Assistenten in SAP Cloud ALM entwerfen Anforderungen und Testfälle aus Workshop-Material. Funktionale Berater verbringen weniger Zeit mit dem Tippen von Dokumenten und mehr Zeit damit, Workshop-Ergebnisse zu hinterfragen.

Code wird häufiger geprüft als geschrieben. SAPs Entwicklerassistenten entwerfen Code, darunter SAP Build Code für Java- und JavaScript-Erweiterungen auf SAP BTP. Technische Berater prüfen, sichern und testen ihn heute.

Hypercare-Desks sehen weniger Routinefragen. Joule kann Routinefragen wie Urlaubssalden oder den Spesenstatus direkt in SAP-Anwendungen beantworten, was dem Hypercare-Desk etwas Volumen abnimmt. Die Beraterzeit verlagert sich auf Prozesslücken, Stammdatenprobleme und die Fälle, die einen Menschen brauchen.

Der Grund, einen Berater zu holen, hat sich nicht geändert. Berater, die diese Werkzeuge beherrschen, verbringen mehr Zeit mit Urteilsvermögen, Kommunikation und Eskalation und weniger mit Arbeit, die die KI inzwischen ordentlich entwirft. SAPs eigene Beschreibung von Joule for Consultants fasst gut zusammen, was es abdeckt.

Funktionale Berater spezialisieren sich auf Module wie FI, CO, SD, MM, PP, EWM oder SuccessFactors. Sie konfigurieren das System entlang der Geschäftsprozesse und schließen die Lücke zwischen SAP-Standard und den Anforderungen des Kunden. Ihr Wert ist Modultiefe plus Geschäftsprozesswissen.

Technische Berater (ABAP-Entwickler, SAP-BTP-Spezialisten, Integrationsarchitekten, Basis) bauen die Erweiterungen und Integrationen, die Konfiguration nicht abdecken kann. In modernen S/4HANA-Programmen verlagern Clean-Core-Prinzipien neue Erweiterungen auf SAP BTP oder freigegebene APIs, was andere Fähigkeiten verlangt als die klassische ABAP-Modifikation.

Projekt- und Programmmanager sorgen für die Struktur der Umsetzung: Governance, Risiko, Terminplan und Problemlösung, mit Überblick über das gesamte Programm, damit Probleme eskaliert werden, bevor sie zu Krisen werden.

Change-Management-Berater arbeiten an der menschlichen Seite: Schulung, Kommunikation, Einbindung und die Governance, die entscheidet, ob Anwender das System annehmen oder es umgehen.

Die meisten großen SAP-Programme brauchen alle vier. Im Mittelstand decken oft weniger Personen mehrere Rollen ab, und dort entstehen Lücken. Die Beratungs-Frameworks und die Fähigkeiten, die in der Beratung zählen, sind in allen vier Rollen dieselben. Wenn Sie als Berater Ihren eigenen Weg durch diese Rollen planen, zeigt SAPopedia Karrierepfade und Kurse, und ERPCV hilft Ihnen, diese Erfahrung gegenüber Recruitern darzustellen.

Der teuerste Beratungsfehler ist, jemanden zu spät zu holen. Ein Risiko-Review vor dem Cutover, vier bis sechs Wochen vor dem Go-live, kann kritische Probleme finden, solange noch Zeit bleibt. Ein Sanierungseinsatz nach einem gescheiterten Cutover kostet weit mehr. Er findet außerdem unter operativem Druck statt, in einer Organisation, die das Vertrauen in das System verloren hat.

Die Tabelle zeigt die Signale und die Hilfe, die jedes davon verlangt.

Signal	Was es meist bedeutet	Welche Hilfe Sie holen	Was diese Hilfe in zwei Wochen liefern sollte
Issue-Log-Einträge sind seit mehr als vier Wochen offen, ohne Lösungstermin	Ein Governance-Problem, kein technisches	Unabhängiger Programmberater	Eine Entscheidungsliste mit Verantwortlichen und Terminen
Go-live in 60 Tagen und keine Cutover-Probe	Ungetesteter Cutover; Überraschungen beim Go-live lassen sich nicht in Echtzeit auffangen	Cutover- oder Programmleitung	Ein geprobter Cutover-Plan und Go/No-go-Kriterien
Fachverantwortliche kommen nicht mehr zu den Terminen	Ohne gezieltes Eingreifen scheitert das UAT	Change-Lead plus ein funktionaler Lead	Walkthroughs mit Key-Usern und ein Plan zur Wiedergewinnung ihrer Beteiligung
Ein Arbeitsstrang hängt seit Wochen bei derselben Fehlerquote	Ursache nicht gefunden	Spezialist für diesen Arbeitsstrang	Eine Ursachenanalyse und ein Sanierungsplan
Das Reporting des Systemintegrators ist der einzige Blick auf die Programmgesundheit	Keine unabhängige Prüfung	Berater auf Kundenseite	Eine ehrliche Zustandsbewertung für den Sponsor

Was tun SAP-Berater in einem Projekt eigentlich?

Sie analysieren Geschäftsanforderungen, konfigurieren SAP entsprechend und schließen die Lücke zwischen SAP-Standardeinstellungen und dem, was der Fachbereich braucht. In Explore führen sie Fit-to-Standard-Workshops durch und dokumentieren Lücken. In Realize bauen sie die Konfiguration auf und arbeiten mit Entwicklern an Erweiterungen. In Deploy unterstützen sie das UAT, steuern Fehler und bereiten den Cutover vor. In der Hypercare lösen sie Probleme nach dem Go-live. Was in Stellenbeschreibungen fehlt, ist das Triagieren der Lücken zwischen den Phasen und das Halten der Lieferdisziplin unter Druck.

Wann brauchen Organisationen tatsächlich einen Berater?

Drei Situationen decken die meisten Einsätze ab. Programmsanierung, wenn der Umfang abgedriftet ist, ein Arbeitsstrang stillsteht oder der Go-live-Termin gefährdet ist. Spezialwissen, wenn dem Team ein Modul oder eine technische Fähigkeit fehlt, etwa die PP-PI-Konfiguration oder Integration auf SAP BTP. Und Governance, wenn die Organisation eine unabhängige Aufsicht über ein von einem Systemintegrator geführtes Programm will. Zu warten, bis sich die Lage verschlechtert, bevor man anruft, ist das häufigste Muster und das teuerste.

Was ist der Unterschied zwischen einem funktionalen und einem technischen SAP-Berater?

Funktionale Berater konfigurieren SAP so, dass es Geschäftsprozesse in Modulen wie FI/CO, SD, MM, PP oder EWM unterstützt, und arbeiten bei den Anforderungen direkt mit den Fachanwendern. Technische Berater bauen, was Konfiguration nicht leisten kann: ABAP- und BTP-Erweiterungen, Integrationen und die Systemadministration über Basis. Clean-Core-Prinzipien verschieben die technische Arbeit von ABAP-Modifikationen im System hin zu BTP-Erweiterungen und freigegebenen APIs.

Woran erkennen Sie, ob ein Berater Mehrwert liefert?

Drei Indikatoren. Der Berater bringt Annahmen ans Licht, die nie geprüft wurden, und Entscheidungen, die aufgeschoben wurden, statt bestehende Meinungen zu bestätigen. Entscheidungen, die wochenlang festhingen, werden endlich getroffen. Und das Issue-Log schrumpft, weil Ursachen behoben werden, nicht weil Einträge ohne Lösung geschlossen werden. Ein Log, das trotz Aktivität gleich lang bleibt, bedeutet, dass die Probleme systemisch sind oder die Korrekturen die Ursache nicht erreichen.

Was ist der schwierigste Teil der Beratungsarbeit?

Probleme zu benennen, die der Kunde schon kennt, aber nicht angegangen ist: der abgedriftete Umfang, die ungeschriebenen Testfälle, der Sponsor, der sich zurückgezogen hat. Dazu braucht es genug Vertrauen, um gehört zu werden, genug Glaubwürdigkeit, um geglaubt zu werden, und genug Direktheit, um Unbequemes auszusprechen. Berater, die die Beziehung auf Kosten der Diagnose schützen, sind teure Zustimmung.

Warum einen unabhängigen Berater holen, wenn der Kunde schon einen Systemintegrator hat?

Der Systemintegrator ist dafür verantwortlich, den vertraglich vereinbarten Umfang zu liefern. Ein unabhängiger Berater ist gegenüber dem Kunden für das Ergebnis verantwortlich. Das sind unterschiedliche Aufgaben. Der Berater auf Kundenseite hinterfragt Designannahmen und prüft, ob das Design die fachlichen Anforderungen erfüllt. Er schützt die kommerzielle Position des Kunden in der Änderungssteuerung und gibt der Führung einen Blick auf die Programmgesundheit, der nicht durch das Reporting des Integrators gefiltert ist. Das ist ein struktureller Interessenkonflikt, keine Kritik an Integratoren.