Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Wed Nov 14, 2007 2:44 am Post subject:
My question to you is 'why'? Individual RFC's and Changes are records, not processes, that simply contain information about the state of your infrastucture at a given point in time. You can treat a process document for managing RFC's and Changes as a CI, however, individual instances of RFC's and Changes should not be regarded as such.
Think of it this way: would you ever need to create an Incident, Change, Problem or an RFC against another Change ticket (no CI in the Change ticket, but the ticket itself?)
Joined: Oct 13, 2006 Posts: 116 Location: South Africa
Posted: Thu Nov 15, 2007 1:54 am Post subject:
You can understand "CI" at two different levels, both of which you can make a case for reading the ITIL books.
1: Anything you need to manage information on in the course of delivering service is a CI. In this view, yes, RFCs, incidents, etc would all be CIs. The processes themselves are CIs. The documents defining the processes are CIs. Of course the records of the flow of the process are CIs. This gives pac666's answer.
2: Anything within the scope of Change control is a CI. This aligns with the concept of populating the CMDB and bringing those CIs under change control at the same time. In this view, obviously RFCs are CIs because then you would have the ridiculous situation of having to raise an RFC in order to raise an RFC. (NB In this view processes and process documents are still CIs - you definitely apply change control and version numbering to them.) This gives Timo's answer.
To quote Timo, "information about the state of your infrastructure at a given point in time" is exactly what Configuration Management is all about.
However, most CMDB tools are designed to deal with definition 2 - CIs are managed entities. If you try to force things into a particular CMDB that it wasn't designed for you are asking for trouble. And this is the difficulty with Config Mgt today: CMDB tools vendors don't explain their designs in terms a customer can align with other process needs, or don't make them open and flexible. (Not easily. Anything can be accomplished with programming, they'll tell you.)
Some software vendors call the service management application the CMDB. So the perception is that everything in the CMDB are CI's becuase what makes up a CMDB ... CI's.
I would not say that an RFC is a CI. You relate the RFC to a CI being the component that you are raising the change request against.
Processes can be stored as documentation classified CI's and put under change control.
You would audit CI's differently to RFC's and incidents. CI' are audited to validate the data for that CI. RFC's are audited to validate that the process was followed and that the information provided in the RFC is in line with what is expected. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Posted: Mon Nov 19, 2007 10:45 pm Post subject: great replies
excellent answers from all of you, thank you.
@Michael: Yes you are absolutely right, changing individual Change Tickets or RFCs through other RFCs does not make much sense, and is not necessary, as a Change Process should itself include provisions to find alternative answers to a change in requirements (starting a new RFC, or looping inside the same Change Process)...
so yes, Change Tickets thus fall out of scope of Change Control and therefore should not be handled as CIs.. Yay for avoiding Gödelian entanglements
but changing the Change process (a CI as all of you pointed out) itself through a RFC is sensible.
I was searching for the connection between these two databases (change tracking DB and CMDB), and it is in essence through these change processes.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum