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.

The objective of this mechanism is to result in a better overall picture of the whole of the working processes of the company and their interactions to be able to optimize them and, as far as possible, automate them to the maximum through Work application

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.