Incident, Problem, Change, Service Request — der Unterschied
Vier Begriffe, die in der Praxis ständig vermischt werden. Die Unterscheidung ist kein Selbstzweck: An ihr hängen Fristen, Zuständigkeiten und die Frage, ob dieselbe Störung zwölfmal gelöst wird.
Was ist der Unterschied zwischen Incident und Problem?
Ein Incident ist eine Störung: Etwas funktioniert nicht mehr, und das Ziel ist, den Betrieb wiederherzustellen — notfalls mit einer Umgehung. Ein Problem ist die Ursache dahinter, und das Ziel ist, sie zu beseitigen.
Beispiel: „Der Drucker im zweiten Obergeschoss druckt leere Seiten" ist ein Incident. „Dieser Drucker fällt jede Woche aus, seit das Firmware-Update lief" ist ein Problem.
Wer beides in einen Topf wirft, behebt dieselbe Störung zwölfmal und wundert sich über die Auslastung. Die Trennung ist der einzige Grund, warum ein Servicedesk mit der Zeit schneller statt langsamer wird.
Was ist ein Service Request?
Ein Wunsch, keine Störung. Jemand möchte etwas bekommen oder dürfen — einen Zugang, ein Gerät, eine Software. Es ist nichts kaputt.
Der Unterschied ist praktisch: Für eine Störung gilt eine Wiederherstellungszeit, für einen Wunsch eine Bearbeitungszeit. Wer beides mit derselben Frist misst, bekommt eine Kennzahl, die nichts aussagt.
Was ist ein Change — und wann brauche ich einen?
Ein Change ist eine geplante Änderung an einem System, das in Betrieb ist. Man braucht ihn, sobald eine Änderung andere treffen kann — also fast immer, wenn sie nicht nur das eigene Gerät betrifft.
ITIL 4 kennt drei Arten. Standard-Changes sind wiederkehrend und vorab genehmigt (eine Festplatte tauschen). Normale Changes durchlaufen eine Bewertung und Genehmigung. Emergency-Changes dürfen sofort umgesetzt werden und werden nachträglich genehmigt.
Der wichtigste Bestandteil ist nicht die Genehmigung, sondern der Rückfallplan. Eine Änderung ohne Weg zurück ist keine Änderung, sondern ein Versuch.
Was ist ein Known Error?
Ein Problem, dessen Ursache bekannt ist, für das es aber noch keine dauerhafte Lösung gibt — dokumentiert mit Symptom, Ursache und Umgehung.
Der Known Error ist das, was den nächsten Anruf von dreißig Minuten auf zwei verkürzt. Er gehört in die Wissensdatenbank, nicht in den Kopf des Kollegen, der gerade Urlaub hat.
Wann wird aus einem Ticket ein Prozess?
Faustregel: Wenn Sie beim Lesen schon wissen, wer es macht und dass es in einem Rutsch erledigt ist, ist es ein Ticket. Wenn mehrere nacheinander dran sind, ist es ein Prozess.
„Bitte VPN-Zugang einrichten" ist ein Ticket. „Neuer Mitarbeiter fängt am Ersten an" ist ein Prozess: Personalakte, Zugänge, Ausstattung bestellen, Arbeitsplatz einrichten, Einweisung — verschiedene Beteiligte, teils parallel, mit Genehmigungen dazwischen.
Wann kommt zusätzlich ein Sicherheitsvorfall dazu?
Wenn es um Informationssicherheit geht und die Sache erheblich sein könnte. Der Sicherheitsvorfall ersetzt das Ticket nicht, er kommt dazu — denn dort laufen die gesetzlichen Meldefristen.
Beispiel: „Ich habe auf einen Link geklickt und danach war mein Postfach komisch" beginnt als ganz normales Ticket. Bestätigt sich der Verdacht auf einen fremden Zugriff, entsteht zusätzlich ein Vorfall — und ab der Kenntnisnahme laufen bei betroffenen Unternehmen die NIS2-Fristen.
Warum lohnt sich die Unterscheidung überhaupt?
Weil an ihr drei Dinge hängen, die sonst nicht funktionieren: Fristen (eine Störung hat eine andere Uhr als ein Wunsch), Zuständigkeit (ein Change braucht einen Genehmiger, ein Incident einen Bearbeiter) und Nachweis (eine Aufsichtsbehörde fragt nach Vorfällen, nicht nach Tickets).
Die Begriffe stammen aus ITIL, aber man muss ITIL nicht einführen, um sie zu benutzen. Es reicht, sie nicht zu vermischen.
In der Praxis: Wie Tickets, Probleme, Changes und Vorfälle zusammenhängen — und warum ein Change ohne Inventar ein Kalendereintrag ist.
ITSM in EntrutraceZur Einordnung: Die Begriffe folgen ITIL 4. ITIL ist ein Rahmenwerk, kein Gesetz — es gibt keine Pflicht, sich daran zu halten, und keine Zertifizierung für Software. Zertifiziert werden Menschen.