ITIL Summary Service Support.doc.doc

ITIL V2 : Service SupportSummary

Author: Pieter Duboismail address: [email protected]

Total Pages: 30 Document Version: 1.2

June, 2003

IGS non-Confidential

Document Control

DistributionPieter DuboisITIL interest groups

Revision History

Date of this revision: 16/06/2003 Date of next revision: TBD

Revision Number Revision Date Summary of Changes

Changes marked

(1) 20/11/2002 Version 1.01.1 December 2002 slight adaptations1.2 June 2003 prepare for publication

References:

� Service Support (CCTA) - ISBN 0 11 330015 8

IBM Belgium Page 2 of 30


1. Overview..................................................................................................................51.1 Management Summary.........................................................................................5

2 Introduction to ITIL.......................................................................................................62.1 ITIL is.....................................................................................................................62.2 General Service Management benefits..................................................................6

3 Relationship between processes..................................................................................73.1 Configuration Management...................................................................................73.2 Service Desk..........................................................................................................73.3 Incident Management............................................................................................83.4 Problem Management...........................................................................................83.5 Change Management............................................................................................83.6 Release Management............................................................................................9

4 Configuration Management.......................................................................................104.1 Mission Statement...............................................................................................104.2 Activities..............................................................................................................104.3 Benefits...............................................................................................................104.4 Problems.............................................................................................................114.5 Costs...................................................................................................................114.6 Reporting.............................................................................................................11

4.6.1 Management Reporting.................................................................................124.6.2 Key Performance Indicators..........................................................................12

4.7 Roles & Responsibilities.......................................................................................124.7.1 Configuration Manager..................................................................................124.7.2 Configuration librarian...................................................................................12

5 Service Desk..............................................................................................................145.1 Mission Statement...............................................................................................145.2 Activities..............................................................................................................145.3 Benefits...............................................................................................................145.4 Problems.............................................................................................................155.5 Implementation considerations...........................................................................155.6 Service Desk type considerations........................................................................15

5.6.1 Local Service Desk........................................................................................155.6.2 Central Service Desk.....................................................................................155.6.3 Virtual Service Desk......................................................................................16

5.7 Reporting.............................................................................................................165.8 Service Desk profile.............................................................................................16

6 Incident Management................................................................................................176.1 Definition and mission statement........................................................................17

6.1.1 Mission statement Incident Management......................................................176.1.2 Definitions.....................................................................................................17

6.2 Activities..............................................................................................................176.3 Benefits...............................................................................................................176.4 Implementation Considerations & Success factors..............................................186.5 Problems.............................................................................................................186.6 Reporting.............................................................................................................186.7 Roles & Responsibilities.......................................................................................18

6.7.1 Incident Manager..........................................................................................186.7.2 Incident-handling support staff.....................................................................196.7.3 Second line support.......................................................................................19

7 Problem Management................................................................................................207.1 Mission Statement and scope..............................................................................20

7.1.1 Goal...............................................................................................................207.1.2 Scope............................................................................................................207.1.3 Definition.......................................................................................................20

7.2 Activities..............................................................................................................207.2.1 Problem Control............................................................................................207.2.2 Error Control..................................................................................................217.2.3 Proactive Problem Management....................................................................21



7.3 Benefits...............................................................................................................217.4 Problems.............................................................................................................217.5 Planning and implementation considerations......................................................227.6 Reporting.............................................................................................................227.7 Roles...................................................................................................................22

7.7.1 Problem Manager..........................................................................................227.7.2 Problem Support...........................................................................................22

8 Change Management.................................................................................................238.1 Goal, scope and definitions.................................................................................23

8.1.1 Goal...............................................................................................................238.1.2 Scope............................................................................................................238.1.3 Definitions.....................................................................................................23

8.2 Activities..............................................................................................................248.3 Benefits...............................................................................................................248.4 Costs & Problems................................................................................................258.5 Planning & Implementation considerations.........................................................258.6 Reporting.............................................................................................................258.7 Roles & Responsibilities.......................................................................................26

8.7.1 Change Manager...........................................................................................268.7.2 Change Advisory Board.................................................................................26

9 Release Management................................................................................................279.1 Goal, Scope & Definitions....................................................................................27

9.1.1 Goal...............................................................................................................279.1.2 Scope............................................................................................................279.1.3 Definitions.....................................................................................................27

9.2 Activities..............................................................................................................289.3 Benefits...............................................................................................................289.4 Problems.............................................................................................................289.5 Planning & Implementation considerations.........................................................299.6 Costs...................................................................................................................299.7 Reports................................................................................................................29

9.7.1 Key Performance Indicators..........................................................................299.7.2 Management Reporting.................................................................................30

9.8 Roles & responsibilities........................................................................................30



1. Overview

1.1 Management SummaryThis document provides a summary of the most relevant information of the ITIL Service Support V2 book to help with preparation of the Exin certificate in ITIL Service Management.

The following topics for all processes got particular attention: What is ITIL Mission statement different ITIL processes Activities of each ITIL process Benefits/difficulties/costs implementing ITIL process Links dependencies with other ITIL processes Information flow with other ITIL processes ITIL process roles and responsibilities Order of implementation within ITIL process Key Performance Indicators of and reports about the ITIL Process



