Jakob Freund has written an interesting defense of Taylorism, and he makes a few interesting points that I don’t recall seeing in previous discussions about ACM v BPM.

Actually, when I am driving, I am a zombie worker most of the time. Sometimes, of course, there are “unpredictable” events, like a child running over the street, or an alien spaceship landing in the middle of the highway. Then I become a knowledge worker, handling that case with my horribly flexible brain.

No, I don’t mean the point about alien spacecraft, I’m referring to his point that being able to operate on auto-pilot leaves our mind free to focus when we really need to, in value-added situations.

So the bottom line is: Making the world more predictable (yes, it can be done), and then applying axiomatic systems to it, is nothing invented by Taylor and somehow an “accident” of the 20th century, but it is a central component of human evolution. It has always been there, and it will always be there, as long as people are interested in less work and more free time.

This is also an interesting argument.  A bit too much credit has gone to Taylor over the years for putting into words what might already have been in progress.

The central thesis seems to be that reducing “knowledge work” to scalable process work is one of the key imperatives of scaling a business.  It is an interesting take on things, and fits a lot of the process efforts that focus on efficiency as a goal.  And it is a refutation of much of the hype around ACM as being something shiny and new.

Alberto Manuel’s End to End BPM blog lists BPM Blogs worth reading in 2011 – linked here in case you don’t follow his blog directly or haven’t seen his posts on twitter.  He lists some of our favorite blogs, including Sandy Kemsley’s and Anatoly Belychook’s blogs.

There are a couple on the list I haven’t been following which I’ll now be checking out.  Thanks to Alberto for putting this list together!

ebizQ has an interesting two-page article on BPM and Healthcare titled “BPM: The healthcare industry’s prescription for serving patients better“, which uses the label BPM broadly (not specifically meaning “BPMS”):

For example, Nunn says, one facility used BPM to reduce the number of patient falls—a common problem among elderly people and those recovering from surgery. After analyzing data, the facility changed the layout of its beds so nurses could better keep an eye on patients when they got up at night to use the bathroom, which was when most falls were recorded.

In another case, Nunn worked with a hospital trying to pinpoint why many of its heart-surgery patients were getting infections. By examining the entire process of surgery from admittance to discharge, Nunn’s team was able to determine that an autoclave, a machine for sterilizing instruments, was not working properly, even though its gauges indicated that it was reaching the proper temperatures. After the hospital replaced the machine, infection rates plummeted.

As I’ve said at other times, there’s a place for more “case” oriented approaches in hospitals and healthcare, but the case approach would *never* address changing the layout of beds, nor determining that the autoclave isn’t sterilizing sufficiently.

To those that think that examining aggregate outcomes is irrelevant in patient care, I’m telling you, you are missing the boat.  Note that the above two examples I picked out don’t necessarily require BPM (six sigma analysis likely would turn this up), BPM can be the instrument for collecting and analyzing the data that allows the six sigma (or other experts) to determine root cause – or failing root cause, at least to identify correlation.

This isn’t the first time we’ve pointed to good work by others, documenting the benefits of BPM to the healthcare business, and I’m sure it won’t be the last.

David Brakoniecki wrote a great post on “those pesky rules” last month and I just had to comment on it.  The startling finding was that at one insurance company, 30% of the rules were flat wrong.  As David says:

Given that the insurance business is really little more than sets of rules – underwriting rules, claims management rules, customer cross-sell rules – and that it is a heavily regulated business, incorrect rules are more than bad business but potential regulatory nightmare.

Bingo.  The problem with rules is that many of them are simple, but the interactions between them are not.  The resulting outcomes are not.  There are better ways to represent these kinds of solutions (constraints, heuristic search, etc.) but they require pretty advanced education to model, and most companies are looking to de-value expertise rather than invest in expertise. So simple rules are used – simple in each instance, but complicated when taken as a whole. Unpredictable as well.  The right abstractions are not available for modeling, so granular abstractions are used, and they’re just not good enough.  It becomes unmanageable or inaccurate over time.

As Dave goes on to say, it just isn’t realistic for the business to maintain rules without assistance from IT.  We have to get past the idea of IT or Business owning the assets of the business.  Both parties need to take responsibility for the health of the business and the health of the assets that allow that business to perform smoothly, or at all.

