When working with BPM tools, it's essential to emphasize that the effort is about business processes (not just the tools).
The problem: You need to simplify people-intensive business processes such as managing approval for loans or ensuring proper billing for insurance claims. The answer? Most commonly, companies look for an automation solution, based on workflow management, document management or business process management (BPM) tools. But this technology-first approach doesn’t work—and could even increase your costs.
Motorola, for one, offers a model for how an enterprise should approach BPM. The communications equipment manufacturer has long been process-driven, using techniques such as Six Sigma to understand and continually improve its processes. Three years ago, CIO Patty Morrison saw that BPM technology was becoming mature enough to give her group a process-oriented tool in addition to the Web services and enterprise application integration (EAI) tools widely used within Motorola at the time to help achieve three major goals: improve integration within the company, link departmental processes more closely and standardize processes across units where possible.
But for Motorola, the Savvion BPM tools it ultimately chose were not a silver bullet, but a way to do what the company has always done: think through the processes, test out different process approaches and then implement them. “Looking at processes is so important before you can do BPM. [Not doing so] is why a lot of organizations haven’t got much value from it,” Morrison says.
“You get in trouble when you start coding things, rather than modeling for the business processes,” concurs Judith Hurwitz, president of the Hurwitz & Associates consultancy. Drug distributor AmerisourceBergen takes a similar approach of assessing, modeling, testing and finally deploying. It too adopted BPM technology three years ago on a pilot project, and then in January 2006 acquired an enterprise license so it could use Metastorm’s BPM tools as it needed anywhere it needed, notes VP of Application Architecture and Strategy Peter Ruggerello.
To date, few companies have taken BPM to the level long-promised by vendors, in which BPM tools orchestrate end-to-end processes across a wide swath of the business. Not only were the tools missing some important attributes until recently but also, most companies applied BPM in niches. That’s starting to change.
The Workflow Automation Trap
While BPM leaders such as Motorola and AmerisourceBergen conceive of BPM as a way to orchestrate processes, most companies view BPM more narrowly, says Bill Swanton, a research VP at AMR Research—typically as document routing and approval tools for what is more accurately called workflow automation.
Workflow automation certainly delivers benefits, including reduced labor costs and greater consistency in how processes are executed. “Automation is attractive because it is cheaper in the early stages,” notes Robert Sheesley, a director at the consultancy Alvarez & Marsal.
For example, First American Property & Casualty Insurance started with a focus on document workflow, mostly to automate repetitive processes. But it also wanted to handle rapid growth without growing its labor force as rapidly, says CIO Jim Court. “We wanted to manage processes based on business events, not just documents,” he says. The company’s desire required integration with external data sources and applications, but more importantly, required an analysis of the current process and of proposed improvements.
Business unit experts and the IT group’s business analysts worked as teams on that analysis. Using Handysoft’s BPM tools, Court chose a pilot project involving policy endorsement requests; since the process flow is not linear, and there are several points involving human decisions, the project was truly about business process management rather than workflow.
Chester County Hospital, in West Chester, Pa., has also implemented BPM in a midlevel way. Although most medical management systems handle processes within them, they rarely handle process flow across application boundaries, notes Ray Hess, vice president of information management. These systems typically rely on staff to know all the possible steps to take based on, for example, a patient’s infectiousness or treatment plan. “That’s asking for trouble,” Hess says. So he’s deployed Siemens BPM tools to tie medical systems to databases, housekeeping systems, e-mail and so forth: Appropriate processes are triggered automatically based on entries in the medical records or results from lab tests.
For example, if a patient has been treated previously for an infectious disease, the new system ensures that certain steps relating to tests and isolation beds begin. The system also tracks the results of triggered processes. “We ‘listen’ for the actions, and in some cases if we don’t see them occur, we issue an alert,” Hess says. “The difference with BPM is that I can define the process to run based on our criteria, not necessarily on the application’s defined workflow.”
As was the case at First American, accomplishing this process orchestration at Chester Hospital meant integrating various systems and their data. And it also meant identifying, optimizing, modeling, testing and finally deploying the desired business processes.
Secrets to BPM Success
Fewer companies take BPM to the next level. “The real value is realized when you go beyond cost reduction and look at how human-to-human interaction can be systematized and lead to innovation,” says consultant Sheesley.
But there’s a problem with how business usually defines its processes, says consultant Hurwitz. “Even if people on the business side use business process modeling tools to come up with a new process, what they build is not related to the execution. The effort stops at the model, and the business people go to IT and say, ‘We need X, Y and Z,’” she says. IT has no insight into the metadata—the process context and business logic—and gets essentially requirements-based requests.
Fortunately, modeling tools from vendors such as IDS Scheer and Tibco Software are increasingly able to store a metadata layer, which IT can use to understand the process, what it’s actually meant to do and how it’s actually meant to work, she says. Some tools can also prototype a process without requiring coding, so business staff can show IT what they mean by their requirements.
Another issue is technological maturity. A few years ago, BPM tools couldn’t hope to address such a wide scope, notes Hurwitz. “But they have changed dramatically, with APIs for common applications, more use of standards and new architectures.” It’s time to look at them again, she says. (In some areas, BPM standards are still lacking—especially around handling the complexity of human-system interactions—but vendors and standards organizations are working to fill these holes. CIOs should not use such holes as an excuse not to apply BPM where it is capable, says AMR’s Swanson.)
Motorola and AmerisourceBergen have taken it to the next level—by focusing on the business processes themselves, rather than merely automating specific functions. Motorola emphasizes the work done by business managers and analysts involving process definition and optimization that happens before IT gets involved. Then business and IT staff spend much time together modeling the processes as they are developed, to test them out, says CIO Morrison. For example, after Motorola acquired Symbol Technologies, “We found BPM to be incredibly powerful to do scenarios of integration,” she says.
Some modeling tools can generate executable code that lets business staff essentially reprogram their processes without IT involvement. But this doesn’t mean IT is out of a job, says Charles Soto, Motorola’s senior director for enterprise platforms and integrated solutions. Motorola does generate code from its business process modeling tool, but not for production. This code serves as a reference for the business analysts.
One reason that IT doesn’t use this code to execute the actual processes: The applications being orchestrated and the data sources being manipulated are more complex than a model represents—requiring IT expertise to program. And IT can have the entire system picture in mind. “You need to create a BPM hierarchy that matches to that of the company; otherwise you create a spaghetti of integration from project to project,” says Soto.
This is especially true as your BPM efforts cross process domains, notes Motorola’s Morrison: “It’s across processes where you have different semantics, syntaxes and application idiosyncrasies.”
While industry analysts all recommend starting small, so IT can build the skills needed to effectively understand and develop processes as well as implement them, Morrison urges other CIOs to aim high once they’ve got their feet wet. “You could use BPM just within a specific domain, but that’s not where the challenges are.”
Too often, says Ron Wince, CEO of the business process consultancy Guidon Performance Solutions, companies that implement a BPM tool are left wondering why their ROI was so small or why their headcounts increased after jobs were supposed to be automated away. They didn’t choose the wrong tool, he says: They forgot that BPM is first and foremost about processes. However, other companies are demonstrating how to succeed with BPM—and proving that if you’re thinking of BPM narrowly, you need to regroup.
0 comments:
Post a Comment