Warum nachhaltiger Betrieb von IBM Planning Analytics mehr bedeutet als funktionierende Cubes und Rules.

Viele Unternehmen nutzen IBM Planning Analytics (TM1) seit vielen Jahren als zentrale Plattform für Planung, Forecasting und Reporting. Das System wächst mit den Anforderungen des Unternehmens: Neue Gesellschaften werden integriert, zusätzliche Planungsprozesse entstehen, Berichte werden erweitert und Schnittstellen zu ERP- oder Data-Warehouse-Systemen kommen hinzu.

Mit jeder Weiterentwicklung wächst jedoch nicht nur das Modell – sondern auch das Wissen darüber.

Dieses Wissen ist weit mehr als die Summe aus Cubes, Dimensionen und TurboIntegrator-Prozessen. Es umfasst Architekturentscheidungen, fachliche Besonderheiten, historische Entwicklungen und unzählige kleine Erfahrungen aus dem täglichen Betrieb. Solange die verantwortlichen Entwickler und Administratoren verfügbar sind, bleibt dieses Wissen oft unsichtbar. Erst wenn sie das Unternehmen verlassen oder kurzfristig ausfallen, wird deutlich, wie stark der Betrieb von einzelnen Personen abhängen kann.

Die eigentliche Herausforderung beginnt deshalb häufig nicht mit dem Personalwechsel selbst, sondern mit der ersten Änderung am System.

Ein Planning Analytics TM1 erzählt die Geschichte eines Unternehmens

Kaum eine produktive TM1-Anwendung sieht heute noch so aus wie am Tag ihrer Einführung.

Über Jahre hinweg verändern sich Geschäftsmodelle, Organisationsstrukturen und Planungsprozesse. Neue Anforderungen entstehen häufig kurzfristig und müssen in bestehende Modelle integriert werden. Budgetierungsprozesse werden erweitert, Forecast-Logiken angepasst oder zusätzliche Datenquellen angebunden.

Dadurch entsteht ein System, das die fachliche Entwicklung eines Unternehmens widerspiegelt.

Viele Entscheidungen wurden dabei bewusst getroffen. Andere entstanden aus den technischen Möglichkeiten einer bestimmten Version oder aus Zeitdruck innerhalb eines Projekts. Manche Lösungen waren ursprünglich als Übergang gedacht und begleiten das Unternehmen noch Jahre später.

Wer das Modell entwickelt hat, kennt diese Geschichte. Ein neuer Entwickler sieht dagegen zunächst nur den aktuellen Zustand. Er erkennt Cubes, Dimensionen und Rules, nicht aber die Gründe, warum sie genau so aufgebaut wurden. Genau an dieser Stelle entstehen Risiken.

Wissen steckt selten nur im Code

Bei Softwareprojekten wird häufig angenommen, dass sich das notwendige Wissen vollständig im Quellcode befindet. Für klassische Anwendungen mag das teilweise zutreffen. Beim Betrieb von IBM Planning Analytics ist die Situation deutlich komplexer.

Ein großer Teil des Wissens entsteht außerhalb des eigentlichen Modells.

Der Entwickler weiß beispielsweise, weshalb eine Berechnung als Rule umgesetzt wurde, obwohl sie theoretisch auch in einem TurboIntegrator-Prozess hätte erfolgen können. Er kennt den Hintergrund einer ungewöhnlichen Sicherheitsstruktur oder weiß, warum zwei scheinbar identische Cubes unterschiedliche Aufgaben erfüllen.

Ebenso kennt er die Diskussionen mit den Fachbereichen, aus denen viele Lösungen entstanden sind. Oft wurde gemeinsam entschieden, eine fachliche Besonderheit bewusst abzubilden oder einen bestimmten Prozess aus Gründen der Nachvollziehbarkeit beizubehalten.

Dieses Wissen ist weder in Cubes noch in TI-Prozessen sichtbar. Es entsteht durch jahrelange Zusammenarbeit mit Controlling, Finance und IT.

Workarounds sind kein Zeichen schlechter Entwicklung

In nahezu jedem gewachsenen TM1-System finden sich Workarounds. Der Begriff wird häufig negativ verstanden. Tatsächlich sind viele dieser Lösungen vollkommen nachvollziehbar. Sie entstanden beispielsweise, weil kurzfristig gesetzliche Anforderungen umgesetzt werden mussten, weil ein Vorsystem bestimmte Daten nicht bereitstellen konnte oder weil ältere Versionen von Planning Analytics technische Einschränkungen mit sich brachten.

Mit der Zeit geraten jedoch die ursprünglichen Gründe in Vergessenheit.

Ein neuer Entwickler entdeckt einen zusätzlichen Prozess oder eine ungewöhnliche Rule und geht möglicherweise davon aus, dass sie überflüssig geworden ist. Erst später stellt sich heraus, dass genau diese Lösung einen seltenen, aber geschäftskritischen Sonderfall berücksichtigt.

