By Alex Lamykin • Oct 23, 2019

Part 2 of a 3-part blog post, read part 1 here.

Myth 2 – ITSM is for service desks.

One of the most critical issues with ITSM implementations that I‘ve recently seen involves level of responsibility. ITSM processes and tools are often associated with service desks – with their managers appointed as owners and coordinators of implementation projects. This is a fundamental mistake that alone can ruin an ITSM initiative or at least severely limit its outcomes.

Only two ITIL^® processes – Incident Management and Service Request Fulfillment – are predominantly performed by service desks. But, even these processes require involvement of multiple functional groups in the IT organization. In fact, IT services are provided by the entire IT organization, and ITSM methodology has always been aimed at designing process models covering the entire IT organization end-to-end.

Let’s be realistic. Contemporary corporate IT often has complex organizational structure with multiple silos. In this circumstance, a tool managed by the Service Desk team is destined to remain a ticketing system with very limited influence on the overall performance of IT department. Ok, there’s nothing wrong in getting user requests registered. But, look at what you are losing in this scenario:

1. Service provider attitude. Yes, the IT service desk is dealing directly with the users. But, IT services are provided by the entire IT department. Is it fair to judge a restaurant only by the work of a waiter? Can service desk alone guarantee service quality and availability? No. What kind of SLAs can you use if you don’t get involvement of the whole IT organization? SLAs for ticket processing only. Is this really what IT customers are looking for? I bet “average response time” and “first line resolution rate” are actually the last things they would care about.
2. Automation. IT service automation is the current trend. The ITSM community is actively discussing potential use of Artificial Intelligence, Machine Learning, and Robotic Process Automation. But, we can see lack of even primitive automations in those organizations that focused their ITSM initiatives on ticketing and Service Desk. Why? Because automation is data hungry. Here is a typical conversation with a System Administrator:
   • Q: How do you create user accounts?
     A: We get tickets from Service Desk.
     Q: And then?
     A: We review them. If request makes sense, we create the account. If not, we consult with the team that owns the server.
     Q: What do you do next if the request makes sense?
     A: We run a script that creates account.
   • Natural question – Why not run a simple workflow to get approval from the server owner and then start the script automatically? To begin with, this approach requires a structured and regularly updated list of servers, including information about their owners, an element of Configuration Management Database (CMDB). And, have you ever seen a decent CMDB in an organization with service desk-centric implementation of ITSM tools and processes? I can hardly imagine a service desk having enough influence, time, and skills required to support organization-wide change and configuration management.
3. Communications. Silo mentality is a well-known issue typical for large IT organizations. In many cases, it causes negative attitude to tools used and managed by other units. I recently attended a Meetup meeting dedicated to Agile development tools. The speaker analyzed multiple tools from most basic to advanced. At the end of the session, I asked a question about his attitude toward ServiceNow. To me, its Agile Development application looked similar to many other tools mentioned, but capability of having all the IT-related data in one system with cross-references between records like defects and incidents seemed to be beneficial. His answer surprised me: “Yes, Agile Development application in ServiceNow is not worse than many other tools, but… in our organization ServiceNow is used as the service desk tool, so we prefer to stick to our JIRA.” I have seen this “Not-our-Tool” syndrome in many organizations. Proper ITSM implementation should balance the needs of multiple groups instead of reinforcing silos. It’s almost impossible if the tool’s implementation and support is run by the Service Desk team.
4. Visibility/Transparency. A key reason to implement ITSM processes and tools is to provide transparency. Ideally, you would like to observe work in progress (incidents, requests, changes), get data to analyze trends, and evaluate performance and customer satisfaction. Why would you limit your reporting capabilities to service desk tasks only?

Implementing an ITSM initiative under the auspices of the Service Desk team will typically result in limited functionality. No matter how wonderful your service desk is, it isn’t likely that its team has enough influence to support full-featured implementation. So, the only viable way to run an ITSM initiative is under direct blessing of the CIO and supervision of an unbiased and well-respected leader who can take into consideration interests of multiple different stakeholders. Also, though ITSM tools and processes are usually initially implemented in the project format, they require continual effort to keep up with the new requirements as your ITSM practices mature. So, it may be wise to have an independent Service Management team that is not associated with any known silos and that reports directly to IT executives.

1. ITIL® is a registered Trade Mark of AXELOS Limited. All rights reserved.

Part 3 of 3 is coming soon.