Por funcionário, por cargo ou por driver? A primeira decisão de um modelo de RH
Todo projeto de planejamento de pessoas começa com uma pergunta que parece técnica e não é: em que nível a gente modela gente?
Ela costuma ser respondida na primeira semana, de passagem, muitas vezes pelo consultor. E é a decisão mais cara de desfazer no modelo inteiro — porque dimensões, segurança, telas de entrada e a integração com Finanças penduram todas nela.
São duas perguntas, não uma
O que normalmente se chama de "nível de detalhe" são dois eixos independentes que a gente costuma tratar como um só.
Primeiro eixo — o que uma linha representa. Pode ser por funcionário (uma linha por pessoa) ou por cargo/vaga (uma linha por posição). Mais detalhe de um lado, mais agregação do outro.
Segundo eixo — de onde vem o número. Pode ser digitado (decidido linha a linha), por driver (calculado a partir de uma regra) ou inferido (deduzido do histórico).
Os dois eixos se combinam. A combinação mais comum de longe é por funcionário com movimentações digitadas — e ela funciona bem para orçamento anual. Cargo e driver ganham peso conforme a escala e o horizonte do planejamento aumentam.
Antes de escolher: o que a empresa já usa?
Essa é a pergunta que deveria vir primeiro, e raramente vem.
O modelo vai ser conferido contra alguma coisa no primeiro mês de uso — o relatório de headcount que o RH já emite, o realizado da folha, o número que a diretoria já conhece. Um nível de detalhe diferente do que já existe significa custo de reconciliação todo ciclo.
Isso não é impeditivo. Às vezes o nível novo é justamente o ganho do projeto. Mas vale escolher com esse custo na mesa, e não descobri-lo em fevereiro.
Por funcionário: o padrão, e por que
É o que espelha o que o RH já tem no sistema, e é o que a maioria dos clientes espera de um processo de orçamento.
A favor:
- Máxima customização. Data de admissão real, salário real, benefício específico, elegibilidade individual. Nada precisa ser aproximado.
- Conferência direta contra a folha e o cadastro.
Contra:
- Sensibilidade. É literalmente uma pessoa dentro do sistema. Isso muda a conversa de segurança de "controle de acesso" para "quem pode ver o quê, célula a célula".
- Perde relevância em escala e horizonte longo. O ano 3 de um plano de cinco anos com nome de pessoa na linha é ficção com aparência de precisão.
Por cargo: só funciona se a padronização existir de verdade
Modelar por cargo pressupõe faixas salariais e cargos padronizados que existem na prática, não só no organograma.
Sem isso, você constrói uma média que ninguém reconhece — e o modelo perde credibilidade na primeira vez que alguém confere a própria área.
Tem ainda um argumento que aparece sempre e quase nunca se sustenta: usar cargo para esconder salário individual. Qual é o ganho de anonimização quando só uma pessoa naquele centro de custo ocupa aquele cargo? Na prática, a proteção só funciona nos níveis mais altos da empresa — que é exatamente onde a confidencialidade importa mais e onde a agregação protege menos.
Por driver: precisa de uma relação medida, não de uma intuição
Driver funciona onde existe uma relação estável e já medida entre volume e pessoas: chamados por hora, toneladas por dia, leitos por turno, caixas por loja.
Onde essa medição não existe, o driver é chute em formato de fórmula — e é pior que um chute, porque a fórmula dá autoridade ao número.
Um teste simples antes de adotar: alguém já reporta esse índice hoje, sem o modelo de planejamento? Se a resposta for "a gente teria que construir", o driver ainda não está pronto para sustentar headcount.
Por inferência: a expectativa de agora
Hoje é a expectativa mais comum na primeira reunião: que o sistema devolva o número em vez de recebê-lo.
Funciona onde há histórico confiável, série longa o suficiente, uma relação que se manteve estável — e alguém disposto a validar o que sai.
Sem isso, o modelo continua devolvendo um número. Ele só passa a decidir sozinho.
Quem enxerga o modelo
Antes de fechar o nível de detalhe, vale responder três coisas sobre o processo, não sobre a ferramenta:
- Quantas pessoas participam do ciclo?
- O processo é colaborativo ou centralizado no RH e no FP&A?
- Quão confidenciais são as decisões de movimentação?
Segurança por célula, aqui, não é item de "nice to have" — é parte da definição do modelo. Finanças precisa do custo de pessoal por centro de custo; Finanças não precisa do salário individual. Isso tem que estar desenhado, não combinado.
O risco que quase ninguém coloca na mesa
Junte três decisões que, isoladamente, parecem razoáveis:
por funcionário + horizonte longo + processo colaborativo.
O plano de redução passa a ter nomes dentro dele. Pessoas que ainda estão trabalhando, num sistema que vários times conseguem abrir, e o nome fica lá pelo ciclo inteiro.
Uma decisão que ninguém tomou ainda, morando dentro do modelo.
Dá para mitigar, e vale desenhar isso de propósito:
- Detalhe nominal com prazo. Nominal até o mês X do ciclo, por posição depois disso.
- Versão separada com acesso restrito para cenários de redução, fora da versão colaborativa.
- Redução modelada por posição e centro de custo, não por pessoa — a pessoa entra na execução, não no plano.
Depois da decisão, o modelo tem camadas previsíveis
Escolhido o nível, o resto de um modelo de RH é razoavelmente estável em qualquer cliente:
- Entradas — cadastro de pessoal (matrícula, cargo, nível, CC, situação), encargos e provisões (INSS, FGTS, 13º, férias), benefícios com elegibilidade e premissas (dissídio, inflação, data-base).
- Dimensões e versões — Pessoa, Vaga, Cargo, Nível, CC, Entidade, Tempo, Versão; e o de-para RH ↔ Finanças entre CC, conta contábil e rubrica.
- Núcleo — headcount e movimentação (ativos, admissões, desligamentos, vagas abertas, FTE por mês), salários e encargos com parâmetros configuráveis, benefícios aplicados por elegibilidade e projeções de dissídio e promoção.
- Consolidação e governança — custo de pessoal por CC, trava do plano aprovado, segurança por célula.
- Saídas — telas de entrada do RH, relatórios de headcount e custo, e consumo direto pelo FP&A como insumo de OPEX e DRE, sem exportação manual.
Repare que a decisão do primeiro eixo aparece em todas as cinco camadas. É por isso que ela é cara de desfazer: não é uma dimensão a mais, é o formato de tudo que vem depois.
Não existe resposta única
Existe uma conversa que precisa acontecer antes do primeiro cubo. E ela pertence ao cliente, não ao consultor.
O papel de quem implementa é colocar os trade-offs na mesa — inclusive o desconfortável — e garantir que a escolha seja uma decisão, e não uma herança do template que o consultor usou no projeto anterior.
A gente modela custo de pessoal dentro do planejamento integrado há mais de 15 anos — veja como tratamos RH e workforce planning ou fale com a gente para discutir o seu caso.