Select your language
It is day four of the close, and finance is the only floor with the lights still on. The controller has a spreadsheet open that does not agree with the ledger, an email out to a cost centre that has gone quiet, and the same number in two reports that somehow changed between this morning and now. Ask her how it is going and she uses one word, the word every controller uses. Chasing.
A five-day close feels like a failure of finance, and finance is where the blame lands. But finance did not make this mess. It only inherited it, on a deadline, at the worst possible moment.
The close is a mirror. It reflects, at month-end, every shortcut taken upstream weeks earlier: in a warehouse, on a work order, nowhere near finance.
IFS Cloud can turn the close from a scramble into a controlled, repeatable sequence. But only if you treat it as the last mile of a clean pipeline, not as a finance sprint bolted onto the end of every month. Here is what a good close actually rests on, and why nearly all of it lives upstream of the people doing the chasing.
Where the mess is madeIn a suite like IFS Cloud, the general ledger sits downstream of everything (inventory movements, manufacturing cost, project transactions, purchasing accruals, sales invoices), each posting in through defined accounting rules. So the ledger is never cleaner than the transactions feeding it. That number the controller cannot explain? Manufacturing or the warehouse created it three weeks ago, and she is doing forensic accounting to account for their open work order.
The lever is not a faster finance team. It is sub-ledger discipline during the month: costed transactions, closed work orders, cleared accruals, reconciled inventory, done continuously, so that at period-end there is nothing left to chase because nothing was left open. The close gets fast when the month was clean, never when finance works the weekend harder.
A gate, not a formalityIFS gives you real control over accounting periods: what can still post where, and in what order things close, so sub-ledgers settle before the ledger locks behind them. Used deliberately, it is a gate: late transactions land somewhere controlled instead of quietly reopening a number you already signed off. Used as an afterthought, it is a button someone clicks at the end, and then spends next month explaining why last month moved after it was closed. Decide the order on purpose. Which sub-ledgers close first, when the ledger locks, who may reopen a period and on whose authority. A close with no sequence is not a close. It is a snapshot that is still moving.
Designed onceOrganisations of any size owe more than one accounting truth: a local statutory view and a group standard, different valuations, different calendars. IFS can carry them in parallel, natively, falling out of the same postings. The trap is treating that as something finance reconciles at the end with spreadsheets. Do that, and every close becomes a manual bridge between two views the system could have maintained all along, rebuilt from scratch, twelve times a year. Designed properly up front, both truths just appear. Bolted on afterwards, you have signed finance up to reconcile two realities by hand forever. It is an implementation decision, and it quietly sets the ceiling on how fast every future close can ever be.
Turn the lights onPart of why the close feels like chaos is that no one can see it. Twelve tasks across six people, and the only status report is walking over and asking. So the controller spends the week chasing status instead of clearing work, the priciest kind of busy there is.
You do not speed up a close by working harder inside a black box. You speed it up by turning the lights on.
IFS Cloud’s Lobbies make the close a live picture (reconciliations outstanding, sub-ledgers still open, exceptions, the cost centres that have not reported), on one screen everybody shares, with no external BI stack to stand up. When the whole team can see the same close in real time, the controller stops being a human switchboard and the bottleneck stops hiding. The thing actually holding up day four becomes visible to everyone at once.
The real examEvery implementation has a moment of truth, and it is not go-live weekend. It is the first month-end on the new system, where migrated opening balances, fresh accounting rules, new cost structures and people still learning the screens all meet real numbers against a statutory deadline. Teams who prepare for it as an event (opening balances reconciled to a trusted number, the close steps dry-run, the first period-end staffed like a second go-live) sail through. Teams who treat it as “just another month” discover, live and on the clock, that an opening-balance assumption was wrong. If you are implementing now, put that first close on the plan as a named milestone with its own rehearsal. It is the exam the entire finance workstream was really studying for.
Every point above pushes the work upstream of period-end: into disciplined sub-ledgers, a deliberate sequence, parallel accounting designed once, a close you can see, a first month rehearsed. Do that and the close stops being five days of chasing. Skip it and no amount of heroics at month-end will save you, because the mess was already made, somewhere you were not looking.
Picture the same controller, a few months later. The sub-ledgers reconciled themselves through the month, because nothing was left open to chase. The sequence ran in order. Both accounting truths were already there. And the whole close sat on one Lobby the team could see, so nobody had to walk over and ask. The lights in finance are off by a reasonable hour, because the close finished on day one, not because anyone worked harder, but because the month was clean before it ever reached her desk.
That is the difference between a scramble and a sequence. It was never really a finance problem. It was a pipeline, and the close was just where you finally saw it.
We design IFS Cloud finance and data governance so period-end is a controlled sequence, not a scramble, and so the first close after go-live is a milestone, not a crisis. If your month-end is five days of chasing, the fix is upstream, and we know where.
Fix the close upstreamA line goes down at 6am, and the plant does the thing it always does. Someone finds Marek, because Marek has been here twenty years and Marek knows the machine. He remembers it did this last winter. He thinks the spare is on a shelf in the back, unless it is the one they used in March. Nobody can say when it was last serviced, because that lives in his head and a laminated sheet by the panel. The line is losing money by the minute while the whole recovery runs on one man’s memory.
Here is the strange part. This plant runs IFS Cloud. It plans beautifully, promises orders to the day, closes its books cleanly. And the one system that could have told them when the asset was last touched and whether the spare was in stock has been sitting in the licence the whole time, switched off.
They chose IFS partly because it unifies ERP, asset management and field service in one model. Then they ran the ERP and left the asset management dark.
It is one of the commonest patterns we see, and one of the priciest. So this is not a feature tour. It is a straight answer to why the dark module is usually the highest-return thing left in the building, and what changes the day you switch it on.
Made concreteStrip away the acronyms (EAM, MRO, preventive, predictive) and the maintenance side of IFS Cloud simply answers four questions Marek is answering from memory right now.
A real asset register (sites, locations, equipment and the parts inside them), so a machine is a living record with a history, not a line in a fixed-asset spreadsheet.
Preventive work orders that raise themselves on a schedule, a meter or a condition, instead of waiting for a 6am failure to remind you the machine exists.
A corrective work order that gathers the labour, the parts, the instructions and the history in one place, and pulls the spare from the same inventory your ERP already runs.
Cost, downtime and reliability captured over an asset’s life, so your worst offenders for cost and breakdown are a report, not an argument in a corridor.
The quiet magic is in the third answer. Because it is all one model, the spare Marek is hunting for is the same part your MRP plans, your buyers purchase and your finance values. No interface. No reconciliation. No second version of the truth.
The invisible costsYour ERP go-live tidied things you could already see: orders, stock, invoices. Maintenance is different, and more valuable, precisely because today it is invisible. And invisible is where the money hides.
The priciest hour in any plant, and the one maintenance exists to prevent. Move even a slice of failures from reactive to planned and it goes straight to the bottom line. Money you currently cannot even measure.
Working capital nobody is steering. On a spreadsheet, stores over-stock “just in case” while the one critical spare is always missing. On one platform with MRP, the guesswork becomes a plan.
Right now it is Marek. When Marek retires, a plant on memory loses him. A plant on IFS keeps every work order, fault and part recorded against the machine.
None of this needs a new system bought, evaluated or implemented. It needs the module already in your licence configured and turned on.
One model, all the way outIf you also service equipment in the field, IFS extends the very same model into Field Service Management: scheduling, dispatch, mobile work, parts in the van, the customer-facing side of it all. What matters is that it is not a separate tool with its own database bolted on the side. The asset, its history and its spare parts are the same records the plant and the ERP already use. The technician on a customer site sees what the planner sees. That single-model continuity, with plant, field, inventory and finance on one platform, is exactly what a standalone maintenance app can never give you, and it is precisely what you already bought.
The fixThe trick is sequencing it sanely rather than trying to boil the ocean. Start by building the asset register only as deep as you will actually maintain: model to the level you will raise a work order against, no finer, because a register you can keep up beats a perfect one you cannot. Put your first preventive plans on the assets that hurt worst when they stop, ranked by what a failure costs in downtime and safety. Connect spares to the inventory you already run, so “where is the spare” becomes a reservation instead of a scramble. Then let the data steer the rest: once work orders carry real cost and failure history, the machines that deserve condition-based or predictive attention raise their own hands. You stop guessing where to spend maintenance effort and start following the evidence.
The maintenance and asset-management capability is the part manufacturer after manufacturer leaves dark, and it sits directly on top of the highest, least-visible costs in the whole operation: downtime, spare-parts capital, and the knowledge that walks out with the people who hold it.
Run the same morning again with the module on. The line stops. This time the work order is already open on a screen, with the machine’s full history under it: last serviced six weeks ago, this fault seen twice before, the fix that worked. The spare shows two in stock, aisle and bin. A technician is assigned before anyone has finished their coffee. Marek is still the best engineer in the building, but now the plant no longer depends on his memory to get the line back, and neither will the person who takes his job.
The software was there the whole time. The only decision left is to switch on the lights.
We help manufacturers already on IFS Cloud light up maintenance and asset management, with no second platform and no re-implementation. If your assets live on a whiteboard beside a world-class ERP, that is the gap we close.
Switch on your asset managementIt is 2am on the go-live weekend, and the old system is already dark. There is no going back to it now. Someone is on the phone to a supplier integration that will not answer. The data load that was supposed to take two hours is at hour five. And a project manager is doing the quiet arithmetic of how little time is left before Monday, when three thousand people log in expecting to do their jobs.
Everybody treats go-live as a date. A finish line with a party after it. That is exactly why it hurts so often, because a date is something you simply arrive at, and you cannot fail at arriving.
A go-live is not a date. It is a load test: the first time your config, your data, your integrations and your people all run at once, with nothing to fall back on.
Load tests have a pass condition and a fail condition. The teams whose weekends are calm are the ones who had already sat this exam twice, in rehearsal. The teams whose weekends turn into a three-month clean-up treated the exam as a deadline they were sprinting toward. The difference is almost never talent. It is what they did in the weeks before.
The dress rehearsalThe single best predictor of a calm go-live is a boring one: a full mock cutover, run end to end on a copy that looks like production, before the real thing. Not the data load on its own. The whole runbook. Extract, transform, load, reconcile, open the balances, flip the integrations, smoke-test the journeys that matter. Timed. In order. By the people who will do it for real.
The first rehearsal always overruns, and it always surfaces the step nobody wrote down. That is the point of it. You want to meet the six-hour load and the reconciliation that will not tie in a rehearsal you can stop, not at 2am with the old system already gone. Do it at least twice: the first proves the runbook is incomplete, the second proves it is repeatable and hands you a real duration to plan the weekend around.
The quiet failureData does not have to be missing to sink you. It only has to be a little wrong, and a little wrong is invisible right up until finance tries to close the month.
A load with no errors is not a load that is right. You have verified the loader, not the data.
So reconcile against numbers the business already trusts, both ways, before you commit: trial balance to trial balance, inventory quantity and value by site, open receivables and payables, open orders by count and value. The dangerous load is not the one that throws errors. It is the one that runs perfectly and lands the wrong costing method on a single site, or drops the orders that were mid-shipment when you took the extract. Those do not announce themselves. They surface three weeks later as a variance, when it is a forensic investigation instead of a validation step.
Decided in daylightThe worst possible time to decide whether you are fit to go live is inside the go-live: at midnight, exhausted, invested, everyone aching for it to be a yes. Decide it in cold blood, weeks ahead. The exact reconciliations that must tie. The transactions that must complete in a smoke test. The count of open defects you will tolerate, by severity. The integrations that must be confirmed live. And, with equal care, the line at which you stop and roll back.
A rollback plan invented on the night is not a plan; it is a panic with a name. Written in daylight, go / no-go becomes a checklist anyone can read against reality. Written on the night, it becomes whatever the highest-ranking tired person in the room wants it to be.
The Monday everyone leftHere is the pattern, and it is almost universal. The cutover succeeds. The team celebrates. And on Monday people quietly drift back to their day jobs, because “we’re live now,” at the precise moment users are hitting the system hardest and finding everything the test scripts never thought to try.
Go-live weekend is not the finish line. It is the start of the sharpest stretch of the whole load test: the first two or three weeks, and above all the first month-end close, where every quiet assumption from the project finally meets real volume and real people. Staff hypercare like it matters: named people, real coverage, a fast path from “a user is stuck” to “someone who can fix it,” and a daily stand-up that burns the list down. Treat that first close as a second go-live, because operationally that is what it is. And where the business allows it, phase the whole thing (a lead site first, then roll the pattern out with the lessons already paid for) rather than betting everything on one heroic weekend.
Every rule here does the same thing: it drags a discovery earlier, into a mock cutover, a reconciliation, a written criterion, a staffed first month, where it costs a rehearsal instead of a crisis. A calm go-live is not bravery on the night. It is an exam you have already passed twice, so the real one is just paperwork.
Picture the same weekend on the other team. It is still 2am. The old system is still dark. But nobody is doing panicked arithmetic, because they have run this exact sequence twice and know it finishes at four. The reconciliations tie, the way they tied in rehearsal. The integration that failed last time was found and fixed a fortnight ago. Monday will be busy, and hypercare is already rostered for it. The weekend is not a leap of faith. It is the calmest part of the project, because all the hard moments happened earlier, on copies, where they were allowed to.
We plan and run IFS Cloud cutovers as rehearsed load tests, with fixed-price guarantees, and we rescue the ones that went live on hope. If your date is close and any of this feels soft, let’s talk while there is still time to rehearse.
Plan a rehearsed cutoverEvery spring, the same line appears in their plan: “IFS upgrade: allow one quarter.” Nobody questions it anymore. It is treated like weather. Three months of a developer re-applying the same modifications, a nervous fortnight of clicking through screens to check nothing broke, and a go-live-sized knot in everyone’s stomach, twice a year, forever.
Two floors down, a competitor on the exact same product takes the same release over a weekend and barely mentions it on Monday. Same platform. Same cadence. Wildly different lives. The difference was decided years ago, by how each of them built.
The cadence that keeps IFS Cloud modern is the same cadence that bills you for every shortcut you took at build.
IFS ships a Release Update twice a year (24R2, 25R1, 26R1), each with new features and cumulative fixes. Between them come monthly Service Updates: high-severity fixes only, no new functionality, nothing that breaks your data model unless a critical bug forces it. And because each release keeps getting those service updates longer than the gap to the next one, you get a real say in when you move. That is the “Evergreen” promise. The promise is genuine. Whether you get to enjoy it is up to you.
The line that decides everythingIFS draws a hard line down the middle of every customisation, and your future sits on one side of it or the other.
The Extensibility Framework (custom fields, custom logic, custom events) plus configuration through Page Designer. It layers on top of the core, so when a release lands it simply comes along. No drama, no re-work.
Modifications that reach into IFS’s own behaviour. They work. They demo beautifully. And every single release, someone has to re-apply and re-test them against a core that moved underneath, a bill that only arrives at the first upgrade.
The rule is unglamorous: exhaust configuration and framework extension before you cut into the core. Every core change is a standing subscription, re-tested twice a year for the life of the system. Sometimes that price is worth paying. It is never free, and it should never be paid by accident at whichever desk the ticket landed on.
Know the differenceHalf the panic around upgrades comes from treating every update as if it were the big one. It is worth keeping the two straight.
| Release Update (RU) | Service Update (SU) | |
|---|---|---|
| How often | Twice a year (24R2, 25R1, 26R1) | Monthly, cumulative |
| What’s inside | New functionality and cumulative fixes | High-severity fixes only |
| Can it move the ground? | Yes; APIs and data models can change | No, unless a critical bug forces it |
| Your part | Choose when to adopt, inside the Evergreen window | Take them; they are the safety net in between |
Ask a team in trouble what they have changed from standard, and you get a pause. Someone starts a sentence about a thing finance asked for years ago. Someone else is not sure if that nightly job is theirs or shipped. That pause is the whole cost of the upgrade, in advance.
An upgrade costs exactly what it costs to know what might break. The silence when you ask is the invoice.
Keep a living register instead: every extension, event, custom field, integration and core change, each with an owner and a reason. It is not documentation theatre. It is the one artefact that turns “how long will the upgrade take?” from a shrug into a number. And it is what lets you prove the business still works afterwards without a fortnight of manual clicking: capture the handful of flows that would stop you invoicing or shipping (order-to-cash, procure-to-pay, plan-to-produce, the close) as a repeatable check you run before and after. What was a nervous two weeks becomes a pass or a fail you can trust in a day.
The compounding kindEvergreen gives you flexibility, and flexibility has a sharp edge. Skip one release and you are fine. Skip three because “we’re stable” and you have dug a chasm: more change to absorb at once, service updates running dry on your ageing release, and an upgrade that is now genuinely a project, because you turned three small steps into one cliff. Stable was never stable. It was deferred, and deferral compounds.
Pick a cadence and hold it. Teams often settle on one release a year, comfortably inside the window, taking the service updates in between. And whatever you adopt, rehearse it on a copy that looks like production first, not on a clean demo where your extensions never meet real volume. The custom event that is fine on ten rows and dies on ten million always shows itself in the dress rehearsal, never politely in the demo.
The platform hands you a predictable path to stay current without a re-implementation. Whether that path is a weekend or a quarter is not set by IFS. It is set by how you extended, whether you wrote it down, and whether you can prove the business still runs. Those are choices made long before the release ever landed.
Imagine the same team, a year on, deleting that line from the plan. Not because the upgrade got easier, but because they moved their changes above the line, wrote down what they own, and built a check they can run in a day. The release still lands twice a year. It has just stopped being weather they brace for and become a Tuesday.
That is the whole promise of Evergreen, and it was never really about the product. It was about the discipline underneath it.
We build IFS Cloud extensions the release cannot break, and turn the twice-yearly upgrade dread into a scheduled non-event. If your last update ate a quarter, let’s make the next one boring.
Make the upgrade boringIt is month eleven, and the status has been green for a while. The steering committee nods along. The sponsor is pleased. Everyone in the room believes the project is healthy, because every report they have seen says so. And the project is already dead. It just has not told anyone yet.
That is the unnerving thing about a failing ERP project. It does not fall over. It keeps scheduling meetings, keeps turning things green, and quietly changes what “done” is going to mean, right up until acceptance, when everyone finds out at once.
The build is almost never wrong. It is faithful. Faithful to requirements that were never quite real.
When you are called in to rescue enough of these, the post-mortems start to rhyme. Nobody was lazy. Nobody skipped a step. The work was done well against a set of requirements that had already gone soft, months earlier, in a room where everyone was too happy to notice. Here is where it actually goes wrong, and where you can still catch it.
The first soft spotThe requirements sit in a spreadsheet, sorted by module. Financials. Manufacturing. Supply Chain. Maintenance. It looks organised, it looks complete, and it has already lost the plot, because nobody in your business experiences a module. They experience a customer order, and one order walks straight through half of them.
A tidy list of things to switch on. Every hand-off (order to shop floor, shipment to invoice, invoice to ledger) falls into the gap between two workstreams. And the gaps between workstreams are exactly where go-lives come apart.
Order-to-cash. Procure-to-pay. Plan-to-produce. One person owns each journey the whole way across the modules, so the seam between manufacturing and finance has a name on it before it becomes a defect.
Point at any requirement and ask a simple thing: which journey does this serve, and who owns that journey end to end? If the honest answer is a module name, it is not a requirement yet. It is a wish, filed alphabetically.
The word that dodgesStandard IFS covers nearly all of what a business needs before anyone touches it. The interesting 10 to 20 percent is the whole game, and it usually gets handled by writing “must have” in a column and moving on. That feels like a decision. It is the opposite of one.
“Must have” is not a decision. It is a way of avoiding one, politely, in writing.
Every gap has two prices, and both belong on the table. What it costs to close: configuration, an extension, a change to how the business works. And what it costs to leave open: a workaround, an hour a week, a quiet risk. The moment a line reads “forty thousand to build, plus a few thousand a year to keep upgrade-safe, versus twenty minutes a week in a spreadsheet,” the argument settles itself. Half the must-haves turn out to be nice-to-haves that nobody wanted to say out loud. The ones you never cost do not vanish; they wait, and come back as change requests at the worst possible moment.
Made concreteWhen you decide to close a gap inside the system, you are also deciding who inherits it, because the way you build it today sets who pays at every upgrade for the next ten years. IFS gives you three doors. They look similar in a workshop. They are not the same door.
| How you close the gap | What it really is | Who pays at the next release |
|---|---|---|
| Configuration: a workflow, a rule, a value maintained on a screen | ✅ Standard | Nobody. It comes along for the ride. |
| An upgrade-safe extension: a custom field or logic through the Extensibility Framework | 🟡 Addition | Little, if it stays inside the framework, though it still needs an owner and a note. |
| A modification that reaches into the core | 🔧 Change | Someone re-applies and re-tests it every six months, for as long as it lives. |
None of these is wrong. The mistake is choosing between them by accident, in the build phase, at whichever desk the ticket happened to land on, instead of on purpose, in requirements, with the person who signs the upgrade budget in the room.
The empty chairsTwo chairs tend to sit empty during requirements, and both bills arrive later with interest.
The first belongs to whoever actually owns the data. Migration gets filed as a technical job for the end. But which customers are still real, which parts are dead, what the costing method is per site, what “clean” even means for your item master: a consultant cannot answer any of that. If the master-data steward or the controller first shows up in month five, month five is when they discover a hundred small assumptions were made on their behalf. Some were wrong. You meet those at the first month-end after go-live.
The second belongs to the people who live the process. The fit-gap document is not paperwork; it is the treaty between what the business thinks it is getting and what is actually being built. Left unsigned, it drifts. Every “oh, we also assumed…” is a silent edit, and none of them shrink the scope. Get it signed by the process owners, not by IT. A signature turns a spectator into a co-author; it stops being our build and becomes their solution. Skip the signature and you do not avoid it. You just move it to go-live weekend, where the same conversation is called a critical defect and costs ten times more.
In requirements, changing your mind costs an email. In build it costs a day, in testing a week, at go-live the whole quarter. Every soft spot above is the same soft spot: a decision quietly postponed to a phase where it is a hundred times more expensive to make.
Return to month eleven and the green report. The project was not healthy and then suddenly sick. It had been drifting since the workshop where everyone nodded, where a shopping list stood in for a scope, must-have stood in for a decision, and two chairs stayed empty. The report was green because nobody had yet asked the questions that would have turned it amber.
So ask them early, while it is still cheap to hear the answer. For every requirement: which journey does it serve and who owns it; what does closing the gap cost to build and to keep; and has the person who owns the data underneath it actually seen the assumption. Anything that cannot answer all three is not a requirement. It is a change request that has not introduced itself yet.
We run fixed-price, PRINCE2-governed IFS Cloud projects, and we are called in to rescue the ones that went green a little too long. If your requirements phase cannot survive those three questions, let’s talk before build.
Book a requirements reviewTwo people sit in front of the same screen at an acceptance meeting. The consultant points at a field and says this was always standard. The key user shakes her head and says no; we asked for this in the workshop, it was built for us. Both of them are calm. Both of them are certain. Neither of them is lying.
That is the strange part. Nobody in the room is wrong. They are just reading from two different dictionaries.
Nobody in the room is wrong. They are just reading from two different dictionaries.
In languages there is a thing called a false friend: two words that look identical across languages but carry different meanings. A speaker trusts the word, uses it the way it works at home, and walks straight into a misunderstanding. The word did the betraying, not the person.
Standard is a false friend inside an IFS Cloud project. The client and the vendor both use it constantly. They nod when the other says it. They write it into workshop notes and status reports. And the whole time it means two different things.
Anything a modern ERP should obviously do. If a competitor has it, if it feels basic, if a salesperson once showed it in a demo, it is standard. Standard means included. Standard means already paid for.
Shipped in the product, configurable without custom code, upgradeable without extra hands at the next release. Everything else is a change, and a change has a number, a cost, and a line on an invoice.
Same word. Two dictionaries. The gap between them is where projects quietly bleed.
The real invoiceThe usual question is who pays for the confusion, and the usual answer is the client through change requests, or the vendor through eroded margin. That framing is too small. It only counts money, and it only counts the people who signed.
Walk forward two years. The consultant who drew the line has rolled off to another project. The sponsor who approved the budget has changed jobs. The salesperson is long gone. The custom event action they argued about is still running every night against ORDER_QUOTATION, and nobody in the building remembers why it exists or whether it is safe to touch.
Inherits a custom package with no comment explaining the intent, and has to decide, alone, whether it is safe to touch.
Stops trusting the system because it does one thing here and a different thing there, for reasons nobody can name.
Quotes high on everything, because they cannot tell which layer is product and which layer is somebody’s old promise.
The invoice was the cheap part. What really got spent was trust, and it was spent by people who never agreed to the deal.
The abstraction becomes real the moment you look at objects. The trouble is never the obvious cases: it is the field and the event, the things small enough to wave through and real enough to come back.
| The object | What it really is | Who owns it at the next upgrade |
|---|---|---|
| A workflow set up in the application, a rule maintained on a screen, a value in a basic-data table | ✅ Standard, configuration | Nobody. Upgrades come along for the ride. |
| A custom field | 🟡 Grey zone, an addition that feels standard | Low effort each, but at volume, real maintenance and documentation weight nobody scoped. |
A custom event with a custom event action |
🔧 Modification, even when it looks small | Someone owns that PL/SQL across every future upgrade, and someone should have said so out loud. |
| A projection extension or a custom entity | 🧩 Custom, and everyone agrees | Clearly the project’s. The easy case; never the one that bites. |
The fix is not a longer contract. It is one honest conversation held early, while everyone still likes each other.
On this scope, in this version of IFS Cloud. Write down a handful of real examples the client assumes are included. Let the consultant mark each one as configuration, custom field, or custom logic, and say plainly what a change would cost, while the answer is cheap, not at acceptance when it is a fight.
Not in an annex nobody opens, in the room where the work happens. The point is not to win the argument later. The point is to never need to have it.
The line between standard and modification is not something to settle at the end. It is a translation done at the start. Skip it, and you do not save the work, you just hand the bill to someone who was not there to say no.
Go back to the two people in front of the screen. They were never really arguing about a field. They were discovering, far too late, that they had been speaking slightly different languages for months and calling it agreement.
The line between standard and modification is not a legal detail to be settled at the end. It is a translation done at the start.
We run the dictionary conversation at the start of an IFS Cloud project, when the answer is still cheap, and we translate scope into configuration, extension, or modification so nobody is surprised two years later.
Book a scoping conversationDiscover how the IFS Cloud platform transforms traditional material resource planning into a highly integrated, project-driven architecture engineered for complex industrial engineering and construction dynamics.
Engineering, Procurement, and Construction environments demand a departure from repeatable manufacturing frameworks. Within complex infrastructure initiatives, operational efficiency cannot rely on standard material requirements planning designed for stable production lines. The Supply Chain Execution module within the IFS Cloud architecture operates as a highly specialized, project-driven ecosystem. This framework unifies structural engineering, global procurement, site logistics, and enterprise finance within a singular, real-time database ledger.
By linking the engineering lifecycle directly to field deployment, the system removes organizational data silos. This ensures that every material commitment, transport milestone, and supplier transaction relates directly to the overarching project structure.
Synchronizing structural design with procurement schedules mitigates data entry fragmentation and accelerates execution timelines.
Securing material inventory allocations ensures project timelines remain uncompromised by competing operational demands.
Optimizing field deliveries reduces site congestion and maximizes installation continuity for construction crews.
Real-time commercial visibility ensures direct cost capitalization against active project budgets.
Modern enterprise implementations often require adapting global logistics records to support specialized project entities. Real-world applications show that mapping functional location identifiers directly to global address books streamlines asset tracking.
System Automation Strategy: When project parameters require delivery addresses to match functional installation sites rather than generic customer locations, dual synchronization frameworks ensure that site data modifications transfer instantly across sales quotes, client orders, and logistics dispatch screens.
By removing separate interfaces between procurement desks, engineering departments, and field operations, the IFS Cloud platform delivers total financial predictability throughout complex asset construction cycles.
In legacy enterprise resource planning systems, order promising relies on simple static rules or unconstrained Availability Check (Available-to-Promise/ATP) logic. ATP queries the inventory balance table, adds firmed supply receipts, subtracts firmed demand obligations, and outputs a binary yes/no or a quantity-time bucket. This mechanism fails in volatile manufacturing environments because it assumes infinite capacity, linear supply yields, and localized inventory pools.
IFS Cloud eliminates this systemic vulnerability through the Capable-to-Promise (CTP) engine. CTP functions as a real-time, high-fidelity deterministic simulation engine. When a customer order or sales quotation line requests a specific quantity and delivery date, CTP evaluates the absolute multi-dimensional constraints of the enterprise network. It does not merely look at what is available; it evaluates what can be made available within the requested temporal boundary.
Operational Definition: CTP is a multi-level, constraint-aware scheduling algorithm that synthesizes the Material Requirements Planning (MRP) bill of material explosion with the Advanced Planning and Scheduling (APS) finite resource allocation engine at the exact millisecond of order entry.
To understand why CTP must be deployed for complex environments, consider the underlying execution differences during a Sales Order save transaction:
| Execution Dimension | Standard Availability Check (ATP) | Capable-to-Promise (CTP) Engine |
|---|---|---|
| Database Operations | Performs a basic aggregate query on INVENTORY_PART_IN_STOCK and firmed supply records. Minimal CPU overhead. |
Explodes the active revision of the MANUF_STRUCTURE, calculates manufacturing lead times, and evaluates resource load tables in memory. High CPU/IO performance requirement. |
| Capacity Handling | Ignores work center load entirely. Assumes machines, labor, and tooling possess infinite throughput capacity. | Analyzes the finite capacity allocations within WORK_CENTER_RESOURCE_AVAIL, blocking slots based on operation run times. |
| Component Visibility | Restricted to the top-level part number on the customer order line. | Explodes deep into sub-assemblies, checking phantom structures, raw materials, and purchase lead times across nested structures. |
| Data Persistence | Updates temporary session states or writes a soft reservation balance record. | Can instantly instantiate and persist INTERIM_ORDER_HEAD and INTERIM_ORDER_LINE structural networks to lock capacity. |
The CTP engine operates via three discrete, mathematically rigorous processing phases whenever a Capability Check is invoked from a sales object. Understanding these pillars prevents misconfiguration and system latency during high-volume data entry.
When the engine fires, it instantly maps out a dynamic matrix consisting of physical inventory, firmed purchase orders, in-transit transfer orders, current shop order allocations, and machine/labor capacity records. The engine uses a backward-scheduling heuristic by default. It begins at the user’s requested delivery date, moves backward through the transport lead time, and identifies the target completion date for the manufacturing cycle.
If backward scheduling reveals a constraint violation—for instance, a machine load exceeds 100% on day three of the sequence, or a critical chemical component has an unalterable 14-day vendor lead time—the engine stops backward execution. It flips instantly to a forward-scheduling pass from the earliest point of constraint clearance, projecting the mathematically true earliest possible delivery date.
Products are rarely flat. A custom pump assembly contains an impeller sub-assembly, which contains machined castings, which require raw stainless-steel bar stock. Standard ATP checks fail here because they assume the impeller is on the shelf. The IFS Cloud CTP engine explodes down through every branch of the active Engineering or Manufacturing Structure revision.
If the part configuration dictates multi-site sourcing (e.g., the casting occurs at Site A in Poland, but final assembly occurs at Site B in Germany), the CTP engine executes a cross-site database pipeline. It calculates the Inter-Site Material Transfer Lead Time, queries the production capacity of Site A, hooks into the calendar constraints of both locations, and builds a unified delivery timeline across company boundaries.
To prevent the "phantom promise" problem—where two sales reps concurrently promise the exact same machine slot to two different customers—IFS Cloud uses the Interim Order mechanism. When a Capability Check is executed and found valid, the system creates an interim reservation layer. This layer writes lightweight, high-speed tracking records directly to the database:
INTERIM_ORDER_HEAD: Holds the unique session identifier tied to the specific Customer Order Line or Sales Quotation Line.INTERIM_ORDER_LINE: Maps directly to the required material components and structural routing stages.INTERIM_ORDER_OPERATION: Places a temporary, firmed block on the specified Work Center Resource capacity grid, effectively hoarding that slot until the customer order is firmed or the quotation session expires.To enable CTP functionality within an IFS Cloud site, the master data must be structurally configured to shift from static inventory counting to dynamic promise planning. Skip no steps in this sequence; any missing flag will cause the system to default silently back to a standard unconstrained inventory check.
Navigate to the Inventory Part page. Query your target component or parent part. Open the Manufacturing sub-tab. Locate the fields governing order promising and planning behaviors. Execute the following configuration changes:
INVENTORY_PART_TAB, telling the transaction manager to allow execution of the Capability Check pipeline.Ensure that the **Planning Method** under the Acquisition properties is set to a method compatible with discrete tracking (such as A, B, or M). Methods designed for kanban or point-of-use consumption (like Planning Method H or I) will cause structural validation errors during the CTP explosion because they decouple direct demand-to-supply parent-child linking.
Navigate to the Work Center screen for every critical execution node in your facility. Under the Capacity properties, verify that your efficiency and utilization factors are precisely calibrated. If your machine runs at 90% real-world output due to calibration drift or setup overhead, set the **Efficiency Factor** to 0.90. Leaving this value at the speculative ideal of 1.00 will force the CTP engine to over-promise delivery dates based on machine rates your shop floor cannot physically achieve.
Next, open the Routing Revision and Alternative page for the parent part. Ensure that your operations are linked to these work centers with verified **Setup Time** and **Factor/Run Time** constants. Toggle the **Resource Capacity Check** option to Finite Capacity on your bottleneck work centers to force CTP to respect hard scheduling thresholds.
Navigate to Site / Manufacturing Information. Under the general rules matrix, ensure the checkbox for **Use Interim Orders for CTP** is explicitly marked TRUE. This enables the database persistence layer to write capacity allocations on a draft Sales Quotation before it hard-converts into a real Shop Order.
The implementation architecture of CTP alters fundamentally depending on your commercial delivery strategy. Below are the three primary production workflows deployed by enterprise-scale IFS Cloud architectures.
In a strict MTO ecosystem, parts are pre-defined structurally via bills of material, but zero component or parent safety stock is held in warehouse locations. Supply chains run strictly just-in-time based on actual demand signals.
The Operational Execution Workflow:
Customer Order window and initiates a new record for a client requesting 15 units of heavy industrial winch assemblies (Part ID: W-400-DISC).MANUF_STRUCTURE for W-400-DISC. It calculates that raw material steel plates are available, but a specialized hydraulic motor component has an external supplier lead time of 10 days.INTERIM_ORDER_HEAD token, locking those capacity segments against other users.Configured components leverage the IFS Product Configurator module. These components do not possess a fixed, static Bill of Material or a immutable Routing sheet. Instead, the structure and the runtime labor paths are dynamically generated on-the-fly based on characteristic responses selected by the customer during sales qualification.
The Operational Execution Workflow:
Sales Quotation line for a commercial HVAC unit. The part number is flagged as a configurable template part.In highly distributed global manufacturing topologies, final customer delivery happens at a local distribution node (Site Sales), but production occurs across multiple distinct manufacturing facilities (Site Machining, Site Assembly) located in different regions or under separate legal entities.
The Operational Execution Workflow:
US_SALES) for an order of custom transmission gears.SE_GEAR).US_SALES order line.SE_GEAR. It explores the local manufacturing structure and looks at the capacity limitations of the cutting and heat-treating furnaces in Sweden.US_SALES, displaying a rock-solid, fully integrated cross-border commitment date. When confirmed, the system generates linked internal Purchase/Customer Order patterns across both site structures alongside an interim manufacturing footprint in the Swedish plant database.Beyond traditional order verification, the architectural layout of the IFS Cloud CTP engine allows it to be leveraged for creative operational advantages across complex macro-industrial execution structures.
During competitive deal cycles with enterprise-tier tier-1 accounts, inside sales teams frequently find themselves trapped in multi-week negotiation standstills. While contracts are routed through legal checkpoints, smaller, low-margin transactional orders coming in from web portals or EDI links can steadily consume your finite production capacities. This leaves your plant unable to satisfy the major account’s delivery targets once the contract is signed.
To hedge against this risk, execute a Capability Check on a dummy **Sales Quotation Line** matching the estimated volume of the pending enterprise contract. Ensure the system parameter for *Save Interim Orders* is active. This action writes temporary, firmed records directly into your work center capacity pools.
When the CTP engine executes a Capability Check across a deep, promise-planned BOM, it flags the exact raw material components that trigger a forward-scheduling shift due to lead-time delays. This asset can be reversed for predictive inventory management.
By regularly running batch capability simulations via data migration or script schedules against speculative master schedules, you can identify precisely which raw material sub-components will break your lead-time commitments if demand ticks up by a specific percentage. This allows your procurement officers to issue targeted forward supply contracts or execute strategic buffer buys on raw commodities long before standard MRP systems register a critical material shortage alarm.
For operations running parallel manufacturing sites with identical or overlapping structural capabilities, CTP serves as an automated distributed logistics broker. By setting up your inventory items as multi-site routed components with alternative supply options mapped directly inside your distribution matrices, a capacity check can be run across multiple locations.
If Site A returns an unacceptable forward-scheduled promise date due to machine maintenance or labor constraints, the calculation loop can immediately run an alternative site trace against Site B. If Site B can fulfill the manufacturing requirements quicker—even when factoring in any additional inter-site logistics transport overhead—the sales agent can re-route the internal fulfillment logic on the spot, achieving live load balancing across separate facilities based entirely on temporal constraint matching.
Implementing Capable-to-Promise is not simply a system configuration project; it is an overarching business transformation that changes how an enterprise handles customer fulfillment. Moving to an automated, high-fidelity constraint check impacts multiple business domains:
To verify that your CTP transaction layers, interim tables, and state flags are executing with correct database-level validation, run the following PL/SQL validation block within your test console. This block executes an explicit state check, ensuring your master data changes are active and that no null values are present on critical columns.
DECLARE
v_part_no VARCHAR2(25) := 'W-400-DISC';
v_contract VARCHAR2(5) := 'SE10';
v_prom_planned VARCHAR2(20);
v_interim_cnt NUMBER;
BEGIN
-- 1. Verify Inventory Part Order Promising configuration state
SELECT order_promising_type
INTO v_prom_planned
FROM inventory_part_tab
WHERE part_no = v_part_no
AND contract = v_contract;
IF v_prom_planned != 'PROMISE_PLANNED' THEN
RAISE_APPLICATION_ERROR(-20001, 'Critical Configuration Failure: Part is not Promise Planned.');
END IF;
-- 2. Verify that the Interim Order Persistence Layer tables are structurally sound
SELECT COUNT(*)
INTO v_interim_cnt
FROM interim_order_head_tab
WHERE rownum <= 5;
Dbms_Output.Put_Line('CTP Validation Succeeded. Target Part Status: ' || v_prom_planned);
EXCEPTION
WHEN NO_DATA_FOUND THEN
Dbms_Output.Put_Line('Master Data missing for verified combination: ' || v_part_no || ' @ ' || v_contract);
WHEN OTHERS THEN
Dbms_Output.Put_Line('Structural system validation fault: ' || SQLERRM);
END;
/
Incorrect delivery commitments ruin customer trust and drive up operational costs. Whether you run complex Make-To-Order production lines, heavily engineered Configured Variants, or multi-site global distribution networks, our certified IFS Cloud consultants are ready to audit your master data structures, build your exact CTP scheduling rules, and clear your execution bottlenecks.