Búsqueda


29 de marzo de 2006

La definición del Catálogo de Servicios

El Catálogo de Servicios es la piedra angular de ITIL en lo referente al tan consabido lema de alineación de las TIC con el Negocio. No deja de ser sorprendente la poca atención que se le presta en los libros centrales de Service Support y Service Delivery a algo tan importante, al mismo tiempo que es uno de los grandes reclamos de productos como el ITIL Survival Kit y similares.
Todo aquel que está interesado en la implementación de alguno de los procesos de ITIL tiene en un primer momento la necesidad o el interés de imaginar qué aspecto debe tener un Catálogo de Servicios y por eso llueven las peticiones de ejemplos, formatos, plantillas o casos de estudio en los que basar el boceto que se está iniciando.


En mi opinión, un Catálogo de Servicios debe cumplir con una serie de requisitos indispensables, a saber:

  • Debe tener una orientación especial para tres tipos de perfil diferente: el usuario, que lo utiliza para obtener información al respecto de los servicios a los que tiene acceso y la forma de interactuar con el proveedor de estos servicios (IT), el cliente, que lo utiliza como si fuera la carta de un restaurante (muchas veces se conoce como carta de servicios) y TI, que lo utiliza para dar un enfoque orientado al negocio (alineado) a sus procesos internos.
  • Debe contener los atributos necesarios como para satisfacer las necesidades de estos tres tipos de perfil.
  • Debe nacer, ya desde su mismo origen, con un espíritu flexible y adaptativo: todo cambia y muy rápidamente.
  • Debe ser publicado en un formato electrónico, accesible para todos los perfiles que lo necesiten.


Antes de acometer el redactado global de la descripción detallada de cada uno de los servicios conviene hacer un ejercicio previo orientado a dar respuesta a tres preguntas importantes: ¿Qué es para mí un servicio?, ¿Qué es para mi cliente un servicio? y Siguiendo esta definición, ¿Cuales son los servicios que proporcionamos?

Una vez resueltos estos dilemas, tendremos que decidir la lista de atributos que va a tener cada uno de los servicios; será de gran ayuda hacer un repaso de los diferentes procesos implementados o por implementar a corto plazo y detectar las necesidades de información que tiene cada uno de ellos, algo así como responder a la pregunta ¿Qué le pediría cada uno de mis procesos al Catálogo de Servicios?. Así dispondremos del conjunto mínimo de atributos necesarios, a los que deberemos añadir aquellos atributos que hagan falta para otras actividades o para facilitar la lectura/uso por parte de los clientes y usuarios finales.

Por último, la etapa final del desarrollo del Catálogo de Servicios será realizar un análisis detallado de cada uno de los servicios que hemos identificado para describir cada uno de los atributos. Aquí es donde el trabajo de definición comienza a requerir bastantes más esfuerzos, ya que tendremos que obtener información de muchas fuentes diferentes y convertirla en algo homogéneo.

En ocasiones ocurrirá que haremos preguntas que la organización no está preparada para responder, que no se ha planteado nunca o que tenía “escondidas bajo la alfombra”, y en ocasiones encontraremos que no hay una única respuesta que dar. En estas ocasiones habrá que llegar a un consenso y decidirse por una u otra opción, pero no nos engañemos: la respuesta que demos puede ser determinante para el futuro de la organización TI.

Un ejemplo de este tipo de icebergs escondidos en el mar de los servicios es una pregunta tan “inocente” como intentar decidir cuál es el modelo de métricas que caracterizan el servicio en cuanto a conceptos como la calidad o el uso que se hace del servicio en cuestión. Resulta que muy probablemente nos encontraremos con que todas las mediciones que se están tomando (o que los responsables de los trocitos de tecnología que componen el servicio nos proponen) son orientadas a la administración, mantenimiento, operación o soporte de la tecnología, pero nunca nadie se ha planteado medir el servicio. Si nos dejamos llevar por la sencillez (a preguntas concretas, respuestas concretas, yo me lo creo y asi queda reflejado en el Catálogo), estaremos cualificando la tecnología sobre la que reposa el servicio y no el servicio en sí mismo.

Por último, simplemente recordar que la definición de un servicio (es decir, todo el conjunto de atributos, reglas y relaciones que lo cualifican) acabará formando parte de la CMDB y entrará en el Ciclo de Vida de los Elementos de Configuración, por lo que habrá que contar con ellos en la creación de nuevos servicios, gestión de cambios, relación con el cliente, etc, etc, etc.

¡Buena suerte, inspiración e imaginación!


BIBLIOGRAFIA

The IT Service Catalogue
The ITIL Community forum
Virgin Mobile
How to Produce an Actionable IT Service Catalog

26 de marzo de 2006

Más reflexiones sobre la FCMDB

Le sigo dando vueltas a la idea de la FCMDB. Comentando las opiniones con algunos amigos, llegamos a la conclusión de que si la federación de directorios ha sido posible es gracias a que existen estándares para la definición de directorios y para el intercambio de información estructurada entre ellos, así que lo que necesitamos es que existan estándares para la consulta y definición de la CMDB.

