2013: A Year in ITSM Review

Merry Christmas and a Happy New Year!
Merry Christmas and a Happy New Year!

As 2013 begins to draw to a close, I thought it would be nice to finish off the year with a final article that’s an overview of what has happened at the ITSM Review over the last 12 months.  That’s right, this will be our last post for 2013 because the entire team is heading off to fill their faces with mince pies and sherry. But don’t worry we’ll be back in 2014 with slightly bigger waistlines and lots of exciting plans for 2014 (insight into which you can find at the end of this article).

Ironically I like neither mince pies nor sherry. 

Visits and Growth

  • We have had nearly 230,000 page views this year, an increase of a whopping 210% from 2012!!! A huge thank you to the circa 120,000 of you for coming to read our content.
  • Visits to our site increased by an astounding 58% between the end of June and end of July alone, and then continued to grow on average by 5.5% every month.
  • Our Twitter followers increased by 193%.

One thing that I think it’s worth pointing out here as well is that the bulk of our readers are not actually situated in the UK (which is what a lot of people presume given that this is where we are based). In 2013, 17% of our readers were from the UK, but an impressive 30% were actually from the USA. Perhaps we should open a US office?! A large proportion of visitors also came from India, Germany, Australia, Canada, The Netherlands, France and Sweden, as well as plenty of other countries too.

Owing to us attracting more and more visitors year-on-year from outside of the UK and America, we are increasingly being asked to produce region-specific content. We are therefore looking for practitioners, consultants or analysts based in Asia, South America, Africa, and Europe who would be interested in writing about their experiences of ITSM in other countries. If you are interested please get in touch.

What was popular?

The top 3 most-viewed articles of the year were:

  1. 7 Benefits of using a Known Error Database (by Simon Morris)
  2. Gartner Magic Quadrant for IT Service Support Management Tools (Martin Thompson)
  3. AXELOS: Capita and ITIL joint venture lift lid on new brand (Martin Thompson)

Of those articles only number 3 was actually written and published in 2013.

I have to say congratulations specifically to Simon Morris here as well, because his KEDB article was not only the most-read article of the year, but it achieved 37% more hits than the second most popular article of the year! (And that’s not counting the hits it originally got in the year it was published).

Of the articles written and contributed in 2013, the top 3 were:

  1. Future of ITIL workshop – a little insight (Stuart Rance and Stephen Mann)
  2. Four Problem Management SLAs you really can’t live without (Simon Higginson)
  3. 7 golden rules for getting the most from the Service Catalogue (Yemsrach Hallemariam)

Is there a specific topic that you would like us to write about? Are there are practical pieces that you would like to see us cover to help you in your day-to-day job? Please let us know.

Content Contributors

In 2013, we were pleased to welcome 3 new, regular content contributors to the ITSM Review.  These are people who now write for us on a regular basis (roughly once a month), so you can expect to see a lot more great content from them in 2014. They are:

We also published content for the first time from the following companies: Cancer Research UK; EasyVista; Fruition Partners; GamingWorks; LANdesk; Macro4; Oregon Department of Transportation; Service Management Art Inc; and xMatters.

A great big thank-you to all of our regular and ad hoc contributors for helping supply with us with such fantastic content.

If you’re reading this and think you might be interested in contributing content (we welcome content from all, including) please get in touch.

Top Searches

Given that we had over 230,000 pages view this year, I thought that many of you might be interested to see what it was that people were searching for on our site.  The top 20 searches of the year were as follows:

  1. KEDB
  2. AXELOS
  3. Known Error Database
  4. ITSM
  5. Issue Log
  6. Proactive Problem Management
  7. ITSM Software
  8. Gartner ITSM
  9. What is Service Management
  10. Cherwell Software Review
  11. Gartner ITSM Magic Quadrant
  12. ServiceNow Review
  13. ITSM Software Review
  14. ITSM News
  15. Major Incident Management Process
  16. Free ITIL Training
  17. RemedyForce Review
  18. BMC Footprints
  19. KEDB in ITIL
  20. Process Owner

