IT Service Operations and Continuous Improvement
What this domain tests
Operations practice boundaries and improvement mechanics: incident, problem, change enablement, service request, event and access management, plus the continual improvement model and the measurement system behind it. Items test the correct next step in a scenario and the handoff between practices.
Core rules
- Incident restores service fast; problem finds and removes the root cause; a known error is a documented problem with a workaround. Closing the incident does not close the problem.
- Change enablement has three types: standard (pre-authorised, low risk, repeatable), normal (assessed, typically by a change advisory board) and emergency (expedited authorisation, reviewed afterwards).
- Priority = impact × urgency, not the caller's seniority or persistence.
- Continual improvement model questions: what is the vision, where are we now, where do we want to be, how do we get there, take action, did we get there, how do we keep momentum. Deming's plan–do–check–act underlies it.
- Measurement: CSFs → KPIs → metrics. Balance lagging indicators (SLA attainment, satisfaction) with leading ones (backlog age, first-time-fix rate, change failure rate).
Worked example
Payment authorisations fail intermittently every Monday. The incident team restores service by failing over (incident closed in 40 minutes). Problem management finds a batch job saturating the connection pool, documents a known error with a restart workaround, and raises a normal change to resize the pool. Once proven, a standard change model covers the restart so future occurrences bypass the advisory board. The full expected chain: incident → problem → known error → normal change → standard change.
Traps that cost marks
- Raising a problem record and leaving users without service - restore first, investigate second.
- Treating every change as normal, which floods the change authority and slows delivery.
- Reporting MTTR when the question asks about availability; MTBF measures reliability between failures.
- Using customer satisfaction surveys as the only improvement input and ignoring operational data.
- Running improvement as a one-off project with no register, owner or review date.
Improvement in practice
Keep one improvement register with owner, benefit hypothesis, measure and review date; use value-stream mapping to expose handoffs and queues; feed service review outputs into the next planning cycle so design, operations and finance stay connected rather than drifting into separate annual rituals.