2 Introduction to ITIL

2.1 ITIL is A Public Domain Framework: the information is publicly available and can be used

by everyone for implementation Best practice Framework: the information documents industry best practice

guidance. While not detailing every action that should be done, which is organization dependant, it provides the goals, general activities, inputs and outputs of the various processes. It provides a framework in which to place existing methods and activities.

De facto standard: ITIL by its widespread use became a de facto standard. The advantage is that there is a common language for people to speak. This makes education very important to provide all people in the process this common language

Quality Approach: ITIL focuses on providing high quality services with a focus on customer relationships. There is a strong relationship between the IT organization and the Customers.

Process Based: ITIL is a process based method. It sees IT Service Management also as a Business Process and tries to organize it that way.

2.2 General Service Management benefits Improved quality of service – more reliable business support Formalizes the use of procedures so that they are more reliable to follow Provides better view of current IT capabilities. Provides better information on current IT services provided. Better understanding of IT support by the business. Better motivated staff through better management of expectations and

responsibilities. Enhanced Customer satisfaction as it is clear what service providers know and

deliver. More flexibility and adaptability through acknowledgement and formalizing working in

a changing environment. Faster cycle times and greater success rates on implementing changes.



3 Relationship between processes

3.1 Configuration ManagementConfiguration management is an integral part of all other service management processes.

Change Management: current, accurate information about all components in the IT infrastructure makes Change management is more effective. It can even be integrated with Configuration Management. As a minimum logging of all changes should be done under control of Configuration Management. Also impact assessment should be done based on data of the CMDB. All change requests should be entered and updated in the CMDB.

Incident Management/Problem Management: Information from the CMDB help the service support group to solve Incidents and Problems faster by understanding the probably cause of failure on the Configuration Item. The CMDB should link Incident records and Problem records to the failing CI and the User.

Release Management: Requires the CMDB to know what CI’s have to be changed with a new release.

Service Level Management: uses info from the CMDB to identify CI’s making up a particular service for which SLA’s are in place. With this information, underpinning agreements can be set up.

Financial Management for IT: needs to know which components are used by whom in order to be able to charge the right departments

IT Service Continuity and Availability management: needs to know the CI’s to perform risk analysis and impact analysis on the service and business when a component fails.

Service Desk: uses CMDB information on CI’s to help resolve incidents or provide feedback on the status of a CI to the User.

3.2 Service DeskService desk is the SPOC between service provider and Users on a day-to-day basis.

Incident Management: SD is the focal point in the incident management process. It its activities are: registering Incidents, informing Users about incidents, and management of the incident end-to-end.

Change Management: As changes can cause incidents, and SD is the SPOC for incidents, it should know about all changes. SD can act as a focal point for Change requests of Users, and inform Users on progress of changes. SD can be given delegation to implement Changes to circumvent Incidents within a scope.

Problem Management: informs the Service Desk on the progress of managing problems.

Service Level Management: Any impact on SLA will arrive at the SD. So SD needs to know what the relevant SLA’s are such that incidents related to services with SLA’s get appropriate priority.

IT Service Continuity: If business continuity plans are invoked, SD plays an important coordination role.

Configuration Management: good info on CI’s helps the SD managing requests and incidents.



3.3 Incident Management Problem Management: an incident that has a large impact or several incidents

having the same cause can lead to investigation of a problem. Therefore all Incidents should be recorded and available for investigation by Problem Management.

Service Desk: Is the prime owner of the incident management process. It coordinates all actions required to manage an incident.

Change Management: Changes can lead to new incidents; therefore a way of linking incidents to changes is required.

Configuration Management: the CMDB can help incident management with identification of the CI in question. Also because of interrogation & reporting reasons it would be good to link or insert incident records in the CMDB.

Service Level Management: priorities given to incidents and escalation procedures should be agreed upon as part of the SLM process and documented in the SLA’s.

3.4 Problem Management Incident management: PM has to have access to accurate and comprehensive

recording of Incidents in order to examine the cause of incidents and trends that are happening.

Configuration Management: PM uses the CMDB to record/update its problem records, and to identify CI’s exhibiting Problems

Availability Management: is strongly connected with PM in order to identify trends and to instigate remedial action.

Change Management: Known Errors give rise to Request for Changes which fall under the responsibility of Change Management

Service Desk: PM keeps SD up-to-date of ongoing Problem Resolution.

3.5 Change Management Configuration Management: is required for change management as it depends on

the accuracy of the CMDB to assess the full impact of a change. Release Management: All releases have to go through change management when

implemented in production Service Level Management: is provided details of the Change process in the SLA’s

such that the change management procedures are known to the Users. Also the impact of changes to the SLA’s are important to take into account

Service Desk: provided details of the changes that happen such that when incidents occur on a CI due to the changes it can inform the User about the cause.

Service Level Management: Before changes happen, their impact on SLA’s have to be assessed.

Availability: Changes to CI’s should be evaluated against the impact on availability of the services it provides.

