Repeat Incidents at OmniMart
OmniMart operates 1,100 stores and a central IT group. The service desk handles about 5,000 tickets a month, but first-contact resolution is 48% and 38% of incidents are repeats of earlier incidents. Problem management has three staff and works almost exclusively on major incidents; 70% of major incidents never produce a problem record. Change enablement rejects 22% of change requests on first review, mostly because risk and test evidence are incomplete. The knowledge base contains 1,200 articles; 55% have not been reviewed in 12 months, and agents report they cannot find the right article during a live call. The configuration management database is estimated at 62% accurate, and store infrastructure is often recorded only after an incident. Store managers complain that the same till and network faults recur every few weeks, while the CIO wants evidence that ITIL practices are reducing risk rather than adding bureaucracy.
1. Explain how incident management, problem management, change enablement and knowledge management should interact across the value chain to reduce repeat incidents. Specify the key inputs, outputs and feedback loops.
Read the worked answer
Treat these practices as one feedback system rather than four silos. Incident management restores service and captures symptoms, affected configuration items, workarounds and resolution details. Problem management consumes repeat-incident clusters and major-incident records, performs root cause analysis, and produces known errors, workarounds and change proposals. Change enablement receives those proposals with risk and test evidence, and feeds back failed or rejected changes to problem management and design. Knowledge management turns validated workarounds and fixes into findable articles and updates them when root cause is confirmed.
In value chain terms, the service desk engages demand, incident and problem management deliver and support, change and fix work through design and transition and obtain/build, and continual improvement uses trends and post-implementation review.
For OmniMart, make the loops explicit. A repeat-incident threshold, such as a third occurrence in 30 days, should automatically create a problem record. Every major incident should have a problem record or a documented exception. Every problem record should produce a knowledge article, a change proposal or a justified closure. Every change record should link to the problem it resolves. Without these links, the 38% repeat rate will persist because the organisation learns nothing between incidents.
2. Which practice should own the repeat-incident measure, and how would you design measures that avoid gaming and show value to the CIO?
Read the worked answer
Problem management should own root-cause reduction, but the repeat-incident measure must be shared with incident management and the service desk. Otherwise problem management can blame incident logging while incident management closes tickets quickly to protect its numbers.
Define repeat incident precisely: same service, same symptom or same configuration item, within a defined window, excluding scheduled maintenance. Pair it with outcome measures: repeat-incident rate, problem records created per 100 major incidents, time to known error, percentage of changes linked to problems, first-contact resolution and customer-reported recurrence. Audit a sample of closures, track reopens and use store-level data rather than only central averages to reduce gaming.
For the CIO, express value as reduced lost store hours and fewer emergency changes, not just ticket counts. Use a balanced set: if repeat rate falls but resolution time rises sharply, the practice may be over-investigating low-value issues. Continual improvement should review the measures quarterly and retire any that no longer drive the desired behaviour.
3. What role should the service desk and configuration management play in design and transition? Give concrete examples from OmniMart.
Read the worked answer
The service desk is a demand sensor. It should feed design and transition with trend data on recurring till faults, network instability by store and workarounds that indicate poor usability. Configuration management should provide accurate service models and CI relationships so design can assess impact and problem management can cluster incidents correctly.
Concrete examples: before a store infrastructure refresh, use incident and problem data to identify the top five failure modes, and require the design to include monitoring, known-error articles and support readiness. During transition, use service validation and testing plus change enablement to confirm that support can restore the service. Make CI updates a mandatory task in change and incident closure rather than an after-the-fact cleanup.
This is the interaction between design and transition and deliver and support in the value chain. Because the CMDB is only 62% accurate, do not attempt a big-bang cleanse. Prioritise CIs involved in repeat incidents and major store services, then measure accuracy by sampling rather than by record count.