Business of BPM

Optimists??

I was a little surprised.  I put a pessimistic view out there thinking I might get a few of the vendors and some others I know that read the blog to comment.  Obviously, there is a lot going on in the BPM world.  Just look at Gartner's next conference or any of the PR coming out of the companies. 

It is a challenge to get this integrated with all the other efforts and prioritized, but the information is out there.  Ideas?  Comments?

I often go to BPM Enterprise's news feed to see the latest articles and PR...(here).

BPM: State of the Industry

BPM (as a technology) continues to move along, but after my time in CRM years ago, I see several parallels. 

1. It has had significant year-over-year growth but is still small dollars in a relative technology pool.
2. Big companies that are innovators have embraced it.
3. Small teams have embraced it.
4. Mainstream executives aren't yet talking about it.
5. No one is betting the business on it yet.  (As I told someone the other day, if the PE firm that bought Chrysler announced they were rebuilding Chrysler around a BPM approach and using a BPM technology platform then the market would change.)
6. The value propositions although clear aren't packaged up enough.
7. Methodology is still lagging.

Will it disappear?  No.  Did CRM?  Look at Siebel.  Look at how 1:1 marketing has evolved.  Look at the impact on database marketing.

I simply think BPM is at the chasm (i.e., Crossing the Chasm by Geoffrey Moore).  As with anything new, you get huge lift from a small group of people willing to innovate.  Then, the hard work begins.  But, I believe BPM will change the way people think about process mapping.  It will change how people approach process integration projects.  It will get people thinking about automated process innovation and problem identification.  All great things.

We will see how things evolve.  Lots of companies are exploring.  Buying has been slower, but it is a long sales cycle.   

WSJ on SEO (aka CPO)

I found it interesting that the WSJ ran an article about the Strategic Execution Officer (SEO) and described it like I would describe a Chief Process Officer (CPO).  Below are a few quotes, but I think it does a great job of explaining the role.  It is difficult.  It blends technology and business.  Execution is critical.  You become a change agent.  You have to understand process and what is important.  In other words, it is a difficult spot to fill. 

"The SEO is an executive put in charge of building, and managing, a platform of digitized processes and data that serve key companywide purposes."

"Not only must they be well-versed in IT, but they also must have the authority to redefine roles and incentives for relevant managers and workers. SEOs and their staff have a personal stake in the outcome of such systems, and can move people out of the way if they are resistant to change.

CIOs frequently bring to this role not only technological expertise but an awareness of how companywide business processes make new kinds of employee behaviors possible, and how the processes require greater coordination across units."

Source: Ross, Jeanne and Weill, Peter, All Roads Lead to the SEO, WSJ, 6/16/07, pg. R9

BPM Lessons Learned

So...many of you thought I was going to offer some BPM lessons learned the other day.  Here they are:

1. If you jump right to technology, you will go backwards and have to do process mapping and/or reengineering.  Additionally, your project will take longer because you don't understand your metrics and the business side. 
2. BPM done right will cause organizational pushback.  Your adoption strategy is important.  This is traditionally overlooked in most technology implementations but here (whether you do this on paper or in a system) you are telling people how to do things that may have been fairly unstructured before.  You need to think through this.
3. Don't throw out the baby with the bathwater.  What I mean by this is don't abandon what has worked for you in the past.  If you have application development, project management, release management, or change management practices that work, don't ignore them just because BPM is new.
4. Real-time ongoing JAD doesn't work.  I have seen a few companies try to do real-time application development where the users are looking over the shoulders of the developers and trying to make changes.  Just because you can do this - don't.
5. Take action and divide your objectives into bite-size chunks of work.  Don't take on an end-to-end process that spans the globe and touches 5,000 people.  Understand the big picture and fix the key pain points in the process. 
6. BPM technology will make you think about SOA (Service Oriented Architecture).  And, having SOA will make BPM easier.
7. Just because there is a better way is not a reason to change.  Focus on the business case...document the current state...and capture the actual results.
8. Find an internal evangelist at a high enough level to support your efforts.  (always a good thing)
9. No one (vendor or consultant) can provide everything you need.
10. Simulation doesn't exist (that I have seen demonstrated to show value).

