Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70

Tiempo medio de lectura: 10 minutos.

 

Este artículo presenta un caso de estudio de una implementación de un sistema Kanban en un Departamento de RRHH.

 Introducción

El Departamento de Recursos Humanos ofrece una multitud de servicios a diferentes clientes internos de las empresas.

Kanban es una metodología ágil que ofrece unas interesantes ventajas a la hora de gestionar flexiblemente la entrega de servicios de RRHH.

En este artículo vamos a mostrar el proceso de diseño de un sistema Kanban que realizamos entre finales de 2019 y principios de 2020.

Esta implementación de Kanban se realizó en el Departamento de RRHH de una empresa del sector químico filial de una multinacional europea, con productos destinados al sector de alimentación y farmacéutico principalmente.

La empresa tiene más de 260 empleados y ha experimentado un sustancial crecimiento a causa del traslado de nuevas líneas de actividad a su planta de producción.

Como es típico en el sector industrial, los aspectos de relaciones laborales cobran bastante relevancia.


 Causas de insatisfacción

La motivación para el cambio eran diversas. La principal era aliviar la sobrecarga de trabajo y la sensación de que se acumula el trabajo en fechas concretas.

El número de interrupciones era muy elevado y muchos ítems estaban bloqueados bastante tiempo, tanto por falta de información o aprobaciones así como por la concurrencia de interrupciones.

Existía una parte de demanda por fallos, derivada de problemas heredados, especialmente políticas laborales que había tomado la anterior Dirección de RRHH y que habían dado lugar a problemas administrativos diversos y un Comité de Empresa especialmente conflictivo, lo que añadía un factor de imprevisibilidad.

Por otro lado existía la necesidad de dar más visibilidad al trabajo y mejorar la priorización para conseguir mejorar el cumplimiento de plazos.

Alivio sobrecarga agenda Kanban

 Análisis de la demanda


 Los clientes

El Departamento de RRHH tiene múltiples clientes a los que debe dar servicios:
  • Los otros departamentos de la empresa, la Dirección y los servicios corporativos.
  • Los empleados.
  • La Administración Pública (Seguridad Social, etc.).
  Además encontramos stakeholders como los sindicatos.

 

 Los servicios

Los servicios prestados son diversos:
  • Selección y contratación de personal.
  • Bajas de personal.
  • Nóminas, retribución variable y otras formas de compensación.
  • Gestión de las condiciones laborales.
  • Relaciones laborales.
  • Formación y desarrollo.
  • Gestión de la carrera profesional.
  • Creación y mantenimiento de la estructura organizativa y descripciones de puestos.
  • Gestión de disciplina.
  • Gestión del clima y la motivación.
  • Proyectos estratégicos, tanto de la empresa como corporativos (despliegue de un nuevo ERP, planes de igualdad,…).

Los aspectos de Seguridad e Higiene, de gran importancia en la industria química, dependían del Departamento de Operaciones.

 

 Expectativas de nivel de servicio


Desde el punto de vista de las expectativas de entrega, existían ítems que deben entregarse en fecha fija (p. ej. el pago de nóminas, seguros sociales,…), otros que tienen un SLA rígido (plazos legales para informar altas, bajas, etc.), además de otros que tienen algo más de laxitud en las fechas de entrega pese a que exista una cierta expectativa de plazos.

 Patrones de demanda

Por lo que respectaba al patrón de entrada de las peticiones de trabajo al Departamento de RRHH, hay algunos que son claramente recurrentes y previsibles en sus fechas de realización (nóminas y seguros sociales), que generalmente suceden mensualmente.

Otros son recurrentes aunque sin fechas fijas (relaciones laborales).

Y finalmente hay otros que pueden llegar de forma no previsible y de ejecución no diferible (conflictos laborales, disciplina, peticiones de servicios corporativos o de Dirección,…) o bien de duración imprevisible (selección de puestos muy especializados), que se distribuyen durante todo el año.

Existen además actividades especiales que se realizan en momentos puntuales a finales de año (cierres) e inicios (presupuesto, planes anuales,…).

La suma de peticiones de llegada impredecible y plazos de cumplimiento estrictos ocasiona avalanchas de trabajo que tensionan el Departamento.

Esto hace que el trabajo con sprints clásicos sea complejo a menos que el Departamento tenga una capacidad sobrada para absorber esa demanda oscilante.

