Start a Discussion
BPM
user-pic

Is It Inevitable That ECM and BPM Will Be Integrated Into One System in the Future?

Vote 0 Votes
An issue that was raised in this Forum, What's the Difference Between case management and BPM?, and on this blog, BPM and ECM -- The War Begins, do you think it's inevitable that enterprise content management and BPM will be integrated into one system in the future?

10 Replies

| Add a Reply
  • The two are inextricably linked already. If I want to perform some task such as sign off a PO then I probably need to access the Purchase Policy document which will be part of ECM. So Nimbus Control has a combination of BPM & ECM and has had for the last 10 years. That is because we are user-centric process management rather than a process workflow engine.

    But there is another area that is becoming combined with BPM and ECM. That is LMS (Learning Management Systems).

  • Already there.

    Appian has had integrated and full featured BPM / ECM for years. The market needs to make the definitions clearer and the set the bar higher for vendors.

    For starters: To all BPM vendors, attaching a document to a task is not ECM. To all the ECM vendors, routing a document for approval is not BPM.

    There's a definite need to unite the features of these two worlds to create more powerful content and process systems. Maintaining an integration between separate BPM and ECM systems can be costly and prone to breaking as each platform upgrades and changes APIs. An integrated approach provides much more power and a lower total cost of ownership.

    Malcolm Ross
    Appian

  • As noted in the comments above, we are already there. I would probably make a further distinction between the relationship of BPM - ECM - DMS. It is one thing to route a document or a PO, add a signature, and then store it in a DMS. It is another thing to start a process in a rich contextual environment and have that environment intelligently populate with the pertinent information based on attributes like user, place, time, and company policies. In my opinion, the later is the future for ECM-BPM integration and it goes way beyond simply storing a signed PO. So, yes, most BPM vendors can store documents, but none are providing this type of build-your-own context sensitive content environments. However, I believe this will be the trend in ECM and an ECM-BPM buildout. And, in many ways, this is the next big thing in BPM (just as it already is in social networking).

    Brian Reale
    http://blog.processmaker.com

  • The mashup is necessary and not the final state. What about social and BI?

    Of course from the technology vendor perspective, these distinctions are necessary as camps of vendors have already pledged their allegiance, re Open Text vs. Pega.

    From the customer, patient, subscriber or end user perspective I want a seamless UI that doesn't distinguish between any class of functions. I want to be able to:

    - Be led through a process that is intuitive and easy to follow
    - Have access to context specific information that is relevant to the need I have at that particular time in the transaction process
    - Understand the ramifications of my decision by looking at the percentage outcomes of those that have made these decisions before me
    - Interact with the collective to collaborate and make the best possible decision for me and/or my company
    - I want it on the device of my choosing whenever it is convenient for me

    That would seem to point to a wide range of product and service capabilities that may span many vendors and many categories. But looking from the outside, this is how consumers need to see it.

  • The short answer is this: in any business that uses BPM in critical applications, BPM is already integrated with ECM. I think it unlikely that we'll see anyone but IBM and maybe EMC really producing a credible E-BP-CM suite.

    Why do I believe this? Well, its important to ask why ECM is so important to businesses... Its not the collaborative-Sharepoint-less, "let's be happy and work together" stuff. Its the fact that in real business, at the end of everything we do in a business process there needs to a record of the transaction, the decisions or whatever that formed the outcome. Of course, that does not need ECM if the data we were work with at every step was fully structured (an online form producing structured database records). But for the real world, documents do exist, and ECM provides a way to handle them.

    As Doug says we must interact with documents, and as the vendors hinted, document management ain't that hard for BPM vendors.

    The problem is that throughout a process, documents will form part of the final business record. BPM vendors rarely manage to focus on understanding the complexities of electronic document and records management, therefore they rarely do much more than routing documents -- plain old-fashioned 'imaging and workflow'.

    What is really needed from BPM is a final step: registering the records and the decisions of the process in the corporate records management system, keeping the context of everything that was done. Working with documents and process context appears in some of the marketing around case management. Though more often than not people get more excited about how processes can change dynamically, than how they can be recorded permanently. So I expect adaptive case management (ACM) to be another missed opportunity.

    It really is a shame that records management has such a 'stodgy' appearance, since it is such an important part of business processes.

    Phil Ayres
    http://blog.consected.com

  • Hiya,

    It's probably a bit early to call this, as document and records management is ripe for reinvention. What's a document/record anyway? A page in a wiki? An email? SMS? A tweet? Defining the scope of BPM and ECM as processes and documents ignores the ongoing erosion of boundaries between organisations and communications channels, and existing solutions are too intrusive to push into these new channels. (Plus, in many instances, you don't own the document or record in question.) Rather than an integrated platform, it's more likely that something new will emerge which has aspects of both, aspects neither has, and sets aside some of the functionality which has become redundant.

    One theme which comes out in the comments is the shift from the data-centric to decision-centric enterprise, which I completely agree with. It's decisions which drive value, not processes and data. The plugging-together of existing BPM and ECM platforms is both a symptom and short term response to this.

    Which brings us to another interesting point. The need for records management is largely driven by compliance and discovery requirements defined by the legal framework companies operate within. This framework was defined back in the day nod and has, at its root, the assumption that a company is an autonomous entity with a strong barrier between inside and out. We've hit a point where this assumption might no longer hold. If a key decision in a business is driven by data sourced from a range of channels (twitter, email, structured data), platforms (public vs. private) and sources (inside, outside, public, private) then how do we audit this? What does discovery look like?

    I expect there's a wave of work to be had for the accounting firms as they work to develop the governance and discovery regulations for the next century.

    r.

    PEG

  • In practice, workflows are not necessarily about content. The two domains, process and content, relate and overlap but only in parts.

    BPM covers processes that are not necessarily related to content. Also, as a disscpline, BPM is different from content management since BPM may refer to manufacturing processes moving parts for instance.

    The discussion seems to be about BPMS (BPM IT Systems rather than BPM) that model, automate... processes; not all processes are content related. BPMS may cover control or data flows as well. Structured data is not usually characterized as content.

    In conclusion, BPMS and ECM systems partly overlap but do not really converge since both have their own domain and standalone applications. Of course, in a SOA world, you may combine services from both as you need them. Otherwise one may employ a monolithic BPM-ECM system in all cases.

    Adrian @ http://www.enterprise-architecture-matters.co.uk

  • Absolutely not!

    I strongly disagree with many of the prior comments that BPM and ECM will or should merge into one system.

    I want to ask the genteleman from Appian three simple questions, given his comment that Appian has been selling BPM and ECM combined for many years:

    1. Is Appian known as a leader in BPM or ECM?
    2. Why is the Appian product called Appian BPM Suite? Why not BPCM Suite or somthing to give recognition to the poor ECM orphan?
    3. Most importantly: If a customer is only looking for ECM (which thousands do every year) will Appian sell them the Appian BPM Suite?

    The point I am making is that BPM and ECM are two very distinct and very large requirements with some overlap. One cannot simply look at the overlap and say, forget the rest, this is something that one product can satisfy!

    Ever since I have been in the BPM/ECM space for over 16 years now, I have seen numerous BPM companies dabble in ECM and gone no where with the effort. They have great BPM but mediocre ECM at best. Likewise numerous ECM companies have dabbled in BPM, but have never been able to grow into leaders in the latter. Does anyone buy Documentum if they are looking to automate their processes?

    The reason is simple. BPM and ECM have many non-overlapping requirements, and some overlapping requirements. No single product can excel at all these requirements. Moreover the customer who is looking for ECM, in most cases, is not also looking at ECM at the same time. Ditto for customers looking for BPM. I sometimes use the example of trucks, automobiles and forklifts in my blogs when talking about ecosystems. They all look the same. They have wheels, engine, steering wheels, seats, etc. They are all means of transportation, but their requirements are very different. To suggest that ECM and BPM requirements can be handled by one product is to suggest that a company should buy a fleet of trucks and use it for all the things that trucks, plus cars, plus forklifts are used for. Everyone will laugh at this suggestion!

    That is why I laugh at the suggestion that it makes sense to combine BPM and ECM into one system!

    Rashid Khan
    Chatty Solutions


  • It may also be interesting to reflect on the previous Forum question that Peter’s question refers to - “What's the Difference Between case management and BPM??. The discussion on this topic appeared generally convinced that BPM should be associated with low-variation processes (valuing repeatability and therefore optimisation) and case management with processes where high variation is the norm.

    There seems to me to be a pretty strong correlation between process variation and the use of unstructured data in the process. For example, unstructured data (such as a hand-written letter from a customer) often requires human interpretation, which itself tends to produce process variation. Equally, most professions associated with case management (lawyers, health workers, etc) make much use of content.

    At the other extreme, processes that make no use of ECM, requiring only input from structured data sources such as CRM systems, internet forms and integrated systems (such as telco provisioning) are very low on variation and therefore perhaps the purest form of BPM processes.

    So perhaps case management will converge with ECM before BPM does?

  • I think Mr. Khan has hit it on the head w.r.t. the fact that these product categories have so many non-overlapping requirements. They are highly complementary products (thus, Doug and Phil's comments about mashup / integration). But in my experience, leveraging ECM from BPM isn't hard - its very straightforward, in cases where ECM has exposed reasonable webservices and document interfaces (for example, an interface for in-browser editing of a Word doc). There's not much need for the customer to buy both products from the same vendor, from a technical point of view.

    Having said that, there are lots of reasons for consolidation - mainly, efficiency of these big companies' sales channels. And reasons for customers to buy from a single vendor are well documented: single contracting process, discounts, hopefully somewhat better technical integration or authoring integration.

    Its hard to say today how ECM will develop. Could it be that ECM becomes just a "feature of a database"? Could BPM just become "a feature of any software development platform"? or "a feature of Visio"? :)

    I'm being a little absurd, but just to make a point - it is hard to see what the future holds for these spaces. It is up to the vendors (and customers) to show us the way.

    Scott

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT