Ein Managed Service beginnt nicht mit einem Ticketportal. Er beginnt mit einer klaren Antwort auf die Frage: Welche Verantwortung soll das interne Team behalten – und welche Arbeit soll der Dienstleister zuverlässig übernehmen?
Gerade in Zscaler-Umgebungen ist diese Trennung entscheidend. ZIA, ZPA, Client Connector, Zertifikate, Identitäten, App-Segmente, Ausnahmen und Protokolle greifen ineinander. Wenn Rollen und Übergaben nicht sauber definiert sind, entsteht kein entlastender Service. Es entsteht eine weitere Abstimmungsschicht.
Ein belastbares Betriebsmodell verbindet Fachwissen, Entscheidungsrechte, wiederholbare Abläufe und messbare Ergebnisse. Es macht den Alltag einfacher, ohne Verantwortung unsichtbar auszulagern.
Der häufigste Fehler: Leistungen statt Ergebnisse einkaufen
Viele Leistungsbeschreibungen listen Tätigkeiten auf: Monitoring, Incident Support, Policy Management, Reporting. Das klingt vollständig, lässt aber zentrale Fragen offen.
Was gilt als Incident? Darf der Dienstleister eine Regel sofort ändern? Wer bewertet eine fachliche Ausnahme? Welche Informationen muss ein Ticket enthalten? Wer spricht mit dem Hersteller? Was passiert, wenn eine Änderung zwar technisch funktioniert, aber einen Geschäftsprozess unterbricht?
Ein guter Service beschreibt deshalb nicht nur, was getan wird, sondern auch:
- welches Ergebnis erwartet wird,
- welche Evidenz die Bearbeitung benötigt,
- wer entscheiden und freigeben darf,
- welche Reaktions- und Bearbeitungslogik gilt,
- wie Rückfall und Eskalation funktionieren,
- woran Qualität gemessen wird.
Baustein 1: Ein eindeutiger Scope
„Zscaler betreiben“ ist zu ungenau. Der Scope muss nach Plattform, Tenant, Nutzergruppe, Standort, Anwendung und Prozess abgegrenzt werden.
Typische Leistungsbereiche sind:
- ZIA- und ZPA-Richtlinienpflege,
- Client-Connector-Konfiguration und Rolloutunterstützung,
- App-Segment- und Connector-Betrieb,
- SSL/TLS-Inspektionsausnahmen,
- URL- und Cloud-App-Freigaben,
- Zertifikats- und Identitätsabhängigkeiten,
- Monitoring, Reporting und Herstellereskalation,
- dokumentierte Changes und regelmäßige Optimierung.
Nicht jeder Kunde benötigt alles. Entscheidend ist, dass enthaltene, optionale und ausgeschlossene Leistungen sichtbar sind.
Baustein 2: Eine RACI, die im Ticketfall funktioniert
Eine RACI ist nur nützlich, wenn sie bis auf typische Vorgänge heruntergebrochen wird. Für eine URL-Freigabe kann das Fachteam verantwortlich sein, Security die Risikobewertung liefern, der Servicepartner die Regel vorbereiten und ein interner Owner die Änderung freigeben.
Bei einem gestörten App-Zugriff sieht die Verteilung anders aus: Helpdesk sammelt Nutzer- und Gerätekontext, der Dienstleister analysiert ZPA- und Connector-Pfade, der Applikationsowner prüft die Anwendung, und Security entscheidet über eine Ausnahme.
Für die wichtigsten 15 bis 20 Vorgangstypen sollte feststehen:
- wer das Ticket qualifiziert,
- welche Mindestinformationen erforderlich sind,
- wer technisch analysiert,
- wer eine Änderung vorbereitet,
- wer sie freigibt,
- wer sie ausführt,
- wer die Wirkung bestätigt.
Baustein 3: Runbooks statt Spezialistenwissen im Kopf
Ein Runbook ist keine lange Produktdokumentation. Es ist ein kurzer, ausführbarer Ablauf für eine wiederkehrende Situation.
Ein gutes Runbook enthält Trigger, Eingangsdaten, Prüfreihenfolge, Entscheidungspunkte, erlaubte Aktionen, Rollback und Abschlussnachweis. Beispiele sind ein Client-Connector-Anmeldeproblem, ein fehlgeschlagener ZPA-Zugriff, eine SSL-Inspection-Ausnahme oder eine Änderung an einem App-Segment.
Runbooks reduzieren nicht die notwendige Expertise. Sie sorgen dafür, dass diese Expertise bei Routinefällen nicht jedes Mal neu erfunden werden muss.
Baustein 4: Gestufte Entscheidungsrechte
Ein Service wird langsam, wenn jede Kleinigkeit auf eine Einzelgenehmigung wartet. Er wird riskant, wenn der Dienstleister frei verändern darf. Die Lösung sind gestufte Entscheidungsrechte.
Standardchanges können vorab genehmigte Parameter, Testschritte und Rollbackregeln besitzen. Normale Changes benötigen eine konkrete Freigabe. Notfalländerungen folgen einem engen Verfahren mit nachgelagerter Prüfung. Risikoausnahmen bleiben bewusst beim zuständigen Kundenowner.
So gewinnt der Betrieb Geschwindigkeit, ohne Kontrolle aufzugeben.
Baustein 5: Herstellereskalation mit vollständiger Evidenz
Ein Supportfall beim Hersteller wird teuer, wenn Logs, Zeitstempel, Tenant-Kontext, Reproduktionsschritte und bereits geprüfte Hypothesen fehlen. Der Managed Service sollte festlegen, wann ein Fall eskaliert wird und welches Evidenzpaket vorher vorliegen muss.
Zscaler stellt Partnern und Integratoren eigene Portale, Trainings- und Supportwege zur Verfügung. Der Nutzen entsteht jedoch erst, wenn der Dienstleister die Kundenumgebung so gut kennt, dass Herstellerfälle präzise vorbereitet und nachvollziehbar zurückgeführt werden.
Baustein 6: Messung, die Verhalten verbessert
Eine reine Ticketzahl sagt wenig über den Zustand der Umgebung. Sinnvoller sind Kennzahlen, die Ursachen und Lernfortschritt zeigen:
- Anteil vollständig qualifizierter Tickets,
- wiederkehrende Störungstypen,
- Zeit bis zur belastbaren Diagnose,
- Anteil der Standardchanges,
- Alter offener Ausnahmen,
- Zahl überfälliger Reviews,
- Änderungen mit erfolgreichem Nachweis und Rollbackfähigkeit.
Das Ziel ist nicht, möglichst viele Tickets schnell zu schließen. Das Ziel ist, vermeidbare Tickets und riskante Sonderwege schrittweise zu reduzieren.
Baustein 7: Ein fester Verbesserungsrhythmus
Ein Managed Service darf nicht im Reagieren stehen bleiben. Monatlich oder quartalsweise sollten Tickets, Ausnahmen, Policy-Drift, Plattformänderungen und bevorstehende Projekte gemeinsam bewertet werden.
Aus diesem Review entstehen wenige, priorisierte Verbesserungen: ein Runbook ergänzen, eine alte Ausnahme schließen, eine Richtlinie vereinheitlichen, eine Integration testen oder eine Nutzergruppe neu segmentieren.
Damit wird aus externer Unterstützung ein Betriebsmodell, das mit der Umgebung lernt.
Entlastung entsteht durch Klarheit
Ein guter Zscaler Managed Service nimmt dem internen Team nicht die Hoheit. Er reduziert die Zahl der Situationen, in denen nur eine einzelne Person weiß, wie es weitergeht.
Klare Servicegrenzen, ausführbare Runbooks, abgestufte Freigaben und belastbare Evidenz schaffen Geschwindigkeit. Das interne Team behält Architektur, Risikoakzeptanz und Prioritäten. Der Dienstleister übernimmt vereinbarte operative Arbeit und macht sie nachvollziehbar.
Genau darin liegt der Unterschied zwischen „wir bearbeiten Tickets“ und einem Managed Service, der den Security-Betrieb tatsächlich stabiler macht.