Any ERPBuyer Guide

ERP AI readiness

Is Your ERP Ready for AI? A Readiness Assessment Checklist

Short answer

ERP AI readiness comes down to four things: master data clean enough to trust an answer built on it, access paths (API or read replica) that do not compromise production performance or security, enough GPU capacity sized to the actual model and user count, and a governance process that defines who approves AI-initiated writes. Most stalled ERP AI projects fail on one of these four, not on model quality.

ERP: SAP, Infor, Oracle, Microsoft Dynamics, Epicor, IFS, Deltek Costpoint
Industries: Manufacturing, Aerospace, Defense, Electronics
Written for: CIO

Discuss your SAP environment See use cases

Before funding a pilot, most CIOs want a straight answer to one question: is our ERP actually ready for this, or are we going to spend the pilot budget discovering that our master data, access model, or infrastructure was not up to it? The honest answer is that readiness is rarely all-or-nothing. Most ERPs are ready for some use cases and not others, and the assessment's job is to say which is which before money moves.

The teams that stall usually skip straight to model selection and prompt design, then hit a wall three weeks in when they realize the item master has 40% duplicate part numbers, or that the only path to live data is a direct connection to the production database that the DBA will not approve, or that nobody has decided whether an AI agent is allowed to update a due date without a person clicking approve.

A readiness assessment is not a certification exercise, it is a short, structured look at four areas, data quality, access and integration paths, infrastructure sizing, and governance, scored against the specific use cases you actually want to run first. The output should be a prioritized backlog: which use cases are ready today, which need two to four weeks of data cleanup first, and which need an infrastructure or policy decision before they are worth pursuing.

This page is a practical checklist you can run internally or use to brief a partner. It applies whether you are on SAP, Infor, Oracle, Dynamics, Epicor, IFS, or Costpoint, the specific tables and APIs differ but the four readiness dimensions do not.

What usually gets in the way

The problems we hear most from cio teams running SAP.

Master data quality is worse than anyone admits in the planning meeting

Duplicate customers, inconsistent unit-of-measure conversions, item descriptions that mean different things across plants, and stale supplier records all directly degrade AI answer quality, because a language model will confidently synthesize an answer from whatever data it is given, contradictions included.

Access is either too open or effectively impossible

Teams either propose giving an AI agent broad direct database access, which security will correctly reject, or they discover the only sanctioned API does not expose the fields the use case actually needs, and the project stalls waiting on an integration decision.

Nobody has sized the infrastructure against real usage

GPU and memory requirements for a 20-person pilot look nothing like a 500-user rollout; projects that skip sizing either overbuy hardware they do not need yet or discover mid-pilot that response times are unacceptable under real concurrent load.

Governance is an afterthought instead of a gate

Who approves an AI-suggested purchase order change, who is accountable if an agent's answer is wrong, and what gets logged, these questions are usually answered reactively after the first incident rather than designed in before go-live.

IT and the business disagree on what 'ready' means

IT measures readiness in uptime and access; the business measures it in whether the answer was actually useful. Without a shared readiness scorecard, the same pilot result gets read as a success by one side and a failure by the other.

Where AI earns its place in SAP

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Master data cleanup sprint

A targeted cleanup of the item master, customer master, and supplier master fields that the first AI use case will actually query.

Touches: Item master, customer master, vendor master tables and their duplicate-detection reports

Outcome: Two to four weeks of focused cleanup on the fields in scope is usually enough to move a use case from 'not ready' to 'pilot ready', versus a multi-month enterprise-wide data governance program.

Role-based access mapping for AI

Documenting which ERP roles a natural-language query tool should inherit, so a warehouse clerk and a controller get different answers to the same question.

Touches: Existing ERP role and permission tables, security groups, row-level security rules

Outcome: Reusing the ERP's own role model for the AI layer avoids building a second, parallel permission system that inevitably drifts out of sync.

Read-replica provisioning

Standing up a read-only replica or reporting database so AI queries never touch the production OLTP instance directly.

Touches: Database replication configuration, reporting schema, ION Data Lake or equivalent extract layer

Outcome: This single infrastructure decision removes most of the DBA's legitimate performance and stability objections to an AI query layer.

GPU and model sizing exercise

Estimating concurrent user load and response-time targets, then sizing GPU memory and count against an open-weight model of appropriate size.

Touches: Expected concurrent users, target response latency, chosen model parameter count (7B-70B class typical for this use case)

