BPM vs. Unstructured, Ad-hoc, Human Processes

I am starting to see a lot of BPM vendors jump on the unstructured, ad-hoc business process bandwagon. That is good, since it validates the value of being able to manage these processes, but since there is no standard terminology to discuss this issue, it is difficult to understand who does exactly what. Hopefully WfMC’s work on Adaptive Case Management will help with the appropriate definitions and descriptions.

I think the key lies in whether the existence of a predefined process model is a cardinal requirement. BPM requires a process model as a starting point for process definition. Without a model – you can implement a process – but it isn’t BPM. Various flavors of BPM extend the notion of what can be expressed in the model (e.g. dynamic BPM allows models to be extended by rules), but they all require a model as a first step. For most BPM suites the more rigorous the model the better – since it allows the model to be executable.

Now to define the simplest basic requirement for handling unstructured processes –enabling processes with emergent models – i.e. the participants are building up the models as they execute process instances (perhaps with some loosely defined guideline or best practice as a starting point). I will claim the ability to do that is at odds with the basic definition of BPM, since it precludes a model based approach.

Let’s say you want to use a BPMS for an emergent process. So first you need to either:

  1. Build a trivial generic model, but then engine wouldn’t be able to do much and it wouldn’t be much help to the participants. Anyway, trivial examples aren’t of much interest in a real world business environment.
  2. Build an outline of a process, but allowing every step to be optional and have an associated exception point – again as an executable model it wouldn’t be worth much.
  3. Build a detailed model (including rules) capturing as many variations on the process that make sense. Of course this makes the modeling process VERY complex but I think most BPM suites would claim this is the way to go. In any case it still won’t work for emergent processes.

Let’s assume we go with option 3 above – the process is modeled as best as possible, including all the known variations.  But since it is modeling an emergent process, by definition we won’t have modeled all possible paths for the process and the participants will need to change the process during execution. The ways they have for doing that are:

  1. The participants change the general model (either the model or the rules) – this is very dangerous, and the more rigorous and complex the model the greater the chance to screw up something big time. It also doesn’t make sense since this really might be a one-off execution.
  2. The participants have their own “local” copy of the process and they modify that. Still would be a lot of work for the participants, but there would also be all kinds of issues of multiple models existing for the “same” process – how to reconcile the changes, how do you store and access variants on a given model etc.
  3. The participants do things “outside” the existing  model.
    1. It is outside the model, but under the control of the BPM engine.  This requires a whole set of new capabilities for the engine. The engine will need to be something much different than a standard BPM (BPEL or BPMN) execution engine. The engine will need to become something VERY different (I would think encompass something much closer to a collaboration tool) – and then of course figure out how to reconcile that back into the original process. It opens a whole can of worms from an execution perspective – and it certainly isn’t anything like BPM today.
    2. It is outside the model, and not under the control of the BPM. If this happens all the time then the model is not worth much, and neither is the engine.  So why start with the model at all?

So a key aspect in using BPM for managing a process is the ability to model the process (and manage that model) in a cost effective way. Unstructured, ad-hoc human processes can’t be modeled (or at least in any cost effective way) so current BPM tools can’t really handle them. Managing human processes requires a different, complementary set of technologies – and a different mindset.

Advertisements

2 Responses to “BPM vs. Unstructured, Ad-hoc, Human Processes”

  1. Scott Says:

    Enjoy reading your blog posts, just wanted to chime in with a (somewhat) different perspective –

    “Unstructured, ad-hoc human processes can’t be modeled (or at least in any cost effective way) so current BPM tools can’t really handle them.”

    Well, actually, having looked at actionbase, it certainly looks as if you have a model for ad-hoc human processes – and i don’t see why it can’t be implemented in “BPM” although all the interesting technical stuff happens AFTER design time rather during the design phase. ie, if I have a system that allows a user to specify tasks and routing in a word doc, at runtime, and each user potentially can add to that- there is still a “meta-model” for this kind of process. (In fact I’ve implemented such processes before)

    I’m not saying that your approach to ad-hoc human processes isn’t valuable – I think it is, I just tend not to use words like “can’t” with respect to software, because these BPM engines are likely Turing Complete… and therefore can solve any computable problem, including allowing users to define process steps and routing at runtime… the only issues are fit-to-purpose and cost-to-implement.

    Having said all that – your last sentence makes a great point – it requires a “different, complementary set of technologies – and a different mindset” – Couldn’t agree more – I think the pairing of traditional BPMS with an approach like actionbase makes a lot of sense. (structured where it makes sense, unstructured where it doesn’t, etc. )

  2. Johan den Haan Says:

    Hi Jacob,

    Interesting post. I agree with your statement that ad-hoc human processes can’t be modeled, at least not with a static process model. Recently I have written some musing about process-centric vs. information-centric SOA (see http://www.theenterprisearchitect.eu/archive/2010/01/13/the-process-centric-vs-information-centric-approach-to-soa ). I think modeling processes with rules/events instead of static process model can be a solution to the problem you sketch. Just wondering what your opinion is….? How should we approach ad-hoc human processes in your opinion?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: