Steps to Selecting a HRIS

Steps to Selecting a HRIS
Based on Article by: John Ryder, Lois Schwartz, and Jean Andrews

18 STEPS TO SELECTING A HUMAN RESOURCE INFORMATION SYSTEM
Selecting a HRIS HRIS selection is invariably a more complex process and has long-term consequences for an organization. What happens when you are the person responsible for selecting a new HRIS? How do you approach this type of project? What is the process and what are the pitfalls? The process that follows has 18 discrete steps. Some steps may be combined or performed concurrently, HR professionals will optimize their selections by following the process as presented. 18 STEPS TO SELECTING A HUMAN RESOURCE INFORMATION SYSTEM John Ryder, SPHR, Lois Schwartz, and Jean Andrews August Reviewed June 2000 Technology has dramatically altered the lives of human resource professionals over the past 15 years. Today, much of what used to be time-consuming manual processes are performed by computers, freeing us to work on higher value activities. And the demand for technological solutions to human resource issues increases each year. What happens when you are the person responsible for selecting a new human resource information system? How do you approach this type of project? What is the process and what are the pitfalls? This paper is designed to give human resource professionals a blueprint to follow for any type of human resource software selection, from stand alone applicant tracking systems to fully integrated HRIS and Payroll solutions. The process that follows has 18 discrete steps. Software selection is invariably a more complex process than we originally estimate and one with long-term consequences for an organization. It requires a careful and thoughtful approach to fully address the issues and impacts related to your decisions. Some steps may be combined or performed concurrently, but the authors strongly believe that human resource professionals will optimize their selections by following the process as presented. Step 1 - Teamwork Congratulations. You've been selected to head up the project to select a new software package for your human resources department. Where do you begin? Most organizations start by forming a team to manage the software selection process and we strongly recommend that you form a 3 to 7 person team to oversee your selection. There are a myriad of issues to consider and software selection is definitely one area where the quality of the decision is improved by having several people involved in the evaluation and decisionmaking process. Who do you include on the team? Look at who the key users and stakeholders will be for the new application. Include a knowledgeable member of your Information Technology staff from the very beginning and make sure that you have appropriate management representation so that as costs are developed, you will not find yourself in a situation of delivering "surprising" news at the end of the evaluation process. Larger organizations may also have a "Steering Committee" separate from the project team. Steering committees typically consist of the decisions makers - management who will sign off on the costs, participate in contract negotiations, support the project team and provide visible top level support. Step 2 - Goals At your initial team meeting(s) begin by identifying and agreeing on the goals for the project. Without a set of fully developed goals at the beginning of your search, you will either waste significant time evaluating the wrong products, or, even worse, select the wrong software. Ask the team to fully answer the following questions: What is your overall HR information technology strategy? What do you need and why do you need it, what system functionality do you need? What results do you wish to accomplish with this effort? What work processes do you wish to change through this selection and what should the new processes look like? What are the business drivers for the new system, how does this system support the overall needs of the business? Identifying goals may include interviewing senior management, others in HR and clients to identify the "right" needs for your organization. Step 3 - Big Picture Once your goals are developed, take a step back and ask how they fit into the bigger picture of your overall human resource information system. If you are looking for a specialized application such as applicant tracking or COBRA management, make sure that you consider how it will need to integrate with other applications such as your main HRIS. Are you trying to solve only one problem when you have other software issues to address that should be considered at this time? If you're selecting a new HRIS, does it cover all of specialized needs you have such as COBRA and HIPAA compliance or training records management? How does this application fit with your HR IT strategy? Step 4 - Future Needs Ask what your information system needs will be in the next few years. What other applications will be needed? When will you need them? Will they share the same information needs as this application, i.e. employee id, ssn, date of birth, name, address, etc? If so, how will you prevent having to enter the same data into different applications in future years? Are you planning to move to web based applications and if so, is this the time to begin moving in that direction? Are any major business processes going to change either as a result of this selection or in the near future? Where do issues like employee self service and manager self service fit into your overall strategy? Step 5 - Technical Environment It is absolutely critical that you define the base technical environment for the new application before you begin to look at any specific products. This is an area where your Information Technology representative plays a key role. The questions that need to be answered include: what type of application are you looking for, stand alone PC, networked client/server, or mainframe. What operating system does it need to run on -- Windows NT, Unix, etc.? If it's a database application, what database does your company support, SQL, Oracle, DB2? How will it connect to remote offices? Does it need to be web deployable? Does it make a difference what language the application is programmed in such as C++ or Visual Basic? Is your IT department planning a major change in technology platforms in the next year? Step 6 - Budget Budgets can be hard to define before you speak with any vendors but you need to at least define some ballpark estimate of what your organization is willing to pay before you start talking to vendors. A key item to keep in mind during budget definition is to separate your costs into three areas: software, hardware and implementation. Software includes the actual software licensing fee and other software costs for items such as database licenses and annual maintenance costs. Hardware is what you will need to spend for servers, PCs, and network upgrades. Finally, implementation costs encompass the money you will spend for configuring the software, training, and data conversion including the possible need to hire consulting services from the vendor or third party consulting firm to help in implementation. Step 7 - Specs Now that you've completed the first 6 steps, you're ready to develop a written specification document for your new software package. The specification should begin with your overall HR IT strategy, list your project goal, define the base system functionality that you require, specify how it needs to integrate with other systems, and list the technical requirements developed in step 5. This is a key deliverable for the overall project. If your specification is clear, specific and well defined, your selection process will be relatively painless. However, if you remain unclear on goals, functionality or the technical environment, then you're not ready to move forward. Step 8 - Build vs. Buy At some point during the process, most organizations address the issue of whether they want to develop the application internally or purchase commercially available software. This issue may be considered as early as step 2 or 3 and as late as step 15 or 16. We don't think it should come any later than step 8 because it is typically both an emotional and confusing debate and one that can sidetrack your process indefinitely. Many organizations have successfully developed their own human resource software. Many more have been less than successful in such efforts. When the issue arises in your process, ask the following questions: Are the necessary IT resources available internally for this project? Does the human resource staff have the time and expertise to develop detailed system specifications, screen designs, system edits and reporting requirements? What priority will it be given by IT management compared to other business systems? What is so specialized about your needs that you can't get 80% of your requirements with commercially available software? Finally, if your Information Technology staff develops any preliminary budgets or schedules for doing the job internally, experience says that you should double both and you will have a more realistic estimate to compare against the commercial products. Step 9 - Research Now you're ready to start identifying vendors and products that could meet your needs. How do you locate information on vendors and products? The obvious starting point is to talk to your colleagues in other companies for recommendations on products they have used that fit your general needs. Another source is the internet. Here are four websites that have extensive vendor/product lists: and IHRIM also produces a reference booklet for their members "IT_Matrix, Integrated HR Applications". It can be purchased from HRMS Directions at or The annual SHRM and IHRIM conferences and most state HR conferences also include vendor exhibits where you can talk with a variety of software vendors. Step 10 - Literature Hopefully your research has generated a good list of potential vendors. The next step is to contact each and get some product literature. Vendors supply different levels of information in their brochures, some are very high level without much detail, and other pieces are more informative. Make sure that you specifically ask for literature containing the level of detail you need. This is a key step in the process and should not be skipped because it should reduce your potential vendor list to a manageable number. Some vendors will drop out when you call for literature and you find out their product isn't available to fit your technical platform, or it really doesn't meet your needs. You will eliminate some after reviewing their literature and determining that the product is not as close a match with your technical specifications as others. One note of caution about this step, many vendors will want to schedule meetings when you contact them for literature. Don't meet with vendors yet, you're not ready. Limit them to sending you as much information as they can, and let them know that you'll contact them if you have further interest. Step 11 - RFP Now you're ready to develop and send a request for proposal (RFP) to your smaller list of target vendors. RFP's can be one page in length or ten or more. You will need to decide how much detail you want prior to seeing product demonstrations. Smaller companies may want to use a simplified 1 or 2 page request for information (RFI) that requests less information and has more flexible response guidelines in order to expedite this stage. Larger companies and those in the public sector most typically will use a formal RFP process. The most common elements in an HRIS request for proposal include: An overview that describes your company, A description of your software need and the employee population it will support, Desired system functionality, Required technical environment/specifications, A request for pricing (licensing fees, maintenance charges, training and implementation support, annual maintenance fees and telephone hotline support), A request for customer references, Details on customer service/support available from the vendor, A request for sample contract terms. Once you have assembled your RFP, send it to your vendor contacts and give them a reasonable period of time to respond, typically 3 to 6 weeks. Some vendors will supply you with a "sample" RFP if you request one, which you can then modify for your specific system needs. The RFP needs to contain guidelines for the vendor response such as: Are each of the required features currently in their system? Are certain features proposed in a future version of the system? Will any of your required features require system customizations and if so what are the costs and problems associated with the customizations? Always be aware of your "special needs" and the extra money and effort it will cost for implementation and future support. Work hard to modify your internal processes to match the software before embarking on customization. Step 12 - Evaluate As the RFP's are returned, you will want to have a common basis for evaluating all of the proposals. A typical approach is to create a spreadsheet with all of the items in the RFP as your column headings and the vendors listed on the rows. Then you would assign a value to each RFP item (yes/no, a dollar value, or a numerical ranking of some type) for each vendor. Once you have received all of the proposals and entered the data on your spreadsheet, then the team can meet, review the evaluations and select the vendors they want to schedule for product demonstrations. Step 13 - Demos Software product demonstrations, by their very nature, are designed to showcase the best attributes of the product and downplay the limitations. You can and should control product demonstrations to try and get as accurate and unbiased information as you can from what is clearly a major sales event for the vendor. How do you control the product demonstration? You control the demonstration by modifying the vendor's agenda. All software vendors have standard product demonstrations -- don't accept the standard demonstration. By this point in the process, you should have a strong grasp of your needs and issues. Create a list of specific questions/trends for the demonstration that focus on your issues and concerns and provide it to the vendor in advance of the meeting. In this way the vendor can include your issues as part of their overall demonstration and you should get a more unbiased look at the product. All of your team members should be involved in the demonstration and the team should agree in advance on specific issues that each member will ensure are addressed during the demonstration. Step 14 - Evaluate Again After you have completed your initial product demonstrations, it's time for the team to meet and evaluate the products based on all of the information you have at that point. Have each team member list the likes, dislikes, concerns, and unresolved questions that they have concerning each product. You may need to have one or more vendors provide some additional information before you move forward. You also need to be concerned about pricing differences at this point in the process. However, do not assume that you have the "final" price from each vendor. As the vendors learn more about your specific needs, they may be in a position to refine the pricing submitted with their RFP. Finally, narrow your vendor list to 2 or no more than 3 vendors. Invite those remaining vendors back for a second product demonstration. Step 15 - Decision Points You've seen all the products once and have the preliminary pricing proposals. It's time for the team to start discussing the items that will drive your final decision. In most software selections price is one of, but not the only, selection criteria. Other obvious decision points may include differences in functionality and compatibility with existing systems. For many companies, implementation costs and timeframes are critical decision points. One word of caution, be certain that your management team representative is heavily involved during this discussion as the team needs to be very sensitive to the items that will influence the eventual approval or disapproval of their recommendation. Step 16 - Check References Now it's time to start checking references on your finalists. Your team should develop a list of questions that they would like answered by each reference. Questions should cover any areas of concern that you have with the product, product functionality, implementation, problems the reference has encountered and ongoing support. Make sure that you understand the technical environment of each reference, i.e. Windows NT, Unix, AS/400, etc so that you can identify issues that may or may not apply to your situation. Listen carefully to what is said and not said by the reference. If you can get references in the same geographic area in which you work, try and visit the reference's business to see the product in action and talk to the actual users. It is best to check all of the references before the second demonstration so that issues that come up during this process can be addressed at the time of the next demonstration. Step 17 - Demo Again As with the first demonstration, set the agenda. The team will have specific items that they want to see again or need to have clarified. These items should form the basis of your second demonstration. Make sure that your management team representative is present at this demo. Your IT representative should ensure that all technical issues are resolved at this time. Review core functionality, reporting, processing time, implementation schedule and costs, customer support, issues raised in the reference checking process and any specific concerns of the team. You should also review each item in the pricing of the product with the vendor's sales representative. If you have any concerns about the pricing portion of vendor's proposal, now is the time to express them so that the vendor has a chance to clarify this critical issue before you make your decision. If you do not get everything resolved to your satisfaction during the second round of demonstrations, do not be afraid to bring one or more of the vendors back for a third demonstration. Step 18 - Evaluate Again & Select The demonstrations are finished, all the questions have been answered, it's time to make a selection. Before everyone decides to vote, take a step back and evaluate the information you learned in the second round of product demonstrations. Compare what you've learned to your initial goals and product specifications. Create a matrix of how each product evaluates against your decision points. If you've done a thorough job of learning the strengths and weaknesses of each product, established clear goals and product specifications and you've been aligned as team from goal setting through final demonstrations, then you should have an easy time reaching consensus on a product recommendation. In some situations, you will have two systems that meet your needs. In that situation, begin contract negotiations with both companies and work on negotiating the best package for your company - software price, training credits, implementation assistance, etc. Remember that making the right selection is only phase one of your project. A successful implementation that achieves your goals is the real challenge. August Reviewed June 2000 2

18 steps to selecting a HRIS Where do you begin?
Step 1 - Teamwork Start by forming a team to manage the software selection process To form a 3 to 7 person team to oversee your selection. Who do you include on the team? Look at who the key users and stakeholders will be for the new application. Include a knowledgeable member of your Information Technology staff from the very beginning and make sure that you have appropriate management representation so that as costs are developed, you will not find yourself in a situation of delivering "surprising" news at the end of the evaluation process. Larger organizations may also have a "Steering Committee" separate from the project team. Steering committees typically consist of the decisions makers - management who will sign off on the costs, participate in contract negotiations, support the project team and provide visible top level support.

18 steps to selecting a HRIS
Step 2 - Goals Begin by identifying and agreeing on the goals for the project. Ask the team to fully answer the following questions: What is your overall HR information systems strategy? What do you need and why do you need it, what system functionality do you need? What results do you wish to accomplish with this effort? What HR processes do you wish to change through this and what should the new processes look like? What are the business drivers for the new system, how does this system support the overall needs of the business? Identifying goals may include interviewing senior management, others in HR and clients to identify the "right" needs for your organization.

Step 3 - Big Picture Once your goals are developed, take a step back and ask how they fit into the bigger picture of your overall IS. If you are looking for a specialized application such as applicant tracking make sure that you consider how it will need to integrate with other applications such as your main IS. Are you trying to solve only one problem when you have other software issues to address that should be considered at this time? How does this application fit with your HR IT strategy?

