La diferencia entre administrar incidentes y administrar problemas

Por José Arias

Corrección de Estilo: Francisco J Ramírez 

Las organizaciones o áreas de TI reciben en mayor o menor proporción, llamadas de clientes y/o usuarios que solicitan soporte al presentarse fallas o incidentes recurrentes que impactan en forma negativa la calidad del servicio de TI que reciben.

En el mejor de los casos, el usuario o cliente recibe indicaciones para continuar trabajando, sin considerar que el incidente se repita en el futuro. Las áreas de TI que actúan solo de manera correctiva (“apagando fuegos”) terminan generando acumulación de trabajo, pues tienen que resolver, de manera simultánea, incidentes anteriores nunca resueltos y los nuevos incidentes; este es el inicio de un “círculo vicioso” (la antítesis de la mejora continua).


Image001
Para revertir y mejorar este escenario, las organizaciones deben conocer la diferencia que existe entre un Incidente y un Problema. ITIL define estos dos conceptos así: 

  • UN PROBLEMA es una condición identificada con frecuencia como el resultado de múltiples incidentes que presentan síntomas comunes. 
  •  UN INCIDENTE es un evento que no es parte de la operación normal del servicio, el cual causa, o puede causar, una interrupción a, o una reducción en, la calidad de ese servicio.

 La diferencia principal entre administrar incidentes y administrar problemas radica en sus obj etivos. La  administración de problemas tiene como meta detectar la causa fundamental de un incidente y generar la solución posterior (prevención). En la administración de incidentes, el propósito es restaurar el servicio en forma rápida y oportuna, con frecuencia haciendo uso de soluciones temporales y no a través de la definición e implementación de una solución permanente.

¿Cuáles son las consecuencias de no Administrar los Problemas?

 De acuerdo a ITIL, los costos de no implementar  la administración de problemas son:

  • Se tiene una organización de soporte meramente reactiva que enfrenta los problemas sólo hasta que el servicio a los clientes se interrumpe.
  • Una organización de usuarios de TI enfrentada a incidentes recurrentes y que pierde la confianza en la calidad de la organización de soporte de TI.
  • Una organización de soporte poco efectiva que enfrenta altos costos y una baja motivación de los empleados, ya que tienen que resolver incidentes similares repetidamente (no se proporcionan soluciones estructurales).

Beneficios de administrar los problemas

  • Mejora la calidad del servicio de TI: La  administración de problemas ayuda a generar un ciclo de rápido crecimiento en la calidad del servicio de TI. Un servicio consistente de alta calidad es bueno para los usuarios de TI y para la productividad y moral de los proveedores de servicios de TI.
  • Reducción del volumen de incidentes: La administración de problemas ayuda a reducir el número de incidentes que interrumpen el desempeño del negocio.
  •  Solución permanente: Reducción gradual en el número e impacto de problemas y errores Conocidos.
  •  Mejora el aprendizaje organizacional: El proceso de administración de problemas se enfoca en el concepto de aprender de las experiencias pasadas. El proceso provee la información histórica para identificar tendencias y los recursos adecuados para prevenir errores reduciendo su impacto, lo que resulta en un incremento en la productividad del usuario.
  •  Mejora la tasa de incidentes resueltos en la primera vez en Service Desk: La administración de problemas permite mejorar el número de incidentes resueltos en un primer contacto del usuario, logrando a partir del registro de las llamadas en la mesa de servicio, una base de conocimiento disponible con la información consistente de incidentes y soluciones temporales a disposición del cliente.

La gestión de incidentes y problemas que se presentan en áreas de TI en una organización, deben estar siempre alineados con las mejores prácticas ITIL y con procesos estructurados para responder en forma eficiente los casos generados en la mesa de servicio, con el fin de mejorar en forma continua la calidad del servicio y la solución a los problemas de TI.

 

Otros Artículos publicados de su interés:

El Checklist de un SLA- Service Level Agreement

Cómo Diseñar Catalogo de Servicios

Recomendaciones Administración CMDB

 

 

Fecha:
 

El Checklist de un SLA- Service Level Agreement

Corrección de Estilo: Francisco J Ramírez 

Para redactar un SLA eficiente debe considerar que un Acuerdo de Nivel de Servicio SLA, define la medición del rendimento de un centro de soporte y clarifica las expectativas del usuario y de la mesa de servicio (service desk). Cada integrante del acuerdo debe entender sus responsabilidades y compromisos teniendo en cuenta lo que debe esperar de la otra parte. Un acuerdo de nível de servicio contiene medidas cuantitativas y cualitativas. 

Image001

Un Service Desk podría tener por separado un SLA por cada área de usuarios, un SLA solamente con las áreas críticas o un SLA con todos los usuarios. En la creación de un acuerdo debe tener en cuenta:

  • Considere los reponsables idóneos para dar soporte. El desempeño de cada especialista puede afectar la capacidad para cumplir los objetivos. Establezca un tiempo para definir y acordar el responsable de cada actividad. 
  •  Cada ítem del acuerdo debe ser medible. Si usted no puede medir el ítem, no lo incluya. 
  •  Cada ítem del acuerdo debe ser específico. Por ejemplo, si se requieren reportes de rendimiento, un formato de los informes debe ser incluído, comunicada y definida la frecuencia y los receptores de los reportes. La mayor especificación de cada ítem evita malos entendidos, de expectativas no alcanzadas. 
  •  Todos los involucrados en el acuerdo deben participar en su creación y proceso de negociación. 
  •  El proceso de creación es iterativo. Un SLA borrador es creado por un grupo de trabajo de representantes de los responsables. Cada representante llevará el borrador a sus grupos para realizar modificaciones o aclaraciones. El proceso continúa hasta que todos los grupos estén satisfechos con el resultado.

 

Los ítems que deben ser incluidos en un SLA son los siguientes:

  •  Descripción y ubicación del grupo de usuarios. Se puede necesitar niveles diferentes de servicio para diferentes grupos y por lo tanto diferentes SLA's. 
  •  Período cubierto por el acuerdo. Generalmente un año. 
  •  Alcance que la mesa de servicio deberá proveer. 
  •  Horario de atención de la mesa de servicio y opciones para atención fuera de horario.
  •  Facilidades de acceso de los usuarios a los servicios de la mesa de servicio.
  •  Responsabilidades del usuario.
  •  Prioridad de los llamados y tiempos de respuesta requeridos.
  •  Mediciones de servicio a ser alcanzadas.
  •  Procedimientos de escalamiento.
  •  Reportes a ser generados por la mesa de servicio.
  •  Componentes soportados.
  • Componentes que son considerados críticos.
  • Tarifas de soporte, si estan consideradas en el acuerdo.
  • Pagos por uso de servicio, si fue acordado. En esta sección se incluye cualquier servicio que esté disponible para sus usuarios con un costo extra; ejemplo:entrenamiento.

 

Otros Artículos publicados de su interés:

Cómo Diseñar Catalogo de Servicios

Recomendaciones Administración CMDB

Importancia de la relacion de un CI

 

 

 

Fecha:
 

Cómo Diseñar el Catálogo de Servicios

Corrección de Estilo: Francisco J Ramírez

El diseño de un catálogo de servicios permite garantizar el adecuado funcionamiento de la mesa de servicio manteniendo el concepto de satisfacción del cliente. De acuerdo a la experiencia y con el fin de conceptualizar, se debe concebir un catálogo de servicios como un acuerdo efectivo que permite asegurar el máximo nivel de satisfacción en el proceso de entrega de servicios a un cliente. Consideremos otras definiciones para ampliar el concepto:

"…El Catálogo de Servicios es la piedra angular de la prestación de servicios, y el punto de partida para cualquier empresa interesada en ahorrar dinero y mejorar las relaciones con el negocio..."[1]

“…El catálogo de servicios es un inventario de información con todos los servicios, proporcionando una descripción clara de todos los elementos y servicios de TI. A través del catálogo de servicios, todo el personal cuenta con una vista global de los servicios que se suministran, cómo se entregan y utilizan, con qué fin y en qué nivel de calidad. El proceso es simple, intuitivo y totalmente transparente…”[2]

“…Catálogo de Servicios es un listado de los servicios que brindan las organizaciones o áreas de TI a clientes y/o usuarios, incluyendo un listado de las características de los mismos…”[3]

“…Es una declaración escrita de los servicios de TI. Representa una herramienta de comunicación muy importante pues da una descripción detallada de los servicios (y niveles de servicio) en el lenguaje del cliente…”[4]

