Standardisation as the price of the discount, and who that trade suits. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
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. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP 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 three. We have spent two sessions on RISE, which is the private edition path, and this one is about the other door: GROW with SAP, built on S four HANA Cloud public edition. I want to be careful with the framing from the start, because the way this product is usually introduced sends people to the wrong question. GROW is not RISE for small companies. It is a different offer, and the difference is about control rather than scale. Three knowledge checks, one of which has more than one defensible answer, so we will talk about the order you should think in. Let's begin.
Five objectives. First, describe the offer: S four HANA Cloud public edition with a fixed methodology, a preconfigured process set, and a release cycle you do not control. Second, state the real difference, because public against private is not a size question, it is a question about who decides how the software behaves. Third, find the extension boundary: where you may still build, on the platform rather than in the core, and what that means for the custom work you have today. Fourth, read the commercial model, which is FUE again, with a shorter and more standard contract and less to negotiate, and that cuts both ways. And fifth, judge the fit honestly, because GROW suits organisations that are willing to change process to match software, and that is a real decision rather than a technicality.
Four things to frame it. Public: one multitenant environment on a fixed release cadence, so you consume the standard rather than shaping it. Faster: preconfigured processes and a fixed methodology, and implementations are shorter precisely because the choices are already made. Cheaper to run: less to operate, less to test, less to maintain, and that saving continues long past go live. And less yours: no core modification, upgrades on SAP's calendar, and a scope boundary you work inside rather than around. The trade is explicit and it is reasonable. You give up the ability to make the software match your process, and in exchange you get speed, a lower running cost and a much smaller estate to look after. Let's deal with the framing problem head on.
Guest analyst clip.
Who decides how the software behaves. That is the question, and notice how much cleaner the conversation becomes once you ask it that way. Size stops being the argument. What replaces it is a genuine business question about whether your processes need to be yours, and that is a question the business can actually answer, unlike a question about employee thresholds that nobody can source. So let's look at what is in the offer.
Four components. The application: S four HANA Cloud public edition, licensed in FUE, with a defined scope of preconfigured end to end processes. The methodology: a fixed implementation approach with a defined scope, phases and acceptance, and it is faster precisely because it is not negotiable. The platform allowance: BTP credits for extension and integration, which is where all of your custom work now has to live. And the service: hosting, operations and upgrades, delivered on SAP's release calendar rather than yours, at two major releases a year. Notice that the shape here is the same as session twenty one, so an application, a platform allowance and a managed service. What changes between the two products is not the shape. It is how much of it you are allowed to alter.
Now the comparison itself, and I would encourage you to read the first row as the whole table. Core modification: not permitted in public, permitted in private, and often the entire reason to choose private. Extensions: on BTP through released APIs only, against in the system including classic ABAP. Upgrades: twice a year on SAP's calendar, against scheduled with you inside a service window. Scope: a defined set of preconfigured processes, against whatever your licence and your build can support. Implementation: a fixed methodology and a shorter programme, against your programme, your timeline and your cost. And best for: net-new, mid-market or a willing greenfield, against complex estates that carry real differentiation. Everything below the first row follows from the first row, because whether you may change the core determines which of these two products you are actually buying.
First knowledge check. A nine thousand person manufacturer with heavily customised ECC asks whether GROW is right for them. What decides it? A, headcount, since nine thousand is too large for public edition. B, whether they will drop the customisation and adopt standard process. C, their data volume and capacity requirement. D, whether they are already on a hyperscaler. Pause here and pick an answer before you continue.
The answer is B, and the deciding question is behavioural rather than technical. Large organisations do run public edition successfully and small ones sometimes genuinely need private edition, so headcount is a weak proxy at best, which rules out A. C and D are real considerations for sizing and for hosting, but neither one determines whether the product fits. What determines fit is whether the business will actually change its processes to match the software. If the answer is yes, GROW is fast and it is cheap. If the answer is no, and it very often is once you ask the process owners rather than the programme sponsor, then public edition becomes a rather expensive way to discover that.
So where may you still build? Five points. On the platform, not in the core: extensions live on BTP as side by side applications, and the core stays standard so that it can be upgraded without you. Through released interfaces only: you integrate through published APIs and events, and reaching into tables the way you could in ECC is simply not available. Key user tooling for the small things: fields, forms, simple logic and layouts are configurable in-app without a developer, and honestly that covers more than most people expect. The rest becomes a process decision: anything you cannot build has to be absorbed by changing how the business works, which is a decision with an owner and a cost. And consumption is metered, because everything you move onto BTP eats the allowance from session twenty two. Extension is permitted. It is not free. Now, on deciding what deserves to be built at all.
Guest analyst clip.
Advantage or sediment. I find that a genuinely useful test, and the reason it works is that it takes the argument away from the licensing team, where it does not belong, and puts it in front of the business, where it does. Nobody can really argue about whether a customisation is technically possible in public edition, because that is just a fact. But whether a process earns its difference is a question the business owns, and it is one that improves an organisation whether or not you ever move to the cloud.
Second knowledge check, and this one has more than one defensible answer, so think about the order rather than just the option. You need a bespoke pricing calculation that public edition does not support. What is the honest first response? A, build it in the core, since it is business critical. B, build it on BTP, and budget the consumption it adds. C, ask whether the requirement is genuinely differentiating. D, switch to private edition immediately. Pause here.
C comes first, and that is really the point of the question. Most requirements described as bespoke turn out to be habits rather than advantages, and the honest question is what separates the two. A is not available at all in public edition, which is the defining characteristic of the product. B is the correct answer once C has been answered and the requirement is genuinely differentiating, and it carries a real consumption cost you should budget for rather than discover. D is sometimes right, but reaching for it at the first unsupported requirement means you never established whether the requirement deserved to survive in the first place. So run C, then B, then D, in that order, and you will make far better decisions than an organisation that starts at D.
The commercial model. Four points. Still FUE: the same weights from session twenty two, so all of your classification work carries over exactly, and you should do it before the baseline here too. A more standard contract: less bespoke drafting, fewer negotiated clauses, faster to sign, and less room to shape the terms you actually care about. Lower implementation cost: the fixed methodology genuinely does shorten the programme, and this is usually the largest single saving in the whole comparison. And the same three questions: renewal mechanism, exit terms and the overage rate all still matter, because a standard contract is not the same thing as an unnegotiable one. That last point is where I see the most money lost, so let's hear it properly.
Guest analyst clip.
A no is information. That is the line to hold onto, because it reframes the whole exercise. You are not trying to win every clause in a template agreement, and you probably will not. You are trying to find out which of the terms that matter are actually movable, and the only way to find that out is to ask. The organisations that get renewal caps in standard contracts are, overwhelmingly, the organisations that asked for them.
So who does public edition actually suit? Five profiles. Net-new entities: a new subsidiary, a carve-out, a greenfield business unit, where there is nothing to unlearn and the standard costs you nothing to accept. Mid-market with a thin estate: few modifications, few integrations, no appetite to run a platform team, and there the saving on operations is the whole case. Organisations with genuine standardisation intent, and I mean intent rather than aspiration, measured by whether the process owners have already agreed in writing to drop their variants. A two tier strategy: private edition at the centre for the differentiated core, public edition at the edges for subsidiaries, which is a common shape and it works well. And not, emphatically, a complex estate looking for a discount, because if your customisation carries real advantage then public edition removes the advantage and the discount does not come close to compensating.
Five traps. Choosing it on price: picking public edition for the lower cost and then trying to rebuild your old processes inside it, which is genuinely the most expensive route available to you. Sponsor says yes, process owners say no: the standardisation commitment gets made in the steering committee and then rejected in practice, about six months into the build. Underestimating BTP consumption: every extension you were going to build in the core now consumes the allowance, and the allowance was sized for rather less than that. Ignoring the release cadence: two upgrades a year on SAP's calendar means a permanent regression testing commitment, so budget the people and not just the licence. And skipping the contract read: treating a standard agreement as a non negotiable one, and leaving renewal, exit and overage exactly as drafted.
Last knowledge check. Which recurring cost do organisations most often leave out of a GROW business case? A, the subscription itself. B, regression testing for two releases a year. C, hosting and infrastructure. D, Digital Access for indirect use. Pause here before you continue.
B. A and C are always in the case, because they arrive as invoices, and D is usually remembered by anybody who has worked through module three. B is the one that goes missing, because it is a people cost rather than a vendor cost, and no invoice ever announces it. Two releases a year means a permanent testing capability: your integrations, your BTP extensions and your critical process flows all need verifying on SAP's calendar rather than yours. It is not an enormous number, but it is annual, it never stops, and a business case built without it understates the running cost in a way that surfaces about a year after go live. Let's hear why this one is so consistently missed.
Guest analyst clip.
No supplier, so no line item. Right, five things for living with a release cycle you do not control. Automate the regression pack, because twice a year forever justifies the investment very quickly, and manual testing on somebody else's calendar becomes a standing tax on your team. Read the release notes early, since they arrive before the release does, so treat them as a planning input rather than a surprise and staff the window properly. Keep extensions thin, because every BTP extension is something to retest and something that consumes, and fewer, simpler extensions age considerably better. Watch the allowance monthly, since consumption grows quietly exactly as it did in session twenty two. And hold the standardisation line, because requests to recreate the old way will keep arriving for years, and somebody senior has to keep saying no. That is a named job, not a good intention.
Three sentences. GROW is S four HANA Cloud public edition with a fixed methodology and a preconfigured process set, and it is a different offer rather than a smaller one, because the difference is control rather than scale. You cannot modify the core, extensions live on BTP through released interfaces and consume the allowance, and upgrades arrive twice a year on SAP's calendar, which is a permanent regression testing commitment you should price. And the metric is still FUE while the contract is shorter, so do the classification work before the baseline and read renewal, exit and overage with exactly the attention you would give a private edition deal. Next session is the decision itself: RISE against on premise against staying where you are, including what the ECC option really looks like beyond twenty thirty.
Homework before session twenty four, about an hour, and most of it is conversation rather than spreadsheet. One, count your modifications: how many core modifications does your current system carry? That figure is the first honest input to the public against private question. Two, ask a process owner rather than a sponsor: pick one heavily customised process and ask the person who actually runs it whether they would accept the standard. Their answer is the real one. Three, separate habit from advantage: take three customisations and write one sentence each on what competitive advantage they deliver, and notice which ones do not survive the sentence. Four, price the testing: what would twice yearly regression testing cost you in people? Put a number on it and add it to any GROW case you are shown. And five, read one release note, found from a recent public edition release, and read it as though you had to plan around it, because that is the rhythm you would be signing up to.
Five guides, all on redresscompliance dot com. GROW with SAP explained covers the whole offer component by component, with the entitlements spelled out rather than summarised. Public against private edition takes slide five into much more detail, including the extension boundary we walked through. SAP BTP consumption and CPEA tells you what extension actually costs once all of it has moved onto the platform, which is the number most GROW cases get wrong. RISE versus S four HANA on premise is the third option, and it is exactly where session twenty four goes next. And RISE negotiation tactics covers renewal, exit and overage, all of which apply to a GROW contract just as much as to a private edition one.
That is session twenty three. The thing to take away is that public against private is a control decision rather than a size decision, so answer the standardisation question honestly before you answer anything else. Next time, the decision itself. See you then.