Outsourcing und moderne Software-Entwicklung
Klassisches Outsourcing ist nicht kompatibel mit moderner Software-Entwicklung. Wie es trotzdem gelingt, lernst du in diesem Artikel.
Bei den Themen Kosteneinsparungen und Optimierung denken vielen Unternehmen sofort an Outsourcing. Die praktischen und wirtschaftlichen Vorzüge der Auslagerung, die häufig ganze Funktionsbereiche betrifft, halten jedoch einer genaueren Betrachtung nicht stand. Denn funktionales Outsourcing kann die Software-Entwicklung geradezu lahmlegen. Wie du das als IT-Führungskraft verhinderst, erklären wir dir in diesem Artikel.
1) Funktionales Outsourcing und seine Nachteile
Unter funktionalem bzw. auch horizontalem Outsourcing versteht man die Vergabe einzelner funktionaler Bereiche, wie Entwicklung, Test oder Betrieb an teils unabhängige, externe Dienstleister. Moderne Methoden der Softwareentwicklung, wie DevOps, haben jedoch gezeigt, dass es nicht sinnvoll ist, diese funktionalen Grenzen zu ziehen. Welche Probleme entstehen dadurch?
Aufbau von Silos
Vorhandene Silos bedeuten immer eine in sich geschlossene Konzentration von Wissen. Bereits innerhalb eines Unternehmens sind sie nachteilig, richtig schlimm wird es jedoch, wenn Silos extern entstehen. Ständige Anfragen nach außen, insbesondere die Entscheidungsfindung betreffend, bremsen Prozesse aus. Dazu kommt, dass der genaue Umfang der Aufgaben und ihre Verantwortlichkeiten vertraglich genau festgelegt werden. Kommt es situationsbedingt zu notwendigen Anpassungen, muss um jede Änderung nachträglich gekämpft werden. In der heutigen schnelllebigen Technologiewelt ist es jedoch essenziell, auf häufig auftretende Änderungen zeitnah reagieren zu können. D.h. auch externe Dienstleister müssen sich ändern, um mit dieser Entwicklung mithalten zu können, z.B. durch mehr Flexibilität in ihren Verträgen.
Geringe Performance
Funktionales Outsourcing wird viermal so häufig von Low-Performern betrieben. Das hat eine Untersuchung von über 30.000 IT-Organisationen DevOps Research and Assessment (DORA) ergeben ( nachzulesen im State of DevOps Report 2018. Low-Performer zeichnen sich u.a. durch deutlich häufigere Ausfallzeiten aus. Durch ständige Fehlerbehebung haben sie weniger Zeit für die Entwicklung neuer Funktionalitäten. Dieselbe Untersuchung zeigt, dass den Low-Performern eine wachsende Elite von hochperformanten Unternehmen gegenübersteht. Wer heute noch Low-Performer ist, muss sich also ranhalten und kann es sich auf keinen Fall leisten durch vermeidbare, falsche Grundsatzentscheidungen weiter Boden an die Konkurrenz zu verlieren.
Übergaben und Abhängigkeiten zwischen Teams
Übergaben sind reibungsbehaftet. Je mehr davon in einem Projekt notwendig und umso abhängiger Teams voneinander sind, desto stärker sinkt die Gesamteffektivität. Dies resultiert aus den folgenden, negativen Effekten:
- Entstehung von langen Wartezeiten.
- Durch hohe Transaktionskosten bei Übergaben werden Batch-Releases anstelle eines kontinuierlichen Release-Prozesses gefördert. Dadurch erhört sich die Lead-Time und damit verbundene Release-Risiken. Denn je länger es dauert, bis Änderungen in Produktion genommen werden können, umso seltener gibt es Feedback und umso mehr verzögern sich kritische Systemanpassungen.
- Suboptimale Lieferung verlängert die Time-to-Market.
Das lässt sich in Verzögerungskosten quantifizieren, auch “Cost of Delay” genannt. Diese fressen Einsparungen durch funktionales Outsourcing in der Regel zum Frühstück. Klar, Kosten werden gespart. Aber Business-Opportunities bleiben ungenutzt und gewaltige Umsätze gehen verloren.
2) Alternativen zum funktionalen Outsourcing
Welche Alternativen hat deine Organisation, um Outsourcing konform mit modernster Software-Entwicklung zu betreiben?
- “Vertikales” Outsourcing ganzer Systeme im SaaS-Style von Design bis hin zum Betrieb, eng verbunden mit dem DevOps-Ansatz.
- Einbettung von externen Abhängigkeiten direkt in deine Teams.
Durch diese beiden Punkte werden (technische) Abhängigkeiten der Systeme reduziert und notwendiges Know-how zur Reduzierung von Wissenssilos in die eigenen Prozesse integriert. Gleichzeitig behält man sich die Flexibilität, auf externe Arbeitskräfte statt auf Vollzeitkräfte zurückgreifen zu können, wenn es z.B. die Marktsituation bzw. die eigenen Kapazitäten und Möglichkeiten nicht hergeben. Damit dieser Ansatz funktionieren kann, müssen zunächst autonome Einheiten innerhalb der Organisation identifiziert werden. Diese kann man dann im Saas-Style outsourcen, um nicht-blockierende Schnittstellen zu ermöglichen. Dabei gilt es ein paar Punkte zu beachten:
Reduzierung von Abhängigkeiten
Wie bereits beschrieben, sind Übergaben und Abhängigkeiten der Systeme ein großes Problem für das operative Geschäft. Um diese zu minimieren, sind vor allem die Führungskräfte in einer Organisation gefragt. Figur 1-3 beschreibt, wie dabei am besten vorgegangen wird: Ideale Systeme, die möglichst autonom sind, befinden sich im grün markierten Bereich. Dorthin zu gelangen, sollte immer das oberste Ziel sein. Da manche Systeme dafür jedoch nicht geeignet sind, ist dies durch simple Maßnahmen nicht immer 1:1 möglich. In einigen Fällen muss man vielleicht ein großes System in zwei kleinere Komponenten bzw. im allgemeinen Fall m Systeme in n neue Teilsysteme zerlegen, um mit diesen jeweils in den grünen Bereich gelangen zu können.
 Figur 1: Reduzierung von Übergaben und Abhängigkeiten |  Figur 2: Zerlegung eines Systems in kleinere Einheiten |
