We often get asked about the how a roll out should take place so we have put together a high level guide. Whilst there are a few variables to consider there number of commonalities we can elaborate on.
One of the most crucial facets of a new system is the reaction and engagements of users. I am not going to lie to you - some people will embrace change, many just won't care and others (regardless of the energetic use of carrots and sticks) will reject any form of participation in the process.
A key element to reducing the negative effects of change management is the setting of expectations through communication and engagement. It isn't uncommon to find individuals who reject change have been overlooked in the consultation process and feel aggrieved that aspects of their job are no longer considered as part of the system. In other words, you have overlooked a task or process that needs to be part of the roll out and have left room for the user to point out the inadequacy of the new system upon deployment.
Project Step - Communication Plan
Advise existing users that there is going to be a review of the payroll system and give them the opportunity to suggest process efficiencies.
At least one key user from each department & function should chair their parts of the system. At a minimum the Accountant, Payroll Officer and Business Manager should involved in review meetings.
Where to start?
Document the scope of existing solution(s) and identify the needs case for each feature that is used in the business. For example the current system might sms pay details to employees each week, why is this done and is it a requirement?
|SMS pays to employees||Casual workers appreciate knowing their pay ASAP||Optional|
|Create ABA file||This is how data is sent to the bank||Required|
Once the scope of the business requirements have been ascertained the next step is to map existing processes to the comparable ROL/payROL feature.
|#Feature||#ROL / payROL Feature|
|Pay Scales||Charge Calculator & Pay Class Codes|
|Create ABA file||Download Bank Disk|
The mapping process should identify defects and alternatives:
- Identify solution defect
- Vendor to create resolution plan
- Identify solution alternatives
- Document a process transition and training materials
At some point you will need to catalogue the technology requirements such as hardware, software and network capability.
Don't worry about about using ROL / payROL - all you need is an up to date web browser and an internet connection.
You are going to want to discuss and get an idea of the schedules involved.
- Testing & Evaluation - This is the scoping and deep feature research that you will need to do.
- Commissioning & Acceptance Testing - This is where the solution gets built and tailored to your requirements, ideally using your data
- Training - Aligning the capabilities of the users with the functioning system
- Production - Running your first payroll
- Follow Up - Having a live system will mean a steep learning curve for users which in turn leads to changes to the requirements or the identification of systemic improvements
- Maintenance - The vendor maintains the system and extends it over time
Working with other systems / products
It is crucial to understand and clearly define the hand off point between the two systems and document the responsibilities of each one. This helps users and vendors alike.
Typically when rolling out a new payroll system and bolting it on to an existing employee database there are a number of ways to achieve efficiency and accuracy. In some environments it is possible to have an API that allows the two systems to "talk" to each other. This is the deepest level of integration and is tightly coupled to the specific software being user. One drawback is that if a vendor changes part of their system then potentially the API will need to be changed. In other words twice the cost
We are a fan of using CSV files for payroll importing and exporting whenever there is no API to leverage off. There are a few good reasons for this primarily 1) They are simple to use and read 2) they clearly define the requirements of two systems
The minimal structures we need for accurate payroll processing & invoicing are:
- Pay & Charge Information: ABC Company, Fitter, Normal Hours, 38, Pay: 37.50, Charge: 49.80
- Relevant Statutory Costs: WorkCover, Payroll Tax and Superannuation
The information listed above is fairly basic but it is not ideal. The reason is that it cannot accommodate much functionality such as salary sacrifice or conditional logic used in Award interpretation. With basic information we can get things running fairly quickly but we cannot use all of the features of our payROL toolkit.
USE CASE: - This sort of file would involve one large export each week which had many columns. - Existing data would be updated with the changes - Only one file is needed to be created for payroll - New customers need to be set up in payROL
Data Structure - Improved
By adopting a more granular approach to data files we can take advantage of more of the underlying features of payROL. This would mean we would require regular exports of new:
- Hours Worked
- Pay & Charge Rates (linked to states, WIC codes, and Payroll Tax rates)
Typically an export will have a unique row ID - eg: EmployeeID - we use this to search for the presence of the record and if there is not one we create it. If there is one then the changes are propagated to the payROL system.
USE CASE: - These sort of files require more development and testing - Both systems could share changes and be synchronised - Four files may needed to for payroll - New customers need to only to be set up in the source database
Getting The Hours
We can work in a number of manual, paperless and hybrid ways to capture data into payROL. We can provide online timesheets and award interpretation or import directly from clock card systems.
......and that's about it!