Konstruktionsprinzipien eines Active Datawarehouse Stephan La Rocca Team GmbH Paderborn Schlüsselworte: automatische Kennzahlenanalyse, Rückführung ins operative System, Closed Loop, ECA (Event-Condition-Action), Ursachen-Wirkungsanalyse, Vergleichende Kennzahlenanalyse Einleitung Noch viele Datawarehouse Projekte enden mit der Präsentation der ermittelten Kennzahlen für die Fachanwender. Sicherlich wird die Aktualität des Zahlenmaterials immer größer und die Art und Weise der Bereitstellung der Daten immer ausgefeilter. Ein automatisierter Rückfluss des berechneten Wissens in die operativen Systeme bleibt allerdings meist aus. Active Datawarehouse bezeichnet die automatisierte Analyse von Kennzahlen und die Rückführung daraus gewonnener Informationen in das operative System. In der Literatur haben sich dafür die beiden Konzepte ECA (Event, Condition, Action) und Closed Loop (nahe dem kontinuierlichen Verbesserungsprozess) etabliert. Diese beiden Verfahren werden näher vorgestellt. Einordnung Nach Bauer/Günzel werden Datawarehouse-Systeme in unterschiedliche Reifegrade unterteilt. Auf der untersten Ebene werden Lösungen für ein Standard-Berichtswesen beschrieben. Über die Stufe von Lösungen pro Fachbereich und unternehmensweiter Datawarehouse-Systeme, stehen am Ende die Stufen der prädiktiven Datawarehouse Systeme und der Closed Loop Systeme. Eine Vielzahl der Projekte befindet sich gerade auf dem Sprung auf diese beiden letzten Stufen. Da je nach Reifegrad die Anforderungen an die Konstruktionsprinzipien, das Datenmodell und die Ladeprozesse different sind, sollen diese Prinzipien beleuchtet werden. Hauptkonzepte In einem Active-Datawarehouse existieren zwei Hauptkonzepte, die das Konstruktionsprinzip von unternehmensweiten Datewarehouse-Systeme unterscheiden.
Automatisierte Analyse Dieser Punkt beschreibt die regelbasierte Abarbeitung von definierten Kennzahlen. Diese Analyse wird durch das ECA-Verfahren näher beschrieben. Das ECA-Verfahren besteht aus den drei Schritten Event, Condition und Action. Event Ein Event bezeichnet ein punktuelles Ereignis, welches zeitlich zugeordnet werden kann. Das Event bestimmt die Ausführung einer Regel. Dabei können die Events unterschieden werden nach: - absoluten - periodischen - relativen Ereignissen. Absolute Events finden einmalig an einem zuvor bestimmten Zeitpunkt statt. Periodische Events können nach einem beliebigen Rhythmus aufgebaut werden. Der Rhythmus ist praktisch nur durch die Implementierung der Event-Engine eingeschränkt. Relative Events beziehen sich auf ein zuvor erfolgtes Ereignis und werden durch einen zeitlichen Versatz davon erzeugt. Condition Die Condition ist ein Prädikat über den gesamten Informationsumfang des Datawarehouse. Die Bedingungen sind idealerweise modular aufgebaut und werden sequentiell abgearbeitet. Durch die Kombination mehrerer Bedingungen, die geschachtelt abgearbeitet werden, kann ein gesamter Entscheidungsbaum erstellt werden. Action Die Ausführung als Ergebnis einer Regel kann unterschiedliche Ausprägungen haben. Von einer einfachen Information, dass eine ECA-Ereignis erfolgreich durchgeführt wurde bis hin zur Ausführung von Transaktionen im operativen System oder der Anpassung von leistungsrelevanten quasidynamischen Konstanten. Closed Loop Im Gegensatz zum ECA-Verfahren beschreibt das Closed-Loop-Verfahren einen etwas anderen theoretischen Ansatz bei der Umsetzung eines Active-Datawarehouse-System. Beim Closed-Loop-Verfahren werden wieder und wieder folgende fünf Schritte abgearbeitet: 1.) Überwachung Die Kennzahlen, die aussagekräftige Informationen über die zu beobachtenden Geschäftsprozesse liefern sollen, werden erhoben und protokolliert. 2.) Interpretation Durch den Vergleich mit Sollvorgaben, historischen Werten oder im Rahmen
verfügbarer Erfahrungswerde werden die erhobenen Daten interpretiert. Diese Interpretation ist dazu geeignet, den überwachten Geschäftsprozess zu bewerten. 3.) Analyse Die Bewertung des Geschäftsprozess bedarf, bevor es zu einer Änderung kommen kann, einer Analyse, auf Grund welcher Faktoren, Einflussgrößen, Geschäftsparameter oder andere Kenngrößen für die Bewertung maßgeblich heranzuziehen ist. Es mag mehrere Ursachen für die Bewertung haben und mehrere Möglichkeiten geben, diesen Prozess positiv zu verändern. 4.) Entscheidung Nach der Analyse der möglichen Veränderungen wird eine Entscheidung herbeigeführt, welche Änderung im operativen System zu erfolgen hat. 5.) Reaktion Beschreibt die Änderung im operativen System. Da es für den prozeduralen Aufbau in einer Oracle-Datenbank naheliegend ist, das ECA- Verfahren zu bevorzugen, wird im Folgenden näher auf die Prinzipien und Umsetzung dieses Verfahrens eingegangen. Dazu ist es in einem ersten Schritt notwendig, sich über die Quantifizierung der Kennzahlen Gedanken zu machen. Für die Quantifizierung sind vier Punkte zu berücksichtigen: - Ausprägung: Beschreibt die Aussagekraft der Kennzahl. Handelt es sich um Häufigkeiten, Ausmaße, eine Dauer, etc. - Objektbezug: Beschreibt den inhaltlichen und zeitlichen Geltungsbereich. Gilt die Kenngröße für einen Artikel oder eine Produktgruppe, für einen Tag oder einen Monat. - Einheit: Selbstredend - statistische Form. Beschreibt das Berechnungsmodell der Kennzahl um diese auf unterschiedlichen Dimensionsebenen zu aggregieren. Für den Aufbau eines ECA-Verfahrens ist es ebenfalls notwendig, eine möglichst vollständige Ursachen-Wirkungs-Analyse für die Kenngröße und deren Einflussfaktoren zu erstellen.
Abb. 1: Ursachen Wirkungs-Analyse in der Logistik Die Ursachen-Wirkungs-Analyse zeigt die Verbindungen zwischen einer definierten Kenngröße und möglichen Einflussfaktoren aus durchaus unterschiedlichen Geschäftsprozessen, Rahmenbedingen oder sogar äußeren Einflüssen. Mit der Erkenntnis aus einem solchen Diagramm können leichter Regeln und notwendige Aktionen aufgebaut werden. Die einzelnen Abhängigkeiten können ggfls. noch gewichtet werden, um die Auswertung der ECA-Verfahren darüber steuern zu können. In einer Implementierung dieses Verfahrens in der Oracle-Technologie-Landschaft mit dem Oracle Warehouse-Builder können die Events folgendermaßen realisiert werden: Mögliche Ereignisse: - Abschluss eines Ladeprozesses. Im Anschluss an einen Ladeprozess oder einen Workflow kann recht einfach ein solches Ereignis durch die ECA-Engine aufgegriffen werden. - Veränderung einer Prozessversion (SCD). Werden Geschäftsprozesse als Dimension zu der betrachteten Kennzahl geführt, so können Änderungen an dem Prozess, die sich
als mögliche Slowly-Changed-Dimension darstellt, das Ereignis für eine neue Ausführung dienen. - Eigene Job-Steuerung. Durch die klassischen Verfahren der Datenbank können eigene Ereignisse definiert und implementiert werden. Für die Implementierung der Bedingungen ist zunächst eine rudimentäre Vergleichsoperation nutzbar. Kenngröße Vergleichsoperator Vergleichswert. Mehrere dieser modularen Vergleiche können dann sequentiell oder parallel in komplexere Bedingungen überführt werden. In einer prozeduralen ECA-Engine können einer Bedingung auch mehrere Aktionen zugewiesen werden. Dies entspricht der Zuordnung von mehreren Aktionen zum gleichen Event und der gleichen Bedingung. Die Aktionen können Entscheidungs- oder Handlungsempfehlungen beinhalten. Im Wesentlichen lässt sich das auf das Versenden von E-Mails oder das Auslösen von vordefinierten Prozessen im operativen System zurückführen. Eine wesentliche Stärke in der prozeduralen ECA-Engine ist die einfache Möglichkeit der Dokumentation. Alle Ereignisse, alle Regelinterpretationen und alle ausgeführten Aktionen werden in den Tabellen der Engine gespeichert. Abb. 1: Die ECA-Engine im Umfeld der BISE1
Die Einbindung der ECA-Engine in die Oracle Landschaft ist schematisch recht intuitiv. In den folgenden Screen-Shots soll eine kleine Idee über die mögliche Implementierung vermittelt werden. Abb. 1: Datenmodell der ECA-Engine Abb. 1: Listing innerhalb der ECA-Engine
Kontaktadresse: Stephan La Rocca Team GmbH Hermann-Löns-Str. 88 D-33104 Paderborn Telefon: +49(0)5254-800865 Fax: +49(0)5254-800819 E-Mail sr@team-pb.de Internet: www.team-pb.de