Hyperion Software: Oracle Hyperion und EPM

Hyperion ist kein klassisches ERP, sondern eine Software für Finanzplanung und Konsolidierung – heute Teil von Oracle. Dieser Beitrag ordnet Hyperion in den Bereich Enterprise Performance Management (EPM) ein und grenzt es von ERP-Systemen ab.

Was ist Hyperion?

Hyperion Solutions war ein Softwarehersteller für Finanzanwendungen und wurde 2007 von Oracle übernommen. Unter dem Namen „Oracle Hyperion“ wurde eine Produktfamilie für Enterprise Performance Management (EPM) bekannt – also für Planung, Budgetierung, Forecasting und die Konzern-Konsolidierung im Finanzbereich.

EPM vs. ERP – wo liegt der Unterschied?

Während ein ERP-System die operativen Prozesse abbildet (Einkauf, Lager, Produktion, Verkauf, Buchhaltung), setzt EPM-Software eine Ebene darüber an: Sie nutzt die Zahlen aus dem ERP für steuerungs- und planungsorientierte Aufgaben. ERP und EPM ergänzen sich also, statt sich zu ersetzen.

Warum taucht Hyperion im ERP-Kontext auf?

Weil beide im Finanz- und Unternehmensumfeld eng zusammenarbeiten, wird Hyperion oft gemeinsam mit ERP genannt. In größeren Organisationen fließen die operativen Zahlen aus dem ERP in die Planungs- und Konsolidierungsprozesse einer EPM-Lösung wie Hyperion ein. Für kleine und mittlere Unternehmen ist eine dedizierte EPM-Software dagegen meist überdimensioniert – hier übernimmt das Controlling-Modul des ERP diese Aufgaben.

Wofür Unternehmen Hyperion typischerweise einsetzen

Die Stärke einer EPM-Lösung wie Hyperion liegt in den planungs- und steuerungsnahen Aufgaben des Finanzbereichs, die ein klassisches ERP nur eingeschränkt abdeckt. Ein verbreitetes Einsatzgebiet ist die Konzern-Konsolidierung: Größere Unternehmensgruppen müssen die Einzelabschlüsse vieler Gesellschaften zu einem konsolidierten Konzernabschluss zusammenführen, konzerninterne Geschäfte eliminieren und unterschiedliche Währungen umrechnen – ein komplexer Prozess, für den Hyperion spezialisierte Werkzeuge bietet. Ein zweites Feld ist die Planung und Budgetierung, bei der Fachbereiche dezentral Planzahlen erfassen, die anschließend zentral zusammengeführt und gegen die Ist-Werte gespiegelt werden. Hinzu kommen Forecasting, Profitabilitätsanalysen und ein anspruchsvolles Management-Reporting.

Diese Aufgaben setzen voraus, dass verlässliche Ist-Daten vorliegen – und genau hier kommt das Zusammenspiel mit dem ERP ins Spiel. Das ERP liefert die operativen Zahlen, die EPM-Lösung verdichtet, plant und analysiert sie auf einer höheren Ebene. Für kleine und mittlere Unternehmen ist eine eigenständige EPM-Software dieser Art in der Regel überdimensioniert; ihre Planungs- und Auswertungsbedürfnisse deckt das Controlling-Modul des ERP meist ausreichend ab. Erst mit zunehmender Größe, vielen Gesellschaften und komplexen Konsolidierungsanforderungen wird ein dediziertes EPM-Werkzeug wirtschaftlich sinnvoll.

Der Trend zur Cloud

Wie viele etablierte Anbieter verlagert auch Oracle seine Performance-Management-Funktionen zunehmend in die Cloud. Neben den klassischen Hyperion-Produkten stehen heute cloudbasierte EPM-Angebote bereit, die ähnliche Aufgaben als Abo-Dienst abbilden. Unternehmen, die eine solche Lösung erwägen, sollten die aktuelle Produktstrategie des Herstellers prüfen, da sich Namen, Funktionsumfang und Betriebsmodelle in diesem Bereich laufend weiterentwickeln.

Die Hyperion-Produktfamilie

Hinter dem Namen Oracle Hyperion steht keine einzelne Anwendung, sondern eine Familie von Produkten für das Enterprise Performance Management. Historisch gehören dazu unter anderem Lösungen für die Planung und Budgetierung, mit denen Fachbereiche dezentral Planzahlen erfassen und zentral zusammenführen, sowie Werkzeuge für die Finanzkonsolidierung, die Einzelabschlüsse vieler Gesellschaften zu einem Konzernabschluss verdichten. Ergänzt wird die Familie durch Komponenten für Reporting, Datenintegration und Stammdatenverwaltung im Finanzbereich.

Diese Spezialisierung erklärt, warum Hyperion vor allem in größeren Organisationen mit komplexen Finanzstrukturen anzutreffen ist. Die Werkzeuge setzen auf den operativen Daten auf, die ein ERP liefert, und veredeln sie zu Planungs-, Steuerungs- und Berichtsgrundlagen. Für kleine und mittlere Unternehmen sind sie in der Regel überdimensioniert.

Der Weg in die Oracle EPM Cloud

Wie viele etablierte Anbieter verlagert Oracle sein Performance-Management-Angebot zunehmend in die Cloud. Neben den klassischen, im eigenen Rechenzentrum betriebenen Hyperion-Produkten stehen cloudbasierte EPM-Dienste bereit, die vergleichbare Aufgaben als Abonnement abbilden und laufend aktualisiert werden. Für Unternehmen, die Hyperion einsetzen oder einführen möchten, bedeutet das: Die aktuelle Produktstrategie und die Migrationspfade des Herstellers sollten genau geprüft werden, da sich Bezeichnungen, Funktionsumfang und Betriebsmodelle in diesem Bereich laufend weiterentwickeln. Wer EPM erwägt, sollte zudem klären, ob der tatsächliche Bedarf eine dedizierte Lösung rechtfertigt oder ob das Controlling-Modul des vorhandenen ERP-Systems bereits ausreicht.

Planung und Konsolidierung im Detail

Die beiden Kerndisziplinen einer EPM-Lösung wie Hyperion verdienen einen genaueren Blick, weil sie unterschiedliche Aufgaben erfüllen. Bei der Planung und Budgetierung geht es darum, Zukunftszahlen zu erstellen: Fachbereiche erfassen ihre Plandaten, die zu einem Gesamtbudget zusammengeführt werden, Szenarien und Forecasts werden gerechnet, und Plan- werden laufend mit Ist-Werten verglichen. Dieser Prozess löst die in vielen Unternehmen verbreitete, fehleranfällige Planung über verteilte Tabellen ab und schafft eine konsistente, nachvollziehbare Grundlage.

Die Finanzkonsolidierung hingegen blickt auf die Vergangenheit und erstellt den Konzernabschluss. Sie führt die Einzelabschlüsse mehrerer Gesellschaften zusammen, eliminiert konzerninterne Geschäfte und Beteiligungen, rechnet Fremdwährungen um und stellt sicher, dass das Ergebnis den Rechnungslegungsvorschriften entspricht. Beide Disziplinen setzen auf verlässlichen Ist-Daten auf, die typischerweise aus dem ERP stammen. Erst diese Datenbasis macht aussagekräftige Planung und korrekte Konsolidierung möglich. Für kleinere Unternehmen sind solche spezialisierten Prozesse überdimensioniert – sie werden erst relevant, wenn die Zahl der Gesellschaften und die Komplexität der Finanzstruktur ein gewisses Maß überschreiten. Dann jedoch wird eine dedizierte EPM-Lösung zum wertvollen Werkzeug, das ein ERP allein nicht ersetzen kann.

Datenqualität als Voraussetzung für EPM

Eine EPM-Lösung wie Hyperion ist immer nur so gut wie die Daten, mit denen sie arbeitet. Planung, Forecasting und Konsolidierung setzen auf den operativen Zahlen auf, die typischerweise aus dem ERP und weiteren Quellsystemen stammen. Sind diese Daten unvollständig, uneinheitlich oder fehlerhaft, leiden auch die darauf aufbauenden Analysen und Berichte. Bevor ein Unternehmen in eine dedizierte EPM-Lösung investiert, sollte deshalb die Qualität und Konsistenz der zugrunde liegenden Daten sichergestellt sein. Dazu gehören einheitliche Kontenrahmen, saubere Stammdaten und verlässliche Schnittstellen zwischen den Systemen. Oft lohnt es sich, zunächst die Datenbasis im ERP zu konsolidieren, bevor eine übergeordnete Planungsebene aufgesetzt wird. So entfaltet EPM seinen Nutzen – als verlässliches Steuerungsinstrument statt als beeindruckende Hülle über unsicheren Zahlen.

EPM und ERP – zwei verschiedene Welten

Hyperion ist keine ERP-Software, sondern eine Lösung für Enterprise Performance Management (EPM). Der Unterschied ist grundlegend:

Vereinfacht gesagt: Das ERP wickelt das Geschäft ab, EPM wie Hyperion steuert und plant es auf Konzernebene. Beide ergänzen sich – EPM-Systeme greifen häufig auf Daten aus einem oder mehreren ERP-Systemen zurück.

Wofür Unternehmen Hyperion einsetzen

• Konzernkonsolidierung mehrerer Gesellschaften
• Budgetierung, Planung und Forecasting
• Management-Reporting und Kennzahlenanalyse
• gesetzliche und Management-Abschlüsse

Hyperion im Wandel zu Cloud-EPM

Oracle Hyperion entstand als eigenständige Produktfamilie und wurde Teil des Oracle-Portfolios. Der strategische Fokus liegt heute auf den Cloud-EPM-Diensten, während etablierte Hyperion-Komponenten weiterhin im Einsatz sind. Wer „Hyperion“ hört, denkt meist an leistungsstarke Konsolidierung und Planung großer Organisationen.

Brauche ich Hyperion – oder reicht das ERP?

Die Hyperion-Module im Einzelnen: HFM, Planning, Essbase und FDMEE

Wer zum ersten Mal mit Oracle Hyperion in Berührung kommt, unterschätzt häufig, dass sich hinter dem Namen kein einzelnes Programm verbirgt, sondern eine zusammengesetzte Produktlandschaft. Hyperion ist eine modulare Suite für das Enterprise Performance Management (EPM) – ein Verbund eigenständiger Anwendungen, die jeweils einen klar umrissenen Zweck erfüllen, sich aber über gemeinsame technische Fundamente miteinander verzahnen. Genau diese Modularität ist der Grund, warum zwei Unternehmen, die beide „Hyperion einsetzen“, völlig unterschiedliche Systeme betreiben können: Das eine nutzt vielleicht nur die Konsolidierung, das andere kombiniert Konsolidierung, Planung und eine analytische Datenbank zu einer integrierten Steuerungsplattform.

