Die IT zieht das ERP auf S/4HANA um, oder es entsteht eine neue Datenplattform, und irgendwo dazwischen steht das Planungsmodell. Es läuft seit Jahren zuverlässig, hängt aber an Schnittstellen, die es bald nicht mehr gibt, und an einer Planning Analytics Version, die selbst gerade im Wandel ist. Spätestens dann kommt die Frage: „Was heißt das für unsere Planung – und was kostet es?“ Eine Planning Analytics Modernisierung ist im Kern ein Redesign. Sie gelingt, wenn Vorgehen und Vorarbeit klar sind, bevor die erste Zeile Code entsteht.

Ob Umzug oder Neudenken der richtige Weg ist, haben wir im Beitrag Modernisierung: Migration oder neu denken? beschrieben. Hier geht es um den nächsten Schritt: wie so ein Projekt konkret abläuft.

Warum Modernisierung selten allein kommt

Planning Analytics befindet sich selbst in einer Übergangsphase. Mit dem Wechsel von Planning Analytics 2.0.9 auf 2.1 entfallen klassische Werkzeuge wie TM1 Architect und TM1 Perspectives; Modellierung und Administration wandern in den Planning Analytics Workspace. Mit V12 folgt der nächste Schritt: eine neue Architektur, betrieben als Service oder auf einer Container-Plattform, ohne direkten Zugriff auf das Datenverzeichnis des Servers (ja, on premise gibt es als Dev Preview, Stand 10-2026).

Gleichzeitig modernisieren viele Unternehmen ihre Datenlandschaft insgesamt: SAP-Migrationen verändern Quellsysteme und Datenstrukturen, neue Datenplattformen lösen gewachsene Dateiablagen und Einzelschnittstellen ab. Das Planungsmodell ist davon immer betroffen – als Empfänger von Ist-Daten und als Lieferant von Plan-Daten.

Das heißt: Selbst ein „reiner“ Versionswechsel verändert Werkzeuge, Betrieb, Schnittstellen und Teile der Logik. Wer das als Anlass nimmt, das Modell gezielt weiterzuentwickeln, braucht ein geordnetes Vorgehen.

Vorab klären: die Checkliste vor dem Projektstart

Bevor Phasen und Aufwände geplant werden, sollten diese Punkte beantwortet sein:

• Zielplattform: Planning Analytics on-premises, als Service oder auf einer Container-Plattform? Davon hängen Betrieb, Schnittstellen und Kosten aber auch SkillSet und Anforderung ab.
• Fachliche Ziele: Was soll nach der Modernisierung besser sein – kürzerer Planungszyklus, weniger Excel-Nebenrechnungen, neue Planungsprozesse?
• Umfang: Welche Cubes, Prozesse und Berichte werden wirklich genutzt? Was wird verbessert oder abgelöst?
• Tools: Welche Perspectives- und Architect-Nutzung gibt es, und wohin wandert sie – Planning Analytics for Excel oder Workspace?
• Umfeld: Welche anderen Projekte laufen parallel – ERP-Migration, Datenplattform, neue Vorsysteme? Wer liefert künftig welche Daten?
• Schnittstellen: Wie kommen Daten heute ins Modell – per ODBC, Datei oder REST API – und wie sollen sie es künftig?
• Rollen: Wer entscheidet fachlich, wer testet, wer betreibt später?
• Zeitfenster: Wann darf nicht umgestellt werden – Budgetphase, Jahresabschluss?

Diese Fragen vorher beantwortet und Konzepte erarbeitet, erspart sich Änderungen und Umbauten im späteren Verlauf.

Das Vorgehen der Planning Analytics Modernisierung in fünf Phasen

1. Inventur und Analyse. Alle Objekte erfassen – Cubes, Dimensionen, Regeln, TI-Prozesse, Chores, Berichte. Dazu gehört, welche Prozesse welche Datenquellen nutzen und welche Objekte verwaist sind. Ein Großteil davon lässt sich über die REST API bzw. TM1py automatisiert auslesen. Ergebnis: ein Bild des Ist-Zustands und eine Liste, was mitgeht, was neu gebaut wird und was entfällt.

2. Zielbild und Design. Gemeinsam mit den Verantwortlichen wird festgelegt, wie das Modell künftig aussieht: Cube-Struktur, Dimensionen, Rechenlogik, Datenflüsse, Berechtigungen. Heutige Anforderungen klären, künftiges Zielbild bestimmen und Komplexität möglichst reduzieren.

