Software MRP: planificación de necesidades de material

El MRP clásico del ERP usa plazos fijos y capacidad infinita. El MRP de MSF se guía por el programa APS de capacidad finita, por lo que las fechas son realistas.

Genera propuestas que sus compradores aprueban; las aprobadas pasan a su ERP como órdenes de compra.

Sí, las operaciones subcontratadas y los materiales suministrados a subcontratistas están totalmente soportados.

Cinco cosas, no tres: listas de materiales que coincidan con lo que de verdad se fabrica, stock disponible que coincida con la estantería, plazos de entrega medidos y no heredados, órdenes de compra y de fabricación abiertas con fechas que alguien siga creyendo, y las reglas de merma, rendimiento y tamaño de lote. El suministro abierto obsoleto es el problema silencioso, porque cubre sobre el papel una necesidad que en realidad no está cubierta. Antes del arranque, saque todas las órdenes abiertas con fecha ya vencida y obligue a decidir una por una: reprogramar o cerrar.

No como usted lo necesita. El MRP netea las necesidades contra el stock disponible y el suministro abierto, así que si el disponible está mal el resultado está mal en las dos direcciones a la vez: pide material que ya tiene y se calla sobre el material que no tiene. El recuento cíclico sobre los artículos que concentran el valor es un requisito previo.

Un lanzamiento completo por la noche, más relanzamientos puntuales tras un cambio de programa o una entrega tardía. Más frecuente no es automáticamente mejor: cada lanzamiento replanifica con información nueva, y una fecha de necesidad que se mueve cada mañana no le da al comprador nada sobre lo que actuar. Dentro del horizonte congelado, aclare si las propuestas dejan de recalcularse del todo o se siguen recalculando y solo se marcan cuando se desvían, porque para quien trabaja la lista son dos comportamientos muy distintos.

Sí, de forma autónoma contra su ERP. Mantiene la explosión multinivel de la lista de materiales, el neteo contra stock disponible y suministro abierto, los calendarios de proveedor y las cantidades mínimas de pedido. Lo que pierde son las fechas guiadas por el programa: las fechas de necesidad vuelven a calcularse con plazos fijos, así que son exactamente tan buenas como los plazos que alguien tecleó en su día, y no se mueven cuando el taller se retrasa.

No toma decisiones comerciales. Propone cantidades y fechas; no negocia precios, no elige entre proveedores más allá de los datos que usted configuró (proveedor preferente, escalado de precio, plazo de entrega, cantidad mínima de pedido, calendario) y no hace previsión de demanda, que tiene que venir de su plan de ventas. Tampoco puede ver el material consumido en planta pero nunca imputado, que es la razón habitual de que una propuesta parezca equivocada.

Una pasada diaria por la lista de excepciones, cuyo tamaño depende de cuántos artículos planifique y de lo ancho que ponga el horizonte de excepciones, y no un vistazo a un cuadro de mando. El lanzamiento genera mensajes de adelantar, retrasar y anular, y el valor está en que alguien decida cuáles importan y actúe ese mismo día. Donde ese paso se salta, la lista crece hasta que nadie la abre y entonces se dice que el sistema hace ruido.

Las fechas de vigencia rigen solo lo que usan las nuevas explosiones; las órdenes que ya están abiertas no cambian. Una orden lanzada lleva la lista de componentes con la que se emitió y no se vuelve a explosionar, así que meter el cambio dentro de ella significa reemitir la orden o modificarla a mano. Compruebe qué fecha dispara la comprobación de vigencia (creación, lanzamiento, inicio planificado o fecha de necesidad), porque esa elección decide si el cambio llega siquiera a afectar a esa orden.