By Rich Schiesser, in conjunction with Harris Kern’s Enterprise
Computing Institute

One distinction that separates world-class infrastructures
from those that are just marginal is the robustness of their processes. In this
article, we examine how to develop robust (well-designed) processes for maximum
effectiveness. What does it mean for a process to be truly robust and what
characteristics are inherent in such a process? Here’s a list of the 24 of the
most common attributes of a robust process. We’ll discuss each one in detail.

  1. Process
    objective identified
  2. Executive
    sponsor identified and involved
  3. Process
    owner identified; given responsibility for and authority over the process
  4. Process
    inputs identified
  5. Process
    suppliers identified and involved
  6. Key
    customers identified and involved
  7. Secondary
    customers identified and consulted
  8. Process
    outputs identified
  9. Process
    is described by a sound business model
  10. Process
    hierarchy is understood
  11. Execution
    is enforceable
  12. Designed
    to provide service metrics
  13. Service
    metrics recorded and analyzed, not just collected
  14. Designed
    to provide process metrics
  15. Process
    metrics recorded and analyzed, not just collected
  16. Documentation
    is thorough, accurate, and easily understood
  17. Process
    contains all required value-added steps
  18. Process
    eliminates all non-value-added steps
  19. Process
    guarantees accountability
  20. Process
    provides incentives for compliance, and penalties for avoidance or
    circumvention
  21. Process
    is standardized across all appropriate departments and remote sites
  22. Process
    is streamlined as much as possible and practical
  23. Process
    is automated wherever practical but only after streamlining
  24. Process
    integrates with all other appropriate processes

Objective identified

The overall objective of the process needs to be stated,
written down, shared with all appropriate parties, and agreed to and clearly
understood by all process design participants. The objective should answer the
questions of what problem the process will solve, which issues it will address
and how it willadd value and quality to the environment.

Executive sponsor identified and involved

Each process needs to have an executive sponsor who is
passionate about its successful design and ongoing execution. This person
provides support, resources, insight, and executive leadership. Any required
participation or communication with other groups, either inside or outside of
the infrastructure, is typically arranged by the executive sponsor. This
individual is often the manger of the process owner.

Process owner identified; given responsibility for and authority over the
process

This person will lead the team that designs the process,
identifies the key customers and suppliers of it, and documents its use. On an
ongoing basis the process owner will execute, communicate, and measure the
effectiveness of the process.

Key customers 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 reprint of a report or the restoration of a
file. 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 identified and consulted

Secondary customers are those who may use a process less
frequently than primary customers or they may be the eventual rather than
immediate beneficiaries of the process. In the above example, if administrative
assistants are making the original requests for reprints or restorations, their
managers are likely to be the secondary customers of the process. Their
consultations can be helpful since they may be the ultimate users of the
process.

Process outputs identified

These are the specific deliverables or services being
provided to the primary and secondary customers. The quality of the delivery
and content of these outputs is usually measured with service metrics.

Process inputs identified

These are the specific input entities required by the
process. They may take the form of soft inputs, such as data, information, or
requests, or they may be hard inputs, such as diskettes, tapes, or other
physical entities.

Process suppliers 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, such as data entry departments. They may be external to an IT
infrastructure but internal to IT, as with a development group inputting change
requests. They may be external to IT but internal to a company, as with an
outside user group supplying report modification information. Process suppliers
may also be external to a company, such as hardware and software vendors who
may provide details about how an upgrade is to be performed.

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 (SLAs).

Process hierarchy is understood

Some processes have secondary processes, or subprocesses, underneath them. Individuals who are
developing well-designed robust processes know and understand the relationships
between the primary and secondary processes.

Execution is enforceable

Most any process, regardless of design, needs to be enforced
to be effective. Whenever possible and practical, software techniques such as
passwords, authorizations, audit trails, or locks should be used to enforce
compliance with a process. When technical enforcement is not practical,
management support, review boards, metrics, or other procedural techniques
should be used to ensure enforcement.

Designed to provide service metrics

Most processes measure something associated with its output.
Often it involves a quantitative measure, such as transactions processes per
second or jobs completed per hour. In addition to these, a robust process also
focuses on qualitative measures that are oriented toward the end user. These
metrics show the relative quality of the service being provided.

For example, service metrics involving a report delivery
process may include not only how often the report is delivered on time, but
also whether it was delivered to the right individual, in the correct format,
with accurate content, and on the proper media. Service metrics should measure
the benefits of the process to the end users in their own terms. The metrics
should be customer-oriented and focused on measuring the right thing; in a
word, these metrics should exhibit effectiveness.

Service metrics compiled and analyzed, not just collected

Mediocre infrastructures often invest a fair amount of time,
energy, and cost in collecting and compiling metrics but do little to analyze
them. The real value of meaningful measurements comes from thoroughly and
consistently examining them for trends, patterns, and relationships and then
applying the results of the analysis to improve the effectiveness of the
particular service being measured.

Designed to provide process metrics

Robust processes not only have service metrics associated
with them but process metrics as well. The key difference between a service
metric and a process metric is that a service metric focuses on how effective a
process is in regard to a customer, while a process metric focuses on how
efficient a process is in regard to a supplier.

A process metric indicates the productivity of a procedure
by measuring such things as resources consumed and cycle times. The frequency
that reports are delivered on time is a service metric since it measures the
result of the process. The number of times the report had to be reprinted to
obtain acceptable quality is a process metric since it measures the amount of
effort required to produce the end product. Abnormal ending of job processing,
rerouting of problems, rerunning of jobs, reprinting of reports, and restoring
of files are common examples of process metrics.

This characteristic reinforces
the notion that process metrics should be supplier-oriented and focused on
measuring the entity right rather than measuring the right entity. In a word,
these metrics determine efficiency. Here’s a summary of the differences between
service and process metrics:

Service metric

  • Focuses on the customer
  • Measures levels of effectiveness
  • Deals with the quality of output
  • Examples include system availability; response
    times; accuracy of content; on-time delivery; network access; and database
    integrity

Process metric

  • Focuses on the supplier
  • Measures levels of efficiency
  • Deals with the quality of input
  • Examples include job and transaction throughput;
    elapsed cycle times; quantity of resources consumed; abnormal job terminations;
    and rerouting of problems; reruns, reprints, restores

Process metrics compiled and analyzed, not just collected

Just as service metrics need to be compiled and analyzed, so
also do process metrics. The importance of analyzing missed process metrics is
often overlooked when the associated service metrics are met. This could be the
case in terms of a service metric involving output delivery being met even
though numerous reprocessing of the job and its output were required. As with
service metrics, the real value of meaningful process metrics comes from
thoroughly and consistently examining them for trends, patterns, and
relationships and then applying the results of the analysis to improve the
efficiency of the particular service being measured.

Documentation is thorough, accurate, and easily understood

Documentation is one of the fundamentals that clearly
separate mediocre infrastructures from truly world-class ones. Well-written
documentation facilitates the training, maintenance, and marketing of key
processes. Progressive shops hold appropriate staffs accountable to reading and
understanding key documentation by making it part of their performance reviews.
These shops also have new employees test the clarity and readability of the
writing while ensuring that senior analysts and technical leads have validated
the accuracy of the material. Thorough documentation eases the tasks of
verifying that all required value-added steps are present and that all
non-value-added steps have been eliminated.

Effective documentation can come in various forms and can be
evaluated in various ways. Some of these forms include online and hardcopy
narrative procedures, diagramed illustrations such as flowcharts or bubblecharts, and Web-enabled help menus.

Process contains all required value-added steps

Using a legal analogy, value-added steps are to a robust
process as truths are to a credible witness’s testimony. The process should
contain the value-added steps, all of the value-added steps, and nothing but
the value-added steps. Two key attributes of a robust process are those of
effectiveness and efficiency. Process effectiveness means that all existing
steps are adding value to the result. Key customers, suppliers, and process
owners should meet prior to and after development of the documentation to
identify all value-added steps and to ensure they are all appropriately
inserted within the final process.

Process eliminates all non-value-added steps

If a step is not directly contributing value to the overall
objective of the process, it should be eliminated. This attribute is critical
to eventually automating the process. Two activities are required to completely
eliminate all non-value-added steps. First, all steps in a process, regardless
of how small and even if previously undocumented, need to be identified. This
comprehensive list of the exact steps of a procedure is commonly referred to as
the informal process. Second, an extremely critical evaluation of each of these
steps needs to be conducted with an eye toward eliminating any steps not
directly contributing to the desired output of a process.

Process guarantees accountability

Process metrics, performance charts, and trending reports
should be used to quickly identify when a department or an individual is not
following the prescribed procedure, with direct feedback to, and consequences
from, management. For this to work, the process designers and owners need to
provide management with sufficient tools to carry out their enforcement.
Management, in turn, needs to follow up with fair, timely, and appropriate
actions to ensure process compliance in the future.

Process provides incentives for compliance, and penalties for avoidance or
circumvention

One of the most effective incentives for compliance is
efficiency. If going around a process
takes more effort and a longer time than going through it, most employees will follow the shortest and simplest
path and use the process. The challenge is to remove the obstacles normally
associated with using a process, and to insert roadblocks for circumvention.
Properly streamlining and then automating a process can encourage its use.
Security measures, such as passwords and locks, and management measures. such as exception reports and accountability, can discourage
circumvention.

Process is standardized across all appropriate departments and remote sites

Some processes may have been developed at different remote
sites at different times and consequently have slightly different standards of
implementation. For example, one of my clients had an older change management
process at a remote site based on an e-mail system and a newer version at the
central site based on an Access database system. Before either process could be
optimized, an agreed standard needed to be reached, which it was. Nonstandard
processes often came into play as a result of acquisitions, mergers, or
takeovers. Implementing an agreed-upon standard is often a much easier
technical challenge than the more difficult political challenge of actually
reaching consensus.

Process is streamlined as much as possible

Streamlining a process involves
removing all non-value-added steps, eliminating redundant steps, placing the
steps in the most efficient sequence possible, and streamlining individual
steps as much as possible. For long-established processes, this may be
difficult to accomplish due to users being deeply entrenched in inefficient
practices. Three of the most common responses to the question of why a
particular process cannot or should not be changed are:

  • “We’ve always done it that way.”
  • “It seems to work most of the time so why bother
    changing it.”
  • “Analyst X designed this process and only he or
    she can change it.” (even after analyst X has left the department)

These explanations are not adequate justifications for
keeping a process the same when improvements through streamlining are clearly
warranted. Once non-value-added steps are removed, streamlining should proceed
by eliminating redundant steps, placing the steps in the most efficient
sequence possible and streamlining individual steps as much as possible.