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
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 3rd level
support, and the Operations Team 2nd level, performing routine
activities in incident, event, request and access management). But for smaller
organisations there won’t be a 2nd AND 3rd 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
No comments:
Post a Comment