Búsqueda


30 de enero de 2012

Visión sistémica en el outsourcing – o nos crecen los enanos

Llevo varios meses trabajando con diversas empresas que se encuentran en una situación de outsourcing con múltiples proveedores. Cada una tiene sus características, sus situaciones especiales, si carácter; pero eso sí, hay algunos detalles que son factor común. Uno de estos puntos en común es la dificultad que tienen para gobernar los contratos con proveedores de servicios que están trabajando en diferentes áreas.

Cuando una empresa se plantea externalizar parte del trabajo que se realiza debe tomar una primera decisión: ¿por dónde pasamos las tijeras?  ¿cómo “troceamos” el modelo de provisión de servicios al cliente interno para asignar partes de este trabajo a terceros? Básicamente, hay tres respuestas a esta pregunta:

Opción 1:  trocear por servicios – Se le asigna a un proveedor la entrega de un servicio completo, extremo a extremo, hacia el cliente interno. Es una práctica muy poco (o nada) empleada en IT, pero sí que se ve en otras áreas de negocio, donde se le llama Business Process Outsourcing o BPO.

Opción 2: trocear por funciones – Se le asigna a un proveedor la ejecución de una función (un grupo de personas con un cuerpo de conocimiento específico). Esto es lo más habitual en el entorno de IT, y así vemos a terceros realizando “Gestión de Infraestructuras”, “Gestión del puesto de trabajo”, “Gestión de Aplicaciones”, etc.

Opción 3: combinar las dos anteriores con un reparto regional – Cuando la empresa está localizada en múltiples sedes o en diferentes países, se puede realizar una aproximación en la que se asigna una función o un servicio por región geográfica (por ejemplo, la “Gestión del puesto de trabajo” para la región de “Sur de Francia”)

Una vez tomada la decisión, viene la siguiente fase: la creación de los contratos; aquí ya se empieza a diversificar el asunto, y normalmente serán los responsables de las diferentes funciones (del área TI interna) quienes definan los requerimientos para estos procesos de externalización, resumiendo en pliegos o RFPs las necesidades y las primeras guías de cómo se va a gobernar la ejecución del contrato (aparecen los primeros indicadores, los primeros borradores de niveles de servicio y de SLAs, etc)

Si nos fijamos bien, en este momento del proceso comienzan a sentarse las bases de lo que será en el futuro el “nuevo modelo de prestación de servicios” de IT a su cliente (a.k.a. “el negocio), y aquí es donde comienzan a sentarse las bases de los futuros problemas de gobernabilidad: lo que en una primera fase fue la definición holística de un modelo ahora se ha traducido en una contratación por partes y de ahí viene el título de este post: es necesario mantener una visión sistémica del conjunto y es necesario transmitir esa visión sistémica a la contratación por partes.

¿Nunca has tenido la sensación de que gobernar tu departamento de IT se parece a una partida de Whacka-Mole?

Básicamente, la sensación viene producida porque cuando aprietas en un sitio, el problema sale por otro lado… y la razón simplemente es que, a pesar de que en la superficie los contratos con tus diferentes proveedores sean inconexos, por debajo están conectados; entre ellos, con nosotros, con los clientes, con las personas; formando una intrincada red de túneles por las que se mueven los topos, los enanos, los problemas, el dinero y siempre aparecen por donde menos te lo esperas.

Es por esta razón por la que debemos adoptar una visión sistémica, de sistema, de todo lo que ocurre en este entorno.

Yo creo que el mejor ejemplo que se puede dar para entender esto es poner un caso simple: una empresa que tiene un equipo interno de Sistemas (que se encarga de la gestión y administración de las infraestructuras, sistemas operativos, máquinas, middleware como las bases de datos o los servidores web, comunicaciones…), un proveedor externo que se encarga del soporte al usuario y otro proveedor externo que se encarga de la gestión de aplicaciones.

Aquí vemos un sistema formado por 3 componentes (a gran escala) que colaboran entre sí para entregar un conjunto de servicios TI al cliente y que se ven regulados por una serie de contratos. Veamos cómo son estas reglas de juego (simplificadas en aras de que se comprenda bien el ejemplo, claro!)