Bien pensado, si hemos sido capaces de evolucionar hacia SOA, ¿por qué no podríamos tener consultas entre entornos que nos den la información extendida y para asegurar que las diferentes herramientas son capaces de comunicarse entre ellas disponer de algun tipo de estandard al respecto de la construccion de la CMDB?

Este es uno de los curiosos puntos débiles de ITIL (que tendremos que analizar en un artículo específico): ITIL no es un estandard, no es una norma ni una metodología; es un estándard de-facto y un conjunto de buenas prácticas. Así que no especifica exactamente qué contenidos o qué formato debe tener la CMDB y por lo tanto no establece un marco común para que los fabricantes de productos se adhieran.

Pero claro, el Sr. Google lo sabe todo. Buscando buscando, he llegado a una iniciativa realmente interesante y que, a priori, me parece que tiene mucho sentido y que es la vía para alcanzar la idea de la FCMDB: el DCML o DataCenter Markup Language. Se trata de la definición de una especificación que debe permitir describir un datacenter, su entorno y sus componentes. Literalmente, dice algo así como "DCML provides both an inventory of data center elements and the desired functional relationship between them. "

Me ha llamado mucho la atención la lista de participantes en el proyecto: los sponsor members son BMC, CA, EDS, Opsware y Tibco. Justamente la lista de compañías que están hablando, escribiendo artículos y propagando el concepto de FCMDB. Si buscamos FCMDB en Google, la primera entrada es la de Resonance Group, la gente que produce nLayers y que es un gran partner de OpsWare.
Así, con el DCML empezando a crecer (ya está la primera especificación "en la calle") y con los fabricantes más importantes trabajando en ello (¿Por qué HP no estará en la lista? Habrá que preguntarlo) parece ser que los primeros pasos para que la FCMDB sea una realidad están dados; ahora viene la pregunta dura:

¿Cuánto tiempo tendrá que pasar antes de que DCML se convierta en algo tan extendido como el XML?

Fijémonos en lo que le está costando a SOA entrar en el mundo de las aplicaciones. Es algo que existe desde hace años, pero pocos son aún los productos que se puedan intercomunicar usando este modelo. Quizás falte aún unos 5 añitos antes de que veamos a los productos usando CMDB Federada basada en DCML y lo suficientemente extendidos como para que podamos decir que es una realidad (visionarios los hay siempre; de hecho ya hay productos usando DCML pero no podemos decir que estén precisamente extendidos).

En definitiva y como siempre: el tiempo y el mercado dirán lo que tengan que decir.

BIBLIOGRAFIA

Demystifying The CMDB
Federated database manages change

25 de marzo de 2006

La Memoria Histórica

Soy un tipo con mala memoria. Me pasa siempre que en el trabajo, en casa, con los amigos siempre se me olvidan las cosas a corto y no es por que no les de importancia o por que no preste atención; simplemente se me olvidan… ¡pluf! desaparecen de mi memoria como si nunca hubieran existido.

Ver la película Memento me dejo bastante marcado

Y entonces empecé a pensar en términos empresariales: si una organización no tiene memoria, ¿qué le pasa?.

Un día, hablando con mi gran amigo Víctor mientras tomábamos unos rones me dijo

-- “la clave de la inteligencia está en ser capaz de predecir el futuro.”


-- “la clave de predecir el futuro esta en ser capaz de recordar el pasado.” - le contesté yo sin pensarlo dos veces.

Sinceramente creo que estas dos frases tienen la clave de muchas cosas a nivel empresarial; tienen la clave de los cuadros de mando, del datawarehouse y el business intelligence y, sobre todo, tienen la clave del buen gobierno de las TIC.

Muchas veces cuando estoy desarrollando proyectos de implantación de algún tipo de proceso ITIL o cuando estoy dando formación, suele aparecer la duda al respecto de qué métricas se deben aplicar para medir el correcto desempeño de un proceso. Normalmente la respuesta va ligada al tipo de proceso, a los objetivos que debemos cumplir, a lo que queremos conseguir mediante la obtención de la métrica, etc..

Pero de todas formas, una métrica es una métrica. Qué pasa si yo contesto “2”. Si, un simple y vacío “2” es el valor de la métrica. ¿Es mucho? ¿Es poco? ¿Es razonable? Y la pregunta más dura para todos los consultores que se dedican a este tipo de cosas: ¿Cuánto es un valor normal?

Para responder a todas estas preguntas entra en juego la memoria histórica. Siempre digo en mis cursos que “medir es comparar algo con una unidad de medida” y por lo tanto “2” es un número tan vacío como “2000”. Para saber si el valor obtenido para una métrica es bueno o malo lo debo comparar con esa unidad de medida que debo establecer antes y que variará entre una organización y otra y que será el listón que me ponga. Así no sólo debo medir, sino que también debo saber con que comparar: resolver el 80% de las llamadas en primer nivel de soporte ¿es un buen nivel para la métrica de autosuficiencia? En algunos casos si y en otros casos evidentemente no; y en tu caso concreto, pues ¡tú sabrás! Lo que debemos hacer es primero saber cuál es el porcentaje de autosuficiencia que estamos dando, identificar si para mis usuarios y clientes ese valor es correcto y decidir si es mucho o poco.

