Service Request oder Incident? Kundenanfragen im IT-Betrieb richtig einordnen

Montagmorgen, drei neue Nachrichten:

„Die Buchhaltungssoftware ist nicht erreichbar.“

„Bitte stellen Sie die Datei aus dem Backup von gestern wieder her.“

„Bitte richten Sie unserem neuen Kollegen einen Server-Admin-Account ein.“

Alle drei Nachrichten kommen vom Kunden. Alle drei landen hoffentlich im Ticketsystem. Und alle drei können dringlich klingen. Trotzdem handelt es sich nicht um denselben Vorgang.

Die nicht erreichbare Buchhaltungssoftware ist zunächst eine gemeldete Störung. Die Wiederherstellung kann eine vereinbarte Standardleistung sein. Beim Admin-Account muss womöglich erst geklärt werden, ob der Kunde ihn überhaupt erhalten darf und ob Sie diese Leistung für ihn erbringen.

Wer alles einfach als Ticket bezeichnet, hat zwar eine gemeinsame Ablage, aber noch keinen gesteuerten Betrieb. Genau deshalb wird die Unterscheidung auch für ein Informationssicherheitsmanagementsystem nach ISO 27001 wichtig.

Die kurze Antwort

Ein Kundenwunsch ist zunächst nur die eingehende Nachricht. Danach ordnen Sie ein, was der Kunde tatsächlich von Ihnen möchte:

• Ein Service Request fordert eine vertraglich vereinbarte, normalerweise wiederholbare Leistung an.
• Ein Incident meldet eine ungeplante Unterbrechung oder Verschlechterung eines IT-Services.
• Eine noch ungeklärte Anfrage betrifft eine Leistung, die nicht eindeutig vereinbart oder nicht ausreichend beschrieben ist.
• Ein Problem wird zusätzlich bearbeitet, wenn für einen Incident weder eine bekannte Lösung noch ein Workaround vorhanden ist und deshalb Ursache und Lösung ermittelt werden müssen.

Die Begriffe stammen aus dem etablierten IT-Service-Management. Service Request Management ist der Umgang mit vordefinierten, vom Nutzer ausgelösten Anfragen. Incident Management und Problem Management sind eigene Practices. Sie müssen jetzt kein vollständiges ITIL-Projekt starten. Die Trennung ist schlicht die seit Jahrzehnten etablierte Fachsprache für Vorgänge, die Sie ohnehin jeden Tag bearbeiten.

Der Kundenwunsch ist noch keine Prozesskategorie

Der Kunde muss nicht wissen, welche Kategorie zu seiner Nachricht passt. Er darf schreiben: „Unser Outlook ist kaputt“, „Wir brauchen die Datei von Dienstag“ oder „Bitte machen Sie Frau Yildiz zum Admin“. Die fachliche Einordnung ist Aufgabe des Dienstleisters.

Das ist ein wichtiger Unterschied. Wenn Kunden beim Absenden die richtige ITIL-Kategorie auswählen müssen, werden sie zwangsläufig raten. Dann heißt ein Formularfeld vielleicht Incident, der Inhalt lautet aber: „Bitte installieren Sie die neue Version der Anwendung.“ Das Ticketsystem besitzt anschließend sehr ordentliche Auswahlfelder und trotzdem schlechte Daten.

Erfassen Sie die Nachricht deshalb zunächst zuverlässig. Ordnen Sie sie danach anhand weniger klarer Fragen ein – hier kann KI sehr gut helfen:

1. Lässt sich aus der Meldung des Kunden herauslesen, dass ein vereinbarter IT-Service nicht wie vorgesehen funktioniert?
2. Fordert er eine vereinbarte Standardleistung an?
3. Betrifft der Vorgang möglicherweise die Informationssicherheit und braucht einen zusätzlichen Eskalationsweg?

Der Eingangskanal ändert daran nichts. Eine E-Mail kann einen Incident melden. Ein Anruf kann einen Service Request auslösen. Ein Chat kann einen gefährlichen Admin-Wunsch enthalten. Wichtig ist, dass alle relevanten Vorgänge anschließend in einer gemeinsamen Arbeitsliste landen.

Service Request: Der Kunde bestellt etwas Vereinbartes

Ein Service Request ist kein technischer Defekt. Der Kunde möchte eine Leistung, die Sie grundsätzlich vorgesehen und für ihn vereinbart haben.

Typische Beispiele sind:

• einen Benutzer anlegen oder sperren;
• eine freigegebene Berechtigung ändern;
• eine Datei aus einer vorhandenen Sicherung wiederherstellen;
• einen Standardbericht bereitstellen;
• ein vorgesehenes Endgerät einrichten;
• eine dokumentierte Konfigurationsänderung beauftragen.

Das Wort Standardleistung bedeutet nicht, dass jeder Mitarbeiter sie ohne Prüfung ausführen darf. Gerade Requests zu Berechtigungen, produktiven Daten oder Konfigurationen brauchen klare Voraussetzungen und Freigaben.

Nehmen wir die Backup-Wiederherstellung. Sie ist ein Service Request, wenn Ihr IT-Servicekatalog die Wiederherstellung als Leistung beschreibt, der konkrete Kunde sie beauftragt hat und die Anfrage den vereinbarten Weg nimmt. Dann prüfen Sie beispielsweise System, Sicherungszeitpunkt, berechtigten Anforderer, Zielort und Freigabe zum Überschreiben vorhandener Daten.

Das eigentliche Backup-Management sorgt dafür, dass eine brauchbare Sicherung existiert. Der Service Request steuert, wie der Kunde die Wiederherstellung bestellt und wie Sie sie ausführen.

Fehlt diese Leistung im Vertrag oder im Betriebsführungshandbuch, wird aus dem Wunsch nicht durch bloße Dringlichkeit ein Service Request. Dann muss jemand entscheiden: Lehnen wir ab, vereinbaren wir einen Sonderauftrag oder erweitern wir unser Angebot?

Incident: Ein vereinbarter Service funktioniert nicht

Ein Incident beginnt mit der Behauptung, dass ein IT-Service ungeplant unterbrochen oder schlechter geworden ist. Der Kunde muss die technische Ursache nicht kennen und auch nicht beweisen, dass tatsächlich der Server schuld ist.

„Die Buchhaltungssoftware ist nicht erreichbar“ ist deshalb zunächst ein Incident. Vielleicht ist die Anwendung ausgefallen. Vielleicht funktioniert die Netzwerkverbindung nicht. Vielleicht ist nur das Kennwort des Benutzers abgelaufen. Die Ursache ist für die erste Einordnung noch nicht entscheidend. Es gibt eine gemeldete Abweichung vom erwarteten Servicezustand. Selbst die Behauptung einer Störung ist erst einmal ein Incident.

Das Ziel der Incident-Bearbeitung ist, den vereinbarten Service möglichst zügig wieder nutzbar zu machen. Dafür darf ein dokumentierter Workaround völlig ausreichend sein. Wenn der Druckdienst nach einem kontrollierten Neustart wieder funktioniert, kann der Incident gelöst werden; die tiefere Ursache kann separat untersucht werden.

Die Priorität ergibt sich dabei nicht allein daraus, wie viele Ausrufezeichen der Kunde verwendet. Auswirkungen, Dringlichkeit, betroffener Service, vereinbarte Servicezeiten und Sicherheitsrelevanz sind deutlich bessere Kriterien.

Ein Restore kann Request, Incident und Problem berühren

Gerade die Backup-Wiederherstellung zeigt, warum die Kategorien keine Produktnamen sind.

Der Kunde hat versehentlich eine Datei gelöscht und bestellt die vereinbarte Wiederherstellung. Das ist ein Service Request. Und absolut kein Incident.

Beim Restore stellt Ihr Mitarbeiter fest, dass die Sicherung nicht lesbar ist. Nun funktioniert ein vereinbarter Bestandteil Ihres Backup-Services nicht wie vorgesehen. Das ist zusätzlich ein Incident.

Es gibt weder eine bekannte Lösung noch einen Workaround. Warum sind mehrere Sicherungen beschädigt? Welche Komponente verursacht den Fehler? Wie lässt sich die Wiederherstellbarkeit dauerhaft sicherstellen? Dafür wird zusätzlich ein Problem eröffnet.

Ein einzelner Kundenkontakt kann also mehrere verbundene Vorgänge auslösen. Sie sollten nur nicht alles in ein einziges Freitextfeld kippen und später hoffen, dass jemand den Zusammenhang noch versteht.

Wann aus einem Incident zusätzlich ein Problem wird

In einem pragmatischen Betriebsprozess funktioniert die Logik so:

1. Bei einer Störungsmeldung eröffnen Sie ein Incident-Ticket.
2. Gibt es eine dokumentierte bekannte Lösung oder einen Workaround, wenden Sie ihn im Rahmen des Incidents an.
3. Gibt es weder Lösung noch Workaround, eröffnen Sie zusätzlich ein Problem-Ticket.
4. Im Problem-Ticket ermitteln und dokumentieren Sie Ursache und Lösung.
5. Mit der gefundenen Lösung bearbeiten und schließen Sie den Incident.
6. Beim nächsten Auftreten steht die Lösung zur Verfügung. Derselbe Fehler braucht dann nicht automatisch wieder ein neues Problem-Ticket.

Damit trennen Sie zwei Ziele: Der Incident bringt den Service wieder zum Laufen. Das Problem schafft Wissen über eine bislang unbekannte Störungsursache und verhindert, dass Ihre Mitarbeiter beim nächsten Auftreten wieder bei null anfangen.