Capacity Management: before implementing a change, the impact on the capacity of the CI should be assessed. Also capacity management activities will give raise to RFC’s to ensure proper capacity is available

Security Management: before implementing a change, the impact on the security of the environment should be assessed.



IT Service Continuity: before implementing a change on a CI, it has to be assessed what the impact is on the IT Service continuity plans.

Release Management: the implementation of new releases happens under the control of change management.

3.6 Release Management Change Management: Changes may require new releases of HW & SW. The

preparation of this before it goes in production is part of Release Management, but bringing it in production happens under control of Change Management

Configuration Management: Creating a new Release should be in close integration with Configuration Management, where the state of all CI’s, whether they are in development/test/validation/production are updated in the CMDB.

Incident/Problem Management: should be provided with the documentation of the new Release and procedures of incident remedial should be provided.

Service Desk: after the roll-out of a new Release, SD should be able to support this new release in terms of requests from Users, and managing of incidents relevant to this new release.

Service Level Management: Implementation of a new release can have impact on the SLA’s. This has to be assessed and remediate in advance.

Capacity Management: The impact of a new Release on the capacity demands of the systems on which it is implemented should be assessed.

IT Service Continuity: the impact to the business by a Release when a failure occurs has to be validated by the IT Service Continuity process. Both when during the rollout as well as during normal operation, should a failure occur, impacting the usage of this Release.



4 Configuration Management

4.1 Mission StatementConfiguration Management provides IT infrastructure control through the identification, registration, monitoring and management of:

All the Configuration Items of the IT infrastructure in scope. All configurations, versions and their documentation All changes, errors, service level agreements and history of the components in

general. Relationships between the different components. Exceptions between configuration records and the real infrastructure.

Configuration Management provides a sound basis for other processes like Incident, Problem, Change and Release management by providing accurate information on all CI’s and to the SD function.

4.2 Activities1. Planning: What is the purpose, scope, objectives, policies, procedures,

organizational & technical context for configuration management2. Identification & registration: selection, identification and labeling of CI’s and the

relationships between them. CI’s can be hardware, software, documentation. Also Incident, Problem, Change records can be associated with a CI. Important is the level of detail required. Each CI should have a unique identifier.

3. Control: Only authorized and identifiable CI’s are recorded during their whole lifecycle time. It ensures updates to CI’s are associated with Change Management documents.

4. Status accounting: Reporting of current and historical data associated with each CI. It tracks the state of a CI from one state to another: test, broken, production, withdrawn.

5. Verification and audit: validate data in the CMDB with the situation in the real environment.

6. Reporting: Information about the IT infrastructure should be provided to the other processes.

4.3 Benefits Provides accurate information on CI’s: supports all other Service Management

processes Controls valuable CI’s: who is responsible for what CI. If a CI is stolen/broke, what

should be the configuration of the replacement. Helps with adherence to licenses: As the CMDB contains an Inventory of all

software installed in the environment, it helps with the verification of legality of installed software during audits

Helps financial planning: is helped by interrogating the CMDB to know expected maintenance costs, life expiry dates, replacement costs.



Changes don’t go undetected: It provides information on all changes in the environment which allows for investigation on other required changes like licensing eg.

Helps contingency planning: The CMDB identifies the CI’s making up a service which helps to know what is required to restore a certain service.

Supports Release Management: When rollouts of new hardware or software happen, information in the CMDB helps to find out what versions should be in the new release, as well as which CI’s are affected.

Improves security by controlling versions: Information on versions of CI’s are in the CMDB so inadvertent changes to other versions becomes more difficult to go unnoticed.

Helps with impact analysis of changes: reduces the risks of implementing Changes in the life environment.

Provides data on trends to Problem Management: Incidents affecting particular CI’s help to find weaknesses in the IT infrastructure.

4.4 Problems CI’s with too much detail/too little detail: causing too much work or not sufficient

control Implementation without design/analysis Overambitious schedules: making CM a bottleneck because not enough time to do

CM activities is provided No commitment from management: resulting in lack of control Perception is too bureaucratic process: resulting in trying to bypass process. Bypass process: for reasons of speed or malice. Inefficient process: because of too many manual activities Unrealistic expectations: CM is not a total solution Inflexible: Inability to process new requirements Isolation: implemented with no link to other processes. Less effective, reducing

benefits. Lack of configuration control: users can order HW/SW and install it without

passing CM.

4.5 CostsCosts are outweighed by benefits, because CM allows handling large volume of changes keeping quality. CM control reduces risks of viruses, wrong software, fraud, theft …

Staff costs developing & running procedures HW/SW configuration identification HW & SW for the CMDB & DSL Users with access to CM system Customization of CM tool Integration with other Service Management tools Training and education

4.6 Reporting



4.6.1 Management Reporting

Supports Service Management activities. Configuration audit reports Number of registered CI’s, versions, categories reports Repository capacity growth Change rate of CI’s in CMDB/DSL Backlog of CM jobs or delays caused by CM CM staffing issues & overtime Value of CI’s Reports on CI’s per location, business unit, service

4.6.2 Key Performance Indicators