Image001
 

Para lograr los objetivos esperados, el proceso de diseño de un catálogo de servicios debe considerar las siguientes fases:

FASE 1. EL PORTAFOLIO. Se debe considerar primero la presentación del Portafolio; esto significa  que TI debe darle a conocer al cliente todo su portafolio para que sea este quien determine los servicios a su medida.                          

FASE 2. SERVICIOS. El cliente selecciona los servicios requeridos, esto permite a TI tener claro el alcance del servicio a prestar.  Luego que el cliente seleccione del portafolio los servicios requeridos se procede a acordar los parámetros para la prestación del servicio.

FASE 3. ACUERDO DE NIVELES DE SERVICIO. Los acuerdos de niveles de servicio, incluyen varios  aspectos  que se acuerdan con el cliente. Los acuerdos de mayor relevancia son:

1.       GRUPOS CLIENTE. En muchas organizaciones existe grupos de usuarios exclusivos a los cuales el servicio de TI es preferencial. Ejemplo de grupos de usuario:: VIP (usuarios críticos para el cumplimiento del core del negocio); ESTANDAR (usuarios que hacen parte de la organización pero no son críticos para el cumplimiento core del negocio), entre otros.

2.       TIEMPOS  DE ATENCIÓN (SLA). Todo servicio puede variar en tiempo de respuesta, por eso es importante que TI acuerde con el cliente tanto el tiempo de atención como el de solución, teniendo en cuenta que la organización tenga Grupos cliente. Ejemplo: Servicio (mantenimiento) SLA (VIP Tiempo de Atención(10) Tiempo de Solución(60)  y ESTANDAR Tiempo de Atención (20) Tiempo de Solución (160))

3.       ESPECIALISTA RESPONSABLE. Cada servicio debe tener un especialista responsable, se recomienda sea el perfil idóneo enfocado con el servicio acordado.

4.       HORARIO ATENCIÓN. Es importante acordar un horario de atención que permita establecer un indicador de gestión con referencia a los tiempos (SLA) acordados.

Al definir con el cliente los acuerdos mencionados, se puede dar inicio a la parametrización en la herramienta que apoya el proceso de mesa de servicios.

                 


[1] GIERA Julia, Vice President and Research Fellow, Forester Research. Fecha de consulta. Junio del 2011.

[2] OVERTI. Catálogo de servicios. Consultado en: www. Overti.es. Fecha de consulta: junio 2011.

[3] SRM (soporte remoto de México). Consultado en: http://www.soporteremoto.com.mx/help_desk/articulo03.htmlFecha de consulta: junio 2011.

[4] OGC. ITIL V3.  Consultado en: http://www.soporteremoto.com.mx.Fecha de consulta: junio 2011.

 

Fecha:
 

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:
 

El Perú aun tiene un largo camino hacia la seguridad corporativa

Lima, Perú, Enero del 2012.- Cuando mencionamos o conversamos acerca de la seguridad corporativa, debemos, necesariamente referirnos a los Sistemas de Gestión de Seguridad de la Información (SGSI). A través de la adopción de un SGSI las compañías mejoran su productividad, competitividad, su capacidad de reducir, mitigar o evitar incidentes al igual como ofrecer garantías a sus empleados, clientes y socios de negocio como elemento referenciador.

Según Andréz Lamouroux, Consultor Especialista en Seguridad de la Información y Gerente de Soluciones de Seguridad de Aranda Software, debemos ser precisos y certeros al momento en que buscamos soluciones globales para cuidar el mayor activo del negocio, como lo es la información corporativa.

“Ante las circunstancias actuales, en donde la información es el valor del negocio y empresas de alcance mundial sufren ataques cibernéticos y podemos ser víctimas del robo de la información,  es imprescindible que las compañías evalúen los riesgos asociados y establezcan las estrategias y controles adecuados que aseguren una permanente protección y salvaguarda de la data” asegura Lamouroux.

 El presente y el futuro del robo cibernético

Muchas entidades locales e internacionales han sabido tomar conciencia de la importancia, no solo de cuidar la data vital de las empresas, sino también de asegurarse el futuro de la misma en un sistema competitivo. Por tal motivo, ya se encuentran actualizando sus sistemas y plataformas para enfrentar mejor los ataques e incidentes relacionados en seguridad de la información.

