Recommendations for getting the most from your service desk
Arguably the most common “get to know you” service desk type question is: What processes have you implemented? This can go also go hand-in-hand with what the service desk is even called: service desk, help desk, or trouble ticketing system (heard this just yesterday Pink13). Most of the time, incident management gets listed first. The exception is that some organizations use different tools/systems for change management compared to incident management. The most common response I hear is “incident, change and some amount of configuration management”. The other common response is "incident, problem, change, and some service level management". After that, there are many different paths. With this response in mind, here are some recommendations on getting the most from your Service Desk.
Process Coverage: Because there are lots of different paths, you want to make sure that you have options to go down any of them—as needed. The most common second steps cover some or all of:
- Problem management
- Service level management
- Knowledge management
- Service Catalog
- Request fulfillment
- Release management
We also have customers complementing some or all of these with availability management, service portfolio management, and the more formal—service asset and configuration management.
Best Practices: This arguably goes with the above, but not always. Regardless of an organization’s commitment or view on industry standard best practices such as ITIL; almost no-one these days wants to start from scratch. We especially see this in core processes such as incident management. Most IT service desk teams are looking to leverage industry standards for these core processes.
Another recommendation is to go lean and reflect classic 80/20 rule for best practices.
If ITIL is important to your organization, then I’d recommend evaluating how important this is to your vendor or service partners. You could begin by evaluating the most recent PinkVERIFY 3.1 requirements. If you are interested in whether other organizations are using such processes in production, then look at the official ITIL endorsements. A gold level endorsement reflects that three different entities made a formal statement that they are using the tool in production to implement the corresponding ITIL process.
Integrations/Solutions: Being able to consume directory information via LDAP, send and receive emails or interact via web services is widely supported in today’s service desk tools. Move past this to get the most out of your service desk. You will want seamless integration between the help desk processes such as moving from incident to problem to change management. You will also want to be able to quickly identify changes (or releases) that have taken place associated with an incident or configuration item. This is a pretty basic request.
One of the most classic integrations is (event) monitoring to service desk and back. Can your monitoring systems correlate events and produce an actionable incident? Then after the incident is closed, can events be acknowledged? To get the most out of your service desk, this type of use case or solution should be easily obtainable – with select integrations pre-built or experience accessible to do it quickly.
Another solution related integration that we are seeing more of is plugging task automation into standard processes. This is arguably more mature, but we have customers that have integrated automation into request and change management. DevOps will bring more of this to release management. Automated remediation has been a staple in the operations event management world for years and these capabilities can also be leveraged in incident management with knowledge management.
Deployment Options: To get the most out of your complete service desk, you might need flexibility in how the service desk is provided or deployed. It could be on-premise—which often simplifies some of the integrations mentioned above along with realizing solutions that have tasks (such as discovery) that need to be close to the infrastructure. It could be via SaaS for any sized organization—but especially in leaner IT organizations that don’t want to administrator and maintain the infrastructure required to support the service desk platform/tool. There are also hybrid scenarios where an on-premise service desk supports central IT and a separate SaaS service desk supports a Line of Business (LoB) or remote entity—either for IT activities or someone outside of IT.
A peripheral point on deployment covers implementing and then upgrading—it all has to be simple. Gone are the days of development platforms where a heavily customized help desk was created (and necessary). New graphical, codeless configuration tools simplify the implementation, on-going upkeep and upgrade tasks.
Services: There are so many idioms to borrow here. A fool with a tool is still a fool. If you need a hip replacement, do you find the cheapest option or the surgeon with the best practice and experience? The service desk is especially sensitive to this topic because it is so process based (and there is great industry experience to draw upon). To get the most out of your service desk, you should consider more than just a basic implementation or a quick-start package. In many situations, good service integration and process consulting along with organizational management of change makes more of a difference than the individual service desk.
There have been books written on this or very long chapters in other books on this topic. Boiling it down to a couple of pages is a challenge (and those who know me say I should be more concise!) To find out more about HP’s capabilities in providing a complete service desk, please visit www.hp.com/go/itsm. To get a quick feel for our SaaS capabilities,you can also register for a free trial of HP Service Anywhere.
I want to hear your experience on this topic. Feel free to share your thoughts on the topic in the comments section below. We can turn these thoughts into a novella and I will split the profits 70/30. =)
Chuck
