Clases de Servicio, ¿Qué se esconde en ellas?

Cost of Delay¿Cuántas veces has visto un sistema Kanban funcionando? ¿Has sentido el vértigo que produce ver como fluye el trabajo? ¿Has contemplado como un equipo altamente enfocado consigue reducir su tiempo de entrega? Aquí ya hemos hablado de Kanban en alguna ocasión. hoy vamos profundizar y hablar de las Clases de Servicio. Uno de los conceptos básicos cuando se empieza a profundizar en la implantación de un sistema Kanban.

Clases de servicio.

En su libro, David J. Anderson habla de las Clases de Servicio. Enumera cuatro que suelen ser las más habituales. Por desgracia se suele pasar por alto la verdadera diferencia entre ellas, el Cost of Delay (CoD). Podemos pensar en este coste como lo que perdemos, o dejamos de ganar, si dicha tarea no ha sido realizada. Para aclararlo mejor vamos a repasar cada una de las clases de servicio con algún ejemplo.

Standard    

En esta clase el CoD es lineal. Es decir, cuanto más tardemos en realizar esta tarea más coste acumula. Un ejemplo claro sería añadir una versión premium a un servicio. Cuanto más tardemos en añadirla más tardaremos en empezar a cobrar esa tarifa.

CoD Clase Standard
CoD Clase Standard

Expedite

En este caso el CoD crece pero de forma no lineal sino exponencial. Por ejemplo añadir una nueva funcionalidad que la competencia ya ha añadido. Esto puede suponer que perdamos potenciales clientes. También alguno de nuestros clientes se irán a la competencia. Con el paso del tiempo esta situación empeorará. La única solución es añadir la nueva funcionalidad lo antes posible.

CoD Clase Expedite
CoD Clase Expedite

Fixed Time

Aquí el CoD no existe hasta una determinada fecha. El típico ejemplo es una nueva regulación gubernamental. Implantarla antes de tiempo no supone ninguna ventaja. En cambio, si llegada la fecha no está implementada la tarea se convertirá en Standard o incluso Expedite.

CoD Clase Fixed Time
CoD Clase Fixed Time

Intangible

Para este tipo de tareas no existe CoD en el medio plazo. Son tareas que de no realizarse previsiblemente incurrirán en un coste futuro. Por ejemplo, la actualización a una nueva versión de la base de datos. No actualizarse no tiene un coste inmediato, pero de no hacerse puede llegar un momento en que no exista soporte o alguna nueva característica no se pueda implementar. En ese momento la tarea se podría convertir en Standard o en el peor de los casos en Expedite.

 

CoD Clase Intangible
CoD Clase Intangible

 

¿Para qué nos sirve el CoD?

Esta información debe guiarnos a la hora de actuar con cada una de las clases de servicio. 

Empecemos por el caso de las tareas Expedite. Cuando una de estas tareas entra en el sistema el equipo pone todo su foco en terminarla lo antes posible.Esto produce que el resto de las tareas se paren y por consiguiente se retrasen. Esto es normal, ya que el CoD asociado a esta tarea es exponencial. Pero, ¿Qué pasaría si una tarea cuyo CoD  no es exponencial se clasifica como Expedite?. Si es así, pudiera darse el caso de estar ralentizando alguna otra tarea cuyo coste sea mayor. Esto incumple la premisa de tener el foco en el cliente, ya que la motivación de acelerar esa tarea no es darle mayor valor al cliente. En este caso deberíamos preguntarnos cuál es la motivación real de clasificar esa tarea como Expedite.

Pasemos a la Fixed Time. Lo ideal en estas tareas sería terminarlas en el mismo día que se cumple la fecha de fin. Para poder conseguir esto suele ser necesario una pequeña estimación por parte del equipo. Esto permite introducir la tarea en el sistema en el último momento responsable. Pero, ¿No sería mejor tenerla antes para asegurarnos?. En este caso otras tareas, por ejemplo Standard, habrán entrado más tarde en el sistema y por tanto habrán ido acumulando CoD.

Con las tareas de tipo Intangible nos interesa tenerlas presentes. De no ser así, con el paso del tiempo estas tareas cambiarán a alguna de las otras clases de servicio, pudiendo, en el peor de los casos, convertirse en Expedite.

Conclusión

Como podéis ver entender correctamente lo que hay detrás de cada clase de servicio nos puede ayudar a gestionar mejor nuestro sistema. Este conocimiento nos permite crear políticas concretas por cada clase de servicio. Por ejemplo podríamos crear un límite WIP por cada una de las clases de servicio. 

Por último podríamos usar el concepto de CoD  para mantener conversaciones a la hora de introducir trabajo en nuestro sistema.

Si quieres practicar estos conceptos puedes usar algunos de los juegos que ilustran el funcionamiento de Kanban, como puede ser Featureban

Compártelo