Dieser Abschnitt seziert die zentralen Bausteine einzeln und macht ihre Aufgabenteilung trennscharf sichtbar. Es geht ausdrücklich nicht um die historische Produktfamilie als Ganzes, sondern um die Funktion jedes Moduls, um die jeweils typische Nutzergruppe und um die Frage, wie die Module technisch ineinandergreifen. Wer die Architektur einmal verstanden hat, erkennt schnell, wo die Grenze zwischen einem reinen Buchhaltungssystem und einer EPM-Plattform verläuft – eine Unterscheidung, die auch bei jeder späteren ERP-Auswahl oder Systemkonsolidierung eine Rolle spielt.

Hyperion Financial Management (HFM): die Konsolidierungs-Engine

Hyperion Financial Management, kurz HFM, ist das Modul für die gesetzliche und Management-Konsolidierung. Seine Kernaufgabe besteht darin, die Einzelabschlüsse vieler rechtlicher Einheiten eines Konzerns zu einem konsolidierten Konzernabschluss zusammenzuführen. Dabei übernimmt HFM die Schritte, die einen Konzernabschluss von einer simplen Summierung unterscheiden: die Eliminierung konzerninterner Geschäftsvorfälle (Intercompany-Abstimmung), die Behandlung von Beteiligungen und Minderheitenanteilen, die Währungsumrechnung von Fremdwährungsabschlüssen sowie die Verbuchung von Konsolidierungsanpassungen und Journalbuchungen auf Konzernebene.

HFM denkt in Dimensionen. Jeder Wert hängt nicht nur an einem Konto, sondern zugleich an einer Einheit (Entity), einer Periode, einem Szenario (etwa Ist, Plan oder Forecast), einer Währung und weiteren frei definierbaren Sichten. Diese mehrdimensionale Struktur erlaubt es, denselben Datenbestand zugleich nach rechtlicher Konzernstruktur und nach Management-Sicht auszuwerten, ohne die Zahlen doppelt erfassen zu müssen. HFM führt darüber hinaus einen revisionssicheren Nachweis darüber, wie sich ein konsolidierter Wert zusammensetzt – vom gemeldeten Einzelwert über die Umrechnung bis zur Eliminierung. Diese Nachvollziehbarkeit ist der Grund, warum HFM in vielen Konzernen über Jahre das Rückgrat der Abschlusserstellung war.

Die typische Nutzergruppe von HFM ist die Konzernkonsolidierung: Group Accounting, Konzernrechnungswesen und die zentrale Bilanzierungsabteilung. Es sind Anwenderinnen und Anwender, die mit Konsolidierungslogik, Konzernrichtlinien und Reporting-Standards wie IFRS oder HGB vertraut sind. Für sie ist HFM weniger ein Eingabewerkzeug als ein Regelsystem: Sie definieren die Konsolidierungsregeln, überwachen die Datenanlieferung der Tochtergesellschaften und gegeben das konsolidierte Ergebnis frei. Wie der eigentliche Periodenabschluss von der Datenmeldung bis zum freigegebenen Konzernreporting abläuft, ist ein eigenes Thema, das an anderer Stelle dieser Seite ausführlich behandelt wird.

Hyperion Planning: Budgetierung, Forecast und operative Steuerung

Während HFM rückwärts gewandt ist und feststellt, was geschehen ist, blickt Hyperion Planning nach vorn. Das Modul dient der Budgetierung, der Planung und dem rollierenden Forecast. Hier entstehen die Jahresbudgets, die unterjährigen Hochrechnungen und die mittelfristigen Pläne, mit denen ein Unternehmen seine finanzielle und operative Zukunft modelliert. Planning stellt dafür Eingabemasken, Workflow- und Genehmigungsprozesse sowie Plan-Logiken bereit: Wer plant welchen Bereich, in welcher Reihenfolge werden Planversionen genehmigt, und wie greifen Teilpläne – etwa Personal-, Absatz- und Investitionsplanung – zu einem konsistenten Gesamtbild ineinander.

Charakteristisch für Planning ist die treiberbasierte Planung: Anstatt jede Zahl manuell einzutippen, hinterlegen die Anwender Annahmen und Treiber – beispielsweise Mengen, Preise, Wachstumsraten oder Personalstandards –, aus denen sich abgeleitete Werte rechnerisch ergeben. Ändert sich eine Annahme, rechnen sich die abhängigen Größen automatisch neu. Diese Rechenlogik ist kein Zufallsprodukt von Planning selbst, sondern wird von der darunterliegenden Berechnungs-Engine erbracht – ein Punkt, auf den der nächste Abschnitt zu Essbase eingeht, denn er erklärt die Architektur der gesamten Suite.

Die Nutzergruppe von Planning ist deutlich breiter gestreut als bei HFM. Neben dem zentralen Controlling und der Finanzplanung arbeiten hier Fachbereichsverantwortliche, Kostenstellenleiter, der Vertrieb und die Personalplanung mit. Viele dieser Anwender sind keine Bilanzierungsexperten, sondern operative Verantwortliche, die ihren Bereich planen. Entsprechend liegt der Schwerpunkt auf einer eingängigen Eingabeoberfläche, klaren Verantwortlichkeiten und einem nachvollziehbaren Freigabeprozess. Die Anforderung an ein gutes Planungssystem ähnelt damit jener an eine zugängliche ERP-Lösung: Die fachliche Logik muss korrekt sein, ohne dass jeder Anwender die technische Mechanik dahinter durchdringen muss.

Essbase: die OLAP-Engine unter der Oberfläche

Essbase – der Name steht für Extended Spread Sheet Database – ist das technische Herzstück, das viele Anwender nie unmittelbar zu Gesicht bekommen. Es handelt sich um eine multidimensionale OLAP-Datenbank (Online Analytical Processing), die für analytische Auswertungen und schnelle Aggregationen über viele Dimensionen hinweg optimiert ist. Anders als eine klassische relationale Datenbank, die Daten in Zeilen und Spalten von Tabellen speichert, organisiert Essbase Werte in einem mehrdimensionalen Würfel (Cube). Eine Kennzahl wird dort nicht als isolierte Zeile gehalten, sondern als Schnittpunkt mehrerer Dimensionen – etwa Konto, Zeit, Szenario, Produkt und Region.

Der entscheidende Mehrwert von Essbase liegt in der Berechnung und Aggregation. Hierarchien wie „Quartal summiert sich aus Monaten“ oder „Konzern summiert sich aus Regionen aus Ländern“ sind in der Würfelstruktur angelegt, sodass Summen entlang dieser Hierarchien sehr schnell verfügbar sind. Komplexere Rechenvorschriften – Allokationen, Verteilungen, abgeleitete Kennzahlen – werden über Rechenskripte (Calc Scripts) und Geschäftsregeln definiert. Essbase tritt klassisch in zwei Ausprägungen auf: als blockbasierte (Block Storage, BSO) Variante, die für schreibintensive Anwendungen mit Dateneingabe und komplexen Berechnungen gedacht ist, und als aggregationsbasierte (Aggregate Storage, ASO) Variante, die auf große, eher lesende Reporting-Würfel mit vielen Dimensionen zugeschnitten ist.

Die wichtigste architektonische Aussage dieses Abschnitts lautet: Essbase ist die Engine unter Hyperion Planning. Wenn ein Planungsanwender eine Annahme ändert und die abgeleiteten Werte sich neu berechnen, dann geschieht diese Berechnung in einem Essbase-Würfel, der die Planning-Anwendung mit Rechenleistung und Speicherstruktur versorgt. Planning liefert die fachliche Anwendung – Eingabeformulare, Workflows, Versionierung –, während Essbase darunter die multidimensionale Datenhaltung und die eigentliche Rechenarbeit übernimmt. Wer die Performance einer Planungsanwendung verbessern will, optimiert daher in aller Regel nicht die Oberfläche, sondern die Würfeldimensionierung und die Rechenskripte auf der Essbase-Ebene. Essbase lässt sich daneben auch eigenständig als analytische Datenbank für Ad-hoc-Analysen betreiben, doch sein größter Hebel innerhalb der Suite ist die Rolle als gemeinsame Rechenschicht.

FDMEE: Datenintegration als Fundament

Kein EPM-System ist besser als die Daten, mit denen es gefüttert wird. Genau an dieser Stelle setzt FDMEE an – Financial Data Quality Management, Enterprise Edition. Das Modul ist die Datenintegrations- und Datenqualitätsschicht der Suite. Seine Aufgabe besteht darin, Finanz- und Bewegungsdaten aus den Vorsystemen – insbesondere aus dem Hauptbuch eines ERP-Systems – zu extrahieren, sie auf die Strukturen der Hyperion-Anwendungen abzubilden und sie vor der Übernahme zu validieren.

Der Kern von FDMEE ist das Mapping: Quellkonten, Kostenstellen und Organisationseinheiten der Vorsysteme entsprechen selten eins zu eins den Konten und Dimensionen der Zielanwendung. FDMEE übersetzt diese Strukturen anhand definierter Zuordnungsregeln, sodass etwa hunderte Sachkonten eines ERP-Systems sauber auf die Kontenhierarchie in HFM oder Planning abgebildet werden. Ebenso wichtig ist die Nachvollziehbarkeit: FDMEE protokolliert, woher ein Wert stammt, und erlaubt einen Rückverweis (Drill-Back) von einer aggregierten Zahl in der EPM-Anwendung bis hinunter zum Quellbeleg im Vorsystem. Validierungsregeln stellen sicher, dass nur vollständige und abgestimmte Daten in die Anwendungen gelangen.

Die Nutzergruppe von FDMEE ist eher technisch-administrativ geprägt: Datenverantwortliche, EPM-Administratoren und Schnittstellenbetreuer richten die Importprozesse, Mappings und Validierungen ein und überwachen die periodischen Datenläufe. Für die Fachanwender in HFM oder Planning bleibt FDMEE meist unsichtbar – sie merken es nur dann, wenn Daten fehlen oder nicht abgestimmt sind. Die Frage, an welchen Punkten EPM und ERP konkret Daten austauschen und wie die Systemwelten organisatorisch zusammenspielen, wird in einem eigenen Abschnitt dieser Seite vertieft; hier genügt die Einordnung, dass FDMEE die unterste, datenseitige Schicht der Hyperion-Architektur bildet.

Smart View und Financial Reporting: die Frontends

