Key User für SAP aufbauen: Auswahl, Aufgaben und Wissenstransfer
Die Rolle entscheidet mehr über den Verlauf eines Umstiegs als jedes Werkzeug. Und sie scheitert selten an den Menschen, fast immer an fehlender Zeit und unklaren Grenzen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Rolle wird vergeben, aber nicht ausgestattet
In vielen Projekten wird die Rolle in einer Sitzung besetzt: Jeder Fachbereich benennt jemanden, die Namen kommen in eine Liste, fertig. Was dabei fehlt, ist die Ausstattung. Es gibt keine Beschreibung, was die Person entscheiden darf und was nicht, keine Freistellung von der bisherigen Arbeit und keine Vertretung für den Fall, dass sie ausfällt. Die Folge ist berechenbar: Die benannte Person macht die Projektaufgaben zusätzlich zum Tagesgeschäft, also abends, also unvollständig.
Der zweite Fehler ist die Auswahl nach Verfügbarkeit. Benannt wird, wer gerade Luft hat, und das ist in aller Regel nicht die Person, die den Prozess am besten kennt. Für ein Projekt, dessen wichtigste Aufgabe das Treffen fachlicher Detailentscheidungen ist, ist das ein schlechter Tausch. Die Entscheidungen fallen dann später, im Test, unter Zeitdruck und meistens von jemandem, der sie eigentlich nicht treffen sollte.
Der dritte Punkt zeigt sich erst nach dem Start. Wenn Wissen nicht ausdrücklich weitergegeben wird, bleibt es bei den wenigen, die im Projekt dabei waren. Der erste Monat nach der Umstellung ist dann eine Dauerbelastung für drei bis vier Personen, und ein Jahr später hängt der gesamte Anwendungsbetrieb an ihnen. Diese Abhängigkeit fällt niemandem auf, solange alle da sind, und sie wird teuer, sobald jemand geht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufbau, Schritt für Schritt
Sechs Stationen von der Beschreibung der Rolle bis zum Betrieb danach. Die Reihenfolge folgt dem Projektverlauf, und die ersten beiden Schritte gehören ausdrücklich vor die Benennung der Personen.
- 1
Rolle beschreiben, bevor Namen fallen
Schreibt auf, welche Aufgaben die Rolle umfasst, welche Entscheidungen sie trifft, wie viel Zeit sie beansprucht und wie lange sie gelten soll. Klärt in derselben Runde, wer im Zweifel entscheidet, wenn zwei Bereiche unterschiedlicher Meinung sind. Erst danach werden Personen angesprochen, denn eine Anfrage ohne beschriebene Rolle erzeugt Zusagen, die später niemand einhalten kann.
Geschafft, wenn: Eine Rollenbeschreibung auf einer Seite, abgestimmt mit den Führungskräften der beteiligten Bereiche.
- 2
Personen auswählen und Vertretung festlegen
Sucht je Bereich eine Person mit Prozesswissen und Ansehen, dazu eine Vertretung, die dieselben Sitzungen besucht. Die Vertretung ist kein Luxus: Urlaub, Krankheit und Wechsel treffen jedes Projekt, und ohne zweite Person ist der Bereich in diesen Wochen ohne Stimme. Lasst die Freistellung von der jeweiligen Führungskraft schriftlich bestätigen.
Geschafft, wenn: Eine besetzte Liste mit Person, Vertretung, freigestelltem Anteil und Bestätigung der Führungskraft.
- 3
Grundlagen und Delta gemeinsam schulen
Baut zuerst eine gemeinsame Grundlage auf, damit alle dieselben Begriffe verwenden, und behandelt danach die Unterschiede zum heutigen System. Für den Umstieg auf SAP S/4HANA gehören dazu der Geschäftspartner als führendes und obligatorisches Objekt, die Pflege über die Transaktion BP und die Umleitung der gewohnten Einstiege sowie die geänderte Ablage im Rechnungswesen mit dem Universal Journal.
Geschafft, wenn: Ein einheitlicher Kenntnisstand in der Gruppe und eine Liste der Punkte, die im eigenen Prozess nachgearbeitet werden müssen.
- 4
Im Test die Verantwortung übernehmen lassen
Key User schreiben die Testfälle für ihren Bereich, führen sie durch und bewerten die Ergebnisse. Das ist die wirksamste Einarbeitung, die es gibt, weil sie am eigenen Prozess stattfindet und weil Fehler dabei nichts kosten. Gebt der Gruppe dafür ein festes Zeitfenster in der Woche, das nicht verhandelbar ist, sonst wird es das Erste, was dem Tagesgeschäft weicht.
Geschafft, wenn: Getestete und abgenommene Abläufe je Bereich, jeweils mit Namen und Datum, und eine Liste offener Punkte mit Verantwortung.
- 5
Wissen an die übrigen Anwender weitergeben
Die Einweisung der Kollegen übernehmen die Key User selbst, in kleinen Gruppen und an den Vorgängen, die diese Gruppe täglich braucht. Ergänzt das um kurze Anleitungen nach einheitlichem Muster. Plant die Termine so, dass zwischen Einweisung und Umstellung nur wenige Wochen liegen, denn Gelerntes ohne Anwendung verfällt schnell.
Geschafft, wenn: Eingewiesene Anwender je Bereich und ein gepflegter Satz kurzer Anleitungen, den die Key User selbst verantworten.
- 6
Die Rolle in den Betrieb überführen
Legt fest, wie die Rolle nach dem Start weitergeht: welcher Anteil der Arbeitszeit dafür vorgesehen ist, welche Anfragen bei den Key Usern landen und welche direkt zur IT gehen, wie oft sich die Gruppe austauscht und wer nachrückt. In der Public-Variante kommt hinzu, dass SAP für Anpassungen durch Key User eine eigene, eingeschränkte Sprachversion vorsieht, die Grenze zwischen Anpassung und Entwicklung sollte also ebenfalls beschrieben sein.
Geschafft, wenn: Eine Betriebsvereinbarung für die Rolle, an der sich Anwender, Key User und IT gleichermaßen orientieren können.
Was ein Key User tut und was nicht
- 01 Tut: fachliche Detailfragen im eigenen Bereich entscheiden und diese Entscheidungen dokumentieren.
- 02 Tut: Testfälle schreiben, testen und den eigenen Bereich mit Namen und Datum abnehmen.
- 03 Tut: Kollegen einweisen und die kurzen Anleitungen für die täglichen Vorgänge pflegen.
- 04 Tut nicht: den ersten Ansprechpartner für jede technische Störung spielen.
- 05 Tut nicht: Entscheidungen treffen, die mehrere Bereiche oder das Berechtigungskonzept betreffen.
- 06 Braucht: freigestellte Zeit, eine benannte Vertretung und einen Weg zur Eskalation.
Was die Rolle tragfähig macht
Sechs Festlegungen entscheiden darüber, ob aus benannten Namen eine funktionierende Rolle wird. Keine davon kostet Lizenzen, alle kosten Führungsentscheidungen.
Die Rolle auf eine Seite schreiben
Haltet fest, welche Entscheidungen ein Key User trifft, welche er vorbereitet und welche außerhalb seiner Zuständigkeit liegen. Ergänzt, an wen er eskaliert und wer im Zweifel entscheidet. Diese eine Seite verhindert die zwei häufigsten Konflikte: eine Person, die alles entscheiden soll, und eine, die nichts entscheiden darf.
Nach Prozesswissen auswählen, nicht nach Kalender
Gesucht sind Leute, die ihren Prozess mit allen Ausnahmen kennen, die im Bereich Ansehen genießen und die erklären können, ohne zu belehren. Technisches Vorwissen ist nützlich, aber nachrangig, denn es lässt sich lernen. Prozesswissen und Ansehen lassen sich in der Projektlaufzeit nicht aufbauen.
Zeit verbindlich freistellen und die Vertretung besetzen
Ein Anteil ohne Entlastung ist keine Freistellung, sondern eine Erwartung. Legt einen Anteil fest, benennt, wer die Aufgaben in dieser Zeit übernimmt, und lasst die Führungskraft des Bereichs beides bestätigen. Nur so wird aus der Zusage eine Planung.
Am eigenen Prozess qualifizieren, nicht am Foliensatz
Die Einarbeitung sollte an euren echten Abläufen entlanglaufen und dort ansetzen, wo sich etwas geändert hat. Für den Umstieg auf SAP S/4HANA sind das typischerweise der Geschäftspartner als führendes Objekt für Kunden und Lieferanten, die Oberfläche und die Neuerungen im Rechnungswesen. Ein Kurs auf dem Standard ist die Grundlage, die Anwendung auf den eigenen Prozess ist der Ertrag.
Die Anleitungen von den Key Usern selbst schreiben lassen
Wer eine Anleitung für die eigenen Kollegen schreibt, prüft dabei den eigenen Kenntnisstand gründlicher als in jedem Test. Gebt ein einheitliches Muster vor und begrenzt den Umfang, damit daraus keine Handbücher werden. Zwei Seiten je Vorgang, mit den drei häufigsten Fehlern am Ende, sind die brauchbarste Form.
Die Rolle über den Start hinaus planen
Legt vor der Umstellung fest, wie die Rolle danach aussieht: Anteil der Arbeitszeit, Zuständigkeit für Anfragen, regelmäßiger Austausch zwischen den Bereichen und eine benannte Nachfolge. Ohne diese Festlegung endet die Rolle mit dem Projektabschluss, und das Wissen zerstreut sich innerhalb eines Jahres.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum die Rolle im Betrieb wichtiger ist als im Projekt
Im Projekt fällt die Arbeit der Key User auf, weil sie in Sitzungen und Testplänen sichtbar ist. Der eigentliche Wert entsteht danach. Eine gut besetzte Rolle fängt einen großen Teil der Anfragen ab, die sonst als Störungsmeldung bei der IT landen, obwohl es sich um fachliche Fragen handelt. Der Unterschied ist erheblich, weil eine fachliche Frage von einer fachlichen Person in Minuten beantwortet wird und im technischen Support eine halbe Stunde Übersetzung kostet.
Der zweite Effekt betrifft die Qualität der Meldungen, die tatsächlich zur IT gehen. Wenn ein Key User eine Anfrage vorher sortiert, kommt sie mit Beispielbeleg, Uhrzeit und Beschreibung des erwarteten Verhaltens an, statt als Satz über ein Programm, das nicht funktioniert. Diese Vorarbeit verkürzt Bearbeitungszeiten spürbar, und sie ist der Grund, warum sich der freigestellte Anteil betriebswirtschaftlich rechnet.
Der dritte Effekt ist die Veränderungsfähigkeit. Ein System, das regelmäßig aktualisiert wird, verlangt regelmäßige kleine Anpassungen im Arbeitsalltag. Häuser mit funktionierender Key-User-Rolle bekommen das mit einer Rundmail und einer kurzen Einweisung hin. Häuser ohne diese Rolle brauchen dafür jedes Mal ein kleines Projekt, und deshalb schieben sie Aktualisierungen auf.
Was Key User beim Umstieg konkret erklären müssen
Drei Änderungen erzeugen die meisten Rückfragen. Die erste betrifft die Stammdaten: Der Geschäftspartner ist in SAP S/4HANA das führende und obligatorische Objekt für Kunden- und Lieferantenstammdaten, gepflegt wird über die Transaktion BP, und die gewohnten Einstiege für Kunden- und Lieferantenstamm werden dorthin umgeleitet. Wer jahrelang mit Kürzeln gearbeitet hat, hält das zunächst für einen Fehler und braucht eine kurze, konkrete Erklärung.
Die zweite betrifft die Oberfläche. SAP Fiori ist die vorgesehene Oberfläche für SAP S/4HANA, in der Installationsanleitung zum Release 2025 steht ausdrücklich, dass Fiori installiert und konfiguriert werden muss, um die volle Nutzererfahrung zu erhalten. In On-Premise und in der Private-Variante bleiben klassische Transaktionen und das SAP GUI daneben verfügbar. Für Anwender heißt das: Es gibt einen neuen Hauptweg und einen bekannten Nebenweg, und beide sollten benannt sein, damit niemand rät.
Die dritte betrifft das Rechnungswesen. Mit dem Universal Journal in der Tabelle ACDOCA lesen interne und externe Sicht aus derselben Quelle, die früheren Summensätze und Indextabellen sind entfallen. Für Anwender wirkt sich das vor allem auf Auswertungen aus, die anders aufgebaut sind als gewohnt. Ein Key User, der die drei bis fünf wichtigsten Auswertungen seines Bereichs neu zeigen kann, nimmt der Umstellung an dieser Stelle den größten Teil ihrer Unruhe.
Wie ihr die Rolle vor Überlastung schützt
Der häufigste Verlauf ist der schleichende: Aus einer klar beschriebenen Rolle wird nach einigen Monaten die Person, die alles weiß und deshalb alles gefragt wird. Dagegen hilft eine ausdrückliche Abgrenzung, die auch die Kollegen kennen, und eine zweite Anlaufstelle für alles, was technisch ist. Wenn Anwender wissen, wohin sie mit einer Störung gehen und wohin mit einer fachlichen Frage, entlastet das die Rolle mehr als jede Absichtserklärung.
Zweitens braucht die Rolle einen Takt. Ein fester Termin, an dem sich die Key User der verschiedenen Bereiche austauschen, macht aus Einzelpersonen eine Gruppe. Dort werden wiederkehrende Fragen erkannt, gemeinsame Antworten festgelegt und Aufgaben verteilt. Ohne diesen Takt löst jeder dieselben Fragen für sich, und niemand merkt, dass es dieselben sind.
Drittens gehört die Nachfolge in die Planung. Legt fest, wer eingearbeitet wird und ab wann, und lasst diese Person von Anfang an bei den Terminen dabei sein. Wissen, das nur in einem Kopf liegt, ist kein Erfolg der Einführung, sondern ein Risiko, das erst sichtbar wird, wenn es zu spät ist.
Die Grenze zwischen Anpassung und Entwicklung
In modernen SAP-Systemen können Key User mehr selbst anpassen als früher, und das ist ausdrücklich vorgesehen: Neben der Sprachversion für die Cloud-Entwicklung führt SAP eine eigene, eingeschränkte Version für Key User. Damit lassen sich Anpassungen im vorgesehenen Rahmen vornehmen, ohne dass daraus eine Entwicklung im klassischen Sinn wird.
Für euer Haus lohnt es sich, die Grenze schriftlich zu ziehen. Was dürfen Key User selbst ändern, was geht über einen Antrag an die IT, und was ist in jedem Fall Entwicklungsarbeit? Diese Abgrenzung schützt beide Seiten: die Key User vor einer Verantwortung, die sie nicht tragen wollen, und den Betrieb vor Anpassungen, die niemand mehr überblickt.
Nützlich ist dabei ein Blick auf die Erweiterungsstrategie insgesamt. SAP unterscheidet Side-by-Side auf der SAP Business Technology Platform und On-Stack mit ABAP Cloud im System selbst, und beides ist Entwicklungsarbeit. Was Key User tun, liegt davor, und genau deshalb sollte die Grenze bekannt sein, bevor jemand versehentlich darüber hinausgeht.
Wie viele Key User ein Haus braucht
Eine feste Zahl gibt es nicht, aber einen brauchbaren Zuschnitt. Sinnvoll ist eine Person je Prozess, der eigene Entscheidungen braucht, nicht je Abteilung und schon gar nicht je Standort. Ein Haus mit Einkauf, Vertrieb, Lager, Produktion und Rechnungswesen kommt damit auf eine überschaubare Gruppe, und jede Person hat einen klar abgegrenzten Bereich, für den sie tatsächlich sprechen kann.
Zu klein geschnitten wird die Rolle, wenn eine Person mehrere Prozesse abdecken soll, die sie nur teilweise kennt. Dann trifft sie Entscheidungen für Bereiche, in denen sie nicht zu Hause ist, und der Fachbereich erkennt das Ergebnis später nicht als seines an. Zu groß geschnitten wird sie, wenn jede Abteilung jemanden entsendet: Die Gruppe wird zu groß für Entscheidungen, und die Termine verlieren an Verbindlichkeit.
Ein zweiter Zuschnitt betrifft die Standorte. Wenn mehrere Werke oder Gesellschaften denselben Prozess unterschiedlich fahren, ist genau das ein Ergebnis, das früh auf den Tisch gehört. Entweder ihr einigt euch auf einen gemeinsamen Ablauf, dann reicht eine Person, oder die Unterschiede bleiben, dann braucht jeder Standort eine Stimme. Diese Frage im Vorfeld zu klären ist deutlich billiger, als sie im Test zu entdecken.
Dazu passende Kurse
Damit alle in der Gruppe dieselben Begriffe verwenden, bevor es an den eigenen Prozess geht, sind SAP-Grundlagenkurse für Key User der übliche erste Schritt.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Wie viel Zeit brauchen Key User im Projekt?
Sollten Key User aus der IT oder aus dem Fachbereich kommen?
Was passiert mit der Rolle nach dem Produktivstart?
Wie verhindern wir, dass alles an einer Person hängt?
Dürfen Key User selbst Anpassungen vornehmen?
Passt thematisch dazu
Für einzelne Key User ist die Rolle der Anfang von etwas Größerem, denn der Weg aus der Fachabteilung in die SAP-Beratung führt genau über dieses Prozesswissen.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Key User so ausstatten, dass die Rolle trägt
Bei cmt baut ihr die gemeinsame Grundlage auf, von der Navigation bis zu den Änderungen in SAP S/4HANA. Danach fällt es Key Usern deutlich leichter, ihren eigenen Prozess zu erklären. Die Kurse laufen in Präsenz und Live-Online.