BPM for Users, or BPM for Developers? BPM for all?
- 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.
- 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.