Business process modelling (BPM) has been around for quite some time now. On conceptual level BPM (together with its little sister business rules engine (BRE)) has the potency to be the 4GL that companies have been looking for.

Business process modelling is an activity to represent the processes of an enterprise [1], any process. Yet, in reality BPM is used very little. BPM's are used mostly in the area of the formal business domains i.e. where it concerns legal constructions with customers or business partners. However, by far, the most processes enterprises have, concern day-to-day activities between employees. And those employees still use forms and emails to communicate with each other. 

All departments have periods in their existence when they are overwhelmed by the amount of work that is expected from them. In an attempt to structure the incoming work, departments make up intake forms that people outside the department must fill in to get something done. Although this structures incoming work it creates a lot of overhead for the requesters. These forms are the bricks that build the walls between departments.

This is where BPM would be extremely useful. It is therefore, at first glance, unbelievable that BPM is not used in such situations. Zooming in on the situation reveals that forms require a lot of information from the requester. And although the information is present somewhere in the enterprise, it is difficult to gather. Most often the information can be found in a configuration management database, in the company's employee directory, or in project documentation. The problem with these information sources, is that they do not structure the information such that it can be re-used easily. And if one manages to enter the information into a process in a BPM tool, the information is lost once the process completes or even before. So, unless databases are created explicitly to store the information, and careful thought is given to the nature and structure of the information, the information is lost.

This is where BPM has left a gap. BPM should have added the concept of an data object. An object is mutated during processes by tasks when events occur. With the notion of the object added to BPM it becomes very easy to re-use the information to fill in the aforementioned intake forms. Departments can create forms at will using the enterprise object dictionary to specify the information required. Information available in the enterprise is added automatically, real-time if needed and therefore always up-to-date. 

Hence, without the concept of the data object being part of BPM, BPM will not find its way into the day-to-day activities of employees. In next posts I will give my thoughts on how Business Object Relationship Modelling (BORM) and artifact-centric business process modelling can fill the hole in BPM.