0% found this document useful (0 votes)
45 views43 pages

ITIL

ITIL is a framework for IT service management best practices that is vendor-neutral and non-prescriptive. It provides best practices for IT service management gathered from various sources. The ITIL framework is modular and customizable for each organization's needs. It includes a core set of five books covering the key stages of the IT service lifecycle, as well as complementary guidance materials. Some key aspects of ITIL include definitions of common terms, descriptions of key processes and roles, and guidance on how to implement ITIL to support an organization's strategies and objectives.

Uploaded by

Ibtisam Ab
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
45 views43 pages

ITIL

ITIL is a framework for IT service management best practices that is vendor-neutral and non-prescriptive. It provides best practices for IT service management gathered from various sources. The ITIL framework is modular and customizable for each organization's needs. It includes a core set of five books covering the key stages of the IT service lifecycle, as well as complementary guidance materials. Some key aspects of ITIL include definitions of common terms, descriptions of key processes and roles, and guidance on how to implement ITIL to support an organization's strategies and objectives.

Uploaded by

Ibtisam Ab
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 43

ITIL

11 October 2018
ITIL Introduction
• ITIL enjoys global success because: -Vendor neutral -Non prescriptive -Best practice
• ITIL is a framework to do IT Services Management. IT Service Management best practices: (which of these are sources/enablers)
• Sources of best practice(what to do)
• Academic research
• Training and Education
• Public Frameworks
• Proprietary knowledge
• Standards
• Enablers of best practice (how to do it)
• Advisors
• Technology
• Suppliers
• Customers
• Employees
• ITIL is a framework, not methodology or a standard(no way to benchmark)
• ITIL is not a set of rules or procedures
• Based on practical experience, not vague theoretical ideas
• Its meant to be adopted then adapted
• Its modular, use only what your organization needs
• Every ITIL implementation will feel different because organizations are different
• ITIL has two components:
• Core library; five books, book for each lifecycle stage
• Complementary Guidance
• Aimed at specific audiences (e.g. executives CIO, IT professionals)
• Guidance for specific industries(e.g. banks, small tech department)
• How to integrate ITIL with other models(PMP, Agile scrum developers)
• Web based updated and dynamic
ITIL definitions
• Service: is a means of delivering value to customers by facilitating outcomes customers want
to achieve without the ownership of specific costs and risks
• Service Management: a set of specialized organization capabilities for providing value to
customers in the form of services (what is this definition of)
• IT Service Management: the implementation and management of quality services that meet
the needs of the business (this is your goal, ITIL framework to help you do that)
• Governance: defines common policies and directions and rules that both the business and IT
use to conduct business. It ensures transparency and fairness in all transactions
• IT Governance: ensures that the organizations IT sustains and extends the organizations
strategies and objectives
• Customer: someone who buys goods or services
• Internal customer: customers who work for the same business as the IT service provider
• External customer: customers who work for a different business than the IT service provider
ITIL definitions
• Services classification:
• Core services: delivers most basic outcomes/functionality desired by customer (email)
• Enabling services: needed in order for core services to be delivered (application support)
• Enhancing services : added to core services to make it more attractive or interesting
(BYOD)
• Supplier: a third party responsible for providing goods or services that are
required to deliver IT services
• User: a person who uses IT services on a day-to-day basis
• Stakeholder: those who have an interest in an organization, project, service etc.
and maybe interested in the activities, targets, resources or deliverables from
service management (anyone can be stakeholder,everybody)
• Services Providers:
• Internal services (dept that serves only one unit in org)
• Shared Services (dept that serve all in org e.g. HR)
• External service providers (vendors/company-STC internet service provider)
Process characteristics:
• Measurable
• Specific results (objectives)
• Deliver results to customer/stakeholder
• Respond to specific event (trigger)
• Must be documented

• Process owner accountable for overall success of process.


