Aranda SOFTWARE Connection

IT Evolution - experiencias en gestión de IT
Aranda SOFTWARE
Aranda SOFTWARE

Soluciones de administración empresarial que permiten el desarrollo de las mejores prácticas de gestión IT / Solutions to manage your IT resources.

TwitterFacebookPageVimeo

Ver tambien

Nosotros

Nuestros Canales

Tags

Archivo

2012 (71)
2011 (116)

Suscripción

Autores

Aranda SOFTWARE
 

Recomendaciones Administración CMDB

Corrección de estilo: Francisco J Ramírez

¿Cómo puedo optimizar el uso y funcionamiento de una CMDB con información correcta y actualizada?

Image001

La CMDB proporciona un modelo lógico de la Infraestructura de TI para el mantenimiento y gestión de los componentes de servicios, compuestos por elementos de configuración llamados CI. La importancia radica en administrar adecuadamente el proceso de Gestión de Configuraciones porque permite tener una imagen global de la infraestructura TI y es núcleo esencial de todo el proceso de servicio de mesa de servicio.

A continuación, presentamos algunas recomendaciones a seguir para la eficiente administración y funcionamiento de una CMDB:

  • Defina un rol o responsable dentro de la organización que administre la CMDB; descentralizar las funciones puede generar descoordinación y generar altos riesgos para el proyecto.
  •  La actualización de la información contenida dentro de una CMDB debe ser constante.La información cambia con frecuencia y los datos que eran correctos la semana pasada podrían ser ineficientes y obsoletos esta semana.
  • La configuración definida para la administración de los datos debe estar disponible para todos los procesos generados en la mesa de servicio de TI. Por ejemplo, si los datos de licencias de software no están disponibles para una Gestión de Cambios, no será posible diseñar un plan de adquisición de licencias de dicho software.
  • Realice la adquisición e inversión de una herramienta de software certificada que se adecúe a los requerimientos de la organización, bajo los lineamientos definidos por ITIL. Algunas veces se percibe esto como una desventaja ya que la inversión económica generalmente es alta para este tipo de soluciones.
  • Genere un filtro cada vez que se realice una carga de CIs, dependiendo del estado de su ciclo de vida. Es decir, pueden obviarse componentes que ya han sido retirados del negocio.
  • Se debe predefinir los códigos de clasificación de los CIs, teniendo en cuenta que este identificador debe ser único y comprensible por el personal interno de la empresa. Se puede utilizar como identificador el nombre de la PC, siempre y cuando este nombre sea definido bajo una nomenclatura estándar dentro de la organización. Adicionalmente, este identificador debe ser usado tanto para activos de hardware y software.
  • Todos los activos de la organización deben estar registrados dentro de la CMDB, para definir de manera adecuada y bajo un planeamiento las interrelaciones entre los mismos.
  • Genere los informes e indicadores adecuados que permitan evaluar el rendimiento del servicio de TI y mejorar la estructura e interrelaciones de los activos dentro de su ciclo de vida.

Administrar eficientemente una CMDB genera grandes beneficios y una mayor productividad para la organización, pero si no se implementa correctamente existe el riesgo que solo se genere pérdida de tiempo y malestar por no obtener a cambio los frutos esperados. Es por esto, que una Gestión de Configuraciones necesita la colaboración de toda la estructura TI para mantener actualizada toda la información almacenada en la CMDB.

 

Fecha:
 

Importancia de la relación de un CI a una incidencia

Por: Diego Fernando Rincón Guevara

Corrección de estilo: Francisco J Ramírez

En el marco de ITIL existen muchos factores que influyen en el proceso de gestión y ciclo de vida del servicio. Al hablar de incidentes se debe empezar por su definición, como una interrupción en el servicio prestado a un usuario o cliente. Este incidente afecta un componente de la organización y debe ser resuelto de manera rápida y oportuna, garantizando la solución del mismo y dando los lineamientos necesarios para evitar que el incidente se repita.

Las herramientas en el mercado donde se registran este tipo de situaciones,  trabajan con base a las mejores prácticas de gestión de servicios, muchas basadas en ITIL. El proceso de incidentes comienza cuando los usuarios reportan un caso a un único punto de contacto. Ejemplo: la caída de una aplicación web, que funciona en un servidor llamado “ZEUS” y que maneja el sistema de ingresos de las personas a un edificio corporativo.

 

Image003
 

Para la mesa de servicios y para la gerencia, es importante conocer estadísticamente, ¿Cuántas veces las personas no pueden ingresar a tiempo al edificio? ¿Por qué el nivel de tiempo de trabajo es relativamente menor algunos días en comparación a otros?. Para entender esta situación se debe conocer el origen del incidente. En nuestro caso, cuando una persona llega al edificio, presenta su identificación al sistema de ingreso y éste no es capaz de procesar la solicitud, se genera la interrupción del servicio. Teniendo en cuenta esto, se notifica a la mesa de servicios para poder solucionar el incidente lo más pronto posible. Cuando el usuario llama a reportar el inconveniente, los especialistas debe tener en conocimiento y registradas las siguientes variables o interrogantes:

  • ¿Qué sistema permite el ingreso a los usuarios al edificio?
  • ¿En qué servidor se encuentra alojado dicha aplicación?
  • ¿Será posible que el  dañó se encuentre en el hardware que controla el software de ingreso?
  • ¿Es este elemento de alto impacto para la organización?

 

El conocer esta información es relevante al momento de registrar el incidente en una herramienta como Aranda SERVICE DESK, porque  puede llevar el control y gestión del caso, los avances de tiempo y acciones realizadas relacionando al elemento, activo o ítem de configuración [1]afectado.

La relación de un elemento de configuración CI en un incidente permite conocer el impacto del CI dentro de la organización a fin de dar celeridad al proceso de solución de casos. Para el ejemplo citado, el control de acceso de un edificio, además de tener el servidor “ZEUS” asociado, puede tener relacionado en una jerarquía inferior una serie de dispositivos o aplicaciones que pueden estar siendo afectados o que directamente puede ser la causa del inconveniente reportado. De esta manera es visible, un análisis rápido y oportuno que permite a la mesa de servicio restablecer el servicio de forma rápida o colocar otro servidor de contingencia para que el acceso al edificio sea restablecido.

A fin de mes, podrá identificar las métricas del proceso como: El número de incidentes que generó el sistema de acceso al edificio y cuántos de éstos incidentes se crearon y tuvieron relación con el servidor “ZEUS”, conocer las diferentes soluciones a los incidentes y establecer qué cambios se realizaron en el elemento (si hubieron) para restablecer el servicio y mejorar el tiempo de vida del elemento, la continuidad del negocio y la operación del mismo.

 


[1] En la gestión de incidentes es importante tener un responsable  encargado de llevar en una base de datos de configuración CMDB (Configuration Management Database), la gestión de cada activo, mostrar las relaciones entre cada uno de esos activos y llevar un historial de todos aquellos que pasan por la organización; desde su compra hasta su baja por finalización de su vida útil. Esto implica que cuando se registre el incidente, se asocie el elemento y los demás actores del proceso puedan  enterarse del inconveniente y la relevancia de lo  reportado por un usuario.

 

Fecha:
 

Qué no es una CMDB?

Por: Oscar Julián Beltrán

Corrección de estilo: Francisco J Ramírez

La CMDB como repositorio de información debe relacionar diferentes componentes tecnológicos o elementos de configuración (CI) físico o lógico, para representar la configuración e interacción entre ellos, y así medir el impacto de una falla o cambio del componente sobre la organización. En la definición de un CI surgen confusiones sobre lo que debe ir o no dentro del levantamiento inicial. A continuación presentamos una guía para identificar lo que No es una CMDB, al lograr diferenciar y definir correctamente  los elementos a controlar en su Organización.

Image001
 

1.  LA CMDB NO ES EL INVENTARIO:
Siendo la CMDB el único repositorio de activos tecnológicos de la organización, es posible que los elementos que usted tenga registrados no sean la totalidad de los CIs existentes.  Esta situación radica en que no se pueden controlar todos los elementos y solo mantiene los activos que puede controlar; concepto que va alineado con las mejores prácticas de ITIL. 

Es posible que para un área de contabilidad sea necesario conocer cuántas pantallas y estaciones de trabajo existen, porque en el manejo contable estos elementos son activos de la empresa; pero para el área de tecnología, solo será necesario registrar como activo, el computador completo uniendo las dos partes. 

En otro caso, un mouse pad con esfero para diseñador, puede que no sea importante para contabilidad por el valor del elemento, pero  es muy importante para el área de tecnología ya que afecta cualquier actualización sobre el sistema de ese diseñador. 

Para estos casos, no debe buscar generar una replicación completa de los elementos que tiene Contabilidad, ya que caería en el error de tomar decisiones basadas en criterios muy diferentes a lo que usted busca en el Área de TI.

2.   NO ES EL REMPLAZO DEL EXCEL 
En la definición de la CMDB es posible que en un primer paso se utilice la información registrada  en un archivo de EXCEL,  sin embargo es solo una parte del proceso de definición de activos. No habría beneficio con solo transcribir los datos de un sistema a otro. 

