Myths of BPM

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles 9 Steps for Implementing Business Process Management A Business Process Management (BPM) Communication Strategy Is Essential Making Business Process Management Work
	Discussion Forum "I am working on development of backend architecture for a customer BPM system and have a few questions. First the background: the main requirements for the databases are to 1) save information on their processes, and 2) to save information used by the BPM system to control the business processes..." Contribute to this Discussion

By Dian Schaffhauser

Even though business process management (BPM) has been going on for many years in one form or another, companies still struggle to formalize their processes and optimize and manage those processes. It's possible that some of our long-held beliefs about BPM are really what hold us back from getting started or achieving more.

In this article Gartner Research Director Michael Melenovsky shares five myths many of us hold about BPM that we need to rethink.

--> Myth #1. BPM is a project.

The idea with a project is that you go in, you do it, and then it's over. But Melenovsky considers BPM "more a management discipline" than a project.

He compares it to Six Sigma in how it provides "engineering disciplines about how you measure a process, how you constantly improve and optimize it." The emphasis is on the cycle: how a company goes about defining its processes, modeling or mapping them, simulating them, deploying them, monitoring and analyzing them, and only then optimizing them -- "which starts you back again at redefining the process."

In fact, he goes so far as to state that "BPM is not about process improvement -- although process improvement happens during the course of the life of a process."

--> Myth #2. BPM is a technology and tool set.

Melenovsky says that BPM isn't dependent on the tools, though he's quick to add that "there has been some advancement in the technology that plays quite well to the idea of the revision cycle." (Also, as he points out below, the tools can help you sell BPM within the organization.)

Gartner has identified 150 vendors providing BPM suites that do modeling, simulation and analysis. One of the biggest tech breakthroughs among some of these tools, he says, is in how the process can be modeled, and then that model becomes the execution code for the technology.

"Many companies for years have been modeling their processes using Visio or yellow stickums on a whiteboard," he says. The problem with that, he points out, is that "once you've made the model, the model stays static while the business is constantly changing."

To fill this gap and provide a means for constantly synching up the models being developed by the organization with what's going on in the business, tools have created a new process language that's actually a graphical interface, he says. "It's just like a Visio interface -- with boxes and lines and decision points -- that happens to be the runtime code."

What that means, he says, is that "you have to define very exactly what your process is if you expect it to operate properly."

--> Myth #3. You need management buy-in at the highest levels for BPM to succeed, since it's a cross-silo or cross-business-unit effort.

Melenovsky does agree that if you have buy-in of senior management, "any project is going to work more properly." But he also says that Gartner is actually seeing many people approaching BPM from a departmental standpoint -- call center, supply chain, invoicing/accounts receivables. "Many companies start with a small area," he says. "They get a particular process fixed. Then it starts to reach out farther and farther as they start to reach more productivity gains over time."

His suggestion is to examine the hierarchy of processes in your organization. A really complex process, such as order-to-cash, in which you take an order from your customer, "do all this stuff," invoice the customer and eventually get the money, has a lot of sub-processes associated with it. Drill down on the sub-processes you can influence.

--> Myth #4. BPM is like any other typical application deployment.

One of the key challenges companies face, says Melenovsky, is that they tend to take a BPM initiative "more from an IT department perspective." The developer, architects or business analysts go out and collect requirements, write functional specs, take those to the coders and have the coders write technical specs, and code it, test it and finally roll it out to the business. "Usually, by that time it's outdated," he says.

Gartner recommends involving the business people. "The more you can get the business people to model their processes and take ownership of the care and feeding of those processes over time, the better," he says. That includes the analyzing of the processes. The role IT can play is to provide the enabling technology to help that effort.

That also proves to be a hurdle for the IT department. Frequently, the IT people have read up on the new technologies and come to the realization that BPM tools could really reduce their work load. So, says Melenovsky, "they go to the business side and say, ‘You're going to have to start modeling your business rules.' And the business [people] are like, ‘Go away. We're too busy. You guys do it. You guys are the technologists. Just bring me a technology. Just fix the problem.'"

The hurdles don't stop there, he says. From the business perspective, somebody may have read a research report or an article in Harvard Business Review and decided, BPM "is one way we could fix our broken processes." "So they hand it to the IT department and say, ‘We've got this process we'd like to automate and manage,'" he says. "IT looks at them and says, ‘Well, that technology doesn't match our technical architecture and plans.'" Or the security folks might say, "Oh, I don't know about this BPM technology. It's inside and outside our firewall, and I don't trust that it's going to be secure."

How do you overcome the obstacles?

If you're on the IT side trying to sell business on getting involved in the BPM efforts, there are two strategies Melenovsky offers.

The first is to put together a business case for the businesspeople -- one with hard numbers and facts about initial investments, what the maintenance will cost, how long the payback period is, estimates on net present value and other calculations. But rather than trying to generate all of the numbers yourself, bring in facts about what others companies have done in the form of case studies.

The second strategy for IT to try is to drive it yourself. Bring in tools and get the businesspeople into the room with you while you define the process. Lay out the process flows and then tell the businesspeople, "Let me simulate that for you." As the process steps through, you begin to reel in the hook. You may find the business folks saying, "Wow, that's pretty interesting. How did you get those timings?" At that point, make a change in the process and let them see how it affects the results. That may turn out to excite them enough to say, "Neat tool! Let me play with that!"

If you're a business person seeking to engage the IT department, Melenovsky recommends trying the education angle. Technologists tend to be more "engineering oriented," he says. "They think in terms of testing and debugging and modeling." As you bring in BPM tools, and people start to try out the tools, "many of the IT challenges start to go away."

Another aspect to that, he says, is to simply state that "If you don't want to help us, we'll do it ourselves." That often wakes up the tech department and gets them to realize that "the more they reach out and assist business with trying to get through some of these problems, the more the business will adopt the standards and architectural frameworks the IT organization is trying to establish."

--> Myth #5. You don't have to change your organizational structure to succeed at BPM.

Melenovsky says he actually sees new roles emerging in the organization to accommodate BPM efforts. A key role is the "business process analyst." This is the person who watches over the process to make sure it's "operating the way it should and changes are being made the way they should." The BPA is also the one who understands who has the authority to make changes in the process and how to involve other departments -- such as IT -- to see what ramifications those changes cause upstream and downstream of the process. The BPA also takes responsibility for analyzing the data and collecting the key performance indicators that senior management wants to see.

The key to succeeding with BPM, says Melenovsky, is to pick a project that's fairly small scope, but with good visibility -- and that means it normally has a lot of "people interactions." Then gain quick wins with it.

The goal, he says, is to "get people saying, ‘Gee, I'd like to do that over here.' Success breeds success in the organization."

Useful Links

Gartner
http://www.gartner.com/

About the Author: