Do we have to consider BPM/BPMS a threat against ECM, DMS, ERP, CRM, SCM more “traditional” applications?

Many discussions arise around the contest among what we could call the “traditional” registering and transactional applications (ECM, DMS, ERP, CRM, SCM, …) by one side and, by the other side, the new players, procedural applications, mainly represented by BPM Processes developed on BPMS platforms.  

This conceptual fight has been created and continuously feedback by several market strategy factors:

1.     As a reaction against the announced BPM tsunami, around five-ten years ago some software vendors of “traditional” registering and transactional applications decided to include workflow module as a procedural extension of their platforms. This strategy has failed.

2.     Most recently, some of these registering and transactional software vendors has decided to change the above strategy and extend the value of their offering by buying a BPMS software vendor company, and then incorporate their technology in its product scope but as a separated product, not trying to arrive to a real product integration.

3.     And last but not least, to even increase the complexity, some BPMS software vendors have decide to include registering and even transactional module in its originally only BPMS focused platform.

As a result of those tendencies and the contradictory messages of the software vendors, end customers as very confused about the new IT architecture paradigm and where to put every each available application piece in order to build a robust, well organized and resilient IT building. 

The confusion has even increased with the irruption of the new mobile and social groups of applications.

In our opinion, all the above types of applications have an important and necessary role in the new IT architecture paradigm. 

As we try to reflect in the following figure, ECM/DMS applications are essential to manage the content, ERP/CRM to keep records/transactions, like taking a picture of what has happen and, finally, BPM/BPMS drives the action.

A BPM Process, like in a movie, is allowing the different scenes (tasks) flow along the life of the process, permitting to the different actors (people, applications, systems, machines, sensors, ..) play their role at the right moment that the scrip (the process class) requires their contribution: 

• In certain scenes from the movie, documents and other content is even required to be used, or to be created and recorded and then the BPM Process manages the automated interactions with the ECM/DMS. 
• In other moments of the process, data from transactional applications is required to fulfil process requirements and then the BPM Process recovers and presents this data in an automated way.
• In addition, finally, normally at the latest steps of the movie, all the necessary data to complete a transaction has been already collected, verified and approved and then the BPM Process is automatically creating the transaction against the transactional application(s).

In this cooperative model, all the pieces are required, have an equally important role for achieving a smooth, as much automated as possible business operations. In addition, a new player appears: the SOA layer, the main success factor in the interoperability among the different combined applications. 

Therefore, in our opinion, there is no discussion about the matter, no contest at all; BPM/BPMS is not trying to substitute the traditional applications but to orchestrate all them together to obtain a much more efficient support to the business operations the organizations are running day to day.

Indeed, we consider it is not possible a massive implementation of BPM with success without insuring a solid, well organized and performing registering and transactional IT layer.