There are as many answers to "what is the value?" as there are to "what does documenting a process mean?"  In a previous article, I suggested three rules for process documentation.

1. It must provide immediate value.
2. An eight-year-old should be able to understand it.
3. It's reusable.

Documenting a process for the business means capturing enough information about the work to explain it to various audiences and have them understand where value is created.  A conversation about the process with the Process Owners is the best way to define a process' scope.  Discussions with Process Leads, Process Architects, and SMEs (subject matter experts) will clarify how the process interfaces with the other areas of the business.  It has often been stated that overall the operational performance of the individual processes, as they are defined in the Business Architecture, is relatively efficient.  The opportunities to create value and increase the efficiency of the overall process life cycle are very often in the handovers between processes.

Recording the Conversations

Figure 1 shows three different types of diagrams that can be used to record the conversations from working sessions to define and understand processes.

Figure 1.  Samples of Various Process Diagrams. 

In this three-part series of articles, we'll explore each of these and how their usage adds tremendous value to any organization wishing to improve its business performance.  Part 1 of this series covered the Hierarchy Diagram.  Part 2 explained the Context Diagram.  This concluding article will focus on the High-Level IGOE Diagram.

High-Level IGOEs (Inputs, Guides, Outputs, Enablers)

IGOE Diagrams capture the information, materials, knowledge, expertise, resources, and technology used by the business to provide value to stakeholders.

      Figure 2a.  IGOE Construct.

      Figure 2b.  High-Level IGOE.

      Figure 2c.  High-Level IGOE with Source & Destination.

IGOE is an acronym for input, guide, output, and enabler.   These are the four component categories of information required to completely understand any 'group of work' in an organisation.

The main purpose of the IGOE Diagram is to capture the answers to the five Ws (who, what, where, when, why) and how.  The clarity of understanding the process is enhanced by transforming the "Context Diagrams" into high-level IGOE Diagrams. 

Components of an IGOE (Inputs, Guides, Outputs, Enablers)

Inputs are defined as elements of the business that change or transform.  There are four types of transformation:  location transformation, state (information) transformation, physical transformation, and capability/skill/knowledge transformation.

Guides are the elements of the business that define:

• 'when' work occurs.
• Normally defined or captured as 'events'.
• Also used to help define boundaries for the work.
• "why" the work is performed.
• Normally captured as company policies, regulations, contract requirements, etc.
• "how" the work is performed.
• Includes all the work procedures (SOPs), established standards, industry standards, ISO standards and documentation, established best practice documentation, as well as discipline knowledge and practices.

Outputs represent the results of the change or transformation that occurs as the work is performed.

Enablers are the support mechanisms that allow the performance of the work.  Enablers include:

• people.
• Depending on the level of detail at which the 'work' is documented, this can be presented as Working Groups, Jobs, Roles, Functions, etc.
  
  
• technology.
• Normally captured as 'applications' used, i.e., SAP, MS-Office, or general technology such as storage mechanism, e.g., file cabinet.
  
  
• facilities.
• Documented only when not assumed as part of general knowledge or when critical to the 'work', such as a warehouse.
  
  
• any other 'resources' or 'assets' used in the performance of work not included in the 'normal' groups of enablers.

The IGOE Diagram will contain the same elements as the 'Context Diagram', with the added clarity of usage.

Once the discussions on process interfaces and the deliverables (information, data, materials, expertise, resources, and technology) to/from those processes are complete, the discussion extends to:

• understanding how the deliverables are used by the process,
• why they are needed,
• how they add value,
• how and why they are changed,
• adequacy of the technology, and
• capabilities of the resources.

1.  It must provide immediate value.

• is useful to people doing the work — 'fit for purpose'

The conversations regarding how the deliverables are used and why they are needed often also prompts the SMEs to remember other less obvious, but no less important, elements of the work.

• highlights "objectively" where the major pain points exist

Asking the questions concerning value-add of the deliverables of the process creates a more objective view of the work and often leads to the elimination of many deliverables.

• identifies clearly solvable problems

Focusing a large portion of the discussions on the "Guides" to the process often highlights redundancies and inefficiencies.

For example, a process that has 20-30 (or even 40) guides but has only 2-3 inputs and 5-10 outputs is a clear warning signal that the process may be encumbered with too many guides, the wrong guides, or redundant guides, a situation that can often be fairly easily corrected.

Figure 3.  Relationship between a Context Diagram, High-Level IGOE, and an IGOE with Interfaces. 

2.  It can be explained to an eight year old.

Kids do get it.  They don't necessarily understand its value but they can understand what it represents.  I've used the example of making a peanut butter and jelly sandwich to explain the concept.

3.  It's reusable.

The knowledge and understanding gained from creating the High-Level IGOE will be used as each activity is broken down and the IGOEs are created at the next level.  This will create integrity for the information used in the work as well as traceability through the flow as flow diagrams are created.  Every deliverable that exists at the process level must exist at the activity level.  The deliverable may be represented as a group of information at the process level and as individual reports at the activity level.

In addition, understanding the interfacing processes also helps clarify where value may be lost or problems are occurring.

Benefits

Figure 4.  Relationship between Hierarchy Diagrams, Context Diagrams, and High-Level IGOEs. 

A lot of time and effort will be spent collecting this information from the business experts so there needs to be an equivalent 'return on investment' for that effort.  There are numerous business benefits gained from documenting the conversations about the operations of the business in a consistent graphical format.

1. Information about the operations of the business can be easily compared and evaluated.
2. No time is lost trying to understand the notes taken during the workshops.
3. Use of a common language (common graphical format) increases understanding.
4. Use of a common language allows information to be easily shared across the business.
5. Gaps, inefficiencies, and opportunities are more readily identified.
6. Cross-process impact, risk, and value-add assessments are possible, with more confidence in the results.
7. Measurements and benchmarks have greater integrity.
8. Data usage and differences in vocabulary are immediately obvious.

Summary

The focus should always be on the business and the best method for capturing that information.  Graphical models are extremely useful for this purpose.

Capturing the conversations about the business, how it works and why, in a consistent but simple graphic format will deliver value-add results to the Process Owners and others working to improve the performance of the business.  As with any technique, too much detail detracts from the benefits.  Care should be taken to only capture the most relevant information.  The detailed information can be documented, when relevant, in other kinds of diagrams such as swimlane diagrams or some other kind of process workflow model.

It is about the Conversation not the Picture.

# # #