proyecto fin de carrera - universidad de...

i

Equation Chapter 1 Section 1

Proyecto Fin de Carrera

Ingeniería Industrial

Modelado y estudio comparativo de sistemas de

control de producción tipo pull

Departamento de Organización Industrial y

Gestión de Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Autor: Raquel Rey Simón

Tutor: Antonio Plácido Moreno Beltrán

Sevilla, 2018

iii

Proyecto Fin de Carrera

Ingeniería Industrial

Modelado y estudio comparativo de sistemas de

control de producción tipo pull

Autor:

Raquel Rey Simón

Tutor:

Antonio Plácido Moreno Beltrán

Profesor Ayudante Doctor

Departamento de Organización Industrial y Gestión de Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2018

v

Proyecto Fin de Carrera:

Modelado y estudio comparativo de sistemas de control de producción tipo pull

Autor: Raquel Rey Simón

Tutor: Antonio Plácido Moreno Beltrán

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2018

El Secretario del Tribunal

vii

Agradecimientos

A mi tutor, Plácido Moreno, por su ayuda a la hora de la elección de este proyecto, orientación y tiempo

dedicado a la corrección.

A mis compañeros, Clara, Inma, Jesús, Nazaret, Tejera y Verónica, con vuestro apoyo, ayuda y momentos

compartidos, habéis hecho que este camino haya sido más fácil y ameno.

A mis amigas, por vuestro interés en mi carrera, en especial Narbona, por tener siempre unas palabras de

ánimo.

A Rocío, Carlos e Iván, por creer en mí y por animarme, sacándome una sonrisa en los momentos más

difíciles.

A mis padres, por ser mis pilares fundamentales, vuestra confianza en mí ha hecho que nunca me rinda.

ix

Resumen

En la actualidad, en la literatura de los sistemas de producción tipo pull, como son Kanban, ConWIP y

POLCA, se encuentra bastante información sobre ellos, en cuanto a cómo funcionan, sus características

particulares, como se llegó a ellos, incluso comparaciones cualitativas entre ellos. Sin embargo, lo que se

quiere en este estudio, es realizar un contraste cuantitativo.

Para ello, se va a simular, mediante el software Arena, cada uno de los sistemas. Se explicará cómo funcionan

los módulos de este software que han sido usados para la realización de los modelos. Así como, se desarrollará

paso a paso como se han modelado cada uno de ellos.

La configuración de los sistemas será de una línea de producción simple de tres estaciones en serie. Se van a

analizar ocho escenarios diferentes, que se consiguen a través de la combinación de tres factores importantes,

que son la variabilidad, congestión y equilibrado de los sistemas. Con ello se hará una recopilación de datos,

de los que serán interesantes cuatro indicadores, que son el tiempo de ciclo promedio total, el tiempo de espera

en cola, el WIP promedio y la utilización de las estaciones de trabajo.

Además, como estudio secundario, se modelará un sistema con secuencia de producción, para demostrar la

existencia de bloqueo en POLCA. En Kanban y ConWIP no ocurre, ya que las tarjetas Kanban dependen del

producto y en ConWIP las tarjetas se mantienen durante todo el procesamiento, desde la entrada hasta la

salida. Después de esta demostración, se propondrán soluciones a este bloqueo que se produce en POLCA.

Con este estudio, se demuestra que el sistema que mejor rendimiento obtiene en cada uno de los escenarios es

POLCA, a pesar de su dificultad de implementación. En muchos casos, los resultados son muy parecidos a

Kanban. Sin embargo, ConWIP, siendo el sistema más fácil, se demuestra que es el que peor actúa en todos

los casos.

xi

Abstract

Nowadays, specialised literature on pull production systems can provide a broad range of information about

these systems, such as Kanban, ConWIP and POLCA, in terms of how they work, their specific

characteristics, the way the systems were developed, and qualitative comparisons between them. However,

there is still a lack of quantitative contrasts, which will be made in this thesis.

To carry out the quantitative comparisons, all card-based systems will be simulated using the Arena software.

The function of the software modules that have been used will be explained. In addition, the models developed

for the pull systems will be detailed, step by step.

The systems' configuration will be a simple production line, consisting of three stations in series. Eight

different scenarios will be analyzed. Each one of the scenarios combines three relevant factors, which are the

variability, congestion and the systems' balance. After the simulation is completed, data will be collected. Four

indicators are of interest, namely the average total cycle time, the waiting time in queue, the average WIP and

the use of the workstations.

Finally, as a secondary objective, a system with production sequences will be modeled, in order to demonstrate

the existence of severe blocking in POLCA. It does not happen in Kanban and ConWIP, as the Kanban cards

depend on the product and ConWIP cards are maintained throughout the processing, from the input to the

output of the system. After this demonstration, solutions to the POLCA severe blockage will be proposed.

After this study, it can be said that obtaining the best performance in every scenario is POLCA, although its

implementation seems to be more difficult than other systems. In many cases, results are very similar to

Kanban. On the other hand, ConWIP, despite being the easiest system, has turned out to yield worse results for

all cases.

xiii

Índice

Agradecimientos vii

Resumen ix

Abstract xi

Índice xiii

Índice de Tablas xv

Índice de Figuras xvii

Introducción 1 1.1 Justificación 1 1.2 Objetivos 1

1.2.1 Objetivo General 1 1.2.2 Objetivos Específicos 1

1.3 Estructura del trabajo 1

Sistemas pull 3 2.1 Sistema Kanban 5 2.2 Sistema ConWIP 9 2.3 Sistema POLCA 11

Arena 15 3.1 Panel de procesos básicos 15

3.1.1 Módulos de diagramas de flujo 15 3.1.2 Módulos de datos 21

3.2 Panel de procesos avanzados 23 3.2.1 Módulos de diagramas de flujo 23 3.2.2 Módulos de datos 26

3.3 Panel de transferencia avanzada 27 3.3.1 Módulos de diagramas de flujo 27 3.3.2 Módulos de datos 28

Modelos 31 4.1 Modelo sistema Kanban 31 4.2 Modelo sistema ConWIP 37 4.3 Modelo sistema POLCA 39 4.4 Modelo con secuencia de producción 39

Discusión de resultados 45 5.1 Estudio comparativo 45 5.2 Propuestas de solución para bloqueo cruzado 48

Conclusiones y líneas futuras 55 6.1 Conclusiones 55 6.2 Líneas futuras 55

Bibliografía 57

Anexo 59

xv

ÍNDICE DE TABLAS

Tabla 5-1: Datos de los factores. 46

Tabla 5-2: Nomenclatura de los factores. 46

Tabla 5-3: Resultados de la simulación. 47

xvii

ÍNDICE DE FIGURAS

Figura 2-1: Símil del barco. Velasco y Campins (2013). 4

Figura 2-2: Tarjeta de transporte. Velasco y Campins (2013). 5

Figura 2-3: Tarjeta de producción. Velasco y Campins (2013). 6

Figura 2-4: Distintas señales Kanban. Heizer y Render (2008). 6

Figura 2-5: Sistema Kanban de dos tarjetas. Hopp y Spearman (2004). 7

Figura 2-6: Equivalencia del sistema Kanban de una y dos tarjetas. Hopp y Spearman (2004). 7

Figura 2-7: Sistema ConWIP. Thürer et al (2016). 9

Figura 2-8: Tarjeta POLCA. Lödding (2013). 11

Figura 2-9: Sistema POLCA. Thürer et al (2016). 12

Figura 2-10: Sistema POLCA bloqueado. Thürer et al (2016). 13

Figura 3-1: Módulo Create. 15

Figura 3-2: Módulo Dispose. 16

Figura 3-3: Módulo Process. 17

Figura 3-4: Cuadro de dialogo de Resources en módulo Process. 18

Figura 3-5: Módulo Decide. 18

Figura 3-6: Cuadro de diálogo de Decide seleccionando Variable. 19

Figura 3-7: Cuadro de diálogo para añadir condiciones si es N-way by condition. 19

Figura 3-8: Módulo Assign. 20

Figura 3-9: Cuadro de diálogo de Assignments. 20

Figura 3-10: Módulo Record. 21

Figura 3-11: Módulo de datos Entity. 21

Figura 3-12: Módulo de datos Queue. 22

Figura 3-13: Módulo de datos Resource. 22

Figura 3-14: Módulo de datos Variable. 23

Figura 3-15: Módulo Delay. 23

Figura 3-16: Módulo Hold. 24

Figura 3-17: Módulo Release. 25

Figura 3-18: Cuadro de diálogo de Resources en módulo Release. 26

Figura 3-19: Módulo Signal. 26

Figura 3-20: Módulo de datos Advanced Set. 27

Figura 3-21: Módulo Route. 27

Figura 3-22: Módulo Station. 28

Figura 3-23: Módulo de datos Sequence. 29

Figura 4-1: Llegada sistema Kanban. 32

xviii

Figura 4-2: Route para inicio de secuencia única. 32

Figura 4-3: Modelado estación A. 32

Figura 4-4: Dispatcher. 33

Figura 4-5: Condición de bloqueo para sistema Kanban. 33

Figura 4-6: Tiempo de llegada y WIP. 34

Figura 4-7: Asignar tarjeta Kanban A. 34

Figura 4-8: Liberar lanzador 1. 34

Figura 4-9: Proceso máquinas tipo 1. 35

Figura 4-10: Devolver tarjeta Kanban A. 35

Figura 4-11: Modelado estación B. 35

Figura 4-12: Salida sistema Kanban. 36

Figura 4-13: Contador WIP. 36

Figura 4-14: Record para contar WIP. 36

Figura 4-15: Retraso para contar WIP cada segundo. 37

Figura 4-16: Llegada sistema ConWIP. 37

Figura 4-17: Estación A del sistema ConWIP. 37

Figura 4-18: Condición de bloqueo para sistema ConWIP. 38

Figura 4-19: Bloqueo órdenes de trabajo. 38

Figura 4-20: Salida sistema ConWIP. 38

Figura 4-21: Estación B sistema POLCA. 39

Figura 4-22: Llegada sistema POLCA con secuencia. 40

Figura 4-23: Atributo tipo. 40

Figura 4-24: Atributo Entity.Sequence. 40

Figura 4-25: Advanced Set. 41

Figura 4-26: Sequence. 41

Figura 4-27: Route secuencial. 41

Figura 4-28: Estación A del modelo con secuencia. 42

Figura 4-29: Rama a seguir según el tipo. 43

Figura 5-1: Ninguna estación en proceso. 49

Figura 5-2: Tarjetas POLCA a cero. 49

Figura 5-3: Todas las estaciones con órdenes de trabajo bloqueadas. 49

Figura 5-4: Colas en los dispatcher. 50

Figura 5-5: Decide de solución al bloqueo cruzado. 50

Figura 5-6: Assign de primera propuesta de solución al bloqueo cruzado. 50

Figura 5-7: Delay de solución al bloqueo cruzado. 51

Figura 5-8: Primera propuesta de solución al bloqueo cruzado. 51

Figura 5-9: Resultado de la simulación de primera propuesta de solución al bloqueo cruzado. 51

