Author: Vibha Baid

Best Practices for Building on Oracle Visual Builder Studio 

Posted on by Vibha Baid

A practical guide for teams: Git workflow, app design, integrations, security, CI/CD and delivery 

Oracle Visual Builder Studio (VBS) brings a low-code application builder together with Git repositories, CI/CD pipelines and agile project tools in one place. That combination lets a small team go from idea to a running application very quickly. It also makes it easy to build up problems quickly: tangled pages, painful merge conflicts, hard-coded endpoints and deployments that only one person understands. 

This guide collects the practices that make the biggest difference for teams working in VBS. Each section explains what to do, why it matters and what to avoid, with diagrams and tables you can share in team discussions or reviews. 

What this guide covers 

Section Description
1. The building blocks What each part of VBS does and who owns it
2. Project setup How to structure repositories and agree on naming
3. Git workflow Branching, merge requests, reviews and conflict handling
4. Application design Flows, pages, fragments, action chains, variables and types
5. Service connections Reusable, efficient and safe REST integrations
6. Security Roles, secrets, backend enforcement and validation
7. Environments and CI/CD Dev, test and production, plus pipeline stages
8. Testing and performance What to test, how often, and how to keep pages fast
9. Agile and documentation Issues, definition of done, README contents
10. Common mistakes Problems teams hit most often and how to fix them
11. Adoption plan and checklist A 30-day rollout plan and a team checklist

1. Understand the building blocks 

VBS is really several tools sharing one workspace. Knowing which part handles what makes every later decision easier, and helps you assign ownership on the team. 

Area What it does Your main responsibility
Visual Builder Design web and mobile apps with pages, flows, fragments, variables, action chains and service connections Keep the app modular, readable and reusable
Git repositories Store application source and record every change Branch, review and merge safely
Pipelines Build, test and deploy automatically Make releases repeatable and low-risk
Environments Targets such as development, test and production Keep settings separate and promotions controlled
Issues and boards Plan sprints and track tasks and bugs Link every change to a reason

Key idea

Low-code does not mean low-discipline. Speed comes from the visual tools. Reliability comes from the habits around them: version control, review, automation and clear structure.

2. Set up the project for the long term 

A few decisions made before anyone builds a page will save the team a great deal of friction later. 

Organize projects and repositories 

  • One VBS project per product or team. The project holds repositories, issues, pipelines and environments, so keep related work together instead of creating a new project for each small app. 
  • Give each repository one purpose. If you build an application and keep documentation, test scripts or shared configuration, place them in clearly named folders or separate repositories. 
  • Set access deliberately. Decide who can merge to the main branch, who can approve merge requests and who can trigger production deployments. 
  • Keep a short project charter. Two paragraphs describing the app’s purpose, users and owners help new members orient themselves quickly. 

Agree on naming conventions early 

Consistent names make an application readable to someone who did not build it. That person is often you, six months later. 

Item Pattern Examples
Flows Business area, lowercase orders, customers, admin
Pages Subject and purpose order-list, order-detail, customer-edit
Fragments What it displays customer-summary, page-header
Action chains Verb and outcome loadOrders, saveCustomer, showErrorMessage
Variables Noun, camelCase selectedOrder, filterStatus
Service connections System or API name crm-service, inventory-service
Branches Type and topic feature/order-search, fix/date-format
Issues Short outcome statement Users can filter orders by status

3. Make Git the backbone of your workflow 

Visual Builder stores pages and flows as JSON and metadata files. When two people edit the same page on long-lived branches, merges become slow and error-prone. The remedy is simple: small branches, frequent merges and clear ownership. 

Make Git the backbone of your workflow

Figure 1. One task, one branch, one reviewed merge request. 

Branching rules 

  • Never build directly on main. Keep it stable and deployable at all times. 
  • One branch per task. A branch should map to one issue, whether a feature, a bug fix or a small refactor. 
  • Keep branches short-lived. Aim to merge within a few days. A branch open for weeks is a merge conflict waiting to happen. 
  • Bring main into your branch often. Do it at least once a day when others are merging, so conflicts stay small. 
  • Assign work by area. Divide tasks by flow, page or fragment so two people are rarely editing the same file. 

Branching rules

Figure 2. Short-lived branches merged back through reviewed merge requests. 

Write useful commit messages 

Commit history is the story of your application. A good message says what changed and why, in one line, and links to the issue when possible. 

Weak Better
update page Add status filter to order list (issue 142)
fixes Fix date format on invoice page for non-US locales
wip Extract customer summary into shared fragment

Run merge requests as real reviews 

Require at least one reviewer for every merge request. The reviewer should check more than whether the app runs. 

Review area Questions to ask
Readability Are names clear? Are action chains short and focused? Could a new team member follow the logic?
Reuse Is anything duplicated that should be a fragment, module or shared chain?
Data access Does the page request only the fields and rows it needs? Is paging or filtering done on the server?
Security Are secrets absent from the code? Is access enforced on the backend as well as in the UI?
Error handling What does the user see when a service call fails?
Traceability Is the merge request linked to an issue with a clear description?

Handle conflicts calmly 

  1. Bring the latest main into your branch before you start resolving anything. 
  2. Resolve conflicts one file at a time and keep both sides’ intent, not just one side’s text. 
  3. Open the app after resolving and click through the affected pages, because JSON that merges cleanly can still break bindings. 
  4. Ask the other author if you are unsure what their change was meant to do. 

4. Design applications for reuse and clarity 

Visual Builder makes it easy to build quickly and just as easy to build a mess. A little discipline early keeps the application maintainable as it grows. 

Design applications for reuse and clarity

Figure 3. Flows group business areas. Anything used in more than one place moves to the shared layer. 

Use flows, pages and fragments deliberately 

  • Flows represent business areas, such as orders, customers and administration. Each flow has its own pages and can hold its own variables. 
  • Pages should stay focused on one task. If a page tries to do several things, split it. 
  • Fragments hold repeated UI, such as a customer summary card, a page header or a common filter bar. If you copy the same components onto a second page, that is the sign to create a fragment. 

Keep action chains small and clear 

  • Give each chain one job and a name that describes the outcome, for example loadOrders or saveCustomer. 
  • Break long chains into smaller ones that call each other. A chain with dozens of steps is hard to read, debug and review. 
  • Handle the failure path in every chain that calls a service. Show a clear message and stop cleanly. 
  • Use comments or descriptive labels on steps whose purpose is not obvious. 

Centralize shared logic 

Put validation rules, formatting helpers and common calculations in application-level JavaScript modules or shared chains instead of repeating them on each page. When a rule changes, you change it once. 

Scope variables carefully 

Scope Use it for Watch out for
Page Values only one page needs, such as a selected row or form field This is the default. Start here.
Flow Data shared by pages in the same business area Reset values when the user leaves the flow
Application Truly global data, such as the signed-in user or theme Too many become hidden global state that is hard to trace

Define types for your data 

Define types for records and service responses so components, variables and service calls agree on shape. It prevents subtle binding errors and makes pages easier to understand. 

Design for clarity in the interface 

  • Use plain words that users recognize, and keep action names consistent across the app, such as always using Save and Cancel. 
  • Show loading and empty states. A blank area looks like a bug. 
  • Keep pages light. Move rarely used content to separate pages or load it on demand. 

5. Manage service connections properly 

Most real applications sit on top of REST services, whether Oracle Fusion applications, ORDS, or custom APIs. How you connect to them affects security, speed and how easily you can move between environments. 

Do Avoid
Define each connection once and reuse it across pages Hard-coding endpoints inside individual calls
Configure endpoints and credentials per environment Editing URLs by hand before each release
Request only the fields you need Fetching whole records when a page shows three columns
Filter, sort and paginate on the server Loading thousands of rows to filter in the browser
Show a clear message and log details when a call fails Leaving the user with a blank screen
Agree with service owners on versions and changes Discovering breaking changes in production

Common slowdown

Pulling large collections into the browser and filtering there is one of the most common causes of slow applications. Push filtering, sorting and paging to the service, and measure with realistic data volumes.

6. Build security in from day one 

Security added at the end is expensive and incomplete. Treat it as part of the design of every page and every integration. 

Practice Why it matters Avoid
Enforce permissions on the backend service Hidden UI can be bypassed. Server checks cannot. Treating hidden buttons as security
Restrict flows and pages with roles Users see only what they should Giving everyone access to every page
Use credential and secret features Keeps secrets out of source control Committing passwords, tokens or API keys
Validate input on client and server Client checks help users, server checks protect data Trusting client-side validation alone
Review who can deploy to production Limits accidental or unauthorized changes Open access to production pipelines

Also review access regularly. People change teams, and permissions granted for a project often outlive the need for them. 

7. Automate delivery with environments and pipelines 

The DevOps side of VBS is where teams gain the most reliability. Manual deployments depend on one person’s memory. Pipelines turn the process into something anyone can run and everyone can trust. 

Automate delivery with environments and pipelines

Figure 4. Build once, run checks, then promote the same artifact through each environment. 

Use separate environments 

Environment Purpose Typical users
Development Try changes quickly and break things safely Developers
Test Verify features and regressions with realistic data Testers, reviewers, product owners
Production Serve real users End users

Design the pipeline in stages 

Stage What happens Fails the run when
Build Package the application once The build cannot complete
Checks Run automated tests and code quality checks Any required check fails
Deploy to dev Publish to the development environment Deployment errors occur
Deploy to test Publish the same artifact for verification Smoke tests fail
Deploy to production Release with approval Approval is withheld or a health check fails

Release practices that reduce risk 

  • Promote the same artifact. Build once and promote that artifact so what you tested is exactly what you release. 
  • Gate merges on pipeline results. A broken main slows the whole team, so require a passing build before merging. 
  • Require approval for production. A quick sign-off from a second person catches many mistakes. 
  • Keep a rollback plan. Know how to return to the previous version before you need to. 
  • Release small and often. Small releases are easier to test and easier to undo. 
  • Keep deployment repeatable. Anyone on the team should be able to trigger it and get the same result. 

8. Test and watch performance 

Type What to check When
Manual walkthrough Key user journeys from start to finish, including error cases Before every release
Automated UI or API tests The most important paths, run repeatedly with the same result In the pipeline on every change
Cross-browser and device checks Layout and behavior on supported browsers and screen sizes Before release and after major UI changes
Performance checks Page load, service response times and behavior with realistic data volumes Regularly, and whenever data grows
Access checks That each role sees only the pages and data intended When roles or pages change

Performance habits 

  • Watch the browser console and network tab while developing. Errors, failed calls and slow requests show up there first. 
  • Use pagination and lazy loading for large lists. 
  • Avoid calling the same service several times on one page when one call would do. 
  • Test with production-sized data, not just a handful of sample records. 
  • Remove unused pages, variables and connections regularly. Dead code confuses newcomers and hides real problems. 

9. Track work and document as you go 

Use issues and boards 

Every task and bug should exist as an issue, linked to its branch and merge request. That gives you a history of what changed and why and lets the team see progress on the board without status meetings. 

A useful issue contains 

  • A short outcome statement, such as: Users can filter orders by status. 
  • Acceptance criteria that can be checked. 
  • Any linked designs, service details or dependencies. 

Agree on a definition of done 

A task is done when…
The change is merged through a reviewed merge request linked to its issue
The pipeline has passed, including automated checks
It has been verified in the test environment
Any new service connection, role or setting is documented
The README or release notes reflect the change

Keep a README for every application 

Section Contents
Purpose What the app does and who uses it
Structure Main flows, shared fragments and modules
Connections Services used and who owns them
Environments What differs between development, test and production
Deployment How to release and how to roll back
Contacts Who to ask about the app, its services and its data

Ten minutes of writing saves hours of onboarding. 

10. Common mistakes and how to fix them 

Mistake Effect Fix
Building directly on main Unreviewed changes and broken releases Branch per task and require merge requests
Long-lived branches Large, painful merges Merge within days and sync often
Copying components between pages Fixes must be repeated everywhere Create fragments and shared modules
Very long action chains Hard to debug or review Split into small, named chains
Too many application-level variables Hidden state and unexpected behavior Use the narrowest scope that works
Hard-coded endpoints and credentials Risky releases and leaked secrets Configure per environment and use secret features
Filtering in the browser Slow pages with large data Filter and paginate on the server
Rebuilding for each environment Untested code reaches production Promote one artifact through all environments
Skipping documentation Knowledge lives in one person’s head Keep a README and definition of done

