Casi todos los equipos empiezan la evaluación de una plataforma IoT de forma sensata. Una lista corta de tres o cuatro candidatos, una hoja de cálculo y requisitos de todas las partes involucradas: SSO y registros de auditoría, alertas y gestión de firmware, un modelo de costos, un portal para clientes. Parece rigor, y durante las dos primeras semanas lo es.
Después la hoja de cálculo llega a 80 filas. Cada proveedor marca casi todas las casillas, porque toda plataforma madura sabe guardar telemetría, dibujar un gráfico y enviar una alerta. Las diferencias que quedan viven en filas que nadie puede puntuar sin usar el producto, así que el equipo agenda más demos. A los tres meses, la evaluación tiene un modelo de puntuación ponderada, cuatro presentaciones de proveedores y ningún dispositivo enviando datos a ninguna parte.
La complejidad tiene dos orígenes, y ninguno tiene que ver con los proveedores. El primero es evaluar funciones que no vas a usar en el primer año. El segundo es tratar la decisión como irreversible, lo que hace que cada fila parezca tener que estar bien. La mayoría no tiene por qué estarlo. Unas pocas cosas sí son difíciles de cambiar después. Todo lo demás es configuración, y para eso existe un piloto.
Señales de que lo estás complicando demasiado
Hay unos cuantos patrones que aparecen en casi todas las evaluaciones atascadas que he visto en integradores de sistemas y equipos de producto de OEM.
- La lista de requisitos tiene filas para funciones que nadie sabe para qué usaría en los próximos doce meses. Los gemelos digitales aparecen en la hoja de cálculo mientras los dispositivos reales son 40 sensores de temperatura LoRaWAN en un almacén.
- Todos los proveedores puntúan entre 82 y 91 por ciento. Cuando la diferencia es tan estrecha, la puntuación mide qué tan bien escribe cada proveedor sus hojas de datos.
- Nadie del equipo de evaluación ha pasado más de una hora dentro de ninguna de las plataformas candidatas.
- Las palabras “a prueba de futuro” aparecen en el documento de justificación y nadie sabe decir contra qué futuro protege.
- Se está hablando de una segunda ronda de RFP para “aclarar las respuestas” de la primera.
- La fecha de inicio del piloto ya se movió al menos dos veces.
Si dos o más de estas te suenan, la hoja de cálculo ya dejó de ayudar.
Qué es de verdad irreversible
La pregunta útil para cada fila no es “¿la plataforma hace esto?” sino “si nos equivocamos aquí, ¿cuánto cuesta cambiar de opinión en dos años?”. La mayoría de las filas no pasa esa prueba. Los tipos de Widget, los canales de alerta, los formatos de informe, los roles de usuario, la disposición de los dashboards y la integración con el ERP son cosas que se configuran y se vuelven a configurar durante toda la vida de la plataforma. Equivocarse en ellas al momento de elegir cuesta una tarde más adelante.
Un puñado de decisiones no funciona así, y esas sí merecen el tiempo de evaluación.
Propiedad y exportación de los datos. Dos años de telemetría son el activo más caro del proyecto, y que puedas exportarlos de forma masiva, en un formato usable y sin abrir un ticket de soporte, define qué tan fuerte queda la posición del proveedor en la renovación. Revisa cómo funciona la exportación de datos, si la API da acceso a todo en crudo y dónde viven los datos. El artículo sobre vendor lock-in detalla qué probar.
Cómo se comporta el precio al volumen del año tres. El precio con 50 dispositivos no dice nada. Modela la factura con la cantidad de dispositivos y la tasa de mensajes que esperas en el año tres, y busca qué medidor mueve la cifra: dispositivos, puntos de datos, almacenamiento, usuarios u otra cosa. Dos plataformas que hoy cuestan lo mismo pueden diferir por un factor de tres a escala, y cambiar después implica migrar los datos del párrafo anterior. La comparación de precios a tres años recorre las cuentas.
Quiénes son tus usuarios finales. Si quien mira los datos es tu propio equipo de operaciones, basta con la consola de Admin. Si son clientes, tenants o técnicos de campo que nunca deben ver los sitios de los demás, la plataforma tiene que ponerles delante un portal con marca propia y reglas de acceso por usuario. Eso es arquitectura, no cosmética. En TagoIO esa capa es TagoRUN con políticas de Access Management; construirla por tu cuenta después es un proyecto, no un ajuste.
Los dispositivos y las redes que tienes hoy. No los que quizá agregues en 2028. Si la flota es LoRaWAN a través de un network server específico, dispositivos celulares que hablan MQTT o un gateway Modbus heredado, la plataforma tiene que decodificar esos payloads hoy.
Superficie de integración. ¿Puedes ejecutar tu propio código dentro de la plataforma cuando una regla deja de caber en un menú, y pueden los sistemas externos entrar y salir por una API documentada? Esa es la diferencia entre una plataforma que se extiende y una que hay que sortear.
Esa es toda la lista. Si un candidato pasa, las filas restantes son configuración que vas a verificar en el piloto, y la configuración no es motivo para mantener la evaluación abierta.
Cambia la hoja de cálculo por un piloto de dos semanas
La hoja de cálculo responde preguntas leyendo. El piloto las responde haciendo, y hacer es más rápido una vez resueltas las preguntas difíciles de revertir. El formato que funciona es acotado y con plazo fijo: un caso de uso que le importe al negocio, de diez a veinte dispositivos reales de tu flota, un sitio, un tipo de usuario y una fecha de cierre fija a dos semanas. Anota qué significa “funcionó” antes de empezar: dispositivos decodificados y enviando datos, un dashboard que quien va a usarlo pueda leer, una alerta que se dispare con una condición real y una exportación de los datos recolectados que tu equipo pueda abrir.
En TagoIO las dos semanas suelen ir así. Días uno y dos: agregar los dispositivos con un Connector para tu red, o escribir un Payload Parser si el dispositivo no está en la lista. Días tres a cinco: armar el dashboard con Widgets estándar y después convertirlo en un Blueprint Dashboard para que una sola disposición sirva a todos los dispositivos. Segunda semana: una Action que envíe la alerta, un script de Analysis si la lógica necesita más que un umbral, y un usuario de TagoRUN que entre y vea solo sus propios datos. El último día, exporta los datos y lee la factura.
Lo que se aprende en esas dos semanas es lo que la hoja de cálculo no podía decir: cuánto tarda de verdad decodificar un dispositivo nuevo, si quien va a usarlo entiende el dashboard sin capacitación, si los medidores de precio se mueven como los modelaste y cómo se comporta la plataforma cuando tu código de Analysis lanza un error a las 2 de la mañana. La guía del comprador tiene las preguntas que hacerles a los proveedores antes de esta etapa; el piloto es donde dejas de preguntar y compruebas.
Cuando la respuesta correcta es una prueba pequeña, no otro RFP
Hay versiones de esta decisión que no necesitan ningún proceso de compras. Si eres un integrador de sistemas eligiendo plataforma para tu propio negocio de servicios, o un equipo de producto con unos cientos de dispositivos en el primer año, una elección equivocada cuesta una migración que se hace en un trimestre. En ese caso, la parte más cara de la decisión es el tiempo invertido en tomarla.
Una cuenta gratuita o del plan más bajo en dos candidatos, los mismos diez dispositivos conectados a ambos y dos semanas de uso real dan una respuesta más clara que una tercera ronda de cuestionarios a proveedores. Construir sobre AWS IoT Core o sobre un stack de código abierto es una respuesta legítima para algunos equipos, y la prueba es la misma: conecta los dispositivos y cuenta las semanas hasta tener un dashboard funcionando.
Después decide, y anota por qué. Las razones que van a importar en dos años son las difíciles de revertir. Todo lo demás lo vas a cambiar al menos dos veces de todos modos.
