The Adaptive Service Model

The Taking Service Forward initiative has launched the first release of the Adaptive Service Model, you can see the official announcement here. This model is the first step on the way to an open architecture for service management. I’d like to share some of my thoughts about what the model is, why we need it, and how it might evolve in the future.

This model is owned by a community called Taking Service Forward. The initial members were invited to participate, but in a few weeks anyone will be able to join by making contributions to the architecture. If you want to see announcements about this then join the Taking Service Forward community on Google+, or the  group on Facebook or on LinkedIn .  You can also see more details about the history of Taking Service Forward on these sites.

This first release is a “meta-model” showing the types of things that will be in the actual architecture. For example it includes “process” and “role” but not any specific processes or roles.

Adaptive Service Model - Abstraction - Diagram v0.11
This diagram shows a very high level view of the model.

Even at the level shown in this diagram there are some interesting things that you can see about the model:

  • There is no reference to IT. This is not an IT service model, it is a generic model about services. It can certainly be used by people who manage IT services, but the intent was to start at a higher level where the key concept is “service”, not “IT service”.
  • There is a symmetrical relationship between the service provider and the service consumer. This is not a model about how service providers create services, it is about how service providers and service consumers work together to create value based on using services. The service consumer plays just as important a role in this relationship as the service provider: both provider and consumer receive outputs and outcomes from the service; and both provider and consumer must have suitable processes and roles to enable the creation of service value.

The meta model has been published as three entities:

  • A document which describes the concepts, modelling language and principles
  • The model itself. This is an entity-relationship diagram which has been created in ArchiMate®, an open and independent modelling language for enterprise architecture. You need to install the free, open source Archi software to open the model, but you can download a diagram showing all the entities and relationships if you want to see the model without being able to make edits
  • A table with descriptions and attributes for each entity and relationship

The Adaptive Service Model is open source, released under a creative commons license, so it can be freely used by anyone, even in a modified form – so long as they give appropriate credit, provide a link to the license, and indicate if changes were made.

Use of the meta model

The main use of the meta model will be as a foundation for creating an architecture, with much more specific entities. For example the meta model has entities called “process” and “role”, the architecture will show all the different processes and roles needed by both service providers and service consumers. The meta model will be useful for a number of purposes, even with the current very generic level of detail:

  • Facilitating discussions between service providers and service consumers, helping them to articulate their needs and expectations
  • Helping managers in service provider and service consumer organizations educate their staff about service relationships, management, governance and other high level concepts
  • Providing a context to help different types of service providers (and consumers) discuss what is common between them, to help create opportunities were we can learn from people in different industries
  • Improving our ability to provide mapping between standards and best practices by providing a consistent, common language for the highest level entities

Next stages

The next stage of our work will be to validate the meta model, correct any aspects that need improvement, and complete missing content. The intent is that this should be done with open participation from the service management community so that we can pull on the widest possible breadth of knowledge.

Once the meta model is complete there will be two more stages to this work:

1)     Creating a detailed service architecture, based on the meta model. This architecture could be used for a number of purposes.

  • It could help the owners of different best practices and standards improve their alignment with each other
  • It could provide a formal structure for service management, to help organizations create and review their systems for governance and management of IT
  • It could be further developed to create industry specific variants (for example an IT service management architecture)
  • It could provide a framework for future releases of best practice such as ITIL, to improve internal consistency while allowing for a natural, narrative, style of communication

2)     Creating a detailed ontology, based on the architecture. An ontology would define detailed protocols for interoperability, for example an “incident exchange” message format. A formal ontology has many potential uses, including:

  • Enabling tool vendors to create inter-operable tools based on open source, published definitions
  • Helping people designing complex multi-supplier solutions to specify the requirements for interchange of incidents, changes, problems and other records

The work has only just started, and there is a huge amount to do to get to our end goal, but I think it will be worth the effort. Please download the model and see what you think of it. Then consider signing up to contribute to the future development of this Adaptive Service Model, it will only be as good as the people who take part. You can offer feedback using any of the community groups listed at the beginning of this article, and in a few weeks you will be able to submit change requests and become a member of the Taking Service Forward initiative that owns the model.

LogMeIn ends free offering

support

Within the last week remote computer access software company LogMeIn have announced that they will be discontinuing their free remote access product – LogMeIn free – with immediate effect.

“After 10 years, LogMeIn’s free remote access product, LogMeIn Free, is going away,” wrote LogMeIn’s Tara Haas. “We will be unifying our portfolio of free and premium remote access products into a single offering. This product will be a paid-only offering, and it will offer what we believe to be the best premium desktop, cloud and mobile access experience available on the market today.”

Current users of the service will receive an email and a screen message the next time that they log in informing them that they have a paltry seven days to upgrade to a premium account before access to their account is revoked.

In an article for PC World Tony Bradley, Principal Analyst at Bradley Strategy Group states:

“The decision to end LogMeIn Free is abrupt and a bit confusing. It seems like it’s been relatively successful at luring customers to sign up and generating revenue for LogMeIn from the premium account subscriptions.”

Forum members of tech.slashdot.org have criticized the company for the abrupt change:

“…I must say I might have considered signing up for pro, but the zero-notice cancellation of the free account has left a major bad taste in my mouth. It’s a pretty blatant attempt to rush people into signing up for the paid program, because hey, give people a month’s notice to evaluate alternatives and the might find something else they like. For that reason, there is zero chance I’ll sign up for logmein pro.” – TX