EQUIPO

RESPONSABILIDAD

OBJETIVOS

SISTEMAS

Mantener las infraestructuras en marcha con los niveles adecuados de capacidad y disponibilidad

Disponibilidad de los Sistemas

Rendimiento de los sistemas

SOPORTE

Atender las incidencias y peticiones de los usuarios

Resolución de incidencias en plazos

Ejecución de peticiones en plazos

GESTION APPs

Mantener y evolucionar las aplicaciones de negocio

Cumplimiento de plazos y presupuestos de desarrollo

Ante esta situación, si pretendemos gobernar el sistema mediante el uso de indicadores y SLAs nos encontraremos con que:

  1. A pesar de tener una correcta disponibilidad y rendimiento de los sistemas, los usuarios pueden estar completamente descontentos (es necesario incorporar una figura que vele por el servicio extremo a extremo, independientemente de las 3 funciones que tenemos en el ejemplo)
  2. El proveedor de soporte… ¿cómo nos factura por el servicio? Evidentemente, es justo que a mayor carga de trabajo nos pueda facturar más; sin embargo, la mayor carga de trabajo puede ser generada en otras de las funciones (que, en el caso de Gestión de Aplicaciones es otro proveedor al que no le interesa lo más mínimo reducir la carga de trabajo de Soporte)
  3. El proveedor de desarrollo, ¿qué objetivos tiene? Cumplir plazos y ajustarse al presupuesto. Simplemente eso.

Así, en este ejemplo vemos rápidamente que la tarea del CIO será hacerse con un martillo y comenzar a golpear enanos que le irán creciendo eternamente… cambiará 1, 2… hasta 7 veces de proveedores y seguirá con el martillo porque la causa no es una incompetencia del proveedor, sino un sistema diseñado para fallar. Apretará al de soporte, pidiéndole que resuelva en plazos y el de soporte hará hasta que los números se lo permitan. El de desarrollo cumplirá plazos y presupuestos, pero a costa posiblemente de producir desarrollos de baja calidad que llenarán al SAU de llamadas o que malgastarán los recursos de sistemas hasta tener que ampliar máquinas una y otra vez. Ahorraremos en un sitio, pero los costes se irán a otro lado.

¿Y todo esto por qué? Porque los objetivos individuales van en contra de una visión de conjunto. Al tener objetivos individuales en cada contrato, estamos rompiendo la visión de sistemas y estamos primando la creación de silos verticales. Además, no nos engañemos: el objetivo de cada uno de los proveedores de servicios será siempre, salvo contadísimas excepciones, “barrer para casa”, así que o imbuimos la visión sistémica desde el principio, en el propio diseño de “por dónde paso las tijeras” y añadimos esa visión en los contratos y en la operativa diaria, construyendo equipos focalizados no en el cumplimiento de indicadores parciales sino en la entrega real de valor al cliente, o estaremos toda la vida dándole golpetazos con un martillo a los enanos que nos crecen por todas partes. Por ejemplo, podríamos:

  1. Hacer co-responsable al proveedor de desarrollo de las implicaciones de su software en soporte y en sistemas.
  2. Hacer que el proveedor de soporte sea co-responsable de la mejora continua de las aplicaciones y los sistemas.
  3. Hacer que el equipo de sistemas sea co-responsable en la definición de arquitecturas y estándares para apoyar al equipo de desarrollo.
  4. Hacer que todos tengan responsabilidad sobre indicadores globales de servicios extremo a extremo.
  5. Establecer responsabilidad transversal de la entrega de servicios entre las diferentes funciones.
  6. Establecer, como decía Walter en una de las presentaciones del itSMF Catalunya 2011, un único indicador: satisfacción del cliente. Perder un poco el foco en el cumplimiento de SLAs y poner el foco en lo que nos importa: el cliente

Ya lo decía Jim Womack en una de sus últimas conferencias: EL problema es que el poder y el control se ejerce verticalmente, cuando el valor al cliente fluye horizontalmente. ¡¡Gestionemos la horizontal!!