Reframing BPM Automation
- June 14, 2010
- 5 Comments
Neil, always a thoughtful writer in our little corner of the world where business meets technology, has another note out about BPM and Process Automation not being a binary choice. I couldn’t agree more. So many times we are presented with false choices, that are incredibly binary – but the world isn’t really like that. The world is full of gray.
Moreover, disagreements are often an issue of framing. If you frame the discussion just a bit differently, there isn’t nearly as much disagreement, because now all parties have a new way to establish context to their arguments and perhaps see where the other folks are coming from.
Neil reframes the discussion of Automation and BPM – often people think that BPM is only about automation – and in so doing, resolves much of the potential conflicts for anyone that can agree with his framework:
It might seem like this is a bit of an academic way of looking at things, but it becomes particularly useful as a frame of reference, I think, in the context of discussions that are currently swirling around concepts like Advanced Case Management, Dynamic BPM, etc etc. I’ve seen a lot of debate about whether the scenarios described as being relevant in ‘Advanced Case Management’ can be addressed by ‘BPM technology’ and the only answer I can come up with is “it depends on how you scope your definition of ‘BPM technology’”.
In my mind (and I agree with Ian Gotts here, as well as with many others) the four aspects of software automation in BPM are independent of each other.
(emphasis added by me)
Well said. The four areas of automation Neil identifies:
- Automated direction of the flow of work
- Automation of the work tasks themselves
- Automation of support functions that help with monitoring/managing work
- Automation of the definition of work
Please see Neil’s post for the full write-up. As Neil points out, these four types of automation are neither mutually exclusive, nor mutually dependent. They are independent aspects, and I think you can reasonably apply any of these to BPM efforts.
As a side note, what we need in the discussion of ACM and BPM is a similar re-framing of the discussion. The two ideas are clearly complementary, and I see the opportunity to find a framework that BPM and ACM philosophies fit into. I made one attempt, because I felt that someone else had actually expressed it quite well as philosophically approaching “processes” or “knowledge work” from different points of view – where one tries to understand and improve the aggregate quality, output, and throughput – and the other tries to improve the specific instance quality, output, and outcome, expecting that improving the individual case will roll up to system-level improvements. I’m not passing judgment negatively against either by stating it that way – and I’m not constraining exactly where to draw the line – just stating a philosophical difference. Each philosophy has its place (in my view), and doesn’t require denigrating the other philosophy to justify its existence. However, the title of my post turned out to be ironic, as the comments implied a bit of controversy after all.