What are IT services?
Let's concentrate on an example first of all and the desired outcome. I log onto a computer and then into a website that allows me enter and submit times for my timesheet. I enter my times and hit the submit button and bingo, I'm done. The outcome - my timesheet is submitted to my line manager, once approved it's off to the payroll system.
So what was the actual service here? Was it the timesheet booking service, was it the employee administration service or was it the web service?
The service in ITIL terms is end to end, from user interface to final outcome, so that is the software and infrastructure required in order to deliver the outcome. From your PC which is your (user) interface, the web browser, the network, the server which hosts the application, the application database which needs to be queried and so on.
Any failure or degradation of one or more of these end-to-end components may lead to a loss of ability to run the task and produce the required outcome.
If you happen to have a fully populated CMDB these end-to-end relationships should be easy to understand. But for a company who is just considering becoming more service orientated a CMDB of this nature is unlikely. Indeed even in those that are already service orientated a fully populated CMDB is still a rare, if not moon on a stick requirement.
Define your services
So why bother with this service definition? Well let’s say the administration system has several functions: timesheet booking, HR reference system, flexible benefits and appraisals. If we concentrate on these functions we may say that the timesheet system is the most critical with the others less so. Or we could just say the whole administration service is critical, affording all the function the same level of criticality.
For argument’s sake we will call it the administration service and provide all the functions a critical rating. This is all fine until incidents for both the timesheet system and the flexible benefits system occur at the same time.
The service desk provides them both with the same priority and the operational teams respond. In reality we really want the timesheet function to be fixed first and quickly but now both are being worked on. This will either increase the time to fix or increase the amount of resources required to fix and the associated cost.
So now you decide to split your services and define the timesheet system separately, it would seem sensible. However the administration home page is required in order to link into the timesheet function, so now we have a dependency on the administration home page for the timesheet function.
Map your IT services
To understand this sometimes complex makeup of service dependencies and criticality you need to map your services. To enable this the organisation needs to understand what is important to them internally and their customers externally, which services generate revenue or have the ability to lose revenue if they are not running. Don’t get to indulged with tooling to carry this mapping out, I recommend a spreadsheet and don’t forget to include all your key stakeholders in this process.
Mapping of these services can sometimes include complexities such as third parties that deliver whole services or a part of a service. To confuse matters further there is now the cloud and the term ‘as a service’ - this essentially means you are being provided with a part of a service as a service. For instance let’s take platform as a service (PaaS), this simply provides you with the platform normally to operating system level on which you host your applications.
In terms of the end to end delivery the platform is a very important part of your service but by no means the whole service, all you have really done here is outsourced this portion of your service to the cloud provider.
A note of caution here - don’t decide on the cloud provider or a third party until you have finished mapping and aligning your services. You wouldn’t buy a car unless it met with your specific requirements.
Apply and align IT service levels
Once you have mapped your services and you understand the criticality and dependencies you can then decide on the required service level for each. The definition of these service levels will depend largely on how long your business can operate without the business outcomes these services deliver.
As with most business activities when it boils down to it we are concentrating on the bottom line. Why should we pay for masses of resources to fix things immediately if we can do without them for a day? And on the other hand why have low resources on things that we need fixed in an hour?
Refine your IT solution
Once you understand your services you can then concentrate on your resource model and the technology required in order to align your IT to your business and ultimately improve your long- to medium-term profitability. Understanding that in the short term you may need to make some changes that could lead to some initial expenditure.
Conclusion
These days most companies rely heavily on IT, in fact for most its core and therefore in order to ensure your organisation is running in an aligned 'fit for purpose' fashion you need to understand what services IT is delivering. Only once you understand this picture can you begin to refine your technology and resources to support the business in efficient, effective manner. Until such a time you could be running a Mini with a V12 or a Ferrari with a 1.4, I’m not sure your customers will be happy with either.