• Process owner Responsibilities: (DIME)
• Document process
• Improve continually to align with business needs
• Measure the process results against metrics
• Educate staff on using process and ensure it is followed
• Process Practitioners people who do the process
• Process Managers manage day to day activities of the process
• Functions (team) : groups within org that is specialized to perform certain types of work and
are responsible for specific outcomes (e.g. service desk, it includes the tools use like self help
portal)
• Roles (hat): set of responsibilities defined in a process and assigned to a person or team
• Processes : performed by one or more functions and may include any of the roles,
responsibilities, tools, management controls required to reliably deliver the defined outputs
• Four ITIL functions:
• Service Desk
• IT Operations Management
• IT Operations Control (monitor- NOC)
• Facilities Management (responsible of physical IT, e.g. cooling of datacenter, cabling)
• Technical Management (server installation, network conf)
• Application Management (managing apps e.g. developers)
• RACI Model: used to assign roles and responsibilities for the activities within a process
• Responsible (executes step,at least 1 person, can be multiple for each step in process)
• Accountable (only one person accountable-sometimes the process owner)
• Consulted (optional)
• Informed (optional)
Service Lifecycle- SERVICE STRATEGY
STAGE
• Service Strategy -think why before how ( ) if it sounds like marketing its strategy
• Service Strategy Objectives:
• Provide understanding of what strategy is
• Ensure good relationship between customers service provider
• Define how value is created
• Decide what services should be offered & to whom
• Strategic (long term) planning
• Set policies & objectives
• ITIL Service Strategy (scope) starts by defining generic principles & processes of service management,
then applied consistently to the management of IT services and then applied consistently to
management of IT services (setting policies & objectives)
• Services to support strategies, strategies to support services
• Service Strategy-Value to business:
• Enable service provider to have clear understanding of types & levels of service will make its customer successful
• Enable service provider to respond quickly & effectively to changes in business environment
• Support creation & maintenance of portfolio of quantified service
• Facilitate functional and transparent communication between service provider & customer, both consistently
understand what is required & how it will be delivered
SERVICE STRATEGY- CREATE VALUE
• Value of Service to customer is influenced
by:
• Customers perception of what is delivered
• Customers pre-established preference
• Actual business outcomes
• Calculate value: value has two components
• Utility- fit for purpose (does it do what I need it to do)
• Warranty- fit for use , the service is available
when needed, in sufficient capacity and is
dependable in terms of continuity and
security (is it up & running when I need to use it) Capabilities:
Resources:
Tangible
• Characteristics of value: Intangible
(e.g. server,
(e.g. people skills
• Value is defined by customer only & abilities)
MS Word,
Stored data,
• Value isn’t about money 4 people)
• Patterns of Business Activity (PBA): Understand & document the demand of IT services
• Certain times the business behaves in a way which impacts IT
• PBA helps IT service provider understand & plan the capacity to handle different levels of business
activity
• Demand patterns can be used to influence how customer use services

• PROCESS: SERVICE PORTFOLIO MANAGEMENT (responsible for the management of service portfolio)
• Objectives:
• Decide which services to offer & to whom
• Maintain definitive portfolio of all services provided(ensure each service has a business case)
• Control which services are offered , under what conditions & what level of investment
• Track the investment in services throughout lifecycle
• Analyze which services should be retired -planned services

-all current
• The service portfolio is created, managed and supported through operational services.
customer facing
Service Portfolio Management process solutions

-archived. Reason
why it was retired.
• The service portfolio is a tool to prioritize investments in IT Can bring back
• PROCESS: FINANCIAL MANAGEMENT
• Financial management provides common language by providing the business and IT
with the quantification, in financial terms, of the value of IT services (which process provides the
quantification, in financial terms, of the value of IT services )

• Objectives:
• Provide financial visibility & accountability
• Ensure money is spent wisely
• Interface with all other processes to plan budget & calculate the cost of providing services
• (not everyone speak tech or business but everyone understands money & value)
• PROCESS: BUSINESS RELATIONSHIP MANAGEMENT
• Purpose:
• Establish & maintain business relationship between service provider & customer.
• Identify customer needs & ensure that the service provider is able to meet those needs
• Objectives:
• Ensure high levels of customer satisfaction
• Establish a formal complaint and escalation procedure for customer
• Articulate business requirements for new services (or changes to existing services) to the IT org
• BRM ensures customer expectation don’t exceed what they’re wiling to pay for and the
service provider is able to meet the customers expectations before agreeing to deliver the
service (should a customers request for new service always be fulfilled? NO)
• SERVICE STRATEGY DELIVERABLES
• Service portfolio
• Defined business outcomes and agreements to fund services
• List of business requirements to satisfy and/or business challenges to solve
• Document Patterns of Business Activity
• Business strategies, policies and constraints
Service Lifecycle- SERVICE DESIGN
STAGE
• Service Design Objectives:
• Design a new or changed service for introduction to live environment
• Design all of governing IT practices, processes, policies necessary to realize service provider
strategy
• Assembly of Service Design Package(SDP) for subsequent transition, operation ,
improvement of new or changed service solution

• Service Design Package is produced for each new IT service, major change or IT
service retirement
• Service Design-Value to business:
• Improve quality of service
• Improved service alignment with business values and goals
• Reduced Total Cost of Ownership(TCO)
• (if designed carefully & implemented & followed properly)
• SERVICE DESIGN: FIVE ASPECTS (the things we will design) (STAMP)
• Design Service Solutions (including functional requirements, resources & capabilities needed &
agreed upon)
• Design management information systems and Tools (service portfolio & service
catalogue)
• Design technology Architecture and management architectures
• Design Measurement methods and metrics
• Design Processes required