Provides reports on how effective the process is. Number of times the configuration is not as authorized Incidents/Problems tracked to wrong changes RFC’s that failed due to bad data in CMDB, wrong impact assessment Cycle time to approve/implement Changes. Unused licenses Exception reports from audits

4.7 Roles & Responsibilities

4.7.1 Configuration Manager

Develops & Implements CM policy & standards Evaluates existing systems and design/implementation new systems Proposes/agrees scope CM Organizes communication plan & awareness campaign. Creates/manages the CI registration procedures Ensure roles & responsibilities are defined in the CM procedures Develops CI naming conventions and manages staff to comply with standards Manages interfaces with other ITIL processes and other business units Plans & executes population, maintenance of CMDB Provides reports on management and status issues Ensures impact analysis is possible by making sure the links between CI’s are

implemented. Ensures Changes update the CMDB Performs configuration audits and initiates corrective actions Obtain budget for having required infra and staffing taking growth of the CM process

in scope

4.7.2 Configuration librarian

Controls receipt, identification, storage and removal of all CI’s Provide information on status of CI Assist CM manager Create identification scheme for CM libraries and DSL Create libraries to hold CI’s Assist in identification of CI’s Maintain current status on CI’s



Archive superceded CI’s Hold master copies Issues copies for change/review when authorized Maintain record on all copies issued Produce configuration status reports Assist CM audits



5 Service Desk

Function, not process

5.1 Mission StatementThe Service Desk intends: To be the focal point for all service requests from the business Users towards the IT

organization (including 3rd party providers), and to manage them within Service Level Agreements

To record and manage the life cycle of incidents, with an emphasis in rapid restoration of service with minimal business impact.

To keep the User up-to-date with the status of his service request. To provide management information on relevant topics regarding the service, like:

o Service deficiencieso Customer training needso Resource usageo Service performance & targets

To be the window on the level of service offered by the IT organization towards the business.

5.2 Activities Call handling. Recording & tracking service requests, including incidents, until closure and

verification with the User. Request/Incident classification and initial support, including forwarding to 2nd

level, within Service Level agreements. Keeping customer informed on request status and priority. Initiate escalation procedures relative to the SLA. Coordinating incident handling until resolution with 2nd and 3rd line support Helping to identify problems by recording all incidents Providing management information and recommendations for service

improvement Communication of planned changes to the Users.

5.3 Benefits Improvement in Customer and business service by- and perception of IT organization Faster response times to standard requests Customers better informed of progress of requests/incidents/changes Reduced Incident resolution times Improved Business & management reporting 2nd & 3rd level teams can work more organized, less interrupt driven More efficient use of resources and technology More proactive and focused approach to service provision when using automated

infrastructure monitoring.



5.4 Problems Underestimation of scale of work: implementing a Service Desk is a major Change No real management commitment to SD. Abandoning at first sign of difficulty

(Silver Bullet lifecycle). Working ‘around’ the SD (or the ‘Helpless Desk). Not enough training for SD staff, or wrong skill set (no communication skills) No information provided to SD when implementing Changes or Releases,

resulting in less good service to the Business. No alignment with business needs

5.5 Implementation considerations Business needs & objectives must be clear, as well as Customer requirements. Management commitment is obtained and budget & resources is made available. Decide on metrics of effectiveness of the Service Desk. Investment is made for training Customers, SD staff & support teams. Decide on the right Service Desk structure (insourced, outsourced, local, remote,

virtual, customer built, off-the-shelf). Get professional support from outside Consult Customers and End Users Adopt a phased approach, generating quick wins. Communicate them. Measure progress. Acknowledge it is hard work. Advertise and sell the service

5.6 Service Desk type considerations

5.6.1 Local Service Desk

Service Requests are logged locally Difficult to provide support services over multiple locations. Duplication of skills & resources can make it expensive Requires common operational standards over the different SD’s. Local skills should be known to other SD’s. Ensure compatibility of infrastructure Use common management reporting metrics Make exchange of Incidents/Requests between SD possible Try to establish a logically shared database

5.6.2 Central Service Desk

Service Requests are logged centrally Reduced operational costs Consolidated management overview Improved usage of available resources

5.6.3 Virtual Service Desk

Physical location and associated services of SD are largely immaterial due to advances in telecommunications.

Can be accessed from anywhere in the world



Reduced operational costs Consolidated management overview Improved usage of available resources Restriction is a need of physical local presence of a specialist Common processes & procedures should be used Network performance should be right sized User/Role based authorization views on Requests should be possible

5.7 Reporting Incident reports by application/support group/customer Service Desk functioning reports

o Telephony pickup timeso Telephony talk timeso % calls answered within x secondso time worked on resolving incidents

Workload reports Daily reports on:

o Escalations by support groupo Outstanding incidentso Service breaches

Weekly reports on:o Service availabilityo Incidents that occur the most, require the most work to resolve, take the

longest to resolve.o Related incidents requiring creation of problem recordso Known Errors and RFC’so Service breacheso Customer satisfactiono Trendso Workload

Proactive reports on:o Planned changes for the following weeko Major incidens/problems/changes of the last week with workarounds/fixeso Customer incidents which were resolved unsatisfiedo Recent poorly performing infrastructure.

