Functions and Processes-sec

8/9/2019 Functions and Processes-sec

http://slidepdf.com/reader/full/functions-and-processes-sec 1/22

Functions and processes in IT management

Modeling 365

6

INTRODUCTION

The ITIL® books are being used more and more as the basis for organizing an IT department

or company. From the 1990s on, many thousands of organizations have adopted ITIL as the

framework for their IT service management approach. It is clear that significant improvements

were realized in many of these projects. And, as a result, IT service management as a

practice was raised to a higher level of maturity.It is also clear that many of the projects did not meet their expectations. Even taking into

account the fact that ITIL projects include the known complexity of regular organizational

change projects, the average results are below expectation. Although the phase “adopt and

adapt” is widely accepted as the best approach to ITIL, in practice people tend to use ITIL as

is. And that’s where the problems arise…

ITIL is a clear example of a reference framework that covers very practical issues in live

IT service organizations. For many years, and for each of the targeted subjects, the best

practices have been collected and documented in separate publications from a practical

point of view. A consequence of this approach was the lack of a basic design.

After some time, titles were grouped in V2 “sets” to organize them. The V2 books did

little more than regroup the activity-based V1 books into new covers that had a more

comprehensive focus on processes and functions, added some missing content from the

same practical point of view, and lost some other content.

The V3 books built on this and added an overall approach, the service lifecycle. However, the

authors’ team decided not to change the most popular parts of ITIL, in spite of the “known

errors” in the previous version. As a result, they inherited most of the problems that came

with the V1 and V2 books.

A lot of these problems originated from the vague and contradictory use of the word

“process”. In fact, a lot of the limited results of so-called “ITIL implementation projects”

can be directly related to the misuse of this term. If an organization doesn’t understand

the difference between a process and a function, it will be very hard to get organized in an

effective and efficient way.

On the other hand, having this essential insight will assist organizations in using ITIL as

a reference set of good practices, applying it in a logical and structured way. But the


Migrating from an ITIL reference model to a universalimplementation model

ITIL does not structurally and clearly discriminate between processes

and functions. This makes ITIL a mixed reference model, where

organizations need implementation models to bring ITSM to practice.

In this article, Wim Hoving and Jan van Bon describe the fundamental

difference between functions and processes and provide a simple

implementation model that works in practice.

6.3






Modeling 367

6

assume that capacity management can only be a process. It is possible to measure and

control capacity and to determine whether it is adequate for a given purpose. Assuming that

it is always a process with discrete countable outcomes can be an error.” (A quote that is in

each ITIL V3 book)

Unfortunately this crucial comment wasn’t followed up in the rest of the books.

If you dig a little deeper, you will see that most of the ITIL “processes” appear to be

“functions” instead. By definition, processes are different from functions: they have different

dimensions. After careful analysis of ITIL V3 only a handful of “true processes” remain. The

rest are functions using these processes. Based on a clear and strict definition of “process”

and “function”, this list of processes and functions will be presented at the end of this article.

Once the distinction between processes and functions is clear, it is much easier to find aproper organization scheme in which process management can be used for optimum results.

Processes, procedures and work instructions

In practice, it is not the process that leads the people in an organization; it is the procedure,

and the work instruction. Processes only show how the logic in a procedure is constructed,

but they don’t tell you who should do what, when and how. However, if you don’t understand

your processes, and if you don’t build your procedure upon your processes, the procedure

will often be inconsistent with the next procedure. It will not be clear how and why it was

constructed. Therefore, you will need to have your process system in place before you can

construct or improve a set of procedures.

Process comes first

Paradigms like “process-people-product”, “structure follows strategy”, “procedure follows

process” and “structure follows process”, emphasize the critical role of the process model

in an organization. Applied to the process-function issue, this implies that functions should

clearly relate to processes for an optimum organization.

PROCESS MANAGEMENT IN MATURITY MODELS

Obviously, processes are important to organizations. Organizations that are aware of this

often tend to invest in their “maturity”.

There are two mainstream “schools” of maturity thinking. They are based on different

interpretations of the term “maturity”:

• Capability maturity models explain how well certain activities are performed. Examples

are CMMI, SPICE, the Test Process Maturity Model, the Project Effectiveness Maturity

Model (PEMM), Luftman’s Business IT Alignment model, and Nolan’s growth model.

Basically, all of these models describe process capability levels, expressing how well

processes are performed.

• Value chain maturity models explain how well an organization is able to contribute to a

value chain. Examples of the value chain maturity school are the KPMG World Class IT

maturity model (Delen et al., 2002), and the INK management model (based on EFQM).

Combinations can also be found, for example in the Gartner Networking Maturity Model.



