When HR Standardisation Becomes Process Compromise

That is where standardisation can become process compromise. 

A common approach makes it easier to manage a distributed workforce, establish consistent policies and improve reporting. It can also reduce unnecessary variation and make processes easier to govern.

The challenge comes when a process has requirements that go beyond the standard workflow.

For example, a talent review may need several stages of assessment and calibration, different approval levels and a defined way of recording decisions. A performance process may need to reflect particular review cycles, responsibilities, rating approaches and governance requirements. 

These aren’t necessarily exceptions that should be eliminated. They may be fundamental to how the organisation needs the process to operate.

The question is not whether standardisation is good or bad. It is where standardisation creates value, and where greater depth or flexibility is necessary.

Large, distributed organisations rarely operate in exactly the same way everywhere. Different business units may have different structures, policies and responsibilities.

Yet the underlying objective can still be consistency.

A large organisation, for example, may need the same overall performance or talent framework across multiple business units while retaining enough flexibility to reflect different governance and operating requirements.

Consistency does not necessarily mean identical processes.

It means the organisation has defined how a process should work, established appropriate controls and can apply those requirements reliably across the business.

Trying to achieve that through a workflow that is too rigid can have the opposite effect.

When a system cannot accommodate an important part of a process, or organisational requirements evolve beyond what it can support, the first workaround may seem insignificant.

A spreadsheet tracks something the system cannot report. An email captures an approval that cannot be built into the workflow. Managers receive separate instructions explaining how to complete a process.

Over time, these solutions can create a parallel process around the system.
Different teams may use different spreadsheets, HR may reconcile information from multiple sources and process changes may need to be communicated separately because the system no longer reflects the complete process.

The organisation still has an enterprise HR system, but the actual process depends on spreadsheets, email, local instructions and manual intervention.

Before changing an established process, HR should establish what is actually causing the problem.

Sometimes the process itself is unnecessarily complicated. Legacy requirements may have accumulated, or different variations may exist simply because teams have developed their own ways of working.

In other cases, the requirement is legitimate but the technology cannot support it without compromise.

A useful starting point is to ask:

• Is this requirement genuinely necessary? Is there a clear policy, governance or operational reason?

• What would be lost by standardising it? Would important controls, approvals or information disappear?

• How much manual activity does the current process require? Consider spreadsheets, email and duplicate data entry

• Is the limitation in the process or the technology? Would simplifying the process actually solve the problem?

• Can the requirement be configured within a governed platform? Configuration and bespoke development are not the same thing.

These questions can prevent organisations from redesigning a process simply because the existing technology cannot accommodate it.

Not every specialist requirement needs a separate system. Equally, not every process should be forced into the core HR platform simply because other HR activity sits there.

A more useful approach is to consider the process requirements and the technology separately.

Identify which activities are well suited to the standard capabilities of the enterprise HR system, then identify where performance or talent processes require specific stages, controls, workflows or greater flexibility.

Before redesigning an established process, HR should be clear about what the process is supposed to achieve, which elements genuinely need to be standardised and where greater flexibility is required. It should also consider the governance, approvals and responsibilities that need to be built in, where current workarounds are creating risk or administration, and whether the process can be configured without unnecessary bespoke technology.

The technology decision should follow the process definition, not the other way around.

The value of an enterprise HR system is not in making every process identical. It is in providing a reliable foundation for core HR activity.

Where a performance or talent process has more complex requirements, the goal should be to retain the consistency and governance the organisation needs without forcing the process into a workflow that no longer reflects how the business operates.

That may mean keeping standard activity within the core HCM while using a configurable platform alongside it for processes that require greater control and flexibility.

If HR is changing an important process because the business needs it to change, that is process improvement. If HR is changing it because the system cannot support it, that may be process compromise.

Recognising the difference is the first step towards building HR processes that remain consistent across a complex organisation without making them unnecessarily rigid.

Your core HR system can provide the foundation for standardised HR activity, while a configurable platform can support the performance and talent processes that require greater depth and flexibility.