IGOE — Link to Decision Criteria
In my last column, I talked about the concept of IGOEs. In that piece, I explained the high-level concepts of each of the IGOE components: Input, Guides, Outputs, and Enablers. This time, I have selected just one element of the IGOE acronym, Guides. One question the guides help us answer about a process is "How do decisions get made?"
Unfortunately, most process documentation does not include the business rules or the decision criteria in a clear and discernible format. The majority of process documentation I encounter when working with organizations includes only about 50% of the "types" of information they need and potentially only 15% of the "knowledge" required for understanding and/or improving the process.
The typical process model will look like a "flow." It will have inputs and outputs, and occasionally some source and destination information like customers and suppliers. The graphical format of this information is normally a swimlane and/or a SIPOC diagram. For years people have assumed this was sufficient information to allow them to make decisions about changing and/or reacting to process/problems, analyzing and identifying problems and root causes, and defining requirements for automated systems.
This is quite simply not true. In addition to the "flow" information — inputs and outputs — we need the guides and enabler information. It is the guide category of information that has the strongest impact on process. This article will take a high-level look at guides and how they provide the data required to understand decision criteria and business rules.
Decision Criteria and Business Rules
Decision criteria and business rules are basically the same concept. Depending on the source of knowledge referenced, people will propose that the business rules provide our decision criteria while others will claim that business rules are derived from the decision criteria.
Regardless of the specifics, the most important part of all of this is that business rules and decision criteria, if not one and the same, are "very" closely related. From a Big Picture perspective, we need to understand how to find and use that information. When capturing process information, process guides are the source for business rules/decision criteria. Whether you consider information/knowledge to be tacit or explicit, both types should be included as guides. To understand the real potential for process improvement, the guides must be documented and understood.
Guides are defined as anything that describes the when, why, or how a process or activity occurs. Therefore, the events that determine when a process begins or when it ends are classified as guides, as well as all the policies, regulations, and any standards requirements. In addition, any reference information or data is considered to be a guide, as well as any knowledge or experience used to help determine how the process/activity should occur.
Some examples of Guides include:
- Any type of starting and completion events related to the process, such as receiving or sending things or information
- Any type of knowledge or experience needed to perform the activities in the process
- Business Policies
- Business Rules
- Acceptance / Completion Criteria
- Performance Targets
- Performance Criteria
- Laws or Regulations
- Any type of information used as reference material during the process
Applying the IGOE Template
Figure 1 is an example of an IGOE template.
Figure 1. IGOE Template
Recently, as I was helping a client with a data utilization project and the documentation of some of their processes, it occurred to me that the concepts they were really documenting were their business rules. They had just concluded a study of data-driven decision making in education processes. They wanted to document the decision-making process. We began by naming the process "Use Data" as shown in Figure 2.
Figure 2. "Use Data" IGOE Example
However, as we began to document the utilization of "Data" there was a realization that all the "Data" we were discussing were the "Rules" for making Decisions for several of their processes. As part of their study they had actually captured some really important information about how very important the data was to the organization's processes. The majority of the relevant decisions were made based on the data we were trying to document as a process.
Their study was actually one of the few occasions where I've seen an organization isolate the decision-making criteria and conduct such a thorough analysis of how decisions were made, how the integrity of the process was affected by the completeness of the data, and whether people actually knew how to use the data to make decisions. The process wasn't the "Use Data" process but the discovery of all the information necessary to make good decisions about many of their processes ... and especially one of their core processes, "Assess Learning." Finally, there was a realization that the information that they had gathered wasn't separate from the process at all, but it actually represented one of the major categories of information required to understand the "why and how" of the performance of many of their processes.
Figure 3. Assess Learning — IGOE
Figure 4. Process Architecture — Education Processes
When understanding and capturing information about how work gets done in any organization — whether a business or an educational organization — it's very important to realize what the information indicates and the best way to use that information. Many organizations miss major opportunities to improve the performance of the work/processes because they either don't have all the information that's important or they don't know how to use that information. Decisions and decision quality are one of the most important aspects of improving process but it is too often overlooked or misinterpreted.
By understanding all the components of a process — the IGOEs (Inputs, Guides, Outputs, and Enablers) — major improvements can be made to the performance of the process. In fact, just understanding and changing the guides has reduced the cycle time of some processes from as much as fifteen days down to forty-five minutes, or from ten days down to two days. Very rarely do organizations realize that kind of improvement from automation.
My next article will examine in more depth how business rules can be extracted from the guides and how all of that information can be aligned and traced through all the processes that use it, creating "one view" of the rules and how processes provide value to an organization.
# # #