Like many other things, finding a new HRIS or payroll system should be a carefully managed process. This process, however, doesn’t start with preparing and issuing an RFP. Rather, the place to start, well before opening discussions with potential vendors, is to properly define your needs.
The first step is a 1 or 2 page statement that, in the simplest language possible, clearly states:
• The primary reasons for the project;
• The main objectives sought; and
• How these objectives will be measured.
Senior management will probably require such a document before authorization or budget approval can be secured. This document can also be vital in preventing ‘scope creep’. In other words, the test for deciding if particular functionality should be added as a systems requirement is the extent to which this functionality would contribute to meeting project goals.
The next step is to thoroughly document your existing environment, including:
• A simple diagram of related systems, including all interfaces to any internal or external applications that are either a source or recipient of employee-related data.
• A separate document for each of these interfaces, defining at a minimum the frequency, direction, data fields, validation logic and synchronization strategy required. There should be sufficient detail to allow an IT resource to replicate these interfaces.
• A process flowchart for each major employee event, such as new hire, termination, etc.
The goal is to correctly describe how each job or position is currently involved in HR/payroll administrative processing.
• A demographic description of the employee population. This should detail all relevant HR or payroll attributes such as BN, pay period type, pay in arrears or current, pay by exception or positive pay, source deduction remittance frequency, how employees are grouped for benefit or cost accounting purposes, etc.
• If the project involves payroll, a description of each earning, benefit, employer contribution and employee deduction. There should be sufficient detail to understand how each transition value must be calculated.
• A discussion of any organizational strategies or commitments that might affect the project. Similarly, there may be something in the systems technical environment that limits the vendors or applications that could be considered. For example, there may be a strategic IT commitment to Microsoft’s .NET software development or the Oracle database environments, that may impact which vendors or new systems could be considered.
The above might look like a lot of work, but you will find that these documents will be required anyway either for an RFP or during any subsequent implementation process. The better the existing environment is documented the more likely you will be able to avoid implementation ‘surprises’ that will escalate project costs and delay full implementation.
Having done all this preparatory work, the final step is a first draft at designing ‘future state’ processes. Until an actual system has been selected, and contracts signed, you can’t define employee administrative processes in the same detail as is required above for the current state. This means that ultimately, detailed work on designing improved or better processes has to wait until a system decision has been made.
However, what you can and should do at this point is to document the general principles that you want to see in any system. For example, it would be common to specify that:
• No single piece of data should be entered more than once. In other words, if there are 5 separate applications or modules that use employee names and addresses, either these have to work off a single, shared database or they have to be interfaced.
• Data entry should be pushed out as far as possible onto line or business units. The ideal, for example, is that new hire demographic data be entered, as much as possible, by applicants themselves.
• Data entry shouldn’t be split across more than one person, for any given employee administrative event. For example, more than one person might need to approve a new hire, but the basic new hire data entry (other than that done by applicants themselves) should be concentrated in the hands of a single person.
The above are general best practices related to HR/payroll data entry. A best effort should be made to apply these when you draw out future state process flows for the same events you documented in the current state. The goal is to describe in as much detail as possible how HR/payroll administrative events must be handled in any new system.
This serves several purposes. First, you can use differences between current and suggested future state processes to verify that the future state will accomplish your project objectives. If they don’t, you may need several rounds of work on future state processes, until you are satisfied that these objectives can be met. Second, the point of applying best practices is to reduce the complexity of existing processes. Reducing this complexity may enable you to consider applications that might not otherwise be suitable. Third, future state processes can be used to rank vendor RFP responses on a scale that measures compliance with future state requirements against cost. This ranking can either help in vendor negotiations or result in greater efforts to reduce the complexity of future state processes.
Alan McEwen is a Vancouver Island-based HRIS/Payroll consultant and freelance writer with over 20 years’ experience in all aspects of the industry. He can be reached at firstname.lastname@example.org, (250) 228-5280(250) 228-5280 or visit http://www.alanrmcewen.com for more information.