Forward Deployed Engineering vs. klassisches IT-Outsourcing: Welches Modell passt zu Ihrem Projekt?

Das gewählte Zusammenarbeitsmodell ist im Grunde eine Architekturentscheidung. Es bestimmt, wer die Verantwortung für technische Entscheidungen trägt und wer zuständig ist, wenn im Produktivbetrieb Probleme auftreten.

Die Entscheidung zwischen Forward Deployed Engineering und klassischem Software-Outsourcing hängt von mehr als nur dem Projektumfang oder Budget ab. Die Unterschiede zwischen beiden Modellen zeigen sich häufig dann, wenn sich Anforderungen ändern, bestehende Systeme unerwartete Abhängigkeiten mit sich bringen oder Architekturentscheidungen die Abstimmung mehrerer Teams erfordern. Wer versteht, wie die beiden Modelle in solchen Situationen funktionieren, kann als technischer Verantwortlicher besser einschätzen, welche Form der Zusammenarbeit zur eigenen IT-Umgebung und den Erwartungen an die Projektumsetzung passt.

Wie die beiden Modelle funktionieren

Beim Forward Deployed Engineering arbeiten die Ingenieure direkt in der technischen Umgebung des Kunden. Dazu gehören sowohl die Code-Repositories als auch die Staging-Systeme. Sie nehmen außerdem an Architektur- und Design-Reviews teil und tragen Verantwortung für die Ergebnisse im Produktivbetrieb, nicht nur für eine Liste vereinbarter Leistungen. Dabei ist es wichtig, dieses Modell von der IT-Personalverstärkung zu unterscheiden. Während zusätzlich eingesetzte Entwickler Aufgaben aus dem Backlog übernehmen und an die zuständigen Manager berichten, tragen Forward Deployed Engineers selbst Verantwortung für die Umsetzung.

Beim klassischen Outsourcing sind die Zuständigkeiten zwischen dem Kunden und dem ausführenden Team in der Regel klarer voneinander abgegrenzt. Der Kunde definiert die Anforderungen, während der Dienstleister die Verantwortung für einen vereinbarten Leistungsumfang übernimmt. Wesentliche Entscheidungen müssen vom Kunden genehmigt werden, der auch die Ergebnisse überprüft und abnimmt. Outsourcing-Teams können ebenfalls agile Methoden einsetzen und eng mit internen Entwicklern zusammenarbeiten. Wie intensiv diese Zusammenarbeit ausfällt, hängt jedoch meist von den vertraglichen Vereinbarungen und der Organisation der Projektumsetzung ab.

Technische Verantwortung und Verantwortung für die Umsetzung

Die entscheidende Frage ist einfach, führt später aber häufig zu Reibungsverlusten: Wer trägt die Verantwortung für das Ergebnis?

Beim klassischen Outsourcing mit fest definiertem Leistungsumfang entwickelt der Dienstleister nur das, was in den Spezifikationen festgelegt ist. Seine Verantwortung beschränkt sich auf die vereinbarten Leistungen, selbst wenn die Spezifikation fehlerhaft ist. Die daraus entstehenden Probleme muss in diesem Fall das interne Team auffangen.

Beim Forward Deployed Engineering ist die Verantwortung dagegen an das Ergebnis geknüpft. Die Ingenieure treffen Architekturentscheidungen gemeinsam mit dem internen Team und bleiben dadurch für die jeweils vereinbarten Umsetzungsergebnisse verantwortlich. Die konkreten Zuständigkeiten hängen vom jeweiligen Vertrag ab, können sich jedoch bis in den Produktivbetrieb erstrecken und auch die Fehlerbehebung und Stabilisierung umfassen. Damit dieses Modell funktioniert, muss das Unternehmen den Ingenieuren allerdings echte Entscheidungsbefugnisse einräumen. Andernfalls werden aus Forward Deployed Engineers lediglich externe Auftragnehmer, die zwar besseren Zugang zu den Systemen haben, aber trotzdem nur langsam vorankommen. Wenn sämtliche Entscheidungsrechte beim Kunden verbleiben, besteht die übertragene Verantwortung lediglich auf dem Papier.

Ein konkretes Beispiel: Ein Dienstleister soll einen bestehenden Authentifizierungsdienst anpassen. Das Entwicklungsteam verfügt möglicherweise über genügend Kontext, um eine geeignete Änderung vorzuschlagen. Dennoch kann eine Freigabe durch das interne Sicherheitsteam erforderlich sein. Auch nach dieser Freigabe bleibt der Dienstleister für die Implementierung und die Tests verantwortlich. Sind diese Zuständigkeiten nicht von Anfang an eindeutig geregelt, kann selbst eine scheinbar einfache technische Entscheidung zum Engpass werden, weil beide Seiten davon ausgehen, dass jeweils die andere für die nächsten Schritte verantwortlich ist.

Änderungen der Anforderungen und Architekturentscheidungen

Beim klassischen Outsourcing greifen bei Änderungen der Anforderungen bestimmte Planungs- und Genehmigungsprozesse. In Projekten mit fest definiertem Leistungsumfang müssen solche Änderungen möglicherweise zunächst hinsichtlich Aufwand, Kosten und Zeitplan bewertet werden, bevor die Entwicklung fortgesetzt werden kann. Das sorgt zwar für mehr Planbarkeit und erleichtert die Kostenkontrolle, kann aber die Umsetzung verlangsamen, wenn sich Anforderungen häufig ändern. Flexiblere Outsourcing-Modelle können hier Abhilfe schaffen, erfordern jedoch weiterhin eine gewisse Abstimmung zwischen Dienstleister und Kunde.

Forward-Deployed-Teams planen in kurzen Zyklen und passen ihre Prioritäten entsprechend dem Backlog an. Architekturfragen werden gemeinsam mit Produktfragen besprochen. Dadurch lassen sich bislang unbekannte Abhängigkeiten frühzeitig erkennen und die Planung entsprechend anpassen. Der wesentliche Nachteil liegt dabei in der geringeren Planbarkeit des Budgets. Bei einem Forward-Deployed-Engagement können Teamgröße und Laufzeit festgelegt werden, während der endgültige Leistungsumfang während der gesamten Zusammenarbeit offenbleibt. Für Projekte, bei denen der Umfang einzelner Funktionen im Voraus verbindlich feststehen muss, kann das eine Herausforderung darstellen.

Zusammenarbeit mit internen Entwicklungsteams

In diesem Bereich werden die Unterschiede zwischen den beiden Modellen besonders deutlich.

Beim klassischen Outsourcing erfolgt die Kommunikation häufig über festgelegte Kanäle, etwa Projektmanager, regelmäßige Besprechungen und Ticketsysteme. Das ermöglicht eine klare Trennung der Zuständigkeiten, kann aber auch zu Verzögerungen führen, wenn Fragen die Beteiligung mehrerer Teams erfordern. Direkte Kommunikationswege können solche Reibungsverluste verringern, müssen jedoch im Rahmen der Zusammenarbeit ausdrücklich vereinbart werden.

Forward Deployed Engineers kommunizieren direkt mit den Entwicklern des Kunden. Das beschleunigt die Abstimmung und Problemlösung, setzt allerdings voraus, dass das interne Team ausreichend Zeit für Reviews und technische Diskussionen aufbringt.

Die Aufteilung der Verantwortlichkeiten wirkt sich auch auf Entscheidungsprozesse aus. Beim klassischen Outsourcing ist dafür häufig eine zusätzliche Abstimmung über Unternehmensgrenzen hinweg erforderlich. Forward Deployed Engineers sind dagegen in der Regel unmittelbarer in technische Entscheidungen eingebunden und treffen diese gemeinsam mit den internen Teams.

Integrationen, Legacy-Systeme, KI und Produktivbetrieb

Bei vier häufig auftretenden Problemstellungen unterscheiden sich die Vorgehensweisen der beiden Modelle:

Integration von Unternehmenssystemen. Bei der Integration von Unternehmenssoftware kommt es häufig auf Details an, die in keiner Dokumentation festgehalten sind. Auch klassische Outsourcing-Teams können solche Besonderheiten untersuchen, sofern sie ausreichend Zugriff auf die Systeme haben und von den internen Entwicklern unterstützt werden. Für Forward Deployed Engineers ist dies meist einfacher, da sie enger mit den Personen zusammenarbeiten, die diese Systeme betreiben. So können sie undokumentierte Abhängigkeiten untersuchen und Integrationsentscheidungen anpassen, sobald Probleme auftreten.

Ein Beispiel ist die Integration eines ERP-Systems, bei der Kundenbestellungen mit einem externen Warehouse-Management-System (WMS) synchronisiert werden müssen. Die ursprünglichen Anforderungen können zunächst einfach erscheinen. Sobald beide Systeme jedoch Daten austauschen, stellt sich möglicherweise heraus, dass das ERP Änderungen an einer Bestellung zulässt, nachdem diese bereits an das Lager übermittelt wurde, während das WMS solche nachträglichen Änderungen nicht unterstützt. Um dieses Problem zu lösen, müssen die Teams vereinbaren, wie Bestelländerungen verarbeitet werden und welches System für die Aufrechterhaltung eines korrekten Datenzustands verantwortlich ist. Ähnliche Probleme können auch an anderen Stellen auftreten und dazu führen, dass die ursprünglich vorgesehenen Arbeiten noch nicht vollständig abgeschlossen sind.

Modernisierung von Legacy-Systemen. Ähnliches gilt für Legacy-Systeme. Da diese häufig verborgene Abhängigkeiten aufweisen, können Forward Deployed Engineers sie gemeinsam mit den Teams untersuchen, die für die Wartung der Systeme zuständig sind. Auf Grundlage neuer Erkenntnisse lässt sich der Modernisierungsplan entsprechend anpassen. Beim klassischen Outsourcing muss genügend Flexibilität vorhanden sein, um auf unerwartete Abhängigkeiten reagieren zu können, ohne den Projektablauf zu beeinträchtigen.

Implementierung von KI. KI-Initiativen erfordern häufig die Mitwirkung verschiedener Fachabteilungen, darunter Supportmitarbeiter und Analysten. Da Forward Deployed Engineers direkt mit diesen Teams zusammenarbeiten können, sind sie sowohl an der Entwicklung und Einführung von KI-Funktionen als auch an deren Weiterentwicklung beteiligt, wenn neue Probleme auftreten. Beim klassischen Outsourcing ist eine gezielte Abstimmung zwischen dem Dienstleister, den internen Entwicklungsteams und den Fachabteilungen erforderlich, um eine vergleichbare Zusammenarbeit zu ermöglichen.

Herausforderungen im Produktivbetrieb. Auch beim klassischen Outsourcing kann die Unterstützung im Produktivbetrieb zum vereinbarten Leistungsumfang gehören. Die Bearbeitung von Störungen erfolgt jedoch häufig nach festgelegten Eskalations- und Supportprozessen. Da Forward Deployed Engineers enger mit den internen Teams zusammenarbeiten, können sie Fehler direkt in der bestehenden Systemumgebung untersuchen und Probleme dort beheben.

Forward Deployed Engineering vs. klassisches IT-Outsourcing

Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen den beiden Modellen anhand verschiedener Kriterien zusammen:

Kosten, Koordinationsaufwand und Umsetzungsrisiken

Beim klassischen Outsourcing richten sich die Kosten nach den vertraglich vereinbarten Konditionen. Festpreisverträge bieten von Anfang an eine höhere Budgetsicherheit, können jedoch problematisch werden, wenn sich Anforderungen im Projektverlauf ändern. In solchen Fällen bieten Time-and-Materials-Modelle mehr Flexibilität. Unabhängig vom Vertragsmodell werden bestimmte Aufwände häufig unterschätzt. Dazu gehören die Vorbereitung der Anforderungen, die Koordination des Dienstleisters, Abnahmetests sowie Nacharbeiten, wenn die Erwartungen beider Seiten nicht übereinstimmen.

Beim Forward Deployed Engineering erfolgt die Abrechnung häufig auf Kapazitätsbasis. Neben den Kosten für den Dienstleister ist vor allem der Zeitaufwand der internen Entwickler ein wesentlicher Kostenfaktor. Da Forward-Deployed-Teams eng mit den internen Ingenieuren zusammenarbeiten, müssen diese Zeit für die Einarbeitung, Reviews, Architekturgespräche und gemeinsame Entscheidungen einplanen. Fehlen dafür die notwendigen Kapazitäten, wird die Zusammenarbeit zum Engpass und die Projektumsetzung leidet darunter, selbst wenn die externen Entwickler über die erforderliche technische Expertise verfügen.

