Übungsaufgaben zur Risikoanalyse im Projekt

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Risikoanalyse im Projekt“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/risikoanalyse
- https://oer-informatik.de/projektorganisation
- https://oer-informatik.de/stakeholderanalyse
- https://oer-informatik.de/hochverfuegbarkeit
- https://oer-informatik.de/datensicherung
- Stilbeispiel: https://oer-informatik.de/risikoanalyse-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Risikoanalyse
- Risikomanagement
- Risikomatrix
- Risikostrategien
- Frühwarnindikator
- Restrisiko
- FMEA
- Betriebsrisiken
- Notfallplan
- Projektmanagement

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Ein Risiko ist ein Ereignis, das eintreten kann, aber nicht sicher eintritt, und das dann die Projektziele (Termin, Kosten, Leistung) gefährdet. Beispiel: Die Händlerkonditionen könnten bei der Datenübernahme unvollständig übernommen werden, sodass Händler falsche Preise sehen. (1 Punkt)

• Ein Problem ist bereits eingetreten und muss jetzt gelöst werden. Beispiel: Die Tabellenkalkulation mit den Rahmenverträgen ist nicht auffindbar, die Konditionen fehlen seit heute im Testsystem. Ein eingetretenes Risiko wird zum Problem. (1 Punkt)

• Bewertungsgrößen: Eintrittswahrscheinlichkeit und Auswirkung (Schadensausmaß, Schadenshöhe). (je 1 Punkt, 2 Punkte)

Andere passende Beispiele sind möglich. Ein Beispiel für ein Problem muss etwas beschreiben, das schon eingetreten ist.

Je Risiko 1 Punkt für eine Ursache aus dem Bericht, 1 Punkt für ein unsicheres Ereignis (das Risiko) und 1 Punkt für eine Auswirkung mit dem betroffenen Projektziel, z. B.:

• Backend: Weil die Rabattregeln nur zur Hälfte aufgeschrieben sind und Cem noch keine solche Preislogik gebaut hat, kann es passieren, dass die Preislogik deutlich mehr als 80 Stunden braucht, mit der Folge, dass das Backend nicht rechtzeitig zum Pilotbetrieb am 01.02.2027 fertig wird (Termin) und zusätzliche Stunden das Budget belasten (Kosten).

• Shop: Weil Cem das Backend allein programmiert und in der Aktionszeit fast nur im Shop arbeitet, kann es passieren, dass die Backend-Arbeiten mehrere Wochen ruhen, mit der Folge, dass sich Pilotbetrieb und Start für alle Händler verschieben (Termin).

• Schlösser: Weil die neue Schnittstellenversion im ersten Quartal 2027 kommt und noch nicht beschrieben ist, kann es passieren, dass sie kurz vor oder nach dem Start am 01.03.2027 erscheint, mit der Folge, dass das Portal unter Zeitdruck angepasst werden muss und gleichschließende Schlösser zeitweise nicht konfiguriert werden können (Leistung, Kosten).

• Anfragegrenze: Weil der Zugang nur 200 Anfragen je Stunde erlaubt, kann es passieren, dass das Portal zum Saisonstart bei vielen gleichzeitigen Konfigurationen gesperrt wird, mit der Folge, dass Händler zeitweise keine Räder mit Schlössern bestellen können (Leistung bzw. Qualität).

• Händler: Weil nur wenige Händler auf die Umfrage reagiert haben und einige beim Alten bleiben wollen, kann es passieren, dass das Portal nach dem Start kaum genutzt wird, mit der Folge, dass Bestellungen weiter von Hand erfasst werden und der erwartete Nutzen ausbleibt (Leistung).

• Budget: Weil bis Ende Oktober schon 1.500 € (rund 19 %) mehr ausgegeben wurden als geplant, kann es passieren, dass die 38.000 € bis zum Start nicht reichen, mit der Folge, dass Funktionen gestrichen oder Mittel nachbewilligt werden müssen (Kosten, Leistung).

Keine Punkte für das Ereignis, wenn nur ein Befund aus dem Bericht wiederholt wird, der schon eingetreten ist (z. B. „Die Preislogik ist noch nicht begonnen“): Das ist die Ursache, nicht das Risiko. Ebenso keine Punkte, wenn Ursache und Auswirkung vertauscht sind.

