Just wishing a Happy Thanksgiving to anyone following our blog, and to our customers, and our team.  We at BP3 are very thankful to our customers, and our team, who quite literally are putting food on our tables on this family holiday.  We hope everyone is having a great Thanksgiving and resting up for the home stretch for 2008!

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…

UPDATE (11/24/2008): Since making this post I had several people write me privately to tell me that things are tougher than what I described here - and I didn’t mean to sound oblivious to the real strain on major segments of the economy and on companies that have previously been at the forefront of BPM adoption.

A couple of vendors had layoffs in the last 3 months, for example, and more generally, it seems the financials and the northeast are really locked up right now as they get through this difficult time.  I think for the BPM vendors that are heavily (over?) exposed to the financials, they are going to have a rough Q4.  The more diversified vendors are going to find demand down in financials (if not non-existant), but demand up most everywhere else.  I also think it is worth noting that Insurance companies may behave differently than banks and investment houses, as they (typically) have a different level of exposure to the market issues, AIG notwithstanding.

We still see the economic climate increasing the level of scrutiny companies are giving their processes, and increasing the level of interest in projects that are driven by ROI first and foremost.  That said, even the best-positioned company, technology, or person, can find themselves swept up in the wave of bad news.  Positioning well with respect to these trends still doesn’t guarantee a positive economic outcome - its just giving that outcome a fighting chance.

In this post I am going to pick up where we left off on the topic of measurement (Measurable benefit in BPM. Where is it? Part I). So let’s just dive in. Notwithstanding the reasons for not capturing baseline measurements in a process to begin to understand its current capability, here is the punchline if it isn’t done. When it comes to turning dials and flipping switches with the aspirations of making things better in a business process, without understanding the range of said dials, or the effect of flipping certain switches, you cannot possibly understand what will actually provide the highest yield and what won’t in process improvement. Take Dr. Bruce Banner for instance, he turned a knob too. He didn’t know the real range and things didn’t work out so well (i.e. overdose of gamma radiation and voila! a hulking, destruction toting beast emerged). I have seen this with process improvements many times. A “new” process is put in place and all of a sudden people either (a) don’t see any real difference or, (b) things actually get worse.

What are the basic metrics needed? There are five, with a “really nice to have” sixth metric. With these few metrics you can learn a great deal about a process, and don’t sweat how accurate or precise they are up front. That is something through additional work you figure out but getting even rough numbers up front are enough to get some real progress going. With emphasis- having these with a 95% or better confidence level is not a pre-condition to move on. Here is the definition of the 6:

1) Cycle Time - what is the mean or median total time for an activity, or step in a process to be executed? could be data entry, call handle time, etc.

2) Lead Time - What is the total mean or median time, defined by the process owner or company, that is required to meet the customer demand? The term backlog comes to mind, and the motivation for companies having SLA’s for their vendors (or customers). This is the fundamental measurement of your commitment to deliver to a customer (or the commitment you expect as a customer).

3) Throughput Time - What is the total mean or median time from the absolute beginning to the absolute end of a process. The summation of Cycle Times. Key metric to use for the notion of continuous improvement.

4) “Nice to Have” Takt Time- The time the customer expects a given process output to be delivered to them.

5) Work In Progress (WIP) - This is the volume of transactions or widgets in a process. An invoice, A report, a car, whatever it is your process is built to deliver.

6) Number of Operators - Number of process consumers participating in the process to create and deliver the good or service. Claim Specialists, HR Specialists, etc.

With these few metrics you can start to get a picture of how the process performs. There are other metrics like good versus bad process outputs (such as number of defects, think bad invoices, bad orders, etc) but up front these will really get things moving along. For instance, you will see as you look horizontally what steps quite possibly should be left alone versus the one or two that you need to remediate to promote flow. Processes which execute faster have few defects by and large. So how do I start getting these?

Value Stream Mapping is almost always the defacto starting point to then bridge metrics against processes and their activities. Let’s look at an example, this does not use standard Lean notation. This VSM was made with Lombardi’s Blueprint product. What is important is not the iconography but rather being able to see the big picture and relative detail in one view.

Here you can see the value stream representing the core end-to-end process with a target of completing the process in 72 hours. It shows the highest level (1) and goes to the next level down. This is the equivalent of using sticky notes. I could add meta information behind the scenes describing problems in each of these process areas, but what it doesn’t tell me is where am I going to get the biggest bang in terms of improvement. Now let’s look at the same image with the basic metrics assigned:

Now, with the metrics associated I can get a much better understanding of where to focus. If the target is to deliver the tickets to the customer in 72 hours, but we can see that our Throughput Time is 162 hours, where do we need to focus? Conventional thinking is we should improve each area and that the sum total of improvements will make everything better. However, that is not in fact how it works. We will just waste scarce resources doing that. If we drop the listing process from 2 hrs to 1 hr it is equivalent of a rock in the Grand Canyon. We need to get yield! So look at the Order Fullfillment, if we drop it from CT 120 hrs/LT 40 hrs to something similar to the others, we just created a ton of velocity. With these metrics attached, and with the process decomposition we were able to channel those scarce resources to the weakest link in the chain- Order Fullfillment. As a result, if we carve off 100 cumulative hours and reduce the lead time coming in to this process area we are much closer, if not dead-on, to hitting the takt time of 72 hours.

Could we have improved those other areas? Sure and it’s most likely without these basic metrics we would have tackeled them (possibly at a great expense). Being intellectually incurious about basic data is a key driver behind failing to move the needle in the business; just flat missing the mark because project selection was poorly executed.

Again, its not critical to be dead-on accurate up front, there are techniques to help shore up what measurement variation is really doing to the overall management of the process. The point is understanding that processes have multiple dimensions to it. The picture is just one important part of it. You need the metrics to help focus in on what will make a meaningful difference, and the obvious ROI.

Hope this helps, if you have questions or feedback, please leave a comment or catch me at lgibbs@bp-3.com

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).

I’m not sure there are exactly seven forms of BPM, but Tom Baeyens writes a thoughtful article here that lays out 7 use cases and how they are addressed by JBoss jBPM.

Before we even get to the 7 forms, Tom has an insight that is key to understanding why BPM systems are a bit “different”:

A key capability of BPM systems is that processes steps can be wait
states. For example in the business trip process above, nodes ‘manager
evaluation’ and ‘ticket purchase’ are human tasks. When the execution
of the process arrives in those nodes, the system executing the process
should wait till the assigned user completes the task.

From a software technical point of view that capability is a big deal. As the
alternative is a bunch of methods that are linked by HTTP requests,
Message Driven Beans (MDB), database triggers, task forms, etc. Even
when using the most applicable architectural components available in
Java today, it is still very easy to end up in a bunch of
unmaintainable hooks and eyes. Using an overall business process makes
it a lot easier to see and maintain the overall execution flow, even
from a software technical perspective.

I couldn’t agree more with this, though it is a sort of “under the hood” consideration.  It is part of why well-designed BPMS packages can scale really well with respect to the number of process instances that might be in a resting state (waiting for something to happen).  Any BPMS solution that is holding all these instances in memory is going to be at a distinct disadvantage because for most of the time a process instance is alive, it is in a waiting state, waiting for an activity to execute, for a human to act, etc.  and not actively processing work.

Setting aside scale, its just hard work to write the code that surrounds such wait-states correctly and you don’t want to have to write this code every time you confront such a problem - rather, you want to use a BPMS that seamlessly represents these wait-states in a diagram, giving the developer the ability to focus on the functionality of the process steps or the flow of the process, and not get caught up on the internals.

A couple additional thoughts on the seven forms (use cases) he outlines…

For Use Case 5, Visual Programming, he lists a few benefits:

With visual programming, we will target developers that do not yet have
the full skillset to develop in Java. They can graphically specify the
activities and draw transitions to indicate the control flow. Instead
of typing Java code, just put blocks like ‘perform hql query’,
‘generate pdf’, ’send email’, ‘read file’, ‘parse xml’, ’send msg to
esb’. Instead of writing Java, they will be composing software programs
by linking activity boxes in the diagram and filling in the
configuration details.

While simplifying activities like stringing together queries and PDF generation without writing that code may make this operation more accessible to developers without these Java skills, I would contend a different benefit:  Things that should be easy (or rote) become easy (or rote) and therefore free the mind to focus on the bigger business problem.  This is akin to the value I receive from a BPM system hiding the details of implementation of parallelism from me.  While I may have the skills to write this code, it is tedious to write, and expensive to get it right.  So you don’t want to roll this kind of code in a one-off fashion - you want to write it once and re-use it liberally to get benefits of scale.  To the extent that a visual environment frees the developer to focus on the important abstractions of the process, it is a big win.  (Note: As soon as I read Use Case 6 it precisely points out my thoughts about threaded programming, by pointing out that you can use a BPM system as a thread control language).

What really intrigues me is whether Tom and the JBoss jBPM team can create the necessary interfaces and utilities around jBPM to allow the creation of the Domain Specific Languages that can be implemented in jBPM (e.g. BPMN).  While Tom apparently doesn’t see much value in the use of BPMN for executable models, my experience differs (and, since his technical approach doesn’t preclude BPMN for executable models in the future, the disagreement is more theoretical).  Perhaps we can change Tom’s mind about this!  While I think it is possible (and even useful) to create BPMN models that are not intended for execution, I believe a good technical implementation can still be accomplished with BPMN (plus technical details captured in context of the process).  And this technical implementation can still be understood by the Business.

