One operating model across OCI, SaaS, and hyperscaler spend: the dashboard, the rhythm, the forecast, and the QBR. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session twenty six of thirty, and the opening of the final module: governance and capstone. Modules one through five taught you to buy, count, negotiate, and defend, one contract at a time. Module six is about the estate as a whole, and it opens with a question I want you to sit with for a second: who, in your organization, currently holds the complete picture of your Oracle relationship? The OCI burn, the SaaS utilization, the BYOL positions on AWS, the support annuity and its rewards offset, the renewal dates, all of it, one person, one page. In most estates I have seen, the honest answer is: the Oracle account team, and nobody on your side. They assemble that picture every quarter for their own forecast calls. Today is about assembling yours: the three meters problem, the estate dashboard, the operating rhythm, the forecast, chargeback that actually changes behavior, and the QBR run as your meeting. Whoever holds the whole picture runs the relationship. Let's make sure it is you.
Five takeaways. One, the problem: three meters, or really four, with different billing physics, watched by different teams on different rhythms, and why that fragmentation is a negotiating disadvantage, not a bookkeeping annoyance. Two, the dashboard: the one page that states the estate, four panels, each a comparison with a clock attached, refreshed monthly. Three, the rhythm: the operating cadence that consolidates every ritual this course has built, the burn review, the gap ledger, the renewal programs, the annual platform rerun, into one calendar with one owner. Four, the forecast: the estate's spend projected from consumption, workforce, and the renewal wall, so that budgets and negotiations start from your number instead of their quote. And five, the QBR: the quarterly business review transformed from a sales call you attend into a negotiation venue you chair. None of today is new work, and that is the point: it is the same disciplines, consolidated, and consolidation is the thing the fragmented estate was missing.
The three meters problem, which is really four. Meter one, OCI Universal Credits: consumption against a committed pool, monthly burn, expiry dates, forfeiture risk, session seven's whole drama, typically watched by cloud operations, if anyone. Meter two, SaaS subscriptions: fixed quantities billed regardless of use, true ups that travel only upward, watched by application owners, usually at renewal, usually too late. Meter three, the hyperscaler positions: BYOL license consumption on AWS and Azure, marketplace burn against EDP and MACC commitments, module three's whole territory, watched by the infrastructure team, invisibly to procurement. And meter four, the support ledger: the twenty two percent annuity, offset by Support Rewards where OCI consumption earns them, watched by procurement once a year, with a sigh. Four meters, four billing physics, four owners, four spreadsheets that have never met. And on the other side of the table: one account team, with one internal view that shows all of it, your burn, your utilization, your renewal dates, your growth trajectory, assembled quarterly for their forecast calls, because your estate is their pipeline. That asymmetry is the fragmentation's real cost. Every negotiation in this course assumed you knew your position; the three meters problem is how estates end up not knowing it. The rest of the session is the repair.
The estate dashboard, one page, four panels, monthly. Panel one, commitments: OCI credit burn against commit and expiry from session ten, marketplace burn against the hyperscaler commitments from session fourteen, every pool, its balance, its clock. Panel two, utilization: the gap ledger's headline numbers, billed against active per SaaS line, and the BYOL census from module three, licenses allocated against licenses owned. What is paid for, against what is used, the whole estate in one comparison. Panel three, offsets and annuities: the support ledger with the Support Rewards accrual running against it, session nine's napkin promoted to a standing metric, what support costs net, this month, and which direction it trends. Panel four, the clocks: renewal countdowns for every material contract, T minus months, notice windows, and, critically, a named owner per clock, the calendar from module five given the front page it deserves. Four panels, and one design test that governs all of them, stated negatively: nothing on this page should be a number the account team knows and you do not. Their internal view is effectively this page, assembled about your estate, for their benefit. The dashboard exists to reach parity, and parity, it turns out, is cheap: four queries and a calendar. First check is about what does not belong on the page, which matters as much as what does.
First check. Building the estate dashboard, the team proposes four panels: OCI list price savings percentages, Oracle's adoption scores from the success portal, total historical spend since twenty twenty, and this month's login counts. What belongs on the front page instead? A, all of them, more data is better governance. B, decision driving numbers with clocks attached: commit burn against expiry, billed against active, net support after rewards, and renewal countdowns with owners, because a dashboard exists to trigger actions, not to describe the past. C, just total spend, executives only read one number. Or D, whatever Oracle's own dashboards show, mirrored. Pause here, and run each proposed panel through one filter: what decision would this number ever trigger, and when?
The answer is B, and the filter does all the work, so apply it to each casualty. List price savings percentages: manufactured by the vendor's own list price, decorating every quote ever printed, triggering nothing, session eighteen's rule that percentages lose to dollars applies to dashboards exactly as it applied to bundles. Adoption scores from the success portal: the vendor's metric, engineered to defend the base at renewal, valuable as intelligence about what they will argue, poisonous as your own governance signal. Total spend since twenty twenty: a description of decisions already made, fires nothing forward, belongs in a board appendix, not on an operating page. Login counts alone: raw material, not signal, they matter only as the active half of billed against active, which is already panel two. Now look at what survives, and notice the shared anatomy: every panel in B is a comparison, actual against committed, paid against used, cost against offset, with a clock attached, expiry, cycle, notice window, and a name that acts when a threshold trips. Commit burn at sixty percent with four months to expiry fires a decision, session seven's rebalancing conversation, immediately. Spend since twenty twenty fires a slide. C underestimates every executive I have ever briefed, and one aggregate number steers nothing. D outsources your governance to your counterparty, which is the three meters problem wearing a dashboard costume. The design rule: every panel is a decision waiting to fire. Decoration goes elsewhere.
The operating rhythm, four cadences, and I want you to notice while we walk it that there is nothing new here, only consolidation. Monthly: the dashboard refresh, burn, deltas, threshold breaches, and the leaver deprovisioning pass, which is sessions ten and twenty three, the burn review and the hygiene ritual, now on one calendar entry. Quarterly: the gap ledger pass, the forecast update, the fuse diary check, and the resistance log review, session twenty three's hour, now feeding the estate view instead of a lonely spreadsheet. Per event: the renewal program spinning up at T minus twelve for each approaching clock, the exit file refreshed annually, claim responses run through session twenty five's verify, dispute, price method. And annually: the platform comparison rerun from session fifteen, the commitment strategy review from session ten, and the estate forecast rolled into next year's budget. Four cadences, one calendar, one owner, one pack. The consolidation is the entire innovation, and it earns something specific: when the account team assembles their quarterly picture of you, the rhythm guarantees a current picture of yourself already exists. Which brings us to the person who taught me why that matters, on an estate where it did not. Let's hear Tom.
Guest analyst The engagement that made me a governance evangelist was a manufacturing group, about eleven million a year across the full Oracle spread: OCI, Fusion ERP and HCM, BYOL databases on AWS, and a support ledger nobody loved. My first week, I asked my standard opening question: show me the whole position, one page. What I got was four teams and four artifacts. Cloud operations had an OCI burn spreadsheet, current to the month. The ERP owner had a seat count from the last renewal, eighteen months stale. Infrastructure had a BYOL tracker that disagreed with the license inventory by forty licenses. Procurement had the support invoices. Nobody had the marketplace burn, and nobody, and I mean nobody, knew the Support Rewards balance, which turned out to be four hundred thousand dollars of accrued offset that had been quietly expiring unclaimed for two years. Then came the part I tell every client. In month two, the Oracle account director presented their QBR deck, and slide three was the whole estate: every meter, every trend, every renewal date, beautifully assembled, better than anything the client owned about themselves. The room went quiet in a way I will not forget. The vendor knew the estate better than the estate did, and everyone suddenly understood what that had been costing at every table for years. The fix took ninety days, and it was embarrassingly simple: one analyst, four queries, one monthly page. The first pack found the expiring rewards, an OCI commit tracking to sixty percent, and nine hundred idle Fusion seats. The renewal that followed came in twenty two percent under the prior run rate. Not because anyone negotiated harder. Because for the first time, both sides of the table were looking at the same picture, and only one side had been surprised by it.
Slide three of the vendor's deck was a better picture of the estate than the estate owned about itself, and the silence in that room cost eleven million a year to learn. One analyst, four queries, one monthly page, and the next renewal came in twenty two percent under run rate. Parity is cheap. Second check.
Check two, chargeback design. You are allocating the Oracle estate's costs to business units. Which of these allocations is wrong? A, OCI consumption to business units by the compartment and tagging structure from session ten. B, Fusion ERP named user costs to the functions whose users hold the seats. C, the full HCM Hosted Employee subscription charged to the HR department, since HR runs the system. Or D, support and its rewards offset netted before allocation, so units see true cost. Pause here. Who drives the Hosted Employee count: the department running the system, or the units employing the people?
The wrong one is C, and the principle it violates is chargeback's only rule: allocate to whatever drives the cost, because chargeback is not accounting theater, it is an incentive system, and incentives only work when they land on someone who can act. HCM bills per Hosted Employee. The driver is headcount, and headcount belongs to every business unit in proportion to its workforce; HR merely operates the system, the way facilities operates the building without paying everyone's rent. Charge the whole subscription to HR and two things break at once: HR carries a seven figure line it cannot influence by any decision available to it, and the divisions whose hiring plans, contractor strategies, and seasonal patterns actually move the count, everything session sixteen taught about the definition sweep, experience workforce systems as free. Allocate per employee by unit instead, and the divisional president planning six hundred seasonal hires watches the subscription line move in the plan, which is precisely the visibility that makes session nineteen's definition amendments and down lane clause worth negotiating. The other three are correct, each for its own instructive reason. A: compartments and tags exist exactly to make consumption attributable, that was their session ten job description. B: named user costs follow the seats, and a function that hoards licenses funds its own hoard, which makes the deprovisioning ritual socially self enforcing, the cheapest control money never spent. D is the subtle one: allocate gross support while the rewards offset sits centrally, and every unit's Oracle cost looks worse than reality while the offset's value disappears from view, so net first, then allocate. The general rule: consumption to consumers, seats to holders, workforce to employers, every allocation aimed at the person who can change the number.
Forecasting the estate, five inputs, one output, and the purpose stated up front: your number, before their quote. Input one, the consumption trajectory: OCI burn trended and seasonally adjusted, projected to commit expiry, which is the data feed for session seven's resize decision, replacing the sales team's growth assumption with your own measured curve. Input two, the workforce projection: headcount plans mapped against the Hosted Employee bands and definitions, so hiring waves, acquisitions, and divestitures get priced before they arrive as true ups, session nineteen's counting questions answered a year early. Input three, the renewal wall: every renewal in the next twenty four months, with its expected uplift, capped or not, and its right size potential from the ledger, and be honest with yourself, the forecast's biggest swings live in this input, a single uncapped renewal moves more than a year of OCI drift. Input four, the program pipeline: the migrations, rollouts, and new modules sitting in the project portfolio, priced with module four's discipline while they are still plans, because a program priced before commitment negotiates, and a program priced after commitment pays. And the output: one estate number, by quarter, by meter, with scenarios, feeding the budget and anchoring every negotiation. The strategic effect is the one that matters: when the account team presents their growth model of your estate, and they have one, you answer with yours, and the conversation happens between two forecasts instead of around one.
The QBR, owned. The quarterly business review happens either way, the account team will see to that, so the only live question is whose meeting it is, and the two versions share a calendar invitation and nothing else. Their QBR: adoption dashboards that defend the base, session twenty five taught you to read those, roadmap slides that seed next year's expansions, success plans that convert to SKUs, and an action list where, read it back afterwards, every action is yours and every outcome is theirs. That meeting is attended, not run. Your QBR: your dashboard opens the meeting, burn, utilization, net support, clocks, four panels, five minutes, and the tone of everything after changes, because the room has just learned who holds the picture. Then your issues list: the stalled module, the throttled API from the exit rehearsal, the credit at risk of expiry, service items with owners and dates. Their roadmap gets heard, genuinely, it is useful intelligence, and logged in the resistance ledger for the gate to answer later, never answered in the room. The standing agenda: commitment status, service issues, forecast alignment, contract housekeeping, and expansion pitches routed to the single channel per session twenty three. The QBR feeds the files, and the files feed the renewals. One sentence to carry: bring the dashboard and the meeting is yours; arrive without it and it is a sales call with your logo on the slides. Last check is the QBR in action.
Last check. At the QBR, Oracle presents an adoption dashboard showing two of your modules at thirty percent utilization. Their proposal: a funded adoption success plan, plus consolidating both modules into a larger suite subscription at the renewal. The analyst hears: A, a helpful vendor offering to fix an adoption problem. B, the vendor documenting your right size case for you: thirty percent utilization is renewal evidence for the ledger, the success plan defends their base, and the suite consolidation converts documented shrinkage into contracted growth. C, a reason to cancel the QBR format. Or D, an accusation of shelfware that requires a defensive response. Pause here. Whose evidence is a thirty percent utilization number? And which direction does each party need it to move the renewal?
The answer is B, and the method is to read the incentives before reading the slides. A thirty percent utilization number is perfectly ambidextrous, and both parties are racing to make it mean their thing. For you, it is session twenty two's right size case, printed by the vendor's own telemetry, the one source they can never dismiss, handed over voluntarily, in a deck, with their logo on it. For them, it is the problem the success plan exists to solve before the renewal, because utilization driven upward defends the base, which is why vendor adoption programs cluster so reliably in the pre renewal year, generosity with a calendar. And the suite consolidation is the same play at double strength: two modules at thirty percent become one bigger subscription, documented shrinkage alchemized into contracted growth, session twenty two's flat if you add mechanics wearing QBR clothes. So the response is neither gratitude nor defense: log their number in the gap ledger, dated, sourced to their own deck, which makes it the strongest entry the ledger will ever hold, thank them sincerely, and route both proposals through the gate, the success plan judged on whether you actually want that adoption, the consolidation judged as the renewal position it is. A hears customer success where the compensation plan says sales. D is exactly backwards, their number is not an accusation to rebut, it is evidence to bank, and the only way to lose this meeting is to argue with data you should be filing. C burns a valuable venue because the other side played it well once. The rule: everything presented at a QBR is either intelligence or evidence. Both belong in your files, and neither requires an answer in the room.
The operating model, the minimum structure that makes everything stick, three pieces. The owner: one named role that owns the Oracle estate across every meter, the dashboard, the files, the single channel, the QBR chair. It can be a fraction of a person, in mid size estates it usually is, but it cannot be a fragment of four people, fractional is fine, fragmented is fatal, and the test is simple: when the account team calls, one person answers, and when your side calls, one person dialed. The pack: the monthly one pager plus the quarterly deep dive, dashboard, ledger movements, forecast deltas, upcoming clocks, distributed to the executives who own renewals and hold the walk away numbers, because session twenty four taught us the walk away only works when its owner has been living with the numbers, the pack keeps the table warm between events. And the picture: remember why all of this exists. The account team assembles their complete view of your estate every quarter, for their forecast, without asking your permission. The operating model's entire purpose is that at every table, in every review, your picture is at least as complete as theirs. That parity is what FinOps buys, and as Tom's ninety day fix showed, it is embarrassingly cheap: one analyst, four queries, one page. Next session, the same governance instinct turns to the paper itself: the contract inventory, the renewals calendar as strategy, and co termination across the whole estate.
Session twenty six, three sentences. One: the estate bills on four meters watched by four teams on four rhythms, while the account team sees one picture assembled quarterly for their own forecast, and that asymmetry, not any individual price, is what fragmentation actually costs, at every table, silently. Two: the repair is structural and boring, a one page dashboard of comparisons with clocks and owners, an operating rhythm that consolidates rituals you already learned, a forecast that produces your number before their quote, and chargeback aimed at whoever can change each number, consumption to consumers, seats to holders, workforce to employers. Three: the QBR is a negotiation venue where everything presented is either intelligence or evidence for your files, and the operating model, one owner, one pack, one picture, guarantees your view of the estate is never worse than your counterparty's. Whoever holds the whole picture runs the relationship. Next week: the paper estate, contract inventory, the renewals calendar, and co termination strategy. See you there.
Homework, about an hour, the first estate pack. One, draft the dashboard: the four panels for your own estate, commitments with clocks, billed against active, net support after rewards, renewal countdowns with owners, and rough numbers are completely fine, the shape is the deliverable, precision comes with the rhythm. Two, find the owner: who holds the whole picture today, and if the honest answer is the Oracle account team, write that down, verbatim, as finding number one, it is the most motivating sentence a governance program ever produces. Three, merge the calendars: the fuse diary from session twenty three, the renewal countdowns from twenty two, and the commitment expiries from module two, into one estate calendar, every date with an owner. Four, run one allocation: take the biggest subscription and allocate it by its true driver, workforce by unit or seats by function, then notice who has never seen this cost before, because those people are your future governance allies, nobody defends a budget line like the executive who just discovered they have one. And five, book the QBR: take the next business review invitation and send your agenda first, dashboard attached, and watch the meeting change character from the moment the agenda is yours. An hour of assembly, and the picture starts being yours.
Five reads before next session, all free on redress compliance dot com. First, the OCI FinOps framework, the consumption meter's operating model in full depth, the monthly rhythm's OCI half expanded. Second, OCI cost optimization, the tactical layer that lives underneath the dashboard's commitment panel, rightsizing, scheduling, the mechanics. Third, FinOps for enterprise software licensing, the discipline extended beyond cloud meters to the whole license estate, which is exactly the extension this session performed. Fourth, FinOps for SaaS licensing and software spend, the subscription meter's version of the same rhythm, the gap ledger's natural habitat. And fifth, the Oracle cost optimization playbook covering support, licensing, and cloud spend, the estate view in reference form, and a preview of how the capstone will think. That's session twenty six. Four meters, one page, one owner, and a vendor who is no longer the best informed party at the table about your own estate. Next week, the paper: inventory, calendar, co termination. Four sessions to the capstone. See you there.