Die beiden klassischen Frontends der Suite bedienen zwei unterschiedliche Bedürfnisse. Smart View ist ein Add-in für Microsoft Office, allen voran für Excel. Es verbindet die vertraute Tabellenkalkulation direkt mit den Hyperion-Datenquellen und erlaubt es Anwendern, lebendige Daten in Excel zu ziehen, durch Hierarchien zu navigieren (Drill-down), Ad-hoc-Analysen aufzubauen und – im Fall von Planning – Werte direkt aus Excel heraus zurück in die Anwendung zu schreiben. Smart View ist damit das Werkzeug der Wahl für alle, die ohnehin in Excel zu Hause sind: Controller, Planungsverantwortliche und Analysten, die flexibel mit Zahlen arbeiten wollen, ohne ihre gewohnte Umgebung zu verlassen.

Financial Reporting dagegen dient der Erstellung formatierter, standardisierter und wiederkehrender Berichte – etwa Monatsreports, Bilanz- und GuV-Darstellungen oder Management-Berichtsbücher mit festem Layout. Wo Smart View die freie Exploration ermöglicht, liefert Financial Reporting das pixelgenaue, druckbare Ergebnis, das Periode für Periode in gleicher Form benötigt wird. Beide Frontends greifen lesend auf dieselben Anwendungsmodule und letztlich auf dieselben Essbase-Würfel zu, sodass die Zahlen in der Ad-hoc-Analyse und im formatierten Bericht aus einer Quelle stammen.

Wie die Module ineinandergreifen

Der Reiz von Hyperion liegt weniger in den einzelnen Modulen als in ihrem Zusammenspiel. Die Architektur lässt sich als Stapel lesen, wie ihn die Grafik oben zeigt: Ganz unten sorgt FDMEE dafür, dass abgestimmte Daten aus den Vorsystemen überhaupt verfügbar sind. Darüber liegt Essbase als Berechnungs- und Speicher-Engine. Auf dieser Engine setzen die Anwendungsmodule auf – HFM für die Konsolidierung, Planning für die Budgetierung, ergänzt um spezialisierte Module wie die Profitabilitäts- und Kostenrechnung. Ganz oben schließlich greifen die Frontends Smart View und Financial Reporting auf diese Anwendungen zu und machen die Zahlen für den Menschen sicht- und bearbeitbar.

Dieses Schichtenprinzip erklärt auch, warum die Aussage „wir nutzen Hyperion“ so wenig präzise ist: Ein Unternehmen kann allein FDMEE und Essbase für analytische Zwecke betreiben, ein anderes setzt HFM auf, ein drittes kombiniert Planning und HFM zu einem geschlossenen Plan-Ist-Vergleich. Die Module sind eigenständig lizenzier- und betreibbar, teilen sich aber gemeinsame Fundamente wie die Datenintegration und die OLAP-Engine. Genau diese Baukastenlogik unterscheidet eine EPM-Suite von einem monolithischen Programm – und sie macht die Entscheidung für oder gegen einzelne Bausteine zu einer eigenständigen, begründungspflichtigen Architekturfrage.

Damit ist der funktionale und architektonische Rahmen der klassischen Hyperion-Suite abgesteckt. Welche Konsequenzen sich daraus für den eigentlichen Abschlussprozess, für das Zusammenspiel mit dem ERP-System, für die Support-Perspektive der On-Premise-Welt und für mögliche Alternativen ergeben, ist Gegenstand der weiteren Abschnitte dieser Seite.

Der Financial-Close-Prozess mit Hyperion: vom Periodenabschluss zum Konzernreporting

Der Konzernabschluss ist kein einzelner Knopfdruck, sondern ein streng getakteter Prozess, an dem in größeren Unternehmensgruppen Dutzende Personen über mehrere Tage bis Wochen mitwirken. Oracle Hyperion Financial Management (HFM) wurde genau für diesen Prozess gebaut: Es nimmt die Zahlen der einzelnen Tochtergesellschaften entgegen, rechnet fremde Währungen um, gleicht konzerninterne Geschäfte ab, eliminiert sie und verdichtet alles zu einem konsolidierten Abschluss, der sowohl dem Management als auch externen Adressaten standhält. Während andere Abschnitte dieser Seite die einzelnen Hyperion-Module und ihre Funktionsdefinition beschreiben, geht es hier ausschließlich um den fachlichen Ablauf: Wer liefert wann was, in welcher Reihenfolge laufen die Schritte ab, und wie sichert HFM die Nachvollziehbarkeit der Ergebnisse. Der Fokus liegt also auf dem Workflow und der Rollenverteilung, nicht auf der reinen Werkzeugbeschreibung.

Charakteristisch für den Financial Close ist sein zyklischer Charakter: Monat für Monat, Quartal für Quartal und schließlich zum Geschäftsjahresende wiederholt sich derselbe Ablauf. Diese Wiederholbarkeit ist zugleich Stärke und Anforderung. Stärke, weil sich ein eingespielter Prozess automatisieren und beschleunigen lässt. Anforderung, weil jeder Periodenabschluss prüfbar, dokumentiert und auf den Cent abstimmbar sein muss. Damit unterscheidet sich der Close grundlegend von der vorausschauenden Planung im operativen System oder im Hyperion-Planning-Modul: Beim Abschluss geht es nicht um zukünftige Annahmen, sondern um die korrekte Verdichtung tatsächlicher, bereits realisierter Ist-Zahlen.

Phase 1: Datenanlieferung aus den Vorsystemen

Am Anfang jedes Periodenabschlusses steht die Datenanlieferung. Jede rechtlich selbstständige Einheit eines Konzerns – die Tochtergesellschaft oder, in der Sprache der Konsolidierung, die Einzelgesellschaft – führt ihre eigene Buchhaltung, häufig in einem eigenen ERP-System und nicht selten in unterschiedlichen Software-Welten. Eine deutsche Gesellschaft bucht vielleicht in einer SAP-Umgebung, eine osteuropäische Einheit in einer lokalen Lösung und eine kleinere Beteiligung in einem schlanken Mittelstandssystem. HFM selbst bucht keine Geschäftsvorfälle; es konsumiert die fertigen Salden und Bewegungen dieser Vorsysteme.

Die Anlieferung erfolgt in der Regel nicht direkt, sondern über eine Datendrehscheibe, die Konten, Kostenstellen und Strukturen aus den heterogenen Quellsystemen auf den einheitlichen Konzernkontenrahmen abbildet. Diese Übersetzungsleistung – das sogenannte Mapping – ist der entscheidende Schritt, damit Zahlen aus unterschiedlichen Buchungslogiken überhaupt vergleichbar werden. Der technische Mechanismus dieser Datenübergabe, einschließlich der Rolle von FDMEE, wird im Abschnitt zu den Schnittstellen und dem Zusammenspiel der Systemwelten behandelt; hier interessiert nur, dass am Ende dieser Phase für jede Einzelgesellschaft ein vollständiges, geprüftes und auf den Konzernkontenrahmen normiertes Datenpaket in HFM vorliegt.

Verantwortlich für die Anlieferung sind die lokalen Buchhaltungs- und Controllingteams der Tochtergesellschaften. Sie melden ihre Daten innerhalb eines vorgegebenen Zeitfensters und bestätigen deren Vollständigkeit. In HFM lässt sich dieser Status über sogenannte Prozess-Management-Stufen abbilden: Erst wenn eine Einheit ihre Daten formal eingereicht und freigegeben hat, gilt ihr Beitrag als abschlussreif. Diese Statusverwaltung ist der erste Berührungspunkt mit dem Gedanken der kontrollierten Freigabe, der den gesamten Close durchzieht.

Phase 2: Währungsumrechnung

Sobald die lokalen Daten vorliegen, müssen alle Beträge in eine einheitliche Konzernwährung – beispielsweise Euro – überführt werden. Die Währungsumrechnung ist die Übertragung von Beträgen aus der Berichtswährung einer Einzelgesellschaft in die Berichtswährung des Konzerns unter Anwendung definierter Wechselkurse. Das klingt einfach, ist es aber nicht: Unterschiedliche Posten der Bilanz und Gewinn-und-Verlust-Rechnung werden mit unterschiedlichen Kursen umgerechnet. Bestandsgrößen wie Vermögen und Schulden werden üblicherweise zum Stichtagskurs des Periodenendes bewertet, während Aufwendungen und Erträge zu Durchschnitts- oder Transaktionskursen umgerechnet werden, und das Eigenkapital zu historischen Kursen.

Aus diesen Kursdifferenzen entstehen rechnerische Umrechnungsdifferenzen, die HFM separat ausweist und nach den hinterlegten Regeln des jeweiligen Rechnungslegungsstandards behandelt. HFM verwaltet die Wechselkurse zentral in eigenen Kurstabellen und wendet die Umrechnungslogik automatisiert auf die hinterlegten Kontentypen an. Die fachliche Verantwortung für die Pflege der Kurse und die Definition der Umrechnungsregeln liegt typischerweise beim zentralen Konzern-Accounting, das damit sicherstellt, dass alle Einheiten nach identischen Vorgaben behandelt werden. Erst nach erfolgreicher Umrechnung liegen die Daten aller Gesellschaften in einer gemeinsamen Währung vor und können miteinander verrechnet werden.

Phase 3: Intercompany-Abstimmung und -Eliminierung

Konzerne handeln mit sich selbst: Eine Tochter liefert Waren an eine Schwestergesellschaft, eine Holding vergibt Darlehen an ihre Beteiligungen, eine Servicegesellschaft stellt anderen Einheiten Leistungen in Rechnung. Aus Sicht der einzelnen Gesellschaft sind das echte Umsätze, Forderungen und Verbindlichkeiten. Aus Sicht des Gesamtkonzerns existieren sie jedoch nicht – ein Unternehmen kann mit sich selbst keinen Gewinn erzielen oder sich selbst etwas schulden. Genau hier setzt die Intercompany-Behandlung an.

Im ersten Schritt erfolgt die Intercompany-Abstimmung: HFM stellt die wechselseitig gemeldeten konzerninternen Positionen gegenüber. Hat Gesellschaft A eine Forderung von 100 an Gesellschaft B gemeldet, muss B spiegelbildlich eine Verbindlichkeit von 100 an A ausweisen. Stimmen die Beträge nicht überein – etwa wegen Buchungszeitpunkten, Kursunterschieden oder Erfassungsfehlern – zeigt HFM diese Differenzen in Abstimmungsberichten an. Die beteiligten Gesellschaften klären die Abweichungen, bis die Salden ausgeglichen sind. Diese Abstimmungsschleife ist einer der zeitkritischsten Teile des Close, weil sie die Mitwirkung mehrerer Einheiten gleichzeitig erfordert.

