David Brakoniecki chimes in on ACM’s product/market fit problem, and hopefully he won’t mind me quoting liberally from his post.  On the one hand, there is the rock:  free or nearly free software from various providers that addresses the freelance/collaboration use case…

Freelance Web designers and developers need a tool to collaborate with clients and to manage projects. They simply can’t afford to pay much for it but there are thousands of them. Basecamp pretty much plays perfectly to this market. It’s SaaS delivery model and freemium pricing makes it easy for users to get started quickly.

On the other side is the hard place: difficult integrations that must be completed before something like ACM or BPM can be successfully implemented…

If your target market is hospitals or insurance companies then just setting up the integrations and data migration is a massive upfront investment. The promised business agility depends on getting the set-up right and the compelling difference with other case management and BPM technologies is less.

And in this latter market, you find yourself up against established technology companies with robust BPM and separately, robust integration offerings (often well-integrated into a single suite).

This doesn’t shoot holes in the “methodology” side of the ACM pitch, but it sure points out a problem for the technology side of the house.  And there is some market evidence to support this view.  A few of the “ACM” vendors have run into the reefs – e.g. ActionBase (which I still think had the best articulation of a product that reflects ACM values, and yet was clearly not a BPMS).

Frank Michael Kraft’s post on Taylorism is interesting, in that it is a response to Jakob Freund’s post on the same subject, but with a different perspective, and a pretty balanced view.

Since I mostly agree with his post I’ll just focus on a few of my nitpicks:

“We cannot conclude that if a management style is good for physical production that it is good for brain work as well.”  We also can’t conclude that if a management style is good for physical production it is NOT good for brain work as well.  Or vice versa.  That requires more data and analysis than has been discussed on the blog posts linked above.

Kraft goes on to say that we should use “the right type of tool for the right type of work.”  To my mind, BPM has always been about that.  In my experience it includes mind maps, BPMN, BPEL, interaction diagrams, Failure Mode Effects Analysis, and other tools of the trade.  Not to mention the data analysis, simulation, optimization side of things.   Most of what I hear about ACM sounds like tools of the trade people have been using in BPM projects for quite some time (which is why, to me, they aren’t that differentiated).

He also has a nifty graphic:

And he’s right, when he makes the point that the arguments about BPM and ACM often sound like mutual exclusivity – only one can be right.  But I think the argument between these advocates is more along these lines:

• ACM proponents: ACM is different and separable from BPM as a method, and (less consensus) a tool set. Corollary: the language used often implies it is just better and more important than BPM.
• BPM proponents:  ACM is fine. But it is clearly one of the tools in your BPM tool belt, rather than its own distinct and separate market (tooling), and methodology.

It is easy to mistake the first group’s arguments as saying BPM doesn’t matter, or that ACM is “the only thing”.  Clearly it does matter, and the staunchest proponents of ACM will also say and write that.  It is easy to read the second group’s arguments as saying “BPM is the only thing.”  But the argument is a bit more subtle, it is just that BPM is the umbrella in these advocates minds.  Maybe this is consistent with “BPM is the only thing” – but only because the BPM proponents likely have a more flexible notion of “what is BPM” than the ACM group.

Finally, we see this from Kraft:

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system.

I think Mr. Kraft is essentially correct, and most people would benefit from adopting some kind of funnel, just as he describes.  However, there are two small issues, which don’t detract from the main point he’s making – but the inconsistencies between these layers may not be obvious in a casual read, while they do affect how you approach the funnel:

1. ERP is a tooling (or software package), without a methodology.  In essence, the “methodology” is to standardize on a big software package.  That may also include giving up on differentiation, but it doesn’t have to.
2. ACM and BPM “methodologies” can both be accomplished with the same tool sets (software packages), even if you accept that the methodologies are distinct.
3. As a result, the transitions from one layer to the next have different degrees of friction with your IT and Business groups.

The funnel itself makes perfect sense.  In fact some of the customers and IT staff we’ve worked with prioritize their process work this way: by forcing new project ideas to go into the funnel starting with a fairly loose “ad-hoc” definition, and only with volume does it move into the more structured definitions more commonly considered “BPM”.

As usual, a strong contribution to the body of thought from Mr. Kraft, around ACM, BPM, and Taylorism.

Peter Schooff once again asks the provocative question: “Will case management eclipse BPM in importance this year?”

The answers were pretty interesting.  I guess I should first own up to my own:

Short answer : no.

More thoughtful answer : When people have trouble listing which products are ACM, and which are BPM, and which are both, the “ACM” tag has some work to do to eclipse BPM. Even as it grows, it is perceived as part of BPM, not separate.

Of course, BPM took a decade or more to come into its own. I don’t think it comes undone overnight.

It isn’t easy to fill in the white space.  It is harder to design a good software solution from scratch than to fix a bug in an otherwise working solution, or to design a small addition to a working piece of software. What if you could have tools that just help you right away, and then later infer the process (filling in the white space for you)?  That’s the promise of “process mining”.

Along those lines, Dave Brakoniecki tackles the idea of “inverting the process life cycle“, in response to a post by Keith Swenson on the subject:

Imagine a patient file or case. This is a favorite example in the ACM space since the expertise of the doctor defines the process or work to be completed. How useful to the doctor is a case management tool that has no information on the patient and no ability to schedule tests? Not very – all of the work would need to be done outside the tool and duplicated in the tool. Still, building integrations to the patient records and to the systems that organize blood work, for example, would be better done at design time than run time.

Even if this was possible at runtime, few doctors would be interested in doing it.

(incidentally, I think this is why something like IBM Watson is getting good airplay in medical / healthcare circles.  It has data and context on a subject domain)

So, a lack of preloaded or pre-integrated data seems like a problem. But supposing you have this pre-existing data, there are a small number of firms prepared to help you discover the processes you are already executing without realizing it.  It isn’t yet clear to me how big these services projects are (there aren’t any shrink-wrap solutions that require no services).

And Dave points out another issue:

In most organizations, what is problem with their Sharepoint deployment, their Lotus Notes application or that little Access database application they wrote three years ago? In almost all these cases, the problem is the same. End users were given a powerful and flexible tool without training and ending up building a system that is impossible to maintain but essential to the business.

I have seen many successful projects start from this position: The end users actually asking for more help in managing the technology so they can spend more time doing their jobs.

This is summarized nicely as “the Sharepoint Effect” in a previous post on this blog.  And I agree with Dave – many projects start exactly this way.

Then Dave gets into what might be an example of ACM in the wild – Basecamp.  Although it doesn’t bill itself as an ACM tool, one could argue that it is one, by accident.  In which case:

Perhaps the most important reason for the ACM camp to try and adopt a solution like Basecamp is that it would give them immediate mainstream legitimacy with tangible customers who have already inverted the process life cycle and will do it again next week. It probably also indicates the delivery model and price point required to disrupt the markets they are targeting.

I’m not sure the ACM vendors are prepared to be at those price points, however.

Keith makes some interesting points in his original post, not all of which are argued by Dave.  Certainly measurement before improving is A Good Thing.  We’ve been implementing “shadow processes” and listening to processes implemented in other systems for years, and using that data to inform our new process models.  But because we’re listening to real systems, we have to implement the broadcast or listening of those interesting transitions in the systems of record.

In short, there’s no magic bullet. But you can certainly do better by measuring twice and cutting once, as they say.  But we can do better than that. We can measure any number of times, and we can get more than one “cut” at the new and improved process by leveraging A/B testing to determine what actually produces the best results.

Jakob Freund has written an interesting defense of Taylorism, and he makes a few interesting points that I don’t recall seeing in previous discussions about ACM v BPM.

Actually, when I am driving, I am a zombie worker most of the time. Sometimes, of course, there are “unpredictable” events, like a child running over the street, or an alien spaceship landing in the middle of the highway. Then I become a knowledge worker, handling that case with my horribly flexible brain.

No, I don’t mean the point about alien spacecraft, I’m referring to his point that being able to operate on auto-pilot leaves our mind free to focus when we really need to, in value-added situations.

So the bottom line is: Making the world more predictable (yes, it can be done), and then applying axiomatic systems to it, is nothing invented by Taylor and somehow an “accident” of the 20th century, but it is a central component of human evolution. It has always been there, and it will always be there, as long as people are interested in less work and more free time.

This is also an interesting argument.  A bit too much credit has gone to Taylor over the years for putting into words what might already have been in progress.

The central thesis seems to be that reducing “knowledge work” to scalable process work is one of the key imperatives of scaling a business.  It is an interesting take on things, and fits a lot of the process efforts that focus on efficiency as a goal.  And it is a refutation of much of the hype around ACM as being something shiny and new.

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.

Bruce Silver, never one to shy from a debate, weighs in with a post I largely agree with:

The question is BPM part of case management, or is case management part of BPM? is a metaphysical one.  I think, however, it is a proxy for the real question, can a BPMS do a good job with case management, or do you need a special dedicated tool?  It’s obvious that if a single offering could provide both, users would prefer it over separate dedicated offerings.  And it’s equally obvious that it can be done, although it’s fair to say that the offerings may not be good enough yet.  Back in 2005, people said you needed separate BPM platforms for human workflow and integration processes.  It was just a matter of time, and not that long a time.

