2011-01-23

Contribution to: ACM: Feature or Paradigm

This is a contribution to a very interesting discussion "ACM: Feature or Paradigm" at http://social-biz.org/2011/01/22/acm-feature-or-paradigm/ and http://mainthing.ru/item/401/

Some of Keith’s arguments do not correspond to my experience with collaborative and process-based applications. Attention, please – those applications were designed for clients (including international ones) based in Switzerland – maybe similar applications for the US-based clients should be different.

At first, as usual, it is necessary to emphasize that BPM is a process-oriented management methodology, BPMS is a technology and ACM is a technology. So, it is not correct to compare BPM vs. ACM. My point of view about their relationships was expressed in http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html

<quote>BPM needs process architecture, ACM has no such need </quote>

Work of a social worker is based on the existing rules, procedures and laws. Some of them are expressed in as processes. So, the process architecture is necessary; it must exist but it is not visible (similar to the 90% of an iceberg); and preferably it should be explicit.

For example, an application for automating “Office de faillite” (a governmental structure to implement bankruptcies) is a mixture of ACM features and classic BPMS because the bankruptcy process template is defined in the law with many slight variations. Although each bankruptcy case (process instance) is different, they use the same process architecture which is the proof that each case follows the law.

<quote>In BPM the person who designs the process needs to be a data architect, but in ACM these are different roles.  The person who designes the “process” does not need to be a data architect. </quote>

Although many BPMS vendors provide data modelling capabilities, it is not always that a BPMS-based implementation of process-managed application forces the process architect to be a data architect. Some process-oriented applications are just moving existing data from one place to another or collecting process metrics.

<quote>BPM needs strong capabilities for integration, but in ACM there is little or no need for field-level integration. ACM can work well with documents, reports, and links to other application user interface.</quote>

At the beginning, the users of collaborative applications are very happy with just the access to documents, reports and links. Then those users ask for provisioning more case-related information which is usually “mastered” in central resources. For example, a Word document should contain several attributes extracted from SAP.

The mentioned above “Office de faillite” application is integrated with a corporate finance system, a corporate electronic publishing system, a corporate document management system, a country-wide postal-addresses system, etc.

In conclusion: considering that “knowledge workers” and “workers who are doing repeatable work” are working TOGETHER, the capabilities from both ACM and BPMS should work together. As the first step for achieving this synergy,  it is necessary to provide the commonly-agreed reference models and reference architectures (independent from the tools).

Thanks,
AS
Post a Comment