Die wichtigsten Rollen und Aufgaben im SAP-Einführungsteam

Eine SAP-Einführung braucht acht Rollen mit benannten, dedizierten Verantwortlichen: Executive Sponsor, Projektleiter, fachliche Leiter, IT-Leiter, Leiter Datenmigration, Leiter Change-Management, Implementierungspartner und einen unabhängigen Programmberater. RISE with SAP ergänzt die eigenen Delivery-Ansprechpartner von SAP und macht die Verantwortung für Clean Core ausdrücklich. Dieser Leitfaden richtet sich an Sponsoren und Programmleiter, die ein Team aufbauen oder reparieren. Er behandelt, was jede Rolle verantwortet, was ohne sie bricht, Teamgrößen nach Unternehmensgröße und wie Sie das Kompetenzzentrum (Center of Excellence, CoE) vor dem Go-live aufbauen. Prüfen Sie zuerst, welche der acht Rollen von jemandem besetzt ist, der auch ein Tagesgeschäft hat. Das ist Ihr größtes Risiko.

Ich habe über die Jahre mit Dutzenden SAP-Teams gearbeitet. Ich habe gut finanzierte Projekte mit erfahrenen Anbietern scheitern sehen, weil Schlüsselrollen fehlten oder auf Personen mit anderen Aufgaben verteilt waren. Ich habe auch unterfinanzierte Projekte gelingen sehen, weil die richtigen Leute im Raum saßen, voll engagiert und mit klarer Verantwortung.

Ein globaler Händler, mit dem ich gearbeitet habe, hatte Budget, Unterstützung der Führung und SAP als gewähltes ERP. Sein Einführungsteam war jedoch ein Desaster. Schlüsselrollen fehlten. Niemand verantwortete kritische Entscheidungen. Die Kommunikation lief in alle Richtungen, ohne irgendwo anzukommen. Termine rutschten, Kosten stiegen und das Vertrauen brach ein.

Jede SAP-Einführung braucht diese Rollen besetzt. Der Titel zählt weniger als die Verantwortung.

1. Executive SponsorEntscheidungen, Finanzierung, Eskalation
   ERP-ProgrammberaterUnabhängige Aufsicht, Risiko, Abstimmung der Führungsebene
2. ProjektleiterZeitplan, Budget, Koordination

• Fachliche Leiter und FachexpertenProzessdesign, Modulkonfiguration
• IT-Leiter und IT-TeamIntegration, Entwicklung, Sicherheit
• Leiter DatenmigrationDatenqualität, Ladereihenfolge, Cutover
• Leiter Change-ManagementSchulung, Akzeptanz, Kommunikation
• ImplementierungspartnerArchitektur, Integrationsdesign, Umsetzung

Rolle	Hauptverantwortung	Was ohne sie bricht
Executive Sponsor	Strategische Entscheidungen, Finanzierung, Eskalationsbefugnis	Driften, Streit um den Umfang, niemand entscheidet im Patt
Projektleiter	Zeitplan, Budget, teamübergreifende Koordination	Verzögerungen, ungelöste Blocker, Kostenüberschreitungen
Fachliche Leiter und Fachexperten	Fachliches Prozessdesign, Modulkonfiguration	Falsche Konfiguration, Workarounds nach dem Go-live
IT-Leiter und IT-Team	Integration, Entwicklung, Sicherheit, Performance	Technische Schulden, defekte Schnittstellen, Instabilität
Leiter Datenmigration	Datenqualität, Ladereihenfolge, Cutover-Genauigkeit	Unbrauchbare Daten, gescheiterter Go-live, monatelange Bereinigung
Leiter Change-Management	Schulung, Akzeptanz, Kommunikation	Widerstand der Anwender, parallele Tabellenkalkulationen
Implementierungspartner	Architektur, Integrationsdesign, Umsetzung	Überdimensionierung, Integrationsausfälle
ERP-Programmberater	Unabhängige Aufsicht, Risiko, Abstimmung der Führungsebene	Entscheidungen in Isolation, vermeidbare Fehler

