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.

An article in the Austin-American Statesman, not long ago, posited that there was, in 2010, a dearth of ‘camps, after a flurry of them in 2008 and 2009.  However, a quick followup was penned by Omar Gallaga, about the fact that ProductCamp was still going strong.  Mostly, Camps are free events sponsored in someone’s corporate offices or in a bar (thus the early “barCamp” labeling), and generally only target local attendees.  But these events are hard work to put on:

Paul Young, who founded ProductCamp Austin, said many events modeled after the same concept simply petered out for lack of interest or organization. “They show up, run their cycles, then die out,” Young said. “I think the reason that happens is that people are surprised for an ‘unconference’ how much coordination it actually takes to put an event on.

I think people are also surprised how difficult it is to pull off a free event!

We’re proud to be having bpmCamp in Austin as well. While we couldn’t pull it off as a free event, we are keeping it as affordable as possible, while still making the event attractive enough for people to travel to Austin to attend.  We also freely admit that we need to produce some of the content up front for similar reasons, rather than doing it all on the fly – but we’ll also keep time (and rooms) available for impromptu sessions that weren’t thought of ahead of time.

If you are interested, the registration page is right here. You just need to be a Lombardi BPM practitioner to attend.

Jim Sinur has thrown in the towel on BPMN in his latest post:

BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark.

BPMN really stands for “Business People May Not…understand”

IT professionals can’t really expect business folks to understand cryptic/standard formats when they really want to see a real representation of their processes with desirable icons; not engineering Icons. It’s kind of like someone saying “let them eat cake”. It is this IT arrogance that could sink BPM technologies.

Respectfully, I think Jim is letting the business off the hook.   No need to learn any new skills over there on the business side, just draw something on a napkin and hope it turns into a process.  Just make up any old iconography you want, no problem if no one other than you can understand it (you know, the value of standards is that more than one person or team can understand what is produced).  Don’t bother to learn something that is about 10% harder than standard flowcharting (Bruce Silver has helpfully identified a subset of BPMN that is more appropriate for new-to-BPMN business users).

At a time when we’re asking IT to learn new skills and to be more business oriented, is it too much to ask Business to learn new skills to support process improvement?  This isn’t unique to BPM – if the business is going to support ACM, they’re going to have to learn new tools for that as well.  If the full BPMN icon set is too much for someone, use the subset that you understand and like to document your ideas, and make use of annotation.  If someone shows you a diagram with more icons in it that you don’t follow, it should be straight forward to get an explanation or to look up the new notations you aren’t familiar with.  While Jim may not be a fan of standardization of notation – business folks are plenty used to standards of notation (not just in BPMN).  I use BPMN basic diagramming shapes to whiteboard processes for businesses all the time (literally on the whiteboard or in collaborative tools) – and they don’t have any trouble following what’s going on.

The problem isn’t that BPMN, as a notation, is too hard. It is that too many people think that BPM starts and stops with BPMN!  There is so much more to managing business processes, and improving them, than BPMN.  By way of comparison, think about search.  Search is a highly technical subject with a very rigorous syntax.  But nearly everyone can take advantage of its more simplistic forms – just typing in a few keywords into a Google search field.  It doesn’t mean that they can’t understand a more complex query string when they see it, nor guess at the meaning of a phrase surrounded by quotes… nor understand the resulting page of search results (the outcome). In fact, if they find their need for search becoming more complex, they can actually endeavor to learn the more advanced forms (domain filtering, exclusion, wildcards, etc).

So let’s all agree that there is much that must be done in the world of BPM to address businesses better, but tossing out BPMN and letting business off the hook is hardly the solution.  One need look no further than a tool like IBM’s BPM Blueprint to see that you can ease the business into BPMN style notation by first having them engage in process mapping or value stream mapping.  You don’t have to throw out BPMN to do this.  At the first company I worked for, we used to like to quote a line from a business book: “Genius of the ‘And’” – as in, why can’t I have both a simpler mapping notation, and a more detailed process execution notation that make sense together – instead of only one or the other?

It is time for everyone to step up to the plate in BPM, not just the software vendors.  BPMN is part of the answer, but only part.

Ann All poses the question: “Is CIO the Right Person to Champion Process Improvement?” on the ITBusinessEdge Blog:

I’ve written about this idea several times. It’s hard to argue against the need for a chief process officer. Yetmany organizations do not designate a specific function for process improvement. What’s less clear is who is best positioned to fill this role. Vizard writes it “may be the chief operating officer or even the CIO.”

I think a good case can be made for the CIO. Because IT touches the entire business, the CIO has a high-level, cross-functional view of the organization shared by few other executives. IT also tends to have more hands-on experience modeling and mapping processes than other areas of the business. CIOs clearly recognize the need for process improvement. They named business process improvement their top priority for 2010 in Gartner’s annual survey.

Honestly, I’ll take anyone at the C-level or just below who is passionate about process improvement and empowered to make a difference.  Having *someone* take the lead is better than no one at all.  And in some organizations, which are heavy on IT to support the business, the CIO may be particularly well positioned (as his or her staff may know many of the business processes as well or better than the business folks who use the software, because the processes are already “encoded” in legacy systems).

However, Ann goes further in her post:

Samir Gulati, vice president of marketing for business process management software provider Appian, is another believer that a CIO or other senior IT executive is the right person to champion BPM throughout an organization. Business leaders tend to focus narrowly on the needs of their own divisions and opt for point solutions, he said when I interviewed him recently.

A lot of software companies prefer for BPM to be led by IT.  Why? Because when it is led by IT they can go for the strategic sale:  buy this software and you can apply it to all of your processes that come up!  Many IT organizations look at this a bit like setting up a utility:  we’re providing “electricity” (BPM), so that the business can turn on the lights, computers, etc (improve process). Its a comfortable relationship for software folks to build with IT organizations.  Speeds and Feeds, features, bells and whistles.  Comfortably avoiding too much discussion of business-oriented ROI.  Proving that the current topic is an emerging meme, Mark McDonald of Forrester has written about this subject as well, advocated for an expanded role for the CIO:

Well because no other executive is responsible for the long term operating model and no other executive has the resources that determine company productivity in the long run.  IT is now a significant source of leverage across the enterprise as information spans operational groups and fuels processes, communications connects people and processes and technology offers new service channels and methods. and throng time.

But this doesn’t mean that the CIO is the ideal candidate in most organizations to lead process improvements.  First of all, the most important criteria are not which three letters make up the title.  The most important criteria are specific to the person:  passion, empowerment, and capability.  Put another way, the most important criteria is leadership, and these three elements tie into the ability to lead an organizational change.

I believe a broader study of BPM would support the empirical data that we have at BP3 that organizations that lead BPM initiatives from the business generally yield higher ROI, tackle more processes, and roll them out more quickly.  Perhaps the secret sauce is that the projects are initiated out of such a close relationship to a business need, combined with accountability to that same business organization.

Having said that, we will take leadership on process over none at all any day.  And if the right person happens to be the CIO, COO, CMO, President, CEO, VP of Sales – it matters not as long as they have the passion, empowerment, and capability.

Update: Even before publishing this, Ann has added to her own thoughts on her original piece:

Of course not just any CIO can lead a BPM effort. It would have to be a CIO who is well-versed in the overall business, not one suffering from technology tunnel vision. In addition, he or she will need great communications and change management skills, since introducing BPM requires folks to make fundamental changes to the ways they work. A CIO without those skills shouldn’t be the go-to person on BPM. But guess what? A CFO or COO lacking those skills probably won’t fare any better.

Like most questions, I think there might be no one right answer to who should lead a BPM effort. lt will vary from organization to organization, depending on the skill sets of their executives.

This sounds much more in alignment with our own thinking at BP3.

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?

We now have our venue chosen for bpmCamp 2010 @ Austin, October 14-15, 2010.  We’ll be at III Forks Austin, right in the heart of downtown, next to City Hall and the Lake.  III Forks is one of Austin’s best steakhouses, but it also has a great interior space for meetings of our size, and they have agreed to open their doors during the day (when they are normally closed for business), to host bpmCamp!

I want to thank III Forks Austin for allowing us to u

se their space.  We’re looking forward to some fantastic food and snacks during the day.  Moreover, thanks to Red Velvet Events for helping connect us with III Forks along with other finalist locations.

We’ll have more announcements on this space, regarding bpmCamp, as we get the wiki, mailing list, and other travel logistics sorted out.  Please let us know if you have any questions – either in the comments here, or on our various email addresses.

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

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

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

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

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

