Documentation
Incident, problem and change in context: the overview
What knooing shows and does on an incident so that causes and ongoing changes do not stay hidden in three lists: the section on the same CI, changes as suspected cause, the waiting statuses for problem resolution and change and the automatic hand-over.
6 min read · Oktober 2026
Störungen, Probleme, Changes und Konfigurationselemente (CIs) hängen zusammen: Eine Störung hat oft eine Ursache, die in einem Problem untersucht wird, und eine Ursache hat manchmal einen Auslöser, nämlich eine Änderung am selben Server. Verknüpfen konnte knooing diese Dinge schon immer. Entscheidend ist, dass der Servicedesk den Zusammenhang dort sieht, wo er arbeitet, und dass eine Entscheidung an der einen Stelle die anderen nicht liegen lässt.
Beispiel in dieser Doku: Bei der Beispiel GmbH lädt am Morgen das Auftragsportal nicht. Kurz davor wurde am Datenbankserver srv-db01 ein Betriebssystem-Update eingespielt. In den Anleitungen arbeiten Julia, Sara und Tobias Beispiel in wechselnden Rollen: im Servicedesk, im Problemmanagement und als Verantwortliche von Changes.
Die drei Hilfen
| Hilfe | Was sie leistet | Anleitung | |---|---|---| | Kontext am Vorgang | Der Abschnitt Am selben CI zeigt an einer Störung oder einem Problem, welche Changes am betroffenen Objekt laufen oder kürzlich liefen, welche weiteren Störungen und Probleme offen sind und welche Known Errors es gibt. | Den Kontext Am selben CI lesen | | Change als Ursache | Passt ein Change zeitlich zur Störung, steht darüber ein Hinweis. Mit einem Klick wird er zur dokumentierten Ursache, der Change-Verantwortliche erfährt davon, und die Kennzahlen zählen die Störung dem Change zu. | Einen Change als Ursache verknüpfen, Verursachte Störungen und die Kennzahl | | Wartestatus und Weitergabe | Eine Störung kann sichtbar auf die Lösung eines Problems oder auf einen Change warten. Löst jemand das Problem, löst knooing die wartenden Störungen mit. Ist der Change umgesetzt, geht die Störung zurück an ihren Bearbeiter. | Eine Störung auf die Problemlösung warten lassen, Problem lösen, Wenn das Problem nicht gelöst wird, Auf einen Change warten, Problem nach dem Change lösen |
Die Wartestatus im Vergleich
| Status | Wann | Was passiert am Ende | SLA-Uhr | |---|---|---|---| | wartet auf Problemlösung | Die Störung ist einem offenen Problem zugeordnet und soll mit ihm gelöst werden. | Wird das Problem gelöst, ist die Störung automatisch mitgelöst. Wird es ohne Behebung geschlossen, abgebrochen oder die Störung vom Problem getrennt, geht sie zurück in Bearbeitung. | läuft weiter | | wartet auf Change | Die Lösung hängt von einer geplanten Änderung ab. | Ist der Change umgesetzt, fehlgeschlagen oder abgebrochen, geht der Vorgang zurück in Bearbeitung. Gelöst wird er nie von selbst. | Die SLA-Regel entscheidet, ob Wartet auf Change die Uhr anhält. |
Warum läuft die Uhr beim Warten auf ein Problem weiter? Das Problem wird im eigenen Haus gelöst. Diese Zeit hat die meldende Person nicht verursacht, deshalb hält sie die Frist nie an. Beim Warten auf einen Change bestimmt dagegen die SLA-Regel, ob die Zeit zählt (siehe SLA-Regeln einrichten).
Was knooing nie von selbst tut
Ein Change, der umgesetzt wurde, löst keine Störung von selbst: Ob die Änderung wirkt, entscheidet ein Mensch. Ein Known Error wird nie von selbst stillgelegt. Und ein Vorschlag für eine Ursache ist nur ein Vorschlag: Verknüpft wird erst, wenn jemand auf Als Ursache verknüpfen klickt.
Wer das sehen und tun darf
Der Abschnitt Am selben CI und die Wartestatus brauchen das Recht, im Servicedesk Vorgänge anzuzeigen beziehungsweise zu bearbeiten. Einen Vorgang sieht nur, wer ihn auch in der Vorgangsliste sähe: Der Kontext zeigt keine fremden Vorgänge. Den Rückblick des Kontexts stellen Personen mit dem Recht für die Servicedesk-Einstellungen ein.
Alle Anleitungen zu dieser Anforderung stehen unter Suche nach A1-07.