This success snippet is about an organization in the insurance industry that has experienced significant top line revenue growth while simultaneously increasing it’s net profits over 40%. This company uses BPM for aggressive acquisitions by leveraging standard processes with local variations while driving down overall costs on a large scale.

Not only do they use standard processes to acquire and assimilate, they use standard processes (with local variations) for their core business functions, which the acquired companies will also participate in.

It actually doesn’t matter if this is defined as “structured” or “unstructured”, knowledge work or routine work.  The world will look at this and likely call it “BPM”.  Because it is about managing business processes. And this is why the arguments among experts about naming are really a bit off-point.

As Jim Sinur says – the success of BPM is spreading and is too big to ignore.

Related posts:

1. Stupid Stuff Happens
2. Airline Mergers Don’t Use BPM?!?!

First, there’s Jim Sinur, of Gartner:

Bottom Line:
If the SAP BPM architects and technicians can show customer value that catches top managements eye, the wait will be shorter. Right now, it looks to be another two years. With that said, look at what SAP has done in BPM from two years ago. http://blogs.gartner.com/jim_sinur/2009/10/14/teched-09saps-bpm-and-brm-progress-to-date-watch-out-for-construction-cones/

I guess Jim and I are on the same page.  It is *always* another two years with SAP.  Two years from now you’ll be amazed.  Except you aren’t – because two years later, they tell you it’ll be another two years.

But, let’s turn our attention to Bruce Silver’s coverage.  After all, earlier this year he was pretty optimistic about SAP’s BPM.  So what did Bruce have to say?

At this week’s SAP Tech Ed conference in Las Vegas, BPM is definitely off the main track.  The only other BPM analyst here that I recognized is Jim Sinur of Gartner.  The keynote sessions were all about HANA, SAP’s new in-memory analytics platform that is the key to reinvigorating the entire SAP portfolio (at least the parts they still care about).  HANA-enabled BPM won’t come until 2012, but it should provide a significant performance boost (process transactions per hour) as well as powerful real-time process analytics.

Started out sounding pretty down on BPM… But Bruce hasn’t given up on BPM with SAP:

But it would be a mistake to say that SAP has not made significant progress in BPM.  It has, but you had to skip the analyst sessions with the execs and go to the breakout sessions from the BPM product managers to hear about it.  Those sessions were, on the whole, excellent, many of them hands-on with the tools.  In that sense, Tech Ed is the mirror image of IBM Impact, where BPM sizzle was all over the keynotes, but almost no details were available in the breakouts.

(Actually the IBM breakouts had a lot of detail – and got some coverage on our blog.  The analysts just need to break out of the special analyst sessions!)

Bruce notes: “Where conventional BPM (such as NetWeaver BPM/PI) emphasizes BPMN-based activity flow, embedded processes involve transaction events where the order of occurrence at runtime is more flexible.”  But later notes that the embedded processes can be visualized as BPMN diagrams.  Hm.  It sounds contradictory on the surface, but I’ll assume not.

Bruce also mentions “Gravity” – the Google Wave integration and BPM implementation.  But, he’s comparing a (still) “shaky” beta product with BlueworksLive, which has been in production and serving customers for more than 5 years (updating roughly every 6 weeks).

Focus matters a lot for big organizations like SAP, IBM, and Oracle.  At IBM, I’m seeing the focus (for now).  At SAP, I’m seeing some progress, but it looks uneven.  Driven from a level lower down the management chain.  It doesn’t get top billing.  Instead – top billing is HANA and in-memory analytics?  Odd.

Or it would be, if BPM were on the front burner.

Related posts:

1. Bruce Silver on IBM’s BPM BlueWorks
2. Bruce Silver Reviews Signavio (BPM in the Cloud?)
3. The Sharepoint Effect Revisited

As BPM matures it will have to reach to groups of knowledge workers that can easily work together for the common good of process outcomes, improving processes and recognizing unexpected patterns of behavior in processes plus participating constituents(clients, partners, employees etc.). Enabling good feedback mechanisms and encouraging “early warnings”. will be behavior that will be encouraged, going forward.

