A few days ago, I blogged about a talk provided by Phil Gilbert at the BPM2010 conference.  In that talk, Phil made a compelling case that the smart people who are working on BPM systems and solutions are WORKING ON THE WRONG THINGS.  It was a clarion call to action.  Phil had to leave the conference and head back to IBM headquarters, but I’ve been able to stay and listen to the results.  While I agree with what Phil said, I have not heard any discussions along the lines of “what should we be adding to BPM software in order to address the things that Phil discussed?” 

No one is taking the next step to discuss what changes need to be made, to existing software, in order to meet the challenge that Phil described.  I’d like to take him up on his challenge and describe a way to create an entire BPM stack that would be useful.   First, a summary of the problem.

Phil’s challenge

Phil had been asked to talk about “the future of BPM.”  As a former executive of Lombardi software, which was recently acquired by IBM, he has some credibility on the topic.  His presentation was very well put together.  I summarized his slides to a single image (my apologies to Phil… but this is a blog after all).

If you look at the numbers of people who work in a typical business, you will see that IT folks are a tiny fraction of the total number.  The above diagram tries to illustrate an (arbitrary) eight-to-one ratio.  This is a good thing.  The work of software developers is well leveraged.  For a small number of software developers, their work can benefit a large number of business people.  (Note: for the sake of this conversation, we are assuming that process modelers actually work for the IT department.  The following logic holds true if they do not work for IT, so please bear with me). 

This is nice and good, but…

The BPM tools on the market today provide solutions to business people, but are not designed for business people to actually use to solve their problems.  A business person has to charter some kind of project, and get one of those rare IT people to come sit with them to model their process and build a custom solution.  In other words, IT uses BPM tools.  The future of BPM lies in the world where the business uses BPM tools.  Why?  Because the vast majority of the business value of a BPM solution, according to Phil, comes from the cumulative value of automating a large number of small workflow processes.  Phil called them “Excel and e-mail” workflows. 

And now, here comes the challenge:

Until we work to bring about BPM democratization, we are doing the wrong things.  If we spend considerable time working on the semantics of an OR gate, but we fail to address this concept, we are limiting the reach, and therefore the ability, of BPM to succeed.  Challenge: bring about this change.

My observations

I asked a few folks about Phil’s challenge.  In fact, I asked folks every chance I got.  I find the idea fascinating, but I don’t believe we are all that close to it.  Here is what I noticed:

First problem… the sales model

Most BPM tool vendors have a sales model that goes like this:

1. convince company that they need a BPM tool
2. sell them licenses and consulting services
3. get the tool installed
4. deliver a BPM solution
5. show everyone how valuable that was
   

This behavior creates incentives that drive the spending of the vendor company… incentives that prevent the development of the tool that Phil is calling for.  The tool that Phil is calling for can be sold that way, but it shouldn’t.  The value of a tool that everyone can use comes when everyone uses it… for a thousand little things.  If the BPM solution cannot be installed until there is a big project, then you have a HUGE barrier to getting it installed.  Vendors have to focus on that barrier.  Unfortunately, that means taking away focus from making those “thousand little workflows” work. 

Second problem… one visual language to rule them all

There has been a huge investment over the years in BPMN and in BPEL and, most recently, in the ability to automatically translate BPMN models to BPEL models that, then, produce code.  This is an interesting problem, but one that probably does not need to be solved… at least not right now.  Unfortunately, it is compelling and technically interesting, so it takes up mindshare of the BPM researchers focusing on creating automated models of business processes.  This is a problem because the future depends on creating a large number of small solutions to automate “Excel over e-mail” workflows.  Solutions of that size are mostly people oriented, and don’t require complex modeling languages.  In fact, for business users, they don’t require ANY modeling languages. 

And so we spend tons of time, perfecting a visual language that only the folks in the IT unit can use.  We are solving a problem, for sure, but it is akin to restacking the deck chairs on the Titanic.  If there is a big problem, and we don’t work on it, what does that say about us?

My suggested solution – business and technical

There is a way out of this conundrum.  It involved two key changes.  One is to change the business model of the vendor companies themselves, and therefore to change the software that they develop.  (That’s right, I’m starting with the business model.  Who knew that an EA would do that?)  The second change is to the features delivered in the software.  Serious investment against new features would need to be made in order to pull it off, but there is no scientific barrier… no technical obstacle.  It is a business problem and an investment priority problem, pure and simple.

First off, I’ll put up an illustration. 

In this illustration, there are essentially four business scenario (labeled 1, 2, 3, 4).  For each scenario, the business user is consuming different amounts of software.  The scenarios are in order.  The goal is to capture those business people who will adopt BPM in a viral manner, essentially in this order.  No big up-front sales process.  Users pay for what they need, when they need it.  I will discuss the sales process below.  The scenarios are:

1. Portal only – Most BPM packages include some kind of user interface, most often a web portal, that puts up a list of work items assigned to that particular user.  The portal may have other functions as well, like document sharing and simple list management.  Let’s change the paradigm.  Sell the portal (or give it away).  The user, in this scenario, is using the “non-BPM” features of the portal.  Note that the BPM capabilities are present, but just not being used.  In this case, the customer does not require a license for the BPM engine.  (They may require a license for the portal software.  I believe in integrated products, so I’d expect that the BPM capabilities would be built in to a portal product, rather than shipped as a completely new technology.)
    
