In den letzten Jahren haben viele Unternehmen in Datentechnologie als „Kraftmultiplikator“ für die Bereitstellung von Geschäftswerten investiert. Leider haben die meisten dieser Unternehmen festgestellt, dass Technologie allein keine magische Lösung für bürokratische Datenprozesse, eine ineffiziente Datenteamstruktur oder einen Mangel an Datenwissen und ‑begeisterung innerhalb des Unternehmens ist. Aus diesem Grund werden selbst die fortschrittlichsten Datenplattformen oft nicht voll ausgeschöpft. Zusammenfassend lässt sich sagen, dass wir die Datentechnologie als Mittel und nicht als Zweck sehen sollten.
In diesem Artikel wird näher beleuchtet, warum viele Datenprojekte von vornherein scheitern. Anhand eines Beispiels zeige ich, dass die alleinige Betrachtung von Datenprojekten unter technologischen Gesichtspunkten nicht ausreicht, um nachhaltige Werte zu schaffen. Als Nächstes führe ich das Conway’sche Gesetz ein, um die zugrundeliegenden Muster zu veranschaulichen, die diese Misserfolge maßgeblich beeinflussen. Im letzten Teil des Artikels gehe ich der Frage nach, wie die Ergebnisse verbessert werden können, indem ein breiterer Fokus auf die datengesteuerten Fähigkeiten des Unternehmens gelegt wird.
Scheitern von Datenprojekten: Ein Beispiel
Viele Unternehmen beginnen ihre datengesteuerte Reise mit der Definition eines „Datenprojekts“. Diese Projekte haben oft den Ehrgeiz, neue datengesteuerte Fähigkeiten innerhalb der Organisation zu realisieren. Ich stelle jedoch fest, dass viele dieser Projekte zum Scheitern verurteilt sind und dieses Ziel nie erreichen werden!
Um dies zu veranschaulichen, betrachten wir eine Organisation, die heute mit den folgenden Problemen konfrontiert ist:
- Lange und unvorhersehbare Datenvorlaufzeit: Alle Berichte werden von einem zentralisierten Berichtsteam erstellt. Die Geschäftsteams leiten ihre Anforderungen an dieses Berichtsteam weiter, das die benötigten Berichte implementiert und bereitstellt. Die Prioritäten zwischen dem Berichtsteam und den Geschäftsteams sind nicht aufeinander abgestimmt, was zu einer langen und unvorhersehbaren Vorlaufzeit führt.
- Schattenberichterstattung: Aufgrund der langen Vorlaufzeit beginnen die Geschäftsteams, ihre eigenen Berichte in Tabellenkalkulationen zu erstellen. Diese Berichte werden anhand von Exporten aus den Quellanwendungen oder sogar anhand von Exporten aus einer Vielzahl von bestehenden Berichten erstellt.
- Nur Paul weiß Bescheid: Es gibt kaum Dokumentation über Daten und den Datenfluss von der Quelle zum Ziel. Zum Glück gibt es Paul, der auswendig weiß, wie jeder Fluss funktioniert. Leider kann Paul nicht alle Bälle in der Luft halten. Pauls Verfügbarkeit ist ein Engpass für viele Lieferinitiativen.
- Unzuverlässige KPIs: Das Managementteam steuert über ein zentrales KPI-Dashboard. Leider muss jeder KPI mit Vorsicht interpretiert werden. Entweder steht die KPI-Definition jedes Mal zur Debatte, wenn wir sie öffnen, oder die Daten, die diesem KPI zugrunde liegen, enthalten Datenqualitätsprobleme, die die Zahl erheblich beeinflussen. Ein KPI, der die Anzahl der Kunden anzeigt, weist beispielsweise 20 % zu viele Kunden aus, weil es in einem Quellsystem zu unerwünschten Datendopplungen gekommen ist.
- Unbekannter Datenzugriff: Der Zugriff auf die Daten erfolgt durch ein zentrales Service-Desk-Team. Dieses Team weiß nicht, wer Zugriff auf welche Berichte oder welche Teile der zugrunde liegenden Datenbank hat. Infolgedessen gewähren sie jedem Zugriff auf die angeforderten Daten, ohne zu wissen, ob dies sinnvoll ist oder nicht. Die Datenzugriffsrechte werden nie überprüft.
- Die Innovation bleibt stecken: Da das zentralisierte Berichtsteam mit den Berichtsanforderungen voll ausgelastet ist, bleibt keine Zeit für Innovationen. Sie konzentrieren sich darauf, alles am Laufen zu halten. Geschäftsanfragen zu Neuerungen wie künstlicher Intelligenz oder unstrukturierten Daten werden aufgrund mangelnder Ressourcen zurückgestellt.
Ein Projekt definieren
Nach einer Weile begannen die oben beschriebenen Probleme zu eskalieren, was zur Definition eines „Datenprojekts“ führte. Dieses Projekt würde eine neue, hochmoderne Datenplattform einführen, mit der das Unternehmen den Sprung ins 21. Jahrhundert schafft. Die Geschäftsteams werden sogar die Möglichkeit erhalten, „Self-Service-Reporting“ zu nutzen. Der Projektplan und die Roadmap wurden fertiggestellt, ein Team von Entwicklern an Bord geholt, und die Arbeit kann beginnen!
Nachwirkungen
Machen wir nun einen Zeitsprung nach dem optimistischen (aber auch unrealistischen) Szenario der „erfolgreichen Lieferung“ und der pünktlichen Bereitstellung der Datenplattform. Diese neue Plattform würde die Datenschmerzen des Unternehmens in Datengewinne verwandeln! Leider war dies nicht der Fall:
- Lange und unvorhersehbare Datenvorlaufzeit: Self-Service-Reporting ist verfügbar, aber die Geschäftsteams sind bei der Dateneingabe und ‑aufbereitung immer noch auf das zentrale Datenteam angewiesen. Unausgewogene Prioritäten führen weiterhin zu Verzögerungen.
- Schattenberichterstattung: Während die Verwendung von Tabellenkalkulationen zurückgegangen ist, existieren nun mehrere Versionen desselben Berichts im Berichtsportal, was zu unkontrollierten Schattenberichten in einem anderen Tool führt.
- Nur Paul weiß Bescheid: Paul ist nach wie vor unverzichtbar, um sich auf der neuen Plattform zurechtzufinden. Sein Wissen ist immer noch ein Engpass für Innovationen.
- Unzuverlässige KPIs: Vorübergehende Verbesserungen der Datenqualität während des Projekts waren nicht von Dauer. Anhaltende Dateneingabefehler führen zu neuen Qualitätsproblemen, was wiederum zu unzuverlässigen KPIs führt.
- Unbekannter Datenzugriff: Die neue Plattform verfügt über granulare Zugriffskontrollen, aber das Service-Desk-Team gewährt weiterhin Zugriff, ohne sich richtig auszukennen, und folgt dabei demselben fehlerhaften Prozess.
- Innovation bleibt stecken: Trotz der Möglichkeiten der neuen Plattform wird die Innovation immer noch durch die Abhängigkeit von Paul, anhaltende Probleme mit der Datenqualität und die Ungewissheit über den Datenzugriff behindert. Zumindest wird die Innovation aber nicht mehr technologisch blockiert.
Conway’s Law
Was wir in diesem Beispiel sehen, ist das Ergebnis eines bekannten Musters, das in vielen digitalen Transformationsprojekten auftritt und als „Conway’s Law“ beschrieben wird:
„Organisationen, die Systeme entwerfen (im hier verwendeten weiten Sinne), sind gezwungen, Designs zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.“ – Melvin E. Conway,
Conways Gesetz stammt zwar aus dem Jahr 1957, aber Skelton et al. zeigen seine Relevanz für heutige Organisationen in ihrem Bestseller-Buch Team Topologies. Einfach ausgedrückt: Wenn Teams miteinander kommunizieren, indem sie sich gegenseitig Tennisbälle zuspielen, wird die resultierende Softwarearchitektur für diese Art der Kommunikation optimiert sein.
Wenn wir das Conway’sche Gesetz auf unser Beispiel in der Datenwelt übertragen, können wir die folgenden drei Schlussfolgerungen ziehen:
- Die realisierte Datenplattform wird für ein zentrales Datenteam optimiert, da die Kommunikation in der derzeitigen Organisation auf diese Weise abläuft.
- Jede datengesteuerte Implementierung beinhaltet Paul, was bedeutet, dass auch die neue Datenplattform um Paul herum aufgebaut wird.
- In der derzeitigen Organisation gibt es keine Kommunikationslinien zwischen dem Datenteam und den Geschäftsteams über Datenzugriff und Datenqualität. Das bedeutet, dass die neue Datenplattform nicht für die Unterstützung von Silo-Aufgaben optimiert sein wird.
Wie kann man es besser machen?
Aus den vorangegangenen Abschnitten haben wir gelernt, dass ein technologieorientiertes Datenprojekt allein nicht das Allheilmittel ist, um alle Datenprobleme in einer Organisation zu lösen. Nach dem Conway’schen Gesetz werden dieselben kommunikationsorientierten Probleme immer wieder auftreten, allerdings mit einer anderen Technologie. Dies bedeutet eine enorme Verschwendung von Geld, Ressourcen und Zeit.
Ein Ansatz zur Verbesserung ist die Anwendung des „Reverse Conway Maneuver“ (siehe Skelton et al. und Forsgren et al.). Bei diesem Ansatz wird die Kommunikation im Team neu konfiguriert, bevor die Software fertig ist. Dieses Manöver bedeutet, dass sich der Schwerpunkt Ihres Datenprojekts von der reinen Technologie auf Menschen und Prozesse verlagert. Tatsächlich liefern Sie (einen Teil) der neuen Plattform, nachdem Sie Ihre Prozesse und die Teams, die die Plattform nutzen, umgestaltet haben.
In unserem Beispiel müssen wir die Kommunikationsleitungen wie oben beschrieben neu konfigurieren, um das Reverse Conway Maneuver zu nutzen. Nachfolgend finden Sie mehrere Beispiele für die Umsetzung dieser Strategie zur Behebung der verschiedenen Datenprobleme.
Self-Service-Berichterstattung
- Geben Sie den Geschäftsteams (oder sogar den Geschäftsbereichen) die nötige Schulung, das nötige Personal und klare Rollen und Verantwortlichkeiten, damit sie ihre eigenen Berichte erstellen können.
- Sobald die Teams bereit sind, führen Sie sie in Ihre Self-Service-Daten-Tools ein.
- Überwachen und ermitteln Sie zusätzliche Schritte, die erforderlich sind, um die gewünschte Vorlaufzeit zu erreichen.
- Wenn Teams häufig durch fehlende technische Fähigkeiten blockiert sind, sollten Sie Dateningenieure in diese Teams integrieren.
- Binden Sie Dateningenieure aus den Geschäftsteams in die technischen Tools der Datenplattform ein.
Vermeiden Sie Paul
- Eliminierung der direkten Abhängigkeit von Paul, Verbot für Teams, Paul in der Projektarbeit einzusetzen.
- Paul dokumentiert sein Wissen mit Hilfe von Metadaten in einem Datenkatalog.
- Durch das Verbot der Kommunikation mit Paul werden die Business-Teams ermutigt, den Datenkatalog zu übernehmen, um ihre Anwendungsfälle zu realisieren.
Datenqualität und Zugriffsmanagement
- Definieren Sie eindeutige Datenverantwortliche, die für Datenzugriffsrechte und ‑qualität verantwortlich sind.
- Ernennung von Datenverantwortlichen, die für das Management von Datenqualitätsproblemen zuständig sind.
- Implementierung eines Datenzugriffsprozesses, bei dem die Datenverantwortlichen Zugriffsanfragen genehmigen und dabei die Grundsätze des geringstmöglichen Rechtsschutzes gewährleisten.
Schlussfolgerungen
Um einen Mehrwert aus Daten zu erzielen, müssen Datenprojekte über die Datentechnologie hinausgehen. Prozesse und Tools sollten berücksichtigt werden, um die Organisation für eine zukunftssichere datengesteuerte Arbeitsweise zu gestalten. Wie im umgekehrten Conway-Manöver beschrieben, wäre es von Vorteil, Ihre Organisation zu gestalten, bevor die Implementierung Ihrer Datenplattform abgeschlossen ist. Dies hilft Ihnen, die optimale Datenarchitektur zu schaffen, die der Art und Weise entspricht, wie Sie arbeiten möchten. Inspirationen für optimale Datenprozesse und Organisationsstrukturen finden Sie im Bereich Data Governance und Data Management, zum Beispiel im DAMA DMBOK.
Ich bin überzeugt, dass das Reverse Conway Maneuver die Einführung und Gestaltung neuer Systeme fördert. Allerdings stellt sich für mich die Frage, welche Auswirkungen es hat, Datenplattformen zu kaufen und zu konfigurieren, anstatt sie selbst zu bauen. Mit dem erstgenannten Ansatz könnten Unternehmen beispielsweise Software kaufen, die eine bestimmte Arbeitsweise erzwingt (z. B. ein Datennetz). Ich glaube, dass es in diesem Fall weniger sinnvoll ist, die organisatorische Umgestaltung kurz vor oder kurz nach der Bereitstellung der Plattform vorzunehmen.
Dieser Artikel gab zwar einige Hinweise darauf, wie ein Datenprojekt besser geplant werden kann, aber es bleiben noch einige offene Fragen zu klären:
- Wissen wir, wie die optimale datengesteuerte Arbeitsweise für unsere Organisation aussehen wird? Wenn wir das nicht wissen, wird es sehr schwer sein, die Organisation und die Prozesse vorher zu gestalten.
- Wie tauscht man den Motor eines Flugzeugs aus, während das Flugzeug weiterfliegen soll? Diese Metapher erklärt die Komplexität des Veränderungsmanagements bei der Einführung einer neuen datengesteuerten Arbeitsweise. Wir können nicht alles auf Eis legen, bis alle mit der neuen Arbeitsweise vertraut sind; wir brauchen einen klügeren Ansatz für das Änderungsmanagement.
Um diese Fragen zu beantworten, muss eine Datenstrategie definiert werden, die Ihre Geschäftsstrategie unterstützt, und zwar in Verbindung mit den geeigneten Verfahren für das Änderungsmanagement. In einer Reihe von Folgeartikeln werde ich Themen wie Datenstrategie und Änderungsmanagement näher beleuchten, um diese Fragen zu beantworten.
Abschließend lässt sich sagen, dass Technologie allein nicht ausreicht, um ein datengesteuertes Unternehmen zu werden; Ihre Technologie funktioniert nur mit den richtigen Menschen und Prozessen. Andererseits ist die Technologie immer noch ein sehr wichtiges Teil des Puzzles. Der Kauf (oder die Entwicklung) der richtigen Datenplattform-Software, die Ihre künftige Arbeitsweise und damit Ihre Datenstrategie unterstützt, bleibt ein unumgängliches Puzzleteil. Eine Reorganisation Ihrer Arbeitsweise ohne eine ausgereifte Datentechnologie wird die Probleme Ihres Unternehmens ebenfalls nicht lösen.
Quelle: medium.com