Toda empresa tem uma história sobre a ferramenta que ninguém usa. Ela foi escolhida com cuidado, venceu três concorrentes na avaliação, a integração funciona, as licenças são renovadas todo ano, e o trabalho de verdade continua acontecendo em uma planilha que alguém mantém à mão. Nada quebrou. A implantação simplesmente fracassou em silêncio e, como fracassou em silêncio, ninguém precisou dar explicações.
Esse é o ponto que vale entender sobre a implantação de software: o risco quase nunca é técnico. A parte técnica é um problema resolvido: provisionamento, SSO, permissões e migração de dados são difíceis, mas são engenharia, e engenharia termina. O que não termina sozinho é a parte em que algumas centenas de pessoas que eram perfeitamente produtivas na terça passada aceitam ficar, por um tempo, mais lentas e piores no próprio trabalho em troca de um benefício que outra pessoa descreveu para elas em uma reunião de kick-off. Um plano de implantação de software existe para tornar essa troca suportável.
Este guia é a versão prática. O que um plano de implantação precisa conter, por que o rollout de software fracassa nas semanas depois do go-live e não durante ele, como escolher entre uma estratégia big bang e um rollout em fases, um processo em oito etapas que você pode copiar inteiro, como dimensionar e controlar as suas ondas, as métricas de adoção que significam alguma coisa e como entregar a orientação dentro do próprio software, que é a diferença entre uma implantação que se sustenta e uma que se desfaz assim que o treinamento acaba.
Principais conclusões
- A instalação termina quando o software funciona; a implantação termina quando as pessoas o usam. A maioria dos planos é um cronograma de instalação com uma data de go-live e nenhum plano de adoção por trás.
- O rollout em fases vence o big bang, a menos que uma dependência rígida imponha uma única data. As ondas permitem corrigir os problemas de cada grupo antes que o próximo os encontre e mantêm a carga de suporte dentro do que o seu helpdesk consegue absorver.
- Cada onda precisa de um gate de go/no-go com números reais. "A onda 2 começa no dia 14" é um calendário. "A onda 2 começa quando 70% da onda 1 tiver concluído a tarefa principal" é um plano.
- O treinamento se perde; a orientação dentro do app, não. Uma sessão assistida duas semanas antes do go-live já foi quase toda esquecida quando chega a hora de usar; a orientação que aparece no momento da tarefa continua funcionando, inclusive para quem entra na empresa no sexto mês.
- Licenças atribuídas não são uma métrica de adoção. Meça alcance, ativação, profundidade e durabilidade, e fique de olho no retorno silencioso à ferramenta antiga.
- Defina cedo a data de aposentadoria. Uma implantação sem data de fim para o jeito antigo vira uma operação em paralelo permanente, que é o resultado mais caro possível.
O que é implantação de software? (E o que um plano de implantação contém)
A implantação de software é o processo planejado de colocar uma nova ferramenta nas mãos das pessoas que vão usá-la e fazer com que elas realizem nela o trabalho de verdade. A distinção que importa, e que a maioria dos planos confunde, é entre a instalação técnica e o rollout.
Implantação de software, definida. A instalação é um evento técnico: termina quando o software está instalado, acessível e funcionando. O rollout é um evento de comportamento: termina quando os usuários previstos realizam o trabalho previsto na nova ferramenta sem precisar de ajuda para isso. Dá para ter uma instalação impecável e um rollout fracassado; na verdade, esse é o modo de fracasso mais comum.
Ou seja, um plano de implantação não é um cronograma de projeto com uma data de go-live. Um plano utilizável responde por escrito a oito perguntas e, se não consegue respondê-las, é um cronograma de instalação usando o nome de plano de implantação:
| A pergunta | O que um plano fraco diz | O que um plano utilizável diz |
|---|---|---|
| Para que serve isto? | "Modernizar a nossa stack" | "Reduzir o prazo de resposta de orçamentos de 3 dias para o mesmo dia, para as 60 pessoas de Sales Ops" |
| Quem é afetado, e em que ordem? | "Todo mundo, no dia 1º" | Ondas nomeadas, dimensionadas e sequenciadas, com um responsável por onda |
| O que cada grupo precisa fazer no primeiro dia? | "Entrar e explorar" | As duas ou três tarefas que substituem o fluxo de trabalho atual, listadas por função |
| Como as pessoas vão aprender? | "Sessão de treinamento de 90 minutos" | Orientação dentro da ferramenta no momento da tarefa, mais uma sessão curta para dar contexto |
| A quem recorrer quando algo quebrar? | "Abra um chamado" | Um multiplicador nomeado por equipe, um caminho de ajuda dentro do app e um SLA em que as pessoas acreditam |
| O que estamos medindo? | "Licenças atribuídas" | Alcance, ativação, profundidade e durabilidade, com limites por onda |
| E se uma onda falhar? | (sem resposta) | Um gate de go/no-go explícito, e o que será corrigido antes da próxima onda |
| Quando o jeito antigo deixa de existir? | (sem resposta) | Uma aposentadoria com data, anunciada desde o início e cumprida |
Existem alguns tipos de rollout, e o formato do plano muda um pouco em cada um: o rollout interno de uma nova ferramenta para os funcionários, o rollout de migração, que substitui algo de que as pessoas já dependem (o mais difícil: você está competindo com um hábito que funciona), e o rollout de funcionalidade dentro de um produto que os seus usuários já têm, que se parece mais com anunciar uma nova funcionalidade do que com uma implantação completa. O processo em oito etapas abaixo foi escrito para os dois primeiros; a maior parte dele vale também para o terceiro, em escala menor.
Por que a implantação de software fracassa (quase nunca é culpa do software)
As análises de implantações fracassadas costumam culpar a ferramenta, porque a ferramenta não pode se defender. As causas reais são tediosamente consistentes, e todas podem ser evitadas ainda no planejamento:
-
O "porquê" foi escrito para quem comprou, não para quem usa
O business case que justificou a compra (consolidação, economia de licenças, relatórios melhores para a liderança) muitas vezes não tem interesse nenhum para a pessoa a quem se pede que mude. Se a resposta para "o que eu ganho com isso?" é "a diretoria ganha um dashboard mais bonito", as pessoas vão cumprir o mínimo necessário para não ter problemas, o que parece adoção em um relatório de licenças e não tem nada de adoção na prática.
-
O treinamento aconteceu semanas antes de alguém precisar dele
A sequência padrão (uma sessão de treinamento, depois um intervalo, depois o go-live) é pensada em torno da agenda do instrutor, não da memória humana. Quando a tarefa finalmente aparece, quase tudo da sessão já se perdeu, e o que sobra é a vaga sensação de que aquilo foi explicado uma vez e que perguntar de novo seria constrangedor. A orientação entregue no momento da tarefa não tem esse problema, e esse é todo o argumento para colocá-la dentro da ferramenta.
-
O jeito antigo continuava funcionando
Toda implantação compete com uma alternativa que funciona: a planilha, a caixa de e-mail compartilhada, o modelo pessoal que vem dando conta há quatro anos. Enquanto voltar atrás for possível e mais rápido, uma parcela significativa das pessoas vai voltar, não por resistência, mas porque tinha um prazo para entregar naquela tarde. Implantações que nunca definem uma data de aposentadoria para o jeito antigo estão escolhendo, em silêncio, a operação em paralelo permanente.
-
Conseguir ajuda era mais difícil do que desistir
A hora da verdade é um funcionário travado às 16h. Se pedir ajuda significa achar um PDF, pesquisar na intranet ou abrir um chamado com SLA de dois dias, a decisão racional é voltar à ferramenta antiga. Isso é fricção do usuário comum, e ela se acumula: cada travamento sem solução torna a próxima tentativa menos provável.
-
Ninguém mediu comportamento, só esforço
Licenças atribuídas, sessões realizadas, taxas de presença: tudo isso mede o que a equipe de implantação fez, nada disso mede o que os funcionários fazem. Uma implantação pode reportar 100% em cada um desses números enquanto o trabalho real não saiu do lugar. Sem métricas de comportamento, o fracasso fica invisível até a renovação do contrato.
-
Houve um lançamento, mas não houve um segundo mês
Atenção, orçamento e tempo dos multiplicadores ficam todos concentrados no dia do go-live. Mas as perguntas que decidem se uma implantação se sustenta chegam entre a terceira e a oitava semana: os casos extremos, o processo trimestral que ninguém ensaiou, a pessoa contratada no sexto mês que perdeu todas as sessões. Planos que terminam no go-live estão planejando a metade fácil.
Repare no padrão: cinco das seis causas tratam do que acontece depois que o software já funciona. É por isso que a lacuna de adoção se mede em comportamento, não em instalação, e por isso ela se abre em quatro pontos previsíveis.
Big bang vs. rollout em fases: como escolher a estratégia de implantação
Na prática, existem só duas estratégias de rollout de software, mais um híbrido que vale conhecer. A escolha define todo o resto do plano: o cronograma, o dimensionamento do suporte, quanto tempo de operação em paralelo você tolera e quanto consegue aprender antes de estar comprometido.
Um rollout big bang migra todo mundo na mesma data. Um rollout em fases migra as pessoas em ondas, cada uma atrás de um ponto de decisão. O modelo mental tentador é "big bang é arriscado, em fases é seguro", mas não é bem isso: a diferença real é quando você descobre os problemas. O big bang concentra toda a descoberta em uma única semana, em escala total. O rollout em fases a distribui no tempo e dá a você a chance de corrigir as coisas entre um grupo e outro.
| Estratégia | Como funciona | Escolha quando | O custo |
|---|---|---|---|
| Big bang | Todos migram em uma única data; o sistema antigo passa a ser somente leitura ou é desligado | O sistema tem uma única base de dados compartilhada que não pode ser dividida (folha de pagamento, ERP, um único livro contábil), ou um prazo contratual ou regulatório impõe a data | Todos os problemas chegam ao mesmo tempo e em escala total, sem ensaio e com uma fila de suporte que você não tem como dimensionar |
| Em fases (por onda) | Um piloto e depois grupos cada vez maiores, cada um atrás de um gate de go/no-go | O padrão. Sempre que o trabalho puder ser dividido por equipe, região ou conta sem quebrar um processo compartilhado | Semanas de operação em paralelo; dois conjuntos de instruções; exige disciplina para realmente segurar um gate |
| Em fases (por funcionalidade) | Todos recebem a nova ferramenta, mas para um fluxo de trabalho de cada vez | A ferramenta substitui vários fluxos e um deles é claramente a vitória mais fácil | As pessoas vivem em duas ferramentas ao mesmo tempo, o que confunde de outro jeito; sequencie com rigor |
| Operação em paralelo | Os dois sistemas são usados para o mesmo trabalho, de propósito, por um período fixo | O resultado precisa ser conciliado e comprovadamente idêntico (financeiro, regulatório) | Trabalho em dobro: só se justifica com uma data de fim rígida, ou vira permanente |
A armadilha do híbrido. "Vamos fazer um rollout em fases, mas todo mundo recebe acesso no primeiro dia para quem estiver animado poder começar antes" soa generoso e, em silêncio, vira um big bang. O acesso é o rollout. Se a onda 3 consegue entrar durante a onda 1, você não sequenciou nada; só escalonou os e-mails.
O plano de implantação de software em 8 etapas
O processo abaixo parte de um rollout em fases de uma ferramenta que substitui um jeito de trabalhar já existente, o caso mais comum e o mais difícil. As etapas 1 a 4 acontecem antes que qualquer pessoa de fora do projeto veja o software; as etapas 5 a 8 são o rollout propriamente dito.
- Defina o resultado nos termos dos usuários, não nos de quem comprou
- Mapeie o público e as tarefas do primeiro dia por função
- Escolha a estratégia e desenhe as ondas
- Prepare o ambiente, os dados e a orientação
- Conduza o piloto e recrute os céticos
- Lance cada onda atrás de um gate
- Dê suporte nas semanas do meio, onde as implantações realmente morrem
- Aposente o jeito antigo e passe para a operação normal
1. Defina o resultado nos termos dos usuários
Escreva uma frase que nomeie o grupo, o trabalho e a mudança: "Sales Ops entrega um orçamento personalizado no mesmo dia, e não em três dias." Essa frase precisa sobreviver ao contato com quem faz o trabalho; se um especialista em orçamentos a ler e pensar "isso deixaria minhas terças muito melhores", você tem uma implantação. Se ele ler e pensar "isso é uma métrica da diretoria", você tem um exercício de compliance, e deveria encontrar a versão do benefício que é verdadeira para ele antes de seguir em frente. Geralmente ela existe; só não é a que está no business case.
Anote também o contra-argumento, com honestidade: o que vai piorar nas primeiras semanas. Sempre piora alguma coisa. Dizer isso logo de início não custa nada e lhe dá a credibilidade de que você vai precisar na terceira semana, quando acontecer.
2. Mapeie o público e as tarefas do primeiro dia
Liste todos os grupos afetados e, para cada um, as duas ou três tarefas que precisam conseguir concluir no primeiro dia na ferramenta, descritas como trabalho e não como funcionalidade ("emitir uma nota de crédito", e não "usar o módulo de faturamento"). Essa lista é a espinha dorsal de tudo o que vem depois: decide o que o piloto testa, o que a orientação cobre, o que "ativação" significa nas suas métricas e o que o gate de cada onda mede.
Seja implacável e mantenha a lista curta. Dez tarefas para o primeiro dia são um currículo, e um currículo não será aprendido. Três são uma implantação. Todo o resto fica para o segundo mês e pode ser ensinado na ferramenta mais tarde, quando for necessário: a mesma lógica do onboarding progressivo, que ensina um produto ao longo do tempo em vez de tudo de uma vez.
Depois, segmente. Um controller financeiro, um técnico de campo e um líder de equipe não precisam da mesma implantação, e dar aos três o mesmo walkthrough genérico é o jeito de tornar a orientação irritante para todo mundo. Agrupar as pessoas pelo que elas realmente precisam fazer, a mesma disciplina da segmentação de usuários no trabalho de produto, é o que torna possível, mais tarde, uma orientação segmentada dentro do app.
3. Escolha a estratégia e desenhe as ondas
Escolha entre big bang e rollout em fases usando a tabela acima e, se for em fases, dimensione as ondas. Um padrão que funciona: um piloto com cerca de 5–10% dos usuários e depois ondas que mais ou menos dobram de tamanho, de modo que cada grupo seja maior que o anterior, mas nunca tão grande que uma semana ruim vire um problema da empresa inteira. Duas semanas entre as ondas é um bom espaçamento inicial: tempo suficiente para os problemas tardios aparecerem e curto o bastante para manter o embalo.
Em seguida, defina o gate de cada onda antes que ela comece, em números. Não "a onda 2 começa no dia 14", mas "a onda 2 começa quando 70% da onda 1 tiver concluído a tarefa principal pelo menos duas vezes e os chamados abertos estiverem abaixo de X". Um gate definido com antecedência é uma decisão; um gate avaliado depois do fato é uma racionalização.
5–10% dos usuários
~25% dos usuários
Todos os demais
4. Prepare o ambiente, os dados e a orientação
A lista de prontidão técnica é conhecida: acesso e SSO, permissões por função, integrações e (o item que derruba mais implantações do que qualquer outro) os dados e as configurações salvas de que as pessoas dependem. Se os doze filtros salvos de alguém, os modelos ou três anos de histórico não forem migrados, essa pessoa vai manter a ferramenta antiga aberta, diga o plano o que disser. Migrar os cinco principais artefatos de cada função vale mais do que uma semana de treinamento.
Prepare a orientação ao mesmo tempo, não depois, e decida onde ela vai ficar. Uma apresentação e um PDF são um ponto de partida defensável, mas a única orientação com uma vida útil razoável é a que aparece na ferramenta no momento da tarefa: um product tour curto no primeiro login, um checklist das tarefas do primeiro dia que acompanha o próprio progresso, tooltips nos quatro campos que todo mundo preenche errado e um caminho de ajuda dentro do app para que travar nunca signifique sair da tela.
5. Conduza o piloto e recrute os céticos
Um piloto formado só por voluntários mostra como a implantação será para quem queria a ferramenta. Essa é a população menos útil que você poderia consultar. Inclua de propósito duas ou três pessoas que acham tudo isso uma perda de tempo; elas vão encontrar o fluxo que a ferramenta resolve mal, e é muito melhor descobrir isso por cinco pessoas na segunda semana do que por trezentas na sexta.
Conduza o piloto com a lista real de tarefas do primeiro dia, observe onde as pessoas travam e corrija a orientação antes da onda 2, em vez de jogar tudo para o backlog. O resultado do piloto não é um sinal de positivo; é uma lista de reparos específicos (três tooltips, uma etapa reescrita, um modelo migrado, um fluxo que o fornecedor precisa confirmar) e evidências para o gate.
6. Lance cada onda atrás de um gate
Cada onda recebe o mesmo pacote: uma mensagem curta de alguém a quem o grupo realmente se reporta (não da equipe do projeto) explicando o que muda e quando o jeito antigo acaba, acesso liberado no dia, a orientação dentro do app segmentada para aquela onda, um multiplicador nomeado presente e um caminho de suporte visível. Depois, você acompanha os números em relação ao gate definido na etapa 3.
Segurar um gate quando os números estão ruins é a disciplina mais difícil e mais valiosa de uma implantação. É também a mais barata: adiar a onda 3 em uma semana custa uma semana, enquanto lançar a onda 3 contra um problema conhecido e não corrigido custa a credibilidade de que você vai precisar em todas as implantações depois desta.
7. Dê suporte nas semanas do meio, onde as implantações realmente morrem
A capacidade de suporte quase sempre é planejada em torno do dia do go-live, que é o dia errado. As perguntas que importam chegam entre a segunda e a sexta semana: o processo mensal que ninguém ensaiou, o fechamento trimestral, o caso extremo de um cliente, a pessoa que estava de férias durante todo o lançamento. Dimensione o suporte para isso e mantenha os multiplicadores ativos depois dos aplausos.
É também aqui que a orientação dentro do app se paga duas vezes. Cada pergunta recorrente é um tooltip ou uma etapa que você pode adicionar naquela mesma semana (sem release, sem novo treinamento), e cada novo funcionário depois disso recebe automaticamente a versão corrigida. Esse é o mecanismo que transforma uma implantação em adoção digital duradoura, e não em um lançamento que se desfaz.
8. Aposente o jeito antigo e passe para a operação normal
Anuncie a data de aposentadoria no início da implantação, não no fim, e depois cumpra-a de verdade: primeiro somente leitura, depois desligado. Cada semana em que a ferramenta antiga continua totalmente disponível é uma semana em que a implantação é opcional, e implantações opcionais se estabilizam no nível de adoção que a equipe menos convencida decidir.
Depois, faça a passagem direito: alguém passa a ser dono da orientação dentro do app, as tarefas do primeiro dia entram no onboarding de novos funcionários e o dashboard de adoção ganha um leitor nomeado com um horário mensal reservado. Uma implantação sem dono depois do go-live é uma implantação que vai precisar ser refeita em dezoito meses.
O cronograma da implantação: o que acontece em cada fase
O cronograma é a parte do plano de implantação para a qual as pessoas mais querem um modelo, e é justamente onde um modelo mais engana: uma ferramenta para 40 pessoas e um ERP para 4.000 não compartilham o mesmo calendário. O que se transfere é o formato: uma fase de preparação mais longa do que qualquer um orça, ondas espaçadas pelo aprendizado e não pela conveniência, e uma cauda de suporte que dura mais do que o lançamento.
Duas coisas nesse formato são sempre subestimadas. A primeira é a preparação: a migração de dados e a orientação levam mais tempo do que a instalação, e ambas estão no caminho crítico para o sucesso da onda 1. A segunda é a faixa de suporte; repare que ela não está centrada em nenhum dia de lançamento. Ela cobre o meio do processo, porque é nessa hora que as perguntas difíceis aparecem.
Um teste útil para o seu cronograma. Pergunte o que, especificamente, teria que acontecer para você adiar a onda 3 em uma semana. Se não houver resposta, as ondas não têm gates; são só datas, e a implantação vai seguir na mesma velocidade, esteja funcionando ou não.
O que medir durante e depois de uma implantação de software
A falha de medição na maioria das implantações não é deixar de acompanhar as coisas; é acompanhar o que mede a atividade da equipe de implantação em vez do comportamento dos funcionários. Licenças atribuídas, sessões realizadas, presença, e-mails enviados: tudo isso pode chegar a 100% em uma implantação que não mudou nada. Quatro camadas, nesta ordem, resolvem isso.
| Camada | A pergunta | O que medir | Quando deve se mexer |
|---|---|---|---|
| Alcance | As pessoas apareceram? | % da onda que entrou pelo menos uma vez | Dias 1–5 da onda |
| Ativação | Fizeram o que importa? | % que concluiu a tarefa do primeiro dia: o trabalho, não o tour | Semanas 1–2 da onda |
| Profundidade | Estão usando aquilo em que o business case se apoia? | Uso semanal dos dois ou três fluxos que justificam a ferramenta | Semanas 2–6 |
| Durabilidade | O hábito se manteve? | Ainda ativos nas semanas 4 e 8; retorno à ferramenta antiga | Semanas 4–12 |
Ao lado delas, dois sinais operacionais dão o alerta mais precoce de problemas. O tempo até a primeira tarefa bem-sucedida, ou seja, quanto tempo passa entre o primeiro login e a primeira entrega de trabalho real, é o equivalente interno do time to value, e quando ele se alonga, tudo o que vem depois cai junto. E os chamados de suporte por cem usuários em cada onda devem diminuir de uma onda para a outra; se a onda 3 gera a mesma taxa de chamados que o piloto, nada do que você aprendeu no caminho foi de fato corrigido.
Olhe para a distribuição, não só para a média. Uma implantação com 68% de ativação pode estar saudável de modo geral ou ser dois departamentos com 95% e um com 12%, e esses casos pedem respostas completamente diferentes. A equipe com 12% costuma ter um motivo específico: um fluxo que a ferramenta resolve mal, um gestor que nunca comprou a ideia ou uma migração que deixou de fora algo de que eles precisavam. As médias escondem justamente aquilo que você pode corrigir.
Implantação de software: faça e não faça
✓ Faça
- Escreva o benefício com as palavras de quem faz o trabalho e diga o que vai piorar primeiro
- Reduza a lista de tarefas do primeiro dia a três itens por função
- Coloque os céticos no piloto de propósito
- Defina o gate de cada onda em números antes de a onda começar
- Migre os filtros salvos, os modelos e o histórico de que as pessoas realmente dependem
- Entregue a orientação dentro da ferramenta, no momento da tarefa
- Dimensione o suporte para as semanas 2–8, não para o dia do lançamento
- Anuncie no início a data de aposentadoria do sistema antigo, e cumpra-a
- Dê à orientação e ao dashboard de adoção um dono nomeado depois do go-live
✗ Não faça
- Reportar licenças atribuídas como métrica de adoção
- Fazer o treinamento três semanas antes de alguém poder usar a ferramenta
- Deixar a onda 3 ter acesso durante a onda 1; isso é um big bang com e-mails extras
- Montar o piloto só com voluntários e entusiastas
- Tratar o gate como formalidade depois que a data entrou no calendário
- Deixar a ferramenta antiga totalmente disponível por tempo indeterminado "por via das dúvidas"
- Lançar um único walkthrough genérico para todas as funções
- Julgar a implantação pela média da empresa e não ver o departamento com 12%
- Encerrar o plano no go-live
Como fazer uma implantação de software sem tempo de engenharia
O item mais difícil de um plano de implantação costuma ser a orientação, porque os jeitos óbvios de produzi-la são todos ruins. Documentação que ninguém lê é barata e inútil. O treinamento ao vivo é caro, se perde em poucos dias e precisa ser repetido para cada pessoa nova. E incorporar a ajuda ao próprio software raramente está ao seu alcance: se é o produto de um fornecedor, você não pode alterá-lo, e se é interno, você está disputando tempo dos desenvolvedores com o roadmap.
O Kompassify existe exatamente para essa lacuna: ele adiciona uma camada de orientação por cima de um software que você já usa, sem mexer no código dele.
- Orientação em qualquer aplicação web, sem ciclo de release. Adicione product tours, tooltips e hotspots à ferramenta que os seus funcionários estão usando, criados em um editor visual sobre a sua aplicação em produção. Sem desenvolvedor, sem janela de deploy.
- As tarefas do primeiro dia como um checklist que acompanha o próprio progresso. Um checklist de onboarding transforma as suas três tarefas do primeiro dia em um progresso visível e salvo por pessoa, então quem for interrompido no meio da configuração volta para onde parou, e não para o começo.
- Segmentação que acompanha as suas ondas. Mostre a cada onda, departamento ou função apenas a orientação feita para ela, e ative uma onda mudando quem está no público-alvo, não repetindo uma sessão de treinamento.
- Anúncios para os marcos. Datas das ondas, novos fluxos de trabalho e a aposentadoria do sistema antigo podem ser comunicados dentro da ferramenta, onde as pessoas já estão, em vez de em uma conversa de e-mail que elas silenciaram.
- Analytics por etapa. Os relatórios integrados mostram a conclusão e o abandono em cada etapa de cada fluxo, então a orientação da onda 2 é uma versão reparada da orientação da onda 1, e não uma reescrita esperançosa.
- Orientação que continua funcionando depois da implantação. A pessoa que entra no sexto mês recebe o mesmo primeiro dia guiado que a onda 1 recebeu, sem ninguém precisar agendar nada.
O Kompassify está em conformidade com o GDPR e hospedado na UE, é gratuito para menos de 100 usuários ativos mensais e tem planos pagos a partir de US$ 129/mês, o que significa que você pode conduzir uma onda piloto inteira antes mesmo de a implantação ter uma linha no orçamento.
Faça da nova ferramenta a opção mais fácil
O Kompassify adiciona product tours, checklists, tooltips e anúncios por cima do software que as suas equipes já usam: sem código, sem ciclo de release, segmentado onda a onda e medido etapa por etapa. Dê a cada funcionário um primeiro dia guiado, inclusive a quem entrar seis meses depois do go-live. Em conformidade com o GDPR, hospedado na UE e gratuito para menos de 100 usuários ativos mensais.
Comece grátis →Perguntas frequentes
O que é implantação de software?
Implantação de software (ou rollout de software) é o processo planejado de colocar uma nova ferramenta nas mãos das pessoas que vão usá-la e fazer com que elas realmente a usem no trabalho do dia a dia. É algo mais amplo do que a instalação: a instalação é um evento técnico que termina quando o software está instalado e acessível, enquanto a implantação só termina quando os usuários previstos fazem o trabalho previsto na nova ferramenta sem precisar de ajuda. Por isso, um plano de implantação cobre o público e a sequência, a migração de dados e fluxos de trabalho, a orientação e o treinamento que as pessoas recebem, o caminho de suporte quando elas travam, as métricas de adoção acompanhadas e a data em que a ferramenta antiga é desligada.
O que um plano de implantação de software deve conter?
Um plano de implantação de software utilizável responde por escrito a oito perguntas: para qual resultado serve a implantação (nos termos do negócio, não da ferramenta), quem é afetado e em que ordem, o que cada grupo precisa conseguir fazer no primeiro dia, como vai aprender isso, a quem recorrer quando algo quebrar, o que será medido e com quais limites, o que acontece se uma onda não passar no seu gate e quando o jeito antigo será aposentado. Todo o resto (cronogramas do fornecedor, contagem de licenças, diagramas de integração) é detalhe de apoio. Se essas oito respostas não existem, o plano é um cronograma de instalação usando o nome de plano de implantação.
Qual é a diferença entre um rollout big bang e um rollout em fases?
Um rollout big bang migra todo mundo para o novo software na mesma data; um rollout em fases migra as pessoas em ondas: primeiro um grupo piloto, depois grupos cada vez maiores, cada um atrás de uma decisão de go/no-go. O big bang é mais rápido, evita manter dois sistemas em paralelo e é a escolha honesta quando a ferramenta é de fato tudo ou nada (uma virada de folha de pagamento, um sistema com uma única base de dados compartilhada). O custo é que todos os problemas chegam de uma vez, em escala total, sem ensaio. Um rollout em fases leva mais tempo e exige um período de operação em paralelo, mas cada onda ensina algo que você pode corrigir antes da próxima, e a carga de suporte fica dentro do que o seu helpdesk consegue absorver. A menos que uma dependência rígida imponha uma única data de virada, o rollout em fases é o padrão de menor risco.
Como implantar um novo software para os funcionários?
Defina o resultado desejado em termos de negócio, mapeie quem é afetado e o que cada grupo precisa conseguir fazer, escolha uma estratégia de rollout (geralmente em fases), recrute um grupo piloto que inclua os céticos além dos entusiastas, prepare o ambiente e migre os dados e fluxos de que as pessoas dependem, coloque a orientação dentro da própria ferramenta e não só em uma apresentação ou PDF, conduza cada onda atrás de um gate de go/no-go com métricas reais de adoção e só então aposente o jeito antigo. O maior indicador de sucesso é onde a ajuda está: o que as pessoas aprendem em uma sessão de treinamento se perde em poucos dias, enquanto a orientação que aparece dentro da ferramenta no momento da tarefa continua funcionando para cada novo funcionário.
Por que as implantações de software fracassam?
Quase nunca porque o software não funciona. As implantações fracassam porque os funcionários nunca receberam um motivo para mudar que fizesse sentido do ponto de vista deles, porque o treinamento aconteceu semanas antes de alguém precisar dele, porque a nova ferramenta ainda não fazia a única coisa que o antigo jeitinho fazia bem, porque conseguir ajuda era mais lento do que voltar ao jeito antigo ou porque ninguém mediu nada além das licenças atribuídas. O fracasso é silencioso: o software continua instalado, as licenças continuam pagas e o trabalho segue, discretamente, em planilhas e e-mails. É por isso que um plano de implantação precisa de métricas de adoção e de uma data explícita de aposentadoria do jeito antigo, não apenas de uma data de go-live.
Quais métricas acompanhar durante uma implantação de software?
Acompanhe quatro camadas, nesta ordem. Alcance: quantos dos usuários previstos entraram pelo menos uma vez. Ativação: quantos concluíram a primeira tarefa real para a qual a implantação existe; não um tour, o trabalho de verdade. Profundidade: quantos usam semanalmente os dois ou três fluxos que sustentam o business case. Durabilidade: quantos ainda fazem isso quatro e oito semanas depois, e quantos voltaram discretamente à ferramenta antiga. A carga de suporte por onda e o tempo até a primeira tarefa bem-sucedida entram ao lado delas como sinais de alerta precoce. Licenças atribuídas e presença nos treinamentos não são métricas de adoção; elas medem o seu esforço, não o comportamento dos funcionários.
Quanto tempo deve durar uma implantação de software?
O suficiente para aprender entre uma onda e outra, e pouco o bastante para que a mudança não perca o embalo. Para uma ferramenta departamental, um formato comum é de uma a duas semanas de piloto, depois de duas a quatro ondas espaçadas por cerca de duas semanas, com o sistema antigo aposentado de quatro a oito semanas após a última onda. O espaçamento importa mais do que o total: cada intervalo precisa ser longo o bastante para que os problemas da onda apareçam (a maioria dos chamados de suporte chega vários dias depois do go-live, não no próprio dia) e para que você corrija a orientação antes que o próximo grupo bata no mesmo muro. Implantações que passam de um trimestre tendem a estagnar, porque a operação em paralelo vira o novo normal e ninguém se sente obrigado a mudar.
Como treinar funcionários em um novo software sem desenvolver nada?
Coloque o treinamento dentro da ferramenta, e não ao lado dela. Com uma plataforma de adoção digital no-code como o Kompassify, você adiciona product tours, tooltips, checklists e anúncios por cima do software que os seus funcionários já usam, criados em um editor visual sobre a sua aplicação em produção, segmentados para a onda ou o departamento em implantação e publicados sem ciclo de release e sem desenvolvedor. Quem entrar meses depois recebe a mesma orientação sem que ninguém precise repetir uma sessão de treinamento, e o analytics integrado mostra exatamente em qual etapa as pessoas desistem. O Kompassify está em conformidade com o GDPR e hospedado na UE, é gratuito para menos de 100 usuários ativos mensais e tem planos pagos a partir de US$ 129/mês.