Con el
presente mail nos gustaría reflexionar acerca de por qué los Sistemas de
Información son complejos, farragosos y/o poco fiables y cómo, cogiendo
técnicas y mentalidad creadas por el LEAN, los podemos transformar en
sencillos, amigables y a prueba de fallos al 100%
1.
Antecedentes
Acudamos
a un escrito anterior nuestro donde definíamos lo que, según el LEAN, debe
tener un proceso para ser calificado de robusto:
“Lo
mínimo, según nuestra opinión, que debe tener un proceso para ser calificado de
robusto es lo siguiente :
-Se añade valor continuamente al Cliente: hay un mínimo despilfarro/No Valor entre actividades de Valor Añadido
-Las actividades de Valor se hacen bien a la primera : no hay vueltas atrás
-Los defectos se detectan en origen al 100% : disponemos de POKA-YOKES, sistemas a prueba de fallos al 100%
-Hay sistemas de control visual en tiempo real : ANDONES, que sacan a la luz cualquier incidencia y/o status de tarea”
-Se añade valor continuamente al Cliente: hay un mínimo despilfarro/No Valor entre actividades de Valor Añadido
-Las actividades de Valor se hacen bien a la primera : no hay vueltas atrás
-Los defectos se detectan en origen al 100% : disponemos de POKA-YOKES, sistemas a prueba de fallos al 100%
-Hay sistemas de control visual en tiempo real : ANDONES, que sacan a la luz cualquier incidencia y/o status de tarea”
También
nos gustaría añadir una idea clave que estuvo desde el principio en la mente de
los creadores del LEAN:
-Transformar
lo complejo en sencillo: es básico para conseguir la polivalencia que
exige la gestión por procesos
NOTA. Caso
típico de esto último: cuando los creadores del LEAN fundaron las bases del
Sistema, el tiempo de cambio de las líneas de Prensas era de 10 horas y solo lo
podían hacer especialistas. Con las técnicas SMED de cambio rápido lo redujeron
a menos de 10 min, transformaron lo complejo en sencillo y el cambio podía ser
hecho por los operarios de producción
En el
antes, cuando lo hacían especialistas, el cuello de botella eran ellos mismos y
solo se podía hacer un cambio a la vez; en el después, al poder ser hecho por
los propios operarios de las Prensas, se podían hacer multitud de cambios al
mismo tiempo
Ver
detalles en nuestro escrito:
2.
¿Dónde
se hacen farragosos, complejos y/o poco fiables los Sistemas de Información?
Ciclo de vida de los Productos
El modelo
pre-LEAN se basa en el paradigma de que se mejora el ciclo de vida reduciendo
al mínimo los tiempos de las operaciones de Valor Añadido, sin prestar
mucha atención a “los vacíos que hay entre operaciones de Valor”
De hecho,
para conseguir que todos los subprocesos de Valor no paren, se busca tener
colchones/stocks actividades de Valor
Como los
subprocesos son manejados por Departamentos diferentes, al final el Modelo
pre-LEAN desemboca en herramientas creadas ad-hoc dentro del propio
Departamento para buscar el bien local de la productividad interna
El
pensamiento LEAN lo primero que se pregunta es por qué están desconectadas las
Operaciones de Valor Añadido…por supuesto, entre los diferentes Departamentos
Para
ello, visualizamos, mediante un Value Stream Mapping, las operaciones de Valor
y, sobre todo, “los vacíos que hay en esa cadena de ADN”
El pensamiento LEAN se basa en gestionar la Cadena Global,
enfocándose no tanto en la productividad de cada Operación Individual sino en reducir al máximo la falta de flujo entre las
citadas Operaciones de Valor ,detectando y minimizando el despilfarro
que NO PAGA EL CLIENTE
3. ¿ Qué es lo que alarga el lead time/ciclo de vida
de los productos?
-Se tarda mucho en definir las estructuras de producto
-Se pierde mucho tiempo en actualizar las estructuras en
caso de modificaciones
-Si no se tiene todo integrado, es un calvario actualizar
las modificaciones en las múltiples herramientas departamentales….las famosas
herramientas “por si acaso”
Estas herramientas han sido creadas ad-hoc para el “bien
local” de optimizar el trabajo dentro de cada departamento, pero provocan un
“mal general” cuando vienen las modificaciones, al no asegurar la integridad
entre los diferentes departamentos
-Si las modificaciones en las estructuras de producto no
están actualizadas, el output del Sistema no valdrá para nada
-Si no están bien metidos los stocks, es evidente que el
MRP calculará mal las necesidades de materiales
-Si el MRP es muy farragoso, la gente no le hará caso, y/o
lo lanzarán con poca frecuencia
4. Soluciones LEAN:
-La experiencia nos dice que casi todos los sistemas
integrados funcionan bien y que realmente el problema es la calidad de los
datos que se meten.
Como dicen los americanos, hasta en el mejor Sistema de
Información del mundo es cierta la máxima:
GIGO ( Garbage in, garbage out ) : si metes
basura, sale basura -à buscando siempre la
sencillez, si lo que se mete es bueno, lo que sale será lo que se necesita
-La integridad de las estructuras de producto, en caso de
modificaciones muy frecuentes, exige un repositorio único donde se lleven a
cabo las actualizaciones, de una sola vez
Además, este repositorio debe ser capaz de entregar la
información actualizada en los diferentes formatos/presentaciones que necesiten
los diferentes departamentos: Ingeniería, Compras, Producción, Expediciones,
etc.
-La fiabilidad de los nuevos diseños y la reducción del
lead time de industrialización deben asegurarse vía configuradores; además ,
estas soluciones actúan como poka-yokes ( sistemas a prueba de fallos al 100%)
en caso de errores
-El MRP debe dedicarse a gestionar las referencias caras
y/o de plazos de entrega largos. Hay que sacar del MRP las referencias baratas/
masivas/pequeñas y gestionarlas vía Kanban
NOTA. El KANBAN fue creado para que hubiera materiales a
pie de línea sin necesidad de cálculo de necesidades: doble contenedor, cuando
se acaba el primero, el mismo contenedor vacío inicia la secuencia de
reaprovisionamiento…. No hace falta cálculo de necesidades para que nunca falte
ese material a pie de línea
Un cordial saludo
Alvaro Ballesteros
No hay comentarios:
Publicar un comentario