Embed Size (px)
Citation preview
1
Serie Artículos sobre Gestión de IT y Calidad
“INTRODUCCIÓN A ITIL”
Segunda Parte
2
Introducción a ITIL (Segunda Parte)
Autor: Dr. Norberto Figuerola (PMP) Contador Público y Licenciado en Administración (U.B.A.) Master in Project Management (George Washington University) ITIL Consultant e ISO 20000 Auditor __________________________________________________________________
En esta segunda parte del artículo veremos un detalle de los principales grupos de gestión de servicios de ITIL correspondientes a los procesos de “Soporte del Servicio”, reflejados en la parte izquierda del gráfico, junto con el “Service Desk”:
Service Desk
Los objetivos de la función de Service Desk son:
• Proveer un único contacto con los usuarios • Facilitar la restauración de un servicio normal de operaciones con un
impacto mínimo posible hacia los negocios del usuario dentro de un nivel conveniente y respetando las prioridades del negocio
• Mejorar los conocimientos al usuario de los servicios disponibles y de los trabajos prácticos
• Identificar las deficiencias en los usuarios y su entrenamiento que o bien impactaron negativamente en el uso de los servicios, o bien, creando una carga de trabajo innecesaria para los empleados
• Implementar un programa educacional que resuelve las deficiencias identificadas para los usuarios, clientes y empleados del mismo
Las funciones del Service Desk más comunes incluyen:
• Recibir llamadas, primer enlace con el cliente • Grabar y seguir los incidentes y las quejas • Mantener a los clientes informados sobre la demanda y su evolución • Hacer una valoración inicial de la demanda, intentando resolverlas o
remitirlas a otra persona, que puede atenderlas, basado en un nivel de servicio conveniente
Service Level Management
FinancialManagementAvailability
Management
IT Service Continuity
ManagementCapacity
Management
Service
Delivery
Service
Desk
Change Management
ReleaseManagementIncident
Management
Configuration Management
Problem Management
Service
Support
Service Level Management
FinancialManagementAvailability
Management
IT Service Continuity
ManagementCapacity
Management
Service
Delivery
Service
Desk
Change Management
ReleaseManagementIncident
Management
Configuration Management
Problem Management
Service
Support
3
• Monitorear e intensificar los procedimientos relativos a la apropiada SLA (Acuerdo de nivel de servicio)
• Administrar el ciclo de vida de la demanda, incluyendo el cierre y la verificación
• Planear una comunicación y un cambio de niveles de servicio a corto plazo hacia los clientes
• Coordinar los segundos enlaces y apoyo de terceros • Proveer la gestión de información y recomendaciones para el mejoramiento
del servicio • Destacar las necesidades del cliente especialmente en la educación y en el
entrenamiento • Cerrar los incidentes y confirmación con los clientes • Contribuir a la identificación del problema
Proporcionar confirmación a los Clientes y los Usuarios de que su solicitud ha sido aceptada y de su progreso, es uno de los roles más importantes del Service Desk. A pesar de ello, muy pocas organizaciones tienen los recursos de personal para centrarse en esto y mantener esta actividad. El uso de tecnologías, tal como e-mail, asiste con esta tarea. Sin embargo, el reto real es el de crear un vínculo personalizado con los clientes aunque sea por comunicación electrónica. Ya que la Gestión de Servicio de IT está orientada en torno a la entrega de niveles predeterminados de servicio a los usuarios finales, es sensato instalar una organización cuyos directivos fundamentales sean:
• Dar soporte a los usuarios a medida que requieran ayuda para hacer uso de los servicios presentes en el entorno de IT
• Monitorear el entorno de IT para el cumplimiento de estos niveles predeterminados de servicio y escalar las incidencias en la entrega de servicios de la manera adecuada cuando surjan
El Service Desk se ha percibido tradicionalmente como un conjunto de individuos que reciben todas las consultas e incidentes y de quienes, se espera, tengan la destreza técnica adecuada para contestar prácticamente cualquier pregunta o queja. Tal y como se representa en ITIL, esta disciplina de Service Desk ha evolucionado hasta tal punto que puede ser ejecutado con un alto grado de eficacia, conseguido gracias a varios factores:
• La actitud de “servicio” está instalada en la documentación de la disciplina, habilitando a los empleados del Service Desk para centrarse no sólo en “resolver este asunto” sino más en “restaurar inmediatamente el servicio para este usuario”.
• Procesos rigurosos se definen para facilitar las actividades de los empleados del Service Desk.
Estratégicamente, para los Clientes el Service Desk es probablemente la función más importante de una organización. Para muchos, el Service Desk es la única ventana al nivel de servicio y profesionalidad ofrecida por la organización entera o un departamento. Esto hace entrega del más importante componente de servicio de “Satisfacción y Percepción del Cliente”. De modo interno a la función de IT, el Service Desk representa los intereses del cliente al equipo de servicio. Cuando un servicio se ha interrumpido, el objetivo de algunos procesos es restaurar el servicio. El Service Desk es la organización que facilita los otros procesos. Esto significa que el Service Desk es responsable de un evento de servicio de principio a final. Mientras que otras funciones (tal como soporte de segunda y tercera línea) asistirán en la resolución, el Service Desk retiene control “administrativo” de la
4
incidencia. Otro objetivo es ser el Único Punto de Contacto (“SPOC”) entre los Clientes, Usuarios, servicios de IT y organizaciones de soporte externas para todas las necesidades, preguntas, quejas, comentarios y cambios relacionados con IT
• El Service Desk debería soportar las actividades de negocio al entender IT en un contexto de negocio y sugerir mejoras de provisión de servicio.
• El Service Desk genera informes de gestión • El Service Desk se comunicará con los clientes acerca de sus llamadas de
servicio. • El Service Desk promoverá sus ventajas a toda la organización
El Service Desk no está programado con la tarea de encontrar la causa original de una interrupción de servicio; esa responsabilidad cae a la Gestión de Problemas.
Tipos de Service Desk
Centro Telefónico (Call Center) El énfasis de un Centro Telefónico está en manejar grandes volúmenes de transacciones originadas por teléfono. Normalmente, un centro telefónico no reaccionará a esas transacciones sino que sólo las registrará y las referirá a otras partes de la organización. Servicio al cliente (Help Desk) El propósito primario es gestionar, coordinar y resolver Incidencias, lo antes posible y asegurarse de que ninguna solicitud se pierda, olvide o ignore. Los vínculos con la Gestión de Configuración y las herramientas de conocimiento se utilizan generalmente para soportar las tecnologías. El Service Desk normalmente no maneja más que incidencias. Service Desk El Service Desk extiende el campo de servicios permitiendo que se integren procesos de negocio en la infraestructura de Gestión de Servicio. No sólo maneja Incidencias, Problemas y cuestiones, pero también proporciona un nexo común para otras actividades tal como solicitudes de Cambio de los clientes, contratos de mantenimiento, licencias de software, Gestión de Nivel de Servicio, Gestión de Configuración, Gestión de Disponibilidad, Gestión Financiera de los Servicios de IT y Gestión de Continuidad de Servicio de IT. Muchos Call Centers y Help Desks naturalmente evolucionan hasta convertirse en Service Desks para mejorar y extender su servicio global a los Clientes y el negocio. Las tres funciones comparten características comunes: representan el proveedor de servicio al Cliente y al Usuario (interno o externo), operan con el principio de que la satisfacción y percepción del cliente son críticos, dependen de mezclar personas, procesos y tecnología para poder entregar un servicio de negocio. La interacción del Cliente ya no se limita tan solo al contacto telefónico y personal. El servicio puede realzarse enormemente y ser extendido al Cliente, Usuarios y empleados de soporte expandiendo los métodos de registrar, actualizar y consultar las solicitudes. Esto podría ser: utilizando e-mail, fax, lnternet/lntranet para oficinas remotas, etc. Estos métodos son mejor explotados para actividades que no son vitales para el negocio, que incluye el registro de Incidencias o solicitudes no- urgentes, tales como:
� Adquisición de productos • Consultas de aplicación
5
• Solicitudes para traslado, instalaciones, mejoras y actualizaciones de equipamiento
• Solicitudes de insumos El uso de inversión basada en formularios aumenta la integridad de los datos sometidos y asiste con la asignación del especialista de soporte, equipo o departamento más adecuado. La herramienta del Service Desk debería automáticamente proporcionar al Cliente o al Usuario un recibo con un número exclusivo de referencia, que también permite la consulta sobre la marcha del progreso de la solicitud. Proporcionar a los Usuarios y Clientes confirmación de que su solicitud ha sido aceptada y de su progreso, es uno de los roles más importante del Service Desk. Aún así muy pocas organizaciones tienen los recursos de Personal para centrarse y mantener esta actividad. El reto real es crear un vínculo personalizado con los clientes, aunque sea mediante la comunicación electrónica.
Estructuras de Service Desk
Service Desk Local o Distribuído Tradicionalmente, las organizaciones han creado desks de soporte locales para cumplir las necesidades locales del negocio. Si la organización está manteniendo varios desks de soporte local, es importante introducir estándares operacionales. Consideraciones para implementar una estructura de Service Desk Local incluyen:
• Establecer procesos comunes para todas las localidades y, de ser posible, procedimientos comunes
• Hacer que se conozcan y sean disponibles a otros Service Desks, • Asegurar compatibilidad de hardware, software e infraestructura de red • Usar los mismos procesos de escalamiento, y los mismos códigos de
impacto, severidad, prioridad y status en todas las localidades • Usar medidas de informes de gestión común • Usar una base de datos compartida (lógica) comúnmente • De estar disponible, establecer la posibilidad de pasar o escalar solicitudes
entre Service Desks, preferiblemente de forma automática. Service Desk Centralizado El Service Desk Local es práctico pero por sus múltiples localizaciones puede duplicar habilidades y recursos y eso es costoso. Por lo tanto, es bueno establecer un Service Desk central si el tipo de soporte lo permite y si es técnicamente posible. En esta opción, todas las solicitudes de servicio están registradas en una localización física central. Si la organización tiene localizaciones múltiples, tener un servicio de soporte central tiene ventajas mayores para el negocio, incluidos:
• Costos operacionales reducidos • Visión global de gestión consolidada • Uso mejorado de recursos disponibles
Claro que otras partes de los servicios siguen teniendo que ser soportados en cada localización. Por ello, se ven muchas organizaciones con Desks Centrales y Locales combinados. Service Desk Virtual Hasta un punto, la situación física del Service Desk y los servicios asociados son inmateriales, debido a los avances en redes y telecomunicaciones. El” Service Desk Virtual” puede situarse y ser accedido desde cualquier lugar del mundo. Si la organización tiene múltiples localizaciones, un Service Desk de soporte global tiene ventajas mayores para el negocio, incluidas:
6
• Costos operacionales reducidos • El rango para la visión global de gestión consolidada • Uso mejorado de recursos disponibles.
Sin embargo, la restricción operacional primordial del Desk Virtual es la necesidad de la presencia física de un especialista o un ingeniero de reemplazo. Establecer un Service Desk no es fácil. Por lo tanto, aquí hay algunos consejos:
• Establecer que la necesidad del negocio está claramente identificada y entendida. Sin esto, es muy difícil implementar un desk. Necesitamos saber qué tenemos que soportar.
• Asegurarnos que el compromiso, presupuesto y recursos de la dirección están disponibles. Todo tipo de procesos y procedimientos deben ser implementados, las herramientas deben ser despachadas y las responsabilidades cambian. Sin el compromiso de la dirección, esto no se va a realizar.
• Asegurar que la solución propuesta está en línea con la estrategia de soporte de servicio.
• Definir objetivos claros y que se puedan entregar • Empezar de modo sencillo; no intente hacer todo de golpe; adoptar un
enfoque de fases • Involucrar /consultar a los clientes y usuarios finales. Hable con ellos de
expectativas, objetivos y tareas • Venda las ventajas al personal de soporte. Dígales que “un solo punto de
contacto” también les beneficia. Tendrán más tiempo para hacer el trabajo “de verdad”.
• Forme al personal de IT para ser personal de servicio. La comunicación es uno de los factores de éxito más críticos. El Service Desk no debe estar centrado de modo técnico sino orientado al servicio.
• Eduque a los clientes y usuarios en el uso del nuevo servicio y sus beneficios.
• Anuncie y “venda” su servicio. Al montar un Service Desk, tenga en cuenta las siguientes guías:
• De ser posible, tener un local apartado de la zona de soporte principal con: • Un área agradable y confortable para Clientes y Personal del Service
Desk • Un entorno de bajo nivel de ruido • Privacidad
• Instalar una biblioteca de todos sus productos, documentación de hardware y software y material de referencia que utilizan los clientes
• Asegurar un Catálogo de Servicio actualizado disponible a todas horas • Instalar facilidades telefónicas y de conferencia • Proveer espacio de mesas y asientos para discusiones de mesa redonda- • Publicar a la base de Clientes la localización de la unidad y sus horarios
operacionales Al considerar el nivel de servicio y el entorno proporcionados, es bueno preguntarse “¿Es así cómo me gustaría que me trataran?”
7
Gestión de Incidencias Ya que la Gestión de Servicio de IT está orientada en torno a la entrega de niveles predeterminados de servicio a los usuarios finales, es sensato instalar una gestión cuyas directivas sean:
Monitorear el entorno de IT para el cumplimiento de esos niveles de servicio
predeterminados y escalar adecuadamente incidentes en la entrega de
servicio cuando surjan.
La función de la Gestión de Incidencia tiene la responsabilidad de resolver esas incidencias cuánto antes, para habilitar el servicio y si la incidencia es crónica informar a Gestión de Problemas. Incidencia es cualquier evento que no es parte de la operación estándar de un servicio y que puede causar una interrupción o disminución del mismo (incluye peticiones de servicios). La importancia del proceso de Gestión de incidencia se puede resumir como sigue: cuando un usuario experimenta un incidente el proceso de Gestión de Incidencias asegurará que el servicio del usuario estará disponible de nuevo tan pronto como sea posible.
El objetivo principal de la Gestión de Incidencias es:
• Resolver el asunto de servicio tan pronto como sea posible, al menos dentro del tiempo objetivo documentado en el acuerdo de Nivel de Servicio
• Mantener la comunicación viva entre la organización de IT y su cliente sobre el status con relación al asunto de servicio (p.ej. a quien se escaló, tiempo estimado de resolución)
• Evaluar una incidencia para determinar si es probable que vuelva a ocurrir o si es síntoma de un problema crónico. Si lo es, informar a un Director de Problemas al respecto
Actividades de la gestión de incidentes: • Detección y registro del incidente • Clasificación y apoyo inicial • Investigación y diagnóstico • Resolución • Cierre del incidente • Monitoreo, seguimiento y comunicación
Un administrador o encargado de incidentes tiene responsabilidades sobre:
• Llevar la eficiencia y la efectividad de los procesos • Generar el manejo de los informes y métricas • Gestionar el trabajo de los empleados del soporte de incidentes • Monitorear la efectividad del manejo de incidentes y de las recomendaciones
principales para su resolución • Desarrollar y mantener el sistema de gestión de incidentes
Las responsabilidades en primera línea (Service Desk) incluyen:
• El registro de incidentes • Hacer un seguimiento de las demandas para apoyar los grupos cuando
entren incidentes y no están completadas • Soporte inicial y su correspondiente clasificación • Propiedad, monitoreo, seguimiento y comunicación • Resolución y restablecimiento • Pasar os incidentes no asignados al soporte de segunda línea • Cierre de los incidentes
8
Soporte en segunda línea (grupos especiales que no deben estar dentro del grupo del Service Desk) estarán envueltos en las tareas como:
• Tratar el servicio de demandas • Controlar los detalles de los incidentes, incluyendo el punto de configuración
afectado • Investigación de incidentes y diagnostico (incluyendo la resolución si es
posible) • Detectar posibles problemas y el encargo de ellos a la gestión del problema • La resolución y restablecimiento de los incidentes asignados
Terminología
Algo que ocurre y causa una interrupción o disminución de un servicio y que no es parte de la operación común de un servicio acordado se llama una incidencia. En la mayoría de los casos las incidencias están interrumpiendo el servicio, algunas veces sólo está reduciendo el servicio, igualmente se denominan incidencias. En muchos casos la incidencia es reactiva (ya ha interrumpido o reducido el nivel de servicio), en otros podemos ser pro-activos advirtiendo sobre esa incidencia y con suerte lo resolveremos antes de que el cliente lo averigüe.
Un “workaround” es un método de evitar una Incidencia o un Problema desde una solución temporal. Es habitualmente la primera solución que restaura el servicio. No es una solución permanente pero algo que se implementa para hacer que el servicio continúe sin sobresaltos. Redirigir trabajos de impresión a otra impresora en el mismo edificio es un workaround. El usuario puede obtener los solicitado pero tal vez a costa de buscarlo en otro piso.
Una “petición de servicio” podría ser una solicitud de información o una solicitud de cambio relacionado con uno de los servicios que entrega la organización. Es, de hecho, cada llamada que no es una incidencia. Una petición de servicio puede ser la solicitud de un cambio que mientras esté cubierto por un servicio prestado de forma estándar es tramitado por Gestión de Incidentes, pero si el servicio no es estándar y altera el estado de la infraestructura de IT (CI) entonces se inicia los que se denomina una Petición de Cambio (RFC).
Inputs del servicio:
Incidencias del Service Desk
Es obvio, pero el proceso no existe si no se registran las incidencias.
Información de Configuración
La “CMDB” como veremos más adelante es uno de los mayores proveedores de información para este proceso. Las relaciones entre los Cl’s (Ítems de Configuración de la infraestructura de IT), entre los Cl’s y expedientes de incidencias anteriores, errores conocidos, cambios y acuerdos de niveles de Servicio, la historia y más información detallada sobre los Cl’s es crucial para la solución de incidencias.
Respuesta de emparejar incidencias con problemas y Errores Conocidos (KE Known Error)
Si la incidencia puede ser comparada con un problema y/o un error conocido es información valiosa que nos puede ayudar a resolverla más rápidamente.
Detalles de resolución
Los detalles sobre resoluciones anteriores de incidencias- y no sólo los parecidos o los mismos- es de nuevo información valiosa para una rápida restauración del servicio.
9
Respuestas sobre Pedidos de Cambios (RFC) para resolución de incidencias
Feedback de la organización de Gestión de Cambios sobre los resultados del cambio para que podamos revisarlos.
Outputs del servicio:
Pedido de cambios (RFC) para resolución de incidencias
Necesitamos RFC’s para la restauración de servicio que se debe alcanzar mediante cambios. Este proceso los generará.
Incidencias resueltas y cerradas
La solución de incidencias y expedientes cerrados con toda la información necesaria sobre cómo se resolvió es información valiosa para la Gestión de Problemas
Comunicación a los Clientes
El establecimiento de una fluída comunicación durante el ciclo de una incidencia entre el Service Desk y los clientes/usuarios finales es vital.
Información de Gestión (Informes)
Información de Gestión sobre los resultados y rendimiento del proceso.
El Ciclo de vida de la Incidencia
Aceptar el evento de servicio, Registrar y consultar la CMDB
Admisión y registro del incidente (por el usuario, un sistema o el Help Desk). Se debe evitar registrar el mismo incidente dos veces, por tal motivo se verifica si no existen similares ya reportados. De existir, se relacionan. El registro de datos de acuerdo a la interrupción o reducción del servicio es muy importante para:
• Localizar la incidencia a lo largo de la totalidad de su ciclo de vida
• Añadir información útil que puedan ayudar, informar y asistir organizaciones de soporte para que puedan encontrar una solución o un workaround (antes)
• Recoger información histórica para su uso futuro
• Coleccionar información (p.ej. para informes) sobre un número de incidencias, eficiencia, disponibilidad y análisis de tendencias y otros procesos de gestión
Consultar la CMDB es necesario para obtener información sobre el servicio que se interrumpe, los datos de los Acuerdos de Nivel de Servicio, los CI’s relacionados a este servicio, incidencias pasadas, errores conocidos, etc.
Clasificación
El Service Desk determina la prioridad de las incidencias a medida que las recibe.
Consultando con el Cliente, el Service Desk calculará la prioridad a partir del impacto y la urgencia de la incidencia. El impacto se mide en términos de número de usuarios o procesos afectados. La urgencia es la demora aceptable por el usuario o proceso de negocio. La clasificación ayuda a indicar la ruta de solución.
Comparación y escalado
10
Se investiga si hay incidentes similares o trabajos en curso. Se debe contrastar contra la base de datos de incidencias, problemas y errores conocidos. En cuanto al escalado puede ser horizontal o funcional y vertical o jerárquico.
Investigación y Diagnóstico
De acuerdo a como fue derivado el incidente otros grupos de soporte investigarán el mismo y darán su diagnóstico y posible solución.
Resolución y recuperación del servicio
Una vez encontrada la solución esta se aplica de forma permanente, o de no ser esto posible, se implementa un workaround. Para algunas resoluciones se deberá emitir una petición de cambio (RFC).
Cierre
Si se indica una solución permanente o un workaround esto lo implementaremos y restauraremos el servicio. El grupo de solución informará al Personal del Service Desk. El Personal del Service Desk investigará con el cliente si la solución/workaround ofrecidos han restaurado el servicio como se requiere. Si es el caso, entonces el Personal puede cerrar la incidencia.
Seguimiento y Monitoreo
Luego del cierre se deberá seguir el control del incidente para ver si la respuesta es la adecuada y como evoluciona
Clasificación: Prioridad y Categoría
El Service Desk determina la prioridad de las incidencias a medida que las recibe. Consultando con el Cliente, el Service Desk calculará la prioridad a partir del impacto y urgencia de la incidencia, considerada frente al criterio descrito en el Acuerdo de Nivel de Servicio y lo antedicho más arriba.
El criterio típico debería incluir:
• Coste potencial de la no-resolución
• Amenaza de lesión a clientes o empleados
• Implicaciones legales
• Trastorno a clientes y empleados
Al priorizar las llamadas en este punto, el soporte de segunda línea puede determinar fácilmente qué llamadas necesitan atención más urgente y en qué orden. La Prioridad no trata simplemente de poner las incidencias en orden para su resolución; también trata sobre los recursos (tiempo, personal, destreza, investigación y soporte de terceros) que se asignarán a la resolución. En términos prácticos, a veces una incidencia de baja prioridad puede que se permita no alcanzar su tiempo objetivo de resolución, para que una incidencia de más alta prioridad pueda tratarse dentro de su objetivo.
La categorización se hace para agrupar incidencias en una categoría específica. La ventaja más grande es que esto podría ayudar a indicar la ruta de solución que se podría tomar, el grupo de solución que se debería elegir (para referir a la incidencia también) y la posible solución.
Después de la categorización, la incidencia se debe contrastar con la base de datos de incidencias, problemas y errores conocidos para investigar si se informaron
11
incidencias con los mismos síntomas antes y averiguar si existen problemas y/o errores conocidos. Si existen, lo más probable es que haya un workaround que podamos utilizar para restaurar el servicio.
Si la incidencia no se puede relacionar entonces es una incidencia única. La solución lo más probable es que no pueda encontrarse en el Service Desk y por lo tanto, tenemos que referirlo al siguiente nivel de soporte.
A menudo, nos referimos a los departamentos y grupos de soporte (especialistas) además Service Desk como grupos de soporte de segunda o tercera línea, teniendo más habilidades, conocimientos, especialistas, tiempo u otros recursos para resolver incidencias. A este respecto, el Service Desk sería soporte de primera línea. El procedimiento tradicional seria:
Paso 1. Intento de resolución de la incidencia por parte del Service Desk: Llevar a cabo la evaluación inicial y buscar una solución o workaround. Si se encuentra una solución, cerrar la incidencia. Si no, referirlo al siguiente nivel.
Paso 2. Asignar la Llamada de Servicio al soporte de 2 línea o administración de soporte. Si el soporte de 2 línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará la incidencia. Si no, referirlo al siguiente nivel.
Paso 3. Asignar la Llamada de Servicio al soporte de 3 línea (desarrolladores y especialistas). Si el soporte de 3 línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará la incidencia. Si no, referirlo al siguiente nivel.
Paso 4. Asignar la Llamada de Servicio al especialista o proveedor externo necesario. Si el especialista o proveedor puede encontrar una solución, referir de vuelta al Service Desk que cerrará la incidencia.
Si no está claro qué grupo de soporte debería investigar o resolver una incidencia relacionada con un usuario, el Service Desk, como dueño de todas las incidencias, debería coordinar el proceso de Gestión de Incidencias. Si hay diferencias de opinión o surgen otros asuntos, entonces el Service Desk debería escalar la incidencia al equipo de Gestión de Problemas.
Escalada y Referencia
Si necesitamos más soporte de la dirección, más dinero y más poder (decisiones) para resolver una incidencia, es necesaria la escalada “vertical o jerárquica”.
Si necesitamos involucrar más gente para resolver el incidente, más departamentos, más conocimiento se denomina escalada “horizontal o funcional”.
Debería haber un procedimiento para ambas escaladas. Y es muy importante que el personal del Service Desk monitorice el progreso de la misma.
La Escalada o Referencia nunca convierte una incidencia en un problema, aunque pueda resultar en que la propiedad de una incidencia pase al Director de Problemas por razones administrativas. Informar es muy importante. La Mejora de Calidad está basada fundamentalmente en Información. Sin registro de alta calidad e informes flexibles no tenemos la información que necesitamos.
Informes sugeridos
� Revisiones diarias de Incidencias individuales y status de Problemas con referencia a niveles de Servicio
� Revisiones de gestión semanales o Revisiones de gestión mensuales � Informes de servicio pro-activos
12
Gestión de Problemas La Gestión de Problemas tiene como objetivo manejar todo tipo de servicios de IT fallidos. Su objetivo principal es identificar las causas raíz de aquellas fallas y recomendar cambios en los Items de Configuración (CI’s) a Gestión de Cambios. La Gestión de Problemas brinda soporte a Gestión de Incidencias suministrando soluciones temporales y reparaciones rápidas (quick fixed), pero no resuelve incidentes, dado que su función es tomarse el tiempo necesario para investigar la causa raiz de los problemas.
El primer objetivo de Gestión de Problemas es minimizar el impacto adverso de Incidencias y Problemas en el negocio causados por errores inherentes a la infraestructura de IT. El segundo es prevenir la recurrencia de Incidencias relacionadas con estos errores. A fin de alcanzar este objetivo, Gestión de Problemas busca llegar a la causa raíz de las Incidencias y entonces iniciar acciones para mejorar o corregir la situación. Parte de la responsabilidad de Gestión de Problemas es asegurar que la información previa está documentada de tal manera que está disponible para el Personal de primera línea y otros de segunda línea.
El proceso de Gestión de Problemas tiene aspectos tanto proactivos como reactivos. El aspecto reactivo se ocupa con resolver Problemas en respuesta a una o más Incidencias. Gestión de Problemas Proactiva se ocupa de identificar y resolver Problemas y Errores Conocidos antes de que las Incidencias ocurran en primer lugar.
Las actividades de Gestión de Problemas son:
• Control de Problemas: Esta función realizará análisis de tendencias; registrará problemas y realizará análisis de causas raíz para aquellos problemas a fin de encontrar una solución permanente y que se conviertan en un error conocido.
• Control de Errores Conocidos: Controla los errores conocidos, genera RFCs a Gestión de Cambios para eliminar los errores conocidos de la infraestructura. Mantiene las bases de datos de conocimiento y errores conocidos/workaround. Publica los errores conocidos para que el Proceso de Incidencias pueda resolver antes incidencias e investigará si problemas y/o errores conocidos también están presentes o no en otras partes de la infraestructura.
• Prevención Pro-activa: Previene la introducción de nuevas incidencias y problemas
• Identificar Tendencias: Esta función monitorea activamente las incidencias y con el uso de métodos estadísticos intenta identificar tendencias para que se puedan reconocer problemas. Las tendencias por sí solas habitualmente no son suficiente para identificar un problema, el conocimiento humano es necesario para determinar si la tendencia lleva a un problema.
• Información de Gestión: Crea informes sobre la efectividad y el rendimiento de la Gestión de Problemas y proporciona esta información a Dirección y otros procesos.
• Revisión de Post Implementación (PIR): Gestión de Problemas archiva las solicitudes de Cambios. Sólo después de implementar un cambio, puede uno tomar la determinación de si el cambio de hecho hizo lo que esperaba La Revisión de Post Implemento (PIR) comprueba si se da el caso.
El encargado del problema tiene las siguientes responsabilidades:
13
• Desarrollar y mantener el proceso de control de problemas • Revisar la eficiencia y la efectividad del proceso de control de problemas • Informes y métricas de la Gestión de Producción • Asignación de los recursos dependiendo del esfuerzo del soporte • Monitorear la efectividad del control de errores y conseguir las
recomendaciones para mejorarla • Identificar los problemas (analizando los datos del incidente, por ejemplo ) • Investigar los problemas, según el impacto, a través de la resolución o la
identificación del error • Solicitar los RFC’s para despejar los errores • Monitorear los procesos en la resolución de errores conocidos • Avisar al personal de gestión de incidentes de la mejor solución alternativa
disponible para los incidentes relacionados con los problemas no resueltos o errores conocidos
• Asistir con el manejo de los mayores incidentes e identificando la causa • Identificar las tendencias y la principal fuente de problemas (revisando los
incidentes y analizando los problemas) • Solicitar los RFC’s para prevenir que surja de nuevo los problemas • Prevenir la réplica de los problemas a través de sistemas múltiples
Inputs del Servicio
lnputs a Gestión de problemas son cualquier cosa que podría ayudar a determinar problemas. Los más importantes son:
Detalles de Incidencias
Toda la información disponible sobre Incidencias se debe pasar a Gestión de Problemas para investigación y análisis de tendencias.
Detalles de configuración
Como en la Gestión de Incidencias, la CMDB es una de los mayores “proveedores” de información de este proceso. Las relaciones entre los CI’s mismos pero también entre los Cl’s y expedientes de CI’s anteriores, errores conocidos, cambios y SLA, historia e información más detallada sobre los CI’s es información crucial para la resolución de incidencias
Workarounds definidos
Todos los workarounds definidos son necesarios para determinar si hay incidencias que por su mero número podrían ser definidos como problema. La correlación entre incidencias y workarounds sólo es posible si se conocen los workarounds.
Outputs del servicio
El proceso de Gestión de Problemas conoce varios outputs, todos dirigidos a eliminar o reducir los efectos de incidencias. Los más importantes son:
Errores Conocidos
Para que los usuarios (vía el Service Desk) sepan que algo se está investigando
Solicitudes de Cambios
Para que los usuarios (vía el Service Desk) sepan que una solución se implementará pronto
14
Expedientes de Problemas actualizados incluidos workarounds y soluciones
Para que el Personal de soporte pueda resolver incidencias en forma previa
Respuesta a gestión de Incidencias a partir de emparejamiento
Para ayudar el proceso de gestión de incidencias a reducir su tiempo de resolución de incidencias
Información de Gestión
Para informar a dirección si los outputs anteriores cumplen su objetivo.
Control de Problemas - Pasos
1 - Identificación y Registro
Las formas de identificar un problema son:
• Si hubo una incidencia con considerable impacto que hemos solucionado lo más probable es que el Director de Problemas registrará un problema enseguida porque una investigación para averiguar la causa raíz de un problema es muy importante
• Durante el análisis de tendencias podríamos encontrar un número de incidencias con síntomas similares
• Si descubrimos una fuente de potenciales problemas
• Si una incidencia se cierra con el código “workaround”
• Si un problema se envía a otro dominio
2 - Clasificación
. El paso de clasificación recoge datos acerca de
• Qué CI’s están involucrados; • Cuáles son las incidencias relacionadas; • Cuáles son los síntomas; • Cuáles son las causas; • Cuáles son las resoluciones/ workaround; • Cuáles son los cambios relacionados a este CI; • Qué niveles de servicio están relacionados • Cuál es el peligro • Qué clientes están implicados • Cuánto tiempo necesitamos (esperamos) para encontrar una solución (tanto
de duración como de esfuerzo) • Con cuánta urgencia necesitamos resolver el problema • Cómo de alto es el posible beneficio positivo si solucionamos el problema
(impacto) • Basado en esta información se asigna Impacto y Urgencia (=prioridad).
3 - Asignar Recursos
Después de la clasificación, podemos priorizar los problemas. Basado en el número de recursos que tenemos, ahora podemos asignar o reasignar problemas a los recursos disponibles. Al hacerlo de esta manera nos aseguramos de los problemas más importantes con el impacto de negocio más alto.
4 - Investigación y diagnóstico
El objetivo de la investigación y diagnóstico es detectar la causa subyacente de una o más incidencias. Las actividades de investigación deberían incluir los Workarounds disponibles para las Incidencias relacionadas con el Problema, como
15
registradas en la base de datos de expedientes de Incidencias, también como expedientes exactos de Cambios recientes, porque pueden proporcionar orientación a la causa. Información histórica de Cl’s (de la CMDB) podría ser útil también como hechos, descripciones y soluciones de datos de incidencias
5 - Establecer un Error Conocido
Después de la fase anterior, se determinará el error conocido. Esta fase registra que un error es conocido, se identifica la causa raíz del problema, se identifican los CI intervinientes y pasa el error al proceso de Control de Errores.
Control de Errores - Pasos
El control de errores conocidos es responsable del registro, monitorización y manejo de todos los errores conocidos desde el principio (la identificación) hasta el cierre después de haber implementado con éxito el cambio que ha eliminado la causa de raíz.
1 - Identificación de error y registro
Un error se identifica cuando se detecta un CI roto. Un estatus de Error Conocido se asigna cuando se encuentra la causa raíz de un Problema
2 - Evaluación del Error
Este paso realiza una evaluación inicial de los medios de resolver el error, en colaboración con personal especialista. El proceso de resolución para cada Error Conocido debe ser grabado en el sistema de Gestión de Problemas. Es vital que los datos de los CI’s, síntomas y acciones de resolución o workaround relacionados con todos los Errores Conocidos se registren en la base de datos de Errores Conocidos porque entonces está disponible para emparejamiento de Incidencias, proporcionando una guía para futuras investigaciones y para proporcionar información de gestión.
3 - Registro del Error / Resolución (envío de RFC)
El paso registra una resolución de un error y completa una RFC de acuerdo con los procedimientos de Gestión de Cambio. La prioridad de la RFC se determina por la urgencia e impacto del error en el negocio. El identificador de la RFC debería incluirse en el registro del Error Conocido y viceversa a fin de mantener un rastro de auditoria completo, o se debe ligar los dos registros. Las etapas finales de la resolución de error- análisis de impacto, evaluación detallada de la acción de resolución a llevar a cabo, modificación del artículo en error, y la prueba del Cambio- están bajo el control de Gestión de Cambio.
4 - Cierre de Error
Tras implementar con éxito los Cambios (determinado por la Revisión Post Implemento) para resolver errores, el Error Conocido relevante se cierra, junto a los expedientes de Incidencias o Problemas relacionados.
Gestión de Problemas Proactiva - Pasos
La Gestión de Problemas Proactiva cubre las actividades dirigidas a identificar y resolver Problemas antes de que ocurran Incidencias. Estas actividades son:
• Análisis de tendencias
• Marcar objetivos de acción de soporte
• Proporcionar información a la organización.
16
Las actividades de Gestión de Problema pro-activa tratan de identificar y resolver Problemas y Errores Conocidos antes de que ocurran Incidencias, dicho de otro modo minimizando-el impacto adverso en el servicio y los costes relacionados con el negocio. La prevención de problemas llega desde la prevención de Problemas individuales hasta decisiones estratégicas. Las últimas puede que requieran mayor gasto de implementar tal como una inversión en una mejor red de conexión.
Las actividades principales dentro de los procesos de Gestión de Problemas pro-activa son análisis de tendencias y el marcar objetivos de acción preventiva. El análisis de tendencias puede llevar a la identificación de fallos en la infraestructura de IT, los cuales pueden ser entonces analizados y corregidos tal y como se describe en las secciones de Control de Errores y Problemas. El análisis de tendencias también puede llevar a la identificación de áreas de Problemas generales que necesitan más atención de soporte. Debería ser posible hacer comparaciones significativas al expresar esto en términos de coste financiero a la organización.
Los informes de análisis de Problemas e Incidencias proporcionan información de medidas pro-activas para mejorar la calidad de servicio. El objetivo es identificar los componentes ‘frágiles” de la infraestructura de IT e investigar las razones para la fragilidad- en este contexto la ‘fragilidad” es proporcional al impacto al negocio si falla el CI.
Incidencias versus Problemas
Incidencias y Problemas (y Cambios) son entidades separadas. Las incidencias, problemas e incluso cambios estarán vivas simultáneamente. Si en algún momento durante la fase de diagnóstico se encuentra un workaround la incidencia se resuelve, pero no significa que el problema dejó de existir (sólo cambiaría la urgencia dado que sería más baja)
Comienzo: Sólo una incidencia.
Cuando ocurre una incidencia, el proceso de gestión de incidencia intentará resolver la incidencia cuanto antes. La incidencia sólo se puede cerrar una vez resuelta la incidencia. Durante la fase de investigación de la incidencia, no se encuentra ninguna solución. El proceso de gestión de incidencias entonces busca la ayuda de gestión de problemas porque la causa raíz de las incidencias se tiene que determinar en primer lugar.
Investigado y Escalada: Incidencia y Problema existen simultáneamente.
La gestión de problemas define un problema con alta urgencia e inmediatamente asigna recursos. Esos recursos diagnostican el problema y encuentran la causa raíz de la incidencia subyacente.
Diagnóstico: Incidencia, Problema y Error Conocido existen simultáneamente.
Definen un error conocido y tras averiguar cómo resolverlo emiten una RFC a gestión de cambio para resolver la situación.
Cambio en trámite: Incidencia, Problema, Error Conocido y Cambio existen simultáneamente
El cambio se implementa con éxito. La Revisión Post implementación muestra que el cambio de hecho ha eliminado el error conocido con éxito. La investigación muestra también que la incidencia se ha resuelto y el problema, por lo tanto, abierto por esta razón ahora se puede cerrar también.
Final: Incidencia resuelta, cambio, problema y error conocido cerrados
17
Si en algún momento durante la fase de diagnóstico el equipo de problemas encuentra un workaround, la incidencia se resolverá antes. Esto no significa que el problema ya no exista. El único cambio en el expediente del problema será que la urgencia caerá de urgente a no urgente. El proceso de problemas decidirá si hay recursos suficientes libres en ese momento en el tiempo para perseguir el diagnóstico del problema o si esos recursos fuesen mejor utilizados en otro lugar.
Procesando Errores Conocidos desde el Entorno de Desarrollo
La segunda fuente de Errores Conocidos surge de la actividad del desarrollo. Por ejemplo, la implementación de una nueva aplicación o Difusión empaquetada es probable que incluya errores conocidos, pero sin resolver, de la fase de desarrollo. Los datos relacionados con Errores Conocidos del desarrollo necesitan estar a disposición del Service Desk del entorno vivo cuando una aplicación o un paquete de Difusión se implementan.
Informes de Gestión
La información de gestión debería proporcionar una vista interna del esfuerzo y recursos gastados por la organización en investigar, diagnosticar y resolver Problemas y Errores Conocidos. Además de esto, es importante proporcionar una percepción del progreso hecho y los resultados obtenidos como resultado. Las medidas se tiene que seleccionar con cuidado. Sólo mediante medidas cuidadosas y significativas puede la dirección formar una opinión de la calidad de un proceso.
Algunas medidas sugeridas son:
• Los números de RFCs surgidos y el impacto de esas RFCs en la disponibilidad y fiabilidad de los servicios cubiertos
• La cantidad de tiempo trabajado en investigaciones y diagnósticos por unidad organizacional o de proveedor, dividido por tipos de problema
• El número e impacto de incidencias que ocurren antes de que se cierre el problema de raíz o se confirme un error conocido
• La proporción de esfuerzo de soporte inmediato (reactivo) frente a esfuerzo de soporte programado en gestión de problemas
• Los planes de resolución de problemas abiertos con relación a los recursos: • Personas • Otros recursos utilizados • Costos (contra presupuesto)
18
Gestión de Cambios IT se está volviendo cada vez más crítico en operaciones de negocio. La velocidad de cambio de condiciones de negocio aumenta. La velocidad de cambio de tecnologías aumenta. Los Usuarios exigen mayores niveles de servicio para alcanzar los objetivos de los roles que sirven en el negocio. Todos estos factores exigen un entorno de IT en el que el cambio se gestiona y controla de manera cercana.
La experiencia sugiere que un alto porcentaje de problemas relacionados con la calidad de servicio de IT se puede rastrear hasta algún cambio que se hizo en el sistema.
El primer objetivo del proceso de Gestión de Cambio es asegurar que se utilizan procedimientos y métodos estandarizados para el manejo eficiente y puntual de todos los cambios, a fin de minimizar el impacto de los cambios sobre la calidad de servicio y la continuidad del negocio. Este enfoque es esencial para mantener un equilibrio apropiado entre la necesidad de cambio frente al impacto de cambio. Es particularmente importante que los procesos de Gestión de Cambio tengan alta visibilidad y canales de comunicación abiertos a fin de promover transiciones suaves cuando un cambio tiene lugar.
Dentro de la declaración de misión, la frase “cambios aprobados” es muy fuerte y rígida. Esto casi insinúa inflexibilidad, aunque una política de Gestión de cambio bien documentada y rigurosa responderá por los pequeños cambios diarios y los cambios necesarios para restaurar inmediatamente un servicio crítico o uno que impacta a un gran número de clientes. Por ejemplo, para que un usuario cambie su clave de acceso, una Solicitud de Cambio completa y una reunión de seguimiento de la Junta de Asesoramiento de Cambio para aprobación sería poco razonable. Además, un cambio necesitado inmediatamente para restaurar un servicio crítico debería seguir un camino de proceso distinto de los cambios normales.
Para algunos, la idea de implementar una serie amplia de procesos de Gestión de Cambio a lo largo de funciones, con documentación formal, reuniones, y aprobaciones parece añadir burocracia y que el Proceso de Gestión de Cambio “atará” las manos de aquellos que necesitan hacer los cambios para mantener en pie el entorno de IT. En realidad, una serie de procesos de Gestión de Cambio (y Gestión de Configuración) adecuada debería reducir la necesidad de cambios “ad hoc” que se puedan encontrar en entornos con pocas o ninguna política de gestión de Cambio o Configuración. Para aquellos cambios que sí hacen falta, un proceso de Gestión de Cambio o Configuración bien diseñado debería procesar y aprobar cambios de manera diligente. Estos cambios aprobados llevan el respaldo de la dirección de IT y se han filtrado tanto el nivel de riesgo, costos e impacto en la organización.
Gestionar cambios se ha convertido en una ocupación de tiempo completo. Si los cambios se pueden manejar para optimizar la exposición al riesgo, la severidad del impacto y trastorno, y claro está, tener éxito al primer intento, el fin para el negocio es llevar a cabo cuanto antes este proceso.
Los Cambios surgen como resultado de Problemas, pero muchos Cambios se producen por la búsqueda anticipada de beneficios empresariales tales como reducción de costos o mejora de servicios. El objetivo del proceso de Gestión de Cambios es asegurar que los métodos y procedimientos estandarizados sean usados para un manejo eficiente y rápido de todos los Cambios, para minimizar el impacto de los Incidentes relacionados con los Cambios en la calidad del servicio, y como consecuencia la mejora de las operaciones cotidianas de la organización.
19
Es particularmente importante que el proceso de la Gestión de Cambios tenga una alta visibilidad y canales de comunicación abiertos para fomentar transiciones suaves cuando los Cambios tengan lugar. La Gestión de Cambios es responsable de la gestión de los procesos de Cambio, implicando:
• Hardware • Equipamiento de las comunicaciones y software • Software de sistemas • Software de aplicaciones “vivas” • Toda documentación y procedimientos asociados a la ejecución, soporte y
mantenimiento de sistemas vivos. Esto significa que los cambios de cualquier componente que estén bajo el control de un Proyecto de desarrollo de aplicaciones (por ejemplo, software de aplicaciones, documentación y procedimientos) no son objeto de la Gestión de Cambios, sino que estaría sometido a los procedimientos de proyecto de Gestión de Cambios de administración del Proyecto. El equipo de Gestión de Cambios se supone, sin embargo, que se comunica estrechamente con el responsable del proyecto de desarrollo de la Aplicación (Project Manager) para asegurar una implementación fluida y lógica dentro de los entornos variables de gestión. Mientras la Gestión de Cambios es responsable de dirigir el proceso, la autoridad de decisión es el Consejo Asesor de Cambios (CAB), el cual es llevado a cabo por la mayor parte de la gente de otros departamentos dentro de la organización. Gestión de Cambios es responsable de dirigir el Proceso de Cambios. Este proceso no está al cargo de implementar cambios, sólo controlará que se aprueben cambios y que se implementen de forma eficiente, de forma efectiva en lo que se refiere a coste y con un mínimo riesgo para los servicios nuevos y existentes. A fin de hacer esto de modo correcto, necesitamos un proceso. Pero también procedimientos y guías muy detallados de cómo hacer distintas cosas en el proceso. Para evaluar el riesgo de cada cambio es muy importante que tengamos una idea de la configuración que controlamos. Por eso, necesitamos Gestión de Configuración, que es la responsable de garantizar que la información relativa a las posibles implicaciones de un Cambio propuesto esté disponible, y que los posibles impactos sean detectados y presentados apropiadamente. Habrá ocasiones en las que una infraestructura de Cambios propuesta tendrá, potencialmente, un impacto más amplio sobre otras partes de la organización (por ejemplo proyectos de desarrollo de aplicaciones u operaciones de empresa), o viceversa. Para mitigar posibles impactos negativos desde cualquier dirección, es imperativo que la infraestructura y otros sistemas de Gestión de Cambios sean enlazados apropiadamente.
Terminología
Cambio: Añadir, modificar o eliminar hardware, software, aplicación, entorno, sistema, documentación asociada, etc.
RFC (Solicitud de Cambio): Formulario, o pantalla, usado para grabar los detalles de una solicitud de cambio a cualquier CI dentro de una infraestructura o a procedimientos asociados con la infraestructura.
Programa Adelantado de Cambios (FSC): Programa que contiene los detalles de todos los Cambios aprobados para implementar y sus fechas propuestas de implementación.
20
Comité de Aprobación de Cambios (CAB): cuerpo de consulta que se reune a menudo en forma formal o informal para la aprobación de los cambios. Cuando surgen problemas mayores es necesario una junta más pequeña para tomar decisiones de urgencia y se denomina CAB/EC (comité de urgencia)
Inputs al servicio
� RFCs : solicitud de cambios a ítems de la configuración de la infraestructura (cambios a CI) o a procedimientos o artículos relacionados con IT.
• CMDB: información sobre que ítems son los que cambiarán o se verán afectados por el cambio
• FSC: programa de cambios aprobados para implementar a largo plazo (fechas propuestas y planificadas de cambios)
Outputs del servicio Las salidas del proceso serán:
• FSC • RFCs • Actas y acciones de CAB • Informes de Gestión de Cambios.
Los deberes del Responsable de Cambios, algunos de los cuales pueden ser delegados, se listan a continuación:
• Recibir, registrar y asignar una prioridad, en colaboración con el iniciador, de todas las RFCs. Rechazar cualquier RFC que no sean completamente prácticas.
• Presentar todas las RFCs para una reunión CAB, publicar una agenda, y hacer circular por adelantado de RFCs de reuniones a miembros CAB para permitir consideraciones previas.
• Decidir qué personas irán a qué reuniones, las cuales tienen RFCs específicas dependiendo de la naturaleza la RFC, que va a ser cambiada, y del área de conocimiento de la gente.
• Convocar CAB urgentes o reuniones CAB/EC para todas las RFCs urgentes. • Presidir todas las reuniones CAB y CAB/EC. • Después de la consideración del consejo dado por CAB o CAB/EC, autorizar
cambios aceptables. • Publicar FSCs, via Service Desk • Comunicar con todos los grupos para coordinar la construcción de Cambios,
prueba e implementación, de acuerdo con los programas. • Actualizar el registro de Cambios con todos los avances que ocurran,
incluyendo cualquier acción para corregir problemas y/o aprovechar para mejorar la calidad del servicio.
• Revisar todos los cambios implementados para asegurar que hayan conseguido los objetivos completamente. Remitir de vuelta cualquiera que haya sido vuelto atrás o haya fallado.
• Revisar todas las RFCs destacadas en espera de acción. • Analizar los registros de Cambios para determinar cualquier tendencia o
problema aparente que ocurra. Buscar rectificaciones con los grupos relevantes.
• Cerrar RFCs. • Producir informes regulares y exactos de gestión.
Responsabilidades del Consejo Asesor de Cambios (CAB)
21
• Revisar todas las RFCs presentadas. Según sea apropiado, determinar y proporcionar detalles del impacto probable, la implementación de recursos, y los costos en curso de todos los Cambios.
• Asistir a todos las reuniones relevantes de CAB o CAB/EC. Considerar todos los Cambios en la agenda y dar una opinión sobre los Cambios en los que debería darse autorización. Participar en la programación de todos los Cambios.
• Estar disponible para ser consultado en caso de que se requiera algún Cambio urgente.
• Aconsejar a Gestión de Cambios respecto a los Cambios urgentes propuestos.
Una función central para la gestión de cambio, configuración y difusión hará posible en algunas organizaciones una implementación del control más eficiente y efectiva. Esta función es la responsable de gestionar cambios en el hardware, software, y todos los elementos de la documentación que son relevantes en el funcionamiento, soporte y mantenimiento de los sistemas que están operativos. Las responsabilidades principales de la función central de gestión de Cambio, Configuración y Difusión son:
• Producir y mantener el plan de configuración y gestión de cambios, diseño de gestión de configuración y política de actualización para la empresa.
• Implementar un cambio consistente, la gestión de configuración y gestión de la difusión en la empresa.
• Identificar los CI que necesitan ser gestionados y controlados. • Integrar la función central con interfaces para otros directores de servicio,
de proyectos, proveedores y clientes. • Asegurarse de que el CMDB y el DSL reflejan el estado autorizado de la
infraestructura de IT y de servicios. • Mantener y controlar los estándares de hardware, estándares técnicos y
copias originales de los documentos. • Proporcionar servicios de soporte, incluyendo registro y comprobación de las
versiones de terceras partes. • Distribuir informes e información de gestión de los CI (por ejemplo la
extensión de qué problemas y errores están afectando a qué CI; y sus fechas límite, fechas y costos de renovación de licencias)
• Asegurar que el sistema de gestión de configuración está informado y será capaz de copiar en el futuro grandes volúmenes de trabajo y su expansión (por ejemplo que el personal adecuado esté presente para la gestión de la configuración)
• Asegurar que todo el personal esté familiarizado con el funcionamiento de la gestión de configuración, la gestión del cambio y las políticas de distribución de software, procesos y sistemas para su trabajo.
• Organizar revisiones regulares del estado del CBDM y del DSL respecto a los sistemas instalados; planear las auditorias de configuración y las de procesos; controlar las excepciones e implementar acciones correctivas.
• Hacer recomendaciones de estrategia, política y diseño de sistemas, incluyendo cómo manejar las configuraciones alternativas y la complejidad de la infraestructura.
• Investigar los problemas principales causados por un control pobre, e identificar acciones de recuperación.
• Proporcionar consejo y guía para los estándares de la infraestructura. • Proporcionar consejo de dónde deben estar situados los componentes de
difusión en la infraestructura. • Comunicar e informar de los proyectos en los que está incluida la gestión de
la configuración y preparar planificaciones que aseguren una transferencia de éxito hacia el servicio final.
22
Actividades del proceso de Gestión de Cambio
1. Solicitud de Cambio
Una RFC es el comienzo de un ciclo de la vida de un cambio.
2. Registro y Clasificación
Recoger la información necesaria para tomar decisiones sobre qué se ha de cambiar, la categoría y el impacto para que la autorización se pueda hacer correctamente. Se asigna una prioridad y categoría que se basa en el impacto del cambio. Evaluación de riesgo es de una importancia crucial en este momento.
3. Monitorear y Programar
Bajo responsabilidad de la Gestión de Cambios todos los cambios se programarán y un plan (con hitos) será proporcionado si es necesario para el control óptimo de (el / los) cambio(s).
4. Aprobar
Decidir si el cambio se va a manejar o no
5. Construir y Probar
Las RFC’s autorizadas deberían ser pasadas a los grupos técnicos relevantes para la construcción de Cambios. La Gestión de Cambios tiene un rol de coordinación, apoyado por Gestión de Difusión y la dirección de línea normal, para asegurar tanto que las actividades tengan recursos, como que se completen de acuerdo con el programa. Para prevenir que los cambios impacten de manera seria la calidad de servicio, se recomienda seriamente que los Cambios se prueben rigurosamente por adelantado (incluidos procedimientos de retroceso o fall-back de ser posible).
6. Autorizar Implementación
Después de una prueba adecuada y comprobación de que toda la acción necesaria se ha llevado a cabo, se puede autorizar la difusión del cambio.
7. Implementación
La Gestión de Cambio tiene la responsabilidad de asegurar que los cambios se implementen según programa, aunque esto será en gran medida un rol de coordinación ya que la implementación será la responsabilidad de otros (p.ej. ingenieros llevando a cabo cambios de hardware).
8. Evaluar
La Gestión de Cambio debe evaluar todos los cambios implementados después de haber transcurrido un periodo predefinido. Esto se puede hacer con la Revisión de Post Implementación. Este proceso puede todavía involucrar miembros del CAB; La Gestión de Cambios solicita ayuda en esta parte del proceso. La Gestión de Cambios debería también evaluar y realizar acciones de seguimiento para corregir cualquier problema o ineficiencias surgidas en el sistema de Gestión de Cambios mismo como resultado de cambios no efectivos.
Solicitud de Cambio (RFC) - Alcance
Las solicitudes de cambio se inician por una amplia variedad de razones, desde una amplia variedad de fuentes. Es el comienzo del ciclo vivo del cambio. Las RFCs pueden tratar de cualquier parte de la infraestructura o con cualquier servicio o actividad. Las RFCs pueden ser solicitadas por medio de planillas, en forma
23
electrónica, o a través de la intranet de la compañía. Todas las RFCs se deberían registrar y tener un número de identificación.
Los siguientes puntos se deberían incluir en el formulario de la RFC, cualquiera sea su formato:
• El número de RFC (más la contra referencia al número de informe de Problema, de ser necesario)
• Descripción e identidad de(l ¡los) artículo(s) a cambiar (incluidos las identificaciones de los CI’s si el sistema de Gestión de Configuración está en uso)
• Razón para el Cambio • Efecto de no implementar el Cambio • Versión del artículo a ser cambiado • Nombre, localización y número de teléfono de la persona que propone el
Cambio • Fecha en la que se propuso el Cambio • Prioridad del Cambio • Evaluación del impacto y recursos (que pueden estar en formularios
separados de ser necesario) • Recomendaciones del CAB en caso de ser apropiado (que se pueden tener
por separado, con impactos y recursos donde sea conveniente) • Firma de autorización (podría ser electrónica) • Fecha y hora de autorización • Implementación programada (identificación y/o fecha y hora de Difusión) • Localización del plan de Difusión ¡Implementación • Detalles del constructor ¡responsable de implementar el Cambio • Plan de retroceso • Fecha y hora de la implementación real • Fecha de revisión • Resultados de la revisión (incluida la contra referencia a la nueva RFC de ser
necesario) • Gestión y evaluación de riesgo • Impacto en la continuidad del negocio y planes de contingencia • Estatus de la RFC, “registrada”, “evaluada”, ‘rechazada”, ‘aceptada”,
“dormida” A medida que el cambio proceda por su ciclo de vida, la solicitud de cambio debería ser actualizada, para que la persona que inició el cambio esté al tanto de su status. Los recursos actuales utilizados y los costos incurridos se deberían registrar como parte del expediente.
Fijar Prioridad
Una vez aceptada la RFC, se indica la prioridad y la categoría de la misma. La prioridad indica la importancia del Cambio y se dirige por el impacto y la urgencia. El código de prioridad ya puede estar atribuido por la Gestión de Problema, pero los códigos definitivos están determinados desde la Gestión de Cambio, considerando las otras RFC pendientes de discusión. La categoría la determina el Director de Cambios, y determina cómo se procesará la aplicación en adelante
Subdivisión de la Prioridad
Los códigos de prioridad por ejemplo, son:
• Prioridad 0, la prioridad más alta: la RFC trata de un problema, lo que causa una inmensa molestia en el uso de servicios esenciales, o concierne un ajuste urgente de IT (por ejemplo una nueva funcionalidad a causa de consideraciones de la compañía o una pequeña ley de emergencia). Los cambios a esta prioridad caen bajo la categoría de “Cambios Urgentes”. Los
24
Cambios Urgentes se difieren de los procedimientos normales porque los recursos necesarios necesitan estar disponibles inmediatamente para este tipo. Una reunión de emergencia del CAB o el comité dirigente de IT puede ser necesaria.
• Prioridad 1, alta prioridad: causa problemas técnicos severos para un gran grupo o un número de usuarios o concierne otras situaciones urgentes. Este Cambio obtiene prioridad máxima en la próxima reunión programada del CAB.
• Prioridad 2, prioridad normal: no una emergencia inmensa o de alto impacto pero el Cambio no se puede posponer a un momento más conveniente. Este Cambio dentro del CAB recibe prioridad media con la atribución de recursos.
• Prioridad 3, baja prioridad: un Cambio es deseado pero podría esperar hasta un momento más conveniente (por ejemplo la próxima difusión o cita de mantenimiento programada).
Subdivisión de la Categoría
Las categorías las atribuye el Director de Cambios, cuando es necesario en deliberación con el CAB, que da una indicación del impacto del Cambio y la carga en la organización de IT. Bajo, se relaciona un ejemplo subdivisión de las categorías enumeradas:
• Estándar: la confianza de que el procedimiento escrito asegurará que los riesgos son mínimos está ahí. El cambio se puede ejecutar sin previo contacto con el director de cambios. Por esta razón, los cambios estándar deben ser ordenados por el director de cambios.
• Categoría 1: pocas consecuencias; un Cambio que no conleva mucho trabajo. El Director de Cambios puede aprobar este tipo de Cambios sin consultar con el CAB.
• Categoría 2: consecuencias sustanciales; Cambios que requieren esfuerzos mayores y que tienen mayor impacto en los servicios. Tales Cambios se discuten en la próxima reunión del CAB para predecir los esfuerzos necesarios y posibles consecuencias. Antes de la reunión, la documentación necesaria será enviada a los miembros del CAB y potencialmente a varios especialistas y encargados de desarrollo.
• Categoría 3: consecuencias inmensas: un Cambio que requiere una gran cantidad de esfuerzo. Con un Cambio así el Director de Cambios necesita obtener autorización de la dirección de IT o un comité dirigente de IT y entonces debe discutirlo con el CAB.
La Junta de Asesoramiento de Cambios (CAB)
El término “Junta de Asesoramiento de Cambios” es un término de ITIL. Para algunos, el término “Junta” crea la imagen de reuniones programadas muy formales del mismo grupo de altos ejecutivos. Aunque una reunión del CAB puede ser formal, también puede ser informal. En el mundo de negocios de hoy, el término “equipo” puede que ilustre mejor la dinámica típica del CAB. El ‘equipo” CAB puede reunirse de forma regular; las reuniones de CAB pueden ser varias veces a la semana, con reuniones especiales convocadas en cualquier momento. Algunos miembros del CAB probablemente tendrán programado asistir a reuniones de CAB regularmente; Otras personas puede que se les pida unirse a una sesión de
25
CAB para proporcionar input sobre una Solicitud de Cambio específica que está programada para discusión.
El CAB existe para aprobar la mayoría de los cambios y para asistir a la Gestión de Cambio en la evaluación y priorización de cambios. Siempre y cuando se convoque al CAB, los miembros elegidos deben ser capaces de evaluar adecuadamente desde un punto de vista tanto técnico como de negocio. Para alcanzar esta mezcla, el CAB necesita incluir personas con un entendimiento claro de las necesidades de negocio del Cliente y de la comunidad Usuaria, además de las funciones de desarrollo técnico y de soporte.
Los miembros del CAB podrían ser el Gerente de Cambios, Cliente(s), Director(es) de Usuarios, representante(s) del grupo de usuarios, encargados de desarrollo /mantenimiento de aplicaciones (en su caso), consultores técnicos, expertos, personal de servicio (según necesidad), personal de servicios de oficina (donde los Cambios puedan afectar alojamiento y viceversa), proveedores y representantes de terceros, etc.
Es importante enfatizar que el CAB:
• Estará compuesta de acuerdo con los Cambios considerados
• Puede variar considerablemente en su arreglo incluso a lo largo de una sola reunión
• Debería involucrar a proveedores cuando sea de utilidad
• Debería reflejar los puntos de vista tanto del Cliente como del usuario
• Es probable que ¡ncluya al Director de Problemas y al Director de Nivel de Servicio y personal de Atención al Cliente por lo menos parte del tiempo.
Cuando surjan Problemas mayores, puede que no haya tiempo de crear el CAB entero, y por lo tanto es necesario identificar una organización más pequeña con autoridad para tomar decisiones de urgencia. Tal cuerpo en ITIL se conoce como el Comité de Emergencia del CAB (CAB/EC). Los procedimientos de Cambio deberían especificar cómo el formato de CAB y CAB/EC se determinará en cada instancia, basado en el criterio arriba indicado y cualquier otro criterio que pueda ser apropiado para el negocio. Esto se hace con la intención de asegurar que el formato del CAB sea flexible, a fin de representar los intereses del negocio adecuadamente cuando se proponen cambios. También asegurará que la composición de la CAB/EC proporcionará la habilidad, tanto desde el punto de vista del negocio como técnico, de tomar decisiones en cualquier eventualidad concebible.
La Gestión de Cambio y de Configuración están muy relacionados una con la otra. En primer lugar, por el hecho de que la Gestión de Configuración no puede sobrevivir sin la Gestión de Cambio. No puedes controlar la CMDB si no controlas la configuración misma. El proceso de Verificación es un proceso que se puede usar para controlar la efectividad de la Gestión de Cambio. Si —tras verificación- el Director de Configuración ha encontrado CI’s en la configuración que no están en la
base de datos hay dos opciones: 1) la base de datos no está actualizada que puede indicar que no se informó a la Gestión de Configuración del cambio o 2) alguien ha ejecutado un cambio ilegal (no aprobado).
El campo más importante donde se relacionan los procesos es en el análisis de impacto y riesgo de un cambio. La mayor parte de esto se tiene que hacer con la ayuda de CMDB. Si alguien envió una RFC, una de las primeras cosas es averiguar que CI o Cl’s se tienen que cambiar y cuál es el impacto en la infraestructura existente. También tenemos que averiguar si esta RFC resultará en más RFCs por el hecho de tener que cambiar más Cl’s como resultado de esta solicitud. Y tenemos que averiguar si el cambio sólo afecta a uno o más usuarios, uno o más dominios o
26
uno o más servicios a fin de asignar el código correcto de impacto a este cambio. Basado en todo esto, podemos decidir si el CAB es necesario, a quién tenemos que invitar para esto, en qué nivel tenemos que discutir y aprobar el cambio y podemos generar la lista de “qué hacer” más completa.
Informes de Gestión
La Gestión de Cambio (de modo ideal en consulta con los directores de negocio) necesita pensar en medidas que tengan significado específico. Mientras que es relativamente fácil contar el número de Incidencias que se convierten en Problemas que se convierten en Cambios, es infinitamente más valioso mirar a las causas subyacentes de tales Cambios e identificar tendencias. Mejor aún poder medir el impacto de tales Cambios y demostrar trastorno reducido a lo largó del tiempo por la introducción de Gestión de Cambios y también medir la velocidad y efectividad con la que la infraestructura de IT responde a necesidades de negocio identificadas.
Se deberían proporcionar resúmenes regulares de Cambios a la dirección de servicio, Cliente y Usuario. Es probable que distintos niveles de dirección requieran distintos niveles de información, desde el Director de Servicio que puede necesitar un informe detallado semanal hasta los comités de Dirección Superior que es probable que sólo necesiten un resumen trimestral de dirección.
Considere los datos y estadísticas a continuación en los informes de dirección:
• El número de Cambios implementados en el periodo, en total y por CI, tipo de configuración, servicio, etc.
• Un desglose de razones para el Cambio (solicitudes de Usuarios, mejoras, requisitos de negocio, arreglos de llamada de servicio / Incidencias / Problemas, mejoras de procedimientos /formación, etc.)
• El número de Cambios con éxito • El número de Cambios retrocedidos, junto a las razones (p.ej. evaluación
incorrecta, mala construcción) • El número de Incidencias que llevan a Cambios (desglosados por niveles de
severidad de problemas) y las razones ((p.ej. evaluación incorrecta, mala construcción)
• El número de RFCs (y tendencias en proceso de originarse) • El número de Cambios implementados revisados, y el tamaño de revisiones
de atrasos (desglosados por tiempo) • Altas incidencias de RFCs/PRS relacionados a un CI (estos merecen especial
atención), dando las razones (p.ej. requisito de usuario volátil, componente frágil, mala construcción)
• Cifras de periodos anteriores • El número de RFCs rechazadas • La proporción de Cambios implementados que no tienen éxito (en total y
desglosado por CI’s) • Atrasos de Cambios, desglosados por CI y por etapa en el proceso de
Gestión de Cambios
27
Gestión de la Configuración La Gestión de Configuración es una disciplina que permite a la gestión de IT obtener un control estricto sobre los bienes de IT tales como hardware, comunicaciones, programas informáticos, documentación y cualquier otro item (llamados Ítems de Configuración CI’s) que se relacionen con la infraestructura de IT.
La implementación de la disciplina de Gestión de Configuración permite a la dirección:
• Especificar versión, propiedad, e información de status para los Items de Configuración (CI’s) existentes en la infraestructura de IT.
• Describir las relaciones entre esos items
• Mantener historiales actualizados de esos items
• Controlar cambios a esos items asegurando que esos cambios son consistentes con los objetivos de las autoridades apropiadas
• Y auditar la infraestructura de IT para asegurar que contiene sólo Cl’s autorizados.
Las empresas requieren servicios de calidad de IT proporcionados de forma económica. Para ser eficientes y efectivos, todas las organizaciones deben controlar su infraestructura y servicios. La gestión de Configuración proporciona un modelo lógico de la infraestructura o de un servicio al identificar, controlar; mantener y verificar las versiones de Items de Configuración (CI’s) existentes. Objetivos detallados de Gestión de Configuración deben incluir:
• Proporcionar a todas las personas trabajando en Gestión y soporte de Servicios información correcta y exacta de las configuraciones actuales con sus especificaciones físicas y funcionales.
• Definir y documentar los procedimientos y prácticas de trabajo a seguir • Identificar, etiquetar y grabar los nombres y versiones de los Cl’s que
constituyen los servicios de IT, infraestructura y sus relaciones. • Controlar y almacenar copias definitivas, autorizadas y fiables de
especificaciones, documentación y software • Informar del status actual e historial de todos los items en la infraestructura
de IT • Asegurar que todos los Cambios a CI’s se graban en cuanto se pueda • Localizar y reconciliar el estado actual de la infraestructura de IT con los
historiales de configuración autorizados y los datos • Educar y formar a la organización en procesos de control • Informar de métricas en CI’s, Cambios y Difusión • Auditar e informar de excepciones a los estándares de infraestructura y los
procedimientos de Gestión de Configuración. • Proporcionar información exacta de configuraciones y su documentación
para soportar todos los demás procesos de Gestión de Servicio • Proporcionar una base sólida para Gestión de Incidencia, Gestión de
Problemas, Gestión de Cambio y Gestión de Difusión • Contabilizar todos los bienes y configuraciones de IT dentro de la
organización y sus servicios. • Verificar los historiales de configuración con la infraestructura y corregir las
excepciones si las hubiera. La Gestión de Configuración cubre desde la identificación, registro, y presentación de los componentes IT, incluyendo versiones y constituyendo componentes y relaciones. Los elementos que deben estar bajo el control del la gestión de configuración van desde hardware, software hasta documentación asociada. Debe
28
quedar claro que la gestión de la configuración no es sinónimo de la gestión de activos, aunque las dos disciplinas estén relacionadas. La gestión de activos es un proceso reconocido de contabilidad que incluye la contabilidad de la depreciación. Los sistemas de gestión de activos mantienen con detalle los activos por encima de un cierto valor, su unidad empresarial, y su localización. La gestión de configuración también conserva la relación entre activos, lo cual no suele hacer la gestión de activos. Algunas empresas empiezan con la gestión de activos después se pasan a la gestión de configuración. Actividades de la Gestión de Configuración
� Planificación. La planificación y el diseño de propósito, competencia, objetivos, políticas y procedimientos, y contexto técnico y organizativo, para la gestión de la configuración.
• Identificación. Selección e identificación de las estructuras de configuración para los CI de todas las infraestructuras, incluyendo sus “propietarios”, sus interrelaciones y la documentación de la configuración. Esto incluye los identificadores de localización y los números de versión para los CI, etiquetando cada elemento, y agregándolo en la base de datos de configuración (CMDB).
• Control. Asegurando que sólo son aceptados y almacenados los CI autorizados e identificados. Esto garantiza que ningún CI es añadido, modificado, reemplazado o borrado sin la documentación de control apropiada, por ejemplo una solicitud de cambio aprobada, o una especificación de actualización.
• Registro de estado. Informando de todos los datos en curso o históricos relacionados con cada CI a lo largo de su ciclo de vida. Esto permite hacer un seguimiento de los cambios en los CI y de sus registros, por ejemplo rastrear el estado de un CI y sus cambio de un estado a otro como es el de “en desarrollo”, “en pruebas” o “retirado”.
• Verificación y auditoría. Una serie de revisiones y auditorías que verifican la existencia física de los CIs y que comprueban que están correctamente grabados en el sistema de gestión configuración.
Las interfaces de la gestión de la configuración directas con los sistemas de desarrollo, prueba, gestión de cambios y gestión de difusión incorporan una nueva y actualizada entrega de productos. El control debe ser aprobado por el proveedor de servicio de soporte o del proyecto en el tiempo planificado con los registros precisos de configuración. Las responsabilidades del encargado o administrado de la configuración son:
• Trabajar los objetivos generales de acuerdo con el servicio de gestión IT; implementar la política de gestión de configuración de la empresa y sus estándares.
• Evaluar los sistemas de gestión de configuración existentes y el diseño, implementación y gestión de sistemas nuevos o mejorados para una mayor eficacia o eficiencia- incluyendo estimaciones y planificaciones de trabajo de recursos relacionados, rastreando e informando del progreso respecto a la planificación.
• Proponer y consentir el alcance de los procesos de la gestión de configuración, funciones, los ítems que deben ser controlados, y la información que hay que grabar. Desarrollar las normas, los planes y los procedimientos de la gestión de configuración.
• Montar una campaña de conciencia para ganar el soporte para el nuevo procedimiento de la gestión de configuración. Asegurar los cambios de los
29
métodos y de los procesos de la gestión de configuración que han sido comprobados correctamente y avisados al personal antes de ser implementado. Planes, publicaciones e implementaciones en el nuevo sistema de la gestión de configuración
• Fabricar las herramientas para producir un medio efectivo de la gestión de configuración en términos de la base de datos y de las librerías del software y de la generación del informe.
• Crear y gestionar el plan, los principios y los procesos de la gestión de configuración y sus implementaciones. Esto incluye los procedimientos del registro del CI; acceso de la lista de control y privilegios. Asegurar que los roles y las responsabilidades correctas están definidos en los planes y procedimientos de la gestión de configuración.
• Proponer y ponerse de acuerdo con los CIs para ser identificados de forma unívoca con las convenciones de nombres correctas. Asegurarse de que el personal cumple con los estándares de identificación en tipos, entornos, procesos, ciclos de vida, documentación, versiones, formatos, bases, emisiones y plantillas (todo el contenido de la CMDB).
• Proponer (y/o ponerse de acuerdo) interfaces con la gestión de cambios, la gestión de problemas, gestión de redes, gestión de difusión, operaciones informáticas, finanzas y funciones de administración (con el resto de procesos en el departamento).
• Planificar y ejecutar la población de la CMDB. Gestionar y mantener la CMDB, las librerías centrales, las herramientas, los códigos de dominio público y los datos. Asegurar la administración de la CMDB.
• Proporcionar informes, incluyendo los de gestión (añadiendo la acción sugerida para realizar con las previsiones actuales o futuras), informes de impacto de análisis e informes del estado de la configuración.
• Usar o proporcionar la CMDB para facilitar el cálculo del impacto de los RFCs y para asegurar que los cambios implementados están autorizados. Al crear los registros de cambios, las bases de configuración, y el empaquetado de los registros de emisión se especifican los efectos en los CIs de un cambio autorizado.
• Proporcionar la CMDB para identificar otros CIs afectados por un error que está afectando al CI.
• Desarrollar las auditorías de configuración para comprobar que el inventario IT físico está acorde con la CMDB e iniciar la acción correctiva necesaria.
• Iniciar las acciones necesarias para asegurar los fuentes de forma que se mejore la infraestructura y los niveles de acceso de los empleados para arreglárselas en caso de cambio y/o crecimiento.
• Ayudar a los auditores en las actividades de auditoría del equipo de gestión de configuración para colaborar en los procedimientos establecidos. Asegurar la acción correctiva que se lleva a cabo.
Terminología
Bien: Componente de un proceso tal como personas, alojamiento, sistemas informáticos, expedientes de papel, máquinas de fax, etc.
Items de Configuración (CI): Componente de una infraestructura - o un item, tal como una Solicitud de Cambio, asociado con una infraestructura- y servicios, que estén (o han de estar) bajo el control de Gestión de Configuración. Cl’s pueden variar mucho en complejidad, tamaño y tipo- desde un sistema entero a un componente de hardware menor. Ejemplos son: hardware, software, documentación, procedimientos, funciones, alojamientos, servicios, servidores, entornos, equipamiento, componentes de red, escritorios, unidades móviles, aplicaciones, licencias, telecomunicación.
30
Base de Datos de Gestión de Configuración CMDB: Muchas organizaciones ya utilizan algunos elementos de Gestión de Configuración, a menudo usando hojas de cálculo, bases de datos locales o sistemas basados en papel. En las infraestructuras de hoy en día grandes y complejas, la Gestión de Configuración requiere el uso de herramientas de soporte, que incluye la base de datos de Gestión de Configuración (CMDB). Son necesarios archivos electrónicos y físicos junto al CMDB para almacenar copias definitivas de software y documentación. Es probable que la CMDB se base en tecnología de base de datos que proporciona facilidades de interrogación flexibles y poderosas. La CMDB debe contener todas las relaciones entre los componentes del sistema, incluidos Incidencias, Problemas, Errores Conocidos, Cambios y Difusiones. La CMDB también contiene información sobre Incidencias, Errores Conocidos y Problemas y datos corporativos de empleados, proveedores, localidades y unidades de negocio. La CMDB también se puede utilizar para almacenar y controlar los detalles de los usuarios de IT, empleados de IT y unidades de negocio, aunque las implicaciones legales de almacenar información sobre personas en la CMDB se deben considerar. Almacenar tal información en la CMDB permitiría que Cambios de Personal se relacionaran con la propiedad de Cambios de CI
Rango CMDB
El factor primordial al decidir tanto el rango como el detalle es la información necesaria para gestionar el servicio al margen del coste o dificultad de obtener y mantener esos datos. Un punto de vista más pragmático es que no sólo se deben tener en cuenta esos factores sino también, y puede que de modo más importante, los directores deben considerar las consecuencias de almacenar datos poco exactos o desfasados en la CMDB.
Antes de que la transición de montar una CMDB se lleve a cabo, se debe decidir acerca de qué parte de la infraestructura de IT será controlada por la Gestión de Configuración. La elección del Rango influye al rango de diagnósticos de Gestión de Problemas, para la coordinación de Gestión de Cambios, etc. Esta elección se recoge de las Declaraciones de Misiones que se montan para los procesos. La elección del Rango también se monta en parte de un análisis de los servicios y su contribución a, o su impacto en, las actividades de negocio de los clientes. Aparte de esto, el Rango se puede recoger de la determinación del Acuerdo de Nivel de Servicio.
Detalle CMDB
Con la subdivisión en niveles, se crea una jerarquía de componentes y unidades. Se toman decisiones sobre qué son Cl’s principales y en cuántos niveles estos Cl’s deben ser detallados. El nivel más alto es la infraestructura de IT misma. El nivel útil más bajo es el nivel donde todavía sea posible llevar control. La encarnación de un CI en la CMDB sólo es efectiva cuando el control sobre el CI y la información que conlleva sea útil para otros procesos de ITIL.
Con el establecimiento de la jerarquía de una CMDB, rigen las siguientes normas:
� Cuando hay más niveles, se debe mantener más información. Esto conlleva más trabajo y resulta en una CMDB más grande.
� Cuando hay menos niveles, hay menos control e información sobre la infraestructura de IT.
Cuando la CMDB no tiene profundidad suficiente, los cambios a los componentes más bajos no se puede mantener adecuadamente. Cada ajuste a componentes de un CI madre resultará en una versión alternativa del CI madre; un PC que aparece con dos discos duros tendrá entonces una versión A y una versión B. Si aparecen
31
muchos ajustes en los componentes filiales, entonces la numeración de variación se volverá opaca y difícil de seguir.
Nombramiento
El nombre de un CI debe ser único. Cada CI en la infraestructura controlada debe ser identificado y sólo podemos hacer esto, dando a cada CI un número único. Como su automóvil. Este automóvil es único en- el mundo por una combinación de números en su matrícula y el estado /país donde vive.
Nombramiento debe ser lógico y sencillo. Sencillo porque ¿qué necesidad hay de hacerlo difícil? Personal de IT y clientes deben tener idea de cómo leer y montar la identificación de CI. Así que intente encontrar una identificación lo más lógica y sencilla como le sea posible: como Al 234567 en vez de PC_BUILDA_LOKI.4_ 1234.
A lo largo del ciclo vital de un CI, la primera identificación dada debe permanecer. 1 que la excepción confirma la regla! Así que esta es otra razón por la que no implementar números como PC_BUILDA_LOKI.4_ 1234 porque se relacione con el edificio donde se instaló.
Detalles de CMDB
Los siguientes atributos son ejemplos que se pueden utilizar en la CMDB. Note que el hardware de los tipos de CI tendrá distintos atributos de los tipos de CI de software.
Atributo Descripción
Nombre de CI El único nombre por el que se conocerá este tipo de CI
Número de Copia o de Serie
El número que identifica de forma única las instancias particulares de este CI, por ejemplo, el número de copia de software, para hardware el número de serie
Categoría Clasificación de un CI (p.ej. hardware, software, documentación, etc.)
Tipo Descripción del tipo de CI, ampliando la información de “categoría” (p.ej. configuración de hardware, paquete de software, aparato de hardware o módulo de programa).
Número de modelo
Modelo de CI (correspondiente por ejemplo al número de modelo de proveedor (hardware) p.ej. Dell model xxx, PC/aa model yyy).
Fecha de vencimiento de Garantía
Fecha en la que vence la garantía del proveedor
Número de Versión El número de versión del CI.
Localidad La localidad del CI, p.ej. la biblioteca o medio donde reside el software del CI, el sitio/cuarto donde se encuentra un servicio.
Propietario Responsable El nombre y/o designación del propietario responsable del CI
Fecha de Responsabilidad
Fecha en la que el propietario arriba mencionado se hizo responsable del CI
32
Fuente / Proveedor La fuente del CI, p.ej. desarrollado en la misma casa, importada de la empresa xxxx etc.
Licencia Número de licencia o referencia al acuerdo de licencia
Fecha de Provisión Fecha cuando el CI fue dado a la organización.
Fecha de Aceptación/Instalación
Fecha en la que el CI fue aceptado por la organización como probado de modo satisfactorio.
Estatus (Actual) El status actual del CI; p.ej. bajo “prueba”, “vivo”, “archivado”.
Status (programado)
El próximo status programado del CI (con la fecha o indicación del evento que provocará el cambio de estatus).
Comentario
Un campo de comentario a ser utilizado para narrativa textual; por ejemplo, para proporcionar una descripción de cómo esta versión del CI es distinta de la versión anterior.
Relaciones en la CMDB
Se pueden llevar al día muchos distintos tipos de relaciones. Las relaciones más frecuentes son:
• Es un componente de; esta es la relación de madre-hija del CI, como un disco A es un componente de un PCy un módulo de software es un componente de un programa.
• Es una copia de; una copia de un modelo estándar o de un programa.
• Se relaciona a un procedimiento, un SLA o un programa
• Se relaciona con; por ejemplo, un PC que está conectado con un segmento LAN.
• Es utilizado por; como un CI que es utilizado por un servicio, para que se puedan calcular los costes y la disponibilidad del servicio, o un módulo de software que es necesario para varios programas para que se pueda hacer un seguimiento de “cuál es el impacto de un ajuste”.
Igual que al determinar el número de niveles, es necesario sopesar de forma meticulosa qué es necesario, la cantidad de trabajo que conlleva y los recursos disponibles para ese trabajo, se debe hacer al determinar las relaciones necesarias.
Otras relaciones:
� RFC’s: La relación con todas las RFC’s afectando este CI.
� Relación con Cambios: La relación con todos los archivos de cambios afectando a este CI
� Relación con Problemas: La relación con todos los archivos de Problemas afectando este CI
� Relación con Incidencias: La relación con todos los archivos de Incidencia afectando este CI
Las relaciones que los CI’s tienen unos con los otros, entre otras cosas, son útiles para muchas cuestiones. En primer lugar, podría ser de tremenda ayuda para el
33
Director de Gestión de Servicio. Para crear un SLA y OLA’s o contrato, para analizar cómo se configuran servicios de punta a punta-es muy importante saber cómo está construida la infraestructura y qué Cl’s son parte de los servicios que producimos.
Si registramos un servicio como CI y relacionamos todos los componentes que necesitamos para poder entregar este servicio, el Servie Desk puede analizar mejor qué componente es el que puede causar la Incidencia. Si hemos relacionado el CI del documento de SLA al servicio, el Service Desk puede averiguar inmediatamente qué servicio es el que tiene que entregar al cliente. Si relacionamos todas las incidencias habidas al CI al que pertenece podríamos investigar si el actual está relacionado con los habidos anteriormente y si se puede encontrar una solución.
En segundo lugar, para el diagnóstico de problemas técnicos, puede ser muy útil también. Si tenemos incidencias relacionadas podemos investigarlas también para encontrar la causa original. Si hemos relacionado el historial de cambios anteriores podemos investigar si esos cambios son la causa de este problema.
Por último, pero no por ello de menor importancia, las relaciones son muy importantes para analizar el impacto de un cambio. Sólo con relaciones puede ver la relación entre el CI que se debe cambiar y otros CI’s. Basado en la información el Director de Cambios puede fijar la categoría, puede invitar el personal adecuado al CAB y puede decidir qué se debe hacer para que este cambio sea un éxito.
Estados de CI’s
El ciclo de vida de un componente se puede dividir en muchas etapas distintas. Cada etapa puede recibir un código de estatus. Esta información se determina por los intereses que la organización ha hecho públicos con respecto a los rasgos de la infraestructura de IT que necesitan ser registrados. Al guardar la fecha de los cambios de status, se puede desarrollar una buena visión del ciclo vital de un producto; las horas de adquisición, las horas de instalación y la cantidad de mantenimiento y soporte que se ha invertido.
El cambio del estado de un CI puede estar relacionado con un ajuste o cambio, permitido o no permitido, o a una incidencia.
Se puede considerar la siguiente subdivisión:
• Nuevos CI’s:
• En desarrollo/pedidos
• Probados
• Aceptados
CI’s Existentes:
• Recibidos. • Aplicación no fijada de cambio para este CI, solicitada nueva versión. • El cambio ha sido aprobado y se ha considerado en el plan, un nuevo CI y
documentación (que también es un CI) llega. • Bajo mantenimiento. • Fuera de servicio, problemas técnicos • Fuera de uso, archivado
Todos los CI’s:
• La orden se ha recibido o la versión ajustada está disponible. • Está siendo probado • Liberado, se puede instalar • Activo, el CI está siendo utilizado. • Provisiones
34
Línea Base (Baseline)
Una línea base de configuración es la configuración de un producto o sistema establecido en un momento concreto en el tiempo, que capta tanto la estructura como los detalles de una configuración. Es una referencia para más actividades. Una aplicación o línea de base de software proporciona la habilidad de cambiar o reconstruir una versión concreta en una fecha más adelante.
Las líneas base de configuración se deben establecer mediante un acuerdo formal en momentos concretos del tiempo y se deben utilizar como puntos de referencia para el control formal de una configuración. Las líneas base de configuración mas cambios aprobados a esas líneas de base, juntos, constituyen la configuración actualmente aprobada. Ejemplos específicos de líneas base que se pueden identificar son:
� Un CI estándar particular necesitado cuando se compran muchos artículos del mismo tipo (p.ej. ordenador de escritorio) a lo largo de un periodo pactado. Si unos servidores deben incluir teclados de circuito impreso adicionales, esto podría corresponder a una “línea base plus”. Si todos los ordenadores de escritorios en el futuro tendrán estos teclados, se forma una nueva línea base.
� Una aplicación de Difusión y su documentación asociada
• A la que referirse (debe existir físicamente y poder referirse a ella con facilidad)
• Como estado del software para distribución a locales remotos • Como estado del software sobre el que trabajar en un futuro • Como estado en el que debe estar un sistema antes de poder mejorarlo
aceptando nuevo hardware o software.
Varias líneas base correspondientes a distintas etapas en la vida de un “item de línea base” pueden existir en un momento dado, por ejemplo, la línea base para una difusión de software que ya está en “vivo”, la anterior a éste y que ahora se encuentra “archivado”, el próximo que está para “instalar”(salvo cambios bajo control de Gestión de Configuración) y uno o más bajo “prueba”. Más de una versión de línea base podría estar “viva” a la vez. Por lo tanto, es mejor referirnos a cada una por su número exclusivo de versión, mejor que como “vivo”, “próxima” o “antigua/archivada”.
Una línea base de configuración es también una foto instantánea, o una situación actual de configuración de la infraestructura de IT grabada. Aunque la posición se pueda actualizar después, la línea base de configuración queda fijada como el estado original y por lo tanto, está disponible para poder compararse con la posición actual. Una línea base de configuración se utiliza para montar todos los componentes relevantes en preparación para un Cambio o una Difusión, y para proporcionar la base para una auditoria y regresión por ejemplo. después de un Cambio. El sistema de Gestión de Configuración debería poder guardar, proteger e informar de una línea base, su contenido y documentación.
Informes de Gestión
Los informes de gestión deberían estar diseñados para soportar actividades de Gestión de Servicio tales como monitoreo de progreso, auditorias de Configuración y programación de servicios. Los informes se deben poner a disposición para interrogación y análisis de tendencias por parte de la Dirección de Servicio de IT y otros grupos dentro de la estructura de servicios de IT. En general, la Dirección de Gestión de Servicios debe marcar la dirección futura de la Gestión de Configuración a la luz de estos informes de gestión, teniendo en cuenta la carga de trabajo y crecimiento de la Gestión de Configuración programada.
Los informes de dirección de Gestión de Configuración deberían cubrir lo siguiente.
35
• Resultados de auditorias de configuración • Información sobre CI’s no-registrados o registrados de modo poco exacto
que se han detectado y la acción correctiva • Información sobre el número de Cl’s registrados y versiones de CI’s,
divididos por categoría, tipo y estatus (y posiblemente también por localización u otros atributos de CI)
• Información de crecimiento y capacidad • Información sobre el ritmo de cambio de Cl’s/ CMDB y la DSL • Detalles de trabajo acumulado (backlogs) de Gestión de Configuración o
atrasos causados por actividades de Gestión de Configuración y remedios propuestos.
• La posición de personal de Gestión de Configuración • La cantidad de trabajo autorizado realizado fuera de horario por empleados
de otros servicios de IT • Los resultados de revisiones de eficiencia / efectividad, revisiones de
crecimiento y auditorias del sistema de Gestión de Configuración y propuestas para atacar problemas reales o en potencia
• Datos y análisis del número de Cl’s por tipo (p.ej. servicios, servidores, routers, conmutadores, licencias de software, CI’s de escritorio, etc.)
• El valor de los Cl’s (o bienes) • La localización de CI’s por unidad de negocio, grupo de soporte o servicio.
36
Gestión de la Difusión (Versiones)
Como cada vez más el hardware y software se consideran un bien organizacional importante, de hecho frecuentemente de naturaleza estratégica, el control de los mismos es obligatorio. A continuación, hay algunas consideraciones importantes:
• Actividad Preventiva (p.ej. protección de copias ilegales)
• Consistencia (p.ej. programas de cliente compatibles con programas de servidores)
• Licenciar (p.ej. no exceder un número acordado de usuarios máximo en un momento dado)
Gestión de Difusión es responsable del almacenamiento de software autorizado por la Dirección (desarrollado de modo interno, comprado o aplicación licenciada o software de utilidad, etc.), de la difusión de software a un entorno vivo, de la distribución de software a locales remotos, de la implementación de software para introducirlo al servicio y de tener hardware para que las incidencias e instalaciones se puedan llevar a cabo rápidamente.
Factores tales como el número creciente de software interdependiente de Ítems de Configuración (CI’s), el potencial de introducción de virus, y estrategias de licencia complejas para minimizar costos de licencia, a la vez de hacer disponible el software donde es necesario, todos sugieren el valor de una inversión inmediata en la implementación de una disciplina rigurosa de Gestión de Difusión.
Muchos proveedores de servicios pueden estar involucrados en la difusión de hardware y software en un entorno distribuido. Una buena gestión y planificación de recursos son esenciales para empaquetar y distribuir satisfactoriamente una difusión para el Cliente. Gestión de la Difusión tiene una visión total de un Cambio a un servicio IT y debe garantizar que todos los aspectos de un lanzamiento, tanto técnicos como no técnicos, se consideren en conjunto. Los objetivos de Gestión de la Difusión son:
• Planear y supervisar la presentación del software y del hardware relacionado.
• Diseñar e implementar acciones eficientes para la distribución e instalación de Cambios para los sistemas IT.
• Asegurar que el hardware y el software que están siendo cambiados puedan ser seguidos, seguros y que sólo sean instaladas versiones correctas y autorizadas.
• Comunicar y gestionar las expectativas del Cliente durante la planificación y presentación de nuevas Difusiones.
• Aprobar el contenido exacto y plan de presentación para el lanzamiento, aunque en colaboración con Gestión de Cambios.
• Implementar nuevas Difusiones de software y hardware en el entorno operativo usando los procesos controladores de Gestión de Configuración y Gestión de Cambios – una Difusión debe estar bajo Gestión de Cambios y puede consistir de cualquier combinación de hardware, software, firmware o documentos CI.
• Asegurar que las copias maestras de todo el software están seguras en la biblioteca de software definitiva (DSL) y que la Base de Datos de Gestión de Configuración (CMDB) este actualizada
• Asegurar que todo el hardware que está siendo comunicado o cambiado es seguro y puede ser seguido, usando los servicios de Gestión de Configuración.
37
El foco de Gestión de Difusión es la protección del entorno vivo y sus servicios a través del uso de procedimientos y comprobaciones formales. Gestión de Difusión trabaja estrechamente con Gestión de Cambios y con los procesos de Gestión de Configuración para asegurar que la CMDB compartida se mantiene al día con los Cambios implementados por las nuevas Difusiones, y que el contenido de esas Difusiones son almacenados en la DSL. Las especificaciones de hardware, instrucciones de implementación y configuraciones de red también son almacenadas en la DSL/CMDB. Las actividades de Gestión de Difusión incluyen:
• Política y planificación de la Difusión • Diseño, construcción y configuración de Lanzamiento • Aceptación de Lanzamiento • Evolución de la planificación • Extensión de pruebas para predefinir el criterio de aceptación • Comunicación, preparación y formación • Auditorias de hardware y software anteriormente y seguidamente de la
implementación de Cambios • Instalación de hardware nuevo y actualizaciones • Almacenamiento de software controlado en ambos centralizados y sistemas • Difusión, distribución e instalación de software.
Los principales componentes a ser controlados son:
• Programas de aplicación desarrollados por el departamento • Software desarrollado externamente (incluido software estándar comprado
tal cual, así como software escrito por el Cliente) • Utilidades de software • Sistemas de software de proveedores y suministradores • Hardware y especificaciones del hardware • Instrucciones y documentación reunidas, incluyendo el manual de usuario.
Todos los entregables necesitan ser manejados eficientemente, desde el desarrollo o adquisición, a través de la personalización y configuración, a través de las pruebas y la implementación, hasta la operación en el entorno productivo. Gestión de la Difusión debe ser usado para:
• Grandes o críticos lanzamientos de hardware, especialmente cuando hay una dependencia con un cambio de software relacionado a un sistema de negocio, es decir, no cada PC que necesita ser instalada.
• Grandes lanzamientos públicos de software, especialmente casos iniciales de nuevas aplicaciones junto con distribuciones de software complementario y procedimientos de soporte para posterior uso en el caso de requerirse
• Empaquetar y ejecutar en modo batch conjuntos relacionados con Cambios en las unidades
Las principales responsabilidades del encargado de la difusión son:
• Planear y supervisar la evolución satisfactoria del software y el hardware relacionado.
• Diseñar e implementar eficientemente procedimientos para la distribución e instalación de Cambios para los Sistemas IT.
• Asegurar que el hardware y el software que están siendo cambiados puedan ser seguidos, seguros y que sólo sean instaladas versiones correctas y autorizadas.
• Comunicar y gestionar las expectativas del Cliente durante la planificación y presentación de nuevas Difusiones.
38
• Aprobar el contenido exacto y plan de presentación para la Difusión, aunque en colaboración con Gestión de Cambios.
• Implementar nuevas Difusiones de software y hardware en el entorno operativo usando los procesos controladores de Gestión de Configuración y Gestión de Cambios – una Difusión debe estar bajo Gestión de Cambios y puede consistir cualquier combinación de hardware, software, firmware y documentos CI.
• Asegurar que las copias maestras de todo el software están seguras en la librería de software definitiva (DSL) y que la Base de Datos de Gestión de Configuración (CMDB) es actualizada
• Asegurar que todo el hardware que está siendo comunicado o cambiado es seguro y puede ser seguido, usando los servicios de Gestión de Configuración.
Proceso de Distribución y Difusión
Los entornos se deben mantener separados con una ruta de migración controlada y un rastro de auditoria de todas las difusiones y retrocesos. El entorno de archivo puede ser considerado un sub-entorno de la DSL y ser sujeta al mismo nivel de control. Si se encuentran errores inaceptables durante las pruebas (y cambios realizados) el número de versión debe ser aumentado. Todo se hace bajo el control de Gestión de Cambios.
La Gestión de Difusión cubre la parte desde el momento en el que se adopta el software en la DSL hasta que el software es trasladado a los archivos.
Durante el ciclo de vida de un programa, se pasan por los siguientes pasos:
• El proceso comienza o con la adquisición del software, o con la asignación del desarrollo del software.
• Cuando se entrega el software se realizará una comprobación de calidad.
• En la comprobación de calidad, el software se adopta a la DSL. Se examina por ejemplo si éste realmente es el software pedido, si nuevas versiones se han desarrollado de la fuente correcta, si todos los ajustes han sido autorizados por Gestión de Cambios y si todos los artículos están registrados en la CMDB.
• Una vez aceptado el software, un backup (soporte) de la DSL se hace después del cual el software será aceptado en la DSL. Estos backups deben ocurrir frecuentemente para que en caso de un desastre la última versión correcta pueda ser montada con rapidez.
• La compilación y sincronización de cada difusión son decididas por adelantado por la Gestión de Cambio, un “Registro de Difusión” se hace en la CMDB y todos los detalles se registran.
• Cuando todos los componentes del software están preparados, el paquete se puede realizar en un área de prueba donde todos los tests obligatorios se puedan ejecutar.
• Cuando se encuentran demasiados errores, el software se devuelve para más desarrollo
• Cuando se apruebe el software, será difundida para su explotación. La difusión entonces será distribuida y llevada a su explotación.
Se puede disponer de copias de los artículos de software de la DSL para varias áreas diferentes, de los cuales los cuatro más habituales se detallan a continuación.
39
• Desarrollo: cuando se desarrolla una nueva versión, se puede originar de una anterior de la DSL. El área de desarrollo es la única área en el que se puede ajustar o cambiar el software.
• Prueba: en un área de testing, se pueden probar ciertas versiones
• Explotación: El área real (producción) desde la cual se pone a disposición a los usuarios el software.
• Archivos: aquí se guardan versiones originales (anteriores) de artículos de software que ya no están en uso. Estas copias sólo pueden estar presentes en un solo área en cada momento.
Biblioteca Definitiva de Software (DSL)
La Biblioteca Definitiva de Software (DSL) es una conglomeración de Items de Configuración de software y documentación en un lugar seguro. Físicamente, la DSL puede ser una colección de medios electrónicos (como disquetes, cintas y CDs) en distintos formatos de software; archivos y documentación electrónica (o de papel). La DSL es una biblioteca lógica. Eso significa que “lógicamente” hay una sola entidad de software almacenada. Físicamente, es posible que haya muchas copias de una entidad de software, almacenadas en distintos lugares (en un banco, en un centro de contingencia, cerca de desarrollo, etc.) Ya que todas estas entidades deben ser la misma, “lógicamente” seguimos teniendo una sola entidad.
Cada item de Software autorizado se almacena (físicamente) en la DSL. En la DSL, se guardan todas las versiones originales de software que han sido transmitidas a explotación.
Almacén Definitivo de Hardware (DHS)
Se debe apartar un área para el almacenaje seguro de repuestos de hardware definitivos. Estos son componentes y montajes de repuesto que se mantienen al mismo nivel que los sistemas comparativos en el entorno vivo. Detalles de estos componentes y sus respectivos contenidos y construcciones se deben registrar comprensiblemente en la CMDB. Estos se pueden utilizar entonces de manera controlada cuando se necesiten sistemas adicionales o en la recuperación de Incidencias mayores. Una vez que su uso (temporal) haya terminado, deben ser devueltos al DHS o se deben obtener sus substitutos.
Versiones
EL Director de Difusión debe fijar una Política de Difusión por adelantado en la que se decide cómo y cuándo se deben compilar las actualizaciones del software. La primera elección que se hace ahí es la del nivel de Difusión de Software. Se hace un inventario en el que los subitems de un programa todavía se pueden distribuir de forma independiente unos de otros.
Un ejemplo de un problema rodeando esta elección es la difusión de expedientes de Dynamic Link Libraries (DLL- Bibliotecas de Nexos Dinámicos), que a menudo requieren programas diferentes. A veces una nueva versión de una DLL se entrega con un paquete y esto podría significar que también le influye a otro software. La elección final depende de:
• La cantidad de trabajo que el ajuste de un componente del programa cause a otros componentes del programa (incluido el software de sistema).
• La cantidad de horas humanas y tiempo que hace falta para construir y probar cambios individuales, en comparación con lo que costaría guardar algunos y ejecutarlos todos a la vez.
40
• El grado de dificultad de una posible instalación con los usuarios; puede por ejemplo, ser más fácil instalar un programa completo por que los mecanismos estándar para ello ya existen.
• La complejidad de dependencias entre el nuevo software y la infraestructura de IT; cuánto más fácil sea aislar el software, más fácil es probarlo.
Es de gran importancia evaluar el número de ajustes que se pueden probar todos juntos por adelantado en un cierto tiempo, una Difusión Empaquetada (agrupación de cambios diferentes en un solo despliegue) puede ser tan compleja que nunca pase la fase de prueba. Como resultado del rápido desarrollo del nuevo software, la nueva Difusión puede que ya no esté actualizada para cuando sea difundida. Por otro lado, una gran cantidad de ajustes puede resultar en grandes molestias para el servicio.
Numeración de Versiones - asegura que cada difusión tenga asignada un número de difusión para que pueda ser identificada de forma única. Debería haber una frecuencia de difusión bien publicitada y predecible y un límite acordado para el contenido de cambio. Los requisitos de negocio deberían ser el factor determinante más que la conveniencia técnica. Las especificaciones se deberían congelar con suficiente adelanto de la fecha de difusión para permitir pruebas suficientes.
Versión Completa — significa que el programa entero se distribuirá una vez más, incluidas las partes que no están presentes.
Versión Delta — en matemáticas, “Delta” significa “diferencia”, es una difusión de ese software que ha sido ajustado exclusivamente. Esto frecuentemente trata de una solución de urgencia o un “Arreglo Rápido”.
Versión Empaquetada — Con una Difusión Empaquetada se enfatizan periodos de estabilidad más largos para los usuarios.
Versión Urgente — una Difusión Urgente ocurre cuando hay una razón urgente para desplegar una nueva versión. Una Difusión Urgente es un ajuste urgente y se lleva a cabo en nombre de la Dirección de Cambio. Normalmente trata de una versión Delta.
Despliegue y Distribución de Software
Los procedimientos se deben programar para la distribución de difusiones de software del entorno de construcción de prueba al entorno de prueba, al entorno vivo de construcción y al entorno productivo vivo. Debería incluir detalles puntuales de cuándo un número de usuarios debe usar la misma versión en varios lugares. El registro de difusión en la CMDB se debe actualizar a lo largo de la implementación de las difusiones. Aparte del entorno técnico, el entorno de negocio también influye, particularmente si 24x7 se desarrolla a escala global.
A fin de mantener una buena política de distribución, las nuevas versiones de software se deberían programar con mucha anticipación. Algunas veces, los errores sólo ocurren cuando una nueva versión ya se ha llevado a la explotación. En este caso, es muy importante que un buen procedimiento de Fail Back esté presente para que una versión archivada se pueda utilizar inmediatamente. Esta también es una razón por la que un Back up de la DSL debe ocurrir frecuentemente.
Antes de cada despliegue, es importante que un plan de distribución e implementación se haga. En este plan, se deben considerar el impacto para los usuarios y las fuentes necesarias.
41
Informes de Gestión
Se deben monitorear un número de indicadores de rendimiento claves (KPI’s) para evaluar la efectividad del proceso de Gestión de Difusión. Elegir algunas medidas que muestran un claro indicativo de lo siguiente:
• Difusiones construidas e implementadas según programa, y dentro de los recursos presupuestados
• Un número muy bajo (de forma ideal ninguna) de Incidencias de Difusiones que se han tenido que retroceder debido a errores inaceptables
• Baja incidencia de fallos de construcción • Gestión segura y precisa de la DSL • Ninguna evidencia de software en la DSL que no ha pasado las
comprobaciones de calidad y ninguna evidencia de retoques en cualquier software extraído de la DSL
• Tamaño de la DSL de acuerdo con la demanda de espacio y mantenimiento preciso y puntual de la DSL
• Cumplimiento de todas las restricciones legales relacionadas con el software comprado
• Distribución precisa de Difusiones a lugares remotos • Implementación puntual de Difusiones a todos los lugares, incluidos los
remotos • Ninguna evidencia de reversión no autorizada a versiones anteriores en
ninguna ubicación • Ninguna evidencia del uso de software no autorizado en ninguna ubicación • Ninguna evidencia del pago de multas de licencia o esfuerzo de
mantenimiento malgastado, por software que no está actualmente en uso en ninguna ubicación
• Registro puntual y preciso de toda actividad de construcción, distribución e implementación dentro de la CMDB
• Un post mortem desarrollado sobre todas las actividades de Difusión y todas las acciones correctivas o de seguimiento necesarias realizadas, junto con cualquier mejora de proceso
• La composición programada de Difusiones de acuerdo con la composición actual
• Recursos de IT y humanos requeridos por la Gestión de Difusión siendo sujetos a buena programación por adelantado
Otras medidas que se pueden monitorizar incluyen:
• El número de Difusiones mayores y menores por periodo de informe • El número de Problemas en un entorno vivo que se pueden atribuir a nuevas
difusiones, que sólo necesitan ser medidos durante los primeros meses de vida de una difusión, clasificados por su causa de raíz (p.ej. ‘versión errónea en expediente”, o “falta expediente”)
• El número de objetos nuevos, cambiados o eliminados introducidos por la nueva difusión- p.ej. cuántos módulos y programas
• El número de Difusiones completadas en el horario acordado; esto requiere la función de Gestión de Difusión central para publicar objetivos predefinidos (niveles de servicio o SLA’s) para distribuciones de software y otras tareas comunes.
Está prohibida la difusión, transmisión, modificación, copia, reproducción y/o distribución total o parcial del presente Documento, en cualquier forma y por cualquier medio, sin la previa autorización escrita del autor, encontrándose protegidos por las Leyes de Derecho de Autor, Marcas, Lealtad Comercial, Bases de Datos y otras normas Asimismo, queda prohibido cualquier uso de los Documentos o parte de los mismos con fines comerciales. La violación de los derechos antes señalados puede acarrear condenas civiles y/o penales establecidas en las normas precedentemente citadas. Se exigirán responsabilidades a los infractores por todas las vías disponibles en derecho. Fecha y lugar de publicación: Buenos Aires, Noviembre de 2008. Queda hecho el depósito que establece la Ley 11.723.
