HCI ITSM Description

Process Modeling

This section is intended to demonstrate the importance of process modeling capabilities as a pre-requisite for implementing service improvement projects based upon ITIL and CobIT best practices. I demonstrate the extend of agreement on this need through reference to CMMI, CobIT and other sources. I finish by describing the key elements which go into a process description - essentially the material required to Institutionalize the process within the organization.

What's in this Section

Organizational Structure

Organizational Process Capabilities

Process Modeling

Organizational Structure

ITSM is about the delivery of services. The delivery of a service differs from the delivery of a commodity in the following ways:

Services are intangible,
The customer may participate in the service delivery process,
Part of the service consists of interactions between customers and technicians,
The production and consumption of a service are inseparable and can occur at the same time,
Services are delivered through multiple processes using a chain of partnerships,
Services may not be mutually exclusive; that is one service may form part of another service.

Most enterprises are not organized along service lines. Traditional organization structures allowed companies to achieve three interrelated goals which have little connection to the service requirements of a customer:

define lines of responsibility and authority
channel the flow of information
help achieve coordination of work activities.^N

All three, but most certainly the last, of these goals have implications for how a service division should be organized. Traditionally, the division may adopt one or more of four primary organizational models (variants and mixes are common):

Functional - employees are grouped together on the basis of the primary skill (or business function) they need to do their job
Divisional - employees are grouped together according to (1) the products on which they work, (2) geographic location or (3) sets of customers they serve.
Lateral Relations - a structural devise to encourage coordination amongst individuals and groups in different work units.
Matrix structures - employees report to multiple supervisors creating multiple chains of command

Most IT services will involve several divisions and/or functional lines which contribute participants in a "service chain". Companies develop and maintain systems and applications according to IT groups or Line Of Business (LOB) - rather than according to business process or service - resulting in a hodgepodge of packaged, custom and legacy applications.

Graphic 1: Organization complexity in IT service provision This diagram illustrates how various processes involve multiple units within the IT division itself. This matrix of organization unit and functions is further complicated when LOBs maintain exclusive or predominant influence over their major applications. With their intrinsically narrow views of the enterprise, these "silos" add to the complexity of managing enterprise applications and create a number of management problems. The lack of visibility across the enterprise hinders the ability to measure service levels and the business impact of problems, obstructs managing availability and performance, and limits the ability to isolate and resolve problems. Since each LOB addresses similar management concerns - often in different ways - management efforts are duplicated, economies of scale are lost, and any prospect of a "big picture" view of the business is wasted by the lack of information sharing^R. In large organizations with multiple mission-critical applications, the respective businesses may be reluctant to relinquish any control over the application to a central IT Provider (ie. Application Support) thereby creating complexity and inefficient management. The need for cooperation can lead to friction because units need to acknowledge process hand-offs.

This need for cooperation is inherent throughout ITIL best practices and requires attention and ongoing scrutiny by the organization wishing to implement, sustain and build upon service improvements:

"When ITIL is implemented, the support and delivery of IT services is performed via cross-functional processes rather than functional groups. It is up to the organization to determine how those processes will map to the existing organizational structure. In some cases, that structure is changed. In other cases, organizations decide to formulate cross-functional committees to oversee and steer processes. In either case, people are ultimately forced to change how they perform their daily tasks and that is not always met with enthusiasm. These changes can include simple procedural changes, entire process reform, changing the tools that are used, individual job title changes, and changing reporting lines."

Problem Management: The Key to Leveraging an ITIL Implementation, Chorus White Paper, March, 2005

Friction occurs at the point where activities, operations, functions, disciplines, departments, or business units interact. Metrics should be placed at these touch points to meaure the amount of friction that occurs.

Mark D Lutcheon, managing IT as a business, Son Wiley & Sons, 2004, ISBN: -0147-14706-6, p. 168.

The introduction of better workforce practices is a key enabler for implementing new process initiatives and needs to be closely coordinated with better governance models including a review of the organizational structure of the IT service provider.

Organizational Process Capabilities

People Maturity Modeling suggests that this "friction" and the workforce practices engendered by rigid organizational structures are endemic in less mature organizations. At a minimum the enterprise must ensure a stable work environment. Without this stability introducing new work practices associated with revised or new processes will be problematic...

At the second level of maturity, organizations must establish a foundation on which they can deploy common processes across the organization. Before being able to successfully implement many advanced practices, management must first establish a stable environment in which to perform professional work. They must ensure that people are not constantly rushing about pellmell, cutting corners, making mistakes from hasty work, and fighting the fires that characterize over-committed organizations. Until basic management control is established over daily work, no organization-wide practices have any chance of being deployed successfully since no one has the time to master them. The primary objective of a level 2 environment is to enable people to repeat practices they have used successfully in the past. To enable this repeatability, managers must get control of commitments and baselines. The effort to establish a repeatable capability is the effort to establish basic management practices locally within each unit or project. Only when this management discipline is established will the organization have a foundation on which it can deploy common processes.

http://www.sei.cmu.edu/cmm-p/version2/

Defining standard processes is crucial in achieving level 3 process capabilities. In devising its' criteria for assessing the maturity of IT governance process, the Information Systems Audit and Control Association suggest that best practices such as ITIL are targeted to the achievement of a point between maturity levels 2 and 3.

Graphic 2: COBIT Executive Summary

Most organizations are currently at level 2 - offering Repeatable services. ISO standards reside about half way between levels 2 and 3 while currently described best practices such as ITIL are focused at organizations striving (but not attaining) a defined maturity level. The ultimate goal for all enterprises should be attainment of an " optimizing" maturity level. The reasons for this are aptly described in the following passage from CMMI.

The organization's set of standard processes, which is the basis for maturity level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization's set of standard processes according to tailoring guidelines.

The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed.

A critical distinction between maturity level 2 and maturity level 3 is the scope of standards, process descriptions, and procedures. At maturity level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At maturity level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit. The organization’s set of standard processes includes the processes addressed at maturity level 2 and maturity level 3. As a result, the processes that are performed across the organization are consistent except for the differences allowed by the tailoring guidelines.

CMMI

In the Netherlands, the Kwintes Project applied CMM to the achievement of level 3 service management maturity^N. It cited the following key processes for obtaining a Standardized level of IT service management:

Organization Service Definition - a service catalogue is developed that describes the services, in terms of customer benefits, that the service provider can deliver.
Organization Process Definition - the organization describes the processes used to deliver the services, described in the service catalogue. Service catalogue and standard service processes undergo improvement as a result of practical experience.
Organization Process Focus - this key process area is aimed at implementing the standard processes and assessing the performance of the processes in practice.
Integrated Service Management - this key process area is aimed at tailoring the standard service processes to specific service commitments for a specific customer so that the tailored process can be used to manage and deliver services to the customer.
Service Delivery - the tailored service processes are performed to deliver the services.
Training Program - based on the standard processes, a training program is developed. Employees are trained to fulfill their roles in the standard process.
Intergroup Coordination - delivering services requires different groups and disciplines to coordinate their work. This key process area makes sure communication between different groups is facilitated.
Problem Management - incidents and service requests that are registered as part of the Event Management key process area are analyzed to identify and solve underlying problems in the information technology.
Resource Management - required resources for delivering different services to different customers are coordinated across the organization.

Kwintes emphasizes the development of process descriptions and suggests that these process assets should be developed in close parallel with a service catalogue. And, many of the Kwintes recommendations can be found in COBIT (CobIT describes how an organization would work at different maturity levels for 34 essential processes, many of which are further elaborated within ITIL best practice areas^N).

To achieve this requires specific capabilities^N. Most prominent amongst these are Organizational Process Definition, necessary for the organization to retain the accumulated experience of knowledge workers in a structured context. Otherwise, the organization has difficulty institutionalizing and benefiting from shared knowledge - "Organizational process assets enable consistent process performance across the organization and provide a basis for cumulative, long-term benefits".

Process Modeling

Definition of Process

"A naturally occurring or designed sequence of operations or events, possibly taking up time, space, expertise or other resource, which produces some outcome. A process may be identified by the changes it creates in the properties of one or more objects under its influence."

Wikpedia

Definition of Process

"a connected series of actions, activities, changes etc., performed by agents with the intent of satisfying a purpose or achieving a goal. "

ITIL, Planning to Implement Service Management, Appendix B 1, Process Theory

Underscoring the concept of process is a theoretical premise - process theory which holds that if an outcome is to be duplicated, so too must the process which originally created it. There are certain constant necessary conditions for the outcome to be reached. This simple relationship can be extended to include additional relationships. Inputs determine (or, in statistical systems establish tendencies), which when followed by certain activities produce specific Outcomes.

A Process Model can be used to describe activities and their relationships. Process Models are graphical representations of existing or planned processes and can be used to understand what functions are performed and how those functions interact. A process represents an action or task that requires some amount of time to accomplish its objectives. A completed Process Model graphically depicts the specific steps, operations, and information needed to perform a process. Data enters the process, is processed, data comes out, the outcome is measured and reviewed. This very basic expression underlies any process description. The process model may represent as broad or as narrow a viewpoint as is required and may be refined further and into more detail. If several viewpoints are desired, separate models can be developed for each. Some characteristics of a process include:

A process is always organized around a goal. The main output of that process should be the result of that goal.
A process model will also describe the activities that exist within a business process.
A scope statement should set out, in broad terms, the content of the business process and the process model that exposes it.
The process model will define the required activities and set them into a logical sequence. This sequence is driven by the dependency of one process on the information that is provided to it by one or more other processes.

A process model can be developed to a very fine or very coarse degree of detail. The more precise the model, the more specific it becomes to a particular process as practised in one place. If it is less precise, it can be used with a high degree of generality.

Often information or materials produced in one process are used in others processes. The term "ICOM" is the acronym for the four possible roles relative to a process:

Input - data or material used to produce the output of a process.
Control - data that constrain a process. Controls regulate the transformation of inputs into outputs.
Output - data or materials produced by or resulting from the process.
Mechanism - people, machines, or existing systems that perform functions or provide energy to the process.
ICOM

