Das «Minimum Viable Product» braucht «Minimum Viable Support»

Als Fitness-bewusster Mensch war «Moves» eine meiner Lieblingsapps für das iPhone. Täglich wurde meine Schrittzahl, Distanz und Energieverbrauch automatisch registriert, sodass ich meine Alltagstätigkeiten ideal mit meinen Sportaktivitäten kombinieren konnte. Leider kann ich davon nur in der Vergangenheitsform berichten, da die App seit ca. drei IOS-Releases beim Starten abstürzt. Google-Suchen halfen mir nicht weiter und mein E-Mail an die Entwickler ist nie beantwortet worden. Das für mich sehr «brauchbare (viable) Produkt» wurde wegen des Fehlens eines «Minimum Viable Supports» nutzlos und ich habe es schweren Herzens gelöscht.

In der neuen Welt der agilen, inkrementellen Produktentwicklung ist es also weiterhin unerlässlich, sich rund um ein MVP auch Gedanken zum «Minimum Viable Service» und damit auch zum «Minimum Viable Support» zu machen.

Die technologischen und methodischen Entwicklungen, die die Servicewelt derzeit massiv verändert, sind in folgender Grafik kurz dargestellt:

Die Idee eines Minimum Viable Products ist es, dem Kunden möglichst früh eine brauchbare Basislösung hinzustellen, damit die Entwickler beobachten können, wie der Nutzer das Produkt nutzt und in welche Richtung er die Weiterentwicklung sehen möchte. Dazu brauchen wir eine entsprechende Basis-Supportleistung, die aber kaum Kosten verursachen darf, da ein MVP geringe Erträge abwirft, aber sehr stark skalieren kann. Geringe Margen bei hohen Volumen bedeuten aber, dass im Support jegliche manuelle Eingriffe vermieden werden müssen, da deren Skalierung rasch teuer wird und die Margen im Nu wegfrisst.

Self-Service und Predictive Analytics müssen daher schon in die Entwicklung eines Minimum Viable Products eingebaut werden. Die Beobachtung des Kundenverhaltens erzeugt Daten, die auch zur Einschätzung und Entwicklung des (automatisierten) Supportbedarfs dienen.

In der Konsequenz heisst dies, dass auch die Supporttools die Möglichkeit bieten müssen, inkrementell aufgebaut und angepasst zu werden. Muss man vorab eine hochkomplexe On-Premise-Plattform installieren, entstehen aus den Lizenzverpflichtungen Opportunitätskosten, die die erhoffte Innovation und Flexibilität schnell abwürgen.

Die Lösung: Software-as-a-Service oder Open-Source mit Cloud

In Frage kommen daher nur zwei Ansätze: Eine Software-as-a-Service-Lösung mit einem dynamischen Subskriptionsmodell oder eine Open-Source-Lösung aus der Cloud. Bei der Saas-Lösung erhält man in der Regel schon viel Funktionalität, ist aber nicht immer völlig frei in der Wahl der Subskriptionspakete, woraus sich wieder die Gefahr von Opportunitätskosten aus «Shelfware» (bezahlte aber nicht gebrauchte Funktionalität) ergibt. Bei der Wahl von Open-Source-Produkten ist technisches Know-how für die gewählten Produkte unerlässlich. Nur hier hat man aber die volle Kontrolle über den inkrementellen Ausbau der (automatisierten) Supportfähigkeiten, der synchron mit dem Ausbau des Produkts erfolgt.

Die hier aufgezeigten Ansätze des agilen Service und Support-Managements gelten nicht mehr nur für die App- und Webwelt, sondern drängen auch in die Welt der Unternehmens-IT. Mit dem Ersatz von proprietären, monolithischen Anwendungen durch einen Mix von internen- und externen Lösungs- und Servicemodulen müssen auch die internen Supportleistungen agiler gestaltet und vermehrt automatisiert werden.