So Jim Sinur really opened a can of worms the other day with his missive on BPMN, literally calling for it to burn baby burn – nothing like a gentle start like that to initiate a moderate discussion of the finer points of BPMN.  I couldn’t help but respond both within his blog as well as on our own blog.  I feel like Jim is letting the business off the hook – as he puts it – they don’t care about process, and they’re too busy making money to worry about process.  I think this is a cop out.  There is a comment thread on Jim’s blog that I’d recommend reading for the follow up discussion, and the original “burn baby burn” statement got walked back somewhat.

But the debate didn’t stay contained there.  Keith Swenson chimed in, taking advantage of the opportunity to pile on BPMN.  I can’t accept the black-and-white approach he is taking to the discussion, and so of course we had a bit of back-and-forth about whether BPMN is appropriate for no one in the business (his contention) or at least some people (my contention).  I was challenged to name people within the business who read or write BPMN, which was quite easy to do, because this is the kind of stuff we do every day for work.  I think the comment thread on his blog, and on Jim’s, or incredibly telling.

But there was also a great post from Neil Ward-Dutton on the subject, that captures my perspective perfectly:

Or – in other words perhaps – surely it’s not too much to ask non-IT participants in BPM initiatives to take a little time to learn some fairly straightforward modelling technniques?

From our case study work here I think what Scott is saying leads to a sensible, middle-ground answer – which is, that the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for “the business” is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that “the business” is some kind of homogeneous organisation with one set of skills, experiences and inclinations.

I literally could not have said this better myself. He goes on to make another important point I agree with:

At the same time, though, there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams. I’ve come across many BAs who know and use (aspects of) BPMN as part of their armoury. They’re not “IT people” – they have business backgrounds and they work in line-of-business departments.

Great read from Neil.

In the comments on this one, Keith takes a nice shot at my assertion that understanding just a few BPMN shapes will allow you to read someone else’s thoughts on a process, or to communicate your own basic processes to others:

Also funny is the comment that learning six (or 7) shapes means that you understand the non-trivial interactions between those shapes at run time without needing the programmer’s insight into how systems function. That would be a little like saying that learning 26 letters makes you a Shakespeare, or able to read all western European languages. (But I must avoid use of similes since this apparently is sometimes confusing.) BPMN certainly is useful is some situations, it simply isn’t useful in all situations.

For the record, I don’t find Keith’s “similes” confusing at all.  I find them inaccurate, misleading, and misrepresentative.  And when we turn the analogy on its head, I think that proves how pointless they are.  In practice, when people read Shakespeare they’re usually in school and get help from cliff’s notes, teachers, and fellow students.  Not unlike those working with business processes and BPMN … and other tools (six sigma, lean, value stream, etc.  ).  Once again, I’ll point out that analogies are illustrative, they simply don’t constitute proof or refutation.

Jakob Freund of Camunda commented on Keith’s blog and summed up a reasonable reader’s interpretation of both Jim’s post and Keith’s post:

I think the main problem is that in both blog posts (Jim and yours) this very important distinction between “all” business professionals and “business (process) analysts” was not made. Analysts are not programmers but very often part of a business department, therefore a subset of “business professionals”. To throw all “business professionals” in one pot judging there skills in working with BPMN (or whatever) makes a good headline, but does not say anything useful.

Furthermore, there has not been made any distinction between “creating” and “reading” BPMN diagrams, and between the extremely different grades of complexity a process diagram can bear (please excuse my bad English).

But those are exactly the parameters you always have to look at when judging modeling approaches (no matter whether they are control flow – based, grids, prosa or what ever).

I guess it just comes down to this: BPMN is quite useful.  It is even useful to people most of us would consider as “business professionals”.  But there are other quite useful tools in our business process management space, and there’s no reason not to use each one when appropriate.  I also recommend as practical reading, this post on practical application of BPMN by Jakob on his own Camunda blog.  I liked how he closed his last comment:

cheers from my customer’s office in Germany (currently introducing BPMN in a 80k-people company, and huh, it works for Business people, but it’s bloody hard work to make that happen  ).

Similarly, as I was writing on the same comment thread, I was about to head in to visit my customer, which also uses BPMN to communicate broad requirements between business stakeholders and IT.  Regardless of what the theory says, the practical reality is our customers’ businesses are using this stuff.

