Authorizations — Assigning roles too early, and rebuilding them later

This is the eighth article in the series "Inside a Large ERP Program." The previous one looked at testing as the only insurance a program actually buys itself. This one stays close to that moment, because the authorization stream is where a quiet design decision, taken months earlier, comes due at exactly the worst time.

The authorization stream almost always starts clean. It's set up like any other workstream, its design kicks off at the same time as the functional modules, and for most of the program nobody worries about it. Then it blocks at testing, a few weeks before go-live, when there's no slack left to absorb it. A stream that did nothing wrong at the start becomes the tension point at the end. That gap, between a healthy beginning and a painful finish, is the whole subject of this chapter.

This is a greenfield story. On a brownfield program the roles already exist, you carry them forward and adjust, and the mechanism below doesn't bite the same way. On a greenfield build, where every role is created from nothing against an organization being designed in parallel, it bites hard.

The false culprit: starting too late

The obvious explanation is that the stream started too late, and it's wrong. Authorizations are treated as a stream among others, design begins in step with the modules, and that's fine. There's no problem starting the design at the same time as everyone else. Starting on time is the right call.

So if the timing of the start isn't the problem, something else is moving underneath.

What actually moves: the transactions, not the organization

Here's the distinction that the whole chapter turns on. The business organization can be perfectly stable at design time. A company knows its legal entities, its plants, its profit centers, its reporting lines. What is not stable is the set of transactions attached to each role. Those keep moving through the entire build, up to the first go-live and, honestly, past it.

During design, the business maps its organization, and that organization is often complex. You come out of it with a wide variety of roles. But each of those roles is bound to transactions that won't be settled until go-live. So all through build, the authorization team is working against roles whose content keeps shifting. Every design arbitration that moves a process, every transaction that gets added or swapped in a module, lands on the role mapping and forces a rework.

That's the technical reading of the trap. The team isn't slow. It's building on a layer that hasn't stopped moving, and each movement costs more than it should because of what comes next.

The combinatorics that kill testing

More axis, more tests, exponentially

The rework is survivable during build. It becomes critical at testing, and the reason is combinatorial.

Take one position: a management controller. Now cross it with the organizational matrix. Factory controller or head-office controller. Then company code, profit center, plant. Then the fact that some of these people also touch accounts payable, others accounts receivable. By the time you've crossed the function with the full org matrix, a single position has produced something like a dozen roles to test. For one job.

Each of those has to go through unit testing, then integration testing. Multiply a dozen variants by every function in the scope and the test workload stops being a line item and becomes the thing that threatens the go-live date. This is where the early-mapping decision finally presents its bill. You designed the roles to match the organization in all its fineness, and now you have to prove every one of those fine combinations works, at the precise moment the program has no time left.

And the surface you have to prove is now larger than it used to be, because of the Fiori front-page layer.

The S/4HANA layer: front end and back end

On S/4HANA, a role isn't just a set of back-end transactions anymore. Access to a Fiori app rests on the launchpad layer (catalogs and, since the 2021 release, spaces and pages rather than the now-deprecated groups) sitting on top of the OData services that actually carry the business data.

How that splits across roles depends on the deployment. In a hub deployment, where the front-end server is separate from the back-end, you maintain two PFCG roles for the same access: a front-end role carrying the catalog, the space, and the OData start authorization, and a back-end role carrying the execution and data-access authorization. In an embedded deployment, the two can collapse into a single role. Either way, the point for testing is the same: an app can break at more layers than before. The tile may not show, the OData service may not start, or the back-end business authorization may be missing, and each is a different failure. On the hub projects I've worked, that meant validating the front and the back as two coordinated things, on top of a role count that was already exploding.

So the combinatorics from the previous section don't just multiply across the org matrix. They multiply across the interface layers too. Which is why, in practice, the program ends up doing the only sane thing left.

Nobody owns the pain, which is why nobody prevents it

Before the way out, it's worth being precise about who carries this, because that's why it's never anticipated.

There is no single owner. The SAP authorization team absorbs the technical rework. The functional teams on each module watch their transactions move, which moves the roles. And the business sees its own roles change often, with a real risk of regression each time a role is rebuilt. The pain runs through all three readings at once, technical, functional, and organizational, and that's exactly why no one stream sees it coming or holds it. A problem distributed across three owners is a problem owned by none of them. It surfaces only when it converges, at testing, as one undeniable workload.

That convergence is what forces the decision the program should arguably have planned for from the start.

The way out: cut wide for go-live

The simplest move, and the right one, is to cut directly for the first go-live. One controller role, restricted by company code or profit center. One wide role per domain, scoped by perimeter, rather than the fine matrix of variants the design produced.

Then you run a parallel targeting project on authorizations across the rollouts, refining the roles over time, at the pace of the business teams who can actually tell you where the fine lines should fall. The principle underneath is the one thing to take from this chapter: wide first, fine later. You defer the precision to the moment the perimeter is known, instead of designing it into the dark while the transactions are still moving.

This isn't a retreat from control. It's a reordering to secure the go-live. This leads some to object that the segregation of duties will not be respected. Let's address this point.

Segregation of duties: precision deferred, not control lost

Cutting wide does not mean SoD goes out the window. You keep a basic segregation of duties with a perimeter restriction. What you drop is the fine composite logic and the over-tight scoping.

Concretely: if a management controller also needs to do accounts payable, they get both wide roles. That's more roles assigned to that user than if you'd built a single tailored role, controller with an accounts-payable attribute and a few key transactions, but the wide roles are stable and the tailored one would not have been. Because every assignment is traced by the project, real SoD conflicts are rare. When one does appear, you grant the specific problem transaction on request, rather than pre-designing an exhaustive composite matrix to cover a case that may never occur. Same logic as the mapping itself: the precision is deferred, not abandoned.

What to take from this

Authorizations are not a design problem to be solved finely up front. They're a layer to be frozen as late as possible. The program that maps its organization into roles at design time pays for it at testing, in combinatorial workload, at the moment it can least afford to. The program that cuts wide for go-live and refines through the rollouts keeps control of its schedule and gives the business the precision later, when the perimeter has stopped moving.

It's the same shape of failure as the next stream in this series: a workstream everyone underestimates because its real complexity doesn't show until late, downstream, when the cost of having underestimated it is highest. That's where the next chapter goes: Data migration — Moving and cleaning the data the whole program depends on.