Es necesario que esta información este acompañada por las relaciones que existen entre los componentes, y poder identificar en qué medida un elemento de configuración afectó un proceso, un activo de negocio o el mismo Core de la organización.

3.   NO ES UNA MIGRACIÓN DE DATOS 
Aunque la CMDB es una Base de Datos, no debe intentar unificar toda la información en un solo punto. Es posible que su organización maneje varias estructuras de información y realice esta recolección en múltiples espacios.  En la CMDB es necesario referenciar estos espacios de trabajo y desde este punto realizar un control y gestión sobre el activo. 
Es  posible que algunos elementos si se “migren” o se gestionen a la base de datos de configuración, pero primero debe realizar un análisis profundo de las funcionalidades que va a ganar y a perder, además de gestionar todo el manejo del cambio, costo y esfuerzo que implique la transferencia.


4.       NO ES LA SOLUCIÓN A TODOS LOS PROBLEMAS. 
De la misma forma que indica ITIL al referirse de la 4 P’s de ITSM (Information Technology Service Management), es necesario habilitarlas en la construcción de la CMDB y por tanto lograr su éxito.

  • Personas: Debe contar con el personal adecuando para el levantamiento y actualización de la información. Estas personas van desde labores operativas, hasta roles administrativos como elde Gestor de la Configuración o el Gestor del Proceso de Cambios. 
  • Productos: Las herramientas agilizan, simplifican y mejoran el seguimiento a la CMDB. Sin embargo no es lo único en lo que se debe enfocar el área. 
  • Socios de Negocio: No todos los activos tecnológicos están controlados por la organización y es posible que un tercero realice la gestión y control de algunos elementos, tales como outsoursing para la gestión de impresión entre otros. No obstante, la caída o modificación de ciertos activos puede verse afectada o afectar a algún activo del socio de negocio. Por tanto debe considerar los elementos que cumplen o encajan en estos escenarios y hacer partícipe de esta información al socio de negocio. 
  • Procesos: Un proceso en la CMDB es un elemento de vital importancia para reportar cualquier modificación, adición o eliminación de un activo tecnológico (CI). El no tener un proceso definido puede ser causa del fracaso de la Gestión de la Configuración.  

Por ejemplo su proceso debe: Registrar cada vez que un computador ingresa a la compañía. 
  • Registrar cada vez que se envié a mantenimiento un equipo. 
  • Registrar cualquier cambio de usuario o responsable de los elementos dados a una salida del personal o una referencia del mismo. 
  • Registrar todo incidente, llamada de servicio, problema o cambio en el que se vea afectado el componente. 
  • Informar a los afectados en cada caso que un elemento este escalado a modificación o eliminación.

Tenga en cuenta, que todas las organizaciones son diferentes, y por tanto su manejo en tecnología también lo es. Es posible que se asesore con otra empresa para el manejo de la CMDB, pero debe tener cuidado con realizar los mismos procedimientos o decisiones que se tomaron. Las dificultades que solucionó la organización, pueden ser diferentes a los inconvenientes que usted presenta y por tanto no las solucionará implementando el modelo guía.
Fecha:
 

Para qué me sirve la CMDB - 5 pasos para su creación

Por: Oscar Beltrán

Corrección de estilo: Francisco J Ramírez

Image003
En el mundo de las mejores prácticas de ITIL, encontramos  una variedad de conceptos, acrónimos y procesos, que al intentar manejarlos al tiempo pueden generar un impacto negativo en nuestra organización; por ende deben ser utilizados correctamente.

Dentro estos lineamientos metodológicos se destaca un proceso simple, fácil de implementar que está ligado a diferentes procesos. El concepto más relevante y valioso es el de la CMDB[1] cuyo enfoque principal es brindar en un único sitio, todas las relaciones, acciones, cambios e impactos de un activo tecnológico en la organización. Es aquí, donde cada empresa o área tecnológica debe enfocarse, si desea conocer cómo es su negoció y cómo puede gestionarlo.

La CMDB como repositorio de información debe relacionar cualquier componente tecnológico o Ítem de configuración (CI) físico o lógico, para representar la configuración e interacción entre ellos, y poder determinar el impacto de una falla o cambio de un componente sobre la organización. Antes de iniciar con la construcción debe tener en cuenta los siguientes objetivos:

·         La CMDB debe permitir visualizar ágilmente, cuáles son los elementos impactados frente a un cambio o falla de ese componente.

·         Cada componente debe tener toda la información requerida para poder tomar una decisión sobre su transformación o evento.

·         Un CI sin relaciones, no es más que un inventario y por tanto solo permite tomar decisiones de  mejora o eliminación,  perdiendo el sentido real de lo que es el repositorio.

