A Resposta Concisa
A questão central na implementação do Salesforce em uma organização não é "qual módulo ativar primeiro", mas sim como construir um caminho onde cada etapa gera um resultado aprovável, e não apenas mais uma reunião. Este guia segue oito estações: Discovery, Solution Design, Construção Iterativa, Migração, UAT, Treinamento, Go Live e Hypercare. Em cada estação, há um produto final obrigatório, um aprovador e um risco principal que deve ser mitigado antes de prosseguir.
A ideia central é uma sequência ininterrupta: não é possível construir sem um Solution Design aprovado, e não é possível entrar em operação sem um UAT assinado por alguém com autoridade de negócio. Quando uma etapa é pulada, o problema não desaparece – ele apenas é transferido para uma fase de correção mais cara. Informações adicionais sobre a decisão de substituir um sistema existente estão disponíveis em Substituir CRM pelo Salesforce.
Mapa Completo das Etapas
| Etapa | Produto Final Obrigatório | Quem Aprova | Risco Principal |
|---|---|---|---|
| Discovery | Documento As-Is/To-Be, Baseline e Métricas de Sucesso | Patrocinador de Negócios e Proprietário do Processo | Definição de sucesso vaga que só é revelada no UAT |
| Solution Design | Modelo de Dados, Permissões, ADR e Diagrama de Integrações | Arquiteto Salesforce e CIO | Solução construída em torno de uma solicitação pontual, e não de um processo |
| Construção Iterativa | Vertical Slice funcional em cada Sprint, com Demonstração | Product Owner | Acúmulo de Backlog de "quase pronto" sem definição de conclusão |
| Migração | Resultado de Rehearsal de Migração completo versus critérios de qualidade | Proprietário dos Dados por Objeto | Dados duplicados ou ausentes que são descobertos apenas após o carregamento em Produção |
| UAT | Assinatura dos proprietários do processo para cenários ponta a ponta | Líderes de Equipes de Negócios | Teste superficial que cobre apenas o "Happy Path" |
| Treinamento | Plano de Habilitação, Materiais de Treinamento e lista de Champions | Gerente de CRM | Usuários aprendem "na prática" e geram dados de baixa qualidade |
| Go Live | Checklist Go/No-Go assinado e plano de Rollback | Gerência de Projeto | Entrada em produção sem um plano de contingência em caso de falha |
| Hypercare | Registro diário de falhas e métrica de adoção versus Baseline | Gerente de CRM e equipe de implementação | Encerramento prematuro do projeto, antes que a adoção se estabilize |
Discovery: Antes de Tocar Nas Ferramentas
A fase de Discovery define tudo o que virá depois e, mesmo assim, é a etapa que mais organizações apressam para "começar a construir logo". O produto final exigido não é uma apresentação, mas um documento que inclui o processo As-Is documentado, a meta To-Be, e uma lista explícita do que não será incluído na primeira versão. Sem essa definição, qualquer nova solicitação que surgir em dois meses será percebida como uma parte "óbvia" do projeto.
A ferramenta mais prática nesta fase é um Baseline mensurável: tempo de manuseio de um Lead, porcentagem de negócios fechados sem dupla digitação, taxa de campos vazios em um registro de cliente. Sem um número antes da mudança, é impossível provar a melhoria após o lançamento - apenas sentir que ela existe. Organizações que pulam esta fase voltam a ela de qualquer maneira, geralmente no meio da construção, e isso custa mais. Outras implicações de pular etapas precocemente são detalhadas em Erros na Implementação do Salesforce.
Solution Design: Onde a Maioria das Decisões Caras Acontece
Solution Design é a fase onde se escolhe entre várias alternativas de implementação e se documenta por que uma foi escolhida e não as outras. O modelo de dados, a estrutura de permissões (incluindo o compartilhamento entre funções e regiões) e o diagrama de integrações com sistemas como ERP, plataformas de pagamento ou marketing – tudo isso precisa estar escrito antes que o primeiro ambiente de desenvolvimento seja aberto.
Um erro comum é permitir que a equipe de desenvolvimento "decida no decorrer do trabalho" como será o modelo de Compartilhamento, porque isso parece um detalhe técnico. Na prática, mudar um modelo de compartilhamento depois que já existem centenas de registros em produção é um projeto em si. Portanto, quando a decisão cruza vários departamentos ou afeta permissões sensíveis, é preciso garantir que as responsabilidades e funções em torno do projeto estejam claras – veja mais detalhes em Equipe de Projeto Salesforce.
O que deve estar documentado no Solution Design
- Modelo de objetos e campos centrais, incluindo o que não será construído na primeira versão
- Mapa de permissões por função, incluindo exceções e casos de acesso temporário
- Lista de integrações com a direção do fluxo de dados e frequência de sincronização
- Pelo menos três decisões arquitetônicas com uma alternativa rejeitada e a razão para isso
Construção Iterativa: Vertical Slice e Não Apenas uma Coleção de Telas
Na fase de construção, a armadilha comum é o progresso "horizontal" – criar todas as telas de uma vez sem que nenhum processo funcione de ponta a ponta. A abordagem correta é construir um Vertical Slice em cada ciclo: um processo completo, com dados reais e permissões representativas, que pode ser demonstrado ao proprietário do processo para obter feedback imediato.
Todo Sprint deve terminar com uma demonstração, não apenas com "código enviado". Quando não há uma Demo regular, acumula-se um inventário de itens "quase prontos" que se revelam incompletos apenas na fase de UAT, e é exatamente isso que encarece o projeto em seu último terço.
Migração: A Parte Mais Subestimada
A migração de dados é frequentemente o maior risco em um projeto, e geralmente recebe menos tempo no cronograma. É imperativo realizar um Rehearsal completo – carregar dados para um ambiente de teste em sua totalidade, incluindo volumes reais, e verificar o resultado em relação a critérios de qualidade predefinidos: duplicidades, campos obrigatórios ausentes, formato de datas e moedas, e compatibilidade entre sistemas.
Uma tabela útil para gerenciar este risco:
| Verificação de Qualidade | O que é verificado | Limite de Aceitação Recomendado |
|---|---|---|
| Integridade de Campos Obrigatórios | Percentual de registros com campo crítico vazio | Abaixo de 2% |
| Duplicidades | Clientes/Leads com o mesmo identificador de negócio | Abaixo de 1% após desduplicação |
| Compatibilidade de Formato | Datas, moedas, códigos de país | 100% compatível com o padrão de destino |
| Conectividade de Registros | Relações Parent-Child que não foram quebradas na transição | 100% das relações críticas |
UAT: Teste com Propriedade Real, Não Assinatura Técnica
Um UAT realizado corretamente envolve os proprietários do processo executando cenários de ponta a ponta por conta própria, e não a equipe do projeto demonstrando a eles. Recomenda-se selecionar 8 a 12 cenários que cubram não apenas o caminho feliz, mas também casos extremos: um cliente sem endereço de e-mail, um negócio cancelado após aprovação, um usuário com permissão parcial. A assinatura de um UAT deve ser explícita – nome, data e uma lista das lacunas que permanecem abertas para a próxima versão, e não apenas "aprovação verbal em reunião".
Treinamento: Onde o Projeto Silenciosamente Atinge o Sucesso ou Falha
Mesmo uma excelente solução técnica falha se os usuários não a adotam. Um bom plano de treinamento inclui material adaptado para cada função (não uma apresentação única para todos), demonstrações em um ambiente Sandbox com dados familiares e uma lista de Champions – usuários-chave de cada equipe que podem responder a perguntas cotidianas sem abrir um chamado de suporte. Organizações que investem em treinamento duas semanas antes do Go Live geralmente observam menos "falsos positivos" de falhas ("o sistema não funciona", quando na verdade é um erro de entrada).
Go Live e Hypercare: A Entrada em Produção é o Começo, Não o Fim
O Go Live exige uma Checklist assinada que inclua a verificação de permissões no ambiente de produção, a validação de integrações ativas e um plano de Rollback claro para o caso de uma falha bloqueante ser detectada. Após o lançamento, inicia-se o período de Hypercare – geralmente de duas a quatro semanas, durante as quais a equipe monitora diariamente logs de erros, taxa de uso real e reclamações de usuários, corrigindo com alta prioridade dentro de um dia útil. Encerrar o projeto antes que a adoção se estabilize é um erro comum: os dados das primeiras duas semanas quase sempre apresentam uma imagem pior do que a realidade será após a estabilização dos hábitos.
O Que Realmente Acontece de Errado em Empresas Médias em Israel
Na prática da HPI Pro com empresas de médio porte em Israel (entre 20 e 300 funcionários), a maioria das falhas não decorre de uma escolha errada de produto, mas sim de atalhos processuais:
- Gerência não disponível para aprovar o Escopo – O projeto avança com base na interpretação do gerente de TI, e quando a gerência finalmente vê o resultado, solicita mudanças que retrocedem semanas.
- Dependência de um único desenvolvedor ou pequeno escritório sem backup de documentação – Quando a pessoa sai, não há quem entenda as decisões tomadas no Solution Design.
- Migração de fontes não oficiais – Planilhas Excel que cada vendedor gerencia separadamente, sem uma fonte de verdade acordada, o que transforma a fase de limpeza em um subprojeto.
- Compactação do UAT em uma semana antes do Go Live – Quando o cronograma aperta, o UAT é a primeira etapa a ser reduzida, e é exatamente a etapa mais importante de se manter.
- Falta de treinamento adaptado ao idioma e à função – Materiais de treinamento genéricos em inglês para uma equipe de vendas que trabalha em hebraico levam a um uso parcial e à contorno do sistema na prática.
A maneira de reduzir esses riscos não é "trabalhar mais rápido", mas planejar a camada de DevOps do projeto – ambientes de teste separados, processo de Release definido e rastreamento de mudanças – desde o início. Mais detalhes sobre isso em Salesforce DevOps Sandboxes.
Checklist Antes de Mudar de Etapa
- ☐ Há um produto final documentado para cada etapa, e não apenas um resumo de reunião.
- ☐ O Baseline é medido antes do início do projeto.
- ☐ O modelo de dados e as permissões são aprovados antes de iniciar o desenvolvimento.
- ☐ Cada Sprint termina com uma demonstração de Vertical Slice.
- ☐ Um Migration Rehearsal completo foi realizado com um limite de qualidade definido.
- ☐ O UAT foi assinado pelos proprietários do processo com uma lista de lacunas abertas.
- ☐ Existe um plano de treinamento adaptado à função e ao idioma.
- ☐ Há um Checklist Go/No-Go e um plano de Rollback.
- ☐ O período de Hypercare é definido em tempo e responsabilidade.
Como Medir o Sucesso Real do Projeto
| Área de Medição | O que é verificado | Frequência de Monitoramento Recomendada |
|---|---|---|
| Adoção | Percentual de usuários ativos versus total de licenças | Semanal no primeiro mês |
| Qualidade dos Dados | Campos obrigatórios ausentes, duplicidades | Antes do Go Live e uma vez por mês |
| Desempenho do Processo | Tempo de manuseio de Lead/Negócio versus Baseline | Mensal nos primeiros três meses |
| Falhas | Número de chamados de suporte e taxa de reabertura | Diário durante o período de Hypercare |
Organizações que optam por um acompanhamento profissional ao longo de toda essa jornada, desde o Discovery até o encerramento do Hypercare, podem utilizar o serviço de Implementação Salesforce para garantir que cada etapa receba o produto, a aprovação e o controle de risco adequados antes de prosseguir para a próxima fase.
Recursos Profissionais
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Implementação Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – Metodologia de Trabalho — https://hpi.pro/methodology