According to the ITIL, the definition of the incident is any unplanned type of interruption to the IT service or the reduction in quality of the IT service. The ITIL has defined the problem as a cause of one of the incidents or more incidents. The key objective of taking the problem management is the prevention of the problem and the prevention of the resultant incidents from happening and to eliminate the recurring incidents and minimizing the impact of the incidents that could not be prevented. The problem management is mainly dependant on the maturity of the incident management.
Though, it is very much possible to start the problem management early, this is a highly integrated process with the incident management. Therefore, the best time to implement the problem management is after the implementation of the incident management. There will be a need for the incident data, frequency, impact and the incident trend so as to help and identify the worthwhile and the relevant problems so as to eventually work on them.
Many a times it is very much possible to begin with the activities of the problem management without having any formally defined process of problem management. Instead of getting bogged with the process design related activities, you must implement the supporting the documentation and the right from the inception of the project and consider opting for fast wins. Here’s the way you can start:
Firstly, you need to identify around 8-10 incidents.
If necessary you can provide guidance to the incident management of the service on how can you record the incidents.
Now, find some of the problems and go ahead solving the same.
The primary activity in the problem management is deeply going and finding the main cause of the incidents and recommend for permanent fixing. As this job is crucial, you need to choose the right kind of people. You can assign the roles to people who are analytical with a perfect technology background. This assigned role need not necessarily be permanent role. Actually, many organizations do not assign a person to be a problem manager. Therefore on the basis of the current problems, the problem managers are identified and assigned the roles. In some cases, the task force can also be assigned instead of one individual. Along with the technical skills, the problem managers that are assigned might have problem solving skill as well as experience.
At some or the other stage, the process might need designing, documentation and formal rollout of the whole organization. The Information Technology Infrastructure Library (ITIL) provides an excellent guidance and framework for defining the steps and activities of the process. The prime responsibility of the owner of the process to check whether the process is properly documented and the responsibilities and the roles are well communicated and clear, and the people are using and the target is on continued improvisation of the process. The reports and the metrics must be defined. The metrics of the problem management is generally not included in the SLA (Service Level Agreements)
One more important activity is setting up the KEDB (Known Error Database). It’s a problem that actually has documented the root cause and working on a solution. Information about the problems is maintained in the KEDB.
Moreover, the KEDB will not add more value to the process of the incident management and is very immature to efficiently utilize the same. There are many organizations who have set the system of KEDB haven’t achieved success as the service desk staff or the incident management staff is too immature for assisting in capturing the information use this system to assist in the first line diagnostics.
Implementing a tool for supporting e creation of the tracking of the problems and the known error records must be considered.
Finally like any of the type of process, the process of the problem management passes to Plan Do Check Act cycle and refined and improved overtime.
