Projeto piloto de controle de patrimônio: testar antes de abrir para todos

Implantar para a empresa inteira de uma vez é como estrear uma peça sem ensaio. Funciona às vezes. Quando não funciona, o custo é a confiança de todo mundo no projeto.

Você escolheu o sistema. Planejou a implantação. Na segunda-feira, vira a chave para todo mundo: cinco filiais, quinhentas pessoas.

Não faça isso.

Construí o UNIO24 porque vi esse filme se repetir. A equipe escolhe a ferramenta, planeja a implantação e pula o piloto porque "não temos tempo". Depois passa seis meses remendando o sistema em produção enquanto o pessoal do campo volta em silêncio para a prancheta. As equipes que rodam um piloto de algumas semanas quase sempre entregam limpo. O padrão é brutalmente consistente.

Este guia mostra como rodar um piloto que encontra os problemas de verdade: o Wi-Fi que não chega onde o equipamento realmente fica, a etiqueta que apaga em duas semanas, a movimentação que leva cinco minutos quando deveria levar trinta segundos. Teste pequeno, encontre os defeitos enquanto são baratos e implante com o risco já drenado.

Por que o piloto não é opcional

Piloto parece burocracia. É mitigação de risco disfarçada de processo.

O piloto não existe para provar que o sistema funciona: isso o fornecedor já provou na demonstração. Ele existe para descobrir como a sua operação vai usar o sistema, e onde o processo que você desenhou no papel não sobrevive ao contato com a realidade.

Um bom piloto cumpre cinco funções. Expõe problemas técnicos antes que virem desastre: o Wi-Fi que não alcança o fundo do almoxarifado, o servidor que não aguenta cinquenta leituras simultâneas. Revela atritos de fluxo que ninguém previu, como o de quem tenta escanear de luva. Cria um ciclo de feedback enquanto ainda dá para trocar de sistema, ajustar a estratégia de etiquetagem ou refazer a estrutura de dados — depois da implantação geral, você está preso ao que escolheu. Forma multiplicadores: quem ajudou a moldar o processo no piloto é quem o defende na expansão. E demonstra retorno antes de assinar o contrato anual, exatamente o que uma diretoria cética precisa ver.

O que o piloto encontra, quase sempre:

• o campo obrigatório que ninguém consegue preencher no ato da entrega;
• o lugar do galpão onde não há sinal e o aplicativo precisa funcionar offline;
• a etapa que faz sentido para quem desenhou e nenhum sentido para quem executa;
• a etiqueta que descola justamente no equipamento que mais circula.

Descobrir isso com 80 itens custa uma tarde. Descobrir com 3.000 custa a credibilidade do projeto.

Onde pilotar: setor, unidade ou os dois?

Não dá para pilotar "um pouco de tudo". Isso é uma implantação geral malfeita, não um piloto. O escopo precisa ser representativo o bastante para validar hipóteses e pequeno o bastante para caber na mão.

Três formatos funcionam.

Um tipo de bem, todas as unidades. Rastrear todo o parque de TI da empresa, e nada além. Funciona quando os processos são padronizados entre filiais e uma categoria de bens tem exigências próprias (TI, veículos). A limitação: você não testa como o sistema lida com variedade. Mobiliário de escritório se comporta diferente de ferramenta elétrica.

Uma unidade, todos os tipos de bem. Implantar tudo na matriz, e em nenhum outro lugar. Funciona quando as unidades diferem muito entre si: escritório, galpão, canteiro de obra, e você quer testar o espectro completo. A limitação: você não enxerga os problemas específicos de cada local, como a zona morta de Wi-Fi do almoxarifado da filial.

Híbrido. Uma unidade representativa mais duas ou três categorias de bens que cobrem usos diferentes. Exemplo: matriz + equipamentos de TI + mobiliário + ferramentas. Você ganha variedade (caro e barato, móvel e fixo, o que troca de mãos toda semana e o que nunca sai do lugar) sem estourar o escopo. É o formato que eu escolheria para a maioria das organizações.

O que faz uma boa unidade piloto

O setor certo tem três características: dor real, gente disposta e tamanho que cabe.