Si el Departamento es pequeño –o está infradimensionado– el uso de sprints puede presentar problemas debido a esa demanda imprevisible y no diferible a menos que dejen un amplio margen de capacidad no utilizada para absorber la llegada de esas peticiones.

Por este motivo el Departamento seleccionó Kanban como la metodología ágil a utilizar.


 Capacidad

El Departamento tiene 4 personas, incluyendo a su Directora, que había entrado recientemente. La coordinación se había realizado hasta entonces de forma casual, vía conversaciones presenciales, llamadas y envío de correos,…

Dos técnicas estaban dedicadas a gestión laboral y aspectos administrativos mientras que la tercera dedicaba parte de su tiempo a esta parte laboral y otra a los aspectos de selección, formación y desarrollo. La Directora dedicaba su tiempo principalmente a la Dirección del Departamento, proyectos y la parte más estratégica de la selección, formación y desarrollo así como la parte legal y de relaciones laborales.

 Clases de servicio

Hasta entonces el Departamento había realizado una priorización un tanto errática. Los servicios de fecha o SLA fijo (nóminas, comunicación de altas y bajas a la Seguridad Social, etc.) tenían prioridad así como las peticiones de Dirección o de los servicios corporativos.

Para gestionar las expectativas de entrega, el Departamento optó por definir más claramente las prioridades para utilizar las clases de servicio basadas en el coste del retraso.

La clase de servicio de fecha fija se aplicarían a nóminas, seguros sociales y los que tienen plazos regulados (altas y bajas de contratos, etc.), así como determinados proyectos (despliegue de ERP).

La clase de servicio estándar constituían el grueso de la demanda (selección, formación, la inmensa mayoría de las selecciones,…).

La clase de servicio de intangibles se aplicaba a acciones internas de mejora y a iniciativas en la parte “soft”, que tienen un impacto más a medio y largo plazo.

La clase expedite se aplicarían a las temibles e impredecibles crisis.

Se requirió una cierta dosis de pedagogía para acostumbrar a los clientes a esperar unos ciertos SLAs.

El workflow

El workflow es muy variado y depende del tipo de ítem. En la selección, formación y otras acciones de desarrollo tenía unas fases similares:
  • Definición de requisitos.
  • Búsqueda.
  • Evaluación.
  • Propuesta.
  • Cierre.
En la selección la fase de definición de requisitos consiste en la definición del puesto y del perfil. La búsqueda consiste en la identificación de candidatos, principalmente a través de redes sociales profesionales hacia candidatos que no buscaban activamente. La evaluación consiste en el proceso de entrevistas preliminares y otras pruebas por parte del Departamento. La propuesta consiste en la transferencia de una lista reducida de candidatos al Departamento y el cierre consiste en la comunicación de los resultados a los participantes y la contratación.

En el caso de la formación la búsqueda consiste en la exploración de proveedores y la comunicación de las necesidades formativas identificadas en la definición de requisitos. La evaluación consiste en la decisión sobre la mejor alternativa, que en formaciones técnicas realiza el Departamento solicitante y en las relativas a habilidades directivas realiza el propio Departamento de RRHH.

Otras acciones de desarrollo consisten en actuaciones infrecuentes como off-sites, assessment centers,…

La mayoría de trámites de gestión laboral (nóminas, bajas,…) tiene un workflow similar:
  • Recogida de información.
  • Preparación.
  • Validación.
  • Ejecución.
Las actividades de cada una de estas fases varían en el tipo de servicio. En el caso de la preparación de nóminas, en la recogida de información se obtienen los datos de horas extraordinarias, días de bajas, vacaciones,…

En esa misma fase, para la realización de bajas se recoge el nombre de la persona afectada,…

Tablero Kanban para RRHH

Diseño del sistema Kanban

 Diseño del tablero

El tablero se realizó a través de una herramienta digital debido a la necesidad de evitar que otras personas de fuera del Departamento vieran su actividad. Se decidió que determinados ítems infrecuentes que requieren una gran reserva durante su ejecución –p. ej. despidos de personal– no se representarían en el tablero hasta finalizados.

Un ítem como una selección de un puesto, o una formación pueden tener una duración muy larga (entre 1,5 y 3 meses en la mayoría de los casos, en ocasiones bastante más).

Por un lado estaría la definición del perfil que se realiza una única vez. Una vez realizada se realiza la búsqueda de candidatos (que puede tener varias iteraciones si los inicialmente evaluados no se ajustan a las expectativas). Luego se realizará la evaluación de cada candidato. Una vez revisados los candidatos se propondrá una decisión al Departamento cliente. Si éste la valida tras entrevistar a los candidatos se realizará la negociación final y el cierre del proceso con el candidato seleccionado.

En caso de tratarse cada proceso de selección como un único ítem eso significaría mantener un WIP muy alto en el tablero (y sistema). Por ello el Departamento decidió tratar estos servicios como una épica compuesta de un lote de ítems. Eso permitía un workflow mucho más simple con ítems de pequeño tamaño que pueden fluir rápidamente.

Por otro lado, las actividades de gestión laboral se ejecutan rápidamente (con un máximo de unos 2 días como máximo si la información necesaria se dispone al inicio), con algunas de las fases de duración normalmente muy corta. Eso también desaconsejaba detallar su workflow.

Por ello se definió un tablero con dos swimlanes:

a. Swimlane de servicios. Por él discurren los ítems de corta duración (menos de 3 días en progreso). Tiene las columnas siguientes:

  • “Backlog”,
  • “Next”,
  • “En progreso”, y;
  • “Completado”.

b. Swimlane de proyectos. Por él discurren el trabajo que puede estar en curso durante un período largo como los proyectos o bien servicios como una selección o una formación. Tiene las siguientes columnas:

  • Backlog.
  • “Next – proyecto”. Aquí están las tarjetas que representan proyectos o lotes de servicios de largo tiempo de ciclo que han sido comprometidas para iniciarse. Las tarjetas hijas en las que se descomponen las épicas se mueven en las siguientes columnas.
  • “Next – Sub”, con los ítems hijos comprometidos en para ejecutar próximamente.
  • “En progreso”, con los ítems en ejecución.
  • “Completado”.

Cuando todos los ítems hijos están finalizados se lleva la épica a la columna de completado.

 Diseño de las tarjetas

Por lo que se refiere al diseño de las tarjetas, se adoptaron las siguientes convenciones:

  • El color de las tarjetas indica el tipo de ítem.
  • Las tarjetas tienen una etiqueta de color que marca las clases de servicio más elevadas.
  • Se indican en la tarjeta el desglose de los ítems hijos, en caso de tenerlos, y sus códigos una vez se crean.
  • Se indica con etiquetas de colores los ítems bloqueados, la demanda por fallos y los riesgos.

Respecto a la información respecto a fechas, se indica:

  • La fecha de inicio y de finalización para calcular el lead time.
  • La fecha límite para los ítems de fecha fija.
  • El SLA para aquellos ítems que tienen un plazo.

Cada vez que se ejcuta un ítem recurrente (p. ej. nómina) se pone el siguiente en el backlog para seleccionarlo en el momento en el que corresponda.

 Límites de WIP

Se introdujo un límite de WIP de 6 tarjetas para la columna «En progreso» del swimlane de Proyectos y otras 6 para la del swimlane de Servicios.

Se definió una política de excepciones a este WIP en caso de “fuegos”.

Por lo que respecta a la columna de «Next», se estableció un límite de WIP de 12 ítems resultados de dividir proyectos o servicios grandes («Next – Sub») para un máximo de 6 épicas abiertas y de 12 ítems para el swimlane de Servicios, que se revisarían más adelante según madurara la implementación.

 Eventos

Semanalmente se realiza la reposición de tarjetas. No obstante, los ítems urgentes que hayan acabado de llegar se pueden seleccionar en el Daily Kanban.

Mensualmente realizan una retrospectiva de equipo.

 Resultado

El resultado conseguido fue una reducción del trabajo en curso y una menor sobrecarga, una mayor visibilidad del trabajo, una mejor priorización por parte del equipo. La realización de reuniones diarias mejoró la coordinación y redujo la necesidad de consultas para conocer el estado del trabajo.

Si quieres aprender más sobre Kanban, cuentas con nuestros cursos oficiales de Kanban University que te permitirán, además, obtener las diferentes certificaciones de esta metodología ágil.

¿Podemos ofrecerte más información?

Newsletter mensual

Cada mes enviamos una newsletter a más de 1.000 personas con contenido interesante que hemos encontrado en Internet, artículos nuestros y nuestras novedades. Queremos ofrecer contenido de calidad y no saturarte con muchos correos.

Formulario de contacto

Si crees que podemos ayudarte con alguna duda o necesidad de soporte, no dudes en contactar con nosotros. Estaremos encantados de ayudar.

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.