Sandy has posted a pretty good presentation on mixing rules and process, which pretty well captures how I feel about the subject.  I’ve never understood why the rules-vendors out there try to model the process using rules.  On the flip side, pure BPMS vendors sometimes fall into the trap of feeling they have to claim to have rules engines because the rules folks will try to claim that they have BPM.  I think customers who are interested in both BPM and BR functionality could do themselves a favor by telling vendors up front that they are using separate packages for this functionality – they’re likely to get more candid answers from the sales folks from both companies, as it allows the vendors to play to their respective strengths.

I’ve deployed several projects that integrated a BPM platform with a rules product, and its just easy to do via webservices or an API call in all but the most extreme cases.  Anyway, enough from me, here’s a link to Sandy’s post.

Disclaimer:  I used to work for a company that did a lot of work in the configuration space, which has a pretty big overlap with rules.  We did heuristic search, constraint satisfaction, resource allocation and pooling, spatial constraints, containment, and we even did massive rule systems that were super fast.  Intellectually it was a very interesting field because you take really hard problems (in some cases, problems that you could demonstrate were NP Hard problems) and finding “reasonably optimal” solutions in a very finite amount of time.  As I said, intellectually very stimulating.  In other cases, it was coming up with very creative ways to use simple rule-based systems to compute very user-friendly user-interfaces in millisecond time against very large rule bases.  But one thing I learned for sure: thinking about the world as a set of configuration logic or rules is a different way of thinking, and it just isn’t intended for the average Bear.  This is why I don’t see representing “everything as rules” as being a terribly useful way of approaching the world when it comes to involving your organization in the process of business process management or improvement.  I consider myself a reformed rules guy, and now, tongue-in-cheek, I see everything as a process!

Update: On a (somewhat) related note, a somewhat humorous post from Jim Sinur on how rules might have initiated the real-estate meltdown.

There has been a flurry of discussion around compliance for BPMN specifications, particularly on Bruce Silver’s blog, and with additional commentary from Ismael’s blog.

Bruce makes some great points about why BPMN is catching on in the marketplace.  It is (relatively) intuitive, it represents most of the really important ideas that need to be expressed in the Business Processes, and I’ll add another thought:  you can actually draw it on the whiteboard pretty accurately.  Some people think that is silly, but I think it matters that you can sketch it out pretty faithfully on a whiteboard or piece of paper as well as in software.  A great many people still think most freely on whiteboard/paper rather than on a computer screen.

Bruce also makes a great point about BPMN to BPEL mappings:

“A key reason for that is it is graph-oriented like a flowchart, not block-oriented like a structured program, or more to the point, like BPEL.  For example, you can loop back to some previous step with a BPMN gateway, but BPEL places severe restrictions on that.  What that means is you can draw BPMN diagrams that cannot be mapped to BPEL, or at least to “roundtrippable” BPEL that preserves the BPMN view after even minimal tweaking in the BPEL environment.”

Personally, I don’t even want “roundtrippable” I want “native” – meaning, a representation specifically designed to store BPMN.  Whether it is “custom” XML or “standards-based” XML, I want it to be targeted so that roundtripping simply isn’t an issue – the diagram is the xml/data and the xml/data is the diagram.  Otherwise, how can the business ever be sure that they’re BPMN diagram is being accurately executed?  If the representation isn’t roundtrippable or native, then it undermines faith that the process works as designed.  One of the key problems with all the previous software systems I’ve used and built prior to BPM is the separation between requirements and the finished solution (or, put another way, between the business and IT delivery).

Ismael of Intalio gives this response in his blog:

“Do not worry about round-tripping between BPMN and BPEL
Round-tripping is a futile and wasteful exercise when attempted between two languages or notations that have a significant semantic gap between them, and so is the case for BPMN and any process execution language optimized for computers (like BPEL). The same is true between UML and Java by the way. Round-tripping should be set as a goal only between two languages or notations that are essentially representing the same thing, such as BPMN and its future serialization format for example. What this means is that there must exist a way to fully serialize BPMN diagrams on one hand, and a way to graphically display serialized BPMN on the other. And all this should work in a deterministic and predictable way, uniformly across tools.”

I find the assertion that round-tripping is irrelevant to be a bit startling.  The problem is, if the translation from BPMN to BPEL representation is wrong, we’ll have a hard time detecting that.  And then how would it help with compliance? I can’t take the BPEL representation and load it in another BPMN tool and see the model… so we haven’t achieved the interchange that Bruce Silver is looking for, nor proven compliance…

