Eine ITSM-Plattform ist kein Ticketsystem. Die meisten Unternehmen betreiben sie als eines.

Fragen Sie in den meisten IT-Organisationen, was die ITSM-Plattform macht. Die Antwort lautet: „Tickets“. Störungen gehen ein, werden zugewiesen und geschlossen. Anfragen gehen ein, werden genehmigt und dadurch erfüllt, dass jemand irgendwo anders etwas erledigt. Die Plattform dokumentiert, dass Arbeit stattgefunden hat. Sie erledigt diese Arbeit selten selbst und weiß fast nie, worum es dabei ging.

Das ist ein Ticketsystem. Es ist nützlich. Es ist auch nur ein kleiner Teil dessen, was die Plattform leisten kann.

Was „Plattform für den Betrieb“ bedeutet

Eine Plattform für den Betrieb beantwortet Fragen, die ein Ticketsystem nicht beantworten kann:

Was hängt von diesem Server ab? Ein Ticketsystem hat ein Freitextfeld namens „Betroffenes CI“. Eine Betriebsplattform hat eine CMDB mit Beziehungen, die durch Discovery erfasst und gestern mit dem Cloud-Anbieter abgeglichen wurden.
Was passiert, wenn diese Anfrage genehmigt wird? In einem Ticketsystem liest ein Mensch das Ticket und klickt sich durch drei weitere Systeme. In einer Betriebsplattform legt ein Workflow das Konto an, weist die Lizenz zu, aktualisiert die CMDB und informiert den Antragsteller, wenn alles erledigt ist.
Ist diese Änderung riskant? Ein Ticketsystem lässt den Antragsteller „niedrig / mittel / hoch“ auswählen. Eine Betriebsplattform berechnet das Risiko aus den beteiligten CIs, ihrer Geschäftskritikalität, dem Änderungsfenster und der Historie ähnlicher Änderungen.

Der Unterschied liegt nicht im Funktionsumfang. Jede dieser Fähigkeiten wird mit der Plattform ausgeliefert. Der Unterschied liegt in vier Entscheidungen, die in den ersten sechs Monaten getroffen wurden oder ausgeblieben sind.

Entscheidung 1: Die CMDB ist ein Produkt, keine Tabelle

Eine CMDB, der niemand vertraut, ist schlechter als keine: Menschen richten Prozesse daran aus und umgehen sie anschließend. Die Lösung ist kein Datenbereinigungsprojekt. Sie heißt Verantwortung: Jemand verantwortet das Datenmodell, ausgerichtet an einem dokumentierten Servicedatenmodell. Jemand verantwortet jede Datenquelle, ob Discovery, Cloud-Konnektoren oder Importe. Und es gibt ein Dashboard zur Datenqualität, das in einer Besprechung tatsächlich angesehen wird.

Wenn die CMDB Ihrer ITSM-Plattform keinen Verantwortlichen mit einem Termin im Kalender hat, haben Sie eine Tabelle.

Entscheidung 2: Konfiguration vor individuellen Anpassungen, verbindlich

Jedes ITSM-System, das sich nicht mehr aktualisieren lässt, ist Skript für Skript dort gelandet, und jedes einzelne schien vernünftig. Die Regel dagegen ist einfach und unbeliebt: zuerst Standardfunktionen, dann Konfiguration, Skripte nur mit schriftlicher Begründung und einem Plan für das nächste Upgrade. Um das durchzusetzen, braucht es einen Plattformverantwortlichen, der Nein sagen kann, einen Review-Schritt vor der Übertragung von Releases und Abdeckung der wichtigen Funktionen durch automatisierte Tests.

Entscheidung 3: Der Katalog beschreibt Services, keine Formulare

Ein Katalog mit 400 Einträgen, die eigentlich 400 Formulare sind, ist ein Aktenschrank. Ein Katalog, der von der Frage „Was müssen Menschen erledigen?“ ausgeht, hat weniger Einträge. Jeder davon hat einen Erfüllungsworkflow, an dessen Ende ein geliefertes Ergebnis steht. Der Test für einen Katalogeintrag lautet: Kann er erfüllt werden, ohne dass ein Mensch das Ticket liest? Wenn nicht, automatisieren Sie ihn oder akzeptieren Sie ihn als manuellen Service und messen Sie ihn entsprechend.

Entscheidung 4: Prozesse werden mit den Menschen gestaltet, die sie ausführen

Störungs-, Änderungs- und Anfrageprozesse, die aus einem Framework kopiert und von einem Partner in einem Workshop ohne Beteiligung des Betriebs konfiguriert wurden, werden innerhalb eines Quartals umgangen. Die Prozesse, die Bestand haben, wurden mit der Service-Desk-Leitung, dem Change Manager und den beiden Entwicklern gestaltet, die die meisten Änderungen durchführen. Anschließend wurde die Plattform so konfiguriert, dass der vereinbarte Weg der einfachste ist.

Wo Sie anfangen sollten

Nicht mit einer Neuimplementierung. Beginnen Sie mit einer ehrlichen Bestandsaufnahme: CMDB-Qualität, Altlasten durch individuelle Anpassungen, Erfüllungsquote im Katalog und die Frage, welche Prozesse tatsächlich befolgt werden. Wählen Sie den Bereich, in dem die Lücke zwischen „dokumentiert“ und „ausgeführt“ am meisten kostet, meist die Erfüllung von Anfragen oder das Änderungsrisiko. Verbessern Sie ihn durchgängig, einschließlich der benötigten CMDB-Daten. Dann folgt der nächste.

Ihre ITSM-Plattform ist bereits da. Die Aufgabe besteht darin, sie die Realität abbilden zu lassen und ihr anschließend zu ermöglichen, auf dieser Grundlage zu handeln.