World-class infrastructures boast robust (well-designed) processes for maximum effectiveness. Take a look at these 24 characteristics of a robust infrastructure process.
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.
- Process objective identified
- Executive sponsor identified and involved
- Process owner identified; given responsibility for and authority over the process
- Process inputs identified
- Process suppliers identified and involved
- Key customers identified and involved
- Secondary customers identified and consulted
- Process outputs identified
- Process is described by a sound business model
- Process hierarchy is understood
- Execution is enforceable
- Designed to provide service metrics
- Service metrics recorded and analyzed, not just collected
- Designed to provide process metrics
- Process metrics recorded and analyzed, not just collected
- Documentation is thorough, accurate, and easily understood
- Process contains all required value-added steps
- Process eliminates all non-value-added steps
- Process guarantees accountability
- Process provides incentives for compliance, and penalties for avoidance or circumvention
- Process is standardized across all appropriate departments and remote sites
- Process is streamlined as much as possible and practical
- Process is automated wherever practical but only after streamlining
- Process integrates with all other appropriate processes
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:
- 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
- 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.