So I couldn’t attend the recent ACM tweet jam live, as I was, well, working. But there were quite a few people participating, and reading the summaries after the fact, I can’t help but feeling a bit underwhelmed.  So much energy has been spent attempting to separate ACM from BPM that I find it kind of ironic when the same criticisms would come full circle.  As Max J Pucher and others have noted, it is difficult to get consensus on a definition of BPM… but it is *also* difficult to get a consensus on the definition of ACM (I can already, almost, hear Max throwing up his arms and sticking with his non-acronym moniker “adaptive process” – no argument from me).  Keith’s summary of the tweet jam lists 6 definitions, but I bet there are more.  Personally, I don’t mind a surfeit of definitions, it is part of the human condition that you can’t get unanimity on things like this.    One of them was “all knowledge work”.  Well, This sounds a bit like BPM – covers just about everything.  Strangely, sometimes people think knowledge work is the only kind of work that doesn’t follow a predefined process.

Next, there’s the justification of “why all the buzz now?”.  These answers are the least reassuring.  Such as this one: “only today limitation of pre-defined BPM became clear. People look for another solution to knowledge mgmt”  Seriously?  BPM has been evolving for 10+ years and only just now, someone says “aha! it is limited! we need another three-letter-acronym!”  Pardon me for being a bit cynical, but I think anyone in the BPM space doing implementation was quite aware of both the limitations and possibilities.  Or this one: “Workflow and BPM is arguably ‘low hanging fruit’ – ACM is harder to get to, which is why it is of interest only today.”  Unless this author was equating BPM with BPEL, this argument misses the mark. BPM is hardly low-hanging fruit, which is why it has taken so long to mature as a market.  Arguably ACM is easier to achieve in many respects because you don’t need to build much of the infrastructure required to support BPM – and you may not be designing as much up front.  Trust me, the “do anything you want” process looks pretty simple in BPM tools… And the supporting technologies for knowledge work are relatively inexpensive.

However, another comment hits closer to home: “The integration vendors hijacked BPM: took a detour. now we see the need to use a diff kind of BPM”  I agree with this statement more than I disagree.  To the integration vendors, business process management was a checkbox feature in their integration stack.  But it needed to be front and center, because it is the new platform for getting process work done in the business.  I believe what people are calling ACM belongs there as well – front and center.  I am just not as convinced that it is a separate product category from BPM, as opposed to part of what BPM should have been doing all along (and for some vendors, exactly what they were doing all along under a BPM flag).  I am going to keep reading and listening to see if new information changes that outlook for me.

One comment was very interesting to me: “More like all vendors saying they do it.  Suddenly all do it – without changing their products.”  The question I have is – is it because they’re just putting out marketing spin, or is this because ACM, as defined, is already (mostly) addressed by existing products?  I wonder if the fact that everyone is so easily claiming to do ACM is because… so many vendors already do ACM… as defined by the chief proponents of ACM.  If that’s the case, then ACM really is about marketing from a software vendor point of view, and about the “approach” to “knowledge work” for those responsible for implementation of solutions (people in my business).

There was a considerable concern that the terms “ACM” and “Case Management” mean nothing to buyers.  I would agree. Buyers don’t seem to differentiate what case management would do that is different than this thing they’ve finally gotten around to tackling called BPM.  Still if a buyer is familiar with case management, it is a good idea to speak their language.  And if a buyer wants BPM, speak their language as well.

There was another section of tweets about what, exactly, constitutes knowledge work.  This gets a little ephemeral to me.  This is sort of like asking someone whether a job is creative or not – most people think they’re own job is very creative and unpredictable, but that all these other people in the organization are doing “routine work”.  A big US magazine “offshored” an issue of their magazine to India once, as an experiment to learn, for themselves, whether journalism could also be outsourced like other work.  They’re “startling” conclusion was that journalism was a particularly local and creative endeavor that could not be offshored (couldn’t see that coming, could we?).  They thought offshoring was only applicable to “rote” work like software engineering, call centers, etc.  Well, I have news for those journalists, writing code takes plenty of creativity.  And some call center work does too, based on the teams I’ve worked with.  So what is the magic creativity threshold that makes work offshorable?  Or, in the case of knowledge work – how much knowledge makes it knowledge work rather than “routine work”?  Difficult to put a gold standard on that one, and I’m not sure it is useful to do so.  These generalizations will only get you so far.

