5S en planta industrial: ordenar y sostener un puesto
Aplica las cinco etapas de 5S a un puesto industrial: ordena, observa al limpiar y sostén el estándar sin fijar una cadencia universal.
Cantidad por kanban en D365 y route train en SAP 2510
Distingue en D365 las unidades por kanban del número fijo; en SAP 2510, lee cuándo una solicitud de almacén puede usar route trains.
Dos lecturas distintas: cantidad en D365 y route train en SAP
La documentación de D365 distingue dos cifras: las unidades que lleva cada kanban y el número de kanbans de una estrategia fija. El manual SAP 2510 responde a otra pregunta: cuándo una solicitud de almacén puede procesarse con route trains. Son lecturas separadas de productos distintos; no describen un campo común ni sistemas equivalentes.
El ejemplo de Microsoft utiliza cinco unidades por kanban y dos kanbans. No indica cuántas unidades hay disponibles ahora en una ubicación. SAP, por su parte, limita una ruta de reposición con Kanban y route train a embedded EWM. Lo que sigue se ciñe a esas páginas de producto, no a una instalación concreta. Microsoft, Replenishment with withdrawal kanbans; SAP, Product Assistance for SAP S/4HANA for Manufacturing Logistics 2510, §4.3.8.
Dos cantidades, dos objetos en D365
En el artículo de Microsoft, la cantidad de un kanban indica cuántas unidades transporta su unidad de manipulación. Fixed kanban quantity se usa cuando la estrategia es fija y cuenta cuántos kanbans requiere el flujo. Una cifra cuenta producto por contenedor; la otra, contenedores Kanban. Microsoft, Replenishment with withdrawal kanbans, “Configure the withdrawal kanban”.
| Campo del ejemplo | Lectura correcta | Lectura que el texto no respalda |
|---|---|---|
| Default quantity: 5 | Cinco unidades transferidas por kanban | Cinco kanbans |
| Fixed kanban quantity: 2 | Dos kanbans en la estrategia fija | Dos unidades de producto |
Microsoft formula la relación de forma explícita: dos kanbans que transfieren cinco unidades cada uno. El 5 no cuenta tarjetas y el 2 no mide piezas. Microsoft, Create a withdrawal kanban rule, “Set quantities for kanban”.
La multiplicación 2 × 5 da diez unidades si los dos kanbans están completos. Es una cuenta sobre el ejemplo, no una lectura del stock real. El procedimiento no informa si ambos contenedores están llenos, dónde se encuentran ni si pueden consumirse en ese momento. Para responder a esas preguntas hace falta un registro de existencias del sistema concreto; estos dos campos no lo sustituyen.
Qué revela el número fijo
Fixed kanban quantity pertenece a la estrategia fija. En el artículo de Microsoft se describe como el número de kanbans necesarios para evitar que el inventario en el origen de demanda se agote o se acumule. La documentación también indica que el valor puede calcularse con demanda real, demanda histórica y niveles de servicio.
Esos factores explican el contexto del campo; el ejemplo de cinco y dos no da una fórmula para copiar a otra regla ni propone una cifra universal. Microsoft, Replenishment with withdrawal kanbans, “Configure the withdrawal kanban”.
Otros dos límites de seguimiento en D365
Microsoft muestra también Alert boundary minimum y Alert boundary maximum. En el ejemplo valen 1 y 2; sirven para seguir el mínimo y el máximo de kanbans completos que deberían encontrarse en destino, por ejemplo en la vista de cantidades. No cuentan las unidades de cada contenedor ni sustituyen Fixed kanban quantity.
Una tabla que guarde los cuatro valores necesita conservar sus etiquetas: unidades por kanban, kanbans de la estrategia fija y límites de kanbans completos en destino son lecturas distintas. Microsoft, Create a withdrawal kanban rule, “Set quantities for kanban”.
Una tercera magnitud: la sugerencia calculada
El ejemplo de cinco unidades por kanban y dos kanbans describe valores de una regla de retirada. Microsoft también documenta otra lectura: una política asociada a una regla puede generar sugerencias de cantidad. No es otro nombre para el número fijo de kanbans. La página de la política explica que es un requisito previo para el procedimiento que calcula esas sugerencias y muestra cómo asociarla a una regla.
Por tanto, conviene separar tres preguntas: cuántas unidades caben en cada unidad de manipulación, cuántos kanbans activos contempla una estrategia fija y qué cantidad propone el cálculo de una política. Microsoft, Add a kanban quantity calculation policy to a kanban rule, “Create a kanban quantity calculation policy” y “Add the kanban quantity calculation policy to a kanban rule”.
La página de Microsoft incluye una política de demostración, no un perfil recomendado para cualquier artículo. Su procedimiento selecciona un plan maestro para calcular demanda y muestra, entre otros campos, una cantidad mínima de kanbans adicionales, un factor de seguridad y ventanas de días alrededor de la fecha del cálculo. La documentación define “Days ahead” como los días anteriores a esa fecha que entran en el cálculo de demanda y “Days behind” como los días siguientes incluidos.
Es útil conservar esas definiciones tal como aparecen en la página, porque el nombre de los campos por sí solo no aclara qué periodo abarca cada uno. Microsoft, Add a kanban quantity calculation policy to a kanban rule, pasos 4–11.
El ejemplo muestra valores 1 para la cantidad mínima adicional y el factor de seguridad, y 30 para ambas ventanas. La fórmula que presenta combina demanda diaria media, plazo de reposición, un factor mostrado como 2.00, cantidad de producto por unidad de manipulación y una unidad adicional de kanban. Esos valores pertenecen al ejemplo de la página; no permiten deducir la política de otra regla ni afirmar que el resultado refleje existencias reales.
Tampoco hay que tratar el factor 2.00 como una recomendación: la fuente solo enseña la fórmula con los valores de demostración. Microsoft, Add a kanban quantity calculation policy to a kanban rule, pasos 8–11.
La vista general de Microsoft confirma que el cálculo de cantidades puede considerar previsiones, demanda real de pedidos abiertos, plazo de reposición e historial. Esa lista describe entradas que el producto puede considerar; no demuestra cuáles se usaron en una sugerencia concreta. Para interpretar un resultado, se necesitan la regla, su política y el plan maestro seleccionados, además de los valores y la fecha del cálculo.
La sugerencia no prueba cuántos contenedores están llenos, dónde se encuentran ni qué stock está disponible en ese instante. Microsoft, Lean manufacturing overview, “Using kanbans to signal demand requirements”.
SAP 2510: solicitud, ruta y route train
SAP §4.3.8 describe el procesamiento con route train de una solicitud de almacén Kanban para embedded EWM. La secuencia y sus condiciones se detallan a continuación. SAP, §4.3.8.
Seguir la solicitud por las etapas que enumera SAP
El manual presenta una secuencia numerada de once pasos. Los primeros dos registran el estado Empty del Kanban en una de las aplicaciones indicadas y crean la solicitud de almacén para reponer. Después se determina la ruta para el artículo de esa solicitud. Asignar la solicitud a una wave y liberarla es opcional; a continuación, SAP crea las tareas de picking y las asigna a una warehouse order. SAP, §4.3.8, “Replenishment Process”, pp.173–174.
Los pasos siguientes preparan y recogen las unidades de manipulación, las cargan en una tour nueva o existente y las descargan en la PSA mediante la transacción RF del route train. Es el tramo de movimiento descrito por los pasos 6–8; el texto luego añade confirmaciones que conviene leer por separado. La creación de una solicitud, el picking y la carga son momentos distintos, no una sola confirmación de llegada. SAP, §4.3.8, “Replenishment Process”, pp.173–174.
| Tramo del proceso SAP 2510 | Qué muestra el manual | Límite de la lectura |
|---|---|---|
| Estado y solicitud | Kanban Empty y creación de una warehouse request | No equivale a traslado físico |
| Ruta y preparación | Determinación de ruta; wave opcional; tareas de picking | La wave no es obligatoria |
| Tour y descarga | Preparar, cargar en tour y descargar en PSA | Aún hay pasos de confirmación después de descargar |
| Confirmación y cierre | Estado Full, posible handover bin y cierre de tour | El caso de handover puede completar la solicitud antes de que la HU llegue a la PSA |
Después de la descarga, el paso 9 confirma la tarea de almacén a un tipo de almacenamiento final y el sistema establece el estado Full del Kanban. El paso 10 es opcional: si la PSA tiene un handover bin, descargar allí completa la solicitud y también establece Full, aunque la unidad de manipulación todavía debe trasladarse desde ese punto hasta la PSA; SAP indica que el sistema crea la tarea correspondiente. El paso 11 completa la tour.
Esa distinción evita tratar “solicitud completada”, “Full” y “unidad en PSA” como si fueran siempre el mismo evento. SAP, §4.3.8, “Replenishment Process”, pp.173–174.
Qué bloquea una ruta sin determinar
SAP denomina la determinación de ruta una precondición para procesar una solicitud de almacén con route trains. Si no hay ruta determinada para esa solicitud, el documento dice que no puede procesarse con route trains y nombra como alternativa el equipo de distribución de EWM. La determinación depende del almacén; la fuente no define una ruta común para todas las ubicaciones. SAP, §4.3.1, “Route Determination”, p.152.
Cuándo vuelve a determinarse la ruta
SAP sitúa route determination dentro de la reevaluación logística, no como una llamada independiente. El manual dice que se activa cuando se crea o actualiza una warehouse request y que también puede iniciarse desde nodos del monitor EWM o al preparar una wave. Son los momentos que documenta el producto; no una instrucción para repetir la reevaluación cada vez que un campo aparezca vacío. SAP, Product Assistance 2510, §4.3.1, “Route Determination in Logistical Re-Evaluation”, p.152.
Si esa reevaluación no obtiene ruta, el mismo apartado describe intentos condicionados durante la creación de wave. La prioridad de la warehouse request puede subir si la opción está habilitada para su warehouse process type; SAP distingue esa solicitud de una production material request. El procedimiento estándar también intenta encontrar otro warehouse process type y una ruta.
El texto describe intentos, no garantiza que aparezca un recorrido ni recomienda cambiar prioridades o configuración. SAP, Product Assistance 2510, §4.3.1, “Route Determination in Logistical Re-Evaluation”, p.152.
La continuación del mismo apartado ayuda a identificar qué significa el campo relacionado. En el Field Catalog, SAP incluye ILO_ROUTE como Route ID y señala que ese ID representa el resultado de la determinación de ruta. Leídos juntos, los dos pasajes separan la condición del dato: la solicitud necesita una ruta para seguir por route train, y Route ID nombra el resultado documentado.
El campo no convierte la regla en una instrucción para crear o cambiar rutas. SAP, §4.3.1, Field Catalog, p.153.
| Lo que se ve en la solicitud | Lectura acotada al manual | Lo que ese dato no demuestra |
|---|---|---|
| No aparece una ruta determinada | No se cumple la precondición descrita para procesar esa solicitud con route train | No explica por qué falta la ruta ni demuestra que no existiera una señal Kanban |
| Aparece un Route ID | El catálogo lo identifica como resultado de determinar la ruta | No acredita que la unidad se haya cargado en una tour o descargado en la PSA |
La tabla relaciona dos descripciones del manual; no añade una comprobación del sistema ni una regla para diagnosticarlo. Por ejemplo, la ausencia del identificador no revela si la solicitud se creó, si se asignó otro método de distribución o qué regla de almacén intervino. Su presencia tampoco reemplaza los pasos posteriores de picking, carga y descarga que SAP enumera en §4.3.8.
La fuente explica que esos pasos pertenecen a una secuencia, no que el identificador sea una confirmación de movimiento físico. SAP, §§4.3.1 y 4.3.8, pp.152–153 y 173–174.
Por eso, cuando se lee un registro concreto, conviene conservar el nombre del campo y el objeto al que se refiere: aquí es la ruta de una solicitud de almacén dentro de un proceso con route train. La explicación del manual no especifica valores permitidos, la lógica completa de determinación ni qué cambio resolvería un identificador ausente. Tampoco permite concluir que todas las opciones de reposición estén bloqueadas.
Esas cuestiones quedan fuera de este pasaje y requieren documentación o datos propios del entorno; no se deben completar a partir del ejemplo.
Otra rama: tareas de almacén para HU
SAP separa también una rama de route trains basada en tareas de almacén para unidades de manipulación. En §4.6 advierte que el staging de Kanban mediante esas tareas no se admite con route trains, porque las warehouse tasks de Kanban no soportan process-oriented storage control. Ese límite pertenece a la vía de tareas HU; §4.3.8 describe aparte Kanban mediante warehouse requests. SAP, Product Assistance 2510, §4.6, “Tours for HU Warehouse Tasks with Route Trains”, printed p.193.
Los prerrequisitos que sí aparecen en el documento
En el apartado de Kanban con warehouse requests, SAP nombra dos prerrequisitos para ese proceso: tener configurado el proceso de reposición Kanban de EWM y que el tipo de proceso de almacén del control cycle conduzca a un proceso relevante para route train. El manual también fija la restricción de embedded EWM. Estos puntos delimitan el contexto documental. No son un tutorial para configurarlos ni una recomendación para elegir ese diseño. SAP, §4.3.8, “Prerequisites”, pp.173–174.
El límite de embedded EWM merece mantenerse junto a la descripción del proceso. Separarlo del texto podría hacer parecer que route train está disponible para cualquier modalidad de EWM o para todo escenario Kanban. SAP 2510 dice expresamente que ese proceso de route trains solo se admite con embedded EWM. Esa es una limitación del flujo citado en el manual, no una afirmación sobre otros procesos de almacén fuera del apartado. SAP, §4.3.8, “Restriction”, p.173.
Preguntas frecuentes
¿Qué representan las unidades por kanban y los valores 5 y 2 del ejemplo de D365?
La cantidad por kanban indica cuántas unidades lleva su unidad de manipulación; en el ejemplo, 5. La cifra 2 es el número de kanbans, no de unidades de producto.
¿Qué cuenta la Fixed kanban quantity?
En la estrategia fija, cuenta cuántos kanbans se requieren; no es la cantidad de unidades de cada uno.
¿Qué exige SAP 2510 para procesar una solicitud con route train?
La documentación exige que se determine una ruta para la solicitud de almacén que va a procesarse con route trains.
¿Qué alternativa nombra SAP si una solicitud no tiene ruta determinada?
El manual indica que esa solicitud no puede usar route trains y nombra el equipo de distribución de EWM como alternativa.
¿La falta de ruta prueba que no existió una señal Kanban o que toda reposición es imposible?
No. El texto limita el procesamiento de esa solicitud con route trains; no afirma que faltara la señal ni que todas las vías de reposición estén bloqueadas.
¿Qué representa una sugerencia de cantidad calculada en D365?
Es una propuesta obtenida con la política vinculada a la regla; no es una lectura del inventario disponible ni sustituye el conteo de kanbans activos.
Cuando la consulta depende de la instalación
La recomendación práctica es consultar la documentación de la versión y el registro concreto que se quiere interpretar. Si la pregunta es sobre existencias reales, una ruta local o el estado de una solicitud, hay que verificar esos datos en el sistema correspondiente. Esta página explica qué dice cada fuente; no verifica la configuración de ninguna instalación ni indica cambios operativos.