We are on 7.5 patch 4, and I see "Release" in the Relationship Type on the Change form, and see "Infrastructure Change" in the Relationship Type field on a Release record.
Rick On Fri, Jul 23, 2010 at 1:38 PM, Roger Justice <rjust2...@aol.com> wrote: > ** I tried to create a child Release to a Change and it is not lited as an > option on the Change Relationships tab. This was ITSM 7.6 no Patch. > > > > -----Original Message----- > From: Rick Cook <remedyr...@gmail.com> > To: arslist <arslist@ARSLIST.ORG> > Sent: Fri, Jul 23, 2010 1:34 pm > 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"
