Arming Yourself with Bullet-Proof Processes

The best defense of an IT infrastructure often involves having an effective offense. Understanding how to create, implement and manage bullet-proof processes leads to one of the most potent offenses an infrastructure professional can employ.

The following 14 steps describe how infrastructure professionals can design, install and maintain highly effective processes in support of any of the functions associated with IT operations management.

1. Objective is 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 the process will add value and quality to the environment.

2. 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. 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.

3. Process owner is identified and given responsibility for and authority over the process. This person leads the team that designs the process, identifies the key customers and suppliers of it, and documents its use. The process owner will execute, communicate, and measure the effectiveness of the process on an ongoing basis.

4. 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 are 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.

5. Process inputs are 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.

6. Process outputs are 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.

7. 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 (a development group inputting change requests)

• External to IT but internal to a company (an outside user group supplying report modification information)

• External to a company (hardware and software vendors who may provide details about how an upgrade is to be performed)

8. Execution is enforceable. Almost any process, regardless of design, must 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.

9. 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 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; that is, these metrics should exhibit effectiveness.

10. Service metrics are compiled and analyzed, not just collected. Mediocre infrastructures often invest a fair amount of time, money, and energy to collect and compile metrics; then they do little to analyze them. The real value of meaningful measurements comes from thoroughly and consistently examining these metrics for trends, patterns, and relationships and then applying the results of the analysis to improve the effectiveness of the particular service being measured.

11. Process is designed to provide process metrics. Robust processes have not only 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 regards to a customer, while a process metric focuses on how efficient a process is in regards to a supplier.
A process metric indicates the productivity of a procedure by measuring such things as resources consumed or cycle times. The frequency of on-time delivery of reports is a service metric because it measures the end result of the process (which is what the customer gets). The number of times the report had to be reprinted to obtain acceptable quality is a process metric because it measures the amount of effort required to produce the end product. Common examples of process metrics include abnormally ending job processing, rerouting problems, rerunning jobs, reprinting reports, and restoring files. 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 other words, these metrics determine efficiency.

12. Process metrics are compiled and analyzed, not just collected. Just as service metrics need to be compiled and analyzed, so 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 the job and its output had to be reprocessed numerous times. As with service metrics, the real value of meaningful process metrics come 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.

13. Documentation is thorough, accurate, and easily understood. Documentation is one of the fundamentals that clearly separate mediocre infrastructures from those that are truly world-class. Well-written documentation facilitates the training, maintenance, and marketing of key processes. Progressive shops hold appropriate staffs accountable for reading and understanding key documentation by making it part of their performance reviews. These shops also have their 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. Effective documentation can come in various forms including online and hard-copy narrative procedures, diagramed illustrations such as flowcharts or bubble charts and Web-enabled help menus.

14. 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. Here are three of the most common responses we get when we ask why a particular process cannot or should not be changed.

. 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 can change it. (We hear this last response 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: Eliminate redundant steps, place the steps in the most efficient sequence possible, and streamline individual steps as much as possible.