05.- Sitio fallido

Hay dos palabras que nadie quiere escuchar cuando trabaja programando telecomunicaciones. Sitio fallido.

Hace tres sábados, el 8 de agosto, cerca de las ocho de la mañana, cuatro personas de nuestro equipo llegaron a un supermercado en Las Condes con cerca de cuatro toneladas de andamio arriba del camión. Para llegar ahí a esa hora el trabajo había empezado bastante antes, con el material preparado, el camión cargado, la cuadrilla programada, el cliente coordinado, el acceso gestionado y Administración informada. Ese sitio, además, solo permitía trabajar los fines de semana, así que esa era la única ventana. Todo estaba listo. O eso creíamos.

El guardia que recibió a la cuadrilla acababa de entrar a su turno y no tenía el correo de Administración autorizando nuestro ingreso. Nosotros sí lo teníamos, se lo mostramos, se lo reenviamos, llamamos, y Operaciones empezó a buscar contactos para ubicar a alguien de Administración que confirmara de nuevo algo que, en teoría, ya estaba confirmado. Nada. El guardia tenía una instrucción bastante simple, si Administración no le mandaba el correo a él directamente, no entraba nadie, y mirándolo desde su procedimiento tenía razón. Nosotros también teníamos razón, el permiso estaba gestionado, el cliente sabía que íbamos, la cuadrilla y el material estaban ahí, el correo existía. Todos podían demostrar que habían hecho su parte. Igual la puerta no se abrió.

Y no es que uno simplemente diga "ya, no pudimos entrar, vámonos". Cuando tienes cuatro personas, un camión y toneladas de material movilizadas, haces todo lo posible por salvar el sitio, llamas, escalas, buscas otro contacto, esperas, vuelves a revisar, intentas un plan B, hasta que llega el momento en que la ventana simplemente se acaba. Ese sábado, las mismas cuatro personas que se habían levantado temprano terminaron devolviéndose con exactamente las mismas cuatro toneladas con las que habían salido. No pusimos un solo fierro. Sitio fallido.

Quienes tuvimos un Atari 400 u 800 y cargábamos juegos desde cassette reconocemos esa misma sensación. Ponías la cinta y, entre el chirrido y la espera, empezaba una cuenta regresiva que, siendo niño, parecía eterna, porque uno no quería entender de tiempos de carga, quería jugar. Y lo peor era cuando el contador ya estaba llegando a cero, cuando faltaba nada y después de toda esa espera uno estaba prácticamente listo, y de pronto aparecía la palabra error. Rebobinar, volver a cargar, empezar otra vez.

La diferencia que ese recuerdo tiene con la realidad es que acá, en el día de hoy, cuando algo falla no perdiste unos minutos frente a una pantalla y no se puede rebobinar para empezar nuevamente. Hay combustible, horas, un camión, una cuadrilla, coordinación, un cliente esperando y técnicos que tenían una ventana acotada para trabajar. Y hay un costo que para mí es incluso mayor, todo lo que dejaste de hacer mientras intentabas salvar ese sitio, porque las cuadrillas no son infinitas, los camiones tampoco, y las horas del día menos todavía. Mientras ese equipo pasa una o dos horas tratando de abrir una puerta que debía estar abierta, no está disponible para otro sitio, y en telecomunicaciones muchas veces ese otro sitio también está esperando, una antena que necesita intervención, una zona con problemas, un técnico con pocas horas para trabajar, un cliente que necesita poner nuevamente un sitio al aire. Por eso perder un sitio no significa perder solamente ese sitio, a veces significa perder también parte de la capacidad que tenías para resolver el siguiente.

Durante años peleamos contra eso, y llegamos a tener cerca de un 30% de sitios fallidos dentro de nuestra programación. Hoy nos movemos alrededor del 7% mensual, y esa baja llegó cuando empezamos a entender que conocer una antena era bastante distinto de conocer realmente un sitio. Con el tiempo fuimos armando algo así como una bitácora invisible del sitio, cosas que probablemente nunca aparecerían en un plano, quién abre, qué llave funciona, si alguien cambió la clave del candado, qué horario tiene el administrador, cuándo cambia el turno del guardia, a qué hora se llena un estacionamiento, en qué momento se puede trabajar sin interrumpir un hotel, qué documentación exige un club, qué ocurrió la última vez que estuvimos ahí, y también algo tan simple como qué día se pone la feria en esa calle. Podemos conocer la altura de la torre, saber cuánto material necesitamos, tener el permiso aprobado, la cuadrilla disponible y el camión cargado, pero si la feria empieza a instalarse a las siete de la mañana y nosotros programamos la llegada a las ocho, probablemente ya llegamos tarde. Quizás podamos entrar, el problema es que después no tendremos cómo salir. La ingeniería puede estar impecable. Sitio fallido.

