Category Archives: …in a nutshell

Changes…in a nutshell

Change management is all about making sure any changes you are making cause the minimal of disruption to the business and if, it cannot be avoided, communicate the change to the business so alternative arrangements can be made.

We have all had that dreaded unscheduled changes happen to us at some point in our lives. Let us take the example of a holiday. There could be a connecting flight involved which is tight but do able, just as Murphy’s law decides to play out and a plane is delayed or cancelled. Time to put your  head in your hands and sob. The change was unscheduled so alternative arrangements have to be made at that moment, not ideal and your calm, holiday self has transformed into a angry ogre as someone is separating you from your holiday. This situation could be avoided if change management was followed.

Lets now take something quite mundane to describe the three types of changes, standard, normal and emergency. A family car, used to take mum to work, one child to ballet and another to rugby on Monday night, kickboxing for one child on Wednesday night and Friday night is always eat out night…well its Friday.

A standard change would be something routine, something which doesn’t need prior planning like a normal change. Maybe checking the tyre pressures and pumping them back up to the correct PSI, checking the oil level and topping the oil up or it could be something like a whole oil change, if you are very competent. Word of warning, have some wood chips or cloth to mop up any excess oil. My dad once found out to his cost…and the wrath of my mother. As you can see it is something quite day to day, nothing too impactful on the service running of the car.

A normal change, is something which could be potentially impactful to the service running of he car. A service of the car at a car dealership could be one candidate for a normal change. The day of the service cannot be impactful to the SLA which has been agreed with the kids  of Monday night and Wednesday night and hopefully not Friday. So the service needs to be either completed in the day time or if it needs to be left over night, the service should be carried out on Tuesday or Thursday to cause the least disruption to the kids. Mum can work from home on these days so she is also minimally impacted. Dad’s car is also there as a back up to take the kids to various clubs if the car does need more time. This is much the same as a backup link on a network, while one switch is being worked on, the backup network can take up the loading. The timing is discussed with both parents (CAB meeting) to make each other aware of the upcoming change to the service running of the car so dad can make provisions to make sure his car is able to step in, if needed.

An emergency change, this could be a breakdown of the car while mum was driving home or in the case of the plane, the plane cannot be used. An emergency CAB is formed of only the people who need to be involved (this should be pre-arranged) to try and make sure the service can be resumed as quickly as possible. In the case of the car, mum will need to call dad to ask if he can go home and make sure the kids can get to the right places in time. In the case of the plane, ground staff and checkin staff will need to try and find if other planes can take the stranded passengers to their destinations or if another plane can be used. Communication needs to be clear and quick in order to keep the customers informed and to reduce customer frustration. These types of emergency changes should be kept to a minimum but you should know what to do if such a change is needed and who to ask for approval in order to know who to involve in the emergency CAB.

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.

Categories in a nutshell

Categories

I wanted to write this post to try and explain why we use categories in ITSM tools such as Remedy, Servicenow etc and why I think there is a need to be monitored regularly.

Lets start at the beginning, when logging and incident or request the team categorises the incident or request.

Please can I have Photoshop installed? – Category = Request – Software – Photoshop – Install

Or

I can’t connect to any network shares – Category = Incident – Network – Loss of network connectivity – Desktop

These categories choices are open to debate and discussion, that’s the beauty of ITIL, it is open to debate and a guide. You have to work out what works best for you and your company.

The next step in ITIL, remember you whole reason for doing ITIL is to provide value to the business, is to analyse these incidents in Incident Management. This should highlight trends, eg reviewing the incidents shows 30 calls per week to install photoshop, which is taking an engineer 30 mins per install to do. Maybe, this could be automated and therefore giving 15 hours back to the engineers and providing a better, quicker service to the business. More importantly, you can see trends with incidents, the incident with the network shares, you notice this happens to the same person every week at 2pm on a Tuesday. A reboot fixes this but it keeps happening and is probably a clue that a problem should be raised and looked at this in more detail.

One of the reasons to logged problems is if incidents are trending but the root cause isn’t found, then these can be looked into in more detail and hopefully finding the root cause. Once the root cause is found and resolved, then the incident shouldn’t happen again, meaning a happy customer and your engineers can work on something else. The whole point of incident management is to look at ways to reduce the number of incidents and requests.

However, how many categories do you have in your organisation? Could an incident be categorised few different ways depending on who picks it up? Are there duplications of categories / sub categories? How often do you look at your categories and check if they are still relevant and if some should be added or deleted?

These questions I think are the crux of why I think categories need to be monitored. Do you need all the categories / sub categories? When were each last used? A lot of ITSM tools has loads and loads of categories…….are they all used and would the engineers who are logging the incidents know which one to use or could they use a few different combinations? If so, are you sure your incident management trend analysis is picking up all the incidents and giving the true picture of what is happening week on week? How often are the categories reviewed? Do you still have a category for Windows Server 2000….do you have any servers still running Windows Server 2000?

A possible solution would be this; rip down the top level categories to your primary services in Service Catalogue eg Telecoms, E-mail etc. Using your engineers previous experience, reviewing any trends of incidents/requests and intuition make up some sub categories, limit the sub categories to less than 10 and add other to all these categories. This gives a better chance to trend incidents and requests in future. However, add ‘other’ to the sub categories so any incidents that don’t match the categories can be logged under the ‘other’ category. Create a workshop for engineers to explain which type of incidents/requests should be logged under which category and what the ‘other’ category is for and document this.

On a regular basis, initially, review the incidents and categories; looking at why the ‘other’ category has been used, does another category need to be added? This is fine-tuning the incident categories. Are the engineers using the right categories for the right types of incidents and requests?

On a bi yearly basis, a review of all categories should take place, are these still all relevant? Does some need to be deleted or added? Are you able to see trends and are you taking steps to reduce them?

I hope this shows how important getting categories right and making sure these are monitored to keep them in check.

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.