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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