Step 4 - Future Needs Ask what your needs will be in the next few years. What other applications will be needed? When will you need them? Are you planning to move to web based applications and if so, is this the time to begin moving in that direction? Are any major business processes going to change either as a result of this selection or in the near future? Where do issues like employee self service and manager self service fit into your overall strategy?

Step 5 - Technical Environment Information Technology representative plays a key role. The questions that need to be answered include: What type of application are you looking for, stand alone PC, networked client/server, or mainframe. What operating system does it need to run on -- Windows NT, Unix, etc.? If it needs/uses database application, what database does your company support, SQL, Oracle, DB2? How will remote offices get connected? Does it need to be web deployable? Is it open source? Is your IT department planning a major change in technology platforms in the next year?

Step 6 - Budget What your organization is willing to pay before you start talking to vendors. Separate your costs into three areas: Software: includes the actual software licensing fee and other software costs for items such as database licenses and annual maintenance costs. Hardware: what you will need to spend for servers, PCs, and network upgrades. Implementation: encompass the money you will spend for configuring the software, training, and data conversion including the possible need to hire consulting services from the vendor or third party consulting firm to help in implementation.

Step 7 - Specification Develop a specification document for your new software package. The specification should begin with your overall HR IT strategy, list your project goal, define the base system functionality that you require, specify how it needs to integrate with other systems, and list the technical requirements developed in step 5. If your specification is clear, specific and well defined, your selection process will be relatively painless. However, if you remain unclear on goals, functionality or the technical environment, then you're not ready to move forward.

