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.