rganisations often agonise over the best approach to
running their HR and Payroll systems, with a common question being whether
to have a fully integrated HR and Payroll system or to
operate entirely separate systems. The arguments for and against each
option are set out below:
1.
Arguments for Integration
In an integrated system, the core HR Management System and payroll
modules sit on top of a common database, so all data about an employee
such as their pay, conditions, cost centre, organisation, position and
personal information are simultaneously available in every module. This has
several advantages in terms of processes and workflow. For example, a newly
hired employee can be set up in the system by an HR administrator, the employee
can add personal data through self-service and pay details can be added by a
payroll administrator using the same core data. There is no need for
cross-referencing or waiting for data to flow through the system.
The biggest risk with separate (non-integrated) HR and Payroll systems is
that the same core data is frequently needed by both, relying on either an
electronic interface or even manual re-keying, requiring additional work to
manage and validate the transfer. Both these methods almost always cause delays
and potentially problems in reconciliation. From a business process
perspective, it’s usually much easier to design a process based on a smooth
flow of data between HR and payroll within the same system. Retaining all data
within the same system also reinforces the idea that the HR module is
the master source of data about people. If the two systems are not
synchronised, it could lead to problems in performing certain
calculations, for example, where pay calculations are based
on position-related data that needs to refer to Terms
& Conditions (held at the HR level) in order to work out overtime
pay or calculate a pay increase.
2.
Arguments for Separation
In some cases, separate HR and Payroll systems may make good sense
on cost grounds. For example, when implementing the payroll module of a
large ERP module, it may not be economically viable to implement the
payroll module to pay only a small part of the organisation, which may
have its own pay rules. Paying a relatively small number of people
(for example a country where only a few people are employed) involves
many of the same set-up costs as those for a large population and it’s
not uncommon for global implementations to feed separate, stand-alone
payrolls or to outsource to a local provider. The ‘tipping point’ for
these calculations will vary according to several factors such as payroll
complexity, the availability of local providers and scale. In some
organisations, the payroll system seems to be working well enough – people are
paid the right amount every week or month and the view is that there is no
point throwing something away that is fit for purpose - ‘If it’s not broken,
don’t fix it’. When the same payroll system has been running for some time, it
will probably have reached a point of maturity where the team responsible for
it feels comfortable, knows it thoroughly and is reluctant to change. Staying
with the same system means there is no need to set up new software and its
operation will not require staff to be retrained. The current license period
may not have expired, in which case the team may wish to let the contractual
period naturally expire, saving cost. However, it’s important to recognise that
introducing an HR system will inevitably have an impact on payroll process (as
outlined in the pro-integration argument) because of the fundamental need to
reconcile the systems. This may actually introduce more cost as the data will
need to be passed to payroll by some means, either through re-keying or via an
interface.