Outcome: Right-sizing before the pilot avoids both the false negative of a slow, under-provisioned demo and the wasted capex of buying enterprise-scale hardware for a 15-person pilot.

Write-back approval workflow design

Defining exactly which ERP fields an agent may propose changes to, and the human approval step required before any write commits.

Touches: Target transaction screens or APIs (PO update, task reassignment, due-date change), existing approval matrix

Outcome: A documented approval gate, built once, becomes the reusable governance pattern for every future agent use case rather than a one-off decision per project.

Documentation and semantic mapping

Capturing what each custom field and non-obvious business rule actually means, in a form an AI grounding layer can use.

Touches: Custom fields, user exits, BAdIs, custom IDOs, and whatever tribal documentation currently exists

Outcome: This is usually the single highest-leverage readiness activity: answer accuracy on customization-heavy questions tracks directly with how complete this mapping is.

Audit logging baseline

Confirming that every AI-initiated query and any proposed write is logged with enough detail to reconstruct what happened and why.

Touches: Existing ERP audit/change-log tables, new AI interaction logs

Outcome: Establishing this before the pilot, not after an auditor asks for it, saves a retrofit project and gives compliance teams something concrete to review.

Reference architecture

A readiness assessment maps directly onto the layers of the eventual architecture: you are checking whether each layer has what it needs before building it out, connectors, semantic mapping, model serving, retrieval and agents, and governance.

1
ERP connectors
Confirm which official APIs (ION API/BOD, OData, CDS views, SuiteQL, AIS/Orchestrator) actually expose the data your target use cases need, and where a read-replica database connection will be required instead.
2
Data and semantic layer
Assess master data quality in the fields your first use cases touch, and inventory what documentation exists for custom fields and business rules.
3
Model serving
Size GPU memory and count against your expected concurrent users and chosen model class, and decide whether this runs on-prem, in a private cloud tenant, or hybrid.
4
Retrieval and agents
Identify which use cases are read-only question answering (lower risk, faster to greenlight) versus agent actions that write back (higher risk, need the approval workflow designed first).
5
Governance and audit
Confirm a logging and approval framework exists or can be stood up before go-live, not retrofitted after the first incident or audit finding.

Integration notes for your ERP team

Start the assessment with the two or three use cases you actually want to run first, not a full ERP-wide audit; readiness is use-case specific, and a full audit burns weeks without moving any pilot forward.
Pull a sample export of the master data fields your first use case touches and run a basic duplicate and null-rate check before assuming quality is fine; this takes a day and surfaces most problems immediately.
Confirm with your DBA or Basis/ION team whether a read replica or reporting database already exists; if not, provisioning one is usually the single longest lead-time item in the readiness process.
Get a written answer from security on whether direct database read access is acceptable for reporting-only queries, versus API-only access, before designing the connector layer around an assumption that turns out to be wrong.
Inventory existing documentation for custom fields and non-standard workflows, even informal wiki pages or tribal knowledge in someone's head; this becomes the seed for the semantic layer and is faster to capture now than to reverse-engineer later.
Decide on paper, before the pilot starts, which actions an agent may propose versus execute automatically; this single decision heads off most of the governance debate that otherwise happens mid-project.
Treat GPU sizing as a range, not a fixed number, based on a pilot-scale user count first, then revisit sizing before production rollout once real usage patterns are known.

Deployment options

Air-gapped on-prem

Regulated data (ITAR, CUI) or sites with no reliable path to any external cloud

Readiness here additionally requires confirming GPU hardware can physically be procured and installed inside the enclave, and that model updates can be applied via an approved offline process.

Private or sovereign cloud

Organizations that need elastic capacity or multi-site access without owning hardware

Readiness here shifts toward confirming the cloud region and contractual terms satisfy data residency requirements, and that network latency to the ERP is acceptable.

Hybrid

Multi-site organizations with a mix of regulated and unregulated data

Readiness assessment should be run per site or per ERP instance, since a single organization can be simultaneously ready for cloud at one plant and only ready for on-prem at another.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

ITAR / EAR

Readiness includes confirming which ERP fields and documents contain controlled technical data, so the retrieval index can exclude or wall off that content until an air-gapped deployment is in place.

CMMC 2.0 / NIST SP 800-171

Readiness includes confirming the AI system's intended scope sits inside, or can be added cleanly to, your existing System Security Plan and enclave boundary rather than creating a new unscoped asset.

GDPR

For EU personal data touched by AI queries (employee, customer contact data), readiness includes confirming a lawful basis and, where required, a data protection impact assessment before the pilot processes real records.

