In Focus: 101 Advice for Process Management NeophytesIn Focus: 101 Advice for Process Management Neophytes

In a recent Intelligent Enterprise poll on business process management (BPM), 36 percent of 1,700 respondents said they were actively considering the technology (while 24 percent were already piloting, rolling out, in production or upgrading). BPM Analyst Connie Moore of Forrester Research details who's adopting and adds her advice on where to begin.

DOUG HENSCHEN (DH): Business process management is gaining a lot of attention as a technology category, but do you think it's well understood?

CONNIE MOORE (CM): There's lots of confusion about the term. When we do surveys about BPM and we define it as software that supports cross-functional processes that involve people and systems, the top buyers are oil and gas, utility, chemical, retail and consumer packaged goods companies. Yet when I look at the base of clients placing inquiries about BPM, it's from government, banks, insurance and financial services. The latter have been doing process automation since the early '90s and still use the term "workflow." The former are newer to the concept [and know it as] BPM, but both groups are talking about the same thing.

DH: What do people expect from BPM?

CM: It helps clarify things to think about the various individuals impacted by BPM. A user sees BPM as something that's managing their work. A manager sees it as a way of monitoring their service level agreements, monitoring their commitments and managing their work force. The developer sees BPM as a way to reduce development time. Process owners see this as a way to commit to Six Sigma or other improvement initiatives. BPM touches many pieces of the organization, and that's why you see it described in many different ways.

DH: What's driving adoption across all the industries you've mentioned?

CM: It's about efficiency and productivity, streamlining processes, reducing cycle time, getting work done faster, getting work done with fewer resources and freeing up people to do value-added work as opposed to the mundane work. Compliance is another driver. Within government, compliance could be the need to comply with freedom-of-information acts. In the corporate realm, it could be Sarbanes-Oxley (SOX); a lot of folks seized on the document dimension of SOX, but there's a very heavy process dimension as well. In healthcare it's HIPAA—each industry has its own list of compliance requirements.

As the economy started moving out of recession last year there was a marked shift in priorities toward growth initiatives; we started seeing CEOs and CIOs focusing on getting product to market faster and getting new ideas turned into products and services. That's a new priority driving BPM adoption.

DH: Once companies settle on a BPM approach, what types of processes should they take on first?

CM: You should start with a process that's causing a lot of pain. Management and user push back diminishes because everyone realizes that something needs to be done. You'll get more support, more resources and more corporate commitment, and you can use the success of the first process and use it to sell the next project.

Customer-facing processes often cause pain because they typically have multiple steps and hand-offs; things can fall between the cracks and it can be very hard to track what's going on. Processes that go outside of functional departments can also be good candidates for initial projects because there's often fuzziness about who owns the process as it cuts across departments.

DH: Are there processes you should avoid for your first project?

CM: If you want high rewards, you have to look for projects that have an impact on the company's revenue, that are high cost or that are associated with customer satisfaction, but processes that transcend company boundaries, that involve extensive integration or that constantly change so that exceptions are the norm can involve much higher risk. If there are, say, three processes you can choose from, don't start with the highest reward, highest risk process; start with the highest reward, lowest risk process and then move on as you move up the learning curve.

DH: What are the biggest stumbling blocks once the process mapping begins?

CM: A lot of people get stuck on the modeling and they don't move on; they take on too much and then try to create the perfect system. The best practice is incremental improvement, so shoot for three-month phases: Take your process, improve it, deploy it, use it, make changes to improve it and then deploy it again. By the time companies have gone through this iterative improvement process three or four times, they've got their process really optimized. By the time they're gone through it six or seven times, they've got it really, truly streamlined and there's not a lot of inefficiency left anywhere.

DH: Many companies do just one or two iterations; they design the process, fix the obvious problems and leave it at that. Is "continuous process improvement" overrated?

CM: It's not overrated, but I've definitely seen some companies put a lot of emphasis on continuous improvement when they evaluate software. But then they never go back and use that capability because people see the new process as good enough or so much better than what they had before that they just run with it. The best approach is not the big bang—taking on too much and modeling the perfect process—and not the "let's improve it once and live with it forevermore." You have to improve the process, revisit it periodically and improve it over time.