foundations of the foundationsitil® v3/2011 foundation study guide 3 o complementary framework...

ITIL® v3/2011 Foundation Study Guide

https://www.DionTraining.com 1

Foundations of the Foundations

● Exam Fundamentals o ITIL Foundation Certification

▪ Entry-level certification for ITIL ▪ Covers a general awareness of the elements, concepts, and terminology

used in the ITIL Service Lifecycle

o Certification Target Audience

▪ People requiring an understanding of the ITIL framework ▪ People needing an understanding of how ITIL can enhance IT service

management within an organization ▪ IT professionals in organizations that adopted ITIL and need to

understand ongoing service improvement o Format of the Exam

▪ 40 multiple-choice questions ▪ 60 minutes to complete ▪ Passing Score: 65% (26 out of 40) ▪ Closed book exam

● ITSM and ITIL

o IT Service Management (ITSM) ▪ Complete set of activities required to provide service to an organization,

including policies and strategies to: ● Plan ● Design ● Deliver ● Operate ● Control



o What Is A Customer? ▪ People to whom you sell service ▪ Your employees

o IT Infrastructure Library (ITIL) ▪ Developed as a framework for organizations to use in order to perform

ITSM

o Are there other frameworks? ▪ Control Objectives for Information and Related Technology (COBIT) ▪ ISO/IEC 20000 framework



o Complementary Framework ▪ Shares many of the same processes, functions, and lifecycle steps as ITIL

o ITIL Framework ▪ Only framework that is covered by the ITIL Foundations exam

● What Does ITIL Provide

o ITIL Provides: ▪ Guidance for IT Service Management ▪ Flexibility ▪ Comprehensive framework ▪ Compilation of best practices ▪ Vendor-neutral framework ▪ Large amount of solutions to select

o ITIL Is NOT: ▪ A standard ▪ A regulation or compulsory actions ▪ A product or something you buy ▪ A substitute for vision, leadership, or management

o The Bottom Line ▪ ITIL is a framework to make service management more efficient and

effective

● Best Practices o Best Practices

▪ Proven activities or processes that have been successfully used by many different organizations in a specific industry

o The Sources of Best Practices ▪ Standards

● International standards represent in-depth drafting, scrutiny, and peer-review

● ISO/IEC 20000 ▪ Industry Practices

● Be mindful that some industries don’t translate well to yours ● If you are a high-tech firm, does a manufacturing plant’s best

practices fit in your organization? ▪ Academic Research

● Provides the latest business research and theory ● Caution – academic research doesn’t always translate to practical

application



▪ Training and Education ● Reading, studying, and course discussions can bring new ideas and

best practices to light for employees ▪ Internal Experience

● Potentially valuable ● Can be misinformed, subjective, and myopic ● Take it with a grain of salt…

o The Enablers of Best Practices ▪ Employees

● Automation is great, but we still need people to run it ▪ Customers

● Who will benefit from our using the ITIL framework in ITSM? ● Customers enable our application of best practices

▪ Suppliers ● If you outsource, your suppliers must enable your vision for

implementation of ITIL in the organization ▪ Advisors

● To implement ITIL, you need guidance from your own research and education, or from outside advisors and consultants

▪ Technology ● Many software tools available ● Tools are helpful, but they don’t work without clearly defined and

documented processes ● Tools can enable ITIL, after processes are created

o Bottom Line on Best Practices ▪ Sources and Enablers allow the organization to fully understand and

implement effective best practices

● Essential Definitions o Business

▪ Meets the need of the customer ▪ Could be a private (commercial) or public-sector (governmental)

o Ownership ▪ Assignment of an individual or group empowered to exercise

accountability for a specific configuration item ▪ Importance of ownership:

● Any process, application, service, or equipment not “owned” will be neglected or forgotten



o Service ▪ Means of delivering value to customers by facilitating the outcomes

customers want to achieve without the ownership of specific costs and risk

o Outcome ▪ Result of carrying out an activity, following a process, or delivering an IT

service ▪ Outcomes can be the intended results or the actual results

o IT Service Management (ITSM) ▪ Implementation and management of quality IT services that meet the

needs of the business ▪ Performed by IT service providers through the proper mix of people,

process, and information technology o Service Providers

▪ Provide IT services to internal or external customers ▪ Broken down into three types

● Type I – Internal service provider embedded within the business unit it serves

● Type II – Internal service provider who services more than one business unit (also called a Shared Service Unit)

● Type III – Provides service to external customers o Stakeholders

▪ Person with an interest or concern in the service provided ▪ Broken down into three types

● Customer – People or organizations that commission or pay for the services provided

● Users – People who have their business activities supported by the IT services provided

● Suppliers – Third-party (Type III) service provider (i.e. outsourced) o Process

▪ Set of coordinated activities combining resources and capability to produce an outcome that creates value for the customer

▪ ITIL covers 27 distinct processes ▪ Only 22 processes are covered in the Foundations exam, though

o Process Characteristics ▪ 1. Responds to a specific event (called a trigger) ▪ 2. Measurable with metrics like performance, cost, productivity, quality,

and duration ▪ 3. Produces specific result ▪ 4. Delivers a result to a defined customer to meet expectations



o Function ▪ Unit of organization specialized to perform certain types of work and

responsible for specific outcomes ▪ Functions actually perform the activities of processes

o Roles ▪ Position, responsibility, or duty within a process or function ▪ Four Basic Roles

● Service Owner ● Process Owner ● Process Manager ● Process Practitioner

o Service Owner ▪ Can own more than one service ▪ Performs the following

● Initiation, transition, and maintaining of the service ● Ensures service delivery is met ● Identifies service improvements ● Liaisons with Process Owners ● Reporting and monitoring ● Accountability for delivering the service

o Process Owner ▪ Can own more than one process ▪ Performs the following

● Initiation, transition, and maintaining of the process ● Defines process strategy and policy ● Assists in process design ● Ensures process is documented ● Audits the process for efficiency ● Communicates the process to others ● Provisions resources and training ● Gives input into service improvement

o Process Manager ▪ Performs the following

● Plans and coordinates activities ● Ensures activities are carried out ● Appoints people to required roles ● Manages process resources ● Ensures smooth running of services ● Monitors and reports on process performance ● Identifies possible improvements ● Helps prioritize improvements



● Implements process improvements o Process Practitioner

▪ Performs the work in the process ▪ Performs the following

● Carries out one or more activities in the process ● Works with stakeholders to ensure process is effective ● Verifies inputs, outputs, and interfaces for activities are correct ● Creates or updates records for activities carried out

o Exam Tips ▪ 1. You don’t need to memorize the definitions word for word, but you

must recognize the right one ▪ 2. Know generic process model and process characteristics ▪ 3. Be able to differentiate between service, process, and function ▪ 4. If you get asked about service owner or process owner, verify your

answer matches the question asked ● If a question asks about a process, think twice before selecting an

ANSWER with SERVICE in it!

● Governance Control o Leadership, Management, and Vision

▪ No matter how good your service or process design is, without these, they are a waste of time

▪ How do you decide which “squeaky wheel gets the grease”? o Governance Control

▪ Ensures fairness and transparency ▪ Business needs determine resource allocation based on governance ▪ Focuses on conformity and compliance ▪ Ensures compliance with legislative requirements

● Sarbanes-Oxley ● HIPAA ● FERPA

▪ Goal is to meet audit requirements and to use resources to maximize the creation of value to the business

● Organizational Structure in ITIL

o Organizational Structure ▪ ITIL doesn’t provide a model for organizational structure ▪ Instead, it provides useful guidance ▪ Each volume of the ITIL books has “Organizing for _______________” for

the 6th chapter ▪ Chapter 6 always contains numerous roles and responsibilities



o Who is responsible for what? ▪ Roles can be filled by multiple people ▪ One person can fill many roles ▪ If many people are filling a role, ensure there are no gaps or seams ▪ Ensure all roles are filled by someone

o RACI Matrix ▪ Responsible ▪ Accountable ▪ Consulted ▪ Informed

▪ Each activity can have many roles who are responsible, consulted, and informed

▪ Each activity can only have one role who is accountable, though! ▪ RACI provides the linkages between roles, their responsibility, and

accountability for a given task

● Risk o What is Risk?

▪ “Uncertainty of outcome” ▪ Outcome could be better or worse than expected, but that is where the

risk lies o What can I do with risk?

▪ Identify ● Essential at beginning of design

▪ Analyze ● Study the risk, understand the risk, consider way ahead

▪ Manage ● Accept ● Avoid ● Mitigate ● Transfer



● Toolsets in ITIL o Tools and Technology

▪ These are wonderfully useful…if you have fundamentals right ▪ If you have a bad process or function, tools will allow you to do more of it

and faster ▪ Processes, functions, roles, and responsibilities are key to setting up the

tools properly for efficiency



The Service Lifecycle

● The Service Lifecycle o Lifecycles

▪ Most management books have some sort of “lifecycle” ▪ Many aren’t actually very relevant…but, the Service Lifecycle is!

o Service Lifecycle ▪ Service Strategy ▪ Service Design ▪ Service Transition ▪ Service Operation ▪ Continual Service Improvement



● Overview of Processes & Phases



Service Strategy

● Service Strategy (Overview) o Service Strategy

▪ Broad concept of our service solution ▪ What business are you in? ▪ Will we outsource services? ▪ Is our service complex or simple? ▪ Who are our customers?

o Clarity is Key ▪ Clear business strategy leads to a good IT service strategy ▪ What IT services can you provide to support the business strategy?

o Reminder: Service Definition ▪ Means of providing value to customers by facilitating the outcomes they

want to achieve without the ownership of specific costs and risks o Key Activities

▪ Define your services ▪ Link them to business processes ▪ Assign resources ▪ Consider costs and risks ▪ Outline service specification based on a valid business case

● Objectives of Service Strategy

o Objectives of Service Strategy ▪ Run the strategy processes ▪ Define the strategy ▪ Define services and their customers ▪ Define value creation and delivery ▪ Define required capabilities/resources ▪ Identify possible service opportunities

o Types of Service Providers ▪ Type I

● Internal service provider embedded inside of another unit of the organization

▪ Type II ● Internal service provider shared amongst multiple units

▪ Type III ● Provides service to external customers



o Types of Service Categories ▪ Core Services

● Deliver the basic outcomes required by one or many customers ▪ Enabling Services

● Necessary services to deliver core services ▪ Enhancing Services

● Supplements to core services to make them more attractive or useful to customers

o Word Processing “Service” Example ▪ Core Services

● Microsoft Word provides word processing capabilities as part of Microsoft Office

▪ Enabling Services ● Updates and security patches to Microsoft Word

▪ Enhancing Services ● Ability to integrate Microsoft Word into the larger Microsoft

Office suite or products ● Ability to save files to the “cloud”

● Creating Value

o How do we create value? o Creating Value

▪ Value is created from the balance between utility and warranty o Utility

▪ Functionality of a service ▪ Fit for purpose ▪ Enabling a job to be done or to be done better

o Warranty ▪ Fit for use ▪ Mix of availability, capacity, continuity, and security

o Maximum Value ▪ Perfect balance provides maximum value ▪ But, neither piece is more important



o Poor Value ▪ High Utility: Best website ▪ Low Warranty: Limited bandwidth

▪ Low Utility: Poorly designed database ▪ High Warranty: 100% Availability

o Value in Service Strategy ▪ Always try to understand the utility and warranty of any new or changed

service ▪ Utility “sells” services ▪ Warranty requires resources and, therefore, represents additional costs

o Cyclic Nature of Value ▪ Value is revisited in each stage of the lifecycle through utility and

warranty ▪ Stay on track to deliver the expected value to the operational

environment

● Assets in Service Strategy o What exactly are your assets? o Types of Assets

▪ Resources ● Tangible, can be purchased



● Financial capital, Infrastructure, Applications, Information, and People

▪ Capabilities ● Must be grown or developed ● Management, Organization, Processes, Knowledge, and People

