Implementing Configuration, Incident, Problem and Change Control Across 14 Countries
TransFleet Logistics operates warehouse management and transport services in 14 countries. Its Manila service desk logs incidents in one tool, while local teams use a second tool for the same services. Changes are approved by email from regional managers, and emergency changes are made at night and documented the next week, if at all. A spreadsheet CMDB lists 4,200 configuration items but is estimated to contain 30% duplicates and is not linked to incidents. Problem management is informal; engineers fix recurring issues without recording known errors. A recent outage affecting 60 customers was traced to an undocumented firewall change. The new service management manager has six months to implement the operation clauses of ISO/IEC 20000-1 before a group audit.
1. Recommend where to start with configuration management. What should be a configuration item, and what risks arise from cleaning the CMDB before defining the CMS scope?
Read the worked answer
Start with services and critical supporting components, not the spreadsheet. Define the purpose and scope of the configuration management system first: which services, locations and tiers need configuration control, and what decisions the data must support, such as impact analysis for changes and incident resolution. A configuration item should be an element that needs to be controlled because it affects a service or is needed to understand dependencies. That usually means services, applications, servers, network devices, databases, interfaces and key documentation, selected by impact and change frequency rather than by completeness.
Risk of cleaning first. Spending weeks de-duplicating 4,200 records before agreeing the service model produces a tidier list with no decision value. The firewall example shows the real problem: the CMDB was not linked to changes or incidents, so nobody could see the dependency. Cleaning without a model also invites rework when scope changes.
Practical sequence. Define the service and CI model, identify critical services and their dependency chains, assign data owners, reconcile incrementally, link CI records to incidents and changes, and measure accuracy through sampling. Use the firewall change as a case study to show why the model matters. Report data accuracy as a management measure rather than claiming the CMDB is complete.
2. Design the interface between incident and problem management so recurring incidents produce known errors and reduced repeat volume. Specify triggers, ownership and records.
Read the worked answer
Triggers. A problem record should be raised when an incident is a major incident, when the same symptom recurs above an agreed threshold in a period, when a workaround is being reused repeatedly, or when trend analysis shows a growing cluster. The service desk should be able to trigger a problem review without waiting for a manager.
Records and ownership. The problem record links to all related incidents, states the symptom, impact, affected services and CIs, and has a single problem owner. Root-cause analysis produces either a known error with a documented workaround or a change proposal. The known error record must be visible to the service desk at the point of incident logging, so the workaround is applied consistently. Incident closure should reference the known error where one exists.
Interface rules. Problem management does not close an incident; it closes when the root cause is removed or a permanent fix is verified. Incidents should not be reclassified as problems to improve incident metrics. The service desk owns incident restoration; problem management owns root cause. A recurring-incident measure, such as the percentage of incidents matching a known error, shows whether the interface works. The firewall outage should produce a problem record, a known error if recurrence is possible, and a change to prevent repetition, not just a fixed device.
3. How should change management handle emergency changes so that the undocumented firewall change is not repeated, while operations continue 24/7?
Read the worked answer
Define an emergency change route, not an exception route. Emergency changes need a named authority, for example a duty manager plus an on-call technical authority, who can approve outside normal hours. The change must still be recorded before implementation where possible, or immediately after restoration, with the risk, rollback plan and affected CIs captured. 'Document next week, if at all' is not a control.
Separate approval from documentation. The urgency is about approval speed, not about skipping records. A short emergency change record can be completed in minutes and linked to the incident. The post-implementation review should confirm what changed, whether the CMDB was updated, whether the change was authorised and whether a normal change is needed to make it permanent.
Use evidence and measures. Track emergency changes as a proportion of all changes, failed changes, unauthorised changes and changes without a linked CI. Review them at the change advisory forum. If emergency changes cluster around one platform, that is a problem for problem management, not a reason to relax control. The 24/7 constraint is met by delegated authority and clear escalation, not by leaving a firewall change invisible.