Lesson 2 of 6
Services and scope
12 min
A TCoE is easiest to fund, staff and measure when it is defined as a catalog of services: things other teams can ask for, with a clear description, an owner, a lead time and a cost. Services turn "the test team" into something the business can understand and plan around.
A service catalog for SAP
| Service | What the customer gets | Typical requester |
|---|---|---|
| Test strategy and planning | Test approach, scope, estimate and criteria for a change or project | Project managers, release managers |
| Regression testing | Execution of the maintained regression pack for a release, with a results report | Release manager, upgrade project |
| Test automation | Building and maintaining automated tests for stable processes | TCoE itself, release manager |
| Test data management | Data recipes, refreshes, masking, data sets on request | Testers, projects |
| Test environment coordination | Availability calendar, refresh planning, transport and interface readiness for testing | Projects, Basis |
| UAT facilitation | Planning, tester onboarding, tool support and evidence for business acceptance | Process owners |
| Upgrade and release assessment | Impact analysis of SAP releases on Contoso's processes and a targeted test scope | IT leadership, process owners |
| Quality reporting and sign-off support | Readiness reports and evidence packs for gates and audits | PMO, audit, process owners |
An SAP TCoE service catalog. Start with the services you can deliver well, and add others as you mature.
Core, flexible and out of scope
Be explicit about what the TCoE does not do. Developers still unit test their own work. Business process owners still accept or reject change. Security testing and performance engineering may sit with specialist teams. Writing these boundaries into the service catalog avoids the slow drift where "testing" becomes everything nobody else wants to do.
Choosing what to start with
A new TCoE rarely starts with every service. Pick by demand and risk: what change is coming in the next 12 months, and which processes would hurt most if they broke? For most S/4HANA customers the first services are regression testing (because upgrades and support packages are certain), test data (because nothing runs without it) and release assessment (because it keeps regression scope targeted).
Service levels
Each service needs a simple service level that requesters can plan around: for example, "regression results for a support package within 10 working days of the build being ready in QAS," or "test data for a standard order-to-cash scenario within 2 working days of request." Service levels make the TCoE predictable, and they expose bottlenecks: if data requests routinely miss their level, that is evidence for investing in data recipes. Start with levels you can meet, publish actual performance against them, and tighten them as capability grows.
What would you do?
Contoso's new TCoE has four people. Requests arrive for regression of a support package, a new performance testing service, test data for an enhancement, and automation of the full order-to-cash process. What should the TCoE lead prioritize?
- Define the TCoE as a catalog of services with owner, lead time and cost.
- Separate always-on core services from on-request demand services and flexible capacity.
- Write down what the TCoE does not do; business ownership stays with process owners.
- Start with regression, test data and release assessment, prioritized by demand and risk.
Check your understanding · not graded
Lesson check
1. Which service is usually "always on" in an SAP TCoE?
2. Who should still accept or reject a business change when a TCoE exists?
3. What does an upgrade and release assessment service deliver?
4. Why write service boundaries into the catalog?