Executive Sponsor

Der Sponsor ist kein Name auf einer Lenkungsausschuss-Folie. Er trifft die Entscheidungen, die sonst niemand treffen kann: Budget, Umfangsänderungen, Ressourcenzusagen über Abteilungen hinweg. Wenn die Rolle zeremoniell ist, driftet das Projekt.

Ich habe mit einem Unternehmen gearbeitet, das diese Rolle ausließ. Das Projekt driftete. Keine Entscheidungen, kein Fortschritt, das Geld versickerte.

Wirksame Sponsoren bleiben bis zum Ende der Hypercare. Sie nehmen nach dem Go-live an den monatlichen Sitzungen des Lenkungsausschusses teil und treffen die kleinen Entscheidungen, die Dinge lösen, die seit Wochen feststecken. Mein Leitfaden zum Aufsetzen eines SAP-Lenkungsausschusses beschreibt, wie Sie dieses Gremium strukturieren.

Projektleiter

Der Projektleiter führt das Tagesgeschäft: Zeitplan, Risikoregister, Koordination, Statusberichte. In einem großen SAP-Programm ist das eine Vollzeitrolle für jemanden, der es schon einmal gemacht hat.

Ich habe erlebt, wie ein Kunde mitten in der Einführung seinen leitenden Entwickler verlor. Das ganze Projekt stand wochenlang still, während er einen Ersatz suchte.

Das umgekehrte Problem ist ebenso schädlich. Ich arbeitete mit einem Unternehmen, das mehr als 30 Personen im Team hatte. Niemand wusste, wer Entscheidungen verantwortete. Einfache Änderungen brauchten fünf Meetings. Der Zeitplan dehnte sich allein durch den Kommunikationsaufwand von 12 auf 18 Monate.

Fachliche Leiter und Fachexperten

Diese Menschen übersetzen die Geschäftsabläufe in SAP-Konfiguration. Sie müssen das Geschäft gut genug kennen, um schlechte Prozesse in Frage zu stellen, und SAP gut genug, um zu wissen, was möglich ist.

Ich arbeitete mit einem Fertigungskunden, dessen Team glänzte, weil seine fachlichen Leiter vor dem Entwurf der Prozesse Zeit in der Fertigungshalle verbracht hatten.

Fachexperten, die nur halb dabei sind, hinterlassen immer Lücken. Entweder bekommt das Projekt ihre Aufmerksamkeit oder es bekommt ihren Namen auf einer Abnahmeliste. Das ist nicht dasselbe.

IT-Leiter und IT-Team

Das IT-Team verantwortet das technische Fundament: Entwicklung, Basis, Sicherheit, Integration und Performance. Auf S/4HANA verantwortet es auch die Clean-Core-Disziplin und hält kundeneigenen Code aus dem Kern heraus.

Die Integration unterschätzen die meisten Teams. Jede Verbindung zu einem Fremdsystem muss entworfen, gebaut, getestet und verantwortet werden. Schnittstellen brechen im UAT, wenn niemand die Datenflüsse abgebildet hat. Holen Sie die IT in die Blueprint-Workshops, nicht erst nach den Entscheidungen.

Leiter Datenmigration

Diese Rolle wird spät besetzt und knapp ausgestattet. Wenn Datenprobleme auftauchen, steht das Programm schon unter Termindruck.

Ein Kunde glaubte, er könne die Datenbereinigung überspringen. Großer Fehler. Sein System war monatelang nutzlos. Die Bereinigung der Daten unter einem Live-System kostet mehr als eine ordentliche Bereinigung vorab.

Ein dedizierter Migrationsleiter führt bei jedem Ladevorgang Abstimmungen durch, und so werden strukturelle Probleme vor dem Go-live sichtbar. Das passiert nicht, wenn die Rolle von jemandem mit drei weiteren Workstreams gehalten wird. Mein Beitrag dazu, warum SAP-Datenmigration scheitert, beschreibt die Methode.

