In den letz­ten Jah­ren haben viele Unter­neh­men in Daten­tech­no­lo­gie als „Kraft­mul­ti­pli­ka­tor“ für die Bereit­stel­lung von Geschäfts­wer­ten inves­tiert. Lei­der haben die meis­ten die­ser Unter­neh­men fest­ge­stellt, dass Tech­no­lo­gie allein keine magi­sche Lösung für büro­kra­ti­sche Daten­pro­zesse, eine inef­fi­zi­ente Daten­team­struk­tur oder einen Man­gel an Daten­wis­sen und ‑begeis­te­rung inner­halb des Unter­neh­mens ist. Aus die­sem Grund wer­den selbst die fort­schritt­lichs­ten Daten­platt­for­men oft nicht voll aus­ge­schöpft. Zusam­men­fas­send lässt sich sagen, dass wir die Daten­tech­no­lo­gie als Mit­tel und nicht als Zweck sehen sollten.

In die­sem Arti­kel wird näher beleuch­tet, warum viele Daten­pro­jekte von vorn­her­ein schei­tern. Anhand eines Bei­spiels zeige ich, dass die allei­nige Betrach­tung von Daten­pro­jek­ten unter tech­no­lo­gi­schen Gesichts­punk­ten nicht aus­reicht, um nach­hal­tige Werte zu schaf­fen. Als Nächs­tes führe ich das Conway’sche Gesetz ein, um die zugrun­de­lie­gen­den Mus­ter zu ver­an­schau­li­chen, die diese Miss­erfolge maß­geb­lich beein­flus­sen. Im letz­ten Teil des Arti­kels gehe ich der Frage nach, wie die Ergeb­nisse ver­bes­sert wer­den kön­nen, indem ein brei­te­rer Fokus auf die daten­ge­steu­er­ten Fähig­kei­ten des Unter­neh­mens gelegt wird.

Schei­tern von Daten­pro­jek­ten: Ein Beispiel

Viele Unter­neh­men begin­nen ihre daten­ge­steu­erte Reise mit der Defi­ni­tion eines „Daten­pro­jekts“. Diese Pro­jekte haben oft den Ehr­geiz, neue daten­ge­steu­erte Fähig­kei­ten inner­halb der Orga­ni­sa­tion zu rea­li­sie­ren. Ich stelle jedoch fest, dass viele die­ser Pro­jekte zum Schei­tern ver­ur­teilt sind und die­ses Ziel nie errei­chen werden!

Um dies zu ver­an­schau­li­chen, betrach­ten wir eine Orga­ni­sa­tion, die heute mit den fol­gen­den Pro­ble­men kon­fron­tiert ist:

  • Lange und unvor­her­seh­bare Daten­vor­lauf­zeit: Alle Berichte wer­den von einem zen­tra­li­sier­ten Berichts­team erstellt. Die Geschäfts­teams lei­ten ihre Anfor­de­run­gen an die­ses Berichts­team wei­ter, das die benö­tig­ten Berichte imple­men­tiert und bereit­stellt. Die Prio­ri­tä­ten zwi­schen dem Berichts­team und den Geschäfts­teams sind nicht auf­ein­an­der abge­stimmt, was zu einer lan­gen und unvor­her­seh­ba­ren Vor­lauf­zeit führt.
  • Schat­ten­be­richt­erstat­tung: Auf­grund der lan­gen Vor­lauf­zeit begin­nen die Geschäfts­teams, ihre eige­nen Berichte in Tabel­len­kal­ku­la­tio­nen zu erstel­len. Diese Berichte wer­den anhand von Expor­ten aus den Quell­an­wen­dun­gen oder sogar anhand von Expor­ten aus einer Viel­zahl von bestehen­den Berich­ten erstellt.
  • Nur Paul weiß Bescheid: Es gibt kaum Doku­men­ta­tion über Daten und den Daten­fluss von der Quelle zum Ziel. Zum Glück gibt es Paul, der aus­wen­dig weiß, wie jeder Fluss funk­tio­niert. Lei­der kann Paul nicht alle Bälle in der Luft hal­ten. Pauls Ver­füg­bar­keit ist ein Eng­pass für viele Lieferinitiativen.
  • Unzu­ver­läs­sige KPIs: Das Manage­ment­team steu­ert über ein zen­tra­les KPI-Dash­board. Lei­der muss jeder KPI mit Vor­sicht inter­pre­tiert wer­den. Ent­we­der steht die KPI-Defi­ni­tion jedes Mal zur Debatte, wenn wir sie öff­nen, oder die Daten, die die­sem KPI zugrunde lie­gen, ent­hal­ten Daten­qua­li­täts­pro­bleme, die die Zahl erheb­lich beein­flus­sen. Ein KPI, der die Anzahl der Kun­den anzeigt, weist bei­spiels­weise 20 % zu viele Kun­den aus, weil es in einem Quell­sys­tem zu uner­wünsch­ten Daten­dopp­lun­gen gekom­men ist.
  • Unbe­kann­ter Daten­zu­griff: Der Zugriff auf die Daten erfolgt durch ein zen­tra­les Ser­vice-Desk-Team. Die­ses Team weiß nicht, wer Zugriff auf wel­che Berichte oder wel­che Teile der zugrunde lie­gen­den Daten­bank hat. Infol­ge­des­sen gewäh­ren sie jedem Zugriff auf die ange­for­der­ten Daten, ohne zu wis­sen, ob dies sinn­voll ist oder nicht. Die Daten­zu­griffs­rechte wer­den nie überprüft.
  • Die Inno­va­tion bleibt ste­cken: Da das zen­tra­li­sierte Berichts­team mit den Berichts­an­for­de­run­gen voll aus­ge­las­tet ist, bleibt keine Zeit für Inno­va­tio­nen. Sie kon­zen­trie­ren sich dar­auf, alles am Lau­fen zu hal­ten. Geschäfts­an­fra­gen zu Neue­run­gen wie künst­li­cher Intel­li­genz oder unstruk­tu­rier­ten Daten wer­den auf­grund man­geln­der Res­sour­cen zurückgestellt.

Ein Pro­jekt definieren

Nach einer Weile began­nen die oben beschrie­be­nen Pro­bleme zu eska­lie­ren, was zur Defi­ni­tion eines „Daten­pro­jekts“ führte. Die­ses Pro­jekt würde eine neue, hoch­mo­derne Daten­platt­form ein­füh­ren, mit der das Unter­neh­men den Sprung ins 21. Jahr­hun­dert schafft. Die Geschäfts­teams wer­den sogar die Mög­lich­keit erhal­ten, „Self-Ser­vice-Report­ing“ zu nut­zen. Der Pro­jekt­plan und die Road­map wur­den fer­tig­ge­stellt, ein Team von Ent­wick­lern an Bord geholt, und die Arbeit kann beginnen!

Nach­wir­kun­gen

Machen wir nun einen Zeit­sprung nach dem opti­mis­ti­schen (aber auch unrea­lis­ti­schen) Sze­na­rio der „erfolg­rei­chen Lie­fe­rung“ und der pünkt­li­chen Bereit­stel­lung der Daten­platt­form. Diese neue Platt­form würde die Daten­schmer­zen des Unter­neh­mens in Daten­ge­winne ver­wan­deln! Lei­der war dies nicht der Fall:

  • Lange und unvor­her­seh­bare Daten­vor­lauf­zeit: Self-Ser­vice-Report­ing ist ver­füg­bar, aber die Geschäfts­teams sind bei der Daten­ein­gabe und ‑aufbereitung immer noch auf das zen­trale Daten­team ange­wie­sen. Unaus­ge­wo­gene Prio­ri­tä­ten füh­ren wei­ter­hin zu Verzögerungen.
  • Schat­ten­be­richt­erstat­tung: Wäh­rend die Ver­wen­dung von Tabel­len­kal­ku­la­tio­nen zurück­ge­gan­gen ist, exis­tie­ren nun meh­rere Ver­sio­nen des­sel­ben Berichts im Berichts­por­tal, was zu unkon­trol­lier­ten Schat­ten­be­rich­ten in einem ande­ren Tool führt.
  • Nur Paul weiß Bescheid: Paul ist nach wie vor unver­zicht­bar, um sich auf der neuen Platt­form zurecht­zu­fin­den. Sein Wis­sen ist immer noch ein Eng­pass für Innovationen.
  • Unzu­ver­läs­sige KPIs: Vor­über­ge­hende Ver­bes­se­run­gen der Daten­qua­li­tät wäh­rend des Pro­jekts waren nicht von Dauer. Anhal­tende Daten­ein­ga­be­feh­ler füh­ren zu neuen Qua­li­täts­pro­ble­men, was wie­derum zu unzu­ver­läs­si­gen KPIs führt.
  • Unbe­kann­ter Daten­zu­griff: Die neue Platt­form ver­fügt über gra­nu­lare Zugriffs­kon­trol­len, aber das Ser­vice-Desk-Team gewährt wei­ter­hin Zugriff, ohne sich rich­tig aus­zu­ken­nen, und folgt dabei dem­sel­ben feh­ler­haf­ten Prozess.
  • Inno­va­tion bleibt ste­cken: Trotz der Mög­lich­kei­ten der neuen Platt­form wird die Inno­va­tion immer noch durch die Abhän­gig­keit von Paul, anhal­tende Pro­bleme mit der Daten­qua­li­tät und die Unge­wiss­heit über den Daten­zu­griff behin­dert. Zumin­dest wird die Inno­va­tion aber nicht mehr tech­no­lo­gisch blockiert.

Conway’s Law

Was wir in die­sem Bei­spiel sehen, ist das Ergeb­nis eines bekann­ten Mus­ters, das in vie­len digi­ta­len Trans­for­ma­ti­ons­pro­jek­ten auf­tritt und als „Conway’s Law“ beschrie­ben wird:

„Orga­ni­sa­tio­nen, die Sys­teme ent­wer­fen (im hier ver­wen­de­ten wei­ten Sinne), sind gezwun­gen, Designs zu pro­du­zie­ren, die Kopien der Kom­mu­ni­ka­ti­ons­struk­tu­ren die­ser Orga­ni­sa­tio­nen sind.“ – Mel­vin E. Conway, 

Con­ways Gesetz stammt zwar aus dem Jahr 1957, aber Skel­ton et al. zei­gen seine Rele­vanz für heu­tige Orga­ni­sa­tio­nen in ihrem Best­sel­ler-Buch Team Topo­lo­gies. Ein­fach aus­ge­drückt: Wenn Teams mit­ein­an­der kom­mu­ni­zie­ren, indem sie sich gegen­sei­tig Ten­nis­bälle zuspie­len, wird die resul­tie­rende Soft­ware­ar­chi­tek­tur für diese Art der Kom­mu­ni­ka­tion opti­miert sein.

Wenn wir das Conway’sche Gesetz auf unser Bei­spiel in der Daten­welt über­tra­gen, kön­nen wir die fol­gen­den drei Schluss­fol­ge­run­gen ziehen:

  • Die rea­li­sierte Daten­platt­form wird für ein zen­tra­les Daten­team opti­miert, da die Kom­mu­ni­ka­tion in der der­zei­ti­gen Orga­ni­sa­tion auf diese Weise abläuft.
  • Jede daten­ge­steu­erte Imple­men­tie­rung beinhal­tet Paul, was bedeu­tet, dass auch die neue Daten­platt­form um Paul herum auf­ge­baut wird.
  • In der der­zei­ti­gen Orga­ni­sa­tion gibt es keine Kom­mu­ni­ka­ti­ons­li­nien zwi­schen dem Daten­team und den Geschäfts­teams über Daten­zu­griff und Daten­qua­li­tät. Das bedeu­tet, dass die neue Daten­platt­form nicht für die Unter­stüt­zung von Silo-Auf­ga­ben opti­miert sein wird.

Wie kann man es bes­ser machen?

Aus den vor­an­ge­gan­ge­nen Abschnit­ten haben wir gelernt, dass ein tech­no­lo­gie­ori­en­tier­tes Daten­pro­jekt allein nicht das All­heil­mit­tel ist, um alle Daten­pro­bleme in einer Orga­ni­sa­tion zu lösen. Nach dem Conway’schen Gesetz wer­den die­sel­ben kom­mu­ni­ka­ti­ons­ori­en­tier­ten Pro­bleme immer wie­der auf­tre­ten, aller­dings mit einer ande­ren Tech­no­lo­gie. Dies bedeu­tet eine enorme Ver­schwen­dung von Geld, Res­sour­cen und Zeit.

Ein Ansatz zur Ver­bes­se­rung ist die Anwen­dung des „Reverse Con­way Maneu­ver“ (siehe Skel­ton et al. und Fors­gren et al.). Bei die­sem Ansatz wird die Kom­mu­ni­ka­tion im Team neu kon­fi­gu­riert, bevor die Soft­ware fer­tig ist. Die­ses Manö­ver bedeu­tet, dass sich der Schwer­punkt Ihres Daten­pro­jekts von der rei­nen Tech­no­lo­gie auf Men­schen und Pro­zesse ver­la­gert. Tat­säch­lich lie­fern Sie (einen Teil) der neuen Platt­form, nach­dem Sie Ihre Pro­zesse und die Teams, die die Platt­form nut­zen, umge­stal­tet haben.

In unse­rem Bei­spiel müs­sen wir die Kom­mu­ni­ka­ti­ons­lei­tun­gen wie oben beschrie­ben neu kon­fi­gu­rie­ren, um das Reverse Con­way Maneu­ver zu nut­zen. Nach­fol­gend fin­den Sie meh­rere Bei­spiele für die Umset­zung die­ser Stra­te­gie zur Behe­bung der ver­schie­de­nen Datenprobleme.

Self-Ser­vice-Bericht­erstat­tung

  • Geben Sie den Geschäfts­teams (oder sogar den Geschäfts­be­rei­chen) die nötige Schu­lung, das nötige Per­so­nal und klare Rol­len und Ver­ant­wort­lich­kei­ten, damit sie ihre eige­nen Berichte erstel­len können.
  • Sobald die Teams bereit sind, füh­ren Sie sie in Ihre Self-Ser­vice-Daten-Tools ein.
  • Über­wa­chen und ermit­teln Sie zusätz­li­che Schritte, die erfor­der­lich sind, um die gewünschte Vor­lauf­zeit zu erreichen.
  • Wenn Teams häu­fig durch feh­lende tech­ni­sche Fähig­kei­ten blo­ckiert sind, soll­ten Sie Daten­in­ge­nieure in diese Teams integrieren.
  • Bin­den Sie Daten­in­ge­nieure aus den Geschäfts­teams in die tech­ni­schen Tools der Daten­platt­form ein.

Ver­mei­den Sie Paul

  • Eli­mi­nie­rung der direk­ten Abhän­gig­keit von Paul, Ver­bot für Teams, Paul in der Pro­jekt­ar­beit einzusetzen.
  • Paul doku­men­tiert sein Wis­sen mit Hilfe von Meta­da­ten in einem Datenkatalog.
  • Durch das Ver­bot der Kom­mu­ni­ka­tion mit Paul wer­den die Busi­ness-Teams ermu­tigt, den Daten­ka­ta­log zu über­neh­men, um ihre Anwen­dungs­fälle zu realisieren.

Daten­qua­li­tät und Zugriffsmanagement

  • Defi­nie­ren Sie ein­deu­tige Daten­ver­ant­wort­li­che, die für Daten­zu­griffs­rechte und ‑qua­li­tät ver­ant­wort­lich sind.
  • Ernen­nung von Daten­ver­ant­wort­li­chen, die für das Manage­ment von Daten­qua­li­täts­pro­ble­men zustän­dig sind.
  • Imple­men­tie­rung eines Daten­zu­griffs­pro­zes­ses, bei dem die Daten­ver­ant­wort­li­chen Zugriffs­an­fra­gen geneh­mi­gen und dabei die Grund­sätze des geringst­mög­li­chen Rechts­schut­zes gewährleisten.

Schluss­fol­ge­run­gen

