Ein Data Warehouse hat häufig chronisch zu viele unbearbeitete Anfragen und gleichzeitig steigt der Anteil des Wartungsaufwands. Der Todesstoß für ein Data Warehouse ist dann oft, wenn der Aufwand für die Wartung den Aufwand der Neuentwicklung übersteigt.
Da liegt es nahe, die Entwicklung zu automatisieren und so die neuen Requirements schneller umzusetzen. Die Automatisierung erfolgt über eine Generalisierung von Problemen, die Lösung wird als Lückentext (Template) umgesetzt. Für die spezifische Lösung wird dann der entsprechende Kontext in dieses Template eingefügt. Die automatisiert erzeugten Ergebnisse sind per se stabiler. Sollte sich doch ein Fehler eingeschlichen haben, kann man per Änderung im Template den Fehler gleichzeitig für alle Verwendungen beseitigen. Entwicklung und Wartung werden damit deutlich schneller.
Produktivitätssteigerung als stetiger Prozess
Nun hat man eine Automatisierungsumgebung, die sich perfekt optimieren lässt, um die Produktivität weiter zu steigern. In ‚The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win’ von Gene Kim, Kevin Behr und George Spafford gibt es eine gute Beschreibung, wie ein solches System aussehen kann. Wichtig ist hier die Bewertung der Arbeit anhand ihres Sinns und Nutzens:
- Wertschöpfung:
Die Abarbeitung von Anforderungen, mit denen neue und aktuelle Auswertungen entwickelt werden - Interne Projekte:
Mit denen der Arbeitsablauf verbessert werden soll - Änderungen:
Änderungen an den bestehenden Systemen, generiert von den ersten beiden Punkten - Ungeplante Arbeit:
Alle Arbeiten, die eigentlich nicht vorgesehen waren und welche die Arbeit an den drei vorherigen Punkten verhindert haben
Ungeplante Arbeit als Hebel für Beschleunigung
Die Überwachung ungeplanter Arbeit bringt eine nachhaltige positive Veränderung in einem Data Warehouse. Indem man die Ursachen für die ungeplante Arbeit gezielt angeht und diese in Zukunft zu vermeiden sucht, werden nicht nur Ressourcen frei, vielmehr kann das BI Team zuverlässiger arbeiten. Geplante Aufgaben können rechtzeitig abgeschlossen werden.
Hinzu kommt das Glück, die Friktionen im eigenen Arbeitsbereich nachhaltig selbst zu senken. Das macht alle Beteiligten glücklich und produktiv.
Leider kommt man hier auch schnell an Grenzen. Das Data Warehouse ist eine komplexe Angelegenheit mit vielen Abhängigkeiten. Im Artikel ‚Das Data Warehouse und die sieben Abhängigkeiten‘ werden diese Abhängigkeiten wie folgt dargestellt:
Geteilte Verantwortung reduziert Handlungsspielräume
Das Data Warehouse hat nur über die Technologie die alleinige Kontrolle. Alle anderen Abhängigkeiten, wie die Schnittstelle zu den Quellsystemen, den Betrieb oder die Datenlieferungen an irgendwelche Empfänger (FrontEnds) sind immer in geteilter Verantwortung. Das begrenzt den eigenen Handlungsspielraum und die Möglichkeiten, Friktionen zu reduzieren. Der Großteil der Vorgaben kommt zudem aus einem Bereich, der wohl seit Anbeginn der IT nie richtig funktioniert hat: die Definition und Weiterentwicklung der unternehmenseigenen Daten, das Datenmanagement.
Keine Angst, der Artikel kommt noch zu einem vernünftigen Schluss und versinkt nicht im Lamento. Halten Sie bitte noch einen kleinen Moment durch und blicken auf die Probleme, die dies im Data Warehouse verursacht. Probleme, die mit einer Automatisierung nicht zu lösen sind:
- Die korrekte und zuverlässige Bereitstellung der Daten durch das Quellsystem:
Das umfasst die Qualität der erfassten Daten genauso wie Lieferfehler durch das Quellsystem. - Mangelnde Einigkeit über die Daten:
Das beginnt mit der Frage ‚welche Entitäten?‘ sowie bei Homonymen und Synonymen, erstreckt sich über einheitliche Klassifikationsdaten im Rahmen des Masterdatenmanagement bis hin zur Frage von Datenschutz und -sicherheit mit seinen Zugriffsrechten.
Das Datenmanagement als große Ursache
Hinter all diesen Problemen gibt es eine gemeinsame Ursache: das Datenmanagement im Unternehmen. Selbst Lieferfehler durch das Quellsystem entpuppen sich häufig als nicht kommunizierte Weiterentwicklung im Datenmodell.
So lange nicht allen Beteiligten klar ist, über welche Daten gesprochen wird, kommt es in der Abstimmung zwangsläufig immer wieder zu Missverständnissen. Das bedeutet nicht, dass alle dieselben Definitionen haben müssen. Ein modernes Data Warehouse unterstützt mehr als eine Sichtweise auf die Daten. Dies verstärkt jedoch den Bedarf eines klaren Verständnisses über die zugrundeliegenden Daten. Das ist leider ein sehr altes Problem und die bekannten Lösungen sind:
- Gorilla:
Lösung mit maximaler Eskalation und Unterstützung durch das Top Level Management - Guerilla:
Ausgleich des fehlenden Datenmanagements durch Mehrarbeit. Diese Lösung kann soweit gehen, dass im Data Warehouse das unternehmensweite Datenmodell gepflegt wird und die Zugriffsrechte auf die Daten durch die IT entschieden werden.
Genug lamentiert. Wie kann eine vernünftige Lösung aussehen? Wo liegt der Mittelweg?
Lösungsorientierung durch Konzentration auf Bedürfnisse
Immer wenn verschiedene Parteien an einem Ergebnis gemeinsam arbeiten müssen, kommt es zu Interessenkonflikten. Für die Lösung eines Konflikts ist es unerlässlich, die eigenen Bedürfnisse zu kennen. Was brauche ich, um hier eine gute Lösung produzieren zu können?
Für ein BI Team heißt das, was braucht das Data Warehouse an Informationen, um eine optimale Lösung zu bieten. Hierzu werden Informationen zu den folgenden drei Aspekten benötigt (siehe Schaubild oben):
- Data Vault Schema:
Genaue Angaben zu den Daten bzw. Entitäten und deren Beziehungen für das Core Warehouse - Sicherheitsklassen:
Alle Angaben zu Datenschutz, Datensicherheit und den Zugriffsrechten auf die Daten - Business Rules, KPIs und Dimensionen:
Eine genaue Beschreibung der Anforderungen an die gewünschten Berichte und den notwendigen fachlichen Datentransformationen
Das Geschäftsobjektmodell als Überblick auf das Core Warehouse
Was ist das Minimum an Informationen, die hier notwendig sind? Ein guter Weg ist die Nutzung eines einfachen konzeptionellen Modells, dem Geschäftsobjektmodell. In einem Geschäftsobjektmodell sind die Geschäftsobjekte, deren Schlüssel, wenige Attribute und deren Beziehungen hinterlegt.
In seiner Einfachheit eignet sich ein Geschäftsobjektmodell für die Kommunikation mit dem Fachbereich. Hier ein weiteres Beispiel für eine einfache Darstellung der gemeinsamen Daten.
Wenn man diese Geschäftsobjekte mit den Quelldaten verknüpft, hat man eine erste Struktur des Core Warehouse. Die Attribute lassen sich nun zuordnen. Der Fachbereich erhält eine Liste, auf der er Datenschutz und -sicherheit klassifizieren kann. Die Vorgaben können mit den Begriffen aus dem Geschäftsobjektmodell gemacht werden und sind damit eindeutig. Alle diese Informationen lassen sich problemlos im Rahmen der Anforderungserhebung ermitteln und führen direkt auf die Lösung hin.
Zukunftsorientiert durch Pragmatismus
Die Konzentration auf die für das Data Warehouse notwendigen Informationen sorgt für ein ausreichendes System, ohne dass ein komplettes Datenmanagement umgesetzt werden muss. Sollte das Unternehmen künftig weitere Vorteile eines Datenmanagements nutzen wollen und zu einem späteren Zeitpunkt ein Projekt für ein unternehmensweites Datenmanagement aufsetzen. Dann kann das BI Team das neue System nutzen und sich ab diesem Zeitpunkt die notwendigen Informationen von dort holen. Da dies die gleichen Informationen sind, ändert sich nur die Quelle, die Struktur kann gleichbleiben.
Das ist weder Gorilla noch Guerilla, sondern pragmatisch und lösungsorientiert. Es werden nur für das Data Warehouse notwendige Arbeiten gemacht. Die geforderten Informationen sind minimal gehalten und entstammen letztlich aus der Betrachtung: „Was brauche ich an Daten für die Erstellung des Data Warehouse?“. Diese Daten lassen sich auch ideal nutzen, um weitere Automatisierungen voran zu treiben.
Data Warehouse Automatisierung als stetige Verbesserung
Eine Data Warehouse Automatisierung ist mehr als nur ein Tool. Mit einem Prozess zur beständigen Verbesserung der Abläufe und einem pragmatischen, lösungsorientierten Umgang mit den Partnern im Unternehmen lässt sich eine nachhaltige Verbesserung erreichen. Sprechen Sie uns unverbindlich an, wir zeigen gerne Lösungswege für eine bessere Data Warehouse Automatisierung auf.