The Process Cafe posits that Humans are your Process’ Greatest Failure Point:

Humans are your most crucial failure point in a process. When ever you are designing processes (or systems to support processes) you should ensure you try and minimise the ability of the human to cause a failure. Google Mail now, for example, can scan your email and look for the words such as ‘attached’ which might indicate that an attachment is expected. If you send the mail without an attachment it will warn you. But how many other email systems have that functionality?

Of course, it is process-improvement 101 that anywhere a human touches a process you expect to find various failure modes there.  Even the process of finding process failures can be error prone because it is performed by humans.  Often these failures are couched as “measurement error” (a  euphemism for human error or variation in that case).

But I prefer to take a more positive view of the human condition.  The humans in your process are your greatest opportunity for improving your business:

• By personalizing service for your customers
• By creating a personal relationship with your customers
• By leveraging their experience to make difficult decisions that can’t be trusted to algorithms alone
• By identifying opportunities to make their own work more effective, as well as that of those they work with (improving the process)
• By identifying new sales opportunities via direct communication with customers

And the list goes on and on.  Your humans are the critical element in your processes.  They’re your differentiating advantage.  So by all means, give them all the automated assistance you can.  Tee up all the information they need.  Double check their work and make sure it appears to be consistent in action and word.  But this is, to me, a bit like applying 5s to office work.   Sure, the knowledge worker doesn’t have to have their desk identical to their neighbors’.  Because they’ll have the same desk tomorrow.  But we can “clean up” the spaces around their process interaction, so that they’re more consistent, more useful, and more pleasant to work with.

I think BPM and process improvement proponents need to take a more positive view of human involvement in their processes.  It isn’t all about raw efficiency or cold accuracy.  Borrowing from a recent “Process Ninja” post:

So when thinking about automating processes, think about the number of moments of truth that are occurring in the process, and look to eliminate or improve them. Process is not just about time and cost, it is fundamentally about the customer experience.

True words…

Mike Gammage posts the question:  is BPM ethical?

Against this background, the hard reality is that the business case for any significant BPM project is almost invariably based on job losses.

The jobs may be lost through automation, or through productivity increases.  The BPM project will typically enable the same work to be done by fewer people.  More positively, the BPM project may enable the same people to do more work – that is, there are no jobs lost immediately.  But, even so, the societal effect is not dissimilar because economic growth will now create fewer jobs.

Put crudely, and for the sake of this argument, BPM seems to be a job-killer.

Now I believe, as will many of you, that work is about far more than simply generating wealth and meeting basic needs. Work provides each of us with a role in the community, it enables us to develop our talents in service to others, and to contribute to the advancement of society.

So it’s a serious question that deserves attention: Is BPM – my work– ethical?

I commend Mike for undertaking a post on this subject.  I have a few thoughts for him to consider when he returns:

1: Competition is the Job Killer.

The first thing to realize, is that BPM isn’t the job killer.  The job killer is the competition for your customers. If you can’t win that competition for customers, you will have a massive dislocation of jobs.  That competition is faceless and unrelenting, unfortunately.  You don’t get to look into the whites of your competition’s eyes and try to agree on a reasonable pricing model – if you do in the US, it is called collusion or anti-competitive behavior (there are similar rules in other locales).

So you have to invest in improving the cost structure and performance of your business, in order to remain competitive.  BPM is a tool to do that.  Just like Microsoft Word and computers put a generation of typists/secretaries out of work, BPM and other software will put a generation of manual paper-movers out of work (or copier repairmen perhaps?).

2. BPM can Save the Jobs of the People you know

A Good BPM implementation can save the jobs of the best people in your company.  By making each unit of work more valuable, it is easier to justify paying them, even increasing their pay.  You’re increasing their economic value add to the system.

Moreover, if the people doing the work become the people improving the work, they can really maximize their positive effect on the business. It also frees up labor to focus on other value-adding areas of the economy (though, I’ll grant, that is an easier macro- than micro- argument – individually not everyone can make the shift, and not everyone has the savings to bridge the gap – which is why I’m a big fan of unemployment benefits and insurance).

Finally, if you can sell the value of these process improvements to your customers, you can actually use process improvement as a way to increase your top line, not just your bottom line.