I love the Graphing Calculator Story.  It is an oldie but a goodie.

When I hear people (you know who you are!) lament a lack of corporate sponsorship as dooming a project to failure, I want to send them this blog post.  Ron Avitzur didn’t even have a *job* and he got his project done and shipped.  He lists out a litany of roadblocks in front of them – and yet he managed to cajole others into helping him.  To get others excited about his vision for the graphing calculator.

It is a classic example of leadership from below, or leadership from outside.  No one reports to him, so he can’t command a change.  He has no official status.  And yet he is able to mobilize resources by creating a buzz, by being honest, by having passion about his work.

I’ve often been a proponent of leading from below.  If you’re successful, the executive sponsorship will come.  Typically it doesn’t happen the other way around.  So quit making excuses and be the change you want to see in your organization.  Read Ron’s story for inspiration.  No excuses now – we’re getting paid after all! (Unlike Ron!)

Bruce Silver reports that IBM is following through on its promises with respect to BPMN 2.0 in its next release, IBM BPM 7.5.1, which ships this week.

Not that IBM is covering EVERY corner of BPMN 2.0, but it is a significant advance – in that they are surprisingly supporting import and export of BPMN 2.0 XML from the Process Designer:

In a recent post, I talked about what “BPMN 2.0 support” really means, in both non-executable and executable model contexts.  It’s not primarily about the notation, although a few shapes and symbols – notably non-interrupting events and event subprocesses – are new in BPMN 2.0. BPMN 2.0 support is really about the XML serialization, the ability to export the process model according to the XSD and rules of the spec, and ideally import from the XML as well.  IBM BPM 7.5.1 can do both.

[...]

The important thing, though, is not just the palette of shapes but the fact that Process Designer supports export and import of the BPMN 2.0 standard XML format.  (Oracle BPM 11g has had the BPMN 2.0 shapes for a year and a half and still cannot do that.)  I haven’t seen the XML yet but I believe that the export includes data objects, data inputs and outputs, data association mappings (assignment), and other details of executable BPMN 2.0. At least I hope it does.

A few new palette items have been added as well, though as Bruce notes, we’re still missing explicit representation of message flows.  I happen to agree with Bruce that this could improve the readability of IBM BPM models. And knowing how things are implemented underneath, I believe I’m qualified to say there aren’t really any technical barriers to having this “transparently” implement message flows, except to update some of the assumptions that go into the process canvas.

Great news, and great recap from Bruce.

In a flurry of posts recently there’s another attempt to sever ACM and BPM.  It’s a strange urgency among some ACM advocates to separate it from the idea of managing business processes.

Keith misinterpreted my recent post on ACM/BPM – confusing product efforts by software vendors with implementation and execution efforts by business users.  Bruce Silver and I are speculating about whether “ACM” will really exist as a distinct market from BPM – and we both doubt it.  Keith is questioning whether doctors and lawyers should use BPMN.  A bit unrelated.

In another post, Keith attempts to put the wheels back on the track.  But Adaptive Process advocate Max J. Pucher notes that he sees a benefit to customers in a holistic solution – and goes on to advocate his own company’s approach:

Therefore I do not see a clear distinction between ACM and BPM, except that a BPMS cannot perform the kind of ACM user-driven processes that you describe so well. My recommendation of a homogenous system that does both really well is not only driven by my product orientation. Remember? I don’t have to sell what I have – I develop what empowers people!

I see it the opposite way: The only reason people have to keep ACM and BPM as independent functions are sales perspectives or BPM design or consulting skills that might become obsolete. From a business benefit perspective, a homogenous solution that also encompasses architecture, content and rules is the only thing that makes sense. Agree? Whether this is easy to sell or argument from an existing BPM mindset is a completely different story.

If it is a single solution, it really doesn’t matter if ACM and BPM are separate or the same.  It just matters whether you can solve the problem for the customer – or not.  Or if the customer can solve the problem for themselves – or not.  I believe Max’s firm is in competition (in a sense) with BPM vendors – because they’re both competing for a market around improving business processes.  Max’s competitive differentiators are related to the adaptive way his firm approaches this subject.  A company like IBM will pitch different differentiators for their product offering.  They may coexist in the market or within customers, or they may compete.  But so far this looks like one market to me. I might have more faith in BPMS based on my personal experience, than Max does – but in the wide angle view I see more agreement than disagreement in terms of what BPM is (versus what a particular product can deliver).

