Monday, September 15, 2008

4.2 - Bureaucratic mumbo jumbo

I never knew the origins of the concept of bureaucracy. Truth be told, I never cared. Turns out, it's more interesting than I thought. Reading Weber's perspectives, I can see how it's well-intentioned. There are many inherent strengths throughout Weber's points; however, implementation has proven to not be so straightforward.

Most notable of my dislikes of what many would consider a bureaucratic process is the concept of the problem ticket. When we have a problem with our computer, we open a problem ticket. We can't just call deskside support directly... no, that'd be too convenient. Instead, we log on to an archaic web interface, filling out literally 2-3 dozen boxes of information. This form is then sent to a queue in Brazil. Hopefully (but not always), Brazil operations team sends it to the proper queue back in San Jose. This team then fills out accounting forms for which deskside personnel will take care of which tickets and at what time. Deskside workers rarely show up on time, not due to lack of effort, but because one employee with a hard problem pushes their entire schedule back. After fixing a problem that takes less than 5 minutes, the deskside person needs to fill out a long form stating specifically what was the problem and what the solution was. The form then gets routed back to the ticket initiator, then finally back to the deskside person to close it out. A couple total man-hours of work for less than 5 minutes of actual work.

Looking at this process, it is easy to see the noble intent. We open a ticket to properly note what the problem is and not cause confusion. Rather than deskside fielding calls, Brazil operations team acts as a dispatcher to facilitate this process so deskside may focus on their job. Deskside's scheduling forms are a method of accounting for their work and claiming labor against the specific department who use them. Finally, both the originator and deskside personnel need to fill the forms to ensure a proper resolution has taken place and a paper trail in place in case of any future discrepancies...

Yes, in each instance, it makes sense. Yet, all together, it makes for a horribly inefficient system that slows things down. I got confused a couple times just typing this out! Not only do we lose the man-hours dealing with the processes, but also the downtime of machines waiting to be serviced... while the ticket is being routed from queue to queue. Weber has noble thoughts, but bureaucracy is difficult to implement well.

Don't get me started on my government job...

2 comments:

Janet S. said...

I understand your frustration with submitting problem tickets and negotiating hierarchical communication. However, I have personal experience with a successful problem ticket system and would like to argue for it's validity.

I worked in a small company of ten employees. Everyone sat in the same room and worked at their individual computers. I knew the primary programmer and could ask him for help whenever I wanted. However, we were all instructed to complete problem tickets when we discovered an issue with the developing software. (FYI, I was a technical writer for the software in development).

Although I could turn around in my seat to talk with the programmers, there were specific reasons for submitting a ticket. 1) It helped document previous problems, 2) We could supply more detailed information, and 3) When another programmer came to work, he/she could check the status of prior tickets and could resume the technical programming.

Although bureaucracy seems confusing and time-consuming, there are often many good reasons for implementing it. We have to step back and ask ourselves: Is the current bureaucracy efficient? How can we make it better? When bureaucracy continues to change in a state of reflection, it can often improve efficiency and develop faster service.

Hapa said...

Thanks for the comment. In your case, I can see the validity of it. It's a small company and documentation along the way is crucial in software development.

As I mentioned, many reasons for the problem tickets are good... it's just the overall aspect of it got bloated and didn't work well. Taking 3 days to address a simple concern is ridiculous... I believe it's safe to say that if your company lost 3 days every time you opened a ticket, it wouldn't be very competitive.