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 Beruehrung kommt, unterschaetzt haeufig, dass sich hinter dem Namen kein einzelnes Programm verbirgt, sondern eine zusammengesetzte Produktlandschaft. Hyperion ist eine modulare Suite fuer das Enterprise Performance Management (EPM) – ein Verbund eigenstaendiger Anwendungen, die jeweils einen klar umrissenen Zweck erfuellen, sich aber ueber gemeinsame technische Fundamente miteinander verzahnen. Genau diese Modularitaet ist der Grund, warum zwei Unternehmen, die beide „Hyperion einsetzen“, voellig unterschiedliche Systeme betreiben koennen: 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 ausdruecklich 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 verlaeuft – eine Unterscheidung, die auch bei jeder spaeteren ERP-Auswahl oder Systemkonsolidierung eine Rolle spielt.

Hyperion Financial Management (HFM): die Konsolidierungs-Engine

Hyperion Financial Management, kurz HFM, ist das Modul fuer die gesetzliche und Management-Konsolidierung. Seine Kernaufgabe besteht darin, die Einzelabschluesse vieler rechtlicher Einheiten eines Konzerns zu einem konsolidierten Konzernabschluss zusammenzufuehren. Dabei uebernimmt HFM die Schritte, die einen Konzernabschluss von einer simplen Summierung unterscheiden: die Eliminierung konzerninterner Geschaeftsvorfaelle (Intercompany-Abstimmung), die Behandlung von Beteiligungen und Minderheitenanteilen, die Waehrungsumrechnung von Fremdwaehrungsabschluessen sowie die Verbuchung von Konsolidierungsanpassungen und Journalbuchungen auf Konzernebene.

HFM denkt in Dimensionen. Jeder Wert haengt nicht nur an einem Konto, sondern zugleich an einer Einheit (Entity), einer Periode, einem Szenario (etwa Ist, Plan oder Forecast), einer Waehrung 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 muessen. HFM fuehrt darueber hinaus einen revisionssicheren Nachweis darueber, wie sich ein konsolidierter Wert zusammensetzt – vom gemeldeten Einzelwert ueber die Umrechnung bis zur Eliminierung. Diese Nachvollziehbarkeit ist der Grund, warum HFM in vielen Konzernen ueber Jahre das Rueckgrat 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. Fuer sie ist HFM weniger ein Eingabewerkzeug als ein Regelsystem: Sie definieren die Konsolidierungsregeln, ueberwachen die Datenanlieferung der Tochtergesellschaften und gegeben das konsolidierte Ergebnis frei. Wie der eigentliche Periodenabschluss von der Datenmeldung bis zum freigegebenen Konzernreporting ablaeuft, ist ein eigenes Thema, das an anderer Stelle dieser Seite ausfuehrlich behandelt wird.

Hyperion Planning: Budgetierung, Forecast und operative Steuerung

Waehrend HFM rueckwaerts 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 unterjaehrigen Hochrechnungen und die mittelfristigen Plaene, mit denen ein Unternehmen seine finanzielle und operative Zukunft modelliert. Planning stellt dafuer Eingabemasken, Workflow- und Genehmigungsprozesse sowie Plan-Logiken bereit: Wer plant welchen Bereich, in welcher Reihenfolge werden Planversionen genehmigt, und wie greifen Teilplaene – etwa Personal-, Absatz- und Investitionsplanung – zu einem konsistenten Gesamtbild ineinander.

Charakteristisch fuer 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. Aendert sich eine Annahme, rechnen sich die abhaengigen Groessen automatisch neu. Diese Rechenlogik ist kein Zufallsprodukt von Planning selbst, sondern wird von der darunterliegenden Berechnungs-Engine erbracht – ein Punkt, auf den der naechste Abschnitt zu Essbase eingeht, denn er erklaert 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 eingaengigen Eingabeoberflaeche, klaren Verantwortlichkeiten und einem nachvollziehbaren Freigabeprozess. Die Anforderung an ein gutes Planungssystem aehnelt damit jener an eine zugaengliche ERP-Loesung: Die fachliche Logik muss korrekt sein, ohne dass jeder Anwender die technische Mechanik dahinter durchdringen muss.

Essbase: die OLAP-Engine unter der Oberflaeche

