Not Sold on "Dynamic #BPM"
- November 3, 2009
- 15 Comments
The concept of “Dynamic BPM”, when explained, is certainly useful. But I’m not much of a fan of the term itself. First, it is yet another buzzword that means whatever the vendor du jour says it means. So all the vendors immediately do “Dynamic BPM” and incorporate it into their messaging. IBM says that they do “Dynamic BPM” by automatically configuring the process in real-time (or read their own words here). Oracle says they do “Dynamic BPM” by incorporating rules-driven process flows, dynamic service binding, and task management. At recent BPM conferences, Dynamic BPM has been used to refer to “knowledge worker processes” or pieces of the process that can not be well-defined in advance (Anatoly Belychook’s blog describes this interpretation quite well, as well as a couple of useful design patterns within it).
Here’s where I see problems:
- This name “Dynamic BPM” doesn’t really mean anything – each vendor can make up a definition that suits their software, or their competitive positioning needs in current sales cycles. This just extends the already ambiguous use of the term “BPM”.
- IBM’s notion of “dynamic” is really more about configuring the process based on early inputs to the process instance about its requirements. A process that can’t do this doesn’t seem worth much to me. BPM tools have been doing this sort of thing (in abstract) for at least 7 years. However, they do have some technology to handle more complex factors (especially with respect to health care related industries). My favorite part about IBM’s description of “previous BPM solutions” is that they “weren’t designed with agility and dynamicity [sic] in mind”. That’s the kind of presumption you hear from someone writing product marketing content who hasn’t worked with those “previous BPM solutions” in the field (which, I can assure you, were often designed to be agile and dynamic).
- Oracle seems to think if you have rules then you have “dynamic BPM”. Last I checked, rules aren’t the future of BPM, rules have been around for decades as a business-enabling technology. Applying rules to BPM isn’t exactly a new idea. Just ask any of the former rules vendors, or Pega.
- Dynamic BPM as a substitute name for “unstructured process” or unstructured subprocesses is more along the lines of Anatoly’s blog. Its also the positioning of ActionBase and a few other vendors. The issue here isn’t a “can you or can’t you” model unstructured process as part of an overall structured process – the question is how much does the BPM vendor’s software help you model or execute such processes. Some BPM solutions help quite a bit (e.g. ActionBase), some help a little, some just don’t get in the way, and some don’t allow for this style of subprocess at all.
I think BPM Vendors need to keep focused on what their products do for business. A term like “Dynamic BPM” doesn’t tell me anything about what this feature or product will do for my business. That’s not a surprise when the tail is wagging the dog (selling software to IT with IT benefits, rather than selling IT to business with business benefits). Let’s drop the IT buzzword bingo and focus on what the business needs, shall we?