Operating model options

The overview course (sap-tst-401) introduced three TCoE models: centralized, federated and hybrid. That comparison is a good start, but it hides the real design work. An operating model is not one choice; it is five separate choices that can be set differently. This lesson takes them apart, shows how SAP-specific factors push each one, and follows Contoso as its model has to stretch for the Monterrey acquisition.

Five design dimensions

Dimension	Central end	Federated end	What usually decides it
Where testers sit	In one TCoE team	In business units or product teams	How specialized the processes are, and how far apart the units are
Who owns test assets	TCoE owns the regression pack, data recipes and automation	Each team owns its own	Whether processes are shared across units
Who sets standards	TCoE, approved by a quality council	Each unit	Audit and regulatory needs; shared systems
How it is funded	Central run budget	Unit or project budgets	Covered in sap-tcoe-401
Where release decisions sit	One quality council and release board	Unit release boards	Whether units share one SAP system and transport path

Five dimensions of a TCoE operating model. Each can sit at a different point between central and federated.

Seen this way, "hybrid" stops being vague. Contoso's hybrid is central on standards, asset ownership and release decisions, mixed on where testers sit (a central core plus key users in the business), and mixed on funding (run budget for core services, project budgets for demand services). Writing your model as five settings makes it explainable and lets you change one dimension without redesigning everything.

SAP factors that push the dial

One system, many units. When several business units share one SAP S/4HANA system and one transport path, a change for one unit can break another. Shared regression assets and one release decision follow almost automatically.
Several SAP products. SAP S/4HANA, SAP SuccessFactors, SAP Ariba and BTP extensions each have their own release rhythm and specialist skills. Specialist cells inside the TCoE, or federated product teams with central standards, often work better than one generic pool.
Partner contracts. If an application management (AMS) partner runs functional support, its testers may be the federated layer. The TCoE then has to own standards and evidence review, or nobody does.
Deployment. Public Edition upgrades arrive on SAP's schedule for every unit at once, which favors central coordination. Private Edition lets you choose timing, which gives units more room.
Maturity. A new TCoE usually starts more central, because standards and assets do not exist yet. Federation works only once there is something consistent to federate.

Do units share one SAP system and transport path?Yes → central asset ownership and one release decision · No → units may own their assets
Are standards and evidence audited across the company?Yes → central standards · No → unit standards may be acceptable
Do units have specialist processes and their own skilled testers?Yes → embed testers in units · No → keep testers in the central core
Is the TCoE less than a year old?Yes → start more central and federate later · No → federate where the measures support it

A decision path for setting each dimension. The answers usually produce a hybrid, but a specific one.

The Sign-Off Table · thesignofftable.com/academy/sap-tcoe-402

Contoso's model, and how it stretched

Contoso started with a core of five in Detroit, twelve named key users, a partner call-off and SAP Cloud ALM as the system of record. Then Wave 2 began adding company code 1910 in Monterrey, which loads into the same S/4HANA system at its February 2027 go-live. Monterrey has its own order-to-cash team, Spanish-speaking key users, Mexican tax and e-invoicing requirements, and a different working calendar. Moving all its testing to Detroit would have been slow and would have lost local knowledge. Letting Monterrey test on its own terms would have put the shared system at risk, because a pricing or output change for 1910 travels through the same transports as everything else.

The answer was a satellite cell: one Monterrey test coordinator and a group of local key users who run functional and acceptance tests for 1910 using the central standards, the central regression pack and SAP Cloud ALM. The central TCoE owns shared assets and the release decision for the whole system. Only one dimension changed (where testers sit), and the rest of the model held.

Contoso's hybrid for Wave 2: a satellite cell tests locally with central standards, assets and one system of record.

The Sign-Off Table · thesignofftable.com/academy/sap-tcoe-402

What would you do?

Monterrey's order-to-cash lead asks for "our own test standards and our own regression pack for 1910, so we don't wait on Detroit." Company code 1910 is being added to the same S/4HANA system and transport path as 1710. What should Priya propose?

Hands-on lab · ACCELQ

Split asset ownership like a hybrid TCoE

In a hybrid TCoE the central team owns shared building blocks and project teams compose them into their own tests. In ACCELQ that split maps to reusable Actions (central) and Scenarios (project). This lab shows why one central fix reaches every team.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first. Play the central TCoE: create a Context for the cart app's home page, then an Action named "Open category" with an input parameter for the category name.
Record the Action with the Web Recorder: click a category in the list. Replace the hard-coded category with the Action Parameter so the Action works for any category.
Play project team A: create a Scenario "Team A browse" that starts with Initiate Browser Session on the app URL and calls "Open category". Add one Test Case row with any category you see.
Play project team B: create a second Scenario "Team B add to cart" that reuses the same "Open category" Action, then records adding any product to the cart.
Open the Application Universe and select each Scenario. Note that both paths pass through the same Action.
Play the central team again: improve "Open category" by adding Verify Element Exists on the product list after the click. Run both Scenarios and confirm both now include the check.
Write down which assets you would let a project team change and which only the central team should change, as a line for your RACI.

Done when Both Scenarios pass and both include the verification added once to the shared Action. Keep the two Test Reports and your one-line ownership rule.

Learn more in ACCELQ’s docs: Calling an Action inside another · Application Universe · Action Input Parameters

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

An operating model is five settings: where testers sit, asset ownership, standards, funding and release decisions.
A shared SAP system and transport path pull asset ownership and release decisions to the center.
Several SAP products, AMS contracts, deployment model and maturity all move the dial.
Start more central; federate one dimension at a time when there is something consistent to federate.
Contoso added a Monterrey satellite cell by changing only where testers sit.

Five design dimensions

SAP factors that push the dial

Contoso's model, and how it stretched

Lesson check