o Financial Capital ▪ Money ready for investment ▪ Can be heavy cash position or the ability to borrow

o Infrastructure ▪ Buildings ▪ Server rooms ▪ Hardware ▪ HVAC ▪ UPS

o Applications ▪ Off-the-shelf software

● Office suites, web portals, etc. ▪ Custom software

● In-house or outsourced developed software which you own exclusive rights

o Information ▪ Massive amounts of data ▪ Email lists ▪ Customer spending habits

o People ▪ Labor is a commodity that can be procured quickly to accomplish tasks ▪ Even skilled labor can be acquired quickly using head hunters

o Management ▪ Fusion of other capabilities ▪ Difficult to find good management that understands your business

processes and methods o Organization

▪ Many organizational methods exist, but yours must be developed ▪ ITIL provides guidance for organization, not a blueprint to follow

o Processes ▪ Like organization, yours must be developed ▪ Tools exist within IT Service Management to manage processes, but you

should develop your process before purchasing one o Knowledge

▪ Synthesis of data and the information it creates



▪ Knowledge Management helps your organization move from tacit to explicit knowledge

o People ▪ Motivated, Trained, and experienced workforce ▪ Consultants can bridge temporary skill gaps ▪ Your people should perform the long-term process and functions

o Key Takeaway ▪ Resources

● Tangible in nature ● You can purchase resources ● Easier to get than capabilities

▪ Capabilities ● Intangibles and abstract in nature ● Must be fostered and nurtured to develop in a business ● Difficult, costly, and requires time to acquire

● Strategy Management Process

o Strategy Management ▪ This process is to ensure a service strategy is defined, maintained, and

managed ▪ Note: Strategy Management process is not covered by the ITIL Foundation

exam o Key Activities

▪ Examining current internal and external environments ▪ Identifying strengths, weaknesses, opportunities, and threats (called a

SWOT analysis) ▪ Identifying future developments ▪ Developing and maintaining the marketing perspective ▪ Defining market spaces ▪ Identifying opportunities for new services for development ▪ Defining differentiation of service provider from others ▪ Developing and maintaining a strategic plan ▪ Managing the Service Strategy stage of the lifecycle

o Strategy Management ▪ This process is not covered by the ITIL Foundation exam, but is important

to fully understand the lifecycle

● Service Portfolio Management Process o Service Portfolio Management (MGMT)

▪ Ensures a correct mixture of services to balance IT investment to support the business objectives



o Service Pipeline

▪ Information on all services from concept to operations ▪ Restricted visibility to those who have a need-to-know

o Service Catalog ▪ Information on all services in operational environment and those being

prepared for rollout (resources allocated) ▪ Customers can view info

o Retired Services ▪ ITIL doesn’t state when services are retired ▪ Many organizations keep them in the service catalog for reference ▪ Other organizations choose to delete their retired services from the

catalog ▪ Resources are released



o Service Portfolio Management (MGMT) ▪ Process begins in Service Strategy, but we will see it in every stage of the

lifecycle since resources are allocated throughout the lifecycle of every service

o Who allocates resources, anyway? ▪ Resources are allocated to resources throughout their lifecycle from the

IT director’s resource pool ▪ Services will usually use more resource in Operations than in earlier

stages

● Business Relationship Management Process o Purpose of Business Relationship Management (BRM)

▪ Establish/maintain business relationship between service provider and customer

▪ Identify customer needs and ensure service provider can meet the needs o Mitigating Needs

▪ Understand, inform, and meet customer’s perceived needs ▪ Communicate needs inside the service provider’s organization

o Identifying Trends ▪ Identify technology trends that could impact the services to a particular

customer o Identifying Changes

▪ Identify changes in a customer’s environment ▪ There could be a shifting business model… and the service provider must

move with them! o Mediation

▪ Mediate requirements when multiple customers need different things from the service

o Complaint Methods ▪ Create formal complaint methods and procedures for each customer ▪ Ensure you consider the escalation process

o Internal/External Providers ▪ Type I/Type II

● BRM involves senior IT managers with heads of business units ▪ Type III

● BRM involves account managers to maintain commercial relationships

● Financial Management Process o Financial Management

▪ Relevant in all stages, but introduced first in Strategy



▪ Purpose is to manage financial resources and costs for services o Purpose

▪ Secure funding to design, develop, and deliver services to support business processes

▪ Ensure service provider doesn’t promise what they cannot deliver ▪ Maintain balance of cost and quality; supply and demand

o Financial Management Fundamentals ▪ Budgeting

● Forecasting of cost to support ongoing and proposed services ● Link requirements to agreed-upon business processes

▪ Accounting ● Money is divided into cost centers to keep track of expenditures

for business units or services ● Each expense is tracked against the cost center and back to the

original budget ▪ Charging

● Charging isn’t mandatory ● Type I/II may not conduct charging (but some organizations do) ● Type III always charge (it is how we create profit)

o Business Case ▪ Argues the benefits and costs of a particular service ▪ Created for new or changing services ▪ Provides an expected Return on Investment (ROI)

o Parts of a Business Case ▪ Introduction

● Short summary of business issues driving the change ● Provides background to leadership ● Contains a statement of objectives

▪ Methods and Assumptions ● Describes the method used in the business case ● Assumptions state the growth projections, technological advances

expected, socioeconomic conditions, etc. ▪ Business Impacts

● Return on Investment (ROI) o Expected financial growth

● Value of Investment (VOI) o Expected non-financial return, such as an increase in

reputation ● Utility and Warranty drive business impact

▪ Risks and Contingencies ● Details the uncertainties identified during previous analysis



● Proposes a countermeasure or mitigation for each identified risk ▪ Recommendations

● Provides conclusions based on the business case ● Provides proposal for future action with alternatives also

presented with their cost

● Demand Management Process o Demand Management

▪ The purpose of the process is to identify the demand for a particular service to prevent capacity limitations

▪ Note: Demand Management process is not covered by the ITIL Foundation exam

o Key Activities ▪ Identify and analyze patterns of business activity (PBA) ▪ Analyze usage of services by different types of users and

identify/document user profiles o Important Considerations

▪ Businesses have busy and slow periods ▪ Retailers are busier during the holiday season ▪ Many companies don’t account for large demand

o Demand Management ▪ This process is not covered by the ITIL Foundation exam, but is important

to fully understand the lifecycle

● Roles in Service Strategy o Roles in Service Strategy

▪ ITIL doesn’t dictate how an organization should be organized ▪ ITIL does recommend these roles:

● Service Owner ● Process Owner ● Process Manager



● Tools in Service Strategy o Tools in Service Strategy

▪ Tools don’t only have to be used in the Service Desk ▪ Service Automation/Analytics and Simulation are useful in the Service

Strategy stage o Service Automation and Analytics

▪ Enables consistency and higher efficiency ▪ Captures accurate data for management and to make informed strategic

decisions ▪ Maximum automation = efficiency

o Simulation ▪ Provides a method to model a potential service solution and analyze the

results ▪ Results can be used in a business case



Service Design

● Service Design (Overview) o Service Design

▪ Conduct the detailed service planning ▪ How will it be supported? ▪ How will it be tested? ▪ How will future development occur?

o When is Service Design Complete? ▪ Service Design is complete when:

● Detailed ● Comprehensive ● Effective (but not necessarily efficient) ● Agreed upon by stakeholders

o Key Takeaways ▪ Detailed blueprint of the service, including:

● Components of the service ● Identify if resources can be shared with another existing service ● Test plan ● Support plan ● Future development plan

● Objectives of Service Design

o Overall Objective of Service Design ▪ To provide guidance on the design and development of both the services

and the service management practices ▪ To ensure the services meet the current and future needs of the business

o Objectives of Service Design ▪ Coordinate Design Activities ▪ Policies and Standards ▪ Process Quality Control ▪ Forward-Compatible Design ▪ Plans ▪ Costs ▪ Service Management System ▪ Security and Resilience ▪ Efficiency of Effort ▪ Skills and Capabilities



o Coordinate Design Activities ▪ Use the required resources as efficiently and effectively as possible

during Service Design o Policies and Standards

▪ Produce policies that are subordinate to those created during the Service Strategy stage

▪ Policies should be developed alongside the existing local policies in the organization

o Process Quality Control ▪ Assess the effectiveness and efficiency of the 8 design processes:

● Design Coordination Process ● Service Catalog Management Process ● Service Level Management Process ● Capacity Management ● Availability Management ● IT Service Continuity Management ● Information Security Management Process ● Supplier Management Process

o Forward-Compatible Design ▪ Ensure new or changed services may be developed or improved in the

future easily and within the given timeframes o Plans

▪ Produce or maintain plans, processes, architectures, infrastructures, frameworks, and documents for IT service design

o Costs ▪ Control the long-term costs associated with service provisioning by

reducing, minimizing, or eliminating as much of the costs as possible o Service Management System

▪ Design an efficient and effective method to manage a given service o Security and Resilience

▪ Design IT infrastructures that are secure and resilient ▪ This is difficult to fully achieve, since there are always tradeoffs

o Efficiency of Effort ▪ Reduce the requirements for rework in a given service ▪ Reduce the requirements for urgent or interim upgrades to a given

service o Skills and Capabilities

▪ Develop the skills and capabilities required of the personnel involved in the service

▪ Develop the functions and processes of the service provider



● “Complete” Service Design o “Complete” Service Design

▪ It is important to consider the service holistically during Service Design ▪ Each of the 5 parts of Service Design must be addressed to design an

efficient and effective service o Five Parts of Service Design

▪ Service Solutions ▪ Management Information Systems and Tools ▪ Technology Architecture and Management Architecture ▪ Processes ▪ Measurement Methods and Metrics

o Service Solutions ▪ New or changed services being designed using a structured and formal

design approach ▪ Incorporates flexibility to support future improvements and changes

o Management Information Systems and Tools ▪ Consists of:

● Service Portfolio ● Service Knowledge Management System (SKMS) ● Configuration Management System (CMS)

▪ These tools are designed during the Service Design phase using a structured and formal method, but they are used throughout the entire lifecycle

o Technology Architectures and Management Architectures ▪ Technical aspect of IT infrastructure, its components, and their

relationship amongst each other ▪ Align the management structure with the existing business processes ▪ Remember that business needs to come first, not a particular technology

o The ITIL Processes ▪ All 26 processes in the ITIL framework must be designed to function

properly ▪ All 26 processes are designed during the Service Design phase

o Measurement Methods and Metrics ▪ Designers should develop the list of metrics and things to be measured

during the System Design phase ● What are we going to measure? ● How are we going to measure it? ● How often are we going to measure?



● 4 P’s of Service Design o 4 P’s of Service Design

▪ People ▪ Processes ▪ Products ▪ Partners

o People ▪ Consists of our technical staff, users, customers, stakeholders, board

executives, and many others ▪ People need to be trained, managed, supervised, led, hired, fired,

convinced, etc… o Processes

▪ ITIL is all about processes ▪ 26 processes in ITIL Framework ▪ Service Design considers all of the processes while designing a service

o Products Consist of… ▪ Services ▪ Technology (hardware, software, etc…) ▪ Tools

o Partners ▪ People and organizations that help us provide excellent services ▪ Manufacturers ▪ Suppliers ▪ Vendors ▪ Etc…

● Service Design Packages

o Service Design Package (SDP) ▪ Key output of Service Design phase ▪ Part of the formal migration from Service Design to Service Transition ▪ Blueprint to guide Service Transition ▪ Detailed requirements and plans for operating the new/changed service

and to provide for continual improvement o SDP in Service Retirement

▪ Service Design Package is also used for service retirement ▪ Verifies there are no outstanding dependencies on that service ▪ Verifies the resources used by the service are not shared by others ▪ Example:

● Is someone else using the server, too?



o Parts of the SDP ▪ Business Requirements ▪ Functional Requirements ▪ Operational Requirements ▪ Service Level Requirements ▪ Design Topology ▪ Organizational Readiness Assessment ▪ Service Transition Plan ▪ Acceptance Criteria ▪ Service Program