Erst auf der abgestimmten Basis erfolgt die Eliminierung. Eliminierung bezeichnet das buchhalterische Herausrechnen aller konzerninternen Beziehungen, damit der Konzernabschluss nur noch Geschäfte mit Dritten außerhalb des Konzernkreises zeigt. Eliminiert werden insbesondere konzerninterne Umsätze und Aufwendungen, gegenseitige Forderungen und Verbindlichkeiten sowie Zwischengewinne aus Lieferungen, die der Empfänger noch auf Lager hält. HFM erzeugt diese Eliminierungsbuchungen weitgehend automatisch auf Basis der gekennzeichneten Intercompany-Partner und der Konsolidierungsregeln. Das Ergebnis ist ein Zahlenwerk, das die wirtschaftliche Einheit Konzern so darstellt, als handle es sich um ein einziges Unternehmen.

Phase 4: Konsolidierungsläufe und Minderheitenanteile

Mit abgestimmten und um Intercompany-Beziehungen bereinigten Daten startet der eigentliche Konsolidierungslauf. HFM verdichtet die Zahlen entlang der hinterlegten Konzernstruktur – einer Hierarchie, die abbildet, welche Gesellschaft zu welcher Teilgruppe und schließlich zur Konzernmutter gehört. Der Lauf aggregiert die bereinigten Einzelwerte stufenweise nach oben und wendet dabei auf jeder Ebene die zutreffenden Konsolidierungsregeln an.

Eine zentrale fachliche Frage in dieser Phase sind die Minderheitenanteile, auch nicht beherrschende Anteile genannt. Besitzt die Konzernmutter eine Tochter nicht vollständig, sondern hält beispielsweise nur einen Mehrheitsanteil, so wird die Tochter zwar voll in den Konzernabschluss einbezogen, weil der Konzern sie beherrscht. Gleichzeitig steht aber ein Teil ihres Eigenkapitals und ihres Ergebnisses wirtschaftlich den konzernfremden Gesellschaftern zu. Dieser fremde Anteil wird als Minderheitenanteil separat ausgewiesen, damit erkennbar bleibt, welcher Teil des Konzernergebnisses tatsächlich den Anteilseignern der Mutter und welcher Teil den außenstehenden Gesellschaftern zuzurechnen ist. HFM berechnet diese Aufteilung anhand der hinterlegten Beteiligungsquoten automatisch innerhalb des Konsolidierungslaufs.

Die Methode des Einbezugs richtet sich nach der Beteiligungshöhe und der Beherrschungssituation. Die folgende Übersicht ordnet die gängigen Fälle ein, ohne den Anspruch auf jede rechtliche Feinheit zu erheben:

Der Konsolidierungslauf ist in HFM wiederholbar: Werden nach dem ersten Lauf noch Daten korrigiert oder nachgemeldet, lässt sich der Lauf erneut anstoßen. HFM erkennt dabei, welche Teilbereiche der Hierarchie tatsächlich neu berechnet werden müssen, und verarbeitet nur diese – ein wichtiger Mechanismus, um die ohnehin knappe Abschlusszeit nicht durch unnötige Vollberechnungen zu verlieren.

Phase 5: Journale und Anpassungsbuchungen

Nicht jeder Sachverhalt lässt sich automatisch ableiten. Für bewusst gesetzte Korrekturen kennt HFM Journale – manuelle Anpassungsbuchungen, die direkt auf Konsolidierungsebene erfasst werden, ohne in den Vorsystemen zu buchen. Typische Anwendungsfälle sind nachträgliche Bewertungsanpassungen, Reklassifizierungen zwischen Posten, die Korrektur erkannter Fehler oder konzernspezifische Buchungen, die es in keiner einzelnen Gesellschaft gibt.

Journale unterliegen in HFM einem eigenen Lebenszyklus mit klar getrennten Rollen. Ein Sachbearbeiter erfasst das Journal im Status Entwurf, ein zweiter, berechtigter Anwender prüft und genehmigt es, und erst danach wird es gebucht (gepostet) und wirkt sich auf die Konsolidierung aus. Diese Trennung von Erfassung und Freigabe – das Vier-Augen-Prinzip – ist kein Komfortmerkmal, sondern eine zentrale Kontrolle: Niemand soll eine ergebniswirksame Buchung allein und unbemerkt vornehmen können. Jedes Journal trägt eine Begründung und ist damit für spätere Prüfungen erklärbar.

Eng damit verbunden ist der Audit-Trail: die lückenlose, chronologische Aufzeichnung aller Datenänderungen, Buchungen und Freigaben mit Angabe von Anwender, Zeitpunkt und Vorgang. In HFM bedeutet das, dass sich für jeden Wert nachvollziehen lässt, woher er stammt, wer ihn wann angepasst hat und welche Journale ihn beeinflusst haben. Diese Nachvollziehbarkeit ist die Grundlage dafür, dass ein Abschluss prüfungsfest ist – also einer Wirtschaftsprüfung standhält. Ohne einen solchen durchgängigen Nachweis bliebe jede Korrektur eine Behauptung; mit ihm wird der gesamte Weg vom angelieferten Saldo bis zur konsolidierten Berichtszeile rekonstruierbar.

Phase 6: Management- und Legal-Reporting

Am Ende des Prozesses steht die Auswertung der konsolidierten Zahlen, und hier teilt sich der Weg in zwei Stoßrichtungen. Das Legal-Reporting, also das gesetzliche Reporting, dient externen Adressaten: dem testierten Konzernabschluss, der Berichterstattung gegenüber Aufsichtsbehörden und der Veröffentlichung. Es folgt strikt den Vorgaben des angewandten Rechnungslegungsstandards und ist auf rechtliche Korrektheit und Vergleichbarkeit ausgelegt. Das Management-Reporting dagegen richtet sich nach innen: Es bereitet dieselbe Datenbasis für Vorstand, Bereichsleitung und Controlling so auf, dass sie Steuerungsentscheidungen unterstützt – etwa entlang von Segmenten, Regionen oder Verantwortungsbereichen, oft mit zusätzlichen Kennzahlen und Vergleichen, die im Legal-Reporting keine Rolle spielen.

Beide Sichten speisen sich aus demselben konsolidierten Datenbestand, was eine zentrale Stärke des Hyperion-Ansatzes ist: Es gibt eine einzige verbindliche Wahrheit, aus der unterschiedliche Berichte abgeleitet werden, statt konkurrierender Tabellen mit abweichenden Zahlen. Bevor ein Bericht freigegeben wird, durchlaufen die Daten Validierungsregeln, die formale und betragsmäßige Konsistenz prüfen – etwa ob die Bilanz ausgeglichen ist oder ob alle Einheiten ihren Beitrag geliefert haben. Erst wenn diese Prüfungen bestanden sind, gibt der Konzernabschluss-Verantwortliche die Periode frei und schließt (sperrt) sie gegen weitere Änderungen.

Rollenverteilung und Freigabeschleifen im Überblick

Der gesamte Close ist über das Prozess-Management von HFM in Verantwortungsstufen organisiert. Lokale Teams reichen ihre Daten ein, ein Reviewer auf Teilkonzernebene prüft und genehmigt sie, und das zentrale Konzern-Accounting steuert Währungskurse, Konsolidierungsregeln, Journale und die finale Freigabe. Wird auf einer höheren Stufe ein Problem entdeckt – etwa eine nicht abgestimmte Intercompany-Position oder eine fehlerhafte Meldung – kann der Vorgang gezielt an die verantwortliche Einheit zurückgegeben werden, die korrigiert und erneut einreicht. Genau diese Rücksprünge sind die Verzweigungen im Prozessfluss: Der Close läuft nicht stur linear durch, sondern enthält bewusste Prüf- und Korrekturschleifen, bis jede Stufe ihren Beitrag freigegeben hat.

Diese klare Rollentrennung ist zugleich die Brücke zur Organisation: Wer einen Konzernabschluss in einem Werkzeug wie HFM sauber aufsetzen will, muss vorab definieren, welche Einheit welche Daten in welcher Frist liefert und wer auf welcher Ebene freigibt. Für Unternehmensgruppen, die diese Strukturen erst aufbauen oder von gewachsenen Tabellenlösungen kommen, ist das oft ein eigenes Projekt – ähnlich anspruchsvoll wie eine ERP-Einführung im operativen Bereich, weil es ebenso Prozessdisziplin wie Software erfordert. Der eigentliche Mehrwert von Hyperion im Close liegt deshalb weniger in einzelnen Rechenfunktionen als in der Verbindung aus automatisierter Verarbeitung, durchgängiger Nachvollziehbarkeit und einem erzwungenen Freigabeprozess, der den Abschluss Periode für Periode wiederholbar und prüfungsfest macht.

Wo EPM und ERP Daten austauschen: Schnittstellen und das Zusammenspiel der Systemwelten

Eine EPM-Plattform wie Hyperion erzeugt keine Buchungen. Sie plant, konsolidiert und analysiert – aber die belastbaren Ist-Zahlen, gegen die jede Planung gemessen wird, entstehen woanders: im operativen System der Buchhaltung. Genau deshalb entscheidet sich der Erfolg eines Hyperion-Betriebs weniger an der Konfiguration der Module selbst als an der Frage, wie sauber die Daten zwischen dem ERP-System und der EPM-Welt hin- und herwandern. Dieser Abschnitt betrachtet ausschließlich diese Nahtstelle: Welche Datenobjekte überqueren die Grenze, in welche Richtung, über welchen technischen Mechanismus und in welcher Frequenz. Die fachliche Abgrenzung der beiden Systemkategorien – was ein ERP-System leistet und worin sich EPM davon unterscheidet – ist an anderer Stelle geklärt; hier geht es um die Mechanik des Datenaustauschs.

Wichtig ist von Anfang an die Einsicht, dass dieser Austausch keine Einbahnstraße ist. Der Datenfluss ist bidirektional: Aus dem ERP-System strömen Ist-Daten in Richtung Hyperion – Hauptbuch-Salden, Kostenrechnungsdaten, Stammdaten. Aus Hyperion strömen abgeleitete Ergebnisse zurück – freigegebene Planwerte, Forecasts, mitunter konsolidierte Konzernzahlen, die in nachgelagerten Berichten wieder benötigt werden. Beide Richtungen folgen unterschiedlichen Regeln, haben unterschiedliche Empfänger und stellen unterschiedliche Anforderungen an Frequenz und Qualitätssicherung. Wer nur den Hinweg „Ist aus ERP“ im Blick hat, übersieht die Hälfte der Integrationsarbeit.

Der Hinweg: Ist-Daten aus dem ERP nach Hyperion

