Organisatorische und prozessuale Voraussetzungen für ein ... / 5 Der erste Erfolg: Die zentrale Datenbasis

Die Vergangenheit hat uns gelehrt, dass es unabdingbar ist, einen "Single Point of Access" zur Verfügung zu stellen. Zum damaligen Zeitpunkt verwendete jeder Controller eine eigene Datenbank und individuelle Tools zur Abfrage und Aufbereitung seiner Daten. Access-Lösungen und eine große Anzahl von Excel-Tabellen haben sich im Laufe der Jahre ebenso wie ein Jedox Palo-Server eingebürgert. Die Verwendung solcher Insellösungen war aufwändig und fehleranfällig. Vor allem die nicht strukturierten und dokumentierten Schnittstellen stellten aus Unternehmenssicht ein hohes Risiko dar.

Nach den Vorarbeiten zur Vereinheitlichung der Organisation und der Arbeitsweisen galt es zu entscheiden, wie wir diese – nun strukturierten – Daten möglichst effizient nutzen konnten, ohne wieder in der Spreadsheet-Hölle zu landen. Dabei wurde uns schnell klar, dass wir um die Einführung einer zentralen Data Warehouse-Lösung nicht herumkommen werden.

Im Variantenvergleich fiel die Entscheidung auf SAP BW. Vor allem in der Möglichkeit, die Daten über Standardschnittstellen aus den beiden operativen ERP-Systemen übernehmen zu können, sahen wir einen großen Vorteil. Die in BW vollintegrierte SAP-Konsolidierungslösung SEM BCS (Strategic Enterprise Management Business Consolidation System) und der erste Ausblick auf die angebotenen Frontend-Tools, die in ihrem optimalen Setup auf BW zugreifen, waren zusätzliche Argumente für die SAP-Lösung.

Abb. 2 zeigt die Systemlandschaft und die Datenflüsse rund um das SAP BW in der Styria-Gruppe. Als Ist-Datenquellen dienen vor allem die beiden SAP ERP-Systeme für Österreich und Kroatien/Slowenien (siehe durchgezogene Linien). Die Beladung erfolgt über tägliche Prozessketten. Zusätzlich bauten wir File-Schnittstellen und SQL-Server-Anbindungen auf. So ist es uns möglich, Mengendaten, Umsatzerlöse, Wareneinsätze etc. aus verschiedenen Vorsystemen zu übernehmen.

Zur Erfassung von Einzelwerten, für die auch eine File-Schnittstelle zu aufwändig gewesen wäre, fanden wir im Zuge der Auswahl unserer Frontend-Tools einen geeigneten Lösungsansatz. Wir erstellten eingabefähige Queries und können somit bspw. öffentlich verfügbare Auflagenzahlen von Zeitungen der Mitbewerber oder Hörerreichweiten von Privatradios über den umgekehrten Weg in SAP BW zurückschreiben. Diese Vorgangsweise ist jedoch nur bei selten zu erfassenden Kennzahlen praktikabel. Zusätzlich werden Kommentare im Monatsabschluss über das Frontend erfasst und quasi als Ist-Daten an SAP BW geliefert.

Abb. 2: Systemlandschaft der Styria-Gruppe

Anfänglich gab es Performance-Probleme beim Abruf der BW-Daten, wodurch die Akzeptanz im Rollout etwas an Dynamik eingebüßt hat. Dieses Thema konnten wir jedoch durch den Umstieg auf SAP BW on HANA lösen.

Etwa 3 Jahre später begannen wir in einem nachgelagerten Projekt mit der Einführung des Planungssystems IBM Cognos TM1. Seitdem werden Ist-Daten für die Budgetierung in TM1 geladen. Die Controller erstellen auf Basis dieser Werte den Forecast sowie die Planung für die 3 Folgejahre und geben diese Planwerte dann an SAP BW zurück (siehe punktierte Linien). Angereichert um zusätzliche statistische Plan-Kennzahlen wie bspw. FTEs, die direkt über das Frontend-Tool erfasst werden, erfolgt die Retraktion in SAP ERP.

Dort werden die Umlagen in den 2 klassischen Schritten gerechnet: Umlage der Hilfskostenstellen und Umlage auf Produkte.^[1] Um den Wartungsaufwand möglichst gering zu halten, haben wir uns bei der Struktur der Planumlagen soweit möglich an jene im Ist gehalten. Die Ergebnisse werden im Anschluss wieder an SAP BW übergeben.

In einem Konzern in der Größe der Styria-Gruppe stellt sich natürlich auch zurecht die Frage, ob der Betrieb von 2 getrennten ERP-Systemen notwendig ist oder die Zusammenführung zu einem System ökonomischer wäre. Da diese Fragestellung jedoch nicht ausschließlich aus FI-/CO-Sicht zu beantworten ist, haben wir sie aus unserem Projekt ausgeklammert.

[1] Die Umlage auf Produkte wurde nach der Einführung der Deckungsbeitragsrechnung (vgl. Abschnitt 6.1 Produkterfolgsrechnung) möglich.