Je fehlerhaftem Eintrag 1 Punkt für Erkennen und Beschreiben des Fehlers, 1 Punkt für eine passende Korrektur:

• Nr. 1: Ursache und Auswirkung sind vertauscht. Korrektur: Ursache „Krankheit oder Überlastung durch den Shopbetrieb, Backend-Wissen liegt nur bei Cem“, Auswirkung „Das Backend wird nicht fertig, das Projekt verzögert sich“.

• Nr. 2: Das ist kein Risiko, sondern ein Problem – es ist bereits eingetreten. Korrektur: in die Liste offener Punkte bzw. Aufgaben übernehmen und sofort lösen; als Risiko könnte man formulieren „Die Testumgebung könnte zum Pilotstart erneut ausfallen“ mit der Maßnahme „Updates vorher auf einer Kopie testen, Sicherung des Servers vor jedem Update“.

• Nr. 3: Die Gegenmaßnahme passt nicht zum Risiko; eine Schulung verhindert keinen Datenverlust und begrenzt ihn auch nicht. Korrektur: vor der Übernahme vollständige Sicherung von CSB-Order, Testmigration mit einer Kopie und Abgleich der Datensatzanzahl, CSB-Order bis zum Abschalttermin als Rückfallebene behalten.

• Nr. 4 ist fachlich in Ordnung.

Je Vorschlag 1 Punkt für die Wirkung und 1 Punkt für einen passenden Nachteil, 1 Punkt für eine begründete Empfehlung:

Empfehlung z. B. A und B: Sie ergänzen sich, weil B die Eintrittswahrscheinlichkeit und A die Auswirkung senkt, und das Portal startet mit vollem Leistungsumfang. C bleibt als Notfallmaßnahme, falls die Lipper SchließTec keine Übergangsfrist zusagt. Andere Paare sind richtig, wenn die Begründung schlüssig ist.

Je richtiger Zuordnung 1 Punkt:

1. Übertragen – die finanziellen Folgen eines Ausfalls trägt teilweise der Hosting-Anbieter.

2. Vermeiden – durch den Verzicht kann das Risiko einer verspäteten oder fehlerhaften Chat-Funktion nicht mehr eintreten.

3. Vermindern – die Probeläufe senken die Wahrscheinlichkeit, dass bei der echten Übernahme Daten verloren gehen.

4. Akzeptieren – das Risiko wird bewusst getragen, weil eine Maßnahme mehr kosten würde als der geringe Mehraufwand.

• Eine vorbeugende Maßnahme setzt an der Ursache an, bevor das Risiko eintritt, und senkt die Eintrittswahrscheinlichkeit. Eine Notfallmaßnahme wird ausgelöst, wenn das Risiko eingetreten ist, und begrenzt den Schaden. (2 Punkte)

• Vorbeugend: Natalia Wróbel führt die Konditionen vor der Übernahme in einer einzigen, bereinigten Liste zusammen; die Pilothändler prüfen ihre Preise im Pilotbetrieb, bevor alle Händler freigeschaltet werden. (1 Punkt)

• Notfall: Stellt sich nach dem Start heraus, dass Konditionen fehlen (Auslöser z. B. mehr als drei Händler melden falsche Preise), bleibt CSB-Order bis zum 31.03.2027 als Rückfallebene nutzbar; betroffene Händler bestellen dort weiter, bis die Daten korrigiert sind, und falsch berechnete Rechnungen werden per Gutschrift korrigiert. (1 Punkt)

Je Methode mit Bezug 1 Punkt, z. B.:

• Brainstorming bzw. Risiko-Workshop beim Kick-off mit Orga-Team, Technikteam und Schul-IT.

• Lessons Learned aus früheren Schulveranstaltungen (z. B. Tag der offenen Tür, Abschlussfeiern) – was ist dort schiefgegangen?

• Befragung von Expert*innen: Svenja Krämer zu Netz und WLAN, Emre Aksoy zur Technik, die Hausmeisterei zu Strom und Gebäuden.

• Checkliste typischer Veranstaltungsrisiken (Absagen, Wetter, Technik, Erste Hilfe, Aufsicht).