368 IT Service Management Global Best Practices, Volume 1

There is a hierarchic relationship between both schools: the capability maturity models are

focused at process management, which encompasses the second or third stage of the value

chain maturity models.

The value chain maturity models make it clear that the road to “total quality” or “business

excellence” passes through the process-focused phase. The phase in which the organization

becomes skilled in managing processes is elementary in this maturity approach. The

organization cannot focus on systems and value chains until the processes are under control.

In general, organizations should learn to get in control of their infrastructure first, then master

their processes, and then learn how to provide the best services with that. Once they’ve

learned to provide the most effective and efficient services, they can adopt an external focus

and learn to understand the needs of the customer in the perspective of the value chain. Only

if an organization can do this, will it be able to survive and become a successful and mature

customer-focused organization.

BUSINESS PROCESS MANAGEMENT

Now we’ve made it clear why process management is an important phase in the road

towards business excellence, we should look at process management in more detail. The

most sensible way of doing this should at least involve the knowledge that was developed in

the discipline of Business Process management (BPM).

BPM involves the management and improvement of business processes. A structured

approach to BPM is often based on continual improvement methods like PDCA, and containssteps like process design (activity flows, actors, inputs/outputs, standard procedures,

communication), process modeling (resources, conditions, scenarios), process execution

(systems, tools, rules), process monitoring (measuring and tracking of individual processes,

metrics, KPIs), process improvement (evaluation, improvement scenarios) and then back to

process (re-)design.

The ISO 9001 documentation describes generally accepted approaches to BPM, using the

process approach. An important element in this process approach is the mapping of the

process structure, using process flow charts. Processes are presented as logically connected

sequences of activities, and not loosely coupled groups of activities.

The ISO 9001 quality model discriminates between processes, procedures and work

instructions. Developing a quality management framework starts at the top and works its way

down the pyramid: first the processes, then the procedures, and finally the work instructions

with supporting documents (figure 1).

A number of these BPM lessons have been widely accepted in businesses all over the

world. And, of course, it is no surprise that ITIL has claimed to adopt this knowledge in its

documentation of best practices. In practice, only a small part of the ITIL documentation is

indeed constructed with this knowledge.

BASIC GUIDANCE ON PROCESS MANAGEMENT

When arranging activities into processes, we do not use the existing allocation of tasks in the

live organization, nor the existing departmental divisions. Instead, we look at the elementary

and logical relationship between activities, in terms of their relevance for, and contribution




Modeling 369

6

to, one specific output. This is a conscious choice. By opting for a process structure, we can

often show that certain activities in the organization are uncoordinated, duplicated, neglected

or unnecessary.

A process organizes activities in a meaningful, logical, effective and efficient sequence

to realize a pre-defined objective. We focus on the objective of the process and the

relationships with other processes. In this sense, a process is a series of activities carried

out to convert an input into an output, and ultimately into an outcome. See the elementary

ITOCO model (Input-Throughput-Output-Control-Outcome) in figure 2.

Quality

manual

Core business

processes

Supporting

processes

Quality procedures

Work instructions

Supplemented by supporting documents

FlowchartsChecklists RecordsFormsDrawings

blueprints

Level I

Reiteration of theISO 9001:2000

quality standard.

Organization's

commitment to

quality model

Level IICPs - Core processes

and quality plans

Level IIIQPs - Quality

procedures

Level IV Wis - work

instructions

Management

Directors

and

managers

Directors, managers,

program & project

managers, personnel

All of the

organization's

personnel

QMS - Quality model

Figure 1 Process documentation in the ISO 9001 quality model (Tricker, 2006)

Figure 2 Process diagram, based on the ITOCO-model

standards and policies

efficiency

trigger

effectiveness

INPUT THROUGHPUT OUTPUT OUTCOME

CONTROL




The process is set off with a trigger. The (reported) output describes the immediate results

of the process, while the outcome indicates the long-term results of the process (in terms of

meaningful effect). Control activities assess whether the input, throughput and output of each

process are compliant with policies and standards, and take action if necessary.This produces process chains which show what input goes into the organization and what

the result is. It also provides monitoring points to check the quality of the organization’s

products and services.

Control activities

Processes are composed of two kinds of activities:

• activities to realize the goal - operational activities concerned with the throughput,

converting input to output

• activities to manage these ( control activities ) - make sure the operational activities (the

workflow) are performed in time and in the right order

For example, in the processing of changes it is always ensured that a test is performed

before a release is taken into production.

The standards for the output of each process have to be defined, such that the complete

chain of processes in the process model meets the corporate objective. If the output of a

process meets the defined requirements, then the process is effective in transforming its

input into its output. To be really effective, the outcome rather than the output should be

considered.

If the activities in the process are also carried out with the minimum required effort and cost,

then the process is efficient. It is the task of process management to ensure that processes

are executed in an effective and efficient way, using planning and control. Therefore, each

process will also contain control activities that make sure that quality standards are followed.

This results in clear transfer points where the quality of processes can be monitored.

Procedures and work instructions

Processes as such are too abstract for most people to be used in daily practice. The

processes only describe the what of an organization, and people need to understand the

who, the why , the when and the how to be able to use the processes in practice.

A procedure is a specified way to carry out an activity or a process. It describes the “how”,

and can also describe “who” carries out the activities. A procedure may include stages from

different processes and can vary depending on the organization.

A set of work instructions defines how one or more activities in a procedure should be

carried out in detail, using technology or other resources.

The process describes what the organization does, the procedure adds the who, when and

why, and the work instructions also cover the how and with. Figure 3 illustrates the fact

that the system gets interesting and meaningful for most people at the level where they are

involved. This is often at the procedure and work instruction level.




Modeling 371

6

WHAT DOES ITIL V3 TELL US ABOUT PROCESS MANAGEMENT

ITIL V3 (like V2 and V1) is “clear but ambiguous” about what a process is. The glossary says

the following.

Process: A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs. It may

include any of the roles, responsibilities, tools and management controls required to reliably

deliver the outputs. A process may define policies, standards, guidelines, activities, and

work instructions if they are needed. (ITIL V3 glossary)

This definition clearly doesn’t follow the BPM definition, as illustrated in figure 3. A process

here also contains elements from quite different levels, like work instructions.

Yet, the ITIL V3 Service Strategy book says something quite different.

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 an

external customer or stakeholder. (ITIL V3 Service Strategy)

The use of the term “outcome” instead of “output” indicates a very high level of process

capability maturity. It’s more likely that the term “output” was actually meant here. The

reference to “resources and capabilities” indicates that the scope of this definition is more at

the level of a procedure than at the level of a process.

At other positions in the V3 books, ITIL describes the widely accepted definition of “a

sequence of activities” (figure 4).

“Process definitions describe actions, dependencies, and sequence”, the ITIL V3 Service

Strategy book says. But if we look at the way the term “process” is applied throughout the

ITIL books, we see that none of these definitions are actually followed in a consistent way. All

Figure 3 Processes, people, products, procedures and work instructions

Process

Procedure

Work instruction

Process

People

Product

WHAT

HOW-WITH

WHO-WHEN-WHY




kinds of activity sets, all kinds of practical advice or “guidance” are described with the term

“process”. In fact, the ITIL V3 core books list at least 25 activity-sets labeled as processes:

• Service Strategy :

− financial management

− service portfolio management

− demand management

• Service Design:

− service level management

− service catalogue management− supplier management

− capacity management

− availability management

− information security management

− IT service continuity management

• Service Transition:

− transition planning and support

− change management

− release and deployment management

− service validation and testing

− evaluation

− knowledge management

− service asset and configuration management

• Service Operation:

− incident management

− problem management

− access management

− event management

− request fulfillment

• Continual Service Improvement:

− 7-step improvement process

− service measurement

− service reporting

Suppliers Activity 1

Activity 2 Customer

Activity 3

Service control and quality

Trigger

Data,

information

and

knowledge

Desired

outcome

Process

Figure 4 A basic process, according to ITIL V3 (source: OGC)




Modeling 373

6

This clearly follows the definition of the ITIL V3 glossary, and not the detailed definition

system that is provided throughout the core books. And it certainly doesn’t follow the lessons

learned in the business process management discipline. Since a process is only about the

what , process definitions should exclude all information on the other dimensions ( who, howand when ).

As soon as we see a process title like capacity management, alarm bells should start ringing.

Since this term refers to infrastructure - clearly an element of the lowest level in figure 3 - it

should not be an element of a process description at all. The same would go for network

management, desktop management, application management and many more infrastructure-

based activity clusters. Activities that are gathered under this kind of title are actually often

functions using a number of elementary processes.

ELEMENTARY PROCESSES OF A SERVICE PROVIDER

As illustrated, there are several definitions of “process”. For a simple, understandable and

practical view on process management, we need to choose a clear definition and a context

for its application.

Process: A sequence of interrelated or interacting activities transforming inputs into

outputs, designed to accomplish a defined objective in a measurable and repeatable

manner.

A process description defines what will be done, what input is required, and what output is produced. See the ITOCO model in figure 2.

Processes have clear business reasons for existing.