Essbase – der Name steht fuer Extended Spread Sheet Database – ist das technische Herzstueck, das viele Anwender nie unmittelbar zu Gesicht bekommen. Es handelt sich um eine multidimensionale OLAP-Datenbank (Online Analytical Processing), die fuer analytische Auswertungen und schnelle Aggregationen ueber 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 Wuerfel (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 Laendern“ sind in der Wuerfelstruktur angelegt, sodass Summen entlang dieser Hierarchien sehr schnell verfuegbar sind. Komplexere Rechenvorschriften – Allokationen, Verteilungen, abgeleitete Kennzahlen – werden ueber Rechenskripte (Calc Scripts) und Geschaeftsregeln definiert. Essbase tritt klassisch in zwei Auspraegungen auf: als blockbasierte (Block Storage, BSO) Variante, die fuer schreibintensive Anwendungen mit Dateneingabe und komplexen Berechnungen gedacht ist, und als aggregationsbasierte (Aggregate Storage, ASO) Variante, die auf grosse, eher lesende Reporting-Wuerfel mit vielen Dimensionen zugeschnitten ist.

Die wichtigste architektonische Aussage dieses Abschnitts lautet: Essbase ist die Engine unter Hyperion Planning. Wenn ein Planungsanwender eine Annahme aendert und die abgeleiteten Werte sich neu berechnen, dann geschieht diese Berechnung in einem Essbase-Wuerfel, der die Planning-Anwendung mit Rechenleistung und Speicherstruktur versorgt. Planning liefert die fachliche Anwendung – Eingabeformulare, Workflows, Versionierung –, waehrend Essbase darunter die multidimensionale Datenhaltung und die eigentliche Rechenarbeit uebernimmt. Wer die Performance einer Planungsanwendung verbessern will, optimiert daher in aller Regel nicht die Oberflaeche, sondern die Wuerfeldimensionierung und die Rechenskripte auf der Essbase-Ebene. Essbase laesst sich daneben auch eigenstaendig als analytische Datenbank fuer Ad-hoc-Analysen betreiben, doch sein groesster 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 gefuettert wird. Genau an dieser Stelle setzt FDMEE an – Financial Data Quality Management, Enterprise Edition. Das Modul ist die Datenintegrations- und Datenqualitaetsschicht 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 Uebernahme 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 uebersetzt 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 Rueckverweis (Drill-Back) von einer aggregierten Zahl in der EPM-Anwendung bis hinunter zum Quellbeleg im Vorsystem. Validierungsregeln stellen sicher, dass nur vollstaendige und abgestimmte Daten in die Anwendungen gelangen.

Die Nutzergruppe von FDMEE ist eher technisch-administrativ gepraegt: Datenverantwortliche, EPM-Administratoren und Schnittstellenbetreuer richten die Importprozesse, Mappings und Validierungen ein und ueberwachen die periodischen Datenlaeufe. Fuer 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 genuegt 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 Beduerfnisse. Smart View ist ein Add-in fuer Microsoft Office, allen voran fuer 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 zurueck in die Anwendung zu schreiben. Smart View ist damit das Werkzeug der Wahl fuer 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-Berichtsbuecher mit festem Layout. Wo Smart View die freie Exploration ermoeglicht, liefert Financial Reporting das pixelgenaue, druckbare Ergebnis, das Periode fuer Periode in gleicher Form benoetigt wird. Beide Frontends greifen lesend auf dieselben Anwendungsmodule und letztlich auf dieselben Essbase-Wuerfel 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 laesst sich als Stapel lesen, wie ihn die Grafik oben zeigt: Ganz unten sorgt FDMEE dafuer, dass abgestimmte Daten aus den Vorsystemen ueberhaupt verfuegbar sind. Darueber liegt Essbase als Berechnungs- und Speicher-Engine. Auf dieser Engine setzen die Anwendungsmodule auf – HFM fuer die Konsolidierung, Planning fuer die Budgetierung, ergaenzt um spezialisierte Module wie die Profitabilitaets- und Kostenrechnung. Ganz oben schliesslich greifen die Frontends Smart View und Financial Reporting auf diese Anwendungen zu und machen die Zahlen fuer den Menschen sicht- und bearbeitbar.

Dieses Schichtenprinzip erklaert auch, warum die Aussage „wir nutzen Hyperion“ so wenig praezise ist: Ein Unternehmen kann allein FDMEE und Essbase fuer analytische Zwecke betreiben, ein anderes setzt HFM auf, ein drittes kombiniert Planning und HFM zu einem geschlossenen Plan-Ist-Vergleich. Die Module sind eigenstaendig 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 fuer oder gegen einzelne Bausteine zu einer eigenstaendigen, begruendungspflichtigen Architekturfrage.

Damit ist der funktionale und architektonische Rahmen der klassischen Hyperion-Suite abgesteckt. Welche Konsequenzen sich daraus fuer den eigentlichen Abschlussprozess, fuer das Zusammenspiel mit dem ERP-System, fuer die Support-Perspektive der On-Premise-Welt und fuer moegliche 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 ausschliesslich diese Nahtstelle: Welche Datenobjekte ueberqueren die Grenze, in welche Richtung, ueber 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 geklaert; hier geht es um die Mechanik des Datenaustauschs.

Wichtig ist von Anfang an die Einsicht, dass dieser Austausch keine Einbahnstrasse ist. Der Datenfluss ist bidirektional: Aus dem ERP-System stroemen Ist-Daten in Richtung Hyperion – Hauptbuch-Salden, Kostenrechnungsdaten, Stammdaten. Aus Hyperion stroemen abgeleitete Ergebnisse zurueck – freigegebene Planwerte, Forecasts, mitunter konsolidierte Konzernzahlen, die in nachgelagerten Berichten wieder benoetigt werden. Beide Richtungen folgen unterschiedlichen Regeln, haben unterschiedliche Empfaenger und stellen unterschiedliche Anforderungen an Frequenz und Qualitaetssicherung. Wer nur den Hinweg „Ist aus ERP“ im Blick hat, uebersieht die Haelfte der Integrationsarbeit.

Der Hinweg: Ist-Daten aus dem ERP nach Hyperion

Der mengenmaessig groesste und regelmaessigste Datenstrom verlaeuft 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-Auszuege, 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 duerfen nur Salden uebernommen werden, die im Quellsystem als final markiert oder zumindest abstimmungsbereit sind, sonst entsteht in Hyperion ein Bild, das sich nach der naechsten Nachbuchung im ERP wieder verschiebt.

Zweitens die Daten aus der Kostenrechnung. Kostenstellen, Kostenarten, innerbetriebliche Leistungsverrechnungen und gegebenenfalls Ergebnisrechnungs-Sichten liefern die feinere Granularitaet, die das Controlling fuer eine treiberbasierte Planung und fuer aussagekraeftige Abweichungsanalysen benoetigt. Waehrend das Hauptbuch die bilanzielle Wahrheit liefert, liefert die Kostenrechnung die Steuerungssicht. Beide muessen in Hyperion zusammengefuehrt werden, ohne dass es zu Doppelzaehlungen kommt – ein klassischer Stolperstein, wenn dieselbe Information sowohl ueber die Hauptbuch- als auch ueber 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 Bruecke

Die technische Bruecke 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 Qualitaetssicherung in den Prozess einbaut.

1. Import: Die Quelldaten werden aus dem ERP gezogen – entweder ueber eine direkte Adapter-Verbindung in das Hauptbuch oder ueber eine bereitgestellte Datei. Das Ergebnis liegt zunaechst unveraendert in einer Zwischenstruktur (Staging).
2. Validierung und Mapping: Die Quellstrukturen werden auf die Zieldimensionen abgebildet, und FDMEE prueft, ob jeder Quellwert eine gueltige 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: Abschliessende Pruefregeln stellen sicher, dass die geladenen Summen mit erwarteten Kontrollwerten uebereinstimmen, bevor die Daten freigegeben werden.

Der entscheidende Mehrwert dieser Bruecke ist die Nachvollziehbarkeit. FDMEE protokolliert lueckenlos, woher ein Wert stammt, und erlaubt einen Rueckverweis (Drill-Through beziehungsweise Drill-Back) von einer aggregierten Konzernzahl bis zurueck in den Quellsaldo des ERP-Systems. Wenn im Konzernreporting eine Position auffaellt, kann der Verantwortliche sie ohne Medienbruch bis zur Herkunft verfolgen. Diese Prueffaehigkeit ist es, die einen kontrollierten Datentransfer von einem blossen Datei-Export unterscheidet – und sie ist der Grund, warum manuelle Excel-Zwischenschritte in einem ernst gemeinten EPM-Betrieb so weit wie moeglich zurueckgedraengt werden.

Mapping: vom Kontenrahmen auf die EPM-Dimensionen

Das Herzstueck der Integration ist das Mapping – die Uebersetzung der ERP-Strukturen in die mehrdimensionale Sprache von Hyperion. Der Grund, warum dieser Schritt unverzichtbar ist, liegt in einer fundamentalen Strukturdifferenz: Ein ERP-System fuehrt seine Werte typischerweise flach an einem Konto und einem Buchungskreis, eine EPM-Anwendung dagegen haengt jeden Wert an mehrere Dimensionen zugleich – Konto, Einheit, Periode, Szenario, Waehrung und weitere. Eine einzelne ERP-Buchungszeile muss also in einen Punkt im mehrdimensionalen Raum von Hyperion uebersetzt werden, und diese Uebersetzung 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 groebere, steuerungsorientierte Kontenhierarchie verdichtet. Mehrere Quellkonten fallen also auf ein Zielkonto zusammen (Many-to-one), oder ein Quellwert wird abhaengig von einem zweiten Merkmal auf unterschiedliche Ziele verteilt. FDMEE kennt dafuer abgestufte Mapping-Typen – von der expliziten Eins-zu-eins-Regel ueber Bereichs- und Wildcard-Regeln bis zu mehrstufigen, an Bedingungen geknuepften Zuordnungen.

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

Frequenz: Batch-Abschlusslogik statt Echtzeit

Eine haeufige Fehlannahme bei der Integration lautet, EPM-Systeme muessten moeglichst nahe an der Echtzeit mit dem ERP gekoppelt sein. Das Gegenteil ist meist richtig – und zwar aus fachlichen, nicht aus technischen Gruenden. 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, waere ein kontinuierlicher Datenstrom nach Hyperion sogar schaedlich: Konsolidierte Zahlen wuerden sich staendig veraendern, Abstimmungen liefen ins Leere, und die fuer den Abschluss noetige Stabilitaet ginge verloren. Deshalb arbeitet der klassische Datentransfer batchorientiert: Die Salden werden geladen, wenn die Periode im Quellsystem abstimmungsbereit ist.

Davon abzugrenzen sind zwei Sonderfaelle. Erstens die haeufigere Aktualisierung waehrend der Planung – etwa woechentliche oder taegliche Ist-Aktualisierungen, damit ein rollierender Forecast nicht auf veralteten Ist-Werten aufsetzt. Das ist haeufigeres Batch, nicht Echtzeit. Zweitens der gezielte Drill-Through: Hier wird nicht permanent synchronisiert, sondern erst auf Anfrage eine Live-Verbindung zum Quellsystem geoeffnet, um einen einzelnen Wert bis zum Beleg zu verfolgen. Das fuehlt sich nach Echtzeit an, ist aber ein punktueller Nachschlag, kein Dauerstrom. Die Konsequenz fuer 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 Rueckweg: Plan- und Konsolidierungsdaten zurueck in die Systemwelt

Die weniger beachtete, aber ebenso wichtige Richtung ist der Rueckfluss. Sobald ein Planungszyklus abgeschlossen und ein Budget freigegeben ist, liegt der verbindliche Plan in Hyperion Planning. Dieser Plan wird in vielen Organisationen wieder zurueck 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 Rueckweg haeufig ueber einen Datei-Export aus Hyperion und einen Ladejob auf der ERP-Seite, seltener ueber 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 Rueckweg stellt eine eigene Governance-Frage, denn nun verlaesst eine in Hyperion erzeugte und verantwortete Zahl die EPM-Welt und wird in einem anderen System zur Grundlage von Entscheidungen. Die Zuordnungsregeln muessen deshalb auch rueckwaerts konsistent sein: Eine in der EPM-Dimension verdichtete Plangroesse muss wieder so auf die ERP-Struktur aufgeloest werden, dass sie dort sinnvoll verglichen werden kann.

Stammdaten-Governance ueber beide Welten

Damit ist der kritischste Punkt der gesamten Integration erreicht. Bewegungsdaten – Salden, Ist-Werte, Plaene – 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 ueberein, 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 dafuer, dass Integration ueberhaupt verlaesslich funktioniert.

Das Kernproblem ist die Drift: Im ERP werden laufend neue Konten angelegt, Kostenstellen umstrukturiert, Gesellschaften gegruendet oder verschmolzen. Geschieht dies, ohne dass die EPM-Seite und ihre Mappings nachgezogen werden, entstehen verwaiste Quellwerte ohne gueltiges Ziel. In einem gut gefuehrten FDMEE-Setup fallen solche Faelle bei der Validierung als Fehler auf – das ist gewuenscht, 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 ueber beide Welten ruht auf wenigen Grundsaetzen:

• Eine fuehrende Quelle je Stammdatenobjekt. Es muss eindeutig festgelegt sein, welches System fuer Konten, Kostenstellen und Einheiten den verbindlichen Stand haelt – in aller Regel das ERP-System. Hyperion folgt, statt eigene, abweichende Strukturen zu pflegen.
• Ein definierter Aenderungsprozess. Jede strukturelle Aenderung im ERP loest eine nachgelagerte Pflege auf der EPM-Seite aus, bevor der naechste Bewegungsdaten-Load laeuft – nicht erst, wenn etwas auffaellt.
• Versionierte, dokumentierte Mappings. Zuordnungsregeln werden nicht stillschweigend ueberschrieben, sondern nachvollziehbar gepflegt, damit ein Wert auch rueckwirkend erklaerbar bleibt.
• Regelmaessige 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 Verstaendnis davon haben, was auf einem Konto liegt – etwa weil im ERP eine Position brutto, in Hyperion aber netto gefuehrt wird –, dann produziert die Integration formal fehlerfreie, inhaltlich aber falsche Zahlen. Solche Differenzen sind besonders tueckisch, weil kein technischer Validierungslauf sie aufdeckt: Der Load laeuft sauber durch, die Summen stimmen, und trotzdem bedeutet derselbe Kontoname auf beiden Seiten etwas anderes. Erst eine bewusst abgestimmte fachliche Definition – ein gemeinsames Datenglossar fuer Konten und Kennzahlen – verhindert diese Klasse von Fehlern. Wer eine spaetere Systemkonsolidierung oder Migration plant, profitiert hier doppelt: Eine im Rahmen einer sauberen ERP-Loesung 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 Rueckgrat. FDMEE beziehungsweise Data Management liefert dafuer das Werkzeug – Import, Mapping, Validierung, Drill-Back –, doch die eigentliche Leistung ist organisatorisch: die Verstaendigung darauf, welches System welche Wahrheit haelt und wie Aenderungen koordiniert werden. Wer diese Nahtstelle beherrscht, hat die Voraussetzung dafuer geschaffen, dass der Periodenabschluss und das Konzernreporting reibungslos laufen koennen – ein Prozess, der an anderer Stelle dieser Seite im Detail betrachtet wird.

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

Kaum eine Frage beschaeftigt 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 fuer Betrieb, Sicherheit und Investitionsplanung haben. Wer heute eine Hyperion-Umgebung betreibt, muss wissen, in welchem Support-Modus sie laeuft, 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 ueber kuenftige Roadmaps zu spekulieren.

Es geht hier ausdruecklich nicht um die fachlichen Faehigkeiten 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 unterstuetzt, was bedeuten die verschiedenen Support-Stufen konkret, und welche strategischen Wege stehen einem Unternehmen offen, dessen Plattform sich dem Lebensende naehert oder es bereits erreicht hat.

Der Wendepunkt Ende 2021: Release 11.1.2.4 verliert den Premier Support

Die ueber 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 fuer diese Generation hat Oracle einen klaren Schlussstrich gezogen: Mit dem Ablauf des Dezembers 2021 endete der reguläre Premier Support fuer die zentralen 11.1.2.x-Produkte. Ab Januar 2022 sind die betroffenen Installationen in den sogenannten Sustaining Support uebergegangen.

Dieser Stichtag ist mehr als ein formaler Verwaltungsakt. Er markiert den Zeitpunkt, ab dem fuer 11.1.2.4 keine neuen Patches, keine neuen Sicherheitsaktualisierungen und keine neuen zertifizierten Plattformkombinationen mehr bereitgestellt werden. Eine Installation, die nach diesem Datum unveraendert weiterlaeuft, ist technisch funktionsfaehig, erhaelt aber von Oracle keine laufende Pflege mehr im Sinne fortlaufender Fehlerbehebung. Fuer 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 uebersehenen 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 Unterstuetzung bei Stoerungen, die Bereitstellung neuer Fehlerbehebungen (Patches und Patch Sets), Sicherheitsaktualisierungen sowie Zertifizierungen fuer neue Betriebssystem-, Datenbank- und Browser-Versionen. Eine Plattform im Premier Support bleibt damit lauffaehig auf einer sich weiterentwickelnden Infrastruktur und erhaelt im Stoerungsfall den vollen Service-Umfang.

Sustaining Support ist demgegenueber die niedrigste Stufe. Sie laeuft zwar zeitlich unbefristet weiter, schliesst aber wesentliche Leistungen aus: keine neuen Patches oder Fehlerbehebungen, keine neuen Sicherheitsupdates, keine neuen Zertifizierungen fuer aktuelle Betriebssysteme oder Datenbankversionen. Bereits frueher veroeffentlichte Korrekturen bleiben zugaenglich, doch alles, was erst nach dem Eintritt in den Sustaining Support entstehen wuerde, wird fuer diese Version nicht mehr erstellt. Praktisch heisst das: Wer die Umgebung modernisieren, das Betriebssystem aktualisieren oder eine neuere Datenbank einsetzen will, bewegt sich ausserhalb 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 regelmaessiger grosser Versionsspruenge, die jeweils ein vollstaendiges Upgrade-Projekt erfordern, wird die Plattform innerhalb der 11.2-Linie durch fortlaufende Aktualisierungen weiterentwickelt. Updates und technologische Verbesserungen fliessen kontinuierlich ein, ohne dass Kunden einen erneuten Major-Upgrade-Aufwand stemmen muessen. Oracle hat 11.2 dabei als die On-Premise-Generation positioniert, die ueber 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 Einschraenkung verbunden, die man kennen sollte. Oracle gewaehrt diese verlaengerte Premier-Support-Perspektive im Rahmen seines Continuous-Innovation- beziehungsweise Applications-Unlimited-Ansatzes und ueberprueft die Fortfuehrung in jaehrlichen Reviews. Das Datum 2032 ist damit eine kommunizierte Perspektive auf Basis der bisherigen Politik, kein vertraglich fixierter Endpunkt, der unabhaengig von kuenftigen Entscheidungen feststeht. Wir geben diese Jahreszahl hier so wieder, wie Oracle sie kommuniziert hat, und vermeiden bewusst jede Aussage darueber, wie sich die Roadmap nach diesem Zeitpunkt entwickeln koennte.

Fuer 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 zurueck in den Premier Support und gewinnt damit wieder Zugang zu laufenden Patches, Sicherheitsupdates und Zertifizierungen fuer aktuelle Infrastruktur. Der Wechsel innerhalb der On-Premise-Welt ist damit kein blosses kosmetisches Update, sondern die Rueckkehr in einen vollwertig gepflegten Betriebszustand.

Die Entscheidungslage fuer Bestandskunden

Aus dem dargestellten Fahrplan ergeben sich fuer Unternehmen, die heute eine Hyperion-Umgebung betreiben, im Kern drei strategische Stossrichtungen. Welche davon die richtige ist, haengt von der Ausgangslage, der bestehenden Lizenzierung, den internen Kompetenzen und der grundsaetzlichen IT-Strategie ab. Eine sorgfaeltige Abwaegung gehoert 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

Fuer 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 koennen weitgehend uebernommen werden, und die Organisation muss sich nicht auf eine voellig neue Bedienlogik einstellen. Wer in den vergangenen Jahren erheblich in Regelwerke, Reportstrukturen und Schnittstellen investiert hat, schuetzt 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 blosses Patch, sondern um eine Neuinstallation der 11.2-Umgebung mit anschliessender Migration der Anwendungsinhalte. Betriebssysteme, Datenbanken und Middleware muessen auf zertifizierte Stände gebracht werden. Diese Arbeit will geplant und getestet sein, lohnt sich aber, weil sie die Plattform fuer einen langen Zeitraum wieder in den vollwertigen Premier Support stellt. Unternehmen, die ihre Anwendungslandschaft ohnehin im eigenen Haus betreiben und ueber das noetige Betriebs-Know-how verfuegen, finden hier den Weg mit der hoechsten Kontinuitaet.

Option 2: In die Oracle EPM Cloud wechseln

Die zweite Stossrichtung ist der Uebergang in die Oracle EPM Cloud, das ueber 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 Grossteil des technischen Betriebs uebernimmt. Der Reiz liegt darin, dass die Frage nach Support-Stichtagen und Plattform-Zertifizierungen in dieser Form entfaellt, 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 uebernommen, 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 eroeffnet die Moeglichkeit, ueber die Jahre gewachsene Altlasten zu bereinigen und Prozesse neu zu ordnen, verlangt dafuer aber ein eigenstaendiges Migrations- und Einfuehrungsprojekt. Die methodische Herangehensweise aehnelt einer klassischen ERP-Implementierung mit Konzeptionsphase, Aufbau, Test und Schulung. Fuer Organisationen, die ihren Rechenzentrumsbetrieb verschlanken und sich von Infrastrukturpflege loesen wollen, ist dieser Weg strategisch attraktiv.

Option 3: Drittanbieter-Support und Marktalternativen pruefen

Eine dritte Moeglichkeit besteht darin, die Plattform vorerst auf dem bestehenden Stand zu belassen und die Pflege ueber Drittanbieter abzusichern. Spezialisierte Dienstleister bieten unabhaengigen Support fuer Hyperion-Installationen an, die im Sustaining Support stehen, und koennen Betrieb und Fehlerbehebung uebernehmen, solange die Umgebung fachlich gut genug ist und kein zwingender Modernisierungsdruck besteht. Dieser Weg verschafft Zeit, etwa um eine groessere strategische Entscheidung sorgfaeltig vorzubereiten, statt sie unter Termindruck zu treffen.

Er hat aber Grenzen. Drittanbieter koennen keine neuen Oracle-Patches oder Sicherheitsupdates erzeugen, die es nicht gibt, und das grundsaetzliche Problem fehlender Plattform-Zertifizierungen fuer aktuelle Betriebssysteme und Datenbanken bleibt bestehen. Drittanbieter-Support ist damit sinnvoll als Ueberbrueckung oder bewusste Auslaufstrategie, nicht als dauerhafte Zukunftsperspektive. In dieselbe Pruefkategorie gehoert die Frage, ob ein vollstaendiger Wechsel auf ein anderes EPM-Produkt sinnvoll ist; diese Marktbetrachtung wird im neutralen Alternativen-Abschnitt dieser Seite vertieft. Wer eine grundlegende Neuausrichtung erwaegt, 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 hinauslaeuft

Die nuechterne Zusammenfassung lautet: Eine 11.1.2.4-Installation ist seit Anfang 2022 im Sustaining Support und erhaelt von Oracle keine neuen Patches, Sicherheitsupdates oder Plattform-Zertifizierungen mehr. Untaetigkeit ist deshalb mittel- bis langfristig keine tragfaehige Strategie, auch wenn die Software technisch weiterlaeuft. Die drei aktiven Wege unterscheiden sich vor allem darin, wie stark sie das Betriebsmodell veraendern und wie viel Investitionsschutz sie bieten.

Welcher Weg der richtige ist, laesst sich nicht pauschal beantworten, sondern ergibt sich aus der individuellen Ausgangslage. Entscheidend ist, die eigene Installation zunaechst sauber zu verorten: Auf welcher Version laeuft sie, in welchem Support-Modus befindet sie sich, und welche Sicherheits- und Compliance-Anforderungen bestehen an die unterstuetzten Prozesse. Erst auf dieser Grundlage lassen sich die drei Optionen seriös gegeneinander abwaegen. Methodisch unterscheidet sich diese Abwaegung wenig von anderen Plattformentscheidungen im Unternehmen, etwa der Auswahl einer neuen ERP-Loesung: 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 regelmaessig verwischt, weil Oracles Suite ueber Jahre hinweg in vielen Konzernen das pragende System fuer Konsolidierung und Planung war und der Name stellvertretend fuer die gesamte Disziplin stand. Wer heute eine Entscheidung trifft – sei es ein Neueinstieg, eine Ablseung oder die Frage, ob die bestehende Hyperion-Landschaft fortgefuehrt 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 spaetere Auswahl entlang nachvollziehbarer Kriterien und nicht entlang von Namen erfolgt.

Vorab zur Begriffsklaerung: EPM (Enterprise Performance Management) und CPM (Corporate Performance Management) bezeichnen weitgehend dasselbe Feld – die Software-gestuetzte Steuerung der finanziellen Leistung eines Unternehmens. Beide Abkuerzungen werden synonym verwendet; der eine Begriff ist eher von Oracle, der andere eher von Analystenhaeusern gepraegt worden. Gemeint ist in beiden Faellen die Klammer aus Planung, Budgetierung, Forecasting, Konzernkonsolidierung und Management-Reporting. Was ein solches System grundsaetzlich leistet und worin es sich von einem operativen ERP-System unterscheidet, ist Gegenstand eigener Darstellungen; hier setzen wir dieses Verstaendnis 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 Groesse oder Alter ordnen, sondern nach ihrer fachlichen Herkunft. Fast jedes Produkt traegt die DNA des Problems in sich, das es urspruenglich loesen sollte – und diese Herkunft praegt bis heute, worin es stark ist und worin es Nacharbeit verlangt. Drei Grundtypen lassen sich unterscheiden.

Der erste Typ sind die konsolidierungszentrierten Loesungen. Sie sind aus der Anforderung des Konzernabschlusses geboren: mehrere rechtliche Einheiten in unterschiedlichen Waehrungen zu einer geprueften Konzernsicht zusammenzufuehren, inklusive Schuldenkonsolidierung, Zwischengewinneliminierung und Minderheitenausweis. Werkzeuge dieser Schule denken zuerst in Buchungslogik, Pruefpfad und Abschlusssicherheit. Planung ist hier moeglich, war aber historisch nicht der Ausgangspunkt. Hyperion gehoert 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 gegenlaeufigen Anforderung entstanden: flexibel, schnell und nutzernah Szenarien zu rechnen – Absatzplanung, Personalplanung, treiberbasierte Modelle, die das Controlling selbst aufbauen und veraendern kann, ohne fuer jede Modelldrehung die IT zu bemuehen. Diese Werkzeuge denken zuerst in Modellierungsfreiheit und Geschwindigkeit. Eine pruefsichere Konzernkonsolidierung nach handelsrechtlichen Massstaeben war dagegen oft nicht ihr Ausgangspunkt und ist teilweise nur ueber Zusatzmodule oder Partnerloesungen abgedeckt. Anaplan und Workday Adaptive Planning stehen exemplarisch fuer diese Schule.

Der dritte Typ sind die unified-CPM-Plattformen. Sie sind die juengste 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 haeufig in diese Kategorie eingeordnet, weil es Planung und Analyse auf einer gemeinsamen Basis fuehrt.

Diese Dreiteilung ist ein Denkraster, keine scharfe Trennlinie. Reife Produkte wandern ueber die Jahre in die Mitte: Konsolidierungswerkzeuge bauen Planung aus, Planungswerkzeuge ergaenzen Konsolidierungsfaehigkeiten, und beide nehmen fuer sich in Anspruch, „unified“ zu sein. Der Wert des Rasters liegt darin, die Herkunft zu erkennen – denn die Herkunft verraet, wo ein Werkzeug von Haus aus stark ist und wo die Funktion erst nachtraeglich hinzugekommen ist.

Die Anbieter im Ueberblick – ohne Wertung

Innerhalb dieser Typen lassen sich die haeufig 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 ueber die Jahre in eine Cloud-Generation ueberfuehrt, die unter dem Dach Oracle EPM Cloud gefuehrt 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 ausdruecklich als unified-CPM-Plattform mit dem Anspruch, mehrere bisher getrennte EPM-Funktionen auf einer Basis zu buendeln. Wird haeufig dort betrachtet, wo Unternehmen eine fragmentierte Landschaft aus mehreren Werkzeugen konsolidieren wollen.

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

Workday Adaptive Planning. Ebenfalls planungszentriert und cloud-nativ, mit besonderer Naehe 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 ausgepraegtem 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-Naehe heraus: SAP Group Reporting ist die in die SAP-S/4HANA-Welt eingebettete Konsolidierung, SAP Analytics Cloud uebernimmt Planung, Analyse und Reporting. Die Positionierung lebt von der unmittelbaren Naehe zum SAP-Hauptbuch – dort, wo SAP ohnehin das operative Rueckgrat bildet.

Auswahlkriterien: woran sich die Eignung wirklich entscheidet

Wer aus dieser Landschaft auswaehlt, sollte das nicht entlang von Markennamen tun, sondern entlang weniger struktureller Kriterien, die den tatsaechlichen Bedarf abbilden. Vier davon tragen in den meisten Faellen die Entscheidung.

Das erste ist die Konsolidierungstiefe. Die entscheidende Frage lautet: Wie komplex ist der Konzernabschluss wirklich? Ein Unternehmen mit wenigen Gesellschaften in einer Waehrung stellt voellig andere Anforderungen als ein Konzern mit vielen Beteiligungsebenen, Fremdwaehrungen, Zwischenergebnissen und einem Bedarf an parallelem Abschluss nach mehreren Rechnungslegungsstandards. Je tiefer und regulatorisch anspruchsvoller die Konsolidierung, desto staerker spielen Werkzeuge mit konsolidierungszentrierter Herkunft ihre Reife aus – und desto genauer ist bei planungszentrierten Tools zu pruefen, ob sie diese Tiefe wirklich tragen oder nur dem Namen nach.

Das zweite ist die Planungsflexibilitaet. Hier geht es um die gegenlaeufige Frage: Wie haeufig und wie tiefgreifend aendern sich die Planungsmodelle, und wie selbststaendig soll das Controlling diese Modelle bauen und drehen koennen? Wo Szenarien woechentlich neu gerechnet, Treiberbaeume staendig umgebaut und Simulationen interaktiv durchgespielt werden, zaehlt die Modellierungsfreiheit der planungszentrierten Schule. Wo die Planung dagegen einem festen, jaehrlich wiederkehrenden Rhythmus folgt, ist diese Flexibilitaet weniger ausschlaggebend.

Das dritte ist die Cloud-Reife. Die Frage ist nicht, ob ein Produkt „Cloud“ auf dem Etikett traegt, sondern wie tief der Cloud-Betrieb tatsaechlich reicht: Ist die Loesung von Grund auf cloud-nativ konzipiert, oder handelt es sich um eine in die Cloud verlagerte, urspruenglich On-Premise gedachte Architektur? Beides kann tragfaehig sein, hat aber unterschiedliche Konsequenzen fuer Update-Zyklen, Skalierung und Betriebsaufwand. Fuer Organisationen, die ohnehin eine Cloud-Strategie verfolgen, ist dieses Kriterium oft das ausschlaggebende.

Das vierte ist die ERP-Naehe. 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 unmoeglich anzubinden waere, sondern weil die Naehe zum vorhandenen Hauptbuch Integrationsaufwand spart. Welche Datenobjekte dabei zwischen den Systemen wandern und ueber 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 Verfuegbarkeit von Beratungs- und Implementierungspartnern fuer das jeweilige Produkt, die vorhandenen Kompetenzen im eigenen Haus, die Gesamtbetriebskosten ueber den Lebenszyklus und nicht zuletzt die strategische Ausrichtung des Herstellers. Eine strukturierte Vorgehensweise, die solche Kriterien gewichtet und gegen den tatsaechlichen Bedarf haelt, gehoert 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 nuechterne Einordnung. Hyperion ist ein ausgereifter, breit eingesetzter und funktional vollwertiger Weg, EPM zu betreiben – mit einer besonderen Staerke 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, laesst sich nicht abstrakt beantworten, sondern nur gegen den konkreten Bedarf: gegen die tatsaechliche Konsolidierungstiefe, die geforderte Planungsflexibilitaet, die angestrebte Cloud-Strategie und die bestehende Systemlandschaft.

Fuer ein Unternehmen mit gewachsener Hyperion-Historie, anspruchsvoller Konsolidierung und einer Cloud-Roadmap, die mit Oracles Linie zusammenpasst, kann die Fortfuehrung der naheliegende und wirtschaftlich sinnvolle Weg sein. Fuer ein Haus, das eine fragmentierte Werkzeuglandschaft zusammenfuehren moechte, ruecken unified-Plattformen ins Blickfeld. Wo die Planung im Zentrum steht und schnell veraenderlich ist, sind die planungszentrierten Spezialisten ein ernsthafter Kandidat. Und wo eine dominante SAP-Landschaft das operative Rueckgrat bildet, liegt die ERP-nahe Variante nahe. Keine dieser Aussagen ist ein Urteil ueber die Qualitaet 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 tragfaehigere Frage „Welches passt zu unserem Bedarf?“. Die erste Frage hat keine allgemeingueltige 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-Loesung, trifft eine Entscheidung, die sich spaeter begruenden laesst – unabhaengig davon, ob sie am Ende auf Hyperion, auf einen seiner Wettbewerber oder auf eine bewusste Kombination mehrerer Werkzeuge hinauslaeuft.

Häufige Fragen