A roadmap to BPM democratization

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.

Comments

• Anonymous
  September 17, 2010
  I am a developer at a large consulting firm currently working on a BPM project giving advice to the business on how to enable their business people to do BPM development on our BPM product. This is a stark change for me as well as for the business.  Typically, I would come in and work on delivering a BPM program solution.  First I would gather the business requirements, document the process (as-is and to-be), build user stories, determine development tasks, code, review (cycle), get the business to sign off, and launch to production.  I'm an IT resource who communicates between the business and IT at the client site.  But my current project is different – ideologically different.  It is enabling customers on a whole different level. What Phil is talking about here is what some companies (especially my customer) are already realizing.  They cannot spend the time to fill out change orders and contracts every time they need to get IT to update their processes, which change constantly. In the interim, before this next model of BPM you speak about can be delivered, clients that have rapidly evolving business process that require changes constantly and would be slowed down by the knowledge exchange between the business and IT should invest in a BPM Center of Excellence. This center would be a mix of IT and Business that fully understand the processes, the product they’re dealing with, and the fastest path to development.  All process development in the company would get approval from this center and they would be responsible for determine best practices to use, governance, and end legacy system integration guidelines. Phil is spot on where the industry needs to go, but getting there is still a ways off.  Like any industry, there will incremental changes and this is one of those ideological advances that is required.

• Anonymous
  September 17, 2010
  Hi Jacob, I agree with you.   Even with the proposed business and solution stack that I describe, scenarios 3 and 4 will require IT folks to step in and assist the business with complex business process models.  While the nature of that interaction would (hopefully) change through the adoption of successful patterns, the need for a BPM corps, with experts able to assist with complex and difficult tasks, will remain.  if anything, the need may grow as the BPM solutions become more useful, prevelant, and valuable to customer companies.   You are correct that the need for a BPM center of excellence exists today in many companies, and in those situations, an investment in a BPM COE can be immediately valuable. Good Luck, --- Nick

• Anonymous
  September 17, 2010
  The comment has been removed

• Anonymous
  September 18, 2010
  Hi Nick, great graphic and summary of the problem. I would like to offer a couple of comments. Regarding "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." Is the IT person really using the BPM tool from a business perspective of an IT solution perspective? I am going to vote from a solution perspective with perhaps a tinge of the business reflected in their approach? How many IT did you find at the BPM conference? How many IT people do you know that can explain BPM from a business perspective and leave the IT world behind. I suspect it is rare. As a member of the Business Model Generation, I performed a cursory query to gather membership statistics. Of the 1328 members, I found less than 10% identified themselves as an IT professional. I used IT, Information Technology and Software Development as the query to gather my stats. If BPM tools are used to model workflow issues associated with Excel and e-mail then they have missed their audience which means that perhaps whomever helps develop a BPM solution is working with the wrong audience or their audience pool is not wide enough. It would be interesting to get feedback from Alex on the pros/cons of BPM tools. Ideally, I would like to see IT and non-IT use a BPM tool on the same project from their unique knowledge perspective. Somewhere in between the BPM tool should provide alignment, duplication, overlap and gap identification. This could solve a number of issues that continue to crop up in business today. The reduction of busy work, duplicate processes, competing processes, no process etc. I will see if I can get some of the hub members to comment.

• Anonymous
  September 19, 2010
  Hi RHW, You ask: "Is the IT person really using the BPM tool from a business perspective of an IT solution perspective?"   Answer: Who cares!  The point is that the Business person cannot solve his own problem, and has to contact IT at all.  The fact that IT is acting as a proxy for the business is indicative of the problem, not the solution.  Why does the business need a proxy?  Why are our tools so UNUSABLE that we can't let mere mortals use them?   That is the problem that democratization represents.   Phil responded with an interesting blog post of his own.  He takes the ball in a different direction, with BPM-as-a-service offerings.  His approach does change the sales model.  That is good. The jury is out on the problem of creating a thousand tiny solutions, because it looks an awful lot like "bottom-up SOA" and we all know how well that worked.  But if there is an EA involved, and the necessary architecture is created and provided to those direct adopters, in such a way as they don't even know they've adopted good practices, then the abstraction is not leaky and we will get some forward progress.  That would be "middle-out BPM" and would work, based on history.   I'll wait and see what Phil and his friends at IBM come up with.  I'm sure it will be interesting. That said, it is always fun to engage in getting folks to look ahead, design new business models, and test out the potential results. Good luck, --- N

• Anonymous
  September 20, 2010
  I think the argument and points are highly valid and correct - BUT - over the past few years it's been my experience that two issues remain - and they are not directly the fault of internal IT. First, with major Vendor acquisitions continuing there is less of a desire to innovate and more of a desire to purchase. And then - when a company is acquired - it depends on whether the vendor really wants to make that change. IBM is a great example - with their own Websphere BPM, then FileNet, now Lombardi (and sprinkle some cognos spice on there) - will there ever be truly a desire to spend the dollars and innovate for better tools?  or is it more probable that recouping the cost of acquisition is more desireable. Second - it has been my experience that indeed there are business departments who decide to make the change on their own - but what they essentially do is hire their own tech personnel who are not part of IT and allow them to create and innovate with the budgets at hand. For the most part, in large enterprises, it's still a position of "IT is in the way - except if something breaks - then they better fix it asap and they are the problem". There is no partnership or desire to allow all parties involved to focus on improving the experience - and in turn improving the productivity and effort of all involved. Some get it - but I think if you counted the number of companies who use these technologies overall - that percentage of the visionaries is quite small.