3. Программу, следующую принципам объектно-ориентированного программирования, в принципе можно написать и на фортране. На C++ теоретически лучше, но бывают разные ситуации. То же и здесь: при желании можно сконструировать ситуацию, в которой теоретически “плохая” workflow-система “здесь и сейчас” будет лучше самой совершенной BPMS.

Да, вы правы, четвертым (а лучше первым) пунктом стоит добавить, что workflow - это, как правило, “автоматизация”, а BPM (и BPMS, как инструмент) - технология бизнес-трансформации. Сделали паузу, почувствовали разницу… BPM, не выходящий на уровень бизнеса, “заказчика заказчика”, цепочки создания ценности и тому подобных вещей - это не BPM. Но, опять-таки, если очень постараться, можно этих целей достичь и при помощи workflow-системы.

Пятым пунктом можно добавить интегральную характеристику - способность быстро менять бизнес-процесс, agility. Впрочем, формализовать этот критерий еще труднее, чем остальные.

И последнее: BPM (и SOA) - это не “оторвать и переписать”, а “сохранить и приумножить” - повысить эффективность использования уже имеющихся баз данных и корпоративных систем, подключив их к бизнес-процессам, затрагивающим на порядок больше сотрудников, чем только пользователей из бухгалтерии и финансов.

Хватит?

I always supported your point that BPMS-centric approach gives biased perspective and that wider architecture-centric view is essential.

Yet this sounds somehow abstract for many of us so practical illustration won’t hurt - hence my post.

This is an excellent overview of some problems originated in mixing of “BPM as software” (a.k.a. BPM suite) and “enterprise BPM system” (what is implemented within an enterprise to manage its business processes). See also — http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html

Sure that a modern BPM suite is necessary, but not sufficient for a good enterprise BPM system - “an aircraft carrier should never operate alone”.

In the absence of agreed reference models and proper standards, creating good enterprise BPM systems implies serious architecting efforts. Below I comment your list from the architectural point of view.

1. Your own enterprise “worklist” application has to be considered regardless of a BPM suite “web portal”. The users want to handle business processes in conjunction with their business objects, e.g. business cases.
2. Business events (receiving an order) are often already available somewhere in your enterprise systems. Just associate them with your processes.
3. Automatically generated forms are usually considered only for quick prototyping.
4. Existing reports are usually considered only for quick prototyping.
5. By definition, business objects as BPM artefacts have to be externalised. Dreaming to keep them within a BPM suite is wrong from the beginning.
6. Audit trails and KPI are other BPM artefacts — put them out of a BPM suite, by definition.
7. Documents are yet another BPM artefacts. Keep them out and do not forget about records management.
8. Handling of roles (also a BPM artefact) is usually difficult. I recommend to create a set of groups oriented to processes, e.g. process owner, activity workers, etc. and to populate these groups from available resources (processes are useful for that).
9. Agree - patterns and anti-patterns are necessary for constructions of complex processes (see my blog http://improving-bpm-systems.blogspot.com/ for some practical process patterns).

I think that any discussion about the architecture of enterprise BPM systems is step from the current vendor-centric BPM to customer-centric BPM.

Thanks,
AS

And you are absolutely right - I put “at some point” everywhere having exactly this in mind. Good BPMS lets you catch the process and deliver the value to the business amazingly fast and this creates the BPM magic: it’s the unique atmosphere of early success giving the way to even bigger success etc. In such atmosphere any issue from the post isn’t a big deal.

Мне особенно импонирует последняя фраза. Абсолютно верно: к определенным проблемам без BPMS лучше даже не подступаться. Ну а то, что при этом возникают новые проблемы, так это всегда так: много знания - много печали, а с увеличением площади круга растет длина окружности

Also, I’ll note that many companies are successful with only *some* of the changes you point out - for example, for some processes, the stock forms are good enough (usually, internal processes), for some processes the portal is “good enough”, and for some processes the data management baked into the BPM tooling is “good enough”. But, each process will stress a BPM platform in different ways, and push the boundaries on different parts of the solution. A good BPMS isn’t as good at forms design as a good forms designer… or as good at data management as a good OR mapper or the Spring framework… but BPM platforms should bring down the level of expertise required to get the basics working, and give you options to get more advanced as required by your process (or as required over time with your process). I think the magic of BPM is making all these myriad items play well together, making the whole greater than the sum of its parts - but that doesn’t mean you can’t upgrade some of the parts when you need to

Great food for thought -
Scott