El primer paso natural en un proyecto IoT es pedir un kit de desarrollo y unos cuantos sensores. Parece un avance, cuesta poco y le da al equipo algo que conectar. Así empieza la mayoría de los proyectos.
El problema es que el hardware comprado antes de definir el alcance decide por ti. Un sensor LoRaWAN te compromete con una red para la que quizá no tengas cobertura. Su firmware fija el formato del payload y las variables que vas a obtener, para siempre. Su intervalo de reporte por defecto define la vida de la batería, el volumen de datos y la forma de tu factura de plataforma durante los próximos tres años. El hardware toma todas esas decisiones de golpe, y son las más difíciles de revertir. Devolver un kit de desarrollo es fácil. Reemplazar cuatrocientos sensores ya instalados con la radio equivocada es reiniciar el proyecto.
El remedio es una secuencia que deja el alcance en una sola página antes de cualquier orden de compra, y que luego lo comprueba en la plataforma con un dispositivo simulado. El hardware va al final, y a esas alturas ya sabes qué pedir.
Paso 1: nombra la decisión que los datos deben cambiar
Todo proyecto IoT que se paga a sí mismo cambia una decisión que hoy alguien toma sin datos. Escríbela en una frase, con un rol concreto: “el jefe de planta decide qué cámaras frigoríficas inspeccionar cada mañana”, o “el responsable de mantenimiento decide cuándo cambiar los sellos de las bombas”. Si la frase necesita la palabra “insights”, no está terminada.
Este paso determina todo lo que viene después. Una decisión que se toma una vez al día tolera un sensor que reporta cada hora. Una decisión que detiene una línea de producción necesita segundos. Los equipos que se lo saltan terminan con un dashboard que nadie abre.
Paso 2: lista las variables, las unidades y el intervalo de reporte
A partir de la decisión, retrocede hasta el dato mínimo: qué variables, en qué unidades, con qué intervalo y con qué precisión. Temperatura con precisión de 0,5 C cada 15 minutos implica otro sensor, otro presupuesto de batería y otro volumen de datos que temperatura con 0,1 C cada minuto.
El intervalo es el número que esconde el costo. Un sensor que reporta cada minuto genera 60 veces más datos que uno que reporta cada hora, agota su batería en una fracción del tiempo y empuja a la flota hacia los tramos altos del precio de entrada de datos de cualquier plataforma. Fija el intervalo a partir de la decisión del Paso 1, no a partir del valor por defecto del sensor.
Paso 3: revisa los sitios y su conectividad real
Lista cada sitio donde va a vivir un dispositivo y responde para cada uno: ¿qué radio llega de verdad hasta ahí? LoRaWAN necesita un gateway con un camino real hasta la ubicación del sensor, y los sótanos, las cajas metálicas y el concreto denso recortan mucho el alcance de la hoja de datos. La red celular necesita cobertura del operador dentro del edificio, no afuera. Wi-Fi necesita que el área de IT del cliente diga sí, por escrito, sobre una red que tú no controlas.
Una prueba de cobertura cuesta una tarde y un gateway prestado. Saltarla es la razón por la que un proyecto especificado para LoRaWAN termina en red celular a tres veces el costo por unidad. Lee el alcance de LoRaWAN en el mundo real antes de dar por buena una cifra.
Paso 4: cuenta los dispositivos del piloto y los del tercer año
Dos números honestos: cuántos dispositivos en el piloto y cuántos si el piloto funciona y se despliega durante tres años. El número del piloto dimensiona tu primer pedido. El número del tercer año dimensiona todo lo demás: qué modelo de precio tiene sentido y qué límites de la plataforma vas a alcanzar primero (entrada de datos, salida de datos, almacenamiento, notificaciones).
Un modelo de precio que sale barato con 30 dispositivos puede ser el caro con 3.000. La comparación de modelos de precio de plataformas IoT repasa cada formato. Escribe el número del tercer año aunque sea una estimación a ojo: una estimación en papel se corrige, una que vive en la cabeza de alguien no.
Paso 5: define quiénes son los usuarios y qué ven
Separa a quienes construyen la aplicación de quienes la usan. En TagoIO, quienes construyen trabajan en Admin: agregan dispositivos, escriben Payload Parsers, arman Dashboards y configuran Actions. Los usuarios finales, el jefe de planta del Paso 1, inician sesión en un portal TagoRUN con tu marca, en la web o en la app móvil, y solo ven lo que les concede su política de Access Management.
Para cada rol, escribe qué ve y qué puede hacer: qué sitios, qué dashboards, qué alertas en el teléfono y si puede cambiar umbrales o solo mirar. Si un rol necesita notificaciones push en obra, la app móvil entra en el alcance desde el primer día, y eso cambia cómo distribuyes los dashboards.
Paso 6: lista las integraciones que tienen que existir
La mayoría de los proyectos IoT termina en otro sistema. La alerta tiene que convertirse en un ticket. Los totales diarios tienen que llegar al ERP. Escribe cada integración con su dirección (entrante o saliente), su disparador (por evento, por horario) y su protocolo (webhook, REST API, entrega de archivos). En la plataforma esto se convierte en una Action que hace POST a un webhook, o en un Analysis programado que llama a la API externa.
Una integración que falta es la causa más común de que un piloto terminado nunca llegue a producción: los datos estaban bien, pero nunca llegaron al sistema que actúa sobre ellos.
Paso 7: escribe los criterios de aceptación del piloto
Antes del hardware, acuerda qué significa que “el piloto funcionó”. Disponibilidad de entrega de datos por dispositivo. Latencia de la alerta, desde el evento hasta la notificación. Consumo de batería frente a la vida proyectada. La decisión del Paso 1, tomada de verdad desde el dashboard, por la persona nombrada, durante una cantidad definida de semanas.
Los criterios escritos ahora son baratos. Los criterios negociados después de un piloto que funcionó a medias son caros, porque cada interesado recuerda una promesa distinta. Ponlos en el alcance, al lado del nombre de quien da la aprobación.
Traduce el alcance a objetos de la plataforma y simula el primer dispositivo
Cada línea de ese alcance de una sola página corresponde a algo que puedes construir hoy en la plataforma, sin tener un sensor en la mano:
- Las variables y las unidades (Paso 2) se convierten en un Device con variables nombradas. Su Connector o su Payload Parser decodifica el payload que enviará el hardware candidato.
- Los sitios y la conectividad (Paso 3) se convierten en el Network del dispositivo y en los tags que agrupan dispositivos por sitio.
- Los usuarios y las vistas (Paso 5) se convierten en Dashboards y en una política de Access Management que muestra a cada usuario de TagoRUN solo sus sitios.
- Las integraciones (Paso 6) se convierten en Actions con una condición y un webhook como destino, o en un Analysis programado.
- Los criterios de aceptación (Paso 7) se convierten en los umbrales de las alertas y en los widgets con los que vas a juzgar el piloto.
Después crea un dispositivo, toma el payload de ejemplo de la hoja de datos del sensor candidato y envíalo por la API con el intervalo del Paso 2. En una hora tienes un dashboard con los datos de la decisión, una alerta en el teléfono a través de la app de TagoRUN y un webhook llegando a un endpoint de prueba. También sabes si el payload trae las variables que necesitas, si el intervalo se lee bien en un gráfico y si el usuario final entiende la pantalla.
Ya puedes pedir el hardware. Estás comprando según una especificación que el equipo ya vio funcionar, y si el primer dispositivo real no coincide con la simulación, te enteras el primer día y no durante el despliegue.