Der mengenmäßig größte und regelmäßigste Datenstrom verläuft vom ERP-System in Richtung EPM. Drei Kategorien von Daten sind dabei zu unterscheiden, weil sie unterschiedliche Wege gehen und unterschiedliche Pflege verlangen.

Erstens die Hauptbuch-Salden. Aus dem General Ledger des ERP-Systems werden die periodengerechten Salden je Konto, Buchungskreis und Periode extrahiert – in der Regel als aggregierte Trial-Balance-Auszüge, nicht als einzelne Belegzeilen. Diese Salden bilden das Fundament des Konzernabschlusses und des Plan-Ist-Vergleichs. Sie sind das, was die Konsolidierung verarbeitet und woran jede Planabweichung gemessen wird. Entscheidend ist hier die Periodenlogik: Es dürfen nur Salden übernommen werden, die im Quellsystem als final markiert oder zumindest abstimmungsbereit sind, sonst entsteht in Hyperion ein Bild, das sich nach der nächsten Nachbuchung im ERP wieder verschiebt.

Zweitens die Daten aus der Kostenrechnung. Kostenstellen, Kostenarten, innerbetriebliche Leistungsverrechnungen und gegebenenfalls Ergebnisrechnungs-Sichten liefern die feinere Granularität, die das Controlling für eine treiberbasierte Planung und für aussagekräftige Abweichungsanalysen benötigt. Während das Hauptbuch die bilanzielle Wahrheit liefert, liefert die Kostenrechnung die Steuerungssicht. Beide müssen in Hyperion zusammengeführt werden, ohne dass es zu Doppelzählungen kommt – ein klassischer Stolperstein, wenn dieselbe Information sowohl über die Hauptbuch- als auch über die Kostenrechnungsstrecke ankommt.

Drittens die Stammdaten, allen voran der Kontenrahmen, die Kostenstellen- und die Profit-Center-Hierarchien sowie die Liste der rechtlichen Einheiten. Stammdaten sind kein einmaliges Importthema, sondern eine Daueraufgabe: Jedes neue Konto, jede neue Gesellschaft, jede umorganisierte Kostenstelle im ERP muss sich auf der EPM-Seite wiederfinden, sonst laufen Bewegungsdaten ins Leere oder landen in einem Sammelposten. Auf die besondere Bedeutung der Stammdaten geht der Abschnitt zur Governance weiter unten gesondert ein.

FDMEE und Data Management als Brücke

Die technische Brücke zwischen den Welten ist in der klassischen On-Premise-Suite FDMEE (Financial Data Quality Management, Enterprise Edition), in der Cloud-Generation das funktional verwandte Data Management beziehungsweise Data Integration. Diese Komponente ist mehr als ein Importwerkzeug. Sie ist die kontrollierte Schleuse, durch die jeder Wert hindurchmuss, bevor er in einer EPM-Anwendung als belastbar gilt. Ein Datenladelauf in FDMEE folgt einem festen Vier-Schritt-Muster, das die Qualitätssicherung in den Prozess einbaut.

1. Import: Die Quelldaten werden aus dem ERP gezogen – entweder über eine direkte Adapter-Verbindung in das Hauptbuch oder über eine bereitgestellte Datei. Das Ergebnis liegt zunächst unverändert in einer Zwischenstruktur (Staging).
2. Validierung und Mapping: Die Quellstrukturen werden auf die Zieldimensionen abgebildet, und FDMEE prüft, ob jeder Quellwert eine gültige Zuordnung besitzt. Werte ohne Mapping bleiben sichtbar als Fehler stehen, statt stillschweigend zu verschwinden.
3. Export/Load: Die gemappten und validierten Daten werden in die Zielanwendung – etwa HFM oder Planning – geschrieben.
4. Check: Abschließende Prüfregeln stellen sicher, dass die geladenen Summen mit erwarteten Kontrollwerten übereinstimmen, bevor die Daten freigegeben werden.

Der entscheidende Mehrwert dieser Brücke ist die Nachvollziehbarkeit. FDMEE protokolliert lückenlos, woher ein Wert stammt, und erlaubt einen Rückverweis (Drill-Through beziehungsweise Drill-Back) von einer aggregierten Konzernzahl bis zurück in den Quellsaldo des ERP-Systems. Wenn im Konzernreporting eine Position auffällt, kann der Verantwortliche sie ohne Medienbruch bis zur Herkunft verfolgen. Diese Prüffähigkeit ist es, die einen kontrollierten Datentransfer von einem bloßen Datei-Export unterscheidet – und sie ist der Grund, warum manuelle Excel-Zwischenschritte in einem ernst gemeinten EPM-Betrieb so weit wie möglich zurückgedrängt werden.

Mapping: vom Kontenrahmen auf die EPM-Dimensionen

Das Herzstück der Integration ist das Mapping – die Übersetzung der ERP-Strukturen in die mehrdimensionale Sprache von Hyperion. Der Grund, warum dieser Schritt unverzichtbar ist, liegt in einer fundamentalen Strukturdifferenz: Ein ERP-System führt seine Werte typischerweise flach an einem Konto und einem Buchungskreis, eine EPM-Anwendung dagegen hängt jeden Wert an mehrere Dimensionen zugleich – Konto, Einheit, Periode, Szenario, Währung und weitere. Eine einzelne ERP-Buchungszeile muss also in einen Punkt im mehrdimensionalen Raum von Hyperion übersetzt werden, und diese Übersetzung leistet das Mapping.

Selten besteht dabei eine Eins-zu-eins-Beziehung. Ein detaillierter ERP-Kontenrahmen mit mehreren hundert Sachkonten wird auf der EPM-Seite oft auf eine bewusst gröbere, steuerungsorientierte Kontenhierarchie verdichtet. Mehrere Quellkonten fallen also auf ein Zielkonto zusammen (Many-to-one), oder ein Quellwert wird abhängig von einem zweiten Merkmal auf unterschiedliche Ziele verteilt. FDMEE kennt dafür abgestufte Mapping-Typen – von der expliziten Eins-zu-eins-Regel über Bereichs- und Wildcard-Regeln bis zu mehrstufigen, an Bedingungen geknüpften Zuordnungen.

Die folgende Tabelle macht den Datenfluss konkret. Sie zeigt für die wichtigsten Datenobjekte, woher sie kommen, wohin sie gehen, über welchen Mechanismus sie transportiert werden und wie oft das geschieht.

Frequenz: Batch-Abschlusslogik statt Echtzeit

Eine häufige Fehlannahme bei der Integration lautet, EPM-Systeme müssten möglichst nahe an der Echtzeit mit dem ERP gekoppelt sein. Das Gegenteil ist meist richtig – und zwar aus fachlichen, nicht aus technischen Gründen. Der dominierende Rhythmus von Hyperion ist der Periodenabschluss, und ein Abschluss ist seinem Wesen nach ein Stichtagsereignis. Solange die Buchungen einer Periode im ERP noch offen sind, wäre ein kontinuierlicher Datenstrom nach Hyperion sogar schädlich: Konsolidierte Zahlen würden sich ständig verändern, Abstimmungen liefen ins Leere, und die für den Abschluss nötige Stabilität ginge verloren. Deshalb arbeitet der klassische Datentransfer batchorientiert: Die Salden werden geladen, wenn die Periode im Quellsystem abstimmungsbereit ist.

Davon abzugrenzen sind zwei Sonderfälle. Erstens die häufigere Aktualisierung während der Planung – etwa wöchentliche oder tägliche Ist-Aktualisierungen, damit ein rollierender Forecast nicht auf veralteten Ist-Werten aufsetzt. Das ist häufigeres Batch, nicht Echtzeit. Zweitens der gezielte Drill-Through: Hier wird nicht permanent synchronisiert, sondern erst auf Anfrage eine Live-Verbindung zum Quellsystem geöffnet, um einen einzelnen Wert bis zum Beleg zu verfolgen. Das fühlt sich nach Echtzeit an, ist aber ein punktueller Nachschlag, kein Dauerstrom. Die Konsequenz für die Architektur: Man dimensioniert die Integration nach Abschlusskalender und Planungszyklus, nicht nach dem Ideal einer Sekunden-Synchronisierung. Eine durchdachte ERP-Implementierung sollte diese Frequenz-Anforderungen der nachgelagerten EPM-Welt bereits beim Schnittstellendesign mitdenken.

Der Rückweg: Plan- und Konsolidierungsdaten zurück in die Systemwelt

Die weniger beachtete, aber ebenso wichtige Richtung ist der Rückfluss. Sobald ein Planungszyklus abgeschlossen und ein Budget freigegeben ist, liegt der verbindliche Plan in Hyperion Planning. Dieser Plan wird in vielen Organisationen wieder zurück in das ERP-System oder in eine nachgelagerte Reporting-Schicht geschrieben – damit das operative System den Plan-Ist-Vergleich auf seiner eigenen Ebene fahren kann, damit Budgetkontrollen greifen und damit alle Beteiligten denselben verbindlichen Sollwert sehen. Technisch geschieht dieser Rückweg häufig über einen Datei-Export aus Hyperion und einen Ladejob auf der ERP-Seite, seltener über eine direkte Schnittstelle.

Analog dazu wandern die konsolidierten Konzernwerte aus HFM oft in ein Data Warehouse oder eine BI-Umgebung, wo sie mit anderen Datenquellen zu einem unternehmensweiten Reporting verschmelzen. Auch hier gilt die Stichtagslogik: Exportiert wird, was freigegeben ist. Der Rückweg stellt eine eigene Governance-Frage, denn nun verlässt eine in Hyperion erzeugte und verantwortete Zahl die EPM-Welt und wird in einem anderen System zur Grundlage von Entscheidungen. Die Zuordnungsregeln müssen deshalb auch rückwärts konsistent sein: Eine in der EPM-Dimension verdichtete Plangröße muss wieder so auf die ERP-Struktur aufgelöst werden, dass sie dort sinnvoll verglichen werden kann.

Stammdaten-Governance über beide Welten

Damit ist der kritischste Punkt der gesamten Integration erreicht. Bewegungsdaten – Salden, Ist-Werte, Pläne – flieszen periodisch und sind nach einem fehlerhaften Lauf korrigierbar. Stammdaten dagegen sind das Koordinatensystem, in dem alle Bewegungsdaten verortet werden. Stimmt das Koordinatensystem auf beiden Seiten nicht überein, hilft auch der sauberste Bewegungsdaten-Load nichts: Die Zahlen landen am falschen Ort oder gar nicht. Eine gemeinsame, abgestimmte Stammdaten-Logik ist deshalb keine Komfortfunktion, sondern die Voraussetzung dafür, dass Integration überhaupt verlässlich funktioniert.

