That would be nice, wouldn't it! I believe that there would be some areas of disagreement between us and him. I have no problem engaging in discussions with people with opposing points of view, because I always feel I can learn something. If the Product Manager has the same attitude, we would love to engage in some discussion here with him for the mutual benefit of BMC and its customer base. I won't call him out by name, but if someone at BMC is watching, let him know we'd like to hear from him, OK?
Rick On Tue, Jul 27, 2010 at 9:25 AM, Guillaume Rheault <guilla...@dcshq.com>wrote: > ** > I still hope that the Change Mgmt product manager at BMC would chime in > this discussion, in the same way that David and Doug have when questions > about ARS pop-up , to at least explain why things were done a certain > way....and what is the recommendation. > As more companies use the OOTB applications and people in those companies > become ITL v3 Foundation certified, this kind of discussions becomes more > and more relevant. > > Guillaume > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Tuesday, July 27, 2010 9:18 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > ** 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"_ >> > > _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"