SOC 2 / internal audit

Readiness includes confirming logging captures enough detail, who asked what, what data was retrieved, what was proposed, who approved it, to satisfy an internal or customer audit without a retrofit.

Where Netray fits

ERPray

The readiness dimensions above (connectors, role-based access, read-only default, audit logging) map directly onto how ERPray is designed to be deployed, so a readiness assessment naturally produces the ERPray configuration plan if that is the chosen path.

Custom build

Where readiness reveals a need for deep customization mapping or multi-source retrieval beyond a single ERP, a scoped custom build is the natural next step after the assessment.

How an engagement runs

Phase 1 . 1-2 weeks

Discovery

-Use case shortlist scored for readiness
-Master data sample quality check on in-scope fields
-Access and connector options review with IT/security
-Draft governance and approval policy for review

Phase 2 . 6-8 weeks

Pilot

-Read replica or approved API connection provisioned
-Cleaned data for the in-scope fields
-Working prototype against the top-scored use case
-Sized GPU/infrastructure recommendation for pilot scale

Phase 3 . 8-12 weeks

Production

-Approval workflow implemented and tested
-Audit logging validated against compliance requirements
-Infrastructure resized for production concurrency
-Runbook and role-based access finalized

Phase 4 . Ongoing

Scale

-Readiness reassessment for each new use case or ERP added
-Data quality monitoring dashboard
-Quarterly governance review
-Capacity planning tied to actual adoption growth

Questions to ask any vendor, including us

A short list that separates real SAP AI work from a chatbot demo.

What is the null and duplicate rate on the specific master data fields our first use case needs?
Do we already have a read replica or reporting database, or does one need to be provisioned first?
Which ERP fields and documents contain export-controlled or otherwise restricted data that must be excluded or walled off?
Who signs off on an AI agent's proposed write, and is that decision documented anywhere today?
What concurrent user count and response-time target should the pilot infrastructure be sized against?
What documentation exists today for our custom fields and non-standard workflows, and who maintains it?
What does our audit or compliance team need logged before they will sign off on a production rollout?

Frequently asked questions

How long does an ERP AI readiness assessment take?

A focused assessment against two or three specific use cases typically takes one to two weeks: a data sample check, an access and connector review with IT and security, and a governance policy draft. A full ERP-wide audit takes much longer and usually is not necessary before a first pilot.

Do we need perfect master data before starting?

No. You need the specific fields your first use case touches to be clean enough that an answer built on them is trustworthy. A targeted two to four week cleanup on those fields is usually enough; enterprise-wide data governance can happen in parallel, not as a prerequisite.

Can we assess readiness without buying any AI software first?

Yes, and this is the recommended order. Readiness assessment, data sampling, access review, governance draft, requires no AI platform purchase and should happen before committing to a specific model, vendor, or build approach.

What is the most common readiness gap you see?

Missing or informal documentation of custom fields and non-standard workflows. Data quality problems are usually visible and get attention; undocumented customizations are invisible until an AI answer is confidently wrong because it did not know a field meant something different at your company.

Does readiness differ between SAP, Infor, Oracle, and Dynamics?

The specific APIs and tables differ, ION versus OData versus SuiteQL versus AIS, but the four readiness dimensions, data quality, access, infrastructure sizing, governance, are the same regardless of which ERP you run.

Should IT or the business own the readiness assessment?

Both need to be in the room. IT owns the access, infrastructure, and connector questions; the business owns whether the in-scope data and use case are actually valuable and whether the governance policy reflects how decisions are really made.

What happens if the assessment finds we are not ready?

A good assessment does not produce a simple pass or fail, it produces a prioritized backlog: which use cases are ready now, which need a specific fix first (data cleanup, replica provisioning, a governance decision), and roughly how long each fix takes.

Related guides

90-day ERP AI pilot

A 90-Day ERP AI Pilot Plan With Real Success Criteria

A week-by-week 90-day plan for piloting AI on your ERP, with defined success criteria for each phase so the pilot ends in a clear go or no-go decision.

ERP AI business case

Building the ROI Business Case for ERP AI in Manufacturing

How to build a defensible ERP AI business case: benefit mechanisms instead of vague productivity claims, cost structure, payback period, and sensitivity analysis.

ERP AI Buyer Guide

How to Choose an ERP AI Implementation Partner

A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.

RAG + SQL + permissions

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

ERP migration + on-prem AI

AI-assisted data migration for ERP implementations

AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.

Agents + approval gates

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows SAP

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides