Skip to main content

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.

To learn more about ITSM Academy's ITIL 4 Courses please visit our website.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…