The bottom line appears to be that the current construct of Release and Change is not as ITIL-compliant as BMC believes it to be, so you will have to choose whether you want to stick with ITIL or use the BMC Release package. I have been told that no changes to the current product construct are in anyone's plans for at least the near term (2-3 years), FWIW.
That being said, if one wants to use the product line the way it was constructed (Release --> Change/Activity --> Task), it would probably work just fine in supporting a company's Change and Release processes. But if you try to force the ITIL model (Change --> Release --> Task) on it, it will not support that model very well. A better alternative to that (IMHO) is to not use Release at all, but stick with the current Change/Activity --> Task methodology, which will work for most of the companies most of the time. Rick On Tue, Jul 27, 2010 at 12:03 AM, Mahendra Mahalkar < mahendra.mahal...@gmail.com> wrote: > ** Thanks to all listers participated in this thread as this discussion > really helped me to clear my concepts. > > Thanks & Regards, > Mahendra Mahalkar > > > > > On Mon, Jul 26, 2010 at 8:36 PM, strauss <stra...@unt.edu> wrote: > >> ** >> >> As near as I can tell, Change Management is the process for continuous >> improvement (or evolution) through corrective changes to a service, and >> works at the component level of the services (CIs, assets, processes). >> Release and Deployment Management is more the process for quality assurance >> of all existing and planned services - with a more strategic approach. >> >> >> >> A few quotes from references on Change and Release Management might help, >> since the ITIL v3 diagrams and texts generally seem to place Change >> Management and Release Management adjacent to each other under Service >> Transition: >> >> >> >> Van Bon, Jan, ed. Foundations of IT Service Management Based on ITIL V3 >> (2007): >> >> “Changes can be bundled into a release.” P.238. >> >> >> >> Klosterboer, Larry, Implementing ITIL Change and Release Management >> (2009): >> >> “Release management is like an orchestra conductor, and change management >> is like the musicians.” P.6 >> >> “Change management provides a disciplined approach to implementing IT >> changes. Decommissioning a service, upgrading an infrastructure component, >> and adopting a new delivery process are all examples of changes that should >> be tracked by the change management discipline. Each change is considered >> in isolation and flows through a set of steps, including identification, >> documentation, assessment, authorization, execution, and evaluation.” P.6-7. >> >> “Release management provides a strategic approach to implementing an IT >> service.” P.7. >> >> “…an IT service is a set of components and service assets that work >> together to provide a unique benefit to the organization. Before ITIL V3, >> many organizations used the term “IT system” instead of “IT service.” >> “System” places the focus on IT components, whereas “service” emphasizes >> value to the organization. P.7. >> >> “Service transition consists of the short-term view of change management >> and the long-term view of release management.” P.7. >> >> >> >> So, Release Management is Strategic, and Change Management is >> Operational. IMHO, the ITIL V3 model has now added so many overlapping >> functions to the V2 model, probably to meet new oversight requirements, that >> it is no longer comprehendible. It’s no wonder that the software vendors >> are finding it hard to instantiate the ITIL defined “processes” into >> coherent application modules. I hate to say it, but ITIL is probably >> overdue for a complete redesign, with consolidation and simplification as >> its goals. >> >> >> >> 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: >> arsl...@arslist.org] *On Behalf Of *Rick Cook >> *Sent:* Monday, July 26, 2010 7:03 AM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Change Management question >> >> >> >> ** I was talking to our local ITIL folks about this this morning, and >> their opinion was that BMC constructed the Release/Change relationship >> backward - that Change should be above Release. I have heard others say the >> opposite, so maybe that's true, maybe not, and there was agreement about >> there being sufficient wiggle room that a company could use it either way, >> but that got me wondering why BMC did it the way they did it. >> >> Then it hit me. If they put Release between Change and Task, it would >> have broken up the Change module. So they put it on top of Change. The >> problem with that is that the way they have constructed the relationships >> limits the customer's ability to use it in a Change --> Release scenario, >> due to the fact that while Releases can be related to RFCs, they cannot be >> dependent upon them - the Parent/Child scenario only works when Release is >> on top. That makes the process of monitoring completion of all Releases >> under a Change a manual one. It also makes Tasks almost unusable. That's >> not a major problem for us due to some other process and tooling issues, but >> it will be for many. >> >> So against my better judgment, and with the understanding that it is not >> optimal from a scaling and efficiency perspective, I feel that we will end >> up using a Master RFC controlling one or more Releases, which would then >> optionally control one or more subordinate Changes. I will submit an RFE to >> BMC to enhance the relationship options, but I don't see them changing that >> any time soon. >> >> Rick >> >> On Sat, Jul 24, 2010 at 10:59 AM, Guillaume Rheault <guilla...@dcshq.com> >> wrote: >> >> ** >> >> For the complex situation you described, I think the following scenario is >> the best: >> >> Release --> Change/Activity --> Task >> >> Approvals can be configured for releases, so you won't be missing that >> initial approval. >> >> Also as you know, you can relate task templates to change templates, to >> "standardize" the work to be done >> >> Guillaume >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [ >> arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] >> >> *Sent:* Friday, July 23, 2010 3:59 PM >> >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Change Management question >> >> >> >> ** 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 >> >> _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"
