itil_final slides reliance

CMS Computers Ltd. © Copyright 2005 ITSM Foundation R1 15-11-05

Introductionto ITIL / ITSM

CMS Computers Ltd. © Copyright 2005 2ITSM 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.


IntroductionInputs 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 heroism’s must change to TEAM

EFFORTS.

TECHNOLOGY FOCUS has to change to

CUSOMER FOCUS.

GUT FEEL decisions to be replaced by FACTS

and DATA.


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.


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.



Practitioner Certificate:

Aimed at the practical level of how to perform a

specific ITIL process and the tasks within that process.



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.


What it contains…

PDCA Process

Businessrequirements

Customerrequirements

Request for new Or changed services

Other process,Eg. Business

Supplier

Service Desk

Other Teamseg Security

BusinessResults

CustomerSatisfaction

New or changedservice

Other process,Business,

Supplier, customer

Team & PeopleSatisfaction

Management ResponsibilityManagement Responsibility

PLANPlan servicemanagement

PLANPlan servicemanagement

DOImplement

ServiceManagement

DOImplement

ServiceManagement

ACTContinuous

Improvement

ACTContinuous

Improvement

CHECKMonitor, Measure

and Review

CHECKMonitor, Measure

and Review

Manage Services


Clarifications


Requirementsof ITIL


Process Improvement Model

Where do weWant to be?

Vision andBusinessobjectives

Assessment

ProcessImprovement

Matrics

Where are we?

How can we getWhere we want

To be?

How do we knowThat we have

arrived


Process

OUTPUT

INPUT

OUTPUT

INPUTINPUT

CONTROLS CONTROLS CONTROLS

ACTIVITIES ACTIVITIES ACTIVITIES

RESOURCES RESOURCES RESOURCES


Process Diagram

Standard Policy

Measurement& Control

Activities OutputInput


IT Customer Relationship Management

Change ManagementIncident Management

Service DeskProduction

Department managersProject managers

Users

Budget holders

ITManagemen

t

BusinessManagers

Service LevelManagement

Support

ChangeRequests

ServiceLevels

StrategicAlignment

IT Customer RelationshipManagement

IT Organisation

Policy

Reporting

Customer Organisation

Strategic

Tactical

Operational

Demand Supply


Planning Horizon

ApplicationsBusiness

Time

1 year

TechnicalInfrastructure


Clarifications


ITIL Model

Problem ManagementProblem Management

Incident ManagementIncident Management

Release ManagementRelease Management

Change ManagementChange Management

Configuration ManagementConfiguration Management

Capacity ManagementCapacity Management

It ServiceContinuity Management


Availability ManagementAvailability Management

Service Level Management


Financial Managementfor IT Services


ServiceDesk

IT CustomerRelationshipManagement

Service Delivery

Service Support

Security ManagementSecurity Management


Service Support Processes

ConfigurationManagement


Configuration Management

Objective

Keeping up-to-date and reliable information about the IT

infrastructure and services.

Maintaining details of relations between the IT

components.



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 CI’s. It keeps track of all the IT components, their versions, status and relationships between them.



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 CI’s.

• Status Accounting – Current and historical details of CI’s.

• Verification and audit – Accuracy of records.

• Reporting – Provides information to other processes.



Configuration Management Planning

• Requirements for Accountability, Traceability and

Auditability.

• Configuration control

– Access

– Protection

– Version

– Build

– Release controls


Configuration ManagementConfiguration 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



Configuration Identification

Configuration Items should be

• uniquely identified

• defined by attributes (functional and physical)

• auditable

• recorded in CMDB




CI’s 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




CI’s to be managed should be identified and should include

• 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)




CI’s to be managed should be identified and should include

• 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 CI’s

• Traceability matrix to be maintained where ever traceability is

a requirement



CMDB Development

• Scope of CMDB (Breadth of CMDB)

• Level of Breakdown (Depth of CMDB)

• Level of Detail (Attributes)



Scope Of CMDB (BREADTH)

Service A

Line 1, digital

Line 2, digital

Line 3, analog

PABX

Service B

System 21

NIC 12

Modem 5

Module A

Module B

PABXApplication A

ITInfrastructure

CI #1

CI #2CI #3

CI #4

CI #5

CI #6

CI #7

CI #8

Scope



IT Infrastructure

Network DocumentationSoftwareHardware

Suite 1 Suite 2

Program 1-2 Program 1-3Program 1-1

Module 1-2-1 Module 1-2-2

CMDB Level of breakdown (depth)


Configuration ManagementCMDB 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



CI Relationships

Relationships between CI’s 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



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



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



Configuration Baselines

A snapshot of a group of CI’s 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’




Archived

Maintenance

Operational

Implemented

Tested

Received / on stock

Planned / on order

Time




Configuration records should be accessible to

appropriate

– Users

– Customers

– Suppliers

– Partners

For appropriate planning and decision making



Configuration Control

The degree of control should be based on

– Business needs

– Risk of failure

– Service criticality



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



Configuration Verification And Audit

Configuration Audit should be carried out

• Regularly on periodic basis

• Before and after major change

• After a disaster

• Random intervals



Configuration Verification And Audit

Configuration Audit deficiencies and non-conformities should be

• Recorded

• Assessed

• Corrective action instigated

• Acted upon

• Fed back to relevant parties



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



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


Configuration ManagementConfiguration 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.

Configuration Management• Goes beyond Asset Management and keeps technical

information about CI’s, and relationship with CI’s.


Configuration Management-Current Assessment

Maximum Attainable Score

Your Score


Clarifications



IncidentManagement


Incident Management

IncidentAny 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 (Not cause)


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.


Incident Management

Resolution TargetsResolution targets are to be identified for Incidents and Problems.

Basis for Resolution TargetsResolution targets are to be based on Priority.


Incident Management

PrioritiesPriorities should to be based on IMPACT and URGENCY

ImpactImpact is based on actual or potential damage to customers

business

UrgencyUrgency is based on the time between problem or incident

being detected and the time that the customers business is

impacted.


Incident Management

Example of a priority coding system

HighHigh MediumMedium LowLow

HighHigh

MediumMedium

LowLow

PriorityResolution

time

< 1 hour

< 8 hours

<24 hours <48 hours

<24 hours

< 8 hours <24 hours

<48 hours

planned

critical

high

medium

high

medium

low

medium

low

planning

IMPACT

UR

GE

NC

Y


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)


Incident Management

Escalation

• Functional Escalation

• Hierarchical Escalation

– Function EscalationInvolving personnel with more specialist skills, time or access privileges to solve the incident

– Hierarchical EscalationInvolving an higher level of Organizational authority, when current level of authority appears insufficient.


Incident ManagementFunctional Escalation Matrix

Level Contact Person Address Contact Nos. Hrs to escalation

1 Service Desk xxx xxxxx Logging

2 Management Departments

xxx xxxxx 3

3 Software Developers and Architects

xxx xxxxx 8

4 Suppliers xxx xxxxx 16


Incident ManagementHierarchical Escalation Matrix

Level Contact Person Address Contact Nos. Hrs to escalation

1 CCE xxx xxxxx Call Logging

2 Field Engineer xxx xxxxx 3

3 Area Manager xxx xxxxx 8

4 Project Manager xxx xxxxx 16


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.


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


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


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


Incident Management

Incident Management Works closely with

• Configuration Management Database (CMDB)

• Problem / Known Error Database (KEDB)

• Service Level Management (SLM)

• Problem Management


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


Incident Management

Benefits

For the IT Organization

• Improved monitoring, allowing performance against SLA’s

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



ProblemManagement


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


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


Problem Management

What is Workarounds?

The process by which service restoration can be

enabled by users of staff is called Workaround

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

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.


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


Problem Management

Problem Management Activities

• Problem Control

• Error Control

• Proactive Problem Management

• Providing Information


Problem Management

Problem Control

Objective: To turn problems into known errors by identifying the underlying cause and identify a workaround

1. Problem identification and recording

2. Classification

3. Investigation and diagnosis

4. RFCs for temporary fixes

5. Error Control


Problem Management

Problem Identificationand recording

Problem Classification

Problem Investigationand diagnosis

RFC and Problem Resolutionand closure

( Error control )

Tra

ckin

g a

nd

mo

nit

ori

ng

of

Pro

ble

ms

Problem Control


Problem Management

Error Control

Objective: To manage known errors until they are

successfully resolved, were possible and appropriate.

