Table of Contents
Anleitung zur Nutzung der Scorecard
Mehr oder weniger komplexe Anforderungen in ein oder zwei Wochen agil umzusetzen und dabei noch das UX zu designen – das fühlt sich irgendwie nicht richtig an?
Erfolgreiche Tech-Firmen vom Startup bis hin zu Google machen das anders. Sie testen potenzielle Lösungen so lange mit einfachen Prototypen oder anderen Experimenten, bis sich das Produktteam sicher ist, dass die geplante Lösung von Kunden gebraucht wird, gut einsetzbar ist, mit vertretbarem Aufwand umsetzbar ist und auch die eigene Organisation weiterbringt. Erst dann startet die Entwicklung und liefert höchste Qualität. Dieses Vorgehen beim Suchen der besten Lösung für Produktverbesserungen nenne ich Lösungsexploration, englisch „Product Discovery“.
Die Produkt-Feature Scorecard hilft dabei, diese Suche nicht vorschnell auf Basis von Bauchgefühl und ungeprüften Annahmen zu beenden und die Entwicklung zu starten.
Wie viel und wie intensiv die Lösungsexploration für eine neue Lösung durchgeführt werden sollte, hängt immer vom Aufwand und von der Komplexität ab. Nehmt diese Vorlage also nicht als verpflichtende Checkliste. Wie immer finde ich wichtig, mit gesundem Menschenverstand pragmatisch vorzugehen.
Auf die Idee zu dieser Scorecard kam ich durch die Innovation Project Scorecard von Strategyzer.
Problem und Lösungsansatz
Das Produktteam sollte von den Produktverantwortlichen ein Problem zu lösen bekommen. Entweder ein Problem der Kunden und Nutzer der Anwendung oder auch ein Problem der eigenen Organisation.
Es braucht dann in der Regel viele Iterationen von unterschiedlichen Lösungsansätzen, bis eine wirklich passende Lösung gefunden ist. D.h. dass auch entsprechend viele dieser Scorecards erstellt werden.
Ob das Problem gut kommuniziert und verstanden ist, zeigt sich an der Qualität des KPIs zum Messen der konkret erreichten Verbesserung des Problems. Es geht also nicht darum, wie schnell geliefert wurde oder wie gut die Lösung ist.
Schauen wir uns ein fiktives Beispiel an: In einem ERP-Produkt für Gewerbetreibende ist es den Kunden lästig, den Eingangsrechnungsbelege zu Scannen, hochzuladen und dann Kreditoren zuzuordnen.
Damit ist das Wer beantwortet: Gewerbetreibende
Was soll sich konkret verbessern: Das Erfassen der Eingangsbelege soll erheblich einfacher werden
Wichtig ist hier nicht so sehr die Formulierung, sondern die Diskussion bis zu einem guten Verständnis der Ausgangssituation im Produktteam.
Als KPI für die Verbesserung kommt beispielsweise ein NPS (Net Promoter Score) infrage, z.Bsp. Sie unser ERP zur würden Verarbeitung von Eingangsrechnungen Kollegen empfehlen? oder wir messen einfach die Zeit, die der Vorgang dauert. Allerdings heisst schneller nicht unbedingt, dass die Anwender die Lösung auch gerne verwenden.
Da ein NPS erst nach einiger Zeit der Verwendung sinnvoll ist, verwenden wir diesen als echten KPI und nutzen den direkt messbaren Zeitwert als Hilfsmetrik während der Lösungsexploration.
Wenn wir hier nicht sauber arbeiten, könnte sich auch die Zahl der Supportfälle wieder deutlich erhöhen. Also nehmen wir die Anzahl der aktuell anfallenden Supportanfragen zum Rechnungswesen pro Woche als Wert, der nicht schlechter werden soll. (Wir haben das im letzten Jahr erheblich reduziert und das soll auch so bleiben.
Nun zum Lösungsansatz: Nehmen wir mal an, die erste Idee vom Produktmanagement war, eine externe Lösung als Webkomponenten direkt in die Oberfläche einzubinden. Ein Testzugang lag bereits vor, und dann kam der Tech-Lead dazu und hat klargemacht, dass die Lösung so nicht in die Security-Infrastruktur passt.
Im folgenden Brainstorming von UX-Spezialisten, Produktmanagement und Entwicklung wird ein anderer Lösungsansatz herausgearbeitet: Eine eigene kleine Smartphone-App, die auf der bestehenden Mobile-Infrastruktur aufsetzt und ein Foto vom Beleg macht, den Lieferanten extrahiert und zur Bestätigung anbietet. Dies ist also der aktuelle zu untersuchende Lösungsansatz.
Risiken adressieren
Meist ist es sinnvoll, die Risiken in der jetzt beispielhaft folgenden Reihenfolge anzugehen. Aber es gibt genügend Ausnahmen, bei denen eine andere Vorgehensweise deutlich effizienter ist. Agiles Mindset in einem innovativen Umfeld bedeutet einfach, nie blind einem Prozess zu folgen!
Risiko 1: Nutzbarkeit
Um den Nutzen einer Lösung bewerten zu können, ist oft ein realistisch wirkender Prototyp das Richtige. Da der mehr Aufwand macht als ein reiner Usability Prototyp, beginnen wir mit diesem. In einem Prototyping Tool für Mobile Apps wird vom UX-Spezialisten ein erster Entwurf erstellt. Der Aufruf der App erfolgt über die Standardoberfläche des Smartphones.
Die in den Test eingebundenen Kunden haben aber Schwierigkeiten, die App zu finden bzw. zu installieren.
Der nächste Prototyp erlaubt den Aufruf der App aus dem kaufmännischen Dashboard heraus. Im Bedarfsfall wird direkt die Installation angestoßen. Das funktioniert bei allen Testanwendern ohne Hilfestellung.
Ähnlich geht es durch die Bedienung der Funktion.
Risiko 2: Mehrwert für Kunden
Erst, wenn die Evidenz & Zuversicht im grünen Bereich ist, geht es zum Mehrwert für den Kunden. Dafür wird der Prototyp noch etwas realistischer gestaltet. Z.B. wird mit 5 fiktiven Rechnungen gearbeitet, für die jeweils passende oder nur eine Auswahl möglicher Lieferanten vorgeschlagen wird. Dieser Prototyp ist also schon deutlich aufwändiger und entsprecht auch optisch der normalen App-Oberfläche des ERP-Systems.
Da diese Erweiterung nicht mit einem eigenen Preis belegt werden soll, werden Kunden nach dem Ausprobieren des Prototyps gefragt, ob sie zum Betatesten bereitstehen und ob sie dann einen Referenzbericht zu der neuen Funktion in der Kundennews beisteuern werden.
Darauf kommt 9x ein doppeltes Ja und einmal möchte der Kunde nicht genannt werden, ist aber zum Betatest bereit.
Ein quantitativer A/B Test macht in diesem Fall keinen Sinn, deshalb markiere ich den so.
Risiko 3: Machbarkeit
Die Aufgabe, das Problem zu lösen, wurde von Produktverantwortlichen bereits an das Produktteam mit der meisten Erfahrung in der Belegverarbeitung vergeben. Entsprechend erfahren ist der Tech-Lead.
Der bespricht zur Sicherheit noch den Lösungsansatz mit seinen Entwicklern. Dabei kommt die Frage hoch, ob die Erkennung der Kreditoren-identifizierenden Texte möglich ist.
Da die angedachte Lösung in maximal 2 Monaten umgesetzt sein soll, entscheidet sich das Team für einen technischen PoC. 2 Entwickler arbeiten als Paar eine Woche an der Umsetzung und sind sich dann sicher, dass die Erkennung gegen die Daten in der Datenbank mit 90% sicherer Erkennung auf Basis der ausgewählten Komponenten machbar ist.
Gleichzeitig haben die beiden gleich noch einen Lasttest mit den maximal zu erwartenden gleichzeitigen Anfragen durchgeführt der auch positiv verlief. Die technischen Fragen lassen sich so innerhalb von 2 Wochen alle bejahen.
Hier fragt es sich, ob der Aufwand vor allem für die Entwicklung gerechtfertigt ist. Ich selbst habe schon oft aus dem Bauch zu optimistisch geurteilt und die Umsetzung war dann doppelt so aufwändig wie gedacht oder noch höher. Wenn man das vorher weiß, kann ein anderer Lösungsweg evtl. deutlich besseren ROI bringen.
Risiko 4: Wirtschaftlichkeit
Jetzt geht es noch an die Stakeholder:
Die Stakeholder, die einen Start evtl. verhindern können oder wichtiges Feedback zu einem Aspekt der Erweiterung liefern können, sollten einzeln den ausführlichen Prototypen aus dem Kunden-Mehrwerttest vorgeführt bekommen.
Evtl. fragt Legal nach, ob die Daten in der Cloud zu einem anderen Anbieter gehen.
Oder Partnermanagement erkennt, dass die eigene Lösung evtl. die Beziehung zu einem Partner, der bereits Rechnungseingangsverarbeitung extern angebunden hat, gefährdet.
Schließlich sollten wir nach dem Abklopfen der Rahmenbedingungen die Gretchenfrage nicht vergessen: Hat die eigenen Organisation einen so großen Mehrwert, dass sich die erwartete Größenordnung des Aufwands auch lohnt? Da die Geschäftsführung bereits wegen erster Abwanderungen im Rechnungswesen-Modul zu anderen Cloudlösungen sehr beunruhigt ist, kommt hier ein klares GO!
Endlich – Umsetzung
Jetzt ist vor allem das Entwicklungsteam an der Reihe. Am Ende soll eine performante, sichere, einfach zu nutzende und wartungsfreundliche Erweiterung entstehen. Da sind noch jede Menge Herausforderungen, die vor allem die Entwicklung, auch unter Einbezug des Produktmanagements, zu lösen hat.
