The Workflow Management Coalition has been working to standardize terminology for process oriented thinking for 20 years. The market is strong, and the consumers confident, only when terms are used with consistent meanings across the industry. For this reason, the WfMC joins many others in presenting and supporting an official and definitive definition of BPM:
“Business Process Management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.”
The goal of this effort is to find the definition that closely represents the concept that most people (including both experts and otherwise) have for the term BPM. The goal was not offer judgment on different BPM methods, technologies or products, many of which are discussed on this site. This definition is by design short and concise, yet definitive and complete. Some broader considerations
- BPM is a discipline; it is a practice; it is something you do.
- Business stems from the state of being busy, and it implies commercially viable and profitable work. A business exists to provide value to customers in exchange for something else of value.
- Process means a flow of business activities and seeing those activities as connected toward the achievement of some business transaction. Flow is meant loosely here: the order may or may not be strictly defined.
- A person doing BPM must consider a process at the scope of interrelated business activities which holistically cooperate to fulfill a business objective. This is the key difference from a functional view of business where each function might be optimized independent of the other functions. In a complex system like a business, it is well known that local optimization of part of the system will rarely lead to good overall results. A BPM practitioner must consider the metrics of the entire system when evaluating a specific process.
- Modeling means that they would identify, define, and make a representation of the complete process to support communication about the process. There is no single standard way to model, but the model must encompass the process.
- Automation refers to the work that is done in advance to assure the smooth execution of the process instances. In many cases this means writing software, but it might include building machinery or even creating signage to direct participants.
- Execution meaning that instances of a process are performed or enacted, which may include automated aspects. Conceptually, the process instance executes itself, following the BPM practitioner’s model, but unfolding independent of the BPM practitioner.
- Control means that the there is some aspect of making sure that the process follows the designed course. This can be strict control and enforcement, or it might be loose control in the form of guidelines, training, and manual practices.
- Measurement means that effort is taken to quantitatively determine how well the process is working in terms of serving the needs of customers.
- Optimization means that the discipline of BPM is an ongoing activity that builds over time to steadily improve the measures of the process. Improvement is relative to the goals of the organization, and ultimately in terms of meeting the needs of customers.
- Enterprise is used here simply to mean a business organization; any organization where people are working together to meet common goals; it does not need to be exceptionally large, and it does not need to be for profit.
- The mention of enterprise goals is included here to emphasize that BPM should be done in the context of the goals of the enterprise, and not some small part of it. This might seem a bit redundant in one sense: any improvement of a process must be an improvement in terms of the enterprise goals – anything else would not be called an improvement.
- Within and beyond the enterprise boundaries recognizes that the enterprise is part of a larger system. Customers are part of the business process. Their interaction, along with those of employees should be considered as part of the end-to-end interaction.
Assumptions and Understanding Beyond the Definition Alone
The discussions and commentary that led to the official definition of BPM also uncovered several assumptions and immutable notions about BPM. These are presented below.
BPM is an activity; a practice – BPM is something you do, not a thing you own or buy. It is described in many definitions as a practice. There was wide agreement on this, well over 90% of the participants expressed this view.
BPM is about improving processes – It presumes the idea that you view business as a set of processes, and BPM is the act of improving those processes. This is important: “skill” is different from “skill improvement”. This can be confusing. For example in competitive situations the two ideas are often intertwined – what is the act of playing tennis, if not also the act of trying to improve the way you play tennis? However, in other contexts it is easier to distinguish – the activity of driving is different than taking a driving course to improve the way you drive.
The implication is that BPM is not about automating business process (in the ‘paving the cowpaths’ meaning) but about improving them. The same way that ‘reengineering’ a process is about not simply automating what is currently there. Some will say that automation by itself is an improvement over a manual process. The BPM is the activity of discovering and designing the automated process, and is done when the finished application is deployed to the organization. The running of the processes is not part of BPM. However, monitoring the process to find areas of improvement would still be an important part of BPM.
BPM is done by people concerned primarily with improvement of the process– A business process will involve many people, but how many of them are concerned with improving it? Some will insist that improvement is everyone’s job. That is, the receptionist should be thinking about how to improve the operations if possible. This interpretation is too broad to be useful. The cook who adds salt to the food making it taste better, motivating more employees to eat in the building, cutting down on waste of time driving to an outside restaurant, and improving the amount of information interaction between worker, and resulting in better performance is NOT business process management by any account. Everybody in a business is working to do their best job, and every good job helps the business, but all of this is not BPM. BPM must be narrowly defined as the activity done by people who actively and primarily look specifically at the business processes, and trying to improve them. Clearly those people must solicit input from as many others as possible, but those others are not doing BPM.
Participating in a process is not doing BPM – A manager approving a purchase order is not doing BPM even though that approval is an activity in a process. A bank manager rejecting a loan application is not doing BPM even though this activity is a step in a business process. These people are doing jobs that are part of a process, but they are not doing BPM.
Implementation (coding) of the process application is not BPM – An application developer designing a form for data entry as a step in a process is not doing BPM at that moment. Once the “to-be” process has been adequately spelled out, the actual implementation of the application that supports it is no longer actively engaged in improving the process. A small caution here: applications are often developed incrementally — show to the customer, get feedback, improve, and iterate — and the process may be improved incrementally as well. Those incremental improvements should be included as the activity of BPM, but the activity of implementation of the application is not BPM. The criteria is clear: if you are actively and primarily engaged in improvement of the process, then it is BPM, otherwise it is engineering.
Making a suggestion for process improvement is not BPM – This means that there is a distinction between many people who make suggestions, and those who then actually do the BPM. When a process analyst is involved in BPM, it is expected that they will solicit lots of information about what is and is not working, as well as suggestions on how it might work. Those people who give the feedback are helping the BPM work, but not themselves doing BPM.
Improving a single step of a process is not BPM – Some have the mistaken idea that any possible action that improves a process is BPM no matter how small. A person doing BPM needs to have some kind of big-picture view of the process. It has been described as an “end-to-end view” of the process. Optimizing one step in a process, without knowledge of the entire process, is exactly what Hammer and Champy were warning about: to understand the correct optimizations we need to consider those optimizations within the context of a complete business process. A workman smoothing gravel on a road is improving all of the process that involved driving on that road, but it is not BPM because he does not have visibility of the whole process. The engineer finding a way to double the bandwidth of a fiber optic cable is improving all the processes that require communications, but this is not BPM either. An office worker who finds that OpenOffice4 helps to create documents faster than some other word processor is improving all the processes that involve writing documents; this is not BPM either. In order to have a discussion about BPM, we can consider only those activities by people who have a view to, and consider the effect on, the entire end to end process.
Misrepresentations of BPM
Here we get into a variety of different ways that people abuse the BPM term.
BPM is not a product – There is a category called “BPMS” which is a BPM Suite or BPM System. Gartner has introduced a new product category called “intelligent BPMS.” What is included depends very much on the vendor. Analysts have attempted to list features and capabilities that are necessary, but those features change from year to year. For example, in 2007 analysts commonly insisted that BPM Suites must have a BPEL execution capability, but today this is entirely ignored or forgotten. Most products designed to support BPM also include a lot of other capabilities beyond just those the BPM practitioner requires. Particularly they generally include a lot of application development and data integration capability. It is very convenient to offer all this in a single package, while other vendors bundle collections of offerings together to get the same benefit. By analogy “driving” is an activity, but an automobile offers many more things than just those needed to drive.
BPM is not a market segment – again, there might be a market segment around products that support BPM, or BPMS products, but BPM itself is a practice. Vendors may be labeled as a “BPMS Vendor” which simply means they have some products which can support the activity of BPM, among other things.
An application does not do BPM – the application might be the result of BPM activity. Once finished, it either does the business process, or support people doing the business process. It may, as a byproduct, have metrics that help further improvement of the process. In this sense it supports BPM in the same way that receptionist may support BPM by coming up with good ideas, and that is not enough to say that the application, or the receptionist, is doing BPM.
BPM as a Service is not application hosting – We use the term business process as a service (BPaaS) to mean applications hosted outside the company that supports more than one function of a business process. Like the application above, it does the process, but it does not do BPM.
Entire organizational units don’t do BPM – To say that a company is doing BPM is simply a way of saying that there are some people in the company that are doing BPM. This kind of abstraction is normal. It should be obvious that when a company or division claims to be doing BPM, the majority of the people there are not actually doing BPM.
BPM is not anything that improves business – some argue that every activity is part of a process – because a process is just a set of activities. Then, any action taken to improve any activity is BPM. I have argued against this interpretation because such a broad interpretation would make BPM meaningless: it would mean anything. There is broad acceptance that BPM is a practice of methodically improving a process that supports business, and that improvements in part of the process must be done only after the consideration of the entire end to end process.
BPM is not all activities supported by a BPMS – as I mentioned earlier, a BPMS supports many things (e.g. application development) which is not BPM. A BPMS that only supported the exact activity of BPM would not be as useful as one that bring a lot of capabilities together. It is however a common mistake for people to say that because a BPMS supports something, it is then an aspect of BPM. While it is true that someone who does BPM needs to document a process, it is not true that anyone who documents a process is doing BPM. While it is true that many BPMS support designing a screen form, it is not true that design a screen form is BPM. The activity of BPM is fairly well defined, but a BPMS support a much wider set of activities.
Because you can do something with a BPMS does not mean you are doing BPM – A BPMS is designed to support the activity of BPM. However there are many things a BPMS can do that are not BPM.