Business of BPM

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 Art of Ware

I was just skimming a story from Guy Kawasaki's blog about The Art of 'Ware by Bruce Webster.  I was a little skeptic, but Guy always has great instincts.  I read a few of the chapters in the book and think you would enjoy it.  Especially if you work with or at a software company. 

Here is some text from the home page about The Art of 'Ware...

Back in the early 1990s, I [Bruce Webster] wrote and published The Art of ‘Ware (M&T Books, 1995), a reinterpretation of Sun Tzu’s The Art of War, a 6th century BC treatise on conflict and warfare. My reinterpretation of Sun Tzu’s maxims applied to developing and marketing information technology products, most particularly software. Here’s an example:

• Sun Tzu (Chapter 2, ‘Waging War’, 1910 Lionel Giles translation): Now, when your weapons are dulled, your ardor damped, your strength exhausted and your treasure spent, other chieftains will spring up to take advantage of your extremity. Then no man, however wise, will be able to avert the consequences that must ensue.
• The Art of ‘Ware (Chapter 2, ‘Supporting Development’, 1995 edition): When your developers are burned out, your technology aging, your resources diminished, and your advantages gone, then others will take advantage of your weaknesses and cut into your market. Even expensive consultants and new CEOs won’t be able to turn things around.

BPMS criteria

If you are thinking about purchasing a BPM Software package, I think you should read Bruce Silver's blog entry on BPM Enterprise.  He tees up a lot of the items you would want to think through.

What Makes a BPMS Good

BPM as a Business User Tool

I have been using the Appian Enterprise 5.1 and 5.5 Suite now for about 6 months.  We have deployed it at a client and have several implementations ongoing.  It has been very easy to learn and use. 

Without being a developer or a hard-core technologist, I find it easy to build models, create automation, implement rules, create document management repositories, customize the portals, and create dashboards.  Since one of the big values that I see in BPM is the ability to push some of this "application management" out to the business, this is critical.

In general, I expect an integration specialist that can write custom code or understands existing ERP or legacy applications will need to be involved, but if a business "power user" can do 75-80% of the application development, that is great.

Although I have used the Lombardi Blueprint tool, I have not gone as far in TeamWorks, their BPM suite.  I hope to get there in the next month and share some similar thoughts around their tool.  In Appian, it is mostly drop-and-drag with the need to subsequently configure the node (e.g., who is the e-mail sent to, what data is collected).  The one area I would have complained about in 5.1 was the forms editor, but 5.5 added an AJAX form editor which makes that even easier. 

Both companies offer rapid implementations.  I know we did one implementation in about 10-12 weeks from process mapping and requirements to production.  In another case, the implementation team is one consultant with some adhoc support.  The ability to create process oriented applications in a RAD (Rapid Application Development) approach is great. 

Lombardi's Blueprint

As a Lombardi partner, I have been asked numerous times what I think of Blueprint.  I hadn't gotten a chance to really play with it until last week.  The first release was a Beta so I have lots of expectations for the future versions, and so far, all the suggestions that I have made seem to have already been on the roadmap.

It is a very easy to use tool.  It didn't take any training to just jump in and get started.  The functionality is basic today, but it allows you to create a pictorial image of your processes simply by typing an outline.  The idea of having a shared, collaborative environment for process design that can be used by anyone is a good idea.  The fact that it then creates a Powerpoint presentation right from the tool is an unexpected benefit.

It is built upon a SIPOC framework which is a Six Sigma process framework which stands for Suppliers, Inputs, Process, Outputs, and Customers.  Capturing this information is a great first step for process analysis.  Once all the functionality is there, this tool would make a lot of sense for people to use in the initial stages of a project. 

You can go do a tour online which is where these images are from. 

So, where do you take it from here:

* Add more process mapping functionality (e.g., decision points) - this is a planned functionality that is already in the demo for the GA version

* Allow the process to be BPMN compliant (I believe this is in process)

* Allow the process to be imported right into TeamWorks (in process)

* Add process analysis to make the tool more like the BPA tools (e.g., Mega) - this is also in process and part of the original plan

I have heard and read lots of skeptical comments about this tool, but I think it is a nice front end tool for starting a process discussion and capturing the critical data points.  Yes, it doesn't execute today and isn't solving all your problems, but what is.

