Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm looking to implement ITSM in a two-man IT department. We have a web-based workflow system where five request types have been defined that end up in our department. The rationale behind the division of the request types is basically for categorization, but the users often don't understand which request type to pick.

I'm planning to simplify the system by making only one request type visible to the users and then we will change the type if necessary. But instead of separating by technical area (the current request types are Computer Support, Web Support, ERP Support, CRM Support, and Analyst Support), I think it would be better to separate into Incident, Problem, Change Request, and Service Request. The old way of categorization will be replaced by linking each request to a project which represents the associated service, and this will be done by us instead of the users.

Now, our workflow system displays all the requests assigned to you in one giant list. It is possible to customize the fields which are displayed so that you could see which are incidents vs. change requests. I have been considering writing my own front end to list each request type in a separate grouping on the screen. This made me wonder about prioritization of requests. Each request is assigned a priority between 1 and 5, so a Priority 1 Change Request is more important than a Priority 3 Change Request. But is a Priority 2 Incident more important than the Priority 1 Change Request because it's an incident? Because there are only two of us in the department, I don't think we can be working on change requests while an incident is happening. I've always been of the opinion that you should fix things that are broken before building anything new. Or am I out to lunch on this? Should we be ignoring the request type and working based off the priority level alone?

If I am heading down the right path with prioritizing all Incidents ahead of everything else, how should I prioritize the other request types? My initial inclination is to do Service Requests next because I expect them to be fairly quick, followed by Change Requests and finally Problems. However, I'm slightly concerned that by putting Problems last, they will never be investigated. Maybe the order should be Incident, Service Requests, Problems, Change Requests?

share|improve this question
2  
Just my 2p here, but that seems a mighty complicated setup for a 2 man department. –  Ben Pilbrow Aug 6 '11 at 14:42
    
I agree with Ben: This sounds like you are going to spend more time categorizing your work than you spend actually doing it. One queue should do it, together with a time management system that allows you to do project work regardless of current problems or incidents. –  Sven Aug 6 '11 at 15:12
1  
@Scott - Just for context, I am also in a 2-man IT department. We have a basic ticketing system which has some broad categories (General/Other, Printer, PC Hardware, Outlook, Internet etc.) and is basically so we can tie tickets to assets & people and leave notes, in case one of us needs to take over the ticket. We don't have things like incidents, problems, change requests. The basic idea is anyone unable to do their work is a priority, then people who have annoying problems but are still able to work, then other random bits and pieces, then projects. –  Ben Pilbrow Aug 6 '11 at 15:33
3  
My best advice to you is to try something relatively simple and see how it goes. If it needs tweaking, then do so and run with that for a bit. Wash, rinse and repeat until you have something that works for you. Don't try and make your processes fit around something else, be very selfish about it and do whatever is easiest and most productive for you and your department to get stuff done. –  Ben Pilbrow Aug 6 '11 at 15:35
    
Take care not to put an eye out with the pointy hair. You're way overmanaging things (and this comes from someone who likes things to be strongly managed). –  womble Aug 6 '11 at 23:12

1 Answer 1

up vote 5 down vote accepted

I was going to just leave this in comments, but actually I'm going to post an answer because while I think you have good intentions, I think you're going about it in a more complicated manner than you need to.

It is good that you are planning some sort of ticketing system, and I am of the opinion that for anything more than about 20 computers it is a good idea to help keep track of things. What you need to bear in mind is that helpdesk systems come in many shapes and sizes ranging from a glorified list of tickets to very complicated systems with many categories, priorities, assignees, escalations, SLA's and dozens of other bells and whistles. The larger and more segregated your IT department is, the more benefit these more complicated systems have, but for smaller departments they can be more of a hindrance than anything else.

For the sake of comparison I also work in a 2 man IT department, and as such do a bit of everything, so too many different options on the helpdesk would just get in my way. We have a relatively simple home-grown helpdesk which has a user facing side and a technician facing side.

The user facing side has a minimal number of fields so as not to scare them off with information overload (title, category, priority, affected asset tag, problem description). Any and all IT issues are logged here, we don't have different systems for change requests, service requests etc. Our categories are also intentionally broad, again so as not to confuse matters (Computer hardware, Printer problem, Outlook, Internet, General/Other).

The technician side has a few more fields, but is still not very complicated (assignee, status, follow-up date). It allows us enough flexibility to categorise tickets (mainly for reporting purposes) but doesn't get in the way of actually fixing the problem. We are able to leave comments on the ticket showing what we have done, and if one of us needs to work on the others tickets, we know what has already been done.

The main goal of our helpdesk is to keep track of the problems our assets are having (and who is creating the tickets) so we can see what assets are being most troublesome or what people may potentially have training requirements. We don't have anything complicated like categorisation of incidents, problems, service requests, change requests etc. - that would be unnecessary for us, everything comes in as a ticket and we deal with it as appropriate.

If you want a comparison of priorities, ours are generally as follows. The user has the option to set a priority when they create the ticket, but we also have the ability to re-align it with reality (we all know one user who creates priority 1 tickets for absolutely everything :P).

  1. Anyone who is unable to work
  2. Anyone who has a problem but is still able to work
  3. General day to day stuff and random things thrown our way
  4. Project work

In short, yes you probably should implement some sort of helpdesk system, but maybe not something as complicated as you're describing in your question. Ultimately, you need to interact with this system every day so it needs to be as streamlined and easy to use as is practical for you. Make the process work for you, don't try and work with some process designed for IT departments of dozens. If you're unhappy with any part of the process then change it a bit and see how that goes and keep refining it until you are happy that it is working efficiently for you.

share|improve this answer
    
This is roughly how we're operating right now, but we've never explicitly stated as such so it feels like we're flying by the seat of our pants every day. –  Scott Aug 9 '11 at 20:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.