Lamenting Definitions

  • November 15, 2011
  • Scott

In a flurry of posts recently there’s another attempt to sever ACM and BPM.  It’s a strange urgency among some ACM advocates to separate it from the idea of managing business processes.

Keith misinterpreted my recent post on ACM/BPM – confusing product efforts by software vendors with implementation and execution efforts by business users.  Bruce Silver and I are speculating about whether “ACM” will really exist as a distinct market from BPM – and we both doubt it.  Keith is questioning whether doctors and lawyers should use BPMN.  A bit unrelated.

In another post, Keith attempts to put the wheels back on the track.  But Adaptive Process advocate Max J. Pucher notes that he sees a benefit to customers in a holistic solution – and goes on to advocate his own company’s approach:

Therefore I do not see a clear distinction between ACM and BPM, except that a BPMS cannot perform the kind of ACM user-driven processes that you describe so well. My recommendation of a homogenous system that does both really well is not only driven by my product orientation. Remember? I don’t have to sell what I have – I develop what empowers people!

I see it the opposite way: The only reason people have to keep ACM and BPM as independent functions are sales perspectives or BPM design or consulting skills that might become obsolete. From a business benefit perspective, a homogenous solution that also encompasses architecture, content and rules is the only thing that makes sense. Agree? Whether this is easy to sell or argument from an existing BPM mindset is a completely different story.

If it is a single solution, it really doesn’t matter if ACM and BPM are separate or the same.  It just matters whether you can solve the problem for the customer – or not.  Or if the customer can solve the problem for themselves – or not.  I believe Max’s firm is in competition (in a sense) with BPM vendors – because they’re both competing for a market around improving business processes.  Max’s competitive differentiators are related to the adaptive way his firm approaches this subject.  A company like IBM will pitch different differentiators for their product offering.  They may coexist in the market or within customers, or they may compete.  But so far this looks like one market to me. I might have more faith in BPMS based on my personal experience, than Max does – but in the wide angle view I see more agreement than disagreement in terms of what BPM is (versus what a particular product can deliver).

Jacob Ukelson proposes to call this area “knowledge process” instead of ACM.  I expressed a bit of my frustration with this distinction, though I generally sympathize with his frustration as well! –

As I mentioned on twitter, I don’t think the problem is that they got in the weeds on features. The problem is that ACM folks got too caught up in trying to prove that BPMS can’t do ACM – which is silly. Or worse, that ACM was superior/above/better-than BPM – which again, is just a silly argument to get into. Like arguing that BPM is better than SOA – they’re either complementary or competitive and if they’re not competitive than better doesn’t really have meaning.

Knowledge work is business work, last I checked. business people describe knowledge work as being part of their business processes. Fighting a definition battle that isn’t worth fighting. Go ahead and convince customers that they don’t have a sales process. That it is, instead, a sales knowledge process or a sales case management. Or that they shouldn’t apply process improvement techniques to aggregate outcomes.[…]

I keep hearing from people about what isn’t the answer… but not hearing much about what is  unless it is a plug for “read the book” or very high level – as you say – principles – which of course could just mean “use email”.

I think the ACM discussion has been useful in that it reminds people that BPM shouldn’t be just about automation and eliminating human work. But to me, separating ACM from BPM is a bit like saying that what’s good for the goose isn’t good for the gander- that some work (usually whatever work we envision ourselves doing) isn’t subject to the same general rules as the work others are doing. My work is creative, but their work is not. My work is knowledge work but their work is routine.

I promise you, all work that involves people involves creativity, passion, skill, energy, pride – or the lack thereof. Our goal should be to reduce the mundane and routine, and allow the people to focus on the creative and expressive and decisive. We could argue over ACM vs. BPM or just agree that BPM and ACM are two slices of bread in the same loaf.

Just because I don’t use a BPMS to tie my shoes doesn’t make it knowledge work.  Nor does it mean it isn’t a process.

Related Posts
  • May 24, 2018
  • Ariana

How can C-level executives recognize problems within their operations Chairman, Lance Gibbs reveals how to cat...

  • May 9, 2018
  • Andrew

