Management

Share

Dentro de unos dias haran 2 años desde que empezamos en mi organización a implantar la ISO20.000 (o algunos de sus procesos).

Despues de este tiempo creo que ya podemos mirar hacia atras y evaluar como fue esta aventura, pero hoy en concreto me gustaria centrarme quizá en un pilar del proyecto, que en nuestro caso fué la CMDB (supongo que como todas las organizaciones de TI) y en concreto como la implantamos, que diseño escogimos y como se implantó con herramientas open source.

Porqué una CMDB?

Una de las primeras cosas que se detectaron en el assessment que nos realizó la consultora que nos dió el empujon a este mundo fué la falta de una CMDB.

Parece una cosa verdaderamente superflua seguramente, pero despues de este tiempo uno va viendo como se van desarrollando los procesos, y como al final, todos ellos acaban vertebrados en una BBDD que empezó con una decena de CIs y que a dia de hoy supera de largo el millar. A dia de hoy en mi organización podemos ir a ella y encontrar lo que buscamos, y ver además las relaciones entre los distintos elementos de configuración. Empieza a ser útil.

Hablando con compañeros de otras organizaciones me sorprendió ver que la gran mayoria no disponian de una herramienta única de gestión de CIs, o que esta se basaba en una hoja Excel. Al final lo que ví en una buena parte de organizaciones era que la CMDB era una herramienta burocrática de gestión, y no una herramienta de soporte a las operaciones.

Que me aporta?

Quizá la primera pregunta que tenemos que hacernos es: Que me aporta disponer de una CMDB? Yo lo resumiria en los siguientes puntos:

  1. Disponer de un registro de todos los elementos, tanto físicos como lógicos, que gestiona el departamento
  2. Tener documentadas las relaciones entre estos elementos (interficies, instalaciones, ...)
  3. Poder ver de forma rapida los CIs y como son afectados por las operaciones (incidencias, problemas, cambios, peticiones de servicio, ...)

Qué tiene que tener la CMDB?

Si tuvieramos que disponer de un pequeño catálogo de características que tiene que tener la CMDB, quiza yo empezaria con las siguientes características básicas:

  • Poder crear un arbol de clases de CI ajustado a las necesidades de mi organización (Hardware - Servidor )
  • Poder definir atributos personalizados en función de la clase de CI (ServidorFisico: Num serie por ejemplo)
  • Poder relacionar CIs en función de dependencias personalizadas (ServidorVirtual - <se aloja en > - ServidorFisico)
  • Que el acceso a la CMDB sea facil y rápido, tanto por los técnicos del departamento de TI como por otras aplicaciones de gestión (Gest. de incidencias, peticiones de servicio y cambios, Cuadros de mando, ...)

Cual escoger?

Llegados a este punto, vemos que una hoja de cálculo claramente no puede cubrir estas necesidades, con lo que hay que ir a un software especializado.

En este punto podemos ver 2 grandes grupos de aplicaciones: las standalone, que se instalan de forma independiente y tienen que integrarse con el resto de software de operaciones, y las integradas en un paquete de software más global, que incluye ya la gestión de operaciones de forma íntegra.

En el segundo grupo podríamos citar a aplicaciones como BMC Remedy, HP Openview (y sus subproductos) o similares; en el primer grupo citaré la única solución con la que he trabajado: CMDBuild.

Hablando un poco de CMDBuild, puedo deciros que nos ha sorprendido grátamente, principalmente por su flexibilidad y su sencillez (que no simplicidad). Quizá como punto de mejora citaria el reporting, que es muy complejo con herramientas quizás demasiado técnicas. Si no teneis un sistema integral os recomiendo encarecidamente que lo evaluéis.

Como empezar?

Una vez escogida la herramienta, es importante poder tomarnos nuestro tiempo diseñando la CMDB. Aquí os aconsejaria dos puntos clave:

  1. No os lanceis implantando la herramienta sin pensar un poco en el diseño de relaciones y clases de CI, ajustandolo a vuestras necesidades (un arbol de CIs simple es tan poco útil como uno demasiado complejo)
  2. No le deis demasiadas vueltas al arbol: se puede modificar y actualizar, ya que tambien estan las organizaciones que se pasan meses pensando en el diseño y acaban abortando el proyecto por falta de resultados.

El diseño que usamos en mi organización es el siguiente:

 

Como podeis ver, tiene su complejidad, pero aún así hay que pensar que al final habrá una serie de personas que utilicen las relaciones más 'técnicas' (chasis, servidor, red, ...), otras con ámbitos más de software (instancias de software, sistemas, plataformas, y finalmente un pequeño grupo que usará las superiores, de SLA, Clientes, Servicios, ...

Como seguir?

Una vez hecho el diseño os recomiendo seguir el proyecto con 2 grupos de trabajo, un primer grupo que importe o registre los CIs más técnicos (servidores, cabinas, redes, ...) y un segundo grupo que se encargue de crear los CIs más relacionados con el negocio (clientes, servicios, catálogo, ...).

Pasado un tiempo veremos que cada grupo de forma independiente ha creado sufienciente masa críticia como para empezar a relacionar los CIs más abstractos y de negocio con las infrastructuras físicas. Aqui canviaria la estratégia, y crearia grupos de trabajo que se focalicen en los diferentes servicios, con el fin de garantizar que estan correctos de principio a fin.

Integración!!!!

Finalmente me gustaria volver a hacer hincapié en la integración. Creo que esta es clave en todas las herramientas de gestión, pero en este caso, siendo la CMDB la 'base' de todos los procesos operativos, esta es fundamental. Así podemos encontrar relaciones muy importantes, como pueden ser:

  • CIs de 'Servicio': Relacionado en todas las incidencias, problemas, cambios, entregas, pudiendo ver, por cada uno de los servicios de nuestro catálogo su 'estado' (muchas incidencias, pocos cambios, etc...)
  • Gestión de capacidad y disponibilidad (volvemos a los servicios y los CIs en general)
  • KPIs por servicio (otra vez)
  • SLAs y documentos de contrato (garantias, soporte, etc.).

Con esta filosofia veremos que al final, la gestión de ticketing, cambios, etc queda toda ella relacionada gracias a la CMDB, y todo ello agrupado y analizado finalmente en los diferentes cuadros de mando de gestión que usemos para seguir el dia a dia de la organización.

La base de las herramientas de gestión de operaciones

Al final, y tal y como he ido detallando en varios puntos, aunque quizás de forma desordenada, podemos ver que todas las herramientas del dia a dia pueden estar apoyadas por la CMDB. Además esta nos facilitará la extracción de datos agrupados en servicios o CIs de forma general, permitiendo un nuevo nivel de análisis mucho más transversal y que nos permita eliminar los difentes silos en los que se convierten las areas de TI con el tiempo.

Add comment


Security code
Refresh