1. Error identification and recording

2. Assessment and investigation

3. Determining solution and recording

4. Post-Implementation Review (PIR)

5. Tracking and monitoring


Problem Management( Problem control )

Error Identificationand recording

Error Assessment

Record Error Resolution

Tra

ckin

g a

nd

mo

nit

ori

ng

of

Pro

ble

ms

Close Error andAssociated

Problems ( s )

RFC

Error Control


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


Problem ManagementProactive 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


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


Problem Management

Problem ReviewsProblem reviews should be held wherever justified necessary like

•Investigation to unresolved problems

•Unusual problems

•High impact problems

Purpose Of Problem ReviewsPurpose of Problem reviews should be to

•Seek Improvements to processes

•Prevent recurrence of incidents and mistakes


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 RFC’s

• Monitoring progress of known errors

• Conducting major problem reviews

• Identifying trends

• Preventing problems spreading to other systems


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


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.


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



ServiceDesk


ITIL Model














ServiceDesk


Service Delivery

Service Support



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


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 –


• Activities concerning standard requests – Change

Management

• Information to the users about the services they are

entitled to as specified in the SLA


Service Desk

Service Desk

• Single point of contact

• Monitoring / tracking of status of incidents recorded

• Handling Service requests


Service Desk

Structure

• Accessibility

• Business support (infrastructure, application)

• Service desk types

• Centralized

• Local (distributed)

• Virtual


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.


Service Desk

How Are Incidents Reported?

• Telephone calls

• Voice mails

• Visits

• Letters

• Faxes

• Emails

• Recording systems

• Automated monitoring Softwares


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)


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?


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.


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 SLA’s and OLA’s and service catalogue in place to ensure that the support provided by the Service Desk has a clear focus.


Service Desk

• 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

Present Process ITIL Processes


Service Desk-Current Assessment


Your Score


Clarifications



ChangeManagement


Change Management

Change Management

To ensure that all changes are assessed, approved,

implemented and reviewed in a controlled manner.


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


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


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 PC’s

• Handled as Service Request under Incident Management


Change Management

Inputs for Change Management

• RFC’s

• 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


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


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


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


Change Management

Recording

All RFC’s 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


Change Management

Acceptance

Change Management will make initial assessment to check if RFC’s are unclear, impractical or unnecessary.

If accepted, the information required for the further processing of the change is included in a change record


Change Management

Change ClassificationChange is classified based on Category and Priority

Category Priority

Impact Urgency

Cost Benefits (Business Needs)

Risks

Availability of res.

On changes to Service, Customer and Release Plans


Change Management

Change Management Implementation

Priority Level Priority Description

1 Low Can Wait

2 Normal No great Urgency

3 High Affecting number of users

4 Highest Essential Services


Change Management

Change Management Implementation

Category Level Category Description

1 Minor Impact Little Efforts with Little Risk*

2 Substantial Impact

Significant Efforts with substantial Impact@

3 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.


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


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


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


Change Management

Change Request(RFC) Closure

The Change Request should be formally Closed and reviewed. (after Post Implementation Review (PIR))

Change Request(RFC) ReviewChange Request should be reviewed after implementation for

– success

– failure

– improvements


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”


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


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


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


Clarifications !!!



ReleaseManagement


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.


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


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


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.


Release Management

Definitive Software Library (DSL)

• Repository of authorized versions (master copies of software CI’s)

• 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.


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


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


Release Management

Release Policy and PlanningFor 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


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.


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


Release Management

Testing and Release AcceptanceRelease 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


Release Management

Roll Out Planning

Rollout Planning includes

• Drawing a schedule, list of tasks and req. resources

• List of CI’s 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


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


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


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


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


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


Release Management-Current Assessment


Your Score


Clarifications !!!


Service Delivery Processes


ITIL Model














ServiceDesk


Service Delivery

Service Support



Scope:

• Support business needs

• Present new options

Through

• Continuous interaction with the customer

• Regular reviews of business needs

• Technological developments

Service

At anAcceptable cost


Service

Service delivery refers to:

• The services the customer needs to support the business

• What is needed to provide these services


Service Delivery

Processes defined are :

• Service Level Management

• Capacity Management

• IT Service Continuity Management

• Availability Management

• IT Security Management

• Financial Management for IT Services