Final thoughts 

The theme running through all of this is that fast tools reward steady habits. Visual Builder Studio speeds up development, but version control discipline, modular design, secure and efficient integrations and automated delivery decide whether a project stays healthy as it grows. Start with a few practices, make them routine and add more as the team gains confidence. Done well, your team can move quickly without breaking things. 

Why Are You Still Paying Invoices Twice in Oracle Fusion?

Posted on by Vibha Baid

A single supplier invoice paid twice on a multi-million-dollar AP run rarely looks dramatic on its own. Scale that pattern across a few dozen vendors, a handful of maverick channels, and one busy close cycle, and you are staring at six-figure leakage that never appears as a clean line item on the board pack. 

Duplicate invoice payments usually come from fragmented visibility inside live Oracle Fusion deployments. When you treat spend management as a measurable outcome discipline rather than another software layer, finance teams can catch the same bill before it clears twice and turn that leakage into documented savings. 

You already run Oracle Fusion Applications. The data sits there. Yet the same supplier invoice still slips through multiple times because no single governed view connects request, receipt, and payment across every channel. The result shows up in your DPO numbers, audit findings, and the hours your team spends chasing corrections instead of closing the books. 

This article walks through the full spend lifecycle, the root causes that create duplicate payments, the real cost to the business, and the practical steps you can take inside your existing system. The goal is simple: turn hidden leakage into tracked value you can defend at the board. 

What spend management actually covers?

Spend management governs the entire request-to-pay lifecycle. It starts with intake and ends with post-payment analysis. Expense tracking only records what employees already spent and then reimburses them. Procurement systems often stay in their own silo. The gap between those two leaves room for the same invoice to be approved and paid more than once. 

Think of it this way. Expense tracking is the receipt drawer. Spend management is the full kitchen: who ordered, what was approved, what arrived, what was billed, what was paid, and whether any of those steps repeated by accident. If you only watch the drawer, you will never see the second payment leave the account. 

The full process runs from initial request through sourcing, ordering, receiving, invoicing, payment, and ongoing analysis. Oracle Fusion already captures much of this data across Payables, Procurement, Receiving, and related modules. The issue is not missing information. It is the lack of a single, governed flow that flags duplicates before money leaves the account. 

Gartner’s definition of spend analytics solutions centers on cleansing, normalizing, enriching, and visualizing spend data so teams can see spend outside standard processes and spot savings opportunities. That framing matches what Oracle Fusion customers already hold in the system: the raw transactions exist, but without a disciplined view they do not protect you from paying twice. 

Three categories of spend matter for duplicate risk: 

  • Direct spend: materials and services tied to core delivery, usually under stronger PO and receipt controls 
  • Indirect spend: facilities, professional services, software, travel-adjacent costs, and other operating purchases that often bypass tight matching 
  • Maverick spend: purchases that skip preferred suppliers, contracts, or approval paths entirely 

Indirect spend and maverick purchases hide the most duplicates because they bypass standard controls. When a manager approves an invoice outside the central process, the system has no reliable record of the prior payment. A supplier resubmits a slightly altered invoice number. A shared-services clerk keys the same bill into two business units. Visibility gaps create the exact conditions that let one invoice become two payments. 

So what should you demand from spend management inside Oracle Fusion? Not a new dashboard for its own sake. A governed lifecycle that answers, for every dollar leaving the company: who requested it, what policy applied, what was received, whether the invoice already exists, and whether payment should stop. 

Why duplicate payments keep happening in Oracle environments 

Duplicate payments rarely start with fraud. They start with incomplete sightlines. Finance leaders often cannot see every channel where a supplier can submit, resubmit, or re-route a bill. Without that view, duplicate checks fail at the exact moment they matter: before the payment batch runs. 

Maverick spend and manual approval bottlenecks make the problem worse. When approvals route through email, chat threads, or spreadsheets, the three-way match never happens in real time. A PO exists in one module. A receipt sits in another. The invoice arrives through a shared mailbox. Nobody owns the cross-check, so the same amount clears twice under slightly different references. 

Ineffective configuration is another common driver. Post-go-live Oracle Fusion setups often remain tuned for transaction recording rather than duplicate prevention. Matching rules stay loose so the business can “keep moving.” Supplier master data carries duplicates or near-duplicates. Invoice holds fire too late, or not at all, when amount, date, and supplier patterns should have stopped the run. 

Pre-approved manager verification processes add another layer of risk. A manager signs off on an invoice that already cleared weeks earlier because the system never cross-checked the supplier, amount, and date against prior payments. The human step feels like control. In practice it becomes a rubber stamp when the person approving has no clean list of what already paid. 

Sounds familiar? Many Oracle Fusion programs hit this pattern six to eighteen months after go-live. The implementation team optimized for cutover. Controls that would catch duplicates were deferred. Workarounds became permanent. Shared services inherited a process that records spend well and governs it poorly. 

The root condition is structural: 

  1. Multiple intake paths for the same supplier bill 
  2. Incomplete or inconsistent supplier and invoice identifiers 
  3. Matching rules that prioritize speed over first-time accuracy 
  4. Approvals disconnected from prior-payment history 
  5. No owner for Spend Leakage Control as a board-level KPI 

Fix the structure and the duplicates drop. Add another disconnected tool on top of the same structure and they usually do not. 

The real cost of paying invoices twice 

The cost of a duplicate payment is larger than the second check. You lose the cash twice, then you lose the life-hours spent finding it, recovering it, explaining it to audit, and rebuilding trust with the supplier who may already have applied the extra funds to a different open item. 

Translate that into Oracle Fusion-relevant KPIs and the board conversation changes. Weak first-time match rates stretch exception queues and slow Close Cycle Reduction. DSO/DPO Optimization suffers when AP is buried in cleanup instead of optimizing working capital deliberately. Audit Readiness erodes when samples keep surfacing the same control failure. Supplier Performance Index scores get noisy because billing disputes mix real performance issues with your own process gaps. 

Consider a simple internal baseline exercise. Pull a recent quarter of paid invoices. Flag exact and near matches on supplier, amount, date window, and PO reference. Even a modest duplicate rate compounds fast across high-volume categories: facilities, contingent labor, logistics surcharges, marketing services, and recurring software invoices. The leakage rarely sits in one dramatic fraud case. It sits in dozens of “small” repeats that nobody owned. 

There is also opportunity cost. Every hour your AP and procurement teams spend reconciling double payments is an hour not spent on Strategic Spend Control, contract compliance, or supplier consolidation. That is the life-hours problem in miniature. Money left the company. Time left with it. Neither shows up cleanly as “duplicate invoice line” on the P&L. 

Senior leaders already feel pressure on corporate spending levels. When the story you bring them is only “we need another module,” the conversation stalls. When the story is “here is our current leakage baseline, here is the first-time match gap, and here is the recoverable value inside Oracle Fusion,” you get airtime. The cost becomes a measurable outcome problem, not a vague process complaint. 

Frame the damage in three layers when you brief the CFO or COO: 

  • Cash leakage: amounts paid more than once, net of recoveries 
  • Process leakage: exception volume, rework hours, and delayed close tasks 
  • Control leakage: audit findings, weak evidence packs, and eroded confidence in AP controls 

High-performing finance teams treat those three as one program. Average teams chase each invoice as a one-off. The difference is not heroics. It is whether spend management is measured like any other operational outcome. 

How effective spend management stops the leakage 

You do not need a new stack to start. You need a sequence. The Business Value Maximization (BVM) model applies four S.E.E.R. phases to spend control: Sense, Evaluate, Execute, and Retrospect. 

In the Sense phase you map every payment channel inside Oracle Fusion and adjacent intake paths. Where can an invoice enter? Which business units bypass central AP? Which suppliers bill multiple legal entities? Which manual journals still touch payables? The output is a plain map of exposure, not a wish list of tools. 

In Evaluate you baseline current duplicate rates, first-time match performance, maverick spend share, and exception aging. Pick a sample window. Document the rules you used so the baseline is defensible. This is where Spend Leakage Control stops being a slogan and becomes a number you can move. 

Execute brings centralised data discipline and automated three-way matching that catches duplicates before payment. Tighten supplier master hygiene. Align invoice matching rules with real risk, not only with historical “keep the queue moving” habits. Route exceptions to owners who can stop a payment, not only comment on it. Supplier performance indexing flags vendors with repeated billing issues. Contract compliance checks reduce off-contract purchases that bypass controls. 

Retrospect measures recovered value against the original baseline. What duplicate rate did you start with? What is it now? How many life-hours left the exception queue? Which controls still fail under volume? That feedback loop is what turns a cleanup project into an operating rhythm. 

Quick wins often sit inside modules you already own: 

  • Enforce consistent supplier identifiers and block obvious master duplicates 
  • Strengthen three-way match thresholds on high-risk categories first 
  • Require PO references on categories where maverick volume is highest 
  • Surface prior-payment warnings in the approval path managers actually use 
  • Report first-time match rate weekly during the first ninety days of the program 

The largest gains still come from process discipline, not from adding another tool. Business Value Maximization (BVM) shows how to sequence these changes so each step produces measurable outcome data. For teams already live on Fusion and stuck in post-go-live drift, Oracle Fusion process optimization work is often the practical path to re-tune matching, approvals, and ownership without a second implementation circus. 

Ask one hard question before you buy anything new: if we fixed master data, matching, and ownership inside Oracle Fusion this quarter, what percentage of our duplicate problem would still remain? If the honest answer is “most of it would shrink,” start there. 

Common misconceptions that keep the problem alive 

Many teams assume more software will close visibility gaps. The data already lives in Oracle Fusion. The missing piece is governed process, not another layer that creates a second version of the truth. Software can help when process owners are clear. It cannot replace them. 

Others treat indirect spend as too small to matter. Indirect and maverick categories together often rival direct spend in volume and carry the highest duplicate risk precisely because controls are looser. The “small” marketing invoice and the “routine” facilities bill are where repeats hide. 

A third misconception holds that existing ERP data is already clean enough for duplicate detection. Post-go-live configurations frequently leave fields incomplete, inconsistently used, or optional in the wrong places. If invoice number formats vary by business unit, if supplier sites multiply without reason, if receipt data is skipped under pressure, your duplicate logic is guessing. 

Finally, some view spend management as a procurement-only task. Finance owns the cash. Procurement owns the supplier relationship. Operations owns the receipt. Shared services owns the queue. If only one of those groups “owns spend,” the invoice still has three other doors to walk through. The outcome discipline must span all of them. 

There is also a commercial misconception worth naming. Traditional time-and-materials consulting can document the problem for months without tying fees to leakage recovered or match rates improved. Outcome-based consulting differs because payment ties to verified results rather than hours logged. That alignment changes what the engagement optimizes for: board-visible KPIs, not slideware. 

If you think that sounds like a process lecture dressed up as strategy, try this frame-flip from quality control on a factory line. Inspectors at the end of the line find defects. Designers who change the line prevent them. Most Oracle Fusion teams are still hiring more inspectors for AP exceptions. Spend management that works redesigns the line: intake, match, approve, pay. 

Clear the misconceptions and the work gets simpler. Keep them and you will keep paying the same invoices twice while debating tool shortlists. 

How to measure whether your spend management is working 

If you cannot measure it inside Oracle Fusion, you do not control it. Start with persona-specific metrics that already map to how executives defend performance. 

CFO-facing metrics 

  • Close Cycle Reduction 
  • DSO/DPO Optimization 
  • Spend Leakage Control 
  • Audit Readiness 
  • Period Close Optimization 

CPO / CSCO / COO-facing metrics 

  • Strategic Spend Control 
  • Supplier Performance Index 
  • Optimized Inventory Turns (where receipt quality affects match rates) 
  • Improved Backordered Rate (where incomplete receipts drive invoice noise) 

Leading indicators for the whole program 

  • First-time invoice match rate 
  • Maverick spend percentage 
  • Duplicate payment rate (exact and near match) 
  • Exception aging and rework hours 
  • Percent of spend on contract 