Personally, I’d start with the following:

1. can i MODEL the specification model (ie, can i draw it in this tooling with standard components).  By this definition of compliance, a visio stencil may do the trick…
2. can the target environment EXECUTE the model.  the compliance model can describe the expected behavior of the model especially illuminating areas that might be up for debate (presently) but which should be standard (near future) interpretation.  Execution should be separated from modeling – from a compliance perspective – because BPMN does not exist solely for execution purposes.

Next, additional models could be provided that describe “illegal” models. If you model these in a compliant environment, it should, in some fashion, warn you that the model is not correct (either by throwing an informative error when you run/test the model, or by showing validation errors at design time).

Granted, testing compliance gets easier once BPMN 2 style storage spec gets released, but til then, there’s no reason we can’t have a representative model – it will just be harder to confirm compliance because we’ll have to actually do the work to model something.

Bruce points out that without the data storage spec, he’s not satisfied with the results – and I can’t blame him – but I think defining what would be a representative model to exercise the specification for a given tool is something that has to be done regardless of the storage medium.  And in the meantime, even the visual representation of such a model could help customers and consultants evaluate BPMN tooling appropriately for compliance.  Currently there’s just too much distance between here and there if we have to have a portable data schema before we can have a model (or set of models) that exhibits all the features of compliance.

Recently there has been quite an interesting discussion around Pi Calculus vs. Petri-Nets, and between BPEL and other implementations of BPMN.  The real discussion thread (consolidated place to read) is here.  The start of this discussion appears to be Ismael’s post on BPEL/Pi-Calculus vs. BPMN engines that use Petri-Nets.  This is pretty esoteric stuff to the average person, but it has sparked quite the debate.

You can find Ismael’s original post here.

If you’re technical, and you’re curious about what’s going on inside the black box BPMS you’re using, this is a great debate to read through.  The basic point made by Arthur and others is that BPEL is an implementation detail, and that BPMN is the most important standard because it represents the process, and as we all should know, representation affects how we think about process.  Arthur’s basic point is not that BPEL is deficient, but merely that it is like arguing about whether we should compile to Java bytecode or C-sharp byte code.  Or native machine code… do we really care as long as the code runs well on our target platform? :)

The victim in the debate is often “petri-nets” as compared to “pi-calculus”. Ismael makes the argument that BPEL is superior to the other approaches out there, partly because it is standards-based, and partly because it employs pi-calculus and that that is superior to petri nets for parallel processes. A great debate over whether BPEL really implements pi-calculus ensues, missing that the key point Arthur was making is that either a pi-calculus model or a petri-net model could represent parallel processing of BPMN models well. My personal experience reflects this as well, as I’ve participated in projects that leveraged both technologies and they both work… moreover, they don’t appear to be entirely mutually exclusive.

Lost in all of this debate is the B in BPMN:  The Business.  The Business doesn’t care as much about the specific technical differences of these approaches under the hood, so long as they execute the process faithfully.  Personally I just want to use the best tool for the job.  I’m going to “write” processes in BPMN.  I’m going to execute them and deal with differences in interpretation of the spec when BPMN is married up to execution engines, regardless of whether they are BPEL or other technologies (and the fact that it goes to BPEL doesn’t get me away from interpretation issues, because the issue is how is BPMN “interpreted” into BPEL just as much as it is an issue of interpreting BPMN into some other exeuction form).

I find it ironic that it’s often the IT department that pushes for and obtains a BPM solution. Again, it’s the IT department that spawns the first BPM evangelists in the enterprise and sets out to internalize and deploy BPM solutions; all with the hope that their business counterparts will “get it” and run with the benefits of process management and become true participants and later owners of the solutions. Yet, all too often, it’s the IT department that then slides into their familiar role as software developers and begins writing software instead of managing processes. They may deploy one or two quick process solutions and then comes the project or program that begins to derail the vision; the process centric vision that is.

The project starts, you know, the one that’s larger than it should be, a seemingly invisible scope boundary, involves business units that don’t even know their included; yeah, that one. The group meetings start with good intentions, the process is kept in the middle for a while. But then, the conversations about how the interface looks, how fast will it run, what kind of system integrations are “we” going to pull off, begin. And suddenly, everyone loses focus of the business process. Suddenly, the “IT guys/gals” are writing software and the business analysts are trying to keep up with the requirements. The group meetings including the business sponsors give way to technical meetings with whiteboard discussions about how the BPM tool will be bent, prodded and tapped into to accomplish the “tricks” at hand. At the end of the day (month, year) you’re left with perhaps a slick solution; but where’s the process? Is there a useful process artifact for which the business sponsors can consume? Is the business unit ready to assume ownership and ongoing evaluation of the business process solution delivered? What about real process metrics, no, not the custom reports that were glued together on top of the custom database wired into the solution; but the real process metrics that could/should be gleaned from an adequate process model? These are the things that get lost when the process discipline and process centric visions are abandoned.

What to do?

If I had all the answers I suppose I’d write a book instead of this blog, but I do think we can start with the Project Manager role. This role is usually rooted in or reports to the IT department. As such, they’re often more focused on time lines, budget, and meeting requirements. Understandably so, but if this role were also responsible for an effective transition of ownership to the business sponsors/process owners, perhaps we could take some measures to keep the process centric view intact.

From the start of the project, the business sponsors should be accountable for delivering a series of statements regarding the metrics they wish to obtain from the proposed solution. In addition, they should be required to agree upon the manner in which the solution will be deemed a success or failure; this often tied to the metrics acquired. The Project Manager should keep this “project contract” or “decree” if you will in focus at each meeting. When scope is concerned, if the item in question does not lend itself in support of the metrics and measurement for success, then it should not be considered (at least for the first release, table suggestions and “sugar coating” for subsequent releases) . After all, an important goal of BPM is to deliver timely solutions with an opportunity for rapid change; that too must not be lost in the vision.

Many project teams are conducting routine “play backs” with their sponsors, but all too often these merely include screen shots or execution of interface screens and/or reports. Again, the process should run front and center. The process owners should know exactly what their process looks like before it’s delivered. They should be acutely aware of the swim lanes that exist, the roles associated with each, the activity steps defined. These are the things process owners manage, not an interface screen.

Upon delivery, the Project Manager should conduct routine meetings with the process owners and hold them accountable for the metrics they stated were necessary. The same measurements for success should be evaluated again and again. The Project Manager must evaluate his/her own success against the process owner’s ability to own the process, to understand the process, to measure the process, and ultimately to be empowered to improve upon the process.

Gartner published an article about the lack of skills needed to implement Business Processes, as well as 11 steps to take to determine whether you should source your BPM projects internally or externally.

As an early colleague of mine used to like to say:  “The Genius of the And” (if I remember right, one of the principles from “Built To Last”).  Even if you have the internal skills to staff a BPM project, you’re likely to want to bring in a vendor-specific expert or an outside expert on process improvement for fresh perspective.  And if you’re a company that prefers to outsource these projects, you are going to benefit from seeding that external team with a well-informed person inside your own org, someone with a lot of institutional knowledge but also the confidence to buck conventional wisdom.  In other words, a little of both internal and external is probably the best of both worlds…

Regardless of what you decide, don’t lose sight of the importance of the partnership between business and IT on these projects.

Good article on SearchCIO.com last week. The first paragraph points out the challenges:  lack of internal resources, and internal politics.  The second paragraph brings up another: complexity.  Of course the article goes on to point out that the challenges are worth it, because the rewards are significant and measurable.

The points are a bit obvious:  BPM is “new” in IT circles, relative to other technologies in use.  It also is a bit “different” in that it isn’t just a new programming language (in fact, it *isn’t* a new programming language), but if done right, it requires a different way of doing things, in that some of the traditional boundaries between the business and the folks who write code for a living are broken down.  It also tends to require a little more agility from the integration specialists and database specialists than traditional application development efforts. The approach is closer to an Agile development approach than a traditional software development approach (although I’m not big on the particular religions of software development methodologies, Agile is at least a close proximity to the implementation style you want to adopt).

Finally, BPM isn’t something the kids are learning in college.  Hiring someone fresh out of school (graduate or undergraduate) isn’t how you jump-start your BPM expertise, as you might have previously jump-started your Java expertise or Ruby or Rails expertise.  With BPM, you might or might not use those technologies, but the skills and knowledge you need to have a handle on include:

• BPMN
• Process Mapping
• ROI
• Measurability
• Prioritization
• Abstraction
• Staging / Incremental Improvement
• Technical prowess for web services, thin or thick user interfaces, Java API’s, XML, Databases

