Paul Vincent on BPMN 2 events (all 63 types of them) :

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate
• … across 8 situations classified by location in a process:
• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving58 63 event types defined [*1].Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

Paul is right: 63 is too many. But I think he also hints at the right answer: the tooling should be able to pick the right symbol based on the context of the detail of the event (or conversely, show the author the right context if they pick a specific event).  But there’s no reason for anyone to know 63 event types off the top of their head.  In fact, they really don’t need to distinguish between all of the 13 “main” event types in most cases.

It is up to the BPMS providers to make the authoring experience powerful and yet simple enough to be manageable and useful.  If the notation has gotten away from us a bit, then software can help reduce it back down to something manageable.  One interesting aspect is that many of these event types are not currently supported by BPMS vendors-  so depending on which tool you’re using you can cross off a lot of the potential event types!  That isn’t exactly what I mean by “simplifying” but it is one way to get there, I suppose.

Back in college I was fortunate enough to sign up for CS 193e (or was it d?).  My friends sometimes joked that I majored in CS193 because I took just about the whole series a, b, c, d, e, u, x, etc.  The class was focused on learning to program in the NeXTSTEP environment – NeXT was Jobs’ workstation company, and they had produced really interesting development tools – the Interface Builder and the App kit.  In my C++ class we took ages to write things like Chunk Lists and other general-purpose data structures.  In our 193 class, we built a calculator application (UI and all) in the first week’s assignment.  I was hooked.

The underlying programming language was objective-C, which I found to be a slim and elegant cousin to C++.  It was much more productive to write user interfaces in objective-C with NeXTSTEP than any other platform I had used (and more productive than the Visual Basic platform I was going to learn once I left college). Objective-C had some amazingly useful features, like protocols (a precursor to interfaces in Java), and category extensions (adding methods to an existing class, without modifying the original source of the class- think of it as subclassing without a subclass).

Following that class, and another on programming Motif interfaces in Unix (wow, that was a real shift from NeXTSTEP), I landed a summer internship at the Stanford Linear Accelerator.  You know, the place where they smash atoms together and measure the tiny high-energy particles that are produced as a result.  I had only a passing understanding of high energy physics, but I got the job because one of the researchers in the Theory group wanted to port their statistical drawing package, HippoDraw (written on NeXTSTEP) and Hippoplotamus (as I recall, a portable C package) to X-windows/Motif, so that more high energy researchers around the world could use it (only a small number of them had NeXT machines -and a large percentage of those were at SLAC itself).

We took an interesting approach to porting… thanks to an idea from a fellow Stanford student.  We used a category extension to overwrite the the write methods and save out our interface definitions in a format which we could read back in and from which we could inflate an X-windows/Motif application, even though the application was written and defined in NeXTSTEPs Appkit and Interface Builder.

Since we could write out all of the instance information we needed to reconstruct the UI, we had a simple task.  As I put it at the time “all we have to do is port the appkit classes to x-windows/Motif.” It was Paul’s idea, but only an undergrad CS student could think it would be so easy as that!  So instead of porting our application, we ported the middle layer of software that translated all our application commands into User Interface.  And of course we relied on the GNU project that allowed for compiling objective-C code.  And Paul Kunz, my mentor on the project, helped launch the GNUstep project and contributed our code to the effort.  (As a side note, Motif wasn’t open source so the whole display mechanism was eventually swapped out to get more purely open source).

So imagine my surprise when I saw Daring Fireball reference GNUstep. Apparently Sony’s new SNAP developer framework is based on GNUstep and Objective-C.   Far from being odd- I think its a good choice.  Objective-C is a better language than many non-Objective-C developers give it credit for.  And it has enabled a suite of very productive development tools from Apple/NeXT.  I’m not sure you could build tools that are as easy to use for a language that is more complex, like C++.

It is just fascinating to me how little pebbles rolling down hill can gather momentum over time and that the unintended or unexpected consequences can be far-reaching.

Late-breaking update:  AppleInsider reports that the project is now on hold.  Maybe they didn’t like the publicity around the GNUstep / Apple connection.  Or maybe it is unrelated.

As we do every year, we’d like to say thanks to our customers, our partners, and our blog readers.  And of course, thank you to our team members, and to their families who support them in doing this thing we call BPM.

