BPM for Users, or BPM for Developers? BPM for all?
- October 7, 2008
- 0 Comments
Recently I’ve been reading and talking to some folks outside of BP3 about where BPM is going. There’s a movement toward SaaS. There’s been an attempt to provide “BPM to the Business” – directly letting business users configure or build a process. There’s been an attempt to provide more developer-friendly tools. There have been several attempts at a BPM tool that bridges the gap between IT and Business. There is a product targeting broader use of process tools, absent execution. Everyone has a sense that there is something more coming, a Next Wave. But, I don’t sense that anyone is sure they know what it is. I’m voting for the law of unintended consequences. That the raw materials for substantial change in the BPM market (and software market in general) are there, but how that change will manifest is not yet apparent…
So, here’s what I’m coming away with.
- SaaS is fine, but unlike salesforce automation, there are much deeper links required into the enterprise (ERP systems for example) to effect real enterprise processes for the operational and fulfillment sides of the business. We’re still a long way from putting the orchestration of those services outside of the corporate firewalls. Not to mention that issues like latency could doom certain kinds of integration from such SaaS solutions. But, I still think SaaS has a really important role to play going forward…
- The developer-friendly tooling… Let me first say that I haven’t been convinced (yet) that the tooling Intalio is providing is the *right* developer tooling nor that it is the wrong tooling, but I do agree philosophically with the approach as it has been described. That one way to expand the scope of BPM adoption is to make it easier to bake BPM technology into all kinds of software and software development. Of course, badly executed, this strategy won’t matter. But I wish all of the BPMS vendors would provide more developer-friendly licensing (OEM) terms, APIs, and packaging.
- A product addressing broader process community is also a great addition to the spectrum (especially for capturing processes that don’t have an apparent immediate need for automation/orchestration), but I want to focus on execution more than the upstream parts for the moment… perhaps the big change will be about this upstream engagement of the business, but we’ll just have to see. I’m focusing on the downstream/execution environment and how that might evolve.
- The products asking the business to build their own processes and run them sound perfect. There’s just one problem: The Business by-and-large doesn’t WANT to build their own processes from scratch, in a new tool. Its actually hard work to do it right, it isn’t just an excel spreadsheet in most cases, but the excel spreadsheet is the repository the Business might use to store the data that informs the process in their heads. These business-develops-the-process tools miss the point that it is nontrivial to take these ambiguous processes and translate them into something a computer can orchestrate. And the difficult part isn’t the code, its the translation of abstract ideas into a more concrete abstraction called a model, and even further, a model that can be executed.
So by now I probably sound like I see more problems than solutions. Well, in fact I see a lot of opportunity, but I think that opportunity is for a few distinct communities in a way that will benefit all three simultaneously:
- BPMS vendors who make it easier to build software on top of their engines, and who make it easier to develop solutions within their software suites.
- The knowledge workers in our economy who are experts in real processes, and who have the skills to realize those processes in software. I’d call these BPM practitioners with deep subject matter expertise.
- The businesses who have both the resources (in terms of personnel, dollars, and focus) and the will to look both inward and outward and address process in the enterprise.
At BP3 we’re working with vendors and businesses who fit the first and last category, and we’re focusing on building our own skills with regard to processes and how to realize those in software. But we’re also hoping to fit into a potential 4th category: those who have deep process improvement and process definition skills who can act as the grease that makes the other three wheels turn more efficiently. If BPM becomes ubiquitous as some of us believe it will, those who don’t fit into one of these categories are going to be at a disadvantage to those who do.