Dor real significa que aquela equipe já sofre com o problema: ferramenta que some, notebook que ninguém sabe onde está, inventário que toma a semana. Gente que já sofre coopera; gente que não vê problema enxerga só trabalho a mais.

Gente disposta importa mais que gente disponível. Um encarregado que compra a ideia vale mais que dois analistas designados por ordem superior. Usuários piloto resistentes condenam o projeto antes do primeiro registro.

Tamanho que cabe: uma unidade representativa da operação, acessível para resolver problemas presencialmente, de porte médio, grande o bastante para expor defeitos, pequena o bastante para administrar.

Evite dois extremos. O setor mais crítico da empresa, porque erro ali é caro demais. E o setor mais fácil, porque o resultado não convence ninguém — "claro que funcionou lá, lá é simples". Evite também unidades remotas onde você não consegue pôr a mão na operação, e qualquer área em turbulência: mudança de prédio, reestruturação, troca de gestão.

Quantos bens entram

Minha régua de bolso:

Piso: pelo menos 50 bens e 5 usuários ativos. Abaixo disso não há movimento suficiente para testar fluxos reais. Teto: no máximo 10% do parque total. Acima disso você está fazendo uma implantação geral com outro nome.

Definindo o escopo

"Vamos testar e ver o que acontece" não é plano. Escopo vago produz resultado vago. Escreva antes de começar, em uma página, quatro coisas.

Quais bens entram. Categoria e localização, explicitamente: "tudo do almoxarifado da obra 4", não "as ferramentas". Liste também o que não entra, para ninguém supor. Fronteiras físicas contam: bloco A, andares 1 a 3, incluindo o depósito, excluindo o data center. E quem participa — nome e papel de cada um, incluindo quem responde pelas dúvidas.

O que você vai medir. Critérios de sucesso definidos antes do primeiro dia: tempo para localizar um bem, percentual de bens com responsável e localização conhecidos, adoção, taxa de erro no cadastro, tempo gasto em tarefas de patrimônio. Números, não impressões — os detalhes vêm na seção de indicadores.

Quais processos entram. Não só o software: o fluxo inteiro. Cadastro e tombamento com etiquetagem, sempre. Retirada e devolução, quase sempre. Transferência entre setores, termo de responsabilidade na entrega ao colaborador, baixa de bens, e sim, uma conferência de inventário durante o próprio piloto. Manutenção e chamados, só se o setor já tem essa rotina.

O que fica de fora, por enquanto. Integração com ERP costuma ficar; ela transforma piloto em projeto. Relatórios complexos, recursos avançados sem uso imediato e personalizações incertas também ficam. É aqui que o escopo escorrega e mata pilotos: "já que estamos mexendo, vamos aproveitar e..." Se hoje o controle vive em planilha, o comparativo planilha ou sistema ajuda a situar o ponto de partida.

Prazo realista: quanto tempo o piloto deve durar

Com menos de duas semanas, você pega os problemas técnicos óbvios mas perde os atritos de fluxo que só aparecem com o tempo, e ninguém constrói hábito. Com mais de três meses, o ímpeto morre: as pessoas esquecem que é um piloto e passam a tratá-lo como algo permanente, porém quebrado — uma rotina paralela sem fim.

A faixa que funciona para a maioria das operações: quatro a oito semanas.

Semanas 1–2 são preparação e uso inicial: configurar o sistema, etiquetar os bens, importar os dados, treinar a equipe e colocá-la para trabalhar de verdade. Aqui você caça problema técnico, tropeço de usabilidade, feedback do tipo "esse botão não funciona".

Semanas 3–5 são operação real. O sistema está no dia a dia, os primeiros atritos de processo aparecem e você começa a ver quais recursos são usados e quais são ignorados. Aqui você caça fricção de fluxo, função que falta, lacuna de treinamento, dado ruim entrando.

Semanas 6–8 são avaliação: colete o feedback formal, analise os dados de uso, teste os ajustes que fez, rode um mini-inventário e decida. A pergunta aqui é se as correções pegaram e se o sistema resolve o problema que motivou tudo.

Quando comprimir

