SlideShare a Scribd company logo
Chief Information OfficersChief Information Officers
(CIO)(CIO)
Module 8
IT SERVICE MANAGEMENT
Objective of Module 8
To present the basic concepts and tools for IT
Services Management within the ITIL Framework
and to explore their applicability in the context of
the E-Government Programme of the Government
of Iraq.
Scope of Module 8
ITIL Framework
IT Service Life Cycle
IT Service Strategy
Service Planning
Service Design and Operations
Service Metrics
EVOLUTION OF ITIL
ITIL - Information Technology Infrastructure Library
History
Originally created in late 80s by the UK government
Now truly global and applicable to all IT Services
Focus on process and roles rather than organisation
Version 1 in 1991- focused on UK Government
Version 2 in 2000 - Industry wide and took into account changes in
technology
Version 3 in June 2007 – Life Cycle Approach
OGC
Office of Government Commerce – UK Treasury ministry
ITSMF
The driver behind all things ITIL taken over from OGC
Global
 USA, Canada, Mexico, Argentina, and Brazil - Americas
 Australia, India, Singapore - Asia Pacific
 Denmark, France, Germany, Netherlands, Sweden, UK - EMEA
Is a collection of books which contain
recommendations & suggestions to improve
provision of IT Services
Not a standard but a Best Practices Framework
Needs to be adopted and/or adapted
ITIL …
Benefits of ITIL framework:-
increased user and customer satisfaction with IT
services
improved service availability, directly leading to
increased business profits and revenue
financial savings from reduced rework, lost time,
improved resource management and usage
improved time to market for new products and
services
improved decision making and optimized risk.
Standards based on ITIL
ITIL
BS 15000 ISO 20000
•BS15000 the first standard derived from ITIL
•ISO 20000: ISO standard derived from ITIL
SERVICE LIFE CYCLE APPROACH
The Four P’s
The implementation of ITIL as a practice is about
preparing and planning the effective use of The Four
Ps:
People
Processes
Products
Partners
FOCUS AREAS
Key CONCEPTS.…….
Service & Service Owner
Service Management
Process & Process Owner
Functions, Staff, Roles
Metrics, Interfaces
RACI
PDCA
Compliance & Governance
Concept of Caps
RESPONSIBILITY ACCOUNTABILITY CONSULTED INFORMED
MATRIX
Key:
R = Responsible; performs the task
A= Accountable; ultimately answerable for
completion of task (only 1 person per task)
C= Consulted; provides information or
assistance
I = Informed; kept apprised of the activity LOS Mgr PM SDM Client
1.1 Internal Kick off A
1.2 Offshore Resource requirement
projection/Approval
A R I
1.3 Travel Plan A
1.4 Resource Readiness R A
1.5 Knowledge Transfer (KT) Transition C I C
1.6 Conduct Lesson learned C A C
1.7 Sign off R A R
Continuous step by
step improvement
Consolidated of the
level reached
(e.g. ISO 9001)
PLAN DO CHECK ACT (Deming’s Cycle for Improvement)
STORY TIME
Module 8 presentation it services
1. SERVICE STRATEGY
ACTIVITIES OF SERVICE STRATEGY
Identify market & define your target area
Decide what services you want to offer & who can be
the potential customers
Develop your service offerings
Build on/improve your services
Develop strategic assets
Develop new services
Help clarify the relationships between different services,
processes, strategies etc.
SERVICE STRATEGY
1.Demand Management
2.Service Portfolio Management
3.Financial Management
SERVICE STRATEGY 1 OF 3
DEMAND MANAGEMENT
Simply Speaking
Demand Management = Know your customer and
then identify his / her requirements
BASIC CONCEPTS OF SERVICE STRATEGY
Utility – It is derived from the attributes of service which have
a positive effect on the performance
What does the service do?
Functional requirements
Features, inputs, outputs
Fit for purpose
Warranty – It is derived from positive effect being available
when needed, in sufficient capacity & magnitude &
dependably in terms of Continuity & Security
How well service does it
Fit for use
OBJECTIVES
 To understand customer’s current requirements
 Trend of requirements over a period/business cycle
 Match the customer’s expectations with organization's
capabilities of providing services
 Ensure Warranty & Utility are in alignment with customer’s
needs
KEY CONCEPTS
• Core service vs. Supporting Service
• Pattern of Business Activity (PBA), User profile
• Service Package (SP) vs. Service Level Package (SLP)
• Business Relationship Management
Core Service vs Supporting Service
Core Service is the service which actually brings ‘value’ to the
customer.
It’s a service which is KEY from organization's perspective as
well
E.g. for a Banking customer, the core services provided will be
all financial services
Supporting Service ‘supports’ or enhances the core services
It’s like an added feature which may not be desired but
important to have
Many times it becomes necessity
E.g. supporting services in above case could be providing a
helpdesk which helps/troubleshoots any issues/queries faced by
Pattern of Business Activity (PBA) & User Profile
Represents change in pattern of customers demands as
explained by organization
Important to track as it helps organization identify
improvements in existing services or identify future
opportunities
Also important to study customer’s business & changing
business needs
User Profile
Demand patterns shown by users
Users means people or even processes/functions etc.
Is usually associated with/is subset of PBA
SP vs SLP
Service Package is a bundle of core services and/or
supporting services which is offered to customer
SP Includes Service Level Package
SLP has a defined level of Utility & Warranty for a
given SP
E.g. Buying 100 servers is a SP deal but some of
them could be under Gold/Silver SLP
Business Relationship Management
Customer centric activities
Constant communication with customer
Helps to know the improvements & future scope for
business
Usually the First Point of contact for the customer
especially for a first time/new business
METRICS
• Accurate understanding of customer’s business needs
• Loss of Business to competitors especially for a new
services
• Improved Customer Relationships
ROLES & RESPONSIBILITIES
Business Relationship Manager
Documenting the customer’s business needs, PBAs,
User Profile etc.
Ensure SLP matches customer’s needs
Discussions with internal teams for setting up new
SLPs or establishing the existing once
Analyze potential SLP improvements ,
Look for future business opportunities with customer
He may have a team working with multiple customers
SERVICE STRATEGY 2 OF 3
SERVICE PORTFOLIO MANAGEMENT
Simply Speaking
SPM = How to bundle/package the services
OBJECTIVES
• Plan for services you can offer
• Record of all the services including current, expired &
in Pipeline
• Provide information/guidance to Service Design
KEY CONCEPTS
• Service Portfolio, It’s Components & structure
• Business Service, Business Service Management
• Business Service vs. IT Service
Service Portfolio
It describes how the services are bundled & packaged
Takes care of Marketing components such as
What is the REASON customer will buy these
services?
What is the REASON customer will buy these
services from US?
SWOT analysis for our Organization’s service
capabilities
What could be our pricing models
How best to allocate resources & capabilities
ACTIVITIES
• DAAC (Based on DMAIC cycle)
• Define
• Take Service Strategy as input, Define Inventories, Business Case,
Validation of Data
• Analyze
• Decide Value Proposition, Prioritization, Balance of Demand &
Supply
• Approve
• Authorize / Finalize the Portfolio, Services, Resources
• Charter
• Communicate information / decisions, Resource allocation,
Chartering of services
• Continually Update/ Improve the portfolio – begins next DAAC
METRICS
• How Accurate & Up-to-Date Portfolio is
• Is the information contained is relevant from Market
perspective
• Is it in alignment with customer needs
ROLES & RESPONSIBILITIES
• Product Manager
• Create Business case
• Evaluate Marketing Opportunities
• Deploy new services/retire the old ones
• Manage a set of related services
• Business Relationship Manager
• First Point of Contact
• Document Customer needs
SERVICE STRATEGY 3 OF 3
FINANCIAL MANAGEMENT
Simply Speaking
Financial Management = Getting the Deal ($$$) right
OBJECTIVES
To serve as strategic tool to align IT services with
Financial Decisions
To balance the Cost & Price as appropriate
Accounting for IT Services
Facilitate Accurate Budgeting
Finalize Financial Policies (e.g. Charging)
Financial Review & Control
COST VS PRICE
Cost = Actual Expenditure of providing IT Services
Price = The amount at which one Sells IT Services
Hence Price – Cost = Profit
KEY CONCEPTS
Service Valuation (Previously known as Charging)
Service Investment Analysis (Previously known as
Budgeting)
Accounting
SERVICE VALUATION (CHARGING)
A mechanism which helps organization to recover at
least the expenditure incurred on providing IT services
with additional monitorial profits as applicable
Types
◦ Cost Recovery (Actual)
◦ Cost Plus Fixed Fee
◦ Cost Plus % of Costs
◦ Cost Plus Incentives
◦ Notional Charging
◦ Fixed Price
◦ Time & Material
SERVICE INVESTMENT ANALYSIS
• Was termed as Budgeting in v2
• It is a Time phased allocation of Funds
• It helps Track & Control the expenditure pattern
• Also guide how to utilize the funds
ACCOUNTING
A mechanism to track WHAT has been spent & WHERE it
has been spent
Maintain accounts of all incoming and outgoing
monetary fund
ACTIVITIES
• To design mechanisms for service valuation,
Investment Analysis & Accounting
• To align IT Business with Finance Policies
• Ensure the accuracy in implementing financial controls
• Bill Payments & Collections
• Updating the Finance Policies as per Organizational
needs
METRICS
Accuracy in Budgeting, Forecasting & Controls
Quick & Effective financial decision making
Proper IT Accounting
Ensure Timely Bill Payments & Collections
Overall performance of Finance Dept.
ROLES & RESPONSIBILITIES
Finance Manager / Dept./ Controller
To Lay Financial Policies & document
To ensure that the policies are adhered to
Implement proper financial controls
Look for Continual Improvement
Note – Every individual manager has some financial
responsibility within his area of control
2. SERVICE DESIGN
ACTIVITIES
• Design services to meet Business Objectives
◦ Design Secure & Resilient IT Infrastructure
◦ Identify, remove the risks from the services before they go
live
◦ Create & maintain IT plans, policies, technical & process
framework (Design tool ensures standards are adhered to)
◦ Design measurement methods & metrics for assessing
effectiveness of processes
◦ Design Effective & efficient processes for design, transition
& operation phases
◦ Scope includes new services & improvements as may be
needed over a service lifecycle
SERVICE DESIGN
Service Catalog Management
Service Level Management
Availability Management
Capacity Management
Supplier Management
Information Security Management
Service Continuity Management
SERVICE DESIGN 1 OF 7
SERVICE CATALOG MANAGEMENT
Simply Speaking
Service Catalogue Management = Services Ready to
Use
OBJECTIVES
Create & Manage Service Catalog
Keep Service Catalog Up to Date with latest information
Continual Improvement in Management of Service
Catalog
KEY CONCEPTS
What is Service Catalog?
Service Catalog vs. Service Portfolio
Types of Service Catalog
• What is Service Catalog?
◦ A single source of information for all the service offerings
◦ Includes Operational & in Transition Services
◦ E.g. Menu Card in a Hotel
• Service Catalog vs. Service Portfolio
◦ Service catalog is a part of Service Portfolio
◦ Service Portfolio depicts the services in their Business Value
Terms i.e. Why customer would buy it from us
◦ Service Catalog depicts what service would you like to offer
to customer (which will be based on customer needs)
◦ Service Portfolio is not usually available to be viewed by
Customer or public whereas Service Catalog may be
Types of Service Catalog
Business Service Catalog
Used by Relationship Manager to win a business
Consists list of all IT services which are important for
Customer’s Business Process
Visible to customer (or even to common public)
Technical Service Catalog
Used by Relationship Manager to know the capabilities
& limits of Business Service Catalog
Contains all the Backup/Supporting services for
services shown in BSC
METRICS
Accuracy of Information within Service Catalog
Number of corrections made
Customer Feedback
Number of successful / lost proposals
ROLES & RESPONSIBILITIES
Service Catalog Manager
Establish & maintain Service Catalog
Ensure all the information is accurate & up-to-date
Oversee all the other aspects of service catalog. E.g.
Information contains all applicable operational & in
Transit services etc.
Work on Continual Improvement of Service Catalog
SERVICE DESIGN 2 OF 7
SERVICE LEVEL MANAGEMENT
Simply Speaking
Service Level Management = Negotiate & Agree
Service Levels with client
OBJECTIVES
To Negotiate, Agree & Document the Service Levels
To balance the customer expectations &
organization’s capabilities
To measure, report & continually maintain/improve
service level
To manage the performance as per agreed service
levels
To manage the customer relationship
Service Scope and description
Service hours
Measures of availability and reliability
Support details – who to contact, when and how
Respond and fix times
Deliverables and time scales
Change approval and implementation
Reference to IT Service Continuity Plan
Signatories
Responsibilities of both parties
Review process
Glossary of terms
ELEMENTS OF SLA
SLA,OLA,UC
Organization Management
Customer
Org’s Internal Teams
Vendors
SLA
OLA
UC
METRICS
Clearly Defined SLAs, OLAs and UCs
Performance against agreed SLAs
Shortfalls in SLA and consequent SIPs
Number & severity of service breaches
Improvement in customer satisfaction
ROLES & RESPONSIBILITIES
Service Level Manager
Process Owner
Review & Reporting
Maintaining an effective Service Level Management
process by defining SLAs, OLAs and UCs
Updating the existing SLAs, SIPs, OLAs and UCs
Reviewing and improving the performance of the IT
organization to meet agreed service levels
SERVICE DESIGN 3 OF 7
AVAILABILITY MANAGEMENT
Simply Speaking
Availability Management = Ensure IT is working as
agreed
OBJECTIVES
To ensure agreed Availability Level is met or exceeded
The Availability Management process plays an
important role in ensuring that a defined level of IT
services is continuously accessible to customers, in a
cost-effective manner
Continually Optimize & Improve the availability by
preparing Availability Plan
Availability
Reliability
Maintainability
Serviceability
Vital Business Function (VBF)
High Availability
Fault Tolerance
KEY CONCEPTS
• The ability of a service, component or
configuration item to perform it’s agreed &
expected function when required
• Usually expressed as Percentage
Availability= (AST-DT) X 100
-----------------
AST
AST = Agreed Service Time
DT = Downtime
AVAILABILITY
Reliability
Implies how long the specified service is available
for the required period without any interruptions
or failures
Serviceability
Ability of the 3rd
party supplier to provide the
expected service to service provider
Maintainability (or Recoverability)
How easy it is to maintain or recover a service,
component or configuration item
Availability Metrics
MTRS- Mean Time to Restore Service (Down Time) =
Relates to Maintainability (Also has an element of Serviceability)
Detection
Diagnosis Recover
Restoration
Incident
Occurred
MTBF- Mean Time
Between Failures(Uptime)
= Availability
MTBSI – Mean Time Between system Incidents = RELIABILITY
Time
Incident
Occurred
Repair
Vital Business Function (VBF)
A critical function or business process
High Availability
Minimizing the impact of component failure
Fault Tolerance
Ability of a service to continue to be available even
after component(s) failure
METRICS
• Uptime per service or group of Users
• Downtime duration
• Downtime frequency
• Number of failures beyond ‘X’ time
ROLES & RESPONSIBILITIES
• Availability Manager
◦ Process Owner
◦ Ensure the agreed levels of service availability
◦ Create & manage Availability Plan
◦ Continual improvement in process/results
SERVICE DESIGN 4 OF 7
CAPACITY MANAGEMENT
Simply Speaking
Capacity Management = Ensure IT is sized in optimum &
cost effective manner
OBJECTIVES
Provide the required IT Infrastructure in a cost
effective manner while also meeting it’s
requirements
Ensure optimum utilization of IT infrastructure
Work on current & future needs
Produce & regularly upgrade Capacity Plan
KEY CONCEPTS
Business , Service & Component Capacity Management
Capacity Management Information System
Capacity Plan
Performance Management, Modeling, Application
Sizing
• Business Capacity Management
• Trend, forecast model and developing the Capacity Plan to
understand future business needs
• Modeling to estimate the best alternative for Capacity deployment
• Service Capacity Management
• Understand the functioning of the IT services, resource usage and
variations to ensure that appropriate service agreements can be
designed
• Report on Service profile of use of services, manage demand for
service
• Component Capacity Management
• Using and monitoring of all components of the IT infrastructure
• Optimize use of the current IT resource components such as
bandwidth, network capacity etc.
• Capacity Plan
• Time (or trigger) phased plan to maintain/increase
the utilization of IT Infrastructure by maintaining or
adding IT infrastructure components
• Capacity Management Information System (CMIS)
• A system which holds the data needed &
maintained by all the capacity sub
processes/activities
Performance Management
– Monitoring
– Tuning
Modeling
– Mathematical models for determining the benefits
and costs of varying capacity
– Simulation and Analytical techniques
Application Sizing
– For determining the hardware capacity required to
support new/modified applications
METRICS
Performance trends after estimates
Reduction in rushed purchases
Reduction in expensive overcapacity
Reduction in number of incidents due to
performance plans
ROLES & RESPONSIBILITIES
Capacity Manager
Monitors the Process
Capacity Plan Creation
Update the Capacity Management Database
Supported by
Technical & Application Management
To provide capacity requirements via capacity
incidents & problems
Other day to day capacity management activities
SERVICE DESIGN 5 OF 7
SUPPLIER MANAGEMENT
Simply Speaking
Supplier Management = Manage Supplier Relationship
& Performance
OBJECTIVES
Manage supplier relationship & performance
Ensure the Right & Relevant contracts with supplier
Manage the contracts throughout their lifecycle
Create & maintain Supplier Policy, List & Contracts
Database
Supplier Selection
Request Supplier
Responses
Requirement of 3rd
party supplier
Select Suppliers
Analyze Supplier
Capabilities
Contract with
Supplier (UC)
Supplier provides
Services
Manage Suppliers SCD
Update
supplier’s
records
Supplier – Contracts Database (SCD)
Supplier Contracts
Database
Organization’s Supplier
Policy & Strategy
Contracts categorization
According to Types of services,
Owner, expiry date, value etc.
Fresh/Renewed
Contracts
Existing
Contracts
Records of
Past/Expired Contracts
Contracts Modification/Termination
Supplier’s performance
Against contract terms
METRICS
Relevance of contracts in terms of SLM
Performance of suppliers
Accuracy of information in SCD
ROLES & RESPONSIBILITIES
Supplier Manager
Process owner
Deliver expected supplier performance
Create, establish & maintain SCD
Manage the contracts in conjunction with
SLM
SERVICE DESIGN 6 OF 7
INFORMATION SECURITY MANAGEMENT
Simply Speaking
ISM = Protect your Data & Information
OBJECTIVES
To prevent Unauthorized Access (& allow Authorized
Access)
To provide effective security measures at Strategic,
Tactical & Operational organizational Levels
To enable organization to do a business “Safely”
To comply with Security Requirements as per SLA
KEY CONCEPTS
Confidentiality, Integrity, Availability, Non-
Repudiation
Information Security Policy
Security Analysis & Controls
• Confidentiality
• Information is accessible to only those who are authorized to
view it
• Integrity
• Information, especially while being communicated, is protected
against unauthorized modification
• Availability
• Information is invulnerable to attacks or is recoverable in
secured way i.e. it is available (only to authorized) when it should
be
• Non-Repudiation
◦ Sender of information can not deny that information has NOT
been sent by him
• Information Security Policy
• A policy of an organization which ensures the
compliance to Information Security Objectives &
Guidelines
• Security Analysis & Controls
• To Analyze the threats to organization’s
data/Information & to eliminate/minimize the
same
• To provide security controls (checkpoints) at
various levels so that reduce the impact of security
breaches
METRICS
Effectiveness of Security Measures / Controls
Number of Security Breaches , Attacks
Business Losses incurred due to security malpractices
Adherence /Compliance to Security Standards
Security Audits reports
ROLES & RESPONSIBILITIES
• Security Manager
◦ Process Owner, Planning for Security
◦ Design & Monitor Security Policy / Analysis / Controls
◦ Oversee entire security aspect of the organization
◦ Overall Improvement
• Security Officer
◦ Mediator between Security manager & Customer / Users
◦ Assist Implementation of security policies/measures etc.
SERVICE DESIGN 7 OF 7
SERVICE CONTINUITY MANAGEMENT
Simply Speaking
• Service Continuity Management = Recover from disaster
Z
as per agreed & applicable SLA
OBJECTIVES
• To create & manage IT service continuity & recovery
plans
• To reduce potential disaster occurrence
• To negotiate & manage necessary contracts with 3rd
parties
• Balance SLAs & Cost factors while planning for service
continuity
KEY CONCEPTS
Business Continuity Strategy
Life Cycle Approach to ITSCM
Assessment of Changes for impact on ITSCM
Dormant Contracts
Negotiated/Compromised SLAs
Regular Testing – Ongoing as a part of Lifecycle
approach
LIFE CYCLE APPROACH TO ITSCM
Initiate ITSCM
Gather requirements
Plan for implementation
Implementation
ORR (Operation Readiness Review)
Mock Testing
Go Live /Sign Off for ITSCM Structure
Ongoing regular testing & updates to ITSCM structure
POSSIBLE RECOVERY OPTIONS
• Do nothing
• Manual Workarounds
• Reciprocal arrangements (Less Frequently used)
• Immediate recovery – hot standby (24 hours)
• Mirrored business systems on an alternate site
• Intermediate recovery – warm standby (24-72 hrs)
• Similar to immediate but critical systems need to be
recovered and run
• Gradual recovery – cold standby (72 hrs)
• Empty facility with utilities
• Fortress Approach
• Dormant contracts
• Insurance
• Business Continuity Strategy
• Aims at reducing risks by developing recovery plan(s) to
restore business activities if they are interrupted by a
disaster
• Assessment of Changes for impact on ITSCM
• To study & mitigate the impact of any changes in IT
Infrastructure on ITSCM
• Dormant Contracts
• Contracts with 3rd
parties which become active only when
triggered by a disaster
• Negotiated/Compromised SLAs
• To negotiate appropriate SLAs with customer which will be
applicable only during disaster
METRICS
Number of shortcomings
Cost to company due to loss if no recovery Plan
Cost in Time, resources and money to restore IT
Services
ROLES & RESPONSIBILITIES
ITSCM Manager
Owns entire ITSCM process
To manage & upgrade ITSCM Plans
3. SERVICE TRANSITION
ACTIVITIES
• Plan & Implementation of all the releases /
Services (Applies to new & existing services)
◦ Ensure that the changes as proposed in Service
Design are realized
◦ Authorize, Package, Build, Test & Deploy the
releases into production
◦ Transition of services to & from other
Organizations
◦ Decommission or Termination of services
SERVICE TRANSITION
Service Asset &Configuration Management
Change Management
Release & Deployment Management
Knowledge Management
SERVICE TRANSITION 1 OF 4
SERVICE ASSET & CONFIGURATION MANAGEMENT
Simply Speaking
SACM = Know what you have
OBJECTIVES
Identify, Record & Provide accurate information of the
Configuration Items (CI = IT components)
Provide the Logical Model for IT infrastructure correlating
the IT services & their components
Protect Integrity of the CIs
Create & maintain Configuration Management System
Manage Service Assets (Service CIs)
Perform regular audits / status accounting activities for all
the CIs
KEY CONCEPTS
Configuration Items, Baseline, Variant
Types of CIs
Configuration Management System
• Configuration Item
• A uniquely identifiable entity/item which needs to be
controlled
• Baseline
• Snapshot of a CI or a group of CIs at a given time or stage
• Variant
• A baseline with minor differences
• Configuration Management System
• It is a system which controls & maintains the record if all CIs in
a structured manner in 1 or more databases known as CMDB
• Stores Attributes of CIs, Relationship between CIs
• Consists of Multiple layers like Integration Presentation etc.
CONFIGURATION MANAGEMENT SYSTEM
CMDB1
Services
CMDB2
H/W
CMDB3
Policies
Data/Source information gathering
Knowledge & Logic processing
Presentation Layer /User Interface
NOTE – CMDB can be any Database,
or even Excel File
TYPES OF CIs
• Service Lifecycle CIs
• Business Case, Service Portfolio, Service Design Package
• Service CIs
• Service Capability /Resource Assets, Service Model
• Organization CIs
• Organization Policies, documentations
• Internal CIs
• Internal to individual projects which are required to maintain IT
• External CIs
◦ Customer Agreements & Requirements
ACTIVITIES
Planning
Identification
Status Accounting
Control
Verification and Reporting
Defining the strategy, policy and objectives for the
process
Analyzing the information, Identifying the tools and
resources available for the process
Creating interfaces with other ITIL processes,
projects and third party suppliers
Planning
To identify the associated IT services and components, which
need to be controlled by the Configuration Management
process.
Define the Scope of the process
IT Services, Hardware, Software and Documentation,
Specific Areas
Specify the Level of Detail for information recording
Identify the Relationships of the CIs
Determine the depth of information to be recorded
Naming Conventions, Attributes covered
Identification
The next activity after Identification is Status Accounting of the IT
component through its life cycle. A status code is assigned to each
of the statuses for easy identification.
Typical Statuses
New CIs
In Order, Tested, Accepted
Existing CIs
Received, RFC open for the CI new version requested,
Down, Phased Out, Undergoing maintenance
All CIs
In Stock, Order received, Under test, Released for
Installation, Live, Spare
Status Accounting
Configuration Management controls all the IT
components received by the organization Control.
Who can Access, who can modify
Control
Audit and Verification
• Does the CMDB reflect reality?
• The activities includes verifying and auditing the details in the CMDB.
• For example, audit tools can be used to automatically analyze workstations
and report on the current situation and status of the IT infrastructure.
• Accuracy is improved by
• Active rather than passive CMDB
• Automatic updating
• Integration with other processes
• Automatic checks
Reporting
Assess the efficiency and effectiveness
Through Regular MIS reports
Scheduled reviews of the expected growth in demand of Configuration
management activities
METRICS
Number of occasions on which a
– "Configuration" was found to be unauthorized
– Number of refused RFCs as a result of
incomplete data in the CMDB
– Number of changes to the CMDB because of
identified errors in the CMDB
– Unauthorized IT components detected in use
ROLES & RESPONSIBILITIES
Service Asset Manager
Configuration Manager
These are responsible for their own processes
Implementing policy
Agree scope, processes & procedures
Define necessary controls
Oversee collection & management of data
Audits
Produce management reports
SERVICE TRANSITION 2 OF 4
CHANGE MANAGEMENT
Simply Speaking
Change Management = Minimize the Impact of
Change
OBJECTIVES
Study the adverse Impact of change & minimize it
Create & maintain a Change Management process
Prevent Unauthorized changes
Prepare Change (& Back out) Plans via FSC & provide PSA
Post Implementation Reviews of Changes
Maintain a record of all changes
Note - Change Management does NOT implement change
KEY CONCEPTS
Scope of Change Management
Change Types , RFC, Change Classification & Prioritization,
Change Models
CAB, ECAB, FSC, PSA, Back out Plans
Scope of Change Management
Scope of Change Management process is restricted to
IMAC of IT Infrastructure Components including
documentation
Strategic, Tactical & Operational changes
Out of Scope
Business Strategy & Processes
Implementation of changes
Any other task documented as out of scope
Change Types
• Standard Changes
• Routine Changes that follow an established procedure
& do not disrupt It services
• E.g. updating the Anti-Virus software is a standard
Change
• Emergency Changes
◦ Crucial to an organization and have to be implemented
immediately.
◦ Emergency Changes are disruptive and prone to failure
◦ E.g. the some ports in critical switch has gone down.
Therefore, a new switch needs to be installed
• Request for Change (RFCs)
• Incidents, upgrades to the infrastructure, or changes
in the business requirements generate the need for a
Request for Change (RFC)
• Change Classification & Prioritization
• To classify & plan changes in the order of their impact
& urgency
• Change Models
◦ Predefined way or procedure for handling known type
or complexity
◦ Automated as far as possible
◦ Allow for scalability to create a new model
• Forward Schedule of Changes (FSC)
• Contains details of all approved changes and their
implementation dates for an agreed period
• Detailed short term schedules and less detailed for
longer term planning
• Projected Service Availability (PSA)
• To determine the best time for a change
implementation
• Both the FSC and PSA are agreed with the customers
• Back Out Plan
• It is executed if the Change can not happen as per plan
• Usually but not necessarily the typical back out plan is
to bring the systems back to original state it was in
before the change started
Change Advisory Board (CAB)
CAB approves Changes after assessing and prioritizing the
RFCs.
CAB members should have sound technical knowledge and
good business perspective.
Change Manager is the only permanent member on the CAB &
ECAB
CAB/Emergency Committee
To review urgent changes
Few members required (typically Senior Managers from
concerned dept)
Availability after shift hours
Change Management Process Flow
Request For
Change (RFC)
Change
Manager
Line Manager
Approval
CAB
Meeting
Post Change
ReviewFSC/PSA
Implement
Change
Update CMDB &
Change Records
Failure
Back out Plan
Success
Problem Management
Customer
or other teams
SCM, Capacity, BRM,
ISM,SLM, R&D, Customer etc.
Consult
Invitations as applicable
Customer
Sign Off
ACTIVITIES
Record RFC
Review RFC
Assess & Evaluate Change – 7 Rs of Change
Authorize Change
Issue Change Plan (to R& D Team)
Support/Coordinate Change
Implementation
Post Change Review
7 Rs of Change
Who RAISED it
What is REASON for change
What is the RETURN expected from change
What could be the RISKS involved in change
Which RESOURCES are needed to implement
change
Who (which R&D Team) is RESPONSIBLE for
build, test & implement change
Is there (or what) any RELATIONSHIP between
this change & other changes
METRICS
Number of Rejected RFCs
Number of Incidents occurring due to implemented
Changes
Number of successful changes
Number of unsuccessful changes
Number of backed out changes
Average Time needed to implement a Change
Number of incidents resolved by implementation of
a Change
ROLES & RESPONSIBILITIES
• Change Manager
• Chairperson of the CAB
• Filtering and accepting RFCs
• Primary Responsibility of planning and coordinating implementation of
changes
• Obtaining authorization for change
• Reviewing Implemented Changes
• Convening emergency CAB meetings
• Generating Change Management reports
• May have Change coordinators to support
• CAB Member
◦ Belongs to the CAB and participates in all CAB meetings
◦ Helps in reviewing all RFCs to estimate impact
◦ Participates in Scheduling Changes
SERVICE TRANSITION 3 OF 4
RELEASE & DEPLOYMENT MANAGEMENT
Simply Speaking
R & D Management = Bring in the change Carefully
OBJECTIVES
Implementing the authorized changes as per
Change plan
Plan, Design, Build, Test & Install Hardware &
Software components
Skills & Knowledge Transfer to enable
Customers & users the optimum use of service
Operations & support staff to run & support the
service
KEY CONCEPTS
Release
Release Units
Release Identification
Types of Release
Release Methods
Release
A collection of authorized Changes to an IT Service
A Release is defined by the RFCs that it implements
A Release could consist of a number of Problem fixes
and enhancements to a service.
• A Release unit describes the portion of the IT infrastructure
that should be released together.
• Depending on the type or item of software and hardware, the
size of the unit can vary. An example of hardware Release
Unit can be changes to the complete PC or Processor. An
example of a s/w release unit could be changes made to a
system, suite, program or module.
• Including too many changes in one release can be too
complex for safe implementation while too many releases
affect user dependency on the stability of the service.
Release Units
• The status of a Release alters according to its current
environment. Release identification means
determining the status of a Release in different
environments. The environments in which a Release
can be categorized are:
– Development
– Test
– Live
– Archive
Release Identification
• Depending on the number of changes that should be included in one Release, a
Release can be of the following type:
 Delta Release
 Just a few changes normally a quick fix
 Package Release
 You use a Package Release when you Release a group of software.
Each of the software in the package depends on the other software in
the group for its performance.
 For example, scheduled upgrades to third-party software, such as
Systems software and Office applications are appropriate for Package
Releases.
 Full Release
 When a program is released in its entirety, including the parts that
were not changed.
 A number of similar Changes can be implemented together in this
Release
 More preparation and resources are required for a Full Release
Release Types
METRICS
◦ Number of Incidents by Back Out
◦ Number of accurate and timely release at remote
sites
◦ Number of unused software that have
unnecessary costs, e.g. Licence fees
◦ Number of times unauthorised software is used
◦ Number of times CMDB status is updated/not
updated
ROLES & RESPONSIBILITIES
 The Release & Deployment Manager coordinates the
implementation of the process with other teams.
◦ Prepares Release Plan
◦ Authorises the Release Build and Configuration
◦ Communicates Release to other groups
◦ Coordinated final Implementation of Release
◦ Member of the CAB.
 The Test Manager ensures that the release is tested
and signed off by proper authorities.
◦ Successful testing of the release before sign-off
◦ Ensure Testing environment is same as Live
environment
◦ Preparing roll-out Plan with Release Manager
SERVICE TRANSITION 4 OF 4
KNOWLEDGE MANAGEMENT
Simply Speaking
Knowledge Management = Gather, Analyze, Store &
Share the knowledge
OBJECTIVES
 Improve the efficiency by reducing the need to Re-
discover the knowledge
 Create, Maintain & update Service Knowledge
Management System
 Make sure that a Right & Relevant information at
Right time is available for organization’s
requirements (e.g. Customer details, contract/SLA
data)
KEY CONCEPTS
D-I-K-W Structure
DML
DML & CMDB
SKMS
Data - Information – Knowledge - Wisdom
 Data
◦ A set of discrete facts about the events
◦ Usually large amount of data is/can be
collected
 Information
◦ The data is arranged/sorted in appropriate
context & manner so that it’s easy to
locate/work on
◦ Answers questions like Who, what, when,
where?
Knowledge
Created based on the information/data or own
expertise
Answers How?
Is dynamic & context based
Helps in decision making
Wisdom
Gives detailed understanding
Arriving at the judgment
Helps finalize future decisions/actions
Data - Information – Knowledge - Wisdom
Definitive Media Library
Store Master copies of all the S/W assets
In house, external, Trail, Commercial Of The
Shelf
Licenses, Scripts & codes
Is controlled by Service Asset & Configuration
Management process
Serves as the only source for build & distribution for
Release & Deployment process
DML & CMDB
CMDB stores the information about all the
CIs (H/W & S/W)
DML stores the actual CIs (S/W only)
(earlier DSL and DHS)
Both are controlled by SACM process
Both form part of SKMS
Service Knowledge Management
System - SKMS
Services H/W Policies
Presentation Layer /User Interface
SCDCDBDML
CMS
Service Knowledge Base
Knowledge & Logic Processing
4. SERVICE OPERATION
ACTIVITIES
Keeping services into Operations
◦ Ongoing day to day activities
◦ Ensure that services are delivered at agreed levels
(SLA)
◦ Continual Improvement in meeting the SLAs &
management of operations
Involves Management of
◦ Services
◦ Service Management Processes
◦ People
◦ Technology
SERVICE OPERATION
Service Desk (FUNCTION)
Incident Management
Event Management
Request Fulfillment
Access Management
Problem Management
Technical Management (FUNCTION)
IT Operations Management (FUNCTION)
Application Management (FUNCTION)
SERVICE OPERATION 1OF 9
SERVICE DESK (FUNCTION)
Simply Speaking
Service Desk = Single & the First Point Of
Contact
OBJECTIVES OF SERVICE DESK
To serve as FIRST Point of Contact (FPOC)
Play a vital role in achieving Customer Satisfaction
First Level Fix (FLF) & First Level Diagnosis (FLD)
To coordinate the activities between End User & IT
Service Provision Teams
To OWN the Logged Request & ensure the Closure.
Escalate as appropriate
To support other IT Provision Activities on need
basis
Help Desk Versus Service Desk
End User
Agent
Help Desk
Help Me!!
Reactive
Culture
Focus on
Restoration
Help Desk Versus Service Desk
End User
Agent
Service DeskHelp Me!!
Inform Me!!
Educate
Me!!
Change
Me!!
Service
Me!!
Inspire
Me!!
Proactive
Culture
Business
Focus
Focus on
Preventative
Awareness
KEY CONCEPTS OF SERVICE DESK
Logging the call with service desk
Types/Models/Structures of Service Desk
Skills required for Service Desk Personnel
LOGGING THE CALL WITH SERVICE DESK
Who – End users, All other relevant teams, Events, Service
Desk Team itself
NOTE: Not every call logged is an incident
Why – As a part of responsibility, as a proactive measure
How – Telephone, Emails, Alerts, Web Console etc.
What is an Incident?
An occurrence of event(s) which disrupts or can
potentially disrupt the normal service operation
What is problem?
Unknown underlying cause of one or more incidents
TYPES / MODELS / STRUCTURES OF
SERVICE DESK
Central Service Desk
Local or Distributed Local Service
Desk
Virtual Service Desk
Follow the Sun Model
Specialized Service Desk
CENTRAL SERVICE DESK
Single Service Desk at a possible central location
Can be a group of service desks Integrated at a
single location
Advantage
Cost cutting
Centralized control
Disadvantage
Some Local presence may still be required for
Physical support
Centralized Service Desk
ABC Ltd.
Delhi
ABC Ltd.
Hyderabad
ABC Ltd.
Bangalore
ABC Ltd.
Pune
Helpdesk
011-232425
H
elpdesk
011-232425
Helpdesk
011-232425
LOCAL OR DISTRIBUTED SERVICE DESK
The desk is co-located within or physically
close to user premises
Advantage
◦ Useful in case of multilingual / multi location
organizations
◦ Faster response wherever Physical presence is
necessary
Disadvantage
◦ May prove Expensive
◦ Difficult to manage multiple desks
Local or Distributed Service Desk
ABC Ltd.
Delhi
ABC Ltd.
Hyderabad
ABC Ltd.
Bangalore
ABC Ltd.
Pune
SD
SD
SD
SD
VIRTUAL SERVICE DESK
By using the extensive technology, an appearance of a
single / centralized desk
Primarily used in Off-shoring kind of services
Advantage
Maximum use of technology so minimum personnel
involvement
Less number of requests go Unregistered
Disadvantage
Expensive to use
Physical support may not be possible
Virtual Service Desk
ABC Ltd.
Delhi
ABC Ltd.
Hyderabad
ABC Ltd.
Bangalore
ABC Ltd.
Pune
SD
London
SD
Sydney
SD
Beijing
SD
New York
Network
Cloud
1800XX
1st
Caller
Answer to
1st
Caller
1800XX
3rd
Caller
Answer to
3rd
Caller 1800XX
2nd
Caller
Answer to
2nd
Caller
1800XX
4th
Caller
FOLLOW THE SUN MODEL
24 Hrs of Desk
Team which is in Day time picks up the call
Advantage
◦ Best for 24 Hrs kind of support
◦ Less desk staff attrition due to working time
Disadvantage
◦ Expensive due to use of technology
◦ Multiple control points so difficult to manage
Follow the SUN
Indian Standard Time
Responding SD Region
10 AM 3 PM 8 PM 1 AM5 AM
AUS
USA
EST
UK
IND
USA
PAC
SPECIALIZED SERVICE DESK
Expert Staff specialized in their respective fields
Advantage
◦ Faster & accurate resolution of request
Disadvantage
◦ Difficult to get skilled staff
Specialized Service Desk
Service Desk
Menus
User
calls
DBA
Network
Admin
Windows
Team
Email
Team
NOTE
In practical world, most of the
organizations use a mixture of service
desk types/models/structures.
SKILLS REQUIRED
Communication
Interpersonal Skills
Business / IT Understanding
Professionalism
Customer Focus
Subject Knowledge (for a Specialist Service
Desk)
ACTIVITIES OF SERVICE DESK
Receive & Log the calls from End Users, events etc.
Provide Preliminary level of diagnosis as applicable
Categorize the incident as possible
Assign to relevant Incident Team
Follow up with Incident Team
Update status regularly & communicate to user as
applicable
Keep an eye on agreed SLAs
Escalate as & when appropriate
Confirm with user before closing the incident
Provide Service Desk Metrics Reports to Service Desk
Manager
METRICS FOR SERVICE DESK
Average call resolution/duration
% of calls picked up in 3 rings, % Unattended
Accuracy of updating ticket status
Number of SLA breaches
Timely Escalations
Customer Satisfaction
ROLES & RESPONSIBILITIES IN SERVICE DESK
 Service Desk Staff
◦ To Perform all the activities of Service Desk as
applicable
 Service Desk Manager
◦ To Oversee the functioning of Service Desk
◦ To build Service Desk Team for new services
◦ To Monitor the performance of Service Desk on
regular basis
◦ To identify & work on the Continual Improvement of
Service Desk
SERVICE OPERATION 2 OF 9
INCIDENT MANAGEMENT
Simply Speaking
Incident management = Restore Service ASAP
OBJECTIVES
To restore NORMAL service operation as quickly as
possible
◦ NORMAL means as agreed in SLA
To log & Track incidents wherever applicable (e.g.
Proactive measure)
To deal with all incidents consistently
To assist Problem Management team as required
To assist Service Desk/ Release Team for any RFCs
KEY CONCEPTS
 Incident
◦ An occurrence of event(s) which disrupts or can
potentially disrupt the normal service operation
 Problem
◦ Set of incidents with similar underlying
“unknown” cause(s)
◦ (A root cause of one or more incidents)
 Priority
 Escalation Mechanism
 Incident Lifecycle
Impact
Evidence of effect upon business activities
Urgency
Evidence of effect upon business deadlines
Priority = Impact X Urgency
Functional Escalation
 Through various functions or support group levels
Hierarchical Escalation
 Through organizational hierarchy
