Servicefälle mit ITIL-Praktiken steuern

Was du nach dieser Lektion kannst

Das Kulturzentrum Weserblick betreibt am Wochenende mehrere Veranstaltungen. Eintrittskarten werden an den Eingängen mit mobilen Scannern geprüft. Am Freitagmorgen landen vier Meldungen beim Serviceteam:

• An Eingang Nord können keine Karten mehr geprüft werden.
• Eine neue Aushilfe benötigt rechtzeitig vor Veranstaltungsbeginn Zugriff auf die Scanner-App.
• Die Scanner verlieren seit mehreren Wochen unregelmäßig ihre Verbindung.
• Für eine neue App-Version soll die Gerätekonfiguration angepasst werden.

Alle vier Meldungen können im selben Ticketsystem stehen. Trotzdem brauchen sie nicht dieselbe Behandlung. Du sollst entscheiden, welche Art von Arbeit vorliegt, welches Ziel zuerst zählt und welche weiteren Schritte aus dem Fall entstehen.

Nach dieser Lektion kannst du:

• Incident, Service Request, Problem und Change anhand ihrer Aufgabe unterscheiden,
• den schnellen Normalbetrieb von der späteren Ursachenarbeit trennen,
• eine Änderung mit Risiko, Freigabe, Prüfung und Rückfallweg vorbereiten,
• aus mehreren Servicefällen eine konkrete Verbesserung ableiten.

Die Lektion gehört zu Lernfeld 6 “Serviceanfragen bearbeiten”. Der Rahmenlehrplan verbindet dort das Einordnen und Bearbeiten von Serviceanfragen mit Dokumentation, fachlichen Standards und Vorschlägen zur Qualitätssteigerung. Der interne Prüfungskatalog nennt Störungs-Management, Bearbeitungsstatus sowie Support- und Serviceanfragen als mögliche Themenbreite. Das ist keine Vorhersage für einen bestimmten Prüfungstermin.

ITIL ist eine Orientierung für Servicearbeit

ITIL bündelt erprobte Praktiken für das Management digitaler Produkte und Services. Eine Praktik verbindet Tätigkeiten, Rollen, Informationen und Werkzeuge für eine bestimmte Aufgabe. Ein Unternehmen übernimmt diese Orientierung nicht automatisch eins zu eins. Es passt sie an Größe, Risiken, Verträge und Arbeitsweise an.

PeopleCert führt die hier verwendeten Themen auch in der aktuellen ITIL-Systematik: Incident Management, Problem Management und Service Request Management gehören zur Unterstützung des laufenden Services. Change und kontinuierliche Verbesserung verbinden den Betrieb mit kontrollierter Weiterentwicklung. Die genaue Benennung und Bündelung kann sich zwischen ITIL-Versionen unterscheiden. Das Grundproblem in dieser Lektion bleibt gleich: Ein Servicefall braucht ein klares Ziel und einen nachvollziehbaren Übergang zur nächsten Arbeit.

Diese Lektion ist deshalb keine Vorbereitung auf eine ITIL-Zertifizierungsprüfung. Sie verwendet keine offiziellen Prüfungsfragen und gibt keine geschützten Definitionen wieder. Du lernst eine praxistaugliche Entscheidungshilfe für Ausbildung und Betrieb.

Vier Arbeitsarten beantworten vier Fragen

Beginne nicht beim Namen des Tickets, sondern bei der Frage, die das Serviceteam beantworten muss.

• Incident: Wie stellen wir einen unterbrochenen oder verschlechterten Service zügig wieder her? Im Szenario funktioniert danach die Kartenprüfung an Eingang Nord wieder.
• Service Request: Wie erfüllen wir eine vorhersehbare, standardisierbare Anfrage? Im Szenario erhält die Aushilfe den freigegebenen Zugriff.
• Problem: Welche Ursache steckt hinter wiederkehrenden oder bedeutenden Incidents? Im Szenario sind danach die Verbindungsabbrüche technisch verstanden und Gegenmaßnahmen bekannt.
• Change: Wie verändern wir einen Service kontrolliert und mit vertretbarem Risiko? Im Szenario ist die neue Gerätekonfiguration freigegeben, geprüft und nachvollziehbar ausgerollt.

Die Begriffe beschreiben Arbeit, nicht zwingend vier getrennte Datensätze. Ein Incident kann eine Problemuntersuchung auslösen. Deren Lösung kann wiederum einen Change benötigen. Ein Service Request kann ebenfalls einen standardisierten Change enthalten, zum Beispiel wenn ein freigegebener Zugriffsprozess automatisch eine Rolle setzt.

Ein Incident stellt zuerst den Service wieder her

Am Eingang Nord zeigt die Scanner-App nur noch eine Fehlermeldung. Das Serviceteam prüft Reichweite, Gerätezustand und die Verbindung zum zentralen Prüfdienst. Ein Neustart des lokalen Zugangspunkts stellt den Betrieb vorläufig wieder her.

Damit ist das Incident-Ziel erreicht: Die Kartenprüfung funktioniert wieder. Das bedeutet noch nicht, dass die technische Ursache dauerhaft beseitigt ist. Für den Abschluss des Incident braucht das Team mindestens:

• den betroffenen Service und die Auswirkung,
• die gewählte Wiederherstellungsmaßnahme,
• das Ergebnis einer Funktionsprüfung,
• verbleibende Einschränkungen,
• einen Verweis auf weiterführende Arbeit.

Die schnelle Maßnahme darf ein tragfähiger Workaround sein. Ein Workaround umgeht oder begrenzt die Wirkung einer Störung, ohne ihre Ursache zwingend zu beseitigen. Im Beispiel hilft der Neustart beim aktuellen Ausfall. Ob er die wiederkehrenden Abbrüche dauerhaft verhindert, ist noch offen.

Ein Service Request folgt einem vereinbarten Weg

Der Zugriff für die neue Aushilfe ist kein Ausfall. Die Organisation hat einen wiederkehrenden Bedarf: Eine berechtigte Person soll zu einem geplanten Zeitpunkt eine freigegebene Rolle erhalten. Dafür eignet sich ein standardisierter Ablauf.

Ein guter Request-Ablauf klärt:

1. Ist die angefragte Leistung im Serviceangebot vorgesehen?
2. Sind Identität, Berechtigung und gewünschter Termin vollständig?
3. Wer darf die Anfrage genehmigen?
4. Welche Standardschritte setzen den Zugriff um?
5. Wie werden Ergebnis und Übergabe bestätigt?

Auch eine einfache Anfrage kann ein Risiko enthalten. Zugriff wird deshalb nicht allein vergeben, weil ein Ticket freundlich formuliert ist. Im Szenario genehmigt die Veranstaltungsleitung die Rolle. Der Service Desk setzt sie über einen vorbereiteten Ablauf und prüft anschließend die Anmeldung.

Ein Problem untersucht das Muster hinter Incidents

Der Neustart hat den Freitag gerettet. Die sechs ähnlichen Vorfälle zeigen aber, dass eine einzelne Wiederherstellung nicht reicht. Das Team eröffnet eine Problemuntersuchung und bündelt die vorhandenen Daten:

• betroffene Geräte und Standorte,
• Zeitpunkt und Dauer der Abbrüche,
• App-, Betriebssystem- und Firmwarestände,
• Netzwerkmessungen vor und während des Ausfalls,
• wirksame und unwirksame Workarounds,
• Änderungen kurz vor dem ersten Auftreten.

Das Ziel ist nicht, einen Schuldigen zu finden. Das Team will die Ursache oder zumindest die Bedingungen des Fehlers so weit verstehen, dass es Wiederholungen verringern kann. Bis dahin kann ein dokumentierter Workaround die Incident-Bearbeitung beschleunigen.

Ein Change kontrolliert die Veränderung

Die Analyse zeigt einen Zusammenhang zwischen einer Energiesparoption und den Verbindungsabbrüchen. Das Team möchte die Gerätekonfiguration ändern. Eine plausible Ursache ist noch keine Erlaubnis für einen unkontrollierten Rollout.

Der Change beschreibt die geplante Veränderung und schafft eine bewusste Entscheidung über Nutzen und Risiko. Für das Weserblick-Szenario hält das Team fest:

• Ziel: Energiesparoption auf verwalteten Scannern deaktivieren.
• Umfang: zuerst zwei Testgeräte, danach 24 Produktivgeräte.
• Risiko: höherer Akkuverbrauch oder neue Verbindungsprobleme.
• Prüfung: Testscan, Verbindungsstabilität und Akkuverbrauch beobachten.
• Zeitfenster: nach Veranstaltungsende.
• Freigabe: Serviceverantwortliche Person und Gerätebetrieb.
• Rückfallweg: vorherige Konfiguration aus der Verwaltung erneut zuweisen.
• Kommunikation: Einlassleitung vor Beginn und nach Abschluss informieren.

Nicht jeder Change braucht denselben Aufwand. Eine bekannte, risikoarme Standardänderung kann einen vorab genehmigten Ablauf haben. Eine neuartige oder riskante Veränderung braucht eine eigene Bewertung und Freigabe. Maßgeblich sind Wirkung, Unsicherheit und betriebliche Vorgaben, nicht die Länge des Formulars.

