So berechnen Sie die Total Cost of Ownership von Integrationen

Was haben Ihre Software- und Systemintegrationen Sie im vergangenen Jahr gekostet?

Die meisten IT-Verantwortlichen können diese Frage beantworten, und die meisten liegen weit daneben, ohne es zu merken. Sie wissen, was sie für Plattformen bezahlt haben, ungefähr wie viel Entwicklerzeit der Aufbau gebunden hat, und welche Wartungsarbeit danach anfiel. Was ihnen entgeht, kommt nach dem Go-live und steht in keiner Budgetzeile: was es das Unternehmen kostet, wenn eine Integration ausfällt. Das ist meist die größere Zahl, und sie wächst mit der Zeit weiter.

Kernaussagen

• Die Total Cost of Ownership (TCO) einer Integration besteht aus drei Töpfen: dem Aufbau, dem Betrieb und der Geschäftsunterbrechung, wenn sie ausfällt. Die meisten Business Cases zählen den ersten und einen Teil des zweiten.
• Der Aufbau ist ein einmaliger Kostenblock. Betrieb und Unterbrechungen summieren sich, solange die Integration existiert, und bei einer funktionierenden Integration sind das Jahre.
• Unterbrechungskosten fallen außerhalb der IT-Budgets an. Verlorene Produktivität, Entscheidungen ohne verlässliche Informationen, verfehlte Service Levels und stockende Projekte zeigen sich als verfehlte Umsatz- und Ergebnisziele und werden selten auf eine Integration zurückgeführt.
• Am stärksten bewegen die TCO drei Variablen: die Änderungsfrequenz, die Zahl der beteiligten Systeme und Parteien und die Frage, wer verantwortlich ist, wenn etwas ausfällt.
• Das Betriebsmodell, nicht die Plattform, entscheidet, ob Sie diese Kosten selbst tragen. Wer Tools kauft, behält Betrieb und Unterbrechungen. Wer Ergebnisse kauft, verlagert sie zu einem Anbieter, zu einem planbaren Abonnement.

Das vollständige Framework. Das Integration-Ops-Buch beschreibt, wie der Lebenszyklus einer Integration in einem Managed Integration Service geplant, betrieben und gemessen wird. Buch herunterladen.

Was ist die Total Cost of Ownership einer Integration?

Die Total Cost of Ownership einer Integration sind die vollständigen Kosten dieser Integration über ihre gesamte Lebensdauer: Konzeption und Aufbau, Betrieb und Wartung bei jeder Änderung an den verbundenen Systemen sowie die geschäftlichen Folgen, wenn sie ausfällt. Lizenzgebühr und Projektbudget sind nur zwei ihrer Bestandteile.

Diese Definition ist wichtig, weil sie zeigt, wo das Geld tatsächlich liegt. Bei einer typischen Unternehmensintegration ist der Aufbau ein abgegrenztes, sichtbares, budgetiertes Ereignis. Alles danach ist diffus. Es kommt als Eskalation, als Stunden, die von anderen Projekten abgezogen werden, als Support-Ticket, das sich als Mapping-Änderung herausstellt, und als gelegentlicher Tag, an dem ein Prozess, auf den das Unternehmen angewiesen ist, einfach stillsteht. Unser Leitfaden zur Berechnung und Kontrolle der Kosten von Service-Integrationen behandelt die sichtbare Hälfte davon ausführlicher.

Die drei Kostentöpfe der Softwareintegration

Topf eins: der Aufbau

Diesen Topf zählt jedes Unternehmen bereits. Anforderungen, Design, Entwicklung, Tests und der Abstimmungsaufwand, bis sich zwei oder mehr Parteien auf einen Datenvertrag geeinigt haben.

Er ist zählbar, weil er einen Anfang und ein Ende hat. Ein Projekt wurde eröffnet und geschlossen, und im Finanzsystem steht eine Zahl. Für die meisten Unternehmen ist das der gesamte Business Case der Integration.

Das Integration-Ops-Buch beschreibt projektbasierte Integrationsarbeit als eine als Prozess getarnte Falle. Die Falle besteht nicht darin, dass das Projekt zu viel kostet. Sie besteht darin, dass das Projekt endet und die Integration nicht.

Topf zwei: der Betrieb

Am Tag nach dem Go-live wird das Projektteam aufgelöst und neu eingesetzt. Die Integration läuft weiter. Eine Zeit lang.

Dann wird eines der verbundenen Systeme aktualisiert. Ein Partner ändert eine API. Jemand fügt ein Feld hinzu. Ein Zertifikat läuft ab. Eine Lastspitze, die niemand modelliert hat, trifft an einem Montagmorgen ein. Jedes dieser Ereignisse ist klein. Jedes holt jemanden zurück. Die Betriebskosten haben vier Bestandteile, und meist steht nur der erste im Budget:

