Blog: Demo vs. Production BPM-based Systems

<discussion ref="http://mainthing.ru/item/212/" />

Bravo, Anatoly. 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 link 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 usually 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