Subcontratando el riesgo

Tanto el blog de Joseba Enjuto como el de Javier Cao tienen un sitio preferente en mi lector de feeds, así que he podido leer en estos días un par de artículos muy interesantes: Caracterizar un Servicio, de Joseba y una reflexión generada por este primer artículo llamada La Subcontratación del Riesgo de Javier.

En ambos artículos se habla de la componente de riesgo que hay en la externalización y Javier acaba con una frase matadora:

Por que de lo contrario, cuando el Responsable de Seguridad vaya a comprobar qué ha pasado, podrá encontrarse al Steve Urkel de turno diciendo ¿he sido yo? y la cabeza a cortar será la que quien contrató un servicio inadecuado.

Es decir, que no se puede subcontratar o externalizar "a lo loco", sino que siempre debe quedar una capa de control y supervisión dentro de la propia organización para garantizar que se realice un seguimiento adecuado de lo que se ha contratado fuera.

Aquí (como en tantos otros sitios) COBIT nos puede ayudar. El Objetivo de control de alto nivel DS2 indica que se deben gestionar las relaciones con terceros. Fijémonos qué nos dice en la descripcion del OCAN

La necesidad de asegurarse de que los servicios proporcionados por terceros cumpla con los requerimientos del negocio requiere de un proceso de gestión apropiado. Este proceso se cumple mediante la correcta definición de roles, responsabilidades y expectativas al respecto de los acuerdos con terceros, así como revisando y monitorizando dichos acuerdos buscando su efectividad y cumplimiento. Una correcta gestión de estos servicios minimiza los riesgos asociados a proveedores poco efectivos o productivos.

Ajá! Una correcta gestión de los servicios minimiza los riesgos asociados a los proveedores... vamos bien. ¿Y los objetivos de control detallados?

DS2.1 Identificación de las relaciones con proveedores. Básicamente, mantener un catálogo de proveedores "homologados" con información al respecto del tipo de proveedor, solvencia, significatividad y criticidad.

DS2.2 Gestión de la Relación con proveedores. Asegurarse de que el proceso de gestión de relación con proveedores está en marcha para cada uno de los proveedores de nuestro catálogo.

DS2.3 Gestión del Riesgo de proveedores. Identificar y mitigar los riesgos relativos a la capacidad del proveedor para continuar prestando los servicios de una forma segura y eficiente.

DS2.4 Monitorización del rendimiento de proveedores. Establecer un proceso que monitorice la provisión del servicio para asegurar que el proveedor está cumpliendo con los requisitos de negocio actuales y continúa cumpliendo los acuerdos contratados y los SLAs establecidos, así como para asegurar que el proveedor sigue siendo competitivo en el mercado

Por último, el modelo de madurez va (como siempre en CobiT) desde el 0-Inexistente hasta el 5-Optimizado, donde y a modo de ejemplo vemos que el nivel 1-Inicial indica

La dirección es consciente de la necesidad de establecer políticas y procedimientos de contratación. La medición de los servicios es informal y reactiva. Las prácticas dependen de la experiencia de los individuos o del tercero

y el nivel 4-Gestionado indica

Existen criterios formales y estandarizados para la relación con terceros, incluyendo planificación, costes, facturación, responsabilidades. Las cualificaciones y riesgos de los proveedores se analizan periódicamente. Los requerimientos de servicio están alineados con los del negocio y existe un proceso que permite analizar el rendimiento del proveedor. Se tienen en cuenta los costes de transferencia y se han acordado KPIs y KGIs

Asi, vemos claramente que CobiT nos ayuda, no sólo a ser conscientes de que es importante mantener una capa de control que nos permita asegurar que cuando se cede un trozo de los servicios TIC a un tercero, éste se va a comportar como hemos acordado, sino que tambien nos ayuda a establecer estos controles.

Por último, recordar que CobiT es un marco de mínimos donde vemos los controles mínimos que debemos establecer.

Mapping ITIL V3 with Cobit 4.1

ISACA ha publicado el documento de mapeo entre ITIL V3 y Cobit 4.1; es el resultado de un trabajo que era bastante complicado de hacer, ya que como en los demás documentos de mapeo, se intenta realizar un análisis de cómo se referencia cada uno de los objetivos de control detallados de Cobit en ITIL V3 y para poder hacer esto el equipo de trabajo debe tener grandes conocimientos de ambos extremos de la comparación.

En este estudio ha habido varias cosas que me han llamado la atención: lo primero es la evolución que ha habido en la metodología de realización de estos estudios: si miramos el documento de mapeo de ITIL V2 con Cobit 4.0 (fechado en Enero de 2007) veremos que el nivel de detalle al que se ha llegado en este nuevo análisis es mucho mayor y que ya no es tan absoluto como antes (en el de V2 se analizaba si un objetivo de control se cubre o no, booleano, blanco o negro); sin embargo, ahora hay una escala en la que se habla de cubrir "mucho, poco o nada" un objetivo de control.

Otro de los detalles que me ha parecido interesante es ver de forma gráfica la evolución de ITIL en cuanto al nivel de cobertura a las necesidades de un departamento IT. Si miramos los mapas de cobertura veremos que ITIL V2 cubría una pequeña parte de Cobit (sobre todo en la parte de Deliver and Support, como era de esperar) mientras que la cobertura de V3 es mucho más amplia

fuente: ISACA

Por último, me llamó la atención ese "agujero" que quedaba en DS... ¿qué pasaba con DS7, que no estaba cubierto?; así que me fui al manual de Cobit a buscar qué era el DS7 y me encontré con una gran sorpresa:

DS7 Educate and Train Users

Impresionante! Según este análisis, ITIL V3 no cubre en ningún aspecto la formación del usuario final. Y al menos por lo que yo he leído, es prácticamente cierto, salvo porque en alguna parte del Service Transition se habla de formar a los usuarios y en V2, en alguna parte de la Gestión de Versiones también se habla de la formación de usuarios. Pero desde luego no es algo a lo que se le preste una atención especial sino que se menciona "de pasada".

¡¡Qué gran carencia!! Visión de servicio? Tratar al usuario como a un cliente? Hacemos de todo para asegurar unos servicios de calidad y no nos acordamos de formar a los usuarios en el uso de los servicios?

Aquí me viene a la cabeza la definición de Mark Toomey sobre el Gobierno de TI y la nueva norma ISO 38500:

Las TIC son una herramienta del negocio. Es responsabilidad del Negocio determinar cómo, cuándo, dónde y porqué utilizará la herramienta y es responsabilidad de IT proporcionar la herramienta que satisfaga estas necesidades.