Baseline before you change anything. Choose a recent, representative period. Define duplicate logic in writing (same supplier, amount tolerance, date window, PO or invoice reference rules). Run the sample. Record the rate and the cash at risk. That baseline is your before picture for Value Demonstration later. 

Then set a short measurement cadence. Weekly first-time match and exception aging during stabilization. Monthly Spend Leakage Control and maverick share for the steering group. Quarterly Audit Readiness evidence packs so you are not inventing a story the week before external audit arrives. 

Connect the numbers to the Value Demonstration phase of Business Value Maximization. The point is not a prettier report. The point is proving that process changes moved a KPI the board already understands. If first-time match rises and duplicate rate falls while close tasks shrink, you have a value story. If dashboards multiply and the KPIs do not move, you have theatre. 

A practical starter checklist: 

  1. Agree owners for each KPI (finance, procurement, shared services) 
  2. Freeze baseline definitions for ninety days so trends are comparable 
  3. Instrument Oracle Fusion reports or OTBI analyses you can rerun without heroics 
  4. Review one high-risk category end-to-end each month (request through payment) 
  5. Retire workarounds that bypass the controls you just measured 

If you are still unsure where your configuration and process maturity sit, pair this measurement plan with a structured self-assessment and a clear modernize path for ERP value realization. Measurement without ownership is just another report. Ownership without measurement is opinion. 

Conclusion 

Duplicate invoice payments are a visibility and process problem that Oracle Fusion customers can turn into measurable savings by applying disciplined spend management inside their existing system. The data is already there. The next step is governed flow, clear ownership, and outcome tracking against KPIs the board already watches. 

Start with a baseline, tighten the match, and measure what changes. If you want a deeper KPI and framework pack for that work, download the Tiny Transformations e-book. For ongoing post-go-live support patterns that keep controls from drifting, explore Oracle Fusion support and managed services. Then book a strategy session to map your current leakage against the same outcome measures and decide what to fix first. 

When Planners Override Oracle Forecasts, Who Measures the Value Lost?

Posted on by Vibha Baid

One planner override on one high-volume SKU can push an extra $180,000 of safety stock into the warehouse. Nobody notices, because nobody checks whether the override beat the forecast it replaced. 

The short answer: manufacturers improve demand planning and inventory visibility in Oracle Fusion by measuring Forecast Value Add, the accuracy each override adds to, or takes from, the statistical baseline. Freeze the baseline, capture the final plan, score both against actual demand. Overrides then stop quietly inflating safety stock, and Optimized Inventory Turns rise while service holds. 

That is the number that turns an override from a habit into a decision. Below: what it is, how you calculate it from data your Oracle Fusion deployment already records, and where a planner sees it and acts on it. 

What is Forecast Value Add? 

Forecast Value Add is the accuracy you gain, or lose, when a planner changes the statistical forecast. 

Two forecasts exist for every item, every cycle. The first is the statistical baseline Oracle Fusion produces. The second is the final plan after human edits. Actual demand arrives later and settles the argument. 

If the final plan landed closer to actual demand than the baseline did, the override added accuracy. If it landed further away, the override added error. Positive value add, an earned exception. Negative value add, an expensive guess. 

That is the whole idea, and it is not a stick to beat planners with. Oracle Demand Management expects planners to adjust the statistical forecast when they hold business intelligence the model cannot see, and often the planner is right. The problem is that most teams never find out which overrides were the right ones. 

So the metric does not ban overrides. It prices them. (And prices, unlike opinions, end meetings.) 

How do you work it out from Oracle Fusion data? 

Four steps, all of them running on data your deployment already records. 

  1. Freeze the baseline. Snapshot the statistical forecast before any human edit, at item and horizon level. If the baseline can drift mid-cycle, nothing downstream is comparable. 
  2. Capture the final plan. Record the consensus forecast that actually released into supply, and who changed it. 
  3. Score both against actuals. When demand lands, measure the error on each forecast using one agreed metric: MAPE or WAPE, whichever your team already argues about. 
  4. Take the difference. Baseline error minus final-plan error is the value add for that item and cycle. Roll it up by planner, by item segment, by horizon. 

Three companion measures make the number readable. Override rate tells you how often the baseline gets touched. Bias tells you whether overrides lean systematically high or low. Accuracy before and after tells you the size of the swing. 

Tie that back to the SKU in the opening. The override that pushed $180,000 into safety stock shows up here as a single row: low baseline error, higher final-plan error, negative value add, one planner, one horizon. Nothing about that row is an accusation. It is simply the first time the cost of that one edit was visible to anybody. 

One caveat worth saying plainly: none of this arrives as a finished Fusion report. The transactions and the forecast versions sit in your Oracle Fusion data. The snapshot discipline, the comparison, and the scorecard are work your planning team or your partner builds on top of that data. 

Where does a planner actually see it? 

A metric nobody opens is wallpaper. Forecast Value Add has to land in three places. 

On a weekly scorecard. Override rate, net value add, and the five items contributing the most absolute error. One page, published to the planning team, not parked in a folder only the centre of excellence can open. 

In the exception list. Set a tolerance band. Overrides on A items that fall outside it get reviewed. A one-unit tweak on a C item does not. Visibility, not bureaucracy. 

In the S&OP meeting, as the opening question. Not “what is the number?”, which invites negotiation. “What was the value add of last cycle’s overrides?”, which invites evidence. Planners who added accuracy explain their method. A pattern of negative value add triggers a look at the inputs, not at the person. 

Then keep the reason attached to the record. Require a short coded reason on material overrides (promotion, customer intelligence, supply constraint, one-off event) in Oracle’s planner notes, not in somebody’s inbox. When a promotion override keeps adding value, that signal belongs in your governed inputs rather than in a heroic edit five minutes before the freeze. 

Expect friction for two or three cycles. People who used to win arguments with volume have to start winning them with evidence. 

Why do planners override in the first place? 

Because the process, not the planner, made overriding the rational move. Three conditions do most of the damage. 

The baseline is opaque. The statistical number arrives finished, with no easy way to trace which shipment history or which promotion flag moved it. People trust what they can inspect, and a black box invites a private rewrite. 

Demand intelligence has no front door. Sales, marketing and finance each hold a slice: pipeline shifts, campaign timing, pricing moves, channel mix. With no structured handoff into Oracle Demand Management, that slice stays a hallway conversation and ends as a spreadsheet edit. 

And re-keying is tiring. The more swivel-chair work a planner does, the more likely the plan finishes in Excel (which is where silent overrides are born). Inside an Orbrick engagement, Smart.Assist cuts data entry time by 50 percent, so planner hours go to judgment instead of retyping figures Oracle Fusion already recorded. 

Close those three and the fourth fix comes free. Cleaner, segmented history produces better baselines. Better baselines need fewer overrides. The overrides that survive are the ones that genuinely deserve a human. Not sure which of the three is biting you? An honest read of your own ERP maturity is a seven-minute way to find out. 

How does this reach Optimized Inventory Turns? 

CSCOs do not fund forecast science for its own sake. They fund it because the demand signal sets the inventory posture. 

Safety stock responds to forecast error and bias. When overrides stop injecting error nobody measured, the error band tightens, and the buffer that existed to cover planner disagreement can come down without touching fill rate. 

Order release settles too. Supply planners stop launching early just in case, and stop expediting late when the consensus number whipsaws. Premium freight and hot lists are the shadow P&L of unmeasured overrides. 

The KPI that captures all of it is Optimized Inventory Turns. Excess finished goods and raw buffers release while service holds, so turns rise because the same demand is planned with less protective inventory, not because you starved the network. Working capital follows, and finance reads it in inventory days and cash conversion. 

Business Value Maximization is how we carry a planning metric through to that board metric instead of stopping at “the forecast looks better”. Sense the override gap, evaluate which segments are costing you turns, execute the instrumentation, then retrospect on turns and cash. Teams that want the weekly cycle to hold after the first rebuild usually pair it with structured Oracle Fusion support. 

Conclusion 

Run the test yourself this month. Pull override rate and Forecast Value Add for your top revenue segments, then pull safety stock and turns for the same slices. High override rate, flat value add, fat buffers: that is your post-go-live value leak, and a measured baseline is the cheapest tool you have to close it. 

Download the free Tiny Transformations e-book for the KPI frameworks supply chain leaders use to keep planning metrics tied to turns and cash. Then schedule a strategy session to map the same discipline onto your live Oracle deployment. 

The Invoice Is Only Half the Story: What Oracle’s Payables and Payments Agents Actually Change

Posted on by Vibha Baid

A supplier agrees to 2/10 net 60. In simple terms, you get a 2% discount if you pay within 10 days. If you don’t, you pay the full amount within 60 days.

Now imagine the invoice comes into AP, but the payment terms are captured as Net 30. Maybe the invoice was read incorrectly. Maybe an old default was picked up. Maybe someone entered the terms manually. Nothing looks obviously wrong. The invoice gets approved, goes into the next payment run, and the company pays on day 30.

The invoice was paid. The accounting is correct. No error message appeared. But the company still lost the 2% discount, and it paid 30 days before it had to.

That’s the part of AP automation that often gets missed: a mistake at the beginning of the process can affect a decision much later. That is why I think Oracle’s Payables Agent and Payments Agent are worth looking at together. Most conversations about AP automation start and end with invoice capture, but what happens to that information afterwards matters just as much.

Before the agents: How AP usually worked

On many Fusion projects, AP has looked similar. Invoices arrive in a shared mailbox, some suppliers use the supplier portal, and others send scanned copies through different departments. Then someone has to open each invoice, enter the details, find the PO, check the supplier, fix missing information and deal with exceptions. Meanwhile, payment runs happen on a fixed schedule, often because that is how the process has always been run.

It’s not a user problem. There are simply too many small manual steps, and that is where the new agents start to change things.

Starting at the inbox

The Payables Agent starts with invoice intake. Oracle’s Capture setup lets you define where invoices come from and how they’re grouped into streams. A stream is a flow of documents with something in common, such as the sender, file type or channel. If you run multiple business units, you can also map an email alias to a business unit so invoices that don’t match anything else still land in the right place. From there, Document IO reads each document and maps it into invoice fields, across file types, page counts and languages.

Training has also changed a lot since 26B, when Document IO replaced the older Intelligent Document Recognition. Because it uses large language models, most invoice attributes are picked up automatically, and you only train the few fields it misses. That is usually a one-time job per invoice layout, so start with high-volume suppliers and the ones with messy layouts. For example, complex invoices from suppliers such as Amazon may need additional training when certain fields aren’t being captured correctly. Their layouts didn’t follow a standard format, and some fields weren’t being picked up correctly. Once the training was saved, the agent recognized those fields on every new invoice from the same suppliers, so nobody had to correct them again.

26C went further and added training for descriptive and global descriptive flexfields on PDF and image invoices. That is useful if your company tracks its own invoice attributes or has country-specific fields to capture.

Most teams train in a test environment first, so moving that learning to production is always a question. In 26D you can export and import fingerprint-based training yourself. The import checks the file and warns you before it overwrites existing learning. Read those warnings properly, especially if production already has newer training than test, or you could replace good learning with old test data.

From setup screens to business policies

Instead of building every rule manually through setup screens, Compliance and Control lets you upload business policy documents, and the agent reads them and turns them into rules. Completion policies fill in what’s missing from the invoice, like account combinations, tax determinants and project information. Control policies check invoices against your criteria and against related POs or receipts and flag anything that doesn’t fit for review.

This needs a bit more care than it looks. Some fields can only be filled in when specific criteria are present. A rule that fills in the distribution account, for example, needs Ledger as one of its criteria fields. Leave it out and the rule never matches, so invoices keep coming through with the account blank. It’s an easy one to miss, and it comes up often in real implementations and in community discussions.

26D also moves invoice matching controls into Compliance and Control. Until now, one tolerance at the supplier site or business unit had to cover everything. Say that tolerance is 2%, but medical consumable prices regularly move up to 5%. Every one of those invoices goes on a price hold, and someone releases it without changing anything. With matching controls, you can add a rule for that business unit and purchasing category with a 5% tolerance. An invoice 4% over the PO price gets its hold released automatically. One that is 7% over still waits for review. Your existing tolerances stay in place as the baseline.

What happens when an invoice needs attention

Not every invoice goes straight through, and that is fine. The Streams page tells you quickly whether the problem is with the whole file or just one invoice buried inside it, which matters more than it sounds. I’ve seen teams waste time investigating a “failed” file when only one line item out of twenty had an issue.

The Payables home page helps here too. Instead of opening five screens and filtering each one, you get a prioritized list to start from. And when a document pauses for review, that is not a failure. It’s a control point doing its job, so there’s no need to panic when you see one.

The Invoice List feels more like a conversation than a search form. You ask for what you need in plain language, then act on it directly, whether that is releasing an exception, correcting a value or overriding an anomaly. If an import gets rejected, the correction spreadsheet is still there as a fallback, which is reassuring if you’re used to the old way of working.

The supplier master still matters

AI can read an invoice, but it can only match what your supplier master tells it. The invoice says ABC Trading Ltd, the supplier master says ABC Trading Limited. Or the invoice comes from a different legal entity or email address. Each small difference can create an exception someone has to investigate, and across thousands of invoices that becomes a real workload.

The bigger risk is a wrong match with no exception at all. Payables Agent identifies suppliers using details like name, address and tax registration number. If two suppliers share the same address, an invoice from one could be matched to the other. If no one catches it during review, the payment goes to the wrong supplier’s bank account. Caught before payment, it’s a quick fix. Caught after, someone must chase a refund from the other supplier, reverse the payment and pay the right one again.

Finding the right suppliers for discounts

The Payments Agent also helps you figure out which suppliers are worth approaching for early payment discounts, rather than guessing. You can sort suppliers by how much you spend with them, then narrow that list by things like their payment terms, how often they’ve taken a discount before, how often they’ve missed one, and whether they’ve said yes to an early-payment offer in the past. Once you’ve picked a supplier, the Supplier Offers Assistant drafts the offer, sends it, and keeps track of whether they accept.

On the payment execution side, you can just ask in plain language how a payment file is doing, or why something got rejected. It also flags things worth checking on its own, like a payment that hasn’t reconciled, a card payment that keeps failing, an offer that’s about to expire, or a supplier whose offer email is missing so the offer can’t even go out.

One invoice, end to end

Put together, the two agents make more sense as one AP story.

What Oracle Payables and Payments Agents Actually Change

Controls, approvals and user review stay important across the whole process. People remain in the flow. The system just does more of the routine work before they need to step in.

What needs to be ready before you start

The agents get most of the attention, but the setup underneath them decides how well they work.

  • Supplier and PO data. Names, addresses and PO information should match what appears on invoices. The supplier profile matters on the payment side too: if the offer email address is missing, the system can’t send the offer.
  • Clear business policies. The agent builds rules from your policies, so a vague or conflicting policy produces rules that need more review. Treat generated policies as something to validate, not switch on blindly.
  • Business unit access. A user may reach the Streams page but still be unable to see invoice details if the BU data security isn’t in place. After granting BU access to the custom job role, run Process Permission Group Policies.
  • The Payables Agent has its own duties for document processing, capture, policy configuration, invoice processing and insights. For the Payments Agent, Oracle’s documented setup uses a custom role based on Payment Specialist, with the required permission groups and the AI agent runtime duty.
  • Your actual payment program terms. If you’ve negotiated specific dynamic discounting or virtual card terms, those documents need to be given to the agent. In AI Agent Studio, upload the financing program documents through the Financing Programs tool, then run Process Agent Documents. Otherwise, the assistant may use system defaults, and the benefit calculations won’t reflect your negotiated terms.

One thing I’ve learned from Fusion projects is that the problem isn’t always where you expect it. A user logs in, the menu is there, the page opens, but there’s no data. It looks like a functional defect. Very often it’s a role or data-access issue. I’ve lost more testing time to these than to some genuine functional defects, so I check roles and data access early, before the testing team reports that something is missing.

The agents don’t replace your controls

None of this replaces your existing controls, and that’s by design. Every recommendation and draft still needs a human to review it, and your approvals, segregation of duties and validations keep working exactly as before. Payment scheduling still uses your existing Payment process request templates and still needs someone to confirm it before it goes out, which matters a lot since real money is moving. The same caution applies to supplier offers. A supplier can qualify for a discounting program on paper and still say no. And since the traditional Fusion pages stay available right alongside the agents, a controlled rollout with a small group of high-volume suppliers makes far more sense than switching everything on at once.

Closing the loop at month end

In 26D, Oracle introduced the Payables Period Close Workspace, an agentic application for the usual month-end hunt across five different screens. For the selected ledger and period, it pulls invoices, payments and period status into one place, ranks priority actions by urgency and monetary impact, and lets you use Ask Oracle to see what each issue is holding up. It also follows your own SOP. Your milestones, thresholds, owners and signoffs decide what counts as done, what needs confirmation and what gets escalated.

Fusion Claw, recently announced by Oracle, pushes this further. It’s a runtime that lets Fusion agentic applications actually carry out work, within your SOPs, policies and approval limits, at whatever level of autonomy you choose. Every action leaves an Outcome Receipt showing the authority used, the evidence and the result.

Which brings me back to that Net 30 invoice. It doesn’t go away once it’s paid. If nobody catches it, it turns up again at month end as something blocking the close. As these applications get more autonomy, that matters even more, because an agent is only as reliable as the data it acts on.

Where I would start

If I were starting an implementation today, I wouldn’t start with the most impressive AI feature. I’d start with the basics: clean supplier data, sensible invoice streams, the right document formats and training, clear business policies, and correct roles and BU access. Once those are in place, I’d bring the Payments Agent in.

If the supplier, amount, payment terms or dates are wrong, automation at the payment end won’t fix it. It will just make the wrong decision faster. For me, that’s what matters most with these new AP agents: keeping the information reliable all the way from capture to payment.

From AI That Answers to AI That Acts

Posted on by Vibha Baid

Understanding the Tool Calling Pattern in Oracle AI Agent Studio

An AI agent can understand a purchase-order question perfectly. But what happens when the answer is sitting inside Oracle Fusion, and the model does not have that information yet?

That is where tool calling becomes important.

An LLM is good at understanding language, reasoning over context, and generating responses. What it does not automatically have is access to every live business system an organization uses. If a manager asks, “Which purchase orders are delayed and why?”, the model needs a controlled way to reach the system that actually contains the purchase-order information.

A tool provides that bridge. It gives the agent a defined capability, such as retrieving a purchase order, checking inventory, querying business data, calling an external REST API, retrieving information, or performing an approved operation.

The distinction is worth keeping simple: the tool is the capability; tool calling is the agent deciding to use that capability as part of completing a larger task.

What happens when the agent needs a tool?

Consider a manager asking:

“Show me delayed purchase orders and check whether inventory is causing the delay.”

The agent first interprets the request using the model, its instructions, the relevant topic, and the capabilities available to it. The first part of the request may require current purchase-order information, so the agent can select an appropriate configured tool and provide the required parameters.

The connected system processes the request and returns structured information. The agent then looks at that result and determines what is still needed. If the purchase order points to a particular item or organization, the agent may need inventory information next. It can make another tool call using the relevant information from the first result.

The inventory result then becomes part of the context used to answer the original question. The user asked one question, but the agent may have needed several tool calls to complete it.

This is the core of the Tool Calling Pattern: instead of trying to generate every part of an answer from its existing knowledge, the agent can obtain current information or perform a defined operation through an available capability.

A tool needs a clear contract

This is where tool design starts to matter. A tool is not simply an API endpoint with a name attached to it. The agent needs enough information to understand what the tool does, when it is appropriate, which inputs it expects, and what sort of result it returns.

For example, a tool called GetInventory does not tell the agent very much by itself. A description such as “Returns the available quantity of an item for a specified inventory organization” gives the agent a much clearer idea of the capability.

Technically, a tool can be treated as a contract between the agent and the underlying capability. That contract includes the operation, input parameters, connection or authentication requirements, and expected result.

Suppose the tool requires an item ID and an organization ID. If the agent has only the item number, the call may fail or return incomplete information. The underlying API may be working correctly, but the agent still cannot use it successfully because the contract was not satisfied.

This is why tool descriptions and parameter definitions are more than configuration details. They provide the context the agent uses when deciding how to work with its available capabilities.

In Oracle AI Agent Studio, tools can be configured and made available to agents. Topics and their instructions can add further guidance about the agent’s business scope and how capabilities should be used. The agent can also be configured with tools, topics, prompts, inputs, outputs, and interaction limits.

A poorly defined tool can therefore lead to poor agent behaviour even when the underlying API works perfectly.

Where Oracle AI Agent Studio fits

Oracle AI Agent Studio provides the environment for putting these pieces together. An agent can be given a business purpose, instructions, topics, and a set of tools. Those tools can expose capabilities from Fusion or from external systems.

For example, a Business Object tool can be used when the agent needs to work with supported Fusion business data. If the required capability is available through an API, an External REST tool can connect the agent to that service. AI Agent Studio also supports MCP tools and other capabilities such as document retrieval, connectors, email, and deep links.

These should not be thought of as three different versions of tool calling. They are different ways of exposing capabilities that an agent can use.

The important point is that the LLM does not need to directly implement communication with every backend system. Instead, the required capabilities are exposed through configured tools, and the agent can use their results as it continues working toward the user’s request.

Different tools, same pattern

The choice of tool depends on the capability the agent needs and where that capability or information is available.

Oracle AI Agent Studio provides different tools for different kinds of capabilities. A Business Object tool can work with supported Fusion business data, while an External REST tool can connect the agent to internal or external APIs. MCP tools provide another way to expose capabilities from external MCP servers. AI Agent Studio also provides tools for capabilities such as document-based retrieval, connectors, email, and deep links.

These are different tool types, but they fit into the same broader Tool Calling Pattern. The agent has access to a defined capability, determines when that capability is relevant to the task, provides the required inputs, and uses the returned result to continue working toward the user’s request.

A concrete tool-calling execution

It helps to follow one request all the way through rather than looking at tool calling as an isolated API operation.

Imagine the user asks: “Why is purchase order 1045 delayed? Check whether the required item is available in inventory.”

First, the agent identifies that the question requires current purchase-order information. It uses the appropriate Business Object capability and supplies the information needed to retrieve the purchase order.

Next, the returned purchase-order data gives the agent information about the item and organization involved. The agent can then determine that inventory information is required and use the appropriate configured tool with the relevant item and organization values.

The inventory result may show that the item is unavailable or that the available quantity is insufficient. The agent can then use both results to explain the likely reason for the delay.

The important part is that the next step can depend on the user’s request, the available tools, and the information returned by earlier steps. The agent uses those results to continue working toward the user’s request within its configured boundaries.

Tool calling is not the same as a workflow

This difference is easy to miss because both approaches can involve multiple steps.

A workflow normally has a known sequence. For example:

Extract invoice
↓
Validate invoice
↓
Update record
↓
Send notification

The developer defines that path in advance. Each step is expected to occur in a particular order.

With agentic tool calling, the capabilities used during a task can depend on the user’s request and the information available to the agent at that point. The agent still operates within its instructions, topics, tools, permissions, and interaction limits.

A simple way to remember the distinction is:

Workflow: the process is defined beforehand.

Tool calling: the agent uses available capabilities as needed within defined boundaries.

AI Agent Studio supports both approaches. Workflows are useful for predictable processes where the sequence is known. Agentic behaviour becomes useful when the information needed, or the steps required to reach an answer, can vary from one request to another.

The enterprise part: control matters

Giving an agent access to tools does not mean giving it unlimited access to the business. The tools available to the agent, the instructions controlling its behaviour, the user’s permissions, and the security of the connected system all matter.

There is also a practical difference between a capability that reads information and one that changes information.

Reading a purchase order is generally different from updating a purchase order, sending an email, or triggering a business operation. The second category can have consequences outside the conversation. For sensitive actions, AI Agent Studio supports human approval so that a person can review the operation before it is executed.

This leads to a useful principle for enterprise agents: the objective is not to give an AI agent maximum freedom. The objective is to give it the right capability with the right boundaries.

