Integración con sistemas de planificación

Cuando un modelo se conecta a un ERP, a un sistema de ejecución de la producción o a uno de gestión de almacén, lo que puede hacer no lo define el diseño ni el modelo: lo define la cuenta con la que escribe. Si el diseño dice que una persona aprueba las órdenes grandes pero la cuenta tiene permiso de aprobar, el límite depende de que la integración se porte bien, no de que el sistema lo impida.

Por eso la revisión de una integración empieza comparando los permisos que pide el diseño con los que de verdad tiene la cuenta, y sigue comprobando si el sistema de destino separa a quien crea de quien aprueba.

Compara la lista de permisos del diseño con la exportación del ERP. Un permiso añadido «para que no se queden órdenes en borrador» resuelve una molestia y, de paso, elimina el control que hacía seguro el piloto. A eso se suma que el ERP no impide que quien crea una orden sea quien la aprueba.

Un modelo de planificación no sabe que un número es absurdo si nadie se lo dice. Si la demanda que recibe se multiplica por diez, la orden que propone también. Un buen control de entrada compara cada orden con el consumo habitual del material, y uno de salida la retiene si se sale de proporción.

Compara cada orden con el consumo semanal de su material.

El informe tiene que decir cuántas órdenes por encima del tope del piloto salieron emitidas sin que una persona las aprobara. Las que no superan el tope pueden emitirse solas según el diseño; las que lo superan y aprobó alguien de compras tampoco cuentan.

La orden absurda no la inventó el modelo: la heredó de un pronóstico de cliente con un cero de más, que se cargó tal cual. El modelo hizo bien su trabajo con un dato malo. Eso cambia la corrección: no basta con ajustar el modelo, hay que controlar lo que entra desde fuera y mantener la aprobación humana en un lugar donde la integración no pueda saltarla.