Deconstructing the Business
BPM's power to analyze, decompose and reengineer processes is ultimately indispensable as part of a larger concept of business and technology architecture, in Mooney's view. In that respect, "BPM is emerging as a kind of business parallel to SOA," she says. "If you just implement service components without tying them back to core business processes -- which is where BPM comes in -- then there's a disconnect between IT and the business."
As such, BPM can help SOA gain traction, according to John Buten, director of product marketing for Pegasystems (Boston). He explains that, typically, the services that IT constructs are inconveniently granular and that while the business doesn't want to build big "bricks" of functionality, clumps and clods would be more manageable than grains of sand.
"BPM can build services-oriented business applications that bind together many services into a process," Buten says. "In that way, BPM can make SOA real and relevant to the business."
The benefits of BPM also are more intelligible to business people reluctant to invest in reusable services just so other divisions that hold off can get a free ride, Buten submits. "When they can start seeing that a service is a business function that does Step A and Step B and presents Step C to them, they start seeing its relevance as something that moves their business forward rather than something that happens to be easier to call technically," he says.
All Too Human
On its own terms BPM has the power to increase efficiency tremendously, Buten insists. But it also is circumscribed by an irreducible human element. "A company's BPM is only as good as its best business people," he says. "The success of BPM is bound by the limits of intelligence and process insight within a company; getting that intelligence and process out of your systems and your organization is a very human process -- and a very humbling one."
Bearing that element in mind, Pegasystems recommends moving toward a BPM culture gradually, beginning to automate and manage existing processes, and developing the insights gained through that endeavor. Many insurers are willing to make changes to increase profitability but are cautious about introducing risk, Buten acknowledges. "A gradual approach gives them the ability to try a little automation, see the results, double-check it with humans if necessary and, later, roll it out at a higher level of automation," he says.
A company can thus build upon small successes, gaining confidence and competence without taking on inordinate risk. "Perhaps for the first project, it will take six months to define requirements; the next one will be done in three, with a second revision in three months," Buten says. "We see people get into a rhythm where they are introducing a new project on a three-month basis, introducing revisions on a one-month and even one-week basis."
Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio
Tweet This