Das Problem: Service-Typen werden zu Schubladen
In vielen ITSM-Einführungen wird früh über Service-Typen diskutiert. Business Service, Technical Service, Professional Service. Die Begriffe sind bekannt, aber sie führen in der Praxis oft zu genau dem Gegenteil von Klarheit.
Services werden doppelt angelegt, nur weil sie „für Business“ oder „für IT“ gedacht sind. Verantwortlichkeiten verschwimmen. Der Servicekatalog wächst, ohne verständlicher zu werden. Und irgendwann diskutiert man mehr über die richtige Einordnung als über den tatsächlichen Nutzen eines Services.
Das eigentliche ITIL-Ziel gerät dabei aus dem Blick: Services sollen Wert liefern, Verantwortung klar kapseln und für definierte Konsumenten verfügbar sein. Die Trennung in Service-Typen wird fälschlicherweise als strukturelle Vorgabe verstanden, nicht als Wirkung im Kontext.
Die Idee: Ein Service, mehrere Kontexte
Schaut man nüchtern auf ITIL, wird schnell klar: Ein Service ist nicht per Definition ein Business- oder Technical Service. Er wird es durch seinen Konsumentenkreis.
Ein Business Service ist sichtbar für Fachbereiche oder Kunden. Ein Technical Service unterstützt andere Services und richtet sich an interne IT-Einheiten. Der Unterschied liegt nicht im Service selbst, sondern darin, wer ihn konsumiert und unter welchen Bedingungen.
Für ITSM-Tools bedeutet das:
Nicht der Service sollte klassifiziert werden, sondern seine Nutzung. Der Kontext entscheidet, nicht die technische oder fachliche Beschreibung.
Ein sauberes Modell trennt deshalb Service und Freigabe. Der Service bleibt stabil, eindeutig beschrieben und verantwortlich geführt. Die Nutzung wird gesteuert, idealerweise flexibel, nachvollziehbar und ohne Duplikate.
Die Umsetzung in Xurrent: Der SLA als Schlüsselfaktor
Xurrent setzt genau diesen Gedanken konsequent um. Ein Service wird einmal sauber definiert, mit Zweck, Leistung, Owner, Abhängigkeiten und Supportmodell. Zu diesem Zeitpunkt ist er noch neutral. Weder Business noch Technical Service.
Die Einordnung entsteht erst über den SLA.
Der SLA regelt, welcher Konsumentenkreis den Service nutzen darf und mit welchem Service-Level. Wird ein SLA für Endanwender, Fachbereiche oder externe Kunden freigegeben, wirkt der Service als Business Service. Er ist sichtbar, bestellbar und geschäftsrelevant.
Wird derselbe Service ausschließlich über SLAs an interne IT-Teams vergeben, bleibt er ein Technical Service. Er unterstützt andere Services, ohne im Endanwenderkatalog aufzutauchen.
Ein und derselbe Service kann damit mehrere Rollen einnehmen, gesteuert über unterschiedliche SLAs. Keine Duplikate, keine widersprüchlichen Verantwortlichkeiten, keine künstlichen Trennlinien.
Auch Professional Services fügen sich nahtlos ein. Dienstleistungen wie Beratung, Onboarding oder spezielle Unterstützungsleistungen werden genauso als Services modelliert. Ob sie intern genutzt oder extern angeboten werden, entscheidet allein der SLA.
Der entscheidende Vorteil: Verantwortung bleibt gekapselt. Jeder Service hat genau einen Owner. SLAs steuern die Nutzung, nicht die Existenz des Services.
Weniger Schubladen, mehr Klarheit im Service-Modell
.png)
