What A Tangled Web (2.0)
I just got off an eBizQ panel discussion hosted by Sandy Kemsley. What a ball.. no slides, just good, topical conversation. Speaking of the conversation....
The panel also consisted of Phil Larson of Appian, Ismael Ghalimi of Intalio. The topic was "BPM and Enterprise 2.0" and we discussed, among other things, what the technologies of (so-called) Web 2.0 meant to the enterprise. A lot of people are looking for a fundamental shift in the BPM world, but I don't think they get it at all. Of course these technologies will make a difference in enterprise applications and mission critical processes, but I don't think that's their initial highest and best use.
Process execution (aka workflow) is not the interesting part of BPM and therefore, process execution from "Web 2.0-like" tools isn't the most interesting use of these new capabilities. Not to get all Cluetrain on you, but the main thing these new technologies give us is a new way to communicate, not a new way to integrate!
Behind-the-firewall BPM is about giving visibility into your core processes, and giving you a more flexible way to implement improvements to those processes. Visibility and improvement are non-trivial things. They require thoughtful implementations (not "zero-code" implementations) and they require top-down guidance. If you don't have leadership at the very top of the tree behind you, then you just aren't doing BPM. But how do you structure that top-down view? How do those leaders tie process to high level goals - the goals that if you hit them you'll still be in business and thriving in five years' time? How do you quickly decompose those processes that make strategic impact and determine which ones have the highest impact? And, finally, how do you know when to hand off those decomposed process "chunks" into a robust behind-the-firewall BPMS that offers a shared model with the higher level views as well as the hard core capabilities of an enterprise class platform?
What I've found over and over is that there's no good way to have the top-down conversation! And it turns out that this is exactly what the new SaaS technologies allow!
So my answer to the "what is Enterprise 2.0 and how does it tie to BPM" question? Here you go:
The key stumbling block to real BPM has been the inability to have a structured, high-bandwidth conversation from the top-down about what the goals of the company are and the related processes that impact those goals. Enterprise 2.0 enables that conversation with new tooling that combines the best of social software with a shared process model accessible to and from the behind-the-firewall implementation BPMS.
Enterprise 2.0 is here, but it's not a regurgitation of the old execution-centered (workflow-centered) BPMS's of the past. It's an extension of the process execution and control systems into new areas of the enterprise, enabling new conversations, that dramatically alter the process life-cycle within a company. And then it's the tight coupling of the internet-based capabilities with the behind-the-firewall capabilities so that a new, more flexible breed of enterprise systems evolve.
Agility comes from being able to respond to strategic changes quickly, not the ability to change a random workflow. Enterprise 2.0 enables this - but not by recycling concepts of execution and web services. We're entering a new era, we're not going back to the '80's... this isn't client-server, and it's not just another set of Excel or Access craziness. It's about empowering the individual but in directed ways that (a) contribute to the company's success and (b) utilize scarce resources to their fullest.
Technorati Tags: 21st Century Process, BPM 2.0, Enterprise 2.0, Web 2.0
Subscribe
Phil,
"The point is that nobody will own all execution."
Right and that's why I'm afraid that BPMS initiatives will end up at the same station as EJB implementations.
"But someone does need to tie together..."
I've not seen any BPMS without an execution engine. Yes there are other things to tie together, but execution context is the silver bullet for most of the vendors of a process platform ...
Posted by: Jonas Ekstroem | March 09, 2007 at 11:47 AM
Jonas,
I agree with you... it's one reason why I say that execution isn't the most interesting aspect of BPM... it's visibility. The application vendors, like SAP, will still control significant aspects of execution but that execution is only part of the bigger end-to-end process story. Having visibility into the process should be the main remit to the BPM part of the architecture.
I guess I'd also say that my research has uncovered some pretty interesting data about the actual amount of "execution" owned by ERP vendors. In one case, one of the top customers of SAP - someone you would describe as a 'wall to wall' SAP shop - estimates that [only] 30% of their total transactions are represented in that platform. 30% is a lot, quite frankly. Most big companies have consolidated maybe 5-15% of their transactions into a single data model. The point is that nobody will own all execution. But someone does need to tie together (i.e. give visibility to) all the executed paths of a process so that companies can get better - regardless of what underlying system provides the execution context.
Posted by: Phil Gilbert | March 09, 2007 at 10:45 AM
I would like to agree with you on agility. But that would never be achieved by a BPMS. BPM and process support will most likely be implemented in applications and not by a centralized all-in-one system. I don't think ERP vendors will stand still watching their apps being disassembled into small services orchestrated in a Lombardi BPMS. Who guarantee the SLA of such a composite? Where are the security boundary?
Posted by: Jonas Ekstroem | March 09, 2007 at 10:20 AM
Sid,
You're confusing the conversation with the tool, and apparently you think the tool is _not_ providing insight (ie. "it's just a drawing tool"). Lombardi just released a tool, called Blueprint, that tries to do what you are referring to. So here's my thoughts:
1) Executives in the corner office are vitally interested in understanding their companies through a "process-prism", and existing BI tools (not to mention the transaction systems they get data from) don't do this very well. Blueprint will provide new insights because it has fresh data _and_ fresh visualizations. Will the execs be in front of Blueprint or simply looking at documents Blueprint creates? Does it matter?
2) Yep, middle management is where the top-down work gets done in many respects. I agree, and this is the target user for Blueprint.
3) No simulation? I think you're dead wrong. Scenario planning is hot and it's impactful. Do you not think the head of every company constantly games out the future? The issue is that the world's put us in a box and when you use the words "process" and "simulation" within the same paragraph, people go straight to some heavy tool like IDS Scheer or some such and the ponderous "s i m u l a t i o n" that it does. But simming your business is important, and it's done in non-scalable ways every day by every CEO. What if we can make that better? Is it hard? You bet. Have others tried and failed? Absolutely. Scare me? Not a bit. The time is ripe.
Malcolm,
Well you ask about Lombardi but Lombardi is the company. We've got multiple tools. Blueprint is our SaaS-based offering and it differs from the process modeling tools you mention because it's focused on the business strategy, not on the drawing. It allows you to discover processes, determine how each of their levers impacts the goals of the business, and helps to identify where and when you should optimize bite-sized "chunks" of those processes. Lombardi's execution and optimization platform is called TeamWorks, and it's a behind-the-firewall solution. We think that for many users Blueprint works better than those tools because its easier to do the type of mapping you need to do at early phases of the process lifecycle, and then because it can round-trip using standards, it's data can be pushed to those tools or into execution environments. As the world moves from modeling a process to modeling a business (a move we think is beginning) there's lots of room for tooling. Blueprint hopefully fills a void. If you're a business person and you need to do something faster or with new partners or sell to new customers, we think Blueprint is the perfect starting point.
Posted by: Phil Gilbert | March 08, 2007 at 11:30 AM
Phil,
Good luck! What you're proposing has been (or tried to be) done by McKinsey and the other big firms for years. I don't think an online documentation tool/Blueprint/SaaS is going to have your executives in the corner office spending valuable time in front of a computer terminal anytime soon. The process specific conversations will always happen but at mid-level management. The executive wants to see Business Intelligence - Metrics, Reports and lots of it. Real-time preferably with no simulation please.
Posted by: Sid | March 08, 2007 at 12:59 AM
So if BPM is not about execution.. What is the different between BPM tools like Lombardi and Business Process Modeling tools like CaseWise, Aris, and others, other than the Web 2.0 aspects.
Posted by: Malcolm Ross | March 07, 2007 at 09:32 AM