o Business Requirements ▪ Clearly documented in the Service Strategy (Clarity is key) ▪ Developed in Service Design ▪ If changes are made in Service Design to the original requirements, they

must go through the Change Management process o Functional Requirements

▪ Concerned with utility of the service ● Fit for purpose

▪ Developed from business requirements ▪ Any changes to functional requirements must be approved through your

organizational processes o Operational Requirements

▪ Concerned with warranty of the service ● Fit for use

▪ Consists of: ● Capacity ● Security ● Availability ● Service continuity ● Help desk support ● Etc…

o Service Level Requirements ▪ Details the desired level of warranty ▪ Used to negotiate Service Level Agreements (SLAs) to specific quality and

service targets to achieve ▪ Service level requirements are developed with the customer, and put in

SDP to document the agreements o Design Topology

▪ Contains: ● Definition of the service



● Hardware, software, applications, tools, networks, and other components of the service

● All relevant documentation ● Processes, metrics and measurements, and reports ● Supporting services and products

o Organizational Readiness Assessment ▪ Builds upon business, functional, and operational requirements ▪ Determines the ability of your organization to adequately support the

service through: ● Finance ● Technology ● Resources ● Skill sets of employees or providers ● Capability of a supplier

o Service Transition Plan ▪ Details how to build, test, and deploy a new or changed service ▪ You should use the organization’s agreed upon Service Transition policies ▪ If new ones need to be made to support the transition, then they should

be documented inside the SDP o Acceptance Criteria

▪ Details the criteria that determines when a new or changed service is considered successful

▪ Note: ● There are experts in the Service Transition phase who conduct the

testing but they need to know what they should test o Service Program

▪ Draws together all parts of the SDP ▪ Provides phasing and timelines for the Transition, Operations, and

Continual Service Improvement phases of a new or changed service o Service Design Package (SDP)

▪ Formally accepted SDP is required before a service moves from the Design to Transition phase

▪ If you need to write an SDP, use Appendix A of the ITIL Service Design manual which provides detailed specifications for each and every section of the SDP

● Design Coordination Process

o Purpose ▪ Ensures the objectives of the Service Design phase are met by providing

and maintaining a single point of coordination and control for all processes and activities in this phase



▪ Similar to Strategy Management in Service Strategy phase but for Service Design phase

o Key Activities ▪ Monitor activities for consistency ▪ Ensure SDPs conform to standards ▪ Manage migration of new, changed, or retired services to Service

Transition ▪ Ensure design conforms to strategic, governance, and architectural needs ▪ Improve processes through coordination with process owners ▪ Review, measure, and improve processes and activities ▪ Create and maintain framework for activities ▪ Guide and support new or changed services ▪ Maintain policies, standards, models, guidelines, budgets, resources, and

capabilities ▪ Plan, forecast, coordinate, prioritize, and schedule all resources used ▪ Ensures that utility and warranty requirements are addressed with all

other requirements levied o Design Coordinator’s Challenges

▪ Must resolve conflicting demands for shared resources ▪ Must ensure SDPs are accurate, consistent, and fully documented ▪ Must produce new or changed services that meet the customer’s

expectations

● Service Catalog MGMT Process o What does a Service Catalog do?

▪ Creates a list and definition of services ▪ Enables all stakeholders to have a clear understanding of the services

being provided to support the business o Definition

▪ A database or structured document with information about all live services including those available for deployment

o Purpose ▪ Provides a single source of consistent information on all live services and

those being prepared to go live and to ensure that it is widely available to those who are approved to access it

o Key Activities ▪ Manage the structure and contents of the catalog ▪ Ensure catalog is complete, accurate, and current ▪ Check and authorize any proposed changes to the catalog ▪ Ensure those who need access can see it ▪ Ensure those who don’t need access cannot see it



▪ Service catalog should be widely accessible unless there is a valid organizational reason to restrict access

o Other Things to Think About ▪ Developing and maintaining service descriptions

● Be brief and concise (200 words or less) ● Speak to a service not to an application ● Example:

o Email, not Microsoft Outlook ▪ Use plain language that users know ▪ Technical platform

● How will catalog be shared and viewed? o Relationships and the Catalog

▪ Configuration Management System (CMS) will have a close relationship ● Service Catalog provides overview and lists important features ● CMS contains detailed information on the components of each

service ● Service Catalog could even be derived from the CMS database (if

needed) o What’s Next?

▪ Different Types of Service Catalogs ● Simple Service Catalog ● Business or Customer ● Technical or Supporting ● Alternate Views

● Types of Service Catalogs

o Service Catalog Benefits ▪ Helps identify services that can be bundled to provide a better solution ▪ Informs customers of services available ▪ Helps service staff understand their part in the business process ▪ Manages customer’s expectations concerning services to be rolled out ▪ Defines communication paths between customers and service providers ▪ Publishes key SLA targets ▪ Key part of “Service Solutions” in holistic Service Design

o Simple Service Catalog ▪ Simplified matrix of available services ▪ Comprehensive and accurate info



o Business or Customer Service Catalog ▪ Identifies the business processes that are being supported by the services ▪ Detailed versions can include service hours, SLA info, escalation paths,

etc.

o Technical or Supporting Service Catalog ▪ Another level of depth, covering infrastructure, applications, and

outsourced services

o Alternate Views: Three-View



● Service Level MGMT Process o Purpose

▪ Service Level Management (SLM) ensures all current and planned IT services are delivered to agreed-upon, achievable targets

o Service Level Management ▪ What metrics are we collecting and comparing our performance to? ▪ What utility and warranty did you promise to your customers? ▪ Are your targets achievable and measurable? ▪ Are the targets relevant?

o Key Factors

▪ Ensure SLM and BRM are aligned ▪ Negotiation is key! ▪ Monitor, report, and review SLA targets

o Three Key SLM Documents ▪ Service Level Agreement (SLA) ▪ Operational Level Agreement (OLA) ▪ Underpinning Contract (UC)

o Service Level Agreement (SLA) ▪ Written agreement between IT service provider and customer providing

the key service targets and responsibilities of both parties ▪ Formal document but not necessarily a written contract ▪ Contains clear, concise language and both parties agree on the contents

o Operational Level Agreement (OLA) ▪ Underpinning written agreement between two elements of the service

provider organization regarding key service targets and responsibilities of both parties for the services being supported



▪ Like an SLA but only for use within the service provider’s own organization

o Underpinning Contract (UC) ▪ Legally binding agreement that conforms to contract law and

organizational contract policy ▪ Written in “legalese” for the lawyers ▪ Negotiated by Supplier Management

o Challenges in SLM ▪ Keeping all the SLAs, OLAs, and UCs in proper alignment to support the

services and business processes

● Service Level MGMT Process o Service Reviews

▪ Occur at different frequencies ● Monthly

o Service Manager and Customer Management ● Quarterly

o Service Owner and Customer’s equivalent ● Annually

o Top-level management level ▪ Presents the SLA Management Charts

● Stoplight Charts ● Red-Amber-Green (RAG)

o SLAM Chart Examples



o Service Improvement Plan

▪ Formal plan for implementation of improvements to a service or process ▪ Fed back into the Continual Service Improvement (CSI) phase…

o Service Level Agreement Structures ▪ Service-based structure

● Each service has its own SLA regardless of the number of customers using it

▪ Customer-based structure ● Each customer has its own SLA regardless of the number of

services supporting them ▪ Multilayer Structure

● Comprised of a common “Corporate-layer”, then “customer-layer”, then “service-layer” SLAs

● Most commonly utilized o SLA Types

▪ Type I SLA ● Between internal service provider and internal customers

▪ Type II SLA ● Between Type I service provider and

Type II service provider under the same business organization ▪ Type III SLA

● Contractual SLAs as an appendix to a business contract ● Part of larger contract

o Key Takeaways! ▪ SLAs are between service providers and customers ▪ OLAs are between groups within a service provider ▪ UCs are contracts and are legally binding



● Capacity Management Process o Purpose

▪ Ensure that the capacity of IT services and of the IT infrastructure meets the agreed capacity and performance related requirements in a cost-effective and timely manner

▪ Concerned with meeting current and future capacity and performance related needs of the business

o The 3 Sub-Processes of CM ▪ Business Capacity Management ▪ Service Capacity Management ▪ Component Capacity Management

o Sub-Process: Business Capacity ▪ Aligns capacity management to business plans and strategy ▪ Translates requirements into services and infrastructure ▪ Coordinates with Business Relationship Management

o Sub-Process: Service Capacity ▪ Ensures services underpin the business processes and outcomes ▪ Focuses on end-to-end performance of operational services and

workloads ▪ Coordinates with Service Portfolio Management

o Sub-Process: Component Capacity ▪ Ensures appropriate understanding of the technical components in the

infrastructure ▪ Employs data analysis techniques to get maximum value from

components ▪ Coordinates with Configuration Management to ensure optimal

configurations are utilized

● Capacity Management Process o Reactive Activities

▪ Monitoring, measuring, reporting, reviewing performance ▪ Responding to occurrences in operational environment when thresholds

are met ▪ Example:

● Bandwidth utilization over 90% ▪ Responding to specific performance issues

o Proactive Activities ▪ Analyze performance data to enact changes to prevent performance

issues ▪ Employ modeling and sizing to estimate impact of changing services ▪ Ensure infrastructure changes are budgeted, planned, and implemented



▪ Tune services and components to optimize performance ▪ Identify new technological advances to be sought after and pursued ▪ Produce and maintain the capacity plan

o Demand Management ▪ Service providers don’t build to peak capacity because most of the time it

wastes resources ▪ Work with customers to level the peaks through business practice

changes ▪ Constraints on high-demand periods could be financial (extra cost) or

physical (limiting number of connections to a service) o Capacity Plan

▪ Product of the Capacity Management process ▪ Plan includes:

● Details of current and historic utilization level and performance ● Forecasts the capacity changes for needed to support future

requirements ● List of assumptions used ● Costed list of recommendations

o Importance of Capacity Plan ▪ IT Directors use the Capacity Plan when making service decisions ▪ Balancing act

● Supply vs Demand ● Cost vs Resources

▪ Questions to consider ● Can my current infrastructure support a new service? ● Do I need to buy more infrastructure to support a new service?

● Availability Management Process

o Purpose ▪ Ensure that the level of availability delivered in all IT services meets the

agreed availability needs and/or service level targets in a cost effective and timely manner

▪ Concerned with meeting current and future availability needs of the business

o 4 Aspects of Availability (ARMS) ▪ Availability

● Ability of a service to perform its agreed-upon and documented function, as required

▪ Reliability ● How long the service or component can function without

interruption



● How long until it breaks? ● Adding redundancy and resilience helps the reliability

▪ Maintainability ● How quickly and effectively can a service or component return to

functionality after a failure ● How long until it is back to normal?

▪ Serviceability ● What is the ability of a supplier (third-party) to provide their

contractual targets for availability, reliability, and maintainability? ● Serviceability is how well a contractor can achieve the

performance of a promised service o Two Types of Availability

▪ Service Availability ● Focused on end-to-end service that is experienced by the end

user or customer ▪ Component Availability

● Focused on each individual piece that together provides the end-to-end experience

o Customer Satisfaction ▪ Derived from service availability which can be measured in Service Level

Agreements (SLAs) and meeting the targets set out in the service catalog …under promise and over deliver…

o When Things Break… ▪ How you react to failure is important ▪ Things break so be honest and upfront ▪ Take swift action to get it back online

o Primary Focus Area ▪ Service availability is the primary focus area not component availability ▪ You care about the end-to-end experience and the components are only

important to meet the service need ▪ Identify critical business services and understand ensure your SLA targets

well represent them o Be Proactive

▪ Prevent issues instead of fixing them ▪ Identify the weakest links and the bottlenecks in your services ▪ Change things early in the lifecycle because things cost exponentially

