Diagnóstico técnico y ruta de mediación
Un reporte para acompañar a la Dirección de TI en una salida sana, justa y documentada del proyecto v19 con el partner saliente — que se le pague lo real y auditado, se libere el código y el conocimiento, y UNE recupere el control sin perder lo construido. Empatía con método; los resultados hablan.
◇ Transparencia — declaración de interés
Grupo Veniu es, a la vez, autor de este diagnóstico y candidato a retomar el proyecto. Lo declaramos por transparencia: el método aquí propuesto es reproducible por un tercero (cualquiera puede repetir la revisión y llegar al mismo dato), y la decisión —incluida la de validar estas cifras de forma independiente— queda íntegramente en manos de UNE. Documento de trabajo interno de UNE; no distribuir al partner saliente sin revisión legal.
El contexto humano — para no juzgar en frío
UNE no es un software: es una universidad de más de 36 años y 20,000+ alumnos. El sistema es la institución; el software es solo la herramienta. Este documento no reparte culpas — reconoce el trabajo de todos y busca el mejor resultado para las personas.
Grupo Veniu fue el primer partner que levantó las herramientas de software de UNE (su Odoo), desde una situación difícil — una ruptura previa que dejó a la institución sin acceso a lo suyo. De ahí se reconstruyó: POS y cafeterías primero, luego el salto a Enterprise, el Departamento de Compras, y la columna analítica (233 cuentas en 28 planes) que hoy la auditoría sigue viendo sana. Al corazón académico entró un segundo partner (Melkart, España); más tarde, tras la salida de Veniu (feb-2025), un tercer partner (Xmart) emprendió la migración a v19.
◇ La causa raíz no fue técnica — fue de gobernanza
Un proyecto que funcionaba se desgastó no por falta de trabajo ni por la herramienta, sino por la ausencia de una sola dirección que coordinara varias manos. Dos equipos sin la unión debida, un vaivén de direcciones, y una migración a v19 que se quedó sin conducción común. Lo decimos sin señalar a nadie: todos pusimos trabajo real, y a todos nos faltó una batuta única. Esa lectura es la que permite una mediación sana.
La realidad auditada — dos instancias, una verdad
En nuestra revisión (nada se modificó). El hallazgo que reencuadra la negociación: UNE opera hoy en el v16; la v19 que se cobra nunca llegó a producción.
🟢 v16 — la producción VIVA
34,911 alumnos · 9.2M facturas · 1.37M POS, facturando ~1,300/mes hasta jul-2026. Es el sistema real de UNE. 100% código (13 campos Studio). Detrás de Cloudflare.
🟠 v19 — la migración facturada, aún en STAGING
211 contactos de prueba ("Alumno test 3"), datos de ensayo, no migrada a producción. Con hallazgos típicos de un ambiente de prueba (seguridad, motor de cobro) que deben cerrarse antes de cualquier promoción a producción. Es un avance, no una entrega en operación.
⚠️ El dato central para la negociación
La v19 no está en producción: es un ambiente de staging con datos de prueba. Si se presenta como "entregada" pese a operar solo en staging, la Dirección de TI puede sostener —con esta evidencia verificable y reproducible— que la entrega aún no alcanzó la operación productiva.
Horas cobradas vs estructuras nativas de Odoo
Aquí la molestia del cliente tiene fundamento técnico. Odoo Enterprise ya trae de fábrica mucho de lo que a veces se factura como desarrollo. En la medida en que estas partidas se hayan facturado como desarrollo a la medida, corresponde reclasificarlas — contra el desglose de la factura, requerimiento por requerimiento. Distinguir código propio de configuración de algo nativo es el corazón de un cobro justo — con neutralidad, reconociendo también lo que sí es trabajo real.
| Funcionalidad | ¿De dónde sale? | Naturaleza del cobro |
|---|---|---|
| Colegiaturas / suscripciones | sale_subscription (Odoo Enterprise nativo) | config, no desarrollo |
| Presupuestos | budget.analytic (Odoo nativo) | config, no desarrollo |
| Cuentas analíticas | account.analytic.* (nativo) — base sembrada por Veniu | config / preexistente |
| CRM · POS · Facturación CFDI | Odoo nativo + Vauxoo (l10n_mx) | config / licencia de terceros |
Suite académica xma_* / school.* | Código propio del partner (24 mód / ~200 modelos) | desarrollo real |
| Referencia Santander · complemento CFDI edu | Código propio del partner | desarrollo real |
◇ Cómo leerlo con justicia (para ambas partes)
Sí hay desarrollo real del partner: la suite académica en código es trabajo legítimo con valor. Pero una parte importante de lo entregado/cobrado corresponde a estructuras nativas de Odoo (suscripciones, presupuestos, analítica, CRM, POS) que se configuran, no se programan — y a licencias de terceros (Vauxoo, Enterprise) que son costo de plataforma, no horas de desarrollo. Un cobro sano separa las tres capas: desarrollo propio, configuración de nativo, y licencias.
🔒 Dependencia de licencia (lock-in) — a resolver en la salida
El sistema del partner valida su licencia contra un servidor externo (cron License Validation).
Como en cualquier traspaso sano, el acuerdo de salida debe incluir la entrega del código fuente y la
liberación/portabilidad de la licencia, para que la continuidad de UNE no dependa de un componente externo.
La matriz de requerimientos — expectativa vs entrega
La posición de UNE: el entregable no cumplió la expectativa y quedó inconcluso — menos del 30% de lo firmado, con más del 70% faltante. Esta auditoría corrobora la señal (v19 en staging, no en operación) y propone cómo cuantificarlo objetivamente para que el número no sea opinión.
Método para auditar la matriz (defendible ante ambas partes)
- Requerimiento por requerimiento del anexo firmado → estado real: Entregado y en producción · Entregado en staging (no productivo) · Parcial · No iniciado.
- Prueba de vida: cada "entregado" se valida por uso real en producción — no por demo en staging. Lo que no está en el v16/producción, no está entregado a la operación.
- Clasificación del esfuerzo (según la tabla anterior): desarrollo propio · configuración de nativo · licencia de terceros. Solo la primera se cobra como horas de desarrollo.
- % de avance ponderado = suma de requerimientos entregados-y-productivos sobre el total firmado, con su peso. Ese % es el que sostiene una liquidación justa.
△ Brecha a documentar
Con la v19 en staging y sin operar, el avance productivo real es bajo frente a lo firmado — consistente con la lectura de "<30% cumplido". El monto exigido (>$1,000,000 MXN por el v19) debe contrastarse contra lo entregado-y-productivo, no contra lo prometido. Ese contraste es el fundamento de la mediación.
Estrategia de mediación — una salida digna para todos
El objetivo no es no pagarle al partner: es pagarle lo justo por lo real y auditado, con dignidad, a cambio de dejar a UNE en control — código, licencias y conocimiento. Un cierre que ambas partes puedan firmar sin resentimiento.
El desarrollo propio (suite académica) tiene valor y se paga. La empatía también aplica al partner que sale.
Lo que quedó en staging, lo nativo configurado y las licencias se separan del cobro de desarrollo.
El pago se libera contra entrega de código fuente + liberación de licencia + documentación.
El marco del acuerdo (no un número — una lógica defendible)
| Componente | Cómo se valúa | Se paga |
|---|---|---|
| Desarrollo propio productivo | Requerimientos entregados-y-en-uso × peso | Sí, a valor justo |
| Desarrollo en staging (no productivo) | Avance verificable, prorrateado | Parcial / a convenir |
| Configuración de nativo Odoo | Horas de consultoría, no de desarrollo | A tarifa de config, no de dev |
| Licencias de terceros (Vauxoo/Enterprise) | Costo de plataforma, transferible a UNE | No como horas del partner |
| Entrega de código + liberación de licencia | Condición del finiquito | Contraprestación del pago |
| Mecanismo de pago | Retención / escrow liberado contra entregables verificados | Protege a ambas partes |
✓ Por qué a Xmart también le conviene
Un finiquito limpio, documentado y sin litigio le da al partner un cierre digno, un pago por su trabajo real, y evita un desgaste reputacional. La alternativa —insistir en el monto completo por algo no productivo— abre una disputa que a nadie beneficia. La mediación protege a las dos partes.
Nota: este documento no fija un monto ni constituye asesoría legal. Aporta el marco técnico y de auditoría para que la Dirección de TI y el área legal/administrativa de UNE negocien con base en evidencia. El monto fino sale de la auditoría requerimiento-por-requerimiento sobre el v16 en producción.
Salvaguardas no negociables de la salida
Antes y durante el finiquito, seis resguardos protegen la operación viva (34,911 alumnos) y a las dos partes. Sin ellos no hay salida ordenada — solo un diagnóstico.
🔑 Accesos y credenciales
Inventario y custodia de admin/root de Odoo, PostgreSQL, servidor, Cloudflare, repos y llaves API — con rotación obligatoria al cierre.
🔌 Continuidad del servicio
Compromiso explícito de no-interrupción ni degradación del v16 durante la negociación, incluida la neutralización ordenada del cron de licencia.
🛡️ Datos personales (LFPDPPP)
NDA del partner saliente + devolución o destrucción certificada de datos de alumnos en todos los ambientes (staging v19 y respaldos incluidos). 34,911 titulares lo exigen.
©️ Propiedad intelectual
Cesión/licencia formal de los módulos propios (titularidad, alcance, perpetuidad) y claridad sobre la base heredada — que no se cambie un lock-in por otro.
💾 Respaldo certificado
Snapshot verificado de v16 + v19 + filestore con hash/acta antes de tocar nada. La foto oficial no es defendible sin esto.
📝 Acta de cierre
Documento que ambas partes firman: alcance liquidado, entregables recibidos, accesos rotados, datos devueltos. Cierra el ciclo sin cabos sueltos.
Plan de acción — interacción y traspaso de conocimiento
Foto oficial del estado (v16 productivo + v19 staging) con respaldo certificado previo, matriz de requerimientos requerimiento-por-requerimiento, con las dos partes invitadas a validar. Método neutral y reproducible.
Cruzar lo exigido (>$1M) contra lo entregado-y-productivo y la clasificación desarrollo/config/licencia. Presentar el marco de finiquito a Dirección de TI + legal.
Finiquito contra entrega de código fuente + liberación de licencia + documentación técnica. Acta de cierre que ambas partes firman.
Base de conocimiento por área (fiscal/nómina/compras/académico), transferencia a los key users de UNE, y documentación viva — que el saber no dependa de un solo partner nunca más.
Atender la deuda urgente del v16 en producción (motor de cobro, correos, seguridad) y decidir con datos: terminar la migración v19, replantearla, o modernizar el v16. Con UNE, no por UNE.
◇ Cómo se interactúa (para que no haya fricción)
Se le habla a cada área en su lenguaje y su emoción: al contador le pesa el riesgo (nómina, Addenda, SAT); al coordinador, el tiempo; al maestro, el alumno. La mediación se conduce con una sola voz técnica neutral que traduce intención, no jerga — para que el "sí" de cada parte llegue sin junta extra.
Cualquier acción cuesta — hay que rescatar lo más posible
El ejercicio de simulación de costos (rehacer desde cero vs migrar vs rescatar) dejó una sola lección: toda ruta implica tiempo y dinero. Rehacer un equivalente al sistema actual es del orden de medio millón de pesos; una salida caótica con el partner cuesta litigio y meses. Por eso la decisión sana es doble: rescatar todo lo que sirve (que es mucho) y cerrar la salida de Xmart limpia y pagada con justicia.
✎ El contrato con el que a Veniu le encantaría reencontrarse
Reconquista, no revancha. Nos encantaría retomar, en conjunto, porque cuando trabajamos juntos, funcionó — de la mano de UNE, con más método que nunca. Medimos antes de tocar; cada propuesta se juzga por el antes y el después. No venimos a declarar villanos: venimos a que el trabajo hable y a que todas las partes salgan de pie.
Revisión sobre v16 (producción) y v19 (staging) + repositorio del código, 2026. Nada se modificó en los sistemas. Cifras verificables y reproducibles; el número de finiquito se cierra con la auditoría requerimiento-por-requerimiento acordada por las partes.
Diagnóstico técnico y ruta de mediación
Un reporte para acompañar a la Dirección de TI en una salida sana, justa y documentada del proyecto v19 con el partner saliente — que se le pague lo real y auditado, se libere el código y el conocimiento, y UNE recupere el control sin perder lo construido. Empatía con método; los resultados hablan.
◇ Transparencia — declaración de interés
Grupo Veniu es, a la vez, autor de este diagnóstico y candidato a retomar el proyecto. Lo declaramos por transparencia: el método aquí propuesto es reproducible por un tercero (cualquiera puede repetir la revisión y llegar al mismo dato), y la decisión —incluida la de validar estas cifras de forma independiente— queda íntegramente en manos de UNE. Documento de trabajo interno de UNE; no distribuir al partner saliente sin revisión legal.
El contexto humano — para no juzgar en frío
UNE no es un software: es una universidad de más de 36 años y 20,000+ alumnos. El sistema es la institución; el software es solo la herramienta. Este documento no reparte culpas — reconoce el trabajo de todos y busca el mejor resultado para las personas.
Grupo Veniu fue el primer partner que levantó las herramientas de software de UNE (su Odoo), desde una situación difícil — una ruptura previa que dejó a la institución sin acceso a lo suyo. De ahí se reconstruyó: POS y cafeterías primero, luego el salto a Enterprise, el Departamento de Compras, y la columna analítica (233 cuentas en 28 planes) que hoy la auditoría sigue viendo sana. Al corazón académico entró un segundo partner (Melkart, España); más tarde, tras la salida de Veniu (feb-2025), un tercer partner (Xmart) emprendió la migración a v19.
◇ La causa raíz no fue técnica — fue de gobernanza
Un proyecto que funcionaba se desgastó no por falta de trabajo ni por la herramienta, sino por la ausencia de una sola dirección que coordinara varias manos. Dos equipos sin la unión debida, un vaivén de direcciones, y una migración a v19 que se quedó sin conducción común. Lo decimos sin señalar a nadie: todos pusimos trabajo real, y a todos nos faltó una batuta única. Esa lectura es la que permite una mediación sana.
La realidad auditada — dos instancias, una verdad
En nuestra revisión (nada se modificó). El hallazgo que reencuadra la negociación: UNE opera hoy en el v16; la v19 que se cobra nunca llegó a producción.
🟢 v16 — la producción VIVA
34,911 alumnos · 9.2M facturas · 1.37M POS, facturando ~1,300/mes hasta jul-2026. Es el sistema real de UNE. 100% código (13 campos Studio). Detrás de Cloudflare.
🟠 v19 — la migración facturada, aún en STAGING
211 contactos de prueba ("Alumno test 3"), datos de ensayo, no migrada a producción. Con hallazgos típicos de un ambiente de prueba (seguridad, motor de cobro) que deben cerrarse antes de cualquier promoción a producción. Es un avance, no una entrega en operación.
⚠️ El dato central para la negociación
La v19 no está en producción: es un ambiente de staging con datos de prueba. Si se presenta como "entregada" pese a operar solo en staging, la Dirección de TI puede sostener —con esta evidencia verificable y reproducible— que la entrega aún no alcanzó la operación productiva.
Horas cobradas vs estructuras nativas de Odoo
Aquí la molestia del cliente tiene fundamento técnico. Odoo Enterprise ya trae de fábrica mucho de lo que a veces se factura como desarrollo. En la medida en que estas partidas se hayan facturado como desarrollo a la medida, corresponde reclasificarlas — contra el desglose de la factura, requerimiento por requerimiento. Distinguir código propio de configuración de algo nativo es el corazón de un cobro justo — con neutralidad, reconociendo también lo que sí es trabajo real.
| Funcionalidad | ¿De dónde sale? | Naturaleza del cobro |
|---|---|---|
| Colegiaturas / suscripciones | sale_subscription (Odoo Enterprise nativo) | config, no desarrollo |
| Presupuestos | budget.analytic (Odoo nativo) | config, no desarrollo |
| Cuentas analíticas | account.analytic.* (nativo) — base sembrada por Veniu | config / preexistente |
| CRM · POS · Facturación CFDI | Odoo nativo + Vauxoo (l10n_mx) | config / licencia de terceros |
Suite académica xma_* / school.* | Código propio del partner (24 mód / ~200 modelos) | desarrollo real |
| Referencia Santander · complemento CFDI edu | Código propio del partner | desarrollo real |
◇ Cómo leerlo con justicia (para ambas partes)
Sí hay desarrollo real del partner: la suite académica en código es trabajo legítimo con valor. Pero una parte importante de lo entregado/cobrado corresponde a estructuras nativas de Odoo (suscripciones, presupuestos, analítica, CRM, POS) que se configuran, no se programan — y a licencias de terceros (Vauxoo, Enterprise) que son costo de plataforma, no horas de desarrollo. Un cobro sano separa las tres capas: desarrollo propio, configuración de nativo, y licencias.
🔒 Dependencia de licencia (lock-in) — a resolver en la salida
El sistema del partner valida su licencia contra un servidor externo (cron License Validation).
Como en cualquier traspaso sano, el acuerdo de salida debe incluir la entrega del código fuente y la
liberación/portabilidad de la licencia, para que la continuidad de UNE no dependa de un componente externo.
La matriz de requerimientos — expectativa vs entrega
La posición de UNE: el entregable no cumplió la expectativa y quedó inconcluso — menos del 30% de lo firmado, con más del 70% faltante. Esta auditoría corrobora la señal (v19 en staging, no en operación) y propone cómo cuantificarlo objetivamente para que el número no sea opinión.
Método para auditar la matriz (defendible ante ambas partes)
- Requerimiento por requerimiento del anexo firmado → estado real: Entregado y en producción · Entregado en staging (no productivo) · Parcial · No iniciado.
- Prueba de vida: cada "entregado" se valida por uso real en producción — no por demo en staging. Lo que no está en el v16/producción, no está entregado a la operación.
- Clasificación del esfuerzo (según la tabla anterior): desarrollo propio · configuración de nativo · licencia de terceros. Solo la primera se cobra como horas de desarrollo.
- % de avance ponderado = suma de requerimientos entregados-y-productivos sobre el total firmado, con su peso. Ese % es el que sostiene una liquidación justa.
△ Brecha a documentar
Con la v19 en staging y sin operar, el avance productivo real es bajo frente a lo firmado — consistente con la lectura de "<30% cumplido". El monto exigido (>$1,000,000 MXN por el v19) debe contrastarse contra lo entregado-y-productivo, no contra lo prometido. Ese contraste es el fundamento de la mediación.
Estrategia de mediación — una salida digna para todos
El objetivo no es no pagarle al partner: es pagarle lo justo por lo real y auditado, con dignidad, a cambio de dejar a UNE en control — código, licencias y conocimiento. Un cierre que ambas partes puedan firmar sin resentimiento.
El desarrollo propio (suite académica) tiene valor y se paga. La empatía también aplica al partner que sale.
Lo que quedó en staging, lo nativo configurado y las licencias se separan del cobro de desarrollo.
El pago se libera contra entrega de código fuente + liberación de licencia + documentación.
El marco del acuerdo (no un número — una lógica defendible)
| Componente | Cómo se valúa | Se paga |
|---|---|---|
| Desarrollo propio productivo | Requerimientos entregados-y-en-uso × peso | Sí, a valor justo |
| Desarrollo en staging (no productivo) | Avance verificable, prorrateado | Parcial / a convenir |
| Configuración de nativo Odoo | Horas de consultoría, no de desarrollo | A tarifa de config, no de dev |
| Licencias de terceros (Vauxoo/Enterprise) | Costo de plataforma, transferible a UNE | No como horas del partner |
| Entrega de código + liberación de licencia | Condición del finiquito | Contraprestación del pago |
| Mecanismo de pago | Retención / escrow liberado contra entregables verificados | Protege a ambas partes |
✓ Por qué a Xmart también le conviene
Un finiquito limpio, documentado y sin litigio le da al partner un cierre digno, un pago por su trabajo real, y evita un desgaste reputacional. La alternativa —insistir en el monto completo por algo no productivo— abre una disputa que a nadie beneficia. La mediación protege a las dos partes.
Nota: este documento no fija un monto ni constituye asesoría legal. Aporta el marco técnico y de auditoría para que la Dirección de TI y el área legal/administrativa de UNE negocien con base en evidencia. El monto fino sale de la auditoría requerimiento-por-requerimiento sobre el v16 en producción.
Salvaguardas no negociables de la salida
Antes y durante el finiquito, seis resguardos protegen la operación viva (34,911 alumnos) y a las dos partes. Sin ellos no hay salida ordenada — solo un diagnóstico.
🔑 Accesos y credenciales
Inventario y custodia de admin/root de Odoo, PostgreSQL, servidor, Cloudflare, repos y llaves API — con rotación obligatoria al cierre.
🔌 Continuidad del servicio
Compromiso explícito de no-interrupción ni degradación del v16 durante la negociación, incluida la neutralización ordenada del cron de licencia.
🛡️ Datos personales (LFPDPPP)
NDA del partner saliente + devolución o destrucción certificada de datos de alumnos en todos los ambientes (staging v19 y respaldos incluidos). 34,911 titulares lo exigen.
©️ Propiedad intelectual
Cesión/licencia formal de los módulos propios (titularidad, alcance, perpetuidad) y claridad sobre la base heredada — que no se cambie un lock-in por otro.
💾 Respaldo certificado
Snapshot verificado de v16 + v19 + filestore con hash/acta antes de tocar nada. La foto oficial no es defendible sin esto.
📝 Acta de cierre
Documento que ambas partes firman: alcance liquidado, entregables recibidos, accesos rotados, datos devueltos. Cierra el ciclo sin cabos sueltos.
Plan de acción — interacción y traspaso de conocimiento
Foto oficial del estado (v16 productivo + v19 staging) con respaldo certificado previo, matriz de requerimientos requerimiento-por-requerimiento, con las dos partes invitadas a validar. Método neutral y reproducible.
Cruzar lo exigido (>$1M) contra lo entregado-y-productivo y la clasificación desarrollo/config/licencia. Presentar el marco de finiquito a Dirección de TI + legal.
Finiquito contra entrega de código fuente + liberación de licencia + documentación técnica. Acta de cierre que ambas partes firman.
Base de conocimiento por área (fiscal/nómina/compras/académico), transferencia a los key users de UNE, y documentación viva — que el saber no dependa de un solo partner nunca más.
Atender la deuda urgente del v16 en producción (motor de cobro, correos, seguridad) y decidir con datos: terminar la migración v19, replantearla, o modernizar el v16. Con UNE, no por UNE.
◇ Cómo se interactúa (para que no haya fricción)
Se le habla a cada área en su lenguaje y su emoción: al contador le pesa el riesgo (nómina, Addenda, SAT); al coordinador, el tiempo; al maestro, el alumno. La mediación se conduce con una sola voz técnica neutral que traduce intención, no jerga — para que el "sí" de cada parte llegue sin junta extra.
Cualquier acción cuesta — hay que rescatar lo más posible
El ejercicio de simulación de costos (rehacer desde cero vs migrar vs rescatar) dejó una sola lección: toda ruta implica tiempo y dinero. Rehacer un equivalente al sistema actual es del orden de medio millón de pesos; una salida caótica con el partner cuesta litigio y meses. Por eso la decisión sana es doble: rescatar todo lo que sirve (que es mucho) y cerrar la salida de Xmart limpia y pagada con justicia.
✎ El contrato con el que a Veniu le encantaría reencontrarse
Reconquista, no revancha. Nos encantaría retomar, en conjunto, porque cuando trabajamos juntos, funcionó — de la mano de UNE, con más método que nunca. Medimos antes de tocar; cada propuesta se juzga por el antes y el después. No venimos a declarar villanos: venimos a que el trabajo hable y a que todas las partes salgan de pie.
Revisión sobre v16 (producción) y v19 (staging) + repositorio del código, 2026. Nada se modificó en los sistemas. Cifras verificables y reproducibles; el número de finiquito se cierra con la auditoría requerimiento-por-requerimiento acordada por las partes.