Das Kernproblem ist die Drift: Im ERP werden laufend neue Konten angelegt, Kostenstellen umstrukturiert, Gesellschaften gegründet oder verschmolzen. Geschieht dies, ohne dass die EPM-Seite und ihre Mappings nachgezogen werden, entstehen verwaiste Quellwerte ohne gültiges Ziel. In einem gut geführten FDMEE-Setup fallen solche Fälle bei der Validierung als Fehler auf – das ist gewünscht, denn ein sichtbarer Fehler ist besser als ein still in einem Sammelposten versickerter Wert. Trotzdem ist jeder solche Fehler ein Symptom mangelnder Governance.

Eine belastbare Stammdaten-Governance über beide Welten ruht auf wenigen Grundsätzen:

• Eine führende Quelle je Stammdatenobjekt. Es muss eindeutig festgelegt sein, welches System für Konten, Kostenstellen und Einheiten den verbindlichen Stand hält – in aller Regel das ERP-System. Hyperion folgt, statt eigene, abweichende Strukturen zu pflegen.
• Ein definierter Änderungsprozess. Jede strukturelle Änderung im ERP löst eine nachgelagerte Pflege auf der EPM-Seite aus, bevor der nächste Bewegungsdaten-Load läuft – nicht erst, wenn etwas auffällt.
• Versionierte, dokumentierte Mappings. Zuordnungsregeln werden nicht stillschweigend überschrieben, sondern nachvollziehbar gepflegt, damit ein Wert auch rückwirkend erklärbar bleibt.
• Regelmäßige Abstimmung der Hierarchien. Kontenrahmen und Organisationsstrukturen werden periodisch zwischen beiden Welten abgeglichen, nicht nur bei akuten Problemen.

Warum diese Disziplin so kritisch ist, zeigt sich am deutlichsten an der gemeinsamen Kontenlogik. Wenn ERP und Hyperion ein unterschiedliches Verständnis davon haben, was auf einem Konto liegt – etwa weil im ERP eine Position brutto, in Hyperion aber netto geführt wird –, dann produziert die Integration formal fehlerfreie, inhaltlich aber falsche Zahlen. Solche Differenzen sind besonders tückisch, weil kein technischer Validierungslauf sie aufdeckt: Der Load läuft sauber durch, die Summen stimmen, und trotzdem bedeutet derselbe Kontoname auf beiden Seiten etwas anderes. Erst eine bewusst abgestimmte fachliche Definition – ein gemeinsames Datenglossar für Konten und Kennzahlen – verhindert diese Klasse von Fehlern. Wer eine spätere Systemkonsolidierung oder Migration plant, profitiert hier doppelt: Eine im Rahmen einer sauberen ERP-Lösung bereits disziplinierte Stammdatenpflege macht die Anbindung jedes EPM-Systems ungleich einfacher.

Zusammengefasst ist die Schnittstelle zwischen ERP und Hyperion kein einmalig zu bauendes technisches Rohr, sondern ein dauerhaft zu pflegender Prozess mit zwei Richtungen, klaren Frequenzregeln und einer Stammdaten-Governance als Rückgrat. FDMEE beziehungsweise Data Management liefert dafür das Werkzeug – Import, Mapping, Validierung, Drill-Back –, doch die eigentliche Leistung ist organisatorisch: die Verständigung darauf, welches System welche Wahrheit hält und wie Änderungen koordiniert werden. Wer diese Nahtstelle beherrscht, hat die Voraussetzung dafür geschaffen, dass der Periodenabschluss und das Konzernreporting reibungslos laufen können – ein Prozess, der an anderer Stelle dieser Seite im Detail betrachtet wird.

On-Premise Hyperion am Lebensende: Support-Fahrplan und Migrationsentscheidung

Kaum eine Frage beschäftigt Bestandskunden von Oracle Hyperion so sehr wie die nach dem Support-Status der eigenen Installation. Die On-Premise-Welt von Hyperion ist in den vergangenen Jahren durch einen klar terminierten Lebenszyklus gegangen, dessen Eckdaten unmittelbare Folgen für Betrieb, Sicherheit und Investitionsplanung haben. Wer heute eine Hyperion-Umgebung betreibt, muss wissen, in welchem Support-Modus sie läuft, welche Fristen bereits abgelaufen sind und welche Optionen sich daraus ergeben. Dieser Abschnitt zeichnet den Support-Fahrplan faktentreu nach und leitet daraus die Entscheidungslage ab, ohne über künftige Roadmaps zu spekulieren.

Es geht hier ausdrücklich nicht um die fachlichen Fähigkeiten der einzelnen Module oder um den Ablauf eines Konzernabschlusses, die an anderer Stelle dieser Seite behandelt werden. Im Mittelpunkt steht allein die Lebenszyklus- und Lizenzdimension: Wie lange wird eine bestimmte Hyperion-Version von Oracle unterstützt, was bedeuten die verschiedenen Support-Stufen konkret, und welche strategischen Wege stehen einem Unternehmen offen, dessen Plattform sich dem Lebensende nähert oder es bereits erreicht hat.

Der Wendepunkt Ende 2021: Release 11.1.2.4 verliert den Premier Support

Die über Jahre am weitesten verbreitete On-Premise-Generation war Release 11.1.2.4. Auf dieser Version liefen und laufen bis heute zahlreiche produktive Hyperion-Landschaften, darunter Installationen von Hyperion Financial Management (HFM) und Hyperion Planning. Genau für diese Generation hat Oracle einen klaren Schlussstrich gezogen: Mit dem Ablauf des Dezembers 2021 endete der reguläre Premier Support für die zentralen 11.1.2.x-Produkte. Ab Januar 2022 sind die betroffenen Installationen in den sogenannten Sustaining Support übergegangen.

Dieser Stichtag ist mehr als ein formaler Verwaltungsakt. Er markiert den Zeitpunkt, ab dem für 11.1.2.4 keine neuen Patches, keine neuen Sicherheitsaktualisierungen und keine neuen zertifizierten Plattformkombinationen mehr bereitgestellt werden. Eine Installation, die nach diesem Datum unverändert weiterläuft, ist technisch funktionsfähig, erhält aber von Oracle keine laufende Pflege mehr im Sinne fortlaufender Fehlerbehebung. Für Finanzprozesse, die regulatorischen Anforderungen unterliegen und auf einer aktuell gehaltenen Sicherheitsbasis aufsetzen sollten, ist das ein gewichtiger Punkt.

Wichtig ist die Abgrenzung zur Nachfolgeversion: Der Wechsel von 11.1.2.4 in den Sustaining Support bedeutet nicht das Ende von Hyperion als Produktlinie. Oracle hat parallel mit Release 11.2 eine neue On-Premise-Generation bereitgestellt, die unter einem grundlegend anderen Support-Modell steht. Bestandskunden auf 11.1.2.4 stehen damit nicht vor der Wahl zwischen Stillstand und Cloud, sondern haben mit dem Upgrade auf 11.2 einen dritten, oft übersehenen Weg innerhalb der On-Premise-Welt.

Sustaining Support versus Premier Support: der entscheidende Unterschied

Um die Tragweite des Stichtags Ende 2021 einzuordnen, lohnt sich ein genauer Blick auf die Support-Stufen, die Oracle im Rahmen seiner Lifetime Support Policy definiert. Premier Support und Sustaining Support sind keine graduellen Abstufungen derselben Leistung, sondern qualitativ verschiedene Betreuungsformen.

Premier Support ist die vollwertige Betreuungsstufe. Sie umfasst die laufende technische Unterstützung bei Störungen, die Bereitstellung neuer Fehlerbehebungen (Patches und Patch Sets), Sicherheitsaktualisierungen sowie Zertifizierungen für neue Betriebssystem-, Datenbank- und Browser-Versionen. Eine Plattform im Premier Support bleibt damit lauffähig auf einer sich weiterentwickelnden Infrastruktur und erhält im Störungsfall den vollen Service-Umfang.

Sustaining Support ist demgegenüber die niedrigste Stufe. Sie läuft zwar zeitlich unbefristet weiter, schließt aber wesentliche Leistungen aus: keine neuen Patches oder Fehlerbehebungen, keine neuen Sicherheitsupdates, keine neuen Zertifizierungen für aktuelle Betriebssysteme oder Datenbankversionen. Bereits früher veröffentlichte Korrekturen bleiben zugänglich, doch alles, was erst nach dem Eintritt in den Sustaining Support entstehen würde, wird für diese Version nicht mehr erstellt. Praktisch heißt das: Wer die Umgebung modernisieren, das Betriebssystem aktualisieren oder eine neuere Datenbank einsetzen will, bewegt sich außerhalb der zertifizierten und gepflegten Pfade.

Release 11.2 im Continuous-Innovation-Modell

Mit Release 11.2 hat Oracle die On-Premise-Linie unter ein verandertes Pflegemodell gestellt, das als Continuous Innovation bezeichnet wird. Der Grundgedanke: Statt regelmäßiger großer Versionssprünge, die jeweils ein vollständiges Upgrade-Projekt erfordern, wird die Plattform innerhalb der 11.2-Linie durch fortlaufende Aktualisierungen weiterentwickelt. Updates und technologische Verbesserungen fließen kontinuierlich ein, ohne dass Kunden einen erneuten Major-Upgrade-Aufwand stemmen müssen. Oracle hat 11.2 dabei als die On-Premise-Generation positioniert, die über einen langen Zeitraum die Basis bleiben soll.

Der entscheidende Vorteil aus Sicht eines Bestandskunden ist die Support-Perspektive: Release 11.2 steht im Premier Support, der nach Oracles Lifetime Support Policy voraussichtlich bis 2032 reicht. Diese Zusage ist allerdings mit einer Einschränkung verbunden, die man kennen sollte. Oracle gewährt diese verlängerte Premier-Support-Perspektive im Rahmen seines Continuous-Innovation- beziehungsweise Applications-Unlimited-Ansatzes und überprüft die Fortführung in jährlichen Reviews. Das Datum 2032 ist damit eine kommunizierte Perspektive auf Basis der bisherigen Politik, kein vertraglich fixierter Endpunkt, der unabhängig von künftigen Entscheidungen feststeht. Wir geben diese Jahreszahl hier so wieder, wie Oracle sie kommuniziert hat, und vermeiden bewusst jede Aussage darüber, wie sich die Roadmap nach diesem Zeitpunkt entwickeln könnte.

