O Que Deve Estar na Mesa no Dia Seguinte à Fase de Análise e Desenho
A fase de Análise e Desenho de CRM é avaliada pelos resultados que podem ser utilizados na prática, e não pela quantidade de reuniões. Se, ao final desta fase, o gestor de projeto ainda não consegue criar um plano de trabalho, o desenvolvedor ainda não sabe qual objeto contém o processo, e o gestor de dados ainda não sabe a origem do cliente, a fase de Análise e Desenho não foi concluída, mesmo que a apresentação tenha sido aprovada.
Este documento define sete resultados essenciais. Para cada um, há um critério de maturidade: uma afirmação que pode ser respondida com "sim" ou "não". Se a resposta for "mais ou menos" para mais de dois, a fase de construção inicia-se com um risco que já pode ser precificado. A visão geral das etapas pós-análise e desenho encontra-se no Guia de Implementação Salesforce.
Resultado 1: Mapa de Processos em Nível de Decisão
Não se trata de um fluxograma de cada clique, mas sim de um mapeamento dos pontos de decisão: quem decide, com base em qual informação, o que acontece em cada ramificação e o que ocorre quando não há decisão. A maioria das falhas em projetos de CRM não reside no caminho principal, mas sim nas ramificações — um negócio que é congelado, um cliente que retorna após dois anos, uma solicitação aberta pelo cliente errado.
Critério de Maturidade: É possível pegar um negócio real do último mês e rastreá-lo no mapa de ponta a ponta sem encontrar lacunas.
Resultado 2: Glossário de Termos de Negócio
Este é o resultado mais subestimado e cuja ausência é a mais custosa. "Cliente" significa algo diferente para finanças e vendas. "Projeto Ativo" significa algo diferente para operações e para a gestão executiva. Enquanto as definições não estiverem escritas, cada relatório gerará discussões.
O glossário deve conter, para cada termo: uma definição em uma frase, a entidade em Salesforce que o representa, o campo que determina o status e o departamento responsável pela definição.
Resultado 3: Modelo de Dados Central Decidido
Na fase de Análise e Desenho, não se constrói um ERD (Diagrama de Entidade e Relacionamento) completo, mas sim se tomam decisões sobre as quatro questões mais caras para serem alteradas posteriormente:
- Se a atividade de negócio reside em um Objeto Opportunity, em um objeto personalizado ou em uma combinação de ambos, e qual a relação entre eles.
- Se a Entidade Account representa uma entidade jurídica, um local físico ou um grupo de compras — e como a hierarquia é tratada.
- Qual é a chave única que identifica o cliente entre Salesforce e os sistemas base.
- Quais dados históricos são importados para o sistema e quais permanecem na origem.
Critério de Maturidade: É possível desenhar em um quadro os cinco objetos principais e seus relacionamentos sem consultar arquivos.
Resultado 4: Modelo de Permissões e Compartilhamento
O modelo de permissões é derivado da pergunta "quem não deve ver o quê", e não da pergunta "quem precisa ver o quê". Estas duas perguntas parecem idênticas, mas levam a arquiteturas opostas. Uma boa análise e desenho define as permissões padrão da organização para cada objeto principal, o mecanismo de expansão e os casos que exigem compartilhamento excepcional.
| Pergunta | O que verificar na Análise e Desenho | Por que é caro mudar depois |
|---|---|---|
| Padrão para o objeto | Privado, Leitura Pública ou Leitura/Escrita | Afeta todo o mecanismo de compartilhamento acima dele |
| Estrutura hierárquica | Se a hierarquia de funções reflete gerenciamento ou geografia | A mudança exige recálculo do acesso em todos os registros |
| Compartilhamento entre unidades | Equipes colaborativas, compartilhamento manual ou critério | Determina se é necessária lógica dedicada |
| Dados sensíveis | Quais campos são restritos e para quem | A mudança posterior expõe informações que já foram visualizadas |
Resultado 5: Mapa de Sistemas e Fontes da Verdade
Para cada entidade central, deve haver uma única e declarada fonte da verdade, e uma direção de sincronização clara. Uma análise e desenho que deixa dois sistemas "atualizando um ao outro" cria conflitos que só serão descobertos na produção. O mapa também deve incluir a frequência e a tolerância ao atraso: um processo de vendas pode conviver com uma sincronização de cinco minutos, mas o controle de crédito geralmente não.
Resultado 6: Critérios de Aceitação para Processos Chave
Esta é a conexão entre a Análise e Desenho e os testes. Para cada processo chave, são necessários de três a cinco critérios de aceitação formulados como um resultado observável: "Após o fechamento de um negócio, um pedido é criado no sistema core em até cinco minutos, com o mesmo ID de cliente". Tal formulação é uma demanda, um roteiro de teste e uma definição de conclusão. Sem isso, a fase de UAT (User Acceptance Testing) torna-se uma série de comentários de design.
Resultado 7: Métricas de Base Antes da Mudança
É impossível provar melhoria sem medição prévia. Na fase de Análise e Desenho, selecionam-se de três a cinco métricas e as mede-se efetivamente no estado atual, mesmo que a medição seja manual e grosseira. A seleção das métricas e a forma de conectá-las ao benefício de negócio são detalhadas no Guia de ROI e Métricas de Sucesso Salesforce.
Exemplo Ilustrativo: Rede de Clínicas Privadas
O cenário a seguir é hipotético e serve apenas para fins ilustrativos. Uma rede de clínicas com oito unidades iniciou um projeto de CRM para centralizar as solicitações dos pacientes. Durante a fase de Análise e Desenho, descobriu-se que duas unidades definiam "solicitação recorrente" de forma diferente: uma contava cada ligação, enquanto a outra contava apenas solicitações sobre um novo tema. A diferença parecia semântica, mas determinava se o sistema precisaria de um único objeto Case com hierarquia ou de dois objetos separados, e influenciava todos os relatórios de carga de trabalho para a gerência.
A equipe não resolveu a disputa no documento. Eles registraram uma decisão em aberto, definiram um proprietário em nível de Diretor de Operações e uma data-alvo antes do início da construção. A decisão foi tomada em duas semanas, e o modelo foi construído uma única vez. Se a decisão tivesse sido adiada, ela teria sido descoberta na fase de UAT — após telas e relatórios já terem sido construídos com base em uma premissa incorreta.
Sinais de Alerta de uma Análise e Desenho Superficial
- O documento descreve telas e campos, mas não descreve o que acontece quando um processo falha.
- Nenhuma decisão documentada considerou alternativas.
- Todas as demandas têm alta prioridade.
- Não há um nome de pessoa associado a nenhum processo, apenas o nome de um departamento.
- O número de campos solicitados em uma única tela excede vinte e cinco sem que ninguém tenha verificado quem os preenche.
A relação entre uma análise e desenho superficial e os padrões de falha que aparecem posteriormente no projeto é detalhada no Guia dos Erros Comuns, e sua influência no cronograma é explicada no Guia de Duração de Projeto Salesforce.
Ao Substituir um Sistema Existente
Quando o projeto substitui um CRM antigo, a fase de Análise e Desenho ganha uma tarefa adicional: decidir o que não será migrado. Um sistema antigo acumulou campos, automações e relatórios que ninguém mais usa, e a replicação cega deles importa a dívida técnica antiga para uma nova plataforma. A sequência de ações recomendada nesta transição está detalhada no Guia de Substituição de CRM por Salesforce.
Como Saber Que é Hora de Começar a Construir
Revise os sete resultados e, para cada um, faça a pergunta de maturidade. Se seis dos sete responderem "sim", é possível iniciar a primeira onda gerenciando a sétima lacuna como um risco documentado. Se três ou mais responderem "mais ou menos", é preferível estender a fase de Análise e Desenho por duas semanas do que descobrir a lacuna após três meses de trabalho terem sido construídos sobre ela.
A próxima etapa natural é a tradução dos resultados para um plano de ondas, com uma decisão explícita sobre o que entra na primeira onda e o que é conscientemente adiado.