A strong Service Desk can cover a multitude of sins. Too many organizations don’t take advantage of this fact, neglecting the poor Service Desk in favor of behind-the-scenes IT initiatives (and giving themselves a black eye in the process).
Avoid the drama of competing priorities. Here's why it's a better bet to take this task off your Service Desk's plate.
It's difficult to make real progress without the right metrics. Here's how to ensure you're measuring the right behavior.
We've all been there. The freeware tool we got when there were two people running the Service Desk and 25 users finally starts to crumble. It cannot be upgraded because we didn't bother following the patching path set out by the original authors, and then it got sold to a commercial vendor and the new version is written in a different language, or the database is no longer compatible, or one of the other myriad reasons that most ITSM tools do not play well with others, even if the others are their successors.
As service organizations mature, and Incident and Service Request Management start to jell, executive management begins to get very interested in Service Asset and Configuration Management. And this is a very good thing. Knowing what assets we have and can provide service for is a powerful thing. It can drive increased budgets and resource allocation for IT, especially when we can point directly to how much time our staff spend on various CIs that might be obsolete or completely unused. If any of us look around, I'm sure we could find a lot of servers doing very little, if any work, but because of their age they require a great deal of resources to keep them "green" on our Event Monitors.
When organizations begin to really embrace ITIL best practices and begin the long journey toward ITSM maturity, one of the biggest stumbling blocks we encounter is appropriately defining, and properly delineating between Incidents, Service Requests, and Problems. While it may seem obvious to some, many struggle to grasp the differences—and how important it is to understand each of these operational processes.
In my career I have held almost every position in IT Service Operations one might imagine. I have been a 1st level tech, operations manager, system engineer, even acted as a data center operations manager. I have also seen the consequences of poor communication within IT Operations. Service Transition without the hand-off is a major contributor to unplanned outages and confusion, which leads both IT and Business Management to lose faith in the efforts put forth by their technical staff.
I recently had the experience of flying into, and out of, Hartsfield-Jackson International Airport in Atlanta. And it got me thinking a lot about Service Management. OK, I think about Service Management a lot. It's kind of my thing. But this really got me considering everything that has to go into delivering tens of thousands of people each and every day through one of the busiest hubs on the planet. Airports are a curious thing. They have an 'Authority', not unlike a small city government, that is responsible for handling all of the vendors, airlines, security personnel, baggage handlers, etc., along with every one of those passengers expecting to get where they are going.
Sitting this past weekend in the auto repair shop, I found myself thought about the fact that IT Service Providers are really quite similar to any other type of service provider. The technology is different, but the principles and processes are the same.