Thanks for all the responses.... The real problem here is to some extent a policy/procedure one. The customer is a large US Federal government organization. Their position is simple: A COTS package should have working features. Bugs and interface items that are clearly confusing (ie, this case is a perfect example) should be fixed by the software manufacturer. This prevents them from putting in costly custom fixes that may have unintended consequences, etc and be hard to upgrade. Philosophically I think this is a pretty legitimate position. We have tried very hard not to customize in any way that will hurt upgrades. Most of our customizations are externalized - ie, you could export them, import them on a new server, and with minor tweaking have them up and running in very short order. It's been a challenge but also very rewarding - at this point I'm pretty sure I could write a white paper (more like a book really) on the pitfalls one can encounter customizing (as I'm sure many other listers could as well.) This philosophy however has consequences.
First, the customer is completely at the mercy of BMC's release schedule for fixes. We can of course push stuff up the chain and such to try to get items fixed earlier (and get hotfixes that will be included in future patches. This has happened several times. This is a big BMC customer so they do have some sway there. But it also puts the customer's release schedule at the mercy of the fixes. If we are waiting for a certain fix we rarely have a timeline for it and it makes planning very difficult. Plus we have no way of knowing what will or will not be fixed until a patch is released. In this organization we have the IT department which is fulfilling a request for another department for a case management system. It makes the IT department look bad when "I don't know" is a common answer to when a specific bug will be fixed. So - could I fix this? Sure - it's pretty easy really. But I don't know what else would break...and I'd be violating policy. William Rentfrow Principal Consultant, StrataCom Inc. [EMAIL PROTECTED] 701-306-6157 C ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Bloom on Sympatico Sent: Thursday, October 16, 2008 6:49 AM To: [email protected] Subject: Re: What's a bug anyway? (Kind of a rant...) ** First check the list of known bugs. Then report it as a bug. If they (BMC) think it is an RFE, they will let you know and Then you fill out a form and get it back to them. Then decide how you will provide a work around for your client based On whether you can wait for BMC to actually fix the bug or decide to Implement the RFE. Given their overall strategy to get everyone away from The native client towards the web, I would not be surprised if that is already Part of ITSM7.5 ... Daniel Disclaimer: I know nothing about what is or is not in ITSM7.5 The above is my opinion as me, and as no one else ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: October 15, 2008 4:11 PM To: [email protected] Subject: What's a bug anyway? (Kind of a rant...) I'm torn whether or not to report some things to BMC as bugs. For example, in IM 7.x the form HPD:Search-Worklog is an OOB join form that is used in the "Advanced Search" functionality from the Incident Nav Bar (when you are in an actual Incident). This allows you to search a join form of Work Log entries + Incident Info. Here's the problem - if you are on the Mid-tier and do a search and then select multiple results list items and choose the "Report" button you get dumped to the standard (ad hoc) report console for the web. The field selection list in there shows all fields from the Join form (including those not displayed in any of the views). That gives us multiple entries for fields like Submitter, Submit Date, etc etc etc (all the usual suspects). Knowing how Remedy works I'd expect this - but I still would call it a bug. It's definitnly an interface design error. However, if I reported every instance of this in the application I suspect it would run in to the hundreds of occurrences. On the other hand I'm pretty much obligated to report it as a bug since I am advocating for my customer and this makes the report interface unusable. They do not know which field to use in the report. Since they are interested on reporting on all Work Log entries for a particular problem, including the submitter and the Work Log Submit Date they legitimately can not tell which is which. And since they only have web access they can't exactly go check other than through trial and error. What do YOU do with this sort of problem? William Rentfrow Principal Consultant, StrataCom Inc. [EMAIL PROTECTED] 701-306-6157 C __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __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"