Às vezes o calendário não respeita o prazo ideal: inventário anual em seis semanas, exigência de auditoria, diretoria impaciente. Um piloto comprimido de duas a três semanas funciona, mas só com gente dedicada, um responsável experiente e requisitos simples:

• Semana 1: configuração intensiva, treinamento e primeiros testes.
• Semana 2: operação plena, com conversa diária de acompanhamento.
• Semana 3: coleta rápida de feedback e decisão.

Não comprima em ambiente complexo. O trabalho do piloto é encontrar problemas; cortar tempo significa encontrar menos.

E atenção à sazonalidade: se a operação tem pico forte (fechamento, safra, período letivo), pilote fora do pico ou aceite duas semanas com escopo reduzido. Piloto durante o pico mede o estresse da equipe, não o sistema.

Indicadores de sucesso

"O piloto deu certo?" é uma pergunta inútil. Você precisa de critérios específicos e mensuráveis, definidos antes do início. Escolha poucos, e escolha estes.

Desempenho técnico

O sistema precisa ser confiável. Mire em 99% ou mais de disponibilidade durante o piloto: se a equipe frequentemente não consegue acessar, você já perdeu. A leitura pelo celular deve completar em menos de três segundos, do QR code aos detalhes do bem; mais lento que isso, e as pessoas inventam desculpa para não escanear. A sincronização é o assassino silencioso: verifique se as leituras feitas offline realmente sobem quando o aparelho volta à rede. Leitura perdida é dado perdido, e confiança perdida não volta fácil.

Adoção

Você quer 80% ou mais dos usuários piloto ativos no sistema toda semana. Acompanhe logins e movimentações por pessoa. Se metade da equipe piloto não está usando, a implantação geral vai desabar no contato com gente normal.

Adoção é o indicador mais honesto: sistema que ninguém usa não tem outro problema a resolver.

A aderência ao processo diz se o sistema cabe no fluxo. Compare o que acontece fisicamente com o que está registrado: se as transferências não estão sendo lançadas, as pessoas estão contornando a ferramenta. O processo está quebrado — conserte agora.

Tempo até a autonomia é o indicador de aceitação de que eu mais gosto. A equipe deve executar as tarefas básicas sozinha em até dois dias. Se depois da primeira semana ainda precisa de acompanhamento, o problema está na interface ou no treinamento.

Impacto no negócio

O tempo para localizar um bem deve cair pelo menos 50%. Peça à equipe uma estimativa antes e outra depois. Se o sistema não torna mais rápido encontrar as coisas, qual é o sentido dele?

Responsabilização: 95% ou mais dos bens do piloto devem ter localização e responsável conhecidos: quem está com o quê, amparado por termo de responsabilidade quando o bem sai com alguém. Rode uma conferência física ao fim do piloto para verificar. Se você não consegue prestar contas dos bens depois do piloto, não vai conseguir depois da implantação geral.

Exatidão dos dados: 95% ou mais. Localização, status e responsável batem com a realidade na verificação física. Divergência alta na conferência final aponta processo, não sistema. Dado podre no piloto vira dado podre em produção. Conte também os bens encontrados durante o piloto: um notebook de R$ 6.000 dado como sumido que reaparece no armário da filial paga o piloto sozinho, e vende a expansão para a diretoria.

Satisfação de quem opera

70% ou mais dos usuários piloto devem recomendar a expansão. Se nem os seus adotantes entusiasmados recomendam, algo está genuinamente quebrado. A facilidade de uso percebida deve ficar em 4 ou mais numa escala de 5. E o valor percebido importa mais que tudo: escute por frases como "isso me ajuda a trabalhar melhor". Se a equipe enxerga o sistema como burocracia a mais, treinamento nenhum conserta — é problema de gestão de mudança.

Uma pergunta direta ao fim vale mais que qualquer painel: "você prefere o jeito novo ou o antigo?" A resposta e o porquê dizem quase tudo.

Coletando feedback na hora certa

Não espere o fim para perguntar "como está indo?". A essa altura, quem se frustrou já desistiu por dentro.

