It would seem that in the instance(s) where ITIL recommendations differ from corporate or IT wishes, there's something some aren't getting.
The corporate sponsors of the ITIL initiative were persuaded that it was a good way to run their company. In fact, they were persuaded that it was a BETTER way to run their company than the one THEY put in place. We've all seen C-teams duped by software vendors before into thinking Product X is the greatest thing since sliced bread, but this is different. Purchasing software is seen as a means to accomplish the company's goals, using the leadership's methods, thus validating the leadership's decision making. Moving to an ITIL functionality is almost the opposite - it INvalidates the direction the leadership had been taking. And yet, despite the fact that C<ITFE>Os don't like being proven wrong, more and more companies are biting the bullet and changing the way they conduct business. The sales pitch is, in essence, "You've been doing it wrong all these years. Here's how to do it right (and, BTW, we sell software and services to support this right way)." So to validate Scott's point, if you have reason to believe that there is a better way to generically process business functionality than the one ITIL has developed over a couple of decades, feel free to point out what that is, and to defend it. If you can't do that, the path of wisdom might be to open one's mind a bit more and see how it can work the ITIL way. It's like when I was in boot camp. There were things I was going through that I didn't understand at the time, but I had enough brains to keep my mouth shut and my brain open, figuring that at some point, I would understand, which I usually did. Most of the resistance to ITIL is that of people not being willing to put down the old tools (thought processes, business practices, paradigms, etc.) and give the new ones a chance. Lead, follow, or get out of the way. There are plenty of companies one can work for who will never do things the ITIL way, and we're all free to choose which we prefer to work for. I choose the future over the past, and I can make money on either side. Rick On Tue, May 6, 2008 at 8:00 AM, Kevin Pulsen <[EMAIL PROTECTED]> wrote: > ** The original question was asked about ITIL and ITSM 7. > > BMC is suppose to have ITSM 7 extremely ITIL compliant... how can one use > ITSM 7 and expect the users not to follow ITIL in all areas of the IT > organization? > > Yes, there will be many o-departments boasting about 'We don't need to > follow ITIL, we are a different company and we do things differently here' > > True, a boat manufacturing company might be different from a mortgage > broker, but business practices are pretty much the same across the board.... > that's why ITIL was made! > > AR Server is like that famous burger slogan, you can have it your way, as > long as you write the code, yourself. If you don't want to follow ITIL, > don't get ITSM, develop your own applications. > > Anyways, if you want to use your head to get nails into a 2x4, go right > ahead... > I just think a hammer is 'best practice' > > Kevin P. > > > > > > **'Norm, > Have you run into this situation: ". . . But then when you challenge those > decisions by asking, "Why are we doing > XYZ?" you get a very vocal and forceful, "BECAUSE ITIL SAYS SO!" > > If so, how did you handle it. If not, how would you handle it? > > Scott Parrish > IT Prophets, LLC > (770) 653-5203 > www.itprophets.com > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 > CS/SCCE > Sent: Tuesday, May 06, 2008 10:19 AM > To: arslist@ARSLIST.ORG > Subject: Re: ITIL Remedy > > Just a few observations on this point...please forgive me if I sound a > bit sardonic. > > First, did anybody really need ITIL to tell them to do what Ben > describes in the first paragraph--i.e., Service Desk (I refuse to call > it that--it's the HELP Desk) should be the first point of contact for > customers, incidents are overseen by the Help Desk, the Help Desk > forwards incidents to appropriate groups, and the Help Desk follows up > with customers once the ticket is resolved? I mean, come on--we were > doing that 15 years ago (or longer). That's, like, Help Desk 101. > > Second, people repeat over and over again, "ITIL is just a guideline...a > framework...some best practices...a guide..." That might be fine if > you're the person making all the decisions about what the ITIL processes > are going to be and how they will be implemented, but if you're just the > *implementer* following the directions of a myriad of bosses who are all > gung-ho about ITIL and about being "ITIL certified" you are not at > liberty to use ITIL (or any other disciplined process framework flavor > of the month) as you so choose. You do what you're told. Other people > make the decisions, and oftentimes those decisions make little sense. > But then when you challenge those decisions by asking, "Why are we doing > XYZ?" you get a very vocal and forceful, "BECAUSE ITIL SAYS SO!" > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Brian Pancia > Sent: Tuesday, May 06, 2008 8:57 AM > To: arslist@ARSLIST.ORG > Subject: Re: ITIL Remedy > > ** > > One issue many organizations face is taking ITIL for gospel. ITIL is > just a framework/guide for organizations to use to define their own best > practices. When you tag positions like Owner or Manager to the process > it leads people to believe that these are physical positions when they > are really functions of the process. Everyone is correct in saying that > the Service Desk should be the central point of contact for customers. > A function of the Service Desk is to oversee the Incident Management > Process. However, an incident may pass through several support groups > and these support groups are also responsible for following the process. > The service desk is there to create a ticket (hopefully resolve too), > forward to support groups when necessary, be the POC for the customer if > the customer needs to call in for additional questions/status updates, > and follow-up with the customer once the incident is resolved. > > Now with Remedy some of these functions may be automated within the > system. Once a ticket is resolved an email or survey may be sent out to > the customer, which would constitute the service desk contact to the > customer. Also, SLAs and OLAs may be put in place to ensure that the > incident is handled in a timely manner. This allows the system to take > over much of the functionality of the process flow. > > So as you implement the ITIL processes look at a lot of the things in > ITIL as functions that are performed during the process. Every > person/group involved in the process needs to understand the functions > and may be responsible for doing the function at some point in the > process. This was one of the things that ITIL v3 tried to address and > one thing that the writers will stress. Remember ITIL is just a > framework/guide to help organizations build their own best practices. > Just because the sample flow diagrams and functions are in the ITIL > books does not mean that organizations have to follow them to a T. Use > what works and makes sense for your organization. The more complicated > you make a process the less likely it will be followed. > > ------------------------------ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now.<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>__Platinum > Sponsor: > www.rmsportal.com ARSlist: "Where the Answers Are" html___ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
