Wednesday, 24 April 2013

Keep the Customers Coming Back – Service Delivery



Whether you like to call them users, clients, or customers the fact of the matter is that you are providing a service to a business unit(s) which in effect is paying you for said service(s) either directly through some form of billing, or as part of an organization via a budget.


To put this in a bit of perspective let’s think about a person (who we all know) which has been going to the automotive dealership to get all the regular maintenance work done on their vehicle because they believe that it is required as part of the warranty agreement. (If this in fact a requirement or not it has never been looked at by this person) After every visit the complaints are endless; the service was too slow, it wasn’t what I wanted, the prices are ridiculous, the complaints go on and on....
Now suppose that we were in a position to look around for a competitive advantage that would satisfy these issues at the same or lower costs, who would not consider that?

IT is really no different than the dealership in this example on many levels. The business, while part of the same organization, may at some point decide that a cloud based service (PaaS, SaaS or IaaS) may be the way to get the delivery that they are looking for with fewer challenges as they see it on their end. Viewing this from another angle the business pays our salaries and effectively ARE the customer, despite what we call them. If they continue to find alternates for their needs there dependency on IT resources could diminish over the long term
How can we ensure that we can be strategic partners with the business? Start with the following:
Need a strategy for aligning with their organizations goals
·         Find out what the business goals are. This is likely whatever impacts the bottom line, driving up profitability and reducing costs

Standardizations which are repeatable either through the right team or through automation through the right systems
·         Determine where you are currently to allow you to choose a few base Key Performance Indicators (KPI’s). Being able to measure and managed activities through KPI’s will allow you to improve on any improvements you make. Keeping these simple in the beginning will allow you to get the ball rolling to achieve goals

A service oriented culture
·         Simply listening and collaborating with the business to see if we are satisfying them. Sometimes the “numbers” may suggest that we are doing one thing and a discussion will reveal another outcome altogether

Sustain the improvements you make
·         Keeping things as simple as possible is definitely a way to work. Try to adopt best practices which can be applied to all business units. This way the business outcomes are the same. Remember that we are leveraging People, Process, Product and Partners to do this

Ensure we review the current state to continually enhance service
·         Just because we have made an improvement, even a significant one, does not mean that there always going to be ways to improve the customer experience

Once all of these are in place it will be key to conduct reviews with all the stakeholders in the Service Delivery process to ensure we stay on target

 

Follow us on Twitter @ryanrogilvie

Thursday, 18 April 2013

ITSM Overview Video


This is a 90 second ITSM Overview Video which outlines:

·         Priorities
·         Value on Delivery
·         Costs
·         Returns on Investment

It is a fairly high level overview, which is a good introduction for those that may not be as familiar with ITSM. I also couldn’t resist sampling Curtis Mayfield’s “Pusherman”




 
Enjoy,

Follow us on Twitter @ryanrogilvie

Thursday, 11 April 2013

Reporting – It’s all about the Numbers

So why are we doing this? There will always be an aspect of reporting that will show interested parties what the status quo of your environments and service is. There should also an understanding that someone reviews the information, digests it and leverages it to either directly make improvements to customer service, processes or infrastructure or does this collectively within IT as a whole.
Sadly, I can’t think of how many times I have submitted some metrics to be reviewed by a group and someone almost always says “looks great… but could we make this bar blue instead of red?” while the aesthetics may be important to some the content is what we really want to ensure is hitting the mark.  
In the beginning there needs to be a simple and clear understanding of what we want to measure and why, a few objectives. We also need to ensure that we have a vehicle to take those outputs to make improvements in some capacity. Like many of you out there who regularly provide statistics to your organization either directly or indirectly (if they are able to access a dashboard of some type on their own). You need to keep this confined to a couple of Critical Success Factors (CSF) with a few KPI’s for each. Once we get a handle on these initial ones we can add others.
Leveraging the CSF’s to make a real difference in service can be made easier if you know what you want to achieve as a result.
Types of CSF to review may include:
·         How efficient a particular process is
·         How well your infrastructure is performing though availability etc.
·         Improving the quality of service – does it perform the way it should
·         Reducing costs for the IT department

While the uses for the results of your metrics may vary they should all be ultimately leveraged to make decisions within your IT organization for service improvements in some capacity. Some of these may include:
·         Using the metrics for trend analysis
·         Productivity reporting
·         The need for (or not) of resources – human or otherwise
·         Making comparisons from date “X” to the same time last month, year etc.

