El día del lanzamiento parece el final del proyecto. Los dispositivos reportan, los dashboards están en verde, el cliente firmó el acta de aceptación y el equipo de implementación pasa al siguiente trabajo.
Quienes heredan el sistema no estuvieron en la construcción. No eligieron el umbral de 7.5 de la alerta del tanque, no saben por qué doce dispositivos quedaron etiquetados como “pilot”, y la alerta de batería baja que suena a las 2 de la mañana llega a un ingeniero que salió del proyecto en marzo. Seis meses después nadie sabe decir cuántos dispositivos siguen reportando. Así se pudre un despliegue que funcionaba. Nada falla; el conocimiento que lo mantenía en pie se fuga con cada persona que se va.
El remedio es un paquete y un período de entrega, preparados antes del lanzamiento en lugar de armados de memoria después. Este es el paquete que vemos funcionar en despliegues de TagoIO, sin importar si el equipo de operaciones es el personal del cliente o la guardia de soporte del propio integrador.
Empieza por un mapa de responsables
La mayoría de las entregas fracasa por una pregunta que nadie hizo: quién responde por cada parte del sistema. Escribe una tabla de una página con una persona con nombre y apellido (no un buzón de equipo) para cada fila:
- Dispositivos: quién los agrega, los reemplaza y los da de baja, y a quién se llama cuando uno se queda callado
- Dashboards y el portal de TagoRUN: quién cambia lo que ven los usuarios finales
- Alertas: quién recibe cada Action, quién puede cambiar un umbral
- Usuarios: quién crea y elimina usuarios de TagoRUN y sus permisos
- Facturación y límites: quién vigila el consumo de servicios y aprueba los cambios de plan
- Código: quién responde por el Payload Parser y por cada script de Analysis
Si una fila no tiene nombre, la entrega no está terminada. Si todas las filas tienen el nombre del líder de implementación, no es una entrega.
Reemplaza los logins compartidos por accesos reales
El atajo más común al lanzar es un único login de administrador compartido por todo el equipo de operaciones. Funciona una semana y después se vuelve imposible de rastrear: nadie sabe quién cambió el umbral, y cuando alguien se va no puedes revocarle el acceso sin dejar afuera a los demás.
Crea usuarios de TagoRUN para el equipo de operaciones y usa políticas de Access Management para darle a cada rol lo que necesita: un técnico de campo ve la lista de dispositivos y el dashboard de salud de sus sitios, un supervisor puede reconocer alertas y editar umbrales desde un formulario, un administrador puede crear usuarios. Escribe las políticas contra tags de dispositivo (sitio, cliente) en lugar de IDs de dispositivo, así siguen valiendo cuando el año que viene entre el dispositivo número 300. Deja la consola de Admin para quienes construyen, y mantén corta y por escrito la lista de usuarios de Admin.
Escribe un runbook para cada alerta recurrente
Una alerta sin runbook es ruido con marca de tiempo. Para cada Action que notifica a una persona, escribe una entrada corta: qué significa la alerta en palabras simples, lo primero que hay que revisar, qué hacer si esa revisión confirma el problema, y cuándo y a quién escalar. Se lee a las 2 de la mañana en un teléfono, así que sé breve.
Después enruta las Actions para que coincidan. Una Action de TagoIO puede enviar email, SMS o notificaciones push a los usuarios de TagoRUN, o llamar a un Analysis, de modo que una alerta de gateway fuera de línea despierte al técnico de guardia mientras un aviso de consumo llega al responsable de facturación. Revisa todas las listas de destinatarios durante la entrega, porque casi siempre siguen incluyendo al equipo de implementación.
Arma la vista de salud de dispositivos que operaciones revisa a diario
El equipo de implementación sabe que la flota está sana porque la vio encenderse dispositivo por dispositivo. El equipo de operaciones necesita esa confianza desde una pantalla: un dashboard de salud, separado de lo que ven los usuarios finales, con la hora del último reporte por dispositivo, el nivel de batería cuando el hardware lo envía, y cuántos dispositivos llevan fuera de línea más tiempo que una ventana definida.
En TagoIO esto suele ser un Blueprint Dashboard alimentado por tags de dispositivo, así un solo dashboard cubre todos los sitios, con un widget de tabla ordenado por hora del último reporte para que los dispositivos callados queden arriba. Agrega una Action que se dispare cuando un dispositivo lleve más tiempo callado que su intervalo esperado; esa única alerta atrapa baterías muertas, gateways movidos y actualizaciones de firmware olvidadas. Si leer la vista toma más de un minuto, simplifícala.
Documenta la lógica que vive en el código
El umbral es 7.5 porque el ingeniero de procesos del cliente dijo que 8 llegaba tarde y 7 provocaba falsas alarmas en julio. Ese razonamiento vive solo en la memoria de alguien mientras no quede escrito junto al valor. Comenta cada factor de escala y cada conversión de unidades en el Payload Parser. Ponle a cada script de Analysis un encabezado que diga qué lo dispara, qué lee y qué escribe, y quién lo pidió. Donde los umbrales viven en parámetros de dispositivo o en un formulario de dashboard, mantén una tabla con los valores actuales y el motivo de cada uno.
Deja por escrito las convenciones de nombres: cómo se nombran los dispositivos, qué tags son obligatorios (sitio, cliente, modelo de hardware, fecha de instalación), cómo nombra el parser las variables. Media flota etiquetada Site A y la otra mitad site_a rompe toda política y todo filtro de Blueprint que dependa de eso.
Define cómo cambian las cosas
Los despliegues no se quedan del tamaño con el que salieron. Alguien va a agregar un sitio, cambiar el modelo de un sensor o pedir una alerta nueva. Sin un proceso de cambios, cada uno de esos pedidos se convierte en una llamada al equipo de implementación, y el equipo de operaciones aprende a esquivar el sistema en lugar de trabajar con él.
El proceso cabe en una página: cómo agregar un dispositivo (qué Connector y qué Network, qué tags, cómo confirmar que aparece en el dashboard de salud), cómo pedir un cambio de umbral y quién lo aprueba, cómo agregar un usuario de TagoRUN, y qué sigue necesitando al equipo de implementación. Mantén un registro de cambios, aunque sea un documento compartido, para que cuando algo se rompa en octubre alguien pueda ver qué cambió en septiembre.
Agenda una revisión mensual
Los costos y los límites se mueven en silencio. Se agregan dispositivos, un Analysis corre más seguido, cincuenta usuarios abren un dashboard con un rango de tiempo largo, y el consumo de Data Input y Data Output del perfil se acerca al límite del plan. Pon una revisión mensual de 30 minutos en el calendario del responsable de facturación: revisar el consumo de servicios contra el plan, confirmar que la configuración de data retention sigue siendo la que el cliente necesita, contar los dispositivos que no reportan desde hace 30 días, y repasar los pendientes del registro de cambios. Los integradores que se quedan con el rol de operaciones ya lo hacen como parte de un servicio recurrente; es la revisión que mantiene un servicio gestionado rentable en lugar de una fuga lenta de dinero.
Acompaña dos semanas antes de irte
El paquete de arriba es necesario y no suficiente. Los documentos se leen una vez; los hábitos se forman haciendo. Durante dos semanas después del lanzamiento, el equipo de operaciones opera el sistema con el equipo de implementación todavía de guardia: atiende cada alerta, agrega el siguiente dispositivo, corre la primera revisión mensual. El equipo de implementación responde preguntas y, más útil todavía, arregla lo que los documentos no cubrieron mientras el conocimiento está fresco.
Cierra con una reunión corta: recorre el mapa de responsables una vez más, confirma que cada alerta se disparó en una prueba y llegó a la persona correcta, y después saca al equipo de implementación de las listas de destinatarios y de cualquier acceso de Admin que ya no necesite. Ahí el proyecto está terminado.
Checklist de entrega
- Mapa de responsables con una persona con nombre y apellido por fila
- Usuarios de TagoRUN y políticas de Access Management por rol; logins compartidos eliminados
- Entrada de runbook para cada Action que notifica a una persona; destinatarios verificados
- Dashboard de salud (último reporte, batería, cantidad fuera de línea) con alerta de dispositivo callado
- Comentarios en el código del Payload Parser y de Analysis; tabla de umbrales; convenciones de tags
- Proceso de cambios de una página y un registro de cambios
- Revisión mensual de consumo, retención y dispositivos fuera de línea
- Período de acompañamiento de dos semanas con reunión de cierre