Figura 5-10: Decide segunda propuesta de solución al bloqueo cruzado. 52

Figura 5-11: Assign segunda propuesta de solución al bloqueo cruzado. 52

xix

Figura 5-12: Segunda propuesta de solución al bloqueo cruzado. 53

Figura 5-13: Resultado de simulación de la segunda propuesta. 53

1

INTRODUCCIÓN

1.1 Justificación

El objetivo principal de los sistemas de control de producción es controlar los procesos para la generación de

un producto. Es importante que estos sistemas sean efectivos y eficientes en cuanto a la atención a sus clientes.

Este proyecto centra la atención en los sistemas de control de producción tipo pull. Estos reaccionan ante el

pedido final del cliente, ya sea aumentando o disminuyendo los requerimientos de operación para producir

sólo lo que se necesita para satisfacer la demanda, y hacerlo únicamente cuando sea necesario (Champan,

2006).

El primer sistema en denominarse tipo pull fue el sistema Kanban, el cual es un sistema basado en tarjetas.

Desde la aparición de éste, se han invertido grandes esfuerzos de investigación en cuanto a estos tipos de

sistemas con el intento de mejorar Kanban o desarrollar sistemas alternativos, como son ConWIP y POLCA.

Por tanto, hay muchos documentos que describen el funcionamiento de estos sistemas de forma particular. En

base a esto, el interés de la realización de este proyecto consiste en comparar de forma cuantitativa que sistema

obtiene un mejor rendimiento ante las mismas condiciones.

1.2 Objetivos

1.2.1 Objetivo General

El objetivo general de este proyecto es la simulación mediante el software Arena de tres sistemas de control de

producción en serie tipo pull, los cuales son: Kanban, ConWIP y POLCA. Mediante esta simulación, se

recopilarán datos de interés que permitan comparar los tres sistemas en este estudio.

1.2.2 Objetivos Específicos

• Recopilar datos del tiempo de ciclo promedio total, el WIP promedio, el tiempo de espera en cola y la

utilización de las estaciones de trabajo.

• Comprobar cómo afecta la congestión, variabilidad y equilibrado de los sistemas al rendimiento de estos.

• Demostrar el problema de bloqueo de los sistemas POLCA y la propuesta de solución para ello.

1.3 Estructura del trabajo

La memoria de este proyecto se divide en seis capítulos y un anexo. En este primer capítulo titulado

“Introducción”, se justifica por qué se realiza y los objetivos generales y específicos de este. Además de la

estructura del trabajo y el contenido resumido de cada uno de los capítulos.

En el segundo capítulo, titulado “Sistemas pull”, se explica el origen de estos sistemas. También, se comenta

los aspectos más importantes de los tres sistemas objeto de estudio, Kanban, ConWIP y POLCA.

Introducción

2

En el tercer capítulo, titulado “Arena”, se desarrolla cada uno de los módulos del software Arena que se han

usado para la simulación de todos los modelos realizados.

En el cuarto capítulo, titulado “Modelos”, se explica paso a paso como se ha realizado el modelaje en Arena de

cada uno de los sistemas de control de producción y del modelo con secuencia de producción.

En el quinto capítulo, titulado “Discusión de resultados”, se presentan los resultados obtenidos tras la

simulación de los distintos sistemas de control de producción con el consiguiente estudio comparativo.

Además, se proponen soluciones al problema del bloqueo en POLCA.

En el sexto capítulo, titulado “Conclusiones y líneas futuras”, se incluyen las conclusiones a las que se llega

tras el estudio realizado y se propone una relación de posibles líneas futuras orientadas a estudios posteriores.

Por último, se tiene el anexo, en el cual se recoge el modelaje completo de cada uno de los modelos realizados

en Arena.

3

SISTEMAS PULL

e forma paralela al desarrollo en EE.UU. de los sistemas MRP (Planificación de Requerimientos de

Material), en Japón empezó el auge de un enfoque de planificación totalmente diferente que, en su

conjunto, se vino a denominar JIT (Just-In-Time, “justo a tiempo”). Su principal valedora fue la

empresa Toyota, que desarrollo un nuevo sistema, denominado Sistema de Producción Toyota (Moscoso y

Lago, 2016).

El sistema MRP se clasifica como sistema push (o de empuje), lo que significa que es preciso calcular con

antelación el material que requerirá la operación, para luego “empujarlo” hacia el sistema mediante una orden

de producción, independientemente de si es oportuno y de la disponibilidad de recursos para trabajar con ese

material (Chapman, 2006, Heizer y Render, 2008).

El Sistema de Producción Toyota tiene dos pilares básicos:

1. Autocontrol: debe interpretarse como autocontrol de los defectos y sirve de soporte al concepto de

producción en el momento oportuno, al impedir la entrada en el flujo, como resultado de cada

proceso, de unidades defectuosas que perturbarían el proceso siguiente.

2. Just-in-time (JIT): el concepto sobre el que se basa el JIT es el de un sistema pull (o de arrastre) que es

un sistema que tira o arrastra una unidad hacia donde es necesaria justo cuando hace falta.

En sistemas MRP, los stocks no dejan ver los problemas originados por una mala organización; no se originan

fallos de entregas de productos y la apariencia es que todo va bien, que no hay problemas. Sin embargo, todo

se basa en unos niveles de stocks cuyo coste es elevadísimo (Velasco y Campins, 2013, Heizer y Render,

2008).

El símil de la filosofía JIT es el de un barco, ver figura 2-1, que puede navegar plácidamente sin chocar con las

rocas del fondo debido a que el nivel del agua es suficientemente elevado pareciendo que no hay ningún

obstáculo. Sólo bajando el nivel de agua (stocks) aparecerá el problema más destacado y podrá ser

solucionado, y ello permitirá seguir bajando el nivel hasta encontrar el próximo y así hasta conseguir

“navegar” plácidamente con un nivel mínimo (Velasco y Campins, 2013).

D

Sistemas pull

4

Figura 2-1: Símil del barco. Velasco y Campins (2013).

Operar con éxito un sistema JIT requiere cumplir unos requisitos importantes:

• La demanda y las cargas de trabajo deben ser estables y niveladas, ya que las fluctuaciones en ritmos

y cargas de trabajo se transmiten directamente entre las estaciones de trabajo.

• Al operar con colchones de inventarios pequeños, un sistema JIT no es demasiado robusto frente a

interrupciones o mucha variabilidad. En contrapartida, requiere de un nivel razonable de colchones de

capacidad (sobrecapacidad) en cada estación de trabajo para poder acomodar las variabilidades de la

demanda que recibe.

• Para favorecer la producción en flujo tenso y tener tiempos de flujo cortos entre estaciones, obliga a

que los tiempos de cambio (set-ups) sean cortos y las estaciones flexibles para servir pequeñas

cantidades de diferentes productos.

• Los niveles de calidad, tanto en los productos como en los recursos (máquinas, instalaciones, etc.)

deben ser muy altos, ya que cada defecto causa un retraso en la estación posterior.

Por todo lo anterior, los sistemas JIT generalmente son exitosos en entornos de manufactura repetitiva, es

decir, donde los volúmenes de producción pueden controlarse, la gama de producto es razonablemente

limitada, o donde, en contrapartida, los procesos sean flexibles. Es un error intentar montar sistemas JIT muy

tensos cuando el sistema no dispone de esta flexibilidad necesaria y necesita trabajar con lotes grandes para

conseguir economías de escala (Moscoso y Lago, 2016).

A parte de esto, hay que tener en cuenta que los sistemas pull son la solución a algunos de los problemas de

muda (despilfarros). Esto es, cualquier actividad desarrollada por una empresa que consume recursos y no

produce valor para el cliente. Hay muchos tipos de muda, los cuales podemos agrupar en: exceso de

producción, operaciones, movimientos, transportes, esperas, stocks, defectos de calidad e infrautilización de

las habilidades del personal. De estas, las que se podrían disminuir utilizando la filosofía pull, son exceso de

producción, esperas y stocks (Velasco y Campins, 2013).

En las siguientes secciones, vamos a desarrollar tres sistemas pull: Kanban, ConWIP y POLCA. Los tres son

sistemas de control de producción basados en tarjetas que utilizan la información sobre la salida del sistema

para controlar la entrada al mismo.

5 Modelado y estudio comparativo de sistemas de control de producción tipo pull

2.1 Sistema Kanban

Taiichi Ohno introdujo los sistemas Kanban en Toyota, fue el primer sistema de control de producción basado

en tarjetas denominado sistema pull. Estos sistemas fueron originalmente desarrollados para coordinar la

confluencia de diferentes flujos de productos, ya sea en el interior de una empresa como entre diferentes

empresas (Thürer et al, 2016).

Para llevar a cabo esta coordinación, hace uso de un dispositivo de señalización que, normalmente, son tarjetas

(la traducción de Kanban en japonés es tarjeta o boleto), que no tienen por qué ir unidas a un solo producto, y

pueden adjuntarse también a contenedores en los que caben varios productos. A cada lote se le asigna una

tarjeta Kanban en cada punto en el tiempo, por lo que el número de tarjetas Kanbans limita el stock de

materiales.

La tarjeta Kanban enumera las características clave del material al cual está anexada. Casi siempre estos datos

incluyen (Chapman, 2006, Lödding, 2013):

• Número e identificación del componente.

• Ubicación dentro del almacén.

• Tamaño del contenedor (en caso de que el material esté almacenado en un contenedor).

• Centro de trabajo (o proveedor) de origen.

Se utilizan principalmente dos tipos de tarjetas, pero de cada tipo puede haber varias en un mismo proceso,

estas son (Velasco y Campins, 2013):

1. Tarjeta de transporte: especifica el tipo y cantidad de producto a retirar del proceso anterior. Ver

figura 2-2.

2. Tarjeta de producción: indica el tipo y la cantidad a fabricar. Ver figura 2-3.

Figura 2-2: Tarjeta de transporte. Velasco y Campins (2013).

Sistemas pull

6

Figura 2-3: Tarjeta de producción. Velasco y Campins (2013).

Hay instalaciones en las que usan el sistema Kanban, pero en vez de hacer uso de tarjetas emplean otros tipos

de señalización. Por ejemplo, un hueco en el suelo del taller es indicio suficiente de que hace falta el siguiente

contenedor o una señal como una bandera (ver figura 2-4) para avisar de que es el momento para el próximo

contenedor (Heizer y Render, 2008).

Figura 2-4: Distintas señales Kanban. Heizer y Render (2008).

Ohno (1988) estableció un conjunto de reglas Kanban, que son las siguientes (Thürer et al, 2016):

1. La última línea acude a la anterior para recoger los productos que necesita.

2. La línea anterior produce ciertos artículos en la cantidad indicada por la tarjeta Kanban.

3. No se hacen artículos o se trasportan sin un Kanban.

4. Siempre hay que adjuntar un Kanban al producto.

La versión clásica de Kanban como pionera de Toyota es el llamado “Sistema Kanban de dos tarjetas”. En este

sistema se hace uso de los dos tipos de tarjetas explicados anteriormente. La producción comienza cuando un

