Cómo optimizar su Kanban

John Cutler publicó un blog de Hackernoon titulado "Odio Kanban ..." con una foto de este tablero. Si no quieres odiar tu Kanban, puedes optimizarlo usando la estrategia de abajo.

Visión general

Para el trabajo basado en interrupciones, como un servicio de asistencia o un centro de llamadas, se suele utilizar un sistema de tickets. Se trata esencialmente de un sistema Kanban en el que (1) el trabajo debe hacerse visible, (2) el trabajo en curso debe reducirse al mínimo y (3) el tiempo de ciclo debe medirse.

El problema de Kanban es que es lento a menos que se apliquen ciertas optimizaciones. En la mayoría de los servicios de asistencia se mide el número de tickets completados por semana. Se trata de una medida de velocidad que equivale a la duración media del ciclo. ¿Cómo se hace el doble de entradas en la mitad de tiempo? Para ello es necesario reducir el tiempo de ciclo mediante 75%.

Contexto

En 2006, Open View Venture Partners decidió utilizar Scrum como motor principal de creación de valor. Scrum se implantó en toda la organización de la empresa de capital riesgo (Sutherland y Altman 2009) al tiempo que se despliega Scrum en las empresas de la cartera. Cuatro grandes rondas de financiación están en marcha para apoyar a más de tres docenas de empresas en cartera activas en todo momento.

El objetivo es convertir $1B en $10B utilizando Scrum. Para ello necesitamos innovar rápidamente y luego ampliar la innovación. Scrum es ante todo innovación (Rigby, Sutherland et al. 2016)A continuación, el tiempo de comercialización y, por último, el impulso de las ventas que amplían la cuota de mercado y aumentan la valoración, lo que conduce a una OPI o a la venta de la empresa de riesgo.

Intronis, una empresa de almacenamiento en la nube y copias de seguridad que vendimos a Barracuda en 2016, tenía un problema cuando invertimos inicialmente en la empresa. Recibían el doble de llamadas de asistencia de las que podían atender, los clientes estaban muy molestos y los ingresos se veían afectados. Como asesor sénior y Agile Coach de Open View, me pidieron que fuera a la empresa y solucionara esto.

El centro de llamadas utilizaba un sistema de tickets típico para gestionar las llamadas. Gracias a las optimizaciones aquí descritas, el tiempo de ciclo se redujo en 75% en seis meses. El mismo personal podía atender el doble de llamadas de las que recibía. Tenían tanto tiempo libre que empezaron a llamar a los clientes de forma proactiva para preguntarles en qué podían ayudarles. He aquí los puntos críticos de optimización de su sistema Kanban.

Optimización 1: El retraso

Me reuní con el Director de Operaciones de Intronis, el Director de Soporte y algunos empleados del centro de llamadas y les pregunté si estaban gestionando las incidencias en el orden correcto para maximizar los ingresos de la empresa. Dijeron que estaban gestionando las incidencias según el orden de llegada y estuvieron de acuerdo en que eso no optimizaba los ingresos. 20% de los clientes aportan 80% de los ingresos y necesitan un acuerdo de servicio de mayor nivel.

Para resolver este problema necesitamos un Product Owner para el sistema de venta de entradas. Rápidamente acordamos que el Director de Operaciones era el dueño de esta operación y debía establecer las prioridades.

El segundo aspecto crítico de la gestión de la cartera de pedidos es la Estado listo del backlog. ¿Los elementos pendientes son claros, pequeños e inmediatamente ejecutables? Sabemos que un backlog listo puede duplicar la producción (Jakobsen y Sutherland). En American Healthways cuando Forbes la clasificó como una de las pequeñas empresas de más rápido crecimiento el CIO pidió a un coach Scrum que mejorara el rendimiento del help desk. El entrenador examinó el backlog y descubrió que el equipo del help desk perdía mucho tiempo intentando obtener del usuario final la información necesaria para solucionar el problema. Estableció un criterio de "listo" para un elemento del backlog e impidió que nadie trabajara en un elemento que no estuviera listo. Cuando empezó, el servicio de asistencia atendía 1.000 solicitudes a la semana. Dos semanas más tarde, atendían 2.000 solicitudes a la semana.

Un Product Owner para el Kanban es esencial para reducir el tiempo de ciclo a la mitad.

Optimización 2: El equipo

Para volver a reducir el tiempo de ciclo a la mitad, el grupo de apoyo tiene que trabajar en equipo para mejorar continuamente su proceso. Para ello, necesitan un jefe de equipo facilitador, un reunión diaria, a retrospectiva semanaly un compromiso por parte del Product Owner de priorizar 10% de su trabajo pendiente como elementos de mejora del proceso.

Necesitábamos más que duplicar la eficiencia de los procesos del equipo para llevar el rendimiento al siguiente nivel. La eficiencia del proceso es el tiempo de trabajo real dividido por el tiempo de calendario. Para calcular la eficiencia del proceso, es necesario trazar el flujo de valor del proceso. Cuánto tarda cada paso, dónde se producen retrasos y cuánto trabajo de valor añadido se realiza realmente.

Pregunté al personal qué pasaba cuando llamaba un cliente. Me dijeron que la mayoría de las veces necesitaban la ayuda del jefe de asistencia para responder a las preguntas de los clientes. Por término medio, tardaban dos horas en obtener ayuda del gestor de asistencia para poder volver a llamar y mantener una segunda conversación con el cliente. Por lo tanto, para 10 minutos de trabajo real de comunicación con el cliente, se necesitaron dos horas y diez minutos de tiempo de reloj. La eficiencia del proceso de esta parte del trabajo fue de 10/130, menos de 10%. Sabía que sería aún peor cuando analizáramos el resto del proceso entre el momento de la primera llamada y la finalización del ticket a satisfacción del cliente.

Sabemos que si la eficiencia del proceso supera los 50% la producción se duplicará (Jakobsen y Sutherland). Conseguí que el Director de Soporte se convirtiera en el líder facilitador del equipo con menos de 10 minutos de tiempo de respuesta para las preguntas de su equipo. Entonces empezamos a profundizar en todo el flujo de valor de los tickets.

Optimización 3: La empresa

A medida que profundizábamos en los problemas del centro de llamadas, le dije al director general que necesitábamos una sesión de tarde para analizar las causas de los problemas más graves del rendimiento del centro de llamadas. Había demasiados errores generados por los desarrolladores. Y el personal del centro de llamadas no entendía el sistema lo suficientemente bien como para resolver los problemas de los clientes sin mantener extensas conversaciones con múltiples expertos tanto de desarrollo como de soporte.

El director general, el director de operaciones, el equipo de desarrollo y el personal del centro de llamadas se reunieron durante una tarde. Hicimos un mapa de todo el proceso de asistencia y analizamos la raíz de los problemas más difíciles. Decidimos que la principal prioridad kaizen (mejora del proceso) era una reunión semanal entre el personal del centro de llamadas y el de desarrollo para formar y actualizar el trabajo pendiente de desarrollo con el fin de reducir los defectos que generaban el mayor número de llamadas de clientes.

En seis meses, el centro de llamadas consiguió un aumento del rendimiento de 400%.

Conclusión

Su Kanban será lento a menos que Scrum el Kanban. Necesita un Product Owner, un refinamiento de la cartera de productos, una planificación semanal, un Scrum Master, un equipo, un Scrum diario, una retrospectiva semanal y el compromiso de toda la empresa de asignar 10% del tiempo de soporte a la mejora del proceso. Así podrá gestionar el doble de incidencias en la mitad de tiempo.