Dependencia de técnicos imprescindibles en un MSP: cómo reducirla

En Star Trek, cuando el capitán Kirk necesitaba algo imposible, siempre acudía a Scotty. Solo Scotty sabía cómo sacarle todo el jugo a los cristales de dilitio, solo él entendía las tripas de la Enterprise y solo él podía obrar el milagro salvador sobre la bocina, con todo en contra. Algo genial para la televisión, pero un desastre como modelo operativo. Porque si Scotty pillaba la gripe klingon, la nave entera quedaba a la deriva.
Eso mismo ocurre en demasiados MSP. Tenemos a nuestro Scotty particular, ese técnico brillante capaz de cargar sobre sus hombros media cartera de clientes y quizá hasta lo celebramos como una fortaleza porque tenemos en nómina a un genio inimitable. Pero como veremos, en realidad es un punto único de fallo humano que nos impide escalar con seguridad.
La especialización técnica es valiosa, eso es indudable, pero cuando cruza la frontera de la dependencia excesiva de personas concretas, deja de serlo. Y la diferencia entre especialización y dependencia es un fallo de diseño operativo, no un problema de talento ni de recursos humanos.

Qué significa realmente depender de técnicos imprescindibles

Sufrimos dependencia operativa cuando el funcionamiento cotidiano del MSP gira alrededor de individuos concretos, en lugar de procesos compartidos.
Esa es la premisa fundamental, porque si el saber crítico vive en las cabezas de esos genios, y no en la base de conocimiento o repartido entre los demás técnicos, nuestro día a día suele estar hecho de:

• Clientes que solamente «entiende» una persona. Porque nadie más ha tocado esa infraestructura, ni sabe por dónde empezar, ya que tampoco se ha documentado en la wiki interna.
• Tareas críticas de mantenimiento que tampoco están documentadas en ningún sitio, salvo en la memoria de quien las realiza desde hace tres años.
• Incidencias que se escalan sistemáticamente al mismo técnico. No porque sea el procedimiento, sino porque nuestro Scotty particular es el único que sabe resolverlas.
• Conocimiento operativo desperdigado. Que vive en chats de WhatsApp, notas mentales, post-its y esa libreta que Laura siempre lleva encima, pero cuyo contenido arcano no aparece en ninguna base de conocimiento compartida.

Si algo de esto nos define, no somos especiales por mucho que nos lo dijeran en el colegio. Se trata de un patrón estructural que se repite con insistencia en muchos MSP y que debemos abordar antes de que nos explote entre las manos.

Señales de que un MSP ya tiene este problema

Los humanos tenemos una habilidad maestra, la adaptación, la cual juega en nuestra contra aquí, porque lo peligroso de la dependencia es que se normaliza.
Como la rana metida en agua caliente, nos acostumbramos sin hacer nada hasta que esta acaba hirviéndonos.
Sin embargo, hay síntomas claros de que debemos saltar a otra forma de hacer las cosas si nos molestamos un poco en mirar sinceramente y no enterrar la cabeza en la arena:
Los principales son:

• Tickets bloqueados durante horas o días hasta que un técnico concreto entra de turno o vuelve de vacaciones.
• Onboarding de nuevos perfiles que se eternizan, debido a que el conocimiento necesario para hacerlo no está escrito y compartido. Este permanece atrapado en conversaciones informales y la experiencia acumulada de los veteranos.
• Vacaciones o bajas que nos ralentizan la operación y generan nerviosismo en el equipo.
• Clientes o entornos que nadie puede asumir con seguridad, excepto los de siempre, convirtiendo cada ausencia que tienen en una ruleta rusa con el SLA.
• Documentación que existe, pero resulta tan genérica o está tan desactualizada, que es inútil para operar en el día a día.
• Dependencia crónica del historial informal. «Pregúntale a Marcos, que fue el que montó eso». Si escuchamos frases así a menudo desde nuestro despacho, tenemos un problema.

El impacto de la dependencia en los SLA, la escalabilidad y la rentabilidad

La dependencia de técnicos imprescindibles es un palo en la rueda del funcionamiento diario, pero también resulta una sangría operativa que afecta directamente al negocio y sus resultados.

Los cuellos de botella

Si solo el genio de turno puede resolver cierto tipo de incidencias, el tiempo de resolución depende de su disponibilidad, cuando debería estar en consonancia con la gravedad del problema.
Cuando esto ocurre, el Tiempo Medio de Reparación (MTTR por sus siglas en inglés) se dispara por razones que poco tienen que ver con la complejidad técnica, y sí mucho con que el conocimiento bajo siete llaves en una cabeza a la que mañana pueden ofrecerle más sueldo en otro lado.