trabajador que tiene una tarjeta de movimiento se dispone a coger un contendor del punto de salida. Esta tarjeta

autoriza al trabajador a tomar este contenedor y le dice dónde se va a necesitar. Antes de su retirada, la tarjeta

de producción que lleva adjunta el contenedor debe ser liberada. Entonces el trabajador llevara el contenedor al

punto de entrada de la siguiente estación de trabajo, en la que no podrá ser procesado el producto hasta que no

haya una tarjeta de producción libre. En el momento que se tenga, se liberará la tarjeta de movimiento y se le

adjuntará la de producción. Periódicamente, un trabajador recoge las tarjetas de movimiento, localiza las

piezas necesarias, las trasporta a la estación de trabajo y el proceso se repite en la estación de trabajo posterior.

Para clarificar este concepto ver figura 2-5:


Figura 2-5: Sistema Kanban de dos tarjetas. Hopp y Spearman (2004).

Como podemos observar, este sistema marca una diferencia entre el procesamiento de las piezas y el

movimiento del material. Si queremos convertir el sistema Kanban de dos tarjetas, en un sistema de una

tarjeta, basta con tratar el movimiento del contenedor como un proceso, por lo que se utilizaría una tarjeta de

producción. Lo podemos ver en la siguiente figura, en la que también se muestra que un sistema Kanban con

una tarjeta de producción es equivalente a un sistema de producción en serie con bloqueo, ver figura 2-6,

(Hopp y Spearman, 2004).

Figura 2-6: Equivalencia del sistema Kanban de una y dos tarjetas. Hopp y Spearman (2004).

En este caso, el contenedor para empezar a ser procesado necesita una tarjeta de producción. Una vez se le ha

asignado la tarjeta, se realiza el proceso que indica y pasará a la cola del siguiente, siempre con la tarjeta

adjunta, hasta que el siguiente proceso tenga una tarjeta libre. Entonces devolverá la tarjeta del proceso

anterior y se le adjuntará la de este.

Al establecer un sistema de control Kanban es necesario determinar la cantidad de tarjetas Kanban requeridas.

Para calcularlas se parte de las siguientes magnitudes:

• Q: Consumo medio previsto del material por unidad de tiempo (por ejemplo, número de piezas por

día).

• LT: Tiempo de entrega total de suministro del material que figura en cada tarjeta, desde que se solicita

y se envía vacío al proceso anterior, hasta que se recibe lleno, pasando por el periodo de producción o

suministro dentro del proceso anterior. La unidad de medida del tiempo LT será la utilizada para Q.

• q: Cantidad de material asociado a cada tarjeta, reunido en un recipiente (por ejemplo, un contenedor).

• K: Cantidad total de tarjetas Kanban que podrán existir entre las de tipo transporte y las de

Sistemas pull

8

producción. La distribución entre ellas dependerá del proceso (si hay o no producción en el proceso al

que se solicita material), el número de componentes y productos procesados y las cantidades que

figuren en las tarjetas.

Es evidente que debe cumplirse que:

𝐾 =𝑄 × 𝐿𝑇

𝑞

Si se considera la existencia de un stock de seguridad SE, este stock dará lugar a una cantidad adicional de

tarjetas:

𝐾𝑒 =𝑆𝐸

𝑞

que en caso de que se exprese como un porcentaje sobre el número de tarjetas calculadas anteriormente, a

través de un coeficiente μ será:

𝐾𝑒 = 𝜇 × 𝑄 × 𝐿𝑇

𝑞

El total de tarjetas necesarias será pues:

𝐾𝑇 = 𝐾 + 𝐾𝑒 = 𝑄 × 𝐿𝑇 × (1 + 𝜇 )

𝑞

Evidentemente, la cantidad de producto en curso dependerá de la cantidad de tarjetas que existan en los

casilleros, de forma que cuando no haya ninguna tarjeta, la cantidad de producto en curso será la máxima

posible.

Por otra parte, se observa que para reducir el producto en curso WIP debe actuarse sobre el lead time LT o

sobre el stock de seguridad SE (o lo que es lo mismo, sobre μ), de forma que cuanto más se reduzcan, menor

podrá ser dicho stock. Como esto es altamente deseable, convendrá tener en cuenta cómo reducir los tiempos y

la seguridad al mínimo.

Esta fórmula es útil, pero en la práctica se suele preferir comenzar el proceso con suficiente número de tarjetas,

y sentirse cómodos, de forma que se pueda hacer frente a cualquier incertidumbre. Es una buena forma de

empezar a implantar el método siempre que no permanezca esa comodidad mucho tiempo. Se necesita ir

reduciendo el inventario para que se expongan los problemas y se solucionen lo más pronto posible (Chapman,

2006, Cuatrecasas, 2011).

Hay varias cosas a tener en cuenta respecto a los sistemas Kanban, que son (Thürer et al, 2016, Heizer y

Render, 2008):

• Cada paso de ruta tiene que ser representado por un bucle Kanban. Esto significa que la variabilidad

de ruta debe ser baja para evitar un gran número de bucles superpuestos que de otro modo serían

engorrosos para controlar.


• Los sistemas Kanban en cuanto al problema de control de inventarios, son muy efectivos si las

estaciones están desacopladas. Sin embargo, para el control de pedidos surgen varios problemas. Por

ejemplo, la última estación que se utiliza para controlar el proceso requiere el mayor número de

kanbans, y los kanbans permanecen en cada bucle, dificultando la propagación de la información

específica del pedido.

• Los contenedores suelen ser muy pequeños, normalmente representan el trabajo de unas pocas horas

de producción.

• Un sistema como éste requiere una programación muy ajustada.

• Hay que producir pequeñas cantidades varias veces al día.

• El proceso debe funcionar con suavidad, con poca variabilidad en el plazo de producción o

aprovisionamiento, porque cualquier falta de suministros tiene una repercusión casi inmediata en todo

el sistema.

• El Kanban pone mayor énfasis en cumplir la programación, en reducir el tiempo y el coste de las

preparaciones o cambios en las máquinas y en una manipulación económica de los materiales.

2.2 Sistema ConWIP

Mark L. Spearman, Wallace J. Hopp y David L. Woodruff desarrollaron ConWIP como una alternativa a los

sistemas Kanban. Es el sistema de control de producción basado en tarjetas más simple que se va a considerar.

El procedimiento de ConWIP es sencillo, se libera una orden para una línea de producción tan pronto como el

WIP de la línea de producción cae por debajo de un límite WIP. Ver figura 2-7.

Figura 2-7: Sistema ConWIP. Thürer et al (2016).

La siguiente orden en entrar en el proceso es la que tenga la prioridad más alta en la lista de liberación. Esta

lista contiene todos los pedidos que aún no han sido liberados y cuya fecha de inicio planificada está dentro de

una ventana de liberación anticipada ya definida. Esta ventana de liberación anticipada determina cuanto

tiempo antes se puede liberar una orden para la producción antes de que se haya alcanzado la fecha de inicio

planificada real.

La condición para ser incluida en la lista de liberación es:

𝑇𝑃𝐿0 + 𝐴𝑅𝑊 ≥ 𝐷𝑃𝑆

Donde,

𝑇𝑃𝐿0 es el punto de tiempo de planificación (SCD = Shop Calendar Day)

Sistemas pull

10

ARW es la ventana de liberación anticipada (SCD)

DPS es la fecha de inicio planificada de la orden (SCD)

Si para controlar el WIP en la producción nos basamos en el número de ordenes como unidad de medida,

tenemos que tener en cuenta que la terminación de una orden es señalada por la última a la primera estación en

la línea usando una tarjeta y se deben cumplir estas condiciones:

1. No se permite que una orden sea lanzada a la producción sin una tarjeta ConWIP adjunta.

2. La tarjeta permanece con la orden durante todo su procesamiento en la línea de producción.

3. Una vez completada la orden, se libera la tarjeta ConWIP y se autoriza el comienzo de otra orden.

El parámetro más importante para ConWIP es el número de tarjetas ConWIP que controlan el WIP en la línea

de producción y por lo tanto también los tiempos de procesamiento de pedidos.

El procedimiento consiste en derivar el número de tarjetas ConWIP de acuerdo con la ecuación, que se va a

ver a continuación, de los tiempos de producción previstos de la línea de producción. Cuando la producción

tiene un backlog/retraso, el número resultante de tarjetas ConWIP es por lo tanto más bajo que la

recomendación anterior, si las órdenes hasta ahora fueron liberadas según las fechas de vencimiento.

Es muy importante alinear los parámetros de los métodos de planificación de nivel superior con el número de

tarjetas ConWIP. Esto se aplica en particular para los tiempos de producción previstos, que son utilizados por

casi todos los métodos generadores de orden general para establecer los parámetros del método. Sólo cuando

los tiempos de producción previstos se acoplan con el número de tarjetas ConWIP, una empresa puede agotar

las ventajas de una reducción WIP en la producción.

Los tiempos de producción previstos de una ley de producción pueden determinarse generalmente de acuerdo

con la Ley de Little:

𝑇𝑇𝑃𝑚,𝑝𝑙𝑎𝑛

𝑁𝑜𝐶𝑂𝑁𝑊𝐼𝑃

𝑅𝑂𝑈𝑇𝑚,𝑝𝑙𝑎𝑛

Dónde,

TTPm,plan Tiempo medio de procesamiento planificado [SCD = Shop Calendar Day],

NoCONWIP Número de tarjetas CONWIP [-],

ROUTm,plan Tasa media de producción planificada [-/ SCD].

Encontramos dos diferencias entre los sistemas Kanban y ConWIP:

1. ConWIP se aplica a una sola línea y no para enlazar diferentes líneas. Por lo tanto, la señal no

comienza desde una línea posterior sino desde la última estación de la misma línea.

2. ConWIP utiliza tarjetas de trabajo anónimas. En Kanban se indica el tipo de trabajo que se debe hacer,

sin embargo, en este caso, indica que se puede iniciar un trabajo sin especificar cuál.

Factores a tener en cuenta en los sistemas ConWIP (Thürer et al, 2016, Lödding, 2013):

• Sólo hay un bucle, por lo que, todos los trabajos entran en la misma estación y salen de la misma

estación. No se debe dividir el flujo y no debe haber gran número de estaciones en el bucle. ConWIP

fundamentalmente sólo se aplica en procesos de flujo puro, donde todos los trabajos visitan todas las

estaciones en la misma secuencia.

• ConWIP sólo se aplica al problema de control de pedido, ya que para el problema de control de

inventario se necesitaría que las estaciones estuvieran desacopladas, es decir, limitar el trabajo en


proceso para cada estación y ConWIP sólo proporciona un límite para el conjunto del proceso.

• No causa ningún WIP bloqueado en el procesamiento de pedidos en la producción.

2.3 Sistema POLCA

Suri (1998) fue el primero en presentar el POLCA antes de ser extendido posteriormente por autores como

Vandaele et al. (2008) y Riezebos (2010). Se argumentó que POLCA era una alternativa al Kanban

