All you need to know about ITIL incident, change and problem management

Hey Wiz!

I am going to start work in IT service delivery. I would like to know the important things that I should know in incident, change and problem management for day to day activities.This will really help me. I don't have time to attend a course or read some dumb books. If you could just sum it all up for me that would be great. Can't be too much to it, surely...

Thanks Wiz!


Dear Chuckie

You're right, there isn't much to it. To sum up all you need to know day to day:

Incident management: if somebody rings up with something gone wrong, get them working again or explain why you can't.
Problem Management: if something is broken get it fixed, or let everyone know it isn't and provide a way to get around it.
Change management: get the OK before you change stuff

There! Saved you two grand and a drain on your scarce mental resources

Good luck!
The ITIL Wizard

P.S. please don't call me Wiz, it sounds like a bodily function


Good Advice!

One thing to keep in mind when starting to learn about these processes - Incident Management is the most important. That's because it's the one that causes the users to scream.

They really don't care about Problem Management or Change Management. The truth is, though, that you will only get Incidents because of Problems & Changes.

Now that I think about it a bit more - maybe Problem Management & Change Management are more important than Incident Management? Let me think about this a bit more and get back to you. Hope this helps.

You're on to something

I think you might be on to something. While Incident helps people that are screaming, Problem and Change fixes stuff, even if it stuff they cause. Is fixing or helping more important?

ITIL management

We train people on ITIL and also need to provide the user friendly systems and processes and work flows for them to practice it.

Systems need to be able to manage the opportunities that arise and managed for Customer perception + Service delivery Task + Cost + usability, availablity and user response levels. You want Customer Interaction and Change and Problem and Incident to be managed in the one system. In a nutshell without all the fluff Can do and just do it - are winners for me to. Personally we can weigh our percentages against these.

What is a good ticketing system for all levels of the company everyone seems to want to break what works because the ground rules change.

The ground rules as mentioned above were the same 30 years ago - technology has changed but we do not appear to be doing it smarter in fact quite the reverse. We seem to refine a system get everything nearly working and the replace it with a sytem that is supposed to do more but never does and breaks the functiuonality of what was working where we persevere with half the functionality.

Sounds like a carmaker - ( The Ford Motor company) - when we get it right lets break it - we can't have that - the peasants can't be that happy
Lets make life a little difficult for them - throw in a bit of spice here and a few herbs there - Hey - we are making some progress here - starting to sound more like the black art that it is!! Besides we cannot have it working well or we will be out of a job - so lets invent a few flaws to keep the economy ticking over.

had to add a little cyncism to help your sites cause and not be too boring !

Hey Wiz, you are right again

You don't know, how right you are.
If Chuckie is capable to follow your very simple definitions and
- He can get working what doesn't work
- He can fix problems or provide a workaround and
- Can inform every impacted party about planned changes in advance and gets their agreement
he will be ITIL "compliant", whatever it is.
If not, his problem, he should go back to school.
Talking more soberly, even sad, I'm interviewing candidates for process baseline, assessment and improvement positions and I'm really disappointed about their knowledge or rather the lack of it. I'm talking about people with lower or higher ITIL certificates, different colored belts and tons of said experiences. And they are not able to give a definition of the ITIL processes at the level of deepness as you did in this small piece.
Are you interested to join me in California (at least for a beer, sometime:)?

Syndicate content