Delivering on IT services
ATFQ and other truisms
How easy it is to say that ‘IT should start with the business’? It’s one of those statements, like ‘customer is king’ or ‘always wash up as you go along’, that may indeed save time in the long run but which can be a lot harder in practice than theorists would like.
Like many truisms, this doesn’t make it any less important. But when faced with the hustle and bustle of keeping IT systems up and running day to day, it can be difficult to keep in mind that IT is a means to an end. Business users don’t necessarily make things easier – while tough to please, they can also find it hard to say what they want. I paraphrase but I can recall being told on more than occasion, “Requirements? Isn’t that your job to work them out?”
To be fair, medium sized organisations do have less of a challenge in trying to understand business needs than enterprise companies, simply because the former are less complex than the latter. This doesn’t always mean IT and the business are in for an easy ride.
I can remember one of my formative first jobs as an IT consultant, when I was brought in to help write a Service Level Agreement (SLA) for a public body. What I didn’t know before I arrived, was that the designated IT department representatives weren’t actually talking to their business counterparts anymore, in the IT-business equivalent of a marital breakdown. I wish I could say I saved the day, but sadly all I did manage to coax out of the situation were a few response time targets.
Even in the best of cases, SLA’s are only one element of service delivery. We all know whether or not we are getting what we would perceive as ‘good service’, be it in a restaurant, a shop or indeed from IT. The challenge (as I’m sure anyone who has worked in hospitality or retail would profess) is knowing what to put in place to support the delivery of services, whatever their shape or form.
In IT terms this boils down to the infrastructure itself, and how it is managed and operated. In a previous article [link] we considered the architectural aspects of IT and how to deploy an infrastructure platform that supports the service requirements. What we haven’t yet talked about is how to decide what services are necessary, and how to ensure they are maintained.
While all organisations are different, business activities tend to fall into one of two categories. The first is activities that are, or can benefit from being treated in a structured manner; and the second is those that cannot.
Considering more structured activities first, these have been called various names at various points over the past few decades – including workflows, business processes and so on. Methodologies abound to identify and restructure such activities, with the goal of making things more efficient. And they also serve as the basis for understanding what can be automated – each task may or may not benefit from use of technology.
Forgive me if this is egg-sucking stuff, but in reality things don’t always work out that way. How many times have we seen applications that are used only in part, if at all, because they don’t actually fit with the way the business works? Of course, the business can (and sometimes should) change to fit with new capabilities provided by technology. But still, business activities should be in the driving seat.
For IT to support structured activities, it needs to operate efficiently – that is, as cheaply as possible. Interactions are largely transactional – that is, responding to specific service requests or updating specific information items. In the structured world, flexibility is a second priority to service levels – if IT is unavailable or inaccessible for whatever reason, the cost impact on the business can be very high
The second activity type – “everything that cannot be structured” – is no less important when it comes to deciding IT service requirements. We talk about collaboration tools, portals and information sharing facilities in this context, as well as mobile devices and other access capabilities.
For less structured activities, accessibility, flexibility and responsiveness are key drivers. There is no point at all for example, in having a world class customer management system if it isn’t able to cough up a phone number to the service engineer who is working on-site.
From a service management perspective as well, the type of management required depends largely on the type of service. Transaction workers in structured environments need similar structure when it comes to fault reporting and resolution, whereas more collaborative environments will probably build in several different ways of getting to an answer (“Can’t access the file? OK, I’ll email it to you.”)
At the heart of it all, however, lies a service mindset, which is difficult to teach. I can think fondly back to a number of colleagues who just knew that the quickest way to working out the answer was first to ask the right question. “Hang on,” said one, “Exactly what problem are we trying to solve here?” Even if we think we know what the business priorities are, it doesn’t take much to check in with someone who is well placed enough to say.
Assuming, of course, that the two sides are still talking. If not, it’s going to take more than an SLA to resolve that one.