Búsqueda


5 de noviembre de 2007

Outsourcing, Gobierno TI y Santo Tomás

Ya he comentado más de una vez en alguno de los artículos publicados por aquí que me llama la atención cómo las cosas nunca vienen solas. ¿Será que nos persigue un destino indescifrable?

Escribía hace cuatro días en GobTIC Flash sobre la importancia de COBIT en un entorno externalizado, hoy leía un artículo en la edición de Junio del IS Control Journal sobre la posibilidad (para mí remota) de externalizar la función de Gobierno TI y hoy me llega al buzón una pregunta para el Consultorio GobTIC con un texto como el que sigue:

[...] se está a punto de adjudicar una externalización total de los servicios del área de Sistemas. Pués bien, el viernes me propusieron que fuera el responsable del "gobierno" de los servicios y aquí me asaltarón dudas. ¿Por donde empiezo? ¿Establecemos métricas estilo COBIT para controlar posibles ANS (perdón SLA)? ¿Definimos un catálogo de servicios a prestar? ¿Acabamos de implantar la gestión de la configuración añadiendo, en lo posible, datos económicos no contemplados en su día? ¿A qué santo rezo? [...]

La Incredulidad de Santo Tomás

La respuesta a esta pregunta podría ocupar tomos y tomos, o bien se podría resumir en un simple "Rézale a Santo Tomás", patrón de las Universidades, la enseñanza y de los incrédulos.

Bromas aparte, vamos a ver unas cuantas cosillas que hay que tener en cuenta: lo primero es lo primero, así que si te proponen ser el responsable del gobierno de los servicios, tenemos que dejar claro qué significa Gobierno y qué significa Servicio en tu contexto. Me da la sensación que el término Gobierno en este contexto significa "Supervisión del desempeño del outsourcer", mientras que el término Servicio es más delicado, ya que me hablas de externalizar los servicios del área de Sistemas de una gran organización, luego el concepto Servicio IT posiblemente no sea el que aplique aquí.

Veamos tus reguntas una por una:

¿Establecemos métricas al estilo COBIT para controlar posibles ANS/SLAs?

Ojo con esto, ya que es un error muy común a la hora de pensar en métricas. Siempre que pensamos en métricas acabamos pensando en SLAs y casi se podría decir que no tiene nada que ver (ojo, ¡casi!). Las métricas pueden medir varias cosas, servicios, procesos, cumplimiento de objetivos, etc. COBIT plantea métricas que ayudan a medir procesos y actividades, pero nunca Servicios TI.

De esta forma, podrás establecer métricas de COBIT que te ayuden a definir los SLA de Proceso del proveedor (Resolución de Incidencias, Gestión de Cambios, etc...) pero COBIT no te dará métricas de Servicio TI (rendimiento de la Intranet hospedada y gestionada por el proveedor).

¿Definimos un Catálogo de Servicios a prestar?

¡Ya tardas! Si no existe este catálogo de servicios, la oferta del proveedor será una gran estimación y luego todo serán discusiones. Además, será sobre este catálogo de servicios sobre el que podrás negociar los SLA (la S es de Servicio, no lo olvidemos) y establecer esas métricas de servicio.

Es decir, tal y como me lo imagino, la oferta del proveedor sin catálogo de servicios se podrá comprometer a métricas de proceso (porque se siente que los puede controlar) y a catacterísticas genéricas de los sistemas, pero no puede llegar a comprometerse en métricas concretas de servicios porque no sabe cuáles son.

¿Acabamos de montar la Gestión de Configuraciones?

Oh! ¡Qué bonita pregunta! En el más puro sentido de la externalización, en el momento en que el proveedor tome el control, a tu organización "le importa tres pepinos la configuración"... eso sería lo que uno podría pensar si se creyera de verdad todas las grandes maravillas de la externalización, pero... si te lo crees nunca más cambiarás de proveedor porque te tendrá pillado por donde no te gusta, teniendo él todo el conocimiento relativo a la infraestructura y las relaciones entre componentes.

Osea, o te aseguras una devolución perfecta del servicio externalizado a la finalización del contrato, o mejor quédate con el conocimiento de la configuración.

¿A qué santo le rezo?

Lo dicho, a Santo Tomás.

Para mi, la actividad principal debe ser la de supervisión del desempeño del outsourcer, junto a la definición, supervisión y mejora de los modelos de relación entre las organizaciones. Es decir, no creo que sea suficiente monitorizar los SLAs y "apretarle las tuercas" al proveedor cuando no se cumplan algunos de los indicadores, sino que se debe realizar una acción continuada sobre la relación, los procesos y los requerimientos del negocio sobre los servicios TIC que tienes externalizados.

Para acabar, una recomendación sobre las métricas: centrate en las métricas que te sirvan para gobernar (valga la redundancia) los servicios y la relación con el proveedor y deja las métricas de operación para el proveedor: es su trabajo.

Por ejemplo, en un proceso de Gestión de Incidencias, es fácil ver la métrica de "tiempo de primer contacto" o la métrica de "porcentaje de resolución en primer nivel de soporte"... a ti, como cliente, ¿realmente te interesa ese tipo de métricas? Seguramente te interesará una métrica del tipo "% de incidencias resueltas dentro de plazo".  Cuando este indicador no funcione bien, será el proveedor quien tenga que investigar en el valor del "tiempo de primero contacto".

PD: Me preguntabas en tu mail si se debería tener en cuenta a la gente de procesos y metodologías para esta labor: ¡¡POR SUPUESTO QUE SI!! Además, seguro que podrán ayudar un mucho en la definicion de controles, auditorias, indicadores, políticas, etc.

2 comentarios:

Jorge Fernández González dijo...

Pues tienes razón, hay algo que esta en el ambiente, porque yo tengo un articulo recien escrito para la revista GdR, que trata de outsourcing total de la funcion de BI. Esta a puntito de salir, en cuanto este te lo linko.

Todo encaja, incluso el Santo Tomás ¿que Tomás? yo una cocacola.

bexternalizacion dijo...

Hablando de outsourcing, para aquellos que Quieran hacer (o hacen) outsourcing? Los recursos e información que necesitas están en http://www.outsourcingfacil.es una web que recomiendo mucho para abordar este tipo de terminología.