Evaluación de viabilidad comercial, técnica, operativa, legal y tecnológica, integrada con evidencia primaria trazable de Oracle NetSuite, SAP, Odoo y compliance SaaS.
Estado: borrador conceptual interno
Riesgo contractual: crítico
PDF contrastado: 10 páginas
Uso: toma de decisión ejecutiva
Integración de evidencia: 16 julio 2026
Decisión recomendada
Dictamen ejecutivo
El modelo de negocio propuesto es viable, pero el documento no está listo para aprobarse, ofrecerse comercialmente ni trasladarse al contrato maestro en su redacción actual.
El problema no es el modelo SaaS. El borrador convierte decisiones comerciales en garantías técnicas, operativas y jurídicas que todavía no están suficientemente definidas, medidas o demostradas.
Definición recomendada: HolosERP es un ERP SaaS totalmente gestionado, con evolución a la medida y extensibilidad controlada. HumandNet administra la infraestructura y la plataforma base. El cliente administra su operación, usuarios, permisos, configuración y datos dentro de las capacidades habilitadas. Los desarrollos, integraciones y componentes externos se incorporan mediante un proceso gobernado de evaluación, construcción, prueba, despliegue y soporte.
No aprobar todavía como instrumento contractual o promesa comercial externa. Antes deben corregirse las contradicciones y afirmaciones absolutas; definirse métricas y anexos operativos; validarse la capacidad durante 60–90 días; realizarse simulacros de restauración, incidente crítico y offboarding; y obtenerse revisión de un abogado mexicano especializado en tecnología, privacidad y propiedad intelectual.
Resultado general de la auditoría
Dictamen y riesgo por dimensión
Dimensión
Dictamen
Nivel de riesgo
Viabilidad comercial
Viable con correcciones de posicionamiento, alcance y promesas
Alto
Viabilidad técnica
Viable, pero no demostrada de forma homogénea para toda la cartera
Alto
Viabilidad operativa
Parcial; faltan métricas, capacidad y procedimientos globales
Crítico
Viabilidad legal
Requiere correcciones sustanciales en PI, datos, privacidad y salida
Crítico
Competitividad
Diferenciación válida, pero más restrictiva que los referentes
Medio-alto
Preparación contractual
No lista
Crítico
Capacidad operativa observada
17 capacidades evaluadas
0 demostradas globalmente
No existe aún evidencia reproducible para toda la cartera.
Evidencia parcial
11 parcialmente demostradas
Hay prácticas o casos puntuales, pero no controles globales acreditados.
Brecha material
5 no demostradas · 1 contradicha
Una capacidad contradice otra política vigente.
La ausencia de evidencia global no prueba que la capacidad no exista. Sí significa que todavía no puede ofrecerse como compromiso contractual reproducible para toda la cartera.
Bloqueadores críticos
Hallazgos que bloquean aprobación o comercialización
Prioridad
Hallazgo
Impacto
P0
“Todo desarrollo es PI de HumandNet” no distingue Odoo, OCA, vendors, copyleft, PI previa ni obra encargada.
Disputas de titularidad e incumplimiento de licencias.
P0
Se reconoce la titularidad de datos del cliente, pero no se garantiza una salida completa y utilizable.
Lock-in, controversias comerciales y riesgo regulatorio.
P0
“Disponible, respaldada y actualizada” carece de disponibilidad, RPO, RTO, retención y política de versiones.
Promesas imposibles de medir o defender.
P0
El SLA S1 de 1 hora/8 horas no está respaldado por guardias, monitoreo, capacidad histórica ni una política unificada.
Incumplimiento contractual recurrente.
P0
El máximo de 10 días para cotizar contradice la duración acumulada de E1–E5.
Promesa estructuralmente incumplible.
P1
P3 prohíbe componentes externos mientras P4 admite excepciones.
Política contradictoria e inaplicable al ecosistema real.
P1
El offboarding se declara emitido, pero no se acreditó un procedimiento integral ensayado.
Salida no ejecutable ni cotizable.
P1
La fórmula de estimación puede sumar entre 85% y 125% con contingencia.
Cotizaciones inconsistentes y riesgo de margen.
Contradicciones y afirmaciones por corregir
SaaS, PaaS y administración del cliente
“El cliente usa la plataforma, nunca la administra” es excesivo. Un servicio sigue siendo SaaS aunque el cliente administre usuarios, roles, configuraciones y datos dentro de la aplicación. Una API, SDK o extensión controlada tampoco lo convierte automáticamente en PaaS.
El cliente no recibe administración sobre infraestructura, sistema operativo o motor de base de datos. Podrá administrar usuarios, permisos, configuración funcional, integraciones y datos dentro de las capacidades expresamente habilitadas.
Datos, base de datos y propiedad intelectual
La separación entre “datos del cliente” y “contenedor de HumandNet” es insuficiente. Debe existir una matriz para datos operativos y personales; configuración funcional; esquema estándar Odoo/PostgreSQL; código propio; código Odoo, OCA y vendors; desarrollos financiados por el cliente; documentación, secretos e infraestructura.
Un dump puede incluir información, relaciones, configuración y metadatos, pero no necesariamente todo el código fuente de HumandNet. Gran parte del esquema puede derivar de Odoo y sus módulos.
No se entrega acceso directo ni copia nativa de la base de datos como parte del servicio estándar, salvo obligación legal o acuerdo expreso. HumandNet proporcionará el paquete de portabilidad definido contractualmente, respetando licencias y derechos aplicables.
“Todo desarrollo es PI de HumandNet”
La afirmación no es jurídicamente segura. La titularidad depende de autoría, relaciones laborales o contractuales, cesiones escritas, componentes reutilizados, código de terceros, licencias LGPL/AGPL/OEEL o propietarias y condiciones de la obra encargada.
HumandNet conserva la titularidad de sus desarrollos originales y componentes preexistentes, sin afectar derechos de Odoo, OCA, vendors, el cliente u otros terceros. Los derechos sobre desarrollos específicos se definirán en cada Orden de Servicio.
“Nunca licenciamiento”
La suscripción por accesos no elimina las licencias subyacentes: Odoo Community 18 usa LGPLv3; Odoo Enterprise aplica OEEL v1.0 y suscripción; las Odoo Apps de Odoo SA son propietarias salvo indicación distinta; OCA y terceros requieren revisión individual. Las fuentes auditadas no prueban que los módulos de HolosERP sean AGPL ni permiten atribuirles una obligación genérica.
El servicio se comercializa mediante suscripción de acceso. Los componentes de software subyacentes permanecen sujetos a sus respectivas licencias y condiciones de uso.
Módulos de terceros
P3 y P4 deben unificarse: “No se incorporan componentes externos salvo aquellos aprobados conforme al procedimiento P4”. El expediente mínimo debe incluir fuente y autor; licencia y compatibilidad; compra o autorización; versión de Odoo y localización mexicana; dependencias; revisión de código, seguridad, secretos y calidad; SBOM; pruebas funcionales, fiscales, contables y de rendimiento; mantenimiento, actualización y abandono; reversión y desinstalación; responsable, costos y tratamiento de datos.
La aprobación no implica garantizar todo el producto del vendor. HumandNet sí responde por errores propios de selección, configuración o integración.
Garantía
Los 30 días requieren inicio definido, aceptación expresa o tácita, tratamiento de entregas parciales, regresiones, requisitos no funcionales, defectos de integración, extensión limitada tras corrección y relación entre FLR, Orden de Servicio y aceptación. La prioridad debe depender del impacto real: una regresión crítica puede ser S1.
Estimaciones y plazo de cotización
Los porcentajes suman 70%–110%; con contingencia fija de 15%, el total alcanza 85%–125%. La fórmula debe normalizarse sobre el esfuerzo base y mostrar la contingencia por separado.
Objetivo de cotización: 10 días hábiles desde la recepción del FLR validado, excluyendo esperas del cliente y casos de complejidad excepcional documentada.
Para incertidumbre alta debe permitirse discovery o contratación por tiempo y materiales.
SLA y capacidad de soporte
Contradicción: el documento propone para S1 primera respuesta en 1 hora hábil y resolución objetivo en 8 horas hábiles, mientras la política operativa vigente usa otra matriz. Helpdesk ya fue definido internamente como fuente oficial desde helpdesk.ticket.create_date. No deben coexistir taxonomías ni relojes distintos.
Separación obligatoria de métricas
Métrica
Definición
Primera respuesta
Comunicación humana con clasificación inicial.
Diagnóstico
Origen probable identificado y documentado.
Workaround
Alternativa temporal que reduce materialmente el impacto.
Restauración
Recuperación de la operación crítica.
Resolución definitiva
Corrección permanente o cierre de causa raíz.
Para S1 es más sostenible comprometer restauración o workaround que corrección definitiva en ocho horas.
Elementos contractuales faltantes
Calendario, zona horaria, festivos y hora de corte.
Inicio y final de cada métrica y fuente oficial.
Estados que suspenden el reloj, notificación y reanudación.
Mantenimiento programado y dependencias externas.
Disputa de severidad.
Créditos o remedios por incumplimiento.
Tratamiento del incumplimiento crónico.
Cobertura fuera de horario y guardias.
Recomendación: no trasladar 1 hora/8 horas al contrato hasta medir 60–90 días y validar roster N1/N2/N3, guardias y sustituciones, alertamiento, escalamiento, capacidad por severidad y cumplimiento histórico.
Disponibilidad, respaldos y recuperación
“Plataforma disponible, respaldada y actualizada” debe sustituirse por compromisos medibles.
Controles que deben definirse y probarse
Control
Definición necesaria
Disponibilidad
Porcentaje mensual, fuente, exclusiones y mantenimiento.
Backups
Frecuencia, alcance, cifrado, ubicación y retención.
RPO
Pérdida máxima aceptable de datos.
RTO
Tiempo objetivo de restauración.
Restauración
Frecuencia de pruebas y evidencia de éxito.
PITR
Disponibilidad por plan, retención WAL y límites.
Actualizaciones
Parches, módulos y migraciones mayores.
Ciclo de vida
Versiones soportadas, mantenimiento limitado y fin de soporte.
La restauración aislada construida para PasteleriaOK demuestra conocimiento técnico, no una política global para todos los clientes. No debe ofrecerse PITR hasta implementar y probar archivado continuo de WAL o tecnología equivalente.
Portabilidad, privacidad y offboarding
Salida mínima
Exportación utilizable
Datos maestros y transacciones, relaciones e IDs, documentos y adjuntos, XML CFDI, UUID, cancelaciones y relaciones fiscales, catálogos, pólizas, auxiliares, balanzas, configuración, fecha de corte, diccionario y conciliación.
Fecha, transición, solo lectura, revocación, retención fiscal/legal, eliminación productiva, expiración de backups, certificado, litigios y responsables.
La transformación, depuración o migración asistida puede cobrarse. La devolución básica de datos no debería depender de una negociación iniciada al finalizar el contrato. Las solicitudes ARCO tampoco pueden condicionarse al pago de consultoría o exportación.
Suspensión por adeudos
Adeudo líquido, vencido y no controvertido.
Aviso previo, periodo de cura y suspensión gradual.
Excepciones para ARCO, CFDI y exportación de salida.
No eliminar datos únicamente por adeudo.
Diferenciar claramente reactivación y terminación.
Contraste con referentes de mercado
La referencia “Netflix de Oracle” se interpretó como Oracle NetSuite.
Comparación de prácticas relevantes para HolosERP
Tema
Odoo
SAP Private/Tailored
Oracle NetSuite
Implicación
Administración
Odoo.sh prueba gestión de proyecto, ramas, backups e importación; no se traslada a Online.
Cliente configura procesos y seguridad aplicativa/datos; no se concede SO o base.
Cliente gestiona roles, usuarios y credenciales; no infraestructura Oracle.
RACI aplicativa/infraestructura, no “nunca administra”.
Desarrollo
Odoo.sh admite addons, submódulos y XML-RPC con límites; Online no admite apps no estándar. Studio no quedó probado.
Admite modifications, Customer ABAP Add-ons e interfaces bajo gobierno.
SuiteCloud/SuiteScript/SuiteApps provienen de los SSA, no de HSDP sola.
Extensibilidad gobernada; no inferir clasificación SaaS/PaaS de estas fuentes.
Backups y DR
Cloud publica objetivos; Odoo.sh concreta producción y excluye recovery de staging/dev.
El suplemento no publica RPO/RTO general; requiere SLA/SDG/Order.
RPO 1 h/RTO 12 h sólo tras desastre declarado y DR activado, sujeto a Exceptions Policy.
Probar y pactar métricas propias.
Disponibilidad
99.9% target mensual; la página declara que no es garantía vinculante.
Sin porcentaje ni créditos en el suplemento analizado.
99.7% y créditos 10/15/25% condicionados; logs Oracle, solicitud y remedio exclusivo.
Separar target, obligación, SLI, exclusiones y remedio.
Soporte
No acredita una matriz completa para HolosERP.
Límites sí; tiempos requieren Cloud Support Schedule.
Response Time Goals según Basic/Premium; no tiempos de resolución.
Separar respuesta, diagnóstico, workaround, restore y resolución.
Salida
Backup Online y dump de producción Odoo.sh por procedimientos distintos.
Export final solicitado antes de terminar; dos semanas para verificar; sin catálogo integral.
Retrieval a solicitud dentro de 60 días; asistencia facturable; sin promesa de dump/formato.
Catálogo, ventana, verificación, costos y borrado contractuales.
Upgrades
Ciclo Odoo.sh no se atribuye a Online/on-premise.
Cliente instala upgrades salvo inicial y mantiene versión soportada.
No reducción material está en SSA; HSDP sola no prueba el régimen de upgrades.
Política propia de versiones, custom code y EOL.
Responsabilidad
Customizaciones matizan uptime, no trasladan toda responsabilidad.
El cap general requiere GTC/Agreement separado.
Cap general está en SSA; HSDP sólo hace exclusivos créditos específicos.
Definir responsabilidad compartida y límites en contrato.
Límites: los dos enlaces SAP suministrados resuelven al mismo suplemento de seis páginas para Private/Tailored Option; no prueba Public Edition y SLA, DPA, GTC, Order Form y soporte siguen separados. HSDP NetSuite no prueba por sí sola SuiteCloud, exportación autoservicio, upgrades o límites generales. Odoo 18 licencias, Odoo 19 hosting, Online, Odoo.sh y on-premise son alcances distintos; la FAQ prueba una shell, no una promesa expresa de SSH.
Trazabilidad de fuentes
Cada claim de mercado queda anclado al documento exacto, versión, sección y condición. Los hashes corresponden a la captura del 16 de julio de 2026 y deben recalcularse si el proveedor sustituye el activo.
Targets 99.9%, backups, RPO/RTO y seguridad en odoo.com.
La página dice que no son garantías vinculantes.
Afirmación → evidencia → condición → aplicación
Afirmación
Evidencia y página/sección
Condición
Aplicación HolosERP
NetSuite 99.7% y créditos
HSDP III.A, pp. 14-15
Incorporación, EP, impacto, solicitud, cuenta al corriente; 10/15/25% como remedio exclusivo.
Definir SLI, elegibilidad y créditos propios.
NetSuite soporte
HSDP Definitions pp. 5-6; II.D pp. 12-14
Basic/Premium y obligaciones cliente; Response Time Goals, no resolución.
Separar cinco relojes de soporte.
NetSuite RPO/RTO
HSDP I.O, pp. 9-10
Desastre declarado, plan activado, EP; RPO excluye cargas en curso.
No prometer sin escenario y prueba.
NetSuite retrieval
HSDP I.T, pp. 10-11
Solicitud dentro de 60 días; asistencia facturable; sin dump/formato.
Catálogo y test propios.
NetSuite export, SuiteCloud, upgrades y cap
SSA Definitions/§§6.8, 10 y 13.2
SSA/Order aplicables; no provienen de HSDP sola.
Citar instrumento correcto y no decir “autoservicio” sin prueba.
SAP administración/custom code/upgrades
Suplemento §§2.1-2.6 y 3, pp. 1-5
Sólo Private/Tailored; Order/SDG completan alcance.
RACI y extensibilidad gobernada.
SAP export final
Suplemento §2.4, p. 3
Solicitud pre-terminación y dos semanas de verificación.
Definir formato, adjuntos y aceptación.
Odoo licencias
L18, Community/Enterprise/Odoo Apps
Versión 18 y licencia concreta de cada módulo.
SBOM/NOTICE y revisión componente a componente.
Odoo administración/export/upgrades
H19 + FAQ Odoo.sh
Por modalidad; producción distinta de staging/dev.
No trasladar shell/builds/dumps/upgrade policy a Online.
Responsabilidad compartida
SAP §§2.6/3; HSDP I.I/K; Odoo por modalidad
Cada fuente distribuye ámbitos distintos.
Accountability único no significa responsabilidad absoluta.
Compliance SaaS
El baseline legal mexicano no es coleccionar certificaciones. Es privacidad lícita, seguridad proporcional, confidencialidad, incidentes, encargados/subencargados, transferencias, conservación, evidencia, PI/licencias y obligaciones fiscales/mercantiles propias.
A · Legal general
Piso mexicano
Privacidad, avisos, consentimiento, ARCO, seguridad, incidentes, contratos de encargo, transferencias, evidencia electrónica, conservación, fiscal, PI, OSS, secretos y personal propio.
MSA, DPA, SLA, seguridad, DR, logs, offboarding, residencia, auditoría y responsabilidad son C al pactarse. Marcos voluntarios son D hasta que regulación o contrato los active.
No son obligaciones legales universales: ISO 27001/27017/27018, SOC 2, CSA STAR, NIST, CIS, OWASP, SLSA/SBOM e ISO 22301. Se vuelven contractuales si se prometen, regulatorias si una norma sectorial aplicable las incorpora o comercialmente necesarias si un comprador condiciona la venta. SOC 2 es una atestación, no una certificación.
Logs íntegros, export/checksum, borrado, evidence pack, regiones, VPAT y pólizas.
D1-D6
ISO 27001/27017/27018, SOC 2, CSA STAR y NIST CSF.
Alcance, SoA/mapeos, evidencia de periodo, CAIQ y perfiles actual/objetivo.
D7-D12
CIS, ASVS, SAMM, SLSA/SBOM, ISO 22301 y WCAG.
Assessment, pruebas, provenance/SBOM, BIA/ejercicios y auditoría accesible.
Minimum viable compliance
Entidad, producto, nube, países, roles y puertas G1-G10 definidos.
Inventario/mapa de datos, avisos, consentimiento y retención versionados.
ARCO probado con plazos 20/15; incidentes sin inventar “72 horas” como regla mexicana universal.
Riesgo aprobado; mínimo privilegio, MFA admin, cifrado en tránsito, secretos, parcheo, backup y monitoreo con evidencia.
MSA, DPA, SLA, seguridad, subencargados y residencia sin claims no demostrados.
Restore, incidente y offboarding probados con adjuntos, diccionario, checksum, revocación y borrado residual.
Evidencia electrónica, CFDI propio y módulo/PAC cliente validados según alcance.
SBOM, NOTICE, licencias Odoo/terceros y cadena de titularidad completos.
Tarjetas excluidas o PCI evaluado; sectores/jurisdicciones B cerrados o fuera de alcance.
Evidence pack con dueño, periodo, excepción y próxima revisión.
Memo de aplicabilidad firmado por abogado mexicano y especialistas sectoriales.
Documentos y anexos contractuales necesarios
Arquitectura documental mínima
Documento
Contenido mínimo
Contrato maestro
Objeto, vigencia, jerarquía, responsabilidad y terminación.
Orden de Servicio
Alcance, precio, entregables, criterios y supuestos.
Anexo de SLA
Disponibilidad, soporte, métricas, exclusiones y remedios.
Anexo de seguridad
Controles, vulnerabilidades, accesos e incidentes.
Tratamiento de datos
Roles, instrucciones, ARCO, subencargados y eliminación.
Matriz de PI y licencias
Odoo, OCA, vendors, código propio y desarrollos específicos.
Política de versiones
Soporte, parches, mantenimiento, migraciones y EOL.
Backup y DR
Retención, RPO, RTO, PITR y simulacros.
Portabilidad
Datos, formatos, relaciones, plazos y costos.
Offboarding
Exportación, revocación, conservación, eliminación y evidencia.
Política de terceros
Evaluación, aprobación, mantenimiento y retiro.
Evidencia electrónica
Firmas, versiones, trazabilidad, conservación y NOM-151 cuando proceda.
Plan de acción 30/60/90 días
Días 0–30 · Definir y medir
Resolver prelación entre ley, licencias, contrato, DPA/SLA, Orden de Servicio, rector, lineamientos y procesos.
Aprobar, versionar y publicar el documento rector y dependencias.
Definir RACI, gobierno y SLA de excepciones.
Verificar infraestructura, tenancy, aislamiento, respaldos y confidencialidad.
Congelar SLA 1 h/8 h, PITR y RPO/RTO contractuales.
Crear CMDB y unificar SLA en Helpdesk.
Completar G1-G10, inventario/mapa de datos y roles responsable/encargado.
Versionar avisos, retención y MSA/DPA/SLA/seguridad.
Inventariar subencargados, regiones y accesos.
Crear matriz PI/licencias y SBOM inicial.
Revisar HUM-OFB y definir portabilidad.
Días 31–60 · Implementar controles
Automatizar backups de base y filestore; cifrado, copia externa y alertas.
Estandarizar pruebas, anonimización y CI/CD con rollback.
Implementar garantía V4, expediente P4 y exportación conciliada.
Implantar IAM, MFA admin, recertificación, vulnerabilidades y logs críticos.
Pilotar PITR sin prometerlo.
Implementar ARCO, consentimiento y evidencia electrónica.
Implantar incident response con criterio mexicano de notificación.
Validar CFDI propio y módulo/PAC si aplica.
Excluir tarjetas o evaluar PCI; bloquear mercados B no aprobados.
Días 61–90 · Demostrar capacidad
Ejecutar restauraciones y medir RPO/RTO.
Simular S1 y vulneración de datos.
Medir respuesta, workaround, restauración y resolución.
Ejecutar offboarding con exportación, checksum, revocación y borrado residual.
Medir SLA real al menos 60 días cuando sea posible.
Auditar backups, monitoreo, CI/CD, accesos y evidence pack.
Completar el minimum viable compliance y cerrar críticos.
Ajustar compromisos a resultados medidos.
Obtener revisión jurídica mexicana y especialistas sectoriales.
Criterios para aprobar la siguiente versión
Documento rector aprobado, firmado, versionado, publicado y con vigencia.
Prelación que protege ley, licencias e instrumentos firmados.
HUM-LIN-HOL y anexos SLA/DPA aprobados y publicados, sin respuestas institucionales contradictorias.
RACI de gobierno con quorum, mayorías, desempate, delegación, conflictos, registro y SLA de excepciones.
Claims de infraestructura y aislamiento verificados contra la arquitectura real.
Adopción con criterios de salida objetivos, medibles y aceptados.
Afirmaciones absolutas eliminadas o condicionadas.
P3 y P4 integradas en una política coherente.
Matriz de PI y licencias por tipo de componente.
Catálogo de datos y paquete de portabilidad definidos.
Disponibilidad, RPO, RTO y retención definidos.
Restauraciones probadas y documentadas.
Odoo Helpdesk como única fuente oficial del SLA.
Capacidad N1/N2/N3 medida.
Fórmula de estimación corregida.
Plazo de cotización iniciado desde un evento controlable.
HUM-OFB revisado mediante simulacro.
Anexos de privacidad, seguridad e incidentes creados.
G1-G10, inventario de datos y roles responsable/encargado aprobados.
Avisos, consentimiento, ARCO 20/15 y retención probados.
Subencargados, incidentes, offboarding y residencia contractualmente auditables.
MFA admin, vulnerabilidades, logs, restore y simulacro con evidencia vigente.
SBOM, NOTICE, licencias Odoo/terceros y cadena de titularidad revisados.
CFDI/PAC, PCI, salud, finanzas, gobierno, consumo y países cerrados o fuera de alcance.
Sin claims de estándares, certificaciones o métricas no demostrados.
Minimum viable compliance completo o N/A fundamentados.
Redacción y aplicabilidad validadas por abogado mexicano y especialistas sectoriales.
Auditoría complementaria del PDF HUM-MOD-HOL-v1.0
Limitación de alcance: se auditó el texto parseado y las imágenes o referencias visuales suministradas del PDF de 10 páginas. No se inspeccionó el archivo binario PDF, sus metadatos, firmas digitales ni propiedades técnicas.
El PDF no reduce los riesgos: los agrava al presentar políticas no aprobadas como reglas uniformes y declararse en la página 1 “Documento rector — gobierna a todos los lineamientos, procesos y contratos”, aun siendo “Borrador v1.0” sin firmas visibles.
Clasificación de hallazgos diferenciales
Hallazgos nuevos, agravados y ya cubiertos
Clasificación
Hallazgo diferencial
Referencia
Nivel
Agravado
Pretende gobernar lineamientos, procesos y contratos siendo borrador sin firmas.
pp. 1, 8, 10
Crítico
Nuevo
P7 afirma SLA “publicados”, pero HUM-LIN-HOL figura “Por elaborar”.
pp. 6, 8
Crítico
Nuevo
Jerarquía absoluta invertida: un documento interno no prevalece sobre ley, licencias ni contratos firmados.
p. 8
Crítico
Cubierto y agravado
“Operando, disponible, respaldada, actualizada y evolucionando”, “garantiza” y “un solo responsable” carecen de métricas, exclusiones y responsabilidad compartida.
pp. 2, 4
Crítico
Cubierto y agravado
“Propiedad plena” y “cien por ciento del valor” no distinguen titularidad, datos personales, conservación fiscal ni completitud.
pp. 2, 4
Crítico
Nuevo
“Infraestructura propia” requiere verificación; recursos de terceros deben describirse como contratados o administrados.
p. 2
Alto
Nuevo
“Todos los clientes hospedados” sugiere recursos compartidos: deben aclararse aislamiento, blast radius, backups, accesos y confidencialidad.
p. 4
Crítico
Cubierto y agravado
Solicitar BD, módulo o acceso no convierte por sí solo SaaS en PaaS/IaaS; un dump no sirve únicamente para replicar.
pp. 3, 4, 9
Alto
Ya cubierto
Negación de código, dumps, credenciales y licencias, y atribución total de PI, exige distinguir activos, licencias, datos y portabilidad.
pp. 2, 4
Crítico
Cubierto y agravado
P4 exige controles válidos, pero el rechazo “sin excepción” puede impedir mitigaciones y no reemplaza el análisis integral.
p. 5
Alto
Nuevo
Cinco pilares “en un solo servicio” frente a tres componentes “siempre cobrados” por separado.
pp. 5, 7
Alto
Nuevo
Exploración pagada obligatoria y cierre de Adopción “con confianza”; este último no es auditable.
p. 7
Alto
Nuevo
N1/N2/N3 se declara sin evidencia de dotación, cobertura, guardias, escalamiento o desempeño.
p. 7
Alto
Nuevo
Decisión de “tres direcciones” con cuatro funciones, sin quorum, mayoría, desempate, delegación, conflictos, registro ni SLA.
p. 10
Alto
Agravado
Agromol justifica controles del caso, no una conclusión universal sobre solicitudes de base de datos.
p. 9
Alto
Agravado
El guion dice que las reglas aplican a todos, pero reconoce legacy, regularización y excepciones.
La pretensión normativa excede su estado. Debe marcarse “no vigente” hasta aprobación, firma, publicación y vigencia.
2
Operando, disponible, respaldada, actualizada y evolucionando; nunca licenciamiento; infraestructura propia; cliente nunca administra; propiedad plena; responsable único; no entrega de código, dump, credenciales ni licencias.
Sustituir absolutos por alcance, métricas, exclusiones, licencias y responsabilidad compartida. Verificar infraestructura.
3
Solicitar BD, módulo o acceso cambia SaaS a PaaS/IaaS; SaaS idéntico, autoservicio y sin personalización; un “sí” detiene la solicitud.
Confunde modalidad con acceso/extensibilidad. Evaluar riesgo, necesidad y salvaguardas, no etiquetas.
4
P1 protege a todos los hospedados; P2 garantiza históricos; dump transfiere plataforma; exportación entrega cien por ciento del valor; toda PI es de HumandNet.
Definir tenancy, aislamiento, catálogo de exportación, integridad y separación de datos, esquema, código y licencias.
5
P4 restringe fuente, exige licencia, mantenimiento, pruebas y tres aprobaciones; rechazo sin excepción; P5; tres componentes cobrados; infraestructura trasladada; desarrollo menor sin cuantificar.
Formalizar expediente, autoridad y excepciones. Conciliar precios, incluidos, adicionales y límites.
6
P7 declara SLA publicados; P8 ofrece exportación como servicio, gracia y paquetes post-cierre.
No declarar publicado lo que p. 8 marca por elaborar. Definir salida básica antes del cierre.
7
Cinco pilares sin cambios y en un solo servicio; Exploración pagada; Adopción hasta operar con confianza; N1/N2/N3.
Alinear empaquetado y P6; transparentar Exploración; reemplazar confianza por competencia y aceptación verificables.
8
Jerarquía absoluta; HUM-LIN-HOL y contrato por elaborar; HUM-REQ pendiente; HUM-OFB emitidos; referencia obligatoria; regularización.
La jerarquía no aplica con instrumentos incompletos. Renovaciones requieren incorporación expresa; contratos vigentes no cambian unilateralmente.
9
Agromol busca replicar Odoo; una BD no resuelve necesidad legítima; reglas para todos.
La intención concreta sustenta el caso, no una negación universal. Legacy y excepciones impiden uniformidad actual.
10
Dirección General propietaria; Comercial/Técnico Operativa interpretan; Desarrollo dictamina; cambios por tres direcciones; excepciones; revisión anual; firmas vacías.
Definir órgano y reglas. Revisión anual no sustituye versiones, vigencia, trazabilidad ni gestión de excepciones.
Correcciones normativas recomendadas
Orden de prelación
Leyes, reglamentos y resoluciones obligatorias.
Licencias de software y derechos de terceros en su ámbito.
Contrato maestro y convenios firmados.
Anexos firmados de datos, seguridad y SLA; el especializado prevalece en su materia.
Orden de Servicio para alcance, entregables, precio y criterios, sin reducir obligaciones superiores.
Políticas incorporadas expresamente, con código, versión y fecha.
Lineamientos internos, sin capacidad de modificar unilateralmente lo anterior.
La prelación definitiva requiere validación jurídica mexicana y armonización contractual. Publicar una política interna no equivale a aceptación contractual.
Gobierno y excepciones
Definir órgano inequívoco, RACI, integrantes con voto y consultivos, quorum, mayorías y unanimidad, desempate, delegaciones y suplencias, conflictos de interés, expediente y vigencia de excepciones, SLA y reconsideración, y registro de versiones, decisiones y comunicaciones.
Responsabilidad y arquitectura
“Un solo responsable de que todo funcione” debe ser un solo punto de accountability frente al cliente, respaldado por una matriz compartida. HumandNet responde por coordinación y componentes bajo su control; PAC, SAT, telecomunicaciones, nube, vendors y uso del cliente requieren obligaciones, dependencias, escalamiento y exclusiones, sin excluir responsabilidades irrenunciables.
“Infraestructura propia” debe reemplazarse por la descripción comprobada: propiedad de, contratada por o administrada por HumandNet. Si hay recursos compartidos, documentar tenancy, aislamiento, credenciales, backups, blast radius y confidencialidad.
Datos, exportación y Adopción
Separar derechos contractuales del cliente; derechos de titulares y roles de privacidad; obligaciones fiscales, contables, laborales y de conservación; y derechos sobre software, esquema, configuración, metadatos y terceros. Sustituir “históricos” y “cien por ciento del valor” por catálogo con alcance, periodos, formatos, relaciones, adjuntos, metadatos, conciliación, exclusiones, plazo y costo.
Adopción debe cerrar con usuarios clave capacitados, evaluación mínima, procesos críticos sin asistencia, incidencias bloqueantes cerradas, documentación entregada y aceptación formal.
Conclusión diferencial
El PDF eleva el riesgo al convertir definiciones no aprobadas en aparentes respuestas institucionales. La contradicción inmediata es afirmar que los SLA están publicados mientras HUM-LIN-HOL figura por elaborar. La estructural es pretender que un borrador sin firmas gobierne contratos y documentos inexistentes o no validados.
Debe marcarse HUM-MOD-HOL-v1.0 como borrador no vigente y no utilizable como respuesta contractual o institucional. Hasta resolver prelación, documentos dependientes, gobierno, arquitectura, capacidad y empaquetado, no debe presentarse como política vigente, regla uniforme ni documento con prevalencia contractual.
HumandNet no entrega únicamente acceso a un ERP; entrega una plataforma operada, acompañada y evolucionada bajo gobierno técnico.
La propuesta puede ser diferenciada, pero debe expresarse como resultados medibles: servicio conforme a niveles definidos, no “siempre disponible”; mantenimiento según versiones, no “siempre actualizado”; exportación según catálogo; recuperación según RPO/RTO probado; evolución cotizada y gobernada; y derechos definidos por activo, no propiedad absoluta de todo el software.
Conclusión: hasta completar estos controles, el documento debe mantenerse como borrador conceptual interno, no como promesa comercial o contractual vigente.
Nota legal
Este dictamen es una evaluación técnica, operativa y documental. No constituye opinión legal ni sustituye la revisión de un abogado mexicano especializado en servicios tecnológicos, privacidad, propiedad intelectual, contratación electrónica, fiscal y competencia, ni la de especialistas sectoriales o de cada jurisdicción aplicable. La aplicabilidad debe revalidarse por entidad, producto, flujo de datos, cliente, país, industria, contrato y fecha antes de comercializar o asumir compromisos.
Evaluación de viabilidad comercial, técnica, operativa, legal y tecnológica, integrada con evidencia primaria trazable de Oracle NetSuite, SAP, Odoo y compliance SaaS.
Estado: borrador conceptual interno
Riesgo contractual: crítico
PDF contrastado: 10 páginas
Uso: toma de decisión ejecutiva
Integración de evidencia: 16 julio 2026
Decisión recomendada
Dictamen ejecutivo
El modelo de negocio propuesto es viable, pero el documento no está listo para aprobarse, ofrecerse comercialmente ni trasladarse al contrato maestro en su redacción actual.
El problema no es el modelo SaaS. El borrador convierte decisiones comerciales en garantías técnicas, operativas y jurídicas que todavía no están suficientemente definidas, medidas o demostradas.
Definición recomendada: HolosERP es un ERP SaaS totalmente gestionado, con evolución a la medida y extensibilidad controlada. HumandNet administra la infraestructura y la plataforma base. El cliente administra su operación, usuarios, permisos, configuración y datos dentro de las capacidades habilitadas. Los desarrollos, integraciones y componentes externos se incorporan mediante un proceso gobernado de evaluación, construcción, prueba, despliegue y soporte.
No aprobar todavía como instrumento contractual o promesa comercial externa. Antes deben corregirse las contradicciones y afirmaciones absolutas; definirse métricas y anexos operativos; validarse la capacidad durante 60–90 días; realizarse simulacros de restauración, incidente crítico y offboarding; y obtenerse revisión de un abogado mexicano especializado en tecnología, privacidad y propiedad intelectual.
Resultado general de la auditoría
Dictamen y riesgo por dimensión
Dimensión
Dictamen
Nivel de riesgo
Viabilidad comercial
Viable con correcciones de posicionamiento, alcance y promesas
Alto
Viabilidad técnica
Viable, pero no demostrada de forma homogénea para toda la cartera
Alto
Viabilidad operativa
Parcial; faltan métricas, capacidad y procedimientos globales
Crítico
Viabilidad legal
Requiere correcciones sustanciales en PI, datos, privacidad y salida
Crítico
Competitividad
Diferenciación válida, pero más restrictiva que los referentes
Medio-alto
Preparación contractual
No lista
Crítico
Capacidad operativa observada
17 capacidades evaluadas
0 demostradas globalmente
No existe aún evidencia reproducible para toda la cartera.
Evidencia parcial
11 parcialmente demostradas
Hay prácticas o casos puntuales, pero no controles globales acreditados.
Brecha material
5 no demostradas · 1 contradicha
Una capacidad contradice otra política vigente.
La ausencia de evidencia global no prueba que la capacidad no exista. Sí significa que todavía no puede ofrecerse como compromiso contractual reproducible para toda la cartera.
Bloqueadores críticos
Hallazgos que bloquean aprobación o comercialización
Prioridad
Hallazgo
Impacto
P0
“Todo desarrollo es PI de HumandNet” no distingue Odoo, OCA, vendors, copyleft, PI previa ni obra encargada.
Disputas de titularidad e incumplimiento de licencias.
P0
Se reconoce la titularidad de datos del cliente, pero no se garantiza una salida completa y utilizable.
Lock-in, controversias comerciales y riesgo regulatorio.
P0
“Disponible, respaldada y actualizada” carece de disponibilidad, RPO, RTO, retención y política de versiones.
Promesas imposibles de medir o defender.
P0
El SLA S1 de 1 hora/8 horas no está respaldado por guardias, monitoreo, capacidad histórica ni una política unificada.
Incumplimiento contractual recurrente.
P0
El máximo de 10 días para cotizar contradice la duración acumulada de E1–E5.
Promesa estructuralmente incumplible.
P1
P3 prohíbe componentes externos mientras P4 admite excepciones.
Política contradictoria e inaplicable al ecosistema real.
P1
El offboarding se declara emitido, pero no se acreditó un procedimiento integral ensayado.
Salida no ejecutable ni cotizable.
P1
La fórmula de estimación puede sumar entre 85% y 125% con contingencia.
Cotizaciones inconsistentes y riesgo de margen.
Contradicciones y afirmaciones por corregir
SaaS, PaaS y administración del cliente
“El cliente usa la plataforma, nunca la administra” es excesivo. Un servicio sigue siendo SaaS aunque el cliente administre usuarios, roles, configuraciones y datos dentro de la aplicación. Una API, SDK o extensión controlada tampoco lo convierte automáticamente en PaaS.
El cliente no recibe administración sobre infraestructura, sistema operativo o motor de base de datos. Podrá administrar usuarios, permisos, configuración funcional, integraciones y datos dentro de las capacidades expresamente habilitadas.
Datos, base de datos y propiedad intelectual
La separación entre “datos del cliente” y “contenedor de HumandNet” es insuficiente. Debe existir una matriz para datos operativos y personales; configuración funcional; esquema estándar Odoo/PostgreSQL; código propio; código Odoo, OCA y vendors; desarrollos financiados por el cliente; documentación, secretos e infraestructura.
Un dump puede incluir información, relaciones, configuración y metadatos, pero no necesariamente todo el código fuente de HumandNet. Gran parte del esquema puede derivar de Odoo y sus módulos.
No se entrega acceso directo ni copia nativa de la base de datos como parte del servicio estándar, salvo obligación legal o acuerdo expreso. HumandNet proporcionará el paquete de portabilidad definido contractualmente, respetando licencias y derechos aplicables.
“Todo desarrollo es PI de HumandNet”
La afirmación no es jurídicamente segura. La titularidad depende de autoría, relaciones laborales o contractuales, cesiones escritas, componentes reutilizados, código de terceros, licencias LGPL/AGPL/OEEL o propietarias y condiciones de la obra encargada.
HumandNet conserva la titularidad de sus desarrollos originales y componentes preexistentes, sin afectar derechos de Odoo, OCA, vendors, el cliente u otros terceros. Los derechos sobre desarrollos específicos se definirán en cada Orden de Servicio.
“Nunca licenciamiento”
La suscripción por accesos no elimina las licencias subyacentes: Odoo Community 18 usa LGPLv3; Odoo Enterprise aplica OEEL v1.0 y suscripción; las Odoo Apps de Odoo SA son propietarias salvo indicación distinta; OCA y terceros requieren revisión individual. Las fuentes auditadas no prueban que los módulos de HolosERP sean AGPL ni permiten atribuirles una obligación genérica.
El servicio se comercializa mediante suscripción de acceso. Los componentes de software subyacentes permanecen sujetos a sus respectivas licencias y condiciones de uso.
Módulos de terceros
P3 y P4 deben unificarse: “No se incorporan componentes externos salvo aquellos aprobados conforme al procedimiento P4”. El expediente mínimo debe incluir fuente y autor; licencia y compatibilidad; compra o autorización; versión de Odoo y localización mexicana; dependencias; revisión de código, seguridad, secretos y calidad; SBOM; pruebas funcionales, fiscales, contables y de rendimiento; mantenimiento, actualización y abandono; reversión y desinstalación; responsable, costos y tratamiento de datos.
La aprobación no implica garantizar todo el producto del vendor. HumandNet sí responde por errores propios de selección, configuración o integración.
Garantía
Los 30 días requieren inicio definido, aceptación expresa o tácita, tratamiento de entregas parciales, regresiones, requisitos no funcionales, defectos de integración, extensión limitada tras corrección y relación entre FLR, Orden de Servicio y aceptación. La prioridad debe depender del impacto real: una regresión crítica puede ser S1.
Estimaciones y plazo de cotización
Los porcentajes suman 70%–110%; con contingencia fija de 15%, el total alcanza 85%–125%. La fórmula debe normalizarse sobre el esfuerzo base y mostrar la contingencia por separado.
Objetivo de cotización: 10 días hábiles desde la recepción del FLR validado, excluyendo esperas del cliente y casos de complejidad excepcional documentada.
Para incertidumbre alta debe permitirse discovery o contratación por tiempo y materiales.
SLA y capacidad de soporte
Contradicción: el documento propone para S1 primera respuesta en 1 hora hábil y resolución objetivo en 8 horas hábiles, mientras la política operativa vigente usa otra matriz. Helpdesk ya fue definido internamente como fuente oficial desde helpdesk.ticket.create_date. No deben coexistir taxonomías ni relojes distintos.
Separación obligatoria de métricas
Métrica
Definición
Primera respuesta
Comunicación humana con clasificación inicial.
Diagnóstico
Origen probable identificado y documentado.
Workaround
Alternativa temporal que reduce materialmente el impacto.
Restauración
Recuperación de la operación crítica.
Resolución definitiva
Corrección permanente o cierre de causa raíz.
Para S1 es más sostenible comprometer restauración o workaround que corrección definitiva en ocho horas.
Elementos contractuales faltantes
Calendario, zona horaria, festivos y hora de corte.
Inicio y final de cada métrica y fuente oficial.
Estados que suspenden el reloj, notificación y reanudación.
Mantenimiento programado y dependencias externas.
Disputa de severidad.
Créditos o remedios por incumplimiento.
Tratamiento del incumplimiento crónico.
Cobertura fuera de horario y guardias.
Recomendación: no trasladar 1 hora/8 horas al contrato hasta medir 60–90 días y validar roster N1/N2/N3, guardias y sustituciones, alertamiento, escalamiento, capacidad por severidad y cumplimiento histórico.
Disponibilidad, respaldos y recuperación
“Plataforma disponible, respaldada y actualizada” debe sustituirse por compromisos medibles.
Controles que deben definirse y probarse
Control
Definición necesaria
Disponibilidad
Porcentaje mensual, fuente, exclusiones y mantenimiento.
Backups
Frecuencia, alcance, cifrado, ubicación y retención.
RPO
Pérdida máxima aceptable de datos.
RTO
Tiempo objetivo de restauración.
Restauración
Frecuencia de pruebas y evidencia de éxito.
PITR
Disponibilidad por plan, retención WAL y límites.
Actualizaciones
Parches, módulos y migraciones mayores.
Ciclo de vida
Versiones soportadas, mantenimiento limitado y fin de soporte.
La restauración aislada construida para PasteleriaOK demuestra conocimiento técnico, no una política global para todos los clientes. No debe ofrecerse PITR hasta implementar y probar archivado continuo de WAL o tecnología equivalente.
Portabilidad, privacidad y offboarding
Salida mínima
Exportación utilizable
Datos maestros y transacciones, relaciones e IDs, documentos y adjuntos, XML CFDI, UUID, cancelaciones y relaciones fiscales, catálogos, pólizas, auxiliares, balanzas, configuración, fecha de corte, diccionario y conciliación.
Fecha, transición, solo lectura, revocación, retención fiscal/legal, eliminación productiva, expiración de backups, certificado, litigios y responsables.
La transformación, depuración o migración asistida puede cobrarse. La devolución básica de datos no debería depender de una negociación iniciada al finalizar el contrato. Las solicitudes ARCO tampoco pueden condicionarse al pago de consultoría o exportación.
Suspensión por adeudos
Adeudo líquido, vencido y no controvertido.
Aviso previo, periodo de cura y suspensión gradual.
Excepciones para ARCO, CFDI y exportación de salida.
No eliminar datos únicamente por adeudo.
Diferenciar claramente reactivación y terminación.
Contraste con referentes de mercado
La referencia “Netflix de Oracle” se interpretó como Oracle NetSuite.
Comparación de prácticas relevantes para HolosERP
Tema
Odoo
SAP Private/Tailored
Oracle NetSuite
Implicación
Administración
Odoo.sh prueba gestión de proyecto, ramas, backups e importación; no se traslada a Online.
Cliente configura procesos y seguridad aplicativa/datos; no se concede SO o base.
Cliente gestiona roles, usuarios y credenciales; no infraestructura Oracle.
RACI aplicativa/infraestructura, no “nunca administra”.
Desarrollo
Odoo.sh admite addons, submódulos y XML-RPC con límites; Online no admite apps no estándar. Studio no quedó probado.
Admite modifications, Customer ABAP Add-ons e interfaces bajo gobierno.
SuiteCloud/SuiteScript/SuiteApps provienen de los SSA, no de HSDP sola.
Extensibilidad gobernada; no inferir clasificación SaaS/PaaS de estas fuentes.
Backups y DR
Cloud publica objetivos; Odoo.sh concreta producción y excluye recovery de staging/dev.
El suplemento no publica RPO/RTO general; requiere SLA/SDG/Order.
RPO 1 h/RTO 12 h sólo tras desastre declarado y DR activado, sujeto a Exceptions Policy.
Probar y pactar métricas propias.
Disponibilidad
99.9% target mensual; la página declara que no es garantía vinculante.
Sin porcentaje ni créditos en el suplemento analizado.
99.7% y créditos 10/15/25% condicionados; logs Oracle, solicitud y remedio exclusivo.
Separar target, obligación, SLI, exclusiones y remedio.
Soporte
No acredita una matriz completa para HolosERP.
Límites sí; tiempos requieren Cloud Support Schedule.
Response Time Goals según Basic/Premium; no tiempos de resolución.
Separar respuesta, diagnóstico, workaround, restore y resolución.
Salida
Backup Online y dump de producción Odoo.sh por procedimientos distintos.
Export final solicitado antes de terminar; dos semanas para verificar; sin catálogo integral.
Retrieval a solicitud dentro de 60 días; asistencia facturable; sin promesa de dump/formato.
Catálogo, ventana, verificación, costos y borrado contractuales.
Upgrades
Ciclo Odoo.sh no se atribuye a Online/on-premise.
Cliente instala upgrades salvo inicial y mantiene versión soportada.
No reducción material está en SSA; HSDP sola no prueba el régimen de upgrades.
Política propia de versiones, custom code y EOL.
Responsabilidad
Customizaciones matizan uptime, no trasladan toda responsabilidad.
El cap general requiere GTC/Agreement separado.
Cap general está en SSA; HSDP sólo hace exclusivos créditos específicos.
Definir responsabilidad compartida y límites en contrato.
Límites: los dos enlaces SAP suministrados resuelven al mismo suplemento de seis páginas para Private/Tailored Option; no prueba Public Edition y SLA, DPA, GTC, Order Form y soporte siguen separados. HSDP NetSuite no prueba por sí sola SuiteCloud, exportación autoservicio, upgrades o límites generales. Odoo 18 licencias, Odoo 19 hosting, Online, Odoo.sh y on-premise son alcances distintos; la FAQ prueba una shell, no una promesa expresa de SSH.
Trazabilidad de fuentes
Cada claim de mercado queda anclado al documento exacto, versión, sección y condición. Los hashes corresponden a la captura del 16 de julio de 2026 y deben recalcularse si el proveedor sustituye el activo.
Targets 99.9%, backups, RPO/RTO y seguridad en odoo.com.
La página dice que no son garantías vinculantes.
Afirmación → evidencia → condición → aplicación
Afirmación
Evidencia y página/sección
Condición
Aplicación HolosERP
NetSuite 99.7% y créditos
HSDP III.A, pp. 14-15
Incorporación, EP, impacto, solicitud, cuenta al corriente; 10/15/25% como remedio exclusivo.
Definir SLI, elegibilidad y créditos propios.
NetSuite soporte
HSDP Definitions pp. 5-6; II.D pp. 12-14
Basic/Premium y obligaciones cliente; Response Time Goals, no resolución.
Separar cinco relojes de soporte.
NetSuite RPO/RTO
HSDP I.O, pp. 9-10
Desastre declarado, plan activado, EP; RPO excluye cargas en curso.
No prometer sin escenario y prueba.
NetSuite retrieval
HSDP I.T, pp. 10-11
Solicitud dentro de 60 días; asistencia facturable; sin dump/formato.
Catálogo y test propios.
NetSuite export, SuiteCloud, upgrades y cap
SSA Definitions/§§6.8, 10 y 13.2
SSA/Order aplicables; no provienen de HSDP sola.
Citar instrumento correcto y no decir “autoservicio” sin prueba.
SAP administración/custom code/upgrades
Suplemento §§2.1-2.6 y 3, pp. 1-5
Sólo Private/Tailored; Order/SDG completan alcance.
RACI y extensibilidad gobernada.
SAP export final
Suplemento §2.4, p. 3
Solicitud pre-terminación y dos semanas de verificación.
Definir formato, adjuntos y aceptación.
Odoo licencias
L18, Community/Enterprise/Odoo Apps
Versión 18 y licencia concreta de cada módulo.
SBOM/NOTICE y revisión componente a componente.
Odoo administración/export/upgrades
H19 + FAQ Odoo.sh
Por modalidad; producción distinta de staging/dev.
No trasladar shell/builds/dumps/upgrade policy a Online.
Responsabilidad compartida
SAP §§2.6/3; HSDP I.I/K; Odoo por modalidad
Cada fuente distribuye ámbitos distintos.
Accountability único no significa responsabilidad absoluta.
Compliance SaaS
El baseline legal mexicano no es coleccionar certificaciones. Es privacidad lícita, seguridad proporcional, confidencialidad, incidentes, encargados/subencargados, transferencias, conservación, evidencia, PI/licencias y obligaciones fiscales/mercantiles propias.
A · Legal general
Piso mexicano
Privacidad, avisos, consentimiento, ARCO, seguridad, incidentes, contratos de encargo, transferencias, evidencia electrónica, conservación, fiscal, PI, OSS, secretos y personal propio.
MSA, DPA, SLA, seguridad, DR, logs, offboarding, residencia, auditoría y responsabilidad son C al pactarse. Marcos voluntarios son D hasta que regulación o contrato los active.
No son obligaciones legales universales: ISO 27001/27017/27018, SOC 2, CSA STAR, NIST, CIS, OWASP, SLSA/SBOM e ISO 22301. Se vuelven contractuales si se prometen, regulatorias si una norma sectorial aplicable las incorpora o comercialmente necesarias si un comprador condiciona la venta. SOC 2 es una atestación, no una certificación.
Logs íntegros, export/checksum, borrado, evidence pack, regiones, VPAT y pólizas.
D1-D6
ISO 27001/27017/27018, SOC 2, CSA STAR y NIST CSF.
Alcance, SoA/mapeos, evidencia de periodo, CAIQ y perfiles actual/objetivo.
D7-D12
CIS, ASVS, SAMM, SLSA/SBOM, ISO 22301 y WCAG.
Assessment, pruebas, provenance/SBOM, BIA/ejercicios y auditoría accesible.
Minimum viable compliance
Entidad, producto, nube, países, roles y puertas G1-G10 definidos.
Inventario/mapa de datos, avisos, consentimiento y retención versionados.
ARCO probado con plazos 20/15; incidentes sin inventar “72 horas” como regla mexicana universal.
Riesgo aprobado; mínimo privilegio, MFA admin, cifrado en tránsito, secretos, parcheo, backup y monitoreo con evidencia.
MSA, DPA, SLA, seguridad, subencargados y residencia sin claims no demostrados.
Restore, incidente y offboarding probados con adjuntos, diccionario, checksum, revocación y borrado residual.
Evidencia electrónica, CFDI propio y módulo/PAC cliente validados según alcance.
SBOM, NOTICE, licencias Odoo/terceros y cadena de titularidad completos.
Tarjetas excluidas o PCI evaluado; sectores/jurisdicciones B cerrados o fuera de alcance.
Evidence pack con dueño, periodo, excepción y próxima revisión.
Memo de aplicabilidad firmado por abogado mexicano y especialistas sectoriales.
Documentos y anexos contractuales necesarios
Arquitectura documental mínima
Documento
Contenido mínimo
Contrato maestro
Objeto, vigencia, jerarquía, responsabilidad y terminación.
Orden de Servicio
Alcance, precio, entregables, criterios y supuestos.
Anexo de SLA
Disponibilidad, soporte, métricas, exclusiones y remedios.
Anexo de seguridad
Controles, vulnerabilidades, accesos e incidentes.
Tratamiento de datos
Roles, instrucciones, ARCO, subencargados y eliminación.
Matriz de PI y licencias
Odoo, OCA, vendors, código propio y desarrollos específicos.
Política de versiones
Soporte, parches, mantenimiento, migraciones y EOL.
Backup y DR
Retención, RPO, RTO, PITR y simulacros.
Portabilidad
Datos, formatos, relaciones, plazos y costos.
Offboarding
Exportación, revocación, conservación, eliminación y evidencia.
Política de terceros
Evaluación, aprobación, mantenimiento y retiro.
Evidencia electrónica
Firmas, versiones, trazabilidad, conservación y NOM-151 cuando proceda.
Plan de acción 30/60/90 días
Días 0–30 · Definir y medir
Resolver prelación entre ley, licencias, contrato, DPA/SLA, Orden de Servicio, rector, lineamientos y procesos.
Aprobar, versionar y publicar el documento rector y dependencias.
Definir RACI, gobierno y SLA de excepciones.
Verificar infraestructura, tenancy, aislamiento, respaldos y confidencialidad.
Congelar SLA 1 h/8 h, PITR y RPO/RTO contractuales.
Crear CMDB y unificar SLA en Helpdesk.
Completar G1-G10, inventario/mapa de datos y roles responsable/encargado.
Versionar avisos, retención y MSA/DPA/SLA/seguridad.
Inventariar subencargados, regiones y accesos.
Crear matriz PI/licencias y SBOM inicial.
Revisar HUM-OFB y definir portabilidad.
Días 31–60 · Implementar controles
Automatizar backups de base y filestore; cifrado, copia externa y alertas.
Estandarizar pruebas, anonimización y CI/CD con rollback.
Implementar garantía V4, expediente P4 y exportación conciliada.
Implantar IAM, MFA admin, recertificación, vulnerabilidades y logs críticos.
Pilotar PITR sin prometerlo.
Implementar ARCO, consentimiento y evidencia electrónica.
Implantar incident response con criterio mexicano de notificación.
Validar CFDI propio y módulo/PAC si aplica.
Excluir tarjetas o evaluar PCI; bloquear mercados B no aprobados.
Días 61–90 · Demostrar capacidad
Ejecutar restauraciones y medir RPO/RTO.
Simular S1 y vulneración de datos.
Medir respuesta, workaround, restauración y resolución.
Ejecutar offboarding con exportación, checksum, revocación y borrado residual.
Medir SLA real al menos 60 días cuando sea posible.
Auditar backups, monitoreo, CI/CD, accesos y evidence pack.
Completar el minimum viable compliance y cerrar críticos.
Ajustar compromisos a resultados medidos.
Obtener revisión jurídica mexicana y especialistas sectoriales.
Criterios para aprobar la siguiente versión
Documento rector aprobado, firmado, versionado, publicado y con vigencia.
Prelación que protege ley, licencias e instrumentos firmados.
HUM-LIN-HOL y anexos SLA/DPA aprobados y publicados, sin respuestas institucionales contradictorias.
RACI de gobierno con quorum, mayorías, desempate, delegación, conflictos, registro y SLA de excepciones.
Claims de infraestructura y aislamiento verificados contra la arquitectura real.
Adopción con criterios de salida objetivos, medibles y aceptados.
Afirmaciones absolutas eliminadas o condicionadas.
P3 y P4 integradas en una política coherente.
Matriz de PI y licencias por tipo de componente.
Catálogo de datos y paquete de portabilidad definidos.
Disponibilidad, RPO, RTO y retención definidos.
Restauraciones probadas y documentadas.
Odoo Helpdesk como única fuente oficial del SLA.
Capacidad N1/N2/N3 medida.
Fórmula de estimación corregida.
Plazo de cotización iniciado desde un evento controlable.
HUM-OFB revisado mediante simulacro.
Anexos de privacidad, seguridad e incidentes creados.
G1-G10, inventario de datos y roles responsable/encargado aprobados.
Avisos, consentimiento, ARCO 20/15 y retención probados.
Subencargados, incidentes, offboarding y residencia contractualmente auditables.
MFA admin, vulnerabilidades, logs, restore y simulacro con evidencia vigente.
SBOM, NOTICE, licencias Odoo/terceros y cadena de titularidad revisados.
CFDI/PAC, PCI, salud, finanzas, gobierno, consumo y países cerrados o fuera de alcance.
Sin claims de estándares, certificaciones o métricas no demostrados.
Minimum viable compliance completo o N/A fundamentados.
Redacción y aplicabilidad validadas por abogado mexicano y especialistas sectoriales.
Auditoría complementaria del PDF HUM-MOD-HOL-v1.0
Limitación de alcance: se auditó el texto parseado y las imágenes o referencias visuales suministradas del PDF de 10 páginas. No se inspeccionó el archivo binario PDF, sus metadatos, firmas digitales ni propiedades técnicas.
El PDF no reduce los riesgos: los agrava al presentar políticas no aprobadas como reglas uniformes y declararse en la página 1 “Documento rector — gobierna a todos los lineamientos, procesos y contratos”, aun siendo “Borrador v1.0” sin firmas visibles.
Clasificación de hallazgos diferenciales
Hallazgos nuevos, agravados y ya cubiertos
Clasificación
Hallazgo diferencial
Referencia
Nivel
Agravado
Pretende gobernar lineamientos, procesos y contratos siendo borrador sin firmas.
pp. 1, 8, 10
Crítico
Nuevo
P7 afirma SLA “publicados”, pero HUM-LIN-HOL figura “Por elaborar”.
pp. 6, 8
Crítico
Nuevo
Jerarquía absoluta invertida: un documento interno no prevalece sobre ley, licencias ni contratos firmados.
p. 8
Crítico
Cubierto y agravado
“Operando, disponible, respaldada, actualizada y evolucionando”, “garantiza” y “un solo responsable” carecen de métricas, exclusiones y responsabilidad compartida.
pp. 2, 4
Crítico
Cubierto y agravado
“Propiedad plena” y “cien por ciento del valor” no distinguen titularidad, datos personales, conservación fiscal ni completitud.
pp. 2, 4
Crítico
Nuevo
“Infraestructura propia” requiere verificación; recursos de terceros deben describirse como contratados o administrados.
p. 2
Alto
Nuevo
“Todos los clientes hospedados” sugiere recursos compartidos: deben aclararse aislamiento, blast radius, backups, accesos y confidencialidad.
p. 4
Crítico
Cubierto y agravado
Solicitar BD, módulo o acceso no convierte por sí solo SaaS en PaaS/IaaS; un dump no sirve únicamente para replicar.
pp. 3, 4, 9
Alto
Ya cubierto
Negación de código, dumps, credenciales y licencias, y atribución total de PI, exige distinguir activos, licencias, datos y portabilidad.
pp. 2, 4
Crítico
Cubierto y agravado
P4 exige controles válidos, pero el rechazo “sin excepción” puede impedir mitigaciones y no reemplaza el análisis integral.
p. 5
Alto
Nuevo
Cinco pilares “en un solo servicio” frente a tres componentes “siempre cobrados” por separado.
pp. 5, 7
Alto
Nuevo
Exploración pagada obligatoria y cierre de Adopción “con confianza”; este último no es auditable.
p. 7
Alto
Nuevo
N1/N2/N3 se declara sin evidencia de dotación, cobertura, guardias, escalamiento o desempeño.
p. 7
Alto
Nuevo
Decisión de “tres direcciones” con cuatro funciones, sin quorum, mayoría, desempate, delegación, conflictos, registro ni SLA.
p. 10
Alto
Agravado
Agromol justifica controles del caso, no una conclusión universal sobre solicitudes de base de datos.
p. 9
Alto
Agravado
El guion dice que las reglas aplican a todos, pero reconoce legacy, regularización y excepciones.
La pretensión normativa excede su estado. Debe marcarse “no vigente” hasta aprobación, firma, publicación y vigencia.
2
Operando, disponible, respaldada, actualizada y evolucionando; nunca licenciamiento; infraestructura propia; cliente nunca administra; propiedad plena; responsable único; no entrega de código, dump, credenciales ni licencias.
Sustituir absolutos por alcance, métricas, exclusiones, licencias y responsabilidad compartida. Verificar infraestructura.
3
Solicitar BD, módulo o acceso cambia SaaS a PaaS/IaaS; SaaS idéntico, autoservicio y sin personalización; un “sí” detiene la solicitud.
Confunde modalidad con acceso/extensibilidad. Evaluar riesgo, necesidad y salvaguardas, no etiquetas.
4
P1 protege a todos los hospedados; P2 garantiza históricos; dump transfiere plataforma; exportación entrega cien por ciento del valor; toda PI es de HumandNet.
Definir tenancy, aislamiento, catálogo de exportación, integridad y separación de datos, esquema, código y licencias.
5
P4 restringe fuente, exige licencia, mantenimiento, pruebas y tres aprobaciones; rechazo sin excepción; P5; tres componentes cobrados; infraestructura trasladada; desarrollo menor sin cuantificar.
Formalizar expediente, autoridad y excepciones. Conciliar precios, incluidos, adicionales y límites.
6
P7 declara SLA publicados; P8 ofrece exportación como servicio, gracia y paquetes post-cierre.
No declarar publicado lo que p. 8 marca por elaborar. Definir salida básica antes del cierre.
7
Cinco pilares sin cambios y en un solo servicio; Exploración pagada; Adopción hasta operar con confianza; N1/N2/N3.
Alinear empaquetado y P6; transparentar Exploración; reemplazar confianza por competencia y aceptación verificables.
8
Jerarquía absoluta; HUM-LIN-HOL y contrato por elaborar; HUM-REQ pendiente; HUM-OFB emitidos; referencia obligatoria; regularización.
La jerarquía no aplica con instrumentos incompletos. Renovaciones requieren incorporación expresa; contratos vigentes no cambian unilateralmente.
9
Agromol busca replicar Odoo; una BD no resuelve necesidad legítima; reglas para todos.
La intención concreta sustenta el caso, no una negación universal. Legacy y excepciones impiden uniformidad actual.
10
Dirección General propietaria; Comercial/Técnico Operativa interpretan; Desarrollo dictamina; cambios por tres direcciones; excepciones; revisión anual; firmas vacías.
Definir órgano y reglas. Revisión anual no sustituye versiones, vigencia, trazabilidad ni gestión de excepciones.
Correcciones normativas recomendadas
Orden de prelación
Leyes, reglamentos y resoluciones obligatorias.
Licencias de software y derechos de terceros en su ámbito.
Contrato maestro y convenios firmados.
Anexos firmados de datos, seguridad y SLA; el especializado prevalece en su materia.
Orden de Servicio para alcance, entregables, precio y criterios, sin reducir obligaciones superiores.
Políticas incorporadas expresamente, con código, versión y fecha.
Lineamientos internos, sin capacidad de modificar unilateralmente lo anterior.
La prelación definitiva requiere validación jurídica mexicana y armonización contractual. Publicar una política interna no equivale a aceptación contractual.
Gobierno y excepciones
Definir órgano inequívoco, RACI, integrantes con voto y consultivos, quorum, mayorías y unanimidad, desempate, delegaciones y suplencias, conflictos de interés, expediente y vigencia de excepciones, SLA y reconsideración, y registro de versiones, decisiones y comunicaciones.
Responsabilidad y arquitectura
“Un solo responsable de que todo funcione” debe ser un solo punto de accountability frente al cliente, respaldado por una matriz compartida. HumandNet responde por coordinación y componentes bajo su control; PAC, SAT, telecomunicaciones, nube, vendors y uso del cliente requieren obligaciones, dependencias, escalamiento y exclusiones, sin excluir responsabilidades irrenunciables.
“Infraestructura propia” debe reemplazarse por la descripción comprobada: propiedad de, contratada por o administrada por HumandNet. Si hay recursos compartidos, documentar tenancy, aislamiento, credenciales, backups, blast radius y confidencialidad.
Datos, exportación y Adopción
Separar derechos contractuales del cliente; derechos de titulares y roles de privacidad; obligaciones fiscales, contables, laborales y de conservación; y derechos sobre software, esquema, configuración, metadatos y terceros. Sustituir “históricos” y “cien por ciento del valor” por catálogo con alcance, periodos, formatos, relaciones, adjuntos, metadatos, conciliación, exclusiones, plazo y costo.
Adopción debe cerrar con usuarios clave capacitados, evaluación mínima, procesos críticos sin asistencia, incidencias bloqueantes cerradas, documentación entregada y aceptación formal.
Conclusión diferencial
El PDF eleva el riesgo al convertir definiciones no aprobadas en aparentes respuestas institucionales. La contradicción inmediata es afirmar que los SLA están publicados mientras HUM-LIN-HOL figura por elaborar. La estructural es pretender que un borrador sin firmas gobierne contratos y documentos inexistentes o no validados.
Debe marcarse HUM-MOD-HOL-v1.0 como borrador no vigente y no utilizable como respuesta contractual o institucional. Hasta resolver prelación, documentos dependientes, gobierno, arquitectura, capacidad y empaquetado, no debe presentarse como política vigente, regla uniforme ni documento con prevalencia contractual.
HumandNet no entrega únicamente acceso a un ERP; entrega una plataforma operada, acompañada y evolucionada bajo gobierno técnico.
La propuesta puede ser diferenciada, pero debe expresarse como resultados medibles: servicio conforme a niveles definidos, no “siempre disponible”; mantenimiento según versiones, no “siempre actualizado”; exportación según catálogo; recuperación según RPO/RTO probado; evolución cotizada y gobernada; y derechos definidos por activo, no propiedad absoluta de todo el software.
Conclusión: hasta completar estos controles, el documento debe mantenerse como borrador conceptual interno, no como promesa comercial o contractual vigente.
Nota legal
Este dictamen es una evaluación técnica, operativa y documental. No constituye opinión legal ni sustituye la revisión de un abogado mexicano especializado en servicios tecnológicos, privacidad, propiedad intelectual, contratación electrónica, fiscal y competencia, ni la de especialistas sectoriales o de cada jurisdicción aplicable. La aplicabilidad debe revalidarse por entidad, producto, flujo de datos, cliente, país, industria, contrato y fecha antes de comercializar o asumir compromisos.