3. Manage for More than one Bottom Line

BPM and the like can help you achieve more than just cost savings – BPM can help you more reliably achieve any outcome you set out to achieve – higher customer sat, a higher net promoter score (NPS), reducing impact on the environment, increasing customer lifetime value, etc. This is sometimes called the “Double Bottom Line” or “Triple Bottom Line”.  But realizing that your business is about more than just money, why shouldn’t you use process improvement to increase your odds of hitting ALL your business goals rather than just some of them?

Although BPM causes us to examine what we do, and second-guess the positive outcome, I believe overall it is not only ethical but necessary.

A colleague of mine pointed me to an interesting McKinsey Quarterly article, which relates the tale of a service automation effort gone awry.  As I started to read it, I was sure that the author would take the tactic of implying workflow and automation were a waste of money.  Surprisingly, the article takes a turn midway through to show how, in this case, the company turned around their project by getting back to basics:

1. Don’t allow limitations of paper- and manual-based processes to continue into an automated world
2. Test drive process changes before cementing them in software.
3. Field test for important success factors
4. Build a minimalistic solution
5. Work on changing culture at the same time that you work on the Information Technology.

These are good tenets for any BPM project to incorporate – but Items 1, 2, 4, and 5 run against the grain for many organizations.  If the project team “goes with the flow”, they’re likely not to challenge assumptions in these four key tenets, and failure for the whole project is a likely result.

I know Kevin’s article was targeted at web analytics, rather than, more generally, business analytics – but the points he makes are entirely valid for business analytics – and business process analytics:

We analyzed each promotion code, using “A/B” test panels. Customers were randomly selected from the population, and then assigned to one of two test panels. The first test panel received the promotion, the second test panel did not receive the promotion. [...]

In almost all cases, the segment receiving the promotion generated more profit than the control segment. [...]

Being a huge fan of “A/B” testing, I decided to try something different. I asked my circulation team to choose two customer groups at random from our housefile. One group would receive promotions for the next six months, if the customer was eligible to receive the promotion. The other group would not receive a single promotion for the next six months. At the end of the six month test period, we would determine which strategy yielded the most profit.

At the end of six months, we observed a surprising outcome. The test group that received no promotions spent the exact same amount of money that the group receiving all promotions spent. After calculating the profitability of each test group, it was obvious that Eddie Bauer was making a significant mistake. [...]

In 1999, we backed off of almost all of our housefile promotions. At the end of 1999, the website/catalog division enjoyed the most profitable year in the history of the business.

This is a classic cautionary tale for anyone measuring business processes and looking for improvements.  In process improvement, often an efficiency gain comes at the cost of customer satisfaction – which is why many businesses now manage to a “double bottom line” or use extremely customer-focused culture to counter-act that tendency.  In the case above, they’re looking at how incentives shape behavior. The thought process is equally valid for customers as it is for internal staff incentives. Do the incentives actually drive better behavior or just more short-term-optimized behavior?

Kevin goes on to recommend several remedies, most of which revolve around having a longer term view of things.  Well. Imagine that.  Good read.

We had a great success with the original bpmCamp @ Stanford in January, this year.  We’re now ready to start the ball rolling for a bpmCamp in Austin.  We’re just at the formative stages, but we are targeting dates in October, and currently scouting locations in Austin.  We’ve also had tentative discussions with Stanford about having another bpmCamp at Stanford, but a bit later in the year 2011 (maybe even in the summer of 2011). Our goals and thought process are much the same as last time:

1. BPM Conferences are good, but BPM Conferences are (usually) too general, too big, too expensive, and stuck on platitudes because of the above.
2. bpmCamp is intimate. It was 40 people (max capacity) at Stanford.  We’ll figure out our max capacity for Austin, it might be just a tad bigger.
3. bpmCamp is specific.  We will be focused on the Lombardi Software products acquired by IBM earlier this year, and now known as IBM BPM Blueprint (aka Blueprint), and Websphere Lombardi Edition (aka Lombardi Edition aka Teamworks).  (We would welcome the chance to organize a bpmCamp for another product offering – but we need a partner to help)
4. bpmCamp is affordable.  Exact price is TBD, but it won’t break your budget.
5. bpmCamp is focused on what attendees care about.  Topics are crowd-sourced, so anyone attending can help shape the agenda.