Na primeira semana, converse todos os dias; cinco minutos bastam. Pergunte sobre atrito: o que travou, o que não ficou claro, o que demorou mais do que devia, o que você teve que perguntar para alguém. É quando a memória do estranhamento ainda está fresca. Um botão confuso que rouba 30 segundos por leitura rouba 500 minutos ao longo do piloto — conserte agora. Adiar correção "para a implantação" é um dos erros de controle de patrimônio que eu mais vejo.

Nas semanas 2–3, passe para pesquisas semanais curtas: cinco perguntas, dois minutos. Nota de facilidade de uso de 1 a 5, qual tarefa tomou mais tempo, o que mudaria, que recurso falta, mais um campo aberto para o que você não pensou em perguntar. A pesquisa semanal revela tendência: se três pessoas pedem a mesma coisa de forma independente, importa. Pergunte também sobre rotina: o que virou hábito e o que ainda é esforço consciente.

Nas semanas 4–6, faça conversas individuais de 15 a 30 minutos com usuários representativos. Percorra o fluxo típico da pessoa: onde o sistema ajuda, onde atrapalha, se ela quer continuar usando, o que faria o sistema passar de "ok" para "excelente". Pesquisa dá dado; conversa dá entendimento — o porquê de algo ser problema, não só o fato de ser.

No fim, rode uma pesquisa final mais uma conversa em grupo. A pesquisa cobre satisfação geral (1 a 10), recomendação da expansão, as três coisas que funcionam, as três que precisam melhorar, e a pergunta de permanência: o que você mudaria antes de isso virar padrão para a empresa toda? Na conversa em grupo, deixe os usuários falarem entre si, não com você: comparando experiências e construindo em cima da ideia do outro, eles revelam o que pesquisa nenhuma captura. Mas não abra mão do individual: reunião coletiva produz consenso educado; conversa individual produz o que a pessoa realmente pensa.

Uma pergunta que eu acrescentaria a todo piloto: "se abríssemos isso para a empresa inteira amanhã, você ficaria animado ou preocupado?" Ela atravessa a cortesia e revela o sentimento real. Se os seus adotantes iniciais — a plateia mais favorável que você jamais terá — estão preocupados, você não está pronto.

Problemas que você vai encontrar

Todo piloto que já acompanhei expôs alguma versão do mesmo punhado de problemas. Conhecê-los de antemão não os evita, mas encurta o tempo que você passa confuso.

O Wi-Fi não chega onde os bens vivem. A equipe não consegue escanear em certas áreas porque não há rede. Se a leitura não funciona onde o equipamento está, o sistema é inútil. A saída é modo offline (os aplicativos modernos têm), pontos de acesso adicionais ou aparelhos com chip de dados para os cantos realmente remotos. Em qualquer caso, teste no ambiente físico real, não no escritório. Mapa de calor de Wi-Fi mente.

Registrar uma movimentação demora demais. Quando o fluxo digital é mais lento que o jeito antigo, a adoção morre. Identifique quais etapas travam, não presuma. Corte campos desnecessários (precisa mesmo dos 15 para uma transferência?). Habilite ações em lote para transferir dez itens de uma vez. Prefira leitura de código a digitação. Cronometre cada fluxo de rotina; se passa de três cliques e 30 segundos, simplifique até caber.

Campo demais no cadastro. A tentação de capturar tudo desde o começo trava a operação. O mínimo viável é código, descrição, categoria, localização e responsável. O resto entra depois.

A etiqueta descola, apaga ou para de ler. A plaqueta não sobrevive ao ambiente. Se você não consegue ler a etiqueta, não consegue rastrear o bem, e o esforço de tombamento foi desperdiçado. Teste a durabilidade nas condições reais: cole uma etiqueta num equipamento que circula e veja como ela está em duas semanas. Troque papel por poliéster, use plaqueta metálica em ambiente agressivo e laminação em item de alto manuseio; NFC vale considerar onde código impresso não dura. O guia de boas práticas de etiquetagem cobre isso a fundo, e o comparativo QR code, NFC ou RFID ajuda a escolher. E observe a posição: se na primeira conferência a pessoa procura a etiqueta antes de ler, a posição está errada para aquele tipo de bem.