Taking a step back from the day-to-day routine, when we look at the BPM space, it is even more interesting this year than it was last year.  The possibilities are more dynamic, and the value to be captured by customers more within reach.  At the same time, we’re starting to see real signs of economic recovery in the US (and in particular, in Austin and Texas).  Perhaps we’re a bit optimistic, but we see signs of progress on several fronts.

Sandy Kemsley recently blogged about a session led by Bank of America’s Peter Braun, at CASCON.  The juicy part of her coverage is:

They also have to deal with model governance to keep the WBM and IFW models in sync: each are used for different types of models at different points in the modeling lifecycle, and have specific strengths such that they want to continue using both tools. Because there are multiple non-integrated tools, they need to do model management to consider the interactions between model types, and there is a great deal of manual work to be done when a model is exported between the two environments. After the initial export/import, any changes in a model in one environment have to be manually made to match in the other modeling environment. They have issues with version management, since there is no proper repository being used for the models, and the modelers can end up overwriting each other’s efforts in a shared area on a server. They’ve also looked at ILOG, and have further issues with managing consistency between the rules designed in WBM – which map to the process server – and when those rules are rewritten in ILOG in order to externalize them.

Well.  If this isn’t an argument for a model-preserving strategy, I don’t know what is.  If you’re going to use different types of models, my advice would be to use them to model different types of things. For example, using an ERD to model a database schema makes perfect sense.  Using Value Stream mapping makes perfect sense.  But using two different process modeling notations only makes sense if you can keep one of them at a different “layer” than the other, or simply constrain by level of detail.

Even then, you have to worry about managing versions.  The paragraph above makes me think that seamlessly integrated version management of process artifacts is the way to move forward – because it provides a better user experience.  (If it is integrated version management and *doesn’t* provide a better experience then I wouldn’t recommend the tool).

I noticed a link to Sandy Kemsley’s Slideshare group for BPM, and thought I’d call it out in our blog for future reference (I believe it was a reference from Marco Brambilla that led me to this).

It appears to be an archive of slideshows contributed by any number of different authors and companies.  Quite a compendium actually (105 and counting).  Thanks, Sandy, for maintaining this archive for everyone!

Sandy attended a sneak peak of Blueworks Live recently, and has reported on it in her blog:

They are trying to reinvent the public BPM community, while avoiding the problems that they perceive with other vendors’ community sites:

• They are mainly product support sites
• They have high membership numbers, but low participation
• A majority of the information is from the sponsor company
• The customer perception is that these sites are proprietary and biased, and that there’s already too many sources of information on BPM

I think they have some of the right ideas here – they’ve identified legitimate problems with the current approaches of these communities – but there’s still some work to do on defining what a healthy BPM community consists of.  I think they have a couple elements right, such as:

1.  A common thread tying it all together: BPM / Process

2.  A “safe” place to share (company spaces, or even more granular spaces)

3.  Don’t try to reinvent twitter, just leverage it

But the mechanics will take some work.  As Sandy points out, pro-level users of Twitter aren’t going to rely on BlueWorks Live to show them interesting tweets.  Having said that, however, how many people are going to add a column for “#bwlive” to their TweetDeck?  So it may be somewhat additive to the experience, but time will tell. Sandy says “It’s probably good for the Twitter newbies, since they haven’t figured out groups, hashtags or Tweetdeck yet; maybe that’s more representative of the expected user base.”  I think that’s probably right – more representative of the expected user base.  Most of the personnel I work with don’t use Twitter at all yet.

Like Sandy, I think their blog section needs to pull in content from other sources.  I think they could curate this somewhat by reaching out to prominent bloggers (like Sandy) and ask for permission to republish interesting posts (or set up a submission process for authors to bring relevant posts to their attention).

I think the real question for BlueWorks Live:  is this the Minimum Viable Product offering, to be improved upon in future releases, or do Phil and IBM believe that it is fully baked?  I believe it is the former, and that the intention is to keep releasing frequent updates and improvements, as they were doing with Blueprint before.

You can see our previous coverage of this topic here (our sneak preview was a little earlier, but we’re looking forward to just laying hands on the product and taking it for a test drive on Saturday).  BlueWorks Live announcement here.

It isn’t a bad policy to just read everything Terry Schurter publishes (whether you agree or disagree with the positions).  This one starts out making the case for people and content in BPM:

In my view, BPM is really about people and content. In fact, content is the very heart of BPM, while people are its soul. I’ll go so far as to say that if people and content aren’t both in a given process, then it’s not a business process. Business processes are nothing more or less than the interactions that occur between people, and between people and content.