Finally, there is a section referencing “GOOD EXAMPLES OF SPECIFIC WORK THAT ARE SUPPORTED BEST BY ADAPTIVE CASE MANAGEMENT?”  (not my emphasize, it is the author’s emphasis)  The majority of these examples are hypothetical and theoretical.  Not work that is currently being implemented by ACM tooling or ACM-supporting vendors.  Taking each one in turn, I’d just point out that I haven’t seen these in the wild yet:

• Putting the decision of a board of directors to action. No predefined process, but the work must be done.  I don’t recall seeing the press release covering this one, or why ACM would replace the conference call for this.
  
• underwriting of life insurance. Insurance companies are using purpose-built software for this (COTS), and augmenting with things like BPM.  I’d like to hear if anyone is using an ACM “product” that is not also a BPMS to do their insurance underwriting.
• mortgage origination would benefit (just went through a painful one).  Ok, another “hypothetically mortgage origination is a good fit”.  But it turns out, BPM software is already the brains behind several major mortgage origination processes for major lending operations.
  
• architectural design.  So is there a market to sell ACM to architects? The architects I know have pretty specialized software…
  
• investigations, audits, contract and RFP management.  Sure, in theory this is true. But there’s already specialized software for these things as well.  And BPM vendors already has proven deployments in these areas.  So the question I have is: while these may be a good fit, is ACM differentiated or just another good fit? Are there existing deployments not by a BPMS vendor?
  
• I’ve seen examples of adaptive case management ideas applied to patient care, might ACM be especially useful there? Why?  Hm.  ACM “management ideas”.  Well truly, this is getting the order of operations backward.  The patient care practice has certain management ideas.  ACM advocates see similarities to what they think are good ACM practice, and therefore look to patient care as an example of what ACM could do well.  I’m not aware of any ACM patient care deployments (yet).
  
• Interior design every activity is art until order confirmation structured prc.  I don’t see interior designers being a big market for ACM, regardless of product fit.
  
• merger of United and Continental. In theory only.  They did it the old fashioned way, I expect. And as noted in other posts, I think companies that really do mergers, will have fairly organized processes (e.g. Cisco).
  
• Disaster Relief for Haiti.  Again, in theory only. And not exactly a market, so much as a need.
  
• Responding to Oil Crisis in gulf.  In theory only. And when it comes to *preventing* the crisis, so far all signs point to the people on the rig overriding (ACM style) the prescribed safety procedures (BPM style procedures) in pursuit of goal-oriented management (extreme pursuit of profit and cost-cutting)… but wait… Drucker’s Goal Oriented management was supposed to be a Good Thing… problem is, you still have to set *the right goals*… This is the problem with these analogies, the break down under any skeptical scrutiny.  Real deployments of real software will expose the real strengths and weaknesses of the ACM approach and tooling to support it.
  

Finally, a parting thought, I believe this is quoting Max J Pucher:

“ACM is not anarchy – it is empowerment! Authority, Goals and Means to accomplish those goals.”

Empowerment should be the goal of any good BPM or ACM solution, I think.  Enablement, and Empowerment. Great thought to close with.  And sometimes just one nugget like this makes reading the whole train of a tweetjam worthwhile!  Thanks Max, and tahnks to Keith Swenson for taking the time to try to capture some of the session for posterity (or at least, those of us who couldn’t attend).

Max J Pucher has written recently that BPM is, essentially, common sense management that could be gleaned from dozens of management books:

In these times I would call BPM common sense management. It is no longer new or a mystery! We are rather going backwards with BPM to Tayloristic management concepts. Is there really anyone left in a management position in larger than SMBs who does NOT KNOW what the idea behind process management is? If yes, he/she shouldn’t be there. And once someone understands the acronym does he really need more than a day to understand what the idea is and how to implement it as a management approach? There are numerous books that will tell you how to do it.

Respectfully, Max is both right and wrong.  Yes, BPM is “common sense management” – but, you can read about the Himalayas and look at pictures all you want – it will not prepare you for BEING THERE.  You can read about playing tennis all you want, but playing it well requires practice, practice, practice… and… coaching.  You need a good coach to become a good player.

