Anyone who wants to define Business Process Management or to develop a course in BPM needs, at some point, to define what topics should be included and what do not need to be included. One way to think about this is to conceptualize BPM as a domain with its own knowledge and best practices. This is, presumably, the BPM Body of Knowledge that a group like the Association of Business Process Management Professionals (ABPMP) seeks to define in it's BPM CBOK. In a similar way, it's what constitutes the content of a comprehensive class in BPM.
In essence, each of these circles shown in Figure 1 is described by books, has experts and consultants who work in the domain, and, in at least some organizations, is represented by a group. I'm not suggesting that Figure 1 is an exhaustive survey of all of the domains of practices found in a large organization, buts it's a start. Each of the domains has established best practices. At least some practitioners in each area have suggested combining one or more of the domains. Thus, for example, it's easy to imagine a CEO who thinks that organizational design and business transformation are simply facets of good Operational Management. Similarly, it's easy to find project management gurus who think change management is part of their responsibility, or vice versa. Some organizations have their business analysts reporting to IT, although most have them reporting to operational managers in various operational units.
Figure 1. A number of domains of practice found in a large organization.
My point in emphasizing this, as a BPM methodologist, is that one encounters this issue whenever one tries to define BPM, or tries to decide what should or should not be included in a BPM methodology.
Let's just consider one possible overlap. A BPM redesign project, is, necessarily, a project. One starts with a goal—to redesign a process—creates a team, organizes one's resources, establishes a schedule and milestones, and then proceeds to manage one's activities as one moves toward the completion of the effort. Should a BPM methodology focus on how to schedule, or how to assemble a project team? Should a BPM Body of Knowledge include information on scheduling and assembling project teams? If one decides to include project management instruction within a BPM project methodology, one is expanding the methodology, and probably reintroducing training that participants learned in other courses.
On the other hand, there are things about planning and scheduling that are specific to process redesign. Any good BPM team leader has specific ideas about the types of individuals that ought to be included on a good process redesign team. For example, one ought to have both individuals who currently work on or manage the existing business process and one ought to have individuals from human resources and IT to provide advice when the process redesign requires people changes or software changes. Similarly, any BPM team leader will have good rules of thumb as to how long a schedule should allow for data collection, or what milestones need to be included in a successful roll-out phase.
The Project Management Institute (PMI) takes this into account when they provide students with the following figure, which is adapted from the PMI's PMBOK guide. In essence, PMI's recognizes that there is some project management knowledge that is generic and some that is specific to other specific domains of practice. PMI focused on the Generally Accepted Project Management Knowledge and Practices. It leaves generic operational management practices aside, and it leaves the specific application area knowledge and practices for those in the specific application areas.
Figure 2. Types of Project Management Knowledge (After PMI PMBOK)
We believe that BPM ought to adopt the same approach. A student of BPM ought not to be provided generic training in general management, or in project management. It helps, of course, if the BPM methodology can reference popular approaches in other domains, since that helps to keep vocabulary from getting too confused. But the essence of BPM training, in so far as it touches on either project management or general management, should be to focus only on the specific knowledge and heuristics that a BPM project manager needs to know that are specific to BPM work. Thus, one doesn't teach how to schedule in a BPM class, but one does teach what kinds of specific activities that a BPM redesign project manager ought to schedule for a redesign project. And one provides some data on how long typical BPM activities take so that the process redesign schedule will be as realistic as possible.
In a similar way, one does not include training on generic Change Management or on Culture Change in a BPM methodology. There are two popular approaches to change management, for example. One is based on the work of Harvard Business School's John P. Kotter. The other is the PROSCI approach which is promoted by, among others, the Association of Change Management Professionals (ACMP) which is working on a Body of Knowledge and a certification program. (See Notes) Either of these approaches offers a generic approach to managing change and someone interested in the domain could profit by reading books or taking courses in either approach.
As with Project Management, however, there are aspects of Change Management that are specific to process redesign. In a nutshell, change management is about identifying stakeholders in a given change, determining their concerns, keeping them informed of the change being considered, and working with them to assure acceptance. In a process redesign project there is a point at which one identifies stakeholders in the business process. Obviously one should determine the interest each stakeholder has in a process change. At other points, one reports on possible changes, to employees and to managers. It is important that specific objections or emotional resistance be addressed. If resistance can't be overcome, it's important that the BPM project redesign team plan for the kinds of resistance it is likely to encounter as the project continues. Put another way, there are generic practices and specific techniques that BPM team leaders need to know about how to introduce and manage change while undertaking a process redesign project. They should learn the generic practices from a good change management class. But they should learn about specific ways of integrating change management practices into process redesign, and how to handle common process change resistance in a comprehensive BPM class.
Much the same can be said for each of the domains picture in Figure 1. By way of a summary, we teach BPM best practices in a process class. We expect students to obtain generic training in the best practices of other domains in separate classes; however, we include specific knowledge and best practices, accumulated by business process practitioners in our process classes to assure that a BPM practitioner knows how to smoothly integrate a variety of different domain practices with his or her BPM work.
In a similar way, if one sets out the define BPM, one should probably create a diagram something like Figure 1, and, in essence, eliminate the generic domain practices that one is not going to include in BPM. That isn't to say that BPM won't include specific, heuristic knowledge of each of the other domains, but only to assert that the core principles and practices of BPM should not overlap with the core principles and practices of other domains that one has specifically excluded from BPM.
Notes
Rosemann, Michael. Process Management as a Service. October 5, 2010. www.bptrends.com Michael Rosemann of Queensland Uni. of Tech. wrote an interesting paper on Process Management as an Enterprise Service. The idea was that an organization had several services and that it blended them to solve problems. Two of the services Rosemann considered were BPM and Project Management. To avoid confusing these “services” with software entities, I propose we rename them and call them Domains of Practice.
It's clear to us that BPM includes Lean and Six Sigma (or vice versa). It's not so clear how much process change overlaps with the practices of business analysts. In some organizations BPM and business analysis are the same, but in other organizations business analysts are more aligned with IT and only interested in getting the software requirements after the basic process redesign has been done by others. We expect, however, that BPM, Lean, Six Sigma, Business Analysis and Business Architecture will eventually merge into a single domain with a common body of best practices.
For a detailed look at how one fits Change Management with the BPTrends Associates Methodology, see the Article by Paul Harmon, Change Management and BPM. May 10, 2011. www.bptrends.com
Kotter, John P. Leading Change. Harvard Bus School Press, 1996.
Hyatt, Jeffrey M and Timothy J. Creasey. Change Management. Prosci Learning Center Pub., 2012.
Assoc. of Change Management Professionals (ACMP). www.acmpglobal.org
Paul Harmon
Latest posts by Paul Harmon (see all)
- Harmon on BPM: A General Management Model - July 4, 2022
- Processes and Capabilities - July 4, 2022
- Harmon on BPM: The Scope of Management - June 6, 2022
- Should Every Manager Be a Process Manager? - June 6, 2022
- Harmon on BPM: Management Processes - May 2, 2022