In Planning to Implement Service Management, ITIL presents a somewhat more elaborate description of the ICOM approach. In their description Controls are specifically identified as either Goals and Objectives, values and characteristics associated with a champion or designated process owner and quality parameters including Key Goal and Performance Indicators. Mechanisms are defined as Resources and Roles. The generic process model

Elements of Good Process

It should be evident that there is general consensus around the importance of developing, documenting and maintaining process artifacts for IT service improvement. Without this capability it becomes exceedingly difficult to implement and then institutionalize IT service management gains. In addition to process flow charting, a good process description should contain the elements needed to sustain and improve. These have been described in CMMI as generic or institutionalization processes^R.

The following is a fairly exhaustive list of attributes that characterize the robustness of a process. In this sense, robustness refers to the resiliency and durability of a process to withstand abuse, enforce compliance, and be able to measure its effectiveness. The robustness of a process comes in degrees - the absence of a few of these characteristics doesn't mean that a process is weakly designed or poorly executed; however, in general, the more of these attributes that are present, the more robust a process is. Many of these are included in the following list of process elements.

The objective is identified. An early step in creating a robust process is to state its overall objective, document it, share it with all appropriate parties, and ensure that all process-design participants agree to it and clearly understand it. The objective should answer the questions of what problem the process solves, which issues it addresses, and how the process adds value and quality to the environment.
The executive sponsor is identified and involved. Each process needs to have an executive sponsor who is passionate about the successful design and ongoing execution of the process. This person provides support, resources, insight, and executive leadership. The executive sponsor arranges for any required participation or communication with other groups, either inside or outside the infrastructure. This individual is often the manager of the process owner.
The process owner is identified and given responsibility for and authority over the process. This person leads the team that designs the process, identifies its key customers and suppliers, and documents its use. The process owner executes, communicates, and measures the effectiveness of the process on an ongoing basis.
Key customers are identified and involved. Key customers are those individuals who are the immediate users and direct beneficiaries of the process. For example, suppose you're designing processes to request the restoration of a file or the resetting of a password. Key customers for these processes may be users who are most likely to request these services on a regular basis. Their involvement in developing the process is important to ensure practical design and ease of use.
Secondary customers are identified and consulted. Secondary customers are those that may use a process less frequently than primary customers or who may be the eventual rather than immediate beneficiaries of the process. Using the example in item 4 above, if administrative assistants are making the original requests for file restorations, then their managers are likely to be the secondary customers of the process. Their consultation can be helpful because they may be the ultimate users of the process.
Process outputs are identified. These are the specific deliverables or services that the process provides to the primary and secondary customers. Service metrics usually measure the quality of the delivery and the content of these outputs.
Process inputs are identified. These are the specific input entities that the process requires. They may take the form of soft inputs such as data, information, or requests, or they may be hard inputs such as floppy disks, tapes, or other physical entities.
Process suppliers are identified and involved. Process suppliers are the individuals who provide the specific inputs to a process. These suppliers may be:

internal to an IT infrastructure (for example, data entry departments)
external to an IT infrastructure but internal to IT (such as a development group entering change requests)
external to IT but internal to a company (for instance, an outside user group supplying report modification information)
external to a company (such as hardware and software vendors who may provide details about how an upgrade is to be performed)

The process is described by a sound business model. In simple terms, a robust process should make common business sense. The benefits of using the process should exceed the cost and efforts expended to design, execute, and maintain the process. The business side of a robust process sometimes involves leasing agreements, maintenance agreements, and service-level agreements.
Process hierarchy is understood. Some processes have secondary processes or sub-processes underneath them. Individuals who are developing well-designed robust processes know and understand the relationships between the primary and secondary processes.
Execution is enforceable. Almost any process, regardless of design, needs to be enforceable to be effective. Whenever possible and practical, software techniques such as passwords, authorizations, audit trails, or locks should enforce compliance with a process. When technical enforcement is not practical, management support, review boards, metrics, or other procedural techniques should ensure enforcement.
The process is designed to provide service metrics. Most processes measure something associated with their output. Often this involves a quantitative measure such as transaction processes per second or jobs completed per hour. In addition, a robust process focuses on qualitative measures that are oriented toward the end user. These metrics show the relative quality of the service being provided. ^N

Developing Robust Processes, Lightpointe, Nov 19, 2004

Process orientation is often a big change and demands commitment from the management. Without this commitment process orientation initiatives often fail to deliver the expected results. By centering ones attention on processes the focus is also transferred from the finished result to the activities forming them. Since the processes create the result, they are also the first things that have to be controlled and developed. By focusing on core elements, the process view can be applied on an all-embracing level in the organization, seeing the whole organization as one system. Looking at the organization as a system of integrated and interrelated processes is vital for this kind of thinking.^R.

I believe that process developing and maintenance is as important a process as any of the ITIL best practices areas. Therefore, I describe the underlying sub-processes which make it up under HCI processes. Access this process for further detail on implementing and sustaining process artifacts.

Maturity Frameworks

Process Implementation Issues