Processes to support Service Integration and Management
This domain tests the operational processes that must work end to end across providers - incident, problem, change, release and deployment, request fulfilment, event and knowledge - and the design decisions that make them function in a multi-provider world.
Rules
- One process model for the ecosystem: one definition, one policy set, one escalation path, agreed interfaces and shared measures. Providers may keep internal procedures, but the end-to-end process is common.
- Ownership sits with the service integrator; execution sits with providers, and the interfaces between them are written as OLAs.
- One service desk, or a virtual service desk with a single point of contact for users; no swivel-chair handoffs between provider desks.
- Major incident management needs one major incident manager, a cross-provider escalation matrix and a single communication channel to the business.
- Change needs a single change model: one change authority or federated authorities with clear thresholds, one forward schedule of change visible to all providers, cross-provider impact assessment and an emergency change route.
- Problem management requires providers to be contractually obliged to supply root cause analysis and join problem reviews.
- Tooling supports the process, it does not define it: integrated or shared ITSM tooling, consistent prioritisation codes and a shared knowledge base.
Worked example
Provider A schedules a firewall upgrade; Provider B's payment application depends on that firewall. Because each provider keeps its own change calendar, no impact assessment happens and payments fail. Process reasoning: a single forward schedule of change, mandatory cross-provider impact assessment for shared configuration items and one change authority for high-risk changes would have exposed the dependency before implementation.
Traps
- Assuming one tool automatically creates one process.
- Letting each provider run its own version of incident or change and calling that integration.
- Confusing process ownership with process execution.
- Forgetting that major incident and emergency change need pre-agreed cross-provider routes.
- Overlooking the shared knowledge base, which quietly determines first-time-fix rates.