La promesa del IoT en Chile suele ser la misma: sensores, dashboard, métricas en tiempo real, ahorro operativo. La realidad es que la mayoría de los proyectos que se inician con entusiasmo se apagan antes del segundo año. No por falla tecnológica: por decisiones de diseño tomadas antes de escribir la primera línea de código.
Lo que casi nadie levanta al inicio
Tres preguntas que rara vez aparecen en el RFP y que aparecen después, cuando ya es tarde:
- ¿Quién opera esto después del despliegue? Si el equipo interno no puede mantener el sistema, depende del proveedor para siempre. Eso no es transformación digital, es outsourcing disfrazado.
- ¿Qué pasa cuando la conectividad falla? En faenas mineras, agro o retail con locales remotos, la conexión no es estable. Si todo depende de la nube, el sistema se cae cuando más se necesita.
- ¿Cuál es la métrica de éxito? "Tener un dashboard" no es éxito. Reducir horas-hombre, detectar fugas antes, optimizar rutas, eso es éxito. Si no hay KPI, no hay proyecto.
Los tres patrones de falla
Patrón 1: dashboard bonito, operación no
Se invierte en una interfaz bonita y se olvida la integración con los sistemas existentes. El operador termina con dos pantallas: la nueva y la legacy. La nueva queda en segundo plano en una semana.
Patrón 2: hardware sin criterio
Se compran sensores por catálogo sin validar el protocolo, el rango, el consumo ni la vida útil de la batería en contexto. A los seis meses, la mitad de los nodos está caída y nadie sabe por qué.
Patrón 3: cloud-only sin justificación
Todo sube a la nube "porque es más moderno". La latencia, el costo por GB transferido y la dependencia de conectividad no se midieron. Cuando llega la factura cloud del mes 8, el proyecto se cuestiona.
Qué hacer diferente
Un proyecto IoT que sobrevive el primer año suele tener cuatro ingredientes:
1. Levantamiento en terreno, no en oficina. Ver la operación real, hablar con los usuarios, observar fallas.
2. MVP acotado a un caso de uso. No "telemetría de toda la faena". Empezar por un activo crítico y expandir.
3. Capas de procesamiento local. Edge computing para decisiones inmediatas, nube solo para análisis agregado.
4. Plan de transferencia. Documentación, entrenamiento, criterios de mantenimiento y un acuerdo claro de soporte.
Cierre
El IoT no es un producto que se compra. Es un sistema operativo de un proceso de negocio que se construye. Si la base está mal levantada, no hay dashboard que lo salve.
En CodeHub ayudamos a empresas a diseñar proyectos IoT desde el levantamiento, no desde el proveedor del sensor.