• Plattform und Infrastruktur. Lizenz, Konnektivität, Umgebungen. Die sichtbare Zeile.
• Monitoring und Incident Response. Jemand muss es bemerken, und jemand muss verfügbar sein, um zu handeln.
• Änderungsarbeit. Versions-Upgrades, Schemaänderungen, neue Felder, neue Endpunkte, erneute Authentifizierung, erneute Tests.
• Wissenspflege. Dokumentation, die aktuell bleibt, und die Tatsache, dass die Person, die die Integration gebaut hat, nicht mehr da ist.

Das Buch behandelt Veränderung als die Konstante, um die Integrationsarbeit herum gestaltet wird, und beim vierten Punkt verlieren die meisten Unternehmen die Diskussion, ohne es zu bemerken. Eine Integration, die niemand versteht, ist teurer im Unterhalt als eine dokumentierte, weil jede Änderung mit einer Untersuchung beginnt. Hier hört auch proaktives Monitoring auf, ein Dashboard zu sein, und wird zur Betriebspraxis.

Zwei der vier Punkte skalieren mit der Zahl der Integrationen. Zwei skalieren mit dem Änderungstempo der umliegenden Systeme. Eine Umgebung mit 40 Integrationen zwischen stabilen internen Systemen verursacht überschaubare Betriebskosten. Dieselben 40 Integrationen über unterschiedliche Systeme und unterschiedliche Organisationen hinweg (Kunden, Partner, Lieferanten, Behörden), die jeweils nach einem Zeitplan releasen, den Sie nicht kontrollieren, sind ein völlig anderes Geschäft.

Topf drei: Geschäftsunterbrechung

Diesen Topf zählt niemand, und er ist meist der größte.

„Wenn Integrationen ausfallen, bricht die Hölle los.“ -- Hanna, DNV

Eine Systemintegration existiert, weil ein Geschäftsprozess darauf angewiesen ist, dass Daten eine Grenze überqueren. Fällt sie aus, steht der Prozess still, und der Schaden reicht weit über das Team hinaus, das sie wiederherstellt. Die Engineering-Stunden für die Behebung sind real, und sie sind der kleinste Teil dessen, was der Ausfall gekostet hat. Der größere Teil trifft das ganze Unternehmen:

• Die Produktivität sinkt. Prozesse brechen ab, manuelle Arbeit ersetzt sie, und wer ohne die Daten nicht arbeiten kann, wartet.
• Entscheidungen werden im Blindflug getroffen. Wenn niemand sicher ist, welche Informationen stimmen, verlangsamen sich Entscheidungen oder beruhen auf Daten, die sich als falsch herausstellen.
• Service Levels werden verfehlt. SLA-Verletzungen ziehen Vertragsstrafen nach sich, und das nächste Service Review beginnt mit dem Incident statt mit der Roadmap.
• Umsatz geht verloren. Wenn Kassensysteme nicht mehr kommunizieren oder eine Online-Bestellung nicht abgeschlossen werden kann, ist der Verkauf verloren, nicht verschoben.
• Sicherheits- und Compliance-Risiken wachsen. Sicherheitsvorfälle und nicht bestandene Audits folgen Integrationen, die niemand im Blick hat.
• Strategische Arbeit stockt. Projekte warten, während Brände gelöscht werden, und Kunden, die den Ausfall spüren, sehen sich nach Alternativen um.

Bei Service Providern zeigt sich dasselbe Muster in der Marge, die Perspektive, die wir in wie MSPs durch Managed Integrations Kosten senken einnehmen. Keine dieser Kosten taucht in einem Integrationsbudget auf. Sie zeigen sich als verfehlte Umsatz- und Ergebnisziele.

Warum Unterbrechungskosten nie im Business Case auftauchen

Niemand schreibt einen Business Case, der davon ausgeht, dass die Integration ausfallen wird. Er wird von den Menschen geschrieben, die sie bauen werden, in dem Moment, in dem sie am meisten von ihrer Arbeit überzeugt sind, und die stillschweigende Annahme lautet, dass gut gemachte Arbeit erledigt bleibt. Für Ausfälle zu budgetieren hieße, etwas einzuplanen, von dem alle hoffen, dass es nicht eintritt, also bleibt es draußen. Die Realität sieht anders aus, und die Lücke kommt als Überraschung: Erwartungen, die nicht erfüllt werden, und Zusagen, die sich nicht halten lassen.

