Deming, IT, and BPM IDEF0 Diagrams

Here's an article that first appeared in April of 2009 and that is interesting enough that I thought I might repeat it.

As the executive editor of BPTrends, I get to read lots of articles by authors from diverse backgrounds. I enjoy the opportunity to learn new things and find out about alternative ways to conceptualize process changes opportunities or to approach process problems.

I've long been impressed by the fact that there are significantly different approaches to process change. The three traditions that I encounter most frequently: The Quality/Six Sigma/Lean tradition, the IT tradition, and the Business Management tradition. [1 Individuals from each of these traditions are likely to put a slightly different spin on the common problems that all process professionals face. I especially enjoy it, however, when I find that individuals from the different traditions have arrived at the same solution without realizing it.

In a book review I wrote for this month's issue of BPTrends, I discuss how James Womack and Daniel Jones' Lean Solutions focuses on the idea of starting an analysis of service business problems by analyzing the steps that the customer goes through as he or she interacts with an organization. Womack and Jones describe what the customer does by means of a “consumption map.” Roger Burlton and I, operating largely in the business management tradition, have been talking of describing what the customer does by defining the “customer's process” using an approach based on Rummler-Brache diagrams. The key, however, is that we have arrived at a similar approach from two slightly different perspectives.

Something similar happened in a recent class that I taught when a student asked me about “The Deming Process Workbench.” I frankly admitted I'd never heard of it, but would investigate online that evening and see what I could say about it the following day.

When I sat down to investigate I quickly discovered that the term had not originated with Deming himself. Nor is the term listed in Juran monumental compendium of quality control technologies – Juran's Quality Control Handbook. I found a couple of papers on the Deming Process Workbench and it turns out that it was created by Tim R. Norton, who, in the mid-Nineties, worked for MCI Telecommunications. [2] Norton explained that his specific diagram was derived from a simpler diagram developed and used by the Quality Assurance Institute (QAI) in 1986.

The Deming Process Workbench Model, as described by Tim Norton and Larry Kayer in a paper presented by Linda Boyd at a SHARE conference in 1995, is pictured in Figure 1. In essence, the “workbench” is a template that users fill in to provide a more detailed description of a process. Each of the boxes on the sides can end up with lots of detailed information.

Figure 1. Norton’s Deming Process Workbench Model

The minute I saw the Deming Process Workbench model I realized, of course, that it had its roots in an older model which came from the IDEF (ICAM DEFinition, which later became Integrated DEFinition) methodology created for the US Air Force in the mid-1970s. [3] IDEF was initially created to help the US Air Force with Integrated Computer Aided Manufacturing (ICAM) projects. IDEF was a suite of models and procedures. The initial phase of the methodology was termed IDEF0, and was designed to elucidate the function of the process to be analyzed and improved. IDEF was still used by the DoD in the Nineties, when Business Process Reengineering was popular, and was gradually transformed from an ICAM methodology to a Structured Analysis and Design Technique (SADT), and then into to a process analysis methodology. [4] Some of its models, which include not only IDEF0, but IDEF1, IDEF2, IDEF3 …to IDEF14, are still used while most have disappeared. The basic IDEF0 model is pictured in Figure 2, as it is typically pictured in the IDEF literature.

The essence of an IDEF0 model is that it allows us to initially ignore what goes on within a process and to focus on how the process interfaces with the world around it. Equally important, an IDEF0 allows us to discriminate between four types of interfaces:

Inputs from people or other processes,
Outputs to people or other processes,
Interactions with sources that control the process, and
Interactions with mechanisms that enable the process.

The relationships between upstream processes, the process-in-scope, and downstream processes are well understood and easily represented in a typical SIPOC or flow diagram. What individuals using simple flow diagrams often miss, however, are the horizontal interfaces. They too often ignore policies, business rules, and management constraints (usually generated by management processes) that control or constrain the activities within the process. Similarly, they too often ignore the processes that enable the process-in-scope, including HR processes that provide the employees that actually do the work, IT processes that provide the software applications that respond to requests from employees, or infrastructure enablers like equipment or facilities. IDEF makes a point of emphasizing that Inputs are transformed to Outputs, but that the Controls and Mechanisms are only used during the transformation, but are not consumed. Controls (rule books) and Mechanisms (employees and software applications) can be used over and over again.

IDEF0, in its initial form, isn't used too much today, but there are other popular diagrams that are derived from it. One is what is often referred to as the Eriksson-Penker Business Extensions that were created by the authors to extend the OMG's UML software modeling notation (via a stereotype) to make it more business friendly. Hans-Erik Eriksson and Magnus Penker did this in the book they published in 2000, Business Modeling with UML: Business Patterns at Work. [5,6]

Figure 3 shows how a Eriksson-Penker UML business extension might represent a business process.

Figure 3. A Eriksson-Penker business diagram in UML

The other extension of the IDEF0 approach was developed by Roger Burlton and consultants at Process Renewal Group (PRG) in the same timeframe. Burlton termed his variation of IDEF0, an IGOE diagram (Inputs, Guides, Outputs, Enablers) and created a methodology that combines IDEF0 and Ishikawa root cause analysis to provide business users with a good way to analyze the problems they face when they try to improve a given business process. Burlton's approach has been incorporated in the BPTrends Redesign Methodology which he and I are involved in developing, and has become one of the main tools that we rely on for both process scoping and problem analysis. [7] Figure 4 illustrates a Burlton IGOE diagram.

Burlton's IGOE diagram goes well beyond simply identifying the four interfaces. This is only the initial step. Process work usually begins when an executive asks that a specific process be improved. That is termed the process-in-scope and is entered in the box in the center of the IGOE. Once external people or processes are identified, users proceed to identify the nature of the exchanges and then to interview stakeholders on both sides to determine how satisfied they are with the exchanges. The exchanges are labeled and rated as satisfactory or unsatisfactory. At the same time we determine the measures that stakeholders use to evaluate the exchanges. Finally, users draw a new border to show what elements will need to be included in a project that is designed to significantly improve the process-in-scope. Sometimes the new border simply encloses the process-in-scope, but in other situations it includes processes making inputs, guidance rules, support processes or processes accepting outputs. The analysis work that goes into creating the IGOE often reveals that processes outside the initial process-in-scope will need to be changed to achieve the improved performance that management desires (as the diagram in Figure 4 proposes to incorporate a delivery activity into the project scope). IGOE's are sometimes documented formally, but they are as often created on a whiteboard to allow a team of business managers and employees to participate in the discussion and analysis that does into creating the IGOE.

If we step back from the specifics, we see that a single idea, originated by a team of IT software analysts, who developed IDEF0 in the mid-Seventies, has been successively adopted and used by process practitioners operating in different traditions. The impulse behind the initial IDEF0 was to extend the process interfaces that teams examined when they define a process. It provided a better way to represent the role of rules and constraints and support processes in a typical flow, and it emphasized the idea that one should begin by understanding how a given process interfaces to its environment.

In the Nineties, one author (Norton) working in the Quality Control tradition at MCI, shaped the diagram into a “workbench” to capture information while focusing on quality issues that would lead to inputs or outputs failing to meet quality standards. Another set of authors (Eriksson and Penker) shaped the IDEF0 diagram into a set of extensions for the UML software notation that would let UML software developers model business situations that captured not only flow, but goals, constraints and support processes. Finally, during the same period, Burlton, a well-known methodologist working in the business management tradition, reworked the IDEF0 idea to make it into a powerful tool that can facilitate business discussions of process problems and the scoping of process improvement projects.

I'm confident that each of these authors worked independently and derived their ideas from the simple, original IDEF0 diagram. Each then elaborated the basic idea to help practitioners working in their particular tradition to capture and model information they needed to solve the specific types of process problems they faced.

To answer my student's question: a Deming Process Workbench is a way of modeling a process that emphasizes the interfaces between a process and its environment, and puts a special emphasis on quality control issues. It is one of a class of models that all relate to an approach to modeling developed in the mid-Seventies that is termed IDEF0.

The existence of a class of related models reflects the fact that there are several different approaches to analyzing process problems and modeling processes. Each of the different models emphasizes slightly different aspects of common problems that all process practitioners face.

Increasingly, in the years ahead, as process emerges as a unified field and practitioners become familiar with the practices of other groups of process practitioners, we will find that we have developed a wide variety of techniques to achieve similar purposes and we will benefit from the different uses that different groups have derived from similar approaches.

Notes

See the BPTrends Advisor of January 27, 2009 for a more extended discussion of the three process traditions.
Norton, Tim R. and Larry R. Kayser. “The Deming Process Workbench: An Application at MCI.” (Paper presented at SHARE, Summer 95 as Session 1851. Presented by Linda Boyd.) Available on line at www.simalytic.com/SHARE85/1851.PDF
IDEF is currently maintained by the Computer Systems Lab of the National Institute of Standards and Technology (NIST) and is documented in FIPS Publication 183. See www.itl.nist.gov/fipspubs/idef02.doc
For an introduction to IDEF0 for business process practitioners, see Clarence G. Feldmann's book: The Practical Guide to Business Process Reengineering Using IDEF0. (Dorset, 1998)
Eriksson, Hans-Erik and Magnus Penker. Business Modeling with UML: Business Patterns at Work. (Wiley, 2000).
For a nice discussion of UML and IDEF that includes a discussion of the Eriksson-Penker model, read the paper by Ovidiu S. Noran: “Business Modeling: UML vs. IDEF. ” (Griffith University, 2000) Available on line at www.cit.gu.edu.au/~noran
For an overview of Burlton's IGOE model, see Roger Burlton's book, Business Process Management: Profiting from Process (SAMS, 2001) or Paul Harmon's book, Business Process Change (2nd Ed) (Morgan Kaufmann, 2007).

PDF Version

Bio
Latest Posts

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of BPTrends Associates, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in Las Vegas. Paul can be reached at pharmon@bptrends.com