Ninguém sabe em qual categoria o bem entra. "Teclado sem fio é Equipamento de TI ou Material de Escritório?" Categorização inconsistente destrói relatório e inviabiliza busca. Crie uma árvore de decisão simples ("liga na tomada → TI; você senta em cima → mobiliário; tem motor → equipamento"). Reduza o total de categorias: dez é melhor que quarenta e sete. Dê exemplos para cada uma e deixe o usuário marcar "não tenho certeza" em vez de forçá-lo a chutar errado. A sua estrutura de categorias faz todo o sentido para você, e confunde todo mundo que não é você.

O processo não tem dono. "Quem cadastra o equipamento novo?" costuma ficar sem resposta clara até o piloto forçar a pergunta. Nomeie o dono de cada processo antes que a dúvida vire fila.

Os usuários piloto não perceberam que era para usar de verdade. Participação passiva não testa nada. Deixe a expectativa explícita na abertura, faça da participação parte do trabalho da pessoa durante o piloto, não algo espremido nas sobras do dia —, nomeie um coordenador que acompanha com frequência e celebre participação, não só resultado. Fique atento à variante silenciosa: ninguém reclama e ninguém usa. É o pior sinal, e só aparece se você olhar o indicador de adoção em vez de perguntar se está tudo bem.

Os dados já nasceram errados. Importar o cadastro antigo sem limpar primeiro faz o piloto começar com lixo, e a equipe perde a confiança de imediato. Limpe os dados antes da largada; o guia de migração e limpeza de dados percorre o passo a passo. Confira uma amostra antes de importar tudo e rode um mini-inventário na primeira semana para pegar erro enquanto é administrável. Seja transparente com a equipe: "sabemos que parte dos registros está errada, ajude a achar e corrigir" cria colaboração; "este é o novo sistema oficial" cria frustração.

O que funciona no piloto e quebra na escala

Esta é a armadilha que já vi arruinar piloto bem-sucedido: 20 usuários engajados, dados excelentes, elogios, e aí vêm 500 usuários na expansão e tudo desmonta. Escala pequena e escala grande não são o mesmo jogo.

Suporte. No piloto, quem tem dúvida pergunta para o analista da implantação. Com 500 usuários, esse analista afunda: o tempo de resposta vai de cinco minutos a cinco dias, a equipe se frustra e desiste. A saída é autoatendimento construído antes da expansão: documentação pesquisável com telas, FAQ montado com as dúvidas reais do piloto, vídeos curtos para as tarefas comuns (as pessoas assistem vídeo quando não leem manual), multiplicadores treinados em cada setor e um caminho claro de escalonamento quando o multiplicador empaca.

Perfil do usuário. Quem participou do piloto se voluntariou ou foi escolhido. Está motivado, perdoa defeito pequeno, dá feedback sem que se peça. Quem chega na expansão não pediu nada disso: tem o próprio trabalho, não perdoa fricção e não vai reclamar — vai parar de usar. Resolva cada ponto de dor relevante antes de expandir, comunique o porquê até o valor ficar claro, corte cada atrito que puder e reconheça publicamente quem adota bem.

Qualidade de dados. Com 50 bens no piloto, dá para conferir tudo manualmente toda semana. Com 5.000, conferência manual é impossível: o erro acumula e a qualidade apodrece. Monte verificações automáticas antes de expandir: bem sem localização, número de série duplicado, data de última movimentação suspeita de tão antiga. Implante uma rotina sustentável de inventário com contagem rotativa, em vez de torcer para o inventário anual pegar tudo. E faça da qualidade dos dados a responsabilidade nomeada de alguém: o que é trabalho de todos é trabalho de ninguém.

Concentração de conhecimento. No piloto, o responsável pela implantação faz tudo: configura, treina, importa, conserta, responde. Na escala, ele vira gargalo em todas as frentes. Documente o que ele sabe antes da expansão, treine administradores adicionais para o conhecimento não morar numa cabeça só e distribua papéis claros entre donos distintos: treinamento, qualidade de dados, suporte técnico.

Volume de cadastro. Cadastrar um bem novo leva cinco minutos no piloto, e tudo bem. Na escala, são 50 bens novos por semana: quatro horas semanais de digitação. Enxugue a entrada de dados com menos campos obrigatórios e valores padrão inteligentes, habilite importação em lote para cadastrar 20 notebooks iguais de uma vez e integre com compras para o bem nascer no sistema a partir do pedido.