BPM as "Topware"

I don't remember who first suggested the word "topware" to me, but it has stuck.  I now categorize BPM technology into two primary camps:

1. A process oriented application development solution.  Here, a company is trying to take a process that involves systems and people and automate it.  The benefits are reduced cycle times, greater quality (e.g., less data entry), more agility to make application changes, and process level data metrics and reporting.
2. An abstraction layer that sits on top of your existing environment to connect systems and people.  In this case, you don't have to hard code changes into your exiting environment.  You are able to minimize some of the change management aspects while gaining huge efficiencies in the white space that exists between applications and subprocesses.  A process owner can now manage an end-to-end process that uses multiple legacy systems and gain much better control.  Additionally, you get many of the same financial benefits (e.g., time to market, quality, customer service, lower costs).

Recently a company was asking about creating a procurement application.  They have three systems they use today.  One to create the request.  One to create the purchase order.  And a third to track the invoice.  Add to that the fact that they have a process for RFP distribution, a process for vendor management, and a budget approval process, and you have a picture of the end-to-end process.  All of these systems could be linked along with the subprocesses to create an automated solution and management tool for the request to payment process for hardware, software, professional services, and all other items that procurement manages.

BPM: Good or Bad for IT

I have heard people make different arguments about the future of IT and the role that BPM plays in that future.  It is an interesting argument.  Here are a few thoughts.

1. BPM is not necessarily technology dependent.  But, technology is often part of the solution.
2. BPM technology is not IT independent.  Don't believe the no code arguement that business can set-up and implement a BPMS solution without IT.  You need help with software installation, servers, maintenance, integrations, customization, and other traditional frameworks (e.g., change management) from your IT staff.
3. IT already has lots of problems.  If anything, a BPM solution can help IT.  It provides a common language for bringing IT and business together - process.  It provides a quicker way to deploy applications.  It allows for more agility in making application changes.  It provides a way for managing SLAs.  It gives metrics and reduces the adhoc query requests.
4. IT is already facing a staffing shortage.  I have heard a quote of 1.6% unemployment in IT thrown around.  Anything that helps deliver more with less is important.
5. BPM does reduce the need for IT involvement in every change.  It makes major rollouts less likely.  The projects become smaller.  Business people can do a lot more. 

So...I guess my opinion is that BPM is good for IT.  It increases their throughput.  It makes the success of their projects more likely.  It allows them to be more in synch with the business.  And, it closes the traditional business and IT disconnect. 

The Other BPM Failures

For some reason, I have seen the same article misquoted by multiple people.  The other BPM (Business Performance Management) was mentioned as failing at 3/4 of firms in IT Week.  Don't be fooled.   

http://www.itweek.co.uk/itweek/news/2190482/firms-dissatisfied-bpm

APS Benchmarking Study on BPM

The Arizona Public Service Company conducted a BPM study.  I found this on ABPMP and thought some of the findings were insightful. 

What was the call to action?

• Customer satisfaction / service
• Legacy system maintenance / shift of system responsibility to business
• Costs of shipping paper
• Reduce processing costs
• Flexibility

When did you implement BPM? - 68% within the past 2 years.

What was the focus of BPM? (of 28 responses)

• 12 operations
• 5 shared services
• 4 IS
• 3 total company
• 2 marketing
• 2 other

84% said they used a methodology.

• 8 of 27 said they used Lean or Six Sigma
• 13 of 27 used an in-house methodology

12 of 23 responses said they used dedicated internal resources.

Only 4 of the 21 respondents said they had a dedicated BPM group.

There were several more that were more qualitative.  Overall, I think it is a good quick scan of the soem section of the market.  I am not sure of who responded, but I am going to reach out to the author and ask him to comment.

The McKinsey Way