5.8 Service Desk profile Customer focused Articulate and methodical Trained in interpersonal skills Understand business objectives Teamplayer Emphasize with Users Act professional Accept ownership Active listener



6 Incident Management

6.1 Definition and mission statement

6.1.1 Mission statement Incident Management

To restore normal service operation, within Service Level Agreement limits, as quickly as possible, after an incident has occurred to that service, and minimize the adverse impact on business operations.

6.1.2 Definitions

1. Incident: is an event, which is not part of the standard operation of a service, and which causes/may cause interruption/reduction in the quality of that service

2. Impact: measures business criticality of the incident. Extent to which an incident leads to degradation of SLA. E.g. number of users that suffer

3. Urgency: measure for required speed of solving an incident4. Priority: measure of the expected effort to solve the incident and the order in which

to solve the incidents. Priority=f(Impact, urgencym).

6.2 Activities

Incident detection and recording: SD, record basic details (time, who, symptoms, CI’s affected) and provide incident number

Classification and initial support: SD, if service request go to SR procedure. Find Service affected. Match against SLA, and assign priority. Also identify technical details like application, version … If possible provide resolution advice. Match against Known Errors, Problems and other Incidents.

Investigation and diagnosis: SD/support group. If SD can’t help functional escalation to 2nd line. If danger of SLA breach, hierarchical escalation. Try to minimize impact by providing degraded service in the meantime. Iterative process.

Resolution and recovery: SD/support group. Can be workaround, or implementation of an RFC.

Incident closure: SD, add details resolution, time spent by whom. Ask for permission to close & close.

Incident ownership, monitoring, tracking and communication: SD

6.3 Benefits Reduced business impact of incidents by timely resolution Proactive identification of possible enhancements Management information related to business focused SLA Improved monitoring Improved management information related to aspects of service Better staff utilization: no more interrupt based handling of incidents Elimination of lost Incidents & service requests Better CMDB information



Better User/Customer satisfaction

6.4 Implementation Considerations & Success factors IM is part of larger scope. When implementing, consider Service Desk, Problem

Management, Configuration Management, Change Management and Release Management.

Start with SD and IM. Together they represent quick wins in Service Management implementation.

Define IM processes and plan creation SD as early as possible (eg. When a new IT service is implemented).

Planning phase is 3-6 months, Implementation 3 mo-1 year (also ongoing activity) Up to date CMDB is a prerequisite for an efficient IM process. Resolving incidents is much easier when having a knowledge base of resolved

incidents/problems Paper based systems are not practical Know what the SLA’s are so that incidents resolution can be targeted against it.

6.5 Problems No management/staff commitment, hence no resources Lack of clarity of business needs Badly defined service goals Working practices not reviewed or changed No service levels defined with Customer Lack of knowledge on resolving incidents No integration with other processes Resistant to use the process

6.6 Reporting Total number of incidents Mean time to resolve incidents per impact code % of incidents resolved within response time SLA average cost per incident N° of incidents per PC % of remotely resolved incidents


6.7.1 Incident Manager

Drives the effectiveness of the IM process Produces Management information Manages the work of Incident support staff Makes recommendations for improvement Develops and maintain the IM system



6.7.2 Incident-handling support staff

Incident Registration Routing service requests to support groups when necessary Initial support and classification Ownership, monitoring, tracking and communication Resolution & recovery of incidents not routed to other support groups Closure of incidents

6.7.3 Second line support

Handling service requests Incident investigation and diagnosis Detection of Problems and assigning them to problem management Resolution & Recovery of assigned Incidents



7 Problem Management

7.1 Mission Statement and scope

7.1.1 Goal

The goal of Problem Management is: To minimize the adverse impact of Incidents and Problems on the business, caused

by errors in the IT infrastructure and to prevent reoccurrence of Incidents related to these errors.

To find the root cause of Problems and to initiate corrective action. Permanently reduce number & severity of Incidents & Problems by identifying

ameliorations in the infrastructure.

2 components: Reactive: identify & solve problems in response to one or more incidents Proactive: analyze trends of incidents and identify & solve problems before they

occur.

7.1.2 Scope

Problem Control: handles problems in an effective way. Identify root cause (CI at fault), and provide SD with information and work around. Similar to Incident Control, bur more careful managed as reoccurrence should not happen.

Error Control: Progresses from Known Errors until elimination by implementation of a Change.

Proactive Problem Management: Analysis of trends from incident records provides view on potential problems b4 they occur

7.1.3 Definition

Problem: Underlying unknown cause of one or more incidents Known Error: A Problem that is successfully diagnosed and for which a Work-

around has been identified

7.2 Activities

7.2.1 Problem Control

Reactive: Find the root cause of a problem and come to a Known Error (sides with Incident Management).

Problem identification and recording: if incidents cannot be matched against Known Errors & Problems, or are recurring. Also when major Incident occurs.

Problem Classification: determine effort required to detect & recover failing CI. Impact on service levels assessed. CMDB helps! Determine: category, impact, urgency, priority.

Problem Investigation and diagnosis: leading to a Known Error (which includes a workaround for the associated Incident). Find underlying cause. Procedural errors



