The same old question arose on a forum once again:
“In fact many BPM tasks could be solved with a document flow as well as with a DB. Yet results may not be very good…”
This is obviously a FAQ so I’m going to give a deailed answer, re-formulating the question for generality.
Question - What are the borders between DBMS, ECM and BPMS? How should they be combined?
Answer - Generally speaking we have:
- structured information where DBMS excels
- unstructured information (documents) is what ECM is for
- process information is BPMS target
(BPMS uses DBMS internally and ECM may use DBMS or file system for storage but it’s beyond our scope.)
Every member of DBMS-ECM-BPMS trio is able to replace any of two remaining brothers but only some more or less nasty way:
- DBMS can store documents in text and binary fields yet it’s far from ECM functionality e.g. in navigation, content search, versioning, access control, MS Office integration.
- DBMS is sometimes used to store process information, usually in a table where each rows defines the next step of document processing. Of course it’s very primitive if compared with BPMS process diagram.
- ECM has a workflow or process engine yet it doesn’t match BPMS because of proprietary notation, platform, integration tools and what’s most important due to the lack of continuous process improvement methodology support. Simply speaking, a business process can be implemented in ECM but it’s hard to modify it with the speed required by business.
- Structured data can be entered into Excel file and stored in ECM.
- BPMS has typed attributes for structured data but clearly it’s for limited use only - the performance is nothing compared to that of DBMS.
- BPMS lets you attach documents to a process instance yet as well as in DBMS case, the service will be very primitive if compared with ECM. Besides there is a question: how are you going to reach your documents when the process has ended?
So if you are planning the perspective infrastructure then you’ll need all three components. On the other hand, if you face a task limited by functionality, resources and/or timeframe then you may look for a poor-man’s solution by compensating missing components with present ones.
Make your strategy balanced over time. E.g. BPMS document capabilities may suffice for a pilot stage of a BPM project. A pilot project should answer the question - “do we need all this staff at all?” - in the shortest timeframe. In case of positive answer we can add ECM afterwards.