In one paragraph, I think Bruce has succinctly cut down 90% of the noise:

1. This is a metaphysical question. In a practical sense, who cares.
2. To the extent that people care, it is because they’re substituting this metaphysical / philosophical question for a practical one: “Can a BPMS do a good job with Case Management?” (or ACM)
3. Everyone understands customers would like to have one tool that does both. And makes breakfast.  Thus the fear and uncertainty and doubt about this issue among software vendors.
4. Anyone who can code worth a lick can see that it can be done. But as Bruce says, there’s a lot of room for improvement on most of the tooling out there.
5. History suggests the ultimate answer.

He then moves on to discuss how a case might be different from a process.  Overall a great read.

John Reynolds writes about the curious case of the disappearing BPM Programmer:

So where does this distinction between Case and Process leave the BPM Programmer?  Are BPM skills irrelevant in the new world of Dynamic Case Management and Social Process?  Are the BPM Programmer’s skills doomed for irrelevance every few years just as the skills of System Programmers (C begat C++ begat Java begat Ruby etc.)?

Will BPM Programmers disappear into the mists of interesting but irrelevant oddities of the past?

The question arises simply because a small but vocal chorus has been calling BPM a subset of Case Management, or predicting the end is near for BPM. Does that mean BPM skills and jobs are thus in decline?

Not to worry.  BPM was always the tool not the goal.  The goal is managing business better.  As the Navy Seals would say, equip the man, don’t man the equipment. BPM is a means to an end.

Processes aren’t going away anytime soon.  Besides, as John says: “Your job has always been about writing software the Manage Business. Process is at the core of Business Management, but you always had to deal with Objects, Rules, and Events.”

Well said.  BPM is here to stay.  It didn’t burn brightly and fade away, it is a slower, steadier progression.  As you would expect it to be, if you understand what it is.  And the momentum is still building, rather than fading.  The name may change, the tools may evolve, but the goal of running businesses better isn’t going away.

I think this post by Activiti‘s Tom Baeyens reveals a blind-spot in the folks behind open source BPM tooling.

To be clear: it isn’t a bad post, and I agree with his conclusions!

Which are, summarized:

• “hosting traditional BPM engine on the cloud is a big technical challenge with a relative low value for professional consumers”
• The data manipulations required by BPM’s automated steps are too complicated to expect professional consumers to design in a webpage (the example given was getting contents from a spreadsheet into a pdf document).
• “On the other hand, the trend to Advanced Case Management (ACM) really fits well into the cloud.”
• “Dynamic management of tasks without a predefined flow matches perfect with the professional consumer needs and capabilities.” (Author’s note: whether you call it ACM or BPM, we understand what Tom is getting at here. )

So if I agree with his conclusions… what’s the problem?  Just that commercial companies have come to these same conclusions a few years earlier – and open source BPM projects have been more focused on building the engines than on exactly what the deployment architectures will be – and what the implications on product direction would be if you change those deployment choices.  So, it has been a blind spot – but that isn’t the end of the world. BPM in the cloud is still in its very early stages.  Even “ACM” in the cloud is in its infancy. Activiti (and others) have time to address the blind spot, and maybe something new and interesting will come out of new entrants to that combination of cloud and BPM/ACM. I’m looking forward to see what Tom and the team working on Activiti come up with.

Tom’s writeup also confirms another conclusion I’ve long held about “ACM” as software implementation- it just isn’t as technically difficult to produce as a BPM platform (throw out all that integration stuff for example, and any notion of structure).  That isn’t some kind of badge of honor to be “more difficult” – it just means it may not be very defensible for a software company to build around, and it tends to look like a toy to customers, rather than a serious enterprise product that stands on its own.

A process for golf?  Or just another analogy designed to prove the deficiencies of BPM?

Ran across a lighthearted post from Jacob Ukelson regarding the process for playing golf.  Well, the thrust of the post is that differentiating processes can not be usefully modeled by a BPMS.  I would contend, rather, that the differentiating elements of your process – people(!)-  cannot be modeled by a BPMS.  It is a subtle difference, but an important one.  The basics of the golf process are easy to model  – easier than most sports- there are, after all, 18 holes to be played in succession… 19th hole is optional :)  However, the quality of process outcomes depends upon how well the player strikes the ball, and there isn’t a good process description for that. In a sense this is the human element that really shouldn’t be addressed directly.

But what Jacob focuses on is the minutiae of golf, which I agree you would certainly not try to model:

But I noticed something about games – players adopt little rituals that they believe help their game – always starting out on their right foot, making weird hand gestures before they play a ball etc.

