Dokumentation, die Teamwechsel übersteht
Stand 2026-09-03
Dokumentation, die Teamwechsel übersteht, ist der Unterschied zwischen einer Datasphere-Landschaft, die ein Nachfolger vom ersten Tag an betreiben kann, und einer, für die das Ursprungsteam achtzehn Monate lang auf Abruf bleiben muss. Das Modul nennt vier dokumentationswürdige Kategorien - Architekturabsicht, KPI-Herkunft, Betriebs-Runbooks und die "Nicht anfassen"-Karte - statt allem, was das System ohnehin schon aufzeichnet. Bei Time-and-Material-Projekten sollten 10-15 % des Umsetzungsaufwands dafür eingeplant werden, in regulierten oder geprüften Umgebungen steigend auf 20-25 %; bei Festpreis-Leistungsbeschreibungen braucht es eine explizite, freigabegebundene Scope-Zeile, sonst wird sie zum Streitpunkt am Projektende. Für einen erfahrenen SAP-Analytics-Berater ist nachweisbare Dokumentationsqualität ein Bindungshebel: Ein Kunde, der für institutionelles Wissen von einem Auftragnehmer abhängt, hat einen echten Anreiz zu verlängern, statt die Einarbeitungskosten eines bei null startenden Nachfolgers zu tragen.
Was Sie lernen
- Die vier Kategorien von SAP-Analytics-Projektwissen identifizieren, die dokumentiert werden müssen, um Teamwechsel zu überstehen, und erklären, was jede Kategorie unersetzlich macht
- Die drei minimal tragfähigen Dokumentationsartefakte für eine Datasphere-Implementierung aufbauen – Space-Inventar, Entitätskatalog und Geschäftsregeln-Register
- Operative Runbooks für wiederkehrende SAP-Analytics-Prozesse schreiben, die ein Nachfolger beim ersten Versuch erfolgreich ohne Unterstützung des Autors ausführen kann
- Dokumentations-Deliverables in Festpreis- und Time-and-Material-SAP-Analytics-Verträgen korrekt scopen und bepreisen
Die Dokumentation, die zurückbleibt
Jedes SAP-Analytics-Programm erzeugt zwei Arten von Wissen: das Wissen, das im System lebt, und das Wissen, das in den Köpfen der Menschen lebt, die es gebaut haben. Wenn diese Menschen gehen – am Projektende, bei Vertragsverlängerung, durch Fluktuation – verdunstet die zweite Kategorie. Zurück bleibt eine Datasphere-Landschaft mit 400 Transformations-Views, eine BW/4HANA-InfoProvider-Hierarchie, die niemand mehr erklären kann, und eine Reihe von SAC-Stories, deren Datenmodelle technisch funktionieren, aber für niemanden mehr wartbar sind, der nicht im Raum war, als die Geschäftsregeln ausgehandelt wurden.
Dokumentation, die Teamwechsel übersteht, ist keine Dokumentation, die alles abdeckt. Es ist Dokumentation, die die richtigen Dinge in ausreichender Tiefe abdeckt, geschrieben für die spezifische Zielgruppe, die sie in 18 Monaten brauchen wird, wenn das ursprüngliche Team sich zerstreut hat und ein neuer Auftragnehmer am ersten Tag eines kritischen Enhancement-Zyklus eingearbeitet wird.
Voraussetzungen
- Praktische Erfahrung auf mittlerem Niveau in SAP-Analytics-Projekten
- Zunächst die Kernkonzepte wiederholen: C058, C047, C087
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein Pharmahersteller im mittleren Marktsegment steht sechs Wochen vor einem Datasphere- und SAC-Go-live.
- Das Anti-Pattern erkennen und vermeiden: Dokumentieren, was das System bereits dokumentiert – Feldsdefinitionen und Objekt-Metadaten werden in Word-Dateien dupliziert, die innerhalb von etwa sechs Monaten vom System abweichen.
- Die zentrale Entscheidung des Moduls anwenden: Was zuerst dokumentiert wird, wenn ein Teamwechsel bevorsteht – wählen Sie Standardmäßig die vier Kategorien, die aus dem System nicht rekonstruierbar sind: Architekturabsicht, KPI-Herkunft.
- Die Beherrschung mit dem KPI verfolgen: Abdeckung der kritischen KPI-Herkunft (Ziel: 100 % der 10-15 geschäftskritischen KPIs Ende-zu-Ende nachverfolgt).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Wissenskontrolle · die Schemata.