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. =)

So Chuck what really resonates for me in this blog is the piece on integrations. I have been on non-stop calls this week talking with partners and the direct team about the integration capabilities and needs in Service Anywhere. Multiple LDAP sources, UCMDB, Discovery, Automation and the hybrid environment with Service Manager/Service Anywhere are all hot topics right now.

I especially want to commend you for your comments about Service Desk best practices. A VERY smart developer here regularly shares his thought (his very passionate thought) that many IT organizations need to change their thinking about the call center. Even today, IT organizations retain an old mindset and name their call center the “help desk”. His point is that this imposes a subtle limit to the scope and value of the agents.

What I see repeatedly is that once the call center is considered a “Service Desk” their role and value to the business increases. Further, the value and effectiveness of the Service Desk rises exponentially when the agents are empowered with ITIL version 3 processes and workflows based around service delivery.

What do you think? Can it be that simple to change the effectiveness of an IT team by changing what we call them? Whether that answer is yes or no, it is very clear that once IT starts thinking that they are delivering a Service Desk and focus on service delivery it can be much easier to take the next steps forward to Service Level Management, Service Catalog, etc.

After an action packed week at Pink13 and then the HP Global Partner Conference in Lost Wages (aka Las Vegas) and then another action packed week in Singapore, Malaysia, and Thailand last week, I am coming back around to the HP ITSM blog.

I definitely support the services oriented approach promoted by our esteemed very smart developer. I like an ITSM definition by Start Rance as being the management of services delivered by IT. This is arguably different, but related. Both entail taking a different vantage point. And, taking a services orientation begs for a more integrated approach (pulling in Mary's comment).

The whole topic around "best practices" is interesting and arguably evolving. I have seen some references to "good practices" - interesting and pragmatic. Evolving in the sense as built-in capabilities don't have to exhaustive to be good. And when it comes to industry recommendations like ITIL, less could be more. Given Scott's love of movies, you could make a children's story comparison with Goldilocks - not too hot, not too cold, just right ...