• Automation of processes (which is good candidate for automation? All of above)


• Design and modeling
• Service catalogue updates
• Pattern recognition & analysis {Event management, Problem management}
• Classification, prioritization, routing {incident, change and problem management}
• Detection & monitoring {event management, incident management} What are the four Ps of
• Optimization {load balancing} design?
What is Products?
What is Partners?
Do I have it to design, to
build(transition stage), to
support it (operation stage)?
• PROCESS: SERVICE CATALOGUE MANAGEMENT
• Objectives /Purpose:
• Create and manage accurate service catalogue as single source of information about all operational services
• Ensure available to everyone who is approved to access it
• Ensure reflects the current details, status, interfaces and dependencies of all services that are being run, or
prepared to run (e.g. it can be ready over the weekend and have ability to request it), in live environment

• PROCESS: SERVICE LEVEL MANAGEMENT


• Objectives :
• Negotiate, agree to, document achievable IT service targets in SLAs (Service Design)
• Monitor & produce reports on services delivered (Service Operation)
• Ensure IT and customer have a clear expectation of level of service to be delivered
• Improve relationship & communication with customer

• Service Level Requirements (SLR): a customer requirement


for an aspect of IT service. It’s a document which record a
customers initial service targets
• THREE TYPES OF AGREEMENT
• SERVICE LEVEL AGREEMENTS: between customer and service provider (SLM)
• OPERATIONAL LEVEL AGREEMENTS: between two groups within the service provider (SLM)
• UNDERPINNING CONTRACTS (third party contract): between IT and external provider (Supplier Management)

• SLA STRUCTURES:
• Service-based SLA: covers one or more services for all the users of that service
• Customer-based SLA: covers all services received by single customer group
• Multi-level SLA:
• Corporate-Level
• Customer-Level
• Service-Level

• Service OWNER: IT person accountable for the end-to-end service. Responsible for: (RISE)
• Represent the service to the business in change management or other meeting
• Continually Improving the service so it’s aligned to business needs
• Sign the SLA
• Usually an IT Executive
• The Service Review
• Service level manager compiles performance reports based on input from process owners and service owners
• (done in Service Operation stage)
• Service Reviews performed as often as specified in each SLA (how often should service level management send reports to the customer? Depends how often it was
agreed in SLA)

• SLA Monitoring (SLAM) chart: (what the service review looks like)
• At a glance overview of SLA achievements measured against targets
• Service Improvement Plan (SIP):
• Drawn when need, can have multiple running or none
• Given to CSI manager to be included in CSI Register

Business Relationship Management Service Level Management


Managing the business relationship Managing the service levels
Strategic Operational
Focuses on understanding how services meet customer requirements Provides information about levels of services agreed and achieved
Nurtures business relationship by keeping customers informed and happy Only interacts with customer when BRM is there
Gathers high level business requirements Writes SLAs and OLAs based on input from BRM
Keeping customer happy Documenting and negotiating SLAs and their targets, compiling reports
BRM identifies customers needs, ensures that the service provider is able to SLM ensures that agreed achievable levels of service are provided to the
meet the customers needs customer and users

• When negotiating SLAs, Service level management process can get input from any or all processes
• PROCESS: CAPACITY MANAGEMENT
• Objectives : (usually word performance is related to capacity management in exam)
• Produce and maintain up-to-date Capacity Plan
• Provide advice and guidance to the business and IT on all capacity and performance issues
• Ensure that service performance achievements meet or exceed all of there agreed targets by managing the
performance and capacity of both services and resources
• Assist with diagnosis and resolution of performance and capacity related incidents and problems
• Asses impact of all changes in Capacity Plan
• Ensure that proactive measures to improve the performance of services implemented wherever cost-justifiable

• CAPACITY MANAGEMENT: 3 Sub processes (what are the three sub processes of capacity management)
• Business Capacity Management: (what is the definition of?) Where future business requirements for IT services
are quantified
• Service Capacity Management (e.g. email, internet)
• Component Capacity Management (e.g. increase number of servers to allow adding more email users)

• Output of Capacity Management:


• Capacity Management Information System(CMIS)
• Business data
• Service Data
• Component utilization Data
• Financial Data
• Capacity Plan: typically published annually, includes current and forecasted levels of capacity
• PROCESS: AVAILABILITY MANAGEMENT
• Objectives :
• Ensure that service availability achievements meet or exceed their agreed targets
• Produce and maintain Availability Plan
• Provide advice and guidance to the business and IT on all availability-related issues
• Assist with diagnosis and resolution of availability-related incidents and problems
• Ensure that proactive measures to improve the availability of services implemented wherever cost-justifiable
• Measuring and monitoring of service and component availability
• Implement or test is service transition
• AMIS is not in the exam

• What does Availability Management measure?


• Service availability: measure end-to-end service
• Component availability: measure availability and downtime of
Individual components
Availability: the ability of component or IT service to perform its
agreed function on time

Reliability: measure of how long service or component perform


agreed function without failing or interruption

Vital Business Function: part of business process that is critical to the


success of business; it’s core functionality
• PROCESS: IT SERVICE CONTINUITY MANAGEMENT
• Purpose: support the Business Continuity Management process by ensuring & managing risks that
could seriously affect IT services, IT service provider can always provide minimum agreed business
continuity-related service levels
• Objectives : Produce and maintain IT Service Continuity Plans and Recovery Plans
• Ensure ITSCM plans aligned with Business Continuity Management(BCM) plans
• Complete regular Business Impact Analysis(BIA) exercises
• Conduct regular Risk Analysis and Risk Management exercises
• Negotiate contracts with suppliers for provision of recovery capability
• Assess impact of changes on Service Continuity/
Recovery plans

• Business Impact Analysis(BIA): Quantifies the impact to


business that loss of service would have
• Hard impact: can be precisely identified/measured
(financial loss, law breach)
• Soft Impact: (damaged reputation, loss of competitive advantage)

• Risk Assessment: three steps of risk assessment


• Identify Risk
• Analyze Risk
• Manage exposure to Risk
• PROCESS: INFORMATION SECURITY MANAGEMENT
• Objective : to protect the organization and communications systems from harm resulting from failures
of confidentiality, integrity, availability (CIA).
• The business defines the level of protection provided by Information Security Management
(which processes are related to Information Security Management? Access Management, Availability Management)
• PROCESS: SUPPLIER MANAGEMENT
• Objectives : Obtain value for money from suppliers and contracts
• Ensure contracts are aligned to business needs
• Manage supplier performance
• Negotiate and agree contracts with suppliers
• Manage Underpinning Contracts (third party contracts) and ensure they are aligned with SLAs
• Maintain a supplier policy and a supporting Supplier and Contracts Management Information System (SCMIS)
• Supplier Management spans the entire lifecycle
(what’s the name of the database that tracks the supplier/contract information? Supplier and Contract Management Information System(SCMIS))

• PROCESS: DESIGN COORDINATION


• Objectives : Ensure consistent design of services, service management information systems and tools, architectures,
processes and metrics
• Coordinate all design activities across projects, changes, suppliers, and support teams(and manage schedules, resources
and conflicts where required)
• Produce Service Design Packages
• Manage and improve the performance of the entire Service Design stage
Service Design Deliverables:
• Service solution that satisfies the documented needs of the business (from Service Strategy)
• Complete Service Design Packages to be handed to Service Transition
• Compiled by Design Coordination process manager, input from IT personnel from Technical Management function, Application Management, IT Operations
Management, Service Desk, process owners, service owners and input from business.
(which needs to be in the service design package? all)
Service Lifecycle- SERVICE
TRANSITION
• Service STAGE
Transition Main Objectives:
• To ensure that service changes deliver the expected business value
• Manage risks related to new, changed, retired services
• Plan and manage service changes efficiently and effectively
• Successfully deploy service releases into supported environments
• Set correct expectations on performance and use of new or changed services
• Provide good quality knowledge and information about services and service assets
• Service Transition-Value to business:
• Achieve higher volumes of successful change
• Enable asset sharing and reuse across projects and services
• Reduce delays from unexpected clashes and dependencies
• Improve expectation setting for all stakeholders
• Increase confidence that new or changed service can be delivered to specification and
without unexpectedly affecting other services or stakeholders
• PROCESS: SERVICE ASSET AND CONFIGURATION MANAGEMENT
• Deciding which CI’s to record depends on how much effort organization want to put towards SACM
• CI several types (hardware, software, people, documentation)
• CI recorded in CMDB and managed through Configuration Management System (CMS)
• Each CI record has information (attribute) and history (status)
• CI’s have relationships (is a parent of, is a child of, is installed on, is the documentation of)
• Configuration Item(CI): Any service asset which is to be under the control of Configuration Management (definition)
• Configuration Management Database (CMDB): Database used to store CI records throughout their lifecycle (definition)
• Configuration Management System (CMS): Set of tools, data, information for collecting, storing, managing, updating, and
presenting information about CI’s and their relationships (whenever you see relationship think configuration management )
• Configuration Baseline: measurement or snapshot of systems configuration, used for later comparison and as possible
rollback point