Are there any search terms that you are surprised to see on there?  Or anything that you would have expected to see that isn’t?

Events

In 2013 we branched out and kicked off Media Partnerships at the itSMF UK Conference and Exhibition (Birmingham) and itSMF Estonia Conference (Tallin).

Our aim was not only to spread the word about The ITSM Review, but to spend time with delegates to find out what things they are struggling with and how we might be able to help them.

Next year you can expect to see us the PINK conference in Las Vegas, and we hope to announce some other new, exciting partnerships for 2015 in the New Year!

Launches

In May we launched the ITSM Review App (Search ‘ITSM’ in the Apple App Store). 

Then there is the ITSM Tools Universe, which we launched at the end of November. The Tools Universe hopes to shed light on the emerging ITSM players (as well as the major competitors) and, over time, the changes in the position of the companies involved and moves in market share. Most importantly it is free to participate and unlike any Magic Quadrant or Wave, the ITSM Tools Universe is open to ALL ITSM vendors. 9 vendors are already confirmed.

If you are a Vendor and are interested in learning more the ITSM Tools Universe please contact us.

Additions to the team

As of 1st January 2013 the ITSM Review was still simply just the man you all know and love Martin Thompson (he tried desperately to get me to remove what I just said there… modest and all that jazz).

However, ITSM Review finished 2013 with an additional 3 employees:

  • In January 2013 Glenn Thompson (you’d be right to suspect that they might be related) joined full-time as the company’s Commercial Director. For some reason there was no official announcement (we’ll blame Martin) so for some of you this might be the first you’ve heard of it! Without Glenn we’d struggle to continue to offer all of our content to readers free of charge, so despite the fact that he’s a Chelsea fan, you’ve got to like him.
  • In July, for some reason Martin decided it would be a good move to hire some strange blonde lady who liked penguins (that would be me) as the Marketing and Community Manager.
  • Finally, in October Rebecca Beach joined as a Research Analyst. Famous for being a “gobby midget”, Rebecca will be writing most of our ITSM research and reviews in 2014. Rebecca also spends time (in conjunction with me) making fun of Martin and Glenn on a regular basis (it’s not our fault they make it so easy).

So then there was 4.

If you’re interested in any upcoming job opportunities at the ITSM Review (or ITAM Review), then please let us know.  We certainly plan on increasing that number 4 in 2014.

What’s planned for 2014?

Next year we are hoping to broaden our coverage of the ITSM space even further by securing new content contributors; participating in more industry events; launching new products (such as video product reviews, webinars, and case studies); and more.

We’re also looking very seriously at the possibility of running regular ‘social meet ups’ like we recently did with the Christmas get-together.

In addition to the publication of our ITSM Tools Universe in the Spring we will also be continuing our Group Tests, and a full list of topics for the Group Test series will be published early January.

In addition to the above we also have some planned changes in the works for our website. Nothing too major (it will still look like the ITSM Review that you know and love), just some cosmetic updates to make it easier on the eye and increase your ability to easily find what you are looking for.

Watch this space and we’ll keep you updated of our plans throughout 2014!

Oh and if you’re interested in the 2013 review and plans for 2014 from the ITAM Review, you can read them here.

Is there anything you would like to see us doing in 2014 that we’re not doing currently? Are there any changes that you would like to suggest to the website? Would you be interested in a tooling event or social get-togethers? Are you a Vendor who is interested in our Group Tests? We welcome your feedback, so please get in touch.

And so…

2013 is drawing to a close. Our success and growth throughout the year has made everybody here happy bunnies; but most importantly we hope that our content / site / presence this year has made YOU a bunch of happy bunnies. The whole purpose of the ITSM Review is to help ITSM practitioners, and everything we do has that end goal in mind.  Even if we only gain an additional 5 readers in 2014, so long as our content aids those 5 people and makes their work lives easier then these bunnies will continue to have smiles on their faces.