Escalation Mechanisms
INCIDENT LIFE CYCLE
Incident Detection & Recording
Classification & Initial Support
Investigation & Diagnostics
Resolution & Recovery
Incident Closure
Request Fulfillment Procedure
Is it a
Request?
Ownership,
Monitoring,
Tracking &
Communication
YES
NO
Incident Life Cycle
MAJOR INCIDENTS
These are incidents which have a short
timescale target & higher urgency
Major Incident NEED NOT BE A Problem
METRICS
Number/Percentage of proactively recorded
Incidents
Average time to resolve Incidents
Number of Incidents/workstation within
SLAs
Percentage of Incidents resolved at First
Line, Second Line Support
Total no. of Remote resolution of Incidents
INTERFACES
Incident Manager : who is the overall in-charge of the Incident
Management process and is responsible for:
Creating Process Reports
Organising Management Information
Recommending measures
Usually this role is assigned to Service Desk Manager
Support Groups
Level 1 to Level n
Tech Specialist Group
Super Users
They act as a link between IT & Service Desk
Manage expectations of users in terms of SLAs & Service Desk
Training & Encouraging users for minor incident resolutions
Involvement in new releases/roll outs
ROLES & RESPONSIBILITIES
SERVICE OPERATION 3 OF 9
EVENT MANAGEMENT
Simply Speaking
• Event Management = Detect Events & decide appropriate
Actions
OBJECTIVES
Detect Events, Make Sense/Analyze them & Decide
the appropriate action
Monitor, Record & filter the relevant events
Trend Analysis as a Proactive Measure/Study
purpose
Contributes to maintain SLAs.
• Event
• A notification or alert created by IT Service, CI or
Monitoring Tool
• Event Management
• A process of managing the events throughout their
lifecycle
• Typically done by IT Operation Staff
• Alerts
• An occurrence of something which triggers event or a
call for action or a human intervention
Information
An event which is only meant to provide
information
E.g. Backup job completed
Usage
To check status of activity, device
To get statistics
Informational events are usually recorded for a
pre-determined period
Types of Events
Type of Events….contd
• Warning
• Event meant as a proactive measure to indicate that
service or device is reaching a threshold
• E.g. Network traffic reaching a congestion point
• Exception
• Event which indicates that a service or a device is
behaving abnormally (against a defined behavior)
• E.g. Hdd1 in RAID has failed
ACTIVITIES
• Recording, Filtering Events
• All Events usually get recorded in a log file
• Events are filtered according to their types either automatically
or manually
• Prioritization of Events
• Events are prioritized based on their importance & their types
• Based on SLAs, some events can always get high priority
• Exceptions Management
• Exception is usually converted into Incident or problem or RFC
• Exception does NOT necessarily represents Incident/problem
METRICS
• Effectiveness of Event Management
• How best are the events designed
• Are they in alignment with SLAs?
• Are they monitored, recorded, filtered correctly?
• How well the events data is maintained
• How many incidents are logged proactively based on
Warnings/Exception
ROLES & RESPONSIBILITIES
• Usually NOT a dedicated role such as Event Manager
• Event Management is conducted by staff in
• Service Desk
• Less Involvement.
• Typically involved for logging incidents based on Exceptions
• Technical & Application Management
• Both Application & Technical Management value add to
event management during Service Design, Service Transition
& Service Operation
• IT Operations Management
• Usually clubbed with Technical or Application management
• Typically do Monitoring & First-Lie responses
SERVICE OPERATION 4 OF 9
REQUEST FULFILLMENT
Simply Speaking
• Request Fulfillment = Provide a quick response to
standard service requests.
OBJECTIVES
• To communicate (or make available) the information
regarding existing Standard services & the procedures
• To provide channel & mechanism for users to avail these
standard services
• Users need to raise a Service Request for the same
• To provide the standard services to users
• May need to work in background as well for e.g.
procurement of h/w (like mouse) for standard services
• To assist for general queries, updates on standard services
NOTE - Request Fulfillment derives guidance from Change Management
KEY CONCEPTS
Service Requests & Standard Service
Components of Standard Services
Request Model
• Service Request
• A request from users for Standard service
• Standard Service
• Typically involves a routine type of change
• Although may be managed by Service Desk, it is NOT treated
as Incident
• E.g. Change of Mouse, Resetting password
• Components of Standard Service
• Pre-defined process
• Some changes can be pre-approved (or Auto Approved) e.g.
Requesting stationary
• Some changes may require additional or special approvals
• Request Model involves a process-flow for Request
Management
• Make Self-Help available
• Typical process flow would be
• User initiates request
• Request is accepted (or rejected as per process) by Service
Desk
• Necessary Approvals (if not pre-approved) are sought by SD
• SD may also order the components (h/w or s/w) if out of
stock
• When approvals and components are ready, SD delivers the
service to user
• Service request is closed by SD
METRICS
User Satisfaction Survey feedback
Number of Requests fulfilled
ROLES & RESPONSIBILITIES
Usually NOT a dedicated role such as Request
Manager
Request Fulfillment is managed by staff in
Service Desk, Incident team or other team as
designated by organization
Typical responsibilities as per Request Process
Flow
Mostly Service Desk Manager is accountable
SERVICE OPERATION 5 OF 9
ACCESS MANAGEMENT
Simply Speaking
Access Management = Manage the Access to Services
OBJECTIVES
• Granting authorized users the access to their Required
services
• Ensure that the access provided is of Right level
• Revoke the access after getting the necessary &
relevant approvals
• Prevent non-authorized access (from possible sources)
NOTE – Access management derives guidance from Information Security Management
KEY CONCEPTS
Access
Level & Extent of functionality that users can enjoy
Identity
Unique Information about the user which confirms his status
within the organization
Rights
Actual settings which ensure that users get the required access
Service & Service Groups
Set of services to which users can get the access in one go
Directory Services
A specific type of tool to help manage the Access or Rights
ACTIVITIES
• Request Access
• Users can request access via, RFC or Service Request via
Request Fulfillment or Helpdesk Menu
• Verify User Identity
• Access Management Team ensures that users are who
they say are & they have legitimate requirement for
service
• Provide Rights
• Access team provides the rights to users as per Policies of
the organization
Monitor Identity Status
Monitor users identity status, their change of roles,
expiry of valid account etc.
Log & Track the Access
Ensure the Accesses are logged & data is
maintained as per organizations policies
Revoke or Restrict Access
Revoke/Restrict or modify the rights as per user
status & as directed by policies
METRICS
Meeting Access SLAs
Accurate levels of Access Management
Any other metrics as asked by Information Security
management
ROLES & RESPONSIBILITIES
• Usually NOT a dedicated staff
• Typically carried out by Service Desk staff
• May also be managed by
• IT Operations Management Staff
• Technical Management Staff
• Applications Management Staff
SERVICE OPERATION 6 OF 9
PROBLEM MANAGEMENT
Simply Speaking
Problem Management = identify Root Cause of the
incident(s)
OBJECTIVES
To ensure that problems are identified and
resolved
To eliminate recurring incidents
To minimize the impact of the incidents or
problems that can not be prevented
KEY CONCEPTS
• Problem
• A root cause of one or more incidents
• Problem Model
• A model/ set of guidelines to deal with the problems which
can not be prevented
• Workaround
• A temporary solution / Quick Fix which enables to user to
continue using the service even though the root cause is not
identified/removed
• Usually Problem Team suggests workaround & Incident
team implements it
KEY CONCEPTS…CONTD
• Known Error
• A Problem for which the root cause is identified and
a temporary Work-around has been made available
• A Known Error is resolved by eliminating the root
cause permanently (E.g. via RFC)
• Known Error Database
• The purpose of this database is to maintain a record
of all the previous incidents, problems & known
errors
• Reactive Problem Management :
• The Reactive Problem Management activities help in
identifying the root causes of the Incidents.
• Then, these help in suggesting permanent solutions
so that these Incidents do not recur.
• Proactive Problem Management :
• The Proactive Problem Management activities aim at
preventing Incidents before they occur. This activity
helps identify weaknesses in the IT infrastructure
and suggests methods to eliminate these
PROBLEM MANAGEMENT TYPES
METRICS
Number of Incidents reduced by resolving Problems
Time needed to resolve Problems
% of Problems re-occurred
Well maintained KEDB
• Problem Manager : who is the overall in-charge of the Problem
Management process and is responsible for:
• Developing and maintaining the process
• Assessing effectiveness of the process
• Managing the Problem Support staff
• Providing MIS to management
• Allocating resources to the Support activities
• Support Groups : Are the Support Group Personnel who help the
Problem Manager in Reactive and Proactive Problem Management
through
• Identifying and recording problems
• Advising Incident Management team about workaround and fixes
• Identifying trends and potential sources of problems
• Submitting RFCs to prevent the occurrence
• Prevent the replication of problems to multiple systems
ROLES & RESPONSIBILITIES
SERVICE OPERATION 7 OF 9
IT OPERATIONS MANAGEMENT (FUNCTION)
Simply Speaking
IT Operations Management = Support day-to-day basic
level operational activities
OBJECTIVES
Ensure the Infrastructure Stability by performing basic
level jobs
Support day to day operational activities
Identify the opportunities to improve overall
operational performance & saving costs
Initial level diagnosis (& resolution) of operational
incidents
ACTIVITIES
• Basic level activities such as
• Backup & Restore jobs, Tape Management
• On call (telephone) or Remote Control (Vnc, netmeeting)
resolution
• Outlook configuration
• Facilities Management (e.g. Printer management)
• Basic H/W & S/W installations/configurations
ROLES & RESPONSIBILITIES
• IT Operation Manager
• Leadership/Management activities
• Management Reports
• Shift Leader
• Overall in-charge of shift activities
• Roaster plans, reports, updates etc.
• Analysts
• Senior staff with more important workload
assigned
• Operators
• All basic level jobs/ activities
SERVICE OPERATION 8 OF 9
TECHNICAL MANAGEMENT (FUNCTION)
Simply Speaking
Technical Management= Maintain Technical Knowledge &
Expertise
OBJECTIVES
Design of efficient, resilient & cost-effective IT Infrastructure
for the organization
Maintain Technical Knowledge & Expertise as required to
manage this IT Infrastructure
Ensure availability of actual technical resources when
required especially during failure
Other activities/roles within other ITIL processes or as
directed by organization
Provide technical resources for complete lifecycle i.e. design,
build , test, transition , implement & improve
KEY CONCEPTS
Technical Management Alignment
Alignment as per Technical lines for e.g.
Mainframes, Networks etc.
Activities
Manage lifecycle of Organization's IT
Infrastructure
Maintain Knowledgebase
Constantly update Technical expertise
ROLES & RESPONSIBILITIES
Technical Managers/ Leads / Analysts / Operators / Specialists
Leadership/management activities
Arranging Trainings, other activities to update the technical
knowledge
Reporting to senior management
Ensure policies/processes are in place for maintaining the
technical data/knowledge
SERVICE OPERATION 9 OF 9
APPLICATION MANAGEMENT (FUNCTION)
Simply Speaking
Application Management = Managing Application throughout their
Lifecycle
OBJECTIVES
Identify the requirement of Applications
Design efficient, resilient & cost effective applications for
managing IT Infrastructure
Ensure availability, security of the applications
Maintain the operational applications & their day-to-day
activities
Provide support during Application Failures
Improve the functionality of applications as per organization’s
needs
ACTIVITIES
Manage applications throughout their lifecycle
Assist Design, Build, Test & implement applications
Maintain knowledge & expertise for Managing the
applications
Make Application resources available
May be involved in Development project but it’s
not their primary responsibility
ROLES & RESPONSIBILITIES
• Application Managers / Team Leaders
• Leadership & management activities
• Reporting to Senior Management
• Trainings & other activities to improve expertise &
knowledgebase
• Application Analysts / Architect
• Work with first level users to capture & manage their
requirements
• Created & maintain standards for Application sizing,
performance modeling etc.
• Coordinate with Technical Management team as
applicable
5. CONTINUAL SERVICE IMPROVEMENT
KEY CONCEPTS
CSI Model
Service Measurement
VDJI Structure
Types of Metrics
7 Step Improvement Process
Continual Service Improvement Model
Service Measurement
Ability to capture the performance of an End to
End service against Targets/Standards
Also helps in prediction of future performance
Produces management reports for comparison /
Trend
Why do we measure?
Organization’s
Measurement
Framework
Strategic
Vision
To Validate
Changes
Corrective
Actions
ToIntervene
Factual
Evidence
ToJustify
Targets
Metrics
To Direct
Types of Metrics
• Technology based Metrics
• Typically used for applications, components etc.
• E.g. Performance, Downtime
• Process based Metrics
• Focused on Customer, Processes
• E.g. KPI, CSF
• Service based Metrics
• End to End services
• Focused on Supplier
• E.g. Gold/bronze package service
ROLES & RESPONSIBILITIES
• Service Manager
◦ Oversee the development, implementation, Evaluation
& Ongoing management of all new & existing products
& services
◦ Develops Business Case, Product Line strategy &
Architecture
◦ New Service Deployment & lifecycle Schedules
◦ Perform Service Cost Management
◦ Instill a Market Focus
7 Step Improvement Process
1.Define What
You should
measure
2.Define What
You can
measure
3.Gather the
Data
4.Process the
Data
5.Analyze the
Data
6.Present & use
the Information
7.Implement
corrective
Actions
Goals
ROLES & RESPONSIBILITIES
• CSI Manager
• Drive, Communicate & Coordinate CSI Vision &
Initiatives in organization throughout service lifecycle
• Oversee & be Accountable for the success of all
Improvement initiatives
• Constantly work with Process/Service owners to identify
Scope of Improvement
• Build effective relationships with the Business & IT
managers
• Ensure Monitoring is in place to gather Data
SUMMARY OF ITIL v3 PROCESSES & FUNCTIONS

More Related Content

PPTX
ITIL Service Design 2011
PPTX
ITIL Service Transition 2011
PPTX
ITIL Continual Service Improvement 2011
PPT
4 itil v3 service design v1.8
PPTX
ITIL Service Operation 2011
PPT
3 itil v3 service strategy v1.8
PPTX
ITIL Service Management
DOC
Sylvia Shah CV July 2016 b
ITIL Service Design 2011
ITIL Service Transition 2011
ITIL Continual Service Improvement 2011
4 itil v3 service design v1.8
ITIL Service Operation 2011
3 itil v3 service strategy v1.8
ITIL Service Management
Sylvia Shah CV July 2016 b

What's hot (19)

DOC
Sylvia shah cv july 2016
PPTX
ITIL Service Strategy
PPTX
ITIL Service Transition
PPT
ITIL Practical Guide - Service Strategy
PPT
ITIL Practical Guide - Service Operation
PPTX
ITIL Continual Service Improvement
PPTX
ITIL Service Design
PPTX
Service operation ppt
PPT
Service Management
PPTX
Service management
PDF
Service Operation Processes
PPTX
ITIL Service Operation
PPT
3 service strategy
PDF
ITIL and Service Management
PDF
05 itil v3 2011 continual service improvement csi
PDF
8c80720090713 Mos%20 Mba
PDF
Itil v3 foundation study guide service strategy
PDF
CV Dheeraj Bhandari
PDF
An introduction to service management (itil)
Sylvia shah cv july 2016
ITIL Service Strategy
ITIL Service Transition
ITIL Practical Guide - Service Strategy
ITIL Practical Guide - Service Operation
ITIL Continual Service Improvement
ITIL Service Design
Service operation ppt
Service Management
Service management
Service Operation Processes
ITIL Service Operation
3 service strategy
ITIL and Service Management
05 itil v3 2011 continual service improvement csi
8c80720090713 Mos%20 Mba
Itil v3 foundation study guide service strategy
CV Dheeraj Bhandari
An introduction to service management (itil)
Ad

Similar to Module 8 presentation it services (20)

PPTX
ITIL Ayman Hraghi
PDF
ITIL_2011_Mind_Maps training zone Mars 2011(1).pdf
PPT
Itilstudy_guide
PPTX
Itil v3-foundation symbiosis
PDF
ITIL V3 Summary
PPTX
Itil service strategy
PPT
Itil V3
PPTX
ITIL 2011 Overview ppt.pptx
PDF
Itil v3 foundation study guide service design
PDF
ITIL Course Wide version
PPTX
What is ITIL? How can it help your business?
PPSX
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
PPSX
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
PPT
ITIL Foundation for Information technology begineers
PPTX
IT Service Management Tutorial | What Is ITSM? | ITIL Foundation Training | S...
PDF
ITIL v3 Foundation Presentation
PPTX
ITIL # Lecture 2
PDF
ITIL V3 and Service Design - ITSM Academy Webinar
PPTX
About itil v3
ITIL Ayman Hraghi
ITIL_2011_Mind_Maps training zone Mars 2011(1).pdf
Itilstudy_guide
Itil v3-foundation symbiosis
ITIL V3 Summary
Itil service strategy
Itil V3
ITIL 2011 Overview ppt.pptx
Itil v3 foundation study guide service design
ITIL Course Wide version
What is ITIL? How can it help your business?
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
ITIL Foundation for Information technology begineers
IT Service Management Tutorial | What Is ITSM? | ITIL Foundation Training | S...
ITIL v3 Foundation Presentation
ITIL # Lecture 2
ITIL V3 and Service Design - ITSM Academy Webinar
About itil v3
Ad

