Plattformgebühren und Aufbau sind der sichtbare Teil der Integrationskosten im IT Service Management. Der größere Teil kommt, wenn Integrationen ausfallen: Die Arbeit zwischen Service Desks steht still, Service Levels werden verfehlt, Kunden bemerken es, und Menschen im ganzen Unternehmen unterbrechen ihre Arbeit, um aufzuräumen. Dieser Teil wächst mit jedem Kunden, jedem Lieferanten und jedem System, das Sie anbinden.
Sowohl die Komplexität als auch die Kosten lassen sich senken. Die Hebel sind struktureller Natur, und die meisten haben nichts damit zu tun, welche Plattform Sie kaufen.
Kernaussagen
- Integrationskosten im ITSM entstehen durch Änderungsarbeit und durch die Geschäftsunterbrechung, wenn Integrationen ausfallen, nicht durch Plattformgebühren. Plattformgebühren sind der sichtbare, kleinere Teil der Summe.
- Komplexität in einer ITSM-Landschaft hat fünf Quellen, und vier davon wachsen mit jedem Kunden oder Lieferanten, den Sie anbinden.
- Sechs Lösungsklassen setzen daran an. Fünf davon kann Ihr eigenes Team umsetzen. Die sechste verlagert den Betrieb zu einem Anbieter, der unter einem Service Level dafür verantwortlich ist.
- Monitoring verkürzt die Zeit bis zur Erkennung. Es senkt nicht die Kosten, denn der Incident tritt trotzdem ein, und der Prozess steht trotzdem still.
- Der Business Case sind die Gesamtkosten eines Ausfalls: die Wiederherstellung, die verfehlten Service Levels und Vertragsstrafen, die Kundenbeziehung und die verlorene Zeit in beiden Unternehmen. Die Engineering-Stunden sind der kleinste Teil.
Wo die Praxis beschrieben ist. Das Integration-Ops-Buch beschreibt, wie Integrationslandschaften in einem Managed Integration Service betrieben und gemessen werden. Buch herunterladen.
Plattformgebühren und Aufbau sind der sichtbare Teil der Integrationskosten im IT Service Management. Der größere Teil kommt, wenn Integrationen ausfallen: Die Arbeit zwischen Service Desks steht still, Service Levels werden verfehlt, Kunden bemerken es, und Menschen im ganzen Unternehmen unterbrechen ihre Arbeit, um aufzuräumen. Dieser Teil wächst mit jedem Kunden, jedem Lieferanten und jedem System, das Sie anbinden.
Sowohl die Komplexität als auch die Kosten lassen sich senken. Die Hebel sind struktureller Natur, und die meisten haben nichts damit zu tun, welche Plattform Sie kaufen.
Kernaussagen
- Integrationskosten im ITSM entstehen durch Änderungsarbeit und durch die Geschäftsunterbrechung, wenn Integrationen ausfallen, nicht durch Plattformgebühren. Plattformgebühren sind der sichtbare, kleinere Teil der Summe.
- Komplexität in einer ITSM-Landschaft hat fünf Quellen, und vier davon wachsen mit jedem Kunden oder Lieferanten, den Sie anbinden.
- Sechs Lösungsklassen setzen daran an. Fünf davon kann Ihr eigenes Team umsetzen. Die sechste verlagert den Betrieb zu einem Anbieter, der unter einem Service Level dafür verantwortlich ist.
- Monitoring verkürzt die Zeit bis zur Erkennung. Es senkt nicht die Kosten, denn der Incident tritt trotzdem ein, und der Prozess steht trotzdem still.
- Der Business Case sind die Gesamtkosten eines Ausfalls: die Wiederherstellung, die verfehlten Service Levels und Vertragsstrafen, die Kundenbeziehung und die verlorene Zeit in beiden Unternehmen. Die Engineering-Stunden sind der kleinste Teil.
Wo die Praxis beschrieben ist. Das Integration-Ops-Buch beschreibt, wie Integrationslandschaften in einem Managed Integration Service betrieben und gemessen werden. Buch herunterladen.
Wo sich Integrationskosten in einer ITSM-Landschaft ansammeln
Integrationskosten im IT Service Management sind der gesamte Aufwand, um Datensätze zwischen Service-Management-Systemen und den umliegenden Anwendungen, Kunden und Lieferanten in Bewegung zu bringen und in Bewegung zu halten, zuzüglich der aufgelaufenen Folgen, wenn etwas ausfällt. Dazu gehören Plattform- und Konnektivitätsgebühren, die Engineering-Arbeit, jede Verbindung anzupassen, wenn sich die Systeme an beiden Enden ändern, Incident Response und Datenabgleich, wenn ein Datenfluss ausfällt, sowie die Folgen für das übrige Unternehmen, solange er steht.
Die letzten beiden dominieren. Eine Ticket-Integration, die elf Monate fehlerfrei läuft und an einem Tag während des Monatsabschlusses eines Kunden ausfällt, hat an diesem einen Tag mehr gekostet als in den elf Monaten zuvor, und der größte Teil dieser Kosten ist außerhalb der IT angefallen.
Was ein einziger Integrationsausfall wirklich kostet
Der Business Case für weniger Integrationskomplexität wird meist in Engineering-Stunden geschrieben, und das ist seine schwache Fassung. Wenn eine Integration ausfällt, reichen die Kosten weit über die IT hinaus. Prozesse stehen still und werden durch manuelle Arbeit ersetzt. Entscheidungen beruhen auf verspäteten oder falschen Daten, Rechnungen gehen fehlerhaft hinaus, und Aufträge gehen verloren. So sieht das bei einem Service Provider aus.
Eine Ticket-Integration zwischen Ihrem Service Desk und dem ITSM eines Kunden fällt an einem Dienstagmorgen aus. Vier Stunden lang erreichen dessen Incidents Ihre Queue nicht. Ihre Uhr für die Erstreaktion läuft gegen Arbeit, die Sie nicht sehen können, und so wird das Service Level bei Tickets verletzt, die Ihr Team nie anfassen konnte. Der Vertrag sieht eine Strafe vor. Ihr Service Delivery Manager verbringt die Woche mit dem Incident-Bericht. Bei der Vertragsverlängerung ist das die Geschichte, die der IT-Leiter des Kunden seinem eigenen Vorstand erzählt.
Vier Stunden Ausfall. Ein verletztes Service Level, eine Vertragsstrafe, ein beschädigtes Verlängerungsgespräch, eine Woche Aufmerksamkeit einer erfahrenen Führungskraft und die Arbeit, die die Teams des Kunden nicht erledigen konnten, während ihre Incidents unbeantwortet blieben. Die Engineering-Stunden für die Behebung sind die kleinste Zahl in dieser Aufzählung. Der Business Case sind die Gesamtkosten, und deshalb ist Prävention ein kaufmännisches Argument. SLA-Verletzungen an der Quelle verhindern erläutert die Mechanik im Detail.
Und es wiederholt sich. Jeder neue Kunde bringt eine weitere Verbindung mit, die auf dieselbe Weise ausfallen kann.
Welche Lösungen eignen sich am besten für eine komplexe Integrationslandschaft?
Sechs Lösungsklassen setzen an der Integrationskomplexität an, und sie wirken auf unterschiedlichen Ebenen. Die meisten Landschaften brauchen mehr als eine.
1. Ein einheitliches Hub-and-Spoke-Verbindungsmuster. Eine Integration, die unabhängig von der Plattform mehrere Endpunkte erreicht, macht aus der Anbindung einer weiteren Partei einen Konfigurationsschritt statt eines Punkt-zu-Punkt-Aufbaus. Jedes System wird einmal angebunden, an das Muster. Routing, Transformation und Fehlerbehandlung liegen dann an einer Stelle, und genau darum geht es bei diesem Modell. Das ist der größte strukturelle Hebel, den es gibt, weil die Landschaft nicht mehr überproportional mitwächst, wenn das Geschäft wächst.
2. Eine Integrationsplattform. Zentrale Konnektivität, vorgefertigte Connectoren und einheitliches Monitoring über alle Datenflüsse. Das ist die am häufigsten gegebene Antwort, und sie ist eine echte. Die wichtigsten ITSM-Integrationstools vergleicht die vier Produktkategorien, die ITSM-Teams zur Verfügung stehen: native Plattform-Connectoren, spezialisierte Sync-Engines, universelle iPaaS und Managed Services.
3. Architekturdisziplin. Ereignisgesteuerte Muster statt synchroner Batch-Jobs, versionierte Schnittstellenverträge und Entkopplung, damit eine Änderung auf der einen Seite keine Änderung auf der anderen erzwingt. Das Integration-Ops-Buch behandelt Veränderung als Designanforderung.
4. Konsolidierung der Tools. Jedes redundante Tool in der Landschaft bedeutet weitere Verbindungen, die gepflegt werden müssen. Wer sich überschneidende Einzellösungen abschaltet, entfernt Integrationspunkte ganz. Damit ist dies der einzige Schritt, der Komplexität durch Weglassen reduziert. Er amortisiert sich auch am schnellsten, denn eine Verbindung, die Sie nicht mehr betreiben, verursacht keine Betriebskosten.
5. Governance und Verantwortung. Ein benannter Verantwortlicher für jede Integration, ein aktuelles Inventar und dokumentierte Daten-Mappings. Wo mehrere externe Lieferanten beteiligt sind, gibt ein Service Integration and Management (SIAM) Framework dieser Governance eine Form. Eine Landschaft, in der sich die Zuständigkeit erst während eines Incidents klärt, bezahlt für diese Klärung jedes Mal.
6. Ein betriebener Service. Monitoring, Incident Response und das Auffangen von Veränderungen gehen an einen Anbieter, der unter einem Service Level dafür verantwortlich ist. So bindet die Landschaft nicht länger das Team, das eingestellt wurde, um das Geschäft weiterzuentwickeln.
Die ersten fünf können Sie selbst umsetzen. Die sechste ist eine Entscheidung darüber, wer sie umsetzt.
Warum die Standardantwort für ITSM-Landschaften unvollständig ist
Fragt man die meisten Quellen, was eine komplexe Integrationslandschaft in den Griff bekommt, erhält man die Optionen 2 und 3: eine Plattform einführen, ereignisgesteuerte Architektur ergänzen, die APIs sauber verwalten. Dieser Rat ist richtig, und er wurde für Integrationen innerhalb einer einzigen Organisation geschrieben.
ITSM-Landschaften liegen häufig nicht innerhalb einer einzigen Organisation. Die Tickets eines Service Providers wandern in das ServiceNow eines Kunden. Die Incidents eines Kunden kommen aus dessen Jira Service Management. Ein IT-Team im Unternehmen tauscht Datensätze mit Lieferanten aus, die etwas völlig anderes einsetzen. Ab diesem Punkt gelten drei Annahmen hinter der Standardantwort nicht mehr. Den Release-Kalender auf der anderen Seite kontrollieren Sie nicht. Ihren Schnittstellenvertrag können Sie einer Partei, die ihm nicht zugestimmt hat, nicht auferlegen. Und wenn der Datenfluss zwischen zwei Anbietern abbricht, steht im Architekturdiagramm nicht, wer ihn wiederherstellt. Mit der Standardantwort werden die Verbindungen gebaut, aber über das, was entscheidet, ob sie weiter funktionieren, haben Sie keine Kontrolle.
Das Integration-Ops-Buch behandelt dies unter dem Begriff Passive Party Management. Der Ansatz geht davon aus, dass ein externes System variieren wird. Sie entwerfen Verträge und Dokumentation, die das erwartete Verhalten beschreiben, machen die Integrationsschnittstelle tolerant gegenüber harmlosen Abweichungen, ohne dass sie Breaking Changes übersieht, und machen Onboarding, Änderungsanfragen und Stilllegung für externe Parteien zu strukturierten Prozessen.
Deshalb gehören Governance und Betriebsmodell neben Plattform und Architektur in die Antwort. Die technische Ebene ist weitgehend gelöst. Selten gelöst ist die Frage, wer das Ganze am Laufen hält, wenn eine dieser Parteien etwas ändert, und in den meisten ITSM-Landschaften lautet die ehrliche Antwort: ein paar Menschen, die bereits eine Vollzeitstelle haben. Das ist eine riskante Ausgangslage, und mit jedem angebundenen Kunden wird es schwerer, sie zu verlassen.
Die fünf Quellen der Komplexität in einer ITSM-Landschaft
Vielfalt der Plattformen. Ihr Service Desk, die Service Desks Ihrer Kunden und die Ihrer Lieferanten sind selten dasselbe Produkt. Jede Paarung hat ihr eigenes Feldmodell, ihr eigenes Verständnis davon, was ein Incident ist, und ihren eigenen Release-Zeitplan.
Zahl der angebundenen Parteien. Jeder Kunde oder Lieferant, der zur Landschaft hinzukommt, bedeutet eine weitere Verbindung, einen weiteren Datenvertrag und einen weiteren Eskalationspfad. Er erzeugt außerdem eine zweite Version derselben Datensätze, und genau daher kommt der Abgleichaufwand. Visa von Paulig hat das Symptom benannt:
„Beide Parteien hatten ihre eigene Wahrheit, wie eigene Ticketsysteme.“ -- Visa, Paulig
Anhäufung von Punkt-zu-Punkt-Verbindungen. Wenn jede Verbindung einzeln gebaut wird, wächst die Landschaft schneller als die Kundenliste. Zehn einzeln angebundene Kunden sind zehn Aufbauprojekte, zehn Monitoring-Konfigurationen und zehn Upgrade-Pfade. Integration von MSP-Ticketsystemen zeigt, wie sich PSA, RMM und das ITSM der Kunden in einer Landschaft aufschichten.
Vielfalt der Anforderungen. Vertragliche Unterschiede zwischen Kunden werden zu technischen Unterschieden in der Integration: andere Felder, andere Prioritäts-Mappings, andere Service-Level-Uhren, andere Aufbewahrungsregeln.
Änderungstempo. Service-Management-Plattformen releasen regelmäßig, Kunden wechseln die Plattform, APIs werden abgekündigt. Jedes dieser Ereignisse ist irgendwo in der Landschaft eine Wartungspflicht.
Vier dieser fünf Quellen wachsen mit dem Geschäft. Das ist das strukturelle Problem, und deshalb werden Landschaften, die bei fünf Kunden noch überschaubar waren, bei zwanzig unbeherrschbar, ohne dass irgendetwas schiefgegangen wäre. Wenn Sie Ihre eigene Landschaft bewerten möchten, bevor Sie entscheiden, was zu tun ist, beschreibt unser Assessment der Integrationskomplexität die Diagnose.
Warum Monitoring die Kosten nicht senkt
Die meisten Unternehmen reagieren auf Integrations-Incidents, indem sie die Transparenz verbessern. Dashboards, Alerting, eine Statusseite. Das lohnt sich, und es löst ein anderes Problem, als die meisten annehmen.
Monitoring verkürzt die Zeit bis zur Erkennung. Es senkt weder die Zahl der Incidents, noch verändert es, was ein Incident kostet, wenn er eingetreten ist. Der Datenfluss stand trotzdem still. Die Tickets kamen trotzdem nicht an. Die Service-Level-Uhr lief trotzdem.
Wer Ausfälle schneller erkennt, verkürzt die Störung. Den Incident verhindert das nicht, und im Incident liegen die Kosten. Wenn Ihre Integrations-Incidents schneller gefunden werden als vor einem Jahr, ihre Zahl aber nicht gesunken ist, haben sich die Kosten kaum bewegt. Prävention entsteht durch Verantwortung, das Auffangen von Veränderungen und ein Design, das hält, wenn sich ein angebundenes System ändert, und genau daran setzen die folgenden Schritte an. Den Wandel beschreiben wir in proaktives Monitoring für IT-Service-Integrationen.
Sechs Schritte, die Kosten und Komplexität von ITSM-Integrationen senken
1. Punkt-zu-Punkt-Aufbauten durch ein Verbindungsmuster ersetzen
Der größte strukturelle Hebel. Die Anbindung eines Kunden wird zur Konfiguration gegen ein Muster, das bereits existiert. Die Landschaft hört auf, sich aufzuschichten, und mit ihr der Aufwand für Monitoring, Upgrades und Dokumentation. Visa von Paulig hat die Wirkung beschrieben:
„Skalieren ohne individuelle Entwicklung. Das schätze ich an ONEiO wirklich. Es ist ziemlich einfach.“ -- Visa, Paulig
2. Den Datenvertrag vor der Verbindung standardisieren
Einigen Sie sich auf ein kanonisches Modell dafür, was ein Incident, ein Change und ein Service Request enthalten, und mappen Sie jeden Kunden einmal darauf. Die Alternative, jeden Kunden auf jeden anderen Kunden zu mappen, ist der Punkt, an dem die Vielfalt der Anforderungen zu dauerhafter Wartung wird.
3. Jeder Integration einen Verantwortlichen zuweisen
Das Integration-Ops-Buch ist hier sorgfältig, und das sollten Sie auch sein. Sie brauchen nicht unbedingt eine eigene Abteilung, aber Sie brauchen eine Gruppe, die die Integrationsfähigkeit gemeinsam verantwortet, und darin einen benannten Integration Owner, der für den Lebenszyklus bestimmter Datenflüsse verantwortlich ist. Entscheidend ist, dass die Verantwortung existiert und ausdrücklich geregelt ist, bevor ein Incident sie dringend macht.
4. Schnittstellen als stabile Verträge behandeln und Änderungen planbar machen
Behandeln Sie eine Schnittstelle zwischen zwei Organisationen als Vertrag. Versionieren Sie sie, unterstützen Sie während einer Übergangsphase Alt und Neu parallel, und abonnieren Sie die Release Notes jeder angebundenen Plattform. Behandeln Sie die angekündigte API-Abkündigung eines Partners als terminierte Aufgabe mit einem Verantwortlichen. Veränderung ist in dieser Arbeit die Konstante, und eine Landschaft, die um diese Tatsache herum gestaltet ist, fängt sie zu einem Bruchteil der Kosten auf. Das ITSM-Integrations-Playbook behandelt die Praktiken der Reihe nach.
5. Nachrichten vorhalten, statt sie zu verlieren
Wenn ein angebundenes System ausfällt, entscheidet eine Frage darüber, ob aus einer Störung ein Incident wird: Werden die während des Ausfalls aufgelaufenen Nachrichten automatisch wiederhergestellt oder von Hand nacherfasst? Der manuelle Abgleich nach einem Ausfall dauert regelmäßig länger als der Ausfall selbst.
6. Prüfen, wie sich die Preisgestaltung mit jedem neuen Kunden verhält
Native ITSM-Connectoren werden üblicherweise pro ausgehendem Aufruf abgerechnet. ServiceNows eigenes Vertragsaddendum definiert eine Integration Hub Transaction als „any outbound call originating from Integration Hub, Flow Designer, Remote Tables, or Orchestration“ (jeder ausgehende Aufruf aus Integration Hub, Flow Designer, Remote Tables oder Orchestration) (ServiceNow-Addendum). Ein Flow in einer Schleife verbraucht also eine Transaktion pro Datensatz, und jeder erneute Versuch eine weitere. Sync-Tools rechnen pro konfigurierter Verbindung ab. Beides ist bei zwei Kunden vertretbar und verhält sich bei zwanzig unterschiedlich. Bidirektionale Ticket-Synchronisation für IT Service Provider beschreibt die Muster hinter diesen Optionen.
Vorher und nachher
Was sich in einer ITSM-Landschaft ändert, wenn die sechs Schritte umgesetzt sind. Keine dieser Zeilen beschreibt eine neue Plattform.
„Wir hatten viel Brandbekämpfung ... immer dieselben Probleme.“ -- Gabriel, Trumpf
„So etwas wie vor fünf oder vier Jahren hören wir heute nicht mehr.“ -- Gabriel, Trumpf
ONEiO betreibt dieses Modell als Managed Integration Service für Service Provider und IT-Teams in Unternehmen. Wir betreiben Ihre Integrationen, Sie liefern Ihre Services: Any-to-any-Konnektivität, damit ein neuer Kunde keinen weiteren Aufbau bedeutet, 24/7-Monitoring mit proaktiver Eskalation, persistente Warteschlangen, damit Nachrichten einen Ausfall auf beiden Seiten überstehen, und ein Service Level, das für die Integrationen selbst gilt.
Fazit zur Senkung von Integrationskomplexität und Integrationskosten im ITSM
Ihr größter Integrationskostenblock im IT Service Management liegt nicht in der Plattform oder dem Softwareabonnement. Er liegt in der Zahl der einzelnen Dinge, die Ihr Team pflegt, im Änderungstempo der Systeme um sie herum und darin, was mit dem übrigen Unternehmen geschieht, solange ein Datenfluss steht.
Ihn zu senken ist strukturelle Arbeit. Sie erfordert ein einheitliches Hub-and-Spoke-Verbindungsmuster, ein kanonisches Datenmodell, weniger sich überschneidende Tools, benannte Verantwortung, versionierte Schnittstellen, Nachrichten, die einen Ausfall überstehen, und ein Service Level, das für die Verfügbarkeit der Integrationen gilt. Eine Plattform und eine gute Architektur sorgen dafür, dass Ihre Integrationen gebaut und überwacht werden. Den Großteil der Kosten verhindern sie nicht, denn der entsteht, wenn etwas ausfällt, und das hängt davon ab, wer das Ergebnis betreibt und ob er dafür verantwortlich ist, dass es weiterläuft.
Bilden Sie Ihre Ticket-Flüsse ab. Vereinbaren Sie ein 30-minütiges Gespräch, und wir gehen gemeinsam Ihre Kundenverbindungen durch und zeigen, wo sich die Kosten ansammeln.
