Software Selection for Behavioral Health & Social Service Organizations: A New Focus on the Customer/Vendor Business Partnership (Part I)

Provider organizations in the behavioral health and social service field need technology to survive and thrive. Survival technologies help to reduce administrative costs, comply with regulations, and efficiently meet staff training requirements. The technologies needed to thrive in this exciting environment provide real-time communication with community-based staff, facilitate e-health services, and assist consumers in the recovery process. For executive teams, there are a vast number of vendor choices and technology solutions to navigate in a market that is constantly changing. New technologies appear every day. New players appear while other vendors are acquired or go out of business. How does an executive team sort through the choices?

The answer to that question is multi-faceted and involves many elements of strategic and marketing planning. In this article, we are going to assume those many decisions have been made and focus on one component: the selection of software. What used to be a simple software application installed in a single location can now be a technology solution that includes the use of wireless devices, disconnected databases, the Internet, and other software applications. The push for outcomes and information reporting, as well as electronic medical records,
is also complicating the software selection issue.

So, how best to approach the software selection process? Until recently, we have relied on a selection methodology based on functionality and price. The primary focus was on functionality – evaluating a vendor based upon how well its product met an organization’s detailed list of business support needs. Essentially, the “value equation” was how much functionality can be purchased for the price. Recently, we have modified our selection methodology, adding an assessment of the vendors’ ability to form a business partnership with the customer to the value equation. The reason for this shift is two-fold. First, many vendors have built a wealth of functionality into their applications; therefore, organizations no longer have to use functionality as their sole factor in decision making. (You are likely to discover that five to ten, or even dozens, of software vendors have robust functionality in all or most of the business areas that you need.) Second, given the growing strategic importance of technology in service delivery as well as administration management, vendor organizations are assuming a more strategic relationship with their customers.

Three Core Vendor Evaluation Factors

In our enhanced model, we recommend that organizations evaluate vendors’ products and services based on three core areas: customer responsiveness, functionality, and total cost. Customer responsiveness is complex. It can include a variety of factors – a vendor’s track record in training and implementation, customer satisfaction with the vendor’s products and services, the vendor’s responsiveness to enhancement requests and market demands, timeliness of help desk support, and rapid problem resolution. It incorporates the notion of the vendor as a partner, rather than that of simply a merchant. This approach reflects the growing strategic role of technology in service delivery.

The second core area of evaluation is software functionality – how well the vendor’s product meets the specific business needs of your organization. To evaluate this properly, you need a clear understanding of what functionality is available in the marketplace, as well as a detailed understanding of your business’ needs and operational goals.

The third key area is total cost. Note that this phrase is “total cost” and not just “price.” The price of software is but one element of the total cost. In the current marketplace, new models of pricing have emerged, including “leasing”-type models where purchasers pay monthly fees for software and services rather than purchase software licenses. Additionally, some vendors offer to “host” the application and databases for a fee. In assessing total cost, software price is considered along with maintenance fees, customization costs, installation costs, training costs, implementation costs, speed of implementation, and more. This expanding definition of “cost” also reflects the more complex role of technology. When evaluating vendors in this area, it is helpful to develop a three- to five-year budget for each vendor – including any technology upgrades and staff enhancements needed – so that you can accurately compare organizational costs.

With these three factors, the new value equation for software selection is:

Functionality + Responsiveness
Total Cost

While all three of these factors should be given consideration in making this decision, it is important to understand that these areas of evaluation are not the sole measurement in making a final selection. Rather, they are used to narrow the list of potential vendors to a group of finalists that will be evaluated further.

A Best Practice Software Selection Process

To operationalize this vendor evaluation model, we recommend an eight-step approach when reviewing software vendors and selecting a software application:

  • Step #1: Identify current/future required and desired software functionality
  • Step #2: Develop and release a request for proposal
  • Step #3: Conduct preliminary vendor screening based on knock-out factors
  • Step #4: Conduct current customer reference checks to gauge customer responsiveness
  • Step #5: Analysis of vendor functionality and total cost
  • Step #6 Conduct software demonstrations and select finalists by focusing on functionality “fit”
  • Step #7: Conduct additional research and evaluation on vendor to make a final selection
  • Step #8: Contract and implement

Step #1: Identify Current/Future Required & Desired Software Functionality

One of the keys to successfully selecting a software application is knowing what functionality your organization needs. Most organizations understand this concept and start this process by defining functional needs based on current operations. They identify opportunities for automation, enhanced reporting, and information sharing, as well as deficiencies in the current information system. However, this process is not enough! Future functionality needs should also be determined based both on your organization’s strategic plan and a comprehensive understanding of what functionality is available in the marketplace. This enables your executive team to identify opportunities to maximize the use of technology for competitive advantage.

For this reason, the first step in the software selection process has three components: a gap analysis of current functional needs versus capabilities, an assessment of future functionality needs based on your strategic plan, and an overview of what new products and services are available in the market place. The last item can be accomplished by attending trade shows where vendors exhibit, requesting marketing and promotional materials from vendors, or sometimes even issuing a request for information to gather basic information about functionality and services. The goal is not to evaluate the vendors, but rather to gain a better understanding of available technologies.

