Minimally Exceptional

Lately, I’m an interesting combination of IT guy and accountant (read: geek and nerd) with this job of mine. While I do perform a lot of accounting functions, more and more I’m picking up IT responsibilities to go along with it. All of this is fine; after all, my bachelor’s degree is in MIS, so it’s nice to feel like I’m actually using the five years of college I endured.

The experience of being kind of a hybrid techie/bean counter has really given me a new perspective – and perhaps a new respect – for both sides of the fence.

No matter where you work, the company line that everyone is expected to tow always sounds a little bit like ‘We’re all part of the same team and we should be acting in the best interest of the company.’ Anyone who is really a part of it, though, knows fully well the the team mentality sounds great in theory, but often deteriorates into ‘our’ team and ‘their’ team. Generally, this mentality often happens when you are dealing with the IT department and, well, anyone else.

Let’s face it – it’s not their fault. IT has a responsibility to make things work and keep them working. So when you have dozens of different ‘user’ departments, consisting of potentially hundreds of individual workstations and systems, it isn’t rare for everything to break at once. Then the IT guy has to prioritize who’s problems to fix when, all in the face of all the users bitching about how their problem is the most important and needs to be taken care of right away. Compound this with a general end-user skill level of ‘I don’t know dick’ and it’s easy to see how us vs. them comes into play – IT guys don’t have the time to educate, and users don’t have any desire to understand. Studies show that IT professionals are highly stressed (if not THE most highly stressed) and this explains why.

We’re in the midst of preparing for an upgrade of our accounting system this week. Additionally, we are converting from a client-install setup to terminal services (just in case you lost the decoder ring: moving from installing software on each individual computer to remote access of the server itself.) Typically, this is a really bad idea – doing both of these things at once means that we will have a much harder time diagnosing problems once we go live. Is it terminal services? Is it the new version of the software? Is it a combination? Who the hell knows?

In for a penny, in for a pound; Regardless of how we got here, we’re here.

Perhaps the hardest part of this process – and what I am absolutely talking about when I say it’s interesting being in the middle – is determining user setup and group policy on the terminal server. All of our users have admin rights on their win2K/winxp workstations, but in terminal services we restrict the access to only the things that they need. So things like the control panel are out, my computer is out, access to c: is out, et cetera. As we move along, it kind of becomes a fight between the ‘us’ and the ‘them’.

From the IT point of view, we want to restrict the terminal server as much as possible so that people can’t screw it up (because people *will* screw it up.)

From the user point of view, back up the damn server daily if you have to, but give me the access I need so that I can do my work – don’t leave me with some crippled half-assed system that doesn’t do what I need it to do, especially when it worked before the ‘upgrade.’

Which point of view is right? Hard to tell. Your users are technically internal customers, so I’m not sure it’s right to break the systems they need to do their jobs. At the same time, your users are often idiots about technology and need to be protected from themselves before they accidentally render said systems useless. A delicate and fragile balance, indeed. If users aren’t willing to adapt and techies aren’t willing to educate and help and be flexible, all you’re going to get is a god damn mess.

Personally, I don’t want to make any more work for the IT staff than necessary, but at the same time, I want to have the kind of functionality that I’ve come to expect from my systems. I can’t think of a good reason to have a software system that is less functional after an ‘upgrade,’ but that’s just me. I tend to think that there needs to be a little bit of common sense, a little bit of cooperation, and a little bit of willingness to evolve for things to really work out well. IT departments need to have a little flexibility and a little extra patience, and end users need to be willing to make some changes to their procedures – that handwritten list of steps you use to run a report in version 2.4 won’t work for shit in version 5.5, so you need to be prepared to run it ‘the new way.’

Let’s be honest – the ‘new way’ is probably better anyway.