Pero no sólo estamos hablando de entregar una herramienta que satisfaga las necesidades, sino que también hemos de garantizar que quien ha de usar la herramienta sabrá sacar el máximo partido de ella; y no ya sólo por una visión egoísta del tema, en cuanto a que a medida que los usuarios estén más y mejor formados, menos problemas tendremos en IT (en soporte funcional, técnico o en peticiones, por ejemplo) sino que cuanto más y mejor estén formados los usuarios más partido podrán sacar de las herramientas que les proporcionemos y podrán aportar mayores eficiencias gracias al uso adecuado de las TIC.

Formar a los usuarios es una gran inversión, pero ITIL V3 se olvidó de ello.

Acto de presentación del 191 de Novática

Ayer, día 14 de Mayo del 2008, se hizo un pequeño acto en el Ateneo Barcelonés para la presentación del número 191 de Novática,  dedicado al Gobierno de las TIC.

Fue un acto muy agradable, con cuatro presentaciones y unas 50 personas en una sala de la dimensión adecuada para que no diera sensación de agobio ni de vacío.

Las presentaciones fueron, por orden de aparición:

• Didac López: Presentación de la revista y del trabajo realizado
• Antonio Valle: El estado del arte en el Gobierno de las TIC
• Aleix Palau: El estado del Gobierno de las TIC en España
• Tomás Roy: El punto de vista de un usuario en una gran entidad (Generalitat de Catalunya)

No me cansaré de decirlo: el 191 de Novática hará historia. Historia por la calidad de los contenidos, por la difusión que se ha hecho y se hará de la revista y por una aproximación menos (mucho menos!) techie a la profesión desde ATI y desde Novática.

Hoy me llegaba un mail de un amigo... sus palabras literales:

Yo fui para que me dieran la revista, ahora tengo en mi poder una mítica Novática 191 :)

La versión en inglés de este número de Novática se puede descargar ya aquí, y la versión en castellano se podrá descargar en breve aquí.

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 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.

Consultorio GobTIC: Auditando la implantación de Sistemas ERP

Una vez más, un lector del blog plantea sus dudas, ya sea vía correo electrónico o ya sea escribiendo comentarios a alguna de las entradas. En esta ocasión, Ricardo Javier preguntaba:

Muy bueno tu blog, soy un lector asiduo y he recibido varias recomendaciones y me ha sido muy util al ir a los sitios que recomiendas para consultar mas a fondo los estandares ITIL y COBIT principalmente, pero ahora la pregunta que te hago es si en algún lugar habrá una guia para auditar la implantación de Sistemas ERP, sé que ISACA ha realizado algunos mapeos de COBIT con PMBOK,CMMI,ITIL, ISO17799 y que cubren algunos aspectos a considerar.
¿Alguna sugerencia?

La respuesta no es del todo simple, ya que el terreno de la implantación de ERP no es precisamente mi fuerte, pero quisiera recomendar desde aquí dos importantes fuentes de información.

Por una parte, tenemos ISACA, que publica habitualmente manuales específicos para la auditoría de entornos comunes y que ha publicado dos documentos relacionados:

• Security, Audit and Control Features Oracle® E-Business Suite, 2nd Edition un paquete de cuestionarios para la auditoria de este ERP (descarga sólo para miembros de ISACA). Tal y como dice en la introducción, literalmente:

The purpose of these audit plans and internal control questionnaires (ICQs) is to provide the audit, control and security professional with a methodology for evaluating the subject matter of the ISACA publication Security, Audit and Control Features Oracle® E-Business Suite: A Technical and Risk Management Guide, 2nd Edition.

• El libro Security, Audit and Control Features SAP R/3: A Technical and Risk Management Reference Guide, Second Edition, libro enfocado a la auditoría y control de las implantaciones de este ERP.

This practical, how-to technical and risk management reference guide enables assurance, security and risk professionals (both IT and non-IT) to evaluate risks and controls in existing ERP implementations and facilitates the design and building of better practice controls into system upgrades and enhancements. The publication is based on SAP R/3 versions 4.6c and 4.7 and is the second edition of the globally demanded 2002 initial edition.

• Por último, la lista completa de publicaciones de ISACA relativas a entornos específicos la puedes encontrar aquí.

Por otra parte, una fuente muy interesante de checklists y controles la página del IT Compliance Institut, que desarrolla una gran cantidad de documentación y que dispone de la sección "Auditor Answers", donde puedes encontrar el artículo Auditor Answers: Enterprise Resource Planning Audits.

La clave de la alineación

En estas últimas semanas me ha tocado hablar con varios clientes/compañeros sobre el asunto de la tan famosa y deseada alineación de las TIC y el Negocio. A pesar de que ahora la moda es decir que "no hay que alinearse, sino que hay que integrarse; que el 'negocio' somos todos", es cierto que alinear los objetivos de cada uno de los departamentos de una organización con los objetivos globales que se persiguen como organización es algo realmente necesario.

COBIT, como marco de trabajo orientado especialmente al gobierno de las TIC, nos ofrece un modelo especialmente interesante para lograr esta alineación. El mecanismo es bonito en su simplicidad:

1.-Objetivos de Negocio

Para comenzar, se obtiene una lista de los objetivos de negocio, extraidos probablemente de su Plan Estratégico (ver entrada La Madurez como prerrequisito para IT Governance ). El modelo que plantea COBIT clasifica, además, esta información según los cuadrantes establecidos para un Balanced ScoreCard ( Kaplan y Norton ).

2.- Objetivos de IT

A continuación, se definen los objetivos de IT y se relacionan con cada uno de los objetivos de negocio. Aquí estamos viendo claramente cómo contribuiremos desde IT a cumplir los objetivos de Negocio y podemos cuestionarnos claramete cualquier objetivo IT que no esté relacionado con un objetivo de negocio: si no aporta al cumplimiento del objetivo global y común, ¿para qué está?

3.- Procesos de IT

El siguiente nivel es saber qué procesos IT deben intervenir en la consecución de estos objetivos departamentales. Así podremos obtener un mapa que refleje cuáles son los principales procesos que contribuyen a cada uno de los objetivos de IT (y por consiguiente a los objetivos de Negocio).

4.- Métricas

Por último, el modelo de métricas de CobiT está pensado para definir un conjunto de indicadores que nos permitan saber cómo de bien se están cumpliendo los objetivos de las actividades que hay dentro de los procesos, cómo están contribuyendo estas actividades al cumplimiento de los objetivos del proceso y cómo están contribuyendo los procesos al cumplimiento de los objetivos de IT.

Lo que siempre me ha llamado la atención de este modelo es que, siendo la gran clave de la alineación planteada por COBIT, todo esto está "escondido" en los anexos del manual del framework, así que escapa habitualmente de la lectura diagonal que gran cantidad de usuarios de COBIT realiza.

Por último, recordar que COBIT es un framework, un marco de trabajo, algo que es una simple guía que debe ser adaptada a las necesidades concretas de cada organización. Es decir, en la lista de objetivos de negocio que se propone no están los objetivos de negocio de tu compañía, sino los que se inventó un estudioso señor de Gartner que vive al otro lado del Atlántico, en la lista de objetivos de IT no están tus objetivos de IT y en la lista de métricas no están todas las métricas que tú puedas necesitar.

BIBLIOGRAFIA:

CONTROL Journal (I)

CONTROL Journal (II)

La importancia del PO2

Hoy estaba leyendo un artículo de Charlie Betz donde se citaba una frase que él mismo escribió y que siempre me ha gustado:

"You can't secure "Customer" data unless you understand that column CSTR_8XY_R7T_N in table GST_N_DT_TB in database GDB0234 actually contains their Social Security Number.

Y me acordé de una vez que tuve que hacer un assessment de controles de COBIT y ... ¡plaf! las dos cosas se juntaron.

Lo dejo aqui sólo como reflexión. El objetivo de control PO2 Define the Information Arquitecture es extremadamente difícil de conseguir, dificil de ver en el mundo real y, sin embargo, importantísimo para poder gobernar las TIC en una entidad ligeramente grande.

Como dice el mismo Charlie aqui,

Las TIC han sido tradicionalmente flojillas en la gestión de sus propios datos. Esta debilidad es inexcusable, y es tan inaceptable que IT sea ignorante al respecto de su propia información como que Recursos Humanos no conozca los detalles de los trabajadores o que Contabilidad desconozca el plan contable.

Publicado COBIT 4.1

Hoy me ha llegado el mail de notificación desde ISACA comentando que se ha puesto a disposición de los miembros de ISACA y de forma anticipada la descarga oficial de COBIT 4.1, incluyendo todo un paquete de documentación adicional.

The new and updated publications are as follows; (D) indicates downloadable:

• COBIT 4.1 (D)
• IT Governance Implementation Guide: Using COBIT and VAL IT, 2nd Edition (D)
• COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition
• IT Assurance Guide: Using COBIT (D)
• COBIT Security Baseline, 2nd Edition (D)

In addition to the above publications, members will also benefit by being able to download:

• IT Governance Implementation Guide toolkit files (D)
• IT Assurance Guide detailed content as an electronic file (D)

Yo ya me lo he descargado todo. Habrá que ponerse a estudiar ya mismo!!

Cobit 4.0 en Castellano

Recientemente la ISACA ha publicado la traducción oficial del Cobit 4.0 al castellano. Le he estado echando un ojo por encima, y realmente se ha hecho un trabajo considerable, bastante mejor que las traducciones (por ejemplo) de los manuales CISA. Aún así, estéticamente creo que les ha faltado un poco de esfuerzo, ya que hay errores de maquetación que enturbian el resultado final.

Personalmente, prefiero trabajar con la fuente en inglés, ya que es la original y me permite "olfatear" un poco mejor lo que podía tener en mente la persona/equipo que escribió el trocito que esté utilizando en cada momento, pero estoy seguro que de cara a la difusión y enseñanza de este magnífico marco de trabajo esto va a ser una muy buena noticia.

Aún así, hay que permanecer atentos: en menos de 3 semanas tendremos aquí Cobit 4.1 e ITIL 3.0... este va a ser un verano movidito!

Mas respuestas a preguntas

Otro lector del blog, esta vez identificado como Jrolivas72, plantea otra consulta:

Felicidades por tu blog Antonio, te mando un cordial saludo desde México (Baja California). Viendo tu experiencia te quería preguntar algo; actualmente estoy preparando el programa de auditoría para el area de TI, espero iniciarla en 30 días. Mis colegas de TI no tienen algún modelo implementado y con esta auditoría se pretende encaminarlos en el Gobierno de TI. Crees que sea conveniente auditar con COBIT 3 (Audit Guidelines 3)?. Veo que COBIT 4 ahora trae un tercio menos de objetivos! y es mas conciso... Saludos y te agradezco cualquier comentario.

¡Caramba! Esta no está mal... con tan poca información será difícil contestar y acertar, pero vamos a ver qué podemos hilvanar como respuesta.

El principal problema con el que nos encontramos en esta pregunta es que no sabemos para qué se está preparando el programa de auditoría, cuáles son los objetivos de este plan de auditoría. Yo no soy partidario de "auditar porque sí", sino que soy más partidario de auditar y recomendar.

Es decir, si el programa de auditoría está pensado con el fin de detectar anomalías o incumplimientos de un conjunto de políticas determinado (es decir, se plantea la necesidad de Gobierno de TI, se definen los procesos, controles, políticas, etc y se define un plan de auditoría que deba comprobar el cumplimiento, entonces se puede utilizar CobiT para definir este plan siempre y cuando se haya utilizado CobiT para la definición de las políticas, controles, etc.)

Ahora bien, si el programa de auditoría está pensado para establecer "cuán lejos estamos de los objetivos planteados por CobiT", entonces no estamos ante un plan de auditorías sino ante un plan de assessments o de evaluación de la madurez.

Una vez reflexionado sobre este punto, vamos a ver qué es más conveniente, la V.3 o la V.4: es una lástima que vayas a empezar en 30 días, porque, tal y como veiamos en el artículo sobre CobiT 4.1, la ISACA está a punto de publicar el equivalente a las guías de auditoría y las guías de implantación para cada uno de los controles en CobiT 4. Pero si no te puedes esperar, comienza el desarrollo con las guías de auditoría de COBIT 3 y posteriormente "haz madurar tu plan hacia Cobit 4"

De todas formas, lo último que te puedo recomendar es tragarte las guías de auditoría de CobiT 3 sin modificación, adaptación y "moldeado" a las políticas, prácticas y experiencias en tu propia organización. Es de recibo adaptar Cobit a las necesidades de tu compañia y adoptar únicamente las partes necesarias, pues si no estarás introduciendo una presión excesiva e innecesaria a tu área de IT.

Respuestas a preguntas concretas

 Hace unos días, un visitante del blog que firma como Sandro dejó esta pregunta en uno de los posts:

Hola! Me dispongo a implementar Cobit en una empresa de Autoría de DVD, quisiera preguntarte de qué forma podría encontrar referencia de otras empresas que hayan implementado Cobit que tengan mas o menos este perfil (Producción de DVDs, video, películas)

Quería contestar "in-line" en los comentarios, pero es difícil que Sandro vaya a mantenerse al día esperando contínuamente a que le responda allí, y por eso he preferido contestar con un post "dedicado".

La verdad es que "implantaciones" de CobiT completas no tengo el gusto de conocer (¿alguien que quiera servir de referencia y me la muestra?).

La idea con CobiT es más utilizarlo como herramienta de trabajo, moldeando las partes que te interesan y desechando aquellas que no te interesan, de tal forma que al final acabas montando tu propio esquema de control, pero usando CobiT como guía o referencia.

Por ejemplo, simplemente hazte unas pocas preguntas: ¿Realmente te dispones a implementar todos los procesos de CobiT de una tacada? ¿A qué nivel de madurez pretendes llegar en cada uno de ellos? ¿Sin modificar nada?