So with that image of turning the entire ITSM industry into smiley rabbits, I bid you all a Merry Christmas and a Happy New Year!  Thanks for reading throughout 2013; without you… the ITSM Review doesn’t exist.

Image Credit

7 Benefits of Using a Known Error Database (KEDB)

KEDB - a repository that describes all of the conditions in your IT systems that might result in an incident for your customers.

I was wondering – do you have a Known Error Database? And are you getting the maximum value out of it?

The concept of a KEDB is interesting to me because it is easy to see how it benefits end users. Also because it is dynamic and constantly updated.

Most of all because it makes the job of the Servicedesk easier.

It is true to say that an effective KEDB can both increase the quality and decrease the time for Incident resolution.

The Aim of Problem Management and the Definition of “The System”

One of the aims of Problem Management is to identify and manage the root causes of Incidents. Once we have identified the causes we could decide to remove these problems to prevent further users being affected.

Obviously this might be a lengthy process – replacing a storage device that has an intermittent fault might take some scheduling. In the meantime Problem Managers should be investigating temporary resolutions or measures to reduce the impact of the Problem for users. This is known as the Workaround.

When talking about Problem Management it helps to have a good definition of “Your System”. There are many possible causes of Incidents that could affect your users including:

  • Hardware components
  • Software components
  • Networks, connectivity, VPN
  • Services – in-house and outsourced
  • Policies, procedures and governance
  • Security controls
  • Documentation and Training materials

Any of these components could cause Incidents for a user. Consider the idea that incorrect or misleading documentation would cause an Incident. A user may rely on this documentation and make assumptions on how to use a service, discover they can’t and contact the Servicedesk.

This documentation component has caused an Incident and would be considered the root cause of the Problem

Where the KEDB fits into the Problem Management process

The Known Error Database is a repository of information that describes all of the conditions in your IT systems that might result in an incident for your customers and users.

As users report issues support engineers would follow the normal steps in the Incident Management process. Logging, Categorisation, Prioritisation. Soon after that they should be on the hunt for a resolution for the user.

This is where the KEDB steps in.

The engineer would interact with the KEDB in a very similar fashion to any Search engine or Knowledgebase. They search (using the “Known Error” field) and retrieve information to view the “Workaround” field.

The “Known Error”

The Known Error is a description of the Problem as seen from the users point of view. When users contact the Servicedesk for help they have a limited view of the entire scope of the root cause. We should use screenshot of error messages, as well as the text of the message to aid searching. We should also include accurate descriptions of the conditions that they have experienced. These are the types of things we should be describing in the Known Error field A good example of a Known Error would be:

When accessing the Timesheet application using Internet Explorer 6 users experience an error message when submitting the form.

The error message reads “Javascript exception at line 123”

The Known Error should be written in terms reflecting the customers experience of the Problem.

The “Workaround”

The Workaround is a set of steps that the Servicedesk engineer could take in order to either restore service to the user or provide temporary relief. A good example of a Workaround would be:

To workaround this issue add the timesheet application to the list of Trusted sites

1. Open Internet Explorer 2. Tools > Options > Security Settings [ etc etc ]

The Known Error is a search key. A Workaround is what the engineer is hoping to find – a search result. Having a detailed Workaround, a set of technical actions the Servicedesk should take to help the user, has multiple benefits – some more obvious than others.

