Avoiding Mistakes with ITIL
Avoiding Mistakes with ITIL (IT Infrastructure Library)
ITIL is best practice advice and guidance. It is a common mistake to take as prescriptive. Needs adapted/customised to be organisation specific. So is not a silver bullet. Not a standard. You cannot be ITIL compliant. You need to adopt and adapt components of ITIL. Decide on the ITIL tools you are going to use and then modify them to suit.ITIL Aims
- Ensure IT completely aligned with current and future needs of the business.
- Continually improve quality delivered IT services.
- Increase the efficiency of IT service delivery
So the aim of ITIL is not to create a disconnect between IT and business (which is common)
Example: a common metric is ‘point of contact resolution’ – the percentage of calls resolved immediately by first line servicedesk over the phone. ITIL would say set this percentage based on business need – which might even mean reducing the metric down from say 90% down to 75% – don’t waste money.
ITIL processes should not be bureaucracy/red tape. They should speed things up and reduce waste.
ITIL Terminology
Customer – the people who pay for and/or set the requirements for IT
User – everyone who uses IT (including students)
IT provider – In house IT people. In a completely outsourced environment this would be the IT contract manager.
IT supplier – third parties, external organisations
Servicedesk (a ‘function’) provides first level Incident Management (a ‘process’)
Incident Management versus Problem Management
Incident Management – firefighters. Goal is to fix incident as soon as possible and minimise interruption. Speed important.
Problem Management – cause analysis and long term fix. Goal is to prevent the re-occurrence of incidents. Note no reference to speed explicitly.
SLA targets dictate incident management response times.
Prioritisation of incidents based on (1) urgency and (2) business impact.
The Servicedesk never undertake problem management, they only do incident management.
There is a 1:many relationship between problems and incidents.
SLA – service level agreement
OLA – operator level agreement
Important to continually review SLAs – relevance quickly ages.
‘Availability’ is in most cases an awful target to use. SLAs should be in plain language.
OLAs apply to individual teams. Example – SLA might state “Email available”. This would have two related OLAs: for the Email Team “Email server functioning”, for the Network Team: “Network functioning”.
OLA can be technical and detailed. But SLAs should be simple and plain. For external suppliers, SLAs/OLAs get written into the legal contracts.
There is no real reference in ITIL to a Systems Architect / Designer function.
Leave a Reply