Service LevelManagement



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



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.



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.



Activities:

– Identify

– Define

– Formalize

– Monitor

– Report

– Review

Levels of service



Identify

• Business needs

• Business processes

• Business plans

• Service level

• BudgetService Level

Requirements

(SLR)



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



Define

• Name of each service

• Scope of each service

• Depth of each service

• Operational level agreements

• Underpinning contracts

Service

Specification Sheet

Service Quality Plan



Service specification Sheet (Spec Sheet)

• Technical specifications of each service

• Delivery and implementation procedure

• Quality control procedure



Service Quality Plan (SQP)

For each service define:

• Critical success Factors

• Key Performance Indicators



Formalize

• Negotiate

• Draft

• Amend

• Conclude

Service Catalogue

Service Level Agreement (SLA)

Operational Level Agreement (OLA)

Underpinning Contract (UC)



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



Service Catalogue

Should have:

• Customer friendly language

• Relevant terminology

• Attractive layout

• Easily available




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.




Contents:

• Introduction

• Scope of work

• Performance Tracking and Reporting

• Problem Management

• Compensation and penalties

• Customer duties and responsibilities



Monitor

• Technical Aspects

• Functional Aspects

• Procedural AspectsService Level Achievement



Service Level Achievement

• Capacity

• Availability

• Supply Procedure

• Reporting Procedure

• Customer’s perception



Report

• Performance reports

• Generated a intervals agreed in SLA

• Exception reports when required

• Provided to Customers, Process

Managers and Management

Service Level

Reports



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



Review

• Performance reports

• Service Trends

• SLA

• Technology

• Business environment

• Business Plans

Service

Improvement

Plan



Service Improvement Plan (SIP)

• Allocating additional personnel and resources

• Modifying service levels in SLA

• Modifying OLAs and Ucs

• Modifying procedures

• Training



External Documents• Service Level Requirements

• Service Level Agreements

• Service Catalogues

Internal Documents• Service Specification Sheets

• Operational Level Agreements (OLA)

• Underpinning Contracts (UC)



CapacityManagement


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.


Capacity Management

Addresses:

Cost versus Capacity

Can the purchase of capacity be justified in the light of business requirements?


Capacity Management

Addresses:

Supply versus Demand

Does the current processing capacity adequately fulfill both current and future demands of the customer


Capacity Management

Addresses:

Performance Tuning

Is the processing capacity performing at peak efficiency?


Capacity Management

The three sub-processes are:

• Business Capacity Management (BCM)

• Service Capacity Management (SCM)

• Resource Capacity Management (RCM)


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.


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.


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.


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.


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


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.


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


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


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.


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.


Capacity Management

Activities:

Modeling

Actual System: This involves the actual operating environment to predict the performance requirements.


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.


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.


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.


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.


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.


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.


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.


Capacity Management

Capacity Management Database :

Business Forecasts

Business Forecasts

Business Forecasts

Business Forecasts

ManagementReports

CapacityPlans

TechnicalReports

CDB



ContinuityManagement


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.



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



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



Activities

• Initial Testing

• Training and awareness

• Review and audit

• Testing

• Change Management

• Assurance



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.



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



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.



Risk Assessment

Risk Analysis: Identify the risks that a business is exposed to

Risk Management:Identify the counter measures to mitigate the risks



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



IT Service Continuity Strategy

Business should strike a balance between:

• Risk reduction (prevention)

• Recovery planning (recovery options)




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




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




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




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



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



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



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.



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)



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.




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




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




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



Initial Testing

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



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.



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



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



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


IT Service ContinuityManagement

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.



AvailabilityManagement


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



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



Basic Concepts:

Reliability

Reliability of a service means that the service is available for an agreed period without interruptions. This concept also includes resilience.



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.



Basic Concepts:

Serviceability

Serviceability relates to contractual obligations of external service providers.


Availability ManagementActivities:

Planning Determining the avail, requirements

Designing for Availability

Designing for Recoverability

Security Issues

Maintenance Management

Developing the Availability Plan

Monitoring Measuring and Reporting


Availability ManagementDetermining 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



Designing for Availability

Designing for availability can be thought of as a pro-active 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.



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.



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


Availability ManagementMaintenance 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)



Measuring and Reporting

