Module by module licensing, who actually needs a subscription, and the implementation partner's incentive problem. 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 eighteen of thirty. Two sessions of foundations, the metrics and the order, and now the biggest room in the SaaS house: Oracle ERP Cloud, meaning Fusion ERP, EPM, and SCM, which together are usually the largest line on an enterprise's Oracle SaaS bill and the longest commitment on its books. Today has a specific ambition: by the end, you should be able to look at an ERP Cloud quote and answer three questions the quote is designed to keep vague. Which modules does this actually require? Who in my organization actually needs a subscription? And whose data produced these quantities? That third question has an uncomfortable answer more often than not, and it gets its own section, because the party that usually sizes these deals is the party whose fee grows when the deal is oversized. Let's start with the map.
Five takeaways. One, the landscape: Fusion ERP, EPM, and SCM module by module, what each does, what each prices on, and the dependency chains, which modules require which bases. Two, the packaging: base subscriptions versus add ons, per module floors, and why the module list on a quote is a negotiation artifact before any price appears. Three, the scoping: who actually needs a Hosted Named User subscription, core users, workflow approvers, report consumers, integration accounts, and the casual use line that quietly decides half the quantity on most deals. Four, the incentive problem: why the implementation partner's sizing arrives generous, the tells that reveal it, and the counter that keeps quantities honest. And five, the initial deal: start narrow, hold prices, cap renewals, everything module four has taught, applied at ERP dosage, where the numbers are biggest and the term is longest. This is the session where the course's discipline meets the course's largest checks.
The landscape, three pillars. Fusion ERP: financials is the base, the ledger, payables, receivables, assets, and around it the expansions, procurement, projects, risk management. This is the pillar most deals start with, and it prices per Hosted Named User, per module, with floors. Fusion EPM: the CFO's analytical layer, planning, financial consolidation and close, account reconciliation, tax reporting, narrative reporting, also named user per module, and note the profile now because it returns later: small user counts, premium rates, and a floor on every line, EPM is where floor arithmetic bites hardest. Fusion SCM: inventory, order management, manufacturing, logistics, product lifecycle, named users for the humans plus transaction metrics on the volume modules, order lines and shipments, the session sixteen transaction family earning its keep. And the fourth row of the table is not a pillar but it decides deals: the connective tissue, approval workflows, reporting, integrations, the populations that touch every pillar without living in any of them, which is exactly where the scoping arguments live. One more thing the map must show: the pillars sell separately but deploy entangled, procurement needs financials, planning consumes the ledger, order management drives receivables. That entanglement is technical and commercial at once, and the commercial half is called packaging.
Packaging, three mechanics that shape every quote before a single price appears. First, base plus add on: add on modules require their base subscription, advanced collections rides payables and receivables, which ride financials, and the add on you asked for quietly carries bases you did not price. Map the dependency chain before comparing quotes, because two quotes with different module lists are not comparable until you know what each list actually requires. Second, per module floors, session sixteen's minimums multiplied: every module line carries its own floor, so a broad module list at small quantities bills mostly floor, and the design principle follows directly, fewer modules deeper beats many modules thinner. That EPM profile from the map is the worked example: a twelve person FP&A team running five EPM modules is routinely floor priced on every single line, five floors for twelve people, which makes the EPM section of any quote the first place I look for savings. And third, the suite temptation: bundled everything pricing, all the modules, one big discount, it looks efficient and it reads as generosity. It also subscribes you to modules years before any deployment, and session sixteen's rule has not stopped being true: unused subscriptions are not credit at renewal, they are evidence of budget. The bundle gets a full knowledge check later, with arithmetic. First, the scoping question, because quantities matter more than module lists.
First check. A Fusion Financials deployment touches three populations. Forty five accountants work in the ledger daily. Three hundred managers approve invoices and expenses through the workflow. Eleven hundred employees receive monthly PDF reports generated from the system. Who needs a Hosted Named User subscription? A, all fourteen hundred forty five, everyone the system touches. B, only the forty five accountants, approvers and readers are casual use. C, the forty five accountants, and the three hundred approvers if they act inside the service; the eleven hundred receiving distributed reports outside the service typically do not count, and that line gets confirmed in writing at the order. Or D, the forty five accountants plus a site license for everyone else. Pause here. Three populations, three different relationships to the service. Which of them are using it, as the service description defines use?
The answer is C, and the dividing line to internalize is acting inside the service versus receiving output from it. The forty five accountants are unambiguous, they live in the module. The three hundred approvers are the population that decides the size of the deal: approving an invoice inside the application is using the service, so workflow approvers generally need subscriptions, and look at the arithmetic, three hundred against forty five means the approvers are eighty seven percent of the quantity. Which yields one of my favorite observations in this course: approval workflow design is secretly a licensing decision. Route approvals through fewer, more senior approvers, use delegated approval pools, and the subscription count moves by hundreds. Nobody designs workflows with the license bill in the room, and the license bill attends every workflow anyway. The eleven hundred report recipients: receiving a PDF the system pushed to you, outside the service, is typically not use, distribution is output, not access. But typically is doing real work in that sentence, service descriptions draw the casual use line in slightly different places, which is why C ends with session seventeen's move, the line confirmed in writing at the order. B underlicenses by three hundred and becomes a renewal finding with interest. A overlicenses by eleven hundred, and D names a license that Fusion does not sell. Now, the full population table.
The four populations, the whole scoping method on one slide. Core users: always subscribed, they live in the module, and the lever is hygiene, right size by role and run the monthly deprovisioning ritual from session sixteen. Workflow approvers: usually subscribed, acting in the service is use, and the lever is the one the last check surfaced, approval design, fewer approvers and delegated pools move the count by hundreds. Report consumers: not subscribed if the output reaches them outside the service, and the lever is architectural, distribute reports rather than provisioning viewers, a reporting portal that pushes PDFs beats eleven hundred read only accounts by exactly eleven hundred subscriptions. And integrations and bots: service accounts, priced per the service description's integration terms, and the lever is naming them explicitly at the order, because silence about integration access at signature has a way of becoming a finding at renewal. The method is the point: scoping runs population by population, never headcount by headcount. A deal priced at two thousand undifferentiated users has skipped this table entirely, and if the table was skipped, someone else did the sizing with someone else's method. Who that someone usually is, and what their method optimizes for, is the next section, and our guest analyst has the story that names the problem.
Guest analyst The question I now ask first on every ERP deal is: who sized this, and what did they use? I learned to ask it on a manufacturing client's Fusion program. The proposed order was two thousand two hundred users across ERP and SCM, and the number came from the integrator's sizing workbook, a beautiful document, role matrices, module maps, very thorough looking. Then we pulled the client's identity system and counted people who actually held finance, procurement, and supply chain roles: eight hundred and fifty, and the approval chains added maybe two hundred more. The workbook had been built from the design document, every persona that might conceivably touch a workflow in some future phase, five divisions of future, when the funded program covered two. When we challenged it, the integrator defended the number for about twenty minutes and then conceded it was a planning envelope, their phrase, not a license recommendation. Here is the thing: nobody had lied. The workbook answered the question the integrator cares about, how big could this program be, and it had been quietly repurposed to answer a question it was never built for, how many subscriptions should the customer buy. The client signed at one thousand fifty with price holds on the rest, saved about one point four million a year, and the program has never once been blocked by license capacity. My rule since: the party whose fee grows with the scope does not get to set the quantities. They can propose, but the license number comes from the customer's identity data, and every delta between the two gets defended line by line, out loud.
A planning envelope repurposed as a license recommendation, two thousand two hundred proposed, one thousand fifty signed, one point four million a year in the gap. Nobody lied, and that is exactly the point: the incentive did the work without anyone needing to. Second check tests the counter.
Check two. Your implementation partner's sizing workbook proposes two thousand four hundred Fusion ERP users. Your identity system shows eight hundred fifty people holding finance, procurement, and approval chain roles combined. The funded go live covers two of your five divisions. The right initial order is: A, two thousand four hundred, the partner knows the product and growth will catch up. B, around nine hundred to a thousand, sized from your own identity and role data for the divisions actually deploying, with price holds securing the expansion quantities at today's rates. C, eight hundred fifty exactly, buy to the census and add users one at a time. Or D, split the difference at sixteen hundred as a compromise. Pause here. Whose data sized the twenty four hundred? Whose money pays for it? And what does a price hold cost?
The answer is B, and the reasoning starts with provenance: the twenty four hundred came from a workbook authored by a party that pays nothing per subscription, the eight hundred fifty came from your identity system, and data does not become less true because a partner's deck is prettier. B buys the deploying population with honest headroom, the approval chains and onboarding churn justify sizing above the raw census, call it nine hundred to a thousand, and moves the other fourteen hundred into price holds, which is the elegant part: a hold costs nothing today, preserves today's unit rate and discount for the divisions that deploy in year two, and converts Oracle's future captive pricing into today's competitive pricing. Session seventeen's clause, doing seven figure ERP work. A signs fourteen hundred subscriptions for divisions without a go live date, and remember the mid term asymmetry, quantities go up any Tuesday and come down never, every signed unit is a floor until renewal. C is too tight the other way: no headroom for the approver populations that check one showed are most of the count, and adding users one by one later means pricing every addition naked, without deal leverage. D is the one to be rude about: splitting the difference between a defended number and an undefended one is not compromise, it is donating seven hundred fifty units to the undefended side. The midpoint of a right number and a wrong number is a wrong number. Provenance, then population, then holds. That is the method.
The incentive problem, stated plainly and without villains, because Tom is right that nobody has to lie for this to cost you money. The incentive: the integrator's fee scales with scope, more modules, more users, more phases, a bigger program, and the subscriptions land in your budget, not theirs, so sizing generosity costs them nothing and enlarges everything they bill for. The mechanism: workbooks built from the design document, every persona that might someday touch a workflow, rather than from your identity data, everyone who actually holds the role today. The tells, learn them: round numbers, user types with no differentiation between core users and approvers, module lists that mirror the demo script, and no population table underneath the total. When you see those four, you are reading a planning envelope, not a license recommendation. The counter: separate the sizing from the implementation. Quantities come from your identity and role data, assembled or at least reviewed by someone whose fee does not grow with the answer, your SAM team, procurement, an independent advisor, and the partner defends every delta against your data, line by line, in a meeting. And the accountability move that closes the loop: if the workbook claims twenty four hundred users by year two, then the program plan that gets twenty four hundred users live by year two becomes the partner's contractual deliverable. Watch how fast planning envelopes deflate when the author has to deliver them.
Negotiating the initial deal, the module four toolkit at ERP dosage. Start narrow, hold wide: buy the modules and users deploying in phase one, and price hold everything you can already name, the phase two modules, the expansion quantities, the rates. Holds cost nothing at signature and everything after it, because the alternative is buying phase two from a vendor who knows you cannot leave. Ramp and cap: the ramp matched to the go live plan, session seventeen's arithmetic, no full quantity billing fourteen months before deployment, and the renewal cap on the first order, and here is the ERP specific reason the cap matters most in this room: ERP renewals arrive with switching costs at their theoretical maximum, your ledger, your close process, your procurement flows all live inside the service, and the cap is the only sentence in the stack that argues back on your behalf when leverage is gone. Floors and swaps: challenge every per module floor with the billed to real ratio written down, EPM lines first, and take swap rights between modules so that phase two guesses become adjustments instead of shelfware plus new spend. The through line for the whole slide: an ERP subscription is a decade long relationship priced in a six week sales cycle, and every protection on this slide is cheap in week six and unbuyable in year four. Last check, and it is the bundle.
Last check. Oracle offers an enterprise ERP bundle: all Fusion ERP, EPM, and SCM modules, twenty five hundred users, thirty eight percent discount. Your modular plan covers phase one at twenty two percent. The bundle subscribes you to SCM modules with no deployment planned before year three. The analyst's read: A, take the bundle, thirty eight beats twenty two and the modules will get used eventually. B, compare spend against deployment: the bundle bills years of undeployed SCM at any discount, the modular plan plus price holds at bundle level rates captures most of the discount on the spend that is real, and shelfware anchors the renewal. C, take the bundle but plan to drop the SCM modules at first renewal. Or D, reject both and stay on premises. Pause here. Thirty eight percent off what, exactly? Compute both plans in dollars deployed, not percentages quoted.
The answer is B, and the arithmetic is the one the quote is built to prevent you from running: thirty eight percent off a basket padded with three years of undeployed SCM modules is routinely more absolute spend than twenty two percent off the footprint you are actually deploying. A discount percentage is only meaningful against spend that buys something, and the bundle's extra discount is funded by subscriptions that buy nothing until year three, if ever. The analyst's counter is the middle of B, and it works: demand bundle level unit rates on the modular footprint, with price holds carrying those same rates to the SCM modules for the day they deploy. That captures the discount without renting the shelfware, and a seller facing a competitive evaluation will move a long way toward it rather than lose the deal, the thirty eight was never sacred, it was bait. C underestimates the anchor: at renewal, the bundle is your installed base and your demonstrated budget, dropping the SCM modules triggers repricing of everything that remains because the discount was built on the whole, and session twenty two will show you that unbundling at renewal is the single hardest move in SaaS. A buys percentages instead of value, the oldest trade in procurement and still the worst. D abandons a business case over a packaging problem. The rule that should survive this course in your muscle memory: never compare discounts, compare dollars against deployment, and treat any quote that leads with its percentage as a quote that loses on the dollars.
The ERP buyer's playbook, the session on one page, three groups. The maps: the module map with dependency chains and floors marked, so no add on smuggles in an unpriced base; the population table, core, approvers, consumers, integrations, with counts from identity data; and the EPM lines with billed to real ratios computed, because that is where the floor money is. The independence: sizing separated from implementation, quantities defended against your data by someone whose fee does not grow with the answer, and the partner's adoption assumptions written into the partner's own contract, the accountability move. The paper: session seventeen's checklist at ERP dosage, ramp to go live, price holds on the named phase two modules and quantities at today's rates, the renewal cap because ERP switching costs make it worth more here than anywhere, swap rights, floors challenged in writing, and the casual use line confirmed. File all three groups together and you have something rare: an ERP deal where every number has a defended provenance. Next session runs the same discipline into HCM Cloud, where the metric flips from Hosted Named User to Hosted Employee, and the counting argument changes from who uses it to who works here, which is a harder question than it sounds.
Session eighteen, three sentences. One: ERP Cloud prices module by module with floors and dependency chains, so fewer modules deeper beats many modules thinner, the add on you want carries bases you must price, and the EPM lines are where the floor arithmetic bites hardest. Two: quantities are argued population by population, core users always, workflow approvers usually, which makes approval design a licensing decision, report consumers outside the service typically not, and the casual use line goes in writing at the order. Three: the partner who sizes the deal profits from oversizing it, so license quantities come from your identity data with every delta defended, expansions ride price holds instead of day one subscriptions, and discount percentages always, always lose to dollars against deployment. Next week: HCM Cloud, the Hosted Employee metric at scale, global workforce counting, and the levers specific to the system that counts everyone. See you there.
Homework, about an hour, and this one produces the most immediately negotiable document in module four: rebuild your ERP sizing from your own data. One, pull the populations from your identity system: who actually holds finance, procurement, and projects roles today, and who sits in the approval chains, real names, real counts, not workbook personas. Two, build the population table: core, approvers, consumers, integrations, per module, the table the sizing workbook should have contained and probably did not. Three, compare against the order: billed quantities per module against your table, ratio per line, star everything above one point two, same threshold as session sixteen. Four, check the EPM lines specifically: every module against its real user count and its floor, because a twelve person team on five floor priced modules is savings sitting in plain sight. And five, trace the provenance: for your last ERP order, whose data produced the quantities? If the answer is the partner's workbook, then the delta you just computed is the price of the incentive problem, denominated in your own subscriptions. Take that number into the next renewal. It argues better than any adjective.
Five reads before next session, all free on redress compliance dot com. First, ERP Cloud modules explained, bases versus add ons, the dependency chains and packaging mechanics module by module, today's map in reference depth. Second, Oracle ERP Cloud module pricing, the rate card landscape underneath the floor arithmetic. Third, how to negotiate Oracle ERP Cloud pricing, the CIO and procurement playbook for the initial deal, including the bundle counter we ran in the last check. Fourth, the Fusion ERP negotiation guide, levers and sequencing for the deal and for the renewal that follows it. And fifth, Oracle EPM Cloud licensing, the premium corner of the pillar, where small teams meet many floors and the savings hide. That's session eighteen. The biggest line on the SaaS bill now has a method: map the modules, table the populations, own the sizing, hold the prices, cap the renewal. Next week we count the whole workforce. See you there.