• Objectives :
• Identify, control, record, report, audit & verify services & other Configuration Items including their versions, baselines,
constituent components, attributes & relationships (relationships is related to configuration management)
• Account for, manage & protect the integrity of CIs through the service lifecycle by working with change management to ensure
only authorized components are used and only authorized changes are made
• Maintain accurate configuration information on historical, planned & current state of services & other CIs
• Provide accurate configuration information to other processes to help people make decisions at the right time
• Definitive Media Library DML: Secure library that stores official, authorized versions of all electronic media CI (authorized
software, licenses/activation keys, master copies of controlled documentation) Never Backups
• Release and Deployment Management installs only from DML (what's the process that owns and manages the Definitive Media Library? Service Asset and
Configuration Management SACM)

• Change Management approves what goes in


• Configuration Management System: system used to manage the information under SACM
• Contains details of all the components of IT infrastructure
• Maintains relationships between CIs and other pieces of data
• Manages & compiles information from CMDBs and other data sources
• Contain corporate information about customers and users
• When possible, automated tools should be used to populate it and pull information from it
• After change, the Change Manager provides list of changed CIs to the Configuration
Librarian so these can be immediately updated into CMDB/CMS

PROCESS: CHANGE MANAGEMENT


• Objectives :
• Respond to the business and IT requests for change that will align the services with the business needs
• Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested,
implemented, documented and reviewed in a controlled manner
• Ensure that all changes to configuration items are recorded in the configuration management system by the
Configuration Librarian
• Change Management Scope: changes to all architectures, processes, tools, metrics, documentation as well as changes to
IT services and other configuration items (CIs)
• Out of scope: changes to business processes/strategies
• Changes typically written/submitted on a Request for Change (RFC) form
• Three types of Changes :
• Normal changes: (Change Advisory Board CAB)
• Defined by each organization
• Assessment requirements defined for each type
• Emergency changes: (Emergency Change Advisory Board ECAB)
• Must be introduced as soon as possible
• Usually handled by a specific procedure for handling Emergency changes
• Standard changes:
• Pre-authorized change that has an accepted and established procedure or work instruction. Low risk, often low-cost, commonly-occuring
• Authorizing Changes :
• Change Advisory Board (CAB) : A group that exists to help the Change Manager assess, prioritize and authorize changes of a larger nature
• Has sufficient authority and experience to judge decisions for the company
• Consists of IT, Business and Supplier personnel, process owners and technical staff as needed

• Emergency Change Advisory Board (ECAB) : subset of CAB, helps asses and approve emergency changes
• Membership maybe chosen on the fly, depending on the nature of the emergency
• The appropriate Change Authority authorizes changes
• A Change Model is a set of pre-defined steps to take to handle a particular type of change in an agreed way. (whenever you see
model look for predefined in the answer )

• Change Model includes:


• Steps should be taken to handle the change
• The chronological order in which these steps should be taken
• Responsibilities- who should do what (including who will authorize change)
• Timescales and thresholds for completion of actions
• Escalation procedures- who should be contacted when

• Remediation (The Backout Plan) :


• Changes should not be approved without explicit plans in case things go wrong and the change has to be backed out
• Some changes cannot be backed out. A plan is required to address the situation
• The remediation plan must be evaluated before change is approved

• PROCESS: RELEASE AND DEPLOYMENT MANAGEMENT


• Scope:
• Includes all processes, systems and functions to package, build, test and deploy a release into live use, establish the service specified in the service
design package (SDP) and formally hand over the service to the service operation functions.
• The scope includes all configurations items required to implement a release, for example:
• Physical assets (server or network)
• Virtual assets (virtual server or virtual storage)
• Applications and software
• Training for users and IT staff
• Services including all related contracts and agreements
• Objectives :
• Create, test, deploy release packages from DML into live environment following agreed plan and schedule
• Define & agree release deployment management plans with customer and stakeholders
• Ensure all release packages can be tracked, installed, tested, verified and/or uninstalled or backed out if appropriate
• Ensure new or changed service and its enabling systems, technology & organization are capable of delivering the agreed utility and waranty
• Knowledge transfer
• To the customer & users so they can use the service to support their business activities
• To the service operation functions to enable them to effectively and efficiently deliver, support & maintain the service according to
required warranties and service levels
• (if mistakes then both: change manager accountable for approving change without ensuring release and deployment fulfilling
their part in training IT staff, release and deployment manager responsible to train IT staff)

• PROCESS: KNOWLEDGE MANAGEMENT


