Wer schließt diesen Incident oder dieses Problem ab?
Beantworten Sie ein paar Fragen zum Datensatz und finden Sie den richtigen Verantwortlichen für die Freigabe – dazu praktische Schritte und die genauen Worte, mit denen ein zögernder Stakeholder zustimmt.
- Klare Verantwortung
- Praktische Schritte
- Datenschutz von Grund auf
Eine namentlich benannte Person schließt den Datensatz, nie ein Team. Bei einem Incident ist das der Engineer, der einen bestätigten Fix umgesetzt hat, oder der Major Incident Manager, wenn er teamübergreifend war. Bei einem Problem verantwortet der Problem Manager den Datensatz, und das Team, dessen Komponente die Ursache war, verantwortet die Behebung. Steckt ein Telekommunikationsanbieter in den VAE hinter dem Netzwerkausfall einer Filiale, lassen Sie sich dessen Maßnahmen schriftlich bestätigen, bevor Sie schließen.
Den Datensatz beschreiben
Ein paar kurze Fragen. Nichts wird gespeichert oder irgendwohin gesendet.
Beantworten Sie die Fragen oben – die Empfehlung aktualisiert sich laufend.
Warum Verantwortung ins Stocken gerät und wie Sie sie lösen
- Benennen Sie eine Person, keine Queue. Für einen Datensatz, der einem Team zugewiesen ist, ist niemand verantwortlich; für einen, der einer Person zugewiesen ist, schon.
- Jeder offene Datensatz braucht ein nächstes Review-Datum. „In Bearbeitung“ ist kein Status – es ist das Fehlen eines Status.
- Trennen Sie den Verantwortlichen für den Datensatz vom Verantwortlichen für die Behebung. Wer den Prozess steuert und wer die technische Arbeit erledigt, wird oft vermischt – deshalb wird nichts termingerecht geschlossen.
- Bringen Sie eine Zahl mit, nicht nur eine Bitte. Rechnen Sie die wiederkehrenden Kosten mit dem IT-Ausfallkosten-Rechner durch, bevor Sie jemanden bitten, die Verantwortung zu übernehmen – eine Zahl wird schneller freigegeben als eine Beschreibung.
Methode & Urheberschaft
Ein kurzer Entscheidungsbaum dazu, wer für den Abschluss eines Incident- oder Problem-Datensatzes verantwortlich sein sollte – abhängig davon, ob er teamübergreifend ist, einen Lieferanten betrifft, eine bestätigte Grundursache hat und wie geschäftskritisch der betroffene Service ist.
Die hier verwendeten Formeln sind etablierte, veröffentlichte Methoden. Umsetzung, Oberfläche, Texte, Auswertungslogik und Richtwerte sind eigene Arbeit von ITSM Compass. Die Ergebnisse sind Schätzungen, keine professionelle Beratung. Siehe die Nutzungsbedingungen.
© 2026 ITSM Compass. Alle Rechte vorbehalten.
Fragen
Warum braucht ein Incident oder Problem eine einzelne benannte verantwortliche Person statt eines Teams?
Ein Team kann man nicht zur Verantwortung ziehen – eine Person schon. „Das Infrastrukturteam“ verpasst nie eine Frist, weil sich niemand darin zuständig fühlt. Eine benannte verantwortliche Person, selbst für eine zweistündige Behebung, bringt den Abschluss tatsächlich voran.
Was ist der Unterschied zwischen dem Verantwortlichen für die Behebung und dem für den Datensatz?
Der Verantwortliche für den Datensatz – oft ein Incident oder Problem Manager – verantwortet den Prozess: dass Reviews stattfinden, Termine gesetzt und Freigaben eingeholt werden. Der Verantwortliche für die Behebung ist das technische Team, das die Arbeit erledigt. Werden beide vermischt, bleiben Datensätze monatelang offen.
Wie bringe ich einen Lieferanten dazu, Verantwortung zu übernehmen, ohne den Vertrag neu zu verhandeln?
Bitten Sie um etwas Engeres als „beheben Sie es“: eine schriftliche Bestätigung seiner Maßnahmen und ein Datum. Die meisten Lieferanten-SLAs verpflichten bereits zur Mitwirkung an der Ursachenanalyse – Sie bitten darum, die heutige konkrete Zusage schriftlich festzuhalten, und verhandeln den Vertrag nicht neu.
Was, wenn niemand ein Problem mit unklarer Grundursache übernehmen will?
Trennen Sie die Verantwortung für die Untersuchung von der für die Behebung. Jemand kann „herausfinden, was passiert“ übernehmen, ohne schon zu wissen, wer „beheben“ übernimmt. Wer diese erste Aufgabe vergibt, macht aus „niemand weiß es“ eine terminierte Maßnahme.
Soll daraus ein fester Prozess werden statt einer Einzelaktion?
Advisory Sessions, die RACI für den Abschluss von Incidents und Problems einrichten, mit den Reviews und dem Reporting, damit es Bestand hat.