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 <[email protected]> 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: > [email protected]] *On Behalf Of *Rick Cook > *Sent:* Monday, July 26, 2010 7:03 AM > > *To:* [email protected] > *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 <[email protected]> > 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) [ > [email protected]] on behalf of Rick Cook [[email protected]] > > *Sent:* Friday, July 23, 2010 3:59 PM > > > *To:* [email protected] > *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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
