Die Überlegung einer möglichst weitgehenden Automatisierung der Prozesse in einem Data Warehouse (DWH) beschäftigt heute viele Projektteams.
Der Wunsch nach einer umfassenden Automatisierungslösung entsteht meist sehr schnell.
Welche Erwartungen an eine Automatisierungslösung gestellt werden, was die Hersteller versprechen und wie die Realität am Ende aussieht, beschreibe ich in diesem mehrteiligen Blogbeitrag. Im ersten Teil habe ich die Erwartungen der Projektteams an die Automatisierung beschrieben. Mit den Versprechungen der Automatisierungsanbieter und einem ersten Negativbeispiel für die Auswahl einer Automatisierungslösung beschäftigt sich der zweite Teil.
Im dritten Teil der Miniserie stelle ich weitere reale Fälle vor, die ich in den letzten Jahren erlebt habe. Zunächst zwei weitere Fälle, die als Negativbeispiele dienen (der erste Fall wurde im zweiten Teil der Miniserie beschrieben). Der dritte Teil dieser Miniserie endet mit einem Fall als Positivbeispiel für eine gelungene Automatisierungslösung.
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 fast 200 Kriterien im Vorfeld des Auswahlprozesses sorgfältig definiert und sich daran gehalten hat. Der anschließende PoC führte zum Erfolg.
Dies war der dritte und letzte Teil der Miniserie. Aber nicht der letzte der Coaching-Serie! Eure Erfahrungen zu diesem Thema würden mich sehr interessieren. Schreibt mir hier in den Kommentaren oder direkt.
Schaut unbedingt wieder vorbei.
Bis dahin
Euer Dirk