Für die Praxis ergibt sich daraus ein klarer Befund: Wer von 11.1.2.4 auf 11.2 wechselt, holt seine Plattform aus dem Sustaining Support zurück in den Premier Support und gewinnt damit wieder Zugang zu laufenden Patches, Sicherheitsupdates und Zertifizierungen für aktuelle Infrastruktur. Der Wechsel innerhalb der On-Premise-Welt ist damit kein bloßes kosmetisches Update, sondern die Rückkehr in einen vollwertig gepflegten Betriebszustand.

Die Entscheidungslage für Bestandskunden

Aus dem dargestellten Fahrplan ergeben sich für Unternehmen, die heute eine Hyperion-Umgebung betreiben, im Kern drei strategische Stoßrichtungen. Welche davon die richtige ist, hängt von der Ausgangslage, der bestehenden Lizenzierung, den internen Kompetenzen und der grundsätzlichen IT-Strategie ab. Eine sorgfältige Abwägung gehört in die gleiche Disziplin wie eine grundlegende ERP-Auswahl, bei der technische, wirtschaftliche und organisatorische Faktoren systematisch gegeneinander gestellt werden.

Option 1: Auf On-Premise bleiben und auf 11.2 aktualisieren

Für viele Bestandskunden ist das Upgrade von 11.1.2.4 auf 11.2 der naheliegende Schritt. Es behebt das zentrale Problem des abgelaufenen Premier Support, ohne die fachliche Architektur grundlegend zu verandern. Die Module bleiben dieselben, die Datenmodelle und etablierten Prozesse können weitgehend übernommen werden, und die Organisation muss sich nicht auf eine völlig neue Bedienlogik einstellen. Wer in den vergangenen Jahren erheblich in Regelwerke, Reportstrukturen und Schnittstellen investiert hat, schützt mit dem Upgrade diese Investitionen.

Gegenzurechnen ist, dass auch ein Upgrade innerhalb der On-Premise-Welt ein Projekt mit Aufwand bleibt: Es handelt sich technisch nicht um ein bloßes Patch, sondern um eine Neuinstallation der 11.2-Umgebung mit anschließender Migration der Anwendungsinhalte. Betriebssysteme, Datenbanken und Middleware müssen auf zertifizierte Stände gebracht werden. Diese Arbeit will geplant und getestet sein, lohnt sich aber, weil sie die Plattform für einen langen Zeitraum wieder in den vollwertigen Premier Support stellt. Unternehmen, die ihre Anwendungslandschaft ohnehin im eigenen Haus betreiben und über das nötige Betriebs-Know-how verfügen, finden hier den Weg mit der höchsten Kontinuität.

Option 2: In die Oracle EPM Cloud wechseln

Die zweite Stoßrichtung ist der Übergang in die Oracle EPM Cloud, das über denselben Zeitraum kontinuierlich ausgebaute Cloud-Angebot. Hier wandelt sich das Betriebsmodell grundlegend: Statt einer selbst betriebenen Installation tritt ein abonniertes Dienstmodell, in dem Oracle die Infrastruktur, die Aktualisierungen und einen Großteil des technischen Betriebs übernimmt. Der Reiz liegt darin, dass die Frage nach Support-Stichtagen und Plattform-Zertifizierungen in dieser Form entfällt, weil der Dienst fortlaufend aktuell gehalten wird.

Allerdings ist ein Cloud-Wechsel kein reines Hosting-Umzug, sondern in der Regel eine inhaltliche Neuaufsetzung. Anwendungen werden nicht eins zu eins übernommen, sondern in den Cloud-Diensten neu modelliert, weil sich Funktionsumfang, Konfigurationswege und teilweise auch die fachliche Logik unterscheiden. Das ist Chance und Aufwand zugleich: Es eröffnet die Möglichkeit, über die Jahre gewachsene Altlasten zu bereinigen und Prozesse neu zu ordnen, verlangt dafür aber ein eigenständiges Migrations- und Einführungsprojekt. Die methodische Herangehensweise ähnelt einer klassischen ERP-Implementierung mit Konzeptionsphase, Aufbau, Test und Schulung. Für Organisationen, die ihren Rechenzentrumsbetrieb verschlanken und sich von Infrastrukturpflege lösen wollen, ist dieser Weg strategisch attraktiv.

Option 3: Drittanbieter-Support und Marktalternativen prüfen

Eine dritte Möglichkeit besteht darin, die Plattform vorerst auf dem bestehenden Stand zu belassen und die Pflege über Drittanbieter abzusichern. Spezialisierte Dienstleister bieten unabhängigen Support für Hyperion-Installationen an, die im Sustaining Support stehen, und können Betrieb und Fehlerbehebung übernehmen, solange die Umgebung fachlich gut genug ist und kein zwingender Modernisierungsdruck besteht. Dieser Weg verschafft Zeit, etwa um eine größere strategische Entscheidung sorgfältig vorzubereiten, statt sie unter Termindruck zu treffen.

Er hat aber Grenzen. Drittanbieter können keine neuen Oracle-Patches oder Sicherheitsupdates erzeugen, die es nicht gibt, und das grundsätzliche Problem fehlender Plattform-Zertifizierungen für aktuelle Betriebssysteme und Datenbanken bleibt bestehen. Drittanbieter-Support ist damit sinnvoll als Überbrückung oder bewusste Auslaufstrategie, nicht als dauerhafte Zukunftsperspektive. In dieselbe Prüfkategorie gehört die Frage, ob ein vollständiger Wechsel auf ein anderes EPM-Produkt sinnvoll ist; diese Marktbetrachtung wird im neutralen Alternativen-Abschnitt dieser Seite vertieft. Wer eine grundlegende Neuausrichtung erwägt, sollte den Entscheidungsprozess wie jede strategische Systemwahl strukturiert aufsetzen und gegebenenfalls externe Beratung hinzuziehen, um fachliche, lizenzrechtliche und betriebliche Aspekte sauber zu trennen.

Worauf die Entscheidung praktisch hinausläuft

Die nüchterne Zusammenfassung lautet: Eine 11.1.2.4-Installation ist seit Anfang 2022 im Sustaining Support und erhält von Oracle keine neuen Patches, Sicherheitsupdates oder Plattform-Zertifizierungen mehr. Untätigkeit ist deshalb mittel- bis langfristig keine tragfähige Strategie, auch wenn die Software technisch weiterläuft. Die drei aktiven Wege unterscheiden sich vor allem darin, wie stark sie das Betriebsmodell verändern und wie viel Investitionsschutz sie bieten.

Welcher Weg der richtige ist, lässt sich nicht pauschal beantworten, sondern ergibt sich aus der individuellen Ausgangslage. Entscheidend ist, die eigene Installation zunächst sauber zu verorten: Auf welcher Version läuft sie, in welchem Support-Modus befindet sie sich, und welche Sicherheits- und Compliance-Anforderungen bestehen an die unterstützten Prozesse. Erst auf dieser Grundlage lassen sich die drei Optionen seriös gegeneinander abwägen. Methodisch unterscheidet sich diese Abwägung wenig von anderen Plattformentscheidungen im Unternehmen, etwa der Auswahl einer neuen ERP-Lösung: Es geht darum, technische Lebensdauer, wirtschaftlichen Aufwand und strategische Ausrichtung in Einklang zu bringen, statt sich von einem einzelnen Stichtag treiben zu lassen. Wer den Support-Fahrplan kennt und die eigene Position darin einordnet, trifft die Migrationsentscheidung aus einer informierten Lage heraus und nicht unter dem Druck einer bereits abgelaufenen Frist.

Alternativen zu Hyperion: das EPM-Marktumfeld neutral eingeordnet

Hyperion ist nicht das EPM, sondern ein EPM. Diese Unterscheidung klingt banal, wird in der Praxis aber regelmäßig verwischt, weil Oracles Suite über Jahre hinweg in vielen Konzernen das pragende System für Konsolidierung und Planung war und der Name stellvertretend für die gesamte Disziplin stand. Wer heute eine Entscheidung trifft – sei es ein Neueinstieg, eine Ablseung oder die Frage, ob die bestehende Hyperion-Landschaft fortgeführt wird –, sollte das Marktumfeld kennen, in dem sich Hyperion bewegt. Dieser Abschnitt ordnet die wichtigsten Anbieter und Kategorien neutral ein. Er bewertet keine Hersteller, nennt keine erfundenen Marktanteile und spricht keine Kaufempfehlung aus. Sein Zweck ist es, das Feld zu strukturieren, damit eine spätere Auswahl entlang nachvollziehbarer Kriterien und nicht entlang von Namen erfolgt.

Vorab zur Begriffsklärung: EPM (Enterprise Performance Management) und CPM (Corporate Performance Management) bezeichnen weitgehend dasselbe Feld – die Software-gestützte Steuerung der finanziellen Leistung eines Unternehmens. Beide Abkürzungen werden synonym verwendet; der eine Begriff ist eher von Oracle, der andere eher von Analystenhäusern geprägt worden. Gemeint ist in beiden Fällen die Klammer aus Planung, Budgetierung, Forecasting, Konzernkonsolidierung und Management-Reporting. Was ein solches System grundsätzlich leistet und worin es sich von einem operativen ERP-System unterscheidet, ist Gegenstand eigener Darstellungen; hier setzen wir dieses Verständnis voraus und konzentrieren uns auf die Anbieterlandschaft.

Drei Grundtypen: woraus eine EPM-Plattform historisch entstanden ist

Die heutigen Anbieter lassen sich am sinnvollsten nicht nach Größe oder Alter ordnen, sondern nach ihrer fachlichen Herkunft. Fast jedes Produkt trägt die DNA des Problems in sich, das es ursprünglich lösen sollte – und diese Herkunft prägt bis heute, worin es stark ist und worin es Nacharbeit verlangt. Drei Grundtypen lassen sich unterscheiden.

Der erste Typ sind die konsolidierungszentrierten Lösungen. Sie sind aus der Anforderung des Konzernabschlusses geboren: mehrere rechtliche Einheiten in unterschiedlichen Währungen zu einer geprüften Konzernsicht zusammenzuführen, inklusive Schuldenkonsolidierung, Zwischengewinneliminierung und Minderheitenausweis. Werkzeuge dieser Schule denken zuerst in Buchungslogik, Prüfpfad und Abschlusssicherheit. Planung ist hier möglich, war aber historisch nicht der Ausgangspunkt. Hyperion gehört mit seinem Konsolidierungsmodul stark in diese Tradition, ebenso Wolters Kluwer CCH Tagetik, das aus dem Umfeld der Finanzkonsolidierung kommt.

