Diseño e implementación de un sistema de inteligencia operativa en manufactura: formalización de dominio, ingeniería de datos y verificación multi-agente con inteligencia artificial

Documentar las reglas que solo existían en la cabeza del director de operaciones

Las reglas de clasificación de productos, rutas de transformación y lógica de reorden existían únicamente como conocimiento tácito del director de operaciones — sin documentación formal, sin control de versiones, y sin mecanismo de transferencia.

Contrato de verdad de dominio. Documento formal de 12 partes (v3.2) que codifica la totalidad de las reglas de negocio: clasificación de productos, rutas de transformación válidas, invariantes de datos, y decisiones que requieren aprobación del director. Cada regla validada contra entrevistas estructuradas, grabaciones operativas procesadas con herramientas de análisis de audio/texto asistidas por IA, y cuestionarios con 204 productos validados individualmente por el director de operaciones.

Modelo híbrido de manufactura. 4 rutas de transformación, cada una con reglas distintas de BOM, costeo y unidades de medida. Un quinto tipo — PASSTHROUGH (201 productos) — fue descubierto durante el análisis: BOMs 1:1 donde el empaque del proveedor es la unidad de venta sin transformación física. El sistema encadena automáticamente la orden de manufactura al confirmar la recepción.

flowchart LR
    A["Producto entrante\n(proveedor)"] --> B{"Ratio\nCM/CB"}
    B -->|"CM = CB\n(sin transformacion)"| C["DIRECTO\n3,113"]
    B -->|"CM > 1, CB = 1\n(se divide)"| D["FRACCION\n41"]
    B -->|"CM < CB\n(se arma)"| E["KIT / ARMADO\n1,894"]
    B -->|"CM = CB\nre-etiquetado"| F["REEMPAQUE\n615"]
    E -->|"BOM 1:1"| G["PASSTHROUGH\n201"]

    style C fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style D fill:#141412,stroke:#e65100,color:#EDEDEC
    style E fill:#141412,stroke:#5b8def,color:#EDEDEC
    style F fill:#141412,stroke:#a855f7,color:#EDEDEC
    style G fill:#141412,stroke:#555554,color:#EDEDEC
        

Validación triangulada. Las reglas de negocio para 627 productos se validaron cruzando tres fuentes independientes: análisis cuantitativo (94.4% de coincidencia en patrón de códigos), hipótesis generada por LLM, y validación directa del director de operaciones con citas textuales — incluyendo un caso donde el experto corrigió explícitamente al modelo de inteligencia artificial.

Auditoría adversarial multi-agente. Cuatro agentes de IA ejecutados en paralelo (verificador, analista, abogado del diablo, árbitro) descubrieron un defecto semántico crítico: 431 listas de materiales con variantes múltiples estaban estructuradas como AND (todos los componentes requeridos simultáneamente) cuando la realidad operativa era OR (el operador elige según disponibilidad). Sin esta corrección, toda orden de manufactura para kits multi-variante habría sido imposible de completar. 2,550 BOMs reestructurados a 3,028 BOMs alternativos.

Ingeniería inversa de lógica de negocio. La fórmula de velocidad de reorden estaba codificada en macros VBA dentro de hojas de cálculo del sistema legacy. Se extrajo, formalizó y validó contra 3,302 filas de salida del macro original con 100% de coincidencia. El análisis reveló una estrategia anti-desabasto de ventana dual que un promedio móvil simple subestimaba en la mayoría del catálogo.

Eliminación de procesos redundantes. Un checkpoint físico entre armado y punto de venta (computadora + escáner + impresora) fue eliminado al verificar que el ERP proporciona el mismo control vía órdenes de manufactura y transferencias internas.

block-beta
    columns 1
    L5["Capa 5: App Inteligencia Operativa (95K LOC)"]
    L4["Capa 4: ERP SaaS — regenerable desde Capa 3"]
    L3["Capa 3: CSVs de exportacion — versionados en Git"]
    L2["Capa 2: Pipeline ETL (18K LOC Python) — reproducible en 5 minutos"]
    L1["Capa 1: Archivos fuente inmutables"]

    style L5 fill:#141412,stroke:#a855f7,color:#EDEDEC
    style L4 fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style L3 fill:#141412,stroke:#5b8def,color:#EDEDEC
    style L2 fill:#141412,stroke:#e65100,color:#EDEDEC
    style L1 fill:#141412,stroke:#555554,color:#EDEDEC
        

Pipeline de limpieza, normalización y migración de 8,700+ SKUs

Los datos del sistema legacy presentaban problemas en todas las dimensiones: nombres inconsistentes, costos faltantes en aproximadamente un tercio del catálogo, códigos de barras sin estrategia documentada, clasificaciones erróneas, decimales truncados, y nombres de fabricante con cientos de variantes de escritura. Todo el pipeline fue diseñado y desarrollado orquestando flujos agénticos como instrumento de ingeniería.

Pipeline de nomenclatura de dominio (12 capas). Algoritmo que evolucionó a través de 5 versiones hasta converger. Aplica 12 transformaciones secuenciales: smart title-case con preservación de siglas y acrónimos, normalización de unidades de medida (con desambiguación de contexto: “31G” es un calibre de aguja, no 31 gramos), deduplicación de concentraciones compuestas, detección de información redundante entre nombre y versión, limpieza de contadores de empaque legacy, y sufijo de fabricante (80% cobertura). 8,700+ nombres procesados. Auditado por 5 agentes de IA en paralelo.

Motor de deducción de costos (6 estrategias en cascada). Algoritmo que explota conocimiento de dominio para inferir costos faltantes. Cada estrategia usa la mediana de márgenes de productos de referencia con costos reales. S1: recuperación de margen cero intencional. S2: mismo compuesto activo + mismo fabricante + misma formulación. S3: mismo compuesto + mismo fabricante. S4: mismo compuesto. S5: misma categoría + fabricante. S6: misma clasificación + categoría. Resultado: 1,506 de 1,523 productos resueltos automáticamente (98.9%). 6 requirieron captura manual.

flowchart TD
    A["Producto sin costo\n(~33% del catalogo)"] --> S1
    S1["S1: Margen cero\nintencional"] -->|"no aplica"| S2
    S1 -->|"resuelto"| OK["Costo asignado\n1,506 automaticos\n(98.9%)"]
    S2["S2: Mismo compuesto\n+ fabricante + forma"] -->|"no aplica"| S3
    S2 -->|"resuelto"| OK
    S3["S3: Mismo compuesto\n+ fabricante"] -->|"no aplica"| S4
    S3 -->|"resuelto"| OK
    S4["S4: Mismo compuesto"] -->|"no aplica"| S5
    S4 -->|"resuelto"| OK
    S5["S5: Misma categoria\n+ fabricante"] -->|"no aplica"| S6
    S5 -->|"resuelto"| OK
    S6["S6: Misma clasificacion\n+ categoria"] -->|"no aplica"| M["Manual\n(6 productos)"]
    S6 -->|"resuelto"| OK

    style OK fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style M fill:#141412,stroke:#e65100,color:#EDEDEC
        

Normalización de fabricantes. Diccionario curado de 106 entradas que consolida cientos de variantes de nombre en formas canónicas. Cinco categorías de corrección: errores tipográficos, separación y puntuación, acentos, mayúsculas, y consolidación corporativa. Cada entrada requiere conocimiento del sector para distinguir errores reales de grafías intencionales de marca.

Normalización GCD de ratios BOM. El ERP requiere cantidades enteras en órdenes de manufactura. 204 ratios no enteros entre unidades de almacén y unidades de venta fueron convertidos a pares enteros vía GCD con escalado decimal. Incluyó detección forense de un bug de truncamiento decimal en el sistema legacy que producía ratios falsos en productos afectados.

Análisis empírico de 268,928 transacciones. La estrategia de códigos de barras se definió analizando 3 años de ventas POS en vez de confiar en documentación existente. El análisis descubrió un patrón de venta mayorista que ningún stakeholder había articulado — miles de transacciones donde el equipo usaba códigos de almacén directamente en punto de venta. Cobertura final: 100% en 8,718 productos.

flowchart LR
    SRC["Fuentes inmutables\nsistema legacy\n+ entrevistas"] --> ETL["Pipeline ETL\nload > correct >\ndeduce > transform\n> export"]
    ETL --> DB[("SQLite\nintermedia")]
    DB --> CSV["4 CSVs\nproducts / components\nboms / inventory"]
    CSV --> ERP["ERP SaaS\nimportacion"]
    CSV --> VER["5 agentes\nverificacion\n52/52 checks"]
    ERP --> E2E["51 pruebas\nE2E en vivo"]

    style DB fill:#141412,stroke:#5b8def,color:#EDEDEC
    style ERP fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style VER fill:#141412,stroke:#e65100,color:#EDEDEC
    style E2E fill:#141412,stroke:#C4A97D,color:#EDEDEC
        

Verificación. 5 agentes de verificación independientes (trazabilidad fuente→DB, cross-references CSV, matemática BOM, nomenclatura de dominio, trazabilidad de correcciones): 52/52 checks PASS. Auditoría técnica completa de 448 líneas identificó 31 bugs (3 de severidad alta, todos resueltos). 51 pruebas E2E contra la instancia en producción: compras, manufactura, transferencias, POS, mermas, edge functions, FEFO. Go-live en 4 semanas.

Aplicación de 95K líneas de código como capa de inteligencia sobre el ERP

El ERP resuelve la infraestructura de datos. Las decisiones diarias — qué comprar, a qué precio, cuánto manufacturar, qué transferir, qué está por caducar — requieren una capa de inteligencia artificial que conecte datos de múltiples fuentes y los presente al operador correcto en el momento correcto.

Arquitectura por persona. Cada pantalla está construida para el flujo de trabajo específico de su operador. Solo el cajero interactúa directamente con el ERP. Los otros 8 roles operan a través de interfaces especializadas con autenticación dual (email para gerencia, PIN de 4 dígitos para personal de piso). 193 componentes React, 54 hooks custom.

flowchart TD
    subgraph app ["App Inteligencia Operativa (React + TypeScript + Supabase)"]
        R1["Gerencia\ndashboard 15 KPIs\n+ Balanced Scorecard"]
        R2["Compras\nofertas + scoring\n+ benchmarking"]
        R3["Manufactura\nplan demanda\n+ ordenes MO"]
        R4["Almacen\nsolicitudes\n+ transferencias"]
        R5["Recepcion\ncotejo offline-first\n+ lotes multi-fecha"]
        R6["Mayoreo\nventas B2B"]
        R7["Tesoreria\nconciliacion"]
        R8["Bodega ext.\ninventario remoto"]
    end

    subgraph pos ["ERP POS (nativo)"]
        R9["Cajero\ncobro + facturacion"]
    end

    subgraph ext ["Canales externos"]
        MSG["Canal mensajeria\nofertas proveedores"]
        WS["WebSocket\nnotificaciones push"]
    end

    R1 & R2 & R3 & R4 & R5 & R6 & R7 & R8 --> EF["46 Edge Functions\n(Supabase/Deno)"]
    R9 --> ERP["ERP SaaS"]
    EF --> ERP
    MSG --> EF
    EF --> WS

    style app fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style pos fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style ext fill:#141412,stroke:#5b8def,color:#EDEDEC
    style ERP fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style EF fill:#141412,stroke:#e65100,color:#EDEDEC
        

Motor de análisis de ofertas de proveedores (1,300+ líneas). Canal de mensajería que recibe ofertas en 11 formatos distintos (texto, imágenes, PDFs, tablas, mezcla de prosa y datos). Gemini 2.5 Flash parsea contenido no estructurado — incluyendo artefactos de OCR, timestamps y ruido conversacional — a JSON normalizado con nomenclatura del sector. Luego un motor de matching de 5 prioridades (P0: correcciones manuales, P1: compuesto activo extraído por IA, P1.5: diccionario de 200+ marcas auto-enriquecido del catálogo, P2: coincidencia directa, P3: fuzzy) cruza cada producto contra 8,700+ SKUs, calcula meses de stock, velocidad de venta, aplica lógica de compra por tiers de velocidad, y genera recomendaciones de compra/no-compra/escalar por producto.

flowchart LR
    subgraph input ["Entrada (11 formatos)"]
        P1["Imagen"]
        P2["PDF"]
        P3["Texto / tabla"]
    end

    MSG["Canal\nmensajeria"] --> WH["webhook\nparsing"]
    P1 & P2 & P3 --> MSG

    WH --> AI["Gemini 2.5 Flash\nextraccion\nestructurada"]
    AI --> MATCH["Motor matching\n5 prioridades\n8,700+ SKUs"]

    MATCH --> AN["Analisis\nvelocidad + stock\n+ caducidad"]
    AN --> DEC{"Decision"}
    DEC -->|"comprar"| BUY["COMPRAR"]
    DEC -->|"rechazar"| NO["NO COMPRAR"]
    DEC -->|"escalar"| ESC["ESCALAR"]

    AN --> BM["Benchmark\nprecios\nmercado"]

    style AI fill:#141412,stroke:#5b8def,color:#EDEDEC
    style MATCH fill:#141412,stroke:#a855f7,color:#EDEDEC
    style BUY fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style NO fill:#141412,stroke:#c62828,color:#EDEDEC
    style ESC fill:#141412,stroke:#e65100,color:#EDEDEC
    style BM fill:#141412,stroke:#5b8def,color:#EDEDEC
        

Benchmarking de precios contra competidores regionales. Antes de recomendar una compra, el sistema consulta precios de mercado en múltiples cadenas competidoras vía web scraping automatizado. Validación de dominio: filtra descuentos falsos, rechaza resultados que no coinciden en concentración/presentación/formulación, y convierte precios mayorista a equivalente kit. El comprador recibe un veredicto cuantificado — buen precio, precio normal, o precio alto — con datos de mercado como respaldo para negociar.

Motor de métricas de stock. Pipeline que sintetiza datos del ERP (8,700+ productos con stock multi-ubicación y lotes con caducidad), historial de ventas legacy (1.3 millones de filas, varios años), órdenes de compra en tránsito, y mapeo de listas de materiales. Produce 20+ columnas derivadas por producto: velocidad de venta con estrategia anti-desabasto, meses de cobertura, cantidad sugerida de reorden, y clasificación de estado (activo / tapado / muerto — donde “tapado” distingue productos sin ventas recientes por desabasto, no por falta de demanda, con factor de descuento 0.5x).

Recepción offline-first. Sistema de pre-cotejo respaldado por IndexedDB para verificación de mercancía en almacén sin conectividad WiFi. Escaneo de códigos de barras, conteo, captura de lotes con fechas de caducidad múltiples por línea, fotos de discrepancias, notas de negociación. Cinco estados de ciclo de vida. Sincronización automática al recuperar conexión. Al recibir, auto-reactiva productos dormidos en el ERP y envía alertas si hay discrepancias de cantidad.

Sustitución inteligente FEFO por compuesto activo. Cuando un cajero selecciona un producto, el sistema busca unidades próximas a caducar del mismo compuesto activo — no solo del mismo nombre de marca — y sugiere la sustitución. Si Producto A (mismo compuesto, misma concentración, diferente marca) caduca en 15 días, el sistema lo detecta y recomienda vender primero el que está por vencer. Reducción directa de merma.

Balanced Scorecard operativo. 15 KPIs configurables con umbrales de semáforo, organizados en 4 perspectivas (financiera, inventario, operaciones, equipo). Los KPIs están vinculados a empleados específicos con metas diarias y semanales. Gestión de rendimiento de nivel enterprise aplicada a una operación de tamaño medio.

flowchart TB
    subgraph client ["Frontend (React + TypeScript)"]
        UI["24 pantallas\nrol-especificas"]
        CACHE["Cache local\nTTL 10 min"]
        IDB["IndexedDB\noffline-first"]
        UI <--> CACHE
        UI <--> IDB
    end

    subgraph supa ["Backend (Supabase)"]
        PG[("PostgreSQL\n70 migraciones\nRLS por fila")]
        EF["46 Edge Functions\n(Deno)"]
        RT["Realtime\n(WebSocket)"]
        PG <--> EF
        PG --> RT
    end

    subgraph erp ["ERP SaaS"]
        API["JSON-RPC API"]
        POS["Punto de Venta"]
        MFG["Manufactura"]
        INV["Inventario"]
        PUR["Compras"]
    end

    subgraph ai ["Inteligencia Artificial"]
        GEM["Gemini 2.5 Flash"]
    end

    subgraph ext2 ["Canales Externos"]
        MSG2["Canal Mensajeria"]
    end

    UI <-->|"HTTPS"| EF
    RT -->|"push"| UI
    EF <-->|"JSON-RPC"| API
    EF <-->|"REST"| GEM
    MSG2 -->|"webhook"| EF
    EF -->|"alertas"| MSG2

    style client fill:#141412,stroke:#555554,color:#EDEDEC
    style supa fill:#141412,stroke:#e65100,color:#EDEDEC
    style erp fill:#141412,stroke:#C4A97D,color:#EDEDEC
    style ai fill:#141412,stroke:#5b8def,color:#EDEDEC
    style ext2 fill:#141412,stroke:#a855f7,color:#EDEDEC