Auch die Risiken unterscheiden sich zwischen den beiden Modellen. Während beim klassischen Outsourcing vor allem Lücken in den Spezifikationen und die späte Erkennung von Problemen Risiken darstellen, liegen die wesentlichen Risiken beim Forward Deployed Engineering in unklaren Entscheidungsbefugnissen und der Abhängigkeit von einzelnen Schlüsselpersonen.

Wann klassisches IT-Outsourcing die bessere Wahl ist

In manchen Fällen ist Forward Deployed Engineering nicht unbedingt die richtige Lösung:

• Wenn die Anforderungen stabil und gut dokumentiert sind

• Wenn das Projekt nur wenige Abhängigkeiten von internen Systemen aufweist

• Wenn das interne Team keine Kapazitäten für eine enge Zusammenarbeit mit dem Dienstleister hat

• Wenn die Finanzplanung einen Festpreis und einen verbindlichen Fertigstellungstermin erfordert

Die folgende Tabelle zeigt typische Projektszenarien und bewertet, wie gut sich die beiden Modelle jeweils dafür eignen:

Praktische Entscheidungshilfe

Wenn Sie überlegen, welches Modell am besten zu Ihrem Unternehmen passt, können Ihnen die folgenden Fragen bei der Entscheidung helfen:

• Wie gut kennen Sie das bestehende System? Wenn noch unbekannte Abhängigkeiten bestehen, spricht das für eine direkte Einbindung externer Ingenieure in die internen Teams
• Wie stabil sind die Anforderungen? Wenn sie weitgehend unverändert bleiben, kann ein Vertrag mit fest definiertem Leistungsumfang sinnvoll sein. Ändern sie sich dagegen ständig, benötigen Sie ein Team, das flexibel darauf reagieren kann
• Haben Ihre erfahrenen Entwickler ausreichend Zeit? Ohne diese zeitlichen Kapazitäten verliert das Forward-Deployed-Modell einen Großteil seines Mehrwerts
• Wer trägt nach der Veröffentlichung die Verantwortung für Risiken? Wenn Ihr internes Team diese Rolle nicht übernehmen möchte, ist ein Dienstleister wichtig, der auch während des Produktivbetriebs eingebunden bleibt
• Welche Vorgaben macht Ihre Budgetplanung? Wenn ein Festpreis erforderlich ist, schränkt das die Auswahlmöglichkeiten ein

Diese Fragen sollten Sie mit einem potenziellen Dienstleister besprechen, bevor Sie einen Vertrag abschließen. Dabei muss klar sein, wer Architekturänderungen genehmigt, wie mit unerwarteten Abhängigkeiten umgegangen wird und was passiert, wenn eine kritische Integration nach der Bereitstellung ausfällt. Außerdem sollten Sie klären, wie viel Zeit Ihre internen Entwickler für das Projekt aufbringen müssen. Anhand dieser Antworten können Sie beurteilen, ob das vorgeschlagene Zusammenarbeitsmodell tatsächlich zu Ihrem Unternehmen passt oder ob es nach Beginn der Entwicklung zu zusätzlichen Abstimmungsproblemen führen könnte.

Bei manchen Projekten kombinieren Unternehmen beide Modelle. Ein Forward-Deployed-Team übernimmt zunächst die Analyse und klärt die Architekturfragen. Anschließend kann ein klassischer Outsourcing-Dienstleister die klar definierten Projektbestandteile auf Grundlage eindeutiger Spezifikationen umsetzen. Damit dieser Ansatz funktioniert, ist selbstverständlich eine strukturierte Übergabe zwischen den beiden Phasen erforderlich.

Sie müssen auch nicht während der gesamten Projektlaufzeit am selben Zusammenarbeitsmodell festhalten. Stattdessen können Sie im Laufe des Projekts von einem Modell zum anderen wechseln. Entscheidend ist, dass das gewählte Modell zu den jeweils anstehenden Aufgaben passt, anstatt unabhängig von der weiteren Projektentwicklung an einem bestimmten Ansatz festzuhalten.