If you’re interested in attending, watch this space, or keep an eye on posts with the tag bpmCamp. If you’re interested in sponsoring bpmCamp, we’ll have more details about that soon.

If you have any questions in the meantime, contact us at:
bpmCamp Email:

(editor’s note: bpmCamp is not affiliated with or sponsored by IBM.  bp3 is not acting on IBM’s behalf, nor is bp3 an affiliate nor subsidiary of IBM. )

IBM’s BPM Blueprint folks recently posted a short video that shows how to create a “join” in a process.  Its a painless video to watch because it is in double-time, but it definitely exposes an opportunity for improvement in how one goes about modeling joins.

It relates to our previous post on process patterns. This video simply shows how to leverage a basic BPMN construct (the join) in a specific collaboration and modeling tool (blueprint). But this is also one of the van der Aalst “patterns”, that, as I mentioned previously, I’d rather call construct than pattern. And I think everyone would benefit if we start to discuss patterns with more useful abstractions embedded.

Dr. Stein of Aris has a blog about workflow patterns in BPMN2:

“In many areas, patterns are used to codify best practices. A pattern describes a solution for a problem. Originally, patterns were used in architecture to describe architectural design ideas. In software engineering, patterns are used to describe typical software design solutions, for example like client-server architecture.

In business process management, the so called workflow patterns by Prof. van der Aalst and friends exist. In their original description, they described the most important 20 workflow constructs like loops, decisions, and sequence flows. Later, Prof. van der Aalst and other research fellows extended the list of patterns and revised the initial description (see workflow pattern homepage). Still, the original 20 workflow patterns are valid and a useful tool to learn a modelling language such as BPMN.”

I’m just not excited about the van der Aalst “patterns” that are oft-quoted in BPM circles. The more accurate statement is that they are snippets of BPMN that demonstrate how various “constructs” work.  They’re useful demonstrations of how BPMN can work, and how to use a particular tool to diagram specific constructs.  And the work of van der Aalst and colleagues was very useful as well in identifying edge case diagrams that expose tricky aspects of the notation’s execution semantics.  They are not, truly, patterns as I would think of them.  Showing three activities executing in a sequence is hardly a “pattern” any more than three lines of code that execute in a row are a pattern.  Splits and joins are just constructs of the notation. The patterns don’t identify the usefulness of the pattern or the “why you would want to do this” aspect.  In that sense, they largely fall short of the bar for a pattern in my book.  A typical name for a “pattern” in this study : “Multiple Instances without Synchronization”… huh?  A name only a parent could love.  What’s the business case for this that helps me understand how it relates to business process? There isn’t one.  The point of these patterns, documented here, is to identify technical edge cases and compliance, not to create patterns that you will base your actual design work off of … and maybe that’s my main complaint.

The “four eyes” pattern is a pattern (where n-1 potential reviewers have to approve something before it moves on).  There are lots of real patterns out there – and generally they’ll get names that make sense- an “observer” pattern, the “shadow process” pattern, etc.  Having voiced my complaint, maybe I need to take some time to document a few BPMN2 style patterns to clarify.  Anatoly Belychook has described a few on his blog, in the past (as well as anti-patterns).

Ben Farrell of Appian notes on their blog recently:

Dealing with varying levels of security requirements in ramping up new federal employees and contractors is a common pain. It is usually handled through manual, paper-based processes involving lots of documentation to be passed around, verified and tracked across multiple systems. This means major time and effort for the staff performing the processing, and delays in getting new hires into a productive work mode.

Other process areas common across government organizations include things like Procurement and Sourcing, Program Planning, Budgeting and Management, Grants Management, and a variety of HR processes. Not coincidentally, these are areas where Appian is seeing great success.

BPM software helps the federal government solve pervasive cost and productivity problems – and not in the “tried-and-failed” approach of commercial off-the-shelf software packages that cause as many headaches as they solve thanks to rigid coding. While attacking an area of common concern, BPM solutions are easily configurable – by business users – to the unique requirements of an individual agency.

