sábado, 25 de abril de 2015

Los siete despilfarros LEAN en IT


Estimad@s Clientes y/o amantes del LEAN: 

Vamos a dedicar el presente escrito a cómo aplicar los conceptos/Metodología de los siete despilfarros técnicos clásicos del LEAN a la hora de identificar operaciones de No Valor en Proyectos con una fuerte carga de IT 

Estamos hablando de un caso en que, dentro del Planning inicial de Cliente del Proyecto global, IT tiene asignadas gran cantidad de actividades y/o recursos, entrelazadas entre otras actividades de Cliente y de otros proveedores

En el método clásico, para reducir los costes y plazos del Proyecto completo se busca minimizar los costes/plazos de cada actividad de Valor, de forma individual; en el caso de estos Proyectos, suele traducirse en mejorar la gestión dentro de cada Departamento/Proveedor  

El pensamiento LEAN se basa en gestionar la Cadena Global, enfocándose en reducir al máximo la falta de flujo entre operaciones de Valor, de forma global, esto es integrando:
Departamentos internos / de Cliente / todos los Proveedores implicados   

En gráfico adjunto visualizamos el concepto clave: cuanto más largo es el lead time del Proceso Global, mayores son los costes de los despilfarros LEAN

Por eso, recomendamos que, aunque el Mercado/Cliente no pida la reducción del tiempo global de un Proyecto dado, es de muy alta importancia esa reducción global….sabéis aquello del especialista LEAN japonés que decía :
“Reduzcan ustedes el lead time de sus Procesos de Negocio…. aunque no sepan para qué hoy, ya lo sabrán mañana
La Metodología LEAN de trabajo pasa por una primera fase de identificación estos despilfarros,  operaciones de No Valor 
Estas operaciones sin valor añadido son las mismas que las clásicas del LEAN que aplicó TOYOTA para el mundo industrial, pero adaptadas al campo de IT 
Un resumen típico de despilfarros encontrados es el siguiente: 
1. Sobreproducción
            - Arrancar una actividad antes de que la siguiente esté terminada
            - Empezar una actividad antes de que la anterior esté terminada
            - Completar el diseño de soluciones antes de chequear la compatibilidad integral del sistema completo o haber comprobado su fácil “integración con el resto de Módulos”
2. Esperas
            - Diseño no tiene todo lo que necesita para llevar a cabo una actividad
            - Diseño lleva a cabo el trabajo por lotes, no entregando nada a Producción interna / Proveedores hasta que no esté completado el Diseño; ello supone que los Proveedores han perdido un tiempo precioso para iniciar su trabajo
            - Esperas por revisiones, decisiones, permisos, aprobaciones, faltas de información, órdenes de compra
            - Esperas por negociaciones innecesarias al seleccionar / gestionar nuevos proveedores
            - Personas / departamentos cuellos de botella, por no tener clara ( en esas personas clave ) una subdivisión de funciones entre tareas que necesitan 20 años de experiencia y otras que las puede hacer alguien con 2 años de experiencia
             - Pérdidas de tiempos en preparación de presentaciones  a muy diferentes niveles de la Organización
3. Transportes
            - Pasos innecesarios desde una actividad a otra
            - Pasos innecesarios de información de unas manos a otras
4. Tiempo de procesos
            - Pérdidas de tiempo diseñando Módulos nuevos en vez de partir de modificaciones de otros existentes ya contrastados
            - No tener estandarizados los métodos / procesos de producción para Módulos de tecnologías similares, lo que supone que cada Proyecto genera sus propios métodos / tiempos. Esto tiene fuertes implicaciones negativas, tanto en la forma de seguimiento de la mejora continua por parte de Diseño como en el ingente esfuerzo que suponen migraciones de Módulos de unos Centros a otros
            - No tener "best practices" por tecnología, lo que puede suponer no solo pérdidas de tiempo en la Integración final sino pérdidas de productividad del propio entregable final, agravado por el hecho de que los cambios de método posteriores ( hacia la best practice ) son mucho más complejos de gestionar
-El punto anterior, los cambios de método “a la brava” tiene los siguientes inconvenientes:
                        - Hay que hacerlo basado en oleadas de trabajo  
                        - Las posibles modificaciones en diseño son lentas de aprobación por parte del Cliente
NOTA. Este despilfarro suele ser el más grave en la mayoría de los casos   
5. Inventario
            - Exceso de información, que conduce a confusiones / malentendidos
            - Exceso de personas / niveles intermedios involucrados en el trabajo de detalle
            - Trabajo llega por oleadas, con fases intermedias de poco trabajo (falta de nivelación)  
6. Movimientos
            - Personas clave asistiendo a reuniones innecesarias / lugares distintos
            - Los informes pasan por muchos sitios / oficinas redundantes, y/o a muchos niveles jerárquicos  
7. Defectos
            - Tiempos perdidos en testear la Calidad de nuevos Módulos, en vez de apoyarse en otros ya probados
            - Tiempos perdidos debidos a cambios de Diseño de última hora por defectos detectados tarde
            - Todo el tiempo / esfuerzo empleado en retrabajos / vueltas atrás es puro despilfarro en sí mismo
            - Perdidas de calidad debido a pruebas / aclaraciones con nuevos proveedores en cada nuevo diseño
NOTA. Este despilfarro suele ser el segundo más importante en el caso de desarrollar un Proyecto basados en casos similares y el más crítico en el caso de Proyectos nuevos 
Los beneficios típicos de la aplicación del LEAN al desarrollo e implantación de Proyectos de IT son los siguientes:
Reducción de costes de No Calidad                                > 20%
Ahorros en recursos necesarios                                      > 20%
Reducción de plazos de ejecución de Proyectos             > 30%
Incremento de capacidad de Proyectos simultáneos        > 50%
Mejora de capacidad de realización de Ofertas                > 100%  
En este punto nos gustaría hacer un pequeño apunte respecto a lo que buscaría una buena solución LEAN : como el enfoque global/holístico de los despilfarros detectados nos está detectando los sobrecostes/tiempo perdido en los procesos “aguas abajo” por no haberlos tenido suficientemente en cuenta, puede ocurrir perfectamente que la solución vaya enfocada a “un mal local para nosotros” pero que produce un bien general en todo el Proyecto
 
Caso típico de lo que estamos hablando: repositorio único / configurador, como método óptimo de gestionar Proyectos donde las modificaciones son constantes
NOTA FINAL. En estos casos, siempre es bueno estudiar los indicadores de los que inventaron el LEAN: hoy por hoy, TOYOTA es capaz de diseñar nuevos modelos en la mitad de tiempo que cualquiera de la competencia
Antes, los cuellos de botella a la hora de diseñar un nuevo vehículo eran las matrices de las nuevas piezas; ahora el cuello de botella es el hard y el soft de la electrónica que lleva el vehículo…curioso, ¿no?
Un cordial saludo
Alvaro Ballesteros

No hay comentarios:

Publicar un comentario