Complexity isn't related to numbers of employees being processed.
Even though bureaux and similar providers sometimes charge per payslip,
the costs and complexity of processing are related to issue like the
numbers and complexity of payments and deductions, the reporting and
interface requirements, employee turnover and accuracy and timeliness of
data recording in the organisation. This is why reports and interfaces
are usually additional to the costs of bureau processing.
A software solution cannot, of itself, correct poor business processes.
If, for example, parts of the organisation are accustomed to not
reporting the fact that some one has left or joined the organisation
until weeks or months after the event, this will result in extra work
for payroll, regardless of any computer system that's in place. Any
system that attempts to provide an automated solution to issues of poor
process is likely to be expensive, complex and disappointing.
End user training.
* Make sure end users have received enough training to be
confident in the operation of the system
* Make sure the training covers details of procedures required in
order to achieve various results in payroll (e.g. how to process
backdated/retro changes, how to make corrections, etc)
Experience of projects where this isn't done shows end users (quite
reasonably) try to perform actions in the same way they have done on
previous systems; then blame the system when the results are not what
they expected.
Don't assume you know and understand the scope and functionality of the
new system until you do!
Don't assume a particular function either exists or operates in a given
way until you've checked.
Don't assume that because a piece of configuration is delivered it will
meet all your needs until you've checked.
Don't assume that functionality in the new system will be the same as
the old.
It definitely won't. Even if they have identical capabilities, results
will be achieved in different ways - at the very least input screens or
pages will look different.
Don't assume the legacy system is always correct.
We have seen examples of legacy systems that have been calculating
payments or deductions wrongly for years.
Don't assume current practises are correct/legal
We were recently asked how to set up the system to process mid-period
changes to NI category codes and calculate each part period using the
appropriate code. The system doesn't support this process because the
NI rules don't require it - in fact they make it clear it shouldn't be
done.
Don't assume "that's how everyone does it"
If consultants had a pound for every time they'd been told "our payroll
is just like everyone else's", they'd have a lot of pounds. Whilst
there shouldn't be too much doubt about the major statutory issues,
there are many variations on pension scheme rules, and calculation of
hourly rates (just two examples).
In addition there are two different (and acceptable) ways of calculating
NI on advance payments and many variations of how NI can be levied on
gifts.
Do plan carefully
If you are implementing retrospective processing, for example, take time
to plan and test so that you have devised procedures for all the
instances where you do/don't want retro to apply. This is particularly
important where, for example, you are implementing retro for the first
time.
Make sure you identify what processes are important - if you have a high
staff turnover, automated P45 production in accordance with your
business processes may be a high priority.
Do allow for the unexpected (and the expected) exception
When designing configuration, if you are trying to automate and
streamline a process (perhaps have the system calculate a rate of pay
based on a number of factors) try to think about circumstances where
there might be an exception. Who is allowed to override the calculation
and under what circumstances? We learned that building rules exactly as
described by users almost always results in a later request for a change
to allow for "special cases".
Migration - Get the data from the system of record.
Example - If you are running a bureau system with a monthly feed of data
down to local enquiry systems, get the data from the provider's records,
not the local enquiry databases. Experience in this example proved that
the local enquiry databases hadn't been kept fully up to date and NI
data was missing.
Even though bureaux and similar providers sometimes charge per payslip,
the costs and complexity of processing are related to issue like the
numbers and complexity of payments and deductions, the reporting and
interface requirements, employee turnover and accuracy and timeliness of
data recording in the organisation. This is why reports and interfaces
are usually additional to the costs of bureau processing.
A software solution cannot, of itself, correct poor business processes.
If, for example, parts of the organisation are accustomed to not
reporting the fact that some one has left or joined the organisation
until weeks or months after the event, this will result in extra work
for payroll, regardless of any computer system that's in place. Any
system that attempts to provide an automated solution to issues of poor
process is likely to be expensive, complex and disappointing.
End user training.
* Make sure end users have received enough training to be
confident in the operation of the system
* Make sure the training covers details of procedures required in
order to achieve various results in payroll (e.g. how to process
backdated/retro changes, how to make corrections, etc)
Experience of projects where this isn't done shows end users (quite
reasonably) try to perform actions in the same way they have done on
previous systems; then blame the system when the results are not what
they expected.
Don't assume you know and understand the scope and functionality of the
new system until you do!
Don't assume a particular function either exists or operates in a given
way until you've checked.
Don't assume that because a piece of configuration is delivered it will
meet all your needs until you've checked.
Don't assume that functionality in the new system will be the same as
the old.
It definitely won't. Even if they have identical capabilities, results
will be achieved in different ways - at the very least input screens or
pages will look different.
Don't assume the legacy system is always correct.
We have seen examples of legacy systems that have been calculating
payments or deductions wrongly for years.
Don't assume current practises are correct/legal
We were recently asked how to set up the system to process mid-period
changes to NI category codes and calculate each part period using the
appropriate code. The system doesn't support this process because the
NI rules don't require it - in fact they make it clear it shouldn't be
done.
Don't assume "that's how everyone does it"
If consultants had a pound for every time they'd been told "our payroll
is just like everyone else's", they'd have a lot of pounds. Whilst
there shouldn't be too much doubt about the major statutory issues,
there are many variations on pension scheme rules, and calculation of
hourly rates (just two examples).
In addition there are two different (and acceptable) ways of calculating
NI on advance payments and many variations of how NI can be levied on
gifts.
Do plan carefully
If you are implementing retrospective processing, for example, take time
to plan and test so that you have devised procedures for all the
instances where you do/don't want retro to apply. This is particularly
important where, for example, you are implementing retro for the first
time.
Make sure you identify what processes are important - if you have a high
staff turnover, automated P45 production in accordance with your
business processes may be a high priority.
Do allow for the unexpected (and the expected) exception
When designing configuration, if you are trying to automate and
streamline a process (perhaps have the system calculate a rate of pay
based on a number of factors) try to think about circumstances where
there might be an exception. Who is allowed to override the calculation
and under what circumstances? We learned that building rules exactly as
described by users almost always results in a later request for a change
to allow for "special cases".
Migration - Get the data from the system of record.
Example - If you are running a bureau system with a monthly feed of data
down to local enquiry systems, get the data from the provider's records,
not the local enquiry databases. Experience in this example proved that
the local enquiry databases hadn't been kept fully up to date and NI
data was missing.
