Wie misst man „Erfolg“? (Teil 2)

Auf der Suche nach Antworten in der Telko-Branche

Im ersten Teil dieser Serie haben wir uns damit beschäftigt, was „Erfolg“ eigentlich ist (ein individuell definiertes und gezielt angestrebtes Ergebnis) und wie dieser in der Software-Welt messbar gemacht werden kann (über kausale Zielspezifikationen). Als Conclusio haben wir zusätzlich festgestellt, dass nicht stattgefundene Ereignisse nicht gemessen werden können – was zwar grundsätzlich logisch, aber trotzdem frustrierend ist. Im heutigen Artikel möchte ich daher die produktive Seite näher beleuchten: wie können sinnvolle Kennzahlen gefunden werden, die gute und beständige Daten zur Erfolgsmessung liefern?

Gute und schlechte Daten

Wie bereits im ersten Serienteil beschrieben ist es wichtig, „einfache“ Ziele zu formulieren und für diese eindeutige (d.h. unmissinterpretierbare) Key Performance Indicators (KPIs) zu finden. Gute – also gut zählbare – KPIs zeichnen sich durch folgende Kriterien aus:

  • wenig Komplexität (z.B. Klicks anstatt dem Ergebnis einer langen Ereignis-Kette)
  • keine Abhängigkeiten oder situative Unterscheidungen
  • geringer Interpretationsspielraum (z.B. Zahlenwert anstatt einer subjektiven Kategorisierung, d.h. beispielsweise „2“ anstatt „gut“)
  • kein unnötiger Ballast (siehe „Product Lifecycle“)

Product Lifecycle

Software lebt – und abhängig von der individuellen Ausprägung und Release-Zyklen bedeutet dies u.U. häufige Anpassungen in Umfang und Darstellung der Inhalte. Features werden ergänzt, verbessert oder entfernt, User Interfaces (UIs) werden modernisiert, erweitert und individuell gestaltbar. Und die KPIs? Im Idealfall passen sich diese an die Änderungen an und liefern so über den Lebenszyklus hinweg vergleichbare Zahlen. Dies hat den Vorteil, dass die Entwicklung der KPIs über mehrere Releases hinweg verglichen werden kann und so Aussagen über das Erreichen der Ziele (d.h. unseren Erfolg) getroffen werden können.

Dabei ist jedoch zu berücksichtigen, dass solche Aussagen natürlich nur dann Anspruch auf Gültigkeit erheben können, wenn der geänderte Bereich nur in gewissem Rahmen angepasst wurde. Bei radikalen Anpassungen ist so ein Vergleich oftmals nicht mehr wirklich zulässig und der alte KPI ist schlichtweg nicht mehr existent bzw. wird durch einen neuen ersetzt. Wie groß der angepasste Rahmen sein darf, um KPIs weiter leben zu lassen, ist ganz von der Definition des jeweiligen Werts abhängig: je präziser ein Datenpunkt definiert wurde, desto schwieriger ist es diesen bei Änderungen weiter fort zu führen. Dadurch ergibt sich ein gewisser Widerspruch zu dem Ansatz möglichst eindeutige Werte zu definieren. Denn eine „offenere“ Definition lässt sich leichter auf eine neue Situation umlegen als eine sehr strikte (einschränkende) Definition.

Auch hier liegt die Lösung in der Zieldefinition: wenn sich das Ziel im Product Lifecycle nicht ändert, dann können zielnahe KPIs auch weiter verwendet werden. Gute KPIs sind daher solche, die nicht ein (möglicherweise unbeständiges) UI-Element messen, sondern einen zielrelevanten Zustand (z.B. eine ausgelöste Bestellung).

Design follows Function?

Der hohe Stellenwert von Erfolgszahlen führt leider immer wieder dazu, dass ganze Releases maßgeblich daran ausgerichtet werden, wie ein bestimmter KPI (künstlich) in die Höhe getrieben werden kann. Dies führt jedoch nur zu kurzfristigen Erfolgen und geht oftmals zu Lasten von langfristig stabilen Werten. Ein (zugegeben extremes, aber plakatives) Beispiel hierzu: um die Häufigkeit eines Buttonklicks zu erhöhen, wäre eine einfache Maßnahme die häufigere Anzeige des Buttons. Alleine durch das Zufallsprinzip wird hierdurch die Klickrate steigen. Die Qualität der Software wird dies aber nicht zwingend im gleichen Maße tun, im Gegenteil: die tatsächlichen Anwender sind durch die häufige Anzeige des Buttons möglicherweise schnell genervt und werden die Software nicht mehr verwenden. Nach einem anfänglichen „Peak“ wird die Klickrate also sinken.

Beispiele für die Praxis