So what is going on? – it is clear to anyone looking on from the side that these rituals and superstitions don’t really work. What I think is happening is that people really want repeatable processes (though most don’t use the word process, and would probably balk at it). They look for some type of pattern, repeatability and inner logic even when none exists. Anytime they have an exceptionally good game, they look around for some set of steps that will let them repeat that performance. The problem is that usually what they find are some silly (to others) rituals that don’t really have any influence beyond providing confidence and the feeling of repeatability – which actually may be enough to enhance performance. The part they have standardized isn’t what truly enhances performance.

The problem with analogies is often that they rely on different assumptions.  Jacob assumes that these rituals (“superstitions”) don’t work, and therefore worries that people are focused on standardizing the wrong things…

Golf and tennis are family sports for my family.  I never took to golf, personally, but I took up tennis.  And I can tell you that there is a method to the madness of rituals.  Of course there are people with ridiculous rituals (just watch McEnroe serving in the 80′s), but there is a point to it.  By having a routine to follow – however simple or complex – you engage muscle memory and disengage conscious thought.  You give your mind a chance to focus without holding on to that focus too tightly.

Much of the accuracy of shots in tennis is due to foot work rather than the stroke. But why?  Because good footwork puts you in a position to hit a shot from the “sweet spot” of your stroke – described vertically and horizontally by the most comfortable place for you to strike the ball accurately.  If your footwork is good, you put yourself in a good position to hit well time and time again.  If your footwork is poor, you are forced to constantly adjust your stroke to account for the distance of the ball from your body, and the varying height at which the ball must be struck.  In a high quality match, a very small percentage change in your stroke can have a big effect on the # of errors (you have many opportunities to commit such errors).

In short: these rituals are often about addressing the ball at the most comfortable distance.  It isn’t just superstition.  But I wouldn’t bring a BPMS anywhere near it!

Jacob concludes:

I worry that this might happen if BPM and ACM get “melded”. You can take a truly repeatable process, model it, simulate it and optimize it. Try to do that with a case – and all you get is ritual and superstition.

Hm.  Having deployed several case management solutions, I haven’t seen any ritual and superstition yet.  It is possible to imagine all kinds of problems, but in practice I don’t see them.  You just have to realize that you can hold that “case” or process too tightly with process modeling, but in practice your BPMS will work well for case management if you find the right balance between control (governance) and flexibility.

There’s an argument that says the world is too complex for humans to understand.  Further, that by thinking we understand cause-and-effect, we’re doomed to act in ways that have unforeseen (usually negative) consequences.  It is a really interesting debate, and informative on the more than two sides represented.

Personally, I found myself rejecting this notion as useful.  Not that the notion of complexity isn’t useful – but letting it paralyze you is not useful.  When it comes to running your business, simplicity is more powerful than complexity.  A combination of relatively simple interactions has more power than a complex single interaction.  Simple interactions are more replicable, more scalable. I would focus more on enabling “emergence” than disabling decision-making by leaders.

Simplicity and abstraction go hand-in-hand.  The iPad has a significant amount of complexity baked in – from the hardware, to the software, to the production processes that lead to its creation, to the design processes that lead to its conception.  But to me, it is just a glossy glass enclosure that responds to my touch.

Does my touch cause the apps to do what they do?  Actually, it doesn’t matter whether touch is causal or not – it is, at minimum, so highly correlated between action and reaction that it feels like causation.

And that’s what we should be striving for in our businesses – that our actions would achieve the results we’re looking for – will feel like causation – though there may be a complex choreography and it may not be driven top-down.

There was a truly fantastic quote in the original HBR article:

“If you want to build a ship, don’t drum up people together to collect wood and
don’t assign them tasks and work, but rather teach them to long for the endless
immensity of the sea.”

- Antoine de Saint-Exupéry

Sometimes simple is best.

Update: In the interest of clarity I’ve updated the second-to-last paragraph of this post.

Anyone following the #BPM hashtag on twitter has probably been amused at times because we also get a fair number of posts about BPM the XM/Sirius station as well.

But in this case, Emily Burns of Pega has decided music offers a metaphor for BPM vs. Case Management:

Recently I was describing to someone the difference between BPM and Case Management, and found that music lends itself very nicely as a metaphor—specifically, the contrast between solo and ensemble works and the contrast between Classical and jazz.

I couldn’t disagree more.  Any use of an analogy like this, especially when it is loaded to make one party sound better than the other, is easy to pick apart.  In particular she states that “the closest musical metaphor to traditional BPM is the performance of a solo piece; a piece of music written to be performed by an individual person.”  I’m not sure what kind of BPM Emily Burns has been familiar with, but I have yet to see a BPM project for one person.  or built around one process-actor (or even multiple process actors all playing out the same role in the process).  BPM projects are cross-functional and typically cross-departmental.