Los escalados innecesarios

Técnicos de nivel 1 que podrían resolver perfectamente una incidencia la derivan todo el rato al «experto», porque nadie les ha proporcionado el contexto que precisan para solventarla.
De nuevo, no es una cuestión de que falte capacidad en esos minions, sino un diseño erróneo de las operaciones del MSP.
Eso empantana a los seniors con tareas de bajo valor. O como he comentado alguna vez, usamos los Ferraris para ir a Mercadona, y estos consumen demasiado y luego tampoco están disponibles para lo importante.

Incapacidad de absorber picos de trabajo o ausencias

Si dos personas concentran el 80% del conocimiento crítico y una se pone enferma mientras la otra está de vacaciones, la operación se tambalea como un castillo de naipes.
Y eso sin entrar en la rotación de personal. Porque cuando uno de esos genios decide marchar a campos que piensa que son más verdes, nos arranca un trozo de nuestra capacidad operativa que nos deja malheridos.

La imposibilidad de escalar de forma robusta

Porque cada nuevo cliente aumenta la carga sobre los mismos hombros de siempre y las espaldas fuertes no son habituales en el gremio informático.
Así no crecemos, engordamos y nos hacemos más frágiles. Tenemos un castillo más grande, pero es de cristal. Así, la eficiencia operativa se degrada con cada nuevo contrato por el que brindamos con champán al principio, para luego gestionar con insanas dosis de estrés.

Cuáles son las palancas para reducir nuestra dependencia operativa

Ya conocemos al enemigo como predicaba Sun Tzu en su Arte de la Guerra, ahora pongamos solución, pero con la advertencia de siempre, que no hay varitas mágicas en la vida real.
Lo que sí hay son palancas claras que debemos accionar.
El marco general de una operación óptima se apoya en cuatro pilares:

• Documentación operativa útil y viva. Que no significa las clásicas wikis fosilizadas que nadie consulta. Estamos hablando de documentación que refleje cómo se opera realmente hoy, actualizada y accesible.
• Estandarización de procesos y entornos. Si cada cliente es un copo de nieve especial, queda bonito como piropo, pero la dependencia de quien conoce cada copo se hace inevitable. La estandarización rompe esa cadena.
• Automatización de tareas repetitivas o sensibles. Lo que una máquina puede hacer con garantías no debería depender de la memoria de un humano, que guarda en esa misma neurona la hipoteca, los hijos y los días malos.
• Visibilidad compartida del contexto técnico y del estado de los servicios. Si todo el equipo ve lo mismo en el NOC, el conocimiento deja de ser secreto y se convierte en datos accesibles que sirven para tomar decisiones óptimas y operar como un reloj.

Ahora, la primera tarea es dar una vuelta por nuestra casa y echar un vistazo honesto a esas cuatro columnas. ¿Cuál se tambalea más? ¿Cuál tiene grietas? ¿Cuál es un andamio provisional pegado con celo, en lugar de una columna?

Cómo reducir la dependencia sin perder calidad técnica

Toda la teoría anterior que he desarrollado es necesaria para ese conocer al enemigo, pero sin un enfoque práctico y progresivo se queda en cosas que solo quedan bien en un Powerpoint.
Así que, una vez revisadas las columnas del templo, bajemos al barro con un proceso aplicable por pasos.

1. Identificar dónde está concentrado el conocimiento

Este es un ejercicio tan sencillo como preguntar: «Si esta persona desaparece misteriosamente mañana, ¿qué se rompe?».
Las respuestas suelen ser reveladoras (y aterradoras en ocasiones).

2. Tener trazado un mapa de tareas críticas y repetitivas

No todas las dependencias técnicas tienen el mismo peso. Hay que distinguir entre lo que es crítico para el servicio y lo que simplemente se hace así porque «siempre se ha encargado Fulanito».
Si es solo cuestión de costumbre y no algo crítico, pasa al final de las prioridades dentro de ese mapa. Y hablando de prioridades…

3. Documentar primero lo más crítico y frecuente

Voltaire dijo que «lo perfecto es enemigo de lo bueno» y, aunque no lo sabía, también hablaba de documentación técnica.
No necesitamos una base de conocimiento perfecta y totalmente terminada para que sea útil. Empecemos por introducir en ella lo que más daño haría si se pierde y lo que más se repite en el día a día.
Eso incluye algo complejo, que los genios de turno con la cabeza llena de sabiduría, la vuelquen para todos de una manera pedagógica.
Aquí entra otro aspecto clave que contribuye a la dependencia: Muchos de esos técnicos serán reticentes. Y más en estos tiempos de incertidumbre donde buena parte de esa dependencia viene porque muchos técnicos quieren hacerse imprescindibles, ya sea por seguridad laboral, estatus, etc.
Con mucha mano izquierda debemos sacar el conocimiento de esas neuronas para volcarlo en una base de conocimiento viva.

