# Is Your ERP Ready for AI? A Readiness Assessment Checklist > Source: https://netray.co/erp-ai/erp-ai-readiness-assessment > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## 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. ## Kind buyer-guide ## Erp Family multi-erp ## Erp Products - SAP - Infor - Oracle - Microsoft Dynamics - Epicor - IFS - Deltek Costpoint ## Industries - Manufacturing - Aerospace - Defense - Electronics ## Region Global ## Persona CIO ## Eyebrow ERP AI readiness ## Intro 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. ## Pain Points ### Master data quality is worse than anyone admits in the planning meeting **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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. ## Use Cases ### Master data cleanup sprint **Description:** A targeted cleanup of the item master, customer master, and supplier master fields that the first AI use case will actually query. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** Standing up a read-only replica or reporting database so AI queries never touch the production OLTP instance directly. **Erp Objects:** 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 **Description:** Estimating concurrent user load and response-time targets, then sizing GPU memory and count against an open-weight model of appropriate size. **Erp Objects:** 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 **Description:** Defining exactly which ERP fields an agent may propose changes to, and the human approval step required before any write commits. **Erp Objects:** 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 **Description:** Capturing what each custom field and non-obvious business rule actually means, in a form an AI grounding layer can use. **Erp Objects:** 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 **Description:** Confirming that every AI-initiated query and any proposed write is logged with enough detail to reconstruct what happened and why. **Erp Objects:** 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. ## Architecture **Overview:** 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. **Layers:** #### ERP connectors **Detail:** 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. #### Data and semantic layer **Detail:** Assess master data quality in the fields your first use cases touch, and inventory what documentation exists for custom fields and business rules. #### Model serving **Detail:** 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. #### Retrieval and agents **Detail:** 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). #### Governance and audit **Detail:** Confirm a logging and approval framework exists or can be stood up before go-live, not retrofitted after the first incident or audit finding. ## Deployment Options ### Air-gapped on-prem **Fit:** Regulated data (ITAR, CUI) or sites with no reliable path to any external cloud **Detail:** 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 **Fit:** Organizations that need elastic capacity or multi-site access without owning hardware **Detail:** 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 **Fit:** Multi-site organizations with a mix of regulated and unregulated data **Detail:** 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 ### 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. **Framework:** ITAR / EAR ### 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. **Framework:** CMMC 2.0 / NIST SP 800-171 ### 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. **Framework:** GDPR ### 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. **Framework:** SOC 2 / internal audit ## Integration Notes 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. ## Product Fit ### ERPray **Why:** 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 **Why:** 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. ## Engagement ### Discovery **Duration:** 1-2 weeks **Deliverables:** - 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 ### Pilot **Duration:** 6-8 weeks **Deliverables:** - 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 ### Production **Duration:** 8-12 weeks **Deliverables:** - Approval workflow implemented and tested - Audit logging validated against compliance requirements - Infrastructure resized for production concurrency - Runbook and role-based access finalized ### Scale **Duration:** Ongoing **Deliverables:** - Readiness reassessment for each new use case or ERP added - Data quality monitoring dashboard - Quarterly governance review - Capacity planning tied to actual adoption growth ## Buyer Questions - 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? ## Faq ### How long does an ERP AI readiness assessment take? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms ERP AI readiness assessment, ERP data readiness for AI, master data quality AI, GPU sizing for ERP AI, ERP AI governance checklist, on-prem AI readiness ERP, private LLM readiness ERP data, AI readiness checklist manufacturing ERP, ERP role based access AI, data quality ERP AI project, is our ERP ready for AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json