RfCs and Changes, can they be treated as CIs themselves?

[fhernand]

Hello to everyone,

my question addresses the tracking of RfCs and Changes as CIs. Being documentations of a process themselves, should they be included in the CMDB?

thank you for your input,
kind regards,
Felipe H.

[pac666]

Yes the RFC can become a CI when it's created. Then you can start tying everything together in the CMDB (the benefit of relationships). Depends on your needs though.

[Timo]

Hi Felipe,

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?)

Hope this helps,

Thanks,

Michael

[JoePearson]

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.)

[Mark-OLoughlin]

Hi,

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

[fhernand]

Hello again,

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.

All your answers made this clear, thanks again.

Kind regards,
Felipe