IT Service Management is a fairly arcane area which can be fraught with danger and pitfalls. Pat Bolger, Chief Evangelist at Hornbill Service Management, tells us more on what ITSM entails and how you make sure you select the most appropriate solution.
What are the main challenges that businesses face when selecting an IT Service Management tool?
Selecting an IT Service Management (ITSM) tool which meets business needs is a significant decision; faced with a number of vendors and tools, it can be a long and complicated process. Whether replacing an existing tool or beginning from scratch, IT groups share common challenges; although these tend to differ according to their level of ITSM maturity. At lower levels of maturity, IT groups may struggle with definition and documentation of basic ITSM processes, such as Service Request, or Problem Management. At higher levels of maturity, the battle may be costing of services and effective mechanisms for charging, or showing the cost of consumption. Yet the greatest challenge for most IT groups is maintaining focus on the primary reason for implementing a new tool, which is to deliver benefit and value to end users; not just to IT.
How should businesses be approaching the selection process; and what should they consider first?
When looking to implement a new tool, it’s critical to first understand how well your existing processes serve users’ needs and reflect upon the overall service experience. Demand for services always exceeds IT’s capacity to supply, so it’s important to understand how the tool can help eliminate low-value interactions that are an irritant both to IT and the end user. A new tool should provide opportunities to simplify and automate low value interactions and create capacity to focus on interactions that are of greater value to the business. This helps define the criteria for service improvement, drives selection of the right solution, and helps determine whether the tool needs extensive configuration or even customisation to deliver the desired outcomes.
What are the common mistakes that businesses make during the selection process?
The criteria for tool selection outlined in requirements documents tend to focus heavily on compatibility with ITIL processes. Although this is likely to be a major requirement, it should not be the primary focus when selecting a tool. The global wave in adoption has driven vendors to produce ITIL ‘compatible’ solutions: as a result, most commercial tools support the framework. Yet this offers no guarantee that the software will deliver what the organisation needs. During the selection process stakeholders are exposed to several solutions. The primary objectives of delivering benefit to the business and improving service quality can easily be derailed by slick demonstrations and the lure of shiny product features that ultimately don’t address real needs and challenges.
Why it is important for businesses to have clearly defined and documented processes in place before the procurement of any new solution?
When processes are clearly defined and documented, it is much easier for IT to determine how they can to be improved to increase quality and deliver a better service experience. This makes it easier for vendors to demonstrate how their tools support these processes, meaning IT stakeholders can feel more secure about their purchasing decision. However, many IT groups do not have well-defined or documented processes in place: even if they do, those processes are likely to change during on-going service improvement and as ITSM maturity increases. Fortunately, most modern tools are shipped with out-of-the-box processes that provide a decent foundation for less mature IT groups; as well as graphical workflow tools that make it easy to make changes without having to write code or dip into heavy customisation.
What are the main differences between settings, configurations and customisation, and how can they best be used?
While all provide a means of tailoring a product to fit specific needs, the differences between settings, configurations and customisation can be confusing. It may help to use a familiar example: if you purchase a new car, you’ll need to adjust the seat, mirrors, and steering wheel position for safety and comfort. These are simply settings, which do not change the car’s performance or function. Using the on-board computer, you can adjust the suspension settings; or even gear ratios. These standard options are provided by the manufacturer, enabling drivers to ‘configure’ the car for a sportier ride. If you want to race the car, you’ll need to make changes to several other settings: perhaps having the engine tuned, or swapping out the suspension or exhaust to boost performance and handling.
Manufacturers offer a particular model of car, but with numerous variations or options to suit the needs of different drivers. A typical family just wants to get from A to B safely and quickly; a hobbyist may want to change the look or performance of the vehicle; while the racing driver demands very specific and finely tuned modifications for each racing circuit. Similarly, ITSM groups at different levels of maturity also have different needs. Even if their aspiration is to "race their cars" further down the line, it will be difficult to make performance-enhancing modifications without first knowing how the car handles as standard.
Why should businesses consider ‘out of the box’ tools before jumping into customisation?
Far too often organisations go into a customisation programme at full throttle; without first questioning, or in some cases even defining, how the end user will benefit from changes to their ITSM processes. It can often be the case that an out of the box tool actually supports most of the processes required, without needing significant changes. "Out of the box" tools can provide a sensible starting point, especially for organisations that have not defined their processes. In effect, implementing a tool out of the box gives the organisation a solid foundation, with a set of distinct best practice ITSM processes that can easily be adapted as their maturity increases. By taking an out of the box tool for a "test drive", you can more easily identify your blind spots. Yet without this test drive, identifying these blind spots is a difficult enough task in the first place, let alone understanding what easy changes you can make within a tool to tackle them.
What should those in charge of the selection process be asking themselves in order to make sure they select the best tool for their needs?
Even if you do have well-defined processes and are confident these are appropriate for your organisation, it’s still important to question whether these are in fact the most efficient and effective way of delivering services from the organisation’s perspective. The primary objective of tool selection should be to deliver benefit to the end user: it’s all too easy for this focus to be derailed by "shiny" product features that don’t necessarily map to the main goals for service improvement.
It is also important to recognise that you’re not just investing in a tool; you’re investing in a relationship with the vendor. During the selection process, stakeholders should continually ask the following questions: (a) Has the vendor invested the time and effort to truly understand our challenges? (b) Is the product being demonstrated in a manner that reflects our desired outcomes? (c) Will this vendor remain committed to our on-going success, and be a partner, once we purchase the product?
When would you recommend exploring a customisation process & What are the possible outcomes of a poorly considered customisation programme?
IT groups that change their ITSM supplier will often try to customise the new solution so that it performs the same functions as its predecessor. If all you wanted was a status quo, why change tools in the first place? Customisation should be explored once you have identified the benefits and the desired outcome of the change.
If a need for customisation has been identified, IT teams need to be fully aware of the effects on their ITSM system and its on-going maintenance and upgradeability. Despite vendor claims that customisations can be easily carried forward through upgrades, there’s a tipping point where customisation will take you off an easily upgradable path. If a system is changed to the extent that the supplier might struggle to recognise it, or the tool is being used to deliver outcomes it was never designed for, maintenance and upgrades will be difficult at best and impossible at worst. Even if customisations have been carried out by your own staff and the knowledge and ability to maintain the system remains in-house, that expertise is lost if workers leave the organisation and the on-going capabilities of the tool to meet business needs will suffer.
What are the key points to consider if you decide to go down the path of customisation? What would be your biggest recommendation?
There are undoubtedly areas where it may be necessary to customise IT systems extensively. If a business has a specific need that is not met by out-of-the-box tools, or by changing the tool through standard configuration settings, then customisation may be the only option. However, it is still easy for organisations to customise themselves into a corner; adding often unnecessary layers of complexity through customisation.
Engage the vendor early on to find out how to avoid this. You may want them to configure, or even customise the tool for you; however, if a vendor advises a 30-60 day timescale to implement a bespoke process alarm bells should start ringing. If you know what process you are looking to achieve then customisation shouldn’t actually be a difficult procedure, certainly not one that takes a month or more to deliver. My biggest recommendation is to continually ask why; and be clear about the outcomes customisation will deliver over the functions the tool provides out-of-the-box. This clarity minimises wasted effort and ensures IT systems meet end-user needs, enhance the service experience, and truly deliver business value.
Picture courtesy of Flickr/dChris