Reading between the lines – he asks if Social BPM is only communication/collaboration or if there is also some structure required to deliver the benefits.  To me, a short-hand way of describing his cautionary note is:  if there’s no Design, then you’re just Doing. 

I’m not sure that just Doing is better than Doing with a little bit of Design thrown in for good measure (or, in the case of highly structured processes, a lot of Design).

Related posts:

1. Doing by Design vs. Design by Doing
2. Design Patterns in BPM – Lost Cause?
3. Anatoly on Design Patterns vs. Templates

[...]

9.  There are several vendors exhibiting spectacular growth rates (north of 60%) even with the power vendors making an impact.

10.  BPM is enabling greater leverage of existing application / package portfolios

I don’t have great access to the growth #’s for the software vendors, but I’ll bet Jim does.  And the growth rates don’t really surprise me – we’ve seen a lot of activity in our sphere, so to speak.  BPM is clearly going more and more mainstream.  The other day I mentioned BPM to someone at a social event and they actually knew what I was talking about.  (Please, don’t judge me for mentioning BPM in a social context – someone asked me what I do for a living!)

Related posts:

1. Happy New Year 2010
2. BPM Spending and the Hockey Stick
3. The First “BPM in Review” Post of 2010

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

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

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

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

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

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

Great read from Neil.

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

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

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

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

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

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

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

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

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

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

Related posts:

1. Business Architecture, Meet BPMN. BPMN, Meet Business Architecture
2. Don’t Take My Word for it: Jakob Freund says BPMN Works!
3. A BPMN 2.0 Update from Bruce Silver

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

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

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

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

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

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

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

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

Related posts:

1. EPC vs BPMN?
2. IBM Fulfilling BPMN 2.0 Promises?
3. Don’t Take My Word for it: Jakob Freund says BPMN Works!

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

Related posts:

1. If there’s no Design, is there Design by Doing?
2. For the Second Decade of #BPM, Design Matters
3. Design Patterns in BPM – Lost Cause?

The Lombardi press release touts a shared belief in customer success, a good product and culture fit, as well as good ole market opportunity:

“Any discussion on business improvement inevitably leads to improving the processes that are at the heart of every company,” said Craig Hayman, general manager, IBM Application and Integration Middleware. “Recognizing this, IBM has strengthened its presence and investments in business process and integration software to meet these growing client demands. Lombardi fills out our company’s portfolio in this key area.”

Lombardi already supports Websphere, and  was an early adopter of the app server in the BPM space (I can testify, I was there with Lombardi’s first Websphere clients).  In Austin, we’ve certainly seen a history of IBM successfully acquiring and expanding software companies that were acquired (Tivoli and Webify come to mind).

I’m sure there will be more news as the day(s) go on, I’ll try to just keep this post updated with the latest, unless something comes up that deserves an entire post on the subject.

Congratulations to the Lombardi team, who have been breaking ground in the BPM space for years now, and yet staying focused on making customers successful, not just on the latest bell or whistle on the product road map.  I think there’s a good chance, depending on the structure of the takeover, that some of Lombardi’s DNA will rub off on the BPM-focused parts of IBM.  I can see the effect Webify has had on IBM’s efforts, and I always thought Lombardi’s and Webify’s products would make for an interesting combination. Now we’ll get to find out, I guess!

More to come…

IBM press release here.

UPDATE: 12/16/2009 7:20am PST
Keep up to date with what the analysts (and others) are saying on Twitter:

And then we have a post from Phil Gilbert on “The Second Decade of BPM“. Phil’s take on where BPM is headed, with an interesting look back:

I can’t begin to convey the impact this will have on how and where BPM will be practiced, going forward. In the blurb above on this blog site (which was posted when I started this blog in 2005), I said that by 2010 process will be the primary prism through which large companies view themselves; and that by 2020 the management of process will be “second nature.” The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.

Phil has a pretty good sense of the big picture.

Second, because Lombardi has focused on the business user, we have also focused on how to engage and support the business user. The work we’ve done on culture, change management, governance and BPM methodology is the best in the industry. Lombardi University and its role-based curriculum, along with tiered certifications and advanced mentoring, means that Lombardi can help IBM scale their business customers more quickly into the world of BPM. Lombardi’s On-Demand Assistance program is also built from the ground up to allow fledgling BPM teams built on business-first principles to still have a technical safety net under them.

This quote illustrates for me what I hope Lombardi can bring to IBM. A better understanding of how to support the business and help them achieve success via BPM, and a better sense of what BPM really could mean for the business world.

UPDATE 12/16/2009 8:45am PST
Austin Startup is carrying the standard press release.

And ebizQ has already launched a forum topic on the subject.

UPDATE 11:35am PST: More great coverage and viewpoints:
Dennis Byron discusses the acquisition, and is focused primarily on eliminating one more option from potential customers, and the inexorable force of consolidation.

Redmonk gives props to the Austin software and enterprise scene, as well as to the deal-making by IBM. The big question is how well IBM can incorporate Lombardi without losing its DNA.

Miko Matsumura posits that this might have been a firesale based on the language of the press release. Could be, Miko has more experience with this than I do. Regardless, I think the timing was good for IBM because I expect 2010 to be a big year for BPM software.

Sandy Kemsley chimes in with the best run-down of the analyst call.

Update EOD 12/16/2009:
David Moser of Australia weighs in. He points out which communities might win or lose, based on this deal going through, in particular which customers. But he also points out:

And with what should be a significant boost to their market, some of the biggest winners could be Lombardi service providers. Watch out for skills shortages.

I happen to agree, that service providers (e.g. BP3) could be well positioned to benefit because, no doubt IBM can sell more of the same product with its much larger sales channel. It takes time for people to ramp up on a BPM product. For a time I expect there will be exacerbated shortages of Lombardi BPM skills, but of course we’ll try to help as best we can!

Bruce Silver also comments on the deal. The tone of Bruce’s post (and some others) is a bit somber – I think some of the folks out there were rooting for a Lombardi IPO or for a deal that made it more clear that Lombardi would still be providing leadership in the BPM space from a “vision” perspective. There is an emerging consensus among outsiders that “departmental” is a losing strategy. I think if it is a pricing/marketing strategy it has legs – potentially target lots of smaller installations to service departments, but if it is reflected in technical direction of the product it could be a real problem. There’s no reason the tech can’t scale much bigger than a department, but its still up to IBM-Lombardi to decide what the market positioning and pricing breakpoints are.

Tony Baer’s take on the acquisition titled “Early thoughts on IBM buying Lombardi“. His emphasis on Lombardi’s chief advantage to IBM is its simplicity – making it possible to address the business directly within the enterprise. He’s looking for the integration of Blueprint and Blueworks to be a good indicator of how this purchase is going to work out.

UPDATE 12/17/2009: Well the blogs keep rolling in with new thoughts or analysis.

Jaisundar’s take is that blueprint is a key piece of the puzzle by widening the user base for BPM and creating a demand funnel. So much comes down to how IBM handles it and whether they keep the Lombardi DNA, while adding to it their massive sales channel synergies.