Um einen Mehr­wert aus Daten zu erzie­len, müs­sen Daten­pro­jekte über die Daten­tech­no­lo­gie hin­aus­ge­hen. Pro­zesse und Tools soll­ten berück­sich­tigt wer­den, um die Orga­ni­sa­tion für eine zukunfts­si­chere daten­ge­steu­erte Arbeits­weise zu gestal­ten. Wie im umge­kehr­ten Con­way-Manö­ver beschrie­ben, wäre es von Vor­teil, Ihre Orga­ni­sa­tion zu gestal­ten, bevor die Imple­men­tie­rung Ihrer Daten­platt­form abge­schlos­sen ist. Dies hilft Ihnen, die opti­male Daten­ar­chi­tek­tur zu schaf­fen, die der Art und Weise ent­spricht, wie Sie arbei­ten möch­ten. Inspi­ra­tio­nen für opti­male Daten­pro­zesse und Orga­ni­sa­ti­ons­struk­tu­ren fin­den Sie im Bereich Data Gover­nance und Data Manage­ment, zum Bei­spiel im DAMA DMBOK.

Ich bin über­zeugt, dass das Reverse Con­way Maneu­ver die Ein­füh­rung und Gestal­tung neuer Sys­teme för­dert. Aller­dings stellt sich für mich die Frage, wel­che Aus­wir­kun­gen es hat, Daten­platt­for­men zu kau­fen und zu kon­fi­gu­rie­ren, anstatt sie selbst zu bauen. Mit dem erst­ge­nann­ten Ansatz könn­ten Unter­neh­men bei­spiels­weise Soft­ware kau­fen, die eine bestimmte Arbeits­weise erzwingt (z. B. ein Daten­netz). Ich glaube, dass es in die­sem Fall weni­ger sinn­voll ist, die orga­ni­sa­to­ri­sche Umge­stal­tung kurz vor oder kurz nach der Bereit­stel­lung der Platt­form vorzunehmen.

Die­ser Arti­kel gab zwar einige Hin­weise dar­auf, wie ein Daten­pro­jekt bes­ser geplant wer­den kann, aber es blei­ben noch einige offene Fra­gen zu klären:

  • Wis­sen wir, wie die opti­male daten­ge­steu­erte Arbeits­weise für unsere Orga­ni­sa­tion aus­se­hen wird? Wenn wir das nicht wis­sen, wird es sehr schwer sein, die Orga­ni­sa­tion und die Pro­zesse vor­her zu gestalten.
  • Wie tauscht man den Motor eines Flug­zeugs aus, wäh­rend das Flug­zeug wei­ter­flie­gen soll? Diese Meta­pher erklärt die Kom­ple­xi­tät des Ver­än­de­rungs­ma­nage­ments bei der Ein­füh­rung einer neuen daten­ge­steu­er­ten Arbeits­weise. Wir kön­nen nicht alles auf Eis legen, bis alle mit der neuen Arbeits­weise ver­traut sind; wir brau­chen einen klü­ge­ren Ansatz für das Änderungsmanagement.

Um diese Fra­gen zu beant­wor­ten, muss eine Daten­stra­te­gie defi­niert wer­den, die Ihre Geschäfts­stra­te­gie unter­stützt, und zwar in Ver­bin­dung mit den geeig­ne­ten Ver­fah­ren für das Ände­rungs­ma­nage­ment. In einer Reihe von Fol­ge­ar­ti­keln werde ich The­men wie Daten­stra­te­gie und Ände­rungs­ma­nage­ment näher beleuch­ten, um diese Fra­gen zu beantworten.

Abschlie­ßend lässt sich sagen, dass Tech­no­lo­gie allein nicht aus­reicht, um ein daten­ge­steu­er­tes Unter­neh­men zu wer­den; Ihre Tech­no­lo­gie funk­tio­niert nur mit den rich­ti­gen Men­schen und Pro­zes­sen. Ande­rer­seits ist die Tech­no­lo­gie immer noch ein sehr wich­ti­ges Teil des Puz­zles. Der Kauf (oder die Ent­wick­lung) der rich­ti­gen Daten­platt­form-Soft­ware, die Ihre künf­tige Arbeits­weise und damit Ihre Daten­stra­te­gie unter­stützt, bleibt ein unum­gäng­li­ches Puz­zle­teil. Eine Reor­ga­ni­sa­tion Ihrer Arbeits­weise ohne eine aus­ge­reifte Daten­tech­no­lo­gie wird die Pro­bleme Ihres Unter­neh­mens eben­falls nicht lösen.

Quelle: medium.com