It’ll be interesting to see what the BPM vendors report in for Q3.  Its clearly a challenging sales environment in general, right now, but we’ve been hearing from a couple of folks in the business that sales have been brisk in Q3 and into Q4.  Since I don’t have access to raw #’s, I don’t know if “brisk” is relative to lowered expectations, or whether its relative to possibly more optimistic plans made at the beginning of the year.

Sandy captured some notes from the Lombardi conference call here, and Dennis captured additional notes here.  They both do a good job capturing the gist of the call -maybe we’ll get invited one of these days :)

One thing Dennis points out from the call is fewer pilots, just diving in and doing it.  This makes sense in a rough economy, as the pilot process is expensive.  A long selection process is expensive.  If you can get the right product and skip some of the expense of a pilot, so much the better.  I’ve heard similar points made by other folks in the business lately.

Sandy points out that while she believes BPM is well positioned in a tough market, that she thinks the real spending will be on projects with customers who have already swallowed the capex to buy software.  We’ve definitely observed this phenomenon in the market - expanding on old solutions, building new ones on existing infrastructure.  Its good to be a BPM consultant in this environment, and really see the yield that customers can get on this process improvement investment.

I’m looking forward to seeing if some of the other vendors in the space will do these calls as well, and see if the trend of good news is across the market or localized with just a couple of the vendors.  I think the big news was continued growth of license revenue, and the fact that they are profitable for 2008.  Given the funding environment right now, it seems like A Very Good Thing to be profitable.

Ok, back to work on processes now…

I’d like to take credit for it, but it is all the magic of WPTouch, a great Wordpress plugin that Sandy Kelmsey turned us onto in this post.  The homepage for the plugin is here.  Literally half of our team has switched from blackberries to iPhones since the 3G model came out.  I’m still the only one using a Mac, but don’t be surprised if that changes too…

Meanwhile, if you have an iPhone, feel free to check out our blog in its new iPhone mode.  I was pretty impressed by the folks at BraveNewCode-  the WPTouch theme/plugin is pretty ingenious and it doesn’t interfere with the normal browsing experience.  I wish all the blogs had this kind of theme for reading from the iPhone.

Incidentally, if you’re wondering how our team feels about the iPhones, we love ‘em.  Being able to read websites or html email on your phone is actually useful.  Typing is marginally harder after using a blackberry for 4-5 years, but getting easier.  And some of the apps we’ve found are pretty entertaining (when you travel a lot for work, the iPhone apps for Yelp! and Urban Spoon are invaluable for finding a quick foodie fix… and the directions/mapping are great too).

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.

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.

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.

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.