Cambiar de proveedor TI sin hacerte daño

Cinco cosas que asegurar antes de preavisar

• Acceso de administrador a tus propios entornos. Tu inquilino, tu cortafuegos, tu consola de copias. No compartido con el proveedor, en tus manos.
• Documentación e histórico de tickets. Una exportación, en un formato legible. El histórico vale más de lo que la gente espera, porque contiene los problemas recurrentes.
• Licencias a tu nombre. Las licencias compradas a través de un proveedor y registradas a su nombre son, con diferencia, lo que más veces convierte una transición en una negociación.
• Un registro de activos que coincida con la realidad. Números de serie, fechas de garantía, qué está en renting y qué es propiedad.
• El plazo de preaviso, por escrito. Lee el contrato antes de la conversación, no después.

Las cinco se consiguen más fácilmente mientras pareces un cliente satisfecho que después de haber preavisado. No es cinismo; es simplemente cómo funciona la posición negociadora.

Las tres fases de una transición

La fase que se intenta saltar es la de trabajo en paralelo, normalmente para ahorrar. Es la fase que decide cómo se recuerda el cambio, porque la experiencia de usuario de una transición se forma entera en las dos primeras semanas.

Ten claro qué es realmente tuyo

Tres categorías causan casi todas las disputas al final de un contrato. Licencias compradas a través del proveedor y registradas en su cuenta de partner. Hardware que resulta estar en renting y no en propiedad. Y herramientas de monitorización o copia que pertenecen al proveedor, lo que significa que tu histórico se va con ellos.

Nada de eso es necesariamente abusivo, y buena parte es práctica normal. Solo se convierte en problema cuando nadie comprobó en qué categoría cae cada cosa hasta después de preavisar. Pregúntalo ahora, mientras es una pregunta rutinaria y no una posición de negociación.

La documentación es el entregable de verdad

Una transición sale bien o mal según cuánto haya escrito. Contraseñas en un gestor gestionado y no en la cabeza de alguien. Un diagrama de red que coincida con el edificio. Una lista de proveedores con fechas de contrato. Qué aplicaciones se autentican contra qué.

Si el proveedor actual no puede producir eso, la parte entrante tiene que reconstruirlo, y ese es el coste que encarece una transición, no el cambio en sí. Es también, dicho sea de paso, el mejor argumento para mantener la documentación como entregable vivo en cada contrato en lugar de como obligación de salida.

Cuándo cambiar es la respuesta correcta y cuándo no

Cambia cuando los mismos problemas se repiten sin que se aborde la causa de fondo, cuando el informe no te dice nada sobre lo que puedas actuar, cuando no consigues una respuesta honesta sobre algo que salió mal, o cuando el proveedor te ha superado en tamaño y ahora eres su cliente más pequeño.

No cambies por un único incidente malo. Todo proveedor tiene un mal mes, y el coste de la transición es real. La pregunta que merece la pena es si la respuesta al incidente fue honesta, porque eso predice mejor que el incidente en sí.

Qué hacemos nosotros al asumir el relevo

Empezamos por el inventario, y decimos con claridad lo que encontramos, incluidas las cosas que la parte anterior hizo bien. Eso importa, porque un proveedor entrante que critica todo suele estar planeando venderte un sustituto de todo.

Después un periodo en paralelo, y después el cambio con la ruta antigua abierta dos semanas. La documentación es un entregable desde la primera semana y no una promesa, y el registro de activos se reconstruye como parte del traspaso en lugar de darse por bueno.

Lo que asumimos se describe en servicios gestionados TI y service desk TI, y el ritmo de informes en gobierno de servicio.