Service structure?

In simple terms, this is about defining, agreeing, and compiling service information into a usable format that you can use to build your service model and drive your reporting. So you can be assured that you are delivering the right things and also providing useful value-based information about performance. In traditional ITSM terms, this is about building a service catalogue and service model, although from the ‘ITSM Goodness’ point of view we don’t need to get too bogged down in this terminology.

What we have tended to do in IT is to try and build SLAs (Service Level Agreements) before we have defined our services – this leaves us limited and tied to fault-fixing and internal operational measures when we could be looking at a wider and more positive definition of service.

It also means that we can’t really see the bigger picture about services and the service experience, so we end up producing dull and functional IT statistics about our (IT) performance – that is of no interest or value to anyone outside of IT support, never mind our customers.

What we need to do (following Step 1 – engage and listen to our customers) is to discuss our understanding of the customer and business perspective of what we do and organise this knowledge and information into a ‘structure of services’. These services should reflect focus and objectives on the business outcomes required – so if you work for a breakfast cereal maker, then the IT services should reflect aspects of producing boxes of corn flakes or Rice Krispies, or whatever… i.e. NOT how many incidents the IT organisation has had or what the blanket service availability is.

So what do we need?

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 sense 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, a user portal, etc.

The database itself doesn’t or shouldn’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).

How can we achieve this – quickly?

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/education 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, it’s 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.

Key Points

1. A brochure catalogue 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.

ITSM Goodness Tips

• Service Catalog isn’t just the customer menu, it’s 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
• Turns 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 availability, 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?