I think the problem isn’t BPMN… its a lack of imagination about how to capture business and technical details in different layers so that the user of these authoring tools can show or hide the “layers” that are interesting to them.   For clarity, I think “technical layer” could include adding additional BPMN elements to the diagram, not just scripting and code and variable input/output details.  And I think tailoring the visibility of details in the diagram is a key component in making a single model multi-purpose in audience.

I’ll definitely have to keep my eye out for jBPM 4…

A question that asks for the wrong answer, and an Answer that doesn’t address the right Question.

• A Question:  “Is this project a good fit for BPM?”
• An Answer:  “This isn’t a good fit for BPM.”

First, let’s talk about the question, and let’s think about it in terms of process rather than project.  BPM is good for processes.  Not just some processes, but processes generally.  The real question that should be answered is “What is the process?” Define the process in terms of what it does for the business.  Don’t define the process in terms of what it does with an incoming system event, or in terms of what a single user community does with some data.  Define the process in terms of how you:

• service your customers
• fulfill your demand
• respond to exceptions or challenges
• meet service level agreements
• create delighted customers and renewable business
• recognize revenue

(These are just a few ideas… )

If you can re-orient your thinking from the “project” or the “application” to really thinking about the process, you won’t question whether it is a good fit for BPM, that will be obvious.  BPM is a good fit for processes, and if you want to manage your processes, you need some BPM!

The answer/statement: “This isn’t a good fit for BPM.”  When I hear someone say that, the following ideas run through my head:

1. They haven’t found the process that their project is intended to serve, or
2. The BPMS they have doesn’t lend itself to a clean representation and implementation of their process, or
3. They just shined the light on their process and discovered all the ugly parts that were hidden in the boiler room.  Now they are feeling like it is barely a process at all, just a jumbled pile of exceptions connected by spaghetti.

To the first point:  Find your process.   Broaden your scope if you must, to consider what happens before your “project” starts (almost every project has inputs - follow the inputs - where do they come from? how did they get created?  who / what is responsible for that?  how do they impact my project/process?), and consider what happens after (who receives my outputs, where do they go and what impacts do my outputs have on their project/process/applications/users).

To the second point:  Just because your BPMS doesn’t represent the problem well doesn’t make it not a process, or not a good fit for BPM.  Let’s distinguish between a software package’s shortcomings and a shortcoming of the concepts embodied by BPM.  The software part is still evolving and improving.  In the meantime, there are going to be gaps.  These can be resolved or patched without abandoning the benefits of BPM.

To the third point:  If you haven’t been managing your projects and applications as key processes that support your business, of course there is a scary boiler room down there in the basement.  Take the time to extract process out of that mess, or else find a way to leverage the boiler room as a black box, with a nice tidy interface (think, electrical wall sockets) that let’s you design higher level process around this one area.  Come back and clean up the boiler room when you can show that by having a better result out of that black box will yield benefits (after all, with BPM, you’ll be able to measure the inputs and measurable outputs and timing and count data… and infer what could be improved without even knowing the inner workings)…

So, when I hear these things, I know we have a chance to help our customers realize an opportunity to look at their problem or project differently and yield the benefits of a BPM approach.  We’ve seen lots of data entry applications that lose sight of the fact that they are interacting with and altering the state of a real process with customer value.  Its really gratifying to see the value we can extract out of this change in perspective, and our CEO, Lance Gibbs, is one of the best in the business at this kind of out-of-the-box thinking (I’ve had the good fortune to be in the room with him on several occasions when such eureka moments have happened).  If you’re using BPM and you think you’ve got a bum deal on your process, take a step back and see if you can’t find the process there, the real process, which your project is meant to service…

Kevin Stollznow wrote a good article on process modeling. He makes a couple of key points that I would agree with, slightly rephrased…

• There is no right or wrong way to model a process.  I would say rather, just that “right or wrong” isn’t the primary question.  The primary question is whether the process is effective.  This is essentially the point Kevin makes, but I would posit that it is actually possible to have a “wrong” process model :)
• He takes a casual swipe at BPMN as a modeling and the idea that commenting on modeling a process must necessarily include a diatribe about the “right” way to use BPMN to do it, or cover some minutiae of the specification.  If you’re an avid reader of BPM blogs like I am, this especially hits home with recent discussions about BPMN compliance and roundtripping with BPEL and whether models should even be executable! :)
• He cites Occam’s Razor (though, I think it actually hypothesizes that the simplest explanation is also the most likely explanation). The point is, simplicity is generally preferred over complexity, when both represent the problem adequately.
• Kevin makes a good point about focusing on the audience or intended use of the model (a model for training purposes may be quite different than the executable model of the same process).

One thing I really like about the article is that Kevin correctly points out that even modeling a process is, itself, a process.  And it is a process that we can improve upon over time…