Ein Dashboard, dem der Inhaber nicht glaubte: 13 618 bezahlte Bestellungen fehlten
Warum eine Zahl ohne Angabe, was sie enthält, schlimmer ist als keine Zahl – und was wir beim Umbau bewusst weggelassen haben
· 4 Min. · App-Entwicklung, Datenqualität, Projektpraxis
Ein Dashboard ist nur so viel wert wie das Vertrauen in seine Zahlen. Bei einer Unternehmensgruppe aus Lebensmittelproduktion und Filialhandel sah der Inhaber eine Zahl, die er selbst als zu niedrig erkannte. Die Prüfung ergab: Die Bestellungen der beiden Onlineshops wurden überhaupt nicht gezählt, für einen Geschäftsbereich blieb der Bildschirm sogar leer.
Das Dashboard und die Zahl, die nicht stimmte
Die Übersicht war dafür gedacht, dem Inhaber jeden Morgen zu zeigen, wie die Geschäftsbereiche laufen. Sie las ihre Zahlen aus dem Bestelljournal, in dem die Großhandelsaufträge erfasst werden. Das war zu dem Zeitpunkt, als die Übersicht entstand, eine vernünftige Quelle, denn der Großhandel war das Hauptgeschäft.
Inzwischen verkaufte die Gruppe aber auch über zwei eigene Onlineshops, und diese Bestellungen landeten nicht im Journal, sondern in den Datenbanken der Shops. Die Übersicht wusste davon nichts. Es zeigte 3 936 bezahlte Online-Bestellungen, obwohl in den Shops insgesamt 17 554 bezahlte Warenkörbe lagen. Die Differenz, 13 618 Bestellungen, war auf keinem Bildschirm sichtbar.
Das Bemerkenswerte ist nicht die Lücke selbst, sondern wie sie auffiel. Kein Test schlug an, keine Fehlermeldung erschien. Der Inhaber kannte sein Geschäft und merkte, dass die Zahl zu klein war. Ohne dieses Gefühl hätte der Bildschirm weiter eine falsche Wirklichkeit gezeigt, mit sauberem Layout und sicher wirkenden Diagrammen.
Warum die Lücke niemandem auffiel
Die Ursache war kein Programmierfehler im engeren Sinn. Der Code tat genau, was er sollte: Er zählte das Journal. Das Problem lag darin, dass nirgends stand, was gezählt wird. Die Überschrift lautete sinngemäß »Bestellungen«, nicht »Großhandelsbestellungen aus dem Journal«. Wer den Bildschirm ansah, musste annehmen, alle Verkäufe zu sehen.
Solche Lücken entstehen in fast jedem Unternehmen, das wächst. Ein neuer Vertriebsweg kommt hinzu, ein Geschäftsbereich wird ausgegründet, eine zweite Währung taucht auf. Die Auswertung wird nicht mitgezogen, weil niemand sie als Anwendung mit eigener Pflege betrachtet, sondern als fertigen Bildschirm.
Was wir am Dashboard geändert haben
Der Umbau hatte drei Teile, und nur einer davon war die eigentliche Datenanbindung.
Erstens die Quellen. Die Übersicht liest jetzt zusätzlich die bezahlten Bestellungen beider Onlineshops. Welche Bestellstatus als bezahlt gelten, ist festgelegt und nicht dem Zufall überlassen.
Zweitens die Sichtbarkeit. Der Bildschirm hat zwei Bereiche mit getrenntem Sichtbarkeitsumfang. Die Produktionsblöcke bleiben dem jeweiligen Geschäftsbereich vorbehalten, die Website-Verkäufe folgen der gewählten Sparte. Ein Mitarbeiter, der nur für eine Sparte zuständig ist, sieht weiterhin ausschließlich seine eigenen Zahlen. Gerade bei einem Umbau, der mehr Daten auf einen Bildschirm bringt, ist diese Grenze leicht zu verletzen; sie ist deshalb mit 319 Prüfungen und einem Mutations-Prüfstand abgesichert, der alle 16 absichtlich eingebauten Fehler erkannt hat.
Drittens die Beschriftung. Unter der Tabelle steht, welche Shops und welche Bestellstatus enthalten sind. Das klingt nach einer Kleinigkeit und war der wichtigste Teil. Die nächste Lücke, etwa ein dritter Shop, wird dadurch nicht verhindert, aber sie wird sichtbar, weil die Beschriftung ihn nicht nennt.
Das Ergebnis: Der Inhaber sieht jetzt 17 554 bezahlte Online-Bestellungen statt 3 936, aufgeschlüsselt nach Geschäft und Währung. Wie ein solcher Umbau als Projekt beschrieben und geprüft wird, erklärt die Seite App-Entwicklung.
Was wir bewusst nicht gebaut haben
Die naheliegende Erweiterung wäre eine Gesamtsumme über alle Shops gewesen, umgerechnet in eine Währung. Wir haben sie nicht gebaut. Die Shops verkaufen in unterschiedlichen Währungen, und der Inhaber gleicht die Zahlen regelmäßig mit den Verwaltungsoberflächen der Shops ab. Eine umgerechnete Summe hätte bei jedem Abgleich eine zweite Rechnung verlangt: Welcher Kurs, von welchem Tag, und warum weicht das vom Shop ab?
Deshalb steht jede Zeile für sich, in ihrer eigenen Währung und ohne Umrechnung. Das ist weniger elegant als eine große Zahl oben rechts. Es ist aber die Form, in der der Inhaber die Zahlen tatsächlich prüfen kann. Die Einschränkung hat einen Preis: Wer die Gesamtlage in einer Zahl sehen will, muss selbst addieren. Diese Entscheidung haben wir mit ihm getroffen und nicht für ihn.
Was daraus für jede interne Anwendung folgt
Aus dem Fall lassen sich drei Regeln ableiten, die wir seither bei jeder Auswertung anwenden. Jede Zahl sagt, was sie enthält und was nicht. Jede neue Datenquelle im Unternehmen löst die Frage aus, welche Übersichten davon betroffen sind. Und wer auf einem Bildschirm etwas sieht, sieht nur, was er sehen darf, auch nachdem der Bildschirm erweitert wurde.
Die dritte Regel gehört vor den Entwurf, nicht in die Nacharbeit. Welche Rollen was sehen, steht bei uns im Lastenheft oder im Angebot und wird bei der Abnahme geprüft, zusammen mit der Frage, woher jede Zahl kommt. Eine solche Übersicht ist damit keine Grafik, sondern eine Anwendung mit Datenmodell, Rechten und Pflege, und genau so bauen wir es.
Weitere Beiträge
Was soll bei Ihnen laufen, das heute nicht läuft?
Erzählen Sie uns, welcher Ablauf heute an einer Tabelle, an E-Mails oder an einer einzelnen Person hängt. Im Gespräch klären wir, ob eine Anwendung, eine KI-Lösung oder keins von beiden der richtige Schritt ist.