Jacob Ukelson proposes to call this area “knowledge process” instead of ACM.  I expressed a bit of my frustration with this distinction, though I generally sympathize with his frustration as well! -

As I mentioned on twitter, I don’t think the problem is that they got in the weeds on features. The problem is that ACM folks got too caught up in trying to prove that BPMS can’t do ACM – which is silly. Or worse, that ACM was superior/above/better-than BPM – which again, is just a silly argument to get into. Like arguing that BPM is better than SOA – they’re either complementary or competitive and if they’re not competitive than better doesn’t really have meaning.

Knowledge work is business work, last I checked. business people describe knowledge work as being part of their business processes. Fighting a definition battle that isn’t worth fighting. Go ahead and convince customers that they don’t have a sales process. That it is, instead, a sales knowledge process or a sales case management. Or that they shouldn’t apply process improvement techniques to aggregate outcomes.[...]

I keep hearing from people about what isn’t the answer… but not hearing much about what is  unless it is a plug for “read the book” or very high level – as you say – principles – which of course could just mean “use email”.

I think the ACM discussion has been useful in that it reminds people that BPM shouldn’t be just about automation and eliminating human work. But to me, separating ACM from BPM is a bit like saying that what’s good for the goose isn’t good for the gander- that some work (usually whatever work we envision ourselves doing) isn’t subject to the same general rules as the work others are doing. My work is creative, but their work is not. My work is knowledge work but their work is routine.

I promise you, all work that involves people involves creativity, passion, skill, energy, pride – or the lack thereof. Our goal should be to reduce the mundane and routine, and allow the people to focus on the creative and expressive and decisive. We could argue over ACM vs. BPM or just agree that BPM and ACM are two slices of bread in the same loaf.

Just because I don’t use a BPMS to tie my shoes doesn’t make it knowledge work.  Nor does it mean it isn’t a process.

I got a kick out of reading Ben Farrell’s post on Appian’s blog today,  “What a Difference a BPM Software Acquisition Makes: A Look into the Wayback Machine“.  I think Ben thinks he’s really caught out Phil Gilbert, formerly President and CTO of Lombardi, now VP of BPM at IBM:

“Today one of our customers said they were told by IBM: “why spend your money with Lombardi, we’ll give you our BPMS for free.” I finally agree 100% with IBM on something: their BPMS is worth nothing. Getting a cheap BPMS is like buying a dancing elephant for a dollar: cool, but who can afford to feed it?”

That’s Phil Gilbert talking. Or rather, Phil Gilbert back when he was president and CTO of Lombardi. Today’s Phil Gilbert is head of BPM at IBM. Say it again, Phil: “Their BPMS is worth nothing.”

And then later on he takes on the new IBM-Lombardi combination, IBM BPM:

The fact is that nearly two years after its acquisition of Lombardi, IBM has still failed to outline a clear path for its BPM customers. Yes, it made a marketing-oriented announcement about a roll-up of its disparate BPM portfolio into IBM BPM 7.5, but that is a unified offering in marketing-speak only.

I wonder after reading this if the only wayback machine is Appian’s blog publishing.  Maybe this is something they wrote in 2009 when the acquisition was announced?  or in 2010 when many analysts were unhappy with IBM’s lack of communication about the plan for Lombardi and WPS integration?  Or in 2011 springtime when Clay Richardson dissented from all other analysts and customers present at Impact by referring to the integration as “a new coat of paint”? At any of these times, Ben could have piled on with his post in a (somewhat) timely fashion.  But no, two years later he’s finally hit “publish”.  Maybe he missed all the Lombardi and IBM news the last two years and is just trying to catch up?  Maybe he’s just burned about losing a deal to IBM?  (this post also reads like a “mad because we lost a deal” post) Or maybe he doesn’t like Phil.

Appian has some good things going for it, and they made a bet on mobile/cloud that was “early” in the BPM space, relative to competitors.  But this whole David vs. Goliath thing is a bit of an art.  Phil was pretty good at it, Ben still needs some work – more edge, less sour grapes.

