Well, having Release at the top allows things to flow Release --> Change/Activity --> Task. Putting Release below Change eliminates the ability to use Tasks, since they can't be directly subordinate to a Release.
So our options for a dependent (i.e. Parent/Child) flow are: Release --> Change/Activity --> Task --OR-- Change --> Task --OR-- Release --> Change(s) Do I have that right? Rick On Fri, Jul 23, 2010 at 3:00 PM, Guillaume Rheault <[email protected]>wrote: > ** > 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) [ > [email protected]] on behalf of strauss [[email protected]] > *Sent:* Friday, July 23, 2010 2:53 PM > > *To:* [email protected] > *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: > [email protected]] *On Behalf Of *Guillaume Rheault > *Sent:* Friday, July 23, 2010 1:29 PM > *To:* [email protected] > *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) [ > [email protected]] on behalf of Rick Cook [[email protected]] > *Sent:* Friday, July 23, 2010 2:19 PM > *To:* [email protected] > *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 <[email protected]> > 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) [ > [email protected]] on behalf of Rick Cook [[email protected]] > > *Sent:* Friday, July 23, 2010 1:34 PM > > > *To:* [email protected] > *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 <[email protected]> > 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) [ > [email protected]] on behalf of Rick Cook [[email protected]] > *Sent:* Thursday, July 22, 2010 11:36 AM > *To:* [email protected] > *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 <[email protected]> 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 <[email protected]> > To: arslist <[email protected]> > 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"_ > _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"
