Assigning incidents to services: the four references of every incident

Eine Störung wird selten mit dem Satz gemeldet, den der Servicedesk braucht. Eine Person schreibt „Mein Programm ist langsam“, die Überwachung meldet „Server srv-db01 antwortet nicht“, ein Fremdsystem schickt nur einen Rechnernamen. Für die Bearbeitung zählt aber eine andere Frage: Welche Leistung fällt für das Geschäft gerade aus, und wen trifft das?

knooing beantwortet diese Frage, indem jede Störung vier Bezüge trägt. Die meisten davon leitet das System selbst ab. Wo es nicht eindeutig ist, fragt es einen Menschen, statt zu raten.

Die vier Bezüge einer Störung

| Bezug | Bedeutung | Beispiel | |---|---|---| | Meldende Person | Wer meldet und für wen die Störung erfasst wird. Die Liste trennt Betroffene Person und Erfasst von. | Max Beispiel | | Geschäftsservice | Die Leistung, die die Fachabteilung kennt und nutzt. Fällt sie aus, merkt es das Geschäft. | Auftragsportal | | Service-Angebot | Die Ausprägung des Geschäftsservice für eine Zielgruppe, mit eigenen Servicezeiten und eigenem Team. | Auftragsportal Standorte | | Auslösendes Gerät (CI) | Das technische Ding, das betroffen ist: Server, Notebook, Speichersystem. Es steht als Configuration Item im Geräteverzeichnis der IT (CMDB). | srv-db01 |

Warum genau diese vier? Das ist das gängige Muster moderner ITSM-Werkzeuge (IT-Service-Management). Nicht das kaputte Gerät entscheidet über die Dringlichkeit, sondern der Geschäftsservice, der dadurch ausfällt. Aus dem Angebot ergeben sich Team und Servicezeiten, aus der Person die Zielgruppe. Das Gerät liefert den Anfang der Kette, die das System nach oben verfolgt.

Die Kette vom Gerät zum Angebot

Der Ausgangspunkt ist meist das Gerät. Daraus leitet knooing die übrigen Bezüge ab:

Gerät → läuft unter einem Service → gehört zu einem Geschäftsservice → wird angeboten als ein Angebot.

Beispiel: Der Server srv-db01 läuft unter dem Service „Datenbank Auftragswesen“. Dieser gehört zum Geschäftsservice „Auftragsportal“, den es in den Angeboten „Auftragsportal Standorte“ und „Auftragsportal Zentrale“ gibt. Fällt der Server aus, weiß der Servicedesk sofort, dass das Auftragsportal betroffen ist, welches Team zuständig ist und welche Servicezeiten gelten. Niemand muss dafür nachfragen.

1Kette bis zu den Geräten

Die Kette entsteht aus den Beziehungen, die Sie im Service-Katalog und in der Konfigurationsverwaltung pflegen (siehe Geschäftsservices und Angebote pflegen und Geräte für die Zuordnung vorbereiten). Das Angebot wählt das System passend zur betroffenen Person: Gehört sie zu einer Abteilung, für die ein Angebot gilt, ist es dieses. Sonst gilt das Angebot ohne Einschränkung auf eine Zielgruppe. Das zuständige Team kommt aus dem Angebot.

Herkunft: automatisch, Vorschlag, manuell

An den Bezügen einer Störung steht, woher der Wert kommt. Das Herkunfts-Abzeichen kennt drei Fälle:

• automatisch: Das System hat den Wert aus dem Gerät und der Kette abgeleitet, und niemand hat ihn geändert.
• Vorschlag: Ein Vorschlag, den jemand per Klick übernommen hat, etwa aus ähnlichen früheren Vorgängen. Ohne Klick setzt das System nie einen Vorschlag.
• manuell: Eine Bearbeiterin oder ein Bearbeiter hat den Wert bewusst gesetzt, am Vorgang per Stift oder in der Servicedesk-Maske. Ein dort von Hand gewähltes Gerät zählt ebenfalls als manuell. Automatiken überschreiben solche Werte nicht mehr. Das Abzeichen entsteht nur mit dem Recht, Vorgänge im Servicedesk zu bearbeiten, sonst bleibt der Wert ohne Abzeichen.

Bei älteren Vorgängen, deren Bezüge nachträglich ergänzt wurden, steht zusätzlich Rückfüllung.

Die Abzeichen sehen Sie im Kasten Angaben des Vorgangs, egal ob die Störung aus dem Portal, aus der Servicedesk-Maske, aus der Schnittstelle oder aus der Überwachung stammt.

1Abzeichen automatisch

Warum die Herkunft sichtbar machen? Wenn später jemand fragt, warum eine Störung beim falschen Team lag, muss nachvollziehbar sein, ob das System, ein Vorschlag oder ein Mensch die Zuordnung getroffen hat. Das fragen interne Revision und Prüfer regelmäßig. Zusätzlich misst die Lage die Annahmequote der Vorschläge: Werden sie selten übernommen, sind die Daten im Geräteverzeichnis vermutlich nicht gut genug gepflegt.

Wenn die Kette nicht eindeutig ist

Nicht jedes Gerät führt zu genau einem Geschäftsservice. Ein Speichersystem kann das Auftragsportal und das HR-Portal tragen. Dann rät knooing nicht:

• In der Servicedesk-Maske bleibt der Geschäftsservice auf Nicht festgelegt und Sie wählen ihn selbst (siehe Störung am Telefon erfassen).
• Bei Meldungen aus Überwachung oder Schnittstelle entsteht ein Klärfall im Eingangsprotokoll, den ein Mensch entscheidet (siehe Klärfälle zuordnen).
• Gibt es keinen erkennbaren Service, landet die Meldung beim Sammel-Service Noch nicht zugeordnet, der Triage. Sie ist nie ein Geschäftsservice und wird in Auswertungen getrennt ausgewiesen.

Warum nicht einfach die wahrscheinlichste Zuordnung nehmen? Eine falsche automatische Zuordnung schickt die Störung zum falschen Team mit der falschen Frist. Das fällt erst auf, wenn die Frist schon gerissen ist. Eine kurze Rückfrage bei der Erfassung ist billiger.

Welche Artikel wozu

Alle Artikel zu diesem Thema finden Sie über die Suche nach A1-02.

| Aufgabe | Wer | Artikel | |---|---|---| | Eine Störung für eine Person erfassen | Servicedesk | Störung am Telefon erfassen | | Bezüge am Vorgang prüfen und korrigieren | Servicedesk, Fachteams | Zuordnung am Vorgang korrigieren | | Geschäftsservices, Angebote und Service-Baum pflegen | Service-Verantwortliche | Geschäftsservices und Angebote pflegen | | Mehrdeutige Meldungen entscheiden | Servicedesk | Klärfälle zuordnen | | Nach Geschäftsservice auswerten | Servicedesk-Leitung, Service-Verantwortliche | Störungen nach Geschäftsservice auswerten | | Geräte für die Erkennung vorbereiten | IT-Mitarbeitende | Geräte für die Zuordnung vorbereiten |

Wer selbst im Mitarbeiterportal meldet, findet den Weg in Störung im Portal melden. Für Fremdsysteme und Überwachung siehe Meldewege im Überblick.