A maioria dos cases de IoT parece ótima no slide. Eles contam a economia óbvia, dividem pelo preço dos sensores e chegam a um número que aprova o projeto. Depois o projeto entra no ar, as contas reais começam a chegar e a economia se mostra mais frágil do que alguém admitia. A conta não estava errada. Estava incompleta.
Um cálculo de ROI de verdade faz duas coisas que a versão de slide pula. Ele soma o custo total de propriedade, não só o hardware. E separa a economia que você consegue medir da economia que você está torcendo para ter. Acerte os dois e você tem um número que consegue defender. Erre qualquer um deles e você está chutando.
Aqui está um método que você pode usar de verdade.
Comece pelo custo total de propriedade
O primeiro erro é tratar o preço do sensor como se fosse o custo. O sensor é a parte mais barata. O custo total de propriedade inclui tudo o que você vai pagar ao longo da vida do projeto, e a maior parte disso é recorrente.
Divida em categorias para que nada fique escondido:
Hardware. Sensores, gateways e qualquer dispositivo de borda. Inclua peças de reposição e as unidades que falham no primeiro ano, porque algumas vão falhar.
Integração. O tempo de engenharia para conectar dispositivos, escrever parsers, montar dashboards e configurar alertas. Costuma ser a maior linha do primeiro ano e a que as pessoas esquecem de cotar.
Conectividade. Planos de celular, acesso à rede LoRaWAN ou o que quer que mova os dados. Isso se repete todo mês, por dispositivo, para sempre.
Plataforma e armazenamento. A camada de cloud que ingere, armazena e serve os dados. Recorrente.
Operação contínua. Alguém monitora o sistema, troca sensores mortos, atualiza firmware e responde aos alertas. É um custo real mesmo quando ninguém o coloca no orçamento.
Acrescente uma linha para o custo de o projeto fracassar ou empacar, porque um piloto que nunca escala ainda custou o piloto. Some tudo isso ao longo de três anos, não de um. Um projeto que se paga no oitavo mês numa visão de um ano pode ter uma cara bem diferente quando a conectividade e a operação do segundo ano entram na coluna.
Separe a economia concreta da economia frouxa
Agora o lado do benefício. A coisa mais útil que você pode fazer é dividir sua economia em duas colunas e nunca misturá-las.
A economia concreta é mensurável. Você consegue apontar para um número que mudou:
- Gasto de energia reduzido porque o monitoramento detectou um equipamento operando de forma ineficiente. A otimização de energia costuma mirar reduções na faixa de dez a vinte por cento da carga monitorada, embora o seu número dependa inteiramente da sua linha de base.
- Horas de trabalho economizadas porque alguém não precisa mais se deslocar para ler um medidor ou conferir um tanque manualmente. Conte as visitas em campo evitadas e multiplique pelo custo total de cada deslocamento.
- Perda de produto evitada. Na cadeia do frio, alertas precoces de temperatura impedem que cargas se estraguem. Se você historicamente perde um número conhecido de cargas por ano, o valor de evitar essas perdas é concreto.
- Parada não planejada evitada por meio de manutenção preditiva. Se uma instalação tem histórico de falhas de equipamento a um custo conhecido cada, e o monitoramento de condição evita algumas delas, o custo evitado é real e comprovável depois do fato.
A economia frouxa é real, mas mais difícil de colocar um preço:
- Evidências de compliance e auditoria que você não tinha antes.
- Incidentes de segurança evitados.
- Decisões mais rápidas porque o dado simplesmente existe.
- Confiança do cliente por conseguir provar que uma carga se manteve dentro da faixa.
A economia frouxa pertence ao case. Ela só não pertence à mesma coluna da economia concreta, e nunca deve sustentar o ROI sozinha. Se o projeto só funciona depois que você atribui um valor generoso em dólares a moral e agilidade, o projeto não funciona.
Estime o período de payback e teste-o
Com o custo total e a economia concreta em mãos, o período de payback é o tempo que a economia concreta acumulada leva para cobrir o custo acumulado. Projetos de manutenção preditiva e monitoramento costumam cair em algum ponto na faixa de doze a dezoito meses, mas trate isso como uma checagem de sanidade, não como uma meta. Seu payback é o que os seus próprios números disserem.
Depois, coloque as premissas à prova antes que alguém assine:
- Contra qual linha de base a economia está sendo medida, e essa linha de base está documentada ou só foi lembrada de memória? Linhas de base lembradas de memória embelezam qualquer projeto.
- O que acontece com o payback se a economia vier pela metade? Se o case só sobrevive no número otimista, não é um case, é uma esperança.
- Quem age sobre o alerta? Um alerta de energia ou manutenção não economiza nada se ninguém for responsável por responder. A economia mora na ação, não no dado.
- O custo recorrente cresce com a escala mais rápido do que a economia cresce?
Um case que sobrevive a essas quatro perguntas é um case que você pode levar a um CFO.
Quando o ROI de IoT não fecha
A parte honesta. Muitos projetos de IoT não deveriam acontecer, e a conta vai te dizer isso se você deixar.
IoT raramente se paga quando o ativo monitorado é de baixo valor. Colocar um sensor conectado em um equipamento que custa pouco para repor e falha sem consequência é difícil de justificar. O sensor, a conectividade e a operação custam mais do que aquilo que protegem.
Raramente se paga em baixas quantidades de unidades, a menos que cada unidade seja de alto valor. O custo de integração é, em sua maior parte, fixo. Diluído entre dez ativos baratos, ele domina o case. Diluído entre dez mil, ou entre dez ativos críticos, ele desaparece.
E nunca se paga quando ninguém assume agir sobre o dado. Esse é o fracasso silencioso mais comum. Os dashboards entram no ar, os alertas disparam e nada muda porque responder a eles nunca foi a função de ninguém. A economia sempre dependeu de alguém fazer algo, e ninguém foi designado.
Se o seu case depende de monitorar ativos baratos, em pequena quantidade, sem ninguém responsável pela resposta, a resposta certa não é um projeto menor. É nenhum projeto. Dizer isso cedo é mais barato do que prová-lo depois de dezoito meses.
Onde a TagoIO se encaixa
A conta de ROI tem um lado de custo, e a camada de plataforma fica bem nesse lado. A TagoIO é a camada que ingere os dados dos dispositivos, armazena, roda a lógica e serve os dashboards e alertas. Como essa camada é cobrada e quanta engenharia ela exige para subir afetam diretamente suas linhas de integração e operação.
Alguns detalhes que tocam a coluna de custo. A TagoIO conecta a mais de 500 integrações de dispositivos, então conectar hardware existente é configuração e não desenvolvimento sob medida, o que reduz a linha de integração. Os scripts de Analysis serverless rodam sua lógica sem um servidor para provisionar ou manter, o que segura o custo de operação contínua. A plataforma é multi-tenant, então um projeto que atravessa vários sites ou clientes não multiplica a infraestrutura. Para trabalhos regulados, a TagoIO é certificada ISO 27001 e alinhada ao GDPR, o que faz parte da evidência de compliance do lado da economia frouxa.
Nada disso muda o lado da economia da sua equação. Sua economia concreta vem das suas próprias operações. A plataforma afeta o quanto o projeto custa para construir e rodar, e um custo de propriedade menor é a metade mais fácil de um payback melhor.
Próximos passos
- Veja projetos e os problemas que eles resolvem: tago.io/use-cases
- Confira como o lado do custo é cobrado: tago.io/pricing
- Comece a construir e cote o seu próprio projeto: admin.tago.io
