De la conversación de WhatsApp al equipo entregado: un solo sistema que mueve la venta, el pago, la producción y la postventa — sobre las herramientas que Fénix ya usa, sin reemplazarlas.
Fénix Serigrafía · equipos de serigrafía y sublimaciónSeptiembre 2026v5 · mapa TO-BE, certificado por pantalla y código limpio
Qué cambió en esta versión. Se agregó un mapa interactivo AS-IS → TO-BE en la consola: cada etapa muestra cómo opera hoy (con su dolor), qué falta y cómo queda con Fénix OS, con un botón que corre el recorrido end-to-end en vivo. Además se certificó pantalla por pantalla (escritorio y móvil), se limpió el código (código muerto y un archivo de caché con datos de cuenta que no debía estar) y se emparejaron los ambientes (mismo comportamiento en todos; Producción intacta). La suite está en 285 pruebas en verde. Los 12 motores siguen en vivo (datos de demostración); lo único pendiente para datos reales son los accesos de Fénix y dos decisiones: PAC y proveedor de IA.
01 El diagnóstico
Reconstruimos los 13 procesos de la operación (Fase 5). Estos son los hallazgos que cuestan dinero y tiempo hoy:
Se promete lo que no hay Alta
Almacén descuenta el material tarde, así que Ventas cotiza sobre stock que ya está comprometido. (D01 · D08)
El pago depende de una persona Alta
Se confirma preguntándole a quien tiene acceso a las cuentas; sin respaldo si no está. (D02)
Calidad se autoevalúa Alta
La misma estación que produce revisa su propia pieza; no hay validación independiente. (D03)
WhatsApp como sistema paralelo Alta
Ahí se toman decisiones y se guarda evidencia oficial, sin integrar a Odoo. (D04)
Más: doble captura en Logística (Excel + Odoo), verificación de material duplicada, y tres áreas (Compras, Finanzas, Diseño) que alimentan el flujo de manera informal.
02 La solución: un motor sobre el stack real de Fénix
Fénix OS no reemplaza las herramientas; las conecta y orquesta, en las dos direcciones. Odoo es el sistema de registro.
Cotización — valida stock real, precio + IVA, marca lo que requiere fabricación.
Producción — orden que reserva + checkpoint de calidad independiente. (D03)
Cobros — liga de pago y confirmación automática. (D02)
Logística — cotiza, guía, rastreo y aviso al cliente. (D09/D10)
Compras — punto de reorden → cantidad sugerida → orden de compra. (D05)
Garantías — alta por n.º de serie y validación de vigencia.
Facturación — arma el CFDI 4.0 completo, listo para timbrar.
Reportes — ventas, entregas a tiempo, recompra y embudo para dirección.
Soporte — clasifica, sugiere desde la base de conocimiento y rutea (IA por definir).
Plataforma y seguridad
Consola Fénix OS desplegada, con Dashboard, módulos y Conexiones.
Cada módulo muestra su motor en vivo con datos de demostración — se prueba botón por botón.
Usuarios, roles y permisos (admin, consultor, operador, colaborador, lector).
Webhooks reales con verificación de firma por proveedor (HMAC).
Ambientes Dev / Staging / Producción separados.
Captura del AS-IS por área, con evidencia adjunta.
Procesador AS-IS → TO-BE: cada respuesta de Fénix se convierte en mejoras concretas por módulo (decisión, fuente del dato, evidencia, pendiente). Automático — un formulario nuevo entra sin reprogramar.
Cómo se enciende con datos reales. Cada motor corre hoy sobre un adaptador de demostración. Al cargar los accesos de Fénix en Conexiones, se cambia la fuente de datos por el sistema real (Odoo, Mercado Pago, Skydropx…) sin tocar el motor, el flujo ni la pantalla: es el mismo código, con datos reales.
04 Cómo cierra cada hallazgo
Hallazgo
Cómo lo resuelve Fénix OS
D01 · Sobrepromesa
Ventas cotiza contra disponible-para-prometer (físico − comprometido); sin stock, dispara la orden de fabricación con fecha calculada.
D02 · Pago 1 persona
Pago en línea que confirma solo (webhook); fuera de línea, cualquiera del rol Finanzas lo confirma con evidencia. Con respaldo.
D03 · Calidad
El sistema exige inspector distinto del productor; la OT no avanza sin ese visto bueno.
D04 · WhatsApp paralelo
El mensaje entra a la Bandeja y se liga al negocio en Odoo/HubSpot; deja de ser el expediente.
D05 · Compra informal
El motor de Compras vigila el punto de reorden y sugiere qué y cuánto pedir; genera la orden de compra en Odoo.
D09 · Doble captura
Una sola fuente en el sistema; se retira el Excel paralelo tras migrar lo que registre de más.
05 Seguridad y robustez Endurecido
Antes de conectar datos reales, el sistema se sometió a un ataque adversarial (se intentó romperlo a propósito). Se encontraron y cerraron 5 vulnerabilidades reales, cada una blindada con pruebas que fallan si alguien la reintroduce.
Riesgo
Cómo quedó blindado
Pago duplicado
Un pago que llega dos veces (reintento del webhook o casi simultáneo) ya no crea dos órdenes de trabajo ni cobra doble: se bloquea en proceso y se verifica el estado real.
Datos de cliente maliciosos (XSS)
Nombres/mensajes que llegan de WhatsApp u Odoo se escapan antes de mostrarse — no pueden inyectar código en la consola.
Saltarse la fase de solo-lectura
Nadie puede forzar una escritura mientras la conexión está en solo lectura: la fase se decide por el estado real de la conexión, no por la petición.
Sincronización duplicada bajo carga
Varias sincronizaciones simultáneas del mismo dato producen un solo efecto (idempotencia real, con reintento si algo falla).
Inventario incoherente
El disponible-para-prometer nunca es negativo; si algo quedó sobre-comprometido, se muestra el déficit en vez de esconderlo.
285
Pruebas automáticas (39 son ataques)
5
Vulnerabilidades cerradas
0
Bugs abiertos
También resistieron sin fallas: autenticación (tokens firmados, expiración), permisos por rol (nadie hace lo que no le toca), verificación de firmas de webhook por proveedor con anti-replay (un evento viejo o alterado se rechaza), y los controles del taller (calidad exige inspector distinto del productor).
Cómo está verificado. Todo lo anterior está probado por código (285 pruebas automáticas), por API en vivo contra el sitio desplegado, y pantalla por pantalla en escritorio y móvil (sin errores ni desbordes). La certificación con los datos reales de cada herramienta (Odoo, HubSpot, etc.) queda pendiente de que Fénix cargue sus accesos — hoy los motores corren con datos de demostración.
06 El plan por olas
Los tres bloques ya tienen su motor construido. El despliegue por olas ordena en qué orden se enciende con los datos reales de Fénix.
Ola 1 · Vender y producir
Bandeja + Clientes 360
Cotizaciones (stock real)
Cobros → arranca la OT
Órdenes de trabajo + calidad
Ola 2 · Abastecer y facturar
Inventario (fuente única)
Compras (punto de reorden)
Facturación CFDI PAC
Garantías por n.º de serie
Ola 3 · Entregar y medir
Logística + rastreo
Soporte con IA Proveedor
Reportes 360 para dirección
Recompra / segunda venta
07 Lo pendiente: accesos y dos decisiones
La recepción, la firma, el ruteo y los 12 motores ya están completos y probados. Para encender con datos reales necesitamos, de Fénix:
Accesos por sistema
Odoo con API externa (plan Custom / on-premise) + usuario de servicio.
HubSpot Private App (token) + App Secret para firmas.
respond.io token del workspace + secreto de webhook.
WooCommerce Consumer Key/Secret + secreto de webhook.
Mercado Pago Access Token + clave del webhook.
Skydropx credenciales OAuth.
Dos decisiones de Fénix
PAC de facturación — qué timbrador usa Fénix. El motor ya arma el CFDI 4.0 completo; al elegir el PAC se conecta sin tocar el resto. No se asume ninguno.
Proveedor de IA para Soporte — con qué motor de IA responde el módulo de Soporte. Mismo patrón: es un dato de Fénix, no un pendiente técnico.
Siguiente reunión. Con los accesos cargados en Conexiones (por ambiente, seguros y verificados en vivo), encendemos la Ola 1 de punta a punta con la operación real de Fénix.