Cutting the number at the architecture, the contract and the licence. 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 fifteen, and this closes module three. The last four sessions have been about understanding indirect access, counting it, measuring it and pricing it. Today we turn the whole thing around and reduce it. There are three levers: architecture, which changes what creates documents, contract, which changes what your paper says is chargeable, and licence, which changes what you own. Only the first of those genuinely makes the problem smaller. The other two settle it, which is a different thing. And the order matters more than anything else in this session, because architecture takes quarters, contract windows open once a term, and buying takes a week. Most organisations run the three in exactly the wrong sequence, and I want to explain why that happens, because it is not stupidity. Three knowledge checks. Let's begin.
Five things by the end. First, name the three levers, know what each one actually changes, and understand why only architecture reduces anything. Second, cut the count: the six architecture patterns that reduce document creation, and roughly what each is worth in a real estate. Third, fix the paper: the five contract changes that shrink the scope of what is chargeable, and the very limited moments when they are available to you. Fourth, sequence the work, which means knowing why architecture goes first, contract second and buying last, and what happens when you do it the usual way round. And fifth, attribute before acting: break the count down by interface, because in most estates two or three integrations produce the overwhelming majority of the volume and the rest is noise.
The three levers, framed. Architecture: change what creates documents. The largest reductions live here, and they are slow, because they need engineering time you have to ask somebody else for. Contract: change what your paper says is chargeable. Nearly free at a renewal, and effectively impossible in the middle of an audit. Licence: change what you own. Fast, always available, and the most expensive of the three, which is a large part of why it gets chosen. And in order: architecture first, contract second, licence last, and most organisations run it backwards. Now, that is not because people are foolish. It is because the last lever is the only one procurement controls on its own, and the first two require other departments to care. Let's play a clip on that, because I think it is the most useful thing in this session.
Guest analyst clip. I want to explain why almost every organisation runs these three levers in the wrong order, because once you see the reason you can do something about it. It is not ignorance. Everybody in the room understands that changing the architecture reduces the exposure permanently and buying licences does not. The problem is organisational. The licence lever belongs to procurement and licensing, who are the people in the meeting. The architecture lever belongs to the integration team, who report elsewhere, have their own roadmap, and were not invited. And the contract lever belongs to legal and to a negotiation window that may be a year away. So when a deadline appears, the only lever the people in the room can actually pull is the expensive one. And they pull it, and they are not wrong to, given where they are standing. The fix is not a better argument in that meeting. By then it is too late. The fix is to start the architecture conversation eighteen months before you need it, when nothing is urgent and an engineering manager can put a small change into a normal release without any drama. That conversation costs almost nothing when there is no deadline attached to it, and it is impossible to have well when there is.
The only lever the people in the room can pull is the expensive one. That is the structural problem in one sentence, and the practical response is a calendar rather than an argument. Find your next renewal date, count backwards eighteen months, and put the architecture conversation there. It will feel far too early. That is the point. Everything in this session that is worth doing needs more lead time than the moment of pressure will ever give you.
So what does each lever actually change? Worth separating, because they get discussed as alternatives and they are not. Architecture reduces the count: fewer initial documents created by non SAP systems means a smaller number under any pricing model, and it is the only lever that reduces exposure rather than covering it. Contract reduces the scope: definitions, exclusions, caps and an agreed measurement method decide what the count includes at all, and that is far cheaper than buying, and only available when the paper is open. Licence covers the rest: once the count is as small and as clearly defined as you can make it, you buy what remains. And evidence holds all three together, because every one of them is defended with the pack from session thirteen, and without a before and after count you cannot show that a reduction happened. That last point deserves emphasis. A reduction you cannot evidence is worth nothing in a negotiation, because the other side is working from their own figure and yours has no working attached to it.
Six architecture patterns. Batch rather than per event: one consolidated document instead of one per transaction, and the effect is large wherever the interface is chatty and the business can tolerate a delay. Read only where possible: query and display rather than creating a record, and this is often both large and free, because the record was never needed by anybody. Create at the head: one initial document rather than several in parallel, which is moderate and mostly a design review question. Stage outside SAP: validate and enrich before anything is written, moderate, and it cuts your error volume at the same time. Retire dead interfaces: integrations nobody consumes are still creating documents, and this is the cheapest work on the list by a distance. And route through a person: a licensed user reviews and posts instead of an interface, which is real at low volume and a bad trade at high volume. On that last one, be careful. It converts a licensing cost into a headcount cost. It works for tens of documents a week and it is indefensible for thousands, so do the arithmetic before anybody proposes it in a meeting.
First knowledge check. A supplier portal creates a purchase document for every line item on every order. What do you look at first? A, whether the portal can be retired altogether. B, whether it can create one document per order rather than per line. C, whether the suppliers could be given named user licences. D, whether the documents could be created in a test system instead. Pause here and pick one.
The answer is B. Consolidating at the right grain is the highest value architecture change available to you, and it usually needs configuration rather than a rebuild, which is what makes it realistic. A is worth asking and it is rarely available, because the portal exists for a reason somebody cares about a great deal. C converts a document cost into a user cost and is almost always worse at supplier scale, although it can genuinely work for a handful of very large partners with dedicated people. And D is not a mitigation, it is a misrepresentation, and it will be found, and I mention it only because somebody says it in about one workshop in five, usually as a joke that somebody else then takes seriously.
Now the paper. Five things to change. The counting definition: which systems, initial documents only, licensed user creations excluded, the object type mapping, and who runs the measurement. That is last session's clause written out in full. The document type list: named in your agreement with a change control mechanism, so the composition cannot move without you agreeing to it. A growth band: a volume corridor at an agreed rate, so ordinary business growth does not trigger a reactive purchase at list price in year two. Non production exclusion: explicit, and by system name where you can get it, because assuming it costs nothing to write down and a great deal to argue later. And measurement terms: notice, frequency, scope, and your right to run your own measurement alongside theirs and compare before anything is agreed. Now, the striking thing about all five is that none of them costs the vendor money on the day. Let's hear why that matters so much.
Guest analyst clip. Contract language is the most underused lever in enterprise software, and the reason is that people think about it as a legal exercise rather than a commercial one. Here is the way I would frame it. Every term on that list costs the vendor nothing today. A definition of how documents are counted does not reduce this year's revenue by a penny. A non production exclusion written down explicitly does not change what you are paying. A growth band at an agreed rate does not affect the current transaction at all. Which means these are terms an account team can agree without going anywhere near a discount approval, and that makes them extraordinarily cheap to obtain, if you ask at the right moment. And the right moment is when they want something. A renewal, a new product, an adoption offer, a cloud transaction, anything where there is a signature they need. In that moment, a page of clarifications attached to your side of the deal is a very small ask against a deal they are trying to close. Ask for the same page in a quiet month, with nothing on the table, and you will get a polite acknowledgement and no movement, because there is nothing in it for anybody. So keep the page written and ready. When the window opens, it is a five minute conversation. When it is closed, it is not a conversation at all.
Keep the page written and ready. That is a small operational habit with a very large payoff, and it is in the homework for that reason. The windows are short and they arrive with less notice than you expect, usually because somebody else in your organisation started a conversation you were not part of. If your asks exist as a document, you can attach them in an afternoon. If they exist as intentions, the window closes while you are drafting.
Second knowledge check. When is the cheapest moment to fix your indirect access definitions? A, when an audit letter arrives, since the issue finally has attention. B, at a renewal or any transaction where SAP wants something from you. C, immediately, in a standalone amendment request. D, after the move to the document model, while the terms are fresh. Pause here before you continue.
The answer is B. Contract language costs you almost nothing when it rides along with something the other side wants to close, which is exactly the argument the clip made. A is the single most expensive moment there is, because you are negotiating definitions while a claim is already sitting on the table, and every clarification you ask for now looks like an admission. C is honest, and it gets a polite no, because there is nothing in it for them and no reason to spend approval cycles on it. And D is too late for the definition that governs the move itself, which is precisely the one that matters most, and it is a very common regret.
The third lever, buying, which is a legitimate answer and it is the last one. Four things about it. It covers, it does not reduce: a purchase makes the exposure compliant, and the underlying volume is unchanged, and it carries on growing at exactly the rate it did before. Buy the curve: if you are buying, buy end of term volume at the better tier, per session twelve, because buying today's count guarantees a second purchase at a worse rate. Check what you own: existing entitlement, adoption credits and the unused licences from session eight all reduce what you actually need to buy. And time it deliberately: the same purchase made inside a negotiation where you have something to trade costs materially less than one made in isolation. Buying works on any timescale, which is exactly why it is over used. It is also the only one of the three levers where the money leaves the building. Let's hear that distinction made properly.
Guest analyst clip. There is a distinction I would like you to hold onto, and it applies well beyond this topic. Covering an exposure and reducing an exposure are not the same thing, and organisations routinely report the first as though it were the second. When you buy licences to cover indirect access, the compliance problem goes away. That is real and it has value. But nothing about your estate has changed. The same interfaces are creating the same documents at the same rate, and that rate is still tracking your business growth. So in three years you will be back, buying again, and the amount will be larger because the volume has grown, and you will have less leverage because you have already demonstrated that you buy when asked. Now compare that with an architecture change. You consolidate a chatty interface. The document count from that source drops by sixty percent and stays down. Next year it is still down. In five years it is still down, and it is down against a larger business, so the saving has grown rather than shrunk. That is a permanent change in your cost base rather than a payment. My rule of thumb is straightforward: if you have found yourself buying to cover the same exposure twice, then the first purchase was not a solution, it was a deferral, and somewhere behind it there is an architecture change nobody funded.
Buying twice means the first purchase was a deferral. So here is the timing, laid out. Retire dead interfaces: available any time with no permission needed, and the lead time is weeks and often somebody's afternoon. Consolidate the grain: available at the next release of that interface, one to two quarters with engineering effort. Read only redesign: at the next architecture review, one to three quarters and sometimes longer. Contract definitions: a renewal, a transaction or an adoption offer, and weeks of work inside a window that comes rarely. Growth band and caps: the same window as the definitions, so ask for both in one draft rather than two. And purchase volume: any time, best inside a negotiation, and days of lead time, which is exactly why it gets chosen. Read that last column and the order explains itself. If you wait until the renewal to start the architecture work, then on the day only one lever is available to you, and it is the expensive one.
Five ways mitigation fails. Mitigating without measuring: changing the architecture with no before and after count, so the reduction cannot be proved and never appears in any negotiation, which is a genuine tragedy because the work was done. Fixing the interface and not the paper: cutting the volume while leaving the definitions vague, so next year's argument is exactly the same argument with a smaller number in it. The human workaround at scale: routing thousands of documents through people to avoid a licence cost, and I would ask you to do that arithmetic honestly, because the licence is usually cheaper than the headcount and considerably cheaper than the attrition. Waiting for the renewal to start: architecture takes quarters, so beginning when the window opens means arriving at the table with nothing changed. And one off then nothing: reducing the exposure once, then adding four new integrations over two years without a document estimate on any of them.
Last knowledge check. You have eighteen months before your renewal. Where does the first month go? A, modelling purchase options at different volumes. B, attributing the count, which means working out which interfaces create most of the volume. C, drafting the contract language you intend to ask for. D, asking SAP to run their estimation service so you know where you stand. Pause here, and think about what has the longest lead time.
B. You cannot reduce what you have not attributed. Session thirteen's count, broken down by interface, tells you where the volume actually sits, and in most estates two or three integrations produce the majority of it. A is month twelve work and it is easy work. C is month nine work and it is genuinely valuable, just not first. And D hands over the framing before you have a position, which is now the third time this module has warned you about the same mistake, and I am not going to apologise for that either. Let's hear the argument for attribution, because it is the step people skip and it is the one that makes the rest possible.
Guest analyst clip. Attribution is the step that turns a licensing problem into an engineering problem, and engineering problems get solved. Here is what I mean. If you walk into an integration team's planning meeting and say we have a document exposure of two hundred thousand records a year and we need to reduce it, nothing happens. Not because they do not care, but because you have not given them anything to do. It is a number without an owner. Now walk in with the same total broken down by interface. The supplier portal produces a hundred and ten thousand. The e-commerce feed produces forty five thousand. Everything else combined produces the rest. Suddenly you are not discussing a licensing problem at all. You are having two conversations with two named people about two specific interfaces, and each of those is an ordinary engineering discussion about batching, or grain, or whether a record needs to be written at all. And in my experience the concentration is always higher than anybody expects. People imagine the volume is spread across dozens of integrations because their landscape diagram has dozens of boxes on it. It almost never is. Two or three sources dominate, and once you can name them, the work becomes finite, fundable and assignable. That is a week of analysis that unlocks everything else in this session.
It turns a licensing problem into an engineering problem. So, five things to keep the exposure down once it is down. Estimate every new interface: a document volume figure before it goes live, in the same review that already checks security and performance, and it takes about ten minutes if you ask at the right point. Quarterly count by interface, not just the total, because the breakdown is what tells you where growth is coming from and which owner to go and talk to. A standing reduction backlog: the architecture changes you have identified and not yet funded, each with the document volume it would remove, so that when budget appears you have a costed list rather than an intention. Contract asks kept ready: that one written page, so a window never closes while you are drafting. And review the paper annually: document type lists and measurement clauses drift against practice, so check them while nothing is at stake and nobody is arguing.
Three sentences, and then module three is done. Three levers cut indirect access exposure: architecture reduces the count, contract reduces the scope, and licence covers what is left, and only the first of those makes the problem smaller. Run them in that order, because architecture takes quarters, contract windows come once a term and buying takes days, so the slow work has to start first. And attribute the count by interface before you change anything, because two or three integrations usually produce most of the volume and everything else is a distraction. Next session opens module four, which is the S four HANA transition, starting with the twenty twenty seven and twenty thirty deadlines and what they actually force you to decide, as opposed to what you will be told they force you to decide.
Homework before session sixteen, about an hour. One, attribute the count: take session thirteen's number and break it down by interface, rank them by volume, and look at how concentrated the top of that list is. Two, ask about the top two, and it is one question to each owner: could this create fewer documents, or none at all, and what would that cost to change? Three, find the dead interfaces, meaning integrations still running with nobody consuming the output. Somebody knows which they are, so ask around before you start analysing. Four, write your contract asks: one page covering definitions, the document type list, a growth band, non production exclusion and measurement terms. Keep it somewhere you can find it in a hurry. And five, put a date on the window: your next renewal or transaction. That date tells you when the contract page becomes usable, and it tells you how much time the architecture work actually has.
Five guides, all on redresscompliance dot com. The indirect access pillar guide covers exposure, models, mitigation and defence in one place, and it is the written version of this whole module. API and indirect access changes explains how API based integration is treated, which drives several of the choices on slide five directly. BTP integration mandate costs covers what routing integration through BTP does to the cost, and that is worth reading before you design around it rather than after. The top ten Digital Access negotiation recommendations rank the contract asks from slide eight by what each is actually worth, which helps when you can only get three of the five. And the indirect access liability report shows where the exposure sits across the market and how much of it is avoidable, which is useful context when you are making the internal case for the engineering time.
That is session fifteen, and that is module three complete. You can now count indirect access, price it, read somebody else's measurement of it, and reduce it. Next time we open module four with the S four HANA deadlines. See you then.