George Lawrie of Forrester recently wrote:

One pioneer that I interviewed was immensely proud of his lightning roll out of a guerilla app to support his firm’s front office in advising clients on complex product choices. I asked him about future plans and sheepishly he admitted they would be starting again from scratch because the guerilla app was unable to leverage enterprise services exposing critical data about product offerings. He remarked ruefully that sometimes you do have to follow the IT standards “yellow brick road” rather than just head for the hills, but wouldn’t it be great to have the best of both worlds, with both agile deployment and full advantage taken of enterprise assets and data?

Well this practically sounds like a call-out for how to approach BPM the right way – roll-out the guerrilla app (usually these are around a specific process) with a BPMS.  But when you’re ready to leverage enterprise services and data, you simply add those features to your process, a bit like a layer cake.  In fact, this avoids one of the key failure modes of BPM projects:  trying to cement integrations to early, instead of focusing on getting the actual process right first.

Sandy has published a review of Active Endpoints’ CloudExtend, an extension of the SalesForce platform that ads some BPM capabilities to the SalesForce platform.  Interestingly it looks like it is deployed “alongside” SalesForce as opposed to being “on” the SalesForce platform. Apparently they’re not the only vendor interested in this type of use case:

We’re starting to see client-side screen flow creation from a few of the BPMS vendors – I covered TIBCO’s Page Flow Models in my review of AMX/BPM last year – but those screen flows are only available at a step in a larger BPMS model, whereas Cloud Extend has encapsulated that capability for use in other platforms. For small, nimble vendors who don’t need to own the whole application, providing embeddable process functionality for data-centric applications can make a lot of sense, especially in a cloud environment where they don’t need to worry about the usual software OEM problems of installation and maintenance.

It is an interesting approach, and perhaps comfortable to Active Endpoints as they previously OEM’ed their BPMS engine to other vendors.  I can’t picture IBM or SAP or Oracle following this approach, for example.

I’m curious about whatever happened to Salesforce’s Visual Process Manager and whether it will end up competing with Cloud Extend; I had a briefing of Visual Process Manager over a year ago that amounted to little, and I haven’t heard anything about it since.

As I was reading Sandy’s review, I was thinking the same thing.  What did happen to Visual Process Manager?  Is it just not fitting the bill?  Maybe we’ll hear more from Dreamforce.

Adam Deane on Business Users and Programmers:

But the best differentiator pitch that I’ve heard being used is the “business user oriented” vs “programmer oriented”.
The claim is that business users can use the tool. I think it’s a great differentiator.  Although it usually doesn’t have much truth to it – it’s still a great market positioning pitch.

You see.. (and I’m trying to hide my sarcasm here..) BPM tools that use programming are bad for you.

If you need to open Visual Studio to build a workflow – it means you need skilled programmers, which means high salaries, and they need to write code, which means you need a tester, a team leader and a project manager (more salaries).

Every time the customer wants to change the business process you need the programmers to recode, recompile, retest (long deployment, or no changes – you can pick). Sophisticated code means that you need to rely on the IT team which means that you are tied in with that programmer/team. If the programmer leaves – no one will dare to change their code (who wants to be responsible for code that someone else wrote.)

“If you need to open Visual Studio to build a workflow” – then you’re doing it wrong.  A good bpm tool doesn’t require you to build your workflow in C++/C# or the like.

Of course if you’re opening visual studio to do an integration – have at it.  To build something custom that will plug into your BPM solution – have at it.  BPM should make certain things easier than traditional development tools (and a “workflow” sounds like one of those things to me).  It doesn’t mean that you won’t still need traditional development tools for a BPM deployment, but you shouldn’t have to write your process flow in assembly language any more than you should have to write it in C++.

Incidentally, I don’t agree that “business can do everything” is a good pitch, though I do agree with Adam that it is horribly oversold.  The business and IT have to work together to make BPM successful (or, arguably, nearly any long-term IT or business investment).  Vendors oversell this all the time, which accounts for Adam’s sarcasm.  But, conversely, companies purchase tools that bring too much complexity to the simple stuff, or tools that start simple but don’t scale with complexity.  What do I mean?  I mean that as you add more process intelligence to your tooling, complexity should increase at a linear (or less) rate.  If you experience complexity increasing at a greater than linear rate, you’ll hit a point where the system can’t be maintained – the interconnectedness and interdependency of the system is too complex for someone to properly understand, modify, and maintain.

That’s why it is important for the “workflow” to be simple.  Because it can be.

In a surprise (to me) move, OpenText has acquired Global360:

Waterloo, Ontario – 2011-07-13 – OpenText (NASDAQ: OTEX, TSX: OTC) announced today it has acquired Global 360 Holding Corporation, a leading provider of process and case management solutions. The acquisition continues OpenText s expansion into the fast growing business process management (BPM) market, adding to its technology, talent, services, partner and geographical strengths, as well as giving the company important new capabilities in dynamic case management.

Merger Agreement
The transaction purchase price is approximately $260 million (1), subject to customary purchase price and holdback adjustments. Global 360 has generated approximately $90 million in trailing twelve months revenue and is profitable. The transaction has closed in the first quarter of fiscal 2012 and is not part of the fiscal 2011 fourth quarter and year-end results of OpenText. The management team of OpenText will provide further information regarding the future plans of the combined company when it provides fiscal year-end results on August 10, 2011.

A press release in June 2011 claims 30% revenue growth YoY for Global360′s BPM unit for the quarter, but I can’t find any references to the baseline revenue # for either the company or the BPM unit.

So, given that OpenText just acquired MetaStorm, what will they do with Global360?  The press release points to leveraging their strengths in Dynamic Case Management and the Microsoft BPM ecosystem.

OpenText says they’ll continue on with roadmaps for MetaStorm and Global360.  But the questions flying on Twitter yesterday were references to indigestion, concern over merger issues, and doubt about how these products fit together.

The question I have is whether this is truly a software acquisition or a financial management acquisition.  In the latter, you simply acquire the company to capture their customer base and maintenance revenue stream – and then cross-license and work off the maintenance while slashing all costs. In the former, the new acquisition not only benefits from your bigger sales channel, but also helps you sell more of the product you already have into a new customer base.    Too early to tell what the real rationale is, or whether it is simply that they didn’t get what they were looking for in the MetaStorm acquisition.

Others commented that Global360 was one of the last of the original pioneers of the space (actually, it was the successor organization to eiStream, which was one of the original pioneers).  The number of viable commercial BPM suites seems to be declining even as the market is growing, which seems counter-intuitive.  I think that partly this is a function of lower ASP (average selling price) in enterprise software, and lower valuation multiples (these companies aren’t getting big multiples on revenue and growth as they might have in the 90′s).  That leaves them vulnerable to being acquired by someone big enough or determined enough. Not to mention, these firms have taken big VC or PE stakes, and those guys want their money out so they can put it back to work elsewhere.

We’ll keep an eye out for updates on this acquisition and report back.  But given how little coverage the OpenText-MetaStorm combination received, I’m not sure how much coverage to expect this time around.

Neil Ward-Dutton and MWD have published a brief piece about TIBCO and ActiveMatrix BPM. There’s a more in-depth assessment available as well, coming down the pike.

A couple highlights from his write-up:

• Revenue was up 25% year-on-year
• License revenue up 32% year-on-year
• Non-GAAP operating profit up 31% year-on-year.

TIBCO is now rapidly approaching $1 billion in annual revenue; and its acquisitions have helped it broaden its market footprint into healthcare, retail and other industries.

But specifically the BPM part of the business doesn’t seem to be standing out (the growth doesn’t look that different from the company as a whole):

Q2 BPM license revenue was 9% of the total $83m; that’s around $7.5m. TIBCO declares that this is up 33% year-on-year – which is a good sign – but I’m guessing that at the moment, the company hasn’t yet seen a return on its very significant redevelopment investment.

From what I understand ActiveMatrix BPM was a “start over” rewrite of their BPM offering… and from what we’re seeing/hearing anecdotally, it is taking acts of heroic proportions to make big deals happen.

Incidentally, wholesale rewrites of a product are rarely the right thing to do.  They open up all the existing customers to re-examine their go-forward choices… and then they have a new, less mature product to go pitch against entrenched competition.  Let’s suppose you build a better mousetrap that scales better (in theory).  Prospect A says “can you show me the three references where it scales to x million transactions per time unit?” and… well you can’t, can you?  It is a new product after all.  And then if you get a customer to buy into it – maybe it scales, maybe it doesn’t.  Scale is just one dimension- there’s feature-fit, UI/UX, production support, etc.  So many unknowns to answer, that the old product had answers for (maybe bad answers, but answers nonetheless).  But, ironically, a company does have to have the courage to rewrite pieces of their software – or to acquire new pieces of software (as Tibco has done).  Sometimes the difference between a product rewrite and a “module” rewrite is one of perspective, but one rule of thumb is that the product is a SKU – something you sell.  A module isn’t sold independently.

I think the move to ActiveMatrix BPM was more problematic than it appeared on the surface. Putting the $7.5M in perspective… if that is up 33% over prior year, they were as low as $5.625M the year before… This is about the scale of pure-play BPM vendors… but TIBCO + Staffware used to be much bigger than those vendors at the time of their merger…  Their momentum seems to have been in the wrong direction… (when I worked for one of those pure-play vendors, we always looked forward to competing against Tibco in a BPM deal cycle…)

[Editor's Note:]  Gary Samuelson joined bp3 full-time in 2011, after years of collaborating on-and-off.  Gary’s been delivering BPM solutions for years, and has been deep into technology development and consulting throughout his career.  We’ll be sharing his blog posts here, republished with his permission – and we think he brings a different voice and perspective and sweet-spot for subject matter to our BPM-focused blog.  Thanks, Gary, for adding to the community!

—

Shared with permission by Gary Samuelson, click here for original blog entry.

[Author's note:]  Quick Forward: In keen interest of fewer keystrokes-per-noun, I’ll refer to IBM Business Process Manager Advanced as “iBPM”.

Think of a phat buffet – a Las Vegas buffet. All good – yes? This is iBPM Advanced: a nicely packaged collection of deep technologies spanning light-weight dojo widgets, through aggregation and hosting platforms, and on into security and high-availability.

My first impression, though honestly skeptical, is good. We’re looking at the result of serious thinking and efforts on software tools and frameworks for building out and maintaining sustainable Business Process Management.

The individual pieces within iBPM are, by themselves, point-solutions. These bits aren’t new… Together though, in their aggregate form, a composite immerges with some voice and resonance as to direction…

An example?

In the BPM space we usually end up wanting and then building several custom web-UIs (pages and widgets). String these pages together and you get a user-facing process with various back-end service integrations. Moving forward – within “corporate client” each business unit has a need and each “need” gets its own: look, feature, and function. Into this mix add the voice-of-reusability. The same web-UI is then tweaked… re-factoring, and so on until we end-up spending more time in polish.

Measuring progress against business value (not building software), BPM projects tend to lose themselves early on low-value platitudes (look-n-feel and reusability) – all good for vision and heated debate but very bad on business. This isn’t to say such topics lack importance. All must be heard…

Now let’s approach the “UI-debate” with a brick… as in building structures – one brick at a time. IBM-BPM Advanced brings in “Business Space” – this technology allows for the use and re-use of “Web 2.0” widgets and functions. Rather than losing ourselves in debate, each end-user (literally) has the tools and building blocks for assembling their own uniquely personalized look-n-feel.

The BPM team can now better specialize and deliver on re-usable components within a framework built for this pattern. The “one-off” solution is over… iBPM Advanced provides a nice framework for us to quickly bridge across a common BPM pitfall. The UI and re-usability debate ends with “drop-in” Business Space (aka Mashup).

In an apparent bid to become tomorrow’s ERP system, Appian makes an appeal to “stop application sprawl“.

But they perked up when talk started shifting to how Appian could wrap or replace existing point solutions in addition to automating currently unstructured processes.  A few minutes later, full of excitement, they said the following before the whole group, “After we adopt Appian, we will need to be convinced why any point solution would be better than what we could create for our own needs in BPM.”

(their emphasis)

It is a little counter-intuitive for a BPM services guy like me to complain about pushing more BPM.  But I’d just say this: your BPM platform is not your application replacement platform.  It is your process -aka BPM- platform.  Your firm won’t be better off having all of its systems inside Appian (or another BPMS) if there isn’t any process improvement and rationalization happening along the way.

Rather than seeing someone say that they would adopt the BPM solution over any point solution that can’t prove it is better, the framing should be in terms of process:  before buying a point solution, we need to understand how it will fit within the overall fabric of our processes, and whether that “fitting” effort will outweigh the benefits of buying a point-solution application (presumably best-of-breed).

We’re not doing anyone favors if we just hand them the BPM hammer and let them think that all their issues are nails.

But if you do find yourself doing a “rip and replace” project, keep this in mind:

When building a BPM solution, we are often integrating with and replacing parts of legacy systems.  Often one of the first requirements from the business will be that the new system does everything the old system did in order to be accepted.  This is generally a bad false start to a project.

However, one of the best tactics is to figure out what the 2-3 key NEW capabilities your solution will bring to the business that are so compelling that some minor discomfort over less important details will not derail the project.  You can call this marketing, but it is truly understanding where the real value opportunities are in your project.  Sometimes these capabilities are things the users will clamor for, sometimes things that the management team will clamor for, and rarely, things that IT will clamor for.  Make sure that at least one of your major stakeholder groups is squarely behind a few of the wow features of your BPM project.  If you don’t have that excitement in one area, my experience is that you’ll find uncomfortable scrutiny on an exact comparison of the new solution versus the old solution.

I was asked the other day by a consultant from a large provider, “What do I need to know to get into BPM consulting?”

So you want to be a BPM Practitioner? “Great, we need all we can get!” Actually, what I did say is that “it is not a career cut out for everyone.” Besides requiring really above par intelligence and a passion for BPM, you also need to possess very strong abilities in leadership, pragmatism, observation, intuition, and adaptability. The challenges you will be engaging with businesses on are usually fairly substantial and all compounded by a fog of competing projects, limited resources, competitive pressures, politics, lack of shared vision, lack of education, paranoia, and a host of other factors. Directional clarity which would be considered “high fidelity” is usually not going to be found there. Ambiguity often rules the corporate landscape, and especially so in the business process arena.

Today’s companies have been transformed by a deluge of overwhelming change and it is up to you and your team to help the organization remediate the highest value areas you can possibly get your hands on. I’ll use the term “operator” in describing a BPM practitioner for a couple reasons. First off, you are not playing the role of a strategist unless you truly have that job and the power to effect a company’s overall direction in a major way. If this isn’t you then you are viewed as a contributor and that is exactly what organizations need, real contribution. I will take a very solid operator over a theorist any day of the week on a BPM program! Secondly, you are going to get your hands dirty and when I say dirty I mean designing, developing, and/or analyzing business processes. Companies need contributors who really know how to deliver and sort out the “should do versus could do” in critical and changing situations, serious operators.

It is not enough to be a good developer/technologist nor is it good enough to be a good business analyst. BPM is specialized and brings with it a whole new level of skill requirements. Are you considered truly excellent at what you have been doing and have those differentiating abilities mentioned? If so, then you will likely be able to enjoy a very rewarding career in BPM!

Today there isn’t a truly recognized industry standard in curriculum or certification for a BPM Practitioner. It’s not worth going into all of the whys of that here, suffice to say there just isn’t and probably won’t be for a good number of years to come, if ever. Nonetheless, that doesn’t prevent you from joining this community and being highly effective in performing the job.

So where do you start on this path? Your best bet is to try and join a boutique consulting firm or possibly a BPMS vendor (I say possibly because only a couple might actually develop skills outside of their own software focus) that has deep expertise, training, performance standards, practical application capability, opportunity to engage on initiatives, and proctor/mentors available to help develop the skills you will need. Learning never ends for anyone.

Whether your background is in IT, Operations, or Line of Business you will need to develop capabilities that are outside of your historical core competency. For example, if you are a developer it would be expected for you to also be able to understand how to perform basic process analysis, e.g. Value Stream, MSA, Pareto, and Process Capability to name a few. Likewise, if you are an analyst you should be able to understand and articulate BPMS capabilities, Enterprise Architecture concepts, Agile and other iterative based SDLC’s, and various enabling technologies surrounding BPM delivery. Moreover, in either scenario you need to wrap that with good project management functions, communications, human interaction/conflict resolution, change management techniques, adult learning, and other soft skills that will allow you to perform in the really challenging environments that are part and parcel of today’s Business Process Management world.

Again, these skills listed outside your initial competency don’t necessarily require mastery but you do need to have some solid capability starting out. Once you have these skills down, there is plenty of opportunity to become more advanced or specialized in any particular area.  Not everyone will make the cut but if you think you have what it takes and the desire, this industry sure does need you!

Sandy Kemsley’s blog on BPMS pricing, she points out that pricing is still incredibly opaque.  There’s also a discussion on Quora that she refers to.

The problems:

1. Different vendors use different metrics to price (user, process, CPU, PVU, duration, etc. )
2. Different vendors are pricing different things (simulation, Modeling, BPMN, BPEL, XPDL, execution, integration, reporting, analytics, ESB, Messaging, Database, etc.)
3. The customers are really in different situations.  If a vendor prices only by user, a customer with a simple process but 100,000 users can’t buy that product.  They might buy a product that prices by CPU (especially if their process has very little processing overhead).  So by publishing prices, vendors run the risk of turning away business as well as the risk of selling too cheaply.  (The CPU-priced vendor might have been able to charge a higher price, but if they published a per-CPU price then the customer will take the lower price, of course).

The root of it is that the vendors are trying to make a value sale (or value-minus).  And customers are just trying to get a price that makes their ROI (value equation) work out.  In that kind of market, transparency isn’t likely.

From Sandy’s blog:

Remember the bad old days of buying a car, when you had no idea how much it cost when you walked into the showroom, and had to go through some weird pseudo-negotiation between the salesperson and his manager, where they would throw in the free floor mats if you did your financing with them, give you an extra discount if it was within a week of the end of their sales quarter, or bait-and-switch you into a more expensive model? Enterprise software has always felt a bit like that to me, and BPMS pricing and sales tactics sadly fall into that same category, at least for many of the major vendors.

“the bad old days”?  Car buying is still like this in the US (you do have alternatives, but by and large, it boils down to this same kind of experience).

A few days ago, IBM announced the release of two new versions of Websphere Lombardi Edition:

WLE 7.1 for Linux on System z – so you can run the (nearly) latest Lombardi portfolio on a mainframe!  (Note: Phil Gilbert points out that earlier versions of Lombardi also supported System z, but it wasn’t widely known)

WLE 7.2 – which includes expanded globalization and translation capabilities (including the authoring application itself).  But 7.2 also ships with better integration to WPS (Websphere Process Server), iLOG, FileNet, and DB2 (as well as optional integrations to Outlook and Sharepoint – SKUs formerly known as Teamworks for Sharepoint and Teamworks for Office).

Its a good incremental step for incorporating Lombardi BPM into IBM’s Websphere application family – and given IBM’s global focus the focus on globalization/localization makes a lot of sense.  But existing customers are still looking for an in-place upgrade path for production databases, to get from Teamworks 6.x and Teamworks 7.x to WLE 7.x.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Well, it wasn’t that long ago when the pure play BPM acquisitions had us all wondering what would happen to the pace of innovation in our corner of the world where business meets IT on a daily basis.

But besides the big players, Pega, IBM, Progress, Oracle, SAP, Software AG, Fujitsu… and a few of the smaller old guard still competing: Appian, ActiveVos, jBPM, Handysoft, Intalio, Global360, Ultimus, Papyrus, etc.  We also see some new players in and around BPM:

ActionBase – focusing on user defined processes, case management, unpredictable work, etc.

Signavio – BPMN modeler in the cloud, but also partnering to white box their modeler with various other tools (including Activiti)

Serena -

RAVEN – An interesting take on starting business process models with simple sentence structure descriptions.

Activiti – new open source effort, execution-oriented, led by some former jBPM members.  Uses a version of Signavio for modeling.

Process Maker – another opensource/cloud offering.

etc.

And I’m probably missing or even insulting several companies based on my overlooking them in this list off the top of my head (my apologies!).  So, here’s my offer to anyone with an innovative BPM product – send me a link and a quick blurb and I’ll update this post or create a new page in our blog to include that information for posterity.

So what’s the point?  There’s a lot of innovation going on in our space.  The sheer number of products targeted at making modeling processes more accessible is surprising. And then there are new execution engines.  I think because the market is no longer trying to compare every offering to Lombardi or Savvion as the definition of a “BPMS” – some of these other offerings now have an opening to start adding value to companies’ BPM efforts without having to get into a direct comparison across the board- just competing based on their strengths.

Innovation in the BPM market is alive and well.

Jacob Ukelson is once again pushing email and documents as the way process should happen when it is “design by doing”:

The only way “design by doing” can work is if you observe knowlwedge work in its natural setting. That means email, documents, meetings and telephony. That just doesn’t mesh with a BPMS. I think that most BPMS vendors would like people to tidily do all of their unpredictable, ad-hoc work in the BPMS, but the real world doesn’t work that way. People use what they like, and like what they know.  They are not going to change their habits just because the vendors think they should.

The idea that design by doing is antithetical to BPM doesn’t seem right to me – there’s a spectrum between these poles, and i’ll give you an example.

The way I’ve seen Lean applied to white collar (officework/knowledge work) processes resembles design by doing. You start by running whatever they currently do, document the wasted effort/steps, try out changes in the process, til you get it right. Then you start training more and more people to follow the process. A BPMS can support this kind of work because you can iterate fast enough to keep up with the changes, even over a very long improvement cycle with many changes.

Now, design by doing isn’t quite the same as “unpredictable work” – but obviously, they are related concepts. If the work is inherently unpredictable, or improvements to it do not justify IT investment in a doing-by-design approach then I think ActionBase is a great answer to that need. As Jacob says, email and documents are the tool of choice when one doesn’t have a process – precisely because of their ubiquity and rather than compete with that, I like how ActionBase leverages that truth.

As to his characterization of BPMS vendors – he may be right that they would prefer to have the unpredictable work go into tidy processes. But this is not a fair description of the BPM service provider community (or at least, of the firm yours truly works for), which has often been creative about applying hybrid structured and unstructured techniques to address knowledge work.

No matter what the vendors say, no business user can take a BPMS out of the box and start using it for their own work.

True – if you mean to use it without a single implementation dollar spent.  But if you have 100s or 1000s of people doing this email and document thing for a process, you can probably afford to spend a few IT dollars to figure out what the best practices are. Let the doing guide the design, but you have some efficiencies of scale to achieve. In general, BPM has to get simpler – and the kind of approach ActionBase takes seems (to me) to be a great example.

Jacob wraps up with something I couldn’t agree more with:

So if we are really to make “design by doing” a reality as part of BPMS, then somehow the tracking and management of  existing end-user tools and work paradigms (especially email) have to become a part of the conversation.

So true. BPMS vendors need to be able to track email-based processes.  A Lean or other process improvement expert can work without this technology, but as with structured processes, it is so much easier to get to the “right answers” when technology supports your efforts.

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim’s intent):

• Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.  It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.  This works if the process is predictable.
• Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.  Since you can not predict it, you have to elaborate it as you go along.  You design it, as you are doing it.  There is no development life-cycle.  This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management.  By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don’t know, why not just call it “design by doing” and use that as the tag-line for your product offering… ACM doesn’t quite have the same ring to it, and it isn’t nearly as easy to relate to.  Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith’s blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:  a bunch of companies have already acquired one or two BPM software vendors.  How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?  Would you rather be the “XYZ” software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?  Of course!  (well, as Max says, he doesn’t care about the labels for his product, Papyrus, so I don’t mean to personalize this to Max, by any means!).  And if you’re a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle – RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.  But like some others (Anatoly for example), I’d like to keep BPM separate from BPMS (method from technology).  There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn’t benefit customers or practitioners.   I see managing unpredictable work as still being “process-driven” even if others don’t.  Design-by-Doing sure sounds like a process to me, folks.  Maybe a meta-process, but a process nonetheless.

I’d like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings – explain why your software is just the right socket wrench for the job, rather than a screwdriver.  Educate the market on why the software fits the problem definition.  As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

Adam Deane noticed a change in Gartner’s BPMS Definition:

If you compare it to previous BPMS definitions by Gartner (for example in last year’s Magic Quadrant for Business Process Management Suites), you will see two major additions:
1. Document and content management.
2. Inline and offline simulation (instead of just simulation)

Good catch.  Of course, we shouldn’t be surprised that the definition of “what’s in the BPMS box” would change over time – I expect that soon it will be a given that several other features (even products, or market segments) should be included in the BPMS definition.  Why? Because too many people view BPM (or BPMS) as the the future “Business Operating System” (in the 90′s, I think most people viewed ERP as the operating system for the business… ).  Rightly or wrongly, that puts a lot of things under the umbrella.

The real progress will be when the technology becomes so good it is transparent to the business, so obvious it is as if it works by magic (see Arthur C Clarke: “Any sufficiently advanced technology is indistinguishable from magic.”).

Theo Priestly: Is the BPMS mightier than the COTS (Commercial Off-The-Shelf software)?

With the advent of similar suites such as Bonitasoft, Outsystems and Iceberg that allow organisations to build business process based applications directly, and others that offer the same web-based style workflow creation, could these BPMS tools eventually replace the more expensive COTS (Commercially Off The Shelf) software alternatives as they mature ?

Theo asks if this is Build or Buy – but I’ve seen many firms look at this as “Build vs. BPM+Build vs. Buy” – where BPM+Build is the middle-ground, leveraging several more simplistic transactional services and wrapping them into processes that make sense to the business.

Every so often, someone makes the argument that essentially nothing has changed in the world of BPM.  Actually, this isn’t unique to BPM – it is a common refrain across all kinds of software categories.

And it is tempting to buy into this, when you realize how durable a writeup like the history of BPM can be (this isn’t a bad writeup, by the way). But one has to remember that history *should* be a bit durable with the passage of time. Jon Pyke recently opined that no one in BPM has anything new to offer.  But the substance of his post is that the marketing isn’t differentiated, and the product positioning isn’t differentiated, and further, that the people who work at these companies don’t know what differentiates them.

Having worked on both sides of the coin (on the software side and the consulting side), I have to disagree with some of Jon’s conclusions because the input data is more limited than he’s realized.

For example:  of course the marketing messages are commoditized among BPM vendors, as is product positioning.  Sadly, it is perfectly easy to copy someone else’s marketing and positioning – it takes minutes, hours, or days at most to do so.  I think the tragedy in BPM is that all the vendors seem willing to implement “checkbox” versions of every feature that analysts care about, rather than go deep with the product in areas that produce real value for customers.  Unfortunately, vendors have been largely rewarded for such behavior with good product comparison reviews and chart placement – but their customers have not been similarly rewarded by this kind of investment.

There are real differences in these products, but it requires a much more in-depth understanding of the products to appreciate it.  Can we be surprised that customers have a hard time achieving this level of product knowledge during the evaluation process?  I used to work with someone who was always telling me how “nothing had changed” in the last 5 years in BPM – at a time when, 5 years before, there was no BPMN – and at that time, BPMN was the de facto modeling standard for BPMS offerings.

There has been quite a bit of innovation in the last 10 years in BPM, but some of the best ideas didn’t get enough investment to go from interesting to indispensable, and some of the best ideas really were commoditized – picked up by all the pure play vendors (and later, but the stack vendors).  I could argue that nothing much has changed since 1994, when I wrote a sales process application that leveraged Lotus Notes VIP to replicate sales data and manage workflow between Sales, Sales Engineering, Manufacturing, and R&D.  But that would be a bit disingenuous. I could write that solution in 1994, but I didn’t have a way to communicate the process to the business (BPMN), that accurately reflected the implementation so we could make sure we had it right.  And I didn’t have a standard data representation for analyzing the process data (for business process improvement).  I certainly couldn’t handle in a trivial way a process that required parallelism the way I can with executable BPMN models.

Jon says:

That’s why, and I’ve said this many times before, BPM is far too important a topic to leave in the hands of product vendors – this is a Business thing – the clue is in the name BUSINESS PROCESS MANAGEMENT. [...] They will talk about the presentation layer, the SOA integration support, analytics, modeling and what have you.

This is, unfortunately, true of a great many people in the BPM ecosystem.  However, it doesn’t sound like a few of the pure plays that have been acquired (take a gander at Phil Gilbert’s blog for several essays on the subject of business taking control back from IT), and it doesn’t sound like some of the new vendors (ActionBase as one example).  Whether these vendors are well-represented at Gartner conferences is another question entirely, but it is ironic that it is typically the small vendor that is more focused on business value. One of Jon’s last points:

Every vendor believes they are unique but the fact of the matter is many of the software metaphors used in these products were defined by pioneering workflow vendors such as Filenet, Staffware, Plexus and Wang

Well, honestly, software metaphors are meant to be re-used, so I’m not sure that that, in and of itself, is a point of criticism.  For example, some of the metaphors in older integration technologies like CORBA and DCOM are embodied in SOAP and WSDL – but not many would argue that web services weren’t a step forward. And if BPM functionality is truly commoditized – is that bad for the customer and the industry if it becomes more standard and more cheaply available?

I know it is tempting to look at the glass as half-empty, but with so many BPM vendors performing so well in a challenging environment, its hard not to look at the glass as half-full. Call me an optimist.

Theo Priestly on BPM Redux wrote about ArisAlign and its lack of “buzz”.  I’ve had similar feelings about Aris’ user experience, and the feeling that some of the enthusiasm espoused is a little forced – sort of trying to hard with the “I (heart) ArisBPM” pins, etc.

But the post reminded me of a theme that has been on my mind a lot over the last year: Design Matters in BPM. As if there was any doubt, I see more and more evidence that in the Second Decade of BPM, design will matter.  Not just a little bit.  I believe design will dictate whether BPM achieves ubiquity in the business. Design will dictate which tools will benefit from that ubiquity.

Apple serves as a good example of how much design matters in an industry that appeared to be commoditized (personal computing, cell phones).  Some might argue that BPM software isn’t commoditized yet, and therefore the focus might be on features/functions rather than “design”.  But I think the key elements of BPMS are, by enterprise software standards, fairly commoditized:  there are many players in the space, customers have a difficult time discerning the differences from a feature/function point of view, and ASP (Average Selling Price) is likely declining for most BPM vendors.  There are also a couple of open-source BPM software offerings on the make.

Combine the above with a trend toward putting BPM suites “in the cloud” and offering them in a SaaS model, and it really starts to look more like a utility.  But what takes it to the next level?  Here are some areas of BPM and my thoughts about how well they’ll differentiate vendors…

• Execution.  I think everyone agrees execution is nearly commoditized.  There are *real* differences at the execution level, but the market doesn’t recognize these differences in a way that channels dollars to the best execution engines.
  
• Simulation. Many of the vendors offer this.
• More modeling constructs? Already, vendors barely provide a fraction of the BPMN modeling capabilities defined in BPMN 2.0 (or even 1.0).  So, there’s an opportunity here, but fast-following will be pretty easy.
• Process Discovery? This holds some promise for differentiation in the short-to-medium term, in my view (there are only a few vendors who even claim this ability).
• Optimization? This has potential, but the current solutions simply don’t achieve it.  They work really well on small data sets and don’t (yet) let you efficiently do “optimization” on enterprise production data.  There’s a significant software investment to make here, and opportunity for differentiation.  Pair optimization with process discovery and you’ve got something really interesting…
  
• Modeling tools?  This is heading toward commodity rapidly.  Absent the advent of SaaS software I would have predicted an open source modeling tool would gain pre-eminence and get embedded in a lot of commercial products.
  
• SaaS / Cloud offering? There are already numerous choices and prices are heading toward standard increments.
  
• Community / Collaboration?  Outside of BPM, these are already fairly commoditized from a feature/function point of view.  Wikis, chats, Instant Messaging, Videochats, Communities – these features will not provide differentiation on their own.  In fact, vendors may rely on Wave or similar technologies to incorporate collaboration without making some of the IT investments that early adopters have had to make.
  
• “Dynamic” BPM or “Case Management”.  Call me crazy, but I remember CASE tools being all the rage in the mid-90′s.  I think unstructured, dynamic, and case management style processes are important, but I don’t think the technology required will offer differentiation to vendors for long from a feature/function point of view.  What they offer is a “better fit” to these use cases, but they’re not solving a problem that couldn’t be solved before.  (Note: Better fit matters, its why you should use BPM tooling to solve process problems rather than just slinging some Java or PHP code or hoisting a SOA stack into place)  To the extent that these “case management” tools are better, its a result of better design to suit the problem, not a case of out-featuring the other guys…
  

The opportunity for BPM vendors will be to produce differentiation based on the design of their products and offerings, by producing designs that engage the users, that elicit effective and efficient usage.  Collaboration, Unstructured BPM, Process Discovery, and Optimization all offer the biggest opportunities for differentiation by product design, in my opinion.

In closing, I should clarify that product design is not just skin deep.  Some make this mistake when they look at Apple Products and see only the outer shell.  Good product design goes much deeper than the UI, than the outer shell of the product.