Baking Up IT Services - Swedish Chef Style

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


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: , , ,