Tool design should therefore consider not only whether an operation works, but also who can use it, what it can change, what inputs it accepts, and whether a human should be involved before a sensitive action is completed.

When something goes wrong

Tool calling introduces another engineering challenge: debugging.

Suppose the agent produces an incorrect answer. The problem may not be the LLM itself. The agent might have selected an unsuitable tool, supplied an incorrect parameter, received an unexpected API response, or interpreted valid returned data incorrectly.

That means looking only at the final response is not enough. The complete execution path matters.

AI Agent Studio provides debugging capabilities that allow developers to inspect execution, context, inputs, outputs, and node behaviour. Developers can use breakpoints, step through execution, rerun parts of an execution, and inspect what happened during the process.

This changes the debugging question from “Why did the AI give me this answer?” to a more useful question: “Where did the execution go wrong?”

Was the request understood correctly? Was the appropriate tool selected? Were the parameters valid? Did the backend return what was expected? Did the agent interpret the returned data correctly?

Following the complete tool call makes these questions much easier to answer.

For example, if a tool returns no inventory records, the first assumption should not automatically be that the model failed. The input organization might be wrong, a required parameter might be missing, the backend response might not match what the agent expects, or the tool itself might not be the right capability for the request. Looking at the execution step by step helps separate these possibilities.

The bigger picture

Tool calling may sound like a small technical feature, but it is one of the pieces that makes agentic AI useful in enterprise applications.

Without access to appropriate tools or other external capabilities, an agent is limited in what current business information it can retrieve or what actions it can perform beyond the information available in its context. With tools, it can reach business systems, retrieve current information, interact with APIs, and perform controlled operations.

The real value, however, is not simply having more tools. An agent with dozens of poorly defined capabilities can be harder to control and debug than an agent with a smaller set of well designed ones.

What matters is having the right capabilities available, describing them clearly, supplying the right inputs, enforcing appropriate permissions, and allowing the agent to use them at the right point in a business task.

A useful way to look at the architecture is:

  • The model understands the request.
  • The tool exposes a capability.
  • The tool call connects the request to that capability.
  • The returned result gives the agent current information to continue reasoning.
  • The agent then turns those results into an answer or, where permitted, a controlled business action.

That is the practical shift from an AI that can tell you about the work to an AI that can actually participate in getting the work done.

The Machine was Running, it was just not producing

Posted on by Vibha Baid

A treadmill can log eight miles of belt travel while you stand on the side rails. The console still claims motion. Your plant does the same thing when availability is the only number on the board.

The KPI is OEE (%), calculated as Equipment Availability × Performance Efficiency × Quality Rate (or First Pass Yield). Oracle Fusion Cloud Manufacturing already records the work order, resource usage, and quality inspection transactions that build all three factors at shift level, so supervisors can stop treating uptime as output and protect promise dates and backordered rate.

Plant boards still celebrate a green shift while promise dates slip and backorders climb. The gap is not missing sensors. It is reading only one of three factors. Availability alone does not equal output. Most plants instrument the first factor and leave performance and quality as monthly afterthoughts. The rest of this piece shows how the transactions you already post in Fusion turn that blind spot into shift-level action.

Why availability-only reporting hides real losses

Availability tells you the workstation reported as running. It does not tell you whether the line moved at the right speed or shipped good parts. That is why a full-shift green light can still leave the warehouse short and the customer waiting.

OEE (%) = Equipment Availability × Performance Efficiency × Quality Rate (or First Pass Yield). Equipment Availability reflects how much of the planned time the equipment actually ran. Performance Efficiency reflects whether it ran at the intended speed. Quality Rate reflects how much of the output was good the first time. The inputs behind all three already post in Oracle Fusion Cloud Manufacturing as work order, resource usage, and quality inspection transactions, and products needing rework pull the quality factor down.

Why a low number matters:

  • Low OEE reduces overall production effectiveness and limits output capacity.
  • It points to issues in equipment availability, performance speed, or product quality.
  • It raises production cost per unit through inefficiency and downtime.
  • It hurts delivery reliability and weakens competitiveness through lower operational efficiency.

Slow cycles and minor stops cut performance without ever flipping a downtime flag. The operator stays clocked in. The workstation status stays in-use. Yet each extra second per cycle compounds across hundreds of units until the shift finishes short of plan. Scrap and rework do the same to quality: the station looks busy while finished goods inventory does not grow.

Those hidden losses show up where COOs and CSCOs feel them. Completed quantities fall. Planners open expedites. Freight premiums rise. Promise dates move. Backordered rate climbs even though every availability report said the line was up. The same work order transactions that record status also hold the counts, cycle times, and inspection results that explain the shortfall.

Think of availability as the lights being on in a kitchen. Performance is ticket speed. Quality is plates that leave without coming back. You would never run a restaurant on lights alone (and yet many plants still do). Shift-level workstation data already captured in work order operations lets you read all three without bolting on another system.

Business Value Maximization (BVM) starts after go-live, when these derived metrics become decision tools rather than after-the-fact scorecards. The point is not a prettier chart. It is catching the loss while the shift still has hours left to recover.

What should you do with this framing on Monday morning? Stop accepting availability as a proxy for output. Ask which work centers report high uptime and still miss standard quantity. Those are your performance and quality leaks, and Fusion already holds the evidence.

The six big losses visible in Fusion transaction data

The classic six big losses are not a separate data project. They map to records Fusion already stores during execution: work order operations, resource usage, workstation status reason codes, and quality inspection results.

Break the losses into the three OEE buckets you will actually manage:

  • Availability losses: planned and unplanned downtime captured when operators change workstation status and assign a reason code.
  • Performance losses: slow cycles and minor stops revealed when ideal cycle time from the work definition is compared with actual runtime and total count.
  • Quality losses: scrap and rework recorded in inspection results against the quantities reported on the operation.

Reason codes assigned at the workstation level classify each stop so the loss type is not a matter of opinion after the fact. Oracle Fusion Cloud Manufacturing readiness documentation on workstation reason codes associates reason codes with workstation status and potential loss, and classifies stops as Availability Loss, Performance Loss, Not a Loss, or Break.

That classification is the difference between a vague “we had issues” note and a shift board that shows whether the hour was lost to a breakdown, a micro-stop, a scheduled break, or something that should not count against the line at all. Supervisors can aggregate the same codes from individual operations up to work center and plant views without new data collection. One operator’s reason code rolls into the work center card; work center cards roll into the plant view the operations leader reviews mid-shift.

A practical pattern we see: plants that only code major downtime bury performance loss inside “running” time. The minor stop never gets a code, so it never becomes a loss category, so it never gets a countermeasure. Once reason codes cover both availability and performance categories, the six big losses stop being a textbook slide and start being a filter on live transactions.

Use the codes as a shared language across shifts. If first shift codes a jam as performance loss and second shift codes the same event as a break, your plant roll-up lies. Align the code list at plant setup, train operators on when each code applies, and review a sample of coded stops in the first weeks after you turn the metrics on. The goal is clean classification, not more paperwork.

Once the codes and inspection results are trustworthy, aggregation is straightforward. Start at the operation, roll to the workstation, then the work center, then the plant. Each level answers a different question: which job is bleeding, which station needs help, which area is off plan, and whether the site will hit the day’s promise commitments.

Building availability, performance and quality from existing Fusion transactions

No additional sensors or side systems are required to derive the three factors. Planned production time and runtime come from shift-assigned work order operations. Ideal cycle time sits on the resource usage rate of the work order operation. Completed counts and inspection outcomes already post as part of normal execution.

Build the factors in this order so the math stays auditable:

  1. Equipment Availability: read planned production time against actual runtime for the shift window on that workstation or work center.
  2. Performance Efficiency: compare the ideal cycle time on the work definition with actual runtime and total count, so slow cycles and minor stops show up.
  3. Quality Rate (or First Pass Yield): compare good units with total units reported for the shift, treating rework and scrap as the drag.
  4. OEE (%): Equipment Availability × Performance Efficiency × Quality Rate for the current shift.

Oracle Fusion Cloud Manufacturing’s guide to monitoring workstations describes supervisors monitoring these metrics on the Production Supervision dashboard using data from work order operations, with ideal cycle time tied to the resource usage rate of the work order operation.

Products needing rework lower the quality value even when the station never went down. That is the quiet killer of promise dates: the line looks occupied while net good output falls behind the schedule the customer already heard.

Aggregate workstation metrics to work center and plant level for supervisor dashboards so you are not managing fifty cards with no roll-up. The same transaction set surfaces open exceptions that affect the current shift: missing assignments, overdue operations, quality holds, and status reasons that need a second look. Metric and root cause sit in one place, which is what makes the number actionable instead of decorative.

A common objection is “our rates are wrong, so OEE will be wrong.” Fair. Ideal cycle time only helps if the work definition reflects the real standard. Treat rate hygiene as part of the rollout. Confirm resource usage rates on the top volume operations first, then expand. Bad masters produce confident nonsense (we have all watched a dashboard defend a fantasy standard).

When the three factors are derived from the same work orders your planners already trust, OEE stops being a parallel science project. It becomes another view of execution truth you already pay to capture.

Moving from monthly reports to shift-level supervisor action

Monthly OEE roll-ups arrive after the expedite has already shipped and the margin is already gone. Real-time workstation cards replace those summaries with visibility a supervisor can use before the shift ends.

Configure performance metrics and reason codes at the plant level so deviations appear as soon as status and quantities post. The Production Supervision dashboard then displays plan adherence, OEE, availability, performance, and quality at work center and workstation level. That is the operating picture, not a weekend analytics export.

When Performance Efficiency drops mid-shift, the supervisor should not wait for a monthly deck. They should open the workstation card, read status and exceptions, and act.

Drill from the work center aggregate into individual workstation cards that show status, assigned operators, and open exceptions. Assign operators and operations at the workstation level to close gaps while hours remain. Each metric deviation should tie back to the specific work order operation causing the loss, so corrective action stays precise: move a skilled operator, clear a quality hold, recode a false downtime, or split an overloaded operation.

The levers that lift OEE are consistent across plants:

  • Improve operator efficiency so cycles run at the work definition’s intended speed.
  • Run WIP inspections so quality problems are caught at the operation, not at final inspection.
  • Reduce equipment downtime by coding every stop and removing the recurring causes first.

A simple shift rhythm keeps the dashboard from becoming wallpaper:

  • First hour: confirm assignments, open exceptions, and any workstation already off plan on availability.
  • Mid-shift: review performance and quality on the highest-volume work centers; rebalance labor where slow cycles cluster.
  • Final hours: protect promise-critical orders, clear rework queues that would otherwise miss packing, and lock reason codes so the next shift inherits clean history.

This is where post-go-live operations discipline matters more than another implementation workstream. The transactions are already flowing. The question is whether supervisors are expected to manage the three factors live, or only to explain last month’s chart in a conference room. Teams that treat the Production Supervision dashboard as a shift tool recover units the same day. Teams that treat it as a reporting curiosity keep buying back their own shortfalls with expedites.

If your plant still runs on end-of-month OEE, pick one work center and run the shift rhythm for two weeks. Compare completed good quantity and exception aging against the prior pattern. You do not need a plant-wide program to prove the point. You need one supervisor with clear codes, trusted ideal cycle times, and permission to reassign before the whistle.

For plants already live on Fusion and hunting measurable ROI rather than another module, process optimization work such as Second Sight sits inside the consulting engagement to tie these operating signals to outcome targets, not as a stand-alone product login.

How OEE shortfalls drive missed promises and backordered rate

Reduced performance and quality directly lower completed quantities per shift. Availability can look healthy while the plant still ships late, because the units that count are good units finished at the planned rate, not hours the station reported as busy.

Trace the path from factor to board KPI. A performance gap means fewer units per hour than the work definition assumed, so the schedule’s math no longer holds. A quality gap means some of those units return as rework or leave as scrap, so net supply to downstream operations and to the customer shrinks again. Stack both gaps across multiple workstations and the cumulative shortfall pushes promise dates out. The COO and CSCO then defend Improved Backordered Rate with a story that started as “the line was up.”

