Die wichtigsten Erkenntnisse
Systemintegratoren (Capgemini, Deloitte, IBM, Accenture, Infosys, HCL, TCS und andere) sind projektförmig aufgestellte Anbieter. Sie sind hervorragend bei einmaligen Transformationen und strukturell fehl am Platz bei laufender Integrationsarbeit.
Die Diskrepanz zeigt sich als Wartungs-Backlog. SI-Engagements enden bei der Übergabe. Jede darauffolgende Änderung wird zu einem neuen Projekt, das zu Tagessätzen kalkuliert und angeboten wird. Die Kosten für den Betrieb der Integration über den SI liegen über einen Drei-Jahres-Horizont typischerweise beim Drei- bis Vierfachen der Kosten für ihren Aufbau.
Managed-Integration-Services wie ONEiO liefern die Ergebnisse, für die Sie einen SI beauftragen würden – über ein kontinuierliches Servicemodell statt über ein Projekt-Engagement. Gleiches Ergebnis. Anderes Betriebsmodell. Andere Ökonomie.
Das ist kein Argument dafür, dass SIs falsch liegen. Sie bleiben der richtige Partner für Transformationsprogramme, ERP-Rollouts und komplexe einmalige Builds. Die Diskrepanz besteht speziell bei kontinuierlicher Integrationsarbeit.
Entscheiden Sie nach der Art der Arbeit. Projektarbeit geht an einen SI. Operative Integrationsarbeit geht an einen Managed Service. Die meisten Unternehmen brauchen beides.
Systemintegratoren haben das Integrations-Ökosystem aufgebaut. Capgemini, Deloitte, IBM, Accenture, Infosys, HCL, TCS und die übrigen namhaften globalen SIs liefern weiterhin hervorragende Transformationsarbeit. Wir haben eine bestehende Übersicht über die führenden globalen Systemintegrator-Unternehmen, die die Kategorie im Detail behandelt.
Dieser Artikel stellt eine andere Frage. Nicht, welcher SI der beste für Ihr Transformationsprogramm ist. Die Frage lautet: Wenn Integrationsarbeit Teil Ihres Tagesgeschäfts ist statt eines einmaligen Projekts – ist das SI-Modell die richtige Form dafür?
Für die meisten Unternehmen lautet die ehrliche Antwort nein. Das ist das Argument dafür, Ihre Integrationsarbeit an ein anderes Betriebsmodell zu leiten und gleichzeitig Ihre SI-Beziehung für die Arbeit zu erhalten, in der sie wirklich am besten ist.
Worin Systemintegratoren hervorragend sind
Systemintegratoren sind Beratungen, die darauf ausgerichtet sind, komplexe Multi-System-Engagements als Projekte zu liefern. ERP-Rollouts. Cloud-Migrationen. Branchenspezifische Plattform-Implementierungen. Systemkonsolidierung nach einer Fusion. Die Arbeit, die neun Monate lang hundert Spezialisten braucht und sie danach nicht mehr braucht.
Das Modell ist Bench-basiertes Talent, Projektmethodik, Statement-of-Work-Vertragsgestaltung. Darin sind SIs hervorragend. Die Kategorie existiert, weil keine andere Delivery-Form für einmalige Transformation genauso gut funktioniert. Für Transformationsarbeit sind SIs selten die falsche Wahl. Die meisten großen Unternehmen werden auf unbestimmte Zeit weiter mit ihnen arbeiten.
Die Frage, die dieser Artikel stellt, ist enger gefasst. Ist das SI-Modell speziell für Integrationsarbeit die richtige Form?
Warum das SI-Modell bei Integrationsarbeit versagt
Die meisten Unternehmensintegrationen enden nicht. Sie entwickeln sich weiter.
Das Buch „Integration Ops" beginnt mit der Diagnose. Kapitel 1 benennt das Muster: Integrationen werden als einmalige Lieferungen behandelt, als Punkte auf einer To-do-Liste. Sind sie einmal als erledigt markiert, tritt die Integration in den Hintergrund. Monate später, wenn sie ausfällt, haben die Menschen, die sie gebaut haben, möglicherweise bereits das Unternehmen verlassen. Die Dokumentation ist dünn. Das Monitoring ist dünn. Teams kämpfen unter Druck darum, Probleme zu diagnostizieren, und lernen dabei oft zum ersten Mal etwas über das Design und die Abhängigkeiten der Integration – während sie bereits lichterloh brennt.
Das Buch nennt projektbasierte Delivery eine Falle, die als Prozess getarnt ist. Die Logik erscheint schlüssig. Den Bedarf definieren, die Arbeit planen, die Verbindung bauen, testen, deployen, das Projekt abschließen. Auf dem Papier ordentlich und beruhigend. In der Praxis verhalten sich Integrationen selten wie isolierte Arbeitspakete. Sie leben in den Zwischenräumen zwischen Systemen, Teams und manchmal ganzen Unternehmen. Sie tragen Verantwortungen, die jedes einzelne Projekt überdauern. Sobald Sie sie als temporäre Anstrengungen behandeln, garantieren Sie fast schon langfristige Fragilität.
Eine schnelle Integration zur Verbindung zweier Ticketing-Systeme wird langsam zu einem wiederkehrenden Engpass bei jeder Systemänderung. Ein Fluss, der nie vollständig dokumentiert wurde, verwandelt sich in eine Black Box, die niemand anfassen will. Eine Schnittstelle, ursprünglich für einen Kunden gebaut, wird still und heimlich für andere wiederverwendet, ohne ihren Support zu erweitern – wodurch unbekannte Abhängigkeiten und unsichtbare Risiken entstehen. Mit der Zeit hinterlässt jedes Projekt einen kleinen Haufen Komplexität.
Der SI hat das Projekt abgeschlossen. Der SI ist nicht darauf ausgelegt, die nächsten zehn Jahre mit dem Projekt zu leben. Das ist die Lücke, und sie schließt sich nicht, indem man einen anderen SI beauftragt.
Die Rechnung projektförmigen Angebots
Jede Integrationsänderung ist zu klein, um ein echtes Projekt zu sein. Aber sie hat genau die Größe, die in das Vertragsmodell eines SI passt. Also kalkuliert der SI jede einzelne, führt sie als kleines Engagement durch und gibt sie zurück. Der Kunde bezahlt für Projektstruktur bei etwas, das eigentlich kontinuierliche Betriebsarbeit ist.
Die Baukosten sind die Schlagzeilenzahl. Sie werden im Einkauf genehmigt. Sie landen in der Case Study. Die Wartungskosten über die nächsten drei Jahre liegen üblicherweise beim Drei- bis Vierfachen der Baukosten.
Das ist zum Zeitpunkt des Einkaufs nicht sichtbar. Es wird erst nach dem zweiten Jahr sichtbar, wenn die Finanzabteilung fragt, warum der Posten für die Integration größer ist als das Baubudget war. Der SI hat nicht zu viel berechnet. Der Kunde hat nicht zu wenig geplant. Das Modell selbst erzeugt dieses Ergebnis, wann immer Sie einen projektförmigen Anbieter für betriebsförmige Arbeit einsetzen.
Derselbe Punkt gilt breiter für die Integrationsökonomie. Wir behandeln die zugrunde liegende Entscheidung ausführlich in unserem Build-versus-Buy-Leitfaden für Integrationen, und unsere Übersicht „Integrations-Service-Provider im Vergleich" behandelt, wie SIs, iPaaS-Berater und Managed-Integration-Services beim Delivery-Modell zueinander stehen.
Was sich ändert, wenn Integrationsarbeit zu einem Servicemodell übergeht
Das Buch „Integration Ops" rahmt die Alternative als vier Denkverschiebungen. Vom Projekt zum Produkt. Von einmaligen Anstrengungen zu wiederholbaren Mustern. Von manuellen Fixes zu proaktiver Automatisierung. Von tribalem Wissen zu strukturierter Verantwortung.
Für Service-Provider sind die Implikationen erheblich. Mit einem Integration-Ops-Betriebsmodell können Anbieter Integrationen als Teil ihres Angebots produktisieren. Statt Integration als Verhandlungspunkt in jedem Vertrag zu behandeln – mit unsicherem Scope und Risiko –, können sie klare Integrationsoptionen mit definierten Verhaltensweisen und SLAs anbieten. Das Onboarding von Kunden und Partnern wird schneller und planbarer. Integrationen können als Teil standardisierter Service-Pakete geliefert werden, was die Time-to-Value verkürzt und die Reibung in Vertrieb und Delivery senkt.
Operativ unterstützt dieses Modell höhere SLAs über Systeme und Organisationen hinweg, weil die Integrationsebene als zuverlässiger Service im eigenen Recht konzipiert ist. Anbieter können ihren Betrieb skalieren, ohne dass die Personalstärke linear steigt, weil die Plattform einen Großteil der Komplexität absorbiert.
Für Enterprise-IT-Teams beseitigt derselbe Wandel im Betriebsmodell den Engpass, auf einen SI warten zu müssen, der jede Änderung kalkuliert und liefert. Die Integrationsfähigkeit wird zu etwas, das das Team konsumiert, statt zu etwas, für das das Team ständig neue Verträge abschließen muss.
Wie man zwischen einem SI und einem Managed-Integration-Service wählt
Drei Fragen, bevor Sie den nächsten SOW unterschreiben.
Ist das ein Projekt oder ein Betrieb? Wenn die Arbeit einen definierten Anfang, ein definiertes Ende und eine saubere Übergabe an der Grenze hat, ist es ein Projekt. Dafür sind SIs aufgestellt. Wenn die Arbeit auf absehbare Zeit durch Veränderungen hindurch weiter funktionieren muss, ist es ein Betrieb. Dafür sind SIs nicht aufgestellt.
Wie viel der letztjährigen SI-Ausgaben war Projektarbeit und wie viel war Betriebsarbeit, die zu Projektsätzen abgerechnet wurde? Die meisten CIOs haben diese Übung nicht gemacht. Nehmen Sie die letztjährigen Ausgaben mit dem SI. Markieren Sie jeden Posten als Projekt oder betrieblich. Summieren Sie die Betriebsspalte. Diese Zahl ist das, was derzeit in der falschen ökonomischen Form bezahlt wird. Sie überrascht üblicherweise diejenigen, die die Übung durchführen.
Wie sieht „Wer behebt das, wenn es bricht" in zwei Jahren aus? Unter einem SI-Engagement lautet die Antwort: ein neuer SOW, kalkuliert und geliefert zu Tagessätzen. Unter einem Managed-Integration-Service lautet die Antwort: das Service-Team, im Abonnement enthalten. Der Unterschied potenziert sich mit jeder Änderung.
Die fünf stärksten Alternativen zu SIs für Integrationsarbeit
Managed-Integration-Service (ONEiO)
Ein Managed-Integration-Service betreibt die Integration im Auftrag des Kunden. Kontinuierlich. ONEiO ist das führende Beispiel.
Das Engagement-Modell ist Service-Verantwortung statt Projekt-Delivery. Implementierung, Monitoring, Wartung, Behebung. Alles inbegriffen. Die Integration wird einmal gebaut und für immer betrieben, vom selben Team, unter einem planbaren Abonnement. Sie abonnieren kein Tool. Sie abonnieren ein Ergebnis. Ein planbarer Kostenposten, der alles abdeckt. Keine Berater-Tagessätze. Keine überraschenden Rechnungen. Kein Rätsel.
Für Datenresidenz und Compliance gibt Ihnen ein Managed Service volle Kontrolle darüber, wo Ihre Daten verarbeitet und gespeichert werden. Sichtbar, prüfbar und rechenschaftspflichtig gegenüber jedem, der fragt.
Am besten geeignet für: Enterprise-IT-Teams und Service-Provider, die geschäftskritische Integrationen betreiben – insbesondere dort, wo die Zahl der Integrationen wächst oder die Änderungsfrequenz auf einer der beiden Seiten zunimmt. Das Muster ist bei unseren Kunden gut etabliert. Unser Managed-Integrations-Ansatz für MSPs erklärt, wie die Skalierung von Kundenintegrationen als Service die kundenindividuelle Engineering-Last ersetzt, die die meisten Service-Provider beim Wachstum einholt.
iPaaS plus internes Team
Eine iPaaS-Plattform (Boomi, MuleSoft, Workato und andere) gibt Ihnen die Infrastruktur, um Integrationen zu bauen und zu betreiben. Ihr internes Team betreibt sie. Das ist ein Zwischenmodell. Der Plattform-Anbieter besitzt die Plattform-Ebene. Ihr Team besitzt die Konfiguration, den Betrieb und die Ergebnisse.
Das funktioniert, wenn Sie über kontinuierliche interne Kapazität verfügen, um die Plattform zu betreiben. Es ist dieselbe Betriebsmodell-Frage, die Teams einholt, die Sync-Tools nutzen. Die Plattform steht bereit. Die Ergebnisse liegen in Ihrer Verantwortung.
Wir behandeln die iPaaS-Entscheidung im Detail in unserem Leitfaden zu den 10 besten iPaaS-Lösungen.
Am besten geeignet für: Unternehmen mit breiten iPaaS-Anforderungen über Daten, Anwendungen, APIs und KI-Agenten hinweg und mit den Engineering-Kapazitäten, um die Plattform selbst zu betreiben.
iPaaS plus Berater-Retainer
Die iPaaS-Plattform plus ein SI oder eine spezialisierte Beratung auf Retainer-Basis, um sie zu betreiben. Das ist das faktische Modell in vielen Unternehmen, die iPaaS eingeführt haben, ohne ihre Delivery-Form zu ändern.
Es kombiniert die Plattformkosten mit den SI-Tagessatzkosten. Es löst nicht die strukturelle Diskrepanz zwischen projektförmigem Angebot und operativer Arbeit. Es mildert sie, indem es die Beteiligung der Beratung kontinuierlich statt projektweise macht, aber die Ökonomie begünstigt weiterhin die Beratung, und die Verantwortlichkeit liegt weiterhin beim Kunden.
Am besten geeignet für: Unternehmen, die bereits in iPaaS investiert haben und einen Übergangspfad benötigen, bevor sie ein vollständigeres Managed-Service-Modell in Betracht ziehen.
Selbst bauen
Für manche Teams ist die Antwort wirklich, Integrationen in-house zu bauen und zu betreiben, mit internen Engineers und Plattform-Teams. Das funktioniert, wenn die Integration ein strategisches Alleinstellungsmerkmal ist, wenn das Team die Kapazität und die Fähigkeiten hat und wenn die Änderungsrate beherrschbar ist.
Es funktioniert nicht, wenn Integration ein Mittel zum Zweck statt eine Kernkompetenz ist, wenn das Team bereits überlastet ist oder wenn die Änderungsrate die Kapazität des Teams zur Reaktion übersteigt.
Wir behandeln die zugrunde liegende Entscheidung ausführlich in unserem Build-versus-Buy-Leitfaden.
Am besten geeignet für: Organisationen, in denen Integration ein strategisches Alleinstellungsmerkmal ist und das Team die Kapazität hat, sie zu betreiben.
Spezialisierter Boutique-Integrator
Kleinere, spezialisierte Integrationsberatungen (regional oder vertikal fokussiert) sitzen zwischen den globalen SIs und den Managed-Integration-Services. Sie tendieren dazu, Projekte mit größerer Aufmerksamkeit für bestimmte Plattformen oder Branchen zu liefern, oft zu niedrigeren Tagessätzen als die globalen SIs.
Das Betriebsmodell ist weiterhin projektförmig. Der Vorteil gegenüber einem globalen SI ist die Tiefe plattformspezifischer Expertise und eine engere Arbeitsbeziehung. Der Nachteil ist derselbe wie bei jedem projektförmigen Anbieter: Jede Änderung ist ein neues Engagement.
Am besten geeignet für: Unternehmen mit spezifischen Plattformanforderungen (z. B. einem tiefen ServiceNow- oder Salesforce-Fokus), bei denen Boutique-Expertise die Betriebsmodell-Frage überwiegt.
Was sich ändert, wenn Integration zum Service wird
Der Unterschied zwischen einem SI-Engagement und einem Managed-Integration-Service liegt darin, was Sie einkaufen. Bei einem SI kaufen Sie ein Projekt. Bei einem Managed Service kaufen Sie ein Ergebnis. Drei Dinge ändern sich gleichzeitig.
Sie gewinnen Planbarkeit. Ein planbarer Kostenposten, der alles abdeckt: Implementierung, Wartung, Monitoring, Behebung. Keine SI-Tagessätze. Keine überraschenden SOWs. Kein Rätsel. Die Integrationskosten hören auf, von Quartal zu Quartal zu schwanken, weil das Modell nicht länger darauf angewiesen ist, dass Incidents für jemand anderen Umsatz erzeugen.
Sie gewinnen Transparenz. ONEiO läuft auf transparenter Integrationstechnologie. Keine Black-Box-Logik. Kein Code, den nur ein Spezialist lesen kann. Sie funktioniert mit Ihrer gesamten Umgebung – mit welchen Tools auch immer Ihr Team arbeitet, mit welchen Plattformen auch immer Ihre Partner arbeiten. Sauberere Integrationen, volle Sichtbarkeit und ein Fundament, das mit Ihrem Geschäft wächst. Für die Datenresidenz erhalten Sie volle Kontrolle darüber, wo Ihre Daten verarbeitet und gespeichert werden. Sichtbar, prüfbar und rechenschaftspflichtig gegenüber jedem, der fragt.
Sie gewinnen Ergebnisse. Die Integration liegt in unserer Verantwortung – im Betrieb und in der Rechenschaft. Ihr technisches Team muss sich nicht länger mit Integrationsproblemen befassen. Ihr Business-Team beginnt, die Ergebnisse zu sehen, die ihm versprochen wurden. Nichts bricht. Das ist die Garantie.
„Zum ersten Mal kann ich tatsächlich sehen, was meine Integrationen tun. Kein Rätselraten. Kein Warten, bis etwas kaputtgeht, um es dann zu bemerken."— IT-Verantwortlicher, globaler Managed-Services-Anbieter
Häufig gestellte Fragen
Ist ein Managed-Integration-Service immer günstiger als ein SI?
Bei einmaligen Integrationsprojekten ist der SI zum Zeitpunkt des Aufbaus manchmal günstiger. Über drei Jahre hinweg, einschließlich Wartung und Reaktion auf Änderungen, hat ein Managed Service fast immer die niedrigeren Gesamtkosten. Der Kompromiss besteht darin, dass Sie die Flexibilität aufgeben, den Anbieter mittendrin zu wechseln – was bei Integrationsarbeit selten ein tatsächlicher Vorteil ist.
Kann ein Managed-Integration-Service unsere bestehende SI-Beziehung ersetzen?
Meist nicht vollständig. SIs erledigen Arbeit, die nicht in ein Servicemodell passt: Transformationsprogramme, Custom-Entwicklung, komplexe einmalige Lieferungen. Ein Managed Service ersetzt typischerweise den laufenden Integrationsanteil einer SI-Beziehung und behält den SI für die Arbeit, in der er am besten ist.
Wird ein SI zustimmen, Integrationen zu betreiben, die er nicht gebaut hat?
Manche schon. Die meisten ziehen es vor, das Übernommene neu zu bauen, abgerechnet als neues Projekt. Ein Managed Service ist darauf ausgelegt, bestehende Integrationen zu absorbieren, statt sie neu zu bauen.
Wie schneidet ein SI im Vergleich zu iPaaS ab?
iPaaS-Plattformen (Boomi, MuleSoft, Workato) stellen die Infrastrukturebene bereit. SIs und Managed Services sind Delivery-Modelle. Sie können auf iPaaS entweder über einen SI oder über einen Managed Service aufbauen. Die Infrastruktur-Entscheidung und die Delivery-Modell-Entscheidung sind getrennte Entscheidungen. Unser Leitfaden „Integrations-Service-Provider im Vergleich" führt durch die Unterschiede.
Wie sieht die Migration von SI-gebauten Integrationen zu einem Managed Service aus?
Sie wird als Teil des Onboardings zum Managed Service abgewickelt. Die Sync-Logik wird übertragen. Die operative Verantwortung geht vom SI (oder dem internen Team des Kunden) auf den Service-Provider über. Die Zeitpläne variieren je nach Anzahl der Integrationen und Komplexität des bestehenden Setups.
Zeit für Veränderung?
SIs haben das Integrations-Ökosystem aufgebaut. Sie werden nicht verschwinden. Die Arbeitskategorien, in denen sie gewinnen – Transformation, komplexe einmalige Lieferung –, schrumpfen nicht.
Was sich ändert, ist die Erkenntnis, dass Integration als laufende Arbeit nicht in ihre Delivery-Form passt. Das tat sie nie. Es hat nur zwei Jahrzehnte und eine Handvoll neuer Betriebsmodelle gedauert, bis die Alternative überhaupt existierte.
Die Teams, die das erkennen, ersetzen ihren SI nicht. Sie leiten die richtige Arbeit an die richtige Form von Anbieter. Projektarbeit an den SI. Operative Integrationsarbeit an einen Managed-Integration-Service. Der Wartungs-Backlog hört auf zu wachsen. Die Dreifach-Kosten-Rechnung kehrt sich wieder um. Die SI-Beziehung wird stärker, weil sie für das genutzt wird, worin sie gut ist.
Zeit für Veränderung? Sprechen Sie mit uns darüber, wie eine Managed Integration für Ihre Umgebung aussehen kann.
