It seems the smartest guys in the room, BPM-wise, have suddenly discovered content management. Or, more accurately, have begun to imagine what an intersection between the two might possibly look like… as if that were almost possible. Ismael tosses out three candidates: 1. Manage the lifecycle of content objects in CM, and just store the links to them in the process instance. (Memo to FileNet. Hmmm, might work, maybe try this…) 2. Use the CM repository as source control system for BPM developers (Memo to engineering… Oh, never mind.) 3. Embed a subset of BPM inside CM to do document approval workflows (is there a CM product anywhere that doesn’t do this natively?)
webMethods’ always-entertaining Kiran Garimella, ebizQ’s latest BPM blogger, adds:
If BPM takes on management of process knowledge, as I think it should, what?s left for ECM? Will ECM morph into the middleware for management of transactional documents? After all, it seems pretty evident by now that we will never be a paperless society. Besides, a lot of enterprise content will be on PostIt notes (to the utter delight of 3M)…
What these guys forget is that life on earth did not begin yesterday, and business is not driven by XML messages alone. Any bank, brokerage, insurance company, utility, or healthcare provider today has a lot more IT investment tied up in ECM repositories than in BPM. And the lifetime of those content objects is far longer than that of the workflows that put them there. Ismael’s hypothesis #1 is of course a huge business already for FileNet (now IBM), EMC, Global 360, and others… and has been for well over a decade. Loans, claims, underwriting… Does any BPMS manage those processes for a G2000 customer without using ECM to manage the lifecycle of attachments?
Not to single out Ismael and Kiran, who really are the smartest BPM guys in the room. They’re just examples of the general fact that BPMS vendors (who did not come from the CM space) still don’t get CM: what it is, what its benefits are, and what its intersection with BPM should be. Retention management alone would be a huge step forward for BPM.
I went through this with all those vendors when I did my 2006 BPMS Reports. Several of the use cases in the evaluation had clear requirements for CM integration, but most vendors had nothing to offer. To them, integrating a CM repository was no different than integrating any other “legacy app.” Note: They tried the same gambit with business rules a couple years ago until Gartner crushed them for it on the MQ. Now they all include business rules in the BPMS, either out of the box, or prebuilt integration with ILOG, FairIsaac, or Corticon.
This is a huge missed opportunity for BPMS vendors, who have basically ceded the content-centric process space to the CM vendors. I have nothing against the new inexpensive bloggy open-source CM offerings, but let’s face it, it’s the CM installed base of FileNet, EMC/Documentum, IBM, G360 that’s – to borrow Willie Sutton’s phrase – “where the money is” in BPM. Introspecting the Java APIs is not enough. Native viewers, content events, team collaboration… This list of integration features goes on. All these vendors support SAP adapters, when a simple Java adapter might “do.” I think they would get as big a bang out of a few ECM adapters. (Memo to Sinur and Hill: Maybe put this in the next MQ criteria?)
[…] Crosno’s approach to the market is a bit different than others. In his view, it’s companies who have invested heavily in information management technology over the past decade – content management, knowledge management, collaboration – that are now looking to add process management. That’s one industry dynamic driving BPM. Crosno admits that much of G360’s customer base today is really document management and document workflow, not full BPM. Part of the strategy is to process-enable not only their own base of content-oriented customers, but those of FileNet, EMC, and other ECM leaders. (This is in sync with my post yesterday on the intersection of process and content. ) […]
I am quite aware of the mass of content lying around in ECM repositories (and a lot more lying outside it). Perhaps I was unclear in my post. My main point was that enterprise content (I am now speaking generically) is one of two kinds: knowledge artifacts that define how the business should operate, and transactional data that is generated as a result of those business operations.
Just as management of transactional data is a specialized subject and is best left to a DBMS (for short term) or a Data Warehouse (for long term), unstructured transactional content is best left to an ECM platform. Hence, I think of ECM as a ?middleware? for transactional documents (this includes not only business transactions but also email, presentations, web content, and so on). Rest assured, I don?t see BPM threatening ECM vendors (at least, not anytime soon).
However, knowledge artifacts (including business rules, operating procedures, decision criteria, control points, etc.) are best managed within the context of business processes (because these artifacts are artifacts about business processes), as opposed to storing them in dumb file folders or disconnected repositories. Therefore, BPM seems naturally suited to the management of such knowledge. These artifacts play a key role in project lifecycles and in the analysis of business operations. Again, a very natural fit with BPM. This is one of those interesting ?side benefits? of BPM that is perhaps not intuitive, but quite powerful in its own right.
Kiran,
First, welcome. I enjoy your blog. Second, I think the disconnect is where you speak of managing this information “in BPM.” If you mean managing it as instance data — well, no, I can’t agree. These knowledge artifacts – business rules, process models, organizational models, etc – not only cut across instances but across processes as well.
webMethods obviously understands this since, for example, Fabric 7’s Metadata Library provides unified access to things like business rules in addition to process artifacts. But to me, and most users as well, I don’t think of that as storing or managing the rules “in BPM”.
–Bruce
Hi Bruce and Kiran,
Interesting discussion going on here…
I think that Kiran touches on a reasonable point when talking about the fact that “knowledge artifacts that define how the business should operate” are stored in ECM systems and that this is not the best place for them. Corporate compliance regulations (esp. SOX) has led to a significant effort in documenting business processes and policies, since traditionally this has been corporate knowledge that exists in the heads of those that execute the process.
Many SOX and compliance applications were born that are effectively just templates on low volume document management systems. They were used to structure and capture the new process documentation (excel spreadsheets, powerpoint and word documents) and add some organizing metadata (typically following the COSO framework). Add to that, the test and audit documents of these human controlled processes and you’ll have a mass of process knowledge inside ECM, none of which actually enforces the operation of the process.
I think that if I read Kiran’s phrase “knowledge artifacts (including business rules, operating procedures, decision criteria, control points, etc.) are best managed within the context of business processes” too literally, it sounds like I’m actually going to have process definitions floating around inside actual executing processes. I would rather say “managed by a BPMS”, since a strong BPMS will provide everything from the modeling of the process (and rules), through its simulation as initial testing, to the actual execution and therefore enforcement of that process according to the needs of the business.
Getting organizations to move process definitions from “paper” into real executed BPM processes is difficult. I talked about a compliance maturity model for organizations in taking this step in a post a long time ago.
But as I realized, compliance and process definition documents make up a very small percentage of the actual data managed by ECM, compared to the correspondence, operational and transactional documents that are generated in day to day business. So process documents are a minimally important focus for the large ECM vendors. It is the effective capture, delivery, generation, collaboration and managment around transactional documents that represents an intersection of BPM & ECM that we see in many key business processes. And it represents the profits of EMC, IBM and others.
If you add structured business data into the mix, alongside seamless human-interaction models around all of this process (structured and collaborative) and information, I think we come back to Bruce’s earlier discussion around “What is Case Management?”
Integrating a repository with a BPM tool gets you little more than traditional imaging and workflow. Nice enough if you were Staffware, which I worked with in this mode for a while. But there are more compelling process/content suites out there that make the combination of business process and content work well, by actually allowing users to work with all their information in context.
I’m sure this great discussion will continue…
Cheers, Phil
ECM, BPM and solving business problems…
there are great software tools and suites out there that sit largely between [ECM & BPM], that consistently and effectively address burning business problems, like how to do new account opening, fraud resolution and HR employee onboarding better….
Phil,
I’m not sure you and Kiran are saying hte same thing. I think you touched on the key idea when you said “repository.” For me, the essential difference between data and content is that content is stored in a repository, i.e. it has metadata that describes it and to a degree, governs it – access, version, retention, etc. Most BPMS do not have a repository for anything other than process design artifacts, which is NOT what we’re talking about here.
The modeling pureplay guys like IDS Scheer, ProForma etc provide those kind of repositories, but BPMS in general does not. And probably should not, because policies, rules, etc exist outside the domain of any particular process, outside of BPM itself, really.
Saying that process governance is itself a process and it needs reference to those repository artifacts is true, but in my view beside the point. I guess I don’t see why a CM repository could not be used as a repository for these things as well.
Ah, clarity. Now you can guess which side of the ECM/BPM fence I came from 🙂 And that crazy time working in the corporate compliance & governance space just confused my interpretation of this language even more!
Bruce, the universal translator of cross industry terms!
Have a great weekend everyone.
[…] Process and Content – which one trumps the other In Kiran Kiran Garimella’s BPM Blog “Paper, paper, everywhere, but nothing intelligent to read” he responds to an earlier posting by Bruce Silver’s BPMS Watch » More on BPM and ECM. […]