![]() |
|
|||||||
| View Poll Results: Which ITIL process will you implement first? | |||
| Incident Management |
|
20 | 43.48% |
| Configuration Management |
|
8 | 17.39% |
| Change Management |
|
5 | 10.87% |
| Service level Management |
|
13 | 28.26% |
| Voters: 46. You may not vote on this poll | |||
![]() |
|
|
Thread Tools | Search this Thread | Display Modes |
|
#1
|
|||
|
|||
|
I found a lot of books and consultants have different viewpoints on which process is best to be implemented first in an ITIL implementation. I suppose it depends on your circumstances. I would like to hear what other memebers think of this? Please participate in this poll.
|
|
#2
|
|||
|
|||
|
Service level management deals about the planning partin the ITIL process. As per PDCA life cycle this should come first
|
|
#3
|
||||
|
||||
|
Quote:
Interesting approach and thinking about it, it does make sense. I would just like to clear up some questions that pop into my mind regarding this. How are you going to implement SLM first if you have no Incident Management and thus nothing to measure. Your SLA's will be totally thumbsucks and may not be realistic or is there an approach to overcome this? ![]() |
|
#4
|
|||
|
|||
|
I think Incident management is best to be implemented first in an ITIL implementation.
Nothing will start unless I can detect incident. |
|
#5
|
|||
|
|||
|
I think Configuration Management. As this is the basis of everything. It holds all the CIs and relationships about your infrastructure. This in turn helps better assess Incidents and what is being affect by them. It helps all of processes in many ways.
|
|
#6
|
||||
|
||||
|
Compman,
I can see that Configuration Management would be the ideal scenario to start with, but how will you keep the CMDB up to date without proper Change Management in place? |
|
#7
|
|||
|
|||
|
Quote:
Two of theactivities of Configuration Management are as follows: Status accounting. The reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development’, ‘being tested’, ‘live’, or ‘withdrawn’. Verification and audit. A series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration management system. Through these two activities the CMDB should be kepted up-to-date. But I can see you point as one of the problems is if Configuration Management has been implemented in isolation. i.e It is implemented without Change Management or Release Management, it is much less effective and the intended benefits will not be realised. So ideally Configuration and Change Management should be implemented together if possible. |
|
#8
|
||||
|
||||
|
Yes, I suppose implementing the two processes in conjunction would be the ideal scenario.
My understanding of status accounting is that it only track the status in which a CI finds itself at a particular moment, but it will not track changes like upgrades, moves etc. My understanding of audits is that it will only be done at intervals e.g. every 3 months, which means that it won't keep the CMDB current as Change Manangement would do. |
|
#9
|
|||
|
|||
|
Everyone is missing the basics here.
Before you start implementing processes you need to develop a business case to implement ITIL practices. To do this properly you have to develop it inconjunction with the business itself so that you can find out what is critical to their operations. Change management could be needed first in say a financial services organisation where an unplanned outage of minutes or seconds could have serious implications. Incident Management may be important when a number of people experience the same issue therefore requring priority and severity to be established. Only when the business has determined what is important to them can you decide which is the most important process to implement. It could be the only function "the Service Desk" if they currently have no way of actually communicating to IT that there are problems. |
|
#10
|
||||
|
||||
|
I agree with John on this one. It's all about where is the pain for the organisation and it's current maturity vs where it wants to get to.
In my particular case, we already have a reasonable service desk and incident management. We'll be revisting elements of SLM and putting together a decent service catalogue before targetting problem management to get the support (show the wfim) from the techies. Next on the our plan is the change and config (concurrent if we can secure resources for it, otherwise change first).
__________________
Follow the Adventures of the ITIL Imp online! |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| ITIL and Process Development | admin | ITIL Articles | 1 | 04-02-2010 08:07 AM |
| Sr. Process Consultant - ITIL - MetLife - Somerset, NJ | admin | ITIL Jobs | 0 | 01-04-2007 05:13 AM |
| Which ITIL Process Should We Implement First? | admin | ITIL Articles | 0 | 09-22-2006 01:48 PM |