My friend Marcelo send me another interesting eMail on a problem he is facing selling BPM into a world dominated by vendos like SAP:

Dear Tom:
I would desire to share with you a recurrent problem we faced trying to sell BPM Projects. Here in Argentina, the medium-large companies have SAP in a high percentage of them, to support their operations. When we initiate the selling process of BPM projects, the reality we faced is the people have only a vague idea about BPM, and tends to confuse BPM with simple workflows systems, DMS or include it as a part of an ERP and not as a separate system. We then make an effort to evangelize about BPM concepts and platforms. Nevertheless, the followings questions are formulated recurrently:

  • Which are the differences between a BPM System and SAP? To be more clear, what things a BPM System can do are not possible to do with SAP?
  • The current SAP platform (SAP Portal) is much more that a simple ERP (like the case of SAP R3). Now, SAP is a development framework furthermore an ERP. Then if we made the investment of buying SAP, which are the arguments to invest in another platform, in this case a BPM platform? Moreover, the SAP people say us that is possible to build the processes and workflows inside SAP.
  • Which is the difference between a workflow system and a BPM system? SAP Portal support workflows.

In several cases, the attitude of client IT people is tough. Some people feel the BPM proposal as a dispute to the SAP selling decision. Why? Because severals BPM platforms declare the “zero programming” feature to build processes, the facilities to modify the bussiness rules without the intervention of any IT consultant, and the quickly development time of BPM projects, in contrast with SAP implementations and maintenance, which are expensives and require the participation of SAP consultants in almost permanent form. Others (the more technological people), feels the BPM proposal like a challenge to their programming abilities, because the nature of “zero programming” of certain BPM platforms (further on the integration points with other systems, which are essentials to the BPM System operation, and require programming).
In my mind leave a phrase that an BPM vendor said, talking about this issue: “One of my main competitors, is an IT Area with a very high ego. This people oppose to the BPM buying decision because they say that they can develop it from scratch. The operation people, which are who have the operation pains, leave disconcert between the words of IT people and the words of BPM vendor. Who have the reason?”.
I hope to have been clear, my english is not so good. If you have some questions, let me know, I am for you disposal.
Best regards.
Marcelo Saparrat
Director de Operaciones
TecnoAp
( (+54)-221-4895206
* msaparrat@tecnoap.com
4 www.tecnoap.com

Marcelo: There is actually a pretty good post about this here.

I am reminded of the 3-waves of Business Process Management as expressed in Business Process management the Third Wave:

  • In the first wave of business process management, which began in the 1920s and was dominated by Fredrick Taylor’s theory of management, processes were implicit in work practices and not automated.
  • In the second wave of business process management of the past decade or so, processes were manually reengineered and, through a one-time activity, cast in concrete in the bowels of today’s automated ERP and other packaged, off-the-shelf systems. Even with document-centered workflow added to ERP, such systems only took up discrete roles as participants in processes. Rarely did that provide business management control over the processes. Those that did only did so for subprocesses and were generally limited in their capability.
  • In the third wave of BPM, the business process is freed from its concrete castings and made the central focus and basic building block of all automation and business systems. They become first-class citizens in the world of automation. Change is the primary design gold because in the world of business process management, the ability to change is far more prized than the ability to create in the first place. It is through agile business process management that entire value chains can be monitored, continuously improved and optimized.

What you are saying is the SAP folks are arguing that the customer should stay with the second wave. Bake the ‘requirements’ into ABAP and create ‘Business-Rules’ by configuring applications.
The last sentence is key to the entire argument. If your organization needs to innovate, need to be agile and respond creatively to changing economic conditions then you can build a case for BPM. To be blunt, SAP is hideously complicated to enter the simplest of business transactions and many of my integration SAP/BPM projects were about taking a 40+ field iDOC and create a 3-4 field workflow screen. Business Rules and BPM creates the integration. That is the nuts and bolts innovation anyway.

BPM is not for every circumstance, if the process you are engineering is complex, changing and innovative in some manner then BPM/Decision Management is the only way to go.

BPM/Decision Management Standard of Care
There are many areas where BPM/Rules are emerging as the standard of care. Life and Casaulty Insurance, Health Benefits, Supply Chain Management, ITIL, Banking and Financial disciplines such as derivatives. These customers will care less what stogy reactionary sales folks are telling them. The back-door way to ’sell BPM’ is find a sucess story in your process area.