Meanwhile, Richard Watson has a couple of witty posts on the subject of showers (listing the # of bpm products and related products IBM has purchased as an embarrassment of riches and portfolio overlaps – but also, market clout. In a previous post, he makes the best statement about this subject: “If IBM wants to become the leader in BPM, they need to get out of the data center and start thinking like business people.” – This is exactly why people are excited about the merger, and why they’re worried. Lombardi is not stuck in the data center mindset. Will that business-focus be lost in the merger? That’s the real fear.

And Derek Miers, well-respected for his thoughtfulness on business process and business improvement, took a look at this merger and concludes:

While the choice of dance partner was a little surprising, the desire for a liquidity event in the Lombardi management team was there to see long ago. They touted an IPO around this time, but in the current market that was always going to be difficult.

IBM brings the broad base and ability to grow. Lombardi brings market cachet / credibility that is hard to quantify – but everyone in BPM knows Lombardi and they’re well-respected. Derek’s take on Lombardi’s success:

As I have said to many other vendors, when people buy BPM products, they buy the promise of success. And I am sure Lombardi’s success in the market is as much down to that aspect as it is their leading technology stack. They help their customers understand how they will succeed in meeting their business objectives (rather than touting the beauty of their technology stack).

That’s exactly the point – the culture that Lance and I (and execs at Lombardi) tried to create in the services organization was around business objectives and customer success. Something we’ve endeavored to continue at bp3.

Update EOD 12/17/2009:
Clay Richardson of Forrester Research writes up his analysis, which includes:

Ultimately, this deal centers on the need for IBM to develop a more compelling story for the business. In many ways it is further validation of the IT-to-BT transition that we are seeing within the enterprise.

IBM already had their story down for the CIO and needed to develop a more compelling story for the VP of Operations, and the VP of Customer Service, and the VP of Procurement – in other words IBM needed to establish a stronger voice into the business. And this is what Lombardi does best as a leader in the human-centric BPM space.

If he’s right, this is good news for Lombardi and its customer-base (and prospective customers). He follows up his points with Phil Gilbert’s plan to push the envelope with Blueprint even further “to collaborate on scoping and discovery for enterprise process initiatives.” As he says, IBM is weak in that area, and there’s little overlap. His basic take is that this is a capability buy as much as a technical buy. If he’s right, it bodes well for the future of BPM, or at least the future of IBM BPM!

Update EOD 12/18/2009: You thought we were done with the updates? you were wrong!

Dr. Diaz, on the IBM BPM Blueworks Blog, gives another IBM angle on the acquisition – conveying a sense of confidence and positivity in the IBM strategy.

John Reynolds, of Lombardi and soon IBM, writes a pretty good defense of the “Department” positioning – after all, what is “bottom-up” BPM if it isn’t a department level solution that scales up to meet your enterprise strategy, vs. the top-down BPM approaches that IBM has been using so far:

It’s not really a technology issue – Lombardi’s solution scales quite nicely. It’s a methodology issue… Some tools really enhance the “Top Down” (Enterprise) approach, while others really enhance the “Bottom Up” (Departmental) approach. Offering both seems like a pretty good idea when you think about it.

Update 12/21/2009:
Jennifer Dubow (@jennifer_dubow) posts a link to an IBM F.A.Q. on the Lombardi acquisition. Hits all the high points with no muss, no fuss.

Update 12/22/2009
Neil Ward-Dutton of MWD Advisors recaps the responses of vendors, which generally provide for fun reads. Of course, if you read their blogs without, somehow, realizing their corporate affiliation you might fall for their bias without correcting for it. Its only natural for competitors to see this as an opportunity to try to steal a march while IBM / Lombardi are distracted by integrating two companies – but having been on the other side of this – it didn’t often work as well as we would hope – often the buyer was able to keep the momentum going in the 12-18 month timeframe.

Update 12/29/2009 Jim Sinur weighs in with Power Vendors vs. Pure Plays, positing that the Power Vendors are catching up. I don’t see the catch-up that Jim is mentioning, but I do see catch-up-by-aggregration and the question is whether any of the remaining pure-plays have enough heft to out-innovate the big guys. Obviously small vendors with a tight focus can continue to outpace bigger players in their niche, but the wide Pure Play field has been thinned with this acquisition…

Update 12/30/2009In the ProcessMaker Blog, Brian makes one of the most compelling statements about why IBM bought Lombardi (and although he didn’t address why IBM bought other Business* companies – e.g. iLog, FileNet, Cognos, Webify, etc. – the same logic applies quite well). The short version: it is about addressing markets, not technology. And if Lombardi addresses a particular market, and is scaling, then IBM can plug that into their vast sales and partner channel and really wring value out of it. The thesis rests on the assumption that the BPM market is hot – but that’s a safe one.

Update 01/06/2010 The debate spills over into 2010. Neil Ward-Dutton reprises his previous review with a more considered analysis and the summary is that perhaps IBM really is buying Lombardi to get a better “business-facing” solution – but that they just don’t want to admit that blatantly in their external positioning. Its an interesting read.

Update 01/08/2010Gartner’s Janelle Hill and Jim Sinur report on the acquisition for Gartner. Basically they advise getting ready for a move to Websphere if you aren’t on it already, in a timeframe of two years, and tout the BPM DNA acquired in the Lombardi acquisition.

Related posts:

1. ProcessMaker blog: 3 Reasons IBM acquired Lombardi
2. Lombardi BPM on the Road
3. New Websphere Lombardi Edition Announced

The anti-BPM argument:  lots of cheap labor, 300k+ engineers turned out every year -so why invest in BPM when we can throw bodies at the problem.

The pro-BPM argument (presumably Jim’s take):

While I value lower labor costs, I think the battle is producing higher gross domestic product (GDP) with less hours per GDP dollar. Eventually Chinas cost have to go up. It’s already happening in India. Don’t throw out BPM; throw out the programmers !!! It’s probably different in the west where the labor costs are higher.

Actually I think this is a tension that takes care of itself.  China (more accurately, firms within China) will invest in BPM when they feel the pressure to do so, and likely not often before that point.  That pressure might be higher labor costs, higher quality standards (not all quality improvements can be fixed by more manpower), or increasing pace of change – the same kind of pressures that apply here.  But I don’t think, at this point, that China’s goal should be higher GDP with less hours of labor – that is a byproduct of other good data, not a goal in-and-of itself.

For now, labor costs are not pressuring China to explore BPM, perhaps. But that picture is likely to change as the economy grows in China at a rapid clip.  But BPM is a “pull” not a “push” sale at this point – the customer has to realize they have the need before you are likely to sell them on the virtues of BPM as the way to satisfy that need.

Related posts:

1. Wage Growth in China? Or Just at Foxconn?
2. BPM, ROI, and other TLAs
3. The Promise versus the Innovation

1. Will the SharePoint Processes be Upward Compatible?
2. Will the SharePoint Content be Managed Well?

I think the answer to both is essentially no.  Oh there may be upgrade paths defined, but the ability of the average firm to execute those adequately is probably not high. This isn’t upgrading from Word 97 to Word 2003. All those customizations you’ve made will probably need to be redone/rewritten.

Sharepoint is a bit of the wild west of process.  Slightly better than the random collection of spreadsheets that often are just as pervasive within organizations as the best way they have available to manage their processes.  The proliferation of Sharepoint is, to my mind, a reaction by business users to not having the right tools and training available to deliver real business process solutions to their business.  Often they aren’t allocated IT budget for the applications they need, and so they cobble together solutions in Excel, Access, and Sharepoint.

A few things I’ve noticed about sharepoint “processes” though:

1. Usually very few people understand what the process is supposed to be.  You kind of have to know what it is to leverage it.
2. There are lots of deadwood Sharepoint sites/sections/processes. More than live ones… Making it harder to find the stuff that is “active” – nothing worse than thinking you’ve submitted your vacation form only to find out that the vacation request process has moved!
3. There is a tension between control and chaos that is particularly problematic on Sharepoint.  To get wiki-like collaboration benefits, you need to open up the gates for users to do their own designs/layouts/etc.  But when you do that, you lose the control and policing necessary to make sure that everything in Sharepoint is “managed” in an enterprise sense.

For a more amusing take on Sharepoint and BPM, see a previous post on this blog, noting the 6 major barriers to BPM adoption.  Quoting directly:

The Sharepoint Effect. This is almost the opposite of the Bus Brake Effect.  Where the bus brake effect concerns too many vetos and not enough yes-votes, the Sharepoint Effect represents the unbridled proliferation of ungoverned, adhoc processes using unmanageable technology.  Sharepoint becomes a substitute for process, or a substitute for the Excel-based or Access-based processes of the past.  However, there’s no way to find the appropriate Sharepoint site for the appropriate process or process task. [...]

It isn’t that enterprises shouldn’t use Sharepoint, but the business and IT should be careful not to let the tail wag the dog with the proliferation of such sites… otherwise you run the risk of Excel/Access purgatory part 2.

Related posts:

1. Appian for Sharepoint
2. Process Optimization Revisited
3. SAP = BPM? Revisited