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.

We’ve been a going concern at BP3 since May 2007.  But it doesn’t seem that long ago that I was part of a much larger organization.  I almost forgot how fast a small team can achieve alignment.  In larger organizations, you accept that you have to say the same thing many times before it sinks in as “policy” rather than opinion.  You spend a lot of time bringing people along with your way of thinking, giving them an opportunity to reflect back to you, provide input into the process.

Sometimes it is great to be part of a small team.  A single email rallies the troops to action.  Everyone is on board with the goals, and providing valuable inputs toward those goals.  One of the things I felt was most important at my last stop was setting out an operating philosophy for our team, and a “compass”.  The compass tells you where “North” is so that you can make decisions in relation to how close they keep the compass aligned with North.  When a company makes every decision as a one-off exception, and hopes that the team will infer the philosophy from those collective decisions, the company is taking a huge bet that won’t pay off.  Spell out the philosophy.  Give them a thumb-rule or compass for making tough decisions. Give them visibility to how you apply the philosophy and compass to your own decisions.  And then watch your team apply the philosophy and compass to their own, providing some coaching along the way.  It isn’t that different from teaching, when you get right down to it.  I’ve seen some pretty senior leaders (in multiple organizations) exhibit some excellent crisis management skills, or customer management skills, and yet fail to communicate the principles behind their behavior to their team.  As a result, those decisions keep going back to those leaders to make, instead of being made closer to where the action is.  This creates bottlenecks in the organization, and it can inhibit growth of the organization in terms of size…

You can’t leave a healthy culture behind unless you invest in this kind of team and grass-roots self-reliance.  One of the Navy Seals sayings is to “equip the man” rather than to “man the equipment” and I think that’s a guiding principle for running teams of any size. We’re working to impart our organizational philosophy to our team, as well as other tools, such as six sigma, process mapping, value stream, etc.  These are alignment-aiding tools that our team can put to work to guide their own efforts without needing to check in with “management”.  Further, I think this philosophy can be pushed to process implementations.  Don’t look at the process as equipment to be manned by operators.  Look at it as a tool to equip your process operators to do their job more efficiently and more effectively.  The change in perspective can open our eyes to great process improvement opportunities that we’ll otherwise miss.

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.

Lance Gibbs, our CEO, was at Gartner’s conference this week.  He’ll have some thoughts to share when he returns next week, but in the meantime, once again Sandy Kemsley comes through with session write-ups on her blog.

Look to this space for more from Gartner BPM conference next week!

Appian had their first user/customer forum this week, and so far the best writeups of the sessions I’ve seen are on Sandy Kemsley’s blog.  We’ll have some thoughts to share as well, but for a session-by-session low-down, this is the place to go.