Seven Benefits of Using a Known Error Database (KEDB)

  1. Faster restoration of service to the user – The user has lost access to a service due to a condition that we already know about and have seen before. The best possible experience that the user could hope for is an instant restoration of service or a temporary resolution. Having a good Known Error which makes the Problem easy to find also means that the Workaround should be quicker to locate. All of the time required to properly understand the root cause of the users issue can be removed by allowing the Servicedesk engineer quick access to the Workaround.
  2. Repeatable Workarounds – Without a good system for generating high-quality Known Errors and Workarounds we might find that different engineers resolve the same issue in different ways. Creativity in IT is absolutely a good thing, but repeatable processes are probably better. Two users contacting the Servicedesk for the same issue wouldn’t expect a variance in the speed or quality of resolution. The KEDB is a method of introducing repeatable processes into your environment.
  3. Avoid Re-work – Without a KEDB we might find that engineers are often spending time and energy trying to find a resolution for the same issue. This would be likely in distributed teams working from different offices, but I’ve also seen it commonly occur within a single team. Have you ever asked an engineer if they know the solution to a users issue to be told “Yes, I fixed this for someone else last week!”. Would you have prefered to have found that information in an easier way?
  4. Avoid skill gaps – Within a team it is normal to have engineers at different levels of skill. You wouldn’t want to employ a team that are all experts in every functional area and it’s natural to have more junior members at a lower skill level. A system for capturing the Workaround for complex Problems allows any engineer to quickly resolve issues that are affecting users.Teams are often cross-functional. You might see a centralised application support function in a head-office with users in remote offices supported by their local IT teams. A KEDB gives all IT engineers a single place to search for customer facing issues.
  5. Avoid dangerous or unauthorised Workarounds – We want to control the Workarounds that engineers give to users. I’ve had moments in the past when I chatted to engineers and asked how they fixed issues and internally winced at the methods they used. Disabling antivirus to avoid unexpected behaviour, upgrading whole software suites to fix a minor issue. I’m sure you can relate to this. Workarounds can help eliminate dangerous workarounds.
  6. Avoid unnecessary transfer of Incidents – A weak point in the Incident Management process is the transfer of ownership between teams. This is the point where a customer issue goes to the bottom of someone else queue of work. Often with not enough detailed context or background information. Enabling the Servicedesk to resolve issues themselves prevents transfer of ownership for issues that are already known.
  7. Get insights into the relative severity of Problems – Well written Known Errors make it easier to associate new Incidents to existing Problems. Firstly this avoids duplicate logging of Problems. Secondly it gives better metrics about how severe the Problem is. Consider two Problems in your system. A condition that affects a network switch and causes it to crash once every 6 months. A transactional database that is running slowly and adding 5 seconds to timesheet entry You would expect that the first Problem would be given a high priority and the second a lower one. It stands to reason that a network outage on a core switch would be more urgent that a slowly running timesheet system But which would cause more Incidents over time? You might be associating 5 new Incidents per month against the timesheet problem whereas the switch only causes issues irregularly. Being able to quickly associate Incidents against existing Problems allows you to judge the relative impact of each one.

The KEDB implementation

Technically when we talk about the KEDB we are really talking about the Problem Management database rather than a completely separate store of data. At least a decent implementation would have it setup that way.

There is a one-to-one mapping between Known Error and Problem so it makes sense that your standard data representation of a Problem (with its number, assignment data, work notes etc) also holds the data you need for the KEDB.

It isn’t incorrect to implement this in a different way – storing the Problems and Known Errors in seperate locations, but my own preference is to keep it all together.

Known Error and Workaround are both attributes of a Problem

Is the KEDB the same as the Knowledge Base?

This is a common question. There are a lot of similarities between Known Errors and Knowledge articles.

I would argue that although your implementation of the KEDB might store its data in the Knowledgebase they are separate entities.

Consider the lifecycle of a Problem, and therefore the Known Error which is, after all, just an attribute of that Problem record.

The Problem should be closed when it has been removed from the system and can no longer affect users or be the cause of Incidents. At this stage we could retire the Known Error and Workaround as they are no longer useful – although we would want to keep them for reporting so perhaps we wouldn’t delete them.

Knowledgebase articles have a more permanent use. Although they too might be retired, if they refer to an application due to be decommissioned, they don’t have the same lifecycle as a Known Error record.

Knowledge articles refer to how systems should work or provide training for users of the system. Known Errors document conditions that are unexpected.

There is benefit in using the Knowledgebase as a repository for Known Error articles however. Giving Incident owners a single place to search for both Knowledge and Known Errors is a nice feature of your implementation and typically your Knowledge tools will have nice authoring, linking and commenting capabilities.

