Phil Gilbert | Perspectives in Process
Business process management requires a new set of technologies. By 2010, these will replace ERP as the primary focus of solution engineering at companies large and small. By 2020, managing process through technology will be second nature to senior executives, and the transactional systems we use today will be like mainframes. My blog talks about BPM today, tomorrow and where we'll be in 2020. Welcome.
  Home About Me About The Blog  Search  

« BPM, George Washington & The Dignity Code | Main | One Single Solitary Notion »

Flash: Free IBM BPMS Worth Exactly What It Costs

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?

But this notion of getting "free" or highly-discounted software from strategic vendors has currency. How many times has your company picked up some crap from some vendor because it's on a discount schedule and you have to buy x amount of software each year to "maintain your discount." So let's discuss the cost of software, and the value of software.

Software has no intrinsic value. Nobody buys software for its own sake; it's not like a Howard Finster painting. Software's value is derived solely from the productivity it provides. It has extrinsic value.

Take the iPhone and the Blackberry. I switched from the BB a year or so ago, and found that while my email productivity has gone down on the iPhone, productivity in all other areas (web browsing, attachment reading, etc.) has gone up. So which is "better" depends on the outcomes I'm optimizing for. For me, my overall productivity on the iPhone is better than my overall productivity on the BB. I don't go back to the BB just because it costs less (which it does), because the cell phone is a tool, its value isn't intrinsic, it's extrinsic: the "cost" of the device is a combination of my own time and performance using it together with the money I pay directly for it.

Stated simply: even a "free" Blackberry would cost me a lot more than an iPhone.

The same is true for your BPMS decision: the extrinsic value gained or lost will be much greater than the "savings" on the software. So be sure you understand what extrinsic value a good BPMS can provide, and then factor that against the "savings" of a cheap BPMS that won't provide those values.

The value props of a BPMS are pretty simple:

  1. Lower development costs vs. traditional tools
  2. Increased business performance vs. traditional tools

Reduced Development Costs

You will expend less effort to get a similar process application with a good BPMS vs. a cheap one. Requirements-gathering is easier because business people can participate directly with IT using the same tools. Therefore, the requirements can be explicitly stated and understood, instead of the usual ambiguity of Word documents and white boards; and because business and IT use the same tooling, the business can understand "the art of the possible" more quickly, leading to more productive discussions around scope and trade-offs.

You can't get this collaboration with a bunch of tarted-up Websphere tools available on the cheap.

Building a Better Process

The importance of having business SMEs working shoulder-to-shoulder with IT people on the process application isn't simply about changing the economics of application development, it also leads to better business outcomes. With direct engagement from model to implementation, business people are for the first time able to quickly discover linkages that would be buried or just not thought of. A hospital group in England recovers an additional £300,000 per month because a business person developing a patient process application realized how some patients were simply never being billed because of the way the underlying process worked. This would not have happened if the business person wasn't able to be in the details during the design and development of the process automation project.

The business involvement is not to make programmers of business people. It is to have them more intimately involved in the ownership of their processes and their information that is flowing through those processes. This level of detail is only understandable via the technology tooling. Therefore, the tooling has to be more broadly accessible or the whole value prop is blown.

Because Lombardi uses a shared model, instead of UML and BPEL and Java and God-knows-what-else, the business can understand at a detailed level exactly what it is able to get.

But don't just take my word for it. Talk to our customers, and then get references for those cheap tools (if you can find them). Be sure to ask them whether the applications they built were built using only the tools you were shown... or did they also have to deal with, say, an event handler, a message bus, maybe an analytics package for reports? What else wasn't "free" and, more important, what else was inaccessible to business users?

Ask about all those IBM BPMS references who started an application in January 2009, deployed it in April, and then changed it twice, in May and June. That's the kind of experience one of our insurance customers had, using Teamworks in an underwriting process. This, from an internal review just completed:

"So useful that [we] have already made the following list of changes during May and June as a result of using this scoreboard:

  • Modified 7 rules
  • Added 2 questions
  • Modified 3 questions
  • Added help text to 2 questions
  • Created additional reference materials

[T]he product manager has already requested more data and more reports. This validates the benefits of having visibility to this data. This is precisely what any company needs right now, especially in this economy, visibility into their operations in order to ensure their viability."

Lower costs, faster turn-around, better visibility... a better business outcome because of Teamworks. All in one package, straightforwardly and fairly priced.

Or you can go for the "free" one and pay out the wazzoo.


All these points are eloquently stated but let me say this another way: If IBM thinks that they had a product through which they could extract money from customers they would do so. In fact, they are really into this particular business model. IBM likes to develop software they can sell to customers for cash. They have offered to give away what they have because they can likely no longer sell what they have. They can no longer sell what they have...because it does not work the way they told the customer. is so far away from that point that it can not be salvaged in such a way that is plausible. IBM does not give away software out of the goodness of its heart. It only does so if it has to. Your customer knows that which is exactly why they picked up the phone to recount their story to you.

Deal Shareholders:

We have decided to give away enterprise software that other companies sell for a lot of money.

Good luck,

The Management

Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.

Recent Posts






    Squidoo BPM Lens

Lijit Search