Step 8 - Build vs. Buy It is typically both an emotional and confusing debate. When the issue arises in your process, ask the following questions: Are the necessary IT resources available internally for this project? Does the human resource staff have the time and expertise to develop detailed system specifications, screen designs, system edits and reporting requirements? What priority will it be given by IT management compared to other business systems? What is so specialized about your needs that you can't get 80% of your requirements with commercially available software? Finally, if your Information Technology staff develops any preliminary budgets or schedules for doing the job internally, experience says that you should double both and you will have a more realistic estimate to compare against the commercial products.

Step 8 – (Contd.) Best of Breed or Enterprise Wide Solution? During the phase above when you are determining the corporate strategy for technology platforms, it usually becomes apparent if your company has a preference for Best of Breed or if they have a philosophy of buying Enterprise Wide software applications. With Best of Breed (BoB), an organization can search for and buy the best solution possible that meets both your functional and technology requirements. Not to take this too far, it would not be advisable to buy separate systems for HR and Payroll applications. HRMS Needs Analysis "Behind Every Successful HRMS Implementation, There Was a Thorough Needs Analysis". You can quote me on that! I cannot back that statement up statistically, however, after over 25 years in the business and 10 years of listening to IHRIM (International Association for Human Resources Information Management) members share "war stories", I am totally convinced that the amount of time spent on a thorough needs analysis before purchasing and implementing a new HRMS is the best barometer for predicting the success or failure of the project. Unfortunately, in hearing all these war stories, I have been hearing far too many of the sad tales where the "battle" was lost due to any number of perceived problems, but when quizzed on specifics, most of the failures seem to related to the lack of up- front work prior to purchasing the new system. All too often the story-teller has related the age-old problem of "not enough time" and the decision to buy being based on the positive reaction to one of the sales presentations by a vendor. I doubt if any of us in our personal lives would make a major investment such as a new car or new house without first making a list of our needs, so why, when making an investment that could cost a great deal of time and money do we rush into such a major decision? Just like buying that new car or house, it is all a matter of sitting down and deciding what it is we are looking for. Of course it gets a bit more complex when other parties are involved, but so does personal shopping for major items, when the spouse, family members, friends, etc. need and expect to have input. Ultimately you build a consensus with your colleagues and you develop a shopping list. Sticking to that shopping list will ensure that you end up with the best fit for the purchase you are making. Two areas that must be dealt with up-front are the corporate Technology Strategy, and included in that but a major concern in itself is the decision to go with "Best of Breed" or to buy an "Enterprise Wide" system. TECHNOLOGY STRATEGY: Knowing the technology direction of your organization will make life much simpler in your search for a new HRMS, it narrows down the choices to be made. For example, if preparing an RFP (Request for Proposal) for a new system for a medium to large-sized company, you would be faced with sending it to over 35 major vendors. Why is this a problem: well, number one, you are going to have to review and evaluate all those responses! When you can identify the technology platforms your company will be working with in the future, you will be able to narrow down the list of vendors to work with. To ensure you have included all the vendors who might meet your needs, consider first sending out an RFI (Request for Information). At this time you can send out a shorter (shorter than an RFP) document that details your technical platforms. Those vendors who have software solutions in this area will reply in the affirmative and you can then deal with the shorter list of suppliers. BEST OF BREED or ENTERPRISE WIDE SOLUTION? During the phase above when you are determining the corporate strategy for technology platforms, it usually becomes apparent if your company has a preference for Best of Breed or if they have a philosophy of buying Enterprise Wide software applications. With Best of Breed (BoB), an organization can search for and buy the best solution possible that meets both your functional and technology requirements. Not to take this too far, it would not be advisable to buy separate systems for HR and Payroll applications. It is assumed in these days of integration that the software solution you are searching for will handle both of these major requirements. However, the vendor with the best solution for your HR/Payroll needs may not have the best solution for your Financial, Purchasing, Distribution, or Manufacturing needs. Indeed, the vendor you choose may not even address those areas. Major software vendors now tend to sell most or all of the Enterprise Wide applications mentioned above. This is the trend these days, away from specializing in just one product line. The case for Enterprise Wide applications grows stronger with the move away from "silos" of business activity. For example, no longer is the HR system considered the domain of the Human Resources department, but rather it is seen in the larger corporate context with line managers and indeed employees wanting access to HR information. Many organizations today are re-engineering their business processes and show a preference for software solutions that work in many functional areas. Without going into the pros and cons of Enterprise Wide systems, it will suffice to say that they save time by reducing the duplication of information and that the information is made available in the company wherever it is required. Additional benefits are: a common look and feel; a common report writer; and, shared technology. Finally, Enterprise Wide solutions generally make for efficient use of Work flow technology, enabling the organization to effectively re-engineer the business. PAYROLL IN HR OR FINANCE? This question is not quite as old as the "chicken or the egg" scenario but it certainly has caused more tension in organizations than the poultry debate. Surveys have shown that the majority of organizations have Payroll reporting to Finance, however the trend is to move Payroll to an HR reporting relationship. In either case, it must be a given that Payroll and HR applications go hand in hand and that any successful HRMS project will depend a great deal on the mutual cooperation of these two groups in clearly defining their requirements collectively. WHAT NEXT? CRITICAL SUCCESS FACTORS (CSFs) When a project starts out to select and implement a new HR system, it is a good idea to ensure that all the key players are on-board and their input has been considered. Not only does this help to identify requirements that may have been missed, but it guarantees some degree of buy-on and support from key individuals in the company. Who are the key players? In most cases, this will be fairly evident to a project manager or steering committee. A general rule of thumb for almost any sized company: senior HR practitioner the individual/s that the senior HR practitioner reports to each functional HR manager (e.g. Compensation, Training, OH&S, Pension, Benefits, etc.). senior Payroll representative senior financial officer/s sample of senior line managers - "clients" or "users" of the current and potential new system. senior Information Technology representative. What information to collect from these individuals? What are the key expectations of each of these key people? three to five key points that they feel the new system must provide to meet their and the company's objectives. How to use this information? Prioritize requirements. Identify new requirements. Eliminate low priority/low value items. With this work completed, the project team will have a good idea of the key objectives of the new system and a list of requirements that require further analysis. RE-ENGINEERING: In most organizations these days some degree of Business Process Engineering (BPE) or Business Process Re- engineering (BPR) is taking place. If this is the case then some documentation may already have been completed that will guide the project team in defining the requirements of a new system. When BPE projects are completed properly, the end products include recommendations on what information needs to be collected and used, and, who will collect it, at what point in the business cycle. NEEDS ANALYSIS: Now that the preliminary work has been done, it is time to document each and every item that the new system will be expected to provide to your company. The CSFs will have provided a high level list of requirements but each of these may require further analysis. Let's take a typical major CSF, "Pay employees accurately and on time". On the surface this may sound quite clear, but without looking into it further, you will not have the detail required to define a requirement. This is where individual and group interviews will be necessary to define each component of the pay process. The payroll process is a long and complicated one and a great deal of time and attention must be paid to documenting the processes. Interviews of the payroll manager, staff, associated HR staff, and clients will help flesh out the detail necessary to define what your company needs in payroll processing in order to "pay employees accurately and on time". This could include defining all the key data elements; ability of the vendor to provide remote data entry of time; interfaces with key HR actions such as new hire, terminations, etc. As each requirement is identified, have your contacts prioritize each specific item into at least three categories: essential (must be provided to meet corporate requirements) highly desired/beneficial (beneficial to the organization) nice to have (not immediately essential but will make certain business processes more efficient if available). As each of these requirements is identified, develop a spread sheet or simple word processing grid that identifies the requirement and its priority. Supplemental information collected during the analysis should be retained for use later when memories may not recall the reasons for some of the requirements or to assist in the evaluation of a vendor response to a particular stated need. SIGN OFFs Some organizations insist on a formal sign-off of the requirements by the responsible officers who helped provide the information. While this is not necessary in all cases, a review of the finished product, one on one with the key person will catch errors and omissions and it will also generate some buy-on to the fact that these are their needs. FINAL DOCUMENTATION: Once all of the documentation has been completed and "signed off" by the key role players, there should be a clear set of requirements, stated in point form, and each need prioritized. This document should be reviewed by the project team and changes made if necessary and ultimately the document should be presented to and signed off by the HRMS Steering Committee. Once the final documentation has been assembled, it can be included in the RFP that goes to each vendor selected to bid on the project. It is recommended that each vendor also receive a disk copy of the requirements and be informed if am electronic response is required. In most cases, the vendor will prefer to reply to the needs in the RFP by completing the disk and returning it to you. This makes life easier for the project team once all the replies have been received. Your complete Needs Analysis will enable you to make an intelligent decision on which of the vendors who reply to your RFP best meet your requirements. HRMS VENDORS There are LOTS of good HRMS vendors out there in a very competitive market today. In fact their products and tools are getting better by the day. -Al Doran, CHRP Copyright © 1998 Phenix Management Int'l Phenix Management Int'l, Inc. 58 Penwick Cr., Richmond Hill, ON L4C 5B4 phone: 416/ fax: 905/ 11