I’m not an expert on which BPM vendors have market share in the Government space (it is hard to measure this kind of “market share”), but being based in or near DC doesn’t hurt Appian’s chances.  And as probably every BPM practitioner has noted, BPM is what the government needs – processes that don’t get lost in the paper stack on someone’s desk, processes that proactively notify participants about progress within the process, and processes that have consistent performance.  Ask anyone who has gone through the green card application process and you will get a story of broken processes – or at the very least, broken visibility (the applicants rarely have any sense how far along they are in the process).

One interesting note from Ben’s post on cloud computing:

There will be more to come on government adoption of BPM in the Cloud. For now, I’ll close with a reminder about why BPM in the government really matters: every one of us, as taxpayers and consumers of government services, benefits when government operations are conducted more efficiently and effectively.

Government adoption of cloud computing is interesting.  I think most people assume that most government functions won’t be in the cloud – but clearly some could be.

BPM Guide has some examples of BPMN 2.0 diagrams, on the heels of Stephen White’s blog post that the BPMN 2.0 spec has been ratified by OMG.  Thanks to Jakob Freund for publishing them.There are a couple of key points that Jakob makes throughout the article, that I’d like to call attention to:

Creating process models for both business AND it is actually one of the absolutely main topics of our consulting business. And it is a very big struggle, of course. For us it was important to show in the document that BPMN is not necessarily “too complicated for business”, because it totally depends on how you actually use the standard when process modeling. That’s why we always need a Framework around BPMN if we want to apply it in bigger modeling engagements.

This is a well-said point – BPMN doesn’t have to be too complicated for the business. But drawing diagrams that are not more complicated than they have to be takes some skill and practice.  I often tell people who aren’t familiar with BPM that it takes a reasonable degree of abstract thinking to really do well.  It is the abstractions and generalizations afforded by a process and its subprocesses that comprise the solution.

Apparently they built these examples with Trisotech’s tools:

The diagrams in the examples document however are all made with Trisotech’s Visio-based BPMN Modeler, provided for this purpose by Denis Gagné. The cool thing is that we could directly serialize the diagrams into BPMN 2.0 XML with that tool.

Denis, where is this tool! Sounds interesting!

Jakob also gives interesting examples of how to take advantage of collaboration diagrams.  His final thoughts:

Make a “strategic” process diagram (Figure 6.1), just a simple sketch for a quick understanding

Make an “operational” process diagram (Figure 6.2) for analyzing the collaborational aspects

Enrich the diagram with the aspects of a process engine, therefore adding a pool for the process engine

Take that process engine pool into your technical environment and enrich it for execution (make a “technical” process diagram).

Good advice for how to approach modeling in BPMN.

In a previous post, I argued that (contrary to Alain Breillatt’s expert perspective) Apple’s approach to product actually saves money rather than “wastes” money.  What most people would look at as waste, I would look at as costly-wrong-turn-avoided.  If you understand the arguments behind technical debt or process debt, the idea that a bad design (or more than the minimum necessary number of designs) is expensive makes perfect sense.  This argument was an exercise in looking at the R&D process around one future product – the 10:3:1 ratio of product design weed-outs, for example.  In another post, we looked at the big picture R&D spending versus revenue and profit growth – and in this wide angle lens, it is hard to argue with the idea that Apple’s R&D is quite efficient.

Recent events and a few good blog posts bring some additional data and perspective to bear on this.  First, we have the Tyner Blaine post, The High Costs of Building the Wrong Product, which is a fantastic explanation of the concepts discussed between myself and Alain Breillatt.  As Scott Sehlhorst writes for Tyner Blaine:

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality.  This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.”  The primary conclusion of that research is that ten dollars spent on fixing bugs:

• Costs and saves $10 when you catch (and fix) the bug during implementation.
• Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
• Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process.  Of course, be pragmatic about it – if the cost of testing exceeds the cost of bugs, don’t test.

We just recently witnessed the cost of a “bug” in the final version of a very popular product.  Apple has taken it on the chin in PR because of this.  Imagine the launch coverage absent this issue – the press and blog coverage would have found something to complain about, but this issue was almost too easy for them to focus on.

