Every S2P platform implies an operating model. It encodes assumptions about who raises requests, who reviews them, where exceptions escalate, and how decisions get made. Configure the platform and you have, by default, adopted those assumptions — whether you have examined them or not.
Most programmes never examine them. The platform gets configured. The organisation continues operating under the model it had before. Two operating models now run in parallel, and the space between them is where transformation quietly stalls.
A platform doesn't impose an operating model. It exposes the absence of one.
The Implicit Operating Model
Configuration is a series of architectural choices dressed as technical decisions. Approval thresholds, intake routes, category ownership, escalation paths, exception handling — each one is an operating model decision. Each one is usually made by a configuration consultant, not a business architect, and frequently made under time pressure with no clear principal accountable for the outcome.
The result is an operating model assembled by accident. It runs in the platform. It does not run in the organisation. Users navigate around it. Category managers continue making decisions the workflow says belong elsewhere. Approvals route to people without the authority to give them. The PMO ends up running a shadow governance layer because the official one was never properly designed.
Why It Goes Undesigned
Three reasons, consistently.
First, operating model design feels organisational, and organisational change feels political. So programmes quietly defer it. The deployment partner builds the system; the client tells itself "we'll figure out the org piece later." Later never arrives — at least, not in time to influence configuration.
Second, scope ambiguity. Nobody owns the operating model the way someone owns the platform or the change plan. It sits between technology and HR and procurement leadership, and falls between all three. What is everyone's responsibility becomes no one's deliverable.
Third, the misread. Programmes assume the operating model is a downstream consequence of platform deployment. It is not. It is an upstream design input. Get the sequence wrong and configuration locks in decisions that the operating model should have made first.
The Symptoms
The signals are reliable because they repeat.
- Duplicated work between centre and BUs. Both think they own the category. Neither has the mandate.
- Category managers becoming buyers. Strategic roles consumed by transactional escalations because the operating model didn't draw the line clearly enough.
- Approvals routing to the wrong people. The workflow is correct; the authority isn't. Approvers rubber-stamp because they can't credibly do anything else.
- Shadow governance. The PMO runs operational decisions through the steering committee because no operational governance forum was designed.
- Exception volumes that never drop. Every exception is a sign the operating model didn't anticipate a real-world condition. Persistent volume signals persistent design gaps.
Each symptom is typically diagnosed as a people problem. It isn't. It is an architecture problem manifesting as friction at the human layer.
What Good Looks Like
The operating model is designed before configuration freezes — not after. It defines decisions at the level of decision rights, not task assignments. It distinguishes between governance (what gets escalated, when, why) and execution (who does the work). It is documented, signed off by accountable principals, and treated as a deliverable in its own right — not an emergent outcome of platform deployment.
Most importantly, it is tested against the platform's implicit model. Where the two diverge, the divergence is either reconciled in configuration or made explicit as a known design tension. What you cannot afford is two models running silently in parallel, with the workforce caught between them.
Name the three operating-model decisions your last transformation deferred to "post-go-live." How many are still unresolved twelve months on — and how much of your current friction traces back to them?
Was your operating model designed — or did it just settle?