The core of her argument is on more common footing with the idea that case management accommodates improvisation whereas BPM does not.  But I’d hardly equate case management with a jazz ensemble.  Nor BPM with classical music.  Music is art.  Office work may not be routine, but it isn’t typically what I’d call art.

Comparisons and analogies around Case Management and BPM always trip up if one is willing to dig into specifics.  Often, the people making the comparisons do so with an implicit (unstated) assumption that all the interactions between process participants has to be modeled in a tool to be effective (or coordinated in a tool at runtime to be effective).  This just isn’t the case – normal human interaction takes place outside of tooling – whether you are a BPM advocate or a Case Management advocate.  There’s no need to model the conversation in the hall, the conversation over the cube wall, the agreements made between coworkers over lunch.

What it boils down to is simple – most case management approaches really focus on improving the outcome of a single case, largely ignoring the consequences at volume.  Case Management approaches seem more appropriate to work “processes” (cases) that can not be well-designed a priori.  BPM approaches, on the other hand, tend to focus on optimizing aggregate outcomes rather than a single outcome.  BPM approaches seem more appropriate to work “processes” (cases) that can be largely designed in advance (a priori).

The analogies may be comforting, they may help explain an opinion or a point of view, but let’s not mistake them for proof. (Or in particular, proof that one approach is better than the other)

David Brakoniecki comments on the ACM discussion on LinkedIn:

Over on Linkedin, there is a spirited debate over several aspects of the Adaptive Case Management (ACM) movement going on.  The whole thread makes is worthwhile a read if you are trying to understand what exactly ACM is trying accomplish, how the community is organized and who some of big players are.

I commented on his blog but thought I’d repost here:

I saw this thread-  too bad it descended into something – how shall we say it-  not very professional.  I like the definition of DCM – it makes that particular definition much more apparent.  And I agree with you – almost every BPMS out there is also DCM.  I’m sure there are/were a few exceptions, but the surviving BPMS’ all have good rule systems to leverage (or can leverage external rules).

Now we’re just left with the muddy ACM definition.  I found it particularly amusing to see that people who have previously argued that BPM can’t succeed because we can’t agree on the definition, then turn around and argue that no definition of ACM is needed!

And I also find myself agreeing that I don’t see the technology issues with case management.  The differences that are communicated are at a really high level, unsubstantiated by an actual software artifact or code snippet or API (to give a few examples).  Philosophically the difference between basketball and “soccer” is quite large, but to a kid with a ball, it turns out he could play either one.  Actually, a kid could probably play either of these sports with any decent ball if he/she was motivated…

I’d recommend reading David’s summary more than the original thread, or at least stop reading the thread when it leaves off the constructive and starts to get a bit heated.

Not that long ago, one of the prime examples given by Keith Swenson in support of the “ACM approach” was a medical example (picture Dr. House examining the really-out-there cases) – check out the comment stream from this post for background.  Jacob Ukelson and I, not long after, proposed a way to think about ACM and BPM approaches in a complementary fashion – where ACM is concerned about an individual case, whereas BPM is concerned about the aggregate of all “cases” or processes.  I used Keith’s medical analogy to make my point.

From twitter (thanks @elliotloh), I ran across this PBS story on a Denver Hospital that fairly well proves my point with respect to hospitals. There’s video, but I’ve quoted a few passages below.  First, what was the outcome of this focus on aggregate quality of care?

DR. PATRICIA GABOW, Denver Health and Hospital Authority: What that translated to at Denver Health last year is that 213 people walked out of here alive who would have been expected to die. So, that makes the statistic into a very personal aspect for people who, in fact, lives were saved.

Think about that – 213 people alive today that statistically, would have passed away at the average hospital.  And they’re not cherry-picking the patients and doctors, as the following passage demonstrates:

DR. DONALD BERWICK, Center for Medicare and Medicaid Services: They are getting levels of performance that most of the rest of us in health care can only envy. The vast majority of their patients are either uninsured or Medicaid patients. They deal with a very, very stressed population. And they are proving that that kind of care isn’t just kind of good enough. It can be the best care — actually, the best care in the country. They are showing the rest of us what’s possible.

But was this process improvement effort really goal-driven? (emphasis added in italics):

BETTY ANN BOWSER: One of Berwick’s chief goals is to reduce hospital-acquired infections in the next two years.

Was this really anything at all like a BPM project? Well sure it was, absent the BPMS software (emphasis added):

BETTY ANN BOWSER: CEO Gabow wanted a cultural change, so she brought in a team of efficiency experts from the business world and asked how they solve problems.

Out of that grew adoption of the Toyota automobile production system’s Lean principles, to eliminate waste, fix problems, and promote constant improvement.

WOMAN: So, as a group, we’re going to process-map it. We’re going to identify your waste. We’re going to pick part those defects.

It sounds pretty familiar, doesn’t it? And they looked at process times, steps, measurement, alerting -  not the checklists a doctor might operate from, or a nurse, but the systemic approach to the overall care-giving processes:

SELEEM CHOUDHURY, Denver Health: People come in and they are sick. And when they are sick, we need to see them as soon as they arrive upon — you know, upon arrival.

And so we had to reexamine our process. We got Post-it notes — we put them on the wall — from every single aspect, from walking through the door, to seeing the nurse, to going through registration. And we had up to maybe two hours’ wait to be seen for that process. And just by making some simple changes, we cut that wait time by half.

(It does pain me a bit to see that they had to resort to post-it notes rather than software…)

But what is driving this change? A change to Medicare payments – tying them to efficacy and safety rather than just performing a service.  This is going to force hospitals to re-examine how they provide care and think about how to serve patients more effectively.  Of course, we can bemoan the fact that it takes a financial incentive to drive this change in quality of care, but maybe we should take improvement at face value, whatever the driving force behind it.

Jim Sinur raises this question in a non-confrontational way in his recent blog post.  It’s good to see him back at blogging on the subject of BPM after a short hiatus.  The trend he predicts:

As BPM matures it will have to reach to groups of knowledge workers that can easily work together for the common good of process outcomes, improving processes and recognizing unexpected patterns of behavior in processes plus participating constituents(clients, partners, employees etc.). Enabling good feedback mechanisms and encouraging “early warnings”. will be behavior that will be encouraged, going forward.

Reading between the lines – he asks if Social BPM is only communication/collaboration or if there is also some structure required to deliver the benefits.  To me, a short-hand way of describing his cautionary note is:  if there’s no Design, then you’re just Doing. 

I’m not sure that just Doing is better than Doing with a little bit of Design thrown in for good measure (or, in the case of highly structured processes, a lot of Design).

Jacob Ukelson, in his post Time for a Process Manifesto? , picks up some ideas from the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

So far so good.  But then he draws the following conclusion:

I think that traditional BPM does less well on the first two principles – it is pretty clear that comprehensive documentation (the process model) is still a basic requirement. Probably because of the mindset – process and tools take precedence over individuals and interaction. So not so good on those fronts.

I guess people have different notions of what “traditional BPM” is.  The traditional BPM I’m familiar with is not about documentation, it is about working software (and so it is not clear that comprehensive documentation is a basic requirement).  The diagram is the process, and the diagram actually runs.  Although, I’ll admit I came into the BPM world via Lombardi, and brought with me software and consulting approaches learned from other jobs.  So I might have missed out on the specific traditional BPM Jacob is referring to.  But in our (BP3) world of BPM:

1. People are the focus
2. Document if it reduces risk or adds value.  Don’t document just to pass gateways.
3. We emphasize working software and feedback loops.  Luckily the software tools we use reinforce this approach and support it.
4. We use the term “value-driven vs. plan driven” but I think it substantially has the same spirit as “collaboration over contract negotiation”.
5. Responding to change over following a plan: of course, see the previous point.

I realize not everyone tackles BPM this way.  And I also realize there’s no One True Way that is always the best way.  But these principles gird every project we do. I agree with the principles in the manifesto, but BPM practitioners should already be abiding by these principles.  If that’s not “traditional” BPM, so be it.  I may not be able to convince everyone to define BPM the way I would, but I can still advocate for our approach.

Side note- I like another point Jacob makes:  “Though many position ACM as a way to respond to change, for me it is a process oriented way to focus on individuals, interactions and working software (which make it more amenable to change).”

The “P” is for Process.

I think Mihnea Galeteanu coincidentally gives us a great anecdote for why it doesn’t make sense to try to change the terms of the discussion or debate from “process” to “case”, or from BPM to ACM:

Once you’re done reading this blog post, I dare you to stand up and look for wherever people congregate in your office, perhaps around water coolers or coffee machines.

Not only will it be good to get that much needed exercise (just saying) but I’m also confident you’ll confirm my theory: whether in English, French, Spanish or whatever other natural language, your colleagues will be talking/complaining/debating about a process. What a company does, how it differentiates itself in the marketplace, how it orders everything from paper clips to engine parts, can all be expressed in terms of a process.

Process is the language of business

When something goes wrong, it’s either because there is too much process, too little process or the wrong process. Likewise, when something goes right, it’s because the right resources (people or systems) were engaged at the right time. What dictates that is again a process.

I’m not enamored of the idea that Watson might actually understand nuance and context well enough to help with process improvement – but I do think he hits on the right point that process is the language of business today. That’s our opportunity in BPM – we just have to keep delivering on it.

