Proceso de TrabajoA grandes rasgos mi empresa hace dos tipos de proyectos:Internos: desarrollo de productos propios (sistemas WMS).Externos: adaptaciones y personalizaciones de nuestros sistemas para clientes.

Cuando se hace un proyecto a cliente se adapta nuestro sistema WMS a las necesidades del cliente ya sea mediante configuración o mediante personalización (módulos custom).

Para este caso práctico describiré el proceso que se sigue para los desarrollos internos, en este caso el desarrollo de una nueva funcionalidad para un producto:

1. El Director de área decide una nueva funcionalidad a añadir al sistema WMS.

2. Se comienza con reuniones preliminares entre el Directores de Área y jefes de los equipos involucrados (Interfaz, Lógica de negocio, Análisis e Integración).La idea, línea a seguir y la arquitectura es marcada por el Director.

3. El plazo de ejecución total del proyecto ha partido de una planificación definida por el director en las reuniones preliminares. Este plazo siempre es inalcanzable para “meter” presión a los equipos.

4. Durante estas reuniones se genera una serie de documentos de análisis por parte del equipo que lleva el mismo nombre.

5. Se comienza el desarrollo por parte de los equipos a partir de dicha documentación.Esta documentación es de muy mala calidad, se queda en la idea preliminares sin profundizar en ninguna solución real.

6. Los jefes de equipo crean las tareas a partir de dicha documentación y las reparten entre sus integrantes. Establecen prioridades y duraciones estimadas.

7. Los equipos que intervienen en el desarrollo se encuentran en distintas zonas de la misma planta. Cada equipo trabaja de manera independiente en su tarea y la finaliza sin tener en cuenta a si hay más equipos involucrados. Al no ajustarse bien las interacciones entre las partes el resultado es que deben de rehacerse trabajos.

8. Durante el desarrollo las dudas funcionales deben de ser resueltas por el equipo de análisis.Partiendo de su documentación escueta y genérica con el fin de no mojarse se producen varias reuniones que acaban normalmente con la intervención del Director que es quien al final decide y resuelve.La documentación de análisis es actualizada pero sigue el mismo esquema anterior, lo mínimo y menos incriminatorio posible.Durante este tiempo lógicamente el desarrollo de las tareas relacionadas estas pendientes.

9. Durante el desarrollo no hay ninguna guía de documentación a seguir. Cada equipo y persona generan la que consideran oportuna. Normalmente ninguna. Tampoco hay ninguna metodología de desarrollo a seguir.

Hay guías de buenas prácticas para cada equipo pero no se mantienen y están totalmente desactualizadas por lo que no se tienen en cuenta.

10. Cada vez que se termina un desarrollo se genera un documento de pruebas. Este documento lo hace el equipo de interfaz (siempre que sea software con UI) ya que se considera el punto de entrada. La parte de lógica de negocio no hace casos de pruebas (no los documenta) aunque se supone que prueba su parte.No hay guía para este documento los casos de prueba y tipos de prueba se deciden por la persona encargada de realizar el documento.El plan de pruebas no es validado ni por Análisis ni por ningún Jefe de equipo.

11. El equipo de integración prueba el desarrollo con el documento de pruebas y el análisis. Además genera los manuales de usuario (si son necesarios).Debido al poco detalle documento de análisis se usan los casos de prueba para crear los manuales. Es común necesitar preguntar a las personas que han desarrollado cómo funcionan las cosas. Si falla algo se envía al equipo de interfaz que evalúa si se trata de un bug por su parte o pertenece a la lógica de negocio.Se resuelven los bugs hasta que pase el plan de pruebas y se da el desarrollo por finalizado.

12. Una vez finalizado se añade a la siguiente versión a publicar del producto para el que ha sido desarrollada la funcionalidad.

13. El plazo estimado normalmente se ha sobrepasado ampliamente.

Desperdicios

Desperdicios de sobreproducción

En este caso creo que podemos identificar como desperdicios las funcionalidades o partes de estas que no sean útiles para el cliente.Como se trata del desarrollo de un producto ha ocurrido que en ocasiones la funcionalidad implementada resultó no ser aplicable en clientes reales, tanto por ser demasiado compleja como por ser demasiado simple.

Aunque es un desperdicio creo que el algo inherente al desarrollo de un producto que en nuestro caso trata de abarcar la mayor parte del mercado. Aunque lógicamente debe de minimizarse su aparición.

Desperdicios del procesadoLa documentación de análisis, la documentación generada durante el desarrollo y los casos de prueba pueden considerarse desperdicios de procesado en la medida de que muchas veces son irrelevantes ya sea por su enfoque incorrecto o por no aportar información útil.

La mala gestión de las reuniones, la escasa toma de decisiones cuando hay opiniones dispares hasta la intervención del Director es también un desperdicio de este tipo.

También podemos encontrarnos con código de muy mala calidad o soluciones técnicas demasiado complejas para el objetivo requerido.

Surgen además cada vez que un equipo desarrolla una parte y esta no encaja con la de otro equipo o dicho desarrollo debe de modificarse puesto que ha cambiado el análisis y no hay un proceso coordinado para que se desarrolle de manera iterativa.

Desperdicios de tiempo de esperaEn el proceso descrito estos se producen a la hora de resolver las dudas funcionales que surgen durante el desarrollo al no solucionarse tras varias reuniones que requieren la intervención del Director y provocan que el personal de desarrollo este parada a la espera de documentación o instrucciones.

Desperdicios de inventarioEn esta tipo de desperdicios podría encajar la excesiva asignación de personas en los equipos de desarrollo. Debido a la indefinición de las especificaciones y el plan de trabajo.

También como consecuencia de la espera por análisis o aclaraciones es común asignar a las misma persona varias tareas resultando en que están todas en progreso con parte implementada pero sin finalizar el integrar (excesivo WIP).

Desperdicios de trasladosSe producen principalmente cuando los miembros de diferentes equipos deben de moverse por la oficina para tratar asuntos con algún miembro del otro equipo.

DefectosLógicamente hablando del software todos los bugs producidos en el resultado.

La documentación, análisis, planes de pruebas y manuales también son susceptibles de contener incorreciones más allá de si son necesarios o adecuados.

MuriComo se indica en la descripción del proceso es producido debido a que se establecen plazos imposibles de cumplir para “meter prisa” a las personas, de esta manera se aginan demasiadas tareas a cada persona ya que están estimadas de manera totalmente incorrecta.

La indefinición clara de objetivos, de tareas, de métodos de trabajo etc en mi opinión también produce Muri en este caso ya que aunque no implica carga de trabajo excesiva sí que provoca un alto estrés a las personas.

Mura La Mura se produce en los casos en que se asignan demasiadas personas para ciertas tareas por mala estimación y por supuesto en el caso contrario.

También se produce debido a que las tareas de un equipo dependen de la intervención de otro. Se da el caso de tener todo parado y de repente tener que finalizar un montón de tareas que se desbloquean.

Como se puede concluir a partir de la información anterior el principal problema del proceso que estamos analizando es la falta de un enfoque sistemático.

Tareas de valor

Acciones que aportan un valor real para el cliente: Generación documentación de análisis, desarrollo, planes de pruebas y manuales. Desarrollo de código. Testeo de software y corrección de bugs. Integración y publicación.

Acciones que no aportan un valor para el cliente, pero que son necesarias para el correcto funcionamiento del proceso:

Reuniones de análisis (Director y jefes de equipo.) Planificación de tareas por parte de los jefes de equipo. Conversaciones y comunicación entre integrantes de los equipos de desarrollo.

Mejoras Lean a implementar

5s En primer lugar y como se puede observar el principal problema del proceso de trabajo del caso de estudio es su falta de estandarización.

Aplicando las 5s con especial atención a la S de Seiketsu se crearía un método de trabajo estandarizado con unas etapas, productos, procesos, resultados y métodos definidos.De esta manera se mejorara enormemente los resultados obtenidos al tener unas reglas de juego claras y para todos.

También tiene especial importancia la S de Shitsuke ya que es necesario un cambio de modelo de trabajo y un cambio de mentalidad de la organización.Creo que el proceso que seguimos para desarrollos internos parte de buenas ideas debido a que intenta ser ligero (incluso ágil) pero peca de poco serio debido a su falta total de estandarización.

No solo se crearían documentos, guías y sesiones de formación y colaboración sino que sería importante establecer una serie de principios que establezcan la filosofía tanto de la empresa como de su método de trabajo (Centrarse en el cliente, procesos agiles, mejora continua…)

Kanban y herramientas visualesUtilizar estas técnicas para seguir el estado de las tareas de desarrollo aportaría una mejora en la organización y la visibilidad del trabajo.Si además estas están accesibles a todas las personas participantes también ayuda a la implicación de los equipos.

Work cellsSe reorganizaría a las personas por cercanía en la oficina. Aunque pertenezcan a distintos equipos se colocara lo más cerca posible a personas que colaboren en los mismos proyectos.

Total Quality Management Se establecerían mecanismos y se definirían procesos para monitorizar la calidad de los productos ya fueran intermedios o finales.Se establecerían métricas y proceso para la calidad de la documentación, del software, de los planes de pruebas.En estas tareas intervendrían personas de los diferentes equipos para así facilitar la comprensión global del funcionamiento (sabemos que hacen los otros) y mejorar la implicación y comunicación.

Poka-yokeActualmente utilizamos sistemas de compilación continua, control de versiones etc .Bastante relacionado con otras técnicas que indico que deberían aplicarse se podrían considerar poka-yoke a la existencia de métodos y procesos estandarizados porque así sabríamos que hacer y cómo enfocar nuestro trabajo lo cual es una manera de evitar errores en si misma.

JidokaComo ya indique en apartados anteriores es necesario un cambio de filosofía.Es necesaria que la toma de decisiones no pase solamente por el director. Cada integrante de un equipo (ya sea jefe o desarrollador) debería tener una cierta capacidad de decisión lógicamente basada en los métodos de trabajo que se definirían.Esto haría disminuir los tiempos de espera la Muri y la Mura.Además de nuevo incidiría en la implicación de las personas con la compañía su método de trabajo y filosofía.

Quick Changeover o Single Minute Exchange of Dies (SMED)Esta técnica sería importante para permitir trabajar en varios procesos tareas a la vez al igual que la anterior nos permitiría disminuir los tiempos de espera la Muri y la Mura.