Grouping sites so they share parts, defaults and process setup is sold as a speed feature. It is really a consistency feature, and the speed is a side effect. When site four inherits the purchasing parameters that sites one to three already run on, you are not just saving a week of configuration. You are removing the possibility that site four quietly does receiving differently, which is what costs you two years later when someone tries to compare performance across the group and finds the numbers are not measuring the same event.

The catch is that a cluster only helps if the template being cloned is one somebody defended. Rolling out a bad standard quickly is worse than rolling it out slowly, because a slow rollout at least gives each site a chance to object. I ask for the template to be signed off by the person who will own the process across all sites, not by the site that happened to go first. That is also where the multi-site purchasing decisions belong: whether demand consolidates centrally, and how stock moves between sites once it has.

Further reading: centralised purchasing in IFS Cloud, distribution orders between sites, and from planning to go-live.

IFS Cloud gives you three tools that cover most of what people used to write code for, and knowing which one to reach for is the whole skill. A Quick Report reads data out: a saved query for a list or an extract, with no logic. A Custom Field stores something the standard data model does not. A Custom Event reacts when a row changes, and can hand off to a Workflow that routes an approval, sends a notification, or calls out to another system.

The failure mode is predictable. Teams discover Custom Events, like them, and attach one to everything. Six months later there is an event layer nobody can explain, firing on saves that were never meant to be significant, and the business has learned to ignore the notifications it produces. The second failure mode is subtler: reaching for a Custom Event when the requirement is actually a scheduled check. An event fires when a row changes. It cannot fire because a row has not changed, which is exactly what an unconfirmed order or an untouched receipt is.

Where the requirement crosses a system boundary, the answer is usually an interface rather than an in-system automation. IFS Cloud's OData projections are the normal integration surface, and keeping the orchestration outside IFS keeps that logic out of your ERP, where it would otherwise become one more thing to retest at every release.

Further reading: Custom Events explained, Quick Reports vs Custom Fields vs Custom Events, IFS Cloud API integration, orchestrating IFS Cloud with n8n. Work that has already been built once sits in the configurations and interfaces sections of the marketplace.

IFS Cloud ships R1 and R2 every year. That cadence is the biggest single change in how you should think about customisation, and it is where legacy habits do the most damage. On Apps 9 or 10 an upgrade was an event you prepared for over months, so carrying technical debt between them felt survivable. On Cloud it arrives twice a year, and anything built outside the Extensibility Framework has to be checked, and often reworked, on that same rhythm.

The boundary is simple to state and easy to cross by accident. Extending the data model with Custom Fields, adding logic through Custom Events and Workflows, adapting screens through configuration: all inside the contract, all carried forward. Touching a core object, or building a report or an interface directly against an internal view rather than a published projection, puts you outside it. Nothing stops you at the time. The bill arrives at the next release, and at every release after that.

I have watched this go wrong in both directions. Companies that refuse all extension end up with a shadow layer of spreadsheets doing the work the system was not allowed to do, which is worse, because at least a customisation is visible. The honest position is that some extension is necessary, and the only real question is whether it is built where the platform will maintain it for you.

Further reading: update-safe extensions, the true cost of customisation, clean core in an SCM context, the upgrade tax, the upgrade readiness checklist, and what a release actually brings, with 25R2 purchasing as the worked example. Scoped modification work is listed under marketplace modifications.

Ask a buyer what goes wrong and you get something dramatic: a late shipment, a line stopped for a missing part. Look in the data and the costly problems are the undramatic ones, because nothing in the system objects to them.

All of this is detectable, and all of it is readable through standard OData projections on a read-only account. That means a monitor can look for it daily without touching a record, installing an object, or adding anything the next release has to be checked against. It is the design principle behind the SCM Automation Pack, and the reason the five-day exception scan exists as a way to see what is already in your own data before committing to anything ongoing.

On the physical side the same principle applies to warehouse work. Picking strategy and packing proposals are configuration decisions that quietly set your throughput ceiling, and they are rarely revisited after go-live.

Further reading: unconfirmed purchase orders, what unmatched receipts do at period end, supplier price changes, advanced picking strategies, the packing proposal.

Anomaly detection, demand forecasting and predictive maintenance are genuinely useful, and they all rest on the same unglamorous foundation: whether your master data is good enough for a model to learn from. A forecast built on lead times copied out of the legacy system in 2019 and never reviewed will be precise, confident and wrong, and it will be harder to challenge than a human guess because it arrives with a number attached.

The second thing the demo leaves out is what happens to the output. Detection is the easy half. The half that decides whether any of it pays off is routing: who receives the signal, how it reaches them, and what happens when they do nothing. An alert stream with no named owner and no escalation is a mailing list, and people unsubscribe from mailing lists in their heads long before they do it in the client.

That is why I design exception rules around the recipient rather than the condition. One deduplicated digest per owner per day beats forty individual notifications that are each technically correct. And a rule that cannot state in one sentence what the recipient is supposed to do about it does not ship.

Further reading: alert fatigue and exception design, the cost of missed exceptions, detecting supplier behaviour change, the data attention gap, assumed vs confirmed records, read-only OData monitoring.

Crystal Reports layouts from Apps 9 and 10 do not carry across to IFS Cloud. That is the fact that matters for your plan, whatever any vendor's support calendar says, and it is usually discovered later than it should be, because reporting gets treated as a workstream that can start once the real configuration is done.

