It’s a rare occurrence when an organisation is happy with out of the box HRIS functionality.

During implementation, it may be that HR/Payroll changed their practices to fit the features of the HRIS. But over the life of a system new information is required to be stored and processes change. The HRIS will need to be customised to meet these requests.

Knowing the right way to approach customising and extending the functionality of your HRIS is critical as the downstream impacts can be expensive and time consuming.

Most organisations have learnt the perils of customising a core vendor product: expensive modifications that can only be performed by the vendor, re-doing the custom work to roll into the next release, or even worse, stuck on a version of the software unable to upgrade.

Only when there is no other alternative should you consider customising your core HRIS.

Another way of adding site specific features to your HRIS is to leverage off existing structures and create new functionality (screens, reports, transactions) that act as extensions not customisations. Extensions, when done correctly, leave a lighter change footprint on your HRIS reducing the ongoing cost and effort required to look after more traditional customisations.

Here’s a couple of points to look out for when planning your next HRIS extension:

Look for current HRIS functionality

Are you sure the new feature the HR Director says she needs is not available in the system? Make sure you read all the documentation you can lay hands on including user guides, release notes, whitepapers.

Talk to people in your user group, and check out any vendor forums. Talk to other organisations in similar industries – chances are they have come across the same issue and already have developed a solution that you can use.

Leverage off current interfaces and data structures

The complexity of a customisation is impacted by the number of screens, business logic and storage objects required to enter, transact and store for the new piece of functionality. To reduce complexity, look at existing tables and functionality to find ways to hook off core functionality.

Examples:

• storing affiliates or contractor information in the employee and job tables creating new codes to distinguish them from salaried employees
• using the survey functionality in Employee Self Service to accommodate performance reviews of employees
• using flex/custom fields to store additional information rather then creating a new table – most HRIS have this functionality
• Be sure to consider data volumes and the impact of storing your data in these existing structures as the system grows.

Planning HRIS customisations

Avoid hardcoding – Use codes and config data to keep the HRIS flexible

There seems to be a school of thought that because you’re developing a customisation it’s OK to hardcode that department or employee status code into your program. Not only is this lazy design, but it prevents business users from having any configuration or control over the customisation.

Keep your customisation flexible and future proof by driving key features – employee applicability, department scope, trigger conditions etc – by leveraging off system codes and setup configuration (example/ codes, CON_DEF’s and code rules in the Alesco HRIS).

Create a framework for building and managing HRIS extensions

Consistent packaging and managing of customisations prevent common issues like moving between non-production and production, identifying customisations and re-applying patches for new releases of the software.

Use consistent naming scheme for your tables, views, screens and reports. Consider using a prefix like your company name on your new objects. Has the HRIS vendor provided a developer pack or customisation guidelines? Make sure you follow them.

Maintain a register of customisations and extensions listing the modules/programs affected and why it was developed. The register comes in handy during upgrades to determine what impact your customisations have against the latest release and whether you still need it.

Vendors building better platforms

As organisations recognise the benefits in having the HRIS as the single source of record for employee data using Self Service as the delivery platform, it makes sense organisations will want to extend the capabilities of the HRIS.

Vendors are recognising the need for customers to extend the system and I think we will soon see an explosion of more frameworks, API’s, web services, business rule frameworks that allow more extensibility in HRIS – without the headaches and disadvantages of traditional customisations.