Der zweite Typ sind die planungszentrierten Tools. Sie sind aus der gegenläufigen Anforderung entstanden: flexibel, schnell und nutzernah Szenarien zu rechnen – Absatzplanung, Personalplanung, treiberbasierte Modelle, die das Controlling selbst aufbauen und verändern kann, ohne für jede Modelldrehung die IT zu bemühen. Diese Werkzeuge denken zuerst in Modellierungsfreiheit und Geschwindigkeit. Eine prüfsichere Konzernkonsolidierung nach handelsrechtlichen Maßstäben war dagegen oft nicht ihr Ausgangspunkt und ist teilweise nur über Zusatzmodule oder Partnerlösungen abgedeckt. Anaplan und Workday Adaptive Planning stehen exemplarisch für diese Schule.

Der dritte Typ sind die unified-CPM-Plattformen. Sie sind die jüngste Antwort auf ein Problem, das die ersten beiden Typen erzeugt haben: Wer ein Konsolidierungswerkzeug und ein Planungswerkzeug getrennt betreibt, muss zwei Datenmodelle, zwei Stammdatenwelten und eine Schnittstelle dazwischen pflegen. Unified-Plattformen treten mit dem Versprechen an, Konsolidierung, Planung, Abstimmung und Reporting auf einem Datenmodell zu vereinen, sodass dieselbe Zahl nicht zweimal gehalten und abgeglichen werden muss. OneStream ist der bekannteste Vertreter dieses Anspruchs; auch Board wird häufig in diese Kategorie eingeordnet, weil es Planung und Analyse auf einer gemeinsamen Basis führt.

Diese Dreiteilung ist ein Denkraster, keine scharfe Trennlinie. Reife Produkte wandern über die Jahre in die Mitte: Konsolidierungswerkzeuge bauen Planung aus, Planungswerkzeuge ergänzen Konsolidierungsfähigkeiten, und beide nehmen für sich in Anspruch, „unified“ zu sein. Der Wert des Rasters liegt darin, die Herkunft zu erkennen – denn die Herkunft verrät, wo ein Werkzeug von Haus aus stark ist und wo die Funktion erst nachträglich hinzugekommen ist.

Die Anbieter im Überblick – ohne Wertung

Innerhalb dieser Typen lassen sich die häufig genannten Anbieter neutral verorten. Die folgenden Beschreibungen geben die jeweilige Selbst- und Marktpositionierung wieder; sie sind keine Eignungsurteile.

Oracle EPM (vormals Hyperion). Oracle hat die klassische On-Premise-Hyperion-Suite über die Jahre in eine Cloud-Generation überführt, die unter dem Dach Oracle EPM Cloud geführt wird. Die fachliche Linie – starke Konsolidierung, ausgereifte Planung, die mehrdimensionale Datenhaltung im Kern – ist erhalten geblieben. Hyperion bleibt damit ein vollwertiger Weg, ist aber kein in sich abgeschlossener, sondern ein sich weiterentwickelnder Pfad. Den Fahrplan vom On-Premise-Lebensende zur Cloud behandelt ein eigener Abschnitt dieser Seite.

OneStream. Positioniert sich ausdrücklich als unified-CPM-Plattform mit dem Anspruch, mehrere bisher getrennte EPM-Funktionen auf einer Basis zu bündeln. Wird häufig dort betrachtet, wo Unternehmen eine fragmentierte Landschaft aus mehreren Werkzeugen konsolidieren wollen.

Anaplan. Ein planungszentriertes, cloud-natives Werkzeug mit einer eigenen Modellierungsengine, das über die reine Finanzplanung hinaus auch operative Planungsfelder wie Vertrieb und Supply Chain adressiert. Stark in der Modellierungsflexibilität, weniger als Konzernkonsolidierungswerkzeug positioniert.

Workday Adaptive Planning. Ebenfalls planungszentriert und cloud-nativ, mit besonderer Nähe zu Workdays HR- und Finanzwelt. Wird oft dort erwogen, wo Workday bereits als HR- oder Finanzsystem im Einsatz ist.

Wolters Kluwer CCH Tagetik. Aus der Finanzkonsolidierung kommend, mit ausgeprägtem Fokus auf Abschluss, regulatorisches Reporting und die Verbindung von Konsolidierung und Planung. Wird im Umfeld anspruchsvoller Konzernabschluss- und Compliance-Anforderungen genannt.

Board. Eine Plattform, die Planung, Analyse und Reporting auf einer gemeinsamen Basis verbindet und damit zwischen klassischer Business-Intelligence und CPM angesiedelt ist.

SAP – Group Reporting und SAP Analytics Cloud (SAC). SAP adressiert das Feld aus der ERP-Nähe heraus: SAP Group Reporting ist die in die SAP-S/4HANA-Welt eingebettete Konsolidierung, SAP Analytics Cloud übernimmt Planung, Analyse und Reporting. Die Positionierung lebt von der unmittelbaren Nähe zum SAP-Hauptbuch – dort, wo SAP ohnehin das operative Rückgrat bildet.

Auswahlkriterien: woran sich die Eignung wirklich entscheidet

Wer aus dieser Landschaft auswählt, sollte das nicht entlang von Markennamen tun, sondern entlang weniger struktureller Kriterien, die den tatsächlichen Bedarf abbilden. Vier davon tragen in den meisten Fällen die Entscheidung.

Das erste ist die Konsolidierungstiefe. Die entscheidende Frage lautet: Wie komplex ist der Konzernabschluss wirklich? Ein Unternehmen mit wenigen Gesellschaften in einer Währung stellt völlig andere Anforderungen als ein Konzern mit vielen Beteiligungsebenen, Fremdwährungen, Zwischenergebnissen und einem Bedarf an parallelem Abschluss nach mehreren Rechnungslegungsstandards. Je tiefer und regulatorisch anspruchsvoller die Konsolidierung, desto stärker spielen Werkzeuge mit konsolidierungszentrierter Herkunft ihre Reife aus – und desto genauer ist bei planungszentrierten Tools zu prüfen, ob sie diese Tiefe wirklich tragen oder nur dem Namen nach.

Das zweite ist die Planungsflexibilität. Hier geht es um die gegenläufige Frage: Wie häufig und wie tiefgreifend ändern sich die Planungsmodelle, und wie selbstständig soll das Controlling diese Modelle bauen und drehen können? Wo Szenarien wöchentlich neu gerechnet, Treiberbäume ständig umgebaut und Simulationen interaktiv durchgespielt werden, zählt die Modellierungsfreiheit der planungszentrierten Schule. Wo die Planung dagegen einem festen, jährlich wiederkehrenden Rhythmus folgt, ist diese Flexibilität weniger ausschlaggebend.

Das dritte ist die Cloud-Reife. Die Frage ist nicht, ob ein Produkt „Cloud“ auf dem Etikett trägt, sondern wie tief der Cloud-Betrieb tatsächlich reicht: Ist die Lösung von Grund auf cloud-nativ konzipiert, oder handelt es sich um eine in die Cloud verlagerte, ursprünglich On-Premise gedachte Architektur? Beides kann tragfähig sein, hat aber unterschiedliche Konsequenzen für Update-Zyklen, Skalierung und Betriebsaufwand. Für Organisationen, die ohnehin eine Cloud-Strategie verfolgen, ist dieses Kriterium oft das ausschlaggebende.

Das vierte ist die ERP-Nähe. Die EPM-Welt lebt von den Ist-Daten, die aus dem operativen System stammen; je sauberer und stabiler dieser Datenfluss ist, desto weniger Reibung entsteht im Betrieb. Eine bestehende, dominante ERP-Landschaft kann daher die Auswahl mitbestimmen – nicht weil ein anderes Werkzeug technisch unmöglich anzubinden wäre, sondern weil die Nähe zum vorhandenen Hauptbuch Integrationsaufwand spart. Welche Datenobjekte dabei zwischen den Systemen wandern und über welche Mechanismen, ist Gegenstand des Abschnitts zum Zusammenspiel von EPM und ERP auf dieser Seite.

Neben diesen vier Hauptkriterien wirken in der Praxis weitere Faktoren mit: die Verfügbarkeit von Beratungs- und Implementierungspartnern für das jeweilige Produkt, die vorhandenen Kompetenzen im eigenen Haus, die Gesamtbetriebskosten über den Lebenszyklus und nicht zuletzt die strategische Ausrichtung des Herstellers. Eine strukturierte Vorgehensweise, die solche Kriterien gewichtet und gegen den tatsächlichen Bedarf hält, gehört zum Handwerk jeder Systemauswahl – und unterscheidet eine belastbare Entscheidung von einer, die dem lautesten Namen folgt.

Die Einordnung: Hyperion als ein Weg unter mehreren

Aus alledem folgt eine nüchterne Einordnung. Hyperion ist ein ausgereifter, breit eingesetzter und funktional vollwertiger Weg, EPM zu betreiben – mit einer besonderen Stärke in der Konsolidierung und einer langen Erfahrungsbasis in vielen Unternehmen. Es ist aber eben ein Weg und nicht der einzig denkbare. Ob es der richtige ist, lässt sich nicht abstrakt beantworten, sondern nur gegen den konkreten Bedarf: gegen die tatsächliche Konsolidierungstiefe, die geforderte Planungsflexibilität, die angestrebte Cloud-Strategie und die bestehende Systemlandschaft.

Für ein Unternehmen mit gewachsener Hyperion-Historie, anspruchsvoller Konsolidierung und einer Cloud-Roadmap, die mit Oracles Linie zusammenpasst, kann die Fortführung der naheliegende und wirtschaftlich sinnvolle Weg sein. Für ein Haus, das eine fragmentierte Werkzeuglandschaft zusammenführen möchte, rücken unified-Plattformen ins Blickfeld. Wo die Planung im Zentrum steht und schnell veränderlich ist, sind die planungszentrierten Spezialisten ein ernsthafter Kandidat. Und wo eine dominante SAP-Landschaft das operative Rückgrat bildet, liegt die ERP-nahe Variante nahe. Keine dieser Aussagen ist ein Urteil über die Qualität eines Produkts – sie sind Konsequenzen aus dem jeweiligen Bedarf.

Genau hier liegt der Kern einer neutralen Marktbetrachtung: Sie ersetzt die Frage „Welches ist das beste EPM?“ durch die tragfähigere Frage „Welches passt zu unserem Bedarf?“. Die erste Frage hat keine allgemeingültige Antwort; die zweite ist beantwortbar, sobald die eigenen Anforderungen sauber erhoben sind. Wer diese Disziplin auf die EPM-Auswahl genauso anwendet wie auf die Wahl einer operativen ERP-Lösung, trifft eine Entscheidung, die sich später begründen lässt – unabhängig davon, ob sie am Ende auf Hyperion, auf einen seiner Wettbewerber oder auf eine bewusste Kombination mehrerer Werkzeuge hinausläuft.

Häufige Fragen