Aren’t some processes really functions?!

Last time I wrote my blog on the ambiguity which is frankly still rife in ITIL. But if there is one thing ITIL is very clear about, than it is the definition of a PROCESS vs. that of a FUNCTION.

A Process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for a customer or stakeholder.

That’s the definition, and this is the core of best practice service management, whereby everybody accepts and uses the same process, performs the same activities. This is also how ITIL ‘justifies’ the introduction of procedures & documentation (see an earlier blog). After all, you can’t manage what you can’t measure, which is one of the characteristics of a process (due to all the logging, recording and tracking).

A Function is a team or group of people, and the tools or other resources they use to carry out one or more processes or activities.

Again quite clear what we’re talking about here, the old ‘units of organisation’. ITIL doesn’t have a lot of functions (only 4) and to be honest they are hardly earth-shattering. When it comes to structuring your teams\units\organisation you'll have to dig deeper into ITIL. There is a section on Operational Organisation Structure in the Service Operations publication, but it is so generic that just about everybody will end up with a ‘hybrid organisation’ (I might tackle this in a future blog).

So, two clear definitions and there could be no mistaking one for the other: functions are hierarchical, vertical, organisational teams (silos) whereas process are horizontal, cross-functional activities. And for the most ITIL sticks very well to this definition, perhaps with two exceptions!

In Transition we're confronted with a PROCESS called Transition Planning & Support. Like other processes, it gets an objective (which focusses on resources) but unlike other processes the book doesn’t define the role of a process owner\manager, but instead that of a Service Transition Manager. I guess that could still be acceptable, but amongst the role of this manager is:

• Managing and coordinating the Service Transition functions
• Budgeting and accounting for Service Transition team activities and resources

Really: functions … team … this certainly sounds more like a functional manager. In fact I often describe the Transition Planning & Support process as ITIL’s version of the Project OFFICE, which is also a role\team in an organisation.

This got me thinking whether ITIL has more processes that would perhaps be better off as a function. And I think I can make a case of doing so with Design Coordination. A bit of a Johnny-come-lately (only in 2011, not really in the syllabi of any Intermediate course, …). After all, whilst it is focussed on the activities of coordinating the design, and creating the Service Design Package, wouldn’t it be better off as a team with that specific responsibility as a constant across the various other processes, technology & application teams. You could assign a Design or Development Manager to this team and thus complete the functional management team of the Operations, Transition, CSI & now the Design\Development Manager.

I think it can work the other way around too. I don’t think every organisation needs an Operations Management team. For larger organisations it makes sense (whereby Technical & Application Management represent 3^rd level support, and the Operations Team 2^nd level, performing routine activities in incident, event, request and access management). But for smaller organisations there won’t be a 2^nd AND 3^rd level support and thus do the Technical & Application Management teams needs to perform operational ACTIVTIES. In this case perhaps it would be better off as a process (in addition to Event, Problem and Incident Management).

And what about Facilities Management, why is that part of Operations Management, which is a function? I can see there are operational activities (monitoring, access management, …) but who designs the Facilities? I actually think Facilities Management is still a function, but in its own right (perhaps performing some of the Operation Management ACTIVITIES) or as part of Technical Management, rather than being restricted to Operations.

ITIL has always been intended as a guideline, so perhaps we should even take the definitions of processes and functions as such and where applicable swap a few of them around!

the ITIL Zealot

May 2012

IT, Customer and User – A Bermuda Triangle

ITIL has a long history of being less than concise, sometimes downright ambiguous. ITIL ‘dinosaurs’ like myself my fondly remember the sleep inducing ITIL v1 books mainly due to its sometimes incomprehensible mumbo-jumbo and its apparent lack of structure, especially across the books. Or how about the v2 books where the chapter definition of a Release, did not reflect the one in the glossary of terms in the back?

Although v3 and 2011 are a lot better there is still some ambiguity and\or unclarity the use of terms and definitions, especially across the books. Personally for instance I find it a shame that the terms ‘utility’ and ‘warranty’ aren’t used outside the Strategy book (for impact\urgency classification, testing & evaluation, KPIs …).

I often say that certain sections in the book (and Service Strategy would be the main example of this) require you to read those two or three or more times. Every time you read it you’ll get a better understanding and develop a better ‘view’ of how it fits with the rest of ITIL. Thus eventually you build your own understanding or model of ITIL and its processes. Another good explanation is the old analogy of the ITIL processes as tectonic plates: they move, shift, bump and overlap each other. It is up to you to define the boundary between them (for instance between Demand Management and Business Capacity Management, Business Relationship Management and Service Level Management, Service Improvement Programs and CSI, Change Management and Transition Planning & Support, …).

One of the enduring ‘misunderstandings’ is that of Customer vs. User. The definition is simple enough though. A Customer is someone (i.e. an individual) who represents the business (i.e. a group, team, function, unit). On behalf of the business they will make decisions (in Service Level Management, in Change Management, …), but they will need to pay for those decisions. In other word a Customer is a decision-making, budget-holder.

The User by contrast is someone who uses the IT (Service). As such they only represent themselves and do not specifically make decisions or pay for those. Hence the difference between Request Fulfilment and Change Management. Request Fulfilment deals with predetermined, pre-costed, standard requests from the User, whereas anything new, different or unknown has to go through Change Management (and the CAB and most likely the Customer).

Roughly speaking Operations deals with Users (as it is business-as-usual and only limited decision-making is required, within specific parameter), whereas Strategy\Design\Transition involves the Customer for definition and decision-making (although the User will need to be involved, if only for someone to represent their interests and points-of-view).

Note though that most Customers will also be Users, as they normally will have a desktop\laptop\mobile phone or other IT device that they use. Even IT staff can be considered Users as they are also using IT devices and services. 

So, the Customer will decide (through Service Level Requirements) that they want an e-mail service with specific utility, for 5 days-a-week, at 99.9% availability, with a capacity for 1,500 users, storage for 7 years (i.e. warranty) etc. etc. Through the service level negotiations this will be agreed, with the IT Service Provider in an SLA, including costs and charges. Once Design and Transition are completed, the IT Service Provider will now deliver this service to the Users and they can use it (as defined by the Customer).

Now, if there is something wrong with the service (i.e. unavailable, no storage-space …) the user should notify the IT provider, through the Service Desk (incident management or request fulfilment, …). But if the Users want something which is outside the current agreed service, they should not notify (or rather as it is in most cases: complain) to IT, but instead bring this to the attention of the Customer, who can then negotiate the service change with the IT provider.

And here is where the Bermuda Triangle analogy comes from, as this line of communication is often missing. If Users do not directly communicate with the Customer (or vice versa) that IT gets stuck between a rock and a hard place. On the one had they have to deliver the agreed (with the Customer) service (often cut down on cost) but have to live up to the expectation of the Users (based on phenomenal quality).

Therefore it is in the IT provider’s interest to establish the lines of communication between Customer and Users. This can be done by performing User Satisfaction Surveys (and reporting this to the Customer), creating User Focal Groups (as part of Design), routinely performing User Acceptance Testing (in Transition) and involving the User in CAB, Post-Implementation-Reviews and CSI.

Ultimately we all want the same thing (service that deliver value to the business), but sometimes we not only approach it from different angle, but from different planets.

the ITIL Zealot