Ahora bien, si quieres casos de estudio sobre compañias que han utilizado CobiT para implantar planes de auditoría, directrices de Gobierno de las TIC, reducción o cotrol de riesgos, etc... entonces puedes visitar la web de la ISACA donde publican periódicamente casos de estudio.

Por último, comentar que respuestas de este estilo te las vas a encontrar continuamente, porque CobiT no es como una ISO que haya que implantarla "tal y como dictan las normas", ni como ITIL que, al fin y al cabo, es una colección de recomendaciones. La respuesta habitual es "es que CobiT es un framework y por lo tanto es sólo una guía".

Para mi, CobiT es una navaja suiza: muchísimos gadgets a utilizar por diferentes roles o perfiles de gente para hacer diferentes cosas.

¡Espero haberte ayudado!

PS:: Espero que nos cuentes a todos (como comentarios en este blog o como artículos en el tuyo propio) cómo te va en tu aventura cobitera!

COBIT 4.1 en el horno

De entre todas las noticias que trae el segundo número de la revista COBIT Focus, publicado en Diciembre del 2006 por la ISACA y el ITGI , hay uno que es especialmente llamativo, no porque el contenido sea clarificador sino porque es una noticia importante: el ITGI planea presentar la versión 4.1 de COBIT a finales del primer trimestre del 2007, osea de aquí a un par de meses.

La nueva revisión comprende las siguientes mejoras:

1. Un paquete de correcciones al texto original de la versión 4, corrigiendo algunos errores e incoherencias reportadas por los usuarios.
2. A nivel de Objetivos de Control detallado, se ha modificado su definición, alineandola más hacia la vertiente de prácticas de gestión.
3. Mejoras en el conjunto de Objetivos de Control Detallados, agrupando, redefiniendo, eliminando y creando otros. Por ejemplo, los objetivos AI5.4, AI5.5 y AI5.6 se han agrupado en uno único.
4. Modificaciones substanciales al Objetivo de Control ME3 (Ensure Regulatory Compliance), añadiendo nuevos OC Detallados para recomendar no sólo el cumplimiento de leyes y regulaciones externas a la organización sino también las políticas internas y requerimientos contractuales
5. Ampliación en la lista de Objetivos de Negocio y Objetivos TI, gracias a un estudio proporcionado por la UAMS.
6. Revisión del resumen ejecutivo con una mejor explicación del proceso de medición, la aportación del mismo, el concepto de "cascada" de métricas y objetivos de actividad e información ampliada sobre los conceptos de Val IT.

AI5.4 Software Acquisition
Ensure that the organisation’s interests are protected in all acquisition contractual agreements. Include and enforce the rights and obligations of all parties in the contractual terms for the acquisition of software involved in the supply and ongoing use of software. These rights and obligations may include ownership and licensing of intellectual property, maintenance, warranties, arbitration procedures, upgrade terms, and fitness for purpose including security, escrow and access rights.

AI5.5 Acquisition of Development Resources
Ensure that the organisation’s interests are protected in all acquisition contractual agreements. Include and enforce the rights and obligations of all parties in the contractual terms for the acquisition of development resources. These rights and obligations may include ownership and licensing of intellectual property, fitness for purpose including development methodologies, languages, testing, quality management processes including required performance criteria, performance review, basis for payment, warranties, arbitration procedures, human resource management and compliance with the organisation’s policies.

AI5.6 Acquisition of Infrastructure, Facilities and Related Services
Include and enforce the rights and obligations of all parties in the contractual terms, including acceptance criteria, for the acquisition of infrastructure, facilities and related services. These rights and obligations may include service levels, maintenance procedures, access controls, security, performance review, basis for payment and arbitration procedures.

Otra parte importante de la noticia es que se hará coincidir esta nueva publicación con la publicación de algunos títulos complementarios en el mundo COBIT que se estaban echando de menos:

• COBIT® Control Practices: Guidance to Achieve Control
  Objectives for Successful IT Governance, 2nd Edition
• IT Governance Implementation Guide: Using COBIT® and Val
  IT™, 2nd Edition.
• COBIT® Security Baseline 2nd Edition
• COBIT® Quickstart, 2nd Edition
• IT Assurance Guide: Using COBIT®.

Esta última publicación promete ser interesante y necesaria, ya que está orientada a remplazar el libro COBIT® Audit Guidelines, que no se ha revisado desde COBIT 3 y que necesita un repaso desde hace tiempo.

Habrá que permanecer atentos, porque además de este atractivo paquete de nuevas nuevas, se está cocinando en el horno de la ISACA un variado surtido de títulos dentro de la serie de herramientas de mapeo de COBIT con otros estándares:

• COBIT® Mapping: Mapping PRINCE2 With COBIT® 4.0
• COBIT® Mapping: Mapping ITIL With COBIT® 4.0
• COBIT® Mapping: Mapping ISO/IEC 17799:2005 With COBIT® 4.0
• COBIT® Mapping: Mapping TOGAF With COBIT® 4.0

que sumados a los que se presentaron ya en el 2006,

• COBIT® Mapping: Mapping SEI’s CMM for Software With COBIT® 4.0
• COBIT® Mapping: Mapping PMBOK® With COBIT® 4.0

le dan a COBIT una presencia más que considerable en el mundo de los estándares.

¿Te Gusta Leer?

La importancia de las palabras

Durante las próximas semanas voy a hacer una especie de maratón formativa que me va a dejar seco: voy a impartir la friolera de 5 cursos de temas diferentes a personas diferentes y uno de estos cursos tiene como título "Inmersión en Estándares de Gestión TIC", en el que se da una visión de ave rapaz sobre ITIL, COBIT, ISO20.000, CMMI-DEV, CMMI-SVC, ISO27001, SIX SIGMA y, lo más interesante, cómo integrar, mezclar, combinar y aprovechar todo esto para "tunear" las prácticas de ITSM que tengas montada o quieras montar.

Evidentemente, esto es a vista de ave rapaz, y no se puede entrar en mucho detalle, principalmente por dos razones: la primera y más importante, el tiempo. ¿Te imaginas la magnitud que tendría una formación detallada en todas estas áreas?. La segunda razón es el tamaño de nuestras cabezas: tanto conocimiento no cabe "de golpe y sin procesar" en la cabeza de nadie, empezando por la mía.

Pero claro, para poder preparar el curso he tenido que refrescar muchos conocimientos que tenía por ahí guardados y ampliar unos cuantos que no tenía (por ejemplo, CMMI-SVC, que aún no se ha publicado) y a base de pasarme horas estudiando y pensando en qué quería explicar y cómo lo quería hacer, he acabado pensando en que, a priori, parece que las tres grandes encajan bien entre ellas.

