1. Proceso de Trabajo
A 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.

2. 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 procesado
La 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.

3. 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 espera
En 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 inventario
En 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 traslados
Se producen principalmente cuando los miembros de diferentes equipos deben de moverse
por la oficina para tratar asuntos con algún miembro del otro equipo.
Defectos
Ló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.
Muri
Como 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.

4. 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
elcorrecto 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 deSeiketsu se crearía un método de trabajo
estandarizado con unasetapas,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 visuales
Utilizar 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.

5. Workcells
Se 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-yoke
Actualmente 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.
Jidoka
Como 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.