Forward Deployed HR (FDHR): el modelo operativo del profesional de RRHH aumentado

Llevo tiempo pensando en un problema concreto: la mayoría de los equipos de personas sabemos diagnosticar bien, pero nos quedamos cortos a la hora de construir e implementar. Forward Deployed HR (FDHR) es mi propuesta para cerrar esa brecha.

No es un cargo nuevo que haya que crear en el organigrama ni una certificación que garantice resultados. Es un modelo operativo: una manera de entender el trabajo de RRHH que asume responsabilidad explícita sobre la implementación, la adopción y el impacto de lo que se construye, integrándose a los equipos del negocio para resolver problemas reales con datos, automatización e inteligencia artificial.

La idea central es simple de enunciar y más difícil de sostener en la práctica: el profesional aumentado no se limita a saber, analizar o recomendar. Construye soluciones y las lleva hasta el punto exacto donde el problema ocurre, se queda ahí el tiempo necesario para ver si funcionan y ajusta lo que haga falta. Ahí es donde quiero poner el foco: en ese último tramo, el que va de la recomendación a la adopción real, porque es el que más se suele dejar de lado.

Qué cambia cuando RRHH construye

Cuando adoptamos este modelo, cambian al menos cuatro cosas en la forma de trabajar.

1. La unidad de trabajo deja de ser el proyecto genérico para toda la organización y pasa a ser el equipo o proceso concreto donde vive el problema.

2. La relación con el negocio deja de ser consultiva a distancia y se vuelve una colaboración sostenida, con presencia real en las conversaciones donde se toman decisiones operativas.

3. Los entregables dejan de ser exclusivamente informes, políticas o recomendaciones, y empiezan a incluir prototipos, flujos automatizados, tableros o asistentes que la gente usa todos los días.

4. Y el criterio de éxito deja de ser la entrega del diagnóstico para convertirse en la adopción efectiva y el impacto medible de la solución.

Cuatro transiciones, no una revolución completa

Quiero ser claro en algo: estas transiciones describen lógicas de trabajo, no un juicio sobre personas ni organizaciones. Muchos profesionales de RRHH ya operan con parte de esta lógica, y la administración de procesos y el diseño de políticas siguen siendo necesarios en cualquier función de personas madura. Lo que propongo es correr el énfasis hacia la construcción situada, sin eliminar lo demás.

De esperar solicitudes a ir donde ocurre el problema

• Antes: el equipo de personas recibe un pedido, un ticket o una consulta, y responde desde su propia mesa de trabajo.

• Ahora: el equipo se integra temporalmente al área donde el problema se manifiesta, observa el contexto de primera mano y participa de las conversaciones operativas.

De administrar procesos y políticas a diseñar soluciones orientadas a resultados del negocio

• Antes: el foco está en que el proceso se cumpla y la política esté actualizada.

• Ahora: el foco está en qué resultado de negocio necesita moverse, y el proceso o la política se ajustan en función de eso.

De recomendar buenas prácticas a construir e implementar con datos, automatización e IA

• Antes: el entregable es una presentación con benchmarks y recomendaciones generales.

• Ahora: el entregable incluye un prototipo funcional, construido con herramientas sin código, datos propios de la organización e IA cuando aporta valor real.

De entregar informes periódicos a medir impacto y mejorar continuamente

• Antes: el informe se entrega, se presenta y el ciclo se da por cerrado.

• Ahora: se define de antemano qué se va a medir, se observa la adopción real y se ajusta o se retira la solución según lo que muestran los datos.

El ciclo de cinco etapas

Sostengo FDHR sobre un ciclo de cinco etapas que se retroalimentan. Para ilustrarlo, uso un ejemplo hipotético que no corresponde a ningún caso real: un equipo de ventas con rotación alta en los primeros seis meses de contratación.

01. Entender

El punto de partida es integrarse al equipo, no analizarlo desde afuera. Eso implica conversar con las personas que están dejando el puesto, con sus líderes directos y con quienes se quedan, para detectar el problema real detrás del síntoma. En el ejemplo, eso podría significar descubrir que la rotación no se explica por compensación sino por falta de acompañamiento en las primeras semanas de venta activa.

02. Diseñar

La solución se define junto a quienes la van a usar, no para ellos. Siguiendo el ejemplo, eso podría traducirse en definir junto al equipo de ventas qué tipo de acompañamiento temprano tendría sentido y en qué momento del proceso hace falta una señal de alerta.

03. Construir

Se prototipa con las herramientas disponibles: sin código, automatización, datos propios e IA cuando aporta valor concreto. En el ejemplo, podría ser un tablero simple que cruce indicadores tempranos de desempeño con señales de riesgo, o un flujo automatizado que dispare un acompañamiento cuando aparecen ciertas señales.

04. Medir

Se evalúan dos cosas: si la solución se está usando (adopción) y si está generando el efecto esperado (impacto), con datos de personas y del negocio. En el ejemplo, eso sería observar si los líderes efectivamente usan el tablero y si, con el tiempo, la rotación temprana se mueve.

05. Iterar

Con esa evidencia, se ajusta lo que no funciona, se escala lo que sí funciona, o se retira la solución si no cumplió su propósito. Este es el paso que muchas veces falta en un ciclo tradicional de diagnóstico, y es también el que le da sentido a todos los anteriores.

De dónde tomo la inspiración

El nombre se inspira en el rol de Forward Deployed Engineer (FDE), que empresas como OpenAI, Anthropic y Palantir usan para describir una ingeniería que se despliega junto al cliente, construye con sus equipos y se responsabiliza de que la solución quede en uso, evaluada por adopción e impacto medible. De ahí tomo la filosofía de fondo, no los requisitos técnicos del puesto: la responsabilidad no termina en la propuesta, sino en verla funcionando en el terreno real.

Una capacidad complementaria al HRBP

FDHR no viene a reemplazar al HR Business Partner, y no quiero que se lea así. El marco de business partnering del CIPD ya describe una capacidad orientada a construir soluciones de personas junto al negocio, con evidencia y comprensión profunda del contexto. Muchos HRBPs trabajan así. Lo que aporta FDHR es un énfasis explícito en la construcción práctica apoyada en tecnología, la responsabilidad por la adopción y un ciclo de medición e iteración visible: una capacidad que se suma, no que compite.

Dónde practicar esta forma de trabajar

Dentro de HR Bootcamp® Aumentado, la Misión FDHR es el espacio donde ponemos en práctica esta forma de trabajar con ejercicios y casos reales de aplicación en RRHH. Su función es desarrollar la capacidad de movernos por las cinco etapas del ciclo, usando los últimos datos y tecnologías a nuestro favor. Mi apuesta de fondo es más simple que cualquier programa: si ya sabemos diagnosticar bien, el paso que falta es animarnos a construir con esa misma rigurosidad, en el contexto donde el problema efectivamente vive, y quedarnos ahí el tiempo necesario para saber si funcionó. Es lo que reflejamos en los 3 principios de referencia:

1. Diagnóstico: RRHH debe transformarse AHORA. El negocio cambió. La tecnología cambió. Las personas cambiaron. Seguir haciendo lo mismo ya no es una opción.

2. Camino: RRHH debe implementar soluciones para potenciar al negocio junto a las personas. Menos procesos genéricos. Más impacto real, medible y humano en cada decisión.

3. Modelo: RRHH debe ser Forward Deployed HR. Cerca del problema. Dentro del negocio. Con IA y datos. Construyendo soluciones junto a quienes las necesitan.