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.

Jacob Ukelson posted about preventing failure vs. fixing failure.  He make a few good points and along the way once again compares ACM / BPM by implication.  In a sense, many will argue, ACM is about learning from failure, and BPM about preventing failure:

One of the key reasons companies deploy a BPM suite is to prevent failure. This is a major selling point for many BPM solutions. A key goal of a BPM suite is to enable the deployment of process driven solutions that prevent a deployed process from failing.

But of course, as he points out later, it isn’t always cheaper to prevent failure rather than fix it. ( Not to mention, in some businesses, fixing it is an opportunity to delight the customer. ) This  is the crux of it:  the arguments about failure are talking past each other.  Process Improvement (BPM) should aim to reduce preventable failures of a fairly routine nature.  Data entry errors, for example.  Logical inconsistencies. This isn’t the primary or only goal, but it certainly is one important form of process improvement for many processes out there. But the idea that we should learn from failure isn’t exactly a new one either… Max Pucher’s blog is an excellent example of this concept in the 70′s and 80′s.  The Lean Startup is an excellent example from the startup world.

If you’re familiar with six sigma technique (a fairly mature method that predates my professional career), then you’re likely familiar with the Failure Mode and Effects Analysis (FMEA).  In it, you rate possible or anticipated failures by:

• Severity – how bad will it be if it happens?
• Frequency – how likely or how often is it to happen?
• Detectability – how easy and reliable is the detection of the failure (or pre-detection).

Different remedies apply to the failures depending on their characteristics.  Often this is applied at a pretty tactical level.  But conceptually you can apply it at a macro or management level.  Such aphorisms as “worry about what you can control, not what you can’t” and “prepare for the worst hope for the best” are perhaps simplified examples of this kind of thinking.  Much business advice could be reduced to focusing on what matters and letting go of what doesn’t.  Some failures don’t warrant preventative treatment, and some do.  This isn’t exactly a new idea.

The kind of “preventing failure” behaviors that ACM folks are pushing against are mostly organizational or cultural in nature rather than procedural. It isn’t like BPM proponents are advocating that businesses circle the wagons and just focus on preventing failures.

So in summary -  where you want to play it safe deploy a process solution focused on managing structured processes, if you need agility (and are willing to accept its associated risk) then you should focus on “first fault problem resolution” for your unstructured processes – rather than try to structure them to prevent failure.

This isn’t as easy as it sounds for some businesses.  Let’s talk the First Horizon oil spill disaster in the Gulf of Mexico.  Did they need agility or preventing failure out there on the platform?  And which situation did their decision-making process most resemble?  (Given that individual operators could and would override long-established safety protocol, I think we can infer that they were on the side of more agility vs. more preventative).  Other businesses, and other situations, would have a different profile and tolerance for various kinds of failure.

If you’re going to have agility and learn from failure, don’t forget one other thing.  You need really good leadership.  If you don’t have that, the results of failure might surprise you.

Jacob Ukelson writes:

What I think surprised me most is how little BPM is used by most development and IT shops for their own use. Even when a truly structured IT process is being implemented (like deploying an application into production) – the tools are never based on BPM suites.

Interestingly, when I worked at a BPM vendor, we used BPM to run our builds, tests, and other automated processes (with, admittedly, some human-facing steps).  We also built our support site with our BPM suite.  Both decisions were fantastic decisions from the perspective of having everyone eat our own dog food, as well as making experts out of people who might otherwise not become experts.

Recently, I was talking with a startup that is into cloud infrastructure.  And they use a BPMS to make their deployments reproducible.

Two data points don’t make for a statistically significant sample.

A third anecdote sums up what I think Jacob is running into.  A few years ago I stopped by a friend’s startup in San Francisco.  He asked me what brought me to SF – long story short, I told him that my customer was using BPM to do some A/B testing around one of their core processes (a fulfillment process).  His response: “why do they need BPM for that?” and “why don’t they just write the code for that?”

Well, the first question – this is the question one always hears – not just with BPM, but with all kinds of new software or productivity tools.  As I like to say “why not just write everything in assembly right?”  After all – the question is are we using the right tool for the job, not whether other tools could theoretically do the job.

