Si estás buscando presupuesto para un proyecto IoT dentro de tu empresa, lo más probable es que domines la tecnología. Ya elegiste los sensores, probaste la cobertura LoRaWAN y quizá armaste un dashboard en una cuenta gratuita durante un fin de semana. La propuesta refleja ese trabajo: diapositiva de arquitectura, lista de dispositivos, opciones de conectividad, una captura de datos en vivo. Todos asienten.
Después no pasa nada. La respuesta es alguna variante de “interesante, vuelve el próximo trimestre”, y al trimestre siguiente las mismas diapositivas reciben los mismos gestos de aprobación. El proyecto nunca se rechaza y nunca se aprueba, y eso es peor, porque un rechazo al menos te dice qué corregir.
El problema casi nunca es el ejecutivo. La dirección aprueba presupuesto cuando hay un problema de negocio que ya reconoce, un número que puede meter en un plan y un riesgo que puede acotar. Una propuesta técnica no ofrece ninguna de las tres cosas: le pide traducir sensores en ahorros por su cuenta, en plena reunión, con gente mirando. Casi nadie lo hace, así que posponen la decisión.
La salida es armar la propuesta al revés: partir de lo que la dirección necesita antes de poder decir que sí.
Empieza por una métrica que el ejecutivo ya sigue
Todo ejecutivo tiene una lista corta de números que revisa cada semana: horas de paro no planificado, costo de energía por planta, tasa de merma, visitas de técnicos al mes, horas extra. Tu propuesta tiene que engancharse a uno solo de ellos.
La tentación es listar todos los beneficios que los sensores podrían dar, porque parece un caso más fuerte. Es más débil: seis beneficios son seis números que el ejecutivo tiene que creer, y el más flojo arrastra al resto. Una sola métrica, con un valor actual que ya se acepta y una meta que puedes defender, es algo que el ejecutivo puede repetirle a su propio jefe en una frase.
Elige la métrica preguntando, no adivinando. Veinte minutos con el responsable de operaciones sobre qué le genera llamadas de madrugada suelen ser suficientes para encontrarla. Si los sensores no mueven ningún número que el ejecutivo siga, mejor saberlo antes de gastar capital político.
Muestra tres años de costo, no la primera factura
Lo segundo que necesita un ejecutivo es un número que no lo deje mal parado más adelante. Los proyectos IoT tienen fama de arrancar con un presupuesto chico el primer año y seguir con sorpresas: tarifas de conectividad por dispositivo, hardware de reemplazo, las horas del ingeniero que nadie costeó, trabajo de integración cuando entra el equipo del ERP. El costo real de un despliegue IoT de mercado medio está bien documentado, y casi todos los ejecutivos ya se quemaron con el mismo patrón en algún otro proyecto.
Pon un total a tres años en una sola diapositiva: hardware e instalación, conectividad, plataforma y el tiempo interno para operarlo. Aclara qué líneas son estimaciones y qué tan amplio es el rango. “Alrededor de $140k en tres años, con la línea de plataforma variando según la cantidad de dispositivos” convence más que una cifra exacta de $38k para el primer año que todos en la sala sospechan que está incompleta. La comparación de precios de plataformas IoT a tres años muestra cómo se comportan los costos de plataforma cuando crece la cantidad de dispositivos.
Después pon la métrica al lado de ese número. Si una hora de paro cuesta $9k y la meta es ocho horas menos por año, el ejecutivo puede hacer la aritmética sin tu ayuda. El momento en que hace la cuenta por su cuenta suele ser el momento en que cambia el tono de la reunión.
Propón un piloto con criterio de cancelación y fecha
A la dirección le preocupa menos gastar dinero que gastarlo en algo que después no se puede detener. Una “fase uno” sin final definido se lee como un compromiso permanente, y los compromisos permanentes se postergan.
Un piloto con criterio de cancelación se lee distinto: una cantidad fija de dispositivos en un solo sitio, una duración fija (noventa días es lo habitual), una medición atada a la métrica y una frase escrita sobre qué resultado termina el proyecto. “Si no detectamos al menos el 80% de las fallas de compresor que registra la bitácora de mantenimiento durante el piloto, paramos y asumimos como pérdida el costo del piloto” le da al ejecutivo una salida. Y una salida clara lo deja mucho más dispuesto a entrar.
Fija una fecha de decisión. No “vamos a revisar los resultados”, sino “el 12 de diciembre nos reunimos y decidimos expandir, ajustar o parar”. La guía de planificación para project managers sin perfil técnico explica cómo delimitar el piloto para que la medición quede limpia.
Dimensiona el piloto para que su costo quepa dentro de la autoridad del ejecutivo que lo aprueba. Un piloto de $15k que firma un solo director avanza en una semana. Un piloto de $60k que necesita comité espera al comité.
Haz la demo en el celular del ejecutivo, no en tus diapositivas
Una captura de un dashboard prueba que sabes hacer un dashboard. Una vista en vivo en el celular del propio ejecutivo prueba que el sistema existe y que podría usarlo sin ti.
Con unos pocos dispositivos reales ya enviando datos, monta un portal TagoRUN pequeño, crea un usuario para el ejecutivo y pídele que instale la app móvil de TagoRUN e inicie sesión antes de la reunión. Cuando digas “la cámara frigorífica del lado este está a 3,8 grados ahora mismo”, puede comprobarlo él mismo. Configura una Action para que una alerta llegue a su celular durante la reunión, y la conversación deja de girar en torno a si funciona.
Limita la demo a la métrica: un dashboard, dos o tres widgets, una alerta. Quince gráficos generan quince preguntas sobre los gráficos y ninguna sobre el presupuesto.
Responde con honestidad la pregunta de por qué no construirlo en AWS
Alguien en la sala la va a hacer, muchas veces el CTO. No la esquives ni finjas que la alternativa es impracticable. Hay empresas que construyen sobre AWS IoT Core, ThingsBoard y stacks propios todo el tiempo, y a algunas les conviene.
La respuesta honesta tiene que ver con tiempo y personal, no con capacidad técnica. Construir por tu cuenta la ingesta, el almacenamiento, la gestión de usuarios, los dashboards, las alertas y el acceso móvil pone un equipo de ingeniería entre el piloto y la fecha de decisión. El artículo sobre AWS IoT Core frente a una plataforma IoT gestionada detalla dónde tiene sentido cada camino. Para la propuesta, lo que importa es que el cronograma del piloto que acabas de plantear asume configurar, no construir. Si la dirección prefiere construir, cambian el cronograma y el costo a tres años, y conviene decir en cuánto.
La dirección respeta esa respuesta porque no suena a proveedor. Suena a alguien pensando en dónde deberían invertir su tiempo los ingenieros de la empresa.
Qué dejar fuera
Casi todo lo que hace que una propuesta técnica se vea sólida es lo que la frena. Deja fuera:
- El diagrama de arquitectura. Guárdalo en el anexo para quien lo pida.
- La elección de protocolo. LoRaWAN o red celular es una decisión que ya deberías tener tomada, no algo que la dirección tenga que sopesar.
- Casos de uso futuros. La expansión es una conversación para la fecha de decisión, cuando el piloto tenga un resultado.
- Estadísticas del sector sobre la adopción de IoT. Delatan que no encontraste un número dentro de tu propia empresa.
- La lista de funciones de la plataforma. El ejecutivo aprueba un piloto contra una métrica, no elige software.
La propuesta que se aprueba cabe en una página. Quienes logran que un proyecto IoT se financie casi nunca son los que llevan el mejor caso técnico. Hicieron el trabajo de traducción que le tocaba al ejecutivo, así que lo único que quedaba por hacer en la reunión era decir que sí.
