When documents and processes come together
Ian Gotts of Nimus: "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."
Malcolm Ross of Appian: "There's a definite need to unite the features of these two worlds to create more powerful content and process systems."
Doug Mow of Virtusa: "From the customer, patient, subscriber or end user perspective I want a seamless UI that doesn't distinguish between any class of functions. "
Brian Reale of ProcessMaker: "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. "
Peter Evans-Greenwood: 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.
I'll quote my own response in full:
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.
This is one of those tough areas where the integration of technology for vendor gain often eclipses the needs of the end customer. Careful consideration is required on what is needed for any particular business, and navigating the options depends largely on experience.


2 Comments:
The most successful BPM systems have to be capable to work closely with the corporate content, i.e. documents. For example, if your BPM system automates business trip processes, it has to be capable to prepare and to provide users all the required documents - business trip notices, business trip reports etc. It can be realised by the integration with some office applications, but it has to be done definitely.
Moreover, the evident weakness of many BPM systems mostly automating office BPs is the result of their inability to provide users ready to print documents following BPs
By
Anonymous, at 2:43 PM
Well, I agree that integrating content, whatever the source is important. Though I fail to see why it should be so hard to print those documents. If the data is actually being prepared by the business process management tool, then maybe what users require is some templated way of presenting structured information in a document style allowing them to print it (so they can take it with them when they travel?). This is certainly a capability I have provided in my solutions, a document template that creates a nicely readable output of data from the process. Though I rarely encourage customers to be printing the result (we're trying to save the proliferation of paper documents!) though it could certainly be done if necessary. You are right though, that many BPM systems don't think much about making data useful outside of the structured online database world.
By
Phil Ayres, at 7:19 PM
Post a Comment
Links to this post:
Create a Link
<< Home