Régua de bolso: multiplique o esforço do piloto pelo seu fator de escala. O que toma uma hora por semana no piloto tomará 25 horas num parque 25 vezes maior. Planeje de acordo.

A decisão: escalar, ajustar ou parar

O piloto acabou. Você tem dados, feedback e experiência. Agora decida com evidência, não com política nem com apego ao custo já gasto. Três desfechos são possíveis, e todos são legítimos.

Escalar, sem ressalvas, quando tudo isto é verdade: desempenho técnico dentro da meta (disponibilidade acima de 99%, leitura rápida), adoção acima de 80%, exatidão de dados acima de 95%, pelo menos 70% da equipe recomendando a expansão, nenhum problema incontornável e retorno demonstrável — tempo economizado, bens encontrados, eficiência ganha. Bateu os números? Avance, e leve os usuários piloto como multiplicadores.

Parar, quando qualquer um destes sinais aparece: o sistema fica fora do ar com frequência, a equipe resiste ativamente ou trabalha por fora dele, fluxos críticos estão quebrados, a qualidade dos dados piorou, o patrocínio da diretoria ou o orçamento evaporou, ou o fornecedor não resolve problemas críticos. Diante dessas bandeiras vermelhas, pare. Corrija os fundamentos, escolha outro sistema ou repense a abordagem, mas não empurre para a frente esperando melhorar. E há o caso mais honesto de todos: o problema que você queria resolver não era o que a operação sentia, ou a solução não cabe no jeito de trabalhar. Descobrir isso com 200 itens é um bom resultado, não um fracasso.

Ajustar e expandir é onde a maioria dos pilotos termina. As coisas funcionam no geral, mas há pendências relevantes: desempenho aceitável sem ser ótimo, adoção entre 60% e 75%, alguns atritos de fluxo, equipe que vê valor mas tem ressalvas, dados melhorando sem ainda chegar lá.

Faça quatro perguntas. Os problemas têm conserto? (Problema técnico costuma ter; desencontro fundamental de fluxo raramente tem.) Quanto tempo levam as correções? (Duas semanas é razoável; seis meses significa que você não está pronto.) As correções respondem às ressalvas da equipe? (Pergunte a ela, não presuma.) Você tem tempo para esperar? Depois, corrija os três a cinco problemas principais, rode um mini-piloto de duas semanas para testar as correções e só então bata o martelo.

Um placar, se você quiser um

Algumas equipes preferem quantificar a decisão:

De 8,0 para cima: avance. Entre 6,0 e 7,9: resolva as pendências e depois avance. Abaixo de 6,0: retrabalho sério pela frente. Ajuste os pesos à sua realidade — se satisfação da equipe é crítica na sua cultura, dê 30% a ela.

Comunicando os resultados

O piloto terminou, a decisão está tomada. Agora conte às pessoas, cada plateia do jeito certo.

Para a diretoria

Uma página. Diretor não lê relatório de quarenta páginas.

Inclua: visão geral do piloto (o quê, quando, com quem), os indicadores em números (adoção, exatidão, tempo economizado), um ou dois casos concretos, os problemas encontrados e como foram resolvidos, os riscos que restam (seja honesto), a recomendação e os próximos passos com prazo e recursos. Abra com resultado, não com processo: "a equipe do piloto reduziu em 60% o tempo de busca de equipamentos" vale mais que "concluímos todas as atividades no cronograma".

Para a equipe de implantação

Este é o seu conhecimento institucional. Documente tudo: escopo e cronograma, participantes e taxas de participação, feedback organizado por tema, problemas técnicos e resoluções, mudanças de processo, comparativos antes/depois, lições aprendidas, recomendações para a expansão e anexos com pesquisas e notas de conversa.

Daqui a seis meses, quando algo travar na expansão, esse documento vale ouro. Daqui a um ano, quando você pilotar outro sistema, ele é o seu roteiro.

Para os futuros usuários

