Der Monatsabschluss steht an, ein TI-Prozess bricht ab – und die einzige Person, die weiß, warum, ist im Urlaub. Oder hat das Unternehmen vor zwei Jahren verlassen. In „wenigen“ Umgebungen mit IBM Planning Analytics TM1 ist genau das der Normalfall: Das Modell ist über Jahre gewachsen, funktioniert meistens, aber niemand hat es je systematisch beschrieben. Wer sein Planning Analytics Modell dokumentieren will, steht deshalb vor einem Berg aus Regeldateien, Prozessen und Wissen in Köpfen.

Die gute Nachricht: Sie müssen nicht bei null anfangen und auch kein 200-seitiges Handbuch schreiben. Entscheidend ist, die richtigen Dinge in der richtigen Reihenfolge festzuhalten.

Warum gewachsene Planungsmodelle so schwer zu durchschauen sind

Planning Analytics ist flexibel – und genau das ist das Problem. Jede Anforderung aus dem Fachbereich lässt sich schnell umsetzen: ein neuer Cube hier, eine Regel dort, ein zusätzlicher TI-Prozess für den Import aus dem Vorsystem. Nach einigen Jahren entstehen so Abhängigkeiten, die niemand mehr vollständig überblickt:

• Regeln greifen per DB() auf andere Cubes zu, Feeder verweisen quer durchs Modell.
• TI-Prozesse rufen andere Prozesse auf, Chores starten sie in einer Reihenfolge, die „schon immer so war“.
• Dimensionen enthalten Elemente und Attribute, von denen unklar ist, ob sie noch genutzt werden.

Das Risiko ist nicht nur technisch. Wer eine Änderung nicht einschätzen kann, ändert entweder gar nichts – oder riskiert falsche Zahlen im Reporting.

Was in die Dokumentation eines Planning Analytics Modells gehört

Eine sinnvolle Dokumentation beantwortet die Fragen unterschiedlicher Zielgruppen. Bewährt hat sich eine Gliederung in drei Ebenen:

1. Fachliche Sicht (für Controlling und Management)

• Welche Planungs- und Reportingprozesse bildet das Modell ab?
• Welche Cubes stehen für welchen Zweck (z. B. Umsatzplanung, Personalkosten, GuV-Konsolidierung)?
• Woher kommen die Daten, und wie oft werden sie aktualisiert?
• Wie werden zentrale Kennzahlen berechnet?

2. Technische Sicht (für Entwickler und Power User)

• Cubes mit ihren Dimensionen, Regeln und Feedern
• Dimensionen mit Hierarchien und wichtigen Attributen
• TI-Prozesse: Zweck, Datenquelle, Parameter, aufgerufene Prozesse
• Chores mit Zeitplan und Reihenfolge
• Schnittstellen zu Vorsystemen (ODBC, Dateien, REST)

3. Betriebliche Sicht (für den laufenden Betrieb)

• Ablauf des Monatsabschlusses bzw. Planungszyklus – Schritt für Schritt
• Was tun, wenn ein Prozess abbricht? Wer wird informiert?
• Berechtigungskonzept: Gruppen, Zugriffe, Verantwortlichkeiten
• Ansprechpartner und Eskalationswege

Gerade die dritte Ebene fehlt fast immer – dabei ist sie im Ernstfall die wichtigste.

So gehen Sie bei einem bestehenden Modell vor

Bei einem gewachsenen Modell hat sich ein pragmatisches Vorgehen in vier Schritten bewährt:

1. Analyse durchführen: Erfassen Sie alle Objekte – Cubes, Dimensionen, Prozesse, Chores. Das geht heute weitgehend automatisiert, z.B. per TM1py.
2. Kritische Pfade identifizieren: Welche Prozesse und Cubes sind für Abschluss und Planung unverzichtbar? Dort beginnen Sie, nicht beim Randobjekt.
3. Abhängigkeiten sichtbar machen: Welche Regel greift auf welchen Cube zu, welcher Prozess ruft welchen auf? Eine einfache Übersichten oder Tabelle helfen oft mehr als Fließtext.
4. Aufräumen: Bei der Inventur fallen fast immer verwaiste Objekte auf – Test-Cubes, alte Prozesse, ungenutzte Attribute. Was nicht mehr gebraucht wird, sollte nach Rücksprache weg. Jedes gelöschte Objekt ist eines weniger, das dokumentiert werden muss.

Diese Analyse ist übrigens auch der erste Schritt jeder Modernisierung. Wer sein Modell dokumentiert hat, ist für den nächsten Versionswechsel deutlich besser aufgestellt.

Aus der Praxis: Wieso macht man eigentlich Systemkopien, also zu gegebener Zeit Objekte aus P (ggf. ohne Daten) wieder zurück in die Entwicklungsumgebung? Weil ansonsten nie die richtige oder ausreichend Zeit ist die Dev Umgebung auszuräumen und dort sammeln sich x verwaiste Objekte, die irgendwann Einfluss auf die Qualität Ihrer Deployments („…aber es lief doch in der Entwicklung – wo ist das Delta?“) haben können.

Die technische Dokumentation automatisieren statt abtippen

Der häufigste Grund, warum Dokumentation veraltet: Sie wird einmal von Hand erstellt und nach der nächsten Änderung nicht nachgezogen. Deshalb lohnt es sich, den technischen Teil zu automatisieren.

Mit TM1py, einer Open-Source-Python-Bibliothek für die REST API von Planning Analytics, lassen sich Cubes, Dimensionen, Regeln, TI-Prozesse und Chores direkt aus der TM1-Datenbank auslesen. Daraus kann regelmäßig eine aktuelle Übersicht erzeugt werden – etwa als Markdown-, HTML- oder Excel-Dokument. Auch Abhängigkeiten zwischen Regeln und Prozessen lassen sich so zumindest teilweise automatisch ermitteln.

Die fachliche und betriebliche Sicht bleibt Handarbeit. Aber wenn die technische Basis automatisch aktuell ist, konzentrieren Sie Ihre Zeit auf das, was wirklich nur Menschen beschreiben können: warum etwas so gebaut ist und wie es genutzt wird.

Fazit: Klein anfangen, aber anfangen

Eine gute Dokumentation muss nicht perfekt sein – sie muss die wichtigsten Fragen beantworten, bevor sie jemand im Ernstfall stellt. Starten Sie mit einer Inventur, dokumentieren Sie die kritischen Pfade und automatisieren Sie, was sich automatisieren lässt. So wird aus einem gewachsenen Modell wieder eine beherrschbare Lösung.

Sie möchten Ihr Planning Analytics Modell dokumentieren oder erst wissen, wo Sie stehen? Im Bereich Betrieb und Support unterstützt die Datenwert GmbH Sie von der Inventur bis zur automatisierten Dokumentation. Der erste Schritt: gemeinsam den Status Quo klären – schreiben Sie an kontakt@datenwert.gmbh. Wir machen aus Daten Entscheidungen – und aus Entscheidungen Wert.