more to fix after they are in operations



● Reactive & Proactive Availability o Overview

▪ Availability Management has both reactive and proactive functions you can do to oversee the services

o Reactive Functions ▪ Monitoring, measuring, reporting, and reviewing the current live

availability data during service operations ▪ Responding to and assisting with availability related issues in the Service

Transition or Service Operation stages o Proactive Functions

▪ Analyzing reliability and maintainability data/trends and taking actions to prevent future issues

▪ Examples: ● Conducting risk analysis ● Component failure impact analysis ● Fault-tree analysis ● Incident handing

▪ Ensuring you appropriately budgeted, planned, and fielded infrastructure related to service availability

▪ Identify new components offering increased reliability and maintainability

▪ Produce and maintain availability plan

● Risk Analysis in Availability o Risk Analysis (… a Refresher)

▪ Risk is the “uncertainty of outcome” ▪ Risk should be…

● Identified ● Analyzed ● Managed

● Risk Identification o Identify all the resources and capabilities that enable your services and

determine where risk lies: ▪ Single points of failure ▪ Poor skills ▪ Unreliable sources

o Quick Example ▪ We are going to switch to a brand-new startup company to host our web

services ▪ Will there be a risk to our availability?



o Risk Analysis ▪ Analyze the vulnerabilities identified and measure them ▪ Determine the impact of the likely outcomes if the vulnerabilities are

realized ▪ Prioritize the vulnerabilities ▪ Ensure you identify the vital business functions

o Vital Business Function ▪ Understand the necessary and the “nice to haves” when identifying the

vital business function ▪ Example

● Consider going to the gas station ● What is the “Vital Business Function”? ● Customer’s perspective > Pumping gas ● Would getting a receipt be considered a vital business function?

o Risk Management ▪ Three options to manage risk

● Remove or Avoid o Buy a different component, design a different architecture,

etc... ▪ Mitigate

● Add redundancy (second data line), etc... ▪ Accept

● Risk is already low enough so management can decide not to invest in avoiding or mitigating the vulnerability

● Example o Hurricanes do not often hit Kansas

● Component Failure Impact Analysis (CFIA)

o Component Failure Impact Analysis (CFIA) ▪ CFIA is useful to identify high-impact areas of failure ▪ Having detailed and accurate plans and/or live configurations are

essential to a successful CFIA ▪ Compile a CFIA matrix to understand which configuration items will

impact what services



o CFIA Matrix

● Fault-Tree Analysis o Fault-Tree Analysis

▪ Useful to identify single points of failure ▪ Boolean Logic determines impact ▪ Complementary to the Component Failure Impact Analysis (CFIA)

▪ Most useful during Service Design in building an availability for new or changed services

▪ Helps to identify the key areas where challenges and issues may lie, but doesn’t provide a solution

● Expanded Incident Lifecycle

o Expanded Incident Lifecycle ▪ Reactive availability management



▪ Utilizes incident data captured from live operational environment and processes it for relevant display

▪ Often called the “post-mortem” o Mean Time Between Failures (MTBF)

▪ Calculates how long (on average) a certain component can run before a failure is expected to occur

▪ Measure of uptime and reliability

o Mean Time to Restore Service (MTRS)

▪ Calculates how long (on average) a certain service can be restored after a failure occurs

▪ Measures downtime and maintainability

o Mean Time Between System Incidents (MTBSI)

▪ Calculates the average length of time between one failure and the next failure

▪ MTBSI measures reliability… how often are you being disrupted?



o MTBF, MTRS, MTBSI Explained

o Downtime’s 5 Steps

▪ Detect the incident ▪ Diagnose the fault or root cause ▪ Repair the issue ▪ Recover the component ▪ Restore the service

o Goal: Improve MTBF ▪ Recommend improvements to allow for

● Auto detection of issues ● Diagnostic scripts ● Prepositioning spare equipment/parts ● Configuration guides ● Restoration checklists

▪ These will increase your MTRS (restoration), but you also need to get more reliable components to improve MTBF and MTBSI

● Availability Measurement

o Availability Measurement ▪ Most commonly measured as % ▪ Measure services at the point of delivery (end-user perspective) ▪ Examine your incident records to determine end-to-end availability and

unplanned downtime o Is a percentage best?

▪ Percentages are most common, but not always the best indicator of availability



▪ How many lost man-hours due to network downtime? ▪ How much money was lost since the e-commerce server was down? ▪ These are more important but harder to actually measure…

o Example ▪ E-commerce credit card processing server has gone down for 1 day this

year… ▪ Which metric is most useful?

● Uptime was 99.726% ● 143 man-hours of productivity lost ● $143,376 lost in sales due to downtime

● IT Service Continuity MGMT

o Purpose ▪ Supports the overall business continuity management (BCM)

arrangements by managing the risks that could seriously affect critical IT services and agrees on minimum service levels that apply during contingencies

▪ ITSCM contains disaster recovery but is also so much more than that o ITSCM Actions

▪ Create ITSCM plans to support BCM ▪ Support business impact assessments ▪ Perform risk assessment and management ▪ Provide advice/guidance on ITSCM ▪ Implement agreed-upon service continuity mechanisms/agreements ▪ Assess changes for impact on ITSCM ▪ Assist Supplier Management to negotiate and agree on recovery

contracts o ITSCM and Risk Analysis

▪ Risk analysis focuses on likely events and their impacts ▪ ITSCM looks at unlikely events (but conceivable ones) that would have

large impacts on your services and therefore need to have contingencies plans made



o Initiation ▪ In coordination with Business Continuity Management (BCM), ITSCM

helps to take action to… ● Agree on a policy ● Set the scope ● Form a project ● Get resources for the project

o Requirements and Strategy ▪ Conduct a business impact analysis with the customer ▪ Determine critical business services



▪ Consider possible events ● Fire, flood, or natural disaster ● Acts of terrorism or cyber attack ● Massive staff sickness or loss

▪ Develop a plan for the events o Implementation

▪ Execute the plan ▪ Introduce the risk mitigation steps and award disaster recovery contracts ▪ Publish your plan ▪ Test you plan

o Ongoing Operation ▪ Keep the plan updated ▪ Train your staff on the plan ▪ Test the plan periodically ▪ ISO 22301 is the international standard for Business Continuity

Management

● Information Security MGMT o Purpose of ISyM

▪ Aligns IT security with business security and ensures the IT security aspects match agreed-upon needs of the business

o ISyM Must Understand: ▪ Business security plans and policies ▪ Current/future business operations, plans, requirements, and their

security aspects ▪ Compliance and legislative requirements ▪ ISyM risks and management ▪ Information security policy alignment to the business security policy ▪ Security controls to support policy ▪ Third-party adherence to policy ▪ Security breach and incident management ▪ Integration to all ITIL processes

o Aspects of ISyM…The CIA Triad ▪ Confidentiality

● Ensures only those with a “need to know” can access the data ▪ Integrity

● Ensures data and services are complete and accurate ▪ Availability

● Ensures the customer can actually access the data they are authorized to access



o Information Security Management ▪ Relevant to Availability Management and should be considered ▪ Plan for it in Service Design ▪ Test it a lot in Service Transition ▪ Monitor it during Service Operation

o Remember… ▪ You can outsource a service but not the responsibility for that service ▪ If you outsource to a third party, ensure the contract specifies that they

are responsible for following your policies ▪ ISO 27000 is the international standard for Information Security

Management

● Supplier Management Process o Purpose

▪ Obtains quality service from suppliers that provide fiscal value to meet agreed-upon needs of the business and ensures suppliers meet their contractual obligations

o Supplier Management ▪ Follow contract management’s policy ▪ Produce an enforceable supplier policy ▪ Maintain a Supplier Contractor Management Information System (SCMIS) ▪ Categorize suppliers and contracts ▪ Undertake risk assessments on contracts ▪ Negotiate/manage contracts through their lifecycle ▪ Evaluate and select suppliers ▪ Award and terminate contracts ▪ Maintain supplier relationships by reporting and managing performance ▪ Ensure subcontracted suppliers are managed openly by the prime

supplier to the best interest of the customer o 4 Supplier Categories



o Strategic Suppliers ▪ Involves senior managers and sharing of confidential long-term plans ▪ Example:

● Roll-out of a new nationwide fiber optic network o Tactical Suppliers

▪ Involves significant commercial activity and business interaction ▪ Example:

● Generator maintenance o Operational Suppliers

▪ Involves supply of operational services ▪ Example:

● Hosting of a minor service or website o Commodity Suppliers

▪ Involves provision of low-value products ▪ Example:

● Purchasing of printer ink or bathroom supplies

● Roles in Service Design o Roles in Service Design





● Tools in Service Design o Tools in Service Design

▪ Technology can be useful in Service Design ▪ Tools help speed up design work, maintain standards, and enable running

“what ifs” through modeling and simulation o Areas to Consider Tool Usage

▪ Hardware design ▪ Software design ▪ Environmental design ▪ Process design ▪ Data design

o EXAM TIP ▪ ITIL believes tools are really useful. If you get a question like, “Which of

the following would be assisted by technology?”, the answer is most likely ALL OF THE ABOVE



Service Transition

● Service Transition (Overview) o Service Transition

▪ Stage when services are built ● Purchase ● Installation ● Configuration ● Testing ● Launch ● Operations begin

o Coordination is Key! ▪ Service Transition requires coordination:

● Stakeholders ● Customers ● Users ● Support Organizations

o Testing of Service Transition ▪ End to end testing to include

● Hardware ● Software ● Processes ● Procedures ● Support Agreements

o Key Takeaways ▪ Physical development and implementation of service ▪ Thoroughly tested and fielded into a live environment with no

shortcomings identified ▪ Configuration has been documented ▪ Operations has been trained and ready to receive the new service

● Objectives of Service Transition

o Objectives of Service Transition ▪ To plan and manage service changes while managing the risks involved in

the transition ▪ To ensure the services meet the current and future needs of the business

by creating value ▪ Plan and manage service changes efficiently and effectively ▪ Manage risks ▪ Successfully deploy versions into supported environments



▪ Manage expectations ▪ Create business value ▪ Gain knowledge and understanding

o Plan and manage service changes efficiently and effectively ▪ Utilizing the eight processes in Service Transition allows you to efficiently

and effective plan, field, and manage new, changed, or retiring services o Manage Risks

▪ Change always involves some risk ▪ Imperative that Service Transition team understands the “uncertainty of

outcome” and provide oversight, mitigations, and management to minimize those risks

o Successfully deploy versions into supported environments ▪ Team must ensure that extra resources, training, documentation,

awareness, and understanding have been gained in order to successfully deploy new or changed services

▪ Should include both the operators of the service and the customers o Manage Expectations

▪ Ensure that the customers are aware of the new or changed services and how the services are different

▪ How are they faster, slower, cheaper, better? ▪ Get the customer involved in pilot and acceptance testing

o Create Business Value ▪ Services must provide business value ▪ Must ensure services have created the agreed-upon and documented

business value before ending the Service Transition phase o Gain Knowledge and Understanding

▪ Create an effective knowledge and information management system to ensure knowledge is gained and converted to understanding

▪ Tools can help with this but so must the customer and service providers

● Outsourcing in Service Transition o Outsourcing

▪ If you have chosen to outsource services or parts of a service, now is the time to set up the appropriate contracts

▪ If you do this, then you have changed from being the provider to the customer

▪ Outcomes are facilitated by the services without the specific detailed costs and risks

▪ Many ways to outsource services… o Traditional Outsourcing

▪ You transfer services from internal provisioning to an external supplier



▪ Example: ● Develop a website in-house, but don’t host it on your own

architecture o Changing Outsourcing

▪ You transfer services from one external supplier to another external supplier

▪ Example: ● Migrate your webserver from Amazon Web Services to Microsoft

Azure o Re-Insourcing

▪ You transfer services from an external supplier to your in-house team ▪ Example:

● You hired a firm to build your new website, but decide to maintain it and update it yourself in the future

