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.
