Three vendors, one SAP client, and a payroll failure
A government shared-service centre runs a single SAP production client for 14 agencies. Three delivery vendors change the system: vendor A releases quarterly, vendor B monthly, and vendor C whenever a statutory change is requested. All transports land in one QA client before production, but there is no shared release calendar and no single owner of the composite schedule. Last month a vendor B payroll transport and a vendor C tax transport were imported in the same window; they conflicted and the payroll run failed, paying 1,100 staff three days late. Vendor C has no documented release records for its last 20 transports. The statutory tax reporting deadline is six weeks away and all three vendors have changes queued, including an HR schema change from vendor A that the payroll vendor says it must test against. The service owner proposes one consolidated big-bang release containing everything, executed once, to avoid further collisions.
1. How should release units and the release calendar be defined here?
Read the worked answer
The current release units are effectively 'whatever each vendor sends' - which means no one owns the composite, and the composite is what broke payroll.
Define release units around business process and shared dependency, not vendor contract. Payroll, tax reporting and HR schema all touch the same employee master data, so they belong to a single coordinated release train with one schedule, even though three vendors contribute.
Build the calendar from the constraints outward:
- Statutory deadlines are fixed points - publish them as blackout dates for unrelated change and as the anchor for the dependent releases.
- Publish cut-off dates for transport delivery into QA, working back from the production window by the integration test duration, not by vendor convenience.
- Insert a mandatory sequencing and dependency check, owned by the shared-service centre, before any transport is released to production.
- Assign one release owner for the composite. Vendor release managers report into that schedule; they do not each run their own.
This is the difference between three vendors' release management and one release management practice covering three vendors.
2. Should the service owner's consolidated big-bang release be accepted?
Read the worked answer
No - it treats a coordination failure as a batching problem. The payroll failure happened because nobody tested the combination or sequenced the imports; putting everything into one event makes that combination larger and the diagnosis harder, not easier.
A big-bang release containing payroll, tax, and an HR schema change means: one fault could affect all three processes at once; rollback is all-or-nothing across three vendors' transports; and if it fails at the tax deadline, there is no partial success to fall back on.
A better structure:
- One calendar, one release owner, several sequenced releases.
- A combined integration test in a pre-production client that mirrors production data, run before any of them go live - testing the interaction is what was missing.
- Deploy the HR schema change first with the payroll regression run against it, then the payroll change, then tax reporting, each with a verification checkpoint and separate go/no-go.
- Keep tax reporting last, closest to its deadline but not on it, with a tested rollback.
Batching is not coordination. The service owner should be given a calendar and a test regime, not a single risky event.
3. What should be done about vendor C's undocumented transports?
Read the worked answer
Treat it as a control failure with a technical gate, not a request for better paperwork.
Immediate actions:
- Audit the last 20 vendor C transports against the change records and the QA test evidence, and establish which production changes are currently undocumented. Reconstruct the records; this is a live configuration and audit exposure.
- Enforcement should be technical: production import is refused unless the transport is attached to an approved change and a release record in the calendar. A policy that relies on the vendor volunteering information will fail again.
- Vendor C's 'on demand' cadence itself is not the problem - statutory changes do arrive unpredictably. The problem is that on-demand changes bypass the schedule. Give them a defined fast lane: shorter notice, but the same dependency check, the same QA evidence and the same record.
Escalate through the service owner to the contract: repeated non-compliance with release records is a contractual matter, and the shared-service centre needs the lever.
Documenting the unknown first, then gating the door, then fixing the contract, is the order that actually closes the risk.