You can certainly never go wrong looking at McKinsey.  Their consultants are usually very top notch and their process of thinking and root cause analysis is great.  Although this post is more about how you analyze a problem (i.e., business process innovation), it also makes a point about how important process and methodology is.  The only way of delivering consistent, high-quality advice worldwide is to have a process of training and consulting that leverages smart people and delivers them to clients.

(Never mind the fact that McKinsey once told me that they only interview people with a 4.0 or people with a 3.8 and above from a top 5 business school.  I didn't fit the bill, but I have several good friends who were there.  I have lots of respect for them.)

The McKinsey Way is actually a book so you can see some insight into the company.  I have read the book and recommend it.  Rather than re-type all my notes, I found comments about the book at MeansBusiness and on blog called Brian Groth's Life at Microsoft and looked at notes on MECE (mutually exclusive, collectively exhaustive) from a book review on The McKinsey Mind.

My old boss who worked for McKinsey was a genius at asking the probing questions.  She new how to get to root cause better than anyone I worked for.  This is essential is diagnosing any problem not least of which are process problems.  (Since I assume you only look at BPM to drive value where you have some type of problem.)

So MECE, as Brian states in his blog, it suggests you should do the following:

1. Identify the problem using a mutually exclusive, collectively exhaustive framework and then map the problem out using some type of logic tree (see example).
2. Create a hypothesis (or hypotheses) about the solution...this drives your analysis.
3. Analyze the data...remember that the only thing that is right is data (assuming some data integrity).
4. Repeat steps 3 & 4 until you find a fact-based solution that makes sense.

  From the book, some of the other key points are:

1. "The most brilliant solution, backed up by libraries of data and promising billions in extra profits, is useless if your client or business can't implement it."
2. "Most business problems resemble each other more than they differ."
3. "If you get your facts together and do you analyses, the solution will come to you."
4. "If you keep your eyes peeled for examples of 80/20 in your business, you will come up with ways to improve it."
5. "Know your solution so thoroughly that you can explain it clearly and precisely to your client in 30 seconds."
6. "It's much better to get to first base consistently than to try to hit a home run and strike out 9 times out of 10."
7. "Just as you shouldn't accept I have no idea from others, so you shouldn't accept it from yourself, or expect others to accept it from you. This is the flip side of I don't know."
8. "When you're picking people's brains, ask questions and then let them do the talking. Keep the interview on track by breaking in when necessary."

Time to Retrench

So what do you do once you have jumped into the pool around BPM and have stalled out. I have seen this several times now. Mostly where companies jumped right to technology. You have to understand your processes, what drives the business, how you measure success, what measures matter, how to drive adoption and change, and what your BPM vision is.

My suggestion is to pause. If you are struggling with your first or second implementation and can't answer those questions, step back. We are looking at helping a few companies with a 2-3 day facilitated session to flush out these answers.

We used this at E&Y all the time. It was amazing. You combine a series of individual, team, and group activities with a master facilitator to accomplish months worth of work in a few days. The benefit is also that everyone comes out bought into the solution and envigorated to fix it.

Imagine taking all your key process owners, your business executives, your continuous improvement people, and your IT leads offsite for 2-3 days. This could be 20-100 people. You then begin with an outside in perspective based on industry and cross-industry information. This market scan helps you understand the big picture and gets you thinking out-of-the-box. After this you move to focus in on the key ideas and key answers that you need. Finally, you move to an action plan.

We have engaged the group that did this at E&Y and has the same techniques and physicial facilities to execute on this. Your outcome can be what you want, but if you have stalled, you have to be able to answer the questions below to be successful.

* What is your company strategy?
* How do you measure success (e.g., Balanced Scorecard)?
* What processes drive this success?
* What process metrics are important - lagging and leading?
* Does the process require automation of the current state or reengineering (or lean improvements) first?
* What are the first and second level processes for the company (think value chain)?
* How do you prioritize BPM projects (IRR, hurdle rate, NPV)?
* What does your BPM team look like?
* What is your BPM methodology?
* What are your BPM standards (e.g., BPMN)?
* How are you going to capture lessons learned (e.g., COE)?
* Do you have a change management plan for driving user adoption?