The Hris Project
The Hris Project
The Hris Project
Resource Centre
GLOSSARY ARTICLES WHITE PAPERS RECORDED MATERIAL EVENTS & EXHIBITIONS
15) Migrate Test Data onto Live Evironment 16) Old Data 16) De-commissioning
THE PROJECT
Introduction
This is a rather more detailed look at the HRIS implementation than that shown in the Buyer's Guide. This has been done with the intention of giving a sense of scope and scale to the professional contemplating the acquisition and implementation of a new or replacement HRIS, and is not exhaustive, nor constitutes the ultimate Project Plan. Most of this article deals with HR and Payroll applications, but a lot of the actions are generic to Time & Attendance systems. We shall update and expand this article from time to time to build on our visitors' knowledge base. Your selected Vendor will have a wealth of experience in the management of Projects such as yours, but it is useful for you to have your own appreciation of what is involved. A lot of this material is based on real-life experience (or scar tissue!) acquired by our Team over the course of years, and we mean it to be presented in understandable language and easily-followed format. Denis W Barnard CEO - HRcomparison Ltd
A good number for the core team is 3. Beyond that, you have a committee, which will make consensus difficult and may slow matters when team members are unable to make the meetings. The more members, the more unlikely you can get everyone together on a regular basis.
1. Cleanse data
Either circulate a blank form and ask employees to complete it, or print out what you have on them and ask them to correct or add information. I actually favour the former course, as it starts the data up from a zero base and means the employees have to make the effort to get it right.
3. Employee Numbers
Ensure that the new application can carry the sequences that you use. If you have a historical set of employee numbers, it can be a good opportunity to start from scratch
And so on... Tip No 4.1 When setting up the structure, remember to have the organisation itself at the top of the "pyramid" otherwise you will not be able to transit people between departments.
Hours: If standard organisational hours are 40 per week, and the Post in question, e.g. Payroll Manager, is a 40 hpw job, then it will be considered to be 1 FTE (Full-Time Equivalent) If the Post was only 30 hours per week, then it would be expressed on a headcount report as 0.75 FTE.
Grade:
Most posts will be allocated within an agreed grade. Certain benefits or conditions may automatically accrue from grades, and will need to be added to the Post accordingly.
Reports to: This will be the immediate report in the organisational hierarchy. This has additional importance when Triggered Actions are set up, to ensure, for instance, that all employees reporting to a certain manager are advised of impending Appraisal meetings or Training Events. The issue is a little clouded when an employee in fact holds two Posts - both perhaps part-time - and reports to more than one Manager. Some software applications cannot handle this without having two different accounts set up for the person, which is highly unsatisfactory, especially when it then impacts on the Payroll. If you have what are known as Multi-Posts in your organisation, you will have to look very carefully at your vendor specification. As a rough guide, most vendors who sell into the Public Sector will have this feature, by necessity.
Benefits: Either dependent upon grade or perhaps as a standard feature of employment, benefits may be attached to Jobs. Theses can include Life Assurance, Permanent Health Insurance (Salary Continuation), Holidays and other Contractual provisions.
Property: Some positions automatically require corporate property, such as Mobile Telephones, Laptops and Company Cars.
You may wish to allow the Training department to see employee records relating to Job and Training History, without having access to personal and salary data or in-house Recruiters to see Job detail only. With Time & Attendance, the most common security set-up is to allow Shift Supervisors to edit their own shift workers' absence records. Non attendance is edited in arrears when the cause for absence is known, and can then be shown as Unpaid, Sickness, Compassionate or made up later on the shift, etc. Access issues will also arise in Time & Attendance, where the system is used for Access Control to a building or parts of a building as well as a Time Recording device. Self Service presents a much more complex task, as you will need to organise security levels for the majority of your workforce (those who have easy access to online access). This will involve setting parameters for the fields that can be changed by all employees (address, bank details, absence and holidays), their managers and supervisors (approvals and training recommendations) and senior management (e.g. headcount, budgets and corporate communications).
Trigger: New Employee Field: Probation Condition: Start Date + 12 weeks - 2 weeks (or +10 weeks) Action: Email Message: "Please note that (employee name) is due for Probation review on Date (derived from the Start Date + 12 weeks). Please ensure that this review is completed by the due date." This is simplistic, but gives an indication of how these Triggers are constructed.
How often do you actually refer to records more than a year old? Does anyone ever look back at career progression over the past 10 years? Just how accurate - and detailed - is the history? The more history you bring forward, the more costly it becomes. Every historical post going back in time must be created, populated, and then depopulated as the employee moves on, even though the jobs, and occasionally departments, may have passed out of living memory. You are in fact reconstructing the past, and, as previously mentioned, this history may be inaccurate enough as to be of dubious worth. An effective way of resolving this would be to agree a point in time, say 2/3 years previous to the current migration time, and import this into the new application. Earlier data can then be retained in a form of History file (see Old Data Item 15)
o o o
Maintaining an environment version of the previous application, where records can be accessed and read; Data converted into a contemporary format such as Excel where it can be used at will; The old-fashioned giant pile of printout. The first two have a cost attached; a) is usually an ongoing rental charge and b) is a one-time charge. Neither is particularly cheap. The last option is not as impractical as it might sound; people generally overestimate the amount of access they need to historical data. Providing the history reports are produced in a range of sorts (Surname, Employee Number, National Insurance Number, Operating Division) then look-ups are not time-consuming.
17. De-commissioning
Remember if you are phasing out a previous application then you will need to study the terms under which you give it up, with special regard to notice periods and financial considerations attached to them. Existing systems should be maintained until complete cut-over to the new application is complete, and then they can be cleared down and withdrawn from the operating platform. Ensure that all master disks are accounted for are returned to the original vendor, or disposed of in line with their wishes. All Articles >>
Copyright HRComparison.com Website design by Gecko Media TERMS & CONDITIONS | PRIVACY | ACCESSIBILITY | LEGAL | SITEMAP | CONTACT US