The point is, many things can be read about and understood in principle.  You can understand the what.  You might understand the how.  Or the when.  But the magic happens when you know what to do, you know *how* to decide what to do, and how to do it.  And you know when the time is right to do it – and you know why.  Business requires not just common sense but practice, and a good feedback loop as well.

Having said all that – the rest of his blog post is quite an interesting read, as usual.

Max often writes provocatively, and this one is no exception. I think if one reads his work and takes the big ideas without getting hung up on a few of the specifics that might cause debate, there’s a lot to take away and internalize.

As an aside, I find it interesting how often BPM is characterized as being a rigid Tayloristic approach to business – but this is never how we approached BPM at BP3, so I have a hard time relating to this point of view – it sort of assumes that we can’t learn from Taylor and Drucker (and others) at the same time, and benefit from more than one process improvement theology. If I can sum up the criticisms (not from Max’s post, I’m borrowing from many discussions on blogs):

1. BPM is rigid, like a Taylor management-by-science-gone-bad approach.
2. BPM can’t be about managing to objectives, like Drucker would suggest
3. Knowledge workers can’t be managed by a process, or by BPM
4. Creative processes can’t be managed by a process, or by BPM

Of course, those of us who do BPM “right” look at it a bit differently:

1. BPM is about adapting to the change that is happening in and around your business.  It is scientific in that it puts value on real data, but it does not believe in replacing human judgment and decision making and subjective valuations. It is not about automating people out of the process – it is about putting the right information in front of them at the right time so that they can do their job more effectively, and make good decisions.
2. BPM can be about whatever you decide to focus on – managing to objectives or managing a prescribed process – much depends upon the kind of work you’re tackling.  Clearly, handling financial transactions there really shouldn’t be a lot of variance in executing account transfers. But deciding how to handle a customer complaint may leave a lot of room for judgment.  And deciding what the objectives are for a line of business is a process that has much wider latitude.
3. Knowledge workers interact with processes all the time.  If the process is to support knowledge work, it has to be quite different from one that is quite constrained and repetitive – but that isn’t the same thing as saying it can’t be done.  ACM proponents prefer to talk about this as a separate discipline than BPM – which may leverage the same software tools.  That’s fine – but the point is, there are software tools that market themselves as BPMS packages that *do* support knowledge work, and there are BPM professionals (like BP3) who build and support knowledge worker processes day-in and day-out.
4. Creative efforts can absolutely be managed by process.  If anyone thinks Einstein and Edison didn’t have a process to guide their efforts, they haven’t studied these two.  Genentech and Apple both have repeatable processes to guide their innovation and creative efforts.  Do they use a BPMS? Likely not, but I don’t despair about that because the penetration of BPMS packages into the market is still small relative to the potential market size, and just because someone doesn’t use a tool doesn’t mean it can’t be useful to that purpose.

Lest it look like I am writing the above as a disagreement with Max, I don’t believe that’s the case – I just want to set the background for some of the general points made against BPM, and my feelings about those points.  Here are some great points from Max that I think a lot of people could learn from:

There are BPM proponents who say that using structured process should be seen as applying experience. I disagree, because a rigid procedure that may have worked in the past is not goal oriented. Experience is something one gains as a person and is not something one can copy. Applying experience happens by people at each singular activity towards the goal. Experience won’t get encoded into process flowcharts during analysis.

Very true.  BPM proponents *should* be applying experience to their work, but that does not mean that a well-built structured process replaces experience.  Max’s points illustrate why it is so important to have experience in general, and specifically with BPM deployments, in order to understand these finer points.

The higher you go in the management hierarchy, the less predefined processes you will find, need and be able to work with. Otherwise, why would one need management and executives? That’s why I am opposed to best practices that are no more than an average of past approaches now being applied to a specific situation without being sure of its applicability.

Again, great points.  Part of the reason processes higher in the organization don’t get defined as well as because there isn’t economy of scale at that level.  But at organizations like GE, they have very evolved processes around developing their executive management team and the bench for each role.  So processes that *do* have scale continue to get process attention. And yet, the decisions made about each of these individuals involve subjective as well as objective data.

The complexity of current information technology leads consultants and analysts to propose that IT has to be rigidly managed as a business resource only and is ideally outsourced or ‘cloudsourced’. This approach certainly kills inhouse innovation.

This reminds me of how some organizations react to complexity by enforcing rigid gateways between project approval, requirements, design, development, testing, and user acceptance… Instead of adopting an agile development approach.

