BizDevOps und die richtigen Regeln für das Lieferantenmanagement

Agile Vorgehen sind mittlerweile unbestritten Grundvoraussetzung für die erfolgreiche Umsetzung von Vorhaben der Digitalisierung. Die Vorgehensweisen sind ausreichend bekannt und einfach erklärt (scheitern aber trotzdem oftmals in der konsistenten Anwendung. Das ist aber ein anderes Thema). Mit DevOps-Ansätzen wird die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb deutlich verbessert. Die erweiterte durchgängige agile Zusammenarbeit zwischen Business, Entwicklung und Betrieb bezeichnet man als BizDevOps. BizDevOps verfolgt den agilen Ansatz, selbstorganisierender Teams aus Vertretern der Fachabteilung (Biz), Entwicklung (Dev) sowie dem IT-Betrieb (Ops). Mit dem richtig aufgestellten Team und optimal angewandt ist das das Erfolgsmodell für die Digitalisierung. Hierfür sind in Großunternehmen umfangreiche Transformationen notwendig und vielfach schon mit ersten Erfolgen umgesetzt.

Oftmals unbeachtet sind hingegen die Auswirkungen auf die Sourcing-Strategie, die passende Vertragsgestaltung und die Zusammenarbeit mit Lieferanten. Dies kann die Erreichung der Ziele der Transformation massiv erschweren und gefährden.

Mit diesem Beitrag wollen wir basierend auf unseren langjährigen Erfahrungen mit Managed Cloud Services und SaaS-Modellen konkrete praktische Empfehlungen für eine zielgerichtete und erfolgreiche Zusammenarbeit mit Lieferanten geben.

You design it, you build it, you run it: BizDevOps

You design it, you build it, you run it: BizDevOps

Einleitend noch einige kurze Erläuterungen zu BizDevOps-Set-Up und Vorgehen. Das folgende Bild zeigt die wesentlichen Grundideen:

  • Der Produkt Owner ist auch hier die zentrale Rolle. Er verantwortet aber nicht nur die fachliche Entwicklung des Produktes, der Anwendung oder der Services sondern ganz entscheidend auch den Betrieb.
  • Business, Entwicklung und Betrieb arbeiten eng und direkt in einem selbst-organisierten und möglichst autonomen Team zusammen. Oftmals verschmelzen somit auch Rollen und aus einem Entwickler mit Betriebsverantwortung wird ein DevOps Engineer. Diese Weiterentwicklung der Rollen und Kompetenzen ist wichtig für den Erfolg und aufgrund der Vielfalt auch erfüllend(er) für die Mitarbeiter.
  • Die einzelnen Schritte der Konzeption, der Analyse, der Umsetzung, des Deployments und des Betriebs werden fortlaufend iterativ ausgeführt und greifen eng ineinander. Dies führt zu direkten Feedbackschleifen und einer kontinuierlichen Verbesserung.

Der positive Effekt auf die drei klassischen betrieblichen Ziele ist mess- und nachweissbar:

  • Verkürzung der „Time-To-Market“
    • Das crossfunktionale BizDevOps-Team agiert schneller und reagiert direkter auf die Bedürfnisse des Kunden.
    • Es werden nur wirklich wichtige Dinge (sowohl fachlich als auch technisch) umgesetzt.
  • Optimierung der „Total Cost of Ownership”
    • Das Team ist sensibilisiert für die Betriebskosten (z.B. nutzungsabhängige Infrastrukturkosten für Cloud Services) und optimiert die Entwicklung auch dahingehend.
    • Das Team hat die Motivation, möglichst alles vollständig zu automatisieren.
  • Erhöhung der Qualität
    • Das Team ist über diesen Ansatz „intrinsisch“ motiviert hohe technische Qualität zu liefern und auch Probleme umgehend und selbstständig zu beheben.
    • Die wirklich wichtigen Kriterien für die Messung der Qualität (z.B. Kundenzufriedenheit, deployment frequency…) werden sichtbar.

Wie stellen sich diese Erfolge auch dann ein, wenn ich mit unterschiedlichen Lieferanten arbeiten muss? Was sind die wesentlichen Aspekte im IT Lieferantenmanagement aus strategischer und operativer Sicht?

Die passende Sourcing Strategie für BizDevOps

