How Do You Manage Requests in Your Organization?

StormShadw asks: "How do you manage IT requests in your organization? There seems to be a lack of software solutions specifically designed to track requests. Most that I've been able to find are either problem tracking systems or bug tracking systems, neither of which completely fit the 'request management' model. I work for a large bank and my department supports all of the internet web presence and online banking applications for the company. We receive hundreds of requests a week (my department has 51 people in it), typically through a variety of mediums (phone, email, hallway conversations). It's impossible to manage all these efficiently when there is no centralized system. What's the solution? What do you all use?"

"There is a 'workflow' aspect to many of these requests: we do our thing, then pass it off to the UNIX admins, firewall folks, or DBAs to process another portion of the request. Ideally, I'd like to have a web based system where our customers (internal lines of business) can submit their requests, get status, etc. We would also manage a queue of work through a web interface, assigning requests internally or to other teams we work with. Email notifications could be generated when requests are completed."

Comments

Re:RT

[SuperBanana]

We use request tracker. http://www.gnu.org/directory/rtracker.html

So do I, across three companies now that I've worked for. It's eccentric, to say the least.

• "Killed" tickets aren't "killed", they're only -marked- killed. Ie- no way to delete tickets. No magic button for the admins to click to delete 'killed' tickets- you've got to delete them by hand in SQL, something management is uneasy about doing on a production system.
• No way for anonymous users to check on the status of their ticket- you've got to grant them rights, or give guest rights to -everyone- to see -everyone's- tickets(and that leads to why-is-my-request/why-is-their-request crap)
• Horrible support- on several occasions I've asked in-depth questions and not recieved so much as a peep from anyone; sometimes I've posted 2-3x. The authors are clearly busy consulting- not supporting.
• Users can bring down the entire system to a halt if you're using MySQL, the default/best supported DB. Because tickets never get removed, and the default search parameters are -all- tickets and -all- queues, a single search can take MINUTES to complete on a SMALL db(20-30,000 tickets).
• Clunky/confusing interface. Things that should require one click require several. Functions have non-intuitive names. Etc.

It's not nearly as bad as Big Brother, but it's close, at least in terms of eccentricity. If I had to recommend a system, after almost a half decade of using RT, I'd flat out tell them to try something else first, and leave RT to last to evaluate. Bugzilla certainly does sound interesting, though I have no experience with it.

Re:Remedy

[lushmore]

My company uses Remedy also. The people who decided to use Remedy paid some consultants to help with the setup, then it has done nothing but rot since then. The new cool features in later versions are untapped, and the changing support structure is not reflected in the schema. Whatever system you go with, make sure someone is committed to keeping it maintained, or that the system is easy to modify. Like most tools, someone has to keep it sharp.