BPM Vendors: Too Broad?
- December 17, 2009
- 1 Comments
Rashid Khan, formerly of Ultimus, asks the question: is BPM the jack of all trades and master of none?
It is certainly a fair question. As he points out, BPM is broad, maybe overly broad. And he also points out that based on the punditry, you would expect BPM to be a much bigger market than it is today. Of course, part of the problem is that many companies, wanting to leverage the BPM banner, will relabel what they do as “BPM” and this can help stifle the growth of the real BPM providers.
He then outlines four challenges for vendors:
- The market, defined as the sum total of all the things BPM can address, is very large.
- No single vendor or product can address the entire market. And if they try to do so the product becomes bulky, expensive and hard to maintain or upgrade.
- Customers have a very hard time discerning what BPM solution is best suited for their needs. And if there is one product that will suit their needs, it is unlikely to meet some other needs in the same organization.
- Vendors are unable to say no to opportunities that potential customers define as BPM but do not fit in the profile of what the vendor can deliver. BPM products always have recourse to customization via programming which theoretically can be made to do anything, albeit at the cost of agility. So vendors pursue opportunities that may not make sense.
Its hard to argue with these points – points 1, 3, and 4 I can agree with without much reservation. And #2, I would say it is actually a tough choice for the vendors: either bulk up the product to address these markets, or keep the product more focused but leave a lot of work for the customer to adapt the product to their needs. Either path is risky.
Rashid proposes that vendors focus on horizontal slices of BPM (e.g. modeling, or workflow automation) and interoperability, in order to solve the focus problem, and in order to help customers answer the “what does it do” question…
But this conundrum affecting BPM affects the software business as a whole. CRM companies wonder if they should also be sales process companies, and vice versa. MRP companies became ERP companies. ERP companies became “Stack” vendors. And before ERP was well-defined, there was a lot of jockeying for what was “in” or “out” of ERP.
The key economic forces compelling software companies to broaden their offerings are:
- The need to avoid getting flanked by a competitor who does your focused product, but also does other products.
- The need to flank your competitors in similar fashion.
- The need to get the most value out of your sales force overhead that you can – more products to sell means that the sales rep has more opportunities to take advantage of their good relationships by selling more software.
These are essentially sales-efficiency arguments- you have spent a lot of money on your sales force. So what you can you do to extract more expected revenue from them? Either:
- Increase the odds of winning a deal (flanking/positioning)
- Increase the lifetime revenue per customer (more software products/licenses to sell)
- Increase average sale per transaction (more software products/licenses to sell)
So these forces are pushing software companies to broaden their offering with either features or products. Simultaneously, the approach of having a narrow focus is risky: if you can’t create a compelling differentiating advantage for your horizontal slice, then you can get disintermediated quite rapidly and easily. But if you CAN build this sustainable competitive advantage, and get the market to recognize it, then you can build a nice moat around your product line and really benefit from your focus.
The other trick is – say you only sell the optimization piece – and it is designed to work with various BPM tools – if you are early in a market’s development, you could face the very real risk that the customer isn’t even sold on BPM software yet, let alone your specific tool. You still have the problem of explaining BPM to them, and getting them to realize that it could be of benefit.
I think as the BPM market gets larger, there will be interesting horizontal and vertical opportunities for software companies to say “look, here is the better mousetrap for optimization” and to then show how it is better than the existing solutions and get it sold as a value-added piece of the puzzle. This is (roughly) how scheduling software was briefly the darling of enterprise software in the 90’s – before all of the fast-growing scheduling companies hit the wall and were acquired by larger ERP companies.
It looks like BPM may already be big enough for a good horizontal BPM modeler to come along and steal the show – but one wonders if that play will be a commercial or an open source play? Similarly, a process engine could OEM into other BPM software vendors, if the market gets big enough. But I think that expecting customers to piecemeal these solutions together is asking too much these days of their lean and mean IT departments. The integration will still have to happen with the vendors.
What’s really interesting is, if BPM vendors have trouble with the broad scope of BPM… what does that say about the vendors who consider BPM only a checkbox on their list of 1000 products? They’ve got to compartmentalize if they’re going to realize the focus they need. Or, I guess you could buy Phil Gilbert and Lombardi to get that “vision and focus” thing you’ve been missing… I’ve always thought the main barrier to stack vendors “getting” BPM was (a) a lack of focus, and (b) lack of believing that such focus was necessary or worth it, and really it isn’t a lack of technical know-how or capability.
So, any BPM vendors out there following Rashid’s advice and getting more focused, more narrow? or staying narrowly focused?