Now if we accept this definition of BPM, then it seems as if BPM should work for everyone. After all, every business has people and every business has content. But even that doesn’t necessarily mean that BPM applies to all. There has to be something more; there must be value to be gained.

(I’d say that if you don’t have people and content, what you have left is a “program” which is not the same thing as a business process)

And near the end, concluding arguments:

The takeaway here is that BPM is for everyone, though not everyone is ready for BPM. The reason: You can’t buy BPM in a box. You can buy BPM software, and depending on what you are doing, that may be a very important part of BPM for you, but the software you receive is not BPM.

So it’s up to you to start looking at what your desired outcomes are and begin documenting them. Then you can follow those outcomes back to see what the process behind them looks like. Or it may be easier to document certain processes and then figure out what outcome you really want from those processes.

I think Terry has laid out a couple of really important principles:

1. You can’t buy BPM in a box.  Repeat that three times.
2. Start with outcomes, and work your way back to process.  (And this is why I don’t understand why so many critics of BPM say BPM is all about cost efficiencies- it is only about that if you decide it is. BPM doesn’t decide business goals for you, you have to do that yourself)

Sandy Kemsley covered a few sessions at CASCON on her blog, and a few of them caught my attention.  In particular her blog of Richard Hull’s Keynote on Business Entities with Lifecycles.  Interesting take on present state of BPM:

He stated that today’s approach to BPM environments is fundamentally disjointed: there’s one conceptual model for rules and policies, another for analytics and dashboards, and another core business process model based on activity flows, while the data being manipulated is often not related to the conceptual models but is more of an afterthought in the design.

I don’t have enough data points to dispute his characterization, as I only know about the projects our teams have worked on.  But I’ve seen quite a few IT (including BPM) efforts that did the opposite – focused so much on defining data entities that they missed the boat with regard to the real requirements of the business processes.  I think the point is, business entities need real thought into their data and lifecycles.  Process data, which has a lifespan only of the process, needs a lot less up-front design to get right – and in particular, needs to remain agile as you implement the processes (and uncover the real requirements through iterative feedback).

Sandy’s take:

Maybe I’ve just seen too many leading-edge products and methods, but I don’t find anything here that new. Yes, it’s nice to have more formalized models and methodologies around this, but the idea of linking business object and process models, and auto-generating user interface screens from them, isn’t cutting edge. He positions this as not really competitive to WebSphere (process modeler), but being for cases when BPMN just doesn’t cut it. He described the differentiator as that of disaggregating operations into chunks that are meaningful to the business, then modeling the lifecycle of those chunks relative to a more global information model.

Well said.  I think auto-generating screens is about the least-useful innovation for this kind of work.  The real progress is just getting people to think through these issues and document them.  The end result will be a much more robust set of data objects and processes.  Not to mention better organizational knowledge of both.

Sandy Kemsley covered Janette Wong’s talk at CASCON recently. The point of the talk was to discuss applying workflow patterns to modeling business requirements, and turning those into executable business processes. A good bit of the commentary revolved around all the hard work still required to make a design pattern actually executable – in particular with respect to role-based task assignment:

She used an example of an “authorization” business requirement, where manager can create confidential requests, and transfer those confidential requests to others. This can be matched to the standard role-based distribution pattern, which is fine for modeling, but then needs to be mapped to an implementation platform: in this case, some combination of WebSphere Process Server (WPS), LDAP or other directory service for user authentication and authorization, a workflow client application for human task management, and any other data sources that include user/role information. This multi-system implementation requires not only a conceptual mapping of the process and roles, but also actual integration between the systems that house the information. WPS provides instance-based authorization roles, then needs to bind that to the other sources at runtime in order to populate those roles; it doesn’t automate the solution, and in fact only provides a small amount of assistance in getting to that mapping. This is complicated further by role and authorization information that is spread out over multiple systems, particularly existing legacy systems; the business may think of the roles as being encapsulated in one of these other systems, which then needs to be mapped into the executing process.

I feel like the patterns (like “multiple instances without a priori runtime knowledge pattern”) are more accurately described as key phrases or constructs, rather than patterns (though there are exceptions to that generalization).   Wait, what is the problem the “multiple instances without a priori runtime knowledge” solves??

I think more of something along these lines in wikipedia.  And the kind of patterns you are likely to read on Anatoly’s blog.  In wikipedia, an “observer” pattern tells me a lot about what it might be doing.  Anatoly’s “Do Redo” pattern rings true, for example.  They describe what they attempt to solve (for the most part).

Of course, many people misunderstand the point of patterns. They wonder why there is still so much work to do!   But patterns are not libraries of code – they’re patterns of design and code.  Its like knowing how to tie a square knot.  Although you know the pattern, you still have to tie the knot each time you want to use it.  Design patterns are much the same way.

The point of the design pattern isn’t that it is less work – it is that you already know you have a good solution if the design pattern fits your problem definition.  The problem with the workflow pattern site is that it lists solutions with no problem.

Anatoly’s blog actually covers design patterns quite well:

Pattern in BPM is a typical process fragment of typical way of communication between processes (some examples).

One may ask: which one is more usefull? My opinion it’s a pattern:

• Templates are specific (one process – one template), patterns are universal. A good pattern can be used in a variety of business processes regardless of the industry.
• A practical benefit of using a template may be less than expected. It usually covers the happy path only and the devil is in details – various workarounds, escalations and exceptions.
• The effect of using the right pattern can be large. For example, there was a case in our practice when the process plotted at 6 A4 sheets glued side-by-side was reduced to the elegant design with just 15 activities by using the right pattern.
• The value of the antipattern is its ability to preserve you from mistakes. The price of a mistake is unlimited in theory and sometimes it’s really big in practice.

And yet industry analysts continue to overly focus on templates… I’d rather have design patterns and useful, re-usable components.  To my mind, templates try to “automate” the process design effort – to commoditize what cannot easily be commoditized.  Design patterns “enable” the process design effort – empowering and improving the design effort (as do re-usable components).

Design patterns in BPM aren’t a lost cause- they’re a key enabler of the successful process designer.  But names matter- and in that department, Anatoly’s approach is vastly superior.

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).

If you needed a pictorial view of BPM history in one screenshot, Marco Brambilla has it for you.  Of course, this is just from one perspective and anything this simple can be nitpicked, but it does capture some interesting trends over the years, precursors to BPM, etc.:

Side Note: I should also thank Marco for including the BP3 blog in his list of prominent BPM blogs to read.  Many thanks for the compliment, Marco.

The Harvard Business Review recently covered Process Improvement, and considers the question of why it is so hard for companies to maintain their process improvement culture after a prominent leader departs.  The primary example is Allied Signal and Larry Bossidy:

Consider the story of Allied Signal. Under Larry Bossidy, Allied Signal was a “poster child” of process improvement success following the “Six Sigma” approach — enjoying consistent growth in earnings and cash flow from 1991 to 1999, highlighted by 31 consecutive quarters of earnings-per-share growth of 13% or more, and tripled operating margins to almost 15 percent. Bossidy wrote a best-selling book, called Execution, about his approach. Yet when Allied Signal merged with Honeywell in 1999 and Bossidy departed in 2000 and was replaced by Mike Bonsignore, they dropped their Six Sigma attention while focusing on a GE-Honeywell deal. According to market analyst Cliff Ransom, “It took about 18 months for a Six Sigma culture to essentially disappear when the wrong successor to Larry Bossidy took the reins.”

This is a cautionary tale to me about the problem with doing process improvement only as a human endeavor.  We need technology to support our process improvement efforts, to sustain the improvements we’ve made when people retire or turnover or move on to other opportunities.  As the author states:

As the Allied Signal and Wiremold stories demonstrate, there are significant potential business benefits from adopting a process improvement program, yet despite these apparent benefits, they weren’t enough to build process improvement into Allied Signal’s or Wiremold’s DNA. What are the factors that get in the way of continuous improvement?

I remember reading about Allied Signal and GE in the 90′s, and reading about how much they focused on Six Sigma and process improvement generally.   There are clearly benefits – but there are challenges in making these things part of a company’s DNA rather than just a yearly objective or review element.  To me, this is a bit like the difference between making customer satisfaction a yearly goal (you know who you are), versus making it a core tenet of the company itself (Zappos).  In a bigger organization, obviously a key element of this is to make sure your lieutenants are not just paying lip service to process improvement and customer satisfaction, but actually believe in it.  It also means making sure that you have local leadership that believes in process improvement – and will do it even without the support of upper management.  Finally, you have to put systems in place to support process improvement efforts – these systems act as a bit of grease on the wheels of process improvement budgeting and planning cycles.

Missed this when it first ran on Bruce’s site, but he now has a review out for DST’s AWD:

One of the oldest BPMS’s around is one you may not have heard of: AWD from DST Technologies.  If you send in a check to fund your retirement account or pay an insurance premium, chances are good that AWD is running the process to handle that transaction and the customer service surrounding it. [...] They call it a BPMS-enabled application rather than a platform.  The basic structure of the app is prebuilt, along with key data objects needed in operations that capture customer transactions and handle customer service.  That means business can build and maintain the solutions themselves… something many still insist cannot be done.

Bruce has a white paper available that goes into more detail.

Steve Blank’s writing about startups often offers insights far beyond the startup world.  Take this post, “You Negotiate Commodities, but Seize Opportunities“:

I hadn’t just lost a potential advisor I had lost an irreplaceable opportunity. We lost him not just over a stock offer. We lost him because we had treated him as a commodity – something that was readily available from multiple sources – and that you could negotiate its price.

In reality what I had in front of me was an opportunity – a favorable combination of circumstances that rarely occurs and if seized upon would have given me an advantage.

You treat commodities and opportunities radically differently.

You might be asking what this has to do with BPM.  But to those of us for whom BPM is a profession, we know what he’s talking about.  BPM is an opportunity for your firm to seize out-sized returns on investment.  The talent pool for doing BPM “right” is limited.  When you find the right person within your organization – the person who can deliver on the promise of BPM – you have to seize that opportunity.  Don’t quibble in negotiating their role and title and salary; give them the responsibility and latitude to deliver, and generously reward them for delivering.

Similarly, when key BPM resources (aka people) are outside the organization, we have to realize that we’re not talking about negotiating the hourly rate for a couple of Java developers (who number in the millions).  These outside staff have multiple opportunities, and sometimes the difference between success and failure is just having the right people at the right time.  A few dollars an hour won’t determine success and failure, but a few less of the right kind of people very well might.

Finally, this is a lesson for us, for BP3.  When we find the right person to bring on board, who can change the game for our business, we have to seize the opportunity.

The IBM Lombardi blog has an update on their Roadshow, where they are showing off the Websphere Lombardi Edition product:

Impact 2010 proved to be a launching ground for Lombardi BPM. Since the flagship event in May, Lombardi BPM has been introduced to a global audience through 20 Impact Comes To You events.  Beyond Impact, Lombardi continues to travel and speak at conferences around the world.  Take a minute to read some highlights from a few of our most recent shows and mark your calendars for an upcoming event near you.

More info on their blog.  I’ve been impressed with how wholeheartedly IBM has adopted the Lombardi product and made it a key part of their messaging.  It really did start at Impact and it has only picked up steam since then.

I also wanted to offer a shout out to an old friend (and customer), Farrukh Humayan, of PNC.  He’s a great speaker and communicator, and he has a great story to tell about BPM.  I first worked with him during the proof of technology for Lombardi BPM at National City, before it was acquired by PNC.  Nice to see him beating the drum for BPM at an event like this, some 5 years later!

I was surprised to run across this article from EMC/Documentum. It is a pretty thoughtful post about Process Improvement methodology and BPM.  It starts with a pretty good background proposition to set the tone:

BPM and PI share a common definition of the concept of process—“activities or tasks that produce a specific service or product for customers”—but from this common ground, their interests can go off in separate directions. In the ideal situation, they are synergistic, with an analytic, data-driven PI methodology identifying and building a sound business case for a BPM application while enabling a continuous improvement cycle driven by BPM transaction data. But it’s also possible for the methodologies to ignore each other’s roles or, worse, disparage each other’s value. This article examines the interaction for both synergies and contradictions.

Followed by a quick summary of origins, pinning process improvement’s history as far back as Henry Ford, with modern manifestations in TQM, Six Sigma, Lean, and Operational Excellence.  Whereas BPM’s origins are in IT, with a background in workflow, SOA, enterprise resource planning, and BI.

Its a pretty good read, overall, especially if you aren’t already familiar with BPM.  The conclusion I find especially interesting:

So, why are we not more aware of the successes of a combined PI–BPM approach? Reviewing articles and blogs on the BPM side, there seems to be a developing interest (or at least an awareness) of sharing the process space with PI and an interest in learning how the methodology can add to BPM’s value. This is especially true among BAs who are responsible for understanding process and process design. Discussion of the value of PI training and certification is common. This interest may be a leading indicator of change, but for the present, much of this thinking is lost in the push for software delivery—“It’s out of scope,” or “We have to get this done now; we’ll fix it later.”

In contrast, PI practitioners are more or less ignorant of BPM’s capabilities; at best, BPM is thought of as workflow. PI’s origins on the factory floor and its tradition of small, simple, incremental improvements sometimes do not translate easily to a complex back-office or case-management environment. Although basic principles of flow, pull, and stability remain the same, a literal U-shaped work cell may not be the answer; an understanding of its BPM equivalent may be. Disdain for or ignorance of software solutions—even a handoff of requirements—will not produce optimum future-state designs. Knowledge of BPM capabilities should be in the PI practitioner’s toolkit right along side Minitab and kanban cards.

At BP3, we’ve noticed the same opportunity, and the same disconnect – PI practitioners are often ignorant of BPM, or dismissive of any technology-enabled process improvement (despite the fact that they do use their own software tools to help do PI work…). At BP3 we look for opportunities to apply PI to our BPM projects, its almost a free boost to ROI (it requires minimal extra investment and yields better returns).

Gartner’s 2010 Magic Quadrant for BPM Suites is out.  As Sandy Kemsley points out, you can almost determine the contents of the report from the requisite vendor press releases (which reminds me of our previous post on the Forrester Wave):

However, three of the leaders have a lot to say about it:

• Pegasystems Positioned as a Leader in Prominent Analyst Firm’s 2010 Magic Quadrant for Business Process Management Suites (which includes a mini version of the graph)
• Software AG Named in the Leaders Quadrant for Business Process Management Suites
• IBM Lombardi positioned in the Leaders Quadrant of Gartner Magic Quadrant for Business Process Management Suites (also containing a mini graph)

At some point, you could probably reconstruct the Leaders quadrant based on press releases; many of the vendors in the other quadrants don’t bother to do a release about it (do they have to pay Gartner for that?): consider that IBM placed all three of its major BPM products in this MQ, but I only saw a press release about the one in the Leaders quadrant.

Luckily, you don’t have to reconstruct it if you are a lucky partner or customer of one of these vendors, they may be quite willing to share the report with you (presumably they’ve paid for the rights to share with their customers).  I think there were some interesting takeaways from this year’s magic quadrant. And not just that it differs so much from Forrester’s evaluation (in particular, the position of the Lombardi suite is dramatically different between the two… and if I may say so, I think Gartner has that positioning more correctly than does Forrester).

First, Gartner’s focus has shifted to four key usage scenarios, which paraphrased are:

• continuous process improvement
• industry-specific or company specific implementations
• business transformation initiatives
• process-based SOA redesign

I do like the fact that when Gartner has an opinion they go ahead and put it out there (in Gartner’s opinion, model-driven process execution, as opposed to code-based execution, is preferable).  Its refreshing to have those types of things spelled out.  You can disagree, but you know where they stand on that issue.

They also take great pains to note the difference between “market leaders” and “best product” (the two are not the same, though strong product offering is a contributor to market leader status). Gartner specifically called out an emphasis on “cohesiveness” of the suite, and support for all of the four key scenarios, above.  As Gartner puts it “The individual composition technologies are often well-proven on their own. Since we are evaluating a suite, we consider how well these technologies work together, and how easy it is for someone (a composer) to use the complete environment.” The emphasis is now on evaluating as a whole rather than evaluating the solutions in parts and then summing the scores for each part.  Experience might be harder to evaluate objectively, but this is a move in the right direction.

In light of recent discussions of why experience matters, I think this is a welcome shift in Gartner’s evaluation methodology – especially for BPM.  As I’ve noted before, BPM is typically comprised of doing many simple things right – but knowing which of the many things you can do is the trick.  With a BPMS, it isn’t a matter of brand new tech so much as it is composing existing technology in ways that really make sense at a deeper level to the composer.

The market trends that Gartner observes bode well for BPM consultancies like ours – a greater emphasis on continuous process improvement and business transformation. We observed anecdotally, and Gartner confirms, that in 2009 BPM initiatives continued to receive funding in a VERY challenging economic and funding climate.

A surprise entrant in the leaders quadrant is Adobe – under the radar (to me), Adobe has grown quite a business around BPM. The pure-play heritage BPM vendors make a strong showing in the leader’s quadrant, either independently or as the purchased solutions of large vendors (IBM, Progress, Software AG, etc. )

In describing leaders, Gartner explicitly calls out the “experience” as being a critical differentiator.

I found it interesting, as well, that Gartner concurs with my own experience vis-a-vis Lombardi customers (now IBM Websphere Lombardi Edition) – that they are the most advanced in BPM maturity.  I think this is a result of the consulting (and product) culture we cultivated at Lombardi (during the time I was there at least).  What a great endorsement of the excellent people who worked in Lombardi’s professional services group.  (it is, also, an endorsement of the sales group – whose job it is to open customers’ eyes to the possibilities, and to the customers, who have seized the opportunity of BPM with both hands and made the most of it).

Overall, this report tells me that despite the acquisitions, there is no shortage of BPM vendors in the market, no shortage of real choices for customers.  And there is still so much for these vendors to improve on – the innovations to come could make a huge difference for BPM professionals in the near future.

Congratulations to the leaders in the Gartner Magic Quadrant, I hope the increased market exposure will inspire you all to innovate BPM in ways we haven’t yet imagined (and in some of the ways we’ve imagined, but waited impatiently for!).

Steve Blank’s posts on the Business Model/Customer Development/Lean Startup stack have been really compelling reading, and I believe are zeroing in on what may be a repeatable process for startups.  It doesn’t mean the process always yields a successful startup – but using the tools and processes outlined, combined with good judgment and great talent appears to give a startup a much better chance of succeeding with the resources at their disposal.

One of his more recent posts focuses on the Business Model Design.  This is a key tenet of his process for startups: that the FIRST job is to find a scalable business model.  Only when this scalable model is found do you focus on actually scaling the business itself.  But how to design and describe the business model was one of those “black boxes” that most entrepreneurs weren’t really sure how to execute.  Steve points to work by Alexander Osterwalder and Yves Pigneur, who have published the definitive work on the subject, “Business Model Generation”.  Steve has, in the last year, started to use their Business Model canvas as not just a static tool, but actually as a launchpad for testing hypotheses and keeping a scorecard for tracking iterations and pivots:

In the last year I found that the Osterwalder Business Model canvas could be used for something much more than a static planning tool.  I realized that it was the launch-pad for setting up the hypotheses to test, and a scorecard for visually tracking iterations and Pivots during Customer Discovery and Validation.

Meanwhile on the other side of the world Alexander Osterwalder was coming to the same conclusion: tying the two processes together would create a “strategy stack for entrepreneurship.”

I find the idea of a process for generating a business model to be compelling.

Neil Ward-Dutton of MWD Advisors takes issue with equating BPM with Taylorism:

So I was really surprised to find all the tweets pointing to this post (”You failed at Customer Service, so now try Social Processes“), which seemed to be equating BPM with slavish application of Taylorism and an overly internal perspective that is acting as a malign force in organisations claiming they’re improving customer service.

And:

The truth is that BPM is a tool that can be applied in a number of ways. Yes, it can be applied to business processes to drive out waste, and this is often the focus. It’s not always done well. But I’ve also found BPM to be practiced very effectively in dealing with customer service improvement issues. Here efficiency can be one of the concerns, but it’s not the only one. And where BPM succeeds, a customer-first perspective is the overarching view taken.

I find myself in agreement.  The final thought on this from Neil:

The point is, a fool with a tool is still a tool. BPM is a tool. A stupid know-nothing who is hell-bent on slavishly applying Taylorism in a customer service environment can cock things up royally using BPM practice, but that’s not BPM’s fault.

The Navy Seals have an expression for this in the US, that I think is appropriate (and which I may not paraphrase quite right):  “Equip the man, don’t man the equipment.”  BPM should be equipping process participants. But in order to carve out a space in the blogosphere or for their product offerings, some are finding need to criticize the very idea of BPM, rather than the specific implementations or practitioners who appear to be the problem.  Having seen a “bad” implementation of BPM, they’ve determined that BPM = Taylor = dehumanizing.  The only explanation offered for those who say that BPM is working (for themselves or their clients) is that they’re mistaken, or talking their own book.  If the ROI is big, it can’t possibly be right.  If customer satisfaction improves, it isn’t being measured over a long enough time frame.

It doesn’t mean BPM answers every problem, but clearly managing your business processes (BPM) can help you improve customer service.  To argue otherwise doesn’t make much sense – unless you are arguing with the specifics of how to manage the business processes (which isn’t the same thing as saying you shouldn’t use BPM at all) – a difference of tactics or approach, not a difference of doing or not doing.