Recently uploaded (20)

PPTX
Pharma ospi slides which help in ospi learning
PPTX
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
PDF
Black Hat USA 2025 - Micro ICS Summit - ICS/OT Threat Landscape
PDF
O5-L3 Freight Transport Ops (International) V1.pdf
PDF
Insiders guide to clinical Medicine.pdf
PDF
3rd Neelam Sanjeevareddy Memorial Lecture.pdf
PDF
O7-L3 Supply Chain Operations - ICLT Program
PDF
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
PPTX
PPH.pptx obstetrics and gynecology in nursing
PDF
RMMM.pdf make it easy to upload and study
PDF
The Lost Whites of Pakistan by Jahanzaib Mughal.pdf
PPTX
Cell Types and Its function , kingdom of life
PDF
Supply Chain Operations Speaking Notes -ICLT Program
PDF
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
PPTX
Cell Structure & Organelles in detailed.
PDF
VCE English Exam - Section C Student Revision Booklet
PDF
102 student loan defaulters named and shamed – Is someone you know on the list?
PPTX
master seminar digital applications in india
PPTX
Institutional Correction lecture only . . .
PPTX
Introduction_to_Human_Anatomy_and_Physiology_for_B.Pharm.pptx
Pharma ospi slides which help in ospi learning
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
Black Hat USA 2025 - Micro ICS Summit - ICS/OT Threat Landscape
O5-L3 Freight Transport Ops (International) V1.pdf
Insiders guide to clinical Medicine.pdf
3rd Neelam Sanjeevareddy Memorial Lecture.pdf
O7-L3 Supply Chain Operations - ICLT Program
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
PPH.pptx obstetrics and gynecology in nursing
RMMM.pdf make it easy to upload and study
The Lost Whites of Pakistan by Jahanzaib Mughal.pdf
Cell Types and Its function , kingdom of life
Supply Chain Operations Speaking Notes -ICLT Program
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
Cell Structure & Organelles in detailed.
VCE English Exam - Section C Student Revision Booklet
102 student loan defaulters named and shamed – Is someone you know on the list?
master seminar digital applications in india
Institutional Correction lecture only . . .
Introduction_to_Human_Anatomy_and_Physiology_for_B.Pharm.pptx