As to the second question – why don’t they just write code?  This is a pretty typical attitude for people who are really adept at writing code.  First, they don’t see a need to learn a new tool to get their job done – unless that tool is an API or a language. Second, they don’t see why anyone else should, either.  Third, they’re often suspicious of commercial software development tools vs. open source tools.  Fourth, they overestimate how many people of their skill level any given organization has at its disposal, and what else those same folks might be working on that is even more important.  What looks easy or obvious to them, isn’t obvious or easy to someone else.

The way I try to boil this down is that the more abstract ideas and organization you have to hold in your own mind, the harder it is to do something.  A BPMS gives you the ability to let go of some of those difficult abstractions (they become models) so that you can hold the same problem and solution in mind with less abstraction – by holding only higher level abstractions in mind.

Jacob worries that this might relegate BPM to a small niche, a la 4GL in the past.  It all depends on the definition of niche.  If a multi-billion dollar market is a niche, I won’t complain.  It was a niche when I started out in BPM.  It is a much bigger “niche” now.

Jacob Ukelson has a fantastic critique of Agile Software – he lists the 4 pillars of Agile, but then points out:

These are all good, important points but they ignore the business perspective! [...]

• Business Value. Software must deliver business value, and that isn’t always completely aligned with user experience or any of the immersive points Mike lists. A application can have a great user experience but bring no value to the business, which means it will either be killed or die from lack of attention. In most cases business value needs to come first, and foremost.
• Platform. Software (even what ends up as applications software) is either a platform itself, or built on (and used to enrich) a platform. This is both a business and technical decision, and can greatly affect the long term success of any software.

He has a point.  My interest isn’t so much in critiquing Agile Software methods – they’re pretty useful to BPM efforts, particularly if you keep the business value element in mind.

But the rest of the post makes a few interesting points, as he then turns the lens on BPM platforms to see how they stack up against both the 4 pillars of Agile, as well as the 2 additional “business” pillars:

• Parallel – the modeling process is a bottleneck, but once completed things can be implemented in parallel

This is interesting.  I suppose in some BPMS environments, modeling itself is a single-threaded activity.  In IBM BPM and IBM BlueworksLive, modeling is a parallel activity.  In meetings reviewing BlueworksLive models you’ll often see multiple editors in action at once capturing feedback or updating the model in real-time.  In IBM BPM, the locking is at a very granular level, allowing for simultaneous editing. In earlier versions, the locking was more coarse-grained but still allowed for quite a bit of parallel modeling because subprocesses were not locked by editing other subprocesses or the parent process. On each of the rest of the points he makes, I agree with his assessment.

He sums up with:  “The problem is the distance between theory and practice. Most BPM suites try too hard to make themselves of value to the business side, and miss a lot of what is needed on the high-end development side.”  I don’t know if developers will ever lean toward using BPM suites independent of BPM efforts, but I do maintain hope that BPM suites will continue to add developer-friendly features as well as business-friendly features.  So far, I’m encouraged by the progress I see.

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

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

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

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

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

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

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

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

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

Jacob concludes:

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

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

I’m sure several BPM firms could comment on this article by Jacob Ukelson, as so many of them have been acquired over the last few years!  Jacob gives “10″ rules for doing this successfully, and they’re all good.  In particular:

Rule 5 – Pretend you are a doctor and have taken the Hippocratic oath – first do no harm. Don’t change anything until you have learned the landscape of the new company. I know successful US executives have a penchant for action – but this is a case where early action can be disastrous. Understand that it will probably take a year until the company is more or less integrated. Maybe I should have put this rule first.

Companies that are acquisitive tend to have a very well-oiled acquisition process.  But companies that don’t do a lot of acquisitions likely put together a team on the spot to go make it happen.  I observed the Lombardi acquisition from the outside, but even so it was obvious that IBM has done a few acquisitions before – the terminology, the process, the time taken, were all indicative of years of practice.  When a company has jargon like “Bluewashing” you know they’ve integrated a few companies.  In the particular case of Lombardi, you have to give IBM credit for giving expression and voice to the “Lombardi” DNA they  acquired, and not just stamping it out with IBM-ness.

Jacob Ukelson recently said:

There was an interesting discussion on ebizQ around the question “What does enterprise tech have to learn from Steve Jobs’ success?” What made it even more interesting for me is that even though the question was asked of the process community, not one person answered “better process management” and certainly not “leveraging a BPMS”. So does that mean that even the process community doesn’t see any way to link outsize success to better process management? – or is this just a quirk related to Apple?

Two thoughts:  first, I think it is a good thing that BPM/BPMS advocates weren’t attempting to take credit for success we didn’t cause.  This doesn’t mean Apple doesn’t have good processes or differentiating process, but with all modesty, I think we have more to learn from Apple than vice versa when it comes to how to run a business process.  It isn’t enough to point at Apple’s success and declare victory for our (or someone else’s) interpretation of how they run their business – we have to tease out the correlated or causal elements and then show that they can be applied intentionally elsewhere.  Instead we should be pointing to those who are succeeding as an example to emulate, not a proof point of our approach – they’re only a proof point if they’re following our lead, rather than the other way around.

Second, I’ve actually made a connection between Apple and BPM several times over the years. I linked to the thread of articles in my ebizQ comment but I don’t blame anyone for not reading them all!

In particular, this one gets the most page views: http://www.bp-3.com/blogs/2009/01/apple-and-business-process-management/

Jacob is wrong in saying that process isn’t what makes Apple great, but he may have a point that process is “table stakes” in the areas we usually think of it (supply chain management, manufacturing, etc.).  Apple’s differentiated processes are their processes for product design and user interface, not to mention their go-to-market decisioning process.  All the great designs in the world wouldn’t be enough if they didn’t have the supply chain process prowess to back them up. But, similarly, all the process prowess in the world isn’t enough if you don’t have the ability to design (see Dell, HP).

Moreover, Apple doesn’t just excel at process where it is obvious.  They’ve innovated with manufacturing process (aluminum casings, glass casings, etc.) that have also differentiated their profit margins and product designs.  These are process improvements – but they’re also process improvements where it really matters.

Jacob goes on to say:

It is clear that companies need to manage processes well, but that isn’t what makes a company great. I am sure Apple had some really good processes, but today those are table stakes. The real battlefield is in the realm of knowledge workers – design, user experience, innovation, customer understanding – and most of today’s process thinking and tools don’t help much there.  That is why I don’t think ignoring process as a success factor is a quirk related to Apple, it reflects what is really important for a company to be successful in today’s world. Process won’t make your company great – design, user experience, customer understanding and innovation will.

Design, by the way, is a process… So is developing a good user experience. The companies that are good at this have process around it – just ask Genentech or Frog Design, to name two. It isn’t “automation” the way most people think when you say “process” but it is a process nonetheless.  But if your focus on process doesn’t include user experience (voice of the customer) – you may find yourself non-differentiated on measures other than price.

I wouldn’t draw too many conclusions from the ebizQ crowd being momentarily focused on product design, etc.  I’m sure that there’s good process behind those efforts at Apple, and it looks to me like we just take it for granted.

History often repeats itself, in software:

The physical topology becomes irrelevant – all that matters is logical topology induced by an application and its components. These virtualization paradigms (and more) have been around in the world of mainframes for decades, and I think we can use those as a map of where cloud computing is headed.

Jacob describes how cloud computing developments are, in many ways, mirroring mainframe computing developments of years past.   Jacob has moved his blog to a new home, recently leaving ActionBase, where, in my opinion, Jacob really advanced the state of industry understanding of unstructured and spontaneous processes.  Jacob is one of the good guys in BPM – someone I enjoy debating even when we disagree, because he really does have a different perspective on the same issues, informed from a different starting point. History repeats itself in other ways- visionary people leave companies that they put on the map, and go on to bigger and better things.  His blog is a great way to keep up with the ideas he’s percolating and engage him in discussion.

These are three different things.  Recently Dave Brakoniecki commented that most successful change implementations or BPM programs had executive sponsorship.  And I responded that, of course, there is selection bias involved- because successful programs will collect executive sponsorship.  I attempted to encourage those “stuck in the middle” to find a way to succeed, and use that success as leverage to get sponsorship and support from executives.