When losses stay unaddressed, planners resort to expedites. Premium freight, overtime, and hot-job disruption inflate cost and compress margin. The short-term save becomes the long-term habit. Backordered rate improves for a week, then returns, because the underlying OEE factors never changed.

The same Fusion data that calculates OEE also supports a forward view of backordered rate risk. If a work center sustains low performance or quality across successive shifts, completed supply will miss the demand already promised. You do not need a separate forecasting product to see the pattern: compare planned quantities on open work orders with good-unit actuals and open exceptions, then flag customer orders that depend on the lagging centers. That is enough to trigger recovery plans while recovery is still cheaper than apology.

Post-go-live value realization is the moment these derived metrics become decision tools. Implementation put the transactions in place. Value work makes supervisors, planners, and operations leaders use availability, performance, and quality as one conversation tied to promise dates. Orbrick’s work with manufacturers already live on Oracle Fusion Cloud centers on that outcome link: measurable movement on KPIs such as Improved Backordered Rate, not hours logged against a change request.

Edge cases still matter. A planned maintenance window coded correctly should not punish the line. A pilot run with intentionally slow cycles should not trigger the same escalation as a steady-state bottleneck. Reason codes and work order context keep those cases honest. The model fails only when every stop looks the same and every green availability score gets a free pass.

So what do you take to the next operations review? Bring one chart of availability-only history and one view of the three-factor OEE for the same work centers. Show completed good quantity beside backordered rate. The room usually stops arguing about whether the machines “ran” and starts asking which loss to remove first.

Conclusion

Shift-level OEE derived from the work order, resource and quality transactions already in Oracle Fusion Cloud Manufacturing turns the statement “the line was up” into the single number that protects promise dates and backordered rate. Read all three factors, code the losses honestly, and act inside the shift while recovery still changes the day.

We help manufacturers turn that number into sustained outcome gains through Business Value Maximization, including ongoing support paths such as Oracle Fusion managed services when the operating rhythm needs a steady partner after go-live.

Download the Tiny Transformations e-book to see how other teams connect execution metrics to board-level KPIs, then schedule a strategy session to map the same approach to your plant.

Oracle Fusion Extension Architecture:  Choosing Between Fusion VBS, Standalone Visual Builder and Oracle Integration VBCS 

Posted on by Vibha Baid

An architect’s decision framework for Oracle Fusion application extensions 

Introduction 

Oracle customers have several technologies available for extending or building applications around Oracle Fusion Cloud Applications, including Oracle Integration with Visual Builder, Standalone Oracle Visual Builder, and Oracle Visual Builder Studio for Fusion Application Extensions. 

One of the most common questions from customers is: “Which technology should we use, and in what situation?” The answer depends on the application’s relationship with the Fusion ecosystem, integration requirements, user population, data requirements, scalability, lifecycle management, and licensing model. 

1. Oracle Integration with Visual Builder 

Oracle Integration can provide Visual Builder capabilities as part of the Oracle Integration platform. This option is particularly useful when the application requires significant interaction with external systems, and the organization already has Oracle Integration available. 

Visual Builder applications can consume Fusion REST APIs as well as external REST services. Oracle Integration also provides integration, orchestration, transformation, monitoring, and connectivity capabilities. 

When should we consider this option? 

  • The application has frequent interaction with multiple external systems. 
  • Oracle Integration is already licensed and has sufficient messages based on message packs. 
  • Integration logic, transformation, orchestration, or monitoring is an important part of the solution. 
  • The application itself is relatively lightweight and does not justify provisioning a separate Visual Builder environment. 

Licensing consideration 

The licensing impact should be evaluated based on the Oracle Integration consumption model and Visual Builder usage. For Oracle Integration, message consumption depends on the applicable licensing model. Visual Builder usage within Oracle Integration also has its own metering rules like 100 messages consumption per session of the user. Therefore, the decision should be based on actual application usage and existing Oracle Integration entitlement rather than assuming a fixed message consumption per user session. 

2. Standalone Oracle Visual Builder 

Standalone Oracle Visual Builder is appropriate when the requirement is to build an independent application outside the Oracle Fusion Cloud Applications ecosystem. Unlike a Fusion Application Extension, the standalone application has its own application lifecycle and can be designed around its own users, security model, data requirements, and application architecture. 

Standalone Visual Builder is licensed based on provisioned OCPUs. 

When should we consider this option? 

  • The application needs to operate independently of the Fusion user experience. 
  • The application has users who do not have Fusion Cloud Application credentials. 
  • The application requires its own security and application boundaries. 
  • The application needs to integrate with multiple enterprise systems, and Fusion is only one of those systems. 
  • The application has sufficient scale or usage to justify a dedicated Visual Builder runtime. 

The cost and required OCPU capacity should be determined based on the application’s expected workload and sizing requirements. It should not be assumed that Standalone Visual Builder is always the most expensive option; actual cost depends on the licensing and consumption model. 

3. Oracle Visual Builder Studio – Fusion Application Extension 

Oracle Visual Builder Studio is the preferred technology when the requirement is to extend an Oracle Fusion Cloud Application. It can be used to customize supported Fusion Redwood pages, create new App UIs/pages, consume Fusion REST APIs, consume supported external REST APIs, reuse Fusion security and application identity, and manage source code, Git repositories, and CI/CD pipelines. 

One of the major advantages is that the extension becomes part of the Fusion Cloud Applications ecosystem, rather than being an entirely separate application. 

When should we consider this option? 

  • The application is primarily intended for Fusion users. 
  • The application should be accessed through the Fusion ecosystem. 
  • Fusion authentication and authorization should be reused. 
  • The requirement is to extend an existing Fusion business process or user experience. 
  • The custom application is relatively lightweight and closely related to Fusion functionality. 

External connectivity 

An important clarification is that Fusion VBS App UIs are not restricted to Fusion endpoints. Current Oracle documentation supports creating service connections to external REST APIs. The architectural question is therefore not simply whether an external endpoint can be called, but whether the required external connectivity, authentication mechanism, data processing, security model, and integration complexity are appropriate for an App UI. 

Data considerations 

For Fusion application data and custom business objects, Application Composer can be used where supported by the relevant Fusion application. Application Composer supports custom objects, fields, relationships, security, and REST exposure for supported objects. However, Application Composer should not be presented as a generic replacement for an external database. 

Cost and lifecycle 

VB Studio is provided as part of the Fusion Cloud Applications ecosystem, and Oracle documents the Fusion Applications identity domain as having no additional licensing cost for building extensions using that identity domain. Related OCI/build/storage services can, however, have their own costs. 

VB Studio also provides Git, CI/CD, code review, and development lifecycle capabilities. Therefore, for a lightweight Fusion-centric application, Fusion VBS can be a very attractive option from both an architectural and cost perspective. 

Architect’s Decision Framework 

The decision should not simply be based on which technology can build the UI. All three options can support application development to some degree. Instead, ask: “Where should the application belong?” 

Requirement Recommended Option
Extend an existing Fusion page Fusion VBS
Build a lightweight application for Fusion users Fusion VBS App UI
Build an independent enterprise application Standalone Visual Builder
Application has external/non-Fusion users Standalone Visual Builder
Heavy cross-system orchestration Oracle Integration VBCS
Complex transformation/integration requirements Oracle Integration VBCS
Fusion is only one of many backend systems Standalone Visual Builder + OIC
Simple Fusion-centric REST-based application Fusion VBS App UI

Do You Really Need Separate Integrations for Each AI application?

Posted on by Vibha Baid

Let me paint you a picture. 

You’ve got an AI agent, maybe it’s sitting inside your enterprise platform, maybe it’s something your team built. It’s smart, it can reason, it can draft answers and summarize documents. But the moment you ask it something that lives outside its training, like “what’s the current status of ticket #4821?” or “pull last week’s sales numbers from the CRM”, it just… stares at you blankly or hallucinates. 

That’s the real problem. AI models, by themselves, are islands. They’re brilliant, but isolated. And the traditional solution? Write custom integrations. Lots of them. 

So, the dev team writes one connector for Jira. Then another for Salesforce. Then one for the internal database. Then someone needs Slack. Then the Google Workspace stuff. And on and on it goes. Every single one is hand-built, hand-maintained, and every time the model changes or the tool updates its API, surprise, something breaks. 

This is what engineers call the M×N problem. You have M AI applications and N tools you want to connect them to, and you end up needing M × N unique integrations. It’s not just repetitive. 

Enter MCP: The USB-C Moment for AI 

In November 2024, Anthropic released something called the Model Context Protocol, or MCP.  

Think of it this way. Before USB-C existed, you had a laptop, a phone, a monitor, a hard drive, and each one needed a completely different cable. It was annoying and wasteful. Then USB-C came along and said: one port, one standard, works everywhere. Plug anything in. 

MCP is basically that, but for AI agents and external systems. 

Basically, MCP is an open standard that lets AI agents talk to external tools and data sources through one consistent protocol instead of a hundred different custom integrations. 

So instead of M × N integrations, you get M + N. Each tool gets built once as an MCP server. Each AI app supports the protocol once as an MCP client. And then everything just connects. No rewriting, no custom glue code, no starting from scratch. 

For example, say your company has a documentation tool, and you want your AI agent to pull information from it. Without MCP, someone has to write a custom plugin specific to that tool and that agent. With MCP, if your documentation tool is already an MCP server, any MCP-compatible agent can connect to it. 

The technical side of MCP 

MCP uses a client-server architecture. There are three main players: 

The MCP Host

This is the AI application the user interacts with. Think of it as the “front-end” of the whole system. Examples: an AI assistant embedded in your enterprise app, Claude Desktop, or a tool like AI Agent Studio. The host is where the conversation happens and where decisions about when to call a tool get made. 

The MCP Client

This lives inside the Host. It’s the part that actually handles the communication with external servers. There’s typically one client instance per server connection. 

The MCP Server

This is the external capability. It’s a server that exposes specific tools. Things like “search this database,” “post to Slack,” “query this Jira project,” etc. The server doesn’t care which AI is calling it, as long as that AI speaks MCP.  

When a user asks the agent something that requires external data, here’s roughly what happens: 

  1. The agent (Host) decides it needs a tool 
  1. The MCP Client sends a structured request to the MCP Server 
  1. The Server processes the request and returns structured data 
  1. The Client passes that back to the Host 
  1. The Host weaves it into its response 

No custom code. No one-off API call logic buried somewhere in the codebase. Just a standardized conversation happening behind the scenes. 

Transport Layer (How They Actually Communicate) 

  • STDIO: Used for local connections where the AI runs the server as a direct subprocess. Great for development and local testing. 
  • Streamable HTTP: The modern, recommended approach for production servers. This is what most enterprise setups use, and it’s what most Agent Studio implementations support today. 

AI Agent Studio 

AI Agent Studio is basically a platform where you build, configure, and deploy AI agents in an enterprise context. These agents can answer questions, automate workflows, escalate to humans, and interact with business systems. They’re not just chatbots they’re actual agents with tools and decision logic. 

MCP in AI Agent Studio  

Inside AI Agent Studio, administrators can configure MCP servers as tools. These tools become available to agents during execution. So when an agent is running a task and realizes it needs to check something external; a database, a web search, a Jira board, it can call the appropriate MCP tool and get real-time data back. 

Think of it as giving your agent a toolbox. Each MCP server in that toolbox unlocks a whole new set of capabilities. And unlike before, you’re not duct-taping those tools together manually. 

What if Your AI Could Actually Reach the Data It Needs with: 

  • No custom API middleware: You don’t need to build REST wrappers or plugin layers for every system you want to connect. If there’s an MCP server for it, you just plug it in. 
  • Dynamic data access: Agents stop being limited to static knowledge. They can pull live data from enterprise ecosystems at the moment a user asks. 
  • Scalability: Adding a new data source doesn’t require rearchitecting anything. You register the MCP server and you’re done. 
  • Security: Authentication credentials are stored securely within the system and can be updated without recreating the tool. Access is controlled at the server boundary. 
  • Modular architecture: Each MCP server is independent. If one breaks or gets updated, it doesn’t cascade into everything else. 

Some examples of built-in MCPs in Oracle AI Agent Studio: 

  • DuFirecrawl MCP: Provides web crawling and content retrieval capabilities. Requires Firecrawl MCP. 
  • Slack MCP: Supports team communication through Slack. Requires Slack MCP. 
  • Dropbox MCP: Enables secure cloud file storage, sharing, and collaboration workflows. Requires Dropbox MCP server. 
  • Box MCP: Provides secure content management and collaboration. Requires BOX MCP server. 

Additionally, there’s an option to configure custom MCP using new connector definition. 

Say your company has an internal sales reporting database, or maybe a custom approval system that no built-in MCP server covers. You can write your own MCP server, point Oracle AI Agent Studio at it using create connector definition, and your agent starts talking to it just like any other tool. 

The point is, MCP is a protocol, not a product. If you can expose something through a standard MCP endpoint, AI Agent Studio will work with it. That opens up a lot of doors for teams that have unique internal systems and don’t want to wait for someone else to build a connector for them. 

A Few things to Keep in Mind 

Here are some things to watch out for: 

Authentication setup is critical.

If you try to add an MCP server to an agent before its authentication is properly configured, you’ll get errors. Always verify auth is working before assigning the tool to an agent. 

Write tools need guardrails.

If an MCP tool can write data (create a Jira ticket, post a Slack message, update a database record), consider putting it behind a Playbook in Agent Studio rather than letting the agent call it freely from open conversation. Supervised execution mode gives you human-in-the-loop control for sensitive operations. 

Tool descriptions drive agent behaviour.

The LLM reads your tool descriptions to decide when and how to use them. Vague descriptions lead to bad tool selection. Invest a few minutes writing good, specific descriptions makes a bigger difference than most people expect.  

Summing Up

MCP isn’t the flashiest thing in AI right now. It doesn’t generate images or write code. But it’s arguably one of the most practical and important developments in how AI actually gets used inside real organizations. 

Without something like MCP, AI agents hit a wall the moment they need real-world data. With MCP, and especially with it built into platforms like AI Agent Studio, those walls come down. Your agent can check your databases, pull from your ticketing system, search the web, read your documentation, and post to your channels, all through one standardized, secure, maintainable protocol. 

It’s the difference between an AI that knows things and an AI that can do things. 

And honestly? That’s the AI most businesses have been waiting for. 

 

 

Time to Hire: Turn the 41-Day Benchmark Into a KPI

Posted on by Vibha Baid

Leave a critical role empty for 41 days and you delay productivity ramp, stretch financial close cycles, and walk into the board meeting with an Accelerated Hiring Cycle number you cannot defend. CHROs who separate time to hire from time to fill and act on Oracle Fusion data already in place can shorten that cycle without adding headcount or cutting quality. 

That 41-day vacancy is not a soft HR inconvenience. It shows up in delayed project starts, extended training queues, and quiet pressure on offer acceptance when strong candidates lose patience. The fix is not another spreadsheet or a larger recruiting team. It is clearer definitions, a repeatable calculation from the dates your systems already store, and a short list of process actions that protect quality while the clock runs slower than you want. 

If you want a quick read on where hiring friction sits inside your current deployment, self-assess your ERP maturity before the next board pack lands on your desk. 

What exactly is time to hire and how does it differ from time to fill? 

Time to hire and time to fill answer different questions, and mixing them in a board pack is how a clean process starts looking broken. 

Time to hire starts when a candidate enters the pipeline (application or sourced entry) and ends at offer acceptance. It measures how fast you move people you already have in view. Time to fill starts earlier, at requisition approval, and includes sourcing, posting, and the quiet days when the role sits open with no viable candidates. Time to fill is the full vacancy clock. Time to hire is the candidate-experience clock once someone is in play. 

Workable’s industry summary of SHRM survey data cites an average time to fill of 41 days, the figure that still anchors many CHRO conversations. More recent planning ranges put time to hire closer to 24 to 30 days in many organisations, while time to fill often lands between 45 and 68 days depending on role mix and source. The Resource’s 2026 reporting places USA’s national average time to fill in the 63 to 68 day band as of early 2026. Those are not contradictions. They are different stopwatches. 

Why the split matters for you: finance and the board care about how long the seat stays empty (time to fill). Candidates and hiring managers look at how long the interview-to-offer path takes (time to hire). If you report only one blended number, you cannot tell whether the problem is sourcing scarcity or process drag after applications arrive. Oracle Fusion Recruiting and HCM already store both clocks if you use the right fields: requisition approval date for time to fill, application or candidate-entry date and offer acceptance date for time to hire, as the shared end point. 

Segment both metrics by function, seniority, and location. A company-wide average hides the fact that entry-level roles may close quickly while specialised technology, healthcare, or government roles sit open for 40 to 60-plus days. Report the pair side by side in the board pack. Label them. Then the conversation shifts from “hiring is slow” to “sourcing is slow in these three functions” or “interview stages stall after panel two.” 

Why 41 days (or longer) is costing your organisation more than salary 

Salary for the open role is the line item everyone sees. The real cost sits in the work that does not start, the close cycle that waits on a controller who has not joined yet, and the candidate who accepts a faster competitor after your fifth panel. 

Each extra day of vacancy delays productivity ramp. A revenue role that starts three weeks late does not simply shift three weeks of quota. It compresses ramp into a shorter remaining year and often misses the first full quarter of contribution. In finance and shared services, delayed hires can push period-close coverage thinner, which is exactly when your CFO is defending Close Cycle Reduction. In operations, a missing specialist can extend exception queues that already stress audit readiness and training calendars. 

Candidate experience is not a soft metric here. Pinpoint’s industry time-to-hire trends report that candidate NPS drops 20 percent when the interview stage lengthens by just five days. That drop shows up later as weaker offer acceptance, fewer employee referrals, and a thinner silver-medalist pool the next time a similar role opens. You pay twice: once in lost productivity, again in reputation among the people you most want to hire. 

Specialised roles in technology, healthcare, and government routinely push timelines into the 40 to 60-plus day range. Those are also the roles where a single vacancy creates the loudest board questions, because the work cannot be covered by a generalist for long. Board-level CHRO KPIs such as Accelerated Hiring Cycle and Training Compliance Uplift move in lockstep with vacancy length. When onboarding and mandatory training cannot start, compliance windows slip. When hiring speed is only reported as a vanity average, you lose the story that ties talent operations to business outcomes. 

So what should you do with this cost picture? Translate days into the language finance already uses. Estimate delayed ramp for the top five open roles. Show offer-acceptance movement when interview stages stretch. Tie both to Accelerated Hiring Cycle and Improved Offer Acceptance. Suddenly the 41-day figure is not an HR curiosity. It is a controllable input to the same scorecard the board already watches. 

How to measure time to hire accurately inside your current systems 

You do not need a new analytics stack to measure time to hire well. You need a fixed formula, disciplined segmentation, and the dates Oracle Fusion already captures. 

Use this formula: for each closed requisition, count the calendar days from the candidate’s application or sourcing-entry date to the offer-acceptance date. Average those days across closed roles in the period. That average is time to hire. For time to fill, start the clock at requisition approval (or the approved open date your governance uses) and end at the same offer-acceptance date. Keep the two series separate in every report. 

Pull the fields from Oracle Fusion Recruiting and HCM rather than rebuilding them in a side spreadsheet. Application date, stage-enter timestamps, interview completion dates, offer-extended date, and offer-accepted date are usually already present when the modules are in active use. Spreadsheets drift. System fields can be audited. If a stage timestamp is missing, fix the process that should have written it instead of inventing a proxy in Excel. 

Segment before you average. Cut the data by: 

  • Function (finance, IT, clinical, operations, sales) 
  • Seniority (entry, professional, manager, executive) 
  • Location or legal entity 
  • Hire type (volume vs specialised) 

A single enterprise average will flatter high-volume roles and punish specialised ones without telling you where to intervene. Set internal planning ranges against published industry bands rather than chasing one global target. Entry-level roles often land near the low teens to high teens in days for time to hire, while government and deep technical roles can exceed 60 days on the fill clock. BambooHR’s time-to-hire glossary summary notes that average time to hire rose to 44 days in 2023, a useful historical anchor when someone claims “we have always been around a month.” 

Run the report on a fixed cadence (monthly is enough for most boards; weekly for active transformation programs). Pair time to hire with offer-acceptance rate and a simple candidate NPS or stage-drop reason code. Speed without acceptance is just a fast no. Then map the trend line to your Accelerated Hiring Cycle KPI so the metric has a home in the same language you already use for Oracle value maximization conversations. 

What drives the 41-day average in 2026 

The 41-day figure feels permanent until you name the bottlenecks that built it. Most of them are process choices, not labour-market fate. 

Interview load is the loudest driver. Curriculo’s 2026 time-to-hire analysis reports that organisations now run 42 percent more interview rounds per hire than in 2021. Extra rounds feel like rigour. Often they are calendar friction: more panelists, more reschedules, more days between stages with no new signal collected. If round four rarely changes the hire decision, it is cost, not quality control. 

Application volume has inflated as AI-assisted resumes flood inboxes. Volume without quality forces longer screening queues. Recruiters spend days sorting lookalike profiles before a human conversation starts. That lag sits entirely inside time to fill and the early part of time to hire, and it is visible in Fusion as time-from-application-to-first-screen if you track stage dates. 

Compliance and governance add real, sometimes non-negotiable days: background checks, security clearances, multi-stakeholder approvals, compensation committees for senior roles. The mistake is treating every role as if it needs the full senior-executive path. High-volume hires drown in the same approval chain designed for a director-level exception. 

Manual screening remains the slowest human step in many Fusion-backed processes. Resumes wait in queues. Interview slots are booked by email. Feedback forms sit incomplete while the candidate interviews elsewhere. None of that requires new headcount to diagnose. Oracle Fusion talent modules already record stage timestamps, interviewer assignments, and offer outcomes. Inside a focused engagement, AI capabilities can surface where stage-to-stage delays cluster (by role family, by hiring manager, by location) so you fix the actual choke point instead of adding another generic SLA. 

Ask a blunt question in your next talent ops review: which of these four drivers owns most of our days? Interview inflation, volume noise, compliance pathing, or manual handoffs? Pick one primary driver per function. Trying to fix all four at once is how programs stall. 

Practical ways to shorten the cycle without lowering quality 

Shortening the cycle is not a slogan. It is a short list of operating moves that protect assessment quality while removing dead time. 

Cut interview rounds that do not change decisions.

Map the last 20 hires in a function. Note which round first produced a clear yes or no. If round four almost never flips the outcome, collapse it into a structured work sample or a calibrated scorecard used in round two. Keep assessment rigour. Remove calendar theatre.

Automate screening and scheduling from data you already capture.

Use Fusion requisition criteria, knockout questions, and interviewer availability rather than inbox ping-pong. Recruiters should spend time on qualified conversations, not on chasing “are you free Thursday?” threads. Automation here is process design inside the system you own, not a new product purchase.

Build role-specific playbooks.

High-volume hires need a fast, repeatable path with fixed stage SLAs. Specialised hires need deeper assessment but tighter ownership (named panel, pre-blocked interview weeks, parallel background checks where policy allows). One generic playbook forces both populations into the wrong speed.

Track quality beside speed.

Report offer-acceptance rate and candidate NPS next to time to hire every month. If speed improves while acceptance falls, you have only moved the pain. Improved Offer Acceptance and Accelerated Hiring Cycle should rise together.

Pre-brief panels and standardise scorecards.

Unprepared interviewers create repeat rounds “to be sure.” A 15-minute pre-brief and a shared rubric reduce that loop. Feedback due within 24 hours of the interview is a process rule, not a personality trait.

Start compliance early on the critical path.

Where policy allows, trigger background or security steps as soon as a finalist is identified rather than after verbal offer. Parallel paths recover days without lowering the bar.

These moves map cleanly to CHRO board language. You are not asking for headcount. You are redesigning the path that already sits in Oracle Fusion workflows. For teams that want a deeper technical companion on configuring stage SLAs and recruiting analytics inside Fusion, pair this piece with a how-to on Fusion Recruiting stage design and offer-cycle reporting (the natural second part of this series). 

If process optimisation across Fusion modules is already on the roadmap, Oracle Fusion process optimization work is one path teams use when hiring-cycle outcomes need to sit beside other verified ERP results. 

