Archive | BPM Overview RSS feed for this section

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

Continue reading

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

BPR vs BPM: What’s Different?

I had the opportunity last week to debrief Michelle Cantara (VP at Gartner) about Talisen. We had met at the Gartner BPM conference, and she was intrigued by our offerings around BPM which include several fixed fee projects. In talking with her about BPM and sharing with her our methodology and typical sales pitch, I was flattered when she saw the table below and suggested that she might re-use it.This shows the difference between BPR (Business Process Reengineering) and BPM (Business Process Management). Bpr_vs_bpm_2

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 knew how to get to root cause better than anyone I worked for. This is essential in 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.”

BPM + Outsourcing not = BPO

Howard Smith says it well in Business Process Management – The Third Wave “What BPM adds to BPO is the capability it gives to partners to retain control of business processes even if they reside partly or wholly with others.”

BPM gives companies a different option for outsourcing.  Traditional outsourcing was one of several flavors – task oriented, project oriented, or total process.  In general, the runaway successes have been around things like payroll processing which companies like ADP do very well and is not a core competency for many companies.  The other successes have been around IT development or call centers where offshore labor is much cheaper (something that is beginning to change).

As companies have outsourced parts of their IT function – development, QA – or some of the customer service functions – help desk, call center, the challenge has always been letting go while maintaining control.  I know right now that one of the biggest companies in the US is looking at bringing their call centers back onshore to better manage customer service.  I know another company that has outsourced all their billing and most of the customer touch points.  Their service is so bad and so different by geography that it is impossible to manage.

Using Business Process Management (BPM), companies can create an overriding process architecture which connects internal processes and external processes.  This allows a company to outsource tasks or multiple process steps or subprocesses while maintaining control.  Using their BPM technology, the company manages the process flow and the rules while having total process visibility using metrics.  This allows them the flexibility to change process as needed.  It allows them to manage workload.  It allows them to provide an exception process (which is where most things break down).  And, it allows the company outsourcing to keep the hard tasks or critical path items internally based on rules-based logic.

So is this really different.  I believe so.  In most outsourcing deals that I have done, we set expectations and outcome based performance metrics, but we did not control the process steps nor have detailed data on how the company performed each step.  Additionally, changing how they did something was difficult because they were lowering our costs by offering a standardized framework across several companies (or simply using lower cost labor).  Using BPM for outsourcing, makes the outsourcer more like an internal entity and having an SLA dashboard with system reported data that you can mine.  (In some cases, this may be the same as having your functional silos within your company only with process control and management data.)

Why end-to-end process – Volvo example

I can’t verify this example, but I have heard it used multiple times over the years and think it does a great job of making the point about end-to-end process.

At some point in the past, Volvo had apparently manufactured too many green cars.  They were sitting on the dealer lots and not selling.  The dealers decided to offer a special incentive around green painted cars.

It worked and the cars started selling rapidly.  The manufacturing group that was doing planning noticed a spike in sales of green cars and immediately changes the paint orders so that more green cars are produced and sent to the dealers.  Hopefully, you see the problem.

We have all had some instance like this occur.  The problem is that processes have not been historically connected across functions, business units or even companies.  Only an end-to-end process which links planning to inventory to distribution to sales would see the problem.  This is one of the values of BPM and one of the challenges.

Today, I can sub-optimize the whole to make my part better.  In the future, I have to do what’s best for the seo company and the entire process.

The Agile Get More Agile

Much like the saying that the rich get richer, I have begun to see more small companies using BPM technology to make themselves more agile.  This to me is a good example of Web 2.0.  In the late 90s, big companies initially shunned the Internet or approached it skeptically.  It rapidly became a basic part of their strategy.  Some of the dotcoms became dotbombs because of their business models but not because the fundamental technology was wrong.

I think we are at the same spot.  BPM technology is right.  It takes BPR (business process reengineering) and BPI (business process innovation) and adds technology to it.  The technology enables us to take these new, more agile processes and automate them.  Automation creates many things:

  1. Process consistency
  2. Auditability (who did what when)
  3. BAM (business activity monitoring) … dashboards
  4. Reduces paper and improves quality
  5. Lowers cycle time (less hand-offs)
  6. Creates automatic escalations (e.g., someone is on vacation and the task gets routed around them)
  7. Process oriented document management

So, what I find so interesting is that big companies that typically have big problems are once again slow to move on BPM.  They are investing heavily in Six Sigma, but they haven’t embraced the correlated subject of BPM which automates and manages the Six Sigma improvements.  On the other hand, smaller, lean companies have begun to see how BPM can help them better compete.  It makes their processes better.  It improves their quality.  It allows them to better manage and prioritize.  It reduces human intervention and error.  It saves them cost and time.

So…the smaller more agile companies continue to gain on the bigger companies while once again the bigger companies are going to wait until they see this threat.  (Not all big companies are waiting, but more than you would expect.)

You can also look at:

It’s the process not the stars

One of my favorite quotes is the following from Toyota which appeared in the HBR article “Decoding the DNA of the Toyota Production System” a few years ago.

“We get brilliant results from average people managing brilliant processes. We observe that our competitors often get average (or worse) results from brilliant people managing broken processes.”

I was reading a Malcolm Gladwell (author of Blink and The Tipping Point) article a friend had sent me a while ago from the New Yorker called “Are Smart People Overrated?” which made a similar point.  The article itself is very interesting and talks about the culture at Enron which was a culture of “stars” focusing on MBAs that grabbed the bull by its horns and ran with it.  It points out that stars work to write books or in other individual focused challenges, but “organizations that are the most successful at that task are the ones where the system is the star”.

