Let me start by referencing an old article by Tim Bray. Tim says that there are essentially two ways that technologies can get introduced into the market: the front door and the back door. "Front door" technologies are bought high up in the organization to solve a business problem or strategically reduce costs. Examples include ERP systems, CRM systems, and application servers. "Back door" technologies are snuck into the organization by sysadmins and programers to solve day problems or reduce tactical, day to day, costs. Examples include Linux, Perl, and and PCs. (Of course, technologies can cross from one category to the other: application servers used to be "front door" but open source J2EE servers have led to "back door" culture as well. PCs used to be "back door" but have become so commonplace that they are dominated by "front door" purchasing).

Spreadsheets were unquestionably a back door technology. A department manager expensed a copy of VisiCalc, 1-2-3, or Excel and wrote his own sales foreasting spreadsheet. Other managers found out about this spreadsheet and built or copied their own version. Management hates the spreadsheets because there is no way to "roll them up", because manager has their own one-off version, and because the data is vulnerable to loss and theft because it generally lives on the managers' laptops. So management tries to push a CRM based sales forecasting system. Success varies from organization to organization, but generally results in department manager's copying and pasteing from their spreadsheets into the CRM system on a weekly basis. :-)

One of the challenges of the BPM market, and the reason that I believe BPM has taken so long to bloom, is that it doesn't fit very cleanly into either category. On one hand, BPM delivers power directly to the business and is very "tactical" in delivering immediate solutions. On the other hand, BPM is sold in a traditional enterprise software model (high upfront license costs, enterprise salespeople) and requires the cooperation of IT because of the needed integration and maintainance. This requires a traditional "front door" approach full of RFPs and cross-functional teams conducting PoCs.

Hopefully you can see the conflict here. If BPM is going to be sold as enterprise software and integrated into IT systems it needs to have IT's blessing. A blessing which it isn't going to give if BPM will result in a rat's nest of processes that it has no control over. But if the business is going accept BPM (and give up the existing paper, email, or spreadsheet based processes) then BPM has to be a little bit subversive.

Now there are several ways to deal overcome this paradox. Some companies have tried the open source route. I believe this is fundamentally flawed as a strategy. The sysadmins aren't going to be able to sneak an open source BPM solution in the door the way they snuck Linux in the door. BPM requires too much enterprise integration and has too much end user visibility. Not to mention that open source has been traditionally weak at some of the key requirements of BPM such as documentation, end user appeal, and enterprise integration. (Please reserve your hate mail, I know that is a generalization and that there are exceptions. I am a generally a fan of open source.)

Other, generally low end, solutions have tried to appeal only the business, trying to fly under the radar of IT by staying departmentally focused and promising the business that they can operate BPM without IT. Others have attempted to give away their modeling tools, hoping to get the business bought in on the modeling tool before IT gets involved. I have to admit that I think this strategy is interesting. But it doesn't solve the fundamental problem, at least not by itself. To get to deployment, the business is going to need IT. 

Fundamentally, I think that the solution to making BPM successful is better cooperation between line of business and IT. I wish there was there was a technological "magic bullet", but I don't believe there is one. The business is going to have to realize that IT has value to add when it comes to writing business logic, organizing data, and working with enterprise systems. And IT is going to have to empower businesses to control their own departmental processes. Yes, that will mean that mistakes will be made. Departmental processes aren't going to look or act perfectly.

Which leads me to part three, which I'll hopefully post Wednesday night: what lessons we can learn from other technologies (including spreadsheets) regarding empowering business users. Including what to control and what to give up control over.