ITIL - Final Slides Reliance

Introduction to ITIL / ITSM
CMS Computers Ltd. Copyright 2005
ITSM Foundation R1 15-11-05
Introduction
ITIL gives a detailed description of a number of important IT practices, with comprehensive checklists, tasks, procedures and responsibilities which can be tailored to any IT organization.
ITIL is the best known approach to IT Service Management (ISM) and describes the relationships between the activities in processes.
Introduction
ITIL publications cover a broad subject area and the ITIL processes can be used to set new improvement objectives for the IT organization.
IT Service Management frame works developed on the basis of ITIL:

HP ITSM Reference Model IBM IT Process Model Microsoft Operations Framework, etc.
Introduction
Inputs from The Office of Government Commerce (OGC), formerly
CCTA The IT Service Management Forum (itSMF) and IT organizations and technical experts
Introduction
itSMF :
The objective of the itSMF is to provide a forum for our membership to enable them to exchange views, share experiences and participate in the continuous development and promotion of best practice and standards, through a range of services that delivers significant value to their enterprises.
Why ITIL?
Comprehensive documentation of best practice for IT Service Management. Used by many hundreds of organizations around the world. Generic framework based on the practical experience of a global infrastructure of professional users. Formalization of processes within the organization
Benefits
Benefits of ITIL to the customer / user:
IT services become more customer-focused. Services are described better, in customer language and appropriate detail. Quality, availability, reliability and cost of services are managed better.
Benefits Benefits of ITIL to the organization :

Clearer structure, more efficient and focused on the corporate objectives. More control of the infrastructure and services. Change becomes easier to manage. Provides framework for the effective outsourcing of elements of the IT services. Introduction of quality management systems based on ISO 9000 or BS 15000.
What can go wrong

Introduction can take a long time, significant efforts and change in the organization culture. Lack of fundamental understanding about what the relevant processes should provide, what the appropriate performance indicators are and how processes can be controlled. Improvement of services and cost reductions are not visible, because no baseline data was available for comparison. Insufficient resources, training because the organization is already overloaded by routine IT Service Management activities.
What can go wrong

INDIVIDUAL heroisms must change to TEAM EFFORTS. TECHNOLOGY FOCUS has to change to CUSOMER FOCUS. GUT FEEL decisions to be replaced by FACTS and DATA.
10
Certification Bodies
Certifications Bodies:
EXIN (Exameninstituut voor Informatica) ISEB (Information Systems Examination Board) Professional certification system developed jointly in cooperation with the OGC and itSMF.
11
Certification levels
Foundation Certificate :
For personnel who have to be aware of the major activities in IT service support and delivery, and relationships between them.
12
Practitioner Certificate:
Aimed at the practical level of how to perform a specific ITIL process and the tasks within that process.
13
Manager Certificate :
Intended for those who are required to control all the ITSM processes, to advise on the structure and optimization of the processes, and to implement them in a way that meets the business needs of the organization.
14
What it contains
PDCA Process
Manage Services
Business requirements Customer requirements Request for new Or changed services Other process, Eg. Business Supplier DO Implement Service Management ACT Continuous Improvement
Management Responsibility
PLAN Plan service management
Business Results Customer Satisfaction New or changed service Other process, Business, Supplier, customer Team & People Satisfaction
Service Desk
Other Teams eg Security CHECK Monitor, Measure and Review
15
Clarifications
16
Requirements of ITIL
Process Improvement Model
Where do we Want to be?
Vision and Business objectives Assessment
Where are we? How can we get Where we want To be? How do we know That we have arrived
Process Improvement
Matrics
18
Process
CONTROLS CONTROLS CONTROLS
INPUT ACTIVITIES
INPUT ACTIVITIES OUTPUT
INPUT ACTIVITIES OUTPUT
RESOURCES
RESOURCES
RESOURCES
19
Process Diagram
Standard
Policy
Measurement & Control
Input
Activities
Output
20
IT Customer Relationship Management

Customer Organisation IT Customer Relationship Management Business Managers Tactical Budget holders Strategic Alignment Service Levels Change Requests Sup port IT Managemen t Service Level Management Change Management Incident Management Service Desk Production IT Organisation
Strategic
Policy
Reporting
Operati onal
Department managers Project managers Users
Demand
Supply
21
Planning Horizon
1 year
Business
Applications
Technical Infrastructure
Time
CMS Computers Ltd. Copyright 2005 22
Clarifications
23
ITIL Model
Release Management IT Customer Relationship Management
Change Management
Service Support
Problem Management Incident Management
Configuration Management
Service Level Management Financial Management for IT Services
Capacity Management It Service Continuity Management Availability Management
Service Desk
Service Delivery
Security Management
24
Service Support Processes
Objective
Keeping up-to-date and reliable information about the IT infrastructure and services. Maintaining details of relations between the IT components.
26
Configuration Items (CI)
All IT components, services and documentations to be controlled by the organization. Ex: PC hardware, software, network components, SLAs etc.
Configuration Management Database (CMDB)

A database of all the CIs. It keeps track of all the IT components, their versions, status and relationships between them.
27
Configuration Management Activities
The configuration Management activities includes
Planning-Scope, Objectives, Policies, standards, roles and responsibilities. Identification-processes to keep the database up-to-date. Control-Unauthorized modifications of CIs. Status Accounting Current and historical details of CIs. Verification and audit Accuracy of records. Reporting Provides information to other processes.
28
Configuration Management Planning
Requirements for Accountability, Traceability and Auditability. Configuration control

Access Protection Version Build Release controls
29
Configuration Management Planning (CMP)
The configuration Management should be carried out by a responsible manager. He should be
Accountable for CMP implementation Provided with necessary information
30
Configuration Identification
Configuration Items should be

uniquely identified defined by attributes (functional and physical) auditable recorded in CMDB
31
CIs to be managed should be identified and should include
All issues and releases of Information System and software and related documentations
Requirements Specifications Designs Test Reports Release documentations Third Party Software
32
Configuration baseline or build statements for each applicable environment, standard hardware builds and releases.
Master copy and electronic libraries (software library) Configuration Management Tools used Licenses Security Components (Like firewalls, IDs)
33
Physical assets that need to be tracked for financial asset management (e.g. magnetic media, equipment)
Service related documentation (SLA, Procedures) Service supporting facilities (power to comp. room) Relationships and dependencies between CIs Traceability matrix to be maintained where ever traceability is a requirement
34
CMDB Development

Scope of CMDB (Breadth of CMDB) Level of Breakdown (Depth of CMDB) Level of Detail (Attributes)
35
Scope Of CMDB (BREADTH)
Scope
CI #1
IT Infrastructure
Service A Service B
CI #2
CI #3
Application A
PABX
PABX
CI #4
CI #6
Module A
CI #5
System 21
CI #7
Line 1, digital Line 2, digital Line 3, analog

36
NIC 12
CI #8
Module B
Modem 5
CMDB Level of breakdown (depth)
IT Infrastructure
Hardware
Software
Network
Documentation
Suite 1
Suite 2
Program 1-1
Program 1-2
Program 1-3
Module 1-2-1
Module 1-2-2
37
CMDB Level of Detail (Attributes)
ATTRIBUTE CI number/label/bar code Copy or serial number Audit tool identification No. Model number/catalog reference Model name Manufacturer Category Type Warranty expiry date Version Number Location RFC numbers Change numbers Problem numbers Incident numbers
ATTRIBUTE Owner responsible Responsibility date Source / Supplier License Supply date Accepted date Status (current) Status (scheduled) Cost Residual value after depreciation Comment Parent CI relationship Child CI relationship Other relationships
38
CI Relationships
Relationships between CIs should be maintained for diagnosing errors and impact analysis.
Physical relationships : E.g. Forms part of, Is connected to, Is needed for
Logical relationships : E.g. Is a copy of, Relates to, Is used by
39
CI Variants

A version that is an alternative of another version One item version is a variant of another, if neither is a revision of the other
Variants are recorded in the CMDB

Ex. A PC available with two types of hard disk could occur as Variant A and Variant B
40
Configuration Status Accounting

Configuration records should be maintained to reflect Changes in the status, location and versions of configuration items. Historical data concerned with each CI throughout its lifecycle. Tracking CI changes through various states
E.g. ordered, received, in acceptance, test, live, under change, withdrawn, disposed
41
Configuration Baselines A snapshot of a group of CIs taken at a specific point in time. It can be used as:
An authorized product that can be included in the IT infrastructure. Starting point for development and testing of new configuration. A back-out if there are problems with new configuration after changes. A standard for supplying configurations to users, e.g. a standard workstation
42
Planned / on order Received / on stock Tested Implemented Operational Maintenance Archived
Time
43
Configuration records should be accessible to appropriate
Users Customers Suppliers Partners
For appropriate planning and decision making
44
Configuration Control
The degree of control should be based on
Business needs Risk of failure Service criticality
45
Configuration Control
Following actions are monitored by configuration Management to ensure actual situation reflects in CMDB

CI is added, removed CI changes its status, owner CI changes in relationship with another CI CI license is renewed or modified CI details are updated after an audit
46
Configuration Verification And Audit
Configuration Audit should be carried out

Regularly on periodic basis Before and after major change After a disaster Random intervals
47
Configuration Verification And Audit
Configuration Audit deficiencies and nonconformities should be

Recorded Assessed Corrective action instigated Acted upon Fed back to relevant parties
48
Configuration Management Reports
Configuration Management reports should cover

Identification of the CI Status of the CI Latest CI Versions Location of CI Location of master version in case of software Interdependencies Version history Associated documentation
49
Benefits
Configuration Management contributes by

Managing IT components Effective problem solving More rapid processing of changes Better control of Software and Hardware Compliance with legal requirements More precise expenditure planning Support for Availability and Capacity Management Solid foundation for IT Service Continuity Management
50
Configuration Management v/s Asset Management
Asset Management
Accounting process for monitoring asset whose purchase price exceeds a defined limit. Details purchase price, depreciation, business unit and location. Provides basis for Configuration Management Systems.
Goes beyond Asset Management and keeps technical information about CIs, and relationship with CIs.
51
Configuration Management-Current Assessment
Maximum Attainable Score Your Score CMS Computers Ltd. Copyright 2005
52
Clarifications
53
Incident Management
Incident Management
Incident
Any event which is not part of the standard operation of a service and which causes an interruption or reduction in the quality of that service.
Incident Management Should Be