Nur die wenigsten Unternehmen (vermutlich nicht einmal Google, Amazon, Apple oder Facebook) verfügen über alle Kompetenzen intern und müssen in unterschiedlichen Konstellationen mit externen Lieferanten zusammenarbeiten. Leider verhindert oftmals die Aufteilung und Trennung der Lieferanten  die erfolgreiche Einführung und Umsetzung des beschriebenen BizDevOps Modells. In einem klassischen „horizontalen Sourcing“ gibt es getrennte Lieferanten für zum Beispiel Entwicklung, Applikationsbetrieb und Infrastrukturbetrieb. Der Übergang zwischen diesen Lieferanten ist oft formel und bedingt hohen Koordinierungsaufwand. Verkompliziert wird das Ganze durch unterschiedliche und inkonsistente Zielvorgaben und KPIs zur Erfolgsmessung.

Statt eines „horizontalen Sourcings“ muss das Sourcing „vertikal“ erfolgen, d.h. es gilt kompetente und passende Lieferanten zu identifizieren, die den gesamten Lebenszyklus und möglichst alle Kompetenzen für einen Service abdecken. Wichtig ist hierbei der richtige Schnitt der Services basierend auf den Prozessen („Value Streams“) in einem Unternehmen. Die Kriterien für eine Lieferantenauswahl sind somit andere und neue. Es geht nicht mehr um isolierte Kompetenzen und Preisführerschaft in einer Disziplin (z.B. Betrieb), sondern um die gesamte Abdeckung der Fach-, IT- und Methodenkompetenz – dafür aber in einem klar definierten fachlichen Umfeld.

Die richtige Vertragsgestaltung für BizDevOps

Wie lässt sich das jetzt konkret vertraglich gestalten, so dass sich in einem BizDevOps-Modell mit meinen Lieferanten die erwarteten Erfolge einstellen?

Die wichtigste erste Änderung ist, dass Sie die Verträge mit Ihren Lieferanten offener mit Freiraum für Innovationen gestalten müssen. Sie wollen sich durch den BizDevOps-Ansatz ja differenzieren und im Rahmen der Digitalisierung einen entscheidenden Wettbewerbsvorteil erhalten. Das muss sich auch in der Zusammenarbeit mit Ihren Lieferanten oder besser Geschäftspartnern widerspiegeln. Es geht nicht um den Einkauf standardisierter und vergleichbarer Waren wie Schrauben!

Für die Vertragsgestaltung im BizDevOps-Umfeld ist aus unserer Sicht ein phasenweises Vorgehen von Vorteil. In Phasen entwickelt sich die Zusammenarbeit beginnend von einem klassischen Modell nach Aufwand hinzu einem 100% performancebasierten Modell.

Die richtige Vertragsgestaltung für BizDevOps

Am Anfang der Zusammenarbeit gibt es noch eine hohe Unsicherheit für alle Parteien. Eine initiale Produktversion ist formuliert. Es kann aber noch keine belastbaren KPIs für eine performancebasierte Zusammenarbeit geben. Somit bietet sich für diese erste Phase nur ein T&M-Vertragsmodell (time&material) an. Die Abrechnung der Aufwände erfolgt nach Aufwand. Unsere Empfehlung ist, für diese erste Phase der Initialisierung maximal vier Sprints (ca. 8 Wochen) einzuplanen. Ergebnis der ersten Phase ist eine geschärfte Produktvision, erste Erfahrungswerte für die Velocity des Teams und auch ein priorisiertes Backlog.

Die Zusammenarbeit ist jetzt bereits etabliert, das Vertrauen steigt und die Unsicherheit sinkt. In der zweiten Phase können jetzt bereits 50% der Kosten mit dem Lieferanten mit performancebasierten KPIs vereinbart werden. 50% bleiben noch in einem Vertragsmodell nach Aufwand (T&M).

Nach Abschluß der zweiten Phase nach insgesamt 10-12 Sprints sollten Sie bereits mit einem ersten MVP (Minimum Viable Product) live gehen und so wertvolles erstes Feedback von Ihren Kunden oder Anwendern bekommen. Ebenfalls gibt es jetzt nach dieser Phase erhärtete Kennzahlen zur Velocity des Teams und erste Kennzahlen aus betrieblicher Sicht im DevOps-Modell.

In der dritten und letzten Phase „BizDevOps Contracting“ schließlich erfolgt die Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer zu 100% auf performancebasierten Kennzahlen. Soweit es sich bei dem Service bzw der Anwendung um eine cloud-basierte Lösung handelt, ist unsere Erfahrung und Empfehlung in diese Gestaltung auch die Kosten für die Nutzung der Cloud Infrastruktur aufzunehmen. Dies motiviert, dass sich das BizDevOps-Team (der Auftragnehmer) auch intensiv mit den Infrastrukturkosten beschäftigt und die Anwendung wo möglich dahingehend optimiert. Die schnelle Verfügbarkeit (scheinbar) unlimitierter Cloud Ressourcen führt oftmals dazu, dass gerade Entwickler eine effiziente Ressourcennutzung nicht mehr im Fokus haben und somit die Kosten für die Nutzung der Cloud-Services aus dem Ruder geraten können.