o Partnership or Co-Sourcing ▪ You migrate to a partnership agreement where some pieces of the

service are outsourced, but others remain in-house ▪ Example:

● You hired a firm to build your new website, but decide to host it on your own servers while they continue to maintain and update it

o Co-Sourcing/Multi-sourcing ▪ Utilize multiple suppliers ▪ Note:

● Increases service level management and supplier management challenges

▪ Example: ● You hired a firm to build your new website, but decide to host it

on a different firm’s web servers

● Transition Planning & Support o Purpose

▪ Provide overall planning for the Service Transition stage and coordinate the required resources

▪ Planning occurs for all related projects and programs during this stage o Functions

▪ Plan and coordinate resources to ensure multiple concurrent transitions can occur seamlessly

▪ Lead major changes through the transition stage ▪ Migrate new or changed services to Service Operations within the

agreed-upon time, cost, and quality



▪ Establish new or improved management systems and tools, technology and management architectures, processes, measurement methods, and metrics

● 5 pieces of holistic Service Design ▪ Provide comprehensive transition plans to align business changes and the

service transition ▪ Identify, manage, and control risks across the other seven (7)

Service Transition processes ▪ Continually monitor and improve the Service Transition stage

performance o Who Does The Planning?

▪ It’s important to note that the Transition Planning and Support process doesn’t do the planning itself

▪ It only ensures that planning is carried out per the service provider’s policies

● Knowledge Management o Purpose

▪ To share perspectives, ideas, experiences, and information ▪ To ensure these are available at the right time to make correct decisions ▪ To improve efficiency by reducing the need to rediscover knowledge

o Functions ▪ Ensure that reliable and secure data, information, and knowledge are

available to decision makers in order to improve quality and drive down cost

▪ Ensure service management data, information, and knowledge are collected, analyzed, stored, used, shared, and maintained

▪ Create and maintain an information management system to securely store data, information, and knowledge

● Service Knowledge Management System (SKMS) o KM’s Place in the Lifecycle

▪ KM really must occur in all stages of the ITIL lifecycle ▪ Your KM program is only as good as your ability to get people to use it…



o Service Knowledge Management System (SKMS) ▪ Data comes from many sources (config DBs, service management tools,

and even open-sources) ▪ Contains all the data in a collection of repositories and systems ▪ Houses the Configuration Management System and in turn contains the

Configuration Management Databases

● Service Asset and Configuration Management o Purpose

▪ Ensures assets needed to deliver services are managed and accurate/reliable information is available for those assets



▪ Service Asset and Configuration Management (SACM) is vital to knowledge management

o SACM Considerations ▪ Don’t start SACM until change control and change management are in

place ▪ Relationships between configuration items is what makes the SACM

powerful instead of a simple asset list ▪ Identify, control, record, report, audit, and verify services and

configuration items (CIs) including their relationships to each other o Functions

▪ Accurate information on configuration items is essential ▪ Historical information on configuration items is necessary ▪ SACM ensures only authorized components are utilized in architecture ▪ SACM ensures only authorized changes occur in the architecture ▪ SACM supports other processes in all stages of the lifecycle ▪ SACM may seem boring but it is crucial to your organizational success

across other various processes

● SACM Definitions and Concepts o SACM Definitions

▪ Configuration items ▪ Categories ▪ Levels ▪ Naming ▪ Labels ▪ Attributes ▪ Configurations ▪ Baselines ▪ Configuration Management System ▪ Definitive Media Library (DML)

o Configuration Items (CIs) ▪ CIs are the individual records in your Configuration Management

Database (CMDB) ▪ CIs are components or service assets that need to be identified and

managed

o Categories ▪ Hardware

● Workstations, servers, switches, … ▪ Software

● OS, productivity, in-house built, …



▪ People ● Users, customers, technical staff, …

▪ Documentation ● End user, admin guides, plans, …

▪ Physical locations ● Server rooms, buildings, …

o Levels ▪ How detailed do your CIs need to be to support your service needs? ▪ Do you need to know every CPU in every workstation or just how many

workstations? ▪ Depends on your organization’s role and any outsourcing being

conducted o Naming

▪ Utilize a uniform naming convention ▪ Do we call all mobile devices one thing, or break them into Laptops,

Tablets, Smartphones, and PDAs? ▪ Do we break them down based on their Operating Systems (Android, iOS,

Windows)? o Labels

▪ How are you going to label assets? ▪ Workstations are easy

● Use a barcoding system ▪ People and electronic software are harder

● Unique employee identifier ● Electronic tracking of software by virtual asset tags

o Attributes ▪ What information do you want to know about the Configuration Item

(CI)? ▪ Universal attributes:

● Description, Unique ID, Location ▪ Other attributes can be customized based on the type of asset ▪ CMDBs are relational databases

● Don’t repeat information multiple times, instead just link to it o Configurations

▪ Group of CIs to makeup a specific build or architecture ▪ Created by linking several CIs in a relationship ▪ KM system may be one configuration which is made up of numerous

assets (servers, software, people) from various CIs o Baselines

▪ Snapshot of a particular configuration at a moment in time ▪ Starting point when equipment arrives



▪ Must document any changes from the baseline to account for the difference between the design and operation

▪ Most common baselines used are for workstations and servers o Configuration Management System

▪ Essential set of tools, data, and information on configurations ▪ Part of the Service Knowledge Management System (SKMS) and each

SKMS can only have one CMS ▪ Includes information on incidents, service requests, changes, problems,

releases, errors, and more o Definitive Media Library (DML)

▪ Secure storage area for authorized software versions for every CI ▪ Includes the licensing information and documentation ▪ Everything must be quality checked before being put into the DML ▪ We will cover this more in the Release and Deployment Management

lesson

● SACM’s 5 Principles o Five Principles of SACM

▪ Planning and Management ▪ Identification ▪ Control ▪ Status Accounting ▪ Verification and Audit

o Planning and Management ▪ First major activity is planning ▪ Must plan to introduce/develop SACM, including resources required, size

of CI types, CI levels, and the management tools needed

o Identification ▪ Designate the CI types ▪ Agree on naming conventions ▪ Decide on unique identifiers for assets ▪ Choose proper CI attributes

o Control ▪ Integrate SACM into the processes that produce changes to keep CI

information up to date: ● Change Management ● Release and Deployment Management ● Incident Management



o Status Accounting ▪ Status of a CI changes over time ▪ Create standard status codes (Example for computers):

● Ordered ● Received ● Configured ● Installed ● Repaired ● Retired ● Disposed

o Verification and Audit ▪ Verify and audit SACM to determine if it is effective ▪ Are users and employees using it? ▪ Is it up to date? ▪ Don’t try to do 100% validation ▪ Spot check it periodically and investigate when a problem is found

● Change Management

o What is Change? ▪ Addition, modification, or removal of anything that could have an effect

on IT services o Purpose

▪ To control the lifecycle of all changes, enabling beneficial changes to be made with a minimal disruption of IT services


● Have a clear change policy and roles/responsibilities to allow for the control of change



● Not just administration of change ▪ To control the lifecycle of all changes, enabling beneficial changes to be

made with a minimal disruption of IT services ● Changes have their own lifecycle ● Some are short and quick ● Others take months or years to finish


● Don’t want to change for change sake ● Need a beneficial reason to change

o Compliance o Make more money o Drive down costs


● Changes cause disruption ● Change management focuses on creating the minimal impact to

the service o Functions

▪ Respond to change-initiating triggers ● New business requirements ● Operational failures ● Improvements and additions

▪ Record, evaluate, authorize/reject, prioritize, plan, test, implement, document, and review changes

o When Does Change Occur? ▪ Changes happen at every stage ▪ Changes happen to the Service Portfolio, Service Catalog, Service Level

Agreements, and processes ▪ Change management needs to be involved with all of these processes



● 3 Types of Changes o Three Types of Changes

▪ Emergency changes ▪ Normal changes ▪ Standard changes

o Emergency Changes ▪ Address unforeseen operational issues, such as failures, security threats,

and vulnerabilities ▪ Rapid change is required to continue the business operations ▪ Emergency changes should still follow the documented procedures, but

they just happen much quicker o Emergency Change Procedures

▪ Clearly define who can declare an emergency change ▪ Emergency Change Advisory Board (ECAB) can be called in after hours for

decisions ▪ Testing may be modified or removed ▪ RFC and documentation are often done after the issue is resolved

o Normal Changes ▪ Change that has a uniqueness to them that represents a higher risk or

uncertainty of outcome ▪ Default type of change that occurs ▪ Emergency and Standard are variations on Normal Change procedures ▪ Example:

● Adding a new server or service o Standard Changes

▪ Typical day-to-day changes that are low-risk and well understood



▪ Utilizes a shorter version of the Normal Change procedures ▪ Minimizes bureaucracy and quickly satisfies customer needs ▪ Example:

● Moving a workstation to another office o Standard Change Procedures

▪ Generally follow a predefined workflow controlled by automation ▪ Usually an automated system checks initiator has permission to start the

process and technicians just work the change ticket to resolution ▪ Don’t need CAB approval since they are approved as part of normal

service management (request fulfillment) o Why Do Changes Fail?

▪ Wider impact than originally thought ▪ Insufficient resources (time, money) ▪ Stakeholder disagreements on who can authorize the change ▪ Poorly planned or conducted testing ▪ Users were not ready for change ▪ Support organizations were not ready ▪ Change rolled out prematurely due to management pressures ▪ Two incompatible changes at once

● Change Process Flow

o Change Management is a Process ▪ A process is a set of coordinated activities combining resources and

capabilities to produce an outcome that creates value for the customer ▪ Processes respond to a trigger, are measurable, produce specific results,

and deliver the results to a defined customer o Change Process Flow

▪ Initiation ▪ Initial Review ▪ Raise RFC ▪ Assess and Evaluate ▪ Authorization to Proceed ▪ Build and Test ▪ Authorization to Implement ▪ Implementation ▪ Remediation ▪ Review ▪ Closure



o Initiation ▪ Change is initiated by a trigger:

● Service request, continual service improvement, program/project, new legal/compliance requirements, better technology, service failures, etc.

▪ Change priority must be determined ● Transition Planning and Support does it



o Initial Review ▪ Determine if proposed change is realistic and check the priority ▪ Record this step into CMS

o Raise RFC ▪ Formal Change Request or “Move, Add, Change” in some organizations ▪ ITIL uses Request for Change (RFC)



o Assess and Evaluate ▪ Analyze change and get recommendations from stakeholders ▪ If your service is being changed, you get a veto!

o Authorization to Proceed ▪ Results of evaluation are presented to the Change Advisory Board (CAB)

for approval or rejection of the change

o Build and Test ▪ Owner/Sponsor builds the service, then Service Validation and Testing

will test it (CM only tracks progress)



o Authorization to Implement ▪ Initial test results are presented to the CAB then approval to implement

can be obtained and scheduling occurs ▪

o Implementation ▪ Release and Deployment are brought in to implement the change into

the production environment

o Remediation ▪ Back out plan if the change release doesn’t work properly or a point of no

return is identified



o Review ▪ If implementation is considered successful then review occurs based

upon accepted timeline after change

o Closure

▪ Results of review are recorded in change record, lessons learned identified, and change pushed to CSI

▪ Authority for closure is the CAB

● Change Advisory Board (CAB) o Change Advisory Board (CAB)

▪ Focused on providing a go/no-go decision for all changes ▪ Meet on a regular basis (i.e. weekly) ▪ In large organizations there may be many smaller CABs, but one is always

the final decision maker o CAB Members

▪ Change Manager (Chairman) ▪ Service Desk Manager ▪ Capacity Manager ▪ IT Security Manager ▪ …other members as appropriate



o CAB Meeting Inputs ▪ Minutes of previous CAB meeting ▪ Any Emergency CAB activity ▪ New changes for decision ▪ Changes ready for implementation ▪ Change reviews completed since last meeting ▪ Any improvement initiatives