• Auswertung der Stakeholderanalyse: Befürchtungen, z. B. aus dem Kollegium oder der Referierenden.

• Durchsicht des Projektplans: Vorgänge auf dem kritischen Pfad (Call for Participation bis 31.01.2027, Sessionplan bis 01.03.2027, Technikaufbau am Vortag).

Je Zeile 1 Punkt für Risikowert und Bereich (7 Punkte), 1 Punkt für die Reihenfolge:

Reihenfolge nach Risikowert: R6 (16), R3 (15), R2 (12), R5 (10), R1 (9), R4 (8), R7 (5). Wer R5 und R7 wegen der katastrophalen Auswirkung früher einplant und das begründet, erhält den Punkt ebenfalls.

Der Aussage ist nur teilweise zuzustimmen. (1 Punkt)

• Richtig ist: Wegen der geringen Eintrittswahrscheinlichkeit lohnen sich teure vorbeugende Maßnahmen (z. B. ein Notstromaggregat) nicht; das Risiko kann bewusst akzeptiert werden. (1 Punkt)

• Aber: Die Auswirkung ist katastrophal (Stufe 5) – ohne Strom fallen Streaming-Server, Access Points, Check-in und Infomonitore aus, und in Gebäude B liegen Mensa und Serverraum. Der Risikowert verdeckt das, weil er eine sehr kleine Wahrscheinlichkeit mit einem sehr großen Schaden verrechnet. (1 Punkt)

• Deshalb braucht R7 zumindest einen einfachen Notfallplan: Ansprechperson der Hausmeisterei bzw. Elektrofachkraft am Samstag erreichbar, Sicherungskasten bekannt, Ablauf für die Räumung bzw. die Verlegung der Sessions in Gebäude A und C, Check-in notfalls mit ausgedruckter Teilnehmendenliste. Außerdem wird das Risiko weiter beobachtet. (1 Punkt)

Je Risiko 1 Punkt für die vorbeugende Maßnahme, 1 Punkt für die Notfallmaßnahme, 1 Punkt für eine passende verantwortliche Person (Folgefehler aus b) werden berücksichtigt):

• Indikator: Zahl der Anmeldungen, wöchentlich in der Orga-Sitzung geprüft. Schwellenwerte z. B.: Liegen am 15.12.2026 weniger als 150 und am 31.01.2027 weniger als 250 Anmeldungen vor, werden die Notfallmaßnahmen gestartet. Mit 14 Anmeldungen am 19.10.2026 ist der Verlauf noch offen. (2 Punkte: Indikator mit Schwellenwert und Termin)

• Zweck: Ein Frühwarnindikator zeigt, dass ein Risiko wahrscheinlicher wird, bevor es eintritt. So bleibt Zeit, gegenzusteuern, und es ist vorher festgelegt, ab wann gehandelt wird und wer entscheidet. Risiken werden dadurch während des ganzen Projekts überwacht und die Risikoliste wird fortgeschrieben, statt nur einmal beim Kick-off erstellt zu werden. (2 Punkte)

Geg.: W_nachher = 2, S = 3
Ges.: R_nachher

R = W \cdot S

R_{nachher} = 2 \cdot 3

\underline{\underline{R_{nachher} = 6}}

Der neue Risikowert 6 liegt im grünen Bereich (vorher 12, gelb). (1 Punkt)

Das Restrisiko ist das Risiko, das nach einer Maßnahme übrig bleibt: Auch mit mehr Access Points kann das WLAN überlastet werden, etwa wenn mehr Geräte als erwartet kommen oder ein Access Point ausfällt. Das Team bewertet das Risiko nach der Maßnahme neu und entscheidet, ob das Restrisiko tragbar ist; dabei wird auch berücksichtigt, dass die Maßnahme Geld aus dem Technikbudget kostet. (2 Punkte)

• Eine Chance ist ein unsicheres Ereignis, das sich – wenn es eintritt – positiv auf die Projektziele auswirkt. Sie wird wie ein Risiko identifiziert und bewertet, die Maßnahmen sollen sie aber wahrscheinlicher machen bzw. ihren Nutzen vergrößern (z. B. in einer SWOT-Analyse unter „Opportunities“). (1 Punkt)

• Beispiel und Nutzung (2 Punkte), z. B.:

  • Ausbildungsbetriebe interessieren sich für das Barcamp → gezielt als Sponsoren oder Aussteller ansprechen, das entlastet das Budget von 6.000 €.

  • Die Aufzeichnungen aus Aula und Mensa können als Lernvideos weitergenutzt werden → Einwilligungen der Referierenden schon beim Einreichen der Session einholen.

  • Mehr Anmeldungen als erwartet → Warteliste und zusätzlichen Raum vorbereiten.

ha) RPZ = B \cdot A \cdot E = 5 \cdot 6 \cdot 4 = \underline{\underline{120}} (1 Punkt)

hb) z. B. (je Maßnahme 1 Punkt, 1 Punkt für die richtige Berechnung):

• Vor jeder Check-in-Schicht wird an beiden Druckern eine volle Rolle eingelegt, Ersatzrollen liegen am Terminal → Auftreten sinkt von 6 auf 2.

• Das Check-in-Terminal zeigt ab 30 verbleibenden Etiketten einen Hinweis an → Entdeckung sinkt von 4 auf 1.

• Die Bedeutung bleibt 5, weil sich an der Fehlerfolge nichts ändert.

RPZ_{neu} = 5 \cdot 2 \cdot 1 = \underline{\underline{10}}

hc) Entdeckung 1, weil der Hinweis am Terminal erscheint, bevor die Rolle leer ist; die Person am Check-in kann die Rolle in einer ruhigen Minute wechseln, ohne dass eine Warteschlange entsteht. Vorher (4) fiel die leere Rolle erst auf, wenn ein Badge nicht herauskam. (2 Punkte; andere Werte mit schlüssiger Begründung sind ebenfalls richtig)

• Ein Projektrisiko gefährdet die Ziele des Projekts – Termin, Kosten und Leistung der App-Erweiterung bis zum Start am 01.04.2027 – und endet mit dem Projektabschluss. Ein Betriebsrisiko gefährdet den laufenden Dienst und damit das Geschäftsmodell: Verfügbarkeit der Ortung, Daten der Kundschaft, Umsatz und Ruf. Es besteht, solange CSB-Rad den Dienst anbietet. Die Risikoliste wird deshalb nach dem Start nicht weggeworfen, sondern die Betriebsrisiken werden im Risiko- und Notfallmanagement des Unternehmens weitergeführt. (2 Punkte)

• Zuordnung (je 0,5 Punkte): 1 Projektrisiko, 2 Betriebsrisiko, 3 Betriebsrisiko, 4 Projektrisiko.

Je gewählter Komponente 3 Punkte (je 1 Punkt für Ursache, Auswirkung und Gegenmaßnahme, wenn sie konkret zum Dienst passen und zum benannten Betriebsrisiko der Komponente gehören), dazu 2 Punkte, wenn die drei Risiken aus mindestens zwei verschiedenen Bereichen stammen und der Bereich jeweils stimmig angegeben ist. Beispiele für alle sechs Bausteine:

• Tracker RadTrack 868 – Tracker fällt aus (technisch). Ursache: Akku leer, Feuchtigkeit oder Erschütterung beschädigen das Gerät, fehlerhafter Einbau. Auswirkung: Die Ortung ist ohne Vorwarnung nicht möglich; Austausch und Reklamationen kosten Geld. Gegenmaßnahme: Akkustand und letzte Meldung überwachen, App und Händler warnen bei niedrigem Akku; Einbauanleitung, Schulung der Händler und Funktionsprüfung nach dem Einbau.

• LoRaWAN-Funknetz des Netzbetreibers – Tracker meldet keine Position (technisch) oder der Netzbetreiber erhöht die Preise bzw. stellt das Netz ein (wirtschaftlich). Ursache: Das Rad steht in einer Tiefgarage oder einem Fahrradkeller ohne Funkabdeckung, Störung beim Netzbetreiber; Abhängigkeit von einem einzigen Anbieter. Auswirkung: Nach einem Diebstahl fehlt die aktuelle Position, Kund*innen sind enttäuscht und kündigen; bei Preiserhöhung Mehrkosten je Rad. Gegenmaßnahme: Tracker speichert Positionen zwischen und sendet sie nach, sobald wieder Empfang besteht; die App zeigt Zeitpunkt und Ort der letzten Meldung; Grenzen der Funkabdeckung in den Produktinformationen offen nennen; Vertrag mit langer Laufzeit und Preisbindung, Alternative mit zweitem Funkstandard prüfen.

• Plattform auf dem gemieteten Server – Ortungsdaten werden gestohlen oder verschlüsselt (technisch/rechtlich). Ursache: Cyberangriff auf den Server, unsichere Zugangsdaten von Kund*innen. Auswirkung: Bewegungsprofile werden öffentlich, Datenschutzverletzung mit Meldepflicht, der Dienst steht still, Vertrauensverlust. Gegenmaßnahme: Patch-Management, verschlüsselte Speicherung, nur kurze Speicherdauer der Positionen, Datensicherung mit Offline-Kopie, Notfallplan.

• Ortungs-App – Verstoß gegen den Datenschutz (rechtlich) oder zu wenige Abos (wirtschaftlich). Ursache: Positionen werden dauerhaft gespeichert oder für Werbung ausgewertet, Mitbenutzende des Rads wissen nichts von der Ortung; ein Wettbewerber bietet einen günstigeren Tracker an. Auswirkung: Bußgeld, Abmahnungen, negative Presse; die Fixkosten für Plattform und Support werden nicht gedeckt. Gegenmaßnahme: Zwei-Faktor-Anmeldung, Ortung nur auf Wunsch der Kundschaft, klare Hinweise in App und Vertrag, Datenschutz-Folgenabschätzung; Neuabschlüsse und Kündigungen monatlich auswerten, Preis- und Paketgestaltung anpassen.

• Händleransicht – Tracker werden nicht oder falsch aktiviert (technisch/organisatorisch). Ursache: Die Werkstätten haben in der Saison wenig Zeit, Mitarbeitende wechseln, die Zugangsdaten sind vergessen. Auswirkung: Kund*innen erhalten Sets, die nicht orten; Reklamationen und Ärger beim Fachhändler. Gegenmaßnahme: Aktivierung per Scan in wenigen Schritten, Prüfung der ersten Positionsmeldung direkt nach dem Einbau, Hilfe-Video und Ansprechperson bei CSB-Rad.

• Zahlungsdienstleister – Abo-Beiträge werden nicht eingezogen (wirtschaftlich). Ursache: Der Zahlungsdienstleister ändert seine Schnittstelle mit kurzer Vorankündigung oder fällt aus. Auswirkung: Einnahmen fehlen, Natalia Wróbel muss nachträglich abrechnen und mahnen. Gegenmaßnahme: fehlgeschlagene Zahlungen täglich überwachen; im Vertrag eine Ankündigungsfrist für Schnittstellenänderungen vereinbaren.

Handelt es sich um ein Projektrisiko (z. B. „Die Händleransicht wird nicht rechtzeitig fertig“) oder passt die Gegenmaßnahme zu einem anderen Risiko, gibt es für die betroffenen Angaben keine Punkte. Andere fachlich passende Lösungen sind möglich.

Je Hindernis 1 Punkt, 2 Punkte für das Risiko mit Folge, 2 Punkte für ein begründetes anderes Vorgehen, z. B.:

• Hindernisse: In der Saison haben die Werkstätten kaum Zeit für Einbau und Aktivierung. Die Händler lehnen ein weiteres Konto bzw. eine weitere Software ab, weil sie darin keinen eigenen Nutzen sehen.

• Beurteilung und Risiko: Das Vorgehen ist riskant. Werden die Händler erst kurz vor dem Start eingewiesen, kann es passieren, dass sie die Händleransicht ablehnen oder Tracker falsch bzw. gar nicht aktivieren. Kund*innen erhalten dann Sets, die nicht orten, und weil ein großer Teil der Sets über Fachhändler verkauft werden soll, wird der geplante Absatz zum Start verfehlt; Nacharbeit an der Händleransicht kurz vor dem Start verzögert das Projekt und kostet zusätzlich.