Richtig messen und steuern – KPIs und SLAs für BizDevOps

Welche sind nun die richtigen Kennzahlen (KPIs), um das bisher erwähnte zum Leben zu Erwecken und dann auch als relevante „Währung“ im partnerschaftlichen Vertragsverhältnis zwischen Aufraggeber und Auftragnehmer zu etablieren?

Richtig bedeutet in diesem Zusammenhang:

  • Ergebnisorientiert: Die KPIs sollen sich am eigentlichen Business Value des Services/der Anwendung orientieren.
  • Qualitätsorientiert: Die KPIs sollen eine hohe Qualität der Serviceerbringung sicherstellen.
  • Pragmatisch: Die KPIs sollen pragmatisch und möglichst vollautomatisch basierend auf den vorhandenen Tools zu erheben sein.

Die folgende Tabelle stellt die wesentlichen KPIs für die Zusammenarbeit und auch noch mal klassischen KPIs der Lieferantensteuerung gegenüber. Während es in der „alten Welt“ noch unterschiedliche (und divergierende KPIs) für Business, Entwicklung und Betrieb gibt, findet man in einem BizDevOps-Modell nur noch gemeinsame übergreifende KPIs

Klassisch BizDevOps
Biz –       Anzahl der Anforderungen

–       Vollständigkeit der Anforderungen

–       Kundenzufriedenheit

–       Velocity

–       Verfügbarkeit

–       Mean Time to Repair (MTTR)

Teaminterne KPIs

–       Technische Schuld

–       Automatisierungsgrad

–       Infrastrukturkosten

Dev –       Metriken zur Code Qualität
Ops –       Anzahl Changes

–       Anzahl Störungen (Incidents)

–       Verfügbarkeit

  • Kundenzufriedenheit: Die Kundenzufriedenheit (der Nutzer des Services) ist die wesentliche Kenngröße und somit auch Bestandteil der Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer. Für die Metrik und Erhebung bietet sich z.B. der NPS (Net Promoter Score) an. Gegebenenfalls kann auch noch die Nutzungsquote mit aufgenommen werden.
  • Velocity: Die Velocity ist eine Metrik für die geleistete Arbeit beziehungsweise umgesetzte Funktionalität in der agilen Softwareentwicklung. Die Definition und Messung erfolgt in Storypoints (und nicht in Personentagen). Die Velocity ist ein Indikator für die Effizienz des Teams und korreliert natürlich auch mit der Teamgröße. Über die Velocity können auch in der Zusammenarbeit Forecasts für eine Teamvergrößerung oder -verkleinerung abgebildet werden. Die Abrechnung zwischen Auftraggeber und Auftragnehmer erfolgt zum Beispiel nach monatlich gelieferten Storypoints.
  • Verfügbarkeit: Die (monatliche) Verfügbarkeit des Services ist auch in einem BizDevOps-Modell eine valide Größe für die Qualität der Serviceerbringung.
  • Mean Time to Repair (MTTR):Wichtig in einem agilen BizDevOps-Set-Up ist nicht primär, ob und wie oft Störungen oder Änderungen aufgekommen sind, sondern wie schnell darauf reagiert wurde.

Die oben aufgeführten teaminternen KPIs zahlen indirekt auf die performancebasierten KPI ein und sollten allen Parteien transparent zur Verfügung gestellt werden.

BizDevOps: Auftraggeber und Auftraggnehmer in einem Boot

Abschließend ist noch einmal wichtig zu verdeutlichen und zu wiederholen, dass in diesem Modell Auftraggeber und Auftragnehmer in einem Boot sitzen. Nur so können die gemeinsamen Vorhaben der Digitalisierung gelingen. Die KPIs dienen also dem Managen der Partnerschaft und nicht der Steuerung eines Lieferanten. Dies gilt für die Zusammenarbeit in der Privatwirtschaft und aber auch für dringend anstehende Digitalsieriungsprojekte im öffentlichen Sektor.

LionGate – Building Custom Cloud Solutions

Wir entwickeln und betreiben seit Jahren kommerzielle kundenspezifische und differenzierende Cloud Lösungen für unsere Kunden in einem BizDevOps-Set-Up. Der Erfolg unserer Kunden mit unseren Lösungen bestätigt unseren Ansatz. Wir freuen uns auf den Austausch hierzu und helfen Ihnen bei Ihren Herausforderungen.


Lassen Sie uns reden.

Ihr Kontakt bei LionGate: Armin Oppitz, Vorstand und Gründer