Change Conflicts

[lucsutherland]

I have found something within change management that I am unsure how to fix. I scheduled a change with CRM as the affected CI, and then scheduled another one with the same CI for the same time.

This generated two conflicts, both of Type CI Already Scheduled, for the CI CRM. The Change and Conflicting Change were the original and current change requests, with positions swapped. Redundant, but not really a problem.

I went to change the CI on the second change request to ServiceNow, but it still generates a conflict. It is of type CI Already Scheduled, where the Affected CI is CRM. However, the Conflicting Change is the current change, and the Change is the change with CRM as the CI.

I changed the Configuration Item; shouldn't this have zero conflicts now?

[robpickering]

Luc,

Best practice would be that the Change itself is happening on a physical or virtual CI, not on a Business Service.   The Business Service will show as "impacted" because underlying infrastructure is undergoing a change.

The issue you ran into is because you're scheduling the change too high in the Business Service Map, thus causing conflicts.   The actual change you're performing is probably on a physical or virtual component of that service, and as such, that's the CI you should pick for it.   If both changes are on the same CI, then combine them into a single Change, but most likely they are not, in which case there won't be a conflict.

Hope this helps.

-Rob

[lucsutherland]

I'm not sure why you are trying to say here. My CIs are just Applications without any relationships. I tried this in my test environment where we haven't mapped out our CMDB

[robpickering]

Luc,

If you don't want Change Conflicts to run, you can disable them, see here:

Enable automatic change conflict detection

-Rob

[lucsutherland]

Hi Rob,

I do want the conflicts to run, I'm just confused as to why it is detecting a conflict where one should not exist.