Independent IFS Cloud practice · Supply Chain
What your ERP consultant did not tell you: the process will drift
Key takeaways
- Go-live delivers a documented, trained, mapped process. But the system will drift from it, quietly, starting the week the consultant leaves.
- Drift is not malicious: a mandatory field goes optional because someone complained, a check gets skipped because it slowed things down, a weekly report becomes monthly.
- Process drift in IFS Cloud means the system stays correct while the behaviour around it slowly changes. The gap between designed process and evolved process is where exceptions live.
- Closing the gap needs a periodic drift review, not a bigger manual, backed by the same exception-routing mechanism used across every process on this site.
Your IFS implementation went live. The consultant handed over the documentation. The key users were trained. The processes were mapped, signed off, and filed. What nobody told you at the time is that none of it stays still. A field that was mandatory becomes optional because someone complained. A check that was part of the workflow gets skipped because it slowed things down. A report that was reviewed weekly gets reviewed monthly because the person who ran it changed roles. None of this is malicious. It is how organisations work. Two years after go-live, your IFS instance is not running the process you designed. It is running the process your team evolved, one small local decision at a time. The question is not whether your implementation was good. It was. The question is whether anyone is still watching the gap between the two.
1.Why does every implementation drift?
Drift has no single cause and no single villain. It is a hundred small local decisions, each individually reasonable at the moment it was made. A planner finds a mandatory field slows down a Friday rush and asks IT to relax it “for now”. A supervisor covering for a sick colleague skips a review step because nobody explained why it mattered. A manager who inherited a weekly report has no idea it used to catch something specific, so cutting its frequency in half feels harmless. Each decision, taken alone, looks like a minor efficiency gain.
What none of these people see is the sum. The documentation from go-live still describes the original design; nobody updates it as the small decisions accumulate, because updating documentation is nobody’s job either. Two years later the gap between the written process and the practised one is wide enough to hide real exceptions inside it. Nobody signed off on that gap. It simply arrived.
2.What does process drift actually cost?
The cost is not a single failure. It is the slow widening of the space where a real problem can hide behind a habit that looks normal because everyone got used to it.
- Mandatory becomes optional. A field relaxed to save five minutes once now lets bad data through every day, with nobody remembering why it mattered.
- A check quietly skipped. The review step designed to catch a specific class of error stops running. That class of error stops being caught, and nobody hears about it.
- Cadence stretched thin. A weekly report that becomes monthly means a problem that used to surface in days now sits for weeks before anyone sees it.
- Role changes erase context. The person who understood why a step existed moves on, and their replacement inherits the task without the reason behind it.
The system stays correct. The behaviour around it drifts. Nobody notices, because nothing that drifted was ever labelled as important in the first place.
3.How do you see drift in IFS Cloud?
Drift leaves a trail, because the original design and today’s behaviour are both visible in IFS Cloud. You just have to compare them instead of only reading one. Mandatory-field settings, approval workflow definitions and role permissions describe what was designed. Actual transaction data describes what is practised: the percentage of orders with an optional field left blank, the percentage of approvals that skipped a step that still exists on paper, the interval between runs of a report that used to be weekly.
Run that comparison once and it is interesting. Run it as a scheduled review and it becomes a system of record for the gap itself, which is what the exercise described in the upgrade readiness checklist already assumes you can produce before touching a release. The same evidence underpins a segregation-of-duties review, because role drift is one of the most common forms this pattern takes.
4.Occasional audit versus continuous drift monitoring
Most organisations discover drift the hard way: an audit, an incident, a new hire asking why the process on paper does not match what they were shown. A continuous comparison catches the same gap while it is still small and cheap to close.
| Occasional audit | Continuous monitoring | |
|---|---|---|
| Runs when | Once every few years, if at all | Continuously, against live data |
| Coverage | Whatever the auditor thought to check | Every mandatory field, check and cadence |
| Owner | An external reviewer, briefly | Process owner, by rule |
| Audit trail | A report nobody re-reads | A trend, tracked over time |
| Fails when | The years between audits | Never sleeps |
The value is not in catching one drifted field. It is in seeing the trend early enough that correcting it is a conversation, not a project.
5.How do you close the gap safely?
You are not rebuilding the implementation. You are re-establishing the habit of looking at the gap.
- Pull the original design. Recover the go-live documentation for mandatory fields, approval steps and report cadence. It is the baseline everything else is compared against.
- Run the comparison once. Measure today’s actual data against that baseline. Expect surprises; drift is rarely where anyone expects.
- Rank by exposure, not by age. A recently drifted approval step on a high-value process outranks a decade-old cosmetic change to a low-risk field.
- Fix the highest-exposure gaps first. Re-tighten, re-train, or formally accept the change. Whichever you choose, make it a decision, not a default.
- Schedule the next comparison. Drift is continuous, so the review has to be too; put a date on the calendar before you close this one out.
The comparison itself is built inside the IFS Extensibility Framework, using standard Custom Events, Workflows and PL/SQL, so tracking it does not require touching the core configuration you are trying to protect.
6.Frequently asked questions
What is process drift in IFS Cloud?
It is the gradual gap that opens between the process designed at go-live and the process your team actually practises months or years later: mandatory fields relaxed, checks skipped, reporting cadence stretched, all through small, individually reasonable decisions.
Does drift mean the original implementation was wrong?
No. Drift happens to good implementations as much as mediocre ones, because it is a property of how organisations behave over time, not a defect in the original design. The question worth asking is not whether it was good, but whether anyone is still watching the gap.
How often should we check for drift?
A first comparison against the original go-live baseline is worth doing regardless of age. After that, a scheduled review (commonly ahead of an upgrade or a segregation-of-duties audit) keeps the gap from growing unnoticed between checks.
Is this update-safe?
Yes. The comparison and any resulting alerts are built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework. Nothing touches the core, so nothing here is at risk from the next R1/R2 release.
7.About the author
Dariusz Myśliwiec has spent 25+ years in ERP and supply chain, 17+ of them on IFS (Apps 7.5-10 and IFS Cloud). He is an IFS Certified Associate Consultant and PRINCE2® 7 certified. His practice is based in Krakow and works remotely across Europe and beyond. 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.
Find out how far your process has drifted
Most teams have never compared today’s data against the process they designed at go-live. A short baseline comparison will show you exactly where the gap is widest. On a 30-minute call I’ll walk through what that comparison looks like for your instance. Fixed price, no obligation.