• Objectives:
• Improve the quality of management decision-making by ensuring reliable and secure knowledge, information & data is available throughout the
service lifecycle
• Maintain service knowledge management system (SKMS) that provides controlled access to knowledge, information and data that is appropriate
for each audience and through the service provider organization
• DIKW Model:
• Data: single point on chart or number
• Information: relationship between data points
• Knowledge: information combined with experience and insight=ability to take action
• Wisdom: strong common-sense judgement
• CMS (Configuration Management System)
• SCMIS(supply contracts management information system)
• AMIS (availability management information system)
• CMIS (capacity management information system)
• SMIS (security management information system)
• CMDB (configuration management databases)
• DML (definitive media library)
• CSI Register
• SKMS needs to access also external data:
• Experience and certification of staff
• Peripheral matters
• User skill levels and special needs

• Wisdom does not reside in a tool

• SERVICE TRANSITION DELIVERABLES (there is no such thing in ITIL as Service Transition Package )
• An installed service that the business can use
• If service is going to be installed with known bugs, IT must document them with proposed path date(s) . The business must sign of formally
acknowledge/accepting the bugs
• All handover activities
• All documentation which shows what this service will look like now that its operational and in production
• Training for users
• Training for support staff
• Operational run books for support staff
Service Lifecycle- SERVICE OPERATION
STAGE
• Purpose & Objectives
• To coordinate & carry out activities & processes required to deliver & manage services at agreed levels to business users & customer
• To manage technology used to deliver & support services
• Minimize the impact of outages
• Ensure that access to agreed IT services is only provided to those authorized
• Provide operation results (reports & metrics) for services, components & processes
• Analyze these reports and metrics in next lifecycle stage (Continual Service Improvement)

• SERVICE OPERATION: value to business (from customer viewpoint, Service Operation is where the value is finally seen)
• Reduce costs through optimized handling of service outages and identification of their root causes
• Reduce duration & frequency of service outages
• Monitor & measure, providing operational results & data that can be used to justify investments in improvements
• Provide quick & effective access to standard services
• Automate some operations, allowing people to focus more on innovative work

• Communication in Service Operation


• Routine operational communication
• Shift changes
• Communication related to changes
• Project updates
• Communication related to outages, exceptions & emergencies
• Training
• Performance reporting
• Communication Guidelines
• All communication must have purpose or resultant action
• Information should not be communicated unless there is a clear audience
• Define communication requirements in SOPs. Examples:
• All change related communications must be sent by email
• Fill out this report at the handover of every shift

• ITIL’s FUNCTIONS
• Technical Management:
• Provides detailed technical hands-on skills & resources to support the IT Infrastructure
• Custodian of technical knowledge & expertise related to managing IT infrastructure (what is the definition of Technical Management
function)
• Provides resources to support the IT Service Management lifecycle
• Help come up with long term technical strategy
• Design technical details of IT services
• Transition technical components of IT services to production
• Operate IT services by supporting the technology
• Continually improve IT services & components
• Helps plan, implement, maintain stable technical infrastructure to support organizations business processes
• Application Management:
• Responsible for managing applications throughout their lifecycle; also supports & maintains operational applications
• Custodian of technical knowledge & expertise related to managing applications
• Provides actual resources to support the IT Service Management lifecycle
• Help come up with long term application strategy
• Design application-related details of IT services
• Transition application-related components of IT services to production
• Operate IT services by supporting applications
• Continually improve IT services & applications
• Ensure that required functionality is available to achieve required business outcome

• IT Operations Management:
• Responsible for ongoing day-to-day “behind the scenes” management & maintenance of organizations IT infrastructure
• IT Operations Control: Oversees the execution & monitoring of the operational activities & events in the IT infrastructure
• Console Management (monitoring)
• Operations bridge/network operations center
• Job scheduling
• Backup and restore
• Print & output management
• Event management
• Facilities Management: refers to management of physical IT environment , typically datacenter or computer rooms & recovery
sites along with all the power and the cooling equipment
• Service Desk-Objectives:
• Logging all incidents/service request details
• Providing first line investigation & diagnosis
• Resolving incidents/service requests they are able; escalating those they cant within agreed timescales
• Keeping users informed of progress
• Closing all resolved incidents & service requests
• Conducting user satisfaction surveys and callbacks

• Service Desk Structures:


1. Local Service Desk Physically located at every customer site. Agents typically receive & manage calls from that site only
2. Centralized Service Desk One physical Service Desk (center) supports multiple Customer sites/locations
3. Virtual Service Desk service desk personnel located anywhere but access the same system using common processes & procedures
4. Follow the Sun may be used 7 x 24 x 365 extended coverage, based on Virtual Service Desk model

• Service Operation Processes: (IPARE)


• Incident Management
• Problem Management
• Event Management
• Access Management
• Request Fulfillment
• PROCESS: EVENT MANAGEMENT (tip for exam, look for word monitoring then its related to event management)
• Objective: the ability to detect events, make sense of them, determine appropriate control action
• Scope: can be applied to any aspect of Service Management that needs to be controlled and which can be automated
• CIs (send/receive pings to determine if that device is alive)
• Environment conditions (smoke/fire/flood detectors)
• Software license (compliance/allocation)
• Network security (intrusion detection)
• SLA targets, (ticket has failed)
• Event: a change of state that has significance for the management of configuration item (CI) or an IT service
• Informational: signifies regular operation
• Warning: signifies unusual operation
• Exception: signifies abnormality; usually triggers incident/change
• Alert: notification that threshold has been reached, something changed, or failure occurred. Alert requires person or team to react.

• PROCESS: INCIDENT MANAGEMENT (tip for exam, look for word fast or quickly as possible then its related to incident management)
• Purpose is restore normal service operation as quickly as possible. “Normal” is defined as service operation within SLA limits
• Incident: unplanned interruption to IT service or reduction in quality of IT service. Failure of configuration item that has not yet impacted
service is also an incident
• Incident Model: predefined template for handling commonly occurring incidents (in exam could be asked what would be in incident model)
• Chronological order steps should be taken
• Responsibilities ; who should do what (RACI chart could be handy here)
• Precautions taken before resolving the incident such s backing up data
• Timescale and threshold for completion of actions
• Escalation procedures; who should be contacted and when
• Major Incidents: usually effects a large number of users and/or severely impacts a critical service and s given higher priority
• Major incident have shorter timescales, greater urgency, and often their own separate procedure for handling them (in exam what makes major different)

• Scope: can be applied to any aspect of Service Management that needs to be controlled and which can be automated
• CIs (send/receive which disrupts or could disrupt a service
• Communicated to service desk by:
• Users
• IT staff
• Event monitoring tools (not all events are incidents)
• Incident Management is highly visible to the business, it’s therefore easier to demonstrate it’s value than most areas in Service
Operation
• Incident Management is often one of the first processes to be implemented
• Prioritization:
• Impact: Effect of incident upon business; deviation from normal service level
• Urgency: How long until there is significant impact on business
• Priority: Order in which calls are processed, based on impact and urgency
Priority= Urgency + Impact
Functional escalation(knowledge-across the org chart)
Hierarchic escalation (authority-up the org chart)
(in exam may have question regarding the steps)
• Identify: End Users (email, phone, self service desk)
• IT staff (phone, self service desk)
• Event monitoring tools
(all incidents must be fully logged!)
• Resolution and Recovery- any one can resolve issue
• Incident Closure- only service desk can close incident

• PROCESS: REQUEST FULFILLMENT


• Scope: up to organization to define which requests
will be addressed via Request Fulfilment process
• Service request: user needs something from IT but nothing is broken (not incident)
• low risk, frequently occurring, low cost request
• Password resets, install additional standard software, relocate PC (Access to IT service)
• User need information, documentation or advice
• Because of their frequency and low risk better to handle in separate process rather than disturb incident and Change Management process
• Objectives:
• Maintain user & customer satisfaction through efficient & professional handling of all service requests
• Provide a channel for users to request and receive standard services for which a predefined approval & qualification process exists
• Provide information to users & customers about availability of services and procedure for obtaining them
• To source & deliver components of requested standard service (licenses, software media)
• Assist with general information, complaints or comments
• PROCESS: PROBLEM MANAGEMENT
• Objectives:
• Find root cause of problem
• Find solution to problem
• Submit a Request for Change so problem can be resolved via Change Management & Release and Deployment (install or deploy fix)
Management processes
• Prevent problems & resulting incidents from happening (Proactive Problem Management)
• Eliminate recurring incidents
• Minimize impact of incidents that cannot be prevented
(incident management & request fulfilment interacts with end users, problem management invisible to end users – in exam careful not to
choose answer with end user for problem management since its invisible to them)
• Problem: unknown root cause of one or more incidents
• Workaround: temporary way of overcoming technical difficulties
• Known error: known root cause of one or more incidents
• Known Error Database (KEDB): database containing all known error records. It is part of CMS
• Known errors can be raised anytime in problem management process
• If it would be helpful for Service Desk (or any resolver group) to see KE info in KEDB as they try to diagnose incidents, ask Problem Manager to put it there
• Problem Management provides known errors for faster incident resolution through workarounds that can be used to restore service
• Only Problem Managers can populate KEDB, this keeps it clean
• Problem Management is typically reactive, it responds to recurring incidents and seeks to find root cause
• Proactive Problem Management: look for trends
• Incidents & events are almost always input to Problem Management
• Using same categories as
incidents management
easier to find trends

• Prioritize based on
urgency & impact
• Major Problem Review
• Similar to Major incidents, only your organization can determine what counts as Major Problem and how exactly they should be handled
• All Major Problems should be followed up with a Major Problem Review, facilitated by the Problem Manager
• What things were done correctly?
• What things were done wrong?
• How can this be prevented from happening again?
• How can we do better in the future?
• Was there some third-party responsible? Should we follow up?
(relationships: incident management->problem management->change management->release & deploy management)

• PROCESS: ACCESS MANAGEMENT


• Purpose: provide the right for the users to be able to use a service or group of services. It’s the execution of policies and actions defined in information security
management
• ACCESS MANAGEMENT TERMS: (in exam remember these access management terms “RAIDS”)
• Access: level and extent of a service’s functionality or data that a user is entitled to use
• Identify: information about them distinguishing them as an individual and which verifies their status within the organization
• Rights (privileges): actual settings whereby user is provided access to service or group of services
• Service Groups: most users don’t use only one service, users performing a similar set of activities will use a similar set of service
• Directory Services: refers to specific type of tool that is used to manage access and rights

• Service Operations Deliverables:


• Services that are being delivered to customers and users as stated in SLA
• SLA reports delivered to customers as often as stated in SLA
• Performance Reporting / Metrics (Analyze these reports and metrics in next stage: Continuous Service Improvement)
• For services and components and all processes
Service Lifecycle- CONTINOUS SERVICE IMPROVEMENT
STAGE
• Purpose: continually align IT services to changing business needs
• CSI is always seeking ways to improve service effectiveness, process effectiveness and cost effectiveness
• CSI Scope: provide guidance in: (in exam CSI improves everything so choose all of above as answer)
• Overall health of ITSM as a discipline
• Continual alignment of service portfolio with current & future business needs Group CSI Initiatives:
• Small, medium, large
• Continual improvement of all aspects of IT service and the service assets that support them
• Priority 1, 2 and 3
• CSI Objectives: • (or whatever works for you)
• Make recommendations on improvement opportunities for all lifecycle stages
• Review and analyze service level achievement
• Identify & implement activities to improve IT services and processes
• Improve cost effectiveness without sacrificing customer satisfaction
• Choose & employ quality management methods
• Understand what to measure, why its measured, and what success looks like
• CSI value to business: adopting and implementing standard and consistent approaches for CSI will:
• Ensure IT services remain continuously aligned to business requirements
• Result in gradual improvements in cost effectiveness through a reduction in costs and/or capacity to handle more work at same cost
• Identify improvements in organizational structure, resourcing capabilities, partners, technology, staff skills, training, communication
• CSI Register: provides coordinated, consistent view of your organizations improvement activities/initiatives, is part of SKMS
• CSI Manager has responsibility and accountability for production and maintenance of CSI Register
• The Deming Cycle (Measuring/Improving Quality)
• Plan- Do- Check- Act (slow, steady, ongoing, step-by-step improvement)

• The CSI Approach


• On exam; what do we mean by “where do we want to be” question? Set measurable targets by agreeing on priorities for improvements (the
question came in exam but opposite)
• On exam; which step is missing
• On exam; which ITIL CSI approach contains how to keep the momentum going
• The Seven-Step Improvement Process
• CSI Metrics: CSFs and KPIs
• Critical Success Factors (CSFs)
• Something that must happen if Process, Project, Plan or IT service is to succeed
• KPIs are used to measure achievement of CSFs
• Key Performance Indicators (KPIs)
• Are metrics which show motion or trends
• Prove if we achieved our CSFs
• Can be both qualitative or quantitative (could KPIs be qualitative or quantitative?)
• KPIs should be tied to CSFs
• Three types of metrics (what are the types of metrics)
• Technology metrics: measures component and application based metrics such as performance, availability etc
• Process metrics: CSFs, KPIs and activity metrics for service management processes (determine overall health of a process)
• Service metrics: measure end-to-end service (technology and process metrics are used to compute service metrics)

• CSI Roles
• CSI Manager:
• Accountable for success of all improvement activities
• Communicates CSI vision across IT organization
• Responsible and accountable for production and maintenance of CSI Register
• Defines and reports on CSI CSFs, KPIs and CSI activity metrics
• Coordinates CSI through the service lifecycle
• Build effective relationships with business and IT
• Ensures monitoring is in place to gather data
• Works with process owners and service owners to identify improvements and improve quality

• CSI Deliverables:
• List of improvements we discovered during the CSI activities in this stage
• We will present these back to Service Strategy to begin the lifecycle all over again

You might also like