Part II: Our Insight and Advice on Business Processes: Process States and Methods

(initially published on EFA on March 31, 2011, as “Our Insight and Advice on Business Processes”, republished here, as the second part of a four-part series;  part of the retrospective Above Average: The Best of Escape from Averageness, 2009-2012)

 

Our proposition regarding processes is very simple:  The way an enterprise creates value on behalf of its customers is mainly through the work that it does, and the way an enterprise performs the resulting workflow is largely through its processes.

For us, understanding workflow is a means to an end.  It is the front-end of a problem-solving methodology, in which we first eliminate the activities, reports, inspections, and other work that is waste (muda), and, therefore, adds no value, and then make the remaining value-adding activities flow more smoothly, more directly.  In our way of explaining production principles, using the analogy of a pipeline, we want a process that is a shorter, straighter pipe.  It is a way of simplifying and streamlining processes, so that our clients can deliver more value from what remains, with the same amount of capacity.

Understanding workflow also tends to clarify the underlying problems and issues, for example, the variation and uncertainty that haunts any production system.  When process workflows are connected to performance measures – to existing performance and targeted performance – clients can start to understand the requirements and necessary conditions that have to exist for the process to be improved.

For the most part, we like to look at the current (AS-IS) state of a process through the lens of cross-functional flowcharting teams, comprised of the people who actually perform the work in the process;  management, we like to remind our clients, at best, only knows how a process is supposed to work.  In the past, we would also use cross-functional flowcharting teams to redesign the same process to reflect its desired future (SHOULD-BE) state, because it made comparisons between previous and redesigned states of a process more insightful;  and, it does make the difference between AS-IS and SHOULD-BE more stark.

We like the starkness.  Now, however, we tend to get to the point more quickly.  We tend to use IDEF process modeling in the design/redesign phase, and we almost always document processes in IDEF notation, the most common version of which is known as IDEF0.  For continuity, and to take advantage of the insight gained mapping the current state, we use the same cross-functional teams for the SHOULD-BE that we used in the AS-IS; we just use a different methodology.

The advantage of IDEF0 lies in the ability of its hierarchical structure of graphic diagrams and supporting text diagrams to gradually and infinitely reveal increasing levels of process detail.  Unlike cross-functional flowcharting, SIPOC charts, or value stream mapping, IDEF0 process modeling does not impose a single level of process detail;  the level of detail is whatever is necessary to create the understanding.  As a result, IDEF0 presents a far better learning/training outcome than flowcharting, SIPOC, or value stream mapping.

There are additional advantages to using IDEF0 for designing and documenting the desired future state of a process. Unlike other methods, IDEF0 establishes parameters and outcomes as part of the process design. More importantly from a process design/redesign standpoint, IDEF0 does not carry the legacy – the burden – of the current state, as other methods tend to do.

I would be glad to send, any reader who requests it, the client tutorial we wrote explaining IDEF0 process modeling.

Process design, improvement, and documentation is only half the battle.  There still has to be a way to manage process workflow.  The inability to provide clients with a practical means of automating and managing processes has tended to be a shortcoming of Business Process Improvement (BPI) and Business Process Management (BPM).

There is an emerging standard known as BPMN, (Business Process Modeling and Notation), the promising aspect of which is the ability to automate and manage process steps through execution language.  Some require code to be written, others claim not to require additional code-writing.  The current version (2.0) is more open source and supported by OMG.  The common execution languages that BPMN uses are BPEL, XPDL, and XML.  The significance is that these types of applications extend process design, improvement, and documentation into process management and automation.  BPMN offers the prospect of process management and automation for the everyday business world.  Like IDEF process notation, BPMN uses a hierarchical, parent-child structure of processes and embedded sub-processes.

Since most of our clients are homebuilding companies, the benefit of automating processes is of less importance than industry verticals that have high-transaction volumes and high-IT components.  For our clients, we would prefer to have whatever automation is needed built into the operating system that supports the process workflow, not the other way around.

Moreover, homebuilding companies, as I said earlier, have to be concerned with project management, not just process management.

 

Next:  Part III:  Recommendations