Prod Plan

Origen

Soy partidario de que todo Excel usado para controlar estándares importantes de una empresa debería descartarse en favor de un sistema de control exacto. Prod Plan nace de esa idea, aplicada a un problema muy concreto: planear la demanda de los clientes tomando en cuenta capacidad por área, por persona, tiempos hombre, horas por turno, demanda, costo y dificultad. Hacer ese cálculo a mano es humanamente casi imposible de sostener sin error, así que la respuesta fue construir la herramienta que faltaba.

Evolución

Fase 1 — Excel con macros y algoritmos de carga. La primera versión ya tenía una estructura sólida: macros y algoritmos que permitían una carga y ejecución rápida en el día a día. Pero un Excel siempre topa pared — cargar datos no era práctico, cada actualización significaba crear archivos sobre archivos, y dos personas no podían trabajar sobre la herramienta al mismo tiempo.

Fase 2 — Proplanner Viewer y Proplanner Dispatch. Para salir de esa pared nacieron dos apps portátiles: Viewer, para que el piso de producción consultara el plan del día, y Dispatch, para que logística diera salida a producto terminado. La idea central era colgarse del sistema SMB que ya manejaba la empresa para aprovechar el servidor y transferir archivos, logrando una herramienta local funcional de forma temprana. Resolvió el problema inmediato, pero trajo el suyo propio: riesgos de seguridad, errores cuando varios usuarios entraban a la vez y desfases de base de datos.

Fase 3 — Proplanner ERP Web (actual). De ahí nace la versión web sobre PostgreSQL: análisis de producción, sistema multi-idioma para que el idioma no sea barrera en empresas internacionales, reportes y actualización de base de datos en vivo, sistemas de API e integraciones MCP con Telegram.

Cómo funciona hoy

El módulo Proplan es donde el piso de producción ve el plan, la demanda, sus tendencias y su adherencia. El motor aplica desviación estándar y curva gaussiana sobre el histórico para calcular con precisión la capacidad disponible por día y por turno, y prorratearla entre las referencias con más riesgo de faltante.

Ese cálculo se traduce en un semáforo de prioridades: crítico si no hay piezas para cubrir lo del día, en tiempo si vamos bien, safety si hay excedente. Es la guía rápida de qué atender primero, sin depender del criterio de cada turno.

El módulo PMD gestiona la base de datos maestra de piezas por cliente: qué se modificó, quién y cuándo, con control de versiones y un sistema de recuperación ante pérdida de datos.

Stocks carga y analiza las existencias reales por semana, con bitácora de cuándo se subió cada archivo para que la planta siempre trabaje con datos frescos.

Todo se alimenta por API con tokens propios por integración — la base para las conexiones MCP y el bot de Telegram — sin depender de que alguien suba un archivo a mano.

Y ahí sigue, de fondo, el origen: el motor de cálculo que nació en Excel — calcular embarques, actualizar PMD, actualizar el split y el semáforo — es la misma lógica que hoy corre sobre PostgreSQL.