Parks Industrial · Coordinación de TI
Arquitectura del CRM de Parks
Diseño técnico del CRM como módulo de la Suite: entidades, módulos, integraciones, decisiones de diseño y plan por fases, con lo que cada área debe definir para que TI avance.
Fecha10 de septiembre de 2026
EstadoDiseño en papel, sin código
BaseRepositorio de la Suite y alcance V1
ElaboróCoordinación de TI
La conclusión
39
Entidades
20
Módulos
15
Integraciones
33
Decisiones
6
Fases
27
Pendientes de negocio
Tesis
El CRM puede estar listo el 18 de diciembre de 2026, con la primera entrega el 2 de octubre: renovaciones con semáforo, expediente documental del cliente e inventario con estatus comercial.
Son 14 semanas desde el lunes 14 de septiembre con dos personas desarrollando con Claude Code, el extremo rápido del rango estimado (10 a 16 semanas), que se logra construyendo Comercial y Legal en paralelo. La fecha se sostiene si las decisiones llegan en su fecha límite; si alguna no llega, esa pieza se entrega configurable y apagada y el cierre no se mueve.
1 · Cómo se ve de un vistazo
Dos diagramas resumen la arquitectura: dónde vive el CRM y qué toca, y cómo recorre la operación un mismo folio entre áreas. Se generaron con Archify y pasaron sus nueve comprobaciones de composición.
2 · Decisión de arquitectura
Módulo de la Suite, no una aplicación aparte: el mismo backend (Express/Prisma), la misma base PostgreSQL, la misma SPA (apps/suite) y el mismo despliegue en los tres ambientes (9000/9001/9002). Eso sí, con una frontera interna estricta que permita separarlo más adelante sin reescribirlo.
Por qué va dentro: (1) Lo que el CRM reusa son llaves foráneas en la misma base, no servicios: User/Empleado para firmar por puesto (FlujoPuesto, schema.prisma:222), Ticket para el aviso de cierre que hoy manda Legal (disc-legal P8), OracleIngreso para cartera (schema.prisma:1444), TareaDiaria para avisos (schema.prisma:1475), Nave. Como aplicación aparte, cada una de esas relaciones se vuelve una integración por API que mantiene una sola persona. (2) RBAC, notificaciones, subida de archivos, PDF, Oracle, respaldos diarios de los tres ambientes y migraciones de Prisma (ordenadas el 03-sep-2026) ya funcionan una sola vez. Duplicarlos es la deuda más cara a tres años. (3) El frontend se acaba de unificar (14-ago-2026) en una sola SPA con un solo inicio de sesión. Una segunda aplicación deshace esa decisión.
Los "usuarios distintos" no justifican separarla. Los comerciales, abogados, CxC y Dirección son empleados: cuentas de la Suite con roles distintos, que es justo lo que resuelve el RBAC. Los brokers son externos y no deben ser usuarios de la Suite. Siguen en el sitio público, donde ya tienen alta, aprobación y descargas en producción, y la Suite los ve como entidad Broker, no como cuentas.
El "ciclo de vida propio" se atiende con la frontera, no con otra aplicación: - Código en carpetas crm-* que solo consumen los servicios compartidos (auditoría, folio, avisos, aprobaciones, notificaciones, documentos, Oracle) por funciones declaradas. - Tablas propias con nombres sin ambigüedad. - Traspasos entre áreas concentrados en un módulo. - Entrega por fases a través de QA y desarrollo.
Riesgo aceptado a sabiendas: hoy un despliegue reinicia todo el backend (docker restart suite-backend), así que un error del CRM afecta a RR.HH., tickets y compras. Si en operación eso se vuelve un problema, la frontera permite levantar el CRM como un segundo proceso del mismo código contra la misma base.
Descartado también: construirlo en el sitio público (Next.js). Ahí están brokers e inventario, pero vive en un VPS público fuera de la red de Parks, y el alcance (sección 05) exige instalación en infraestructura propia sin que la información salga de su red.
3 · Módulos
Los módulos crm-* solo consumen los servicios comunes por funciones declaradas; no se llaman entre sí salvo a través de crm-flujo, que es el único dueño del traspaso del folio entre áreas.
| Módulo | Responsabilidad | Depende de |
|---|---|---|
| auditoria (transversal, nuevo) | Función auditar(tx, acción, entidad, antes, después) que se llama dentro de la misma transacción de cada acción crítica, más la consulta de la bitácora en Administración → Bitácora. Sirve a toda la Suite, no solo al CRM. | prisma, auth, rbac |
| folio (transversal, generalizado) | Un solo generador con prefijo libre y sondeo hasta encontrar un folio libre (lógica de tickets/folio.ts). El CRM lo usa desde el inicio; las cinco copias existentes no se migran dentro de este proyecto. | prisma |
| avisos (transversal, adapta notifications/avisosDiarios.ts) | Reglas de aviso con umbrales configurables, idempotencia por AvisoEnviado y corrida registrada en TareaDiaria. Agrega tareas cada N minutos al planificador del proceso (hoy solo hay una corrida diaria a las 8:00) y deja visible el correo que no salió. | notifications (emailService), crm-parametros, auditoria |
| aprobaciones (transversal, adapta rrhh/movimientoService.ts y mantenimiento/flujoService.ts) | Aprobación secuencial por puesto: crea los pasos según FlujoPuesto, valida quién puede decidir cada paso, registra decisión y motivo, y avisa al origen. | rbac, users/Empleado, FlujoPuesto, auditoria, notifications |
| auth (extensión) | Inicio de sesión con Microsoft 365 / Entra ID con la verificación reforzada del inquilino de Microsoft, obligatorio para los roles del CRM. docs/11-integracion-microsoft-365.md lo da por preparado, pero en backend/src no hay una sola referencia a M365_ ni a OIDC. | configuración del inquilino de M365 (la hace su administrador), rbac |
| crm-parametros | Catálogos del CRM (CrmCatalogo) y parámetros con vigencia (CrmParametro). Es el lugar donde se cargan los umbrales, SLA, criterios y esquemas cuando el levantamiento los defina. | rbac, auditoria |
| crm-inventario | Parques, espacios arrendables y su estatus comercial. Recomendación de espacios por filtros deterministas (m², mínimo divisible, región, fecha, tipo). Cuando un espacio se libera, avisa para la reactivación. | asistencia (Nave, solo lectura), crm-parametros, auditoria |
| crm-cuentas | Cuentas, contactos y brokers con su clasificación. Detección de duplicados. Correspondencia validada con el cliente de Oracle. | oracle (tabla espejo OracleIngreso, solo lectura), crm-parametros, auditoria |
| crm-marketing | Campañas y espejo de fichas enviadas o descargadas. No calcula indicadores: eso vive en crm-tableros, para no crear dependencia de ida y vuelta con prospectos. | crm-parametros, auditoria |
| crm-prospectos | Captación desde todos los canales con origen obligatorio, cola de asignación del Director Comercial (quién asignó y cuándo), calificación que condiciona el avance, descarte con motivo y conversión a Oportunidad y Cuenta. | crm-cuentas, crm-marketing (referencia a Campana), crm-parametros, folio, auditoria, notifications |
| crm-expediente | Documentos de cuenta y de operación, checklist por tipo de contrato, vigencias y escalamiento de faltantes. Lo usa Comercial, que valida al cliente antes de llegar a Legal (disc-legal P3), y lo usa Legal. | attachments/upload.ts, crm-parametros, avisos, auditoria |
| crm-oportunidades | Embudo de las etapas 04-07: requisitos de avance evaluados en el servidor, tours, actividades, propuestas de renta con cálculo, condiciones especiales, Hoja de Acuerdos en PDF, pérdida, pospuesta y reactivación. | crm-inventario, crm-cuentas, crm-expediente, aprobaciones, crm-parametros, folio, auditoria, notifications |
| crm-comite | Regla de disparo por m², monto total o nivel de cliente, foto fija del trato, votación con motivos, regla de mayoría configurable, escalamiento a Dirección y bitácora de cada decisión. | crm-parametros, auditoria, notifications |
| crm-legal | Casos por instrumento, asignación de abogado, reloj de SLA desde la entrega de la Hoja de Acuerdos, semáforo, contratos y versiones con huella, alertas de renovación desde 12 meses antes y detección de vencidos sin renovar. Solo el director legal, el subdirector legal, Dirección General y la responsable de carga pueden modificar; los abogados leen (disc-legal P9). | crm-expediente, crm-cuentas, crm-inventario, crm-parametros, avisos, auditoria |
| crm-cxc | Perfil de cobro, calendario de renta, cartera priorizada con antigüedad calculada desde el calendario, gestión de cobranza, depósitos, escalaciones INPC y ajustes con aprobación. Concilia contra lo facturado y aplicado en Oracle. No factura ni mueve fondos (alcance 08). | oracle (espejo), crm-cuentas, aprobaciones, avisos, crm-parametros, auditoria |
| crm-flujo (traspasos entre áreas) | Es el único dueño del recorrido del folio entre áreas: oportunidad → comité → Legal → CxC, el regreso a negociación por rechazo o faltantes, y la apertura de renovaciones desde contratos por vencer. Valida la completitud antes de cada traspaso, crea el caso de la siguiente área en la misma transacción y genera el ticket para las áreas que no usan el CRM. Los módulos de área no se llaman entre sí; así no hay ciclos. | crm-oportunidades, crm-comite, crm-legal, crm-cxc, crm-expediente, tickets, notifications, auditoria |
| crm-comisiones | Esquemas y cálculo de comisión al firmarse el contrato. La estructura se construye; el cálculo espera a que Parks describa los tres esquemas. | crm-legal (contrato firmado), crm-cuentas (broker), crm-parametros, aprobaciones, auditoria |
| crm-tableros | Vistas SQL de solo lectura en un esquema 'reportes' de PostgreSQL. De ellas salen los seis tableros por área, el de Dirección y la alimentación a Power BI, así cada indicador tiene una sola definición. Los KPI concretos no están definidos (alcance 03). | tablas de todos los módulos crm-* (solo lectura), rbac |
| crm-integraciones | Conector con el sitio público por consulta periódica desde la Suite. Importadores de Monday.com y del Excel de renovaciones con mapeo por encabezado y modo simular (patrón de rrhh/kardexService.ts). Carga de prospectos del Call Center. | crm-prospectos, crm-cuentas, crm-inventario, crm-marketing, avisos (programación), auditoria |
| Frontend: apps/suite, grupos del CRM | Pantallas por área dentro del chasis actual (SuiteLayout, usePermisos/puede, Paginador, patrón de expediente con pestañas), con carga diferida por módulo. Las pantallas de tour y seguimiento se diseñan para el teléfono. | endpoints crm-* bajo /api/v1, rbac (/rbac/me/permisos) |
4 · Modelo de datos
Ninguno de los objetos centrales de un CRM existe hoy en la Suite. Tres nombres del esquema actual se parecen a lo que se necesita sin serlo: Nave es la geocerca de asistencia, RenovacionContrato es la renovación laboral de un empleado y Cotizacion es la cotización de un proveedor sobre un ticket. Se reusan mecanismos, no modelos.
| Entidad | Propósito | Origen |
|---|---|---|
| User / Empleado | Comerciales, Director Comercial, marketing, comité, abogados, CxC y Dirección son cuentas de la Suite. El puesto del Empleado resuelve quién firma cada paso. | existente sin cambios (schema.prisma:18 User; Empleado ligado por correo) |
| FlujoPuesto | Define por PUESTO quién aprueba condiciones especiales, ajustes de cobranza y la firma interna. Coincide con cómo describió Legal a sus cuatro firmantes por cargo. | existente (schema.prisma:222-233). Se extiende solo con nuevos valores de 'funcion' (p. ej. crm_condiciones_especiales, crm_ajuste_cobranza), sin cambio de esquema |
| Nave | Ancla física y geográfica del espacio arrendable. No se usa como inventario comercial. | existente (schema.prisma:1509-1533). Solo se referencia desde EspacioArrendable; no se tocan 'tipo' ni 'direccion' porque asistencia, inventarios y activos de TI dependen de ella. Nota: el comentario en schema.prisma:1503 habla de '100+ naves' y hay 46 cargadas |
| Parque | Catálogo de parques con mercado y municipio. Termina con el texto libre de Nave.parque y Vacante.parque y permite reportar por parque y región. | nuevo (semilla: los 29 valores de asistencia/naves-parks.json y Market/Municipality del sitio público) |
| EspacioArrendable | Unidad que se renta; puede ser una fracción de nave. Guarda superficie disponible, mínimo divisible, tipo de espacio (catálogo: los '3 tipos de m²' de la etapa 04 no están descritos), fecha de disponibilidad, estatus comercial (disponible / en negociación / ocupado), la clave del sitio (slug) y la nave opcional. | nuevo. Atributos técnicos tomados de Property del sitio (parks-industrial-web/prisma/schema.prisma:144); referencia opcional a Nave |
| Cuenta | Cliente o inquilino: razón social, RFC como llave de negocio candidata, grupo, nivel de cliente (lo pide la regla de disparo del comité, lámina 10) y dueño comercial. | nuevo (en la Suite 'cliente' solo existe como texto en Empleado.cliente y OracleIngreso.cliente) |
| Contacto | Personas del lado del cliente con su rol en la decisión. Cuántos intervienen no está en la documentación (P17 comercial sin responder). | nuevo |
| Broker | Intermediario con su clasificación (alcance 04) y estatus. Guarda la llave del usuario BROKER del sitio para cruzar sus prospectos y descargas. No es cuenta de la Suite. | nuevo, espejo del User BROKER del sitio (parks-industrial-web/prisma/schema.prisma:41-101). NO reusar Proveedor: aparecería en la Matriz de Proveedores |
| Prospecto | Etapas 01-03 del embudo. Guarda origen obligatorio (catálogo), campaña, broker, requerimiento (empresa, giro, región, m², plazo), huella para detectar duplicados, dueño, quién asignó y cuándo, calificación y motivo de descarte. Al calificar se convierte en Oportunidad. | nuevo (se inspira en Lead del sitio :13-25 y en los campos cliente* del broker) |
| Oportunidad | Etapas 04-07 y portadora del FOLIO ÚNICO que la acompaña por Comité, Legal y CxC. Tipo (nueva / renovación), etapa, cuenta, dueño, broker, m² requeridos, fechas, motivo de pérdida y fecha de pospuesta. | nuevo. El folio sale del generador de tickets/folio.ts generalizado a un prefijo libre (hoy generateFolio está atado al enum TicketType) |
| OportunidadEtapa | Historial de avance: de qué etapa a cuál, quién, cuándo, qué requisitos se cumplieron o qué autorización excepcional se dio y con qué motivo. | nuevo (patrón de TicketStatusHistory :320 y de la excepción con motivo de Compras, comprasService.ts:307-350) |
| RequisitoEtapa | Catálogo configurable de lo que exige cada etapa para avanzar: campo lleno, documento cargado, actividad registrada o aprobación resuelta. | nuevo |
| OportunidadEspacio | Espacios de interés o propuestos con m². Es la base de la recomendación y de la reactivación cuando se libera un espacio compatible. | nuevo |
| Tour y TourAsistente | Visita al parque con fecha, espacios recorridos, asistentes del cliente y seguimiento posterior (alcance 04). | nuevo |
| Actividad | Seguimiento con fecha compromiso (llamada, correo, reunión, tarea) sobre prospecto, oportunidad o cuenta. Sustituye las notas dispersas de la etapa 05. | nuevo |
| PropuestaRenta y PropuestaRentaEspacio | Cotización de renta con versiones por ronda de negociación: renta por m², moneda, plazo, escalación, periodo de gracia, depósito y condiciones especiales. Dinero en Decimal. | nuevo (forma de OrdenCompra/OrdenCompraPartida :1202-1258). NO reusar Cotizacion (:235): es la cotización de un proveedor sobre un ticket |
| Aprobacion y AprobacionPaso | Aprobación secuencial por puesto: condiciones especiales en fase 1, ajustes y notas de crédito en fase 3. Guarda la decisión, quién decidió y el motivo. | adapta MovimientoAprobacion (:802) y movimientoService.ts; firmantes vía FlujoPuesto |
| HojaAcuerdos | Foto fija, sin cambios posteriores, de la propuesta aceptada, con su firma y la fecha de entrega a Legal. Esa fecha arranca el reloj de 45/60/90 días (disc-legal P7) y abre el comité si aplica. | nuevo. PDF con pdfkit (patrón existente). Si dirección autoriza firma por enlace, adapta ResponsivaTI (:1657-1697); la modalidad de firma de la Hoja no está en la documentación |
| Campana | Campaña de marketing con canal. Los prospectos la referencian para medir por canal y saber en qué etapa se perdió cada uno. | nuevo |
| FichaEnvio | Espejo de las descargas y envíos de fichas técnicas por broker (quién, qué nave, cuándo). | espejo de FichaDescarga del sitio (parks-industrial-web/prisma/schema.prisma:248-260) |
| CrmCatalogo | Orígenes, motivos de pérdida, tipos de espacio, tipos de documento, tipos de instrumento y criterios de calificación, sin texto libre. | nuevo (forma de RrhhCatalogo :655) |
| CrmParametro | Parámetros con vigencia: umbrales del comité, días de SLA por tipo de instrumento, umbrales de aviso, pesos de calificación y regla de mayoría. Cada caso guarda copia de la regla con la que se decidió. | nuevo |
| EsquemaComision y Comision | Esquemas de comisión y comisión calculada por contrato firmado, broker o ejecutivo. Los tres esquemas de la lámina 9 no están descritos en ninguna fuente. | nuevo |
| CasoComite y VotoComite | Se abre cuando la operación supera el umbral. Guarda foto fija del trato (parque, nave, m², precio de lista contra acordado, plazo, gracia, broker), votos con motivo, resultado y escalamiento a Dirección. Los votos no se pueden modificar. | adapta el voto en paralelo de ChangeApproval (:395, changesRoutes.ts:37-102); modelo nuevo |
| CasoLegal | Caso por instrumento (arrendamiento, renovación, terminación anticipada, modificatorio). Guarda abogado asignado, reloj de SLA que arranca con la entrega de la Hoja de Acuerdos, pausas, semáforo y estatus. | nuevo. NO extiende SLA (:115): está atado al enum de prioridad y mide minutos desde el alta |
| RequisitoDocumental | Checklist por tipo de contrato: acta, poder, comprobante de domicilio, INE del representante, CSF, constancia de cumplimiento, garantía y estados financieros auditados del obligado solidario (disc-legal P3). | nuevo |
| DocumentoCuenta y DocumentoOperacion | La base documental del cliente, con vigencia porque se reusa entre operaciones, y los documentos propios del folio. Ambas con llave foránea real. | nuevo (forma de ProveedorDocumento :923-943). Subida con attachments/upload.ts. NO se usa Attachment: exige ticketId (:350) |
| ContratoArrendamiento, ContratoEspacio y ContratoVersion | Contrato por instrumento con fechas, renta, moneda, escalación, depósito, fecha de restitución y estatus, incluido 'vencido sin renovar con inquilino activo' (disc-legal P10). Espacios que ampara. Versiones con número y huella SHA-256 para el cotejo antes de firmar. | nuevo. NO confundir con RenovacionContrato (:680-698), que es el contrato laboral del empleado |
| AvisoEnviado | Registra cada aviso por regla, entidad y umbral; la llave única impide duplicados. Sirve a renovaciones (desde 12 meses), documentos por vencer, SLA de Legal, escalaciones y cobranza. | nuevo. Las corridas se registran en TareaDiaria (:1475) tal cual |
| PerfilCobro | Lo que CxC no ve hoy (lámina 15): contacto y correo de facturación, si el cliente exige orden de compra o carga de la factura en su portal de proveedores, y día de pago. | nuevo |
| CalendarioRenta | Cargos pactados por periodo con fecha de vencimiento, prorrateos, depósito e incentivos. Da la antigüedad de saldos que la vista de Oracle no trae (no tiene fecha de vencimiento). | nuevo |
| GestionCobranza | Acciones de cobranza con resultado, promesa de pago y escalamiento, para priorizar la cartera. | nuevo |
| DepositoGarantia | Ciclo del depósito: recibido, retenido, devuelto, con autorización. Las condiciones de liberación no están en la documentación (P8 de CxC sin responder). | nuevo |
| EscalacionRenta e IndiceInpc | Ajuste anual por contrato y valores del INPC capturados, para avisar antes de la fecha y no aplicar retroactivo (lámina 17). | nuevo |
| AjusteCobranza | Notas de crédito, condonaciones, actas de restitución y cobro en situación de vencido sin renovar, con su aprobación y motivo. | nuevo; su autorización usa Aprobacion |
| ClienteOracle | Correspondencia validada entre Cuenta y el texto 'cliente' de Oracle, para que la cartera cuadre con la contabilidad. | nuevo. Lee OracleIngreso (:1444-1473) sin cambiarlo |
| Notification | Aviso en la aplicación que lleva a la ficha del CRM correspondiente. | existente (:409-421). Se extiende con entidadTipo/entidadId (o enlace) opcionales; hoy solo liga a ticketId |
| Ticket | Aviso de cierre a áreas que no usan el CRM (Facturación, administrador del parque), como hoy lo hace Legal por ticket. | existente (:141-197) sin cambios |
| Bitacora | Auditoría transversal de toda la Suite: quién, cuándo, acción, entidad, folio, valores antes y después, IP. Solo se agregan registros. | nuevo. El submódulo 'bitacora' ya existe en el catálogo RBAC (rbacService.ts:35) sin nada detrás |
5 · Integraciones
| Sistema | Dirección | Mecanismo |
|---|---|---|
| Oracle EBS, vista XXSINGU_INGRESOS_V | Oracle → Suite, solo lectura | La sincronización programada que ya existe (oracleClient en modo thick, tabla espejo OracleIngreso, bitácora OracleSync) ejecuta solo SELECT. El CRM lee el espejo, nunca Oracle directo, y cruza con Cuenta mediante ClienteOracle. Oracle y LDAP están apagados en QA y desarrollo, así que la conciliación solo se prueba con datos copiados. |
| Oracle EBS, vista de saldos y vencimientos (no existe todavía) | Oracle → Suite, solo lectura | Hay que pedir al área de Oracle una vista con fecha de vencimiento o saldo abierto por factura. Mientras no exista, la antigüedad sale del CalendarioRenta de la Suite. Si CxC hoy recibe los pagos de Oracle o los captura a mano no está en la documentación (P4 de CxC sin responder). |
| Sitio público de Parks (parks-industrial-web): prospectos, brokers con su requerimiento y descargas de fichas | Sitio → Suite | La Suite consulta cada N minutos una API del sitio con credencial de servicio y cursor por fecha o id. Guarda Prospecto, Broker y FichaEnvio sin duplicar. La conexión sale de la red de Parks hacia el VPS, así que no se abre ninguna ruta pública nueva en la Suite. |
| Sitio público de Parks: inventario técnico | Sitio → Suite en la fase 1; Suite → sitio (estatus comercial) diferido | Misma consulta periódica, con la llave slug del sitio contra la clave de la nave (coincide en mayúsculas en los tres casos revisados; faltan las 46). Según las notas de TI del sitio, superficies y fechas vienen de un PDF de Administración ('Resumen de propiedades'), no de un sistema. Publicar el estatus comercial en el sitio espera a que Comercial responda las preguntas 9 y 10. |
| Mesa de ayuda de la Suite (Ticket) | CRM → áreas que no usan el CRM | Llamada interna al servicio de tickets en la misma transacción del cierre de Legal. Replica el ticket que hoy va a CxC, Facturación, administrador del parque y Comercial (disc-legal P8) y ya lleva los datos del cliente que hoy faltan (lámina 14). |
| Correo corporativo (SMTP de Office 365) | Suite → usuarios internos | El emailService actual, con el aviso en la aplicación como respaldo. Se agrega registro visible del correo que falló (hoy solo se anota en consola). Sin envíos masivos a prospectos desde este canal. |
| Power BI | Suite → Power BI, solo lectura | Usuario de base con permiso SELECT solo sobre las vistas del esquema 'reportes'. Si Power BI es el servicio en la nube hará falta su puerta de enlace de datos local, y los datos saldrían de la red: lo decide dirección frente al alcance 05. Qué fuentes alimentan hoy los tableros existentes no está en la documentación. |
| Call Center | Call Center → Suite | No está en la documentación qué sistema usa ni si expone interfaz. Mientras tanto: captura directa en la Suite con un rol 'captura de prospectos', o carga de archivo con el importador en modo simular. El origen 'Call Center' queda obligatorio. |
| Monday.com | Monday → Suite, una sola vez | Exportación a Excel desde Monday e importador con mapeo por nombre de encabezado, llave de negocio y modo simular. La interfaz de Monday no se revisó. Volumen y antigüedad los define el levantamiento (alcance 03). |
| Excel de renovaciones de Legal | Excel → Suite, una sola vez | Mismo importador. Carga contratos vigentes y fechas de término para arrancar las alertas desde 12 meses antes. |
| Microsoft 365 / Entra ID | Entra ID → Suite (identidad y verificación reforzada) | Inicio de sesión OIDC con la verificación en dos pasos del inquilino de Microsoft. La baja de un colaborador en Microsoft 365 le quita el acceso al CRM. Hay que construirlo: la guía docs/11 existe, el código no. |
| Directorio LDAP | Directorio → Suite | Existente (auth/ldapProvider.ts). Queda como respaldo dentro de la red. |
| INPC (INEGI) | Captura → Suite | Captura mensual del índice publicado en IndiceInpc, con registro de quién lo capturó. La consulta automática a INEGI queda para después. |
| Acceso desde fuera de la red (túnel de Cloudflare) | Internet → Suite | El túnel ya expone la Suite completa con solo el inicio de sesión (suite.webtestenv.site). Para el CRM, que guarda contratos y cartera, se exige Entra ID con verificación reforzada antes de abrirlo fuera de la red, o Cloudflare Access delante de las rutas no públicas. |
| Firma electrónica de contratos (DocuSign u otra) | No se integra | Legal declaró que todo el circuito de firma es físico por indicación de dirección general (disc-legal P2). La Suite registra la versión firmada escaneada y su cotejo. |
6 · Etapas del embudo comercial
Las etapas y sus requisitos de avance se guardan como datos, no como código: cuando Comercial defina su ciclo de venta, se configuran sin reprogramar.
- 01 Captación de leads: objeto Prospecto. Regla de avance según el alcance 04: origen obligatorio y detección de duplicados. Canales: sitio, brokers, Call Center, captura directa.
- 02 Asignación de lead: cola del Director Comercial con registro de quién asignó y cuándo (alcance 04). La asignación automática por reglas no se construye mientras Comercial no responda la P4.
- 03 Calificación del lead: criterios configurables que condicionan el avance. Si califica, el Prospecto se convierte en Oportunidad con folio y Cuenta; si no, se descarta con motivo. Los criterios no están definidos (P3 comercial sin responder).
- 04 Espacios y tour: recomendación de espacios por filtros deterministas y registro del tour con asistentes, capturable desde el teléfono.
- 05 Seguimiento activo: actividades con fecha compromiso y alertas por inactividad. Para decidir si es etapa o actividad continua falta la P1 comercial. La reactivación está en el alcance para cuando se libera un espacio compatible; la de 'pospuestos a 6 meses' es de la propuesta del proveedor.
- 06 Cotización y LOI: propuesta de renta con versiones y cálculo automático, aprobación de condiciones especiales, y generación y firma de la Hoja de Acuerdos. La equivalencia LOI = Hoja de Acuerdos no está confirmada en la documentación.
- 07 Aprobación y comisiones: traspaso al Comité si la operación supera el umbral (etapas 10-11), o directo a Legal. La comisión se calcula al firmarse el contrato, no es una etapa en la que la oportunidad espere. Cierres: ganada (contrato firmado), perdida con motivo, pospuesta.
7 · Decisiones de diseño
| Decisión | Alternativa descartada | Por qué |
|---|---|---|
| El CRM es un módulo de la Suite (mismo backend, base, SPA y despliegue), con frontera interna estricta. | Aplicación aparte con identidad compartida. Obliga a duplicar RBAC, avisos, archivos, conexión a Oracle, respaldos y despliegue, y convierte cada llave foránea en una integración por API. | Lo que reusa son llaves foráneas en la misma base (User/Empleado y FlujoPuesto, Ticket, OracleIngreso, TareaDiaria, Nave) y servicios que ya corren una sola vez (RBAC, avisos, archivos, PDF, respaldos de los tres ambientes, migraciones ordenadas). Lo mantiene una persona. La frontera deja abierta la opción de moverlo a un segundo proceso del mismo código si su operación llega a afectar al resto. |
| No construir el CRM en el sitio público, aunque ahí estén brokers e inventario. | Extender parks-industrial-web (Next.js) con los modelos del CRM. | El sitio vive en un VPS público fuera de la red de Parks. El alcance 05 exige instalación en infraestructura propia sin que la información salga de su red, y contratos y cartera no deben estar en un servidor expuesto. |
| Los brokers no son usuarios de la Suite: siguen en el sitio y la Suite los ve como entidad Broker, ligada al usuario del sitio. | Cuentas de la Suite o portal de brokers dentro de la Suite. También se descarta guardar brokers como Proveedor, porque aparecerían en la Matriz de Proveedores. | Ya tienen alta, aprobación, cuentas masivas y descargas en producción en el sitio. Meter externos en la tabla User de la Suite mezclaría cuentas de terceros con las de empleados en un sistema que guarda nómina y expedientes. El alcance V1 pide registrar y clasificar brokers, no darles un portal. |
| Un módulo RBAC por área (comercial, marketing, comite, legal, cxc, direccion), cada uno con sus submódulos. | Un único módulo 'crm' en rbacService.MODULOS. | Sigue el catálogo actual, que tiene un módulo por área (personal, compras, finanzas) y un menú por grupo. Legal ya dio sus permisos por área (P9) y cada área tiene su tablero. Un solo módulo 'crm' con treinta submódulos haría ilegible la matriz de roles. |
| Visibilidad por registro (propios / equipo / todos) resuelta en una sola función del servidor que usan todos los servicios del CRM. | Filtros escritos a mano en cada servicio, como hoy 'el solicitante solo ve los suyos' en ticketsService.ts:217-220. | El RBAC actual solo concede por submódulo. El alcance pide que cada persona vea solo lo suyo. Si cada pantalla filtra por su cuenta, en tres años habrá tantas reglas como pantallas y alguna se olvidará. El equipo se obtiene del organigrama, como ya hace 'Mi equipo'. |
| Prospecto y Oportunidad son objetos distintos: el prospecto se convierte al calificar. | Un solo objeto Oportunidad desde el primer contacto. | Los prospectos de sitio, Call Center y campañas llegan en volumen y con duplicados; la lámina 03 se queja de que se toman todos sin criterio. Separarlos protege el embudo y la tabla de Cuentas, y permite medir en qué etapa se perdió cada prospecto de campaña (alcance, Marketing). |
| El folio único vive en la Oportunidad; comité, caso legal, contrato y activación de CxC lo referencian. Las renovaciones son oportunidades de tipo 'renovación' que se abren solas desde el contrato por vencer. | Un folio por área, o un objeto Renovacion aparte del embudo comercial. | El alcance 02 promete un folio que acompaña al expediente por Comercial, Comité, Legal y CxC. Legal atiende renovaciones con un año de anticipación y dice que Comercial es quien se retrasa (P7 y P10). Abrirlas como oportunidades pone la renovación en el embudo de quien la tiene que mover. |
| Las etapas y sus requisitos de avance son datos (RequisitoEtapa), con cuatro tipos de requisito: campo, documento, actividad y aprobación. Una sola función del servidor los evalúa y admite autorización excepcional con motivo. | Enum de PostgreSQL (el propio sitio documenta que ALTER TYPE tumba despliegues con un usuario de base que no es dueño del tipo) o un mapa fijo en código como NEXT_STATUS de tickets. | Las etapas y los campos obligatorios no están definidos (P1 y P6 comerciales sin responder) y cambiarán después del levantamiento. El alcance pide que sean configurables. La excepción con motivo ya es un patrón probado en Compras. |
| Los traspasos entre áreas se concentran en crm-flujo: son síncronos, van en la misma transacción y el correo sale después de confirmar. Los módulos de área no se llaman entre sí. | Bus de eventos o cola externa (infraestructura nueva y otra imagen que mantener), o llamadas directas entre módulos. | El rechazo del comité regresa a Comercial y el caso incompleto regresa desde Legal. Si los módulos se llaman directo, se forman ciclos. Un solo dueño del recorrido del folio concentra las reglas de 'no pasa incompleto'. Con 80 usuarios no hace falta una cola. |
| EspacioArrendable es un modelo propio que referencia a Nave (opcional) y a Parque. Nave no se modifica. | Ensanchar Nave con campos comerciales. | En Nave, 'tipo' significa régimen de checada y 'direccion' guarda el mercado. Asistencia, inventarios y activos de TI apuntan a ella. Además, un espacio rentable puede ser una fracción de nave (mínimo divisible). |
| Inventario: la Suite es la fuente del estatus comercial. Los atributos técnicos se leen del sitio mientras Comercial y Administración no designen la fuente. En V1 no se publica al sitio. | Tomar el sitio como fuente de verdad, o capturar el inventario de cero ignorando lo ya digitalizado. | El estatus comercial no existe en ninguna parte (Property.active significa publicado). Según TI, los datos técnicos del sitio vienen de un PDF de Administración. Además, las 46 naves son las publicadas y el esquema menciona '100+ naves': el universo de naves YA rentadas, que necesitan Legal y CxC, no está en ninguna fuente revisada y hay que cargarlo desde otra fuente o capturarlo. |
| Documentos en dos tablas con llave foránea real: DocumentoCuenta, para la base del cliente con vigencia, y DocumentoOperacion, por folio. Más un checklist por tipo de contrato. | Tabla polimórfica (entidadTipo/entidadId) sin integridad, o generalizar Attachment ahora: exige ticketId y cambiarlo toca Mesa de Ayuda sin pruebas que avisen si algo se rompe. | La base del cliente (acta, poder, INE, CSF) se reusa entre operaciones y caduca; los documentos de la operación no. La llave foránea conserva la integridad que una tabla polimórfica pierde. |
| Los avisos se registran por regla, entidad y umbral en AvisoEnviado, con umbrales en CrmParametro. | Banderas booleanas por umbral en cada tabla, que es la convención actual. | Los umbrales no están definidos. Legal trabaja a un año y el proveedor propone 12/6/3/1 meses. Las banderas aviso15/aviso10/aviso5 en la fila fijan los umbrales en el esquema y obligan a una migración por cada cambio. El precedente de avisosDiarios.ts, donde cuatro de cinco avisos nunca salieron sin que nadie lo notara, obliga a dejar constancia de cada envío. |
| El SLA de Legal es propio del caso: días por tipo de instrumento (45/60/90), reloj que arranca con la entrega de la Hoja de Acuerdos, pausas registradas y semáforo. | Extender el modelo SLA (schema.prisma:115) y su cálculo en ticketsService. | Así lo mide Legal hoy (P7). El modelo SLA de la Suite está atado al enum de prioridad, mide minutos desde el alta y no admite pausas. Si los días son naturales o hábiles no está en la documentación, así que queda como parámetro. |
| El comité es un modelo propio: foto fija del trato, votos en paralelo que no se pueden modificar, regla de mayoría y umbral configurables, y copia de la regla vigente en cada caso. | Reusar ChangeApproval tal cual (cualquier rechazo tumba, sin abstención ni escalamiento) o fijar 2/3 en código. | El umbral no está definido (alcance 09). La mayoría de 2/3 y la abstención aparecen en la columna Salesforce de la lámina, no como regla de Parks. La portadilla dice 'comité de 3'. Guardar la regla con la que se votó permite auditar decisiones pasadas aunque el parámetro cambie. |
| Bitácora transversal escrita a propósito en cada acción crítica, dentro de la misma transacción. Solo admite altas: la tabla pertenece a un rol de base distinto del que usa la aplicación, que solo tiene permiso INSERT y SELECT. | Disparadores de PostgreSQL, que no se ven en schema.prisma y se pierden fácil en una migración, o una extensión de Prisma que registre toda escritura sin significado de negocio. | El alcance la promete dos veces y hoy no existe. Registrar la acción de negocio (quién bajó la renta) sirve más que un volcado de todos los UPDATE. Si la tabla es del mismo usuario de la aplicación, la restricción es de adorno: el dueño puede borrar. |
| Convenciones del CRM: fechas de negocio con DateTime @db.Date e instantes con DateTime; updatedAt en todos los modelos; dinero en Decimal(18,2) con moneda por contrato; identificadores cuid; sin borrado físico (estatus más bitácora); nombres sin ambigüedad (PropuestaRenta, ContratoArrendamiento) en el esquema público. | Heredar la convención de texto 'AAAA-MM-DD' y Float, o crear un esquema 'crm' con multiSchema. | La mitad de la Suite guarda fechas como texto y ya rompió en silencio el cálculo de días restantes (dd/mm/aaaa contra ISO). Solo 7 de 73 modelos tienen updatedAt. Oracle ya distingue moneda y tipo de cambio. Un esquema separado de PostgreSQL exige multiSchema, que en Prisma 5.22 es vista previa y obliga a declarar el esquema en los 73 modelos existentes. |
| Los parámetros de negocio viven en CrmParametro con vigencia, y cada caso copia la regla con la que se decidió. | Variables en .env o una tabla clave-valor que se sobrescribe. | El alcance los deja al levantamiento y dice que se cargan cuando se definan. Van a cambiar durante los tres años, y un umbral sobrescrito borra la explicación de por qué una operación de hace un año sí o no fue a comité. |
| Contratos: V1 registra versiones con número y huella SHA-256, imprime número de versión y huella corta en el pie para el cotejo físico, y guarda el escaneo firmado. No genera el texto del contrato. | Motor de plantillas con campos combinables (docxtemplater o similar) desde la fase 2. | El alcance para Legal dice 'registro de versiones', no generación; los borradores precargados son de la propuesta del proveedor. Legal coteja que la versión firmada sea la impresa (P2). Un motor de plantillas exigiría las plantillas de Legal, que no están en las fuentes, y una dependencia nueva de ejecución, que obliga a rehacer la imagen porque el despliegue copia solo dist. |
| La Hoja de Acuerdos se genera en PDF con pdfkit desde una foto fija de la propuesta aceptada. La modalidad de firma (física o por enlace) queda como parámetro que decide dirección. | Hoja editable en Word fuera del sistema, o firma electrónica impuesta sin decisión de dirección. | Su generación y firma sí están en el alcance (Comercial). Es el evento que abre el comité y arranca el reloj de Legal, así que no puede cambiar después de firmada. La firma por enlace ya existe (ResponsivaTI), pero dirección pidió papel para los contratos y no consta su criterio para la Hoja. |
| CxC: el calendario de renta pactado vive en la Suite y se concilia contra lo facturado y aplicado en Oracle. La facturación se queda en Oracle. | Esperar a que Oracle exponga saldos antes de construir la cartera, o registrar pagos a mano en la Suite. | La vista de Oracle no trae fecha de vencimiento, así que la antigüedad de saldos no sale de ahí. El alcance excluye la facturación electrónica y el movimiento de fondos. El calendario resuelve también la lámina 17: INPC olvidado, restituciones tardías, condiciones que CxC desconoce. |
| La llave entre Cuenta y el cliente de Oracle es una tabla de correspondencia validada por CxC, con sugerencias por similitud de nombre. | Coincidencia automática por nombre sin validación humana. | OracleIngreso.cliente es texto sin identificador. Un cruce automático por nombre que se equivoque pone saldos en el cliente equivocado sin que nadie lo note, y en tres años nadie sabrá por qué. |
| Tableros y Power BI salen de las mismas vistas SQL del esquema 'reportes', con un usuario de base de solo lectura. | KPI calculados en endpoints (patrón de reportsRoutes.ts) y una exportación aparte para Power BI. | Una sola definición por indicador. Si los tableros calculan en endpoints y Power BI en otra consulta, divergen y Dirección recibe dos cifras. Los KPI todavía no están definidos (alcance 03). |
| La integración con el sitio se hace por consulta periódica desde la Suite, con credencial de servicio y cursor. | Aviso HTTP del sitio (webhook) a un endpoint público de la Suite expuesto por el túnel. | El flujo va hacia dentro de la red y la Suite no abre rutas públicas nuevas. Si la Suite está apagada, recupera lo pendiente en la siguiente corrida, cosa que un aviso perdido no hace. |
| La verificación reforzada se da con inicio de sesión de Microsoft 365 / Entra ID, obligatoria para los roles del CRM antes de abrirlo fuera de la red. | Segundo factor propio (TOTP), que deja a TI atendiendo teléfonos perdidos, o dejar el inicio de sesión actual. | Los comerciales trabajan en campo y el túnel ya expone la Suite completa con solo contraseña. Entra ID aplica la verificación de la organización y retira el acceso con la baja del colaborador. Con un equipo de una persona, eso importa más que cualquier mecanismo propio. |
| La IA no entra en la primera entrega. Se construyen reglas explícitas (calificación por criterios, recomendación por filtros, priorización de cartera por antigüedad y monto) y se guardan los datos que después permitan medir un modelo. | Llamadas a servicios de IA externos desde el día uno (enriquecimiento, puntuación, cotejo de contratos). | Es la partida menos especificada del alcance. Usar servicios de IA externos saca información de la red, contra el alcance 05, y eso aplica igual al proveedor. Sin historial limpio no hay qué calificar. |
| El motor de comisiones se deja con estructura y parámetros; el cálculo se construye cuando Parks describa los tres esquemas. | Implementar esquemas supuestos (porcentaje del contrato, por meta o por tipo de nave). | Ninguna fuente los describe (lámina 9, P16 comercial sin responder, alcance 09). Suponerlos produce un motor que se reescribe y comisiones en disputa. |
| El planificador del proceso gana tareas cada N minutos con la misma cerradura y bitácora (TareaDiaria) que la corrida diaria. | Cron del sistema operativo (el usuario rgarcia no tiene sudo y todo vive en contenedores) o una cola externa. | La sincronización con el sitio y los avisos de SLA no caben en una sola corrida a las 8:00, y la recuperación tras un apagado ya está resuelta en server.ts. |
| Frontend: el CRM se agrega en apps/suite con carga diferida por módulo; las pantallas de tour y seguimiento se diseñan primero para el teléfono. | Seguir importando todas las páginas en el paquete inicial, o una app móvil aparte. | App.tsx importa hoy 66 páginas de forma directa y sin carga diferida. Treinta pantallas más harían lento el primer acceso desde el teléfono en un tour. La app nativa está excluida del alcance. |
| Se agregan pruebas automatizadas del CRM desde el inicio, como dependencia de desarrollo, para requisitos de avance, cálculo de renta, SLA, avisos, conciliación y comisiones. | Seguir con verificación manual, como el resto de la Suite. | El repositorio no tiene una sola prueba. Las reglas del CRM son dinero y plazos legales. Una dependencia de desarrollo no llega a la imagen de producción, así que no obliga a reconstruirla. |
| Durante el proyecto no se refactorizan módulos que ya funcionan (las cinco copias del folio, Attachment, SLA, los permisos por banderas heredadas). El CRM usa las piezas nuevas y las viejas se migran después, una por una. | Unificar primero todos los patrones duplicados y luego construir el CRM. | Sin pruebas, tocar Mesa de Ayuda, Compras o RR.HH. para 'aprovechar' mete riesgo en operaciones vivas y mezcla dos proyectos en el mismo plazo. |
| No se envían correos masivos a prospectos desde el SMTP de la Suite; las campañas se registran y se miden, y el envío masivo se hace con la herramienta que Marketing use. | Campañas masivas por nodemailer y SMTP de Office 365. | El alcance para Marketing pide registro, medición y envío de fichas, no una plataforma de correo masivo. Mandar volumen por el buzón corporativo de Office 365 arriesga su reputación y sus límites. Qué herramienta usa Marketing no está en la documentación (P11 sin responder). |
| Poner a decisión de dirección el destino de los respaldos del CRM. | Incluir el CRM en el respaldo actual sin revisar dónde terminan las copias. | El respaldo diario ya existe y cubre los tres ambientes, pero copia los volcados a un VPS externo (74.208.125.151, según las notas de TI). Con contratos y cartera dentro, eso choca con 'la información no sale de su red' (alcance 05). |
8 · Plan por fases
Total: del lunes 14 de septiembre al viernes 18 de diciembre de 2026: 14 semanas con dos personas y Claude Code. Los rangos no incluyen esperas por definiciones de las áreas ni por el acceso a Oracle, y cada fase cierra con una o dos semanas de operación acompañada. Supuesto: dos personas trabajando con Claude Code, con pruebas automatizadas y revisión de código cruzada incluidas en cada rango. La referencia es la propia Suite, que una persona con asistencia de IA construyó en 8 semanas (73 modelos); el CRM equivale a cerca de la mitad de ese esquema, más los cimientos que la Suite no tiene.
Fase 0. Cimientos del módulo CRM dentro de la Suite
Duración. Del 14 al 18 de septiembre (1 semana; el 16 es día de descanso). La lleva el coordinador de TI mientras se integra la segunda persona.
Esta fase construye lo que falta en la Suite y el CRM no puede heredar. (1) Bitácora de auditoría transversal, que el anexo exige en sus secciones 02 y 05; el submódulo "Bitácora" del catálogo de permisos es solo una etiqueta, sin nada detrás. (2) Permisos por registro: Legal pidió lectura para los abogados y modificación solo para cuatro personas, y hoy el control llega a nivel de módulo. (3) Tabla de documentos genérica: Attachment exige un ticket asociado y el patrón de documentos está resuelto cinco veces por separado. (4) Reglas de datos para todo el CRM: fechas como fecha y no como texto, dinero en Decimal y fecha de última modificación en cada modelo. (5) Pruebas automatizadas para cálculos de dinero y plazos; hoy no existe ninguna en el repositorio. (6) Alertas observables: que un correo no enviado quede visible y cada corrida diaria quede asentada. (7) Segundo factor de acceso por aplicación autenticadora. (8) Límite de peticiones y bloqueo por intentos fallidos calculados por usuario y no por dirección de red. (9) Prueba real de restauración de respaldos. (10) Exportar los tableros de Monday y contar los registros activos, lo que toma un día. Aquí también se decide si el CRM corre en el mismo proceso que nómina, compras y mesa de ayuda, o aparte.
Condición · No depende de ningún parámetro de negocio. Depende de que dirección decida la capacidad: contratar un segundo desarrollador o liberar carga a Raúl. Sin esa decisión el proyecto no arranca en serio.
Fase 1. Renovaciones, expediente del cliente e inventario con estatus (primera entrega)
Duración. Del 21 de septiembre al 2 de octubre (2 semanas). Primera entrega el viernes 2 de octubre. Legal entrega el Excel de renovaciones y confirma permisos antes del 18 de septiembre.
Incluye cuatro piezas. (1) Contrato de arrendamiento mínimo: cliente, nave, vigencia, renta, fecha de vencimiento y responsable. (2) Renovaciones con semáforo y avisos escalonados, que sustituyen el Excel que Legal revisa y semaforiza cada 15 días. Se reusa la corrida diaria y el cálculo de días restantes, pero con una escala nueva de meses: la actual es de 15/10/5 días y Legal trabaja con un año de anticipación. (3) Detección de contratos vencidos sin renovación firmada que siguen cobrándose; Legal confirmó que esos casos existen. (4) Expediente documental del cliente con la lista que Legal ya dictó (acta, poder, comprobante de domicilio, INE del representante, constancia de situación fiscal, constancia de cumplimiento, garantía y estados financieros auditados del obligado solidario), con vigencias, avisos de caducidad y permisos por registro. (5) Inventario de espacios con estatus comercial (disponible, apartado, en negociación, ocupado). El punto de partida son los 46 espacios del sitio público, con los metros convertidos a número. Esos 46 son solo disponibilidades, así que las naves ocupadas salen de la lista de contratos. También se exponen vistas de solo lectura para Power BI si ya se sabe de dónde leen hoy los tableros.
Condición · Arranca cuando Legal entrega el Excel de renovaciones con los contratos vigentes y confirma quién lee y quién modifica, y cuando Administración o Comercial entregan el portafolio completo, ocupadas incluidas, y nombran a un responsable de mantener el estatus comercial. Si ninguna área acepta ser dueña del inventario, TI no debe volverse dueña de ese dato. Es la fase que menos depende de definiciones pendientes.
Fase 2. Núcleo comercial y marketing mínimo
Duración. Del 5 al 30 de octubre (4 semanas), a cargo de una de las dos personas. Comercial contesta su levantamiento antes del 2 de octubre.
Prospecto con origen obligatorio de un catálogo cerrado. Cola de asignación del Director Comercial con registro de quién asignó y cuándo. Oportunidad con etapas, campos obligatorios por etapa y bitácora de cambio de etapa. Calificación que condiciona el avance. Motivo de pérdida. Registro de tours con asistentes. Padrón de brokers traído del portal del sitio público, con su clasificación. Campañas ligadas al prospecto y medición por canal; el registro de descargas de fichas ya existe en el sitio. Envío de fichas técnicas. Recomendación de espacios por filtro y puntuación con reglas escritas, sin IA. Reactivación de oportunidades perdidas cuando se libera un espacio compatible, dentro de la corrida diaria. Migración de los registros comerciales activos de Monday con el importador que ya existe, que tiene modo de simulación.
Condición · El reloj de esta fase arranca cuando Comercial responde las preguntas 1, 2, 3, 4, 5, 6 y 8 del discovery, que hoy están en blanco. Son unas dos sesiones de trabajo. No debe empezar a construirse con etapas supuestas.
Fase 3. Cotización, negociación, Comité y casos de Legal
Duración. Del 5 al 30 de octubre (4 semanas), en paralelo con la fase 2 y a cargo de la otra persona: primero la parte de Legal, que ya tiene su levantamiento respondido, y después cotización y Comité. Dirección define umbral del Comité, fórmula de renta y firma de la Hoja de Acuerdos antes del 16 de octubre.
Cotización con cálculo automático de renta. El nombre "Cotizacion" ya lo usa la Suite para otra cosa, así que este modelo va con otro nombre. Flujo de aprobación de condiciones especiales con el patrón que ya existe: la regla bloquea, se puede autorizar dando un motivo y el motivo queda asentado. Hoja de Acuerdos en PDF; se firma en papel salvo que dirección autorice la firma electrónica, que ya opera en la Suite con enlace con vigencia, trazo e IP. Comité de Autorización: se dispara por umbral, recibe el expediente en PDF, registra la votación en paralelo con motivos y escala por tiempo sin decisión. Caso legal con validación de expediente completo al abrirlo, asignación de abogado, plazos de 45, 60 y 90 días contados desde la entrega de la Hoja de Acuerdos y registro de versiones del contrato con huella del archivo. Esto obliga a un modelo nuevo de plazos, porque el acuerdo de servicio (SLA) actual de la Suite mide minutos desde que se crea el registro. Migración de los casos activos de Legal que viven en Monday.
Condición · Arranca con cuatro definiciones: la fórmula de renta, el umbral y los integrantes del Comité con su regla de votación y de empate, la decisión de dirección sobre la firma de la Hoja de Acuerdos, y si Legal cuenta días naturales o hábiles y cuándo se detiene el reloj. Sin umbral, el Comité se entrega con el umbral configurable y apagado.
Fase 4. Cuentas por Cobrar
Duración. Del 2 al 20 de noviembre (3 semanas). Cuentas por Cobrar contesta su levantamiento antes del 23 de octubre y la ruta a Oracle queda lista antes del 30 de octubre; si no, los pagos se capturan y la cartera con antigüedad queda apagada.
Aviso a Cuentas por Cobrar, Facturación y administradores de parque con los campos del contrato al cierre. Sustituye el ticket manual que hoy manda Legal, y ese ticket ya existe en la Suite. Registro de pagos a partir del espejo de ingresos de Oracle, que ya se sincroniza en modo solo lectura. Incidencias y ajustes con quién autoriza. Avisos de incrementos anuales (INPC) y fechas clave. Depósito en garantía. Cruce entre el cliente del CRM y el de Oracle, que llega como texto libre (1,655 nombres), con la normalización que ya se usa para proveedores. La cartera con antigüedad de saldos y priorización solo entra si Oracle entrega una vista con fecha de vencimiento y clave de cliente; si no, se entrega saldo por factura y por cliente, sin antigüedad.
Condición · Tiene dos condiciones. (1) Cuentas por Cobrar responde su discovery completo; hoy están en blanco las 15 preguntas. (2) El servidor alcanza a Oracle: hace falta una VPN sitio a sitio o una ruta de red, el cliente Oracle instalado en el contenedor o que el administrador de la base de datos (DBA) reasigne la contraseña, y una revisión de la estructura de la vista de ingresos. Hoy la integración está apagada en el servidor y la carga se hizo a mano desde la PC de TI. Si el acceso no llega, la fase se entrega con captura manual de pagos y la cartera queda pendiente.
Fase 5. Comisiones, tableros de área y Dirección General
Duración. Del 16 de noviembre al 4 de diciembre (3 semanas; el 16 es día de descanso). Esquemas de comisión e indicadores definidos antes del 6 de noviembre. Cierre del 7 al 18 de diciembre con operación acompañada y retiro de Monday.
Motor de comisiones que calcula y propone, y una persona autoriza con motivo asentado; no paga en automático. Tableros de Comercial, Marketing, Legal y Cuentas por Cobrar con los indicadores que cada área defina. Tablero ejecutivo con ocupación, embudo comercial, renovaciones y cartera. Alertas de riesgo con reglas escritas que dicen por qué se dispararon: días sin contacto, vencimientos concentrados por parque, mora, vacancia. Reportes para sesiones de consejo en PDF. Vista de las decisiones de Comité que requieren a dirección.
Condición · El tablero ejecutivo va al final porque sus cuatro indicadores no existen como dato hasta que existan el inventario, el embudo, el contrato y la cartera. Si dirección espera el tablero como primer entregable, hay que decírselo antes de arrancar. Las comisiones arrancan solo cuando los esquemas estén escritos y firmados por quien paga.
9 · Fuera de la versión 1
| Fuera de la versión 1 | Por qué |
|---|---|
| Inteligencia artificial generativa: copiloto de dirección, resumen diario, puntaje de prospectos con IA, enriquecimiento con noticias y LinkedIn | El anexo la describe en una sola frase ("análisis y priorización") y nadie ha definido qué debe hacer. Enriquecer con fuentes externas choca con la promesa de que la información no sale de la red de Parks. La Suite no tiene modelos de lenguaje; lo único que tiene es detección de rostro en el navegador para fotos de RRHH, y no sirve para esto. En la versión 1 TI entrega priorización con reglas escritas y auditables, que ataca el mismo problema operativo (qué atender primero) y que se puede explicar ante el consejo. |
| Asignación automática de prospectos "con IA" | El anexo pide una cola de asignación para el Director Comercial con registro de quién asignó y cuándo. La asignación la hace una persona. Automatizarla requiere reglas que Comercial no ha dado: la pregunta 4 del discovery está en blanco. |
| Aplicación móvil nativa | El propio anexo la excluye. La versión 1 es web y se usa desde el teléfono. Hoy solo 45 de las 93 pantallas de la aplicación principal se adaptan a móvil, así que las pantallas del CRM se diseñan para móvil desde el inicio, pero sin aplicación instalable. |
| Reconocimiento automático de documentos (OCR) de actas, poderes, INE y constancias | Sería procesar documentos de identidad y societarios con un servicio externo, lo que saca información de la red, o con uno instalado en el servidor, cuya calidad nadie ha probado. Un error de lectura en un poder o una garantía es un problema legal. En la versión 1 hay carga manual, checklist con vigencias y revisión del abogado, que es como opera Legal hoy. |
| Cotejo automático entre versiones del contrato como control | El control real hoy es humano: se verifica que la versión firmada sea la impresa y se pone el sello de jurídico. TI registra versiones con huella del archivo, quién la subió y cuándo, pero no vende una comparación automática como garantía de que se firma la versión correcta. |
| Escritura hacia Oracle EBS (integración "bidireccional") | La cuenta disponible es de solo lectura y la Suite solo ejecuta consultas, con dos candados que lo aseguran. La facturación y la contabilidad se quedan en Oracle; el anexo también lo dice. Escribir en el sistema contable es una decisión de gobierno de quien administra Oracle, no un tema técnico. |
| Integración bancaria y conciliación automática de pagos | La pregunta 14 del discovery de Cuentas por Cobrar sobre conciliación está sin responder, no hay ningún acceso bancario y la dispersión de pagos está excluida también en el anexo. Los pagos se leen de Oracle, que es donde ya se aplican. |
| Envío masivo de campañas de correo con plantillas, bajas, rebotes y métricas de apertura | No está en el anexo, solo en la presentación. Es un producto en sí mismo, que depende de la reputación del dominio, y el envío desde la infraestructura propia ya ha tenido problemas de autenticación. Si Marketing lo necesita, se contrata una herramienta de envío y el CRM le entrega la lista. |
| Firma electrónica del contrato de arrendamiento | Legal declaró que todo el circuito de firma es en papel por indicación de dirección general. La versión 1 registra el contrato firmado y su expediente. La firma electrónica solo se considera para la Hoja de Acuerdos y solo si dirección la autoriza. |
| Pago automático de comisiones | Nadie ha escrito los esquemas y el cálculo toca dinero que se paga a personas. El sistema calcula y propone, una persona autoriza con motivo asentado y el pago se hace fuera del sistema. |
| Integración con el Call Center | Ninguna fuente dice qué sistema es ni si tiene alguna forma de conectarse. Mientras no se sepa, los prospectos de ese canal se capturan como un origen más del catálogo. |
| Acceso de brokers dentro del CRM | Los brokers ya tienen cuenta, por cientos, en el portal del sitio público. Dejarlos entrar al embudo sin permisos por registro probados expone condiciones negociadas de otros clientes. Siguen en su portal y al CRM entra el prospecto que generan. |
| Integración con WhatsApp y editor de distribución sobre plano | WhatsApp aparece en el discovery y en la presentación, pero no en el anexo. El editor sobre plano, el propio anexo lo manda a la versión 2. |
10 · Lo que las áreas deben definir
Los levantamientos de Comercial (17 preguntas) y de Cuentas por Cobrar (15) están sin responder; solo Legal contestó, el 26 de mayo de 2026. Cada fase arranca cuando su área entrega lo que le toca.
| Qué hay que definir | Quién | Qué bloquea |
|---|---|---|
| Etapas exactas del ciclo de venta y qué campo es obligatorio en cada una (discovery Comercial, preguntas 1 y 6, sin respuesta) | Director Comercial | Fase 2 completa: sin etapas no hay embudo, calificación ni tablero comercial |
| Catálogo de canales de origen de prospectos (pregunta 2, sin respuesta) e identificación del sistema de Call Center | Director Comercial con Marketing | Fase 2: captación con origen obligatorio y medición por canal y campaña |
| Criterios de calificación de prospectos (pregunta 3, sin respuesta) | Director Comercial | Fase 2: calificación que condiciona el avance |
| Número de ejecutivos comerciales, sus niveles y cómo se reparten los prospectos (pregunta 4, sin respuesta) | Director Comercial | Fase 2: roles, cola de asignación y dimensionamiento de usuarios |
| Cómo se registran y clasifican los brokers, y si entran o no al sistema (pregunta 5, sin respuesta) | Director Comercial | Fase 2: registro y clasificación de brokers |
| Proceso para oportunidades que no cierran y catálogo de motivos de pérdida (pregunta 8, sin respuesta) | Director Comercial | Fase 2: motivo de pérdida y reactivación |
| Qué sistema lleva hoy el inventario, portafolio completo con naves ocupadas y quién mantiene el estatus comercial (preguntas 9 y 10, sin respuesta) | Director Comercial con Administración, que emite el Resumen de propiedades | Fase 1: inventario con estatus. Después, recomendación de espacios, reactivación e indicador de ocupación |
| Fórmula de la cotización de renta: variables, moneda, mantenimiento y escalación. No está en ninguna pregunta del discovery | Director Comercial con Finanzas | Fase 3: cotización con cálculo automático |
| Qué se considera una condición especial y quién la aprueba, en qué orden | Dirección General con Director Comercial | Fase 3: flujo de aprobación de condiciones especiales |
| Umbral que manda una operación al Comité, integrantes, regla de votación, qué pasa en empate y en cuántos días escala | Dirección General | Fase 3: Comité de Autorización. Sin umbral se entrega apagado |
| Si la Hoja de Acuerdos puede firmarse electrónicamente o sigue en papel | Dirección General, con opinión de Legal sobre su validez como prueba | Fase 3: firma de la Hoja de Acuerdos |
| Confirmar quiénes intervienen en la firma (la respuesta dice 4 personas pero enumera más cargos), cuántos abogados hay y quién lee y quién modifica | Director Legal | Fase 1: permisos por registro del expediente y del contrato |
| Escala de avisos de renovación (Legal dijo un año antes; se propone 12, 6, 3 y 1 meses) y entrega del Excel de renovaciones con los contratos vigentes | Director Legal | Fase 1: renovaciones con semáforo y carga inicial |
| Vigencia aceptada por tipo de documento del expediente del cliente | Director Legal | Fase 1: avisos de caducidad del expediente |
| Si los plazos de 45, 60 y 90 días son naturales o hábiles, cuándo se detiene el reloj y qué define un caso especial | Director Legal | Fase 3: control de plazos de los casos de Legal |
| Campos del contrato que Cuentas por Cobrar necesita para emitir la primera factura, y cómo se entera hoy del cierre (preguntas 1 y 9, sin respuesta) | Responsable de Cuentas por Cobrar | Fase 4, y parcialmente la fase 1: si se conocen antes, el contrato mínimo los incluye desde el principio |
| Proceso de cobranza paso a paso y criterios para priorizar la cartera (pregunta 5, sin respuesta) | Responsable de Cuentas por Cobrar | Fase 4: cartera con priorización |
| Cómo se factura hoy al inquilino que sigue ocupando con contrato vencido y quién lo instruye (pregunta 6, sin respuesta) | Responsable de Cuentas por Cobrar con Legal | Fase 4: seguimiento de esos casos. La detección de vencidos sin renovar entra en la fase 1 |
| Incrementos anuales: de dónde sale el factor (INPC u otro), quién autoriza y qué pasa con los que se negocian caso por caso (pregunta 7, sin respuesta) | Responsable de Cuentas por Cobrar con Finanzas | Fase 4: avisos de incrementos y fechas clave |
| Ciclo del depósito en garantía, notas de crédito y ajustes, y quién los autoriza (preguntas 8 y 11, sin respuesta) | Responsable de Cuentas por Cobrar con Dirección de Finanzas | Fase 4: incidencias y ajustes |
| Número de contratos activos y de personas que los gestionan (pregunta 12, sin respuesta) | Responsable de Cuentas por Cobrar | Fase 1 (tamaño de la carga inicial) y fase 4 |
| Ruta de red del servidor de la Suite a Oracle, cliente Oracle o contraseña reasignada, estructura completa de la vista de ingresos y, si no trae vencimiento ni clave de cliente, una vista nueva | Administrador de Oracle y responsable de la red | Fase 4: registro de pagos automático y cartera con antigüedad de saldos |
| Exportación de los tableros de Monday con el conteo de registros activos y su antigüedad | Dueños de los tableros en Comercial y en Legal, con TI | Tamaño de la migración en las fases 2 y 3 |
| Indicadores de cada tablero de área, qué reportes pide hoy dirección (preguntas 12 y 13 de Comercial y 13 de Cuentas por Cobrar, sin respuesta) y cuáles son las "métricas homologadas con el grupo" | Dirección General con cada director de área | Fase 5: tableros de área y tablero ejecutivo |
| Los esquemas de comisión, sus porcentajes y si los ejecutivos internos también comisionan (pregunta 16, sin respuesta) | Dirección General con Director Comercial y Finanzas | Fase 5: motor de comisiones |
| De qué fuente leen hoy los tableros de Power BI y quién los mantiene | Dueño de los tableros de Power BI; la documentación no dice quién es | Vistas para Power BI (fase 1 o fase 5) |
| Decidir la capacidad del proyecto: contratar un desarrollador o liberar a Raúl de parte de la operación, y nombrar un patrocinador y un punto de contacto por área | Dirección General | Fase 0 y, con ella, todo el proyecto |
11 · Riesgos
| Riesgo | Impacto | Cómo se contiene |
|---|---|---|
| El proyecto depende de una sola persona: 332 de 346 commits de la Suite son del mismo autor. | Una enfermedad, una renuncia o una saturación detienen el CRM y dejan sin mantenimiento a mesa de ayuda, personal, compras, inventarios y finanzas al mismo tiempo. | Sumar una segunda persona con Claude Code desde la fase 0, revisar el código entre los dos y documentar cada módulo al cerrarlo. Si no hay contratación, la fecha de diciembre no se sostiene: con Raúl solo la construcción es de 19 a 27 semanas y aceptar el riesgo por escrito. |
| El CRM le quita tiempo a lo que ya funciona. | La misma persona sostiene hoy 20 módulos, 4 aplicaciones, el servidor y el sitio público. O se atrasa el CRM o baja la atención a la operación actual. | Que dirección defina qué deja de hacer TI mientras dura el proyecto y congele los módulos nuevos de la Suite fuera del CRM. |
| No hay pruebas automatizadas en ningún archivo del repositorio y el backend no tiene comando de pruebas. | El CRM calcula rentas, comisiones, incrementos y plazos legales. Un cambio puede romper un cálculo sin que nadie se entere hasta que llega mal a un cliente o a un pago. | Exigir pruebas automatizadas en todo cálculo de dinero y de plazos desde la fase 0, y que ninguna fase se entregue sin ellas. |
| Alertas que existen pero no corren. Ya pasó en la Suite: cuatro de cinco avisos diarios nunca salieron porque la línea que los programaba estaba dentro de un comentario, y ningún error lo mostró. Además, el envío de correo ignora sus fallas a propósito para no tumbar otras operaciones. | Una renovación o un incremento se vencen porque el aviso no salió, justo lo que el CRM debe evitar. | Bitácora de cada corrida, un indicador visible de correos no enviados y una revisión semanal de que las corridas ocurrieron. Todo desde la fase 0. |
| Tomar como reusable algo que no lo es. Varios modelos suenan a CRM y no lo son: RenovacionContrato es la renovación laboral de un empleado, Cotizacion es de proveedores de mantenimiento y Attachment exige un ticket. Además, el flujo de firmas por puesto deja que cualquier administrador firme cualquier paso. | Plazos calculados sobre un reuso falso que no se cumplen, o un flujo de aprobación donde TI podría autorizar en nombre del director general. | Reusar mecanismos, no modelos. Crear modelos propios del CRM y quitar la firma universal del administrador en todo flujo de aprobación comercial o legal. |
| Dos sistemas de permisos conviven en la Suite (el control por roles nuevo en siete archivos de rutas y el esquema anterior de tres roles con banderas), y ninguno filtra por registro. | Un expediente de contrato o una condición negociada queda visible a quien no debe verla. | Que el CRM use solo el control por roles nuevo, más permisos por registro construidos en la fase 0 y probados con los perfiles que Legal definió, antes de cargar el primer expediente. |
| Todo corre en el mismo proceso y el mismo servidor. Producción, pruebas (QA) y desarrollo están en 10.253.50.113, y el backend es un solo proceso de Node que también genera los PDF. | Una falla o una carga pesada del CRM, como generar expedientes o reportes de consejo, puede afectar nómina, compras y mesa de ayuda. | Decidir en la fase 0 si el CRM corre en un proceso aparte. Paginar todas las listas y medir la carga antes de abrir el sistema a todas las áreas. |
| El límite de peticiones (600 por minuto) y el bloqueo por intentos fallidos (5 en 15 minutos) se calculan por dirección de red. | Si los usuarios salen a internet por una misma dirección, se bloquean entre sí en horas de mucho uso. Ya pasó una vez detrás del túnel. | Calcular ambos límites por usuario en la fase 0, antes de sumar usuarios del CRM. |
| Los respaldos no tienen una restauración probada. Se configuran en el servidor y el repositorio no muestra evidencia de ninguna restauración. | Si se pierden expedientes contractuales, es posible que no se puedan recuperar. | Hacer una restauración completa en el ambiente de pruebas durante la fase 0 y repetirla cada trimestre. |
| El acceso no tiene segundo factor. Hoy se entra con contraseña local o con el directorio corporativo, y no hay inicio de sesión con Microsoft 365. | Una contraseña robada abre expedientes de clientes y condiciones comerciales. | Segundo factor por aplicación autenticadora en la fase 0, que no depende del administrador de Microsoft 365. El inicio de sesión con Microsoft 365 queda como mejora posterior. |
| La mitad del esquema de la Suite guarda fechas como texto y mezcla Float con Decimal para dinero. | Si el CRM hereda esa costumbre, vencimientos, incrementos anuales y plazos se calculan mal. | Reglas de datos fijadas en la fase 0: fechas como fecha, dinero en Decimal, fecha de modificación en cada modelo, y revisión de cada modelo nuevo contra esas reglas. |
| Nadie usa el sistema. TI no tiene capacitación ni gestión del cambio, y Legal y Cuentas por Cobrar hoy trabajan en correo, Excel y papel. | Un sistema correcto sin datos no resuelve nada, y el tablero ejecutivo muestra ceros. | Entregar cada fase con una o dos semanas de operación acompañada dentro del área, un punto de contacto por área y una fecha fijada por dirección para dejar de usar el Excel y Monday. |
| El error lo absorbe Parks. En el desarrollo interno no hay póliza ni un tercero a quien reclamar si se calcula mal una comisión o se filtra un expediente. | El costo de un error de cálculo o de una fuga de información queda completo en la empresa. | Autorización humana en todo cálculo que termina en dinero, bitácora de auditoría y permisos por registro antes de operar. Evaluar con Finanzas si conviene contratar una póliza propia de responsabilidad tecnológica. |
12 · Lo que aún falta resolver
Una revisión crítica independiente buscó lo que este análisis no contesta. Son temas a resolver antes o durante la fase 0.
| Lo que aún falta resolver | Por qué importa |
|---|---|
| Una estimación de esfuerzo y un calendario del plan interno. El análisis clasifica 44 capacidades en A/B/C/D, pero no dice cuántas semanas-persona lleva cada entregable ni en qué fecha estaría el primero. Los tamaños se expresan con adjetivos: 'chico', 'reuso casi literal', 'una sesión, no un proyecto', 'trabajo de un día', 'ajuste de una línea'. La cifra de 'unos 30 modelos nuevos' no dice de dónde sale. | Es lo primero que va a preguntar un director sobre un plan interno ya decidido: cuándo tiene cada cosa y con cuánta gente. Una clasificación A/B/C sin horas no se puede comprometer ni seguir. La categoría B va de 'un modelo y una llave' hasta el contrato de arrendamiento completo. |
| Qué pasa con la Suite en operación mientras se construye el CRM. Falta decir qué pendientes se congelan: el rumbo a ERP pedido por la organización, la fase 2 del portal único y RBAC, el túnel y el buzón de tickets externos, los checadores de otros parques, la auditoría transversal, el staging, la página web y el Broker Day. También falta quién atiende el soporte de TI y cuántas horas a la semana consume hoy. | El análisis menciona el costo de oportunidad como riesgo abstracto, pero no lo cuantifica ni propone qué se deja de hacer. Sin eso, el CRM se suma a la carga de una sola persona y el calendario no es real. La documentación no dice si TI tiene más personal que el coordinador. |
| El riesgo técnico concreto para los módulos en uso. Hay un solo esquema Prisma y un solo proceso de backend. Cada despliegue es 'docker restart suite-backend', lo que deja fuera a todos los módulos. El 20-ago-2026 producción se cayó porque un módulo nuevo no pudo crearse al desplegar. Las migraciones se aplicaron a mano y estuvieron desincronizadas hasta el 03-sep-2026. | Cada entrega del CRM toca la misma base y el mismo proceso que nómina, compras, personal y mesa de ayuda, y no hay pruebas automatizadas. El riesgo de 'concentración de fallas' que menciona el análisis ya tiene precedentes documentados que no se citan. Hace falta una política de despliegue, ventanas de cambio y reversa antes de empezar. |
| El estado real de 'producción' de la Suite. Según la memoria del proyecto, el 27-ago-2026 la base de producción se movió a desarrollo y producción quedó vacía: solo migraciones, roles y la cuenta de administrador. Los datos reales eran 25 empleados, 90 tickets y 333 mil filas de Oracle, y viven en desarrollo. Todo el análisis se apoya en 'ya opera en producción' para dar credibilidad al reuso. | 'En producción' parece significar 'código desplegado', no 'mecanismo usado por las áreas con volumen real'. Firma por enlace, expediente con vigencias, avisos diarios y flujos de aprobación tienen un uso real muy limitado o no verificado. Eso cambia cuánto se puede confiar en el reuso. |
| La consecuencia explícita del cuestionario de Comercial sin responder (17 preguntas, todas en blanco): qué no se puede construir. P1 y P6 (etapas y campos obligatorios) bloquean el pipeline. P2 (canales) bloquea el origen obligatorio. P3 bloquea la calificación. P4 bloquea la asignación y el número de usuarios. P5 y P16 bloquean brokers y comisiones, incluido si los ejecutivos internos también comisionan. P7 (duración del ciclo) define la cadencia de alertas. P8 bloquea las oportunidades perdidas y la reactivación. P9 y P10 (qué sistema lleva el inventario y cómo se sabe qué está disponible, en negociación u ocupado) bloquean el inventario con estatus. P12 a P14 bloquean reportes, KPIs y metas. P15 decide si WhatsApp es canal. P17 (broker que representa al inquilino, varios decisores) define el modelo de contactos. | El análisis dice que los entregables mínimos 1 y 3 'no dependen de ningún parámetro pendiente'. No es cierto. El inventario con estatus depende de P9 y P10; los estados 'disponible, apartado, en negociación, ocupado' los propone TI, no Comercial. El pipeline depende de P1, P6 y P17. Solo el entregable 4 (lista de documentos, dictada por Legal en P3) tiene una definición real. |
| La consecuencia explícita del cuestionario de Cuentas por Cobrar sin responder (15 preguntas en blanco). P9 (datos obligatorios del contrato para la primera factura) define los campos mínimos del contrato. P4 dice si Oracle registra el pago o alguien lo captura. P5 es el proceso de cobranza. P6 es el holdover. P7 son las escalaciones INPC. P8 es el depósito en garantía. P10 son los modificatorios. P11 son las notas de crédito y quién las autoriza. P12 es el volumen de contratos y de personas. P14 es la conciliación bancaria. P15 es el dolor principal. | El entregable 2 (contrato y renovaciones) se propone con cinco campos: cliente, nave, vigencia, renta y responsable. Sin P7, P8, P9 y P10, el objeto contrato se diseñaría dos veces. Toda la fase de CxC y el indicador de cartera de Dirección no se pueden diseñar. Los datos de holdover 'al doble de renta' y de INPC retroactivo son afirmaciones del proveedor, no de CxC. |
| Las áreas y actores sin levantamiento. No hay cuestionario de Marketing, Comité ni Dirección General. Tampoco se considera a Facturación ni a los administradores de parque, que reciben el ticket de inicio según Legal P8. Falta Tesorería o Cuentas por Pagar, que paga las comisiones que calcula el CRM. Falta el área que construye naves a la medida (Legal P5, caso MELI; Comercial P9, build-to-suit y terrenos). Falta quien ejecuta los 'cortes de servicios al cliente para ejecutar cobranza' (Legal P10). Y faltan los auditores (Legal P10 menciona que el holdover 'aparece en auditoría'). | Son usuarios, fuentes de datos o destinatarios de flujos que el alcance da por hechos. El análisis los cuenta como 'áreas incluidas' sin haber hablado con ellas. La composición del Comité y quién vota no está en ninguna fuente. |
| La relación con el grupo. Legal P4 dice que el contrato 'se integra dentro del proceso FUNO y NEXT (esto a nivel proceso se considera tercero)'. La agenda de la presentación (pres02) tiene una sección '02 Continuidad con el grupo · Exportes idénticos · Salesforce corporativo'. Ninguno de los análisis trata esto como condición del plan interno. | Si el grupo usa Salesforce corporativo o exige exportes con un formato idéntico, el CRM interno tiene que producirlos, o la decisión de construir en casa choca con una norma del grupo. Hay que resolverlo antes de diseñar el primer modelo. Qué son FUNO y NEXT y qué exigen no está en la documentación. |
| La carga inicial de contratos y expedientes. Legal P6 dice que los contratos firmados viven 'físicamente en corporativo'. El control de renovaciones es un Excel. El número de contratos activos es desconocido (CxC P12 sin responder). Oracle trae 1,655 nombres de cliente como texto libre. El análisis no dice quién captura o digitaliza el portafolio activo, cuánto tarda ni cómo se valida. | El entregable 2 'sustituye el Excel' solo si alguien carga todos los contratos vigentes con fechas correctas. El expediente documental del entregable 4 requiere escanear archivos físicos. Es trabajo de operación, no de programación, y no tiene dueño ni tiempo asignado. |
| Un modelo de contrato completo. Legal P1 enumera cuatro tipos de documento: arrendamiento, renovación, convenio de terminación anticipada y modificatorio. A eso se suman la nave construida a la medida (Legal P5), el cliente con varias naves o fracciones (mínimo divisible), el depósito, la garantía y el obligado solidario (Legal P3), la moneda, el arrendador y la cancelación. La vista de ingresos de Oracle trae moneda y tipo de cambio. En qué moneda se pactan las rentas y qué razón social arrienda no está en la documentación. | Un contrato de cinco campos no soporta modificatorios ni terminaciones, y Legal ya mide 'KPI puntuales de cancelaciones' (P7). Rehacer el modelo después de cargar el portafolio es el retrabajo más caro del proyecto. |
| El inventario real de canales de captación. El análisis menciona el formulario del sitio y el alta de brokers. Deja fuera el chat de Cliengo ('Navi') en el sitio, los clics a WhatsApp y teléfono, el boletín, el formulario del Broker Day que escribe en una hoja de Google y el Call Center, que no está identificado. Tampoco considera que el sitio vive en un VPS externo y la Suite en la LAN, así que llevar los prospectos del sitio al CRM es una integración entre redes. | El alcance pide 'todos los canales que Parks usa hoy' con origen obligatorio. Si un canal queda fuera, el reporte por canal nace incompleto. Cliengo guarda sus propios prospectos en una plataforma de terceros. |
| La protección de datos personales. El CRM guardaría INE, actas, poderes, constancias fiscales, estados financieros auditados de obligados solidarios y datos de prospectos. No hay análisis de aviso de privacidad, finalidades, plazos de conservación, derechos de acceso y cancelación, ni de quién es el responsable del tratamiento. La memoria del sitio registra que su aviso de privacidad ni siquiera menciona cookies. | Es una obligación legal (Ley Federal de Protección de Datos Personales en Posesión de los Particulares) y un riesgo reputacional. En el camino interno no hay póliza que lo cubra. No aparece en ninguna fuente del caso. |
| La postura de seguridad heredada. Según la memoria, la Suite completa, con su pantalla de acceso, está expuesta a internet por túnel de Cloudflare en suite.webtestenv.site, sin Cloudflare Access y sin segundo factor. Los respaldos diarios existen desde el 01-sep-2026, pero se copian al VPS externo 74.208.125.151. La restauración solo se comprobó con 'pg_restore --list', no restaurando. | El análisis clasifica 'infraestructura propia, la información no sale de la red' como A ('ya opera así'), pero la copia fuera del servidor y la exposición pública contradicen esa promesa para datos contractuales. También dice que los respaldos 'no son verificables desde el repositorio', cuando la memoria sí los documenta. |
| La propiedad y la continuidad de los activos técnicos. El código vive en GitHub privado en la cuenta 'Rullsgb'. El acceso al servidor usa llaves personales (id_ed25519_erp) con el usuario rgarcia, sin sudo. Los autores 'Rullsgb' y 'adminprk' del historial muy probablemente son la misma persona, y 'CodexSandboxOffline' es una herramienta de IA. Eso deja la dependencia en 341 o más de 346 commits, no en 332. | Si la cuenta de GitHub es personal y no de la empresa, la continuidad del CRM y de la Suite depende de credenciales individuales. El análisis trata la dependencia de una persona como riesgo, pero no propone mitigación: cuenta institucional, custodia de llaves, documentación, un segundo desarrollador. Si la cuenta es personal o corporativa no está en la documentación. |
| El costo del camino interno. No hay ninguna cifra: tiempo del coordinador, contratación de una segunda persona, servicio de envío masivo de correo (que el propio análisis clasifica D y manda a contratar), reconocimiento de documentos y IA, segundo factor, almacenamiento de PDFs, y asistentes de programación. El historial tiene commits de 'CodexSandboxOffline' y el manual técnico tiene un apéndice sobre contratar Claude Team. | Dirección necesita un presupuesto aunque la decisión esté tomada. Si la velocidad de entrega de la Suite depende de asistentes de programación de pago, eso es a la vez un costo y una dependencia que el análisis no revela. |
| La transición y el retiro de Monday y del Excel: cuánto tiempo operan en paralelo, fecha de apagado, costo de las licencias de Monday mientras tanto, y qué pasa con el historial que no es 'registro activo' (el alcance solo migra activos). | Sin fecha de apagado, las áreas siguen en Monday y el CRM queda como sistema secundario. El histórico de cancelaciones y tiempos de firma que Legal usa para sus KPIs podría perderse. |
| La línea base y los criterios de éxito: cuánto tardan hoy las renovaciones contra el estándar de 45, 60 y 90 días, cuántos contratos están vencidos sin renovar, cuántos prospectos entran al mes. Tampoco hay criterios de aceptación por entregable ni quién los valida en cada área. | Sin línea base no se puede demostrar que el CRM interno resolvió algo, y la dirección no tiene con qué evaluar a TI. Legal P7 dice que 'estos convenios llegan vencidos': el problema es el retraso de Comercial. Un semáforo no lo corrige si no hay una regla que obligue a Comercial y alguien que escale. |
| El gobierno del proyecto: patrocinador con autoridad sobre Comercial, Legal y CxC; dueño funcional por área; fecha límite para responder los cuestionarios; y qué pasa si un área no entrega sus parámetros. En el camino interno no hay una cláusula como la sección 09 del proveedor que ajuste el calendario. | Dos de tres cuestionarios siguen en blanco desde mayo. Si nadie con autoridad obliga a responderlos, el CRM interno se detiene en el mismo punto, y TI no tiene mandato sobre esas áreas. |
| El número real de usuarios del CRM y la capacidad del servidor. El análisis afirma que las cuentas de la Suite 'probablemente ya superan 80', pero la memoria registra 25 empleados cargados y 66 personas en el checador biométrico. Tampoco hay medición de CPU, memoria y disco del servidor PRK-MX-LANDING, que comparte el equipo con contenedores ajenos (iv_*, n8n) y con los tres ambientes. | La cifra de 80 no se sostiene con los datos disponibles. Sin conocer la holgura del servidor no se puede decir que aguanta el CRM, sus PDFs y sus usuarios externos. |
| Un plan de pruebas y de adopción: casos de prueba escritos con cada área para renta, comisiones y plazos; quién prueba; capacitación y manual de usuario. El análisis registra 'cero pruebas' y 'adopción' como riesgos, sin ninguna acción. | El sistema calculará dinero y plazos legales. Sin casos acordados con el área dueña del cálculo, no hay forma de aceptar una entrega ni de detectar una regresión en los módulos existentes. |
Anexo · Las 19 etapas del flujo
Transcritas de la presentación del proveedor. Los dolores son los que ahí se declaran; ninguna área de Parks los ha confirmado en un levantamiento respondido, salvo los de Legal.
| # | Etapa | Dolor declarado | Lo que se pide a la plataforma |
|---|---|---|---|
| 01 | Captación de leads | Sin métricas de apertura, clics ni conversión; Fichas técnicas se adjuntan manualmente en cada solicitud; No existe una Base de Datos Consolidada | Integración con brokers, portales, web de Parks y automatización anti-duplicados; IA: Enriquecimiento automático con IA; Generación automática de fichas — con tracking de apertura |
| 02 | Asignación de lead | Asignación 100% manual por el CEM — cuello de botella; Sin criterios de nivel del LO ni carga activa | IA: Motor de asignación con IA: rank de cuenta + nivel del LO (Sr/Mid/Jr); Considera carga activa, historial de cierre y especialidad |
| 03 | Calificación del lead | Se toman todos los leads sin criterios formales; Sin lead scoring — 22 leads por LO con igual prioridad | IA: Score con IA desde el día 1 — análisis de la empresa validado con noticias y LinkedIn; IA: Detección de señales de expansión y necesidad |
| 04 | Espacios y tour | 3 tipos de m² sin diferenciar entre sí; El LO toma notas del tour fuera del CRM y las captura después | IA: Motor de recomendación con IA: sugiere naves óptimas por perfil; App móvil en el tour — el LO nutre el lead en campo, sin notas externas; Inventario sincronizado con Oracle vía API |
| 05 | Seguimiento activo | 22 leads por LO sin priorización; Seguimiento disperso — WhatsApp, correo, Monday sin integrar; Prospectos pospuestos abandonados en Excels individuales | IA: Alertas con next best action — la IA sugiere qué hacer; IA: Nurture automático por correo según etapa; App móvil — seguimiento y actualización de etapa desde cualquier lugar; Reactivación automática de pospuestos a 6 meses |
| 06 | Cotización y LOI | Propuestas manuales sin plantillas estandarizadas; Condiciones especiales acordadas verbalmente | IA: Sugerencia IA de precio y condiciones por perfil del cliente; Propuesta y LOI generadas automáticamente |
| 07 | Aprobación y comisiones | 3 esquemas de comisión calculados a mano; Sin metas individuales por LO | IA: Detección de expansión de inquilinos con IA; IA: Alerta de concentración de vencimientos por parque; Motor de comisiones automático — 3 esquemas |
| 08 | Campañas de email | Sin métricas de apertura, clics ni conversión | Campañas masivas de Email Mkt con plantillas predefinidas |
| 09 | Brochures y fichas | Fichas técnicas se adjuntan manualmente en cada solicitud | Generación de brochures y fichas de las propiedades |
| 10 | Disparo del comité | Comité de autorización sin flujo claro | Reglas de disparo por m² cotizados, monto total del contrato o nivel de cliente; Apertura automática del comité al firmar Hoja de Acuerdos (CEM + cliente) |
| 11 | Votación y resolución | La trazabilidad de las autorizaciones se vuelve compleja | Comité con voto Aprueba / Rechaza; Una vez aprobado se crea el caso Legal; si fue rechazado regresa al LO con razones para ajustar; Bitácora inmutable de votos, comentarios y resolución — auditoría lista para consejo; Bandeja de escalamiento CEO con contexto completo del deal y del voto |
| 12 | Documentación y asignación | Catalina es el único punto de carga; Asignación de abogado manual desde Monday; Validación de documentos hoja por hoja | IA: Extracción y validación con OCR + IA: actas, poderes, INE, CSF; IA: Asignación inteligente de abogados por carga y especialidad; Checklist automático por tipo de contrato |
| 13 | Borrador y versiones | Sin generación automática de borrador; Cotejo de versiones manual — riesgo de firmar versión incorrecta; SLAs sin alertas automáticas | IA: Cotejo inteligente con IA: detecta cambios entre versiones; IA: Alertas de renovación a 12/6/3/1 mes del vencimiento; Borradores con datos precargados |
| 14 | Firmas y cierre | Todo en físico por directiva del CEO; Ticket de cierre a CxC no incluye datos del cliente; Notificación manual a múltiples áreas | Almacenamiento con capa de seguridad y auditoría; Notificaciones automáticas por etapa; Al cerrar — aviso simultáneo a CxC, Facturación y Tenant |
| 15 | Activación y facturación | Ticket de Legal sin correo ni teléfono del cliente; Sin aviso automático a CxC del inicio del ciclo; CxC no ve si el cliente requiere OC o portal de pago | Pipeline Legal → Activación → Facturación → Cobranza → Pagado; Notificación inmediata al cerrar en Legal — caso CxC creado con expediente completo; Expediente del cliente: ficha, Hoja de Acuerdos, contrato, calendario de rentas y reglas de pago (OC / portal) |
| 16 | Cobranza mensual | "Todo lo manejamos por correo" — Claudia, textual; 200 contratos por ejecutivo sin priorización de riesgo; Sin SLAs ni KPIs definidos en CxC | IA · Score de riesgo de pago con IA; Flujo OC → factura → carga a portal del cliente, con recordatorios y confirmación de recepción; Calendario de pagos visible por contrato — prorrateos, depósitos e incentivos incluidos |
| 17 | Incidencias y ajustes | INPC olvidado y aplicado retroactivo; Actas de Restitución tardías — falsos adeudos; Condiciones especiales que CxC desconoce | IA · Detección con IA de riesgos de facturación antes de que ocurran; Alertas automáticas de INPC antes de la escalación; Condiciones especiales visibles para CxC desde el día 1 |
| 18 | Dashboard de CEO | KPIs críticos viven en Power BI, Excels y correos — sin una sola vista ejecutiva; Sin ocupación, absorción, MRR y cobranza juntos en tiempo real; Vista de consejo improvisada: sin tendencias históricas ni benchmarks de grupo | Panel ejecutivo unificado — Comercial + Legal + CxC en una sola pantalla; Dashboard diario — ocupación, absorción, MRR, pipeline, cobranza y ciclo legal / SLA en vivo; Vista de consejo — tendencias 12 meses, comparativos por parque/región y lectura de board; Bandeja de decisiones DG — pendientes de firma/aprobación enlazados desde el mismo panel |
| 19 | Decisiones inteligentes | Decisiones sin cruce entre Comercial, Legal y CxC — cada área reporta aislada; Señal de riesgo llega tarde: vencimientos, mora y vacancia no se leen juntos; No hay briefing ejecutivo: el CEO arma la narrativa a mano para consejo | [IA] Copiloto IA cross-área — cruza pipeline, ocupación, cobranza, vencimientos y SLAs legales; [IA] Briefing de decisiones diario — qué mirar, por qué importa y qué acción tomar; [IA] Alertas de riesgo y oportunidad — renovaciones 12/6/3/1, mora/anomalías CxC, holdovers, SLA legal, concentración de vencimientos; Narrativa lista para consejo — pulso comercial + cash + legal, sin armar el story en Excel |
Documento elaborado sobre el repositorio de la Suite, el sitio público de Parks Industrial y la documentación del proveedor (alcance V1, presentación y levantamientos). Diseño en papel: no se modificó código ni base de datos. Parks Industrial · Coordinación de TI.