Change and Incident Collision at Helio Energy
Helio Energy supplies 1.8 million meters and runs SAP plus 30 SaaS applications. Three providers dominate: AppsCo for SAP, CloudCo for hosting and NetCo for network. Each keeps its own incident and change process. AppsCo's major incident manager has authority only inside AppsCo. Last quarter there were 14 emergency changes, five of which caused outages. One six-hour outage began when CloudCo applied a hypervisor patch as a standard change; AppsCo saw database latency and declared a major incident; NetCo was not engaged for two hours. The weekly CAB sees only about 40% of changes. Problem management is absent across providers: 300 recurring incidents a month have no shared problem record, and each provider closes its own tickets. The CIO wants one process but providers resist losing control.
1. Design the end-to-end incident and change flow. Who should own it, and where should decision rights sit?
Read the worked answer
Design one process with three layers, not three processes stitched together.
Layer 1: process ownership. A SIAM process owner in the service integrator owns the end-to-end incident management process, sets policy, the severity matrix, escalation timelines and reporting. This role does not fix incidents; it designs and assures the process.
Layer 2: cross-provider major incident management. A major incident manager (MIM) role, on call 24x7, is empowered to declare a major incident, convene any provider, set the bridge cadence and require a shared timeline. The MIM should not be AppsCo's MIM, whose authority stops at the AppsCo boundary. It should sit in the integrator, or rotate among trained and mandated individuals from all three providers.
Layer 3: provider execution. Provider incident managers retain authority for their own domains and remain accountable for technical actions and timescales.
Change flow. One change calendar and one standard change catalogue agreed by all providers. Any change that can affect another provider's service is a cross-provider change requiring impact assessment and a representative from each affected provider. CloudCo's hypervisor patch would be classified as cross-provider, not standard, because it can affect SAP performance. Emergency change authority should be delegated to named MIM and change manager roles so a weekly CAB is not a bottleneck. A daily 15-minute forward-schedule review catches collisions early.
Decision rights. The integrator owns process, severity and escalation; providers own technical execution; the service owner owns business communication and risk acceptance.
2. How should problem management be triggered across providers, given 300 recurring incidents a month?
Read the worked answer
Do not create 300 problem records. Set a cross-provider trigger: three or more incidents in 30 days with the same symptom or configuration item; any major incident with an unknown cause; or a recurring workaround that has become normal practice. The integrator's problem coordinator creates one problem record, not one per provider.
Ownership. Assign the problem to the provider best placed to resolve the root cause, supported by a named cross-provider technical group. The coordinator owns progress, escalation and cross-provider data, not the technical fix. The record must link incidents, changes, known errors and configuration items across all three providers, otherwise the same cause will be rediscovered in a silo.
Start small. Triage the 300 monthly incidents into patterns and select the top five by volume, customer impact and cross-provider nature. Publish a monthly problem review to the service governance board. Require each provider to contribute incident and change data, and make participation a contractual scorecard item.
Measure the right thing. Track reduction in repeat incidents, reduction in major incidents with a known error, and time from trigger to root cause, not the number of problem records closed. If providers close records quickly but repeat incidents stay flat, the process is being gamed.
3. The CIO wants to appoint AppsCo as the single process owner for incident and change. What are the risks, and what would you advise?
Read the worked answer
Risks of appointing AppsCo.
- Conflict of interest. When an incident involves AppsCo's own SAP service, AppsCo would investigate itself and control the narrative.
- Limited authority. AppsCo cannot direct CloudCo's hypervisor changes or NetCo's network actions, so the six-hour patch scenario could recur.
- Provider resistance. CloudCo and NetCo may withhold information or resist direction from a commercial competitor, especially in a blame-and-credit culture.
- Loss of neutrality. The integrator becomes a rubber stamp, and the CIO loses an independent view of end-to-end performance.
Advice. Do not appoint a permanent single-provider owner. A workable compromise is for AppsCo to supply major incident management capability under the integrator's process ownership, with rotating MIMs from all providers, a documented conflict-of-interest rule that the provider causing an incident cannot lead its own review, and the integrator holding policy and escalation. If AppsCo is appointed, make it explicit that it operates the process on behalf of the integrator, hold it to cross-provider participation measures, and retain the integrator's right to reassign ownership. The CIO's goal of 'one process' is right; making one supplier the owner confuses process ownership with technical leadership and creates a new single point of failure.