Chris, good point. In the end, the main issue that needs to br definrd and standardized is the usage of the application. The BMC Remedy Change Mgmt and Release Mgmt are loosely coupled OOTB, so various ways of usage can be defined, and that is usually the most difficult part in change mgmt implementations. Once you standardize usage, you can create business rules to lock down the app (customization really), to enforce such usage.
Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of strauss [stra...@unt.edu] Sent: Friday, July 23, 2010 2:53 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** Could the proper sequence be that an initial RFC would be considered for enterprise application versus local, and if approved for the enterprise you would create a parent Release for it, followed by additional child (to the Release) Infrastructure Changes and Activities for the rest of the enterprise? Or if the RFC was going to stand alone, for local application, then it still might be appropriate to create a parent release and add more Changes or at least Activities that were going to be necessary in conjunction with the action on the original RFC. Larry Klosterboer’s book “Implementing ITIL Change and Release Management” is the newest guide I have found, but it is not specific to BMC ITSM (from IBM Press) so you have to figure out how to apply the generic concepts in your environment. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Friday, July 23, 2010 1:29 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** hi Rick, I understand the situation. But that parent change could be a release entry too. My understanding of the philiosphy behind the BMC Release Mgmt module is that the release entry is intended to be the parent of changes, i.e. the actual implementation changes to production... So the starting point is the release, not the change. From the release, you create child changes that are scheduled within the release. So it seems we have a terminology/nomenclature issue here, since most people would think the release is downstream of the change, when in fact it is not, it is upstream. Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 2:19 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and >then the Child approvals take over until they all are completed. So from a >corporate level, I can look at the Parent RFC and from it, see the status of >all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault <guilla...@dcshq.com<mailto:guilla...@dcshq.com>> wrote: ** from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change.... Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault <guilla...@dcshq.com<mailto:guilla...@dcshq.com>> wrote: ** Rick, Having "parent" or "master" changes that have days or months for implementation may not be a good idea, because it is going to mess up your change calendars, whether your OOTB ITSM change calendar, or any other calenda (BTW, take a look at the Kinetic calendar, it is awesome and really simple to set up), unless you filter out this "parent" changes by the change type or something else. Other things that will be messed up are is the new 7.5 collision detection and impact analysis. I am running into this specific situation right now and it is not clean... it is actually cludgy. I advise you to stay away from that scenario as much as possible from day one. I agree with Roger that these kind of parent changes should find their place in the release module somehow, and not in the change module. This implies of course using another module, training,etc, but in the end it will be much cleaner from a process, data and reporting perspectives. Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Thursday, July 22, 2010 11:36 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Change Management question ** We intend to log the actual work in Release, but we want local RFCs to track the scheduling of the change, which would have different acceptable maintenance windows at each location. So the parent change would give, say, a 30 day window for implementation, and each child RFC logs where within that window the individual location will do their change. Does that seem like a sound structure, Roger, or should everything underneath the parent RFC be based in Release? Rick On Thu, Jul 22, 2010 at 11:30 AM, Roger Justice <rjust2...@aol.com<mailto:rjust2...@aol.com>> wrote: ** This would be better handled by Release. I know that the parent in either case cannot be closed until the children changes are completed. -----Original Message----- From: Rick Cook <remedyr...@gmail.com<mailto:remedyr...@gmail.com>> To: arslist <arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>> Sent: Thu, Jul 22, 2010 11:26 am Subject: Change Management question ** We are looking to use CM (7.5) like this: One Project or Release RFC that would dictate what needed to be done at multiple locations. Then subordinate RFCs would be created at each location to handle the exact scheduling and implementation. My question is whether the Parent/Child RFC process works like the RFC/Task process, in that closing the last task in an RFC auto-closes it and/or if the Parent RFC is prevented from being closed until all of the children are closed. Just trying to get a handle on the degree of dependence or control the parent RFC has on the subordinate RFC, and vice versa. Rick _attend WWRUG10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
