Se você está tentando aprovar orçamento para um projeto de IoT dentro da sua empresa, provavelmente domina a parte técnica. Já escolheu os sensores, testou a cobertura LoRaWAN, talvez tenha montado um dashboard numa conta gratuita durante um fim de semana. A apresentação reflete esse trabalho: slide de arquitetura, lista de dispositivos, opções de conectividade, uma captura de tela com dados ao vivo. Todo mundo balança a cabeça concordando.
Depois disso, nada acontece. O retorno é alguma variação de “interessante, volte no próximo trimestre”, e no próximo trimestre os mesmos slides recebem os mesmos acenos. O projeto nunca é reprovado e nunca é aprovado, o que é pior, porque uma reprovação pelo menos diz o que precisa ser corrigido.
O problema raramente é o executivo. Executivos aprovam orçamento com base em um problema de negócio que já reconhecem, um número que cabe no plano e um risco que dá para delimitar. Uma apresentação técnica não entrega nada disso. Ela pede que ele traduza sensores em economia por conta própria, numa reunião, com gente olhando. A maioria não vai fazer isso, então adia.
A saída é montar a apresentação de trás para frente, partindo do que ele precisa ter em mãos antes de poder dizer sim.
Comece por uma métrica que o executivo já acompanha
Todo executivo tem uma lista curta de números que olha toda semana: horas de parada não planejada, custo de energia por unidade, índice de perdas, visitas técnicas por mês, horas extras. Sua apresentação precisa se ligar a exatamente um deles.
A tentação é listar todo benefício que os sensores poderiam entregar, porque parece um caso mais forte. É mais fraco: seis benefícios são seis números em que o executivo tem que acreditar, e o mais frágil derruba os outros. Uma métrica, com um valor atual que ele já aceita e uma meta que você consegue defender, é algo que ele consegue repetir para o próprio chefe em uma frase.
Escolha a métrica perguntando, não adivinhando. Vinte minutos com o líder de operações sobre o que faz o telefone dele tocar de madrugada normalmente resolvem. Se os sensores não movem nenhum número que o executivo acompanha, melhor descobrir isso antes de gastar capital político.
Mostre três anos de custo, não a primeira fatura
A segunda coisa que um executivo precisa é um número que não vai deixá-lo mal depois. Projetos de IoT têm fama de orçamento pequeno no primeiro ano seguido de surpresas: taxas de conectividade por dispositivo, hardware de reposição, o tempo do engenheiro que ninguém contabilizou, trabalho de integração quando o time de ERP entra na história. O custo real de um projeto de IoT mid-market já está bem documentado, e a maioria dos executivos já se queimou com o mesmo padrão em algum outro projeto.
Coloque o total de três anos em um slide: hardware e instalação, conectividade, plataforma e o tempo interno para operar. Diga quais linhas são estimativas e qual é a margem de erro. “Algo em torno de $140k em três anos, com a linha de plataforma variando conforme o número de dispositivos” vale mais do que um valor preciso de $38k no primeiro ano que todos na sala suspeitam estar incompleto. A comparação de preços em três anos mostra como o custo de plataforma se comporta conforme a base de dispositivos cresce.
Depois coloque a métrica ao lado desse número. Se cada hora de parada custa $9k e a meta é reduzir oito horas por ano, o executivo faz a conta sem a sua ajuda. O momento em que ele faz a conta sozinho costuma ser o momento em que o tom da reunião muda.
Proponha um piloto com critério de encerramento e data
Executivos têm menos medo de gastar dinheiro do que de gastar em algo que não pode ser interrompido. Uma “fase um” sem prazo definido soa como compromisso permanente, e compromisso permanente é adiado.
Um piloto com critério de encerramento soa diferente: um número fixo de dispositivos em uma unidade, uma duração fixa (noventa dias é comum), uma medição ligada à métrica e uma frase escrita dizendo qual resultado encerra o projeto. “Se não detectarmos pelo menos 80% das falhas de compressor registradas no log de manutenção durante o piloto, paramos e damos baixa no custo do piloto” dá uma saída ao executivo. Uma saída clara o deixa muito mais disposto a entrar.
Coloque uma data de decisão. Não “vamos revisar os resultados”, mas “em 12 de dezembro nos reunimos e decidimos expandir, ajustar ou parar”. O guia de planejamento para gerentes de projeto não técnicos trata de dimensionar o piloto para que a medição saia limpa.
Dimensione o piloto para que o custo caiba na alçada do próprio executivo que vai aprovar. Um piloto de $15k que um diretor assina anda em uma semana. Um piloto de $60k que precisa de comitê espera pelo comitê.
Faça a demo no celular dele, não nos seus slides
Uma captura de tela de dashboard prova que você sabe montar um dashboard. Uma visão ao vivo no celular do próprio executivo prova que o sistema existe e que ele conseguiria usá-lo sem você.
Com alguns dispositivos reais já enviando dados, monte um portal TagoRUN pequeno, crie um usuário para o executivo e peça que ele instale o app móvel do TagoRUN e faça login antes da reunião. Quando você disser “a câmara fria leste está a 3,8 graus agora”, ele pode conferir. Configure uma Action para que um alerta chegue ao celular dele durante a reunião, e a conversa deixa de ser sobre se aquilo funciona.
Mantenha a demo restrita à métrica: um dashboard, dois ou três widgets, um alerta. Quinze gráficos geram quinze perguntas sobre os gráficos e nenhuma sobre o orçamento.
Responda com honestidade ao “por que não construímos isso na AWS”
Alguém na sala vai perguntar, muitas vezes o CTO. Não desvie, e não finja que a alternativa é inviável. Empresas constroem sobre AWS IoT Core, ThingsBoard e stacks próprias o tempo todo, e algumas devem mesmo construir.
A resposta honesta é sobre tempo e equipe, não sobre capacidade. Construir ingestão, armazenamento, gestão de usuários, dashboards, alertas e acesso pelo celular por conta própria coloca um time de engenharia entre o piloto e a data de decisão. O post AWS IoT Core contra uma plataforma gerenciada mostra onde cada caminho faz sentido. Para a apresentação, o ponto é que o cronograma de piloto que você acabou de propor pressupõe configurar, não construir. Se a liderança preferir construir, o cronograma e o custo de três anos mudam, e você tem que dizer em quanto.
Executivos respeitam essa resposta porque ela não soa como fornecedor. Soa como alguém pensando em onde os engenheiros da empresa devem gastar o tempo deles.
O que deixar de fora
Boa parte do que faz uma apresentação técnica parecer completa é justamente o que a trava. Deixe de fora:
- O diagrama de arquitetura. Guarde no anexo para quem perguntar.
- Escolha de protocolo. LoRaWAN contra celular é decisão que você já deveria ter tomado, não algo para eles pesarem.
- Casos de uso futuros. Expansão é conversa para a data de decisão, depois que o piloto tiver um resultado.
- Estatísticas de mercado sobre adoção de IoT. Elas sinalizam que você não achou um número dentro da própria empresa.
- A lista de recursos da plataforma. O executivo está aprovando um piloto com base em uma métrica, não escolhendo software.
A apresentação que é aprovada cabe em uma página. Quem consegue orçamento para IoT raramente é quem tem o melhor argumento técnico. Essas pessoas fizeram o trabalho de tradução no lugar do executivo, então a única coisa que sobrou para a reunião foi dizer sim.