IFS Cloud splits the job across different tools. Quick Reports handle lists and extracts: saved queries, no layout ambition, self-service for anyone who can be trusted with a data set. Laid-out business documents are produced through IFS Cloud's own report layout tooling. Analysis and dashboards belong in the reporting and analytics layer rather than in a printed report at all. Trying to recreate a 200-item Crystal inventory inside any one of these is how reporting becomes the critical path.

The work that actually saves you time is triage, and it is a business job rather than a technical one. Pull the usage data first. Most report inventories contain a long tail nobody has run in two years, a middle band that exists because one person likes the format, and a small core the business genuinely runs on. Rebuild the core properly, convert the middle band to Quick Reports or a dashboard, retire the tail. The conversation about retiring the tail is the hard part, which is why it needs to start early and needs someone senior to close it.

Further reading: when a Quick Report is the right answer, and the reports section of the marketplace.

Permission sets in IFS Cloud are capable enough to express proper segregation of duties. Whether they end up doing so is decided in the first six weeks of the project, when someone is under time pressure and the fastest way to unblock testing is to grant a broad set to a group and move on. That grant is almost never revisited, because nothing breaks. It surfaces at the first external audit, when a tester asks who can both create a supplier and approve a payment to it, and the honest answer takes a fortnight to assemble.

Design the role model against the process rather than the org chart, and build it while the process design is still fresh in everyone's head. It costs days then and weeks later. The same applies to standards work: if you operate under ISO requirements, the evidence those audits want is largely a by-product of decisions you are already taking, provided you record them as you go instead of reconstructing them afterwards.

Further reading: RBAC and segregation of duties, permission sets in IFS Cloud, ISO standards in IFS Cloud, and the security section of the marketplace. My own view on the wider ownership question sits on the data governance page.

Every implementation plan has a migration workstream, and most are optimistic by the same margin. The reason is consistent: the effort is not in loading the data, it is in deciding what the data should say. Loading is mechanical. Agreeing that these 4,000 part records are the ones worth keeping, that this status code maps to that one, and that a customer with no valid tax ID is a customer you are not going to migrate, is a series of business decisions with no obvious owner.

Two habits change the outcome. Rehearse the load more than once, on a schedule, with a defined cut of source data each time, so the failure list shrinks between rehearsals instead of being discovered on cutover weekend. And treat validation as its own deliverable with its own sign-off rather than as the last step of loading, because IFS Cloud enforces its business rules at load time: well-formed source data can still be rejected for violating application logic nobody had read.

Further reading: the data migration checklist, how FNDMIG and the Data Migration Manager fit together, and the data migration section of the marketplace.

In most of the companies I work with, a large amount of operational knowledge lives in one person's head and one person's spreadsheet. The buyer who knows which supplier actually delivers on time regardless of what the lead time field says. The planner whose workbook reconciles two things the system does not reconcile. None of this shows up in an ERP assessment, and all of it walks out of the building when that person leaves.

An implementation is the one moment when you have a mandate to surface it. Every shadow spreadsheet is a documented requirement waiting to be read: it exists because the system does not do something, and finding out what that something is tells you more about your real process than a workshop will. Some of them should become configuration. Some should become a Quick Report. A few are genuinely someone's judgement and should stay human, but at least then you know where they are.

The same logic applies to the implementation record itself. Decisions taken in month two get questioned in month eleven by people who were not in the room, and a project that cannot answer "why is it set up this way" reopens settled arguments for the rest of its life.

Further reading: shadow spreadsheet risk, knowledge loss when people leave, buyer knowledge concentration, and the implementation documentation kit if you would rather not build the templates from scratch.

I am wary of quoting percentage improvements. Published ranges come from situations you cannot inspect, with baselines nobody defined, and a number borrowed from another company's business case is not evidence about yours. What I can offer is the short list of measures that survive contact with an actual steering committee.

1. Pick metrics you were already arguing about. If nobody argued about on-time supplier delivery before the project, nobody will defend it as a benefit afterwards.
2. Take the baseline before go-live, from the old system. This is tedious and it is the only chance you get. A benefit you cannot baseline is a benefit you will eventually be asked to withdraw.
3. Keep it to three. Fifteen KPIs is a spreadsheet that gets maintained for four months. Three get reported for years.
4. Separate "we saved money" from "we can now see it". Visibility is a real benefit and a different one. Claiming it as cash is how a benefits case loses credibility.
5. Re-measure on a fixed date, not when it looks good. A quarterly slot in the calendar, owned by a named person, beats an ad hoc review after a good month.

Further reading: ERP ROI analysis, why go-live is a load test, the implementation crisis.

If you are live on IFS Cloud and this article has described your situation rather than your plan, the order that works is roughly this. Find out what is actually in your data before redesigning anything, because the exception population usually contradicts the received wisdom about where the problems are. Then fix the governance decisions that get harder with time: the role model, the report inventory, the ownership of master data. Automation comes after that, not before, because automating a process nobody owns only makes it produce wrong answers faster.

What I do is on the offer page, the platform view is on the IFS Cloud page, and the process side sits under business process optimisation. The applications themselves, including the read-only exception monitoring described in section 4, live on ifs-erp.com.

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. Based in Kraków, delivering remotely across Europe and globally through an independent practice.

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.