o CAB Meeting Outputs ▪ Minutes of this CAB meeting ▪ Authorized new changes ▪ Rejected changes ▪ Updated change schedule ▪ Update PSO (Project Service Outage)

o CAB Chairman’s Role ▪ Protector and enforcer of the standards and processes to ensure positive

change ▪ Ensures all change authorities have approved the changes before he does ▪ Ensures good governance ▪ Provides final approval on RFC

● Change Authority

o Change Authority ▪ CAB is actually not the change authority but serves as an advisory body

making recommendations ▪ Change Authority comprises a role, a person, or a group/team ▪ Change Authority is the stakeholder for a given change

o Who is the Change Authority? ▪ RFC documents the change authority for a given change ▪ Change Management Team notates this during the “raising of an RFC” in

the workflow activity ▪ Change Authorities are often in the management level, executive board,

or IT steering group o Delegation

▪ Delegation of the Change Authority often occurs to the CAB or Change Manager

▪ Routine changes can be delegated down to junior management such as during Standard Changes



● Change Models o Change Models

▪ Predefined steps taken to handling a certain category of change ▪ Numerous change models exist with one for each configuration item

o Simple or Complex? ▪ Change models can be simple or complex ▪ Simple

● Used for tasks like changing a password or moving a workstation ▪ Complex

● Used for tasks like major system rollouts or configuration changes o Standard Change Model

▪ Detailed model covering all the technical details and angles of the proposed changes

▪ Routine tasks can be covered by incorporation into the Standard Operating Procedures

o Normal Change Model ▪ Not as detailed because each change being proposed has unique qualities

o Usefulness of Change Models ▪ Change models are useful when emergency changes are proposed ▪ Provides guidance and useful checklists when limited time is available

● Change Documents

o Change Documents ▪ Request for Change ▪ Change Record ▪ CAB Minutes ▪ Change Schedule ▪ Projected Service Outage

o Request for Change (RFC) ▪ Formal change proposal ▪ Manages change throughout the process

o Change Record ▪ Gives additional details to the RFC and records the relevant information

about the change throughout the workflow and its lifecycle o CAB Minutes

▪ Record of the CAB meetings ▪ Documentation of members present ▪ Documents what was discussed ▪ Documents reasoning used to make decisions



o Change Schedule ▪ States changes to be implemented ▪ Scheduled dates ▪ Other pertinent information useful to the IT staff, users, Service Desk,

and the customers o Projected Service Outage (PSO)

▪ Notifies IT staff, users, Service Desk, and the customers of any changes to normal service availability resulting from impending changes that have been approved for implementation

● Release & Deployment Management o Definition of a Release

▪ One or more changes to an IT service that are built, tested, and deployed together

▪ Releases consist of software, hardware, configurations, or a combination of these

o Purpose ▪ Plans, schedules, and controls the build, test, and deployment of

releases, as well as delivers new functionality required by the business while protecting the integrity of existing services

▪ Plans, schedules, and controls the build, test, and deployment of releases, as well as delivers new functionality required by the business while protecting the integrity of existing services

● Crucial to a successful release and controlled by higher-level guidance of the Change Management process


● Signifies governance and not just the administration of releases and deployments


● Each component of the release has been built and tested separately and as an entire system to ensure a successful integration


● Release is placed into the live environment using your deployment mechanisms




● Provides enhanced utility in the production environment to enable more effective customer outcomes


● Rollout of the new changes cannot negatively impact the existing services (other than as specified in PSO)

o Scope/Span of the Process ▪ Physical assets (servers, networks,…) ▪ Virtual assets (VMs, cloud) ▪ Application/System software ▪ Relevant documentation ▪ Training for users and IT staff ▪ Supporting services, including all related contracts and agreements ▪ Ensuring appropriate testing is completed (per Service Validation and

Testing process) o Functions

▪ Produce/maintain R&D policy ▪ Produce/maintain individual R&D plans ▪ Define/create/test release packages ▪ Maintain integrity of live environment ▪ Deploy software from DML only ▪ Track progress of releases with SACM process ▪ Ensure each release has a test plan for backout ▪ Manage organizational and stakeholder change ▪ Ensure services deployed deliver agreed-upon utility and warranty ▪ Record and manage deviations, risks, and issues ▪ Ensure successful transfer of skills and knowledge to users, customers,

and Service Operation functions

● Release & Deployment Assets o Secure Repositories

▪ All assets being deployed (hardware or software) need to come from a trusted, quality-assured source

▪ Two main ones: ● Definitive Media Library (DML) ● Definitive Spares



o Definitive Media Library ▪ Secure storage of master copies of all software ▪ Access to DML is controlled ▪ DML is physical, electronic, or both ▪ All software is quality-checked for completeness and viruses prior to

entering the DML ▪ Software remains in the DML until it is no longer useful

● Older versions can prove useful in legacy systems and during troubleshooting

▪ Many organizations also keep copies of licenses in the DML for tracking and safekeeping

o Definitive Spares ▪ Unallocated items of hardware ▪ Float is unallocated but configured hardware, ready to be swapped into

the network for broken assets ▪ Definitive spares are controlled like the DML and each item is quality-

checked to ensure it is ready for use when needed

● Release & Deployment Process



o Plan and Prepare ▪ In accordance with policy, determine RFCs for the release candidate ▪ Check authorization on RFCs for implementation ▪ Check resource availability ▪ Publish the plan for release ▪ Ensure organization/users are ready to receive release (training)

o Build and Test ▪ Combine all components (even across multiple RFCs) that comprise

release ● Sometimes, RFCs will be from different projects, but release as a

single release to maximize the maintenance window ▪ Testing ensures no incompatibility in the mixture of the RFCs ▪ Testing of the deployment mechanism should also occur in this phase

o Service Testing and Pilots ▪ Ensures that the release, as a whole, will provide the agreed upon utility

and warranty ▪ Often includes a Pilot test in the live environment across a limited

number of live users such as a whole department or a single geographic region

o Plan and Prepare Deployment ▪ Usually uses automated deployment for software products ▪ Software originates from the DML ▪ Hardware requires physical deployment and coordination with the

software deployment o Transfer, Deploy, Retire

▪ It is time to put our plan into effect! ▪ Service is transferred from one service provider to the next ▪ Hardware/software are deployed ▪ Redundant services, hardware, and software are retired and their

resources are made available to resource pool o Early Life Support

▪ Additional highly skilled specialists may augment the operational teams during the initial roll out of the new or changed services

▪ Goal: ● Bring operational staff up to speed and allow them to take over

the operations fully o Review and Close

▪ Once everything is “done”, it is time to review and close out the deployment

▪ Includes a review to confirm success has been achieved and to collect the lessons learned



o A Note on Phased Releases ▪ In large organizations, releases are done in a phased approach based on

time and/or geography ▪ Planning, preparation, and control are essential to the success of a

phased release, and good configuration management is essential to understand your ever-changing services!

● Service Validation & Testing o Service Validation & Testing Process

▪ Ensures the service that has been built meets the specifications and will provide the agreed-upon utility and warranty to the customer

● Note: Service Validation & Testing Process is not covered by the ITIL Foundation exam

o Important Considerations ▪ Testing is performed under both the Change Management process and

the Release & Deployment process ▪ Different testers than the Release & Deployment personnel conduct the

testing to ensure compliance and proper validation o Service Validation & Testing Process

▪ Process is not covered by the ITIL Foundation exam, but it is necessary to fully understand the lifecycle

● Note: Service Validation & Testing Process is not covered by the ITIL Foundation exam

● Change Evaluation o Change Evaluation Process

▪ To assess the likely performance of the new or changed service ▪ To compare predicted performance against actual performance ▪ To identify and manage risk and issues

● Note: Change Evaluation Process is not covered by the ITIL Foundation exam

o Important Considerations ▪ Helps to set stakeholder expectations ▪ Valuable in providing guidance to the Change Management team on

whether to allow a change to proceed to the next phase of the change process workflow or not

o Change Evaluation Process ▪ Process is not covered by the ITIL Foundation exam, but it is necessary to

fully understand the lifecycle ● Note: Service Validation & Testing Process is not covered by the

ITIL Foundation exam



● Roles in Service Transition o Roles in Service Transition



● Tools in Service Transition o Tools in Service Transition

▪ Many of the same tools from the Service Strategy stage are useful in Service Transition

▪ Many different areas in Service Transition can be benefited by the use of technology

o Areas Where Tools Help ▪ System, network, and application management ▪ Integrated ITSM tools for configuration, change, and release &

deployment ▪ Discovery and auditing tools ▪ Software distribution and management

o Areas Where Tools Help ▪ Service dashboards and reporting ▪ Document and records management ▪ Collaboration tools ▪ Test and test management tools



Service Operations

● Service Operation (Overview) o Service Operation

▪ Begins upon transition of a new service to facilitate the outcomes desired by customers

▪ Urgent operational problems are handled by this stage while others are fed back to Strategy, Design, or Transition (as appropriate)

o Work with What You’ve Got! ▪ Service Operation often requires you to be flexible ▪ Don’t have the benefit of reengineering everything from the beginning ▪ Operations must continue, but Continual Service Improvements must

also occur o Key Takeaways

▪ Service Operations never really end but they do feedback to earlier stages for future development

▪ Provides users and customers with agreed-upon services ▪ Identified faults are quickly fixed or referred back to an earlier stage

● Objectives of Service Operation

o Objectives of Service Operation ▪ Deliver and support agreed-upon IT services ▪ Minimize the impact of failure ▪ Control access to services based on organizational IT security policy

o The Scope ▪ Services ▪ People ▪ Processes

● Event Management ● Incident Management ● Problem Management ● Request Fulfillment ● Access Management

▪ Technology

● Principles of Service Operation o Principles

▪ Balance ▪ Communication



o Four (4) Elements of Balance ▪ Internal IT versus External Business ▪ Stability versus Responsiveness ▪ Cost versus Quality ▪ Proactive versus Reactive

o Communication is Critical ▪ With users and customers ▪ Between operational teams ▪ Between operational shifts ▪ In performance reporting ▪ With projects and programs ▪ For any changes, releases, & deployments ▪ For any failures, exceptions, & emergencies

● Event Management

o Purpose ▪ To manage events throughout their lifecycle

● Lifecycle of an event is usually short ▪ An event is a change of state that has significance for the management of

a CI or IT service o Functions

▪ Detect changes of state that have an impact for any specified configuration item (such as an IT service or system)

▪ Identify the type of event detected and take appropriate actions ▪ Trigger other service management process or actions (if needed) ▪ Capture performance information for comparison against the design

specifications and SLA targets ▪ Provide inputs to service assurance and to the Continual Service

Improvement (CSI) phase o What Does That Really Mean?

▪ Event management monitors CI’s for their technical configuration, software licensing/usage, and adherence to the organizational security policy

▪ Components and services should remain in a steady state once designed or may operate within an allowed range or specification

● Alerts & Event Types

o Alerts ▪ Warning that a threshold has been reached, a failure has occurred, or

something significant has changed ▪ Generated by automated monitoring tools and trigger intervention



▪ May be indicative of event based on the severity level o Event Types

▪ Informational ▪ Warning ▪ Exception

o Informational ▪ Shows that everything is

operating properly ▪ Examples:

● Successful logons by an authorized user ● Completion of a server backup to an offsite data center

o Warning ▪ Something isn’t operating

properly ▪ Usually a threshold has been breached and this gives us enough time to

respond before a failure ▪ Examples:

● Primary hard disk is over 80% capacity ● Network utilization is over 85% usage

o Exception ▪ An error condition has occurred ▪ Performance level is currently

unacceptable ▪ Examples:

● Failed login attempts after 3 tries by user ● Software license has expired ● Backup server’s network connectivity is no longer functional

o What Do You Do With An Alert? ▪ Information

● Considered a completed event and are logged in the CMS ▪ Warning

● Trigger the Problem Management process to determine the root cause

● Logged in CMS ▪ Exception

