Corporate IT functions are being squeezed by an increasing variety of business pressures and constraints. Not only the enterprise-wide mandate to ‘do more with less’, but IT-specific drivers to demonstrate business value (through business alignment) and the need to maximise the availability of business critical applications. In addressing this squeeze, business adoption of the IT Infrastructure Library (ITIL) process framework has both raised the profile of, and increased the necessity for, tools to support IT Service Management (ITSM).
ITSM has evolved beyond the basics of Incident Management (the traditional ‘Four Rs’ of record, route, resolve, and report) with IT needing to rise to additional challenges that include the introduction of service level, problem, change and release, configuration, availability, and capacity management. IT also has to adapt customer-facing processes to accommodate the realisation that what was once the IT Help Desk should now be operating as a Service Desk and appreciate that, in this IT-dependent world, there are no longer IT issues; only business-affecting issues that the IT function must proactively manage for.
Prior to the introduction of ITIL v3, ITSM tools were expected to support one or more of the eleven ITIL v2 Service Support and Service Delivery elements. However, with ITIL v3, Service Support and Service Delivery were replaced by Service Design, Service Strategy, Service Operation, Service Transition, and Continual Service Improvement. The eleven original disciplines remain and are supplemented with a host of new and ‘promoted’ processes such as Service Catalogue Management, Supplier Management, Information Security, Service Portfolio Management, Demand Management, Self Service, Event Management, Access Management, and Knowledge Management.
In reality, organisations will only adopt the ITSM processes they deem fit, and even then to a level that meets their own requirements. Consequently, the choice of an ITSM-supporting tool is complicated by the effective implementation of the organisation’s ITSM processes given that ITSM tool deployments should be process-driven. There is also added complexity given that different ITSM solutions support different ITSM processes, to varying degrees and, therefore, organisations must ensure that their choice of solution fits both current and future needs (as their existing processes mature and ITIL adoption widens).
So where should an organisation wishing to select an ITSM tool, or tools, start? There is always the temptation to ‘see what is out there’ and become enthralled by the exciting functionality offered by a particular solution. However, organisations should start closer to home – initially deciding upon the ITSM processes they wish to support and automate. For some organisations this will be relatively easy, taking existing processes and considering how these will evolve, and be added to, in the short- to medium-term. For others, usually where existing IT support activities have yet to be aligned to ITIL best practice, they will need to undertake an ITIL-focused process maturity assessment to understand the process improvement activity required to become ITIL-compliant. Such an organisation may opt to only design a few of the processes in detail but must remain aware of what they may want to achieve, in terms of additional processes, in the future. Butler Group recommends that organisations, during process design, distinguish processes from procedures, from detailed work instructions, to minimise the future impact (in terms of document revision) of legitimate day-to-day operational changes.
There is, of course, a swathe of preparatory activity required both before and in parallel with process design and the requirements specification. The corporate adoption of ITIL and ITSM processes must be endorsed at board-level, with their consistent utilisation mandated throughout the organisation, ranging from the use of the Service Desk as the single point of contact for all IT issues, to the mandatory adoption of a single corporate Change Management process for all IT-related changes. Both IT and non-IT staff also need to be ‘sold’ on the benefits of ITIL and ITSM tool adoption, with continued communications throughout the life of the technology deployment, and the process and organisational change project.
The ITSM process design work will form the basis for the ITSM toolset’s specification of requirements. It is important that these requirements should be split between those that are mandatory and those that are desirable; and once determined, that mandatory requirements must not be compromised. Of course, IT vendors with offerings that do not meet all of the mandatory requirements will try to convince organisations that the requested functionality is not really necessary, but they must consistently remind themselves that their people and processes are driving the technology utilisation and not the reverse.
In specifying the functional requirements, an organisation must consider the requirements for integration. This is not only the integration between ITIL processes (and maybe the discrete ITSM tools that will be used to support different processes), for example Configuration Management with Incident, Problem, and Change Management as a minimum. It is also the ability to easily, and seamlessly, integrate the ITSM toolset with existing corporate Systems Management tools – ranging from the low-level submission of Event Management information to the Incident Management system to network discovery data auto-populating the Configuration Management Database (CMDB), if these activities are not themselves part of the ITSM toolset’s functionality. The requirements must also be created with a mindset that envisions the toolset’s utilisation evolving, along with the organisation’s ITIL processes, over a five year time period – ensuring that it can deliver against future, as well as current, process-enabling needs.
This technology and inter-process integration is critical to support process automation and optimisation and, unfortunately for intra-IT function team politics, it extends outside of Run the Business teams (who are seen as the core users of the ITSM toolset) to include Change the Business resource. A possible scenario would be where a Procedural Support or Application Development team actively receive, and resolve, incident related calls on a daily basis. Under ITIL these must be recorded in the corporate Incident Management system and hence both the process and ITSM toolset must also be adopted by the Change the Business teams. Also, to achieve the highest levels of accuracy, Butler Group recommends that organisations define, and run through real-life, what-if scenarios to ensure that their ITSM toolset requirements have been fully fleshed out and understood by all interested parties.
These requirements should then be prioritised, using a suitable weighting system. Emphasis should be placed on attributes which could possibly be underweighted as ‘non-core process functionality’: roles and responsibility features
(in light of compliance requirements); automation features including notification, escalation, and approval; and reporting capabilities such as end-to-end visibility, dashboards, and the support of organisation-defined ITSM metrics (KPIs). The organisation is then ready to shortlist potential tools (and vendors) based on their most important requirements.
Depending on the organisation’s sourcing strategy, the shortlist may be a mix of ITSM solutions that deliver against all ITIL processes and those that deliver against a particular subset. The solutions of the big four IT Management Software vendors have the greatest breadth of functionality whilst specialist vendors will potentially have more depth across fewer ITIL processes. Unless the corporate sourcing strategy mandates otherwise, Requests For Information or Requests For Tender should be supplied to ten to fifteen shortlisted vendors across both categories. Upon receipt of vendor responses, organisations should rank the products using the internally agreed weightings; to identify the top two or three solutions (which may include groups of products) on which to do a detailed assessment, and consequently obtain detailed, face-to-face vendor presentations, and evaluation copies of the tools for use within the organisation.
If not already considered, it is as this point that the procuring organisation must look beyond the day-to-day functionality provided by the solutions at how vendors are able to assist with the softer issues involved with the introduction of ITSM tools. This includes how they can assist with the necessitated people- and process-based changes; and whether they have proven methodologies to help address the cultural and organisational impact of the imminent changes. Whilst the new technology will ideally meet the demands of existing IT processes, due to process immaturity it might also be necessary for the vendor to assist in the delivery of best practice processes, tweaked to suit corporate needs and intricacies. Vendors must also demonstrate that they can deliver tailored, in-process training; how their solutions can actively ensure compliance; and can deliver KPI information for effective management.
Vendor knowledge and experience can also be leveraged in two productivity-based areas. Firstly, whilst the introduction of ITSM technology can save time and resource, the concerted, consistent application of ITIL-based ITSM processes and procedures will potentially increase workloads (even if only in the short-term). Vendors should be able to predict the initial impact on the Incident Lifecycle, and the required levels of ramp-up resourcing (which will also be impacted by any form of initial parallel running of processes). Secondly, they should also be able to advise on the adoption of short- to medium-term metrics that will allow the organisation to understand how the new technologies (and maybe processes) are bedding in and the benefits they are delivering.
In addition to the paper-based evaluation of functional fit, it is imperative that organisations allow staff to appraise the evaluation copies of the tools. This is not just IT staff – as some functionality, such as customer self service or automated password resetting, will require appropriate user feedback. IT staff will need to be provided with focused evaluation criteria to rate each tool and this should include user-friendliness, breadth and depth of reporting, and speed of time-critical activities such as customer call logging.
Whilst organisations will assess standard criteria such as inter-process integration, interoperability with existing IT and management software, technical requirements (including performance, security, and resilience), supplier background (including product assurance, and financial stability and reliability), implementation parameters, and support and maintenance arrangements. Tools should also be evaluated in the context of any changed process requirements to ensure that they fit the desired future state.
Whilst arduous, and in no way definitive, this outlined selection process can help IT ensure that they procure the right ITSM tool, or tools, for their organisation, and avoid the mistakes (and associated costs) that can cause the ITSM tools to be abandoned mid-deployment, be unfit for purpose, or underutilised by staff.
Republished from http://www.butlergroup.com