Anforderungen sind noch kein geschäftlicher Nutzen

Genau das hat mir einmal ein Kunde in einem Workshop entgegengehalten. Schließlich beginne jedes klassische Datenprojekt mit den Anforderungen des Fachbereichs.

Das stimmt. Nur sind Anforderungen des Fachbereichs und geschäftlicher Nutzen nicht dasselbe.

Anforderungen beschreiben meist, was der Fachbereich haben möchte: einen Report, eine Kennzahl, eine Schnittstelle oder ein Datenprodukt. Sie sagen noch nicht, welche Entscheidung dadurch besser wird, wer anschließend anders handelt oder woran der Nutzen erkennbar wird.

Die Anforderung gilt trotzdem oft als Nachweis des Nutzens. Doch sobald das Projekt beginnt, wandert die Aufmerksamkeit zu Quellsystemen, Datenmodellen, Qualität, Ownership und Plattformen.

Um den versprochenen Nutzen zu klären, müsste das Datenteam jetzt Prozesskenner, Entscheider und spätere Nutzer zusammenbringen. Es könnte das Gespräch anstoßen. Aber hat es dafür das Mandat? Darf es eine Bereichsleitung nach ihren Entscheidungen fragen? Was, wenn die Fragen naiv wirken – oder sichtbar wird, dass niemand eine klare Antwort hat?

So beginnt die Arbeit dort, wo Rollen und Sprache vertraut sind: bei Quellen, Aktualität und Prüfregeln. Das Datenteam bleibt bei seinem Auftrag, der Fachbereich schützt seine Zeit und das Management hält den Nutzen für geklärt.

Niemand handelt unvernünftig. Die Organisation verwandelt einen ungeklärten Konflikt in ein planbares Datenprojekt.

Das entlastet alle. Das Datenteam kann liefern. Der Fachbereich muss nicht festlegen, was er künftig anders macht. Das Management muss keine Prioritäten verschieben.

So kann ein Datenprodukt pünktlich bereitstehen, alle Qualitätsregeln erfüllen und einen Owner haben. Trotzdem entscheidet oder handelt niemand anders als vorher.

Wer Datenarbeit wirklich vom Nutzen her steuern will, braucht deshalb mehr als einen Business Case. Es braucht ein festes Vorgehen, in dem drei Fragen geklärt werden:

• Was soll besser oder neu möglich werden?
• Wer muss dafür anders entscheiden oder handeln?
• Wer übernimmt den Betrieb und trägt die Folgen?

Nutzen kann mehr Umsatz bedeuten, aber auch weniger Risiko, schnelleres Lernen, erfüllte Vorgaben oder eine mehrfach nutzbare Grundlage. Entscheidend ist, dass er konkret genug ist, um das Projekt zu steuern.

Erst daraus folgen Informationen, Daten, Qualitätsanforderungen, Verantwortlichkeiten und technische Lösungen.

Governance muss deshalb mehr sein als ein Regelwerk für Daten. Sie sorgt dafür, dass Nutzen, Entscheidungen, Daten und Verantwortung zusammenpassen und nach neuen Erfahrungen überprüft werden.

Solange es dafür kein Mandat und kein festes Vorgehen gibt, beginnt Datenarbeit weiter bei den Daten – ganz gleich, was auf der ersten Folie steht.