Now, imagine that Apple had developed, say, one of the many bad Android phones.  There are Android phones that review well.  But had Apple wasted the resources to build one of the ones that wasn’t good – that is quite a cost, isn’t it?  To reputation for one.  But there are marketing costs, support costs, potentially recall costs (analysts were estimating north of $1B in recall costs to Apple if it came to that). The Droid X is already getting criticism for its bad User Interface (allegedly, worse than the default Android 2.1 interface – though I don’t claim to be an expert on that).  What is the cost to Moto’s business to develop “a bad product” or, a product with a few really bad bugs?  People often compare Apple to “Android” – but actually each Android handset maker is a separate competitor.  Each one has to invest significant energy into developing their handsets.  As long as Apple has significant volume advantages over any single competitor, they should enjoy economies of scale that the other manufacturers don’t.

TechCrunch has an excellent article detailing Apple’s surprising vertical integration benefit. I say surprising, because in economics we’re generally taught that vertical integration is less efficient than specialization.  Apple seems to buck that trend.  Steve Cheney writes:

Perhaps the best example of this so far is FaceTime, Apple’s take on video-calling. FaceTime makes video-calling on the Android-based Sprint HTC EVO look silly, because the EVO awkwardly requires users to sign up and download a third-party app, then launch it every time they want to talk. Normal people simply won’t do this.

Apple eliminated this friction by innovating at the confluence of hardware and software—hit one button mid-call and the feature just works. It really is amazing (yes, I am channeling Steve Jobs).

Once Apple does release a product, they really know how to market it.  In this FaceTime ad compaign, they do a great job of not marketing technical specs and instead marketing human value.  This is what makes the difference between evangelizing your product and just geeking out.  Not every body likes it – but think back to when the iPod commercials were ubiquitous.  They didn’t market the # of songs so much, nor the quality of the build (though it was high), nor the RAM, nor the CPU speed.  They marketed people dancing in their heads while going about their every day life (the shadows are dancing while the person calmly walks to the subway).  Sell the benefit, sell the humanity.

Back to the TechCrunch article… the author argues that Apple actually benefits from feature bloat in component vendors.  For one, they get to strip out unnecessary features from their designs (which aids battery life, for example).  For another, Apple gets an inside track view of what is coming down the pipeline in these components that their competitors depend upon.  And then Apple has degrees of freedom to decide how to respond.

Good food for thought for anyone running a product business.

Chris Adams, VP of Product and Technology at Ultimus:

Despite all of the recent recognition of processes being dynamic in the Business Process Management (BPM) / Adaptive Case Management (ACM) spaces, the majority of processes in business have ALWAYS been unstructured.  [...]

Thinking back to the inception of automated processes, the reason why workflow technology came first, arguably, is that it is “low hanging fruit”.  Like with any large project across the enterprise, the concept of starting small and growing from initial successes is a well understood strategy to achieve large scale success.

Chris depicts workflow as the lowest hanging fruit, structured processes as the middle fruit, and unstructured as the highest fruit to attain.

From reading his post, it sounds as if he’s saying that unstructured is harder, technically, to implement than workflow or structured processes.  However, unstructured is actually easier, technically speaking.  Businesses have been performing their unstructured processes for years – using email, for example.  Or Lotus Notes applications.  Or SharePoint.  We can argue whether any  of these were good solutions – but my point is just that even the ways in which these products fall short are not hard technical issues to resolve (if only the folks who write email software and the like actually cared about processes as a target).

Unstructured processes are “not low hanging fruit” due to organizational barriers, not technical barriers.  Processes that cross organizational boundaries run into resistance.  There will be users who worry that software will over-constrain their free-wheeling unstructured process – like the Borg assimilation routine. No one wants to feel like a Borg automaton.  But there are times when process *should* cross organizational boundaries – whether structured or unstructured.

Mike Gammage points out that a recent Gartner report touts BPA for the masses, but fails to understand how absurd that sounds:

Within this context, how can BPA possibly be an activity for the masses? This kind of analysis is understood and undertaken by a small group of IT specialists.

Each kitchen has only a small cadre of pastry chefs. Diners, waiters, the maitre d’ – they may all be involved in continuously improving the mille feuille aux amandes – but it’s the pastry chefs alone who sift the flour and need the rolling pin.

I think Gartner may have, in this instance, gotten tools and work confused.  Some of the tools they are reviewing (BPM Blueprint, and ARISalign) are designed for the masses – but not to turn the masses into BPAs.  The goal is to turn the masses of business users into real participants in continuous process improvement.  Of course, they have features to support BPA activities – but those particular features are primarily intended to support the analysts, not the “masses”.

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.