Jacob Ukelson commented (cleverly) that this could have been “more about Business Politics Management” – a subject he wrote about previously.  We even got a nice ebizQ discussion out of the topic.  Adam Deane followed up with a missive on Business Politics Management as well… but this is where I think our paths diverge:

The task should go to head of the department for his review. But everyone knows that Mister X needs to be bypassed. Sometimes it’s because he is a slacker, he will never do the task, he has been in the organisation for years, he doesn’t care about the “procedure” and there is no one to discipline him. Sometimes it’s because he is too powerful and can get away with murder. In any case, trying to force the process to make him do the task will end in tears. The best way is to bypass.

Actually, this isn’t the kind of business politics that interests me.  This isn’t leadership this is conflict avoidance (or resolution).  The politics around the particulars within a process are there – and you have to manage them – but the success or failure of your project depends more upon the leadership of your team and the sponsorship of executives – not the politicking of tweaks in the process.

And lest someone get confused, sponsorship isn’t the same thing as leading in most organizations, though it should be either leading or coaching (taking a vested interest in the outcomes).

Jacob returns to the subject here, but whereas Adam addresses design time of processes, Jacob focuses on run-time:

So yes, Business Politics Management is the cousin of Business Process Management – a kissing cousin. Most BPMS vendors don’t consider politics something a BPMS should address. In my opinion as long as BPMS tools ignore all the stuff that goes on around the process (i.e. politics), but has influence on the outcome of the process – they have a big hole in functionality.

Whether you agree with Jacob’s assessment of BPMS vendors or not, what Dave Brakoniecki and I were more focused on is whether executive sponsorship is a pre-requisite for success for your change management or BPM program?  Or is it sometimes a byproduct of a successfully run program?  Should you just give up if you can’t get the executive sponsorship lined up before you start the project?  (I’m not just talking about funding, I’m talking about truly sponsoring)

It seems even with Business Politics Management we have different ideas about what BPM means… But I’ll step away from the terminology and just focus on the funding and executive support – these are things you will have with successful programs by the end, but at the beginning you may have to go it alone for a bit first.

Jacob Ukelson has a great post on Business Politics Management vs. Business Process Management-

I suggest that we should have a separate branch of BPM that is Business Politics Management – it is the cousin of regular BPM, but for knowledge worker tasks. These tasks are very heavily dependent on collaboration, meetings, discussions, negotiation – and yes politics (in the sense that all interactions between humans involves politics). I think using the word “politics” would cause enough of an uproar that we could actually start understanding how the two BPMs actually are different.

[...]

But realistically that is a job more suited to Business Politics Management, since it requires the kind of knowledge work that involves collaboration, meetings, discussion and negotiations – and yes, politics.

He has a great point – that one of the first processes one should set up is the meta-process for evaluating process opportunities and chartering a project, if you will.  There’s just one problem: software doesn’t solve politics.  And I’m taking the benign definition – software doesn’t help you get people to agree on the right answer, where that answer is subjective or based on human judgment and consensus.

I’ve actually used a process to model the pipeline (funnel) of demand and the actual evaluation process. But the real roadblocks are not in software – they’re in people’s heads.  And those people have to be confronted in person or on conference calls and their objections dealt with.  They won’t always write them down for you to rebut.  The point is, it takes real convincing and persuasion.  Good news folks: these are things that PEOPLE are really good at, and we won’t easily be displaced.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BPM 2x2, Alternate View

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

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

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

One of my favorite industry thought leaders to spar with is Jacob Ukelson.  His company, ActionBase, has released ActionBase 6.5, which sports a new web interface and better support for best practices.

ActionBase deserves credit for not only pursuing a different approach to “process” (some would prefer to say “knowledge work” or “ACM” – I leave it to the reader to choose the term they think fits best), but also ActionBase deserves credit for being explicit about how their products address ACM, rather than theoretical.  You don’t have to imagine how it works; they make it clear through their blog, website, and demonstrations.

That being said, check out Jacob’s brief presentation on the subject.

Jacob’s post on what could cause ACM to fail in 2011 is interesting, especially in that it comes from an ACM proponent.  A couple of statements jumped out at me:

Here is the catch – business folks don’t really understand or buy platforms, they buy applications.

[...]

