In two terrific blog posts, CIO of the services arm of British Telecom JP Rangaswami blogs about visibility and openness as the heart of process excellence. He talks about documenting the reality of your company - and of your customers' interactions with it - and leaving behind the failed "process" approach of ERP, CRM, SCM (and I'd add EAI, so-called "integration-centric BPM" to the list).

Bravo, JP!

Where you didn't go in the posts, but I suspect have in your head, is whether we should open-source process frameworks and KPIs for companies. While the dirty details of implementation (at, say, the BPMN level and below) are not something most companies would want to share (not because of of competitive advantage but because of competitive disadvantage, disclosing weaknesses in process that could be competitively exploited), I think that higher level process and strategy maps would be valuable to standardize: a tangible Zachman for your industry for example, along with the specific metrics and KPIs that you are expected to achieve. Wall Street is almost certainly already judging you on these (the higher level ones anyway, which have implicit, just not explicit ties to the lower-level ones). Why not just agree on them? In the same way that every company is currently reinventing the wheel with respect to non-differentiating technology (how many redundant WebSphere administrators are there in the world?), companies are also wasting their collective time on drawing the same high level process maps and agreeing the KPIs that are linked to them.

Excellent companies in _any_ industry are process-excellent. The KPIs of these processes are almost always known (most truly excellent companies share them, even with competitors, for they are not "insecure," another aspect of JP's posts I am glad he discusses). Toyota is famous for sharing its methods and results with competitors, for example. These companies compete on their ability to innovate and improve, not on some static state of today's process (of course, certain technical processes, like painting methods, are secret).

Visibility, transparency and a willingness to change (I call this culture) are the key elements of BPM, not execution and workflow. Those are simply two of the many artifacts of where you are at any given point in time on the Process-Driven journey. Great BPM technology should encourage the visibility, transparency and cultural change parts of your journey to become process-excellent... we've already got enough technology that simply encourage how to build workflows.

So read JP's posts (here and here). And for a similar set of thoughts, as well as the beginnings of how to go about achieving this process excellence, click on the picture of my forthcoming book, Process Driven, and you can get a copy of Chapter One, where I discuss shining a light on your company, and the four pillars of BPM.

ps = And for those of us north of the equator, happy first day of spring, when the sun shines its light for longer periods of time on the state of our lawns and gardens. Driven by guilt or desire, we improve them constantly. Then winter's rest, and then they reappear, a little better, the next year. We're in our sixth year at our current place, and each year the garden is in better shape. Maybe it can be springtime at your company, too; it just requires a little sunlight and a willingness to improve.

Technorati Tags: Visibility

Nathaniel Palmer wrote a review of Lombardi's Blueprint that I thought was interesting. So after my conversation on "Enterprise 2.0" with Sandy Kemsley a couple of days ago I thought I'd go back to that.

You see, I agree with Nathaniel's assessment that platform-level BPM-SaaS   (or any other integration-intensive platform) is a non-starter (for the relevant future, anyway).  Like any new technology (for purposes of this discussion, let's assume "SaaS" is new and that it's a technology, both of which are bad assumptions but that's another discussion) it will be mis-used by existing players and only new ideas will bring out its primary benefits.  Remember the move by the mainline DOS players to Windows?  They all died because they viewed this new thing as just a re-swizzling of their old thing... when in fact a new design approach was required.

So if you want to look at the BPM market I think there are 3 or 4 "buckets" that a process platform addresses.

- Modeling
- Execution
- Monitoring
- Reporting

I suspect we could quibble at the edges but generally that's what there is to this thing.  Each of us vendors make implementation choices that we can debate, but the functional buckets are pretty much those four. Let's take a look at what's required for each of those, and where new technology or services could make a difference:

Modeling doesn't require integration and it benefits from collaboration.  Now, there are advanced use cases where integration into and introspection of existing systems will help build scenarios for simulation, but in general, the bulk of the work done in the front-end of the modeling life-cycle looks like an OK fit for something delivered over the web. SaaS is not simply about a scalable way to deliver functionality, it facilitates collaboration if you tap into that part of it. The web allows people to get together to do their human-based work. If the tool you are providing also is easier than competing alternatives, structures data and puts in an accessible place and can hand it to you in a standardized format, then SaaS gives you a very scalable way to deliver this capability. That's where salesforce.com excels: doing something that was already being done but in a better way. In addition to that, if there are new concepts in this tool, then even better. At Lombardi, we think Blueprint is both easier to use than modeling alternatives (like salesforce.com) but also we think there are some new ideas (like integration with our behind-the-firewall BPMS). Easy access at the beginning, and tightly-coupled standards-based round-tripping when you move to execution.

Execution is different.  The aspect of BPM process execution that I find most interesting is the execution that is done to make existing alternatives more flexible.  BPM isn't a rip-and-replace thing where you should be building a new application. In fact, a BPM system should host as little system-of-record data as possible (other than the intrinsic SOR data that execution and monitoring spins off, process analytical data about the process performance... which I think is the most interesting aspect of BPMS-based execution!) If you aren't integrating to legacy systems, then all you're really doing is building a workflow application. Been there, done that, more silos, more support headaches for IT. That's not the process problem for the Global 3000. These companies have significant dollars invested in their systems and now those systems are holding them back.  They can't dump them, their whole business depends on them.   At the same time, these big systems just can't be changed fast enough.   SOA alone isn't the answer, because the problem is not that the system-to-system transactions aren't working... it's the patchwork quilt of systems and humans that want to work together in new ways that aren't able to move fast enough. So service-enabling legacy systems as a part of a larger SOA is a Good Thing, but it's a Good Thing so that you can consume them in the new human-facing processes unified across the new business initiatives. BPM (and SOA) is a part of that.  A BPM layer can be inserted and extended... it is more flexible for new things, and it masks the old thing while making the whole process seamless across the multiple systems.  Well, anyway, the point of all this is that integration of the process platform into your business BPM is heavy, heavy lifting.   If it's not heavy lifting (the low hanging fruit of unintegrated workflows) then all you have is a portal, a form and a workflow engine... you're not doing BPM. Unintegrated workflow applications using SaaS? Sure. Core-process BPM execution? Nope, not well suited to SaaS. (Of course, you could see a path from modeling to unintegrated prototype - one that "executed" - and then a transfer into a behind-the-firewall platform, but to me that's just modeling, so I'd put that up above...)

Monitoring.  This part of BPM gets very interesting and sometimes not well understood.  Not only should BPM offer up technologies that are agile, but BPM is the conduit through which we make business decisioning more agile.  In fact, my experience (from many years pre- and post-BPM) is that being able to make informed business decisions is the longest pole in the tent of agility.  And having good information is getting more difficult because of the morass of systems and silos (Ex-hell, as a customer calls one popular spreadsheet silo...).  So monitoring complements execution and is equally important to execution for almost any process of consequence.   You probably won't execute all of a core business process, but you will have to monitor key parts of it to provide the process-oriented "perspective" to management so they can know when, where, what, who and why of improvement.  The reason is simple: any core process will already have some systems in place to support it. They may not be great (hence the need for BPM) but they will exist, resulting in more integrations, therefore not a candidate for SaaS (again, in the relevant future).

Reporting.    The results of execution and monitoring need to be visualized.  I think interesting Saas-based work may be done here around real-time collaboration and real-time data visualization.  This is an area where a lot of vendors will be tempted to simply put their BI tools into SaaS.    That won't do much in the market.  But there is opportunity here, I think, to use the SaaS platform for something very interesting... the integrations required for reporting databases are so standardized these days - and the performance of modern data warehouses is so good - that some of the technical hurdles that we talk about in the execution and monitoring sections, above, don't exist (although the political hurdles of data access still do).  I am watching this space for interesting developments, though... things like what businesses (like IBM) are doing in Second Life fall into this category, for me. In addition, I certainly would consider a future where a product like, say, Blueprint, might want to visualize the execution artifacts of a product like TeamWorks. Now wouldn't that be Enterprise 2.0'ish!

Well, those are my thoughts on when and where SaaS innovations may play a role in BPM in the next couple of years, and also on how Enterprise 2.0 (so-called) might transpire. Enterprise 2.0 is, to me, about the merging of the public and private delivery platforms accessible by a person in their worklife. By merging these platforms and leveraging each one to its fullest, we can do a better job of delivering the right stuff to the right person at the right time at the right cost. Enterprise 2.0 isn't Web 2.0 because the relative importance of "me" is reduced. As someone pointed out in Sandy's conference the other day, "this isn't communism, we have to think about corporate profit." And as I pointed out, it's also not about anarchy. It's about looking across the landscape of the enterprise and using every technical asset at our disposal, and leveraging it to the fullest. Where BPM comes into play is that it directs the order in which you create this leverage. It is the basis for understanding your business. If you marry these two ideas, BPM directing the Enterprise 2.0 leverage, then you'll be more quickly on your way to closing the gap between your PE multiple and Google's!

Technorati Tags: Enterprise 2.0, IBM, Sandy Kemsley, Nathaniel Palmer

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