BP3 now has a customer live with the next generation of task federation in IBM BPM. While the Brazos portal h...

  • May 3, 2018
  • Ariana

RPA Business Use Cases from BP3. How do you identify where to use Robotic Process Automation (RPA) in you...

  • At least I am consistent 🙂 and there is certain frustration in my tone.

    You are right – knowledge processes are business processes – and in theory every business process could be a knowledge process. For many BPM vendors the goal is make business processes “non-knowledge” processes so that even untrained workers can do them by relying on centralized control driven by an absolute model. That is why there is so much focus on the process model in most BPMS tools and the focus is on automation. In my opinion the part of the process that gets modeled is the least important part of the process and the part that can be automated is even less interesting from a business perspective. Not that it isn’t important, it just isn’t what makes the business special.

    I think work is segregated. Sometime by the type of work needed at different times in the lifecycle of a business process but that in most processes both types of work are needed at different times. I also believe that if most of your work is rote work you will need a different set of skills than if most of your work is knowledge work – and dare I say a different set of tools.

    About tying shoes – well it is rote work for most us (even for me, unless I have had much too much to drink), you could model it(though not in BPMN) and you could even imagine a machine that completely automates it. So I would put that in the “process paradigm” of routine work not worth the trouble of automating. I firmly believe that there is a type of work which many people call knowledge work that would benefit from a new set of tools that are better than plain old email and documents. Just like we could have remained in a world of Cobol and Fortran (there was no program you couldn’t write) – but for the sake of productivity it made sense to move up to languages with higher level of abstraction. A BPMS can do anything – but should it? Object-Cobol anyone?

    • Jacob -this comment hits home: “for many BPM vendors the goal is make business processes ‘non-knowledge’ processes” – that’s a very fair criticism.  I’m not sure if that comes more from the vendors or the customers but it is unfortunate that that is often the case.

      And your next comment about the model – “not that it isn’t important, it just isn’t what makes the business special” – Amen.

      I’m all for a more productive “language” to describe work or business.  I think that’s what BPMN represents for a certain class of business problems.  Just as Ruby might be better for a certain class of coding problems than, say, cobol. 

      But even within a BPMS, BPMN isn’t the only “language” – it just happens to be the business-oriented one.  There are technical languages as well.  I think there’s room for another “language” for describing work/business.  Maybe the principles behind ACM will drive that.  Or maybe a product’s vision will become the de-facto standard.  Thinking of the way MS Outlook does calendaring. There wasn’t a “standard” for the language of seeing and setting reminders and calendar entries and color coding, etc.  But it is a bit of a standard – in the sense that it had wide adoption and it represents the expectations that other tools get measured against. 

  • Scott, I don’t think this passage represents my position fairly:

    “Bruce Silver and I are speculating about whether “ACM” will really exist as a distinct market from BPM – and we both doubt it.  Keith is questioning whether doctors and lawyers should use BPMN.  A bit unrelated.”

    The fact is that Bruce Silver argues quite explicitly that BPMN, the language, is useful for both BPM and ACM uses.  I point out that the language BPMN is NOT useful for ACM uses.

    I hope you can see the relationship now.

    • Keith – fair enough.  Rather than try to explain what I think Bruce is getting at, I’ll concede the point 🙂

  • Actually I made both points, first that “most” case management can and ultimately will be implemented by BPMS rather than dedicated ACM tools, although current BPMS may not be good enough yet.  And second, to the extent that ACM benefits by having any modeling notation at all (maybe Keith thinks it does not), it would be better to try to *extend* BPMN than start over completely.  The second point really follows from the first.

    • Bruce, to your point about “implemented by BPMS” – to me this doesn’t necessarily mean that a consultant or IT specialist will implement, it means a product developer at a BPM vendor will implement.  Second, its a fair point that for CM/ACM of certain profiles a modeling notation would make sense (insurance claims come to mind).

      I was tempted to make this point myself, but I felt like I might be putting words in your mouth.

  • Pingback: BPM and Case Management Quotes « Adam Deane()