Serie Artículos sobre Gestión de IT y Calidad INTRODUCCIÓN A ITIL Segunda Parte 1
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 : Change Management Release Incident Service Management Management Support Service Level Management Financial Availability Service Management Management Delivery Configuration Management Problem Management IT Service Continuity Management Capacity Management 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 2
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 3
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 nourgentes, tales como: Adquisición de productos Consultas de aplicación 4
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: 5
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? 6
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 7
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. 8
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 9
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 10
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 11
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: 12
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 13
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 14
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. 15
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 proactiva 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 16
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) 17
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. 18
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. 19
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) 20