Gerade solche Zusammenhänge machen den Unterschied zwischen einer oberflächlichen Wartung und einer fundierten Betreuung und damit einem guten IBM Planning Analytics Betrieb aus. Nicht jede ungewöhnliche Lösung sollte entfernt werden. Zunächst muss verstanden werden, warum sie überhaupt entstanden ist.

Die eigentliche Komplexität liegt in den fachlichen Zusammenhängen

Viele Unternehmen unterschätzen, wie eng technische und fachliche Anforderungen in TM1 miteinander verbunden sind. Rules bilden nicht nur mathematische Berechnungen ab. Sie repräsentieren Geschäftslogiken. TurboIntegrator-Prozesse übernehmen nicht nur Datenimporte, sondern setzen häufig komplexe Abläufe des Unternehmens um.

Dazu gehören beispielsweise Währungsumrechnungen, Intercompany-Prozesse, Konsolidierungslogiken oder unternehmensspezifische Planungsverfahren.

Der Entwickler kennt oft nicht nur die technische Umsetzung, sondern auch die fachlichen Hintergründe. Er weiß, welche Zahlen regelmäßig hinterfragt werden, welche Berichte besonders kritisch sind und welche Besonderheiten einzelne Gesellschaften berücksichtigen müssen.

Verlässt dieses Wissen gemeinsam mit dem Entwickler das Unternehmen, steigt die Unsicherheit bei jeder fachlichen Änderung.

Ein großer Teil des TM1 Betriebs findet außerhalb von TM1 statt

Wer ausschließlich auf das eigentliche Modell blickt, übersieht einen wesentlichen Teil der Systemlandschaft.

Ein produktiver Betrieb umfasst weit mehr als TM1 Objekte. Geplante Aufgaben auf dem Server, PowerShell-Skripte, Batch-Dateien, Datenbankschnittstellen, Dateifreigaben oder REST-Integrationen sorgen dafür, dass Daten täglich zur richtigen Zeit verfügbar sind.

Auch Monitoring, Backup-Strategien und Recovery-Prozesse gehören zu einer professionellen Betriebsumgebung. Wie oft testen Sie eigentlich Ihre Recovery Prozesse? *

Gerade diese Komponenten wurden häufig über Jahre hinweg erweitert und angepasst. Nicht selten existieren sie außerhalb einer zentralen Dokumentation und werden erst wahrgenommen, wenn sie nicht mehr funktionieren. Zur Sicherstellung des Betriebs, ist es sehr wichtig nicht nur das TM1-Modell verstehen, sondern die gesamte Betriebsumgebung zu kennen.

Technische Schulden verschwinden nicht von allein

Jedes langlebige System sammelt im Laufe der Zeit technische Schulden. Das gilt auch für IBM Planning Analytics TM1 Modelle.

Historische Dimensionen werden nicht mehr verwendet, alte TurboIntegrator-Prozesse bleiben erhalten oder Sicherheitskonzepte entsprechen nicht mehr den heutigen Anforderungen. Manche Rules wurden erweitert, obwohl eine grundlegende Überarbeitung langfristig sinnvoller gewesen wäre.

Der ursprüngliche Entwickler kennt diese Bereiche meist sehr genau. Er weiß, welche Komponenten seit Jahren unverändert laufen und wo besondere Vorsicht geboten ist.

Ein Nachfolger verfügt über dieses Erfahrungswissen zunächst nicht. Dadurch steigt das Risiko, dass vermeintlich einfache Optimierungen unerwartete Auswirkungen auf andere Bereiche des Modells haben.

Technische Schulden sind deshalb nicht nur ein Wartungsthema. Sie stellen auch ein Wissensproblem dar.

Dokumentation ist notwendig – aber nicht ausreichend

Wenn Unternehmen das Risiko erkennen, lautet die erste Forderung häufig: „Wir brauchen eine bessere Dokumentation.“

Das ist richtig.

Eine gute Dokumentation beschreibt jedoch in erster Linie den aktuellen Zustand eines Systems. Sie dokumentiert Cubes, Dimensionen, Prozesse, Benutzergruppen oder Schnittstellen. Was sie nur selten beschreibt, sind die Entscheidungen hinter der Architektur.

• Warum wurde diese Lösung gewählt?
• Welche Alternativen wurden diskutiert?
• Welche bekannten Schwächen wurden bewusst akzeptiert?
• Welche Workarounds sind weiterhin erforderlich und welche könnten inzwischen entfallen?

Diese Fragen lassen sich nur beantworten, wenn technisches Wissen und Projekterfahrung miteinander verbunden werden. Eine Dokumentation ersetzt deshalb niemals den persönlichen Wissenstransfer.