ITIL, COBIT e ISO27001 ya se han hecho cuadrar, tanto en el artículo "Combinando Estándares" de este blog como en las publicaciones del itSMF e ISACA que en él se referencian. Pero hay dos nuevos players en la arena: CMMI-SVC e ISO 20.000

El título de este artículo viene precisamente del gran peligro que puede suponer la lectura en diagonal de tanto estándard sin pararnos a mirar aquella parte de los manuales que todos nos saltamos cuando ya sabemos un poco: el glosario

Si nos dicen que CMMI-SVC está orientado a proporcionar una guía hacia el modelo de madurez en la provisión de servicios y que entre otras, las áreas de proceso que incluirá son la gestión de la capacidad o la gestión de problemas, pensaremos de forma inmediata que ya tenemos (al fin!) un modelo de madurez serio para ITIL, ¿no?

Hasta aquí, es lo más normal del mundo. El problema viene cuando de repente piensas "pero... ¿se están refiriendo a lo mismo? ¿TODOS se refieren a lo mismo?"

La clave de todo es el servicio: ITSM, ITIL, ISO20.000 y CMMI-SVC están orientadas todas a servicios IT, por lo que si no nos miramos el glosario, están todas orientadas a la idea que tenga el lector de lo que es un servicio IT. Esta forma de verlo era válida hasta hace poco, en que no había certificación; pero a la que aparece un "sello" que te certifica en ISO20.000 o en CMMI nivel 3, es obligatorio que el concepto certificado sea exactamente el mismo, o las certificaciones no tendrían valor.

Así que me fui directo al glosario:

Service Support: ARG! No tiene definición de servicios en el glosario!

Service Delivery: One or more IT systems which enable a business process.

Planning to Implement: One or more IT systems that enable a business process.

COBIT 4: ARG! Tampoco tiene definición

A estas alturas ya estaba preocupado. De todas formas, por ahora no había entrado en los "cuerpos certificadores", así que las interpretaciones podían ser todo lo libres que uno quisiera (se acuerdan de aquello del "Estilo Campechano"? ).

El siguiente paso fue buscar en las áreas de certificación:

BS15000: ARG! No define el término service ni IT Service

ISO 20.000:1 o 20.000:2 ARG!!!! Tampoco define los términos.

Versión Española de la ISO 20.000 ¡¡Tampoco!!

CMMI-SVC: En las FAQS aparece algo...

The CMMI for Services team defines a service as a product whose primary value is delivered to a customer or end user in a form that is intangible, non-storable, and dependent on the direct application of labor.

Yo diría que la aproximación a servicio que está dando CMMI se parece bien poco a la que está dando ITIL en el glosario, ¿No?

Es más, el típico servicio (ITIL) que todo el mundo usa siempre en cada uno de los discursos es el correo electrónico, y eso, si bien podríamos decir que es intangible y quizás no almacenable (ja!) lo que seguro que no es es dependiente de la aplicación directa del trabajo, ¿No?

Es decir, mientras que ITIL habla de un servicio como una agrupación de hardware, software, comunicaciones, etc.., CMMI habla de servicio como lo que normalmente entendemos como "Servicios Profesionales": mantenimiento de equipos, gestión de la red, formación, etc.

¿Serán mapeables estos dos estándares?

Seguramente los harán mapear, porque hay el esfuerzo de mucha gente en juego. Pero gestionar, medir, evaluar y administrar un servicio tecnológico no tiene nada que ver con hacerlo con un servicio profesional.

¿Y las ISO ?

Esa es mi gran duda. Me parece haber leido en algún sitio que las ISO20000 están orientadas a Servicios TI y eso significa (al menos bajo mi punto de vista) un servicio al estilo ITIL.

Ahora bien... hago dos promesas formales:

1. Leeré los glosarios de todo standard nuevo que caiga en mis manos.
2. Prometo tener más cuidado a la hora de definir los servicios en un Catálogo de Servicios. 

Con respecto a este último punto, prometo escribir algún día un post: los servicios al estilo CMMI, los servicios profesionales, deben ir en la Carta de Servicios (documento para el cliente).   

Reflexiones desde el cielo

Hoy escribo este post a 10.000m de altura y a 1.000Km/h, el post más rápido que he escrito nunca!!

Me encanta volar. Odio las esperas en los aeropuertos y más aún las ocasionadas por retrasos inexplicados como el de hoy, pero cuando el avión comienza la aceleración en la pista y me siento aplastado contra el asiento se me pasa todo y ya, cuando despega y puedo ver por la ventanilla el espectáculo desde el aire, entonces es cuando me quedo colgado mirando y mirando.

El despegue de hoy ha sido especialmente bonito; el aeropuerto de El Prat estaba cubierto de niebla y el piloto se ha dado prisa en subir, poniéndonos con una inclinación que yo creo que era de más de 30º... de repente hemos atravesado la capa de nubes y allí estaba la luna iluminando desde arriba el mar de nubes. Especialmente bonito.

Me gusta ver el paisaje desde arriba y cuando el vuelo es nocturno, más aún ver las formas caprichosas que dibujan los alumbrados de las calles, los focos de las fábricas y hoy, además, he tenido la oportunidad de ver los haces de luz de una discoteca desde arriba!

Desde la distancia las cosas se ven diferentes. Los pueblos se parecen entre ellos y todo se funde, se mezcla, se homogeneiza (se dirá así?).

Mariano me tiró un lance, a ver si lo pillaba. Hace mucho tiempo me preguntó si podríamos usar ITIL para otras cosas que no fueran las TIC, y no le contesté. Como él dice, la respuesta, o era trivial, o era complicadísima... se me hacía pesado contestarle por lo largo y meditado de la contestación porque, claro, ITIL son buenas prácticas para gestionar servicios TIC y no para gestionar cualquier cosa. Sin embargo, siempre que haya un servicio podremos generalizar ITIL para construir unas buenas prácticas de gestión... al menos los nombres de procesos, estructura, relaciones.

Luego, meses más tarde, escribí un artículo sobre COBIT y Mariano volvió al ataque, esta vez más ilusionado aún porque veía que realmente podría extrapolar la idea hacia su mundo particular del sistema educativo. ¿Por qué le llamó más la atención COBIT que ITIL? ¿Por qué no dudó lo más mínimo en reinventar el concepto de Gobierno de las TIC y el Gobierno Educativo?

Porque a vista de pájaro las cosas son diferentes. COBIT es un modelo mucho más abstracto que ITIL y también mucho más generalista... y la definición de Gobierno Corporativo ya es el extremo de la generalidad, y es por eso por lo que ha podido aprovecharlo para su modelo propio de Gobierno Educativo.

Para poder extrapolar ahora el resto de COBIT e ITIL hacia un modelo que sirva de marco de referencia para la gestión de otras cosas (un sistema educativo, un centro o una cadena de restaurantes) yo creo que hay que quedarse con los títulos más importantes, usar ITIL y COBIT como el índice de tu marco de trabajo definiendo:

• Definición de objetivos de negocio.
• Los procesos que se deben dar para conseguir la gestión adecuada del tipo de servicios que se proporcionan incluyendo (para no caer en los mismo errores de antaño) todos los procesos que cubren el ciclo de vida completo del servicio: desde la gestión de la demanda, el alineamiento con los objetivos estratégicos de la organización, la construcción, la producción y el mantenimiento de la vida productiva del servicio.
• Mapeo de los objetivos de negocio sobre la lista de procesos
• Los indicadores, que deben servir para medir el grado de cumplimiento de los procesos, el volumen y rendimiento en la actividad de los procesos y el nivel de madurez de la implantación de cada uno de los procesos anteriormente detallados.
• Los roles, responsabilidades y habilidades necesarias para cada una de las actividades o funciones dentro de los procesos.
• Las relaciones entre los procesos.

No se, así a priori y desde un avión es lo que se me ocurre a voz de pronto para definir el marco de trabajo.

Luego vienen las guías de implantación, o sea las prácticas recomendadas por el sector como apropiadas para la ejecución de cada uno de estos procesos y para el orden de implantación; y cuando esto se haya convertido en algo extendido y aplicado entonces viene el trabajo de definir el benchmarking: ¿cuales son los valores habituales considerados como correctos para los indicadores definidos anteriormente? y los formatos de representación: ¿cuál es la forma más común de representar estos indicadores de forma que sean útiles al máximo número de personas en la organización?

¿Con esto estamos aplicando ITIL o COBIT para la gestión de otro tipo de servicios? No exactamente... estamos replicando la forma de crear un marco de trabajo para definir el marco adecuado para el tipo de servicios que queremos gestionar/controlar.

¿Te sirve como respuesta, Mariano, o una vez más he volado demasiado alto?

Technorati tags: ITIL, Cobit, sistema educativo, centros educativos

El huevo, la gallina y el cliente que sabía demasiado

Tengo un cliente que sabe más que yo... en realidad sabe mucho más que yo y trabajar con él siempre me hace llegar a extremos insospechados. A este chico le bastan un par de frases para poner mi cabeza a trabajar hasta que echa humo, no se si le pasará a todos los que trabajan con él o simplemente es una característica de nuestra relación profesional.

Pues bueno, uno de estos extremos insospechados apareció hace un par de días cuando estábamos hablando sobre COBIT y la implantación que está llevando a cabo él en su organización. Me comentó que tuvo una charla con uno de sus compañeros, que le decía que COBIT era demasiado amplio y demasiado teórico como para conseguir implementarlo. De hecho la frase fue algo así como

-- "si no hemos conseguido estabilizar la puesta en marcha de los procesos principales de ITIL, ¿cómo vamos a pensar ahora en utilizar COBIT?"

a lo que este hombre le contestó:

-- "Si no te ha funcionado la implantación de ITIL es precisamente porque no tenías COBIT"

¡Toma bomba de relojería para mi cabeza! Me ha estado rondando un par de días, y sigue ahí metido el come-come.

Vamos a ver, esto se parece mucho a lo que comentaba en el artículo sobre madurez y gobernabilidad sobre el enfoque de "abajo a arriba" o de "arriba a abajo". Cuando haces el enfoque de abajo a arriba, resulta que te encuentras diseñando procesos con el objetivo de mejorar la forma en la que sirves los servicios TIC a la organización y después decides añadir el concepto de control para asegurar que los procesos se cumplen (osea, que la gente hace lo que has dicho en el papel que van a hacer) y para reducir el riesgo que te genera el tener los procesos descontrolados.

Pero... ¿es bueno diseñar los procesos sin control?

Según el propio modelo de proceso que muestran los libros de ITIL, una buena definición de proceso debe tener asociada su definición de proceso de control, y su reparto de roles, responsabilidades y recursos necesarios para la ejecución, así que a nada que empieces a funcionar, si no tienes proceso de control estarás navegando "a ciegas". Entonces, cuando diseñas el proceso has de tener en cuenta los objetivos del proceso y los controles que debes aplicar para asegurar su funcionamiento.

Pero ITIL no habla de controles, ni de indicadores de rendimiento (apenas) y cuando tienes que pensar en indicadores que te ayuden a saber si el proceso está logrando sus objetivos, la cosa se pone dura: o te los inventas (reinventando la rueda una y otra vez) o usas un modelo que te sirva para diseñar los que necesitas, y ese modelo se llama COBIT.

¿Y si quiero pensar en el diseño "de arriba a abajo"?

Entonces la cosa es más curiosa todavía... partimos de COBIT, y sus Objetivos de Control y nos encontramos con que tenemos (por ejemplo) un objetivo de control que dice "AI6 - Gestionar Cambios".

Como el objetivo de control no es el control en sí mismo, nos encontramos con que tenemos que pensar en qué controles definir para cumplir el objetivo de control Gestionar Cambios, y llegas univocamente a la necesidad de definir un proceso de Gestión de Cambios que cumpla, al menos, los objetivos de control detallados que propone COBIT.

Pero ¿puedo tener algo parecido a Gestión de Cambios sin tener proceso definido y en marcha?

¡¡Por Supuesto que Si!! Tendrás un Objetivo de Control XX en nivel de madurez 0.-Inexistente, pero lo tendrás.

Y aquí viene otra idea que me concome... ¿"Implementar COBIT"? ¿Acaso el COBIT se implementa? ... no se cómo explicarlo, porque es sólo un embrión de idea, pero es algo así como que COBIT ya está implementado en todas partes... solo que en muchos de los 34 procesos estás a nivel 0 de madurez. En todo caso el COBIT se usa, pero no estoy seguro de que se implemente.

Osea, lo que hay que plantear no es un plan de implementación de COBIT, sino un roadmap de maduración de los procesos críticos para tu organización: establecer la medición y el análisis de madurez necesario para saber dónde estás y cómo vas creciendo.

¿Y esos procesos críticos, son críticos para quien?

Buena pregunta. Busca los objetivos estratégicos de la compañia, hazlos corresponder con su mapeo en objetivos de la organización TIC, busca los procesos que hacen que esos objetivos TIC se cumplan y tendrás la lista de procesos críticos que has de madurar según los requerimientos del negocio... de esta forma harás madurar tus TIC alineadas con el negocio y el esfuerzo tendrá doble visibilidad.

En definitiva... ¿que es primero, el proceso que necesita un objetivo de control o el objetivo de control que te pide que tengas proceso?

Ya ves lo que hace tener clientes que saben tanto... te hacen pensar!!

¿Comentarios?

¿Opiniones?

¿Experiencias desde la trinchera?

Technorati tags: cobit, itil, gobernotic

del.icio.us tags: cobit, itil, gobiernotic

La madurez como prerrequisito para IT Governance

