Embed Size (px)
Citation preview
MBA 2010
“LA MEJORA DE RESULTADOS EN PROCESOS NO OPERATIVOS
APLICANDO METODOLOGÍAS ÁGILES”
Año: 2012
Alumno: Javier Alejandro Re
Tutor: Viviana Suares
Lugar: Ciudad Autónoma de Buenos Aires
MBA 2010
1 de 50
AGRADECIMIENTOS
A mi hija Clara que nació durante el primer año en que cursé el MBA, y fue muy duro para mí dejarla
para asistir a clases, y a mi esposa Cecilia que me dio ánimo y aunque pasamos algunos momentos
difíciles durante la cursada del MBA me soportó, me ayudó y fue la principal impulsora para que
estudie esta maestría.
A Leopoldo Simini, que fue el gran impulsor de la metodología KANBAN en la empresa en la que
trabajo, principal ejecutor del proceso empírico de implementación de KANBAN que conforma esta
tesis, y quién me contagió ese entusiasmo por este tipo de métodos, que definitivamente prueban un
modelo excelente de trabajo.
A Inés Toyos y todo el equipo de reclutamiento del área de Recursos Humanos de Thomson Reuters
Cono Sur, por su paciencia y su predisposición a experimentar con nuevas ideas.
A Pello Yabén Solchaga, Director de RRHH de Thomson Reuters Cono Sur, por su apertura de
pensamiento, y la libertad de acción que nos dio con este trabajo para implementar esta metodología
a pesar de los desafíos continuos que tiene su equipo.
MBA 2010
2 de 50
INDICE
AGRADECIMIENTOS ............................................................................................................................. 1
INDICE .................................................................................................................................................... 2
RESUMEN .............................................................................................................................................. 4
INTRODUCCIÓN .................................................................................................................................... 5
OBJETIVOS ESPECÍFICOS ................................................................................................................... 8
CAPÍTULO I: MARCO TEÓRICO ........................................................................................................... 9
1.1. KANBAN .................................................................................................................................. 9
1.1.1. Definición ......................................................................................................................... 9
1.1.2. Visualizar el flujo de trabajo .......................................................................................... 10
1.1.3. Limitar el trabajo en progreso ....................................................................................... 10
1.1.4. Medir el tiempo de ciclo ................................................................................................ 10
1.2. SCRUM ................................................................................................................................. 11
1.2.1. Definición ....................................................................................................................... 11
1.2.2. Pilares ........................................................................................................................... 12
1.2.3. Puntos de control .......................................................................................................... 13
1.2.4. Roles ............................................................................................................................. 13
1.3. KANBAN vs SCRUM ............................................................................................................. 14
1.3.1. Nivel de prescripción ..................................................................................................... 14
1.3.2. Límites de trabajo en progreso ..................................................................................... 15
1.3.3. Cambios ........................................................................................................................ 16
1.4. Conclusión ............................................................................................................................. 17
CAPÍTULO II: CUERPO EMPÍRICO ..................................................................................................... 18
CAPÍTULO III: RELEVAMIENTO INICIAL ............................................................................................ 20
3.1. Diagramando el proceso ....................................................................................................... 20
3.2. Midiendo el estado actual del proceso de reclutamiento ...................................................... 23
CAPÍTULO IV: MEJORANDO EL PROCESO DE RECLUTAMIENTO IMPLEMENTANDO KANBAN 26
4.1. Implementación del método KANBAN en el proceso de reclutamiento................................ 26
4.1.1. Tablero KANBAN .......................................................................................................... 26
4.1.2. Tarjetas KANBAN.......................................................................................................... 27
4.1.3. Reuniones de seguimiento ............................................................................................ 30
4.1.4. Pasos y condiciones para el cambio de etapa de una tarjeta ...................................... 31
CAPÍTULO V: MIDIENDO EL RESULTADO DE LA MEJORA ............................................................. 33
5.1 Segunda encuesta de proceso de reclutamiento.................................................................. 33
MBA 2010
3 de 50
5.2 Tablero de bajas del proceso ................................................................................................ 36
5.3 Sesiones de retrospectiva ..................................................................................................... 36
CONCLUSIONES ................................................................................................................................. 39
GLOSARIO............................................................................................................................................ 40
BIBLIOGRAFÍA ..................................................................................................................................... 41
ANEXOS ............................................................................................................................................... 42
I. Encuesta Inicial de relevamiento ............................................................................................... 42
II. Encuesta final de relevamiento del proceso de reclutamiento................................................... 45
III. Encuesta final de relevamiento ............................................................................................. 45
IV. Fotos de evolución del Tablero Kanban del proceso de reclutamiento ................................ 48
MBA 2010
4 de 50
RESUMEN
Esta tesis pretende demostrar que el uso de metodologías ágiles derivados del Lean Management en
procesos no relacionados con el desarrollo de software, puede mejorar la ejecución de los mismos.
Para dicho fin esta tesis desarrolla la teoría de las distintas metodologías, en particular KANBAN y
SCRUM, realizando una comparación entre ambas, luego, explicar la implementación empírica de
una de estas metodologías en el proceso de reclutamiento de la compañía Thomson Reuters en
Argentina. En particular se utiliza KANBAN dado que la misma es agnóstica del proceso al que se
aplica1,
Para aplicar la misma se realizó un estudio preliminar del estado actual del proceso de reclutamiento
y se contó con el apoyo del equipo de RRHH que ejecuta dicho proceso, luego se implementó la
metodología KANBAN y se midió la mejora al fin de la implementación.
1 Se dice que es agnóstica porque no condiciona el tipo de procesos en el que se puede aplicar, SCRUM en particular solo se
aplica al desarrollo de software, KANBAN puede aplicarse al desarrollo de software o a cualquier otro proceso no relacionado
con el desarrollo de software.
MBA 2010
5 de 50
INTRODUCCIÓN
Mi interés inicial en esta materia empezó a partir de mi incorporación a Thomson Reuters en el año
2006, cuando me hice cargo de dos grupos del área de tecnología.
El primero era un equipo de desarrollo de soluciones para el proceso editorial de la compañía, que
consistía básicamente en el desarrollo y mantenimiento de un sistema de gestión documental,
denominado “Sistemas Editoriales”.
El segundo equipo era el equipo que mantenía los sistemas de negocio de la compañía
principalmente, el sistema de facturación, cobranzas y contabilidad de la misma, denominado
“Sistemas Comerciales”.
Ambos equipos a pesar de estar dentro del área de Tecnología de la compañía tenían realidades
muy distintas.
El equipo de Sistemas Editoriales, se caracterizaba por realizar el mantenimiento de un software
desarrollado en la compañía hacía un año, y que estaba requiriendo mucho crecimiento y el
agregado de nuevas funcionalidades para cumplir con las necesidades del negocio tanto para la
publicación de contenidos online como para optimizar el proceso editorial haciéndolo más
automatizado, por ende gran parte del trabajo era de pequeños proyectos de desarrollo sobre la
misma aplicación.
El equipo de Sistemas Comerciales, por otro lado, mantenía y daba soporte a una única aplicación
de gestión en general un paquete de software. En este caso era Peoplesoft en su versión 7.5.
Las realidades de ambos equipos eran distintas pero con un punto en común ya que mientras en el
primer caso, el equipo podía realizar desarrollos sobre el software, en el segundo caso, al ser un
paquete cerrado el desarrollo estaba limitado a las capacidades y limitaciones del producto.
A pesar de las diferencias entre ambos equipos encontré con los siguientes puntos en común:
Muchos requerimientos de cambios en tiempos muy cortos.
Necesidades urgentes por parte de los usuarios representantes del negocio.
Dificultad de priorizar por parte de los usuarios.
Ante estos puntos empecé a buscar una metodología que me ayudara a ordenar el trabajo de estos
equipos, y a la vez poder dar una respuesta al negocio de manera adecuada a las expectativas con
respecto al área de tecnología, que dicho sea de paso, eran muy altas, ya que en la gestión anterior
de tecnología había tenido muchos problemas de entrega en los proyectos.
MBA 2010
6 de 50
Intenté inicialmente aplicar algo de las metodologías de procesos de CMMI, las cuales son utilizadas
como estándar en la industria del desarrollo de aplicaciones de software, en las cuales había tenido
experiencia previa en mi anterior empleo.
El problema que encontré con dichas metodologías era que eran muy demandantes de
documentación y generación de evidencias, tanto o más que el proceso en sí que se quiere
normalizar. Dada esta situación comencé a evaluar alternativas y encontré algunas opciones
bastante nuevas para ese momento, en particular, la metodología de desarrollo ágil basada en
SCRUM. Esta metodología propone basándose en una derivación del Lean Management de Toyota
el uso de procesos ágiles de desarrollo y control de calidad periódicos para producir un proceso de
desarrollo evolutivo de software donde los principios básicos son:
División del ciclo de producción en períodos fijos denominados “Sprints”.
Poca documentación de respaldo para el proceso en sí, la mínima indispensable para que el
mismo funcione.
Reuniones diarias muy cortas de control del avance.
Controles recurrentes del producto generado.
Roles claros de responsabilidad en el proceso, con dos figuras clave: el Scrum Master, que
lleva y coordina el proceso, y el Product Owner que ordena las tareas pendientes por
prioridad para el negocio.
Ciclos de producción cortos, y limitados por tiempo, de manera tal de poder planificar siempre
las fechas de cierre de cada ciclo o Sprint.
Con la implementación de esta metodología logré muy buenos resultados, en particular en el equipo
de desarrollo de Sistemas Editoriales que tenía su foco en el desarrollo de nuevas versiones del
software editorial.
En el caso particular del equipo de Sistemas Comerciales, esta metodología no funcionó del todo
bien, dadas la distinta idiosincrasia del trabajo de este equipo, más enfocado como describí
anteriormente en mantenimiento y limitado proceso de desarrollo. No fue hasta el año 2010 en que
conocí la metodología KANBAN, que aplica mucho mejor a este tipo de procesos repetitivos, pero sin
foco en el producto, como SCRUM, sino con foco en el proceso de producción y la salida del mismo.
En particular la metodología KANBAN, sigue algunos lineamientos particulares dado que es un
modelo de “arrastre” o “pull”, o sea que un nuevo trabajo solo puede ser iniciado cuando el sistema
tiene capacidad para hacerlo y no puede sobrecargarse si los límites de trabajo en proceso se han
establecido adecuadamente, que como veremos más adelante es muy importante, es el que
determina el trabajo que puede realizarse.
MBA 2010
7 de 50
Por ende el límite de la cantidad de trabajo en proceso o “Work in progress” de KANBAN se aplica
mejor a los procesos repetitivos, como la producción de autos en TOYOTA o el mantenimiento de
software, que básicamente toma errores o mejoras pequeñas y las implementa en un software
existente, pero no es un proceso de desarrollo incremental donde el software se va construyendo de
a poco.
En este sentido es que comencé a incursionar en lo que a KANBAN se refiere, y entendí que
KANBAN con sus pocas reglas más que limitar el trabajo en progreso y libertad para definir el
proceso de “producción” puede adaptarse a cualquier proceso que uno quiera realizar, siempre y
cuando diseñe adecuadamente el mismo y ponga límites lógicos según la capacidad del equipo que
ejecuta el proceso mencionado, como así también, busca mejorar continuamente, parte fundamental
de la teoría de Lean Management.
Las áreas de compañías multinacionales poseen procesos formales estructurados que en el ámbito
cambiante y demandante de resultados de hoy en día, tienen problemas para alinearse al resto de
las áreas y tienen una reacción a los cambios lenta.
Esta tesis plantea la posibilidad de implementar metodologías ágiles utilizadas con éxito actualmente
en procesos de desarrollo de software como SCRUM o KANBAN en procesos de negocios no
operativos, en particular trata de la aplicación de KANBAN en el proceso de reclutamiento de la
compañía, a cargo del área de Recursos Humanos, planteando los siguientes objetivos específicos.
MBA 2010
8 de 50
OBJETIVOS ESPECÍFICOS
Identificar procesos de negocio que sean susceptibles de ser mejorados aplicando metodologías
ágiles: procesos que tengan muchos cambios, demanda de resultados en corto plazo.
Identificar métricas que determinen el estado actual del proceso de negocio en cuanto al
cumplimiento de sus objetivos y medirlos para obtener un estado inicial
Seleccionar un proceso de negocios de los identificados y realizar un experimento aplicando
alguna metodología ágil en el mismo a fin de probar la tesis.
Obtener métricas de los resultados del proceso de negocio con la nueva metodología.
MBA 2010
9 de 50
CAPÍTULO I: MARCO TEÓRICO
El método Lean Management nació en Toyota y fue creado por Taiichi Ono y tienen como base
fundamental dos pilares, el “just-in-time” y la automatización con un toque humano o
“Autonomatización” del término “Autonomation” en inglés, que es la herramienta para operar el
Kanban. Los procesos de desarrollo de software tanto SCRUM como KANBAN derivan de estas
prácticas. Ambos limitan alguna variable del proceso de producción en el caso de SCRUM el tiempo
del ciclo de producción, en el caso de KANBAN la cantidad de trabajo a realizar en cada paso del
proceso.
1.1. KANBAN
1.1.1. Definición
KANBAN deriva su nombre de las tarjetas utilizadas en el sistema de producción de Toyota, deriva
del término en japonés “kan-ban”, que significa, tarjeta de señalización. Estas tarjetas indican el
trabajo que debe realizarse en la siguiente etapa del proceso de producción, o qué materiales deben
agregarse al mismo. De esta manera las tarjetas indican qué debe realizarse por el proceso anterior y
van ajustando el proceso en tiempo real o “just-in-time” de esta manera se reducen por un lado la
necesidad de inventarios intermedios y también ajustan el proceso productivo a las necesidades del
cliente en lugar de hacer que la planta productiva produzca los más posible, sino lo necesario, lo cual
también reduce el stock o inventario de producto terminado.
Un ejemplo sencillo para explicar KANBAN que utiliza David Anderson es el de los jardines del
palacio del emperador en Japón. Los jardines de este palacio están abiertos al público para ser
visitados y la forma en que se administra el ingreso de visitantes al mismo es muy sencilla pero a la
vez muy eficiente para lograr que el mismo no se vea colapsado de visitantes que pudieran arruinar
el mismo.
El sistema funciona de la siguiente manera: a cada visitante a los jardines del palacio imperial para
hacer un picnic se les entrega una tarjeta plástica que no tiene costo. Cuando el visitante se retira de
los jardines por cualquiera de las puertas la misma es devuelta al personal que controla el ingreso al
parque y se devuelve a un tablero donde se almacenan. ¿Cuál es el objetivo de entregar dichas
tarjetas, ya que no tienen costo, ni numeración ni ningún atributo que identifique a quien fueron
entregadas? La respuesta es simple, limitar la cantidad de visitantes que ingresan al mismo tiempo a
los jardines. De esta manera los jardines del palacio imperial en Tokio utilizan un sistema KANBAN
para limitar la cantidad de visitantes que ingresan, y cada vez que sale uno puede ingresar otro. Este
ejemplo es muy simple, pero representa la esencia de un sistema KANBAN y cómo funcionan las
tarjetas.
MBA 2010
10 de 50
1.1.2. Visualizar el flujo de trabajo
Para visualizar el flujo de trabajo, KANBAN divide el trabajo en bloques comúnmente denominadas
“stories” y escribirlas en una tarjeta similar a las Kanban utilizadas en el proceso productivo de
Toyota, las mismas representan un ítem de trabajo a realizar, en general denominados “story” dado
que es lo que los usuarios explican como requerimiento del sistema a desarrollar.
Utilizando un tablero o pizarra se divide el mismo en columnas que ilustran donde está cada bloque
en el flujo de trabajo
1.1.3. Limitar el trabajo en progreso
La limitación del trabajo en progreso o “work in progress” se realiza asignándole límites concretos a
cuántos elementos pueden estar en progreso en cada estado del flujo de trabajo.
1.1.4. Medir el tiempo de ciclo
Se debe medir el ciclo de tiempo o “lead time”, optimizando el proceso para que el ciclo sea tan
pequeño en términos de tiempo como sea posible.
ILUSTRACIÓN 2: TABLERO DE KANBAN PARA DESARROLLO DE SOFTWARE
ILUSTRACIÓN 1 TICKETS DE ADMISSION DE LOS JARDINES
IMPERIALS DE TOKIO
MBA 2010
11 de 50
Entonces, las “stories” en el proceso de KANBAN son elementos de trabajo que “nacen” cuando el
sistema tiene capacidad para absorberlo, por eso es un sistema “pull” o de “arrastre”, y se mueve por
todo el proceso de desarrollo hasta finalizar el mismo cuando la “story” o porción de software está
listo para ser entregado al usuario o cliente.
ILUSTRACIÓN 3: EJEMPLO DE TABLERO KANBAN DE DESARROLLO DE SOFTWARE
Un punto importante de KANBAN que lo hace simple pero a la vez tiene implicancias importantes, es
la limitación del trabajo en proceso, cuando suficientes elementos se bloquean el sistema entero se
bloquea, obligando al equipo que lo administra a destrabar el problema y a mejorar. Esto genera una
cultura de mejora continua en el equipo y a la vez ordena el proceso en lo importante y no en lo
urgente, dado que si el sistema se bloquea el equipo no puede producir nada más (Anderson, 2010).
“Las metodologías Ágiles han obtenido buenos resultados proporcionando transparencia respecto al
trabajo en curso y completado, así como en el reporte de métricas como la velocidad (cantidad de
trabajo realizada en una iteración). KANBAN sin embargo va un paso más allá y proporciona
transparencia al proceso y su flujo”. (Kniberg & Skarin, 2010)
1.2. SCRUM
1.2.1. Definición
SCRUM está basado en la división del equipo de trabajo en equipos pequeños y sus roles, eventos,
artefactos y reglas, basándose en tres pilares del proceso de control empírico: transparencia,
inspección y adaptación. (Schwaber & Sutherland, 1991-2011)
MBA 2010
12 de 50
Además SCRUM divide el trabajo a realizar en pequeñas porciones comúnmente denominadas
“stories”, las cuales deben estar incluidas en una lista ordenadas por prioridad denominada “product
backlog” y se estima el esfuerzo para producir cada uno de estos elementos. Luego divide el tiempo
de desarrollo en iteraciones pequeñas de duración fija (generalmente de 1 a 4 semanas como
máximo) denominadas “sprint” que producen código entregable2 y demostrado en cada iteración.
(Kniberg & Skarin, 2010). Luego optimiza el plan de entregas, revisando las prioridades del product
backlog con el cliente y optimiza el proceso teniendo una restrospectiva después de cada iteración.
ILUSTRACIÓN 4: EJEMPLO DE TABLERO SCRUM
1.2.2. Pilares
Los tres pilares definidos por Schwaber y Sutherland para el proceso de SCRUM son:
1.2.2.1. Transparencia
Todo el proceso deber poder ser visualizado por los responsables del mismo y requiere que el mismo
tenga indicadores estandarizados que permitan un entendimiento en común para todos.
1.2.2.2. Inspección
Consiste en inspeccionar los artefactos producidos por el proceso y detectar variaciones indeseables:
Estas inspecciones deben ser frecuentes para detectar problemas rápidamente, pero no tan
frecuentes que afecten la capacidad de producción del proceso.
1.2.2.3. Adaptación
2 Se refiere al código fuente producido como parte del software y entregable indica la capacidad de esta porción de software
MBA 2010
13 de 50
Cuando se detecta que uno o más aspectos del proceso están fuera de los límites aceptables el
proceso debe ajustarse lo más pronto posible para minimizar mayores desvíos. Para controlar el
proceso, SCRUM establece puntos de control específicos para controlar los desvíos. Estos puntos de
control consisten en reuniones informales, generalmente de poca duración que se realizan de pie
(para evitar prolongarlas en el tiempo) y que tienen una duración generalmente fija y estricta.
1.2.3. Puntos de control
Las reuniones de puntos de control son las siguientes:
1.2.3.1. Sprint Planning Meeting
Reunión del equipo en la que se revisa que ítems del product backlog serán incluidos en el siguiente
sprint basado en las prioridades asignadas por el cliente representado en el rol de Product Owner y
el equipo de Scrum, basándose en las estimaciones realizadas y en la velocidad de trabajo.
1.2.3.2. Daily Scrum
Es una reunión diaria de 15 minutos donde solo participa el equipo de desarrollo del producto con el
objetivo de sincronizar los trabajos realizados y planificar las próximas 24 horas, revisando el trabajo
realizado desde la última reunión diaria (el día anterior). Se revisan los puntos que salieron bien y
qué problemas tuvo el equipo de desarrollo para realizar el trabajo asignado.
1.2.3.3. Sprint Review Meeting
Reunión que se lleva a cabo al finalizar cada sprint donde se revisa el trabajo realizado en el sprint
finalizado, revisando el incremento en la construcción del software, en la misma participa todo el
equipo de Scrum y los clientes o stakeholders. La salida de esta reunión es un product backlog
actualizado con los cambios solicitados por el cliente
1.2.3.4. Sprint Retrospective
Reunión que se realice al fin de cada sprint y antes de la reunión de planificación del próximo sprint,
para identificar mejoras en las siguientes áreas: personas, relaciones, procesos y herramientas.
1.2.4. Roles
SCRUM identifica los roles claramente y de una forma estricta, que tienen responsabilidades y tareas
específicas a saber:
1.2.4.1. Scrum Master
Es el responsable que el equipo de Scrum adhiera a los valores, prácticas y normas explicadas
anteriormente y además lidera al equipo de Scrum, los capacita en las prácticas de la metodología, y
fomenta la autogestión. “El papel del Scrum Master es el de servidor y líder del equipo de Scrum. Sin
embargo, el Scrum Master no gestiona al Equipo Scrum; el equipo Scrum es auto-gestionado.”
(Schwaber & Sutherland, 1991-2011).
MBA 2010
14 de 50
1.2.4.2. Product Owner
Es el único responsable de mantener actualizado y priorizar según el valor de cada elemento del
Product Backlog. Es fundamental que el que desempeña el rol de Product Owner, nunca puede
desempeña el rol de Scrum Master. Debe ser una única persona y no un comité aunque puede estar
asesorado por uno. “Para que el Propietario del Producto tenga éxito, todos en la organización deben
respetar sus decisiones. Nadie está autorizado a obligar al Equipo a trabajar bajo un conjunto
diferente de prioridades, y a los Equipos no se les permite prestar atención a nadie que diga lo
contrario.” (Schwaber & Sutherland, 1991-2011)
1.2.4.3. El equipo
Los miembros del equipo son los que convierten el Product Backlog en entregables durante los
incrementales. El equipo debe ser multifuncional, es decir, no hay títulos en el equipo y todos
colaboran para construir el producto final. Además el equipo se auto organiza, ni siquiera el Scrum
Master tiene potestad para organizar el equipo de alguna manera. El tamaño óptimo de un equipo
Scrum es de 7 personas, más menos, 2 personas. Con más de 9 personas el equipo empieza a tener
problemas, dado que requiere demasiada coordinación. Se debe tener cuidado con los cambios en la
composición del equipo, dado que el mismo adquiere cierta dinámica de organización que al cambiar
los miembros puede ser afectada negativamente.
1.3. KANBAN vs SCRUM
La diferencia fundamental entre ambos sistemas para el desarrollo de software, SCRUM y KANBAN
es que ambos requieren que el proceso de trabajo tenga límites, ambos son sistemas pull pero
limitan una variable distinta del proceso.
1.3.1. Nivel de prescripción
En el caso de SCRUM el mismo es más prescriptivo que KANBAN, como se puede observar en la
descripción de ambos sistemas, SCRUM tiene muchas más reglas a seguir y más condiciones que
deben cumplirse.
En el siguiente cuadro se observan varias metodologías de desarrollo de software con distintos
grados de reglas a seguir. Cuanto menos reglas la herramienta a seguir tiene, se los denomina más
adaptativos. (Kniberg & Skarin, 2010)
MBA 2010
15 de 50
ILUSTRACIÓN 5: HERRAMIENTAS DE DESARROLLO ADAPTATIVAS VS PRESCRIPTIVAS
SCRUM prescribe roles, reuniones específicas y actividades para cada uno de los roles. En el caso
de KANBAN, deja casi todo el proceso abierto, las únicas prescripciones son: Visualiza el flujo de
trabajo, limita el trabajo en progreso (WIP), o sea que está muy cerca de la opción “Haz lo que sea”,
sin embargo es realmente una herramienta muy poderosa.
Con respecto a los roles, como vimos, SCRUM prescribe 3 roles específicos, Scrum Master, Product
Owner y el Equipo de Scrum, por el contrario KANBAN no prescribe ningún rol específico. No
significa que KANBAN lo prohíba sino que no es obligatorio, en general prevalece el criterio de que
“menos es mas”, por ende se puede tener roles similares en KANBAN pero no está prescripto por la
metodología como en KANBAN.
SCRUM prescribe una cadencia de producción de entregables fijas (cada Sprint) de duración fija, y
las tareas específicas de planificación y mejora de procesos descritas en las reuniones específicas
anteriormente, en KANBAN por el contrario no prescriben iteraciones de tiempo fijo, sino que se
puede elegir el momento para la entrega, la planificación y la mejora de procesos, de manera regular
o a demanda sin la formalidad de SCRUM.
1.3.2. Límites de trabajo en progreso
Con respecto a los límites, KANBAN limita el trabajo en progreso (WIP: Work in Progress) por estado
del flujo de trabajo, en cambio SCRUM limita el trabajo en progreso en el Sprint completo, como se
ve a continuación en los tableros de SCRUM y KANBAN respectivamente.
MBA 2010
16 de 50
ILUSTRACIÓN 6: TABLEROS SCRUM Y KANBAN CON LIMITES DE WORK IN PROGRESS
En este ejemplo, el trabajo en progreso en el tablero de SCRUM es de 4 elementos, ya que en el
mismo, se visualizan los elementos incluidos en el Sprint en curso, es una limitación implícita, ya que
la cantidad de elementos que se incluyen en cada Sprint las determina el equipo, pero tienen que
poder ser desarrolladas y terminadas durante el Sprint. Mientras que en el tablero KANBAN la
limitación del trabajo en progreso es la indicada con el número debajo de la etiqueta del estado “En
curso” convertido en una pizarra de Kanban!
De forma que en Scrum el WIP se limita por unidad de tiempo. En Kanban el WIP se limita por el
estado del flujo de trabajo. (Kniberg & Skarin, 2010)
1.3.3. Cambios
En el caso de Scrum, los cambios son rechazados en el transcurso de un Sprint, de este modo si un
nuevo elemento debiera agregarse, el Product Owner deberá agregarlo al Product Backlog y deberá
ser priorizado. Si la prioridad fuera la más alta, en este caso se incluirá en el siguiente Sprint, pero el
equipo Scrum nunca agregará el elemento agregado al Sprint en curso, debido a que ya se
comprometió a entregar los elementos que están en progreso de ser desarrollados.
En el caso de Kanban, mientras el límite de trabajo en progreso no se haya alcanzado, pueden
agregarse elementos en el estado pendiente de empezar, mientras que si el límite de trabajo en
progreso del estado se ha alcanzado, el equipo no podrá tomar este nuevo elemento hasta que no
libere capacidad para absorber este nuevo elemento, siguiendo el criterio general de “un elemento
entra cuando un elemento sale” del estado de trabajo en curso.
En Scrum, el dueño del producto no puede tocar el tablero Scrum una vez el equipo se ha
comprometido a completar un conjunto de elementos en la iteración. En Kanban tú tienes que
establecer tus propias reglas sobre quién puede cambiar qué en el tablero. Típicamente el dueño del
producto controla una columna del tipo “Pendiente”, “Listo”, “Propuesto”, “Pila de Producto” en la
parte más a la izquierda en el panel, en la que él puede hacer todos los cambios que desee.
(Kniberg & Skarin, 2010)
MBA 2010
17 de 50
1.4. Conclusión
Como conclusión se puede obtener que a pesar de algunas diferencias citadas previamente, tanto
Scrum como Kanban, son sistemas de planificación tipo “Pull”, similar al modelo de gestión de
inventario “Just-In-Time”. Particularmente en Scrum y Kanban el inventario define al trabajo
pendiente y el equipo “tira” del mismo cuando están listos para absorber más trabajo.
Scrum y Kanban se basan en modelos empíricos y de optimización continua, que se corresponden
con el principio Kaizen de Lean.
Scrum y Kanban dan más importancia a la gestión del cambio que al seguimiento de un plan.
Por otro lado, cuando se empiezan a achicar las iteraciones en Scrum, por ejemplo haciéndolas
menores de 1 semana, se puede decir que no tienen sentido las iteraciones de tiempo fijo y se
aproxima a un modelo de Kanban.
MBA 2010
18 de 50
CAPÍTULO II: CUERPO EMPÍRICO
Basado en el marco teórico explicado en los puntos anteriores, es que decidí dentro del alcance de
esta tesis, intentar demostrar que la implementación de este tipo de metodologías, podría mejorar
cualquier proceso operativo de una compañía, no solo limitarse al desarrollo de software.
Al momento de seleccionar qué proceso de la compañía en la que trabajo podría ser mejorado por
algún método como los mencionados, decidí que el área de recursos humanos era un área donde se
podría implementar, básicamente debido a que el área estaba pasando por una limitación de
recursos y una alta demanda de las otras áreas. En particular el proceso más demandado por la
compañía hacia recursos humanos era la contratación de personal.
La empresa se encuentra en un proceso de gran expansión y de mucha necesidad de contratar
gente nueva, tanto para ocupar nuevas posiciones como para reemplazar posiciones existentes.
El equipo de recursos humanos de Thomson Reuters Cono Sur había reclutado en promedio unas
170 personas en 2010, lo cual representa un promedio de unas 2 personas nuevas ingresando en la
compañía cada 2 días.
Con este nivel de demanda, al inicio de esta tesis, en diciembre de 2011, el equipo de recursos
humanos, tenía abiertas unas 70 posiciones, entre nuevas y reemplazos incluyendo todas las áreas
de la compañía.
Dada esta situación y con nuevas personas trabajando en el área, en particular 3 de los 5 empleados
dedicados al área de reclutamiento tenían menos de 3 meses de antigüedad en la compañía, se
acordó con el Gerente de Recursos Humanos realizar el experimento de tratar de implementar una
metodología ágil para poder afrontar el desafío de contratar estas 70 posiciones en forma no haga
colapsar al propio equipo.
Al momento de decidir sobre cuál de los métodos implementar, opté por implementar Kanban por
varios motivos, pero uno de los fundamentales, es la libertad que otorga Kanban, como se explicó en
la sección Scrum vs Kanban, a saber:
No es necesario tener equipos multidisciplinarios
No hay roles prescriptos como en Scrum
Kanban se adapta a cualquier realidad de trabajo del equipo, Scrum está pensado nativamente para
desarrollo de software.
No es requerido tener reuniones fijas de planificación, retrospectiva, etc. Da libertad al equipo para
hacer esto en cualquier momento.
MBA 2010
19 de 50
Estos motivos, con el agregado de que el equipo de reclutamiento no tenía experiencia previa en
este tipo de métodos me hicieron pensar que sería más fácil implementar la metodología sin tener
resistencia por parte del equipo y sería mucho más accesible su asimilación.
El trabajo de campo consiste en la implementación de Kanban en el proceso de reclutamiento del
área de recursos humanos de Thomson Reuters Cono Sur.
MBA 2010
20 de 50
CAPÍTULO III: RELEVAMIENTO INICIAL
Se realizó un relevamiento inicial del área de reclutamiento de la compañía a través de dos métodos:
Entrevistas: para entender y diagramar el proceso de reclutamiento.
Encuestas: para medir el estado actual del proceso de reclutamiento.
3.1. Diagramando el proceso
Se realizaron un conjunto de entrevistas con el personal del área de reclutamiento para entender el
proceso actual de reclutamiento encontrando los siguientes pasos:
3.1.1. Requerimiento de personal: este requerimiento es generado por el jefe del área en la cual
ingresará la persona a contratar, a través de un formulario que describe la posición
describiendo el perfil del mismo y las características tanto técnicas como actitudinales
requeridas para la posición. Este requerimiento debe ser aprobado por el Gerente del área y
por el Gerente General de la compañía3.
3.1.2. Definición de la descripción del perfil: en este paso tomando los datos incluidos en el formulario
de solicitud de personal y validando el perfil con comunicaciones con el solicitante, el
encargado del reclutamiento define las necesidades del perfil y lo detalla en planillas internas
del área de reclutamiento.
3.1.3. Carga en Taleo4: una vez entendido la solicitud del perfil a reclutar el encargado del
reclutamiento ingresa la posición a cubrir en el sistema de aprobación de posiciones
denominado Taleo.
3.1.4. Aprobación de la posición: una vez ingresada la solicitud de personal en el sistema Taleo, el
mismo envía un mail al solicitante para su aprobación formal, y luego de ser aprobada por este,
se envía otro mail al Gerente del área y al Gerente General. Ambos deben aprobar la posición
antes de iniciar el proceso de reclutamiento formal.
3.1.5. Job Posting: dada la política de desarrollo de personal que posee la compañía, existe un
subproceso denominado Job Posting en el que las posiciones a cubrir son publicadas por un
período en forma interna para determinar si existen potenciales candidatos dentro de la
3 La necesidad de aprobación por parte del Gerente General de la compañía surge por la restricción de headcount máximo que
posee la compañía actualmente. Esta restricción puede verse sujeta a modificación y no ser necesaria si el límite de
headcount se encuentra por encima de la cantidad real de empleados de la compañía.
MBA 2010
21 de 50
compañía que quieran y puedan cubrir dicha posición. Este proceso se realiza por 10 días
previo a la publicación externa de la búsqueda.
3.1.6. Publicación de búsqueda: en este paso se publica la búsqueda de personal en portales
especializados de búsqueda, o bien se utilizan consultoras externas para posiciones muy
demandadas del mercado en caso que se requiera, como por ejemplo, las posiciones de
tecnología que son altamente demandadas hoy en día, o posiciones gerenciales o directivas.
3.1.7. Preselección de CVs (Currículum Vitae): luego de publicadas las búsquedas comienza el
proceso de recepción de currículum vitae, esto se realiza o bien descargando los mismos de
los sitios de publicaciones online, donde los potenciales candidatos se postulan o bien
recibiendo los mismos a través de las consultoras externas. Una vez obtenidos los CVs se
preseleccionan en función del perfil solicitado para la posición en el formulario de requerimiento
de personal, verificando las características técnicas, estudios y experiencia previa de los
postulantes.
3.1.8. Proceso de entrevistas: este proceso se realiza luego de preseleccionar los CVs de los
candidatos, realizando un set de tres entrevistas a saber:
3.1.9. Entrevista con RRHH: se realiza una entrevista inicial, y se evalúan características actitudinales
del candidato. Si pasa esta entrevista se procede con las siguientes entrevistas.
3.1.9.1. Entrevista técnica: en esta entrevista personal con experiencia en el área requirente
que pueda evaluar el las características técnicas del candidato y se le agrega una evaluación.
3.1.9.2. Entrevista con Jefe o Gerente del área: se realiza una entrevista con el Jefe del área
solicitante o con el Gerente del área en caso que sea un reporte directo al Gerente.
3.1.9.3. Feedback entrevistas: en este paso se evalúa para un candidato particular el
feedback de todas las entrevistas realizadas y se decide si el candidato sigue en proceso para
realizarle una oferta o es descartado para la posición, en este caso se comunica al candidato
de la decisión.
3.1.10. Aprobación para avanzar: este es un punto de control adicional del proceso, en el cual se
verifican que todas las aprobaciones hayan sido realizadas para incorporar a esta posición.
Esto se realiza en este paso del proceso como doble control para verificar que no haya ninguna
posición con candidatos firmes que no hayan sido aprobadas formalmente. Esta es una
situación particular dado que muchas veces, áreas solicitan una búsqueda urgente o express,
que comienza en forma anticipada antes de realizarse el proceso de aprobación formal descrito
en el paso 3 y 4. Si se llegara a este punto sin la aprobación del paso 4, en este punto deberá
aprobarse antes de avanzar con la oferta al candidato, hasta que no se cumpla este paso, no
se avanza en la oferta al candidato, aquí pueden salir del proceso candidatos que hayan
pasado esta instancia por no tener la aprobación.
MBA 2010
22 de 50
3.1.11. Propuestas: luego del control de aprobación, se le comunica al candidato la oferta y posición
y se le envía una carta oferta al candidato seleccionado. Si el candidato no acepta la oferta el
mismo sale del proceso y se descarta al candidato.
3.1.12. Exámenes pre-ocupacionales: en este paso del proceso se envía al candidato a realizar los
exámenes pre-ocupacionales para admisión. Una vez recibidos los resultados, si están de
acuerdo a los parámetros esperados, se procede a la confirmación del ingreso formal. En este
paso pueden rechazarse un candidato.
3.1.13. Ingreso: en caso que el candidato acepte la oferta realizada se procede a ejecutar el proceso
de incorporación administrativo. En este paso se realizan varios subprocesos de ingreso a
saber:
3.1.14. Confirmación formal: el candidato debe confirmar formalmente la aceptación de la carta
oferta, firmando la misma.
3.1.15. Envío de formulario de Ingreso Online, solicitud de Alta Interna y envío de datos del
candidato al área de Administración de Personal.
3.1.16. Plan de Inducción: se arma el plan de inducción del nuevo empleado, en la cual se realizan
varias entrevistas con personal de la compañía para interiorizar al mismo de los procesos del
área en la que se desempeñará y áreas relacionadas con su posición
3.1.17. Ingreso: este es el último paso del proceso, donde el nuevo empleado ingresa en la
compañía, se le da la bienvenida, tarjeta de ingreso, puesto de trabajo, y comienza el plan de
inducción.
3.1.18. En la siguiente ilustración se describe gráficamente el proceso descrito.
Requerimiento de Personal
Definición de descripción del
perfilCarga en Taleo
Aprobación de la posición
Job PostingPublicación de la Búsqueda
Preselección de CVs
Entrevistas
Control de Aprobación
PropuestasExámen pre-
ocupacionalesConfirmación de
Ingreso
Alta interna e Ingreso Online
Plan de Inducción
Ingreso
ILUSTRACIÓN 7: PROCESO DE RECLUTAMIENTO
MBA 2010
23 de 50
3.2. Midiendo el estado actual del proceso de reclutamiento
Se realizó una encuesta inicial anónima para entender la percepción del equipo de reclutamiento
acerca del funcionamiento del proceso en sí.
A continuación se detalla el resultado de la encuesta inicial:
MBA 2010
24 de 50
Como conclusiones preliminares de los datos de la encuesta, se puede observar lo siguiente:
Existe un proceso de reclutamiento, pero solo el 25% del equipo lo conoce. A la vez solo el 50%
contestó que existen o conocen las métricas para medir la performance del proceso. Esto se
debe fundamentalmente a que parte del equipo es nuevo con un promedio de entre 2 y 3 meses
de antigüedad, pero a la vez habla acerca del tiempo que demora un integrante en conocer el
proceso completo.
Respecto de las prioridades, se evidencia que la mayor parte del equipo 75% no conoce las
prioridades de sus pares, a pesar de trabajar en el mismo proceso, lo que hace que compensar
la carga de trabajo entre los miembros del equipo sea difícil, el 50% opinó que la comunicación y
colaboración es Alta, mientras que el otro 50% contestó que es media. Esto es lógico, dado que
los miembros del equipo no conocen las prioridades del resto.
La mitad del equipo tiene la sensación de que el proceso está desordenado en parte, y la otra
mitad siente que está Desbordado. Esto se debe fundamentalmente a que el equipo está muy
demandado y como vemos no tiene visibilidad de todas las búsquedas que tiene el equipo en
conjunto como así también sus prioridades y se evidencia en las respuestas de la pregunta 7
dado que el 75% respondió que la prioridad está en lo más urgente y esto muchas veces no es
lo más importante
Con respecto a la carga de trabajo se observa que la hay un alto porcentaje del equipo que tiene
muchas búsquedas abiertas , entre 10 y 20 o más de 20, totalizando un 75% con más de 10
búsquedas a la vez, métrica que explica el desbordamiento del equipo.
Como conclusión final se puede observar en la pregunta 9 que solo el 50% del equipo percibe
que su trabajo es eficiente/efectivo, y además la mayoría describe que podría realizar mejor el
mismo si lograran enfocar sus prioridades. Además se observa que el equipo percibe un alto
MBA 2010
25 de 50
grado de desorden, llevándolos a extremos donde se vuelve a entrevistar al mismo candidato 2
veces pero por desconocimiento, no como parte del proceso.
El trabajo de campo apuntará a ordenar el proceso respetando el proceso actual, pero tratando
que al aplicar KANBAN, el equipo pueda lograr los siguientes objetivos:
Visualizar el trabajo en proceso
Priorizar las búsquedas en función de su importancia pero a la vez que el proceso soporte
búsquedas urgentes sin que se desenfoque todo el resto.
Poner límites al trabajo en progreso para no perderse en la cantidad de búsquedas abiertas,
dado que las mismas son muchas, y el proceso no puede evitar esto, pero si ordenarlas.
MBA 2010
26 de 50
CAPÍTULO IV: MEJORANDO EL PROCESO DE RECLUTAMIENTO
IMPLEMENTANDO KANBAN
Una vez relevado las condiciones del proceso actual, se procedió a la implementación de la
metodología KANBAN en el proceso de reclutamiento. El proceso consistió en diagramar el proceso
descrito en el punto 3.1
4.1. Implementación del método KANBAN en el proceso de reclutamiento
Para la implementación de KANBAN fueron necesarias definir los siguientes elementos:
Tablero de KANBAN: en el que se lleva adelante el seguimiento del proceso con cada estado
determinado, las condiciones de control de cada estado, y los límites de Work In Progress de
cada estado.
Tarjetas KANBAN: necesarias para representar tanto las solicitudes de personal como los
candidatos
Reuniones diarias: en estas reuniones sirven para hacer seguimiento y “mover” las tarjetas a
través del tablero, representando así el proceso de pull de requerimientos y candidatos hasta
el ingreso final del empleado contratado.
4.1.1. Tablero KANBAN
A continuación se ve la versión final del tablero KANBAN construido para seguir el proceso de
reclutamiento.
PRE OCUPACIONAL PEND. DE ALTA
INTERNA
CONFIRMADOS PLAN DE
INDUCCIÓN
INGRESO
TERMINADO
SOLICITUDES SELECCIÓN INGRESOSPENDIENTES CARGA DE
REQUISICIONES
JOB POSTING PUBLICACION PRESELECCIONAD
OS
ENTREVISTAS PROPUESTAS
ILUSTRACIÓN 8: TABLERO KANBAN PARA PROCESO DE RECLUTAMIENTO
MBA 2010
27 de 50
Estos estados no representan exactamente todos los pasos del proceso, sino más bien, los estados
en los que puede tanto una solicitud como un candidato pueden estar y que sirven para monitorear el
estado del mismo.
4.1.2. Tarjetas KANBAN
A continuación se definieron las tarjetas KANBAN que representan los elementos que se mueven a
través del tablero. Este proceso tiene la particularidad que posee dos tipos de tarjetas, que
representan por un lado las Solicitudes de personal, y por otro los Candidatos para cubrir dichas
solicitudes. Esto se definió de esta manera para permitir el seguimiento de los candidatos una vez
obtenidos los mismos desde la solicitud inicial. De esta manera el tablero debe dividirse en dos
secciones, la primera incluye el proceso de Solicitudes, donde se representa el proceso
administrativo de una solicitud de personal. La segunda sirve para realizar el seguimiento de los
candidatos, dado que cada solicitud puede poseer más de una posición a cubrir en el mismo perfil, y
a la vez puede haber varios candidatos a cubrir cada posición solicitada.
De esta manera se definen dos tipos de tarjetas:
4.1.2.1. Tarjeta de Solicitud
A continuación se visualiza la tarjeta de solicitudes, esta tarjeta representa una solicitud de personal
y tiene los datos necesarios para identificar cada una de las solicitudes para poder realizar el
seguimiento:
ID TALEO
F.SOLICITUD: XX/XX/XXXX
F.APROBACION: XX/XX/XXXX
GERENCIA DE SISTEMAS
DESARROLLADOR .NET
CANTIDAD: 3
JOB POSTING
ILUSTRACIÓN 9: TARJETA KANBAN SOLICITUDES
Cada vez que se crea una solicitud de requerimiento de personal se completa una tarjeta como esta
que ingresa en la columna de solicitudes del tablero KANBAN.
Esta tarjeta posee los siguientes datos:
MBA 2010
28 de 50
ID Taleo: identifica el requerimiento en el sistema de aprobaciones de solicitudes de personal.
F. Solicitud: identifica la fecha en la que se creó la solicitud.
F. Aprobación: indica la fecha en que la solicitud fue aprobada formalmente en el sistema Taleo.
Descripción de la solicitud: identifica la gerencia que realizó la solicitud, el nombre de la
posición requerida y la cantidad de posiciones a cubrir con las mismas características. En el
ejemplo ilustrado se ven estos datos: Gerencia de Sistemas, Desarrollador .NET,
Cantidad: 3.
Job Posting: indica la cantidad de días con círculos rojos que dicha solicitud estuvo publicada
en el proceso de Job Posting. Estos círculos se completan cuando la tarjeta ingresa en la
columna Job Posting del tablero. Como la cantidad máxima que una solicitud puede estar en
el proceso de Job Posting, una tarjeta que tenga 10 círculos saldrá de la columna Job
Posting para pasar a la columna Publicación.
FLAGS
DEMORADO
IMPORTANTE
ILUSTRACIÓN 10: FLAGS DE SOLICITUDES DE REQUERIMIENTOS
La ilustración anterior muestra los flags que pueden agregarse a una solicitud de requerimiento
de personal. Estas banderas indican visualmente si la solicitud está demorada o es más
importante que el resto y sirven para que el equipo al momento de realizar las reuniones diarias
pueda visualmente identificar estas solicitudes y darles una prioridad sobre el resto de las
solicitudes en el mismo estado.
4.1.2.2. Tarjeta de Candidato
A continuación se visualiza una tarjeta de candidato. Son tarjetas de menor tamaño que las de
solicitudes dado que en general se tiene más de un candidato para la misma posición. Esta tarjeta
nace en la etapa Preselección del subproceso Selección del tablero e indica los datos de un
candidato que puede ser seleccionado relativo a la solicitud en cuestión.
MBA 2010
29 de 50
ID TALEO: 001
DESARROLLADOR .NET
MIGUEL PEREZ
F.INGRESO:
ILUSTRACIÓN 11: TARJETA DE CANDIDATO
Esta tarjeta identifica al candidato y puede haber de 1 a n candidatos por cada tarjeta de solicitud.
Nacen este tipo de tarjetas en el tablero a partir del subproceso de selección.
Los datos que contiene la misma permiten al equipo identificar la situación del candidato:
ID. Taleo: al igual que en las tarjetas de solicitudes el ID de Taleo identifica la solicitud de
esta posición en el sistema Taleo.
Nombre de la posición: identifica el nombre de la posición a la que aplica el candidato en
cuestión. En la ilustración de ejemplo: Desarrollador .NET
Nombre del candidato: identifica el nombre del candidato para una fácil identificación del
mismo. En la ilustración de ejemplo: Miguel Perez
F. Ingreso: identifica la fecha en la que el candidato ingresará a la compañía. Este dato se
completa una vez que el candidato inicia el subproceso Ingresos.
Icono: el icono identifica a la persona del equipo que sigue el proceso para ese candidato.
Cada participante del proceso tiene un ícono de color y forma distinto lo que permite una fácil
visualización de los candidatos de cada miembro del equipo en el tablero.
Las tarjetas se mueven a través del tablero de la siguiente manera:
Subproceso Solicitudes: ingresa una solicitud de requerimiento y se mueve por las etapas del
proceso Solicitudes pasando por los estados Pendientes, Carga de Requisicione, Job
Posting y Publicación. Se utilizan las tarjetas de Solicitudes únicamente.
Subproceso Selección: aquí nacen las tarjetas de candidatos que pasan por los siguientes
estados del subproceso: Preseleccionados, Entrevistas, Propuestas, Pre-Ocupacional.
Subproceso Ingresos: una vez seleccionados el o los candidatos para una posición solicitada
se adjunta la tarjeta de Solicitud y la del/los candidatos seleccionados y se pegan juntas y las
mismas pasan por los siguientes estados del subproceso: Pendiente de Alta Interna,
Confirmados, Plan de Inducción, Ingreso terminado.
Con esta definición un tablero se vería de la siguiente forma:
MBA 2010
30 de 50
PRE OCUPACIONAL PEND. DE ALTA
INTERNA
CONFIRMADOS PLAN DE
INDUCCIÓN
INGRESO
TERMINADO
SOLICITUDES SELECCIÓN INGRESOSPENDIENTES CARGA DE
REQUISICIONES
JOB POSTING PUBLICACION PRESELECCIONAD
OS
ENTREVISTAS PROPUESTAS
ILUSTRACIÓN 12: TABLERO KANBAN CON TARJETAS EN LAS DISTINTAS ETAPAS
4.1.3. Reuniones de seguimiento
Cabe aclarar que la creación del tablero se logró luego de varias revisiones de modelos con los
representantes del equipo de reclutamiento. Inicialmente el tablero se armó sin límites de trabajo en
progreso, dado que esto condicionaba a los integrantes del equipo.
Luego una vez lograda una mínima adaptación al uso del tablero, las tarjetas y las reuniones (unas 2
semanas) se agregaron los límites de trabajo en progreso a cada estado del tablero. De esta manera
se logró la implementación completa de KANBAN.
Las reuniones de seguimientos o “daily meetings” son reuniones sonde el equipo de trabajo se reúne
frente al tablero y duran alrededor de media hora. Se hacen de pie, para evitar que la duración de la
misma exceda la media hora y se ponga foco únicamente en el seguimiento del tablero.
En la misma los participantes revisan sus tarjetas y pasan de columna las que hayan cumplido con
las condiciones de cambio de etapa. A su vez se revisan las solicitudes que hayan cambiado su
prioridad o estén demoradas y se les pone el flag correspondiente.
Los límites de trabajo en progreso de cada etapa permiten a su vez poner foco en las etapas donde
haya tarjetas acumuladas y ayudan a los integrantes a poner foco en los mismos para desagotar los
cuellos de botella, debido a que no pueden ingresar tarjetas en las columnas donde se haya
alcanzado el límite hasta que no salga otra tarjeta que esté en dicha columna.
Tarjetas de Solicitudes Tarjetas de Candidatos Tarjetas de Solicitudes combinadas con
Candidatos
Sentido de circulación de las
tarjetas
MBA 2010
31 de 50
De esta manera el equipo focaliza su trabajo diario en las columnas donde se haya alcanzado el
límite y pone el esfuerzo en “desagotar” el estado que se convirtió en cuello de botella (cuando
alcanza el límite) y hace fluir las tarjetas de una punta a la otra.
4.1.4. Pasos y condiciones para el cambio de etapa de una tarjeta
Para facilitar la visualización del proceso de reclutamiento y las condiciones que se deben cumplir
para que una tarjeta cambie de etapa, se definieron las siguientes condiciones por etapa:
Subproceso Columna del tablero Kanban
Pasos y condiciones
Solicitudes Pendientes Carga en Taleo
Incluir descripción del perfil
Job Posting Máximo: 10 días en esta etapa
Enviar mail interno con perfil & política de Job Posting
Publicar en la intranet
Publicación Tip: descargar todos los CVs recibidos de los candidatos antes de finalizar la publicación
Selección Preseleccionados Sin condiciones
Entrevistas Coordinar entrevistas
Unificar feedback
Confirmar aprobación para avanzar
Propuestas Preparar y enviar carta oferta al candidato
Pre-Ocupacional Esperar resultados
Confirmar Ingreso/No ingreso al candidato
Enviar planilla de ingreso online al postulante
Confirmar fecha de ingreso con el candidato
Ingresos Confirmados Enviar alta interna
Ingreso online a Administración de Personal
Validar lugar físico y solicitar elementos (Computadora, Celular, etc.)
Plan de Inducción Preparar plan de inducción
Ingreso Entregar materiales y hacer inducción
Estas condiciones se escribieron al pie de cada columna del tablero de manera tal que al realizar las
reuniones diarias de seguimiento se tengan a la vista y ayuden al equipo a recordar las mismas.
MBA 2010
32 de 50
A su vez se agregaron en cada etapa del proceso (columnas del tablero) los límites de trabajo en
progreso que indican la cantidad de tarjetas (o solicitudes y candidatos) máxima que puede haber en
cada etapa del proceso.
MBA 2010
33 de 50
CAPÍTULO V: MIDIENDO EL RESULTADO DE LA MEJORA
Para medir el resultado de la implementación del método KANBAN en el proceso de reclutamiento se
realizaron varias acciones:
Segunda encuesta con los empleados del equipo de reclutamiento, esta encuesta fue similar a la
encuesta inicial pero con algunas preguntas adicionales a las realizadas en la primera, dado el
conocimiento del proceso KANBAN.
Tablero de bajas de proceso: en este tablero se clasificaron los candidatos que salieron del proceso
por distintos motivos de manera de poder medir las razones por las que un candidato salía del
proceso antes de finalizar el mismo.
Sesiones de retrospectiva: se realizó una sesión de retrospectiva inicial en la cual se mide lo que
salió bien y lo que deberá mejorarse en el proceso, utilizando el método “Mad, Sad, Glad” (Derby &
Larsen, 2006)
5.1 Segunda encuesta de proceso de reclutamiento
Se realizó una encuesta anónima para entender la percepción del equipo de reclutamiento acerca del funcionamiento del proceso, luego de la implementación de Kanban.
A continuación se detalla el resultado de la segunda encuesta:
MBA 2010
34 de 50
MBA 2010
35 de 50
Como conclusiones preliminares de los datos de la encuesta, se puede observar lo siguiente:
Mejoró el índice de conocimiento del proceso de reclutamiento de un 50% a un 100%, ya que el
equipo participó en todo el proceso de implementación, lo que niveló el conocimiento del
proceso.
Respecto a las mejoras observadas se evidenciaron mejoras en varios aspectos, siendo los más
significativos señalados por los encuestados, el Orden en el proceso y El seteo de
prioridades. En segunda medida se observa que además el equipo conoce Los límites del
trabajo en proceso ya que actualmente se mide en el tablero.
Aumentó la tasa de conocimiento de las búsquedas de cada uno por el resto del equipo, de un
25% a un 33%.
Aumentó la tasa que indica la colaboración y comunicación del equipo de un 50% en valor Alto a
un 66%. Esto se observa debido a la obligatoriedad de la reunión diaria en la que al menos todos
pueden ver la totalidad de las búsquedas en proceso.
Con respecto a la sensación del equipo respecto del proceso de reclutamiento la mejora es
significativa. Desapareció la sensación de desbordamiento, dado que la opción Desbordado
arrojó un 0% y aumentó la sensación de orden dado que un 33% opinó que el proceso está Muy
ordenado y previsible y el 66% opinó que algunas cosas están ordenadas y otras les falta un
poco de orden, pero este último índice aumentó un 16% respecto al valor de la encuesta inicial.
A su vez las prioridades del equipo se movieron hacia lo urgente y lo prioritario en un 75% y un
25% respectivamente, desapareciendo el ítem Atrasado, esto se debe a que el equipo ordenó el
flujo de trabajo y minimizó los cuellos de botella, por ende eliminó los atrasos, a pesar que
existen búsquedas prioritarias y urgentes.
Con respecto a la carga de trabajo se observa que a pesar que no se redujo la cantidad de
búsquedas se ha reducido el valor correspondiente a Más de 20 de un 50% a un 33% lo cual
indica una mejora paulatina en la carga de trabajo.
MBA 2010
36 de 50
Además se puede observar en la pregunta 9 que solo el porcentaje de personas con sensación
de que el proceso es eficiente aumentó de un 50% a un 67%.
Por último se observa que a pesar que al equipo le costó un esfuerzo adicional cambiar su forma
de trabajo anterior por esta, el 100% recomendaría implementar el método Kanban en otro
proceso de la compañía.
5.2 Tablero de bajas del proceso
A medida que se ejecutaba el proceso de reclutamiento, el equipo se dio cuenta que muchos
candidatos salían del proceso antes de que el mismo finalice. Para reflejar esto en el tablero de
Kanban, debían eliminar las tarjetas del mismo, pero perdían el rastro de por qué un candidato salía
del proceso. Para lograr obtener una métrica que permita luego medir los motivos por los cuales un
candidato salía del proceso sin ser contratado y poder mejorar así el proceso de reclutamiento se
decidió crear este tablero en el cual se pegarían las tarjetas que no concluían el proceso dividiendo el
mismo en tres categorías principales.
De esta manera el equipo pudo categorizar los motivos principales por los cuales un candidato sale
del proceso de reclutamiento sin ser seleccionado.
A continuación se muestra una foto del tablero con las tarjetas de los candidatos que abandonaron el
proceso clasificadas en las tres categorías:
ILUSTRACIÓN 13: TABLERO DE BAJAS CON TARJETAS DE CANDIDATOS
5.3 Sesiones de retrospectiva
MBA 2010
37 de 50
Como parte fundamental del proceso se realizaron reuniones de retrospectiva, pero adicionalmente
estas reuniones sirvieron para poder medir la mejora en el proceso y además sentar bases para
mejorarlo aun más, siguiendo la filosofía de Lean de mejora continua.
Para las reuniones de retrospectivas se eligió el método “Mad, Sad, Glad”, este método establece las
siguientes pautas para la retrospectiva:
Realizar una reunión de no más de 1 hora de duración con todos los miembros del equipo.
En un pizarrón colocar tres categorías con íconos gráficos como se muestran a continuación
de hechos que cada integrante catalogará en función de cada categoría a saber:
Mad: identifica los hechos relevantes que salieron mal y deberán corregirse
inmediatamente.
Sad: identifica los hechos que no salieron del todo bien pero no son críticos para
la metodología.
Glad: identifica los hechos que salieron bien y deberían seguir así.
ILUSTRACIÓN 14: EJEMPLOS DE TABLEROS MAD, GLAD, SAD
Cada miembro del equipo escribe en un post-it o papel cada hecho que le pareció relevante y
lo coloca en una de las categorías según su entender.
Luego se procede a agrupar los hechos iguales o que representen lo mismo.
Habiendo agrupado las ideas, a cada miembro del equipo se le dio 4 puntos que podían
usarse para votar los temas que a criterio de cada uno eran más importantes, pero solo
podrían utilizar esos 4 puntos y no más.
MBA 2010
38 de 50
A partir de la votación se obtuvo una lista priorizada de temas a mejorar y se analizó en
conjunto las posibles acciones.
Se eligieron en particular en esta reunión dos temas prioritarios y se asignó un responsable
para cada uno de ellos, el cual se encargará no necesariamente de realizar la mejora, sino
de ser responsable ante el equipo de que la misma se realice.
Los hechos elegidos para mejorar son los siguientes:
Daily meetings: en las reuniones diarias de seguimiento, no todos los miembros del equipo
participaron y no se respetó el horario ni la duración de la reunión.
o Mejora sugerida: que el equipo se compromete a asistir diariamente y a respetar el
horario y duración de la reunión para evitar que la misma compita con otras tareas
importantes como las entrevistas a candidatos.
Métricas: una de los hechos que se destacó por todos los miembros del equipo es que no se
han logrado construir métricas más concretas sobre el proceso de reclutamiento, más allá del
tablero de bajas del proceso:
o Mejora propuesta: identificar las métricas relevantes y construir un informe mensual
con dichas métricas a partir de las mediciones del proceso.
MBA 2010
39 de 50
CONCLUSIONES
Se puede asegurar que el método Kanban aplica perfectamente a cualquier proceso estructurado de
trabajo de una compañía, y que la teoría de Lean Management puede mejorarlos, basado en los
resultados de la implementación empírica del mismo.
Luego de la implementación del tablero, se entreno al equipo de RRHH para su uso y seguimiento.
Los resultados fueron muy alentadores ya que el equipo adquirió una práctica que les permitió entre
otras codas:
Predecir la duración de una búsqueda
Determinar la cantidad de búsquedas abierta con su prioridad y estado, como así también la
cantidad de candidatos potenciales en un solo vistazo.
Ordenar el proceso en función de los pasos del mismo y poner foco en los procesos que
generan cuellos de botellas para no estancar el proceso entero.
Determinar límites de trabajo en proceso durante cada etapa del proceso.
Realizar retrospectivas que permitan realizar una mejora continua del proceso.
De esta manera, el equipo de RRHH adquirió una metodología de procesos muy simple y que les
permite ir mejorando el proceso constantemente.
Esta tesis demuestra que el proceso de KANBAN en particular puede aplicarse a cualquier proceso
sin importar la complejidad.
Actualmente luego de la implementación en RRHH, hay varias implementaciones en proceso
y finalizadas de la metodología KANBAN a otros procesos de la compañía, a saber:
Seguimiento del plan anual de lanzamientos de productos online.
Proceso de testing por parte del área de contenidos del producto online y sus contenidos.
Prioridades de la Dirección de Tecnología.
Como hecho relevante también es importante mencionar que esta experiencia ha sido elegida para
ser presentada en el evento lean kanban southern europe 2012 (http://lkse12.leanssc.org/) liderada
por david anderson en españa, por leopoldo simini, quien lideró la implementación en thomson
reuters bajo el título más allá de it: implementando kanban en el proceso de reclutamiento y selección
de personal (http://lkse12.leanssc.org/sessions.htm).
MBA 2010
40 de 50
GLOSARIO
CMMI: Capability Maturity Model Integration, metodología de desarrollo de software
estandarizada desarrollada por el Software Engineering Institute. “Es un modelo de madurez de
mejora de los procesos para el desarrollo de productos y de servicios. Consiste en las mejores
prácticas que tratan las actividades de desarrollo y de mantenimiento que cubren el ciclo de vida
del producto, desde la concepción a la entrega y el mantenimiento” (Chrissis, Konrad, & Shrum,
2009).
HEADCOUNT: Cantidad de empleados permanentes que posee una compañía. No incluye
contratos temporales ni personal contratado por proyectos.
TALEO: sistema utilizado en Thomson Reuters para el seguimiento y autorización de posiciones
de empleados. El sistema posee un modelo de circuito de aprobaciones jerárquico que permite
que la cadena de mandos apruebe las posiciones solicitadas a RRHH.
MAD, SAD, GLAD: método de retrospectivas utilizado para recopilar información de cómo se
ejecutó el método.
BACKLOG: lista detallada de requerimientos priorizada según la importancia de los mismos para
el negocio en función de algún criterio.
MBA 2010
41 de 50
BIBLIOGRAFÍA
Anderson, D. (2010). KANBAN, Cambio evolutivo exitoso para su negocio de tecnología. (M. K.
Maeda, Trans.) Estados Unidos de América: Blue Hole Press.
Chrissis, M. B., Konrad, M., & Shrum, S. (2009). CMMI® Guía para la integración de procesos y la
mejora de productos. En M. B. Chrissis, M. Konrad, & S. Shrum, CMMI® Guía para la integración de
procesos y la mejora de productos (C. d. Madrid, Trad.). Pearson Educación S.A.
Derby, E., & Larsen, D. (2006). Agile Retrospectives, Making good teams great. United States of
America: Pragmatic Bookshelf.
Kniberg, H., & Skarin, M. (2010). Kanban y Scrum – obteniendo lo mejor de ambos. Estados Unidos
de América: C4Media, editores de InfoQ.com.
Schwaber, K., & Sutherland, J. (1991-2011). The Scrum Guide. scrum.org.
MBA 2010
42 de 50
ANEXOS
I. Encuesta Inicial de relevamiento
La encuesta inicial de relevamiento del proceso se realizó con la herramienta SurveyMonkey5.La
encuesta se envió a los cinco integrantes del equipo de reclutamiento y fue respondida por 4 de ellos
(80% de los encuestados)
A continuación se muestra la encuesta como fue enviada.
Encuesta inicial del proceso de reclutamiento RRHH
*1. ¿Dentro del proceso de reclutamiento, como se mide la performance del equipo de RRHH?
Texto libre
*2. ¿Existe algún indicador de performance del proceso de reclutamiento?
Si
No
Describir los indicadores
*3. ¿Existe un proceso formalizado de reclutamiento que sigan todos los miembros del equipo? Si la
respuesta es sí, describir el proceso.
Si
No
Describir el proceso
4. ¿Qué tan al tanto estás acerca de las búsquedas y prioridades de sus pares?
5 SurveyMonkey: herramienta web que permite crear encuestas, enviar un link por correo electrónico a los encuestados, y
luego recopilar resultados. Permite crear distintos tipos de preguntas, abiertas, con opciones múltiples, solo una opción, etc.
MBA 2010
43 de 50
Totalmente al tanto
Tengo conocimiento de algunas búsquedas pero no conozco el detalle
No tengo idea
MBA 2010
44 de 50
5. ¿Cómo es la colaboración y comunicación entre Uds., y la comunicación referida al proceso de
reclutamiento?
Alta
Media
Baja
Nula
Describir que problemas de colaboración o comunicación existen
6. ¿Cómo se sienten con el proceso de reclutamiento? (anterior a la implementación del tablero)
Muy ordenado y previsible
Algunas cosas ordenadas, otras desordenadas
Desbordado
Otro (especifique)
7. ¿Donde enfocas tu prioridad en el día a día?
En lo más urgente
En lo más importante
En lo atrasado
*8. ¿Cuántas búsquedas manejas actualmente en paralelo?
MBA 2010
45 de 50
Entre 1 y 10
Entre 10 y 20
Más de 20
*9. ¿Sentís que tu trabajo es eficiente/efectivo? Es decir logras los resultados que se esperan de vos
en el equipo
Si
No
En caso de No, describir por qué
II. Encuesta final de relevamiento del proceso de reclutamiento
III. Encuesta final de relevamiento
La encuesta final de relevamiento del proceso se realizó con la herramienta SurveyMonkey6.La
encuesta se envió a los cinco integrantes del equipo de reclutamiento y fue respondida por 3 de ellos
(60% de los encuestados, el porcentaje menor de respuestas se debe a que se utilizó adicionalmente
la reunión de retrospectiva para detectar mejoras y estado actual del proceso).
A continuación se muestra la encuesta como fue enviada.
Encuesta final del proceso de reclutamiento RRHH
*1. ¿A partir de la implementación del método KANBAN en el proceso de reclutamiento, como se
mide la performance del equipo de RRHH?
6 SurveyMonkey: herramienta web que permite crear encuestas, enviar un link por correo electrónico a los encuestados, y
luego recopilar resultados. Permite crear distintos tipos de preguntas, abiertas, con opciones múltiples, solo una opción, etc.
MBA 2010
46 de 50
*2. ¿Indique cuales de estas cosas mejoraron luego de la implementación de Kanban?
¿Existe algún indicador de performance del proceso de reclutamiento? Orden en el proceso
Seteo de prioridades
Foco en lo urgente
Foco en lo importante
Conocimiento de los límites del equipo
Ninguna de las anteriores
Indicar qué otras cosas se ganaron con el nuevo método que no estén listadas
*3. ¿A partir de la implementación del método KANBAN, entiende Ud. que un proceso formalizado de
reclutamiento que sigan todos los miembros del equipo?
Si
No
Justifique su respuesta
MBA 2010
47 de 50
4. ¿A partir de la implementación del tablero, indique que tan al tanto estás acerca de las búsquedas
y prioridades de sus pares?
Totalmente al tanto
Tengo conocimiento de algunas búsquedas pero no conozco el detalle
No tengo idea
5. ¿Cómo es la colaboración y comunicación entre Uds., y la comunicación referida al proceso de
reclutamiento a partir de la implementación del tablero KANBAN en el proceso de reclutamiento?
Alta
Media
Baja
Nula
Justifique su respuesta
MBA 2010
48 de 50
IV. Fotos de evolución del Tablero Kanban del proceso de reclutamiento
A continuación se muestran algunas fotos de la implementación de Kanban en el proceso de
reclutamiento de Thomson Reuters.
ILUSTRACIÓN 15: TABLERO KANBAN DE PROCESO DE RECLUTAMIENTO CON LIMITES DE
TRABAJO EN PROGRESO Y REFERENCIAS DE TARJETAS
ILUSTRACIÓN 16: REUNIONES DIARIAS DE SEGUIMIENTO
MBA 2010
49 de 50
ILUSTRACIÓN 17: DETALLE DE ESTADOS DEL TABLERO KANBAN CON LIMITES DE TRABAJO
EN PROGRESO
ILUSTRACIÓN 18: DETALLE DE TARJETAS EN EL TABLERO KANBAN
ILUSTRACIÓN 19: DETALLE DE CONDICIONES PARA CAMBIO DE ETAPA
![Transformación Digital en Reclutamiento y en Recursos Humanos [Infografía]](https://img.dokumen.tips/doc/110x75/58e841061a28ab4b158b513b/transformacion-digital-en-reclutamiento-y-en-recursos-humanos-infografia.jpg)
