In der letzten Folge ging es um Anforderungen. Und auf diese Folge habe ich einiges an Feedback bekommen. Genau dort möchte ich heute ansetzen.
Anforderungen entstehen im Kopf und erst später auf Papier
Joachim hat beschrieben, dass er einen großen Vorteil darin sieht, selbst sein eigener Anforderer zu sein. Er kennt die Praxis. Er weiß, welche Fragen er beantworten möchte. Dadurch entstehen Dashboards, die zielgerichtet sind und gleichzeitig skalierbar auf andere Bereiche mit ähnlichen Fragestellungen. Ohne ein klares Gerüst an Grundfragen, so seine Haltung, braucht man mit der Berichtserstellung eigentlich gar nicht erst anfangen.
Harald hat einen anderen wichtigen Punkt ergänzt. Anforderungen sind keine neutrale Liste. Sie sind Entscheidungshypothesen. Jede KPI, die wir definieren, lenkt Aufmerksamkeit. Jeder Schwellenwert legt fest, wann gehandelt wird. Und was wir nicht messen, verschwindet aus dem Fokus. Mit jeder Anforderung treffen wir bereits implizite Entscheidungen. Vieles davon bleibt im Kopf. Erst wenn wir Anforderungen verschriftlichen, merken wir, wo Denkannahmen verborgen sind und wo Gestaltungsspielraum liegt.
Steuerung entsteht nicht durch Beobachtung allein, sondern erst dann, wenn klar ist: Wenn Wert X eintritt, folgt Aktion Y. Genau deshalb gehört Ownership ins Fach, dort wird Bedeutung verantwortet, nicht nur Technik umgesetzt.
Und genau hier liegt auch die Herausforderung, wie Harald ergänzt: Ideen sind häufig vorhanden, aber nicht bis zum Ende ausformuliert. Das eröffnet beratenden Gestaltungsspielraum, birgt aber gleichzeitig die Gefahr von Scope-Creep, wenn man nicht sauber strukturiert.
Christoph hat aus seiner Power-BI-Praxis einen weiteren Aspekt eingebracht: Alte Excel-Reports als Grundlage zu nutzen, schafft Vertrauen. Zahlen bleiben vergleichbar. Der Übergang wird kleiner. Die Akzeptanz steigt. Er beschreibt das weniger als radikalen Neubeginn, sondern eher als evolutiven Prozess: Erst Stabilität und Vergleichbarkeit schaffen, dann schrittweise neue Perspektiven aus dem Datenmodell entwickeln. Dashboard-Bau ist für ihn häufig eher entwickelte Praxis als langwierige Theorie, ein kontinuierlicher Verbesserungsprozess.
Und ja, das ist ein valides Argument. Aber es gibt auch die andere Seite.
Alte Excel-Reports enthalten oft Sonderlogiken, statische Werte, implizite Regeln. Dinge, die über Jahre gewachsen sind. Wenn wir diese ungeprüft in ein neues System überführen, übernehmen wir nicht nur Vertrauen, wir übernehmen auch Altlasten.
Manchmal ist der neue Bericht fachlich korrekter. Und trotzdem entsteht Unsicherheit, weil man sich vom alten nicht lösen kann. Ein Systemwechsel ist eben nicht nur ein technischer Wechsel. Er ist ein Wechsel der Systematik.
Ein Akkuschrauber funktioniert anders als ein Schraubendreher.
Wer ihn wie einen Schraubendreher benutzt, hat keinen Vorteil, sondern zusätzliche Last.
Informationsbedarf ist hierarchisch
Im Kern führt uns diese Diskussion zu einer grundsätzlichen Frage. Für wen bauen wir eigentlich Dashboards? Wenn wir Organisationen betrachten, sehen wir häufig eine Pyramidenstruktur des Informationsbedarfs.
Operative Ebene
Hier werden detaillierte Daten benötigt.
Listen, Statusinformationen, Prozessdaten.
Live-Daten sind relevant. Veränderungen müssen sofort sichtbar sein.
Das sind operative Dashboards, oft direkt im ERP-System.
Management-Ebene
Hier geht es um Verdichtung. Trends. Abweichungen.
Ad-hoc-Analysen.
Warum performt eine Sparte nicht wie erwartet?
Warum wird ein Ziel verfehlt?
Hier reichen häufig Vortagesdaten.
Hier beginnt die Stärke einer Analyseplattform.
Führungsebene
Hier stehen strategische KPIs im Fokus.
Performance-Kennzahlen. Finanzberichte. Gesamtunternehmenssicht.
Je höher die organisatorische Ebene, desto höher die Flughöhe der Information. Und genau hier entsteht ein häufiges Missverständnis. Das „Dashboard für alle“ funktioniert nicht. Die Führungsebene braucht keine operativen Detaildaten.
Der operative Mitarbeiter braucht keine Unternehmens-Gesamtperformance. Informationsbedarf folgt Verantwortung.
Und Verantwortung ist hierarchisch organisiert.
Wo gehört die Analyse hin?
Diese Überlegung führt direkt zur nächsten Frage. Wo sollte eine Auswertung stattfinden?
Gerade im Kontext von ERP-Systemen, beispielsweise im Umfeld von Dynamics 365 Business Central, wird genau diese Differenzierung deutlich. Microsoft unterscheidet klar zwischen operativen Analysen im System und weiterführender Business Intelligence auf einer separaten Plattform.
Eine Übersicht dazu findet sich hier:
„Analysen, Business Intelligence und Berichterstellung – Übersicht“
https://learn.microsoft.com/dynamics365/business-central/reports-bi-reporting?WT.mc_id=DP-MVP-5004288
Die zugehörige Darstellung der Analyse-Personas macht sehr gut sichtbar, wie unterschiedlich Informationsbedarfe je nach Rolle sind.
Wenn ich im operativen Prozess arbeite, möchte ich die Information dort sehen, wo ich arbeite. Ohne Medienbruch. Ohne Toolwechsel. Mit Live-Daten.
Wenn ich analysiere, möchte ich Verdichtung, Flexibilität, Exploration.
Wenn ich strategisch entscheide, möchte ich Klarheit und Fokus.
Das Problem entsteht, wenn wir versuchen, alles in ein einziges Artefakt zu pressen.
Die eigentliche Frage
Vielleicht ist die entscheidende Frage also nicht. Welches Tool verwenden wir?
sondern, Für welche Ebene bauen wir gerade? Und haben wir den Informationsbedarf wirklich verstanden?
Ich lade dich ein, einmal auf deine eigene Organisation zu schauen:
- Sind eure Dashboards zielgruppengerecht?
- Stellt ihr Informationen dort bereit, wo Entscheidungen getroffen werden?
- Oder versucht ihr, ein Dashboard für alle zu bauen?
Vielleicht liegt genau dort der Engpass.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
