Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..
287 views

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
0 Likes
3 Replies
Highlighted
Absent Member.
Absent Member.

Re: Processes for big/complex change/device environments

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.
0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

Re: Processes for big/complex change/device environments

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

-Larry-
0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

Re: Processes for big/complex change/device environments

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.

 

Thanks,

Narendra

 

 

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.