Minimum Viable Product II – eine Frage der Organisation

In diesem zweiten Beitrag zum Thema Minimum Viable Product liegt der Fokus auf den organisatorischen Aspekte des Minimum Viable Supports.

AutorMarkus Schweizer
Datum26.11.2018
Lesezeit3 Minuten

In meinem vorletzten Blogbeitrag habe ich zum Thema Minimum Viable Product geschrieben, dass dafür auch ein Minimum Viable Support bereitgestellt werden muss. Ich habe dabei vor allem auf die Erfahrungen aus einem Kundenprojekt fokussiert, wo dank Automatisierung und Analytics der Support beschleunigt werden konnte. Dieses Mal möchte ich auf die organisatorischen Aspekte des Minimum Viable Supports fokussieren.

Dank agilen Methoden sind wir heute in der Lage rasch ein neues Produkt in seiner Basis-Funktionalität (Minimum Viable Product) an den Markt zu bringen. Ab diesem Zeitpunkt müssen wir in der Lage sein, auftretende Fehler rasch zu beheben und neue Funktionalität zu liefern. Wir müssen also gewährleisten, Störungen nachhaltig beseitigen zu können.

ITIL hat uns dazu methodischen Grundlagen geliefert, wie in Abbildung 1 dargestellt:

minimum-viable-product

Eine Störung wird im

  • Event Management entdeckt,
  • im Incident Management behoben,
  • im Problem Management deren Ursache gefunden und eine Lösung dafür bereitgestellt,
  • die dann wiederum via Change Management bereitgestellt und verteilt
  • und in der CMDB dokumentiert wird.

Wird dieser Kreislauf immer wiederholt, reduzieren sich Schwere und Länge von Ausfällen exponentiell. Kunden berichten von bis zu 85% Reduktion von Störungen innert drei Jahren!

Im Zeitalter der Digitalisierung sind drei Jahre allerdings eine Ewigkeit, in der unser MVP schon lange im App-Nirvana geendet hätte. Die Methodik von ITIL ist nachweisbar korrekt, muss aber um Quanten beschleunigt werden! Die Automatisierung aller Schritte ist dafür zwingend, reicht alleine aber nicht aus. Auch die Menschen müssen die Art, wie sie entlang der obigen Kette zusammenarbeiten grundsätzlich neu erfinden. Anstelle von funktionalen Gruppen müssen sich service-bezogene Teams Ende-zu-Ende in einer «DevOps-Squad» organisieren, wie das in der folgenden Grafik dargestellt wird:

minimum-viable-product-2

DevOps ist dazu das Stichwort: DevOps ist kein Framework oder Methodik, sondern eine «Bewegung», die sich in den letzten 10 Jahren entwickelt hat. Nach langen Jahren des «angeordneten» Schweigens zwischen Entwicklung und Betrieb, sieht man auf dem Hintergrund der Agilität nun wieder die Notwendigkeit miteinander zu sprechen. Dank Cloud, der Virtualisierung und Automatisierung aller Infrastruktur-Layers (Everything-as-a-Servcie) gehen Organisationen heute sogar noch einen Schritt weiter: Der «blaue» IT-Betriebler in der Grafik oben ist nur noch eine Rolle, die von den anderen Mitgliedern der DevOps-Squad wahrgenommen wird. In diese Richtung weist auch eine Studie von McKinsey, die davon ausgeht, dass sich agile Methoden auch im IT-Betrieb durchsetzen werden und damit bis zu 35% der Aufwände reduziert werden können.

Damit wird in Zukunft der Minimum Viable Support integraler Bestandteil jeder Produktentwicklung und damit jedes Minimum Viable Products sein.

Weitere Infos

    Über den Autor

    Markus Schweizer

    Markus Schweizer ist Digicomp Trainer, ITIL®- und Cobit®-Experte und Projektleiter für alle Belange des IT-Managements. Nach Erfahrungen bei IBM und PwC verbrachte er neun Jahre in den USA, wo er Grossfirmen beim Einsatz von Service-Management-Konzepten beriet. Markus ist Geschäftsführer der Ginkgo Management Consulting Schweiz GmbH.