Process Simplicity

There have been a growing number of conversations on the web around the differences between business process management (BPM) and adaptive case management(ACM) – for example here.  A lot of those conversations end up discussing the definition of BPM, and whether BPM Suites (the BPM tools, not the discipline) can actually handle ad-hoc, unpredictable human processes or not.

I don’t think we’ll ever find a definition of BPM (the discipline, not the tool) that everyone will agree upon. Just for argument’s sake I’d like to use the definition – “BPM is discipline of making work processes simpler”.  I know it isn’t a perfect definition – but using it does have interesting implications. 

  • What is a work process? Well, I think that is intuitively simple – those are the processes used to generate the work products required by the business. A more rigorous definition could be nice, but at least for me – that is good enough.
  • What make a process simple? Well first off, it has to be correct (i.e if the process doesn’t generate the required work product, then it may be simple – but the “null” case of simple doesn’t matter). So beyond correctness – what makes a process simple? I think that is a very hard question – but I found a nice set of ten “Laws of Simplicity” that I think are interesting to think about in this context (see John Maeda’s Laws of Simplicity).
  1. The simplest way to achieve simplicity is through thoughtful reduction.
  2. Organization makes a system of many appear fewer.
  3. Savings in time feel like simplicity.
  4. Knowledge makes everything simpler.
  5. Simplicity and complexity need each other.
  6. What lies in the periphery of simplicity is definitely not peripheral.
  7. More emotions are better than less.
  8. In simplicity we trust.
  9. Some things can never be made simple.
  10. Simplicity is about subtracting the obvious, and adding the meaningful.

I think the first four laws sum up a lot of how BPM makes a process simpler and what the modelling stage of BPM is about. As complex as models are, they are simplifying metaphor used by BPM practitioners. The model is BPM’s expression of law 4, the model is the knowledge about the process, and that knowledge is what enables the process to be made simpler.

I see  lot of the arguments between BPM and ACM around Laws 5,6 and 9 – about whether it is even possible to apply the BPM simplicity metaphors to certain processes. Applying laws 5,6 and 9 is a lot of where the line between BPM and BPMS blur. Models can mean lots of things – it can be as rigorous as a BPMN model or as loose as guidelines and checklists – almost every BPMS leans towards rigorous BPMN models. ACM proponents believe that there are a whole set of processes that can not be simplified using the basic BPM simplification tool, the rigorous model.

Law 7 is why I think Google Wave is an interesting paradigm for BPM – it focuses on discussions and conversations, things that get people involved and participating. The Social BPM movement is a step in this direction – but only for a very specific process, the process of creating a model.  These is nothing special about modelling – there are many other processes like it that would benefit from the appropriate tools. Also, BPMS would be better off if they started to account for Law 7 (though it sort of is “anti-techie”) and focusing as much effort on the end user experience as the process models. People use tools that they like and  that empower them – that is true both in a consumer and business settings.

As BPM has evolved a technical platform to support more and more process types – the tools have already become quite complex – and now vendors are adding rules and events. I think ACM is partly a backlash to that complexity – trying address Law 8 by limiting the scope of BPMS (though sometimes I think that Law 8 is just not appropriate for technical tools – technical people love complexity and features when it comes to their tools, the problem is when they think everyone feels that way too).

Finally Law 10 – This is an interesting law from a BPM perspective – isn’t BPM about exposing and codifying the routine (which is version of the obvious)? So maybe BPM’s job is to lay the groundwork so we can get to Law 10 in business processes, and something else will need to come along enabling the next step towards Law 10.


2 Responses to “Process Simplicity”

  1. Tweets that mention Process Simplicity | ActionBase Blog - Thoughts on Collaboration Process Management Unstructured Compliance and Audit -- Says:

    […] This post was mentioned on Twitter by process2go, ActionBase. ActionBase said: Process Simplicity – […]

  2. Process for the Enterprise » Blog Archive » Ukelson on Process Simplicity Says:

    […] with several previous posts from Mr. Ukelson, I really like this one, about Process Simplicity.  Simplifying and Simplicity have been themes of late- because what software needs, and […]

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: