Archive for March, 2011

Our Insight and Advice on Business Processes

Posted March 31, 2011 By Fletcher Groves

Those of you who know me, know that I rarely promote the capability of SAI Consulting on the pages of this weblog. On this matter, I need to make an exception, because advice offered is different than opinion or viewpoint, and advice offered carries with it a requirement to submit evidence that assures readers that the advice-giver knows something of what he is talking about.

So, here it is: Flat-out, SAI Consulting is the homebuilding industry’s leading expert, when it comes to the documentation, analysis, measurement, design and redesign, improvement, and management of operating and business processes.

It is our tour de force.

It is the area for which we are most recognized. Virtually every consulting engagement we have ever accepted, in-or-out of homebuilding, has dealt – in some way – with how a client should structure itself around its core-critical business processes.

So, I am more than willing to provide the readers of this weblog the same insight and advice we regularly offer others on matters of process, particularly process mapping.

There is a reason for the centrality of business processes. When you talk about an enterprise, whether it is a homebuilding company or a company in some other industry vertical, the most basic proposition of that enterprise – the reason for its existence, the way it makes money – is through the value that it delivers to customers and other stakeholders. That value is only delivered by the work that the enterprise performs, and that work has to be performed in processes.

Those processes exist, whether enterprises are intentional about them or not. Processes are important. They are critical.

Start with some distinctions and some clarifications.

First, there is a difference between process management and project management. In addition to processes, most business enterprises today involve the scheduling and management of projects, to the point that many companies are now becoming project management organizations. It is a term that is particularly relevant in homebuilding, because jobs are essentially projects. Homebuilding is essentially multi-project management; it is project portfolio management with embedded processes.

Second, there is a distinction between procedures, processes, and value streams. They serve different, but related, purposes, and, although there is an ascending order to the relationship between them, they are not interchangeable expressions of workflow.

Third, there is a distinction between processes and areas/functions/departments. The functional perspective is vertical, a picture of departmental silos, in which everything associated with a department is contained within its own walls. Processes present a horizontal perspective of work flowing through an enterprise, across areas, departments, and positions. You do not “map” the accounting function, you “map” the accounting processes.

Finally, processes – like everything else – must fit within a context at the business enterprise level, as part of the business operating model. That context must be clear, it must be understood, it must be unified.

With that being said, the term “process mapping” encompasses a lot. It invariably includes the flowcharting of process workflows, but it could go well beyond flowcharting. A project will typically focus on a specific process approach or method for documenting processes that is aligned with a particular improvement methodology; Six-Sigma prefers to document processes in SIPOC charts, Lean likes to use value stream maps, etc. IT has its own quirks. Consultants often determine the methodology, and the methodology often determines the definition.

At SAI, when we use the term “process mapping”, it includes more than documenting the current workflow of a process. Most of the time, it also includes redesigning workflows, which invariably leads to other issues. Because it is so foundational, it is difficult to get around the need to understand and improve – and change – the way work is performed, before starting down the road on other change or improvement initiatives.

As I said, 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 only way an enterprise performs that work is 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 IDEF 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 charting, or value stream mapping, IDEF 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, IDEF presents a far better learning/training outcome than flowcharting, SIPOC, or value stream mapping.

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

I would be glad to send, any reader who requests it, the client tutorial we wrote explaining IDEF 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 2.0, (Business Process Modeling 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 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.

As for book recommendations, there is no single, comprehensive reference or guide to all of the areas of process improvement and documentation. At SAI, much of what we know, we learned by doing, by seeing what worked – and what did not work – in the real world.

Having said all of that, here are my book recommendations:

For processes generally, I still think “Business Process Improvement” (Harrington) and “Beyond Reengineering” (Hammer) are the best. Although there is a newer handbook, Harrington is now dated because of its TQM approach, but it is a process classic. Hammer, although also dated, still has the best understanding of enterprise-level processes, if you set aside the focus on reengineering.

Depending on your level of experience and expertise, you might also pick up “The Horizontal Organization” (Ostroff) or “Process Redesign” (Tonner, DeToro). They are not great books, but they can help, if you are new to process improvement.

For process mapping, I generally recommend “The Basics of Process Mapping” (Damelio), “Process Mapping: How to Reengineer Your Business Processes” (Hunt), “Workflow Modeling” (Sharp, McDermott), “Process Mapping, Process Improvement, and Process Management” (Madison), and “BPMN Method and Style” (Silver). Damelio covers very basic flowcharting, Hunt covers IDEF0 process modeling, Sharp has more of an IT and project perspective, and is better on implementation issues, Madison is a good practical guide in all three areas in its title, while Silver does a nice job of explaining BPMN as an emerging standard.

Somewhere in between are books like “Improving Performance: Managing the White Space on the Organization Chart” (Rummler, Brache), “Cycle Time Reduction” (Harbour), and “Fast Cycle Time” (Meyer). These books tend to focus on both processes and process mapping, but usually in the context of their own views and methods on areas like strategy and change management. They are older books.

Almost every book ever written about process design, analysis, and documentation is in the SAI library, including all of the ones that I recommended. I have personally read all of them. There are some newer books that I have not had a chance to read. The recommendations are not a comprehensive list, nor are they the only worthwhile reading on the subject, but I do think it is a good starting point. In any event, they are the best recommendations I can offer.

As far as process software, we use and recommend the iGrafx ( suite of process applications. We are an iGrafx Consulting Partner, not a reseller. iGrafx applications support a wide range of process methodology, including basic flowcharting, cross-functional flowcharting, BPMN, IDEF0 process modeling, Six-Sigma (SIPOC) process documentation, Lean Six Sigma, and Lean Value Stream Mapping (VSM).

I will offer you a couple of final suggestions:

First – most of the value we are attempting to create for “customers” (customers, clients, constituents, etc) is created by the work flowing through processes, so, wherever possible, the other elements of the business operating model (systems, organizational structure, employees, culture, etc) should support process design, not vice versa.

Second – knowledge of process design and process documentation is one matter, knowledge of process management is something altogether different. In addition to the process areas, a working knowledge of management areas like Six Sigma, Lean Manufacturing, and Theory of Constraints – and how to blend them – is essential when it comes to good process management. As I previously suggested, a process management interface – a tool that automates and manages processes – may or may not be important, depending on your situation; process automation is not as important in homebuilding, as it is in other industries and disciplines.

Third – as I mentioned at the outset – you need to be able to distinguish (and operate effectively) between the areas of process management and project management. In particular, you would find a knowledge of Critical Chain Project Management (CCPM) helpful; CCPM is part of the Theory of Constraints.

NOTE: As I noted earlier, I rarely plug SAI on the pages of this weblog. However, SAI has done more work with processes – and done it longer – than anyone in the homebuilding industry. Before the creation of the National Housing Quality (NHQ) Award, we were already assisting Malcolm Baldrige National Quality Award winners in their efforts to refocus, restructure, and redesign their business operations around their processes. Before there was any interest in the homebuilding industry on the documentation and management of business and operating processes, we were already recognized experts in that field.

Our process toolbox is the best in the industry. We pioneered the development of many of the tools and techniques we use in this area. We use the most advanced process flowcharting and modeling software available – after having participated in a part of their development.

We are adept at every form of process documentation, including cross-functional flowcharting, value stream mapping, and IDEF process modeling, all of the notation languages, as well as the methodologies – Total Quality Management, Lean-Six Sigma, Theory of Constraints, and Lean/TPS – that act upon them.

We know what we are talking about.

Here is my contact information:

Fletcher L. Groves, III
Vice President
SAI Consulting, Inc.
PO Box 1755
101 Laurel Court
Ponte Vedra Beach, FL

(904) 273-9840 (office)
(904) 613-5213 (mobile)