A process can be detailed in one or more procedures, and subsequent work instructions.

The organization can define roles and responsibilities and relate these to the activities in the

process.

Sequence

The structure of a process is in fact a sequence of activities that are placed in a repeatable

logical order: a workflow. This workflow is controlled by control activities. These activities

make sure the operational activities are performed on time, in the right order and in the

correct way.

Repeatable and measurable

A process is measurable, has specific results delivered to a customer, and responds to

a specific event. ITIL says: “While we can count changes, it is impossible to count how

many service desks were completed. So change is a process and service desk is not: it is a

function.”

A logical question would now be: how many capacities have you done today, how many

continuities, and how many availabilities? Obviously, this question cannot be answered, and

we are at risk of degrading the real question to a word game. It would make a lot more sense

if we would turn this into questions like:

• How many capacity incidents have you managed today?

• How many capacity changes have you managed today?

• How many capacity risks have you managed today?




These questions refer to repeatable, measurable and meaningful results.

Effectiveness and efficiency

So what would a set of elementary processes look like? Like any other kind of serviceorganization, an IT service provider has only a very limited set of high frequency elementary

processes:

• Four processes are concerned with effectiveness:

a. Agree with your customer what you will deliver. We can call this the contract

management process.

b. Deliver what you have agreed. We can call this the operations management process.

c. Repair anything that goes wrong. We can call this the recovery management process.

d. Change your service if your customer wants another service. We can call this the

change management process.

• Two processes are concerned with efficiency :e. You know what you use to deliver your service with. We can call this the configuration

management process.

f. You adjust (to) conditions that may prevent you from delivering tomorrow what you

have agreed today. We can call this the risk management process.

This applies not only to an IT service provider, but also to service providers in other

disciplines. Imagine a catering service provider, the national post, or any other service

provider: they all will perform these same elementary tactical and operational processes.

For an IT service provider, the contract management process (a) will cover responsibilityareas like service level management, supplier management and business relationship

management. The operations management process (b) will cover everything the organization

needs in order to produce the IT service, when the service is not down and when it is

not changed (which is the bulk of the IT provider’s activities). It would normally cover the

planning and execution of all operations activities, including the monitoring of all services

and components. The recovery process (c) covers everything concerned with the repair

of services or components. The change process (d) covers everything to be done when

changing an IT service or component. The configuration management process (e) covers all

activities for providing correct information on all infrastructure components used to deliver

the services. And finally, the risk management process (f) covers all proactive management

activities that make sure that the organization will still be able to deliver the service as

agreed, in spite of changing conditions (capacity, performance, problem, demand).

Strategic processes

Of course, an organization will have some kind of strategic process covering this elementary

set. However, strategic activities do not usually get caught in process descriptions. The

frequency of these activities is relatively low, so the short term repetitive character is

missing. Moreover C-level managers in strategic positions do not usually consider their

activities as being standard and commoditized. The Service Strategy book in ITIL is a good

example: although many activities are described, you will have to look very hard to be able

to recognize a real strategic process in the book. For practical reasons, we’ve chosen to limit

the set of high frequency elementary processes to the tactical and operational levels in an

organization.




Modeling 375

6

A SIMPLE PROCESS MODEL BASED ON ELEMENTARY PROCESSES

Contrary to what ITIL says, the basic processes for an IT service provider are quite standard

and vary little. In fact, they are commoditized. They may vary in the level of detail, but the

logic and meaning of, for example, the change management process will be similar for allorganizations.

The previous paragraph described the six elementary processes that are common to each

service provider, in whatever line of business they are active. Combined with the observation

that IT organizations have great difficulties in managing their processes, and that they hardly

ever master more than four or five processes, this leads to the conclusion that for most

organizations, only very simple process models will work in practice. Figure 5 presents such a

model, which is based on the ISM® model, as first published by Van den Elskamp c.s. in 1999.

This is a very simple but practical model that covers the vast majority of what a service

provider should manage in terms of processes. It’s a process model, and therefore it doesn’t

show any information on functions. It’s easy to show how functions can be used to cover

the organizational dimension. The model doesn’t show information flows, just the process

triggers:

• a change in a contract triggers a change in the infrastructure (through change

management)

• an infrastructure change triggers an operational activity in the production environment

(through operations management)

• if something doesn't function as agreed, it is repaired or reset (in operations management)

or adapted (through change management)

• all changes require an update of the administered infrastructure (through configuration

management)

• errors in the infrastructure administration may require a controlled change to re-establish

the required infrastructure

Figure 5 A simple process model for IT service management

Contract managementRisk

management

Recovery

management

Configuration

management

Change management

Operations management




