Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Praxis · Supply Chain
Warum Ausnahmemeldungen ignoriert werden und wie Zurückhaltung das behebt
Auf einen Blick
- Ausnahmemeldungen scheitern aus einem Grund, der nichts mit den Daten zu tun hat: Sie behandeln einen Menschen wie eine Warteschlange. Wer jede Zeile jeden Tag verschickt, hat nach einer Woche einen Ordner, den niemand öffnet.
- Gute Ausnahmebehandlung heißt Zurückhaltung: eine Nachricht pro Person und Tag, nur das, was sich seit gestern geändert hat, nur das, was eine Entscheidung braucht.
- Menge wirkt wie Sorgfalt. Tatsächlich bewirkt sie das Gegenteil, denn jede überflüssige Meldung macht die nächste leichter zu ignorieren.
- Eine Meldung, die niemand liest, ist schlechter als keine. Sie erzieht das Team zum Wegsehen und nimmt die wichtige Meldung mit.
In einer Planungsabteilung läuft irgendwo eine Regel, die auf jede Zeile feuert, jeden Tag, ob sich etwas geändert hat oder nicht. Sie begann als gute Idee: Niemand wollte eine Ausnahme verpassen, also meldete das System alles, was wichtig sein könnte. Sechs Monate später hat der Bericht einen eigenen Ordner mit Tausenden ungelesenen Mails. Die eine Mail, die eine Entscheidung am selben Tag verlangte, sah genauso aus wie die zweihundert, die nichts verlangten. Sie wartete mit ihnen, und als jemand sie öffnete, war der Liefertermin schon vorbei. Das Team ist nicht nachlässig. Die Meldung hörte an dem Tag auf, Information zu sein, an dem sie auch ohne Anlass kam. Dieser Beitrag zeigt, warum die Menge an Ausnahmemeldungen aufläuft, was die Müdigkeit kostet, wie Sie sie in IFS Cloud erkennen und wie Sie die Meldung so umbauen, dass nur noch die ankommt, auf die es ankommt.
1.Warum läuft die Menge an Ausnahmemeldungen auf?
Niemand baut absichtlich einen Bericht, den keiner liest. Am Anfang steht ein nachvollziehbarer Gedanke: lieber alles melden als etwas verpassen. Die erste Version der Regel wirft deshalb ein weites Netz aus (jede offene Bestellung, jede Position unter Soll, jeden Lieferanten mit einem Termin in der Vergangenheit) und geht live, weil breite Abdeckung in der Demo gründlich aussieht. Tatsächlich bekommt der Empfänger eine Sortieraufgabe im Gewand einer Meldung. Jede Zeile verlangt dieselben fünf Sekunden Aufmerksamkeit, um zu klären, ob sie zählt.
Nach dem Livegang bleibt die Menge stehen, solange niemand sie infrage stellt, weil das Herunterdrehen einer Meldung nach weniger Sichtbarkeit aussieht und niemand das Sicherheitsnetz still abbauen will. Der Bericht feuert also in voller Menge weiter, lange nachdem alle gelernt haben, darüber hinwegzulesen. Die Regel, die die wichtige Ausnahme fangen sollte, geht im Rauschen unter, das sie selbst erzeugt hat.
2.Was kostet Alarmmüdigkeit tatsächlich?
Der Schaden liegt nicht im Rauschen selbst, sondern darin, wie das Rauschen Menschen im Umgang mit jeder späteren Meldung prägt, auch mit den wichtigen:
- Antrainierte Blindheit. Nach genug irrelevanten Meldungen unterscheidet das Gehirn nicht zwischen ihnen und den wichtigen, und jede Nachricht bekommt denselben flüchtigen Blick.
- Verspätete Entscheidungen. Die eine Zeile, die heute Handlung verlangte, liegt ungelesen in einem Ordner für Zeilen, die nichts verlangten, und taucht erst auf, wenn die Frist abgelaufen ist.
- Verschwendete Sichtungszeit. Jemand muss den Bericht trotzdem gelegentlich öffnen und von Hand herausfinden, welche von zweihundert Zeilen echt ist. Genau diese Arbeit sollte die Automatisierung abnehmen.
- Vertrauensverlust für jede künftige Meldung. Hat ein Bericht einmal den Ruf, nur Lärm zu machen, vertraut das Team auch dem nächsten System nicht, das etwas meldet.
Eine Meldung, die niemand liest, ist nicht neutral. Sie ist schlechter als keine, denn sie erzieht das Team zum Wegsehen und nimmt die wichtige Meldung mit.
3.Woran erkennen Sie das in IFS Cloud?
Müdigkeit zeigt sich eher in einer Ordnerregel als in einer Beschwerde: in einer Regel, die die Meldung am Posteingang vorbeileitet, in einem Empfänger, der seit Monaten auf den Verteiler nicht antwortet, oder in einem Custom-Event-Protokoll, in dem dieselbe Nachricht täglich für dieselben Bestellungen feuert, ohne dass sich das Ergebnis ändert. Jedes dieser Zeichen beschreibt eine Meldung, die aufgehört hat, als Meldung zu funktionieren.
Am Anfang steht das Zählen, nicht der Umbau. Erheben Sie für jede wiederkehrende Benachrichtigung drei Zahlen: die Nachrichten des letzten Monats, davon die mit echter Änderung gegenüber der vorherigen Nachricht, davon die, bei denen der Empfänger entscheiden musste. Liegen die zweite und die dritte Zahl weit unter der ersten, feuert die Regel auf Vorhandensein statt auf Änderung. Genau diese Lücke soll eine Custom-Event-Bedingung stattdessen prüfen.
4.Alles melden oder Ausnahmen mit Disziplin entwerfen
Der Unterschied liegt nicht in der Raffinesse, sondern in der Disziplin bei drei Regeln: auf Änderung feuern statt auf Vorhandensein, auf eine Nachricht pro Person und Tag begrenzen und nur die Zeilen weitergeben, die eine menschliche Entscheidung brauchen. Dieselbe Custom-Event-Mechanik, die jede Regel im Katalog der SCM-Automatisierungen antreibt, trägt beide Muster. Der Unterschied liegt allein darin, wie Bedingung und Frequenzgrenze geschrieben sind.
| Alles melden | Disziplinierter Entwurf | |
|---|---|---|
| Auslöser | Vorhandensein einer Bedingung | Änderung einer Bedingung |
| Frequenz | Bei jedem Lauf, unabhängig von früheren Sendungen | Begrenzt: einmal pro Person und Tag |
| Inhalt | Jede passende Zeile | Nur Zeilen, die eine Entscheidung brauchen |
| Reaktion des Empfängers | Überfliegen, ignorieren, Ordnerregel | Lesen, handeln |
| Vertrauen im Zeitverlauf | Sinkt | Bleibt |
Eine Regel, die nur bei Änderung feuert, ist nicht schwächer. Es ist dieselbe Erkennungslogik mit einer zusätzlichen Bedingung (hat sich das seit meiner letzten Meldung geändert), die aus einer Warteschlange von Zeilen eine kurze, verlässliche Liste macht.
5.Wie führen Sie diszipliniertes Melden sicher ein?
Eine laufende Meldung ohne Plan umzubauen erzeugt nur anderes Chaos. Straffen Sie sie in Stufen und lassen Sie die Empfänger jeden Schritt bestätigen, bevor der nächste folgt.
- Aktuelle Menge auswerten. Ziehen Sie einen Monat Versandhistorie und zählen Sie getrennt die Nachrichten mit echter Änderung und die Nachrichten, die den Stand von gestern wiederholten.
- „Änderung“ ausdrücklich definieren. Legen Sie die Bedingung fest, die eine echte Ausnahme von einer Zeile trennt, die nur weiter besteht: ein Statuswechsel, eine Terminverschiebung, eine überschrittene Schwelle.
- Neue Bedingung im Probelauf (Dry-run) fahren. Protokollieren Sie, was die gestraffte Regel im letzten Monat versendet hätte, und vergleichen Sie es mit dem, was tatsächlich Handlung verlangte.
- Frequenz begrenzen. Eine Nachricht pro Person und Tag; alle Ausnahmen einer Person werden zu einer Zusammenfassung gebündelt statt einzeln verschickt.
- Mit einem Team pilotieren, dann auswerten. Fragen Sie direkt, ob die Meldung jetzt gelesen wird, und justieren Sie die Schwelle, bevor Sie weiter ausrollen.
Die überarbeitete Regel entsteht weiterhin im IFS Extensibility Framework (Standard-Custom-Events, Workflows und PL/SQL) und ist deshalb update-sicher. Das Straffen der Bedingung ändert, was feuert, nicht den Core, sodass das nächste Release die Arbeit nicht rückgängig macht.
6.Fragen und Antworten
Was ist Alarmmüdigkeit in der Lieferkette?
Alarmmüdigkeit ist der Zustand, in dem ein Empfänger Meldungen von geringem Wert in einer Menge erhält, die ihn alle Meldungen nur noch flüchtig lesen lässt, auch die eine, die am selben Tag Handlung verlangt. Die Ausnahme selbst wird womöglich korrekt erkannt. Der Fehler liegt vollständig darin, ob jemand sie bemerkt.
Ist es nicht sicherer, alles zu melden, als etwas zu verpassen?
Es fühlt sich sicherer an, führt aber zum gegenteiligen Ergebnis. Hat ein Bericht den Ruf, nur Lärm zu machen, vertraut ihm niemand, und die wirklich wichtige Ausnahme wird mit geringerer Wahrscheinlichkeit gelesen als in einer kürzeren Liste, der man traut.
Welche Zahl an Meldungen pro Tag ist zu hoch?
Eine allgemeingültige Zahl gibt es nicht, aber eine zusammengefasste Nachricht pro Person und Tag ist ein verlässliches Arbeitsziel. Reicht eine Nachricht pro Person und Tag nicht aus, um echte Änderungen abzudecken, ist die Bedingung der Regel vermutlich zu weit gefasst und sollte zuerst gestrafft werden.
Riskiere ich, beim Straffen einer bestehenden Meldung etwas Wichtiges zu verpassen?
Nicht, wenn Sie die gestraffte Bedingung zuerst im Dry-run fahren und gegen einen Monat Historie vergleichen, bevor Sie sie einschalten. Dieser Vergleich bestätigt, dass die neue Regel alles fängt, was zählte, und nur die Zeilen weglässt, die nichts verlangten.
7.Über den Autor
Dariusz Myśliwiec: 18 Jahre Praxis mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Krakau, remote tätig in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Ausgewählte Kunden: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
Meldungen, die wieder gelesen werden
Hat Ihr Team einen Bericht mit eigenem Ordner voller ungelesener Mails, liegt die Lösung bei weniger Meldungen, besser gezielt. In einem 30-Minuten-Gespräch sehen wir uns eine laufende Regel an und skizzieren, was eine disziplinierte Fassung stattdessen versenden würde (Festpreis, Probelauf, bevor sich etwas ändert).