Now that we know what we want to measure and why, we should determine the way in which we gather data. Depending on the ITSM solution you have (or don’t) you should really ensure that the data you capture can be reproduced in the same manner each and every time. For example if one person pulls all incident information from “last month” and the next does the “last 31 days” they may have slightly conflicting information. When you go to provide the data to your stakeholders, any discrepancy, even a small one will allow the reviewer to question the validity of the information you are providing. In some cases your audience may discredit the information entirely making it a challenge to provide and leverage these stats in a meaningful way.
There is always going to be a different level of interpretation depending on who is reviewing the data you provide. The business stakeholder may have a different take on the information provided compared with your IT Operations Manager. The important thing to keep in mind is to use this as a dialogue point between the two groups and close any gaps so that the service you provide can be the forefront of all discussions going forward.  


Follow us on Twitter @ryanrogilvie

Friday, 5 April 2013

Incidents Caused by Changes, Nessie and the Yeti

I recently overheard someone say that they were having application issues, was there a change? At an initial look it didn’t appear so. Much like the Yeti, and my favorite Nessie, having actual proof of the existence of the change relationship there are those which believe they exist. There is a statistic that says that 80% of Incidents are the result of a Change. The real question here is how you quantify the number of changes which actually cause the incidents and how can you better position yourself to be able to do so.

In some cases identifying that a Change has inadvertently caused an issue is easy (and obvious – network change and network outage). While other times the relationship is not quite as clear, network change and application issues. Some factors which can complicate matters include:

·         the time elapsed since the change completed and the incident is reported,
·         the description is not reflective of the symptoms which are being displayed
·         there were change activities which may not have been tracked in the known change or
·         the change was not tracked at all.

Leaving the latter aside let’s take this example into consideration:
Assuming we have a Problem, Change and Incident management process owner we should start by getting them together to review activities at regular intervals. Each of the process owners bring the following information to the table

Change Management
There was 200 Changes last month. The success rate was 99 percent
This meant there were 2 Changes which were reported to have caused Incidents
There are 10 Incidents related in total to these Changes


Incident Management
There were 100 incidents reported last month of varying severities

Problem management
What are they working on or has been escalated to them.

So if we are working on the premise that 80% of incidents are the result of a change we should have had 80 incidents
related to changes rather than 10. Obviously this metric is isn’t an exact science, however what it represents is important.

Can we really quantify the relationships between Incidents, Problems and Changes? We now need to ask ourselves were there more incidents as a result of a Change that were not identified? Also how many of these incidents were common to one particular issue or required a Problem Management review. The more you discuss these activities amongst yourselves the more you will realize what other moving parts which can contribute to streamlining improved service.

These types of reviews at the very least within your ITSM teams should be going on right now, and if they are not it is time to take a closer look at what you are doing, review your KPI’s and work towards improving the customer experience.

Follow us on Twitter @ryanrogilvie

Monday, 1 April 2013

Business Service Management - The Next Step

In our journey to improve Service Delivery, when do we focus our energy to a Business Service Management (BSM) role within our organization? For some companies there may already be a role, while others perform these activities in a less formalized way or don't perform them at all.

To get to this point we need to ensure that IT is a business partner and are aligned with the business in a way that allows for a collaborative partnership. Remember that IT is providing services, so in that spirit we should have a good understanding of what the business does and why particular functions within the services are important. There may also be agreements already made with the business with respect to operational or service requirements. If there are not, some will need to be drafted in order to identify a matrix of what services are supported, and when so we are on the same page for levels of support

Once IT is able to identify areas that are critical to the business from a service perspective we should be in a position to be able to make corrections before the business even notifies us that an issue exists, minimizing any potential impact. This can be accomplished through mapping of the service to show its components and relationships. A fundamental understanding of what makes the service “tick” enables us to best ensure a stable environment. Some of this mapping functionality can be handled through certain Service Management tools, while other functions such as monitoring of infrastructure may be handled through other tools altogether.
One of the benefits of having the service mapped to its components allows still other ITSM functions to ensure that they do not inadvertently impact service. A fairly accepted statistic is that a large majority of issues experienced by users is the result of a failed change. If the Change Management team would be able to graphically see all the pieces that might impact service “X” which positions them to make better decisions to perform changes in a way which until now may have had some adverse impact on the service.
In order to keep on target there needs to be repeatable processes in place. Since there are likely going to be many participants we need to ensure that the process is repeatable by all parties. Having this process in place and adhered to allows for a more consistent customer experience. Once the process has been optimized we can look to automate these to be more cost effective and streamline activities for both IT and Business stakeholders.

This is not where BSM ends however; the key to this is that the IT and Business engagement continues so that the silos between them are non-existent


Follow us on Twitter @ryanrogilvie