The complexity of deploying BPM often comes from the cross-department, cross-functional nature of the projects.  The typical analogy is that the process is the elephant and each group within the process is like the blind man feeling their part of the elephant and trying to guess what the whole process looks like.  We have to get these constituents into the room and complete the picture.

The lack of internal staff with these skills or experiences is most likely because these kinds of cross-department and cross-function projects are rarely embarked on.  Most of the members of your IT and Business teams may not have worked on such a project (and their previous experience may have made them gun-shy).  That’s the time to pull in some outside experience- and if you can get both generalized experience with BPM projects, and specific-vendor experience, from the same outside firm, then so much the better.  You’ll be better served by firms that aren’t interested in backing up the bus and unloading a whole bunch of consultants, if you’re goal is to have a core competency in Business Process roll-outs, or BPM.  Instead, you’ll want to find firms that will augment your team, will reduce your risk, and will be available for the long-term, on your terms, to assist your process efforts.  In our experience, most companies start with one project, and then expand to two or three parallel projects in the next iteration.  So, even as internal staff are getting ramped up, the need to leverage outside expertise across those projects (risk mitigation) actually increases at that point, even while the percentage of outside help relative to internal resources actually declines as the internal expertise builds up.

If your organization is one that outsources non-core competencies, and BPM is not a core competency, then you can also work with a firm who will staff up as you need more work done, and stand down as your work winds down.  At BP3 we’re interested in business continuity contracts where we maintain a long-term relationship with our customers and help them through high- and low- tides both with initial development as well as ongoing maintenance and support.  Doubtless we’re not the only ones interested in providing this kind of white-glove service.

We added the Lijit (prounounced like “legit”) search widget (or “Wijit” using Lijit terminology) to our blog.  We tried it out in “beta” by putting it toward the bottom of the page but after using it for a while I think it trumps the default WordPress Search widget.  If you do a search in the widget, it will search our blog, as well as the blogs we link to via our blogroll, as well as the BP3 site and a couple of other sites we’ve added as high signal-to-noise ratio sites (e.g. the OMG site).

One feature you might not notice or use unless you click on it is the Explore feature – which let’s you see how the BP3 blog is tied into other blogs in a graphical way, and then in turn to follow the network to other sites.  This is one of the cooler features.  Regardless, feel free to check it out and/or recommend sites we should add to our search results.

Note the other interesting feature… If you come to BP3′s blog from a search engine result, Lijit runs a “research” using the same search terms to search the BP3 search network to come up with a set of related results specific to our content tree.  This is a pretty novel way to provide higher quality results if someone is finding useful content on our site through a more general search.  Give it a try by searching for “lance gibbs bp3″ for example and then pick a result that takes you to the bp3 blog…

A business unit commissions a solution that involves people, decision points, multiple paths and real-time visibility. Sounds like a business process, right? Sounds like a perfect fit for Business Process Management; more specifically, a BPMN rendering and a BPMS tool to implement and execute the vision.

Some key aspects in this solution are:

• People
• Business Decisions
• Multiple paths sometimes in parallel
• Point to point orchestration
• Metrics

These are all aspects that support and imply a BPM solution.

Now, what if I needed a similar solution, but minus the people? What if I had a batch or back-office solution that did not involve people other than an occasional exception path? What if this batch solution was expected to process thousands of transactions daily? Would this still be a BPM solution or would it be a software program designed specifically for this purpose? I have heard many, even in the BPM field; argue that such a batch solution may not be suited for a BPMS implementation. That BPMS tools are not geared for this type of high-volume fast paced execution required of such a batch oriented solution. However, to that I say why not?

You see, just because “People” are not necessarily involved in activity steps within the process, the process is no less a business artifact than those which do involve people. Now surely I’m not advocating that every program written could otherwise be a BPM solution, but I am saying that many of these so-called batch solutions do indeed involve business decisions, multiple paths, and multiple point-to-point system-to-system communications; all of which require sophisticated orchestration and most certainly should have adequate real-time metrics. These solutions are often augmented and evaluated for efficiency and accuracy just like that of people oriented BPM solutions. Often these batch solutions do need to handle exception paths which may involve people. Should the program kick-out on exception to some other process solution? And if so, how do the solution owners manage the big picture of the process flow? More times than not, these batch solutions must maintain state in some manner. They must be prepared to handle system failures and contingencies. Is this all to be written rigidly into a program somewhere with very little visibility?

I also find that many BPM enthusiasts tout automation as one of the goals of BPM in a march towards efficiency. I agree with that sentiment, but once a process has been improved upon to the point of automation, is it no longer a process? Should it then be re-factored into a compiled program of sorts? I think not; for automation left unattended is a dangerous thing. An automated solution still requires checks and balances, reported metrics, and proof that the efficiency gains expected are realized; and what about improvements, new products that adjust the automation, new regulatory requirements that incur change in the solution? Even when fully automated, the business process still remains in the fore front.

Software programs and compiled, efficient code certainly has its purpose, and after all, these BPMS tools wouldn’t run without it, but when it comes to business visibility, orchestration, state management and multiple touch points; whether people are involved or not, Process Management solutions are quite applicable. And as these program interfaces become more and more modular through an SOA discipline, the orchestration and process management of those modules and services at run-time becomes increasingly important. So I challenge the BPMS vendors to stay focused on the process vision, but don’t stop at Mortgage Apps, Claims Adjudication, and Book Order solutions …… think further, faster, and with greater depth than ever before; I want to manage all my business solutions through a well defined, visible, and deployed process!

Phil Gilbert gave the keynote for Day 2 of the OMG BPM ThinkTank 2008 conference.  Using a combination of facts and humor, Phil made a great case for community governance intellectual property, to be developed in the near future (fall 2008?).  The key benefits were to reduce friction/drag on the overall process of chartering projects and resolving resource conflicts.  For example:  How does the integration team decide whether to allocate someone to the $500k BPM project or the $100M legacy system replacement project?  It is too easy for IT teams to simply freeze up and only tackle these huge projects and not address any of the smaller quick-benefit solutions.  On the budgeting/approval side:  chartering 1 big project has the same overhead as chartering 20 smaller projects.  To reduce the drag, one can allocate an investment to a BPM capable team, with an expected return.  Then that team can, in turn, charter projects in an expedited way.  As Phil points out, the incentives have now been flipped, such that the incentive is to ACT, rather than to veto or stall, because the goal is an outcome, not a budgetary one, but a results-oriented outcome.

This is pretty neat stuff if we can take it from philosophy to actionable framework.  In fact, it occurs to me that a good governance framework can help with several of the “effects” that act as barriers to BPM adoption (the sophomore effect, for example, and potentially the bus brake effect).

Good Q&A session afterward as well, ranging from governance to BPM and SOA playing nice together.  Phil did a great job of tying it back to these governance issues.  Looking forward to seeing the next level of detail on this… I’m not sure if its the yellow brick road but it does seem like it has some promise.  Look to phil’s blog for more details and for upcoming updates.

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.

1. 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…
2. 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.
3. 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.
4. 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:

1. 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.
2. 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.
3. 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.

Round Table sessions at the conference didn’t go as expected due to the turnout.  At our new, combined table, we discarded the prescribed topics and chose our own:  talking about the barriers to successful BPM adoption.  Our table, by chance, was comprised entirely of vendors and consultants (a vendor fest).

In no particular order:

1. The Sophomore Effect. Most companies are successful with their first BPM project.  They tend to focus on something fairly attainable and have good alignment and staffing for the first project.  They get an unmitigated success, but as soon as it goes live, the team that was supposed to get all the learning about BPM and form the core of a Center of Excellence is reassigned to everyday work within the organization.  That might be back to their business units or to other applications or support functions in IT.  As a result, when the second BPM project comes along, the staff has to be re-incarnated.  Often the actors are all new, or mostly new, and you don’t get the benefit of expertise gleaned from the first project.
2. The Bowflex Coat Rack Effect.  BPM is not a pill.  Its exercise.  But companies are always looking for the quick fix.  If you want to be successful with BPM, you have to work at it, you have to have discipline, to really reap the rewards over time.  After all the biggest ROI %’s don’t come from the 1.0 release of each process, but from the point-releases – the 1.1 and 1.2 releases for example, or the 2.0 release.
3. The Used-Car Effect (or, my preference: The Little Red Wagon Effect). Often a company can’t come up with the budget to buy new software (Capex) but they have maintenance dollars that can be appropriated for other purposes.  This can end up being more expensive in the long-run, but in the short term it lets the company get going at a lower price entry point. The used car analogy is that you keep investing in keeping the used car running rather than buying a new one.  The little red wagon analogy is simply the “if it ain’t broke don’t fix it” theory.
4. The Bus Brake Effect. In many companies, the BPM project can be halted by almost anyone that is involved in the project.  We called this the Bus Brake Effect because everyone on a city bus can be stopped by each person pulling the brake cable at each interesection.  Making progress quickly depends on everyone on the bus withholding their right to pull the cable.  In the BPM world, this means convincing all the different parties to participate – the Compliance group, Governance, Security, Integration teams, the Line Manager in the Business, the Champion, and other Business stakeholders.  Its quite a list of people that can raise exceptions to your deployment progress, or essentially veto progress if they don’t agree to staff their responsibilities to your process.
5. The Sharepoint Effect. This is almost the opposite of the Bus Brake Effect.  Where the bus brake effect concerns too many vetos and not enough yes-votes, the Sharepoint Effect represents the unbridled proliferation of ungoverned, adhoc processes using unmanageable technology.  Sharepoint becomes a substitute for process, or a substitute for the Excel-based or Access-based processes of the past.  However, there’s no way to find the appropriate Sharepoint site for the appropriate process or process task.  The general consensus was that Sharepoint does more harm than good.  UPDATE:  Now the real worry in many big IT groups is that BPM will be another Sharepoint – leading to unrestrained anarchy of adoption by business users.  See below for solutions, but I don’t believe this is the danger that IT departments worry it will be, because of the nature of BPM installations and deployments.
6. The AA Effect. Ok this wasn’t part of our Round Table but probably should have been.  For BPM adoption, the first step is to admit you have a process problem (in some circles, we call these “problems” opportunities).  If you can’t do that, then you’re not receptive to really making the changes your business needs.