The HRIS in the Context of Enterprise-wide IS
ERP Packages can integrate human resource data with other systems in the firm Management Information System Performance Management Human Resources Information System Product IS Knowledge Training Management Operation IS Organization Management Inter organization IS Personnel Administration (Benefits, Payroll International IS Business Information System: Recruiting Promoting Out placing Finance Accounting Marketing Logistics Legal

Step 9 - Research How do you locate information on vendors and products? The obvious starting point is to talk to your colleagues in other companies for recommendations on products they have used that fit your general needs. Another source is the Internet.

Step 10 - Literature Get product literature. Ask for literature containing the level of detail you need. This is a key step in the process and should not be skipped because it should reduce your potential vendor list to a manageable number. One note of caution: many vendors will want to schedule meetings when you contact them for literature. Don't meet with vendors yet, you're not ready. Limit them to sending you as much information as they can, and let them know that you'll contact them if you have further interest.

What is an RFP? RFP is an acronym for Request for Proposal. RFPs describe a task or project that must be completed, establish competition and evaluation guidelines, and ask all qualified vendors to submit a proposal (a bid) to complete the work. RFPs are legally binding documents. While they are not contracts, they are normally considered (under the law) to be the foundation of a contract between two parties. Any information contained in an RFP should be reviewed for factual and technical accuracy before it is released to the vendors. RFPs are often used to encourage open bidding for goods and services. In this case, RFP creation, publication and distribution is part of a legal bidding process that must be seen as fair and impartial. Similarly, the contract evaluation and award process must be fair and free from bias, misrepresentation or corruption HR TECHNOLOGY Writing an effective RFP for a new HRMS What is an RFP? RFP is an acronym for Request for Proposal. RFPs describe a task or project that must be completed, establish competition and evaluation guidelines, and ask all qualified vendors to submit a proposal (a bid) to complete the work. RFPs are legally binding documents. While they are not contracts, they are normally considered (under the law) to be the foundation of a contract between two parties. Any information contained in an RFP should be reviewed for factual and technical accuracy before it is released to the vendors. RFPs are often used to encourage open bidding for goods and services. In this case, RFP creation, publication and distribution is par t of a legal bidding process that must be seen as fair and impartial. Similarly, the contract evaluation and award process must be fair and free from bias, misrepresentation or corruption. When do you need an RFP? An RFP should be used in any situation where you have a complex set of requirements and you want to know how well one or more vendors can meet your specific requirements. All too often an organization will start off its search for its first or replacement Human Resource Management System (HRMS) by inviting in a vendor or two to demonstrate their systems. Then the vendor starts asking questions that the organization cannot answer yet as it has not put any real thought into the process. Buying HRMS software is not like buying a new word processing package and loading it onto your network. Some of the obvious questions a vendor should be asking at this point, and you should be able to answer, include: a) What is your budget? b) What are your key business drivers (why are you looking for a new HRMS right now)? c) Will your new HRMS include payroll? d) What technical platform do you plan to have the new HRMS on? e) What is your implementation plan and when do you want to “go live?” f) Do you have the resources to dedicate to the implementation project? If you cannot answer these questions yet, you are not ready to look at vendors. What work has to be done first? Complete a detailed needs analysis. This will give you the basic ingredients for the RFP. It will also force you to go over the things you want to include within the scope of your project. This is your shopping list and it’s fundamental to the process. You cannot proceed without it. Normally, this work will be done with a consultant who specializes in this kind of work. This specialist will help identify your requirements, prioritize them, and document them in a format that will enable you to use them in your RFP. You will want information that HRMS vendors will recognize and be able to respond to in a way that can be measured by your project team after all the proposals to the RFP have been received. How to write an RFP RFPs come in different styles, formats, depth and length. If your RFP is structured to the type of service you are looking for, you will receive more appropriate and descriptive responses. Keep the length and depth of your RFP in proportion to the job. If you are looking for a strategic provider to meet all your HR information technology needs (full outsourcing) for the next five years, you might need a 50-page RFP. However, if you are looking for a vendor to provide basic HR record-keeping for 50 people, without payroll, you might only need a 10-page RFP. Unfortunately, I have seen RFPs lately that I would not recommend ever be given to an HRMS vendor. Two recent RFPs that came across my desk appeared to have been strongly influenced by purchasing departments who are used to boilerplate RFPs for the construction of buildings and bridges and were so technical that the average vendor would ignore them in favour of more streamlined documents. Try to avoid this if at all possible, even though it is advisable to use your corporate legal and purchasing departments to check your RFP for language that could potentially harm the company. Describe what you need in an HRMS: Much like the old computer phrase “garbage in = garbage out,” general specifications will give you weak responses, while detailed specifications will give you thorough responses. Describe your specifications with as much detail as possible. Topics to cover should include: how to install and set up the system, what training is included, managing online help files, access/security controls, and how reports are generated. And tell vendors your “must have” criteria rather than “nice to have” criteria. Format: I prefer the three-column approach to every question, especially the detailed questions related to what you identified in your needs analysis. Column one is where you describe what you are looking for. Column two at a minimum should be a Yes or No response. But even better if you can use a simple 1- 5 scale with 1 being “No” and 5 being “Yes, can meet all of this requirement.” Then 2,3 and 4 would represent various levels in between. Column three is where the vendor may want to expand upon its own rating with comments such as “we will have this feature in our next release during the 4th Quarter of 2002.” Using this format enables you to quickly compare all of the proposals you receive back from the vendors. Response date: The organization issuing the RFP needs to communicate a deadline for vendor response. As a general rule of thumb, I recommend at least three weeks response time for an RFP. Remember, you may not be the only potential client sending a vendor an RFP this week. If the vendor is busy, it cannot respond to all requests – and you do not want to miss out on a good solution to your requirements so provide enough time for vendors to complete their responses. Inform the vendors of your timetable to review the responses, make a decision, and your expected purchase and implementation dates. Beware the vendor who calls you the first or last week and asks for an extension to the date. At least if they call in the middle week, they give the impression that they at least looked at the RFP! Remember, if you change the date, you then have to let all the other vendors know. Number of copies: Since an organization typically has a team of people working on the project for which the RFP is required, specify how many copies of the vendor’s response are needed. Multiple copies will simply make the review process easier for the organization. I highly recommend that the vendors also be required to submit a soft copy of their response, especially if you are using a consultant to review the responses for you. Typically the hard copies submitted by the vendors include a lot of “glossy” materials in addition to the required RFP response. Organization contacts: During the proposal development period, several questions or issues may arise that need clarification prior to proposal submission. The vendor should be given a contact name. This is often your HRMS consultant, who will be expected to expedite all questions to the proper contact. This will allow the bidding process to move more smoothly. The contact should be the same on all RFPs that go out on a particular project, and this individual will ensure that vendors receive consistent answers. Offering an initial line of communication also acknowledges the organization’s willingness to act as a partner throughout the project. I also recommend sharing all new information with all the vendors if one asks a good question that turns up new information. Beware the vendor who tries to go around this process by calling personal contacts in the company to try and get “inside” information or to ingratiate themselves. I have had clients remove vendors for committing this act. Formal vendor presentations: The RFP should include a section informing the vendor that the organization may require a formal presentation or demonstration of the vendor’s product(s). This section may be worded in such a way that allows the organization to receive presentations prior to any internal evaluation process or only after the list of potential vendors has been narrowed. The presentation or demonstration section should state exactly what the organization expects to view or hear. A statement notifying the vendors of their responsibilities for any expenses associated with the presentation or demonstration should also be included. Cover letter: This letter should include – at a minimum – a statement that the organization is intending to purchase a system. (Note that since the RFP is a tool ultimately used to choose a vendor’s product, the statement should not say that the organization is intending to purchase any particular vendor’s product.) The letter may also contain organizational information, such as type of facility, size, annual revenues, growth pattern, expected future growth, mission, purpose, etc. In addition, special instructions to the vendor may also be included in the letter such as where to refer questions, when the responses are due, etc. Distributing your RFP to vendors Once your RFP is complete, you must distribute it to the appropriate HRMS vendors. But where do you find the right vendors? You can send your RFP to vendors that you or your colleagues know, seek guidance from an HRMS consultant, research new online indexes such as the International Association for Human Resource Information Management (IHRIM) Buyers Guide or attend a trade show where most of the vendors will be. One such event is the annual Fall IHRIM conference in Toronto, Nov. 20, Details can be found at There are benefits in using the services of an HRMS consultant to distribute your RFP. The consultant will ensure that the RFP is distributed to the proper vendors, control the responses and field all questions related to the process. As well, they will provide assistance in comparison and evaluation of the responses. While compiling this information to create an effective RFP is a lot of work, the quality of responses you receive will save you time in the long term. And, after you’ve written a few RFPs, it does get easier. Remember, the first step to finding the best HRMS for your organization is creating a quality RFP! 15

