Bidirektionaler Ticket-Sync bewegt Incidents, Status, Anhänge und SLA-Daten in Echtzeit zwischen dem zentralen Service Desk eines IT-Service-Providers und dem ITSM jedes einzelnen Kunden. Die technische Ebene ist gelöst. Der schwierige Teil ist das Betriebsmodell rund um das Tool – und genau daran skalieren sie über Kunde Nr. 20 hinaus oder hören still und heimlich ganz auf zu skalieren.
Dieser Artikel behandelt die Tool-Entscheidung und die Betriebsmodell-Entscheidung, mit Querverweisen auf ONEiOs Framework für die schmerzlose ITSM-Integration für den Onboarding-Prozess und unsere Checkliste für die Integration neuer Kunden für die Abfolge je Onboarding.
Die wichtigsten Erkenntnisse
- Die meisten modernen Integrationslösungen können die technischen Anforderungen von IT-Service-Provider-Integrationen erfüllen. Der Unterschied im großen Maßstab liegt darin, wer die Integration Tag für Tag betreibt.
- Drei Integrationsmuster dominieren: direkte Point-to-Point-Konnektoren, Hub-and-Spoke-iPaaS und Managed-Integration-Service. Jedes passt zu einem anderen Anwendungsfall.
- Für viele wachsende IT-Service-Provider tritt eine „Integration Wall" zwischen Kunde Nr. 20 und Kunde Nr. 30 auf. Jenseits davon wird selbst betriebener Sync zu einer Wartungsfunktion, die schneller wächst als der Kundenumsatz.
- Für IT-Service-Provider, die über diese Wand hinaus skalieren, liefert ein Managed-Integration-Service niedrigere Gesamtkosten, schnelleres Onboarding und planbare Preise im Rahmen von SLA-Zusagen.
Was bidirektionaler Ticket-Sync tatsächlich leistet
Bidirektionaler Ticket-Sync ermöglicht den automatisierten Ticket-Austausch in Echtzeit zwischen dem zentralen System eines Service-Providers (z. B. ServiceNow oder Jira) und den Kundensystemen (z. B. Zendesk, Jira Service Management, Freshservice). Wenn ein Ticket im Tool des Kunden erstellt wird, erscheint es im Service Desk des Service-Providers, damit die Engineers daran arbeiten können. Wenn der Engineer des Service-Providers das Ticket aktualisiert, fließt das Update in Echtzeit zurück in die Ansicht des Kunden.
Gut gemacht, hat die technische Fähigkeit drei Komponenten.
- Zwei-Wege-Datenfluss in Echtzeit. Updates, die im Tool des Service-Providers vorgenommen werden, spiegeln sich im System des Kunden wider und umgekehrt – mit voller Status-, Kommentar-, Anhang- und SLA-Treue. Beide Seiten sehen dieselbe Wahrheit, ohne manuellen Abgleich.
- Sicherer Datenaustausch über die Organisationsgrenze hinweg. Nur relevante Informationen werden geteilt. Der Service-Provider behält eine einheitliche operative Sicht über mehrere Kunden hinweg. Jeder Kunde sieht nur seine eigenen Daten in seinem eigenen Tool.
- Prozess-Alignment zwischen zwei Zustandsautomaten. Incident-Definitionen, Prioritätsstufen, Statusübergänge und SLA-Semantik werden sauber zwischen dem Framework des Service-Providers und dem Framework des Kunden abgebildet. Ohne dieses Alignment fließen zwar die Daten, aber die Bedeutung geht in der Übersetzung verloren.
Die operative Wirkung von gut gemachtem bidirektionalem Ticket-Sync ist erheblich. IT-Service-Provider mit ausgereiften Ticket-Sync-Setups berichten von Reduktionen der Ticket-Bearbeitungszeit um 70 bis 90 % gegenüber der manuellen „Swivel-Chair"-Dateneingabe und von einer Beschleunigung des Kunden-Onboardings um 50 bis 60 % gegenüber dem Aufbau jeder Integration von Grund auf. Diese Zahlen stammen von Service-Provider-Operations-Teams, die den Wandel im Betriebsmodell vollzogen und nicht bloß einen Konnektor installiert haben.
Gängige Integrationsszenarien
Drei Szenarien decken die meisten Anwendungsfälle des Ticket-Syncs zwischen Service-Provider und Kunde ab.
Zentralisiertes Management. Der IT-Service-Provider nutzt ein Master-System (typischerweise ServiceNow oder Jira), um viele Kunden zu verwalten, von denen jeder sein eigenes IT-Service-Desk-Tool betreibt. Die Sync-Ebene fächert vom zentralen System zum Tool jedes Kunden auf – mit kundenspezifischen Feldzuordnungen, SLAs und Prozessregeln.
Brücke zwischen DevOps und IT-Support. Der Service-Provider erfasst Incidents in seinem IT-Service-Desk-Tool. Diese Incidents müssen zu einem Entwickler-Tool des Kunden (Jira Software, Azure DevOps) für die Engineering-Arbeit fließen – und wieder zurück. Dieses Muster kombiniert ITSM- und DevOps-Integration in einem bidirektionalen Fluss.
Multi-Vendor-Service-Delivery. Der IT-Service-Provider arbeitet neben anderen Service-Providern in der Umgebung des Kunden. Tickets müssen nicht nur zwischen dem Service-Provider und dem Kunden fließen, sondern über mehrere Service-Provider-Grenzen hinweg. Hier wird die Betriebsmodell-Frage akut. Der Sync ist nicht länger eine einzelne Verbindung. Er ist eine Orchestrierung mehrerer Parteien.
Unser Leitfaden mit MSP-Integrationstipps und -tools behandelt die umfassendere Integrationslandschaft, in der Service-Provider agieren.
Die besten Tools und Plattformen für bidirektionalen Ticket-Sync bei IT-Service-Providern
Vier Tools decken den Großteil der praktischen Landschaft ab.
ONEiO
ONEiO ist ein Managed-Integration-Service. Es bietet vorgefertigte, einfach konfigurierbare Konnektoren für gängige ITSM-Tools, mit Ende-zu-Ende verantwortetem Betrieb. Implementierung, Monitoring, Wartung, Behebung – alles in einem planbaren Abonnement enthalten. ONEiO fungiert als Übersetzungsschicht zwischen dem zentralen System des Service-Providers und dem Tool jedes Kunden und passt sich jeder Plattform unabhängig an, statt eine zu zwingen, die Sprache der anderen zu sprechen.
Am besten geeignet für: IT-Service-Provider mit mehr als 15 Kunden auf unterschiedlichen ITSM-Tools, bei denen die Betriebsmodell-Last des selbst betriebenen Syncs zum limitierenden Faktor für das Wachstum geworden ist. Unser Managed-Integrations-Ansatz für MSPs behandelt, wie dies die Kosten- und Skalierungskurve verändert.
Zapier
Zapier ist die bekannteste No-Code-Automatisierungsplattform am Markt. Es verbindet über 7.000 Apps durch Trigger-Action-Workflows namens Zaps, einschließlich vorgefertigter Vorlagen für populäre ITSM-Kombinationen wie Jira zu Azure DevOps und Freshservice zu den meisten großen SaaS-Tools. Es ist benutzerfreundlich, erfordert keine Programmierung und ist für nicht-technische Teams zugänglich. Für kleinere Service-Provider, die einfache Ticket-Automatisierungen betreiben, ist es wirklich nützlich.
Der ehrliche Kompromiss liegt darin, wofür Zapier gebaut wurde. Es ist allgemeine Workflow-Automatisierung, kein speziell für ITSM entwickelter Ticket-Sync. Zaps folgen einem „if this, then that"-Modell, das für unidirektionale Trigger wie „wenn ein Freshservice-Ticket erstellt wird, poste in Slack" gut funktioniert. Echter bidirektionaler Sync mit voller Status-Treue, Anhang-Round-Tripping und SLA-Weitergabe ist nicht Zapiers Stärke. Wenn die Ticket-Volumen skalieren, wird auch Zapiers Preismodell pro Task zu einem Kostenvolatilitäts-Problem für Service-Provider, die sich auf SLAs verpflichtet haben.
Am besten geeignet für: kleinere Service-Provider, die einfache unidirektionale Ticket-Automatisierungen und Benachrichtigungen betreiben, oder Teams, die einige wenige SaaS-Tools schnell und ohne Engineering-Beteiligung zusammenfügen möchten. Nicht die richtige Wahl für komplexe Multi-Client-ITSM-Umgebungen, in denen bidirektionale Treue zählt.
Syncro
Syncro kombiniert RMM, PSA und Remote-Access in einer einzigen Plattform. Es ist für kleinere Service-Provider positioniert, die den Betrieb über mehrere Kategorien hinweg konsolidieren möchten, statt spezialisierte Tools zu verbinden. Syncros Ticket-Sync ist Teil einer breiteren Betriebs-Suite, kein eigenständiges bidirektionales Integrationsprodukt.
Am besten geeignet für: kleinere Service-Provider, die eher operative Konsolidierung als Integrationstiefe wünschen.
Xurrent
Xurrent (ehemals 4me) ist eine ITSM-Plattform mit einem eingebauten „Trust"-System für direkte, sichere Konnektivität zwischen verschiedenen Xurrent-Instanzen. Das Angebot ist native Multi-Instanz-Integration, die gut funktioniert, wenn sowohl der Service-Provider als auch der Kunde Xurrent betreiben. Weniger gut funktioniert sie, wenn der Kunde etwas anderes betreibt.
Am besten geeignet für: Service-Provider und Kunden, die sich beide auf Xurrent standardisiert haben.
Integrationsmuster: Wie der Sync strukturiert ist
Drei Architekturmuster decken die meisten bidirektionalen Sync-Deployments von Service-Providern ab.
Direkte Point-to-Point-Konnektoren
Der Service-Provider baut einen individuellen Konnektor zwischen seinem zentralen System und dem ITSM jedes Kunden. Jeder Kunde erhält seine eigene maßgeschneiderte Integration. Das ist das einfachste Muster zum Starten und das am schwersten im großen Maßstab zu wartende.
Vorteile: volle Kontrolle, passt auf jeden Sonderfall, geringe Abonnementkosten.
Nachteile: Der Wartungsaufwand wächst linear mit der Kundenzahl. Das Engineering-Team wird zum Engpass. Wissen konzentriert sich auf zwei oder drei Personen, deren Weggang zum Geschäftsrisiko wird.
Am besten geeignet für: Service-Provider mit weniger als 10 stabilen Kunden auf einem kleinen Satz von Tools.
Hub-and-Spoke mit iPaaS oder Middleware
Der IT-Service-Provider nutzt ein zentrales ITSM als Hub und verbindet sich über eine iPaaS-Plattform (Boomi, MuleSoft, Workato) oder eine Sync-Middleware mit dem Tool jedes Kunden. Die Plattform übernimmt Authentifizierung, Queueing und Konnektor-Wiederverwendung. Die kundenspezifische Konfiguration startet von einer Vorlage statt von Grund auf.
Vorteile: besser als direkte Konnektoren im großen Maßstab. Ein Teil des operativen Toolings ist enthalten. Muster können über Kunden hinweg wiederverwendet werden.
Nachteile: Der Service-Provider betreibt die Integrationen weiterhin selbst. iPaaS liefert Infrastruktur; es liefert kein Betriebsmodell. Die Wartungs-Tretmühle ist pro Integration kleiner, verschwindet aber nicht.
Am besten geeignet für: Service-Provider mit 10 bis 30 Kunden und einem Integrationsteam mit den Kapazitäten, die Plattform selbst zu betreiben.
Managed-Integration-Service
Der IT-Service-Provider bezieht Integration als Service. Der Anbieter betreibt die Integrationen im Auftrag des Service-Providers, mit kontinuierlicher Service-Verantwortung über den gesamten Lebenszyklus. Das Onboarding eines neuen Kunden wird zu einer Service-Anfrage, nicht zu einem Projekt. Die Wartung liegt in der Verantwortung des Anbieters. Die Reaktion auf organisationsübergreifende Veränderungen ist inbegriffen.
Vorteile: skaliert ohne Wachstum der Engineering-Personalstärke. Planbare Abonnementpreise. Der Betrieb wird Ende zu Ende von einem Spezialisten verantwortet.
Nachteile: weniger direkte Kontrolle über die Laufzeitkonfiguration. Abhängigkeit vom Service-Anbieter.
Am besten geeignet für: IT-Service-Provider mit mehr als 15 Kunden, wachsender Kundenzahl und einer strategischen Präferenz, das Engineering auf Kundendifferenzierung statt auf Integrationswartung zu konzentrieren.
Die Skalierungswand des IT-Service-Providers
Die meisten Service-Provider beobachten eine „Integration Wall" irgendwo zwischen Kunde zwanzig und Kunde dreißig. Bis zu diesem Punkt funktioniert das In-House-Modell. Zwei oder drei Integrations-Engineers, eine Handvoll Konnektor-Tools, eine Confluence-Seite, die größtenteils aktuell bleibt.
Dann kreuzen sich die Kurven. Die Vielfalt der Kunden-Tools übersteigt, was ein kleines Team aktuell halten kann. Die Änderungsfrequenz auf den kundenseitigen Plattformen erzeugt mehr reaktive als proaktive Arbeit. Das Integrationsteam wird zur Wartungsfunktion. Das Commercial-Team lernt, sich für Integrationszeitpläne zu entschuldigen. Die Erfahrung, die der Kunde mit dem Service-Provider macht, wird ebenso sehr davon geprägt, was der Sync tut, wie davon, was die Engineers tun.
Ich habe die Skalierungswand von Service-Providern bei der Arbeit mit schnell wachsenden Service-Providern viele Male beobachtet. Es ist auch der Moment, in dem die Betriebsmodell-Frage kommerziell relevant wird. Das In-House-Modell fortzuführen bedeutet, Engineers schneller einzustellen, als der Kundenumsatz wächst. Die Arbeit an einen spezialisierten Service zu übergeben, der die Integrationen betreibt, verändert die Gleichung. Der Service betreibt die Plattform. Die Engineers des Service-Providers konzentrieren sich auf differenzierte Kundenarbeit. Der bidirektionale Sync wird zur Infrastruktur statt zum Projekt.
Das ist das Muster, das ONEiO über unseren IT-Service-Provider-Kundenstamm hinweg dokumentiert hat. Wie MSPs durch Managed Integrations Kosten senken und Wachstum vorantreiben behandelt die Kosten- und Wachstumsseite. Sechs Wachstumsblocker für IT-Service-Provider behandelt das operative Skalierungsproblem im Detail. Unser Framework für die schmerzlose ITSM-Integration ist das Playbook, um jeden einzelnen Kunden sauber zu onboarden.
In diesem Artikel geht es darum, was diese Onboardings zusammenhält, sobald Sie dreißig davon parallel laufen haben.
Best Practices für bidirektionalen Ticket-Sync bei IT-Service-Providern
Welches Tool oder Muster Sie auch wählen – vier Praktiken trennen die Integrationen, die im großen Maßstab Bestand haben, von denen, die still und heimlich verfallen.
Nutzen Sie eine Hub-and-Spoke-Architektur. Betreiben Sie Ihr zentrales ITSM als Hub. Verbinden Sie das Tool jedes Kunden als Spoke. Vermeiden Sie Mesh-Muster, in denen jeder Kunde direkt mit jedem anderen Kunden integriert. Das Hub-and-Spoke-Muster vereinfacht Ihre operative Sicht und macht die kundenspezifische Reaktion auf Änderungen beherrschbar.
Automatisieren Sie das Onboarding mit Vorlagen. Erstellen Sie Konfigurationsvorlagen für jedes gängige Kunden-ITSM (ServiceNow, Jira Service Management, Zendesk, Freshservice). Starten Sie jedes neue Kunden-Onboarding von der Vorlage, nicht von Grund auf. Die Onboarding-Beschleunigung von 50 bis 60 %, von der Managed Services berichten, stammt größtenteils aus der Wiederverwendung von Vorlagen, nicht daraus, dass die technische Sync-Ebene schneller wäre.
Gewährleisten Sie Datensicherheit mit granularen Kontrollen. Nutzen Sie Tools, mit denen Sie genau definieren können, welche Daten an der Grenze geteilt, maskiert oder gefiltert werden. Das Compliance-Team des Kunden wird Fragen zum organisationsübergreifenden Datenfluss stellen. Die Integrationsebene muss in der Lage sein, sie zu beantworten.
Überwachen Sie kontinuierlich auf Sync-Ausfälle. Richten Sie Alerts für Sync-Ausfälle ein. Nicht nur für das Stoppen der Queue. Auch für die subtileren Ausfälle: Status-Updates, die nicht weitergegeben wurden, Anhänge, die ihre Integrität verloren haben, SLA-Uhren, die zwischen den beiden Seiten auseinandergedriftet sind. Die Erfahrung, die der Kunde mit der Integration macht, wird von den Ausfällen bestimmt, die Sie abfangen, bevor er sie bemerkt.
Was sich ändert, wenn Integration zum Service wird
Der Unterschied zwischen dem Betrieb von bidirektionalem Service-Provider-Ticket-Sync auf einem selbst betriebenen Tool und dem Betrieb auf einem Managed-Integration-Service liegt darin, was Sie einkaufen. Drei Dinge ändern sich gleichzeitig.
Sie gewinnen Planbarkeit. Ein planbarer Kostenposten, der alles abdeckt: Implementierung, Wartung, Monitoring, Behebung. Keine überraschenden Rechnungen. 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. Transparente Integrationstechnologie. Keine Black-Box-Logik. Kein Code, den nur ein Spezialist lesen kann. Sie funktioniert mit Ihrer gesamten Umgebung – mit welchen Tools auch immer Ihre Kunden 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 Delivery-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
Zeit, das Modell zu ändern?
Bidirektionaler Ticket-Sync bei IT-Service-Providern ist einfach zu starten und operativ komplex im großen Maßstab. Die Tools funktionieren. Die Architekturmuster sind gut verstanden. Der schwierige Teil ist das Betriebsmodell rund um die Integration, und dieser schwierige Teil taucht rund um Kunde Nr. 20 mit der Verlässlichkeit eines Uhrwerks auf.
IT-Service-Provider, die über die Wand hinaus skalieren, haben keine besseren Engineers. Sie haben ein anderes Betriebsmodell. Die Integration wird als Service bezogen, statt als interne Fähigkeit betrieben. Die Wartungslast wird zum Spezialgebiet von jemand anderem. Das Engineering-Team des Service-Providers konzentriert sich auf Kundendifferenzierung statt auf Infrastruktur.
Zeit für Veränderung? Sprechen Sie mit uns darüber, wie eine Managed Integration für Ihr Service-Provider-Kundenportfolio aussehen kann.