Module 8 presentation it services

  • 1. Chief Information OfficersChief Information Officers (CIO)(CIO)
  • 2. Module 8 IT SERVICE MANAGEMENT
  • 3. Objective of Module 8 To present the basic concepts and tools for IT Services Management within the ITIL Framework and to explore their applicability in the context of the E-Government Programme of the Government of Iraq.
  • 4. Scope of Module 8 ITIL Framework IT Service Life Cycle IT Service Strategy Service Planning Service Design and Operations Service Metrics
  • 5. EVOLUTION OF ITIL ITIL - Information Technology Infrastructure Library History Originally created in late 80s by the UK government Now truly global and applicable to all IT Services Focus on process and roles rather than organisation Version 1 in 1991- focused on UK Government Version 2 in 2000 - Industry wide and took into account changes in technology Version 3 in June 2007 – Life Cycle Approach OGC Office of Government Commerce – UK Treasury ministry ITSMF The driver behind all things ITIL taken over from OGC Global  USA, Canada, Mexico, Argentina, and Brazil - Americas  Australia, India, Singapore - Asia Pacific  Denmark, France, Germany, Netherlands, Sweden, UK - EMEA
  • 6. Is a collection of books which contain recommendations & suggestions to improve provision of IT Services Not a standard but a Best Practices Framework Needs to be adopted and/or adapted ITIL …
  • 7. Benefits of ITIL framework:- increased user and customer satisfaction with IT services improved service availability, directly leading to increased business profits and revenue financial savings from reduced rework, lost time, improved resource management and usage improved time to market for new products and services improved decision making and optimized risk.
  • 8. Standards based on ITIL ITIL BS 15000 ISO 20000 •BS15000 the first standard derived from ITIL •ISO 20000: ISO standard derived from ITIL
  • 10. The Four P’s The implementation of ITIL as a practice is about preparing and planning the effective use of The Four Ps: People Processes Products Partners
  • 12. Key CONCEPTS.……. Service & Service Owner Service Management Process & Process Owner Functions, Staff, Roles Metrics, Interfaces RACI PDCA Compliance & Governance Concept of Caps
  • 13. RESPONSIBILITY ACCOUNTABILITY CONSULTED INFORMED MATRIX Key: R = Responsible; performs the task A= Accountable; ultimately answerable for completion of task (only 1 person per task) C= Consulted; provides information or assistance I = Informed; kept apprised of the activity LOS Mgr PM SDM Client 1.1 Internal Kick off A 1.2 Offshore Resource requirement projection/Approval A R I 1.3 Travel Plan A 1.4 Resource Readiness R A 1.5 Knowledge Transfer (KT) Transition C I C 1.6 Conduct Lesson learned C A C 1.7 Sign off R A R
  • 14. Continuous step by step improvement Consolidated of the level reached (e.g. ISO 9001) PLAN DO CHECK ACT (Deming’s Cycle for Improvement)
  • 18. ACTIVITIES OF SERVICE STRATEGY Identify market & define your target area Decide what services you want to offer & who can be the potential customers Develop your service offerings Build on/improve your services Develop strategic assets Develop new services Help clarify the relationships between different services, processes, strategies etc.
  • 19. SERVICE STRATEGY 1.Demand Management 2.Service Portfolio Management 3.Financial Management
  • 20. SERVICE STRATEGY 1 OF 3 DEMAND MANAGEMENT
  • 21. Simply Speaking Demand Management = Know your customer and then identify his / her requirements
  • 22. BASIC CONCEPTS OF SERVICE STRATEGY Utility – It is derived from the attributes of service which have a positive effect on the performance What does the service do? Functional requirements Features, inputs, outputs Fit for purpose Warranty – It is derived from positive effect being available when needed, in sufficient capacity & magnitude & dependably in terms of Continuity & Security How well service does it Fit for use
  • 23. OBJECTIVES  To understand customer’s current requirements  Trend of requirements over a period/business cycle  Match the customer’s expectations with organization's capabilities of providing services  Ensure Warranty & Utility are in alignment with customer’s needs
  • 24. KEY CONCEPTS • Core service vs. Supporting Service • Pattern of Business Activity (PBA), User profile • Service Package (SP) vs. Service Level Package (SLP) • Business Relationship Management
  • 25. Core Service vs Supporting Service Core Service is the service which actually brings ‘value’ to the customer. It’s a service which is KEY from organization's perspective as well E.g. for a Banking customer, the core services provided will be all financial services Supporting Service ‘supports’ or enhances the core services It’s like an added feature which may not be desired but important to have Many times it becomes necessity E.g. supporting services in above case could be providing a helpdesk which helps/troubleshoots any issues/queries faced by
  • 26. Pattern of Business Activity (PBA) & User Profile Represents change in pattern of customers demands as explained by organization Important to track as it helps organization identify improvements in existing services or identify future opportunities Also important to study customer’s business & changing business needs User Profile Demand patterns shown by users Users means people or even processes/functions etc. Is usually associated with/is subset of PBA
  • 27. SP vs SLP Service Package is a bundle of core services and/or supporting services which is offered to customer SP Includes Service Level Package SLP has a defined level of Utility & Warranty for a given SP E.g. Buying 100 servers is a SP deal but some of them could be under Gold/Silver SLP
  • 28. Business Relationship Management Customer centric activities Constant communication with customer Helps to know the improvements & future scope for business Usually the First Point of contact for the customer especially for a first time/new business
  • 29. METRICS • Accurate understanding of customer’s business needs • Loss of Business to competitors especially for a new services • Improved Customer Relationships
  • 30. ROLES & RESPONSIBILITIES Business Relationship Manager Documenting the customer’s business needs, PBAs, User Profile etc. Ensure SLP matches customer’s needs Discussions with internal teams for setting up new SLPs or establishing the existing once Analyze potential SLP improvements , Look for future business opportunities with customer He may have a team working with multiple customers
  • 31. SERVICE STRATEGY 2 OF 3 SERVICE PORTFOLIO MANAGEMENT
  • 32. Simply Speaking SPM = How to bundle/package the services
  • 33. OBJECTIVES • Plan for services you can offer • Record of all the services including current, expired & in Pipeline • Provide information/guidance to Service Design
  • 34. KEY CONCEPTS • Service Portfolio, It’s Components & structure • Business Service, Business Service Management • Business Service vs. IT Service
  • 35. Service Portfolio It describes how the services are bundled & packaged Takes care of Marketing components such as What is the REASON customer will buy these services? What is the REASON customer will buy these services from US? SWOT analysis for our Organization’s service capabilities What could be our pricing models How best to allocate resources & capabilities
  • 36. ACTIVITIES • DAAC (Based on DMAIC cycle) • Define • Take Service Strategy as input, Define Inventories, Business Case, Validation of Data • Analyze • Decide Value Proposition, Prioritization, Balance of Demand & Supply • Approve • Authorize / Finalize the Portfolio, Services, Resources • Charter • Communicate information / decisions, Resource allocation, Chartering of services • Continually Update/ Improve the portfolio – begins next DAAC
  • 37. METRICS • How Accurate & Up-to-Date Portfolio is • Is the information contained is relevant from Market perspective • Is it in alignment with customer needs
  • 38. ROLES & RESPONSIBILITIES • Product Manager • Create Business case • Evaluate Marketing Opportunities • Deploy new services/retire the old ones • Manage a set of related services • Business Relationship Manager • First Point of Contact • Document Customer needs
  • 39. SERVICE STRATEGY 3 OF 3 FINANCIAL MANAGEMENT
  • 40. Simply Speaking Financial Management = Getting the Deal ($$$) right
  • 41. OBJECTIVES To serve as strategic tool to align IT services with Financial Decisions To balance the Cost & Price as appropriate Accounting for IT Services Facilitate Accurate Budgeting Finalize Financial Policies (e.g. Charging) Financial Review & Control
  • 42. COST VS PRICE Cost = Actual Expenditure of providing IT Services Price = The amount at which one Sells IT Services Hence Price – Cost = Profit
  • 43. KEY CONCEPTS Service Valuation (Previously known as Charging) Service Investment Analysis (Previously known as Budgeting) Accounting
  • 44. SERVICE VALUATION (CHARGING) A mechanism which helps organization to recover at least the expenditure incurred on providing IT services with additional monitorial profits as applicable Types ◦ Cost Recovery (Actual) ◦ Cost Plus Fixed Fee ◦ Cost Plus % of Costs ◦ Cost Plus Incentives ◦ Notional Charging ◦ Fixed Price ◦ Time & Material
  • 45. SERVICE INVESTMENT ANALYSIS • Was termed as Budgeting in v2 • It is a Time phased allocation of Funds • It helps Track & Control the expenditure pattern • Also guide how to utilize the funds
  • 46. ACCOUNTING A mechanism to track WHAT has been spent & WHERE it has been spent Maintain accounts of all incoming and outgoing monetary fund
  • 47. ACTIVITIES • To design mechanisms for service valuation, Investment Analysis & Accounting • To align IT Business with Finance Policies • Ensure the accuracy in implementing financial controls • Bill Payments & Collections • Updating the Finance Policies as per Organizational needs
  • 48. METRICS Accuracy in Budgeting, Forecasting & Controls Quick & Effective financial decision making Proper IT Accounting Ensure Timely Bill Payments & Collections Overall performance of Finance Dept.
  • 49. ROLES & RESPONSIBILITIES Finance Manager / Dept./ Controller To Lay Financial Policies & document To ensure that the policies are adhered to Implement proper financial controls Look for Continual Improvement Note – Every individual manager has some financial responsibility within his area of control
  • 51. ACTIVITIES • Design services to meet Business Objectives ◦ Design Secure & Resilient IT Infrastructure ◦ Identify, remove the risks from the services before they go live ◦ Create & maintain IT plans, policies, technical & process framework (Design tool ensures standards are adhered to) ◦ Design measurement methods & metrics for assessing effectiveness of processes ◦ Design Effective & efficient processes for design, transition & operation phases ◦ Scope includes new services & improvements as may be needed over a service lifecycle
  • 52. SERVICE DESIGN Service Catalog Management Service Level Management Availability Management Capacity Management Supplier Management Information Security Management Service Continuity Management
  • 53. SERVICE DESIGN 1 OF 7 SERVICE CATALOG MANAGEMENT
  • 54. Simply Speaking Service Catalogue Management = Services Ready to Use
  • 55. OBJECTIVES Create & Manage Service Catalog Keep Service Catalog Up to Date with latest information Continual Improvement in Management of Service Catalog
  • 56. KEY CONCEPTS What is Service Catalog? Service Catalog vs. Service Portfolio Types of Service Catalog
  • 57. • What is Service Catalog? ◦ A single source of information for all the service offerings ◦ Includes Operational & in Transition Services ◦ E.g. Menu Card in a Hotel • Service Catalog vs. Service Portfolio ◦ Service catalog is a part of Service Portfolio ◦ Service Portfolio depicts the services in their Business Value Terms i.e. Why customer would buy it from us ◦ Service Catalog depicts what service would you like to offer to customer (which will be based on customer needs) ◦ Service Portfolio is not usually available to be viewed by Customer or public whereas Service Catalog may be
  • 58. Types of Service Catalog Business Service Catalog Used by Relationship Manager to win a business Consists list of all IT services which are important for Customer’s Business Process Visible to customer (or even to common public) Technical Service Catalog Used by Relationship Manager to know the capabilities & limits of Business Service Catalog Contains all the Backup/Supporting services for services shown in BSC
  • 59. METRICS Accuracy of Information within Service Catalog Number of corrections made Customer Feedback Number of successful / lost proposals
  • 60. ROLES & RESPONSIBILITIES Service Catalog Manager Establish & maintain Service Catalog Ensure all the information is accurate & up-to-date Oversee all the other aspects of service catalog. E.g. Information contains all applicable operational & in Transit services etc. Work on Continual Improvement of Service Catalog
  • 61. SERVICE DESIGN 2 OF 7 SERVICE LEVEL MANAGEMENT
  • 62. Simply Speaking Service Level Management = Negotiate & Agree Service Levels with client
  • 63. OBJECTIVES To Negotiate, Agree & Document the Service Levels To balance the customer expectations & organization’s capabilities To measure, report & continually maintain/improve service level To manage the performance as per agreed service levels To manage the customer relationship
  • 64. Service Scope and description Service hours Measures of availability and reliability Support details – who to contact, when and how Respond and fix times Deliverables and time scales Change approval and implementation Reference to IT Service Continuity Plan Signatories Responsibilities of both parties Review process Glossary of terms ELEMENTS OF SLA
  • 66. METRICS Clearly Defined SLAs, OLAs and UCs Performance against agreed SLAs Shortfalls in SLA and consequent SIPs Number & severity of service breaches Improvement in customer satisfaction
  • 67. ROLES & RESPONSIBILITIES Service Level Manager Process Owner Review & Reporting Maintaining an effective Service Level Management process by defining SLAs, OLAs and UCs Updating the existing SLAs, SIPs, OLAs and UCs Reviewing and improving the performance of the IT organization to meet agreed service levels
  • 68. SERVICE DESIGN 3 OF 7 AVAILABILITY MANAGEMENT
  • 69. Simply Speaking Availability Management = Ensure IT is working as agreed
  • 70. OBJECTIVES To ensure agreed Availability Level is met or exceeded The Availability Management process plays an important role in ensuring that a defined level of IT services is continuously accessible to customers, in a cost-effective manner Continually Optimize & Improve the availability by preparing Availability Plan
  • 72. • The ability of a service, component or configuration item to perform it’s agreed & expected function when required • Usually expressed as Percentage Availability= (AST-DT) X 100 ----------------- AST AST = Agreed Service Time DT = Downtime AVAILABILITY
  • 73. Reliability Implies how long the specified service is available for the required period without any interruptions or failures Serviceability Ability of the 3rd party supplier to provide the expected service to service provider Maintainability (or Recoverability) How easy it is to maintain or recover a service, component or configuration item
  • 74. Availability Metrics MTRS- Mean Time to Restore Service (Down Time) = Relates to Maintainability (Also has an element of Serviceability) Detection Diagnosis Recover Restoration Incident Occurred MTBF- Mean Time Between Failures(Uptime) = Availability MTBSI – Mean Time Between system Incidents = RELIABILITY Time Incident Occurred Repair
  • 75. Vital Business Function (VBF) A critical function or business process High Availability Minimizing the impact of component failure Fault Tolerance Ability of a service to continue to be available even after component(s) failure
  • 76. METRICS • Uptime per service or group of Users • Downtime duration • Downtime frequency • Number of failures beyond ‘X’ time
  • 77. ROLES & RESPONSIBILITIES • Availability Manager ◦ Process Owner ◦ Ensure the agreed levels of service availability ◦ Create & manage Availability Plan ◦ Continual improvement in process/results
  • 78. SERVICE DESIGN 4 OF 7 CAPACITY MANAGEMENT
  • 79. Simply Speaking Capacity Management = Ensure IT is sized in optimum & cost effective manner
  • 80. OBJECTIVES Provide the required IT Infrastructure in a cost effective manner while also meeting it’s requirements Ensure optimum utilization of IT infrastructure Work on current & future needs Produce & regularly upgrade Capacity Plan
  • 81. KEY CONCEPTS Business , Service & Component Capacity Management Capacity Management Information System Capacity Plan Performance Management, Modeling, Application Sizing
  • 82. • Business Capacity Management • Trend, forecast model and developing the Capacity Plan to understand future business needs • Modeling to estimate the best alternative for Capacity deployment • Service Capacity Management • Understand the functioning of the IT services, resource usage and variations to ensure that appropriate service agreements can be designed • Report on Service profile of use of services, manage demand for service • Component Capacity Management • Using and monitoring of all components of the IT infrastructure • Optimize use of the current IT resource components such as bandwidth, network capacity etc.
  • 83. • Capacity Plan • Time (or trigger) phased plan to maintain/increase the utilization of IT Infrastructure by maintaining or adding IT infrastructure components • Capacity Management Information System (CMIS) • A system which holds the data needed & maintained by all the capacity sub processes/activities
  • 84. Performance Management – Monitoring – Tuning Modeling – Mathematical models for determining the benefits and costs of varying capacity – Simulation and Analytical techniques Application Sizing – For determining the hardware capacity required to support new/modified applications
  • 85. METRICS Performance trends after estimates Reduction in rushed purchases Reduction in expensive overcapacity Reduction in number of incidents due to performance plans
  • 86. ROLES & RESPONSIBILITIES Capacity Manager Monitors the Process Capacity Plan Creation Update the Capacity Management Database Supported by Technical & Application Management To provide capacity requirements via capacity incidents & problems Other day to day capacity management activities
  • 87. SERVICE DESIGN 5 OF 7 SUPPLIER MANAGEMENT
  • 88. Simply Speaking Supplier Management = Manage Supplier Relationship & Performance
  • 89. OBJECTIVES Manage supplier relationship & performance Ensure the Right & Relevant contracts with supplier Manage the contracts throughout their lifecycle Create & maintain Supplier Policy, List & Contracts Database
  • 90. Supplier Selection Request Supplier Responses Requirement of 3rd party supplier Select Suppliers Analyze Supplier Capabilities Contract with Supplier (UC) Supplier provides Services Manage Suppliers SCD Update supplier’s records
  • 91. Supplier – Contracts Database (SCD) Supplier Contracts Database Organization’s Supplier Policy & Strategy Contracts categorization According to Types of services, Owner, expiry date, value etc. Fresh/Renewed Contracts Existing Contracts Records of Past/Expired Contracts Contracts Modification/Termination Supplier’s performance Against contract terms
  • 92. METRICS Relevance of contracts in terms of SLM Performance of suppliers Accuracy of information in SCD
  • 93. ROLES & RESPONSIBILITIES Supplier Manager Process owner Deliver expected supplier performance Create, establish & maintain SCD Manage the contracts in conjunction with SLM
  • 94. SERVICE DESIGN 6 OF 7 INFORMATION SECURITY MANAGEMENT
  • 95. Simply Speaking ISM = Protect your Data & Information
  • 96. OBJECTIVES To prevent Unauthorized Access (& allow Authorized Access) To provide effective security measures at Strategic, Tactical & Operational organizational Levels To enable organization to do a business “Safely” To comply with Security Requirements as per SLA
  • 97. KEY CONCEPTS Confidentiality, Integrity, Availability, Non- Repudiation Information Security Policy Security Analysis & Controls
  • 98. • Confidentiality • Information is accessible to only those who are authorized to view it • Integrity • Information, especially while being communicated, is protected against unauthorized modification • Availability • Information is invulnerable to attacks or is recoverable in secured way i.e. it is available (only to authorized) when it should be • Non-Repudiation ◦ Sender of information can not deny that information has NOT been sent by him
  • 99. • Information Security Policy • A policy of an organization which ensures the compliance to Information Security Objectives & Guidelines • Security Analysis & Controls • To Analyze the threats to organization’s data/Information & to eliminate/minimize the same • To provide security controls (checkpoints) at various levels so that reduce the impact of security breaches
  • 100. METRICS Effectiveness of Security Measures / Controls Number of Security Breaches , Attacks Business Losses incurred due to security malpractices Adherence /Compliance to Security Standards Security Audits reports
  • 101. ROLES & RESPONSIBILITIES • Security Manager ◦ Process Owner, Planning for Security ◦ Design & Monitor Security Policy / Analysis / Controls ◦ Oversee entire security aspect of the organization ◦ Overall Improvement • Security Officer ◦ Mediator between Security manager & Customer / Users ◦ Assist Implementation of security policies/measures etc.
  • 102. SERVICE DESIGN 7 OF 7 SERVICE CONTINUITY MANAGEMENT
  • 103. Simply Speaking • Service Continuity Management = Recover from disaster Z as per agreed & applicable SLA
  • 104. OBJECTIVES • To create & manage IT service continuity & recovery plans • To reduce potential disaster occurrence • To negotiate & manage necessary contracts with 3rd parties • Balance SLAs & Cost factors while planning for service continuity
  • 105. KEY CONCEPTS Business Continuity Strategy Life Cycle Approach to ITSCM Assessment of Changes for impact on ITSCM Dormant Contracts Negotiated/Compromised SLAs Regular Testing – Ongoing as a part of Lifecycle approach
  • 106. LIFE CYCLE APPROACH TO ITSCM Initiate ITSCM Gather requirements Plan for implementation Implementation ORR (Operation Readiness Review) Mock Testing Go Live /Sign Off for ITSCM Structure Ongoing regular testing & updates to ITSCM structure
  • 107. POSSIBLE RECOVERY OPTIONS • Do nothing • Manual Workarounds • Reciprocal arrangements (Less Frequently used) • Immediate recovery – hot standby (24 hours) • Mirrored business systems on an alternate site • Intermediate recovery – warm standby (24-72 hrs) • Similar to immediate but critical systems need to be recovered and run • Gradual recovery – cold standby (72 hrs) • Empty facility with utilities • Fortress Approach • Dormant contracts • Insurance
  • 108. • Business Continuity Strategy • Aims at reducing risks by developing recovery plan(s) to restore business activities if they are interrupted by a disaster • Assessment of Changes for impact on ITSCM • To study & mitigate the impact of any changes in IT Infrastructure on ITSCM • Dormant Contracts • Contracts with 3rd parties which become active only when triggered by a disaster • Negotiated/Compromised SLAs • To negotiate appropriate SLAs with customer which will be applicable only during disaster
  • 109. METRICS Number of shortcomings Cost to company due to loss if no recovery Plan Cost in Time, resources and money to restore IT Services
  • 110. ROLES & RESPONSIBILITIES ITSCM Manager Owns entire ITSCM process To manage & upgrade ITSCM Plans
  • 112. ACTIVITIES • Plan & Implementation of all the releases / Services (Applies to new & existing services) ◦ Ensure that the changes as proposed in Service Design are realized ◦ Authorize, Package, Build, Test & Deploy the releases into production ◦ Transition of services to & from other Organizations ◦ Decommission or Termination of services
  • 113. SERVICE TRANSITION Service Asset &Configuration Management Change Management Release & Deployment Management Knowledge Management
  • 114. SERVICE TRANSITION 1 OF 4 SERVICE ASSET & CONFIGURATION MANAGEMENT
  • 115. Simply Speaking SACM = Know what you have
  • 116. OBJECTIVES Identify, Record & Provide accurate information of the Configuration Items (CI = IT components) Provide the Logical Model for IT infrastructure correlating the IT services & their components Protect Integrity of the CIs Create & maintain Configuration Management System Manage Service Assets (Service CIs) Perform regular audits / status accounting activities for all the CIs
  • 117. KEY CONCEPTS Configuration Items, Baseline, Variant Types of CIs Configuration Management System
  • 118. • Configuration Item • A uniquely identifiable entity/item which needs to be controlled • Baseline • Snapshot of a CI or a group of CIs at a given time or stage • Variant • A baseline with minor differences • Configuration Management System • It is a system which controls & maintains the record if all CIs in a structured manner in 1 or more databases known as CMDB • Stores Attributes of CIs, Relationship between CIs • Consists of Multiple layers like Integration Presentation etc.
  • 119. CONFIGURATION MANAGEMENT SYSTEM CMDB1 Services CMDB2 H/W CMDB3 Policies Data/Source information gathering Knowledge & Logic processing Presentation Layer /User Interface NOTE – CMDB can be any Database, or even Excel File
  • 120. TYPES OF CIs • Service Lifecycle CIs • Business Case, Service Portfolio, Service Design Package • Service CIs • Service Capability /Resource Assets, Service Model • Organization CIs • Organization Policies, documentations • Internal CIs • Internal to individual projects which are required to maintain IT • External CIs ◦ Customer Agreements & Requirements
  • 122. Defining the strategy, policy and objectives for the process Analyzing the information, Identifying the tools and resources available for the process Creating interfaces with other ITIL processes, projects and third party suppliers Planning
  • 123. To identify the associated IT services and components, which need to be controlled by the Configuration Management process. Define the Scope of the process IT Services, Hardware, Software and Documentation, Specific Areas Specify the Level of Detail for information recording Identify the Relationships of the CIs Determine the depth of information to be recorded Naming Conventions, Attributes covered Identification
  • 124. The next activity after Identification is Status Accounting of the IT component through its life cycle. A status code is assigned to each of the statuses for easy identification. Typical Statuses New CIs In Order, Tested, Accepted Existing CIs Received, RFC open for the CI new version requested, Down, Phased Out, Undergoing maintenance All CIs In Stock, Order received, Under test, Released for Installation, Live, Spare Status Accounting
  • 125. Configuration Management controls all the IT components received by the organization Control. Who can Access, who can modify Control
  • 126. Audit and Verification • Does the CMDB reflect reality? • The activities includes verifying and auditing the details in the CMDB. • For example, audit tools can be used to automatically analyze workstations and report on the current situation and status of the IT infrastructure. • Accuracy is improved by • Active rather than passive CMDB • Automatic updating • Integration with other processes • Automatic checks Reporting Assess the efficiency and effectiveness Through Regular MIS reports Scheduled reviews of the expected growth in demand of Configuration management activities
  • 127. METRICS Number of occasions on which a – "Configuration" was found to be unauthorized – Number of refused RFCs as a result of incomplete data in the CMDB – Number of changes to the CMDB because of identified errors in the CMDB – Unauthorized IT components detected in use
  • 128. ROLES & RESPONSIBILITIES Service Asset Manager Configuration Manager These are responsible for their own processes Implementing policy Agree scope, processes & procedures Define necessary controls Oversee collection & management of data Audits Produce management reports
  • 129. SERVICE TRANSITION 2 OF 4 CHANGE MANAGEMENT
  • 130. Simply Speaking Change Management = Minimize the Impact of Change
  • 131. OBJECTIVES Study the adverse Impact of change & minimize it Create & maintain a Change Management process Prevent Unauthorized changes Prepare Change (& Back out) Plans via FSC & provide PSA Post Implementation Reviews of Changes Maintain a record of all changes Note - Change Management does NOT implement change
  • 132. KEY CONCEPTS Scope of Change Management Change Types , RFC, Change Classification & Prioritization, Change Models CAB, ECAB, FSC, PSA, Back out Plans
  • 133. Scope of Change Management Scope of Change Management process is restricted to IMAC of IT Infrastructure Components including documentation Strategic, Tactical & Operational changes Out of Scope Business Strategy & Processes Implementation of changes Any other task documented as out of scope
  • 134. Change Types • Standard Changes • Routine Changes that follow an established procedure & do not disrupt It services • E.g. updating the Anti-Virus software is a standard Change • Emergency Changes ◦ Crucial to an organization and have to be implemented immediately. ◦ Emergency Changes are disruptive and prone to failure ◦ E.g. the some ports in critical switch has gone down. Therefore, a new switch needs to be installed
  • 135. • Request for Change (RFCs) • Incidents, upgrades to the infrastructure, or changes in the business requirements generate the need for a Request for Change (RFC) • Change Classification & Prioritization • To classify & plan changes in the order of their impact & urgency • Change Models ◦ Predefined way or procedure for handling known type or complexity ◦ Automated as far as possible ◦ Allow for scalability to create a new model
  • 136. • Forward Schedule of Changes (FSC) • Contains details of all approved changes and their implementation dates for an agreed period • Detailed short term schedules and less detailed for longer term planning • Projected Service Availability (PSA) • To determine the best time for a change implementation • Both the FSC and PSA are agreed with the customers • Back Out Plan • It is executed if the Change can not happen as per plan • Usually but not necessarily the typical back out plan is to bring the systems back to original state it was in before the change started
  • 137. Change Advisory Board (CAB) CAB approves Changes after assessing and prioritizing the RFCs. CAB members should have sound technical knowledge and good business perspective. Change Manager is the only permanent member on the CAB & ECAB CAB/Emergency Committee To review urgent changes Few members required (typically Senior Managers from concerned dept) Availability after shift hours
  • 138. Change Management Process Flow Request For Change (RFC) Change Manager Line Manager Approval CAB Meeting Post Change ReviewFSC/PSA Implement Change Update CMDB & Change Records Failure Back out Plan Success Problem Management Customer or other teams SCM, Capacity, BRM, ISM,SLM, R&D, Customer etc. Consult Invitations as applicable Customer Sign Off
  • 139. ACTIVITIES Record RFC Review RFC Assess & Evaluate Change – 7 Rs of Change Authorize Change Issue Change Plan (to R& D Team) Support/Coordinate Change Implementation Post Change Review
  • 140. 7 Rs of Change Who RAISED it What is REASON for change What is the RETURN expected from change What could be the RISKS involved in change Which RESOURCES are needed to implement change Who (which R&D Team) is RESPONSIBLE for build, test & implement change Is there (or what) any RELATIONSHIP between this change & other changes
  • 141. METRICS Number of Rejected RFCs Number of Incidents occurring due to implemented Changes Number of successful changes Number of unsuccessful changes Number of backed out changes Average Time needed to implement a Change Number of incidents resolved by implementation of a Change
  • 142. ROLES & RESPONSIBILITIES • Change Manager • Chairperson of the CAB • Filtering and accepting RFCs • Primary Responsibility of planning and coordinating implementation of changes • Obtaining authorization for change • Reviewing Implemented Changes • Convening emergency CAB meetings • Generating Change Management reports • May have Change coordinators to support • CAB Member ◦ Belongs to the CAB and participates in all CAB meetings ◦ Helps in reviewing all RFCs to estimate impact ◦ Participates in Scheduling Changes
  • 143. SERVICE TRANSITION 3 OF 4 RELEASE & DEPLOYMENT MANAGEMENT
  • 144. Simply Speaking R & D Management = Bring in the change Carefully
  • 145. OBJECTIVES Implementing the authorized changes as per Change plan Plan, Design, Build, Test & Install Hardware & Software components Skills & Knowledge Transfer to enable Customers & users the optimum use of service Operations & support staff to run & support the service
  • 146. KEY CONCEPTS Release Release Units Release Identification Types of Release Release Methods
  • 147. Release A collection of authorized Changes to an IT Service A Release is defined by the RFCs that it implements A Release could consist of a number of Problem fixes and enhancements to a service.
  • 148. • A Release unit describes the portion of the IT infrastructure that should be released together. • Depending on the type or item of software and hardware, the size of the unit can vary. An example of hardware Release Unit can be changes to the complete PC or Processor. An example of a s/w release unit could be changes made to a system, suite, program or module. • Including too many changes in one release can be too complex for safe implementation while too many releases affect user dependency on the stability of the service. Release Units
  • 149. • The status of a Release alters according to its current environment. Release identification means determining the status of a Release in different environments. The environments in which a Release can be categorized are: – Development – Test – Live – Archive Release Identification
  • 150. • Depending on the number of changes that should be included in one Release, a Release can be of the following type:  Delta Release  Just a few changes normally a quick fix  Package Release  You use a Package Release when you Release a group of software. Each of the software in the package depends on the other software in the group for its performance.  For example, scheduled upgrades to third-party software, such as Systems software and Office applications are appropriate for Package Releases.  Full Release  When a program is released in its entirety, including the parts that were not changed.  A number of similar Changes can be implemented together in this Release  More preparation and resources are required for a Full Release Release Types
  • 151. METRICS ◦ Number of Incidents by Back Out ◦ Number of accurate and timely release at remote sites ◦ Number of unused software that have unnecessary costs, e.g. Licence fees ◦ Number of times unauthorised software is used ◦ Number of times CMDB status is updated/not updated
  • 152. ROLES & RESPONSIBILITIES  The Release & Deployment Manager coordinates the implementation of the process with other teams. ◦ Prepares Release Plan ◦ Authorises the Release Build and Configuration ◦ Communicates Release to other groups ◦ Coordinated final Implementation of Release ◦ Member of the CAB.  The Test Manager ensures that the release is tested and signed off by proper authorities. ◦ Successful testing of the release before sign-off ◦ Ensure Testing environment is same as Live environment ◦ Preparing roll-out Plan with Release Manager
  • 153. SERVICE TRANSITION 4 OF 4 KNOWLEDGE MANAGEMENT
  • 154. Simply Speaking Knowledge Management = Gather, Analyze, Store & Share the knowledge
  • 155. OBJECTIVES  Improve the efficiency by reducing the need to Re- discover the knowledge  Create, Maintain & update Service Knowledge Management System  Make sure that a Right & Relevant information at Right time is available for organization’s requirements (e.g. Customer details, contract/SLA data)
  • 157. Data - Information – Knowledge - Wisdom  Data ◦ A set of discrete facts about the events ◦ Usually large amount of data is/can be collected  Information ◦ The data is arranged/sorted in appropriate context & manner so that it’s easy to locate/work on ◦ Answers questions like Who, what, when, where?
  • 158. Knowledge Created based on the information/data or own expertise Answers How? Is dynamic & context based Helps in decision making Wisdom Gives detailed understanding Arriving at the judgment Helps finalize future decisions/actions Data - Information – Knowledge - Wisdom
  • 159. Definitive Media Library Store Master copies of all the S/W assets In house, external, Trail, Commercial Of The Shelf Licenses, Scripts & codes Is controlled by Service Asset & Configuration Management process Serves as the only source for build & distribution for Release & Deployment process
  • 160. DML & CMDB CMDB stores the information about all the CIs (H/W & S/W) DML stores the actual CIs (S/W only) (earlier DSL and DHS) Both are controlled by SACM process Both form part of SKMS
  • 161. Service Knowledge Management System - SKMS Services H/W Policies Presentation Layer /User Interface SCDCDBDML CMS Service Knowledge Base Knowledge & Logic Processing
  • 163. ACTIVITIES Keeping services into Operations ◦ Ongoing day to day activities ◦ Ensure that services are delivered at agreed levels (SLA) ◦ Continual Improvement in meeting the SLAs & management of operations Involves Management of ◦ Services ◦ Service Management Processes ◦ People ◦ Technology
  • 164. SERVICE OPERATION Service Desk (FUNCTION) Incident Management Event Management Request Fulfillment Access Management Problem Management Technical Management (FUNCTION) IT Operations Management (FUNCTION) Application Management (FUNCTION)
  • 165. SERVICE OPERATION 1OF 9 SERVICE DESK (FUNCTION)
  • 166. Simply Speaking Service Desk = Single & the First Point Of Contact
  • 167. OBJECTIVES OF SERVICE DESK To serve as FIRST Point of Contact (FPOC) Play a vital role in achieving Customer Satisfaction First Level Fix (FLF) & First Level Diagnosis (FLD) To coordinate the activities between End User & IT Service Provision Teams To OWN the Logged Request & ensure the Closure. Escalate as appropriate To support other IT Provision Activities on need basis
  • 168. Help Desk Versus Service Desk End User Agent Help Desk Help Me!! Reactive Culture Focus on Restoration
  • 169. Help Desk Versus Service Desk End User Agent Service DeskHelp Me!! Inform Me!! Educate Me!! Change Me!! Service Me!! Inspire Me!! Proactive Culture Business Focus Focus on Preventative Awareness
  • 170. KEY CONCEPTS OF SERVICE DESK Logging the call with service desk Types/Models/Structures of Service Desk Skills required for Service Desk Personnel
  • 171. LOGGING THE CALL WITH SERVICE DESK Who – End users, All other relevant teams, Events, Service Desk Team itself NOTE: Not every call logged is an incident Why – As a part of responsibility, as a proactive measure How – Telephone, Emails, Alerts, Web Console etc. What is an Incident? An occurrence of event(s) which disrupts or can potentially disrupt the normal service operation What is problem? Unknown underlying cause of one or more incidents
  • 172. TYPES / MODELS / STRUCTURES OF SERVICE DESK Central Service Desk Local or Distributed Local Service Desk Virtual Service Desk Follow the Sun Model Specialized Service Desk
  • 173. CENTRAL SERVICE DESK Single Service Desk at a possible central location Can be a group of service desks Integrated at a single location Advantage Cost cutting Centralized control Disadvantage Some Local presence may still be required for Physical support
  • 174. Centralized Service Desk ABC Ltd. Delhi ABC Ltd. Hyderabad ABC Ltd. Bangalore ABC Ltd. Pune Helpdesk 011-232425 H elpdesk 011-232425 Helpdesk 011-232425
  • 175. LOCAL OR DISTRIBUTED SERVICE DESK The desk is co-located within or physically close to user premises Advantage ◦ Useful in case of multilingual / multi location organizations ◦ Faster response wherever Physical presence is necessary Disadvantage ◦ May prove Expensive ◦ Difficult to manage multiple desks
  • 176. Local or Distributed Service Desk ABC Ltd. Delhi ABC Ltd. Hyderabad ABC Ltd. Bangalore ABC Ltd. Pune SD SD SD SD
  • 177. VIRTUAL SERVICE DESK By using the extensive technology, an appearance of a single / centralized desk Primarily used in Off-shoring kind of services Advantage Maximum use of technology so minimum personnel involvement Less number of requests go Unregistered Disadvantage Expensive to use Physical support may not be possible
  • 178. Virtual Service Desk ABC Ltd. Delhi ABC Ltd. Hyderabad ABC Ltd. Bangalore ABC Ltd. Pune SD London SD Sydney SD Beijing SD New York Network Cloud 1800XX 1st Caller Answer to 1st Caller 1800XX 3rd Caller Answer to 3rd Caller 1800XX 2nd Caller Answer to 2nd Caller 1800XX 4th Caller
  • 179. FOLLOW THE SUN MODEL 24 Hrs of Desk Team which is in Day time picks up the call Advantage ◦ Best for 24 Hrs kind of support ◦ Less desk staff attrition due to working time Disadvantage ◦ Expensive due to use of technology ◦ Multiple control points so difficult to manage
  • 180. Follow the SUN Indian Standard Time Responding SD Region 10 AM 3 PM 8 PM 1 AM5 AM AUS USA EST UK IND USA PAC
  • 181. SPECIALIZED SERVICE DESK Expert Staff specialized in their respective fields Advantage ◦ Faster & accurate resolution of request Disadvantage ◦ Difficult to get skilled staff
  • 182. Specialized Service Desk Service Desk Menus User calls DBA Network Admin Windows Team Email Team
  • 183. NOTE In practical world, most of the organizations use a mixture of service desk types/models/structures.
  • 184. SKILLS REQUIRED Communication Interpersonal Skills Business / IT Understanding Professionalism Customer Focus Subject Knowledge (for a Specialist Service Desk)
  • 185. ACTIVITIES OF SERVICE DESK Receive & Log the calls from End Users, events etc. Provide Preliminary level of diagnosis as applicable Categorize the incident as possible Assign to relevant Incident Team Follow up with Incident Team Update status regularly & communicate to user as applicable Keep an eye on agreed SLAs Escalate as & when appropriate Confirm with user before closing the incident Provide Service Desk Metrics Reports to Service Desk Manager
  • 186. METRICS FOR SERVICE DESK Average call resolution/duration % of calls picked up in 3 rings, % Unattended Accuracy of updating ticket status Number of SLA breaches Timely Escalations Customer Satisfaction
  • 187. ROLES & RESPONSIBILITIES IN SERVICE DESK  Service Desk Staff ◦ To Perform all the activities of Service Desk as applicable  Service Desk Manager ◦ To Oversee the functioning of Service Desk ◦ To build Service Desk Team for new services ◦ To Monitor the performance of Service Desk on regular basis ◦ To identify & work on the Continual Improvement of Service Desk
  • 188. SERVICE OPERATION 2 OF 9 INCIDENT MANAGEMENT
  • 189. Simply Speaking Incident management = Restore Service ASAP
  • 190. OBJECTIVES To restore NORMAL service operation as quickly as possible ◦ NORMAL means as agreed in SLA To log & Track incidents wherever applicable (e.g. Proactive measure) To deal with all incidents consistently To assist Problem Management team as required To assist Service Desk/ Release Team for any RFCs
  • 191. KEY CONCEPTS  Incident ◦ An occurrence of event(s) which disrupts or can potentially disrupt the normal service operation  Problem ◦ Set of incidents with similar underlying “unknown” cause(s) ◦ (A root cause of one or more incidents)  Priority  Escalation Mechanism  Incident Lifecycle
  • 192. Impact Evidence of effect upon business activities Urgency Evidence of effect upon business deadlines Priority = Impact X Urgency
  • 193. Functional Escalation  Through various functions or support group levels Hierarchical Escalation  Through organizational hierarchy Escalation Mechanisms
  • 195. Incident Detection & Recording Classification & Initial Support Investigation & Diagnostics Resolution & Recovery Incident Closure Request Fulfillment Procedure Is it a Request? Ownership, Monitoring, Tracking & Communication YES NO Incident Life Cycle
  • 196. MAJOR INCIDENTS These are incidents which have a short timescale target & higher urgency Major Incident NEED NOT BE A Problem
  • 197. METRICS Number/Percentage of proactively recorded Incidents Average time to resolve Incidents Number of Incidents/workstation within SLAs Percentage of Incidents resolved at First Line, Second Line Support Total no. of Remote resolution of Incidents
  • 199. Incident Manager : who is the overall in-charge of the Incident Management process and is responsible for: Creating Process Reports Organising Management Information Recommending measures Usually this role is assigned to Service Desk Manager Support Groups Level 1 to Level n Tech Specialist Group Super Users They act as a link between IT & Service Desk Manage expectations of users in terms of SLAs & Service Desk Training & Encouraging users for minor incident resolutions Involvement in new releases/roll outs ROLES & RESPONSIBILITIES
  • 200. SERVICE OPERATION 3 OF 9 EVENT MANAGEMENT
  • 201. Simply Speaking • Event Management = Detect Events & decide appropriate Actions
  • 202. OBJECTIVES Detect Events, Make Sense/Analyze them & Decide the appropriate action Monitor, Record & filter the relevant events Trend Analysis as a Proactive Measure/Study purpose Contributes to maintain SLAs.
  • 203. • Event • A notification or alert created by IT Service, CI or Monitoring Tool • Event Management • A process of managing the events throughout their lifecycle • Typically done by IT Operation Staff • Alerts • An occurrence of something which triggers event or a call for action or a human intervention
  • 204. Information An event which is only meant to provide information E.g. Backup job completed Usage To check status of activity, device To get statistics Informational events are usually recorded for a pre-determined period Types of Events
  • 205. Type of Events….contd • Warning • Event meant as a proactive measure to indicate that service or device is reaching a threshold • E.g. Network traffic reaching a congestion point • Exception • Event which indicates that a service or a device is behaving abnormally (against a defined behavior) • E.g. Hdd1 in RAID has failed
  • 206. ACTIVITIES • Recording, Filtering Events • All Events usually get recorded in a log file • Events are filtered according to their types either automatically or manually • Prioritization of Events • Events are prioritized based on their importance & their types • Based on SLAs, some events can always get high priority • Exceptions Management • Exception is usually converted into Incident or problem or RFC • Exception does NOT necessarily represents Incident/problem
  • 207. METRICS • Effectiveness of Event Management • How best are the events designed • Are they in alignment with SLAs? • Are they monitored, recorded, filtered correctly? • How well the events data is maintained • How many incidents are logged proactively based on Warnings/Exception
  • 208. ROLES & RESPONSIBILITIES • Usually NOT a dedicated role such as Event Manager • Event Management is conducted by staff in • Service Desk • Less Involvement. • Typically involved for logging incidents based on Exceptions • Technical & Application Management • Both Application & Technical Management value add to event management during Service Design, Service Transition & Service Operation • IT Operations Management • Usually clubbed with Technical or Application management • Typically do Monitoring & First-Lie responses
  • 209. SERVICE OPERATION 4 OF 9 REQUEST FULFILLMENT
  • 210. Simply Speaking • Request Fulfillment = Provide a quick response to standard service requests.
  • 211. OBJECTIVES • To communicate (or make available) the information regarding existing Standard services & the procedures • To provide channel & mechanism for users to avail these standard services • Users need to raise a Service Request for the same • To provide the standard services to users • May need to work in background as well for e.g. procurement of h/w (like mouse) for standard services • To assist for general queries, updates on standard services NOTE - Request Fulfillment derives guidance from Change Management
  • 212. KEY CONCEPTS Service Requests & Standard Service Components of Standard Services Request Model
  • 213. • Service Request • A request from users for Standard service • Standard Service • Typically involves a routine type of change • Although may be managed by Service Desk, it is NOT treated as Incident • E.g. Change of Mouse, Resetting password • Components of Standard Service • Pre-defined process • Some changes can be pre-approved (or Auto Approved) e.g. Requesting stationary • Some changes may require additional or special approvals
  • 214. • Request Model involves a process-flow for Request Management • Make Self-Help available • Typical process flow would be • User initiates request • Request is accepted (or rejected as per process) by Service Desk • Necessary Approvals (if not pre-approved) are sought by SD • SD may also order the components (h/w or s/w) if out of stock • When approvals and components are ready, SD delivers the service to user • Service request is closed by SD
  • 215. METRICS User Satisfaction Survey feedback Number of Requests fulfilled
  • 216. ROLES & RESPONSIBILITIES Usually NOT a dedicated role such as Request Manager Request Fulfillment is managed by staff in Service Desk, Incident team or other team as designated by organization Typical responsibilities as per Request Process Flow Mostly Service Desk Manager is accountable
  • 217. SERVICE OPERATION 5 OF 9 ACCESS MANAGEMENT
  • 218. Simply Speaking Access Management = Manage the Access to Services
  • 219. OBJECTIVES • Granting authorized users the access to their Required services • Ensure that the access provided is of Right level • Revoke the access after getting the necessary & relevant approvals • Prevent non-authorized access (from possible sources) NOTE – Access management derives guidance from Information Security Management
  • 220. KEY CONCEPTS Access Level & Extent of functionality that users can enjoy Identity Unique Information about the user which confirms his status within the organization Rights Actual settings which ensure that users get the required access Service & Service Groups Set of services to which users can get the access in one go Directory Services A specific type of tool to help manage the Access or Rights
  • 221. ACTIVITIES • Request Access • Users can request access via, RFC or Service Request via Request Fulfillment or Helpdesk Menu • Verify User Identity • Access Management Team ensures that users are who they say are & they have legitimate requirement for service • Provide Rights • Access team provides the rights to users as per Policies of the organization
  • 222. Monitor Identity Status Monitor users identity status, their change of roles, expiry of valid account etc. Log & Track the Access Ensure the Accesses are logged & data is maintained as per organizations policies Revoke or Restrict Access Revoke/Restrict or modify the rights as per user status & as directed by policies
  • 223. METRICS Meeting Access SLAs Accurate levels of Access Management Any other metrics as asked by Information Security management
  • 224. ROLES & RESPONSIBILITIES • Usually NOT a dedicated staff • Typically carried out by Service Desk staff • May also be managed by • IT Operations Management Staff • Technical Management Staff • Applications Management Staff
  • 225. SERVICE OPERATION 6 OF 9 PROBLEM MANAGEMENT
  • 226. Simply Speaking Problem Management = identify Root Cause of the incident(s)
  • 227. OBJECTIVES To ensure that problems are identified and resolved To eliminate recurring incidents To minimize the impact of the incidents or problems that can not be prevented
  • 228. KEY CONCEPTS • Problem • A root cause of one or more incidents • Problem Model • A model/ set of guidelines to deal with the problems which can not be prevented • Workaround • A temporary solution / Quick Fix which enables to user to continue using the service even though the root cause is not identified/removed • Usually Problem Team suggests workaround & Incident team implements it
  • 229. KEY CONCEPTS…CONTD • Known Error • A Problem for which the root cause is identified and a temporary Work-around has been made available • A Known Error is resolved by eliminating the root cause permanently (E.g. via RFC) • Known Error Database • The purpose of this database is to maintain a record of all the previous incidents, problems & known errors
  • 230. • Reactive Problem Management : • The Reactive Problem Management activities help in identifying the root causes of the Incidents. • Then, these help in suggesting permanent solutions so that these Incidents do not recur. • Proactive Problem Management : • The Proactive Problem Management activities aim at preventing Incidents before they occur. This activity helps identify weaknesses in the IT infrastructure and suggests methods to eliminate these PROBLEM MANAGEMENT TYPES
  • 231. METRICS Number of Incidents reduced by resolving Problems Time needed to resolve Problems % of Problems re-occurred Well maintained KEDB
  • 232. • Problem Manager : who is the overall in-charge of the Problem Management process and is responsible for: • Developing and maintaining the process • Assessing effectiveness of the process • Managing the Problem Support staff • Providing MIS to management • Allocating resources to the Support activities • Support Groups : Are the Support Group Personnel who help the Problem Manager in Reactive and Proactive Problem Management through • Identifying and recording problems • Advising Incident Management team about workaround and fixes • Identifying trends and potential sources of problems • Submitting RFCs to prevent the occurrence • Prevent the replication of problems to multiple systems ROLES & RESPONSIBILITIES
  • 233. SERVICE OPERATION 7 OF 9 IT OPERATIONS MANAGEMENT (FUNCTION)
  • 234. Simply Speaking IT Operations Management = Support day-to-day basic level operational activities
  • 235. OBJECTIVES Ensure the Infrastructure Stability by performing basic level jobs Support day to day operational activities Identify the opportunities to improve overall operational performance & saving costs Initial level diagnosis (& resolution) of operational incidents
  • 236. ACTIVITIES • Basic level activities such as • Backup & Restore jobs, Tape Management • On call (telephone) or Remote Control (Vnc, netmeeting) resolution • Outlook configuration • Facilities Management (e.g. Printer management) • Basic H/W & S/W installations/configurations
  • 237. ROLES & RESPONSIBILITIES • IT Operation Manager • Leadership/Management activities • Management Reports • Shift Leader • Overall in-charge of shift activities • Roaster plans, reports, updates etc. • Analysts • Senior staff with more important workload assigned • Operators • All basic level jobs/ activities
  • 238. SERVICE OPERATION 8 OF 9 TECHNICAL MANAGEMENT (FUNCTION)
  • 239. Simply Speaking Technical Management= Maintain Technical Knowledge & Expertise
  • 240. OBJECTIVES Design of efficient, resilient & cost-effective IT Infrastructure for the organization Maintain Technical Knowledge & Expertise as required to manage this IT Infrastructure Ensure availability of actual technical resources when required especially during failure Other activities/roles within other ITIL processes or as directed by organization Provide technical resources for complete lifecycle i.e. design, build , test, transition , implement & improve
  • 241. KEY CONCEPTS Technical Management Alignment Alignment as per Technical lines for e.g. Mainframes, Networks etc. Activities Manage lifecycle of Organization's IT Infrastructure Maintain Knowledgebase Constantly update Technical expertise
  • 242. ROLES & RESPONSIBILITIES Technical Managers/ Leads / Analysts / Operators / Specialists Leadership/management activities Arranging Trainings, other activities to update the technical knowledge Reporting to senior management Ensure policies/processes are in place for maintaining the technical data/knowledge
  • 243. SERVICE OPERATION 9 OF 9 APPLICATION MANAGEMENT (FUNCTION)
  • 244. Simply Speaking Application Management = Managing Application throughout their Lifecycle
  • 245. OBJECTIVES Identify the requirement of Applications Design efficient, resilient & cost effective applications for managing IT Infrastructure Ensure availability, security of the applications Maintain the operational applications & their day-to-day activities Provide support during Application Failures Improve the functionality of applications as per organization’s needs
  • 246. ACTIVITIES Manage applications throughout their lifecycle Assist Design, Build, Test & implement applications Maintain knowledge & expertise for Managing the applications Make Application resources available May be involved in Development project but it’s not their primary responsibility
  • 247. ROLES & RESPONSIBILITIES • Application Managers / Team Leaders • Leadership & management activities • Reporting to Senior Management • Trainings & other activities to improve expertise & knowledgebase • Application Analysts / Architect • Work with first level users to capture & manage their requirements • Created & maintain standards for Application sizing, performance modeling etc. • Coordinate with Technical Management team as applicable
  • 248. 5. CONTINUAL SERVICE IMPROVEMENT
  • 249. KEY CONCEPTS CSI Model Service Measurement VDJI Structure Types of Metrics 7 Step Improvement Process
  • 251. Service Measurement Ability to capture the performance of an End to End service against Targets/Standards Also helps in prediction of future performance Produces management reports for comparison / Trend
  • 252. Why do we measure? Organization’s Measurement Framework Strategic Vision To Validate Changes Corrective Actions ToIntervene Factual Evidence ToJustify Targets Metrics To Direct
  • 253. Types of Metrics • Technology based Metrics • Typically used for applications, components etc. • E.g. Performance, Downtime • Process based Metrics • Focused on Customer, Processes • E.g. KPI, CSF • Service based Metrics • End to End services • Focused on Supplier • E.g. Gold/bronze package service
  • 254. ROLES & RESPONSIBILITIES • Service Manager ◦ Oversee the development, implementation, Evaluation & Ongoing management of all new & existing products & services ◦ Develops Business Case, Product Line strategy & Architecture ◦ New Service Deployment & lifecycle Schedules ◦ Perform Service Cost Management ◦ Instill a Market Focus
  • 255. 7 Step Improvement Process 1.Define What You should measure 2.Define What You can measure 3.Gather the Data 4.Process the Data 5.Analyze the Data 6.Present & use the Information 7.Implement corrective Actions Goals
  • 256. ROLES & RESPONSIBILITIES • CSI Manager • Drive, Communicate & Coordinate CSI Vision & Initiatives in organization throughout service lifecycle • Oversee & be Accountable for the success of all Improvement initiatives • Constantly work with Process/Service owners to identify Scope of Improvement • Build effective relationships with the Business & IT managers • Ensure Monitoring is in place to gather Data
  • 257. SUMMARY OF ITIL v3 PROCESSES & FUNCTIONS

