I would think, Knowing the Air Force a little.. That reprogramming the "old dog" manager who had been there forever mindset -- would be very difficult. Which in turn would break the real functionality of the application in the first place. Otherwise like hundreds of other "systems" the military institutes, some manager somewhere or everywhere will bypass with local policy ignoring Governing policy.
On 1/26/07, Aaron Keller <[EMAIL PROTECTED]> wrote:
** From a company viewpoint, I have always been a proponent of the custom build. ITSM, or any pre-built app, must by its nature be an attempt at all things to all companies. And since all companies are not alike, you invariably end up with a square peg and a round hole. You spend as much time customizing and compromising as it would have taken to develop from the ground up. And you've paid twice (once for ARS, once for the app), and continue to pay twice in the form of support. That's especially true with Remedy. Because Remedy is so customizable, (and is marketed and sold as such) companies *expect* customization. Now, from a developer or administrator viewpoint, is all that extra work really a bad thing? After all, it keeps them their jobs. I'll leave that for another discussion. To your points: 1 - I don't believe the vendor controls an organization's processes, but the ITIL standards themselves control an organization's processes (and a vendor's). And because the ITIL standards derive (at least in part) from the organizations, it's really just a peer-pressure situation among companies instead of high-schoolers. For those companies that don't embrace ITIL – don't upgrade. Instead, go custom. 2 – Of course it makes it difficult to reverse engineer, but not really to customize. One doesn't need an understanding of the entire product to customize it, only an understanding of the workflow surrounding the item to be customized. And through logging and the search DB, that's relatively easy to figure out. 3 – Yes, customization is unavoidable. 4 – You handle configuration control with a change control process. The basics are: 1) no changes without a change control record. 2) The change control record tracks what was changed, and why. 3) EVERY changed object references a change control record. When it comes time to evaluate an upgrade, you then have a list of changed items to compare to the list of "What's New". It's not easy, but it's straight-forward. Also, *when* you customize, try to do it in a way that will play well with future upgrades. Such as: never delete, just hide. And don't change workflow, just disable and replace. (By the way, you'd never have that problem if you built custom.) -Aaron * Email: [EMAIL PROTECTED] ------------------------------ *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 11: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 SunCom is the wireless company that's committed to doing things differently. Things we want you to know. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
-- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
