Posted by Sarah Lahav
on March 21, 2017 in Service Desk
While smart, connected devices in the home such as Amazon’s Echo
get much of the media attention around the Internet of Things (IoT), there are many other IoT use cases already in the wild – especially use cases that relate to the improvement of business operations and services. Whether it’s automation, data collection/monitoring, controlling previously “dumb” devices, or something else, the use of IoT devices in the enterprise is growing rapidly as businesses seek to improve operations and the customer experience, gain greater insight into operations and service quality, and capitalize on new revenue streams.
The Impact of IoT on the Corporate IT Service Desk
These enterprise IoT “infrastructures” need supporting, and the existing corporate IT service desk is the most likely home for that support capability. Some might argue that support should lie with the business function that supplies the IoT-enabled service – for instance, that the facilities team should support a connected intelligent heating system. However, many of the issues that enterprises have already encountered with IoT devices relate to such business functions simply not understanding the risks and management needs, of what is ultimately technology
It will probably be an ongoing topic of debate for many companies, as the different lines of business “empires” want to keep or gain control of things, but for now, let’s assume that the corporate IT service desk has responsibility for IoT devices and the dependent services. There are a number of things that will affect them, such as:
- Increased volumes. The IoT brings with it more end points, higher bandwidth usage, increased storage requirements, and more incidents. The IoT increases the IT infrastructure, and the scale of the management and support needs, by an order of magnitude. Service desks and their support tools will need to be able to handle thousands, potentially millions, of new end points and their data transmission and storage needs.
- Greater complexity. When we talk of enterprise IoT devices we often think of things that aren’t attached to, or associated with people – for example a network-connected scanner or the sensors powering intelligent lighting or heating systems. But let’s not forget the IoT devices directly used by people. From the traditional PC and smart phone, through tablets and wearables, to intelligent personal assistants (such as the Echo) where voice is now the UI. Thus, complexity is not only the increased types of technology but also the reliance on different technologies for people to “get things done.”
- Increased security requirements. Security now gets, and will continue to get, a big chunk of the enterprise IoT attention; and rightly so. In late-2016 we saw the first large-scale security attack attributed to the IoT – a distributed denial of service (DDoS) attack on Dyn, an internet infrastructure company, which was believed to be the work of a bot that uses IoT devices, protected only by the factory-default log-in details, to attack online services. IT security per se will of course also continue to be a high priority area for IT organizations in 2017.
- Asset and configuration management. When an IT device is “used” by a person, it’s often easier to know (or to find out) it’s location, purpose, owner, and the impact of its failure. In the absence of “end users,” service desks will need to have a better appreciation and understanding of IoT assets – whether via configuration management, asset management, or knowledge management. This also covers the need to understand whether devices are up to date in terms of software and security patches.
Five Ways to Better Equip Your Service Desk for IoT
There are of course going to be far more than five things that could be done to help IT service desks deal with the growth in numbers and importance of IoT devices. But here are five to get you thinking:
So there you have some key points to consider with the IoT. What would you add or disagree with?
- Service desk people need the ability to look beyond the technology to see the business impact of IoT device failures. Plus, the ability to recognize that a “silent” IoT device might be a far more urgent priority than a shouting business colleague – as the former might have a much worse business impact than the latter.
- Service desk people need new or improved IT management tools. Some might say they need new IoT management tools but I’m sure most IT pros would prefer to be able to use fewer management tools wherever possible. Ideally, existing IT management tools need to be able to deal with the types and high volumes of IoT devices we will see. Plus, the ability to predict future failures and launch remedial action before services are adversely impacted.
- Built-in redundancy and/or localized (but secure) stock. Cheap doesn’t always mean “easily breakable” but cheap does mean that it might cost more to visit and fix/replace an IoT device than the device costs (although some IoT devices will be expensive). And this is before the cost of business-affecting downtime is added into the equation. Thus, having crunched the numbers, it might be better to over-deploy cheaper IoT devices or to keep a local stock of spare devices such that downtime and the costs of replacement are minimized.
- Access to local support resources. I’m not referring to traditional desktop support but suitably-skilled business colleagues who are able to quickly rip-and-replace simple, inexpensive IoT devices when remote access can’t quickly diagnose and fix the issue. This is reinforced by localized stock (#3 above) and my next point (#5 below).
- Access to knowledge and better collaboration. In an IoT-dependent world, the availability of knowledge becomes even more important. Not just for service desk agents who now have a wider range of technology, and potentially services, to support. But also for business colleagues who might be assigned to support an IoT device that they use personally or that they are responsible for due to their locality. Plus, better collaboration is needed too, given that the issue and resolution might not always be addressable by the remote IT service desk team, with the issue passed to facilities, say, for a building engineer to address.
Posted by Dena Wieder-Freiden
on March 14, 2017 in Help Desk
Everyone has a help desk these days, and the service that a help desk delivers will probably cover a range of aspects. The service will be delivered by a combination of human-to-human and computer-to-human interactions, by calls/emails/chats to help desk agents and use of the self-service portal via an organization’s integrated help desk software system
. That combination of people and automation is what delivers support to the users. Along with the actual support, how that support is delivered in terms of the way people feel afterwards, will very much affect how willing those users are to us it again.
The help desk deals with both incidents
in a similar way, although there is a key difference between them:
- Requests is a user asking for something new or different, like a PC upgrade, additional software, or new access rights
- Incidents are when something has gone wrong and the user is looking to get it put right.
So, requests are things you actually want to happen – improvements and new capabilities; incidents are things that nobody wants to happen.
Measuring the Help Desk
Because the help desk costs money – for staff, equipment, software, etc. – organizations feel the need to measure its performance, and its cost. So they record the money spent and measure metrics that describe how effective it is. Typically, organizations will measure the desk using a set of tension metrics
to give a broad and balanced view of how well the help desk is performing against the targets set for it.
This will give you a set of numbers and an indication of whether the help desk delivers what you’re paying for, and whether it’s getting better or worse against those measurements. It might include a measurement called something like ‘user satisfaction’ but, at best, that will be one small part of the measurement. The major focus gets put onto easier-to-measure aspects like ‘first time fix rate’ and ‘average call duration’.
How Does Your Help Desk Make Folks Feel?
I’m a firm believer that the best help desks add more to an organization’s potential than just numbers can easily measure. Every interface with the help desk is a transaction of sorts. We, all of us, know from our everyday lives that this kind of interaction delivers two kinds of outputs:
- Did I get what I set out to get?
- Has the experience made me happier or angrier?
Whether it’s booking a flight, making a doctor’s appointment, or a host of other things, most of us have had the experience of getting what you needed but having been upset by the overall experience. A host of factors can upset us: having to wait, rude operators, confusing screens with obscure questions, trouble understanding, and more.
If your help desk is like this, your normal measures may show you meeting the service level targets you have set. But you will not be delivering the level of support your customers and users – and the organization as a whole – expect and deserve. Critically, unpleasant experiences with a help desk can have almost immediate detrimental effects on the business, such as:
- Reluctance for the user to call again, meaning future requests are delayed and incidents will affect business performance for longer than they need do.
- Increased temptation to try and fix things alone, or with peer support before considering to contact the help desk. This effectively stops both the user, and others, from working, and increases the prevalence of shadow IT.
- A bad reputation, meaning customers are predisposed to see, and tell others about, the bad in your performance above the good.
Finding Out How They Feel about You…
It isn’t easy to get an accurate feel for how a help desk is perceived, and the effect it’s having on the user community. But you can try.
Of course, the obvious thing is to ask your users, but that only gets us so far for a couple of reasons:
- Firstly, IT isn’t always so good at building and interpreting the right approach to surveys. (Joe The IT Guy wrote about that in his blog: Is Your IT in the Shadows?)
- There is usually a wide range of variables – different groups, at different times, in different circumstances will feel differently about their help desk experience. Unless you can measure across that range of variables, it’s almost impossible to prepare and implement relevant improvements. That range includes things like:
- Request or incident?
- Time of day, month, or business cycle
- Users from different parts of the organization
- Language and cultural differences
The issue here is that we’re trying to find out how the help desk makes people feel – was it a pleasant experience, did they actually feel helped afterwards or just like they had been processed by an impersonal service? Since it’s a feeling rather than an objective fact, sometimes subtler methods than simple questions are needed, i.e. more general conversations, and of course feedback from business relationship management, account managers, and the like.
…And Then Doing Something about It
It isn’t enough to learn the effect that your help desk has on your users. That knowledge has to then be applied to improve the impact, to increase the ‘feel good’ factor during interaction with the help desk. That might mean: targeted training for help desk staff; workshop sessions with the help desk’s users to increase awareness; better knowledge gathering and presentation so that help desk staff are more aware of their clients concerns and attitudes.
There is a range of skills and practices that make a difference to a help desk providing a good experience. Obvious factors like interpersonal skills, awareness of the user’s role and environment those users live and work in, and so on. Time spent on training to increase these factors is usually time and money well spent.
Another valuable and effective technique is simulation and practice – these can be done in-house fairly easily. Pick out some examples of past issues and take a group out of the workspace for a few hours to talk through how things were done and how else they might have been done.
And, of course, do understand and encourage the application of “intelligent disobedience”
(knowing when NOT to follow the rules) towards help desk performance and perception.
Have you tried any of these “feel good” tactics? Please do let me know if it helped and how so. Sometimes I get inspiration from the Godfather of Soul himself…maybe you will too :)
Posted by Stuart Rance
on March 7, 2017 in ITSM
If I asked you how your organization does problem management, would you, like so many of the people I have worked with over the years, tell me that you don’t do it? You know you ought to, of course, but you simply don’t have the time and resources to get started.
I’m willing to bet that if you’re one of those people, and you asked me to take a close look at the running of your IT operation, you’d be surprised. Because, quite often, when I look at what people who work in IT organizations actually do, as opposed to listening to what they tell me they do, I find that they’re already quietly getting on with many of the things that need to be done to manage problems. They just don’t call what they do problem management. Too often people believe that problem management is something formal and complex that can’t be put in place without specialized tools and extensive training. And so they fail to recognize the power – or the potential – of the steps they’ve already put in place.
I’m always really pleased when I come across a situation like this, because it’s a great position for an organization to be in. It only takes a very small amount of effort to create an effective problem management capability when you’re building on what’s already being done. (See my blog Back to ITSM Basics: Start Where You Are
for some more thoughts on this idea.)
So what should you look for if you want to know whether or not your IT organization already has in place the foundation it needs to build an effective problem management capability? Where do you start?
Well, you start by understanding the difference between managing incidents – which any IT organization must do routinely – and managing problems.
What’s the Difference Between Incident Management and Problem Management?
In case you aren’t familiar with the difference between incidents and problems here’s a brief summary.
An incident is “An unplanned interruption to an IT service or reduction in the quality of an IT service”
Most incidents are detected by users who phone the service desk to report that something is wrong. The purpose of incident management is to get the business working again, and to reduce the overall impact of the incident as far as possible. For example, if a user reports that a printer isn’t working, then you could resolve the incident by routing their printout to another nearby printer so that they can get the document they need.
Incident management activities include:
- Identifying, categorizing, logging, and prioritizing incidents
- Diagnosis and escalation (where needed)
- Incident resolution and closure
- Ensuring that users are kept informed about status
- Managing the lifecycle of incidents and ensuring that SLA targets are met
For more information, see ITSM Basics: A Simple Introduction to Incident Management
A problem is “The cause of one or more incidents”
The purpose of problem management is to prevent incidents from happening and to minimize the impact of incidents that can’t be prevented. For example, you could identify that a particular model of printer tends to fail after two years of use and plan to replace these printers before they fail. This would completely prevent the associated incidents. Alternatively, you could order a stock of spare printers so that you can replace them very quickly when they do fail, which would minimize the impact of the failures when they occur.
Problem management activities include:
- Analyzing incident trends to identify problems that should be investigated
- Reviewing information from other sources, such as vendors or development teams, to identify problems that need to be managed
- Investigating problems to identify what is causing the incidents
- Developing and testing workarounds that can help to minimize the impact of future incidents
- Identifying remedial actions that can prevent future incidents
For more information, see ITSM Basics: A Simple Introduction to Problem Management
Hidden Problem Management
I started this blog by saying that many IT organizations are actually doing some problem management, even if they claim not to be. Here are some examples of things that I have seen in place:
- A major incident review being held after every major incident, where everybody involved helps to understand:
- What caused the incident
- What can be done to prevent future similar incidents
- What can be done to minimize the impact if the same thing happens again
This then results in improvement activities.
- Technical support teams keeping up to date with information from vendors, identifying patches that need to be installed, and other proactive actions that can be taken to help prevent future incidents.
- A service desk manager identifying frequent incidents, and reporting them to vendors or technical support teams for investigation.
- A service desk agent developing a workaround for an incident and discussing it with co-workers, so it can be used whenever similar issues arise.
I have no doubt that there are many other examples of hidden problem management taking place. So, if you “don’t do problem management
” why not take a close look at your organization and see what you discover?
Building an Effective Problem Management Capability
If you know you should be doing problem management, but keep putting it off because you think that it would involve too much effort and expense, then you should think about using three of the ITIL Practitioner guiding principles
to help you get started: Observe Directly
, Start Where You Are
, and Progress Iteratively
- Observe Directly – Go and talk to people who work on the service desk, and in technical support teams. Make sure you know and understand what they are already doing. Identify the things that help your organization manage problems – there will almost certainly be some, if you look for them.
- Start Where You Are – Think about how you could build on the things that people are already doing. If there really is nothing, introduce something, however small, making sure it’s straightforward but capable of producing useful results. But it’s more than likely that there will be a lot of good practice around, once you go looking for it. Start measuring and reporting the good practice that already exists; share best practice between teams; gradually increase the scope of the work that is already being done.
- Progress Iteratively – Make small improvements, and measure how effective they are. Build on the ones that work well, and modify the ones that work less well. Then do it again.
If you follow these guiding principles you should find that you’re building an effective problem management capability at a very low cost and with minimum effort. And 2017 could be the year your increasingly proactive approach results in better service and happier customers. You can’t ask for better than that, can you? So why not give it a try?
Posted by Doug Tedder
on February 21, 2017 in Service Desk
Categorization is a critical aspect of many IT service management (ITSM)
processes. Categorization helps us:
- Route work associated with an incident or a request
- Produce effective management reporting that enables further analysis or process improvements
- Translate what a consumer is telling us into something that IT can understand and do something about
There’s a lot of good advice about categorization that is readily available via an internet search. A couple of great articles can be found right here on the SysAid blog. Stuart Rance
shared his thoughts about categorization in his post titled Improving Categorizing Incidents
. Another SysAid blog post, Incident Categorization – Reasons and Consequences
, discusses the benefits of a good categorization scheme and the consequences of poor categorization.
But how do you go about defining your categorization scheme? I have some ideas about categorization that I’d like you to consider.
Good Categorization Is About Balance
The most important thing to understand about categorization is that it is all about balance. If a categorization scheme is too simple, it will inhibit work flow and trend analysis. The categories will simply be too broad or vague to facilitate effective process execution or continual improvement.
The other end of the spectrum is a categorization scheme that is overly complex. While further definition may help with more precise workflow and analysis, this comes at a cost – the up-front time it would take a service desk agent to determine the exact category of an incident or request. While good documentation may mitigate this risk, keep in mind that a primary objective of a service desk is to complete its tasks in a timely manner. Service desk agents don’t necessarily have time to read through a lengthy procedure while the consumer is on the other side of a telephone call or chat session.
Also, categories can and should change over time. As services are introduced or retired from the managed environment, there will be impact to a categorization scheme. A good categorization approach recognizes that, and should strike a balance between the need for consistency for managing day-to-day activities with the flexibility needed when services do change.
Common Categorization Mistakes
Unfortunately, many organizations don’t take the need for balance into consideration when defining their categorization schemes. They often don’t think about how they want to leverage their categorization schemes in terms of workflow routing, reporting, or identifying improvements. As a result, I’ve seen them make the following mistakes:
- Define categories based on the organizational chart
This might work, and seem very straight-forward…until the organization chart changes.
- Top level categories are “too technical”
Generally speaking, the consumer has no knowledge of the underpinning technologies that are used in delivering service, and are unable to articulate an issue in technical terms. As a result, the service desk has to translate (read: guess) from the business-reported symptom to the technical taxonomy.
- Too many top-level entries or a scheme that is “too deep”
I once worked with a client that had a six-level deep categorization scheme. I’ve seen clients that had dozens of top-level entries in their categorization scheme. If there are too many entries (keep in mind that “too many” for one organization may or may not be too many for another organization), handle times for logging an incident will become needlessly excessive.
- Assuming that the consumer “knows” the categorization scheme
Yes, it may make absolute sense to the IT organization, but how (or even why) will the consumer know about the categorization scheme? The consumer has no idea how the scheme is defined, how the scheme is intended to be used, or even the cause of their issue so that it can be properly categorized within an IT-centric scheme.
- Using “other” or “miscellaneous” as a category
Frankly, this is laziness! If these categories are defined, they will (and do) inevitably become a dumping ground, nullifying the reasons for categorization to begin with!
Another Way of Looking at It
Consider this – what is the trigger for categorization? How an incident is categorized is essentially based on what the consumer has said
So why not take a consumer-centric approach to categorization?
In my experience, most categorization schemes have been defined following an “inside-out” approach. The scheme is defined based on the IT organization’s processes and services, and is pushed from “inside” IT “out” to the consumer. So why not look at it from the consumer’s perspective? Looking at this from the “outside,” or consumer’s perspective, what should the consumer’s experience be? This is known as “outside-in” thinking
So rather than trying to categorize incidents by “hardware” or “software” or “network” (all IT-ish ways of looking at an incident), why not categorize based on the consumer’s perspective? This might look something like “can’t print,” “error message,” “not working or slow,” or “need help.” From this top level, the service desk agent can then drill into the issue to identify further symptoms that will assist in determining how to manage the issue. Following this approach essentially defines the roadmap for helping the service desk agent categorize the issue; for example, “not working > intranet > broken link” or “need information > software > excel”.
Advantages of an Outside-In Approach
Here’s a few advantages of taking an outside-in approach to categorization:
- It improves the customer experience – service desk agents can have a conversation (rather than follow a script) with the consumer to manage the incident.
- Strikes the right balance – it allows for the needed flexibility (changes in offered services can be easily added or removed at a sublevel), while having consistency at the top level.
- Removes the ‘tech speak’ from categorization – consumers need not be intimated by a call to the service desk, as the service desk will be enabled to speak and use terms that the consumer understands.
Taking an outside-in approach to categorization may seem awkward at first. But by taking this approach, both the consumer and the service provider will benefit by facilitating a good customer experience (and for more on that, I highly recommend you read Sarah Lahav
’s blog Bridging the Gap Between Service and Customer Experience
Posted by Stephen Mann
on February 21, 2017 in Help Desk
There are a number of reasons why email and other personal productivity tools are used for IT support, for example:
- Most IT staff usually have access to email
- IT staff know how to use email
- The email technology has already been “paid for” in providing a set of tools for personal productivity reasons
So it’s easy to think of email as being a cheap IT support technology, one that’s easy for IT support people to use. But easy isn’t always best…or even appropriate.
Breaking Down the Issues with Using Email to Manage IT Support
Let’s consider IT support operations – key activity by key activity – in the scenario where we’re part of a group of service desk agents using a communal email inbox to receive and manage end-user incidents and service requests:
[caption id="attachment_1938" align="aligncenter" width="638" class="center"]
Original source: A Companion to ITIL (v2)[/caption]
Phase 1. Incident Detection and Recording
An end-user email comes in and it’s automatically “recorded” – because it’s sitting there as an entry in the communal inbox. However, does it contain all the required information from the end user? Well, we can’t say, as this will differ by issue or service request type (plus service requests might be mixed in with the far more time-sensitive incidents). We could use an email template to help end users provide the right information though; maybe even something showy that requires different information based on the issue or service request type.
But what do we do if the end user calls by phone, rather than emails? Do we create an email ourselves, add the issue to an Excel spreadsheet, use a post-it note, or record nothing at all? And what about benefiting from the modern penchant for self-service
? It’s not just about improving IT efficiency, it’s also about providing contact channels to suit end-user preferences and delivering a better customer experience
Phase 2. Initial Classification and Support
I guess we could classify an issue, or service request, in an email inbox through the use of folders or tags, but what happens if the initial classification is wrong? The issue can be reclassified but would we know how much service desk time is wasted on misclassified issues? And what about prioritization? Are issues and requests dealt with on a first-in-first-out (FIFO) basis, with some bias towards “important” end users, or is a more scientific urgency and impact-based approach taken?
Also, what about the ease and quality of initial support? Is information related to the task at hand readily available through integrated knowledge management capabilities? Do you have information related to the end user’s IT history and the IT assets they use? And what about information related to service level agreements (SLAs) and the targets for fixes and service request delivery? So of course we can solve the end user’s issue or service request but only if we have the right knowledge, skills, and experience and our service desk has the absolute minimum of staff churn.
Phase 3. Escalation to a Major Incident Process Where Needed
The reality is that if email is being used to manage IT support then the “process” for major incidents is very likely to be a lot of running around like headless chickens until things are “better again.”
Sadly, this might seem harsh, but using an email inbox and/or manual procedures will not be the quickest route to the required resolution (due to a lack of insight into the root cause, previous resolutions, and ongoing status). Most likely, there will also be insufficient communication to stakeholders, and probably no post-major-incident review to ascertain “what went wrong” and to identify any improvement opportunities.
Phase 4. Investigation and Diagnosis
So there was no immediate fix and one or more of our IT support or service desk agents now need to spend time investigating the issue to better understand what needs to be done to rectify things. But what happens here in terms of logging progress and important aspects of our investigations, such as: failed solution attempts, who is currently working on the issue, expected resolution time, and the eventual solution? Of course the email could be updated with all of this information, but will it be? Hard to believe, especially if an issue, once closed, is simply filed away in the “completed” folder with no metrics created, or knowledge captured, to improve resolution of similar issues in the future.
Phase 5. Resolution and Recovery
So the issue is now fixed or, in the case of service requests, the service delivered. The email system can be used to inform the end user, so all is good. Right?
Well, it depends. Is everything that was learned, while resolving the issue, lost as soon as an email is “filed”? Meaning, do the other service desk agents need to reinvent the proverbial wheel when a similar issue gets reported in the future? And what about dealing with customer feedback on IT support’s performance, or is that ignored? Of course, knowledge management and customer feedback capabilities can be built and integrated, but surely this is just additional evidence that a fit-for-purpose help desk or service desk tool is so much more than an email system?
Phase 6. Incident Closure
Probably little to worry about here with email – the issue or service request can be moved into the “completed” folder (plus it can be moved back into the main inbox if the issue or service request needs to be readdressed). That is until we look at the email system’s ability to provide visibility into support operations – with metrics related to throughputs and efficiency, including the number of reopened issues.
Thus transactionally, email can be used for incident management, but there are so many suboptimal elements and inefficiencies, which cost time and money, and can be addressed through the use of a fit-for-purpose help desk or ITSM tool
But It’s Not Just Issues with the Transactional Elements of Email Handling
There’s also the ongoing monitoring, tracking, and communication
of issues/requests to consider. And boy is there a lot to consider here, probably as much as with the previous six bullets combined:
- Does the email system allocate a unique reference to each incident or service request such that an end user or IT team member can quote/find it when needed? And what about providing a suitable audit trail?
- Can the email system calculate the timings between key activities such as email receipt, allocation, resolution, and closure? Thus allowing for the assessment of performance for individual tasks, incident and service request types, individual service desk agents, and the service desk team as a whole? Plus, can those who work on an issue or service request log the time they spend doing so?
- From a management perspective, can incident-related data be used to quantify the adverse effect of IT issues on business operations – a cost of quality and an opportunity to improve things?
- Are service desk agents able to identify issues and service requests that are taking too long to deal with? Even if there are no IT support SLAs to be met, what’s to say that tasks get accidentally delayed or even forgotten about, especially when multiple parties are involved?
- How are issues and requests tracked, not just over time but also from person to person? How is responsibility or accountability assigned – is it the last person to “view” an email or the last person to add a note? Or are emails tagged to individuals or dropped into people-based folders rather than category-based folders?
- Email software lacks “workflow, automation, and alerting” – so how do the individuals with the right skills or authority know that something needs their attention, or how does the system know if an issue has awaited third-party attention for too long? Do people have to regularly check the communal inbox, or has the email system been tweaked to allow for action-request emails (alerts) to be sent? Plus, I’d be willing to bet that such emails, if they exist, don’t automatically get resent (or someone else alerted) if the third party hasn’t done what they need to do in a reasonable time frame.
- Communication-wise, of course emails can be sent to and received from the email system but how are they “organized” and is it easy to separate important emails from trivial ones? Plus, what happens when a telephone call is made or received, or a deskside support agent wants to notify the service desk of what they have discovered or tried as a resolution? What I’m trying to say here is that emails can be used, even if just for collecting notes, but the information within the emails is mostly unstructured and inaccessible at speed.
So How Well Is it All Working?
The last bullet above leads us nicely into another area, and probably the biggest area, of operational and management weakness when using email for the management of IT support – insight and reporting
With an email system you can probably manually count things such as the number of emails received or closed in a month, and split them between incidents and service requests. You might also be able to attribute them to individuals to ascertain personal “throughputs” (although I’d be worried about people playing the system and quickly jumping on the easiest of issues while avoiding those that take time).
As mentioned earlier, the information or data held within the email system is unstructured and thus difficult to analyze and report on. So accessing insights into: incident and request volume peaks and troughs, average handling times for each incident type, achievement of SLAs, the costs of IT support by category, incident trends for problem management, business unit to business unit comparisons, and other metrics – is either impossible to get or a highly manual and time-consuming activity.
Plus of course the email system will not have a modern reporting capability nor dashboards, nor any form of ability to slice and dice data to identify patterns or other insights such as business intelligence
Finally, IT Support Is More than Just Service Desk
How does your IT organization manage problems (if they do at all) and changes? Do your monitoring or event management systems integrate with your email system? Can your email system launch automation capabilities to solve issues? I could go on but this blog is already long enough, many would say too long.
My point is merely that using an email system for IT support is really only scratching the surface of support capabilities and missing others espoused by industry best practice such as the ITIL IT service management (ITSM)
best practice framework.
So if you’ve read this blog and still think that you can use the corporate email system for IT support, adding to it to get around all of the issues raised, then I’ll pose you one last question – “Would you build your own HR or CRM system?” Unless your answer is oddly “yes” then surely you should be applying the same “buy, not build” logic to invest in fit-for-purpose technology for IT support that’s optimized to business needs (and reliable), maximizes people efficiency through workflow and automation, delivers a better quality service to end users, and provides greater insight into operational performance and improvement opportunities.
Posted by Dena Wieder-Freiden
on February 14, 2017 in Help Desk
There are lots of different names for “the corporate team or function that provides internal IT support to end users.” Examples that I’ve seen used on my IT service management (ITSM) travels include:
- IT help desk
- Service desk
- IT support
- Support center
- Technical services/technical services center
- Technical support (center)
- Technical customer support
- Level 1 support
- Frontline support
And there are probably many more.
But how often do each of these get used “in the wild”? And are some of the names better than others?
Let’s Start with What HDI Members Use
, which is a professional association for the technical support industry, showed how different names are used by its members in their 2015 Support Center Practices & Salary Report
[caption id="attachment_1913" align="aligncenter" width="435"] Source: HDI 2015 Support Center Practices & Salary Report
So we have service desk at 36% and help desk at 23%, with the remaining 41% of companies using a variety of other names.
Have We Been Killing Off the IT Help Desk One ITIL Exam at a Time?
In many ways the HDI results are to be expected.
, the most commonly-adopted ITSM best practice framework, took the IT help desk of old, and IT operations best practice, and built a body of ITSM advice around them. But, as ITIL and ITSM evolved, the term “IT help desk” no longer fit the new world of “managing IT as a service” and the term “service desk” was deemed to be a better name for the help desk 2.0 – which now offers more than just help for IT issues.
In fact, the term “help desk” has been removed altogether from the ITIL lexicon. If you don’t believe me, then take a look at the ITIL 2011 books or the online ITIL Glossary:
[caption id="attachment_1914" align="alignnone" width="800"] Source: AXELOS ITIL Glossary of Terms
It makes sense – we have ITSM, IT services, and the service lifecycle so why not a service desk instead of a help desk? Or does it?
What Does the “Service” in Service Desk Allude to?
It’s an interesting question, one that I’m not sure most people stop to think about. So I thought I’d give it a go. Why is the service desk called a service desk?
Is it because the service desk is there to support the needs and wants of the users, or consumers, of services? If so, then a service desk is just the same as the supermarket meat counter that provides specially-tailored meat portions to customers. Or is it called a service desk because it services end-user needs, in the same way that supermarkets have service desks or customer services?
Both reasons are conceivable.
Or, is it called a service desk only because ITIL, backed by many ITSM tools, says that this IT support capability should be called a service desk rather than a help desk? If we go back 5-10 years, ITIL was a big part in ITSM tool marketing and selection; and ITIL-educated customers wanted to buy service desks not help desks.
Importantly, Do the Above Reasons Actually Matter?
Not really, as this is all inside-out thinking
, which is where decisions and actions are made with internal rather than customer-focused motivations. So far this is more about what people in IT want to call it – due to evolution/reinvention or wanting to introduce a better help desk
, rather than thinking about the customer perspective. For instance, they might say:
- “Help desks only deal with break-fix issues.”
- “Service desks take a different, more customer-focused, approach to IT support.”
- Or, “Help desks of old didn’t do first contact resolution (FCR).”
However, there is, and was, no reason why an IT help desk couldn’t do more than break-fix, be more customer focused, or hit high levels of FCR. Instead, I think that the term “IT help desk” just didn’t fit with the “service-this” and “service-that” lexicon of service management best practice. Plus it didn’t help vendors to market and sell something better than the existing customer IT help desk tools, and therefore had to go.
Let Me Play Devil’s Advocate for a Moment
So to sum up – the “service desk” is named as it is because it’s what most people call it these days, it’s best practice. Agree?
Well I disagree. Not with the logic of good or best practice but with it’s what most people call it these days.
In my experience, most people still call the service desk “the IT help desk” or “IT support” not “the service desk.” Why? Because “most people” are the corporate end users, or customers, that need support – as surely they must outnumber service desk, and even all IT, personnel in the majority of companies!
So was “service desk” merely a new term introduced to market and sell more books, training, exams, technology, and consultancy? Sadly, I’m struggling to see beyond this, as an IT help desk could have delivered everything a service desk does without the name change.
You can read more on the help desk vs. service desk debate in Joe the IT Guy’s blog: “You Say Tomato: Help Desk vs. Service Desk”
Posted by Stuart Rance
on February 7, 2017 in General IT
Enterprise service management (ESM) is the use of IT service management (ITSM) tools and processes to support other lines of business within an organization. It’s a term that’s generally used by IT people, who know and understand ITSM, but may be off-putting to those less familiar with IT. In fact, I enjoyed a presentation by Elina Pirjanti
at the itSMF conference in Estonia last year, where she asked us to stop calling it “enterprise service management” (in fact, she wrote a blog
about it too). Everyone else in the organization thinks of this way of working as “digitalization” or “digital transformation” and we should use their language, rather than trying to force IT language on the rest of the organization.
And this is fair enough, at least up to a point; particularly when I know that all the articles I’ve read about ESM recently have a focus on using ITSM tools to help manage service requests from business units such as HR, legal, or facilities. This is certainly an important use case, and is something that almost every organization should be doing. ITSM tools
are great for logging and tracking service requests, as well as supporting automation of request fulfilment, and providing reporting so that you know how well you’re doing. Why would we not choose to take advantage of these capabilities that are already at hand?
Here are my thoughts on how you can take advantage of ITSM to help other areas of your organization…
Providing a Single Portal for All Service Requests
Today, we’re seeing cases of ESM that go a little bit beyond just managing service requests for different units within a business.
For example, in some organizations, ESM now provides a single portal for employees to access all the business services they need, whether it’s ordering a new laptop, notifying the reception desk that a visitor is expected, or requesting a pension statement from the finance department. This improves employee experience, as well as providing greater efficiency for internal business units, and increased transparency and understanding of what work is being done by each team. The most effective organizations extend this portal outside their own organization, providing a way to work more effectively with suppliers, and with external customers.
Using Incident and Problem Management Outside IT
When people think of ESM as “digital transformation”, they are only thinking about request fulfilment, and this is all that they include in their ESM project. The trouble is that if those of us familiar with the possibilities inherent in ITSM tools and processes just stick to request fulfilment, then we are needlessly limiting ourselves. There is a huge opportunity for ESM – or whatever we choose to call it – to exploit the value of other
ITSM capabilities across the enterprise.
I have worked with organizations who are very good at managing their IT incidents and problems, but had never considered using the same approach for managing incidents and problems in other parts of their business. A few forward thinking organizations, however, have now started to consider this.
Recently I was talking to a friend who was working as a management coach for a transportation company. This company provides drivers to take trucks on single journeys. Their key business metric is the percentage of trucks that arrive at their destination at the correct time, and they typically manage to get about 98.5% of the trips to meet this target. The CEO wanted to improve, but realized that achieving a very ambitious 100% success rate would require much better, and more detailed, understanding of exactly what was happening with the failing trips. Failures might be caused by breakdowns, unexpected traffic, drivers falling ill, and many other causes too numerous to list; and without good data it would be impossible to devise an investment strategy that would lead to improvement.
The way forward is obvious, once you’ve thought of it. We suggested implementing processes based on IT incident and problem management – to help them deliver better service to their customers, and to supply the missing data.
The transport company already use tools and processes for managing IT incidents. By using the same tools to implement an incident management process focused on truck movement, the organization will be able to:
- Understand the current status of all the trucks that have issues, providing management with transparency and enabling them to prioritize their resources where they will deliver the best value.
- Provide clear and accurate data about incidents to people who are helping to resolve them, reducing communication errors and improving incident resolution times.
- Access a knowledge base with information about how other similar incidents have been resolved in the past, allowing the organization to learn from experience, rather than depending on the knowledge of the person managing the specific incident.
- Categorize incidents so that they can see trends, and prioritize problem management activity.
If the organization also implements a problem management process
, they will also be able to:
- Identify trends, based on incident management data, so that they know which incident types need a better way to resolve them.
- Research and document the best way to deal with different incident categories, to enable their best people to influence what happens throughout the organization.
- Understand the costs and benefits of different approaches to incident resolution, and make targeted investments that will improve business performance.
If you have been involved in IT incident and problem management, then I’m sure you can add to this list.
Design for Experience
But before you go off and implement ESM across your organization, I need to offer a warning. As I was writing this blog, I discussed the concept of using incident and problem management with a friend who doesn’t work in IT. Their immediate reaction was “I already waste too much time fighting my computer. I don’t want to waste even more time filling in forms for some IT manager when I could be getting on with my job.”
If you want the benefits of ESM, then you’ll need to think about how people in your organization already view IT, what their current experiences are telling them, and what training they might need. You will need co-operation to get people to change the way they work, and if you don’t design your solution so that it works well for them, then your project is never going to succeed. So make sure you talk to all the stakeholders before you do anything. Understand their concerns and make sure you work with them to design a solution that works for everyone.
So What’s Next?
In this blog, I have given only one example of how incident and problem management processes might be used outside of IT, but I have seen similar approaches in use in many different industries, and I am confident that there are many more I have never imagined.
So, have a think about your own organization. Perhaps you can see how an imaginative application of ITSM tools and processes outside of IT could benefit your organization? If you can think of an ESM solution that will work well and give a great experience to all your stakeholders, don’t let the potential difficulties stop you. You could end up providing your business with a real competitive advantage.
Posted by Stuart Rance
on January 31, 2017 in ITIL
In a previous blog
I talked about “starting where you are” as a guiding principle for people who want to improve outcomes for customers. I talked about how this means not throwing away everything you already do and starting again from zero, and how following this principle can really help you to do a great job when you’re planning IT service management improvements. What I didn’t mention was that “Start where you are” is one of the guiding principles in the new ITIL Practitioner Guidance, which was launched in February 2016. I was delighted to be included as one of the authors of this publication, and I want to tell you a bit more about it.
The ITIL Practitioner Guidance describes nine guiding principles, and I believe everybody in service management should think about all of them, because if you follow these guiding principles, they can really help you succeed.
In addition to Start Where You Are
, the other ITIL guiding principles are as follows:
- Focus on Value: Everything you do should be based on maximizing value for your customers.
- Design for Experience: Think about, and manage, how your users and customers experience your services and their interactions with you.
- Work Holistically: Consider the end-to-end value chain, and how all the bits fit together. Don’t optimize one process or activity at the expense of the overall service.
- Progress Iteratively: Make a series of small improvements, rather than trying to create one enormous project. Agile works really well as an approach to ITSM improvements.
- Observe Directly: Don’t just rely on reports and metrics, go to where the work happens and see what people actually do.
- Be Transparent: Make sure everyone knows what’s happening, engage them early, and make sure they understand organizational goals as well as the actions you’re taking.
- Collaborate: It takes a lot of people to deliver IT, which makes it all too easy for IT teams to have too narrow a focus without due regard for the bigger picture. IT that runs in silos is often the cause of our problems, but if we collaborate across teams then we can do a much better job.
- Keep It Simple: Eliminate everything that you don’t need, so that you can focus on the things that are really important.
We should remind ourselves to think about all of these guiding principles whenever we plan any ITSM improvement. If we could all learn to focus on these things instead of on our processes and technology, then we’d do a much better job for our customers, and we’d create more value for everyone.
Combining the Guiding Principles
Each of the guiding principles I’ve talked about has a lot of value on its own, but the real benefit comes from combining them. For example, you could combine the ideas of Observe Directly
, Be Transparent
, and Collaborate
when you’re carrying out an ITSM assessment. I’ve done this and it leads to great results. For instance, on one assessment I invited the customer to join me when I interviewed the IT people responsible for planning changes and releases. Not only did this give the customer great insight into the issues that IT were dealing with, but it also helped me to create a report that really did focus on customer value. That made for a better result all round.
Another very powerful combination of principles is Focus on Value
, Design for Experience
, Work Holistically
, and Keep It Simple
. I used all four of these principles to make absolutely sure that the new incident management process one customer asked me to design really did work for both the customer and the IT organization involved. Actually, this was another occasion where I engaged the customer in helping to design the process — after all the process was there to satisfy their needs — so, in fact, we also used Collaborate
, Be Transparent
, and Observe Directly
. And really, now that I think about it some more, we also used Start Where You Are
to make sure we didn’t waste the great work that had already been done in this area. That’s eight out of the nine principles right there in just this one example!
And here’s another example of how I’ve used these guiding principles in practice. This story is based on a real client but I’ve changed some of the details for privacy reasons. The organization operated in many countries, and had lots of separate service desks. Some of the service desks supported just a few users, others supported users in four or five different countries. Some of the service desks were managed in-house, others were outsourced. The organization wanted to improve the service offered to roaming users, and to provide a more consistent worldwide service, but they didn’t even have any consistent metrics that they could use to compare quality of service in different locations. They had an “ITIL Consultant” who proposed to create a new process, which could be deployed to all locations. The consultant had told the customer that it would take about nine months to write the documentation for this new process. I worked with the customer to understand the situation, and then proposed a different approach that would deliver value much faster. This is what I recommended:
- Break the work down into a number of activities, each of which would deliver some value — [Progress Iteratively]
- Talk to customers and users, and agree on a small number of business-focused metrics that we would measure for each service desk — [Collaborate], [Focus on Value], [Design for Experience], [Observe Directly]
- Select the two or three best performing service desks and investigate how these could expand to provide support to more locations, replacing poorly performing desks — [Start Where You Are], [Progress Iteratively], [Be Transparent], [Keep It Simple]
- Continue to measure the agreed metrics and allow the best performing service desk to take over gradually over a period of time — [Progress Iteratively], [Start Where You Are]
Whatever you’re responsible for in IT, I think that the ITIL Practitioner guiding principles can really help you to focus on what’s important, for you and for your customers, so please read about them, and think about how you could incorporate them into your work. You can buy the ITIL Practitioner Guidance from AXELOS
, or from TSO
or from other online bookstores. Consider each guiding principle in turn and think about how you could use it to improve what you’re doing, whether this is an improvement project or just doing your normal work.
As always, please let me know how these ideas work out for you. You can contact me easily on Twitter at @StuartRance
Posted by Dena Wieder-Freiden
on January 24, 2017 in Help Desk
Having an external perspective is valuable, and even essential, for an organization to establish improvement ideas. That ability to ”see the wood for the trees” coupled with knowledge of the broader world outside your organization can be helpful. That’s why consultants are often worth the money: to deliver that outside world view and help an organization adopt approaches that have proven to be helpful to others. This is often referred to as following best practice, and getting external help to do so – a traditional IT service management (ITSM) approach taken by many CIOs and IT managers.
But there is another, often equally important, perspective (aside from the wider world view) that an organization should be aware of in pursuit of continual improvement
. And that’s the perception based around familiarity, local knowledge, and shared experience, which is available to companies that want them
. These are far cheaper than the external consultant path, and will complement and refine best practice approaches.
The most powerful concentration of useful knowledge and awareness in many organizations resides right inside their help desk
– especially true if that help desk is internal and local to the user community.
Let Your Help Desk Help You
Collecting and analyzing data is an important and valuable exercise. At the heart of good problem management is working with the collected incident data, seeking trends and patterns, and initiating corrective or, better yet, preventative actions. Don’t stop doing that, but remember also that users are people, and the heart of the help desk role is people-to-people communication. So… along with looking at the cold, hard statistics, it makes good sense to collect information on how your users actually feel about the services you deliver, the things you get right, and the things you get wrong. In fact, what exactly do they see as right and wrong? Their ideas may not line up with yours.
A good help desk offers IT management a quick, simple, and reliable route towards understanding how their users actually feel about the services delivered. But how often do those IT managers do the simple and obvious thing: go and talk to the help desk staff. So much can be gained from opening channels of conversation, no need for anything too formal, just go and talk to them, maybe over coffee or even a beer?
A Conversation Is Worth a Thousand Statistics
In fact, talking with front line staff is, and always has been, a good plan for most organizations. As mentioned earlier, this shouldn’t be seen as an alternative to formal analysis but as a human-oriented complement to statistical and factual analysis.
A whole range of subtler nuances are available from ongoing dialogues with help desk staff, and even more from sitting down and watching them in action. For example, here are some things that might be learned/discovered:
- How often do they need to calm users down before they can capture relevant information? Is it clear why the users get upset? Is it just that they need their services fixed, or is the mechanism you have for calling the help desk part of the problem? Features that are attractive from a supplier perspective – like menu choices (the press 1 for complaints, press 2 for requests kind of thing) – may cause users to get even more upset than they initially were when they decided to call the help desk!
- How much user self-help is going on out there? The conversations that help desk staff have are likely to expose how often users have tried to fix things themselves, and how often they have discussed and tried approaches with colleagues before calling the help desk. This kind of information is rarely captured by any formal mechanism but should have influence over how services are built, maintained, and supported.
- And, crucially, how happy are the help desk staff? That might not sound like a top priority but consider how expensive staff turnover can be – recruitment, training, security clearance, etc. before a new staff member is fully contributing. Keeping staff happy is key to reducing those kinds of costs.
Keep the Conversations Going
Of course, the help desk people are not the only staff a manager could usefully spend time with. Second and third line support personnel have their own tales to tell, as do service level managers. In fact, just about every one of them offers information and early warning signs about possible future issues.
Therefore, don’t just rely on measurements and numbers – remember that service is about people, so take the time to talk to those people who are out there delivering those services on your behalf.
Posted by Stuart Rance
on January 17, 2017 in ITSM
I visited two very different customers recently. They had very different problems and the solutions I suggested for them were also very different. But there was one thing that they had in common — they had both delayed starting the improvements they knew were needed because the costs and risks were too high. Instead, they had done nothing and so allowed their problems to continue completely unchecked.
For both these customers, the solution was very similar. Both needed to “Start where you are”, “Keep it simple” and “Progress iteratively”. These are three of the guiding principles from ITIL Practitioner, and between them they encourage IT service managers to adopt an agile approach to resolving issues, rather than taking on big, risky, expensive IT service management (ITSM) projects. I created a few podcasts on these topics for SysAid’s Back to ITSM Basics
project, so please do listen to those if you are interested.
If you also need improvements that seem too expensive, or too risky, then read on to learn how you can get started.
A Big Organization with a Big Problem
One of the organizations that I visited is very large. It provides support services to many external customers all over the world, and has lots of service desks. Some of these service desks are dedicated to a single customer, others support multiple customers, and some are for internal users. Some of them provide logging and dispatch only, others provide level 1 support as well. While many of the service desks use the same ITSM tool for logging and managing incidents, there are quite a few other tools in place as well.
Almost all of the customer communication, for all the different service desks, takes place by phone. The organization would like to shift to more efficient channels, e.g. text-based chat and a self-service
web portal, but because the company is so big, the implementation costs would be enormous. IT has, in fact, identified a tool that could provide chat for all of their complex environment, but since they can’t be confident that an implementation project would run smoothly or that the returns would justify such a big investment, they can’t get the funding for this.
As I talked to the IT department, the solution to their problem became obvious. Instead of trying to implement chat for all of their users, which would be a very big and expensive project, they could start where they are, start small, and grow in small steps.
The organization’s users already have a tool that supports chat, although it is not currently used for IT support. So it would be quite easy for IT to start there.
Here’s what they can do:
Find a small group of users and offer to use this existing tool to provide them with IT support. Monitor carefully to reveal any issues for the service desk or the users, and resolve them before scaling up to support more internal users. Eventually the IT department will reach the limits of how well this tool can scale in their environment, but by then they will have:
- Identified and resolved many issues relating to how the service desk works when handling chat-based interactions
- Understood which types of incident are best handled by chat, and which are better managed using phone or other channels
- Discovered what communication and support works best to encourage users to migrate from phone to chat
- Collected data about how many calls each service desk agent can manage using chat, and how much this could save if scaled up to the whole organization
This gradual implementation of chat would be very low risk, and, by starting with a tool that is already in use and familiar, would not involve much cost. By the time the IT department has scaled up to supporting a large number of internal users they will know whether a full implementation using an expensive tool will be a cost-effective investment, and they will also have learned what needs to be done to ensure success. If they wish to go ahead with an expensive new tool, this will give them everything they need to create a business case for the next stage.
A Small Organization with a Security Problem
The other organization that I visited is MUCH smaller. They have just two staff working on their in-house service desk, supported by a manager who carries out other roles as well. They have a few thousand users in a small number of offices, all in a small part of one country. They are finding it difficult to manage user access controls.
When a new user joins the organization, they ask about what access this user needs, and then grant individual rights to the specific applications and data. When people change jobs or leave the organization, it’s difficult to find all the access rights that have been granted, so these are often left in place – and this creates a significant security risk.
The support manager knew that the solution to their issue was to move to role-based access controls (RBAC), where all access rights are granted to roles, and then those roles are assigned to users. But there had been no attempt to migrate to RBAC because of the risks involved. Sometimes things go wrong during even the best planned migrations, and this could cause significant cost and risk to the business.
The solution for this customer was also to take an agile approach. Instead of attempting to change everything at the same time, the organization could start where it is, keep it simple, and do it a bit at a time.
Here’s what they can do:
Next time a new employee joins the company, grant all the rights that user needs to a newly created role, and then assign this role to the new user. This should be no more work and no more risk than would normally be involved in providing appropriate access to a new user. Once confident that the role works well, and that no changes are needed, go on to migrate one existing user to the role, removing the current rights that user has. Again, this would carry only a small amount of risk, and the change could be undone quickly and easily. Next, continue adding users a few at a time. Once confident that there are unlikely to be any issues, move over everyone else who should be assigned to that role. When the opportunity arises, create a second role, and migrate users in the same incremental, low-risk, way.
This approach means it will take quite a long time to completely move from the current situation to a well-managed RBAC implementation. But the one improvement that you can guarantee will never be finished is the one you think it’s too risky to start in the first place. By starting where you are, keeping it simple, and progressing incrementally, the improvement this company wants will eventually be achieved, with little risk, and without a big project that keeps its two support staff tied up and unavailable for long stretches of time.
Many organizations use agile software development to reduce risk and speed up time to market. The same ideas apply equally well to ITSM
. Almost every ITSM improvement can be carried out in an agile way, and there really is no need for huge, expensive ITSM improvement projects.
If you’ve been putting of improvements that you KNOW you need, because of the cost and risk, then why not think about how you can “Start where you are”, “Keep it simple” and “Progress iteratively”?