Leiter Change-Management

Das ist die Rolle, die am durchgängigsten zu knapp besetzt wird. Ich habe erlebt, wie Systeme für Millionen ungenutzt standen, weil niemand ändern wollte, wie er arbeitet.

Ich habe eine technisch perfekte Einführung scheitern sehen, weil die Anwender sie hassten. Die Konfiguration war korrekt und das Prozessdesign solide. Aber die Menschen, die täglich damit arbeiteten, waren nicht in den Entwurf einbezogen worden. Sie verstanden nicht, warum sich Dinge geändert hatten, und nutzten weiter ihre alten Excel-Dateien.

Ein Handelskunde hatte Erfolg, weil er auf die Bedenken seines Kassenpersonals zum neuen System hörte und sein Vorgehen anpasste.

Das Minimum für ein Konzernprogramm sind zwei dedizierte Change-Management-Mitarbeiter. Eine Person kann nicht gleichzeitig Schulungsdesign, Kommunikation, Umgang mit Widerstand und Messung der Akzeptanz abdecken.

ERP-Programmberater

Ein unabhängiger Berater ist nicht der Implementierungspartner. Die Aufgabe ist Aufsicht und Kurskorrektur: prüfen, ob die Richtung noch sinnvoll ist, Risiken erkennen, die das Delivery-Team zu nah am Geschehen nicht sieht, und die Lücke schließen zwischen dem, was die Führung für den Stand hält, und dem, was tatsächlich der Fall ist.

Ich habe diese Rolle für Kunden mit starken Delivery-Teams, aber ohne unabhängige Stimme übernommen. Ich arbeitete mit einem Fertigungskunden, der fast die falschen Module eingeführt hätte, weil niemand seine Wachstumsstrategie mit seiner SAP-Roadmap verknüpft hatte.

Probleme früh zu erkennen ist die andere Hälfte. Ich habe einmal eine kritische Qualifikationslücke im Datenteam eines Kunden drei Monate bevor sie den Go-live verzögert hätte identifiziert. Wir behoben sie, bevor sie zur Krise wurde.

Das Acht-Rollen-Modell gilt weiter. Drei Dinge müssen Sie 2026 darin einbauen.

SAPs eigene Delivery-Ansprechpartner bei RISE

Bei RISE with SAP Private Cloud betreibt SAP die Infrastruktur und den technischen Betrieb. Im Dokument zu Rollen und Verantwortlichkeiten vereinbaren Kunden Services mit einem SAP Cloud Architect Advisor, einem Client Delivery Manager oder dem Team des SAP Private Cloud Customer Center. Nehmen Sie, wen SAP zuweist, neben dem Partnerteam in Ihre Besetzungsliste auf und benennen Sie auf Ihrer Seite die Person, die diese Beziehung verantwortet. On-Premise ist SAP Softwareanbieter, und das gilt dann nicht.

Clean Core und Verantwortung für Erweiterungen

In S/4HANA Cloud Public Edition ist Clean Core konstruktionsbedingt durchgesetzt: Erweiterungen laufen über freigegebene APIs, Key-User-Tools oder SAP BTP. In Private Cloud und On-Premise sind Modifikationen weiterhin möglich, aber jede erschwert Upgrades. Jemand muss diese Linie verantworten.

In größeren Programmen ist das ein dedizierter Clean-Core-Architekt oder BTP-Extension-Lead, der an den Lösungsarchitekten berichtet. In mittelständischen Programmen übernimmt es meist der Lösungsarchitekt, aber die Verantwortung muss schriftlich festgehalten sein. Wenn Sie Partner bewerten, fragen Sie, wie viele BTP-Erweiterungen sie geliefert haben, und lassen Sie sich Beispiele zeigen.

KI verändert die Produktivität, nicht die Verantwortung