• risks that are a threat to the realization of the SLA should be taken away by changing the

information system or by negotiating the SLA (through risk management)

• changing conditions may require an adjustment of the agreed service specifications or a

change to the infrastructure

Functions like capacity management, application management or the problem management

team may use these processes to realize their specific objectives.

FUNCTIONS

Having defined “processes”, it’s now time to define “functions”.

What is a function

“Service management is a set of specialized organizational capabilities for providing value to

customers in the form of services. The capabilities take the form of functions and processes

for managing services over a lifecycle” (ITIL V3 Service Strategy book)

So, according to ITIL V3, functions and processes are apparently different entities.

ITIL V3 provides a clear definition of the term “function”.

Functions are units of organizations specialized to perform certain types of work and

responsible for specific outcomes.

They are self-contained with capabilities and resources necessary for their performance and

outcomes. Capabilities include work methods internal to the functions. Functions have their

own body of knowledge, which accumulates from experience. They provide structure and

stability to organizations.

Functions are a way of structuring organizations to implement the specialization principle.

Functions typically define roles and the associated authority and responsibility for a specific

performance and outcome.

In organization design, functions are commonly coordinated through shared processes.

Functions tend to optimize their work methods locally to focus on assigned outcomes. Poor

coordination between functions combined with an inward focus leads to functional silos

that hinder alignment and feedback, which are critical to the success of the organization as

a whole. Process models help avoid this problem with functional hierarchies by improving

cross-functional coordination and control. Well-defined processes can improve productivity

within and across functions. (ITIL V3 Service Strategy)

Although ITIL V3 does not make this explicit, it’s worthwhile to note that functions don’t have

to be limited to fixed organizational units. Virtual teams would also fall within the definition of

function.

Apart from the organizational unit, the term “function” is also used in various other meanings.

Definitions (Van Bon, 2008) of the term cover the following:

1. A (virtual) team or group of people and the tools they use to carry out one or more

processes or activities. For example the service desk, availability management, capacity

management and IT operations.






to the line. Activities can be managed through the process as well as through the line. An

organization that wants to be in control of all of its important activities should establish the

relevant process as well as the line aspects for these activities. It also needs to establish a

strategy to manage the activity: through the process, through the line, or through a mix.

In practice, process-based organizations are always matrix organizations: they combine a

mix of management via the line and via the processes. Each individual organization can vary

the extent to which it uses these two control mechanisms according to its own preferences

(figure 6).

According to the process management matrix (PMM, see the article of Wim Hoving and Jan

van Bon in this book), the mix of the two “pure” control models can take seven key positions:

1. The pure line organization - All recognized activities are only managed from the position

of a team or a role.

2. The line organization recognizes workflows – Workflow-defined activities are related to

teams or roles.

3. Tactical process management - Processes are described and managed by reports.

4. Operational process - Processes are described and process control is responsible

for monitoring the process performance, informing the involved staff and escalating to

management. The line is still in charge.

5. Operational process direction - Processes are described and process control is

responsible for monitoring the process performance and informing, directing or correcting

the staff involved. This is the first position where the process is actually in charge.

6. Operational and content direction through processes - Processes are described and

process control is responsible for monitoring the process performance and informing,

directing or correcting the staff involved. Process control should also allocate the staff to

the process activities.

7. Full process direction - All teams are organized to execute a process.

Figure 6 Different ratios of line and process-based control (Hoving & Van Bon, 2008)

Process manager

Line manager

Employees

12

34

5

6

7




Modeling 379

6

Depending upon the weight of process management in the management matrix, an

organization will spend more or less energy on its process system. The “heavier” the process

component is, the more an organization will have to understand and manage its processes.

An organization that is in stage one, two or three of the PMM will have a rather superficialunderstanding of processes, but any stage beyond that will require thorough awareness and

understanding of processes.

Functions in IT service management

IT service management literature provides us with many examples of best practices,

guidance and instructions. Some of these descriptions are in the format of a process, some

are in the format of a function, and some are rather unclear. If an organization wants to

implement a clear management approach to IT service management, it will have to make

a choice on how to organize the work. This means that it should be aware of the use of

processes and functions, since both require quite a different approach.

Example: change management can be presented as a process—a logical sequence of

activities—that start with a trigger (RFC) and provide a specific and measurable customer-

related output. However, many organizations also have a department known as change

management, or a change management team. This unit doesn’t cover all the human

resources that are involved in all of the organization’s changes: since almost everyone in an

organization is involved in the change management process, that wouldn’t be a practical

model. Instead, the change management team takes care of most of the administration of

the changes, and provides human resources that act as change coordinators. Often, the

