Como continuación de mi anterior webcast sobre el tema de la De relacional a NoSQL base de datos en la que comenté que estamos en la tercera fase del Base de datos NoSQL adopción, el "Broad Replatforming" de la Aplicación Empresarial. Quiero proporcionar un ejemplo en este artículo sobre cómo la aplicación puede aprovechar el modelo de datos JSON y Couchbase N1QL (una implementación de SQL) para abordar la compleja regla de visibilidad de datos de una aplicación CRM.

Visión general

Un aspecto crítico en una aplicación CRM, pero que a menudo se pasa por alto, es el proceso de gestión de actividades. Para gestionar la relación con el cliente, y hacerlo de forma eficaz, la aplicación necesita hacer un seguimiento de todas las actividades asociadas directa o indirectamente a la tarea de gestión de la relación. Una actividad CRM captura todas las interacciones que una empresa tiene con sus clientes a lo largo de toda la relación. También se utiliza para registrar diferentes actividades que se encuentran en el sistema CRM, algunas de las cuales pueden no estar directamente asociadas a las cuentas, como por ejemplo el proceso de generación de clientes potenciales, la gestión de cuotas y la realización de pedidos. También lo utilizan la campaña de Marketing y los Servicios para hacer un seguimiento de todas las actividades de apoyo.

En este artículo mostraré cómo el modelo de gestión de actividades puede representarse mejor en JSON. A continuación, utilizando Couchbase N1QL como lenguaje de consulta para satisfacer los requisitos funcionales de visibilidad de datos directa y de equipo.

Los retos de la gestión de actividades

Debido a que las actividades pueden asociarse a todos los demás objetos clave, la gestión de actividades se considera un componente común en la aplicación CRM. Pero a diferencia de otros objetos CRM, la actividad suele estar configurada para depender de otros objetos clave para la seguridad de sus datos. Por tanto, el acceso a la actividad viene determinado por el objeto u objetos a los que está asociada. Por ejemplo, cabe esperar que un usuario pueda ver todas las actividades asociadas a las cuentas u oportunidades que posee. Por estas razones, con el tiempo, muchas implantaciones de CRM empresarial pueden dar lugar a un gran volumen de registros de actividades. Tenga en cuenta que el volumen de datos de las actividades por sí mismo no siempre es motivo de preocupación. Sin embargo, cuando se combina con reglas complejas de visibilidad de datos, se convierte en un problema más difícil.

Las consultas relacionales para recuperar las actividades que puede ver un usuario pueden resultar complejas debido a las reglas de acceso indirecto a los datos. A menudo, esto se traduce en un tiempo de respuesta lento del sistema en el proceso de gestión de actividades, así como en la generación de informes empresariales para esta función.

Volumen

Dado que las interacciones de las actividades se capturan en todas las etapas de CRM, es con diferencia el objeto más utilizado. A menudo, intentar acceder a todas las actividades que un usuario puede ver puede dar lugar a respuestas lentas del sistema debido al volumen de datos y a las complejas reglas de negocio.

Acceso a los datos

En CRM, el acceso a los datos se define de varias maneras. Propiedad directa e indirecta, así como acceso en equipo y jerárquico.

Acceso directo/propio

Un usuario puede acceder a un objeto de datos a través de la propiedad directa de dicho objeto. En CRM, todos los objetos clave, como cuentas, contactos, oportunidades, etc., tienen una definición clara de propiedad directa. Un gestor de cuentas es propietario de una cuenta, un representante de ventas es propietario de una oportunidad, un miembro del equipo de soporte es propietario de una solicitud de servicio.

Acceso indirecto

En este modelo, el acceso a un objeto se infiere del objeto padre. Por ejemplo, un sistema CRM puede configurarse para permitir al usuario acceder a todos los contactos de una cuenta si el usuario tiene acceso a la cuenta. Esto también podría extenderse a otros objetos relacionados con la cuenta, como la oportunidad y la solicitud de servicio.

Acceso del equipo

Una variación de la propiedad directa es cuando un objeto tiene múltiples miembros de equipo. Por ejemplo, mientras que una cuenta tiene un propietario, también puede haber un equipo de cuenta con varios representantes de ventas que gestionen la cuenta. Esto también es muy común en las ventas basadas en territorios.

