The HR Operating Model Is Under Strain, and Redesigning the Org Chart Won't Fix It
Quick answer: Most HR operating model redesigns are aimed at the right goals: one connected employee experience, AI in the workflow, consistency across a global workforce, and HR as a real strategic partner. The catch is that all of those goals sit on top of a data foundation most HR organizations do not control. Redraw the org chart and rebuild service delivery, and if the data layer underneath stays fragmented and ungoverned, the new model strains the same way the old one did. The operating-model conversation is really a control conversation, and it starts underneath the structure, not at it.
The Strain Is Real
The model most large HR functions run on has been stable for a long time. Business partners, centers of excellence, and shared services, arranged to balance strategic partnership with efficient delivery. It was a sound design for the world it was built in.
That world changed faster than the model did. HR is now expected to produce strategic insight on demand, put AI to work inside its own processes, deliver one experience across a workforce spread over many countries and regulations, and move at the pace of the business rather than the pace of an annual cycle.
The strain shows up in the day to day. Several platforms with governance split across teams. Processes with unclear ownership. Duplicated work and competing priorities. An employee experience that changes depending on who you are and where you sit. The common read is that this is an execution problem or a structure problem, so the response is a reorganization. The strain is real, and the reorganization usually does not relieve it.
What Every Redesign Quietly Assumes
Look at how these redesigns actually run. Teams redraw the boxes, redefine service tiers, standardize processes, and consolidate platforms. All useful work.
Underneath every one of those moves sits an assumption that nobody writes down: that HR data is connected, current, reconciled, and governed well enough for the new model to run on. In most organizations that assumption is false.
The HRIS, payroll, benefits, and recruiting systems each hold a partial version of the truth. Nobody owns the reconciliation between them. Changes move on batch cycles and manual fixes, and no single layer decides what is correct as of a given date. You can design an elegant target operating model on top of that and still get fragmentation, because the fragmentation does not live in the org chart. It lives below it, in the data.
Why the Foundation Decides the Outcome
Take the four things nearly every modern HR strategy is reaching for, and look at what each one requires underneath to actually work.
One connected employee experience. This needs a single reconciled source of truth, so an employee gets consistent answers no matter which team or system serves them. Without that, the experience fragments by design, because each function is reading a different version of the person.
AI inside the workflow. An agent or model is only as reliable as the data beneath it. Point it at unreconciled data with no point-in-time model and it repeats and amplifies every inconsistency at machine speed. Embedding intelligence raises the bar on the foundation rather than lowering it, which is the opposite of how it is usually budgeted.
Consistency across a global workforce. Standardizing experience and process across entities requires control over how data is structured and how it flows between them. Standard processes running on non-standard data produce standard-looking reports that quietly disagree with each other.
Speed and strategic partnership. HR can only move at the speed of the layer it controls. When every data change waits on IT or an outside consultant, the strategic ambitions queue behind a ticket backlog, and the business stops treating HR as a partner it can move with.
Each of these is treated as an operating-model outcome. Each of them is actually decided by the data layer underneath the model.
This Is a Control Problem, Not a Structure Problem
Here is the part the reorg misses. HR is held back not by a shortage of data or talent, but by not controlling the systems that produce and move that data.
Structure sits on top of that control. Redraw the organization while the dependency stays in place, and the same fragmentation reassembles within a year, because the thing that caused it was never touched. The teams whose redesigns actually hold are the ones that fixed the foundation first, then let the operating model run on top of it.
That reframes the whole exercise. The question is not "what should the HR operating model look like." It is "what does HR need to control for any modern operating model to hold," and the answer is the data layer.
What the Foundation Actually Looks Like
The foundation is a layer HR owns that sits between the HR systems and the operating model. It connects the systems, holds one reconciled and point-in-time source of truth, governs who can see and do what, and lets reporting and agents run on top of the same trusted data.
The important property is ownership. HR configures and runs the layer, and IT keeps the guardrails it is accountable for, with scoped access and a full audit trail. HR gets speed and autonomy, IT keeps governance, and neither has to give up its mandate to the other.
With that layer in place, the operating-model ambitions stop fighting the plumbing. One experience becomes possible because everyone reads the same truth. AI becomes safe to embed because the data under it is reconciled. Global standardization becomes achievable because the data is controlled, not just the process. This is the layer we build at Aragorn, and it is described in full in The HR Control Layer.
Where to Start, Before the Reorg
The sequence matters more than the org design.
Before you move a single box, map your HR systems and find the specific places the data breaks today, the reconciliation nobody owns, the changes that move by hand, the questions that return different answers from different systems. Name the owner of that reconciliation. Fix the foundation. Then redesign the model on top of a layer that can actually carry it.
Do it in that order and the redesign holds. Do it in the other order and you will be redesigning again in eighteen months, for the same reasons.
If you are rethinking your operating model now, the most useful first step is a short working session where we map your systems and the places your data foundation will strain before the new model even goes live.