Processes for big/complex change/device environments

Hello all, I'm looking for ideas/examples on how larger, complex environments are managing relating CIs/devices to changes. Looking at the out-of-box RFC forms that use the assets array to store multiple CIs per change. This seems like too simple a data model for "real life".

How do you handle catching overlapping changes? For example change 1 opens for a given start/end with 3 devices. Another change is opened with some of the same devices and date range. Ideally the system would alert you that there are conflicting changes. The simple pending.change feature isn't enough for this, because you should be able to schedule multiple changes against devices.

How do you handle a change that adds a new device? How are you storing that data and adding it to device tables?

The concept we've come up with is creating something similar to screlation, a new table that would store device and change data (start, end, change#), open/close flag etc, and display as a vj/table on the change form. Adding devices to a change would add records to that table, then that data could be used for a query to see if there are scheduled/overlapping changes for the device selected. More logic to control closing those records when the change closes. A lot of development but potentially a great solution, with plenty of areas for expansion.

Please let me know your thoughts, or if anyone has any references or documentation of how you support these processes.

Thanks in advance! Malcolm
  • I'm very interested in hearing how others are solutioning this issue as well. Would be nice if HP/PGN stepped up with a work flow to this as it certainly is key to the Change/Config picture as Malcolm indicates.

    John S.
  • Nice solution to a complex issue.
    We rely on Change Advisory Board meetings to spot these scheduling conflicts, but I like where you're going.

    Have you considered adding affected items (children of the to your table as they can also affect these scheduling conflicts.

    I do have a script that goes 2 levels deep into discovering all children & grand-children for a configuration item. I wanted to go 3 levels, but I thought my head would explode. We use the routine to populate affected.items on changes.

    We wrote routines to add devices to ICM from request mgmt, but had to scrub it as users that maintain ICM wanted to continue to use the easy method of adding ICM entries manually (who knew) since they can bring up a similar device, change a couple of fields and hit add. This was easier than filling in all the fields on a RM line item.

  • Hi,


    I woked some time back on integration of release calendar with the HPSM. I saw there are couple of options to identify the Ovelapping changes based on CI, Start date and end date and change co-ordinator etc in the release calendar it is customizable also.