Build a service structure based on business outcomes

From practical experience, the simplest and most effective way to progress this service-centric approach is to produce 2 initial documents:

1 A Service Structure – a simple 1 page graphic view of the key services, organised into a hierarchy. This can then be used in all subsequent documents as the initial header and summary of services. Usually it makes sens to break these into 2/3 groups – e.g. like core IT (commodity consumption) services, business services (what the organisation does) and Consultancy/Project Management/Change

2 A Service Database – Once the structure is defined, we can build a collection of as much relevant information and useful data about these services.

These deliver the following:

(1) The Structure is a single and simple view of services that everyone can understand, visualise and relate to as the framework of services. This makes it much easier to discuss and amend and develop the outputs, SLAs, reports etc that need to be produced – everyone is also referring to the same agreed structure.

(2) The database then provides a repository for information about these services, that can then be used to provide the content for different outputs. This could include a ‘brochure’, a technical view, a business view, service reporting, user portal etc.

The database itself doesn’t or shouldln’t be viewed by more than a couple of central project people – but it is the control document and ‘single source of truth data source for other documents that are produced as required and in appropriate formats.(from experience it’s just not possible to provide a document that works and is suitable for all stakeholders).

It’s worth having some thoughts and writing down your ideas for the structure, once you’ve had some initial customer meetings. However the best way to move this forward with support is to run a workshop. This can build great momentum, commitment and shared understanding quickly and effectively.Workshop Key Points:

• Get key stakeholders together
• Start with some basic explanation/eduction around what you are trying to do
• Clarify the taxonomy of SLM – this is vital to avoid misunderstanding and delay later in the project
• Discuss the current service issues and how a business focus on service operations would work and improve quality
• Brainstorm current services and build the structure – usually this involves getting all the services out on a flip chart then deciding as a group whether these are ‘services’ or simply system components
• Usually its good to invite a couple of customers along later in the day to see what they think of the work you’ve done – this also helps to get direct feedback and let the IT guys know this is for real….

Ideally you will come up with something that looks like this… (but your version of course..!)

This can then be developed and used as the main image to front all your service documents – and it should be an agreed structure that is understood and ‘owned’ by all parties. What you can then do is to populate a spreadsheet or simple database with information and attributes for these services, as a basis for your other outputs.

This may take some time to compile – particularly as you will need to get information from a number of sources – but that’s OK, the main point is to have an initial agreed framework that you can use and also socialise with a cross section of business and IT people.

1. A brochure catalog is useful to help (e.g. the CIO) to ‘sell’ the bigger picture of the service structure and associated priorities – particularly if investment in tools is needed.
2. Once the structure is agreed, you will find that a number of groups start taking an interest in using it as a source for documentation (e.g. technical information/summary support information, knowledge)
3. Don’t be pushed too quickly into setting up a ‘user request portal’ – until you are happy with the structure and have a full understanding of the processes involved and what the customers experience and requirements are.
4. You can revisit and iterate Step 1 and Step 2 until you are happy that your service structure and customer requirements are clear and appropriate. Time spent on getting this working is time saved later on – and it can be changed. too many organisations dive straight into SLAs, incident and request management here without getting a rounded view of what is actually needed.
5. Once you have your structure of services in place and in motion you can then look at how to deliver this with a sourcing model, processes, tools and resources.

• • Barclay Rae BRIGHTTALK Presentation Dec 2012
  • BRighttalk webinar – Strictly Service Catatlog
  • Sample Basic Service database
  • Sample SC Business + forms
  • Sanitised XX Service_Catalogue_Template
  • Service Catalogue A4
  • SLA Customer Document 2
  • Why Bother with a Service Catalogue-2011

• Service Catalog isn’t just the customer menu, its also the blueprint for what IT does and how it performs
• If you don’t have a clear definition of what you do in IT, how can you know if you’re doing a good job?
• Service Catalog is not a single entity – its a number of views and presentations of the service structure and data
• Tuns out you can’t actually set up SLAs without defining services first. No, really…!!
• Don’t be sidetracked from setting aspirational SLA targets because of 1 or 2 occasions where it will fail – that;s the point!
• SLAs breathe business life and relevance into fairly dull IT operational processes
• Don’t write an SLA if you are a frustrated lawyer, a novelist or a tech junkie…
• SLAs should be about positive value delivered by IT services, not just how IT responds to failure.
• Your service reporting is a bundle of stuff you already report on, like availablity, customer satisfaction and support performance
• SLAs need to show up gaps in capability and performance. Keep goals real and not just easy targets – otherwise how can you improve?