Criando um sistema do Zero - Account Management - Parte 1

Nesta série de artigos estaremos criando, do zero, um sistema de Account Management (gerenciamento de contas de usuário).

Hoje em dia um relógio não representa mais nenhum avanço tecnológico, visto que todo e qualquer aparelho moderno deve possuir um relógio como requisito mais básico. Celulares, aparelhos de som, DVD players, Blu-Ray (e o extinto videocassete), microondas, televisores, monitores, agendas, calculadoras, telefones fixos, videogames e qualquer outro aparelho pode vir com um relógio, e geralmente vem.

O relógio passou do status de  produto tecnológico para ser apenas um ingrediente, uma peça.

É exatamente isso que está acontecendo com os sistemas de Account Management, aqui chamados de AMS.

Veja que enquanto alguns dizem que o CRM é o topo da evolução de sistemas para gerenciamento de clientes, o CRM serve apenas para gerenciar contato e relacionamento com os clientes. A tendência de o CRM tentar centralizar os dados a respeito de clientes de todos os outros sistemas, inclusive legados, em um formato próprio pode mais dificultar do que facilitar.

O carregamento de um CRM qualquer com os dados de todos os sistemas legados da empresa deve ser feito o em duas vias, ou seja, seguido de um carregamento de TODOS sistemas legados com os dados do CRM, DEPOIS DE DEVIDAMENTE TRATADOS.

Caso isso não aconteça os dados do CRM tornam-se apenas mais um montante de dados a serem administrados. Os mesmos problemas existentes antes do CRM prevalecerão depois do CRM, apenas para citar exemplos básicos:

1. Dados desatualizados - O cliente mudou-se, ou mudou de telefone, e-mail, estado civil;
2. Dados inconsistentes - O DDD informado não pertence à cidade constante no endereço;
3. Dados incorretos - Mais grave do que dados inconsistentes, nada pode ser aproveitado, muitos campos nulos;
4. Dados falsos - O cliente ou o operador do cadastro deliberadamente armazenou no sistema falsas informações, talvez com o propósito de cometer uma fraude;
5. Dados Repetidos - Existem vários tipos de repetições, e dados repetidos não querem dizer idênticos. 

Porém a responsabilidade de um CRM não deveria ser manter o cadastro dos clientes, mas apenas gerenciar a relação com os mesmos, independente de em qual sistema da empresa eles estejam.

Dizemos "independente de em qual sistema da empresa eles estejam" porque empresas muito grandes, com uma gama variada de produtos e serviços, ou empresas formadas por conglomerados de outras empresas podem ter vários sistemas para gerenciamento de produtos diferentes, e mesmo que os clientes sejam consumidores de dois produtos distintos, por estarem em sistemas diferentes eles são considerados clientes diferentes.

Na empresa onde trabalho, por exemplo, há vendas de livors e revistas para distribuidores e atacadistas, bem como venda de assinaturas de revistas (1° sistema). Mas há também um sistema de vendas de livros pela internet, ou seja, um e-commerce (2° sistema). Este e-commerce não tem como backoffice o primeiro sistema, mas sim um terceiro, que também faz vendas em atacado e varejo. Nas filiais e livrarias (lojas físicas), para vendas de livros e revistas, há um 4° sistema. E a editora ainda oferece 2 sistemas de consulta de conteúdo das revistas online, pago através de assinatura, que são diferentes entre si: 5° e 6° sistemas.
Há um sistema de call center,( 7°) e um CRM (8°) que não se integra completamente com os outros sistemas, tornado-se assim apenas mais um.

Um cliente da livraria, por exemplo, não é visto como um prospectivo cliente do conteúdo online, mesmo já sendo assinante.

Agora imagine o cenário onde um cliente foi cadastrado com CPF do cônjuge, divorciou-se, mas não mudou de e-mail. O cônjuge não conseguirá criar um cadastro próprio porque "o cpf  informado já existe". Já o outro cliente não conseguirá criar um outro cadastro porque "o seu e-mail já existe".

