Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Supply Chain
Supplier behaviour change in IFS Cloud: the early warning nobody is listening for
Key takeaways
- A supplier behaviour change (a reliable supplier suddenly confirming late, or not at all) is one of the earliest signals a supply chain can give you, and IFS Cloud does not flag it by default.
- A static “unconfirmed after X days” rule catches a stuck order. It does not catch a supplier whose pattern just changed, and pattern is what predicts trouble before the order itself is late.
- By the time the change is obvious to a human, several orders are already affected and the supplier’s problem is no longer news to anyone but you.
- A baseline-and-deviation check, built the same way as an unconfirmed-PO escalation, turns a buyer’s memory into a system rule and stays update-safe.
For two years, a supplier confirms every order within two days. Reliable enough that nobody thinks about it until, one week, an order sits unconfirmed for seven days. Then the next one does too. A buyer who has worked with this supplier for years notices immediately: this is not how they behave. But nothing in the system agrees. The order is within the age most escalation rules would allow, so no threshold fires. The only thing that caught the change was one person’s memory of what normal looks like for this specific supplier, and memory does not scale, does not survive a handover, and is not written down anywhere IFS can act on. By the time the pattern is undeniable, several orders are late and the supplier’s trouble is no longer a secret to anyone but the business relying on them. This article covers why pattern changes go unnoticed, what they cost, and how to turn a buyer’s gut feeling into a rule IFS Cloud can watch for you.
1.Why do supplier behaviour changes go unnoticed?
Confirmation-lag rules in most IFS Cloud setups (where they exist at all) use one threshold for every supplier: flag anything unconfirmed after, say, five days. That catches the stuck order. It says nothing about a supplier whose average lag just doubled while staying inside the threshold. A supplier who normally confirms in two days and now takes four is still within a five-day rule, and still telling you something is wrong.
The knowledge that would catch it lives in one person’s head. An experienced buyer holds a rough baseline for every supplier they manage: who is fast, who is slow, who never misses. That baseline evaporates the moment the buyer goes on leave, changes role, or the supplier gets reassigned. Newer buyers have no baseline to compare against at all, so a slow week looks the same as any other week. As supplier counts grow, no one can hold a hundred individual rhythms in their head at once, and the system that could was never asked to.
2.What does a missed behaviour change actually cost?
The cost is not the late order itself, which is visible and gets fixed. The cost is everything that happens because the warning arrived only when the pattern had already broken down completely.
- Lost lead time. Every day between the first anomalous order and the moment someone acts is a day the supplier does not have to recover, and you do not have to find an alternative.
- Reactive expediting. Discovering a supplier’s trouble through a missed delivery means paying premium freight to fix a problem a pattern-based signal would have flagged weeks earlier.
- Defensive buffer stock. Without early warning, the instinct is to raise safety stock across the board, tying up working capital to compensate for information you should have had for free.
- Lost negotiating position. A conversation that starts with “we noticed your confirmations have slowed. Is everything all right?” is a very different conversation from one that starts with “why is our line down?”
The supplier almost always knows before you do. The only question is how many orders pass before you find out too.
3.How do you detect it in IFS Cloud?
The confirmation date, the order date and the supplier are already recorded on every purchase order line in IFS Cloud, so the data needed to build a baseline is not missing, it is just never compared to itself. A rolling baseline per supplier, built from a trailing window of confirmed orders (ninety days is a reasonable start), gives you a typical confirmation lag for that specific supplier rather than one number for the whole supplier base.
Detection then becomes a comparison, not a threshold: does the new order’s confirmation lag sit meaningfully outside that supplier’s own history? A supplier who is normally two days and is now six has moved further from their own baseline than a supplier who is normally four days and is now six, even though the raw number is identical. That distinction is invisible to a flat day-count rule, and it is exactly the distinction an experienced buyer makes instinctively, but without documenting it, and without scaling past their own memory. It is a different signal from the flat threshold covered in unconfirmed purchase orders in IFS.
4.Static threshold versus behavioural baseline
The two approaches are not competitors: a flat threshold and a baseline check catch different failures, and most mature setups run both.
| Static threshold | Behavioural baseline | |
|---|---|---|
| What it catches | Orders stuck past a fixed limit | Suppliers whose normal pattern has shifted |
| Sensitivity to supplier profile | None: one rule for everyone | Personalised: compares each supplier to itself |
| Earliest warning | After the threshold is breached | Often before any single order looks late |
| False positives | Low, but blind to slow drift | Depends on window length and tuning |
| Maintenance | Set once | Recalculates itself as history accumulates |
Run the static rule to keep catching orders that simply sit too long. Layer the baseline check on top to catch the supplier who is still technically within every threshold but no longer behaving like themselves.
5.How do you roll it out safely?
Behavioural detection is more sensitive than a flat threshold, so it earns a more careful rollout.
- Choose the baseline window. Ninety days of confirmed orders is a reasonable default; shorten it for suppliers with sparse order volume.
- Run in dry-run. Let the comparison log what it would flag for a month before anyone receives an alert, and check the list against what buyers already suspected.
- Set the deviation threshold. Decide how far outside a supplier’s own baseline counts as meaningful. Start conservative and tighten once you trust the signal.
- Pilot on your top suppliers by spend. These are the relationships where an early warning is worth the most and where buyers can validate the signal fastest.
- Review quarterly. Baselines shift as relationships mature; a threshold that made sense at go-live may be too loose (or too tight) a year later.
Because the whole thing runs on standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, there is no core modification for the next release to break, so it stays update-safe and avoids the upgrade tax. The same discipline protects related rules such as supplier price-change alerts.
6.Frequently asked questions
How is this different from an unconfirmed-PO escalation?
An unconfirmed-PO rule flags any order past a fixed age. A behavioural check compares a supplier’s current pattern to their own history, so it can flag a supplier who is drifting while still inside that fixed age, and the two rules complement each other rather than replace one another.
How much order history do I need before the baseline is reliable?
Ninety days, or roughly ten to fifteen confirmed orders per supplier, is a workable starting point. Lower-volume suppliers need a longer window or a wider tolerance, since a single slow order swings a thin baseline more than it would a busy one.
Will this create false alarms for suppliers who are naturally inconsistent?
Tuned well, no. The deviation threshold is set against each supplier’s own variability, not a flat number, so a supplier who is naturally erratic needs a bigger deviation before it fires. The dry-run month is where you catch and correct that before anyone sees a live alert.
Is this update-safe?
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework with no core modification, so there is nothing here for the next R1/R2 release to quietly break.
7.About the author
Dariusz Myśliwiec: 18 years of hands-on IFS practice (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. You talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Stop finding out from the production line
If a buyer’s memory is currently your only early-warning system, a dry-run month will show you what a baseline check would have caught. On a 30-minute call I’ll map the rule to your top suppliers, at a fixed price and with a dry-run before anything goes live.