Wissenssicherung beginnt lange vor dem Personalwechsel

Der größte Fehler besteht darin, Wissenssicherung erst dann zu beginnen, wenn ein Entwickler bereits gekündigt hat.

Zu diesem Zeitpunkt ist der Handlungsspielraum meist begrenzt.

Professionell betriebene Planning Analytics Systeme verteilen Wissen kontinuierlich auf mehrere Schultern. Architekturentscheidungen werden nachvollziehbar dokumentiert, Änderungen gemeinsam umgesetzt und regelmäßige Reviews helfen dabei, technische Schulden frühzeitig zu erkennen.

Ebenso wichtig ist ein strukturierter Austausch zwischen IT und Fachbereich. Nur wenn beide Seiten die fachlichen Hintergründe verstehen, kann man einen stabilen Betrieb von IBM Planning Analytics sichergestellen und Planungsmodelle langfristig sinnvoll weiterentwickeln.

Wissenssicherung ist deshalb kein Offboarding-Prozess. Sie ist Bestandteil eines professionellen Betriebsmodells!

Ein Health Check schafft Transparenz

Viele Unternehmen wissen nicht genau, in welchem Zustand sich ihre IBM Planning Analytics TM1-Landschaft befindet.

• Welche Bereiche sind besonders komplex?
• Wo existieren historische Workarounds?
• Welche Prozesse sind kritisch für den täglichen Betrieb?
• Welche Komponenten sind nur unzureichend dokumentiert?

Ein technischer Health Check beantwortet genau diese Fragen. Neben Performance, Wartbarkeit und Architektur werden auch Betriebsrisiken sichtbar. Gleichzeitig entsteht eine fundierte Grundlage für zukünftige Weiterentwicklungen oder eine geordnete Wissensübergabe.

Ein solcher Review ist besonders sinnvoll, bevor organisatorische und personelle Veränderungen stattfinden – nicht erst danach.

Gute Betreuung bedeutet mehr als Fehler zu beheben

Viele Unternehmen verbinden Support vor allem mit der Reaktion auf Störungen. Nachhaltige Betreuung beginnt jedoch deutlich früher.

Sie sorgt dafür, dass Wissen erhalten bleibt, technische Schulden kontrolliert werden und neue Anforderungen nachvollziehbar umgesetzt werden können. Dadurch sinkt die Abhängigkeit von einzelnen Personen und gleichzeitig steigt die Qualität des gesamten Systems.

Ein gut betreutes TM1-System ist deshalb nicht nur stabiler. Es lässt sich auch einfacher weiterentwickeln.

Fazit

Ein IBM Planning Analytics TM1-System besteht nicht nur aus Cubes, Rules und Prozessen. Es ist das Ergebnis zahlreicher fachlicher und technischer Entscheidungen, die sich über Jahre hinweg angesammelt haben.

Genau dieses Wissen entscheidet darüber, ob eine Planungslösung auch nach personellen Veränderungen zuverlässig betrieben und weiterentwickelt werden kann.

Unternehmen sollten Wissenssicherung deshalb nicht als einmalige Aufgabe verstehen, sondern als festen Bestandteil ihres TM1 Betriebsmodells. Regelmäßige Architektur-Reviews, nachvollziehbare Dokumentation, strukturierter Wissenstransfer und technische Health Checks schaffen die Grundlage dafür, dass IBM Planning Analytics langfristig unabhängig von einzelnen Personen betrieben werden kann.

Denn die entscheidende Frage lautet nicht, ob ein Entwickler das Unternehmen irgendwann verlässt. Sondern ob das Unternehmen dann noch in der Lage ist, sein TM1-System mit derselben Sicherheit und Qualität weiterzuentwickeln.

Ist Ihr TM1-System von einzelnen Personen abhängig?

Wenn sich wichtige Architekturentscheidungen, Workarounds oder Betriebsabläufe nur im Kopf weniger Mitarbeitender befinden, entsteht ein erhebliches Betriebsrisiko. Ein unabhängiger Health Check schafft Transparenz über den technischen Zustand Ihres Systems, identifiziert Dokumentationslücken und zeigt auf, wie sich Wissen langfristig sichern lässt.

Wir unterstützen Sie dabei, Ihre IBM Planning Analytics-Landschaft wartbar, nachvollziehbar und unabhängig von einzelnen Personen aufzustellen. Erfahren Sie mehr über unseren TM1 Support und Betrieb.

* Und? Wie oft testen Sie ihr Desaster Recovery? Bei einem dringendem Support-Fall für einen neuen TM1 Kunden ist der absolute Worst-Case aufgetreten. Die Backups waren derart stark komprimiert, dass das Entpacken Stunden dauerte – stundenlang stand die Produktion zum Ende der Planungsphase