Der Zeitpunkt verschärft das. Vor dem Go-live sind die einzigen Kosten einer Integration Arbeitszeit, und Arbeitszeit lässt sich gut planen. Nach dem Go-live kehrt sich das Profil um. Der Personalaufwand fällt fast auf null, weil das Team aufgelöst wird, und schnellt dann unregelmäßig hoch, wenn Eskalationen Leute zurückholen. Zwischen diesen Spitzen sammeln sich Unterbrechungskosten in einem Tempo, das niemand misst, weil kein einzelner Incident groß genug für eine Überprüfung ist und keine Berichtslinie sie zusammenführt.

Dazu kommt eine Verantwortungslücke. Der Aufbau hat einen Verantwortlichen. Der Betrieb meist nicht. Das Integration-Ops-Buch benennt genau deshalb den Integration Owner als eigene Rolle. Ohne diese Rolle sind die Kosten einer Integration nach dem Go-live real, aber niemandem zugeordnet, und nicht zugeordnete Kosten sind unsichtbare Kosten. Michael von MHP hat den Lebenszyklus klar beschrieben:

„Wenn man ein Haus hat, ist man mit dem Haus nie fertig.“ -- Michael, MHP

Die TCO-Berechnung in fünf Schritten

Fünf Schritte. Das Ergebnis ist eine belastbare jährliche Zahl pro Integration, die Sie auf die gesamte Landschaft hochrechnen können.

1. Den Aufbau einmal zählen. Interner Aufwand zu Vollkosten, externer Aufwand laut Rechnung, plus die Abstimmungszeit aller, die sich auf die Schnittstelle einigen mussten. Verteilen Sie das über die erwartete Lebensdauer der Integration. Drei bis fünf Jahre sind eine vernünftige Arbeitsannahme für eine Integration, die an einem laufenden Geschäftsprozess hängt.
2. Den Betrieb pro Jahr zählen. Plattform und Infrastruktur, die dieser Integration zuzurechnen sind. Dann die Änderungsarbeit. Zählen Sie, wie oft in den letzten 12 Monaten jemand diese Integration angefasst hat und was jeder Eingriff an Stunden gekostet hat. Wenn es niemand protokolliert hat, findet sich die Antwort meist im Ticketsystem unter einer anderen Bezeichnung.
3. Die Incidents pro Jahr zählen. Ausfälle, gesamte Ausfallzeit und die Stunden für die Wiederherstellung. Rechnen Sie den Datenabgleich danach ein, der regelmäßig länger dauert als die Behebung selbst.
4. Die Unterbrechung bepreisen. Benennen Sie für jeden Incident die Prozesse, die stillstanden, und die geschäftliche Folge. Verlorene Produktivität ist die erste Zeile: Menschen, die ohne die Daten nicht arbeiten können, werden trotzdem bezahlt. Falsche Rechnungen bringen Streitfälle, eine längere Days Sales Outstanding und Druck auf den Cashflow. Ein verzögertes Onboarding verschiebt Zahlungseingänge nach hinten, manchmal so weit, dass eine Kreditlinie nötig wird, und mancher Umsatz kommt nie zurück, weil ein Online-Verkauf, der nicht zustande kommt, verloren ist. Die Marge leidet durch Beraterstunden, die niemand abrechnen kann, sinkende Auslastung und kurzfristig eingekaufte externe Experten. Entscheidungen auf Basis falscher Daten haben ihren eigenen Preis. Diesen Schritt überspringen die meisten Unternehmen, und genau er verändert das Ergebnis.
5. Mit der Veränderung multiplizieren. Nehmen Sie die Betriebs- und Unterbrechungskosten und fragen Sie, was passiert, wenn sich das Änderungstempo der verbundenen Systeme verdoppelt. In den meisten Landschaften ist das bereits geschehen. Das Ergebnis ist die Zahl, mit der Sie planen sollten.

Ein veranschaulichendes Beispiel

Die folgenden Zahlen dienen der Veranschaulichung. Sie zeigen die Struktur der Berechnung und bilden kein bestimmtes Unternehmen ab. Setzen Sie Ihre eigenen Werte ein.

Zwei Dinge fallen auf, und keines davon sind die Plattformkosten. Der Aufbau, die Zeile, mit der jeder Business Case beginnt, macht weniger als ein Zehntel des ersten Jahres aus und in jedem folgenden Jahr einen kleineren Anteil. Die Geschäftsunterbrechung, die Zeile, die kein Business Case enthält, macht rund 90 Prozent der Summe aus und steigt, weil die Änderungsfrequenz steigt. Die vier Incidents kosten 3.200 an Engineering-Zeit und fast das Hundertfache an Unterbrechung.

Was die Zahl tatsächlich bewegt

