Who Moved My Process?

Who Moved My Process?

There are some misconceptions about ITIL? 4 and its use of the term ‘practice’ vs. ‘process’ as a component of its recently introduced service value system.

One misconception is that processes aren’t important anymore. Another is that organizations think they must completely redesign their tools in order to accommodate this change. Neither is true. 

Let’s begin by taking a look at how ITIL 4 defines these terms.

Process: a set of interrelated or interacting activities that transform inputs into outputs [to accomplish an objective]. Processes define the sequence of actions and their dependencies.

Practice: a set of organizational resources designed for performing work or accomplishing an objective. Practices include resources based on the four dimensions of service management which include: organizations and people, information and technology, partners and suppliers, and value streams and – wait for it – processes.  

Both processes and practices focus on achieving an objective. Processes define specifically how to achieve that objective using well-defined, standardized procedures. Practices look more holistically at the capabilities needed to achieve that objective.

With processes, the goal is to continually improve efficiency and effectiveness by defining specifically how work gets done. A good thing…sometimes.

With practices, the goal is to create a learning organization where people are continually refining their capabilities in areas such as analysis and observation, decision making and leveraging all available sources of information. A good thing…always.

You can think about this as a continuum. On one end you have clearly defined processes, supported by structured information, that spell out – step-by-step – how to perform a set of activities. On the other end, you have a more loosely defined approach to work that leaves the specifics up to the people who have the knowledge and skills to do that work.

There are times when processes are appropriate. But they can also get in the way. Let’s walk through an example. If a user contacts the service desk to report an incident, it is absolutely critical to have a process that defines how the contact is handled and how the incident gets recorded. This process enables the contact to be handled efficiently (thus putting the user at ease) and ensures the structured information needed to handle the incident is captured (thus preventing a bunch of rework downstream).

Where we go from there, however, may vary. Sometimes it’s clear how to handle the incident, whether at the service desk or by escalating it to the appropriate support team. With complex systems, however, it’s not always that easy. If the failing component is unclear, using a traditional tiered escalation approach (and possibly having the incident bounce around for a while until it lands in the right team) will only elongate the process. Here’s where an approach such as swarming comes in to play. Swarming involves many different stakeholders working together until it becomes clear how to proceed. It’s an approach that is more loosely defined and that relies on skilled professionals using their knowledge and experience to make judgment calls about what to do and who should do it.

If the notion of ‘loosely defined’ scares you, rest assured it doesn’t mean there aren’t ground rules for how work is handled. Here’s where principles-based thinking comes into play. But principles-based thinking is a conversation for another day. Back to practices and processes.

Processes will always be important and when used appropriately, free humans up for activities that require experience and judgment. They are effectively supported by tools and can often even be automated. It’s when we start to think an existing process, or some ‘best practice’ view of a process, is the only way to do something that we run into trouble. Or when we think that all types of work can be well-defined and standardized. That rigidity will inevitably stifle innovation and bind organizations to old, and perhaps inefficient, ways of working.

ITIL 4 is encouraging us to use processes where they are appropriate, and to continually evolve and improve those processes to ensure that they at all times meet our organization’s circumstances, needs and goals. And to also understand that in today’s complex and dynamic workplace, there are some types of work where emergent practices and experimentation are more appropriate.

ITIL? is a registered trade mark of AXELOS Limited.

Originally posted by the ITSM Professor

Find ITSM Academy on Twitter @ITSMAcademy ?? Find Lisa on Twitter @ITSM_Lisa?


Jan van Bon

Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery

5 年

ITIL 4 finally admitted it: "what we used to call processes, actually always have been practices". The way you explain it, contradicts the advanced insight of ITIL 4. You still use the old interpretation of *process*, that has cost (and still are costing) organizations billions. Try to get rid of the old idea of *process* representing the policies and practices of a service organization, and you may make a huge step forward.

Al Bedgood, EdS, PMP, ITIL4 MP

Instructor, Consultant, Veteran, Advocate.

5 年

Hi Lisa. Thank you for a well stated description and discussion of these aspects of ITIL4.

回复

要查看或添加评论,请登录

社区洞察