Tag Archives: itil blog

The ITIL cynic

“What is a cynic? A man who knows the price of everything and the value of nothing.”

Oscar Wilde

Sometimes I think most people see ITIL and ITSM as this. Organisations implement the bare minimum of ITIL in order to say ‘We follow ITIL’ but ITIL is too costly to the business so some form of incidents, problems and change has been implemented. As that is ITIL right? In my view, the IT organisation does not appreciate the true value of ITIL.

If we go for a drink after work, after a hard day. I offer to get the drinks but all I have is my credit card and there is a minimum charge for credit cards at the bar, so, can you pay for the first round? I know the prices of most of the drinks so ask if I can borrow £10 and promise to buy the next drinks with some food . You give me £10 and before you can say what you would like, I take the £10 note and goto the bar. You shrug your shoulders and hope I will know what you want, but do I? The answer is clear when I come back with a pint of cider for me and a cocktails, with sparklers, a little umbrella and some much fruit it in you think a gorilla will pop out for you…no Hmmm, I think I have messed up, after looking at your face looking at your drink and the longing look you have for my pint of cider. No problem, off I go again to rectify the matter with the change (we are not in London so I do still have some change), and I come back with…..a glass of sparkling apple juice. I thought you liked apples and a fizzy drink just like my pint of cider. At this point, you go to the bar yourself and buy yourself a drink, one which you want. Would you let me buy you another round?

This is my point, in the example, I know the price of the drinks so know I will come in under budget (£10) but have I provided value to my customer, you? I think the answer is no. I have assumed I know what you want without asking what you really want. If only I had asked ‘What would you like’ then I would of achieved the budget BUT also achieve customer satisfaction and value for money?

Sometimes I hear of companies who are very proud of their ITIL structure, incidents, problems and changes. However, how often do these companies meet with their business and find out how It is perceived? Can the IT organisation do things better to provide more value? Has the IT organisation improved its value from when it was not following ITIL to after it is following ITIL to the business? Does the IT organisation know the critical success factors for different business units and how IT can help achieve these?

If the customer does not see any more value pre ITIL to post ITIL or the business still feels they are not integrated with the IT organisation, then is the IT organisation following ITIL properly? ITIL is just an ideas book to help provide value, it is not a recipe book showing you steps 1-10 on how to bake a great IT cake.

This, I think, is the true value of ITIL. IT organisations should look at the value ITIL can help provide and not just the cost. Do not be an ITIL cynic.

Thankyou for reading my post. This is my opportunity to blog about a subject I love but am still learning. These posts are my way of showing how I understand the subject, however, I would encourage you to leave comments, did you agree / disagree with the post? Did I not explain something well enough or incorrectly? Do you want me to blog about another subject within ITIL? All feedback helps me to understand more. Thankyou.

Do we still need ITIL?

This is a great blog post http://optimalservicemanagement.com/blog/do-we-still-need-itil/. It reminds me of WHY you do ITIL, not because the ITIL book says so on page 32 but to provide value to the business.

If you just follow ITIL blindly then you will create a mess. Engage brain and see how bits can work for you, maybe some won’t work for you or could in future and that is ok. Just look to ‘adopt and adapt’ to make your IT organisation the best value for money it can be to the business.

Thankyou for reading my post. This is my opportunity to blog about a subject I love but am still learning. These posts are my way of showing how I understand the subject, however, I would encourage you to leave comments, did you agree / disagree with the post? Did I not explain something well enough or incorrectly? Do you want me to blog about another subject within ITIL? All feedback helps me to understand more. Thankyou.

Requests, Incidents, Problems and Known Errors in a nutshell

Over the past few weeks I have noticed some talk and discussion around what incidents, problems and requests are and what are the differences between them on some of the ITIL blogs. So here is my take :

Requests

These are requests made by the customer, eg please can you install x software or please can you replace the toner on the sales printer. These types of ‘can I haves’ should be logged as a request. These are separate to incidents, as they will have different SLA’s and priorities associated to them. Installing a piece of software for one member of the sales team has a different priority than someone in the sales team can’t access the network shares.

Incidents

These are for when thing breaks or isn’t working. eg My PC won’t turn on, I can’t access any network shares or none of the print outs are coming out of the printer. These are different to requests as it normally means the customer or team cannot work or a service is degraded so they can’t work as well. The person who picks up the incident will associate a priority eg a whole office who can’t access the network might be a Priority 1 incidents and a customer who can’t print might be a priority 3 call. These priorities should be documented with an SLA associated to them so the business will know roughly how log an incident of this type will take to fix. Again, it is up to you and the business to work out these priorities and SLA’s, ITIL is just a guide. The incident can be closed when the incident is fix permanently or a work around has been put in place which restores the service back to normal.

Ahh, and this is where some will wheel out the old chestnut, is a password reset and incident or a request?

Answer

1) Why is this not automated? Plenty of tools can allow the customer re set their password themselves without needing to log a incidents/request.

2) It is up to you and how you want to define it. All you are trying to do is separate incidents (priority) over a request (sometimes, not as higher priority, as an incident), be able to produce stats on the two to show trends to help with incident and request management and reporting to the business to show how great IT are.

Problems

What happens if all that the person who picks up the incident, can do is produce a work around or doesn’t know why the fix worked or multiple customers are logging the same type of incident eg reboot the PC and the problem goes away or all that can be done to resolve the incident is produce a work around, meaning the issues still exists but there is a sticky plaster to hold everything together? Now, problems come into play. Problems are something where a virtual problem team or an individual can look into the issue deeper, hopefully finding out the root cause and a permanent fix. A problem is also something that can be taken ‘off line’. The service has been restored as the incident has been closed so the danger has past but the problem can be used to investigate over a longer period to find the real issue.

Known errors

Through your diligent problem management and investigation, the root cause is found. However, like most things in life, it is not an easy fix. The fix requires a new server, cabling or the manufacturer of the component has acknowledged there is an issue but there is no driver update so all you can do is stick with the work around. ITIL has rather cleverly thought of this scenario and known errors can be used.

e.g.

An incident was logged and a workaround took two days to come up with but the manufacturer needs to update a drives before a permanent fix can be implemented. If someone logs a similar issues, the wheel doesn’t need to be created again, a known error should of been created after the first incidents work around was found so this can be used to implement a fix/work around quickly for the second incident.

A known error and the known error database greatly reduces the fix times for subsequent and similar incidents which are awaiting permanent fixes or there are other reasons why a permanent fix can’t be implemented, so a work around is as good as it is going to get.

Hopefully, requests, incidents, problems and known errors are a little clear on what they are and what the differences are.

Thankyou for reading my post. This is my opportunity to blog about a subject I love but am still learning. These posts are my way of showing how I understand the subject, however, I would encourage you to leave comments, did you agree / disagree with the post? Did I not explain something well enough or incorrectly? Do you want me to blog about another subject within ITIL? All feedback helps me to understand more. Thankyou.