change management team is combined with the configuration management team.

It may be difficult to determine whether something is a function or a process. According to

ITIL, whether something is a function or a process depends entirely on the organizational

design. For example, according to ITIL, capacity management could be defined as a process

with specific and measurable results that focuses on a specific goal.

Now, if ITIL defined capacity management as a logically ordered sequence of activities

realizing a certain predefined objective, with inputs, outputs, procedures, work instructions,

adjustment on the basis of feedback and comparison against standards, then it could surely

be deemed a process.

However, this is not the case in ITIL. ITIL’s capacity management covers a range of activities

that cannot be ordered as a logical sequence of activities. As such, the ITIL context presents

a capacity management function and not a capacity management process. The processes

deployed by capacity management are generic processes specified to that part of the

infrastructure that is the subject of attention in capacity management: all elements of the

information system that deal with capacity.

Based on the definition of a process in terms of the what , anything that describes the who,

how and when will have to be classified as a procedure or a work instruction. And as soon

as the who comes into the description, it touches on the organization. And then, we might

classify this as a function.

There are quite a few entities in IT service management literature, specifically in the ITIL

books (V1, V2 and V3), that can be recognized as functions instead of processes. Looking at

content in terms of the who, when, and how, helps in recognizing these.




Infrastructure-specific functions

First of all, we can recognize a set of functions that are infrastructure-specific. Terms like

capacity management, network management, print and output management, and financial

management clearly relate to a specific part of the enterprise infrastructure. This kind ofentity will typically be a function: an organizational unit that is involved with all aspects of this

entity, using all the processes that are recognized in that organization. You may recognize

functions like:

• Capacity management, a function limited by its scope. It addresses only the capacity

elements of an IT service. As a function, it uses a set of elementary processes:

− for realization of the capacity of the agreed services at the agreed rate/demand, this

function uses the operations management process.

− for repairing capacity issues it uses the recovery management process.

− for changing capacities it uses the change management process.

− for agreeing on capacity aspects it uses a contract management process.− for proactive actions of capacity issues it uses a risk management process.

− for knowledge of which capacity carriers are deployed in which parts of the enterprise

infrastructure it uses the configuration management process.

• Application management, a function limited by its scope. It is not addressing the entire

IT services but just an infrastructural sub domain (applications). As a function, it uses a set

of elementary processes:

− for realization of the application components of the agreed services at the agreed rate/

demand, this function uses the operations management process.

− for repairing application issues it uses the recovery management process.

− for changing applications it uses the change management process.− for agreeing on application functions it uses a contract management process.

− for proactive actions on application issues it uses a risk management process.

− for the knowledge of which applications are deployed in which parts of the enterprise

infrastructure it uses the configuration management process.

Network management, data management, workload management and print management will

now all be recognized as variations to the themes above. Table 1 shows the set of entities

that can be recognized as infrastructure-specific functions.

This analysis is limited to primarily infrastructure-related or service-related processes.

Secondary supporting activities that are normally managed outside the scope of IT

service management—such as financial management and knowledge management—are

out-of-scope. This doesn’t mean that it is impossible to apply the approach to financial

management, but it would require the financial management activities and functions to

be specified in the SLA and, as a consequence, controlled in IT service management.

In practice, however, the financial department normally is a function that is managed as

a separate entity. The same goes for knowledge management: the scope of knowledge

management is not restricted to the core service management activity domains, so this is

something that is normally managed apart from the service management domain.

Service quality specific functions

Secondly, we can recognize a set of entities that are quality-specific. Terms like availability

management, continuity management and security management relate to just one quality

aspect of the information service. This kind of entity will also use the elementary processes

that each service organization follows, and will apply these to just their specific objective. For

example, availability management uses:




Modeling 381

6

• the operations management process for realization of the availability of the agreed

services at the agreed rate/demand

• the recovery management process for repairing availability issues

• the change management process for changing availability• the contract management process for agreeing on availability aspects

• the risk management process for proactive actions of availability issues

• the configuration management process for the knowledge of which availability measures

are deployed in which parts of the enterprise infrastructure

Replacing “availability” with other service quality attributes like security or continuity, will

provide a series of other functions (see table 1). This is not limited to the quality attributes

that ITIL V3 lists, but also to attributes like performance, scalability, reliability, maintainability,

portability, or traceability.

Activity-specific functions

Thirdly, we can recognize a set of process- or activity-specific functions, such as teams

for change, problem, service level, supplier and configuration management, but also a

service desk (see table 1). All of these teams can be functions that focus on elements of

specific processes but are involved in other processes as well. For example, the problem

management team will coordinate the handling of problems and administer the problem

