问题管理流程概要说明书.doc

BWI Service Operation System General Instructions (Problem Management Process)Organization: INFORMATION DEPARTMENT OF BEIJING SHOUGANG AUTOMATION INFORMATION TECHNOLOGY CO.LTDContributor: Yin Hua Zhu Ming Miao JingAuditor: Approver: April 2010VersionDateAuthorConditionRemarksV1.0Document Revision RecordNO.RevisionRevise DateReviserRevise Cause /DescriptionRevised Content(includes Chapters)1. Summary1.1 Document IntroductionThis document, general instructions of Problem Management Process Design Instruction, is designed by BWI -Beijing West Industry Automation Information Technology Co. Ltd. Information Department. The design of this process could efficiently help processing unexpected incidents in IT Environment and improve the quality of IT service, provide BWI better IT support for rapid business development, as well as set up a foundation for efficient implementation of other relevant ITSM processes, such as Issue Management.1.2 Applicable Scope This document is settled as the deliverable summary of Problem Management process design for the project. Readers were defined as all the technical and administrative personnel associated with Problem Management Process. 1.3 Related TermsITIL（IT Infrastructure LibraryIt was developed in 1987 by UK Government as a set of recommendations on IT service management, which now has already become the actual standard for ITSM.Service DeskDesk fundamentally provides the only interface for users and IT departments. This function usually provides services in a centralized method. The basic purpose is to provide initial support, and using wordarounds, solutions or transferring tickets to on-sites engineer and support expert group, etc to help user restore IT services to normal operating condition.Incident ManagementOne of ITIL process, Incident Management is to solve all the IT incidents, problem and user request. The object of it is to restore any outages or affected IT service, thus its feature is usually characterized by purpose of settle the phenomenon, rather than find the root cause.Problem ManagementProblem Management is one of the ITIL processes, handling all the significant emergencies, or sets of incidents with the same symptoms. It aims to find and resolve the root causes of incidents, and to prevent recurrence of incidents related to these errors. Problem Management is also a proactive process identifying and resolving problems before incidents occur.Configuration ManagementConfiguration is an ITIL process that is responsible for describing, tracking and reporting all the processes of the applications or systems in ITIL. All these applications and systems are called CI (Configuration Items). Each CI has an effective system for managing, tracking and controlling to support the normal operation of all the IT services and infrastructures of the company.CMDB - Configuration Management DatabaseCMDB is a database set up for recording the information and the interactions of all the related CIs of the companys IT service. Change ManagementChange Management is an ITIL process that controls and manages all the modifications so as to minimize their impact or risks to the production environment. In this way, the integral IT environment can be heightened. Incident Incidents indicate activities that can or would stop or deteriorate the service quality. Incident is not part of the ITIL process. ProblemProblems indicate the unknown root errors that cause one or more incidents. 2 Process Design for Problem Management2.1 The Object of Problem ManagementProblem Management aims to resolve or reduce the number and the severity of incidents that occur in the manufacture environment, and thus promote the utility of IT service by setting up a stable IT environment for the company. It handles the problems that emerge in the key business systems of BWI through finding the root causes, making a fundamental solution plan or a flexible method or a proposed proactive measure according to the requirement in order to prevent the reoccurrence of incidents related to these errors.Problem Management usually needs to work with Change Management so as to find out the solution plan and thus the root causes can be fundamentally removed. The main objects are:Analyze and identify the root causes, and find out the ultimate solution in order to prevent the reoccurrence of these kind of incidents.Make sure that the incidents are assigned to the right technical person(s), thus the problem-solve efficiency can be raised.Dispatch the IT resources on the basis of the incidents priorities. Analyze the trend referring to the incidents record and initiatively provide the proactive measures.Heighten the authenticity of the IT service.Lower the cost of IT support2.2 Content of Problem ManagementProblem Management puts lots of emphasis on reducing, removing the occurrence of incidents, and resolving the root causes. Its principle activities are: analyzing incidents, finding out problems, generating problem records, assigning problems, analyzing problems based on the causes, finding and implementing solutions, reviewing and closing incidents. By all these actions, incidents can be removed and the adverse impact to clients or businesses can be minimized. The related activities can be described as follow:Incidents Analysis Analyze incidents regularly and find out the underlying problemsGenerate Problem RecordsGenerate problem Records in the system and connect all the related incidents to this record.- The urgent incidents handled are defined as Problems.- Problems that are found by technical support Master Expertise in routine maintenance - Analyze the incidents record history and find out incidents trend.AssignmentAssign problems to appropriate technical teams according to problem content.Root Causes AnalysisThe assigned team will investigate the problems to find out the root causes.Develop, confirm and promote solution planMake solution plans, flexible methods or prompt proactive measures in order to remove the root causes and minimize the adverse impact in the recurrence. Evaluate and test the solution plan and bring out the RFC or the specific implement solution. Review Review the problems solutions, and make sure that the expected effect is achieved. Conclusion and closure Make sure that the information of the problem is recorded correctly, then close the problem record.2.3 Relation to the other processesRelation to Incident ManagementThe urgent incidents will be raised to problems. If the underlying problem is discovered according to the incident trend analysis, the problem management provides solutions for the Incident Process.Relation to Change ManagementProblem Management solution schemes are usually realized via Change Management by submitting the application to the latter.Relation to Configuration ManagementConfiguration Management provides information of CI to Problem Management.2.4 Guideline of the processes The definition of the guidelines is based on the best IT practices on purpose of guiding Problem Management to the most effective implementation. The guidelines for Problem Management are as follows: Guideline One:Because of different purposes of Incident Management and Problem Management, their processes are set up relatively independent, and their management, too. Guideline twoProblem Management resources should be firstly dispatched to the problems that having biggest impact on business.Guideline threePeople in charge of Problem Management should have routine meetings, record and analyze the problems that are handled, confirm the management trend of the initiative problems, and define the analysis regulations of initiative problems. (for example, problem analysis should be done if the amount of a certain kind of incidents takes 30 or more percent of the total)2.5 Scope of ProcessesThe scope of BWI Problem Management is sth.is not included.2.6 Principles for the Processes Implementation2.6.1 General principles The area service manager regularly reviews and generates Problem Management report, and evaluates the unsolved problems in the routine Problem Management meetings. As for the key problems, the area service manager should weekly track the solution process so as to promptly discover and solve the bottleneck, and thus the key problems can be tackled with as soon as possible.The person(s) in charge of Problem Process should semiannually review the key measure index, implement efficiency, support tools validity etc. so as to improve and optimize the process.2.6.2 Processes Relevance Principles Relation to Incident ManagementProblem tickets should be established after the service recuperation of all the incidents, of which the priority is defined as Urgent (Problem ticket should be connected to incident ticket.)Relation to Change ManagementIn the process of incident handling, if the system is in need of change, the RFC ticket should be submitted in accordance of the definition of Change Management. (Change ticket should be connected to problem ticket.). After the change, problem ticket handling should be continued.Relation to the Configuration ManagementIn the process of incident handling, the information of the involved CI can be queried via Configuration Management.In the process of incident handling, if the root causes can be located to a specific CI, the problem ticket must be connected to this CI.2.6.3 Ownership Principle The premise for effective problem management is that each problem is under some appropriate persons responsibility at any time. Each problem should be verified by the area service manager, and then assigned to appropriate Master Expertise or team.When a problem is assigned to a certain expertise, this expertise should be responsible for this problems diagnosis and resolution. Expertise takes the responsibility to communicate the key information when a problem is handled with the service desk or the problem applicant. 2.6.4 Reassign Principle Reassign also is called transference, it assures that the problem ticket is not frequently intertransferred, which can bring this problem to unsettlement within the fixed time. Problem ticket reassignment frequency should be minimized. A problem ticket should not be reassigned exceeding twice. The reassignment of problem ticket should be approved by the area service manager.2.6.5 Problem Closure Principle Regularly, when the problem ticket is solved, one period of review should be done to check whether the expected effect of the solution plan is achieved. The settled problem ticket should be handed to the service desk or the area service manager to confirm the solution of the problem. After the confirmation, a further conclusion and analysis in the current environment should be carried out. And thus analyze if the similar problem exists, then refer to the former root causes and solution plan to prevent the reoccurrence. After the review and conclusion analysis, the service desk can close the problem.2.7 Process Related Definitions 2.7.1 Problem Information Item A problem ticket includes the following information items: NO.Information ItemDescription 1Problem IDAssign a unique number for each problem (generated by the system automatically)2Information of the Applicant The applicants information includes: name, department, e-mail address, office telephone number, cell phone number(hand written for the first time, automatically generated by the system for the second time)3Register TimeGenerate the time of the problem record (generated by the system automatically)4Site record the site of the problem(handwritten)5Problem Source Refer to the definition of Problem Source6Problem Priority Refer to the definition of Problem Priority 7System Type of ProblemRefer to the definition of System Type of Problem8Problem Categories Refer to the definition of Problem Categories9Problem Title Describe Problem briefly( handwritten)10Problem DescriptionDetailed description of Problem(handwritten)11Reason for Problem Rejection Describe the reason for Problem Rejection in detail, and recommend other Master Expertise or technical team(handwritten)12Workarounds Record workarounds in detail13 Problem CauseRecord the root causes of Problem in detail(handwritten)14Problem Tab RepetitionMark the repetition Problem, using the existed tab(handwritten)15Problem State Refer to the definition of Problem State16Assignment ObjectAssign Problems to each expertise in the team(handwritten)17Work Log Describe the information in Problem handling process, e.g. the reassign reason, cause for detain18Problem Record Reflect the change history of CI in the process of problem handling, including the reassigned person, condition etc.(generated by the system automatically)19Real Start Time for DiagnosisProblem Condition is raised to Analyzing(handwritten)20Real Close Time for DiagnosisProblem Condition is raised to Already Solved(handwritten)21Solution Plan Detailed description for the solution plan(handwritten)22Problem Close CodeRefer to the definition of Problem Close Code23Reason for the Inextricable ProblemExplain why the problem can not be solved(handwritten)24Related CIRecord the code of the problem CI(handwritten)25Related Incident Ticket NumberRecord the incident ticket number that triggers the problem(handwritten)26Related RFC Ticket CodeRecord the related RFC ticket code when problem changes(handwritten)27Problem Close Time Record the time when problem condition upgrades to End and closed(handwritten) 2.7.2 Problem Sources Problems are categorized according to their different sources:No.CodeDescription 1Urgent Incident RaisingPromoted after the recovery of urgent incident in order to analyze their root causes2Promoted in operationProblems that discovered by expertise or monitor system in the operation process3Incident Trend AnalysisAnalyze incident and record the discovered problems（1）one kind of incidents that have clear trend direction （2）incidents that emerged and have the same symptoms2.7.3 Problem Priority Problem Priority is the criterion for Master Expertise to solve problems, and it is defined as follows:NO.CodeDescription 1KeyProblems coming from Urgent Problem upgrading:Whether the problems brought up by service operation expertise or by trend analysis:l Influence the key business systeml Have broad impacts(e.g. one plant or more factories)l The degree of urgency is the highestl If the problem is solved, funds, labor power can be saved to a large extent, and the service quality and operation efficiency can be promoted.2Important With regard to the following factors, whether problems:l Influence the non-critical business systeml Influence large scope( e.g. a factory)l The degree of urgency is highl If the problem is solved, funds, labor power can be saved effectively, and the service quality and operation efficiency can be promoted to a certain extent.3CommonWith regard to the following factors, whether problems:l Influence the non-critical business systeml Have a certain influence to the outside environmentl If the problem is solved, the service operation quality and efficiency can limitedly be promoted.2.7.4 Time Bar of Problem Solution Time Bar is drawn up to provide an alarm to prompt the problem to be solved timely:NO.PriorityTime Bar1Key15days 2Important 30days 3Common45days Note: Time Bar of Problem Solution indicates the period between the condition of problem changes Registered and Problem Reviewed. Time Bar of Problem Solution provides reference for area service manager and Master Expertise in tracking the problem-solve process.2.7.5 Problem Condition In order to record the lifecycle of Problem-handling, different conditions should be set up for description, which is stated below: NO.CodeDescription1RegisteredProblem has been registered in the system2Analyzing Master Expertise are analyzing the problems3Located causes Root causes of Problem have been found4Existed solution planSolution plan has been made5Raised RFCPFC has been submitted6Deferment of Implementation Waiting for resources or the right time for implementation 7Reviewed Problem has been reviewed8ClosureProblem has been closed. 2.7.6 System Type of ProblemAccording to the definition of business system, to which the problem of the key businesses infrastructure belongs, when problems arise, the problem system can be initially located. Categories Subcategories 2.7.7 Problem Categories 问题分类是针对问题所属的专业类型进行划分的，通过问题分类可以定位解决问题的人，并针对问题分类进行分类统计。Problems are categorized according to their professional types, thus problems can be assigned to the proper persons and also, Analysis can be separately done based on problem categories. 问题的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。Problems are categorized into no more than three levels, the first level is called Categories, the second level is called Sub-categories, and the third level is called Entry.Categ