Lesson 4 of 6
Service catalog and intake
9 min
Listen to this lesson
sap-tst-401 described the TCoE as a catalog of services, each on one page. This lesson makes the catalog operational: service tiers, entry criteria that start the clock, lead times and dependencies on other teams, and an intake process that turns a vague request into a scheduled, sized piece of work.
Three service tiers
Catalog entries that work
| Service | Entry criteria (clock starts when met) | Lead time | Depends on |
|---|---|---|---|
| Release regression | Build in CMR (CMQ before go-live); transport list and SAP release information attached; test users and interfaces confirmed; date in the calendar | 10 working days to results in year 1; target 5 | Basis, security, integration |
| Test data set | Request form complete: process, variant, volumes, client | 2 working days for standard recipes; 10 for new recipes | Data owners for new recipes |
| Project test strategy | Project charter and scope; named project test lead | 10 working days to first draft | Project solution architect |
| UAT facilitation | Tests approved; testers named and released by line managers | Booked a quarter ahead | Line managers, security |
| Automation build | Process stable for one release; manual test approved; data recipe exists | Scheduled in the automation backlog | Test architect, data lead |
| Release assessment | SAP release information or note list available | 5 working days | Solution architects |
Six Contoso catalog entries with entry criteria and lead times. A missed date is traced to whichever side missed its criteria.
Entry criteria do two jobs. They protect the TCoE from being blamed for delays it did not cause, and they show requesters exactly what to prepare. Dependencies on other teams are written as operational level agreements: Basis commits to a CMR refresh within an agreed time, security to restoring roles, integration to pointing endpoints at test systems. Without those, the TCoE's own lead times are promises it cannot keep.
Measuring the catalog itself
Publish three numbers per service every quarter: how many requests arrived by tier, the share delivered within the lead time, and the share of late deliveries caused by missed entry criteria on the requester's side. The third number is the most useful. If half of all late regression results trace back to builds arriving in CMR without transport lists, the fix is in the release process, not in the TCoE, and the data makes that conversation easy.
The intake process
Every request uses the demand process IT already runs, with a short form: what is changing, which processes and company codes are affected, target date, requester, and whether SAP release content is involved. Triage meets weekly with the TCoE lead, the test architects and Luis. It assigns the service, the tier and an owner, and lists the entry criteria back to the requester. Emergency changes skip the queue but not the form; the triage is done the same day by the TCoE lead and recorded afterwards.
What would you do?
Kenji's team asks Ravi directly, by chat, to "quickly automate" a new pricing check for a release in two weeks. Ravi is willing. What should Priya do?
- Offer three tiers (self-service, consult, managed) and choose the lightest safe tier by size and risk.
- Every catalog entry lists entry criteria that start the clock, a lead time and its dependencies.
- Back the TCoE's lead times with operational level agreements from Basis, security and integration.
- Use one front door, a completeness check and weekly triage; escalate only capacity conflicts.
Check your understanding · not graded
Lesson check
1. What do entry criteria in a catalog entry do?
2. A small but risky pricing change arrives. Which tier fits best?
3. Why back TCoE lead times with operational level agreements?
4. Half of all late regression results trace back to builds arriving in CMR without transport lists. Where is the fix?