Warum scheitert DevOps so häufig? Fünf Thesen.

Warum scheitert DevOps so häufig? Fünf Thesen.

 

DevOps scheint so faszinierend einfach. Trotzdem scheitern entsprechende Initiativen in großen Organisationen immer wieder. Fünf große interne Herausforderungen sind mir im Laufe der letzten Jahre als Cloud Business Developer immer wieder begegnet. Am Beispiels einer App für digitalisiertes Einkaufen am Point of Sale wird deutlich, warum DevOps in klassischen Unternehmen immer noch scheitern.

Einzelhändler in Deutschland müssen sich den Veränderungen stellen

Wenn ich durch meinen angestammten Supermarkt laufe, denke ich oft, das wird so nicht weitergehen. Muss ich mir hier alle Produkte selber suchen? Wieso bekomme ich keine relevanten Empfehlungen?

Um potentielle Käufer überhaupt noch an den Point of Sale zu locken, gilt es für die Händler, kundenfreundlicher und spannender zu werden. Getrieben von der Online-Konkurrenz, werden sich in den kommenden Jahren Arbeitsabläufe und Einkaufserlebnis ändern (müssen).

Amazon macht es vor: Ein Kunde mit vorinstallierter App auf dem Smartphone betritt den Amazon Store und legt seine Einkäufe in den Wagen. Via RFID-Chip registriert die App, um welche Produkte es sich handelt. Anhand smarter Algorithmen werden dem Einkäufer nun Komplementärprodukte, Rezepte oder spezifische Rabatte angeboten. Wer bspw. gerade Löffelbiskuits in seinen Warenkorb gelegt hat, kann so eine Werbung für Mascarpone erhalten. Oder einen Rezeptvorschlag für Tiramisu. Und per Indoor-Navigation wird ihm gleich der direkte Weg zur Ware angezeigt.

Eine solche App gibt es noch nicht in Deutschland. Aber wie würde es aussehen, wenn ein deutsches Einzelhandelsunternehmen eine solche technische Innovation intern umsetzen würde?

DevOps scheint so faszinierend einfach

Dass DevOps funktioniert, haben wir in unserem Blog schon mehrfach gezeigt.

Für ein neues Projekt werden alle relevanten Mitarbeiter interdisziplinär in einem Team zusammengeführt und kümmern sich um dieses in End-to-end-Verantwortung. Da mit einem solchen Team alle notwendigen Mittel und Fähigkeiten eng versammelt sind, können auftretende Probleme und Anforderungen schnell und unkompliziert gelöst werden. Die entwickelte Software wird somit kostengünstiger, qualitativ besser und innovativer.

Geschwindigkeit ist Trumpf

Die technischen Features unserer Warenkorb-App scheinen nicht sehr kompliziert zu programmieren: Mit dem Smartphone die RFID auslesen? Vielleicht 10 Personentage. Ein Vorschlagssystem mittels verwandter Produkte entwickeln? Ebenfalls 10 Personentage. Benutzer- und Warenkorb-Profile anlegen, Auswertung und Bewertungsfunktion? Vielleicht noch einmal 10 Personentage. Oberflächen gestalten, Daten aufbereiten, Nutzerfeedback einholen …

Am Ende wird die App mit einem ersten Feature-Set vielleicht 100-150 Personentage benötigen und – je nach Teamgröße – in 6-8 Wochen lauffähig sein.

Also REWE, EDEKA, ALDI: Das sollte in eurem Budget doch drin sein, oder?

Warum scheitert DevOps so häufig?

Die Realität der DevOp-Umsetzung in Unternehmen ist weitaus schwieriger als das. Viele gutgemeinte Projekte scheitern an internen Widerständen und versanden.

These 1: Der Chef muss es wollen

Man muss kein intimer Kenner der Organigramme und Arbeitsabläufe deutscher Einzelhandels-Konzerne sein, um deren Schwierigkeiten bei der Umsetzung von IT-Projekten zu erahnen. Schon die Frage, wer am Ende für die Umsetzung einer digitalen Warenkorb-App zuständig ist, wirft Probleme auf: Bei REWE betreiben bspw. Franchise-Nehmer viele der Märkte. Diese wiederum müssten ein entsprechendes Commitment zur Umsetzung des digitalen Warenkorbs in ihren Märkten geben – Sie müssen schließlich die RFID-Chips installieren und ggf. Kameras für die kognitiven Services aufstellen.

Zentral organisierte Einzelhändler wie ALDI haben es da scheinbar einfacher. Aber auch hier sind die Zuständigkeiten nicht klar: Die Kundendaten, wenn überhaupt vorhanden, liegen bei Marketing und Vertrieb. Die Produktdaten im Einkauf sowie in der E-Commerce-Abteilung. Der Betrieb einer IT-Lösung obliegt meist noch der IT-Abteilung. Aber die E-Commerce-Kollegen haben mittlerweile auch eigene Software gekauft, die von externen Providern betrieben und entwickelt wird. Eigene Entwickler gibt es wenige, egal in welcher Abteilung.

Cloud-Experten propagieren DevOps als Lösung: Die Schaffung von Mini-Teams, die abteilungsübergreifend besetzt – und nicht in die traditionellen Befehls- und Hierarchieketten des Unternehmens eingebunden sind. Ein solches Start-Up innerhalb des Unternehmens kann in Eigenverantwortung – und ohne Störsignale aus bestehenden Machtstrukturen – die App auch wirklich in acht Wochen mit 100 Personentagen umsetzen.

Ein solches Team zu gründen, in dieser Besetzung, mit diesen Handlungsmöglichkeiten – das ist allerdings etwas, was der Chef auch wirklich wollen muss.

These 2: Auch die Mitarbeiter müssen es wollen (und können)

Dass das Team die App entwerfen, programmieren und betreiben kann, setze ich voraus.

Aber will es das auch? Klar, der Programmierer wird sicher programmieren wollen, aber möchte er auch nachts aufstehen, wenn seine Software nicht mehr funktioniert? Möchte er sich täglich die User-Stories anhören?

Und im Detail ist das „Können“ dann auch nicht so einfach: Menschen, die ihr Leben lang in hundertprozentigen Lösungen gedacht haben, die gerne detaillierte Projektpläne machen, die am liebsten dem Lieferanten per Vertrag alle Risiken überschreiben, sollen plötzlich 80%-Lösungen entwerfen? Sollen einerseits in großen Visionen denken („Die Warenkorb-Experience digitalisieren“), aber dann erst einmal nur ein Minimum Lovable Product bauen („Komplementärprodukte vorschlagen“) und auf Markt-Feedback warten? Anstatt die beste Lösung zu programmieren, den Kunden zwei Varianten zur Verfügung stellen und schauen welche besser funktioniert (AB-Testing)? Offensichtlich: Es reicht nicht, wenn der Chef ein DevOps-Fan ist, die Mitarbeiter müssen es können und wollen.

These 3: Organisationen müssen Entwickler einstellen

Wie viele Entwickler beschäftigen REWE, ALDI und EDEKA, die eine solche App wirklich programmieren können? Sicherlich sind es in den IT-Abteilungen und Konzernabteilungen nicht allzu viele. Einige der Lebensmittel-Discounter suchen aktuell entsprechende Programmierer.

Es besteht also Hoffnung, denn ohne Entwickler wird es nicht gehen. Wird wirklich alles, was digitalisierbar ist, auch digitalisiert, dann werden an allen Schlüsselpositionen der Digitalisierung auch Entwickler mit am Tisch sitzen müssen.

These 4: Aus Tech-DevOps müssen Biz-DevOps werden

DevOps entstammt der Welt der IT. DevOps-Jünger wissen, was GitHub ist, was CI/CD bedeutet und kennen die wahre Faszination der REST-API. Seine eigentliche Kraft aber entfaltet DevOps nun einmal im Kern-Geschäft – oder in unserem Beispiel beim Einkauf im Supermarkt.

BizDevOps ist die einfache Erweiterung des Teams um Business-Verantwortliche, Designer und Kommunikationsexperten. Übertragen auf die fiktive Warenkorb-App entsteht dabei ein eigenes schlagkräftiges Team innerhalb des Unternehmens, das sich mit der Umsetzung der Aufgabe beschäftigt: Software-Entwickler für Programmierung, Betrieb und Test der App; Designer für die Oberfläche sowie Experten für die Vermarktung der App und die Kommunikation mit den Stakeholdern.

Jetzt sind glücklicherweise auch Software-Developer regelmäßige Kunden im Supermarkt. Sie haben einen Bezug zum Geschäftsproblem, das die Einkaufswagen-App löst.

Im jeder Organisation sollte der Bezug der DevOps zum Geschäftsproblem fest institutionalisiert sein – in Form von BizDevOps. Andernfalls ist die Gefahr groß, dass die Software-Lösung am Geschäft vorbei weiterentwickelt wird.

These 5: Es wird nie aufhören

Das Schöne an DevOps ist, dass die erste Funktion in der Regel sehr schnell programmiert ist („Komplementär-Produkt vorschlagen“). Ist sie erfolgreich, geht es weiter:

  • Warum nicht individuelle Kundenrabatte erstellen?
  • Eine Navigationshilfe durch den Supermarkt integrieren?
  • Den Kunden beim Betreten des Geschäfts begrüßen?
  • Schnittstellen zu sozialen Netzwerken bauen?

Das Feld möglicher Erweiterungen ist schier unendlich. Und dann gibt es auch noch eine Schattenseite: Cloud-Provider wie AWS und Azure bieten immer wieder neue Funktionen an, Partner verändern ihre Schnittstellen, es gibt neue Datenschutzverordnungen usw. Der Service ist im ersten Schritt zwar günstig zu erstellen, alleine lassen kann man ihn allerdings nicht.

Die erfolgreiche Implementierung von DevOps ist daher nicht der Endpunkt sondern der Ausgangspunkt eines langfristigen Unternehmenswandels. Die Aufgabe einer  erfolgreichen Organisationsentwicklung besteht darin, den Prozess des Wandels (Change) zu verstetigen.

DevOps ist somit keine einmalige Aufgabe auf der ToDo-Liste, sondern der Beginn einer Reise in Richtung Agilität, Innovation und Kundenorientierung.

2 Antworten

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.