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
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
Posts
2 comments:
Alexander,
Thanks for the links and the discussion.
You have provided some examples where the ACM capability needs to be well integrated into the BPM capability. The "Office de faillite" application is an example that needs all of the capabilities that you mention.
There is no question that to implement such a system, having both BPM capabilities and ACM capabilities in a single system is not only convenient, it may be required. From this we can conclude that BPM Suites should acquire ACM capabilities, and we agree on this point.
But can we also say that all applications that need ACM capabilities will also need BPM capabilities? You have shown some applications that need process architecture, but can you say for sure that all ACM applications need this? I think not. There are (some) applications for ACM that have no need for the requirements that Anatoly listed.
My statements were not clear. When I said that ACM does not need process architecture, I should have said that ACM applications do not inherently need process architecture. Some applications need it, some do not; we can not say that all ACM applications need it.
Just as you have given examples of applications that require data integration and stronger process management, I can also provide examples of applications that do not. For example, judging an essay contest, preparing for a working group meeting, responding to an emergency, etc. A simple "Google Group" with email lists and discussion forums would be sufficient in most cases. Yes, an expensive custom application would do a better job, but it would be a stretch to say it was required.
Hopefully this clarifies my point: while ACM capabilities may be a feature of a BPMS, ACM in general is not JUST a feature of a BPMS. To say the latter would be misleading.
-Keith
http://social-biz.org/
Thanks Keith,
Your point is clear and fine by me.
Thanks,
AS
Post a Comment