Visio / Sharepoint - Dead?

Are these tools dead today?  Obviously not.  Most of you probably use them.  Some of you may even use them daily.

Although I like both of the tools, I question their value.  If you hare using Visio to map processes, those two dimensional static representations quickly become shelfware.  I could pull up dozens of these on any BAs computer or file cabinet.  With the constant change of people and processes within companies, these hold little value outside of their immediate project use.  For a short-term tool to quickly get people on board, they do well (although index cards and string might have the same effect). 

If you are focused on continuous improvement, you are doing process mapping, looking at current state and future state, identifying metrics, and hopefully evaluating automation strategies.  So, why not use a BPM modeling environment that can be imported into a run-time engine.  This is why all the software vendors started offering free modeling tools over the past year.  You could also use a BPMN template for Visio and hope that the import process works for your software of choice.

I feel the same way about Sharepoint.  Easy to use.  Simple to understand.  Decent interface.  But, isn't it just the next Access.  Every project, every team, every department has one.  There are numerous installations of this across any company using it.  You immediately lose control and have content distributed in places where it is forgotten and not integrated.  Eventually, this all has to come together.  Talk to anyone that has had to reign in their Access use for control purposes.  Something to avoid if you can. 

Since document management and collaboration are possible in BPM tools, why not do it there.  Most documents are either inputs to or outputs of a process.  Collaboration is happening around a specific instance of a process especially around exceptions to a process.  Why not centralize all of these things. 

With the BPM vendors providing easier and easier modeling and development environments using AJAX, this is something that a broader audience can use and understand.  If someone can use Access, Sharepoint, or Visio, I believe they can do 75-85% of the work in a BPM tool.  The only heavy lifting that is code specific is the integration points.  With the vendors (or consultants) developing pre-built integration "nodes" this is becoming less critical. 

So, my suggestion is to step back in your continuous improvement efforts.  Think about the long-term, and realize that a BPM solution is what you are likely needing to address mapping, versioning, collaboration, knowledge management, document management, reporting, analysis, and automation. 

Compliance with BPM

"A Business Process Management (BPM) based foundation for compliance provides for complete lifecycle management of compliance processes, integrates them across technologies, and embeds efficiency across people, processes, and technologies."  ("Future Proof Your Compliance Using BPM", Neiser, James, 10/12/06, Sarbanes-Oxley Compliance Journal)

Nicely said.  This seems to be an increasingly interesting topic for companies.  I have had 3 conversations on this in the past 36 hours.  After initially scrambling around for SOX and other compliance initiatives, companies are now saying how to we integrate this, track this, create a central repository, improve our efforts, etc. 

With COSO, CobiT, SOX, HIPAA, and other drivers, it is something that finance, IT, and operations all care about.  This means that execs at your company probably care too.  I think I am going to try to get a compliance BPM event organized in the second quarter, but for now, I thought I would data dump some links here for all of you that are looking around.

Appian compliance solution (article, website)

An old retailing example around rebates (D&T, Fuego)

Handysoft BPM Compliance Solution

Webinar from BearingPoint

Upside Research Article

How BPM Bolsters Compliance (Hackett Group)

Automating SOX Compliance

SaaS - Is the time right?

The IT Compliance Institute recently came out with their 10 Big Predictions for 2007.  Prediction number nine is that "the need for standardized processes and lower costs will drive increased implementation of Software as a Service (SaaS)". 

I do agree that the timing is right for an SaaS strategy but for different reasons.  Most of the BPM clients to date have been large companies with a bias towards financial services.  Although some big companies embrace SaaS type frameworks (e.g., Salesforce.com), this generally is a framework employed by midsized companies ($100M-$1B). 

I believe SaaS is right for BPM for the following reasons:

• The software solutions are now mature enough to enable this business model.
• The industry is mature enough to clearly demonstrate the value proposition and financial benefits of BPM.
• Companies are looking to invest in process and technology.
• Companies like the concept of BPO (Business Process Outsourcing) but would like to retain more control.  SaaS of a BPM solution provides this for them.

Several vendors are talking about this and more will come out this year.  This will change the dynamics of the space by opening it up to new companies and creating a new type of managed services business model.