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.
Die Versprechungen der Automatisierungsanbieter sowie erste Negativbeispiele bei der Toolauswahl stehen im Mittelpunkt dieses zweiten Teils der Miniserie.
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.
Versprechen der Automatisierungsanbieter
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 in den letzten Jahren 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 größte 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.
Im dritten und letzten Teil des Blogbeitrags geht es um die weiteren Fälle zur Auswahl einer Automatisierungslösung und meinen Gedanken dazu.
Schaut unbedingt wieder vorbei.
Bis dahin
Euer Dirk