So … you're either in the market for your company's first human resources management system (HRMS), or you're ready to move up to a more sophisticated system, and you're struggling with whether to bring in the consultants or tackle the evaluation process by yourself. Can you do it yourself? The answer is yes, and maybe. It all depends on whether or not you can commit the time and resources to doing it right.
Be prepared for a fairly time-consuming process, ranging from at least three to nine months or more. You'll also need to recognize that it will require a considerable outlay of capital and staff resources to bring the project to fruition. Your company will have to live with your decision for the next eight to ten years or more, so you want to make sure that you do it right—the first time.
For starters, it will be extremely helpful to begin with a clean slate and an open mind. The less biased you are regarding a specific software vendor or application (either “for” or “against”), the easier it will be to make an objective evaluation and decision. In the last five years or so, vendors, software applications, and hosting options have undergone significant changes. Making a decision based solely on past experiences (good or bad) may be a disservice to your organization. Try to remain unbiased throughout the evaluation process. Whether you use a consulting firm to help you in your quest, or decide to strike out on your own, following a rock-solid methodology is the key to success.
User-Needs Assessment
The process begins with a user-needs assessment (UNA) to develop a wish list of features and functionality you expect the new system to deliver. In this phase, brainstorming sessions with each group of functional and technical users are scheduled to discover what they like about the current system, what they dislike about the current system, and what they are looking for in a new system.
There are various ways to build this information. Some people use questionnaires and surveys to collect this information, and some use the tools that software evaluation companies like Technology Evaluation Centers (TEC) offers to help organizations build their requirements. In addition to these tools, the interactive nature of face-to-face meetings with small groups of users allows useful information to be exchanged to help the decision process along. Some users may know exactly what they want out of a new system, while others may have difficulty envisioning their future needs. You'll have to facilitate the discussions and prod the users by asking such questions as “What are you doing manually today that would save you time if it were automated?”
While you're conducting these sessions, be sure to ask how new features and functionality will affect efficiency and productivity. This information will help you later when you prepare a cost-benefit analysis to justify the expense of the new software.
Next, take a look at some of the software vendors present in the marketplace. In the mid-market, there are no less than 20 vendors that could be considered “players” (prominent in the industry), and there are many more that are trying to enter this market. There is no way that you can evaluate all of them in depth, but there are some shortcuts that you can use to narrow down the choices.
One option available is to see what the analysts have to say about the major players in the HRMS software arena. Gartner's Magic Quadrant for HRMS, Forrester's Wave, or TEC's eBestMatch™ are all effective decision support systems offered by software evaluation organizations that can help you evaluate different vendors.
Another option is to attend conferences, such as those held by the Society for Human Resource Management (SHRM) and the International Association for Human Resource Information Management (IHRIM). These conferences usually have an exhibit hall, and the major HRMS vendors will each have a booth and product specialists on hand to discuss their offerings and to provide demos of their solutions. Often they will arrange a vendor shoot-out, where each vendor demos its solution to the assembled attendees, and the attendees decide for themselves which offers the best solution.
You can also use the Internet to research the vendors, but beware: this could turn out to be the equivalent of looking for a needle in a haystack. On the day I wrote this article, I did an Internet search on “HRMS software vendors,” and it returned 728,000 hits. You are going to either have to narrow your search, or be prepared to do a lot of surfing.
One other way is to do some sleuthing and try to find out what your competition is using. There are several vendors that have carved out a niche in the marketplace, and that have specialized solutions tailored to specific market verticals (such as health care, professional services, manufacturing, etc.)—a case of “birds of a feather …” This research should allow you to narrow your choices down to a handful of promising vendors. Call each one to request a copy of its company's current product information, and see if it has an online demo to provide a high-level familiarity of its products. This should help you come up with a shortlist of perhaps three or four prospective vendors.
Breaking with Tradition
Traditionally, the next phase of the project would involve issuing a request for proposal (RFP), in which you would draw up a list of high-level requirements and submit it to a large list of HRMS software vendors. After reviewing your requirements, interested vendors would notify you if they were interested in competing for your business.
This approach is time-consuming because you have to wait for vendors to complete their reviews of your requirements and contact you with their intentions. The next step would be to draft a request for information (RFI) to send to those vendors that chose to compete. The RFI should describe your requirements in more detail, list your project goals and objectives, provide a high-level project timeline, and request background on the vendor (including information about its proposed solution, the technical architecture employed, implementation approach and methodology, hosting options or partners, references, testimonials, and pricing strategies).
I recommend skipping the RFP, and start contacting the three or four short-listed vendors that you feel may have the best solution for your needs (based on your research). Your goal is to determine their willingness to conduct a scripted demonstration (versus a canned sales demo). This requires the vendor to “script” (prepare with detail) the demo according to your specific needs and scenarios.
Once you have the vendors' commitments, you can then send them a detailed RFI, and schedule the scripted demos. By skipping the RFP process, you can reduce the project timeline by as much as a month.
Scripted Demonstrations
The scripted demo is the heart and soul of the evaluation process. What's the difference between a sales presentation (a canned demo) and a scripted demo? In a canned sales demo, you typically see only what the salesperson wants you to see. Salespeople usually spend a significant amount of time focusing on what they feel are the product's strong points, glossing over any shortcomings. By requesting a scripted demo, you detail to them what functionality is important to you and what you want to see. This puts you in the driver's seat and evens the playing field. Since all of the vendors will be addressing all of the same scenarios in the script, it will be easier for your team to evaluate each vendor's ability to meet your company's needs.
Let's look at the scripted demo in some detail. In order for the vendor to provide an effective scripted demo, you need to develop an accurate script for them to follow. You will need to draft a scenario that describes your problem and your needs. You do this by examining the business functions you want to address. Next, you'll need to describe what these tasks are and how they are currently done, and then describe how you envision them in the desired state using the vendor's solution—that is, your expected results. (Refer to Table 1 for examples of scripted scenarios).
(Click here for larger version)
Table 1. Sample scripted scenario (Collaborative Solutions Consulting, 2007)
In drafting your scripts, you'll combine the results of your UNA with any additional input from the user groups. Make sure these scripts represent real-world, daily scenarios. Even though these demos should be scheduled as daylong events, the demos will not be able to demonstrate every scenario in human resources (HR) and payroll. Focus on the processes that represent the most important functions, as well as the painful manual processes that you really need to automate. Here is a shortlist of considerations based on some typical scenarios:
- How does the vendor provide online help?
- How can workflow automation (with approvals) streamline your current processes to increase productivity and improve efficiency?
- How will the vendor's solution interface with other systems in your organization to improve data integrity and reduce redundant data entry?
- How does the vendor's solution handle what-if modeling?
- How does the new system handle “a day in the life of …” functionality for the HR and payroll staff? For example, how does it handle everything from a line manager opening a requisition, to scheduling interviews, all the way to taking applicant data and automatically converting it to employee data without having to re-key the information?
The RFI (including the scripted scenarios) should be sent to the vendors on a staggered schedule, providing each vendor about two weeks to prepare for the demo (counting back from the date the demo is scheduled). This approach ensures that no favoritism is shown to the final vendor. If you don't schedule in this way, the first vendor may have two to three weeks to prepare, while vendors scheduled for later may wind up with two or more additional weeks to get ready for their demos, putting the first vendor at a possible disadvantage.
You'll need to make it perfectly clear to all of the vendors that they may only demo functionality that has been released for general availability (GA). They should be instructed to not demo beta releases or versions that are still in testing. If you are interested in future functionality, try to program time at the end of the day so there is no possibility of erroneously believing that it is delivered with the current release the vendor is offering. Also, tell vendors that if they make any customizations to their delivered systems to accommodate any of the scripted scenarios, they must disclose this to your team, along with the estimated effort (time, resources, and funding) required to provide this capability on your system.
Demo Evaluations
Next, you'll need to provide the attendees a demo score sheet to use to evaluate each vendor's demonstration. The score sheet should outline the business functions being addressed, such as applicant tracking and recruiting, onboarding, benefits administration, training administration, payroll, etc. You will also need to provide a short description of the scripted scenarios, a description of your desired results, and a blank column for each vendor so that the evaluators can jot down their notes and scores regarding their impressions of how each vendor solved each scenario.
When all of the demos are completed, your decision should be based on the following:
* the functionality of the software;
* the degree to which it satisfied the needs of each user;
* the technical infrastructure required to operate and deploy the software;
* platform and database compatibility (if applicable); and
* adequacy of the hosting solution (if applicable).
Note that at this stage, cost should not be a driving factor because it has a tendency to cloud the evaluation process. At this point, your prime objective is to find a solution that satisfies the above criteria. Most of the vendors in a specific tier will be within the same or similar price range (depending on whether the cost is per module or based on a bundled solution). Once you've determined which vendor best meets your needs, it will then be up to you to build your best business case to support your decision. Pricing will be included with the vendor's response to the RFI.
Evaluating the Vendor's RFI Responses
Evaluating the RFI response is perhaps the most laborious and dreaded task of the entire evaluation process. RFI responses typically come in one or two binders, containing everything from marketing collateral and testimonial to detailed technical specifications and pricing. I recommend that you break down the response and delegate the reviews or comments to each of functional or technical sections addressed in the RFI. Then you should schedule a session that brings all of the reviewers together in an open forum to discuss their findings and concerns.
Now that the demos are complete and you have reviewed the responses to your RFI, it's time to tally up the scores from the scripted demo score sheets (along with any weighted factors you may have assigned) and review the comments collected. This will provide you with a mathematically derived, objective winner. This usually—but not always—corresponds with the popular vote. If it doesn't, you'll need to discuss why there is disparity. By this time, you should have produced a hierarchical listing of software (from most desirable to least desirable).
Dollars and Sense
Eventually, someone will ask the all-important question: “How much is this going to cost us?” At this point, you will have all of the vendors' pricing structures in a comparison spreadsheet. The pricing that was requested should reflect the total cost of ownership, including required hardware and software, maintenance, implementation, training, and hosting. If you don't have carte blanche (full power to decide)—and you probably won't—you will have to make a solid business case to support and justify your selection.
First, you'll want to explain that the proposed HRMS-payroll system is not simply a repository of mandated personnel- and payroll-related information. The system should be viewed as an essential management tool that can be used by all decision makers in developing the organization's key strategies and business goals.
It will be your responsibility to demonstrate how the system will provide management with tools to perform staff budgeting and forecasting better and faster, as well as what-if analysis for compensation and benefits. You will need to show how the entire HRMS-payroll staff will be able to work more efficiently and be more productive through the automation of many of the current manual and repetitive tasks. If all of these factors are addressed and considered, your organization's key decision makers should see a greater necessity for the preferred system, even if it is more expensive than the other systems evaluated.
To prevent your case from being rejected, you need to develop a strategy that will capture the hard costs and savings of a new system in addition to its soft costs and savings.
Hard costs are relatively easy to define and include software, related hardware (including new workstations), maintenance fees, training costs, and consulting fees (for the implementation). Hard savings can be calculated in reduced head count; outsourced functions brought back in house; funds saved by not having to maintain an archaic legacy system; reduced printing and mailing costs through Web-based, self-service benefits open enrollment instead of paper enrollment; and the elimination of interactive voice response (IVR) and paper forms to make changes to employee records in favor of the new employee and manager self-service.
Soft costs and soft savings are tougher to get your hands around. Soft costs are incurred when an organization doesn't implement a new system that allows it to realize soft savings, such as
* the use of effective dating (which streamlines the process of time-sensitive data entry, especially pay- and benefits-related data, such as benefits deductions and pay increases);
* the use of online performance appraisal processing (which streamlines the process, reduces the likelihood of forgotten appraisals, and provides timely input to payroll for raises);
* the ability to use what-if analysis in forecasting staffing needs and budget analysis;
* the automation of benefits enrollment by employees using self-service, so that this information does not have to be captured on paper and then keyed into the legacy system by the HR or benefits staff.
Nailing Down Total Cost of Ownership
If it wasn't clearly defined in the response to your RFI (and some vendors are very good at glossing over some of the more obscure costs), you'll want to ensure that you ask vendors these questions:
* Is the listed price for the software based on a la carte selection (the total of each separate price of each feature or function) of the modules you picked or a bundled pricing strategy?
* If it is not a bundled price, what is the vendor's per module pricing strategy, and what is its multiple product discount?
* Is the pricing based on actual named users, an unlimited user's license, or the number of active employees tracked in the database?
* Does the listed price include installation of the software and implementation of the system?
* Does the price include a fit/gap analysis or design sessions?
* Are the fees for software application maintenance listed as separate line items?
* Will you require any third party or ancillary software or hardware, such as scanners for resume processing, time card readers for time capture, or special printers for printing paychecks in house?
* How did the vendor price the development of required electronic interfaces?
* Did you receive a separate cost breakout for data conversion?
* Does the cost of the system include vendor-conducted application training?
* Has the cost of any additional hardware been factored in (that is, new database, Web, or application servers; upgraded or new workstations; additional bandwidth of Web access for self-service, etc.)?
Reference Checks and Site Visits
No software package or implementation is without flaws. It doesn't cost you anything (other than a few long-distance phone charges) to speak with someone who has implemented your preferred software package. Ask your software vendor for several references, preferably organizations that are within your industry and similar in size. Ensure that you speak with representatives from both sides of the house—functional and technical—in order to get the full story. Ask them questions that will make a difference in a successful implementation. You'll want to focus on the following key points:
* performance issues of the system;
* duration of the implementation (from installation to going live);
* challenges encountered during the implementation;
* adequacy of the training provided by the vendor; and
* vendor support during and after the implementation.
Along with the reference checks, try to visit at least one site in person. Seeing your preferred software solution in action has much more impact than seeing it as a demo. In addition, speaking with actual users will provide you with considerable insight into the general direction of your future implementation and operations. Take advantage of this opportunity to absorb everything you can. By hearing the trials and tribulations of other organizations' projects, you may be able to capitalize on their errors and learn from them.
Conclusion
As the title of this article suggests, “it ain't rocket science,” but evaluating and selecting a new HRMS-payroll software solution does require a considerable amount of planning, execution, and monitoring. If you put together a solid plan and follow it, you can make the right decision regarding your next system.
No comments:
Post a Comment