Itil
Content
ITIL Foundation
Essential for IT Service Management
Course Outline
ITIL/ITSM Overview ITSM - Service Support
Service Desk Incident Management Problem Management Change Management Configuration Management Release Management
ITSM - Service Delivery
Service Level Management Availability Management Capacity Management IT Service Continuity Management Financial Management for IT Service
1
ITIL Overview
ITIL Service Management
ITIL overview
ITIL = IT Infrastructure Library
Developed in the Late 1980’s CCTA (Central Computer and Telecommunications Agency) = Office of Government Commerce (OGC) OGC website URL http://ww.ogc.gov.uk ITIL website URL http://www.itil.co.uk
ITIL is a Best Practice Framework Public Domain ITIL Philosophy – Scaleable Process driven approach
3
The ITIL Objectives
Key Objectives
Align IT services with the Current and Future needs of the business and its Customers（both internal and external） To improve Quality of the services delivered Reduce long term Cost of service provision
4
ITIL Service Management
Service Support Functions:
Service Desk Incident Management Problem Management Change Management Configuration Management Release Management
Service Delivery Functions:
Service Level Management Availability Management Capacity Management IT Service Continuity Management Financial Management for IT Service
5
Service Support
including:
• Service Desk • Incident Management • Problem Management • Change Management • Configuration Management • Release Management
Service Desk
Objectives:
Supports the agreed IT service provision by ensuring the accessibility and availability of the IT organization and by performing various supporting activities. To act as the central point of contact between the User and IT Service Management for all Calls, Questions, Requests, Complaints and Remarks To restore the service as quickly as possible To handle Incidents life-cycle and request and provide an interface for other activities To support business activities To generate reports, to communicate and to promote
7
Service Desk
Service Desk Essentials:
Not a Process but a function Single point of contact / Restore service ASAP Tasks: Customer Interface, Business Support, Incident Control & Management Information Concentrates on incident lifecycle management Incident: Unexpected disruption to agreed service Priority determined by business impact and urgency Correct assessment of priorities enables the deployment of manpower and other resources to be in the best interests of the customer
8
Service Desk
Setting up a Service Desk:
Understand the business needs and requirements Define clear objectives Obtain support, budget and resources Advertise and sell benefits / communicate quick wins Involve and educate users / train support staff Types of Service Desk:
Local Service Desk Central Service Desk Virtual Service Desk (Several service desks)
9
Service Desk
Different Desks (by different skill level)
Call Center:
Handling large call volumes of telephone-based transactions.
Help Desk:
To manage, coordinate, and resolve Incidents as quickly as possible.
Service Desk:
Allowing business processes to be integrated into the Service Management infrastructure. It not only handles Incidents, Problems and questions, but also provides an interface for other activities. (e.g. Change requests, maintenance contracts, software licenses, SLM)
10
Incident Management
Objectives:
To restore normal service as quickly as possible Minimize the adverse impact on business operations Ensuring that the best possible levels of service quality and availability are maintained according to SLAs.
Incident Definition:
Any event which is not part of the standard operation of a service and which causes or may cause an interruption to or a reduction in the quality of that service.
11
Incident Management
Service Request:
Every Incident not being a failure in the IT Infrastructure.
Problem:
The unknown root cause of one or more incidents.
Known Error:
A condition that exists after the successful diagnosis of the root cause of a problem when it is confirmed that a CI (Configuration Item) is at fault.
Category:
Classification of a group of Incidents (Application, Hardware, etc.)
12
Incident Management
Incident Life-Cycle:
Accept Service Event, Register and Consult the CMDB Classification Solve Closure
Reporting:
Daily reviews of individual Incident and Problem status against service levels Weekly management reviews Monthly management reviews Proactive service reports
13
Incident Management
Impact
The likely effect the incident will have on the business (e.g. numbers affected, magnitude)
Urgency
Assessment of the speed with which an incident or problem requires resolution (i.e. how much delay will the resolution bear)
Priority
The relative sequence in which an incident or problem needs to be resolved, based on impact and urgency
14
Incident Management
Incident Error in infrastructure Problem Known Error RFC Structural Resolution
Relationship between incidents, Problem and Known Errors
15
Incident Management
Escalation
IT Service Manager
Hierarchical (authority)
Service Desk Manager
2nd Line Manager
3rd Line Manager
Service Desk Support Team
2nd Line Support Team Functional (competence)
3rd Line Support Team
16
Problem Management
Objectives:
Stabilizing IT services through: Minimizing the consequences of incidents Removal of the root causes of incidents Prevention of incidents and problems Prevent recurrence of Incidents related to errors Improving productive use of resources
17
Problem Management
Key Activities:
Problem Control Error Control (including raising RFCs – Request for Change) Proactive Prevention Identifying Trends Management Information Post Implementation Review (PIR)
Problem control • Incident details • CMDB • Defined workarounds Error Control Proactive prevention Identifying trends Reports Completion of problem reviews • Known errors • RFC • Updated Problem record • Closed Problem record • Management Information
18
Problem Management
Problem Control:
Goal: To identify the root Cause Activities: Identification Classification Assign Resources Investigation and Diagnosis Establish Known Error
19
Problem Management
Error Control:
Goal: Bridges the development and live environments Activities: Error Identification and Recording Error Assessment Recording Error / Resolution (Send out RFCs) Error Closure Known Error: An Incident or Problem for which the root cause is known and temporary Work-around or a permanent alternative has been identified.
20
Problem Management
Proactive Problem Management:
Goal: The activities aimed at identifying and resolving problems before incidents occur. Activities: Trend Analysis Targeting Support Action Providing Information to the Organization Known Errors resulting from Development should be made known to the Helpdesk.
21
Change Management
Objectives:
To implement approved changes efficiently, cost-effectively and with minimal risk to the existing and to the new IT infrastructure. Only approved changes made, risk and cost minimized.
22
Change Management
Key Activities:
Logging & Filtering Changes Managing Change Process Managing Changes Chairing CAB and CAB/EC Review and Closure Management Information
Filtering changes • RFC’s • CMDB • Forward Schedule of changes (FSC) Managing Changes and Change process Chairing the CAB Reviewing and closing RFC’s Management reporting • FSC • RFC’s • CAB minutes and actions • Reports
23
Change Management
Types of Change:
Basic Change Priority: Based on Impact+Urgency High, Medium, Low … (Urgent?) Category: Based on business impact Minor, Significant, Major Urgent Change A change that needs to be implemented more quickly Standard Change An accepted solution to an identifiable and relatively common set of requirements (e.g. set up of User profile, Password reset)
24
Change Management
Impact of Change:
Category 1
Little impact on current services. The Change Manager is entitled to authorize this RFC.
Category 2
Clear impact on services. The RFC must be discussed in the Change Advisory Board. The Change Manager requests advice on authorization and planning.
Category 3
Significant impact on the services and the business. Considerable manpower and/or resources needed. The RFC will have to be submitted to the board level (CAB/EC – Change Advisory Board / Emergency Committee)
25
Change Management
Priority Setting:
Urgent
Change necessary now (otherwise severe business impact)
High
Change needed as soon as possible (potentially damaging)
Medium
Change will solve irritating errors or missing functionality (can be scheduled)
Low
Change leads to minor improvements
A change backout plan must always be possible. Change management always ends with a review of the change.
26
Change Management
A RFC may include following Items:
RFC Number Description Reason for Change CI Name Date Change priority (Immediate, High, Medium, Low) Impact and resource assessment Back out plan Risk assessment Impact on business continuity and contingency plans Etc..
27
Change Management
Change Advisory Board (CAB):
“The CAB is a body that exists to approve Changes and to assist the Change manager is the assessment and prioritization of changes CAB members (may vary)
Change manager Services staff Customer User manager Application developers Experts/technical consultants Problem manager Service level manager
28
Configuration Management
Objectives:
Account for all the IT assets and configurations within the organization and its services Provide accurate information to support other Service Management processes Provide a sound basis for all other Service Management disciplines Verify records against the infrastructure and to correct exceptions Enabling control of the infrastructure by monitoring and maintaining information on:
All the resources needed to deliver services Configuration Item (CI) status and history Configuration Item relationships
29
Configuration Management
Key Activities:
Planning
Strategy, policy, scope, objective, roles & responsibilities Config Mgt processes, activities and procedures CMDB, Relationships with other processes and 3rd parties Tools and resource requirements
Identification
Selection, identification and labelling of all CIs - Relationships
Control
Authorized additions, modifications and removal of CIs
Status Accounting
The reporting of all current and historical data of each CI Ordered, Under Repair, Live, Test …….
Verification & Auditing
Reviews and audits to verify physical existence of CIs
30
Configuration Management
Configuration Management Database (CMDB)
A database that contains all relevant details of each CI and details of the important relationships between CIs
Configuration Items (CIs)
Component of an infrastructure that is (or is to be) under the control of Configuration Management
4 Types of CIs:
Hardware Software Documentation
Processes and Procedures Technical documentation Diagrams/Charts
IT Staff NOT USERS
31
Configuration Management
Characters of a Configuration Item (CI):
Is needed to deliver a service Is uniquely identifiable Is subject to change Can be managed (A CI has: a Category, Relationships, Attributes and a Status)
CI Attributes
CI name Serial number Category ( hw,sw, documentation) Type Model number Location Version Owner Installation dates, acceptation dates, delivery date Financial information (purchase cost, maintenance cost) Status or lice cycle (development, test, operational, defect, archived) Relations ( is part of, connected to, uses)
32
Configuration Management
Relationships
..is a parent/child of.. ..is a version of.. ..is connected to.. ..applies to..(e.g. documentation) ..is used for.. (CI’s related to service) ..is a variant of.. (MS Dictionary English vs. Dutch)
33
Configuration Management
Definitions:
Configuration Baseline
Configuration of a product or system at a specific point in time which captures both structure and details. As a reference for further activities. (A snapshot of CMDB structure and detail)
Definitive Software Library
Location where all definitive authorized versions of all SW CI’s are stored and protected.
Configuration management vs Asset management
Asset: Component of a business process like people, accommodation, computer systems, paper records, fax machines, etc.
34
Release Management
Objectives:
Safeguard all software and related items Ensure that only tested / correct version of authorized software are in use Ensure that only tested / correct version of authorized hardware are in use Right software, right time, right place Right hardware, right time, right place
35
Release Management
Key Activities:
Define the release policies Control of the Definitive Software Library (DSL) Control of the Definitive Hardware Storage (DHS) Distribute Software and Associated CIs Carry out S/W audits (using CMDB) Manage the software releases Oversee build of the software releases
36
Release Management
Release policy and planning Release design, build and configuration • Project planning • Product definitions • Approved RFC • Test environment • Installation media Release acceptance Rollout planning Extensive testing Sign-off for implementation Communication preparation and training Storage of controlled software Release distribution and installation of software • Release plan • Test plan and acceptance criteria • Detailed instructions • Back-out/fall back procedures • Release in production • Up-to-date CMDB, DSL
37
Release Management
Build Management:
Software and Hardware components for release should be assembled in a controlled, reproducible manner. Build Management becomes the responsibility of Release management from the controlled test environment on wards. Back out plans should be devised and tested as part of the release. Change Management allows CMDB to remain accurate. Without Configuration data change impacts are not accurately assessable. Without Change and Configuration Management, Releases will not be controllable.
38
Release Management
Types of Release:
Delta release
Only the CI’s that have actually changed or are new since the last full or delta release
Full release All components of the release unit are built, tested and implemented together
Example: New version of client SW
Package release
Grouping of Delta and Full releases in order to provide longer periods of stability in the live environment (Release Policy)
39
Service Delivery
including:
• Availability Management • IT Services Continuity Management • Capacity Management • Financial Management • Service Level Management
Availability Management
Objectives:
To predict, plan for and manage the availability of services by ensuring that:
All services are underpinned by sufficient, reliable and properly maintained CIs Where CIs are not supported internally there are appropriate contractual agreements with third party suppliers Changes are proposed to prevent future loss of service availability
Only then can IT organizations be certain of delivering the levels of availability agreed with customers in SLAs.
41
Availability Management
Principle 1:
Availability is at the core of business & end user satisfaction
42
Availability Management
Principle 2:
When things go wrong, it is still possible to achieve business & end user satisfaction
43
Availability Management
Principle 3:
Improving availability begins when it is understood how IT services integrate with and support the business
44
Availability Management
Availability Definition:
Availability is the ability of an IT Service or component to perform its required function at a stated instant or over a stated period of time. Depends on:
Availability of components resilience to failure quality of maintenance and support quality, pattern and extent of deployment of operational process and procedures security, integrity and Availability of data.
45
Availability Management
Cost of Availability / Unavailability:
46
Availability Management
Incident Lifecycle:
MTTR: Mean Time to Repair (Downtime) – Time period that elapses between the detection of an Incident and it’s Restoration. Includes: Incident, Detection, Diagnosis, Repair, Recovery, Restoration. MTBF: Mean Time Between Failures (Uptime) – Time period that elapses between Restoration and a new Incident. MTBSI: Mean Time Between System Incidents – Time period that elapses between two incidents. MTTR + MTBF.
47
Availability Management
Incident Lifecycle:
Detection time/ Time to repair (MTTR) Time between failures/Uptime (MTBF)
Start Repair
Detection time
Start Diagnose
End Repair
Incident close
INCIDENT Detection time Reaction time Repair time Restore time
INCIDENT
48
ITSC Management
Objectives:
To support the overall Business Continuity management process by ensuring that the required IT technical services and facilities can be recovered within required and agreed business time-scales
49
ITSC Management
Why Continuity Management:
Ensuring business survival by reducing the impact of a disaster or major failure Reducing the vulnerability and risk to the business by effective risk analysis and risk management Preventing the loss of Customer and User confidence Producing IT recovery plans that are integrated with and fully support the organization’s overall Business Continuity Plan(BCP)
50
ITSC Management
Considerations:
IT Service Continuity options need to be understood and the most appropriate solution chosen in support of BCM requirements Roles and responsibilities need to be identified and supported from a senior level IT recovery plans and Business Continuity plans need to be aligned regularly reviewed, revised and tested
51
Capacity Management
Objectives:
To determine the right, cost justifiable, capacity of IT resources such that the Service Levels agreed with the business are achieved at the right time.
52
Capacity Management
Responsibilities of Capacity Management:
Business Capacity management (BCM) Ensuring future business requirements for IT services are considered and matched to capability - Demand Management Service Capacity Management (SCM) Managing performance of IT services delivered to customers and documented in SLAs - Workload Management Resource Capacity management (RCM) Management of components ensuring that all resources are monitored & measured - Resource Management
53
Capacity Management
Definitions (cont.):
Modeling Trend Analysis Analytical Modeling Simulation Modeling Baseline Modeling Application Sizing: To estimate the resource requirements to support a proposed application change to ensure that it meets its required service levels. CDB – Capacity Data Base Contains all Metrics, etc. Used to create a Capacity Management Plan. Performance Management Data populates the CDB.
54
Financial Management for IT Services
Objectives:
To provide information about and control over the costs of delivering IT services that support customers business needs. Costing is a must!
55
Financial Management for IT Services
Input cost units recommended by ITIL:
Equipment Cost Units (ECU) Organization Cost Units (OCU) Transfer Cost Units (TCU) Accommodation Cost Units (ACU) Software Cost Units (SCU)
Equipment = hardware Organization = staff Transfer = costs which IT incurs acting as an agent for the customer, they do not appear as a cost against the IT department’s budget Accommodation = buildings Software = software
56
Financial Management for IT Services
Why Financial Management:
Identify the actual cost of services provided Provide accurate and vital financial information to assist in decision making Make Customers aware of what services actually cost TCO Assist in the assessment and management of changes Help influence customer behaviour Positioning for charging
57
Financial Management for IT Services
Concepts:
Accounting and Budgeting (mandatory) Understand costs involved in providing a service Prediction of future costs monitor actual against predicted costs Account for monetary spend over given period Charging (optional) Recovery of service costs from Customer Operate IT Division as a business unit if required
58
Financial Management for IT Services
IT Financial Cycle:
Business IT Requirements IT Operational Plan (inc. Budgets) Cost Analysis (Accounting) Charges
Financial Targets Costing Models Charging Policies
Feedback of proposed charges to business (effects behaviour)
59
Financial Management for IT Services
Cost Model:
The Cost Model will consist of COST ELEMENTS COST Type Transfer (Cross Charges) Hardware External Services Software People Accommodation COST Categorization Capital OR Operational Direct OR Indirect Fixed OR Variable
60
Financial Management for IT Services
Charging and Pricing Options:
Charging: No Charging – IT treated as support center Notional Charging – IT treated as cost center Actual Charging Pricing: Recover of Costs – IT treated as a service center Cost Price Plus – IT treated as a profit center Market Prices – IT treated as a profit center Support and Cost centers used “soft charging” in which no money changes hands; service and profit centers use “hard costing” in which money is transferred between bank accounts
61
Service Level Management
Objectives:
The goal for SLM is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service - in line with business or Cost justification. Through these methods, a better relationship between IT and its Customers can be developed.
62
Service Level Management
Terminology:
Service Level Requirements (SLR) – Amounts Availability, Response Time …….. Service Level Agreement (SLA) – Document Client/Supplier Operational Level Agreement (OLA) – Document Internal Underpinning Contract (UC) – Document 3rd Party Suppliers Service Improvement Program (SIP) – To Maintain Business alignment
63
Service Level Management
Service Level Agreement (SLA):
A written agreement between an IT Service provider and the IT Customer(s), defining the key service targets and responsibilities of both parties. Minimum Requirements for an Agreement: Period, Service Description, Throughput, Availability, Response Times, Signature Other Possible Clauses: Contingency arrangements, Review procedures, Change procedures, Support services, Customer responsibilities, Housekeeping, Inputs and Outputs, Changes SLAs must be monitored regularly and reviewed regularly Monitor to see if service is being delivered to specification Review to see if service specification is still appropriate
64
Security Management
Objective:
Ensure such a level of security, that the agreed availability of the infrastructure is not compromised.
65
Q&A
Essential for IT Service Management
Course Outline
ITIL/ITSM Overview ITSM - Service Support
Service Desk Incident Management Problem Management Change Management Configuration Management Release Management
ITSM - Service Delivery
Service Level Management Availability Management Capacity Management IT Service Continuity Management Financial Management for IT Service
1
ITIL Overview
ITIL Service Management
ITIL overview
ITIL = IT Infrastructure Library
Developed in the Late 1980’s CCTA (Central Computer and Telecommunications Agency) = Office of Government Commerce (OGC) OGC website URL http://ww.ogc.gov.uk ITIL website URL http://www.itil.co.uk
ITIL is a Best Practice Framework Public Domain ITIL Philosophy – Scaleable Process driven approach
3
The ITIL Objectives
Key Objectives
Align IT services with the Current and Future needs of the business and its Customers（both internal and external） To improve Quality of the services delivered Reduce long term Cost of service provision
4
ITIL Service Management
Service Support Functions:
Service Desk Incident Management Problem Management Change Management Configuration Management Release Management
Service Delivery Functions:
Service Level Management Availability Management Capacity Management IT Service Continuity Management Financial Management for IT Service
5
Service Support
including:
• Service Desk • Incident Management • Problem Management • Change Management • Configuration Management • Release Management
Service Desk
Objectives:
Supports the agreed IT service provision by ensuring the accessibility and availability of the IT organization and by performing various supporting activities. To act as the central point of contact between the User and IT Service Management for all Calls, Questions, Requests, Complaints and Remarks To restore the service as quickly as possible To handle Incidents life-cycle and request and provide an interface for other activities To support business activities To generate reports, to communicate and to promote
7
Service Desk
Service Desk Essentials:
Not a Process but a function Single point of contact / Restore service ASAP Tasks: Customer Interface, Business Support, Incident Control & Management Information Concentrates on incident lifecycle management Incident: Unexpected disruption to agreed service Priority determined by business impact and urgency Correct assessment of priorities enables the deployment of manpower and other resources to be in the best interests of the customer
8
Service Desk
Setting up a Service Desk:
Understand the business needs and requirements Define clear objectives Obtain support, budget and resources Advertise and sell benefits / communicate quick wins Involve and educate users / train support staff Types of Service Desk:
Local Service Desk Central Service Desk Virtual Service Desk (Several service desks)
9
Service Desk
Different Desks (by different skill level)
Call Center:
Handling large call volumes of telephone-based transactions.
Help Desk:
To manage, coordinate, and resolve Incidents as quickly as possible.
Service Desk:
Allowing business processes to be integrated into the Service Management infrastructure. It not only handles Incidents, Problems and questions, but also provides an interface for other activities. (e.g. Change requests, maintenance contracts, software licenses, SLM)
10
Incident Management
Objectives:
To restore normal service as quickly as possible Minimize the adverse impact on business operations Ensuring that the best possible levels of service quality and availability are maintained according to SLAs.
Incident Definition:
Any event which is not part of the standard operation of a service and which causes or may cause an interruption to or a reduction in the quality of that service.
11
Incident Management
Service Request:
Every Incident not being a failure in the IT Infrastructure.
Problem:
The unknown root cause of one or more incidents.
Known Error:
A condition that exists after the successful diagnosis of the root cause of a problem when it is confirmed that a CI (Configuration Item) is at fault.
Category:
Classification of a group of Incidents (Application, Hardware, etc.)
12
Incident Management
Incident Life-Cycle:
Accept Service Event, Register and Consult the CMDB Classification Solve Closure
Reporting:
Daily reviews of individual Incident and Problem status against service levels Weekly management reviews Monthly management reviews Proactive service reports
13
Incident Management
Impact
The likely effect the incident will have on the business (e.g. numbers affected, magnitude)
Urgency
Assessment of the speed with which an incident or problem requires resolution (i.e. how much delay will the resolution bear)
Priority
The relative sequence in which an incident or problem needs to be resolved, based on impact and urgency
14
Incident Management
Incident Error in infrastructure Problem Known Error RFC Structural Resolution
Relationship between incidents, Problem and Known Errors
15
Incident Management
Escalation
IT Service Manager
Hierarchical (authority)
Service Desk Manager
2nd Line Manager
3rd Line Manager
Service Desk Support Team
2nd Line Support Team Functional (competence)
3rd Line Support Team
16
Problem Management
Objectives:
Stabilizing IT services through: Minimizing the consequences of incidents Removal of the root causes of incidents Prevention of incidents and problems Prevent recurrence of Incidents related to errors Improving productive use of resources
17
Problem Management
Key Activities:
Problem Control Error Control (including raising RFCs – Request for Change) Proactive Prevention Identifying Trends Management Information Post Implementation Review (PIR)
Problem control • Incident details • CMDB • Defined workarounds Error Control Proactive prevention Identifying trends Reports Completion of problem reviews • Known errors • RFC • Updated Problem record • Closed Problem record • Management Information
18
Problem Management
Problem Control:
Goal: To identify the root Cause Activities: Identification Classification Assign Resources Investigation and Diagnosis Establish Known Error
19
Problem Management
Error Control:
Goal: Bridges the development and live environments Activities: Error Identification and Recording Error Assessment Recording Error / Resolution (Send out RFCs) Error Closure Known Error: An Incident or Problem for which the root cause is known and temporary Work-around or a permanent alternative has been identified.
20
Problem Management
Proactive Problem Management:
Goal: The activities aimed at identifying and resolving problems before incidents occur. Activities: Trend Analysis Targeting Support Action Providing Information to the Organization Known Errors resulting from Development should be made known to the Helpdesk.
21
Change Management
Objectives:
To implement approved changes efficiently, cost-effectively and with minimal risk to the existing and to the new IT infrastructure. Only approved changes made, risk and cost minimized.
22
Change Management
Key Activities:
Logging & Filtering Changes Managing Change Process Managing Changes Chairing CAB and CAB/EC Review and Closure Management Information
Filtering changes • RFC’s • CMDB • Forward Schedule of changes (FSC) Managing Changes and Change process Chairing the CAB Reviewing and closing RFC’s Management reporting • FSC • RFC’s • CAB minutes and actions • Reports
23
Change Management
Types of Change:
Basic Change Priority: Based on Impact+Urgency High, Medium, Low … (Urgent?) Category: Based on business impact Minor, Significant, Major Urgent Change A change that needs to be implemented more quickly Standard Change An accepted solution to an identifiable and relatively common set of requirements (e.g. set up of User profile, Password reset)
24
Change Management
Impact of Change:
Category 1
Little impact on current services. The Change Manager is entitled to authorize this RFC.
Category 2
Clear impact on services. The RFC must be discussed in the Change Advisory Board. The Change Manager requests advice on authorization and planning.
Category 3
Significant impact on the services and the business. Considerable manpower and/or resources needed. The RFC will have to be submitted to the board level (CAB/EC – Change Advisory Board / Emergency Committee)
25
Change Management
Priority Setting:
Urgent
Change necessary now (otherwise severe business impact)
High
Change needed as soon as possible (potentially damaging)
Medium
Change will solve irritating errors or missing functionality (can be scheduled)
Low
Change leads to minor improvements
A change backout plan must always be possible. Change management always ends with a review of the change.
26
Change Management
A RFC may include following Items:
RFC Number Description Reason for Change CI Name Date Change priority (Immediate, High, Medium, Low) Impact and resource assessment Back out plan Risk assessment Impact on business continuity and contingency plans Etc..
27
Change Management
Change Advisory Board (CAB):
“The CAB is a body that exists to approve Changes and to assist the Change manager is the assessment and prioritization of changes CAB members (may vary)
Change manager Services staff Customer User manager Application developers Experts/technical consultants Problem manager Service level manager
28
Configuration Management
Objectives:
Account for all the IT assets and configurations within the organization and its services Provide accurate information to support other Service Management processes Provide a sound basis for all other Service Management disciplines Verify records against the infrastructure and to correct exceptions Enabling control of the infrastructure by monitoring and maintaining information on:
All the resources needed to deliver services Configuration Item (CI) status and history Configuration Item relationships
29
Configuration Management
Key Activities:
Planning
Strategy, policy, scope, objective, roles & responsibilities Config Mgt processes, activities and procedures CMDB, Relationships with other processes and 3rd parties Tools and resource requirements
Identification
Selection, identification and labelling of all CIs - Relationships
Control
Authorized additions, modifications and removal of CIs
Status Accounting
The reporting of all current and historical data of each CI Ordered, Under Repair, Live, Test …….
Verification & Auditing
Reviews and audits to verify physical existence of CIs
30
Configuration Management
Configuration Management Database (CMDB)
A database that contains all relevant details of each CI and details of the important relationships between CIs
Configuration Items (CIs)
Component of an infrastructure that is (or is to be) under the control of Configuration Management
4 Types of CIs:
Hardware Software Documentation
Processes and Procedures Technical documentation Diagrams/Charts
IT Staff NOT USERS
31
Configuration Management
Characters of a Configuration Item (CI):
Is needed to deliver a service Is uniquely identifiable Is subject to change Can be managed (A CI has: a Category, Relationships, Attributes and a Status)
CI Attributes
CI name Serial number Category ( hw,sw, documentation) Type Model number Location Version Owner Installation dates, acceptation dates, delivery date Financial information (purchase cost, maintenance cost) Status or lice cycle (development, test, operational, defect, archived) Relations ( is part of, connected to, uses)
32
Configuration Management
Relationships
..is a parent/child of.. ..is a version of.. ..is connected to.. ..applies to..(e.g. documentation) ..is used for.. (CI’s related to service) ..is a variant of.. (MS Dictionary English vs. Dutch)
33
Configuration Management
Definitions:
Configuration Baseline
Configuration of a product or system at a specific point in time which captures both structure and details. As a reference for further activities. (A snapshot of CMDB structure and detail)
Definitive Software Library
Location where all definitive authorized versions of all SW CI’s are stored and protected.
Configuration management vs Asset management
Asset: Component of a business process like people, accommodation, computer systems, paper records, fax machines, etc.
34
Release Management
Objectives:
Safeguard all software and related items Ensure that only tested / correct version of authorized software are in use Ensure that only tested / correct version of authorized hardware are in use Right software, right time, right place Right hardware, right time, right place
35
Release Management
Key Activities:
Define the release policies Control of the Definitive Software Library (DSL) Control of the Definitive Hardware Storage (DHS) Distribute Software and Associated CIs Carry out S/W audits (using CMDB) Manage the software releases Oversee build of the software releases
36
Release Management
Release policy and planning Release design, build and configuration • Project planning • Product definitions • Approved RFC • Test environment • Installation media Release acceptance Rollout planning Extensive testing Sign-off for implementation Communication preparation and training Storage of controlled software Release distribution and installation of software • Release plan • Test plan and acceptance criteria • Detailed instructions • Back-out/fall back procedures • Release in production • Up-to-date CMDB, DSL
37
Release Management
Build Management:
Software and Hardware components for release should be assembled in a controlled, reproducible manner. Build Management becomes the responsibility of Release management from the controlled test environment on wards. Back out plans should be devised and tested as part of the release. Change Management allows CMDB to remain accurate. Without Configuration data change impacts are not accurately assessable. Without Change and Configuration Management, Releases will not be controllable.
38
Release Management
Types of Release:
Delta release
Only the CI’s that have actually changed or are new since the last full or delta release
Full release All components of the release unit are built, tested and implemented together
Example: New version of client SW
Package release
Grouping of Delta and Full releases in order to provide longer periods of stability in the live environment (Release Policy)
39
Service Delivery
including:
• Availability Management • IT Services Continuity Management • Capacity Management • Financial Management • Service Level Management
Availability Management
Objectives:
To predict, plan for and manage the availability of services by ensuring that:
All services are underpinned by sufficient, reliable and properly maintained CIs Where CIs are not supported internally there are appropriate contractual agreements with third party suppliers Changes are proposed to prevent future loss of service availability
Only then can IT organizations be certain of delivering the levels of availability agreed with customers in SLAs.
41
Availability Management
Principle 1:
Availability is at the core of business & end user satisfaction
42
Availability Management
Principle 2:
When things go wrong, it is still possible to achieve business & end user satisfaction
43
Availability Management
Principle 3:
Improving availability begins when it is understood how IT services integrate with and support the business
44
Availability Management
Availability Definition:
Availability is the ability of an IT Service or component to perform its required function at a stated instant or over a stated period of time. Depends on:
Availability of components resilience to failure quality of maintenance and support quality, pattern and extent of deployment of operational process and procedures security, integrity and Availability of data.
45
Availability Management
Cost of Availability / Unavailability:
46
Availability Management
Incident Lifecycle:
MTTR: Mean Time to Repair (Downtime) – Time period that elapses between the detection of an Incident and it’s Restoration. Includes: Incident, Detection, Diagnosis, Repair, Recovery, Restoration. MTBF: Mean Time Between Failures (Uptime) – Time period that elapses between Restoration and a new Incident. MTBSI: Mean Time Between System Incidents – Time period that elapses between two incidents. MTTR + MTBF.
47
Availability Management
Incident Lifecycle:
Detection time/ Time to repair (MTTR) Time between failures/Uptime (MTBF)
Start Repair
Detection time
Start Diagnose
End Repair
Incident close
INCIDENT Detection time Reaction time Repair time Restore time
INCIDENT
48
ITSC Management
Objectives:
To support the overall Business Continuity management process by ensuring that the required IT technical services and facilities can be recovered within required and agreed business time-scales
49
ITSC Management
Why Continuity Management:
Ensuring business survival by reducing the impact of a disaster or major failure Reducing the vulnerability and risk to the business by effective risk analysis and risk management Preventing the loss of Customer and User confidence Producing IT recovery plans that are integrated with and fully support the organization’s overall Business Continuity Plan(BCP)
50
ITSC Management
Considerations:
IT Service Continuity options need to be understood and the most appropriate solution chosen in support of BCM requirements Roles and responsibilities need to be identified and supported from a senior level IT recovery plans and Business Continuity plans need to be aligned regularly reviewed, revised and tested
51
Capacity Management
Objectives:
To determine the right, cost justifiable, capacity of IT resources such that the Service Levels agreed with the business are achieved at the right time.
52
Capacity Management
Responsibilities of Capacity Management:
Business Capacity management (BCM) Ensuring future business requirements for IT services are considered and matched to capability - Demand Management Service Capacity Management (SCM) Managing performance of IT services delivered to customers and documented in SLAs - Workload Management Resource Capacity management (RCM) Management of components ensuring that all resources are monitored & measured - Resource Management
53
Capacity Management
Definitions (cont.):
Modeling Trend Analysis Analytical Modeling Simulation Modeling Baseline Modeling Application Sizing: To estimate the resource requirements to support a proposed application change to ensure that it meets its required service levels. CDB – Capacity Data Base Contains all Metrics, etc. Used to create a Capacity Management Plan. Performance Management Data populates the CDB.
54
Financial Management for IT Services
Objectives:
To provide information about and control over the costs of delivering IT services that support customers business needs. Costing is a must!
55
Financial Management for IT Services
Input cost units recommended by ITIL:
Equipment Cost Units (ECU) Organization Cost Units (OCU) Transfer Cost Units (TCU) Accommodation Cost Units (ACU) Software Cost Units (SCU)
Equipment = hardware Organization = staff Transfer = costs which IT incurs acting as an agent for the customer, they do not appear as a cost against the IT department’s budget Accommodation = buildings Software = software
56
Financial Management for IT Services
Why Financial Management:
Identify the actual cost of services provided Provide accurate and vital financial information to assist in decision making Make Customers aware of what services actually cost TCO Assist in the assessment and management of changes Help influence customer behaviour Positioning for charging
57
Financial Management for IT Services
Concepts:
Accounting and Budgeting (mandatory) Understand costs involved in providing a service Prediction of future costs monitor actual against predicted costs Account for monetary spend over given period Charging (optional) Recovery of service costs from Customer Operate IT Division as a business unit if required
58
Financial Management for IT Services
IT Financial Cycle:
Business IT Requirements IT Operational Plan (inc. Budgets) Cost Analysis (Accounting) Charges
Financial Targets Costing Models Charging Policies
Feedback of proposed charges to business (effects behaviour)
59
Financial Management for IT Services
Cost Model:
The Cost Model will consist of COST ELEMENTS COST Type Transfer (Cross Charges) Hardware External Services Software People Accommodation COST Categorization Capital OR Operational Direct OR Indirect Fixed OR Variable
60
Financial Management for IT Services
Charging and Pricing Options:
Charging: No Charging – IT treated as support center Notional Charging – IT treated as cost center Actual Charging Pricing: Recover of Costs – IT treated as a service center Cost Price Plus – IT treated as a profit center Market Prices – IT treated as a profit center Support and Cost centers used “soft charging” in which no money changes hands; service and profit centers use “hard costing” in which money is transferred between bank accounts
61
Service Level Management
Objectives:
The goal for SLM is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service - in line with business or Cost justification. Through these methods, a better relationship between IT and its Customers can be developed.
62
Service Level Management
Terminology:
Service Level Requirements (SLR) – Amounts Availability, Response Time …….. Service Level Agreement (SLA) – Document Client/Supplier Operational Level Agreement (OLA) – Document Internal Underpinning Contract (UC) – Document 3rd Party Suppliers Service Improvement Program (SIP) – To Maintain Business alignment
63
Service Level Management
Service Level Agreement (SLA):
A written agreement between an IT Service provider and the IT Customer(s), defining the key service targets and responsibilities of both parties. Minimum Requirements for an Agreement: Period, Service Description, Throughput, Availability, Response Times, Signature Other Possible Clauses: Contingency arrangements, Review procedures, Change procedures, Support services, Customer responsibilities, Housekeeping, Inputs and Outputs, Changes SLAs must be monitored regularly and reviewed regularly Monitor to see if service is being delivered to specification Review to see if service specification is still appropriate
64
Security Management
Objective:
Ensure such a level of security, that the agreed availability of the infrastructure is not compromised.
65
Q&A