·         La CMDB no va a remplazar a un software de diagramación de red, ya que su propósito es complementario y aumentado.

 

Tenga en cuenta estos elementos durante todo el procedimiento de construcción y levantamiento de información que sucede a continuación.


1.       DEFINA EL ALCANCE

Antes de iniciar con el ingreso y levantamiento de información, primero debe considerar, qué es lo que realmente quiere colocar en el sistema, y por tanto qué está dispuesto a controlar; por esto debe tener en cuenta los siguientes criterios:

  • Lo controlo?
Muchas veces se realiza la carga de todos los elementos físicos que tiene la organización, sin  tener en cuenta que hay un grupo de elementos sobre los que no se tiene control sobre sus movimientos, o que su manejo no depende del de área TI y por tanto conocer su estado no es fácil o no se reporta al área.

  • Genera la Información que requiero? 

Al incluir ítems en la CMDB, se encuentra con una cantidad de elementos que no son informativos o que su existencia no es determinante en un proceso de gestión de incidentes, problemas o cambios.

Ejemplo: Un computador puede ser definido como un (1) CI, pero también puede ser considerado como un conjunto de cuatro (4) CI’s: la CPU, la pantalla, el teclado y el mouse.

De validar el conjunto es posible que deba realizar un seguimiento de 4 elementos en vez de uno, y asumiendo que es una compañía de 2000 máquinas, el número de elementos de control podría llegar a ser 8000.

Ante esta situación  vale la pena hacerse las siguientes preguntas: ¿es necesario controlar el teclado? ¿Al realizar el diagnóstico de cambios va a importar el tipo de teclado o mouse que tiene el cliente?. Si las respuestas son negativas, seguramente no se debe realizar la carga de estos elementos como CI y lo más adecuado es que esta información sea una característica propia o componente del CI Computador.

 

2.       DEFINA LOS TIPOS DE ÍTEMS DE CONFIGURACIÓN

Los activos tecnológicos no necesariamente son elementos físicos de TI, también pueden ser lógicos[2] tales como bases de datos, programas cliente servidor, interfaces, incluso manuales. Cada elemento de configuración debe tener su propio ciclo de vida y características propias.

Ejemplo: Las impresoras en su ciclo de vida, ingresan a bodega, pasan a ser un activo, se les da mantenimiento y se dan de baja. Una base de datos primero está en desarrollo, luego pasa a pruebas, seguido se deja activa y finaliza en una etapa de actualización. Por otro lado, en una impresora puede ser importante el tipo de toner que se usa, mientras que en una base de datos se requiere el tipo de motor en el que se está trabajando.

3.       OBTENGA LOS REQUERIMIENTOS MÍNIMOS

Existen dos tipos de requerimientos mínimos: Recurso Humano y Activos Tecnológicos.

Los Recursos Humanos se refieren a las personas que van a realizar el seguimiento de los CIs, y que pueden cumplir el rol de gestores de configuración. Sin el personal adecuado, el mantenimiento de la CMDB puede ser traumático.

Los elementos de configuración tenológicos se refieren a las características propias de cada tipo de activo. Cada elemento de configuración debe tener un único nombre distintivo compuesto por el modelo, el centro de costo y la oficina en que se ubica; todos los elementos deben tener su ubicación, propietario y usuarios del elemento.

4.       DEFINA EL TIPO DE RELACIONES A GESTIONAR

La relación existente entre cada elemento de configuración, es la principal diferencia entre mantener una CMDB gestionada y una hoja de Excel con el inventario de los activos. De allí que es tan importante que conozca y defina, el tipo de relaciones va a manejar. Estas pueden ser lógicas (consultado por, documenta a, contingencia de) o físicas (conectado a, instalado en, es parte de). Tenga en cuenta que cada relación creada debe ser controlada y por tanto gestionada.

5.       GESTIONE EL PROCESO DE REGISTRO

Cualquier herramienta que utilice debe ser definida por un proceso que soporte la operación, permitiendo que cualquier modificación en los activos se refleje en la CMDB y por tanto su actualización constante debe ser el reflejo de lo que está sucediendo en TI. Al no velar por este procedimiento y sus modificaciones, se corre el riesgo de tener una CMDB desactualizada y genera desconfianza en la información levantada.

 

El correcto uso de la CMDB en la gestión de los elementos de configuración de su organización, le permitirá conocer y mantener actualizada la información de sus recursos  mientras reduce costos y mejora los niveles de servicio.

 


[1] Configuration Management Data Base – Base de Datos de la Configuración  

[2] Una de las diferencias principales frente a un software de monitoreo de red.

Fecha:
Tema original de Cory Watilo.