I noticed that process part of our BPM projects tend to be smaller than the part that may be called traditional enterprise application - planning, accounting, reporting. (With the only difference from tradition that it’s web applications instead of client-server.)

In fact I always believed that BPM is for those who “got a ERP yet didn’t get happiness”. But I can’t see a single company around who have reached the nirvana of total automation - everyone wishes to add something to their software assets. And advanced ones don’t want to go traditional way, they want to strengthen new applications with process support. No objections indeed but as a result we fall into projects that have a lion’s share of more or less traditional applications develoment and smaller process management part. Our analysts and developers spend most of their time on these applications, not on business processes. Not a big deal of course - we are in this business for more than 15 years - just boring if compared with the process work.

As someone said on sql.ru forum, BPMS ain’t a silver bullet because there is still a lot to do manually.

But a simple thought got into my mind today: i’ts simply because BPMS makes the process part easy while the rest of the job remains the same. Let’s imagine for a moment that we have the same two parts of the job - traditional and process ones - but no BPMS. The volume of process work would increase manyfold and balance would shift.

Let me use my favorite BPMS-DBMS analogy. Database development takes relatively small part in today’s projects if compared with UI development. But it’s only because modern DBMS’es simplify this job tremendously. Just imagine for a moment that data are managed by some C library and you have to programm data navigation also on C instead of SQL.

Conclusion: it’s not about being rich with BPMS, it’s about being very poor without it!