You've read articles and white papers, sat in on Webinars and perhaps even attended a conference on business process management (BPM). Maybe you've even talked to people who have already gone down this road and examined ratings and reviews of leading products. You think you're ready to select a process management suite (BPMS), but you're not entirely clear on next steps.

This article takes you, step by step, through the BPMS selection process, from clarifying goals and objectives, and forming an evaluation team to structuring a request for proposal, evaluating demos and selecting the right suite.

Clarify Goals and Objectives

Once you're satisfied that key stakeholders have a shared understanding of the basic principles of BPM (see "Business Process Management 101"), it's time to clarify the overall goals and objectives of your BPM project. Most organizations have priorities such as a need to cut costs, increase customer satisfaction, improve compliance or integrate back-office systems.

At Tenet Healthcare, which operates hospitals and related health care services throughout the US, a BPMS was implemented in 2003 to support common pricing, supply chain and invoicing processes across multiple, disparate IT platforms. At the start of the project, Tenet mapped out where it wanted to go over the next three to five years.

"We wanted more self service, more flexibility in [process] design, and good fit with overall IT trends [like services-oriented architecture]," says Todd Coffee, Tenet's Director of Business Process Management. Support for self service enabled business people to make changes in processes without waiting for IT support, says Coffee, while process flexibility accommodated variations in business processes by city and state.

Be sure that you're clear on your goals and then take time to estimate quantifiable benefits you hope to achieve understanding, of course, that you will revise these estimate as you go through the selection and implementation process.

Form an Evaluation Team

It's essential to form an evaluation team that will collaborate on the RFP, the evaluation and the final selection process. The team should be small enough for effective decision making while including representatives from all key stakeholders, including business sponsors, product managers, business analysts, system engineers, IT architects, IT operations and the support desk. The input starts with finalizing goals and writing the RFP and continues through the vendor review, product demo and final selection and implementation phases. At Enterprise Rent-A-Car, a BPMS implementation completed early this year has turned a formerly paperwork-intensive IT product-and-service-request bureaucracy into a highly automated, online process. Constituents included representatives of the company's 65,000 employees as well as the 1,500-person IT team, but Pat Steinmann, Department Manager Request Services, says it was crucial to have high-level input from an IT architect throughout the project. "He ensured that we incorporated appropriate technical evaluation throughout the process so we didn't end up with a product that met our functional requirements but wouldn't play nice in our IT environment," she explains. "His input ranged from asking key technical questions in our RFP, so we could quickly eliminate incompatible products, through to the final step of conducting a technical proof-of-concept project with the product we selected."

When the evaluation team is ready to start drafting the functional requirements of the BPMS, it's useful to examine the specific problems your trying to address. You know you need BPM when…

-- Processes involve many complex steps
-- The business lacks process control and auditing features
-- Exception conditions are handled inconsistently
-- Transactions are plagued by high error rates
-- You can't view and track all process-related data and documents
-- Information flows slowly or inconsistently across the organization
-- Disparate IT systems are in need of integration
-- Processes require manual paperwork
-- Work in progress can't be traced across multiple departments
-- Reporting on work steps and end-to-end processes is cumbersome
-- Decisions take too long

Write the RFP

Once you've covered the basics of BPM, you will know whether your needs lie primarily in addressing human-centric or integration-centric processes. This knowledge will narrow the list of candidates at the outset, but the role of the RFP is to enable you to select a short list of qualified vendors. The RFP document itself should give vendors enough information to effectively outline how they will meet your functional and technical requirements in areas such as process modeling, simulation, document management, business activity monitoring, IT systems integration and so on. The document should also detail your expectations on the pace of development, the extent of training and ongoing support required, how upgrades are handled, time needed to become self-sufficient with the BPMS, and the ease of making ongoing changes to processes.

