Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Posts Tagged ‘ECM’

(Русский) Откуда есть пошли контент-менеджмент и документооборот

Sorry, this entry is only available in Русский.

12/04/12 | Articles | ,     Comments: 6

Difference Between BPM and Workflow: Not Just Technologies

Janelle Hill from Gartner asked: “Do You Understand the Difference Between Workflow and BPM?“. I enjoyed the comment saying that her answer “makes it easy to show that BPM is not just workflow on steriods as some call it.”

According to Gartner, the ideal BPMS implements 10 technologies of which workflow is only one:

  1. Process Execution and State Management Engine - a component that implements workflow.
  2. Model-Driven Development Environment. But workflow products usually has a graphical modeling tool too. Limited (usually only the orchestration without choreography), not following standards (BPMN), but it’s there. Hence the score should be 2/10 instead of 1/10.
  3. Document and Content Management. In my opinion, there are structured data, unstructured content and processes. For each of them we have, respectively, DBMS, ECM and BPMS. It’s better to respect the borders: neither manage content via BPMS nor manage processes via ECM. After all we do not include Data Management into BPMS because DBMS is perfect fit for this task, so why the content should be different? 2/9.
  4. User and Group Collaboration. Yes indeed, but again - why considering this as part of the BPMS? Do we only collaborate within the process context? Of course not - there are projects for example. It’s absurd to have separate collaboration environments for processes and projects. 2/8.
  5. System Connectivity. BPMS treats the work done by people, document processing activities and actions performed by automated systems consistently, without bias towards the first (human workflow) or second (docflow). I’d place items 3 and 4 above here too as integration with content management and collaboration tools.
  6. Business Events, BI and BAM. Strictly speaking, only BAM is tightly coupled with BPMS, the other two can be used independently.
  7. Inline and Offline Simulation and Optimization. I guess only Gartner knows what “inline and offline” means here but it’s OK.
  8. Business Rules Engine. In theory it can be used as a global variables repository by any (preferably by each) corporate application. But in practice it’s mainly used by BPMS.
  9. System Management and Administration. Well any system has one form of it or another: 3/8.
  10. Process Component Registry/Repository. There is some kind of process repository in a typical workflow system, too. On the other hand it’s probably not the best idea to have a process repository within BPMS separated from SOA services repository. 4/8.

The final score I got is 4:8 rather than 1:10. But the scoring idea is silly indeed: there is something more than just technology at BPM side. Before comparing BPMS vs. Workflow one should stress that BPM != BPMS. BPM consists of:

  1. Methodology: hierarchy of organization’s goals, value chain, cross-functional business processes, process discovery, cycle of continuous improvement.
  2. Implementation: a program comprising a series of projects, agile development.
  3. Technology (BPMS).

Without the competence in methodology or implementation a BPM project is doomed even with the best BPMS.

You just won’t figure out how to use it right. BPM is integral and holistic discipline where three parts above perfectly fit to each other. For example:

  • There is no efficient process discovery (methodology) without rapid prototyping (technology).
  • There is no continuous improvement (methodology) without agile development (implementation).
  • There is no agile development (implementation) without process notation acceptable by business analysts (technology).

Unfortunately most of those who doesn’t see the difference between BPM and workflow believe “methodology” is a dirty word. The arguments above won’t impress them because they only believe in the technology of their own:

  • Continuous improvement? Nonsense, we must design carefully and most importantly - specify requirements thoroughly!
  • The graphical process diagram? The true program is made of the code, not by arrows and boxes.
  • We automate whatever business says.
  • Agile Development? Our users agree to work only with a system having full functionality.

Since workflow is nothing but technology it’s more comfortable for these kind of people than obscure, overhyped and overcomplicated (from their point of view) BPM.

Yet being limited by just technology is a weak spot of workflow. It’s typical usage is the automation of routine operations at the department level. It saves efforts and brings more order to the office but the company’s bottomline is not affected, the competitive advantage is not gained. In order to reach these targets we must deal with the value chain and end-to end processes, resolve resource conflicts around cross-functional processes, design a network of communicating processes…

So complexity doesn’t come from BPM but rather from business processes. The complexity of BPM is adequate to the complexity of business and the complexity of workflow is insufficient. Since the complexity of the control system can never be less than the complexity of the system being managed the complex task of business transformation in case of workflow is inevitably reduced to the office automation.

Getting back to technology, I would not say that BPMS wins workflow 10-to-1. But it doesn’t need to because there is another important aspect: BPMS is generally the next generation of technology. Thin client, XML and web, modern standard platforms (J2EE or .NET) and standard notations (BPMN, BPEL) instead of proprietary ones. In the rapidly changing IT world even a relatively small technology gap is fatal: when the majority of developers start treating some direction as obsolete, it quickly becomes marginal simply because nobody wants to deal with it without extra reward or pressure. Whether you like workflow systems or not, only those will survive who can switch to the mainstream: migrate to a modern platform, accept standard notation, implement the missing features from Gartner’s list, i.e. become a BPMS.

04/28/10 | Articles | , , ,     Comments: 3


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:

  1. structured information where DBMS excels
  2. unstructured information (documents) is what ECM is for
  3. 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.

02/05/09 | Notes | , ,     Comments: 4

Copyright © 2008-2023 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments