Ich finde, dass ein Software-Lieferprozess erst richtig rund läuft, wenn wir auch die Ergebnisse unseres Tuns messen. Damit meine ich wirtschaftliche Ergebnisse, also nicht nur “Relesaes pro Monat” sondern auch “Umsatzanstieg durch ausgeliefertes Feature X” oder “Verringerte Supportkosten durch Feature Y”, oder “um x% gestiegene Kundenbindung”.

Dazu passt eigentlich der Wunsch des Managements nach einem Dashboard, oder einer täglichen (bzw. wöchentlichen) Email mit den wichtigsten Metriken. Parallel dazu gibt es das allgemeine Bedürfnis: “Unsere Organisation soll mehr datengetrieben werden”. Dashboards sind schön, täglich eine Email mit den aktuellsten Verkaufszahlen bekommen auch. Software-Entwickler haben dementsprechend schon viel Zeit damit zugebracht, für das Management Zahlen in Reports aufzubereiten.

Die andere Seite der Medaille: Monitoring, d.h. aufpassen, ob sich etwas verschlechtert. Sei es, dass der Webshop unerwartet langsam geworden ist, oder dass nicht mehr so viele Neukunden zu uns kommen wie letzten Monat. Bevor man reagiert, muss man eine Verschlechterung natürlich erstmal wahrnehmen, also messen, können.

Ich sehe in der Praxis weniger das Problem, dass zu wenig Daten und Metriken erhoben werden. Vielmehr hapert es bei der rationalen Umsetzung von Metriken in Handlungen.

Woher weiß man, dass man jetzt etwas tun muss – und sei es nur auf Ursachenforschung zu gehen? Wie tief muss die Zahl der Bestellungen pro Tag sinken, damit wir uns Sorgen machen? Ab wo nehmen wir einen plötzlichen Besucherzustrom ernst und suchen nach den Ursachen dafür (Marketingkampagnen, SEO, was auch immer)? Welche Retourenquote ist noch “normal”, und ab wo müssen wir systematisch etwas verbessern?

Hier ein Beispiel, wie es (jedenfalls nach meiner Erfahrung) vielerorts läuft:

---

Stellen Sie sich vor, Sie haben die Verantwortung für das Geschäftsergebnis aus dem Webshop Ihres Unternehmens. Es ist ein Mittwoch im Juli, und Sie bekommen ihre tägliche Email mit den Zahlen: “Gestern (Dienstag) hatten wir 63 Bestellungen.” (Ich nehme hier reale Daten aus einem öffentlich zugänglichen Ecommerce-Datensatz.)

Sie denken sich: “Moment mal, am Montag hatten wir doch noch mehr als 100 Bestellungen!”, und richtig, in der Email von gestern steht: “Montag: 127 Bestellungen”. Die Zahl hat sich also halbiert!!

Was nun? Rufen Sie die IT-Abteilung an und verlangen auf der Stelle eine Erklärung? Neulich war ja der Webshop mal ziemlich langsam geworden, aus unerfindlichen Gründen – das hat richtig Umsatz gekostet.

Oder sehen Sie nach, ob gerade irgendwo die Sommerferien begonnen haben? Vielleicht atmen Sie erstmal durch und suchen die Emails von letzter Woche raus: Letzen Montag waren es 80 Bestellungen, am Dienstag 89 Bestellungen.

Dann ist vielleicht alles nicht so schlimm, und die 127 Bestellungen vom Montag waren ein Ausreißer nach oben, vielleicht verursacht durch eine Marketingaktion? Und nur 64 Bestellungen am Dienstag können schon mal vorkommen, ohne dass gleich irgendwo etwas kaputt gegangen ist?

---

Sie sehen schon, am Ende ist man so verunsichert, dass man eher nicht reagiert. Oder vielleicht haben Sie auch das andere Extrem erlebt: eine Überreaktion auf kleinste Abweichungen.

Wie gesagt:

Die beste Metrik nützt nichts, wenn sie nicht zu sinnvollen Handlungen führt. Sei es, dass Sie aus “guten Tagen” lernen oder dass Sie “schlechte Tage” als solche erkennen und versuchen, mehr davon zu bekommen.

Die alten Hasen werden jetzt natürlich sagen: “Klar, die Bestellungen schwanken immer, man entwickelt eben im Laufe der Zeit ein Bauchgefühl dafür, wann so eine Schwankung ungewöhnlich ist.” Wirklich? Oder läuft es eher darauf hinaus, dass uns echte Probleme entgehen, während wir auf der anderen Seite viel Zeit mit der vergeblichen Ursachenforschung verschwenden?

Wer etwas quantitativer orientiert ist wird sagen: “Dann brauchen wir eben noch die Daten aus der Vergangenheit, dann sieht man schon, was Sache ist.”

Bitteschön:

Dies sind die Bestellungen der letzten Wochen, die Historie endet mit den 64 Bestellungen vom Dienstag, 6. Juli, ganz rechts. An Sonntagen sind es tendenziell wenige Bestellungen, deswegen sind die entsprechenden Datenpunkte grau. (In diesem Datensatz gibt es übrigens keine Bestellungen an Samstagen, das ist wahrscheinlich dem Umstand geschuldet, dass uns hier nur das Rechnungsdatum zur Verfügung steht.)

Wenn wir also den Zeithorizont etwas erweitern, können wir sehen, dass sowohl die Zahl vom Montag (127 Bestellungen) als auch die Zahl vom Dienstag (64) noch irgendwie innerhalb der “natürlichen Schwankungsbreite” liegen – wir haben schon größere Ausschläge gesehen.

Die meisten Metriken muss man in ihrem historischen Kontext betrachten

Sollen wir es also damit bewenden lassen und zur Tagesordnung übergehen? Nicht so schnell…

Wie gesagt, eine Metrik sollte eine Handlung bewirken, sobald sie aus dem Normbereich läuft. Dazu brauchen wir eine gute Antwort auf die Frage:

Wie groß ist die zu erwartende Schwankungsbreite?

Wenn wir die Schwankungsbreite zu eng anlegen, bekommen wir laufend Fehlalarme. Das ist dann “falsch positiv” – der Test schlägt Alarm, obwohl die Abweichung purer Zufall ist: Das Wetter ist schön oder schlecht, es ist gerade ein Fußball-Länderspiel usw. (manchmal können sie Marketing-Aktionen auch unter Rauschen verbuchen). In der Statistischen Prozesslenkung nennt man solche Schwankungen “common cause variation”.

“Falsch positiv” ist schlecht, weil Sie tätig werden (Fehlersuche betreiben, Erklärungen verlangen, den Dienstleister feuern), obwohl die Abweichung nur der normalen statistischen Schwankung Ihrer Metrik geschuldet ist.

“Falsch negativ” ist auch schlecht, denn dann hat die Veränderung eine spezielle Ursache, die wir fälschlicherweise dem puren Zufall zuschreiben. Hier verpassen wir also eine Gelegenheit, ein Problem zu finden und zu beheben. Beziehungsweise eine Gelegenheit, etwas systematisch zu verbessern (wenn z.B. Marketingkanal X gut funktioniert hat).

Wo würden Sie in der obigen Grafik den Normbereich festlegen?

Matthias Berth