Drei Variablen dominieren, und keine davon ist die Plattform. Zwei beschreiben die Umgebung, in der die Integration sitzt. Deshalb verändert die Plattformwahl die Summe so wenig.

Änderungsfrequenz. Das Tempo, in dem sich die Systeme auf beiden Seiten der Integration ändern, und wie viel Vorlauf Sie bekommen. Jeder Änderungspunkt ist ein mögliches Kostenereignis in Topf zwei und drei. Eine Landschaft, deren Systeme quartalsweise releasen, und eine, deren Systeme kontinuierlich releasen, haben bei identischer Architektur eine völlig andere Ökonomie.

Die Zahl der Systeme und Parteien. Das ist das Komplexitätsargument. Jedes zusätzliche System bringt einen weiteren Release-Zeitplan und ein weiteres Datenmodell, mit dem Sie im Gleichschritt bleiben müssen. Integrationen innerhalb Ihrer eigenen vier Wände sind ein Problem. Integrationen, die eine Unternehmensgrenze überschreiten, zu einem Kunden, Lieferanten oder Partner, sind ein anderes. Deren Release-Zeitplan und Eskalationspfad kontrollieren Sie nicht. Visa von Paulig hat die Ausgangslage an einer Lieferantengrenze so beschrieben:

„Die Lieferantenlandschaft ist ziemlich fragmentiert. Alle nutzen ihre eigenen Systeme ... das war ein ziemliches Durcheinander.“ -- Visa, Paulig

Verantwortung. Wenn eine Integration an der Grenze zwischen zwei Anbietern ausfällt, wer ist für die Wiederherstellung zuständig? Wenn die ehrliche Antwort lautet „das klären wir dann“, ist der Unterbrechungstopf größer, als jedes Modell vorhersagt, weil die Wiederherstellung mit einer Verhandlung beginnt.

Das Betriebsmodell entscheidet, ob Sie die Kosten tragen

Es gibt drei Wege, Integrationskosten zu tragen. Jeder ist legitim. Sie unterscheiden sich darin, wer Betrieb und Unterbrechungen trägt, und in welchem Umfang. Die drei Modelle haben wir in unserem TCO-Vergleich von Integrationslösungen gegeneinander gestellt, und die Entscheidung selbst beschreiben wir in Integrationen selbst entwickeln oder kaufen.

Der entscheidende Unterschied steckt in den letzten drei Zeilen. Eine Plattform zu kaufen senkt den Aufbauaufwand und lässt Betrieb und Unterbrechungen genau dort, wo sie waren. Das ist eine echte Einsparung, aber eine kleinere, als der Business Case meist annimmt, weil die Plattform nie der teure Teil war.

Wer Ergebnisse kauft, verlagert den Betrieb und einen definierten Teil des Unterbrechungsrisikos zu einem Anbieter, der vertraglich dafür verantwortlich ist. Diesen Unterschied arbeiten wir in Anbieter von Integrationsdiensten im Vergleich heraus. Die Kosten werden zu einer Abonnementzeile, die sich auch bei schnellerem Wandel berechenbar verhält, und genau diese Eigenschaft erwartet das Finanzwesen von dieser Kategorie.

ONEiO arbeitet als Managed Integration Service nach diesem dritten Modell. Wir betreiben Ihre Integrationen, Sie liefern Ihre Services: Die Plattform und ihr 24/7-Betrieb liegen bei uns, zusammen mit dem Expertenteam, das Veränderungen auffängt, unter einem Service Level, zu einem Abonnementpreis, der sich nicht bewegt, wenn sich Ihre Systeme bewegen. Das ist die konkrete Aussage, und sie lässt sich an der obigen Berechnung überprüfen.

Fazit zur Total Cost of Ownership von Integrationen

Jedes Unternehmen zählt den Aufbau. Weniger zählen den Betrieb. Fast niemand bepreist die Unterbrechung, und deshalb sind Business Cases für Integrationen zuverlässig zu optimistisch und Integrationsbudgets zuverlässig überschritten.

Wenden Sie die fünf Schritte zuerst auf eine reale Integration in Ihrer Landschaft an, bevor Sie sie auf das ganze Portfolio übertragen. Die erste ehrliche Zahl reicht meist, um das Gespräch zu verändern, weil sie die Diskussion von der Frage, was Integration die IT kostet, zu der Frage verschiebt, was sie das Unternehmen kostet.

Das Risiko ist nicht der Go-live. Das Risiko ist der laufende Betrieb.

Sehen Sie, wie das für Ihre eigene Landschaft aussieht. Vereinbaren Sie ein 30-minütiges Gespräch mit einem Integrationsspezialisten und gehen Sie die Berechnung mit Ihren Zahlen durch.