BSM Remedy: its not just awful, it's Godawful.

[catsidhe]

Seriously, what the hell is wrong with BSM Remedy when the client, which is a glorified web page and must be accessed through a browser (although to be fair, the previous version's dedicated client was, in essence, a glorified and fundamentally broken web browser with pretentions of adequacy), uses almost as much memory as an entire running VMware instance of WinXP?


BSM Remedy: levelling the playing field by making simple jobs as hard to do as complicated ones, and complicated ones impossible.

BSM Remedy: because the person designing the system has no idea what you do, and it shows.

BSM Remedy: because there's nothing like an ITIL-compliant job tracking tool; and this is, indeed, nothing like one.

BSM Remedy: because if the person who designed your implementation knew what they were doing, they'd be doing something important instead of designing your implementation.

BSM Remedy: management hates you and wants you to suffer.

Comments

[felinophile]

I am immensely pleased I no longer have to use this beast. That was really useful training.... Now if only I could get removed from the notifications list.

[eagle]

We used their unsupported Perl API to write some stuff that poked things into and pulled things out of their Help Desk product sufficient to process tickets on a day-to-day basis, put a remctl wrapper around it, and then I stopped using their god-awful web interface almost completely. I still have to look at it every once in a while and marvel.

I hear the next version is supposed to have an actual web services API instead of an awful C thing, against which you could in theory write something sane.

[catsidhe]

Some of the guys here wrote something similar. CGI and commandline interfaces, more tolerable searching, the presence of individual preferences, all sorts of nifty stuff.

Then we got a team leader who dictated that we weren't allowed to use it and we had to use the provided interface. That we weren't to use any bespoke interfaces to it at all, in fact.

That man was a complete waste of oxygen (who is, as I repeatedly said under his regime, batting zero for three out of Leadership/Personal skills, Bureaucrat skills and Technical skills). But the habit remains.

And to be fair (which pains me to say about that underwear stain of a human being), there are things which are damn near impossible to do without going into the standard interface. Mainly because the mouth-breathing morons who designed the processes have not only Used All The Possible Options!, they've done so in a confusing, internally incoherent and perpetually changing way. (We get Incidents, Work Orders and Tasks, with no consistency as to which is what, and different interfaces and workflows for each. And it's almost impossible to sort out even what's happening with a Task, let alone doing something about it. Change Requests are universally reviled, if only because they're even more painful that everything else to work through, and just generally it seems to have been assembled by demented gibbons on crack, but working in a committee.

Or, we were forbidden from using non-standard tools to interface with Remedy because there are some things you just can't do through them, but to counter that, you can't do most of those things through the standard portal either.

[eagle]

Oh yeah, Tasks are unbelievably painful. I think the fact that we tend to just not respond to them because they're so much more difficult to do anything with than Incidents is discouraging people from sending them to us.

We have some email interface for the Change Request stuff that I use for approvals. I still create new requests via the web interface since I've not gotten around to working out how the email form works, and it usually takes five minutes just to do the data entry.

I'm fairly sure the Change Request web interface was specifically designed to have a pattern of repetition of fields, obscure and unrelated groupings of fields, and interfaces spread across multiple tabs in exactly the way most likely to drive humans mad.

[ideological_cuddle]

My immediately-prior gig was using Remedy (well, I *think* it was, but it's possible that I am misremembering) and it was set up in a vaguely sane-ish manner so it wasn't too painful to deal with.

We all used the stock interface for most things, all the assets were logged in it properly, and we stuck with just Incidents and Change Requests so I've no idea what this "Tasks" business is about.

Helps that it was a freaking huge corporation with processes and training out the whazoo, specifically aimed at lowish-skill workers. So while it was more complicated than I'd have liked, and we had custom interfaces for some specific things, it basically worked tolerably.

Certainly better than the system at the immediately-prior place, anyway.

Here we just use Basecamp. Everything is a project, the ops-ish side is miniscule so we just use a specific project for that.

[pursuedbybear]

Yeah, it's pretty special. I've been dealing with it in my new(ish) job, and I'm astonished at how it manages to maximise the effort involved in finding out what it is that you're actually expected to do with a particular job.