4. Estandarizar antes de automatizar

Ahora que nos venden que las máquinas lo harán todo, corremos a poner parches de automatización antes de comprender qué queremos conseguir.
Sin embargo, automatizar un proceso caótico solo produce caos más rápido.
La solución es dejar primero bien claro el comportamiento óptimo o esperado de un proceso, y después ya podemos dejar que lo ejecuten las máquinas.

5. Validar que el resto de técnicos pueden trabajar y resolver sin apoyo constante

De nada sirve tener la Biblioteca de Alejandría si luego nadie es capaz de seguir la documentación del paso 3 sin necesitar al de siempre.
La prueba real de que no tenemos solamente una wiki bonita es que un técnico no llamado Scotty resuelva el problema con autonomía. Si no lo consigue, la documentación no está lista, por mucho que parezca completa.

6. Revisar periódicamente

Las dependencias técnicas en las organizaciones se regeneran como la mala hierba.
Nuevos clientes, nuevas tecnologías, nuevas costumbres… Hay que auditarlas con regularidad para evitar que los malos hábitos vuelvan a cristalizar.

Cómo ayuda Pandora FMS a reducir la dependencia operativa en un MSP

Pandora FMS nació en las trincheras de lo práctico y la experiencia. Eso se nota en cómo aborda, precisamente, este problema de la dependencia, corrigiendo lo que hemos comprobado, durante estos más de veinte años, que la provoca.
Así, la visibilidad centralizada de Pandora FMS permite que cualquier técnico del equipo vea el estado completo de cualquier cliente desde un único lugar, nuestra Metaconsola.
Así, no hace falta molestar al genio de vacaciones para saber qué está pasando, ni rebuscar en chats del año pasado. El contexto está ahí, en una monitorización de infraestructura accesible para todos.
Por su parte, el inventario y el contexto compartido eliminan la necesidad de que alguien se sepa de memoria la infraestructura del cliente. Qué hay, cómo está configurada, cuál es su historial de eventos… Con Pandora FMS todo queda registrado y disponible en el sistema.
Las plantillas reutilizables permiten que el conocimiento operativo se codifique una vez y se aplique a todos los clientes similares. De esa manera, lo que antes vivía en la cabeza de un técnico ahora lo hace en una política que cualquiera puede desplegar.
La automatización operativa integrada en Pandora FMS se encarga a su vez de las tareas repetitivas: self-healing, escalados automáticos, respuestas predefinidas ante condiciones conocidas… Si el sistema sabe qué hacer, no necesita despertar a nadie a las tres de la mañana.
Por otro lado, la trazabilidad de eventos y alertas proporciona un registro auditable de qué ha ocurrido, cuándo y qué se hizo al respecto. Esto significa que un novato recién llegado, o un técnico que cubre la ausencia de otro, puede entender rápidamente el historial sin depender de neuronas que se han ido de vacaciones.
Y en entornos donde la seguridad forma parte del servicio, Pandora SIEM complementa esta visión con correlación de eventos de seguridad y visibilidad unificada, según las mejores prácticas de ENISA y otros marcos de referencia.
La idea central de Pandora FMS es sencilla:
Que la operación dependa del sistema y sus procesos, no de que Scotty obre una vez más el milagro, porque me temo que la vida no es una serie de televisión y mucho menos una utopía.
Un MSP maduro debe cultivar el talento sin generar dependencia, de modo que asegure una continuidad del servicio que no dependa exclusivamente de unas pocas personas, por brillantes que sean.
Insisto en que la brillantez individual es a la vez admirable y un punto único de fallo inaceptable cuando hay SLA que cumplir y clientes que confían en nosotros, por eso premisas como la búsqueda de los famosos ingenieros 10x es un arma de doble filo.
Además, una condición imprescindible para la escalabilidad real es liberar el conocimiento de la mente de individuos elegidos, para ponerlo a buen recaudo en los procesos, herramientas y conocimiento común del MSP.
De esa manera, podremos asumir más clientes, evitar que un soporte reactivo consuma el margen y no necesitar héroes. Al fin y al cabo, se ha demostrado muchas veces que un buen equipo siempre supera a un puñado de superestrellas haciendo la guerra por su cuenta.
Eso es lo que queremos, porque con dependencia técnica tendremos una aventura cada día, pero esas solamente quedan bien en la ficción.