Proactive (Responding to potential incidents) Reactive (responding to incidents) Concerned with restoration of customer service cause) (Not
55
Incident Management
Scope of Incidents
Incidents include not only hardware and software errors, but also Service Requests.
Service Requests
Request from a user for support, delivery, information, advice or documentation, not being a failure in the IT infrastructure.
56
Incident Management
Resolution Targets
Resolution targets are to be identified for Incidents and Problems.
Basis for Resolution Targets

Resolution targets are to be based on Priority.
57
Incident Management
Priorities
Priorities should to be based on IMPACT and URGENCY
Impact
Impact is based on actual or potential damage to customers business
Urgency
Urgency is based on the time between problem or incident being detected and the time that the customers business is impacted.
58
Incident Management
Example of a priority coding system
IMPACT
Priority Resolution time
High
critical
< 1 hour
Medium
high
< 8 hours
Low
medium
<24 hours
URGENCY
High Medium Low
high
< 8 hours
medium
<24 hours
low
<48 hours
medium
<24 hours
low
<48 hours
planning
planned
59
Incident Management
Scheduling
Scheduling of Incidents or Problem Resolution should take into account

Priority Competing requirements for resources Efforts / Cost for providing resolution Response Time (time to provide method for resolution)
60
Incident Management
Escalation

Functional Escalation Hierarchical Escalation Function Escalation
Involving personnel with more specialist skills, time or access privileges to solve the incident
Hierarchical Escalation
Involving an higher level of Organizational authority, when current level of authority appears insufficient.
61
Incident Management
Functional Escalation Matrix
Level Contact Person 1 2 3 Service Desk Management Departments Software Developers and Architects Suppliers Address xxx xxx xxx Contact Nos. xxxxx xxxxx xxxxx Hrs to escalation Logging 3 8
xxx
xxxxx
16
62
Incident Management
Hierarchical Escalation Matrix
Level Contact Person 1 2 3 4 CCE Field Engineer Area Manager Project Manager Address xxx xxx xxx xxx Contact Nos. xxxxx xxxxx xxxxx xxxxx Hrs to escalation Call Logging 3 8 16
63
Incident Management
First, Second and Nth-Line Support
Typically:

First-line support (or tier 1 support) Service Desk Second-line support Management departments Third-line support software developers and architects Forth-line support Supplier
Depending upon the organization size, the support levels are less or more.
64
Incident Management
Incident Management Activities

Detection and recording Call reception, recording, priority Classification and first-line support Category and Category Type Matching Similar Incidents Investigation and Diagnosis Support group with more expertise and technical competence Resolution and Recovery Record the solution or raise RFC Closure Inform and update Progress tracking and monitoring Service Desk
65
Incident Management
Incident Management Process

Incident reporting Retrieval and Analysis of Incident Reporting Progress in Incident Resolution Recording of Actions taken Means to continue Customers Business (Example: Degraded Service) Establishment of Workaround in case of undiagnosed causes Closure of an Incident
66
Incident Management
Incident Management Staff should have access to upto date knowledge base holding information on

Technical specialist Previous Incidents Related Problems Known Errors Workarounds Checklists CMDB
67
Incident Management
Incident Management Works closely with
Configuration Management Database (CMDB) Problem / Known Error Database (KEDB) Service Level Management (SLM) Problem Management
68
Incident Management
Benefits
For the Business
Timely resolution of incidents resulting in reduced business impact Improved user productivity Independent, Customer focused incident monitoring Availability of SLA-focused business management information
69
Incident Management
Benefits
For the IT Organization
Improved monitoring, allowing performance against SLAs to be accurately measured Better and more efficient use of the personnel No lost or incorrectly registered incidents More accurate CMDB Improved user and customer satisfaction
70
Problem Management
Problem Management
Problem Management
The Identification and management of the underlying causes of service incidents whilst minimizing or preventing disruption to the customers.
Scope Of Problem Management

Investigate the underlying causes of Incidents Proactively prevent the recurrence or replication of incidents or Known Errors wrt Business requirements
72
Problem Management
Known Error
When root cause of an incident is known and a temporary workaround has been identified, the problem should be classified as Known Error.
Known Error Should Be

Recorded against current and Potentially affected services. Maintained in a Knowledge base along with workaround. Closed after successful resolution
73
Problem Management
What is Workarounds? The process by which service restoration can be enabled by users of staff is called Workaround
When root cause of an incident is identified and a method of resolving the incident is available, the problem should be classified as Known Error.
Development and maintenance of Workarounds

Applicable only for known errors Corrective Action has been successfully applied Information on workaround stored in knowledge base Applicability and Effectiveness should be stored and maintained
74
Problem Management
Problem Management Inputs
Inputs to Problem Management are:

Details of incidents, including workarounds Configuration details from CMDB Service Catalogue and SLAs
Problem Management Outputs

Updated known error database RFCs Up-to-date problem records Management Information
75
Problem Management
Problem Management Activities
Problem Control Error Control Proactive Problem Management Providing Information
76
Problem Management
Problem Control
Objective: To turn problems into known errors by identifying the underlying cause and identify a workaround
1. 2. 3. 4. 5.
Problem identification and recording Classification Investigation and diagnosis RFCs for temporary fixes Error Control
77
Problem Management
Problem Control
Tracking and monitoring of Problems
Problem Identification and recording
Problem Classification
Problem Investigation and diagnosis
RFC and Problem Resolution and closure

( Error control )
78
Problem Management
Error Control
Objective: To manage known errors until they are successfully resolved, were possible and appropriate.
1. 2. 3. 4. 5.
Error identification and recording Assessment and investigation Determining solution and recording Post-Implementation Review (PIR) Tracking and monitoring
79
Problem Management
Error Control
Tracking and monitoring of Problems
( Problem control )
Error Identification and recording
Error Assessment
Record Error Resolution
RFC
Close Error and Associated Problems ( s )

80
Problem Management
Proactive Problem Management
Proactive problem management should lead to reduction in incidents and problems. It should include analysis of :

Asset and configuration Trends and identification of potential incidents Published known Error, workaround information from suppliers
Historical information on similar problems

81
Problem Management
Proactive Problem Management
Problem prevention may also include
Providing information to customer
(Customer need not ask for assistance in the future)

Preventing incidents caused by lack of user knowledge or training
82
Problem Management
Providing Information

Communications should be made about Workarounds to Incident Management Permanent Fixes Progress of problems to users via Service Desk
Tracking And Escalation

Progress of all problems should be tracked. Escalation of issues to appropriate parties as defined in SLA
83
Problem Management
Problem Reviews
Problem reviews should be held wherever justified necessary like
Investigation Unusual High
to unresolved problems
problems
impact problems
Purpose Of Problem Reviews

Purpose of Problem reviews should be to
Seek
Improvements to processes recurrence of incidents and mistakes
Prevent
84
Problem Management
Functions And Roles
Responsibilities of personnel with problem support role
Identifying and recording problems by analyzing incident details Investigation and managing problems based on priority Raising RFCs Monitoring progress of known errors Conducting major problem reviews Identifying trends Preventing problems spreading to other systems
85
Problem Management
Functions And Roles
Responsibilities Problem Manager
Developing and maintaining problem control and error control procedures and assess their effectiveness Providing management information for proactive problem management Obtaining resources for activities Monitoring progress of known errors Conducting Post Mortems or major problem reviews Analyzing and evaluating the effectiveness of Proactive Problem Management
86
Problem Management
Incident And Problem Record Closure
The record closure procedure should include checking to ensure that

Details of resolution have been accurately logged. That the cause is categorized to facilitate analysis If appropriate, both the customer and support staff are aware of the resolution.
The customer agrees that the resolution has been achieved If a resolution is not to be achieved or not possible, the customer is informed.
87
Problem Management
Benefits
Problem Management ensures that

Failures are identified, documented, tracked and resolved Permanent or temporary solutions for failures are documented Request for Changes are raised to modify the Infrastructure Avoidable incidents are prevented Reports are issued about the quality of the IT infrastructure and process
88
Service Desk
ITIL Model
Service Support
Problem Management
Change Management
Incident Management
Service Desk
Service Delivery
Security Management
90
Service Desk
Objective
To support the provision of the services that have been agreed by guaranteeing access to the IT organization and undertaking a range of support activities
91
Service Desk
Service desk handles activities related to

Incident Management Software and hardware installation Release Management or Change Management Verification of caller details and allocated resources Configuration Management Activities concerning standard requests Change Management Information to the users about the services they are entitled to as specified in the SLA
92
Service Desk
Service Desk

Single point of contact Monitoring / tracking of status of incidents recorded Handling Service requests
93
Service Desk
Structure

Accessibility Business support (infrastructure, application) Service desk types

Centralized Local (distributed) Virtual
94
Service Desk
Service Desk Personnel

Call Center Calls routed to specialist dept Unskilled Calls recorded and immediately assigned. Skilled Better skills and experience. Some incidents resolved and others passed on.
Expert Specialist knowledge of full IT infrastructure and expertise.
95
Service Desk
How Are Incidents Reported?

Telephone calls Voice mails Visits Letters Faxes Emails Recording systems Automated monitoring Softwares
96
Service Desk
Activities

Responding to calls Incidents (incl. Service request and standard changes) Providing information Passively (bulletin board) Actively (emails, on-screen log-in messages etc) Supplier liaison (Contacts with maintenance suppliers) Operational management tasks (backups, disk space management, LAN connections) Infrastructure monitoring (Tools which estimate the impact of faults)
97
Service Desk
Performance Indicators for an effective Service Desk

Time within which calls are answered. Call escalations as specified Restoration of service within acceptable time and in accordance with the SLA Timely information to users about current and future changes and errors. Conduct customer surveys to determine
Is the telephone answered courteously? Are users given good advice to prevent incidents?
98
Service Desk
Management Reports
The Service Desk should regularly verify
Percentage of incidents closed without resorting to other levels Number of calls handled per workstations and in total Average incident resolution time (with elapsed time and time actually spent on the call) EPABX reports (Avg. answer time, call duration, abandoned calls) Standards can be set for these metrics and then measured, evaluated.
99
Service Desk
Critical Success Factors
Bring the Service Desk upto a required level before running a publicity campaign. If users contact specialists directly, they should always be referred to the Service Desk. There should be good SLAs and OLAs and service catalogue in place to ensure that the support provided by the Service Desk has a clear focus.
100
Service Desk
Present Process

ITIL Processes

Termed as Help Desk Calls are only recorded No first level support
Termed as Service Desk Incidents are classified (Monitor Incident lifecycle) Restoration of service within acceptable time and in accordance with the SLA
101
Service Desk-Current Assessment
102
Clarifications
103
Change Management
Change Management
Change Management
To ensure that all changes are assessed, approved, implemented and reviewed in a controlled manner.
105
Change Management
Change Authorities
Change Manager
Responsible for filtering, accepting and classifying all RFC Supported by change coordinators Responsible for planning and coordinating the implementation of the changes.
Change Management is responsible for obtaining the required authorization for implementation of change
106
Change Management
Change Authorities
Change Advisory Board (CAB)
Consultative body which meets regularly to authorize, assess, prioritize and plan changes Mainly concerned with significant changes A CAB/EC (Emergency Committee) should be appointed with authority to make emergency decisions Consists of representatives from all IT sections eg. Change Manager, IT Line Managers, Business Managers, Incident and Problem Managers, User group
107
Change Management
Standard Change
Routine Management tasks, covered by procedures are not controlled by Change Management
Covered by Change Models

Creating user ID Changing network connections Installing PCs
Handled as Service Request under Incident Management
108
Change Management
Inputs for Change Management

RFCs CMDB Information (esp. impact analysis) Information from other processes (capacity, budget) Change planning (Forward Schedule of Change: FSC)
Outputs

Updated change planning (FSC) Triggers for CMDB and Release Management CAB agenda, minutes and action items Change management reports
109
Change Management
Change Management Scheduling (FSC)
The Change Management Scheduling to cover

Status of changes Scheduled Implementation dates Release Scheduling
Change Management Scheduling should be available with

All affected person All affected person considering an outage, with prior approval of affected person
110
Change Management
Change Management Planning
The Change Management Procedure should ensure

Changes have a clearly defined and documented scope Only changes that have business benefits are approved Changes are scheduled based on priority and risk The time to implement the changes is monitored and improved where required
111
Change Management
Activities Change Management uses the following activities to process changes :

Recording Acceptance (filtering for further consideration) Classification (based on category and priority) Planning and Approval (consolidating changes) Coordination (building, testing and implementation) Evaluation
112
Change Management
Recording
All RFCs are recorded or logged
Can be submitted by anyone working with the infrastructure. Ex. Problem Management, Customers, other IT personnel
Details that can be included in RFC

ID number Associated problem number, ID of CI Reason for change & business benefit Name, location, phone no. of person submitting the RFC
113
Change Management
Acceptance
Change Management will make initial assessment to check if RFCs are unclear, impractical or unnecessary. If accepted, the information required for the further processing of the change is included in a change record
114
Change Management
Change Classification
Change is classified based on Category and Priority
Category Impact Cost Risks Availability of res. Priority Urgency Benefits (Business Needs)
On changes to Service, Customer and Release Plans

115
Change Management
Change Management Implementation
Priority Level Priority 1 2 3 4 Low Normal High Highest Description Can Wait No great Urgency Affecting number of users Essential Services
116
Change Management
Change Management Implementation
Category Level Category 1 2 3 Description
Minor Impact Little Efforts with Little Risk* Substantial Impact Significant Efforts with substantial Impact@
Major Impact Large Effort and Major Impact^
* @ ^
CAB Approval may not be required CAB Approval will be required IT Steering Committee and CAB approval may be required.
117
Change Management
Planning And Approval
Changes are planned using a change calendar or FSC Major changes have to be approved by the IT management, before being presented to the CAB. The approval can consist of

Financial approval cost/benefit analysis and budget Technical approval impact, necessity and feasibility Business approval approval by customers
118
Change Management
Change Management Coordination
The change management process should demonstrate how a change is

Reversed or remedied if unsuccessful (back out plan) Documented

RFC is linked to affected CI RFC is linked to updated version of implementations RFC is linked to updated Release Plans
119
Change Management
Evaluation
Major changes shall have a post Implementation review to ensure that

Change met its objectives The customers are happy with the results There have been no unexpected side effects
Non-conformities are identified, recorded and action taken
120
Change Management
Change Request(RFC) Closure
The Change Request should be formally Closed and reviewed. (after Post Implementation Review (PIR))
Change Request(RFC) Review

Change Request should be reviewed after implementation for
success failure improvements
121
Change Management
Emergency Changes

Frame work for Emergency Changes should be addressed Where ever possible change process should be followed Wherever changes have been bypassed, the changes should be confirmed as soon as practicable
Emergency changes should be

Justified by the implementer Reviewed after change for True Emergency

122
Change Management
Change Management Reporting

Regular Analysis of Change Records are required for To detect increasing levels of changes Frequently recurring types Emerging trends Other relevant Information
Change Management Analysis and Actions

Should be recorded Should be acted upon
123
Change Management
Key Performance Indicators (KPI)
Number of changes completed per time unit, by category Number of incidents resulting from changes Number of back outs related to changes Cost Number of changes within resource and time estimation
124
Change Management
Benefits
Reduced adverse impact of changes on the quality of IT services Fewer changes are reversed, and any back-outs that are implemented proceed more smoothly Enhanced management information is obtained about changes, enabling diagnosis of problem areas Improved user productivity through stable IT services Increased ability to accommodate frequent changes without creating an unstable IT environment
125
Clarifications !!!
126
Release Management
Release Process
Release Set of new and/or changed Configuration Items, which are tested and introduced into the live environment together.
Release Management A planned project style approach to implementing changes in IT services, which address all aspects of the changes.
128
Release Management
Release Levels
Major releases (V1)
Increased fun. And Eliminates Known errors, workarounds and temporary fixes
Minor releases (V1.1)
Minor improvements and fixes of Known errors
Emergency fixes (V1.1.1)
Temporary fix for problem or Known error
129
Release Management
Release Units
The portion of the IT infrastructure that is released together for control and effectiveness of the change made
Release Identification

Development Environment Test Environment Production Environment Archive Environment

130
Release Management
Release Types
Delta Release

Not possible to test all the links in software Unwanted modules are not deleted
Full Release
All components of Release Unit are built, tested and distributed including components that are not changed.
Package Release
Bundle of Full and Delta Release and new functionalities.
131
Release Management
Definitive Software Library (DSL)
Repository of authorized versions (master copies of software CIs) May be physically in many locations Made up of secure media and fireproof safes DSL may have several versions of the same software, including archive versions, documentation and source code. DSL should be backed up regularly In case of multi-sites, each site will have a copy of the DSL for rolling out software.
132
Release Management
Definitive Hardware Store (DHS)
Contains spares and stocks of hardware Details and composition to be available in CMDB
CMDB gets updated information from

Software versions from DSL Hardware versions from DHS
133
Release Management
Release Management Process consist of

Release policy and Planning Design, building and configuration Testing and release acceptance Rollout planning Communication, preparation and training Distribution and installation
134
Release Management
Release Policy and Planning
For each system, the Release Manager should develop a release policy defining how and when releases are configured. Eg: Major releases can be planned ahead together so that additional changes can be considered at app. times
Following issues are to be considered while planning

Content of the release Drawing up the release schedule, comm. Plan Site visits to determine the h/w and s/w in actual use Agreeing to roles and responsibilities Drawing up back-out plans, quality plans
135
Release Management
Design, Build and Configure Release
Release and distribution should be designed and implemented to
Risks are clearly identified and remedial actions can be taken if required Enable verification that the target platform satisfies prerequisites before installation Enable verification that a release is complete when it reaches its destination.
136
Release Management
Design, Build and Configure Release
Output of this process should include

Release Notes Installation Instructions Installed h/w and s/w with related configuration baseline
Output of the process should be handed over to group responsible for testing Automating the build, installation, release distribution process to aid repeatability and efficiency
137
Release Management
Testing and Release Acceptance
Release should undergo
Functional test by rep. of users Operational test by IT management personnel
Change management must arrange formal acceptance by users and sign-off by the developers
Output of this activity should include

Tested installation procedures, known errors Test results, list of affected systems, back out plans Training program, signed acceptance documents
138
Release Management
Roll Out Planning
Rollout Planning includes

Drawing a schedule, list of tasks and req. resources List of CIs to be installed and to be phased out Activity plan for each implementation site Communication to relevant parties Drawing plans for purchase of h/w and s/w Scheduling update/review meetings with management, departments, change management and user representatives
139
Release Management
Roll Out Planning Ways to implement a rollout

Big Bang approach Release can be rolled out in full Functional increments All users get new functions at the same time
Site increments Groups of users are dealt with Evolutionary Functions are expanded in stages
140
Release Management
Communication, Preparation and Training
Service desk, operational personnel should be made aware of he plans. Training to be provided to deal with change of routine activities. Changes to SLA, OLA and UC should be communicated in advance to all relevant personnel
141
Release Management
Distribution and Installation
Automated tools for software distribution and installation where possible Tools will also facilitate verification of successful installation Check if the environment fulfills the conditions. Eg disk space, security, environmental controls, UPS etc. Information in the CMDB should be updated after installation
142
Release Management
Release Management should

Be integrated with Configuration and Change Management Ensure all associated updates to documentation is included in the release
Impact of all new or changed CI should be assessed Consider technical and non technical aspect of the change Ensure that Release items are traceable Ensure that Release items are secure from modification Accept only suitably tested and approved releases into live environments
143
Release Management
Benefits

Release Management helps to ensure that The s/w and h/w used in the live environment are of high quality The risk of errors in s/w and h/w combination is minimized There are fewer separate implementations and each implementations is thoroughly tested Users are more involved in the testing of a release A release calendar is published in advance
144
Release Management-Current Assessment
145
Clarifications !!!
146
Service Delivery Processes
ITIL Model
Change Management
Service Support
Problem Management Incident Management
Service Desk
Service Delivery
Security Management
148
Service
Scope:

Support business needs Present new options
At an Acceptable cost
Through

Continuous interaction with the customer Regular reviews of business needs Technological developments
149
Service
Service delivery refers to:
The services the customer needs to support the business What is needed to provide these services
150
Service Delivery
Processes defined are :

Service Level Management Capacity Management IT Service Continuity Management Availability Management IT Security Management Financial Management for IT Services
151
Service Level Management


Definition
Service-level management is the set of people and systems that allows the organization to ensure that the agreed quality of services are being met and that the necessary resources are being provided efficiently
153

Who is the CUSTOMER?
The CUSTOMER is the representative of the organization who is authorized to make agreements on behalf of that organization about obtaining IT services.
154

Who is the PROVIDER?
The PROVIDER is the representative of the organisation who is authorized to make agreements on behalf of that organisation about the provision of IT services.
155

Activities:
Identify Define Formalize Monitor Report Review
Levels of service
156

Identify

Business needs Business processes Business plans Service level

Service Level
Budget
Requirements (SLR)
157

Service Level Requirements (SLR)

Function to be provided by the service Times and days the service must be available Service continuity requirements IT functions needed to provide the service Operational methods/quality standards
158

Define

Name of each service Scope of each service Depth of each service Operational level agreements
Service
Underpinning contracts
Specification Sheet Service Quality Plan
159

Service specification Sheet (Spec Sheet)
Technical specifications of each service Delivery and implementation procedure Quality control procedure
160

Service Quality Plan (SQP)
For each service define:

Critical success Factors Key Performance Indicators
161

Formalize
Negotiate Draft Amend Conclude
Service Catalogue Service Level Agreement (SLA) Operational Level Agreement (OLA) Underpinning Contract (UC)
162

Service Catalogue Define for each service:

Name and functions Benchmarks, targets and metrics Acceptable and unacceptable levels of service Reporting procedures Actions in exceptional circumstances Communication and escalation lines
163

Service Catalogue Should have:

Customer friendly language Relevant terminology Attractive layout Easily available
164

Service Level Agreement (SLA)
Service Level Agreement is a Contract between a customer organisation and the IT service organisation to provide a range of support services up to an agreed minimum standard.
165

Service Level Agreement (SLA)
Contents:

Introduction Scope of work Performance Tracking and Reporting Problem Management Compensation and penalties Customer duties and responsibilities
166

Monitor

Technical Aspects Functional Aspects Procedural Aspects

Service Level Achievement
167

Service Level Achievement

Capacity Availability Supply Procedure Reporting Procedure Customers perception
168

Report

Performance reports Generated a intervals agreed in SLA Exception reports when required Provided to Customers, Process Managers and Management
Service Level Reports
169

Service Level Report

Availability and Downtime Response and Resolution Time Volume during peak times Number of completed and open changes Cost of the service provided Proportion of service capacity used
170

Review

Performance reports Service Trends SLA Technology Business environment Business Plans
Service Improvement Plan
171

Service Improvement Plan (SIP)

Allocating additional personnel and resources Modifying service levels in SLA Modifying OLAs and Ucs Modifying procedures Training
172

External Documents

Service Level Requirements Service Level Agreements Service Catalogues
Internal Documents

Service Specification Sheets Operational Level Agreements (OLA) Underpinning Contracts (UC)
173
Capacity Management
Capacity Management
Definition
Capacity Management is the proactive process of planning, analyzing, sizing and optimizing IT resource capacity to satisfy demand in a timely manner and at a reasonable cost.
175
Capacity Management
Addresses:
Cost versus Capacity Can the purchase of capacity be justified in the light of business requirements?
176
Capacity Management
Addresses:
Supply versus Demand Does the current processing capacity adequately fulfill both current and future demands of the customer
177
Capacity Management
Addresses:
Performance Tuning Is the processing capacity performing at peak efficiency?
178
Capacity Management
The three sub-processes are:

Business Capacity Management (BCM) Service Capacity Management (SCM) Resource Capacity Management (RCM)
179
Capacity Management
Business Capacity Management
Evaluation of current business, financial, economic and technology indicators with the goal of forecasting future business load placed on the IT system by business needs. The goal is to plan and implement projects to achieve necessary capacity on time and at an appropriate cost and risk.
180
Capacity Management
Service Capacity Management
Evaluates and bases short term strategy and tactical response to service related issues and needs. The goal is to profile and meet the needs of specific services on end-to-end basis in order to remain in compliance with SLA.
181
Capacity Management
Resource Capacity Management
Evaluates and analyses the use of the IT infrastructure and components that have a finite resource. The goal is to manage the capacity and performance of individual components within the IT infrastructure.
182
Capacity Management
Activities:
Developing a Capacity Plan Describe the current and future requirements for capacity of the IT infrastructure and the expected changes in demand for IT services and the associated costs.
183
Capacity Management
Capacity Plan documents:

Capacity Requirements Current and Future Performance Expectations Current and Future Replacements Outdated and defective Items Technical Developments Costs New or/and Changed Services
Updated annually and reviewed quarterly

184
Capacity Management
Activities:
Modeling Determine the capacity requirements of services and best capacity solutions using measuring and estimating tools to extensive prototyping tools. Modeling allows various scenarios to be analyzed and the what-if questions addressed.
185
Capacity Management
Activities:
Modeling Rule of Thumb: This is the cheapest way of determining the best capacity solution and is based on experience and current resource utilization. Accuracy depends on the ability and skills of the analyst
186
Capacity Management
Activities:
Modeling Linear Projection: This involves trend analysis based on resource utilization. Analytical Modeling: This involves algorithms based on IT service data, typically involves elaborate software that generates predictive and proactive capacity information
187
Capacity Management
Activities:
Modeling Simulation Modeling: This is usually more accurate than analytical modeling since it provides greater capabilities and more closely emulates the application. Simulation modeling may require significantly more time and cost to prepare scripts and generate realistic transaction loads.
188
Capacity Management
Activities:
Modeling Baseline Assessment: A baseline model accurately reflects the performance levels and workload characteristics of the current system. This can allow predictive what-if scenarios with planned changes to resources under a variety of workloads. A good prediction of performance levels depends on the accuracy of the baseline model.
189
Capacity Management
Activities:
Modeling Actual System: This involves the actual operating environment to predict the performance requirements.
190
Capacity Management
Activities:
Application Sizing Determine the hardware or network capacity needed to support new or modified services and the predicted future load along with the costs.
191
Capacity Management
Activities:
Monitoring The utilization of each resource and service is monitored on an ongoing basis to ensure that hardware and software resources are being used optimally and that all agreed-upon service levels can be achieved.
192
Capacity Management
Activities:
Analysis Data monitored and collected is analyzed and used to carry out tuning exercises and establish profiles. These profiles are important since they allow the proper identification and adjustment of thresholds and alarms. When exception reports or alarms are raised, they need to be analyzed and reported upon, and corrective action needs to be taken.
193
Capacity Management
Activities:
Tuning Analysis of the monitored data may identify areas of the configuration that could be tuned to better use the system resource or improve the performance of the particular service. Tuning optimizes systems for the actual or expected workload on the basis of interpreted monitoring data.
194
Capacity Management
Activities:
Implementation This activity includes the identification of necessary change (changed or new capacity), and subsequent generation and approval of a change request. The implementation of any change should be done through formal change management processes.
195
Capacity Management
Activities:
Demand Management This activity aims to influence the demand for capacity. This can involve differential charging to influence user behavior by controlling demand during periods of high usage.
196
Capacity Management
Activities:
Populating the Capacity Database (CDB) Contains the detailed technical, business, and service level management data that supports the capacity management process. The resource and service performance data in the database can be used for trend analysis and for forecasting and planning.
197
Capacity Management
Capacity Management Database :
Business Forecasts Business Forecasts Business Forecasts Business Forecasts
CDB
Management Reports
Capacity Plans
Technical Reports
198
Continuity Management
IT Service Continuity Management

Definition
The objective of ITSCM is to support the overall Business Continuity Management (BCM) by ensuring that the required IT infrastructure and IT services, including support and Service Desk can be restored within specified time limit after a disaster.
200

Disaster
An event that affects a service or a system such that significant effort is required to restore the original performance level. Eg. Fire, water damage, burglary, vandalism and violence, large scale power outage
201

Activities

Defining the scope of ITSCM Business Impact Analysis Risk Assessment IT Service Continuity Strategy Organization and implementation planning Prevention measures and recovery measures Developing plans and procedures for recovery
202

Activities

Initial Testing Training and awareness Review and audit Testing Change Management Assurance
203

Business
BIA is the first step in developing the business continuity plan (BCP). This phase involves identifying the various events that could impact the continuity of operations and their financial, human and reputational impact on the organization.
204

Business Impact Analysis (BIA)
Identify the IT services essential to the business and must be available Identify the IT resources that perform these services Identify the recovery time period for IT resources in which business processes must be resumed before significant losses are suffered
205

Business Impact Analysis (BIA)
Identify reason for the company to include ITSCM in BCM (Business Capacity Management)
The business can survive for some time and emphasis will be on restoring services. The business can not operate without IT services and the emphasis will be on prevention.
206

Risk Assessment
Risk Analysis: Identify the risks that a business is exposed to Risk Management: Identify the counter measures to mitigate the risks
207

Risk Analysis

Rank relevant IT components (assets) Analyze the threats to those assets Estimate likelihood (high, medium, low) that a disaster will occur Identify and classify the vulnerabilities Evaluate the threats and vulnerabilities to provide an estimate of the level of the risks
208

IT Service Continuity Strategy
Business should strike a balance between:
Risk reduction (prevention) Recovery planning (recovery options)
209

Prevention measures aim to reduce the likelihood or impact of contingencies and therefore narrow the scope of the recovery plan. Eg. Measures against dust, temperature variations, fire, leaks, power outages, burglary or the most extensive Stronghold/Fortress Approach
210

Risks that are not eliminated by prevention measures are addressed through recovery planning. Recovery options to be provided for:
Personnel and accommodation alternative premise, furniture, transport and travels, essential staff etc. Support services power, water, telephone, post and courier services
211

Recovery options to be provided for:
Archives files, documents, paper-based systems and reference materials Third-party Services email and internet service providers IT Systems and Networks
212

Recovery options for rapid recovery of IT Systems and Network Services:

Do nothing Return to manual (paper based) system Reciprocal arrangements Gradual recovery (Cold site) fixed/mobile Intermediate recovery (Warm site) fixed/mobile Immediate recovery (Hot site) fixed/mobile Combination of options
213

Organisation and Implementation Planning
Highest level plans:

Emergency response plan Damage assessment plan Recovery plan Vital records plan Crisis Management and PR plans
These plans are used to assess emergencies and to respond to them

214

Organisation and Implementation Planning
Second level plans:

Accommodation and services plan Computer system and network plan Telecomm. Plan (accessibility and links) Security plan (integrity of data and network) Crisis Management and PR plans
215

Prevention measures and recovery options
Preventive measures identified earlier are implemented. Prevention measures to reduce the impact of an incident are taken in conjunction with Availability Management and may include:

Use of UPS and backup power supplies Fault tolerant systems, alternative routing Off-site storage and RAID systems, etc.
216

Prevention measures and recovery options
Recovery measures identified earlier are put into practice. Stand-by agreements negotiated and formalized for:

Off-site recovery facilities with third parties Maintaining and equipping the recovery facility Purchasing and installing stand-by hardware (Dormant contracts)
217

Developing plans and procedures for recovery
The recovery plans should be detailed and subject to formal Change control. It should include all elements relevant to restoring the business activities and IT services and should be communicated to all those involved in, or affected by the plans.
218

Plan should include:
Introduction structure of the plan and envisaged recovery facilities Updating procedures and agreements for maintaining the plan and tracks changes to the infrastructure Routing list identify teams for specific activity Recovery initiation when and under what condition the plan is invoked
219

Plan should include:
Contingency classification classify as per seriousness (minor, medium, major), duration (day, week, weeks), damage (minor, limited, serious) Specialist sections:
Administration IT infrastructure Personnel Security Recovery site Restoration
220

The recovery plan provides a framework for drafting the procedures. Effective procedures will lead to easily undertaking the recovery actions and should address:

Installing and testing hardware and network components Restoring applications, databases and data
221

Initial Testing
Initial testing of the plans, procedures and technical components involved is a critical aspect of ITSCM
222

Training and Awareness
Effective training of IT and other personnel and awareness by all personnel and the organization, are essential to the success of any IT Service Continuity process. The actual contingency facilities, on-site or off-site should also be covered by the training.
223

Review and Audit
Plans should be reviewed and verified regularly to ensure that they are up-to-date. This concerns all aspects of ITSCM. Eg. Every time there is a significant change to the IT infrastructure Audits must be carried out if there is any change in business strategy or IT strategy
224

Testing
The Recovery Plan must be tested regularly, rather like an emergency drill on a ship. The test will help identify weakness in the plan or changes that were overlooked. Tests could be announced or unannounced and should be designed to test the effectiveness of the plan both at on-site and off-site Eg. Paper test, preparedness test, full test
225

Change Management
Change Management plays an important role in keeping all the ITSCM plans current, and for ensuring that the impact of any change to the Recovery Plan is analyzed
226

Assurance
Verify that the quality of the process (procedures and documents) and its deliverables are adequate to meet the business needs of the company. The test reports provide a level of assurance. Third party audit could also be undertaken for assuring the effectiveness of IT Service continuity plans.
227
Availability Management
Definition
The objective of Availability management is to provide a cost-effective and defined level of availability of the IT service that enables the business to reach its objectives
229
Basic Concepts:
High availability means that the IT services is continuously available to the customer, as there is little downtime and rapid service recovery. The achieved availability is indicated by metrics. The availability of the service depends on the

Reliability Maintainability Serviceability
Of the IT infrastructure
230
Basic Concepts:
Reliability Reliability of a service means that the service is available for an agreed period without interruptions. This concept also includes resilience.
231
Basic Concepts:
Maintainability Maintainability and recoverability relate to the activities needed to keep the service in operation and to restore it when it fails. This includes preventive maintenance and scheduled inspections.
232
Basic Concepts:
Serviceability Serviceability relates to contractual obligations of external service providers.
233
Activities:
Planning Determining the avail, requirements Designing for Availability Designing for Recoverability Security Issues Maintenance Management Developing the Availability Plan Monitoring
Measuring and Reporting

234
Determining the availability requirement.
This activity should be undertaken before a SLA is concluded and should address both new and old IT services and changes to existing services. This includes:

Identify key business functions Agreed definition of IT service downtime Quantifiable availability requirements Quantifiable impact on the business functions of unscheduled IT service downtime Business hours of the customer Agreements about maintenance windows
235
Designing for Availability
Designing for availability can be thought of as a proactive task where the focus is on keeping the IT service running and preventing service outages from occurring or reducing the impact of failures on the service being provided.
236
Designing for Maintainability
Designing for recovery is predominantly a pro-active task that aims to diagnose and recover service as quickly as possible if it actually fails or becomes degraded in some manner.
237
Key Security Issues
A poor information security design can affect the availability of the service. During the planning stage, the security issues should be considered and their impact on the provision of services should be analyzed. Issues to be included:
Determining who is authorized to access secure areas Determining which critical authorizations may be issued
238
Maintenance Management
Scheduled windows of availability must be clearly defined. These periods can be used for :

Preventive actions (s/w and h/w upgrades) Implement changes Undertake backup / restoration of data
(Maintenance must be carried out when the impact on services can be minimized)
239
Measuring and Reporting
Measuring and reporting provide the basis for verifying service agreements, resolving problems and defining proposals for improvements.
240
Availability Measurement
Time Between system Incidents
Downtime, Time to repair
Uptime, Time between failures
response time Detection Incident time
repair time
recovery time Incident
Resolution time recovery Time
MTTR: The Average Mean Time to Repair across a number of incidents MTBF: The Average Mean Time Between Failures across a number of incidents
CMS Computers Ltd. Copyright 2005 241
Availability and ITSCM
Availability management and ITSCM are closely related as both processes strive to eliminate risks to the availability of IT services. The prime focus of availability management is handling the routine risks to availability that can be reasonably expected to occur on a day-to-day basis. Where no straight-forward countermeasures are available or where the countermeasure is prohibitively expensive or beyond the scope of a single IT service to justify in its own right, these availability risks are passed on to service continuity management to handle.
242
Tools:
Determining downtime Recording historical information Generating reports Statistical Analysis Impact Analysis
243
Methods and Techniques
Component Failure Impact Analysis CFIA Fault Tree Analysis (FTA) CCTA Risk Analysis Management Method (CRAMM) Service Outage Analysis (SOA) Technical Observation Post (TOP)
244
Component Failure Impact Analysis Matrix (CFIA)
Configuration Item: Service A PC #1 PC #2 Cable #1 Cable #2 Outlet #1 Outlet #2 Ethernet segment Router WAN link Router Segment NIC Server System Software Application Database B N B N X N X X X X X A B B B X Service B B B B B X X X X X X X A B B B X
X = Fault means service is unavailable A = Failsafe configuration B = Failsafe, with changeover time N = No impact
245
Fault Tree Analysis FTA
Basic Events Resulting Events Conditional Events Trigger Events
And / OR / XOR / Inhibit
246
Security Management
Security Management
IT Security Management
The objective of IT Security Management is to control the provision of information and to prevent unauthorized use of information. It is an essential quality aspect of management.
248
Security Management
Value of Information depends on:
Confidentiality : Protecting information against unauthorized access and use Integrity: Accuracy, completeness and timeliness of the information Availability: Accessible at any agreed time
249
Security Management
Activities :
Control Information Security Policy and Organization

Develop and implement Information Security policy Define sub-processes and their functions Define roles and responsibilities Define organization structure Define reporting arrangements
250
Security Management
Activities :
Plan

Define the security section of the SLAs Define the security sections of the UCs Develop Information Security OLAs for each organizational unit and each specific service
251
Security Management
Activities :
Implement
Classification and management of IT resources

Personnel security Managing security Access control
252
Security Management
Activities :
Evaluate
Self-assessments Internal Audits External Audits
253
Security Management
Activities :
Maintenance
Maintenance of the security section of SLAs and detailed security plans (OLAs) Based on the assessment and audit reports As a response to changes in IT infrastructure / organization / business
254
Security Management
Activities :
Reporting

Is an output of the security sub-processes Extent of compliance with the SLA and agreed KPI for security Current and new Security issues Annual Security plans and action plans Results of audits, reviews and internal assessments
255
Security Management
Customer defines business requirements
Reporting (as per SLA) Service Level agreement (security chapter)
IT Service Provider Implements SLA Security requirements
Maintain
Plan
Control
Evaluate
Implement
256
Security Management
Customer defines business requirements Service Level agreements Underpinning Contracts Service Operation Level AgreementsLevel agreement (security chapter) Internal Policies IT Service Provider Implements SLA Security requirements Maintain Control Plan
Reporting (as per SLA)
Evaluate
Implement
257
Security Management
Reporting Service Level agreement (as per SLA) (security chapter) Improve awareness Classification &Service Provider resources IT management of Implements Personnel Security Security requirements SLA Physical security Security management of h / w, s / w, n / w, etc. Plan Maintain Access control Resolve security incidents Control
Evaluate
Implement
258
Security Management
Service Level agreement (security chapter) IT Service Provider Implements SLA Security requirements Internal audits External audits Self assessments Security Incidents Control
Maintain
Plan
Evaluate
Implement
259
Security Management
Customer defines business requirements Learn Reporting Service Level agreement Improve (as per SLA) (security chapter) Plan Implement IT Service Provider Implements SLA Security requirements Maintain Control Plan
Evaluate
Implement
260
Security Management
Service Level agreement (security chapter) IT Service Provider Implements SLA Security requirements
Maintain Control Organize Create management framework Evaluate Evaluate Allocate responsibilities
Plan
Implement
261
IT Financial Management
Financial Management
The objective of the Financial Management process is the sound management of monetary resources in support of organizational goals. It ensures that activities engaged to meet the requirements defined in service level management are justified from a cost and budget standpoint.
263
Service depends on:
Quality Capacity, Availability, Performance, Disaster Recovery, Support Cost Expenditure and Investment Customer Requirements Business Needs
264
Cost Types:
Materials Equipment Costs Unit (ECU)
Software Cost Unit (SCU) Labor Organization Cost Unit (OCU)
Overhead - Accommodation Cost Unit (ACU) Transfer Cost Unit (TCU) Cost Accounting (CA)
265
Financial Management is implemented through:
Budgeting Accounting Charging Reporting
266
Budgeting :
Budgeting is the activity of predicting how much money the organization will spend during a specified period. It also involves controlling the distribution of money to areas for which it was originally budgeted, thereby ensuring that sufficient funds are available throughout the entire period.
267
Budgeting Methods

Incremental Budgeting Zero-Base Budgeting
268
Budgeting Process:

Sales and Marketing Budget Production Budget Administrative Budgets Cost and Investment Budgets
269
Accounting :
The objective of accounting is to identify and understand all the costs that IT is responsible for so that they can be controlled.
270
Accounting Activities:

Identify the service elements Identify the cost elements Assign the direct costs Allocate indirect costs
271
Service Structure
Business Application Accounts Business Application Relationship Management Terminal Emulator IBM environment Business Application Marketing Data Terminal Emulator other environment
Internet, Extranet and Internet Information Services Groupware (Mail & Directory Services) General Business Applications Office Applications File Services & Print Services Operation system Windows 98 Workstation Baseline A Powerful desktop PC Operation system Windows NT 4.0 Workstation Baseline B Standard desktop PC Network Services (LAN & WAN) Workstation Baseline C Laptop PC
272
Charging:
Charging is an effective tool to encourage users to use the IT resources more carefully as well as a cost recovery activity for the IT services provided.
273
Charging Policy:

Communication of Information Notional Charging Actual charging
274
Charging Policy:
No
Charging: most of the times used as Communication and Information where the customer are informed about the cost of the services that IT is delivering. The customer does not pay for the services and is not going to.
Notional
Charging: This is used as the first step for charging, the invoice is made and delivered to the customer but they dont have to pay (Yet). This gives the organization the opportunity to get more experience and to fine tune the Invoices. It gives the Organization the opportunity to get used to charging. This is sometimes called Soft Charging" In which no Money changes hand.
Actual
(Real) charging: Now the Invoice has to be Paid, The blue Dollars becomes Green Dollars.
275
Rate :

Decide the objective for charging Determine Direct and Indirect costs Determine market rates Analyze the demand for services Analyze the number of customers and the competition
276
Pricing :

Cost Plus Going Rate Target Return Negotiated Contract Price
277
Reporting :

IT services expenditure per customer Difference b/w actual and estimated expenditure Charging and accounting methods Disputes about charges, with causes and solution
278
Last thoughts
The risk?
(better late than never)
Costly mistakes, if a wrong decision's is made early in the process
Gotcha ! Heres where you made a mistake!!!
279
Clarifications
280
Questions
281
Thank You
Lets pledge to get certified on ITIL

282

ITIL - Final Slides Reliance

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ITIL - Final Slides Reliance

Hochgeladen von

Copyright:

Verfügbare Formate

Introduction to ITIL / ITSM

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

ITSM Foundation R1 15-11-05

IT Service Management frame works developed on the basis of ITIL:

CMS Computers Ltd. Copyright 2005

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

Benefits Benefits of ITIL to the organization :

What can go wrong

What can go wrong

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

Process Improvement Model

Where do we Want to be?

Vision and Business objectives Assessment

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

INPUT ACTIVITIES OUTPUT

INPUT ACTIVITIES OUTPUT

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

Measurement & Control

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

IT Customer Relationship Management

Department managers Project managers Users

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

Service Level Management Financial Management for IT Services

Capacity Management It Service Continuity Management Availability Management

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

Service Support Processes

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

Configuration Management Database (CMDB)

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05

CMS Computers Ltd. Copyright 2005

ITSM Foundation R1 15-11-05