I'll admit that the coming-together of processes and documents (BPM+ECM) has been a common theme of this blog for the four years that I've been spouting-off here. My background was imaging and workflow, then I got trapped along the way in understanding records management and even more trapped when process improvement became BPM suites, and more about the process than the stuff in it. I can not avoid feeling that I've heard this all before, but still wasn't satisfied.
Yesterday, a forum on ebizQ brought together some of the opinions about the question "Is it inevitable that BPM and ECM will be integrated into one system in the future?". For companies running both of these technologies in house, the answer is probably a no-brainer. ECM and BPM are already integrated, because the customer did it themselves. For vendors, nobody has worked out really if they can make money from it.
I've included some quotes from the forum that I think sum up the range of opinions, though its worth reading through the whole thing if this topic interests you:
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.
A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com
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
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.
Post a Comment