Measuring and reporting provide the basis for verifying service agreements, resolving problems and defining proposals for improvements.



Availability Measurement

Detection

time

Resolution time

response repair recovery

Uptime, Time between failuresDowntime, Time to repair

time time time

Time Between system Incidents

recovery

Time

Incident Incident

MTTR: The Average Mean Time to Repair across a number of incidents

MTBF: The Average Mean Time Between Failures across a number of incidents



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.



Tools:

• Determining downtime

• Recording historical information

• Generating reports

• Statistical Analysis

• Impact Analysis



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)


Availability ManagementComponent Failure Impact Analysis Matrix (CFIA)

Configuration Item: Service A Service B

PC #1 B B

PC #2 N B

Cable #1 B B

Cable #2 N B

Outlet #1 X X

Outlet #2 N X

Ethernet segment X X

Router X X

WAN link X X

Router X X

Segment X X

NIC A A

Server B B

System Software B B

Application B B

Database X X

X = Fault means service is unavailable

A = Failsafe configuration

B = Failsafe, with changeover time

N = No impact



Fault Tree Analysis – FTA

• Basic Events

• Resulting Events

• Conditional Events

• Trigger Events

And / OR / XOR / Inhibit



SecurityManagement


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.


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


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


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


Security Management

Activities :

Implement

Classification and management of IT resources

• Personnel security

• Managing security

• Access control


Security Management

Activities :

Evaluate

• Self-assessments

• Internal Audits

• External Audits


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


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


Security Management

Maintain

Evaluate Implement

Plan

Control

Reporting(as per SLA)

Service Level agreement(security chapter)

IT Service Provider ImplementsSLA Security requirements

Customer defines business requirements


Security Management

Maintain

Evaluate Implement

Plan

Control





Service Level agreements Underpinning Contracts Operation Level Agreements Internal Policies


Security Management

Maintain

Evaluate Implement

Plan

Control





Improve awareness Classification & management of resources Personnel Security Physical security Security management of h / w, s / w, n / w, etc. Access control Resolve security incidents


Security Management

Maintain

Evaluate Implement

Plan

Control





Internal audits External audits Self assessments Security Incidents


Security Management

Maintain

Evaluate Implement

Plan

Control





Learn Improve Plan Implement


Security Management

EvaluateEvaluate

Maintain

Evaluate Implement

Plan

Control





Organize Create management framework Allocate responsibilities



IT FinancialManagement


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.



Service depends on:

• Quality – Capacity, Availability, Performance, Disaster Recovery, Support

• Cost – Expenditure and Investment

• Customer Requirements – Business Needs



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)



Financial Management is implemented through:

• Budgeting

• Accounting

• Charging

• Reporting



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.



Budgeting Methods

• Incremental Budgeting

• Zero-Base Budgeting



Budgeting Process:

• Sales and Marketing Budget

• Production Budget

• Administrative Budgets

• Cost and Investment Budgets



Accounting :

The objective of accounting is to identify and understand all the costs that IT is responsible for so that they can be controlled.



Accounting Activities:

• Identify the service elements

• Identify the cost elements

• Assign the direct costs

• Allocate indirect costs



Business Application

Accounts


Relationship Management


Marketing Data

Terminal Emulator

IBM environment

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

Operation system

Windows NT 4.0

Workstation

Baseline – A

Powerful desktop PC

Workstation

Baseline – B

Standard desktop PC

Workstation

Baseline – C

Laptop PC

Network Services (LAN & WAN)

Service Structure



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.



Charging Policy:

• Communication of Information

• Notional Charging

• Actual charging


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 don’t 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.




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



Pricing :

• Cost Plus

• Going Rate

• Target Return

• Negotiated Contract Price



Reporting :

• IT services expenditure per customer

• Difference b/w actual and estimated expenditure

• Charging and accounting methods

• Disputes about charges, with causes and solution


Last thoughts… (better late than never)

The risk?

Costly mistakes, if a wrong decision's is made early in the process

Gotcha !Here’s where you made a mistake!!!


Clarifications…


Questions


Lets pledge to get certified on ITIL…

Thank You

itil_final slides reliance

Documents

itsm foundation r1

itil itsm cms computers

itsm processes

organization cms computers

review cms computers

clarifications cms computers

itil processes

service management ism