Anleitung
Folgeprozesse und Zeitachse: Notfalländerung, Problem, vollständige Zeitachse und Protokoll
So legen Sie aus einem laufenden Major Incident eine Notfalländerung und ein Problem an, prüfen die vollständige Zeitachse, filtern und exportieren sie und laden das Kommunikationsprotokoll als CSV oder JSON herunter.
8 min Lesezeit · Oktober 2026
Ein Major Incident hört nicht mit der Wiederherstellung auf. Oft braucht es eine sofortige Änderung an den Systemen, und fast immer bleibt eine Ursache, die erst gefunden werden muss. Dieser Artikel zeigt, wie Sie beides aus dem Major Incident heraus anlegen, wie Sie später lückenlos nachvollziehen, was wann geschah, und wie Sie das Kommunikationsprotokoll für eine Prüfung herunterladen. Den Gesamtablauf zeigt der Überblick.
Das brauchen Sie
Einen ausgerufenen Major Incident (siehe Major Incident ausrufen) und das Recht, im Servicedesk Vorgänge zu bearbeiten. Zeitachse und Kommunikationsprotokoll lesen und herunterladen genügt das Leserecht. Die E-Mail-Adressen in der JSON-Datei des Protokolls sehen Sie nur mit dem Recht auf personenbezogene Daten im Klartext.
Beispiel im Artikel: Um 12:09 Uhr wird die Datenbank des Auftragsportals auf einen Ersatzserver umgeschaltet. Das ist eine Notfalländerung. Das Problem „Speicher der Datenbank Auftragswesen läuft voll“ soll die Ursache klären.
Schritt 1: Eine Notfalländerung anlegen
Öffnen Sie den Major Incident, wechseln Sie in den Reiter Vorfall-Betrieb und scrollen Sie zum Block Wiederherstellung und Folgeprozesse. Klicken Sie bei Änderungen auf Notfalländerung anlegen. Tragen Sie bei Titel (optional) eine Bezeichnung ein. Das Feld Begründung für das ECAB (optional) können Sie leer lassen: Dann wird die Begründung aus dem Major Incident übernommen. Klicken Sie auf Anlegen.

- 1Titel eintragen
- 2Begründung, leer lassen übernimmt den Major Incident
- 3Anlegen
Es erscheint Notfalländerung … wurde angelegt. Die Änderung steht danach unter Änderungen mit Nummer und Titel, dem Abzeichen Notfalländerung, dem Freigabestand (zum Beispiel ECAB nicht beantragt) und dem Status. Eine bereits bestehende Änderung ordnen Sie mit Bestehende Änderung verknüpfen zu.
Warum? Auch in der Krise darf niemand an der Freigabe vorbei Systeme ändern. Die Notfalländerung durchläuft ein verkürztes, aber dokumentiertes Verfahren, und die Verknüpfung zeigt später, welche Änderung zu welchem Ausfall gehörte. Solange eine Notfalländerung offen ist, steht im Block Noch offen: 1 Notfalländerung(en). Prüfen Sie vor dem Stand-down, ob die Wiederherstellung den Freigabeweg durchlaufen hat.
Schritt 2: Ein Problem anlegen
Klicken Sie im selben Block beim Problem auf Problem anlegen, tragen Sie bei Titel (optional) einen Titel ein und klicken Sie erneut auf Problem anlegen. Es erscheint Problem … wurde angelegt. Das Problem ist mit dem Vorgang verknüpft. Gibt es schon ein passendes, nutzen Sie Bestehendem Problem zuordnen.

- 1Verknüpfte Notfalländerung
- 2Verknüpftes Problem
Warum? Ein Major Incident ist fast immer ein Anlass für ein Problem: Die Störung ist behoben, die Ursache noch nicht. Beim Stand-down fragt knooing deshalb, ob ein Problem verknüpft ist (siehe Major Incident beenden und nachbetrachten). Der Block Known Error und Workaround zeigt, ob eine bekannte Ursache mit Umgehungslösung angewendet wurde.
Schritt 3: Die vollständige Zeitachse prüfen
Scrollen Sie im Reiter Vorfall-Betrieb ganz nach unten und klappen Sie Vollständige Zeitachse anzeigen auf. Sie ordnet alle Ereignisse zum Vorgang in eine Reihenfolge: Major-Incident-Ereignisse, Zuweisungen, Notizen, Kind-Incidents, SLA und Eskalation, Lieferanten, DORA sowie verknüpfte Änderungen und Probleme. Jede Zeile zeigt Zeitpunkt, seit Ausrufung …, Ereignis, Person und Sichtbarkeit (intern, für Kunden und so weiter).
Schränken Sie die Ansicht ein:
- Bei Umfang wählen Sie Ganzer Vorgang oder, wenn es mehrere Ausrufungen gab, eine einzelne (Ausrufung vom …).
- Bei Zeitspanne seit der Ausrufung wählen Sie Gesamter Verlauf, Erste Stunde, Erste 4 Stunden, Erste 24 Stunden oder Vor der Ausrufung.
- Mit den Schaltflächen darunter wählen Sie die Art der Ereignisse, zum Beispiel Major Incident und Änderung. Die Zahl in Klammern nennt die Ereignisse dieser Art. Ohne Auswahl sehen Sie alle.
Unter den Schaltflächen steht, wie viele Ereignisse die Ansicht zeigt, zum Beispiel 11 von 23 Ereignissen.

- 1Zeitspanne wählen
- 2Art der Ereignisse wählen
- 3CSV exportieren
Warum? Nach einem Major Incident muss man lückenlos rekonstruieren können, wann was geschah: für die Nachbetrachtung, für Meldungen an Aufsichten und für Prüfungen. Eine Zeitachse, die nur Krisenereignisse kennt, reicht dafür nicht. Notizen, Zuweisungen, Fristen und Änderungen gehören in dieselbe Reihenfolge.
Beispiel: Erste Stunde zeigt die Ausrufung um 11:58, das erste Update für Kunden mit seit Ausrufung +7 min und die Notfalländerung mit seit Ausrufung +11 min.
Schritt 4: Die Zeitachse exportieren
Klicken Sie auf CSV exportieren oder JSON exportieren. Der Export enthält genau die Ereignisse, die Sie gerade sehen, also die gefilterte Ansicht. Die CSV-Datei ist Semikolon-getrennt und hat die Spalten Zeitpunkt, Minuten seit Ausrufung, Art, Ereignis, Person, Sichtbarkeit, Vorgang, Text und Angaben. Sie lässt sich direkt in einer Tabellenkalkulation öffnen.
Schritt 5: Das Kommunikationsprotokoll herunterladen
Das Protokoll listet jede Kommunikationspflicht der Lage mit Fälligkeit, Erfüllungszeit und Erfassungszeit, jede Runde einer Takt-Pflicht einzeln. So ist auch sichtbar, was erst nachträglich eingetragen wurde. Es enthält auch ausgesetzte, versäumte und entfallene Pflichten.
Zwei Wege führen dorthin:
- Am Vorgang: im Block Kommunikationsfahrplan auf Kommunikationsprotokoll klicken. Dort stehen CSV und JSON. Der Block bleibt auch nach dem Stand-down am Vorgang stehen.
- Nach dem Ende: in der Seitenleiste Servicedesk, Major Incidents / DORA, Reiter Major Incidents. Im Abschnitt Beendet oder abgelehnt (letzte 90 Tage) wählen Sie in der Spalte Protokoll beim Vorgang CSV oder JSON.

- 1CSV oder JSON
Die CSV-Datei ist Semikolon-getrennt und nennt je Pflicht unter anderem Bezeichnung, Kanal, Runde, Fälligkeit, Status, Erfüllungs- und Erfassungszeit, die erfassende Person, den Notizen- oder Begründungstext und die Empfänger, Personen ohne Konto mit dem Zusatz „(ohne Konto)“. E-Mail-Adressen enthält sie nicht. Die JSON-Datei enthält dieselben Pflichten mit den E-Mail-Adressen der Empfänger und zusätzlich die Einträge des Nachweisjournals zur Lage. Die Adressen stehen nur im Klartext, wenn Ihr Konto personenbezogene Daten sehen darf, sonst sind sie maskiert oder fehlen. Jeder Abruf mit Adressen wird im Sicherheitsprotokoll vermerkt. Der Export ist ein normaler Export, kein prüffester Hash-Export.
Warum? Bei einer Prüfung oder Aufsichtsanfrage muss man belegen können, dass die Kommunikationspflichten gehalten wurden. Die Zeit der Erfassung neben der Zeit der Erfüllung zeigt, was nachträglich eingetragen wurde.
Beispiel: Die interne Revision fragt, wann die Geschäftsleitung zum Ausfall des Auftragsportals informiert wurde. Die Zeile „Geschäftsleitung informieren (Art. 17 Abs. 3 lit. e DORA)“ nennt Fälligkeit, Erfüllung und die erfassende Person.
Wenn etwas nicht klappt
- „Die Zeitachse konnte nicht geladen werden.“ Laden Sie die Seite neu und klappen Sie die Zeitachse erneut auf.
- „Keine Ereignisse in dieser Auswahl.“ Ihre Filter schließen alle Ereignisse aus. Wählen Sie eine längere Zeitspanne oder heben Sie die Auswahl der Arten auf.
- „Das Protokoll konnte nicht heruntergeladen werden.“ Versuchen Sie es erneut. Für Vorgänge, die nie ausgerufen wurden, gibt es kein Protokoll.
- Im Abschnitt Beendet oder abgelehnt fehlt ein Vorgang. Die Liste zeigt die letzten 90 Tage. Ältere Lagen finden Sie über den Vorgang selbst.