ITSM in der Verwaltung: Servicekatalog, CMDB und Change nicht getrennt einführen
ITSM wird erst wirksam, wenn Incident, Request, Problem und Change an verständliche Services, belastbare Ownership und gepflegte Konfigurationsdaten gekoppelt sind.
Mit Services statt mit Ticketmasken beginnen
Ein Servicekatalog sollte Leistungen, Nutzergruppen, Owner, Supportzeiten, Abhängigkeiten und erwartete Bearbeitungswege beschreiben. Erst daraus entstehen sinnvolle Request-Formulare, Prioritäten und Eskalationen.
Incident und Request brauchen unterschiedliche Steuerung
Störungen zielen auf Wiederherstellung, Service Requests auf standardisierte Leistungserbringung. Werden beide nur als generische Tickets behandelt, werden SLAs, Automation und Reporting schnell unbrauchbar.
CMDB nur mit klarer Datenverantwortung
Discovery allein erzeugt keine belastbare CMDB. Datenquellen, technische und fachliche Owner, Aktualisierungsregeln und Qualitätsmetriken müssen definiert sein; sonst wird die CMDB zu einem zweiten unzuverlässigen Inventar.
Change braucht Risiko, Test und Rückfall
Änderungen sollten nach Auswirkung und Risiko klassifiziert werden. Standard Changes, normale Changes und Notfalländerungen benötigen unterschiedliche Freigaben, aber immer einen nachvollziehbaren Test-, Abnahme- und Rollbackpfad.
Integrationen bestimmen den Betriebswert
Identity, Monitoring, E-Mail und Endpoint-Management sollten im Pilot angebunden werden. Entscheidend sind Fehlerpfade, Secrets, Dublettenvermeidung und die Frage, welches System für Asset- und Statusdaten führend ist.