Existe un tema recurrente que aparece en todos los debates entre profesionales de la gestión tecnológica o CTO: la externalización (o no) de labores de la empresa. Algunos profesionales consideran que es una buena forma de ahorrar costes de personal mientras que otros huyen a toda velocidad de la externalización por el miedo a perder el control del producto y a no conseguir los resultados buscados.

Lo cierto es que cada proyecto es un mundo, cuenta con sus propias características y por defecto no es aplicable ninguna de estas dos valoraciones de forma inmediata. No es fácil saber cómo podemos externalizar de manera ideal una parte de un proyecto sin cometer errores básicos en el proceso, pero la experiencia me ha ayudado a entender algunas claves de este ecosistema que me permiten hacerlo con efectividad.

¿Cuándo se puede externalizar y cuándo no un proyecto de IT? La respuesta es relativa al estado del proyecto. ¿Es 100% nuevo? ¿Es continuidad de algo que ya tenemos en marcha? ¿Contamos con profesionales internos que pueden ejecutarlo? ¿Cuáles son las exigencias internas que debe cumplir el proyecto y cómo se podrían cumplir al cien por cien con una externalización?

Hechas estas preguntas, no pocos compañeros y compañeras CTO me han comentado que evitan externalizar porque pierden el control del producto y el calendario, y eso termina afectando al desarrollo del proyecto. Siempre que se me ha dicho esto he continuado con una pregunta: ¿Existe alguna figura en tu equipo que actúe como enlace entre el equipo interno y el equipo externo? La respuesta es no.

En ocasiones acudimos a la externalización como una vía para quitarnos de problemas y olvidarnos de ellos. Error. Cuando externalizamos estamos creando un nuevo brazo de nuestra empresa y estamos en la obligación de supervisar de manera minuciosa como si fuera otro departamento. Es sencillo: crea una figura profesional en tu equipo que controle tiempos, marque objetivos y gestione el proyecto.

Este profesional debe hacer seguimiento del proyecto, mantener reuniones periódicas con la empresa donde se ha externalizado el servicio, conocer a los profesionales que van a trabajar en ello y establecer, poco a poco, el plan de trabajo. No debe ser visto como un intruso, que a veces pasa, sino como un aliado que va a garantizar que la relación profesional entre empresas sea a largo plazo.

Es muy fácil externalizar un producto y echar la culpa a otro cuando los resultados no acompañan. La realidad es que si conseguimos establecer un guión de trabajo y supervisamos el proyecto, los resultados acompañarán. Esta supervisión debemos entenderla como una labor de coordinación, no como un trabajo de guardería: la empresa externa debe ser autosuficiente para funcionar en el día a día, que para eso estamos cubriendo el coste del servicio.

Hay que conocer cómo funciona un aliado externo antes de meterse de lleno a trabajar con él. Para ello, recomiendo aproximarse a su equipo humano, conocer los perfiles profesionales que llevarán nuestro proyecto a interactuar. Pedir recomendaciones también ayuda, pero no es viable en todas situaciones. Es algo que podemos solucionar conociendo a nuestro aliado más allá de los presupuestos.

¿Estoy de acuerdo en externalizar? Sí. ¿En todos los casos? No. Creo que es algo que se debe evitar cuando el proyecto es uno de los focos principales de la empresa y no por ausencia de profesionales que puedan apoyarlo, sino porque en productos o servicios troncales que inician es mejor hacerlos rodar con nuestro propia cabeza. Nosotros sabemos lo que queremos mejor que nadie.

Decía que externalizar ahorra costes, pero si no se hace con inteligencia puede terminar aumentando la inversión por costes derivados. Como se suele decir, lo barato sale caro, así que espero que estos consejos sirvan para pulir las estrategias de las empresas a la hora de externalizar servicios IT.  ¿Qué opináis sobre la externalización? ¿Habéis tenido malas o buenas experiencias?