ITIL Process Management An Overview of Service Management Processes IT109 North Seattle College Larry Ryan

Introduction to ITIL ITIL – Information Technology Infrastructure Library Developed by the Office for Government Commerce (OGC) in England Best practices focused on the management of IT service processes Open source

Three Levels of Certification Foundation Focused on an understanding of the overall linkages between the stages in the lifecycle, the processes used and their contribution to Service Management practices. Intermediate Operational Support and Analysis (OSA) Service Offerings and Agreements (SOA) Planning, Protection and Optimization (PPO) Release, Control and Validation (RCV). Advanced Professional The ITIL Advanced Diploma in IT Service Management will assess an individual’s ability to apply and analyze the ITIL concepts in new areas.

ITIL Service Management (ITSM) Two main components: Service Support – five processes that provide support for day-to-day operation of IT services Service Delivery – five processes that focus on long-term planning and improvement of IT services These two components are linked together through the Service Desk – a function that provides a single point of contact that focuses on rapid restoration of normal service operations to users

The Big Picture

ITIL Service Management Change Management Service Level Management Release Management Financial Management Incident Management Availability Management Service Support Service Delivery Configuration Management Problem Management IT Service Continuity Management Capacity Management Service Desk

ITIL Service Management Goals Ensure that IT services are aligned to the needs of customers and users Improve availability and stability of services Improve communication within IT and with users Improve efficiency of internal processes

ITIL Processes Each ITIL process has associated: Goals Definitions Activities

Service Support Service Support Change Management Incident Management Release Management Service Support Configuration Management Problem Management

Change Management Goal To ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of any related incidents upon service. Definition Change is an action that results in a new status for one or more IT infrastructure Configuration Items (CI).

Change Management Activities Accept, record, authorize, plan, test, implement and review Requests for Change (RFCs) Provides reports of changes to the infrastructure Provides updates to the Configuration Management Database (CMDB). (Formal process)

Configuration Management Goal To provide a logical model of the IT infrastructure (hardware, software and associated documentation) by identifying, maintaining and verifying the version of all configuration items. Definition A Configuration Item (CI) is a component of the infrastructure. Configuration Management Database (CMDB) is a database which holds a record of all configuration items associated the IT infrastructure.

Configuration Management Activities Plan, design and manage a Configuration Management Database (CMDB) Identify CIs for entry into CMDB and their relationships to each other Verify CMDB accuracy

Service Support again…… Change Management Incident Management Release Management Service Support Configuration Management Problem Management

Incident Management Goal To restore normal service operation as quickly as possible and minimize the adverse impact on users and the organization. Definition An incident is any event which causes, or may cause an interruption to, or a reduction in, the quality of a service.

Incident Management Activities Detect, classify, record, and provide initial support of incidents Prioritize incidents based upon impact and urgency Service Desk is responsible for Incident Management

Problem Management Goal To minimize the adverse impacts of incidents and to prevent recurrence of incidents. Problem Management seeks to get to the root cause and initiate action to remove the error. Definition A problem is the unknown, underlying cause of one or more incidents. A known error is when the root cause of a problem is known and a temporary workaround or alternative has been identified.

Problem Management Activities Analyze incidents to identify underlying problems Record, classify and diagnose problems Transfer problems into “known errors” Generate Requests for Changes (RFCs) to resolve problems and errors Problems are identified and managed separately from incidents (although linked)

Service Support again…. Change Management Incident Management Release Management Service Support Configuration Management Problem Management

Release Management Goal To coordinate service providers and vendors involved with a significant release of hardware, software and associated documentation across a distributed environment. Definition A release is a collection of authorized changes to an IT service and is defined by the RFC that it implements.

Release Management Activities Plan and oversee successful rollout of new and changed software, hardware and documentation Collaborate with Change Management Verify that all release items are entered into the CMDB Manage customer and user expectations. Maintain Definitive Software Library (DSL) and Definitive Hardware Store (DHS)

