become-itil-foundation-certified-abhinav-kaiser(www.ebook-dl.com)
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 7 ■ Service Operations<br />
In the problem management process lifecycle, I have used seven steps to achieve the<br />
objectives. I will explain each of the steps in the following sections.<br />
7.5.4.5.1 Step 1: Problem Detection<br />
As with the incident management process, problems need to be detected for the process<br />
to be triggered. A problem can be identified from any source; it can <strong>com</strong>e as an action<br />
item from the customer, a threat notification from regulatory departments, or loopholes<br />
identified by hackers. In the problem management lifecycle, I have considered the<br />
most <strong>com</strong>mon triggers for a problem. Remember that the triggers need to be identified<br />
beforehand to ensure that the process is well controlled and does not spiral into<br />
directions that were not factored in.<br />
7.5.4.5.1.1 Event Management<br />
These days, event management tools play a large role in keeping a finger on the pulse<br />
and to standardize monitoring and capture events that are of significance to IT service<br />
management. I discussed the application of event management tools in the incident<br />
management process. In a similar vein, these tools can be programmed to detect<br />
problems as well. For example, if a server being monitored goes down, an incident<br />
ticket is raised. Suppose the same server alternates between being offline and online at<br />
a preconceived number of times. The tools can then be programmed to raise a problem<br />
ticket for the problem manager to start investigation-related activities.<br />
That being said, it is rare to see the event management tools used to raise problem<br />
tickets. I have seen such instances with a handful of implementations. To program<br />
problems on the automation solutions requires a certain amount of maturity for the<br />
service management organization to design, execute, and control.<br />
7.5.4.5.1.2 Major Incidents<br />
The most <strong>com</strong>mon source for triggering problems are major incidents. It is a <strong>com</strong>mon<br />
sighting in the process world to see major incidents tagged to problem investigations.<br />
Normally, toward the resolution of a major incident, a problem ticket gets created by the<br />
incident manager. While the major incident resolution brings logical closure to the major<br />
incident management process, it also gives rise to the problem management process to<br />
initiate investigations.<br />
This is a good practice as major incidents can cause massive damage to clients,<br />
financial, productivity, brand image, among others. It is in the interests of all stakeholders<br />
that a problem investigation is performed for the major incident to identify the loopholes<br />
and <strong>com</strong>e up with a preventive measure to ensure such outages do not happen in the<br />
future.<br />
7.5.4.5.1.3 Partners/Suppliers<br />
We live in a world where no single IT service provider organization can afford to provide<br />
all IT services. There is a need for having suppliers. I discussed this in Chapter 5.<br />
Suppliers han<strong>dl</strong>e specific areas in the delivery of IT services. Let’s say that a particular<br />
184