Editor's Notes

  • #2: Best Practice vs. Good Practice – Good practice could be either the application of Best Practice or could be an input to Best Practice itself.
  • #3: Best Practice vs. Good Practice – Good practice could be either the application of Best Practice or could be an input to Best Practice itself.
  • #7: Best Practice vs. Good Practice – Good practice could be either the application of Best Practice or could be an input to Best Practice itself.
  • #13: Read ALL slides till “IT PROCESSES & POSITIONS”.
  • #14: There can not be >1 person Accountable for any Task. Any single person can not be Accountable & Responsible for the same task.
  • #39: Please see the Roles & Responsibilities of Demand Management
  • #58: 1. More Information: http://servicecatalogs.typepad.com/servicecatalogs/2006/10/gartner_report_.html . 2. Also see Service Portfolio Diagram in Service Portfolio Management section
  • #76: Continuous Operation & Continuous Availability
  • #108: Also discuss Risk Management.
  • #148: An emergency fix normally includes corrections to a small number of Known Errors and the solution is implemented as quick fixes. Consider a situation when a bug is reported in the network communications port on a high usage server. Then as a quick fix to this problem another network port can be installed immediately. A Minor Release includes a number of minor improvements and fixes for Known Errors. Some of these fixes may have been implemented as emergency fixes earlier. Now these fixes are grouped in one Minor Release. Supposes a server crashed frequently due to insufficient memory. Increasing the memory and adding an extra network port can be two emergency fixes combined in one minor release. A Major Release is a major Roll-out of a new software or hardware or significant increase in the functionality of the existing infrastructure. A Major Upgrade or Release usually supersedes all preceding minor upgrades, Releases, and emergency fixes. Consider a situation where a server cannot be upgraded for increasing the functionality. Therefore, it is necessary to add another server and distribute the workload between the two servers. This addition affects the entire division and is a Major Release.
  • #158: Also read NEXT slide.
  • #160: Replaces DSL in v2.
  • #173: Read ALL the types in next few slides.
  • #203: Event Management Forms basis of Operational Monitoring & Control.
  • #204: Alert vs. Event: When the Alerting is completed, it turns into Event
  • #206: Debate - A Failure in RAID. Is it a Warning or Exception? Ans: - No firm answer but a s a thumb rule every Failure should be treated as a Exception.
  • #214: Design & Establish Standard Services Design services based on user needs, cost budget approvals etc. Pre-approve the appropriate changes & establish the approval requirements for other changes Create processes/procedures for availing Standard Service Implement standard services
  • #246: Think of it same as in case of IT Ops management. Note- Applications management is NOT same as Application Development.