Die Arbeitsarten bilden einen nachvollziehbaren Fluss

Der Ablauf zeigt, wie aus einem aktuellen Ausfall eine nachhaltige Verbesserung werden kann. Nicht jeder Incident durchläuft alle Schritte. Die Verbindungen werden dort genutzt, wo der konkrete Fall sie trägt.

Kontinuierliche Verbesserung braucht eine prüfbare Veränderung

Nach dem Rollout sind zwei Fragen offen: Hat die Änderung die Abbrüche verringert? Und hat sie neue Nachteile verursacht? “Die Scanner laufen jetzt besser” ist dafür zu ungenau.

Das Team vereinbart für die nächsten vier Veranstaltungswochen:

• die Zahl der Verbindungsabbrüche pro Veranstaltung zu erfassen,
• Akkuwarnungen vor Veranstaltungsende gesondert zu beobachten,
• betroffene Geräte und Softwarestände einheitlich zu dokumentieren,
• die Werte anschließend mit dem Zeitraum vor der Änderung zu vergleichen.

Kontinuierliche Verbesserung bedeutet hier nicht, ständig etwas zu verändern. Das Team wählt eine begründete Maßnahme, legt ein erwartetes Ergebnis fest, prüft die Wirkung und entscheidet mit den gewonnenen Daten weiter. Wenn die Abbrüche sinken, aber Scanner nun zu früh ausgehen, ist der Service noch nicht insgesamt verbessert.

Transfer: Plane die Arbeit für einen neuen Servicefall

Was du mitnehmen kannst

• Ein Incident richtet den Blick zuerst auf die Wiederherstellung eines unterbrochenen oder verschlechterten Services.
• Ein Service Request erfüllt eine vorgesehene, möglichst standardisierte Anfrage.
• Ein Problem untersucht die Ursache oder die Bedingungen wiederkehrender und bedeutender Incidents.
• Ein Change bringt eine Veränderung mit bewertbarem Risiko, Freigabe, Prüfung und Rückfallweg in den Service.
• Kontinuierliche Verbesserung prüft, ob eine Maßnahme den Service messbar und ohne unvertretbare Nebenwirkung verbessert.

Das Ticketsystem unterstützt diese Arbeit als gemeinsame Dokumentation. Die Qualität entsteht aber nicht durch das Werkzeug allein. Sie entsteht, wenn Ziel, Zuständigkeit, Übergang und Ergebnis des Servicefalls nachvollziehbar sind.

Quellenbasis und Grenzen

Der KMK-Rahmenlehrplan trägt die berufliche Handlung: Serviceanfragen einordnen, bearbeiten, dokumentieren und zur Qualitätssteigerung reflektieren. Die Fachinformatikerausbildungsverordnung stützt die Planung von Arbeitsaufgaben, die Kundenkommunikation, die Dokumentation sowie das Begleiten von Veränderungsprozessen. Der interne Prüfungskatalog grenzt die mögliche Themenbreite für den ersten Teil der Abschlussprüfung ein.

PeopleCert dient als fachliche Primärquelle für die Einordnung der ITIL-Praktiken und den Versionsstand. Die konkreten Entscheidungsregeln, Tabellen, Aufgaben und Szenarien dieser Lektion sind eigenständig formuliert. Sie ersetzen weder die offiziellen ITIL-Publikationen noch eine Zertifizierungsschulung. Betriebliche Prozesse, Rollen und Freigabegrenzen können abweichen.

Die Belegmatrix verbindet jedes Lernziel mit seiner Grundlage und der passenden Lernaktivität:

• Servicefälle unterscheiden: LF6, A1, A2 und T1; getragen vom KMK-Rahmenlehrplan, dem Prüfungskatalog AP1 und den PeopleCert-Übersichten; geübt in der Zuordnungsaufgabe mit vier Meldungen.
• Wiederherstellung und Ursachenarbeit trennen: LF6, A1, A7 und T1; getragen vom KMK-Rahmenlehrplan, dem Prüfungskatalog AP1 und den PeopleCert-Übersichten; geübt im Incident-Quiz und in der Sortieraufgabe.
• Einen Change kontrolliert vorbereiten: LF6 und A7; getragen von der FIAusbV, der PeopleCert ITIL FAQ und der ITIL-4-Übersicht; geübt in der Mehrfachauswahl und am Change-Plan.
• Eine Verbesserung überprüfbar ableiten: LF6, A1 und A7; getragen vom KMK-Rahmenlehrplan, der FIAusbV und der PeopleCert ITIL FAQ; geübt im Wirkungs-Quiz und in der Transferaufgabe.