Step 11 – Request For Proposal (RFP) Develop and send a request for proposal (RFP) to your smaller list of target vendors. RFP's can be one page in length or ten or more. Smaller companies may want to use a simplified 1 or 2 page request for information (RFI) that requests less information and has more flexible response guidelines in order to expedite this stage. The most common elements in an HRIS RFP include: An overview that describes your company, A description of your software need and the employee population it will support, Desired system functionality, Required technical environment/specifications, A request for pricing (licensing fees, maintenance charges, training and implementation support, annual maintenance fees and telephone hotline support), 16

Cont. Step 11 - RFP 6. A request for customer references, 7. Details on customer service/support available from the vendor, 8. A request for sample contract terms. The RFP needs to contain guidelines for the vendor response such as: Are each of the required features currently in their system? Are certain features proposed in a future version of the system? Will your required features require system customizations and if so what are the costs and problems associated with the customizations? Always be aware of your "special needs" and the extra money and effort it will cost for implementation and future support. Work hard to modify your internal processes to match the software before embarking on customization. 17

Step 12 - Evaluate A typical approach is to create a spreadsheet with all of the items in the RFP as your column headings and the vendors listed on the rows. Then you would assign a value to each RFP item (yes/no, a Rupee value, or a numerical ranking of some type) for each vendor. Once you have received all of the proposals and entered the data on your spreadsheet, then the team can meet, review the evaluations and select the vendors they want to schedule for product demonstrations. 18

