SIAM / multi-supplier service integration¶
Trigger¶
A service depends on multiple suppliers/teams and end-to-end accountability, OLAs, incidents, problems, changes or acceptance are fragmented across boundaries.
Intended outcome¶
One governed service-integration model joins supplier responsibilities into end-to-end service outcomes with measurable SLAs/OLAs, clear process ownership and cross-supplier escalation.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | SIAM Manager | defines end-to-end service scope, integrator authority and supplier responsibility model | SIAM operating model | No customer outcome or integration process is ownerless |
| 2 | Service Level Manager | decomposes customer SLA into measurable OLAs/underpinning supplier obligations | SLA/OLA matrix | Every SLA has sufficient underpinning measures/owners |
| 3 | Architecture Repository and Modelling Lead | maintains cross-supplier service/technology/dependency model | shared dependency register/view set | Material supplier/service dependencies have stable IDs and owners |
| 4 | Incident Manager | defines cross-supplier incident ownership, bridge, evidence and handoff rules | cross-supplier incident model | Severity and service restoration ownership cannot bounce between suppliers |
| 5 | Problem Manager | owns systemic problem process across supplier boundaries | cross-supplier problem model | Root causes crossing contracts still receive one end-to-end owner |
| 6 | Enterprise Release Manager | integrates supplier change/release windows, collisions and readiness | integrated change/release calendar | Cross-supplier change collisions and blackout constraints are governed |
| 7 | SIAM Manager | defines dispute/escalation clocks, evidence standard and decision authority | supplier escalation matrix | Escalation cannot be blocked by contractual ownership ambiguity |
| 8 | IT Service Owner | accepts the integrated service and residual multi-supplier risks | shared service acceptance | Service acceptance is end-to-end, not a collection of supplier self-attestations |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
siam-multi-supplierworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.