SAP Joule for Consultants (seit 2025 allgemein verfügbar) beantwortet Konfigurationsfragen aus SAPs eigener Wissensbasis und erklärt ABAP-Code. SAP Build Code erzeugt Java- und JavaScript-Erweiterungscode auf SAP BTP. Microsoft Copilot entwirft Vorlagen für den Lenkungsausschuss und Statusberichte.

Die Gewinne zeigen sich bei Rollen mit viel Workflow wie Anforderungsanalyse, Statusberichten und kundeneigener Entwicklung, und nur, wenn Menschen die Tools konsequent nutzen. Behandeln Sie jede Produktivitätszahl, die man Ihnen nennt, als Behauptung, die Sie in Ihrem eigenen Programm prüfen.

Das Team ist etwas kleiner, als derselbe Umfang vor diesen Tools erforderte, aber nicht dramatisch. Schreiben Sie die Tools in die Rollendefinitionen, statt sie als Nebentätigkeit zu behandeln. KI entwirft schneller. Menschen verantworten weiterhin, was der Entwurf sagt.

Die Tabelle zeigt typische Größenordnungen für jede Rolle nach Unternehmensgröße. Verstehen Sie sie als Ausgangspunkt und passen Sie sie an Umfang und Region an. Für dieselbe Frage außerhalb von SAP siehe meinen Leitfaden zum ERP-Einführungsteam.

Rolle	Kleines Unternehmen	Mittelstand	Großunternehmen
Executive Sponsor	Senior Director	CIO oder CFO	C-Level mit Lenkungsausschuss
Projektleiter	1 in Vollzeit	1-2 in Vollzeit	Programmmanager plus Projektleiter je Workstream
Fachliche Leiter	1-2 je Modul	Dediziert je Modul	Mehrere je Modul
IT-Team	2-3 (geteilt)	4-6 (dediziert)	8+ Spezialisten
Datenmigration	1 Leiter	1 Leiter plus Analysten	Dedizierter Workstream
Change-Management	Mindestens 1	Mindestens 2	3-5 dediziert
Clean-Core- oder BTP-Extension-Lead	Lösungsarchitekt	Lösungsarchitekt	Dedizierte Rolle
SAP-Ansprechpartner (RISE)	Benannter Ansprechpartner	Benannter Ansprechpartner	Benannte Ansprechpartner mit vierteljährlichen Reviews
Implementierungspartner	5-10 Berater	15-25 Berater	30+ mit einem Programmdirektor

Technische Fähigkeiten bringen das System zum Laufen. Emotionale Intelligenz entscheidet, ob Menschen es nutzen.

Ich arbeitete mit einem Fertigungsunternehmen, in dem der Lagerleiter in Meetings lächelte, das Projekt aber hinter den Kulissen unterlief. Ein aufmerksamer Change-Manager erkannte die Zeichen früh und machte ihn zum Fürsprecher. Es erst zum Go-live zu entdecken, wäre viel schwerer zu beheben gewesen.

Der Projektleiter eines Kunden war technisch brillant, konnte seine Botschaft aber nicht anpassen. Ein CFO braucht eine andere Kommunikation als Lagerpersonal. Das Ergebnis war geringe Zustimmung in der gesamten Organisation und ein schmerzhafter Go-live.

Die Antwort auf „Mitarbeiter oder Berater?“ lautet fast immer: beides.

Mitarbeiter kennen das Geschäft: die Prozesse, die Politik und die Workarounds, die niemand dokumentiert. Ich arbeitete mit einem Fertigungsunternehmen, dessen Mitarbeiter Einführungsprobleme bemerkten, die externe Berater völlig übersahen. Diese Erkenntnisse bewahrten es vor einer katastrophalen Lagerkonfiguration.

Mitarbeitern fehlt oft Einführungserfahrung. Ein Handelskunde bestand auf einem rein internen Team. Nach sechs Monaten lagen sie hoffnungslos zurück, weil sie SAP lernten, während sie es einführten.