2. Use for common tasks – Most portal packages have the ability to set up a “workspace” or a “room” (welcome to “metaphor stew”) that is particularly useful for generic and common types of tasks.  These workspaces are normally focused around some form of collaboration.  For example, you may have the ability to set up a simple “article submission and approval” workspace, and it will come preconfigured with a simple workflow that allows authors to submit articles, while editors review and either request updates, or accept for publication.  Another editor may assign a particular article to a particular magazine issue.  This is good for everything from company or community newsletters to webzines to small-office publishing businesses.  The information captured is stored in an non-integrated data store (although web services can be available to allow the data to be drawn out if needed).
    
3. Use for configured tasks – There are a wide variety of basic tasks that most companies need.  Things like “update customer information,” “update order information,” “review and update employee information,” etc.  The assumption is that this data lives in corporate systems of some kind, and that an adapter must be written to make it available to the web application, but that is all.  A developer would write the adapter, but the product would be shipped with about two-dozen basic adapters from which a developer can crack open the code, make a few changes, and run.  The BPM product would also ship with 500+ mini-applications, ready to go, requiring only a configured data adapter to be written. 
   
   Of course, many companies surround these types of basic tasks with business rules, so the mini-apps must be built in a way that it allows for configuration.  In this scenario, the requirements for configuration happen to match the options built in to the mini-application.  A developer would make these configuration changes.  When a business user wants to use this level of integration, they need to purchase a license for the BPMS.  They get the modeling interface as a result.
    
4. Use for custom tasks – when the mini-applications won’t meet your needs, or they need especially complicated information adapters to be built, you have entered this scenario.  This is the most complicated scenario, requiring the most sophisticated BPMS software.  In this scenario, a developer can start from scratch or from a collection of the “mini-applications” and can build a complete solution from there.  The curious thing is that most existing BPMS products already handle this scenario through rich technology (except most products do not provide more than a few sample mini-applications to start from, and mostly they are not written to be configurable so that you only have to change out data adapters).
    

The beauty of building a BPM package from this viewpoint is that this process of adoption mirrors the way that existing “Excel and e-mail” solutions have come into existence.  Most  businesses follow this bottom-up path already!  It is familiar, if not consciously so, and that makes the sales process much easier. 

The (new) sales model

Give the portal package away for free, or build the BPM engine into a successful portal package and get it into businesses by sending out a “new version” of the portal software.  Make the upgrade painless, to the point of being trivially easy.  The idea is to make all of the pre-packaged common task applications available to business users, as quickly as possible.  Also, make sure that they can see the list of mini-applications that they can use if they are willing to spend money and get their IT department to write some adapters.  Every common app and every mini-app will have a demo video available on your company web site, with links built into the portal product to allow for discoverable marketing.

When the customer’s IT dept want to build their first few adapters to internal data, let them do it for free.  Don’t require a license until the adapter is being used more than 30 times a day.  Even then, let it be a nag to the IT and business users for some period of time.  The license is simply added to the running system and the nag goes away.  Make it easy to click the nag to request the attention of your company’s sales team.

When the customer wants to configure custom business rules or modify the mini-applications, offer really good documentation and then offer consulting services.  Many companies will buy the consulting services.  Others won’t.  Don’t limit the success of your product to those companies that are willing to pay for consulting services.  

Mind the Gap

So what do BPMS vendors need to build in order to bring this approach to life?  Where should they focus?

1. Integrate with a successful portal product.  If you don’t have one among your company’s product stack, find a package from another vendor that is successful and offer to embed your BPM engine into it for free distribution.  This has to be the most important, and therefore, first thing you do. 
2. Create twenty-five or more “common task” apps, with prebuilt workflows and local data management.  Out of the box solutions.  Create a list of a few hundred uses for those common task templates.  Modify the process that a portal user goes through so that they will have the right to select one of these solutions. 
3. Create a stripped down version of your “process state” viewer for the free version of the product.  This is used to track those common task workflows.  
4. Create a taxonomy of data adapters that don’t overlap and from which you can build 500 mini-applications.  (This requires a little information architecture.)   Build sample adapters on top of common enterprise packages for practice… systems like SAP, Seibel, Dynamics, Oracle, etc.  Ship the samples.
5. Create 500 mini-applications that meet actual business needs.  Poll your customers to find as many different specific situations as you can.  Then write a mini-app to match.  Get your customers to write a few, and get partners to jump in as well.
6. Document the mini-applications and make them available to all customers.  Even better, create your very own iTunes-type of store for your partners to sell their mini-applications on.  Make sure that the repository (or store catalog) is automatically called from within the portal product to help your customers find the “newest, latest, and greatest” mini-application to solve their problem. 
7. Get 20 ‘early adopters’ to put in your ‘upgraded’ portal application with BPM installed.  Work with business customers in those locations to get them to set up 50 installations of free common tasks.  Write down success stories.  Use them to market the heck out of the free side of your application.
    

Some BPMS vendors are VERY close to this already.  They may have some horizontal sample apps but no mini-applications.  They may have integrated with a successful portal.  These are the vendors that are the closest to success… the closest to meeting Phil’s challenge.

Last word

I heard many presentations at the BPM conference.  Not every vendor was represented, but of the few that were, they were still offering software to the IT users, not to the business.  In order words, no one was focused on actually solving the problem. 

This post is an open invitation: go fish.