The merger of two airlines has been used as an example of something BPM is not well-suited for, that ACM would be well-suited for.  I gave this argument a bit too literal a reading, based on Keith Swenson’s response (thought exercise vs. demonstration).  But having worked on quite a few BPM projects that were born of mergers (not the act of deciding to merge, but the after-affect of the merger), I found this article on the Wells Fargo and Wachovia merger to be just the kind of external, public information I was looking for to better explain my own views about how mergers happen – and the fact that there really is method (dare I say, process) to the madness.  When you are a big financial institution, or a big tech company (e.g. Cisco), you don’t do just one or two acquisitions in your history.  You might do one or two acquisitions a quarter.  Not all of them will be as big as Wachovia of course… These institutions are constantly reinventing themselves through acquisitions and spin-offs and joint ventures. Any time you do something so valuable, so often, you’ll want to understand it as a business process.

So how do you handle something massive like Trust conversions from Wachovia to Wells Fargo?

This year, Wells Fargo and Wachovia completed one of the biggest trust conversions ever; 81,000 trust accounts and $150 billion in assets were transferred to a common platform. Wells Fargo is now one of the largest U.S. trust providers in the U.S. with 233,000 accounts and $1.3 trillion in assets.

There was a big analysis effort to understand the processes operating at both firms, and to pick and choose best practices from both. After that they modeled these processes, simulated some of them, and implemented.  Some interesting ancillary benefits:

Another benefit is that the use of business process modeling helps the business and IT people communicate with each other. Instead of exchanging Word documents about requirements and technical specifications, where each side typically had trouble understanding the other, they’ve transitioned to graphical process models where both parties can look at the diagrammed process flow and exceptions. Watkins says this has saved thousands of hours of time in writing requirements documents and interpretation time for the technology developer.

So… is BPM low hanging fruit or was it hard work?  Sounds like it was hard, but valuable, work.  Is Wells Fargo really committed to BPM?

“Processes are pervasive whether you’re facing your customer or in the back office, and there’s been a recognition over the last couple of years among business leadership and IT that we should start focusing on more opportunities around process improvement, where we can leverage BPM technology we already own,” he says. “We’ve trained more than 400 people on BPM technology and technical standards like BPMN (business process modeling notation) as a common language for communicating process improvement,” he says.

Well, what do you think?

Keith Swenson has announced a case management mentor meeting (or ACM Mentor Camp) following the BPM 2010 conference, at the same venue:

The “Adaptive Case Management Mentor Camp” has just been announced.  This will be a meeting of minds for people interested in learning effective techniques for using case management for knowledge work.  It is right after the BPM 2010 conference, at the same venue, symbolically representing ACM as the next thing after BPM.

I think it is a great idea to put something like this together – these informal gatherings are often more valuable than more formal conferences – the only danger is conference burn-out!  At BP3, we’re looking forward to bpmCamp in Austin.   Sadly, I can’t make BPM 2010 this year unless my schedule changes, and therefore I also can’t attend the ‘camp.  Its a great gathering of people, definitely recommend attending to anyone who can make it.  Keith argues that the symbolism is that ACM is the “next thing after BPM” – but I’d argue it also supports my point of view – the same vendors, practitioners, and customers are going to be interested in BPM and ACM…  Keith and I just draw different conclusions about what that means for what will be defined as the “BPM” market.

The Death of Google Wave is interesting.  We’ve written about Wave before, several times, but in particular when SAP put out its “Gravity” demonstration.

The official Google Blog blames the closure of Wave on a lack of user adoption:

But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects. The central parts of the code, as well as the protocols that have driven many of Wave’s innovations, like drag-and-drop and character-by-character live typing, are already available as open source, so customers and partners can continue the innovation we began. In addition, we will work on tools so that users can easily “liberate” their content from Wave.

So, there’s a bunch of open source code, it looks like, that partners and customers might leverage.  But most of us, I think, would prefer to just use a finished product.  There are many other unofficial takes, here and here are two examples.  I had a few others linked, but no need – you can find such commentary easily!

When Wave was announced last year, I spent some time discussing with others what it meant for BPM.  Some thought it was a game-changer, some thought it was a non-event.  The thing that became clear to me: collaboration tools like this are going to tend toward being free, or extremely inexpensive.

Starting last fall, the discussion in BPM circles had often turned to “ACM” (A variant on Case Management).  Some in BPM circles would call this unstructured process. Some would call it “chaotic” or unpredictable processes/work.  Keith Swenson and colleagues even penned a book about managing such unpredictable work.  Google Wave was, to this crowd, a great example of where “knowledge work” is headed – into collaboration spaces, not into BPM software.  To me, it was just proof that email and lightweight project management tools were not going away.   If Google Wave accomplished anything, it showed:

1. Separating yourself from email divorces you from a knowledge worker’s daily routine (some might say, process).
2. If it isn’t trivial to involve the right people in a collaboration, then users give up
3. Collaboration is going to be free or nearly free.  Even if it has pretty amazing features.
4. It is really hard to do a “big bang launch” successfully.  It makes me even more impressed that Apple seems to pull this off with such regularity.

So what does it mean for BPM?  Not much.  Wave was never really about structured interaction, it was about ad-hoc interaction.  Although ad-hoc interaction is important to a good BPM strategy, no one (maybe except for SAP) was really leveraging Wave for this.  If they were, they can probably leverage the open source bits to get a jump on the development effort.  For the ACM crowd, its both good news and bad news.

First, the good news:

1. A free competitor to your products, supported by a major software company, has gone away.
2. Hm. I think that’s it.

The bad news:

1. If you were counting on convincing users to leave email to use your product for knowledge work, it is time to change gears.
2. If you were expecting that being good and free was good enough… Maybe it isn’t.  Although Wave was panned in the press, it really was pretty good at what it did, though perhaps it tried to do too much.
3. If you were expecting to charge a lot of money for general-purpose collaboration software… I think those days are over.
4. If Wave was your favorite example of how ACM was really relevant to what people are doing… time to find a new example.

Silver lining:

1. Collaboration software for very specific purposes will live on (aka process modeling, or services like tripIt).
2. Some of Wave’s features will likely get absorbed by Gmail.
3. Some of Wave’s features will likely show up in other products.

I think Keith Swenson summed it up best for the ACM folks on Twitter:

“nooooo. It can’t beeeee. :-( RT @jpmorgenthal: Google waves goodbye to Wave: http://bit.ly/bg3ixC”

Well, fans of Wave and its approach were bound to be disappointed.  I saw quite a few more comments on twitter with a more positive spin on Wave being shut down.  Google found Wave squeezed inbetween email and all the other things we do in life.  It apparently couldn’t live on its own.  I’m not sure the future of ACM, per se, is anything different.  Yes, the ACM proponents will have their analogies, and they sound compelling.  And we could even agree that a large percentage of work is not addressed by BPM today, or by, more specifically, structured process.  But what ACM proponents fail to mention is that even less work is currently addressed by purpose-built ACM software.  It *could* be, but isn’t.  It is still likely to be addressed by email, project management tools, telephone, hallway conversation, and more email.

Note, I’m not arguing against ACM as a description of work, I’m just looking at the software market and not seeing it as an independent market, yet.  Willing to be proven wrong.  And I think there are a couple vendors that have the right strategy or tactics, but we’ll see if they can execute.

Working on a longer collaborative post on ACM and the marketplace.  Watch this space.

Recently Bern Ruecker’s article on “A Collaborative Approach for Real-World BPM” appeared in InfoQ. It is a good read, with much I agree with and just a few things I don’t.

We have been working in the business process management (BPM) space for years already, and it is very interesting to see the recently growing attention for it. Catalysts for this interest may be the growing maturity of the tools, the new 2.0 version of the BPMN standard, better understanding caused by more publications or improved preconditions for BPM approaches, to name only a few of the most important developments within BPM.

Couldn’t have said it better myself. Bern goes on to criticize tools that they’ve worked with:

Vendors offer more and more high-sophisticated graphical tools, which promise automation of business processes without any coding or even developers; however, we see a problem with these “traditional” vendor centric approaches: They don’t deliver on these promises!

Agreed.  But of course, most vendors don’t promise “no code” – but they do often claim that someone less than a true “developer” can deliver the solution.  In my experience, while these tools do enable personnel with less technical training to participate in the process development effort, there is no such thing as someone “too technical” for a BPM project.  Good technical help is important in any project involving information technology.  He goes on:

Without naming the concrete tool, which wouldn’t be fair since most of them share the same basic problems, a colleague had to implement an easy process with a small web GUI. The tool introduced an own magic Drag and Drop GUI designer, which seemed to be handy in the beginning, but when we almost finished the project, there were some small data validation requirements in the form, which the magic tool wasn’t designed for. In an attempt to get around these limitations, we spent more time futzing with the designer than we needed to implement the entire GUI in plain JSF, which we did in the end anyway.

I can understand his feeling here.  However, I have worked with at least one tool that has such a drag-and-drop GUI designer.  It is great for prototyping UI, as it requires no code to marshal data into and out of the the process context on the server.  There is also a validation framework that does just about everything imaginable for validation (but, admittedly, this validation framework is something only experts on the platform would know about).  There’s also an option to validate forms after submitting (in the event that validation can only be accomplished with server-side checks or more complicated business rule evaluation).   My concern with the statement above is, though it may be true for a single tool – a good understanding of the BPM software being employed, combined with good understanding of requirements, and with healthy value-based prioritization of work – should allow one to avoid rewriting the entire GUI in something like JSF.  Of course, in Bern’s specific situation it may have been necessary, but I believe that on the whole we’re better of leveraging the baked in capabilities of a BPM suite rather than writing custom interfaces in JSF (or other UI tech).  The exception being, if the customer is already an expert in the custom interface technology (already using JSF in their organization? great).

We, as BPM practitioners, have to keep in mind that it is not about the technology we’re most comfortable with, it is about technology our customers can consume, maintain, nourish, and build on.

Bern goes on with another anecdote:

For another customer, one developer told me, “It took more than two days to try to model some special requirements, which he could have written in Java directly in half an hour!”

I’ve heard this thousands of times.  9 out of 10 times, the developer is wrong, or missing the point.  Once in a while, they’re right.  But the point isn’t to bury the business model in Java code (wrong), or to put what should be Java code into the business model (missing the point), it is to use the model to represent what is significant to the business process, and to use code to represent (primarily) what isn’t.

Another customer tried to get transactions and stateful services running, which unfortunately required calling services as Web services. After experimenting with WS-Addressing, WS-AtomicTransaction and trying to patch several frameworks, he basically gave up and dumped the whole BPM tool.

I wish I knew which tool so that I can avoid it!  A decent BPM tool should include good coverage of web services scenarios.  And a Java API.  Bern’s article is a cautionary tale of products that don’t live up to the promise of BPM.

Bern goes on to argue that a BPM tool should be making the developer’s job easier, not harder.  While that may be true, I think the framing is wrong. The framing we would use is that a BPM tool should allow a model that accurately portrays the process to the business and also accurately represents the execution context required to run the process.  If it is harder for the developer to provide visibility to the business, that’s secondary to producing something that has high-fidelity between business model and IT reality.

Bern goes on to describe a solution that he calls “Camunda Fox” – which pulls together various other technology, including JBoss, jBPM, Signavio, and a glue layer created by Camunda.  It seems like a reasonable approach for a very technically competent team to tackle – especially a team that is intimately familiar with the technologies in question.  But it is a model-transforming approach with several inputs and outputs.  And this approach isn’t going to address the needs of a smaller business or smaller team that doesn’t have these technical skills, nor the budget to pay outside consultants to build and leverage this glue – I think Bern might argue that the “simpler” BPM tools won’t address these customers well either.  As Bern says, Camunda Fox isn’t a silver bullet, but it addresses projects that are pretty Java development focused.

I prefer to use BPM tools with a model-preserving approach (as described by Keith Swenson) because it is a higher fidelity mapping of business process to running software.

Keith Swenson has another post where he compares Case Management to BPM:

“The two approaches are very different:

• Sherlock Holmes will use a case management approach, not a BPM approach, when solving a case.
• Bank of America will use a BPM approach, not a case management approach, to support signing up people for new regular accounts.
• Admiral Thad Allen will use a case management approach, not a BPM approach, when responding to the oil disaster.
• Amazon will use a BPM approach, not a case management approach, to handling sales of common books.”

I’d propose another example:  I sure wish BP had been using a BPM approach on that oil rig, rather than a case management approach that allowed winging it with decisions like whether or not to use drilling mud.  I wish there had been a little more BPM going on in the mortgage business pre 2008 – not just signing up new accounts but making sure that customers actually met credit and income requirements.

I think there are more than just mundane examples of where a little more BPM would be a good thing.

Keith has another interesting comment:

To say that these approaches are the same, because they both help to get work done, ignores the very essence of BPM and case management. Yes, they are both techniques to help accomplish work, but they achieve this result through different means.

[...]

This has nothing to do with any vendor’s product. I am not making a sales pitch here. Those that say their favorite BPMS can do all of this are simply pointing out that these two management practices can be supported with similar technology – and many products will support both approaches. But remember, BPM, and Adaptive Case Management are not technology, not products. They are both approaches to managing work.

Interestingly, because they are both approaches to managing work, the same people are likely to be involved in both approaches.  One can argue about which approach “wraps” the other approach, but as BPM is an amalgamation of techniques and approaches, the question (to me) is whether case management is just another one of those, or whether it is a whole “methodology” unto itself.  A relevant example:  Six Sigma and Lean are examples of different approaches to process improvement that, today, most people lump together because they both represent useful sets of tools for the same set of people engaged in process improvement.

Steve Wood, in the comments, captures my thoughts well:

“So, for example, when I look at how an agent supports a customer through an issue. At the high level, it’s very BPM-like, at the implementation level it’s very hybrid. I can optimize some tactical processes to improve performance and also optimize tactical experiences to improve case management.”

And of course, Max J Pucher has a well-worded  comment also:

“Analytic knowledge provides conversation pieces but no practical how-to knowledge and is thus quite useless.

The ‘war of who owns ‘adaptive cases’ is thus quite senseless. I do agree that I am chasing windmills in asking for a common sense approach, but at that is also the reason why the question whether BPM, ECM, E20 or ACM will bring adaptiveness won’t be agreed upon.”

Its an interesting read in the discussion / comments and the wealth of different perspectives – even from people who co-authored “Mastering the Unpredictable”.  Unfortunately, as with most of these discussions, there is a little too much focus on the arbitrary limitations of software tools (the specific experiences of the authors with either specific ACM or BPM tools), rather than sticking to Keith’s original premise that we’re talking about two different kinds of work, but it is a small blemish on a good discussion.

Keith has an excellent post in the form of a Q&A session, as a followup to an ebizQ recorded session that didn’t have time to address all the questions that came in.

Some choice quotes:

The knowledge worker supporting “planning by doing” approach is less about up front definitions of a process.  In general it seems to me that rule sets are primarily useful in order to clearly specify an automated response, and must be prepared ahead of time.  It is hard to see how you would use such rules when directly performing the work.

I can imagine someone defining fairly trivial rules – such as requiring approval above a certain $ threshold after delegating some work to someone else, and deciding that “on the fly”.  But as he says, “in general” the whole point of rules is to address rules at design time, rather than on the fly at run-time (other than by executing the rule)…

4. HOW DOES THE CONCEPT OF A SERVICE ORIENTED BUSINESS APPLICATION(SOBA) RELATED TO SOCIAL BPM, IF AT ALL?
SOA is an orthogonal concept to BPM in general — although there is a widespread misunderstanding about them being similar or the same thing.

Agreed.

Q&A #7 was particularly well-done, as it relates to something Keith has been thinking or writing about a lot lately – unpredictable work and how to track it or measure it – too long to quote here, but please link over to Keith’s page and read it.  He breaks down at least 4 approaches to tracking unpredictable work for the purpose of better understanding it and improving it.

Keith has one more anecdote I had to quote because it is mind-boggling in hindsight:

I remember a friend who was at a company that was acquired by Computer Associates in the 1990′s.  At that time, CA ran an email system, but they allowed access to it only at lunchtime and after hours.  You see, nobody was allowed to access email “during working hours”.

Well, I think it is safe to say that “social” is facing some of the same challenges in the workplace today.  But 15-20 years from now people will look back and wonder that companies weren’t more encouraging of tools like Twitter and others to get work done.

Keith Swenson makes the case for simpler run-time editing of a process in the comments on one of his blog posts.  This might even be a small insight into where his conversion to the Case Management fold comes from:

“The difficulty with changing a process comes when the person who needs to make the change does not have the skill to understand the process editor and the implications of any given edit.”

This is a failing of many of the BPMS tools ( and even worse, for the pre-BPM tooling out there – no one even tries to edit the process for an ERP system! ) …

“This has led us to believe that to allow a process to be changed, there needs to be a very simple process paradigm — like a checklist — that can be easily modified by 100% of the managers. It is not a technical challenge, but instead a usability challenge.”

I think the basic point here is: software vendors need to invest in deeply understanding the needs of the users (managers) and invest in giving them control over complex changes with simple analogs (e.g. checklists, but I’m sure there are other approaches as well).  I think the software vendors still have a long way to go to make the hard stuff easier, and this is really the whole point of software engineering – to make the previously impossible possible, the previously hard easier, the previously complex understandable.

(Just yesterday I was checking out RAVEN, for example, which converts text descriptions of a process into flow.  It is a pretty simple modeling approach.  Blueprint offers something nearly as useful – you outline, which is converted into process flow on the fly.  However, Blueprint doesn’t attempt to parse your sentences for nouns that indicate swim lanes or actors.  )

Keith Swenson plays “Go Fish” with BPM Definitions:

This was not a scientific study — just a couple of hours of google searches to try and get a feeling for the deviant definitions.  The collection above is not representative — I picked what I felt were the most unusual definition.

Look, people have a lot of different definitions for what constitutes Tex-Mex*… but that doesn’t mean you won’t like it, or that it isn’t good.  You will, and it is.

People have different definitions of hot weather and cold weather, too.  I don’t feel that this diminishes our ability to discuss temperatures and humidity and, even, hot weather.  Colorful language is just part of the fun.

The part I find more agreement with:

My overall conclusion is that there is an “IT community” which talks about BPM as being equal to/converged with/part of system architecture/SOA/EA.  This community represents 30% to 50% of what articles on BPM.  There is another “business community” that represents the non-IT management side and sees no connection to system architecture at all, and that is maybe 40% to 55%.

The problem is that these two communities don’t communicate with each other.  They have their own magazines, their own blogs, their own books, their own analysts, their own forum sites.  Like the Democrats and the Republicans, these groups are being polarized by their own in-bred ideas bouncing around an echo-chamber of their own making.  It is a divide with potentially tragic consequences for the technology consumer.

Communication is incredibly important – BPM doesn’t cause this communication rift- but BPM projects really expose this issue because of the close proximity of the IT and Business team figuring it out and the iterative nature of the projects.

* if you don’t know Tex Mex, please come to Austin Texas and we’ll show you.

I’d been looking forward to hearing what Appian would say about their “Technical Case for Case Management”.  Part 1 was just a teaser, and Part 2 promised to get into more details.

But when I read part 2, I could just hear Keith Swenson’s dismay (or actually, share it).  Appian describes it thusly:

The first and foremost feature in a Case Management solution is “Ad-Hoc”.

While I appreciate the effort to explain how Appian addresses case management,  that is a very underwhelming start.  The use of ad-hoc activities in BPM and BPMN is well-known (and well supported by at least some of the tools that aren’t BPEL-based).

But this is *not* what Keith (and others behind the ACM movement) are talking about when they talk about case management or ACM.  While the “ad-hoc” activity may happen at any time or place or sequence, what the ACM crowd are after is that not only is the “when and where” undetermined at design time, but also the “who, what, and how” is ad-hoc – determined *at* run-time.

Hopefully we’ll see someone step up with a better explanation of the technical attributes of their case management solutions.  I shouldn’t be too hard on Appian – at least they’re trying to explain the underpinnings, and this was only part 2 – perhaps in subsequent articles they’ll have more to say – but part 2 was not encouraging to me.

Keith Swenson weighs in on Social and BPM:

Similarly, proper use of social software will be about individuals producing, publishing and running their own processes. Not collaboration on the design phase, but designing individually, and collaborating with a completed process.  This won’t just be the BPM lifecycle using social software, it will be the elimination of the BPM lifecycle, the elimination of a design phase, the elimination of the separation between designers and workers.

How our expectations have changed in just a year – I read the above statements and agreed.  And yet, I remember a year ago even getting people to buy in to the idea of social features around designing BPM was a stretch (here’s a post from barely 9 months ago on the subject).

One thought-  social collaboration on structured processes will be important, just as Keith argues that collaboration on “user-designed” processes will be important.  As Keith put it “collaboration on the finished product” (his emphasis).  Social collaboration of users within a process could result in best practices bubbling up – much like some of the improvements discovered on factory floors by the people who work the line – but you have to have support for collecting and acting on that feedback over time.

The only part I really couldn’t agree with:

“This won’t just be the BPM lifecycle using social software, it will be the elimination of the BPM lifecycle, the elimination of a design phase, the elimination of the separation between designers and workers.”

The work will change, but I don’t believe process design goes away.  I think it just means that a rising tide lifts all boats- making more processes accessible from an ROI and skills point of view – not eliminating the need for design on a significant number of processes.  In other words, I don’t think that process collaboration turns process designers into typists whose job has become obsolete because everyone does their own word processing and typing.  I think it is a bit more like introducing productivity tools that make something that would previously have been difficult, easier.  Lowering the barriers to entry, rather than eliminating the whole discipline and process of process improvement.  However, I reserve the right to disagree with myself in a year or two as we see what the future holds! We’re still learning what “social” can mean for our businesses – too early to close our minds to a range of possibilities.

(As an aside, this article from Keith is a good read, but I disagree with his conclusions)

Keith Swenson on Airline Mergers not using BPM, making the case for ACM:

Usually when I talk to BPM experts, they say something like “Of course you wouldn’t use BPM for something like a major airline merger”.    Most people understand that you would never use BPM to arrange a lunch with a colleague.    There is broad understanding that there are things that BPM is simply overkill for, or too slow for.

The merger between United and Continental is a unique event.  It has never been done before, and will never be done again in the same way.  It has similarities with other mergers, but not to the level of detail that specific action plan (process definition) could be drawn up and re-used.  This is a case where a pre-defined process will simply not be worth the benefit, or the cost in terms of delay.

Am I to believe that they used an ACM product for this?

Going into the weeds here, though I think that makes my basic point, here’s some of the background thinking:

Companies that engage in acquisitions a lot actually do have pre-defined processes for acquisitions – IBM, Cisco, Oracle.  Are there parts of the acquisition that don’t fit neatly in a box? sure there are.  That’s why it is called BPM, and not automation.  Keith is giving us a false choice: all paths must be defined in BPMN in order to be BPM, on the one hand; on the other – nothing predefined in ACM and process nirvana is achieved.  I’ll just assume that ACM would equal process nirvana in this case, and focus on the BPM choice to demonstrate my point.

With the right abstractions in your BPM models, you don’t model all possible choices, the choice is just data along the path to the next node, rather than having a separate path per choice. Nodes can be well-defined BPMN models, or they can be applications, or they can be “ACM” style processes like “Meet and make a Final Decision”, which may end up being 3 meetings or getting some additional emergent process defined.

Or they could map out the process they’d like to follow in Blueprint or ActionBase and go from there – much lower overhead for a one-off process- although THIS process has an effect measured in Billions so it might actually be worth it to spin up some cycles on defining the process even if it isn’t a running implementation of the process.  Yes, requires a little bit of thinking ahead – but it doesn’t require BPMN – and it also allows for documenting any changes as you go.  And yet, I’d still call it “BPM”.  From a technology point of view, these folks may not be using a BPMS to do their acquisitions.  But that doesn’t prove that they couldn’t.  Whether a BPMS would be helpful or not largely depends on how well it supports this kind of use case, and that varies widely from one software package/vendor to another. Part of the problem: is “BPM” defined by what a BPMS can do for you? or is a BPMS defined by what you need to do “BPM”?  Tough one.  But you see this kind of problem all the time in software market definitions.

Do I think ACM could be a good fit for an airline merger? Sure, depending on the specific software and its features – this isn’t a run-of-the-mill situation.  But if I use Keith’s logic, the fact that the airlines didn’t use ACM for this merger is proof that ACM doesn’t solve the problem.  (tongue in cheek)

Generally in my experience if your modelers can’t model the process, you need to find new modelers.  I might need to add a corollary though – your BPMS should be capable of handling abstractions well (like generic failure events, arbitrary data definitions, dynamic binding to service definitions or sub process definitions… )  It sounds like a lot of the folks writing about BPM and ACM still haven’t used a BPMS that supports these features.

(Incidentally, I agree with Keith that you wouldn’t use a BPMS to schedule lunch with a colleague.  However, that’s because there are already good software solutions for scheduling lunch.  If I was writing one of these solutions, like Tungle- I might very well use a BPMS to coordinate finding the right time on our schedule – because it is often done via electronic means and the back-and-forth is pretty inefficient.  Tungle.me didn’t use a BPMS – but they sure could have.  The point of BPM or ACM isn’t to do everything that they could do – it is to apply them when you don’t already have a good solution)

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.

Dave Duggal attempts a take-down of BPMN in a comment on Keith Swenson’s blog, concluding with:

“There is a reason why business leaders are suddenly have wandering eyes, they don’t think BPMN is the vehicle for the component-based distributed future.”

I humbly refer you to Bruce Silver’s blog for a quick rebuttal.  The market is adopting BPMN more than ever, and at an increasing pace.  Better to spend your energies figuring out how to make BPMN more effective (in combination with whatever other techniques you recommend) rather than making your recommended approaches an either-or proposition.  I think I’ve been hearing about this component-based distributed future since CORBA. I’m all for distributed and component-based, but I don’t hear an either-or proposition, and this doesn’t sound like business-leader language.

The question business leaders ask is will BPM and BPMN yield ROI? and the answer is yes.

Great article by Keith Swenson explaining why large and complex organizations are difficult to model using “scientific management”.

I think Keith makes a couple of great points that are worth letting soak in:

• Complex systems are unpredictable
• Organizations that “Learn” can adapt when the environment becomes less predictable.
• If you divide your organization between brains and brawn, you are failing to reach your organization’s full potential.
• Learn from *near* mistakes – not just the *actual* mistakes.

Of his takeaways for BPM- my favorite is transparency:  people involved in the process need to understand the part they play and the context of the process if they are to help the organization learn and improve upon it.

Worth the read and there’s a good comment-stream as well.

On a tangent relating this to political science…

For very complex organizations, it may well be worth applying some theories from political science and international relations to your thought process. One of the most useful political science theories is “Realism” – the notion that nations act in their own best self-interest, in a rational and calculating way.  My first exposure to this was in Dr. Krasner’s course on International Politics.  Usually deviations from what appears to be self-interest can be explained by imperfect information or miscalculation – but in general realism probably most closely describes how most states will act at critical moments of international relations.  In large, complex organizations, it helps to assume that departments, teams, and divisions will apply a healthy dose of Realism to the way they behave.  Part of how you deal with overly complex systems is by having useful abstractions that give you a shortcut to understanding, not ALL of the minutiae of cause and effect, but rather the SUM TOTAL of these effects.  It is much like the difference between micro and macro economics. Realism does not deny the other effects, but it argues that they are secondary effects rather than the primary correlating explanation.

Keith put together a pretty interesting chart reflecting business process technologies over the last few decades, showing how they relate on a spectrum from predictable to unpredictable, as well as how firm the consensus about how to use the technology has become.

Keith Swenson, Thoughts on Collaborative Planning, "4 Process Trends & 1 Gap"

As usual, Keith presents a good thought model.  But of course there’s a gap that may or may not be real – it is Keith’s perception of the gap between manual (email) processes and workflow-based processes.  I think there are actually a range of technologies inbetween these two approaches-  ticketing systems, case management, and wikis are all examples of technologies that address the space described by the gap.  Still, I always find this kind of graph thought-provoking: it organizes your thoughts in support or in contrast to a particular point of  view.

Keith Swenson has a few posts on the frustrations of email these days – and after some time experimenting and a friendly nudge from me, he’s come around and tried OtherInbox.

The problem?  Too much spam, which makes email nearly useless.

The proposed solution (my take):  use an email provider that has a REALLY good spam filter.  Like Gmail.  I have a very old personal address that gets 99% spam but the occasional personal note comes through it.  I forward it through a Gmail account and as a result I see the 10 or so useful emails that show up on that email address per year.

But, Gmail only effectively filters spam.  It doesn’t help you filter merchant emails that you would like to receive, but perhaps not in the quantities that you receive them.  Only some merchants are nice enough to let you state how often you want to hear from them.  There are lots of opt-in situations where you are required to provide an email address.  You could use a single “spam email” to opt-in to all these confirmations, etc.  But then you can’t tell who gave your email address to the spammers when it does go bad, and you can’t turn it off selectively.

OtherInbox solves that problem by letting you give each merchant a unique email address that you can later turn off if it becomes an avenue for spam.  You can also use it to sign up for group mailing lists, and the like, which are more likely to get compromised than some commercial accounts.

I think between Gmail and OtherInbox, you can largely whip the spam problem.  For now…

Keith is consistently writing the clearest thoughts on the subject of “Process Reification” vs. “Model Preservation”.

In this particular article on the subject, Keith focuses on a very common misconception in the BPM community (even by some well known names in the field):

I have met so many people that think that BPM is just a scripting language for SOA services.  These people will argue at length that “BPM is a part of SOA because SOA is useful without BPM, while BPM is useless without SOA”

(Notably, he also references a good article by JP Morganthal which sounds controversial – keeping your SOA and BPM initiatives separate, but which actually makes some very good points about why SOA and BPM initiatives are motivated by different organizational and business imperatives).

But BPM is not just a scripting language for your SOA services.  To quote from Keith’s blog: “SOA is a tool we use, while BPM is what we do.”   I think this is a really important dichotomy to understand, and explains precisely why so many companies that purport to be in “BPM” still don’t really get it yet.

Having just referenced Connie Moore’s thoughts on collaborative BPM, it seems a propos to then turn our attention to “the process wiki” – which I learned about through Keith Swenson’s blog post (“Rise of the Process Wiki”) on the subject (and I’ve since seen a couple of additional references).

If something like the process wiki takes off, it could really change some things in the BPM world.  I’m still a little underwhelmed by what is already in the wiki, but I think that is partly because the vendor-specific collaboration forums offer more interaction with the models directly.  But, where I can see real value is in promoting discussion of the processes that are posted, trade-offs in design, etc.  That’s where it would play to a wiki’s strengths, in my opinion.

You can find a pretty good discussion of the site on Keith’s blog, as it dovetails nicely with his interest in model portability and XPDL as a vehicle for such.