Propuesta de Desarrollo

1. Resumen Ejecutivo

Nexor 360 necesita convertir cada oportunidad comercial en una propuesta costeada, con márgenes protegidos y evidencia de valor — de forma rápida, consistente y auditable. Esta propuesta describe el desarrollo de un MVP en la nube que automatiza ese proceso de preventa de punta a punta, diseñado para operar de forma autónoma y quedar preparado para interconectarse con el desarrollo existente sin rehacer arquitectura.

El Desafío

Hoy la preventa de soluciones de tecnología en Nexor 360 depende de procesos manuales: armar la lista de materiales (BoM), cotizar y calcular márgenes a mano abre la puerta a errores costosos y a vender por debajo del piso de rentabilidad. Además, cada oportunidad se estructura distinto según quién la trabaje, y no queda evidencia clara del valor económico que se está dejando sobre la mesa.

• Errores de margen: calcular precios y descuentos manualmente arriesga cerrar tratos por debajo del piso de rentabilidad.
• Inconsistencia: cada cotización se arma diferente, sin reglas comunes ni trazabilidad.
• Riesgos no detectados: licencias faltantes, PoE insuficiente o ambientes fuera de rango se descubren tarde.
• Valor invisible: no hay una forma sistemática de mostrar la oportunidad de mayor valor (upsell) ni el potencial económico del canal.

La Solución

Un MVP cloud end-to-end que toma el requerimiento de una oportunidad y ejecuta un flujo único, controlado y determinístico: captura estructurada → clasificación → generación de BoM base → validación por reglas (gates) → costeo con márgenes → escenario de mayor valor (Shadow BoM Lite) → propuesta comercial (SOW) → vista interna de rentabilidad → tareas accionables → auditoría. La IA asiste en redacción y explicación, pero toda decisión crítica de margen, bloqueo y estatus corre por reglas versionadas y cálculos trazables, no por criterio improvisado.

2. Descripción de la Solución

El MVP es un flujo único de oportunidad, cloud, API-first y determinístico. Cada etapa recibe la anterior, la valida y produce un artefacto trazable — sin perder datos entre pasos.

Flujo End-to-End

Arquitectura

Aplicación web cloud administrada, API-first, con separación de dominios de datos y auditoría versionada. La lógica de negocio vive en un motor determinístico independiente de la interfaz.

Módulos del MVP

Ciclo de Vida de la Oportunidad

Cada oportunidad tiene un estado persistente. El sistema nunca libera una propuesta final si existe un bloqueo crítico.

3. Interoperabilidad y 2 Rutas de Conexión

El MVP opera de forma autónoma, pero queda preparado desde el diseño para conectarse con el desarrollo existente sin rehacer arquitectura. Contemplamos dos rutas posibles, no excluyentes: la decisión se toma con evidencia tras la revisión acotada del Sprint 0 (sección 4).

Contrato de Datos — Qué Consume y Qué Devuelve el MVP

Versionado y Compatibilidad del Payload

Para evitar que un cambio del desarrollo actual rompa el flujo:

• Versionado explícito en cada payload (schema_version), con política semver (cambios compatibles vs. cambios mayores).
• Campos obligatorios: validados por JSON Schema; su ausencia produce un blocking_issue trazable, nunca un fallo silencioso.
• Campos desconocidos: política tolerant reader — se ignoran y registran en auditoría sin romper el procesamiento (permite que el emisor evolucione sin tumbar al MVP).
• Cambios de estructura: un cambio mayor de schema exige nueva schema_version; el MVP mantiene compatibilidad con la versión previa durante una ventana definida.

4. Arquitectura de Datos y Sprint 0

Antes de construir pantallas se cierra la base de datos, las reglas y los criterios de conexión. Sprint 0 entrega la arquitectura de datos y el contrato de integración como base firme del proyecto.

Sprint 0 Reforzado — Entregables

La propuesta ya contempla en Sprint 0: modelo de datos por dominios, JSON schemas, catálogo y price book iniciales, project types, plantillas, gates y casos de prueba. Se agrega explícitamente:

• Contrato de datos publicado y versionado (sección 3).
• Criterios de data readiness — qué datos y en qué calidad se requieren para pasar de demo a piloto (alimenta el Data Readiness Gate).
• Ownership de dominios — qué componente/actor es dueño de cada dominio de datos (catálogo, price book, reglas, gates, PVI...).
• Endpoints principales — generate-deal-package (principal) + auxiliares (intake, generate-bom, evaluate-gates, render-sow).
• Campos obligatorios por contrato.
• Prueba inicial con payload real o representativo (sección 3).

Modelo de Datos por Bloques

Los dominios se separan desde el diseño para no mezclar variables en una sola base y permitir comparar escenarios con menos ruido. Cada bloque es dueño de su dato (ownership) y se versiona por separado; el motor los consume vía contrato, no por acoplamiento directo.

Revisión Acotada del Entorno Actual (dentro de Sprint 0)

No es una auditoría formal ni una ampliación de alcance — es una matriz de clasificación para reducir retrabajo y evitar arrastrar estructuras que hoy generen ruido o falsos positivos. Se clasifica cada componente existente:

• ✅ Reutilizar — ya cumple el contrato de datos y aporta valor.
• 🟡 Normalizar — aprovechable, pero no cumple el estándar.
• 🔴 No arrastrar — genera ruido, falsos positivos o acopla indebidamente.

5. Alcance y Entregables

El alcance del MVP queda gobernado por el SOW V8.4 de Nexor 360, que funciona como PRD y fuente de verdad del proyecto. A continuación, los entregables clave.

Fuera de Alcance (Fases Futuras)

6. Motor Financiero y Escenarios

El motor financiero (Deal CFO) mantiene las reglas suficientemente claras para que cada propuesta no dependa del criterio individual de quien la arma. Regla dura: el margen se calcula siempre sin IVA.

Qué contempla el motor

4 Escenarios Comerciales Predefinidos

En lugar de abrir un loop de prueba y error con infinitas variantes, el motor ofrece escenarios predefinidos filtrados por reglas:

7. Rol de la IA vs. Reglas

Cuando hay demasiadas variables juntas, un sistema puede sugerir opciones que parecen correctas pero que financiera o comercialmente no lo son. Por eso el principio es claro: la IA asiste, las reglas deciden. El control económico y técnico nunca depende del criterio libre de un modelo.

• Todo cálculo crítico (margen, piso, gates, costeo) corre por reglas determinísticas versionadas, no por el modelo.
• La IA explica su recomendación (qué regla la respalda), para que un revisor no técnico entienda el porqué.
• Esto evita el "loop de prueba y error": el sistema no propone infinitas variantes, sino los escenarios predefinidos (sección 6) filtrados por reglas.
• Menos dependencia de gates de funcionalidades específicas: los gates son de negocio/datos (piso, PoE, ambiente, datos faltantes), no de features de UI.

8. Controles, Casos de Prueba y Aceptación

Se confirma explícitamente qué controles entran a nivel MVP (en sus versiones de fase 1), los 9 casos de prueba mínimos que definen la aceptación objetiva, y la matriz que conecta cada componente con su evidencia.

Controles a Nivel MVP (fase 1)

9 Casos de Prueba Mínimos (aceptación objetiva)

Matriz de Trazabilidad y Aceptación

Permite validar el avance componente por componente, no solo con una demo general.

9. Roles y Permisos

Como el sistema maneja información sensible (márgenes, costos, descuentos, overrides, vista interna, PVI), se define una matriz básica de permisos por rol. Son 6 roles, alineados con el SOW V8.4 (§22.2).

10. Cronograma y QA Progresiva

Seis sprints sobre 8–9 semanas, con un colchón para QA/hardening y para la validación de los datos base que entrega Nexor. Cada sprint cierra con una demo funcional y evidencia concreta.

QA Progresiva (no se concentra al final)

• Los casos de prueba se ejecutan parcialmente conforme cada módulo esté disponible (por sprint), no por primera vez en el sprint final.
• El Sprint S5 es la validación documentada (corrida formal de los 9 casos + hardening), no la primera corrida.
• Esto reduce el riesgo de hallazgos críticos tardíos.

Cadencia de Revisiones Semanales

Cada sesión cierra con evidencia concreta, no solo con estatus general:

1. Zulunity entrega algo concreto y probable (ej.: contrato de datos validado, BoM generado, gate bloqueando, cálculo sin IVA, SOW exportable, vista interna, Shadow BoM Lite, casos aprobados).
2. Zulunity explica brevemente cómo revisarlo (guía corta, apta para no técnicos).
3. Nexor manda feedback por escrito (puede apoyarse en IA para redactarlo; nada se envía sin su revisión interna).
4. Zulunity responde/valida ese feedback aunque sea breve, para confirmar alineación y evitar corregir semanas después algo ya comentado.

11. Inversión

Precio cerrado por el alcance definido en el SOW V8.4, bajo el modelo de contrato por proyecto de Zulunity.

Formas de Pago

Ofrecemos dos esquemas sobre el mismo total. Ambos consideran el plazo de 8–9 semanas del proyecto.

Opción A — En 3 exhibiciones (30 / 30 / 40) · recomendada

Menor desembolso inicial y pagos atados al avance demostrable; es la más cómoda para el flujo del cliente.

Opción B — En 2 exhibiciones (50 / 50) · alternativa

Menos hitos administrativos, esquema más simple de gestionar.

12. Costos Operativos, Soporte y Nube

Para evitar confusiones posteriores, se precisa qué paga Nexor directamente, qué absorbe Zulunity, quién administra la nube y cómo se transfieren los accesos.

Costos Operativos y Operación de Nube

Plan de Soporte y Mantenimiento

Recomendación de Nube y Modelo de IA

Recomendación basada en costo, calidad, estabilidad y facilidad de mantenimiento:

13. IP, Handoff, Términos y Próximos Pasos

Al liquidar el 100% del proyecto, Nexor recibe la propiedad intelectual y un paquete de handoff completo. Aquí se detalla qué se entrega, los términos del proyecto, la información requerida por fase y los próximos pasos.

Propiedad Intelectual y Handoff

Al liquidar el 100% se entrega:

En el mismo evento se transfieren la titularidad de la nube y los accesos (proyecto GCP, dominio y componentes cloud), que Zulunity administró durante dev/piloto (sección 12).

Información Requerida por Fase

Para que la preparación de datos no retrase el arranque, se separa qué se necesita y cuándo:

Términos y Condiciones

1. Infraestructura y Servicios de Terceros: Los costos de Google Cloud, dominios, certificados, almacenamiento, correo transaccional y cualquier servicio externo no están incluidos en esta propuesta y serán responsabilidad del cliente.
2. Alcance Congelado por SOW: El alcance del MVP queda definido por el SOW V8.4 de Nexor 360, que actúa como fuente de verdad. Si durante el desarrollo aparecen cambios estructurales al proceso o nuevas reglas no documentadas, se evaluará su impacto en alcance, tiempo y costo.
3. Incluido vs. Adenda: La revisión acotada del entorno actual (sección 4) queda incluida en Sprint 0 dentro del tope definido (10 componentes / 8 h + 1 h por componente adicional). Cualquier adaptación, normalización o reutilización concreta del desarrollo existente, así como integraciones nuevas, se cotizan como adenda con su propio hito.
4. Propiedad Intelectual: Una vez liquidado el 100% del proyecto, la propiedad intelectual del código fuente desarrollado será transferida al cliente, junto con la titularidad de la nube y los accesos.
5. Cambios al Alcance: Cualquier funcionalidad adicional no contemplada en esta propuesta será analizada y cotizada por separado, en bloques de trabajo acordados con el cliente.
6. Migraciones e Integraciones: Esta fase no incluye integraciones oficiales con herramientas de fabricante (CCW, PXP, XVantage), CRM, ERP ni CPQ, ni cálculo oficial de rebates/PVI, salvo que se indique explícitamente en el alcance.
7. Datos Base del Cliente: Nexor 360 entregará o validará el catálogo de SKUs, precios, costos, rate card, reglas de margen, templates de SOW y escenarios de PVI. El modo piloto queda condicionado a la disponibilidad de estos datos (Data Readiness Gate).
8. Confidencialidad: Toda la información compartida durante el proyecto será tratada bajo principios de confidencialidad entre ambas partes.
9. Deslinde de Responsabilidad: Tras la entrega formal de la solución y la liquidación correspondiente, Zulunity queda deslindado de responsabilidades futuras sobre operación, evolución o mantenimiento del sistema, salvo contratación expresa del servicio opcional de soporte.

Riesgos Controlados

• Ambigüedad en la conexión con lo existente → prueba mínima de payload en Sprint 0 (sección 3).
• Integración abierta → separación explícita incluido vs. adenda (secciones 4 y 13).
• Información sensible → matriz de roles y permisos (sección 9).
• QA concentrado al final → pruebas progresivas por sprint (sección 10).
• Dudas de operación → costos, soporte y handoff precisados (sección 12).

Próximos Pasos

• Revisión de esta propuesta — Validación interna con el champion (Ernesto) antes de compartirla con Juanjo y los socios.
• Compartir con los socios — Con la propuesta cerrada, se comparte con Juanjo y los socios para revisión.
• Contrato y arranque — Con visto bueno: contrato, calendario de arranque, pago y sesión técnica inicial.
• Canal técnico en paralelo — Abrir el canal de trabajo técnico (WhatsApp) para acceso, revisión de repo/entorno, diccionario de datos y una primera sesión de arquitectura, en paralelo a lo comercial.
• Sesión de Kick-Off — Cierre de catálogos base, reglas de gates, rate card y casos demo prioritarios para el piloto.