específicamente para el contexto de la Fabricación de Respuesta Rápida o la competencia basada en el tiempo

(Suri, 1998). La diferencia con los sistemas de control basados en tarjetas aquí estudiados es que combina un

componente basado en tarjetas con un sistema de planificación de necesidades materiales (MRP). Por lo tanto,

se describe como un sistema push / pull.

A cada par de células de fabricación se le asigna tarjetas POLCA para controlar el WIP, éstas giran entre las

células de fabricación y autorizan la producción de pedidos. Además, POLCA lanza los pedidos de acuerdo a

las fechas de vencimiento: una célula de fabricación sólo puede procesar un pedido cuando se ha superado la

fecha de liberación asignada.

La implementación de POLCA se basa en tres elementos:

• Lista de lanzamiento: La lista contiene todas las órdenes que se pueden liberar.

• Tarjetas POLCA (ver figura 2-8): Una tarjeta POLCA siempre está asignada a un par específico de

celdas de fabricación. Información que contienen:

o Las abreviaturas de las células de fabricación.

o El número de tarjeta, así se facilita el control del número de tarjetas POLCA.

o La autorización del procesamiento de una orden designada a una celda de destino específica

en la célula de origen.

• Fecha de lanzamiento: Se permite que una célula de fabricación procese una orden sólo cuando se ha

alcanzado o superado la fecha de liberación.

Figura 2-8: Tarjeta POLCA. Lödding (2013).

La literatura POLCA se refiere a células, pero sólo es cuestión de nivel de análisis, así que, para mantener la

consistencia en todo el documento, nos referiremos a estaciones.

Para aclarar el funcionamiento de POLCA, vamos a considerar una orden que se mueve de la estación A a la B

y de esta, a la estación C. Cuando la orden llega a la estación A, para iniciar el proceso, se deben cumplir tres

condiciones:

1. La estación A debe estar disponible.

2. Se debe haber alcanzado la fecha de lanzamiento más temprana para la estación A.

Sistemas pull

12

3. La tarjeta POLCA A-B (tarjeta que circula entre las estaciones A y B) debe estar disponible,

indicando la futura disponibilidad en la estación B.

Cumplidas estas condiciones, se adjunta la tarjeta A-B a la orden y empieza a procesarse en la estación A. De

ahí, se mueve a la estación B manteniéndose unida la tarjeta A-B a la orden. Ahora, deben volver a cumplirse

las tres condiciones anteriores, cambiando A por B y B por C en el nombre de las estaciones. Por lo tanto, en

este momento, la orden tiene adjunta las tarjetas A-B y B-C. Una vez se termina el proceso en B, la tarjeta A-B

es liberada y la orden se mueve a la estación C. El proceso seguiría así sucesivamente, hasta llegar a la última

estación, en nuestro caso la C, donde la última condición de las citadas anteriormente, como es evidente, no se

tendría en cuenta al no haber una estación futura. Ver figura 2-9.

Figura 2-9: Sistema POLCA. Thürer et al (2016).

Se puede observar que el sistema POLCA es equivalente al sistema Kanban, donde hay principalmente, sólo

dos diferencias:

1. En POLCA la tarjeta A-B permanece con la orden hasta que es procesada en B, mientras que, en

Kanban, la tarjeta es liberada tan pronto como comienza el proceso en B. De ahí, que POLCA se

refiera a bucles superpuestos.

2. Las tarjetas POLCA son anónimas como ocurría en CONWIP.

Los parámetros esenciales de POLCA son el número de tarjetas POLCA y la fecha de lanzamiento de las

órdenes de trabajo en las celdas de fabricación.

Para el número de tarjetas, Suri menciona la siguiente ecuación que se basa en la Ley de Little, para dos celdas

de fabricación i y j:

𝑁𝑃𝐶𝑖𝑗 = (𝑇𝑇𝑃𝑚,𝑖 + 𝑇𝑇𝑃𝑚,𝑗) ×𝑁𝑂𝑖𝑗

𝑃

Dónde,

NPCij Número de tarjetas POLCA con celda i como célula de origen y celda j como célula de destino [-],

TTPm,i Tiempo de rendimiento medio de la célula i (originadora) [SCD = Shop Calendar Day],

NOij Número de órdenes que fluyen a través de las Células i y j consecutivamente durante el período P [-],

P Longitud del período de referencia [SCD].


Características de POLCA:

• El WIP se limita por el número de tarjetas POLCA.

• Cada paso de ruta tiene que ser representado por un bucle POLCA. Esto significa que la variabilidad

de ruta debe ser baja para que POLCA sea eficaz. Además, POLCA puede conducir al bloqueo si hay

bucles de retroalimentación en la ruta. Por lo tanto, los sistemas POLCA sólo deben aplicarse a

procesos con rutas simples y dirigidas.

• POLCA al usar tarjetas de trabajo anónimas, trata el problema de control de pedidos como un

problema de control de inventarios. El flujo de trabajo es tratado por el sistema MRP. Si bien esto

hace que POLCA trate mejor el problema de control de pedidos que los sistemas Kanban, introduce

las debilidades de un sistema MRP y puede conducir al bloqueo.

Hay que destacar el problema de bloqueo, que se le va a denominar bloqueo cruzado, que ocurre en POLCA,

si hubiera bucles de retroalimentación en el proceso. Por ejemplo, una estación puede no ser capaz de iniciar el

trabajo ya que requiere una tarjeta de otra estación, que a su vez necesita una tarjeta de esta estación. Ver

figura 2-10.

Figura 2-10: Sistema POLCA bloqueado. Thürer et al (2016).

Una solución a este comportamiento de bloqueo sugerido por Harrod y Kanet (2013) es el uso de las llamadas

tarjetas de seguridad que están disponibles para cualquier trabajo. Sin embargo, un sistema POLCA sólo puede

funcionar adecuadamente cuando el número de tarjetas de seguridad es limitado (Riezebos, 2010, Thürer et al,

2016, Heizer y Render, 2008).

15

ARENA

rena es el programa que se ha utilizado para la simulación de los sistemas de control de producción

basados en tarjetas estudiados en este proyecto. Se va a explicar los módulos lógicos que se han

aplicado para su realización, diferenciando entre los del panel de procesos básicos, los del panel de

procesos avanzados y los del panel de trasferencia avanzada. En los diferentes paneles se encuentra tanto

módulos de diagrama de flujo como módulos de datos. Para el desarrollo de esta sección se ha consultado la

guía Arena.

Los módulos de diagrama de flujo son el conjunto de objetos que se colocan en la ventana del modelo para

describir el proceso de simulación.

Los módulos de datos son el conjunto de objetos en la vista de hojas de cálculo del modelo que definen las

características de varios elementos del proceso, como recursos y colas.

3.1 Panel de procesos básicos

3.1.1 Módulos de diagramas de flujo

• Create: Este módulo está destinado a ser el punto de partida para entidades en un modelo de

simulación. Las entidades se crean utilizando un horario o se basan en un tiempo entre llegadas. Las

entidades dejan el módulo para comenzar a procesar a través del sistema. El tipo de entidad se

especifica en este módulo. En la parte inferior derecha del módulo se indica el número de entidades

que se han creado. Ver figura 3-1.

Figura 3-1: Módulo Create.

A

Arena

16

Parámetros:

o Name: Nombre que se le da para identificar al módulo, debe ser único.

o Entity type: Nombre del tipo de entidad que se generará.

o Type: Tipo de flujo de llegada que se generará. Puede ser Random, Schedule, Constant o

Expression. En este proyecto se ha hecho uso de Expression, en el que se puede elegir entre

distintas distribuciones y Constant, para especificar un valor constante.

o Value: Aparece en el caso de seleccionar Constant, ahí se indica el valor constante para el

tiempo entre llegadas.

o Expression: Cualquier distribución o valor que especifique el tiempo entre llegadas. En los

casos estudiados se ha empleado la normal, en la que hay que indicar la media y la desviación

típica.

o Units: Unidades de tiempo que se usa para los tiempos entre llegada y la primera creación.

o Entities per arrival: Número de entidades que entrarán al sistema con cada llegada.

o Max arrivals: Número máximo de entidades que generará este módulo.

o First creation: Momento en el que la primera entidad llega al sistema.

• Dispose: Último módulo por el que pasan las entidades en un modelo de simulación. Las estadísticas

de la entidad pueden registrarse antes de que la entidad sea eliminada. Ver figura 3-2.

Figura 3-2: Módulo Dispose.

Parámetros:


o Record entity statistics: Se activará si se quiere registrar las estadísticas de las entidades.

• Process: Este módulo corresponde a la principal forma de procesamiento en simulación. Ver figura 3-

3.


Figura 3-3: Módulo Process.

Parámetros:


o Type: Método que especifica la lógica dentro del módulo. Se puede seleccionar Standard o

Submodel, para este caso particular, todos van a ser de tipo Standard. El procesamiento

Standard significa que toda la lógica será almacenada dentro del módulo process y definida

por una acción particular.

o Action: Tipo de proceso que ocurrirá una vez la entidad entre en el módulo. Hay cuatro tipos:

Delay, Seize Delay, Seize Delay Release y Delay Release. Se explican los usados en el

presente proyecto:

Seize Delay: A la entidad se le asignará un recurso y sufrirá un retardo, no liberará el

recurso. La liberación será más tarde, haciendo uso de un módulo denominado

Release que está explicado en los módulos del panel de proceso avanzado.

Seize Delay Release: A la entidad se le asignará un recurso, sufrirá un retardo y

posteriormente, liberará el recurso reservado.

En la figura 3-3 aparece el Seize Delay Release, pero en ambas aparecen los mismos

parámetros a rellenar, que son los que se explican a continuación.

o Priority: Valor de prioridad de la entidad que espera en este módulo para el recurso

especificado si una o más entidades están esperando el mismo recurso en cualquier parte del

modelo.

o Resources: Aquí podemos añadir una lista de recursos o conjuntos de recursos que serán

utilizados para procesar la entidad. Al añadir un recurso nos aparece un cuadro de diálogo

(Ver figura 3-4) con los siguientes parámetros:

Type: Especificación de un recurso particular, o la selección de un conjunto de

recursos. En este caso concreto, añadiremos solo recursos particulares.

Resource name: Nombre que se le va a dar al recurso.

Arena

18

Quantity: Cantidad de recursos.

Figura 3-4: Cuadro de dialogo de Resources en módulo Process.

o Delay Type: Tipo de distribución o método que especifica los parámetros de retardo. Las

opciones son Constant, Expression, Normal, Uniform y Triangular. Las dos primeras que son

las necesarias para las simulaciones realizadas, y sus parámetros son:

Value: este parámetro en caso de ser Constant es para especificar el valor de un

retraso de tiempo constante y si es Normal, para indicar la media de esta distribución.

Std Dev: En ese campo, se establece la desviación típica de la distribución Normal.

o Units: Unidades de tiempo para los parámetros de retardo.

o Allocation: determina cómo se asigna el tiempo de proceso y el coste del proceso a la entidad.

• Decide: Este módulo permite la toma de decisiones en el sistema. Las decisiones pueden ser basadas

