.
Läuft Oracle Hyperion bei Ihnen 'eigentlich noch gut'?
Der Satz "Don't change a running system" klingt vernünftig und genau deshalb ist er verführerisch. Wenn Oracle Hyperion seit Jahren zuverlässig läuft, gibt es scheinbar keinen Grund, etwas zu ändern. Die Planung funktioniert, das Team kennt das System, die Zahlen stimmen.
Doch genau in diesem "eigentlich noch gut" verstecken sich die Risiken am liebsten im Hintergrund, bis sie plötzlich sichtbar werden: ein Know-how-Träger verlässt das Unternehmen, ein Server muss ersetzt werden, oder eine Funktion, die der Wettbewerb längst nutzt, ist auf der eigenen Plattform schlicht nicht verfügbar.
Drei Anzeichen, dass Ihre Hyperion-Instanz zum Risiko wird
Bevor es um die Frage geht, wie eine Migration abläuft, lohnt sich der ehrliche Check der eigenen Situation. Drei Signale sprechen dafür, dass der Zeitpunkt näher ist, als man denkt:
Was eine Migration wirklich kostet
Die Zurückhaltung vieler Finanzabteilungen ist nachvollziehbar: die Vorstellung eines Großprojekts mit offenem Zeitrahmen, unklaren Kosten und dem Risiko, bewährte Prozesse zu verlieren, schreckt zu Recht ab. Nur beruht diese Vorstellung meist auf dem klassischen Implementierungsprojekt: wochenlange Anforderungsaufnahme, individuelle Workshops, Modellierung von Grund auf, bevor überhaupt ein produktives System entsteht.
Dass es anders geht, zeigt das Beispiel der Schweizer Gewerkschaft unia.
So sieht eine planbare Migration in der Praxis aus: das Beispiel unia
unia ist eine der größten Gewerkschaften der Schweiz und verwaltet Finanzen und eine umfangreiche Mitgliederbasis eng verzahnt. Mitgliederzahlen beeinflussen dort direkt Beiträge, Budgets und Ressourcenverteilung. Auch bei unia war Hyperion über Jahre die zentrale Planungsplattform: bewährt, aber mit genau den oben beschriebenen Risiken.
Der entscheidende Unterschied zum klassischen Projekt war der sogenannte Ready2use-Ansatz: Statt bei null zu beginnen, startet das Projekt mit einem vorkonfigurierten Standard für typische Planungsszenarien. Bestehende Strukturen werden übernommen statt neu erfunden, der Aufwand verschiebt sich von der Entwicklung zur Anpassung. Die zentrale Projektfrage lautet dadurch nicht mehr „Wie bauen wir das alles auf?“, sondern „Wo muss der Standard an unsere Besonderheiten angepasst werden?“ Das ist ein deutlich kürzeres Gespräch.
Konkret lief das Projekt in vier festen Phasen ab:
Wie der Umstieg bei unia im Detail ablief, hat Tim Janßen, EPM Lead bei Broadpin, im Blog dokumentiert: EPM Migration in Practice: How unia Went Live in 8 Weeks.
Was bleibt gleich und was wird besser?
Eine berechtigte Sorge bei jeder Migration: Verliert das Team seine gewohnte Arbeitsweise? Bei unia zeigte sich, dass die tägliche Arbeit sich kaum verändert hat. Das Excel-Add-in blieb die Eingabeschnittstelle, die vertraute Terminologie aus der Hyperion-Welt blieb erhalten. Wer bisher in Excel geplant hat, plant weiterhin in Excel, nur mit Zahlen aus einer einzigen, verlässlichen Quelle.
Was wegfällt, ist das, was zuvor belastet hat: die On-Premise-Infrastruktur, manuelle Updates, die Abhängigkeit von einzelnem Spezialwissen. Und was neu hinzukommt, ist der Zugang zu Funktionen wie automatisierter Konsolidierung und KI-gestütztem Forecasting. Diese sind schrittweise einführbar, sobald der Bedarf entsteht.
Fazit: Die Frage ist nicht mehr ob, sondern wann
Wer eines oder mehrere der drei genannten Risikosignale bei sich erkennt, sollte die Migration nicht länger als hypothetisches Großprojekt behandeln, sondern als das, was sie mittlerweile sein kann: ein planbares Vorhaben mit festem Rahmen, festem Preis und einem realistischen Zeithorizont von wenigen Wochen statt Monaten.
Wer wissen möchte, wie eine solche Migration für die eigene Organisation aussehen könnte, findet weiterführende Informationen zum Broadpin EPM Ready2use-Ansatz unter: broadpin.com/what-we-do/oracle-ready2use/epm/broadpin-epm-ready2use
Läuft Oracle Hyperion bei Ihnen 'eigentlich noch gut'?
Der Satz "Don't change a running system" klingt vernünftig und genau deshalb ist er verführerisch. Wenn Oracle Hyperion seit Jahren zuverlässig läuft, gibt es scheinbar keinen Grund, etwas zu ändern. Die Planung funktioniert, das Team kennt das System, die Zahlen stimmen.
Doch genau in diesem "eigentlich noch gut" verstecken sich die Risiken am liebsten im Hintergrund, bis sie plötzlich sichtbar werden: ein Know-how-Träger verlässt das Unternehmen, ein Server muss ersetzt werden, oder eine Funktion, die der Wettbewerb längst nutzt, ist auf der eigenen Plattform schlicht nicht verfügbar.
Drei Anzeichen, dass Ihre Hyperion-Instanz zum Risiko wird
Bevor es um die Frage geht, wie eine Migration abläuft, lohnt sich der ehrliche Check der eigenen Situation. Drei Signale sprechen dafür, dass der Zeitpunkt näher ist, als man denkt:
- Das Know-how ist an einzelne Personen gebunden. Wenn Betrieb und Wartung von Hyperion von ein oder zwei Personen abhängen, ist das kein stabiler Zustand sondern ein aufgeschobenes Risiko.
- Der On-Premise-Betrieb bindet spürbar Zeit und Budget. Server, Updates, Patches, Sicherheitsmaßnahmen: Das alles muss intern gestemmt werden, unabhängig davon, ob es strategisch sinnvoll ist.
- Neue Funktionen sind für Sie nicht verfügbar. Oracle entwickelt Funktionen wie KI-gestütztes Forecasting für die Cloud-Plattform. Auf dem Altsystem bleiben diese außen vor. Damit wächst der Abstand zu modernen Planungsmöglichkeiten mit jedem Release.
Was eine Migration wirklich kostet
Die Zurückhaltung vieler Finanzabteilungen ist nachvollziehbar: die Vorstellung eines Großprojekts mit offenem Zeitrahmen, unklaren Kosten und dem Risiko, bewährte Prozesse zu verlieren, schreckt zu Recht ab. Nur beruht diese Vorstellung meist auf dem klassischen Implementierungsprojekt: wochenlange Anforderungsaufnahme, individuelle Workshops, Modellierung von Grund auf, bevor überhaupt ein produktives System entsteht.
Dass es anders geht, zeigt das Beispiel der Schweizer Gewerkschaft unia.
So sieht eine planbare Migration in der Praxis aus: das Beispiel unia
unia ist eine der größten Gewerkschaften der Schweiz und verwaltet Finanzen und eine umfangreiche Mitgliederbasis eng verzahnt. Mitgliederzahlen beeinflussen dort direkt Beiträge, Budgets und Ressourcenverteilung. Auch bei unia war Hyperion über Jahre die zentrale Planungsplattform: bewährt, aber mit genau den oben beschriebenen Risiken.
Der entscheidende Unterschied zum klassischen Projekt war der sogenannte Ready2use-Ansatz: Statt bei null zu beginnen, startet das Projekt mit einem vorkonfigurierten Standard für typische Planungsszenarien. Bestehende Strukturen werden übernommen statt neu erfunden, der Aufwand verschiebt sich von der Entwicklung zur Anpassung. Die zentrale Projektfrage lautet dadurch nicht mehr „Wie bauen wir das alles auf?“, sondern „Wo muss der Standard an unsere Besonderheiten angepasst werden?“ Das ist ein deutlich kürzeres Gespräch.
Konkret lief das Projekt in vier festen Phasen ab:
- Setup und Abgleich
Die vorkonfigurierte Umgebung wird bereitgestellt und mit den bestehenden Planungsstrukturen verglichen. - Anpassung und Datenübernahme
Der Standard wird auf die eigenen Anforderungen zugeschnitten, Daten und Logik werden übertragen. - Test und Validierung
Das Fachteam prüft die Ergebnisse anhand echter Planungszahlen, bevor es live geht. - Go-live und Übergabe
Produktivstart und Einarbeitung des Teams für den eigenständigen Betrieb.
Wie der Umstieg bei unia im Detail ablief, hat Tim Janßen, EPM Lead bei Broadpin, im Blog dokumentiert: EPM Migration in Practice: How unia Went Live in 8 Weeks.
Was bleibt gleich und was wird besser?
Eine berechtigte Sorge bei jeder Migration: Verliert das Team seine gewohnte Arbeitsweise? Bei unia zeigte sich, dass die tägliche Arbeit sich kaum verändert hat. Das Excel-Add-in blieb die Eingabeschnittstelle, die vertraute Terminologie aus der Hyperion-Welt blieb erhalten. Wer bisher in Excel geplant hat, plant weiterhin in Excel, nur mit Zahlen aus einer einzigen, verlässlichen Quelle.
Was wegfällt, ist das, was zuvor belastet hat: die On-Premise-Infrastruktur, manuelle Updates, die Abhängigkeit von einzelnem Spezialwissen. Und was neu hinzukommt, ist der Zugang zu Funktionen wie automatisierter Konsolidierung und KI-gestütztem Forecasting. Diese sind schrittweise einführbar, sobald der Bedarf entsteht.
Fazit: Die Frage ist nicht mehr ob, sondern wann
Wer eines oder mehrere der drei genannten Risikosignale bei sich erkennt, sollte die Migration nicht länger als hypothetisches Großprojekt behandeln, sondern als das, was sie mittlerweile sein kann: ein planbares Vorhaben mit festem Rahmen, festem Preis und einem realistischen Zeithorizont von wenigen Wochen statt Monaten.
Wer wissen möchte, wie eine solche Migration für die eigene Organisation aussehen könnte, findet weiterführende Informationen zum Broadpin EPM Ready2use-Ansatz unter: broadpin.com/what-we-do/oracle-ready2use/epm/broadpin-epm-ready2use
