Source: http://docplayer.es/2329100-Maestria-en-evaluacion-y-auditoria-de-sistemas-tecnologicos-promocion-i-tesis-de-grado-maestria-en-evaluacion-y-auditoria-de-sistemas-tecnologicos.html
Timestamp: 2016-10-25 01:32:42+00:00

Document:
⭐MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS PROMOCIÓN I TÉSIS DE GRADO MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS
MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS PROMOCIÓN I TÉSIS DE GRADO MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS
Download "MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS PROMOCIÓN I TÉSIS DE GRADO MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS"
1 MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS PROMOCIÓN I TÉSIS DE GRADO MAESTRÍA EN EVALUACIÓN Y AUDITORÍA DE SISTEMAS TECNOLÓGICOS TEMA: ANÁLISIS Y DISEÑO DEL PROCESO DE LA OPERACIÓN DEL SERVICIO (ITIL V.3) CON ENFOQUE DE GESTIÓN DE RIESGOS AUTORES: ING. LLERENA FUENMAYOR, MÓNICA ALEXANDRA ING. SAÁ CHONLONG, JOSÉ DAVID DIRECTOR: ING. PALIZ, VICTOR SANGOLQUÍ, JULIO DE 20142 i UNIVERSIDAD DE LAS FUERZAS ARMADAS VICERRECTORADO DE INVESTIGACIÓN Y VINCULACIÓN CON LA COLECTIVIDAD UNIDAD DE GESTIÓN DE POSTGRADOS CERTIFICADO Ing. Víctor Paliz CERTIFICA Que el trabajo titulado ANÁLISIS Y DISEÑO DEL PROCESO DE LA OPERACIÓN DEL SERVICIO (ITIL V.3) CON ENFOQUE DE GESTION DE RIESGOS realizado por la Ing. Mónica Llerena con CI: y el Ing. David Saá con CI: está terminado, ha sido guiado y revisado periódicamente y cumple normas estatutarias establecidas por la ESPE, en el Reglamento de Estudiantes de la Universidad de las Fuerzas Armadas. Sangolquí, 3 de Julio Ing. Víctor Paliz3 ii UNIVERSIDAD DE LAS FUERZAS ARMADAS VICERRECTORADO DE INVESTIGACIÓN Y VINCULACIÓN CON LA COLECTIVIDAD UNIDAD DE GESTIÓN DE POSTGRADOS Ing. Mónica Alexandra Llerena Fuenmayor Ing. José David Saá Chonlong DECLARAMOS QUE: El proyecto de grado denominado ANÁLISIS Y DISEÑO DEL PROCESO DE LA OPERACIÓN DEL SERVICIO (ITIL V.3) CON ENFOQUE DE GESTION DE RIESGOS ha sido desarrollado con base a una investigación exhaustiva, respetando derechos intelectuales de terceros, conforme las citas que constan al pie de páginas correspondientes, cuyas fuentes se incorporan en la bibliografía. Consecuentemente este trabajo es de nuestra autoría. En virtud de esta declaración, nos responsabilizamos del contenido, veracidad y alcance del proyecto de grado en mención. Sangolquí, 3 de julio de Ing. Mónica A. Llerena Fuenmayor Ing. José David Saá Chonlong4 iii UNIVERSIDAD DE LAS FUERZAS ARMADAS VICERRECTORADO DE INVESTIGACIÓN Y VINCULACIÓN CON LA COLECTIVIDAD UNIDAD DE GESTIÓN DE POSTGRADOS AUTORIZACIÓN Nosotros, Ing. Mónica Alexandra Llerena Fuenmayor Ing. José David Saá Chonlong Autorizamos a la Universidad de las Fuerzas Armadas la publicación, en la biblioteca virtual de la Institución del trabajo ANÁLISIS Y DISEÑO DEL PROCESO DE LA OPERACIÓN DEL SERVICIO (ITIL V.3) CON ENFOQUE DE GESTION DE RIESGOS cuyo contenido, ideas y criterios son de nuestra exclusiva responsabilidad y autoría. Sangolquí, 3 de julio de Ing. Mónica A. Llerena Fuenmayor Ing. José David Saá Chonlong5 iv DEDICATORIA Dedicamos nuestro trabajo de investigación a nuestras familias en el cual con la finalización del mismo hemos logrado cumplir otro objetivo de nuestras vidas al crecer personal y profesionalmente.6 v AGRADECIMIENTO Agradecemos a Dios y a nuestras familias; a nuestros padres por ser ejemplo de esfuerzo, compromiso y perseverancia en todo momento y a nuestros hermanos por ser un apoyo en nuestra vida. Adicionalmente agradecemos de igual manera al coordinador de la Maestría el Ing. Mario Ron y a nuestro Director Ing. Víctor Paliz por su gran apoyo en el desarrollo y finalización del presente proyecto de posgrado.7 INDICE DE CONTENIDOS CERTIFICADO... i DECLARAMOS QUE:... ii AUTORIZACIÓN... iii DEDICATORIA... iv AGRADECIMIENTO... v INDICE DE CONTENIDOS... vi INDICE DE TABLAS... viii INDICE DE GRÁFICOS... ix INDICE DE FIGURAS... XI RESUMEN...XII ABSTRACT... XIII 1 ANÁLISIS Y DISEÑO DEL PROCESO DE LA OPERACIÓN DEL SERVICIO (ITIL V.3) CON ENFOQUE DE GESTIÓN DE RIESGOS Gestión de Servicios de TI Definición Qué es un servicio? Qué es ITIL? ITIL y sus Publicaciones Gestión de Riesgos Operación del Servicio con enfoque de Riesgos Propuesta Operación del Servicio Fundamentos de la Operación del Servicio Procesos y Funciones Guía Metodológica Misión / Visión/ Valores Corporativos Estructura Organizacional Gestión del Catálogo de Servicios (Diseño) Gestión de la Configuración y Activos del Servicio (Transición) Gestión de Eventos (Operación) Gestión de Incidencias (Operación) Gestión de Peticiones (Operación) Gestión de Problemas (Operación) Gestión de Acceso (Operación) Mejora Continua del Servicio (MCS) vi8 vii Funciones de la Operación del Servicio Caso de Implementación Objetivo Alcance Desarrollo La Organización Misión / Visión / Valores Organizacionales Mejora Continua del Servicio (Situación Inicial) Estructura Organizacional Gestión del Catálogo de Servicios Gestión de la Configuración y Activos del Servicio Gestión de Eventos Gestión de Incidentes Gestión de Peticiones Gestión de Problemas Gestión de Acceso Funciones de la Operación de Servicio Mejora Continua del Servicio Conclusiones y Recomendaciones Conclusiones Recomendaciones Glosario de Términos Bibliografía9 viii INDICE DE TABLAS Tabla 1 Matriz De Clasificación De Servicios Tabla 2. Matriz De Asignación De Servicios Tabla 3 Matriz De Puntajes Para Definición De Prioridad Tabla 4 Matriz De Asignación De Prioridades Tabla 5 Yellowpepper Servicios Internos Tabla 6 Yp Catalogo De Servicio Resumen Tabla 7 Priorización De Servicios Tabla 8. Número De Tickets Por Prioridad Y Análisis Del Porcentaje De Cumplimiento Dentro De Los Marco De Tiempo Definidos... 9410 ix INDICE DE GRÁFICOS gráfico 1 Sistema De Priorización Simple (Office Of Government Commerce Ogc, 2007) Gráfico 2. Categorías Para Ingreso De Un Ci En Proyecto Cmdb Jira (Imagen Ampliada Anexo C) Gráfico 3 Pantalla De Ingreso Ci De Aplicaciones (Imagen Ampliada Anexo C) Gráfico 4 Pantalla De Ingreso Ci De Hardware (Imagen Ampliada Anexo C) Gráfico 5 Pantalla De Ingreso Ci De Software (Imagen Ampliada Anexo C) Gráfico 6 Pantalla De Ingreso Ci De Base De Datos (Imagen Ampliada Anexo C). 70 Gráfico 7 Pantalla De Ingreso Ci De Proveedores (Imagen Ampliada Anexo C) Gráfico 8 Pantalla De Buscador Personalizado De CIs (Imagen Ampliada Anexo C) Gráfico 9 Relación Ci Con Ticket Creado En Customer Support Project (Imagen Ampliada Anexo C) Gráfico 10 Operations Center Yp Nagios Xi Gráfico 11 Muestra De Archivo Con Cada Alerta A Ser Generada Para Cada Tipo Aplicación Y Servicio En Producción. (Imagen Ampliada Anexo C) Gráfico 12 Muestra De Interfaz De Monitoreo Yp (Imagen Ampliada Anexo C) Gráfico 13 Pantalla De La Pestaña Basics Al Crear Un Nuevo Incidente En Jira (Imagen Ampliada Anexo C) Gráfico 14 Matriz De Puntajes Para Asignación De Prioridades (Imagen Ampliada Anexo C) Gráfico 15 Matriz De Puntajes Respuesta Y Marcos De Resolución (Imagen Ampliada Anexo C) Gráfico 16 Pantalla De La Pestaña Basics Al Crear Un Nuevo Requerimiento De Servicio En Jira (Imagen Ampliada Anexo C) Gráfico 17 Pantalla De Ingreso De Un Ticket En El Proyecto Maintenance En Jira (Imagen Ampliada Anexo C) Gráfico 18 Pantalla De Ingreso De Una Solicitud De Acceso En Jira (Imagen Ampliada Anexo C) Gráfico 19 Promedio De Tiempo De Respuesta Por Parte Del Equipo De Soporte. 9211 Gráfico 20 Incidentes De Producción Gráfico 21 Número De Tickets De Peticiones x12 xi INDICE DE FIGURAS figura 1 Itil Ciclo De Vida - Publicaciones (Office Of Government Commerce Ogc, 2007)... 5 Figura 2 Proceso De Gestión De Eventos (Office Of Government Commerce Ogc, 2007) Figura 3 Proceso De Gestión De Incidentes (Office Of Government Commerce Ogc, 2007) Figura 4 Proceso De Gestión De Problemas Reactivo (Office Of Government Commerce Ogc, 2007) Figura 5 Modelo De Mejora Continua Del Servicio (Office Government Commerce Ogc, 2007) Figura 6 Proceso 7 Pasos De Mejora (Office Government Commerce Ogc, 2007) Figura 7 Espiral Del Conocimiento. (Office Government Commerce Ogc, 2007) Figura 8. Modelo Dikw (Office Government Commerce Ogc, 2007) Figura 9 Flujo De Comunicación Prioridad Crítica (Imagen Ampliada Anexo C) Figura 10 Flujo De Comunicación Prioridades Alta Normal Baja (Imagen Ampliada Anexo C)... 8913 xii RESUMEN El avance de la tecnología siempre ha ido de la mano con la evolución de los seres humanos. A medida que los años pasan se han ido creando un sin número de tecnologías que a su vez soportan diferentes tipos de servicios que suplen nuestras necesidades, pero así mismo, éstas necesidades cada vez son más amplias y exigentes con muchas variables de por medio que hacen que los servicios deban ser cada vez más flexibles, escalables, efectivos y por sobre todo que sea útil para el usuario del servicio.tomando en consideración estos escenarios, las empresas como tal y por ende el personal de TI principalmente tiene un gran desafío, el cual es disponer de una infraestructura tecnológica que permita soportar los servicios internos y externos de la empresa, maximizando recursos y oportunidades, estableciendo procesos efectivos basados en marcos o estándares de referencia internacionales que ayuden a minimizar los riesgos a los que está expuesto el servicio, disponer de una infraestructura de TI que esté alineada con los objetivos del negocio y sea escalable, flexible, disponible, segura y confiable. El presente proyecto de investigación busca el poder establecer una referencia razonable para analizar y diseñar el Proceso de la Operación del Servicio según ITILv3, que específicamente se orienta a soportar los servicios actuales en producción, con un enfoque de Gestión de Riesgos que permita definir controles para una mayor efectividad en el proceso en sí. Palabras Clave: ITIL, OPERACIÓN DEL SERVICIO, RIESGO DE TI, INCIDENTES DE TI, GESTIÓN DE SERVICIO DE TI.14 xiii ABSTRACT The growth of technology has always gone hand in hand with the evolution of human beings. As the years pass a number of technologies have been created which in turn support different types of services that address our needs, but also, these needs are becoming broader and more demanding with many variables that make it through services must be increasingly flexible, scalable, and effective and above all that is useful to the user of the service. Considering these scenarios, companies as such and therefore mainly IT staff has a great challenge, which is to have a technology infrastructure to support internal and external enterprise services, maximizing resources and opportunities, establishing processes effective frame-based or international reference standards to help minimize the risks to which it is exposed service, have an infrastructure that is aligned with business objectives and is scalable, flexible, available, secure and reliable. This research project seeks to establish a reasonable benchmark to analyze and design the process according to the ITILv3 Service Operation, which specifically aims to support current production services, with a focus on risk management controls designed to define greater effectiveness in the process itself. KEY WORDS: ITIL, OPERATION SERVICE, IT RISK, IT INCIDENTS, IT SERVICE MANAGEMENT15 1 1 ANÁLISIS Y DISEÑO DEL PROCESO DE LA OPERACIÓN DEL SERVICIO (ITIL V.3) CON ENFOQUE DE GESTIÓN DE RIESGOS 1.1 Gestión de Servicios de TI La constante evolución, diversidad y usos de la tecnología ha generado que la Gestión de Servicios de TI también evolucione en el tiempo orientándose a tratar con una mejor efectividad los eventos diarios que afectaban los servicios ofertados por las empresas hacia sus clientes. En la búsqueda de ésta efectividad el gobierno de Reino Unido estableció documentar cómo las mejores y más exitosas organizaciones alcanzaban la gestión de servicios por lo que a finales de la década de 1980 y a inicios de la década 1990 una serie de libros fueron publicados en donde ser abordaba la necesidad de una gestión de servicios para el soporte a los usuarios del negocio, a ésta librería se denominó ITIL (IT Infrastructure Library) (Office of Government Commerce OGC, 2007). ITIL como mejores prácticas para la gestión de servicios de TI fue cada vez siendo un marco de referencia para las empresas y es así que desde sus inicios ha tenido varias mejoras y actualizaciones desde empezar con una colección de 40 libros, una siguiente revisión de la librería publicada a inicios del año 2000 ITIL v2 contempla 9 libros enfocándose particularmente en la brecha entre la tecnología y la empresas así como en los procesos necesarios para la entrega de los servicios a los clientes de una forma más efectiva. Posteriormente ITILv3 publicado en Mayo 2007, donde la principal diferencia con la versión 2 es la nueva estructura del Ciclo de Vida del Servicio y por último será en Julio de 2011 donde se realiza una nueva actualización, la cual toma como referencia las retroalimentaciones dadas por los usuarios y la comunidad de entrenamientos como tal (Maps, 2013). Es importante notar que ITIL 2011 es una actualización mas no una nueva versión.16 2 1.2 Definición Es claro que hoy en día, los Servicios de TI en las empresas, son considerados estratégicos para la entrega, soporte y administración de los servicios ofertados a sus clientes internos y externos, en tal virtud y tomando en consideración que la información es uno de los principales recursos que posee una empresa, su administración, análisis, producción y distribución son en sí la calidad de los servicios de TI provistos al negocio. Según ITIL La Gestión de Servicios es un conjunto de capacidades organizativas especializadas cuyo fin es generar valor para los clientes en forma de servicios (Office of Government Commerce OGC, 2007) Este conjunto de capacidades que se transforman en funciones y procesos para administrar los servicios sobre el ciclo de vida hace que se asegure que estos servicios de TI estén alineados a las necesidades del negocio y que estén completamente soportadas por ellos. El objetivo de la Gestión de Servicios es proveer Servicios de TI que apoyen a los procesos del negocio, los cuales estén alineados con los objetivos estratégico de la empresa y por ende se ofrecer servicios de calidad útiles y aceptables para el usuario final en donde el proveedor toma la responsabilidad de gestionar los recursos en nombre del cliente Qué es un servicio? Según ITIL servicio se define como el medio para entregar valor a los clientes, facilitándoles un resultado deseado sin la necesidad de que éstos asuman los costes y riesgos específicos asociados. (Office of Government Commerce OGC, 2007)17 3 El valor que se entrega a los clientes es la parte medular del servicio ya que está compuesta por cada uno de los beneficios que el cliente recibe, siendo ésta la funcionalidad como tal que el cliente percibe por el servicio y la garantía es vista por el cómo se entrega el servicio al cliente. Los servicios como tal satisfacen los requerimientos del cliente sin que este sienta la necesidad de asumirlo directamente en todo su entorno y de disponer de los recursos que impliquen para tener este servicio, lo cual mejora la condición actual del cliente, reduce las limitaciones que se presenten y permite incrementar los resultados que el cliente desea obtener. El objetivo principal de la Gestión de Servicios es asegurar que los servicios de TI estén alineados con las necesidades del negocio y que estén en constante soporte de las mismas. (Cartlidge, et al., 2007) 1.3 Qué es ITIL? Debido a la constante evolución y dependencia de la tecnología hoy en día en las organizaciones como un activo estratégico para la entrega de los servicios ofertados a sus clientes, nace la necesidad de que los Servicios de TI sean gestionados de forma efectiva. Como se mencionó anteriormente en este capítulo, en la búsqueda de encontrar el acercamiento a la Gestión de Servicios de TI nace ITIL que a lo largo de los años y por su gran popularidad fue tomada como referencia base para la elaboración de estándares internacionales como la British Standard inicialmente y posteriormente el estándar ISO/IEC ITIL es un marco de referencia público en el que se describen las mejores prácticas para la Gestión de Servicios de TI y Gobierno de TI, así como también el18 mejoramiento y control continuo de la calidad de los servicios entregados desde la perspectiva del negocio y del cliente. (Cartlidge, et al., 2007) 4 Como principales beneficios que se obtiene al adoptar las mejores prácticas indicadas en ITIL tenemos: Mejora la alineación de los Servicios de TI con los procesos del negocio. Incrementa la comunicación entre el área de TI y el resto de la organización Reduce los costos Mejora la calidad de los servicios de TI Mejora la gestión de proveedores. Incrementa la satisfacción del cliente. Mejora de la productividad de la organización. Facilita la toma de decisiones en base a indicadores de rendimiento Minimiza las fases de cambios mejorando los resultados de los procesos de TI ITIL y sus Publicaciones. El conjunto principal de publicaciones de ITIL consiste en 6 libros (Office of Government Commerce OGC, 2007): Introducción a la gestión de servicios de ITIL Estrategia del Servicio Diseño del Servicio Transición del Servicio Operación del Servicio Mejora continua de Servicio. Como se puede visualizar en la Figura 1 cada fase del ciclo de vida del servicio de TI se relacionan entre sí y juegan un rol importante para la adopción de ITIL, los cuales una vez que el flujo del servicio pasa por cada fase llega a un ciclo de19 mejoramiento continuo en el cual se busca la efectividad de los Servicio de TI y por ende el acercamiento a una mejor Gestión de los Servicio de TI. 5 Figura 1 ITIL ciclo de vida - publicaciones (Office of Government Commerce OGC, 2007) Cada publicación mantiene una estructura similar y referencias entre sí para una mejor navegación entre cada libro. De igual forma existen publicaciones complementarias y servicios web que ayudan al mejor entendimiento y aplicación de ITIL. El ciclo de Vida del Servicio consta de 5 fases que a su vez son descritas en cada una de los libros que contempla la librería El libro Estrategia del Servicio (Office of Government Commerce OGC, 2007) provee dirección de como diseñar, desarrollar e implementar la Gestión de Servicio desde la orientación como un ente estratégico. El libro Diseño del Servicio (Office of Government Commerce OGC, 2007) provee dirección para el diseño y desarrollo de los servicios y gestión de los procesos de servicio.20 6 El libro Transición del Servicio (Office of Government Commerce OGC, 2007) provee dirección para el desarrollo y mejoramiento de las capacidades para la transición de nuevos y servicios puestos en producción operación. El libro Operación del Servicio (Office of Government Commerce OGC, 2007) se personifica las prácticas de la gestión de servicios donde se busca la eficiencia y eficacia en la provisión y soporte de los servicios con el fin de generar valor a los clientes y al proveedor como tal del servicio. El libro Mejora Continua del Servicio (Office of Government Commerce OGC, 2007) provee dirección para generar y mantener el valor para el cliente mediante la mejora continua del diseño, transición y operación de los servicios. 1.4 Gestión de Riesgos Toda organización hoy en día tiene como objetivo principal utilizar, administrar y automatizar sus recursos de forma efectiva para soportar como tal los objetivos de la organización. Sin embargo no todas las empresas consideran los posibles riesgos que pueden ocurrir que afecten sus recursos y por ende generar un impacto a la organización que impida cumplir su misión organizacional. Una gestión de riesgos efectiva y como tal el proceso en sí no debe ser considerada como un componente separado y más aún solo manejado por el personal de TI, la gestión de riesgos debe ser una función esencial de la organización y debe ser concebida por todos los principales actores de la organización. Al tomar en cuenta los objetivos de una persona o empresa y adicionalmente las actividades relacionadas para que estos objetivos se cumplan es necesario considerar que puede suceder durante estas actividades. El tener esta incertidumbre de saber que puede pasar se llama riesgo. Es ahí la importancia de conocer que riesgos pueden acaecer para así afrontarlos y controlarlos.21 Riesgo es la probabilidad de que un evento ocurra y afecte desfavorablemente al logro de objetivos (COSO, FLAI, Pricewaterhouse Coopers, 2005). 7 Estos eventos negativos impiden la generación de valor por parte de la organización a sus clientes sin embargo también existen eventos de impacto positivo llamados oportunidades. Oportunidad es la posibilidad de un evento ocurra y afecte positivamente a la consecución de objetivos. (COSO, FLAI, Pricewaterhouse Coopers, 2005) La gestión de riesgos permite identificar y planificar los eventos para así disponer de un entorno controlado de los riesgos que puedan acaecer haciendo uso eficaz, eficiente y razonable de las tecnologías de información involucrando a cada uno del personal de la empresa para la consecución de los objetivos de la organización.22 8 2 Operación del Servicio con enfoque de Riesgos Toda empresa sea pequeña, mediana o grande dispone de un portafolio de servicios los cuales soportan los procesos del cliente interno o en su defecto son productos y/o servicios ofertados a sus clientes externos lo que permite generar ingresos a la compañía. Por otro lado las áreas de TI que deben soportar los servicios en producción, en especial los administradores de TI, tienen la responsabilidad de buscar el mejoramiento continuo de sus procesos e infraestructura para ofrecer una alta disponibilidad de los servicios. En tal razón nace la necesidad de apoyarse en mejores prácticas o estándares internacionales que permitan lograr este objetivo. Como ya se ha comentado en el anterior capitulo ITIL es uno de los marcos de referencia más utilizados por los profesionales de TI para el mejoramiento de la gestión de servicios de TI sin embargo una vez que los profesionales de TI toman la decisión de usar un estándar o un marco de referencia, nacen interrogantes para los profesionales de TI, como Por dónde empezar a implementar la gestión de Servicios?, Cómo minimizar el impacto de los posibles riesgos que pueden acaecer ante los servicios ofertados? Si bien ITIL dentro del ciclo de vida menciona la importancia de manejar los riesgos corporativos en las diferentes etapas del ciclo de vida de la gestión de Servicios sin embargo se puede complementarlo definiendo puntos de control basados en un enfoque de Riesgos. 2.1 Propuesta La presente investigación busca analizar y diseñar la Operación del Servicio basada en ITIL con un enfoque de Riesgos, es decir definir procesos, tareas, actividades, tablas y flujos necesarios siguiendo las mejores prácticas indicadas por ITIL en la gestión de eventos, incidentes, problemas, peticiones y acceso,23 9 adicionando a éstos procesos, el enfoque de riesgos correspondiente con lo cual se logrará mejorar, implementar, controlar y gestionar los procesos necesarios en el soporte de los servicios que entregan día a día valor al negocio, acercándose a una mejor gestión de los servicios de TI con un enfoque de Riesgos de TI. 2.2 Operación del Servicio La Operación del Servicio es la cuarta publicación en el ciclo de vida de ITIL el cual sirve de guía para desarrollar una gestión de servicios adecuada en donde el negocio y los usuarios estén satisfechos y a la vez recibir el valor definido en la estrategia y diseño. La Operación del Servicio contempla las actividades diarias, procesos e infraestructura que es responsable en la entrega de valor al negocio a través de la tecnología. (Orr, 2013) Fundamentos de la Operación del Servicio El objetivo de la Operación del Servicio es diseñar, implementar, monitorear y coordinar las actividades y procesos necesarios para la entrega y gestión de los servicios acordados tanto con los clientes internos y externos, también es responsable de la administración, monitoreo y rendimiento de la tecnología que soporta los servicios ofertados a los clientes así como del control y gestión continua de los riesgos que estén presentes y puedan afectar la calidad de los servicios ofertados. El alcance de la Operación del Servicio incluye: Toda actividad que sea parte de un servicio sea realizado por proveedores, personal interno o clientes externos. Procesos de gestión de Servicio. Toda la tecnología necesaria para la entrega de los servicios. Las personas relacionadas a los procesos y tecnología que soportan a los servicios.24 Procesos y Funciones Los procesos claves relacionados con la Operación del Servicio son: Gestión de Eventos: Monitorea todos los eventos que ocurren a través de la infraestructura de TI para vigilar la operación normal, detectar y escalar condiciones de excepción (Office of Government Commerce OGC, 2007). Gestión de Incidencias: Se enfoca en restaurar los servicios degradados interrumpidos inesperadamente a los clientes tan pronto sea posible con el objetivo de minimizar el impacto al negocio. (Office of Government Commerce OGC, 2007) Gestión de Problemas: Consiste en determinar y resolver la causa raíz de los incidentes, realizando actividades que detecten y prevengan futuros incidentes y problemas, así como también como fuente de errores conocidos para diagnosticar y resolver incidentes futuros (Office of Government Commerce OGC, 2007). Gestión de Peticiones: Es el proceso responsable de gestionar los requerimientos de servicio que pueden ser pequeños cambios en la prestación del servicio. Gestión de Acceso: Es el proceso que otorga a los usuarios autorizados el acceso correcto al uso de los servicios. Los procesos como tal trabajan en relación con las unidades especializadas (funciones), que en realidad son las personas adecuadas con el conocimiento necesario, las cuales en conjunto con los procesos, permiten una efectiva Operación del servicio. Dentro de las funciones principales tenemos: Las funciones involucradas en la fase de Operación del Servicio son las responsables de que los servicios cumplan los objetivos solicitados por los clientes y25 de gestionar toda la tecnología necesaria para la prestación de dichos servicios. (OSIATIS S.A, n.d.) 11 Centro de Servicios: Es el primer punto de contacto con los clientes cuando existe una interrupción en el servicio, requerimientos de servicio o requerimientos de cambio. De igual forma son el punto de comunicación con otros grupos de TI y procesos. Gestión de Operaciones de TI: Son los responsables de cada acción diaria necesaria para la gestión de la infraestructura que soporta los servicios. Gestión Técnica: Es la que provee los conocimientos técnicos y recursos necesarios para soportar la operación diaria de la infraestructura de TI. Gestión de Aplicaciones: Es la función responsable del manejo de las aplicaciones de TI a lo largo de su ciclo de vida. (Office of Government Commerce OGC, 2007) 2.3 Guía Metodológica El objetivo de la guía metodológica es brindar un soporte al lector el cual puede ser usado como base para la implementación de ITIL empezando por el proceso de la Operación del Servicio adicionando el enfoque de riesgos de TI, así como procesos y actividades adicionales necesarias que en si son parte del ciclo de vida de la Gestión de Servicios. Es importante notar que todos los procesos durante el ciclo de vida son necesarios para una efectiva gestión de servicios sin embargo la propuesta orienta a definir un punto de partida para la implementación de la gestión de servicios para que posteriormente se continúe la implementación en más detalle los diferentes procesos definidos por ITIL según requiera la empresa.26 Misión / Visión/ Valores Corporativos La misión, visión y los valores corporativos son herramientas esenciales para el desarrollo, rumbo e identidad de una organización. La misión es la razón de ser de la empresa la cual ayuda a establecer la personalidad de la organización y por ende cada empleado pueda sentirse identificado. El definir una adecuada misión aporta estabilidad y coherencia en las operaciones ya que toda acción realizada debe estar alineada con la estrategia definida la cual a su vez, está alineada con la visión. La visión y los valores corporativos complementan la misión, siendo la visión lo que la empresa quiere llegar a ser, el futuro de la empresa donde cada miembro direccione sus acciones y esfuerzos hacia este objetivo común. Así mismo los valores corporativos son los factores de la cultura de la empresa, es la idiosincrasia organizacional en la cual se basa el trabajo del día a día. La comunicación y adopción adecuada de la misión, visión y valores corporativos es una estrategia esencial para incrementar la efectividad, es decir ser eficientes y eficaces ofreciendo servicios de calidad. Punto de Riesgo: El no disponer o difundir la misión, visión y valores corporativos puede ocasionar una pérdida de recursos al no orientar todos los esfuerzos en un bien común afectando la estabilidad y coherencia de las operaciones diarias y por ende no se logrará llegar al estado de misión y visión establecidos (Meltom Technologies, 2009) Estructura Organizacional Definir y difundir la estructura organizacional de una empresa es fundamental ya que permite entender las líneas jerárquicas de cada puesto así como la relación27 13 directa e indirecta entre las áreas funcionales, de igual forma permite a los empleados saber cuáles son sus funciones y responsabilidades, delimita las actividades, segrega funciones, creando así un ambiente de orden, ahorrando tiempo y recursos para una mayor efectividad en el trabajo diario. Como parte de la estructura organizacional, aparte de tener el organigrama de la empresa, es importante tener los perfiles de cada puesto de trabajo así como las responsabilidades departamentales y relaciones entre cada uno que ayudarán en la información de cómo está organizada la empresa jerárquica y funcionalmente. De igual forma como lo indica la ISO es importante tener bien definido el establecimiento del contexto interno y externo en el cual la organización está relacionada para así alcanzar un mejor análisis de los riesgos que pueden acaecerse, es decir de forma externa se deberán validar temas como regulaciones, aspectos financieros, económicos, políticos cultural, tendencias y aspectos claves que puedan impactar la consecución de los objetivos del negocio. De forma interna se deberán validar las capacidades de la organización en relación a sus recursos y conocimientos, procesos, políticas, valores organizacionales, objetivos y estrategias, flujo, roles y responsabilidades. Punto de Riesgo: En base a la experiencia y como se menciona en el blog de wordpress, (WordPress.com) el no tener una estructura organizacional definida implica Funciones duplicadas, incorrecta comunicación de eventos, toma de decisiones incorrectas, actividades y/o procesos sin una clara definición de la persona responsable. Pérdida de recursos monetarios y tiempo. (Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica, 2012) Gestión del Catálogo de Servicios (Diseño) La Gestión del Catálogo de Servicios es parte de los subprocesos definidos en el proceso de Diseño de los Servicios de TI como parte del ciclo de vida definido por28 14 ITIL. El objetivo principal del Catálogo de Servicios es condensar toda la información referente a los servicios que se encuentran en producción que permitan dar claridad y entendimiento de cada servicio y su relación con la organización. El Catálogo de Servicios debe describir los servicios de manera comprensible evitando lenguaje técnico, incluyendo de forma general información sobre precios, responsabilidades asociadas al servicio, acuerdos de servicio y que pueda ser utilizado como guía tanto para clientes internos y externos. Cada uno de los servicios identificados deben ser clasificados o agrupados según su tipo, es decir pueden ser por producto o relación entre ellos, ésta clasificación debe ser definida por la organización con el objetivo de tener un visión clara de los servicios que presta la empresa a sus clientes. Una vez clasificados los servicios se deberá definir la información a recabar para cada servicio como ejemplo nombre, cliente, fecha de paso a producción, versiones, precios, etc. entre los principales. Si bien la organización definirá la clasificación de los servicios, para la presente investigación se usará como base la clasificación establecida por MAGERIT en el catálogo de elementos (Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica, 2012), la cual se presenta a continuación: Anónimo: Sin requerir identificación del usuario Público: Al público en general sin relación contractual Externo: Usuarios externos, bajo una relación contractual Interno: A usuarios propios de la organización www: world wide web Telnet: Acceso remoto a cuenta local Correo Electrónico Archivo: Almacenamiento de archivos FTP: Trasferencia de archivos29 15 EDI: Intercambio electrónico de datos Dir: Servicio de Directorio. IDM: Gestión de identidades IPM: Gestión de Privilegios PKI: Infraestructura de clave pública Como parte importante del proceso el catálogo de servicio se debe mantener actualizado y revisado así como mantener un control sobre las actualizaciones realizadas al catálogo y en qué periodo de tiempo. Punto de Riesgo: Si bien se puede tener la clasificación de los servicios y la información relacionada a ellos, es necesario también adicionar un visión de la importancia que los servicios representan para la organización con el objetivo de enfocar los recursos necesarios en el caso del acaecimiento de un evento que impacte al servicio. Proponemos definir, en base a la experiencia adquirida, una clasificación de los productos y servicios alineados con los objetivos del negocio, es decir, la clasificación se realizará en función de los servicios que la empresa considere con mayor importancia para el negocio sin restar importancia a los ingresos que los servicios en una menor clasificación representen. Sin embargo es de considerar que si uno de los servicios con mayor importancia tiene una afectación esta puede generar una mayor pérdida para la empresa que la suma de uno o dos servicios con menos importancia. La clasificación debe ser definida principalmente por el área comercial y financiera así como las áreas que puedan aportar a tener una mejor clasificación de los servicios. De igual forma el disponer de ésta clasificación puede servir de punto de decisión en la matriz de prioridad definida para la gestión de incidentes y problemas. Para clasificar los servicios se puede establecer un código de clasificación por tipo de importancia e ingresos que represente el servicio para la organización. Se30 definirá pesos, rangos para enmarcar los ingresos y una categorización por importancia ver. Tabla Tabla 1 Matriz de Clasificación de Servicios Peso Ingreso Importancia 3 Rango D Crítica 2 Rango C Alta 1 Rango B Media 0 Rango A Normal Una vez definidos los rangos y la categorización se procede a enmarcar cada servicio con el peso correspondiente según la tabla de clasificación de servicios y así agrupar los servicios con un enfoque de la criticidad que representan para la empresa. Tabla 2. Matriz de Asignación de Servicios Puntuación Clasificación 5 6 Crítico 3 4 Alto 1 2 Medio 0 Baja31 Gestión de la Configuración y Activos del Servicio (Transición) La gestión de la configuración y activos del servicio es parte de los procesos definidos dentro de la transición de los servicios de TI de lo que comprende el ciclo de vida de ITIL. La transición de los servicios de TI tiene como finalidad que los productos y servicios definidos en la fase de Diseño se integren en el entorno de producción y sean accesibles a los clientes y usuarios autorizados. Como uno de los principales objetivos de la transición de TI citamos que se minimiza los posibles riesgos asociados a los cambios en producción, lo que permite mantener una actualizada base de datos de configuración y activos que soportan los servicios así como lo responsables de los mismos. Para poder soportar los servicios que actualmente están en producción es necesario definir una política la cual determine la prioridad, el tipo de servicio sea interno o externo y que activos se van a identificar. Las principales funciones de la Gestión de la configuración y activos de TI son: Llevar el control de los elementos de configuración de la infraestructura TI y gestionarla a través de la Base de datos de Configuración (CMDB). Proporcionar información sobre la configuración TI. Interactuar con la gestión de incidencias, problemas y cambios para un tener una eficiente resolución y gestión de los requerimientos recibidos. Monitoreo continuo de la configuración de los sistemas en el entorno de producción. Entre los beneficios que se obtienen mediante una Gestión de la configuración y activos tenemos: Resolución de requerimientos más efectiva32 18 Reducción de gastos. Gestión de cambios más eficiente Permite detectar vulnerabilidades en la infraestructura. Control de Hardware y Software Es importante tener claro la definición de que un elemento de configuración (CI) y lo que es la base de datos de configuración (CMDB) ya que son elementos claves de la gestión de configuración y activos como tal. Elemento de configuración (CI) son todos aquellos componentes que deben ser gestionados por la organización de TI, son todos los elementos de los servicios de TI así como los servicios que ofrecen los cuales tienes atributos que en si son la información registrada de cada CI. Como ejemplo podemos citar el CI-001 que corresponde al Firewall etiquetado con el nombre de FW01 y que es de la marca Checkpoint donde marca y nombre son los atributos como tal del CI Firewall. La base de datos de configuración (CMDB) como su nombre lo dice es una base de datos donde debe constar la información detallada de cada CI, las relaciones y dependencias que existan entre cada CI. Las actividades principales de Gestión de la Configuración y Activos son (OSIATIS S.A, n.d.): Planificación: Establece los objetivos y estrategia a seguir en la gestión de la configuración y activos. Clasificación: Cada elemento de configuración (CI) debe ser registrado según el alcance y nivel de detalle definido. Monitorización y Control: Revisar constantemente la CMDB para verificar que todos los elementos autorizados estén registrados correctamente. Auditorías: Asegurar que la información registrada en la CMDB es consistente con la infraestructura actual de TI Elaboración de informes que midan el rendimiento de la Gestión de configuración y activos así como también la información que puede aportar a otros procesos.33 19 (Office of Goverment Commerce, 2007) Planificación de la configuración. La Gestión de la configuración y Activos es uno de los sub procesos principales dentro del ciclo de vida de ITIL en función de la relación e interdependencias con otros procesos. Tomando en consideración la complejidad que implica su implantación es importante que se defina: Un responsable para evitar descoordinación Automatizar lo más posible el proceso ya que de ser un proceso manual resulta ineficiente el mismo. Definir claramente el alcance, objetivos, nivel de detalle, proceso de implementación y actualización. Punto de Riesgo: El no planificar la gestión de configuración puede afectar la veracidad de la información (Office of Goverment Commerce, 2007) que es usada por otros procesos como Gestión de Capacidad, Incidencias, Problemas generando un grave riesgo para la organización y por ende impactando al negocio en sí Clasificación y Registro de CIs Dentro de la clasificación y registro de CIs es necesario definir la estructura de la CMDB con lo cual no se llegue a tener una profundidad muy extensa lo que genera mayor carga operativa y por ende se puede llegar a un estado de que el personal deje de lado la responsabilidad de mantener la CMDB actualizada, por otro lado de igual forma importante se deben registrar al menos todos los CIs críticos para la infraestructura de producción.34 20 El Alcance debe estar delimitado como mínimo por los sistemas y componentes de TI que son críticos para la organización o por el ciclo de vida como tal de los mismos que soportan en sí los servicios ofertados. Como referencia de clasificación de los tipos de activos se puede usar lo indicado por MAGERIT en el catálogo de elementos (Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica, 2012) CLASIFICACIÓN DE ELEMENTOS 1) Activos esenciales a) Información i) Datos de interés para la administración pública ii) Datos vitales como registros de la organización. iii) Datos de carácter personal: Alto, Medio, Bajo iv) Datos clasificados: Confidencial, Restringido, Sin clasificación, Público. b) Servicio 2) Arquitectura del Sistema a) Punto de acceso al servicio b) Punto de interconexión c) Proporcionado por terceros 3) Datos/Información a) Archivos b) Respaldos c) Datos de configuración d) Datos de Gestión Interna e) Contraseñas f) Datos de validación de credenciales g) Datos de control de acceso h) Registro de Actividad i) Código fuente35 21 j) Código Ejecutable k) Datos de Prueba 4) Claves Criptográficas a) Protección de la información i) Claves de cifrado (1) Secreto compartido (2) Clave pública (3) Clave privada de descifrado ii) Claves de Firmas (1) Secreto compartido (2) Clave privada de firma (3) Clave pública de verificación de firma b) Protección de la comunicaciones i) Claves de cifrado ii) Claves de autenticación iii) Claves de verificación de autenticación c) Cifrado de soportes de información d) Certificados de clave pública 5) Software Aplicaciones Informáticas a) Desarrollo Propio b) Desarrollo subcontratado c) Estándar i) Servidor de aplicaciones ii) Cliente de correo electrónico iii) Servidor de correo electrónico iv) Servidor de archivos v) Sistema de gestión de Base de Datos vi) Ofimática vii)monitor transaccional viii) Antivirus ix) Sistema Operativo x) Gestor de Máquinas Virtuales36 22 xi) Servidor de Terminales xii)sistema de Respaldos d) Hardware i) Equipos grandes ii) Equipos medios iii) Informática Personal iv) Informática Móvil v) Equipo Virtual vi) Equipo de Respaldos vii) Periféricos (1) Medios de impresión (2) Escáner (3) Dispositivos Criptográficos viii) Soporte de Red (1) Módem (2) Switch (3) Ruteador (4) Cortafuegos (5) Acceso inalámbrico ix) Central Telefónica x) Teléfono IP e) Redes de Comunicaciones i) Red Telefónica ii) RDSI iii) ADSL iv) X25 v) Punto a Punto vi) Comunicaciones por Radio vii)red Inalámbrica viii) Telefónica Móvil ix) Satelital x) Red Local37 23 xi) Red Metropolitana xii) Internet f) Soportes de Información i) Electrónicos (1) Discos (2) Discos Virtuales (3) Almacenamiento de red (4) CDs (5) DVDs (6) Memoria USB (7) Cinta Magnética (8) Tarjetas de Memoria (9) Tarjetas Inteligentes ii) No electrónicos (1) Material Impreso g) Equipamiento Auxiliar i) Fuentes de Alimentación ii) Sistemas de Alimentación ininterrumpida iii) Generadores Eléctricos iv) Equipos de Climatización v) Cableado (1) Cable eléctrico (2) Cable UTP (3) Fibra óptica vi) Robots (1) Cintas (2) Discos vii)equipos de Destrucción de soportes de información viii) Mobiliario ix) Cajas fuertes h) Personal i) Usuarios Externos38 24 ii) Usuarios Internos iii) Operadores iv) Administrador de Sistemas v) Administrador de Red y Comunicaciones vi) Administrador de Base de Datos vii)administrador de Seguridad viii) Desarrolladores ix) Subcontratados x) Proveedores i) Instalaciones i) Local ii) Edificio iii) Cuarto iv) Plataforma Móvil v) Vehículo Terrestre vi) Vehículo Aéreo vii)vehículo Marítimo viii) Contenedores ix) Canalización x) Instalaciones de Respaldo Una vez definido el alcance de la CMDB es necesario determinar el nivel de detalle y profundidad por lo tanto se debe determinar: Los atributos que serán relacionados a cada tipo de CI Relaciones lógicas y físicas entre cada CI Subcomponentes de cada CI De igual forma es necesario definir la nomenclatura de cada CI, la cual debe ser única y utilizada en todos los CI.39 Gestión de Eventos (Operación) Teniendo en consideración la importancia de saber el estado de la infraestructura de TI y los servicios en producción para la Operación del Servicio, es necesario saber que posibles eventos puede acaecer y afectar la calidad los servicios, en donde un evento puede ser cualquier situación, comportamiento detectable que tiene incidencia en la infraestructura de TI o en la entrega de los servicios (Office of Government Commerce OGC, 2007). Es aquí donde la Gestión de Eventos tiene el objetivo de detectar estos posibles eventos y canalizarlos para la respectiva gestión y comunicación a los responsables según el proceso definido. Ahora la gestión de Eventos si bien principalmente apoya a la operación de Servicio, el alcance del mismo puede ir a todo el ciclo de vida donde puede apoyar a detectar o informar situaciones importantes necesarias para la continuidad del negocio como por ejemplo si un CI ha cambiado de estado, o ha pasado el tiempo de licenciamiento etc. La Gestión de Eventos permite la automatización de actividades monitoreo y operacionales liberando recursos para otras actividades requeridas en la operación como tal. De igual forma apoya en la detección de incidentes que pueden ser notificadas o detectadas por las áreas responsables y así minimizar el impacto que se pueda producir y tomar acciones de comunicación antes que el cliente detecte el incidente. ITIL en su publicación de la Operación del Servicio presenta el proceso de la gestión de eventos la cual puede ser utilizada como base para la implementación en cada organización o adaptarla a las necesidades y procesos de la misma.40 26 Figura 2 Proceso de Gestión de Eventos (Office of Government Commerce OGC, 2007) Una vez definido el proceso de la Gestión de Eventos es importante definir qué eventos van a ser identificados y clasificados para que soporten a la Gestión de Servicio en sí pero principalmente a la Operación del Servicio. Por lo tanto se propone lo siguientes puntos a seguir en función de implementar la gestión de Eventos41 27 Definir los tipos eventos a identificar. o Información o Advertencia o Error Definir qué elementos de configuración van a ser monitoreados. o Hardware o Software o Aplicaciones internas o Aplicaciones externas o Comunicaciones o Red Punto de Riesgo: En base a las lecciones aprendidas durante la implementación de la Gestión de Evento, previa a la definición de cuales elementos de configuración van a ser monitoreados es importante tener claro la cadena de procesos que siguen los servicios al estar en producción, esto con el objetivo principal de identificar los principales puntos de riesgos que pueden acaecer en los diferentes puntos por donde pasan los servicios para prevenir o identificar de forma más efectiva los eventos que puedan acaecer y así minimizar el impacto en los servicios. Como ejemplo, por lo general las empresas empiezan a monitorear el hardware principal que soportan los servicios en producción, es decir, espacio en disco, disponibilidad de los equipos de conectividad, rendimiento de los servidores sin embargo pueden existir otros elementos de configuración fundamentales en el flujo del servicio que pueden afectar como por ejemplo servicios web que si bien el hardware de la organización puede ser que esté funcionando correctamente la conexión con otros proveedores o con el cliente mismo puede estar afectado lo cual al implementar la alerta se orienta al servicio proactivo en donde se informa al cliente de los sucedido y se trabaja en conjunto para solucionar el incidente. Otro punto importante a considerar es que las alertas a ser creadas tiene que ser realmente útiles para el equipo o personal que los analiza ya que se puede cometer el error de crear alertas con parametrizaciones incorrectas las cuales pueden42 28 generar muchas alertas lo que provocaría pérdida de tiempo en analizarlas o en su defecto que el personal responsable no realice la gestión necesaria o pasar por alto una alerta importante debido a la falta de credibilidad de las alertas creadas. Adicionalmente hoy en día muchas empresas ofrecen servicios las 24 horas o en su defecto tienen líneas de producción que no se detienen sin embargo dependiendo de la hora del día o temporada los niveles de producción pueden cambiar, por lo tanto también se recomienda definir horarios de alertas para validar los comportamientos de los servicios en determinados tiempos de producción los cuales generan un proceso más efectivo y no genera falsas notificaciones o pérdida de recursos al analizarlas. Cabe notar también que si bien se puede y es importante tener la documentación de las alertas, clasificaciones y eventos monitoreados para el debido control de los mismos, es necesario que exista el apoyo necesario de que el proceso de gestión de eventos debe tener herramientas que apoyen el proceso en sí y por ende lo automaticen ya que de ser el proceso manual el objetivo de la gestión de eventos no se cumpliría Gestión de Incidencias (Operación) La Gestión de Incidentes se enfoca principalmente en la restauración del servicio de la forma más efectiva posible ante el acaecimiento de cualquier evento que pueda disminuir la calidad o continuidad de los servicios ofertados a los clientes internos y externos. Los incidentes pueden ser reportados por el cliente interno o externo o a través de los canales establecidos como correo electrónico, telefónicos, herramientas de gestión de tickets o a su vez reportados por el personal técnico sean identificados por tareas de mantenimiento o por intermedio de la gestión de eventos.43 29 Siendo la Gestión de Incidentes uno de los primeros procesos a implementarse por el alto retorno que implica para la empresa su correcta implementación, es decir que mediante la gestión de incidentes se puede minimizar el impacto de los incidentes ya que permite identificarlos y resolverlos previniendo un crecimiento del impacto sobre los servicios afectados, permite de igual forma prevenir posibles incidentes al trabajar en conjunto con la gestión de eventos y por ende alinear las actividades de gestión de la operación con el negocio al priorizar los incidentes según el grado de prioridad definido. El empezar a trabajar en la resolución de los incidentes lamentablemente es una trabajo reactivo ya que solo se puede empezar a trabajar en ellos cuando está sucediendo, tomando en cuenta que esto no es beneficioso para la organización, sin embargo el objetivo siempre será monitorear todo el sistema de la forma más efectiva posible para que así cuando los incidentes sucedan, la gestión de incidentes entre en marcha y por ende minimizar el impacto que pueda darse. Por lo tanto es necesario que cada empresa defina un proceso de gestión de incidentes que se ajuste a sus necesidades pero como recomendación, basándose como tal en las mejores prácticas establecidas en ITIL como se describe a continuación en la figura 3.44 30 Figura 3 Proceso de Gestión de Incidentes (Office of Government Commerce OGC, 2007)45 31 Una vez definido las diferentes formas en las que se puede identificar los incidentes ahora se los debe registrar. El registro de los incidentes es muy importante ya que es la información base que se usará para el análisis y posterior resolución del incidente, de ahí resulta necesario definir qué información se va a registrar en cada incidente identificado. Dentro de la información posible identificada por ITIL en su publicación tenemos (Office of Government Commerce OGC, 2007): Número de referencia única. Categorización del incidente Urgencia Impacto Prioridad Fecha y hora del incidente Persona o identificación quien reporta el incidente Método de identificación Forma de contacto Descripción del incidente Estado del incidente Elementos de configuración relacionados Equipo o persona asignada Problema o error conocido relacionado Actividades relacionadas para la resolución del incidente Hora y fecha de resolución Categorización de cierre Hora y fecha de Cierre Como parte del registro se categorizó el incidente lo cual vamos a profundizar un poco más ya que el categorizar los incidentes implica una adecuada definición tanto en los niveles de categorización así como la categorización en sí y más aún cuando cada organización tendrá su propia definición, por tal motivo es necesario que para la categorización y los sub niveles, éstos sean definidos por las áreas involucradas haciendo sesiones de trabajo que permitan depurar la categorización,46 32 una vez establecida la primera versión, se deberán definir periodos de prueba en la cual con datos reales se confirme que la categorización definida es correcta. La categorización debe ir enfocada al uso posterior para toma de decisiones y análisis de los incidentes De igual forma dentro del registro del incidente se especificó la prioridad la cual permite definir un orden en la gestión de los incidentes en base a qué tan rápido es necesario atender el incidente (urgencia) y el nivel de impacto que puede causar el incidente sobre el servicio. Sin embargo el determinar la prioridad en base a urgencia e impacto no es tan sencillo ya que debe ser analizada según el tipo de negocio y así definir qué matriz de prioridad se va utilizar. La urgencia normalmente es definida es un aspecto subjetivo el cual es analizado por el equipo encargado según la situación del incidente. El impacto por otro lado es un aspecto que debe ser concebido según los aspectos más importantes para el negocio, por ejemplo por tipo de cliente afectado, número de transacciones o servicios afectados, credibilidad organizacional, legal, perdida financiera etc. ITIL dentro de su publicación propone un sistema de código de prioridad el cual se detalla a continuación.47 Gráfico 1 Sistema de priorización simple (Office of Government Commerce OGC, 2007) 33 Sin embargo se puede ir más en detalle siguiendo la matriz de puntajes y asignación de prioridades (ITSM Solutions, 2007) segregando el impacto para que pueda ser analizado con mayor detalle. Dentro de la Tabla 4. Matriz de Puntajes para definición de prioridades se establece un sistema de puntaje, la urgencia la cual es subjetiva siendo un parámetro que es analizado según el tipo de incidencia, previamente definida y comunicada a las áreas encargadas. Los aspectos de Impacto deben ser definidos por la importancia para la empresa según los tipos de servicios e impactos que distinguen el impacto de un incidente, como se mencionó anteriormente estos pueden ser tipo de cliente afectado, número de transacciones o servicios afectados, credibilidad organizacional, legal, perdida financiera etc. y dentro de cada aspecto definir los rangos de impacto que serán puntuados dependiendo donde coincida el incidente identificado. Tabla 3 Matriz de puntajes para definición de prioridad Puntaje Urgencia Impacto Aspecto1 Aspecto2 Aspecto3 Aspecto4 3 Crítica Rango A Rango A Rango A Rango A 2 Alta Rango B Rango B Rango B Rango B 1 Media Rango C Rango C Rango C Rango C 0 Baja Rango D Rango D Rango D Rango D Una vez establecida la Matriz de puntajes se debe definir la Tabla 5. Matriz de asignación de Prioridades en donde obtendrá la prioridad del incidente, los marcos de resolución y las acciones a tomar en base a la prioridad. El rango de puntaje está48 34 en base al número de columnas definidas en la Matriz de puntuaciones por el puntaje máximo definido, es decir para la matriz de ejemplo serían 5 columnas (urgencia más 4 aspectos de impactos) por 3 que es el valor máximo dando el puntaje máximo de prioridad 15. Los rangos posteriores para las prioridades deberán ser definidos y acordados por las áreas encargadas. Tabla 4 Matriz de Asignación de Prioridades Puntaje Prioridad Respuesta/Acciones Marcos de Resolución Crítica Acciones A Tiempo Alta Acciones B Tiempo Media Acciones C Tiempo Baja Acciones E Tiempo 4 Una vez registrado, categorizado y priorizado el incidente se pasa al análisis en sí del incidente donde la primera línea de soporte es la encargada del mismo en base a la información que disponga en el ticket, bases de conocimiento y sets de validaciones para casos conocidos. Si la primera línea de soporte no puede resolver el incidente se debe pasar a las siguientes áreas encargadas según el proceso de escalamiento definido en cada organización, sean estos escalamientos funcionales o jerárquicos. Dependiendo de la complejidad del incidente la etapa de investigación y diagnóstico puede tomar tiempo por lo cual la asignación de recursos necesarios y las comunicaciones respectivas tanto al cliente en si del servicio como a las áreas encargadas en importante manejarlo siendo la primera línea de soporte el responsable del incidente en todo momento. Teniendo presente una posible solución del incidente sea que el usuario como tal tenga que realizar acciones en concreto o por intermedio de las áreas encargadas, se debe probar que las acciones realizadas para la solución del incidente hayan sido efectivas con lo cual se pueda pasar al cierre del incidente previa confirmación y49 satisfacción del cliente así como el registro y verificación de que la información relacionada al incidente haya sido guardada y relacionada al incidente en sí. 35 Es importante que se definan indicadores de rendimientos (KPIs) así como también indicadores de riesgo (KRIs), siendo lo KPIs métricas que permitan tomar decisiones de mejora en base los incidentes reportados por categorías, clientes, prioridades, por áreas de responsabilidad, tiempos de respuesta, tiempos de resolución, tiempo de vida de los incidentes etc. y los KRIs métricas que permitan identificar estados de riesgo que puedan perjudicar a la organización por ejemplo porcentaje promedio de respuesta definido en los SLA cerca del límite aceptado. Puntos de Riesgo: Dentro de los principales riesgos que se pueden encontrar en la gestión de incidentes se puede mencionar principalmente la falta de responsabilidad y/o incorrecto registro, categorización y priorización de los incidentes (Office of Government Commerce OGC, 2007) (van Bon, y otros, 2008) ya que el no hacerlo de una forma correcta tanto los análisis de mejora e información que sirve de entradas para otros procesos no sería valedera así como también no existe un respaldo de la gestión realizada y responsabilidades sobre la resolución o gestión de los incidentes. Otro riesgo existente identificado durante el desarrollo del presente proyecto es la falta de apoyo al proceso en sí desde la alta gerencia, sea por no asignar los recursos necesarios al proceso como herramientas adecuadas de gestión de incidentes que soporten la efectividad en la gestión de los incidentes o el no seguir los flujos definidos para el reporte de los mismo lo cual genera confusión, reportes paralelos de los mismo incidentes por varias personas y por ende pérdida de recursos tanto operacionales como en sí sobre la afectación del servicio. De igual forma se identificó que la falta de personal capacitado tanto en servicio al cliente como de conocimiento sobre los servicios ofertados también es un riesgo alto ya que puede repercutir en un mal trato al cliente o que en la resolución del incidente tome más tiempo del necesario o en su defecto una solución incorrecta50 lo que perjudica en la credibilidad tanto de la organización como del equipo encargado de la resolución del incidente. 36 Es importante notar que una correcta gestión de incidentes apoya directamente a los objetivos del negocio ya que al ser el objetivo principal de la gestión de incidentes el restablecimiento del servicio afectado en el menor tiempo posible hace que el impacto sea mínimo y por ende la empresa genere valor al cliente traducido en ingresos Gestión de Peticiones (Operación) La Gestión de Peticiones tiene como objetivo ser el canal de comunicación en el cual los usuarios puedan solicitar y recibir servicios, así como sus respectivos procedimientos para el uso de cada uno de ellos. Para que una Gestión de Peticiones se ejecute correctamente se debe definir claramente el tipo de peticiones que van a ser gestionadas para que el usuario pueda remitir sus sugerencias, quejas, etc. Por ejemplo, una petición de servicio puede ser una solicitud de desbloqueo de contraseñas de un usuario, actualización de una aplicación es una estación de trabajo o reportes, todas estas peticiones tiene frecuencia alta pero cada una no representa un riesgo para la empresa y por ende es preferible separarlo en un proceso diferente para que no afecte al proceso de incidencias que si implican un impacto en el servicio. Es importante identificar la diferencia entre Gestión de Peticiones y Gestión de Incidentes, conociendo la definición de cada uno, la petición de servicio es un requerimiento de información, asesoramiento, cambio estándar o acceso a un servicio por parte del usuario (van Bon, y otros, 2008) por lo cual se lo puede planificar, y la incidencia es un evento no planificado que puede impactar o reducir la calidad de un servicio.51 37 La Gestión de Peticiones permite a la organización definir un proceso para la gestión de servicios estándar y definidos de forma rápida y minimizando la burocracia incrementando la efectividad de los recursos y del proceso en sí. Las empresas podrán definir flujos para cada tipo de petición sea estas accesibles de selección y pasando por actividades de aprobaciones financieras según sea el caso así como también las actividades necesarias para la gestión en sí de la petición y el respectivo cierre previa aceptación y conformidad de quien lo solicitó Punto de Riesgo: Dentro de los principales riesgos en la Gestión de Peticiones es el diseño incorrecto de las interfaces de usuario (Office of Government Commerce OGC, 2007) en cual dificulten la presentación de peticiones de los usuarios así como la claridad y la comunicación de que servicios se tramitan a través de la gestión de Peticiones su procesos y flujos como tal. Otro riesgo es la capacidad insuficiente de monitorización que puede impedir la obtención de las métricas precisas para la evaluación de la Gestión de Peticiones. También se pueden pasar peticiones por la gestión de Incidencias por lo cual es importante que el personal responsable de la gestión de los requerimientos tenga claro los procesos y por ende asesorar a los usuarios ya que esto genera falsas incidencias y por ende puede caer en la asignación de recursos innecesarios. Otro punto de riesgo es el no definir los tiempos de respuesta y/o resolución de las peticiones por lo cual es necesario que se definan SLAs u OLAs (Office of Government Commerce OGC, 2007) para este tipo de requerimientos así el control y asignación de recursos es más efectivo. Se pueden implementar matrices de prioridades previamente acordadas, como se definió en la gestión de incidentes en donde los clientes sepan y estén claros de los rangos de tiempos y respuesta según el tipo de solicitud levantada Gestión de Problemas (Operación) La Gestión de Problemas es parte de los procesos definidos en la Operación del Servicio en donde se busca identificar las causa raíz de los incidentes para52 38 posteriormente establecer posibles soluciones a los mismos, siendo importante mencionar que un Problema es un evento no identificado, registrado o categorizado que puede generar el acaecimiento de varios incidentes provocando un impacto alto al servicio prestado y un Error conocido es el evento Problema que ya ha sido identificado, categorizado y registrado. La Gestión de Problemas trabaja en conjunto con la Gestión de Incidentes y son dos procesos altamente vinculados donde la Gestión de Incidentes busca el restablecimiento del servicio de la forma más rápida posible minimizando su impacto ante un incidente, mientras que la Gestión de Problemas como ya se mencionó anteriormente busca el entender el origen y solución del incidente. De igual forma la Gestión de Problemas además de buscar la causa raíz y solución a los incidentes también tiene un enfoque proactivo ya que se plantea el encontrar soluciones a posibles eventos o mejoras sobre la infraestructura de TI que minimicen las incidencias, incremente la disponibilidad de los servicios y garantice que tanto las soluciones dadas para los incidentes encontrados o posibles sean implementados de forma correcta basados en los procedimientos de control definidos. La Gestión de Problemas tiene dos procesos importantes como son la Gestión Reactiva realizada por la Operación del Servicio y tiene un flujo similar a la gestión de incidencias y la Gestión Proactiva donde trabaja en conjunto con la Mejora Continua del servicio analizando las incidencias, tendencias y posibles puntos de falla. La Gestión Reactiva contempla las siguientes actividades (van Bon, y otros, 2008): Identificación Registro Clasificación Priorización Investigación y Diagnóstico53 39 Decisión sobre soluciones provisionales Identificación de errores conocidos Resolución Conclusión Corrección de los errores detectados Figura 4 Proceso de Gestión de Problemas Reactivo (Office of Government Commerce OGC, 2007)54 40 Así como se realiza con la Gestión de Incidencias en la Gestión de Problemas también se debe identificar, registrar, clasificar y priorizar los problemas en donde según el impacto y urgencia del evento se definan la asignación de recursos necesarios para analizar y diagnosticar el mismo para su posterior solución temporal o definitiva del problema. Si para el problema se ha dado una solución temporal es importante mantener el seguimiento del problema e incluir toda la información necesaria que soporte la solución temporal para que de ser necesario en un futuro sirvan de fuente de consulta para una solución más rápida minimizando el impacto y por ende restableciendo el servicio lo más pronto posible. De igual forma de encontrar una solución definitiva al problema se puede plantear una solicitud de cambio sobre la infraestructura TI que será manejado por la Gestión de Cambios y así posterior a la validación de que la solución aplicada es correcta se procederá al cierre del problema y los incidentes relacionados. Punto de Riesgo: La gestión de Problemas se enfoca principalmente en mejorar la actual infraestructura TI (Office of Government Commerce OGC, 2007) que soporta los servicios ofertados a los clientes, por ende su relación con otros procesos dentro del ciclo de vida del Servicio como la Gestión de Disponibilidad, Capacidad y continuidad del Servicio, Gestión de Configuraciones, Gestión Financiera, Gestión de Niveles de Servicio en el cual de no aplicar una correcta Gestión de problemas la organización puede caer en mantener una acción en la solución de los incidentes solo de manera reactiva pero no buscando la causa raíz para así plantear soluciones que cambien la perspectiva a una gestión más proactiva, definiendo métricas que permitan analizar la efectividad del proceso e incluso definiendo métricas de riesgo que permitan alertar por ejemplo cuando no se cumplen los SLA definidos, numero de eventos sin solución, tiempo de resoluciones etc. La Gestión de Problemas al trabajar de la mano con la Gestión de Incidentes son los procesos que más resultados y beneficios presentan para la organización una vez implementados ya que permiten tener una idea clara de que sucede, restablecer los55 41 servicios ante un evento servicios ofertados. y plantear mejorar para una mejor prestación de los Gestión de Acceso (Operación) La Gestión de Accesos como tal es la encargada de otorgar o denegar permisos para el uso de los servicios ofertados a los clientes internos y externos aportando a la organización un mejor manejo de la confidencialidad de su información, minimizar el impacto de errores de ingreso o configuración de información por usuarios no autorizados o con una incorrecta calificación, permite monitorear y detectar el correcto uso o abuso de los servicios ofertados, cumplimiento en regulaciones de seguridad o controlando accesos a ambientes de alto riesgo si previa autorización. La Gestión de Accesos permite definir los niveles y alcances funcionales de un servicio por parte de los usuarios, permite identificar y asegurar que los usuarios sean autorizados al uso de un servicio los cuales están asociados a grupos de servicios con sus respectivos privilegios según corresponda. Los accesos pueden ser solicitados a través de un RFC, por la gestión de peticiones o por una acción autorizada en donde se procederá a verificar la solicitud de acceso tanto a nivel de autorización o si aplica la solicitud basada en las políticas y normas establecidas. De igual forma los roles de un usuario pueden cambiar con el tiempo sea por cambios de posición, actividades etc y por lo cual estos deben ser registrados y monitoreados sea que se deban revocar, limitar o cambiar. Según sea definido por la organización por el tipo de servicios que disponga para sus clientes internos o externos la identidad del usuario a registrarse puede variar sin embargo este debe ser único pero asociado a diferentes perfiles o roles de usuarios según el tipo de servicio y tipo de usuario ya que por ejemplo un usuario perteneciente al departamento de Tecnología puede tener acceso a servicios56 financieros por lo cual su usuario puede estar atado a diferentes grupos o perfiles según el cargo o tipo de usuario dentro del servicio. 42 Punto de Riesgo: En base a la experiencia adquirida, uno de los principales riesgos que presentan las organizaciones al no tener definidas políticas, normas sobre los accesos a los servicios es que pueden acaecer situaciones con mucho impacto para la organización como por ejemplo el uso de usuarios genéricos sin estar asociados a un perfil o grupo que determine que privilegios tiene sobre un determinado servicio lo cual podría implicar que un usuario accede a los ambientes de producción sea autorizados o no cambiar o alterar información sobre los servicios lo cuales pueden implicar robo de información, indisponibilidad de los servicios, integridad de la información o identificación de la persona responsable del mismo. De igual forma el no tener una Gestión de Accesos puede implicar asignaciones duplicadas o denegaciones a los servicios lo cual puede generar complicaciones en la operatividad de los servicios Mejora Continua del Servicio (MCS) El propósito de la Mejora Continua del Servicio MCS (o CSI por sus siglas en inglés) es mantener la alineación de los servicios de TI respecto de los objetivos del negocio durante todo proceso de cambio que esta tenga, implementando y mejorando los procesos que en sí soportan los servicios ofertados a los clientes. Como su nombre lo indica ésta mejora continua se la aplica a todo lo largo del ciclo del vida del servicio buscando la eficiencia y eficacia de los servicios para brindar un producto de calidad. Cada resultado de información que se obtiene de cada proceso y subproceso del ciclo de vida del servicio deben ser usados como entrada para el MCS para que se así se pueda entender, analizar las situaciones que suceden en la empresa, verificar las métricas obtenidas y por ende controlarlas.57 43 Existen cuatro términos utilizados comúnmente al hablar de los resultados que se obtienen al implementar mejoras en los servicios. (Office Government Commerce OGC, 2007) Mejoras: Resultados comparados entre el estado obtenido posterior a la implementación de la mejora y antes de la misma donde los KPI pueden ser favorables o desfavorables. Beneficios: Son las ganancias obtenidas posterior a las mejoras implementadas que normalmente pero no siempre son valores monetarios. ROI (Retorno de la Inversión): Es la diferencia entre los beneficios obtenidos y el valor invertido para la implementación de la mejora. VOI (Valor de la Inversión) : Es el valor agregado que se obtiene de los beneficios que incluyen los resultados no monetarios o de largo plazo siendo ROI un subcomponente de VOI. La Mejora Continua debe orientarse en la efectividad de los recursos y procesos que soportan los servicios ofertados buscando siempre las oportunidades de mejorarlos a través del ciclo de vida del servicio. Es así que existen varios principios sobre la Mejora continua del Servicio que son importante notarlos principalmente cuando posterior a la implementación de la Operación del Servicio según la metodología propuesta la información obtenida servirá de entrada para el análisis correspondiente y seguir con la implementación de los diferentes procesos del ciclo de vida propuestos en ITIL. Toda mejora implica cambio tanto a nivel de procesos como de la forma de trabajar de las personas por lo que el comprometimiento organizacional es importante donde la comunicación y el entendimiento de los beneficios a obtener por el cambio deben ser claros para evitar regresar a procesos anteriores, de igual definir el o los responsables de la gestión de mejora continua así como sus roles y responsabilidades ayudará al seguimiento y control de la correcta adopción e implementación de las prácticas de mejora definidas.58 44 Cada organización tiene aspectos internos y externos que pueden detener el progreso de la misma por lo que realizar un análisis FODA podrá dar una visibilidad a la organización de posibles oportunidades y fortalezas para mejorar, como de amenazas y debilidades a controlar. Uno de los principios clave de la Mejora Continua es la adopción del proceso de Gestión de Niveles de Servicio que en la actualidad permite establecer y orientar relaciones de confianza en función del cliente, donde la organizaciones definan un portafolio de servicios que pueda sustentar el desarrollo de un servicio de forma planificada y modular en donde la relación departamental se base en términos y responsabilidades establecidos en los niveles de acuerdos operacionales (OLAs), así como también permite definir un catálogo de servicios orientado al cliente, claro y transparente detallando sus costos y descripción del servicio manteniendo la calidad del mismo usando como base los acuerdos de niveles de servicio (SLAs), todos estos aspectos que contemplan una gestión de niveles de Servicio son parte esencial del diseño del Servicio en sí. Mantener como base importante de la mejora continua al ciclo de Deming permitirá una alta consolidación y un control continuo de la calidad del proceso como tal ya que se encontrará en constante evolución. De igual forma es necesario medir nuestros servicios estableciendo líneas base de control, métricas e indicadores de rendimiento operacional (KPIs) ya que así las organizaciones podrán validar decisiones tomadas, direccionar recursos para alcanzar los objetivos establecidos, justificar las diferentes actividades a desarrollar y por ende interviniendo en la inclusión de nuevos cambios o acciones correctivas. En la Figura 5 se define el modelo de Mejora Continua del Servicio.59 45 Figura 5 Modelo de Mejora Continua del Servicio (Office Government Commerce OGC, 2007) Como hemos visto el medir es parte fundamental de la Mejora Continua del Servicio donde no solo se abarca a nivel de administración de la organización sino de todo lo que contempla el ciclo de vida del servicio. ITIL en su publicación de Mejora Continua define el proceso de los 7 pasos de Mejora (Office Government Commerce OGC, 2007) los cuales se mencionan a continuación y permiten a su vez responder las interrogantes especificadas en el modelo de Mejora Continua del Servicio: 1. Definir qué se debería medir -- Dónde estamos ahora? 2. Definir qué se puede medir -- Dónde queremos estar? Cómo llegamos allá? 3. Obtener los datos 4. Procesar los datos 5. Analizar los datos 6. Presentar y usar la información -- Llegamos donde queríamos estar? 7. Implementar acciones correctivas Si bien los 7 pasos forman un círculo continuo (Figura 6.) estos a su vez constituyen una Espiral del Conocimiento (Figura 7). Donde se debe diferenciar60 46 entre Datos, Información, Conocimiento y Sabiduría (DIKW) donde los datos pueden ser cuantitativos o cualitativos siendo hechos o resultados obtenidos los cuales una vez reunidos son organizados y procesados para su posterior análisis e interpretación generando un conocimiento que a futuro servirá para una mejor toma de decisiones, esto lo llamamos sabiduría. Figura 6 Proceso 7 Pasos de Mejora (Office Government Commerce OGC, 2007)61 47 Figura 7 Espiral del Conocimiento. (Office Government Commerce OGC, 2007) La gestión del Conocimiento juega un papel importante en la Mejora Continua dentro de cada fase del ciclo de vida del servicio permitiendo a la organización conocer y entender la situación actual y por ende aplicar las acciones necesarias como se puede visualizar en la Figura 8 sobre el modelo DIKW (Data, Information, Knowledge, Wisdom)62 48 Figura 8. Modelo DIKW (Office Government Commerce OGC, 2007) De igual forma y no menos importante para la mejora continua del servicio es realizar procesos de benchmarking lo cual siendo una práctica estratégica de gestión permite encontrar las mejores prácticas que pueden ser implementadas según el tipo de negocio basados en casos de éxito de otras empresas así como también la adopción o uso de marcos de referencia, estándares, modelos y sistemas de calidad que permitan a la organización mejorar sus procesos y por ende la calidad de sus servicios. Puntos de Riesgo: La adopción e implementación del Proceso de Mejora Continua no es una tarea fácil donde cada organización tiene retos diferentes para lograr la implementación del proceso por lo cual existen varios factores que pueden deben ser considerados con el objetivo de iniciar y mantener el correcto desarrollo del proceso de Mejora Continua. Parte fundamental del proceso es tener el respaldo y comprometimiento de la alta gerencia para la consecución de los proyectos así como también de cada uno de los empleados de la organización en trabajar en equipo, responsables y comprometidos con su trabajo diario. Definir y comunicar los objetivos organizacionales es de igual forma importante ya que no se puede mejorar sino sabemos a dónde se quiere llegar por lo tanto los proyectos de mejora definidos deben estar enfocados a la consecución de los objetivos de la organización respaldados con los recursos humanos y tecnológicos necesarios, previamente presupuestados y priorizados de manera realista según la situación de la organización, manteniendo procesos de capacitación constantes que permitan adquirir conocimiento y por ende sean aplicados posteriormente. Realizar análisis FODA (Office Government Commerce OGC, 2007) así como la adopción de modelos de mejora continua como Deming, los 7 pasos de mejora, DIKW permiten identificar y mitigar riesgos como la toma de decisiones sin fundamentos o sin orientación, realizar tareas de mejora sin tener la información y por ende el conocimiento adecuado para generar acciones correctivas o de mejora alineadas a los63 49 objetivos del negocio, estrategias, diseños y transiciones definidas en el servicio sin una relación sistemática y de calidad que posteriormente se ven reflejados en la operación del servicio lo cual implicaría pérdida a nivel económico y de credibilidad de las organizaciones Funciones de la Operación del Servicio Las funciones son unidades especializadas en el cual incorporan todos los recursos y capacidades para cumplir los objetivos solicitados por los clientes: Centro de Servicio al Usuario El Centro de Servicio al Usuario es una unidad funcional que sirve como contacto entre usuario y la Gestión de Servicios IT. Los requerimientos solicitados por los usuarios internos y externos pueden llegar a través de llamadas telefónicas, por portal web o por herramientas de Gestión de Tickets. Centro de Servicio al Usuario ofrece mejorar el servicio al cliente incrementando el nivel de satisfacción entre los clientes. Permite solucionar de forma rápida las peticiones de clientes y usuarios. Reducción de costos mediante la asignación correcta de recursos. Un Centro de Servicio al usuario se puede estructura de 5 formas: Centro de Servicio al Usuario Local: ubicados en un mismo lugar que los usuarios a los que se están siendo atendidos Centro de Servicio al Usuario centralizado: Son Centros de servicios locales centralizados en uno solo punto permitiendo el contacto con los usuarios a través de una sola estructura. Centro de Servicio al Usuario virtual: es un centro de servicio que se mantiene comunicadas mediante redes con los usuarios.64 50 Follow the sun Servicio 24x7 : son centros de servicios ubicados en distintas zonas horarios permitiendo cubrir las 24 horas del día durante los 7 días de la semana. Grupos de Centros de servicio especializados: los incidentes muy específicos son derivados a grupos especializados con mejor capacidad para resolverlos. Puntos de Riesgos: En la implementación de un Centro de Servicio de usuario se tienen algunos puntos de riesgos, uno de ellos al tener varios canales de comunicación no es posible llevar un control o registros de todas las incidencias reportadas al soporte de usuario. La atención al cliente no es rápida y proactiva teniendo una insatisfacción del cliente Gestión Técnica La Gestión Técnica comprende un grupo de personas con experiencia y con conocimientos técnicos. La Gestión técnica sirve de guía a la Operación de TI y gestiona las operaciones tecnológicas. La Gestión Técnica contribuye a la organización a obtener acceso al tipo y nivel de recursos humanos que sean necesarios para gestionar la tecnología permitiendo cumplir los objetivos de negocio. Las principales actividades de la Gestión Técnica es identificar los conocimientos necesarios para la gestión de la infraestructura de IT, intervención en el diseño, pruebas y rendimiento de nuevos servicios. La Gestión Técnica está involucrada en cada una de las gestiones de la organización, en la Gestión Financiera ayuda identificar el costo de tecnología y recursos humanos para la prestación de servicios, en la gestión de problemas e incidencia ayuda a resolverlos, en la gestión de cambios son la mayoría de veces ejecutadas por la gestión técnica, en la mejora continua ayuda a identificar las actividades de mejora continua.65 Gestión de Operaciones de TI La principal actividad de la Gestión de Operaciones de TI es realizar el mantenimiento y mantener la estabilidad de la infraestructura de TI. Los objetivos de la Operación de IT es buscar métodos de mejora para conseguir un mejor servicio a menor costo y adaptándose a los requisitos y demandas del negocio. Las métricas de la operación de TI mide la eficacia de la implementación y ejecución de las actividades y procesos. La Gestión de Operaciones de TI usa documentos como: Procedimientos de Operación Estándar: contiene instrucciones detalladas y planes de actividades para cada equipo o grupo de gestión de operaciones de TI. Registros de operaciones: Todas las actividades ejecutadas por la operación de TI deben registrarse. Planes de turnos o informes: detallan que actividades deben realizarse durante el turno. La Gestión de Operaciones se compone a la vez de 2 sub-funciones: Control de Operaciones la cual se encarga principalmente de la ejecución y monitoreo así como de cualquier evento relacionado a la infraestructura de TI. La Gestión de Instalaciones se preocupa por la administración de las instalaciones físicas, centro de datos, energía, servidores, refrigeración etc. Así como también en apoyar para la ejecución de proyectos de importancia. Puntos de riesgo: No aplicar las actividades de la Operación de TI se tiene los riesgos de no conocer el resultado de la prestación de los servicios, no se puede66 realizar la programación de tareas como backup y restauración de archivos, no se tiene tiempos de respuesta a eventos o resolución de incidentes Gestión de Aplicaciones La Gestión de Aplicaciones está encargada de gestionar las aplicaciones en su ciclo de vida, en el diseño, prueba y mejora. Afecta a las aplicaciones adquirida o desarrolladas internamente. El rol de la gestión al momento de desarrollar una aplicación interna es: Dar los conocimientos técnicos para la gestión de las aplicaciones Proporcionar recursos que para el soporte de Ciclo de vida de la Gestión de Servicios de TI. Indica cual es la mejor forma de efectuar la gestión operativa de las aplicaciones. Integración entre el Ciclo de Vida de la Gestión de Servicios TI y el ciclo de la Gestión de Aplicaciones. Las fases de la gestión de aplicaciones dentro de la Operaciones del Servicio son (van Bon, y otros, 2008): Requisitos: se debe recopilar los requisitos en base las necesidades de la organización, existen requisitos funcionales, de gestión usabilidad, arquitectura, interfaz y nivel de servicio. Diseño: se encarga de reunir todos los requisitos y convertirlas en especificaciones. La arquitectura para el diseño y la operación es lo más importantes en esta fase. Construcción: Despliegue Operaciones Optimización67 53 3 Caso de Implementación 3.1 Objetivo Implementar la metodología propuesta en una organización y analizar los resultados obtenidos posteriores a la implementación. 3.2 Alcance La implementación estará enmarcada bajo los puntos especificados en la guía metodológica. De igual forma la información presentada podrá ser parcial a modo de ilustración por motivos de confidencialidad de la información de la organización sin embargo los resultados y conclusiones finales serán en base a la totalidad de la información obtenida en los análisis correspondientes. 3.3 Desarrollo La Organización YellowPepper es un startup de tecnología fundada en el 2004 que tiene su holding en el centro de Miami así como sus agencias regionales en Ecuador, Colombia, Perú y México quienes son los encargados de mantener la operación en toda la región adicionando a los países antes mencionados a Bolivia, Panamá y Guatemala que son los países en donde sus servicios se encuentran operativos. YellowPepper es el pionero en América Latina en proveer soluciones Móviles Financieras y de Pagos a grupos e instituciones financieras de la región generando la posibilidad de procesar alrededor de 25 millones de transacciones mensuales a 4 millones de clientes. Dentro de sus productos ofrecen la Banca Móvil que a través de la tecnología SMS crearon sus primeros productos para posteriormente avanzar con el desarrollo de aplicaciones financieras nativas sobre teléfonos inteligentes en plataformas BlackBerry, Android y ios. Actualmente buscan expandir sus productos poniendo68 54 sus objetivos organizacionales en ser líderes en pagos móviles a través de sus productos Smart Banking 3.0 y Yepex App soportados por la plataforma ME (Mobile Everywhere) Misión / Visión / Valores Organizacionales. YellowPepper tiene definida su visión como el de convertir a los pagos móviles en una aplicación estándar en las Américas Vision: Become the Mobile Payment standard application in the Américas La Misión es hacer que los pagos móviles sean una realidad Mission: Make mobile payments a reality Los valores organizacionales definidos se detallan: Transparencia Trabajo en equipo Honestidad Mejoramiento Continuo Trabajo + Vida no Vida versus Trabajo: Work + Life not work vs life Comprometimiento Responsabilidad Mejora Continua del Servicio (Situación Inicial) Si bien el Proceso de Mejora Continua actúa en todo el ciclo de vida alimentando los procesos según las mejoras identificadas sirve también de punto de inicio para que basándose en la visión y misión establecidas se pueda establecer la situación actual de la organización, departamento o proceso que se quiere mejorar para posteriormente definir a donde se quiere llegar y así establecer las acciones necesarias para cubrir la brecha existente.69 55 Es por esta razón que se realizaron sesiones de trabajo principalmente para determinar las Fortalezas y Debilidades que son relacionadas al ambiente interno sobre la infraestructura que soporta los servicios de TI. Fortalezas: Se dispone de presupuesto para mejorar y actualizar la infraestructura que soporta los servicios de TI. Apoyo por parte de la alta gerencia para implementar cambios radicales sobre el actual ambiente de producción. Se dispone de una misión y visión definida. Debilidades: No existe una definición clara del organigrama funcional así como de los roles y responsabilidades de cada puesto de trabajo. No existe documentación acerca de la Red, configuración de servidores, dispositivos de red. No existe un archivo de claves actualizado Tiempos de respuesta ante requerimientos alto Hardware antiguo Falta de inventario de HW, SW, DB Licencias caducadas Soporte caducado No se dispone de una priorización de los requerimientos recibidos en el área Monitoreo de elementos de configuración incompleta y en ocasiones incorrecta. Gran cantidad de alertas falsas son generadas No se tiene una gestión de Problemas y Acceso por separado.. No existe estabilidad en los servicios. Puntos únicos de falla en la infraestructura de TI. En base a las fortalezas y debilidades identificadas se definieron los siguientes objetivos:70 56 Tener una infraestructura de TI alineada con los objetivos del negocio que soporte los actuales servicios internos y externos. Tener una infraestructura de TI que tenga la capacidad de ser flexible y escalable para soportar nuevos servicios. Tener una infraestructura de TI segura y de alta disponibilidad que además de brindar el soporte completo de los servicios ofertados ayude a los clientes internos en su trabajo diario maximizando su efectividad para proveer servicios de calidad a los clientes externos. Para el cumplimento de los objetivos trazados se definieron los siguientes planes de acción macro: Identificar, conocer e inventariar la infraestructura de TI actual Identificar riesgos actuales, analizar su impacto y probabilidad de ocurrencia Crear documentar y mejorar procesos necesarios Reducir gastos incrementar ingresos Mejora continua de HW, Aplicaciones, Procesos y Documentación. Establecidos los lineamientos se realizó la implementación de procesos y mejoras siguiendo como base la metodología propuesta que se especifica con más detalle cada paso a continuación Estructura Organizacional YellowPepper al ser un start up y desde su creación ha tenido grandes cambios innovando productos que estén bajo su filosofía por lo cual, debido a su crecimiento y potencial, han buscado profesionales que permitan crear, mantener e innovar estos productos sin embargo por una falta de atención en el aspecto organizacional se generó un desorden en el manejo de sus recursos humanos lo cual ha implicado pérdida a la empresa por la incorrecta selección del personal para un determinado cargo o la sobrecarga de personal en áreas de trabajo con sueldos altos71 que en resumen generaban gastos altísimos a la compañía pero los niveles de productividad y calidad cada vez disminuían. 57 En el primer semestre del 2013 hubieron cambios radicales para la organización tanto financieros como de orientación que principalmente se enfocaron en reducir los gastos, maximizar ingresos y mejorar la calidad de los servicios actuales así como orientar todo trabajo en función de estar alineados a su nueva misión, visión y valores organizacionales. Por lo cual a nivel organizacional se hizo un análisis de cada rol en todos los departamentos con sus funciones y responsabilidades contratadas, se validó la efectividad de cada empleado en cada rol y confirmación de las tareas diarias, semanales y mensuales realizadas por cada empleado para posteriormente ser validadas con el rol asignado. En base al análisis realizado la organización redujo casi en un 50% a su personal y por ende se definió una nueva estructura organizacional que sería revisada en 6 meses a manera de control y validación de la efectividad de la nueva estructura. A modo de muestra para la presente tesis se detalla el análisis realizado en el área de Operaciones y el área de Soporte del departamento de Tecnología. El área de Operaciones se conformaba por 5 puestos de trabajo definidos de la siguiente forma: Operations Manager o SysAdmin o Reporting Engineer o Dev Op Engineer o Production DBA o DBA Dentro del análisis realizado los puntos sobresalientes fueron los siguientes:72 58 La posición de Operations Manager se encontraba vacante por casi dos años, El Support Manager tomó interinamente el rol por motivos de continuidad del negocio sin embargo no existía un empoderamiento total del cargo lo que generaba problemas internamente. Se identificó que dos personas ocupan el rol de DBA con particularidades que una de éstas personas se dedicaba específicamente a realizar backups y mejoramiento de querys en caso de incidentes reportados sobre las bases de datos de producción y la segunda persona de igual forma realizaba tareas de administración y mejoramiento de las bases así como soporte de nivel 2 y administrador de una plataforma interna de SMS. De igual forma se identificó que la persona de Reporting solo se dedicaba a realizar reportes específicos de clientes y dedicado al proyecto de Data Warehousing, adicionalmente la efectividad en la entrega de los requerimientos y proyectos no eran cumplidos a tiempo o necesitaban revisión por parte de uno de los DBA. En temas de remuneración la brecha entre cada uno de los integrantes era muy grande a pesar de las responsabilidades y carga operativa era mayor. A nivel general el equipo se encontraba desmotivado, sin un horizonte a donde trabajar y por ende no existía el comprometimiento necesario para suplir todas las tareas a realizar dentro del área. El promedio de resolución y entrega de los requerimientos eran altos y con errores. Una vez realizado el análisis de cada tarea realizada por cada integrante del área, efectividad de cada uno de ellos, experiencia, conocimiento e identificar las brechas para cubrir los puestos de trabajo deseados se definió el siguiente organigrama para el área de Operaciones con la respectiva definición del rol y responsabilidades de cada puesto de trabajo. Ver Anexo A. Operations Manager o SysAdmin o DBA73 59 o Networking Engineer Posteriormente se realizó el mismo análisis con el área de soporte a diferencia que todos tienen el mismo cargo y trabajan en horarios rotativos por cual se enfocó más en identificar el número de personas necesarias para cumplir un servicio de 24X7 y que pueda atender de mejor manera los requerimientos recibidos. El equipo de soporte se conformaba por 6 personas las cuales hacían turnos rotativos h1: 6:30 a 14:30 h2: 14:30 a 22:30 h3: a 6:30 y h4 de 9:00 a 18:00. Dentro de los problemas identificados principalmente se daba a los altos tiempos de respuesta en la atención de requerimientos, falta de monitoreo de aplicaciones y plataformas así como también problemas de comunicación en el paso de información y requerimientos pendientes entre turnos. Tomando en consideración que el área de Soporte y Operaciones eran los niveles de escalamiento 1 y 2 correspondientemente, tomando en cuenta que el soporte a nivel del lado de aplicaciones que se encargaba el área de arquitectura ahora debía ser soportado en su totalidad por el área de operaciones y considerando que el Jefe de Soporte tomó el liderazgo interinamente de las dos áreas se decidió unir las dos áreas en una sola teniendo como organigrama final de la siguiente forma Como cambio final se definió que el turno h4 no sería rotativo y se designó a una persona del equipo para que ocupe este turno con responsabilidades adicionales en el seguimiento continuo de los tickets así como ayuda operativa para tareas en específico con el área de Operaciones principalmente para soportar la carga de requerimientos manejados antes al área de Arquitectura. Operations Manager o SysAdmin o DBA74 60 o o Networking Engineer Support Team IT Support Engineer (6) Gestión del Catálogo de Servicios. Para la generación del Catálogo de Servicios en primera instancia se realizaron reuniones de trabajo entre las áreas Comercial, Producto y Tecnología con el objetivo de levantar y cruzar la información sobre los servicios que actualmente son soportados en producción, cuáles de ellos son todavía comercializados y confirmar la definición de cada servicio con el área de producto. Como resultado de las sesiones de trabajo realizadas se definió una clasificación de los servicios de manera interna y externa donde a la vez de manera externa se dividió en tres secciones desde lo general a lo particular, es decir: Categoría Producto Servicio. De igual manera se definieron términos de identificación para cada categoría, producto, servicio externo ya que existían confusiones internas de la definición de los servicios a nivel de soporte como los servicios a nivel comercial generando problemas en los requerimientos y reportes solicitados entre los problemas más concurrentes.75 61 A continuación el Catálogo de Servicios Resumido definidos en su primera fase. Servicios Internos: Tabla 5 YellowPepper Servicios Internos Tipo Nombre del Descripción Servicio Interno, Web Servicio de Correo Electrónico Google Interno Comunicaciones Servicio de Telefonía e Internet manejado por Operaciones. Otros países manejado por personal de cada país. Interno Help Desk Servicio técnico personalizado para Ecuador remotamente para otros países Interno, Web SAP Aplicación de uso solo del departamento Financiero Servicios Externos Tabla 6 YP Catalogo de Servicio Resumen Tipo Categoría Producto Servicio Descripción Externo, Web Text Banking SMS Notificati ons (MT) Metrobroadcast Envío de 1 mensaje a varios destinatarios en un solo consumo del servicio Continua76 62 Text Banking Top Ups Metroline Metroline Prio Metro SMS Text Banking Remote Payment Web Envío de 1 mensaje a 1 destinatario en un solo consumo del servicio Envío de 1 mensaje a 1 destinatario en un solo consumo del servicio definiendo la prioridad del mensaje Aplicación web para envíos de notificaciones manuales estáticos y dinámicos Servicio que permite a los clientes solicitar un servicio a través de SMS Servicio de recargas tiempo aire mediante consumo de Web Service Servicio de recargas tiempo aire mediante una interfaz Web propia otorgada al cliente. Continua77 63 Externo, Smart Smart Smart Aplicación banca móvil Web Banking Banking Banking donde se puede tener servicios como transferencias, información de cuenta, recargas, retiros realidad aumentada entre sus principales servicios Smart Smart Aplicación banca móvil Banking Banking donde se puede tener LITE LITE servicios basicos como transferencias, información de cuenta, recargas, retiros. Mobile Smart PERA Aplicación para pagos Externo, Payments Payment móviles Web Client PERA Aplicación para pagos App móviles (SOCIA) Smart Banking Aplicación banca 3.0 móvil donde se puede tener servicios como transferencias, información de cuenta, recargas, retiros realidad aumentada entre sus principales servicios Continua78 64 Yepex App Yepex App Aplicación que une las caracteristicas de smart banking 3.0 y PERA desarrollado especificamente para transformar la forma de pago de los clientes De igual forma con el área comercial se trabajó en definir una priorización de los servicios en producción enfocado principalmente para que cualquier gestión en todas las áreas se pueda priorizar las tareas por tipo de cliente y tipo de servicio por importancia para la organización. El área comercial y producto en base al análisis y tipo de servicios definieron una matriz de 3 niveles: Alta (3), Media (2), Baja (1) en donde los servicios fueron priorizados de la siguiente manera. Tabla 7 Priorización de Servicios Servicio Prioridad Metrobroadcast 2 Metroline 2 Metroline Prio 2 Metro SMS 2 Text Banking 2 Remote Payment 1 Web 1 Smart Banking Smart Banking LITE 3 PERA 3 Yepex App 379 Gestión de la Configuración y Activos del Servicio La falta de seguimiento y actualización del inventario de equipos es uno de los problemas que se identificaron principalmente cuando se necesitaba validar la procedencia de un servicio o verificar un incidente en producción. Por lo cual en primera instancia se definió que para la primera fase el alcance sería sobre la infraestructura que soporta los servicios de producción y pruebas. Posterior a la misma se definió las categorías de Elemento de Configuración a identificar así como el detalle de información que cada CI iba a tener dependiendo del tipo de categoría. Para el levantamiento de Hardware se realizó un viaje a Miami en el mes de Septiembre de 2013 debido a que el centro de datos de YellowPepper se encuentra en el NAP de las Américas en el cual se cotejó el inventario financiero con el último inventario de tecnología, adicionalmente se etiquetó todos los equipos y se reorganizó el espacio posible en los Rack con la visión de nuevo HW que iba a ser adquirido en el mes de Diciembre. De igual forma se definió las categorías de los CI a levantar así como las características de cada CI las que se detallan a continuación. Categoría Aplicaciones: General o Nombre de Aplicación o Categoría o Producto o Servicio o Cliente o País o Tipo Interno Externo80 66 o Estado Activo Inactivo Interfaz Gráfica de Usuario o Aplicación URL o Web Service URL Servidor o Servidor de Producción o Nombre Servicio de Windows o Ruta de Aplicación en Servidor SMS y Recargas tiempo Aire o Ruta del Servidor de los archivos de conciliación o Operadora Celular o Código Corto Categoría Hardware: General o Nombre o Tipo Firewall Router Switch Load Balancer Server Storage Otro o Marca o Modelo o Serial o YP Code o Virtualizado (SI/NO) o Producto81 67 Garantía o Fecha de Compra o Garantía (SI/NO) o Soporte (SI/NO) o Leasing(SI/NO) Hardware o Procesador o Numero de Procesadores o Arquitectura 32 bits 64 bits o Memoria o Disco Duro o Hardware Remoto o NIC o Puerto Ubicación o Rack o U_Rack o Numero U o Dispositivo de Red o Puerto Dispositivo de Red o PDU Red o o o o o VLAN IP Interna IP Externa Heartbeat (SI/NO) Dispositivo Heartbeat82 68 Categoría Software: Nombre Software Base (SI/NO) Número de Licencias Renovación: o Mensual o Anual o De por vida Soporte NO 1 año 2 años 3 años Categoría Base de Datos: Nombre País Servidor de Base de Datos Estado de Base de Datos Base Histórica (SI/NO) Ubicación Respaldo Base de Datos Categoría Proveedores: Nombre Página Web Servicios Información de Contacto Notas adicionales Una vez definida las categorías y la información necesaria para cada CI se automatizó el registro de los CI acoplando la herramienta de proyectos JIRA para el registro de los CI en el cual se creó un proyecto llamado CMDB donde se tiene la posibilidad de escoger que tipo de CI se desea ingresar.83 69 Gráfico 2. Categorías para ingreso de un CI en proyecto CMDB JIRA (imagen ampliada Anexo C) Una vez seleccionada la categoria a ingresar cada uno tiene diferentes pantallas y tab de selección. Gráfico 3 Pantalla de ingreso CI de Aplicaciones (imagen ampliada Anexo C) Gráfico 4 Pantalla de Ingreso CI de Hardware (imagen ampliada Anexo C)84 70 Gráfico 5 Pantalla de Ingreso CI de Software (imagen ampliada Anexo C) Gráfico 6 Pantalla de Ingreso CI de Base de Datos (imagen ampliada Anexo C) Gráfico 7 Pantalla de Ingreso CI de Proveedores (imagen ampliada Anexo C) De igual a través de la herramienta se puede buscar y personalizar reportes de los CI ingresados según se requiera.85 71 Gráfico 8 Pantalla de buscador personalizado de CIs (imagen ampliada Anexo C) Adicionalmente el proyecto CMDB tiene relación con el proyecto de Customer Support por lo se puede relacionar el CI asociado al incidente, petición de servicio o acceso solicitado por el cliente permitiendo una mayor efectividad en los requerimientos recibidos así como análisis posteriores para la acciones correctivas necesarias. Gráfico 9 Relación CI con Ticket creado en Customer Support Project (imagen ampliada Anexo C) Gestión de Eventos A nivel de Gestión de Eventos YP presentaba dos situaciones particulares. Disponía de una herramienta de Monitoreo la cual fue configurada por personas externas a la organización, no existía la documentación relacionada de roles, cual fue la definición de monitoreo y que CIs se encontraban monitoreados, además existía una gran cantidad de alertas que eran enviadas al área de soporte las cuales no eran revisadas en primer lugar porque no reflejaban valores correctos y segundo por la86 72 cantidad en sí. Cabe notar que esta herramienta de monitoreo Nagios XI tenía la licencia caducada y ninguna de los empleados recibió una capacitación para la administración de la herramienta o conocimiento al respecto. De igual forma Nagios XI solo monitoreaba los CIs de Hardware y Bases de Datos. En segunda instancia debido a la personalización de las aplicaciones entregadas a los clientes se dispone de una herramienta de monitoreo local la cual permite configurar consultas según la información almacenada en la base de datos y así identificar eventos que puedan afectar al servicio sin embargo pocas aplicaciones eran monitoreadas y no se tenía una definición base a monitorear. Como primer paso fue mantener reuniones entre el área de Operaciones y Soporte para poder identificar la situación actual y definir que se debería medir para tener una visión más completa de lo que sucede con la infraestructura que soporta los servicios de TI y a la vez orientarse a la proactiva y no a la reactividad más aún reportada por los clientes. A nivel de la aplicación de monitoreo Nagios XI se identificaron los siguientes riesgos: Problemas para reconfigurar, agregar y administrar la herramienta Nagios XI principalmente por la falta de conocimiento sobre la herramienta Hardware agregado a la infraestructura de producción no está monitoreada Gran cantidad de alertas no presentaban información real sobre los dispositivos y servicios monitoreados, así como generaban carga operativa al equipo de soporte en la revisión de las alertas recibidas. Dentro de las acciones tomadas al respecto se tomó un curso online de parte del proveedor lo cual permitió principalmente al administrador designado de la herramienta y a todo el equipo de Operaciones y Soporte entender sobre la herramienta, las bondades de la misma y por ende depurar y reconfigurar la herramienta en base lo definido que contempla:87 73 Firewalls Balanceadores de Carga Servidores físicos y virtualizados o Disco Duro o CPU o Memoria Dispositivos de Red Web Services Bases de Datos Como se puede visualizar en el grafico 9 posterior a la depuración y configuraciones necesarias en Nagios XI actualmente se tienen 229 Host y 2030 servicios monitoreados sin embargo se mantiene constante revisión y ajuste de las alertas en base a los eventos suscitados o revisiones del sistema, también se disminuyó la carga operativa para monitoreo ya que no se pierde tiempo en revisión de alertas incorrectas. Gráfico 10 Operations Center YP Nagios XI88 74 Respecto a la aplicación de monitoreo de aplicaciones interna se definió crear 3 aplicaciones adicionales con el objetivo de poder distinguir y crear diferentes rangos de medición en diferentes tipos de aplicaciones. De igual forma se definió 53 alertas generales que se enfocan en analizar cada flujo y tipo de transacción por cada servicio en producción validando tanto errores del lado de YP como del lado del cliente para minimizar el impacto al cliente final ver Gráfico 10. Gráfico 11 Muestra de Archivo con cada alerta a ser generada para cada tipo aplicación y servicio en producción. (Imagen ampliada Anexo C)89 A pesar que las alertas son enviadas al equipo de soporte vía correo electrónico se cuenta con una interfaz web que permite visualmente identificar los estados según la alertas configuradas ver Gráfico Gráfico 12 Muestra de Interfaz de Monitoreo YP (Imagen ampliada Anexo C) Actualmente se tienen configuradas 768 alertas para 144 aplicaciones en producción.90 76 En la segunda fase del proyecto se definió analizar la información medida para configurar por horarios de tendencias, es decir además de medir el estado de una transacción también medir la cantidad de transacciones dentro de un determinado horario y día lo que permite tener un monitoreo más efectivo y minimizar aún más las alertas enviadas al equipo de soporte para su revisión y así poder destinar este tiempo para tareas de seguimiento y troubleshooting de los incidentes y requerimientos recibidos Gestión de Incidentes La Gestión de Incidentes en YP es uno de los procesos más estables sin embargo ha tenido varios cambios en los últimos tres años, se inició registrando los requerimientos en una hoja de cálculo lo cual llegó a un punto que se tornó ineficiente, posteriormente se automatizó el proceso donde se tuvieron dos migraciones a herramientas de gestión de proyectos lo cual implica acoplar la lógica del proceso a la herramienta y por ende tener limitantes al no trabajar en una herramienta dedicada para la gestión de tickets, este escenario se dio principalmente por la falta de presupuesto para la adquisición de una herramienta adecuada. De igual forma una de las dificultades para la implementación de este proceso fue la falta de colaboración y adopción de la cultura de tickets así como la informalidad para registrar y dar seguimiento a los requerimientos repercutiendo en la pérdida de confianza por parte del cliente por los tiempos de respuesta altos, falta de seguimiento y altos tiempos de resolución de los incidentes. A inicios del mes de Junio de 2013 se hizo una revisión del proceso, tanto de los responsables del proceso como del flujo en sí identificando los problemas siguientes: Ingreso incorrecto de los tickets generando problemas para poder obtener KPIs91 77 Requerimientos no eran registrados en la herramienta y por ende no se seguía el proceso definido generando problemas en el seguimiento de los incidentes así como el uso de los recursos para la resolución de los incidentes Tiempos de respuesta a incidentes altos Falta de seguimiento de los incidentes. Tickets abiertos por mucho tiempo sin gestión al respecto. Tiempos de respuesta y resolución de los niveles de escalamiento altos o sin respuesta. No existe una gestión de Problemas No existe una categorización clara de los incidentes No existe relación del CI afectado ante un incidente. Resolución de Incidentes sin priorización. Una vez identificados los riesgos que presenta el proceso se definieron las siguientes acciones: Revisión y definición de los campos a registrarse en cada ticket Depuración y actualización de los campos de cada ticket del último mes (Agosto) en base a la nueva definición y de los tickets abiertos Definición de la Matriz de Prioridad Roles y Responsabilidades de cada nivel de escalamiento Definición de Indicadores de Rendimiento Definición Plan de Soporte Se mantuvieron sesiones de trabajo con el equipo de soporte para reforzar la importancia de llenar correctamente los tickets con el objetivo de tener datos que permitan tener información adecuada para la toma de decisiones y mejora continua, de igual forma se definió en conjunto los campos a registrarse en cada ticket los cuales se presentan a continuación: Asignado Título (Mandatorio) Categoría92 78 Producto Servicio Ambiente afectado Descripción (Mandatorio) País Cliente / Operadora Componente (CI) Nombre de contacto (Mandatorio) Correo electrónico de Contacto (Mandatorio) Fecha de recepción del requerimiento Fecha de cierre del requerimiento Escalamiento Pendiente Urgencia Impacto Prioridad Incidente Categoría Incidente Sub-Categoría Una vez definido los campos a registrar en cada ticket se implementaron los cambios en la herramienta JIRA que nuevamente al no ser una herramienta para help desk se adaptó el proceso a lo permitido por la herramienta. Se especificó un tipo de error llamada production incident que será el identificador para los incidentes dentro del proyecto YP Customer Support.93 79 Gráfico 13 Pantalla de la pestaña Basics al crear un nuevo Incidente en JIRA (imagen ampliada Anexo C) Como se puede visualizar parte de los campos a registrar se encuentran información definida en el Catálogo de Servicios para que posteriormente pueda ser usado en la toma de decisiones. De igual forma la definición de una matriz de prioridades fue importante para mejorar el orden en que los requerimientos eran gestionados. Se trabajó en conjunto con el departamento Comercial y Tecnología para establecer una matriz de prioridades enfocada y alineada a los objetivos del negocio, para lo cual se especificaron los siguientes parámetros: Priorización de los clientes en base su importancia para la organización Priorización de los servicios actualmente en producción. Definición de las variables de impacto a considerarse en el acaecimiento de un evento. Definición de urgencia Definición de puntajes, acciones y marcos de resolución para matriz de asignación de prioridades. Una vez recibida la información de la priorización de los clientes y servicios desde la perspectiva del área comercial las variables de impacto fueron priorizadas94 asignando un valor de 3 como valor más alto y 0 valor más bajo. A continuación las variables de impacto definidas para la matriz de puntajes: 80 Cliente Porcentaje de Transacciones afectadas Número de Servicios Afectados Tipo de Plataforma afectada Urgencia De igual forma en base a los pesos establecidos los rangos para cada prioridad así como las acciones a tomar ante cada prioridad y los marcos de resolución fueron definidos.95 81 Gráfico 14 Matriz de Puntajes para asignación de Prioridades (imagen ampliada Anexo C) Gráfico 15 Matriz de Puntajes Respuesta y Marcos de Resolución (imagen ampliada Anexo C)96 82 De igual manera se definió el rol y la responsabilidad que tiene cada nivel de escalamiento durante la gestión de un ticket. Nivel 1 Equipo de Servicios Soporte Primer responsable del ticket y seguimiento hasta el cierre del mismo. Responsable de la comunicación del estado del ticket de forma interna y externa Responsable de la gestión del SLA del ticket Responsable por el direccionamiento correcto del ticket si así lo amerita. Nivel 2 Equipo de Operaciones Segundo responsable del ticket durante el proceso de resolución, comunicación del estado del ticket escalado al nivel 1 o direccionar al nivel 3 si así lo amerita Nivel 3 Equipo de Desarrollo Tercer responsable del ticket, resolución del ticket y comunicación hacia el nivel inferior. Los indicadores de rendimiento se han ido incrementando a medida que se mejoraba o implementaba cambios en el proceso de incidentes, por lo cual posterior a los 6 meses de trabajo se tienen establecidos los siguientes indicadores: Número de incidentes por País / Cliente Número de incidentes por Prioridad Número de incidentes por Producto / Prioridad Número de incidentes por Servicio / Prioridad Número de incidentes resueltos por cada nivel de escalamiento Promedio de tiempos de Respuesta Promedio de tiempos de Resolución97 83 A partir del mes de Agosto que se empezó con la revisión del proceso de Incidentes, durante los meses de Agosto y Septiembre se probaron y ajustaron las definiciones de campos a necesitarse en el registro de los incidentes, se mantuvo constante motivación con los equipos Operaciones y Soporte para lograr mayor comprometimiento en los tiempos de respuesta, registro de los tickets, escalamientos y resolución, Durante los meses de Noviembre y Diciembre se trabajó con el departamento Comercial, Tecnología y Desarrollo para que la matriz de Prioridades esté en producción desde el mes Enero 2014 posterior a su aprobación y sesiones de trabajo realizas validando la matriz con casos reales. Adicionalmente como parte del proceso de gestión de Incidentes se definió un Plan de Soporte (Ver Anexo B) que es parte del SLA que se entrega a los clientes lo que permite tanto al cliente como a YP tener un proceso establecido para la gestión de incidentes Gestión de Peticiones La Gestión de Peticiones al igual que la Gestión de Incidentes presentaba problemas similares como el registro incorrecto de los requerimientos, el no tener un orden y seguimiento de los requerimientos, información faltante para la toma de decisiones, tiempo de respuesta y resolución altos, por lo cual se procedió de manera similar a la revisión del proceso de gestión de Peticiones. Se definieron los campos a registrarse para los requerimientos de servicio: Asignado Título (Mandatorio) Categoría Producto Servicio Descripción (Mandatorio) País Cliente / Operadora98 84 Componente (CI) Nombre de contacto (Mandatorio) Correo electrónico de Contacto (Mandatorio) Fecha de recepción del requerimiento Fecha de cierre del requerimiento Escalamiento Pendiente Urgencia Impacto Prioridad Requerimiento Categoría Requerimiento Sub-Categoría Se configuró correspondientemente los cambios en la herramienta Jira Gráfico 16 Pantalla de la pestaña Basics al crear un nuevo Requerimiento de Servicio en JIRA (imagen ampliada Anexo C) Así mismo se usa como base la matriz de prioridades establecida para los incidentes para la gestión de los requerimientos de servicio considerando que al no haber impacto en los servicios de producción la prioridad estará dada en términos principalmente por el tipo de cliente, plataforma y urgencia del requerimiento. De igual manera se trabajó con los equipo involucrados la importancia del correcto escalamiento y registro de los requerimientos de servicio que si bien no99 85 impactan directamente a los servicios en producción ofertados puede verse afectado otras variables como de credibilidad y efectividad si los requerimientos no son atendidos correctamente por lo cual similares indicadores de rendimiento que se establecieron para la gestión de incidentes fueron establecidos para la gestión de Peticiones Gestión de Problemas La Gestión de Problemas es un proceso que no se tenía implementado en YP de forma correcta, se lo manejaba como parte del proceso de incidentes, se trabajaba de forma reactiva ante los incidentes y en muy pocas ocasiones se realizaban proyectos de mejoras en base a eventos suscitados que podía impactar a los servicios en producción. Para lo cual se implementó en un inicio un proyecto en Jira llamado Maintenance en el cual se escalaban tickets tanto de incidentes como de servicio para los niveles de escalamiento 2 y 3 que eran relacionados al ticket creado en Customer Support por el área de soporte sin embargo el problema principal de esta forma adoptada es que tickets referentes a incidentes a pesar que el servicio ya se había restablecido o en su defecto se dio un solución temporal al mismo, el ticket permanecía abierto sea por falta de asignación de recursos o era relegado por otros proyectos o tickets. Es con esto que se decide cambiar el proceso en el cual el proyecto Customer Support serviría para escalar los requerimientos hasta de nivel 2 y en el caso de que se necesite la búsqueda de una solución temporal o dar solución correctiva o minimizar su ocurrencia se escalaría a nivel 3 a través del proyecto Maintenance, adicionalmente en este proyecto se aumenta un tipo de ticket que permita establecer proyectos de mejora en base a los incidentes suscitados o en base a mejoras definidas para mantener la alta disponibilidad y calidad de los servicios ofertados.100 86 Gráfico 17 Pantalla de Ingreso de un ticket en el proyecto Maintenance en Jira (imagen ampliada Anexo C) De igual forma se definió usar la misma matriz de prioridades establecida para la gestión de incidentes en la gestión de problemas El proceso de Gestión de Problemas se implementó en Enero de 2014 por lo cual al momento se está validando que el proceso en sí establecido se encuentre correcto sino se realizarán cambios de mejora hasta tener el proceso más estable y adoptado por todas las áreas involucradas Gestión de Acceso La Gestión de Acceso al igual que la Gestión de Problemas es un proceso que se encontraba implícito en la gestión de requerimientos y que no era orientado de forma correcta, si bien se registraba los requerimientos de acceso a los servicios en producción no se seguía un proceso de aprobación y validación de autorizar el acceso, de igual forma no permitía disponer de un control de auditoría y seguimientos de las solicitudes de acceso registradas. De igual forma se realizó la implementación del proceso en Jira agregando una opción para registrar este tipo de requerimientos. El proceso en sí fue implementado en el mes de Enero de 2014 y actualmente se está validando en producción que el proceso definido esté correcto.101 87 Gráfico 18 Pantalla de ingreso de una solicitud de Acceso en Jira (imagen ampliada Anexo C) Funciones de la Operación de Servicio Tomando en consideración la última distribución organizacional en el área de Operaciones y Soporte para la formación de las funciones definidas por ITIL dentro de la Operación del Servicio se definieron las mismas de la siguiente manera: Mesa de Servicios: Definido como un centro de servicios centralizado el cual es el único punto de contacto tanto a nivel de clientes internos como de clientes externos el cual se encuentra localizado en Ecuador. Se conforma por un equipo de 5 Analistas del Centro de Servicios en turnos rotativos (h1 -h2-h3), un Supervisor del Centro de Servicios y de ser necesarios actúa como Analista en horario fijo h4, como Director del Centro de Servicios se designó al Gerente de Operaciones y Soporte. De igual forma tanto el DBA como el Sysadmin actúan como soporte nivel 2 dentro de la línea de escalamiento dependiendo del tipo de incidente o requerimiento solicitado y como tercera línea de soporte el equipo de Desarrollo, los cuales son parte de la Mesa de Servicio. Dentro de las Responsabilidades que tiene definido cada nivel de soporte se detalla a continuación: Nivel 1 Equipo de Servicios Soporte102 88 Primer responsable del ticket y seguimiento hasta el cierre del mismo. Responsable de la comunicación del estado del ticket de forma interna y externa Responsable de la gestión del SLA del ticket Responsable por el direccionamiento correcto del ticket si así lo amerita. Nivel 2 Equipo de Operaciones Segundo responsable del ticket durante el proceso de resolución, comunicación del estado del ticket escalado al nivel 1 o direccionar al nivel 3 si así lo amerita Nivel 3 Equipo de Desarrollo Tercer responsable del ticket, resolución del ticket y comunicación hacia el nivel inferior. De igual forma se especificó el flujo de comunicación dependiendo el tipo de prioridad del ticket Figura 9 Flujo de comunicación Prioridad Crítica (imagen ampliada Anexo C) Mostrar más
INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS DISEÑO Y MODELADO DE PROCESOS DENTRO DE LAS MEJORES PRÁCTICAS BASADO EN ITIL INFORME Más detalles DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA PROYECTO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO DE SISTEMAS E INFORMÁTICA. AUTORES: BASANTES Más detalles UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITÉCNICA SUPERIOR
UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITÉCNICA SUPERIOR INGENIERÍA TÉCNICA DE TELECOMUNICACIONES SISTEMAS DE TELECOMUNICACIÓN PROYECTO FIN DE CARRERA ITIL COMO BASE PARA EVALUAR LA CALIDAD DE SERVICIO Más detalles UNIVERSIDAD INTERNACIONAL SEK
UNIVERSIDAD INTERNACIONAL SEK FACULTAD DE SISTEMAS Y TELECOMUNICACIONES Trabajo de fin de carrera titulado: IMPLEMENTACIÓN DE UN SERVICE DESK PARA LA GESTIÓN DE LA INFRAESTRUCTURA TECNOLÓGICA PARA LA EMPRESA Más detalles ESCUELA POLITECNICA NACIONAL
ESCUELA POLITECNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS DISEÑO Y CONSTRUCCION DE UN SISTEMA DE GESTION DE INCIDENTES PARA UN SERVICE DESK FUNDAMENTADO EN ITIL PROYECTO PREVIO A LA OBTENCIÓN DEL Más detalles MEJORA DE LOS PROCESOS DE GESTIÓN DE INCIDENCIAS Y CAMBIOS APLICANDO ITIL EN LA FACULTAD DE ADMINISTRACIÓN - USMP
FACULTAD DE INGENIERÍA Y ARQUITECTURA ESCUELA PROFESIONAL DE COMPUTACIÓN Y SISTEMAS MEJORA DE LOS PROCESOS DE GESTIÓN DE INCIDENCIAS Y CAMBIOS APLICANDO ITIL EN LA FACULTAD DE ADMINISTRACIÓN - USMP PRESENTADA Más detalles PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR FACULTAD DE INGENIERÍA ESCUELA DE SISTEMAS
1 UNIVERSIDAD POLITÉCNICA SALESIANA FACULTAD DE INGENIERÍAS SEDE QUITO CAMPUS SUR CARRERA DE INGENIERÍA DE SISTEMAS MENCIÓN TELEMÁTICA ESTUDIO E IMPLEMENTACIÓN DE BUENAS PRÁCTICAS PARA LA GESTIÓN DE SERVICIOS Más detalles UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja ÁREA TÉCNICA
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja ÁREA TÉCNICA TITULACIÓN DE INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN. Implementación de una solución de Inteligencia de Negocios Más detalles UNIVERSIDAD POLITÉCNICA SALESIANA SEDE QUITO
UNIVERSIDAD POLITÉCNICA SALESIANA SEDE QUITO CARRERA: INGENIERÍA DE SISTEMAS Tesis previa a la obtención del título de: INGENIERO DE SISTEMAS TEMA: PROPUESTA DE MONITOREO DE LA INFRAESTRUCTURA TECNOLÓGICA Más detalles UNIVERSIDAD TECNOLÓGICA ISRAEL FACULTAD DE SISTEMAS INFORMÁTICOS
I UNIVERSIDAD TECNOLÓGICA ISRAEL FACULTAD DE SISTEMAS INFORMÁTICOS GESTIÓN DE INCIDENTES Y PROBLEMAS EN EL ÁREA DE SISTEMAS CON METODOLOGÍA ITIL, PARA MEJORAR LA UTILIZACIÓN DE LOS RECURSOS DE LA ORGANIZACIÓN Más detalles Universidad Latinoamericana de Ciencia y Tecnología. Facultad Ingeniería. Escuela de Ingeniería Informática
Universidad Latinoamericana de Ciencia y Tecnología Facultad Ingeniería Escuela de Ingeniería Informática Artículo Metodologías de ITIL Estudiante Helen Jara Phillips Tutor: Miguel Pérez Montero I cuatrimestre Más detalles UNIVERSIDAD TÉCNICA DE AMBATO FACULTAD DE INGENIERÍA EN SISTEMAS ELECTRÓNICA E INDUSTRIAL
UNIVERSIDAD TÉCNICA DE AMBATO FACULTAD DE INGENIERÍA EN SISTEMAS ELECTRÓNICA E INDUSTRIAL CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES E INFORMÁTICOS Tema: ESTUDIO DE OPERACIÓN DE LOS SERVICIOS DE Más detalles PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ
PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA IMPLANTACIÓN DE LOS PROCESOS DE GESTIÓN DE INCIDENTES Y GESTIÓN DE PROBLEMAS SEGÚN ITIL v3.0 EN EL ÁREA DE TECNOLOGÍAS DE INFORMACIÓN Más detalles UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE PRODUCCIÓN Y ORGANIZACIÓN EMPRESARIAL
UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE PRODUCCIÓN Y ORGANIZACIÓN EMPRESARIAL ANÁLISIS Y PROPUESTA DE MEJORA DEL PROCESO DE GESTIÓN DE INCIDENTES DEL Más detalles MODELAMIENTO DE PROCESOS DE ATENCIÓN DE SERVICIOS DE DATACENTER
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE INGENIERIA INDUSTRIAL MODELAMIENTO DE PROCESOS DE ATENCIÓN DE SERVICIOS DE DATACENTER ALEXIS OSVALDO ARELLANO QUEZADA Profesor Más detalles UNIVERSIDAD POLITÉCNICA SALESIANA
UNIVERSIDAD POLITÉCNICA SALESIANA FACULTAD INGENIERÍAS SEDE QUITO CAMPUS SUR CARRERA DE INGENIERÍA EN SISTEMAS MENCIÓN ROBÓTICA E INTELIGENCIA ARTIFICIAL TELEMÁTICA IMPLEMENTACIÓN DE UN MODELO DE GESTIÓN Más detalles La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador.
La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador. Los derechos de autor han sido entregados a la ESCUELA POLITÉCNICA NACIONAL bajo el libre consentimiento del Más detalles FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE INGENIERÍA INDUSTRIAL MEJORAMIENTO DEL SERVICIO DE SOPORTE DE ITMANAGEMENT A LOS SISTEMAS DE APOYO A LAS OPERACIONES Proyecto Más detalles 1. OBJETIVO 2 2. INTRODUCCION 3
ÍNDICE 1. OBJETIVO 2 2. INTRODUCCION 3 3. DESARROLLO 6 3.1 Objetivo 6 3.1.1 Alcance 6 3.1.2 Qué es ITIL? 6 3.2 ANTECEDENTES DE ITIL 7 3.2.1 OBJETIVOS DE ITIL 7 3.2.2 BENEFICIOS DE ITIL 7 3.2.3 ESTRUCTURA Más detalles DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA EN SISTEMAS E INFORMÁTICA TESIS PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO DE SISTEMAS TEMA: IMPLANTACIÓN DE UNA HERRAMIENTA PARA EL Más detalles UNIVERSIDAD DE ALCALÁ Escuela Técnica Superior de Ingeniería Informática GRADO EN SISTEMAS DE INFORMACIÓN
UNIVERSIDAD DE ALCALÁ Escuela Técnica Superior de Ingeniería Informática GRADO EN SISTEMAS DE INFORMACIÓN Trabajo Fin de Grado Puesta en marcha de un servicio de Help Desk basado en las mejores prácticas Más detalles UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA CARRERA DE INGENIERÍA INFORMÁTICA

References: Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución