Dienstag, 09:05 Uhr, Packlinie 4. Der Etikettendrucker bleibt nach jedem zehnten Karton stehen. Lukas, Schichtleiter, hat Handschuhe an und einen Scanner in der Hand. Der nächste Rechner steht im Meisterbüro, zwei Hallen weiter.
Also ruft er an. Bei der Instandhaltung, beim Kollegen aus der IT, manchmal bei der Person, die er gerade erreicht. Das ist richtig so, denn ein Anruf ist der schnellste Weg, eine Störung loszuwerden. Ins Ticketsystem kommt sie erst später, wenn jemand Zeit hat. Oder gar nicht, weil sich das Problem nach einer halben Stunde erledigt hat und keiner mehr daran denkt.
In diesem Artikel geht es darum, warum genau dieser Anruf der wertvollste Moment einer Störung ist und wie wir ihn in IncidentLive festhalten: mit einer Störungshotline, bei der IncidentLive abnimmt. Lukas muss weiterhin nichts anderes tun als anzurufen, nur eben eine Nummer statt drei verschiedener Kollegen.
Warum Störungen immer noch per Telefon gemeldet werden
In der Fertigung, in der Logistik, in der Haustechnik und in jeder Nachtschicht ist das Telefon der Meldeweg Nummer eins. Nicht weil die Leute keine Tools kennen, sondern weil die Situation es so vorgibt:
- Die Hände sind voll. Wer gerade eine Maschine absichert, tippt kein Formular.
- Es eilt. Ein Anruf dauert eine Minute, ein vollständiges Ticket fünf bis zehn.
- Man will eine Rückfrage stellen können. Am Telefon fragt die andere Seite sofort nach.
Das Problem ist also nicht der Anruf. Das Problem ist, dass er keine Spur hinterlässt. Wer abnimmt, notiert sich vielleicht etwas auf einem Zettel. Das Ticket entsteht später, mit der Uhrzeit, zu der es angelegt wurde, und mit den Worten der Person, die es abtippt. Wer angerufen hat, um wie viel Uhr und was er genau gesagt hat, steht nirgends.
Was in der späteren Nachbereitung fehlt
Solange die Störung läuft, fällt das kaum auf. Spätestens bei der Nachbereitung schon:
- Im 8D-Report fragt D2, wann das Problem zuerst aufgetreten ist und wer es bemerkt hat. Steht im Ticket 09:48 Uhr, weil es dann angelegt wurde, ist die Problembeschreibung schon am Anfang falsch. Mehr dazu in unserem Artikel zum 8D-Report.
- Bei einer NIS2-Meldung zählt, wann ihr von einem erheblichen Vorfall Kenntnis hattet. Die Frühwarnung muss innerhalb von 24 Stunden raus. Ohne belegten Zeitpunkt diskutiert ihr hinterher, ab wann die Frist lief.
- Bei der Ursachenanalyse helfen die ersten Worte oft mehr als jede spätere Zusammenfassung. „Seit etwa 09:05, nach jedem zehnten Karton“ ist ein Hinweis. „Drucker defekt“ im Ticket ist keiner.
Wie die Telefonmeldung in IncidentLive abläuft
Der Ablauf ist absichtlich kurz. Lukas ruft nicht mehr die Instandhaltung oder den Kollegen aus der IT an, sondern die Störungshotline. Das ist eine feste Nummer für alle Störungen: eine interne Durchwahl, ein gespeicherter Kontakt in Teams oder eine Nummer bei Twilio. Am anderen Ende nimmt IncidentLive ab und stellt drei Fragen:
- Was ist passiert?
- Was ist betroffen?
- Seit wann?
Für jede Antwort hat er bis zu einer Minute, eine Pause oder die Rautetaste beendet sie. Wer lieber frei erzählt, kann stattdessen eine Nachricht von bis zu drei Minuten hinterlassen.
Den Schweregrad schätzt IncidentLive aus dem Gesagten ein, etwa ob eine Linie steht. Wer es selbst festlegen will, drückt eine Taste von 1 (sehr dringend) bis 4 (niedrig). Das Team kann den Grad jederzeit ändern, die Einschätzung ist ein Vorschlag.
Wenige Sekunden nach dem Auflegen ist die Störung angelegt:
- im Namen von Lukas, weil seine Nummer in seinem Profil hinterlegt ist,
- mit einem Titel aus seinem ersten Satz, nicht mit einem, den sich ein Modell ausgedacht hat,
- mit dem Anruf als erstem Eintrag der Zeitleiste, samt Uhrzeit und Wortlaut.
Die Störungsnummer bekommt Lukas per E-Mail, damit er später nachsehen kann, was daraus geworden ist. Ruft fünf Minuten später sein Kollege von Linie 5 wegen desselben Druckers an, entsteht keine zweite Störung: Der Anruf wird der offenen Störung hinzugefügt.
Ab da läuft alles wie bei jeder anderen Störung in IncidentLive. Alarme, Tickets und Notizen landen auf derselben Zeitleiste, Coding-Agents melden ihre Befunde per MCP, und wer wissen will, wie der Stand ist, fragt die Störung, statt Lukas noch einmal anzurufen.
Wer eine Störung anlegen darf
Eine Störungshotline, die jede Person anrufen kann, ist auch eine Einladung. Deshalb gelten ein paar feste Regeln:
- Bekannte Nummern: Jede Person hinterlegt bis zu drei Telefonnummern in ihrem Profil. Nur Anrufe von diesen Nummern legen direkt eine Störung in ihrem Namen an.
- Unbekannte oder unterdrückte Nummern legen nichts an. Sie landen in der Triage. Dort liest dein Team, was gesagt wurde, und entscheidet, ob daraus eine Störung wird. Das ist zum Beispiel der Fremdtechniker, der nachts meldet, dass das Kühllager in Halle 2 auf 9 Grad steigt.
- Ein Anruf kann genau zwei Dinge: eine Störung anlegen oder eine bestehende ergänzen. Er schließt nichts und ändert keine Berechtigungen. Was danach automatisch passieren soll, legt ihr selbst fest (mehr dazu unten).
- Gefälschte Nummern fallen auf. Legt jemand mit der gefälschten Nummer eines Kollegen eine Störung an, bekommt der Kollege darüber eine E-Mail.
Zusätzlich sind es höchstens fünf Anrufe pro Nummer und Stunde, damit ein Fehlalarm in der Wahlwiederholung nicht die Zeitleiste flutet.
Telefonanlage, Teams oder Twilio
Ihr braucht keinen neuen Telefonanbieter. IncidentLive lässt sich auf drei Wegen anbinden:
- Eure Telefonanlage per SIP, vor Ort oder in der Cloud, mit einer internen Durchwahl. Wichtig ist nur, dass die Anlage die Nummer des Anrufers mitschickt und nicht die der Zentrale, sonst kann IncidentLive niemanden erkennen.
- Microsoft Teams, etwa über einen gespeicherten Kontakt. Ein Anruf aus Teams funktioniert wie einer von jeder anderen Nummer.
- Twilio, wenn ihr eine eigene Rufnummer von außen erreichbar machen wollt. Das ist ein Weg, keine Voraussetzung.
Mit Telefonanlage oder Teams können die Anrufe komplett im internen Netz bleiben. Mit Twilio muss nur der Teil von außen erreichbar sein, der Anrufe annimmt.
Datenschutz am Telefon
Ein Anruf enthält mehr, als man denkt. Darum gehen wir mit ihm sparsam um:
- Die Spracherkennung läuft standardmäßig lokal auf euren Servern, nicht in einer fremden Cloud. Deutsch oder Englisch, eingestellt pro Nummer.
- Die Nummer des Anrufers wird nur gekürzt gespeichert.
- Passwörter und Schlüssel werden vor dem Speichern herausgesucht. Wer am Telefon „das Passwort ist …“ sagt, findet es nicht in der Zeitleiste wieder.
- Mit Twilio bleibt eine Aufnahme dort nur so lange, bis IncidentLive sie abgeholt hat, danach wird sie gelöscht. Alternativ könnt ihr die Spracherkennung von Twilio nutzen. Dann wird nichts aufgenommen, aber Twilio verarbeitet die Worte.
Was die Telefonmeldung nicht ist
IncidentLive ist kein Alerting und keine Rufbereitschaft, und es ersetzt euer Ticketsystem nicht. Die Telefonmeldung löst ein schmaleres Problem: Der erste Hinweis auf eine Störung kommt oft per Anruf, und der soll nicht verloren gehen.
Natürlich lässt sich aus einer gemeldeten Störung mehr ableiten. Ein Ticket in Jira oder GitHub anlegen, die Bereitschaft benachrichtigen, einen Workflow anstoßen: Das alles geht. Nur sieht es bei jedem Team anders aus. Welche Störung wen um drei Uhr nachts weckt, welche bis zum Morgen warten kann und welche gleich ein Ticket braucht, hängt von euren Abläufen ab. Deshalb gibt es dafür keinen Standard, der für alle passt. Wir stellen das mit euch individuell ein und bewerten vorher, was euch wirklich hilft und was nur zusätzlichen Lärm erzeugt.
Das klingt klein, aber in der Nachbereitung zahlt es sich aus. Der Anruf um 09:05 Uhr steht in der Zeitleiste, bevor irgendjemand das erste Ticket anlegt. Wenn später D1 bis D8 für den 8D-Report vorbereitet werden oder die Frühwarnung für das BSI ansteht, ist der Zeitpunkt belegt, mit dem Wortlaut von Lukas daneben.
Wie das in der Oberfläche aussieht und wie ihr eure Störungshotline einrichtet, zeigt die Seite Störung per Anruf melden. Für das Pilotprojekt richten wir IncidentLive auf euren Servern ein und binden es an eure Telefonanlage oder Teams an.