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

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…

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.

In this case, I don’t mean promoting people, I mean promoting custom-developed solutions from a development environment to a test environment, and from a test environment to production.

Everyone has such a process, but they usually leave a lot to be desired because they have some of the most common pitfalls of process implementations generally:

• Overloaded fields: rather than have each field for one and only one purpose, the owners of the process will, at some point, decide to overload the meaning of a field in order to extract more process behaviors out of the same software, or the same number of input fields, without having to go back to IT for a change request.
• Process Data entered into free-text fields: This is an especially egregious form of the overloaded field. “Please put the name of approver X in your description, otherwise we have to deny your request.” Such business rules should be captured by first-order fields with obvious consequences. Keep in mind the first-time user. Looking at the screen, do they know what information they need to provide and what the consequences of not providing it are? (or consequences of incorrect data)
• The process isn’t customer-facing: By this, I mean that the process is designed to optimize around the people who execute software promotions. Those aren’t the customers. The software developers, consultants, and business users (hoping to realize ROI) are the customers. The process should be designed to help them successfully promote, and to help them realize when they shouldn’t promote. But most promotion processes are inward facing. Raise as many barriers to entry, and push as much work to the outside world as possible, in order to protect the hard cost expenditures of the group responsible for promotions.
• SLAs are measuring the wrong thing: Usually SLAs for promotion are written such that they don’t include customer metrics, only internal metrics. Typical example is measuring time to complete the request. Sounds good. But the measurement typically only starts once the request is approved! From a customer point of view this isn’t acceptable as it encourages the promotions team to push back and reject promotion requests. Better to measure the % of successful promotion requests, or the time inclusive of the first attempted request. The promotion team will scream that it isn’t fair, but it incents the right behavior (and who says the world is fair?!), which is getting good code promoted promptly.
• Not automated in the right places.  Too many manual touch points that don’t add value.

This seems like a general enough problem that someone could write a process around it using a BPMS package. Maybe we (BP3) will do that. But there are a lot of software packages out there for managing this kind of problem. I just think that most of them focus on doing the actual build of software, and moving binaries, and don’t do the whole package well, which would consist of:

1. Manage the approvals process of each part of a deployment (e.g. DBA, Appserver, and BPM assets)
2. Ensure nothing is deployed if any of the approvals fail.  Allow optional auto-approve with lack of response from the approver.
3. Collect all the technical assets (db queries, install scripts, and manual instructions)
4. Execute any of the automated tasks in the appropriate order, perhaps with human supervision.
5. Provide recipe for the user to execute manual tasks and perform appropriate validation
6. Measure statistics for SLAs, etc.
7. Provide a robust way to extend the “process” for different kinds of promotions (custom fields, custom routing, etc).  Many of the tools allow you to do this, but you get painted into a corner in the process… Often the baked-in process is built around enterprise level apps, but then you lose the flexibility to support less mission-critical apps efficiently.

These issues are especially acute when you’re doing BPM deployments because so often they are incremental or iterative in nature… and so often they touch so many other parts of the business.  You might be thinking that because you’re integrated to the ESB or SOA stack, that the unit/system testing will involve fewer people as a result.  However, in practice, the ESB/SOA stack just adds one more testing component to the integrations to each of the systems your process connects with.  Those systems still have to be tested/validated by people as well as the ESB/SOA stack as well as the BPM changes.  A good process would not only be prescriptive in nature for the various validation teams, but would collect the results in an audit trail to inform the go-live/rollback decision.

On a LinkedIn Group I participate in, there was the question posed: “How can BPM Practitioners help Banking and other Financial organizations effectively, in the current scope of situations? Do you believe Financial Regulations will significantly change the way the processes are driven.”

My thoughts… We’ve see an uptick in interest from financial services companies in what we do in the BPM space. Granted, budgets are tight, but times such as these are exactly the time to invest in process, if you haven’t already. If you already have significant process investment, now is the time to revisit thresholds and measures and make sure they reflect current reality.

Although whenever regulations change, the analyst community and people in general assume this will mean an uptick in process. However, I’ve not seen regulation *by itself* as a big incentive for companies to tackle process improvement. It is only when the bottom-line costs of compliance become apparent that there is interest in investing in process to mitigate or eliminate those additional costs. (For example, Sarbox didn’t cause a big uptick in BPM by itself in the first wave of implementation.  Most companies implemented a highly manual or paper-based system at first.  But about a year after everyone implemented Sarbox, projects were kicking up all over the place to improve compliance and reduce cost.) I tend to think that the economic environment will cause more process change than the regulatory environment.