Este fin de semana vinieron a casa un par de parejas de amigos a tomar el aperitivo. Estuvimos hablando de todo un poco, como pasa siempre en estos casos, y uno de los temas que salió fue el caso de un mando intermedio en la empresa de uno de ellos que estaba perdiendo el correcto funcionamiento del departamento (de ventas) y que para ocultarlo estaba "apañando" las estadísticas de resultados.

En el mismo momento en que lo estaban contando y, a pesar de que el susodicho personaje estaba cometiendo otras faltas que humanamente me parecían peores (el mobbing es una práctica despreciable desde mi punto de vista), la idea de un mando intermedio manipulando las estadísticas me pareció interesantísima como ejemplo para comentar en clase.

Claro, el primer concepto que ejemplifica este comportamiento es el de la Segregación de Funciones: ¿A quién se le ocurre que las métricas que evalúan el correcto funcionamiento de una Unidad Organizativa las genere manualmente el propio responsable de la UO? Y si además al responsable de la UO le va parte del sueldo variable en ello, ¡peor aún!

Ahora bien, el meditar sobre esto fue también el disparador que me hizo querer esribir sobre el nivel de madurez que debe tener una Organización para poder trabajar bien el mundo COBIT. Hasta ahora, siempre he tocado COBIT como una herramienta de apoyo a la implantación de procesos desde el punto de vista de ITIL.. un simple "truco de magia" para dotar a ITIL de cosas que no tiene, pero la realidad es al revés (al menos explicitamente por parte de COBIT, la cosa es al revés): COBIT reconoce abiertamente estar muy centrado en el qué, y deja el cómo a otros estandares, metodologías o marcos de trabajo que estén centrados en el área operativa; por esta razón es por la que hay documentación de ISACA para mapear COBIT con ITIL, ISO27000, CMM o incluso PMBOK.

Pero ahora pensemos en los primeros pasos de COBIT: se habla de alinear IT con el Negocio mediante el aseguramiento de que la información cumple con los requerimientos de negocio (los 7 famosos requisitos de la información) y de cómo se produce una "cascada" de información desde los objetivos de negocio hasta las propias personas, tal y como se ve en la gráfica

Así, modelaremos los recursos IT y los procesos IT en función de los requerimientos de negocio, y esto es una alineación de las TIC con el negocio enfocada de arriba a abajo, y no de abajo a arriba que es como se suele explicar en el mundo ITIL.

Ah! y esto? en qué nos afecta?

Pues.... la respuesta a la pregunta te la darás tú mismo: ¿Cuáles son los objetivos de negocio de la Organización en la que trabajas? Si los conoces, entonces tienes el punto de partida y puedes hacer el trabajo de alineación.

Pero si no los conoces... si resulta que tu organización no transmite claramente los objetivos de negocio (o si simplemente no los tiene detallados, que no sería la primera) entonces cabe preguntarse: ¿Cuántos objetivos tiene la compañía? Casi que unos cuantos por directivo, unos cuantos por mando intermedio y unos cuantos por trabajador; es decir, cada uno se plantea sus propios objetivos, y así ¿Quién se alinea con quién?

(Aquí vuelve a aparecer nuestro mando intermedio de una de las áreas de ventas, que al margen de los objetivos que pueda tener la empresa con respecto a su departamento y a las funcionas que desempeña la gente que esté a su cargo, tiene unos objetivos personales claramente definidos y por los que está dispuesto incluso a falsear informes para no aparecer mal en la foto)

Por lo tanto, necesitamos que antes de pensar en aplicar COBIT como framework para el Gobierno de las TIC (una de sus varias utilidades, pero quizás la más importante y en la que estaban pensando cuando lo hicieron) los primeros pasos en Gobierno Corporativo (si no formalmente, al menos informalmente) se hayan dado, y la compañía tenga definidos claramente los objetivos de negocio a los que nos debemos alinear.

PD:Un par de definiciones:

Gobierno Empresarial

Es el conjunto de prácticas y responsabilidades ejercidas por la Dirección Ejecutiva con la meta de proporcionar dirección estratégica, asegurándose de que los objetivos son cumplidos, comprobando que los riesgos se gestionan adecuadamente y verificando que los recursos de la Organización se utilizan adecuadamente

de esta definición vemos que el Gobierno Empresarial es a la Organización lo que el Gobierno de las TIC es a la Organización TIC.

El Gobierno de las TIC es responsabilidad tanto de la dirección como de la administración ejecutiva. No es una disciplina aislada, sino que es parte integral del Gobierno Empresarial (o Corporativo) y consiste en el liderazgo, las estructuras organizativas y los procesos necesarios para asegurar que las TIC mantengan y amplíen los objetivos y estrategias de la empresa

Claro, y en definitiva, si pretendo que "las TIC mantengan y amplíen los objetivos y estrategias de la empresa", como la empresa no los tenga definidos no llegaremos a ningun buen resultado.

Combinando Estándares

Una de las técnicas más habituales en los días que corren es la combinación de diferentes estándares en la definición del Modelo de gestión de Servicios TIC de una organización. Normalmente, siempre decimos que ITIL no es suficiente y que es bueno combinarlo con otros modelos o estándares como puede ser COBIT.

Precisamente, la combinación ITIL+ COBIT + ISO17799 que ahora es tan y tan conocida (en parte gracias al documento publicado conjuntamente entre el itSMF e ISACA llamado Aligning COBIT, ITIL and ISO 17799 for Business Benefit ) en realidad comenzó allá por el año 2002 cuando Angeli Hoekstra y Nicolette Conradie publicaron un simple powerpoint (yo lo bajé del Chapter de Sudáfrica del itSMF) llamado Cobit, ITIL and ISO17799, how to use them in conjunction Este powerpoint sentó las bases del trabajo que posteriormente se desarrollaría en muchas de las implantaciones de procesos en todo el mundo, y curiosamente es uno de los archivos sobre estos temas más compartidos en las redes P2P.

En este tipo de trabajos, normalmente se tiende a presentar a ITIL como una fuente de definición de procesos y de tareas a realizar (nos dice “el qué”) y a COBIT como fuerte en la definición de métricas y controles (nos dice “qué medir”) así que el trabajo más normal es hacer una combinación de ambos estándares para conseguir los procesos detallados según ITIL y medidos y controlados según COBIT.

Hasta aquí nada raro. ¿Entonces?

Pues entonces viene cuando aparece el problema de la falta de documentación en castellano. Los libros oficiales de ITIL son pesados… no son precisamente un libro que uno se lleva a la cama para leer antes de dormir (más que nada porque te duermes antes de comenzar!) y además están escritos en un perfecto inglés de la Gran Bretaña, de ese que utiliza Whilst en lugar de While y te deja buscando en el diccionario la mitad de las veces (menos mal que se están cocinando los libros en castellano!) así que uno se lee lo que necesita. Los libros más trabajados, obviamente, son el Service Support y el Service Delivery.