O cadastro original não pode ser desmembrado em dois, e não pode ser deletado pois já possui um histórico.
O correto nesse caso seria fazer a exclusão via flag (deletado = 1) mas aí você não pode definir o CPF ou o e-mail como unique no banco de dados. Talvez criar um conjunto de tabelas auxiliares para contas e pedidos  "lixeira" e mover tudo para lá seria uma boa idéia.

Outra situação, um pouco mais complexa, são de usuários diferentes que são cadastrados com e-mail trocado, ou CPF trocado. Simplesmente é impossível colocar o CPF correto em um porque ele já existe no outro.

Outro problema são e-mails falsos, CPF's falsos, fraudes etc...

Agora imagine um sistema de banco ou de seguro de saúde: esses sistemas são os mais confiáveis em matéria de autenticidade do cliente, pois para um cliente existir no sistema ele teve que comparecer pessoalmente em uma agência e apresentar documentos originais e comprovante de residência. Cada vez que seus dados cadastrais mudarem ele deve voltar pessoalmente em uma agência e apresentar novamente os documentos. Talvez cópias dos documentos fiquem com a empresa e até uma impressão digital do cliente.

Porém sistemas de bancos e seguros saúde não são os mais dinâmicos no sentido de contatos, ou mais especificamente, redes de contatos e atualização desses dados. Por exemplo, se você adquirir 10 celulares novos, 5 contas de e-mail, twitter, orkut, facebook etc... dificilmente o seu banco será informado disso.

Em contrapartida os e-commerces, blogs, jornais e revistas online, embora sejam os mais sensíveis em matéria de dados cadastrais fraudulentos, são os mais dinâmicos no aspecto "social", sendo assim, caso o usuário tenha (e tenha o hábito de usar) celular, SMS,

Esta série de artigos terá como objetivo elocubrar a criação de um sistema de Gerenciamento de Contas seguro e unificado, que possa conter API's tanto para alimentar os sistemas legados com clientes como para ser alimentados por eles.



Conforme forem surgindo os desafios falaremos sobre como resolve-los.

Os objetivos desse sistema, denominado AMS, serão:

1. fornecer entrada de clientes unificada para todos os sistemas
2. fornecer consulta de clientes unificada para todos os sistemas
3. agregar segurança no processo de cadastro de clientes
4. atualizar e sincronizar em duas vias todos os dados utilizados pelo cliente em todos os sistemas
5. servir como gerenciador de sessões para sites e blogs com conteúdo pago
6. ser extensível para acomodar outros tipos de relações além de empresa/cliente

A longo prazo podemos considerar:

1. prover serviços para sistemas de terceiros, mediante pagamento
2. prover autenticação para sistemas de terceiros, mediante pagamento
3. ser um gateway de clientes assim como Moip, PagSeguro e Braspag são gateways de pagamentos
4. ser uma autoridade no quesito autenticação de usuário assim como o facebook/openID o é, mas fornecendo a segurança de o usuário ser perfeitamente identificável e reconhecível, o que traz segurança para o usuário evitando enganos ou fraudes da empresa, e evitando que sua conta seja sequestrada por outro usuário, e trazendo segurança para a empresa por garantir que o usuário exista.

Optou-se por criar o modelo mais trivial possível e ir aumentando em complexidade conforme necessário. Não tocaremos no assunto sobre metodologias porque simplesmente eu não domino tão bem a engenharia de software a ponto de ser prepotente o bastante para impor alguma metodologia, porém, conforme já disse em aula o meu guru professor Duduchi, "A melhor metodologia de desenvolvimento de software é o bom senso".

Por isso abordaremos algumas boas práticas como testes unitários e TDD, sistemas de gerenciamento de versão (SVN, CVS, VCS, Source Safe, GIT, Mercury e tantos outros) e alguma coisa de UML. Falaremos também sobre frameworks de persistência,  webservices e serialização de objetos. 

Obviamente alguns desses objetivos são até utópicos, mas vejamos até onde conseguiremos chegar. 

Para iniciar nosso projeto usaremos o ArgoUML para gerar os diagramas UML, primeiramente de classes. Podemos também exportar os esqueletos de código. 

No próximo post trataremos de mais alguns cenários de problemas e abordaremos a questão da persistência.