21 21 ITIL v3 Service Management 1 ITIL v3 Service Management as a Practice 21 21 ITIL v3 Service Management 2 Service Management as a Practice ITIL = IT Infrastructure Library §Set of books giving guidance on the provision of quality IT services §Common language §Best practices in delivery of IT services §Not standards! §Platform independent §3rd version 21 21 ITIL v3 Service Management 3 Service Management as a Practice §ITIL Certification of Individuals - Foundation –Content >Entrance level >General awareness of Service lifecycle >Understanding key elements >Knowledge of ITIL terminology >Core principles >Processes, roles and functions –Target group >IT professionals >People who need basic understanding (power users, customers, business service owners –Exam >Multiple choice, 40 questions, 60 minutes, Pass score 65%, Close book 21 21 ITIL v3 Service Management 4 Service Management as a Practice §ITIL is not the only best practice § § § § § § § § Procedures Process Operation Process Control Process Strategy ITIL CMMI COBIT The Control Objectives for Information and related Technology (COBIT) is a set of best practices (framework) for information technology (IT) management created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI) in 1996. COBIT provides managers, auditors, and IT users with a set of generally accepted measures, indicators, processes and best practices to assist them in maximizing the benefits derived through the use of information technology and developing appropriate IT governance and control in a company. Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization 21 21 ITIL v3 Service Management 5 Service Management as a Practice § §Service management is a set of specialized organizational capabilities for providing value to customer in the form of service § §Service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. 21 21 ITIL v3 Service Management 6 Service Management as a Practice §Functions, Roles and Processes –Function is a team or group of people and tools they use to carry out one or more processes or activities –Role is a set of responsibilities, activities and authorities granted to a person or team –Process is a set of activities design to accomplish a specific objectives and provide value to customers or stakeholders. Process is strategic asset when it creates competitive advantage and market differentiation 21 21 ITIL v3 Service Management 7 7 Maturity Levels of the process 1 2 3 4 5 In terms of: -vision -people -processes -technology -culture Initial Repeatable Defined Managed Optimizing §Level 1 - Initial –The process has been recognized but there is little or no process management activity and it is allocated no importance, resources or focus within the organization. This level can also be described as 'ad hoc' or occasionally even 'chaotic'. §Level 2 - Repeatable –The process has been recognized and is allocated little importance, resource or focus within the operation. Generally activities related to the process are uncoordinated, irregular, without direction and are directed towards process effectiveness. §Level 3 - Defined –The process has been recognized and is documented but there is no formal agreement, acceptance and recognition of its role within the IT operation as a whole. However the process has a process owner, formal objectives and targets with allocated resources, and is focused on the efficiency as well as the effectiveness of the process. Reports and results are stored for future reference. §Level 4 - Managed –The process has now been fully recognized and accepted throughout IT. It is service focused and has objectives and targets that are based on business objectives and goals. The process is fully defined, managed and has become proactive, with documented, established interfaces and dependencies with other IT process. §Level 5 - Optimizing –The process has now been fully recognized and has strategic objectives and goals aligned with overall strategic business and IT goals. These have now become 'institutionalized' as part of the everyday activity for everyone involved with the process. A self-contained continuous process of improvement is established as part of the process, which is now developing a pre-emptive capability. 21 21 ITIL v3 Service Management 8 Processes & KPI’s §Process characteristics –It is measurable –It delivers specific results –It delivers its primary results to a customer or stakeholder –It responds to specific events §Process Roles –Process Owner - Responsible with documenting the process, defining process Key Performance Indicators (KPIs), improving the process, ensuring process staff undertake the required training –Process Manager - The Process Manager’s responsibilities include planning and coordination of all Activities required to carry out, monitor and report on the Process. –Process Specific Roles - Responsible for specific task within the process §KPI‘s –Key Performance Indicators (KPI‘s) are quantifiable measurements, agreed to beforehand, that reflect the critical success factors of a process. • 21 21 ITIL v3 Service Management 9 Process Model/Description § §Procedure: a description of logically related activities and of who carries them out. A procedure may include stages from different processes. A procedure defines who does what §Work instruction: defines how one or more activities in a procedure should be carried out 21 21 ITIL v3 Service Management 10 Service Management as a Practice §Organizations: –are often highly dependent on the IT services –need IT services not only to support the organization but also to present new options to achieve the objectives §IT Service: –one or more IT systems which enable a business process –is a product the organization can buy: •Does the service align with my expectations? •Can I expect a similar service the next time? •Is the service provided at a reasonable cost? §Providers of IT Services –Type 1: Internal service provider –Type 2: Shared service provider –Type 3: External service provider There is a need to improve performance while managing trade-offs. Under similar pressure, customers seek advantage from service, they need IT services not only to support the organization, but also to present new options to achieve the objectives of the organization 21 21 ITIL v3 Service Management 11 Continual Improvement - Deming’s cycle § PDCA ("Plan-Do-Check-Act") Cycle is four-step problem-solving process typically used in quality control. It was made popular by Dr. W. Edwards Deming. Target is on Continuous Improvement of service. §PLAN - Establish the objectives and processes necessary to deliver results in accordance with the specifications. §DO - Implement the processes §CHECK - Monitor and evaluate the processes and results against objectives and Specifications and report the outcome. §ACT - Apply actions to the outcome for necessary improvement. This means reviewing all steps (Plan, Do, Check, Act) and modifying the process to improve it before its next implementation. 21 21 ITIL v3 Service Management 12 ITIL v3 Service lifecycle 21 21 ITIL v3 Service Management 13 The ITIL Service lifecycle approach §Manage services from the beginning to the end §Remove process silos §Enable integration with business processes §Use Deming quality cycle (PDCA) §Focused on service, not just process §Coordinated with ISO 20000 §Improved measurability and traceability 21 21 ITIL v3 Service Management 14 5 stages of service life cycle = 5 core ITIL books §Service strategy §Service design §Service transition §Service operation §Continual service improvement Business value realization Service Strategy: The Service Strategy volume provides guidance on how to design, develop, and implement service management not only as an organizational capability but also as a strategic asset. Service Design: The Service Design volume provides guidance for the design and development of services and service management processes. It covers design principles and methods for converting strategic objectives into portfolios of services and service assets. Service Transition: The Service Transition volume provides guidance for the development and improvement of capabilities for transitioning new and changed services into operations. Service Operation: This volume embodies practices in the management of service operations. It includes guidance on achieving effectiveness and efficiency in the delivery and support of services so as to ensure value for the customer and the service provider. Continual Service Improvement: This volume provides instrumental guidance in creating and maintaining value for customers through better design, introduction, and operation of services. 21 21 ITIL v3 Service Management 15 Service strategy Service design Service transition Service operation Continual service improvement Demand management IT Financial management Service catalogue mgmt Capacity management Service level mgmt Availability mgmt Service continuity mgmt Strategy gen Service portf.mgmt Information security management Supplier management Change management Service asset and configuration management Knowledge management Release and Deployment mgmt Valid & Testing Operation m. Access m. Request ful. Event m. Incident management Problem management Service improv. Service measure Service reporting The Service Lifecycle 21 21 ITIL v3 Service Management 16 Processes Service design Service transition Service operation Continual Service Improvement Strategy Generation Demand mgmt Financial mgmt Service catalogue mgmt Transition Pl & Sup Event mgmt 7-Steps improvement Info security mgmt Supplier mgmt Service cont mgmt Service level mgmt Capacity mgmt Availability mgmt Change mgmt Asset & Config mgmt Release & Deploy mgmt Validation & Testing Evaluation Knowledge mgmt Incident mgmt Request Fulfillment Problem mgmt Access mgmt Service reporting Service measurement Service strategy Service portfolio mgmt 21 21 ITIL v3 Service Management 17 Processes Service strategy Service design Service transition Service operation Continual Service Improvement Strategy Generation Service portfolio mgmt Demand mgmt Financial mgmt Service catalogue mgmt Transition Pl & Sup Event mgmt 7-Steps improvement Info security mgmt Supplier mgmt Service cont mgmt Service level mgmt Capacity mgmt Availability mgmt Change mgmt Asset & Config mgmt Release & Deploy mgmt Validation & Testing Evaluation Knowledge mgmt Incident mgmt Request Fulfillment Problem mgmt Access mgmt Service reporting Service measurement 21 21 ITIL v3 Service Management Utility Value Fit for purpose..? Fit for use..? Warranty Performance supported..? Constraints removed..? Availability enough..? Capacity enough..? Continuous enough..? Secure enough..? Business requirements Service portfolios (concepts of services definitions – outcome based) – from the perspective what is valuable for the customer 21 21 ITIL v3 Service Management §Utility & Warranty: define services and work together to create value § §Utility - fit for purpose = what the customer gets, the positive impact § §Functional requirements §What does the service do? §Features, inputs, outputs – – §Warranty- fit for use = how well it is delivered to the customer, the certainty of impact – in terms of security, availability, capacity and continuity §How well the service do it? §Non-functional requirements §Capacity, performance, availability Strategy Generation KEY TERMS 21 21 ITIL v3 Service Management 20 Service strategy Service design Service transition Service operation Continual Service Improvement Strategy Generation Service portfolio mgmt Demand mgmt Financial mgmt Service catalogue mgmt Transition Pl & Sup Event mgmt 7-Steps improvement Info security mgmt Supplier mgmt Service cont mgmt Service level mgmt Capacity mgmt Availability mgmt Change mgmt Asset & Config mgmt Release & Deploy mgmt Validation & Testing Evaluation Knowledge mgmt Incident mgmt Request Fulfillment Problem mgmt Access mgmt Service reporting Service measurement Service Design Processes 21 21 ITIL v3 Service Management 21 21 Service Design §Purpose –Design of new or changed services for introduction into the live environment –Design services to meet business objectives –Design processes to support the service lifecycle –Identify and manage risks –Design measurement methods and metrics §Main input §Service level package §Main output §Service design package – 21 21 ITIL v3 Service Management 22 Service catalogue management (SCM) – Key terms §The Service Catalogue provides a central source of information on the existing IT services delivered by the service provider organization. §The Business Service Catalogue contains details of all the IT services delivered to the customer. This is the customer view of the Service Catalogue. §The Technical Service Catalogue contains details of all the IT services delivered to the customer. This should underpin the Business Service Catalogue and not form part of the customer view. •Full descriptions: •The Service Catalogue also contains a customer-facing view of the IT services in use, how they are intended to be used, the business processes they enable, and the levels and quality of service the customer can expect for each service. •The Business Service catalogue contains details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT services. This is the customer view of the Service Catalogue. •The Technical Service Catalogue contains details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. This should underpin the Business Service Catalogue and not form part of the customer view. 21 21 ITIL v3 Service Management 23 23 Business vs. Technical service catalogue Technical Service catalogue Business Service catalogue Business Process A Business Process B Business Process C Service A Service B Service C Service D Service E Support Data Applications Software Hardware The Business Service Catalogue: containing details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT services. This is the customer view of the Service Catalogue. The Technical Service Catalogue: containing details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. This should underpin the Business Service Catalogue and not form part of the customer view. 21 21 ITIL v3 Service Management 24 Service level management (SLM) - Goal §Service Level Management (SLM) negotiates, agrees and documents appropriate IT service targets with representatives of the business, and then monitors and produces reports on the service provider’s ability to deliver the agreed level of service. §The goal of the Service Level Management process is to ensure that an agreed level of IT service is provided for all current IT services, and that future services are delivered to agreed achievable targets. 21 21 ITIL v3 Service Management 25 25 Service level management (SLM) – Key terms §Service Level Requirements (SLR) - A document that contains customer requirements regarding the IT services they want §Service Specification - The translation of the customer requirements into "how" the IT organization is going to provide these services §Service Level Agreement (SLA) - A document that defines agreed service levels between the customer and provider §Underpinning Contract (UC) - A document that defines agreed service levels between the internal IT organization and an external provider §Operational Level Agreement (OLA) - A document that defines agreed service levels between the internal IT organization and another internal provider §Service Quality Plan (SQP) - The plan contains information about performance indicators for the IT organization to measure the Services § 21 21 ITIL v3 Service Management 26 26 Service Level Management: Relationships between documents and involved parties Business SLA SLR UC OLA UC IT Organization Internal Partner External Partner 21 21 ITIL v3 Service Management 27 27 Capacity management - Goal §Capacity Management provides a point of focus and management for all capacity and performance - related issues, relating to both services and resources. § §The goal of the Capacity Management process is to ensure that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner. § 21 21 ITIL v3 Service Management 28 28 Capacity management – Key terms §Capacity Plan –documents the current levels of resource utilization and service performance –forecasts the future requirements §Capacity Database (CMIS - Capacity Management Information System) –Capacity plan –Capacity performance data –Business forecasts §Sub-processes: –Business Capacity Management – translates business needs and plans into requirements for service and IT infrastructure –Service Capacity Management – manages, controls and predicts the performance and capacity of the IT services –Component Capacity Management – manages, controls and predicts the performance, utilization and capacity of IT components 21 21 ITIL v3 Service Management 29 Supplier Management – Goal §The goal of the Supplier Management process is to manage suppliers and the services they supply, to provide seamless quality of IT service to the business, ensuring value for money is obtained § §It is essential that Supplier Management processes and planning are involved in all stages of the Service Lifecycle, from strategy and design, through transition and operation, to improvement. 21 21 ITIL v3 Service Management 30 Supplier Management – Key terms §Supplier service improvement plans (SSIP) - records improvement plans with the supplier §Supplier survey reports - feedback gathered from individuals that deal with supplier §Supplier & Contract performance report – input for the review meetings to manage the quality §Types of supplier agreements: –Co-sourcing – An informal combination of insourcing and outsourcing –Partnership (multi-sourcing) – formal agreement between two or more organizations to work together –Business process outsourcing – formal agreement provides and manages the business process 21 21 ITIL v3 Service Management 31 Supplier Management – Key terms §Supplier and Contract database (SCD) –Part of SKMS ( Service Knowledge Management System ) –Contains •Policies •Supplier and contract details •Types of services •Products •Relationships with CI‘s ( Configuration Item ) 21 21 ITIL v3 Service Management 32 Supplier Management - Activities –Purchasing/procurement –Contract development and administration –Strategic planning / sourcing –Relationship management –Supplier evaluation –Economic forecasting 21 21 ITIL v3 Service Management 33 Supplier Management – Benefits §Protected from poor supplier performance §Supporting services align with business needs §Better availability §Clear ownership of supplier and contractual issues. 21 21 ITIL v3 Service Management 34 Supplier Management - Risks §Lack of commitment from management §Lack of information on future plans §Suppliers agree to targets impossible to meet §Suppliers are not cooperative §The process becomes too bureaucratic §Poor corporate financial processes 21 21 ITIL v3 Service Management 35 35 Goal: To ensure that the level of service availability delivered in all services is matched to or exceeds the current and future agreed needs of the business in a cost-effective manner. Concerned with availability of services and components – NOT PEOPLE. Availability Management - Goal 21 21 ITIL v3 Service Management 36 36 Availability Management – Relationships (Availability Management and the incident lifecycle) Metrics: 1. MTTR: Mean Time To Repair – „Downtime“ (Used to express average Maintainability) 2. MTBF: Mean Time Between Failures – „Uptime“ (Used to express average Availability) 3. MTBSI: Mean Time Between System Incidents (Used to express average Reliability) Understanding the Incident 'lifecycle' It is important to recognize that every Incident passes through a number of stages. These are described as follows: Incident start Incident detection Incident diagnosis component repair component recovery service restoration (and verification). This 'lifecycle' view provides an important framework in determining amongst others, systems management requirements for Incident detection, diagnostic data capture requirements and tools for diagnosis, recovery plans to aid speedy recovery and how to verify that IT Service has been restored. 21 21 ITIL v3 Service Management Availability Management and the incident lifecycle Down Time Up Time MTBSI (Reliability) MTRS (Maintainability) MTBF (Availability) System Incident System Incident MTRS – Mean Time to Restore Service (depends on MTTR – Mean Time To Repair individual IT components) MTBF – Mean Time Between Failures – Failure free period MTBSI – Mean Time Between System Incidents – The mean period of time between two system incidents 21 21 ITIL v3 Service Management 38 38 Availability Management § §Availability: the ability of a service, component or CI to perform its agreed function when required. It is often measured and reported as a percentage: § § § § §Note: Downtime should only be included in the above calculation when it occurs within the Agreed Service Time (AST). However, total downtime should also be recorded and reported. § § § § § (Agreed Service Time (AST) – downtime) Availability (%) = ———————————- X 100 % Agreed Service Time (AST) 21 21 ITIL v3 Service Management 39 39 Availability Management §Reliability: a measure of how long a service, component or CI can perform its agreed function without interruption. The reliability of the service can be improved by increasing the reliability of individual components or by increasing the resilience of the service to individual component failure. It is often measured and reported as Mean Time Between Service Incidents (MTBSI) or Mean Time Between Failures (MTBF): § 21 21 ITIL v3 Service Management 40 40 Availability Management Maintainability: a measure of how quickly and effectively a service, component or CI can be restored to normal working after a failure. It is measured and reported as Mean Time to Restore Service (MTRS) and should be calculated using the following formula: 21 21 ITIL v3 Service Management 41 41 Availability Management - Key terms §Availability: The ability of an IT Service or component to perform its required function at a stated instant or over a stated period of time. §AMIS: Availability Management Information System §Reliability: Freedom from operational failure. §Resilience: The ability to withstand failure. §Maintainability (internal): The ability of an IT component to be retained in or restored to, an operational state. - based on skills, knowledge, technology, backups, availability of staff. § 21 21 ITIL v3 Service Management 42 Processes Service strategy Service design Service transition Service operation Continual Service Improvement Strategy Generation Service portfolio mgmt Demand mgmt Financial mgmt Service catalogue mgmt Transition Pl & Sup Event mgmt 7-Steps improvement Info security mgmt Supplier mgmt Service cont mgmt Service level mgmt Capacity mgmt Availability mgmt Change mgmt Asset & Config mgmt Release & Deploy mgmt Validation & Testing Evaluation Knowledge mgmt Incident mgmt Request Fulfillment Problem mgmt Access mgmt Service reporting Service measurement 21 21 ITIL v3 Service Management 43 Service Transition §Purpose –Deliver services that are required by the business into operational use –Implement all aspects of the service –Application and adaptation of service design, including arranging for modification of the design, where the need is detected during transition –Support knowledge transfer, decision support and re-use of processes, systems and other elements § § § § Service Design Package Service transition processes Service in Prod. environment Service Transition is the third book of the Service Lifecycle. Main input Service design package Key processes/activities Change management Service asset and configuration management Knowledge management Evaluation management Transition planning and support Release and deployment management Service validation and testing Main output Service in production environment 21 21 ITIL v3 Service Management 44 Change Management - Goals §Use standardized methods and procedures to control change implementation § §Respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption and re-work. § §Respond to the business and IT requests for change that will align the services with the business needs. § §Standardized methods and procedures are used for efficient and prompt handling of all changes. § §Minimize the risks associated with change § § - Change management – Objectives - Ensures that standardized methods and procedures are used for efficient and prompt handling of all changes in order to minimize the impact of any change –related Incidents upon service quality and consequently to improve the day-by-day operations of the organization Objectives The goal statement of Change Management is to ensure that standardized methods and procedures are used for efficient handling of all Changes, in order to minimize the impact of Change-related incidents and to improve day-to-day operations. The goal also build an internal understanding of the "how and why" for the process (how =standardized methods and procedures, why = to minimize impact). For an effective and efficient IT service delivery it is necessary to have the capability to implement many changes correctly. Changes in reality often lead to (implementation) problems. "Not every Change is an improvement but every improvement requires a change" The created problems are subsequently resolved by the implementation of a change, which in turn leads to more problems. Breaking this negative spiral is an important task for Change Management. 21 21 ITIL v3 Service Management 45 Change Management - Definitions § §Change : The addition, modification or removal of CIs – §Request for Change (RFC) : Form used to record details of a request for a change to any CI § §Change Advisory Board (CAB) : Group of representative people responsible for assessing all RFC's § §CAB Emergency Committee (ECAB) : Consists of one to three key staff Available 24 x 7 § §Forward Schedule of Changes (FSC) : Schedule that contains details of all changes authorized for implementation § §Projected Service Availability (PSA) : Document used to outline effect of changes on availability levels as defined in SLA's Change Management Terminology Change the addition, modification or removal of CIs Request for Change (RFC) form used to record details of a request for a change and is sent as an input to Change Management by the Change Requestor Forward Schedule of Changes (FSC) schedule that contains details of all the forthcoming Changes 21 21 ITIL v3 Service Management 46 Change Management - Definitions § §Change Categories –Category 0 : Is executed without prior contact. Used for workarounds/ temporary fixes –Category 1 : Little or no impact. Change Manager authorizes this RFC –Category 2 : Significant impact. CAB discussion needed. Change Manager requests advice on authorization and planning –Category 3 : Major impact. Considerable resources required. Senior Management need to be a part of the CAB. §Change Priorities –Urgent: change is required now, in order to achieve the service levels –High: as soon as possible, otherwise risk to current or future production –Normal: change solves serious mistakes or a lack in functionality –Low: change yields improvements that are not required by contract – §Change Types: –Standard ( pre- approved ) –Ordinary : Minor, Significant , Major. –Urgent Change Categories Category 0 : Is executed without prior contact. Used for workarounds/ temporary fixes Category 1 : Little or no impact. Change Manager authorizes this RFC Category 2 : Significant impact. CAB discussion needed. Change Manager requests advice on authorization and planning Category 3 : Major impact. Considerable resources required. Senior Management need to be a part of the CAB. Change Priorities Urgent: change is required now, in order to achieve the service levels High: as soon as possible, otherwise risk to current or future production Normal: change solves serious mistakes or a lack in functionality Low: change yields improvements that are not required by contract 21 21 ITIL v3 Service Management 47 §Registration and classification: –All requests for change must be legged using RFC form –The change manager briefly filter requests and reject any that are impractical, undesirable or repetitive –The change manager classify the changes § Approval: –Based on the assigned change type the RFC is approved (Minor, Significant, Major) –The approved change is scheduled §Authorization and Implementation: –Prepare and build the change –Test the change –Authorize the change –Implement the change –Document the change § Verify: –Verification that the change was implemented according to the specification –Make the Post implementation review Change Management - Activities Activities Recording Although this activity is not carried out by Change Management itself, it is the responsibility of Change Management to make sure all Changes are recorded correctly. Accepting (Rejecting) At this stage RFC’s will be reviewed and accepted or rejected. Any rejection should always be communicated and explained. A reason for the rejection of an RFC might be that it is incomplete or illogical. Accepted RFC's then be classified. Ex: A new disk unit has to be installed to solv a problem with performing back-ups over the network. The procedures for doing the back-ups have to be changed as well. In this case Change Management is the process that has to give formal approval for carrying out these changes. 21 21 ITIL v3 Service Management 48 48 Service strategy Service design Service transition Service operation Continual Service Improvement Strategy Generation Service portfolio mgmt Demand mgmt Financial mgmt Service catalogue mgmt Transition Pl & Sup Event mgmt 7-Steps improvement Info security mgmt Supplier mgmt Service cont mgmt Service level mgmt Capacity mgmt Availability mgmt Change mgmt Asset & Config. mgmt Release & Deploy mgmt Validation & Testing Evaluation Knowledge mgmt Incident mgmt Request Fulfillment Problem mgmt Access mgmt Service reporting Service measurement Service Desk Technical mgmt IT Operation mgmt Application mgmt Processes and Functions Functions 21 21 ITIL v3 Service Management 49 49 § To coordinate and to carry out the activities and processes required to deliver and to manage services at agreed upon levels to business users and customers. § To enable effectiveness and efficiency in delivery and support of IT Services. § Responsible for the ongoing management of the technology § Includes the implementation and carrying out of all ongoing activities required to deliver and support services. §Realizing the value customers wants Service Operation – Goals Service in Prod. environment Service Operation processes Service operated with agreed level Purpose/goal/objective The purpose of Service Operation is to coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers. Service Operation is also responsible for the ongoing management of the technology that is used to deliver and support services. Well-designed and well-implemented processes will be of little value if the day-to-day operation of those processes is not properly conducted, controlled and managed. Service improvements will not be possible if day-to-day activities to monitor performance, assess metrics, and gather data are not systematically conducted during Service Operation. Service Operation includes the implementation and carrying out of all ongoing activities required to deliver and support services. 21 21 ITIL v3 Service Management 50 50 Event: - any detectable or discernable occurrence that has significance for the management of the IT infrastructure - a change of state that has significance for the management of a Configuration Item (including IT Services). This can be detected by technical staff or be automated alerts or notifications created by an IT Service, Configuration Item(CI) or monitoring tool. Event - informational - This refers to an event that does not require any action and does not represent an exception – Ex: A user logs onto an application. Event - warning - event that is generated when a service or device is approaching a threshold Event - exception - a service or device is currently operating abnormally (however that has been defined). Alert: A warning that a threshold has been reached or something has been changed. (An event has occurred) Trigger: An indication that some action or response to an Event may be needed. Event Management – Key Terms Event - Any detectable or discernable occurrence that has significance for the management of the IT infrastructure Policies/principles/basic concepts There are many different types of events, for example: Events that signify regular operation - notification that a scheduled workload has completed Events that signify an exception - a device’s CPU is above the acceptable utilization rate Events that signify unusual, but not exceptional, operation - The completion time of a transaction is 10% longer than normal. 21 21 ITIL v3 Service Management 51 51 Incident Management – Goals § To restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. § Incidents can be reported by anyone who detects a disruption or potential disruption to normal service. This includes technical staff § Incident Management is the process for dealing with all incidents; this can include failures, questions or queries reported by the users (usually via a telephone call to the Service Desk), by technical staff, or automatically detected and reported by event monitoring tools. § Known Error Record and the Incident Model are used for managing incidents § Purpose/goal/objective The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within SLA limits. Scope Incident Management includes any event which disrupts, or which could disrupt, a service. This includes events which are communicated directly by users, either through the Service Desk or through an interface from Event Management to Incident Management tools. Incident Management concentrates on restoring unexpectedly degraded or disrupted services to users as quickly as possible, in order to minimize business impact. Although both incidents and service requests are reported to the Service Desk, this does not mean that they are the same. Service requests do not represent a disruption to agreed service, but are a way of meeting the customer’s needs and may be addressing an agreed target in an SLA. Service requests are dealt with by the Request Fulfillment process. 21 21 ITIL v3 Service Management 52 52 Incident Management – Activities (contd..) §Incident Classification §Categorization – Application, Hardware, Service Request, Security Incident –WHY? To establish trends for use in Problem Management and other IT Service Management (ITSM) activities – Prioritizing – Impact : extent of the deviation from the normal service level; aspects are the number of users and the service concerned – Urgency : To what extent the solution of an incident can be postponed – 52 Priority = Impact X Urgency Next slide Categorization: All incidents are categorized in order to establish appropriate priorities and resolution lead times : Application (Service not available, Application bug/query),Hardware (Automatic alert, Printer not printing),Service Request (Password forgotten),Security Incident (Virus) The criteria to consider when assigning priority are: impact and urgency . The priority with which Incidents need to be resolved will depend upon : The impact on the business ,The urgency with which a resolution/work-around is needed, The size, scope and complexity of the Incident, The resources available for correcting the fault. 21 21 ITIL v3 Service Management 53 53 Problem Management - Goals §Minimize the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure, §Seek to identify a permanent resolution to a number or reoccurring incidents §Prevent recurrence of Incidents related to errors. In order to achieve this goal, Problem Management seeks to get to the root cause of Incidents and then initiate actions to improve or correct the situation §Problem Management differs from Incident Management in that its main goal is the detection of the underlying causes of an Incident and their subsequent resolution and prevention. The goal of Incident management is to restore the service to the Customer as quickly as possible. Purpose/goal/objective Problem Management is the process responsible for managing the lifecycle of all problems. The primary objectives of Problem Management are to prevent problems and resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented. Scope Problem Management includes the activities required to diagnose the root cause of incidents and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially Change Management and Release Management. Problem Management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents over time. In this respect, Problem Management has a strong interface with Knowledge Management, and tools such as the Known Error Database will be used for both. Although Incident and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related incidents and problems. Problem Management differs from Incident Management in that its main goal is the detection of the underlying causes of an Incident and their subsequent resolution and prevention. In many situations this goal can be in direct conflict with the goals of Incident Management where the aim is to restore the service to the Customer as quickly as possible, often through a Work-around, rather than through the determination of a permanent resolution (for example, by searching for structural improvements in the IT infrastructure, in order to prevent as many future Incidents as possible). In this respect, therefore, the speed with which a resolution is found is only of secondary (albeit still of significant) importance. Investigation of the underlying Problem can require some time and can thus delay the restoration of service, causing downtime but preventing recurrence. The Problem Management process is intended to reduce both the number and severity of Incidents and Problems on the business. Therefore, part of Problem Management's responsibility is to ensure that previous information is documented in such a way that it is readily available to first-line and other second-line staff. This is not simply a matter of producing documentation. 21 21 ITIL v3 Service Management 54 54 Problem Management – Key Terms §Problem - The unknown underlying cause of one or more Incidents §Work-around - A temporary fix to recover a disrupted service after an incident. Are documented into problem records §Known Error - A Problem that is successfully diagnosed and for which a Work-around is known §Known Error Database (KEDB) - Repository of known errors for the benefit and utilization of Incident Management §RFC - A Request For Change to any component of an IT Infrastructure or to any aspect of IT services § Relationship between Incidents, Problems, Known Errors and RFCs Figure 5.4-Relationship between Incidents, Problems, Known Errors and RFCs A Problem is a condition often identified as a result of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant. A Known Error is a condition identified by successful diagnosis of the root cause of a Problem, and the subsequent development of a Work-around. Not all Known Errors need to be resolved. An organization can decide to allow Known Errors to remain - for instance because the resolution is too expensive, technically impossible, or requires too much time to resolve. 21 21 ITIL v3 Service Management 55 Continual Service Improvement - Processes Service strategy Service design Service transition Service operation Continual Service Improvement Strategy Generation Service portfolio mgmt Demand mgmt Financial mgmt Service catalogue mgmt Transition Pl & Sup Event mgmt 7-Steps improvement Info security mgmt Supplier mgmt Service cont mgmt Service level mgmt Capacity mgmt Availability mgmt Change mgmt Asset & Config mgmt Release & Deploy mgmt Validation & Testing Evaluation Knowledge mgmt Incident mgmt Request Fulfillment Problem mgmt Access mgmt Service reporting Service measurement 21 21 ITIL v3 Service Management 56 Continual Service Improvement § Purpose §Aims to continually align IT services to changing business needs by identifying and implementing improvements §Continually looking for ways to improve process efficiency and effectiveness as well as cost effectiveness Existing services and processes Improved services and processes Continual Service Improvement Processes These improvement activities support the lifecycle approach through Service Strategy, Service Design, Service Transition, Service Operation. In effect, CSI is about looking for ways to improve process effectiveness, efficiency as well as cost effectiveness. Objectives of CSI are to review, analyse and make recommendations to each lifecycle phase. Review and analyze Service level achievement results,etc .etc.. Consider the following saying about measurements and management: You cannot manage what you cannot control. You cannot control what you cannot measure. You cannot measure what you cannot define. 21 21 ITIL v3 Service Management 57 The RACI matrix. 2009-09-15_235128 The authority matrix clarifies to all involved which activities they are expected to fulfill, as well as identifying any gaps in service delivery and responsibilities. It is especially helpful in clarifying the staffing model necessary for improvement. It clearly defines roles and responsibilities for an initiative It clarifies what activities everyone involved needs to perform It defines gaps in responsibility and in service delivery It identifies potential OLAs through the responsibilities shown on the paths It exposes communication paths It exposes workflow paths Problems associated with using a RACI authority matrix are: Responsibility or accountability may be delegated without the necessary authority People may focus on matching processes and activities within departments instead of across departments Functions may be incorrectly combined or divided, leading to conflicting agendas or goals The combination of responsibility for closely related processes may be confusing THE AUTHORITY MATRIX A key characteristic of a process is that all related activities need not necessarily be limited to one specific organizational unit. EX: Configuration Management process activities, for example, can be conducted in departments such as computer operations, system programming, Application Management, Network Management, Systems Development and even non-IT departments like procurement, warehouse or accounting. Since services, processes and their component activities run through an entire organization, the individual activities should be mapped to the roles defined above. The roles and activities are coordinated by process managers. Once detailed procedures and work instructions have been developed, an organization must map the defined roles and the activities of the process to its existing staff. Clear definitions of accountability and responsibility are CSFs for any improvement activity. Without this, roles and responsibilities within the new process can be confusing, and individuals will revert to ‘the way we’ve always done it’ before the new procedures were put in place. To assist with this task an authority matrix is often used within organizations indicating roles and responsibilities in relation to processes and activities. While there are many variations of the authority matrix, the RACI model, also supported by COBIT 21 21 ITIL v3 Service Management 58 §Metrics: –define what is to be measured –are a system of parameters or ways of quantitative assessment –Include the way of how the measurement is carried out §Types of metrics: –Technology metrics (ex. Application performance, component serviceability, etc.) –Process metrics (ex. efficiency, compliance, etc.) –Service metrics (ex. availability, quality, etc.) Service Measurement - Metrics It is important to remember that there are three types of metrics that an organization will need to collect to support CSI activities as well as other process activities. Technology metrics – These metrics are often associated with component and application – based metrics such as performance, availability etc. Process metrics – These metrics are captured in the form of CSFs, KPIs and activity metrics for the service management processes. These metrics can help determine the overall health of a process. Four key questions that KPIs can help answer are around quality, performance, value and compliance of following the process. CSI would use these metrics as input in identifying improvement opportunities for each process. Service metrics – These metrics are the results of the end-to-end service. Component metrics are used to compute the service metrics. page 61 CSI In general, a metric is a scale of measurement defined in terms of a standard, i.e. in terms of a well-defined unit. The quantification of an event through the process of measurement relies on the existence of an explicit or implicit metric, which is the standard to which measurements are referenced. Metrics are a system of parameters or ways of quantitative assessment of a process that is to be measured, along with the processes to carry out such measurement. Metrics define what is to be measured. Metrics are usually specialized by the subject area, in which case they are valid only within a certain domain and cannot be directly benchmarked or interpreted outside it. Generic metrics, however, can be aggregated across subject areas or business units of an enterprise. 21 21 ITIL v3 Service Management 59 §Identify the purpose, the target audience and what the report will be used for. §Build a business-focused Service Reporting Framework. §Define and agree the policy and rules with the Business and Service Design about how reporting will be implemented and managed. –Agreement on what to measure and what to report on –Agreed definitions of all terms and boundaries –Basis of all calculations –Reporting schedules –Access to reports and medium to be used –Meetings scheduled to review and discuss reports. Service Reporting - Objectives It is no longer sufficient to measure and report against the performance of an individual component such as a server or application. IT must now be able to measure and report against an end-to-end service. In many cases when an organization is monitoring, measuring and reporting on component levels they are doing so to protect themselves and possibly to point the blame elsewhere -’My server or my application was up 100% of the time.’ Service measurement is not about placing blame or protecting oneself but is really about providing a meaningful view of the IT service as the customer experiences the service. The server may be up, but because the network is down, the customer is not able to connect to the server. Therefore the IT service was not available even though one or more of the components used to provide the service was available the whole time. Being able to measure against a service is directly linked to the components, systems and applications that are being monitored and reported on. For services there are three basic measurements that most organizations utilize. ■ Availability of the service ■ Reliability of the service ■ Performance of the service 21 21 ITIL v3 Service Management 60 §Service Reporting - Activities 2009-09-15_213929 21 21 ITIL v3 Service Management 61 The 7-Step Improvement Process 2009-09-15_202853 The 7-Step Improvement Process covers the steps requires to collect data, analyze this data to identify trends and issues, present the information to the management for their prioritization and agreement and implement improvements. 0STEP - Steps in the process are directly related to the strategic, tactical and operational goals that have been defined for measuring services and service management processes as well as the existing technology and capability to support measuring and CSI activities. 1STEP - A set of measurements should be defined that fully support the goals of the organization. The focus should be on identifying what is needed to satisfy the goals fully, without considering whether the data is currently available. 2STEP - Organizations may find that they have limitations on what can actually be measured, but it is useful to recognize that such gaps exist and what risks may be involved as a result. A gap analysis should be conducted between what is or can be measured today and what is ideally required. The gaps and implications can then be reported to the business, the customers and IT management. It is possible that new tools or customization will be required at some stage. 3STEP - Gathering data requires having some form of monitoring in place. A combination of monitoring tools and manual processes should be put in place to collect the data needed for the measurements that have been defined. Quality is the key objective of monitoring for CSI. Therefore monitoring focuses on the effectiveness of a service, process, tool, organization or CI. The emphasis is on identifying where improvements can be made to the existing level of service, or IT performance, typically by detecting exceptions and resolutions. CSI is not only interested in exceptions. If a Service Level Agreement is consistently met over time, CSI is also interested in determining whether that level of performance can be sustained at a lower cost or whether it needs to be upgraded to an even better level of performance. 4STEP - Raw data is processed into the required format, typically providing an end to end perspective on the performance of services and/or processes. Processing the data is an important CSI activity that is often overlooked. While monitoring and collecting data on a single infrastructure component is important, it is key to understand that component’s impact on the larger infrastructure and IT service. 5STEP - Data analysis transforms the information into knowledge of the events that are affecting the organization. Once the data is processed into information, the results can be analyzed to answer questions such as: Are we meeting targets? Are there any clear trends? Are corrective actions required? What is the cost? … 6STEP - The knowledge gained can now be presented in a format that is easy to understand and allows those receiving the information to make strategic, tactical and operational decisions. The information needs to be provided at the right level and in the right way for the intended audience. It should provide value, note exceptions to service, and highlight any benefits that have been identified during the time period. 7STEP - The knowledge gained is used to optimize, improve and correct services, processes, and all other supporting activities and technology. The corrective actions required to improve the service should be identified and communicated to the organization. CSI will identify many opportunities for improvement and an organization will need to determine priorities based on their goals, and the resources and funding available. 21 21 ITIL v3 Service Management Thank you § § §Question? § § 62