CIO playbook: strategy, budget, org
A CIO's Guide to Sequencing AI on Your Manufacturing ERP
Short answer
A manufacturing CIO adds AI to the ERP by picking one or two high-frequency, low-risk use cases first (exception triage, natural-language reporting), grounding a model in the ERP's own data rather than a generic chatbot, and deciding upfront whether budget, ownership, and governance sit in IT or with the business unit. The sequence matters more than the technology choice: shops that start with a narrow, well-governed pilot reach production faster than shops that run five parallel proofs of concept.
- ERP
- SAP S/4HANA, Infor CloudSuite Industrial, Oracle Fusion Cloud ERP, Epicor Kinetic, Microsoft Dynamics 365
- Industries
- Manufacturing, Aerospace, Defense, Electronics
- Written for
- CIO
Most manufacturing CIOs are past the question of whether to do something with AI, the board or the CEO has already asked for a strategy. The harder question is sequencing: which use case first, how much budget, whether it sits in IT or with operations, and how to avoid the common failure mode of running four or five pilots in parallel that never reach production because nobody owns the decision to graduate one.
The vendor landscape does not make this easier. Every ERP publisher now has its own copilot, every point-solution vendor has an AI feature, and the CIO is left evaluating claims that are hard to compare because they describe different scopes, different data sources, and different deployment models. Meanwhile shadow AI is often already happening, someone on the finance or engineering team is pasting ERP exports into a public chatbot because it is faster than waiting for an approved tool.
The pattern that tends to work is narrow and grounded: pick one or two use cases with clear, measurable value, a well-known frequency of use, and a low blast radius if the AI gets something wrong, natural-language reporting over the ERP or exception triage on purchase orders are common starting points, then build the ERP connector, governance, and approval workflow once, and reuse that foundation for the next use case rather than treating each pilot as a one-off integration.
Sequencing also has to answer an organizational question before a technical one: who owns the AI budget and the decision to move a pilot into production. Leaving that ambiguous is the single most common reason a manufacturer ends up with several stalled proofs of concept and no production system a year later.
What usually gets in the way
The problems we hear most from cio teams running SAP S/4HANA.
Board pressure for an AI strategy without a concrete plan
Leadership wants to hear what the company is doing with AI, and a vague answer or a list of disconnected pilots does not hold up in a board conversation the way a sequenced roadmap does.
Vendor pitches are hard to compare apples to apples
One vendor's copilot means a chat window over a subset of ERP data, another's means a full agent framework, and without a consistent evaluation framework the CIO ends up comparing marketing language instead of capability.
Shadow AI is already happening
Staff are pasting ERP exports, BOMs, or financial data into public AI tools because it is faster than the approved process, creating a data exposure risk the CIO often does not know the scope of.
Budget ownership is unclear
AI spend does not fit neatly into an existing IT capex line or an operations opex line, and without a clear owner, funding decisions stall while the fiscal year moves on.
Pilot fatigue: many proofs of concept, nothing in production
Without a defined graduation criterion and a named owner for the decision, pilots accumulate and none of them convert into a system the business actually relies on day to day.
Where AI earns its place in SAP S/4HANA
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Natural language question answering over ERP dashboards
Lets a plant manager or planner ask a plain-language question about inventory, open orders, or shortages and get an answer grounded in live ERP data, without waiting on a custom report.
Touches: Inventory, open order, and MRP action message tables across the ERP
Outcome: Reduces the volume of one-off report requests landing on the BI team and gives operational staff faster access to the same underlying data.
Purchase order exception triage
Summarizes past-due, price-variance, and quantity-mismatch PO exceptions for a buyer each morning, grounded in live purchasing data.
Touches: Purchase order header/detail, receiving and invoice matching tables
Outcome: A common first production use case because the data is well-structured and the risk of an AI error is low, the buyer still confirms every action.
Quality notification and CAPA drafting
Drafts a first-pass nonconformance or CAPA narrative from inspection and quality module data for a quality engineer to edit.
Touches: Quality notification, inspection lot, and nonconformance tables
Outcome: Speeds up routine documentation without changing who signs off on the disposition.
Shop floor work instruction assistant
Answers an operator's question about a routing step or work instruction in plain language, grounded in the ERP's routing and linked document data.
Touches: Routing/operations tables, linked work instruction and traveler documents
Outcome: Reduces the number of times an operator has to stop and find a supervisor for a routine clarification.
Demand forecast explanation
Explains, in plain language, why a statistical forecast moved for a given item, citing the underlying demand history and any manual overrides.
Touches: Demand history, forecast, and planning parameter tables
Outcome: Gives planners a faster way to sanity-check a forecast change before committing it to the production plan.
AP invoice exception matching
Flags three-way match exceptions between PO, receipt, and invoice, and summarizes the likely cause for the AP clerk to resolve.
Touches: Purchase order, receiving, and AP invoice tables
Outcome: Cuts the manual investigation time on the routine subset of exceptions, leaving the genuinely unusual ones for the clerk's judgment.
Engineering change impact summary
Lists the open jobs, orders, and BOM lines an engineering change affects before it is released, so operations can plan around it.
Touches: Engineering change records, BOM and routing tables, open job/order tables
Outcome: Reduces the number of changes that land on the floor with stale routings, a recurring source of rework.
Reference architecture
The same five-layer pattern applies across the ERPs common in US manufacturing, SAP S/4HANA, Infor CloudSuite Industrial, Oracle Fusion Cloud ERP, Epicor Kinetic, and Dynamics 365, and building it once for the first use case is what makes the second and third use case faster and cheaper.
- 1
ERP connectors
A read-only integration built for the specific ERP in place, reusable across use cases rather than rebuilt per pilot.
- 2
Data / semantic layer
A shared mapping from ERP tables to the business vocabulary staff actually use, built once and extended as new use cases are added.
- 3
Model serving
An open-weight model served on infrastructure the manufacturer controls or a private cloud, sized to the current use case count with headroom for the next two.
- 4
Retrieval and agents
Retrieval-augmented generation for grounded answers, plus narrow task agents added incrementally as each new use case is approved.
- 5
Governance and audit
A single logging, access-control, and approval framework shared across all use cases, so governance is built once, not re-litigated for every pilot.
Integration notes for your ERP team
- Build the ERP connector, semantic layer, and governance framework once around the first use case, and treat every subsequent use case as an incremental addition rather than a new integration project.
- Standardize on a read-only connector pattern per ERP (OData/CDS for SAP, IDO/ODBC for Infor, REST/BAQ for Epicor, data entities/OData for Dynamics 365) so the same pattern serves multiple use cases.
- Mirror existing ERP role-based access in the AI layer from day one, so a use case never grants a user broader visibility than their ERP login already allows.
- Log every query and every AI-suggested action with the requesting user, and require human approval before any write-back to the ERP, across all use cases without exception.
- Set a graduation criterion before starting a pilot, a specific accept rate, time saved, or error rate threshold, so there is a defined moment to decide production or retire, rather than an open-ended pilot.
- Name a single budget and decision owner for the AI program before the first pilot starts, whether that is the CIO, a joint IT/operations steering committee, or a named business sponsor.
Deployment options
Air-gapped on-prem
Manufacturers with defense-adjacent programs, ITAR data, or a policy of keeping ERP data off any external network
Model and connector run entirely inside the plant network, appropriate when even the first pilot's data includes anything ITAR-controlled or contractually restricted.
Private / sovereign cloud
Manufacturers without hard air-gap requirements who want to avoid owning GPU infrastructure directly
A single-tenant deployment under the manufacturer's control, a common starting point for a first pilot when the data involved is sensitive but not classified or ITAR-controlled.
Hybrid
Multi-site manufacturers with mixed program sensitivity across plants
Sensitive programs or sites run on-prem, while lower-sensitivity sites or use cases run in a private cloud, under one shared governance framework.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
CMMC 2.0
Where any plant or business unit holds DoD subcontracts requiring CMMC, the AI deployment for that unit is scoped inside the assessed enclave rather than built as a separate system.
ITAR / EAR export control
Technical data subject to export control stays on infrastructure the manufacturer controls, avoiding deemed-export exposure from routing it through a public model API.
State and sector data privacy requirements
Employee and customer data referenced by AI use cases (HR-adjacent queries, customer order data) is handled under the same access controls and retention rules already applied to that data in the ERP.
Internal AI governance (aligned to NIST AI RMF)
A lightweight internal governance framework, an AI steering committee, a use case intake and approval process, gives the board a concrete answer to strategy questions and gives IT a repeatable way to say yes or no to new requests.
Where Netray fits
ERPray
Question-answering, dashboards, and narrow agents work the same way across SAP, Infor, Oracle, Epicor, and Dynamics 365, which fits a CIO building one shared AI foundation across a multi-ERP manufacturing footprint.
DataRay
Where the highest-value first use case spans the ERP plus a separate MES, quality system, or document store, DataRay's cross-source chat is a better starting point than an ERP-only tool.
Custom build
Once the foundation is in place, specific agents (a particular exception workflow, a specific narrative-drafting task) are usually built as bespoke additions on top of it.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -Use case inventory scored by value, frequency, and risk
- -Current shadow AI exposure assessment
- -Draft AI steering committee charter and budget ownership recommendation
Phase 2 . 6-8 weeks
Pilot
- -One use case live with the shared connector and governance foundation
- -Defined graduation criteria tracked against actual usage
- -Steering committee review of pilot results before scale decision
Phase 3 . 4-6 weeks
Production
- -First use case in daily production use with logging and approval workflow
- -Second use case scoped and added to the shared foundation
- -Budget model (capex vs opex) finalized for ongoing operation
Phase 4 . Ongoing
Scale
- -Use case intake process for new requests across business units
- -Quarterly steering committee review of production use cases
- -Rollout to additional plants or business units on the shared foundation
Questions to ask any vendor, including us
A short list that separates real SAP S/4HANA AI work from a chatbot demo.
- What specific use case are we solving first, and what is the measurable criterion for calling the pilot a success?
- Who owns the AI budget line, and who has authority to move a pilot into production?
- Does this vendor's offering reuse our existing ERP connector and governance work for the next use case, or is each use case a fresh integration?
- Where does the model run, and what is our position on ITAR or CUI data reaching it?
- How do we prevent shadow AI use while an approved tool is still being piloted?
- What does role-based access look like in the AI layer compared to our existing ERP security?
- What is the real cost to extend this from one plant or use case to five?
- If we stop the engagement after the pilot, what do we own and what reverts to the vendor?
Frequently asked questions
Should our AI budget sit in IT or in operations?
There is no universally right answer, but the budget and the decision authority need to sit in the same place, whether that is IT, a joint steering committee, or a named operations sponsor. The common failure is splitting funding from decision authority, which is what produces stalled pilots with no one able to say yes to production.
How do we stop shadow AI while we build an approved tool?
Publish a clear, short policy on what data cannot go into public AI tools, and give staff a faster approved alternative as quickly as possible, since policy alone rarely changes behavior when the unapproved option is faster. A narrow first pilot that ships quickly does more to curb shadow AI than a policy memo.
What is a realistic first 90 days?
Discovery and use case selection in the first two to three weeks, a working pilot on one narrow use case by week eight to ten, and a go or no-go decision on production by day ninety, based on a graduation criterion defined before the pilot started.
Should we pick our ERP vendor's built-in copilot or a separate tool?
It depends on whether the built-in copilot's deployment model matches your data sensitivity requirements and whether it can be extended to use cases beyond what the vendor shipped; for many manufacturers with ITAR or CUI-adjacent data, a separately deployed private model ends up being the more flexible and more clearly compliant option.
How many use cases should we run at once?
One, sometimes two, at the pilot stage. Running four or five in parallel with no shared foundation is the most common reason manufacturers end up with several stalled proofs of concept and nothing in production a year later.
Does this require replacing our ERP or upgrading it first?
No, the connector pattern is built for the ERP as it exists today, on-prem or cloud, current version or an older one still in support, so an ERP upgrade is not a prerequisite for a first AI pilot.
What does the board actually want to hear?
A specific sequence, not a technology list: which use case is live, what it measurably improved, and what is next, which is a stronger answer than a description of every AI tool the company has evaluated.
Related guides
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.
90-day ERP AI pilotA 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.
Vendor copilots vs private AIBuild vs Buy: Should You Use Your ERP Vendor's AI Copilot, or Build Your Own?
SAP Joule, Copilot for D365, Infor GenAI, Oracle AI Agent Studio, or a private LLM on your own data. A CIO framework for the build vs buy decision, with real trade-offs.
ERP AI business caseBuilding 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 readinessIs Your ERP Ready for AI? A Readiness Assessment Checklist
Is your ERP actually ready for AI? A practical checklist covering master data quality, access and permissions, GPU sizing, and governance before you fund a pilot.
On-prem AI, any ERP, A&DOn-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing
A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.
Plan it with numbers
AI Roadmap Priority Scorer
Score a candidate AI initiative on business value, feasibility, data readiness, and risk to get a single weighted priority number for roadmap sequencing.
Free ToolAI Vendor Evaluation Checklist
A structured checklist for evaluating AI vendors across technical fit, data security and compliance, commercial terms, viability, and implementation support.
Free ToolManufacturing AI Readiness Assessment
Score your manufacturing operation's readiness for AI across data, systems, people, and governance, and get a prioritized roadmap for closing the gaps.
GuideThe 90-Day AI Roadmap for Manufacturers
A 90-day AI roadmap for manufacturers: week-by-week plan from first pilot to production AI agents inside your ERP, with milestones and budget guidance.
GuideAI Strategy for the Mid-Market Manufacturer
AI strategy for the mid-market manufacturer: how $20M-$500M firms compete with AI without enterprise budgets, staff, or multi-year transformations.
GuideThe CFO Guide to AI ROI in Manufacturing
A practical CFO guide to AI ROI in manufacturing: payback benchmarks, cost models, and how to separate real returns from vendor hype before you sign.
Talk it through with an engineer who knows SAP S/4HANA
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.