I’ve been playing about with some Twitter tools recently and thought I would analyze the two big ITSM events this week: The HDI Conference and Expo in Orlando, Florida, USA and The Service Desk and IT Support Show in London, UK.
I appreciate twitter is not the most perfect mechanism for measuring sentiment at conferences – but I believe it provides a good indication of conversations and interests. In the run up to attending SDITS I noticed a growing number of ITSM practitioners joining twitter (as opposed to consultants and vendors) – so in theory fewer product led conversations.
What an enormous reach these events have outside the conference, both in terms of eyeballs and geographical reach.
Editor’s Note: We are very pleased to welcome Rob England (a.k.a The IT Skeptic) as regular columnist at The ITSM Review.
Railways provide a useful analogy for understanding what service management is and how it works.
What is a railway for? (or “railroad” for our American readers)
If you said “to move people and/or goods” you are only partly right. On the right track (pun intended) but not there yet.
How should it move goods and passengers? With maximum quality? Or at minimum cost? The answer to that is “it depends”. It depends on what the customer wants.
A customer is one who pays for the service of the railway. That isn’t always the same as the one who buys the ticket or books the freight. Many railways receive public funding, so the government or other body is effectively also a customer: they are paying for part of the service. Not all customers are users of the services.
The railway is answerable not only to its customers. It is also answerable to its owners and the governors they delegate authority to. The owners may not want the same things as the customers at all. For example, railways are often required to provide a passenger service as a requirement of gaining the right to operate. These passenger services are often unprofitable: the money is in the freight services. Guess how often such passenger services meet the needs of the paying ticket-holders.
So a railway exists to provide a service that moves people and/or goods to meet the needs of its governors and customers.
Your are in the service business
If you were operating a railway, what activities would you have to manage in order to ensure you meet the needs of your governors and customers? There would be some activities that are unique to railways, such as scheduling, servicing rolling stock, dispatching trains and so on. But the bulk of the activities involved in operating a railway are the same as operating any business: reporting, financials, HR, marketing, IT, procurement… and delivering your services. It doesn’t matter whether an organisation’s services are transporting goods, providing accommodation, building houses or catching fish. They all serve customers and they all perform a similar set of activities to manage that service.
Whether you build roads or map them, operate ports or use them, build houses or sell them, plan weddings or sing at them, care for kids or clothe them, sell PCs or scrap them, you are in a service business, even if you may not be in a “service industry”.
We aren’t talking about over-the-counter “may I help you?” service, how to develop the customer service interface, the experience of contact. Service Management is about the end-to-end process of providing services. It covers such things as:
Service management activities
Executing a service for users
Food service, engine drivers, shunters
running the infrastructure that makes the services work
Signaling, track maintenance, security guards
Responding to user requests for service or help, and resolving them
Ticket sales, call centre, guard, repair crews
Providing information about what services are available
Timetables, websites, brochures
Maintaining relationships with customers
Customer account managers, sales, public relations
Monitoring and reporting service metrics
Punctuality, traffic volumes, profitability
Proposing, choosing and strategising new services, improvements and retirements
Routes, trains, schedules, freight deals, specialised cars e.g. refrigerated)
How the service will work, what infrastructure it needs
Developing anew schedule, specifying new equipment
Creating the infrastructure, mechanisms, and processes to deliver a service
Ordering or constructing new rolling stock, laying track, hiring and training staff, printing collateral
Rolling out the new service, going “live”
Commissioning new rolling stock, publishing new or changed schedules, deploying staff, rolling trains
Protecting the organisation, its staff, customers and users. Making sure the service is safe for people, compliance and profits.
Direct, monitor and evaluate the management and execution of the services
Corporate vision and goals, high-level policy, risk profile, annual report
Service Management says the most important thing you do is deliver services to your customers. Moreover, everything you do should be considered in terms of the services you provide to your customers.
Adopting a service management approach can have a profound affect on the way your business works and your staff think. It takes us away from that introverted, bottom-up thinking that begins with what we have and what we do and eventually works its way up and out to what we deliver to the customer. Instead, with service management we change our point of view from concentrating on the internal “plumbing” of our business, moving instead to a focus on what “comes out of the pipe” – what we provide. We take an “outside-in” view. Starting from this external perspective we then work our way top-down into the service organisation to derive what we need and what we have to do in order to provide that service.
Service management isn’t one subset of the business; it is not one activity at the end of the main supply chain. It is a different way of seeing the whole supply chain, the whole business that produces the services, by seeing it initially from the outside, from the customer’s point of view. Therefore any discussion of Service Management may stray into general business management topics.
Seeing our business in terms of the services it provides can’t help but make us better at providing them.
To a customer, “better” means more useful and more reliable, i.e. more valuable and better quality.
From the service-provider’s point of view, “better” means more effective and more efficient, i.e. better results and cheaper.
Follow along in this series of articles as we look at Service Management through the lens of railways and how they operate. We hope it will provide a fun and useful way to understand this thing called Service Management.
Spring has sprung and the IT conference season engine for 2012 has officially started. Actually, Las Vegas and Orlando got going in January/February, but at least we’re civilised enough to wait until the clocks go forward before we dust off our conference venues.
April is special of course as this is the month that we see the Service Desk & IT Support Show return to London’s Earls Court from the 24-25 April, with over 80 suppliers demonstrating 250+ products and services.
This is the UK’s biggest showcase for the IT Service Management and IT support industry and this year the central exhibition will also benefit from a comprehensive two-day free education programme, which combines eight keynotes, 40 seminars, breakfast briefings and roundtable discussions.
A full exhibitor list is available here. Looking over the attendees we can see that there are plenty of the “usual suspects” and that’s always a good thing. Even better is the news that there will also be nearly twenty completely new faces taking part this year.
“The support from the industry this year, as always, has been fantastic. Our 2012 line-up of big name exhibitors and illustrious expert speakers has already generated a lot of positive feedback from pre-registered visitors,” commented event manger Laura Venables. “I’ve been working on the show for five years now and it’s a testament to its continuing success that, with less than two weeks to go, we’re still getting significant exhibitor interest from some top ITSM providers.”
Common sense tells us we ought to choose a select few ITSM metrics which clearly demonstrate value.
But what happens if we outgrow our original metrics? Or the goalposts change? Or we acquire 15 different companies?
Similarly, once we have completed the basics and want to start exploring continual service improvement – Do we start all over again? or can we work with what we have?
Former US Secretary of Defense Donald Rumsfeld famously stated in 2002:
“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don’t know.”
The same might be said of ITSM metrics. The reporting capabilities of most industry tools are based on a certain subset of metrics which are usually accessed via canned reports, bespoke queries or bespoke reporting (Known Knowns). But what if we want to peel back the layers of the ITSM onion and REALLY discover what is going on? We need to explore the Unknown Unknowns.
Next Generation BI?
The next logical step is to investigate Business Intelligence (BI) – but unfortunately most IT professionals I know shudder at the prospect of BI project because we want the results next month not next year.
UK based Service Management Company ‘RMS Services’ believes it has hit upon an ideal solution to this conundrum with what it claims to be next generation Business Intelligence.
In a nutshell: RMS Vision provides free form search of both database schemas and data from multiple data sources simultaneously.
Gone are the limitations of enterprise integrations, labour intensive excel pivots and custom reporting – to be replaced by on-the-fly analytics across local or enterprise data sources. Best of all, hundreds of chart options are auto-generated.
From the brochure:
“RMS Vision combines a powerful keyword search engine, with comprehensive graphical reporting to deliver real-time business intelligence and analytics on terabytes of data, permitting unrestricted cross-dimensional associations between data entries and spanning multiple data sources.”
I believe the most compelling aspect of this offering is that you can begin to start exploring data without knowing precisely you are looking for. You can just surf, browse and discover.
The end result is more flexible access to the stuff you know about and a creative process of discovering the stuff you don’t know about. All of which lead to more insights and better decision making. So if you are frustrated with the limitations of the reports in your existing technology but don’t want to throw out the whole service desk – it’s worth a look.
More info here or for UK based readers RMS will be exhibiting at SDITS next week.
In my previous piece for The ITSM Review, I examined the state of general dissatisfaction with ITSM tools at the moment.
In doing so, I wanted to question why a positive dedication to “process” should be at the heart of how organisations solve complex (and simple for that matter) IT services challenges. This time around, I want to look at the human element of process.
The new ABC
ABC (for the purposes of our story here) stands for Attitude, Behaviour and Culture — basically, this sets out to ensure that the human aspect of ITSM and service delivery matches that of the IT implementation.
One area that can help ITSM professionals today is to look at their approach to ABC in a new light, based on understanding the wider processes that are in place.
Re-evaluating processes gives ITSM teams the opportunity to look at their own ABC successes and issues again. It also represents a chance to examine how these ABC milestones can be used to improve wider service within the organisation. Without the right elements in place, those individuals working on the service desk may not be able to deliver what the business expects and requires of them. More importantly, changes within the organisation won’t be successful.
ABC is equally important when it comes to inter-team communication, as the hand-off between teams can be affected by differences in approach and behaviour. If one team is performing well on its own terms, but its output goes through another group with motivational challenges or a different work method, then the initial team’s work may be viewed as not meeting the overall requirements of the business.
The release management black hole
This can be seen in the ITSM world when an application implementation is not completed successfully across to the complete scope and breadth of the organisation. The application itself has been written to specification, thoroughly tested and was ready to go — but the team responsible for managing help-desk calls may see a massive spike in users getting in touch. In this example, the release management process has not been completed successfully, which leads to issues getting raised with the help-desk team and poor perception of IT in general.
Nothing was wrong in the development phase and the ITSM function can provide a great level of service — however, what users remember is that there was a problem in the first place.
In the user’s mind, IT is seen as being one complete unit, yet this is not often the case. Most teams within large organisations are broken down into project and technology teams, depending on how they have evolved over time. Responsibility is split across these different teams and each can have its own approach to managing work based on how it is led.
Achieving some kind of level of “unity of approach” and getting each part of IT to buy into a common set of values is a significant challenge. The responsibility for this should sit with the CIO as part of their leadership role. As business requirements change and IT has to evolve to support new demands, so getting the right processes in place to complement the right ABC is therefore critical. Changing or amending behaviour at the individual level relies on how much people buy into what is being put in place at the process level, too.
Process and ABC: a two-way street?
On the individual attitude and behaviour front, there has to be an understanding across the IT team responsible for delivering a service of how their section fits into the wider business process. This can be as simple as letting each individual know how their work contributes towards a key performance indicator or meeting a service level. For organisations that already have some degree of joined-up processes, the information given back to people can be much more granular.
At the same time, this emphasis on process can be used to remove manual work where it is possible to take it out. In the example above, automating the release of an application that has been developed and tested properly, rather than relying on ad hoc scripting and manual labour, could remove the potential for things going wrong. Not only does this speed up the process overall, it also makes the whole IT team concerned with that installation appear to be part of a uniform and co-ordinated strategy to the business.
For organisations with ABC challenges, looking at “process hand-overs” between teams is the simplest way to evaluate where these problems start and why. Is this an issue with an individual, a team or with the wider IT function within the organisation? Depending on the level at which the problem is occurring, this will change how the ITSM team looks at their processes in a new light.
The attitude and culture that a company has in place will have an impact on the overall process that is being completed — if employees feel valued and trusted, then they are more likely to care that the results of their work are good. At the same time, design of a process can affect ABC as well — a well-designed process that is fit for purpose, automated where it needs to be, and running well should support employees in achieving job satisfaction.
The business-to-IT connection challenge
One of the most common complaints around IT is that it does not match up with the business. Traditionally, IT has been separate to business functions based on the availability of the skills that were required to understand and run the technology department. This is changing with the advent of cloud computing and the growing understanding of IT within the business itself. But whether organisations want to embrace a cloud computing approach or not, the fact is that ITSM professionals have to realise that their service delivery is being judged against a different yardstick. Whereas previously, IT operations and services would be based on what direct competitors are doing, now it is more likely that the business will look at what consumer websites and portals are able to deliver.
This change in emphasis and the need to keep pace with what the business expects from IT, makes looking at ABC more important than ever. Service providers have the mantra in place that “the customer is king” – even when they either don’t know what they want, or are actively looking at the wrong approach. For ITSM, this means looking again at their attitudes to managing users and where this may have to change in future. As cloud continues to attract interest, IT will have to learn lessons from the service provider world.
Managing ABC in this environment should theoretically be easier — after all, IT and the business are both part of the same company. However, there can be this barrier between the two that has to be broken down. If it is not, then IT risks either remaining as a support function with little value, or instead being replaced with outside tools and services instead. This would do ITSM a grave disservice, as it should be obvious that internal IT teams have not only the interest of the organisation at the front of their minds but also the most in-depth knowledge of what the business really requires. What does have to change is that understanding of service delivery from the business perspective.
Hand in hand with this ITSM imperative is the need to get the business function’s perception of IT to change. The attitude and behaviour of the business towards IT is just as important as IT’s own ABC i.e. without the willingness to embrace IT as a strategic part of the corporate decision making process, there can be no real change in approach across ITSM. IT can aim at being customer-centric as much as possible, but if the IT team is not involved in the decision-making process from the outset, then this will remain a largely unfulfilled ambition.
Analysing the role of IT across the business process is the best way to achieve the much-needed inclusion that we must achieve here, alongside aligning the culture of the IT team with that present across the wider organisation. By understanding how work goes through the business and the ITSM resources required to support that flow, IT can claim its place at the table.
I was wondering – do you have a Known Error Database? And are you getting the maximum value out of it?
The concept of a KEDB is interesting to me because it is easy to see how it benefits end users. Also because it is dynamic and constantly updated.
Most of all because it makes the job of the Servicedesk easier.
It is true to say that an effective KEDB can both increase the quality and decrease the time for Incident resolution.
The Aim of Problem Management and the Definition of “The System”
One of the aims of Problem Management is to identify and manage the root causes of Incidents. Once we have identified the causes we could decide to remove these problems to prevent further users being affected.
Obviously this might be a lengthy process – replacing a storage device that has an intermittent fault might take some scheduling. In the meantime Problem Managers should be investigating temporary resolutions or measures to reduce the impact of the Problem for users. This is known as the Workaround.
When talking about Problem Management it helps to have a good definition of “Your System”. There are many possible causes of Incidents that could affect your users including:
Networks, connectivity, VPN
Services – in-house and outsourced
Policies, procedures and governance
Documentation and Training materials
Any of these components could cause Incidents for a user. Consider the idea that incorrect or misleading documentation would cause an Incident. A user may rely on this documentation and make assumptions on how to use a service, discover they can’t and contact the Servicedesk.
This documentation component has caused an Incident and would be considered the root cause of the Problem
Where the KEDB fits into the Problem Management process
The Known Error Database is a repository of information that describes all of the conditions in your IT systems that might result in an incident for your customers and users.
As users report issues support engineers would follow the normal steps in the Incident Management process. Logging, Categorisation, Prioritisation. Soon after that they should be on the hunt for a resolution for the user.
This is where the KEDB steps in.
The engineer would interact with the KEDB in a very similar fashion to any Search engine or Knowledgebase. They search (using the “Known Error” field) and retrieve information to view the “Workaround” field.
The “Known Error”
The Known Error is a description of the Problem as seen from the users point of view. When users contact the Servicedesk for help they have a limited view of the entire scope of the root cause. We should use screenshot of error messages, as well as the text of the message to aid searching. We should also include accurate descriptions of the conditions that they have experienced. These are the types of things we should be describing in the Known Error field A good example of a Known Error would be:
When accessing the Timesheet application using Internet Explorer 6 users experience an error message when submitting the form.
The Known Error should be written in terms reflecting the customers experience of the Problem.
The Workaround is a set of steps that the Servicedesk engineer could take in order to either restore service to the user or provide temporary relief. A good example of a Workaround would be:
To workaround this issue add the timesheet application to the list of Trusted sites
1. Open Internet Explorer 2. Tools > Options > Security Settings [ etc etc ]
The Known Error is a search key. A Workaround is what the engineer is hoping to find – a search result. Having a detailed Workaround, a set of technical actions the Servicedesk should take to help the user, has multiple benefits – some more obvious than others.
Seven Benefits of Using a Known Error Database (KEDB)
Faster restoration of service to the user – The user has lost access to a service due to a condition that we already know about and have seen before. The best possible experience that the user could hope for is an instant restoration of service or a temporary resolution. Having a good Known Error which makes the Problem easy to find also means that the Workaround should be quicker to locate. All of the time required to properly understand the root cause of the users issue can be removed by allowing the Servicedesk engineer quick access to the Workaround.
Repeatable Workarounds – Without a good system for generating high-quality Known Errors and Workarounds we might find that different engineers resolve the same issue in different ways. Creativity in IT is absolutely a good thing, but repeatable processes are probably better. Two users contacting the Servicedesk for the same issue wouldn’t expect a variance in the speed or quality of resolution. The KEDB is a method of introducing repeatable processes into your environment.
Avoid Re-work – Without a KEDB we might find that engineers are often spending time and energy trying to find a resolution for the same issue. This would be likely in distributed teams working from different offices, but I’ve also seen it commonly occur within a single team. Have you ever asked an engineer if they know the solution to a users issue to be told “Yes, I fixed this for someone else last week!”. Would you have prefered to have found that information in an easier way?
Avoid skill gaps – Within a team it is normal to have engineers at different levels of skill. You wouldn’t want to employ a team that are all experts in every functional area and it’s natural to have more junior members at a lower skill level. A system for capturing the Workaround for complex Problems allows any engineer to quickly resolve issues that are affecting users.Teams are often cross-functional. You might see a centralised application support function in a head-office with users in remote offices supported by their local IT teams. A KEDB gives all IT engineers a single place to search for customer facing issues.
Avoid dangerous or unauthorised Workarounds – We want to control the Workarounds that engineers give to users. I’ve had moments in the past when I chatted to engineers and asked how they fixed issues and internally winced at the methods they used. Disabling antivirus to avoid unexpected behaviour, upgrading whole software suites to fix a minor issue. I’m sure you can relate to this. Workarounds can help eliminate dangerous workarounds.
Avoid unnecessary transfer of Incidents – A weak point in the Incident Management process is the transfer of ownership between teams. This is the point where a customer issue goes to the bottom of someone else queue of work. Often with not enough detailed context or background information. Enabling the Servicedesk to resolve issues themselves prevents transfer of ownership for issues that are already known.
Get insights into the relative severity of Problems – Well written Known Errors make it easier to associate new Incidents to existing Problems. Firstly this avoids duplicate logging of Problems. Secondly it gives better metrics about how severe the Problem is. Consider two Problems in your system. A condition that affects a network switch and causes it to crash once every 6 months. A transactional database that is running slowly and adding 5 seconds to timesheet entry You would expect that the first Problem would be given a high priority and the second a lower one. It stands to reason that a network outage on a core switch would be more urgent that a slowly running timesheet system But which would cause more Incidents over time? You might be associating 5 new Incidents per month against the timesheet problem whereas the switch only causes issues irregularly. Being able to quickly associate Incidents against existing Problems allows you to judge the relative impact of each one.
The KEDB implementation
Technically when we talk about the KEDB we are really talking about the Problem Management database rather than a completely separate store of data. At least a decent implementation would have it setup that way.
There is a one-to-one mapping between Known Error and Problem so it makes sense that your standard data representation of a Problem (with its number, assignment data, work notes etc) also holds the data you need for the KEDB.
It isn’t incorrect to implement this in a different way – storing the Problems and Known Errors in seperate locations, but my own preference is to keep it all together.
Known Error and Workaround are both attributes of a Problem
Is the KEDB the same as the Knowledge Base?
This is a common question. There are a lot of similarities between Known Errors and Knowledge articles.
I would argue that although your implementation of the KEDB might store its data in the Knowledgebase they are separate entities.
Consider the lifecycle of a Problem, and therefore the Known Error which is, after all, just an attribute of that Problem record.
The Problem should be closed when it has been removed from the system and can no longer affect users or be the cause of Incidents. At this stage we could retire the Known Error and Workaround as they are no longer useful – although we would want to keep them for reporting so perhaps we wouldn’t delete them.
Knowledgebase articles have a more permanent use. Although they too might be retired, if they refer to an application due to be decommissioned, they don’t have the same lifecycle as a Known Error record.
Knowledge articles refer to how systems should work or provide training for users of the system. Known Errors document conditions that are unexpected.
There is benefit in using the Knowledgebase as a repository for Known Error articles however. Giving Incident owners a single place to search for both Knowledge and Known Errors is a nice feature of your implementation and typically your Knowledge tools will have nice authoring, linking and commenting capabilities.
What if there is no Workaround
Sometimes there just won’t be a suitable Workaround to provide to customers.
I would use an example of a power outage to provide a simple illustration. With power disrupted to a location you could imagine that there would be disruption to services with no easy workaround.
It is perhaps a lazy example as it doesn’t allow for many nuances. Having power is a normally a binary state – you either have adequate power or not.
A better and more topical example can be found in the Cloud. As organisations take advantage of the resource charging model of the Cloud they also outsource control.
If you rely on a Cloud SaaS provider for your email and they suffer an outage you can imagine that your Servicedesk will take a lot of calls. However there might not be a Workaround you can offer until your provider restores service.
Another example would be the February 29th Microsoft Azure outage. I’m sure a lot of customers experienced a Problem using many different definitions of the word but didn’t have a viable alternative for their users.
In this case there is still value to be found in the Known Error Database. If there really is no known workaround it is still worth publishing to the KEDB.
Firstly to aid in associating new Incidents to the Problem (using the Known Error as a search key) and to stop engineers in wasting time in searching for an answer that doesn’t exist.
You could also avoid engineers trying to implement potentially damaging workarounds by publishing the fact that the correct action to take is to wait for the root cause of the Problem to be resolved.
Lastly with a lot of Problems in our system we might struggle to prioritise our backlog. Having the Known Error published to help routing new Incidents to the right Problem will bring the benefit of being able to prioritise your most impactful issues.
A users Known Error profile
With a populated KEDB we now have a good understanding of the possible causes of Incidents within our system.
Not all Known Errors will affect all users – a network switch failure in one branch office would be very impactful for the local users but not for users in another location.
If we understand our users environment through systems such as the Configuration Management System (CMS) or Asset Management processes we should be able to determine a users exposure to Known Errors.
For example when a user phones the Servicedesk complaining of an interruption to service we should be able to quickly learn about her configuration. Where she is geographically, which services she connects to. Her personal hardware and software environment.
With this information, and some Configuration Item matching the Servicedesk engineer should have a view of all of the Known Errors that the user is vulnerable to.
Measuring the effectiveness of the KEDB.
As with all processes we should take measurements and ensure that we have a healthy process for updating and using the KEDB.
Here are some metrics that would help give your KEDB a health check.
Number of Problems opened with a Known Error
Of all the Problem records opened in the last X days how many have published Known Error records?
We should be striving to create as many high quality Known Errors as possible.
The value of a published Known Error is that Incidents can be easily associated with Problems avoiding duplication.
Number of Problems opened with a Workaround
How many Problems have a documented Workaround?
The Workaround allows for the customer Incident to be resolved quickly and using an approved method.
Number of Incidents resolved by a Workaround
How many Incidents are resolved using a documented Workaround. This measures the value provided to users of IT services and confirms the benefits of maintaining the KEDB.
Number of Incidents resolved without a Workaround or Knowledge
Conversely, how many Incidents are resolved without using a Workaround or another form of Knowledge.
If we see Servicedesk engineers having to research and discover their own solutions for Incidents does that mean that there are Known Errors in the system that we aren’t aware of?
Are there gaps in our Knowledge Management meaning that customers are contacting the Servicedesk and we don’t have an answer readily available.
A high number in our reporting here might be an opportunity to proactively improve our Knowledge systems.
want to ensure that Known Errors are quickly written and published in order to allow Servicedesk engineers to associate incoming Incidents to existing Problems.
One method of measuring how quickly we are publishing Known Errors is to use Organisational Level Agreements (or SLAs if your ITSM tool does’t define OLAs).
We should be using performance measurements to ensure that our Problem Management function is publishing Known Errors in a timely fashion.
You could consider tracking Time to generate Known Error and Time to generate Workaround as performance metrics for your KEDB process.
Additionally we could also measure how quickly Workarounds are researched, tested and published. If there is no known Workaround that is still valuable information to the Servicedesk as it eliminates effort in trying to find one so an OLA would be appropriate here.
The itSMF held their UK South West & South Wales Regional meeting at the University of Exeter this week.
The theme of the day was processes and toolsets with a big emphasis on member interaction and discussion.
In a nutshell: A good day. Recommended.
Two presentations really stood out for me during the day. Firstly Deborah Pitt, Configuration Manager at Land Registry Information Systems in Plymouth, gave a compelling talk on how she managed to convince various IT teams within Land Registry to buy-in to their CMDB. In short, Deborah recalled her strategy of badgering, evangelising and more badgering.
Winning Friends and Implementing CMDBs
Deborah shared with us that she increased engagement and adoption with the CMDB by farming out responsibility for configuration items to various IT teams. For example, the team responsible for management of blackberry devices were assigned ownership of Blackberry data within the CMDB, a great strategy for building confidence in the system and getting users to let go of their precious excel sheets.
“Although process and tools have both been important in getting buy in from consumers and owners of the data that goes into the CMDB, another, often overlooked factor has been a major plank of getting the message across. This is building successful, communicative relationships with both consumers and owners. Through selectively targeting the audience and tailoring the message, Land Registry have been able to build enthusiasm for CMDB, such that there is now a widespread take up of CI use and ownership.” Deborah Pitt, Land Registry.
Zach shared how the IT support team at the University were coping with the changing demands of students. It was interesting to hear of the changing attitudes towards IT support since tuition fees were abolished. Since students will be paying £9K per annum out of their own pocket from 2012, this was beginning to translate into higher expectations and demands of IT support (e.g. If I’m paying £9K a year to study here I’m not paying extra for printing).
The IT team are also under increasing pressure to provide 24/7/365 IT services for multiple devices per student. For example students are arriving on campus with a laptop, tablet and phone with all flavours of platforms and expecting instant compatibility and high-speed ubiquitous WIFI access.
Fish Where The Fish Are
To provide higher levels of support at the University and align closely with current requirements Zach and his team hold focus groups with students. As a result the University has begun to explore Twitter as an IT support communication channel. When given the option, students at the University chose Twitter as their preferred update mechanism.
I think this is an important point for anyone considering implementing social channels into their support infrastructure. When considering implementation with a particular channel we need to consider:
Do our customers actually use this social media channel?
And do they want to hear from us when they are using it? (Zach noted that although students spent a great deal of time on Facebook their preferred update mechanism was Twitter)
If students of today are recruits of tomorrow then this initiative paints a picture of IT Support in 2015.
The University of Exeter are a long term Hornbill customer and are exploring a module from Hornbill specifically for twitter integration. Want to know how they get on? Follow them here.
“Gamification is the concept of applying game-design thinking to non-game applications to make them more fun and engaging.” http://gamification.org/
The logic states that generations of IT workers have been weaned throughout their youth on video games, so game-like features can be introduced to the workplace to increase employee engagement and satisfaction.
In ITSM terms this means being awarded points, badges and appearing on leader boards based on specific service desk actions.
There is much talk of Gamification in the ITSM industry (Gartner plots ‘Gamification’ hype at near peak) – but is Gamification simply marketing hysteria or a real force for change?
Firstly, I believe something smells a bit fishy about conditioning employees to beg, roll and fetch for coins and stars like Pavlov’s dogs. Shouldn’t the work itself be rewarding and fulfilling? But existential angst aside, I think it is a smart idea if implemented correctly and a great opportunity to inject a bit of fun into everyday working life.
Two examples of game mechanics in action stand out from my working career. Both were a similar format with similar goals – one went very well and one went horribly wrong. If I were to pinpoint the difference between success and failure of these two games – it would be the respect staff had for the boss. I don’t think game mechanics can be implemented as a Band-Aid for poor morale and poor performance. It takes the right spirit and the right manager.
InvGate claims the benefits of gamifying the service desk include great team engagement, increased productivity, increased team collaboration, and aligned objectives.
An important point in the InvGate offering is the ability to reward service desk agents, in a fairly automated fashion, based on perceived quality by users.
These rewards are not based on banal ITSM metrics but by ‘likes’, ‘thumbs ups’, ‘stars’ and other simple measures of user satisfaction (Social concepts that users are likely to be increasingly familiar with outside of work). Never mind first call resolution time – was the user HAPPY?
The most powerful aspect of this for a manager, assuming she has her team onside and playing along – is the ability to align quickly with business goals. Even the largest of service desks can quickly focus on tactical campaigns with a high degree of engagement from agents. Good-bye Service Desk Manager, hello Game master.
A cool offering from InvGate, I’m looking forward to delving further – further info here.