• Anderes Vorgehen: Katarzyna Nowak und zwei weitere Händler testen schon jetzt in kurzen Iterationen Entwürfe der Händleransicht. So wird die Aktivierung so einfach wie möglich (z. B. Anmeldung mit dem vorhandenen Händlerzugang statt eines neuen Kontos, Tracker per Scan des Codes auf dem Gerät aktivieren, Ablauf in unter zwei Minuten); eine Einbaupauschale gibt den Händlern einen eigenen Nutzen. Akzeptanzprobleme zeigen sich dann vor der Saison und nicht erst zum Start.

Andere stimmige Lösungen sind möglich, z. B. eine kurze Einweisung beim Händler mit Hilfe-Video außerhalb der Saison.

da) Strategie Vermindern (1 Punkt): Der Proof of Concept klärt unter echten Bedingungen, wo die Funkabdeckung nicht reicht, bevor Kund*innen enttäuscht werden. Dass Tracker in Tiefgaragen keine Positionen senden, ist aus dem Dienst für den Zweckverband schon bekannt; der Test zeigt, wie groß das Problem in Bielefeld ist. Die Ergebnisse fließen in die Machbarkeit, die Produktbeschreibung und die Bewertung des Risikos ein (z. B. Hinweis „keine Ortung in geschlossenen Garagen“, Nachsenden der Positionen). Der Test kostet wenig Zeit und Geld im Verhältnis zu Reklamationen und Kündigungen nach dem Start; er muss aber jetzt geplant werden, damit der Starttermin nicht gefährdet ist. Der Vorschlag ist sinnvoll. (2 Punkte)

db) Strategie Übertragen (1 Punkt): Die Versicherung übernimmt nur die finanziellen Folgen, etwa Kosten für Wiederherstellung oder Rechtsberatung. Das Risiko selbst bleibt: Bewegungsprofile der Kundschaft können trotzdem gestohlen werden. CSB-Rad muss die Datenschutzverletzung in der Regel binnen 72 Stunden der Aufsichtsbehörde melden und die Betroffenen informieren; der Vertrauensverlust trifft das Geschäftsmodell direkt. Außerdem verlangen Versicherer meist Mindestmaßnahmen der IT-Sicherheit. Die Versicherung ist deshalb nur eine Ergänzung zu vorbeugenden Maßnahmen (Updates, Zwei-Faktor-Anmeldung, Verschlüsselung) und einem Notfallplan; der Vorschlag allein reicht nicht. (2 Punkte)

Je Indikator mit Schwellenwert 1 Punkt, je passendem Risiko 1 Punkt, z. B.:

Die Schwellenwerte sind Beispiele; entscheidend ist, dass der Wert messbar ist und vor dem Schaden auffällt. Der Verlauf unten zeigt das Prinzip an der Kündigungsquote: Schon der steigende Trend ist ein Anlass, genauer hinzusehen; mit dem Überschreiten des Schwellenwerts beginnen die vorher festgelegten Maßnahmen.

Je Angabe mit passendem Beispiel 1 Punkt, z. B.:

• Auslöser: Ab wann gilt der Notfall? – z. B. Die App ist länger als 30 Minuten nicht erreichbar oder mehr als die Hälfte der Tracker meldet keine Positionen.

• Verantwortung und Entscheidung: Wer wird informiert, wer entscheidet? – z. B. Rufbereitschaft der IT, Entscheidung über den Notbetrieb durch Cem Sarıkaya, Vertretung festgelegt.

• maximale Ausfallzeit: Wie lange darf der Dienst höchstens ausfallen? – z. B. höchstens vier Stunden, weil Kund*innen bei einem Diebstahl schnell eine Position brauchen.

• Notbetrieb: Wie wird der wichtigste Teil des Dienstes vorläufig aufrechterhalten? – z. B. zweiter Server, auf den umgeschaltet wird; im Diebstahlfall ermittelt der Support die letzte Position aus der Datensicherung und schickt den Bericht per E-Mail.

• Kommunikation: Wer informiert die Kundschaft und die Fachhändler, auf welchem Weg? – z. B. Statusmeldung in der App und auf der Website, Vorlage für eine E-Mail an die Händler.

• Wiederanlauf und Nachbereitung: Wie wird der Normalbetrieb hergestellt und geprüft? – z. B. Daten aus der Sicherung zurückspielen, nachgesendete Positionen prüfen, Ursache in der Risikoliste festhalten.