Actualmente Perú ocupa el quinto puesto en el ranking de ataques de robo cibernético en Latinoamérica detrás de México, Brasil y Colombia.  Según afirma Andréz Lamouroux, el aumento se debe al crecimiento de la población y de la penetración de internet en la región, además de la realidad económica peruana, la cual ha sido lo suficiente estable como para motivar el interés para realizar ataques de fraude y robo cibernético.

Otra realidad de importancia que se puede mejorar para futuros ataques cibernéticos son las soluciones que las entidades bancarias brindan a los usuarios, localmente, el Perú no esta acostumbrado a conocer y explorar todas distintas formas de fraude o de robo de identidad, no estamos aun preparados para afrontar y cuidar nuestra información privada. De igual forma deben invertir en cambiar sus sistemas de seguridad y pasar a plataformas más seguras que permitan implementar múltiples algoritmos en sus sistemas de autenticación.

Las buenas prácticas

La certificación en la norma ISO 9001 es un elemento que hoy en día cualquier compañía u organización no puede obviar si quiere garantizar la calidad en sus productos y/o servicios. En la actualidad, solo el 20% ó 25% de organizaciones que operan en Perú han implementado la norma, en donde el mayor porcentaje lo comprenden organizaciones que reportan sus estados financieros al extranjero.

Actualmente, la Norma Técnica Peruana ISO/IEC 17799 (Código de Buenas Prácticas para la Gestión de la Seguridad de la Información) es de implementación obligatoria en todas las instituciones públicas del Perú desde agosto del 2004,

El pasado 21 de julio del 2011, la Presidencia del Consejo de Ministros del Perú (PCM) mediante la Resolución Ministerial N° 197-2011-PCM, estableció que 50 Organismos e Instituciones Públicas del Perú deberán implementar el Plan de Seguridad de la Información indicado en la norma NTP ISO/IEC 17799 (ahora ISO 27002), antes del 31 de Diciembre del presente año.

Entre los 50 organismos, se listan del Poder Legislativo, Poder Judicial, Organismos Autónomos y Poder Ejecutivo. El especialista Andréz Lamouroux comenta que esta acción no es el único esfuerzo que el gobierno peruano ha evidenciado sobre implementar la norma de seguridad de la información. “En el año 2004, cuando se publica la norma en Perú, establecieron su cumplimiento obligatorio y un plazo de 18 meses para su implementación en todas las entidades del estado, lamentablemente la realidad de estas entidades no les permitió cumplir, variándose en el futuro las normas.”

Mucho camino por recorrer

Cuando las empresas empiezan el cumplimiento de certificarse según la norma, es el momento en que nuevos retos y soluciones son esperados y requeridos, para poder formar parte del estándar básico.

Uno de los cambios más complejos y el que demanda más tiempo, es el cambio cultural entre los colaboradores. Además, un requisito previo necesario para tener éxito involucra la perspectiva de la Junta Directiva y la alta gerencia. Solo después de que sus miembros tomen conciencia de que los activos de información son un factor vital para el éxito de la organización, es que la certificación de un SGSI es apreciada como un asunto serio que merece atención.

“Los ataques informáticos van en aumento, la cifra supera el 50%, lo que significa que de cada cien empresas que hay en el Perú más del 80% son vulnerables a los ataques informáticos; mientras que de los 25 ministerios del Estado, alrededor de 17 son vulnerables” precisa Andréz Lamouroux, Gerente de Soluciones de Seguridad de Aranda Software.

El primer paso es definir e integrar la política de seguridad en la organización. Las empresas deben establecer su propia configuración de privacidad y definir claramente quién tiene derecho a acceder a cada tipo de información, así como quién puede ver los datos confidenciales. En segundo lugar, implementar soluciones específicas de seguridad de datos que aseguren la información sensible en múltiples formas y en todo su ciclo de vida: datos en reposo, datos en movimiento y datos en uso.

Fecha: por Aranda SOFTWARE
 

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:
 

Green IT, La verdadera estrategia corporativa

Elizabeth_morales
Por: Elizabeth Hernandez           

Gerente de Cuenta de Aranda Software Perú

Elizabeth.Hernandez@arandasoft.com          

 

