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.

(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?

Max J. Pucher always writes interesting copy on his blog.  And one of his latest, on BPM and the Jobless Recovery, is no exception:

Well, I propose that it is the efficiency and cost-cutting mindset also employed in BPMS justifications that is a major cause of the ongoing lack of jobs in the US. BPM implementations focused on automating work with flowcharted processes (and excuse me,  the majority are!!!) are only usable for a subset of work – those repeatable, low value, high-volume admin processes that ERP can’t handle. The ROI justification is virtually always about less people needed per revenue!

I’m afraid that BPM isn’t in such common usage as to affect the staffing decisions of the local bakery, the law firm, the ad agencies, and the factory floors, which have all shed quite a few jobs in the US (and, of further note, manufacturing jobs in most countries around the world are in decline, as non-BPMS automation is displacing more and more human workers in the manufacturing process).  And it isn’t relevant as an explanation for the dramatic job losses in construction, real estate, mortgage financing, and other related businesses.  (Moreover, according to the New York Times, Eurozone unemployment was steady at 10% as of May 2010… perhaps the US is more volatile, but at 9.6% it doesn’t seem to be an order of magnitude off).

While I agree with Max’s frustration with companies that are so focused on cost-cutting that they’ve cut bone as well as fat – and I agree that this extreme cost-cutting actually deepened the recession and slowed the recovery (because, in this particular recession, the primary driver has been a reduction in consumer spending, rather than in corporate investment).  But BPM is hardly the reason that home building, mortgage processing, loan origination, and other related fields were hit so hard. Quite simply, there was a bubble in that segment of the US economy that had nothing to do with BPM. The bubble led to over-investment, and the bubble bursting led to dramatic re-valuation and contraction in those sectors.

But there’s more meat to Max’s article, regarding the cost of BPM implementations:

Yes, I totally agree with Jim’s assessment of the complexity and substantial people effort need to get BPMS implemented. Some of the cost is also not process related, but caused by the technology stack being used and the resulting INTEGRATION work. Therefore I propose a consolidated platform rather than integration with others. Businesses who try to integrate existing ECM, BPM, CRM, BRM, E20 and BI suites will never achieve a truly dynamic, adaptive and financially sound BPM.

Not too much to take issue with there. Integration is usually one of the biggest costs… And later:

Because the BPMS skills are expensive and rare they are mostly provided by outside consultants. In effect that means that once the processes are implemented the people who know and understand them move on, leaving the business with unskilled workers and killing the ability to improve or innovate. This is the worst possible business proposition I can think of.

(Max’s emphasis).  Max is blaming the wrong party here.  If businesses are left with unskilled workers, then it is the business that must change – by hiring and retaining talent for improvement and innovation.  Hiring consultants as part of a strategy for change makes sense. But making outside consultants the beginning, middle, and end of a strategy for change is not the answer.  Like *all* human resources applied to projects, consultants will move on.  But so will full-time employees.  It is important to build enough critical mass and momentum in BPM efforts to create sustainable organizational learning that can survive the departure of a key team member(s).

Mainly, however, I disagree with Max’ dark view of BPM:

I hope that Jim is wrong with BPMS adoptions speeding up and that we are rather on the verge of enough people realizing that BPM as a concept that turns people in to process monkeys is a failure.  In the worst case, it won’t just be the ‘jobless recovery’ that is going to crash on top of us, but it will be the inhumane, fully automated, mass-produced, market-segmented, analytically predicted process nonsense that will make even those customers walk away that still have a job.

As I’ve argued many times before, BPM can’t be about turning people into “process monkeys”.  It has to be about removing the mundane, and enabling the real humans in the process to excel.  Once someone’s job has been reduced to “process monkey” it is truly something that will be automated.  The point is to remove the “process monkey” parts via automation and leave the judgment calls behind.

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.