The service transition SIG presented an interactive session at the itSMF conference in November to discuss modern innovative and traditional approaches to Service Transition.
The conference session covered Release Management, Service Catalogue and Early Life Support and arguments were made for both traditional and more modern innovative approaches in quick fire 5 minutes presentations.
After each round, the audience discussed and voted which approach they preferred.
Presenters were as follows:
Agile – Matt Hoey
Traditional – Sue Cater
Agile – Patrick Bolger
Traditional – Vawns Murphy
Early Life Support
Agile – Jon Morley
Traditional – Peter Mills
The final scores were as follows:
As you can see in the table above, the audience favoured Matt’s approach to release management but were on the fence for both Service Catalogue and Early Life Support.
My key takeaway from the session was that most folks were keen to explore new innovative approaches as long as the key benefits were adopted from traditional methods.
Two Speed Transition – 5 minute Video Summary
For further information on the Service Transition SIG please visit www.itsmf.co.uk
Following his fantastic presentation at the itSMF Ireland conference; Dave Van Herpen has written a follow up article for us on Agile SIAM:
In my daily practice I rarely encounter an organisation which does NOT show an unstoppable hunger for agility and customer value at an optimal cost/quality ratio. Time-to-market is under constant pressure, users are getting more demanding and serious cost reductions incite standardisation of services and components. The adoption of cloud services seems like a logical consequence for many organisation, as well as the emergence of complex multi-vendor service landscapes. This demands for an agile, fit-for-purpose demand/supply organisation, continuously provisioning suitable solutions to dynamic business requirements.
The organisational function managing this multi-vendor landscape is increasingly called the SIAM function (Service Integration And Management). This is where management of demand and supply converges. A set of roles, resonsibilities, processes and competences ensures an adequate orchestration of multi-vendor chains and realisation of the required value.
There are several ways to shape this function (internal or outsourced):
– Customer takes up Service Integrator (SI) role
– Major service provider takes up SI role
– SI role is outsourced to a dedicated SI
– Customer partly takes up SI role, together with external SI
Over the past few months a lot has been said and written on the distinct relevance of SIAM. Some may claim it’s a hoax, others approach it from the process and framework point of view and say it has very distinct additions to ITIL and COBIT, and I’ve seen statements that it’s not about a specific framework but rather an organisational capability and set of useful practices to manage complex multi-vendor landscapes. In my view, I consider SIAM to be very useful and appealing container for sharing organisational practices, case studies and practical instruments to deal with demand-supply in complex multi-vendor environments, including cloud services. There. I said it.
Agile & Lean
Dealing with complexity in service chains requires an approach which fits the dynamics and unpredictability of such environments. Any organisation designing a SIAM function along traditional (best practice) ways of working, will lack the ability to cope with continuously changing and unpredictable customer demands and environmental factors. Integration and adoption of Agile, Lean and TOC principles, methods and instruments provides organisations with the ability to face all this. Instruments such as Value Stream Mapping and Business KPIs provide insight into the multi-vendor chain, define shared goals and interdependencies, and enable the different parties to identify and prioritise opportunities for optimization, eg. lead time optimisation or unnecessary process steps. In addition, actively working on Agile behaviour across the entire value chain encourages multidisciplinary teams, peer reviews between suppliers or Agile contracts and service agreements.
Agile SIAM – short case description
A logistic services provider expressed a growing need to free up their own IT people for the benefit of user support, analysis and validation. In other words, more focus on identifying and orchestrating the delivery of value. Executing and operating IT was seen as something in which third parties would be far more efficiënt and effective. This is why the decision was made to grow towards an orchestration function, in which managing and coordinating suppliers remained a relevant responsibility. This customer chose to have the full service integration efforts done by an external service integrator. Nevertheless, particularly at the start of this transition, lead times of incidents and changes were quite unacceptable. Issues spanning multiple suppliers brought a lot of delays and frustrations. One of the most visible instruments delivering positive effects, turned out to be the integrated Value Stream Mapping workshops with the primary suppliers in the relevant business chains. During these practical sessions representatives of all parties jointly analysed the entire stream of consecutive activities. Waiting times, non-value-added tasks, overproduction (e.g. of documentation) and other waste reduction and optimisation opportunities have been identified. After this, shared Improvement Backlogs were the basis for realisation and follow-up of these desired optimisations. This resulted not only in more effective multi-vendor chains, but moreover in visible awareness and behavioural change an nearly all parties regarding more transparant collaboration and a holistic approach to continuous improvement.
Cloud specific service and delivery characteristics require different demands in designing and executing service management processes. Although the composition of the landscape defines the scope and depth of the associated processes and activities, the NIST has put together an applicable set of guidelines regarding service management in cloud environments.
Although this shows little resemblance to ITIL, SIAM or COBIT terminology, I find this a useful overview of the most dominant activityclusters in cloud-dominant landscapes: supporting the business/users, configuration and on-demand provisioning, portabilitity and interoperability. However, the average multi-vendor environment does not consist of cloud services alone. All too often, I see hybrid environments, where cloud (SaaS, PaaS, IaaS), in private or public form, converge with outsourcing services, software licences and staffing services. Using multiple approaches and frameworks is undesired and unlogical, this would only introduce silos and unnecessary hand-offs in the delivery chains. Enriching existing approaches, which also embrace non-cloud environments, is far more natural in practice.
Adaptations our team has introduced include:
– Incident and event management: supporting self-service models, social service desks.
– Capacity and availability management: financial model in line with changing capacity needs
– Financial management: metering/pay per use, automated charging for dynamic sizing
– Change and release management: changing focus of Change Advisory Boards, user
communities, SaaS subscriptions (opex) under change management, solid risk analysis by
multiple roles (e.g. architecture, security)
A transformation from the current IT organisation towards a SIAM function, irrespective of the actual organisational and sourcing model, but where an agile mindset and cloud-readiness are second nature, preferrably takes place in an incremental and iterative way. Critical success factors for such a transformation consist of:
– explicit focus on value
– holistic view on continuous improvement
– adaptivity of the organisation, processes and technology
– a sound balance between demand and supply (speed, maturity, collaboration)
– enabling multidisciplinary teams across organisational borders
– fit-for-purpose tooling for sharing knowledge, progress and job automation
Agile SIAM will give the modern service delivery organisation a more flexible set of instruments and means in order to effectively utilise and manage complex multi-vendor service chains.
The practices mentioned above are a representation of several assignment I and my colleagues have carried out at several (inter)national customers. These clients range from small companies with lean IT functions, to multinational organizations with complex governance structures. I do not mean to promote a single method, a one-size-fits-all approach. In fact, if there’s one thing my experience in Agile environments has taught me, it is that context is king. The practices above have helped us and our customers greatly to improve their mindset and actual daily work practices, including those of the suppliers and integrators involved. If you think there is some value in here, please do experiment with it in your multi-vendor environment. All I did was apply common sense and service thinking to complex, dynamic environments. That’s what I do.
Happy New Year to all our readers and especially to all the Change Managers out there. Why especially Change Managers? Well this week is “back to work” week for most people following the end of the Christmas break as well as the end of any Change freeze / restrictions. This means that not only are our poor Change Managers dealing with the January blues; they’re dealing with the floodgates opening and a deluge of Change activity. With the best will in the world, we try to ensure Changes are transitioned seamlessly into our live environment but the reality is, more Changes equal an increase in Incidents so here’s our guide to surviving the end of the Change freeze whilst keeping your sanity in check.
Step 1: Stick the kettle on
I know, I know, I’m a caffeine addict but in all seriousness, you’re facing a busy week, might as well rock it powered by Starbucks.
Step 2: Have a look at your Change Schedule
Look at your FSC and see if you can identify any bottlenecks or pain points. You know the ones, that business critical service that needs a software update but the rest of the business will be after you with flaming torches and pitchforks if there’s any unforeseen downtime, the server that takes forever to come back up again following a maintenance reboot or that router that’s so twitchy it falls over if someone even looks at it the wrong way. Look at your areas of highest risk and give them an extra sanity check to make sure all the due diligence has been done, the implementation windows are at sensible times and that everyone is happy with the action plan.
Step 3: Get Proactive
As the late, great Bob Hoskins once said, “it’s good to talk”. Now is the time to pre-warn your Service Desk, support teams, Service Delivery Managers and management teams that Change activity will be returning to normal and that it will be an extra busy week or so while the backlog that will have invariably have built up during the Christmas break is dealt with.
Step 4: Turn on the charm
Talk to your Relationship Managers and Service Delivery Managers so that they’re pre warned of any additional risks. By making them aware, you’re enabling them to pre warn customers of any potential blips and if you’re really lucky they may even be able to negotiate a relaxation of any SLAs during busy periods – yay teamwork!
Keep smiling, it will be fine, all will be well because you’ve got this. If all else fails – at least you’re not this cat:
The IT world we know and love exists today thanks to the bedrock of the IT community: ITIL, the IT Infrastructure Library. Since ITIL’s inception 26 years ago, the world has changed and an app exists for everything – shopping, messaging, ride sharing, or just staying connected via social media. We’re in the midst of a new technological age. This evolution has been guided by agile methodology and now, with the rise of cloud computing, many teams are embracing DevOps.
The consumerization of technology is changing expectations of IT. And IT has pressures to live up to these expectations. Because the pace of innovation is largely driven by DevOps and agile methodologies, IT must adapt. To do this, ITIL must support an agile environment. By working together, these practices reinvent how IT teams deliver reliable services to the business, faster.
DevOps and ITIL working together
Developers want an agile process – and it’s best for the organization that they have one. This means having a frictionless release process, and continuously improving software for customers.
ITIL’s framework is hyper-focused on reliable service delivery and support, with its feedback loop based on incident management. ITIL can combine with agile to get the best of both worlds: better software and a reliable, stable environment.
How agile saves the day
Real world example – the Service Desk received reports of a slow loading login page. The underlying issue is confirmed by a bad Apdex score (a user satisfaction score reported by New Relic). The problem might be a runaway query so the development team implements the bug fix into their next sprint, which happen on a weekly basis. From incident to resolution, turnaround time is two weeks.
Using ITIL to support Agile and DevOps
Agile incident management
Maximize your team’s bandwidth with sprint planning. Reserve 30-40% of your team’s capacity for operational tasks, where priority 1 and 2 incidents are resolved immediately, and lower priority incidents are resolved within bandwidth. This means that incident management doesn’t affect sprint goals.
Agile problem management
Trim down on time-wasting administrative work. Manage problems as user stories in a product backlog. Don’t separate “incidents” and “problems” – everything should be cohesive. If a problem occurs more often, it should have higher priority in the backlog.
In ITIL orgs, there’s an assumption you’ll need multiple instances of an incident before starting problem analysis.
Instead of waiting for incidents to pile up, detect and solve problems faster with automated monitoring. Link monitoring tools to your incident management system to identify the cause of problems earlier and get it restored faster.
Agile change management
When it comes to change and releases, many IT orgs drown in bureaucracy related to heavy processes. That can change.
In a DevOps environment, releases are frequent. ITIL framework combined with DevOps means development, operations, and support are always collaborating. It means change requests link from incidents and problems. Issues related to changes are added to a developer’s backlog and allocated to their sprint.
In the end, there’s no budding conflict when it comes to these methodologies. It’s all about making processes leaner, making data visible and enabling faster resolutions. With the right practices, the ITIL framework supports the agility of DevOps.
Sid Suri is the Vice President of Marketing for JIRA Service Desk. He’s worked in various technology roles over the last fifteen years at Salesforce.com, Oracle (CRM), InQuira (acquired by Oracle) and TIBCO Software. An expert in the intersection between IT Support and DevOps, Sid helped create the detailed ebook, “How to Enhance IT Support with DevOps”.
This quick guide has been contributed by Mike Simpson of CIH Solutions.
The guide discusses how Knowledge Management (KM) can be used to manage risk and control costs in an IT Service Management environment. The guide identifies four ‘hot spots’ based on the author’s experience and outlines common problems and suggests solutions using KM.
As with most terms found in IT the term Knowledge Management means different things to different people. There is much available on the subject of KM and the term is often interchangeable with other terms such as intellectual capital, information management, data management and document management. In reality, KM embraces all of these.
So, what is my definition of KM in relation to an ITSM organisation?
First, this is not about scale. A KM system can operate just as effectively in a small organisation as a large enterprise. The principles remain the same – identifying, collating, storing and retrieving knowledge for use by all personnel in their day-to-day tasks. Also, this is not just about documents and data. When the experience of personnel is added into the mix we get Knowledge and this needs to be captured and stored for future use.
Second, from my experience the key feature of a KM system within an ITSM organisation is the understanding that different information has different values depending on circumstances. For me assigning value to information is vital and has priority over the capture of all available material.
At this point I should add that I do not differentiate between an MSP serving external clients and an internal IT service provider. The same KM principles apply. Also, the KM system described in this guide should be considered a ‘practical solution’ that can be implemented with limited resources and budget and extended over time.
I want to begin by briefly describing two KM systems that I have encountered in the course of my consultancy work.
I’ve seen only one truly outstanding example of an enterprise wide KM system and that was at a European pharmaceutical company. What struck me about this KM system was the sheer scale of the repository containing research papers, trials results and project documents covering decades of research amounting to many millions of pages and database entries. The success of this KM system was of course the strength of the underlying thesaurus that enabled scientists to discover (or perhaps re-discover) knowledge to support the design of a new R&D programme.
My second example is at the other end of the scale. This is a local KM system that supports an IT organisation that provides hosting support for external SAP clients. This KM system also impressed me but for a different reason. Without any real top down sponsorship or funding the technical teams had created their own KM system based on a single central repository, but where all the content was created, published and maintained under very strict guidelines by a few key members of staff, but accessed by many. The rationale for using this approach was to bring discipline to the management of documents and data that were considered vital to the successful running of their IT organisation.
KM Model for ITSM
The rationale for the second example above sounds somewhat obvious, but the background problem as explained to me was one of long term ill-discipline in the day-to-day management of key information. Individuals, both staff and sub-contractors, would create multiple documents, held in isolated repositories or held on local drives, resulting in poor retrieval and inaccurate information.
The problem is a familiar one. Admittedly, this KM system is basically document management, plus some other information formats and a simple data classification system, but in my view this doesn’t matter as the problem of badly managed information was controlled by introducing a strong KM framework with a central repository to address a specific local need.
It is this model of KM that I want to discuss as the starting point for KM for ITSM, but first I need to say something about the concept of assigning value to information.
Defining Business Value
I mentioned above that assigning value to information is vital.
I call this category High Business Value information. So, what does it mean exactly? Essentially, this is a category of business information that covers all the vital and irreplaceable business records, documents, information and data that are associated with sensitive areas like customer data, compliance, security, personnel, finance and legal and commercial activities.
It is this category that has the potential to damage an ITSM organisation should this material be compromised by loss, breach of security, inaccuracy or the inability to locate and retrieve quickly when needed. It is the failure to identify, capture, publish and retrieve this category of knowledge that can have a significant impact on the management of risk and cost control.
Whilst all information is valuable, depending on circumstances, some information suddenly becomes more valuable.
Our first step is to build a KM Framework. This framework must define the KM life cycle to create, capture, review, release, amend, publish and retire content. In addition, the KM Framework must define a system of classification for the ITSM information. We have already identified a need to segregate high value information – I’m calling this Layer 1 information. All the remainder of the ITSM information and data is collected into Layer 2.
Basically, for Layer 1 we know what we want and where it is – hence we can find it quickly using a hierarchy with a controlled vocabulary where everything is tagged.
However, for Layer 2 the structure is more linear using a Thesaurus and non-controlled vocabulary. This allows for a more ‘search and discover’ approach.
Finally, the framework will identify the ITSM knowledge managers who will be responsible for implementing the framework, plus a KM Steering Committee.
Five Stages of the KM Framework
There are five stages within the KM Framework and these are shown in Figure 1 below. By following this five stage sequence all the information considered as High Business Value can be identified and either uploaded into the KM Database or retained in local repositories (known as source databases). This is the Integrate stage that is covered in detail later on under the Hot Spot scenarios.
Each stage should be followed for Layer 1 and then repeated for Layer 2.
Figure 1 – Five Stages of KM Framework
Audit – once the categories within Layer 1 have been identified all the material to be included in each category needs to be identified. The audit will do this and will cover different media formats such as PDF, database tables, e-mails, webinars and HTML et al.
Map – during the audit the location of the material is identified. This is mapping and will be needed when the KM database is designed and built to identify what material should be transferred to the KMDB and what material should remain in local repositories.
Classify – once all the information has been identified for the categories of Layer 1, the documents and data can be classified according to the controlled vocabulary system and the hierarchy structure.
Assemble – once classified and physically located, the content for each category should be assembled as a schedule of descriptive metadata tables complete with information titles, document numbers, versions, data sets and physical location.
Integrate – once all the information has been assembled the metadata tables can be used to manage the population of the KMDB – either directly with content or connected to other repositories to extract the content. These are known as source databases.
As mentioned above it is important to classify by value as well as classify by subject. For example, all customer data should always be considered high value, but the exact list will depend on the types of client and services that are supported by the ITSM organisation.
When it comes to the subject of classification there are many standards1 on taxonomy and debates about linear versus the hierarchy structure approach. I’m therefore suggesting that it makes sense to divide our total ITSM information into two distinct groups – the High Business Value information already discussed and a second group which is essentially everything else. I’m calling the first grouping Layer 1 and the second grouping Layer 2.
Once all the information has been divided into these two layers we must structure the information in two different ways. Figure 2 below shows this division.
Layer 1 should be structured using a taxonomy with a hierarchy and controlled vocabulary. This scheme will identify the information according to importance, sensitivity and security level, and will be used to control access to the information in Layer 1. The search tools that underpin our KM system will then be able to locate and retrieve any of the information in Layer 1 very quickly. Layer 1 will typically have the lowest volume.
Figure 2 – Grouping Information by Layers
For our second layer – Layer 2 – I suggest a thesaurus with a more linear structure that will allow more of a free form of search and retrieval based on a smaller number of the terms.
Not everything needs to be tagged in Layer 2, instead broader searches and cross searches can be adopted to allow a more ‘search and discovery’ approach even ‘looking inside’ some documents and files to locate content of interest.
This makes sense as the population of Layer 2 will cover all manner of archived project material, design documentation, presentations, non-critical business records et al. Layer 2 will typically have the highest volume.
Hierarchy of Layer 1
Given the relatively simple structure of our KM system I suggest a top down approach for Layer 1, based on a hierarchy of Categories and Sub-categories using a controlled vocabulary to tag documents and data sets. An example is shown in Figure 3 below. As Layer 1 is the primary focus of our initial KM design and build it’s not my intention to outline the structure of Layer 2.
Figure 3 – Classification Hierarchy
Once all the constituents of Layer 1 have been identified during our Audit stage all the information and data can be divided into Categories. These categories will be assembled under various functional headings, for example:
Category 1 – Customer Data Category 2 – Compliance Category 3 – Legal Category 4 – Service Continuity Category 5 – Finance Category n – Security
Once all the Categories have been identified then the material should be further sub-divided into Sub-categories. I would suggest that these three drill-downs are sufficient to hold all the information in Layer 1. The Sub-categories will contain all the specific document and data sets that relate to a particular Category and this can be assigned by client or customer type or by any other specific grouping.
This hierarchy is not meant to be in any way prescriptive, just examples on the concept of Categories and Sub-categories.
Example ‘Hot Spots’
I’ve identified four possible ‘hot spots’ based on personal observations of real life events and these are shown in Figure 4. Clearly, there will be others depending on the set-up of a particular ITSM organisation and the types of client it supports.
The figure is based on a simplified ITSM organisation that could be either a MSP dedicated to external clients, or an ITSM organisation providing IT services to an internal client. The IT Operations can be either internal or external hosting with or without applications support. For the purpose of this guide it is assumed that the IT Operations is in-house and provides hosting, communications and applications support – within an overall governance framework.
There are four example ‘hot ‘spots’ shown in Figure 4.
Client Portal – Risk to reputation due to poor quality of customer information
Legal and Commercial – Cost of litigation due to incomplete contract audit trail
Compliance – Cost of compliance due to audit failure and forced re-work
Service Continuity – Risk to IT service continuity due to inadequate preparation
All of the above examples relate to the absence, inaccuracy or timely retrieval of information.
Figure 4 – Example Hot Spots
Risk to Reputation (Hot Spot 1)
In this scenario I’ve created a simple Service Operation (SO) organisation that has responsibility for managing the information available to customers via a Client Portal. I should state at this point that not all of the information available through the portal is the responsibility of the SO team. Some material will be supplied direct from the Client for uploading onto the portal – material from the Marketing Department such as prospectus and application forms.
The remainder of material will be service and technical support information produced within SO and cover such topics as service availability status, technical self-help and how-to-do-it video clips. The client portal also has a secure area for the client customer groups to access data on performance against SLAs.
The ‘Risk’ we are trying to mitigate here is out-of-date, missing and inaccurate information being posted to the client portal. The current arrangement within our SO is that information is currently held in separate repositories. Information is identified and collected and then manually or semi-automatically uploaded onto the Client Portal database using scripts. The risk here is that:
not all information is collected at the right time (like monthly SLA data updates)
incorrect information is selected for the right location
correct information is uploaded to the wrong location
not all information is collected
All the above risks can be minimised by the correct processes and checks in place and rigorously enforced. However, experience has shown that this manual and semi-automatic process can break down over time and quality – and reputation – can be impacted.
Figure 5 – KM Integration of Client Portal Information
All the client information that was previously managed manually has now been compiled into metadata tables from the Audit – Map – Classify – Assemble stages. We can now move to the Integrate stage. The metadata tables will hold the locations of all the information and data needed to be accessed by the client portal and the KMDB will use distributed queries to collect all the information and data from these locations. In practice these will be permitted areas within local repositories (or tool set databases) – known as source databases. See Figure 5.
For example, the Known Error database (KEDB) could supply diagnostic help and work-arounds for self-service customers for the most common errors. The KEDB will also collect Event and Incident Management data in support of the SLA reporting that is provided to the client business units via the portal. The Configuration Management database (CMDB) will also be another source database for the supply of data to the client on service configuration.
Cost of Litigation (Hot Spot 2)
My second scenario relates to the threat of litigation as a result of a breach of contract. Whilst this sounds dramatic it is important not to underestimate the legal and commercial requirements to hold and maintain all contractual material and associated business records.
Most service based agreements come with some form of service credit arrangement. However, a decrease in payment may not fully compensate a client for poor service particularly when a number of service failures occur in quick succession or a major outage lasting several days hits not just the client but the client’s customers. Such a scenario could be considered a breach of contract resulting in litigation to seek damages and a termination of the service contract.
Any move to litigation will result in a demand from the client’s legal team for all relevant information to be handed over. This is known as e-discovery2 and the Service Operation team along with the organisation’s legal department will need to respond very quickly in a short time frame.
Figure 6 – KM Integration of Legal Information
This is another example of how the KMDB can be used to store high business value information. Figure 6 shows how the KMDB can contain a Legal DB segment that is used to store in one location all contractual and historical SLA information relating to an individual client. As with Scenario 1, the metadata tables will hold the locations of all the information and data needed to be accessed by the Legal KMDB segment. Again, distributed queries are used to collect all the information and data from these source DB locations.
The information will include all versions of contracts, contract amendments, SLAs including email trails between the client and the IT Service Provider. This latter point of email capture is increasingly used to highlight any communication that might indicate an implied contract variation by either party. I would suggest the inclusion of a Message Record Management (MRM) system as part of the KM solution.
Also, it will be necessary to install an activity monitor to log and track activity of users of the KMDB segment. In reality, this would be good practice across all of the KMDB segments but essential in this instance.
One final point. Where the service provider is internal to an organisation, for example the public sector, the risk of litigation is negligible. However, be aware that a consistent under performance against SLA targets could be a fast track to IT outsourcing.
Here is another example of the importance of a KM sub-set of material that can be assembled on the basis of a specific demand. During a compliance audit, ISO27001 for example, there will be a specific document set that will need to be made available to the auditors for the certification process.
Cost of Compliance (Hot Spot 3)
I’ve seen this happen on a number of occasions. Although this is usually presented as an exercise in cost saving, invariably it is driven by a long term dissatisfaction in the performance of the internal service provider.
Without a rigorous KM approach there is the risk of auditors finding a shortfall in the control objectives and controls. This will result in low auditor marking and possible non-compliance. There is now a real cost involved with the remedial work needed for a re-run of the audit, particularly with the high daily rates charged by external auditors.
The material can range from Information Security Policies to Physical and Environmental Security. There is a wide range of different types of information and data and the Audit and Map stages of the KM Framework will require a lot of research and agreement from the KM Stakeholders on what should be included in this KMDB Compliance segment. It is likely that some of the lower level information may be located in Layer 2. If this is the case then it might make sense to leave it where it is and simply connect between the two layers. It is also true that the scope of ISO270013 is such that the KM will need to connect to a wider range of tools and assets.
One particular example is software asset management (ISO 27001 – Clause A8: Asset Management). Under this heading auditors will check the number and validity of software contracts held and check that the licences cover all the users who actually use the software. This could be addressed by setting up a source DB within a SAM tool and extracting all the data needed for the audit (as a controlled set) and then sending it to the KMDB. This is actually a very common failure point.
Risk to Service Continuity (Hot Spot 4)
In this final scenario I want to look at how the KMDB can be used to support Service Continuity. This has a much broader scope than just KM and I’m not intending to cover the whole subject of Business Continuity Management (BCM). Again, there are multiple terms involved here – like Disaster Recovery, Business Recovery and Service Recovery. In the case of ITSM and KM, I’m going to describe how KM can be used in support of Service Recovery within the broader BCM that covers the end-to-end business of a client.
The dilemma facing an ITSM organisation is no one can really identify all the situations likely to occur. Certainly, the evacuation of a data centre due to fire and flood is an obvious scenario, but thankfully not one that occurs very often. Clearly you can’t prepare for every instance but it is possible to target some common ‘knowns’.
So, here is a possible starting point. In our Layer 1 (High Business Value) under the Service Continuity category, the sub-categories should be constructed to reflect various ‘threat scenarios’ – one per sub-category, such as cyber threat, data theft and denial of service to name a few. We could also add major software outages that can and do occur from time to time.
Each ‘threat scenario’ can then be structured along the scope and guidelines of ISO223014. This will create a consistent framework for compiling all the recovery procedures, communication escalations and fall back plans for each scenario. Clearly, there is much more to discuss here but there is a future article that will address all of these aspects of service recovery which is planned for publication later in 2015.
What this guide attempts to outline is a number of possible solutions to common issues around both risk and cost control in an ITSM organisation. It is not intended to be prescriptive. The KM system described here should be considered an ‘entry level’ system, but with the capability of extension as time and budget permit. This KM system is also predicated on content being held within existing repositories, as well as a central KMDB, but extracted on demand. The success of implementing a KM system will always reside with the management and staff of an ITSM organisation and not the technology. Hence the emphasis must always be on developing a KM Framework as the starting point.
This quick guide has been contributed by Mike Simpson of CIH Solutions.
At the start of every year or quarter, senior managers across the organization get pulled into the tug-of-war of budgeting and headcount planning. And few feel the pain as much as IT. If your team is viewed as a cost center, as IT more often than not is, asking for a bigger budget or head count increase can be a daunting task. But not doing so is not an option either. If you don’t properly plan and make a compelling argument to senior management for those extra resources you need, teams that are stretched get even more stretched resulting in a decrease in quality of work and employee burnout; neither of which helps the employee, the IT team, or the company.
They say if you can’t measure it you can’t fix it. Equally true is, if you can’t measure it, you can’t justify it to management. It’s time for IT teams to learn a lesson from customer support.
Why Customer Support?
I don’t mean wearing a headset and wishing every one a nice day. Though your co-workers would probably like that. I am referring to the practice of building a strong competence in measuring how much work the IT team is taking on, how quickly they’re responding, and how satisfied are the people who depend on them. Sounds simple? It should be, but astonishingly many IT organizations are so mired in the day to day blocking and tackling that they don’t remember to remind everyone how much they’re getting done.
Customer support organizations for years have become masters of analytics. They live and die on measuring key performance metrics like average response time, number of requests solved per person per day, and customer satisfaction.
The benefit? Support organizations can tell you exactly what their team utilization is and how good of a job they’re doing. More importantly, they have the numbers and analysis to credibly ask for a budget and headcount increase when they need it.
Not just IT, but every internal business team could think of themselves as a customer service organization across HR, Finance, Legal and others. Though no one is closer to customer support than IT. IT is the internal customer service organization, troubleshooting software and hardware problems for employees. If IT is similar in many ways to the external support organization, then they also need to mimic support’s best practices on gathering the right data and using that information to show their value to the business.
Here are 3 steps internal teams can take to report the kind of performance metrics that executives understand and respond to.
Establish and Document Processes for How Work Gets Done
The biggest barrier to measuring anything is a lack of a consistent method of execution or in other words, a process. If all requests for work, be it in IT or outside such as reviewing a contract or updating an employee benefit plan are executed in an inconsistent manner with varying levels of efficiency, it’s hard to get a read on how long a task takes and at what rate it can be executed. Further, if all requests for tasks are received and responded to over email, it’s easy for teams and managers to lose sight of the total volume of work being serviced by the entire team over any one quarter and how that volume is either increasing or fluctuating in that timeframe. In the support world, processes are well documented and automated so customers get quality and consistent service. Requests for help from customers come through applications and systems that document not just when the request came in but the time it took for each step in the support process from inception to resolution. While many IT teams do use ticketing systems they rarely have the same sophistication as those used by external support. And if they are not user friendly and zero-effort to use, employees bypass them with email or fly-bys to the IT agent’s desk.
The common mantra for many teams is that no day is typical. But that doesn’t mean there isn’t room for a process that accommodates flexibility. Often there will be an 80-20 rule; 80% of requests will follow a certain pattern while 20% might be outside the norm. By shying away from documenting and following a process at least for the 80%, IT departments are missing out on a crucial ability to not only better track their work but also service their stakeholders better by bringing increased consistency and quality control into their daily tasks.
Measure Everyday Activities
This might seem overkill at first but it’s the only way to truly understand how long it takes for you or your team to fulfill common requests. Even rough measurements will go a long way to give you an idea of how to plan your day or week. As teams grow and become geographically distributed, understanding how long tasks take is critical to planning capacity. Software developers often use a method called agile development where each task gets a number score that indicates how long the developer thinks that task will take. This allows a product manager to ensure a product release is adequately planned, staffed, and on track. Lawyers and consultants regularly clock their hours since they need to bill clients per hour. There are many examples of different functions bringing an increased measurement rigor in order to not only track progress more efficiently, but also help managers better plan and staff every quarter.
Best of all, there are many work management or task management systems that make it easy for employees to track time spent on a task, similar to the many apps for your smart phone that will help you count calories and track exercise routines.
Use Processes and Measurement to Build Your Personal Analytics Dashboard
Once you have documented the process and put in place steps to either manually measure time taken or in an automated manner through a tool, you’re ready to start building your own personal analytics.
Wouldn’t it be nice if you could answer questions like:
Last quarter with 3 people we supported 342 IT related requests for help from employees and on average were able to provide a response within 2 hours.
The number of requests were up 12% from last quarter
For the next quarter we expect a 8% increase based on company wide headcount growth
Imagine the possibilities you have armed with those kinds of numbers?
Now you no longer have to say – “I think we need more headcount, because we’re swamped and working late most nights.”
Instead, you have real numbers, tied to measurable results, that executives love and respect. To further spice things up, you could add employee satisfaction surveys to demonstrate your successes.
So now your analytics read:
Last quarter with 3 people we supported 342 requests with an average employee satisfaction score of 77%.
The #1 issue many employees cited was the length of time it takes to get help
For the next quarter, we’re looking at a potential 8% increase in # of requests.
With an extra headcount we are confident we can scale to meet demand while boosting our overall customer satisfaction to our stated goal of 90%
While you may not get what you ask for, if you ask for it enough times in the right way, often good things will happen.
It’s time for IT teams to embrace the best practices that have led to customer service organizations becoming the lean mean fighting machines that they are. There is no substitute for good analytics, but that comes at a price; the need to follow a process for how work gets done and measure the time taken to perform the steps along the way. But the upside is huge. Not only are you able to build the type of reports and analytics needed to succeed, but the people who depend on you get fast, consistent service they can trust. There are many tools and systems in the market to help you on your journey.
So in 2015, think like a customer support organization. Your company will thank you for it.
This article is a guest post and has been contributed by Drago Topalovic, ITIL & ISO20000 expert.
The first thing to consider when implementing best practices and standards in service management is motive.
Why Should We Do It?
When you provide IT services, you have to be the BEST you can. In other IT areas like development, infrastructure, and business system deployment, you can perform slightly under par and still add perceivable value to a customer’s business. In service management, your good performance is usually taken for granted, and every error is highly visible. Service downtimes adversely impact a customer’s business, and SLA breaches are penalized.
Every resource and every configuration item (CI) has to be utilized efficiently. Business processes and functions have to be organized with defined roles, responsibilities, and action sequences. Ambiguities and a lack of definitions and organization promptly lead to user dissatisfaction. So, IT service organizations should take any help they can get.
Is ITIL Enough?
ITIL is abundant with best practices, describing life as it should and could be in IT service management. You have all the options laid out in front of you – the sky is the limit. Like living in a big city, you can go to theatres, fancy clubs, and whatnot. But, do you? Living with ITIL alone tends to move you to roads more travelled, and to neglect service management components you don’t feel comfortable with. Knowing your ITIL is good; you can competently implement all the interesting processes and functions, and safely ignore the other ones, knowing that you can turn to them when the time comes.
It differs from one type of service provider to the other, but typical evaded processes in IT are financial management, supplier and customer management, and Documentation management.
For some insight on ITIL benefits, please have a look at the article Why ITIL?.
When you live with ITIL long enough, whether you are a managed services company or internal IT in a small/midsize/large company, you start to realize a few downsides of doing ITIL alone:
ITIL certification is personal, and as people come and go, you start to wish for a way to keep your organization’s intellectual property more anchored, instead of being strongly affected by the fluctuation of your staff.
With all the options of best practices, it is hard to get the firm management commitment to what really has to be done, and without it, you are on a slippery slope. There are always more urgent things to attend to.
ITIL 2011 addresses more processes and functions then before, and implementing all of them seems like mission impossible.
It is really difficult to say when enough is enough.
Once you have improved those processes that cause you the most pain, you may realize that your focus shifts to things you didn’t consider important at first. For example, you implement Incident and Change management, and it suddenly becomes obvious to you that your Configuration management lacks the power to support these processes. That’s a good sign that your organization is growing. And, it’s usually a sign that you should start considering ISO/IEC 20000.
ISO20000 – An Opportunity to Grow
ISO/IEC 20000 provides a very strict set of requirements for implementation. The scope can prove to be very demanding for most of the growing IT service companies in the beginning. But, as you mature, you start to consider the advantages of a service management system that takes care of what SHALL be done in order to make you a competent IT service management organization, as opposed to what could or should be done.
At some point, this set of opportunities will start to feel more appealing to an organization.
ISO 20000 Benefits
By implementing ISO/IEC20000, the organization benefits from the following:
Integrated Service Management System (SMS) supporting the vital service management functions.
Organization focuses on all key processes. Measurements and control of integrated SMS brings new perspectives and ideas about organization’s service management business. Since all 16 processes are implemented, combined results from say, Budgeting and accounting with Capacity management will give you the better idea on which customers are more valuable to you.
Better alignment of IT services and the business it supports. Adopting the common language and the knowledge about processes usually helps in building trust and confidence of customers.
Better reputation on the market. Having an ISO20000 certificate is still not a very common thing; it proves you are serious about your business.
ISO/IEC 20000 certificate stays with the company, not individuals. The SMS helps to keep knowledge about service management business within the company, as its intellectual property.
Roles, responsibilities, and ownership of all processes remove bottlenecks and ambiguities in service management domain.
By defining key processes and agreeing about them internally, ISO20000 helps to overcome natural barriers between organizational units. For example, Sales is forced to cooperate more tightly with internal IT in order to offer more cost-effective services to external customers.
Vertical communication in the organization is usually greatly enhanced. Management is involved in the process from the beginning, and the feedback they receive regularly enables better quality of tactical and strategic decisions.
I am fully aware that the above benefits are primarily aligned with an IT management perspective. These are the pains immediately recognized by the IT members of the community. So, I intend to provide a separate post where they will be properly addressed from a business point of view. I would love to see some of the visitors’ comments regarding this.
The certification process for ISO/IEC 20000 is not an easy one. It’s a very demanding project, requiring a lot of resources. That is one of the major reasons it is not a common certificate. On the other hand, this makes it even more appreciated on the market.
If you are an experienced IT organization with good internal knowledge of key ITIL processes, the above-mentioned benefits should be inspiring to consider ISO20000. From my experience, it looks harder than it is. Just take the first step.
Drago is an IT Business Consultant oriented to Service Management and Customer Relationship Management, project management in SW development.
Specialties: ITIL Expert certificate, Implementation of service management tools, methodologies and processes. Preparation and implementation of ISO/IEC 20000.
I don’t know about you, but I’ve worked for a number of companies at which, as a new employee, it has taken days or weeks to be given the technology I need to do my job. I’ve no doubt it’s still happening in many organisations today. But as the proportion of ‘digital natives’ in the workforce increases, that scenario is becoming less and less acceptable. More importantly, it is becoming a serious business risk, rather than just a temporary inconvenience. Why? Because today’s employees expect to be able to use technology at work in the same way as they do in their personal lives. That means switching between devices at will, and accessing software and services at their convenience, often through a central app store. If that’s not possible, they are more likely to look for employment elsewhere.
Giving employees this kind of control over technology is a scary prospect for many corporate IT departments. But with the right approach to enabling user self service, the reality can be more fulfilling than frightening.
Start with the User, Not the Technology
Enabling your employees with self service access to the technology tools they need requires a fundamental shift in the way you deliver IT to users. Rather than the IT department acting as a local supplier of heterogeneous hardware and software, it needs to become a provider of standardised services – all delivered and managed from a central IT service/workspace management system. The process starts with the definition of a service portfolio (the needs of the business that the IT department must fulfil) and a service catalog (the actions required in terms of technology delivery to meet the business need). Importantly, both the service portfolio and the service catalog must be built around the needs of your employees, not the established capabilities and processes of the IT department. Once these needs and services have been defined, they can be realised within your chosen ITSM/workspace management solution, which should ideally feature an app store interface that gives users a consumer-style experience when choosing and consuming corporate IT services. That solution should also automate every service-related process, from order to approval and delivery, right through to on-going maintenance and management.
Standardise Services, Establish Value
Automating processes is all well and good. But automating a bad process is often worse than leaving it alone, because in an integrated ITSM system, the consequences will automatically impact other processes. That’s why it’s so important to standardise the processes within each service as much as possible, and thereby minimise the potential for error.
Equally as important is ensuring that users understand the value of the service they receive. If no cost or value is attached to a service, users will consume it at will, creating additional and uncertain cost and workload for the IT department. Equally, if a price is attached to a service without defining every aspect of the service being provided, business users and managers will invariably see only the hardware or application they are consuming. The accompanying admin, networking, security, support, management and maintenance work will be invisible. As a result, they may try to circumvent the service catalog because they will perceive the service to be expensive and believe that they can get it cheaper elsewhere. Both of these scenarios can be avoided with a centralised service portfolio and catalog that provide clear price/performance definitions for each service.
Five Steps to Self Service Success
So, you’ve made the decision. You want to give business users the consumer-style IT experience they expect, and prove the value of IT to your business. At Matrix42, we believe there are 5 essential success factors to be aware of, however you choose to implement user self service.
1. Define and standardise services
Efficient self service in corporate IT requires every service to be standardised around particular usage scenarios, such as the onboarding of a new sales person, and automated at every stage of the service lifecycle. Once this has been achieved, it becomes easier to make small adjustments that may be necessary for specific locations, such as linking PC orders to a local hardware supplier.
2. Integrate all the necessary processes
Ideally, users, managers and IT departments should all be using one IT service delivery and workspace management system that integrates all the IT and business processes required to order, approve, deliver and manage an IT service. This ensures cost and status transparency for all, and maximises IT service management efficiency.
3. Give everything a value
Services without costs attached encourage users to consume them freely, regardless of whether they are actually necessary for their work. To avoid unnecessary expenditure and workload, every IT service must be clearly and realistically described and priced. This ensures the cost of service consumption and expected service quality are transparent and predictable for users and approvers.
4. Ensure compliance
Your ITSM system should enable you to create and manage the relevant license agreements for each service centrally. This requires that your service catalog is integrated with your compliance solution, which should proactively alert managers to any over or under licensing. This will enable them to avoid compliance failures and continuously optimise costs.
5. Make it accessible from any device
Many of your users don’t work in one place on one device, so they expect to be able to order and use a service from wherever they are, and on whichever device they are using at the time. A complete, centralised IT service and workspace management solution will ensure that each service only needs to be ordered once for it to be made available on multiple devices.
With device and software diversity increasing all the time, and an ever-more demanding and sophisticated user base, greater IT complexity within organisations is almost inevitable. Introducing user self service into ITSM is one of the most important tools at your disposal for simplifying the management of that complexity.
Collaboration, across diverse teams and between levels of the hierarchy remain the twin, unconquered peaks for many organisations. This is also true of collaboration internally, within IT functions. Poor collaboration is often revealed to be the fatal flaw in well publicised corporate disasters. Within IT and between IT and the internal functions IT supports, it is a silent, relentless drain on time, cash, productivity, motivation and talent during organisational projects and operational improvements.
The following shows how teams from three very different organisations identified and overcame barriers to collaboration. In one case the teams were specialists within the same large IT function – responsible for different steps in the service delivery process managed in different countries. The other teams were from different functions including: Finance, Legal, Sales, Marketing, HR and IT.
At its simplest: ‘To work with another person or group to achieve something’. Initially the teams thought of collaboration in terms of:
The tools: The technology and media for accessing and sharing documents and applications, tracking progress, gathering data for decision-making, following processes
The location: In some cases the teams worked remotely, across sites, countries and continents. In others they were on different floors of the same building
However all agreed that the real heart of collaboration was not just working alongside each other to deliver products and services; there was a creative, proactive element and more in-depth on-going knowledge sharing, learning and debate.
Examples of good collaboration included doing interesting, challenging work, discovering a whole new side to people, making a difference and being recognised for it. Poor collaboration led to deep frustrations and anger over what were seen as avoidable blocks by individuals, teams and management. Where these had been left unchecked, the stronger emotions had dulled to cynicism, small barbs of passive-aggressive behaviour such as not turning up to meetings or going against decisions made, indifference to new initiatives and doing the minimum.
What Stops Collaboration Happening?
Human beings, it seems from looking at any news media on any given day, are socially and psychologically programmed to stick to and to defend their own. Collaboration is also a natural human behaviour but which requires a degree of maturity, awareness of self and others, positive perseverance in the face of others’ reluctance and an environment where it is safe to explore the new and unfamiliar. Goffee & Jones’ ‘Why Should Anyone Be Led By You?’ (2006) and Kotter’s ‘Accelerate Change’ (2014), show there are inbuilt systemic loops that discourage collaboration. It takes a resilient individual or team to question their own and others’ habits, behaviours and thinking.
The danger, when senior management talk about collaboration, is that they refer to best practice principles and thinking which make perfect sense but do not connect with the day-to-day experienced of team members and managers ‘on the ground’. In each of these three examples, senior management encouraged teams to first get some perspective, then address the details that mattered to them.
Proceeding sensitively was important, as there would clearly be areas of rawness around attitudes and perceptions relating to behaviour and performance. The groups included speakers of English as a 1st and 2nd (or 3rd …) language from all continents.
Three Barriers Identified by the Groups + Solutions Explored
Among the many barriers identified, these three were the top priorities because
a) everyone could take action and benefit immediately
b) improving these basic communication areas would enable more in-depth collaboration in other areas
Barrier 1 – Emails
The phenomenon of email ‘flaming’ is commonly recognised. When stepping back and analysing the specific language in their emails, the groups were quite shocked. Both managers and team members commented that they had become immune. Comments included: ‘It’s not nice but they are always like this so we try not to let it get to us’. Given that email was the only tool available for communication between some teams on a regular basis, this was critical. The language ranged from the unclear, incomplete and insensitive, to the frankly abusive. Plus, there was limited understanding of the damage that a frustrated ‘cc’ escalation could cause, particularly in cultures with more hierarchical relationships.
The groups focused initially on factors outside their control. These included frustrations around (perceived or real) poor planning and prioritisation passed down the hierarchy, skills gaps, bottlenecks, misaligned processes, managers using unhelpful language themselves. However, when the focus was directed at what practical steps were possible, the group started to feel less embattled, more positive and more willing to take on some responsibility for finding solutions. E.g.: Asking for a meeting, picking up the phone and asking questions.
Having discussed the 7 areas of waste identified in ‘Lean’ process reviews, one team identified ‘Waiting’ for action from those interdependent teams, as an area to work on. By using the ‘neutral’ vocabulary of the ‘Lean’ thinking, they could name their concerns and offer practical suggestions more comfortably.
Barrier 2 – International English
There were some good examples in all the groups of ‘false friends’ where 2nd/3rd language English speakers had done their best to articulate their needs, and the native speakers, perhaps having never experienced working in a second language, took the words used at face value. Some examples included the use of ‘You should …’ which sounds like a command to a British reader but in German translates as ‘May I suggest that you …’ .
Actually discussing these language aspects was extremely helpful in relationship building. All parties were keen to learn how they were perceived and what they could do to help understanding. For native speakers, slowing down – considerably – was key, and not using local expressions. Keeping sentences short. No waffle or ambiguous management jargon. Plain English actually sounds more professional and authentic, but many people, native and non-native speakers believe otherwise.
Groups created their own ‘meetings from hell’ checklist – as a light-hearted way to highlight better practices for face-to-face meetings and video/audio conferencing.
Barrier 3 – Prejudice
Having never met in some cases, and with nothing but a few words in emails and general media images to inform their judgements, the teams had created surprisingly detailed pictures of the intentions, level of intelligence, technical competence, work ethic and values of the other groups.
One team invited the other party to work with them on highlighting and addressing issues together, one at a time. ‘The whole solution in the room’ was a phrase used. Another turned process mapping into a shared, physical and visual activity, with giant post-its, a wall and marker pens. This filled many gaps in understanding and increased appreciation of each other’s knowledge, context and constraints.
In one team, where intercultural training was not an option, managers asked each team to research one of the countries they were working with and present their findings. This included contacting their local native speaker colleagues and asking for their input. The groups found this fun, fascinating and a great ice breaker.
The changes in mood, attitudes and behaviour in each of the teams, was quicker and more significant than expected. Within 3 months, there were multiple examples of small improvements in collaboration and significant improvements in delivery. Actively spending time reviewing successes and small improvements reinforced the shared sense of achievement. In all three cases, a senior manager got involved, either at the start, or when asked to support and the initiatives being taken.
Six months on, internal and customer relationships and delivery have improved in all cases.
Collaboration breeds more collaboration!
Philippa Hale has 25 years of experience in enabling collaboration and communication on international projects and programmes, particularly within and between the IT & Digital functions and colleagues from other business functions. She is Director & Senior Consultant at Open Limits Ltd and an Associate Faculty member at Henley Business School.
Service desk teams provide support and service to company employees, helping them to make the most of the IT assets that the company provides. At least, that was always the role that IT Service Management teams saw themselves providing. The overall goal may not have altered, but how this is fulfilled has been changing.
The traditional methods that service desk teams use to demonstrate their value don’t effectively capture all that the ITSM function can deliver. At the same time, new initiatives like Bring Your Own Device, cloud applications and self-service portals are entering business IT. This means that key performance indicators (KPIs) have to be changed. However, are we changing our approaches to keep up, or are we being forced into this? As the service desk landscape changes, how can we take back control and demonstrate more value?
Where are we today?
Many service desk teams will still use first-time fix as their number one demonstration of value. However, while this metric is still valid, it’s very quantitative, and only one step above looking at the overall volume of calls being handled. Service desks today have to deal with a larger number of channels than before, so how calls are categorised is a good place to start thinking differently.
The key questions to ask here are: “How do my customers want to interact with me? Are they happy with more traditional email and phone requests, or would they like more options such as chat?” For many teams, answering these questions can be difficult, as options are grafted on over time rather than being thought through strategically.
For a service desk manager looking at all the different traffic coming in, it can be difficult to assign weighting on the requests that come in. Should social media or chat interaction be counted in the same way as a phone request? A lot of this will depend on the process that customers go through as their incidents are handled. This will also affect how success is measured in the future as well.
Where do we go from here?
There are two avenues open to the service desk manager here – one is prescriptive, and one is to allow more freedom in how incidents are handled. The first approach would be based on mapping out all the most common problems that are encountered by users, and then looking at the workflow for those incidents across different communication methods.
This can work well when you have a large number of service desk operatives and need to get consistency on customer support experience. Putting this together would provide both guidance on how to handle requests that come through, and also ensure quality of service.
However, there is one issue with this approach, it takes away a lot of the flexibility that service desk professionals can have in solving problems and ensuring that the customer is happy at the end of the call or interaction. Now, for regulated industries where security and compliance are important, this is something that will just have to be accepted but for other businesses, allowing more leeway on how calls and requests are handled can be both better for the customer and for the service desk personnel. Allowing service desk staff to help customers in the way that best suits them – and the customers that make the request – can help to provide better service, both in terms of quality and service levels.
Looking at a bigger picture
Thinking about specific targets for the service desk team also involves looking at how ITSM is incorporated into the overall business or organisational goals. Is the service team delivery part of external-facing, “paying customer” work, or more around internal customer or employee satisfaction and keeping users productive? Building up metrics around customer retention and satisfaction leads to a very different set of KPIs compared to this internal service delivery, where efficiency is paramount.
Setting out new KPIs involves looking at what the customer expectations are around service, as well as what the company or organisation wants to deliver. This is a very different approach to the quantitative approach that many service desks are used to. Instead, it has to be more qualitative. Often, there will be larger company goals that will help frame KPIs in the right way.
As an example, your company may provide a product with premium branding. Service delivery around this should therefore match that perception. Creating a measurement KPI around delivering “five star service,” with personnel encouraged to go the extra mile, would be more effective than simply looking at how many calls or requests were handled. Conversely, companies that pride themselves in efficiency would want the same approach to be reflected in their service strategy.
For public sector organisations, efficiency and call handling will still be important metrics to track as well. However, the growth of online and digital service delivery means that requests that might previously have been calls can be answered either through information on websites or email/chat requests. This will leave more personal interaction time for staff, providing a better quality of care for those that really need it.
Alongside these changes in KPIs, the way that service desk teams manage themselves may have to change as well. For too long, the tiered service desk approach has been less about dealing with front line problems and more about managing how skilled professionals can provide support where it is needed. The change from solely supporting phone and email over to using multiple channels should be seen as an opportunity to increase skills for everyone.
Managing service interactions more efficiently
It’s also worth considering how sessions are handled. For requests that have a technical or specialist knowledge requirement, playing telephone tag and having the customer explain their issues multiple times can be a painful process. Instead, it should be possible to use those with specialist knowledge in a more efficient way through collaborative sessions.
This approach involves letting third parties join calls securely – particularly if there is a remote access session involved. Rather than depending on the third party and customer to get connected, the service desk can manage this themselves, cutting down on time taken and providing a better experience for the customer. Bringing together assets in this way does mean that the front-line staff have to be aware of what challenges they may face that are intricate or require outside help, but that does not mean that they have to hand a call straight over to someone else.
The growth of online support and services is only going to go up, as more people prefer to work directly through chat or social channels rather than more traditional phone systems. The make-up of the workforce is changing as well. In the higher education sector, research by the Service Desk Institute found that 76 per cent of students preferred using the web form for raising a request rather than picking up the phone or emailing directly, while 37 per cent were happy to use social media channels to contact the service desk.
As these students move from university and enter the workforce, their expectations of support will be very different to what has gone before. Maintaining a consistency of approach when trying to keep all these options open is a real challenge, but it can be delivered by thinking through the problems that are due to come up.
Rethinking your KPIs so they are more aligned with the needs of the business is a good first step. From this, you can then look at how to work more closely with line of business teams, too. Ultimately, the service desk can start to think about changing the perception it has within the organisation, from one of only being there when things go wrong to providing more guidance about how to make things go right in the first place.
There seem to be as many choices on how to manage interaction with customers as there are service desks, particularly as customers want to interact in new ways. However many channels you have to support, the important distinction is around customer service, not just IT support. ITSM teams have to look beyond their role as IT professionals and think about displaying their acumen around other areas, too.
Setting out KPIs is one way to achieve this aim. By linking the aim of the business to the quality of service that is delivered, ITSM teams can look to demonstrate more of the value that they create for the business every day.