Ein Problem ist daher nicht einfach ein besonders schlimmer Incident. Auch müssen Sie nicht aus jeder einmaligen Kleinigkeit ein Problem-Ticket machen. Entscheidend ist in diesem vereinfachten Prozess, ob eine brauchbare Lösung oder ein Workaround bereits bekannt und dokumentiert ist.

Wir werden Problem Management, bekannte Lösungen und die nutzbare Wissensbasis in einem eigenen Artikel vertiefen. Hier reicht zunächst die saubere Übergabe zwischen den Vorgängen.

Der Admin-Wunsch zeigt die Grenze des Service Requests

Der Kunde schreibt: „Legen Sie unserem neuen Kollegen bitte einen Server-Admin-Account an.“

Technisch dauert das möglicherweise fünf Minuten. Prozessual geht es sofort ans Eingemachte:

• Bieten Sie kundeneigene administrative Konten überhaupt an?
• Ist das für den betroffenen Server vereinbart?
• Darf wirklich der Praktikant diese Berechtigung anfordern?
• Wer genehmigt das?
• Welche Rechte werden genau vergeben?
• Ist eine starke Authentisierung vorgesehen?
• Wie werden Nutzung und spätere Entziehung nachvollzogen?
• Wer trägt die Verantwortung für Änderungen durch den Kundenadministrator?

Ist die Leistung definiert und beauftragt, kann daraus ein Service Request werden. Ist sie nicht vorgesehen, bleibt es zunächst eine ungeklärte Anfrage. Der Satz „Der Kunde bezahlt doch nach Aufwand“ ersetzt weder die Sicherheitsentscheidung noch die Freigabe. Sie fahren ja auch nicht mit dem Auto vor die Wand, nur weil Ihnen jemand 50 Euro dafür verspricht.

Unser Beitrag zu Adminrechten nach ISO 27001 erklärt die technische und organisatorische Seite privilegierter Zugänge ausführlicher. Für den Service Desk genügt an dieser Stelle die Erkenntnis: Technisch machbar ist keine Prozesskategorie.

Ein (ITIL-)Incident ist nicht automatisch ein Sicherheitsvorfall

Im Deutschen ist das Wort Incident tückisch. Im IT-Service-Management bezeichnet es eine Störung oder Qualitätsminderung eines IT-Services. In der Informationssicherheit wird Incident häufig für einen bestätigten oder vermuteten Sicherheitsvorfall verwendet.

Das kann sich überschneiden, muss es aber nicht:

• Ein abgestürzter Druckdienst ist ein operativer Incident, normalerweise aber kein Informationssicherheitsvorfall.
• Ein übernommenes Administratorkonto kann beides sein.
• Eine nicht erreichbare Anwendung kann auf einen technischen Defekt oder auf einen Angriff zurückgehen.

Ihr Service Desk braucht deshalb erkennbare Kriterien für die Eskalation. Verdächtige Zugriffe, unerklärliche Konfigurationsänderungen, Schadsoftware, Datenabfluss oder ungewöhnliche Ausfälle dürfen nicht im normalen Störungsticket versanden. Der geregelte Übergang zum Management von Informationssicherheitsvorfällen gehört zum Betriebsprozess.

Die Unterscheidung ist auch sprachlich hilfreich: Nennen Sie das eine beispielsweise Betriebsstörung und das andere Informationssicherheitsvorfall. Dann muss bei einem Gespräch niemand erst erraten, welche Sorte Incident gerade gemeint ist.

Warum diese Trennung für ISO 27001 wichtig ist

ISO 27001 schreibt weder ITIL-Begriffe noch ein bestimmtes Ticketsystem vor. Abschnitt 8.1 verlangt aber, dass die für das ISMS notwendigen Prozesse geplant, verwirklicht und gesteuert werden. Wie das praktisch gemeint ist, erläutert unser Artikel über die Planung und Steuerung von ISO 27001-Prozessen.

Für einen IT-Dienstleister ist der Kundenbetrieb sicherheitsrelevant. Ihre Mitarbeiter greifen auf Kundensysteme zu, verändern Berechtigungen und Konfigurationen, bearbeiten Störungen und stellen Daten wieder her. Die Klassifikation hilft dabei, für jeden Vorgang den richtigen Ablauf auszulösen:

So wird nachvollziehbar, warum eine Tätigkeit ausgeführt wurde, wer sie veranlasst und genehmigt hat, welches Kundenobjekt betroffen war und welches Ergebnis erreicht wurde. Das ist nicht nur für ein Audit nützlich. Es verhindert auch, dass der nächste Mitarbeiter denselben Sachverhalt komplett neu rekonstruieren muss.