en una o más probabilidades o en una o más condiciones. Ver figura 3-5.

Figura 3-5: Módulo Decide.


Figura 3-6: Cuadro de diálogo de Decide seleccionando Variable.

Parámetros:


o Type: Se puede seleccionar, 2-way by Chance, 2-way by Condition, N-way by Chance y N-

way by Condition. Con los dos primeros, hay dos salidas del módulo, verdadera o falsa. En

los dos últimos casos, habría múltiples salidas. En este caso se ha hecho uso de 2-way by

Condition y N-way by Condition, donde los parámetros que piden son:

If: Se selecciona el tipo de condición, ya sea, Variable, Attribute, Entity type o

Expression. En el caso de elegir 2-way by Condition se seleccionará Expression o

Variable. Seleccionando Expression el último parámetro a completar sería el valor de

la expresión que se debe cumplir para que sea verdadero (ver figura 3-5), en caso

contrario, sería falso. Si seleccionas Variable (ver figura 3-6) aparecen una serie de

parámetros a rellenar explicados a continuación. Si la elección es N-way by

condition (ver figura 3-7), aparecerá este parámetro al añadir condiciones, que se

añaden tantas como ramas menos una se quieran, ya que hay que tener en cuenta la

rama de falso, es decir cuando ninguna de las condiciones verdaderas se cumple.

Para este caso concreto, en este proyecto, se seleccionará Attribute.

Named: Especifica el nombre del atributo que se evaluará cuando una entidad entre

en el módulo.

Is: Evaluador de la condición.

Value: Expresión que se comparará con un atributo para determinar si es verdadero o

falso.

Figura 3-7: Cuadro de diálogo para añadir condiciones si es N-way by condition.

• Assign: La función de este módulo es asignar nuevos valores a las variables, a los atributos de las

entidades, tipos de entidades, ilustraciones de las entidades u otras variables del sistema. Se pueden

realizar múltiples asignaciones con un único módulo Assign. Ver figura 3-8.

Arena

20

Figura 3-8: Módulo Assign.

Parámetros:


o Assignments: Especifica las asignaciones que se harán cuando la entidad ejecute el módulo.

Para añadir una asignación, se presiona add y nos aparecerá un cuadro de diálogo (ver figura

3-9) con los siguientes parámetros para completar:

Type: Tipo de asignación que se hará. Para el caso en estudio se ha empleado

Attribute, Variable y Other, se explica a continuación los parámetros a completar.

Attribute name: Nombre del atributo de la entidad al que se le asignará un nuevo

valor cuando la entidad entre al módulo. Este parámetro aparece en caso de

seleccionar Attibute.

Variable name: Nombre de la variable que se le asignará un nuevo valor cuando la

entidad entre al módulo.

Other: Identifica la variable del sistema especial al que se le asignará un nuevo valor

cuando la entidad entre al módulo.

New value: Valor asignado al atributo, variable u otra variable del sistema. Este

parámetro aparece en todos los usados en este proyecto.

Figura 3-9: Cuadro de diálogo de Assignments.


• Record: Este módulo se utiliza para recopilar estadísticas en el modelo de simulación. Ver figura 3-10.

Figura 3-10: Módulo Record.

Parámetros:


o Type: Tipo de estadística observacional o estadística de recuento a generar. Puede ser: Count,

Entity Statistics, Time Interval, Time Between y Expression. En este caso se ha hecho uso de

Time Interval y Expression, los parámetros a rellenar serían:

Attribute name: Nombre del atributo cuyo valor se usará para las estadísticas de

intervalo. En caso de seleccionar Time Interval.

Value: Valor que se registrará en la estadística de observación. Cuando el tipo es

Expression.

Tally name: Define el nombre de la cuenta en la que se va a registrar la observación.

Record into Set: Casilla de verificación para especificar si se utilizará o no un

conjunto de contadores.

3.1.2 Módulos de datos

• Entity module: este módulo de datos define los diversos tipos de entidades y sus valores de imagen

iniciales en una simulación. La información de costo inicial y los costos de mantenimiento también se

definen para la entidad. Ver figura 3-11.

Figura 3-11: Módulo de datos Entity.

Arena

22

Parámetros:

o Entity Type: el nombre del tipo de entidad que se define. Este nombre debe ser único.

o Initial Picture: Representación gráfica de la entidad al inicio de la simulación. este valor se

puede cambiar durante la simulación usando el módulo Assign.

• Queue module: este módulo de datos se puede utilizar para cambiar la regla de clasificación para la

cola especificada. La regla de clasificación predeterminada para todas las colas es First In, First Out a

menos que se especifique lo contrario en este módulo. Hay un campo adicional que permite que la

cola se defina como compartida. Ver figura 3-12.

Figura 3-12: Módulo de datos Queue.

Parámetros:

o Name: el nombre de la cola cuyas características se están definiendo. Este nombre debe ser

único.

o Type: regla de clasificación para la cola, que puede basarse en un atributo. Los tipos son:

First In, First Out; Last In, First Out; Lowest Attibute Value (first); and Highest Attibute

Value (first). Para este proyecto, solo se hace uso de la que viene por defecto, First In, First

Out.

o Report Statistics: especifica si las estadísticas se recopilarán automáticamente o no y se

almacenarán en la base de datos del informe para esta cola.

• Resource module: este módulo de datos define los recursos en el sistema de simulación, incluida la

información de costos y la disponibilidad de recursos. Los recursos pueden tener una capacidad fija

que no varíe durante la ejecución de simulación o que pueda funcionar según un calendario. Los fallos

de recursos y los estados también se pueden especificar en este módulo. Ver figura 3-13.

Figura 3-13: Módulo de datos Resource.

Parámetros:

o Name: el nombre del recurso cuyas características se están definiendo. Este nombre debe ser

único.

o Type: método para determinar la capacidad de un recurso. Fixed Capacity no cambiará

durante la ejecución de la simulación. Base on Schedule significa que un module Schedule se

usa para especificar la información de capacidad y duración del recurso. En este caso, todos

serán Fixed Capacity.


o Capacity: número de unidades de recursos de un nombre dado que están disponibles para el

sistema para su procesamiento. Se aplica solo cuando el tipo es Fixed Capacity.

o Report Statistics: especifica si las estadísticas se recopilarán automáticamente o no y se

almacenarán en la base de datos del informe para este recurso.

• Variable module: este módulo de datos se usa para definir la dimensión de una variable y el valor

inicial. Las variables se pueden referenciar en otros módulos (por ejemplo, en un module Decide), se

pueden reasignar a un nuevo valor con el module Assign y se pueden usar en cualquier expresión. Ver

figura 3-14.

Figura 3-14: Módulo de datos Variable.

Parámetros:

o Name: Nombre de la variable, debe ser único.

o Clear option: define el tiempo (si es que lo hace) cuando el valor de la variable se restablece

al valor inicial especificado. En el presente proyecto, se escoge siempre System, que indica

que esta variable debe volver a su valor inicial cada vez que se borre el sistema.

o Initial Values: Lista de los valores iniciales de la variable. Este valor puede ser cambiado con

un módulo Assign.

3.2 Panel de procesos avanzados


• Delay: Este módulo retrasa una entidad una cantidad de tiempo especificado. Ver figura 3-15.

Figura 3-15: Módulo Delay.

Arena

24

Parámetros:


o Allocation: Tipo de categoría a la que se sumará el tiempo y el costo de demora de la entidad.

o Delay time: Determina el valor de demora para la entidad.

o Units: Unidades de tiempo para el tiempo de demora.

• Hold: Este módulo mantendrá una entidad en una cola a la espera de una señal, el cumplimiento de

una condición o será detenida indefinidamente. Ver figura 3-16.

Figura 3-16: Módulo Hold.

Parámetros:


o Type: Indica el razonamiento para mantener a la entidad en una cola específica o interna. Si

se escoge Wait for a Signal esperará a que le llegue una señal del mismo valor de un módulo

Signal, que se encontrará en algún lugar del modelo, para continuar al siguiente modulo. En

el caso de elegir Scan for Condition mantendrá la entidad hasta que una condición especifica

se cumpla. Y si la elección es Infinite Hold la entidad permanecerá en la cola hasta que sea

eliminada por un módulo Remove, el cual se encontrará en alguna parte del modelo. Los

parámetros que interesan, debido al alcance de este proyecto, son los de Wait for a Signal y

Scan for Condition.

o Wait for Value: Señal para la entidad en espera. Se aplica solo cuando es Wait for a Signal.

o Limit: Número máximo de entidades que serán liberadas al recibir la señal. Se aplica solo

cuando es Wait for Signal.

o Condition: Especifica la condición que se evaluará para mantener a la entidad en el módulo.

Si la condición es verdadera, la entidad dejará el módulo inmediatamente. En caso de ser

falsa, la entidad esperará en la cola asociada hasta que sea verdadera. Se aplica solo cuando es

Scan for Condition.


o Queue Type: Determina el tipo de cola que se usa para mantener la entidad. Se puede elegir

entre Queue, Set, Internal, Attribute y Expression. En este caso para todos los módulos Hold

de las simulaciones se ha seleccionado Queue.

o Queue name: Aparece este campo al haber seleccionado anteriormente Queue, y define el

nombre de la cola.

• Release: Este módulo se usa para liberar unidades de un recurso que una entidad había tomado

previamente. Puede utilizarse para liberar recursos individuales o conjunto de recursos. Ver figura 3-

17.

Figura 3-17: Módulo Release.

Parámetros:


o Resources: Aquí se ponen los recursos a liberar. Se añaden mediante el botón Add. Entonces

aparece otro cuadro de diálogo (ver figura 3-) con los siguientes parámetros:

Type: Tipo de recurso para liberar. Pueden ser Resource, Set, Attribute, Expression.

Para este proyecto siempre se seleccionará Resource.

Resource name: Nombre del recurso que será liberado.

Quantity: Numero de recursos de un nombre dado que serán liberados.

Arena

26

Figura 3-18: Cuadro de diálogo de Resources en módulo Release.

• Signal: Este módulo envía la señal a cada módulo Hold que esté configurado con Wait for a Signal y

libera el máximo número especificado de entidades. Ver figura 3-19.

Figura 3-19: Módulo Signal.

Parámetros:


o Signal Value: Valor de la señal que se envía a las entidades en los módulos Hold.

o Limit: Máximo número de entidades que son liberadas de cualquier módulo Hold cuando

reciben la señal.


• Advanced Set: el módulo Advanced Set especifica los conjuntos de colas, los conjuntos de

almacenamiento y otros conjuntos y sus respectivos miembros. Un conjunto define un grupo de

elementos similares que pueden referenciarse mediante un nombre común y un índice establecido.

Los elementos que componen el conjunto se conocen como los miembros del conjunto. Ver figura 3-

20.


Figura 3-20: Módulo de datos Advanced Set.

Parámetros:

o Name: el nombre del Advanced Set cuyos miembros se están definiendo. Este nombre debe

ser único.

o Set Type: Tipo de conjunto que se está definiendo, que puede incluir: Queue, Storage u

Other. Para el caso que se estudia, se elige Other.

o Other: nombre de los miembros que están incluidos dentro del tipo de conjunto “other”.

3.3 Panel de transferencia avanzada


• Route: Este módulo transfiere una entidad a una estación especificada o a la siguiente estación

definida por una secuencia de visitas para la entidad. Se puede definir un tiempo de retardo para

transferir a la siguiente estación. Ver figura 3-21.

Figura 3-21: Módulo Route.

Parámetros:


o Route Time: Tiempo de viaje desde la ubicación actual de la entidad a la estación de destino.

o Units: Unidades de tiempo para el parámetro Route Time.

o Destination type: Método para determinar el destino de la entidad. Se puede seleccionar

Station, Sequential, Attribute y Expression. Si es por secuencia, se requiere que a la entidad

Arena

28

se le haya asignado una secuencia y que esa secuencia haya sido definida. Para las

simulaciones realizadas se hace uso de Station y Sequential.

o Station name: Nombre de la estación de destino. En caso de elegir Station.

• Station: Este módulo define una ubicación donde se produce el procesamiento. Se usa por la claridad

que le da al modelo al separar ciertos procesos y hace más fácil su manejo. Ver figura 3-22.

Figura 3-22: Módulo Station.

Parámetros:


o Station Type: Tipo de estación que se define, puede ser individual o un conjunto, para el caso

en el que se centra este proyecto solo se definen individuales.

o Station Name: Nombre de la estación individual.

o Parent Activity Area: Nombre del área de actividad.

o Repor Statistics: Casilla de verificación que especifica si las estadísticas se recopilarán

automáticamente y se almacenarán en la base de datos del informe para esta estación y su

área de actividad correspondiente.


• Sequence: el módulo de sequence se usa para definir una secuencia para el flujo de entidad a través

del modelo. Una secuencia consiste en una lista ordenada de estaciones que una entidad visitará. Para

cada estación en la secuencia de visitas, atributos y variables pueden tener valores asignados. Ver

figura 3-23.


Figura 3-23: Módulo de datos Sequence.

Parámetros:

o Name: Nombre de la secuencia.

o Steps: grupo de repetición que define la lista ordenada de estaciones que una entidad visita

para la secuencia nombrada, así como las asignaciones de atributos y variables que se

realizarán en cada una de las estaciones en la secuencia.

o Station Name: Nombre de la siguiente estación en la secuencia de visitas.

31

MODELOS

a simulación realizada se ha hecho para un solo tipo de producto, ya que Kanban no utiliza tarjetas de

trabajo anónimas, como ConWIP y POLCA, que en lugar de indicar que se puede iniciar un

determinado trabajo, indica que se puede iniciar un trabajo. Esto priva a las tarjetas de una de sus

funciones principales en un sistema Kanban, indicando que trabajo hacer primero, e introduce la necesidad de

otro medio de priorización. Por tanto, para el caso de varios tipos de producto, la simulación sería distinta para

Kanban. La configuración de los sistemas será de una línea de producción simple de tres estaciones en serie.

En todos los sistemas se ha hecho uso del mismo número de tarjetas para poder comparar el rendimiento al

mismo nivel de WIP, de manera que se ha escogido 6 tarjetas por sistema, dónde en ConWIP se adjudica una

al principio del proceso y la orden de trabajo la mantiene hasta el final, en Kanban se diferencian por

estaciones, por lo tanto, se hará uso de 2 en cada estación y en POLCA al tener cada dos estaciones una tarjeta,

solo se tiene dos tipos, y se adjudican 3 a cada tipo.

Por otra parte, hay que indicar que se han empleado distribuciones normales y se ha trabajado en minutos. La

duración de la simulación es de 960 minutos, es decir, dos turnos de trabajo de 8 horas, teniendo en cuenta un

tiempo de calentamiento de 4 horas. Salvo para el modelo con secuencia de producción, en el cual no se

pondrá tiempo de calentamiento, ya que lo que se quiere es ver es el bloqueo y el empleo de tarjetas de

seguridad.

También, hay que decir, que en este caso se ha supuesto que las órdenes de trabajo llegan ya con la prioridad

que les corresponde.

A continuación, se explican los detalles más importantes para entender cómo funcionan los sistemas, los

modelos completos se encuentran en el Anexo.

4.1 Modelo sistema Kanban

El modelo de Kanban comienza con una estación de llegada, una vez sale la orden de trabajo de esta estación,

empieza su trayectoria en serie por tres estaciones A, B y C, de ahí, irá a la salida. Mediante el Create se

modifica la variabilidad y congestión, mediante la desviación típica y la media de la distribución normal

respectivamente, de la llegada de órdenes de trabajo. En la figura 4-1 se puede observar cómo se modela la

llegada y el cuadro de diálogo del Create.

L

Modelos

32

Figura 4-1: Llegada sistema Kanban.

Para la trayectoria en serie, en el Route (ver figura 4-2) se indica la siguiente estación a la que debe ir, como se

ha dicho la trayectoria será siempre A-B-C-Salida, por tanto, en el Route de la entrada se indica la primera

estación. En los siguientes Routes se pondrá la estación siguiente que se va a visitar.

Figura 4-2: Route para inicio de secuencia única.

A continuación, en la figura 4-3 se muestra como comenzaría el recorrido por la estación A:

Figura 4-3: Modelado estación A.

En cada estación, lo primero que hay es un Dispatcher, que es un módulo Process (ver figura 4-4) que actúa

como lanzador de órdenes de trabajo, donde éstas se acumularán esperando que se cumplan las condiciones

necesarias para continuar el proceso. Estas condiciones se indican en el módulo Hold (ver figura 4-5), en este

caso llamado Bloquear 1, y son las dos siguientes:

• El número de tarjetas Kanban tiene que ser mayor que cero. Para el número de tarjetas se han creado

tres variables llamadas: tarjetas Kanban A, tarjetas Kanban B y tarjetas Kanban C, con dos tarjetas

cada tipo, como se indicó anteriormente.

• La máquina debe estar libre.


En caso de que algunas de las condiciones no las cumpla, se mantendrá ahí bloqueada hasta cumplirlas.

Figura 4-4: Dispatcher.

Figura 4-5: Condición de bloqueo para sistema Kanban.

Una vez cumplidas, podrá empezar su proceso. Lo primero es un módulo Assign (ver figura 4-6) que asigna

un tiempo de llegada TNOW, para luego al final del proceso mediante un módulo Record, poder contabilizar

el tiempo de ciclo medio. También se crea una variable llamada WIP que se incrementará cada vez que pase

una orden de trabajo y al salir del proceso esta variable decrementará. A la misma vez, a través de otro módulo

Assign (ver figura 4-7), se le adjudicará una tarjeta.

Modelos

34

Figura 4-6: Tiempo de llegada y WIP.

Figura 4-7: Asignar tarjeta Kanban A.

A continuación, por medio de un módulo Release (ver figura 4-8), se liberará el lanzador para poder pasar la

siguiente orden de trabajo. La orden de trabajo será procesada, en un módulo Process (ver figura 4-9), en el

cual, es donde se cambia la variabilidad y el equilibrado de las máquinas, en la desviación típica y en la media

de la distribución normal respectivamente.

Figura 4-8: Liberar lanzador 1.


Figura 4-9: Proceso máquinas tipo 1.

Finalmente, pasará a la siguiente estación. En las estaciones sucesivas, una vez cumpla las condiciones

necesarias para comenzar el proceso, devolverá la tarjeta (figura 4-10) del proceso anterior a la vez que se le

asigna la del proceso siguiente, como se puede observar en la figura 4-11 donde se muestra el modelado de la

estación B.

Figura 4-10: Devolver tarjeta Kanban A.

Figura 4-11: Modelado estación B.

En la última estación, la diferencia es que la tarjeta se devuelve una vez acaba el proceso, porque ya está

terminada la orden de trabajo y preparada para ir a la estación de salida.

Modelos

36

Justo antes de salir, como se comentó anteriormente, habrá un decremento del WIP y el módulo Record para

calcular el tiempo de ciclo promedio total. En la figura 4-12 se puede contemplar cómo se modela la salida del

sistema y el cuadro de diálogo del módulo Record.

Figura 4-12: Salida sistema Kanban.

Para poder calcular el WIP promedio, se hará uso de un Demonio (figura 4-13), donde se creará una entidad

para contar el WIP cada segundo de simulación y poder obtener luego la media. Se hace mediante un módulo

Record (figura 4-14) que contará el WIP cada vez que la entidad pase por él y un módulo Delay (figura 4-15),

que hará que la entidad tenga un retraso de un segundo para la siguiente medida.

Figura 4-13: Contador WIP.

Figura 4-14: Record para contar WIP.


Figura 4-15: Retraso para contar WIP cada segundo.

4.2 Modelo sistema ConWIP

En el caso de ConWIP la entrada es distinta, ya que las tarjetas se asignan al principio del proceso y no se

devuelven hasta el final. Por lo tanto, la condición se pone ahí como puede verse en la figura 4-16, después

será un simple proceso en serie de tres estaciones, como el que se muestra en la figura 4-17 de la estación A.

Figura 4-16: Llegada sistema ConWIP.

Figura 4-17: Estación A del sistema ConWIP.

Como en Kanban, lo primero que se encuentra una orden de trabajo es un Dispatcher, donde el funcionamiento

es el mismo que el explicado anteriormente. Para seguir el proceso es necesario que se cumpla una condición,

que se introduce mediante un módulo Decide (figura 4-18), esta es “la suma de las órdenes de trabajo que hay

entre la cola de los procesos y las que se están procesando, debe ser menor que el número de tarjetas que se

hayan adjudicado al sistema”.

Modelos

38

Figura 4-18: Condición de bloqueo para sistema ConWIP.

A continuación, si cumple la condición, se liberará el lanzador, se le adjudicará un tiempo de llegada, se

incrementará el WIP e iniciará la secuencia, de la misma forma que se hizo en Kanban.

En el caso de no cumplir la condición, se bloquearía, mediante un módulo Hold (figura 4-19). Para que se

desbloquee, habrá que esperar a que salga una orden de trabajo del proceso, entonces se enviará una señal

desde un módulo Signal (figura 4-20), que es lo mismo que devolver una tarjeta, por tanto, podrá empezar una

nueva orden el proceso.

Figura 4-19: Bloqueo órdenes de trabajo.

Figura 4-20: Salida sistema ConWIP.

La recopilación de datos mediante el módulo Record y el Demonio para contar el WIP, se hace de la misma

forma que en Kanban.


4.3 Modelo sistema POLCA

El modelo de Polca es muy similar al de Kanban, la diferencia que existe es por la forma en la que se usan las

tarjetas. En Polca las tarjetas se utilizan para dos estaciones. En este caso particular, que hay 3 estaciones, A, B

y C, se necesitan tarjetas para el proceso AB y para el proceso BC. Por lo cual se han creado dos variables

llamadas: tarjetas Polca AB y tarjetas Polca BC, cada una de ellas tendrán 3 unidades, por la explicación que

se dio al principio del capítulo. Las condiciones que se deben cumplir son:

• Estar disponible la tarjeta necesaria. Para estaciones intermedias, nuestro caso la B, deben estar

disponibles las tarjetas AB y BC para continuar. Para las estaciones inicial y final, sólo necesitan una

tarjeta.

• La máquina esté libre. En la estación final, la C, es la única condición, ya que la orden de trabajo ya

tendrá adjudicada la tarjeta desde el proceso anterior.

Se muestra, el modelo de la estación B en la figura 4-21, donde se puede observar que se le adjudica la tarjeta

BC antes de empezar el proceso y la tarjeta AB no se devuelve hasta que no lo ha realizado.

Figura 4-21: Estación B sistema POLCA.

El resto del modelo es el mismo que el explicado para Kanban.

4.4 Modelo con secuencia de producción

En los modelos con secuencia, va a ocurrir el bloqueo cruzado, que se explicó en el punto 2.3 de este proyecto.

Este bloqueo solo se produce en POLCA como se dice en el artículo de Thürer et al (2016), ya que, Kanban

las tarjetas van asociadas al tipo de producto y en ConWIP se hace uso de la misma tarjeta para todo el

sistema. El bloqueo en estos dos últimos casos solo ocurriría por la ocupación de una estación de trabajo

durante un tiempo de procesamiento muy alto.

Por consiguiente, se va a mostrar el modelo con secuencia para POLCA. Éste se usará para demostrar el

bloqueo cruzado y se propondrá una posible solución a este problema, todo ello en el punto 5.

En este caso, el número de tarjetas utilizadas también es 6 pero al ser secuencial, habrá tres tipos de tarjetas

(AB, BC, CA), acordes a las tres secuencias que se han definido (A-B-C-Salida, B-C-A-Salida, C-A-B-

Salida), y dos tarjetas para cada tipo.

A diferencia con el modelo de POLCA anterior, en este caso, hay que introducir la secuencia, al no ser siempre

la misma. Para ello, se hace uso de un módulo Assign al principio del modelo (figura 4-22), donde se

introducen dos atributos. Uno para indicar mediante una distribución discreta, el porcentaje de probabilidad de

cada tipo de secuencia, que se ha supuesto 45% para la primera, 35% para la segunda y 20% para la tercera

(figura 4-23). El segundo atributo para saber que secuencia seguir según el tipo (figura 4-24).

Modelos

40

Figura 4-22: Llegada sistema POLCA con secuencia.

Figura 4-23: Atributo tipo.

Figura 4-24: Atributo Entity.Sequence.

Para incluir las secuencias al modelo se hace mediante los módulos de datos, Advanced Set y Sequence. En

Advanced Set se especifica el número de secuencias. Luego en Sequence, para cada secuencia se le detalla el

recorrido a seguir de la orden de trabajo por el sistema. Como podemos observar en las figuras 4-25 y 4-26.


Figura 4-25: Advanced Set.

Figura 4-26: Sequence.

En este caso, el Route (figura 4-27) sería diferente al visto anteriormente, puesto que ahora hay tres recorridos

diferentes. Así que, se señalará que es de tipo de secuencial en todos los Routes del modelo.

Figura 4-27: Route secuencial.

A continuación, se va a mostrar el modelo de la estación A, ver figura 4-28. En este caso, hemos incluido un

módulo Decide (figura 4-29) para que según el tipo de secuencia que siga la orden de trabajo, vaya por una u

otra rama. Por consiguiente, habrá tantas ramas en el Decide, contando la salida falsa, como secuencias pasen

por esa estación.

Modelos

42

Figura 4-28: Estación A del modelo con secuencia.


Figura 4-29: Rama a seguir según el tipo.

Cada rama, define el modelo según el orden de la estación en una secuencia determinada, es decir, si actúa

como estación inicial, intermedia o final. Para cada rama, se modela exactamente igual que para un POLCA

sin secuencia.

En el caso de las estaciones B y C se hace de forma similar a la explicada.

La estación de salida se modela igual que para un POLCA sin secuencia.

45

DISCUSIÓN DE RESULTADOS

n este capítulo se van a analizar los resultados obtenidos mediante las simulaciones realizadas. En

primer lugar, un estudio comparativo de los tres sistemas de control de la producción basados en tarjetas

que se han explicado y, en segundo lugar, las propuestas de solución ante el bloqueo cruzado.

5.1 Estudio comparativo

Para realizar el estudio comparativo de los sistemas de control de la producción detallados anteriormente,

Kanban, ConWIP y POLCA, se hace uso de cuatro indicadores y tres factores.

Los cuatro indicadores (variables dependientes) son:

• Tiempo de ciclo promedio total: es el tiempo desde que la orden de trabajo empieza el proceso hasta

que termina.

• Tiempo de espera en cola: suma de todos los tiempos que la orden de trabajo está esperando en cada

cola durante el proceso.

• WIP promedio: número de unidades que se están procesando, promediadas a lo largo del tiempo de

simulación.

• Utilización: tiempo que está la máquina ocupada dividido entre el tiempo que está disponible, es decir,

porcentaje de uso que se le da a ésta.

Se tendrán tres factores (variables independientes) y la combinación entre ellos, da lugar a 8 escenarios

distintos. Los factores que se emplean son:

• Variabilidad: se estudia el comportamiento de los sistemas ante la baja y la alta variabilidad de la

llegada de las órdenes de trabajo y de los tiempos de proceso de las máquinas.

• Congestión: se estudia el comportamiento de los sistemas ante la baja y alta aglomeración de las

ordenes de trabajo en el sistema.

• Equilibrio: el sistema estará equilibrado cuando, sabiendo la duración del proceso en total, a cada

estación, se le adjudica el mismo tiempo para completar las operaciones que tiene asignadas. Se

comparará también el comportamiento ante sistemas desequilibrados, en los cuales las tareas

asignadas no tienen la misma duración para cada estación.

Se ha decidido usar estos factores como generalización de los predictores de tiempo de espera en cola, y por

tanto WIP (debido a la Ley de Little), para una única estación de trabajo. El tiempo de espera en cola se define

como el producto V·U·T, donde V representa la variabilidad en tiempos de proceso de las máquinas y tiempos

de llegadas de las unidades a la estación, U tiene una relación no lineal con el nivel de utilización y T se refiere

al propio tiempo de proceso.

Sin pérdida de generalidad, se han supuesto para los distintos factores los valores que se muestran en la

siguiente tabla 5-1:

E

Discusión de resultados

46

Tabla 5-1: Datos de los factores.

En base a esto, se han obtenido los resultados que se muestran en la tabla 5-3. En dicha tabla, para cada

escenario, se nombran los factores con B si se refiere a baja, con A si es a alta, seguido de la inicial v o c, de

variabilidad y congestion respectivamente. Para el equilibrado, se ha usado Eq si esta equilibrado y Nq en caso

contrario. Se resume en la siguiente tabla 5-2:

Tabla 5-2: Nomenclatura de los factores.


Tabla 5-3: Resultados de la simulación.


48

Se va a comenzar comentando como afectan los factores, usados para el estudio, a los resultados.

En primer lugar, la congestión. Para este factor, se observa que, con baja congestión, como son los escenarios

1, 2, 5 y 6, se obtiene un mejor rendimiento, ya que, con alta, escenarios 3, 4, 7 y 8, empeora el sistema,

aumentando la utilización, el WIP promedio, el tiempo de ciclo promedio total y el tiempo de espera en cola,

es decir, los cuatro indicadores en los que se basa este estudio.

El segundo lugar se tiene la variabilidad. En este caso, también empeora el rendimiento cuando ésta es alta,

escenarios 5, 6, 7 y 8, ya que, como se puede contemplar en la tabla de resultados, todos los factores aumentan

respecto a los escenarios de baja variabilidad como son el 1, 2, 3 y 4, exceptuando la utilización que la

variación es mínima, siendo mayor para estos últimos.

Por último, queda analizar el factor equilibrio. Respecto a esto se ve afectada la utilización de las estaciones,

de forma que aquella con menor tiempo de proceso cuando están desequilibradas, tiene menor utilización.

Además, se puede ver en los resultados, como predicen Hopp y Spearman (2011), que el desequilibrio ante

una variabilidad alta mejora el rendimiento, como se puede ver comparando los escenarios 5 y 6. Sin embargo,

con la congestión actúa de forma distinta, teniendo con alta congestión peores resultados si está

desequilibrado, se puede observar contrastando los valores de los escenarios 3 y 4.

Ahora, se van a comparar los tres sistemas pull ante los resultados obtenidos tras las simulaciones.

Como se puede observar, ante escenarios no exigentes, como son los de baja variabilidad y congestión,

escenarios 1 y 2, los sistemas actúan de la misma forma. Por tanto, es indiferente el aplicar uno u otro.

Kanban y POLCA actúan exactamente igual para todos los escenarios, exceptuando los más exigentes, es

decir, 7 y 8. Sin embargo, ConWIP siempre tendrá mayor tiempo de ciclo promedio total y WIP que los

demás. Con esto, se puede concluir, que a pesar de que ConWIP tiene los tiempos de espera en cola más

cortos, su funcionamiento siempre es peor, ante modificaciones de variabilidad y congestión.

Para los escenarios más exigentes se deduce, que el sistema que mejor se adapta a los cambios y obtiene

mejores resultados es POLCA, esté o no equilibrado. Se puede observar una mejora del tiempo de ciclo

promedio total de un 24% respecto a ConWIP y de un 2.5% en relación con Kanban, cuando los sistemas

están equilibrados. Sin embargo, ante un desequilibrio esta diferencia es menor, ya que ConWIP mejora sus

resultados, así que es ese caso el porcentaje de mejora de POLCA con relación a ConWIP es de 14%. Sin

embargo, con Kanban los dos actúan igual y empeoran ante el desequilibrio, aun así, POLCA sigue siendo

mejor un 2.2%. Si se analiza el WIP promedio, sigue siendo POLCA el que obtiene mejores resultados al

tenerlo siempre menor que ConWIP y Kanban, siendo el porcentaje de mejora de POLCA de un 22% y un

14% respectivamente, estando el sistema equilibrado. Si el sistema no está equilibrado, la mejora se produce

en todos los sistemas, aun así, el que mejor actúa sigue siendo POLCA con una mejora del 18% con relación a

ConWIP y 5% respecto a Kanban.

5.2 Propuestas de solución para bloqueo cruzado

En esta sección se va a proponer una solución para el bloqueo cruzado, que como se dijo en el punto 4.4 solo

se produce en POLCA y éste está explicado en el punto 2.3.

En primer lugar, se va a demostrar que, ante esta situación de distintos tipos de secuencia, las tarjetas se cruzan

y provocan lo que se denominó bloqueo cruzado.

Haciendo uso del modelo con secuencia de producción, se va a simular con los datos de sistema equilibrado y

baja variabilidad usados en el punto anterior, ver tabla 5-1 de datos de los factores. Lo que se va a variar, para

ver como ocurre el bloqueo cruzado, es la congestión.

La primera vez que se observa el problema de bloqueo cruzado es al configurar una situación de alta

congestión como se había definido, es decir, un valor de media de llegada de órdenes de trabajo de 12 minutos,

donde todas las tarjetas están con alguna orden de trabajo y ninguna estación de trabajo está procesando una de

ellas, por lo que esas órdenes deben estar en cola esperando una tarjeta que a su vez está en otra cola.


En las siguientes imágenes de la simulación, se puede observar como ninguna estación está procesando

ninguna orden de trabajo (figura 5-1) y no hay ningún tipo de tarjeta POLCA disponible (figura 5-2). A la vez,

se contempla como en todas las estaciones hay una orden de trabajo (figura 5-3) sin posibilidad de ser

procesada, y por esta razón, en los dispatcher se están acumulando las órdenes de trabajo que van llegando

(figura 5-4).

Figura 5-1: Ninguna estación en proceso.

Figura 5-2: Tarjetas POLCA a cero.

Figura 5-3: Todas las estaciones con órdenes de trabajo bloqueadas.


50

Figura 5-4: Colas en los dispatcher.

Para este problema de bloqueo se han buscado unas posibles soluciones similares a la solución propuesta por

Thürer et al (2016). La primera de ellas se trata de añadir tarjetas de seguridad a uno de los tipos de tarjeta

POLCA. Para ello, al modelo se le ha añadido una nueva entidad que pase por un módulo Decide (figura 5-5),

donde la condición para añadir una tarjeta sea que todos los tipos de tarjeta se hayan quedado a 0 y que

ninguna de las estaciones de trabajo este ocupada. Cada vez que esta condición se cumpla, mediante un

módulo Assign (figura 5-6) se asignará una tarjeta de seguridad a cierto tipo de tarjeta POLCA. La elección de

a qué tipo de tarjeta agregar una tarjeta de seguridad se ha hecho pensando en que secuencia es la que tiene un

porcentaje más alto de ocurrencia. En este caso particular, sería la secuencia 1, que empieza en la estación A,

por lo cual, esa tarjeta de seguridad se añadirá a las del tipo AB, ya que es la primera tarjeta que se necesita

para empezar el proceso.

Figura 5-5: Decide de solución al bloqueo cruzado.

Figura 5-6: Assign de primera propuesta de solución al bloqueo cruzado.


Se ha puesto un Delay (ver figura 5-7), es decir, un retraso, para que la entidad pase cada 50 segundos a

comprobar si se cumple la expresión indicada en el Decide.

Figura 5-7: Delay de solución al bloqueo cruzado.

Por lo tanto, la parte del modelo de la primera propuesta que da la solución al bloqueo cruzado queda como se

ve en la figura 5-8.

Figura 5-8: Primera propuesta de solución al bloqueo cruzado.

Si se simula el modelo con la correspondiente modificación, el resultado que se obtiene es la creación de 15

tarjetas de seguridad de tipo AB (figura 5-9). El incremento de tarjetas que se produce tiene una desventaja, ya

que aumentará el WIP promedio. Por lo cual, una vez solucionado el problema, se deben eliminar las tarjetas

de seguridad.

Figura 5-9: Resultado de la simulación de primera propuesta de solución al bloqueo cruzado.


52

Se ha buscado otra segunda propuesta de solución en la que se impliquen todas las estaciones. Se van a agregar

tarjetas de seguridad de todos los tipos. Mediante simulación, se ha llegado a la deducción que en este caso

particular es suficiente con un máximo de 4 tarjetas de seguridad por cada tipo de tarjeta POLCA. La idea es

empezar a añadir tarjetas de seguridad al tipo de tarjeta POLCA que es necesaria en la primera estación de la

secuencia con más probabilidad de salir, es decir a las tarjetas POLCA AB. Una vez que se llegue a 4 tarjetas

de seguridad del tipo AB, se ordenará que las siguientes tarjetas de seguridad en salir, sean las necesarias para

la siguiente estación de la secuencia, es decir la BC. Una vez hayan salido las 4 tarjetas de seguridad de este

tipo, será la última estación de la secuencia la que empezará a recibir tarjetas de seguridad, por tanto, serán de

del tipo CA.

Para esta propuesta, se han creado 3 variables, llamadas tarjetas de seguridad AB, tarjetas de seguridad BC y

tarjetas de seguridad CA. Para poder contabilizar cuantas se agregan a cada tipo.

El modelo de esta propuesta comienza como el anterior, con el mismo Decide llamado “bloquear POLCA”

(figura 5-5) que en caso de no cumplir la condición pasa a un Delay, también modelado de la misma forma

que anteriormente (figura 5-7). El cambio se produce cuando si se cumple la condición que se le puso. Esta

vez, pasará a otro Decide denominado “comprueba tarjetas seguridad AB” (figura 5-10), donde la condición es

que el número de este tipo de tarjetas de seguridad sea menor que 4. Si se cumple la condición, la entidad pasa

a un Assign, donde añadirá una tarjeta POLCA AB y también aumentará el contador de tarjetas de seguridad

AB (figura 5-11).

Figura 5-10: Decide segunda propuesta de solución al bloqueo cruzado.

Figura 5-11: Assign segunda propuesta de solución al bloqueo cruzado.


En caso de no cumplir la condición porque ya haya llegado a las 4 tarjetas de seguridad permitidas, pasará a

otro Decide llamado “comprueba tarjetas de seguridad BC”, se modela exactamente igual que el de AB, pero

cambiando el tipo de tarjeta. Por último, cuando ya se tengan también 4 tarjetas de seguridad BC, se pasará al

módulo Decide “comprobar tarjetas de seguridad CA”. Se vuelve a modelar de la misma forma, en este caso

sino cumple la condición, la entidad volvería al principio, pero ello significaría, que se ha vuelto a bloquear y

ya no hay permiso para más tarjetas de seguridad. En la figura 5-12, se puede ver la parte del modelo de la

segunda propuesta de solución al bloqueo cruzado.

Figura 5-12: Segunda propuesta de solución al bloqueo cruzado.

Con esta propuesta, los resultados tras la simulación, ver figura 5-13, son de un total de 11 tarjetas de

seguridad, 4 de tipo AB, 4 de tipo BC y 3 de tipo CA. Se ha conseguido disminuir en 4 según la primera

propuesta. Aun así, una vez solucionado el bloqueo cruzado, las tarjetas de seguridad serán eliminadas, como

se dijo en la propuesta anterior, ya que siempre es una desventaja el aumento de WIP que se produce debido a

este problema.

Figura 5-13: Resultado de simulación de la segunda propuesta.


54

55

CONCLUSIONES Y LÍNEAS FUTURAS

ste capítulo presenta las conclusiones extraídas del análisis de los datos obtenidos tras las simulaciones

realizadas de los sistemas de control de producción presentados en este proyecto. Además de una

relación de posibles líneas futuras para ampliar este estudio.

6.1 Conclusiones

Tras las simulaciones realizadas a los tres sistemas de control de producción, Kanban, ConWIP y POLCA, y

comparar los resultados, se puede decir que ConWIP actúa pero que Kanban y POLCA coincidiendo con las

conclusiones de Thürer et al (2016), a pesar de que su implementación es la más fácil. Sin embargo, POLCA

que involucra bucles de estaciones y con ello una complicada implementación, es el que consigue un mejor

rendimiento en todos los casos.

Respecto a las soluciones propuestas para el bloqueo cruzado, hay que tener en cuenta que un número elevado

de tarjetas crea un inconveniente importante que es el aumento del WIP, habría que valorar dependiendo del

caso concreto si es conveniente el uso del sistema POLCA.

6.2 Líneas futuras

Hay varias líneas futuras interesantes para ampliar el estudio realizado en este proyecto como son:

• El sistema elabore distintos tipos de producto. Para ello cabe recordar que las tarjetas Kanban

dependen del producto y que las tarjetas ConWIP y POLCA son anónimas.

• Tener en cuenta la prioridad de las órdenes de trabajo implementando un sistema MRP para ello. En

este caso se ha supuesto que ya tenían adjudicada la prioridad.

• El estudio de sistemas de control de producción que incorporen el equilibrio de carga de trabajo, como

es el caso de COBACABANA, ya que es interesante cuando existe una alta variabilidad.

E

57

BIBLIOGRAFÍA

Arena user’s guide.

Champan, S.N. (2006). Planificación y control de la producción. Pearson Prentice Hall.

Cuatrecasas, L. (2011). Organización de la producción y dirección de operaciones: sistemas actuales

de gestión eficiente y competitiva. Diaz de Santos.

Harrod, S., Kanet, J.J. (2013). “Applying Work Flow Control in Make-to-Order Job Shops”.

International Journal of Production Economics, 143: 620-626.

Heizer, J., Render, B. (2008). Dirección de la producción y operaciones: decisiones tácticas. Pearson

Prentice Hall, 8ª Edición.

Hopp, W. y Spearman, M. (2011). Factory Physics. McGraw-Hill, 3ª Edición.

Hopp, W.J., Spearman M.L. (2004). “To Pull or Not to Pull: What Is the Question?”. Manufacturing

& Service Operations Management, 6(2):133-148.

Lödding, H. (2013). Handbook of manufacturing control: fundamentals, description, configuration.

Springer.

Moscoso, P., Lago, A. (2016). Gestión de operaciones para directivos: destapa el pleno potencial de tu

empresa. McGraw-Hill Education.

Ohno, T. (1988). Toyota Production System: Beyond Large Scale Production. 1st ed. Cambridge,

MA: Productivity Press.

Riezebos, J. (2010). “Designo of POLCA Material Control Systems”. International Journal of

Production Research, 48(5): 1455-1477

Suri, R. (1998). Quick Response Manufacturing: A Companywide Approach to Reducing Leadtimes.

Cambridge, MA: Productivity Press.

Bibliografía

58

Thürer, M., Stevenson, M., Protzman, C.W. (2016). “Card-based production control: a review of the

control mechanisms underpinning Kanban, ConWIP, POLCA and COBACABANA systems”.

Production Planning and Control, 27(14): 1143-1157.

Vandaele, N., Nieuwenhuyse, I.V., Claerhout, D., Cremmery, R. (2008). “Load-Based POLCA: An

Integrated Material Control System for Multiproduct”. Multimachine Job Shops, Manufacturing &

Service Operations Management, 10(2): 181-197.

Velasco, J., Campins, J.A. (2013). Gestión de la producción en la empresa: planificación,

programación y control. Ediciones Pirámide.

59

ANEXO

MODELOS COMPLETOS DE LOS SISTEMAS

Ilustración 1: Modelo completo sistema Kanban.

Ilustración 2: Modelo completo sistema ConWIP.

Anexo

60

Ilustración 3: Modelo completo sistema POLCA.


Ilustración 4: Modelo completo sistema con secuencia.

Anexo

62

Ilustración 5: Modelo completo con la primera propuesta de solución al bloqueo cruzado.


Ilustración 6: Modelo completo con la segunda propuesta de solución al bloqueo cruzado.

proyecto fin de carrera - universidad de...

Documents