Jacob Ukelson’s post about extending Data Loss Prevention through ACM took time out to list out four areas of “process” work if you will:

• BPM (Business Process Management) – The focus is on structured data (forms) and structured flow.
• ECM (Enterprise Content Management) – The focus is on unstructured data (documents) and structured flow.
• DCM (Dynamic Case Management) – The focus is on structured+unstructured data (forms and documents) and semi-structured flow.
• ACM – The focus is on structured+unstructured data (forms and documents) and unstructured flow.

Sandy Kemsley commented on Twitter that she sees these four ideas as more of a spectrum from more structured to more unstructured, rather than four distinct areas.  I agree.  In fact, she later wrote a detailed post about it, including the following depiction:

Spectrum from structured to unstructured - courtesy Column 2, Sandy Kemsley

Sandy’s working on a whitepaper on the subject, which I’m looking forward to reading, as I happen to agree with her starting point thesis (and her visualization is better than mine, in this post!)

Another visualization is with two axes, however- “Data” and “Process” – which can exist across some wide spectrum of how much structure is there.  The standard 2×2 chart comes to mind.  One might draw it like this:

This would likely make everyone outside of the BPM “purists” happy.  But it isn’t quite representative, as it makes it look like the four boxes are really distinct, rather than blurry.  And the placement of ACM and DCM isn’t right on this chart, but bear with me.

But as Sandy noted, it isn’t clear that the other three things aren’t also “BPM”.  The chart many BPM practitioners would draw for this looks like the following, with BPM dominating the landscape and covering a wide spectrum, and the other ideas covering rather smaller areas of the spectrum.

BPM 2x2, Alternate View

I think this is how many BPM practitioners see the world (whether we agree or disagree with this view, we can agree some people hold this view).  Note, the spectrum is not weighted based on the number of processes  – the density of processes in each pixel, if you will.  I think most people would agree that there are more unstructured processes than structured ones in the universe today.

A third view that I’m seeing emerge:  It is all BPM and we’re just talking about the definitions of different branches of the main tree.  Some would argue, reasonably, that this dilutes what “BPM” means too much, and some would argue that arguing that something that walks like process and talks like process should be considered “in scope” for BPM.

Jacob and I agree that the differences are largely one of focus – of the vendors and of the practitioners, rather than technical capability.  Keeping in mind that the differences in focus might make it much easier or much harder to deliver a solution in the sweet spot of one of these approaches to process.

(Editor’s note: I’ll just apologize now for the sensational title)

Well, actually, Max J. Pucher is declaring ACM dead, and Adaptive as the worthy successor to ACM (“ACM is Dead! Long live ADAPTIVE!“).  But the article overall is curious – because it marks an official departure from the ACM camp that Max has been alluding to in comments on various blogs and forums for months.  Paraphrasing, he’s tired of fighting over the definitions of three letter acronyms, and tired of compromising and watering down the definition of the terms to suit all the various vendors who want to play in the space.

As he writes:

There was never a doubt that we all live in the ‘BPM State’, but we have different ideas how to govern it. Many ACM proponents feel that a lesser definition will allow to include more aspects and more vendors. That is a mistake. Opportunistic coalition governments of many different small fractions ALWAYS collapse sooner than later. I feel that we have missed the opportunity of truly advancing process management with the limited ACM approach. Dynamic Case and Process Management are now seen as like definitions to ACM. But it is not just about ‘unpredictable’ work items, but about a more globally encompassing technology approach that is linked to business architecture and strategy. I defined what I saw as relevant for business – and not as market segments or product categories – shortly after the ACM acronym was chosen in a post on Adaptive Processes. But so be it. I rather be Brutus and end this senseless debate to focus on what businesses truly need.

I think he has a point.  ACM has been defined thinly (broadly?) enough that it could mean Twitter or Yammer (or nearly any social tech). Or it could mean Blueworks Live, or Appian.  Or Asana.  But Max is pushing for a more definitive take on something – and giving up on redefining BPM and ACM per se – he’s going with the Adaptive moniker or paradigm:

What cannot die is the ADAPTIVE paradigm, that – much as the principle ideas of freedom and democracy – will continue to guide those who do believe that people empowerment is the way forward. Those who believe in strict governance, because they can’t believe that people can govern themselves with a limited set of guiding rules, will have to learn the hard way. The dynamics of natural evolution will create the tension that will eventually break the chains of rigid processes.

In principle I agree with Max that empowerment is the right answer.  But even “people empowerment” has different interpretations to different people – I’ll admit that although I read all of Max’ posts, I still don’t know what Isis Papyrus does, in detail.  I just know the principles that Max has in mind that his product(s) support.  (That’s probably better than knowing a set of functionality without knowing the foundational principles, however!)  Interestingly, in Jacob Ukelson’s lists of risks of ACM failure in 2011, I don’t think fraying of the ACM community was one of them.

A Cautionary Tale of Two Names

Of course, any “name” runs risks.  Working at software companies I often observed code names being assigned to releases.  The code names meant something to the people who hear them – but the problem is, they often meant two different things to two different people.  The release name implied particular features, initiatives, and bugfixes.  The names became a shorthand for the functionality.  What’s that? Waiting on support for Linux?  That’s in the kubrick release.  In the future, you just equate “kubrick” with “Linux” (and myriad other features that might be included).

But the product engineering team often has no such mind-map. The code name just ties to a release date.  The exact set of final functionality is subject to change until code freeze.  But this difference in understanding what a name means, presents all kinds of problems. One person thinks that because kubrick is shipping next week, they’re getting Linux support, and doesn’t even think to ask if it is still in, as it might have seemed like the defining feature of the release.  But the developer just knows that kubrick is shipping, thinking nothing of Linux, and doesn’t even think to mention that Linux support was dropped a month or two ago in favor of a localization effort.

When the release comes out, you can imagine what happens.

One can argue that everyone should be looking at the release plan, which is frequently updated, to see the latest “in-out” of the release-  but this just isn’t in everyone’s daily work routine. One can argue that engineering should communicate each change to the whole company – but when should that communique happen? Often these decisions are made and rescinded over a short period of time – and some of the changes are so minor that announcing to the whole company amounts to spam.   It’s a challenge, but one that has to be managed to avoid these misunderstandings.  And a good point of discipline is for Engineering to note use this codename shorthand for anything other than features that can not be dropped from the release.

What Does this have to do with ACM? or BPM?

My thought is simply that we have, already, an “all encompassing three letter acronym”.  Its BPM.  As Max says, we all live in a BPM state.  The question is how to get the most out of it.  Some say ACM.  Max says “Adaptive”.  I’d like to talk about it in more granular terms that defy a single phrase to rule them all.  Because I fear that if Adaptive becomes the term du jour, the vendors (of which Max’ company is only one) will again butcher the usage and the meaning beyond recognition, or at least, beyond consensus.

I just think all of our energy is better spent focusing on solving problems for customers, regardless of what labels analysts and vendors apply to the work and to the products.  I think I’m actually agreeing with Max on this, if I understand his posts correctly.  I hope the broader community that lives within this BPM state will agree as well.

It looks like I’m not the only one who feels this way, as the Process Cafe’s Gary Comerford writes:

There appears to be a move in the BPM world to create a whole new substrata of ‘process management’. Max Pucher appears to be one of the leading members of this cadre and – like so many before him – he tries to establish a little niche ‘fiefdom’ which he can call his own. Andrew Smith from  One Degree has posited Adaptive Process Guidance (APG) as a new paradigm too. Forrester have created Dynamic Case management

And bravo to them for doing that.

But here’s the problem I have: Why seek to split the capability of BPM down into different acronyms or niches when we don’t fully understand BPM as it stands at the moment?

Indeed.  But the lure of a fiefdom is just hard for software vendors to resist (especially after a round of acquisitions).  I’m not sure that that is what Max is trying to do – but the general tendency is there in nearly every marketing or PR release you see from a software vendor (“the leading <fill-in-a-narrow-intersection-of-attributes> vendor in the world”).  Define things narrowly enough and you can be #1.  But I prefer the approach a company like Apple uses.  Sure, they could define their market as “touchscreen smart phones” in which they likely dominate in share. But they define the market much more broadly. It encourages them to set higher sights.

Is ACM dead?  Not in the way you might think from the title.  There is an avid community promoting the acronym, and the methods, that ACM acts as a catch-phrase for.  Many an analyst paper and a vendor product announcement will discuss ACM for many moons to come.  I guess the question is how much wind is behind the sails?

Anatoly’s excellent blog turns its attention to ACM:

Adaptive Case Management was one of the most discussed BPM topics in 2010. It transformed from fuzzy marketing noise into a more or less consistent concept over the past year.

Why “more or less”? Because even the authors of “Mastering the Unpredictable” – probably the most authoritative book on ACM to date – say in the preface that there is no consensus among them, so the book in essence is a collection of articles. Nevertheless there are more similarities than differences in their positions, hence the consistent concept.

He goes on to give his take – an admittedly different perspective from many of the other authors on the subject and an interesting read.  He challenges the orthodoxy of both ACM thinking and BPM thinking in his blog, which is part of why I find it a refreshing read.