management database in the risk management process, but it will also support the handling

of incidents in the recovery management process: one of the most commonly cited

mistakes in IT service organizations is that anything handled by the members of the problem

management team automatically is a problem. Following the same logic, the suppliermanagement team will also be involved in the processes for contract, change and recovery

management.

Type Function

Infrastructure functions Application management (*)

Capacity management (*)

Database administration

Data & information management

Desktop support

Directory services management

Facilities & computer management

Internet/web management

Mainframe management

Middleware management

Network management

Print management

Server management & support

Storage and archive (*)

Technical management (*)

Service quality

functions

Access management

Availability management

Capacity management (*)

IT service continuity management

Security management

Workload management




While the number of significant processes is limited to just a few, the number of importantfunctions that can be defined is endless: a function can be defined for each service

attribute that is agreed upon. Common paragraphs in an SLA deal with familiar service

quality attributes like availability, capacity, and continuity. As a consequence, we will find

availability management, capacity management, and continuity management functions in that

organization. But if the organization also agreed to specifications for performance, reliability,

portability, or others, you may expect to find functions like performance management,

reliability management and portability management. These functions would then all use the

elementary processes for their activities.

Organization-specific functions

Finally, organizations can vary tremendously in terms of their organizational shape. A small

IT shop of five people simply cannot be compared to the IT department of a multinational or

a large bank. Furthermore, organizational structures like centralization and decentralization

will make a lot of difference. And the relative position in the process management matrix will

have significant influence as well. An organization at positions one and two doesn’t recognize

processes and will not have process managers. An organization moving around position

three will mainly have team leaders, while process ownership may reside with a quality

manager. And an organization that moves around the positions four or five of the PMM will

have process managers in high-ranking positions, for example in the management team.

Many IT organizations still organize according to traditional principles like development

versus operations. Although this may seem logical, based on the specific nature of the

activities involved, it doesn’t make much sense in terms of a process focus: the processes

clearly do not follow these boundaries but go right through them.

Culture and history have great influence on practical organizational structures. And

Type Function

Activity functions Business relationship management

Change management (team)

Configuration management (team)Demand management

IT operations

Managing communications and commitment

Managing organization and stakeholder change

Monitoring & control

Problem management (team)

Requirements engineering

Service level management (team)

Stakeholder management

Storage and archive (*)Supplier management

Organization functions Application management (*)

IT operations management

Service desk

Technical management (*)

Table 1 Functions in IT service management, based on ITIL V3. Financial and knowledge management are out of

scope. (* = function classified in more types)




Modeling 383

6

“organizational change” appears to be one of the most challenging activities in IT

organizations.

Finally, the infrastructure that organizations use can have a great influence uponorganizational structure. Activities and knowledge vary with this infrastructure, and

organizations tend to cluster similar skills in organizational units.

As a result, we’ll see all kinds of organizational functions in practice (table 1), and there is no

simple standard to be applied here.

ITIL AS A SOURCE OF INFORMATION

ITIL has been used as the source of best practice on IT service management for many years

now. It has also been claimed that ITIL describes a set of processes. In ITIL V2, the mainfocus of attention was primarily on the scope of the ITIL Foundations certificate, which was

largely concentrated in just two of the core books, Service Support and Service Delivery.

These two books were said to document ten processes and one function.

Service delivery contained:

1. service level management

2. service continuity management

3. financial management

4. capacity management

5. availability management

Service support contained:

1. incident management

2. problem management

3. change management

4. release management

5. configuration management

6. and the function: service desk

An eleventh “process”, security management, was within the scope of Foundations, but was

covered in a separate book (as well as in the availability management chapter of service

delivery).

In ITIL V3, a lot of new processes were added to this list. Table 1 showed most of these

processes, but qualified them as functions. The processes and activities that fit the

description of the set of six are now shown in Table 2. This table also qualifies a number of

the ITIL V3 processes as components of the six elementary processes.

Although it was claimed that ITIL V3 would align better to ISO/IEC 20000, there was still one

ISO process missing in this version: business relationship management (see table 1.).

Main processes and sub processes

Some of the ITIL V3 processes in table 2 are no more than activities in the larger perspective

of an elementary process. For example, the V2 change management process was split into

several steps of the overall change process. This means that some of the V3 processes are




actually sub-processes that can be reassembled into one process, and describe the steps ofwhat was called “the change management process” in ITIL V2.

Conflicts in process definitions, such as change management versus release management,

were not solved in V3.

Other processes are really clusters of sub-processes. For example, the ITIL V3 service asset

and configuration management covers various kinds of activities that cannot be aligned in