Regardless, he clearly doesn’t understand what happened vis-a-vis IBM and Lombardi.  Lombardi was, at times, in heated competition with IBM.  Given that IBM bought Lombardi, one could infer that IBM learned a bit about BPM from Lombardi and Phil, and realized that there was another take on BPM in the market – Lombardi’s – that would be better received than IBM’s current portfolio, and would create more value with IBM’s resources behind it for both IBM and Lombardi shareholders and customers.

If you look at IBM’s BPM vision (also commented on here, and here, and here) – which Ben derides without knowing it – IBM has adopted Lombardi’s vision of BPM and added some pieces to the puzzle that create additional value (ILOG, Integration Designer, the message bus, Business Monitor, etc).  And the key thing that IBM and Phil had to do when bringing Lombardi and WPS and ILOG together was not a technical problem, it was a business problem.  They had to define the go-to-market strategy – edit the value propositions to a manageable number that IBM’s huge sales force can really leverage.  Of course lots of development effort went into creating IBM BPM – but to get the integration “right” without understanding how to take the products to market would be an utter failure to the market, customers, and shareholders.  Now, it could have gone the other way.  Lombardi might have been swallowed up by IBM, discontinued, and chalked up as a “technology buy”.  But it wasn’t.  It became the centerpiece of a new strategy and BPM go-to-market for IBM.  Phil did get the change he wanted – from the inside.  And that change is ongoing, with a few more surprises yet to come.

Customers aren’t “forced to figure out their own path” – the upgrade path is clearly defined and actually well-supported by IBM.   Unsurprisingly, Ben’s role doesn’t include knowing the real story behind IBM’s products and strategy.  That’s not corporate communications’ job.  But you’d think he’d be a little more timely with his shots across the bow, if not more accurate in his firing solution.  I tell you one thing, I know what corporate communications folks are really good at: cherry picking.

Bruce has left no stone un-turned in his review of IBM BPM 7.5.  In his words:

IBM is the big dog in the BPMS landscape.  BPM 7.5 combines the old WebSphere Lombardi Edition and WebSphere Dynamic Process Edition (aka Process Server) in a single offering.  More than two separate products in a single box, there is real integration under the covers, in the form of a shared Process Center repository.  Find out all about it in my latest Industry Trend Report, available here.  You’ll need to be registered on BPMS Watch to access it.

Registration is simple but you might miss the link in the lower right-hand corner of the site (or just search for “Registration” on the page).  It is a comprehensive report and if you’re considering IBM BPM, this is worth a read.

Bruce Silver, never one to shy from a debate, weighs in with a post I largely agree with:

The question is BPM part of case management, or is case management part of BPM? is a metaphysical one.  I think, however, it is a proxy for the real question, can a BPMS do a good job with case management, or do you need a special dedicated tool?  It’s obvious that if a single offering could provide both, users would prefer it over separate dedicated offerings.  And it’s equally obvious that it can be done, although it’s fair to say that the offerings may not be good enough yet.  Back in 2005, people said you needed separate BPM platforms for human workflow and integration processes.  It was just a matter of time, and not that long a time.

In one paragraph, I think Bruce has succinctly cut down 90% of the noise:

1. This is a metaphysical question. In a practical sense, who cares.
2. To the extent that people care, it is because they’re substituting this metaphysical / philosophical question for a practical one: “Can a BPMS do a good job with Case Management?” (or ACM)
3. Everyone understands customers would like to have one tool that does both. And makes breakfast.  Thus the fear and uncertainty and doubt about this issue among software vendors.
4. Anyone who can code worth a lick can see that it can be done. But as Bruce says, there’s a lot of room for improvement on most of the tooling out there.
5. History suggests the ultimate answer.

He then moves on to discuss how a case might be different from a process.  Overall a great read.

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

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

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

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

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

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

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

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

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

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

John Reynolds writes about the curious case of the disappearing BPM Programmer:

So where does this distinction between Case and Process leave the BPM Programmer?  Are BPM skills irrelevant in the new world of Dynamic Case Management and Social Process?  Are the BPM Programmer’s skills doomed for irrelevance every few years just as the skills of System Programmers (C begat C++ begat Java begat Ruby etc.)?

Will BPM Programmers disappear into the mists of interesting but irrelevant oddities of the past?

The question arises simply because a small but vocal chorus has been calling BPM a subset of Case Management, or predicting the end is near for BPM. Does that mean BPM skills and jobs are thus in decline?

