Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Beratung · Datenqualität
Die Ausnahme, die keine war: warum veraltete Statusdaten das Vertrauen in IFS Cloud untergraben
Auf einen Blick
- Eine falsche Ausnahmemeldung in IFS Cloud entsteht, wenn der Systemzustand der Wirklichkeit nicht gefolgt ist: Eine telefonisch bestätigte Bestellung steht Monate später noch im Status Released.
- Der halbe Tag, den die Klärung kostet, ist nicht der eigentliche Preis. Der eigentliche Preis ist, dass Mitarbeiter dem, was das System meldet, still das Vertrauen entziehen.
- Der Fehler entsteht, weil niemand dafür zuständig ist, nach einer mündlichen Bestätigung den Status in IFS nachzuziehen, und der Anruf sich bereits wie die Lösung anfühlt.
- Eine Abgleichsregel, die den Bestellstatus mit nachgelagerten Ereignissen vergleicht (Wareneingang, Rechnungsabgleich), findet die Abweichung, bevor ein Bericht einen Fehlalarm auslöst.
Eine Bestellung bleibt fünf Tage unbestätigt. Der Einkäufer hakt nach, der Lieferant bestätigt telefonisch, und der Einkäufer wendet sich dem nächsten Brand zu. In IFS ändert sich nichts: Die Bestellung bleibt im Status Released, denn ein Telefonat ist keine Systemaktualisierung. Die Ware wird versandt und kommt an, der Wareneingang wird auf die Bestellung gebucht. Drei Monate später lässt jemand den Standardbericht zu unbestätigten Bestellungen laufen, und diese steht immer noch darauf. Jemand verbringt einen halben Tag damit, einer Lieferung nachzujagen, die längst stattgefunden hat: Er ruft die Bestellung auf, ruft den Lieferanten an und hört, mit Recht: „Das haben wir vor Monaten bestätigt.“ Beide Seiten haben recht, und die Daten beider Seiten stimmen nicht überein. Das ist kein Einkaufsfehler, sondern ein Abgleichfehler, eine Lücke zwischen dem, was in der Wirklichkeit geschah, und dem, was IFS mitgeteilt wurde. Er zersetzt das Vertrauen stärker als jede einzelne verpasste Bestellung.
1.Warum hinken die Statusdaten der Wirklichkeit so weit hinterher?
Bestätigt wird dort, wo es am schnellsten geht, und das Telefon ist schneller als das System. Ein Einkäufer, der einem Lieferanten nachläuft, will eine Antwort, keine Dateneingabe, also schließt der Anruf die operative Frage und endet dort. Die Aktualisierung von IFS danach ist ein zweiter Schritt ohne sichtbaren Lohn. Die Bestellung fühlt sich erledigt an, sie rutscht ans Ende der Liste und wird womöglich nie nachgezogen.
Die Lücke wächst, weil nichts sie schließt. IFS kann nicht wissen, dass ein Anruf stattgefunden hat, solange es ihm niemand sagt, und es gibt keine Aufforderung, keine Erinnerung und keine Folge, wenn der Status unverändert bleibt. Die Bestellung steht einfach da, technisch falsch und für alle richtig aussehend, außer für den einen Bericht, der sie schließlich meldet, lange nachdem der Zusammenhang, der sie erklärt hätte, vergessen ist.
2.Was kostet eine falsche Ausnahmemeldung?
Der halbe Tag, den die Suche nach einer bereits eingetroffenen Lieferung kostet, ist echtes Geld, aber der kleinste Teil der Rechnung. Der größere Teil baut sich über Monate still auf, als Muster und nicht als Einzelfall:
- Vergeudete Prüfzeit - Jeder Fehlalarm unterbricht einen Einkäufer oder Disponenten bei echter Arbeit, damit er etwas erneut prüft, das längst geklärt war.
- Wiederkehrende Fehlalarme - Ein Status, der nie korrigiert wird, taucht immer wieder im selben Bericht auf, sodass dasselbe Scheinproblem wiederholt untersucht wird.
- Schwindendes Vertrauen - Nach genügend Fehlalarmen glaubt niemand dem Bericht, auch nicht an den Tagen, an denen er recht hat.
- Schattenaufzeichnungen - Mitarbeiter führen eine eigene Nachverfolgung außerhalb von IFS (Postfächer, Tabellen, Haftnotizen), denen sie inzwischen mehr vertrauen als IFS.
Eine Ausnahme, die gar keine ist, ist schlimmer als eine verpasste, denn sie trainiert Mitarbeiter, die nächste Meldung nicht zu lesen, auch die, auf die es ankommt.
3.Wie unterscheiden Sie eine echte von einer falschen Ausnahme?
Der Beleg, dass ein Status veraltet ist, liegt bereits in IFS, nur nicht verknüpft. Eine Bestellung, die als unbestätigt markiert ist und zugleich einen gebuchten Wareneingang, eine nachgelagerte Warenausgabe oder einen bereits abgeglichenen Rechnungseingang hat, ist keine offene Frage, sondern eine Datenabweichung im Gewand einer Ausnahme. Der Bericht muss nur beide Fakten vergleichen, um den Unterschied zu erkennen.
Dieser Abgleich macht aus einer verrauschten Liste eine kurze, glaubwürdige: Bestellungen, die tatsächlich unbestätigt sind und keine nachgelagerte Aktivität zeigen, rücken als echtes Risiko nach oben. Bestellungen, die nur auf dem Papier unbestätigt sind, aber schon laufen, werden still geschlossen oder zur Statuskorrektur markiert statt per Anruf verfolgt. Der Bericht löst keine Fehlalarme mehr aus, und die Leser beginnen, ihm wieder zu vertrauen.
4.Manueller Abgleich oder automatische Synchronisierung
Sich selbst überlassen, hängt das Schließen der Lücke zwischen mündlicher Bestätigung und Systemeintrag allein davon ab, dass jemand daran denkt, zurückzugehen und es zu korrigieren. Eine systematische Regel prüft beide Fakten jedes Mal gegeneinander, ohne dass ein Bericht laufen oder jemand etwas bemerken muss.
| Manuell | Systematisch | |
|---|---|---|
| Erkennt die Abweichung | nur, wenn jemand sie zufällig bemerkt | jedes Mal, wenn die beiden Datenpunkte nicht übereinstimmen |
| Läuft | wenn an den Bericht gedacht wird | fortlaufend, nach Zeitplan |
| Verantwortlicher | wer ans Telefon geht | die Regel, per Definition |
| Prüfpfad | keiner | protokolliertes Abgleichsereignis |
| Versagt, wenn | viel zu tun ist, jemand neu ist oder nichts davon weiß | nie: Sie schläft nicht |
Der Anruf soll nicht entfallen, denn eine mündliche Bestätigung kann der schnellste und vernünftigste Weg sein, eine festhängende Bestellung zu lösen. Entfallen soll die Haltung, das Systemupdate sei freiwillig. Werden beide Fakten automatisch geprüft, stimmen Anruf und Datensatz innerhalb von Minuten überein statt nach Quartalen.
5.Wie führen Sie es sicher ein?
Beginnen Sie eng, belegen Sie die Wirkung an echten Bestellungen und weiten Sie erst dann aus.
- Signal festlegen. Bestimmen Sie, welche nachgelagerten Ereignisse in Ihrem Unternehmen als Beleg für eine Bestätigung gelten (Wareneingang, Warenausgabe, Rechnungsabgleich).
- Im Dry-run laufen lassen. Vergleichen Sie über einen Testzeitraum den Bestellstatus mit diesen Ereignissen und protokollieren Sie die Abweichungen, ohne etwas zu ändern.
- Aktion festlegen. Entscheiden Sie, ob eine festgestellte Abweichung den Status automatisch korrigiert oder nur zur Bestätigung durch eine Person markiert wird.
- Mit einer Einkaufsgruppe pilotieren. Beobachten Sie einen vollen Zyklus, bevor Sie die Regel auf alle Standorte und Kategorien ausdehnen.
- Nach einem Monat auswerten. Prüfen Sie die Zahl der falschen Ausnahmen, die die Regel entfernt hat, und passen Sie die Signalliste an, wenn neue Muster auftauchen.
Die Regel entsteht vollständig im IFS Extensibility Framework (Standard-Custom-Events, Workflows und PL/SQL) und ist deshalb update-sicher. Es gibt keine Änderung am Standard, die das nächste Release brechen könnte, sodass der Upgrade-Aufwand vollständig entfällt.
Technisches 30-Minuten-Gespräch buchen SCM Automation Pack ansehen
6.FAQ
Was ist eine falsche Ausnahmemeldung in IFS Cloud?
Eine falsche Ausnahmemeldung ist ein Datensatz, den ein Bericht oder eine Regel als Problem markiert, etwa eine unbestätigte Bestellung, obwohl die Lage außerhalb des Systems längst geklärt war, etwa durch ein Telefonat oder eine E-Mail, die nie als Statusänderung in IFS ankam.
Warum weisen Sie die Mitarbeiter nicht einfach an, den Status nach jedem Anruf zu aktualisieren?
Anweisungen werden an ruhigen Tagen befolgt und an hektischen fallen gelassen, und genau dann öffnet sich die Lücke. Eine Abgleichsregel arbeitet unabhängig davon, wie ausgelastet der Einkäufer ist, weil sie den Beleg prüft, statt sich darauf zu verlassen, dass jemand an einen zusätzlichen Schritt denkt.
Verdeckt die automatische Statuskorrektur ein echtes Problem?
Nicht, wenn das Signal streng ist. Die Regel schließt die Lücke nur bei eindeutigem nachgelagertem Beleg (gebuchter Wareneingang oder abgeglichene Rechnung), nicht auf Verdacht. Alles unterhalb dieses Belegs wird einer Person gemeldet und nicht stillschweigend geändert.
Ist die Abgleichsregel update-sicher?
Ja. Die Abgleichsregel entsteht mit Standard-Custom-Events, Workflows und PL/SQL im IFS Extensibility Framework, ohne Änderung am Standard. Sie ist keine Anpassung, die das nächste Release R1/R2 unbemerkt zerstört.
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 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.
Schluss damit, Mitarbeiter zum Ignorieren des Berichts zu erziehen
Wenn Ihre Ausnahmeberichte still an Glaubwürdigkeit verlieren, zeigt ein Dry-run-Abgleich, welche der „offenen“ Positionen in der Wirklichkeit schon geschlossen sind. Im 30-Minuten-Gespräch bilde ich das Signal auf Ihre Daten ab: Festpreis, Dry-run, bevor etwas geändert wird.
