An AI pilot that never reaches production produces learning, but no business value. The six-week plan below is the structure our teams use to keep ERP AI pilots accountable: every week has a defined output and a decision point. Six weeks is a planning target for a focused use case, not a guarantee. Some use cases reach production inside that window; others show in week 2 that they need a longer programme, and finding that out early is part of the design.
How do you take an AI pilot in ERP to production in six weeks?
To take an AI pilot in Oracle ERP to production in about six weeks, plan the work as six gated stages: agree the KPI and its owner, test feasibility, build a working prototype on real data, evaluate it against written acceptance criteria, integrate it into Fusion with logging and monitoring, and then measure and tune it weekly.
The timeline is only realistic when the use case is narrow, such as one process in one business unit, when the data it needs already exists in Fusion or a connected system, and when a named business owner can make decisions quickly. Each stage ends with a go or no-go decision, so a use case that is not viable is stopped or re-scoped early instead of consuming the full budget. Treat six weeks as the target you plan against; the week 2 feasibility review is where you confirm or revise it.
| Week | Focus | Output | Decision |
|---|---|---|---|
| 1 | KPI discovery | Named metric, baseline, and business owner | Start, or stop until a metric and owner exist |
| 2 | Feasibility | Data audit, model choice, guardrail design, cost envelope | Six-week pilot or longer programme |
| 3 | Prototype | Working prototype on real data with a small user group | Proceed to formal evaluation |
| 4 | Evaluation | Accuracy, safety, and cost results against acceptance criteria | Pass, fix, or stop |
| 5 | Productionise | Integration, logging, observability, and user rollout | Go-live approval |
| 6 | Measure and iterate | Weekly KPI tracking and tuning | Scale, adjust, or retire |
Week 1: KPI discovery
Pin down the metric. Pin down the owner. If you cannot name both, you are not ready to start. The metric should be a business measure that already matters to the process owner, for example invoices processed per person, days to close, or first-contact resolution for employee queries, and it needs a baseline taken before any AI is introduced.
- Write down the current value of the KPI and how it is measured.
- Name one accountable business owner and one technical lead.
- Define the target and the minimum improvement that would justify production.
- Agree which users, process steps, and records are in scope, and which are explicitly out.
Week 2: Feasibility
Week 2 covers four checks: a data audit, model selection, guardrails design, and a cost envelope. By the end of week 2 you should know whether this is a six-week pilot or a longer programme.
Data audit
Confirm that the data the use case needs exists, is accessible through supported interfaces, and is of usable quality. For document or knowledge use cases, confirm the source documents are current and have owners. If key data has to be built first, the use case is a longer programme.
Model selection and guardrails design
Decide whether an embedded Fusion AI capability covers the use case or whether a custom solution is needed, for example on OCI Generative AI. Embedded features are usually faster to productionise because they sit inside existing Fusion security and workflows. Design guardrails at the same time: what the AI may and may not do, which actions need human approval, and how sensitive data is protected. OCI Generative AI, for example, documents configurable guardrails for content moderation, prompt injection detection, and detection of personally identifiable information.
Cost envelope
Estimate run costs at expected volumes, including model usage, integration, and support effort, and set a ceiling. A use case whose cost per transaction exceeds the value it creates should be stopped here.
Week 3: Prototype
Build a working prototype against real data, tested with a small user set. Not a slide deck or a recorded demo: something the users can operate on their own transactions. Use a non-production environment with a representative sample of real records, and gather structured feedback from the users who will own the process.
Keep the prototype deliberately plain. The aim is to test whether the AI output is accurate and useful in the real workflow, not to finish the user interface. Record every case where a user corrected or rejected the output, because that log becomes the test set for week 4 and the starting point for tuning in week 6.
Week 4: Evaluation
Run accuracy, safety, and cost evaluations against the acceptance criteria agreed in weeks 1 and 2. If the prototype does not pass, stop it now rather than after another four weeks of polishing. Stopping is a valid and useful outcome.
- Accuracy: measured on a held-out set of real cases, with results reviewed by the process owner.
- Safety: tests for incorrect or unsupported answers, prompt injection, exposure of sensitive data, and actions outside the user's role.
- Cost: actual cost per transaction compared with the week 2 envelope.
- Usability: whether users completed tasks faster, and where they overrode the AI.
Week 5: Productionise
Integrate the solution into Fusion, Oracle Integration (OIC), or Oracle Analytics Cloud (OAC) as the use case requires, wire up logging and observability, and roll out to the target users. Oracle Integration provides prebuilt adapters and process automation for ERP, HCM, and CX applications, which reduces custom integration work. For agents built in Oracle AI Agent Studio, Oracle describes built-in testing and validation before deployment, monitoring and observability, and human-in-the-loop approval controls.
- Log every AI suggestion, the user's decision, and the outcome, so results are auditable.
- Monitor accuracy, latency, cost, and error rates against thresholds, with alerts to a named owner.
- Keep human approval on actions that post, pay, or change master data until the evaluation evidence supports removing it.
- Prepare user guidance, a support route, and a rollback plan before go-live.
Security review belongs in this week, not after launch. Confirm that the AI feature respects existing Fusion roles and data security, that users only see records they are already entitled to, and that the process owner and internal audit have signed off the controls designed in week 2.
Week 6: Measure and iterate
Track the KPI weekly, tune prompts and policies, and build on what works. AI is never shipped and done: source documents change, data patterns shift, and Oracle updates its cloud applications on a regular cadence. Our teams hold a weekly KPI review for the first eight weeks after launch and a monthly review after that, with each review covering the KPI against baseline, accuracy and exception trends, cost, and user feedback.
A typical outcome at the end of week 6 is one of three decisions: scale the use case to more users or business units, adjust it and run another measurement cycle, or retire it if the KPI has not moved. Each decision should be recorded with the evidence that supports it.
What to watch for
- Scope creep: adding a second process mid-pilot usually breaks the timeline.
- Missing owner: without a business owner, evaluation results have no one to accept them.
- Unrepresentative test data: accuracy on clean samples rarely holds on real transactions.
- Skipping guardrails: controls added after go-live are harder to test and to explain to auditors.
ETHX Softcon's leadership team has more than 15 years of Oracle experience, and the company works with a network of over 120 certified consultants, with a US presence and an offshore delivery centre in Pune, India. We use this plan to scope, build, and support AI use cases on Oracle Fusion.