● Trigger the Incident Management process or create a Change Management issue



● Incident Management (Purpose) o Purpose

▪ Restore normal service operation as quickly as possible while minimizing the adverse impact on business operations, thereby ensuring the agreed-upon level of service quality is maintained


● Normal service is defined by the Service Level Agreements (SLAs) ▪ Restore normal service operation as quickly as possible while minimizing

the adverse impact on business operations, thereby ensuring the agreed-upon level of service quality is maintained

● Just because your SLA states to fix 90% of all problems within 2 hours doesn’t mean you should wait 2 hours to fix the problem…some fixes take less time and some take more


● Efficient and effective incident management causes issues to be resolved faster with less impact to the organization…avoid chaos!


● Check your SLA…What was agreed upon?

● Incident Management (Scope) o Scope of Incident Management

▪ Covers any event or occurrence that disrupts or may disrupt service delivery

o Definition of An Incident ▪ An unplanned interruption to an IT service, a reduction in the quality of

an IT service, or failure of a CI that may impact an IT service ▪ An unplanned interruption to an IT service, a reduction in the quality of

an IT service, or failure of a CI that may impact an IT service ● If it was planned, it would fall under change management (called

a change, not an incident) ▪ An unplanned interruption to an IT service, a reduction in the quality of

an IT service, or failure of a CI that may impact an IT service ● IT services are managed in ITIL based on your SLAs

▪ An unplanned interruption to an IT service, a reduction in the quality of an IT service, or failure of a CI that may impact an IT service



● Reduction in quality is an incident, we don’t need to wait for total failure to take action

▪ An unplanned interruption to an IT service, a reduction in the quality of an IT service, or failure of a CI that may impact an IT service

● Even if a failure hasn’t occurred to the overall service, the failure of a CI must be addressed

● We are always looking to improve reliability and resilience of the service

● Incident Management Process

o Identification ▪ Occurs when a trigger happens

● Exception occurs in Event Management ● Technician discovers an issue ● System auto-detects an issue and creates a service ticket ● User calls to complain



o Logging ▪ Service desk logs all incidents

● Help Desk Analyst creates a ticket with as much detailed information as they can gather on the incident

o Categorization ▪ Service desk determines if an incident or just a service request

● Push ticket to service request (OR) ● Continue incident process per SLAs

o Determine Priority ▪ Incident response occurs based on triage of events and priority

● Impact o What is the effect on the business?

● Urgency o How long before impact is considered significant?

▪ Priority is determined by the SLA ▪ Also determines timeline to correct



o Initial Diagnosis & Escalation ▪ Tier 1 Support is all about triage

● What can I fix quickly? ● What needs a specialist?

▪ If the Service Desk can’t fix it fast, escalate to a higher tier or a specialist

o Escalation ▪ Functional

● Most common type of escalation ● Incident requires a specialist or skills beyond initial Tier of the

Service Desk ▪ Hierarchical

● Referred to management due to severity, persons affected, or permission to obtain replacement components due to cost threshold

● Remember that the Service Desk still owns the incident… o Resolution and Restoration

▪ Complete investigation and appropriate incident correction occur ▪ Incident solution is reported back to the Service Desk and the user



o Closure ▪ Just because a technician says it is fixed does not mean you close the

incident ▪ Check with the end user that it is fixed ▪ Close the ticket and detail what was wrong and how it was fixed

● Major Incidents o What Is a Major Incident?

▪ During prioritization, an incident might be labeled as a Major Incident ▪ Based on predefined criteria ▪ If this occurs, it is reported up to Service Desk Management and the IT

Director

o Major Incident Teams ▪ Most organizations have a “major incident” team to attack these issues



▪ Have preplanned responses for major likely events ▪ Remember, the Service Desk still owns the incident

● Models for Incident Handling o Incident Models

▪ Set of predefined steps for handling a particular type of incident ▪ Generic and Specific Models can exist

o Generic Models ▪ Most service desks use a generic model for handling the initial logging

and categorization of an incident ▪ Simple script for Help Desk Analysts to use ensures a consistent user

experience and an efficient data collection process o Specific Models

▪ Once the incident is categorized, the help desk analyst can move to a specific model for common diagnostic issues

● Password reset and user account lockout ● Restoral of files from backup ● Troubleshooting network connectivity ● Workarounds for a current incident like a proxy server being

offline

o Incident Matching ▪ Help Desk Analysts should attempt to match incidents to the known

existing incidents or recent incidents ▪ Can identify a negative trend that should be addressed for improvement ▪ Can match the symptoms to a database of known incidents and

workarounds

● Problem Management o Problem vs. Incident Management

▪ Problem Management focuses on the long-term solution and fixing the root cause

▪ Incident Management often focuses on firefighting and correcting issues as quickly as possible



o Purpose ▪ To manage problems through their lifecycle, seeking to minimize the

adverse impact of incidents and problems caused by underlying errors and to prevent recurrence of incidents related to those errors

▪ To manage problems through their lifecycle, seeking to minimize the adverse impact of incidents and problems caused by underlying errors and to prevent recurrence of incidents related to those errors

● Lifecycle exists for Problem Management, much like the Incident Management process


● Problem Management seeks to identify and correct the underlying cause of the incidents and to prevent future occurrences


● Why are we getting 32 incidents per month for users being unable to login? Yes, we can reset their login credentials, but is this solving the underlying issue?


● Allows us to prevent incidents and problems from occurring in the future…

o Scope ▪ Triggered by Event Management, Incident Management, and Problem

Management ▪ Implements solutions through Change Management and the Release &

Deployment processes ▪ Proactively uses Availability Management and Capacity Management to

prevent issues

● Problem Management Concepts o Problem Management Concepts

▪ Problem ▪ Workaround ▪ Known error ▪ Known error database (KEDB)



o Problem ▪ Underlying cause of one or more incident, or even possible incidents (like

warnings) o Workaround

▪ Method to minimize or eliminate the impact of an incident until a permanent fix can be implemented

▪ Example ● A server loses power when an electrical breaker trips. You reset

the breaker and restart the server. ● Did we solve the root cause? ● Why did the breaker trip?

o Known Error ▪ Exists when you have an incident and a current workaround ▪ Not as good as a permanent solution, but it allows business operations to

continue until a permanent solution can be implemented ▪ Example

● You can’t use the microwave and the toaster at the same time… o Known Error Database (KEDB)

▪ Forms part of the Configuration Management System (CMS) ▪ Details problems, workarounds, and known errors in a common database ▪ Contains Error records and Problem Records (these are different things)

o Error and Problem Records ▪ Error Records

● Problem with an associated workaround ▪ Problem Records

● Problem without an associated workaround o Incident vs. Problem

▪ Incident ● When open, normal service is interrupted; when service is

restored, incident is closed ▪ Problem

● When open, a permanent solution hasn’t been implemented yet ▪ Incidents, Problems, and Known Errors

● All are stored in your CMS and should show the current relationship between them

● Problem Management Process o Problem Management Process

▪ Incident Matching ▪ Initiating the Process ▪ Problem Models



▪ Major Problems o Incident Matching

▪ Matching an incident to a known error helps the service desk’s efficiency ▪ By matching symptoms to existing incidents and known errors, the

Incident Management process is aided by the Problem Management process

▪ Goal: consistency, quality, and sharing of knowledge across the service desk analysts

o Initiating the Process ▪ Does every incident trigger a Problem Management process? ▪ Often, organizations rely on the Service Desk supervisors and managers

to determine when an incident meets the threshold to begin the Process Management process

▪ Conducting a full root cause analysis can cost lots of time and money… o Problem Models

▪ Just like in the Incident Management process, the Problem Management process likes to provide models to use

▪ Problem Models provide predefined steps to use when conducting the investigation of a given problem

▪ Creates a standard methodology to be used in the organization for problem analysis and resolution

o Major Problems ▪ Just like Incident Management defines Major Incident, we need to define

it ▪ Identify Major Problems and perform postmortem analysis

● What went right? ● What went wrong? ● What could be done better next time? ● How can we prevent this in the future? ● What involvement did we have from 3rd parties, if any?

● Request Fulfillment Process

o Purpose ▪ To manage the lifecycle for all service requests from users ▪ Deliver value directly and swiftly to users, enhancing their efficiency and

effectiveness o Types of Requests

▪ Numerous types of requests are made: ● New account creation ● New hardware ● New software



● Resetting their password ● Move a workstation to a new office

o WARNING: Stick to the Process… ▪ Users want to circumvent the process ▪ Then, it usually makes the request take longer and aggravates both the

user and the IT staff o Managerial or Individual?

▪ Is the request being made managerial or individual? ▪ If managerial, use the Business Relationship or Service Level

Management processes ▪ If individual, use the Request Fulfillment process

o Functions ▪ Increase user satisfaction ▪ Provide access to a standard service set (usually web-based) ▪ Provide information, help, and guidance for user issues and requests ▪ Handle complaints, comments, and compliments

o Key Takeaways ▪ Request fulfillment is about handling all requests, not necessarily solving

them ▪ All requests should be recorded, as this helps Continual Service

Improvement ▪ Requests can trigger other processes (Change, Incident, & Problem

MGMT) ▪ Some requests are impossible to fulfill

● Access Management

o Purpose ▪ To provide the access rights to allow users to utilize a given service or

group of services ▪ Access Management executes the IT Security Management policy set

forth by the organization o Functions

▪ Operate per the IT Security Management policy ▪ Grant/Change/Remove access rights as approved and/or directed ▪ Ensure changes occur per the process ▪ Oversee access to services in conjunction with Event Management

o Process Initiation ▪ Often triggered by a service request, Change Management, or Release &

Deployment Management processes



o Organizational Access Management ▪ Some organizations do not treat access management as a separate

process ▪ Access management may be rolled into Request Fulfillment, Change

Management, or Release & Deployment, depending on your organizational design

● The Service Desk o Overview

▪ Crucial component to Service Management ▪ What most people think of with ITIL ▪ Personnel are generalists with expertise over a variety of services

o Purpose ▪ To provide a single, central point of contact for all users of IT services ▪ To be the first point of contact for all issues with all services

o Effective Service Desks Provide… ▪ Improved customer satisfaction ▪ Consistency in support to users ▪ Speedy service restoration for failures ▪ Quality and speed for fixing incidents ▪ Effective teamwork by delegating tasks to specialists ▪ Better management and control of the infrastructure through use of CMS ▪ Proactive approach to service improvement and service provisioning ▪ Capture of metrics and relevant data

● Service Desk Functions

o Functions of the Service Desk ▪ Log & categorize incidents ▪ Log & categorize service requests ▪ Prioritizing incidents ▪ Diagnose & correct Tier 1 incidents, restoring services when possible ▪ Escalate incidents and service requests by function or hierarchy, per

organizational directive ▪ Communicate status with users

● Current incidents and problems ● Future rollout of services

▪ Close incidents and service requests ▪ Maintain currency of the CMS data ▪ Communication between user community and service provider ▪ Follow-up with users to determine their satisfaction level (surveys,

calls,…)



● Service Desk Personnel o Personnel of the Service Desk

▪ Often, the service desk is the first position in IT many will have ▪ It is still a vitally important role, though ▪ Training must be professional and complete for them to be successful

o Qualities for Service Desk Analysts ▪ Knowledge and Awareness of the business’ role to the user/customer ▪ Technical acumen and skill ▪ Communication and interpersonal skills ▪ Methodical approach to problems ▪ Ownership and responsibility

● Structure of the Service Desk

o Help Desk -> Service Desk ▪ First service desks were simply call centers or help desks ▪ Over time, they became better organized and evolved into full-service

desks, offering more than just a “break-fix” mentality to problem solving o Local Service Desk

▪ Located physically close to the customers they support

o Centralized Service Desk ▪ Makes better use of resources, improves consistency, and centralizes

management



o Virtual Service Desk ▪ Doesn’t require a centralized location, but can still make better use of

resources, improves consistency, and centralizes management