Pero esta semana he centrado mi atención en el Planning to Implement Service Management. Resulta que ahí aparece el famoso cuadro que muestra las diferentes tareas en el ciclo de mejora continua de los procesos que vamos a implementar:

• Definición de objetivos de alto nivel, respondiendo a la pregunta “What is the vision”
• Definición del nivel de madurez actual (antes de empezar, para poder luego medir el progreso!) respondiendo a la pregunta “Where are we now?”
• Definición de a dónde queremos llegar, objetivos claros y mesurables; respondiendo a la pregunta “Where do we want to be?”
• Definición de los procesos y de las mejoras en los procesos; con la pregunta “How we do get where we want to be?”
• Definición de métricas y controles para responder a la pregunta “How do we check our milestones have been reached?”
• Y por último y para cerrar el ciclo, Definición de actividades de esponsorización para responder a la pregunta “How do we keep the momentum going?”

Y justamente en el capítulo 6, respondiendo a la pregunta “How do we check our milestones have been reached?” hay todo un fantástico apartado dedicado a la definición de CSF (Factores Críticos de Éxito) y de KPIs (Indicadores Clave de Rendimiento) que he dedicado un rato a estudiar y a comparar con los que propone COBIT para sus diferentes procesos incluidos en ITIL.

Por ejemplo, si miramos la Gestión de Cambios podemos ver que aparecen 4 CSF y 32 KPIs organizadamente agrupados para medir la consecución de cada uno de los 4 CSF. Sin embargo, si comprobamos la información presente en COBIT 3 nos encontramos con que hay la friolera de 12 CSF y 6KPIs y si miramos en COBIT 4, aquí vemos que el concepto CSF ha sido eliminado y ahora aparecen 4 Activity Goals, 6 KPIs (totalmente diferentes a los planteados por COBIT 3), 4 Process Goals, 6 Process KGI, 5 IT Goals y 1 IT KGI.

Personalmente, me parecen mucho más adecuados los CSF de COBIT3 que los de ITIL, aunque el modelo COBIT 4 es innovador y es el que más me gusta, pero… ¿Quién se quiere encorsetar es una única propuesta?

A la hora de definir tus procesos, tus indicadores, tus herramientas de control y tus objetivos, se creativo: no te bases únicamente en lo que han escrito otros, piensa e inventa aquello que tu organización necesite (porque al fin y al cabo, tú conoces mejor que nadie tu propio entorno). No reinventes la rueda, así que inspírate en todo lo que leas pero ten siempre abierta la mente a crear nuevas propuestas.

¿La magia recorre tu cuerpo?

En mis primeros cursos de ITIL recuerdo que siempre había un momento en el que notaba que a los alumnos les empezaban a encajar las cosas en su mente, comenzaban a ver la foto completa y en ese momento explicaba que cuando eso te pasa, sientes “la magia recorrer tu cuerpo”. Esto es una referencia a las Crónicas de la DragonLance en las que el mago Raistlin tenía más habilidades para ejercer la magia que la gran mayoría de los demás magos a pesar de su juventud.

En los momentos en que Raistlin tenía que utilizar la magia, cada hechizo le consumía las fuerzas de forma que a pesar de sus extraordinarias habilidades no podía realizar mucho más de dos conjuros seguidos. En una situación muy crítica, el mago tuvo que gastar todas sus energías para realizar un conjuro especialmente complicado, y las autoras describían el momento contando que “a pesar de lamentable estado, Raistlin sintió la magia recorrer su cuerpo subiendo desde los pies hasta llegar a concentrar las pocas fuerzas que le quedaban para susurrar las cuatro palabras que componían el conjuro”.

Esa es la sensación que me recorre cuando siento que mis alumnos comienzan a entender cómo los conceptos de la Gestión de Servicios son la agrupación total de los conocimientos que uno ha estado amasando durante años hasta ver que se fusionan todos en uno y surge la magia de ITIL. Han pasado años, al menos seis desde aquellos primeros seminarios y ahora la sensación ya no es tan intensa cuando los alumnos comienzan a ver la luz. Supongo que principalmente porque ahora los alumnos vienen mucho más preparados, y por lo tanto no les estás iluminando con tantísima intensidad como hace seis años (conceptos como Servicio, Proceso y Gestión ya han sido asimilados completamente por el mercado), pero también hay otro factor importante: yo se ahora más que hace seis años. Y ya no es ITIL “la punta de la pirámide”, sino que es “la punta del iceberg”: hay mucho más que hacer y veo claramente que ITIL se queda corto en muchísimos aspectos, por lo que es necesario complementar ese conjunto de buenas prácticas con otros estándares, marcos de trabajo o recomendaciones. Al fin y al cabo, ¿dónde dice en ITIL que es bueno disponer de un plan estratégico para la compañía o para el Departamento de TI? o bien, ¿cuáles son los pasos que se deben dar para exigir la devolución de un servicio a un proveedor de externalización?

Hay toda una serie de procesos que no están descritos en ITIL y que son profundamente necesarios para el buen gobierno de las TIC en una compañía, y es por eso por lo que más allá de las Best-Practices tenemos la necesidad (cada vez más imperiosa) de acudir a otras fuentes:

COBIT en sus Objetivos de Control de Alto Nivel, establece un conjunto de procesos mucho más amplio que los que establece ITIL “troceados” en cuatro dominios. La lástima de COBIT es que dice claramente el qué, pero no dice el cómo. Es decir, tenemos una buena guía de los procesos, actividades y controles que se deben establecer, pero no tenemos (a diferencia de ITIL) una guía de buenas prácticas a la hora de implementar y ejecutar los procesos.

Con la entrada en escena de COBIT 4, se ha dado un importantísimo paso adelante, ya que la nueva versión está mucho mejor estructurada y es mucho más clara que la anterior. Adicionalmente y previo a la publicación de COBIT 4 se realizó un trabajo conjunto entre ISACA , ITGI y la OGC para redactar una valiosa guía de referencia cruzada que plantea la combinación de ITIL, COBIT e ISO 17799.

Por otra parte, no tan conocido como el mundo COBIT, pero especialmente orientado a empresas proveedoras de servicios, podemos acudir a los modelos de la Carnegie Mellon: eSourcing Capability Model for Service Providers (eSCM-SP) o bien el eSourcing Capability Model for Clients (aún en desarrollo).

¿Qué aporta este modelo adicionalmente a los modelos que podemos encontrar en ITIL, CMM o COBIT?

Podemos encontrar toda una serie de comparativas entre los diferentes modelos aquí, hay que seguir leyendo (¡y mucho, que el eSCP es grande!) porque en realidad hace muy poco que lo conozco y tengo que estudiar mucho, pero una primera aproximación más visual que el “tocho” de libro la puedes encontrar aquí.