Esa misma bitácora nos enseñó algo bastante simple, el plano te dice dónde está la antena y la historia del sitio te dice cómo llegar a ella. Ahí es donde entra una figura que yo llamo, medio en broma y con cariño, la señora Juanita. No necesariamente es una señora y probablemente no se llama Juanita, puede ser la presidenta de una junta de vecinos, el conserje de un edificio, el administrador de una cancha, la persona que lleva veinte años viviendo ahí y sabe dónde está la segunda llave. En el sistema puede aparecer acceso aprobado, pero después llegas a terreno y descubres que ahí manda quien sostiene el manojo de llaves. Por eso para mí hay una diferencia enorme entre un permiso, que es información, y saber quién realmente abre la puerta, que es conocimiento.

Esa distinción tiene otra capa que durante años las telecomunicaciones no siempre supimos manejar bien. Todos queremos señal, queremos llamar, queremos internet, queremos conectividad cuando ocurre una emergencia, pero no siempre relacionamos ese servicio con la infraestructura física que tiene que existir para hacerlo posible. Nos ha tocado llegar a lugares donde la comunidad no quería una antena, donde había desconfianza, donde primero tuvimos que explicar quiénes éramos, por qué estábamos ahí y qué estábamos haciendo, y ahí fuimos entendiendo algo más, que la comunidad no vive alrededor de nuestra programación, somos nosotros los que trabajamos dentro de la comunidad. Eso cambia la forma de operar, porque hay sitios donde hay que llegar antes de que se llene un estacionamiento, otros donde existe una ventana muy acotada para no interrumpir el funcionamiento del lugar, calles donde una feria cambia completamente la programación, y comunidades donde la relación previa puede ser la diferencia entre una puerta que se abre y otra que no.

En el sur la misma lógica cambia de escala. Hay operaciones completas que no se activan hasta que un eslabón externo confirma que sí, y recién entonces empiezan a moverse personas, materiales, pasajes, cliente y ventanas de trabajo detrás. Lo importante no es el tamaño de la dependencia, puede ser un ferry, una feria, un correo o una llave. Porque después de tantos años entendí que hay una parte de la infraestructura crítica que nadie dibuja. No está necesariamente en el acero, en la fibra o en la antena. Está, muchas veces, en el espacio entre una cosa y la siguiente, entre Administración y el guardia, entre el permiso y la puerta, entre la programación y el territorio real, entre la infraestructura y la comunidad, entre lo que alguien cree que entregó y lo que el siguiente efectivamente recibió. Y muchas veces la fragilidad está precisamente ahí, entre las cosas.

Ese sábado en Las Condes nadie necesariamente hizo mal su trabajo. Administración había autorizado, Accesos había gestionado, Operaciones había programado, Logística había cargado, la cuadrilla había llegado y el guardia estaba cumpliendo su procedimiento. Cada uno podía marcar su parte como realizada, y aun así el resultado final fue cero. Y esa es una pregunta que creo que va mucho más allá de las telecomunicaciones, ¿quién se hace responsable de aquello que ocurre entre dos responsabilidades?

Porque podemos llenar una empresa de indicadores, con Operaciones cumpliendo su KPI, Logística cumpliendo el suyo, Administración cumpliendo el suyo, el cliente cumpliendo el suyo, y aun así el sistema puede no entregar el resultado para el cual todas esas áreas existen. Quizás estamos midiendo muy bien las partes y bastante menos aquello que las conecta. Para mí ahí empieza a cambiar la manera de mirar la infraestructura crítica, no solamente preguntarnos si el activo funciona, también empezar a hacer visibles sus dependencias, conocerlas, registrarlas, anticiparlas, tener una alternativa cuando el plan A se cae, entender que algo tan aparentemente irrelevante como una llave, un turno o una feria puede ser tan determinante para la disponibilidad real como cualquier componente técnico.

Eso es parte de lo que nos permitió pasar de cerca de un 30% de sitios fallidos a alrededor de un 7%. Todavía queremos llegar a cero, y probablemente sea lo más difícil, porque siempre va a existir una variable que no controlamos, pero cada dependencia que conseguimos entender significa menos personas levantándose de madrugada para volver sin haber podido trabajar, menos camiones moviendo toneladas para nada, menos técnicos esperando, menos dinero perdido, y más capacidad disponible para resolver el sitio siguiente.

Nosotros seguimos llamándolo sitio fallido, pero después de tantos años creo que el nombre a veces engaña. Porque lo que suele fallar ahí, más que un sitio o una persona, es la conexión entre todas las cosas que tenían que hacerlo posible. Puede estar la ingeniería, puede estar el permiso, puede estar el cliente, puede haber cuatro toneladas de fierro esperando afuera, y aun así, a veces todo depende de algo tan simple como que alguien abra la puerta.

Y a veces, inevitablemente, esa puerta no se abre.

Sitio fallido.

*Artículo publicado originalmente en el Boletín Armatec de LinkedIn