don’t become Known Errors. These problems are closed with appropriate categorization code.

7.2.2 Error Control

Reactive: solve the Known Error (sides with Change Management) Error Identification and recording: faulty CI is detected, and Known Error status is

assigned. Error assessment: initial assessment of means required to solve the problem and

raise of an RFC. The actual work done is under control of Change Management. Also the decision can be that some errors are not solved because too expensive e.g.

Recording error resolution: solution for each Known Error should be in the PM system, made available for incident matching

Error Closure: After successful implementation of the Change, the error is closed together with all associated Incident records. Potentially interim status given.

Monitoring Problem and error resolution progress: Change Management is responsible for implementing RFC’s, but Error control is responsible for monitoring progress in resolving Known Errors and the continuing impact of the Problem. Hence close interaction between both (PM might raise CAB). Monitoring against SLA should happen.

7.2.3 Proactive Problem Management

Identify Problems and Errors b4 Incidents occur. Trend Analysis: identify ‘fragile’ components and their reason. Requires availability

of sufficient historical data. Targeting support action: towards Problem areas requiring most support time, or

causing most impact to the business (volume of incidents, n° of Users impacted, cost to the business).

Providing information to organization: Providing insight in effort & resources spent by organization in diagnosing & resolving Problems & Known Errors to management. Also information on Work-around, permanent fixes and status information should be given to Service Desk.

7.3 Benefits Improved IT service quality: removal of structural errors improves the quality of

service. Incident volume reduction: Problems generating Incidents are removed Permanent solutions: Problems resolved stay resolved Improved knowledge on organization: PM learns from past experience, using

historical data to identify trends Higher first time fix rate at Service Desk: because incident & problem work around

data is available

7.4 Problems Absence of Incident Management and hence absence of historical incident data will

make it difficult to identify Problems. Failure linking Incident records with Problem records will make it difficult to move

from reactive PM to proactive PM Lack of management commitment makes it difficult to dedicate staff on finding

problems Undermining Service Desk role if requests come from multiple sources. No knowledge base restricts benefits of the process



Lack of prioritization of Problems that need to be tackled will take business critical problems take longer to be solved.

7.5 Planning and implementation considerations PM relies on established Incident Management process. If few resources are

available, implement first Problem Control and Error Control. After that Proactive PM.

Concentrating on top 10 Incidents previous day can be efficient for PM as 20% all Problems cause 80% of service degradation.

Ensure there is staff available to spend at least part time exclusively on working on underlying Problems in the infrastructure

IM & PM should cooperate very well but should not fall under responsibility of the same person due to conflicting interests.

7.6 Reporting Number of RFC’s raised and impact on services Time worked on investigation & diagnosis per problem type Number of Incidents linked to Problem b4 it is closed. Plans of resolution of open Problems relating to resources to be used N° of Problems/Errors split by status, service, impact, category, user group Elapsed time on closed/open problems Expected resolution time on open problems

7.7 Roles

7.7.1 Problem Manager

Develop & maintain the process Review efficiency & effectiveness process Produce management information Managing problem support staff Allocating resources for support staff Developing & maintaining Problem & Error control systems.

7.7.2 Problem Support

Identify problems Investigate problems until resolution or error identification Raising RFC’s Monitor progress on resolution of Known Errors Advice IM on Work-around for incidents related to Problems or Known Errors Identify root cause Identify trends and potential problem sources Prevent replication of problems to other systems.



8 Change Management

8.1 Goal, scope and definitions

8.1.1 Goal

Change Management ensures that standardized methods and procedures are used for efficient and prompt handling of all changes. To minimize the impact of Change-related Incidents on service quality and to improve the day-to-day operations of the organization.

8.1.2 Scope

Responsible for managing change processes involving:o Hardwareo Softwareo Documentation & procedures associated with IT infrastructure in scope

Development is not under CM but under Release Management, but should have its own project based CM.

Change Management produces approval for proposed Changes based on input from CAB and Configuration Management impact data.

CM is not about handling Service Requests (Incident Management), and not every Problem leads to a Change.

8.1.3 Definitions

Change: process of moving from one defined state to another Change Advisory Board (CAB): Body which approves changes and assists Change

Management in assessment and prioritizations of changes. CAB members can be different depending on which changes to approve. Composition should reflect user, customer and service provider view. CAB members should be:

o Change Managero Customero User manager/group representativeo Experts, technical consultantso Services staffo Contractorso Advisory Body.

Final decision is responsibility of management. CAB/EC: CAB Emergency Committee. Convened for urgent changes, or when

emergency decisions have to be made. Forward Schedule of Change (FSC): list of all Changes that have been authorized

for implementation over a previously agreed (with the business) period of time. Input for CAB. Agreed with Service Desk, Availability Management, SLA Management.

Projected Service Availability (PSA): Details of Changes to agreed Service Level Agreements, and service availability because of the currently planned FSC. Input for CAB. Agreed with Service Desk, Availability Management, SLA Management.

Post Implementation Review (PIR): assessment implemented changes after predefined period of time.



