La respuesta corta
No empiece modelando. Empiece clasificando cada requisito en uno de seis veredictos: ya activo en el espacio · una funcionalidad incluida pero desactivada · alcanzable mediante configuración · un desarrollo real · un límite rígido de la plataforma que hay que replantear · o, directamente, no es un problema de producto. Solo el cuarto es un ejercicio de modelado de datos.
Cuando sí es un desarrollo, hay que elegir entre una entidad personalizada (con su propio endpoint de API, formularios, numeración por secuencia y funcionalidades de registro), campos adicionales en una entidad estándar existente o un registro hijo relacionado. La prueba es si la cosa tiene su propio ciclo de vida y se lista de forma independiente.
El problema de negocio
Una organización llega con una lista. Se había entrevistado por separado a seis departamentos, y entre todos produjeron unas 44 solicitudes distintas de cosas que debería hacer el CRM: hacer seguimiento de inspecciones in situ, asociar permisos a activos, registrar a quién se invitó a un evento frente a quién asistió realmente, mostrar sugerencias a los gestores de cuentas, organizar cuestionarios de incorporación, elaborar informes por región.
Cada solicitud llegó formulada como una solución y no como un problema («necesitamos un mosaico en el panel», «necesitamos un módulo nuevo para permisos»), porque así es como la gente describe lo que quiere. Y el instinto a ambos lados de la mesa es tomar la lista al pie de la letra y empezar a diseñar objetos para ella.
Ese instinto resulta caro de una forma concreta. Convierte un ejercicio de análisis en un presupuesto de desarrollo, y lo hace antes de que nadie haya establecido cuáles de las 44 cosas ya hace la plataforma.
Por qué falla el enfoque obvio
Una gran parte de las solicitudes no son desarrollos
De unas 44 solicitudes, 11 correspondían a funcionalidades que estaban presentes y con licencia en el propio espacio del cliente, simplemente desactivadas. Nueve de ellas correspondían directamente a algo recogido en las notas de las reuniones. Sin desarrollo, sin esquema, sin modelado: una sesión de administración.
Presupuestar desarrollo para un interruptor es peor que un esfuerzo desperdiciado. Consume presupuesto que debería haber ido a las carencias reales, y cuando el cliente descubre más tarde que la funcionalidad estaba ahí desde el principio, cuesta una credibilidad difícil de recuperar.
Un espacio de Coevera lo expone directamente. En el espacio examinado, la colección
application contenía aproximadamente 107 registros de funcionalidades e integraciones, cada uno
con un indicador de activación. Es el panel de funcionalidades de cada espacio, y leerlo
lleva minutos.
Las capacidades de IA son filas que se activan una a una y suelen estar desactivadas, mientras que otro conjunto distinto a menudo ya está activo y nadie lo ha mostrado. En el proyecto de referencia, once aplicaciones relacionadas con la IA estaban desactivadas, mientras que otras dieciséis funcionalidades (entre ellas varias integraciones y los agentes de automatización y de informes) ya estaban activas y nunca se habían mostrado al cliente.
Los grupos de solicitudes suelen compartir una única carencia de fondo
Por separado, tres de las 44 solicitudes parecían tres desarrollos distintos: un informe de los invitados a eventos, un informe de las personas con las que realmente hubo reunión y una sugerencia basada en la asistencia. Las tres fallaban por la misma relación ausente: la entidad de evento no tenía ningún vínculo directo con los contactos. El único camino existente pasaba por un registro de gastos, lo que significaba que solo se podía saber quién había asistido si alguien había registrado un gasto por esa persona.
Una relación, construida una sola vez, convirtió tres solicitudes en datos sobre los que se podían hacer informes. Estimarlas por separado habría triplicado el presupuesto y aun así habría producido tres respuestas parciales.
Algunas cosas no pueden construirse a ningún precio
Unas pocas solicitudes apuntaban a objetos de la plataforma con una forma fija: un punto de extensión que simplemente no existe. Prometerlas es el peor resultado posible, porque el fallo aparece en la entrega y no al definir el alcance.
El marco de decisión
Cada requisito recibe exactamente un veredicto antes de que nadie estime nada. El veredicto determina quién se hace cargo de él, y eso es lo que lo hace útil y no meramente académico.
| Veredicto | Significado | Responsable |
|---|---|---|
| Activo | Activo hoy en el espacio. La carencia es de conocimiento, no de capacidad. | Habilitación / formación |
| Interruptor | Viene con el producto; la aplicación está inactiva en este espacio. | Administrador |
| Configuración | Alcanzable con automatización, campos personalizados, informes o listas de comprobación por paso. | Arquitecto de soluciones / administrador |
| Desarrollo | Esquema, relación o integración completamente nuevos. | Arquitecto + ingeniería |
| Límite | Frontera rígida de la plataforma. Replantear sobre algo que existe. | Producto |
| Ajeno al producto | Política, cuestiones comerciales o herramientas internas disfrazadas de CRM. | Equipo de cuenta |
Cuando el veredicto es Desarrollo, ¿adónde va?
Cuatro destinos, en orden creciente de coste:
| Destino | Cuándo usarlo | Coste |
|---|---|---|
| Un campo en una entidad existente | Los datos describen ese registro y no tienen existencia independiente: un nivel, un territorio, un indicador. | El más barato. Pero cada campo es otra fila en un formulario que ven todos los usuarios. |
| Un subtipo de una entidad existente | Se necesitan el mismo ciclo de vida y la misma cola, pero un conjunto de campos distinto para cada variante. | Bajo. Se trata a fondo en el Blueprint 001. |
| Un registro hijo relacionado | Hay muchos por registro principal: líneas de pedido, visitas de inspección, lecturas. | Moderado. Un lookup al registro principal y una cuadrícula en línea en el formulario del registro principal. |
| Una entidad personalizada nueva | Tiene su propio ciclo de vida, necesita su propia numeración de referencia y se lista y se analiza en informes de forma independiente. | El más alto. Sus propios formularios, sus propios permisos y una entrada en el menú de creación. |
Fuente. Centro de ayuda de Coevera, Advanced admin — working with custom entities, sobre lo que implica realmente configurar el más caro de los cuatro destinos.
La pregunta decisiva es breve: ¿esta cosa se lista, se filtra y se analiza en informes de forma independiente, y tiene vida propia? Una inspección sí: tiene una fecha, un inspector, un resultado, y querrá una lista de las que están vencidas. El nivel de un distribuidor no; es un atributo de una cuenta.
Lo que una entidad personalizada le da realmente, y por tanto lo que está pagando: su propio endpoint REST, sus propios formularios editables por subtipo, una numeración de referencia basada en secuencias y funcionalidades de registro opcionales (actividades, documentos, notas y búsqueda global). Si no necesita nada de eso, probablemente no necesite la entidad.
Mecánica de configuración
Cómo leer el panel de funcionalidades
Exporte los registros de funcionalidades del espacio y sepárelos por estado de activación antes de definir el alcance de nada. Después, asigne cada solicitud del cliente a una fila, y considere algo un desarrollo solo cuando ninguna fila lo cubra.
Corrobore un interruptor con el uso
Que un interruptor esté desactivado es, por sí solo, un hallazgo débil. Combinado con pruebas de que no se usa, se vuelve sólido: en el caso de los campos de IA, revise todas las colecciones de descriptores de campo en busca de un bloque de opciones de IA no nulo. Cero campos configurados más la aplicación desactivada significa que la funcionalidad nunca se ha usado, una afirmación mucho más defendible que el interruptor por sí solo, y que le indica que la solicitud está realmente sin atender y no mal explicada.
La configuración del detector de duplicados merece el mismo tratamiento. Incluye un indicador de activación, un nivel de similitud y los ID de los campos comparados por entidad, de modo que una solicitud de «activar la detección de duplicados» a menudo significa en realidad «la regla existente compara demasiado pocos campos».
Campos lookup: la mecánica que suele sorprender
- Un campo lookup es una relación multivalor, que se intercambia como un array de referencias, no una clave foránea escalar. Una lectura devuelve un array de objetos de referencia; un array vacío significa que no hay nada vinculado.
- Escribir un array sustituye los vínculos en lugar de añadirse a ellos. Envíe siempre el conjunto completo previsto; un array vacío borra la relación. Es la forma más habitual en que una integración desvincula sin avisar registros que pretendía dejar intactos.
-
Los nombres de los campos personalizados se usan tal cual, sin sufijo
_id, aunque las claves foráneas del sistema sí lo llevan. - Crear un campo lookup requiere un bloque de filtro completo incluso cuando el filtrado está desactivado; si se omite, falla con un error genérico poco útil.
La trampa cuando sí crea una entidad personalizada. Al crear una, se crea automáticamente un subtipo por defecto por debajo de ella, con el mismo nombre y un formulario vacío. Si añade sus propios subtipos, los usuarios ven en el menú de creación una entrada más de las que usted pretendía, y la sobrante no lleva a ninguna parte. En su lugar, aloje uno de sus subtipos en el subtipo por defecto creado automáticamente; consulte el Blueprint 001.
Cómo ordenar la respuesta
Una vez que cada solicitud tiene su veredicto, el orden de entrega sale solo, y adelanta deliberadamente todo lo que no cuesta nada.
- DesbloquearTodo aquello en lo que el cliente está atascado hoy. Días, no semanas, y genera buena voluntad para todo lo que viene después.
- Mostrarle lo que ya tieneCada veredicto Activo, demostrado. Ningún desarrollo. En el proyecto de referencia, esto abarcó dieciséis funcionalidades activas que nunca se habían mostrado.
- Activar y configurarLos veredictos Interruptor y Configuración. Una sesión de administración y algo de configuración, sujetas a la aprobación interna que el cliente necesite primero.
- DesarrollarSolo lo que ha superado las tres primeras fases, con alcance y presupuesto aparte, porque para entonces es una lista mucho más corta.
- Seguimientos ajenos al productoSe entregan a quien realmente se hace cargo de ellos, en lugar de absorberlos discretamente en el alcance del CRM.
Las fases 1 a 3 son las que cambian la conversación. Un análisis de requisitos que entrega una cuarta parte de la lista sin ningún desarrollo, antes de presupuestar el primero, se gana el derecho a una conversación seria sobre el resto.
Límites y compromisos
La salvedad que desmonta toda la historia de las victorias rápidas si se pasa por alto
El indicador de activación de una aplicación no distingue entre «un administrador puede activarlo hoy» y «esto depende de la licencia». En algunas filas refleja un derecho de uso y no un simple interruptor.
Confirme con el equipo de producto qué elementos puede activar realmente un administrador antes de presentarlos como victorias rápidas gratuitas. Todo el valor del hallazgo de los interruptores depende de esa distinción, y equivocarse convierte una ganancia de credibilidad en una pérdida de credibilidad.
Límites rígidos: replantear en lugar de desarrollar
En el proyecto de referencia aparecieron tres categorías, y cada una tiene una alternativa honesta:
| Límite | Consecuencia | Replantear sobre |
|---|---|---|
| Algunos objetos de la plataforma tienen una forma fija y no admiten campos adicionales | No se puede mostrar contenido personalizado a través de esa funcionalidad | Mosaicos de informes o paneles, o tareas generadas por automatización |
| Ciertos filtros solo operan sobre el propietario y la unidad organizativa | No se puede configurar el filtrado de esa funcionalidad por región | Informes y filtros guardados sobre los campos de ubicación nativos |
| La plataforma no tiene ninguna capacidad de gestión del aprendizaje ni de cuestionarios | No se puede prometer la evaluación de la incorporación como producto | Una guía proporcionada por el equipo de servicios, o un LMS de terceros del centro de integraciones |
Uno más que conviene conocer antes de diseñar en torno a ello: los procesos de aprobación no pueden tener como destino una entidad personalizada, y el propio registro de aprobación no admite campos personalizados. Si su nueva entidad necesita aprobación, eso condiciona el diseño; la solución alternativa está en el Blueprint 001.
El coste permanente de una entidad personalizada
Conviene decirlo con claridad, porque normalmente se deja fuera de la estimación: cada entidad personalizada es otro formulario que mantener, otra superficie de permisos que configurar bien, otra entrada en el menú de creación y otra cosa que hay que tener en cuenta cada vez que se reconfigura el espacio. Las entidades son baratas de crear y caras de mantener.
Dónde este análisis no puede ayudar
Las solicitudes recogidas en notas de reuniones arrastran ambigüedades que ningún conocimiento de la plataforma resuelve: una abreviatura sin explicar, un nombre de producto poco claro, una referencia a una persona que nadie sabe identificar. En el proyecto de referencia, cuatro elementos no pudieron acotarse exactamente por ese motivo. Márquelos como preguntas abiertas en lugar de adivinar; una solicitud que se ha entendido mal es más peligrosa que una que todavía no se ha respondido.
Verificación
El resultado de este ejercicio es un conjunto de afirmaciones sobre lo que puede hacer una plataforma, hechas a un cliente que se las exigirá. Cada una necesita respaldo antes de decirse en voz alta.
- Cada veredicto vinculado a una prueba. Un veredicto Interruptor cita la fila de la aplicación y su estado. Un veredicto Configuración cita el mecanismo que lo consigue. Un veredicto Límite cita la ausencia: la forma fija del objeto, o que no hay ninguna operación correspondiente en todo el esquema.
- Interruptores corroborados con el uso configurado, no afirmados solo a partir del indicador.
- Licencias confirmadas con el equipo de producto para cada elemento que vaya a presentarse como un interruptor gratuito.
- Correcciones documentadas, no absorbidas en silencio. Varias lecturas iniciales eran erróneas y se corrigieron durante el análisis; conservar ese rastro es lo que permite a un revisor comprobar el razonamiento en lugar de dar la conclusión por buena sin más.
- Los elementos que no se pueden resolver, listados como preguntas abiertas, con el motivo por el que no pueden responderse sin el cliente.
- Para todo lo que llegó a Desarrollo: el destino justificado frente a las cuatro opciones del §3, y las alternativas descartadas por escrito. Una entidad personalizada cuya necesidad nadie sabe explicar acaba creándose de todos modos seis meses después, por alguien que no sabe que ya se consideró y se descartó.
Qué indicaría que el análisis salió mal: que se presupueste un desarrollo para algo que después resulta ser un interruptor; tres estimaciones separadas que comparten una única carencia de fondo; una entidad personalizada entregada cuya vista de lista nadie abre.
Preguntas frecuentes
¿Cómo modela algo para lo que su CRM no tiene un objeto, como inspecciones, permisos o activos?
Antes de diseñar nada, determine en cuál de seis veredictos encaja realmente el requisito: ya activo en el espacio, una funcionalidad que viene con el producto pero está desactivada, alcanzable mediante configuración, un desarrollo real, un límite rígido de la plataforma que hay que replantear o, directamente, no es un problema de producto. Solo el cuarto es un ejercicio de modelado. Cuando se trata de un desarrollo, hay que elegir entre una entidad personalizada nueva (con su propio endpoint de API, formularios, numeración por secuencia y funcionalidades de registro), campos adicionales en una entidad estándar existente (más barato, pero visible para todos) o un registro hijo relacionado con un lookup de vuelta a su registro principal.
¿Cuándo conviene crear una entidad personalizada en lugar de añadir campos personalizados?
Cree una entidad personalizada cuando la cosa tenga su propio ciclo de vida, necesite su propia numeración de referencia o vaya a listarse y a analizarse en informes de forma independiente. Añada campos a una entidad estándar existente cuando los datos describan ese registro y no tengan existencia independiente: es mucho más barato y hereda todo el comportamiento del registro principal, pero cada campo es otra fila en un formulario que ven todos los usuarios. Use un registro hijo relacionado cuando haya muchos por registro principal, como líneas de pedido o visitas de inspección.
¿Por qué las solicitudes de personalización de un CRM a menudo no necesitan desarrollo?
Porque muchas de las capacidades solicitadas ya vienen con la plataforma y simplemente están desactivadas a nivel de espacio. Todo espacio de Coevera expone un panel de funcionalidades; en el espacio examinado contenía aproximadamente 107 registros de funcionalidades e integraciones, cada uno con un indicador de activación. En un análisis reciente de requisitos con seis departamentos, 11 de aproximadamente 44 solicitudes distintas correspondían a funcionalidades que estaban presentes y con licencia, pero desactivadas: no hacía falta ningún desarrollo. Leer ese panel antes de definir el alcance es el paso de mayor valor en un análisis de requisitos, porque presupuestar desarrollo para algo que es un interruptor destruye la credibilidad y consume presupuesto que debería ir a las carencias reales.
¿Cómo se distingue un límite real de la plataforma de algo que solo necesita configurarse?
Compruebe la forma de lo que intenta ampliar. Algunos objetos de la plataforma tienen una forma fija y no admiten campos adicionales, y algunos filtros solo operan sobre dimensiones concretas, como el propietario o la unidad organizativa. Cuando no existe en ninguna parte una mutación ni una vía de configuración para una capacidad, es un límite rígido, y la respuesta honesta es replantear el requisito sobre algo que sí existe (informes, paneles o tareas generadas por automatización) en lugar de prometer un desarrollo que no se puede entregar.