Organizations just starting with BPM often have the misconception (often unknowingly) that it's an area that allows business processes to be automated and that executing BPM activities is the responsibility of systems folks. These organizations often have business analysts that belong to systems department working with the business partners to model the business process flow. This activity is no different than the typical requirements gathering. Like they gather user-system interaction in form of use cases and business rules requirements in form of rules repository, they capture business process flow in form of process description and BPMN model. This process results in yet another artifact owned and maintained by the systems department. These artifacts are used for process automation and then, they get lost in the pile of papers that are looked up only when the system implementing the business process needs to be changed. This works well if the goal is to simply document the process flow. But BPM is not about just identifying the process flow. It is much more than that.

A successful BPM strategy requires the organizations to stop treating BPM as the requirements gathering activity owned by systems. Going back to the car analogy, business processes must be well built, owned and maintained; and this must be done by the business. IT is a stakeholder in the process of building and maintaining the business processes but the business must define it, own it and maintain it. 

This is a very important concept to develop and implement a successful BPM strategy. In my future blog entries, I will explore it in much more detail.