To conduct an assessment of current and future functional needs requires a detailed review of current operations and identification of software support needed the key functions, as well as a similar assessment of future operations outlined in your strategic plan. To develop a gap analysis, current functional needs are compared to current system capabilities. The result of this phase is a functional needs specification document that outlines current and future functional needs of your organization and presents a “gap analysis” of your current systems.

While the exact functional specifications may vary from organization to organization, there are common areas of functionality that you should review to determine which specifications are most important. These broad categories include:

  • Consumer and staff demographic and billing data
  • Scheduling and eligibility verification support
  • Service delivery data
  • Service billing capabilities – fee-for-service, per diem, inpatient, case rate, and/or capitated contract billing
  • Accounts receivable management
  • Electronic medical/case record functionality
  • Clinical decision support and outcomes management
  • Staff alerts, messaging, and tickler systems
  • System security functionality
  • Report writing functionality
  • Point-of-service system access

In addition to these standard service delivery supports, there are categories of functional needs that are specific to the types of services an organization delivers:

  • Consumer self-service and personal health information
  • Resourced-based appointment scheduling
  • e-health functionality
  • Foster and adoptive family tracking, licensing, and payment-based staff support tools
  • Volunteer matching and tracking
  • Service authorization and claims adjudication and payment
  • On-line training and credential tracking
  • Network provider management
  • Prescription and pharmacy management functionality

Step #2: Develop & Release a Request for Proposal

The second step is to incorporate your organization’s functional needs into a request for proposal (RFP). We recommend that the RFP specify the structure and content of the responses you wish to receive, typically including the following components:

  • Vendor Overview
  • Technical Requirements & Staff Support Recommendations
  • Software Platform
  • Training, Implementation & Support Processes
  • Software Functionality
  • Report Writing Functionality
  • Customer Reference Contact Information
  • Cost
  • Additional Information

Vendor Overview

Ask the vendor to describe its company, customers, and services, as well as what key qualifications they can offer to meet your technology needs. These answers give you a basic understanding of the vendor’s business. In the overview, you should ask for vendor financial information.

Technical Requirements & Staff Support Recommendations

Request that the vendor describe the hardware, software, network, and telecommunications set-up needed or recommended for its technology solution. This information lets you know what infrastructure you will need to support the vendor’s product so that you can develop the appropriate budgets. You may also want to ask for recommended staffing to support the application once it is up and running.

Software Platform

Ask the vendor to describe the software platform and/or databases used by its technology solution and any near- term plans for upgrade, if applicable.

Training, Implementation & Support Processes

Request a description of the vendor’s typical approach to training and implementation, as well as how it provides customer support. Specifically, request an implementation plan with an itemized list of activities, estimated manpower, and a timeline. This helps you to understand the time and effort that would be needed on your part to successfully implement the vendor’s technology solution.

Software Functionality

Provide a list of your functional specification needs, and ask the vendor whether its product supports each.

Report Writing Functionality

Ask the vendor to describe the report writing capability of its technology solutions, including a listing and description of standard reports and export capabilities.

Customer Reference Contact Information

Request a list of at least 25 customers who you may contact. Also ask the vendor to highlight some of those customers who are satisfied with its products and services and/or those whose needs are most similar to those of your organization.

Cost

Ask the vendor to detail the cost of its software technology solution. This information should clearly distinguish between one-time and on-going costs and be complete enough (along with the information from the Technical Requirements section) for you to develop a three-year budget for the proposed solution.

Additional Information

Include an optional section where vendors have an opportunity to share any other information they feel would be helpful to you in the selection process.

In the next issue, we will cover the remaining six steps in the software selection process, picking up at the point of issuing the RFP. From a preliminary vendor screening to making the final selection of a software package, we’ll provide you with a roadmap for future technology success.

To read the second article in this two-part series on Software Selection for Behavioral Health & Social Service
Organizations, go to www.openminds.com/eprint/2006/080106/080106b.htm.

By Joseph P. Naughton-Travers, Ed.M., Senior Associate, OPEN MINDS & M. Colleen Elmer, MSW, Consulting Practice
Leader OPEN MINDS

For more information contact Joseph Naughton-Travers, Ed.M., Senior Associate, OPEN MINDS, 163 York Street, Gettysburg, Pennsylvania 17257; 717-334-1329; Fax: 717-334-0538; E-mail: jnt@openminds.com; Web site: www.openminds.com; or M. Colleen Elmer, MSW, Consulting Practice Leader, OPEN MINDS, 163 York Street, Gettysburg, Pennsylvania 17257; 717-334- 1329; Fax: 717-334-0538; E-mail: celmer@openminds.com; Web site: www.openminds.com.

Elmer, MSW, M. Colleen, Naughton-Travers, Ed.M., Joseph P. (2006, July). Software Selection for Behavioral Health & Social
Service Organizations: A New Focus on the Customer/Vendor Business Partnership (Part I). OPEN MINDS, The Behavioral Health
& Social Service Industry Analyst, 18:4, 2-3, 10.

© Copyright 2004, OPEN MINDS

Show Buttons
Hide Buttons
Website Security Test