Wow, I just read the CM User Guide again, and you're right - Release is designed to be the parent of Changes and Activities. A quote from page 42: "A release is a collection of related authorized changes to an IT service that are tested and introduced into the live environment together."
OK, then. We have some paradigm-shifting to do on the part of the customer. I think I will wait until Monday to do that - don't want to spoil anyone's weekend. [?] Rick On Fri, Jul 23, 2010 at 2:29 PM, Guillaume Rheault <guilla...@dcshq.com>wrote: > ** > 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>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] on behalf of Rick Cook [remedyr...@gmail.com] >> *Sent:* Friday, July 23, 2010 1:34 PM >> >> *To:* 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>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] on behalf of Rick Cook [remedyr...@gmail.com] >>> *Sent:* Thursday, July 22, 2010 11:36 AM >>> *To:* 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>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> >>>> To: arslist <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 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"_ >>> >> >> _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"_ > _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"
<<347.png>>