Though it appears not all customers are jumping ship with some reportedly being offered six months of pro service as an incentive to continue:

“…at the risk of not conforming to a potential lynch mob mentality, it would appear they’re giving me 6 months of pro service on my existing account before they turn it off. This is plenty of time to make a change.” – Zugmeister

With some just suggesting users should thank LogMeIn for provided the free service for as long as they did:

“It’s so typical. Someone offers a service/product for free. People use it and like it. They keep using it. Then the service/product gets changed/removed/etc. and everyone yells at the owner about how they feel shafted instead of *thanking* the owner for providing such a useful service for free for so long. Everyone feels entitled to get whatever they want for free.” – Nicholasjay

Thinking of changing to another free service?  Stuart Facey, VP EMEA at Bomgar has the following advice…:

“A lot of people are complaining that the once-free service is being taken away and they’ve only been given a week to either pay for LogMeIn Pro or switch to another free service, like Teamviewer. However, while these free tools can be great for accessing your personal computer, they aren’t designed for providing professional support to your company’s or customers’ systems.

If you find yourself having to switch away from a free tool, it’s important to think about your next step – are you only supporting friends and family? Then stick with other free tools that are on the market.

If you are responsible for a wider range of services, or if you have to think about connecting to customer systems in a secure way, then you will have to put more thought into this change. In the world of support, it is important to look at how you deliver services over time and make sure that you are providing value for your customers as well as maintaining your own approach in the right way. The increasing need for collaboration around support challenges, including the capability to securely involve third party vendors, means that free tools will only be able to provide small sections of what you are after overall.

In this instance, it is very much a case of “you get what you pay for” – if you pay nothing, then you won’t get all the functionality that you need, and that may negatively impact the overall quality of service.”

LogMeIn hasn’t done itself any favours with the way it has approached the situation with many users seeming to be more annoyed with the notice period than the discontinuation of the service.

Advice to anyone else planning on pulling a free service where you have a paid alternative:  Treat users like prospective paying customers and not a bunch of freeloaders.

Moving away from LogMeIn?  Here are some alternatives:

Tool Name Description Cost
TeamViewer TeamViewer provides an All-In-One solution for a wide variety of scenarios in a single software package: remote maintenance, spontaneous support, access to unattended computers, home office, online meetings, presentations, training sessions and team work. Free for all non-commercial users£439-£2,219 for Business users depending on package
Chrome Remote Desktop Chrome Remote Desktop allows users to remotely access another computer through Chrome browser or a Chromebook.  Computers can be made available on an short-term basis for scenarios such as ad hoc remote support, or on a more long-term basis for remote access to your applications and files.  All connections are fully secured. Free*As it’s supplied by Google I’d check the privacy policy
Remote Utilities Remote Utilities gives users 15 different modes for connecting to PCs remotely. Users can view screens, send keystrokes, control the mouse, and transfer files. This makes it ideal for IT professionals looking to provide remote support and network administration. Free for both business and personal use for up to 10 remote PC’sOver this$29.95 per remote PC OR$549.00 per operator

 

Citrix GoToAssist GoToAssist enables you to provide fast and easy live remote support with a solution designed to meet your specific business needs. Compare our remote support, service desk and IT monitoring solutions and see which works best for you and your organisation. £39/mo per technician
Bomgar Remote Support Bomgar lets you support all of your systems over the web, even if they are behind firewalls you don’t control.Support customers on remote desktops running Windows, Mac or various Linux distros. Or support a variety of mobile devices – including Android, iPhone, iPad, BlackBerry and Windows Mobile. POA

Image Credit 

 

 

Social Meet Up: 9th February

drinkOwing to the success of our ad hoc social gatherings in London in 2013, we’re planning a full schedule for 2014! The first of which will take place on Sunday 9th February at 6pm GMTSunday I hear you cry?! You can blame that on our US ITSM friends John Custy and Brian Hollandsworth, as they don’t have any other availability during their visit to the UK and we couldn’t have them leave without a social get together. Actually that is unfair, John had space during the week so just blame Brian!

Full details on location, costs and how to RSVP can be found below. Whether you’re a practitioner, vendor, or consultant we would love to have you come along for some informal networking, putting the ITSM and ITAM world to rights, a few tipples, and generally just a fabulous time.

Also, for anyone who is interested, we will also be arranging an afternoon of sightseeing across London for our dear American friends and anybody and everybody is welcome to come along. Please just let me know when you confirm your place for dinner.

A full schedule of all of our planned socials will be published soon. Apologies to all of our readers outside of the UK, as our sites continue to grow and prosper we hope to be able to arrange similar networking events like this on a more global basis.


WHAT

Informal ITSM and ITAM social gathering

WHERE

Somewhere yummy in London. Exact location TBC.

WHEN

Sunday 9th February from 6pm GMT

COSTS

Cost of your individual meal and drinks will be payable on the night. We recommend budgeting between £20-40 for the evening. Please note that we will not be responsible for the final bill. There is a £10 deposit required per person.

RSVP

Please contact me directly to confirm your attendance. Deposit instructions will then be provided.

CONFIRMED ATTENDEES

Confirmed attendees will be listed here.

Image Credit

Why is configuration management so tough?

phones
IT Hoarders – do you really need all those old IT items that you no longer use?

Overheard at a recent conference:

“Oh, we are working on configuration management…Why? Because it’s an ITIL process”

