From a raw query to a figure that survives challenge. 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 thirteen. Last time we did the theory of Digital Access: the nine document types, the four counting rules, the exclusions and the shape of the price curve. Today we do the work. This is the session where you take a raw query result and turn it into a figure that survives somebody else looking at it hard. Scope, query, subtractions, evidence, and reconciliation against SAP's number. It is about a day of effort and I want to be honest that it is not glamorous work. It is also the difference between walking into a renewal with a position and walking in with an opinion, and that difference is usually worth more than anything else in this module. Three knowledge checks as always. Let's begin.
Five things by the end. First, fix a scope: decide your systems, your period, your document types and your creator populations before you run anything, and write that decision down. Second, run the count properly, which means pulling creations by type by month, keeping only the head of each chain, and storing the query alongside its output. Third, apply the four subtractions in order: follow on documents, licensed user creations, non production systems, and types outside the nine. Fourth, build the evidence pack, which is four artefacts that turn a number you can state into a number you can defend. And fifth, reconcile against SAP, because when their figure differs from yours, every possible source of the gap is a factual question with an answer.
Four things to frame the day's work. Scope first: systems, period, types and creators, all decided before the query runs, because a scope set afterwards looks like an adjustment however correct it happens to be. One method: one documented query that a colleague could rerun and get the same figure, since reproducibility is what makes a count evidence rather than a claim. Two numbers: yours and SAP's, and the gap between them is the entire negotiation, and you can only explain a gap you can trace to specific rows. And three years, because the figure that matters is the run rate at the end of the term rather than the count today. Here is the sentence I would keep from this whole session. A number without a method is an opinion. Let's play a clip on that, because I think it is worth hearing from somebody who has watched it go wrong.
Guest analyst clip. I want to describe a meeting I have sat in more than once, because it explains why this session exists. Somebody has been asked to work out the Digital Access exposure. They are competent, they are busy, and they run a query. It gives them a number. They put the number on a slide, they add the words first pass estimate underneath it, and they present it. And here is what happens next. The caveat evaporates within about ten minutes. By the second meeting the number has no caveat at all. By the third it is in a board pack. And nobody involved is being dishonest. It is simply that a figure spoken out loud in a serious room acquires a life of its own, and the qualifications do not travel with it. Now, the number was probably two or three times too high, because nothing had been subtracted yet. So the organisation spends the next four months walking a frightening figure back down, and every step of that walk looks like special pleading, because you are arguing against a number your own side produced. Compare that with spending one more day before you speak. Same person, same query, same data, but the scope is written, the subtractions are applied, and the working is attached. That day is the cheapest insurance available in this entire subject, and almost nobody takes it.
The caveat evaporates within about ten minutes. That matches what I have seen, and it is worth taking seriously as a practical rule: do not say a document number out loud until it has been through the subtractions on slide eight. Not to your CIO, not to procurement, and certainly not to SAP. A raw count is not a draft of the real number. It is a different quantity, measuring something the model does not price. So let's start where the day starts, which is before the query.
Four scope decisions, and each of them moves the answer materially. Which systems: production only, named explicitly, with test, development, sandbox and training excluded and the exclusion recorded rather than assumed. Which period: twelve consecutive months, never a busy month multiplied by twelve, because seasonality is real and annualising a partial year falls apart the moment anybody examines it. Which document types: the nine as your own agreement words them, mapped to the specific tables and object types in your system, and that mapping is genuinely the hard part of the exercise. And which creators: technical accounts and interface users are in scope, while documents your own named users created through the SAP interface are out, because their licence already covers those. Write all four on one page before you start. That page becomes the first item in your evidence pack, and its real function is to stop the exercise turning into a negotiation with yourself once you can see the numbers.
Now the query itself, in five steps. Identify creators: the technical and interface accounts in your production systems, and record the account list along with which interface each one belongs to, because that mapping is what lets you attribute volume later. Pull creations: document header tables, filtered on creator and creation date, and record counts by type by month rather than a single annual total. Keep the head only: use the preceding document fields on each record to drop the follow ons, and write down how many records that removed and what ratio it represents. Split by system: capture the source system on every record and keep production separate from everything else, always. And sign and date it: whoever ran it, on the day they ran it, with the query text stored alongside its output. On that second step, counts by month by type is not administrative fussiness. A single number tells you nothing about seasonality, nothing about which interface is driving your volume, and nothing about where to look when somebody challenges the figure.
First knowledge check. Your query returns six hundred and twenty thousand records for the year. Before you tell anyone, what do you do first? A, report it with a caveat that it is a first pass. B, strip the follow ons and the licensed user creations, then look again. C, divide by twelve as a sanity check on the monthly rate. D, ask SAP to run their estimation service and validate it. Pause here and pick one.
The answer is B. The two large mechanical reductions come off before anybody sees the figure, because a number said out loud is very hard to withdraw, which is exactly what the clip described. A is how a frightening figure enters a boardroom with a caveat nobody remembers by the second meeting. C is a genuinely useful check and it is not the first one, because it validates the shape of a number that has not been filtered yet, and a clean monthly distribution on a wrong total is a false comfort. And D hands over the framing before you have a position at all, which is the error session twelve spent an entire clip on.
So, the subtractions, in this order. Follow on documents: every record with a preceding document in the same chain, and this is usually the largest single reduction, commonly taking between a half and two thirds off a raw count. Licensed user creations: documents your own named users created through the SAP interface, which are already covered by their licence and should never have been in an indirect count in the first place. Non production systems: test, development, sandbox and training, and you check the source system on each record rather than trusting that the query was scoped correctly, because it frequently was not. Types outside the nine: records your query caught that are not on the list in your agreement, so map every object type you counted to a named document type or drop it. And then one note rather than a subtraction: write down the borderline cases you deliberately kept, and why. The order matters more than people expect, and so does the discipline of recording each step. Let's play a clip on that.
Guest analyst clip. The subtractions are simple arithmetic. The thing that makes them powerful is writing them down as you go, and I want to explain why, because it took me a while to appreciate it. Picture two versions of the same conversation. In the first, you say the number is one hundred and forty eight thousand. Somebody asks how you got there. You say you filtered out the follow on documents and the internal users. They ask how much that removed. You say a lot. That conversation is now about you, not about the estate. In the second version, you hand over a single page. Raw count, six hundred and twenty thousand. Less follow on documents, three hundred and ninety one thousand, being sixty three percent, with the chain rule cited. Less named user creations, sixty two thousand. Less non production systems, fourteen thousand, from these three named systems. Less object types not on the agreement list, five thousand. Final figure, one hundred and forty eight thousand. Now the conversation is about the estate, and the only available challenges are specific. Somebody can argue that one of your systems really is production, and that is a real discussion with a real answer. Same arithmetic in both versions. Completely different meeting. And the second version costs you about twenty minutes of typing while you are already doing the work anyway. That is the best return on twenty minutes anywhere in this course.
The only available challenges are specific. That is the whole principle of an evidence pack in one line, and it applies well beyond document counting. A number presented alone invites people to question your judgement. A number presented with its derivation invites people to question a step, and a step is something you can either defend or correct in an afternoon. Both outcomes are fine. What you are avoiding is the third outcome, where the argument is about whether you are reliable.
Second knowledge check. Your figure is one hundred and forty eight thousand. SAP's estimation service returns one hundred and ninety thousand. What is the most useful next step? A, accept theirs, since their tooling sees things your query does not. B, reconcile, and find which types and systems produce the forty two thousand gap. C, split the difference and negotiate from one hundred and sixty nine thousand. D, refuse to discuss their figure until they publish their method. Pause here before you continue.
The answer is B. A gap of forty two thousand is not a disagreement about principle. It is a disagreement about specific rows, and it resolves by working out which document types and which systems produce it. A surrenders a position you did a day of work to build, and does so on an assumption about their tooling that may not even be true. C negotiates against arithmetic, which is the one thing in this model both parties can actually settle, and settling it is to your advantage. And D is a reasonable instinct expressed as an ultimatum. Ask for the method, absolutely, but ask as a question inside the reconciliation rather than as a precondition to having one, because the precondition version costs you weeks and makes you look like the difficult party.
Four artefacts, and together they are the day's real output. The scope statement: systems, period, document types and creator populations, written before the query ran, one page, dated, with a named author. The query itself: the actual report definition or SQL, stored with its output, so a colleague can rerun it next year and get the same figure. The subtraction ledger: raw count, then each reduction with its size and its reason, down to the final number, and a reader should be able to follow it end to end without asking you a single question. And the growth model: the three year projection, the rate you used, and where that rate came from, and finance's own forecast is the strongest source available to you for that. There is a second argument for this pack that usually gets it funded, which is that it makes next year's refresh a two hour job rather than a repeat of this one. Let's hear that made properly.
Guest analyst clip. I want to make the business case for the evidence pack, because in most organisations somebody has to justify the day it costs. The compliance argument is obvious and I will skip it. Here is the one that actually works. Licensing positions are not annual events. They are living things that get asked about at unpredictable moments, usually by somebody senior with no notice. A vendor letter arrives. An acquisition closes and finance wants an exposure figure by Friday. A new integration goes to architecture review and somebody asks what it costs. If your document count exists only as a number in somebody's head, every one of those moments is a fresh two week project. If it exists as a scope page, a stored query, a subtraction ledger and a growth model, every one of those moments is an afternoon, and often less. I have watched teams rebuild the same count three years running because nobody kept the working. Three separate multi week exercises, each producing a number slightly different from the last for reasons nobody could explain, which incidentally destroyed their credibility with their own finance function. The pack is not paperwork. It is the difference between owning a position and re-deriving one under pressure, every single time somebody asks.
Three separate exercises producing three slightly different numbers, for reasons nobody could explain. I would add that the damage there is not really the wasted weeks. It is that the finance function stops believing any licensing figure the team produces, and once that has happened it takes years to repair. Consistency across time is a credibility asset, and the pack is how you get it more or less for free.
Five places the gap between two counts usually sits. Chain handling: the two counts treat follow on documents differently, and you find it by comparing one document type in one month and looking at the ratio. System scope: a non production system is in one count and not the other, so ask which systems were in scope and name yours explicitly. Type mapping: an object type is mapped to a document type in one count only, and you reconcile the object type lists rather than the totals. Period: different twelve months, or an annualised partial year, so fix both counts to the same calendar window and run them again. And user attribution: documents created by your named users being treated as indirect, which you resolve by matching creator accounts against your own user master. Notice something about that list. Every row is a factual question with an answer. None of them is a matter of opinion, which is the advantage of a countable metric and worth holding on to when a meeting gets tense.
Five ways a technically correct count still fails. Nobody can rerun it: the person who built the query left, or it lived in a spreadsheet on their laptop, and an unreproducible number is an anecdote with decimal places. The scope moved: systems or types were adjusted once the figure looked wrong, and even when the change is genuinely correct, making it after the fact damages the credibility of everything else on the page. A partial year annualised: three months multiplied by four, which seasonality makes wrong in both directions and which collapses the moment somebody asks how you got there. No growth attached: an accurate count of last year, presented as the answer to a question about a three year commitment. And it never gets refreshed: built once for one negotiation, then quoted for four years while the business grew around it. That last one deserves emphasis. A stale number is worse than no number, because people trust it.
Last knowledge check. You have a defensible count and a three year projection. Where does the figure actually go? A, into the negotiation file, ready for the renewal conversation. B, into the entitlement baseline as a tracked position, refreshed quarterly. C, into a report for the CIO, then archived. D, to SAP, so the account team can confirm you agree on the number. Pause here, and think about what session ten said about positions.
B. Same discipline as the engine register in session nine and the baseline in session ten. A position that is not maintained decays into a historical number, and a historical number is worse than none because people still trust it. A is also true, and only if it is being refreshed, or you arrive at the renewal quoting a figure that is two years old. C is how good work disappears, and it disappears quietly. And D sends your position across the table before you have decided what to do with it, which is a timing decision you should be making deliberately rather than by reflex. Let's hear the argument for treating this as a standing position.
Guest analyst clip. There is a habit I would like you to break, and it is the habit of treating a licensing number as a project deliverable. Projects end. You produce the count, you present it, everyone thanks you, and the file goes into a folder. Eighteen months later the renewal arrives and somebody opens that folder, and what they find is a number that was true once. Here is the better model, and it costs almost nothing once the first version exists. The count is a position, and a position has an owner, a refresh cycle and a trigger. The owner is a named person, not a team. The refresh is quarterly, using the same stored query against a new period, which is fifteen minutes of work. And the trigger is the distance to the next tier, because that is the number that actually requires a decision. Not the count. The gap. When the gap gets to a year of growth, you have a conversation about buying, and you have it on your calendar rather than on the vendor's. That last part is the whole point. A tracked position lets you choose the timing, and in every negotiation module later in this course you will find that timing is worth more than any argument you can make on the day. You cannot choose the timing if you do not know where you are.
A tracked position lets you choose the timing. So, five things to make it standing rather than a project. One owner: a named person owns the query and the number, exactly as somebody owns the engine register from session nine. Quarterly refresh: same query, same scope, new period, which is fifteen minutes once the method exists and catches growth while you can still act on it. Distance to the tier: report the count and the gap to the next threshold at current growth, because the gap is what triggers a decision, not the count. New interfaces go through it: every new integration gets a document volume estimate before it goes live, alongside the architecture review from session eleven. And an annual method review: once a year, check the document type list in your agreement against the mapping inside the query, because contracts change and mappings drift, usually silently.
Three sentences. A number without a method is an opinion, so fix the scope first, run one documented query, and record every subtraction with its size and its reason. The four reductions, follow on documents, licensed user creations, non production systems and types outside the nine, take most raw counts down by half or more, and the first two do the bulk of it. And a gap between your count and SAP's is a set of factual questions about types, systems, periods and attribution, and every one of them has an answer. Next session we look at the measurement from the other side: SAP's estimation service, what it does and does not see, and the Digital Access Adoption Program with the conversion credits that come attached to it.
Homework before session fourteen, about ninety minutes, and unlike most homework this one produces something you keep. One, write the scope page: systems, period, document types, creator populations, before you run anything. Half a page is enough, and it is the most valuable half page in the exercise. Two, run one type for one year. Sales documents, production only. Record the raw count before any subtraction, so the starting figure exists on paper. Three, build the subtraction ledger: each reduction with its size and its reason, down to the final number, and note what percentage of the raw count came off. If it is under forty percent, check your chain handling again. Four, store the query, meaning the actual text with its output and the date, somewhere a colleague could find it without asking you where it is. And five, attach a growth rate. Take the three year assumption from finance rather than inventing one, and project the count forward.
Five guides, all on redresscompliance dot com. What counts as a document goes through the types one by one, with the object mappings that make a query correct, which is the hard part of slide four. Digital Access measurement tools covers the tooling on both sides of the table and what each one actually measures, and it is the written companion to next session. The Digital Access cost calculator turns a verified count into a cost, including the tier behaviour, so it picks up where your final figure lands. The Digital Access audit defence guide is for the situation where the count you are shown is not the count you produced, which is precisely the reconciliation on slide twelve under time pressure. And the SAP audit defence framework generalises the evidence discipline from slide eleven across the whole estate, not just documents.
That is session thirteen. If you do the homework you will finish the week with a real document count and the working behind it, which is more than most organisations have. Next time, the measurement from SAP's side, and the adoption program. See you then.