At a recent ITSM event I was speaking with
another practitioner who said that they were looking to implement service level
management. The challenge was that as he was describing this activity he was
developing a crinkle in his forehead from the forlorn look on his face. I asked
him if they were in a good position to move forward on this and he said “our
CIO thinks so… he thinks we would be in a better position to provide service if
we had some service level agreements put in place”
The first question I would ask is whether you
had a service catalog in place. He indicated that they had something but
nothing that was managed or formal in a way that was usable. I went on to
explain that the purpose of ANY catalog, service or otherwise, was to outline
what services were provided. To do this you really need to know what the
business needs. The other thing is to start looking at this from the business
perspective as well. What ‘services’ is the business consuming.
This takes us back to the original statement
made by my colleagues CIO “if only we had some SLA’s”. keep in mind that the
first word in that acronym is service. So in reality we should have a really
good understanding of what the service is all about.
When looking at the definition of the service
and all that applies we should be able to keep it pretty simple. In fact all
the details of what the service are, including things like; what it does, when
it is used, by whom, when maintenance can (or cannot be done), are easy enough
to be understood by the business who consumes the service.
To do this you need to communicate with the business
It seems obvious enough, the trouble is that in
some cases IT makes assumptions that they know and understand the services that
they provide when in reality they are not as informed as they think. This
assumption is typically the piece that is the issue when implementing service
level management.
The key when looking at this is to look at how
we provide service in a basic way and communicating with those who are using
the services. Unfortunately IT overcomplicates things which are half the
trouble.
In the beginning get the content from the
business with their goals or outcomes in mind. Also get the information
captured and validated in their terms rather than the IT (technical) viewpoint.
Getting the business input might be a challenge if this hasn’t gone well before
the key is to market this in a way which outlines how the success will be
achieved and how their input and participation will directly contribute to that
success.
Once you get these requirements down make sure
that they are visible (not hidden away in a group share) and that they are in
the same terms which were discussed with the business. Resist the need to make
this a technical document.
When you get it built you need a way to keep
this current. Where it applies make sure that you integrate other service
management processes to input or take the outputs of service level management.
To help with keeping the process on track make sure that you have appropriate
reporting to outline areas where things may not be going well so you can
correct them. Also make sure to celebrate your successes where you find them.
This methodology applies to any service catalog initiative, not only IT.
Follow me on Twitter @ryanrogilvie or
connect with me on LinkedIn
Labels: ITIL, ITSM, Service Catalog, Service Level Agreements, Service Management