I propose that if executives chose to manage by orthodox (BPM) process management, they chose to ignore the knowledge between the ears of the people that count — their employees and customers!

Executives and management at all levels have to value the knowledge and experience of the people in their businesses – and use software to help them, rather than hinder them.  Thanks to Max for another really interesting read in the BPM/ACM/Adaptive Process discussion.

One of the more entertaining comments in the whole BPM, “you’re not my father” (Star Wars reference, sorry folks) debate:

Using an object model and letting actors express processes in terms of assembling (and continuously changing) those objects in the desired way is a very powerful way of creating applications. Is it an application? Is it a BPM process? Is it a Mashup? Who cares? The technical questions have to be asked at some point in time, but at first one needs to check with the business if they can get the functionality they need ASAP, and if they can adapt it any time they want.

We are discussing the ‘Emperor’s New Clothes’ here, I’m afraid. Let’s go and do something productive.

I think there is entirely too much gnashing of teeth over the new three letter acronym.  I might have to check out what Max’s product (Papyrus) really does now, after reading three interesting comments from him in as many days.

In the main body of the post, Keith rightly points out that there was way too much focus on BPEL in the BPM community, despite protestations from some fairly vocal members of the community.

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim’s intent):

• Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.  It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.  This works if the process is predictable.
• Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.  Since you can not predict it, you have to elaborate it as you go along.  You design it, as you are doing it.  There is no development life-cycle.  This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management.  By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don’t know, why not just call it “design by doing” and use that as the tag-line for your product offering… ACM doesn’t quite have the same ring to it, and it isn’t nearly as easy to relate to.  Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith’s blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:  a bunch of companies have already acquired one or two BPM software vendors.  How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?  Would you rather be the “XYZ” software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?  Of course!  (well, as Max says, he doesn’t care about the labels for his product, Papyrus, so I don’t mean to personalize this to Max, by any means!).  And if you’re a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle – RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.  But like some others (Anatoly for example), I’d like to keep BPM separate from BPMS (method from technology).  There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn’t benefit customers or practitioners.   I see managing unpredictable work as still being “process-driven” even if others don’t.  Design-by-Doing sure sounds like a process to me, folks.  Maybe a meta-process, but a process nonetheless.

I’d like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings – explain why your software is just the right socket wrench for the job, rather than a screwdriver.  Educate the market on why the software fits the problem definition.  As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

Max J Pucher writes a pretty thorough rebuttal of the idea that BPEL matters.  He starts by pointing out that the defenders of BPEL often malign those who question BPEL’s utility.  Mr. Pucher has quite a few controversial posts and discussions in the BPM space, and this post is no exception. I can summarize his article in a few key points:

• BPEL is not widely supported.  There are over 200 BPM vendors, and less than 10% support BPEL, and by Mr. Pucher’s reckoning, their support is partial at best.
• Avoiding “vendor lock-in” is not a valid goal of BPEL – because there is still vendor lock-in with BPEL implementing products.  I happen to agree that it is a bit naive to think that software you buy from a software vendor won’t entail a certain amount of vendor lock-in.  Transferring execution details from one body of software to another and expecting complete faithful reproduction is non-trivial.  Just think about Java Virtual Machines – without a robust specification test to validate against, these JVM’s would never approach parity.  Even so, software vendors usually only warranty their products against particular JVMs and even JVM versions. He quite rightly points out that the combinatorics on database, OS, JVM, appserver, rules, security, etc. make it nearly impossible that an implementation can merely be lifted from one BPEL vendor and run inside another BPEL vendor’s platform.
• Since BPEL is XML that we hope never to lay eyes on, why is it the representation that we hope to preserve?  Aren’t the diagrams more useful to preserve?
• BPEL doesn’t address key business requirements – such as monitoring the execution of the process for important business metrics.  And the business shouldn’t really care how the process is executed so much as those metrics… So is BPEL missing the point?

His conclusion:

Conclusion: When BPEL and even BPMN are looked at from a pragmatic business need perspective the only acceptable benefit is that products that use them have similar functionality and people designing processes will find it easier to switch products.[...]

Well, this is a significant benefit – but it is not what the vendors of BPEL vendors will claim – “model portability” and vendor independence.  As usual, interesting stuff from Mr. Pucher, and a little different perspective on the BPM space.