Not Sold on "Dynamic #BPM"

Scott Francis
Next Post
Previous Post
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:
  1. 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”.
  2. 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).
  3. 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.
  4. 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?
  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Not Sold on “Dynamic #BPM” -- Topsy.com()

  • Scott

    Sorry, didn’t get your point: are you against the term “dynamic BPM” or don’t see anything new in the concept?

    From my perspective, there always was customers demand for something more “liquid” (using old BEA motto) than predefined diagram-based BPMS. And this demand is growing: more people start using BPMS – more visible this limitation become. On the other hand, the new generation of web-based collaboration tools raised the expectation so customers are less willing to accept current BPMS limitations and it’s becoming harder for the vendors to ignore this demand.

    As for the term, I believe “Dynamic BPM” isn’t worse than any other and probably it’s actually better because it’s intuitive for the customers. Of course vendors play the old term substitution game as they do it with BPM itself (you noted it right) and any other technology. Isn’t ERP a confusing term? DBMS probably isn’t nowadays but I recall how it was.

  • Scott

    Sorry, didn’t get your point: are you against the term “dynamic BPM” or don’t see anything new in the concept?

    From my perspective, there always was customers demand for something more “liquid” (using old BEA motto) than predefined diagram-based BPMS. And this demand is growing: more people start using BPMS – more visible this limitation become. On the other hand, the new generation of web-based collaboration tools raised the expectation so customers are less willing to accept current BPMS limitations and it’s becoming harder for the vendors to ignore this demand.

    As for the term, I believe “Dynamic BPM” isn’t worse than any other and probably it’s actually better because it’s intuitive for the customers. Of course vendors play the old term substitution game as they do it with BPM itself (you noted it right) and any other technology. Isn’t ERP a confusing term? DBMS probably isn’t nowadays but I recall how it was.

  • Anatoly –
    As you surmised, my issue isn’t with any of the underlying concepts or with making processes capable of handling less predictable or less structured process or subprocesses. My issue is with the term “Dynamic BPM” that people are floating around (a) as if it is a new idea… and (b) as if it is differentiating from some older form of bpm. If you are getting your dynamism from rules, talk to someone from Digital Equipment Corp or Xerox about how long they’ve been using rules to model decisions in software. Its a very old idea.

    I think the better category of “dynamic” BPM to discuss is the category you put under that label – interleaving structured and unstructured elements of process to achieve a good result. The growing demand for this is a result of people finally understanding the distinction, I think, between top-down prescribed process vs. discussion or collaboration-oriented work that might surround structured processes, or might compose a single “activity” box on the structured process (At one company I worked with, when we interviewed people, at the end of the day all the interviewers would get together to discuss the candidates – modeling that interaction as a process would be silly – but the fact that we had such a meeting was integral to our interview process… ).

    No one mistakes Collaborative or Unstructured processes as meaning “I use Rules or Configuration Rules to do that process”… And, instead of saying “dynamic process” these stack vendors should be a bit more honest that what they are providing is Rules + Process. Which is fine and dandy, it just doesn’t sound “new” when you pitch it that way. For example “dynamic service invocation” is something that I’ve been doing my whole career in BPM… so I don’t see how it is new… :) It just tells me that some of these vendors’ offerings were even worse than I thought before they started using the label “Dynamic”…

    Now… back to terminology – Dynamic is an IT term, not a business term. If your customers are IT folks, you’re fine. If they’re business folks, I think there are better descriptors. And if there aren’t, we should work on one :)
    A few ideas:
    – Collaborative Processes
    – Knowledge Worker Processes
    – Self-directed processes (this reminds me of self-directed majors in university)
    – Auditing processes

    Others? comments?

  • Anatoly –
    As you surmised, my issue isn’t with any of the underlying concepts or with making processes capable of handling less predictable or less structured process or subprocesses. My issue is with the term “Dynamic BPM” that people are floating around (a) as if it is a new idea… and (b) as if it is differentiating from some older form of bpm. If you are getting your dynamism from rules, talk to someone from Digital Equipment Corp or Xerox about how long they’ve been using rules to model decisions in software. Its a very old idea.

    I think the better category of “dynamic” BPM to discuss is the category you put under that label – interleaving structured and unstructured elements of process to achieve a good result. The growing demand for this is a result of people finally understanding the distinction, I think, between top-down prescribed process vs. discussion or collaboration-oriented work that might surround structured processes, or might compose a single “activity” box on the structured process (At one company I worked with, when we interviewed people, at the end of the day all the interviewers would get together to discuss the candidates – modeling that interaction as a process would be silly – but the fact that we had such a meeting was integral to our interview process… ).

    No one mistakes Collaborative or Unstructured processes as meaning “I use Rules or Configuration Rules to do that process”… And, instead of saying “dynamic process” these stack vendors should be a bit more honest that what they are providing is Rules + Process. Which is fine and dandy, it just doesn’t sound “new” when you pitch it that way. For example “dynamic service invocation” is something that I’ve been doing my whole career in BPM… so I don’t see how it is new… :) It just tells me that some of these vendors’ offerings were even worse than I thought before they started using the label “Dynamic”…

    Now… back to terminology – Dynamic is an IT term, not a business term. If your customers are IT folks, you’re fine. If they’re business folks, I think there are better descriptors. And if there aren’t, we should work on one :)
    A few ideas:
    – Collaborative Processes
    – Knowledge Worker Processes
    – Self-directed processes (this reminds me of self-directed majors in university)
    – Auditing processes

    Others? comments?

  • OK, thanks for complete clarification. Gartner pushes “knowledge worker processes” term – a bit complicated to me but they are strong in establishing terms so let’s see.

  • OK, thanks for complete clarification. Gartner pushes “knowledge worker processes” term – a bit complicated to me but they are strong in establishing terms so let’s see.

  • Anatoly –

    you’re right, and I think it does describe a subset of processes that are “unstructured” but I think it describes the user rather than the process (or problem) – which is why I like the other terms better…

    BTW, I like the name of your patterns on your post “A little help from a friend”, for example. I think having good names for patterns is part of the magic for helping people remember to use them (think four horsemen in Java).

  • Anatoly –

    you’re right, and I think it does describe a subset of processes that are “unstructured” but I think it describes the user rather than the process (or problem) – which is why I like the other terms better…

    BTW, I like the name of your patterns on your post “A little help from a friend”, for example. I think having good names for patterns is part of the magic for helping people remember to use them (think four horsemen in Java).

  • Scott

    I learned this kind of magic on a training last year, it’s called “switching the communication protocol”. We use scientific protocol mostly for our IT jobs: definitions, logical conclusions, democratic style of discussions etc. But there are also administrative (“you do this now!”), conflictological (“I’m on your side”, the “win-win” kind of talks) and metaphorical. The latter is specifically prescribed for new ideas generation. It turns out to be more powerfull than scientifical e.g. when a team makes an early attempt to design the future. One of the most important recommendation was about brain storming sessions: the session moderator should be able to detect the protocol used by participants at the given moment and to switch the protocol to more appropriate.

    Yet it’s a new technique for me so I appreciate your side note very much – seems that it works!

  • Scott

    I learned this kind of magic on a training last year, it’s called “switching the communication protocol”. We use scientific protocol mostly for our IT jobs: definitions, logical conclusions, democratic style of discussions etc. But there are also administrative (“you do this now!”), conflictological (“I’m on your side”, the “win-win” kind of talks) and metaphorical. The latter is specifically prescribed for new ideas generation. It turns out to be more powerfull than scientifical e.g. when a team makes an early attempt to design the future. One of the most important recommendation was about brain storming sessions: the session moderator should be able to detect the protocol used by participants at the given moment and to switch the protocol to more appropriate.

    Yet it’s a new technique for me so I appreciate your side note very much – seems that it works!

  • Dynamic BPM as you said it is a buzzword. It means nothing and delivers nothing new. For me, dynamic would imply adaption of a process, but we know BPM doesnt allow this in a real sense…You can only deliver Adaptive processes if you ditch the reliance on a designer tool and map that strictly builds the process.

    I am not saying go Case Management, but using a rigid map and designer tool stops any form of adaptive processing…With my consultant hat on, if a BPM vendor told a customer of mine, “we are dynamic” I would urge them to be shown the door….

    • Dynamic, adaptive… to me these are words that mean, at run-time, I can change the behavior of a process (as a user), and that the software supports that. Or, additionally, that I can change something other than code (as an author) and change the behavior of the process.

      But neither term focuses on business benefit. The benefit isn’t to be dynamic or adaptive. The benefit is what being dynamic or adaptive gets you, the business user/customer.

      The vendors are (too often) still selling to IT.

      • I agree with you here, but I have yet to see a real adaptive BPM solution. When they say “change at run time” these are variables within the process, as opposed to the actual structure of the process itself…

      • No argument from me :) In some environments the structure itself can be parameterized… but it takes a pretty skilled and creative author to set those types of processes up, and there are still limitations. It reminds me of a conversation I once had with the ACM crowd. The argument was not all decisions can be exploded in a hail of decision gateways – I pointed out that often decisions can be treated as data, rather than flow – greatly reducing the reliance on flow to represent decisions that don’t really impact the process flow (ie, they don’t change the nature of the business process).