Wie können wiederkehrende Aufgaben vereinfacht werden? Die Frage nach der Automatisierung von Prozessen in einem Data Warehouse (DWH) beschäftigt Projektteams.
Der Wunsch nach einem umfassenden Automatisierungsprodukt entsteht dann meist sehr schnell. Mittlerweile gibt es viele Produkte auf dem Markt: Etablierte, Newcomer und Eigenentwicklungen. Die Projektteams haben die Qual der Wahl. Und erleben nicht selten nach der Produktauswahl oder Produkteinführung eine Enttäuschung.
Worum geht es also? Viele Data Warehouse Projektteams haben sich in der Vergangenheit damit beschäftigt oder beschäftigen sich aktuell mit der Frage, wie sich die Entwicklung und Ausführung von Prozessen in einem Data Warehouse (im folgenden Data Solution genannt) automatisieren lässt: Wie können immer wiederkehrende Aufgaben vereinfacht und die Entwicklung der Prozesse mit möglichst wenig Aufwand durchgeführt werden?
Vor allem in einer Data Solution mit vielen sich wiederholenden Mustern - zum Beispiel mit Data Vault - besteht der Wunsch nach einem Automatisierungswerkzeug, das die Teams bei der Entwicklung unterstützt und einen Vorteil in der Gesamtperformance verspricht.
Welche Erwartungen an eine Automatisierungslösung bestehen, was Hersteller versprechen und wie die Realität am Ende aussieht, das beschreibt dieser Artikel.
Erwartungen an die Automatisierung
Die Erwartung der Projektteams an eine Automatisierungslösung besteht darin, den Neuaufbau oder eine notwendige Um- und Neustrukturierung einer Data Solution zu unterstützen. Spätestens dann, wenn über die Anschaffung oder Entwicklung einer Automatisierungslösung nachgedacht wird, tauchen in den Köpfen der Teammitglieder eine Reihe von Schlagworten auf.
Automatisierte ETL
Automatisierte Erstellung aller ELT- oder ETL-Datenlogistikprozesse - Wenn Datenlogistikprozesse manuell entwickelt werden, sind sie anfällig für Implementierungsfehler oder, wenn sich das Lademuster ändert, nur schwer zu aktualisieren. Dies ist häufig der Ausgangspunkt für Überlegungen zu einer Automatisierungslösung. Schließlich handelt es sich meist um wiederkehrende Muster (Tabellen und Prozesse), die einfach automatisiert werden sollten.
Vereinfachung
Vereinfachung des Entwicklungsprozesses - Wie kann das Projektteam die zu erledigende Arbeit vereinfachen und gleichzeitig schneller Artefakte liefern? Ist dies mit einem geeigneten Werkzeug möglich? Es wird erwartet, dass die Automatisierungslösung die tägliche Arbeit vereinfacht.
Orchestrierung
Orchestrierung der Datenlogistikprozesse - Viele kleine Prozesse (oft mehrere 1000) existieren in der Data Solution und müssen parallel und/oder in einer bestimmten Reihenfolge ausgeführt werden. Wenn diese alle manuell in ein Orchestrierungstool eingefügt werden müssen, ist dies sehr aufwendig und es wird erwartet, dass die Automatisierungslösung diese Aufgabe übernimmt.
Metadaten
Metadaten, die DNA der Data Solution - Spätestens jetzt wird den Teams die Notwendigkeit von Metadaten bewusst. Es wird erwartet, dass diese die Grundlage bilden, um die Prozesse zu erstellen, zu vereinfachen, zu orchestrieren und schließlich so weit wie möglich zu automatisieren.
Geschwindigkeit
Schnellere Lieferung von Artefakten - Die bisherigen Gedanken und Schlagworte zu einer Automatisierungslösung führen zu der Erwartung, dass das durch eine Automatisierung, Vereinfachung und Orchestrierung mit Metadaten die Lieferung von Artefakten schneller wird.
Data Vault Standard
Vorhandene Data Vault Standards nutzen - Natürlich wird erwartet, dass alle Data Vault Standards unterstützt werden. Unabhängig davon, welcher Data Vault Standard in der Data Solution geplant ist oder bereits eingesetzt wird. Und die Automatisierungslösung sollte an die Bedürfnisse im Projekt anpassbar sein, wie z.B. die Wiederverwendung von Standards aus einem Buch oder eines anderen Automatisierungstools.
Unempfindlich
Unempfindlich gegenüber (externen) Änderungen - Wenn sich etwas im operativen System ändert oder neue Daten integriert werden müssen, wird erwartet, dass die daraus resultierenden Änderungen oder ein Refactoring in der Data Solution sehr einfach durchgeführt werden können.
Integration
Die Integration unterschiedlicher operativer Systeme - Es wird erwartet, dass die Integration verschiedener operativer Systeme einfach zu handhaben ist. Dies gilt auch für die Unterstützung bei der Integration unterschiedlicher, sich überschneidender oder konkurrierender Geschäftsschlüssel.
Top 10
Hohes Ranking - Die Automatisierungslösung ist in einem Ranking möglichst hoch bewertet. Dabei spielen die Kriterien bzw. die bewerteten Features keine Rolle (bzw. dürfen keine Rolle spielen).
Dies sind nur einige der Erwartungen, die mir in den letzten Jahren begegnet sind und die an die Automationslösung gestellt werden. Und doch sind es auch die Gründe, die für eine Investition in eine Automatisierungslösung sprechen.
Versprechen der Automatisierungsanbieter
Projektteams, die auf der Suche nach einer Automatisierungslösung sind, haben die Qual der Wahl. Mittlerweile gibt es viele Produkte auf dem Markt: etablierte Lösungen und Newcomer sowie unzählige Eigenentwicklungen.
Nicht selten erleben die Teams nach der Produktauswahl oder Produkteinführung eine Enttäuschung. Eine der Hauptursachen dafür sind die Versprechungen, die die Verkäufer einer Automatisierungslösung während des Verkaufsprozesses machen.
Bei der Auswahl von Anbietern für eine Automatisierungslösung kommt immer der Punkt, an dem die Projektteams die Anbieter zu einer Demo oder Produktpräsentation einladen.
Präsentationen zeigen die Idealwelt, Demos sind genau auf die Funktionalitäten einer gezeigten Automatisierungslösung abgestimmt. Unabhängig davon, ob es sich um eine etablierte Lösung, ein Start-up oder die Eigenentwicklung eines Beratungsunternehmens handelt. So soll es auch sein! Schließlich verfolgen alle Automatisierungslösungen (mehr oder weniger) das gleiche Ziel.
Ein guter Verkäufer fragt nach den Erwartungen des Projektteams an die Automatisierungslösung. Genau an dieser Stelle kommen die Versprechen des Verkäufers als Antwort auf die bestehenden Erwartungen ins Spiel:
- „Natürlich unterstützen wir die Data Vault Modellierung!“ - Aber wie? Und ist es das, was das Projektteam erwartet?
- „Wir können (alles) automatisieren!“ - Aber was genau? Eine Suche im Internet zeigt, wie viele Tools es gibt, die das Stichwort Automatisierung in ihrer Beschreibung haben, aber völlig anders sind als erwartet.
- „Unsere Lösung funktioniert sofort nach dem Auspacken!“ - Kurz installieren und das war’s?
- „Wir können Continuous Delivery! Sie müssen sich um nichts kümmern!“
- „Die gesamte Codegenerierung ‘out of the box’! Keine Anpassungen notwendig!“
Die Antworten auf weitere Erwartungen des Projektteams könnten wie folgt lauten:
„Wenn es um Orchestrierung, kontinuierliche Bereitstellung von Artefakten und Entwicklungsgeschwindigkeit geht - unsere Lösung bildet all das ab und läuft fast von selbst. Es sind nur ein paar kleine Dinge zu tun und das war's.“
„Data Vault Tabellen generieren? Klar, in allen Variationen!“
Fragt das Projektteam konkret nach den Möglichkeiten der fachlichen Datenmodellierung, könnte die Antwort lauten:
„Unsere Lösung unterstützt fachliche Datenmodellierung!“
Versprochen wird alles und meist noch viel, viel mehr. Manche Versprechungen sind vielleicht in einem anderen Zusammenhang gemeint, aber das macht ja nichts, oder?
Wir alle kennen diese Versprechungen, wir alle kennen die Notwendigkeit, Lösungen objektiv zu bewerten, und gleichzeitig lassen wir uns leicht davon überzeugen, dass die Lösung, die gerade präsentiert wird, die beste ist.
Ich möchte nicht, dass ein falscher Eindruck entsteht. Jede Lösung hat ihre Daseinsberechtigung, alle gemachten Aussagen und Versprechungen können in einem bestimmten Kontext richtig, korrekt und vollständig sein. In diesem Sinne gibt es keine schlechte oder gute Automatisierungslösung - nur eine, die besser oder weniger gut zur Situation passt.
Deshalb ist es so wichtig, sich als Projektteam darüber klar zu werden, was von einer Automatisierungslösung erwartet wird und nach welchen Kriterien sie objektiv bewertet werden kann.
Dies sind nur einige der Versprechungen, die mir begegnet sind. Und doch sind es auch die Gründe, die für eine Investition in eine Automatisierungslösung sprechen.
Fallbeispiele
Im Folgenden stelle ich einige reale Fälle vor, die ich in den letzten Jahren erlebt habe. Zuerst nur einige negative Fälle. Dann aber auch ein positives Beispiel für eine gelungene Auswahl einer Automatisierungslösung.
Erster Fall
Im ersten Fall wurde von Anfang an ein gutes Instrumentarium geschaffen. Das Projektteam, nennen wir es Team A, führte einen umfassenden Auswahlprozess durch, beginnend mit einer langen Liste von Automatisierungsanbietern, die auf vier Anbieter bzw. vier Automatisierungslösungen reduziert wurde.
Team A war zu Recht sehr stolz auf seine Leistung, einen definierten Satz von wirklich guten Auswahlkriterien zu erstellen, diese zu gewichten und alle Informationen, die sie von den Anbietern (schriftlich oder in Interviews) erhielten, als zusätzliche Informationen zu den Auswahlkriterien hinzuzufügen. Das Ziel von Team A war es, so schnell wie möglich eine Automatisierungslösung zu finden, die den Anforderungen des Unternehmens gerecht wird.
Eigentlich eine gute Ausgangssituation, oder? Allerdings, und das ist die Kehrseite der Medaille, hatte Team A insgeheim eine bevorzugte Automatisierungslösung. Dies war während des gesamten Prozesses weder transparent noch offensichtlich.
Wie konnte es dazu kommen? Die Versprechen der Verkäufer waren ausschlaggebend. Ich habe großen Respekt vor der Leistung und Überzeugungskraft mancher Verkäufer, das gebe ich ehrlich zu. In dem hier geschilderten Fall war die Präsentation einer Automatisierungslösung so gut, dass die teilnehmenden Mitglieder von Team A diese Lösung als ihre Wunschlösung festlegten und im weiteren Verlauf nicht mehr davon abwichen.
Zurück zu Fall 1: Die Ergebnisse des Auswahlprozesses - der wirklich gut durchgeführt wurde - entsprachen natürlich nicht der bevorzugten Automatisierungslösung, aber den ursprünglich gestellten Anforderungskriterien.
Was geschah dann? Die Kriterien aus dem vorherigen Auswahlfragebogen wurden so lange angepasst und verwässert, bis alle Kriterien der gewünschten Automatisierungslösung entsprachen. Und so kam diese dann auch auf den ersten Platz!
Hinzu kam, dass das technologieorientierte Denken wieder die Oberhand gewann. Das heißt, Team A konzentrierte sich mehr auf die technologischen Eigenschaften der Automatisierungslösungen als auf die tatsächlichen Anforderungen, die durch Use Cases, Datenarchitektur und andere Kriterien definiert wurden.
Und was war das Ergebnis in Fall 1? Heute, nach mehreren Jahren, hat sich Team A bzw. das Unternehmen immer noch nicht für eine Automatisierungslösung entschieden. Die ausgewählte Automatisierungslösung hat den anschließenden Proof of Concept (PoC) nicht bestanden bzw. nicht wie erwartet funktioniert. Die Zeit verging, Team A entschied sich für eine andere Automatisierungslösung, der PoC scheiterte und so weiter.
Aus meiner Sicht war hier im ersten Fall der Fehler, dass sich Team A im Auswahlprozess nicht mehr auf die Kriterien und Funktionen konzentriert hat, sondern von Emotionen und einigen Fancy Features getrieben die Entscheidung für eine Automatisierungslösung getroffen hat.
Zweiter Fall
Im zweiten Fall hat das Projektteam, nennen wir es Team B, eine Vorauswahl von Automatisierungslösungen getroffen. Diese sah wie folgt aus: Mit Google nach dem Stichwort ‘Automatisierung’ suchen. Es ist erstaunlich, was man dort an Suchergebnissen erhält, die so gar nicht zu einer Datenlösung passen.
Das Ergebnis war eine riesige Liste von über 30 Anbietern mit dem Angebot einer ‘Automatisierungslösung’, die bei der Suche im Internet gefunden wurden.
Die Liste von Team B umfasste alles, was irgendwie mit Automatisierung zu tun hatte. An diesem Punkt nahm Team B externe Hilfe in Anspruch, reduzierte die Anzahl der Anbieter erheblich und hatte schließlich eine Vorauswahl von Anbietern getroffen.
Das wirklich Gute an der Start- und Erwartungsphase von Team B war, dass sie die Chance genutzt haben, sich mit anderen Unternehmen auszutauschen, die bereits erfolgreich Automatisierungstools eingeführt haben.
Zu diesem Zeitpunkt schien es, dass Team B wirklich auf dem besten Weg war, ein perfektes Werkzeug für ihre Anforderungen und Ziele zu identifizieren. Aber: Team B formulierte die Anforderungen auf einem sehr hohen und abstrakten Niveau, mit einer vagen Definition und einem sehr starken Fokus auf Technologie. Und darüber hinaus hat es von diesem Zeitpunkt an auf externe Unterstützung verzichtet.
Das eigentliche Ziel von Team B war es, eine Automatisierungslösung zu finden, die alle manuellen Aufgaben des Entwicklers auf ein Minimum reduziert und unterstützt. So sollte der Schwerpunkt auf der fachlichen Modellierung - konzeptionell und logisch - liegen. Auch die physische Modellierung und damit die Erstellung von Tabellen, Ladeprozessen und die Orchestrierung sollten durch die Automatisierungslösung unterstützt werden.
Team B hatte in der Praxis große Schwierigkeiten, die Kriterien für den Auswahlprozess zu identifizieren, festzulegen und zu gewichten. Grund dafür waren die im Vorfeld vage und abstrakt formulierten Anforderungen.
Bevor dieser Kriterienfindungsprozess abgeschlossen war, lud Team B bereits die ersten Hersteller zu Präsentationen und Vorführungen ein. Und auch hier, in Fall 2, waren die Verkäufer sehr stark in der Präsentation ihrer Tools. Sie haben Team B immer versprochen: Ja, unser Tool kann das.
Und was ist passiert? Im Prinzip ein wirklich trauriges Ende, denn Team B ist mit diesem Projekt nach einem Jahr gescheitert und hat die Arbeit an der Automatisierungslösung komplett eingestellt. Die Automatisierungslösung entsprach nicht den Anforderungen, den Erwartungen. Aufgrund der vagen und unvollständigen Kriterien wurde eine falsche Entscheidung getroffen. Es wurde viel Geld verschwendet bzw. verbrannt.
Dritter Fall
Im dritten Fall hat das Projektteam, nennen wir es Team C, einen starken Wunsch nach einem Automatisierungstool.
Team C hat von Anfang an keine vollständige Liste für die Auswahl einer Automatisierungslösung erstellt. Es gab nur eine sehr kurze Liste, da die Vorauswahl auf den persönlichen Ansichten und Empfindlichkeiten einer einzelnen Person aus Team C basierte.
Auf der anderen Seite hat Team C gute Arbeit geleistet, indem es einen Proof of Concept (PoC) erstellt hat, um Erfahrungen mit den Automatisierungslösungen zu sammeln. Andererseits waren für den PoC keine konkreten Bewertungskriterien, sondern nur allgemeine Schlagworte vorgegeben.
Zusammenfassend kann gesagt werden, dass Team C ein ‘unabhängiges’ Auswahlverfahren für eine Automatisierungslösung durchführen wollte, ohne eine wirkliche Vorauswahl der Anbieter zu treffen. Und das verbunden mit einem geforderten POC, der nach Schlagwortkriterien bewertet werden sollte.
Die (unklare) Kriterien für den PoC sowie (unklaren) Anforderungen und Ziele für den Auswahlprozess wurden maßgeblich von persönlichen Meinungen und Vorlieben eines einzelnen Teammitglieds bestimmt. Mögliche externe Hilfe zum Auswahlprozess unabhängiger Anbieter und der Erstellung eines PoC wurden mit der Begründung abgelehnt, dass Team C mehr als genug Expertise dafür hat.
Bis heute hat Team C keine Entscheidung für eine Automatisierungslösung getroffen. Einer der Gründe war neben den oben genannten Unsicherheiten, dass fachliche Probleme mit einer neuen Technologie gelöst werden sollten. Dies funktioniert in der Regel nicht, da fachliche Probleme auf fachlicher Ebene gelöst werden müssen und nicht mit einer neuen tollen Technologie.
Gedanken
Ein paar Gedanken (fast) zum Abschluss der Beitragsreihe. Der wichtigste Gedanke, den ich vermitteln möchte, ist, dass man sich immer überlegen muss, welche Herausforderungen mit einer Automatisierungslösung gelöst werden sollen.
Anforderungen und Ziele
Welche Anforderungen werden gestellt und welche Ziele werden verfolgt? Wohin soll die Reise gehen? Wenn Anforderungen und Ziele klar definiert sind, geben sie eine objektive Orientierung.
Weitreichend Entscheidung
Die Wahl einer Automatisierungslösung ist eine weitreichende Entscheidung, die mehrere Jahre Bestand hat. Mögliche Änderungen dürfen nicht dazu führen, dass die Automatisierungslösung ersetzt werden muss.
Proof of Concept
Definition eines PoC zum Testen der definierten Anforderungen und Ziele in der kleinstmöglichen Timebox.
Technologie ist keine LösunG
Die Technologie selbst ist nicht die Lösung der Probleme. Entscheidend für die richtige Auswahl sind die Anforderungen und Ziele.
Kompetenzkreis
Den tatsächlichen Kompetenzkreis im Vergleich zum wahrgenommenen Kreis für die Auswahl einer Automatisierungslösung kennen. Das Kompetenzniveau nicht überschätzen.
Verantwortlich handeln
Verantwortungsbewusstes und nachhaltiges Handeln für sich, das Projekt und das Unternehmen.
Unabhängiger Experte
Zu wissen, wann man die Hilfe eines unabhängigen Experten benötigt. Man kann als Projektteam nicht alles wissen, vor allem weil die Softwareauswahl nicht jeden Tag stattfindet.
Kritisch sein
Vertrauen Sie nicht (blind) den ‘haltlosen’ Versprechungen des Verkäufers. Das Ziel des Verkäufers ist es, sein Produkt zu verkaufen und nicht, Ihre Probleme zu lösen.
Auswahlverfahren
Die Anforderungen und Ziele sowie der vorhandene Kompetenzkreis bilden die Grundlage für den eigentlichen Auswahlprozess.
Strukturiert
Strukturiert beginnen, Anforderungen und Ziele nutzen, um gute Kriterien für den Auswahlprozess zu finden.
Kriterien
Finden von greifbaren und nachvollziehbaren Kriterien zur Bewertung der Automatisierungslösung im Hinblick auf Ihre Anforderungen und Ziele.
Zuversicht
Vertrauen in die Veränderungen, falls in Zukunft Anpassungen notwendig werden.
Fallbeispiel - Idealtypisch
Die ersten drei Fälle für die Auswahl einer Automatisierungslösung waren nicht erfolgreich. Im vierten Fall hat das Projektteam - nennen wir es Team D - am Ende des Auswahlprozesses eine erfolgreiche Entscheidung getroffen. Die folgende Abbildung zeigt das Ergebnis des Auswahlprozesses.
Was haben sie anders gemacht? Team D hat die Anforderungen und Ziele, die Kriterien und Funktionen, die es für die Entscheidungsfindung für eine Automatisierungslösung benötigte, genau definiert und beschrieben.
Kategorien wie Metadaten, Sicherheit, Datenqualität wurden von Team D definiert und beschrieben. Alle Detailkriterien in diesen Kategorien wurden entsprechend den Anforderungen gewichtet.
Das Ergebnis war, dass Team D durch die einfache Visualisierung in der Lage war, die für sie beste Automatisierungslösung auszuwählen. Es schnitt nicht in jeder Kategorie am besten ab, aber insgesamt war es das beste Ergebnis. So konnte Team D objektiv eine Automatisierungslösung auswählen. Im Hinblick auf die Anforderungen und die Ziele, die das Team D hatte, haben sie eine gute Entscheidung getroffen. Einer der zentralen Erfolgsfaktoren war, dass Team D alle Kategorien und die für sie wichtigen Kriterien im Vorfeld des Auswahlprozesses sorgfältig definiert und sich daran gehalten hat. Der anschließende PoC führte zum Erfolg.
Eure Erfahrungen zu diesem Thema würden mich interessieren. Schreibt einen Kommentar oder mir direkt.
Schaut unbedingt wieder vorbei.
Bis dahin
Euer Dirk