In-Depth

Business Process Success: Advice from an Expert

Organizations do successfully manage people and process changes en route to large scale enterprise transformations. Here’s how.

• By Stephen Swoyer
• 02/28/2006

If anything can put the brakes on the best-laid plans of business process automaters, it will probably be the same showstopper that’s checked the momentum of more than a few Next Big Initiatives over the years.

People and process change. We’ve all grappled with it. It’s the single biggest bugaboo of any enterprise modernization effort. But it’s not an intractable problem. Fact is, organizations do successfully manage people and process changes en route to large scale enterprise transformations.

For starters, says Dr. Tushar Hazra, a senior consultant with consultancy group Cutter Consortium, communication and coordination are crucial. That’s a no-brainer, though, isn’t it? Not so fast, Hazra stresses. Many organizations only pay lip service to effective communication and coordination. In other words, just because they think they’re coordinated doesn’t necessarily mean that they are coordinated. While this is true for project management in general, it’s doubly the case for business process automation.

Consider one way in which organizations commonly attempt to manage people and process change—entrusting it to oversight or governance boards. This is fine as far as it goes, Hazra says, but in a lot of cases, governance boards only make a token show of identifying and interviewing business process stakeholders. “What usually keeps on happening is that companies usually start with a small group of people—maybe three or four or five people—who are assigned to go out and assess what the situation really is. These people start with a set of assumptions about who the important stakeholders are. But once that information has been gathered, the number of stakeholders almost always increases,” explained Hazra, in an interview late last year.

This causes a kind of methodological error, he says. Companies assume from the outset—as a guiding methodological concept, even—that they won’t be able to identify, much less involve, all relevant stakeholders. All too often, Hazra says, they leave it at that. They might want to cover themselves by attempting to involve all important stakeholders, to be sure, but beyond that they have little or no incentive to do much more. The mistake, Hazra says, is not to make an honest and thorough effort to identify and involve as many business stakeholders as possible. Nothing reinforces resistance to people or process change more than having a door preemptively slammed in one’s face.

“What I usually propose that people do is try to make sure that the expectation is set right from the beginning that not all stakeholders are going to be able to be [present] at all times,” Hazra explains. “The idea is to give [absent stakeholders] some sort of way—perhaps [by means of] a portal or dashboard— so that those who are not readily available can still have access to the information.”

Of course, communication and collaboration can only accomplish so much. In the end, some stakeholders are going to feel as if they’ve gotten the short end of the business process stick—regardless of how much input they’ve had into things. How can organizations best accommodate these folks?

It’s a legitimate concern, says Vince Re, chief architect with Computer Associates International Inc. (CA). After all, active (or passive) resistance on the part of disgruntled stakeholders has derailed countless business realignment or large scale transformation projects, especially where service enablement and business process automation are concerned, Re says. “In the transition … to the Web-services approach, people will talk about performance and all of that of the Web-services model versus a more traditional model. The deployment model is different, the operational piece is different, and it creates this kind of buzz around it—a kind of skepticism that [while] the end point might be very viable, the path seems kind of treacherous to a lot of folks, especially those who have a stake [in the status quo].”

That’s why Re advocates a slow-and-steady approach to business process automation—for example, by service-enabling processes where and when it makes the most sense to do so. This helps minimize the disruptive aspects of business process automation, he says, and—assuming, of course, that an organization’s iterative approach to service enablement is consistently (or largely) successful—can also help allay the concerns of key stakeholders. “There is sort of a chicken-and-an-egg problem here. The [line-of-business] customers aren’t going to be happy about these [next-generation] application environments until they know they’re secure and reliable,” he observes. “So if you look at what we’ve done, our message has become ‘unify and simplify,’ because the complexity of this [business process automation] is pretty enormous. It makes sense to approach this like that [i.e., iteratively].”

Best-effort collaboration and iterative process automation don’t by any means amount to a combined process automation silver bullet, of course. In any organization, a finite number of stakeholders are going to resist business process change. There’s nothing that can be done to avoid this. Organizations can, of course, minimize active resistance by employing these and other strategies. In the end, however, business process automation must also be driven by a strong top-down commitment, says Cutter’s Hazra. No large company can afford to be a gulag, of course—but neither can it (or should it) be a democracy.