ITIL Service Desk Service Service Support Delivery Change Management Service Level Management Release Management Financial Management Incident Management Availability Management Service Support Service Delivery Configuration Management Problem Management IT Service Continuity Management Capacity Management Service Desk Single point of contact

Service Desk Goal A single point of contact that provides advice and guidance and rapid restoration of normal service operations to users Definition A Service Request is a request that is not due to disruption.

Service Desk Activities Manage the Incident and Service Request life-cycle, including closure Communicate with customers concerning request status and progress Provide initial assessment and attempt to resolve incidents working with appropriate IT staff Provide reports and recommendations to management for service improvement

Service Delivery Service Delivery Service Level Management Availability Management Financial Management Service Delivery IT Service Continuity Management Capacity Management

Service Level Management Goal To maintain and improve IT Service quality through a constant cycle of agreeing, monitoring and reporting to meet the customers’ objectives. Definition Service Level Agreement (SLA) is a written agreement with the customer. Operational Level Agreement (OLA) is an agreement between two internal areas.

Availability Management Goal To optimize the capability of the IT infrastructure, services, and supporting organization to deliver a cost effective and sustained level of availability enabling IT to meet their objectives. Definition Availability is the ability of an IT service or component to perform its required function at a stated instant or over a stated period of time.

Capacity Management Goal To ensure that all the current and future capacity and performance aspects of the business requirements are provided cost effectively.

Financial Management Goal To provide cost-effective stewardship of the IT assets and resources used in providing IT services.

IT Service Continuity Management Goal To ensure that the required IT technical and service facilities can be recovered within required and agreed timeframes Definition A crisis is an unplanned situation when one or more IT services is unavailable and when the outage exceeds the expectations of the customer

Processes and Functions Process: a structured set of activities designed to accomplish a specific objective. Defined inputs Defined outputs Measurable by performance Benefit to customers and stakeholders

Process Model

Processes and Functions Function: a team or group of people and other resources or tools that are used to carry out a process or process activity Roles responsible for carrying out Functions: Group, Team, Department and Division

Service Lifecycle Service Strategy Service Design Service Transition Strategic approach for service management activities Service Design Customer requirements plus strategy Service Transition Roll out new and changed services Service Operation Manage day to day service delivery plus optimizing effectiveness and efficiency Continual Service Improvement Continual alignment to changing business needs

Service Strategy What is the strategy? Who are the customers? What are the services? Define value creation Define delivery Define opportunities to provide services Deliver a provisioning model Coordinate and document service assets Processes and services to deliver the strategic ITSM plan Establish relationship between service provider and customer

Consistent management of IT services Strategy: gives the service provider guidance and recommendations about delivering services to meet the customers business outcomes. Define a strategy for managing those services

Service Value is defined by customer Link service provider activities to business-critical outcomes Support customer’s success Deliver value! Respond to business change Service portfolio delivers positive ROI Transparent communication with customer Organize for service delivery

Utility vs Warranty in Value Creation Utility: fit for purpose, what the customer gets, increases performance average (service supported?) Warranty: fit for use, how the service is delivered to the customer, decreases variation (secure, enough capacity, continuous, available?) Unless utility and warranty are developed and explained to the customer, the value of IT services cannot be realized by your customer and you will not be able to attach a meaningful price tag on your IT services.

Assets, Resources and Capabilities Assets: the resources and capabilities, IT services should be a customer’s service asset. Assets must create value. Resources: the direct input for the production of services ($, people, infrastructure….) Capabilities: assets that represent the organization’s ability to do something to achieve value – typically knowledge or information based (coordinate, control, provision)

Assets, Resources and Capabilities Examples of capabilities and resources:

IT Governance, ISO/IEC 38500 IT Governance: where IT and business meet

IT Governance Governance insures that policies and strategies are actually implemented and that the required processes are correctly followed. Service management MUST include the standards and policies of corporate governance Governance is the driver for ITIL continual service improvement also called “CSI”

Risk Management Also called “risk mitigation” Identify risks and create a mitigation action plan for each The list of risks and the action plans form the Risk Management Plan

Pattern of Business Activity: “PBA” The primary source of information regarding anticipated service demand. PBA sets service asset requirements PBA analysis requires careful study of the customers business to truly understand the customer demand cycle. Creates an opportunity for the service provider to create or add value

Demand management

Service Design Deliver a new service or change to an existing service that is capable of delivering the strategic outcome. Four Ps: People, Processes, Products and Partners must be considered rather than narrow technical solution to a problem.

Service design scope Aligned with business needs Design coordination SLA management Availability and capacity management IT service continuity management Security Supplier management

Value of Service Design Lower cost of ownership over the service lifecycle Warranty will insure all aspects of the service are included in the design process. Service Design Package insures transition of the new service from to design to live Good governance through appropriate metrics Insure strategic requirements are aligned with the business

Service Transition Ensure that the services that have been designed are now delivered effectively into operation. This stage is concerned with customer, user and support staff. Also a consideration with retiring a service.

Service Transition objectives Plan and manage changes and the introduction of new services (or retirement of old services) Manage risk Successful deployment and/or provisioning Set performance expectation Ensure delivery of business value Provide knowledge and information about the services and service asssets.

Service Transition value While delivering changes, provide guidance on how to adopt and implement these changes. Properly designed, it will result in the ability to manage higher volumes of change. Reduce the effort spent on managing test and pilot environments (“sand boxes”). Increased confidence on the part of the recipients of the changes. Enables control of costs and assets Ensure seamless delivery of changes into the live environment.

Resources are people too

CSI – Continual Service Improvement Purpose: continue to support the business with IT services in the face of changing business needs. It must be perceived by business units that IT and the changes match the changes in business Measurement is critical in this stage Must include cost effectiveness and efficiency

CSI Objectives Review, analyze, prioritize and recommend improvement in all lifecycle stages Review and analyze service level achievements according to SLAs in place. Measure quality! Understand what to measure, why measure it and what is defined as a successful outcome. Yes, even QoS. Improve cost effectiveness of IT service delivery.

CSI Elements

CSI Value Controlled, gradual and maintainable improvement Assures an acceptable level of support Gradual and sustainable increase in capability due to increased efficiency and effectiveness Monitoring and reporting on performance allows for improvement opportunities. Tools?

Service Portfolio Management Purpose: Ensure an appropriate mix of services are delivered by the service provider to meet the needs of the customer. Ensures a clear definition of the services and their link to business outcomes Manage overall service provision

Service Portfolio Management Text p. 46 Service Portfolio Management CMDB

Service Portfolio Mgt Objectives Maintain a definitive portfolio of services provided by the service provider Provide an information source that allows the organization to understand and evaluate how the IT services provided enable them to achieve their desired outcomes. Provide control over which services are offered Track the organizational spend on IT services throughout their lifecycle Provide information to enable decision making regarding the viability of services and when they should be retired.

Service Catalog Management Text p. 98 Service Catalog Management

Service Catalog Management A service catalog is defined in the ITIL glossary as follows: “A database or structured document with information about all live IT services, including those available for deployment.” Customer facing services (deliverables, prices, ordering, contacts, request processes) Support services are not customer viewable, support services in place to insure delivery to the customer.

Service Catalog Management Text p. 100 Service Catalog Management A two-view service catalog

Service Catalog Management The purpose of the service catalog management process is to provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally and to ensure that it is readily available to those who are authorized to access it. The scope of the service catalog management process includes all services that are being transitioned or have been transitioned to the live environment.

Service Level Management Purpose: ensure that all current and planned IT services are delivered to agreed achievable targets. Covers current and planned services SLA – Service Level Agreement mandatory, common mistake: SLA coming after the go-live date Remember utility and warranty apply to the SLA Define and document services Develop targets and ensure they are measured and met Continually improve service levels Builds a good working relationship with business cust.

Service Level Requirements - SLR Represents what is required by the customer for a particular aspect of the service, and they are therefore based on business objectives . Relate primarily to warranty aspects of the service. SLRs are an essential element of the service design specification.

Service Level Agreement - SLA Describes the service and the quality measures by which the delivery of that service will be judged. Must be a written agreement and not an “MOU”. Should include components in two areas: services and management. Covers service hours and service availability Covers support and consequences of a breach of contract

Service Level Agreement - SLA See the sample SLA from:

SLA – Security as a Service, SaaS (not part of ITIL but a good example of a service – offered by Cisco, McAfee and others Constant virus definition updates that are not reliant on user compliance. Greater security expertise than is typically available within an organization. Faster user provisioning. Outsourcing of administrative tasks, such as log management, to save time and money and allow an organization to devote more time to its core competencies. A Web interface that allows in-house administration of some tasks as well as a view of the security environment and on-going activities. Internet-based security is sometimes referred to as cloud security

Operational Level Agreements Agreements between internal departments Includes support levels, technologies supported and not supported. No legal jargon needed – should fit on a single page Identifies management tools used Must be listed and available in the CMDB

Underpinning contract - UC UC is an agreement with external organizations that provide elements of the overall service. Unlike OLA, they are enforceable contracts Like OLA, monitoring and reporting is mandatory Every SLA must have an OLA and/or UC Example from Donut:

Service Relationships

Availability Management – have a plan! Def: the ability of an IT service or other configuration item to perform its agreed function when required. Downtime: An unplanned interruption of a service during its agreed service hours. Availability is 100% - the %age of downtime Example (page 103): 24/7 service is down for 1 hour. Calculate availability: Agreed – downtime/ Agreed x 100%

Calculating availability (page 103)

“Five nines” availability For a 24/7 operation, what it the total downtime per week? 100 – 99.999% = .001% Given that one week = 168 hours: Time = (x / 168) x 100% = .001% x = 6.048 sec per week for five 9s Or…. 6.048 sec x 4.33 weeks = 26.2 sec/month

Scope of Availability Management Encompasses ALL phases of the service lifecycle Requires a firm grasp of business processes VBF = “Vital Business Function” Appropriate availability targets must have a business case

Availability Management Process Figure on Page 107 Availability Management Process “Reactive” “Proactive”

More Availability Terms Reliability defined: “a measure of how long a service, component, or CI can perform its agreed function without interruption.” Measure reliability by calculating the mean (or average) time between failures (MTBF) or the mean (or average) time between service incidents (MTBSI). Resilience is obtained by having “fail-over” designs like redundant networks and clustered servers. Maintainability: Mean time to restore service (MTRS) = Total downtime in hr / total number of failures. Helped by having “hot spares”.

Expanded incident lifecycle Figure on p. 110 Expanded incident lifecycle

Serviceability Serviceability: The ability of a 3rd party supplier to meet the terms of its contract. Read bakery example on p 110. Better and true example: healthcare facility in OR, HP system mgt software running without fault for 13 months, crashed, required a certain German software developer to be on line to fix, 8hr time difference, caused many unnecessary but costly delays to restore with a software patch. Reliable but not very serviceable. Downtime=3 days!

SACM Service Asset and Configuration Management The ITIL v3 book on SACM provides direction on “Configuration Items, Definition of policies and procedures in Management and Planning, CI Identification and tracking, CI Control, CI Verification, and CI Auditing” which is good enough to be labeled as the old Configuration Management Difficult to apply to your organization but focus on the Foundation exam – use their definitions

SACM Purpose – be able to control assets that make up your services. Requires identifying them and keeping complete record of configs, inventory and versions Service assets are also known as CIs or “configuration items”. Not all assets are CIs. Yes, a virtual infrastructure (cloud) and virtual server are CIs. Scope is all CIs throughout their entire lifecycle

Service Asset & Config Mgt Purpose is to ensure you have accurate, meaningful and relevant info about your assets. Capture info about services you provide Manage integrity of the CIs (config items) that make up the service using a config mgt system Maintain historical, planned and current info on CIs. Use the info for trending (linear regression) Promotes accurate decision making by service providers

Service Asset & Config Mgt Key definitions Service Asset: Any resource or capability that could contribute to the delivery of a service. Configuration Item, CI: A service asset that needs to be managed in order to deliver an IT service Configuration Record: A set of attributes and relationships about a CI

Configuration Items Best list of descriptions and definitions on pp 190 – 191. All of them may be on the Foundation exam Which of the following statements is not part of the purpose of the SACM process? To control the assets that make up your services To manage the changes to your service assets To identify service assets To capture accurate information about service assets.

Configuration model - Bank Ans: B – is part of change management Figure on p 192 Configuration model - Bank

Consolidate all info into a single repository: Config Mgt System, CMS Figure on p. 193 Consolidate all info into a single repository: Config Mgt System, CMS Service Knowledge Mgt System SKMS holds all CIs that are part of the SACM. Service Desk has access.

Figure on p. 195 CMS Architecture

Definitive Media Library Definitive: includes EVERYTHING. Not everything is a CI like software licenses, cold spares, in-house software (mostly scripts – shell, perl, Java, XML and HTML, php. They will all be in the DML Physical spares and equipment should be in a secure store but listed in CMS documentation Policies that control the management of the DML will form party of the SKMS

Change Management ITIL refers to Change Management as a process. On the exam, you will be asked about activities, concepts and purpose of this process. Start with purpose: “to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.” ITSMF*: 80% of all incidents are caused by IT infrastructure changes. True? *ITSMF IT Service Management Forum

Change Management Objectives ITIL: “ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.” Keep abreast of changes that happen in the business environment Maintains control of the configuration management system (CMS) and insures data is current and relevant.

Change Management Scope ITIL definition of change: as “the addition, modification or removal of anything that could have an effect on IT services.” Scope is huge: architecture, infrastructure, processes documentation, metrics, tools, service changes and CIs. (Configuration Items). Exclude organizational and business changes. Exclude routine maintenance and repairs

Change, RFC and Change Record Change: “The addition, modification, or removal of anything that could have an effect on IT services.” Request for Change: “Formal proposal for altering a configuration item, recorded either electronically or on paper.” Change Record: “A capture of the details of the lifecycle of a change. Should reference the CIs associated with the change”

Change types Standard Change: Change to a service or CI. Typical example: moves/adds/changes for desktop users. Clearly defined and planned with low risk. Emergency Change: “response to or in order to prevent a business-critical error.” High risk, disruptive and prone to failure. Highly advised that there be a documented model for emergencies as part of the Service Design and SLA.

Change Advisory Board - CAB CAB: a group of people who are tasked with evaluating changes to the IT environment. The CAB ensures the right people with the right information, knowledge, and background are there to effectively review each change. Focused exclusively on reviewing Change Requests for risk and unintended consequences Should be staffed with representatives from all functional areas/technical disciplines, key decision makers, and business stakeholders. All changes are brought to the CAB for review

Normal change process model Text page 171 Normal change process model

Typical change management question 4. Which of these is part of the scope of IT change management? Business strategic changes Minor operational changes IT service changes Project changes

Answer to typical change management question 4. Which of these is part of the scope of IT change management? Business strategic changes Minor operational changes IT service changes Project changes C. Change management does not cover business, project or minor operational changes. The change process is used for IT service changes.

Event Management Event: “Any change of state that has significance for the management of a configuration item (CI) or IT service. Note that this does not state that the change of state is a failure.” Alert: “An event that notifies staff of a failure or that a threshold has been breached.” Incident: “An unplanned interruption to an IT service, a reduction in the quality of an IT service, or a failure of a CI that has not yet impacted an IT service (for example, failure of one disk from a mirror set).”

Event Management Trigger: An indication that some action or response to an event may be needed. Notification - the notification generated by the CI/system or a monitoring tool that indicates that an event has occurred on the CI/Service/System. (Know all five of these terms) ------------------------------------------------------- Purpose: “To detect events, understand what they mean, and take any necessary action.” Objectives: Detect all “changes of state that have significance for the management of a CI or service” Trigger an automated response

Event Management Objectives: (continued from previous slide) “Provide sufficient information to enable an accurate assessment of the performance of a service against the SLA target.” “Measure the success or failure of improvement actions.” Scope: “Applied to any aspects of service management that need to be controlled and that could benefit from being automated.”

Event Management Monitoring vs Managing: Event Management: “concerned with generating events and detecting notifications that have been produced.” Event Monitoring: “detects these notifications but goes further than this. Monitoring includes actively checking CIs to ensure that they are working as they should, whether or not an event has been generated.”

Event Management HP NNM

Event Management HP NNM

Service Management Incidents and Problems – Part of Service Operation

Service Management Incidents and Problems

Service Management Incidents and Problems Incident: “An unplanned interruption to an IT service, a reduction in the quality of an IT service, or a failure of a CI that has not yet impacted an IT service (for example, failure of one disk from a mirror set).” (Look familiar?) Problem: “An underlying cause of one or more incidents.” Problem Management: “process that investigates the cause of incidents and , wherever possible, implements a permanent solution to prevent recurrence.”

Service Management Incidents and Problems Purpose of Incident Mgt: restore normal service operation as quickly as possible and minimize the adverse impact on business operations. Objectives of Incident Mgt: “to ensure that all incidents are efficiently responded to, analyzed, logged, managed, resolved, and reported upon.” The scope of Incident Mgt: All incidents

Service Management Incidents and Problems Problem: “An underlying cause of one or more incidents.” Problem Mgt: “Is the process that investigates the cause of incidents and , wherever possible, implements a permanent solution to prevent recurrence.” Purpose of Problem Mgt: “Document, investigate, and remove causes of incidents.” Problem mgt aims to identify the root cause of problems

Service Management Incidents and Problems Scope of Problem Mgt: “includes diagnosis of the root cause of incidents and taking the necessary action in conjunction with other processes (such as change management and release and deployment management) to permanently remove them.” Tools should link incidents to specific problem records in the Knowledge Database Incidents – Reactive, Problems – Reactive and Proactive

Service Management Incidents and Problems Links between Problem Mgt and Lifecycle Stages: Service strategy financial management process, the cost of down time and support services Service design processes of availability management, capacity management, and IT service continuity management all take proactive steps to identify possible issues and deal with these problems before they result in incidents. Service Transition: Change Management when a change is required to resolve a problem, Service Asset and Config Mgt (SACM) when identifying faulty CIs, Release and Deployment Mgt when a change to resolve a fault is approved by Change Management, Knowledge Management when holding problem histories in the Known Error Database (KEDB).

Review: Incident vs Problem Incidents and Service Requests are formally managed through a staged process to conclusion. This process is referred to as the "Incident Management Lifecycle". The objective of the Incident Management Lifecycle is to restore the service as quickly as possible to meet Service Level Agreements. The process is primarily aimed at the user level. Problem Management deals with resolving the underlying cause of one or more Incidents. The focus of Problem Management is to resolve the root cause of errors and to find permanent solutions. Although every effort will be made to resolve the problem as quickly as possible this process is focused on the resolution of the problem rather than the speed of the resolution. This process deals at the enterprise level.

Incident mgt sample question What is the objective of Incident management? A. to annoy users B. keep track of difficult users so that the IT organization can take measures to bring them into line C. to provide a place where users can quite rightly complain about the atrocious levels of service they receive from us D. A, B, and C

Managing incidents should not be putting out fires Previous slides: just checking to see if you were awake  Managing incidents should not be putting out fires

Managing incidents – ITIL 9-steps See page 244, text for flow chart Managing incidents – ITIL 9-steps Step 1: Incident Identification Step 2: Incident logging – create incident record database Step 3: Incident Categorization

Managing incidents – ITIL 9-steps Step 4: Incident Prioritization – business impact and urgency Step 5: Initial Diagnosis – use Known Error Database – try Incident Matching Step 6: Incident Escalation (service desk still owns the incident) Functional escalation: service desk is unable to resolve the incident Hierarchic escalation: move up to a higher management level

Managing incidents – ITIL 9-steps Step 7: Investigation and Diagnosis Full description of the issue Impact and urgency Timeline Identify possible causes Mine the Knowledge Database (HP Kmine) Step 8: Resolution and Recovery Step 9: Incident closure

Managing Problems – ITIL 7 steps Step 1: Detecting problems Step 2: Logging problems Step 3: Categorizing problems Step 4: Prioritizing problems Step 5: Investigating and Diagnosing Problems Step 6: Identifying a workaround Step 7: Raising a Know Error Record, Known Error Database (KEDB)

Service Design

Service Design

Service Design Purpose: to deliver a new service or a change to an existing service that is capable of delivering the strategic outcome required. Objective: aim to deliver a service that will require very little improvement later. Scope: see previous slide or see the next slide:

Service Design Scope Design coordination Service catalog management Service level management Availability management Capacity management IT service continuity management Information security management Supplier management

Service Design value to the business #1: Lower cost of ownership across the service lifecycle. #2: Insure that the service is aligned with the business #3: SDP or Service Design Package insures a smooth transition from design to live #4: Includes metrics and controls for good governance #5: Includes strategic requirements of the business

Service Design – The SDP, Service Design Package Text p. 65 Service Design – The SDP, Service Design Package Original agreed business requirements for the service How the service will be used Key contacts and stakeholders Functional requirements Management requirements Service level requirements Technical design of the new or changed service including hardware, software, networks, environments, data, applications, technology, tools, and documentation Sourcing strategy New or changed processes required to support the service

Service Design – The SDP, Service Design Package Organizational readiness assessment Service lifecycle plan, including the timescales and phasing, for the transition, operation, and subsequent improvement of the new service Service program, service transition plan Service operational acceptance plan Service acceptance criteria (SAC)

People Processes Products Partners Service Design 4 Ps Both a resource and capability Will the new service require training? Processes Will new processes need to be created? Products Software and Hardware Partners In-house or 3rd party

Service Design – Building the Service Text p. 67 Service Design – Building the Service

Service Design What are the parts of a service? The business processes that the IT service will support. Fulfills all the utility requirements Abide by any governance or reporting requirements and ensuring the service is in line with the organization’s strategic goals. Service level requirements and service level agreements (OLAs too) The technical components of the service, using the configuration management system, CMS, to show how these are linked to provide the service. Applications that will provide the functional requirements of the business process. Other services that support the new or changed service.

Five Key Aspects of Service Design “STAMP”: Service solutions Tools and systems for management information Architectures Measurement systems Processes

Service Design Constraints Text p. 69 Service Design Constraints

Service Strategy Use this chart to help you study for the Foundation Exam. You will find it on my website: “Good ITIL Cheatsheet Circular Chart”

Service Strategy “ITIL service strategy specifically defines how a service provider will use (i.e. plan to use) IT services to achieve the business outcomes of its customers, thereby enabling the service provider (whether internal or external) to meed its objectiv es (of providing value to the customer).”

Service Strategy and Service Portfolio

Service Strategy – getting there Purpose and objectives Understand the IT strategy Identify customers and services Define value and delivery Discover service opportunities Deliver a service provisioning model Discover IT capabilities required to deliver Understand levels of demand Understand customer relationships

Service Strategy - Scope IT service strategy documentation covers: Defining a strategy that gives a service provider guidance and recommendations about delivering services to meet a customer’s business outcomes Defining a strategy for managing those services

Service Strategy - Value The ability to link the activities carried out by the service provider to the business-critical outcomes that are required by internal or external customers. The ability to understand the type and levels of service that will support the customers The ability to respond to business change Guidance for creating and maintaining a service portfolio The ability to understand how to organize so that the required services can be delivered in an effective and efficient manner.

Service Strategy – Demonstrating Value Value is determined by customers – they must see value as greater than the cost of purchasing the service. Understatement: “If IT is perceived only as managing the infrastructure equipment (servers, networks, PCs, and so on), then the customer’s perception of value will be difficult to associate to business outcomes and activities.”

Utility and Warranty – know the definitions for the exam

Last slide – Deming Cycle Text, p. 292 Last slide – Deming Cycle “PDCA”, Plan, Do, Check, Act as part of The cycle of continuous improvement