Berater bringen Mustererkennung mit. Ich holte für einen Kunden einen Berater, der sofort einen Ansatz zur Datenmigration erkannte, der den Go-live zum Absturz gebracht hätte.

Das Risiko bei Beratern ist der Wissenstransfer. Wenn im Haus niemand das System lernt, laufen die Beraterhonorare lange nach dem Start weiter.

Das Modell, das funktioniert: Tandems (Shadow Pairs). Ein Pharmakunde gab jedem Berater ein internes Gegenüber, das diesen Bereich nach dem Go-live verantworten wird. Der Berater liefert, das Gegenüber lernt, und das Wissen bleibt. Rund um dieses Modell machen sechs Praktiken den Unterschied:

1. Bauen Sie das Team auf, bevor Sie Software auswählen. Ein Kunde kaufte Module, die sein Team nicht warten konnte, und es folgten sechs Monate Chaos.
2. Stellen Sie Leute voll frei. Teilzeit heißt: Wenn Druck entsteht, gewinnt das Tagesgeschäft. Ich habe erlebt, dass kritische Konfiguration wochenlang wartete, weil jemand zu beschäftigt war.
3. Bringen Sie das Team nach Möglichkeit räumlich zusammen. Ein Fertigungskunde sparte Wochen an Hin und Her, indem er sein Team an drei Tagen pro Woche in denselben Raum setzte.
4. Legen Sie Eskalationswege früh fest. Ein Handelskunde hatte ein einseitiges Dokument, das genau zeigte, wie Entscheidungen die Kette hinaufliefen. Es ersparte unzählige Verzögerungen.
5. Halten Sie Entscheidungen mit ihrer Begründung schriftlich fest. Ich arbeitete mit einem Unternehmen, das festhielt, was es entschied und warum. Das ersparte endloses Wiederaufrollen, als mitten im Projekt neue Führungskräfte hinzukamen.
6. Markieren Sie Meilensteine unterwegs. Ein Fertigungskunde hielt monatliche Anerkennungsveranstaltungen ab. Eine Kleinigkeit, aber sie hielt die Moral durch eine zermürbende, 18 Monate dauernde Einführung hoch.

Der Fehler, den Unternehmen nach dem Go-live machen, ist die Auflösung des Einführungsteams. Genau dann muss das CoE Erweiterungen, Upgrades, Governance, die Schulung neuer Anwender und die Abstimmung der Konfiguration auf den tatsächlichen Geschäftsablauf übernehmen.

Planen Sie es während der Einführung. Ich hatte einen Fertigungskunden, der diesen Rat ignorierte. Drei Monate nach dem Go-live verließen seine zentralen Konfigurationsexperten das Unternehmen. Niemand wusste, wie man das Gebaute pflegt, und das System begann sofort zu verfallen.

Diese CoE-Rollen sollten Sie ab den ersten Monaten der Einführung einplanen.

CoE-Rolle	Hauptverantwortung
CoE-Direktor	SAP-Strategie, Abstimmung mit den Geschäftszielen, CoE-Betrieb
Lösungsarchitekt	Architektur, Integrationsdesign, Clean-Core-Governance
Clean-Core- oder BTP-Extension-Lead	Erweiterungskatalog, Analyse der Upgrade-Auswirkungen
Funktionale Berater	Modul-Optimierung, Prozessverbesserung
Technische Berater	Entwicklung, Basis, Performance, Sicherheit
Leiter Change und Schulung	Akzeptanz, Schulung, Kompetenzaufbau
Leiter Datengovernance	Stammdatenqualität und Standards
Integrationsleiter	Middleware, APIs, systemübergreifende Datenflüsse
Support-Leiter	Störungsbehebung, kontinuierliche Verbesserung
SAP-Beziehungsverantwortlicher (RISE)	Eskalationen an SAP, Service-Reviews, Roadmap-Abstimmung

Ein Pharmaunternehmen benannte Modulverantwortliche, die jede Änderung freigeben mussten, die ihren Bereich betreffen konnte. Diese Governance verhinderte die unkoordinierten Änderungen, die Systeme nach zwei oder drei Jahren meist schwer nutzbar machen.