What if there is no Workaround

Sometimes there just won’t be a suitable Workaround to provide to customers.

I would use an example of a power outage to provide a simple illustration. With power disrupted to a location you could imagine that there would be disruption to services with no easy workaround.

It is perhaps a lazy example as it doesn’t allow for many nuances. Having power is a normally a binary state – you either have adequate power or not.

A better and more topical example can be found in the Cloud. As organisations take advantage of the resource charging model of the Cloud they also outsource control.

If you rely on a Cloud SaaS provider for your email and they suffer an outage you can imagine that your Servicedesk will take a lot of calls. However there might not be a Workaround you can offer until your provider restores service.

Another example would be the February 29th Microsoft Azure outage. I’m sure a lot of customers experienced a Problem using many different definitions of the word but didn’t have a viable alternative for their users.

In this case there is still value to be found in the Known Error Database. If there really is no known workaround it is still worth publishing to the KEDB.

Firstly to aid in associating new Incidents to the Problem (using the Known Error as a search key) and to stop engineers in wasting time in searching for an answer that doesn’t exist.

You could also avoid engineers trying to implement potentially damaging workarounds by publishing the fact that the correct action to take is to wait for the root cause of the Problem to be resolved.

Lastly with a lot of Problems in our system we might struggle to prioritise our backlog. Having the Known Error published to help routing new Incidents to the right Problem will bring the benefit of being able to prioritise your most impactful issues.

A users Known Error profile

With a populated KEDB we now have a good understanding of the possible causes of Incidents within our system.

Not all Known Errors will affect all users – a network switch failure in one branch office would be very impactful for the local users but not for users in another location.

If we understand our users environment through systems such as the Configuration Management System (CMS) or Asset Management processes we should be able to determine a users exposure to Known Errors.

For example when a user phones the Servicedesk complaining of an interruption to service we should be able to quickly learn about her configuration. Where she is geographically, which services she connects to. Her personal hardware and software environment.

With this information, and some Configuration Item matching the Servicedesk engineer should have a view of all of the Known Errors that the user is vulnerable to.

Measuring the effectiveness of the KEDB.

As with all processes we should take measurements and ensure that we have a healthy process for updating and using the KEDB.

Here are some metrics that would help give your KEDB a health check.

Number of Problems opened with a Known Error

Of all the Problem records opened in the last X days how many have published Known Error records?

We should be striving to create as many high quality Known Errors as possible.

The value of a published Known Error is that Incidents can be easily associated with Problems avoiding duplication.

Number of Problems opened with a Workaround

How many Problems have a documented Workaround?

The Workaround allows for the customer Incident to be resolved quickly and using an approved method.

Number of Incidents resolved by a Workaround

How many Incidents are resolved using a documented Workaround. This measures the value provided to users of IT services and confirms the benefits of maintaining the KEDB.

Number of Incidents resolved without a Workaround or Knowledge

Conversely, how many Incidents are resolved without using a Workaround or another form of Knowledge.

If we see Servicedesk engineers having to research and discover their own solutions for Incidents does that mean that there are Known Errors in the system that we aren’t aware of?

Are there gaps in our Knowledge Management meaning that customers are contacting the Servicedesk and we don’t have an answer readily available.

A high number in our reporting here might be an opportunity to proactively improve our Knowledge systems.

OLAs

want to ensure that Known Errors are quickly written and published in order to allow Servicedesk engineers to associate incoming Incidents to existing Problems.

One method of measuring how quickly we are publishing Known Errors is to use Organisational Level Agreements (or SLAs if your ITSM tool does’t define OLAs).

We should be using performance measurements to ensure that our Problem Management function is publishing Known Errors in a timely fashion.

You could consider tracking Time to generate Known Error and Time to generate Workaround as performance metrics for your KEDB process.

In summary

Additionally we could also measure how quickly Workarounds are researched, tested and published. If there is no known Workaround that is still valuable information to the Servicedesk as it eliminates effort in trying to find one so an OLA would be appropriate here.