| |
SPECIAL EDITION
Business Process Methodologies
by Paul Harmon, Executive Editor, Business Process Trends
In this advisor, I want to review the public business process
methodologies. Lots of people talk
about methodologies, but finding a practical methodology you can use in your
own organization is too easy.
First, some ground rules: When I refer to a methodology, I mean a comprehensive and
specific set of instructions for accomplishing a task—in this case
redesigning or improving a business process. The complexities are such that no methodology can ever be an
algorithm—it can’t specify exactly what to do in every case. At best a methodology can provide
a generic approach and a collection of heuristics. A good methodology, however, can provide a large collection
of heuristics, a precise vocabulary, checklists and worksheets, and well
defined procedures for accomplishing particular tasks. A good methodology can guarantee that
trained teams will approach projects in a reasonably consistent manner and usually
achieve the same results.
I define a public methodology as a methodology that is
described in a book, taught in available courses, and used by at least one
company. This excludes the
methodologies offered by some consulting companies that you can only learn
about by hiring the consultancy. Similarly, it excludes the various methodologies that people write about
in articles that never get beyond a general description, and it excludes the
various vendor methodologies that are sold in conjunction with a software
product. All of the methodologies
described below can be used without using a specific software tool. Thus, these are methodologies that any
organization can study and discuss with others. I’ve tried to include all the public methodologies
being actively marketed today.
Second, a qualification: I have worked with Roger Burlton and others to develop two
Business Process Trends Associates methodologies, which I include in this
discussion. In fact, I’ll begin by
describing them and then use them as a reference point for the subsequent
discussion. Thus, I can hardly be
described as an objective source of information on this topic, although I am
trying to be as objective as I can.
The Business Process Trends Associates methodology is, in fact,
two methodologies: one for
enterprise work and one for process redesign. BPTrends Associates describes the two methodologies and the
major steps associated with each, as shown in Figure 1. We discriminate between enterprise
activities that create tools for executives and BPM centers of excellence to
use and the projects companies undertake to redesign a specific process. As a generalization, less sophisticated
companies focus on process redesign and improvement, while more sophisticated
companies tend to focus on creating a business process architecture that can be
used to help manage and prioritize the entire enterprise’s process efforts. It’s nice to have an enterprise process
architecture in place to help select processes for redesign, but most
organizations don’t have an enterprise architecture in place, so we treat the
two situations more or less independently.
Figure 1. The BPTrends Associates Enterprise and Redesign Methodologies
BPTA Enterprise Methodology. BPTrends Associates refers to its
methodology as a “best practices” methodology. It doesn’t seek to create a unique, proprietary approach,
but, instead, seeks to synthesize the best of various previous approaches into
a well coordinated whole. At the
enterprise level the goal is to create or organize the tools and resources that
senior managers and a business process center of excellence will need to manage
and coordinate process work throughout the entire organization. Thus, phases in the enterprise effort
include organizing strategy and processes, creating a business process
architecture, organizing a process measurement system, establishing a process
governance system, and aligning processes with other resources from IT, HR,
etc. These tools and resources, in
turn, are used by executives or by a BPM group to identify and prioritize
process change efforts, to train and evaluate process managers and to support
specific process redesign or improvement projects. The sequence of
activities isn’t too important at the enterprise level; companies approach
enterprise development in different ways. Some focus on process modeling first, while others are much more
concerned with performance measurement. They key is establishing tools that managers can use consistently.
BPTA Process Redesign Methodology. The
BPTrends Associates redesign methodology focuses on projects that involve major
changes in business processes. We
look, in a systematic way, at the business model underlying the process, at
inputs, outputs, activities and flows, the management of processes, the control
of processes and the support of processes. At this level, sequence is very important. We focus on a step-by-step approach to
analyzing the As-Is process and creating a new To-Be process. We use the core notation of BPMN and
rely on best practices whenever possible.
BPTA offers public courses in conjunction with Boston University. For more information check: (www.butrain.com/Business-management-training-courses/business-process-management-training.asp The book to read for an
introduction to this approach is Paul Harmon’s Business Process Change, 2nd Ed. (Morgan Kaufmann, 2007).
With this framework in mind, Figure 2 suggests how I would
describe the other public business process methodologies I know about. I’ve subdivided them in two ways. First I discriminate, very broadly,
between those methodologies aimed primarily at enterprise level change and
those aimed at process level or implementation level change. This isn’t always a very precise
distinction, as we will see. Second, I have discriminated between more or less comprehensive process
methodologies and those that are more specialized and only used for specific
types of projects.
Figure 2. An overview of the public business process change methodologies
Enterprise Level Methodologies
Enterprise Adoption of Six Sigma. Doing
justice to Six Sigma, as a methodology, is hard. First there is definitive description of the Six Sigma
approach. It originated at
Motorola in the mid-Eighties, but there are no books that everyone agrees
define what Six Sigma is. In fact
there are dozens of books on Six Sigma, each slightly different. There are six leading Six Sigma
training-consulting companies each with extensive programs of courses. Broadly, Six Sigma can be divided into
four areas: Management, Six Sigma
for Design, process redesign, and process improvement. Process Improvement, with its DMAIC
methodology is what most people associate with Six Sigma—and we consider DMAIC
below. Six Sigma Management refers
to a whole bag of things, but I use it here principally to refer to the fact
that Six Sigma is often brought into an organization by a CEO or COO to
transform an organization. Organizational transformation is hard to do and Six Sigma has a better
record than any other process approach. By involving the CEO and focusing on saving the company large amounts of
money, it rallies the executives. That, followed by an extensive training program, results in getting
large numbers of employees to be more aware of the importance of process. One of the best books to read to
understand how this is done is The Six Sigma Fieldbook: How DuPont
Successfully Implemented the Six Sigma Breakthrough Management Strategy by
Mikel Harry and Don R. Linsenmann (Doubleday, 2006). A more generic book is Rowland Hayler and Michael Nichols’
book, What is Six Sigma Process Management? (McGraw-Hill, 2005).
The other Six Sigma enterprise level initiative is Design
for Six Sigma, which is a rather technical niche methodology aimed at designing
new products so they can be more easily. A good book on this niche methodology is Design for Six Sigma in
Technology and Product Development by C.M.
Creveling, J.L. Slutsky and D. Antis Jr. (Prentice Hall, 2003).
Rummler-Brache-PDL Methodology. The font of all
modern process methodologies is the methodology defined by Geary Rummler and
Alan Brache in their book: Improving Performance: How to Manage the White Space on the Organization Chart. (Jossey-Bass, 2nd Ed. 1995). Geary Rummler started
teaching process analysis and redesign at the end of the Sixties and refined
his methodology in the Seventies. In the early Eighties he taught courses at Motorola University that laid
the process foundation for what became Six Sigma. He and Alan published their book, Improving Performance, in 1990. In 1993, when process reengineering became an overnight sensation, folks
looked around for a systematic way to apply Davenport and Hammer’s ideas and
many settled on Process Improvement and the courses offered by Rummler-Brache. (This is where process diagrams with swimlanes came from.)
In spite of his seminal role in process change, Rummler has always insisted on
a “performance” view of an organization. He focuses equally on organization architecture and management and on
processes and people. Thus, it
would be easy to classify the Rummler-Brache methodology as either an
enterprise level organization change methodology or as a process redesign
methodology, and, in fact, Rummler-Brache always offered courses in both areas.
Geary Rummler currently manages the Performance Development
Lab (PDL) and still teaches the latest version of his comprehensive approach to
organization and process improvement. The best book to read is Geary Rummler’s Serious Performance
Consulting: According to Rummler (ISPI or
ASTD, 2004).
xBML Methodology (Business Genetics) This
is another methodology that’s a bit hard to classify. The fact that it is termed the eXtended Business Management
Language (xBML) methodology suggests its roots in IT. On the surface it feels like a limited
implementation of the Zachman approach to enterprise architecture. One begins by creating hierarchies or
networks (models) for: 1- activities (What), 2-information flows (Which),
3-managers and employees (Who), 4-geographical locations (Where), and 5-flows
between activities (When). If a
company can do this, then it has created a repository of all its processes and
the possible links between them and it also knows what information is required,
who works on each, and where the work takes place. Using this information one can construct a flow
diagram. When one first hears of
this approach—it sounds simple: identify all your processes or activities in a hierarchy diagram. Identify all your employees and
indicate what roles they perform in any possible activity. The reality, of course, is that these
are huge undertakings in large companies, and often involve circularity. You have to know the names of the
processes and activities before you can say which activities a given employee helps
implement. On the other hand, if
you don’t complete a comprehensive analysis of your firm before you proceed to
a project, how do you scope the specific project and determine which subprocesses
you will need to focus on? Business Genetics is presented as a combination enterprise methodology
and a process redesign methodology. In fact, it seems more like an enterprise repository methodology to us,
but, in any case, it is hard to classify in our schema.
Business Genetics, the company that sells the methodology
and training, is closely allied with a software vendor, xBML Innovations, that
provides a modeling tool tailored for xBML. The methodology was offered before the software tool,
however, and was developed and is more or less independent of the tool, so we
are treating this as an independent methodology and not a software vendor
methodology. The book to read to
learn more about this approach is Business Genetics by Cedric Tyler and Stephen Baker (John Wiley, 2007).
Some Specialized Enterprise Methodologies
Some people would deny that some or all of the following
approaches to process change constitute a process change methodology. In fact, however, I encounter these
approaches when I visit companies working on process change and that many find
them very useful. These are not comprehensive
process change methodologies, but constitute specialized or niche approaches to
process change.
Balanced Scorecard. A good example of a specialized
methodology is the Balanced Scorecard approach created by Robert Kaplan and
David Norton. The initial Balanced
Scorecard was a conceptual device to get organizations to be more flexible and
comprehensive in evaluating company goals and measures. It evolved into a structured
methodology for evaluating organization and managerial performance that is now
widely used by leading organizations throughout the world. Recently, Kaplan and Norton have
suggested how Balanced Scorecard could be extended to tie strategy to
performance goals and measures. The best general book on Balanced Scorecard is The Balanced
Scorecard: Translating Strategy into Action by Kaplan and Norton
(Harvard Business School Press, 1996). A recent book that suggests how it can be aligned with
Six Sigma is Praveen Gupta’s Six Sigma Balanced Scorecard (McGraw-Hill, 2004). We use a variation on the Balanced Scorecard approach in the
BPTA Enterprise Methodology to organize metrics and process manager
evaluations.
CMMI. Another specialized methodology is offered by the
Software Engineering Institute (SEI) at Carnegie-Mellon University. Working for the US Department of
Defense, SCI created CMM—the Capability Maturity Model. It was originally designed to evaluate
the maturity of software development organizations. It has been extended to CMMI, which can be used with any
business process. If you study
CMMI, you will find that they believe that the most effective way to evaluate
the process maturity of organizations is to study the skills possessed by
managers. Similarly, if you
develop a change program based on CMMI, you are, in effect, defining skills and
capabilities that your process managers will need to master. Thus, CMMI, as a methodology or
prescription for change, defines a training program for your organization’s
managers. It doesn’t provide any
direct help with specific process improvement, but, assumes that if you improve
your manager’s skills in managing processes that will eventually result in
improved processes and better performance. Thus, CMMI, as a process change methodology, is both a
long-term and a niche-focused approach. There are many books on CMMI and on various specialized versions of
CMM. The best general introduction
is CMMI, 2nd Ed., Guidelines for Process Integration and
Improvement, by Mary Beth Chrissis, Mike Konrad and Sandy
Shrum (Addison-Wesley, 2007).
SCOR. SCOR is the Supply Chain Council’s
supply chain framework. It is also the name of a notation and a methodology
defined by the SCC. Obviously the
SCOR methodology is a niche methodology that is focused on redesigning or
improving an organization’s supply chain. If the SCC’s methodology were all there was, we wouldn’t include it,
since the SCOR methodology isn’t much more than a very general approach. Peter Bolstorff and Robert Rosenbaum,
however, have extended the SCOR methodology into a very systematic, seventeen
week program that helps a company examine and improve its supply chain. They term their methodology Supply
Chain Excellence, and they document their step-by-step approach in a book of
the same name. They have just
released the second edition of Supply Chain Excellence (AMACOM,
2007).
Proteus. Proteus is a business rules
methodology created by Ron Ross and Gladys Lam, both of Business Rule
Solutions. Rules are used in
processes to guide decisions, and hence, there is a close relationship between
analyzing activities and defining the rules the employees or systems use to
make the decisions that are made when the activity is performed. In some cases, simply changing a
set of business rules can solve a process performance problem. That said, however, those who focus on
business rules use a somewhat different approach than process analysts. They tend to start with company
policies and put quite a bit of effort into defining the organization’s
vocabulary and work, top-down, to define a traceable hierarchy of business
rules. Most process analysis
methodologies, on the other hand, either ignore rules, or only focus on them
when they attempt fine-grained task analysis. The use of rules in simulation systems, ERP systems, and in the
development of BPMS applications, however, guarantees that the analysis of
rules and processes will become increasingly intertwined. Meanwhile, Proteus is a systematic
approach to business rules analysis and improvement. A good book read on this
approach is Ron Ross’s Principles of the Business Rule Approach (Addison-Wesley, 2003).
Process Level Methodologies for Process Redesign or
Improvement
Lean Six Sigma (DMAIC) We have already
discussed the problem of classifying Six Sigma. There is no single source book. Instead, Six Sigma has evolved from practices initially
taught at Motorola University. Today, the most respected source of Six Sigma certification is probably
the American Society for Quality (ASQ) but there are other Six Sigma
professional groups (e.g. ISSSP), dozens of books, and workshops on every
aspect of Six Sigma. Most Six
Sigma practitioners focus on process improvement. They begin with an established process and seek to improve
the quality of the process outputs while simultaneously reducing the
variability of the output. Most
Six Sigma practitioners put a major emphasis on measuring processes and on the
use of statistical techniques to analyze process problems. The best known methodology associated
with Six Sigma is DMAIC (Define, Measure, Analyze, Improve, and Control). Over the years many observers have
objected that Six Sigma teams have focused too narrowly on low-level processes,
often seeming to insist on improving the way deck chair are placed even as the
ship sanks. In fact, most Six
Sigma training companies and most Six Sigma authors warn of this and urge
practitioners to not only consider process improvement projects but to also
consider larger process redesign efforts and company process management issues. Most Six Sigma companies have courses
in all these areas.
Recently, most Six Sigma practitioners have begun to
incorporate Lean in their practice. Lean derives from the Toyota Production System and is focused on
improving the flow of activities within an organization. At the enterprise level, Lean
practitioners map entire value streams and seek to make the flow more efficient
by introducing ideas like Just-In-Time and flows that are pulled by demand
rather than pushed. At the process
level, Lean folks tend to focus on the elimination of waste (muda). To a process redesign practitioner,
like myself, Lean seems like a rather limited approach to improving flow,
ignoring, for example, business rules and process management practices, but it
fits well with Six Sigma improvement efforts. Unfortunately it tends to pull Lean Six Sigma discussions
back toward a focus on manufacturing, but presumably Lean will be extended to
other domains just as Six Sigma has been.
I won’t bother to recommend a book for Lean Six Sigma. There are dozens of them that all cover
nearly the same ground. If you are
interested in this area, you will probably want to get the book of someone
working with whatever Lean Six Sigma training company you decide to go to for
training.
BPM Methodology. John Jeston and Johan Nelis have
written a popular book, Business Process management: Practical Guidelines to
Successful Implementations (Elsevier, 2006), that defines a business
process redesign methodology. Like
most business process methodologies they combine enterprise architecture work
and process redesign work into a single process, but they could easily divide
them and have an enterprise methodology and a separate process redesign
methodology if they choose. I
would describe their methodology as a best practices methodology. They provide a general structure for a
wide variety of popular techniques. In addition, the book describes how to move from a redesign effort to a
BPMS effort, making this the methodology that is probably most aligned with the
current interest in developing BPMS systems.
A Specialized Redesign Methodology
RIVA and Human Interaction Management. Here
are two specialized methodologies from the UK. RIVA is a methodology by Martyn Ould that puts a lot of
emphasis on processes that involve human communication and collaboration. The methodology introduces a unique
notation, the Role Activity Diagram, that is specialized to describe
collaborations. Keith
Harrison-Broninski uses the Role Activity Diagram and extends RIVA to describe
an approach to analyzing human-driven processes. Harrison-Broninski doesn’t provide a phased methodology and
it would be easy to see his HIM approach as simply a set of heuristics. Together with RIVA, however it defines
a method for attacking human-driven process problems. Neither of these approaches constitutes a general approach
to dealing with business process problems. RIVA has the feel of a software methodology. Both authors, however, are forcing
people to think about processes that involve collaboration and the dynamic
development of solutions to tasks and techniques from each will probably be
incorporated into the more popular redesign methodologies. The two books for these methodologies
are: Martyn A Ould’s Business
Process Management: A Rigorous Approach (The British Computer
Society, 2005) and Human Interactions by
Keith Harrison-Broninski (Meghan-Kiffer, 2005).
Implementation Level Methodologies
The implementation level is concerned with providing support
and infrastructure for business processes. Thus, an HR methodology to generate training or an IT
methodology to generate software applications constitute implementation level
methodologies. In general, process
analysts ignore the more technical implementation level methodologies. In many
organizations, however, IT is responsible for process change and some IT groups
use extended software methodologies for process work. In effect, “requirements capture” becomes a process
analysis phase. Thus, it is
appropriate to comment on a few of the implementation methodologies with strong
process modules.
IDEFO Methodology. IDEF is a methodology initially
developed for the Air Force in the Seventies. It is, in essence, a structured software methodology. It has a front-end module, IDEF0, which
is focused on analyzing business functions and the processes within them. The methodology as gone through several
iterations and there are those with backgrounds in military work, who like
IDEF0 for process analysis work. A
good book that explains IDEF0 is Clarence G. Feldmann’s The Practical Guide
to Business Process Reengineereing Using IDEF0 (Dorset House,
1998).
IBM’s LOVEM Methodology. In the mid-Nineties IBM promoted
a methodology called LOVEM (Line of Vision Enterprise Modeling). In essence, LOVEM was a variation on
the Rummler-Brache methodology with extra swimlanes added to make it easier to
see where IT resources supported business processes. The name, Line of Vision, derived from the fact that
Rummler-Brache always placed a swimlane for the customer at the top and one
could glance across the top line and see all the places that the process
touched the customer. LOVEM’s way
of representing IT systems were quickly incorporated into Rummler-Brache
practice, just as other methodologies quickly incorporated swimlanes and LOVEM,
as an independent process or IT methodology has largely disappeared.
Unified Software Development Process. Finally, a word on IBM/Rational’s Unified Software Development methodology. In the mid-Nineties, Rational hired
three of the popular object-oriented software development methodologists and
set out to create a unified approach to OO software development. At the same time the Object Management
Group (OMG) decided to try to standardize the notation for OO diagrams. In response, Rational decided to split
their notation from their procedural methodology and submitted their notation to the OMG. It was adopted, with some changes and
has become the OMG’s Unified Modeling Language (UML). The initial version of UML included a
number of different modeling techniques including one for activity
diagrams/state diagrams. By
combining state and activity diagrams the initial UML diagrams, the OMG
guaranteed that no one involved in process workflow analysis would use their approach. In the recent major UML update (Version
2.0) this problem was corrected and UML 2.0 has an Activity diagram
specification that could be used by business people. Meantime, however, the process modeling vendors have settled
on the Business Process Modeling Notation (BPMN) which is also an OMG
specification and work is now underway to align UML activity diagrams and BPMN
diagrams.
The key thing, however, is that Rational and the OMG split
notation from methodology. Rational, on its own, proceeded to create the Unified Software
Development Process. IBM then
bought Rational. The
IBM/Rational Unified Software Development Process is probably the most widely
used software development methodology today, and many companies have
standardized on it. USDP uses UML
and business analysts and software developers working with USDP are necessarily
using UML. Thus they use Use Cases
and Activity Diagrams for requirements analysis. As noted earlier, few business people are interested in UML
or USDP, but when IT leads the process work at a company, business people often
find themselves looking at requirements documents defined by means of UML
models. The authoritative books on
UML and USDP are all coauthored by the three software methodologists who
created this approach: Grady
Booch, James Rumbach and Ivar Jacobson.
ARIS. Finally, there is ARIS, the methodology
of IDS Scheer. It would be easy to
dismiss this as a vendor methodology, designed to support IDS Scheer’s ARIS
software modeling product were it not for two things. First, Dr. Scheer has written a number of books on the ARIS
methodology, some of them focused on enterprise and process level
analysis. And, second, the use of
ARIS as a modeling technique by SAP, Oracle and Microsoft, guarantees that ARIS
is extensively used by those engaged in ERP implementation efforts at leading
companies throughout the world. Overall,
ARIS is heavily focused on software development, but it is also widely used by
business process analysts, especially when they are working on company ERP
projects. For more information on
the ARIS methodology, read one or more of the books written on ARIS by
August-Wilhelm Scheer.
Summary
This overview of process methodologies suggests the
diversity of the field. If I were to include vendor, consultant, and academic
methodologies we would see there is even more variety than we have sketched out
here. I’ve undoubtedly missed a public
methodology or two and would appreciate information from readers on other
methodologies I might have included. I’ve mostly avoided methodologies at the implementation level and
haven’t even begun to consider training or human performance methodologies one
might use in conjunction with a process improvement effort.
Of the methodologies I have considered, Six Sigma DMAIC is
undoubtedly the best known and most widely used, but it is, as we have suggested
generally used to achieve rather limited goals. Similarly, the second and third largest groups of users
would be business analysts and software developers who use ARIS or UML for IT
related problems.
Put a different way, the methodologies that are truly BPM
methodologies, in the broadest sense, are neither well established nor broadly
used. Business process change
initiatives have been popular for the last twenty years, but we have yet to
arrive at a consensus about the best way to conceptualize or approach
systematic process change. The
good news, however, is that companies now have some interesting process change
methodologies available that are designed to be used by business managers and
process change practitioners and we will undoubtedly see one or more of them
become more widely known in the years ahead.
Paul Harmon is the Executive Editor of Business Process
Trends, a website devoted to providing information on business process change,
the author of Business Process Change, a
popular book on business process redesign, and he is the Chief Process
Methodologist at BPTrends Associates, a process training and consulting
company. He can be reached at pharmon@bptrends.com.
return to top
|
|
|