The RFP should force respondents to indicate whether they can or cannot meet specific requirements. (Determining just how they will meet those requirements will typically require a two-way conversation — something best dealt with in demonstration meetings once you've narrowed the field to a short list of candidates.) Accordingly, it's essential that the RFP clearly state which are absolute requirements that a vendor must have and which are important-but-not-essential requirements. Some organizations prefer to list the absolute requirements in a separate section, while others list the entire range and request that respondents indicate the extent to which they can meet each requirement on a one-to-five or one-to-ten scale. Regardless of the method employed, the absolute requirements should be crystal clear.

The balance of the RFP should drill down into aspects of the BPMS that will be critical for the specific process(es) you are planning to automate. For example, the RFP should drill down into document management and rules management capabilities if it's a claims process in an insurance setting or a funding evaluation process in a government setting. If it's a time-sensitive process such as recruiting or financial statement preparation, the RFP should delve more deeply into product features such as electronic alerts.

Hold Demo Meetings

The two fundamental questions to consider in reviewing the responses to the RFP are "to what extent will this BPMS tool meet our requirements," and "how much will it cost?" The answers should narrow the selection down to a short list of three to four vendors. The next step is to meet with the finalists so they can detail precisely how their suites will meet your requirements.

Product demonstrations and face-to-face discussion will enable your evaluation team to closely examine product features and vendor capabilities while learning more about the people behind each organization. Ask each vendor to explicitly show you just how the product and organization can meet requirements around modeling, document management, business activity monitoring, simulation, rules management, ease of process change, and ease of integration with your IT environment. Delve into the details on important specifics such as multiple language support, forms design and interfaces, records management, process tracking, portal architecture and so on.

The conversation with each vendor should enable the evaluation team to estimate expected benefits tied to improvements such as:

-- Faster processing time
-- Reduced data delivery cost
-- Easier access to documents
-- Reduced system integration cost
-- Better tracking and auditing of tasks across departments
-- Real-time monitoring of work in process
-- Automated alerts, escalations and actions
-- Elimination of paper-based processes, redundant logging, manual tracking and phone calls
-- Automated reporting on process bottleneck
-- Automated submission, routing, approval, and archiving of electronic forms
-- Improved compliance with regulatory guidelines
-- Improved adherence to budgets and profit thresholds
-- Simplified delivery of services

By the end of each demonstration meeting, the evaluation team should have sufficient information to assess the suitability of the BPMS, the expected pace of development, the time required to become self sufficient with the suite, and the quality of interaction with vendor personnel. In some instances you may need to schedule follow-up meetings so candidates can develop specific use cases or workflows specific to a particular process. Depending on the complexity of the initial project, you may even want to conduct a more comprehensive proof-of-concept project.

Make the Final Selection

The final vendor selection should be made based on hard and soft factors including:

-- Speed of implementation
-- Likely return on investment
-- Time to self sufficiency
-- The appeal of the vendor (its culture and people) as a potential partner

The pace of implementation will depend on factors such as the ease of integrating the BPMS into your IT environment, the complexity of the product, and the time needed for training. The return on investment will depend on the scope of the process(es) to be improved, hard and soft benefits, the required investment and time-to-break-even calculations.

If your firm has a history of making technology decisions based on high-level perspectives on what needs to be done, then you may not wish to invest a lot of time and energy in calculating expected ROI figures. However, if your leadership will want to see an ROI before approving the funding, you may have little choice. Accurate ROI estimates start with "baseline" estimates of current performance in terms of cost, time, quality and productivity. Only then can you gauge expected improvements. Cost-savings estimates are often expressed in full time equivalents (FTEs) based on eliminating manual work steps. Compressing the time to execute a process drives out cost, increases responsiveness and improves customer satisfaction. Similarly, reducing error rates lowers exception-handling costs while also improving customer satisfaction. Increasing productivity — as in handling more transactions with the same or fewer resources — has an obvious impact on the bottom line.

Framing The Benefits of BPM
(click image for larger view)

"Soft" benefits such as increased process visibility or reduced risk may be harder to quantify, but they should definitely be weighed in the final selection process. To evaluate the cost of each BPMS, consider the required investment in software, people, training and hardware. Pay particular attention to staffing, training, and other incremental costs in quality assurance, capacity planning and production-related areas.

Once the benefits and required investments for each BPMS are understood, frame the choices in terms that executives will understand and support. The table at right provides an outline you can use in detailing the benefits of a BPM initiative.

Embrace 'The Three Vs'

Does this seem like a lot of work? It is. How can you make it flow better? That depends on the three Vs: vision, value, velocity.

An overarching vision of your BPM objectives is not an absolute requirement, but it can be a powerful force in galvanizing people around a BPMS deployment. Value creation is an absolute must. The deployment of a BPMS must be directly linked to improvements in operational performance. Only when you can demonstrate that the first BPM project has delivered measurable results will other projects follow. Velocity of execution — the ability to rapidly adapt to changing business conditions — is the ultimate promise of BPM and it's something the BPMS must deliver.

Choosing the product that's right demands that you go beyond the basics. You have to ensure adequate input and collaboration and take time to estimate the benefits and costs of each BPMS candidate. What's at stake here? Nothing less than competitive advantage.

Andrew Spanyi is the author of two books on process management: Business Process Management is a Team Sport: Play it to Win! and More for Less: The Power of Process Management. Write him at [email protected]