Not to worry.  BPM was always the tool not the goal.  The goal is managing business better.  As the Navy Seals would say, equip the man, don’t man the equipment. BPM is a means to an end.

Processes aren’t going away anytime soon.  Besides, as John says: “Your job has always been about writing software the Manage Business. Process is at the core of Business Management, but you always had to deal with Objects, Rules, and Events.”

Well said.  BPM is here to stay.  It didn’t burn brightly and fade away, it is a slower, steadier progression.  As you would expect it to be, if you understand what it is.  And the momentum is still building, rather than fading.  The name may change, the tools may evolve, but the goal of running businesses better isn’t going away.

Jacob Ukelson writes:

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

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

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

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

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

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

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

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

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

I was surprised to see Lexmark acquired Pallas Athena.  I didn’t realize that Lexmark has a software unit, Perceptive Software.  The consolidation in BPM continues… Pallas had a good reputation in the market, in particular for being able to “mine” data for the emergent processes within it:

Pallas Athena is a leading provider of BPM, DOM and process mining software, with significant industry experience in the insurance, government and life sciences segments. Pallas Athena’s software products enable a broad range of BPM capabilities, which includes dynamic case management and customer communications management. Key differentiators of its software products include ease of implementation and an intuitive user interface.

I can’t comment as to how well Pallas Athena fits within the portfolio of Perceptive Software/Lexmark, I’ll leave that to others with more specific information.

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

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

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

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

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

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

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

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

I missed this update due to a busy work schedule last month, but the September update to BlueworksLive has a few interesting tidbits:

• Better Word document export options (allows including subprocess details, and increases the amount of detail available on a given process).
• Customized Branding – so that you can have BlueworksLive reflect more of your own company’s branding rather than IBM/BlueworksLive’s branding… I’ve experimented with this for BP3 and while it does work, you have to have a really good transparent logo at a height of 45pixels… not a lot of room to work with if your logo is taller than it is wide.  But it does let you change up color scheme nicely and also customize the logos included in things like document exports (a big plus).
• And single sign on- which allows you to configure the issuer/entity ID, the email domains, login page, etc.  That’s a great feature for enterprise customers who don’t like to have to administer additional login/pwd information.  (This feature is in limited roll-out, but you can contact their support team to expedite access to it).

This blog post itself is probably just in time to pre-date the next BlueworksLive update!

About a month ago, Sandy Kemsley attended Progress Revolution – first giving an intro-to-BPM course and then blogging about the sessions she attended.  The whole series of posts is worth reading, and I thought a few highlights from her coverage might convince you to read more…

On the importance of BPM (and CEP) to Progress, from opening remarks:

In spite of Progress’ long history with their OpenEdge software development environment, it’s clear that much of their future success is based on the Apama CEP and Savvion BPM acquisitions, and the integration of these product functionalities into a comprehensive solution.

On OpenEdge development methods and how they relate to BPM:

Does the integration of BPM just relegate OpenEdge to the scripting/coding language slaved to BPM? Maybe, but that’s not necessarily a bad thing. Instead of layering BPM on top of a monolithic application developed with OpenEdge, it’s about having an integrated development platform that includes BPM as a part of the toolkit. It will be interesting to see how well this message is received by the OpenEdge development community, and how long it takes to actually impact their development methods.

And, we can see that Progress took a similar approach to integrating BPM acquisitions as IBM did:

Although (Savvion) BPM Studio and the OpenEdge Architect development environment are both Eclipse-based, it doesn’t appear that they’ve been integrated in any significant manner. Similarly, there are two different servers – although a BPM process can call an OpenEdge functionality, using web services at least – and two different end-user portal environments, where the BPM server functionality can be surfaced in the OpenEdge portal.

This approach drew a lot of fire from analysts covering IBM’s integration a year in, but I don’t see the same angst in coverage of Progress-Savvion after 18 months.  In fact, I’d say although Progress has the same approach it doesn’t look like they’re quite as far along implementing their strategy.  I’m not saying there should be angst – I think both companies are simply taking realistic measures to integrate different product lines.

On her realization that this isn’t a BPM vendor conference, during her coverage of Dr. Ketabchi’s talk:

…which really drives home that I’m not at a BPM vendor’s conference, I’m at an application development tool vendor’s conference where they are introducing this hot new technology called BPM. This is, of course, the stage that most of the business world is at with respect to BPM understanding; I’m just so used to being in the BPM echo chamber that I rarely hear these messages unless I’m delivering them to a client.