Common misconceptions that keep cycles long 

A few stubborn beliefs keep CHROs stuck defending a number they could already change. 

Faster hiring equals lower quality.

Only if you remove signal instead of removing wait time. Structured work samples, calibrated scorecards, and early compliance checks protect quality while cutting idle days. Quality fails when you skip assessment. It does not fail when you stop waiting a week for a panel that adds no new information. 

More interview stages improve one-year retention.

Extra stages mostly test stamina and calendar luck. Retention at one year tracks role clarity, manager quality, onboarding, and compensation fit far more than whether someone survived six conversations instead of four. If retention is the worry, measure Talent Retention Boost and onboarding completion, not interview count. 

Time to hire is a vanity metric.

It is vanity only when it floats free of business outcomes. Tied to Accelerated Hiring Cycle, Improved Offer Acceptance, and Training Compliance Uplift, it becomes a leading indicator the board can use. Untied, it is just a stopwatch. 

Industry averages are targets.

They are planning ranges. Your mix of regulated roles, locations, and seniority will not match a national mean, and it should not. Use 41 days (and the wider 45 to 68 day fill bands) as reference points, then set segmented internal benchmarks you can actually move. Matching the average exactly is not a strategy. Beating your own baseline in the roles that matter most is. 

We need new tools before we can improve.

Most organisations already own the dates, stages, and offer outcomes required to diagnose the cycle. The gap is definition discipline and operating rhythm, not another license. New tooling on top of fuzzy definitions only produces faster confusion. 

Challenge these assumptions in the next talent steering meeting. Write the counter-evidence next to each belief. You will usually find two or three days you can recover in a single quarter without touching quality bars. 

Conclusion 

The 41-day benchmark is not fixed. CHROs who measure time to hire separately from time to fill, read the stage signals already sitting in Oracle Fusion, and attack interview inflation and manual handoffs can turn hiring speed into a measurable business advantage rather than a recurring board apology. One stopwatch for the vacancy. One stopwatch for the candidate. One monthly rhythm that ties both to Accelerated Hiring Cycle and offer acceptance. That is the whole game. 

Orbrick works with mid-to-large Oracle Fusion teams on outcome-tied improvements when those hiring-cycle signals need to become verified results, not slideware. The body of this article is yours to run without anyone in the room. 

Ready to turn your hiring cycle into a board-level advantage? Download the free Tiny Transformations e-book for 70-plus KPIs and practical frameworks, then book a strategy session to map the next steps inside your Oracle Fusion deployment. 

Dead Stock Is a Decision, Not Bad Luck

Posted on by Vibha Baid

Dead stock is not a ghost in the warehouse. It is a receipt for decisions that once made sense, then stopped being reviewed. Forecast buffers, minimum order quantities, slow SKU cleanup, and supplier lead-time assumptions can all turn into inventory that occupies cash, space, and management attention. Inventory turnover is the signal that tells you which decisions are still sitting on the shelf. 

What does inventory turnover really tell you? 

Inventory turnover indicates how efficiently a business is using its inventory investment. It is calculated by dividing the total value of inventory consumed during a period by the total inventory valuation, helping supply-chain leaders understand how effectively inventory is being utilized over time. If the value of inventory consumed in a year is 2 million against a total inventory valuation of 500,000, turnover is four. In plain English, the business turns its stock four times per year. 

That number becomes more useful when converted into days. Divide 365 by the turnover ratio. Four turns equals about 91 days on hand. Eight turns equals about 46 days. Two turns equals about 183 days. 

The ratio is not a moral judgement. Faster is not always better. A high-turn item with unstable supply can create stockouts. A low-turn spare part may be acceptable if it protects a high-value asset. The question is whether the turnover matches the product’s margin, demand pattern, lead time, and service promise. 

Oracle Fusion Cloud SCM documentation describes the inventory, item, lot, planning, and supply-chain data that support this kind of review. The external reference for product capability should stay with Oracle’s Supply Chain Management documentation. The business interpretation belongs to you. 

For Orbrick’s supply-chain persona, the KPI is Optimized Inventory Turns. That wording matters. The goal is not maximum turns. The goal is the right turn rate for cash, margin, service, and risk. 

Which decisions create dead stock before it looks like a problem? 

Dead stock grows quietly because each decision looks reasonable in isolation. 

A planner raises safety stock after a supplier misses a delivery. Nobody revisits the buffer when the supplier stabilises. A buyer accepts a larger minimum order quantity because the unit price looks attractive. Demand drops, but the reorder rule stays in place. An engineering change replaces an item, yet old revisions remain without a disposition owner. A new SKU gets added for a customer request, then survives long after demand disappears. 

If you think that sounds like a storage problem, flip the frame. Inventory is not sitting still. It is voting on yesterday’s decisions with every day it stays unsold. 

The early signs are practical. A SKU hits reorder point even though trailing demand is falling. Open purchase orders exceed the last twelve months of usage. A lot crosses 180 days on hand without a clearance plan. A supplier buffer remains above its original exception threshold. An item has demand in one location and dead stock in another. 

These are not random events. They are process memories. The system remembers what people decided, even when the people have moved on. 

How do you read inventory turnover by SKU instead of hiding behind averages? 

Portfolio averages hide the work. One fast-moving SKU can cover ten slow movers. A category-level ratio can look stable while a specific location is turning into a museum. 

The practical review should cut turnover by SKU, location, supplier, age bucket, lot, item lifecycle, margin, and demand volatility. Start with age and demand. A high-value item with 180 days on hand and falling usage deserves attention before a low-value item with the same age but stable service need. 

Then compare turnover with service signals. Pair the ratio with fill rate, backordered rate, expedite cost, and supplier lead-time performance. Low turns plus healthy service may indicate overstock. High turns plus rising backorders may indicate understock. The metric only becomes useful when read with the neighbouring signals. 

The paired how-to, Reading inventory turns by SKU in Oracle Fusion SCM, should show this in practice. Pull item-level stock, age, lot, planning, purchase order, and demand history. Then sort by cash value, age, and demand decline. The management question is how to act on the view. 

Here is a simple working sequence: 

  1. List SKUs with the highest inventory value. 
  2. Add days on hand and last twelve months of demand. 
  3. Flag items above the age threshold you set for that category. 
  4. Split the list by supplier and location. 
  5. Assign action: consume, transfer, return, sell down, redesign, or stop buying. 

That fifth column is where the work becomes real. Without it, the report is only a neatly arranged complaint. 

What should a supply-chain leader do when turnover is too low or too high? 

Low turnover needs a cause map before it needs a policy change. 

If demand fell, stop future purchase triggers and review forecast assumptions. If minimum order quantities caused the pileup, renegotiate or group orders more carefully. If supplier lead time drove the buffer, compare the original lead-time risk with the current one. If engineering change created the issue, assign disposition before the next revision arrives. If SKU proliferation is the cause, retire slow variants rather than asking the warehouse to absorb strategy drift. 

High turnover deserves equal care. If turns rise because demand is healthy and service is stable, good. If turns rise because stock is too thin, you may be creating backorders, expediting, and unhappy customers. Inventory turnover can flatter a business that is slowly starving service. 

Use a controlled pilot. Pick one supplier, category, or location. Change one policy at a time: reorder point, safety stock, minimum order quantity, or replenishment frequency. Measure turns, fill rate, backordered rate, and expedite cost before and after one demand cycle. 

That discipline keeps the team from swinging between too much stock and too little stock. Shelves fill. Shelves empty. The customer still has to be served. 

How does Business Value Maximization turn inventory data into an outcome? 

Business Value Maximization (BVM) turns the turnover review into a measured outcome. It follows S.E.E.R.: Sense, Evaluate, Execute, Retrospect and Refine. 

Sense means establishing the baseline. Current turnover by SKU, dead-stock value, age, location, supplier, and fill-rate impact. Evaluate means identifying which decisions created the issue. Forecast policy, buying rule, supplier buffer, engineering change, or SKU governance. Execute means changing the operating rule and assigning an owner. Retrospect and Refine means proving whether cash release, fill rate, and backorder movement improved. 

Inside a Value Discovery engagement, Second Sight can serve as an in-engagement capability for process mining and KPI baselining. It is not a stand-alone SaaS offer. It is part of the consulting wrapper that links Oracle Fusion data with measurable supply-chain outcomes. 

This distinction is central to Orbrick. Orbrick is a boutique Oracle Cloud / Fusion consulting firm that specialises in Oracle’s existing Fusion Applications customers and also takes new customers. Orbrick competes on outcomes, not staffing volume. The pricing model reflects that: Orbrick is the only Oracle Cloud consulting firm operating fully on at-risk, outcome-based pricing, paid only on measurable business impact. 

For the reader, the value is the method. You do not need a perfect transformation charter to begin. You need one clean SKU view, one clear decision owner, and one measured result. 

What should you do in the next inventory review? 

Run a one-week dead-stock decision review. 

First, choose the scope. Pick a category, warehouse, supplier, or business unit. Second, calculate turnover and days on hand by SKU. Third, add demand trend, age bucket, open purchase orders, supplier lead time, and margin. Fourth, rank the list by cash value at risk. Fifth, assign an action for the top twenty items. 

The action list should use plain verbs: 

  • Consume through planned demand. 
  • Transfer to a location that still needs it. 
  • Return to supplier where terms allow it. 
  • Sell down with margin guardrails. 
  • Redesign the item or replace the old revision. 
  • Stop buying until the signal changes. 

That last one is often the most powerful. Dead stock continues when the future buying rule keeps recreating the past mistake. 

This is why Optimized Inventory Turns belongs beside supplier performance and backordered rate. Inventory is a cash story, but it is also a service story. When those signals move together, leaders can act with more confidence. 

What mistakes make inventory turnover reviews less useful? 

The first mistake is chasing one perfect turnover target. Inventory does not work that way. A high-margin spare part, a seasonal finished good, a regulated healthcare item, and a fast-moving component do not deserve the same number. The review should start with category intent. Is the item protecting service, supporting production, meeting regulatory need, or sitting there because nobody closed the loop? 

The second mistake is ignoring item lifecycle. A new SKU may need early stock while demand stabilises. A mature SKU needs tighter buying rules. An end-of-life SKU needs a disposition plan before the replacement arrives. Without lifecycle context, teams punish the wrong items and protect the wrong ones. 

The third mistake is separating finance from supply chain. Finance sees trapped cash. Supply chain sees service risk. Procurement sees supplier terms. Operations sees the shelf. Each view is true, but incomplete. A useful review brings those views together around one SKU list and one decision column. 

The fourth mistake is letting the report become the work. A turnover dashboard can become a very polished way to say “we have slow movers.” That is not enough. Every flagged item needs an owner, a next action, and a review date. If the action is “monitor,” set a date and a threshold. Otherwise “monitor” becomes a polite word for “ignore.” 

This is where the paired how-to earns its place. Once Reading inventory turns by SKU in Oracle Fusion SCM gives you the list, the leadership work is deciding what each slow mover is allowed to become: consumed, transferred, returned, sold down, redesigned, or stopped. 

One practical meeting format helps. Put the top fifteen slow movers on screen. For each item, ask: who ordered it, why was it ordered, what demand did we expect, what changed, and what decision is needed now? Keep the answer short. If nobody in the room can explain why the stock exists, the next action is not more analysis. The next action is ownership with named owners. 

One more question is worth adding: what will stop this item from returning to the list next quarter? If the reorder rule stays unchanged, the team may clear today’s stock and recreate tomorrow’s pile. Close the loop by changing the buying rule, supplier agreement, forecast review, or lifecycle status. Dead stock is expensive. Repeated dead stock is a management habit. 

The key insight: dead stock is rarely bad luck. It is often the result of an inventory decision that was once reasonable but is no longer relevant and now needs clear ownership and action. 

Start with the ERP Maturity Quiz to see whether your Oracle Fusion setup is ready for this kind of KPI-led review. Then use Business Value Maximization to connect the metric to cash and service outcomes. If you want to baseline slow movers inside your own Oracle Fusion environment, request a Value Discovery session. For the technical half of this series, pair this article with Reading inventory turns by SKU in Oracle Fusion SCM and use Second Sight as the process-mining capability inside the engagement.