The gap between what a role redesign is designed to cost and what it actually costs once deployed is real and measurable. On one estate the designed cost sat 61.5 percent below what the package actually ships, and the shipped saving was zero. Price what you deliver, not what you drew.
The number on the slide and the number in production are not the same number
Across four client redesigns, the gap between the designed cost and the shipped cost ranged from under 1 percent to 61.5 percent of the shipped bill, and on the largest-gap client the shipped saving was zero while the design promised much more. That is not rounding. It is the distance between a cost the design assumes and a cost the shipped package produces on day one, and it is the single most important thing to understand before anyone quotes a figure to a CFO.
A saving becomes bankable only when the deployed package actually delivers what the model priced. Until then it is a design target, not a result.
Why read-only substitution does not ship a read-only price
Most of this gap comes from one mechanism. When the optimization model finds a user who only reads data in a given module, it proposes substituting a read-only privilege for a write privilege, and it prices that user at the read tier, which is cheaper.
The problem is that the read-only privilege has to exist as a real object before it can ship. In D365 F&SC, a read-only variant is a separate security object, commonly built as a dedicated `_ViewV2` privilege. Until that variant is built and deployed, the package still ships the original write privilege. The user is still granted write access, so Microsoft's licensing rules still price that user at the write tier.
The result is a design that says read tier and a deployment that bills at write tier. The saving exists as designed. It does not exist as shipped.
The second leak: roles that were priced but never delivered
The read-only gap is the common case. There is a second, blunter one. Some redesigned roles never ship at all, mostly because their names collide with roles that already exist live in the environment (a redesigned role cannot be deployed over a live role of the same name), and in some cases because the role was itself rebuilt from a live role rather than created fresh.
On one client, users were priced as though they had already moved onto these new roles, and 123,144 dollars of the claimed saving rested on roles that were never delivered. The model moved the users on paper. The deployment could not. Any saving attributed to an undelivered role is a saving that does not exist.
The discipline: measure the gap, do not hide it
The honest way to handle this is to treat the designed-to-shipped gap as a ratio and report it on every client, rather than keeping a private list of which clients are affected. Every redesign has some gap. Stating it for all of them is what makes the number trustworthy.
Two checks make this concrete. Before quoting any saving, compare the user's designed seat rank against the seat rank the package will actually ship. Where they differ, the difference is unrealized until the read-only variants are built. And confirm that every role the model assigned users to is a role that will actually deploy, not one that collides with a live role.
The business case does not disappear when you do this. It splits honestly into two parts. There is the saving available today, which is what the shipped package bills. And there is the additional saving that unlocks once the `_ViewV2` read-only privileges are built, which is the business case for building them. Both are legitimate. Mixing them into one headline is not.
Bottom line
A saving you quote is a promise about a bill. If the package ships a write privilege, the bill shows the write price, no matter what the design intended. Report the as-shipped cost as today's number, report the as-designed cost as the target, and show the gap between them. On the client at 61.5 percent, the entire headline was a target, not a result: the package as shipped saved nothing yet. Telling the client which is which is the difference between a saving and a surprise.
Frequently asked questions
If the saving is not available today, is the redesign still worth doing?
Yes, on its own terms. Even where the money is entirely unrealized at launch, the redesign still delivers least-privilege access and cleaner security hygiene. The cost saving arrives when the read-only variants ship. Those are two separate benefits and both are worth stating plainly.
How do we close the gap so the saving becomes real?
Build the dedicated read-only privilege variants, often `_ViewV2` objects, so a read-only substitution ships a read-only grant instead of a write grant. Once the deployed package matches the design, the as-shipped cost falls to meet the as-designed cost and the saving becomes bankable.
Why not just quote the as-designed number and note it is a target?
Because a target quoted as a saving reads as a saving. The safe default is to lead with the as-shipped number, which is what the next invoice will reflect, and present the designed number as the upside that specific build work unlocks.