Externalizar la administración de sistemas: qué cedes y qué te quedas

Qué es la administración de sistemas y dónde termina

Administrar sistemas es mantener en marcha lo que hay debajo de los puestos de trabajo: servidores y máquinas virtuales, el sistema operativo que corre en ellos, las actualizaciones, los permisos de los usuarios, la copia de seguridad y la vigilancia que avisa de que algo se rompe antes de que alguien llame.

Eso es otra cosa que un service desk. El service desk es la conversación con tu compañero que ya no llega a sus archivos; la administración de sistemas es la razón por la que llega o no llega. En organizaciones pequeñas la misma persona hace las dos cosas, y ahí es justo donde se confunden, con el resultado de que el trabajo de mantenimiento siempre pierde frente al teléfono que suena.

Esa distinción es el núcleo de esta decisión. Puedes externalizar el service desk y quedarte la administración, o al revés, o las dos. Lo que no puedes es externalizarlo sin nombrar de cuál de las dos hablas. Cómo montamos la primera está en service desk TI.

Las tres razones por las que llega a la mesa

En las conversaciones que tenemos, esta pregunta casi siempre viene de una de tres direcciones, y rara vez de un plan.

• Hay una sola persona que lo sabe todo. Lleva diez años, lo resuelve, y nadie más puede entrar. No es una crítica hacia ella: es un riesgo que la organización ha dejado crecer. Mientras esté, funciona de maravilla, y por eso mismo no se hace nada al respecto.
• No hay cobertura fuera de horario. Una incidencia a las seis y media de la tarde es una llamada a un móvil particular. Eso funciona hasta la vez que no.
• El trabajo que nunca se termina. Parchear, documentar, limpiar cuentas que ya no usa nadie y demostrar una vez al año que una copia de seguridad se puede restaurar de verdad. Es el trabajo que cede en cuanto aparece algo urgente, y siempre hay algo urgente.

Solo la tercera es motivo para cambiar algo estructural. Las dos primeras también se resuelven con un segundo administrador o con un acuerdo de guardias: más caro por hora, pero sin traspaso. Lo decimos en la conversación, porque un proveedor que solo conoce su propia respuesta no es un asesor.

Qué cedes y qué te quedas

Aquí es donde más fallan los contratos, porque no se pone por escrito.

Lo que pasa a otras manos es la ejecución. Actualizar los sistemas, vigilarlos, gestionar cuentas y permisos, la copia de seguridad y la restauración desde ella, y la disponibilidad fuera de horario. Es trabajo con un ritmo y un resultado demostrable, y se deja traspasar.

Lo que se queda es la decisión. Qué proveedor eliges, cuánto gastas, qué riesgo asumes y cuándo se sustituye algo. Eso pertenece a la organización que carga con las consecuencias. Un proveedor de gestión que se lo queda entrega comodidad a corto plazo y dependencia a largo, y por eso mismo esta pregunta vuelve a la mesa dentro de cinco años.

En la práctica se reduce a un acuerdo que quieres por escrito: podemos hacer todo lo que caiga dentro de los límites pactados, y todo lo que quede fuera te lo presentamos. Eso hace que la separación sea practicable y no teórica.

Dónde está el coste

Los importes no aparecen en esta web; la estructura sí, porque ahí están las sorpresas.

La gestión casi siempre se cobra por unidad: por puesto, por servidor, por usuario o una combinación. Es transparente mientras sepas qué entra en una unidad. Las dos preguntas que hay que hacer: la recuperación tras una incidencia, ¿entra en ese precio o queda fuera? Y un usuario con dos dispositivos, ¿cuenta como uno o como dos?

Luego está la transición misma. Asumir un entorno cuesta trabajo antes de gestionar nada: inventariar, documentar, limpiar lo que nadie reconoce. Un proveedor que lo ofrece gratis no lo hace, o lo cobra en otro sitio. Nosotros lo presupuestamos aparte y decimos cuánto dura.

Y luego el lado que rara vez llega al papel. ¿Qué te cuesta ahora que no se parchee, que no se haya probado ninguna restauración y que una sola persona pueda irse de vacaciones? No son partidas de un presupuesto, pero son la mitad de la ponderación.

Dónde falla un traspaso en la práctica

Cuatro cosas, en el orden en que nos las encontramos.

• El entorno no está escrito. No hay un inventario de qué corre, qué licencias están vivas y quién tiene qué permisos. Es lo normal y no es ninguna vergüenza, pero tiene que hacerse primero. Un proveedor que empieza sin inventario está adivinando.
• El administrador que se va no participa. Este es el error caro. Lo que él sabe no está en ninguna parte, y después de su último día ya no está. Cuéntale, págale por ello si hace falta, y haz que el traspaso se solape en lugar de encadenarse.
• La expectativa es 24/7 y el acuerdo no lo es. Lee qué dice sobre tiempos de respuesta fuera de horario y qué significa "respuesta": alguien que mira, o alguien que resuelve.
• La limpieza se aplaza. Siempre hay una lista de cosas para "más adelante". Ponle fechas, o esa lista será la misma dentro de dos años, solo que más larga.

Lo que hacemos antes de asumir nada está en servicios gestionados TI: primero inventariar y escribir lo que encontramos, incluido lo que el proveedor anterior hizo bien, y solo después acordar un traspaso.