Great material across 7 or 8 posts! Thanks to Sandy for capturing this for those of us who couldn’t be there in person.

IBM has already an update to IBM BPM 7.5 scheduled- the first minor release, due 18th of November, 2011.  The meat of the release is reviewed in the announcement letter:

• Ability to deliver differentiating BPMN 2.0 support while keeping the user experience simple
• Simplified event management in Process Modeling
• Ability to import and export of industry models directly into or out of the Process Center using BPMN 2.0 format
• Simplified installation and configuration experience for production deployment environments
• New refactoring features for process application and toolkits
• Creation of process application documentation that can be reviewed and printed by business stakeholders
• Ability to view change management history between process application versions
• Integration with IBM Case Manager tasks to enrich case management applications
• Common inbox with IBM Case Manager V5.1

I think the key improvements for the average user of IBM BPM 7.5 will be the refactoring and difference reports.  They look like small changes separately, but together this really improves the productivity of process developers who are managing multiple versions or who are working on a new version of a process while also supporting a production version. Not to mention, better refactoring support will cut down on the number of typos. There are some additional features that are focused on supporting production instances which will also prove important over time.

I think this post by Activiti‘s Tom Baeyens reveals a blind-spot in the folks behind open source BPM tooling.

To be clear: it isn’t a bad post, and I agree with his conclusions!

Which are, summarized:

• “hosting traditional BPM engine on the cloud is a big technical challenge with a relative low value for professional consumers”
• The data manipulations required by BPM’s automated steps are too complicated to expect professional consumers to design in a webpage (the example given was getting contents from a spreadsheet into a pdf document).
• “On the other hand, the trend to Advanced Case Management (ACM) really fits well into the cloud.”
• “Dynamic management of tasks without a predefined flow matches perfect with the professional consumer needs and capabilities.” (Author’s note: whether you call it ACM or BPM, we understand what Tom is getting at here. )

So if I agree with his conclusions… what’s the problem?  Just that commercial companies have come to these same conclusions a few years earlier – and open source BPM projects have been more focused on building the engines than on exactly what the deployment architectures will be – and what the implications on product direction would be if you change those deployment choices.  So, it has been a blind spot – but that isn’t the end of the world. BPM in the cloud is still in its very early stages.  Even “ACM” in the cloud is in its infancy. Activiti (and others) have time to address the blind spot, and maybe something new and interesting will come out of new entrants to that combination of cloud and BPM/ACM. I’m looking forward to see what Tom and the team working on Activiti come up with.

Tom’s writeup also confirms another conclusion I’ve long held about “ACM” as software implementation- it just isn’t as technically difficult to produce as a BPM platform (throw out all that integration stuff for example, and any notion of structure).  That isn’t some kind of badge of honor to be “more difficult” – it just means it may not be very defensible for a software company to build around, and it tends to look like a toy to customers, rather than a serious enterprise product that stands on its own.

William Band, of Forrester, asks: “Are CRM Solutions Soon to be Displaced by Dynamic BPM?”:

Increasingly, companies are using business process management suite (BPMS) or dynamic case management (DCM) solutions as the primary point of entry for strategic, cross-functional processes and view individual CRM functions as supporting administrative processes. However, taking advantage of these solutions may require a higher level of process management maturity and skills than is typically found in many organizations.

But really, if you’re asking yourself a question in the form of: “What systems can we replace with BPM?”, you’re probably asking the wrong question.  Of course, existing systems or software categories might get displaced by BPM in your organization.  But that isn’t the starting point – it is only a side-effect.  You start and end with a process, and focusing on the best way to start it, execute it, and finish it.

If your CRM system is the system of record, and you need to layer more process, or better process, or more dynamic process on top of it, so be it. But that typically doesn’t require ripping out the old CRM system.  But what about small or medium-sized businesses?  Are small businesses going to turn to BPM instead of SalesForce or SugarCRM or other similar tools?  I don’t the CRM space is in any danger, per se, from BPM  (or its variants).

On the other hand, if Mr. Band is really asking “is BPM where the action is in CRM?” – then he might be on to something. BPM is influencing traditional Enterprise Software and approaches to managing the silo-ed business functions that it supports.