Ok, so we’ve listed the effects that act as barriers or resistance to BPM adoption.  What can we do about them?

1. The Sophomore Effect and the Bowflex effect really require similar treatment to avoid.  Preventative measures are key.  Education helps managers avoid this, but more importantly, plan for more work than the first roll-out, and staff that additional work with the same team, BEFORE the rollout.  By having the staffing plan extend to work for a 1.1 release, or extend to work on the next process immediately following, the time for people to “return to the day-to-day busines” is reduced.  The temptation is reduced as well.  And the longer these people are focused on process improvement, the less likely they are to be re-allocated. The third tactic pays off in the long run, but is not preventative – and that is to make sure you measure the process, so that you have real measurable results to communicate to the executive team and justify getting your crack team together to deliver additional results.
2. See above.
3. The Used Car Effect – the coping mechanism here is, if you can’t beat them, join them.  Sell software in ways that these corporations are prepared to buy – as a subscription, for example, or SaaS.  It may be more expensive for the customers in the long run to rent rather than buy, but in the short term they have predictable, smaller, expenses, and it becomes an ongoing budget item to plan for.  I think this is a tough one to fight head on with a customer.  If they have a certain way of funding projects, usually the best bet is to play ball with their predilections.
4. The bus brake effect – the best advice we have here is to “paint the matrix green”.  Which is a fancy way of saying, make a matrix of all the people you need to support your project or contribute to your project, and then make sure you get each of them to truly agree to do so.  You have to watch out for those who say yes, but do “no”.  But fundamentally you have to build consensus in your process/project.  Still, this is a tough one to conquer.  Lots of moving parts are required to make BPM projects a success, so I feel it is particularly susceptible to this kind of failure.
5. The Sharepoint Effect requires the company to take control of its own destiny – vendors can’t do this for them.  One of the better ideas was to have governance around creating Sharepoint portals – that you can set one up if you implement and stand up a real process associated with that portal.  But with respect to BPM, IT can manage the assets that run the processes, and the process for putting those assets into production, and still give the business the flexibility and room to breathe to create the right kind of process assets to be promoted…
6. The AA Effect.  Well, since this is just my own personal addition to the list, I’ll just tackle this one with my own opinion.  If you don’t believe you have a process problem, or you don’t believe there is much room for improvement (a gentler way of saying the same thing – because implicitly if you think you don’t have any problems, that you also have no opportunities to improve!), try doing a kaizen event, or a business process discovery session.  Establish measures for your process and see if you still feel that there aren’t opportunities for improvement.  The good news is, figuring out whether or not you have a process opportunity/problem does not require buying a lot of software and making a big infrastructure investment – it just requires bringing in an expert or consultant for a short period of time to do some discovery and size the opportunities for you…

Now, the real story is this.  All of the solutions just require one thing from an organization and its vendors:  Leadership.  I don’t mean, necessarily, upper management or “champion” when I say leadership.  I just mean leadership in its most basic form.  Someone on your team, or someone outside your team, will have to lead, to create consensus, to see these effects before they fully stop your progress and plan the path around them or through them.  Not to mention, you need an aspirational view of what you can achieve in your organization with business process improvement – and that, too, requires leadership.