8.2 Activities Change logging and filtering: practical feasible changes only. Use standard forms.

Everybody should be able to raise requests (potentially after manager approval). Allocation of priorities: order in which to do changes. Risk assessment. Based on

impact and urgency; immediate, high, medium, low Change categorization: prior to approval, category based on impact in environment

(risk to the business). CAB meetings: to be prepared in advance with FSC, RFC’s, once or twice a year.

Not necessarily face-to-face meetings. Impact assessment on business & infrastructure. Impact not implementing. CAB provides recommendations.

Change approval: 3 principal approval groups: financial, business & technical organizations. Formally Change authority approves changes.

Change scheduling: best, one change at a time, otherwise manage concurrent changes and the impact on each other. Changes best as packaged Releases. FSC’s help in planning.

Change building, testing & implementation: CM coordinates (supported by Release Management). Back-out instructions! Testing includes:

o Performanceo Securityo Maintainabilityo Supportabilityo Reliability/availabilityo Functionality

Urgent Changes: Kept at absolute minimum. Try to test anyway, even after going life it’s useful to test. Too many urgent changes that go wrong indicated problems with:

o Problem analysiso Remedy testingo Solution implementation

Change Review: after predefined period of implementation. Check whether:o Change had desired effecto Users/Customers are content with resulto Implementation plan worked correctlyo Change was implemented within time and budgeto Back-out plan, if implemented, worked correctly.

Review Change management process: for efficiency and effectiveness. o Large change backlog: under resourced CM processo High number of unsuccessful changes: bad CM assessment and/or change

buildingo Review could point to problems in other processes, CI’s or

documentation/training users/staff

8.3 Benefits Better alignment of IT services to business requirements. Increased visibility and better communication of Changes Improved Risk Assessment Reduced adverse impact of Changes on service quality and SLA Less backed out failed changes Better Problem and Availability Management due to management information on

accumulated changes



Better productivity of Users (less disruptions, better service quality) Better productivity of IT staff, as duties are better planned and less wrong changes. Ability to absorb larger volume of Changes. Better perception of IT by the Business Reduction in N° of Changes with adverse impact because of poor CM Reduction in number of Incidents because of Changes. Low number urgent Changes.

8.4 Costs & Problems Staff Costs: Change Manager, CAB members, Change builders Support Tools Over bureaucratic: excuse not too follow it. Cultural difficulties: Staff, Users, Customers have to accept a single CM system for

all aspects of infrastructure. Changes implemented bypassing CM: eg. Bringing unknown CI’s into

infrastructure. Installing patches. Scope of CM too wide: resource constraint Ownership impacted systems unclear Change Management w/o Configuration management: less effective Untested backup procedures. Too many emergency changes No management commitment: staff resistance, lengthen implementation times Inaccurate Configuration Management data: poor impact assessment.

8.5 Planning & Implementation considerations Define responsibilities Change Manager & goal of Change Management Decide whether Change Management, Configuration Management & Release

Management are implemented together Decide on Change Management system, based on size, level of automation wanted

… Obtain adequate management commitment and resources Try to avoid parallel run CM systems and do a direct cut-over. Create awareness and support for the CM process (Training, communication plan). Go live only when procedures are in place, CAB is set up and everyone is aware

8.6 Reporting Number of changes implemented in period, by CI N° Changes without passing CM FSC’s that do not happen Backlog RFC’s Comparison resource estimation changes with reality N° of rejected changes that should’ve been done Reasons of Change N° successful Changes N° incidents traced to changes N° of backed-out changes N° of RFC/PR per CI (if high then ‘fragile’ CI)



N° of rejected changes N° of reviewed Changes that are implemented % unsuccessful Changes Backlog of Changes broken down by CI N° and trends of RFC’s N° of emergency Changes


8.7.1 Change Manager

Receive, log, filter requests & allocate priority. Reject impractical RFC’s Organize & chair CAB: set agenda, table RFC’s, and circulate FSC’s. Invite right

people. Convene & chair urgent CAB/EC’s. Authorize acceptable changes Issue FSC through Service Desk Coordinate Change building, testing & implementation according to schedules Update Change log with progress Review implemented changes Review outstanding RFC’s Analyze Change records for trends Close RFC’s Produce Management Reports

8.7.2 Change Advisory Board

Review submitted RFC’s and provide details of impact, resources required and costs. Attend CAB(/EC) meetings. Provide opinion on which Changes to authorize For CAB/EC; be available for consultation



9 Release Management

9.1 Goal, Scope & Definitions

9.1.1 Goal

Plan & oversee successful rollout of software & hardware releases Design & implement efficient procedures for distribution and installation of Changes

to IT systems Ensure changes in HW & SW are traceable, authorized, tested and correct. Communicate and manage expectations to the Customer during planning & rollout of

Releases Agree content and rollout plan for the Release, through Change Management Implement SW & HW releases in operational environment using controls from

Configuration Management and Change Management. Endure all master copies of all software is secured in the DSL and that the CMDB is

updated

9.1.2 Scope