Acceso jerárquico

Un ejemplo de este tipo de acceso es la jerarquía de gestión. Un directivo debe tener visibilidad sobre todas las actividades de sus subordinados directos. Del mismo modo, un usuario en el nodo del territorio padre debería poder ver las actividades que están asociadas a los territorios hijos.

Acceso a reglas de negocio personalizadas

Las organizaciones también pueden tener reglas personalizadas para gobernar la visibilidad de los datos. Por ejemplo, línea de producto o región geográfica personalizada.  

Modelo de datos de gestión de actividades  

Documento JSON de la actividad

Una de las características del documento JSON es su flexibilidad con la estructura de datos. Para el objeto Actividad de CRM, la restricción de la base de datos relacional requeriría que todos los atributos de la actividad estuvieran predefinidos en la definición de la tabla. Esto puede ser confuso al mirar el registro de la actividad, ya que no todos los atributos estarían rellenados. Sin embargo en JSON, al no tener un esquema, cada documento puede tener un conjunto diferente de columnas.

Los dos documentos de actividad siguientes muestran las ventajas del esquema flexible de JSON. Una actividad de tipo "Cita" incluye atributos contextuales como un conjunto de contactos, hora de inicio, duración y "Participantes". Mientras que las 'Tareas' tienen atributos que les son específicos, como Fecha de vencimiento y ToDoList.

Extensibilidad

El objeto de actividad es también uno de los objetos clave que a menudo se amplían para diferentes necesidades de CRM. En la automatización de ventas genéricas, puede representar un informe de llamada con atributos específicos, como el resultado y los detalles de seguimiento. Para las ventas farmacéuticas, puede representar una visita médica que puede incluir la captura de una lista de entrega de muestras de medicamentos.

La naturaleza mutable del objeto de actividad requerido por diferentes verticales de CRM puede dar lugar a diversas variaciones de la estructura del esquema para este objeto. JSON es, por tanto, un medio ideal para modelar este objeto por esta única razón.

Modelo de propietario y participante

Visibilidad de los datos

El usuario debe ver: Todas las actividades

  1. Que el usuario posee
  2. Que el usuario sea participante de

Propietario y participante, con propietario de cuenta y equipo de cuenta asociados

 

Visibilidad de los datos

El usuario debe ver: Todas las actividades

  1. Que el usuario posee
  2. Que el usuario sea participante de
  3. Pertenecen a la cuenta que posee el usuario
  4. Pertenecen a la cuenta en la que el usuario está en el equipo de la cuenta

Propietario y Participante, Propietario de Cuenta y Equipo de Cuenta asociados, Propietario de Territorio asociado y Equipo territorial

 

Visibilidad de los datos

El usuario debe ver: Todas las actividades

  1. Que el usuario posee
  2. Que el usuario sea participante de
  3. Pertenecen a la cuenta que posee el usuario
  4. Pertenecen a la cuenta en la que el usuario está en el equipo de la cuenta
  5. Pertenecen al territorio de la cuenta que posee el usuario
  6. Pertenecer al territorio de la cuenta donde el usuario está en el equipo del territorio

Resumen

Los ejemplos anteriores ilustran los siguientes puntos clave

  • El modelo de datos de esquema flexible JSON se adapta bien a la naturaleza ambigua del objeto de actividad
  • Hay menos objetos JSON que en el modelo de datos relacional
  • El concepto de miembro de equipo funciona bien con la matriz JSON
  • La construcción de consulta de N1QL es bastante similar a SQL, y algo más simple

En el próximo artículo, hablaré del reto de la seguridad jerárquica de los datos y de la mejor forma de modelarla funcionalmente en JSON.

Autor

Publicado por Binh Le

Binh Le es director de producto principal del servicio de consultas de Couchbase. Antes de Couchbase, trabajó en Oracle y dirigió el equipo de gestión de productos para Sales Clould Analytics y CRM OnDemand. Binh es licenciado en Informática por la Universidad de Brighton, Reino Unido.

Dejar una respuesta