How to use AI with IFS ERP: a practical starting point
Most AI-for-ERP advice is written by people who have never watched a planner try to find a screen. This is the version for people who have.
In short
The practical way to use AI with IFS ERP is to start where the friction is highest and the risk is lowest: let people ask questions of live IFS data before letting anything write to it. Prove the answers, then enable one low-risk transaction type, then expand by role rather than by module.
- Start with read-only questions — they are verifiable in seconds and need no governance approval.
- Pick a use case where the current alternative is interrupting a colleague.
- Expand by role, not by module: give one group the whole job.
- Measure interruptions avoided and records created at source, not "AI adoption".
Where does AI genuinely help in IFS Cloud?
AI helps most where IFS already holds the answer and the only cost is reaching it. Look for the tasks where somebody currently interrupts a colleague, or opens a spreadsheet instead, or waits until Friday. Closing those gaps is a larger and far more certain win than any prediction model.
The last one is worth separating clearly. Conversational access is human-initiated and single-step; automation is event-driven and multi-step. In the Ngage Suite those are deliberately different products, because conflating them produces something that does both badly.
- Access — letting non-expert users query live IFS data by asking.
- Capture — getting records created at the moment and place the event happened.
- Explanation — answering "how is this meant to work" without a super-user.
- Automation — running defined processes unattended, which is a different product category.
Which use case should we start with?
Start with a read-only question that someone currently answers by interrupting a colleague. Stock balance and order status are the canonical choices: high frequency, trivially verifiable against Aurena, zero write risk, and immediately obvious value to the person being interrupted twenty times a day.
Resist starting with the most impressive demo. The goal of the first phase is not to be impressed; it is to establish that the answers are right. People extend trust to systems that have been correct about small things.
How should a rollout be sequenced?
In four phases over roughly a quarter: read-only questions, then low-risk writes such as fault and incident reports, then operational updates, then IFS actions like release and approve. Each phase should run long enough for users to catch errors, and each should be enabled for whole roles rather than sprinkled across modules.
| Phase | Scope | Typical duration | What to watch |
|---|---|---|---|
| 1. Read | Stock, order status, work order backlog | 2–4 weeks | Answer accuracy against Aurena |
| 2. Low-risk write | Fault reports, HSE incidents, meter readings | 2–4 weeks | Record quality and volume at source |
| 3. Operational write | Work order updates, requisitions, date changes | 4–6 weeks | Confirmation-step behaviour and error handling |
| 4. Actions | Release, approve, complete | Ongoing | Permission refusals — they should happen |
Scroll the table sideways to see every column.
What should we measure?
Measure the behaviour you wanted to change, not usage. The meaningful metrics are interruptions avoided, records created at source rather than retrospectively, and time between an event happening and it appearing in IFS. Message counts tell you the tool is being used; they do not tell you anything improved.
- Lookup requests to super-users and planners, before and after.
- Share of fault and incident reports created on the day of the event.
- Median lag between event and IFS record.
- Proportion of occasional users touching IFS at all in a month.
What usually goes wrong?
Three things, reliably. Starting with write access before trust exists. Rolling out to a horizontal slice of every department so nobody gets a complete job. And leaving the data quality problems that made IFS hard in the first place — a conversational interface makes bad master data easier to find, not better.
The third is worth taking seriously. If your part descriptions are inconsistent or your object structure is a mess, an assistant will surface that faster than any audit. That is genuinely useful, and it is also not what people expect in week two.