Se a decisão é avançar, o anúncio define expectativas e constrói disposição. Compartilhe resultados concretos e destaque o que funcionou. Mostre que o feedback foi ouvido ("com base no que aprendemos, simplificamos a transferência e ativamos o modo offline"). Dê expectativas claras ("o treinamento chega duas semanas antes de o seu setor entrar"). Conecte a benefícios que interessam a quem ouve ("menos tempo procurando, mais tempo no trabalho de verdade").

O tom: confiante, sem desdenhar das preocupações. "Sabemos que mudança dá trabalho. Testamos a fundo e funciona" convence mais que "vai ser ótimo!".

Pilotos viram multiplicadores

Os usuários do piloto são o seu ativo mais valioso na expansão. Eles usaram o sistema, sabem que funciona e respondem às dúvidas dos colegas com credibilidade. Use as frases deles nos anúncios, deixe que co-conduzam o treinamento nos próprios setores — treinamento entre pares convence mais que instrução de cima para baixo —, faça deles a referência de dúvidas na sua área e reconheça a contribuição publicamente.

Checklist do piloto

4–6 semanas antes

• Definir o escopo (setores, unidades, categorias de bens)
• Escolher os usuários piloto (dispostos, representativos, acessíveis)
• Definir critérios de sucesso e indicadores
• Fechar o cronograma (início, fim, avaliação)
• Comunicar o plano à diretoria e aos participantes

2–3 semanas antes

• Configurar o sistema para o ambiente do piloto
• Preparar plaquetas e etiquetas
• Limpar e preparar os dados para a carga
• Criar o material de treinamento
• Montar os canais de feedback (pesquisas, agenda de conversas)

Semana anterior

• Etiquetar os bens do piloto
• Importar os dados iniciais e conferir a exatidão
• Treinar os usuários (na prática, com o celular na mão)
• Distribuir guias rápidos de consulta
• Abrir os canais de suporte (grupo da equipe, e-mail)

Durante o piloto

• Conversa diária na primeira semana
• Pesquisas semanais dali em diante
• Resolver problema técnico de imediato
• Documentar todo feedback e toda ocorrência
• Aplicar ajustes rápidos no caminho
• Acompanhar os indicadores de uso continuamente

Fim do piloto

• Pesquisa final com os usuários
• Conversas individuais ou em grupo
• Conferência física para verificar a exatidão dos dados
• Calcular todos os indicadores de sucesso
• Analisar o que funcionou e o que não funcionou

Depois do piloto

• Resumo executivo de uma página
• Relatório detalhado do piloto
• Decisão de avançar ou parar, com o placar
• Se avançar: plano de expansão com as lições aprendidas
• Se ajustar ou parar: correções necessárias documentadas
• Comunicar os resultados aos envolvidos
• Agradecer e reconhecer os usuários piloto

O piloto que se paga sozinho

Esses padrões viraram as restrições de projeto do UNIO24.

Aplicativo móvel que funciona offline primeiro, porque vi equipes demais abandonarem um sistema na primeira vez que o Wi-Fi do galpão caiu no meio da leitura. Os primeiros 50 bens grátis, sem cartão e sem prazo de teste, porque quero que você consiga rodar um piloto de verdade, não negociar com o setor de compras antes de saber se a ferramenta serve. Importação e transferência em lote, porque a diferença entre cinco minutos e trinta segundos por operação é o que decide a adoção entre o piloto e a escala. Uma estrutura inicial de categorias propositalmente curta, porque ver usuário chutando categoria é problema de fluxo fantasiado de problema de interface.

Nada disso está neste playbook por acaso. Está porque vi os mesmos problemas quebrarem as mesmas implantações, e construí um produto que não facilita cometê-los.

Um detalhe prático: comece o piloto no plano grátis até 50 itens. Ele cobre a ferramentaria de uma obra, o parque de TI de um andar ou o audiovisual de uma escola — que é exatamente o tamanho de piloto que funciona. Sem processo de compra, sem aprovação de orçamento e sem compromisso para descobrir se a coisa faz sentido na sua operação. Comece o piloto gratuito, e se outra ferramenta servir melhor, use-a. Só não pule o piloto.

Quando o piloto convencer, o resto da implantação já tem o mais difícil resolvido: o processo testado e alguém que sabe defendê-lo.