Release Policy & Planning Release Design, build & configuration Release acceptance Rollout planning Testing release to predefined acceptance criteria Sign-off release for implementation Communication, preparation & training Audits of HW, SW prior & following implementation of Changes Installation new or upgraded hardware Storage of controlled software in DSL Release, distribution and installation of SW

9.1.3 Definitions

Release: a collection of authorized Changes to an IT service. Often divided in: o Major software Releases and hardware upgradeso Minor software Releases and hardware upgradeso Emergency software and hardware fixes

Release Unit: portion of IT infrastructure that is normally released together. Full Release: all components of the Release Unit are built, tested & implemented

together. Less possibilities of untested errors, Longer time to implement. Delta Release: includes only these CI’s in the Release Unit that have actually

changed since last Release. Package Release: grouping of Full & Delta Release to reduce the frequency of

releases. Reduces probability of outdated/incompatible SW in use. Definitive Software Library (DSL): Secure compound containing all definitive

authorized versions of all SW CI’s (master copies). Also for master copies of documentation.

Definitive Hardware Store: secure area containing definitive hardware spares. CMDB: contains definitions of planned Releases, CI’s impacted by planned and past

Releases.



9.2 Activities Release Planning: consensus contents, targets, high level schedule, site surveys,

resource req’s, roles & responsibilities, back-out plans, acceptance of support groups and Customer

Design, build, test and configure a Release: instructions to assemble a Release is a CI, compiling, linking app modules for developments, buy softwared, static reference data (post codes), automated installation routines, master copies in DSL, back-out procedures

Release Acceptance: part of Change Management process. After testing independent party. All levels of support should be involved. Done in controlled test environment. End result is a sign-off.

Rollout Planning: Adds details to Release plan with the exact installation process. Timetable of events, identified CI’s, action plan by site, create communications to Users and Release Notes, plan communication, buy req’d HW/SW. Big Bang approach or phased approach.

Communication, preparation and training: inform Customers & support what is planned and how it affects them. Meetings. Publicize Release mechanism, constraints to Users.

Distribution and installation: keep integrity of software during handling & delivery. Bring SW into active use after –automated- transfer. Update CMDB. Do final acceptance test by User.

9.3 Benefits Greater success rate in the Release of HW & SW, and hence an improved QOS

delivered to the business Consistency in the Release processes of HW & SW environments Less disruption of service to business by synchronizing Releases having impact on

different components Assurance that HW & SW in use is of known quality, because Releases are built

properly (quality control, testing, under Change Management). More stable environment as Changes are bundled into Releases and hence fewer

implementations are required. Better expectation level because of Release schedule Audit trail of Changes Control and safeguarding of hardware and software assets Higher rate of Changes can be absorbed without affecting IT QOS by using a

Release comprising of multiple changes. Lower probability of illegal copies in environment Easier detection of wrong versions and unauthorized copies Reduced time to Release and fewer delays

9.4 Problems Staff resistance to procedures because of lack knowledge on benefits. Education is

required Those needing it the most have the least time to adopt it. Find minimal-impact

foothold. Circumvention of RM procedures attempts. Bypassing standard procedures to install emergency fix Controlled builds should happen both in test and production. Copying SW from one

environment to another should not be done.



Cost of Release Management procedures and tools could be seen as expensive and ‘too difficult’.

Unclear ownership and responsibilities between operational groups and development projects.

Insufficient resources (both human as machine/network) for adequate testing reduce the effectiveness of procedures.

Differences in environments (dev, test, prod) may allow errors to slip trough Non-tested back-out procedures or reluctance to activate them. Pressure to put inadequate tested SW & HW into production.

9.5 Planning & Implementation considerations Release Management is heavily dependent on Configuration Management and

Change Management. Release policies and procedures Release roles and responsibilities Choice of tools to support Release of HW and SW in the life environment Required resources and training. Build, test, distribution & live environments Form of DSL setup, and when to start with it. Naming conventions. Built environment setup and tests Start gradual to streamline procedures and technical tools. Start testing procedures by putting Releases from Test to operational acceptance b4

putting in production Back-up plans for when tools fail

9.6 Costs Development of best practices, procedures Education and training Staff costs File storage costs for DSL Build, test, distribution, archive environment costs Space equipment Computer & network resources for moving SW in & out of the DSL and for build, test,

distributing Releases Automation procedures costs Initial operating costs are higher due to learning curve Installation of management & staging servers Operational costs

9.7 Reports

9.7.1 Key Performance Indicators

Releases built and implemented on schedule, within budget. Low number of Releases having to be backed out. Secure and accurate management of DSL No evidence of SW in DSL not passed quality checks or reworks of SW after pulled

from DSL Compliance with legal restrictions on bought software Accurate distribution of Releases to all sites



No evidence of use of unauthorized SW on all sites No evidence of paying wasteful licenses Accurate recording of all Release activities in CMDB

9.7.2 Management Reporting

Number of major and minor releases Number of problems in life environment due to implementing new Release Number of Releases completed in agreed timescales.

9.8 Roles & responsibilities Release Manager Change Manager Development Manager & staff Test Manager & staff Operations Manager & staff Desktop Support Manager & staff Server Manager & staff Service Desk Users


Technology

ITIL Summary Service Support.doc.doc