The biggest issue with ACM is that business process management suites, which for many are the platform of choice  for process implementation, are sold to IT. The IT department understands platforms but doesn’t understand unstructured process. On the other hand, the business understands unstructured processes but doesn’t understand platforms.

To me, this is interesting – because BPM also is (typically) sold as a platform as well.  Pega is probably the only BPM vendor of note that seems to take an application-first, platform-second approach to selling BPM.  It seems to have worked out all right for them overall.

Jacob’s concerns about the risks to the ACM market remind me of some of the risks I’ve pointed out myself over the last year in various forums, because his concerns are complementary:

1. It needs to be a platform sale more often than an application sale (I’m sure there are a few applications that might fit ACM, so I won’t conclude that there is no such thing)
2. IT people aren’t bought into ACM – perhaps just aren’t bought into it yet. You could say this is because the IT people don’t understand (the ACM-advocates’ argument), or you could say that it is because the ACM arguments aren’t compelling (the IT side of that argument)… of course, even the ACM advocates are IT folks, so that muddies the waters a little bit!

My concerns are around whether ACM is a market or a feature-set (as far as the software side of ACM goes – there’s also an approach to managing “unstructured” work):

1. It doesn’t seem to me that there’s a big technical barrier to add ACM capabilities to existing BPM platforms.
2. The BPM platforms that I’ve worked with are Turing Complete.  Meaning, within the context of the BPM platform, I can “program” anything another software program can do.
3. IT may not assign much $ value to something they perceive as being technically straightforward.

As a result, given Jacob’s business-side concerns (Businesses don’t often buy platforms), and given its proximity to BPM software, and given a real lack of a real technical barrier to delivery (the BPM firms certainly have the resources to invest to add ACM to their platforms if they desire)… it looks to me that one possible outcome is a very short market window for ACM to catch on as an independent software category.  We already see vendors like IBM adding ACM-style capabilities to their process execution in the cloud (Blueworks).  I think we’ll start to see these capabilities added to the open source BPM products like Activiti as well.

I can sympathize with the difficulty of selling a business proposition to IT, or a platform to the business – because this is exactly the space good BPM vendors have been straddling for the last decade.

My advice to ACM advocates – don’t worry about purity of your arguments and methodology, just be pragmatic.  If people think that all work fits into an overall structure (largely an argument about abstraction and organization – an IT argument), then explain that ACM may help address those parts of the work/process that can’t be easily structured, and explain how it can augment a structured approach.  Don’t worry about which fundamental principle of work is supreme.

Jacob Ukelson has another couple of thought-provoking posts on Choosing a Process Management Tool, and then evaluating Email + Spreadsheets against those criteria.

The proposed criteria:

1. Ease of to use for all the constituents involved in the proces implementation and execution – developers, business analysts, process owners and process participants.
2. Existing product usage patterns and successful deployments – not just in general, but with the same type of processes.
3. Process implementation speed and agility.
4. Cost – not just the software, but the overall project and maintenance cost.
5. Tool reliability, ubiquity and acceptance.
6. No vendor lock-in.
7. Multiple language support.
8. Participant control – an environment that can be configured into an actual, useful production interface without coding.
9. Ability to implement true end-to-end processes (this is my translation for – powerful, eay to use integration capabilities).

He concludes his evaluation of email + spreadsheets thus:

So given that list – why would anyone NOT use email and spreadsheets?

