Commonwealth of Massachusetts IT Consolidation Phase 2. ITIL Process Flows

Transcription

1 Commonwealth of Massachusetts IT Consolidation Phase 2 ITIL Process Flows August 25, 2009

2 SERVICE DESK STRUCTURE Service Desk: A Service Desk is a functional unit made up of a dedicated number of staff responsible for dealing with a variety of service events, often made via telephone calls, web interface, or automatically reported infrastructure events. Implications and Key Decisions Location Services HR Finance Other Tier 1 Core Helpdesk Team Tier 2 Agency A Agency B Agency C N Regional Team Tier 3 Vendor 1 N

3 INCIDENT MANAGEMENT : An unplanned interruption to an IT service or reduction in the quality of an IT service. : The process for dealing with all incidents;this can include failures, questions or queries reported by the users, by technical staff, or by event monitoring tools. Customer From Event Mgmt From Web Interface From User Phone Call From Technical Staff Tier 1 Identification Logging Categorization Service? Prioritization Major? Initial Investigation and and Recovery Resolved? Closure / Service Fulfillment Major Procedure Knowledge Mgmt./ Known Error DB / Service End Tier 2 Level 2 Initial Investigation and / Service and Recovery Resolved? Tier 3 Level 3 Initial Hierarchic Investigation and and Recovery Resolved? / Service Multi level Categoriza tion Prioritization Investigation and and Recovery Closure Sample Fields Unique reference number categorization urgency impact prioritization Date/time recorded Name/ID of the person and/or group recording the incident Method of notification (telephone, automatic, e mail, etc.) Name/department/phone/location of user Call back method (telephone, mail, etc.) status (active, waiting, etc.) Related s Support group/person to which the incident is assigned Related problem/known Error Activities undertaken to resolve the incident date and time Closure category Closure date and time Sample Development Process and Categories 1. Develop top level categories (including an other ) category. Set up the relevant logging tools to use these categories for a trial period. 2. After a trial period, perform an analysis of the incidents logged during the trial period and identify gaps. 3. Perform a breakdown analysis of the incidents within each higher level category to develop the lower level categories. 4. Review and repeat periodically Software Application Administration Time & Attendance Sample Prioritization Coding Clear guidance should be provided for all support staff to enable them to determine the correct urgency and impact levels, so the correct priority is assigned. Such guidance should be produced during service level negotiations. Urgency Impact High Medium Low High Medium Low Priority Description Target Code Res. Time 1 Critical 1 hour 2 High 8 hours 3 Medium 24 hours 4 Low 48 hours 5 Planning Planned Sample Procedure Establishing exactly what has gone wrong or being sought by the user Understanding the chronological order of events Confirming the full impact of the incident, including the number and range of users affected Identifying any events that could have triggered the incident (e.g. a recent change, some user action?) Knowledge searches looking for previous occurrences by searching previous / s and/or Known Error Databases or manufacturers /suppliers E rorlogsor Knowledge Databases. Sample Procedure Asking the user to undertake directed activities on their own desk top or remote equipment The Service Desk implementing the resolution either centrally (say, rebooting a server) or remotely using softwaretotakecontroloftheuser s desktop to diagnose and implement a resolution Specialist support groups being asked to implement specific recovery actions (e.g. Network Support reconfiguring a router) A third party supplier or maintainer being asked to resolve the fault. Sample Closure Procedure Closure categorization. Check and confirm that the initial incident categorization was correct and update as necessary. User satisfaction survey. Carry out a user satisfaction call back or e mail survey for an agreed percentage of incidents. documentation. Chase any outstanding details and ensure that the is fully documented. Ongoing or recurring problem? Determine whether it is likely that the incident could recur and decide whether any preventive action is necessary (if so, open a ). Formal closure. Formally close the. te: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research

4 REQUEST FULFILLMENT : A generic description for many varying types of IT demands that are small changes low risk, frequently occurring, low cost, etc. Fulfillment: The process for dealing with all requests using pre defined approval and qualification processes. te: many organizations use their incident management process to fulfill requests. Service Desk Service Catelogue Proactive Asset and Input Tier 1 Identify and Log /Service Categorization Standard? Prioritization Financial Approval? Planning Referral? Fulfill /Service Completed? Closure End Tier 2 2 Level Planning Referral? Fulfilled /Service Completed? Tier 3 2 Level Planning fulfilled Completed? /Service Sample Fields What service is being requested Who requested and authorized the service Which process will be used to fulfill the request To whom it was assigned to and what action was taken The date and time when the request was logged as well as the date and time of all actions taken Closure details. te: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research

5 CHANGE MANAGEMENT : The addition, modification, or removal of authorized, planned or supported service or service component and its associated documentation. : The process for responding to changing business and IT requirements while minimizing risk and reducing incidents, disruption and re work. or Service Portfolios Service Project Operational n Standard Initiator Create RFC the RFC Design and Plan Plan Updates Develop Remediation Plan Implement Review Results Manager Review the RFC Standard? Assess & Evaluate the Authorize the Proposal Coordinate Implementation Review Results Close End Authority Authorize the Approved? Review Completed s Evaluation Report RFC Standard Asses & Evaluate Authorization Review and Close Sample for (RFC) Fields Unique reference number Impact assessment and evaluation Trigger (e.g. business need, resources, capacity, cost, benefits purchase order, etc.) Governance impact (continuity Description management) Identity of items to be changed decision body Reason for change (business case) Decision and recommendations Effect of not implementing the accompanying the decision change (business, technical, financial) Authorization signature items and baseline Authorization date and time versions to be changes Target baseline or release to Primary contact information of person incorporate change into proposing change Scheduled implementation time Date and time of proposed change Location/reference to release/ category (minor, major, etc.) implementation plan Predicted timeframe, resources, Details of change implementer costs and quality of service implementation details priority Actual implementation date and time Risk assessment and risk Review dates management plan Review results Back out or remediation plan Closure Sample Standard Considerations A standard change is a change to a service or infrastructure that is preauthorized by with an established procedure. Elements of a standard change: There is a defined trigger to initiate the RFC The tasks are well known, documented and proven Authority is effectively given in advance Budgetary approval will typically be preordained or within the control of the change requester The risk is usually low and always well understood. Sample Considerations Seven Rs of change management: Who raised the change? What is the reason for the change? What is the return required from the change? What are the risks involved in the change? What resources are required to deliver the change? Who is responsible for the build, test and implementation of the change? What is the relationship between this change and other changes? Additional Considerations: Impact on business operation Effect on infrastructure services that share the infrastructure Impact on customer service Effect of no change Impact on resources Impact on future plans Impact on current schedule Sample Authorization Model Path Level 1 Level 2 Level 3 Level 4 Authority Business Executive Board IT Board Advisory Board Local Authorization Potential Impact High cost/risk change Multiple services or orgs impacted Single service or org impacted Standard change Advisory Board Membership Membership Considerations Composition based on the changes being considered Should include business and technical representation Should involve suppliers when that would be useful Shouldreflectbothusers and customers views Is likely to include the problem manager and service level manager and customer relations staff. Sample Closure Processes The change has had the desired effect and met its objectives Users, customers and other stakeholders are content with the results, or have identified any shortcomings There are no unexpected or undesirable side effects to functionality, service levels, warranties The resources used to implement the change were as planned The release and deployment plan worked correctly The change was implemented on time and to cost If needed, the remediation plan functioned correctly te: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research

6 ASSET AND CONFIGURATION MANAGEMENT Asset and : Full lifecycle management of IT and service assets, from the point of acquisition through to disposal Input Approved New Asset Approved Asset Asset/Config. Data Audit for Report Approved Asset Disposal/ Reallocation Finance / Procurement Procure Asset Finance/ Procurement Update Financial Finance/ Procurement End Asset/Config. Manager Asset Standard? Define New Config. Codes Schedule & Plan Audit Direct Corrective Action Plan and Assign Report Analyze Report Asset/Config. Analyst Conduct Audit Report Findings Prepare Report IT Technicians Create Asset Update Asset Implement Corrective Action Retire Asset Asset Identification Control te: Asset Disposal Sample Identification Procedures Define and document criteria for selecting configuration items and the components that compose them Select the configuration items and the components that compose them based on documented criteria Assign unique identifiers to configuration items Specify the relevant attributes of each configuration item Specify when each configuration item is placed under Identify the owner responsible for each configuration item. A baseline configuration should be developed. An example of a baseline is an approved description of a service that includes internally consistent versions of requirements, requirement traceability matrices, design, specific service components and user documentation. Asset Considerations The items placed under will typically include service bundles, service packages, service components, release packages and products that are delivered to the customer, designated internal work products, acquired services, products, tools, systems and other items that are used in creating and describing the configurations required to design, transition and operate the service. Choosing the right Item (CI) level is a matter of achieving a balance between information availability, the right level of control, and the resources and effort needed to support it. CI information is valuable only if it facilitates the management of change, the control of incidents and problems, or the control of assets that can be independently moved, copied or changed. Sample Asset Attributes Unique identifier CI type Name/description Version (e.g. file, build, baseline, release) Location Supply date License details, e.g. expiry date Owner/custodian Status Supplier/source Related document masters Related software masters Historical data, e.g. audit trail Relationship type Applicable SLA. Control Considerations License control, to ensure that the correct number of people are using licenses and that there is no unlicensed use and no wastage Version control of service asset, software and hardware versions, images/builds and releases Access control, e.g. to facilities, storage areas and CMS Build control, including the use of build specification from the CMS to perform a build Promotion, migration of electronic data and information Taking a configuration baseline of assets or CIs before performing a release (into system, acceptance test and production) in a manner that can be used for subsequent checking against actual deployment Deployment control including distribution Installation Asset Disposal Considerations Security Disposal PII and HIPAA Sensitive information Legislative mandates Legal requirements Environmental Disposal Precious metal recovery Hazardous substance disposal Legal requirements External repurposing te: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research

7 PROBLEM MANAGEMENT : The unknown cause of one or more incidents. : The process of preventing problems and resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented. Input Service Desk Event Proactive Supplier or Contractor Analyst Detection Major Procedure Logging / Service Categorization Prioritization Initial Known or Known Error / Service Closure Major? Major Review End Investigation and Workaround? Create Known Error Tier 2 Known Error Database / Service Investigation and Tier 3 / Service Detection Prioritization Investigation and Sample Detection Procedures Suspicion or detection of an unknown cause of one or more incidents by the Service Desk Analysis of an incident by a technical support group which reveals that an underlying problem exists, or is likely to exist. A notification from a supplier or contractor that a problem exists. Analysis the trend of incidents as part of proactive. Sample Fields Cross reference the related incident logs to capture details such as: User details Service details Equipment details Date/time initially logged Priority and categorization details description Details of all diagnostic or attempted recovery actions taken. Sample Prioritization Coding Priority and severity should be included in the Prioritization process. s are prioritized using the same methodology as incidents. Severity can be determined using the following criteria: Can the system be recovered, or does it need to be replaced? How much will it cost? How many people, with what skills, will be needed to fix the problem? How long will it take to fix the problem? How extensive is the problem? Urgency Impact High Medium Low High Medium Low Sample Approaches Chronological Analysis: Briefly document all events in chronological order to provide a timeline of events to help identify which events may have been triggered by others or to discount any claims that are not supported by the sequence of events. Kepner and Tregoe: Charles Kepner and Benjamin Tregoe developed a useful way of problem analysis which can be used formally to investigate deeply rooted problems. They defined the following stages: defining the problem describing the problem in terms of identity, location, time and size establishing possible causes testing the most probable cause verifying the true cause. Ishikawa Diagrams: A method of documenting causes and effects. The main goal is represented by the trunk of the diagram, and primary factors are represented as branches. Secondary factors are then added as stems, and so on. Creating the diagram stimulates discussion and often leads to increased understanding of a complex problem. Pareto Analysis: This is a technique for separating important potential causes from more trivial issues. The following steps should be taken: 1 Form a table listing the causes and their frequency as a percentage. 2 Arrange the rows in the decreasing order of importance of the causes 3 Add a cumulative percentage column to the table. 4 Create a bar chart with the causes, in order of their percentage of total. Superimpose a line chart of the cumulative percentages. 6 Draw line at 80% on the y axis parallel to the x axis. All data elements below where the line intersects with the curve are important causes Sample Develop fault elimination action plan Track progress of problem resolution against plan Document progress against plan Close problem once plan is complete te: Content included in this document is a combination of ITIL v3 Standards, leading practices from Deloitte subject matter experts and industry research

8

9 Fulfillment

10

11 Release