Step 13 - Demos You should control product demonstrations to try and get as accurate and unbiased information How do you control the product demonstration? You control the demonstration by modifying the vendor's agenda. All software vendors have standard product demonstrations -- don't accept the standard demonstration. Create a list of specific questions for the demonstration that focus on your issues and concerns and provide it to the vendor in advance of the meeting. In this way the vendor can include your issues as part of their overall demonstration and you should get a more unbiased look at the product. All of your team members should be involved in the demonstration and the team should agree in advance on specific issues that each member will ensure are addressed during the demonstration. 19

Step 14 - Evaluate Again After you have completed your initial product demonstrations, it's time for the team to meet and evaluate the products based on all of the information you have at that point. Have each team member list the likes, dislikes, concerns, and unresolved questions that they have concerning each product. You may need to have one or more vendors provide some additional information before you move forward. You also need to be concerned about pricing differences at this point in the process. However, do not assume that you have the "final" price from each vendor. As the vendors learn more about your specific needs, they may be in a position to refine the pricing submitted with their RFP. Finally, narrow your vendor list to 2 or no more than 3 vendors. Invite those remaining vendors back for a second product demonstration. 20

Step 15 - Decision Points Discus the items that will drive your final decision. In most software selections price is one of, but not the only, selection criteria. Other obvious decision points may include differences in functionality and compatibility with existing systems. For many companies, implementation costs and timeframes are critical decision points. One word of caution, be certain that your management team representative is heavily involved during this discussion as the team needs to be very sensitive to the items that will influence the eventual approval or disapproval of their recommendation. 21

