Reframing BPM Automation

Scott Francis
Next Post
Previous Post
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:
  1. Automated direction of the flow of work
  2. Automation of the work tasks themselves
  3. Automation of support functions that help with monitoring/managing work
  4. 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.
  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Reframing BPM Automation -- Topsy.com()

  • Phil Gilbert

    Scott,

    This whole debate is nuts and simply reflects that here we are, ten years later, and the people of BPM – at least the so-called thought leaders – are still techies. To business leaders there is no distinction between a “case” and a “process.” In fact, all this nonsense does is simply reinforce to the business reader that once again a promising method is being hijacked by control freaks in IT.

    The advance of BPM over, say workflow and case management, is that the focus was supposed to be on the business outcomes, not the automation itself. It was supposed to be about the improvement of how long and with how much effort business got done! “Business” isn't different just because something is a task with structured data vs. a task with (essentially) unstructured data. Yet from discussions like the above you would think that finishing a milestone in an engineering process is wildly different (to the CEO) from changing the status of a claim in a claims process.

    I've spoken with many business leaders over the past decade and what they want is simple: regained control over their digital assets and transparency in how those assets are dealt with.

    Instead of focusing on this goal in common cause with mainstream business people, we have to reassert our intellect, and show the world that we're smarter than the business. We have to split up this problem and show that really it's very very complex… in fact it's not even just BPM, it's ACM. Trust me, left to the experts, there will be yet another acronym tomorrow (wait, there's “Social BPM”!). In the end this whole discussion is a silly argument advanced by people who have an economic interest in either (1) increasing the perceived complexity of this BPM problem and/or (2) diverting the discussion because they've lost the battle so far.

    We need to quit arguing about what's so special about all this. It's not special. The hard part is how to make it easy.

  • Thanks for your comments! I find the least useful part arguing what is a “case” and what is a “process” – it seems just exceedingly obvious that you might have processes around ANY enterprise data object, and a case is just one of those.

    I just think there's a disconnect between the theory and the practicality – in practice, we solve these alleged different domains (BPM and ACM) with the same software features and techniques, and the same people buy the software and pay for the projects… and the same business users are impacted… the same business drivers need to be addressed…

    I think BPM does a great job of focusing on business outcomes (especially if you modify it to say “aggregate business outcomes”) – and if there is a space for ACM, it is getting people to think about how to address business outcomes for single instances without regard to the aggregate. Of course, ideally in a BPM project you address both perspectives, and that's what we've been doing for the last few years at least.

    As you say, the focus is business outcomes… and the focus for vendors should be making this stuff easy (or easier).

  • As opposed to Phil, I actually think these attempts to frame the issues is valuable and important. One thing I learned early on in academia is that a key step in finding a solution is framing the problem correctly – make it general enough so that it is useful, specific enough that it can be solved.

    I am not sure why 4 is there – why is automating the definition of work different than any other process – I see it as just a work process of a specific type.

    I am also not sure where collaboration fits – it is close to 3, but not exactly the same. It is a suport function – but not necessarily for management or monitoring of work. There needs to something about automation of collaboration between participants in the work process.

    Jacob Ukelson – CTO ActionBase

  • They *can* be useful, but it can be frustrating when the debate gets tripped up on something that is too esoteric. :)

    I think neil is interested in feedback on his framing of “automation” – but I'll put my 2 cents in – I think automating the definition implies that some running software inspects your existing running systems, and infers the process from that (an example, as I understand it, is Fujitsu's product/service to do just that, as described by Keith Swenson).

    I haven't considered collaboration automation per se… but perhaps that's missing something – the act of typing may be manual, but there is a lot of automation involved in getting this social information to the right people at the right time, and in the right context/place.