Select your language
Independent IFS Cloud practice · Supply Chain
Key takeaways
A report tells you twelve purchase orders are unconfirmed. A decision tells you which three need a phone call today. Most supply chain reporting confuses the two. It delivers volume — forty pages, eighty line items, a dashboard with six charts — and the recipient scans it, notes that nothing is obviously on fire, and moves on. The value was never in the forty pages. It was in the three lines that needed action. But those three lines were buried among thirty-seven that did not, and the person who could have acted on them never saw them at all. Good exception handling does not report. It routes. It puts the right three lines in front of the right person at the right time, and it does not ask them to hunt. This article looks at why reporting defaults to volume, what interpreting a report actually costs, and how to route exceptions in IFS Cloud instead of reporting them.
Reports are easy to build comprehensively and hard to build selectively. Comprehensiveness is a query: pull every open order, every line, every field. Selectivity requires someone to decide, in advance, which combination of conditions actually matters — and that decision feels like a risk, because leaving something out looks like a mistake later, while leaving everything in never does. So the safe choice, repeated across every dashboard and every export, is to include everything and let the human sort it out.
The human, of course, is usually the same person the report was meant to save time for. They open it between two other tasks, scroll for a pattern, and either catch the three lines that matter through sheer familiarity with the data, or miss them because today was a busy day. The report did its job — it reported. Nobody decided anything, because nobody was asked a specific question.
Handing someone a report instead of a decision does not save work. It moves the work, unpaid and unscheduled, onto whoever opens the report next.
A report that requires interpretation is a task you have given to someone who did not ask for it.
The test is simple: does the output name a person and a next action, or does it name a data set? A Quick Report that lists every open purchase order is a data set — useful, but still a report. A rule that filters that same data set to the handful of orders past a defined threshold, and sends only those to the buyer responsible, is a decision arriving pre-qualified. The mechanics of both are covered in Quick Reports, Custom Fields and Custom Events compared, and the trigger-and-action pattern behind routing specifically is the backbone of the SCM automations for IFS Cloud.
Most instances already have the report. What is usually missing is the second step: a Custom Event that reads the same underlying data, applies the threshold that defines “matters today”, and sends the result to one named recipient instead of publishing it for everyone to interpret.
The two are built from the same data. The difference is entirely in what happens between the data and the person who has to act on it.
| Reporting | Routing | |
|---|---|---|
| Output | Every row that matches the query | Only the rows past the threshold |
| Recipient | A distribution list | The named person who can act |
| Interpretation needed | Yes, every time it is opened | None — the filter already did it |
| Timing | Fixed schedule, regardless of urgency | As soon as the threshold is crossed |
| Fails when | The reader is busy or fatigued | Never sleeps |
Keeping the report is often still worth it — it is the audit trail and the occasional deep dive. Routing does not replace it; it removes the requirement that a human read the whole thing to find the part that matters.
Start from a report you already trust, not from a blank page.
The routing layer is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — so it sits alongside your existing reports without modifying them or the core, and survives the next upgrade untouched.
A report lists everything that matches a query and leaves interpretation to whoever reads it. Routing applies the interpretation in advance — a threshold, a filter, a named recipient — so what arrives is already a decision, not a data set to search through.
No. Reports remain valuable as an audit trail and for the occasional deep dive. The change is to stop relying on a report as the primary mechanism for surfacing something urgent, and to route the urgent cases separately.
Watch what an experienced person actually flags from the full report over a few cycles, then turn that pattern into an explicit threshold. The dry-run period exists precisely to test that the filter matches what a human would have chosen.
Yes. Routing is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, sitting alongside existing reports rather than modifying the core — nothing here is at risk from the next R1/R2 release.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
Pick the report your team dreads opening and I will show you, on a dry-run, what routing it would actually send — and to whom. On a 30-minute call we will map the first threshold together — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Procurement
Key takeaways
She knows every supplier by name. She can tell you which orders need chasing without opening IFS. She has done this for eight years, and she is the reason nothing falls through the cracks on her desk. She is also the reason everything could. If she won a competitor’s offer tomorrow, her replacement would inherit a supplier list and a login — not the eight years of pattern recognition that made her effective. This is not a story about one buyer being irreplaceable. It is a property of any role where expertise lives in a person instead of a process: the organisation only feels safe because nobody has priced what leaves with her. This article looks at why that concentration builds up unnoticed, what it costs the day it is tested, and how to move the judgment — not just the task — into something IFS Cloud can carry.
Nobody sits down and decides to make the procurement function dependent on a single buyer. It happens one competent decision at a time. A supplier misses a delivery once, she notices the pattern before it repeats, and the organisation quietly starts trusting her judgment over the system’s default rules. Three years later she is not running a documented process with occasional exceptions — she is the process, and the documented version in the training folder describes a simpler world that stopped being true a long time ago.
The reason nobody intervenes is the reason it is dangerous: she is good at her job. A struggling buyer gets coached, escalated, and eventually supported by a second pair of eyes. A buyer who never drops a ball gets left alone, because there is nothing visibly wrong to fix. The gap between what she knows and what the organisation has captured about what she knows grows every year she keeps performing — and it is invisible for exactly as long as she stays.
The cost does not show up while she is at her desk. It shows up the day she is not — and by then it is too late to build the thing that would have prevented it.
The measure of a healthy procurement function is not how well it runs when the best buyer is in the room. It is how well it runs on the Tuesday she is not.
The concentration itself does not show up as a red flag anywhere in IFS Cloud — it is the absence of something, not the presence of an error. What you can see are its shadows: a small number of buyer codes attached to a disproportionate share of purchase orders that were escalated, chased or rescued outside the standard workflow; suppliers whose confirmation delays never trigger the same generic threshold rule twice, because the buyer intervenes before it fires; and a training folder or SOP that has not been updated since a point release everyone has forgotten the number of.
None of that is visible from a summary dashboard. It becomes visible only when someone asks a specific question: for this buyer’s supplier portfolio, what percentage of exceptions were caught by a system rule versus caught by her noticing first? If the honest answer is “mostly her,” the concentration is already real, whether or not anyone has named it yet.
The goal is not to replace her judgment — it is to stop the organisation’s exposure being entirely proportional to her presence.
| Tacit judgment | Documented system rule | |
|---|---|---|
| Where it lives | One person’s memory | IFS Cloud, applied consistently |
| Survives absence | No | Yes |
| Transfers to a new hire | Only through years of exposure | Immediately, on day one |
| Auditable | No trace of why a call was made | Logged rule, logged trigger |
| Improves with review | Only if she reflects on it herself | Tunable by anyone with visibility |
None of this argues she should stop exercising judgment on the cases that genuinely need it. It argues that the routine ninety percent of what she does by pattern — which supplier is drifting, which order needs a call today — belongs in a rule the system enforces, freeing her judgment for the harder ten percent only she can actually add value to.
This only works if it is framed — honestly — as protecting the function, not auditing the person. Done the wrong way, it reads as a performance review. Done the right way, it reads as building her a backup.
Built this way — standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — the rules stay update-safe and avoid the upgrade tax, the same discipline behind a supplier behaviour-change signal or an unconfirmed-PO escalation. Clear ownership of who can see and change each rule follows the same logic as segregation of duties in IFS Cloud.
Documentation captures what the process is supposed to be. It rarely captures the exceptions an experienced buyer makes by instinct, and it does not act on its own. The goal here is a rule IFS Cloud enforces automatically, not a page someone has to remember to read.
A departure is one moment you can at least plan a handover around. Concentration risk exists every single day she is simply out sick, on leave, or in back-to-back meetings — long before anyone has thought about a resignation.
Only if it is introduced as one. Framed and sequenced correctly — interview first, give her the resulting alerts first, extend coverage only once she trusts the rules — it reads as removing her busywork, not her judgment.
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so there is nothing here for the next R1/R2 release to quietly break.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
If your best buyer’s judgment is currently your only safety net, a dry-run month will show you exactly which of her instincts can become a system rule today. Fixed price, nothing goes live until she has seen it work.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A delivery is due today. The buyer means to check it. Then a supplier calls about a different order and the call runs long. A quality issue on the shop floor needs someone right now. The check moves to tomorrow. Tomorrow, the same thing happens again: another fire, another reason, another day added to the queue. By Friday the delivery date was four days ago and nobody has looked at it. Nothing here counts as negligence. It is prioritisation working exactly as designed — the urgent has a person asking for it, and the important has only a date sitting quietly in IFS. The cost of this pattern is real, but it stays invisible, because it is distributed one day at a time across fifty orders and twelve months. This article covers why deferral happens, what it actually costs, how to see it in IFS Cloud, and how to fix it without asking anyone to be more disciplined than they already are.
Deferral is not a character flaw. It is what happens when every open exception competes for the same finite attention, and the loudest one always wins. A supplier on the phone, a machine down, an angry email from a customer — each of these has a person attached to it, asking in real time. A purchase order sitting three days past its confirmation date has no one asking. It waits patiently in a queue, and patience is exactly what lets it slip.
The system reinforces the pattern. Most screens show the exception as a line in a list, not as an event demanding a response. There is no ring, no red banner, no name attached to the delay — just a date that quietly falls further behind the current one. Buyers who are conscientious about the loud problems are, by definition, the same people too busy to go looking for the quiet ones. The check does not fail because someone is careless. It fails because nothing in the workflow makes it compete on equal terms with whatever is happening right now.
The arithmetic of deferral is deceptively small at the level of one order. A day slips, someone catches it a day late, the shipment still arrives, mostly on time. Multiply that by fifty open orders running at once and twelve months of the same daily trade-off, and the accumulated days of inaction stop looking small:
The cost never shows up as a line item called “deferred check.” It shows up as a late shipment, an expedite fee, or a customer call — three steps removed from the day someone meant to look and did not.
IFS Cloud already has everything needed to see deferral, because every open exception carries an age. A purchase order past its confirmation date, a requisition waiting on approval, a delivery running late — each one has a created date and a current date, and the difference between them is the story. What is missing is not data; it is a place that turns “days since flagged” into something someone has to act on before it grows another day older.
Run the numbers today and the picture is usually more sobering than anyone expects — not the count of open exceptions, but the average age of the ones still open, and the tail of orders that have been sitting for a week or more. That tail is where the real cost lives, and it stays invisible in any dashboard that only reports the current snapshot rather than how long each item has been waiting.
The fix is not a reminder to try harder tomorrow. It is closing the gap between how urgent things get attention and how important things get attention, using the same trigger-and-action pattern behind other Custom Events in IFS Cloud: watch the age of the exception, and the moment it crosses a threshold, turn it from a quiet line into an alert with a name attached.
| Manual recall | Automated escalation | |
|---|---|---|
| Runs when | Whenever something louder isn’t happening | On a schedule, every day |
| Coverage | Whatever is left after today’s fires | Every open exception, every buyer |
| Visibility | A date sitting in a list | A named alert with an age and an owner |
| Owner | Whoever happens to notice | Assigned by rule, every time |
| Fails when | Exactly the busy days it matters most | Never — it does not compete for attention, it demands it |
This does not remove judgement from the buyer. It removes the requirement that the buyer remember to apply that judgement on a day already full of louder problems.
Roll this out the same way you would any exception rule: prove it before anyone depends on it.
Because the whole thing runs on standard Custom Events and Workflows inside the IFS Extensibility Framework, there is no core modification for the next release to break. It is update-safe, and it avoids the upgrade tax entirely.
No. It is what happens when every exception competes for the same attention and the loudest one wins by design. The fix is structural, not motivational: give the important item the same visibility the urgent one already has.
Training assumes the constraint is knowledge or willpower. The constraint is usually time and competing signals. An escalation rule changes what competes for attention instead of asking buyers to fight the same losing battle with more resolve.
Not if it is thresholded and capped. The rule fires once an exception crosses an agreed age, not on every minor delay, and a frequency cap stops the same order escalating repeatedly. Dry-run first shows you the real volume before anything goes live.
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so the next R1/R2 release has nothing here to break.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
If deferred checks are quietly costing you days across dozens of open orders, a dry-run week will show you the real scale for the first time. On a 30-minute call I’ll map the escalation to your exception types — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Supply Chain
Key takeaways
On-time delivery: 94 percent. The dashboard is green. The monthly review notes the improvement and moves on. What the number does not show: the six percent that were late included the three largest orders of the month. Two of them stopped a production line. One cost a customer. None of that is visible in a single aggregate figure, because 94 percent is an average, and averages are built to erase exactly the kind of detail that would have made someone act sooner. Aggregate metrics are not wrong. They are honest about the wrong thing — they tell you the average, and in supply chain the average is rarely what does the damage. This article covers why on-time delivery in particular hides its worst cases, what that costs, how to surface the outliers inside IFS Cloud, and how to build a rule that treats a late critical order differently from a late routine one, without replacing the KPI you already report.
On-time delivery is calculated the same way almost everywhere: on-time lines divided by total lines, expressed as a percentage. Every line counts exactly once, regardless of what it was carrying. A pallet of low-value consumables that arrived a day late counts the same as the single component that stopped a production line for a week. The formula has no concept of consequence, only of timing.
That is not a flaw in the formula — it is a summary statistic doing exactly what summary statistics do. The problem starts when the number is treated as the finding rather than the starting point. A team that watches the percentage month over month can genuinely improve the average while the handful of orders that actually cost money stay exactly as late as they always were, simply outnumbered by everything that shipped on time.
The gap between the metric and the damage is where the real cost hides. It shows up downstream, in places the on-time percentage never looks:
Ninety-four percent on-time is not a result. It is an invitation to look at the six percent and ask which of them actually hurt.
IFS Cloud already carries what is needed to separate the outliers from the noise: order value, customer, part criticality, and promised versus actual delivery date all live on the same records the on-time percentage is calculated from. The aggregate simply never asks those fields a question.
Filter late lines by order value above a threshold, by a criticality flag, or by top-tier customer, and the six percent stops being an undifferentiated tail — it becomes a short, specific list of the deliveries that were actually expensive to miss. That list is usually a fraction of the size of the full late report, and far more useful.
The fix does not replace the on-time percentage — leadership will keep asking for it. It adds a second, narrower view built on the same automation pattern behind other SCM alerts in IFS Cloud, watching for the late orders that were never supposed to be treated the same as the rest.
| Aggregate KPI | Outlier-weighted monitoring | |
|---|---|---|
| What it measures | Percentage of lines delivered on time | Which late orders actually mattered |
| Weighting | Every line counts the same | Weighted by value, criticality, customer tier |
| What it hides | The orders that stopped production | Nothing — each is flagged on its own |
| Reviewed | Once a month, as an average | The moment a threshold is crossed |
| Fails when | The average stays green while a handful of misses cost the most | Rarely — each miss is visible individually |
None of this argues for abandoning the percentage. It argues for not stopping there.
Building the second view is a modest project, not a re-platforming exercise.
Built inside the IFS Extensibility Framework with standard Custom Events and Workflows, the flagging rule sits alongside the core reporting without touching it — update-safe, with nothing here for the next release to break.
Because the percentage treats every late order as equally bad. A late shipment of low-value stock and a late shipment that stops production both count as one miss out of many, so the average can look healthy while the handful of misses that actually cost money go unnoticed.
Most teams start with what they already know: a value threshold, a small list of top-tier customers, or a criticality flag already used in planning. The dry-run period usually confirms or corrects the first guess quickly.
No. It sits alongside it. Leadership keeps the trend line; the operational team gets a short list of the misses that actually deserve a conversation.
Yes. It uses standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no modification to core on-time delivery reporting.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
If you suspect your green on-time delivery number is hiding a handful of expensive misses, a dry-run week will show you exactly which orders they are. On a 30-minute call I’ll map the outlier rule to your critical orders — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A buyer spends two hours a day checking order states. Two hours, five days a week, forty-eight working weeks a year. That is four hundred and eighty hours -close to twelve full working weeks - spent on something a system could do in seconds. Not because IFS cannot do it. Because nobody configured it to. This is the hidden cost of manual monitoring, and it is easy to miss precisely because it never looks like a cost. It looks like diligence. The buyer feels productive, the exceptions get caught, the organisation sees results, and nobody asks whether the same result could have been achieved without quietly consuming a quarter of a full-time employee’s year. The most expensive monitoring is the kind that works well enough that no one ever questions what it costs to run.
Checking order states by hand feels responsible. It is visible, it produces catches, and it never triggers the awkward conversation an automation project does — budget, scope, who owns it. A buyer who scans the screen every morning is doing exactly what a good buyer is supposed to do, and that is precisely why nobody questions whether it should be a screen-scan at all.
It survives because the cost is invisible on the org chart. Two hours a day never appears on an invoice, a project plan, or a monthly report; it simply disappears into “buyer work,” alongside negotiation, expediting and everything else the role covers. Nobody totals the hours, so nobody ever sees the number large enough to act on.
The bill is not one number, it is several, and none of them appear next to “monitoring” on any report:
The most expensive monitoring is the kind that works. It works well enough that nobody ever asks what it costs to keep running.
The starting point is not a system query, it is a short conversation, timed honestly: ask each buyer what they check every day, how long it takes, and why they check it manually instead of relying on a report. Most of what surfaces is repetitive — the same filter, the same sort, the same screen, scanned for the same handful of conditions — which is exactly the pattern a Custom Event is built to replace.
Once the checks are listed, IFS itself can usually already answer the underlying question — unconfirmed orders, orders below a coverage threshold, deliveries running late — through the same data the buyer is reading by eye. The audit does not need new instrumentation, only the discipline to write down what “I just check it every morning” is actually costing, in hours, every week.
The comparison is not about accuracy — a careful buyer is usually accurate. It is about where the hours go and whether coverage depends on a person’s calendar.
| Manual | Automated | |
|---|---|---|
| Time cost | ~2 hours/day per buyer | Seconds, on schedule |
| Consistency | Depends on the day | Same rule, every day |
| Scales with orders | No — more volume means more hours | Yes, at no extra hours |
| Visible as a cost | No — buried in “buyer work” | Yes — a rule with a scope and a log |
| Buyer’s time goes to | Scanning a screen | The exceptions that actually need judgement |
Automating the check does not remove the buyer’s job. It removes the part of the job that was never really a judgement call — scanning for a state that a rule can recognise faster and more consistently — and leaves the buyer with the exceptions that genuinely need a person’s experience.
Start with the check that costs the most hours, not the one that feels most urgent.
Because each rule is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — it is update-safe and stays out of the core, which is also why teams that automate this way tend to see up to 60% less regression testing at the next upgrade: there is simply less bespoke code sitting in the path of the release.
Ask each buyer or planner what they check daily by habit rather than by system alert, and how many minutes each check takes. Multiply by working days and headcount. Most teams are surprised the number reaches hundreds of hours a year once it is added up honestly.
No. It removes the repetitive scanning, not the judgement. The freed hours typically go straight back into negotiation, supplier development and the exceptions that genuinely need a person — work the role was always supposed to prioritise.
Whichever consumes the most hours across the most people, not whichever feels most dramatic. A five-minute daily check done by twenty buyers usually costs more, in aggregate, than one buyer’s occasional deep investigation.
Yes. Each monitoring rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification. Nothing here is the kind of customisation that the next R1/R2 release quietly breaks.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
If your buyers are quietly spending hours a week scanning screens IFS could watch for them, a short time-audit will show you exactly how many. On a 30-minute call I’ll map the highest-cost checks to automation rules — fixed price, dry-run before anything changes.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A delivery date passes on the 3rd. The buyer is tied up today, the material isn't critical, and we've heard this from the operations team: “we will catch it at month-end.” Month-end arrives. The exception report shows twelve late deliveries. Three are now critical. One has already stopped a production line. The buyer spends two days firefighting instead of the one hour it would have taken to check on the 4th. This is not a story about a lazy review process — the monthly report did exactly what it was built to do. It is a story about latency: the distance between a record changing state in IFS Cloud and a human finding out about it. This article covers why that distance compounds, how to see the real cost of it, and how to shrink it without adding more meetings or more reports.
Monthly review is inherited from an era of batch reporting, when a report was expensive to run and the finance calendar was the only rhythm a business had. It survives because it is a real, working cadence — it does catch everything eventually — and because nobody has had to prove, with a number, that the delay itself has a cost.
The judgement that a given exception is “not critical today” is made in the moment, with no evidence about how it will look in three weeks. Nobody owns the daily exception list, because it is treated as someone else’s report rather than a live risk. So it waits, along with everything else that seemed fine on the day it was postponed.
The cost of catching an exception on day one is not the same as catching it on day twenty-eight. Every day it sits unaddressed, the cost compounds along several dimensions at once.
A day-one fix costs an email. A month-end fix costs two days, a stopped line, and a harder conversation with the customer.
Every exception that shows up on a month-end report already existed as a state change in IFS Cloud on the day it happened — a delivery date passed, an order stayed unconfirmed, a stock level fell below minimum. The report does not create that information; it simply waits a month to surface it. The same state change can trigger a Custom Event the day it occurs, which means the report and the alert are reading identical data, just at very different latencies.
The practical question is not whether to build same-day detection for everything — that would recreate the alert-storm problem in a different shape. It is choosing the two or three exception types where the cost curve is steepest, and closing the gap there first, following the same trigger-and-action pattern used across the SCM automations for IFS Cloud.
Both approaches surface the same underlying facts. They differ in exactly one dimension — and that dimension is where the cost lives.
| Periodic (month-end) review | Real-time exception detection | |
|---|---|---|
| Detection lag | Up to one full month | Same day the state changes |
| Cost per exception | Compounded by delay | Closer to the base cost |
| Who is affected | Whoever inherits the backlog | The person who can still act on it |
| Scalability | Gets harder as volume grows | Runs the same regardless of volume |
| Trust in the number | Reactive, arrives as a surprise | Expected, arrives while fixable |
Keep the month-end report for what it is genuinely good at: a trend view and a sanity check. Do not ask it to be the thing that catches a problem while it is still cheap to fix — that job belongs to the exception the moment it happens, exactly as covered for one specific case in unconfirmed purchase orders in IFS.
Shrinking detection latency is not a big-bang project. It is picking the highest -cost exceptions first and proving the model before it spreads.
Because each rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, none of it is core modification — it stays update-safe and avoids the upgrade tax while quietly making the month-end report shorter every cycle.
Only if it is built for every exception at once. Starting with the two or three highest-cost types, and tuning thresholds during a dry-run period, keeps volume low enough that each alert still gets read and acted on.
No. The month-end report stays useful as a trend view and a sanity check on totals. Real-time detection takes over the job of catching individual exceptions while they are still cheap to fix — a job the monthly cadence was never fast enough to do.
Look at last month’s exception report and ask which items were mild on day one and severe by month-end. Those with the steepest cost curve over time give you the best return for closing the detection gap first.
Yes. Each rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so nothing here is at risk from the next R1/R2 release.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
If your team is still catching exceptions once a month, the cost of that delay is already visible in last month’s firefighting hours. On a 30-minute call I’ll help you rank your exceptions and map the two worth fixing first — fixed price, dry-run before anything goes live.
Independent IFS Cloud practice · Manufacturing
Key takeaways
Every manufacturing site has one. A spreadsheet that is not on the network. It lives on a desktop. It has a dozen tabs, and one person understands the columns that actually drive the numbers everyone downstream relies on. It tracks the things IFS does not track, or tracks in a way that no longer matches how the floor works. It bridges the gap between what was configured at go-live and what the operation turned into over the following three years. The spreadsheet works perfectly — until the author is on leave, or the laptop dies, or someone sorts column F without selecting the whole range. A spreadsheet that runs a factory is not a tool. It is a liability wearing a familiar face, and the familiarity is exactly what makes nobody question it. This article covers why it exists, what it actually risks, and how to bring its logic into IFS Cloud without a disruptive rebuild.
At go-live, IFS was configured to match the operation as it existed on that date. The operation did not stand still. New product lines arrived, a quality step got added, a customer started demanding a report nobody had asked for before — and every one of those changes needed either a proper configuration change or a workaround. A configuration change needs budget, approval and a project slot. A workaround needs Excel and an afternoon.
A power user who understands both the process and a spreadsheet formula solves the gap locally, inside their own authority, without asking anyone. It works, so it stays. Three years later nobody remembers it was meant to be temporary, and the plant now depends on a file that IT does not know exists, finance cannot audit, and only one person can actually maintain.
The risk rarely shows up as a single dramatic failure. It shows up as an accumulation of small exposures that only become visible the day one of them triggers.
The spreadsheet does not fail when it breaks. It fails long before that, the moment everyone stops noticing it is the thing actually running the shop floor.
You will not find a shadow spreadsheet by querying IFS Cloud — by definition it lives outside it. What you can do is instrument the boundary: use Quick Reports and Custom Fields to see what people are actually pulling out of IFS and what fields get manually annotated after export, because that is where a gap between the system and the shop floor tends to surface first. A short, direct conversation with each cell or line supervisor — “what do you keep track of that IFS does not show you?” — usually surfaces the rest within a day.
The comparison covered in Quick Reports, Custom Fields and Custom Events is the right lens here: each shadow spreadsheet column is really an unmet requirement for one of those three tools, and knowing which one it maps to tells you how hard the fix actually is.
The comparison is not spreadsheet versus no spreadsheet. It is an uncontrolled file versus the same logic captured inside a structure IFS Cloud actually manages.
| Desktop spreadsheet | Systematic extension | |
|---|---|---|
| Backup | Whatever the laptop policy is | Standard system backup |
| Access control | Whoever has the file | Role-based, as configured |
| Audit trail | None | Logged change history |
| Single point of failure | One person, one device | None — part of the platform |
| Alignment with source data | Manually re-entered, drifts | Reads live IFS data |
None of this requires ripping the spreadsheet out overnight. It requires identifying which of its columns actually matter and giving each one a proper, supported home — a Custom Field where a value needs to live on the record, a Quick Report where it needs to be seen, a Custom Event where it needs to trigger something. That is the same Clean Core discipline covered in Clean Core in IFS Cloud SCM.
Treat the spreadsheet as a specification, not an enemy. Its author has already solved the problem once; the job is to give that solution a supported home.
Because the replacement is built with standard Custom Fields, Quick Reports and Custom Events inside the IFS Extensibility Framework, it is update-safe — no core modification for the next release to break, and no more single laptop standing between the floor and a working process.
Frame it as protecting their work, not replacing it. Most owners built the spreadsheet because nobody gave them a proper tool, and they are often the most relieved once the logic is safely captured somewhere it cannot be lost with one hardware failure.
It depends on how much of it turns out to be logic versus notes. A spreadsheet with three or four columns that actually drive decisions can often move to Custom Fields and a Quick Report within a couple of weeks, parallel run included.
No. A spreadsheet used for genuine one-off analysis is not the risk. The risk is a spreadsheet that has quietly become a permanent, single-person system of record for something IFS should be tracking and backing up.
Yes. The migration uses standard Custom Fields, Quick Reports and Custom Events inside the IFS Extensibility Framework — no core modification, so nothing here is broken by the next R1/R2 release.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
If you suspect a spreadsheet is quietly load-bearing somewhere in your operation, a short discovery pass will tell you exactly which columns matter. On a 30-minute call I’ll map a safe path to bring it inside IFS Cloud — fixed price, parallel run before anything is retired.
Independent IFS Cloud practice · Supply Chain
Key takeaways
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.
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.
The cost is not the late order itself — that is visible and gets fixed. The cost is everything that happens because the warning arrived only when the pattern had already broken down completely.
The supplier almost always knows before you do. The only question is how many orders pass before you find out too.
The confirmation date, the order date and the supplier are already recorded on every purchase order line in IFS Cloud — 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 — just 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.
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.
Behavioural detection is more sensitive than a flat threshold, so it earns a more careful rollout.
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 — it stays update-safe and avoids the upgrade tax. The same discipline protects related rules such as supplier price-change alerts.
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 — the two rules complement each other rather than replace one another.
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.
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.
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so there is nothing here for the next R1/R2 release to quietly break.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (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.
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 — fixed price, dry-run before anything goes live.
Calculate your return on investment