There is a rich irony in the fact that BPM initiatives, which are typically intended to streamline a company's activities, can themselves end up unwieldy, unfocused or over-complicated.
Indeed, BPM initiatives have a natural tendency to expand. "They can start small, but as people see what is happening, they tend to grow in scope and complexity," says independent BPM consultant Sandy Kemsley of Kemsley Design.
TYPES OF COMPLEXITY
She describes two aspects of complexity: one political and cultural; the other technical.
"Keeping it simple culturally and politically is important so that you don't get involved with areas you shouldn't and don't let the scope grow," she says. For example, a team launching a BPM initiative may find similar efforts, such as Six Sigma groups or other process-improvement projects, underway elsewhere in the company. That raises a natural question: Should you combine that new initiative with the other efforts, or even just link to them? Kemsley's answer: Probably not at first. "Eventually, you probably do want to do that, but you might not want to burden a BPM project that's just starting out with those additional things," she says.
On the other hand, you don't want to totally isolate your BPM effort. That's an excellent argument for establishing a BPM center of excellence or competency center—a place to share BPM knowledge, skills and resources throughout the enterprise.
You can also get too complex with technology. Kemsley says the problem often begins when customers see a vendor demo that emphasizes all a BPM solution's bells and whistles. Then, instead of using the product in its basic out-of-the-box form, they get seduced by visions of the many sophisticated ways it could be applied. "They end up turning it into a high-end graphical application development tool and write a huge amount of complex customization," she says. That, in turn, complicates the constant change and fine-tuning that are inherent in BPM, and in the resulting work. "Typically, you'll get some feature in place that seems to make sense, but then when you see how it works, you'll want to change it almost immediately," Kemsley says.
Instead, Kemsley recommends, adopt as much of the out-of-the-box functionality as possible for your first BPM iteration. Then, after people have begun using the solution, you can consider customizing it, integrating it with other systems or developing specialized user interfaces for it.
"It isn't like you will go into production with zero coding. That is a fantasy," Kemsley says. "But you should be able to do something useful with minimum customization." The goal is trying to keep the technology as simple as possible up front, letting the complexity grow with your needs.
KEEPING ON TRACK
Complexity can afflict small BPM projects as well as large ones, notes Nathaniel Palmer, executive director of the Workflow Management Coalition, an industry group. For that reason, he says, BPM projects of any size specific components to keep them trim and on track, including clear governance, regular milestones for measuring progress and a solid communication plan. They also need well-established patterns for how work will be done and how the process and workflow will be identified, captured, and turned into an end state.
Another reason BPM projects get too complicated, in Palmer's view: Thanks to the availability of fourth-generation language (4GL) capabilities, it's now possible for just about anybody to, in effect, become a programmer. "It's easier for people to provide direct input and even contribute models and business rules," he says.
In many ways, that's a positive development because it "shortens the loop," reducing or removing the need for interpretation and translation. Still, the idea of all those different chefs adding their own ingredients to the mix helps explain why a project might rapidly get more complicated.
But how do you know if it is getting too complex? Palmer says the best indicator will be based on your definition of success. "It goes back to the idea that, from the beginning, you need a yardstick for measuring your final success as well as the increments along the way," he says. He suggests scheduling milestones at least every 30 days to gauge whether what you're doing is working.
Discovering that there are significant disconnects between plan and reality is, according to Palmer, "almost inevitable." That's why he emphasizes the importance of frequent checkups: "You don't need to get it right the first time, but if you wait too long and you don't get it right, it will be too late."
If there's a motto for keeping BPM simple yet effective, Palmer says, it's keeping in mind that BPM is a team sport. "No matter what the size of the project, the challenge is to get people to play together," he says.
True, many people think they're more efficient when they work alone—but that's not the optimal approach for BPM. "Alone, we can go fast; together, we can go far," Palmer says. "That, more than any single thing, is what must be learned."