o Follow-the-Sun ▪ Combines local, centralized, and virtual service desks, allowing for 24x7

coverage across all time zones ● America ● United Kingdom ● India

o Specialist Service Desks ▪ Internal variation on Tier 1 service desk ▪ Sub-team of the service desk to address a certain type of issue that

occurs frequently, instead of escalating everything to Tier 2

● IT Operations Management o Purpose

▪ To provide a stable platform on which services can be delivered to meet the agreed-upon business needs

▪ To perform the day-to-day running of the IT infrastructure o IT Operations Management

▪ Consists of ● IT Operations Control ● Facilities Management

o IT Operations Control ▪ Monitors the infrastructure for optimal performance minute-by-minute ▪ Carries out the administrative and functional tasks to keep services up

o IT Operations Control: NOC ▪ Network Operations Center (NOC) or Operations Bridge are common

terms for their workspace



o IT Operations Control: Activities ▪ Monitoring the infrastructure performance and event management

process ▪ Scheduling jobs, roll-outs, and upgrades ▪ Performing backups and restorations ▪ Managing production of reports and metrics ▪ Performing maintenance activities on the infrastructure

o Facilities Management ▪ Concerned with the physical environment of the infrastructure

● Data centers, server rooms, … ● Power Supplies ● Air Conditioning (HVAC) ● Physical access control

▪ Close relationship necessary with the IT Operations Control for success ▪ Only concerned with IT facilities, not

kitchens, bathrooms, etc.

● Technical Management o Purpose

▪ To provide technical resources to various phases, including Service Operations, Service Transition, Service Design, and Continual Service Improvement

o Roles of Technical Management ▪ Custodian of technical knowledge and skills in the organization ▪ Source of technical resources needed to support the entire ITIL lifecycle ▪ Helps to plan, implement, and maintain a stable technical infrastructure

o What is Technical Infrastructure? ▪ Networks ▪ Servers ▪ Mainframes ▪ Operating systems ▪ Desktop ▪ Middleware ▪ Databases ▪ Other components that makeup the topology or platform that runs

services o Functions of Technical Management

▪ Produce a well-designed, resilient, flexible, and cost-effective platform for services to run upon

▪ Provide guidance to IT Operations Management to maintain operations ▪ Keep technical infrastructure in the best operating condition



▪ Provide additional support during investigation, diagnosis, and resolution during incidents and problem management

● Applications Management

o Purpose ▪ To provide application resources to various phases, including Service

Operations, Service Transition, Service Design, and Continual Service Improvement

▪ To help identify software requirements and their sourcing (internal/external)

o Roles of Application Management ▪ Custodian of technical knowledge and skills relating to the management

of applications in the organization ▪ Source of actual application resources needed to support the entire ITIL

lifecycle ▪ Helps to determine if an application should be developed in-house or

outsourced o Functions of Applications Management

▪ Design cost-effective and resilient applications ▪ Ensure applications deliver the required functionality (utility) ▪ Provide applications-related technical skills to keep applications in the

best condition ▪ Provide additional support during investigation, diagnosis, and resolution

during incidents and problem management o App Management vs Development

▪ Application Development ● Focused on the design and construction of an application solution

to gain initial utility ▪ Application Management

● Focused on the ongoing oversight, operational management, and improvement of applications for both utility and warranty

● Roles in Service Operation o Roles in Service Operation





● Tools in Service Operation o Tools in Service Operation

▪ Numerous tools have been developed to help in Service Operation ▪ Don’t lose sight of the importance of processes in favor of tools ▪ Tools should be used once your processes have been documented and

implemented in the organization o Tools Capture Metrics

▪ Tools can be especially helpful during Service Operations to capture performance data for use in the Continual Service Improvement phase

▪ Incident and Problem Management are key areas in Service Operations to implement tools to process workflows

o Tools: Self-Help Functionality ▪ Provide users a method to conduct routine service requests quickly and

initiate standard changes ● Password resets ● Ordering toner/ink ● Gaining access to Knowledge Bases ● Request access to files/folders ● Submitting incidents to the Service Desk

o Tools: Workflow and Process Control ▪ Process control in Service Operations is one of the biggest areas of ITIL

toolset available ▪ Example

● Remedy



o Tools: Configuration Management System ▪ A good CMS will automate many of the processes and functions in Service

Operations ▪ Example:

● Log an incident ticket, and user information service level agreements, workarounds, and configurations will auto populate for the analyst

o Tools: Remote Control of User Desktop ▪ Service Analysts can use software to remotely control the user’s

workstation and fix an issue or provide training ▪ Example:

● Remote Desktop (by Microsoft) ● LogMeIn

o Tools: Diagnostic Scripting ▪ Service Analysts can use diagnostic scripts created by Tier 2 and Tier 3

analysts to collect data and possibly resolve issues quicker for a user o Tools: Dashboards and Reporting

▪ Provide real-time performance information and detailed metrics to NOC personnel and management

● Service Operation Interactions o Service Operation Interactions

▪ Many of the processes in Service Operations trigger each other and are interwoven by events, incidents, and problems



Continual Service Improvement (CSI)

● Continual Service Improvement o Continual Service Improvement

▪ Occurs during all stages ▪ Most useful starting it during the Service Operation stage ▪ Identifies processes and functions that

need to be strengthened in order to increase efficiency o Efficiency is Key!

▪ Main effort in Continual Service Improvement is increasing efficiency ● Are you tracking customer issues? ● What issues are occurring? ● Which processes are failing? ● Which service agreements are not working?

o Key Takeaways ▪ Captures relevant information to inform appropriate fix actions ▪ Interprocess links are verified as functional, effective, & efficient ▪ Occurs at all stages (& even on itself) ▪ Service Operations data is critical to feed into the Continual Service

Improvement process (metrics, …)

● Objectives of CSI o Objectives of CSI

▪ Measure and identify the value created by various initiatives ▪ Review management information and trends to ensure services meet the

SLAs to achieve desired results ▪ Review existing deliverables for appropriateness ▪ Review business trends, priorities, and projections ▪ Perform customer satisfaction surveys ▪ Conduct maturity assessments against current processes, functions,

activities and roles ▪ Conduct internal and external service reviews to find areas for

improvement ▪ Conduct internal audits to verify compliance with processes & activities ▪ Review existing deliverables

● Principles of CSI

o Principles ▪ Deming Cycle

● Plan



● Do ● Check ● Act

▪ The Continual Service Improvement (CSI) Register o Deming Cycle (Plan-Do-Check-Act)

▪ Plan ● Establish and define objectives and processes to achieve desired

output ▪ Do

● Implement the plan and processes to collect appropriate data and metrics

▪ Check ● Study and assess the data

▪ Act ● Improve original plan with changes to achieve desired goals

o Deming Cycle (Plan-Do-Check-Act) ▪ Closed-loop feedback system

o Continual Service Improvement (CSI) Register ▪ Central repository that documents all potential improvement

opportunities ▪ All stakeholders can make entries, but the register is owned by CSI

manager ▪ CSI register is large (500+ items) ▪ Allows cross-synchronization of “good ideas” to occur for maximum

return on investment



o CSI Register Items ▪ Description ▪ Scale of proposal

● Small, medium or large ▪ Timeline

● Short, medium, or long ▪ Resources needed

● Estimated cost ▪ Originator and Sponsor ▪ Cross-references

● CSI items, RFCs, or project proposals o Continuous or Continual?

▪ Continuous is relentless and unceasing ● Becomes a way of life

▪ Continual means there are starts/stops ▪ Plan-Do-Check-Act implies continual improvement with a beginning and

end o CSI is a Way of Life

▪ CSI must become a way of life ▪ Cannot just do it for short durations ▪ May champion a major CSI initiative as a project, but you cannot do CSI

itself that way!

● CSI Process o Purpose

▪ Define and manage the steps necessary to identify, define, gather, process, analyze, present, and implement improvements

▪ Note: ● CSI Process is the only process in the CSI phase of the ITIL lifecycle

o Functions ▪ Identify opportunities for improving services, processes, tools, &

activities ▪ Seek to reduce the cost of services ▪ Identify the required things to measure, analyze, and report upon ▪ Review all service achievements ▪ Understand what to measure ▪ Understand why it is measured ▪ Define the objective

● What is a successful outcome?



o 7 Steps to Service Improvement ▪ 1. Define the vision/strategy ▪ 2. Define what is to be measured ▪ 3. Gather the relevant data ▪ 4. Process the data for analysis

● Data becomes information ▪ 5. Analyze the data for trends

● Information becomes knowledge ▪ 6. Leaders assess knowledge and produce service improvement plans ▪ 7. Implement agreed-upon changes

● An Approach to CSI o An Approach to CSI

▪ Helpful to have an overview of the CSI process and how to implement it



● Metrics and Measures o Purpose

▪ To validate previous decisions ● Evidence that we’re doing things right

▪ To direct activities by setting targets ● Are we meeting the SLAs?

▪ To justify a course of action ● Provides evidence that it is the right path

▪ To course correct if errors occur ● What do we do when a threshold is breached in Event

Management? o Baselines in Measurement

▪ Create a snapshot of an area of the Configuration Management System ▪ Create baselines before and after a change is implemented to determine

change’s effect on operations ▪ Provides an accurate picture of the services, processes, and other CIs

being measured o Metrics

▪ Measure that is captured and reported on a given service, process, or activity

▪ Technology Metrics ● Component or application-based ● Server availability or app performance

▪ Process Metrics ● Captured using process workflow tools

▪ Service Metrics ● Measures end-to-end experience

o Key Performance Indicator (KPI) ▪ Metric used to help manage an IT service, process, or activity ▪ Quantitative

● Based on numbers ▪ Qualitative

● Subjective in nature ▪ KPIs are supported by metrics

o Critical Success Factor (CSF) ▪ Thing that MUST happen for an IT service, process, or activity to succeed ▪ CSFs are supported by related KPIs



o Measuring Objectives

● Putting CSI Into Practice o How To Put It Into Practice?

▪ Leadership buy-in is crucial to success ▪ Get better at fighting fires (operations) ▪ Get control over Change Management ▪ Improve Configuration Management ▪ Focus on managing services, not on managing technology

o What If You Are In Charge? ▪ What should be your first steps? ▪ Get some small wins and then build up some momentum ▪ Partnerships with the “right” folks will pay big dividends in the end ▪ Learn to influence others to achieve your goals

o Kotter’s 8 Steps to Change ▪ 1. Create a sense of urgency ▪ 2. Form a guiding coalition ▪ 3. Create a vision ▪ 4. Communicate the vision ▪ 5. Empower others to act on the vision ▪ 6. Plan for and create quick wins ▪ 7. Consolidate improvements and produce more change ▪ 8. Institutionalize the change



o Bottom Line… ▪ If you are to continually improve (CSI) then you need to build a culture of

change and improvement ▪ Look for efficiencies and quick wins ▪ Build your partnerships

● Roles in CSI

o Roles in CSI ▪ ITIL doesn’t dictate how an organization should be organized ▪ ITIL does recommend these roles:

● Service Owner ● Process Owner ● Process Manager ● CSI Manager ● CSI Process Owner ● CSI Process Manager ● Reporting Analyst

o Roles in CSI

● Tools in CSI o Tools in CSI

▪ All tools from other phases of the lifecycle are useful in CSI ▪ CSI also helps determine the best tools to use for each other phase

o Useful Areas for Tools in CSI ▪ Event/Incident/Problem Management ▪ Systems and Network Management ▪ Service Requests ▪ Knowledge Management ▪ Performance Management



▪ IT Security Management ▪ Financial Management

o Always Continually Evaluate Tools ▪ CSI always looks for places to improve ▪ Continually review tools’ status and success to determine if new tools or

configurations are needed ▪ Tools are useful in

● Data gathering ● Analysis ● Reporting ● Determining process efficiency and effectiveness



Process, Functions, and Phases

● ITILv3: Overview of Processes & Phases

Let’s get you certified!