From signals to decisions: planning, budget and HR Intelligence

The last three modules in the lifecycle are the ones executives actually ask about, and they only work if everything before them is connected. Headcount Planning, Budget and HR Intelligence are where the foundation stops being an architectural argument and starts being a decision.

Headcount Planning — from demand to approved capacity

Plan roles and timing by business dimension, compare scenarios, and connect funded gaps directly to Recruiting. The chain is short and it is explicit: demand 12, approved 10, gap 2, recruit for South Sales in M2.

That last step is the one that usually breaks elsewhere. An approved gap that does not become a recruiting priority is just a number in a deck.

Budget — see cost before the variance grows

Budget connects planned, actual and committed workforce costs so owners can manage variance while there is still time to act. Remaining is derived, not entered: plan minus actual minus committed.

• Set the plan by dimension and period.
• Load actuals — from payroll, approved requests, imports or manual categories.
• Review variance against commitments already made.
• Reallocate with evidence rather than instinct.

Committed is the field that changes conversations. A budget that shows 82% actual looks healthy until you add the 10% already committed through approved-but-unpaid requests.

HR Intelligence — better questions, earlier

HR Intelligence connects workforce, attendance, payroll, recruiting, learning, performance, budget, approvals and ticket data. It surfaces risks and, more usefully, suggests what to investigate next.

A real example of the shape it takes: headcount trails plan in H2, learning is at risk, and recruiting has the longest approval lead time. The suggested investigation writes itself — check vacancies, recruiting conversion and approval lead time, in that order.

The value is not the dashboard. It is that three separate signals were readable against each other at all.

None of those three signals lives in the same module. In a disconnected stack, spotting the relationship between them is a quarterly exercise somebody has to volunteer for. On a shared foundation it is a query — which is the entire reason we built HumanC the way we did.