Die Konfigurationsdokumentation im SAP-Projekt

2017-01-31

Die Dokumentation der Anwendungskonfiguration - des Customizings - ist in den meisten SAP-Projekten ein echtes Trauerspiel. Was dabei oft entsteht - wenn etwas entsteht - ist in aller Regel nicht zu gebrauchen. Ich empfehle daher Unternehmen, die nicht Willens oder in der Lage sind, einen angemessenen Zustand dieser Dokumentation sicherzustellen, komplett darauf zu verzichten.

Geht das?

Davon ausgehend, dass der Zustand dieser Dokumentation in vielen Unternehmen ihrer Nicht-Existenz ziemlich nahe kommt, ist davon auszugehen.

Ideal ist das jedoch nicht.

Die optimale Konfigurationsdokumentation richtet sich an drei Adressaten:

• den zukünftigen Systemsupport, der Änderungen und Fehlerkorrekturen durchführen muss und die Auswirkungen der Konfiguration auf Prozesse und Stammdaten beurteilen muss, sowie
• zukünftige Projekte und Roll-Outs, die die Systemlösung erweitern und umbauen und zu diesem Zweck die existierende Lösung verstehen müssen,
• Reviewer und Auditoren, die eine Konfiguration nach verschiedenen (z.T. zum Zeitpunkt der Konfiguration noch nicht absehbaren) Fragestellungen analysieren und dazu verstehen müssen.

Die Struktur der Konfigurationsdokumente richtet sich im Grunde nach dem SAP-Einführungsleitfaden (IMG), auch wenn das nicht immer streng einzuhalten ist, da einzelne Konfigurationspunkte mehrfach im IMG enthalten sind und die Struktur mancher IMG-Punkte etwas "willkürlich" gehalten sind. Auch kann man nicht streng beispielsweise für "jeden IMG-Level-2-Knoten" ein Dokument verlangen, da die Tiefe der IMG-Struktur von Modul zu Modul unterschiedlich ist.

Jeder Abschnitt eines Konfigurationsdokuments sollte als Referenz folgende Angaben enthalten:

• IMG-Menüpfad
• Transaktion zum Aufruf der Konfiguration
• Konfigurationsobjekt (Transportschlüssel)

Den Namen des Konfigurationsobjekts erhalten Sie, in dem Sie im IMG den Eigenschaften-Dialog des IMG-Knotens aufrufen und dort auf das Tab "Maint.-Object" wechseln. Der Vorteil der Angabe des Konfigurationsobjekts liegt darin, dass Sie pro Konfigurationsschritt eine eindeutige Identifkation haben, die Sie als Abgleich gegen die Objektliste des SAP-Transportauftrags abgleichen können, mit dem Sie die Einstellungen in das produktive System transportieren. Somit können Sie jederzeit sicherstellen, dass alles, was Sie produktiv setzen, auch angemessen dokumentiert ist. Wenn man dann noch in einer Suchmaschine über das Konfigurationsobjekt nach allen Konfigurationsdokumenten suchen kann, die dieses Objekt beschreiben, hat man ein sauber dokumentiertes System gewonnen!

Inhaltlich sollte dann kein Screenshot folgen. Das kann man eigentlich zur Grundregel erfolgreicher Konfigurationsdokumentation machen: keine Screenshots.

Es interessiert niemanden, was konfiguriert wurde. Das kann man im System nachschauen. Interessant ist einzig warum etwas konfiguriert wurde. Auch hier ist vieles selbsterklärend oder offensichtlich, manches jedoch nicht. Diese Beschreibung gehört in die Konfigurationsdokumentation. Auch sind Verweise auf Anforderungen, wie sie im Designdokument niedergelegt wurden, hilfreich.

Auch gibt es Einstellungen, bei denen man für zukünftige Änderungen Vorgaben z.B. für die Namenskonvention oder für die Struktur und Zulässigkeit bestimmter Einstellungen machen möchte. Auch das gehört hier hin.

Vielleicht noch ein Wort zur Protokollfunktion einer Dokumentation. Ich habe oben geschrieben: "keine Screenshots". Oftmals wird mir entgegnet, dass es auch Sinn einer Dokumentation sein soll, Änderungen und frühere Zustände einer Konfiguration nachzuverfolgen.

Dazu zwei Anmerkungen:

• Alle Änderungen an der Konfiguration eines produktiven SAP-Systems müssen (sollten und werden normalerweise) über das SAP-Transportwesen aus einem Entwicklungssystem in das produktive System übertragen. Damit kann man im Produktivsystem jederzeit alle Änderungen an einem Konfigurationsobjekt nachvollziehen, ohne dass es dazu einer zusätzlichen Dokumentation bedarf.
• Darüber hinaus ist es auch im Entwicklungssystem interessant, Änderungen nachzuvollziehen. Zu diesem Zweck gibt es im SAP-Standard eine Tabellenprotokollfunktion (DBTABLOG). Diese wird über einen Profilparameter global eingeschaltet und gilt dann für die meisten Customizing-Tabellen. Aus historischen Gründen gibt es eine Reihe von Tabellen, bei denen die Protokollfunktion standardmäßig nicht eingeschaltet ist. Hier sollte man sich beim Aufsetzen eines neuen Systems die Arbeit machen, und das Protokollflag einmal setzen.

Eine saubere Konfigurationsdokumentation ist aufwändig - aber hilfreich. Eine Alibi-Konfigurationsdokumentation, wie sie in vielen Unternehmen gelebt wird (z.B. nur Screenshots) ist überflüssig und Ressourcenverschwendung und kann getrost entfallen.

Im nächsten Artikel beschreibe ich die Spezifikation und Dokumentation von Zusatzentwicklungen.