GW
HomeWorkAboutNotesStackLab
Experience atOmnicom Group

Driving financial systems and automation across global teams.

Builder ofEnterprise AI Systems

AI agents, audit workflows, and decision intelligence at scale.

Based inNew York City

Building systems for enterprises around the world.

HomeNotesWorkAboutStackLabPartners
XLinkedInGitHubEmailllms.txt
© 2026 · New York City

Workforce Planning Has an Ownership Problem

Sep 10, 2026

In most companies, people cost is the largest line in the operating plan, and the data behind it is the least trusted. That is not a technology gap. It is an ownership gap, and it sits exactly between HR and Finance.

HR owns the system of record. Workday, or whatever holds the employee. Finance owns the forecast. Neither owns the definitions that connect them, so every planning cycle starts with the same argument: how many people do we actually have.

Three numbers that never match

Headcount, FTE, and cost sound like one thing. They are three things, and every function counts them differently.

HR counts employees on the active roster. Finance counts positions in the budget, including open requisitions that have money attached. Payroll counts whoever got paid. Contractors appear in one, two, or none of these depending on the company. A part-time employee is one head, half an FTE, and a cost that depends on the hours.

Put those in a planning model without agreeing the definitions first and the model will faithfully produce a forecast nobody believes.

The privacy constraint is real

Workforce data is the most sensitive data in the plan. Salaries, terminations, performance, medical leave. The planning team should never see employee-level detail, and in most jurisdictions cannot without a documented purpose.

This is usually treated as a reason to keep workforce planning in a spreadsheet the head of FP&A maintains alone. It should be treated as a design requirement. The integration from HCM to the planning model has to aggregate before it lands: role, cost band, org unit, start and end dates. Not names. Access to the underlying detail stays with HR, and the planning model is provably unable to expose what it does not hold.

Done right, this makes the integration more acceptable to HR, not less, because the data leaving their system is already anonymized.

What a working design looks like

Agree the definitions in writing before any data moves. Headcount, FTE, cost, and what counts as an open position. Get HR and Finance to sign it. This document prevents more forecast errors than any pipeline.

Pull only approved fields from the HCM, aggregated to the level the plan needs. Give the planning model role-based access so a planner sees cost and role for their area and nothing else.

Set the refresh to the planning calendar. A workforce change that reaches the forecast the cycle after it happened is a variance waiting to be explained. Weekly is usually enough. Real-time is rarely worth the complexity.

Keep the movement between versions reviewable. When the forecast changes because headcount changed, a reviewer should be able to see which roles moved and why, without opening HR's system.

Why the labs keep naming it

Finance systems postings at the AI labs list workforce planning cycles by name, alongside monthly forecasting and annual planning. For a company hiring hundreds of people a quarter, headcount is the plan. The person they want is not a Workday administrator or an FP&A analyst. It is someone who can sit between the two functions, write the definitions, build the governed path, and make the largest number in the forecast trustworthy.

Ask a follow-up about this note
$