Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Beratung · Supply Chain
12 Prozesse der Lieferkette, die Sie in IFS Cloud heute automatisieren können
Wer in IFS Cloud Prozesse der Lieferkette automatisiert, lässt das System die Daten überwachen, die es ohnehin hält, und Alarm schlagen, sobald eine Kennzahl eine von Ihnen gesetzte Grenze überschreitet. Jedes der zwölf Szenarien unten folgt dem Muster Auslöser, Aktion, Nutzen: Eine Bedingung in den Daten stößt eine Mail, einen Alarm oder eine Markierung an und schützt einen Betrag, den Sie sonst für Eilfracht, Fehlmengen oder verpasstes Skonto zahlen.
Auf einen Blick
- Das Hauptproblem im Tagesgeschäft ist ein übersehenes Signal, keine fehlende Funktion: Die Daten liegen in IFS Cloud, aber niemand beobachtet sie.
- Zwölf Szenarien aus Einkauf, Bestellanforderung, Lager und Rechnungsprüfung lassen sich mit dem Muster Auslöser → Aktion umsetzen.
- Gebaut im IFS Extensibility Framework (Custom Events, Workflows, PL/SQL) bleibt die Automatisierung update-sicher und bricht beim nächsten Release nicht.
- Jedes Szenario läuft zunächst im Probelauf (Dry-run) und mit Frequenzbegrenzung, damit aus einer manuellen Lücke kein Alarmhagel wird.
Wenn Ihre Einkäufer und Planer den Tag mit denselben Bildschirmen beginnen (unbestätigte Bestellungen, überfällige Lieferungen, gesperrte Rechnungen), bezahlen Sie Personal als Überwachungssystem. Das ist teuer, es liefert uneinheitliche Ergebnisse, und es versagt genau dann, wenn es darauf ankommt: zum Monatsabschluss, in den Ferien, bei Krankheit.
1.Warum Prüfungen in der Lieferkette automatisieren?
Eine manuelle Prüfung hat drei Schwachstellen: Sie fällt aus, wenn die Leute beschäftigt sind, sie wird zwischen Einkäufern und Standorten ungleich angewendet, und sie hinterlässt keinen Nachweis, den später jemand prüfen kann. Der Schaden ist nur ausnahmsweise ein einzelnes großes Ereignis; üblich ist ein stetiger Abfluss: eine Eilfracht hier, eine Fehlmenge dort, eine Preiserhöhung, die niemand hinterfragt hat, eine Rechnung, die über die Skontofrist hinaus gesperrt blieb. In der GuV steht dafür keine Zeile „Dinge, die wir nicht geprüft haben“.
Die Automatisierung nimmt dem Menschen die Erkennung ab, nicht die Entscheidung. Das System beobachtet gleichmäßig und ununterbrochen und leitet ein konkretes Signal an die Person, die handeln kann. In IFS Cloud ist diese Erkennungsschicht ein Custom Event: ein Standardmechanismus, der beim Ändern einer Zeile oder nach Zeitplan auslöst.
2.Das Muster: Auslöser, Aktion, Nutzen
Ein Auslöser ist eine Bedingung in Ihren Daten: eine Bestellung, die nach fünf Tagen unbestätigt ist, ein Lagerbestand unter dem Sicherheitsbestand. Eine Aktion ist die Antwort darauf: eine Mail an den Lieferanten, ein Alarm an den Einkäufer, eine Aufgabe im Posteingang, eine Markierung am Datensatz. Der Nutzen ist der Betrag, den Sie sich künftig sparen. Sind diese drei Punkte sauber definiert, ergibt sich die Umsetzung fast von selbst.
Zwei Sicherungen wiegen schwerer als jedes einzelne Szenario: ein Probelauf (Dry-run), der protokolliert, was ausgelöst worden wäre, bevor eine Mail an einen Lieferanten geht, und eine Frequenzbegrenzung, damit eine hängende Bestellung nicht eine Woche lang stündlich dieselbe Mail erzeugt.
3.Die zwölf Prozesse mit Auslöser und Nutzen
Die Szenarien verteilen sich auf vier Bereiche: Einkauf, Bestellanforderungen, Lager und Rechnungen. Keines verlangt eine Änderung am Standardcode; alle arbeiten nach dem Muster „lesen und melden“ oder „lesen und markieren“ auf Standard-Events.
| Nr. | Auslöser → Aktion | Nutzen |
|---|---|---|
| 1 | Eskalation unbestätigter Bestellungen. Bestellung nach X Tagen nicht bestätigt → Mail an den Lieferanten, Alarm an den Einkäufer. | Schließt die stille Lücke zwischen „bestellt“ und „beim Lieferanten angekommen“. |
| 2 | Lieferantenpreis über Schwelle. Neuer Preis weicht um über X % vom Rahmenvertrag ab → anhalten und Einkäufer informieren. | Hält schleichende Preiserhöhungen aus den Kosten fern, solange niemand sie geprüft hat. |
| 3 | Liefertermin überschritten. Zugesagter Wareneingang verstrichen, kein Wareneingang gebucht → Alarm an den Einkäufer mit der offenen Menge. | Erkennt Lieferverzug, bevor die Linie steht, nicht danach. |
| 4 | Bestand unter Minimum. Bestand fällt unter den Sicherheitsbestand → Disposition informieren, optional einen Bestellanforderungsentwurf anlegen. | Macht aus der Fehlmenge ein Nachbestellsignal im Voraus. |
| 5 | Rechnung gesperrt. Eingangsrechnung geht in den Sperrstatus → an den Verantwortlichen mit dem Sperrgrund weiterleiten. | Sichert Skonto und die Beziehung zum Lieferanten. |
| 6 | Anforderung ohne Freigabe. Bestellanforderung bleibt über eine Frist hinaus ungenehmigt → an den Vorgesetzten des Freigebers eskalieren. | Beseitigt den Engpass, an dem der Einkauf unbemerkt stockt. |
| 7 | Abweichung Wareneingangs- zu Bestellmenge. Gelieferte Menge weicht über die Toleranz von der bestellten ab → für den Einkäufer markieren. | Zeigt Unter- und Überlieferungen vor der Rechnungsprüfung. |
| 8 | Alterung WE/RE-Verrechnungskonto (GR/IR). Position aus Wareneingang und Rechnungseingang länger als X Tage offen → Bericht an Finanzen und Einkäufer. | Räumt den Abstimmungsstau ab, der sich zum Periodenende verbirgt. |
| 9 | Gesperrter oder auslaufender Artikel auf offenen Bestellungen. Ein Artikel wird gesperrt oder als auslaufend gekennzeichnet, während Bestellungen offen sind → Verantwortlichen informieren. | Verhindert Bestellungen auf Artikel, die Sie nicht länger verwenden können. |
| 10 | Kundenauftragsposition ohne Deckung. Zu einer Position gibt es keinen Nachschub → Disposition mit der Unterdeckung informieren. | Deckt Zusagen auf, die Sie noch nicht halten können. |
| 11 | Trend bei Lieferzeitabweichung. Ein Lieferant unterschreitet oder überschreitet seine angegebene Lieferzeit wiederholt → Trendbericht an den Einkauf. | Liefert Belege für Planungsparameter und Lieferantengespräche. |
| 12 | Kreditlimit überschritten. Neuer Kundenauftrag treibt einen Kunden über sein Kreditlimit → sperren und Kreditkontrolle informieren. | Verhindert Lieferungen in ein nicht einbringbares Risiko. |
Die Szenarien werden gemeinsam als SCM Automation Pack geliefert. Welche davon, mit welchen Schwellen und Empfängern, legen wir im Scoping fest: Ihr Prozess, Ihre Grenzen.
4.Zwei Szenarien im Detail
Unbestätigte Bestellungen (1). Eine Bestellung, die der Lieferant nie bestätigt hat, bearbeitet er womöglich gar nicht, und Sie merken es erst, wenn die Ware ausbleibt. Eine Eskalation, die nach einer festgelegten Zahl von Tagen den Lieferanten anschreibt und den Einkäufer benachrichtigt, schließt diese Lücke. Den vollständigen Fall beschreibt der Beitrag Unbestätigte Bestellungen in IFS erkennen und eskalieren.
Lieferantenpreis über Schwelle (2). Preise steigen Bestellung für Bestellung, jede Erhöhung klein genug, um ungelesen durchzugehen. Eine Regel, die jeden eingehenden Preis anhält, der um einen festgelegten Prozentsatz über dem Rahmenvertrag liegt, und ihn an den Einkäufer leitet, erzwingt eine Entscheidung statt eines Standardwerts. Wo der vereinbarte Preis gelesen wird und wie die Toleranz gesetzt wird, steht in Lieferantenpreisänderung in IFS Cloud früh erkennen.
5.Übersteht die Automatisierung das nächste Upgrade?
Ja, denn keines der Szenarien berührt den Standardcode. Jedes ist mit Standard-Custom-Events, Workflows und PL/SQL im IFS Extensibility Framework gebaut. Das ist der Kern des Clean-Core-Ansatzes: Sie erhalten die Automatisierung ohne den Aufwand, den Anpassungen bei jedem R1/R2-Release verursachen und der jedes Upgrade zu einem Nachbesserungsprojekt macht. Wer im Framework bleibt, bei dem findet das nächste Release nichts, was es zerbrechen könnte.
Technisches 30-Minuten-Gespräch buchen SCM Automation Pack ansehen
6.Fragen und Antworten
Brauche ich alle zwölf Automatisierungen?
Nein. Das SCM Automation Pack ist eine Auswahl, die im Scoping festgelegt wird, kein festes Paket aus zwölf Szenarien. Sie können mit zwei oder drei beginnen, die zu Ihrem größten Schmerzpunkt passen, etwa unbestätigte Bestellungen, Preisänderungen und gesperrte Rechnungen, und später weitere hinzunehmen.
Überschwemmen automatische Mails meine Lieferanten?
Nein. Jedes Szenario hat eine Frequenzbegrenzung, sodass eine hängende Bestellung nicht Tag für Tag erneut eine Mail auslöst, und einen Probelauf, der protokolliert, was verschickt worden wäre, bevor irgendetwas einen Lieferanten erreicht. Die Schwellen stimmen Sie in einer verpflichtenden Testwoche vor dem Go-live ab.
Wie lange dauert es bis zum Go-live des SCM Automation Pack?
Die Dateien sind schnell importiert. Der begleitete Go-live ist ein einzelner Tag, an dem Schwellen und Empfänger auf Ihren Prozess eingestellt werden, danach folgt eine Testwoche im Probelauf, bevor in Produktion etwas auslöst. Sie sind damit in Tagen live, nicht in Monaten.
7.Über den Autor
Ich bin Dariusz Myśliwiec und habe 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, Umsetzung 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.
Überlassen Sie das Beobachten dem System
Sagen Sie mir, wo Ihre Einkäufer heute Zeit verlieren. In einem technischen 30-Minuten-Gespräch zeige ich Ihnen, welches der zwölf Szenarien sich zuerst bezahlt macht, zu einem Festpreis und mit einer Probewoche, bevor etwas live geht.
