Unidad 6 Operación del Servicio... 2 6.1 Introducción y Objetivos... 2 6.2 Gestión de Incidencias.... 2 6.3 Gestión de Problemas.... 12 6.4 Gestión de Eventos... 15 6.5 Gestión de Peticiones.... 17 6.6 Gestión de Acceso.... 19 6.7 Centro de Servicio al Usuario.... 21 6.8 Gestión Técnica.... 24 6.9 Gestión de Aplicaciones.... 27 6.10 Gestión de Operaciones de TI.... 28
Unidad 6 Operación del Servicio 6.1 Introducción y Objetivos La fase de Operación del Servicio es una de las más importantes debido a su alta criticidad. La operación del servicio en ITIL y sus procesos asociados se identifican como buenas prácticas, y permiten que la organización pueda asegurar que los servicios se prestan de manera eficaz y eficiente. Es la fase que está en mayor contacto con el usuario final. La fase de Operación del servicio está preparada para acometer las nuevas entregas para su operación, así como para tratar los casos de resolución de los correctivos de las entregas. Los principales objetivos de la fase de Operación del Servicio incluyen: Garantizar que las actividades y funciones necesarias para la prestación de los servicios acordados es correcta y acorde a los niveles de calidad aprobados. Gestionar la infraestructura TI necesaria para la prestación del servicio. Dar soporte a los usuarios del servicio. La asignación de recursos, formación y capacidad tecnológica es vital para el servicio. Gestión de Incidencias. Gestión de Peticiones. Gestión de Problemas. Gestión de Eventos. Gestión de Accesos. 6.2 Gestión de Incidencias. Conceptos: SLAs: (Service license agreeitment)
Objetivos: La Gestión de Incidencias tiene como objetivo garantizar la resolución eficaz y eficiente de cualquier incidente que cause una degradación en el servicio. Registrar y clasificar las incidencias del servicio TI. Detectar y corregir cualquier incidencia en el servicio TI. Asignar los recursos para restaurar el servicio acordes con los SLAs establecidos. Coordinación total con el Centro de Servicios. Una incorrecta utilización de la gestión de Incidencias, conlleva a la degradación del servicio, Mala asignación de recursos, pérdida de información y descontento del cliente/usuario. Beneficios: Asegurar la calidad del servicio. Control y monitorización del proceso en el servicio. Mejorar la productividad de los usuarios. Cumplimiento de los niveles de servicio. Optimización de los recursos disponibles. Registro de las incidencias en la CMDB con su relación con el CI afectado. Cumplimiento y mejora de la satisfacción del cliente/usuario. Dificultades: Registro inadecuado = Conocimientos no actualizados. No seguir los procedimientos establecidos. Registro inadecuado y sin nivel de detalle de las incidencias. El siguiente diagrama resume el proceso de Gestión de Incidencias:
Todas las incidencias deben aglutinarse en el primer nivel HelpDesk, aquí se procederá a la resolución. Si el grupo no pudiese resolver esta incidencia en este nivel, bien por conocimientos, bien por otro tipo de necesidades procedería a escalar la incidencia a un siguiente nivel donde los tecnicos de Gestión Remota, donde se procedería a la resolución de la incidencia, si aún así el grupo al que se escalo esta incidencia no es capaz de darle solución, se escalaría al siguiente nivel. Es posible que la incidencia, dependa de una petición para la solución y esto lo veremos en el Proceso de Gestión del cambio. También es posible que la incidencia genere un problema y que sea el Proceso de Gestión de Problemas el que se encarge de la resolución de la incidencia. En el siguiente diagrama, vemos los procesos implicados dentro del Flujo para el tratamiento de las incidencias. Tipificación y configuración: Aunque ITIL deja abierta la puerta para la configuración de los tipos de casos, nosotros los vamos a definir como 3 tipos: Incidencia. Petición. Consulta Tipificación de la incidencia: Es necesaria una correcta tipificación de los casos con los suficientes niveles de categorización. Podríamos dividirlos en: CATEGORIA: Determinamos tratamos con Hardware o Software SUBCATEGORIA: Determinamos si tratamos con Informatica, comunicaciones, infraestructura etc.
PRODUCTO: Determinamos si tratamos con Software Windows, Portátiles, Routers, centralitas, impresoras, etc. En este nivel debería asignarse automáticamente el Grupo que va a tratar el caso. PROBLEMA. Determinamos el tipo de incidencia, petición o consulta que afecta, Ej. Problema con correo electrónico. Las asignaciones automáticas nos aseguran una máxima fiabilidad en los datos. Tipificación de grupos: El previo análisis y estructuración de La tipificación de los grupos es un arma indispensable para utilizar a la hora de tipificar correcta y automáticamente una incidencia. Dependiendo de la tipificación que asignemos a la incidencia, tambien el grupo debería asignarse automáticamente. Esta asignación automática del grupo tras la tipificación, evitará errores de escalado y de asignación de casos. Este es ejemplo de tipificación automática. Una vez que el caso está asignado a un grupo, el estado del caso pasa a estar ASIGNADO. Esta asignación, también tiene que ser automática en el momento del cambio del estado del caso. Impacto, Urgencia y Prioridad: El impacto y la urgencia, van a determinar la prioridad del caso. Es muy importante que el cálculo sea automático y predefinido posteriormente a su análisis. Cálculos de Prioridad: Impacto Muy Alto + urgencia Muy Alta: PRIORIDAD CRITICA Impacto Alto + urgencia Alta: PRIORIDAD ALTA Impacto Medio + urgencia Alta: PRIORIDAD ALTA Impacto Alto + urgencia Medio: PRIORIDAD ALTA Impacto Medio + urgencia Alta: PRIORIDAD ALTA Impacto Medio + urgencia Media: PRIORIDAD MEDIA
Impacto baja + urgencia Media: PRIORIDAD MEDIA Impacto Media + urgencia Baja: PRIORIDAD MEDIA Impacto baja + urgencia baja: PRIORIDAD BAJA Categorías de CIs: Esta funcionalidad tiene como objeto identificar, controlar y mantener la información referente a los equipos objeto de gestión del servicio, optimizando la Gestión de Incidencias, de manera que solamente se puedan abrir incidencias sobre los equipos, determinando las prioridades de estos a través de los SLA acordados para cada uno de ellos. La posibilidad de seleccionar el CI en la incidencia, nos posibilita la interrelación directa con la Gestión de la configuración. Tipo de CI: Estación de trabajo, Comunicaciones etc. Subtipo de CI: Portátil, Router etc. Estado del CI: Activo, Inactivo, EN revisión etc. Estado del CI: En los CI a seleccionar, debe haber del tipo No aplica y No disponible. Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados, aplicando el estado RETIRADO en ese CI o componente. Se proponen desarrollos en las herramienta de Gestión para que en la pestaña de inventario se pueda seleccionar un CI, previamente categorizado el tipo, el subtipo y el estado. Todos estos datos, deben ser leidos automáticamente de la CMDB, una vez seleccionado el CI. Estos desarrollos ampliarán las posibilidades de la Gestión de la configuración y de la integración con otros sistemas. También otorgara la posibilidad de Gestiónar SLA independientes de cada CI, si previamente se ha categorizado tambien este dato. Este es un ejemplo: En este nuevo flujo de estados, estamos contemplando la posibilidad de que cualquier
modificación de estados o modificación de las tipificaciones del caso, sean automáticas. Nuevo caso: Se abre un nuevo caso. Puede ser una Incidencia, Petición o Consulta. Asignación a un grupo de trabajo: La asignación del grupo de trabajo. Esta asignación debe producirse de forma automática, tras la tipificación del caso. Previamente habrá que haber modificado los desarrollos actuales de la herramienta para que esta asignación sea automática. Ejemplo: Cuando tipificamos un caso, por ejemplo una Incidencia con la tipificación: Categoría: Software. Subcategoría: Corporativo. Tipo de Producto: Correo Electrónico. Tipo de Problema: Error en el acceso. En el momento en el que hemos seleccionado el Tipo de Problema, que sería nuestro tercer nivel de tipificación, automáticamente se habrá asignado el Grupo que deba tratar esta incidencia. Si durante el ciclo de vida del caso, se necesita elevar el caso a otro nivel superior, este debe modificar las tipificaciones del caso, si fuese necesario un cambio de grupo. Todas estas modificaciones deben quedar reflejadas en el histórico del caso, pudiéndonos utilizar a la hora de solicitar informes. Modificación del Estado: El estado inicial será el estado Asignado, y se tiene que asignar el grupo que va a tratar la incidencia. Esta asignación de grupo se producirá automáticamente en el momento en el que se ha tipificado el caso, tal y como expusimos en el punto anterior. Parada de caso: En este estado para automáticamente el reloj interno. De esta forma podremos saber cuanto tiempo se ha invertido desde que se asigna un grupo, hasta que se asigna el técnico de ese grupo. Modificación de estado: El estado del caso debe figurar como Parado tras la especificación de un motivo obligatorio. Reactivación de caso: El caso vuelve a cambiar a Asignado, tras la especificación del motivo obligatorio por el cual se reactiva, volviendo a funcionar el reloj de tiempo. Asignación de técnico: Se asigna un técnico del grupo que Gestiónará el caso. Esta asignación si que es manual, seleccionando un técnico de los que pertenecen a ese grupo. Modificación de estado: En el momento en que el técnico ha sido asignado, el estado del caso es En proceso.
Envío de OT: Orden de trabajo. Parada de caso: En este estado para automáticamente el reloj interno. De esta forma podremos saber cuanto tiempo se ha invertido desde que se asigna un grupo, hasta que se asigna el técnico de ese grupo. Modificación de estado: El estado del caso debe figurar como Parado tras la especificación de un motivo obligatorio. Reactivación de caso: El caso vuelve a cambiar a En proceso, tras la especificación del motivo obligatorio por el cual se reactiva, volviendo a funcionar el reloj de tiempo. Reclamación de caso: Se reclamará un caso que esté en proceso, y su demora exceda los tiempos marcados en los SLA. Actualización de caso: En cualquier momento del ciclo de vida del caso, se podrá actualizar con información, y debe quedar reflejado en el Histórico del caso. Resolución de caso: En el momento de tener una solución, aplicarla, y solucionar el caso, detallaremos la solución, con el máximo de información posible. Tras completar los datos obligatorios para la solución, el estado cambia a Resuelto. En este momento el reloj de tiempo SLA parará, sumando y restando todos los tiempos que se aplican a este caso. Modificación de estado: Estado Resuelto. Reclamación de caso: Es posible que una vez aplicada la solución, esta no sea acertada y no haya solucionado el problema. El usuario puede reclamar el caso, y con esto volveríamos al estado En Proceso. En este momento el reloj SLA vuelve a ponerse en marcha, añadiendo los nuevos tiempos a los antiguos de resolución. Es decir se sumarán este nuevo tiempo hasta que se solucione totalmente el caso. En este momento y tras cumplimentar de nuevo los datos necesarios, el caso vuelve al estado Resuelto. Cierre de caso: El operador cierra el caso, una vez conforme el usuario con la solución. Cierre Manual. El caso pasa al estado Cerrado. Cierre de caso: El caso se cierra automáticamente tras unos días acordados. El caso pasa al estado Cerrado. Este es el cierre administrativo del caso. Modificación de estado: Estado Cerrado. Queja sobre el caso: Si aún así, y después de dar por valida una solución, el problema volviese a generarse, el usuario podrá enviar una queja. Esta queja, abrirá otro caso nuevo, relacionado con el caso anterior que se cerró y que no se había solucionado. En este caso los tiempos SLA del caso previo, deberían trasferirse al nuevo caso.
Escalados: Existen 2 tipos de escalados: Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema. Es un escalado de conocimientos. Escalado jerárquico: Se acude a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico. Es un escalado de gestión. En la siguiente ilustración, podemos consultar los flujos de escalados ITIL. Debe existir la posibilidad de definir SLA a la hora de crear nuevos usuarios, y nuevos CIs. Debemos definir tres tipos de SLA. Un SLA de CI: Si hemos seleccionado un CI el SLA asociado a este, prevalecerá ante cualquier otro SLA definido. Un SLA del contacto: SI no tenemos un CI que seleccionar a la hora de dar alta al caso, el SLA que medirá los tiempos Será el definido para el contacto.
UN SLA Generico: Si el contacto no tiene definido ningún SLA, este sera el SLA que medirá los tiempos de actuación. La Prioridad se basará en el cálculo del impacto por la urgencia. Este cálculo debe ser automático para evitar errores humanos en los cálculos. Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados. Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA. Resoluciones y cierres: Con la ayuda de la base de datos de conocimientos (SKMS), comparamos y analizamos si existe algún caso con la misma incidencia. Durante todo el ciclo de vida del incidente se debe actualizar la información en todos los repositorios existentes y que pueden ser consultados por los diferentes recursos implicados en el proceso. Una vez solucionado el caso: Comunicación a los usuarios por el procedimiento establecido. Registro de resolución en SKMS. Actualiza la información en la CMDB sobre los elementos de configuración (CIs) implicados en el incidente. Cierra de la incidencia.
Flujo de estado completo de una incidencia: Métricas: Número de incidencias clasificadas, por tipificación, tipo o nivel de escalado si lo hubiese. Tiempos de respuesta y resolución clasificados en función del impacto y la urgencia de los incidentes. Clasificación por fecha y prioridad. Costes asociados. Recursos asignados del Centro de Servicios. Grado de satisfacción del cliente.
6.3 Gestión de Problemas. Conceptos: Workaround: Solución temporal, hasta encontrar la solución definitiva. Urgencia: demora aceptable para la solución de un caso Impacto: Grado de deterioro de la calidad del servicio PIR: Revisiones Post-Implementación. La Gestión de Problemas puede ser: Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos. Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que éstos ocurran. Cuando una incidencia se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI, es el proceso de Gestión de Problemas el que determina las causas para encontrar posibles soluciones. Problema: causa aún no identificada, de una serie de incidencias o una incidencia aislada de importancia significativa. Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas. Objetivo: El objetivo principal de la gestión de problemas es investigar y analizar los problemas que afectan al servicio. Determinar las causas de una alteración en la Infraestructura TI o Servicio y aplicar Workarounds hasta encontrar la solución definitiva. Entre las funciones principales de la Gestión de Problemas figuran: Beneficios: Un aumento de la calidad de los servicios TI. Minimiza el número de incidencias. Solución de incidencias en el primer nivel de soporte. Ahorro de costes Aporta documentación vital para el resto de procesos ITIL Dificultades:
Problemas de colaboración, coordinación entre las áreas para aportar la mayor información sobre las causas de un problema. Nivel de detalle de las incidencias que proponen un problema. Nivel de detalle del escaso, por parte del operador, del propio problema. Aumento de los costes por la contratación de personal especializado, escalados. Procedimiento: Las funciones principales de la Gestión de Problemas son: Identificar, registrar y clasificar los problemas. Dar soporte a la Gestión de Incidencias, proporcionando información y soluciones temporales o parches. Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto, aportando conocimiento. Analizar problemas potenciales para prevenir incidencias potenciales. Investigar las causas de la degradación, real o potencial, del servicio TI. Aportar posibles soluciones a las mismas. Proponer RFCs para restablecer la calidad del servicio. Revisiones Post-Implementación (PIR) para asegurar que los cambios solucionan el problema sin afectar a otras partes o software de la infraestructura TI. Registro: Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales, informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI. Una de las tareas funcdamentales del proceso es encontrar los problemas y para ello, se basa en: La BBDD de Incidencias: Analizando una degradación de un servicio: Analizando la infraestructura TI. El registro de problemas es, se detalla dependiendo de su naturaleza y posible impacto, aportando la siguiente información: Estado: activo, error conocido, cerrado. Niveles de prioridad, urgencia e impacto. Síntomas asociados. Los CIs implicados. Servicios involucrados. Causas del problema. Origen del problema.
Incidencias adjuntas al problema. Soluciones temporales. Clasificación: Es un problema de hardware o software? Qué áreas funcionales se ven afectadas? Qué CIs están afectados? Para determinar la prioridad, utilizaremos la misma fórmula que en la Gestión de Incidencias: Prioridad: urgencia x impacto La prioridad, podría variar, dependiendo de si los Workaround aplicados han reducido el impacto del problema. Una vez clasificado el problema y determinada su prioridad, se deben asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que la resolución en el mínimo tiempo posible. Análisis: Un problema puede ser causado entre otros por: Errores procedimentales. Descoordinación entre diferentes áreas. Documentación de baja calidad Un problema de HW o SW. Errores humanos. Los objetivos principales del análisis son: Determinar las causas del problema. Determinar la fuente del problema. Proporcionar soluciones temporales a la Gestión de Incidencias para minimizar el impacto del mismo hasta que se implementen los cambios necesarios que lo resuelvan por completo. Una vez determinadas las causas del problema, fuente del problema y aplicado el workaround, se convierte en un Error Conocido y se remite al proceso para su posterior procesamiento. Métricas: Informes de rendimiento Informes de Gestión reactiva y proactiva
Informe de calidad del servicio Relaciones con otros procesos de ITIL: Gestión de niveles de servicio: Gestión de Incidencias Gestión de la disponibilidad Gestión de cambios Gestión de la continuidad 6.4 Gestión de Eventos. Conceptos: Evento/Alerta: Suceso que detecta un signo importante en la Infraestructura TI o servicio. SNMP:(Simple Network Management Protocol). Triggers: Disparadores de automatizaciones. Objetivos: El principal objetivo de la Gestión de Eventos, en su función de monitorizar todos los sucesos, así como la monitorización del Servicio para prevenir los posibles problemas. Existen dos tipos de monitorización: Monitorización activa. La herramienta de monitorización genera una alerta cuando detecta un problema en un CI y la envía al grupo asignado. Monitorización pasiva. La herramienta de monitorización detecta alertas operacionales generadas por los propios CIs. Tipos de alerta: No solo existen alertas cuando se detectan problemas en los CIs. También se puede generar una alerta automática que nos avise del buen funcionamiento del CI del Servicio. Alertas que Indican que el servicio está operando con normalidad. Alertas que indican un problema. Alertas que indican un signo ocasional, y que requieren una monitorización especifica. Este proceso, puede ser el encargado de clasificar y analizar el impacto del origen de la alerta, y derivarlo a los procesos de Gestión de Incidencias o Gestión de Problemas para su estudio y resolución.
Beneficios: Detección de signos de posible incidencia, llegando a evitar la degradación del Servicio. La coordinación con otros procesos hace posible una mayor eficiencia de toda la organización TI. Monitorización automatizada de actividades, generando alertas que se envían al grupo correspondiente para su análisis, a través del correo electrónico. Dificultades: Costes en Herramientas y formación. Dificultad de configuración de automatizaciones. Falta de compromiso entre las áreas. Procedimiento: Fase 1: El flujo de trabajo, comienza cuando se detecta un signo o suceso en la infraestructura TI, un elemento de ella o del Servicio. Fase 2: Las notificaciones de eventos en su mayoría, emplean el estándar SNMP (Simple Network Management Protocol). Fase 3: Análisis de la alerta. Dependiendo de lo detallado en la notificación, será más sencillo que llegue al grupo adecuado para su estudio y/o resolución. Fase 4: Se clasifican los eventos. Estos pueden ser: Fase 5: Informativos. Alertas. Excepciones. En esta fase se estudia la importancia del evento.
Elementos de configuración (CIs) que generan eventos similares. Acción asociada al evento. Eventos similares registrados con anterioridad. Información que se detalla. Nivel de prioridad asignado al evento. Fase 6: Los triggers son importantes para el registro del evento en el proceso correspondiente para su estudio y/o resolución. En esta fase se estudia la importancia del evento. Los Triggers, crean un registro en el Sistema de Gestión de Incidencias, una RFC en el proceso de gestión de cambios, un sms a un móvil, una notificación de aviso, etc. Registro del evento y cierre. Métricas: Eventos redundantes. Número de eventos filtrados por categoría. Número de eventos, filtrados según su importancia. Eventos que registraron una nueva incidencia o solicitud de cambio. Número de eventos automatizados o de acción humana. Relaciones con otros procesos de ITIL: Gestión de niveles de servicio: Gestión de Incidencias Gestión de la disponibilidad Gestión de cambios 6.5 Gestión de Peticiones. Es la encargada de atender las peticiones de los usuarios de la organización TI. Las peticiones pueden ser: Peticiones de consultas. Peticiones de cambios. Peticiones de Acceso.
Las peticiones pueden generar un beneficio en adquisición de bolsa de peticiones por parte de los usuario y/o clientes. Conceptos: Objetivos: Atender y gestionar las peticiones de usuarios y/o clientes de la Infraestructura o Servicio IT. Beneficios: Procedimientos de solicitudes. Interfaz gráfico de ayuda para los usuarios. Canal de comunicación cliente/operaciones. Ayudar a resolver consultas o comentarios ofreciendo información general. Dificultades: Definir las bolsas de peticiones. Desarrollo de Autoayudas. Coste de la herramienta o funcionalidad (desarrollo) de acceso a peticiones. Descoordinación entre las áreas. Responsabilidad difusa del proceso. Procedimiento: La Petición, podría estar incluida en la propia herramienta Service Desk, como un tipo de caso. Aun así, conociendo su estrecha relación con el proceso de Gestión de incidencias, es importante dar a conocer al usuario y/o cliente la diferencia notable entre las dos. Selección de peticiones: Los usuarios, a través de las herramientas destinadas por la Gestión de Peticiones, emiten sus peticiones conforme a una serie de tipificaciones predefinidas. Aprobación financiera de la petición: Se considera su coste y se decide si tramitar la petición o no. Tramitación. La petición es cursada por la persona o personas responsables e inmiscuidas en el proceso.
Cierre. Tras notificar al Centro de Servicios conocer la satisfacción del cliente y proceder a su cierre. Métricas: Prioridad de la Petición. Número total de peticiones. Bolsa de peticiones contratada por el usuario y/o cliente. Coste medio de cada tipo de petición de servicio. Peticiones cursadas y no cursadas. Tipos de peticiones. Peticiones de servicio satisfechas en los tiempos acordados. Nivel de satisfacción del cliente con la gestión de las peticiones de servicio. Relaciones con otros procesos de ITIL: Gestión de niveles de servicio: Gestión de Incidencias Gestión de la disponibilidad Gestión de cambios 6.6 Gestión de Acceso. La Gestión de Acceso a los Servicios TI es la encargada de proporcionar los permisos necesarios para hacer uso de los servicios de la organización TI. También llamada Gestión de identidades. La Gestión de identidades a los Servicios TI esta relacionada con la fase de diseño a través de la Gestión de seguridad y el Catálogo de servicios. La Gestión de identidades a los Servicios TI esta relacionada con la fase de operación a través de la Gestión de peticiones y el Centro de servicios, Gestión de incidencias y Gestión de aplicaciones. Conceptos: Objetivos: El objetivo de la Gestión de Acceso a los Servicios TI es proporcionar permisos de acceso a los servicios a aquellos usuarios autorizados e impedírselo a los usuarios no autorizados. Son las buenas práctica de las políticas y acciones definidas en la Gestión de la Seguridad y la Gestión de la Disponibilidad.
Beneficios: Confidencialidad de la Información. Minimizar los conflictos y problemas derivados de la asignación de permisos. Capacidad de monitorización. Mayor rapidez y eficacia al desactivar permisos. Adecuación a los estándares de calidad. Dificultades: Análisis de los permisos. Mal diseño de los permisos en fases previas. Gestionar el acceso. Actualización de la BBDD. Procedimiento: Petición de acceso: Puede llegar a través (de la herramienta para tal fin) de un usuario, o un departamento, o puede ser una tarea automatizada. Verificación del usuario: Se comprueba la identidad de la persona que solicita el acceso, así como la de los que lo autorizan. Se analiza la solicitud y se proporciona acceso si se cree conveniente. Monitorización de identidad: Se monitorizan las solicitudes para recoger posteriormente las posibles métricas. Registro y monitorización del acceso: Asegurar que los permisos que han proporcionado se están usando apropiadamente. Restricción de acceso: Se elimina el acceso al servicio. Las causas podrían ser por baja en la Organización, despido, cambio de departamento. Etc.
Métricas: Número de peticiones de acceso dependiendo del tipo de acceso. Acceso por servicio. Fecha de acceso. Consecuencias de la eliminación de los permisos de acceso. Consecuencias de una configuración incorrecta de los accesos. Relaciones con otros procesos de ITIL: Gestión de seguridad. El Catálogo de servicios. Gestión de peticiones. Gestión de incidencias. Gestión de aplicaciones. 6.7 Función: Centro de Servicio al Usuario. El Centro de Servicios sirve de punto de contacto entre los usuarios y la Organización TI. Es el centro de todos los procesos de soporte al servicio: Registrando, actualizando y resolviendo casos. Parando los casos; Por ejemplo hasta la llegada del material. Cerrando los casos. Asistiendo a las reclamaciones. Asistiendo a las quejas. Satisfaciendo las consultas. Conceptos: 24/7: Conocido como Siguiendo al sol(follow the sun)
Objetivos: Dar soporte al servicio, de alta calidad, eficiente e independiente de su localización geográfica. Ofreciendo una una atención personalizada y ágil a los usuarios y/o clientes. Tipos de centros de servicio: Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios. Centro de Soporte (Help Desk): También considerado como Nivel 0. El objetivo es que los casos queden solventados en esta primera línea. Centro de Servicios (Service Desk): Enfocado a dar solución a las posibles interrupciones de un servicio. El centro de servicios a su vez, ofrece servicios a sus clientes, usuarios y la propia organización TI centralizando todos los procesos asociados a la gestión TI. Beneficios: Soporte al Servicio. Reducción de costes. Calidad y fidelización de los clientes y/o usuarios. Mejor gestión de la Información y de la comunicación. Procedimiento y planificación: El centro de servicios debe estar alineado con las necesidades de la organización TI. Se tendrán que implementar los requisitos previamente establecidos para su implementación. Se deben tener en cuenta: Estructura del Centro de Servicios. Necesidades. Responsables. Funciones. Métricas. Formación de los técnicos. Herramientas necesarias. Procedimientos. Comunicación. Encuestas de satisfacción y sondeos. Tipos de estructura: Estructura lógica:
Los integrantes del Centro de Servicios deben conocer la organización TI, poseer los permisos adecuados para realizar su función, así como recibir la formación adecuada. Estructura Física: Local: Situado en la misma ubicación de los clientes y/o usuarios. Beneficios: Mejor comunicación. Mejor trato humano directo. Soporte Insitu. Inconvenientes: Más coste. No justificación del recurso contratado. Centralizado: Contacto con los usuarios a través de una sola estructura central. Beneficios: Se reducen los costes. Se optimizan los recursos. Se simplifica la gestión. Inconvenientes: Lengua Degradación de la comunicación Virtual: Centro que da soporte en cualquier situación geográfica. Beneficios: Conocimiento centralizado. Ahorro de costes La calidad del servicio es homogénea y consistente. Inconvenientes: Poco trato humano. Problemas de comunicación.
Asignación de recursos errónea. 24/7: Conocido como Siguiendo al sol (follow the sun) Métricas: Centros de Servicios Locales en distintas zonas horarias con el fin de cubrir de forma conjunta las 24 horas del día durante los 7 días de la semana. Esta configuración es adoptada por casi todas las organizaciones de TI cuyos servicios no dejan de funcionar los 365 días del año. Porcentaje de casos que se cierran en nivel 0. Tiempo medio de respuesta a casos cursados por correo electrónico y teléfono o fax. Tiempos de resolución de cosos según su urgencia e impacto. Porcentaje de consultas respondidas en primera instancia. Cumplimiento de los SLAs. Número de casos gestionados por cada técnico. Relaciones con otros procesos de ITIL: El Catálogo de servicios. Gestión de peticiones. Gestión de incidencias. Gestión de Problemas. Gestión de cambios. 6.8 Función: Gestión Técnica. Es la encargada de gestionar la aportación de habilidades técnicas y los recursos necesarios para soportar la fase de Operación del servicio. Esta función, podría tomar parte en otras fases de los servicios TI si estos lo requieren. Es la responsable del conocimiento técnico. Proporciona los recursos para dar soporte al ciclo de vida. Su estructura dependerá de las dimensiones de la organización. Es una estructura de especialización. Si hablamos de una compañía pequeña, toda la función se estructurará y desarrollará en un departamento grupal. Si hablamos de Empresas grandes, podrían crearse departamentos dependiendo de las habilidades técnicas. Algunos ejemplos de equipos o departamentos de Gestión Técnica:
Departamento técnico central Departamento técnico de base de datos Departamento técnico de almacenamiento de datos Departamento técnico de Sistemas distribuidos Departamento técnico de soporte a redes Departamento técnico de aplicaciones de escritorio Conceptos: Outsourcing: Subcontratar. KEDB: Base de datos de Errores conocidos. Objetivos: El objetivo principal de la función consiste en colaborar en la planificación, implementación y mantenimiento de una infraestructura técnica par que sea estable, apoyar a los procesos de negocio de la organización y colaborar en la documentación. Debe proporcionar las habilidades técnicas para asistir cualquier degradación técnica del servicio, y prestar apoyo al resto de procesos de operaciones. Procedimiento: La Función técnica, se encargará de seleccionar los recursos con habilidades específicas. Equilibrará el coste / habilidad / desempeño, de manera que cada recurso contratado, se emplee el máximo posible sacando así el máximo partido del recurso. Si en algún caso existen picos de trabajo, se encargará de contratar el servicio de un tercero (Outsourcing) para solventar ese pico. Función: Formación: Técnica a los usuarios, al Centro de servicios, y otras formaciones necesarias en cualquier proceso del ciclo de vida del servicio. Búsqueda y detección del conocimiento: Documentando las habilidades de la Organización IT y valorando las necesidades formativas.
Asesoría en contratación: La función técnica, puede colaborar en la contratación de perfiles necesarios para la Organización IT. Estándares: Participará en el diseño de nuevas arquitecturas, y en la definición de las mismas durante las fases de Estrategia y Diseño del Servicio. Nuevos Servicios: Participará en la creación de nuevos servicios. Conocimiento. La función técnica, pone el conocimiento al servicio de la Organización: Identificando el coste de la tecnología y los recursos humanos que intervienen en la prestación de servicios. En la Gestión de Problemas, ayuda a diagnosticarlos y resolverlos. Contribuye mantener el KEDB (Base de datos de Errores conocidos). En la Gestión de Incidencias, los equipos de la función Técnica participan como línea de soporte de conocimiento especializado. Colaboran en la definición de los casos de escalado. En la Gestión de Cambios, evalúan las RFCs. En la Gestión de la configuración, aseguran que se creen los atributos y relaciones correctas entre CIs, tanto en la implementación, como en el evolutivo del proceso. Ayuda a identificar oportunidades de mejora. Actualiza la documentación. Métricas: Rendimiento de la tecnología. Tiempo promedio entre incidencias de determinado equipamiento. Número de incidentes escalados y razones para esos escalados. Número de cambios implementados y retirados. Número de cambios no autorizados detectados. Medición de las actividades de mantenimiento. Formación y desarrollo de habilidades. Apoyo a logros para el negocio. Porcentajes de transacción y disponibilidad en transacciones de negocio críticas. Formación del Centro de Servicios. Resolución de problemas en la KEDB. Mediciones de la calidad de los entregables. Instalación y configuración de componentes. Tiempos de respuesta medios a eventos. Tiempos de resolución de incidentes en segunda y tercera líneas de soporte. Estadísticas de resolución de problemas. Relaciones con otros procesos de ITIL:
Esta función presta apoyo a todos los procesos ITIL 6.9 Función: Gestión de Aplicaciones. Es responsable del soporte y mantenimiento de las aplicaciones utilizadas en la Operación del servicio. Es la responsable del conocimiento técnico y la experiencia en las aplicaciones. Proporciona los recursos destinados a dar soporte al proceso. Diseño, prueba y mejora de las aplicaciones. Evolucionar una aplicación o adquirirla a un proveedor. Conceptos: Objetivos: Identificar los requisitos funcionales del software de aplicaciones, diseño y evolución de dichas aplicaciones y colaborar en el soporte y evolutivos de mejora tras su implementación. Se encargará de: Garantizar las funcionalidades de los aplicativos. Identificar aplicaciones bien diseñadas que optimicen costes. Mantener el equilibrio entre los recursos y su coste. Obtener las habilidades técnicas para que los aplicativos rindan el nivel más optimo. Para su implementación, se debe tener en cuenta el objetivo del aplicativo y que los equipos conozcan los objetivos marcados por el negocio. También hay que tener en cuenta la funcionalidad, tecnología y plataformas empleadas. Existen muchos tipos de aplicativos, que podrían dividirse por departamentos. Estos son algunos ejemplos: Aplicativos financieros. Aplicativos de mensajería y colaboración. Aplicativos de RRHH Aplicativos de soporte industrial Aplicativos de automatización de fuerza de ventas (CRM) Aplicativos de procesamiento de ventas. Aplicativos del centro de llamadas y marketing Aplicativos específicas del negocio (sanidad, seguros, banca, etc.) Portal web. Tienda online. Aplicativos TI: ServiceDesk.
Función: Ayudar a la Gestión Técnica a identificar el conocimiento y experiencia necesarios para gestionar los aplicativos. Diseñar y Evolucionar programas formativos destinados al usuario final Interviene en labores de contratación. Interviene en la definición de estándares. Interviene en el diseño de nuevos servicios: Pone el conocimiento al servicio del resto de la organización. Proporcionar asesoramiento en riesgos, identificando servicios críticos y dependencias de sistema y definiendo e implementando soluciones. Relaciones con otros procesos de ITIL: El Catálogo de servicios. Gestión de peticiones. Gestión de incidencias. Gestión de Problemas. Gestión de cambios. 6.10 Función: Gestión de Operaciones de TI. La Gestión de Operaciones es la encargada de asegurar que los servicios cumplen con los niveles de calidad establecidos, para asegurar que los servicios se están prestando con normalidad. También se encarga del mantenimiento de la infraestructura de la organización TI. Debe estar compuesto por un equipo altamente cualificado y especializado por lo que sus recursos requieren una formación rigurosa. Marcan procedimientos planeados y programados para asegurar la fiabilidad del servicio. Conceptos: ROI: Retorno de la inversión.
CPS: Centro de proceso de datos. Objetivos: Se encarga del mantenimiento diario de los procesos y procedimientos para declarar la eficacia del servicio. Este mantenimiento provee mejoras en el servicio y diagnostica y resuelve cualquier degradación de las operaciones. Procedimiento: Se desarrolla basándose en los estándares establecidos en la fase de diseño. Requisitos: ROI Mayor que el valor del gasto. Como la tecnología apoya o afecta al servicio. Establecer el impacto del servicio en el negocio. Documentación y procedimientos. Métricas e indicadores. Optimización de la tecnología existente e inversión en nuevas tecnologías. Las dos funciones de la Gestión de Operaciones son: Control de Operaciones: Se encarga de las tareas rutinarias, así como de las tareas de monitorización y control. Supervisar la ejecución y monitorización de la prestación del servicio. Monitorización de consolas Programación de tareas. Back-up y restauración de datos. Gestiona los entregables. Gestión de Instalaciones: Se encarga del mantenimiento del equipamiento físico. CPDs. Control energético. Métricas: Número de restauraciones de datos.
Instalaciones con éxito. Tareas programadas con éxito. Tiempo de respuesta a eventos. Tiempos de resolución de casos. Rendimiento según acciones planificadas. Objetivos de mantenimiento. Incidentes relacionados con ella infraestructura. Informes de acceso a la infraestructura. Número de casos relacionados con la seguridad. Tiempos de respuesta y resolución. Relaciones con otros procesos de ITIL: El Catálogo de servicios. Gestión de peticiones. Gestión de incidencias. Gestión de Problemas. Gestión de cambios.