Does ITIL v3 says how much relationships should be defined between Configuration Items?

No, ITIL v3 does not indicate how much relationships should be defined between Configuration Items. ITIL v3 provides some generic guidance on CI relationships in section 4.3.5.3 of the ITIL v3 Service Transition book. My recommendation would be to only include those relationships for which there is a defined use case scenario which drives the need for this information. This could for example be a CMDB/CMS report in which certain CI relationships need to be reported upon.

Dear Jeroen, At the moment we have integrated Production Change Management along our internal processes based on ITIL V.2. In this processes we had to make a differences between following change types: - Application Changes - Infrastructure Changes - Housing-Infrastructure Changes - Network Changes - Client and APS Changes - Core Desktop Changes - Operational documentation and licenses changes This diversification was mainly done because the change procedure models were different for each type of change. My Question is whether there are other best-practices, where such a differentiation has been made or whether this is a unique issue within our own IT Services organisation. Best regards. Quinten P. Ockers

Hello Quinten. The challenge that I see with your change types is that it sustains organizational silo's. It is best practice to use change types like major changes, emergency changes, pre-authorized changes, etc. For more guidance, I'd recommend that you take a look at the change management process described within the ITIL V3 Service Transition book. I hope this answers your question. Best regards, Jeroen Bronkhorst.

Hello Jereon, Within our process we classify our changes in the categories pre-authorized; minor; significant and major. For those categories we established a 10-criterien questionnaire along which the change category can be indicated by the requestor. My question remains, because although the procedures for each change type (application; infrastructure, housing, etc.) are the same, the procedure steps for i.e. an application significant change differ with those of an infrastructure significant change. My Question is still whether there are other best-practices, where such a differentiation has been made or whether this is a unique issue within our own IT Services organisation. Especially the procedure steps are different when a 3rd-party is involved. met vriendelijke groeten. Quinten P. Ockers

Quinten, understood. As each IT organization is managing a unique set of (service) assets, the change activities defined at a work instruction level (sidenote: I use the ISO9001 chapter 4 definitions here) will always be specific and customized to fit your unique environment. When it comes to processes and procedures however, my recommendation is to standardize and keep them generically applicable as much as possible. This reduces complexity and keeps maintenance of your process documentation at an acceptable level/effort/cost. Could you please elaborate a little on why the change procedures in your organization need to be different per technology type? Best regards, Jeroen Bronkhorst.

Hello Jeroen, Within a large organisation I do see the necessity to standardise the change activities, when it comes to processes and procedures. During the implementation of the internal process globally however depending on the type of change typical issues re-occurred again and again for different services. I.e. A change on an (in-house) developed application / software needs another set of work orders and approval stakeholders as a change on infrastructure. Furthermore the business requires a far more lean procedure for application changes as for hardware changes. Aspects such as operational acceptance tests are not in scope for minor application changes, it does for hardware. Furthermore the order life-cycle (budget approval) of hardware is not in scope of infrastructure changes; however it does on software changes. Within our continuous improvement program we are now twisting whether we should establish one process with extra may-be procedures for specific types are to establish several change process models with mandatory procedures. This is way I raised the question whether there are other best practises, which deal with similar issues. PS. Sorry for the late response, unfortunately I was on a business trip last week. Best regards, Quinten P. Ockers

Hello Jeroen, Could you comment on Service Catalogue Management? What are the form(s) of service catalogue we can see today?

Hello Vincent, I am not exactly sure what you are looking for, could you please elaborate a little. In addition I would like to better understand the context for your question. If other people have any suggestions to this topic, then feel free to jump in as well. Thanks in advance. Best Regards, Jeroen Bronkhorst