The ability to support your customer’s
business outcomes will inevitably come back to a discussion on the services
they consume and the way they are provided and supported by IT. Pause for a moment
and think about what that means from a business perspective, rather than an IT
one.
The business expects a certain consistency of
#service. They don’t know, or frankly care how you make things work, only that they are up and running. Your challenge is to ensure that we have all the pieces in place to
provide that service expectation. Whether you have formal processes to ensure
this is happening or not you need to ensure that you cover off a few things to
get the ball rolling
What is the service?
Ask 10 people and you
could likely get 10 slightly different answers. This activity can be
complicated, so having some strategy regarding your scope for this undertaking
is important.
The requirements for a service should
underpin a business outcome. In fact in the actual service record (however you
track it) there should be a field that clearly indicates what that is.
Now that we have identified what a service
is, by definition. We need to know what OUR services are. Using the scope we
have outlined earlier should guide us to decide the level of granularity that
we use for consideration. Remember it’s not about IT, it’s about the customer
Example
Since
all customers are not the same for example purposes I will generalize a little
here. As we are starting out, we need to keep our scope simple and because our
customer base is also small we may “know” what applications that they leverage
across the enterprise each day. As a result we may want to use well known
applications as our services. The cautionary tale here is to not assume too
much – remember it’s about the business outcomes, so discussing this with the
business is imperative. We can always adjust these services later – watch for
scope creep
In
keeping with the title of this post let’s assume that the key application our
customers need is called “B.O.R.K” or Business Operations with Registered
Knowledge. This application is used Monday to Friday from 8am to 6pm and is
only used in the city for the corporate office. There are 50 people at any
given time who need to leverage the tool and we have identified the backend
systems which make it tick. This supports our business to be able to track all
of their customer’s payments. This in turn impacts our businesses bottom line
for billing, or MAKING MONEY.
We have verified the details of the service
record with the business, remember they may not care that we have a SQL
database, an app server and a web server in the background. But they do care
that the tool works. All of your IT functions should understand on some level
what the service means to the customer and that we are positioned to support it
accordingly
Establishing a notion of service culture
across your IT organization rather than an “us vs. them” will go a long way to
assist in the support of the established services
These records will in turn drive the way that
you manage incidents, implement changes and fulfill requests in some way or
another. It allows your IT teams to be able to more appropriately prioritize
your customers work
Now that you have this information put
together we need to maintain the accuracy of the service record. Who owns that
component? Again there are no easy answers here and no right or wrong
with the exception that someone or something (process) must ensure that we keep
on top of the accuracy of the information we so painstakingly collected. We
also need a way to ensure that we review with the business the service we have
on record. Whatever B.O.R.K might be used for today may have different business
requirements in 6 months and the way we deliver and support the application
should be scalable as well. You could even tie in these reviews with your annual Operation
budget activities. This could come in handy in the event you need to allocate resourcing to the services
which you are providing.
Overall you need to start small and think a
bit ahead of where your service roadmap will need to go.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
If you like these articles please take a few minutes to share on social media or comment
Labels: ITIL, ITSM, Service Delivery, Service Management