Tarjeta kanban: qué autoriza y qué información puede mostrar

Una tarjeta kanban no es una previsión de producción. En la definición del Lean Enterprise Institute, kanban es una señal que autoriza e indica la producción o retirada de artículos dentro de un sistema pull. La señal conecta una necesidad del proceso que consume con el proceso que suministra. Las tarjetas son el ejemplo más conocido, y LEI enumera posibles datos como nombre y número de pieza, proveedor o proceso abastecedor, cantidad de embalaje y ubicaciones de almacenamiento y consumo.

La fuente presenta ejemplos; no impone una plantilla universal. (LEI, “Kanban”, líneas 1–37 del HTML retenido)

Aquí importa la tarjeta que circula en un circuito de reposición: qué autoriza, qué datos permiten ejecutar la señal y qué registro puede conservarse. El equipo que la emite, la recibe o repone el material puede comprobar si esos campos sirven en ese flujo.

La señal autoriza dentro de un flujo

Cada organización define cómo emite, usa, cancela y repone la señal. La tarjeta no sustituye el plan general, la especificación de producto, las decisiones de calidad ni las restricciones de seguridad; tampoco autoriza fabricar o mover cualquier cantidad.

El origen y el destino pueden distinguir dos señales para la misma pieza. LEI incluye proveedor o proceso suministrador y dirección del proceso consumidor entre sus ejemplos; el caso práctico más abajo muestra por qué conviene separarlos cuando el circuito los necesita. (LEI, “Kanban”, sección de card data)

Dos acciones que una señal puede autorizar

LEI distingue la tarjeta de producción, que indica al proceso anterior qué tipo y cantidad fabricar para el siguiente, de la tarjeta de retirada, que autoriza trasladar piezas aguas abajo. En el ejemplo descrito por LEI, el operario retira la señal de movimiento al consumir la primera pieza del contenedor y la deja en una caja de recogida. El manipulador la toma y, al volver al supermercado anterior, la coloca en un nuevo contenedor destinado al proceso consumidor.

Cuando ese contenedor sale, se separa la tarjeta de producción y vuelve al proceso que debe fabricar la reposición.

LEI ilustra la tarjeta de producción con un contenedor que el proceso anterior fabrica para el supermercado siguiente. Es un ejemplo de relación, no una regla de una tarjeta por contenedor.

La distinción ayuda a leer una tarjeta: un código de pieza y una cantidad no indican por sí solos si se solicita fabricar o mover. Antes de elegir campos, el equipo puede identificar qué acción activa la señal y quién la recibe. La secuencia de cajas y devoluciones es el ejemplo de LEI, no un flujo que todas las plantas deban copiar. LEI, secciones “Production Kanban” y “Withdrawal Kanban”

Imprimir una tarjeta no crea por sí solo un sistema pull. Si funciona como una lista de trabajo separada de la señal de consumo, puede acabar siendo otra forma de planificación. Lo primero es identificar qué evento la activa y qué autoriza. Sin una regla clara para emitirla y devolverla, puede circular sin controlar el flujo.

Campos que la fuente menciona

LEI cita nombre o número de pieza, proveedor o proceso abastecedor, cantidad de embalaje y ubicaciones de almacenamiento y consumo. También menciona códigos de barras para seguimiento o facturación automática; son posibilidades, no una plantilla.

Toyota Systems explica que su kanban digital especifica pieza, lugar, momento y cantidad, y envía esos datos a fabricantes según las condiciones diarias de producción. También describe una comprobación de exactitud al introducirlos. Es un ejemplo de su sistema, no una plantilla física general ni prueba de que el material se moviera o recibiera. Toyota Systems, líneas 88–90 y 98–100 (LEI, “Kanban”, líneas 15–37)

En Kanban Part List, Part Number identifica la pieza y Signal Number la cantidad requerida para un proveedor específico. Los campos de cantidad dependen del estado seleccionado. Infor Supplier Exchange, “Kanban Part List”, líneas 7–13

Una pieza configurada no es una señal individual

Infor documenta dos niveles distintos en Supplier Exchange. La página Kanban Existing Parts permite crear, modificar o eliminar el registro de una pieza. Su lista presenta campos de configuración: Part Number identifica la pieza; Planner es el usuario del cliente que gestiona su inventario Kanban; Facility es el lugar donde se genera la demanda; Ship To indica el lugar de recepción; Supplier identifica quién abastece.

Esos campos describen la relación configurada, no el estado de cada señal consultada después. Infor, “Kanban Existing Parts”, líneas 2 y 6–18

La ayuda de Infor explica que la pieza se configura antes de usar sus señales y que el registro contiene información de Kanban y de las señales pull. También documenta que eliminar manualmente una pieza Kanban quita sus señales existentes y la demanda asociada a esa pieza. Es un comportamiento descrito para Supplier Exchange; no es una regla general de Kanban ni una recomendación para borrar una tarjeta física.

La distinción útil para leer el sistema es si la pantalla describe la configuración de la pieza o una señal concreta. La definición de la pieza también depende de la clave de demanda del cliente. Infor indica que puede basarse en el número de pieza y, de forma opcional, en PO number, model year o engineering level. Si dos registros comparten número de pieza, comprueba qué atributos forman esa clave antes de tratarlos como la misma demanda.

La ayuda no define una regla para fusionar registros ni para resolver esa coincidencia. Infor, “Kanban parts”, líneas 2–3 Infor, “Kanban parts”, líneas 2–4

Una vista de software puede separar cantidades por estado

En la lista de Infor, estos dos campos identifican la pieza y la cantidad requerida para un proveedor; las cantidades por estado se detallan más abajo. (Infor Supplier Exchange, “Kanban Part List”, líneas 7–13)

Elegir campos para un flujo local

El ejemplo anterior deja dos preguntas abiertas para el diseño local: qué evento cierra la señal y qué registro permite detectar una pérdida o evitar una reposición duplicada. LEI no prescribe esas reglas.

Un destino ambiguo cambia la lectura de la señal

Supongamos que dos celdas consumen la misma referencia de tornillo y reciben reposiciones desde un almacén común. Una tarjeta dice “tornillo M8, cantidad 2”, pero no indica si son dos piezas o dos cajas ni a qué celda debe llegar el contenedor. La persona que prepara el pedido conoce el artículo, pero no puede distinguir el destino ni interpretar la cantidad sin preguntar.

No es un caso observado ni un resultado de LEI: sirve para probar qué información necesita el circuito.

Si el destino se deriva de un código que el lector interpreta correctamente en el punto de uso, imprimirlo otra vez podría duplicar datos. Si el código solo identifica el artículo, no resuelve cuál de las dos celdas recibe el material. Una tarjeta que muestra “almacén A” puede estar indicando dónde recoger el contenedor, no dónde entregarlo.

Conviene nombrar las dos funciones por separado cuando el circuito las maneja como datos distintos: origen de la retirada y proceso que la solicita. El ejemplo de LEI menciona ubicaciones de almacenamiento y dirección del proceso consumidor; no dice que deban imprimirse siempre juntas ni establece qué etiqueta usar. Si el código solo identifica la pieza, queda por definir cómo se distingue la celda.

Si la unidad usada para comprar difiere de la unidad movida entre procesos, la conversión también debe quedar clara para quien repone; la fuente no fija esa equivalencia. Si se usan abreviaturas para separar esos datos, la leyenda debe aclarar cuál es el origen, cuál el destino y a qué cifra corresponde la unidad. El equipo que mantiene el circuito decide qué campo o referencia resuelve la ambigüedad.

En Infor, Signal Number representa la cantidad requerida enviada a un proveedor específico. En la vista Kanban Part List, Due Date indica cuándo debe enviarse la cantidad y Sent Date cuándo se envía; son definiciones de esa vista concreta.

En el ejemplo de LEI, un código de barras puede enlazar con seguimiento o facturación automática. Para saber si registra un movimiento, hay que identificar qué sistema lo lee y qué evento guarda. Toyota Systems menciona una comprobación de exactitud al introducir datos en su propio sistema, pero no afirma que el material llegara a la celda ni que se conservara un registro de errores.

Qué registra cada detalle de Infor

La lista Kanban Part List permite revisar señales por pieza y los campos que dependen del estado seleccionado. Las páginas de detalle añaden información para una pregunta más concreta: qué sigue pendiente del proveedor, qué consta del shipper publicado o qué se registra como recibido. La comparación sirve para localizar el detalle pertinente; no declara que las cantidades sean comparables entre sí.

Due Date depende de la vista: At Supplier la define como fecha requerida; In-House, como fecha límite de recepción. Shipment Date es la fecha de publicación del shipper, no necesariamente recogida, inicio del tránsito o entrega. Infor, At Supplier, líneas 14–22; In-Transit, líneas 11–20; In-House, líneas 15–23

Supongamos que compras pregunta por una cantidad pendiente y, a la vez, una célula quiere confirmar qué recepción aparece en el sistema. At Supplier identifica Due Quantity y Due Date; el detalle In-Transit puede localizar el registro del shipper mediante sus referencias; In-House presenta Received Quantity y Received Date.

Elegir el detalle permite localizar el registro pertinente, pero no resuelve por sí solo una discrepancia ni define la unidad que usa la planta.

Infor no proporciona en estas páginas una unidad común, conversión o fórmula para calcular faltantes entre vistas; no se puede inferir una regla de conciliación o de envíos parciales. Infor, At Supplier Signals, líneas 14–22; Infor, In-Transit signals, líneas 11–20; Infor, In-House Signals, líneas 15–23

Distinguir número de señales y cantidad de material

At Supplier separa Part Detail, con instalación, destino, proveedor, pieza y fechas de búsqueda, de Pull Signal Detail. En Part Detail, Signal Amount cuenta señales que se recibirán; en el detalle, Due Quantity expresa la cantidad de pieza pendiente. Infor no define una conversión entre ambos datos. Infor, At Supplier Signals, líneas 4–22

In-House también distingue el conteo de señales de las cantidades por señal. Available Pull Signals cuenta las señales con estado In-House; Number of Signals to Consume solo aparece para FIFO. Con Unique, Infor describe seleccionar una señal concreta en Pull Signal Detail. La tabla anterior recoge Due Quantity y Received Quantity para esa señal. Infor, In-House Signals, líneas 6–23

Un ejemplo ilustrativo, no tomado de una captura ni de una planta: si una vista mostrara tres señales disponibles y una señal individual tuviera Due Quantity 12, el primer dato contaría registros y el segundo expresaría cantidad de pieza pendiente en ese registro. No se deduce que cada señal represente 12 unidades, que las cantidades sean iguales ni que exista una conversión entre el conteo y el material. Infor, In-House Signals, líneas 13–23

In-Transit combina Signal Number y referencias de documentos con Shipped Quantity. Los identificadores permiten localizar la señal o el shipper; no demuestran que el material haya llegado. Shipment Date es la fecha de publicación del shipper, como indica la tabla anterior. Infor, In-Transit signals, líneas 11–20

Al leer estas vistas, identifica si el dato describe la pieza, una señal individual, el número de señales o un documento, y si aparece en el resumen de la pieza o en el detalle de una señal. Es una pauta de lectura, no una regla de diseño o conciliación.

Qué puede y qué no puede demostrar una tarjeta

La tarjeta muestra una señal y sus datos. Por sí sola no confirma que la cantidad sea correcta, que el proveedor haya servido el material o que el proceso consumidor lo haya recibido. Para esas conclusiones, el circuito necesita los registros de movimiento y las comprobaciones que la organización haya definido.

Si se pierde una tarjeta, el centro puede tener que decidir cómo reconstruir la señal sin crear una orden duplicada. Si se daña o se vuelve ilegible, el dato no se recupera solo por conocer el número de pieza. Esos casos requieren una regla local para anular, reemplazar y conciliar la tarjeta, pero no se presentan como una política de LEI.

El número de tarjetas en circulación tampoco revela por sí solo si el flujo está equilibrado. Para evaluar consumo, reposición o faltantes hacen falta definiciones de periodo y registros de transacción. Una tarjeta física representa una señal, no un KPI. El sistema puede estar funcionando con pocas tarjetas o con muchas según su diseño; LEI no fija una cantidad general.

Límites de la fuente

LEI describe el concepto y ejemplos, no una cantidad estándar ni una plantilla sectorial. Infor y Toyota documentan sus propios sistemas, no requisitos para una tarjeta física. (LEI, “Kanban”; Infor Supplier Exchange; Toyota Systems)

Jira, Trello y Scrum no son equivalentes a esta señal. Aquí se trata la autorización de producir o retirar material en un sistema pull, no una herramienta genérica para gestionar tareas. También evita presentar un ejemplo hipotético como resultado de una planta real.

Preguntas frecuentes

¿Qué autoriza una tarjeta kanban?

Según LEI, puede autorizar producir o retirar material según la señal y el flujo pull al que pertenezca. LEI, Kanban

¿Qué campos puede llevar una tarjeta?

LEI presenta ejemplos de datos de tarjeta; producto, cantidad y puntos de origen/destino pueden usarse si el circuito local los necesita. LEI, líneas 15–37

¿Existe un formato universal de tarjeta kanban?

La fuente no fija una plantilla obligatoria; los campos se adaptan al flujo y al modo de ejecutar la señal. LEI, “Kanban”

¿La tarjeta kanban es una previsión de producción?

No: en el uso descrito por LEI es una señal de autorización en un sistema pull, no una orden basada simplemente en previsión. LEI, Kanban

¿Qué cantidad muestra cada vista de Infor?

At Supplier muestra Due Quantity pendiente; In-Transit, Shipped Quantity junto con Shipment Date; In-House, Received Quantity y Received Date. Due Date tiene definiciones propias en At Supplier e In-House. Son campos de Supplier Exchange, no un formato universal de tarjeta física. Infor, At Supplier Signals, líneas 14–20; Infor, In-Transit signals, líneas 11–20; Infor, In-House Signals, líneas 15–23