a process sequence, but rather cover an implementation sequence, or PDCA approach:

management and planning, configuration identification, configuration control, status

reporting, verification and audit. Therefore, it should be qualified as a process cluster, just like

the V2 configuration management.

IMPLEMENTING ITSM BASED ON EXISTING REFERENCE MODELS

Information on the details of the six essential processes can be found in many places. The

ITIL books provide detailed guidance on at least four of them (contract, change, recovery,

and configuration management), and some information on the two others (risk and operations

management).

But once an organization understands that simplicity is a key requirement for a practical

process model, it won’t be difficult to define all six processes. And if an organization would

prefer to use traditional ITIL titles, it could for example replace recovery management

with incident management, configuration management with configuration management,

contract management with service level management, and risk management with problem

management. In that case, however, the organization must be able to adequately differentiate

between ITIL guidance referring to processes and ITIL guidance referring to functions.

The six elementary processes in IT service

management

ITIL V3 processes and activities

Contract management Service level management

Service portfolio managementService catalogue management

Change management Transition planning & support

Change management

Evaluation

Service validation & testing

Release & deployment management

Recovery management Incident management

Operations management IT operations

Monitoring & control

Event managementRequest fulfillment

Configuration management Service asset & configuration management

Risk management Problem management

The 7-step improvement process

Service measurement

Service reporting

Table 2 Processes and activities in ITIL V3




Modeling 385

6

Implementing an IT service management approach based on the six essential processes can

be a lot more effective and efficient than the general, complex approach using published

practices in ITIL. The fact is that the ITIL practices are not designed in terms of processes

and functions. They only provide practical guidance on aspects of the service managementsystem, which by itself is quite useful, but also holds significant risks in terms of overview

and manageability.

Once an organization understands the difference between processes and functions, it can

determine its service management architecture, and build on that.

Implementation projects are then much easier to carry out, and they have a very significant

advantage above traditional approaches: the implementation project can focus on the

organizational change, and the people involved. Defining a set of simple processes is the

first step, but since these processes are at the end of their evolution (thanks to ITIL and other

sources), this would require very little time. The energy of the implementation project can bealmost entirely focused on the softer side of the project, which is exactly where traditional

projects have always failed.

Project teams can start with the existing organization, gaining an understanding of the way

they use the six elementary processes. Once they understand this, they can carefully migrate

to a better, more effective and efficient organization. This may involve a new position in the

process management matrix, for example bringing some process management roles into the

organization’s management team. It may also involve training and coaching focused on the

roles the organization has chosen to fill in their function structure.

There is one thing the organization should never forget: if you haven’t organized your “what”,

you don’t know what you do. If a house is built on quicksand, it will collapse in time, or it

will cost a lot of resources to keep it upright. And the fundament of each organization is its

identity: the “what”. Without a thorough understanding of your most elementary processes in

a comprehensive process model, you’re bound to pay the price sooner or later.

Wim Hoving (The Netherlands) is the CEO of BHVB, specialists in service management, ITIL

and ISM. He has been involved in IT service management for twenty years, as a program

and project manager in large and small organizations.

Jan van Bon (The Netherlands) is the CEO of Inform-IT, editors & innovators. He has

been involved in the development of IT service management best practices since the early

nineties, managing the production of dozens of publications, conferences and several

knowledge platforms.

REFERENCES

• Bon, J. van (to be published in 2008).Compendium IT Management. A definitions set.

• Delen, G., M. Griep, D. Grund, & J. Roelofs (2002). The future of the IT organization. A

multi-client study into the transformation of IT organizations. In J. van Bon (ed.), The Guide

to IT Service Management (Pages 366-382). London: Addison Wesley.

• Elskamp, H. van den, W. Kuiper, H. Wanders, J. van Bon, & W. Hoving (1999). ISM:

Integrated Service Management. In J. van Bon (ed.), IT Beheer Jaarboek 1999 (Pages 149-

162). The Hague: ten Hagen & Stam.

• Hoving, W., & J. van Bon (2008). The Process Management Matrix. In J. van Bon (ed.),

IT Service Management, Global Best Practices, Volume 1. Zaltbommel: Van Haren

Publishing.




• ITIL. Continual Service Improvement (2007). OGC. London: TSO.

• ITIL. Service Design (2007). OGC. London: TSO.

• ITIL. Service Operation (2007). OGC. London: TSO.

• ITIL. Service Strategy (2007). OGC. London: TSO.• ITIL. Service Transition (2007). OGC. London: TSO.

• Tricker, R. (2006). ISO 9001:2000. The Quality Management Process. Zaltbommel: Van

Haren Publishing.

Documents

Functions and Processes-sec