Step 16 - Check References Now it's time to start checking references on your finalists. Your team should develop a list of questions that they would like answered by each reference. Questions should cover any areas of concern that you have with the product, product functionality, implementation, problems the reference has encountered and ongoing support. Make sure that you understand the technical environment of each reference, i.e. Windows NT, Unix, AS/400, etc so that you can identify issues that may or may not apply to your situation. If you can get references in the same geographic area in which you work, try and visit the reference's business to see the product in action and talk to the actual users. It is best to check all of the references before the second demonstration so that issues that come up during this process can be addressed at the time of the next demonstration. 22

Step 17 - Demo Again Have specific items that you want to see again or need to clarify. These items should form the basis of your second demonstration. Make sure that your management team representative is present at this demo. Your IT representative should ensure that all technical issues are resolved at this time. Review core functionality, reporting, processing time, implementation schedule and costs, customer support, issues raised in the reference checking process and any specific concerns of the team. If you have any concerns about the pricing portion of vendor's proposal, now is the time to express them so that the vendor has a chance to clarify If you do not get everything resolved to your satisfaction during the second round of demonstrations, do not be afraid to bring one or more of the vendors back for a third demonstration. 23

Step 18 - Evaluate Again & Select Evaluate the information you learned in the second round of product demonstrations. Compare what you've learned to your initial goals and product specifications. Create a matrix of how each product evaluates against your decision points. If you've done a thorough job of learning the strengths and weaknesses of each product, established clear goals and product specifications and you've been aligned as team from goal setting through final demonstrations, then you should have an easy time reaching consensus on a product recommendation. Remember that making the right selection is only phase one of your project. A successful implementation that achieves your goals is the real challenge. 24

Best HR Software Now HRIS vendors are broadening their offerings on strategic HR functionality, such as competency management, workforce planning and budgeting. They are also adding new abilities such as tracking headcounts, demographics, compensation trends, and turnover.

Best HR Software Now Vendors are providing extended Web access to support comprehensive manager and employee self-service applications, reporting and decision support features such as performance indicators and role-based Web portals focused on managing employee relationship Vendors are moving away from client/ server architectures and toward component-based, “n-tire,” and Internet architectures HRIS vendors are enhancing their ability to integrate with other business applications and third parties, such as expending integration capabilities within ERP suits.

Lawson Insight II Rating and Analysis of Leading HR Software Packages
Evaluation summary: The Lawson Insight II HR Suite offers strong payroll and benefits administration and rich HR functionality overall. The system provides a complete point-in- time view of a company’s work force including current employees, open positions and contract labor. Limitations: Compared to the best-in-class HRMS, the product could be expanded in its workforce planning and forecasting features. It made recent enhancements, however in the position management area (including headcount and FTE budgeting). Lawson insight also has limitations in time and attendance management (for example, the system provides no work schedule features), but makes a standard interface with Kronos available for sophisticated time management requirements.

Oracle HRMS Rating and Analysis of Leading HR Software Packages
Evaluation summary: Oracle HRMS is still a challenger of choice for PeopleSoft and SAP in the top–tier ERP market. From a functional standpoint, the product has potential to become a dominant player in the global, high end HR space, as the company continues to address the few functional limitations that exists within the package. Limitations: The drawbacks of Oracle applications lie mainly in the complexity of their implementation. Users should be prepared to face costly implementation process (though some progress has been made to accelerate the products configuration) with issues such as the need for expensive consultants and difficulties acquiring in house resources and in developing internal expertise ( training)

PeopleSoft HR Management
Rating and Analysis of Leading HR Software Packages PeopleSoft HR Management Evaluation summary: Highly flexible PeopleSoft HRMS offers the broadest HR functionality on the market and is limited in its international payroll capabilities. Limitations: Although it supports multiple currencies, the payroll functionality is not offered as a global solution. The European payroll project (developing in collaboration with ADP using PeopleTools) was revealed to be more complicated and resource- intensive than anticipated. Like Oracle and SAP PeopleSoft belongs to the family of highly configurable ERP packages, involving relatively high implementation costs.

Rating and Analysis of Leading HR Software Packages
Ultipro HRMS/Payroll Evaluation summary: Focused on the North American market, Ultipro is a highly functional, best-of- breed HRMS solution for companies with 500 to 1500 employees( the vendor also targets companies with less than 500 employees). A successful player in this market, the vendor combines a solid, Microsoft- based technology strategy, a particular emphasis on customer support( experienced support representatives and so on. Limitations: Ultipro is available only in English and has limited international features. The system handles some international addresses and includes some features for expatriates. The compensation function dose not support scale points (the public sector and higher education are not targeted markets for the vendor at this time).

Thank You

Steps to Selecting a HRIS

Similar presentations

Presentation on theme: "Steps to Selecting a HRIS"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Steps to Selecting a HRIS

Similar presentations

Presentation on theme: "Steps to Selecting a HRIS"— Presentation transcript:

Similar presentations

About project

Feedback