Störungen erfassen und priorisieren

Worum es geht

Dienstag, 7.50 Uhr, Service Desk der Alpnet Informatik AG in Sarnen. Ronja hat gerade ihren Kaffee abgestellt, da klingelt das Telefon. «Das ERP ist extrem langsam», sagt eine Projektleiterin der Holzbau Durrer AG. Zwei Minuten später: «Meine Pläne auf dem Laufwerk P: öffnen sich nicht.» Und kurz darauf ein dritter Anruf aus derselben Firma.

In diesem Moment entscheidet sich, ob die Störung in einer Stunde gelöst ist oder ob sie den ganzen Vormittag frisst. Nicht weil Ronja sofort die Ursache kennt, sondern weil sie richtig erfasst: Wer ist betroffen, seit wann, was genau passiert? Und weil sie erkennt, dass drei Anrufe vielleicht nur eine Störung sind.

In dieser Lektion lernst du, eine Störungsmeldung so aufzunehmen, dass dein Team sofort weiss, worum es geht, und ihr eine begründete Priorität zu geben. Das klingt nach Formularkram, ist aber die halbe Miete: Ein gut erfasstes Ticket spart beim Eingrenzen, beim Eskalieren und beim Dokumentieren jedes Mal Zeit.

Was eine Störung ist und was nicht

Im Support landen ganz verschiedene Anliegen im selben Ticketsystem. Damit du richtig reagierst, unterscheidest du vier Begriffe:

Bei einem Incident ist das erste Ziel immer: Der Dienst soll wieder laufen. Das kann eine echte Lösung sein oder ein Workaround, also eine vorübergehende Umgehung. Beispiel: Outlook Desktop verbindet nicht, Outlook im Web funktioniert. Die Leute können weiterarbeiten, während du die Ursache suchst.

Jedes Ticket durchläuft einen Lebenszyklus. Die Namen der Status unterscheiden sich je nach Werkzeug (Jira Service Management, TOPdesk, Freshservice), das Prinzip ist überall gleich:

Die richtigen Fragen am Telefon

Anrufende beschreiben das Symptom aus ihrer Sicht: «Teams geht nicht», «alles ist langsam», «der Drucker spinnt». Deine Aufgabe ist es, daraus in zwei Minuten eine prüfbare Beschreibung zu machen. Dafür helfen dir die W-Fragen:

Aus den Antworten schreibst du einen Tickettitel, der das Symptom und den Umfang nennt, und eine Beschreibung mit den Fakten. Vergleiche:

Priorität: Auswirkung mal Dringlichkeit

Nicht jede Störung ist gleich dringend. Die Priorität legt fest, wer wann daran arbeitet und welche Reaktions- und Lösungszeit gilt. Sie entsteht aus zwei Fragen:

• Auswirkung: Wie viele Personen oder wie wichtige Geschäftsprozesse sind betroffen?
• Dringlichkeit: Wie schnell wird es teuer oder gefährlich? Gibt es einen Workaround?

Jeder Betrieb hat seine eigene Matrix. Bei der Alpnet Informatik AG sieht sie so aus (Beispiel):

Dazu gehört ein SLA (Service Level Agreement), das mit dem Kunden vereinbart ist. Bei Alpnet gilt zum Beispiel:

Drei Beispiele mit dieser Matrix:

1. Eine Sachbearbeiterin kommt nirgends mehr in Outlook und Teams, sonst niemand betroffen: Auswirkung gering, Dringlichkeit hoch, also P3.
2. Die ganze Planungsabteilung mit 14 Personen ist blockiert, die Produktion läuft: Auswirkung mittel, Dringlichkeit hoch, also P2.
3. SharePoint ist bei Microsoft gestört, 60 Mitarbeitende betroffen, aber die synchronisierten Dateien sind offline nutzbar: Auswirkung hoch, Dringlichkeit mittel, also P2.

Die Matrix ist reine Logik und eignet sich deshalb gut als kleines Programm. Im Labor setzt du sie in Python um:

Viele Anrufe, eine Ursache: Sammeltickets

Wenn innerhalb kurzer Zeit mehrere ähnliche Meldungen kommen, ist das ein starkes Signal: Wahrscheinlich steckt eine gemeinsame Ursache dahinter. Achte auf diese Muster:

• gleicher Kunde oder gleicher Standort
• gleicher Dienst oder gleiches Symptom (ERP langsam, Laufwerk hängt)
• Beginn im selben Zeitfenster (z.B. alle «seit etwa 7.45»)
• gleiche Abteilung, die dieselben Server nutzt

Dann legst du ein übergeordnetes Ticket an (je nach System «Major Incident», «Parent» oder «Sammelticket») und verknüpfst die einzelnen Meldungen damit. Die Diagnose und die Kommunikation laufen nur noch über dieses eine Ticket. Das hat drei Vorteile: Niemand im Team sucht parallel am selben Fehler, alle Betroffenen bekommen dieselbe Information, und am Ende siehst du genau, wie viele Personen betroffen waren.

Schritt für Schritt: Ronjas erste zehn Minuten

So hat Ronja am Dienstagmorgen die drei Anrufe der Holzbau Durrer AG verarbeitet:

1. 7.50 Uhr, Anruf 1 (Projektleiterin Planung): Ronja fragt nach Symptom, Beginn und Fehlermeldung. Notiz: «ERP reagiert extrem langsam, seit ca. 7.45, keine Meldung.» Ticket T-4711 angelegt, noch ohne Priorität.
2. 7.52 Uhr, Anruf 2 (Zeichner Planung): «Pläne auf P: öffnen sich nicht.» Ronja fragt nach: «Funktioniert Outlook?» Ja. Ticket T-4712.
3. 7.55 Uhr, Anruf 3 (Bauleiter, ebenfalls Planung): ERP langsam, Laufwerk P: hängt. Ronja erkennt das Muster: gleicher Kunde, gleiche Abteilung, gleiches Zeitfenster, zwei Dienste, die beide auf dem Hyper-V-Host laufen.
4. 7.57 Uhr, Umfang klären: Ronja ruft die Projektleiterin zurück: «Ist die ganze Planung betroffen? Läuft die Produktion?» Antwort: alle 14 Personen der Planung, die Produktion arbeitet mit Papieraufträgen normal weiter.
5. 7.58 Uhr, Sammelticket: Ronja eröffnet T-4713 als übergeordnetes Ticket und verknüpft T-4711 und T-4712, die dritte Meldung erfasst sie direkt darin. Titel: «ERP langsam und Laufwerk P: hängt, Planung Holzbau Durrer (14 Pers.), seit ca. 7.45».
6. 7.59 Uhr, Priorität: Auswirkung mittel (eine Abteilung), Dringlichkeit hoch (kein Workaround, Planung blockiert). Ergebnis P2. Reaktion bis 8.28 Uhr, Lösungsziel 15.58 Uhr.
7. 8.00 Uhr, Rückmeldung: Kurze Info an die Projektleiterin: «Wir haben die Störung aufgenommen und prüfen jetzt die Server. Ich melde mich spätestens um 8.30 Uhr wieder.»

Die Beschreibung im Sammelticket sieht dann so aus:

Symptom:     ERP reagiert nach 20 bis 30 s, Laufwerk P: (SRV-FS01) lädt nicht
Betroffen:   Planung Holzbau Durrer AG, 14 Personen; Produktion nicht betroffen
Beginn:      ca. 07:45 (erste Meldung 07:50)
Funktioniert: Outlook, Teams, Internet
Meldungen:   keine Fehlermeldung, nur Sanduhr
Änderungen:  keine bekannt
Priorität:   P2 (Auswirkung mittel, Dringlichkeit hoch, kein Workaround)
Verknüpft:   T-4711, T-4712

Jetzt weiss jede Person im Team, was los ist, ohne nochmals anzurufen. Im Labor prüfst du solche Tickets automatisch auf fehlende Angaben:

{"wer": "M. Durrer, Planung", "was": "ERP sehr langsam", "seit": "07:45",
 "wo": "Planung Holzbau Durrer", "fehlermeldung": "keine, nur Sanduhr", "betroffene": 14}

Typische Fehler

• Sofort loslegen, ohne zu fragen. Wer bei «Outlook geht nicht» direkt das Profil neu anlegt, merkt erst nach 30 Minuten, dass alle im Haus betroffen sind. Erst W-Fragen, dann handeln.
• Interpretation statt Symptom notieren. «Netzwerkproblem» ist eine Vermutung. Schreib auf, was die Person sieht: «Webseiten laden, Laufwerk P: nicht.»
• Jeden Anruf einzeln bearbeiten. Drei Tickets zum selben Problem heissen drei Leute, die parallel suchen. Muster erkennen und ein Sammelticket anlegen.
• Priorität nach Gefühl. Wer laut ist, bekommt P1, wer höflich ist, P4. Nutze die Matrix und schreib die Begründung ins Ticket.
• Keinen Rückmeldezeitpunkt nennen. Ohne «ich melde mich um 8.30 Uhr» rufen die Betroffenen alle zehn Minuten wieder an.

Zusammenfassung

• Ein Incident ist eine ungeplante Störung eines Dienstes. Zuerst zählt, dass die Leute wieder arbeiten können (Lösung oder Workaround).
• Mit den W-Fragen (wer, was genau, seit wann, wo, welche Meldung, wie viele, was hat sich verändert, Workaround) machst du aus einer Klage eine prüfbare Beschreibung.
• Die Priorität ergibt sich aus Auswirkung und Dringlichkeit nach der Matrix des Betriebs. Sie bestimmt Reaktions- und Lösungszeit laut SLA.
• Mehrere ähnliche Meldungen im selben Zeitfenster deuten auf eine gemeinsame Ursache. Fasse sie in einem Sammelticket zusammen.
• Ein guter Tickettitel nennt Symptom, Betroffene und Beginn. Die Begründung der Priorität steht im Ticket.
• Nenne Betroffenen immer, wann sie wieder von dir hören.