Lesson 3 of 6
Operating model and governance
13 min
A service catalog says what the TCoE offers. The operating model says how it works: who is in it, how work comes in, how it is prioritized, what standards apply and who the TCoE reports to. Without one, a TCoE becomes a pool of testers that everybody borrows and nobody manages.
Roles
| Role | Responsibilities |
|---|---|
| TCoE lead | Service catalog, budget, standards, metrics, stakeholder management, sign-off support |
| Test architects / process test leads | Regression design per end-to-end process, release assessments, test strategy for projects |
| Automation engineers | Build and maintain automated tests; framework and tool standards |
| Test data and environment specialists | Data recipes, refresh and masking; environment calendar and readiness |
| Test analysts | Test case design and execution, evidence, defect reporting |
| Business test network | Named key users per process who join regression and UAT when needed |
| Partner capacity | Flexible testers and specialists under a framework agreement |
TCoE roles. A small TCoE combines several roles per person; the responsibilities still need owners.
Sizing the core team
Size the permanent core from the work that never stops: maintaining the regression pack after every release, running data and environment routines, building and fixing automation, and reporting. Peaks such as a feature pack upgrade or a plant roll-out are covered by the business test network and partner capacity under a framework agreement, so that you are not paying for peak staffing all year. Contoso started with a core of five (a lead, two process test architects, one automation engineer and one data and environment specialist), backed by twelve named key users and a partner call-off for upgrades.
Central, federated or hybrid
| Model | How it works | Strengths | Risks |
|---|---|---|---|
| Centralized | One team does all testing for all SAP change | Consistency, shared assets, clear accountability | Bottleneck; distance from the business |
| Federated | Standards are central; testing is done in business units or product teams | Close to the business; scales | Inconsistent evidence; duplicated assets |
| Hybrid | Central team owns standards, regression, data and tools; teams run their own functional testing | Balance of consistency and speed | Needs clear service boundaries |
Intake and prioritization
Requests should arrive through one front door, ideally the same demand or change process that IT already uses. Each request carries enough information to size it: what is changing, which processes are affected, the target date and the requester. The TCoE triages weekly, estimates and schedules against capacity, and escalates conflicts to a small governance group rather than resolving them by who shouts loudest.
- RequestThrough the standard demand or change process
- TriageWhich service, which processes, how urgent, how risky
- EstimateEffort, lead time, data and environment needs
- ScheduleAgainst capacity and the release calendar
- DeliverUsing TCoE standards and tools; evidence stored centrally
- ReportResults to the requester; metrics to governance
Standards
- Test policy and strategy templates: test levels, entry and exit criteria, risk-based scope.
- Test case standards: naming, structure, link to process and requirement, reusable building blocks.
- Evidence standards: what a passed test must show (who, when, system and client, expected vs actual, document numbers).
- Defect standards: severity definitions, mandatory fields, triage and retest rules.
- Automation standards: when to automate, maintainability rules, ownership of scripts.
- Tool standards: which tools are the system of record (for example SAP Cloud ALM for test management and defects) and how data is linked.
Governance and reporting lines
Where the TCoE reports shapes how it behaves. Reporting into the delivery organization keeps it close to change but can weaken its independence when deadlines bite. Reporting into a quality or enterprise architecture function strengthens independence but can distance it from delivery. Many companies place the TCoE in IT with a dotted line to business process owners, and set up a quarterly quality council (IT leadership, key process owners, the TCoE lead) that reviews metrics, approves standards and resolves priority conflicts.
What would you do?
Three Contoso projects each want the TCoE's two automation engineers in the same month. Each project manager says theirs is the top priority. What should the TCoE lead do?
- Define roles, including a business test network and flexible partner capacity.
- Most SAP customers use a hybrid model: central standards, regression, data and tools; local functional testing.
- Use one front door for intake, weekly triage, and a governance forum for conflicts.
- Write standards for tests, evidence, defects, automation and tools, and protect the TCoE's independence.
Check your understanding · not graded
Lesson check
1. In a hybrid TCoE model, what does the central team usually own?
2. Where should TCoE requests come in?
3. What is a quality council?
4. How should a decision to proceed against a negative TCoE assessment be handled?