Ein Kunde investierte 10 % seines CoE-Budgets in kontinuierliches Lernen. Drei Jahre später führte er neue Funktionen ein, an die seine Wettbewerber nicht herankamen. So sieht ein funktionierendes CoE aus.

Warum scheitern SAP-Einführungsteams, auch wenn der Plan solide aussieht?

Meist, weil der Plan die Technologie abdeckt und die Menschen ignoriert. Die typischen Muster: Schlüsselrollen, die von Leuten mit anderen Aufgaben besetzt sind, Fachexperten, die mitten im Projekt in den Betrieb zurückgeholt werden, und Change-Management, das als Schulungsfunktion behandelt wird. Wenn niemand eine Entscheidung verantwortet und es keinen Eskalationsweg gibt, bleiben Blocker wochenlang liegen, und das Projekt scheitert an der Koordination, nicht an der Technologie.

Welche Rollen sind in jeder SAP-Einführung unverzichtbar?

Sechs Rollen brauchen dedizierte, verantwortliche Personen: Executive Sponsor, Projektleiter, mindestens einen fachlichen Leiter je großem Modul, einen IT-Leiter, einen Leiter Datenmigration und einen Leiter Change-Management. Fehlt eine davon, zeigt sich die Lücke in den letzten Wochen vor dem Go-live. Change-Management ist am knappsten besetzt. Bei RISE kommt ein klarer Verantwortlicher für Erweiterungen und für die Beziehung zu den Delivery-Ansprechpartnern von SAP hinzu.

Was ändert sich beim Teamdesign für RISE with SAP?

SAP betreibt Infrastruktur und technischen Betrieb, daher arbeiten Sie mit von SAP zugewiesenen Ansprechpartnern wie einem Client Delivery Manager oder Cloud Architect Advisor. Nehmen Sie sie in die Besetzungsliste auf und benennen Sie Ihren eigenen Beziehungsverantwortlichen. Auch die Verantwortung für Clean Core muss ausdrücklich geregelt sein: ein dedizierter Architekt bei großen Programmen oder der Lösungsarchitekt bei mittelständischen.

Sollte ein SAP-Projektteam aus Mitarbeitern oder aus Beratern bestehen?

Aus beiden. Mitarbeiter bringen Geschäftskontext mit, den Berater nicht schnell nachbilden können. Berater bringen die Mustererkennung aus Einführungen mit, die Mitarbeitern meist fehlt. Stellen Sie jedem Berater ein internes Gegenüber zur Seite, das diesen Bereich nach dem Go-live verantworten wird, damit das Wissen bleibt, wenn die Berater gehen. Unternehmen, die das auslassen, zahlen oft jahrelang für Support, den sie selbst hätten leisten sollen.

Wann sollten Sie mit dem Aufbau des SAP-CoE beginnen?

Während der Einführung, idealerweise ab den ersten Monaten. Ihre besten CoE-Mitglieder sind meist Ihre stärksten Beitragenden in der Einführung, und wenn Sie bis zum Go-live warten, sind sie weitergezogen, bevor Sie sie erkannt haben. Ein Fertigungskunde, der wartete, verlor seine zentralen Konfigurationsexperten drei Monate nach dem Go-live, und niemand wusste, wie man das Gebaute pflegt.

Wie verändert KI das Teamdesign bei SAP im Jahr 2026?

Tools wie SAP Joule for Consultants, SAP Build Code und Microsoft Copilot steigern die Produktivität bei Rollen mit viel Workflow, wenn Menschen sie konsequent nutzen. Das Team ist etwas kleiner, als derselbe Umfang vor diesen Tools erforderte, aber nicht dramatisch. Bauen Sie die Tools in die Rollendefinitionen ein und lassen Sie die Verantwortung bei Menschen: KI entwirft schneller, Menschen verantworten weiterhin, was der Entwurf sagt.