3. Umsetzung. Neu- und Umbau in überschaubaren Paketen, idealerweise entlang der Planungsprozesse. Realistisch eingeplant, sodass kritische Pfade und Engpässe transparent berücksichtigt werden.

4. Test und Abgleich. Fachliche Tests durch die Anwender, Zahlenabgleich gegen das Altsystem, Performance-Tests mit realistischen Datenmengen und vergleichbare Maßnahmen schaffen Vertrauen.

5. Go-live und Übergabe. Umstellung im vereinbarten Zeitfenster, Schulung, Übergabe an den Betrieb, Abschaltung des Altsystems. Erst danach ist das Projekt wirklich fertig.

Der Aufwand hängt stark vom Umfang ab. Ein seriöser Aufwand lässt sich erst nach der ersten Detailanalyse nennen – alles davor ist Glaskugel.

Zwei Beispiele aus der Praxis: Projekt 1 – technisches Redesign, parallel zur SAP Hana Migration und weiteren IT Projekten erforderte eine 6-monatige Konzeptionsphase durch ein kleines Kernteam. Die Realisierung des technischen Redesigns war „in time & budget“ ein voller Erfolg. Projekt 2 – Komplexität und Altlasten, die zu erheblicher Instabilität und Vertrauensverlust in Plandaten geführt hatten, sollten parallel zum Betrieb aufgeräumt und erneuert werden. Heute werden in kürzester Zeit neue Planungsprozesse mit deutlich weniger Aufwand realisiert – so überzeugt man Verantwortliche.

Typische Stolpersteine

Anforderungen. Der Weg z.B: zur PA 3.1 bzw. V12 hat klare Regeln: Objekte mit bestimmten Sonderzeichen im Namen werden nicht übernommen, und ein Blattelement muss in allen Hierarchien einer Dimension denselben Elementtyp haben. TI-Prozesse, die auf Dateien im Datenverzeichnis zugreifen oder Betriebssystembefehle ausführen, müssen umgebaut werden – etwa auf den File Manager oder REST Calls. IBM stellt u.a. ein Migrationswerkzeug bereit, dessen Protokoll Warnungen und Fehler ausweist; es gehört in jede Analyse ebenso, wie die erforderlichen Techstack Skills im PA Team.

Ablösen von Legacy unterschätzt. Alte Perspectives-Berichte und Access Datenbanken zur Erzeugung von Flatfiles laufen oft seit Jahren in Fachbereichen, IT weiß davon meistens nichts. Sie tauchen häufig erst im Test auf – zu spät für eine saubere Neugestaltung.

Quellsysteme ändern sich mitten im Projekt. Läuft parallel z.B. eine SAP-Migration, verändern sich Kontenstrukturen, Stammdaten und Schnittstellen. Wer das nicht früh abstimmt, baut Prozesse zweimal.

Schattenrechnungen. Excel-Dateien, die Daten aus Planning Analytics weiterverarbeiten, sind Teil des Prozesses. Werden sie nicht erfasst, verschiebt sich das Problem nur.

Schnittstellen und Netzwerk. IT Infrastruktur ist im ständigen Wandel, Änderungen zum Zweck der IT Sicherheit und regulatorische Anforderungen sind nur ein Beispiel. Ist die Ziellandschaft hybrid und IT im Wandel, steigt die Komplexität.

Wissen an einer Person. Wenn nur eine Person das Altmodell versteht, ist sie der Engpass des ganzen Projekts. Früh einplanen und entlasten.

Fazit: Erst die Analyse, dann der Zeitplan

Eine Planning Analytics Modernisierung ist kein Sprung ins Ungewisse, wenn die Vorarbeit stimmt. Klären Sie Zielplattform, fachliche Ziele, Umfang und das Zusammenspiel mit parallelen Projekten, bevor Sie Termine zusagen – und starten Sie mit einer Analyse, die auf Fakten statt auf Annahmen basiert.

Sie möchten wissen, was eine Modernisierung in Ihrer Umgebung bedeutet? Im Bereich Upgrade und Modernisierung begleitet die Datenwert GmbH Sie von der Inventur bis zum Go-live.

Der erste Schritt: gemeinsam den Status Quo klären – schreiben Sie an kontakt@datenwert.gmbh. Wir machen aus Daten Entscheidungen – und aus Entscheidungen Wert.