I cringed.

The conversation continued with “…yeah, I don’t know why it’s not going well. We bought <well-known tool name here> which has a CMDB. We have been adding configuration items (CI) into the CMDB for the last two months. Nobody in the IT team is using the CIs for incidents or change…”

I walked away, no longer wanting to hear any more of the gory details. Unfortunately, I feel this is more the norm than the exception. Let us take a few moments to examine why.

IT is a version of “Hoarders

IT is notorious for buying lots of stuff (that is a technical term) and equally notorious for not decommissioning items. Working in Higher Education, I often see departments who have plenty of funds and those departments who have to do whatever necessary to survive. This culture propagates surviving on the “scraps” thrown off by the “rich” departments when they get new items. IT often helps “repurpose” equipment to defer costs. Unfortunately, we end up with rooms full of devices, some of which may be running important business operations, with limited knowledge of what/how they are connected, the service they help provide, or why. Sometimes it may even become difficult to know who supports the device.

These actions have positioned IT to have a “hoarder” mentality. Don’t think so? We all know the team mate who has a copy of Windows 3.1 on 3½” disk who is hanging on to them because “…you just never know when the might be needed…” The spare equipment room, items sitting on inventory shelves, unappropriated devices in communications closets, servers under desks, overhead desk cabinets full of various versions of software, all adding up to “a big ol’ mess”.

With this much stuff, the task of building usable CIs becomes daunting. The sheer volume (thousands of items) becomes overwhelming and dooms the thinking of the configuration management team to “…we can’t do this…”.

It’s all about the CMDB

Ask this question “Are you doing any type of configuration management?” There is a good chance you will get a response of “Yes, we’ve got a CMDB”. This is just maddening.

I do not blame vendors for this. It is the vendor’s job to promote its products, but unfortunately, too many folks take the information provided by the vendor and translate it into “…to do configuration management we need a CMDB…”” to making your configuration management process work. Configuration management is about understanding the items that make your services work and their relationships. The CMDB should help the IT team mitigate risk during change decisions, help in trending during problem management, and allow the IT team to understand the impact of their operational decisions.

Education on Configuration Management

Where is the education? Now before all the ATO send me hate mail, I’m taking about where are the practitioners talking about configuration management? Formal training is not the issue. There seem to be very few good storytellers out there when it comes to configuration management.

In fairness, the reason there may be so few good storytellers may be due to how much context plays in configuration management. Let’s be honest, the context of my organization is different from the context of your organization. Incident management runs pretty much the same across all organizations. Simple premise of “get the issues resolved as quickly as possible” translates to everyone. The stories are transportable to each organization regardless of context. Because of this, ideas become quickly adaptable and usable.

With configuration management, we do not see the same ability to be transportable. Configuration management begins with the relationship of your services to the business. It becomes difficult to adopt an idea that does not match with your context.

Configuration management also seems to be the place most people really want a “recipe” for. “Just tell us how to do it”, the phrase uttered from many configuration management teams who realize the level of work they will need to do just to figure out where to start. Education on configuration management is most likely not a fair phrase. Configuration management does require a “deep dive” into the method and diligence to obtain desired outcomes. Make sure your team has the passion and the “intestinal fortitude” to make the tough decisions to build a configuration management process for your context.

“Ownership” of CIs

When you start discussing Configuration Management, you will undoubtedly run into folks in your organization who feel they “own” whatever CI you may be discussing. Sometimes their attitude may be perceived as “…this <device> is my responsibility…how dare you have an opinion on what I should do…” or “…I don’t report to you…you can’t tell me what to do…” They come by this honestly. For many years, IT perpetuated “silos” and one did not simply cross boarders without permission. Because of the way IT has worked in the past, many people see the items that they manage as “personal” pieces of their work and change for those items “require” a personal level of collaboration with the individual.

As we know, ITSM breaks down this paradigm and promotes a spirit of service across departments. Unfortunately, this does not always hold true when it comes to people managing devices. Depending on your organization culture, you may have teammates who do not buy in to the concept of configuration management. The configuration management team must do everything they can to break down these walls and ensure all teammates understand configuration management is not about taking away authority. Building a plan that helps IT deliver great services depends on team member participation at all levels. If your organization culture values individual performance over team achievement, you will have problems getting configuration management to stick.

Final Thoughts and Tips for Configuration Management

Configuration management is tough because:

  • Everyone in IT must commit to the process
  • It depends on organizational context
  • It may require big organizational change AND individual change

Tips:

  • Understand the services your organization offers. Have discussions regarding CIs around how they relate to services.
  • Find people who are willing to do the deep dive into Configuration Management and who are willing to change the organization. Having a few “cynics” who are willing to challenge ideas is a good thing as long as they are working for the betterment of the business and not disrupting progress.
  • Repeat with me, “IT’S NOT ABOUT THE CMDB!” The CMDB should be something that helps accelerate other processes.
  • At some point, someone is going to take the change personally. The Configuration Management team should practice dealing with this issue. Have a script on how to respond when challenged with why the change is necessary. Remind others, it’s about us looking good.
  • Take the time to move a CI through its lifecycle manually. Doing so will help the Configuration Management team understand how CIs are used with other processes, the relationships CIs have with services, and if your process meets your context. Once you have perfected the flow, use the CMDB to accelerate processes.

Configuration management is not impossible but it does require commitment, compassion, and compromise. Be sure to build a team that has the passion to build a configuration process and to help IT commit to using it.

Image Credit

Problem management challenges and critical success factors

Following his presentation on “problem management challenges and critical success factors” at the 8th annual itSMF Estonia conference in December, Tõnu Vahtra, Head of Service Operations at Playtech (the world’s largest publicly-traded online gambling software supplier) gives us his advice on understanding problem management, steps to follow when implementing the process, and how to make it successful. 

Tõnu Vahtra
Tõnu Vahtra

Problem management is not a standalone process

Incident management and event management

It cannot exist without the incident management process and there is a strong correlation between incident management maturity and problem management efficiency/results. Incident management needs to ensure that problems are detected and properly documented (e.g. the basic incident management requirement that all requests need to be registered). Incident management works back-to-back with the event management process, if both of these processes are KPI managed then any anomalies in alarm or incident trends can be valuable input to problem management. Incident management also has to ensure that in parallel to restoring service during an incident it has to be ensured that relevant information is collected during or right after resolution (e.g. server memory dump before restart) so that there would be more information available to identify incident root cause(s).

Critical incident management

Problem management at Playtech gains a lot from the critical incident management function, which is carried out by dedicated Critical Incident Managers who have the widest logical understanding of all products and services and years of experience with solving critical incidents. They perform incident post mortem analysis following all major incidents, and they also start with initial root cause analysis (RCA) before handing this task over to problem management. RCA is handed over to Problem Managers within 24 hours from incident end time during which the Critical Incident Manager is collecting and organizing all information available about the incident. Critical Incident Managers usually do not have any problems with allocating support/troubleshooting resources from all support levels as critical incident troubleshooting and initial preventive measures are considered the highest priority within the mandate from highest corporate management. All the above ensures high quality input for problem management on a timely manner.

Change management and knowledge management

In Error Control phase the two most important processes for problem management are change management and knowledge management. Most action items identified during RCA are implemented through change management, the stronger the process the less problem management has to be involved directly in change planning (providing abstract goals VS concrete action plan or task list for implementation) and the smaller the risks of additional incidents during change implementation. Change management also needs to have the capability and documented process flow to implement emergency changes in an organized way with minimum impact to stop reoccurring critical incidents as fast as possible.

Knowledge management is vital for incident management for ensuring that service desk specialists would be able to quickly find and action specific workarounds for known errors until their resolution is still in progress by problem management. Regular input and high attention is needed from problem management to ensure that every stakeholder for known error database (KEDB) would be able to easily locate information relevant to his/her role, all units would be aware of information relevant to them and that all the information in KEDB would be relevant and up to date. In Playtech problem management is also managing process errors identified from root cause analysis and process improvements only last when properly documented, communicated to all relevant stakeholders and additional controls are put in place to detect deflections from optimal process. Local and cross-disciplinary knowledge management for process knowledge has an important role here.

Defect management

Problem management has to go beyond ITSM processes in a software development/services corporation like Playtech and also integrate to software development lifecycle (SDLC). For this purpose in Playtech a separate defect management sub-process has been established under problem management. Defect management is managing the lifecycle of all significant software defects identified from production environments and aligning defect fixing expectations between business and development departments. Defect Managers ensure a consistent prioritized overview of all significant outstanding software defects, which warrants optimal usage of development resources and minimizes overall business impact from defects. They act as a single point of contact for all defect related communication and ensure high transparency of defect fixing process and fix ETA’s. Defect Managers define the defect prioritization framework between business and development key stakeholders and govern the agreed targets.

Software problem management

Problem management is leading the software problem management process through defect management. Under the software problem management process (which is usually being ran by a quality assurance team in relevant development units) development teams are performing root cause analysis for defects highlighted for RCA by problem management or raised internally. Every defect is analyzed from two aspects: firstly why the defect was created by development and secondly if the defect was created then why was it not identified during internal QA and reported from production environment first. Root causes and action items are defined from both questions and tracked with relevant stakeholders. This process ensures that similar defects will not be created or will be identified internally in the future. Even more importantly there is a direct feedback channel from the field to the respective developer or team who created the defect so that they get full understanding of the business implications in relation to their activities.

Important steps to take problem management to the next level

The problem management unit has to become more proactive, to get more involved in service design and service transition phases to identify and eliminate problems before they reach production environments. Problem management needs resources to accommodate contributing to pre-production risk management and even more importantly this involvement has to be valued and enforced by corporate senior management as it may take additional resources and delay time-to-market in some situations.

The Problem Management Team itself can get more resources for proactive tasks by reducing their direct participation in reactive Problem management activities. This has to be done via advocating the Problem management mindset across the entire corporation (encouraging people to think in terms of cause and effect with the desire to understand issue causes and push their resolution for continuous improvement) so each major domain would have their Problem Coordinators and identify root causes/track action items independently and problem management could take more a defining and governing role. To assert the value created from problem management and enlist more people to spread the word about problem management ideas for them to go viral, it is essential to visualize the process and explain the relations between incidents, root causes and action items to all stakeholders for them to understand how their task is contributing to the bigger picture.

There is a high number of operationally independent problem management stakeholders in Playtech and implementing KPI framework that would be fit to measure and achieve problem management goals and be applicable to all major stakeholders individually and cross stakeholders seems almost impossible a task. The saying ”You get what you measure“ is very true in problem management and no stakeholder wants to be measured by problems that involves other stakeholders and are taking actions to remove such problems from their statistics instead of focusing on the problem and its solution. At the same time problem management tends to be most inefficient and difficult for problems spreading across multiple division. A Problem Manager’s role and assertiveness in facilitating a constructive and systematic process towards the resolution of such problems is crucial. And still problem management needs to find a creative approach to reflect such problems in KPI reports to present then as part of the big picture and sell them to executive management to get their sponsorship for major improvement tasks that compete with business development projects for the same resources while the latter has a much clearer ROI.

No problem exists in isolation and the problem records in KEDB can be related to specific categories/ domains and also related hierarchically to each other (there can be major principal problems that consist of smaller problems), also specific action items can contribute to the resolution of more than one problem. Problem categories cannot be restricted to fixed list as it can have multiple triggers and causes, it should be possible to relate a problem record to all interested stakeholders, for this dynamic tagging seems to be a better approach than limited number of categories (for example list of problems that are related to a big project). Instead of looking into each problem in isolation each problem should be approached and prioritized in the right context fully considering its implications and surroundings. No ITSM tool today provides the full capabilities for problem tagging or creating the mentioned relations without development, not to mention the visualization of such relations that would be a powerful tool in trend or WHAT-IF analysis and problem prioritization. Playtech is still looking for the most optimal problem categorization model and the tool that would enable the usage of such model.

Advice to organizations that are planning to start the implementation of the problem management process

For organizations starting the implementation of problem management process  my advice is don’t take all the process activities from the ITIL book and start blindly implementing them, this is not the way to start the implementation of this process or any other. Problem management success depends mostly on a specific mindset and in an already established organization it may take years for the right mindset to be universally accepted. Problem management formal process should be initially mostly invisible to all the stakeholders outside of the Problem Management Team to avoid the natural psychological tendency to resist change.

It is essential to allocate dedicated resources to problem management (Playtech assigned dedicated person to problem management in 2007, and any problem management activities prior to that were ad-hoc and non-consistent). The problem management unit should start from performing root cause analysis and removing the root causes of present major incidents that have the highest financial and reputational impact on the organization. If such incidents are being closely monitored by senior management and key stakeholders, solving them can earn the essential credits for problem management to get attention and resources for solving problems elsewhere. Secondly problem management should look at the most obvious reoccurring alarm and incident trends that result in a high support/maintenance cost. By resolving such problems they gain the trust of support and operational teams whose workload is reduced and they are more willing to contribute and cooperate in future root cause analysis. Problem final review before closure is a task often neglected but to improve the process it is essential to assess if the given problem was handled efficiently and to give feedback about problem solution to all relevant parties. Proactive problem management or KPI’s are not essential to start with and Problem Managers should concentrate on activities with highest exposure and clear value.

In summary

There will definitely be setbacks in problem management and in order to make a real difference with this process and increase the process maturity over time it has to have at least three things. A strong and assertive leader who is persistent in advocating the problem management; a continuous improvement mindset throughout the organization; and the ability to find a way forward from dead-end situations with out of the box thinking. When there is no such leader then involving external problem management experts may also help as a temporary measure to get the focus back on the most important activities. However, this measure is not sufficient in the long-term as the problem management process constantly needs to evolve with its organization and adjust with significant operational changes to be fit for purpose and remain relevant.

You can download Tõnu’s presentation in full here.

Coming Soon: The Battle of Change, Configuration and Release

wrestling
Let the battle begin!

We’re excited to be kicking off our research briefings next week for our competitive analysis on Change, Configuration and Release. Scheduled for publication in May, vendors confirmed to participate so far include:

The research will highlight competitive differentiators; feature key strengths (and weaknesses too of course); and showcase innovation within each product. Once reviewed, we will crown one Vendor “Best in Class” and the “leader” in Change, Configuration and Release.

Our research is based solely on responses to an in-depth questionnaire as well as a series of briefings, but we are always interested in hearing the end-user perspective.

Do you have experience with any of the participating Vendors? Do you have any views on their capabilities when it comes to Change, Configuration and Release? Are there any Vendors that you think are successful in this area who are not currently scheduled to participate in this review?

The review will be conducted by Rebecca Beach. For more information on the assessment view the Group Test criteria here. Vendors can still sign up to be involved up until Friday 31st January.

Subscribe to the ITSM Review newsletter or follow us on Twitter to receive a notification when the research is published.

Image Credit

Pink14 Preview: What’s the big idea?

"Sometimes you're so busy putting out fires that you don't have time to improve fire-fighting or fire-safety"
“Sometimes you’re so busy putting out fires that you don’t have time to improve fire-fighting or fire-safety”

Do you ever get a Big Idea?  You’ll be talking or reading about ITSM and the proverbial light bulb comes on.  You see a connection or an underpinning concept that you hadn’t seen before.  Sometimes it appears to be an original insight, one you haven’t heard expressed exactly that way before.  And very occasionally it really is novel and it really is right: you subject it to the scrutiny of others and it stands up.

It happens to me.  Because I’m privileged to spend so much time interacting with some of the best minds in ITSM worldwide – and thinking and writing about what I learned in those discussions, and applying that knowledge as a consultant – it happens to me quite often, about once a year. In fact I will be presenting on some of these big ideas at the upcoming Pink Elephant IT Service Management Conference and Exhibition (PINK14).

Standard+Case

A couple of years ago my Big idea was Standard+Case, a topic which I will be running a half-day workshop on at PINK14.

