Reintegration von Reporting in ERP-Systemevon Marcus Dill
Lesedauer: 7 Minuten
|
Seit den 90er Jahren wurden operative Prozesse und das zugehörige Reporting getrennt betrachtet. Die Ursachen waren primär technologischer Art. Das Berichtswesen wurde zur Last für die produktiven ERP-Systeme und musste auf separate Systeme ausgelagert werden. Dort entwickelten sich über Reporting hinaus auch komplexere Formen der Datenanalyse, die heutzutage viele intelligente Auswertungen möglich machen. Innovationen der jüngeren Zeit schaffen nun Möglichkeiten, Reporting und Analytics wieder ganz nah an operative Anwendungen in ERP-Systemen heranzuführen. Dies bietet Unternehmen viele neue Potenziale, fordert aber auch Konsequenzen für IT-Architekturen und die Organisation in Unternehmen.
Die Gründe für die Trennung von transaktionaler und Berichtswelt sind vielfältig. Business Intelligence (BI) ist rechenintensiv und komplex. Es konsumiert erhebliche Systemressourcen. Auswertungen erfordern akzeptable Antwortzeiten. Erst diese erlauben verschiedene Blickwinkel auf die Daten und damit einen wirklich guten Einblick in den Stand des Geschäfts. Auf herkömmlichen IT-Architekturen können kurze Antwortzeiten nur mithilfe von angepassten Datenmodellen erzielt werden. Diese dimensionalen Datenmodelle eignen sich aber wiederum nicht für transaktionale Verarbeitung und unterscheiden sich deutlich von den Datenmodellen der operativen Systeme. Der Aufbau dieser angepassten Datenmodelle und Analysesystemen erfordert viel Spezial-Know-how, das in vielen Organisationen über die Jahre in separaten Einheiten zusammengefasst wurde.
Die lange Zeit technisch unvermeidliche Trennung von operativen und Analysesystemen bringt massive Nachteile mit sich. Für das Management am auffälligsten sind die Unsummen, die der Aufbau von Data Warehouses verschlingt. Datenanalysten und fachliche Anwender beklagen dagegen vor allem die Trägheit dieser BI-Systeme, die auf neue Anforderungen oft nur nach Monaten reagieren können. Für Unzufriedenheit sorgen darüber hinaus Fehler, die sich bei der Übertragung und komplexen Aufbereitung der Daten einschleichen und in nicht wenigen Fällen die Daten und Berichte unbenutzbar machen. Auch dass Ereignisse von heute sich erst morgen oder sogar erst im Folgemonat in Berichten widerspiegeln, schränkt den Nutzen von isolierter BI ein.
Trennung überholt
Längst hat sich auf den Managementebenen und in den IT-Abteilungen dieser Welt herumgesprochen, dass die Notwendigkeit der Trennung von transaktionaler und Berichtswelt nicht in allen Fällen mehr gegeben ist. In vielen Unternehmen hält In-Memory-Technologie mit bisher nicht gekannten Verarbeitungsgeschwindigkeiten Einzug. Diese Performance macht eine auf die Analyse hin angepasste Datenmodellierung überflüssig. Sie erlaubt es, Reporting wieder näher an die transaktionalen Systeme heranzuführen, es zumindest in Teilen wieder in die ERP-Prozesse zu integrieren und zusätzlich auch weitere intelligente Verfahren zum Einsatz zu bringen.
Der Nutzen dieser neuen Architekturoptionen ist evident: Aufwände für die Replikation und Aufbereitung von Daten entfallen ebenso wie das lange Warten auf die Bereitstellung von Berichten bzw. die Umsetzung neuer Anforderungen. Auch das Risiko von Fehlern in den Verarbeitungsprozessen nimmt grundsätzlich ab. Der Grund, warum nach wie vor Fehlerquellen auftreten, ist, dass die meisten Berichte und Analysen ein Mindestmaß an fachlicher Verarbeitung und Berechnung erfordern. Diese wird natürlich auch auf In-Memory-Architekturen weiter benötigt. Sie wird jedoch virtualisiert, d. h. die Ergebnisse dieser Verarbeitung müssen nicht wie bisher aus Performancegründen vorberechnet und abgespeichert werden. Stattdessen erfolgt die fachlich notwendige Aufbereitung von Daten zum Zeitpunkt des Berichtsaufrufs bzw. in dem Moment, in dem sie von Analysten benötigt werden.
Vor allem drei Anwendungsgebiete werden in den nächsten Jahren das Zusammenwachsen von BI und Prozesswelt vorantreiben (Bild 1): operatives Reporting, Planungsapplikationen und integrierte Echtzeit-Analysen.
Operatives Reporting, d. h. einfache, historisch oft listenartige, zunehmend aber auch grafische Übersichten über einzelne Prozesse und Entitäten, gehört dabei zu den schnellen Erfolgen. Zukünftige IT-Architekturen erlauben grundsätzlich den kostengünstigen Bau von auch optisch ansprechenden Reporten und Dashboards, die beim Ausführen den aktuellen Datenstand des ERP bis hin zur Transaktion der letzten Sekunde beinhalten.
Die grundlegenden Konzepte und Bausteine für solche Architekturen sowie die Prinzipien für die Entwicklung operativer Berichtsanwendungen sind zwar grundsätzlich im Markt schon vergleichsweise weit entwickelt. Nicht alle Unternehmen bedienen sich aber dieser Konzepte. Sie setzen stattdessen die falschen Werkzeuge ein und arbeiten mit Methoden, die sich im Prozessumfeld bewährt haben mögen, im Analysekontext aber Fehler, unnötige Aufwände und Unzufriedenheit erzeugen. Eine simple Ursache für solche Fehlstarts ist, dass über die letzten Jahrzehnte in vielen Organisationen die Verantwortlichkeiten (und damit auch das Know-how) für BI von denen für die operativen Systeme getrennt wurden. Wenn nun auf operativen Systemen analytische Anwendungen entwickelt werden, greifen viele Unternehmen nicht auf die vorhandenen Konzepte und Erfahrungen in den BI-Abteilungen zurück. Strategisch denkende CIOs sollten daher ihre ggf. überholten Organisationsstrukturen im Kontext von Analysen überdenken und das im Haus vorhandene BI-Know-how ebenfalls wieder näher an die ERP-Systeme heranführen.
Planungsanwendungen, als zweite wichtige Treiber der Verschmelzung von analytischer und transaktionaler Welt, sind traditionell eng verbunden mit Reporting. Beide haben viele ähnliche Anforderungen. Viele Planungs- und Reportingtools setzen daher auf gemeinsame Komponenten und Konzepte. Planung erfolgt i. d. R. immer mit einem Blick auf historische Ist-Daten. Plandaten müssen im Normalfall auch wieder in das Reporting laufen, um dort Plan-Ist-Vergleiche zu ermöglichen. Andererseits gibt es im Planungskontext aber auch viele Szenarien, die eng mit den operativen Prozessen verbunden oder für deren Funktion sogar unverzichtbar sind. Beispielsweise erfordern Produktion und Logistik eine detaillierte und integrierte Planung von Lagerbeständen und Kapazitätsbedürfnisse. Produktions-, Einkauf- und Lieferprozesse werden mithilfe solcher operativen Planungsapplikationen gesteuert. Natürlich sind solche Planzahlen auch essenziell für ein effektives Management der Liquidität eines Unternehmens.
Viele Planungsanwendungen sind so eng mit ERP-Prozessen und der darin verbauten Logik verknüpft, dass sie nie aus deren Kontext isoliert werden konnten. Die effiziente Funktion moderner Planungswerkzeuge kommt daher nur wenig zum Einsatz. Stattdessen dominiert Spezialprogrammierung. Auch dies wird sich in den nächsten Jahren jedoch ändern: Mit dem Einzug von In-Memory- und BI-Technologie bieten sich vielen operativen Planungsanwendungen neue Möglichkeiten der Beschleunigung. Planungsprozesse, die heute noch Stunden oder gar Tage laufen, werden dann in Minuten oder gar Sekunden beendet sein. In vielen Fällen bietet sich hierdurch das Potenzial, Prozesse ganz neu zu konzipieren und dadurch die Basis für neue Geschäftsmodelle zu schaffen.
Herausforderungen
Erst langsam entwickelt sich der dritte Treiber für die Rückkehr von Analysen in das ERP-System. In den letzten Jahrzehnten wurden zahlreiche Softwaretools entwickelt, die über die Betrachtung von Berichten hinaus auch das Erkennen komplexer Zusammenhänge und die Prognose von Ereignissen auf der Basis von Wahrscheinlichkeiten ermöglichen (Predictive Analytics). Diese Werkzeuge werden in der überwiegenden Mehrzahl der Fälle noch „offline“ eingesetzt, d. h. außerhalb des unmittelbaren Prozesskontexts auf einem Data Warehouse oder einem anderen redundanten Datenbestand. Die Zahl der Ideen wächst jedoch, wie intelligente Verfahren die Prozesse unmittelbar steuern und verbessern können.
Bis operative und analytische Welt wieder vollständig zusammengewachsen sind, müssen die Vordenker dieser Entwicklung jedoch noch viele Probleme lösen und neue Konzepte entwerfen. In der Praxis bisher kaum ersetzbar sind Data Warehouses, z. B. wenn es um die Integration von Daten aus verschiedenen Systemen geht. Schon heute ist aber die Richtung klar, in der sich Technologie und Anwendungen entwickeln werden: sog. ETL-Prozesse (ETL = Extraction, Transformation, Load) werden virtualisiert und die dafür benötigten Tools ebenfalls operativen Anwendungen zur Verfügung gestellt.
Jüngste Neuerungen beispielsweise im Portfolio der SAP machen deutlich, dass diese Entwicklung auch gar nicht lange auf sich warten lassen wird. So enthält SAP HANA seit einigen Monaten auch die Funktionen der SAP Data Services, eines umfassenden ETL-Werkzeugs, Streaming-Tools, die z. B. die Integration von Sensordaten aus dem Produktionsumfeld erlauben, sowie einen sog. Smart Data Access. Letzterer erlaubt den Zugriff auf diverse außerhalb der HANA-Datenbank liegenden Quellen (Remote Datenbanken und Systeme, Hadoop etc.). Selbstverständlich hängt in solchen Fällen die Performance der Gesamtlösung wieder stark von den Antwortzeiten der Remote Quellen ab. Es sind daher übergreifende Konzepte und Investitionen in der gesamten IT-Architektur eines Unternehmens erforderlich.
ETL und die zuvor schon erwähnten organisatorischen Anpassungen sind jedoch nicht die einzigen Herausforderungen. Bild 2 führt einige der relevanten Themen auf. Darunter auch die Frage, wie mit Daten zu verfahren ist, die zwar akut nicht mehr ständig gebraucht werden, aber trotzdem nicht verworfen werden dürfen, da sie beispielsweise für rückblickende Auswertungen und die Erstellung von Prognosemodellen noch sehr nützlich sein können. Oder wie historische Sichten auf ERP-Systemen erhalten werden können, die ansonsten in den meisten Fällen nur den jeweils aktuellen Stand von Objekten und Transaktionen speichern. Die komplette Änderungshistorie würde auch die besten modernen In-Memory-Datenbanken an technologische oder Kostengrenzen führen. In der Vergangenheit waren Data Warehouses beliebte Archive für Datenhistorien. Insofern können möglicherweise auch in dieser Hinsicht bewährte Konzepte aus der BI- und Data Warehouse-Welt übernommen werden. Es werden jedoch mit Sicherheit Anpassungen auf die Besonderheiten des ERP erforderlich sein.
Das könnte Sie auch interessieren