Besides BPM implementations, in terms of the mechanics of the process, one can still address financial services situations via a process lens. By way of example, one might consider a particular financial process to not benefit from process improvement because the defect rate is quite low, or because there isn’t a lot of pressure on timing. But there are areas to look at that matter: if the few defects that exist cost a significant amount of money, then you still want to address them; if money sits in reconciliation accounts, unrecognized until it gets reconciled, then that is like a manufacturing business sitting on inventory - there is a cost to that inefficiency because those funds can’t be deployed to investing in the business.

BPM can improve speed while retaining alignment with process and goals. Good time for companies to be process-aware.

After getting back from the Gartner 2008 BPM Fall Summit in D.C. my intention was to write up a blog about the summit, highlighting the areas I thought were the most interesting. However, instead of the many topics which were covered at the event I am going to hit just one because it seemed to have the most confusion.  In short, why are there so few cases of companies articulating the measurable business benefit in deploying BPM? In a room of about 450 people using a show of hands Michelle Cantara, a Gartner analyst, asked a series of questions that went something like this- “Who has deployed BPM solutions which use BPMS?”, “Who has deployed more than 2 or 3 process solutions with BPMS”?, “Who has or is in process of developing a center of competency?”. In those cases you saw that about 90% could answer the first, 50% could answer that they have done more than one, and lastly about 20% said they have or are working on developing a BPCC. Then the question, “How many have had measurable business benefit in their deployments?”, only about 5% kept their hands raised. Factor in some margin of error due to the audience segments (companies, consultants, vendors) on the poll and for all practical purposes you are looking at a ratio somewhere around 1:20 who can attest/verify they indeed have calculated measurable business benefit. Amazing!

First off I was not all that surprised based on my own personal experiences through the years but this continued large scale, fundamental issue of the lack of measurable business benefit in BPM deployments is a real problem for everyone; commercial enterprises, governments, vendors, consultants, you name it. Why? The short answer is that it creates a barrier to growth. At Gartner there was talk about things like Governance, Model-Driven Businesses, Transformation and the like. Truth is little of that forward looking, game changing, futuristic ideaology will matter if the fundamental concept of investment-risk-reward measurement is not attached to business process management. Very difficult to get unwavering executive buy-in to grow a substantial program if the only thing you can say is “we did a project and it felt good”. In fact, I have seen first hand the promise of BPMS be sold to some major companies who had great ambitions to roll it out “enterprise wide”, check in with them 6 months or a year later and maybe they have done one project, possibly two. What happened to that executive buy-in? For the most part, they lost interest and moved on. I could get in to the root-causes for only a project or two in a year but that’s a completely different topic, so let’s examine: where is the measurable business benefit in BPM?

The last statistic I have is from Gartner in 2004 in a report called “Justifying BPM Projects” and cites the following: 10% of projects had no less than 10% IRR, 78% had more than 15%; wild numbers included 100% to 360%. I don’t have the actual sample size used, and considering what the world looked like then there were major variations of what a BPM project really consisted of. Suffice to say I am on the hunt for broader data which is more current and where source/evidence can be provided.

When looking at the lack of widely known measurable business benefits of BPM deployments I can at least cite what I know from professional experience (consider these contributing causes, not necessarily root-causes):

• Matter of will - “as-is” process measurement was viewed too hard, untrustworthy, or even embarrassing. Usually summed in a statement “we really don’t care about that aspect”.
• Skunk works - BPMS was deployed in a very innocuous process area and used as a “prove out the tech” initiative, quite often a lot of features/benefits were not really utilized on the BPMS side
• IT Centric Replacements - BPMS used to wholesale replace custom applications or other system(s). Usually these manifest themselves as previous improvement projects which failed; now trying BPMS.
• Innovation - brand new processes with no real historical data available

I could go on but these are the big contributors as I have seen them. The more I consider this issue the more I think what would be helpful is answering the question, “How can I practically get to the baseline measures?”. At BP3 we are very measurement driven and firmly believe any company should be able to quickly get the core information so that their BPM endeavors have measurable business benefit. The next part of this blog post will focus on some basic techniques to get those core measurements with the hope that the improvements you choose will deliver the value they should.