Standard+Case is a synthesis of our conventional “Standard” process-centric approach to responding, with Case management, a discipline well-known in industry sectors such as health, social work, law and policing.

The combination of Standard and Case concepts gives a complete description of ticket handling, for any sort of activity from Incidents to Changes.

  • Standard tickets are predefined because they deal with a known situation. They use a standard process to deal with that situation. They can be modelled by BPM, controlled by workflow, and improved by the likes of Lean IT and ITIL.

  • Case tickets present an unknown or unfamiliar situation. They rely on the knowledge, skills and professionalism of the person dealing with them. They are best dealt with by experts, being knowledge-driven and empowering the operator to decide on suitable approaches, tools, procedures and process fragments.

ITIL and Lean do fit this S+C paradigm, if you use them in the right situation: Standard responses. S+C extends them with better tools for non-Standard cases: Adaptive Case Management, Kanban, Knowledge Centered Support(KCS)… Better still, this S+C approach might let the ITIL and anti-ITIL camps live in peace and harmony at last.

Slow IT

Last year it was Slow IT.  Slow IT is a provocative name.  It doesn’t mean IT on a go-slow.    It means slowing down the pace of business demands on IT so as to focus better on what matters, and to reduce the risk to what already exists.  Think Slow Food, and more recently Slow Business and mindfulness etc.

The intent of Slow IT is to allow IT to deliver important results more quickly.  It does this by concentrating on the interfaces between business executives and CIOs.  Slow IT highlights the importance of Governance of IT and of Service Portfolio in order to make the right decisions to do the right things in the right way at the right time, to maximise benefit and minimise risk.

Right now the pace of change in IT is approaching human limits.  Many IT shops are overwhelmed by change, drowning in projects.  More are overheating: working at lunatic pace because the IT community convinces us we have to.  Slow IT challenges the hysterias and fads of IT to ensure that these results are really needed as quickly as we think they are.  Slow IT is about trying to introduce more measured responses, to bring some sanity to the current dangerous madness that is organisational IT (you can read more on this here).

I’ll be presenting on Slow IT at PINK14.  In addition we’ll talk about my Meet-In-The-Middle strategy to address the Slow IT issues by offering a quid pro quo: Fast IT.   If the organisation will slow down the demands on IT, IT will have the breathing space to implement approaches to respond faster, such as Lean, Agile, DevOps, and good old CSI.  Right now too many IT teams are so flat out serving the business they don’t have the bandwidth to introduce better methods properly.  It’s the old catch-22 of being so busy putting out fires that you can’t improve fire-fighting or fire-safety.  Slow IT takes off a bit of pressure, giving the team some headroom, to make improvements.

I hope to see you at the Pink Elephant ITSM conference.  I’m honoured to be assembling some of those great ITSM minds at the Pink Think Tank, to address one of the biggest issues facing IT today: how to manage a multi-sourced IT value chain.  We’ll be looking to produce tangible actionable advice, so look out for the results.  I have a feeling it may be the catalyst for my next Big Idea.

What do YOU think the next “big idea” will be?


Find me at PINK14:

Customer Experience the Apple Way

geniusYou’ve probably noticed that Customer Service has become an old fashioned term.  Nowadays it’s all about the “Customer Experience” led in no small part by Apple and it’s crew of blue shirted genii poised to help with all of your purchasing and technical needs.

According to Carmine Gallo, author of The Apple Experience, there are ‘5 Steps of Service’ that every Apple Store staff member needs to work through and these should either lead to a sale, or more importantly to Apple, to build a customer for life:

A = Approach Customers with a personalized, warm welcome       

P = Probe politely to understand the customer’s needs

P = Present a solution for the customer to take home today 

L = Listen for and resolve any issues or concerns

E = End with a fond farewell and an invitation to return

He continues by saying that ‘Apple employees are not in the business of selling computers, they are in the business of enriching lives’.

Recently I’ve noticed there have been more organizations eschewing the traditional customer service model and adopting the ‘Experience’ paradigm.  Walnut Hill Medical Centre in Dallas, Texas is creating its own steps of service complete with its very own acronym (W-E-C-A-R-E = Warm welcome, Empathize, Communicate and connect, Address concerns, Resolve and reassure, End with a fond farewell) to improve relations between patients and staff, and AT&T have been using a form of Apple’s system for a number of years.

Although its early days with Walnut Hill, AT&T clearly don’t have all the answers yet as last year they were ranked last for the third year running for value, voice quality and customer support by Consumer Reports and in November 2013 Lifehacker named AT&T as the US’ least favourite cellphone carrier following a vote by readers.

How is this different to how other companies do customer service?

In mid 2013 Craig Johnson head of Customer Growth Partners suggested that ‘Apple needs to recreate and reinvent its once novel retail model, which is now not so novel,’ (source: Daily Mail).

Perhaps this is true in the US, but back here in the UK I have seen little to suggest this in my day-to-day life.  To me, for the most part, Customer Service is still the same stale old formula it’s been for years.  Things that I would expect to be a bare minimum such as smiling, politeness and a willingness to help are still missing more often than not, so to me that approach is still very novel.

I mean how many stores can you think of where you can go in and play with the merchandise?  All Mac’s, iPads and iPhones are preloaded with apps and connected to the Internet to encourage you to try them out.  This is in stark contrast to most other stores where if you move a product more than the allotted 5cm’s an alarm goes off and you get rugby tackled to the floor by security personnel.

Is it possible though to create the kind of Customer Experience that Apple strives to offer for companies that are selling more than just a few different types of products?

It’s much easier for an Apple Genius to be clued up on everything they sell when there’s, at most, a fifth of the products on offer that there are in say Curry’s PC World.  Plus when you take into consideration the massive markup on an Apple product they can afford to not only have people trained to an expert level in a chosen area but also to hire more of them.

My experience at the Apple store

Recently I had my first ever visit to an Apple store.  This might seem odd to some of you, especially the ones who are aware of my attraction to pretty shiny things, but my family hails from Yorkshire and the miser in me always won.

I’d like to start with the good in my Apple experience but frankly there wasn’t a lot of it.  I waited a good 25 minutes loitering but not entirely sure what to do or where to go. There was no ‘Help’ point and each Apple employee was surrounded by many other slightly peeved potential ‘customers for life’ circling like shoals of piranha’s.

When I did manage to flag down a blue shirt the advice I received was practically non-existent.  Rather than probing me to understand my needs it was more a case of me prompting as to what was required.

I’m led to believe by my subsequent conversations with store managers at Apple that at this point I should have been asked what kind of work I would be doing and what I would be using the product for in order for appropriate advice to be given.

However, once I had decided on my purchase things started to look up considerably.  My shiny new MacBook Air appeared within a matter of minutes and aforementioned blue shirt then produced a handheld gizmo, which appeared to be an iPhone strapped to a card reader to take payment.  This I liked…no ‘I’ve left it behind the counter madam now if you’d like to queue for another 20 minutes someone will eventually relieve you of a shed load of money and try and persuade you to buy a bag for life and two chocolate bars for a pound’.

However it wasn’t enough to save the experience and when emailing the receipt for my purchase later that evening to the boss the message had one line…

Genius my arse!’ (For those non-UK readers out there who may not have come across this before it is an exclamation of disbelief).

The Apple way was ground breaking but where is customer service/experience heading next?

It’s reported that following the departure of Ron Johnson (Head of Retail), Apple has taken a wrong turn advising its store sales advisors to forget about Customer Experience and concentrate on the business of selling.

Never mind a wrong turn this is one gigantic step backwards.

Concentrating on what is seen as the primary need of the customer has always been short sighted.

With the addition of Angela Ahrendts (credited with the turnaround of 150 year old brand Burberry) to the top team, Apple has shown its commitment to not selling technology to the masses but to being a company that can support lifestyles by providing experiences rather than just products.

There are the obvious contenders such as Zappos and Google, but recently Samsung has invested heavily following reports of “the worst customer service ever” from consumers.  Steps to improve its reputation have included launching a worldwide customer service campaign and offering a free app that provides online support that you can take anywhere.

Hotels tend to get a bad press but Hilton makes strides by outlining exactly how they’ll take care of you. For example Doubletree, a franchise owned by Hilton Worldwide where you get free yummy cookie on arrival, maintains a CARE committee within each of its hotels that includes workers from every department and exists to monitor hotel performance and ensure that guests are satisfied. With four out of every five guests reporting an “excellent” or “good” interaction this seems to be working.

And lets not forget that Apple’s ‘5 Steps…’ model was actually inspired by the ‘steps-of-service’ pioneered by the Ritz-Carlton hotel chain.

Conclusion

Creating a model or philosophy for Customer Service/Customer Experience is fantastic.  It makes sure that everyone knows what the company is trying to achieve and where they stand.

In my experience they certainly didn’t deliver what was promised in their ‘5 steps…’ but they are clearly aware of this and are taking strides back towards where they want to be.

If you are attempting to put in place your own model don’t just assume that because something works for someone else it will work for you too.  Organizational culture, company history, who your customer is and even location can play a massive part in what make you tick and these all need to be taken into account.

In reality plain old Customer Service is of a bygone age and so much more than what consumers and customers expect, even if that’s not what they get 70% of the time.  A caller on the end of the phone will remember how you treated them far longer than whether or not you resolved the issue for them.

Every company should have something in place to show that they understand what is required of them by their customers be that in a mission statement, agreed statement of values or a formal written agreement.  We’ve all been in situations where everyone’s working to what they believe is a level of good customer experience yet side by side they all vary drastically.  Don’t leave it up to interpretation.

On that same trip to the Apple store I had the usual request from my six year old to visit the Build-A-Bear Workshop.  I’ve lost count of the number of times we’ve visited and the small one has wandered around in awe. We rarely buy anything as you can get teddies much cheaper from other stores and like most parents an avalanche of toys threatens me if we add anything else.

However, it’s the experience of creating something exactly as she wants it, being able to ask any question she wants about her teddy’s back story without feeling dumb and playing teddy Star Wars with the eccentric sales assistant that means that more often than not we return.

So maybe they won’t have a customer for life but I suspect it will definitely be until the end of her childhood.

Secrets of Request Fulfilment

 

Peter Hubbard
Peter Hubbard

This article has been contributed by Peter Hubbard, Principal IT Service Management Consultant at Pink Elephant EMEA and is based on a recent presentation that he delivered at the itSMF UK Conference and Exhibition.

Request Fulfilment is one of the most useful, yet underrated, areas within IT Service Management. It has been widely recognized for many years that the ‘Front Face’ of IT is the service desk, and so how the service desk performs colours the whole perception the business has of the entire IT Department.

But what is Request Fulfilment? Request Fulfilment provides a channel for users to request and receive standard services for which a predefined approval and qualification process exists. It simple ensures that each request doesn’t have to ‘reinvent the wheel’.  A request model is a way of predefining the steps that should be taken to handle a process.

So how do you implement it?

Getting the basics right

The first thing that you need to do is create a Service Request Catalog. At its most basic level this is simply a list of all the Service Requests it’s possible for the business to make of an IT department.

The easiest way to do this is to ask your service desk staff, after all they spend all day dealing with these very issues. Ask them to write a list of their most frequent service requests, and use this as your starting point to turn an entry in the Service Request Catalogue into a fully mapped and automated Request Model.

The second major thing to do is to make sure that you separate your incidents from your requests in the toolset. After all, they are separate things! Telling a business that 10,000 incidents were received to the service desk sounds like the world is ending. Saying that 1,000 incidents were received, and 9,000 service requests were made for new kit is a very different story.

Build a request model

You MUST do this. Request Fulfilment without Request Models is just mucking about. The whole point of Request Fulfilment is to work out in advance the steps that are required, the information that you need to collect and when, and who performs the required actions & authorizations. This is the soul and centre of Request Fulfilment. Collecting all that information and not transforming it into a model, either as an established manual procedure, or ideally, within an ITSM toolset is just plain silly!

In order to build a request model the simplest method is to bring the people who are involved in fulfilling that request together.

Ask them to verbally walk through the activities involved using post it notes to build a basic flow on the wall. Once the steps have been agreed, and are in the right order, go back and detail what happens at each step: who does it, what information they would need to fulfill that step, any agreed timescales or authorizations required etc. I find this takes about half a day for a moderately complex request like building a new starters laptop and delivering it to them. Once you have the model capture it in a formal document (Visio flowchart with explanations is best) and then use this to configure your chosen ITSM toolset to automate the request.

Request Fulfilment is simple, but that’s not the same as easy?

Many people are often make the mistake in being under the impression that ‘doing’ Request Fulfillment doesn’t take more than a week or two, but let’s say you haves 800+ known types of service request. The rule of thumb is to allow half a day to map a request model as you work out all the steps involved and who does them. Then allow another half a day to document that flow into a format that can be saved, understood, and shown to others. Then add another half a day to put that flow into the toolset. So that 2 weeks worth of work was actually 1200 days work!

My best advice to keep things simple is to start with an easily understood, and not too complex request. Avoid starting with the ‘new starter’ request as a typical new starter request will involved multiple actions crossing HR, Security, Access Mgt, Facilities and IT. I am not saying don’t do it at all, just make sure you start with something simpler to get the feel for the process first.

The most spectacular mistake I have ever seen made with regards to Request Fulfilment was when I saw a CIO promise to his executive board that 95% of all service requests would be completed within 5 days.

It’s safe to say that I almost fell off my chair. I very quietly sidled up to him afterwards and said that it was very courageous promise he had just made…would he mind if I asked a few questions?

Question: Have you defined what a Service Request is as opposed to an Incident?

Answer: No, is that important?

Question: Have you worked out a complete list of all the types of request that you support?

Answer: Not as such 

Question: What is the most common type of request you receive at the Service Desk?

Answer: A request to build a new laptop

Question: Have you worked out the steps involved in fulfilling that request and the timescales involved?

Answer: No, but I know it can’t take long to simply build a laptop!

I went off and built the request model for that request. It turned out that the process to build a laptop took 37 separate steps, across 4 teams, and went to 2 external organizations who had their own response times in their contracts. If everything worked as it was supposed to then it would take 10 days to complete the cycle. Essentially the CIO had just set himself up to fail and the board hammered him for the next 6 months every time they had a meeting.

The moral of the story? Know the steps, and timescales involved before you start committing to SLA targets!

Benefits to Request Fulfilment

I always tell people ‘never keep a dog and bark yourself!’  Most ITSM toolsets are built around perfectly good workflow engines with associated notification rules. Well… guess what…that’s how Request Fulfilment works too.  You work out ONCE what a particular request needs to do, who it should go to, what they should do and so on. Then you take that hard won information and enter it into the toolset as a Request Model. From that point on the tool does the hard work for you. It moves the requests to the right team(s) automatically. It makes sure they have all the information they need on a silver platter, and it even escalates the issue to the relevant authorities if pre defined criteria are breeched.

Someone has to do all of the things I have just listed, and unless you have the tool doing it (supported by your processes of course) then your service desk agents have to do it by hand, which means you’ll soon have your agents tied up manually shepherding requests and explaining to irate users why their laptop is not ready yet. By using Request Fulfilment most of this is done for you by the tool through the Request model; although you should always make sure the final ownership of the requests sits with the service desk as normal.  Trust…but verify!

A final note

Tackle Service Request Fulfilment head on. Handling Service Requests manually is major drain on your resources on the service desk at the moment and the single largest cause of user dissatisfaction.

Do comments such as ‘we never get told what’s going on with our requests?’ or “why does it take so long to get anything done by IT?” sound familiar?

Well, you can either deal with each issue as it arises on a one by one basis, or you can invest some start-up time into identifying the top 10 requests that get made to your service desk, and create them as request models. Then put them in your toolset and automate the notification and assignment rules.

Request fulfilment frees up your service desk, and technicians time from endlessly chasing their tails as they try to find out what the next step in the chain is and who they should be talking to. By automating the basics you free your staff up to concentrate on other areas of greater interest.