IT Service Management Case Studies · ITIL as an agent for change – 1 (Chapter 3) ITIL as an...

Only authorised users may download this material subject to the terms and conditions of the userlicence supplied. Unauthorised users should contact TSO© Crown Copyright.This is a Value Added product which falls outside the scope of the HMSO Class Licence.

IT Infrastructure Library

IT ServiceManagementCase Studies

This ITIL Back Catalogue represents an historicalrepository of knowledge on IT ServiceManagement. Given its age, however, it is notpart of OGC's current Best Practice Portfolio, andmay not be updated in the future.

Applications to reuse, reproduce or republishmaterial in this publication should be sent toHMSO, Licensing Division, St Clements House,2-16 Colegate, Norwich, NR3 1BQ, Tel No +44 (0)1603 621000 Fax No +44 (0) 1603 723000, E-mail: [email protected], or complete theapplication form on the HMSO websitewww.hmso.gov.uk/forms/cform2.htm. HMSO,in consultation with Office of GovernmentCommerce - IT Directorate (OGC-ITD) willprepare a licence based on standard termstailored to your particular requirements includingpayment terms.

LONDON: THE STATIONERY OFFICE

http://[email protected]/

http://www.hmso.gov.uk/forms/cform2.htm/

IT Infrastructure LibraryIT Service Management Case Studies

Only authorised users may download this material subject to the terms and conditions of the userlicence supplied. Unauthorised users should contact TSO.

© Crown copyright 1996 Published by permission of the Central Computer andTelecommunications Agency under licence from theController of HMSO

Applications for reproduction should be made toHer Majesty's Stationery Office, The Copyright Unit,St Clements House, 2–16 Colegate, Norwich NR3 1BQ

Second impression 1999 ISBN 0 11 330676 8

This is a Value Added product which falls outside the scope of the HMSO Class Licence.© Crown Copyright.

Contents

3


ContentsChapter Page

1 Introduction 71.1 Purpose1.2 Audience1.3 Structure of this volume

2 Overview 92.1 Fit with CCTA Guidance2.2 Synopses

3 ITIL as an agent for change – study 1 173.1 Where we started from and what triggered

the change3.2 Where we wanted to be3.3 How we got there – or not!3.4 Where we are now3.5 Where we go from here3.6 Lessons learned

4 ITIL as an agent for change – study 2 294.1 Introduction4.2 The starting point4.3 The next step4.4 How they went about it4.5 Where they are now4.6 Where next?4.7 Conclusion

5 Implementing a systems managed environment 455.1 Introduction5.2 Where we were5.3 Where we wanted to be5.4 How we got there5.5 Where we are now5.6 General issues and lessons learned

6 Delivering an application support and 59maintenance service6.1 Introduction6.2 Where we start from6.3 Where we want to be6.4 How we get there6.5 Benefits of applying ITIL principles6.6 Where we want to go in the future



4


7 Technological change, market testing 71and agency status7.1 Where were we?7.2 How, exactly, did we start?7.3 The opposition7.4 So, what happened next?7.5 And then came market testing ...7.6 So, where did it all end?7.7 Conclusion

8 Service management implementation 918.1 Introduction8.2 The way we were8.3 Improving service to customers8.4 The threat of CCT8.5 The future8.6 One final point – perception

9 Disaster recovery planning 1019.1 Introduction9.2 The need for a Contingency Plan9.3 Business continuity9.4 Testing the Plan9.5 Future plans9.6 The verdict on ITIL

10 ITIL support for IT service quality improvement 11110.1 Just books and bureaucracy10.2 The company10.3 ... but why change the basic way of working?10.4 Did ITIL seem like a good bet?10.5 So, before we started ...10.6 IPW10.7 Production10.8 A place for everything ...10.9 The first implementation10.10 Lessons about restructuring10.11 Checking the results10.12 The morning after10.13 The final hurdle10.14 Conclusions

11 Justifying and implementing support tools 131for ITIL11.1 Introduction11.2 Where we started from11.3 Justification: processes of change11.4 Orientation: where we wanted to be


Contents

5


11.5 Implementation: how we got there11.6 Where we are now11.7 Where we go from here: on the trail of ITIL11.8 Users become customers

12 Measuring advantages gained from using ITIL 14112.1 Introduction12.2 Where we started from and what triggered

the change12.3 How we started12.4 How we got out12.5 Measuring12.6 How we got where we wanted to be12.7 Lessons learned12.8 Where we go from here

Annex A Profiles of consultancies involved 151

Bibliography 159

Glossary 163



6


THIS PAGE HAS BEEN LEFT BLANK INTENTIONALLY


Chapter 1Introduction

7


1 Introduction1.1 Purpose

1.2 Audience

The main aim of the IT Infrastructure Library (ITIL) hasbeen well documented. It is to facilitate improvements inefficiency and effectiveness in the provision of quality ITservices and the management of the IT infrastructurewithin any organisation. Each ITIL book provides bestpractice guidance on how to plan, implement and reviewa certain element of IT service management. But peoplelike to read about the problems other people encounterwhen using the guidance in real life situations and howthey overcame those problems.

This book contains ten case studies, provided bycompanies that use ITIL as a basis for their IT servicemanagement consultancy and software tools. The studiesare based on their experiences either when working onindividual projects or, in one case, of experienceaccumulated over a large number of projects.Organisations at all stages of implementing IT servicemanagement, from planning to review, or organisationshaving already done so, will find the case studies usefulwhen formulating their approach, or when looking toimprove the quality of their existing systems.

The obvious, and probably the main, audience for thesecase studies is IT Service Managers and managers withresponsibility for delivery and support of essentialelements of IT service management. They should alsoprove of interest and relevance to those withresponsibilities for outsourced IT service provision; toQuality Managers; to applications developers; and to ITsystems auditors. As well as those involved in theprovision of IT service, those on the receiving end, iebusiness managers, may find it useful to read about theproblems experienced and the benefits achieved by otherorganisations in the delivery and receipt of IT servicemanagement.

The studies demonstrate the range of differentenvironments within which ITIL has proved its valueand relevance in private sector organisations, local andcentral government and utilities. Geographically, the tenstudies are split equally between the UK and theNetherlands, those countries currently making most useof ITIL guidance, although this situation is changing



8


1.3 Structure of thisvolume

rapidly as ITIL is taken up in countries around theworld.

Chapter 2 describes how the case studies have beenassembled.

Chapters 3 to 12 contain the ten case studies.

Annex A gives a short profile of the consultancies thatprovided the case studies. These and other companiescan provide services and products in support of ITservice management. Annex A does not constitute an'approved' list of ITIL service providers.

A chapter outlining other related guidance and usefulinformation and a Glossary of terms used in this volumeare also provided.


Chapter 2Overview

9


2 OverviewThis book provides a set of ten case studies that will be ofinterest and use to organisations involved with orcontemplating an approach to IT service management ascontained in the IT Infrastructure Library (ITIL).

The case studies have been selected to show how thecontributors set about tackling problems they met whenimplementing certain elements of IT service managementin a live situation. They are intended to present acomplementary picture to the more theoretical approachcontained within the mainstream ITIL books. As suchthey represent a more pragmatic view, concentrating onproblems encountered and overcome and with thecompromises needed to achieve a broadly ITILconformant application within a real organisation.

The case studies clearly reflect the different organisationswho have prepared them and the wide variety oforganisations on whose experience their work is based.Only the very minimum of editorial change has beenmade to the case studies submitted for this book. Thisminimalist approach has been a deliberate act to preserveas far as possible the directness of the experiencerecounted.

Some of the case studies have been written so as to keepthe source organisation anonymous. Others name thoseconcerned – both organisations and individuals. We havebeen pleased to see this; it allows positive identificationof two elements of implementing IT Service Management(ITSM) that cannot be put across convincingly in themainstream ITIL work:

• service management is not only about ITequipment and organisational procedures – it ismore about people, ITSM people providing aservice to their users and customers

• the success (or failure) of an ITSM initiative often(arguably always) depends on the enthusiasm anddrive of a single manager to make it happen.Without a 'champion' willing to put their reputation,and perhaps their job, on the line to support anddrive the project, then it is less likely to happen.



10


2.1 Fit with CCTAguidance

2.2 Synopses

ITIL as an agent forchange – 1(Chapter 3)

ITIL as an agent forchange – 2(Chapter 4)

Reinforcement of this is evident from the frequency withwhich the case studies are written in the first person.When a case study starts out with 'What we wanted todo,' then the reader is already confident of a happyending.

The approach to implementing IT service management,contained in ITIL, is based on perceived contemporarybest practice. However, best practice is evolutionary,especially in an area such as ITIL which combines IT andmanagement. These case studies document somesituations where it was necessary to adapt the ITILguidance to fit with the particular organisation and itscircumstances. This can be taken as an indication ofITIL's adaptability: it does not rely on a dogmatic 'all ornothing' approach. It is, and indeed always has been, atool for managers – documenting best practice, offering astructure for organisations, but allowing IT servicemanagement professionals to function and bring theirskills to the particular circumstances they find.

ITIL was introduced into an IS organisation threatenedby competition in supplier choice for its services to theclient business. Quality improvements to its processesand customer focus were necessary for its survival. Thekeys to success shown in this study were implementationof ITIL (but avoiding a bureaucratic approach),responsibility upon all staff to improve processes andgood communications throughout the qualityimprovement programme. Most importantly, successcame by taking as a starting point the gap between thecustomers' needs and the capabilities in the organisation.Having survived, the organisation intends to furtherimprove its service delivery and customer responsiveness.

An electricity supplier's central IT department was facedwith the threat of outsourcing. A review by ITIL expertsshowed that the department was not satisfying end-users' requirements and had poor contact with itscustomers. Internal management had not tackled controland reporting issues.

A quality improvement programme was set in train toimprove service management. The department was re-organised, work group specific procedures set up andtraining given.


Chapter 2Overview

11


Implementing a systemsmanaged environment(Chapter 5)

Delivering an applicationsupport and maintenanceservice(Chapter 6)

Technological change,market testing and agencystatus(Chapter 7)

Service managementimplementation(Chapter 8)

Some improvement has enabled the department tosurvive, but the customers' expectations have been raisedand must now be met! Help Desk and problemmanagement procedures are working well, butimplementation of other ITIL service managementprocesses needs to be completed and service levelagreements with the customers formalised.

Following the acquisition of this medium-sized companyin the financial and pensions sector, strong pressure wasplaced on its IT department by the larger company toimplement ITIL best practice. The mission was toimplement a systems management environment for theprovision of computer facilities to the company tomeasured levels of service – in three months.

The effort and resource to do this was underestimatedand things did not progress quickly enough until aService Manager was appointed to see through theimplementation.

The provider of third party application support andmaintenance services has incorporated the ITIL approachto provide a means of continually improving itseffectiveness and efficiency, and to follow recognisedstandards.

The company aims to install an application supportservice tailored to match each customer's environment.This case study highlights issues in implementing eachITIL element.

This is a case study about a government department's ITdirectorate, and the way in which it responded, in servicemanagement terms, to three changes drivers:technological advance, market testing and executiveagency status. Initially, only one division of thedirectorate was targeted for implementing servicemanagement, but the interdependencies with otherdivisions and the need to create a new relationship withthe directorate's customers suggested the need toimplement each ITIL function in turn across the wholeorganisation.

A service culture has been created within this localauthority's IT department. User dissatisfaction withcomputer response times and a haphazard approach tochange requests had resulted in 'total disillusionmentwith IT'. The new manager of the department started to



12


Disaster recoveryplanning(Chapter 9)

ITIL support for ITservice qualityimprovement(Chapter 10)

introduce a service management culture, and thendiscovered ITIL, which became the guiding light forachieving this aim. The organisation responded to thethreat of compulsory competitive tendering by orderingan external review of the health of its servicemanagement. This showed up weaknesses which wereaddressed, through the further implementation of ITILfunctions and training.

This case study starts with the contingency planning forthe local authority's financial services computer systems.The priority was to have disaster recovery in place formainframe systems, then a more complete businesscontinuity plan was developed, with external advice.

The IT department is now developing its intelligentcustomer role as a facilitator and enabler of IS/IT. Thefocus has moved out beyond mainframe contingencyplanning into the office systems generally and theintention, over time, is to implement business continuityplanning for all of the authority's IS.

There was pressure on the IT department of a majortelecommunications company to do more with less – toan improved level of quality! A search for methods forimproving the entire service lifecycle ended with ITIL.But ITIL would only be taken on if it proved flexible andadaptable to the organisational structure of the ITdepartment, and provided the means to build in qualitywithout incurring more staff overheads.

The department focused first on processes in order tobring about overall service quality improvements. A

model (Implementation of Process-oriented Workflow™) wasdefined to place ITIL functions within the circle ofquality improvement. When the processes, processboundaries, roles and responsibilities were clear, itbecame easy to build procedures and work instructions,drawing on the guidance contained in ITIL modules. Anexternal audit recorded a high level of ISO9002compliance. The challenge was then to extendimplementation of the model into the End User ServiceDepartment ...


Chapter 2Overview

13


Justifying andimplementing supporttools for ITIL(Chapter 11)

Measuring advantagesgained from using ITIL(Chapter 12)

ITIL enables IT specialists to adapt to technological,political and market developments. The IT department ofan industrial insurance board faced competition as asupplier of IT services to an organisation whose owncustomers are now free to choose where to obtaininsurance services. The IT department started by seekingconfiguration management and Help Desk tools andfound it was on the trail of ITIL.

The final case study describes the benefits of successfulimplementation of ITIL in the computing centre andinfrastructure department of a large organisationimplementing social legislation. There have beenfrustrations along the way, but the ITIL approach hascome to be of vital importance to the department,focusing as it does now not just on software, hardwareand networks, but on providing services to customersthat meet their specific requirements and anticipatingthe impact of new developments oh futurerequirements.

IPW is a trademark of the Quint Wellington Redwood Group and PTTTelecom Automation



14





ITIL as an agent for change – study 1





Chapter 3ITIL as an agent for change – study 1

17


3 ITIL as an agent for change – study 1

Section Page

3.1 Where we started from and what 19triggered the change

3.2 Where we wanted to be 21

3.3 How we got there – or not! 22

3.4 Where we are now 25

3.5 Where we go from here 25

3.6 Lessons learned 25

This case study was provided byThe Pink Elephant Group



18






19


3.1 Where we started fromand what triggered thechange

How do you get twenty individual groups of IS staff toshare one vision?

No, it isn't a children's playground joke, but a problemwhich was costing us lots of money and threatening uswith the loss of our customer base.

Let me set the scene. We work in the IS division of amulti-national chemical company. The company employstwenty thousand people in twenty international locationsand is rapidly expanding through acquisition of smallerchemical concerns.

We had been through a consolidation exercise in whichthe IS units, which were fragmented throughout theorganisation, were brought together under the control ofone umbrella IS division. This division alone consisted ofsix hundred staff. The intention was to give IS a standardvision and direction.

However, despite this central control, each IS unitinterpreted the IS policy differently, with the result thatthere was no uniformity in direction for IS.

Figure 3.1: Direction and vision of IS



20


We also had a major shift in company policy to contendwith; it had been decided to concentrate on 'corebusiness', which for the company meant chemicals, notIT. The business units were to be allowed to buy their ITservices from the supplier of their choice. If we wanted tosurvive as an IS organisation, we had to prove our worthto our customers.

The upshot was, we had to get our house in order. Weneeded to have enough central control to be able to steerthe division and maximise the benefits of having a largeIS organisation, while allowing each IS unit to be flexibleenough to be able to meet local business needs. Our staffhad to feel part of one group, with its own identity andmentality. We chose ITIL as our method for gettingeveryone pulling in the same direction, through theimplementation of a Total Quality Programme.

Figure 3.2: Centralised/decentralised IT infrastructure locationand control

The IT infrastructure consisted of an amalgam of DECVax, IBM 3090, IBM AS400, and Novell networks.

The IS organisation supported the business throughprovision of manufacturing and office applications.




21

Figure 3.3: Drivers for change

3.2 Where we wantedto be

A quality improvement programme needs a goal.Without that goal, you lose the motivation of the verypeople you need to make the programme a success, andyou have no chance of achieving the results you want.

We tried to make the improvement programme goals asconcrete as we could, and where possible, measurable.We were working with a disparate, internationalorganisation, in which culture, language, customs andeven the IS customers were different in each IS unit. Weneeded to have 'one language' by which everyone couldcommunicate. The language we chose was ITIL

Our principal goal was survival. We had sub-goals bywhich to achieve this principal goal:

• ensure that all staff speak 'one language'

• ensure an improvement in the customer- perceivedquality of IT service provision

• develop clearly defined responsibilities forprocesses and tasks

• stimulate the development of a 'knowledge network',by which the skills and expertise of our staff could bemost effectively used to support our customers.



22


3.3 How we got there –or not!

ITIL – the referencemodel

The major headache for an IT service provider isbalancing the achieved quality of service provisionagainst the level the customer expects. It is an art to get itright!

We started by investigating our customers' expectationsand perception of the service levels we were providing.We then objectively examined our service provisioncapabilities to ensure we were capable of meeting thoseexpectations. The difference between what our customersexpected and what we were currently providing,tempered by financial constraints, gave us the scope ofthe quality improvement programme. In effect, ourcustomers were assisting us in setting our goals andpriorities.

Incidentally, we periodically checked with our customerson how we were doing and how we measured up to theirexpectations. We found that the regular request forfeedback was beneficial in developing a healthy workingrelationship with our customers; we received positive aswell as negative criticism, and our customers felt wewere taking them seriously.

We wanted a reference model for the improvementprogramme, to provide assurance that the goals we hadset ourselves were in fact achievable. For themanagement of IT infrastructure, ITIL was the bestavailable.

The programme was tackled in the form of a structured,but highly fluid project. And we tried to get staff buy-infrom the start.

There was no official project leader or rigid project plan.Instead, we had goals, teams, responsibilities, milestonesand senior management commitment. We didn't intendto let the project be owned by a single project manager,but by the whole IS organisation!

We involved ten per cent of our staff directly in theprogramme, who were of all nationalities and experiencelevels.

We initially tackled the operational level processes, iethe five ITIL service support modules; Help Desk,Problem Management, Change Management,Configuration Management and Software Control andDistribution.




23

Work groups

We wanted to establish and improve our work processesso that an employee's actions became process-driveninstead of hierarchically driven, for example workactivities were to be determined by their place in aprocess rather than by instructions given by a boss. Theoverall knowledge and understanding of the work weundertook was to shift down through the organisation tothe work floor.

Five work groups were established, one per process, eachhaving eight to ten members. The work groups weresupported by a steering group, composed of the ITdirector, an external advisor and the process teammanagers.

We chose to use a cyclic approach, based on Deming'squality circles. We analysed the current situation, froze it,analysed the bottlenecks and came up withimprovements. One improvement level was carried outper cycle, and all processes were improved in parallel.

We went for optimal improvement, which we judged tobe overall implementation to 80% of the processaccording to ITIL, rather than the maximum we couldhave possibly achieved.

Meetings were forbidden! There is no quicker way todestroy motivation than make people suffer hours ofboring meetings. Instead, we instigated work groups,which met once a week under the guidance of anexternal advisor. There were no minutes, but an actionlist and a spirit of positive determination which weemployed to achieve results. People left the work groupsessions pleased with what they had achieved.

The process improvement tasks were fitted in alongside aperson's day-to-day work. After all, improving yourwork is a part of your normal job! Staff responsible forcarrying out an activity are often in the best position tosay how it can be made more effective or efficient; wegave them the responsibility and authority to carry outthe improvement.

If the amount of work was a problem, we hired reliefstaff to do the 'normal' work and take some of thepressure off our permanent employees.

An incredibly important area of the whole qualityprogramme was public relations, which supported theprocess work groups. A team of four staff produced



24


Quick hits

weekly newsletters distributed by e-mail) and posters foroffice walls.

Folders detailing programme progress were sent to anemployee's home address, along with his/her salary slip.This form of mailing was an innovation for our company,and was well-received.

Achieved milestones were celebrated with cake, onwhich the initials 'ITIL' were iced, and staff were treatedto periodic day excursions. We put a lot of effort intocreating commitment for the quality improvementprogramme.

The programme was heavily results-oriented, and gearedfor results which the customer would notice. We lookedfor 'quick hits'; anywhere where improvements could bemade which quickly showed cost reduction and/orquality improvement. We used existing resources whereat all possible in order to keep costs down. No heavytomes, department manuals or handbooks which couldsubstitute as a doorstop were produced! Instead wedeveloped a quality handbook, process descriptions andsupporting procedures to act as a guide for IT servicedelivery for the distributed IS units. Flowcharts weredeveloped and pinned up on the wall to make theprocess visible and accessible for everyone.

We developed task-responsibility matrices, so thatownership of activities rested where it belonged.

We needed information on our workload and currentperformance. How many calls were we handling in acertain time period? Of what priority and impact? Howmany changes were being requested? We startedmeasuring at the very beginning of the programme andused the information to support decisions as needed.

All IT infrastructure equipment of one type, eg DEC Vax,IBM, was brought together in one physical location forease of management.

Later in the programme, we established a team of fivestaff selected from the process work groups to look atpotential tools to support the processes.

The whole change process was much slower thanexpected; we had anticipated that we would achieve ourgoals within about three months, whereas it took about




25

3.4 Where we are now

3.5 Where we go from here

3.6 Lessons learned

a year in total. People needed time to get into the swingof the programme, and before we were up to speed we'dhad to completely revise our milestones. (But we still hadour cake, and ate it!)

End-user interaction is handled locally at the businessunit level. This covers delivery of those IT servicesrequired by the end-user, first line support (Help Desk)and handling change requests. This method of workingprovides maximum flexibility to the customer at the'point of sale'.

The 'front-end' IT units are supported by theconsolidated computer centres and specialist groups,which agree to supply services to the individual unitsaccording to specified requirements.

ITIL implementation is considered to be finished to therequired maturity level, and to have met its specifiedgoals in supporting the Total Quality Programme. Anexternal auditor was brought in to objectively evaluatethe programme, and gave us the 'thumbs-up'!

Our next step is to go through the programme again, thistime improving our IT service delivery processes. Weespecially want to improve our service levelmanagement process, and develop our customer liaisonfunction. Our intention is to strengthen our relationshipwith the budget-holding business customers, havingalready succeeded in improving our relationship withthe end-users of our services.

If we were about to do the same project again, wewouldn't change a single thing; we are very satisfiedwith the result. In fact, we are going to follow the samework method for the next programme.

We did, however, learn that you have to watch out forbureaucracy! Try to keep the paperwork to a minimum;go for a balanced approach addressing procedures,people's attitudes, resources and tools, and sharedknowledge (synergy in the organisation).

Avoid having meetings, go for work groups instead. Andpublic relations is of the utmost importance!Communicate what you are trying to achieve and howyou are approaching it. Try to get early commitment.

We did find that the 'pull' approach, where change wasdriven by the work groups, demanded a great amount



26


of energy. There is a temptation to lapse into the 'push'approach, where pressure from on-high declares thatpeople either show commitment to the programme, orfind themselves another employer! People found itdifficult to commit to change, and after all, any changecontains a certain amount of pain, until they understoodthe need for and purpose of the change.

Make the programme goals public, ensure thatperformance indicators are known, and that progress iscommunicated to the whole organisation.

Go first for improving the processes which directly affectthe end-user, the operational processes and aim forquick, tangible results. And keep your customerinvolved!



ITIL as an agent for change – study 2







29


Section Page

4.1 Introduction 31

4.2 The starting point 31

4.3 The next step 33

4.4 How they did it 34

4.5 Where they are now 40

4.6 Where next? 41

4.7 Conclusion 41

This case study was provided byThe Pink Elephant Group




30





31

4 ITIL as an agent for change – study 24.1 Introduction

4.2 The starting point

How would you feel if your local electricity board saidthey could guarantee to supply you with electricity for95% of the day? Pleased?

That's one hour and twelve minutes when electricitymight not be available. You can bet your cotton socksthat in that hour you'd miss your favourite televisionprogramme, be gasping for a cup of tea and not even beable to telephone your mother because your cordless'phone runs off the mains!

In actual fact, figures of 99.99% are more realistic.Electricity boards generally manage their core businesswell enough to ensure that their customers are providedwith their product on demand.

This case describes what happened when an electricityboard looked critically at their IT, and realised that 95%availability of IT services was not providing optimalsupport for the core business.

The utility company in question supplies electricity to adefined geographical region, employing two thousandstaff to do so. It has undergone some major changes inthe past few years, the principal being a transition from asemi-government institution to an independentcompany. There have also been some acquisitions of, andfusions and collaborations with, other companies withthe aim of being able to purchase bulk quantities of rawmaterials at a reduced tariff.

The company is composed of four major divisions,responsible for energy distribution, business supportactivities (eg vehicles, meters) and for the shops, whichhandle contact with the electricity board customer.

Each division has its own IT unit, which functionsindependently of the central IS division. The individualIT unit is responsible for its own IT plans, its ownpurchasing, and its own first-line user support.The central IS Division provides central IT services,development services, support and attempts to co-ordinate the IS/IT planning through standards andpolicy.




32

Figure 4.1: Organisation chartAt the start of this quality programme, a department inthe IS division which attracted critical review was the ITService Centre (ITSC).

Senior directors were doubting the need for theorganisation to have its own computer centre, and wereconsidering the possibility of outsourcing.

At the same time, there were plans afoot to move to anew application for business support; SAP-RIVA, apackage to handle statistics, based on the SAP family ofenterprise application systems.

The head of the IS division wanted to know if ITSC wascapable of working with the product, as its complexitydemands a high-quality IT management organisation. Ifthe answer was 'no', then ITSC had no added value forthe organisation.

He also wanted to know how the IT unit was functioningwhen compared to other similar IT units. Could thequality of the IT service provision be improved? Howsatisfied were the end-users with the IT serviceprovision?

There was a major problem which complicated the issue.There was a clash of personalities between the head of ISand the head of the ITSC unit, and they were unable tocommunicate effectively with each other. This led to poorinternal communication, with policy decisions not beingpassed through to the work floor,




33

ITIL consultancyreview

4.3 The next step

and consequent staff demotivation due to lack ofdirection. Externally, the ITSC was not taken seriously,and had credibility problems in its relationship with end-users.

Having seen a presentation on ITIL, the head of IScommissioned an ITIL consultancy review of thedepartment. The results confirmed suspicions that thequality of the IT management processes, especially thetactical ones, were currently inadequate to enableintroduction of SAP-RIVA.

The investigation also highlighted that interdepartmentalcommunications were poor. IT services were not beingdelivered to user requirements, and there wasconsiderable dissatisfaction among users, caused by lackof customer contact and lack of information.

Possibly in part due to the friction between departments,it was found that within the ITSC itself, colleaguessupported each other, creating a culture in which peopleand values were considered important. There was littleevident respect for regulations or rules, and thedepartment lacked management direction andleadership. Control and structure were considered to beabsent, especially when regarded from the end-users'perspective. There was no consultation with the usersover longer term IT plans. Innovation, and self-improvement of work, was also conspicuous by itsabsence. All in all, not a pretty picture!

So what was the next step? The IT architecture had beendecided on. It was to be based on SAP-RIVA for finance,sales, planning and logistics activities. For company widesupport of design work ISICAD was chosen, and PCswere to fulfil the local office systems requirements,providing access to all applications and tools a userneeded from his/her own workstation. The networkwould be based on OS/2 Lan Manager.

The IT services which were to be delivered using theseplatforms had to meet business requirements, whichmeant that someone had to talk to the business. The ISdivision wanted the quality of ITSC IT service delivery toimprove. The IT service management processes were tobe brought to a maturity level which demonstrated thatITSC had control over its processes, with clearly definedtasks and responsibilities, standards, a modular




34

4.4 How they did it

Major problems

handbook and with procedures and guidelines beingdeveloped to support the provision of IT services.

A quality improvement programme was set up in theform of a project. The review had covered the ITprocesses service level management, configurationmanagement, Help Desk, problem management, changemanagement, availability management and costmanagement. These processes would be improved overthe following year and another review would check onprogress at the end of the project.

There followed a two month phase in which relevantinformation was gathered and consultations were heldwith representatives of the business, which led to thedevelopment of a project plan.

From the information gathering, it was clear that thefollowing was needed:

• a clearly communicated mission statement

• an unequivocal organisational structure

• clearly communicated task responsibilities

• formal reporting and communication lines

• a split between IT support and production

• eradication of unnecessary tasks.

It was obvious that communication and clarity ofpurpose were areas which needed some attention.

At the start of the project it was possible to identify somemajor problems, which may be inherent in a 'publicservice' organisation. Work tended to be divided up onthe basis of status, 'empires' and personal preferences,rather than looking at the underlying processes drivingthe work. This meant that the divisions of labour werenot always the most efficient or effective for the workwhich had to be done, and led to islands being formedwhich had their own personalised goalsets, oftenconflicting with those of the organisation as a whole.

Despite recognition that the recommendations from theIT service management review needed to beimplemented, no one in ITSC really believed they wouldwork. The department was suffering from 'Consultitis', (asurfeit of consultancy), and a lack of belief in its




35

Phase one

abilities. Management displayed no motivation for staffmanagement, with the result that the staff had littlemotivation for the work.

There was no formal (or even informal) structure forcommunication and reporting, which exacerbated thegeneral feeling of helplessness and hopelessness on thepart of the staff.

Interdepartmental co-ordination had not been wellmanaged. The fact that each business division had itsown IT unit and could buy its own IT equipment meantthat configuration management was a nightmare! (Theconfiguration database was, in fact, found to be full ofrubbish data. It was decided not to clean it, but to moveto a new system and enter the correct data from scratch.)

ITSC was functioning as a second-line support unitwithout agreeing responsibilities and aligningexpectations with the first-line unit. Agreeing a servicelevel agreement with users in this sort of situation isalmost impossible.

The project plan was divided into two phases.

Phase one clearly defined the scope of the project withinthe organisation. The activities included:

• creation of a mission statement

• definition of services, and production of a servicecatalogue which contains a list of the IT services,categorised into priority groups

• identification of tasks and responsibilities

• documentation of user requirements, and hencederivation of service level requirements

• definition of a communication model for theproject, and for the organisation when the projectis complete.

It was recommended that IS be reorganised, so that thenumber of IT units was reduced to four. ITSC wasabolished. Instead, a User Support Centre and aComputer Centre were created.




36

Figure 4.2: New organisation

Communication

The Computer Centre covered only mainframes andcontained the sub-units of System Programming,Production and Technical System management. Itsprincipal function was to provide cost effective servicesfor the user applications and IT infrastructure, that is,facility management and support.

The User Support Unit contained the sub-units HelpDesk, and Office Systems and Networks. Its core taskswere to identify, solve and prevent incidents in IT servicedelivery and to manage the organisation's networkfacilities.

A formal communication structure was proposed for theIT units:

• a daily morning work discussion in whichunsolved incidents and problems were examined

• a weekly problem meeting, in which longer termproblems were examined, and action taken to clearthem

• a weekly change meeting, (in fact a ChangeAdvisory Board meeting), in which proposedchanges were examined, and decisions taken onwhether/when to implement them

• a fortnightly general planning and personnelmeeting




37

Phase two

• a monthly (internal) service level meeting in whichthe general performance of the IT unit wasexamined

• a monthly (external) service level meeting inwhich the customer took part.

Phase two covered the implementation of ITIL processes.Critical success factors were identified as:

• the proposed organisational change beingimplemented according to the phase one proposal

• commitment to the project being activelydemonstrated by management

• no moving goalposts

• a quality programme (including training) for allstaff

• adequate resources (ie people).

The staff active in the project were grouped into teams,each of which had a particular role. With hindsight, theproject structure was mimicking the hierarchical cultureof the organisation itself, and took the problems inherentin the organisation with it. Another structure would havebeen more appropriate, for example, having linemanagement lead the implementation instead of using aformal project structure.

Nevertheless, the project structure comprised threelayers and was headed by a sponsoring senior manager,the head of IS.

The layers were made up of a steering group, who actedas a source of advice for the project, a project group, whoco-ordinated the activities of the work groups, and threework groups, each led by a manager who was in turn amember of the project group. The work groups were splitinto areas of responsibility:

• problem management, Help Desk andconfiguration management

• change management

• service level management, cost management andavailability management.




38

The plan for phase two was composed of a series ofgeneral steps:

• form the project steering, project and work groups

• ITIL training, to get everyone thinking along thesame lines

• project training

• set up handbook

• set up procedures, standards and guidelines

which were in turn supplemented by workgroup-specificactivities. As an example 'Plan and Implement Help DeskImprovement':

• appoint a Help Desk supervisor

• define role Help Desk

• record current working practices

• categorise incidents

• define relationships with other processes anddepartments

• write procedures

• record tools available

• specify metrics

• improve accommodation

• decide on communication to users

• decide on management reporting

• decide on audits

• write implementation plan

• implement.

The Help Desk was implemented in the form of onecentral desk which staff units could call directly and fourdistributed Help Desks for support of the business units.The Help Desk staff were given formal training and werecoached by allocating experienced staff to educate thosewith less experience. Secondments to the computercentre were organised. The aim was to clear 80% of callsat the Help Desk, without referral to




39

Implementationproblems

Improvements

second-line support. The task was clear and staff wereenthusiastic.

During phase two, an audit took place to look at theimplementation problems. It was found that two projectswere having a major impact on the quality improvementprogramme. These projects, conversion of a mainframeoperating system, and the move to SAP-RIVA, were bothallocated a higher priority in management attention.There was too little management commitment and noactual hands-on steering. The amount of resourcesactually available for the ITIL implementation was wellbelow that required and requested at the outset. Theproject was hindered by bureaucracy and hierarchy.

The knowledge and capabilities of the IT unit staff werefound to be below the expected and required level. Forexample, it necessitated the introduction of the coachingscheme for Help Desk staff.

There was a natural aversion to change, and anunwillingness to undertake any actions to change. Thiswas typified by the fact that one appointed member ofthe steering group never showed up for a meeting.

Not enough attention was given to the steering group atthe beginning of the project. They hadn't been throughITIL training and often either forgot or didn't understandtheir role. If a work group produced a piece of work,such as a procedure or plan, the steering group wouldoften have a different interpretation of its content to thatintended by the work group and would devote much ofits energy to discussions concerning content.

It was also shown that problems with particularmembers of staff, who were deliberately obstructingimplementation of ITIL, were circumvented. Seniormanagement did not want to take on a confrontation.Ninety per cent of problems in the project were political.

However, despite these problems during the project,there was a change of staff mentality. People began towork proactively, producing ideas to improve theirwork. Customer and service orientation was clearlyimproved, aided by increased staff awareness of thegoals and functions of the IS division. This all helped toincrease the knowledge, motivation and involvement ofstaff.




40

4.5 Where they are now

The reorganisation was declared a success, while ITILprovided an insight into the IT costs, and enabled acharging structure to be put in place.

For the Computer Centre, ITIL meant that:

• tasks were defined

• reports were improved, and contained meaningfulinformation

• a daily meeting was established, which assisted inimproving communication

• production planning was implemented.

For the User Support Centre (Office Systems), ITIL meantthat:

• a renewed configuration management wasestablished

• problem management was greatly improved

• all changes to the IT infrastructure passed throughthe change management process

• incident control has gained recognition as being ofcrucial importance for the business customer

• a daily meeting was established, which assisted inimproving communication

• reports were improved, and contained meaningfulinformation

• central and distributed Help Desks have beenestablished.

Staff have benefited in terms of experience and theircareer opportunities.

Areas which still need addressing include customercontact. Users are still not receiving the operational andtactical level information they require.

Procedures have been drawn up, but they have notresulted in an improvement in the perceived quality ofthe IT services by the customer. Efficiencyimprovements are mainly in the operational levelprocesses, and have not yet been implemented in thetactical level processes, where the customer experiencesthe benefit.




41

4.6 Where next?

4.7 Conclusion

The procedures are inward looking and do not reallyconsider the customer's or a peer department'sperspective. The procedures also exceed the originalscope of the project, and require the co-operation of otherdepartments to make them function correctly. It was alsonoted that staff do not necessarily follow the proceduresin their day-to-day work!

The project 'Quality improvement through ITILimplementation' has led to the customer havingincreased expectations of the IT unit, which cannot all befulfilled at present.

A review of the processes after implementation showedthat problem management and the Help Desk functionwere formalised, with management reports, definition oftasks and authorisation, documentation of procedures,work instructions and planning all having been definedand implemented. The change management,configuration management, availability management andcost management processes were found still to haveshortcomings, in that the quality of management reportswere not yet up to standard and the processes did notfunction as described in the documented workinstructions and procedures. Service level managementwas still in its infancy.

The next step is to complete the implementation of andconsolidate these processes, and to begin implementationof tactical level processes. A major area still to beaddressed is the relationship with the customer,preferably to be formalised through the use of negotiatedservice level agreements. The customer requirements canbe translated into operational targets for the ITorganisation, and assist in steering the work of the unit.

If the project was being tackled again, it wouldprobably be done in a much less structured way. Themethod of formally documenting everything beforeimplementation increased bureaucracy and producedno 'quick hits' to assist in motivation and directionforming within the project. People had the impressionthat all the effort put into the project was merelyproducing a pile of paper!




42




Implementing a systems managed environment





Chapter 5Implementing a systems managed environment


45

5 Implementing a systems managed environment

Section Page

5.1 Introduction 47

5.2 Where we were 47

5.3 Where we wanted to be 48

5.4 How we got there 49


5.6 General issues and lessons learned 54

This case study was provided byF.I. Group plc




46





47

5 Implementing a systems managed environment5.1 Introduction

5.2 Where we were

ConfigurationManagement

Help Desk

Support groups

Problem Management

Change Management

This case study looks at the ITIL issues that arose when amedium-sized company in the financial and

pensions sector, was acquired by a larger company withsimilar interests. The smaller company's IT departmentdealt with independent PC-based applications togetherwith local UNIX and other mini-based systems. TheApplications Support Teams supported over fourteenmajor systems spread over forty offices nation-wide.

A reorganisation took place after the acquisition toprovide a stronger focus on service delivery. There waspressure to introduce ITIL best practices from themainframe-orientated acquiring company.

The case study looks at the pragmatic approach taken toimplementing ITIL procedures appropriate to PC-andLAN-based systems. It highlights the danger ofunderestimating the effort and tools required toimplement ITIL modules and shows what can beachieved even with these constraints.

There was an existing asset register, but the validity ofthe information on this was felt to be doubtful, and it wasupdated only twice a year.

Originally incidents were dealt with by the individualsupport teams, with users ringing the support teamsdirectly with their problems There had been a Help Deskfor PC support that had worked well.

In addition, there were local operations and supportgroups spread around the country that dealt with basichardware problems, and acted as a filter for commoneasy-to-solve incidents.

The only problem management in operation was anunofficial analysis undertaken within the support teams.Some teams had a paper Known Error list and one of theHelp Desk staff who had previously been on supportalso had a card index file with common errors that hadcome to her attention.

Some systems already had change procedures in place,but these were not consistent, and some areas had noprocedures at all.




48

Service LevelAgreements (SLAs)

AvailabilityManagement

5.3 Where we wantedto be

Due to previous reorganisations and take-overs of smallfirms, no one had an overall view of all the systems theApplications Support team were supporting, and therewere no formal Service Level Agreements (SLAs) ordefinitions.

Some information was available on types of hardware,but this had not been considered in conjunction withavailability of the systems themselves.

As part of the management reorganisation there was aprocess review of the Operational Services section, whichdecided to introduce Systems Management principlesinto the organisation. A two day Systems ManagementWorkshop was therefore held with the objectives of:

• agreeing a mission statement

• defining and prioritising action plans to achievethe mission

• establishing a team with commitment to theagreed activities.

As part of the workshop there was a brainstormingsession on critical success factors and a review of theeffectiveness of the current processes within theOperational Services Department. These were then usedto develop action plans and initiate a number of projects,including:

• providing an integrated Help Desk


• problem management

• availability management

• defining the roles and responsibilities of local andregional support

• staff

• instituting SLAs.

The agreed mission statement was as follows:

To implement a systems managed environmentfor the provision of the company's computerfacilities in the UK, to measured levels of service,by June 1994.




49

5.4 How we got there


Although the target date gave a timescale of threemonths, only the Help Desk project was assigned to amember of staff without other commitments. As a resultonly the integrated Help Desk was operational by thetarget date.

A Service Manager was appointed at this time tocontinue with the ITIL initiatives already started, and anexternal consultant was contracted to work with her toreview the Help Desk and to assist in drafting roles andresponsibilities and procedures.

Their first task was to decide which was the order ofpriority for the implementation of the ITIL ServiceDelivery elements. They initiated the following projects,with priority being given to change management:

• inventory control as a first step to configurationmanagement



• training in ITIL concepts

• availability management

• roles, responsibilities and scope of local supportgroups

• service definition, and production of a skeletonSLA in preparation for SLA negotiation

• introduction of new Help Desk software thatwould also integrate problem and changemanagement.

During the Service Workshop the management team hadoriginally given Configuration Management a lowerpriority, because it was seen to be too difficult toimplement at the same time as a parallel OfficeAutomation project was taking place.

However, the newly appointed Service Manager, withthe consultant, decided that the planned roll out of OfficeAutomation (OA) was an ideal opportunity to gatherinformation on the hardware in place within thecompany.

They felt that to institute full ConfigurationManagement, ie both version control of all configurable




50

Help Desk

Problem Management

items and the relationship between them, withoutappropriate tools being in place, and with all the otherchanges occurring, would be too resource intensive.Therefore, a project should be initialised looking atInventory Management of configurable items but notattempting to map the relationships between them.

A Help Desk Manager was appointed who had been ateam leader for one of the major systems, and Help Desksoftware was developed in-house using the PC-basedQ&A database manager package.

The Help Desk was based on the 'intelligent model' withthe Help Desk staff having a mixture of skills includingbusiness knowledge, plus systems knowledge with goodPC and word processing skills.

The external consultant's review was carried out after theHelp Desk had been in operation for three months. Thisreview found that, despite the lack of resources and thelimited Help Desk software, the procedures had workedwell, with all calls being routed to the Help Desk.

As a result the Help Desk was working efficiently as anincident logging point and managing to clear around50% of incidents without referring to second-linesupport. However, it was reactive rather than proactiveas there were no problem management procedures inplace and no priority codes or target response timeswere set.

It became obvious that a more flexible support tool wasrequired, which would integrate incident control andproblem and change management and provide a KnownError database, preferably linking from the start to anInventory system and eventually to a full configurationmanagement database.

Initially Help Desk Exec was the preferred tool of theHelp Desk Manager although it did not fully meet theGroups' needs. Eventually it was decided to investigateIHD (IBM's Integrated Help Desk).

The priority was to load errors and problems into aKnown Error database, appoint a Problem Manager withresponsibility for analysing incidents to identifyunderlying causes and to agree priority and severitycodes, plus target response times.




51

Change Management

The procedures for problem management were drafted,but it was decided to delay implementation of them untilthe new Help Desk software was installed, as the Q&Adatabase did not easily allow for prioritisation of calls,nor provide a sufficiently speedy look-up on otherdatabases such as a Known Error database.

It was decided that change management should have ahigh priority and could be tackled without problemmanagement being in operation and could, if necessary,be a paper-based system and not, therefore, dependanton the new Help Desk software.

Procedures were written which outlined the roles andresponsibilities of the Change Manager, Change Co-ordinator, Change Requestor, Change Implementor andChange Builder. A request for change (RFC) form wasdesigned, with an RFC log, and it was decided that theseprocedures should be followed both in ApplicationSupport and also in Operations.

As the Group procedures specified that any changes overten man/days have to be lodged as a project and followproject procedures, it was decided that the need for aChange Advisory Board for changes outside theauthorisation limits of the Change Manager was notnecessary.

A great deal of discussion took place with the teams,who were initially reluctant to accept that small changesof under one man-day should go through this procedure.Some ITIL training was undertaken, which raisedawareness of the importance of including all effort,testing and implementing in the estimate. As a result theteams agreed that all changes, no matter how minor,should go through the change procedure.

The procedures were piloted in the two areas perceivedto be most problematic, PC support and PC movement.This gave rise to a number of amendments in the RFCform. Unfortunately, the volume of changes in theseareas was low and did not constitute a representativepilot. When the procedures were extended to other areas,it became apparent that a paper-based system was tootime consuming, and the RFC form and log weretransferred on to a Q&A database.




52

Service LevelAgreements (SLAs)




Help Desk

Problem Management

The Service Manager together with the consultantundertook a comprehensive Service Level Definitionreview. Once this had been completed a skeleton SLAwas drawn up.

A metrics gathering exercise on the availability record ofdifferent types of hardware was undertaken, however,without a more appropriate Help Desk tool, it was notpossible to measure the overall availability of software.

The detail to be held for both hardware and software, hasnow been defined and is awaiting the appropriate tool tobe put into action.

Meanwhile a simplified inventory database has beencreated with a record of all users and their software. Thisis being compiled during the Office Automation (OA)roll out and input into a Hardcat asset register.Ultimately it will be used to populate the new Help Deskand Configuration Management tool.

The decision has not yet been reached on an integratedHelp Desk tool. Therefore, some further tailoring of theQ&A database has been undertaken which, although notideal, is proving to be a reasonable stop-gap. The HelpDesk staff have had ITIL awareness training and areproviding a good centralised service to the users.

The Help Desk has increased the number of incidentsresolved by them, and has built up a good reputationwith the users. The consequential reduction in thevolume of calls going to second-line support has reducedthe number of staff required in applications support andhence the overall cost.

Some Problem Management has been achieved evenwithout a PMS system, and in one particular areastudying the underlying causes of the problems hashalved the number of calls. Identification of trends hasstarted, and the Help Desk staff are more aware of theproblem management issues rather than simply beingconcerned with 'fire-fighting'. As a result the resolutionrate by the Help Desk has increased from 40% to 50%.

Problem management techniques were used when thenumber of incidents on the OA roll out started toescalate, and this was of considerable benefit in




53

Change Management

Service LevelAgreements


highlighting to the third party supplier the underlyingproblems causing the incidents.

It would have been beneficial, with hindsight, to haveimplemented an interim tool solution to problemmanagement. It was assumed that the new Help Desksoftware would have been procured more quickly and,therefore, that it was a waste of resources to tailor theexisting system. If this had been done, metrics gatheringon priority of calls could have been started earlier, moretrends identified, and a basic Known Error databaseinstalled.

A specification for a medium-term solution is nowunderway as the Q&A database has a number ofshortcomings.

Generally change management procedures have madestaff far more aware of the need for accurate reportingand estimating. In Operations, measurable targets havebeen set against number of changes implemented.

Until an integrated tool is available a Lotus NotesDatabase will be used. This will allow different views ofthe change request form depending upon what type ofchange is underway. For example, the Operations sectionfound it time consuming to use a RFC that was designedfor both Software and Hardware.

The Service Manager has met with the service ownersand has issued the skeleton SLA to the main businessareas, feedback from the users has been positive so far.

As problem management procedures have not beenimplemented with the priority levels the metrics havenot yet been gathered. It is felt that it will be necessary torecord these for three months before agreeing a baseline.

More information has been gained on what the primarycomponents of the systems are, and which are the servicestoppers. There is now a heightened awareness of theimportance of availability management and the impactthat this area has on SLAs.




54

5.6 General issues andlessons learned

Key lessons

Benefits

Overall the exercise has been beneficial, even in thoseareas of service delivery that do not yet have a fullyoperational procedure.

The timescale needed to put procedures into place wasunderestimated at first. The exercise is both timeconsuming and resource intensive.

A major factor in delaying the start of projects was howlittle time people had available. The projects movedahead much more quickly once a dedicated ServiceManager was in place.

The decision to wait for the introduction of a specificintegrated Help Desk tool that would include change,problem and configuration management was, inretrospect, incorrect. An interim solution should havebeen sought while the decisions about tools were beingmade. However, no one anticipated the extra time thatthe interface with the new Group management wouldtake.

It is expected that when an integrated Help Desk andproblem and change management tool with a KnownError database is in place the resolution of calls by theHelp Desk will increase to around 70%.

In summary the key lessons learnt were as follows:

ensure that agreement is forthcoming to release staff todevote to ITIL initiatives

• ensure that tactical as well as strategic plans areincorporated into the schedule so that movementcan be on several fronts at once

• always look at the process as a whole as well aslooking at the individual projects.

General benefits have been:

• a reduction in resources needed for applicationssupport

• a reduction in volume of incidents coming throughto the Help Desk

• an increased resolution of incidents at the HelpDesk level

• increased awareness of the importance of SLAsespecially when dealing with third party support.




55

The aim is to continue with the ITIL initiatives alreadystarted, implementing where necessary medium termsoftware solutions, so that some of the initiatives canmove ahead without the new Help Desk software beingin place.




56




Delivering an application supportand maintenance service





Chapter 6Delivering an application support and maintenance service

59


6 Delivering an application support andmaintenance service

Section Page

6.1 Introduction 61

6.2 Where we start from 61

6.3 Where we want to be 62

6.4 How we get there 63

6.5 Benefits of applying ITIL principles 66

6.6 Where we want to go in the future 67

This case study was provided byFI Group plc




60




61


6 Delivering an application support andmaintenance service

6.1 Introduction

6.2 Where we start from

ITIL Service Supportelements

F.I. Group plc (FI) has been a supplier of third partyapplication support and maintenance for a number ofyears. When the ITIL Library became available FI trainedits Application Support consultants and ServiceManagers in ITIL Service Support and Service Deliveryand reviewed its Application Support service against therelevant ITIL functions. This was to ensure that theservice followed recognised standards and to provide ameans of continually improving the effectiveness andefficiency of the service provided.

This approach is illustrated by looking at how FI deliversan Application Support service for a range of customersacross a variety of platforms applying the most relevantITIL Service Support and Service Delivery elements. Allthe techniques described are equally applicable toproviding an in-house software support service.

The case study starts by describing what FI finds in termsof the ITIL Service Support and Service Deliveryelements at the beginning of a project with a newcustomer. It then goes on to describe how we apply ITILbest practices to the service and what benefits thisapproach provides. It ends by looking at the expectedfuture direction of Application Support services and thelikely relevance of ITIL.

Although each organisation is unique in its approach tosoftware support we find that they have a lot in commonand the findings listed below are typical across the rangeof organisations which we service.

Hardly any organisations have a fully comprehensivecentralised Configuration Management Database,covering hardware, software and data.

It is rare for organisations to make a clear distinctionbetween incidents, problems and known errors. They donot collect and report useful metrics and therefore do nothave an adequate Problem Management System.

Most mature IT departments have formal changemanagement along ITIL lines for large enhancements




62

ITIL Service Deliveryelements

6.3 Where we want to be

and developments but not for smaller, maintenance-typechanges.

It is usual to find a central, non-expert IT Help Deskusing a tool for logging incidents, but often it is difficultto ensure that all application incidents are logged via theHelp Desk.

Virtually all our customers have formal software controland distribution mechanisms and authorisationprocedures, with some release planning and somecontingency/regression planning.

It is usual to find Service Level Agreements (SLAs)between operations and user areas defining the on-lineservice hours, percentage availability and sometimessystem response times and critical deadlines butextremely rare to find an SLA specifically coveringapplication support.Organisations tend to have basic capacity managementcovering disk capacity and data storage only.The majority of our customers have contingencyplanning, controlled security and access (sometimes lesswell controlled for PCs) and some formal risk assessmentidentifying critical systems and critical times.

We rarely find formal availability management forapplication software. Optimisation of softwareavailability relies almost exclusively on the experienceand skill of the support teams.

The majority of our customers do not have formal costmanagement of their Support and Maintenance functionand this may be a major factor in the decision tooutsource application support.

FI's key objectives for the application support coveringboth Service Support and Service Delivery are:

• deliver the contracted service reliably andefficiently

• enhance the systems' performance and availabilitythrough cost effective preventive maintenance

• provide a more cost effective service by increasingthe productivity of the support team.



63


6.4 How we get there

6.4.1 ITIL Service SupportElements


Problem Management

The Application Support service is tailored to functionwithin each customer environment, using existing formalprocedures and tools, and normally operating as aspecialist support group within the customer's ITdepartment.

The areas where we deliver most benefit are thosedirectly or partially under our control and these are theones described below.

As a first step in Configuration Management, wedocument the installation naming conventions. We thenproduce a 'configuration map' of the environment(s),menus, libraries, system, application software anddocumentation.

Code movement is controlled by library managementtools with cross reference to configuration items (CIs)where appropriate. For example, in one case, CIs alreadyunder development were identified, showing location,status and ownership by application, change or problemnumber. Entries were archived after implementation toform a change history.

We instigate version numbering if this is not already inplace, and maintain an amendment history, including thedescription, date, owner, change, problem, release,amendment and version number as comments at thestart of each CI entry.

Our approach to problem management is based onensuring that all problems have an owner, that initialemphasis is on system recovery and incident resolution,and that relevant metrics are collected to ensure timelyand targeted problem identification.

We identify a Problem Manager (often on a team rotabasis) who manages all problems associated with thesystems under our care, whether they are caused byapplication software or something else (eg hardware,network, operations or user instructions).

We concentrate on fast response diagnosis and systemrecovery, making the system available for use as soon aspossible. This action is then followed up by full impactanalysis, problem resolution and cost-justified preventivemaintenance.




64

Change Management

6.4.2 ITIL Service Deliveryelements

Service LevelManagement

We identify performance indicators for the agreedservice and collect relevant metrics so that we can reportagainst these to identify trends and monitor servicedelivery performance. The metrics will be tailored to theneeds of each organisation but typically include:

• responsiveness and effectiveness of the service(time to respond, fix by priority)

• weak components

• accuracy of changes

• numbers of incidents/problems over time bypriority downtime

• support effort - normal and 'out-of-hours'.

The discipline of having a contractual agreement forsupport and maintenance drives organisations towardsmore formal change management. Changes are identifiedas Work Parcels within the contract and are sized, costedand formally signed off by the customer's ChangeManager/Contract Manager.

FI's approach is formal. We review and prioritise anybacklog of change requests with the customer at the startof the project and at regular intervals thereafter. We thenlog change requests and provide timely estimates ofimpact and effort to the customer so that he can assessthe cost/benefit and agree priorities. Finally we bundleapproved change requests, where possible withinpriorities and timescales, for cost-effectivedevelopment/testing.

Applying formal change procedures to all outstandingrequests can have dramatic results. For one customer wewere able to reduce a three year backlog to less than twomonths for high priority changes by agreeing with userswhat was essential, applying cost benefit analysis to allchanges and removing cosmetic change requests.

As well as complying with any existing SLAs FI expectsto work to a formal SLA. The focus is on deliveringbenefits to the business both in terms of the application(its functionality and deliverables), and the ApplicationManagement Service itself. We proactively monitor the



65


Capacity Management


regular business critical deliverables (reports,transmissions, interface dependencies, on-lineavailability).

FI works closely with the users to 'fine-tune' both theapplication and the service in response to specificbusiness needs. Typically these include:

• ensuring availability at business critical times

• tuning performance and throughput at peak timessuch as year end

• planning or rescheduling for unusual businessperiods (eg holidays)

• providing additional or improved functionality.

Targets for the service are defined in conjunction withthe business, and the service is monitored and regularlyreviewed for key performance indicators includingresponsiveness, productivity, accuracy and quality. Wefrequently find that there are unstated requirements inthe service required. In one case the delivery of a weeklysales report to the directors had the highest possiblepriority although this was not specified anywhere. As aresult we built this into our own service definitionalthough it never became part of the formal SLA.

Capacity management is addressed both directly andindirectly. We estimate capacity and performance impactof software changes as part of change management andestimate peak load requirements as part of riskmanagement.

We identify, via the problem management system,capacity or performance issues that require increasingcapacity or database reorganisation or clear-down. Wegive the support team guidelines for optimisingperformance and storage utilisation and ensure that theguidelines are followed.

Availability relies heavily on good change and problemmanagement. Effective service reporting metrics,collected via the problem management mechanism, areessential to identify trends, vulnerabilities and threats toavailability.

FI aims to improve application reliability by reducing theoverall number of incidents occurring, particularly thoseinvolving downtime, by cost-justified preventive




66

Cost Management

6.5 Benefits of applyingITIL principles


Problem Management

maintenance. This may cover a number of vulnerablesystem components including storage utilisation,database and file organisation, user instructions andtraining, operator instructions and training,documentation and system interfaces. Reliability is alsoimproved by better quality control, testing andimplementation procedures for both application andsystem changes.

Availability can be improved significantly by preventivemaintenance on batch operations. One of our customershad a very tight batch window where one failure in therun could delay the start of the on-line service by overtwo hours. We created intermediate back-up andrecovery points in the batch run reducing the recoverytime to ten minutes and eliminating the need to repeatthe whole batch run in the event of the failure.

The very fact of outsourcing, and transfer of 'real' moneytends to crystallise the cost issue, since a chargingmechanism must be in place. Formalised changemanagement results in improved cost management andbetter control of how resources are utilised and moneyspent.

Cost effectiveness and productivity are carefullymonitored, comparing actuals against estimates. Thescope and cost of the support service is periodicallyrenegotiated so that the service continues to meetchanging business needs and remains cost effective.

The benefits derived from applying the best practices ofthe various ITIL elements tend to overlap but for claritythey are listed by element below.

Consistent, reliable impact analysis which facilitateschange and problem diagnosis and reduces risk.

Less reliance on the knowledge of key individuals andbetter cross-skilling within the support team improvingflexibility and productivity.

Tighter control of the systems portfolio, reducing errorsat all stages of the maintenance process.

Improved productivity and system availability.

Improved user confidence – problems are satisfactorilyresolved, and the business kept informed.

Better control with a measured, improving service.



67


Change Management

Service LevelManagement


Cost Management

6.5.1 Overall ITIL ServiceSupport and Deliverybenefits

6.6 Where we want to goin the future

The customer can make more effective decisions basedon the known cost and benefits of requested changes.Better control and planning – changes delivered areaccurate and within known timescales, enabling both theIT department and users to plan ahead.

Increased productivity for the IT department and users.

Application Management service and applicationdeliverables tuned to business needs.

Improved application reliability, maintainability andexpected life span.

Risk identification and reduction.

Containment of cost and targeted control of IT budget.

Demonstrable productivity gains of 20% to 50%.

Reduction or elimination of IT management effort spent'fire fighting'.

Improved flexibility and responsiveness to businessneeds.

Improved user perception and confidence from aprofessional relationship with users.

FI consistently finds that outsourcing of the Support andMaintenance function tends to formalise the applicationmanagement process and drive organisations towardsITIL best practices. The more that ITIL practices arefollowed by an organisation the easier it is to implementa cost effective, high quality, Application Supportservice.

From FI's viewpoint the incorporation of ITIL bestpractices is a key factor in the process of continuallyrefining our Application Support service to increase thebenefits and provide value for money. We work inpartnership with our customers to improve the costeffectiveness of the Application Support service withinthe overall service framework supplied by our customersto their users.

Increasingly, FI is being asked to provide the samequality of service in distributed or client/serverapplications with their more complex series of interactivetechnologies. Typically in these environments many ofthe mainframe ITIL best practices have not beenimplemented. We are convinced that it is essential




68

that ITIL principles be applied in this arena if thepromised business benefits and improvedresponsiveness of client/server developments are to bedelivered.



Technological change, market testingand agency status





Chapter 7Technological change, market testing and agency status


71

7 Technological change, market testingand agency status

Section Page

7.1 Where were we? 73

7.2 How, exactly, did we start? 74

7.3 The opposition 77

7.4 So, what happened next? 78

7.5 And then came market testing ... 81

7.6 So, where did it all end? 83

7.7 Conclusion 86

This case study was provided byThe Quint Wellington Redwood Group




72





73

7 Technological change, market testingand agency status

7.1 Where were we?

'What is the use of a book', thought Alice,'without pictures or conversations?'

Lewis CarrollThis is a case study about a government department ITDirectorate and the way in which it approached, inService Management terms, technological change, markettesting and agency status. ITIL formed the basis of thatapproach but there was more to it, so much more, thancould be read in the books.

By the autumn of 1990, the departmental IT strategy wasset and it had become clear that, despite a wholesalemove towards UNIX and client/server computing formuch of the newly planned application softwaredevelopment, the mainframe processes would berequired for a number of years yet. So, how could thatsituation be managed to ensure that:

♥ each existing mainframe system had a suitableconfiguration on which to run for the rest of itslife?

♥ the quality, reliability and availability of ITservices was improved?

♥ the costs of providing services were lowered?