The article compares Enron’s failure and the Navy’s failure in WWII vs. the German U-boats to the successes of Southwest, Wal-Mart, and Procter & Gamble.  All of the later are cultures more focused on the process versus creating a culture of all-stars.

As you think about the importance of process, these are good examples.  Building a process that survives turnover, acquisition, market change, and other typical issues is critical.  Your processes need to be able to adapt and change, but they also need to have codified implicit knowledge so that you can survive change.

Stockholm Process Syndrome

I was talking about Stockholm Syndrome this morning, and it hit me.  This is the explanation for why users or companies struggle to move away from a bad process.  We have all been there where we are part of a process which is obviously broken…BUT, we are so close to it, and it is all we know.  We don’t know how to change our situation.

I think the problem is that people become comfortable with the process they know even if it’s bad.  They have found a way to make it work for them.  They know the rules.  They understand it’s faults.  So, why move away from it.  Change looks scarier than the current state.

So, how do we move on.  The key is showing users a better way.  Helping them understand the longer term value.  Putting them in touch with people using a better process.  It’s about managing change so that a better process can take over.

ROT (Return on Time)

“So, what if you could maintain the same work hours and still be able to avoid growing your headcount without compromising quality, customer service, transactional cycle time, throughput, and all those wonderful metrics.” (The Power of Process, pg. 99-100)

I will give credit to Kiran Garimella in The Power of Process for “coining” a new term – Return on Time – that captures one of my thoughts around time management.  I think the struggle all of us have in any type of role is prioritization and improvement without simply throwing hours at the problem.  At a BPM conference in Boston last year, one of the speakers talked a lot about this also.  His point was that the one thing most executives no longer have is time to sit back and think.  Trying to step back, think strategically and plan for the long term is a luxury.

In an ideal state, BPM can help with this.  Most of what makes our days unplanned and chaotic is fire-fighting.  The cause for lots of fire-fighting are exceptions or unplanned events.  Lots of this can be resolved by investing upfront.  By documenting SOPs (standard operating procedures) about how to handle known exceptions keeps them from being issues.  Just like building software, upfront investment in the right requirements and user involvement minimize your changes on the backend.

Business Process Management can free up time by doing the following:

  • Requiring documentation of your process and agreement on how things will be done (policies & procedures) and how exceptions will be handled
  • Capturing internal knowledge which sits with your process SME and codifying it
  • Building out rules about situations that automatically make decisions
  • Creating escalation paths that no longer require manual involvement to track some piece of paper down and give it to a different person for approval while person X is on vacation
  • Providing process level dashboards that allow management to see bottlenecks and forecast issues rather than reactive measures where nothing can be done

Since time is a key asset in planning for the future and being innovative (not to mention reducing stress), any tool or management approach that helps with this should be highly regarded.  I believe we are starting to see some of this, but I doubt we will ever see a published business case that talks about ROT.

Process Rules – The Apprentice

For now, I will stick with the reality TV genre.  If you watch The Apprentice on NBC, the one thing that I notice is there is always a chaotic team versus a well executed team.  Much of this could be attributed to leadership, but a lot of it can be tied to process.  I think this gives all of us an important voyeurism opportunity.

Imagine if you could take any of your tasks at work and put two teams on each task.  One you gave little direction and a basic objective.  The other you gave clear directions, assigned roles, developed some rules, and executed against a process map.  Of course, the second would win.  The first might get lucky occasionally (a true management pitfall).  This is exactly where BPM as a management theory plays.  And, this is an insight you can get from the show.  You see how much better one team is with some process.  Imagine where you get with a fully documented and optimized process.

BPM helps you to capture the process.  It forces you to articulate what sits in your head and the head of your team.  You translate qualitative decisions into decision trees.  You allocate tasks to people which begins to define roles.  You select and articulate metrics which become reports and shared objectives.

Surprisingly, each episode offers a good nugget of business advice along with some quick lessons in management challenges.  These include:

  • Being faithful to your team
  • Focus on delivery
  • Getting organized
  • Being respected
  • Know your customers; know your market
  • Be decisive
  • Know yourself
  • Listen to your team
  • Be quick but careful
  • Winning is everything
  • Keep your eyes on the prize

Ubiquitous BPM

Taking a business user’s perspective, I can’t help but think that driving massive BPM adoption includes making it part of our standard workflow.  Now there are still (amazingly) some executives who assistants print their e-mails for them to hand write responses, but in general, e-mail and mobile phones are the two adopted tools of the business professional.  I could argue MS Office is the third.

When I think about where BPM is going, I imagine being able to send e-mails to initiate processes.  I imagine never seeing any BPM application since everything happens through Outlook (or my e-mail system).  I imagine being able to call up and respond to tasks on IVR (interactive voice response).  I imagine getting reports e-mailed to me or being able to dial in and hear key metrics.  Some of this is starting to happen, but over the next two years, I expect to see some radical changes.

I compare BPM to where CRM (Customer Relationship Management) was in 1999-2000.  It has a good install base and good client references, but it is just starting to get the right momentum.  I can still use the acronym and get a blank look back from people.  When I went to work for Firepond (a CRM software company) in early 2000, it was the same situation.  Two years later, most people knew what CRM was (primarily driven by Siebel’s marketing machine).  Now, anyone knows CRM, and you no longer have to spell it out.

I draw the parallel because we went through many of these same debates in 2000 with CRM.  Who is the right buyer – IT or business?  How do you make this seamless?  Does this have to change the user’s workflow?  Will they use it?  Are business users technically savvy enough?  What changes need to happen to a company’s infrastructure and architecture?  What industries are most interested?  What products should use CRM?  How to use these tools with your external constituents?

%d bloggers like this: