Externalización de servicios IT

Este año visité una gran empresa del sector aéreo que decidió internalizar de nuevo parte del servicio externalizado de infraestructuras IT después de varios años sufrir maletendidos con un proveedor de “los grandes”.

Hace ya unos años la misma empresa decidió también hacer lo mismo internalizar (o realizar un “INsourcing”) del desarrollo de aplicaciones.

La diferencia es que, al internalizar de nuevo, la empresa se decidió por trasladar los servicios de un país Europeo de costes laborales altos a otro país con costes más bajos, pero con personal propio. Además para los datacenters se decidió por un modelo híbrido de cloud privada y pública. Al ser una compañía aérea antigua tiene mucho “legacy”.

Como personalmente me he encontrado con tanta frustración y malentendidos con los contratos de outsourcing de IT siempre me pregunto cómo podrían mejorarse estos contratos para que no acaben tan mal. Y la verdad que no lo tengo del todo claro.

Parece que cliente y proveedor de servicios IT estén condenados al conflicto, pero algo debemos hacer mal cliente y proveedor sino somos capaces de mejorar esta situación.

La responsabilidad de firmar y llevar adelante un buen contrato de servicios es algo que corresponde a ambas partes:

Por parte del cliente

  • Proveer de la información correcta (Inventarios, Volúmenes, costes actuales, documentación, etc) y más detallada posible para que el proveedor pueda hacer una oferta lo más ajustada a la realidad.
  • Ofrecer el tiempo razonable para que el proveedor de servicio puede analizar con tiempo toda la información que se provee y resolver las dudas que el proveedor plantee
  • Disponer del tiempo necesario del equipo de personas que puedan dar soporte al proveedor para realizar la oferta. Una buena solución es considerar el proceso de externalización de servicios como un proyecto con recursos dedicados parcial o totalmente
  • Informar claramente al personal interno directamente afectado por el proceso de externalización sobre su futuro laboral una vez externalizado el servicio para reducir la resistencia al cambio
  • Dependiendo de la duración del contrato, preveer crecimientos o decrecimientos que puedan afectar a los volúmenes establecidos en la línea base del contrato
  • Reconocer que el proveedor de servicio es otra empresa que busca ganar dinero, con sus márgenes de beneficio. No puede haber un buen entendimiento y buen servicio si el cliente piensa en “exprimir” al máximo al proveedor de servicios. Aquí hay mucha empresa final que pretende conseguir del proveedor lo que se conoce como “your mess for less” – te paso mi IT desastrosa, me quito el problema y me lo administras por un menor coste
  • Conocer cómo pretente conseguir las reducciones de costes el proveedor:
    • Economías de escala: No es lo mismo administrar 100 servidores que 1000, pero sin automatización difícilmente conseguiremos reducción de costes
    • Transformar la infraestructura – Automatización y estandarización
    • Contratos de larga duración – para dar capacidad al proveedor de transformar la infraestructura – No puedo pretender entregar al proveedor un “zoológico” de sistemas y que al cabo de un año finalice un contrato con una infraestructura automatizada y con reducción de costes!
  • Pretender personalizar el servicio demasiado … por mucha automatización que pongamos siempre tendremos personas tras un servicio y aquí no tengo claro qué es lo mejor:
    • Queremos únicamente un servicio con un SLA a cumplir, sin importar las personas que hay detrás?
    • O quizás un servicio basado en FTEs (Full Time Employees) con nombres y apellidos ?
    • El personal de nuestro proveedor está exprimido a base de guardias, turnos, sin motivación?
    • Preferimos tener un servicio barato aunque se de desde otro país con costes más bajos?
    • Nuestro proveedor tiene una alta rotación de personal, dificultando el traspaso de conocimiento de nuestros sistemas cuando el personal cambia?
    • Qué pasa con el servicio en periodo vacacional: Por ejemplo trabajando en una empresa turística julio y agosto pueden ser meses pico pero habrá que ver cómo cubre las vacaciones el outsourcer

Por parte del proveedor de servicios

  • No vender “humo”, ser honestos en cuanto a experiencia y capacidad para llevar adelante un proyecto de outsourcing. Exponer claramente en qué se dispone de experiencia con ejemplos y referencias y en qué casos tendremos que “re-inventar” la rueda
  • Proporcionar transparencia en cuanto a las subcontratas, qué contratos tendrá el proveedor con las empresas subcontratadas y cómo se gestionarán a lo largo del contracto de servicio con el cliente final – evitemos un cambio de subcontrata, salvo por motivos justificados, a mitad de nuestro contrato de servicio
  • Comprometerse, tanto en tiempo como en recursos, a una transformación y modernización real de la infraestrutura IT del cliente con indicadores claros de grado de transformación a lo largo del cliente
  • Proporcionar costes unitarios claros del servicio y establecer los volúmenes máximos y mínimos donde aplicarán estos costes unitarios
  • Adaptar los costes unitarios al mundo cloud, por ejemplo de cada vez tiene menos sentido ofrecer costes por tamaño de servidor en un mundo cloud
  • Cómo gestionaremos de forma integral la seguridad de la infraestructura IT – no podemos tener ya parcheos mensuales de servidores
  • Trabajar para satisfacer las expectativas del cliente. Sabremos si hemos hecho un buen contrato y cumplido con las espectativas si, al finalizar el contrato, el cliente se encuentra satisfecho y quiere renovar el contrato porque realmente está contento con el servicio y no por el coste o esfuerzo de salida del cambio de proveedor

No-Trust Infrastructures

La forma tradicional de implantar sistemas IT se ha basado en tener una red interna de confianza considerada “segura”, protegida por uno o varios firewalls y capas de seguridad. Fuera de esta zona, teníamos Internet público y la zona de red insegura.

En la zona segura teníamos hospedados nuestros servidores y sistemas críticos, con sus bases de datos, directorios, datos críticos, etc.

Sin embargo cada vez resulta necesario, por no decir imprescindible conectar nuestros servidores y sistemas internos de la zona segura con el mundo exterior para conectarlos a servicios en el cloud público, APIs, microservicios, etc. Y todos estas conexiones externas han convertido a los firewalls en auténticos “quesos de gruyere” con tanta conexión abierta.

Lo mismo sucede con los equipos de usuario final como PCs, Smartphones o Tablets: Aunque sean equipos de empresa la mayoría de las veces se conectan directamente a Internet desde fuera de la oficina. Ya no sirve que los protejamos suponiendo que se conectarán siempre a través de un proxy o un firewall para acceder a innumerables servicios que, en la mayoría de casos, también son accesibles únicamente a través de Internet público.

Y lo mismo sucede con otros elementos de infraestructura como switches, access points, sensores IoT, impresoras, etc – todos requieren cada vez más conectividad con servicios accesibles por Internet fuera de la red interna de la empresa.

La solución a esto implica un cambio de paradigma y en lo que se basa la filosofía de infraestructura “no-trust”: Ya no podemos distinguir en una zona de red segura y confiable y otra insegura. Debemos considerar todas las redes y sistemas no confiables y preparar la infraestructura y los sistemas para ello.

Cómo securizar las infraestructutras “No-trust”

  1. Securizar cualquier sistema (“Hardening”) desde su puesta en marcha: Ya no podemos esperar a la puesta en producción para securizar los sistemas. El “Security by design” se debe aplicar desde el primer momento que se pone en marcha cualquier sistema
  2. Hacer accesibles a los sistemas únicamente a través de conexiones cifradas y securizadas: SSL / TLS, IPSec, doble factor de autenticación, etc
  3. Cifrar los datos
  4. Parchear continuamente los sistemas. Ya no podemos espesar semanas a securizar los sistemas. Se deben parchear tan pronto como se puedan y se publiquen las vulnerabilidades. Si tenemos externalizada la administración de sistemas debemos asegurar que nuestro proveedor lo cumple por contrato
  5. Retirar inmediatamente los sistemas que no se utilicen

En definitiva debemos diseñar la seguridad de nuestros sistemas, aunque sean internos, para que puedan exponerse a Internet.

Por supuesto por temas de compliance y normativas (PCI-DSS, GDPR, etc) puede ser que aun así tengamos que proteger los sistemas en “burbujas” especiales con una protección dedicada.

Nueva etapa después de casi 13 años en TUI

Ahora que comienzo una nueva etapa en mi vida profesional quiero agradecer a todos mis colegas que han trabajado conmigo estos 13 últimos años su profesionalidad y compañerismo. Os voy a echar de menos.

En ocasiones lo habré hecho mejor y otras peor, pero lo que sí he hecho es ponerle mucho empeño y toda la ilusión a lo largo de estos años.

Me siento muy orgulloso del trabajo realizado entre todos y, como siempre, insisto que lo mejor es complementarse con tu jefe o con los miembros de un equipo.

Y como me dijo uno de mis jefes tenemos tendencia a sobreestimar lo que vamos a conseguir en el corto plazo y a infravalorar lo conseguido en el largo plazo. Aún así aprovecho para hacer un repaso muy rápido de lo que nos ha sucedido en estos últimos años:

La etapa de TUI España

En febrero de 2006 regresé de Barcelona a Palma y empecé a trabajar en TUI España llevando el equipo de Infraestructura IT. Era la primera vez que llevaba un equipo tan grande y para mi supuso un reto.

También era la primera vez que trabajaba en un cliente final en el mundo del turismo, después de 9 años trabajando en EDS – una empresa de servicios IT y outsourcing.

Y ha llovido mucho desde entonces… y cómo ha cambiado la tecnología. Para entonces teníamos:

  • Servidores IBM AIX con Oracle Financials y e-Business suite, cuando llegué finalizaba el traslado del datacenter de la torre Asima en Palma a los datacenters de TUI Infotec en Hannover
  • Lotus Notes como correo electrónico y Blackberry
  • PCs con Windows XP
  • La red de datos se estaba migrando de una red frame-relay de Telefónica a una red MPLS gestionada por T-Systems
  • Desde Palma dábamos servicio a todas las oficinas de destino en TUI España y República Dominicana
  • Se hicieron los primeros pinitos con una web para venta de viajes y también los primeros servicios online.
  • Mi jefe en estas primera etapa fue Luis Valle

En TUI España aprendí lo que era el negocio receptivo, una DMC, los traslados, las excursiones, los distintos TTOO del grupo TUI.

Además de a Luis Valle tuvimos de jefes de IT a Miguel Henales y a Teresa Nicolau con Salva Joval.

Y así seguimos hasta 2009 con la integración entre TUI y Hotelbeds.

IMG_0008.JPG
Trabajando en la Torre Asima – TUI España

IMG_0011.JPG
Toni Martorell y Miguel Mengod trabajando en Asima

La etapa de Hotelbeds

Mi nuevo jefe en Hotelbeds Juan de Dios García me propuso liderar el equipo conjunto de infraestructuras de Hotelbeds y TUI. Y así pasamos el primer año, unificando el equipo y las infraestructuras, con un nuevo traslado de datacenter de Hannover a los de Telefónica en Madrid (Tres Cantos y Julían Camarillo).

Y en Hotelbeds descubrí lo que era el mundo online y la necesidad de tener un buen capacity plan, llegando a tener más de 800 servidores que administrar. Fueron los tiempos de la virtualización con VMWare, Oracle Exadata, Cisco UCS y balanceadores F5. También del 24×7, guardias, incidencias P1 y pases a producción interminables.

También fuimos de los primeros en implantar Office 365 junto con un nuevo directorio activo en todas las oficinas de Hotelbeds en los 5 continentes, dando servicio a casi 10.000 usuarios en todo el mundo.

En infraestructura IT, con casi 40 personas teníamos 4 equipos: Datacenter (Marcelino Martínez), Workplace (Jose María Iglesias), Network (Tòfol Piña) e IT Logistics (Juan Luís Pujol).

equipo juan de dios Hotelbeds.jpg
Equipo de Hotelbeds Technology frente al edificio Mirall

managers.JPG
Jose María, Marce, Juan Luís, Tòfol y Adi

datacenter.jpg
El equipo de Datacenter

Workplace.jpg
El equipo de Workplace

IT Logistics.jpg
El equipo de IT Logistics

nagios
La monitorización en Nagios, mostrando los servicios en verde

Vuelta a TUI – Destination Services

A principios de 2015 Greg Garrison me propone incorporarme a TUI Destination Services  como responsable del equipo de infraestructura.

Han sido los tiempos del proyecto Drive (Separación de Hotelbeds) con la puestas en marcha de nuevos sistemas de nuevo en Telefónica (Julian Camarillo y TecnoAlcalá), separación de oficinas, la puesta en marcha de un nuevo servicio de Servicedesk con Accenture y el inicio de la transición al mundo cloud con Amazon.

Y así ahora tenemos Cloud público, DevOps y automatización (nunca hay suficiente de esto), iPads, iPhones, redes SD-WAN, PCs con Windows 10 y Office 365 con Teams

Smile awars team photo
El equipo recibiendo un Smile Awards por el arranque de temporada – Greg, Inma, Miguel Tugores, Fernando, Marce, Adi, Miguel Mengod, Jose María, Rubén y Ana

L2 Team.jpg
El equipo de Infraestructura – L2 – Inma, Sebas, Toni, Miguel T., Pedro, Ana, Leo, Miguel M. Rubén y Marcos

Team L3 foto 2.jpeg
El equipo de Infraestructura – L3 – Fernando, Jose María, Adi, Gerald, Marce y Carlos

IMG_2719.jpg
Con el equipo del TUI Experience Centre – Vinod, Juanjo, John, Fernando, Marcos y Adi

2018-11-07_20-53-29

Trabajando de noche desde Parc Bit en la prueba de disaster recovery para TUI DX este último año