After watching the market gyrate a bit over the last weeks, months… year?… and as a business owner, I get a lot of questions from friends about how the economy is affecting our business, or our customers.  I’d be lying if I said there was no effect.  Clearly, some of our customers are making tough business decisions, altering forecasts, and making plans to deal with a tougher financial environment.

But I’ve noticed something else.  The pace of process innovation and change hasn’t slowed.  If anything, it has increased.  This is entirely appropriate-  process improvement can save a company a lot of money, and typically it is money that goes straight to the bottom line (much like an improvement in pricing performance will go straight to the bottom line).

We see customers focusing on process innovation for the following ends:

1. Making a location-specific process global (applying best-of-breed across the enterprise)
2. Making a global process location-independent (no longer dependent on a single call-center location)
3. Extracting savings from commodity processes
4. Measuring performance of BPO (Business Process Outsourcing) contracts against SLAs through BPM.
5. Making it possible to utilize BPO companies in combination with internal staff on a single process
6. Improving on differentiated processes
7. Measuring adherence or increasing adherence to Risk Management processes

We’re seeing less focus on refactoring processes for growth, and more focus on refactoring for savings.  What’s the difference?  When you are building a process for growth, the concern is that the process that handles 1000 calls a day won’t handle 10,000.  That you need a process to help you scale that 10x growth curve, and to help people who are new to the process cope with the process.  Often this means taking a process suited for experts and making it accessible to new employees.  When you’re refactoring for cost, you’re looking for the defects.  In a call-center process that’s eliminating the need for call-backs, dropped calls, calls that finish without conclusion.  So you look for root causes and look for preventative measures, quality control on data entry, etc.  You look for elimination of non-value-adding steps in the process, and for eliminating bottle necks that cause one area or another to be overstaffed.

Not every company is making these investments, and the companies we work with are already narrowed to a select group that are already pursuing process excellence via BPM - but it feels as though most companies are not panicking and they are focused on these tried-and-true ways to improve their bottom line.

One of the reasons we offer bite-sized packages to customers (and prospective customers) is because there is an element of “you have to see it to believe it” with process improvement.  I’ve seen a few of our relationships go from a 1-hour session to a 2 day working session to a 4 week study to a 3 month roll-out.  Each piece a palatable risk-reward investment to move down the path toward process improvement, rather than signing up for a boil-the-ocean endeavor.

Now that the day is over, I’m happy to see the market ended up for the day.  But regardless of the market ups and downs, we see real value and real need for process improvement all around us.  And consistent investment in those activities will yield results in good times and bad.

The case for modeling without thought of execution…

I recently came across a blog entry from IDS Scheer on their Aris BPM Blog. Thanks to Sandy Kemsley for pointing me to it from her blog. Upon first read of the article by Sebastian Stein, I was struck by the difference in perspective between those who implement processes and those who model them.

For those who model (Modelers), the Model is the chief output and goal. Having a Model that will survive the test of time is the goal. You can see that bias throughout the post. In fact, the core philosophy is embodied right here:

“A business process model, depicted in one of the popular notations like BPMN or EPC, should not contain any technical details. If the underlying IT infrastructure or implementation technology changes, the business process model should remain stable. Your warning bells should ring if you have to change your business process just because you changed the implementation technology used.”

The two key points:

1. No technical details
2. stable with respect to technology changes

Something Overlooked by a Model-only Perspective…

But there are some problems with this… First, all the BPMN/BPMS tools that I have worked with support layering of processes. This layering allows the user to create a model that reflects Business sensibilities at the top layer, and if needed, several layers down in detail. So, if your need is to model something without “any technical details” you are not prevented from doing so in the BPMN-oriented tools that I’ve used.