Sobre este escenario, es momento que su empresa reconsidere y evalúe soluciones tecnológicas que le permitan adoptar una estrategia ante esta situación. En la actualidad, el concepto Green IT reúne todas las tendencias encaminadas a definir, propagar e incentivar la eficiencia energética en la tecnología, reduciendo con ello su impacto medioambiental y logrando a la vez un necesario ahorro de costes.

¿Usted conoce el consumo actual de energía de su empresa? Hoy, el aire, el agua y la tierra están en riesgo en muchas partes del universo y su empresa a través de adecuadas políticas   puede ahorrar costos de operación y hacer los consumos de energía eléctrica de una manera más eficiente y responsable.

En estos momentos, la industria, sujeta a un entorno de creciente competencia, ha perseguido el desarrollo de productos y servicios de alta calidad, fiables y con el menor coste inicial posible. Aspectos relacionados con la eficiencia energética de los sistemas no han sido considerados prioritarios, pero el ininterrumpido avance de las redes de trabajo o el aumento de la digitalización de contenidos y de la capacidad de procesamiento, entre otras actividades, han provocado una demanda de infraestructuras y sistemas de información cada vez más potentes y, en consecuencia, una demanda energética cada vez mayor. 

¿Cómo hacerlo y apoyar desde el negocio a las acciones de Responsabilidad Social que hoy el mundo necesita para asegurar un mejor ecosistema tanto en el presente y el futuro? Aquí se le indica algunos ítems que Ud. puede tomar en cuenta y ser partícipe de este gran cambio.

Primero, obtenga un consumo controlado de energía por estación de trabajo. Luego ahorre dinero y energía eléctrica mientras protege el medio ambiente. Tercero maximice la eficiencia energética durante la vida útil del producto. Cuarto obtenga reportes diarios o mensuales de acuerdo a criterios como el consumo de energía, consumo de C02, consumo en dinero y consumo por estado. Por último, implemente políticas y prácticas amigables con el medio ambiente.

Recuerde que estar al día con acciones de Responsabilidad Social Empresarial no es una tendencia sino una estrategia para generar valor para sus clientes. En este sentido, Usted puede administrar la energía de sus recursos de Tecnología de la Información y Comunicaciones (IT) y lograr el menor impacto ambiental.

 

 

 

Fecha: por Aranda SOFTWARE
 

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:
 

Una Apuesta Ganadora al Conocimiento

La Gestión del Conocimiento se utiliza durante todo el Ciclo de Vida del servicio, siendo especialmente importante durante su etapa de transición, puesto que el conocimiento adecuado es uno de los elementos claves del servicio en transición.  La  aplicación de la Gestión del Conocimiento está presente en la formación y transferencia del conocimiento, la propiedad intelectual, la información sobre conformidad y estándares, documentación de errores, soluciones provisionales e información de pruebas. Entonces podemos decir que:

  • Incluye una gran cantidad de información que conforma el conocimiento.
  • Incluye información de la Base de Datos de Gestión de la configuración (CMBD) y del Sistema de Gestión de la Configuración (CMS)
  • Es un concepto amplio que cubre una gran base de conocimiento, por ejemplo, la experiencia del personal.

Image003

El volumen de información y conocimiento que una organización genera, es suficiente para implementar una gestión centralizada de la información y su objetivo principal es mejorar la eficiencia, reduciendo la necesidad de redescubrir el conocimiento. La importancia de la a Gestión del Conocimiento radica en:

·         Mejora la calidad de las decisiones que se adoptan en una organización, y garantiza que los responsables en la toma de decisiones dispongan de información segura y fiable.

·         Garantiza que el personal utilice las herramientas, tanto para registrar como para consultar los datos disponibles.

·         Evalúa la información recogida, velando que esté permanentemente actualizada.

·         Analiza las necesidades de información de ciertos departamentos y coordina la correcta transferencia de conocimiento desde aquellos que tienen la información.

·         No se duplica el trabajo innecesariamente. Si surge un problema que ya se presentó en el pasado, se recuperan con facilidad los detalles de la solución aplicada, ahorrando tiempo y esfuerzo.

·         Aprovecha eficientemente  los recursos existentes.

·         Previene situaciones de desinformación en caso de faltar los responsables de los datos de acceso a una aplicación, de contacto con un cliente, etc.

El manejo adecuado del conocimiento permite tener información centralizada para la mejor toma de decisiones en su organización.

Fecha: