Como acompanhamento de meu webcast anterior sobre o tema De relacional para NoSQL onde discuti o fato de estarmos na terceira fase do Banco de dados NoSQL a "Replataforma ampla" de aplicativos corporativos. Neste artigo, quero dar um exemplo de como o aplicativo pode aproveitar o modelo de dados JSON e o Couchbase N1QL (Uma implementação do SQL++) para abordar a complexa regra de visibilidade de dados de um aplicativo de CRM.
Visão geral
Um aspecto essencial em um aplicativo de CRM, mas que geralmente é ignorado, é o processo de gerenciamento de atividades. Para gerenciar o relacionamento com o cliente e fazê-lo de forma eficaz, o aplicativo precisa acompanhar todas as atividades direta ou indiretamente associadas à tarefa de gerenciamento do relacionamento. Uma atividade de CRM captura todas as interações que uma empresa tem com seus clientes durante todo o relacionamento. Ela também é usada para registrar diferentes atividades que estão no sistema de CRM, algumas das quais podem não estar diretamente associadas às contas, como o processo de geração de leads, o gerenciamento de cotas e o atendimento de pedidos. Ele também é usado pela campanha de marketing e pelos serviços para rastrear todas as atividades de suporte.
Neste artigo, mostrarei como o modelo de gerenciamento de atividades pode ser melhor representado em JSON. Em seguida, usarei o Couchbase N1QL como linguagem de consulta para satisfazer os requisitos funcionais de visibilidade direta dos dados da equipe.
Os desafios do gerenciamento de atividades
Devido ao fato de que as atividades podem ser associadas a todos os outros objetos-chave, o gerenciamento de atividades é considerado um componente comum no aplicativo de CRM. Mas, diferentemente de outros objetos de CRM, a atividade é frequentemente configurada para depender de outros objetos-chave para sua segurança de dados. Portanto, o acesso à atividade é determinado pelo objeto ou objetos aos quais ela está associada. Por exemplo, pode-se esperar que um usuário consiga ver todas as atividades associadas às contas ou oportunidades que ele possui. Por esses motivos, ao longo do tempo, muitas implantações do Enterprise CRM podem resultar em um grande volume de registros de atividades. Observe que o volume de dados das atividades comerciais por si só nem sempre é motivo de preocupação. Entretanto, quando ele é combinado com regras complexas de visibilidade de dados, torna-se um problema mais desafiador.
As consultas relacionais para recuperar as atividades que um usuário pode ver podem se tornar complexas devido às regras de acesso indireto aos dados. Isso geralmente resulta em um tempo de resposta lento do sistema no processo de gerenciamento de atividades, bem como na geração de relatórios comerciais para essa função.
Volume
Como as interações de atividade são capturadas em todos os estágios do CRM, esse é, de longe, o objeto mais usado. Muitas vezes, tentar acessar todas as atividades que um usuário pode ver pode resultar em respostas lentas do sistema devido ao volume de dados e às complexas regras comerciais.
Acesso aos dados
No CRM, o acesso aos dados é definido de várias maneiras. Propriedade direta e indireta, bem como acesso hierárquico e de equipe.
Acesso direto/do proprietário
Um usuário pode acessar um objeto de dados por meio da propriedade direta desse objeto. No CRM, todos os principais objetos, como conta, contato, oportunidades etc., têm uma definição clara de propriedade direta. Um gerente de contas é proprietário de uma conta, um representante de vendas é proprietário de uma oportunidade e o membro da equipe de suporte é proprietário de uma solicitação de serviço.
Acesso indireto
Nesse modelo, o acesso a um objeto é inferido a partir do objeto pai. Por exemplo, um sistema de CRM pode ser configurado para permitir que o usuário acesse todos os contatos de uma conta se o usuário tiver acesso à conta. Isso também pode se estender a outros objetos relacionados à conta, como oportunidade e solicitação de serviço.
Acesso à equipe
Uma variação da propriedade direta é quando um objeto tem vários membros de equipe. Por exemplo, embora uma conta tenha um proprietário, também pode haver uma equipe de contas com vários representantes de vendas que gerenciam a conta. Isso também é muito comum nas vendas de base territorial.
Acesso hierárquico
Um exemplo desse tipo de acesso é a hierarquia de gerenciamento. Um gerente deve ter visibilidade de todas as atividades dos subordinados diretos. Da mesma forma, um usuário no nó do território pai deve ser capaz de ver as atividades associadas aos territórios filhos.
Acesso a regras de negócios personalizadas
As organizações também podem ter regras personalizadas para controlar a visibilidade dos dados. Por exemplo, linha de produtos ou região geográfica personalizada.
Modelo de dados de gerenciamento de atividades
Documento JSON da atividade
Uma das características do documento JSON é sua flexibilidade com a estrutura de dados. Para o objeto Atividade de CRM, a restrição do banco de dados relacional exigiria que todos os atributos da atividade fossem predefinidos na definição da tabela. Isso pode ser confuso quando se olha para o registro da atividade, pois nem todos os atributos estariam preenchidos. Entretanto, no JSON, como ele não tem um esquema, cada documento pode ter um conjunto diferente de colunas.
Os dois documentos de atividade abaixo mostram os benefícios do esquema flexível do JSON. Uma atividade do tipo "Compromisso" inclui atributos contextuais, como um conjunto de contatos, hora de início, duração e "Participantes". Já a "Tarefa" tem atributos específicos, como Data de vencimento e ToDoList.
Extensibilidade
O objeto de atividade também é um dos principais objetos que costumam ser estendidos para diferentes necessidades de CRM. Na automação de vendas genéricas, ele pode representar um relatório de chamada com atributos específicos, como resultados e detalhes de acompanhamento. Para vendas de produtos farmacêuticos, pode representar uma visita ao médico, que pode incluir a captura de uma lista de amostras de medicamentos.
A natureza mutável do objeto de atividade exigido por diferentes verticais de CRM pode resultar em diversas variações da estrutura de esquema desse objeto. Portanto, o JSON é o meio ideal para modelar esse objeto apenas por esse motivo.
Modelo do proprietário e do participante
Visibilidade dos dados
O usuário deve ver: Todas as atividades
- Que o usuário possui
- Que o usuário é um participante de
Proprietário e Participante, com Proprietário da Conta e Equipe da Conta associados
Visibilidade dos dados
O usuário deve ver: Todas as atividades
- Que o usuário possui
- Que o usuário é um participante de
- Pertencem à conta que o usuário possui
- Pertencem à conta em que o usuário faz parte da equipe da conta
Proprietário e Participante, Proprietário da conta associado e Equipe da conta, Proprietário do território associado e Equipe do Território
Visibilidade dos dados
O usuário deve ver: Todas as atividades
- Que o usuário possui
- Que o usuário é um participante de
- Pertencem à conta que o usuário possui
- Pertencem à conta em que o usuário faz parte da equipe da conta
- Pertencem ao território da conta que o usuário possui
- Pertencem ao território da conta em que o usuário está na equipe do território
Resumo
Os exemplos acima ilustram os seguintes pontos-chave
- O modelo de dados de esquema flexível JSON é adequado para a natureza ambígua do objeto de atividade
- Há menos objetos JSON do que no modelo de dados relacional
- O conceito de membro da equipe funciona bem com a matriz JSON
- A construção de consulta do N1QL é bastante semelhante ao SQL e um pouco mais simples
No próximo artigo, discutirei o desafio da segurança de dados hierárquicos e como isso pode ser modelado de forma mais funcional em JSON.
