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