Warum gewachsene IBM Planning Analytics-Systeme nicht schlechter werden – sondern schwieriger zu verändern und was technische Schulden damit zu tun haben.

Wer seit vielen Jahren mit IBM Planning Analytics (TM1) arbeitet, kennt die Situation: Das System funktioniert zuverlässig, Budgetierung und Forecast laufen stabil und die Fachbereiche können arbeiten. Gleichzeitig dauert jede Änderung länger als früher. Neue Anforderungen werden zunehmend aufwändiger, Upgrades erscheinen riskant und bei komplexeren Anpassungen hört man häufig den Satz: „Diesen Teil sollten wir lieber nicht anfassen.“

Viele Unternehmen vermuten dann Performanceprobleme oder gewachsene Datenmengen als Ursache. Tatsächlich liegt die eigentliche Herausforderung häufig an einer anderen Stelle – den technischen Schulden des Systems.

Der Begriff stammt ursprünglich aus der Softwareentwicklung. Er beschreibt Entscheidungen, die zu einem bestimmten Zeitpunkt sinnvoll waren, deren Auswirkungen jedoch mit der Zeit den Aufwand für Wartung und Weiterentwicklung erhöhen. Genau dieses Phänomen lässt sich auch in nahezu jeder gewachsenen TM1-Landschaft beobachten.

Technische Schulden sind kein Zeichen schlechter Entwicklung

Der Begriff klingt zunächst negativ. Tatsächlich entstehen technische Schulden oft aus guten Gründen.

Kaum ein Unternehmen entwickelt sein Planungssystem vollständig auf dem Reißbrett. Neue Gesellschaften werden integriert, gesetzliche Anforderungen ändern sich, das Controlling benötigt zusätzliche Auswertungen oder ein neues ERP-System muss angebunden werden. Häufig müssen Lösungen kurzfristig umgesetzt werden, weil Budgetprozesse oder Monatsabschlüsse keinen Aufschub erlauben.

Unter diesen Rahmenbedingungen entstehen Workarounds, zusätzliche Prozesse oder pragmatische Erweiterungen, die das Unternehmen handlungsfähig halten. Das ist zunächst weder ungewöhnlich noch problematisch.

Schwierig wird es erst dann, wenn diese kurzfristigen Lösungen dauerhaft Bestandteil des Systems werden und niemand mehr hinterfragt, ob sie noch notwendig sind.

Technische Schulden entstehen daher nicht durch schlechte Entwickler. Sie entstehen, weil Unternehmen sich weiterentwickeln – ihre Planungssysteme jedoch nicht immer im gleichen Tempo modernisiert werden.

Wie technische Schulden in TM1 entstehen

In langjährig betriebenen TM1-Systemen begegnen uns immer wieder ähnliche Muster.

Eine Rule wurde ursprünglich für einen Sonderfall entwickelt und im Laufe der Jahre mehrfach erweitert. Ein TurboIntegrator-Prozess übernimmt heute Aufgaben, für die später eigentlich ein neuer Prozess vorgesehen war. Historische Cubes bleiben bestehen, weil niemand mit Sicherheit sagen kann, ob sie noch benötigt werden. Berechnungen existieren an mehreren Stellen, weil neue Anforderungen schneller umgesetzt werden mussten als eine grundlegende Überarbeitung möglich war.

Für sich genommen sind diese Entscheidungen meist nachvollziehbar. In ihrer Summe erhöhen sie jedoch die Komplexität des Modells.

Das eigentliche Problem besteht deshalb selten aus einer einzelnen schlechten Lösung. Vielmehr entsteht über Jahre eine Architektur, deren Zusammenhänge immer schwieriger nachvollziehbar werden.

Die Symptome zeigen sich im Alltag

Technische Schulden werden selten durch Fehlermeldungen sichtbar. Viel häufiger machen sie sich im täglichen Betrieb bemerkbar.

Änderungen benötigen deutlich mehr Zeit als früher, weil zunächst analysiert werden muss, welche Auswirkungen sie auf andere Bereiche des Modells haben könnten. Neue Entwickler benötigen viele Monate, um sich in die bestehende Architektur einzuarbeiten. Jede größere Anpassung wird vorsichtshalber mehrfach verschoben, weil niemand unerwartete Seiteneffekte riskieren möchte.

Auch Upgrades werden zunehmend aufwendig. Nicht weil IBM Planning Analytics komplizierter geworden wäre, sondern weil unklar ist, welche historischen Besonderheiten im eigenen System berücksichtigt werden müssen.

Mit der Zeit entsteht eine Situation, in der das Modell zwar zuverlässig arbeitet, seine Weiterentwicklung jedoch immer teurer wird.

Nicht jede Komplexität ist eine technische Schuld

Ein häufiger Irrtum besteht darin, komplexe Modelle grundsätzlich als schlecht zu bewerten.

