Making the Most of IT support? 107
wetfeetl33t asks: "On Slashdot, we've seen quite a few stories about employees who are unhappy with their company's IT department, or are seeking advice on how they can whip their company's IT department into shape. So, enough of the complaints about the supposed stupidity of technicians, the incompetence of sysadmins, or the excessive network down time. A better question is: how can users work peacefully and effectively with their IT department and make the interaction between the IT people and other employees as productive as possible?"
Get a Service Level Agreement... (Score:3, Informative)
- Systems/Services will have a criticality assigned to them
- business critical (BC)
- department critical (DC)
- service critical (SC)
- non-critical (NC)
- The level of criticality will determine levels of response time/support expected for that system or service
- (BC) Reporting person is contacted by IT professional within 10-15 minutes with an assesment made to determine the nature of the problem and contact appropriate person(s) including possible management to get IT personnel immediately working on the problem
- (DC) Reporting person is contacted by IT professional within 10-15 minutes with an assesment made to determine the nature of problem and management contacted to determine if action is immediately required (if after normal hours of operation) or if it can wait until normal business hours and worked on by appropriate IT professionals, BC events take precidence
- (SC) Reporting person is contacted within 10-15 minutes (normal hours) or next morning by an IT professional with an assesment made to determine the nature of the problem and the appropriate IT professions start working to fix the problem BC, and DC events take precidence
- Processes are created for tasks
- Process for adding accounts
- Process for installing software
- Process for purchasing equipment
- Process for installing equipment
- Process for moving user desktop equipment
- Process for recovery requests
- Process for foo bar
- Expected levels of uptime are agreeded upon
- Budget requirements are tracked (i.e. tasks themselves are tracked so that time spent installing xyz piece of software on y number of systems can be used to show that X number dollars were needed for that task)
These are just some suggestions. This helps both the IT department as well as the user community because actions are tasked and tracked and accounted for. Budgets are also kept track of so that the money spent can be tracked (like when a Department Head starts yelling that the IT department is costing too much overhead the IT department can show that they spent $500k in time/manpower/infrastructure moving that Department Head's engineers to the shiny new building because he/she wanted the big office on the 4th floor).Re:Isn't it obvious? (Score:2, Informative)
It all comes down to your support levels, a sys-admin shouldn't be handling 1st level support calls, he/she needs to be doing what they do best. Likewise a 1st level support person shouldn't be trying to debug a large network issue, they should be noting it and passing the details up the tree.
For smaller companies that have less staff this may be harder, but the issues *should* be less as the people working there *should* be able to see the goings on much easier.
But at the end of the day it all comes down to how you manage your users. If you've got a hot headed un-happy IT dept. hating person, do a couple of little things here and there, even if he's angry, speak nicely etc etc, if he abuses you hang up, call his manager for some advice. There are ways of handling difficult people. And if you get the more vocal people onside, others tend to follow.
Re:Tell them to THINK (Score:3, Informative)
A few days ago I received a laptop from the IT department for a business trip the day after. I told them to install some software on it. Net result was that I received a laptop with the software I requested - but without a login, and the software wasn't activated.
If the IT department thinks along with you those things shouldn't happen.
A very big question I would ask in this scenario is this: Who put it off to the last minute, and why? There may be a very good answer to this, but one thing that is generally not understood is that system builds never go smoothly. It is absolutely mandatory that enough lead time be in place that the little problems that will be encountered can be squashed before the deadline.
This entails cooperation on the part of both parties. The user needs to make the request in a timely fashion; the IT guys need to act on it in a timely fashion. The user should perform acceptance testing well before the facility is needed (in this case, a day or two would probably be OK). If something goes wrong in the acceptance testing, then the IT guys need to act on it straight away.
The IT world is frought with problems that refuse to solve under stress. Yes, thinking is a good idea, but it is no substitute for timeliness.
How? (Score:4, Informative)
Simple.
STFU.
RTFM.