BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, December 01 2016, 09:47 AM
  4.  Subscribe via email
How do you think ECM and BPM relate to each other in today's enterprise?
Well, ACM certainly picks up ECM and I don't know of any ACM implementations that do not have background BPM, so we might as well talk about ACM, BPM, CRM and ECM all being core to Case.

See "Steering the ship - the new business management reality" via the link below...

  • Traditional BPM, with its focus on end to end processes, is now a core capability under Case that provides background orchestration and governance in respect of the performance of work,

  • Senior management no longer just stares at executive dashboards featuring KPIs, leaving operations to do what they like. Senior management is now able to piano-play their environment and not only challenge trends but also challenge KPIs themselves,

  • CRM has been absorbed into Case,

  • ECM is now embedded in Case.
References
  1. http://wp.me/pzzpB-P4
Comment
I need to read more of my blog posts.

Looks like the above is a close repeat of a rant dated 2012/05/16

"The final frontier? – ACM, BPM, CPM, DMS, ECM"

http://wp.me/pzzpB-jI

The relationships between ECM and BPM are difficult. The former has some (permanently improving) workflow capabilities and the latter has some (permanently improving) document management capabilities. Thus there is no clear boundary at the conceptual level and there is a huge overlap in tools because each vendor wants to beef-up the functionality. A standard API for ECM system does exist (CMIS) but it is rather limited.

Sometimes we need to initiate a process as a response to an event generated by ECM and sometimes we need to evolve a document through its lifecycle via processes.

As the both BPM and ECM are “eroded” by ACM and “business collaboration” products respectively their relationships are rather messy. Also the both of them are losing the ground to blockchain-based hype.

In a platform-based architecture [REF1], the both BPM and ECM:
are the essential components of the platform
are accessible via in-house specific APIs (which are built on product’s native APIs)
are called via their APIs from many integration and automation microservices
are viewed in some “zones” of a unified portal (e.g. list of folders, list of tasks, etc).

It will be nice that BPM and ECM vendors would stop positioning their products as the “centre” of the enterprise application architecture and would start positioning their products as good and useful “citizens” of the enterprise application architecture.

Thanks,
AS
References
  1. http://improving-bpm-systems.blogspot.ch/search/label/%23platform
Comment
Absolutely, Alexander !

CRM vendors also can be accused of claiming to be the "centre" of the enterprise application architecture.

My model of a run time environment featuring one split screen (calendar, to-do list) works for the type of work I do:

where Case is nothing more than a cursor position in a post-relational dbms,
where BPM sits comfortably in the background,
where you can attach anything you like and have version control (ECM),
where you can reach out/accept input from customers (CRM),
where the environment handles R.A.L.B. and F.O.M.M.
where we have a generic data exchanger for two-way conversations with devices and local and remote systems and apps,

the only thing I wish I had is auto-upload from Cases to our Kbase (relational to visual hierarchical)

David Chassels Accepted Answer
On same track as Karl ECM belongs to old IT...BPM supporting software will take care of content ...and deliver Adaptive.... in reality are we at tipping point where many of the old TLAs are sliding into history....?
Comment
Juan J Moreno Accepted Answer
Properly managing a business process and properly managing business knowledge are indivisible tasks. The same when managing the contents of your company: they are the explicit form of all your knowledge. Said that, I can not see BPM without ECM.

We have been working the last 15 years in joining these 2 worlds in simple, yet complete and powerful BPM Suites, that lets people take advantage of company knowledge stored in documents.
Comment
Bogdan Nafornita Accepted Answer
I am with Juan here, in my use cases ECM and BPM are so intimately linked that it's a shame to try to split them :-)

And while I agree in principle with Karl that every work objective is technically a case, I find it hard to explain such an inclusive concept to small customers.

On that note, I think the distinction between ACM, ECM, BPM and other related tech is increasingly just a vendor beef, with less and less relevance to customers, who are just seeing hybrid solutions that fix their needs. They don't need to understand the underlying tech more than for understanding how it helps their business goals.
Managing Founder, profluo.com
Comment
Boris Zinchenko Accepted Answer
Enterprise Content Management (ECM) is just one aspect of Business Process Management (BPM). Ideally, Business Process Management should stay in the center of all enterprise consolidation and improvement initiatives by providing common reference point for all other enterprise systems, both in terms of their internal processing and interactions in cross-system processes. Therefore, optimally, BPM should describe and control all processes inside Enterprise Content Management system.

In reality, BPM systems usually do not integrate well with Enterprise Content Management. Due to growing popularity of process management, many leading ECM systems tend to implement their own rudimentary built-in BPM functionality to be self-sufficient in this respect. As a rule, these built-in BPM systems are quite limited in capabilities and confine to core functions of specific ECM without wider implications. Alas, this trend prevails over standardization of ECM API to allow their external communication with full-fledged BPMS and wider enterprise integration.

http://caseagile.com/wp-content/uploads/BPM_ECM.png
Boris G. Zinchenko, Ph.D. is Chief Technology Officer of CaseAgile LLC, an innovative software and business service company specializing in integration of platforms and environments for enterprise modeling. http://caseagile.com/
Comment
@ Boris . . .You raise several important and very interesting points.

It is essential to have a core "command center" in a setup such as the one you have diagrammed, if only for resource allocation purposes. i.e as steps become current along a process template, they will not be serviced promptly if the performers cannot see them at some convenient UI. Important to have a common resource pool so that work moves forward smartly.

Clearly, the users have to actually go to the command center, so the best scenario is they load up the UI and keep it open all day long.

In our apps, we frequently broadcast an order to several people who have the rights skills to perform (members of "process_order") - we expect one to "take" and "own" the order resulting in faster processing than a broadcast to a particular individual. Broadcasting to individuals would be a disaster (away, busy, on vacation).

As for reachout/in, there is a tradeoff between, taking ECM as an example, attaching documents to steps, with, as you say, possibly reduced functionality, versus linking to a document that is in a proper ECM system.

There is another tradeoff in that some of these "peripheral" environments are slow to invoke from a distance i.e you have to message them, they respond, all of this takes time. So, more functionality at the expense of time, or the functionality you need with instant display/save is the tradeoff here.

The third and critical tradeoff (in some industry domains) is security.

Rights and Roles, in a healthcare EHR for example, are very complex and during any audit, agencies have to demonstrate or face severe financial penalties that in respect of a document with data on it (not a template) there are no back doors to the document from within, say, the ECM environment that has lesser security or any other system other than the EHR that talks to it. This can get complicated.

But, we can always encrypt so that even if a user can gain access to a document that contains data in some ECM environment, they cannot view the content except from with the core "command center"

I like your model.

We do all of this via a generic data exchanger that can, using parsers and formatters, talk to any number of subscribers or publishers multi-directionally.

We no longer call our "command centre" BPM (it has simply become a run-time environment that accommodates any mix of ad hoc and structured sequence step).

We tell customers we are "practicing ACM" in that environment but the environment is not an ACM environment nor a BPM environment.

Truth be told, the core capability is "resource, allocation, leveling and balancing" much like a CPM system minus durations at steps and with probabilistic branching/loopbacks etc as opposed to deterministic branching. Our healthcare customers typically handle 20-50 Cases per day per healthcare professional.
@Karl, I appreciate your detailed reply. Let me comment per every point mentioned.
We do not consider BPM as one stop GUI for daily user activity. Rather should be is an ultimate visionary platform, which serves to alignment of all real processes and transactions. In this role, BPM more serves for metadata aggregation and a reference guide than for real time control of operations. Users need not to navigate to BPM system in every step of their normal working activity. However, they can resort to BPM help in case of difficult practical situation where they are unsure about proper course of actions.
Taking analogy from a medical field, a regular medical professional is normally able to prescribe standard medicines and treatment to his or her permanent patient with a known diagnosis, who is under observation for a long time. However, for a new patient with a complex set of symptoms, a doctor may need to consult medical guides and experts in specific diseases. Same can be an ideal role of BPM, to serve as knowledge base and expert system on enterprise policies and best practices.
Another role of BPM, which is closely related to metadata aggregation, is high level view of overall process performance. This gives management good understanding of operational metrics and alerts on immediate involvement in case of unexpected problems. Same information can help workers on workplaces to estimate their personal results against overall company metrics and results of their colleagues. Again, BPM here serves not for command purposes but reference and consulting goals.
It might be wrong to expect from BPM an ability to command and aggregate all low level business transactions. As in any normal business practice, IT systems should have own dedicated levels of aggregation where low level activities remain confined to their dedicated system of execution and only overall performance metrics are translated to next levels. This simple principle allows optimally divide and orchestrate business and IT services on all levels with arbitrary scalability for a company of any size.
This also naturally solves the mentioned problem of security. Confidential data remain locked reliably in their systems of origin. Only higher level aggregates are translated outside. But these aggregates already do not contain any confidential personal information, which eliminates ability to compromise precise confidential content.
Related to ECM, individual documents and their routine routing, undoubtedly, should stay on ECM level, while BPM should serve to develop and enforce their processing schemes and optionally report process conformance problems and overall ECM performance metrics.
  1. Boris Zinchenko
  2. 1 hour ago
Hmm. thinking about these forum topics, however sparse the participation at some topics, often gives rise to interesting ideas.

In our run-time Case Management environment, we took an approach that allows a user to attach a template at any step within a sub-Case.

The problem I see with this is that any structured sequence that has sub-paths is likely to start off at some point on one sub-path with one template, convert that to a document and then want to refer to that document for the remainder of the sub-path until the processing gets to a merge point.

At the merge, who knows? We might be done with the document, or we might end up with two or more documents going forward.

The point is we could make things easier for users by making some default assumptions. This would avoid the current situation where the user on a sub-path has to pick the right document-in-progress - they might pick the wrong document or not know which one is the right document.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.