Gerade in internationalen Unternehmen bildet ein TM1-System häufig anspruchsvolle Planungs- und Konsolidierungsprozesse ab. Mehrstufige Währungsumrechnungen, komplexe Intercompany-Logiken oder unternehmensspezifische Berechnungen lassen sich nicht beliebig vereinfachen. Die Komplexität entsteht hier nicht durch die technische Umsetzung, sondern durch die fachlichen Anforderungen.

Deshalb ist es wichtig, zwischen notwendiger Komplexität und technischen Schulden zu unterscheiden.

Eine umfangreiche Rule ist nicht automatisch schlecht. Sie kann eine komplexe fachliche Logik präzise und nachvollziehbar abbilden. Ebenso ist ein großer Cube nicht zwangsläufig ein Architekturproblem, sondern möglicherweise die passende Lösung für den Anwendungsfall.

Technische Schulden beginnen dort, wo Lösungen nur deshalb bestehen bleiben, weil ihre ursprüngliche Funktion nicht mehr bekannt ist oder niemand das Risiko einer Änderung eingehen möchte.

Diese Unterscheidung erfordert Erfahrung. Wer ausschließlich auf Kennzahlen oder Modellgrößen blickt, läuft Gefahr, fachlich sinnvolle Lösungen als technische Probleme zu interpretieren – oder tatsächliche Risiken zu übersehen.

Die eigentlichen Kosten entstehen nicht im System

Technische Schulden wirken sich nur selten unmittelbar auf die Anwender aus. Budgetierung und Forecast funktionieren oft über viele Jahre zuverlässig.

Die Kosten entstehen an anderer Stelle.

Neue Anforderungen benötigen mehr Entwicklungsaufwand. Projekte werden komplexer als geplant. Externe Unterstützung wird häufiger erforderlich, weil das interne Wissen nicht mehr ausreicht. Gleichzeitig steigt die Abhängigkeit von einzelnen Entwicklern, die historische Entscheidungen noch nachvollziehen können.

Auch Innovationsprojekte leiden darunter. Neue Datenquellen, moderne Benutzeroberflächen oder Automatisierungen werden zurückgestellt, weil zunächst die bestehende Architektur verstanden werden muss.

Technische Schulden sind deshalb nicht nur ein technisches Thema. Sie beeinflussen die Geschwindigkeit, mit der sich ein Unternehmen an neue Anforderungen anpassen kann.

Technische Schulden lassen sich steuern

Die gute Nachricht ist: Technische Schulden lassen sich weder vollständig vermeiden noch müssen sie vollständig beseitigt werden.

Entscheidend ist, sie sichtbar zu machen und bewusst zu steuern.

Ein strukturierter Health Check schafft Transparenz über die Architektur, identifiziert kritische Bereiche und bewertet die Wartbarkeit des Systems. Häufig zeigt sich dabei, dass nur wenige Komponenten den größten Teil der Risiken verursachen. Statt das gesamte Modell neu zu entwickeln, können diese Bereiche gezielt modernisiert oder dokumentiert werden.

Ebenso wichtig ist eine kontinuierliche Pflege der Architektur. Regelmäßige Reviews, nachvollziehbare Dokumentation und gemeinsame Code-Reviews verhindern, dass kurzfristige Lösungen über Jahre unbemerkt zum Standard werden.

Der Abbau technischer Schulden ist deshalb kein einmaliges Projekt, sondern Bestandteil eines professionellen Betriebsmodells.

Fazit

Jede gewachsene IBM Planning Analytics TM1-Landschaft enthält technische Schulden. Das ist weder ungewöhnlich noch ein Hinweis auf schlechte Entwicklungsarbeit.

Entscheidend ist vielmehr, ob Unternehmen ihre Architektur kennen und bewusst weiterentwickeln oder ob historische Entscheidungen zunehmend zum Hindernis werden.

Nicht jede komplexe Rule muss vereinfacht werden. Nicht jeder große Cube ist ein Problem. Ebenso wenig ist jede historische Lösung automatisch eine technische Schuld.

Die Herausforderung besteht darin, notwendige fachliche Komplexität von unnötigen technischen Altlasten zu unterscheiden. Genau diese Bewertung entscheidet darüber, ob ein TM1-System auch in Zukunft wirtschaftlich betrieben und flexibel weiterentwickelt werden kann.

Wer technische Schulden regelmäßig bewertet und schrittweise abbaut, reduziert nicht nur Betriebsrisiken. Er schafft die Grundlage dafür, dass IBM Planning Analytics auch nach vielen Jahren noch ein leistungsfähiges und wartbares Planungssystem bleibt.

Wie hoch sind die technischen Schulden Ihrer TM1-Landschaft?

Viele Unternehmen wissen nicht, welche Bereiche ihres Planning Analytics TM1-Systems besonders wartungsintensiv oder risikobehaftet sind. Ein unabhängiger Health Check schafft Transparenz über Architektur, Wartbarkeit und technische Schulden – und hilft dabei, Modernisierungsmaßnahmen dort anzusetzen, wo sie den größten Nutzen bringen.

Wir unterstützen Sie dabei, Ihre TM1-Landschaft nachhaltig weiterzuentwickeln – ohne Bewährtes unnötig zu ersetzen.