Im Folgenden möchte ich daher ein paar exemplarische Kennzahlen vorstellen, die sich in der Praxis als stabil bewährt haben und daher für eine Zieldefinition gut herangezogen werden können:

  • Anzahl an Downloads einer Software
    Dies ist eine relativ „banale“ Kennzahl, die sich aber ziemlich gut messen lässt (abgesehen von kleinen Unschärfen, z.B. abgebrochenen Downloads); mittels dieser Kennzahl lässt sich zwar noch keine Aussage darüber treffen, ob der Benutzer dann tatsächlich die Software verwendet oder nicht, aber sie gibt zumindest an, dass der Benutzer an der Software soweit interessiert ist, dass er sie herunter geladen hat. Eben dieses Interesse des Endkunden an einem Thema wird daher von vielen unserer ISP-Kunden als Erfolg gewertet, weil die erste Hürde (wie kommt der Benutzer überhaupt zur Software?) damit bereits gemeistert ist.
  • Verwendung der Software
    Dieser KPI mag auf den ersten Blick als einer der wichtigsten erscheinen, in der Praxis ist er aber jedoch schwer greifbar. Denn was versteht man unter „Verwendung“? Hier gehen die Erwartungshaltungen der einzelnen ISPs teilweise enorm auseinander, weshalb wir uns bei mquadr.at für ein flexibles System entschieden haben: wir unterscheiden einerseits das aktive „Vorhandensein“ der Software (z.B. sie läuft im Hintergrund auf dem Kunden-PC und wendet sich bei Problemen automatisch an den Benutzer) und andererseits dezidierte Aufrufe von Funktionen und Tools. Für letztere ist es dabei jedoch nicht relevant, ob diese vom Benutzer selbst ausgelöst wurden (z.B. über Klicks) oder ob die Software automatisch aktiv wurde (beispielsweise aufgrund erkannter Fehler oder anderer definierter Auslöser), denn das Ergebnis ist das gleiche: die Software wird für einen bestimmten Zweck verwendet und stellt damit einen Erfolg dar.
  • Milestones
    Eine andere Möglichkeit zur Erfolgsmessung ist die Zieldefinition über Milestones. Dabei werden gewisse „Punkte“ in der Software definiert, die der Benutzer erreichen soll. Diesem Prinzip folgen oftmals auch Zielmessungen bei Web-Anwendungen, indem dezidierte URLs, die beispielsweise nach dem Abschluss einer Bestellung angezeigt werden, als „Milestones“ gewertet werden. In unserer Software könnten das hingegen beispielsweise bestimmte Screens sein, die der Kunde erreichen soll.
  • Ausschlussprinzip
    Die bisher genannten Kennzahlen gehen allesamt davon aus, dass der Benutzer die Software genau im Sinne des Erfinders verwendet und beispielsweise einem vordefinierten Ablauf folgt. Die Praxis lehrt uns jedoch, dass dies oftmals nicht der Fall ist: Anwender verhalten sich manchmal unvorhersehbar, werden während der Nutzung durch Umwelteinflüsse abgelenkt oder unterbrochen und unterliegen somit Faktoren die von der Software nicht berücksichtigt werden können (auch wenn gutes Produkt-Design natürlich häufige Szenarien berücksichtigt). Hier kann das Ausschlussprinzip helfen: Erfolg ist, wenn der Benutzer die Software verwendet hat und es dabei nicht zu bestimmten Szenarien gekommen ist, z.B. zu Fehlermeldungen, Verweise auf die Support-Hotline etc. Im ersten Artikel dieser Blog-Serie wurde zwar darauf hingewiesen, dass nicht-stattgefundene Ereignisse nicht gemessen werden können, aber in diesem Fall handelt es sich um nicht-stattgefundene Ereignisse innerhalb der Software – und diese können sehr wohl gemessen werden.

Insbesondere der zuletzt genannte Ansatz des Ausschlussprinzips hat sich daher für Zieldefinitionen in der Software-Welt gut bewährt und wird daher auch von uns und unseren ISP-Kunden gerne eingesetzt. Die individuelle Verwertung besagter KPIs ist jedoch weiterhin Sache der jeweiligen Zieldefinition.

Fazit

Heutzutage ist es leider nicht mehr ausreichend, gute Ideen zu haben. Man muss auch beweisen können, dass sie gut sind – hierbei darf man sich jedoch nicht von kurzfristigen (künstlichen) Datenpunkten verleiten lassen, sondern muss langfristig beständige KPIs suchen und einen realistischen Blick auf die Zieldefinition behalten. Dafür gibt es unterschiedliche Ansätze, die in verschiedenen Szenarien ihre Vor- und Nachteile haben. Bei der persönlichen Zielsetzung muss daher häufig abgewogen werden zwischen präzise messbaren aber oftmals wenig aussagekräftigen KPIs einerseits und andererseits Kennzahlen, die zwar eine hohe Aussagekraft besitzen aber deren Messung möglicherweise nur ungenau möglich ist.