Y luego viene la segunda parte: después de años midiendo este valor, ¿hemos progresado? Pues aquí entra en juego otra vez la memoria: si no tengo memoria como organización no tengo idea de qué es lo que ocurrió en el pasado y no se exactamente cómo ha evolucionado cada uno de los parámetros.

Qué importante se hace, entonces, el disponer de un mecanismo que apoye a nuestra (poca) memoria y nos permita almacenar, representar y documentar los valores de cada una de las métricas y, de esta forma, disfrutar de esta “memoria digital” que nos permitirá ser una organización más inteligente porque podrá predecir el futuro.

23 de marzo de 2006

La CMDB Federada

Últimamente oigo hablar mucho del concepto de CMDB Federada (o FCMDB o Federated CMDB) y a más vueltas de cabeza le doy menos me atrae el concepto.
Claro, también puede ser que no lo entienda y simplemente en este artículo no esté haciendo nada más que dejar patente mi ignorancia, que también puede ser, por eso en la introducción a este blog se habla de miles de dudas y sólo de decenas de ideas.

¿Qué quieren decir los fabricantes cuando hablan de FCMDB?
Pues a nivel conceptual la idea es buena y tiene sentido: se trata de no tener duplicada la información sino "punteros" a donde se encuentra la fuente de la información puramente. Así, en una FCMDB en lugar de tener una base de datos con los 1.000 elementos de red que hay en mi red, lo que tengo es un enlace a la herramienta de descubrimiento de redes donde se mantiene el inventario (ojalá que automatizado) de estos elementos.

Claro, pero no sólo de redes se compone mi CMDB, así que también tendré que tener el enlace a las herramientas de inventariado de PCs, de servidores, de almacenamiento, etc, etc, etc. De esta forma, en lugar de tener una CMDB con miles de elementos que se han "sincronizado" (importado o reconciliado) desde los diferentes repositorios de las herramientas de inventario y de tener la obligación y la seria responsabilidad de mantener esta información debidamente actualizada, lo que tengo es una CMDB con toda una serie de "punteros" que me permiten obtener la información directamente desde su fuente.

Ah, interesante. ¿Entonces?
A este modelo, que a priori parece totalmente adecuado, a mi se me antoja que le fallan algunas piezas de base:

Para empezar está el hecho de que tenemos que tener claro que el objetivo de una herramienta de inventario técnico es ofrecernos, como dice un cliente mío, "datos para aburrir". Estos datos son obtenidos por las herramientas con el fin de facilitar el soporte, proporcionar preciosos reports que faciliten la vida de los administradores o incluso aportar datos de carácter menos técnicos pero que ayuden a tomar decisiones a alguien: marca, modelo, numero de serie, capacidad, componentes, estado, software instalado, procesos en ejecución, contenido de los ficheros de configuración; no se: un sinfín de datos que en mayor o menor medida le sirven a alguien para hacer su trabajo.

Pero la CMDB es la base de todos los procesos ITIL, y debe contener los atributos necesarios para soportar cada uno de los procesos que la compañía tenga implantados y los procesos ITIL son muchos y variopintos. ¿Acaso una herramienta de inventario será capaz de saber el número de factura del proveedor que me vendió el equipo? ¿Será capaz de decirme cómo se reparten los costes indirectos para el modelo de costes? Es evidente que no, así que esos atributos del Elemento de Configuración los tendré que ir a buscar a otra parte, o los tendré que aportar manualmente después de que un humano tome alguna decisión al respecto.

Y esta afirmación me lleva directamente a otro modelo: tengo una CMDB "de las de toda la vida" con la información que yo necesito y, cuando necesito información ampliada, la herramienta me proporciona las integraciones o funcionalidades necesarias para acudir a la fuente de información y consultarla. Algo así como "en la CMDB se almacenan los datos necesarios para soportar los procesos y si necesitas el inventario detallado hasta el último bit 'para aburrir' pulsas un botón y te llevo directamente a donde está esa información".

Por otra parte, está el hecho de que los fabricantes de herramientas que me permitan implementar una FCMDB son eso: fabricantes, o sea empresas que hacen una gran inversión en I+D y que esperan lucrarse con la venta de licencias y servicios alrededor de los productos desarrollados. La federación de los datos deja totalmente en manos de otros el contenido, la fiabilidad, la velocidad, la usabilidad y la "buena presencia" de mi CMDB y, por si fuera poco, resulta que es imposible federarse con todos los fabricantes de inventario, porque todo cliente tendrá siempre alguna fuente de datos hecha a medida (¿cuántas hojas Excel, ficheros de texto y ficheros Access hay sueltos por el mundo con la información más preciosa de las organizaciones IT?).

De esta forma, tengo que decir que no creo en la FCMDB multifabricante, abierta y genérica. Si que creo posible (y útil e inteligente por parte de los fabricantes) una federación "endogámica", en la que un fabricante desarrolle una CMDB que se federe con sus propios productos y quizás con los de sus mejores partners pero ¿se imaginan a HP federando su CMDB con IBM, CA y BMC?

Yo no.