Figur 3: Systemlandschaft neu zuschneiden
Oft kommt es jedoch vor, dass es nicht ausreicht, sich auf Teilsysteme zu beschränken, sondern größere Teile der Systemlandschaft müssen neu zugeschnitten und auf die Teams verteilt werden.
Strukturierung von Teams und Systemen
Eine systematische Methode, wie man die Systemlandschaft und korrespondierende Teams zusammen strukturiert, ist das Team Interaction Modelling (TIM). Sie wurde im Umfeld von Team Topologies entwickelt und ausgiebig evaluiert.
Figur 4: Umstrukturierung der Teams mittels TIM
Mittels TIM werden Fähigkeiten innerhalb von organisatorischen Einheiten identifiziert, die entweder in Subteams oder Platform-Teams zusammengefasst werden können. Platform-Teams bieten Produkte an, die von anderen Teams verwendet werden.
Außerdem schaut man sich Wechselwirkungen zwischen den Einheiten an. Gibt es viele interne-externe Interdependenzen, z.B. wenn es nötig ist, häufig Zustimmung oder Feedback einzuholen und die Entscheidungsfindung obliegt dann den internen Einheiten, dann sollte über Insourcing nachgedacht werden.
Figur 5: Insourcing zur Reduzierung von Wechselwirkungen
Allerdings sollte dabei, unabhängig ob intern oder extern, immer geprüft werden, ob die Prozesse und ihre Wechselwirkungen überhaupt einen Wert beitragen. Alles, was auf ein redundantes “always yes” hinausläuft, sollte eliminiert werden.
Figur 6: Eliminierung von redundanten Prozessen
Ein weiterer wichtiger Aspekt von TIM ist eine ausführliche Dokumentation der Evolution eines Unternehmens vom Status Quo hin zu einer vollständigen Implementierung des DevOps-Ansatzes.
Identifizierung geeigneter Kandidaten
Nun stellt sich die Frage, für welche Systeme sich die Überlegungen bezüglich TIM und der Reduktion von Abhängigkeiten und Übergaben lohnen? Um diese zu identifizieren, kann einem der DevOps-Ansatz helfen. DevOps vereint alle Aspekte des Lebenszyklus einer Anwendungsentwicklung der Bereiche Development (Dev) und Operations (Ops) von der Anforderungserhebung über die Implementierung hin zum Betrieb der Anwendung.
Bei der Auswahl der Systeme sollte man sich zunächst auf diejenigen konzentrieren, bei denen oft Änderungen passieren oder bei denen Änderungen lange dauern, die aber wertvoll sind. Dabei muss man sich die folgenden Fragen stellen: Figur 7: Geeignete DevOps-Kandidaten finden
- Wie häufig kommt es zu Änderungen?
- Wie viele Änderungsanfragen und Beschwerden gab es?
- Wie schnell landen Änderungen in Produktion? Wie ist die durchschnittliche Wartezeit auf Änderungen?
- Welche Schäden oder verpasste Möglichkeiten resultierten aus der Wartezeit?
- Wie hoch der Business-Value des zu betrachtenden Systems?
In Figur 7 wird gezeigt, wie ich die für DevOps geeignetsten Kandidaten, in grün markiert, in einem Unternehmen finde. Betrachtet man die beide Dimensionen durchschnittliche Dauer und Anzahl der Änderungen, lassen sich Systeme mit geringer Änderungsrate, geringer Wartezeit und niedrigem Business-Value streichen. Das, was übrig bleibt, ist die DevOps “Strikezone”. Dort befinden sich die besten Kandidaten, bei denen DevOps die größte Hebelwirkung entfalten kann und bei denen ich mit einer DevOps-Transformation weniger Abhängigkeiten und Übergaben bekomme und damit besonders viel Benefit erhalte. Als positiven Nebeneffekt mache ich diese Systeme gleichzeitig zu guten Outsourcing-Kandidaten.
Die ersten Schritte in Richtung DevOps
Hat man sinnvolle Kandidaten identifiziert, sollte man evaluieren, wie fit die zugehörigen Teams in der Thematik sind und auf welchem Niveau sich ihre Performance befindet. Einen guten Ansatz dafür bietet der DORA Quick Check. Durch eine fragenbasierte Selbsteinschätzung lassen sich innerhalb weniger Minuten erste Optimierungsvorschläge generieren. Dazu erhält man weiterführende Dokumentationen, um mehr über die Thematiken zu erfahren. Zusätzlich dazu kann man sich an den 24 DORA Capabilities und an dem Thema Minimum Viable Continuous Delivery orientieren.
Um Optimierungen umzusetzen, hat sich das Konzept des “Improvement Backlogs” etabliert. Zusammen mit dem Team erarbeitet man priorisierte Arbeitspakete, die den Arbeitsalltag nach und nach verbessern sollen.
Fazit
Die Frage nach Optimierungen und Effizienzsteigerungen der Arbeitsprozesse lässt sich nicht einfach nur durch funktionales Outsourcing beantworten. Moderne Arbeitsmethoden wie z.B. DevOps können bessere Antworten auf diese Thematik liefern. Dabei kommt den Führungskräften eine wichtige Aufgabe zuteil, die Systemlandschaft und ihre Teams entsprechend systematisch und wertstiftend zu strukturieren. All die genannten Punkte sind zwar ein erheblicher Eingriff in die Organisation, aber der Aufwand lohnt sich, um das volle Potenzial der Teams zu entfesseln.
Wie das in der Praxis funktioniert, konnten wir in der DevOps-Transformation zusammen mit RWE erfolgreich realisieren. Hast du ähnliche Vorhaben in deinem Unternehmen? Dann unterstützen wir dich gerne, damit die Umsetzung deines Projektes ein voller Erfolg wird.