(For the most part, email+spreadsheets scored well, except with respect to #9)

Well, I read the first list, and it sounded like a good list to me.  A few of these could be tossed out and you’d still have a good list (for example, if your firm is single-language, or if vendor-lock-in isn’t a big concern to your organization).

But once you measure an actual solution against the list, I think we can see a few things are missing:

1. A way to capture information for organizational learning (a massive archive of emails and spreadsheets doesn’t quite cut it).
2. A way to analyze the information gathered – for both process designers and participants (if they aren’t one and the same).
3. An audit trail to satisfy regulatory, fiduciary, or other obligations.
4. Repeatability.  Even executing my own personal process I may not remember what I did last time and execute it differently (and not necessarily better).
5. (I’m sure someone else could improve on my off-hand list here)

Moreover, Jacob gives email a “check” for multi-lingual support.  But email just allows you to type whatever language you want (most tools allow that much).  It doesn’t help two people who speak different languages communicate.  If you are initiating the process and need to include people who don’t speak your language… does email help with that?  Or spreadsheets?  Not in my experience.  But I think we can say that email at least doesn’t *create* any additional burdens on multi-lingual support (and Excel, at least, is multi-lingual) – the application prompts etc. will be in the native language.

But, its hard to argue that email (and spreadsheets) are not tools to be leveraged.  In fact, in most BPM projects I’ve seen, they are.  But they’re complimented with what the industry calls a BPMS, that better addresses the four points I listed above (although I’m sure someone could come up with other points, maybe even better points).

I didn’t actually see twelve steps in this post, but I really like the framing of the discussion.  And most of it I agree with:

Don’t try to structure every process. Most of the world’s business processes are currently unstructured and executed using email and documents. Many of these just can’t be structured. Even though more and more processes will get structured over time, an even greater number of unstructured processes will be continue to be created.

I always take issue with words like “can’t” – I would say many of these processes “should not be” structured.  Often the issue isn’t what can or cannot be done, but what is the right or best answer.

The other bit I would modify slightly:

Help spread the word in the process community. There are structured processes – which is where BPMS excel. Unstructured, unpredictable human processes – they exist, and aren’t just “processes that haven’t yet been structured” – that is where ACM can help.

I agree, except that I’d say “ACM techniques” because you may already have the software tools you need.  If you’re doing BPM, and you aren’t applying the concepts that ACM proponents espouse as well, you should be.  But don’t fool yourself into thinking these approaches are mutually exclusive, rather than mutually beneficial.

Jacob Ukelson posed this question the other day:

So where does all this leave us? I think that in 2011 we’ll start seeing business user backlash to BPMS – they will want more participant control over process, faster start up time, better end-user usability.  That will lead them to ACM (or to continue using email+excel).  It also probably means that the BPMS growth rate will slow.

Having been in BPM, and remembering how many times a break-out year was predicted… I prefer not to make these kinds of predictions.  BPM has been a steady grower, however, which may actually be more appropriate for enterprise technology- giving technology time to catch up to some of the hype (although, admittedly, the hype always seems to lead!).

Regarding BPMS growth rate slowing – I don’t think any slowing of growth rate will be caused by ACM, nor by a “backlash” as Jacob calls it.

I see the trends Jacob is pointing too, but these are trends that play out over many years or even decades, not 12-18 months.  I often agree with Jacob – and 2011 may well be a “break-out” year for ACM – but I disagree with some of the arguments he proposes to make his case:

“1. BPMN is becoming more complex because it is primarily a tool for IT professionals.”

BPMN is not becoming more complex.  The standard (BPMN2.0) is out. BPMN is unlikely to now change for some time.  Whether BPMN is primarily a tool for IT professionals or not, this hasn’t suddenly changed.  If ACM is successful, it will not be because of BPMN.  It will be because of ACM’s unique, value adding, capabilities.  If those capabilities are subsumed by existing software packages that have market presence, then it will be difficult to determine what is ACM separate from what is BPM.

“2. IT departments like the centralized control most BPMS give them.”  Actually, many IT departments push back against BPM, and against the methods that make BPM most likely to succeed.  In many cases it requires cultural change in IT departments to be successful.  This accounts for some of the slow-and-steady growth I referred to (not that 20% CAGR is bad).  On the other hand, in many cases the business is championing BPM – somehow I can’t accept that this is a bad thing.  Naturally IT can feel threatened in some cases when business takes the lead with respect to software, but it isn’t always that way.

“Paraphrasing Phil Gilbert – it enables 1 Java programmer to control the productivity of 250 business users, and makes those business users completely dependent on IT.”  I don’t agree with this paraphrasing.  Phil Gilbert was, if I read correctly, arguing that Java programmers are highly leveraged, not highly controlling.  The implication of intent to control isn’t really accurate or appropriate.  It is simply an implication, on Phil’s part, of a limitation to agility because this 1 Java programmer is overloaded.

“This is reminiscent of the mainframe era in the 60, 70, and 80’s – which generated the client-server backlash of the 80’s, 90’s, and 00s.”  I normally think of backlashes as things that happen faster than over 3 decades.  Also, I recall IT departments being pretty high on client-server and MS Office roll-outs… and *not* fighting them.

“4. IT, the CIO and most vendors hated that trend and tried to fight it. The more they fought it, the more people found ways to get around IT and use the systems that gave them back control.”   I don’t remember this at all.  We had different experiences with this (and, admittedly, both experiences probably happened, depending on which companies you were working with at the time).

Having said that, I think that products that address the “other 75%” of process work will find an audience.  I just don’t think that they’re competitive with BPM products – in fact, they’re highly complementary.  Just as email and Excel spreadsheets aren’t competitive with BPM…

Jacob Ukelson has run a blog post espousing BPM for “business process management” and ACM for “best practice management” (reporting from the BPM2010 conference):

One participant (I didn’t get his name) summarized the conversation by the intriguing statement”So BPM is for processes, ACM is for best practices” – from earlier comments he made it was clear he was a management consultant.

I think his statement is a good way of looking at ACM – especially if you come from a management consulting background. According to wikipedia “A best practice is a technique, method, process, activity, incentive, or reward which conventional wisdom regards as more effective at delivering a particular outcome than any other technique, method, process, etc. when applied to a particular condition or circumstance.” also “A given best practice is only applicable to particular condition or circumstance and may have to be modified or adapted for similar circumstances. In addition, a “best” practice can evolve to become better as improvements are discovered”.

Now, referring back to a previous post on this blog, it is no wonder that Jacob and I agree so often:

… If BPM is focused on optimizing the aggregate of many process instances, Case Management is focused on optimizing the outcome of an individual run of a process by providing better information and tools to the case worker.  To take the medical example – case management would philosophically try to help improve the outcome for a single patient.  BPM would philosophically try to improve the overall outcome of health care provided by the facility across all patients.

(Note, I used the word process but could have just as easily substituted the word “case” or “issue” or “patient”).

So, I once again find myself in violent agreement with Mr. Ukelson.

As with several previous posts from Mr. Ukelson, I really like this one, about Process Simplicity.  Simplifying and Simplicity have been themes of late- because what software needs, and specifically what BPM needs – is deeper thinking into how it is surfaced to those of us who use it.

I also like how Mr. Ukelson focuses on what his product can do for the business, and not about whether it is BPM or ACM or something else.  He offers a definition of BPM as the “discipline of making work processes simpler”, which leads to interesting conclusions and points of comparison.

I agree with the philosophy of making work processes simpler, though you could say “making work simpler” because not every participant of a process will perceive it to be a process – to that person it may look like a single action or reaction, or a case.

Finally Law 10 – This is an interesting law from a BPM perspective – isn’t BPM about exposing and codifying the routine (which is version of the obvious)? So maybe BPM’s job is to lay the groundwork so we can get to Law 10 in business processes, and something else will need to come along enabling the next step towards Law 10.

(law 10 was “Simplicity is about subtracting the obvious, and adding the meaningful.”)

I think Mr. Ukelson may be on to something.  And I think his characterization of the BPM/ACM debate is one of the better “framings” of the discussion that I’ve seen.  Not that that won’t stop anyone from disagreeing with me… please comment!

Recently at IBM Impact I said that “process data wants to be free” – available in more places, more accessible to users and managers, and more sensible in form and structure.

Jacob Ukelson makes the case (paraphrasing) that process just wants to be free:

From my perspective the simplest answer is that we focus on unstructured, unpredictable, ad-hoc human processes that knowledge workers do, while BPM suites focus on structured, predictable processes – and the two approaches are complementary.

In other words, make it easier for the everyman/everywoman to execute their processes.  He focuses on three key themes that differentiate ActionBase from other approaches to knowledge work:

1. Familiarity – ActionBase leverages email and documents in a way that is immediately famliar, rather than asking users to learn a new tool or URL.

2. Collaboration – This is as much a benefit of leveraging email as anything, but the point is that users can dynamically bring others into a process to help, at runtime.

3. Managed – applying “enough structure to make the process manageable, but not so much as to strangle it.” And so the focus is on visibility rather than constraining or controlling the flow.

These are good tenets for anyone to build software around.  Philosophically, I think ActionBase has it about right.