Jim Sinur, VP at Gartner, gave a talk in the morning session about the economics of Business Process (or BPM).  The basic contention was that BPM is something that will do well in up markets, and well in down markets.  The argument basically is that at the micro-economic level, when the economy is tough, you have to do more with less – achieve results with limited resources.  Constrained systems tend to reward those with better processes.  One example not mentioned in the presentation is that if you’re in a deflationary system, you don’t want to hold inventory.  The company with the shortest inventory turnover time generally has an advantage.  In the 90′s and early 2000′s that was Dell… Until the other players figured out how to either catch up or change the game.

In addition, BPM is a good fit for tight economic times because BPM projects produce reliable returns from relatively small investments, generally increasing productivity and quality at the same time.  As I mentioned in a previous post about BPM growth in this economy, companies are still able to take down BPM purchases, and BPM deployments.  In particular, BPM deployments allow for incremental improvement in short-order rather than big-bang deployments of ERP and other large systems.  If we needed more support of this, check out this article on SAP warning that their earnings will miss based on just the last couple weeks of the quarter having big transactions fall through.  This might be convenient posturing but I suspect its true: that those companies that might have otherwise made massive software purchases have put those off.  But I don’t see the same thing happening to BPM efforts at this point.  I don’t think we will unless potential customers move from caution and concern to panic.  So far reason is prevailing in terms of running the business.

I thought the most interesting point Jim made was about productivity.  Indexing productivity per hour of labor, if I read the chart right, the index was 100 for the US, and 140 for Luxembourg, and about 41 for South Korea.  So, the good news is, we don’t have to do a moonshot to improve our GDP by 40% without working any extra hours – Luxembourg already demonstrates that you can be 40% more efficient with the hours you have!  And if you look at countries like South Korea, potentially that could be a 3-4x improvement.  So, while some might focus on the shortcomings we have with respect to some of the European nations, and some might focus on the dangers to our economy if all the Eastern/Asian countries dramatically improve their productivity, I tend to focus on the positive here.  There is lots of opportunity for improvement, and no doubt much of the improvement in the US will come from process improvement.

In the Q&A Session at the end, Derek Miers brought up a great point that the opportunity for BPM is not just other IT-managed system replacement, or IT-managed processes… it is actually a space defined by the # of Excel, Database, and Sharepoint sites out there in the corporation (or at least some significant number of them!).  Good start to the day…

Once again, best coverage of the event as a whole is on Sandy’s blog -

Well, Lance and I are here at ThinkTank 2008.  Looking forward to the sessions.  Its a rare opportunity to step back from the daily rush of work and deadlines and think about where you’ve been and where things are going.  We’re not acting as journalist-bloggers for this event, but Lance is moderating a session on “Managing Complexity in a Process-Driven World” and I’m moderating a session on “From ERP through SOA to Web 2.0 – New Ways of Process Execution”.  If there are any interesting conversations that come out of these sessions, we’ll post our thoughts here.

Thanks to Sandy’s blog post, I’ve once again been pointed to an interesting post in a blog I didn’t have in my Google reader (I’ve now added it!  thanks again Sandy!), in which Ismael Ghalimi gives unsolicited advice to the BPMS competition out there.  I can sum it up as:  “Use our BPEL engine!”

I want to discuss this theme in three parts:  The Case for Change, The Proposed Solution, The Proposed Benefits.

The Case For Change. The economy is hurting, and logically software vendors selling perpetual licenses will be commensurately hurt by reduced purchasing plans.  It isn’t a bad premise, though I will point out a couple of things.  During a slowdown in the early 90′s, software that had good ROI sold at accelerated rates, while software without large ROI stagnated or didn’t sell at all.  Products that extracted cost from expensive operations enjoyed great success.  On the other hand, during the 2001-2003 slowdown, I saw something else happen.  Instead of buying software to make complex processes and operations more efficient, I saw companies dramatically simplify their processes or products to eliminate the need for software (for example, PC and Server configurations became dramatically simpler, and fewer configurations were offered.  The same thing happened in telecommunications.  Complicated sales processes got streamlined).  I can’t say whether the current economic environment will spur more software sales in BPM or less… I have visibility to the deployment side, and companies that already own BPM are looking to get more ROI out of that software $.  But for those without BPM software, I’m not sure that they can effect the same kinds of rapid ROI that BPM platforms provide, and therefore I’m not sure how many of them will back off of plans to acquire BPMS packages.  Ismael asserts that many of their purchase plans will change.  I’m not so sure. If I look to 2003 and 2004 as examples, IT departments dramatically cut spending in the 4th quarter to preserve earnings for the current year (and yet, it didn’t stop BPMS vendors from selling in those quarters).  In the new year, however, priorities were reassessed and projects that were deemed to have a large probability of a large ROI were started. I can’t say for sure how this year will play out yet for BPMS vendors.

So, I’m not sure I buy the economic argument. But I do buy that replacing proprietary solutions with open source solutions or de facto standard solutions makes sense. Why? well, you focus your engineering efforts on the parts that differentiate you, and you rely on the Open Source community to provide for the plumbing elements.  If you find a bug, you fix it, build it, submit it back to the community, and benefit from gradually increasing quality of the overall solution.  Ismael uses the Database example, but I’d say this analogy isn’t perfect for his purposes, because the “winners” in the database space have been primarily licensed software vendors. A better example for BPMS solutions would be the J2EE stack.  Once upon a time it would have been hard to avoid using Weblogic or Websphere, but JBOSS has become a viable solution, and it doesn’t have additional licensing costs (though, the support contracts are actually quite expensive at present).  And you certainly wouldn’t want to write your own J2EE or LAMP stack for your BPM product – you want to focus on BPM and let someone else solve those interesting platform problems for you.

The Proposed Solution. Ismael proposes embedding (OEMing) Intalio‘s BPEL engine in competitor products. In terms of his Blog post, it looks like “BPEL Engine” and process engine are being equated.  However, I think that several of the vendors use something closer tied to the parallel processing notation BPMN, rather than to the XML notation BPEL (there is a brief reference in his post that BPEL’s pi-calculus is better than Petri-nets, but without any supporting data directly in the blog post, since I think that was a bit of a tangent… and certainly doesn’t fit in this post!).  So while they may use a conversion of BPMN to BPEL and then in turn use a BPEL engine, it isn’t necessarily the case (they may, in fact, have a BPMN engine using some other technology).  This introduces some friction for vendors to adopt Intalio’s BPEL engine as a literal replacement for their own processing engines.  Nevertheless, I’m sure some vendors would benefit from getting a BPEL engine embedded even if it isn’t their main processing engine… (and therefore, worth it for Intalio to pursue such agreements where possible)

Looking at his database analogy… This isn’t the same as deciding not to build your own DB and “outsourcing” this technology to Oracle, Sybase, or MySQL… Its actually the equivalent of Oracle deciding to replace their Database Engine with MySQL or PostgreSQL on the grounds that they are cheaper and scalable and times are tough so Oracle could save some money by doing so… but read on for why that may not be their decision…

The Proposed Benefits. No more investment in “stack” technology, pick up a scalable BPEL engine.  The key here is, does the BPEL engine Intalio produces eliminate any competitive advantage or perceived advantage, that the other BPMS vendors have vis-a-vis the competition due to their own respective process engines?  I can’t answer that question for the BPMS vendors, but if we go back to the Oracle analogy, I think Oracle has done quite well (so far) by sticking to their guns and their own DB engine.  There are switching costs that can’t be underestimated too badly – its costly to switch someone from one Database to another… not to mention the monumental task Oracle would have of switching their own software stack to run on an open source database.  Similar friction would exist for the BPMS vendors to switch their process engines out for a BPEL engine.

Conclusion. So, it isn’t that I think this is a bad idea, I just think the bar may be really high, and I’m not (yet) in a position to judge if Intalio passes the bar (or if the other vendor solutions don’t set the bar high enough).  Ismael and Intalio should keep pushing this angle though, with the BPM vendors.  I don’t think any of them will be picking up the phone to call Intalio, as Ismael suggests, but I would suggest he approach them about co-development and OEM agreements.  Having the industry solidify around a common process engine would be a good thing, assuming that process engine is truly superior to all the engines out there today, and might help accelerate adoption of certain standards and innovations.  It would make it easier to expose useful APIs to the developer world (Ismael has some posts about building for developers that are pretty good too), it would make it easier to write solutions that will work across more than one BPMS vendor.  And it would make it easier to push BPMS education down into the college levels at some point.  Still, it looks like a tough hill to climb from here.  Keep fighting the good fight, Ismael.