Welche Form solche Aufzeichnungen annehmen können, zeigt unser Artikel über praxistaugliche ISO 27001-Dokumentation. Ein ordentlich geführtes Ticket ist häufig ein besserer Nachweis als eine ausführliche Prozessgrafik, die mit dem tatsächlichen Betrieb nur lose bekannt ist.

Was ein brauchbares Ticket mindestens erkennen lassen sollte

Sie brauchen keine 47 Pflichtfelder. Einige Informationen sollten aber zuverlässig auffindbar sein:

• Kunde, betroffener Service und betroffenes System;
• ursprüngliche Nachricht und Eingangskanal;
• Einordnung als Request, Incident, Problem oder ungeklärte Anfrage;
• Anforderer und gegebenenfalls Genehmiger;
• Auswirkung, Dringlichkeit und daraus abgeleitete Priorität;
• ausgeführte Tätigkeiten und beteiligte Mitarbeiter;
• verwendete bekannte Lösung oder Verknüpfung zum Problem;
• Ergebnis, Kundenkommunikation und Abschlusszeitpunkt;
• Kennzeichnung und Eskalation bei möglichem Sicherheitsbezug.

Nicht jedes Feld ist für jeden Vorgang erforderlich. Ein standardisierter Passwort-Reset braucht keine Ursachenanalyse. Ein Ausfall der zentralen Kundensicherung sollte dagegen nicht mit „Backup ging nicht, jetzt wieder okay“ geschlossen werden.

Typische Fehler bei der Einführung

Alles wird zum Incident

Wenn jeder Wunsch eine Störung ist, lässt sich aus Incident-Zahlen wenig lernen. Die Warteschlange vermischt Ausfälle mit Bestellungen und Berechtigungswünschen. Priorisierung und Kennzahlen werden Kokolores.

Alles wird zum Service Request

Das Gegenstück ist ebenso unbrauchbar. Dann verschwindet eine nicht funktionierende Sicherung zwischen Benutzeranlagen und Berichtsanfragen. Wiederkehrende Störungen werden nicht als solche erkannt.

Das Ticket wird nach dem schnellsten Lösungsweg kategorisiert

Ein Incident bleibt ein Incident, auch wenn die Lösung nur aus dem Entsperren eines Kontos besteht. Entscheidend ist, was gemeldet wurde und welcher Servicezustand wiederhergestellt werden musste – nicht die Anzahl der Mausklicks.

Das Problem ersetzt den Incident

Der Kunde braucht die Wiederherstellung seines Services. Die Ursachenanalyse ist damit verbunden, aber nicht identisch. Halten Sie beide Vorgänge verknüpft, damit Kundenkommunikation und technische Erkenntnis nicht auseinanderfallen.

Die Kategorie ist wichtiger als die Bearbeitung

Kategorien dürfen korrigiert werden. Wenn eine Anfrage zunächst wie ein Request aussieht und sich als Incident entpuppt, ändern Sie die Einordnung oder verknüpfen einen zusätzlichen Vorgang. Ein perfektes Etikett nach zwei Stunden Diskussion hilft dem wartenden Kunden erstaunlich wenig.

So führen Sie die Unterscheidung pragmatisch ein

Beginnen Sie mit echten Kundenanfragen statt mit einem Prozesshandbuch.

Nehmen Sie 50 abgeschlossene Tickets und sortieren Sie sie in vier Gruppen: Service Request, Incident, Problem und ungeklärte Anfrage. Besprechen Sie die Grenzfälle mit Service Desk und Technik. Daraus entstehen verständliche Kriterien, weil Ihre Mitarbeiter ihre eigene Arbeit wiedererkennen.

Danach definieren Sie zunächst wenige Unterkategorien für häufige Services. Verknüpfen Sie Requests mit dem Servicekatalog und Incidents mit dem betroffenen Service. Legen Sie fest, wann eine Freigabe und wann eine Sicherheitseinstufung erforderlich ist.

Prüfen Sie nach einigen Wochen:

• Wie viele ungeklärte Anfragen entstehen?
• Welche Incidents wiederholen sich?
• Wo fehlen bekannte Lösungen?
• Welche Requests werden häufig falsch zugeordnet?
• Welche Vorgänge erreichen das Ticketsystem noch immer nicht?

Der Einstiegsartikel dieser Serie zeigt das größere Bild eines steuerbaren Kundenbetriebs. Die Einordnung von Kundenanfragen ist ein weiterer Baustein: Sie verbindet den vereinbarten Service mit dem richtigen Bearbeitungsweg.

Interesse geweckt?

Sie möchten Ihren IT-Betrieb so strukturieren, dass Kundenanfragen zuverlässig bearbeitet werden und die Abläufe auch für ISO 27001 tragen? Sprechen Sie mit uns