¿Alineación con el Negocio, Integración con el Negocio o Simplemente Negocio?

El amigo Jorge, de Sistemas Decisionales, me tira el guante en el post anterior y me propone escribir un post a partir de un título y propone este título en concreto, basado en el extracto del libro IT Service Management, strategies that workcomentado en el post anterior.

Durante mis años de profesión, cada vez más me he dado cuenta de que el trabajo de consultoría (o quizás de asesoría como prefiero yo llamarlo) ha hecho de nosotros en realidad unos agregadores/transmisores de conocimiento: cuando te preguntan ¿cuántos años de experiencia tienes en esto? en realidad te están preguntando ¿en cuántos clientes / proyectos / sectores has trabajado?.

¿Por qué eres más valioso cuanta más experiencia? Porque en realidad en este trabajo la relación con cada uno de los clientes es simbiótica: ellos piensan que aprenden de ti, pero en realidad eres tú el que estás aprendiendo de ellos una barbaridad y luego acumulas y transmites ese conocimiento a cada nuevo cliente al que vas.

De todos estos clientes, hay dos que me vienen "al pelo" para este artículo. Uno de ellos, escéptico y crítico como el que más, decía

Y todo esto de ITIL, Cuadros de Mando, métricas y mejora continua, ¿por qué?. ¿Acaso los de RRHH nos dan un SLA sobre la contratación de nuevo personal, o un cuadro de mando con indicadores sobre sus procesos de provisión de personal? ¿Acaso los de contabilidad y finanzas nos dan una definición clara de los servicios que proporcionan al resto de la organización? ¡NO!

Lo que ocurre es que en esta profesión tenemos un complejo de inferioridad tan grande, que tenemos que estar demostrando continuamente lo que valemos y para qué servimos...

 

Otro de ellos, pragmático y práctico me decía en una primera visita, cuando tenía que tratar de entender a qué se dedicaba la empresa:

No, si nosotros somos como cualquier otra empresa, nada raro: como en todas partes, hay unos que venden, otros que hacen lo que se vende y otros que controlan y gestionan para que todo funcione bien. Esas son nuestras tres direcciones generales: Ventas, Operaciones y Finanzas.

En estos dos comentarios de estos dos clientes de los que tanto he aprendido, está la clave de la pregunta que planteaba Jorge: la idea de que haya un "negocio" y un "nosotros" o de que la cosa esté en cómo nos relacionamos "nosotros" con "ellos" es totalmente errónea además de perjudicial.

Cualquier empresa u organización, en realidad es un "nosotros" y por eso los chicos de RRHH no se plantean "la alineación del departamento de RRHH con el 'negocio'" ni los de contabilidad se plantean 'integrarse' en el negocio. ¿Pero qué tontería es esta? Cada una de las funciones, actividades, roles, puestos de trabajo de una organización sirve para algo, debe servir para algo, dentro del complejo engranaje de la empresa y si no, lo que ocurre es que estamos tirando el dinero y/o el tiempo. Así, tan integrado con el negocio está el chico del almacén, como la telefonista, como de Director General y el CIO: todos son el negocio, y si no lo son, es que sobran.

Ahora bien, hay que recordar que esto no son más que palabras: En realidad, cuando se habla de "alinear las TIC con el Negocio" lo que se quiere decir es que no se debe permitir que los objetivos que mueven al Departamento de Informática de una organización sean diferentes o no estén alineados o simplemente no tengan en cuenta los objetivos de toda la organización, y que cuando se habla de "Integración con el Negocio" lo que se persigue es dar a entender la necesidad de que las unidades de la organización, las que ejecutan los procesos de negocio y utilizan los Servicios TIC como herramienta para almacenar, procesar y publicar la información de la que dependen o se basan estos procesos de negocio se integren, participen y definan exactamente sus necesidades, a la vez que el área TIC vigile y piense en cómo mejorar e incrementar la funcionalidad o el uso que se le da a estos Servicios.

Esa es la gracia de todo esto: la visión holistica del tema

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.

Herramientas

Desde que comencé a escribir en este blog hace ya casi un año, me puse el firme objetivo de ser lo más agnóstico posible en lo referente a tecnología, intentando no dar ni una sola opinión sobre productos para que este blog no se convirtiera en una actividad de márketing ni de mi empresa ni de ningún fabricante.

Pero claro, mantenerse al margen es bien difícil porque la Tecnología es parte importante de mi vida, de las TIC y uno de los famosos "tres pilares de ITIL ", ¿no?

La semana pasada me llegó un mail de Juan Martínez en el que me planteaba la siguiente consulta:

Llevo poco tiempo dentro de este mundo y ando investigando actualmente herramientas que den soporte a ITIL en concreto al proceso de Gestion de incidencias y Service Desk para realizar una comparativa de que oferece cada una. Actualmente solo conozco y he encontrado informacion sobre Remedy ITSM 7.0. Quiza sea un poco descarado por pedirte ayuda pero como te comento ando un poco perdido.¿Podrias echarme una mano?

Podría escribir un post gigantesco contandote las maravillas de algunas de las herramientas que conozco, pero en lugar de eso lo que vamos a hacer es darte una lista de las que más me he encontrado "en el campo" y, sobre todo, una lista de las cosas importantes que se deben tener en cuenta a la hora de escoger la herramienta.

Herramientas Más Comunes

Remedy : Una de las más extendidas entre los grandes clientes, ha tenido una historia curiosa, ya que es una de esas herramientas que han ido pasando de mano en mano. Extremadamente flexible, yo siempre la he definido como "un compilador de lujo para ITSM" ya que puedes hacer con ella prácticamente lo que quieras.

HP OV Service Desk: Una de las más cómodas herramientas que ha desarrollado HP, pero que ahora ha caido en desgracia por la entrada en escena de Service Center. Muy fácil de parametrizar y muy potente, un verdadero lujo.

Service Center: Descrito por un colega como "una caja de tornillos", es también una de esas herramientas extremadamente flexibles que te permitirán hacer prácticamente lo que quieras. Ahora es propiedad de HP.

Service Desk Plus: Bueno, en realidad este producto juega en una liga totalmente diferente a los anteriores, pero lo he visto en varias empresas. Simple, barato y poco adaptable, cubre las necesidades básicas de un ServiceDesk y puede servir como vía de entrada.

System Center Service Desk: Esta aún no ha salido, pero estoy seguro de que dará mucho de que hablar porque Microsoft si algo sabe hacer bien es ruido y publicidad. Por lo  pronto las presentaciones que he visto son interesantes.

Bueno, estas son las que yo me he encontrado más habitualmente en el sector en el que me muevo profesionalmente, pero seguro que otros han visto/usado/evaluado muchas más.

Puedes encontrar un listado de herramientas en estas dos ubicaciones:

Pink Verify, donde la gente de Pink Elephant pasa unos checklists públicos a los productos y establecen el nivel de adecuación (no certificación ni compatibilidad) a ITIL de cada uno.

ITSM Portal Tool Selector, donde podrás encontrar multitud de herramientas y sus características.

Siguiente entrega: criterios para seleccionar herramientas.

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!