(And why didn't we think of flexibility, I wonder,because it became one of the most significantfactors.)

The answer to the first and third objectives lay inrestructuring the existing mainframe sites and resourcesso that significant overhead and staff savings could bemade in their operation and management. In total therewere 298 staff involved in providing IT services,excluding applications development and generaladministration and planning. How the reduction wasmore than achieved within a fairly short period of timedoes not form part of this detailed case study, but the factthat it provided a hook upon which to hang – and justify– the second objective was crucial to the success




74

7.2 How, exactly, did westart?

of the whole exercise. And there were some lessons to belearned:

♣ mammoth IS consultancy studies have a habit ofproducing mammoth amounts of paper andlooking, in far too much detail, too far forward. Ifyou build upon their detail, you are building uponsand. And further, they tend to repeat themselvesendlessly. This is a technique used by all projectmanagers to instil belief in the veracity of whatthey say and write!

'What I tell you three times is true.'

♣ to gain general acceptance of where, in broadterms, you think you want to go is important; toplan the framework that should take you there isextremely important; to know what the next stepshould be is crucial; to know where to begin isvital. So ...

'Begin at the beginning,' the King said, gravely, 'and go ontill you come to the end: then stop.'

Activities had actually started a little earlier in that year.That was when the concept of having Service LevelAgreements had been widely discussed – and indeed theidea of them had become fashionable throughoutgovernment IT circles. Here, then, was the second hook,for the Service Level Manager post established tonegotiate and conclude these agreements was to providejust the additional resource we required in order to makeprogress on that second objective.

By June 1991, therefore, we had completed the studyinto the future management of our IT Servicesinfrastructure. Why did there have to be a formal'study'? Simply because that was what the book said wehad to do. And, for all its fine words, did it convinceone single soul outside of the project of the sense of ourobjectives, of the urgent need to change? I doubt it!Indeed, its thoroughness (indigestibility?) may havemade it seem even more suspect – for by now theopposition was beginning to awake and it is entirelynatural to suspect what you do not understand.




75

Objectives

Scope

And the fact that you have enthusiasts in your midst ...

Why, sometimes I've believed as many as six impossiblethings before breakfast.

... makes the situation even more suspicious.

The objectives of our study were to:

♦ identify the most suitable approach to theimplementation of the principles of the CCTA ITInfrastructure Library within the directorate's ITServices division

(How carefully we had avoided suggesting thatthe project might stray into other areas of thedirectorate! A nonsense of course since, as becamequite clear later on, any project of this nature mustencompass the whole of the IS managementactivity in order to be successful.)

♦ prepare cost and resource estimates for fullimplementation of the recommended approachand plan in detail the next phase

(Note that we did not have to promise to makesavings of any particular magnitude since our first'hook' had provided all the financial justificationneeded. However, that did not absolve us fromattempting an estimate of the benefits – see later.)

In addition to the above, the scope of the project was setout in detail. This was to:

♠ examine current IT service managementprocedures and establish appropriate metrics inorder to set a baseline and to identify those areaswhich will obtain most benefit from implementingITIL disciplines

(A very good place to start. But be careful how youcriticise current practices and procedures for it isnot the management of today's services that youare concerned with, it is whether today's methodswill be suitable for tomorrow's services.)

♠ review available software tools for ITinfrastructure management. Assess the extent towhich requirements are (or will be) satisfied bysuch tools




76

(A necessary activity but, as the second item in thelist, it was in the wrong place. Having come torealise that, whatever the departmental pressures,Service Level Agreements were almost the lastthings we should be concerned with at this stage,we were also beginning to understand that asoftware-led project was not a sensible way toproceed. Before tools are bought there needs to bea detailed understanding of how they are going tobe used – and by whom! We were not at that stage.Still, it did no harm to look.)

♠ produce an outline implementation plan for ITIL –to reflect an objective assessment of priorities aswell as logical dependencies

(We knew that there would be insufficientresources to progress at a common speed on abroad front. So we had to decide what fitted bestwith what and where the greatest paybacks were.)

♠ structure the plan into logical stages that can beprogressed with a high degree of independence,according to resource availability; the plan tocontain details of effort, skills, timescales and costs(including software and hardware)

(We were beginning to understand that, just as theMay 1991 BCS Release 2 Industry Structure Modelhad predicted, a host of different skills are neededto manage a modern IS infrastructure and that itwas important to start sorting out the differentlyshaped pegs, partly through trial and error, partlythrough training.)

The rule is, jam tomorrow and jam yesterday – butnever jam today.

♠ produce a cost estimate for each stage andidentify the expected benefits, tangible andotherwise.

(In the event, and probably in common with mostother projects of this nature, no singular costsaving attributable directly to infrastructuremanagement changes was ever identified. Thedirect savings arising from, for example, thegreater automation of operations managementcould be and were estimated at this stage.However, the statistics needed to estimate the




77

7.3 The opposition

measurable savings later achieved from (say) areduction in the numbers of failures attributable toservice changes were simply not there.)

The result of all this activity was that those intimatelyinvolved became resolutely convinced of the sense of theITIL approach to service management. However, thosearound them – including some at the highest levels ofmanagement in the directorate – remained sceptical or, atbest, supportive but unconvinced that radical changewould be required in order to survive. In the end, it wasnot so much the lack of direct support that mattered, butthe variable nature of that support.

Will you, won't you, will you, won't you, will you jointhe dance?

But who can blame them?

If everyone minded their own business ... the world would goround a deal faster than it does.

As in many IT organisations, each 'division' had its ownagenda, felt its own threats, and had developed its ownset of relationships. Each resisted change unless it hadbeen invented locally. Each concentrated on their standof trees and missed the wood.

The main problem was that, despite the assurancesgiven in the earlier study terms of reference, it had notproved possible to limit the scope of the servicemanagement activities to just the IT Services division.When we came to examine and describe the individualservice management processes and functions, thedependencies, particularly between 'operations' and'development' but also between 'operations' and'administration' became clear. Not that thosedependencies were denied; in fact they had almostbecome peripheral to the argument because what hadassumed an overwhelming importance was thequestion of organisational control.

'The question is,' said Humpty Dumpty, 'which is to bemaster – that's all.'

And the fiercest battles centred around the question ofthe relationship with the directorate's customers. Thishad traditionally been the province of the softwaredevelopers and maintainers. Their past products wereafter all in a state of constant change, with some major




78

A set of fundamentalbeliefs

7.4 So, what happenednext?

services suffering a daily amendment cycle. Theirrelationship – sometimes with a precursor to theintelligent customer within the business areas served – wascomfortable, or well-established, or simply important totheir parochial needs and ambitions.

The problem with ITIL is that, while not a method to beslavishly followed in its application, it nevertheless hasto be treated as an entity. It has a single structure, asingle set of fundamental beliefs. And these are not to dowith its organisational implementation but with therelationship that should (must) exist between serviceprovider and service recipient. At its very heart, we cameto believe, were the following precepts:

♥ that responsibility and authority for delivering aservice must coexist

♥ that the only sensible view of a service was onethat encompassed every stage and activity of itslife, from conception to death.

'When I use a word,' Humpty Dumpty said in a ratherscornful tone, 'it means just what I choose it to mean –

neither more nor less.'

We also came to believe that the language of ITIL was animportant factor in establishing a commonunderstanding of how services should be managed butthat this created its own difficulties, particularly amongthose who had not the inclination (or opportunity) tolearn the language for themselves. So, the lesson welearned was that enthusiasm was vital for cohesionwithin the project and fine for the clients – theywelcomed being spoken to as customers – but that itmust be tempered when negotiating with other IT staff ifunnecessary conflict is to be avoided.

It is now the beginning of 1992. The directorate's eightmonth freeze on recruitment, imposed during 1991 whilesome departmental organisational changes took place, isover. Why it was thought necessary to interrupt aplanned reduction of staff numbers I'll never understand!

'... and your hair has become very white'.

Phase 2 of the project is underway. This involvespursuing a number of common activities for theestablishment of each ITIL function such as Problem




79

Management, Change Management, etc. Recognisingthat this was a substantial IT organisation butnevertheless understanding that one 'functional manager'does not necessarily equal one person, the common taskswere:

♣ appoint a functional manager

(Quite a lot of thought was given to who mightbest fit a function or number of functions, based onthe BCS Industry Structure Model, Release 2.However, some candidates who were considered'ideal' didn't want to do that particular job – andthere was not actually an infinite choice!)

♣ identify staff to be trained and arrange suitabletraining

(This was easier. All managerial staff (HEO andabove) attended ISEB accredited ServiceManagement training courses – mainly at the Civil

Service College. Some PRINCE® training also tookplace.)

♣ produce a Mission Statement and a definition ofthe rô1es, requirements and responsibilities of staff

(This turned out to be a much more substantialexercise than first envisaged and resulted in theproduction of a complete set of 'FunctionalDescriptions', covering every aspect of ServiceManagement. These are described later.)

♣ review the current processes, procedures and 'deskinstructions' and define detailed new managementand clerical procedures as well as any changedaccommodation and environmental requirements

(Much of this work had been completed during ageneric gap analysis and reporting exercise.)

♣ mount an awareness campaign

'I have answered three questions, and that is enough ...Do you think I can listen all day to such stuff?'

(This was something that we didn't manage at allwell. We were never quite sure what it was and inany case really didn't have – or thought we didn't




80

Other tasks

have – the resources or skills to do it properly. Thiswas a mistake! An awareness campaign, mountedfor the benefit of internal IT staff as well as for thecustomers would have been a golden opportunityto isolate the dissenters and force a reconciliationof views and objectives before we had progressedtoo far. The later interruptions to progress becauseof silly battles over 'what is a configuration itemand does a mouse have to be identifiedseparately?' or major battles over where theCustomer Account Manager sits might then havebeen avoided.)

♣ test tools and clerical procedures before bringingthe function into service

♣ introduce effective, timely and accuratemanagement reporting and plan for the function toevolve to meet changing business needs and forperiodic reviews of its efficiency and effectiveness.

(It had already been decided that information notrequired for decision making had no permanentvalue.)

In addition to these individual activities, there were anumber of general tasks. These were:

♦ carry out a procurement exercise to identify andprocure the most suitable software support tools

♦ buy the appropriate hardware to run them on

♦ monitor and manage the overall implementationof ITIL processes.

During this phase, one of the biggest problems was thatof balancing skilled and scarce staff resources. Inevitably,there turned out to be only a small number of keyplayers, at various levels in the organisation – the sort ofpeople that you rely on to keep things going as well as todevelop the new schemes.

Now, here, you see, it takes all the running you can do to keepin the same place. If you want to get somewhere else, you

must run at least twice as fast as that!

And the world did not stop turning, neither could thedepartment escape being involved in national 'exercises'.So the balance between the old and the new




81

7.5 And then came markettesting ...

shifted many times in favour of the old: that was, afterall, where our current customer commitments residedand, frustrating as it was for progress, it was clear whereour duty lay. The alternative approach of separating theold from the new entirely was never considered feasible.Too much was changing and we knew we had to takeaccount of, and learn from, the new in order to create astrong and flexible management framework for thefuture.

That need for flexibility was also unsettling for thoseinvolved. While they accepted that a new furrow wasbeing ploughed, their natural preference was for areasonable measure of stability. It was not alwayspossible to supply this, particularly in terms of theorganisational structure within the IT Services division,given that we were learning all the time. And of coursethere were still the management battles being fought.However, there were periods of relative peace!

'Let's fight till six, and then have dinner,' said Tweedledum.

I only took the regular course ... the different branches ofArithmetic – Ambition, Distraction, Uglification and

Derision.

Market testing, mainly because it was followed fairlyquickly by the directorate's move towards agency status,caused relatively little impact. In order to defusepotential internal arguments (which might have lead tofurther delay) we commissioned a short independentconsultancy study to ensure that nothing that was beingdone or planned in the infrastructure managementproject would conflict with the move towards markettesting. The report, delivered in February 1993,concluded that not only were there no conflicts betweenthe two objectives but that all the work now beingundertaken was a proper precursor to a successfulmarket testing project. It did, however, point out that,with the skills available, the infrastructure project targetdates were too ambitious and should be phased – partlyto demonstrate the tangible improvements alreadyaccomplished; and that the close association betweenITIL and ISO 9000 should be further explored.

The report also highlighted the progress made towardsdeveloping a service management strategy for thedirectorate as a whole.




82

Functionalspecifications

The spring and summer of 1993 were spent furtheringthat aim and producing one of the most important set ofdocuments to emerge from the project, which comprised

♠ the Functional Specifications

♠ the Catalogue of Customer Services

♠ the Standard Code of Practice (SCOP).

(This was the document designed to sit above theSLAs and contain all the non-service specificinformation customers would require.)

Discipline by discipline, the functional specificationsdescribed how the best practice guidance in ITILtranslated into terms meaningful to our organisation.They explained in straightforward language what thefunction was, who was involved and what its missionstatement was.

They then went on to set out, again in plain language.

♥ The objectives

(For the first time the task of those responsible forthe delivery and support of live services wasopenly described in great detail.)

♥ the functional boundaries and interfaces – not justIT but covering the whole of the organisation

(Of crucial importance, this emphasised thateveryone in the directorate had a rôle to play. Itsaid plainly that there were no internal boundariesthat were of the slightest interest to customers butit was nevertheless vital that all understood andaccepted their individual or collectiveresponsibilities.)

♥ the processes and procedures

(The functional specifications did not descend tothe 'desk instruction' level but set out all the mainprocedural components.)

♥ the parameters by which that function would bemeasured

(As well as introducing the concept of functionalefficiency and effectiveness reviews, this section,for the first time, started to describe the metricsthat would be collected and used to ensure that




83

Managing relationships

7.6 So, where did it allend?

the service management processes remained ontrack.)

♥ the skills and training required to carry out thefunction successfully.

(The skills described were based upon the BCSIndustry Structure Model – soon to be republishedin its third release. ISEB InfrastructureManagement: Service Management training wasmandatory for all middle managers and above –though not all chose to take the examinations. Hadit been available at the time, the ISEB/EXINService Management Foundation Certificate wouldalso have been a firm requirement for theremaining staff.)

The SCOP, again, proved to be something of abattleground for it aimed to describe the external servicesprovided by the three constituent parts of the directorateand the nature and extent of the relationships they hadwith their clients. Also, importantly, how thoserelationships were to be managed in the future. Thedirectorate had not before faced these issues and, likemost other organisations not under threat, it hadcomfortably continued in what it would have describedas a mature relationship with its users. From the outside,however, others saw it as old fashioned and ill-equippedto face the future. The SCOP provided the opportunity todiscuss these issues, to develop a commonunderstanding of through-life service management andto adopt a common approach. It was not entirelysuccessful in achieving that aim. Perhaps language alonecannot persuade.

"'Then you should say what you mean,' the March Hare wenton. 'I do,' Alice hastily replied; 'at least – at least I mean what

I say – that's the same thing you know.'"

"'Not the same thing a bit!' said the Hatter. 'Why, you mightjust as well say that 'I see what I eat' is the same thing as 'I eat

what I see!"

The answer, of course, is that a project such as I havedescribed never really ends, it simply turns into a cycleof continuous improvement. So, the best that can be doneis to describe what the project has achieved so far, andwhat it has not.




84

Change Managementand Software Controland Distribution

Problem Managementand the CustomerService Desk (CSD)


The aim was to create a centralised change managementprocess. This needed to embrace all parts of thedirectorate to be fully effective. Most of the resistancecame from the software project teams – and a fewcustomer sites. It was argued to be a bureaucraticbottleneck rather than an essential source of informationin the fight to reduce the number and severity of servicefailures – most of which arose from change. There arestill islands of resistance but the availability of goodmanagement information, including type, frequency andcost of changes, is turning the tide. A working ChangeAdvisory Board, however, has still not yet been set up.

Software release management has taken a step in theright direction with fewer unscheduled releases. Thisfunction has been closely allied with software technicalsupport.

Now working well, with excellent statistics beingproduced. An interim call logging system was createdlocally at the beginning of the project and proved to be amost valuable source of information and training.Among other things, it showed that it was unrealistic toaim for 90% of calls to be closed by CSD staff, 60% beingnearer the mark. The difference between incidents andproblems, and the need to separate their management, iswell understood. The interface with Customer AccountManagement – which was recognised to be intimatelyassociated with the CSD – continues to cause somedifficulty. There also continues to be a danger ofintelligent customer style clients not sharing 'their'service quality information, collected via their own 'HelpDesks'.

The data collection exercise proved to be most difficult.Issues of 'ownership' arose and insufficient authority wasvested, publicly, in those responsible for the creation ofthe CMDB. Some third party assistance was bought inand this helped. The phasing of data capture is importantsince there has to be a close link established andmaintained between Configuration Management andChange Management. The depth of data recording wasnot finally settled until it was pointed out that a box oftoner for a laser printer (which did not have a discreteserial number) was more valuable than a PC keyboard!The real overhead in Configuration Management is not,of course, in labelling the equipment but in managingfuture change.




85

Service LevelManagement andCustomer AccountManagement (CAM)

Cost Management

Capacity Management


From the start, the CAM rô1e failed to achieve theprofile, authority or recognition that it deserved andrequired, mainly because the directorate continued toconcentrate on the organisational, rather than functional,issues – who will control the CAMs and who will signthe SLAs rather than what is their purpose. In part, it wasalso due to the organisational culture of the governmentdepartment in question. Consequently, some of thedirectorate's customers still do not understand thedifference between a Service Level Requirement and aService Level Agreement and service management stillfails to be involved early enough in the service lifecycle.Other customers, however, have come to recognise thevaluable contribution that Customer Account Managerscan make and are now insisting on their presence duringdiscussions and negotiations with the softwaredevelopers. So, all in all, a much healthier state of affairsthan existed before and well-worn phrases like 'customerfocus' are beginning to ring true.

The first invoices have now been produced but, on theway, there have been a number of difficulties in ensuringthat all financial information is recorded in a compatibleformat and to a common structure. The lesson to belearned here is that financial management staff need tobe more fully involved from the beginning of such aproject – and take a much greater responsibility fordriving this aspect of service management. But, althoughit now seems obvious that everyone is, perhaps they didnot consider themselves then to be part of thedirectorate's service delivery mechanism, more just anecessary administrative control function! We did not, atthat time, tend to judge our worth on the contribution wemade to our business value chain.

With the use of modern UNIX-based software, thisfunction is now playing a full rôle in helping to predictthe future – as well as keeping an eye on currentperformance.

Perhaps too much emphasis initially was given to theinventorial aspects of the function, which is really morethe province of Configuration Management. They havestill to get to grips with issues of vendor quality and theprovision of useful management information on thereliability of components and services. However, this




86

7.7 Conclusion

function will no doubt mature as more SLAs come on-stream.

It was once said that, unlike a detective novel, where thetrick is to try and guess who did it, with ITIL you are leftwondering 'has anyone done it?'

Well, the answer is yes, and in spite of the emphasis inthis case study on what went wrong and why, thereality is that the project I have described can rightlyclaim to have been a success. It was a leading edgeinitiative with little in the way of previous practicalexperience to lean on. The statistics needed to prove itscase to the doubters within the family could only comefrom implementing the ITIL functions and it was in thisparticular respect that the ISEB training proved to besuch a boon.

Our decision not to implement service managementtools before writing and gaining general acceptance ofthe functional specifications was fundamental to thatsuccess. Apart from anything else, it allowed the viciouscircle of change/incident/problem to become widelyunderstood. That is not to play down the invaluablecontribution made by Ultracomp's Red Box software(our eventual choice) but to understand that theflexibility and power of such an integrated tool-set isboth its greatest asset and its greatest weakness, if notmanaged with care.

As may be discerned from the preceding paragraphs, themajority of the problems encountered were thoseconcerning internal IT relationships and, in the heat ofbattle, it was a pity that we in the project teamunderestimated the power of the customer to influenceour collective service management attitudes. Perhaps,next time, a customer survey should appear earlier in theactivity list!

There remains one more major goal to be achieved – ISO9000 certification. But such solid foundations have beenlaid that when that final project objective is reached, allwill know for sure that it is worth more than the paper it




87

is written on. And of course the move to agency statushas had a significant and beneficial impact upon theculture of the entire organisation. The competitive worldinto which the directorate has now moved demandedchange in exchange for opportunity and the challengehas been taken up.

Just then flew down a monstrous crow,As black as a tar-barrel;

Which frightened both the heroes so,They quite forgot their quarrel.




88




Service management implementation





Chater 8Service management implementation


91

8 Service management implementation

Section Page

8.1 Introduction 93

8.2 The way we were 93

8.3 Improving service to customers 93

8.4 The threat of CCT 94

8.5 The future 97

8.6 One final point – perception 98

This case study was provided byUltracomp Ltd




92





93

8 Service management implementation8.1 Introduction

8.2 The way we were

8.3 Improving service tocustomers

Four years ago, the departments at Stockton BoroughCouncil had low expectations of their IT department.Since the arrival of Graham Coe as IT manager, he hasworked with and expanded his team to create a serviceculture and raise the profile of IT among the council as awhole. This case study illustrates how Graham and his ITteam managed to achieve a complete transformation, andin the process, strengthen the in-house IT department'sposition against any competitive bids to do the job fromoutside suppliers and the part ITIL guidelines played inachieving this.

Up to 1988, Stockton Borough Council receivedcomputing services from Cleveland County Council, alarge user of IBM equipment. In 1988, the borough brokeaway from this arrangement and installed an ICLmainframe system, chosen because it ran a good portfolioof local government applications.

But by the time Graham Coe arrived as IT manager inNovember 1991, there was general level of dissatisfactionwith IT. His customers were in some instances having towait several minutes for responses on the system,requests for change were handled haphazardly, andamong the council in general 'there was totaldisillusionment with IT'.

The IT department had fourteen staff, including fivecomputer operators. 'The department was under-resourced and the machine (an ICL 3955) wasoverloaded,' says Graham Coe. 'There was no-long termplanning and the staff were constantly firefighting. Theynever had time to do anything properly.'

Fast action was required, and Graham immediatelyadvertised for eight new staff, in order, as he says, 'tobuy time, achieve some level of stability, and to addressthe customers' problems'. There were 300 applicants forthe eight jobs, and so he managed to take on the best andmost appropriate to his needs. All of them have stayedwith the council.

The net result of these actions was to create some goodwill among the rest of the council. 'The customers couldstart to see an immediate improvement. They started tounderstand what we were trying to do. They were not




94

8.4 The threat of CCT

as aggressive, even though the service was notmeasurably better yet. They could see little bits beingadded and improved.'

Having won approval from the council for a new way ofrunning IT, he upgraded the system to an ICL 3965 inJune 1992, and in late 1992, set about makingimprovements to the way the department ran its affairs.Graham had experience of installing costing andcharging systems, unattended operations and disasterrecovery, and he made these his first goals at Stockton. 'Itwas not a co-ordinated plan at the time. It was justcommon sense and gut feeling,' he admits, 'I knew Icould make an impact on this council without costingthem money. I could create a department that was leanand mean, while delivering the service, and all for£30,000 less a year.'

What turned this personal crusade into a more co-ordinated approach was a chance visit to a meeting of theUltracomp Scottish Users Group, where Graham heardsomeone talking about ITIL and accreditation to theInformation Systems Examinations Board (ISEB). 'I'dnever heard of it,' Graham admits, but among the titles ofthe books referred to by the speaker, he recognised manyof the ideas he had arrived at independently. 'I'd foundsomething I had been looking for but thought was notthere, a standard of work that could be accredited toshow what you can do.'

On returning to Stockton, he immediately sent two staffon Ultracomp's Service Management course to achievethe ISEB Certificate of Proficiency in IT InfrastructureManagement. Both were successful, and this also helpedto raise awareness of the benefits that could be gainedfrom introducing the appropriate working practicesdefined in the ITIL guidelines.

In early 1993, the in-house IT department had some'serious worries' about the threat of CompulsoryCompetitive Tendering (CCT). Stockton IT department isthe newest of the north-eastern authorities and as suchfelt it could be a target for outside bids. They weredetermined to pre-empt the threat, by taking adispassionate look at the service they were providing,finding the weaknesses and fixing them. 'As a team, wetook a strong look at ourselves and came up with aframework and a series of business plans. It wasn't




95

funny and it wasn't pleasant. But we identified all theweaknesses,' recalls Graham Coe.

The exercise also produced a report setting out howinformation is handled and how business unit planningis done, and this has now become the standard referencework for the council's newly created InformationSystems Steering Group. One of the areas that neededurgent action was the Help Desk, and the council lookedat a number of packages before settling on Red Box fromUltracomp. Those staff who had been on the ISEBtraining courses were well qualified to identify thefacilities and functionality required of an integratedservice management solution, and to test how well thepackage performed and how closely it conformed to theITIL guidelines. 'The need for an integrated servicemanagement toolkit was an afterthought,' says GrahamCoe, 'We had only looked at Help Desk in isolation up tothis point. Now we knew we needed to integrate otherdisciplines such as configuration management andchange management, which not many packages handledto ITIL conformance.'

The Help Desk went live in May 1994, followed byConfiguration Management – 'which is still not completeand never will be' – and then Change Management,which is now being implemented and expanded to covermore areas of activity.

On disaster recovery, a great deal of progress has beenmade, especially considering the council had norecovery plans when Graham Coe arrived. They havecompleted three successful tests now, but he still seesways of making the plan even more watertight.Therefore, by May 96, he intends that disaster recoverytests will be carried out entirely by an outsideorganisation. He makes the point that it is foolish to relytotally on anyone from inside the council to handle anypart of the plan: 'You need to able to plan for theunfortunate situation of your own staff not beingavailable following a disaster.' The whole thing will behandled and tested externally, as it should be – 'andthat isn't in the (ITIL) book', he observes.

This last piece of the disaster recovery plan could havebeen done this year, but the last test, monitored by anUltracomp consultant, showed twenty-four points thatneeded fixing. One of these was an apparently simple




96

Areas for improvement

point, that part of the recovery relied on having a VMEoperating system expert to hand. The IT team plan torewrite this part of the manual so that anyone can followit. Next time, they will make sure staff with no VMEexperience can handle that part of the recovery process.

ITIL has become the guiding light for the development ofservice management and the full set of books are to handfor regular reference. 'I believe that service managementas advocated by ITIL is the key to winning CCT. And Iwant to make sure I don't lose,' says Graham Coe. Forthis reason, last October he underwent an outsideassessment to test how his department was conformingto the ITIL guidelines. They were assessed by Ultracomp,whose Squares service is an objective measure ofperformance using a combination of ITIL guidelines andpractical experience as a benchmark.

The report identified a quantum leap in quality of servicebeing delivered to the customer, but it also identifiedsome areas for improvement. The assessment scored therelevance and performance of each activity out of 100,and some of the worst were as follows:

• 7 for Change Management

• 17 for Problem Management

• 25 for Capacity Management

• 20 for Service Level Management.

For example, under change management, the assessmentfound staff changing live code, not recording changes,and leaving no reversion path in case changes did notwork. There was also no consistent approach among thethree development teams and technical support team,each of whom would handle requests differently. Inoverall terms, the assessment made seventy-fiverecommendations for how to improve the service, eachgiven a 1, 2 or 3 priority.

For each recommendation, the IT team then had todecide:

• do we accept it?

• who owns it?

• is it IT's responsibility?




97

8.5 The future

For instance, business recovery is a corporate issue, andso has been moved under the control of the InformationSystems Steering Group. Other issues, such as thekeeping of terminal downtime statistics, which wasraised in the Squares report, have been passed to thenewly formed Customer Care Group, made up of ITpeople and customers. 'Because not all customers requirethe same level of information, I can't dictate they shallhave terminal downtime statistics. If they want it, we'llprovide it,' says Graham Coe.

The remaining recommendations were broken down intotwo categories:

• an action item – that can be done in a day or two,and does not need a plan

• a planning item – with a set number of activitiesover a given period of time, under changemanagement control.

The master plan to attack those issues has now beenproduced, and the IT team will be concentrating theirefforts on the worst score areas. In those areas wherethey achieved high scores, such as unattended operationswith 72%, they realise that directing resources to getcloser to 100% would be less effective.

The immediate future will be taken up in implementingSquares recommendations and going through another'mini-Squares' assessment to see how far they haveprogressed against agreed service improvement targets.One measure of success is seen in the PC support area,where the team has just been increased from one to twopeople to support a population of 230 PCs.

ITIL highlights that IT departments can become victimsof their own success, and this is something the team atStockton have experienced at first hand. Before thesecond person arrived (paid for by the userdepartments), the number of outstanding calls stood ataround seventy. 'Logic says that those calls will godown,' says Graham Coe. But the opposite hashappened. The Help Desk is used more, the number ofoutstanding calls now averages 100-plus, and he isfeeling the need to increase the Help Desk staff further.

The success of the Help Desk operation has opened upnew opportunities in the rest of the council and Red Boxis going to be used more widely as a general complaints




98

8.6 One final point –perception

handling/service request system. Now, when someonecalls to complain about the dustbins or the schools, thecomplaint will be logged in the Red Box system andescalated until it is resolved and answered. As GrahamCoe says: 'Local government these days is aboutcustomer service.' The use of ITIL– and a good measureof common sense – has helped Stockton turn whatseemed to be a helpless situation to one where IT isrespected and valued as force for good in the council.

Graham Coe knows that once he has fully implementedthe ITIL principles as recommended in the Squaresassessment, customer care will inevitably improve. Butas he says, there is just one more ingredient to success,and that is how the service is perceived. The involvementof other parts of the council in the Information SystemsSteering Group and Customer Care Group plays a part ingetting the message across, but he has supplemented thiswith regular IT awareness days to raise the department'sprofile and regular presentations on public platforms.

This marketing is having an effect. He is constantlyplaying host to other councils who want to see howStockton are managing their affairs. This enhances thereputation of the council as a whole and hopefully willcause FM companies to look elsewhere for their business.As Graham Coe says: 'Stockton has had enough kicks inthe past – now it is time for some credit marks. And thecouncillors like kudos, they like pats on the back, as dothe staff involved in delivering the service. When theyhear that other councils, much larger than us, now visitto see how we do things, then that increases the feel goodfactor.'

'From an IT viewpoint, ITIL has helped generate a lean,mean service environment focused on delivering acompetitive service. Obviously the advent of CCT hasbeen a motivating factor, but it goes beyond just winningthe contract. It is about having everyone, regardless ofjob position, working together and being obsessed withproviding a service second to none.' The greatest benefitof following the ITIL guidelines for service managementis that the IT department's 'users' – viewed previouslywith distrust and irritation – have now become'customers' working in conjunction with the IT team todeliver an efficient and consistent level of service to thecommunity



Disaster recovery planning





Chapter 9Disaster recovery planning


101

9 Disaster recovery planning

Section Page

9.1 Introduction 103

9.2 The need for a Contingency Plan 103

9.3 Business continuity 104

9.4 Testing the Plan 106

9.5 Future plans 107

9.6 The verdict on ITIL 108

This case study was provided byUltracomp Ltd




102





103

9 Disaster recovery planning9.1 Introduction

9.2 The need for aContingency Plan

If it has ever been true that local government was asleepy backwater, that is certainly not the case now.Local authorities work to tight budgets, and individualdepartments must be prepared to brave the rigours ofcompulsory competitive tendering. They are fighting fortheir lives. Central to achieving many of these goals is theneed to have efficient information systems for themanagement of local government finances. But greaterreliance on computers begs the obvious question: whatdo you do when they go wrong? Four years ago StAlbans District Council set about tackling the problem,and began laying the foundations of a contingency planwhich could ensure that, whatever happened, theCouncil would be able to continue to do its workeffectively and serve the community.

Four years ago, St Albans District Council had onlyrecently installed its own ICL mainframe systems, havingpreviously been served by a consortium withneighbouring Watford Borough Council.

The Council placed a high priority on disaster recovery,especially given the growing pressure on localgovernment to perform like a business and the need tocollect the new Community Charge (the so-called 'PollTax'). In addition, the need for a contingency plan washighlighted further by two terrorist incidents in StAlbans close to the Council's offices. Martin Ferguson, ITManager at St Albans, recalls that the Council carried outa simple business impact analysis across all departmentsof the Council to assess how each department would beaffected by a loss of systems. 'You can go to all sorts oflengths with this impact analysis. Essentially, ours wasvery simple, looking at each of the main applications onthe mainframe and then discussing with the users thepractical requirements of each of these applications,prioritising them and determining what sort of back-upthey needed in terms of hot and cold start, or simplymanual alternatives.'

Since all the main financial systems resided on themainframe system, it made sense to provide immediateback-up by making arrangements with both hot-start andcold-start suppliers of mainframe services. Hot-startsuppliers specialise in making a system immediately




104

9.3 Business continuity

available to carry out urgent jobs while the customer'sown system is temporarily out of service; cold startsuppliers cater for the more serious long-termbreakdown (such as the loss of a building), where areplacement machine may have to be supplied for aperiod of time, possibly in a temporary computer room.St Albans initially evaluated the Hot Start options andfound three possible suppliers.

Price was naturally a factor in choosing the services, butMartin Ferguson was eager to choose a company thatwould work well with his own staff, particularly in thestressful situation of a disaster. 'We wanted the staff tofeel comfortable with the whole environment and theprocedures they had to follow to recover systems. Weinvolved a lot of our staff in selecting our supplier.' Theymade a short list of two, and asked them to do a dry-runexercise to see how they coped with taking Council filesand running them on their own machines.

The tests were quite conclusive and as a result ACT waschosen as the hot-start supplier. In addition, Comdiscowas chosen as the cold-start supplier for the provision oflonger-term cover.

But as Martin Ferguson concedes, replacing themainframe is 'a fairly minimalist view of disasterrecovery planning'. You have to move on intocontingency planning, looking at the wider issues of anorganisation and the services it provides. The approachup to that point had been pragmatic and geared toputting in the basic back-up the Council would need ifthe mainframe stopped. 'Politically, we felt this was apriority,' says Martin Ferguson. So once the hot- andcold-start facilities had been put in place, St Albansstarted working closely with the software andconsultancy company Ultracomp to put together a morecomplete business continuity plan. Ultracomp consultantVernon Lloyd, who worked with them during thatperiod, takes up the story: 'We began by using theproforma plan straight from the ITIL book, and filled inthe blanks for the specific site.'

'The ITIL guide to disaster recovery', he says, 'acted as anexcellent reference list of everything that needed to becovered, from listing the telephone numbers of everyonewho would need to contacted in an




105

Coverage

emergency, and who would be responsible for what, tothe relevant insurance requirements.'

'As the plan evolved, it became more of a workingdocument,' says Vernon Lloyd. The document developedto fit the specific requirements of St Albans, and grewaway from the original proforma document. 'It made avery good starting point for writing a plan, but it is onlymeant as a guideline,' he says.

The current plan defines everything that needs to bedone for each level of emergency, escalating responseaccording to the seriousness of the problem. MartinFerguson is the owner of the plan and is ultimatelyresponsible for its effectiveness. But as part of their on-site duties Ultracomp manage the plan, and ensure that ifany changes occur (even someone's home telephonenumber), the master plan is updated and new sheets aresent out to each holder of a copy so that their copies areright up to date.

The main areas covered by the plan are:

• the business requirements for disaster recovery

• the essential services covered by the plan, withtheir recovery priority ratings

• the contingency planning team members, and theirduties

• a list of all the names (of both individuals andorganisations) with their telephone numbers andaddresses

• a description for disaster detection and impactassessment up to the point of invoking the plan

• a detailed description of the disaster recoveryprocedures, including return to the originallocation after the emergency is over

• guidelines on salvaging equipment from thedisaster site and arranging cleaning and repair,with details of possible contractors

• all insurance policy details

• procedures to adopt following failure of airconditioning or power supplies




106

9.4 Testing the plan

• procedures to follow whenever changes occur thatcould affect the contingency plan.

An essential prerequisite of any plan is that it should betested regularly. St Albans tests its own plan annually,with Ultracomp acting as an independent assessor todocument any shortcomings in the plan, or to recordwhere the plan is not followed. If the mainframe systemis brought to a halt, the back-up files kept in fireproofsafes at a central depot two miles away are transportedto the ACT site in Portsmouth. Provided the Councilbuildings are useable, the staff can access the ACTmachine from their terminals and PCs, as they wouldnormally. In the event of a major disaster affecting theoffices, then the staff would move to a central depotwhere there is ample office space. There is also someprovision for staff to take over desk space in Portsmouth,although this would be kept to a minimum.

In the tests, the IT team has tried to be as realistic aspossible, but has not gone as far as shutting down themain systems completely while the contingencyprocedure kicks into action. 'The annual test is currentlyfocused on the mainframe. We learnt a lot from our earlyannual tests and always have a debriefing session toidentify what needs to be done to improve the plan,' saysFerguson.

The tests have always worked, although they havealways thrown up problems to be ironed out, asFerguson recalls: 'One early problem that we identifiedwas that our low speed link to Portsmouth was not goodenough and we have since installed an ISDN2 link at thecentral depot to speed up communication betweenPortsmouth and St Albans.' Some work has also beendone to ensure that the Finance Department's plansdovetail with those of the IT department. 'We tightenedup a lot of the tape handling routines for our Unixsystems and also the whole area of PC back-up wasimproved at both ends,' says Ferguson.

With the Unix systems the departmental link officersload the tapes and take them to the off-site depot. PCsare the responsibility of the user to ensure they haveadequate back-up, and they have the service of a tapestreamer back-up device. 'Depending on how criticaltheir systems are they will back-up more or lessfrequently. At the moment we allow them to decide but




107

9.5 Future plans

that could change further down the track if we get intonetworked PCs.'

Martin Ferguson strongly favours the notion of theintelligent customer – the capability within the business forworking with the IT department to set the direction forthe use of IS and IT rather than the passive reception ofservices. He says: 'It changes the role of the IT functionfrom purely providing a kind of technical solution tobeing a facilitator and enabler, working with andeducating the customer. As time goes on the complexityof the requirement increases as you start to build in a lotof other issues such as the culture of the organisation,internal procedures of departments, and the way theservices are delivered. That way we can start to expandout from focusing purely on the mainframe to officesystems generally, whether they happen to be onmainframe or distributed systems – or manual systemsfor that matter. And that's when life starts to get quiteinteresting.'

This wider thinking makes the whole organisation moreaware of contingency planning, and in St Albans case,has prompted the extension of information systems intonew arenas.

Martin Ferguson again: 'You realise the importance ofdocument image systems and geographic informationsystems (GIS). At the moment, all our maps are kept inhard copy on the first floor and that's it, no back-upwhatsoever. It's the same with microfiche where we havejust one copy in the offices somewhere. The same goesfor historical records. There is no back-up. Withdocument image systems and GIS we can have off-siteback-up with files locked away in fireproof safes.'

The process that started off as mainframe back-up, hastherefore spread its boundaries to all areas of theCouncil. 'We have raised the level of awareness andunderstanding about the need for contingency planningwithin the authority as a whole and we have acommitment to it now across the authority,' saysFerguson. But he is also realistic: 'Getting commitmentturned into action is another matter. The approach weare adopting is to bite off a bit at a time. We started in theFinance Department – they have their own contingencyplan now for their accounting and financial services andthey now have one for their revenue's side




108

9.6 The verdict on ITIL

of the business. We are in the process of looking for thenext bit to bite off. We shall gradually build up a jigsawof plans to cover the whole authority. The other issuethat arises then is to pull them all together corporately.'

All parties agree the ITIL guidelines made an excellentpoint of departure for mapping out a business continuityplan. But Martin Ferguson's view is: 'The frameworkprovided by the ITIL guidelines served the purpose ofdirecting our thinking into all the various technical andnon-technical areas of contingency planning. We thenoverlaid this on our own site-specific requirements toensure the completeness of the plan.'



ITIL support for IT service quality improvement





Chapter 10ITIL support for IT service quality improvement


111

10 ITIL support for IT service quality improvement

Section Page

10.1 Just books and bureaucracy 113

10.2 The company 113

10.3 ... but why change the basic way of working? 114

10.4 Did ITIL seem like a good bet? 115

10.5 So, before we started ... 115

10.6 IPW 118

10.7 Production 119

10.8 A place for everything ... 120

10.9 The first implementation 121

10.10 Lessons about restructuring 121

10.11 Checking the results 122

10.12 The morning after 122

10.13 The final hurdle 123

10.14 Conclusions 125

This case study was provided byThe Quint Wellington Redwood Group




112





113

10 ITIL support for IT service quality improvementRules are for the guidance of wise

men and the obedience of fools.

The truth is rarely pure, and never simple.Oscar Wilde

10.1 Just books andbureaucracy

10.2 The company

ITIL, IPW and ISO 9000 are recognised means ofimproving an IT Services organisation. But do they justrepresent a lot of books, a lot of bureaucratic rules andprocedures, a lot of work – work that is of no immediatevalue to the customer? Can they really lead to higherservice quality?

We think they can, but only indirectly. ITIL, IPW and ISO9000 are the means of creating a structure for workingpractices; a structure that is consistent and effective, onethat ensures strong organisational direction and reducesthe possibility of getting sidetracked.

But the structure itself is not a service qualityimprovement, it is only a framework for qualityimprovement. Nevertheless, the expectations of ITIL inthis respect continue to be high. Sometimes too high.

This case study is the story of what we believe to be thelargest ITIL implementation in the world, why we did itand what we have learned.

The subject of this case study is a majortelecommunications company. It has one of the largest ITdepartments in the country and their main goal is toprovide information services to all of the differentbusiness units within the company as well as dealingwith the underlying technical aspects of businessautomation. The company is divided into businessoriented units. These are in turn divided into a numberof widely spread 'working units' and some central staffunits responsible for deciding how the business shouldbe run and what products are to be sold.

The IT department supports all these functions and isitself divided into five branches, each responsible formanaging a different IT platform. There are four maincomputing centres, one for IBM mainframes, one forDigital, one for Unisys and HP and one for Tandemarchitectures. There is also a centre, called the End User




114

10.3 ... but why change thebasic way of working?

Service Department, that services the LANs/WANs andthe Office Automation customers. Each of these centressupports a different aspect of the company's corebusiness. In 1992, more than 2000 people were workingin IT departments and the total number of customers wasin excess of 30,000. When the company decided to useITIL as the basis for its organisational improvements itwas, without doubt, the biggest project of its kind in theworld.

As competition gets tougher, the demands placed on theIT department get stronger. In this case, the directmessage from the company was: provide a better qualityof service and handle more work with the same or afewer number of people or ...

This caused some of the IT managers to start searchingfor solutions to the problems they now faced. Thedemand was for more throughput, better predictions,higher overall quality, wider responsibilities, greaterflexibility – but everything against a need to reduce costs.

The manager of the Digital site searched for methods todeal with the data centre problem. He came across lotsof models and methods for software development,project management etc, but nothing dealing with theentire service lifecycle. It might have been easy at thatstage to argue that his service centre was unique, thatthere was a good case for going his own way, that thedifferent technology and culture of his departmentjustified this. Then he came across ITIL. His firstreaction was, I could have thought of this myself, but Ihaven't had to, so it is good.

The fundamental questions that ITIL was going to haveto solve were:

• Could we build a structure in our service centresthat allowed room for flexibility?

• Could we improve the quality of our work, not byinvolving more people in extra checks but byembedding quality into the natural workflow?

• Could we operate, survive and be successful in acompetition-oriented world, against market-oriented prices?




115

10.4 Did ITIL seem like agood bet?

10.5 So, before westarted ...

• Were we capable of managing this new type oforganisation, now and in the future?

In the first place ITIL was chosen because there was noreal alternative. ITIL was attractive because it waspragmatic and because it contained a lot of supportingdetail for the practical implementation of the variousService Management functions.

But there were also a lot of volumes! Clearly it wasunrealistic to expect everyone to read the books, hopethat they would do what was in them and then expect asuccessful outcome. What was missing was an overallview of the processes that needed to be managed. Yet itwas obvious that was going to be necessary to implementITIL in a highly controlled and structured manner – inthe same way in which any major organisational changeshould be managed.

The lesson learned from earlier ITIL experiences andfrom other companies was that it is impossible toimplement ITIL as though one were implementingEncyclopaedia Britannica. What was required was amodel, against which we could examine the mostimportant functions in IT, those which were expensive inpeople and specialist skills. But we did not want to makethe same mistake that a lot of IT companies had made bystarting with talking about ITIL and the organisationalstructure to support it. We knew that would end up inendless discussions about functions and responsibilities,about who rather than what. We therefore decided totake the approach of defining the most important ITprocesses that supported the overall quality of theservices. But even before we talked about the processes,we thought about how and in what steps the projectshould be managed. We chose the followingimplementation strategy model.




116

Figure 10.1: Implementation strategy model

This simple structure defines the steps that we followedin order to ensure the successful completion of our ITorganisational improvement project. It was preceded byan analysis phase where, by questionnaire and othertechniques, we established the existing ServiceManagement baseline. The first three steps then becameknown as the 'unfreeze' phase, the next four the'reconfigure' phase and the final step the 'refreeze' phase.

We already knew that implementing ServiceManagement was not simply the implementation of anumber of sets of procedures but the implementation of acomplex set of interdependent processes. Because of




117

Quality improvement:the IPW model

this it was very important to recognise that theimplementation of Service Management would requirechanges in working methods, changes in culture and,eventually, changes in organisational structure. Each ofthese would require a good deal of attention but theorder in which we dealt with them was crucial. But howto define a generic process model that could be used toimprove the quality of all of the services?

Figure 10.2: The quality circle

Since quality models are very well known inmanufacturing we went to see how they did it. It seemedthat the most important concern in a factory was thecontinuity of quality improvement. In order to guaranteequality it needed to be designed into the day-to-dayproduction cycle. For this they used the quality circle,then designed working processes which supported thatquality circle. After careful examination, we concludedthat we could not define our processes directly with theuse of ITIL. We recognised that ITIL would provide agreat deal of help at the procedure and work instructionlevels but it said little about the processes in combinationwith a quality model. So before we progressed furtherand in order to secure a generic working model, we hadto define the ITIL processes within a quality circle. Whatemerged from that work was the beginning of theprocess model which became known as IPW(Implementation of Process-oriented Workflow).




118

10.6 IPW

Figure 10.3: IPW process model

IPW is the standardised implementation of the ITILprocesses. It deals with every aspect of IT ServiceManagement, the processes, procedures, tasks, functionalresponsibilities, documentation, organisational concernsand support tools.

In its full form, it encompasses the complete range ofService Support and Delivery functions as well assoftware development, customer account managementand the production environment – and contains all of therequired data links. However, the simplified IPW processmodel with which we started to map out the processes ofProduction, Incident Management, ProblemManagement and Change looked like this:

The strength of IPW is that it translates ITIL from thebooks to the real life working situation. You cannot readIPW, you can only do it.

The major problem in many IT organisations is lack ofclarity. Everyone seems to be involved in everything. Yetwhen things go wrong, it is always so difficult to pindown the responsibility for putting them right again. Themajority of IT staff are dealing with incidents andchanges and many will have direct contact with the




119

10.7 Production

customers. Staff are usually technically well-groundedand motivated but none are able to attach an accuraterelative priority, either to their firefighting duties or totheir routine work. And seldom do they learn fromothers during the careful process of passing the refusebin on to next door.

What was so important about ITIL and the IPW model inthis project was that they made individuals aware oftheir rôle in the different processes, free from concernsabout company organisational structure. Also, where oneprocess stopped, its output became the input for the nextprocess so it was clear what the input and outputboundaries and expectations were. IPW clarified thecontact points and moments between the IT staff and thecustomers; working and thinking in processes brokedown the walls between departments – walls which hadexisted for as long as anyone could remember.

Production is the process that gets carried out whennothing happens to disturb it! Of course it is the singleprocess that provides benefit to the customer; provideswhat has been asked for; maybe even provides what isdescribed in a Service Level Agreement. If the systemsare available, the customer can log in, enter data,manipulate stored information, reach conclusions, makeinformed decisions, produce a printout, etc. However ...

... the production process is constantly threatened withthings going wrong. And it is at that point that incidentmanagement starts.

Incident management deals with every kind of serviceinterruption. Interruptions varying from a simple,forgotten password, up to the total loss of an informationsystem network. Our first goal was to minimise theimpact of the incident on customers by restoring theservice as soon as possible, or at least giving them a goodworkaround. Incident solving was something that wewere good at. After all, we were always doing it. We didit over and over again, hardly seeming to learn from ourmistakes.

We therefore needed a form of problem solving thatremoved, once and for all, the root causes of repetitiveincidents. Problem Management does this. Lookingthrough the incident database we started to findincidents with similar symptoms, or configuration itemsthat seemed to give rise to more than their fair share of




120

10.8 A place foreverything ...

incidents or customer groups who appeared to besuffering more than an average number of failures. It didnot take long to find the weak spots in our ITinfrastructure environment. Problem Management thenhelped to define the solutions.

A second aspect that constantly threatens the productionprocess is change. We were trying to improve the qualityof the infrastructure all the time, suppliers launched theirnew versions of hardware and software – often it seemedbefore full use had been made of the old ones – andcustomers needed new applications, improvedfunctionality and everything faster than before. FormalChange Management gave us a tremendous opportunityto keep that constant flow of changes controlled; toimplement them in the right order, after proper analysisand planning, with clear communication between all theparties involved and, finally, at the lowest possible riskof production failure.

However, we knew that none of this would runautomatically. Everyone had to have their place in eachof these processes. We therefore described the processesin outline so that there was no uncertainty as to wherethe process boundaries lay. We then divided them intosmaller and smaller steps. First we devised theaccompanying procedures, describing whichdepartments were involved at what point in theprocedure, who was responsible, who was actuallycarrying out that procedure and who had to be keptinformed. Then how the output of one set of tasks was toprovide the input for the next one. At the end of thisstage, we had described the 200 or so activities thatneeded to be carried out in the service centre.

Then we re-grouped those activities into logical units(tasks). Management activities, such as progress control,quality control and reporting we grouped into variousmanagers' functions. And, to ensure that the boundariesremained clear within the organisation, we called themIncident Manager, Problem Manager and ChangeManager, each of them ultimately responsible for themanagement of that process though not necessarilymanaging all of the resources being utilised.

The activities that dealt with capacity planning and theengaging and controlling of people were grouped intodepartment managers' functions. And so we created




121


10.9 The firstimplementation

10.10 Lessons aboutrestructuring

each of the functions in turn, ensuring that every definedprocess, procedure and task was placed in one or morefunctions, and if in more than one, that the boundaries ofresponsibility were kept crystal clear.

After we had developed the IPW process model it waseasy to build procedures and work instructions with thehelp of the ITIL books. What we had learned from ourdiscussions about the model was that ConfigurationManagement is not the first function you should beconcerned about. From just reading the ITIL modules itseems that you can not do anything withoutConfiguration Management. However, we decided totackle Configuration Management last, after we hadsubstantially completed our work on the main ServiceSupport processes. In that way, we would not have toface the risk of drowning in Configuration Managementdata before producing something really useful to the ITServices organisation. We could not avoid some of theConfiguration Management connotations of the IPWprocesses but we did not suffer from the commonmistake of appearing to be filling in ConfigurationManagement data for its own sake and then struggling tomaintain its validity.

After a lot of discussions about the IPW model we haddecided that its great value lay in allowing us to clarifythe true rôle of the IT Infrastructure Library, that is atthe procedure and work instruction level. We thenstarted to build a company quality model that lookedlike that shown overleaf.

Figure 10.4: company quality model

To implement this corporate quality model we had torestructure the way many of our IT employees worked.To achieve this we thought that we had only to arrange




122

10.11 Checking the results

10.12 The morning after

a few workshops. After a couple of weeks it becameapparent that more regular workshops were needed and,when the final score was counted we found that we hadcarried out more than sixty. Looking back, it is clear thatit was these workshops that did the trick. We havelearned that implementing these models is only possibleif you are able to change the culture of working.Managing the project in a way that recognised andsupported that culture change saved the implementation.Within eleven months we had a restructured Digital DataCentre which employed service oriented work methodsinstead the old functional and hierarchic approach.

Because the company wanted to check how well this newway of working was implemented and measure theresults, the management of the IT department arrangedfor an external audit of the project to be carried out. Todo this, they brought in the quality experts from DetNorske Veritas. The results were astounding. By usingITIL as a means of achieving high quality and stableprocedures and desk instructions within an IPW processmodel that itself contributed to a quality circle, theoverall score recorded by Det Norske Veritas was 72% onthe ISO 9002 scale. It seemed that without knowing muchabout ISO 9000 we had invented a quality system for IT,based on ITIL.

When published, the audit report created a hugemotivational peak within the company, and because ofthe degree of ISO compliance resulting from use of theIPW model, the company's management decided tointroduce identical projects into all the other data centres.After a year, every data centre was well on the way toimplementing Service Management based on ITIL. Theprojects were relatively problem-free until ...

... it became noticeable that there were problems with theintegration of the services from different data centres.Individually, Change and Problem Management wereworking well but there was no co-ordination or flow ofinformation between sites. However, as time went onmore and more desk-level applications were using thebackground applications and these were run at differentdata centres, each of which had their own particulardirect clients as well as this more general responsibility.Carrying out Change Management, for example, on thegeneral use hardware and software




123

10.13 The final hurdle

posed a number of new problems. One of these was thatthe background applications had their own direct userswith their own service level expectations. So who ownedthe application, who paid for the application and whowas to be given priority? To overcome these problems itwas decided that there should be a new range of ServiceLevel Agreements and a new way of working betweenthe data centres.

Another problem arose from the introduction of ISO9002 in that it created a tendency towards bureaucracy.More and more people were saying 'today I have toconcentrate on ISO 9002, tomorrow I go back to work'.People saw the introduction of ISO 9002, combined withIPW and ITIL, as work in its own right, losing sight oftheir real day-to-day jobs. This way of thinking becameeven more pervasive after the introduction of theQuality and Procedure Handbooks. The mistake thatwas made was letting the central staff specialists writethese books instead of asking the people whose day-to-day job it was. The tendency of the 'specialists' is torecord everything on paper and we therefore ended upwith books of more than 200 pages. It was being saidthat you could even hire a monkey to do the work,providing he or she could read!

Happily this was recognised in the project before toomany resources had been wasted and that particularapproach was stopped. The Quality and ProcedureHandbooks then became much slimmer and staffrecognised that they were working within a qualitysystem, not on one.

By this time, only one of the IT departments had not yetmade the leap and the final goal of the project was toimplement Service Management, with IPW as its processmodel, for the End User Service Department.

This department was huge; some 15,000 terminals or PCsand about 120 LANs spread across 17 different locations.Its size and complexity always represented the majorhurdle we would, eventually, have to overcome.Introducing formal Service Management into adecentralised department has to be done very carefully,particularly so if there is no single centre of executivecontrol. Added to which, there was the problem thatmost of the end user IT services originated from one orother of the technical data centres and were




124

The franchise approach

being delivered through a complex web of client/serverfacilities. Clearly the implementation of full ServiceManagement within this department was only going tobe possible with top corporate managementcommitment. We knew enough at that stage to realisethat attempting to deliver a service of that plannedquality without controlling processes underlying theservice was a waste of time.

However, no further organisational changes were to bepermitted, so for the first time, we had to deal withService Management staff who were not 'ours'. Welooked around to see how other organisations tackledthis problem and concentrated our research on two,McDonalds and the Post Office. What was particularlyinteresting about each of these was that they had basedtheir internal control mechanisms upon the franchiseconcept. With a franchise, the central control mechanismshave to ensure corporate quality while not owning thelocal means of delivery. This is managed, not through amass of detailed contracts, but through the agreementand issuing of service formulae, formulae that mightgovern how a customer is to be greeted, how to deal withcomplaints, how to sell a telephone, what onions or other'service components' to buy, etc. In this way, the centre isable to influence, effectively control, the manner in whichthe service is delivered without having to be 'in charge'of the people concerned.

We were not a franchised organisation of course but weset up a formula section and, with the end userdepartments, constructed a set of organisational rulesand procedures that would serve exactly the samepurpose. This section effectively designed the way theservice was to be delivered in each of the seventeen otherdepartments.

In order for those seventeen sites to carry out their localService Management responsibilities to a commonstandard, a great deal of time had to be spent oncommunication and training. Each of the local Problem(which included incident) Management and ChangeManagement cells were integrated into the corporateProblem and Change Management process and over-arching Problem and Change Advisory Boards were setup. Each of these was chaired by the Change/ProblemManager in the central End User Service Department andall of the seventeen 'free-standing' Change/Problem




125

10.14 Conclusions

Management functions were represented. Naturally, onlyproblems or changes with corporate wide implicationswere discussed. We were certainly not in the business ofbureaucracy for bureaucracy's sake!

The project problems that were met and overcome in thatfinal phase, were mainly those concerned with humanrelationships; organising how the people in thedecentralised units could be managed both by their localline manager and by their centralised 'process' manager.It was in ITIL and IPW's approach to ensuring clearfunctional boundaries that the solutions were found. Itdid not stop the occasional clash of priorities of coursebut the proof of the pudding is that a successful practicalsolution was found.

After just over two and a half years the project wascompleted successfully. All central and local IT staff hadbecome process driven and responsibilities and taskswithin the company had been made very clear. Morework was being carried out with fewer people and,importantly, because of the separation of process fromorganisational structure, future organisational changecould take place without fundamentally affecting theway IT services were delivered. And finally, although ithad not been one of the original objectives, the projecthad allowed all five data centres to achieve ISO 9002certification.

This only happened because of the skill of the peopleinvolved and the recognition by the IT managers thatimplementing Service Management is more thanimplementing ITIL.

On an occasion of this kind, it becomes more than a moralduty to speak one's mind. It becomes a pleasure

Oscar WildeThe Importance of Being Earnest

IPW is a trademark of the Quint Wellington Redwood Group and PTTTelecom Automation




126



An introduction to case studies in Chapters 11 and 12


127

An introduction to case studies in Chapters 11 and 12

The final two cases, in which ITIL and PROLIN form themain theme, come from the Netherlands. Both cases concernlarge-scale organisations responsible for the implementationof social legislation. Both have opted for the ITIL approachcombined with the Pro/Helpdesk system and tools suppliedby PROLIN. The main difference between them is theirhistory. One (the GAK – the Dutch Industrial InsuranceAdministration Office) has been using ITIL for some timeand added the PROLIN tools along the way. This case studyat GAK focuses on measuring the advantages of ITIL. Theother (the Detam – Dutch Industrial Insurance Board for theRetail Trade and Tradespeople), started with PROLINPro/Helpdesk modules and came into contact with ITIL as aresult. Pro/Helpdesk is entirely ITIL-oriented and isextended as ITIL is further developed. The Detam casestudy mostly concentrates on the justification andimplication of support tools.




128




Justifying and implementing support tools for ITIL





Chapter 11Justifying and implementing support tools for ITIL


131

11 Justifying and implementing support toolsfor ITIL

Section Page


11.2 Where we started from 133

11.3 Justification: processes of change 133

11.4 Orientation: where we wanted to be 134

11.5 Implementation: how we got there 135


11.7 Where we go from here: on the trail of ITIL 136

11.8 Users become customers 137

This case study was provided byPROLIN




132





133

11 Justifying and implementing support toolsfor ITIL

11.1 Introduction

11.2 Where we started from

11.3 Justification: processesof change

Information Technology and Automation (I&A)departments are hardly ever static. Technologicaldevelopments are too fast and furious for them to standstill. Sometimes, political and market developmentsexacerbate the demand for IT specialists in the I&Adepartment to be flexible. At times like that, ITIL can bevery useful.

Peter Reitsma has worked at the Detam for eighteenyears. The first fifteen years were fairly quiet. Under theterms of social legislation, retailers and trades people andtheir employees were simply affiliated with the Detam;there was no alternative, and everyone within the Detamemployed the services provided by its own computingcentre. There was no need to change this situation. Theresult was a somewhat static enterprise -call it an 'oldstyle' quango – in which everyone was sure of their jobs(unless they made a real mess of things) everythingfollowed tried and tested procedures and, moreover, theautomation department decided what was good for the'users'. In the last three years that Peter Reitsma has beenat the Detam, this situation has changed dramatically.

Let us sum up a few radical changes that have alreadytaken place or are currently underway.

• The traditional mainframe environment is rapidlymaking way for client/server and PC LAN/WANstructures. There is a fair chance that the Detamwill not have a single mainframe left in a fewyear's time.

• The Detam employs some 2,600 people (in overthirty branch offices) and has even more PCs andterminals, all of which are regularly required tomove.

• Nowadays, politics and the market expect theindustrial insurance board to make even more ofan effort. It is no longer an established fact thatcustomers traditionally affiliated with the Detamremain so for years on end. They are now free tochoose.




134

11.4 Orientation: where wewanted to be

• The Detam organisation itself is being divided intomore or less autonomous business units, each withits own target.

• The I&A department is certainly part of this trendand will have a few years at the most to establishitself as a competitive supplier of IT services. Thedepartment's budget is already being cut if it failsto achieve set expectations. The other Detam unitswill soon be free to buy their IT services elsewhere.

• And to make things even more complicated; thereis a declaration of intent on the table for a mergerbetween Detam and a fellow industrial insuranceboard of almost the same size, the BVG. If thisdeclaration actually goes through, two highlydivergent worlds of I&A will have to beinterconnected in the next three to five years.

For top level IT services, one can no longer make do withinadequate or limited tools. What is needed now is theimplementation of support tools that allows an integratedapproach to basically all internal IT services.

These are turbulent times for the IT specialists at theDetam, an organisation that is crying out for structureand management. This is why what we now callconfiguration management and a Help desk were startedup about three years ago. Peter Reitsma is in charge ofthe Help desk team at the Detam. It did not take himlong, however, to realise that the tools he had at hisdisposal for the management of the Help desk wereinadequate for the job. His colleague Donald Wijsman,head of the configuration management team, came to thesame conclusion in his work; a lot of effort and work foran unsatisfactory result. Reitsma: It was obvioussomething would have to change. We decided not tobuild anything ourselves, but to have a look around themarket. Our research was thorough and, ultimately, weplumped for PROLIN's Pro/Helpdesk. An importantreason for our choice was that Pro/Helpdesk covers boththe Help Desk functions and configuration management.The system can also be extended, for example, withproblem and change management. And finally,Pro/Helpdesk is compatible with Oracle technology,which the Detam is using more and more.




135

11.5 Implementation: howwe got there


Early in 1994, it was decided to buy Pro/Helpdesk, but ittook another nine months before implementation was infact started. The program required a Unix machine thatDetam did not have, and in an organisation such asDetam this meant that the whole authorisation processhad to be gone through all over again. As it was alsoconsidered better to wait until the holidays were over,actual implementation did not start under September1994, and a very energetic start it was too. A task forceclassified the hardware, software and network systems ina way that both the Help Desk and the configurationmanagement will be able to work with for years to come.They were assisted by the Prolin consultants, who coulddraw on experience gained in previous jobs. The finalclassification consisted of two screens containing basicinformation about such things as type of equipment,serial number, date of purchase, supplier, serviceprovider, guarantee number, price, cost centre and site.For Help Desk functions, type and site are the two mostimportant items.

The database itself was loaded in October 1994. 'Wedecided from the outset not to convert data from our oldtools,' says Mr Reitsma. 'The old data was far fromcomplete and contained too many incorrect records. Thatis why we set up an action plan and made available thenecessary funds to re-enter all data, this time correctly.That was quite a job, all the more so because theequipment was divided among more than thirty sites. Allin all, we are talking about more than 7,000 hardwareunits, a number that is growing daily.'

In October 1994, three people had a full-time job loadingthe database, assisted by about a dozen volunteers at thedifferent sites. Most of the work had to be done early inthe morning or on the free Saturday. As Donald Wijsmancomments; 'fortunately, Pro/Helpdesk can be combinedwith an effective bar-code system. That October, allhardware modules were given a bar-code sticker linkingthem to the background information in the database.Furthermore, all offices in thirty or more branches werecharted and given their own bar-code, which makes itvery easy to link types of equipment to their site using ahand-held terminal. Very useful for both Help Deskfunctions and periodic inventories.

'These inventories are necessary to keep the database up-to-date. Don't ask how or why, but computers and




136

11.7 Where we go fromhere: on the trail ofITIL

peripheral equipment manage to disappear now andthen, if only to the supplier's for repairs. Appropriatesteps must of course be taken, ranging from finding themissing machine to buying replacement systems.

So far, all we have done is input the hardware into thedatabase. The software and network systems still have tobe done. Preparations for this are nearly complete, so wecan soon start loading them into the database. Separateregistration is also being considered for critical hardwaremodules.'

That is not the end of the implementation process,however. Attention has now turned to other functions,such as the Help Desk. Detam is already looking toexpand these basic systems by solving problems inadvance and guiding change management. Differentkinds of software distribution are also being considered.Although Detam still has a long way to go in its supporttool implementation, it has laid a strong foundation tobuild on in the near future.

Once it had chosen Pro/Helpdesk, the Detam was onthe trail of ITIL, since PROLIN uses ITIL as a guidelinefor its products. 'I had heard of ITIL, but I did not knowmuch about it', Wijsman admits. 'PROLIN told us aboutITIL's potential, as did Bull, our main hardwaresupplier, at almost the same time. The result was thatthe board allocated a significant budget for a study ofthe potential and the benefit of using ITIL within ourorganisation. This enabled us to attend courses andseminars, conduct internal research etc. The situation asit stands is that we take ITIL on board and carry on inthe same direction.' Reitsma adds that the board hasapproved the ITIL route. 'I think that's a vital point,because you can't make these kinds of decisions withoutmanagement support. I believe that the ITIL route has tobe accepted by the entire organisation, or it would notsucceed. Some options are being kept open due theimpending merger. As far as I know, our new partner,the BVG, is not yet working with ITIL, but I think they'llhave to change that. It's already hard to oversee theconfiguration, and it's becoming even more complex.We believe ITIL to be an excellent method forcontrolling and channelling this complicated material. Ican well imagine that the integration, which will have tofollow the merger, will be conducted on the basis ofITIL.'




137

11.8 Users becomecustomers

Furthermore, the Service Organisation has beenoperating within the Detam for just under two years. Thisis a platform for periodic consultations betweenrepresentatives of all sections of the facility managementcompany, and, although the entire Library is not yetavailable during these consultations, this platform isassuming more and more ITIL 'features'. It seems obviousthat this will become more structured in the not-too-distant future.

The Detam is undergoing radical processes of changewhich are crying out for methods and tools to managethem. This concerns not only management of thetechnical side of the matter. Detam's I&A departmentwill soon have to measure up to other potential(commercial) suppliers, and when it does, it will requirean adequate organisation and approach to the work. TheDetam's facility management company has alreadytravelled some way down this new road. DonaldWijsman couches the situation in a short but typicalsentence: 'We don't talk about 'users' any more. Theyhave become 'our customers'. Things could not bebetter.




138




Measuring advantages gained from using ITIL





Chapter 12Measuring advantages gained from using ITIL


141

12 Measuring advantages gained from using ITIL

Section Page


12.2 Where we started from and what triggeredthe change 143

12.3 How we started 144

12.4 How we got out 144

12.5 Measuring 145

12.6 How we got where we wanted to be 146

12.7 Lessons learned 147

12.8 Where we go from here 147

This case study was provided byPROLIN




142





143

12 Measuring advantages gained from using ITIL

12.1 Introduction

12.2 Where we started fromand what triggered thechange

The Dutch Industrial Insurance Schemes (GAK) is nowreaping the benefits of four years of ITIL efforts. The pastfew years have been full of ups and downs, and thoseinvolved are well aware of the fact that what has beenachieved now is but a milestone on a long road yet to betravelled. Systematic measurement allows continuousadjustment of processes and yields indications of theadvantages of using ITIL. But that is all they are –indications; ITIL is only one of the factors that influenceimprovement processes.

Everyone in the Netherlands knows the GAK, anorganisation responsible for the administrativepaperwork of about fifteen industrial insurance boards.They implement social legislation by collectingpremiums, on the one hand, and by providing benefitslike unemployment, sickness and disablement benefits.All in all, a considerable number of the Dutch employers,as well as hundreds of thousands of unemployed anddisabled people, come into contact with the GAK. Thismeans that millions of people are involved and theconcomitant paperwork is extremely extensive. The GAKemploys 16,000 people, who work in the headquarters inAmsterdam and in thirty district offices. Almost all ofthem have a PC or terminal on their desks. All terminalsand PCs are integrated into a standardised nationalnetwork linking five computing centres, directed by theR&I (computing centres and infrastructure) department.

'Some five years ago, the need for a more structuredapproach towards IT services arose in this R&Idepartment,' says Jos London, who supervises the teamresponsible for the optimisation of business processes.'This was not because a lot of complaints about qualitywere received from people within the organisation, butrather as a result of the growing awareness that ITservices were, and still are, of crucial importance to theGAK. If, say, a computer in an industrial companybreaks down, they can just go on making products andcatch up the administrative backlog later. But things aredifferent in an organisation like ours. If one of the maincomputers breaks down, thousands of our people areunproductive, because production is impossible. Andwhat's worse, if this breakdown continues, hundreds or




144

12.3 How we started

12.4 How we got out

thousands of people will receive their benefits too late.This is bad for our name and must be prevented at allcosts.'

This awareness, fed by advice from a consultant, led theGAK to ITIL. London explains: 'The ITIL approach waswelcomed with open arms. At last we had a method tochannel all kinds of processes; at last we had a theorythat expressed what we had always thought but couldnever put a finger on. Although, as I said, we were underno pressure to have the computing centre function moreefficiently run, ITIL was still an eye-opener formanagement. The ITIL books were studied fervently andconsulted all the time to solve problems. Mind you, I'mtalking about the first stage of ITIL experience, in theearly 90s. In those days, most IT people were still up intheir ivory towers, with an attitude of 'I manage abrilliant network, but it is such a nuisance that otherpeople make it unstable owing to their unpredictablebehaviour'. This was also the attitude with which ITILwas approached. I'm exaggerating a bit, but ITIL becamea hype for a relatively small group; there was not enoughlink to the shop-floor, to the people that actually had torender the services. In this stage ITIL became well-known in the organisation, but there was too littleintegration of ITIL in our business process. After twoyears of experimenting this way, ITIL seemed to die aslow death.'

The approach taken in the second phase, which started inthe middle of 1993, was totally different. 'We realisedthat ITIL was not a panacea and, what's more important,we understand that we had to gear the things ITILoffered to our own organisation,' reasons London. 'Weestablished a team to guide the ITIL process, evaluatedthe strengths and weaknesses of our organisation and thetools available to use, and sifted out the most relevantITIL themes. We soon found out that we already hadsome elements, such as change management andsoftware distribution. All we needed to do wasinterconnect those elements and to extend with otherelements.'

The GAK has also learnt to employ ITIL in a morepractice-oriented manner. London: 'We de-theorisedITIL within the organisation in favour of simplycompleting and implementing. And not just for the




145

12.5 Measuring

happy few, but for everyone. In addition, we constantlyevaluated and checked, so that all computing centreemployees soon learned the ITIL approach.Consequently, everyone could see for themselves that thenew approach generated improvement.' On the otherhand, employees did have to change their workingmethods. Previously, IT specialists used to work mostlyin isolation; they all worked on their own little islands.But with the new approach, the work environment ismuch more open. What's more, everybody has to make arecord of what they intend to do in order to improve theco-ordination of the activities. This met with someresistance initially, but that soon changed once they sawthe improvement.'

In the first phase, up to 1993, results were rarelymeasured. Subsequently, however, the GAK startedcollecting data systematically, particularly regarding thedegree of availability of IT systems. Six-month planswere drawn up and monthly reports written on theactual situation. Responsibility was allocated for theplans and monthly reports required for all the processes(such as configuration management, Help Desk, problemand change management). 'We made a divisionaccording to process organisation on the one hand andprocess implementation on the other,' said London.'Process organisation concerns procedures that exist orare to be introduced, how much is known about them,and who is responsible for their implementation. Inaddition, reports are written on everyday matters, suchas the number of failures reported to the Help Desk inthe past month, the nature of the failures, how they weresolved and how long it took to solve them. We also havea similar system for other processes, such as whatchanges have been made to the system (changemanagement), at whose request and with what result.We started using checklists for this which derive largelyfrom ITIL.'

At the end of 1994, the GAK succeeded in organisingmost of the processes in such a way that measurementwas possible and useful. Initially, different informationsystems were used for each process. As a result, theinformation collected was inconsistent, making controlinefficient and difficult. So the GAK started looking for asystem for integrating the processes in order to improvecontrol.




146

12.6 How we got where wewanted to be

In the fourth quarter of 1994, most of the operationalprocesses were redesigned. Each process was supportedby an information system and that worked quite well.Nevertheless the improvements once again seemed tocome to a halt. The main reason was that the GAK hadmany different information systems supporting thebusiness processes. The co-ordination was insufficientand it was far from easy to realise consistency in theinformation flows. Managing the processes and theintegration of processes, became more and moredifficult.

Another aspect was the intensification of the informationsystem, partly to show that the new approach reallyprovides more efficiency and effectiveness, partly to gainan even better understanding of the relation betweenprocesses of change and the desires of clients. Anintegrated (and integrating) tool was needed to supportall processes in order to obtain more extensive, consistentinformation. This tool was found in the form of thePro/Helpdesk from PROLIN of Amsterdam.

'In our search for suitable tools, we found that there aremany suppliers in this field', says London. 'But mostpackages covered only part of the subject and/or werenot ITIL-oriented. Pro/Helpdesk is based on ITIL andprovides an integrated approach towards all elements.Furthermore, PROLIN was prepared to help us to co-ordinate the modules exactly to our own requirements.PROLIN made use of our experience in this field in thedevelopment of the product'.

This is not the place for an extensive discussion of thePROLIN system but we do want to give a brief overviewof Pro/Helpdesk, because, contrary to what the namesuggests, it includes much more than Help Deskfunctions. It consists of the following modules:

• configuration management

• Help Desk management



• software control & distribution

• service level management.




147

12.7 Lessons learned

12.8 Where we go from here

All modules are integrated, but can also be usedseparately, so it is possible to install the system in phases.'We have also added elements to the software systemusing our experience and expertise in the field of ITIL,'explains London. 'Pro/Helpdesk is extremely flexible,aimed at future developments and, partly because ofthat, suitable for the GAK. It meets our requirements formore comprehensive and, particularly, consistentinformation. This has given new impetus to our ITILprocesses.'

At the GAK, process measurement is always gearedtowards ascertaining the availability of IT systems. Thatavailability must, of course, be optimal, preferably 100%.However, that maximum is probably unattainable as ourorganisation is constantly undergoing processes ofchange, which naturally also affect availability. After all,when someone in the organisation wants a newapplication package, it is by no means always available.London explains, 'We attach great importance to thewishes of our clients, the people who work with the ITsystems. We work from the bottom up to ensure that ourorganisation is as prepared as it can be and to keepavailability of IT systems as high as possible. In addition,we also work from the top down, ie we consult closelywith our clients in order to take stock of their wishes.When working from the bottom up, ITIL is ideal; for thetop-down method, the clients come first, and they are notinterested in ITIL or ISO. They simply want to seeresults.'

London does not cite any exact figures (they would be ofno use to other organisations anyway), but he does saythat availability has increased to a considerable extentlately. 'But I would not go so far as to attribute thatimprovement entirely to ITIL,' says London. 'There areother factors involved. For example, the technicalservices have sharpened up, and PCs and othercomputer equipment have become far more reliable inthe course of time. You see, if such machines simply donot break down any more, the degree of availabilityautomatically approaches the 100% mark.'

It is impossible to imagine the IT department of the GAKorganisation without the ITIL approach. London evenconsiders the approach to be of 'vital importance'. Amajor shift has taken place within the GAK with respectto the perception of ITIL. Initially, ITIL was




148

approached primarily from a technical point of view, tosolve technical problems. Nowadays, ITIL has been putin a service and business economics perspective, tiltingthe matrix 90°: the focus is not on software, hardwareand networks, but on providing services to ourcustomers with their specific requirements. Jos Londonexpects this service/business economic perspective togain in relevance in the next few years.

'Certain trends within the GAK are leading towards theIT organisation becoming more independent. Thisinevitably comes with a certain degree ofprofessionalism in the relationship between the R&Ddepartment as service supplier and the other GAK userdepartments. How does the user, the customer, perceivethe computing centre, what are the requirements of thecustomer, what do they want to pay for them? Thisimplies that we have to pay more attention to theirrequirements and to making facilities available to them.We cannot go on simply reacting to developments, wemust also anticipate new developments and thecustomer requirements that ensue from thesedevelopments. The ITIL approach has rendered thispossible.'



Annex AProfiles of consultancies involved

Pink ElephantF.I. Group plc

Quint Wellington RedwoodUltracomp Ltd

Prolin Automation







151

Pink ElephantProfile in outline

Company name andaddress

Pink Elephant offers integrated services on managementand exploitation of Information Technology to allorganisations whose business processes are dependenton IT. The company is specialised in technical,organisational and business management of computerand information centres, at operational, tactical andstrategic levels.

In addition, Pink Elephant offers many services related toIT organisational structure, consultancy and ITmanagement. Assignments in these fields range from theestablishment, staffing and technical management ofcomputer and information centres, control of networksand office automation, consultancy, facilitiesmanagement and outsourcing, education (in relation toIT management), through to executing interim and long-term line and project management functions

Through full adoption and via contributions to CCTA'sdevelopment of the IT Infrastructure Library (ITIL)management method, Pink Elephant has helped topromote ITIL as the de facto standard for ITinfrastructure management.

Pink Elephant has fifteen years of experience in themanagement of computer and information centres, is thebusiness partner in IT management for several multi-national companies, and employs more than 950 staff.

The Pink Elephant Group is part of the RoccadeInformatica Groep.

Pink Elephant GroupPublic Sector bvPostbus 1062270 AC Voorburg

Telephone + 31 70 304 77 77Fax + 31 70 335 13 57




152

F.I. Group plc (FI)

Profile in outline FI offers a variety of managed IT services to support itscustomers which include some of the largest blue chipcompanies in the UK. FI works to suit each customer'sneeds through partnerships, through managed servicesand training and through the recruitment of computerpersonnel.. It's MAINSTAY application support andmaintenance service is a market leader in the UK.

FI strives for excellence in customer service, quality ofwork, innovation and flexibility. Its reputation has beennoted by such gurus as Tom Peters and Charles Handy,and was reflected in recent years by a British Standardsquality accreditation (BS EN ISO 9001).

FI has been involved in ITIL since its inception,reviewing and commenting on several of the ITIL booksprior to publication. FI is an accredited trainer for servicesupport and delivery and has more than twentyaccredited ITIL consultants. FI's MAINSTAY productmanager sits on the management board of the ITIMF andFI has provided speakers at a number of ITIMF forums.

For further information please contact:

F.I.GROUP plcCampus 300Maylands AvenueHemel HempsteadHertfordshire HP2 7TQ

Tel: 01442 238300Fax: 01442 238400




153

Quint Wellington Redwood

Profile in outline Quint Wellington Redwood is a group of internationalorganisational improvement companies. It specialises inproviding practical help and guidance to the managerswho are directly responsible to their business partnersfor the development and delivery of InformationTechnology services. It also understands the need forthose services to make a measurable contribution to thebusiness value chain and for that contribution to berecognised.

The Group focuses on the five main areas of work inwhich its professionally qualified consultants haveextensive practical experience; service management(service support and delivery), sourcing, service andtechnical architectures, quality and informationeconomics

The independent advice and guidance for which thecompany is highly regarded includes audits, healthchecks, education and training, consultancy, toolselection and implementation and interim management.It may be at a strategic level, helping to create newservice lifecycle relationships, or in operational mode,assisting with the setting up of improved supportprocesses and procedures. In either case, although anassessment of the present state will be necessary, what ismost required is a clear and firm presentation of theactions and resources needed to move from the currentposition to that chosen by the client. Quint WellingtonRedwood therefore specialises in providing just that; notsimply concentrating on what needs to be done but onexactly how the changes are to be successfully negotiatedand measured.

In assisting its clients to progress satisfactorily throughthe four phases of organisational improvement – analyse,unfreeze, reconfigure and re-freeze – Quint WellingtonRedwood employs its own unique understanding of theservice management processes. These are embodiedwithin the company's process models which, togetherwith their associated process relationship and data flowdiagrams and descriptions, have proved their worth in awide variety of situations. Two of these are described inthis book.




154


For further information, please contact:

For the UK, Ireland and the British CommonwealthQuint Wellington Redwood (UK) Ltd.Suite 18 North Oxford Business CentreLakesmere CloseOxfordOX5 1LG

Tel: +44 (0) 1865 370501Fax: +44 (0) 1865 370502

For the Caribbean, Central and South AmericaFervoro Consultants n.v.Kaya Wilson Goddett 33-35PietermaaiCuraçaoNetherlands Antilles

Tel: +599 9 656169Fax: +599 9 656391

For Mainland Europe, North America and the Rest ofthe WorldQuint Wellington Redwood Nederland b.v.Group HeadquartersEmmaplein 21075 AW AmsterdamThe Netherlands

Tel: +31 (0) 20 6761600Fax:+31 (0) 20 6761700




155

Ultracomp Ltd

Profile in outline Ultracomp is a leading supplier of Service Managementproducts, consultancy services and training. Since itsformation in 1981, Ultracomp's strategy has been to focusits energy and skills on helping IT providers improve thedelivery and support of services to their users.

Ultracomp has a well established and evolutionaryproduct development strategy for all of its ServiceManagement tools. The Red Box Service ManagementSystem represents the latest generation of Ultracomp'sproduct strategy and provides complementaryapplications for Service Management.

Consultancy and training are an essential part ofUltracomp's Service Management portfolio. This,together with Ultracomp's product strategy, provides acomplete service to client organisations. Indeed,Ultracomp is one of the leading suppliers of training forthe ISEB's (Information Systems Examination Board)Certificate of Proficiency in IT InfrastructureManagement.

Ultracomp is at the forefront of the move towards ServiceManagement methods in the UK. It has worked closelywith CCTA contributing to the production of the ITInfrastructure Library – ITIL. These guidelines forprofessional IT management have been adopted by manyorganisations throughout Europe and the UK.

Ultracomp designs and develops its product set at its UKdevelopment centre in Bracknell. With over 100 staffUltracomp has built up an excellent reputation for thedelivery of software, consultancy and training.

Ultracomp's customers include many of the largestcomputer users in both the commercial and publicsectors. Nearly 600 organisations rely on Ultracompproducts and services in the UK, the Netherlands,Australia, South East Asia and South Africa.




156



Marketing ManagerUltracomp LtdUltracomp HousePinehill RoadCrowthorneBerks RG45 7JD

Tel: 01344 779333Fax: 01344 779385




157

Prolin Automation

Profile in outline Prolin Automation is a relatively young company whosehistory is characterised by very strong and continuousgrowth. Founded in 1987, the company has grown intoan international organisation with distributors andresellers in many different parts of the world.

Prolin Automation has based its IT Service Managementtool PROLIN IT Service Manager (originally known asPro/Helpdesk) on the guidance contained in ITIL. As thenew name implies the took supports problemmanagement, change management, configurationmanagement, software control and distribution andservice level management.

PROLIN IT Service Manager has been developed withOracle Case Tools in the Oracle RDBMS environmentand runs over more than 80 different platforms.PROLINS not only have the resources and expertise tohelp ensure the successful installation andimplementation of their tools, they also provide trainingfor beginners and advanced system users.

PROLIN's philosophy is to be more than just a supplierof tools by forming partnerships with their customers.The products that Prolin offers closely fit the needs anddemands of organisations with a very complex andextensive IT infrastructure. So it is no surprise thatvarious organisations from the Fortune top 1000 areProlin clients.


PROLIN PROLIN Benelux NVVan Diemenstraat 200 Contact: Katleen Baeten1013 CN Amsterdam Phone: +32.2.716.4030

Fax: [email protected]

For USA – PROLIN Software Inc.Contact: Mr. Arjen J. ProntPhone: +1.415.854.7489Fax: +1.415 854 7537

Tel: +31 20 530 1600Fax: +31 20 530 1611

email: [email protected]




158



Further information and associated guidance


159

Further information and associated guidanceUseful contacts This book of case studies is part of the IT Infrastructure

Library (ITIL). ITIL is managed on behalf of CCTA byStichting Exin, the Institute for Information Science. Ifyou would like further information on any aspect of ITIL,they can be contacted at:

ExinSovereign HouseBotolph StreetNorwich NR3 1DNUnited Kingdom

Tel: (+44/0) 1603 695172Fax: (+44/0) 1603 695174e-mail: [email protected]

An ITIL home page is available on the World Wide Web,at www.exin.nl/itil, which will carry news, informationand links for those interested in IT Service Management.

The ITIL books themselves are only a part of the 'ITILphilosophy'; the guidance is supported by training,consultancy and software tools. These are available frommany suppliers, not only those who have contributed thearticles in this book. The ITIL-based qualificationsmentioned in several of the case studies in this book areavailable for managers, practitioners and at anintroductory/familiarisation level. Information isavailable from the examination bodies:

Stichting Exin Information SystemsPostbus 19147 Examination Board3501 DC Utrecht London WIM 9FJNetherlands United Kingdom

Tel: (+31/0) 2344 811 Tel: (+44/0) 171 637 2040

While the case studies in this book give some idea of theproblems others have faced and the benefits possiblefrom an ITIL approach to IT Service Management, theywill not, of course, cover all the questions. It is alwaysuseful to meet and talk with others in a similar position,or those who have already done what you are setting outto do. Helpful contacts and the chance to discussappropriate topics are offered by the ITIMF. Establishedas the user group for ITIL, they offer their members aninvaluable forum for Service Management professionals;




160

Further reading

Management of Risk

including relevant seminars on Service Managementtopics and an annual conference. Contact them at:

For Benelux For South Africa & ZimbabweITIMF ITIMFPostbus 188 PO Box 693629700 AD BryanstonGroningen 2021Netherlands South Africa

Tel: (+31/0) 50 85 1111 Tel: (+27) 11 8071080

For UK and elsewhereITIMF1A Taverners SquareSilver RoadNorwich NR3 4SY

Tel: 01603 767181

The ITIMF also publishes the ITIL 'Pocketbook' – a handypocket-sized guide to the core ITIL disciplines.

Detailed guidance on the individual IT ServiceManagement functions can be found in the individual ITILbooks within the Service Support and Service Delivery sets.Those considering implementing ITIL may also beinterested in some of the books within the Managers set:

IT Services OrganisationPlanning and ControlCustomer Liaison

Also worthy of specific mention is the guide aimed atimplementing ITIL with small IT organisations, ITILPractices in small IT units.

The following CCTA volumes provide furtherinformation on the topics covered by these case studies.These are published by HMSO and available from theaddress shown below:

Introduction to the Management of RiskISBN: 0 11 330648 2

Management of Programme RiskISBN: 0 11 330672 5

Introduction to Managing Project RiskISBN: 0 11 330671 7

Management of Project RiskISBN: 0 11 330636 9


Further information and associated guidance


161

PRINCE For managing individual projects within a programmethe PRINCE® method is recommended. The PRINCEManuals are available from NCC Blackwell, 108 CowleyRoad, Oxford, OX4 0JF.

PRINCE Reference Manuals (a five volume setcomprising: Introduction to PRINCE, PRINCEManagement Guide, PRINCE Technical Guide, PRINCEQuality Guide, PRINCE Configuration ManagementGuide).ISBN: 1 85554 012 6

Also available from HMSO:

PRINCE – An OutlineISBN: 0 11 330599 0

All ITIL books are published by HMSO and are availablefrom ITIMF, in the UK, Benelux and South Africa (seeabove) or HMSO (see below). In many countriesthroughout the world, local agents supply ITIL and otherHMSO publications. For advice on how best to obtain thebooks in other countries contact Exin or HMSO.

HMSO Publications CentrePO Box 276London SW8 5DT

Tel: 0171 873 9090Fax: 0171 873 8200




162



Glossary


163

Glossary

application software

architecture

asset

BCM

BCS

benchmark

business process

capability

capacity

CCTA

client/server

An information system that supports a specific businessfunction, such as personnel management or orderprocessing.

The overall, complete design of, for example, an ITinfrastructure, or a building; used in this volume todescribe a framework for organisational change.

Component of a business process. Assets can includepeople, accommodation, computer systems, networks,paper records, fax machines.

Business Continuity Management.

British Computer Society.

Comparison of performance of a function, process oractivity typically between an external organisation andyour organisation.

A group of business activities undertaken by anorganisation in pursuit of a common goal. Typicalbusiness processes include receiving orders, marketingservices, selling products, delivering services,distributing products, invoicing for services, accountingfor money received. A business process will usuallydepend on several business functions for support, eg IT,personnel, accommodation. A business process willrarely operate in isolation, ie other business processeswill depend on it and it will depend on other processes.

The aggregation of the organisation, people, processesand technology which provides an enterprise with theability to achieve business goals and satisfy stakeholders.

Computing and telecommunications power and datastorage space: the capacity to process computertransactions and store data which matches the businessrequirements of the enterprise.

The Government Centre for Information Systems.

An IT architecture in which application processing ispartitioned between two separate computers, one a clientand one a server. The client requests services across atelecommunications link from the server which performsthe requirements of the client.




164

Configuration Item (CI)

contingency planning

disaster recoveryplanning

Facilities Management

incident

intelligent customer

IS

ISEB

ISO 9000

ISDN

IT service management

IT infrastructure

IT system

A component of an IT infrastructure – or an item, such asa request for change, associated with an IT infrastructure– which is (or is to be) under the control of configurationmanagement. CIs may vary widely in complexity, sizeand type – from an entire system (including all hardwaresoftware and documentation) to a single module or aminor hardware component.

Planning to address unwanted occurrences that mayhappen at a later time. Traditionally, the term has beenused to refer to planning for the recovery of IT systemsrather than entire business processes.

A series of processes that focus only upon the recoveryprocesses, principally in response to physical disasters,that are contained within BCM.

Placing work with an external specialist (seeoutsourcing).

A single occurrence of deviation from the specification ofan IT infrastructure component or an aspect of IT service.

A general term applied to an organisation when itsculture and procedures successfully enable the planning,implementation and use of IS/IT to achieve businessobjectives. The capability to purchase (as distinct fromprovide) IT services. The term is often used in relation tothe outsourcing of IT/IS.

Information System.

Information Systems Examination Board.

The International Standards Organisation series ofstandards relating to Quality Management.

Integrated Services Digital Network.

The totality of providing one or more IT services tobusiness units and of effectively managing theunderpinning IT Infrastructure.

The hardware, software, organisation, procedures,computer related communications, documentation andskills required to support the provision of IT services.

In the context of this volume, IT system is used as anembracing term for the hardware and software that serveas the basis for provision of an IT service or services tocustomers.


Glossary


165

IT

ITIL

market testing

outsourcing

preventive maintenance

PRINCE®

problem

release

Request for Change(RFC)

risk

service provider

Service LevelAgreement (SLA)

software lifecycle

software (development)method

Information Technology.

The CCTA IT Infrastructure Library – a set of guides onthe management and provision of operational ITservices.

Inviting bids from external service providers which arecompared on a fair commercial basis with bids to run thesame service from the internal provider, to achieve bestvalue for the enterprise.

The process by which functions performed by theorganisation are contracted out for operation, on theorganisation's behalf, by third parties.

Action taken to make subsequent maintenance moreefficient and reliable. This includes reverse engineering.

PRojects IN a Controlled Environment, the CCTA projectmanagement method.

PRINCE® is a registered trademark of CCTA, the Government Centrefor Information Systems.

The underlying cause of multiple occurrences ofincidents; also, a serious incident.

A collection of new and/or changed configuration itemswhich are tested and introduced into the liveenvironment together.

A form or screen, used to record details of a request for achange to any component of an IT Infrastructure or anyaspect of IT services.

The chance exposure to the adverse consequences offuture events. A measure of the exposure to which anorganisation may be subjected. This is a combination ofthe likelihood of a business disruption occurring and thepossible loss that may result from such disruption.

A third party organisation supplying services orproducts to customers.

A formal statement of service characteristics between ademander and supplier of services.

The lifetime of a software system from conception todecommissioning. Software lifecycle includesenhancement and maintenance following delivery.

A systematic way of performing part or all of theprocesses involved in a lifecycle model or stage (forexample, the requirements stage, or design stage).




166


Printed in the United Kingdom for The Stationery OfficeJ0100434 12/99 C3





Date post:	22-May-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

IT Service Management Case Studies · ITIL as an agent for change – 1 (Chapter 3) ITIL as an...

Documents