I have no problem with the shift to ITIL - at least the concept is well documented, proven, and taught. Our "IT organization" (isn't that an oxymoron, just like "military intelligence"??) could use a little bit of structuring in how it manages work. If the application forces some of that, it is probably a good thing. You are hitting the nail on the head, as far as ITSM 7 is concerned. Our alternatives are to stick with an older version of the application well beyond its support expiration date (we are already there on ITSM 5.5.1), start developing a complete custom application, or consider other packaged products from other vendors. ITSM 7 is almost impossible to get your arms around - even without Asset my servers are sitting at just over 30,000 code objects; it reminds me of a military helicopter: "50,000 moving parts, all made by the lowest bidder." What makes this complexity even worse, is that no one in the BMC Remedy support organization knows anything about ITSM 7 except for a very few people in application support. Half of the issues we have submitted go to teams who have no understanding of ITSM 7, and can't seem to get it through their heads that the problem is in how ITSM 7 has incorporated some function that they support differently for the rest of the ARS world. The entry points in the Home Page are a perfect example - the ITSM 7 developers used a method unfamiliar to the regular support staff. Many times the support staff state that they will have to obtain access to an ITSM 7 system just to check out what we are telling them - it's an additional step, and a further delay. As to customization, I intend to avoid it (because of the new patching model), but we are going to catch hell from our users over the customizations we were able to make and maintain in Help Desk 3, 4, and 5.5 that they will lose in ITSM 7 because they will not be practical to maintain. Some customization will absolutely be necessary - we keep hitting bizarre things in ITSM 7 that are just going to _have_ to be fixed before we can implement it. For example, even in a submitter locked system, requesters cannot update their own tickets unless they were put in through self-service (requester console). The incident console is making the support staff member who creates the ticket the Submitter, instead of the old Submitter=Requester model that enabled self-service updates by email, web links, or other customer interfaces after a ticket was put in on their behalf. This also affects the new Requester Console - it can only see tickets that the customer puts in for themselves (the rarest kind, in our environment), not the ones they called or emailed in to have placed for them. Another flagrant problem is the effect on the Company menus after you have loaded/imported the DSL - suddenly you have to wade through 2,288 Manufacturer entries in order to find the customer or operating company entries in order to locate a customer. The developers forgot to filter irrelevant types of companies out of the menus in the incident/problem/change customer search interfaces, so we will have to customize that too before the app is reasonably useable. I'm sure we'll get the answer that these behaviors are "as designed," which says something about that design process, but if we have to fix them, then we will have to protect those fixes in the future from patches that might return them to the original state. So far we have only been configuring and exploring Incident, so I expect to find other must-fix behaviors in the other applications as well. On your last point, by far the worst problem is that there is no way to capture the data from days/weeks of application configuration, especially if you plan to use multi-tenancy, if you need to reload the application code with a fresh installation of some module. Usually that means reloading the entire suite since the application updates like 7.0.02 cannot install over an existing installation. Since this application is much more data-driven than ever before, there should be some way of extracting your configuration setting data to an external data store from which you can apply them to a new code install.
Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/helpdesk/ _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CG/SCWOE Sent: Friday, January 26, 2007 10:06 AM To: [email protected] Subject: OT: ITSM Total Cost of Implementation Discussion ** Hi list: I apologize for not being a more active participant of the ARS list community recently...work has had me tied up more in red tape than in real development lately. Anyway, I put this in as off topic, but I think it's only a bit off topic. I would like to get any and all viewpoints on the subject of implementing ITSM vs. another product or a custom product. Specifically, how do you feel about the following points (some are from a devil's advocate perspective): - ITSM 7.0 was overhauled from the previous version to be "ITIL compliant". An organization that does not want to embrace the ITIL model, however, is stuck because BMC only supports so many versions back. Eventually support is dropped on the non-ITIL compliant versions. Thus, doesn't the vendor effectively control your organization's process and not the other way around? What are your thoughts on that? - ITSM 7.0 has some 26,000 code objects (forms, ALs, filters, and escalations). Doesn't that make the tool nearly impossible to reverse engineer? And a bear to customize? - Isn't customization unavoidable...especially in large enterprises with longstanding, proven business practices? - If customization is unavoidable, how do you handle configuration control? That is, how do you know the next version won't wipe out all the work you did on your customizations? All thoughts and opinions are much appreciated. Norm __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