Second, when you get to a certain level of detail, the process design should be informed by Technology. How so? It is important to understand if a transition is a manual or an automated one. Is it a non-value-added manual step? Then generally we want to automate it, or ideally remove it. Value-added manual step? Then generally we want to optimize around its constraints, but automation won’t be the goal. However, we may want to use technology to reduce errors, to improve time-to-execute, etc. In the posting, Sebastian doesn’t go into detail as to what he considers a “technical detail”, but it does beg the question: what is too technical? How about input and output data from a step in the process? These are critical process design considerations (if you know that a piece of data is required as an input, but you’re not sure where it comes from, you have a problem to resolve in your process design. And those inputs and outputs help define the “contract” of an activity or subprocess (or even of the entire process).

Third, Modeling tools today make it exceedingly easy to change a Model to adapt to Process changes. While it seems like a good idea to have a Model that is “stable” with respect to technology changes - the fact is, business processes change faster and more often than the technologies and systems that support them. The real problem isn’t keeping the Process consistent across technology changes - the problem is that the underlying technology may not be flexible enough to adapt to the new process model! At the least, the technology layer is often not agile enough to do so at a sufficiently affordable price and on a sufficiently short timeline (unless of course, that process technology layer is a good BPMS).

Fourth, the resilience that one needs, truly, is with respect to performance data. Performance data analysis is what will drive my process improvement activities, or identifying a process operating outside control limits. I need to be able to compare the performance of my process now to the performance of my process next year, to the performance of the process last year… If my process changes dramatically, how do I do that? Note: I’m not saying the technology changed. The process changed. So what I need is a way to track data that will make sense even in the face of relatively substantial changes in my process. BPMS tools can provide this facility, either baked in or via smart modeling practices, by taking snapshots of data at key milestones in the process that are not likely to change, semantically, even while the syntax (specific steps) of the process may change. To this end, even though the order entry portion of the process may change dramatically, you can still track information around the # of orders in, the value of those orders, the time it takes to process them, etc. even though the order entry process may go from highly manual to highly automated to web-self-service (or may yet encompass all three).

How do we Sum it up?

So the argument is that a modeling-only tool buys you a benefit (stability against technical change) that you don’t need, while not providing a benefit (technical agility with respect to business process changes) that you do need… yet still doesn’t address the key stability need -that of the measured process performance data. Moreover, the integration from most modeling tools to an actual functioning BPMS is, for the most part, non-existent from a practical perspective. Even when that integration exists, it is usually lacking process execution sensibilities in the model. There is a difference between drawing a model that represents the business needs and drawing one that can NOT be executed because of ambiguities and inconsistencies. For the best integrations I’ve seen so far, the products and the integration are all written by one vendor. (I’m definitely interested in seeing examples of this kind of tooling and integration and I’d be happy to write up reviews for such)

I’ve actually written an import to a BPMS suite using an Aris model as a starting point - and its hard!  There is a ton of non-relevant data in the export - positioning information, for example - and other information you need is difficult to lay hands on (roles/ownership).  To be fair, this wasn’t a BPMN diagram in Aris, but it WAS a diagram of a process, in a very unstructured environment.  It wasn’t any easier than parsing it out of Visio vdx files.  My recommendation, is that if you are given a process modeled in a modeling only tool - your first instinct should be to redraw that process in your execution modeling environment rather than try to import it (unless the importer ships with your product, in which case, give it a try!).  You’ll be surprised how fast you can recreate the model in your execution environment.

Now what?  Does an Execution-Oriented Model still make sense?

Okay. Given the arguments Sebastian presents, it seems he is suggesting that if you don’t know what product you will use to implement, you should use Aris to model your process (in fairness, if you don’t know what execution environment you will use, paper, visio, and Aris are all good options). And that, because it is “agnostic” with respect to the implementation tool you use, there is some derived benefit (this is really the point I disagree with). However, if you are going to build your solution in a completely different toolset, and you accept my premise that exports out of Aris (and other modeling tools) into execution BPMS suites leave a great deal to be desired, then you come to an interesting crossroads. Is he suggesting that once given an Aris model we should just write BPEL xml or some Java code to implement the process? or that we should then use a BPMN-oriented modeling suite to re-model and then implement the process?

In our experience, just “writing code” to codify a process in a modeling tool is a mistake. For one, how can the business determine if you have faithfully reproduced the process in your code? Extensive usability / UAT testing might reveal an answer, but it is a very expensive way to find out, and it only happens after all the code is written - and any mistakes will be very expensive to fix at this point because they could be simple mistakes or they could be conception or foundational mistakes. An Agile development process can help, but many organizations have trouble carrying off this approach with traditional software tools. If the technical team uses a BPMN execution environment (a BPMS) to build that process, then the business will be able to see the process in BPMN, a language (drawing) that they can understand, and understand the semantics thereof. By visually inspecting the design, the business can eliminate the greatest proportion of future defects at the earliest part of the design phase. And the technical team will implement each portion of the process in context of the business process at that point. And that is critical for providing useful business context to the technical team at the time they most need it.

Which Model is the Master?

And finally, now that your Process is implemented in an execution-oriented BPMS, as well as modeled in your modeling-only environment… which Model is the “Master”? Of course, you can make either answer work.  But let’s be clear about the choice you make :

Option 1:  The Model as drawn by the business in the modeling tool is the master.  it does NOT reflect what is actually happening in the business, or within IT, but it does show what the business was hoping the process would look like when the project started.  (Optionally, it may have even been revised and updated at the end to reflect some of the changes that implementation and testing revealed needed to be made).

Option 2:  The Model that works as agreed to by IT and the Business, drawn and executed in the BPMS environment.  This is the model that was actually tested by business users in UAT, by Unit Testing in IT, and system testing in IT.  This is the model that is actually running your business process in production, and it reflects reality.

Is it important that your original Model is resilient to technology change in this context?  Is it relevant that your model doesn’t have any technical details in it?

Or does it seem to be more interesting that there is now a BPMN model that represents what actually runs in your business every day, that can be measured and analyzed over time.  Does it matter that this BPMS is resilient to back-end technology changes (activities provide abstraction to what type of integration, and each integration can provide abstraction as to what specific systems are being tapped)?  Does it matter that this BPMS can support relatively rapid changes in process to adapt to your real business?  Does it matter that you can map the data you are tracking to your Model, to generate heat maps and highlight problem areas?

Well, you can guess where our heads are at.  Modeling is important, but Execution makes it relevant to the bottom line, and makes the Model itself more valuable.  If you want help turning your models into reality, we can help.

It’s clear that organizations are recognizing the value of Process Management in their overall strategy. These organizations are researching, investing, and sponsoring projects in growing numbers to understand, model and implement their processes in a BPMS tool. However, I find too often, the momentum stops there. You have analysts and technologists that help install, build and deploy BPM solutions but what then? Who “owns” the process once deployed?

I submit that the business unit should own the process in which they operate; but far too often, the line between an IT-implementation and the execution ownership is so blurred that the BPM solution becomes another asset that IT never lets go of. You see, the growing need for a BPM solution is the realization that to innovate, improve, and accelerate my business, I must understand and manage the processes I have. I need to measure my inputs, resources, and performance in order to make decisions on my capability and offerings. At the center of these points of interest lies my process. How can I accurately pivot my data points if my center pivot point (the process) continues to change without my knowledge? By change I mean, unexpected, un-managed change on the business floor. It’s the work-a-rounds, the “shift to old ways”, the manipulation game many workers and managers play to achieve goals that may frankly be out of date and/or no longer valid. As we embark on process improvement (often necessary for growth), we have to measure current performance and understand the impact of changing the inputs, adding more resources or simply improving performance. This computation is has no foundation if the process we think we’re measuring against is not the actual process in action. Our information is flawed and our decisions compromised.

A well defined process is a valuable piece of intellectual property for the organization and when the business decision makers lose site of that process artifact and don’t refer to it when making business decisions, its value drops and the process suffers as a result. Changes may be communicated and enforced without understanding the impact to their process and solutions in place. Metrics become skewed and don’t reflect actuals when process steps are ignored, changed without reflection, or utilized incorrectly.

BPM tools help solve this problem by not only providing the means to model a business process and communicate effectively, but by deploying the model in a run-time, executable environment such that the model not only becomes a communicative device but a managing, orchestrator of the process flow keeping the model itself front and center in the business. However, when this software solution is not coupled with an adequate Business Process discipline, the BPM solution begins to look like another commodity software package managed by IT. This is a path that the business strategists must seek to avoid.

Process-centric business training such as Lean Six Sigma helps keep business analysts and managers focused on change that positively impacts a business process at the lowest cost. When married with a BPM tool that can visibily reflect those process efforts and implement that solution, the competivie advantage can be down right compelling; but continues only if the process remains the focal point of decision making (one might argue the fulcrum to achieve leverage on your strategic assets). Remeber, it’s not just about the software, it’s also about process responsibility and stewardship, in order to achieve maximum benefit.