Heute war ich wieder für einen Workshop vor Ort bei einem meiner Lieblingskunden.
Okay, zugegeben: Ich habe eigentlich nur Lieblingskunden. Aber bei solchen Projekten ist es mir wirklich wichtig, dass wir partnerschaftlich auf Augenhöhe arbeiten. Denn dann bringe nicht nur ich meine Erfahrung mit, sondern bekomme gleichzeitig Einblicke in die tägliche Realität einer Organisation, die pragmatisch nach vorne will. Nicht im Hochglanz-Konzern, sondern im Mittelstand. Dort, wo Entscheidungen, Verantwortung und Umsetzung oft noch nah beieinanderliegen.
Genau darum ging es auch in diesem Workshop: um die gemeinsame Entwicklung eines zukünftigen Vorgehensmodells für KPI-Anforderungen, Kennzahlen, Dashboards und Reporting-Prozesse.
Worum es im Kern ging
Der Anlass war zunächst praktisch. Eine Organisation braucht ein sauberes Vorgehen für die Frage, wie KPI-Anforderungen entstehen, wer sie fachlich verantwortet und wie daraus am Ende eine umsetzbare Spezifikation wird.
Im Raum standen deshalb vor allem zwei Fragen:
- Welche Rolle übernimmt das Reporting-Team?
- Wo beginnt und endet die Verantwortung der Global Key User?
Aus diesen Fragen wurde kein abstraktes Governance-Konstrukt, sondern ein gemeinsames Rollen- und Prozessverständnis entwickelt. Dabei wurden auch das Executive Board, die Global Functions, die Global Key User und das Reporting Team in einen klaren Ablauf eingeordnet.
Das ist mehr als eine Organigrammfrage. Es ist die eigentliche Voraussetzung dafür, dass KPI-Arbeit nicht im Nebel aus Zuständigkeiten stecken bleibt.
Das Vorgehensmodell im Überblick
Das gemeinsame Modell sah im Kern so aus:
Was an diesem Prozess sofort sichtbar wird: Die KPI entsteht nicht einfach im Reporting-Team und auch nicht im Dashboard. Sie entsteht in einem abgestuften Zusammenspiel aus fachlicher Anforderung, technischer Machbarkeit, fachlicher Prüfung und Freigabe.
Was das Modell fachlich klärt
Der wahrscheinlich wichtigste Punkt in solchen Vorhaben ist nicht die Frage, wie viele Kennzahlen entstehen.
Die wichtigere Frage lautet: Wer trägt welche Verantwortung?
Das Reporting-Team bringt Wissen über die vorhandene Datenplattform mit. Es weiß, welche Daten bereits verfügbar sind, welche Informationen technisch realistisch umsetzbar sind und wo die Grenzen liegen. Genau deshalb ist das Team in der Spezifikation wichtig. Aber es ist nicht die Instanz, die fachlich entscheidet, was eine KPI im jeweiligen Verantwortungsbereich bedeuten soll.
Diese Verantwortung liegt woanders:
- Die Global Key User prüfen, ob die fachliche Umsetzung den Bedarf wirklich trifft.
- Die Global Functions geben die fachliche Richtung vor und holen die Freigabe ein.
- Das Executive Board gibt die Steuerungsanforderung vor.
Die Trennung ist wichtig, weil sonst schnell ein bekanntes Muster entsteht: Das Reporting-Team wird zur fachlichen Ersatzinstanz, obwohl es eigentlich technische und datenbezogene Kompetenz einbringt. Gleichzeitig bleibt die Fachseite unscharf, obwohl genau dort die eigentliche Verantwortung liegt.
Der eigentliche Wert: gemeinsame Sprache
Solche Workshops sind für mich dann gut, wenn am Ende nicht nur ein Prozessdiagramm steht, sondern eine gemeinsame Sprache.
Denn in vielen Organisationen scheitern KPI-Vorhaben nicht an fehlenden Tools oder an mangelnder Technik. Sie scheitern daran, dass unterschiedliche Rollen verschiedene Erwartungen an dieselbe Zahl haben, ohne diese Erwartungen vorher sauber zu klären.
Ein KPI-Prozess muss deshalb mehr leisten als Freigabeschritte zu definieren. Er muss sichtbar machen:
- Wer fordert an?
- Wer übersetzt fachlich?
- Wer prüft technisch?
- Wer validiert fachlich?
- Wer gibt frei?
- Und wann kommt die KPI wirklich ins Live-System?
Diese Klarheit wirkt unspektakulär. Aber genau sie verhindert später teure Missverständnisse.
Aus thinkBI-Sicht ist das auch kein Nebenpunkt, sondern der Kern: Informationsbedarf folgt Verantwortung. Wer Verantwortung trägt, braucht eine andere Informationsform als jemand, der nur einen Auswertungswunsch formuliert.
Warum das im Mittelstand besonders relevant ist
Im Mittelstand liegen Entscheidungen, Verantwortung und Umsetzung oft noch näher beieinander als in großen Konzernen. Das ist eine Stärke. Aber es bedeutet auch, dass Rollen leicht vermischt werden.
Wenn dann ein Reporting-Team stillschweigend die fachliche Spezifikation übernimmt, ein Global Key User nur noch abnickt und die Global Functions die Freigabe eher formell wahrnehmen, verliert das KPI-System seine Substanz.
Dann sieht der Prozess nach Governance aus, ist aber in Wirklichkeit nur eine technische Abwicklung mit ein paar fachlichen Schleifen.
Genau das wollten wir im Workshop vermeiden.
Fazit
Das eigentliche Ergebnis des Workshops war nicht nur ein Diagramm.
Es war die Klarheit, dass KPI-Governance mit Rollenklärung beginnt und nicht mit dem ersten Dashboard.
Die Mermaid-Grafik war dabei kein schmückendes Element, sondern die nachträgliche, präzise Verdichtung einer Whiteboard-Skizze. So wurde aus einer groben Prozessidee ein pragmatisches Werkzeug, um den gemeinsamen Ablauf sichtbar, diskutierbar und weiterentwickelbar zu machen. Und manchmal ist genau das der Unterschied zwischen einer abstrakten Abstimmung und einem tragfähigen Vorgehensmodell.
