Global HRIS Modernization Done Right

The request looks harmless. A country asks for one extra approval step before compensation letters are released. It is feasible, it is two days of build, and it is agreed in the meeting where it is raised. Nobody asks whether the country manager should hold that decision, because that was not the question on the agenda.

Do that across twenty countries and you have rebuilt the fragmented estate you were replacing, expressed this time as conditional logic inside one platform, where it is harder to see and much harder to remove.

What actually happened

From 2017 the Workday platform came under the remit of Polymath’s founder in a CPG business of roughly $2–3 billion in revenue that had gone public on the TSX. Payroll ran in approximately 21 countries and integrations reached more than 20 offices. He led implementation and redesign across Core HCM, Recruiting, Advanced Compensation, Benefits, payroll processes and integrations, Absence, Onboarding, Time Tracking and Adaptive Planning. A hire-to-retire redesign, not a module rollout.

His one advantage had nothing to do with the platform. For years he had owned the HR-related internal controls, designed the segregation-of-duties requirements, and maintained the General Authority Matrix that set who could initiate, review and approve a people or pay action, at what threshold, across HR and Finance. That instrument existed before the programme did, and it settled the argument the programme actually had.

Variation requests arrived constantly and sorted into two piles that looked identical on the way in. One was fixed by law: how gross pay is calculated, what must be filed and when, minimum statutory leave, what a works council has a right to agree. The other was habit with a local accent — an extra approver before merit letters, an eligibility rule no insurer had restricted, a country-specific title for a role that existed identically in four other markets.

They separate only when you stop asking what the platform can do and start asking what the request changes about a role. Read the role past job, family, level and skills: what it is responsible for, which enterprise process it sits in, whether it initiates, reviews or approves there, what decision right follows, which control depends on it, what access it needs. A statutory requirement survives that reading with a provision attached. A habit resolves into one sentence about who gets to decide.

Absence is the cleanest example. It was reconfigured once in Canada and rolled out globally, so countries entered against a design that already existed rather than commissioning their own. Where a statute genuinely bit, the variation went in and was recorded against the provision. Where it did not, the request went to whoever owned that process globally — and often the answer was still yes, decided by someone who would live with it everywhere else. Asking a country to produce the provision reads as distrust, so it works only if the same question is asked everywhere, head office included.

Every one of those requests asked whether the system could do it. Not one of them was a question about the system.

Polymath carries that reading into a client programme while the design is still open, because a variation granted on build effort cannot be taken back once twenty countries are live on it.

Why it happens

The request arrives in configuration language because configuration is the only channel open. No enterprise runs a forum called “who decides pay outcomes in Germany”. It runs a weekly design session with a backlog, an integrator and a date. So a question about authority is submitted as a ticket, and answered by whoever the ticket reaches.

Look at who that is. A platform lead, an integration consultant, a country HR representative and, if you are fortunate, someone from the process team. That group is well constituted to answer one question: can it be built, and at what cost in build days. It has no standing to answer the other, because nobody in it owns the global policy.

Feasibility then answers yes, almost every time. Configurability is what you bought. The platform will carry a different approval chain in every country, for years, without complaint. So a decision about who holds authority is resolved by a sentence containing no reference to authority: yes, two days.

Nobody applies a statutory test, and the reason is social rather than technical. Asking a country to evidence a legal requirement is an accusation unless it is standard practice everywhere, and mid-programme is the worst moment to introduce it. The schedule supplies the tiebreaker: approving a variation costs two days, contesting one costs an argument and a delay of unknown length. Each individual decision is small, locally sensible, and made by competent people. Multiply by twenty countries and a handful of requests each, and the arithmetic is unforgiving.

That is the part that compounds. Fragmentation across separate systems was visible on a diagram. Once it lives as conditional branches inside shared business processes it disappears into the design, and reappears as cost whenever you want to change anything. A release, an acquisition, a statutory update: each is now regression tested against every variant.

The two piles behave differently over time, which is why the test earns its discomfort. Statutory variation is small, finite, evidenced, and it changes at the speed legislatures move. Habitual variation is large, unwritten and defended, because it is not about process at all.

The strongest objection

The strongest case against this: local statutory requirements make standardization impossible, and central teams who have never run a payroll in that country consistently underestimate them.

Both halves are true. Statutory requirements are not negotiable, and getting them wrong is a filing failure with penalties attached. In several jurisdictions a works council holds a legal right to agree changes affecting employees, so the variation is mandated rather than preferred.

What the argument does not establish is scale. Statutory variation clusters in a few objects: pay calculation, mandated filings, minimum entitlements, data residency, collectively agreed steps. It is narrow and it can be evidenced. The requests that consume a programme cluster elsewhere — approval chains, benefit eligibility, job titles, field visibility — and almost none appear in a statute.

The second objection is better: apply that test and you will win the argument and lose the country. The risk is real. A country team that feels overruled runs the process outside the system, and you are left with a system of record that is not the record. Which is why we put the test before build starts, applied by a named process owner, and why the answer to “habitual” must sometimes be yes. The point is not to refuse variation. It is to stop the schedule granting it.

The method

We run six steps, in this order. We take one and two before configuration starts, which is what makes them hard.

1. We name a global owner for every process before we configure any of it. One person accountable for hire, pay change, leave, benefit enrolment and termination — globally, not per region. The trade-off we accept: it forces a political argument before anyone has seen a screen. Skip it and the platform team becomes your policy owner by default, the one job they were never hired to do.
2. We classify every variation request as statutory, collectively agreed, or habitual — by reading the role, not the screen. Three boxes, one form, and we apply it to every request from every country including head office. For the first two we require evidence: the provision, the agreement, the regulator’s requirement. What produces the answer is the role definition — what it is responsible for, whether it initiates, reviews or approves, what decision right and control follow, what access it needs. The trade-off we accept: it is slow, and it reads as distrust unless we apply it universally. Skip it and feasibility is the only test the request faces.
3. We route habitual requests out of the configuration meeting. Feasibility belongs in the design session; we settle authority with the process owner, and we put the country in the room. The trade-off we accept: decisions take longer and the cutover date absorbs the delay, which is the pressure this step exists to resist. Skip it and your operating model is set by whoever is free on Thursday.
4. We design once, then roll out. We do not design per country. We build the global design in one deliberately chosen country and require every other country to enter against it. The trade-off we accept: the first country carries disproportionate load, and we build its design to travel rather than to fit. Skip it and you own twenty designs and no baseline.
5. We keep a variation register, with an owner and a review date on every line. We record what varies, in which country, on what authority, approved by whom, reviewed when. The trade-off we accept: registers are maintenance, and an unmaintained one is worse than none. Skip it and nobody can tell three years later which variations were legally required, so all become untouchable.
6. We give countries an exception path that actually works. A named route, a stated decision period, and a real possibility of yes. Your authority framework already does this for expenditure; an HR General Authority Matrix is the same instrument pointed at people decisions, and that is the instrument we use. The trade-off we accept: you will grant exceptions you would rather have refused. Skip it and refused requests move offline into local trackers you cannot see.

None of this is about being strict. We have watched a programme that refuses every variation end where one that grants them all ends: the process runs somewhere you cannot see it. What separates the two piles, in our experience, is a role definition reaching further than job architecture normally does. Job, family, level and skills describe what a person is; they say nothing about what that person may decide. We extend the spine into responsibilities, enterprise processes, initiator, reviewer and approver, the decision rights and controls that follow, the handoffs and the access that enforces them — and a Hire-to-Retire variation request answers itself.

Evidence and measures

The same test, applied to the requests that arrive most:

Five measures worth tracking over ninety days. None needs a new system:

— Proportion of open variation requests classified statutory versus habitual — and how many statutory ones produced an actual provision when asked.

— Number of conditional branches inside your three highest-volume processes: hire, pay change, leave. Track direction, not level.

— Elapsed days between a variation being raised and decided by someone who owns the process rather than the platform. — Count of variation decisions taken in a meeting whose stated purpose was configuration. It should fall towards zero.

— Number of countries running a core people process outside the system. Ask the country team, not the platform team.

If those five move, decision rights moved with them. If the only gain is more modules in production, they did not.

How Polymath solves this

We do not settle this in the configuration backlog. Before design freeze we take your five highest-volume Hire-to-Retire processes — hire, pay change, leave, benefit enrolment, termination — role by role, and write every role that touches them past job, family, level and skills into initiator, reviewer, approver, decision right, control, handoff and system access. We deliver that as Job Architecture 2.0, and we run it as Foundational Architecture. It is what we then test each variation request against.

We run the test in the room where the requests actually arrive. We sit in your design sessions beside the integrator and the country teams, take each request through the spine, and record what was accepted and on whose authority. Where the answer changes an approval chain or an access role, we configure it with the administrators who will maintain it, then hand the spine and the register to your process owners and step back.

What compounds is the spine, because it outlives the implementation. The same definitions later drive your joiner-mover-leaver provisioning, the access that segregation of duties is tested against, and the audit scope for people and pay controls. When you route work to automation, they decide what a workflow or an agent may approve. Permission becomes a property of the role rather than of the platform. That is why the second country costs less than the first, and the twentieth costs less again.

What it costs to do nothing

The cost of granting variation on feasibility grounds is not paid during the programme. It is paid on every change afterwards, indefinitely.

Each variant multiplies regression scope. A platform release, a statutory update, a new benefit, a reorganization: all now tested against every branch you accepted, by a team sized for one design. HR change slows to the pace of your most complicated country and stays there.

It bites hardest in acquisitions, where you must decide which of twenty variants an acquired population joins and there is no defensible answer. It bites again in audit: segregation of duties and approval thresholds are tested per variant, so control scope grows with fragmentation rather than headcount.

You did not buy a platform to run twenty operating models. You bought it to be able to change one — and every variation granted on build effort quietly sold that back. That is the work we take on first, before your design freezes.