《8.3 问题管理流程图》由会员分享，可在线阅读，更多相关《8.3 问题管理流程图（1页珍藏版）》请在金锄头文库上搜索。
1、Monitoring A problem, by definition is when the cause is unknown. An error, by definition is when the cause is known. Problem Management Process Flow Important note: Internationally recognized flowchart symbols are used when their use is unambiguous Decision Document Predefined process Stored Data M
2、anual Operation This flow chart prepared by The Art of Service as a representative example. Errors and Omissions Excepted Can you have Problem Control without Error Control? Simple answer: YES If you discover what the problem is it may be determined the cost of correcting the error is not justifiabl
3、e. PROACTIVE PROBLEM MANAGEMENT ERROR CONTROL PROBLEM CONTROL Vendor advice Legislation Research Forums There are a limitless number of sources that the IT professional will use to gather information about potential issues that could affect the IT infrastructure. The challenge is to identify these s
4、ources and then have systems in place to filter and sort through the large amounts of datea. Problem Management comprises these 3 primary activities. Each major activity is then broken down into a variety of component (or sub) activities. Service Level Management (SLAs) Capacity Management Trend inf
5、ormation Incident Management Escalated incidents + resolutions not understood Availability Management Missed availability targets Think of Proactive Problem Management component as being a “what-if” analysis. “What if, this happens”, “What if that happens” This flow chart has a specific process focu
6、s, but also indicates where other processes contribute. Trend Analysis Targeting Preventative Action Major Problem Reviews Problem Identification and Recording Problem Classification Problem Investigation and Diagnosis Error Identification and Recording Error Assessment Record resolution information
7、 Error Closure The actual work of the Problem Management process is carried out by technical groups, under the supervision of the Problem Manager Is Problem Rejected? No Yes Return to point of origin Is the cause known? No Yes Close the problem and Proceed to Error Control Requests for Status can co
8、me from Change Management, Incident Management, Customers, Users, Vendors On many occasions once the technical specialists have discovered the (known) error and how to resolve it, the Change Management process is triggered. As with many of the ITIL processes there is no specific timing of when one p
9、rocesses hands off to another; indeed many processes run in parallel dealing with the same issue. It is likely that a technical specialist will be part of the Change Management team and they will also be involved as part of the Post Change review. Capacity Management Focus groups conduct walk throug
10、h scenarios that simulate a wide range of potential possibilities that could lead to service failure. Availability Management Two categories of review: 1. “Post Implementation Reviews” (PIRs) following a change; 2. Major failure review to look for process improvements. The concept of end-to-end Serv
11、ice Management and Service Delivery is one that is very relevant for Problem Management. The concept (which allows us to understand how many components go in to the delivery of a service to an end user) highlights the importance of tracking problems against all components and proactively looking for
12、 potential issues in all areas (not just the easily identifiable ones). Problem Record Unique ID # Creation Date: Raised by: Affected System: SLA x-ref: Close Date: Problem Type: ProductionDevelopment Action Log / / Problem Status Current Known Error Pending Closed Low PRIORITY ImpactUrgency High MainframeServer LANWAN ApplicationO/S Procedureother / Workaround details / Permanent Resolution RFC x-ref: ITIL is a Registered Trade Mark of the Office of Government Commerce, in the United Kingdom
