Source: http://docplayer.es/501236-T-e-s-i-s-universidad-nacional-autonoma-de-mexico-para-obtener-el-titulo-de-ingeniero-en-computacion.html
Timestamp: 2016-10-22 20:22:24+00:00

Document:
⭐T E S I S UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO PARA OBTENER EL TÍTULO DE: INGENIERO EN COMPUTACIÓN
Download "T E S I S UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO PARA OBTENER EL TÍTULO DE: INGENIERO EN COMPUTACIÓN"
Emilio Barbero Ayala
1 UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO FACULTAD DE INGENIERÍA T E S I S I M P L E M E N T A C I Ó N D E U N S I S T E M A S E R V I C E D E S K B A S A D O E N I T I L. PARA OBTENER EL TÍTULO DE: INGENIERO EN COMPUTACIÓN P R E S E N T A N: DE LA CRUZ RAMÍREZ ANAYELI. ROSAS MIGUEL ROBERTO. DIRECTOR DE TESIS EDUARDO ESPINOSA AVILA. CD. UNIVERSITARIA 2012.2 Una meta alcanzada, que fue lograda no solo por una persona si no por muchas, personas que en mi vida son muy importantes, mis padres y en general toda mi familia. A mis padres. Les agradezco todo el apoyo brindado, todo el tiempo dedicado y el esmero con el que siempre me han cuidado y brindado las cosas; Los quiero mucho, espero haber podido brindarles un poco de satisfacción con este trabajo concluido. Abuelita Amalia. Eres una personita muy importante para mí, que me ha brindado los mejores consejos, te quiero mucho, gracias por darme tu apoyo incondicional. Abuelita Emma. Me hubiera gustado que estuviera aquí, para que compartiéramos mi alegría por el término de este trabajo, gracias por enseñarme que lo más importante es el cariño hacia los demás y en particular a la familia ( ). A mi hermana. Hermanita gracias por alegrarme la vida y brindarme tu cariño, te quiero mucho, espero siempre estar juntas y recuerda que siempre puedes contar conmigo. Roberto. Después de todo terminamos gracias por tu apoyo y por la paciencia que tuviste conmigo. No olvidaré el tiempo invertido en este trabajo. Atte. Anayeli de la Cruz Ramírez.3 Una meta alcanzada, un sueño hecho realidad, un éxito logrado no sólo por cuenta propia sino también porque conté con todos ustedes en el camino: Dios, mis padres y familia, contigo Anayeli, mis amigos, profesores, nuestro asesor y sinodales, a ti que lees estas líneas y por supuesto a todas las personas que de manera directa o indirecta contribuyeron a mi formación no sólo personal sino también profesional. Lo hemos logrado! Por siempre agradecido. Atte. Roberto Rosas Miguel.4 Índice de Contenido. INTRODUCCIÓN CAPÍTULO 1: ANTECEDENTES ANTECEDENTES DEFINICIÓN DEL PROBLEMA OBJETIVOS ALCANCE PROPUESTAS DE SOLUCIÓN RESULTADOS ESPERADOS CAPÍTULO 2: MARCO DE REFERENCIA IMPORTANCIA DE LAS TECNOLOGÍAS DE INFORMACIÓN (TI) SERVICIOS TI GESTIÓN DE SERVICIOS TI VALOR DE UN SERVICIO TI INTRODUCCIÓN A ITIL OBJETIVOS DE ITIL MÓDULOS DE ITIL BENEFICIOS DE ITIL CICLO DE VIDA DEL SOFTWARE QUÉ ES UN PROCESO DE DESARROLLO DE SOFTWARE? RUP DE RATIONAL PARA DESARROLLO DE SOFTWARE CICLO DE RUP: FLUJOS DE TRABAJO Y FASES BASES DE DATOS SQL (Structured Query Language) MySQL LA AQUITECTURA CLIENTE SERVIDOR SITIOS DINÁMICOS IMPLEMENTACIÓN DE UN SITIO DINÁMICO C A P Í T U L O 3: MESA DE SERVICIOS, ADMINISTRACIÓN DE INCIDENTES, NIVELES DE SERVICIO CICLO DE SOPORTE TIPOS DE PRIMER CONTACTO MESA DE SERVICIOS MISIÓN DE LA MESA DE SERVICIOS III5 3.2.2 VISIÓN DE LA MESA DE SERVICIOS OBJETIVOS DE UNA MESA DE SERVICIOS ACTIVIDADES DE UNA MESA DE SERVICIOS BENEFICIOS DE UNA MESA DE SERVICIOS ESTRUCTURA DE LA MESA DE SERVICIOS IMPLEMENTACIÓN DE UNA MESA DE SERVICIOS EQUIPO Y FORMACIÓN DE UNA MESA DE SERVICIOS MÓDULOS DE SOPORTE AL SERVICIO INCIDENTES ESTADOS DE UN INCIDENTE REQUERIMIENTOS ESTADOS DE UN REQUERIMIENTO ADMINISTRACIÓN DE INCIDENTES Y REQUERIMIENTOS OBJETIVOS DE LA ADMINISTRACIÓN DE INCIDENTES POR QUÉ UNA ADMINISTRACIÓN DE INCIDENTES? DIFERENCIAS Y SIMILITUDES ENTRE LA ADMINISTRACIÓN DE INCIDENTES Y LA ADMINISTRACIÓN DE PROBLEMAS CICLO DE VIDA DE UN INCIDENTE ACTIVIDADES REALIZADAS DENTRO DEL CICLO DE VIDA DE UN INCIDENTE ESCALAMIENTO DE INCIDENTES Y TIPOS PROCESO DE ESCALAMIENTO DE INCIDENTES A TRAVÉS DE LOS NIVELES DE SOPORTE CONTROL DEL PROCESO DE ADMINISTRACIÓN DE INCIDENTES Y REQUERIMIENTOS INFRAESTRUCTURA NECESARIA PARA LA IMPLEMENTACIÓN DE LA ADMINISTRACIÓN DE INCIDENTES MÉTRICAS QUE DEBEN OBSERVARSE EN LA ADMINISTRACIÓN DE INCIDENTES ADMINISTRACIÓN DEL NIVEL DE SERVICIO OBJETIVOS DE LA ADMINISTRACIÓN DEL NIVEL DE SERVICIO ACTIVIDADES DE LA ADMINISTRACIÓN DEL NIVEL DE SERVICIO ACUERDO DE NIVELES DE SERVICIO (SLA) OBJETIVO DE LOS SLA S CATÁLOGO DE SERVICIOS ESTRUCTURA DE UN SLA IV6 3.8.4 CONTENIDOS DE UN SLA ACUERDOS DE NIVEL DE OPERACIÓN (OLA) IMPLEMENTACIÓN DE UN OLA CAPÍTULO 4: ANÁLISIS Y DISEÑO DE REPORTS SYSTEM REPORTS SYSTEM: UN SISTEMA SERVICE DESK ANÁLISIS PARA LA IMPLEMENTACIÓN DE REPORTS SYSTEM LISTA DE REQUERIMIENTOS DIAGRAMAS UML DIAGRAMAS DE CASO DE USO DIAGRAMA DE ACTIVIDADES DISEÑO DE LA BASE DE DATOS ANÁLISIS, DIAGRAMA ENTIDAD RELACIÓN Y DICCIONARIO DE DATOS CAPÍTULO 5: IMPLEMENTACIÓN Y PRUEBAS DE REPORTS SYSTEM IMPLEMENTACIÓN DE REPORTS SYSTEM INTERFAZ DE INGRESO A REPORTS SYSTEM INTERFAZ DE MÓDULOS INTERFAZ DE MÓDULO DE HERRAMIENTAS INTERFAZ DE MÓDULO ESTADÍSTICAS INTERFAZ DE MÓDULO REPORTES PRUEBAS DE REPORTS SYSTEM PRUEBAS FUNCIONALES PRUEBAS DE INTEGRACIÓN CAPÍTULO 6: SEGURIDAD SEGURIDAD EN LOS SISTEMAS INFORMÁTICOS SEGURIDAD EN LOS DATOS SEGURIDAD EN LAS BASES DE DATOS FACTORES EN LA SEGURIDAD DE BASES DE DATOS FASES EN LA SEGURIDAD DE LAS BASES DE DATOS SEGURIDAD EN EL SERVIDOR WEB PREVENCIÓN DE ATAQUES DETECCIÓN DE ATAQUES RECUPERACIÓN DE ATAQUES SEGURIDAD EN REPORTS SYSTEM V7 6.4.1 CONTROLES LÓGICOS EN REPORTS SYSTEM SEGURIDAD EN LA BASE DE DATOS CONCLUSIONES CONCLUSIONES ANEXOS ANEXO I ANEXO II GLOSARIO REFERENCIAS CONSULTADAS VI8 INTRODUCCIÓN. Hoy en día las empresas buscan soluciones de información que les permitan competir en el mercado global por lo tanto el uso de las Tecnologías de Información TI tiene la finalidad de encontrar métodos eficientes para formar parte de la estrategia competitiva de la compañía y de esta manera incrementar la eficiencia productiva, la calidad en los productos y servicios del negocio así como la disminución en los tiempos de respuestas ante las necesidades del cliente. Sin duda las TI, son una excelente herramienta de gestión empresarial, que ayudan positivamente para el desarrollo y viabilidad de las organizaciones, se dice que las empresas que no se adapten a las nuevas tecnologías simplemente dejarán de existir, puesto que éstas no tendrán las herramientas necesarias para poder competir. Sin embargo se debe considerar que las TI requieren tener una administración adecuada que se componga de métricas definidas y así poder medir el verdadero desempeño y valor que están aportando a los fines del negocio. Existen diferentes estándares para implementar la gestión de las TI y la elección de uno de ellos depende de las necesidades de cada organización. Considerando la información anterior, el presente trabajo de tesis hace referencia a la problemática que existe en las organizaciones para el desarrollo de procesos ordenados y la administración de las TI, se propone como solución el desarrollo de un sistema de gestión basado en uno de los estándares más utilizados en la actualidad. VII9 CAPÍTULO 1: ANTECEDENTES.10 Capítulo 1: Antecedentes. 1.1 ANTECEDENTES El constante manejo de grandes volúmenes de información dentro de la vida cotidiana ha dado como resultado una constante evolución en las TI, esto hace que exista una estrecha relación entre ambas (información tecnología). En la actualidad, la información ocupa un lugar importante dentro de las organizaciones y las TI son el medio para realizar actividades de transmisión, resguardo, seguridad y automatización de procesos de ésta de una forma simple, eficaz y menos costosa; por lo anterior el concepto de TI involucra a todas aquellas metodologías, técnicas y dispositivos que son usados para la manipulación de la información, facilitando su acceso y uso para lograr el objetivo del negocio. El uso de las TI engloba innovación, aprendizaje y aceptación de herramientas diferentes, las cuales permiten realizar las tareas laborales de cada persona de una forma más sencilla y rápida por lo tanto las empresas se ven en la necesidad de implantar TI acorde a sus necesidades, sin embargo, es necesario contemplar que el personal que forma parte de la organización, requiere asesoría y atención técnica para el uso de los nuevos servicios TI disponibles. Todos los departamentos de TI atienden fallas en hardware o software y otras peticiones de servicio como altas, bajas y cambios de empleados. Si esta labor de apoyo no se sistematiza se depende mucho de la capacidad de cada técnico para dar solución de forma rápida y de calidad a los problemas que reportan los usuarios, además no se reutiliza todo el conocimiento empleado en resolver incidencias 1 pasadas. En la década de 1980, fue desarrollada la Biblioteca de Infraestructura de Tecnologías de la Información (Information Technology Infrastructure Library, ITIL 2 ), que se ha convertido en el estándar mundial de facto en la gestión de servicios informáticos; fue implementada debido a que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos, esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que correspondan con los objetivos del negocio. A través del tiempo se han desarrollado sistemas basados en ITIL para llevar a cabo la administración de fallas o solicitudes 3 de los usuarios. El uso de una herramienta de gestión de incidencias tiene tres objetivos básicos: 1 Dentro del campo de la Informática una incidencia es una falla de software o hardware, término que se abordará en el capítulo tres. 2 Las TI e ITIL, son temas tratados con detenimiento en el capítulo 2. 3 También conocidos como requerimientos, peticiones de servicio o solicitudes de cambio. Un requerimiento es una descripción genérica para varios tipos de demanda formuladas por los usuarios de los servicios al grupo de TI. Un requerimiento no interrumpe la operación normal de un servicio11 Capítulo 1: Antecedentes. Minimizar los tiempos de paro, es decir, contribuye a que la atención para la solución de la falla sea en el menor tiempo posible evitando que el usuario pierda tiempo en sus labores cotidianas. Registrar la información relevante de todas las incidencias y solicitudes realizadas. Administrar de forma adecuada las fallas o solicitudes de cada usuario. Es importante mencionar que en el mercado estas herramientas son conocidas como sistemas Service Desk, algunos de ellos son: Altiris: es una aplicación desarrollada por Symantec, ofrece una reducción en los costos y en la complejidad de seguimiento, soporte y mantenimiento de los activos 4 de una empresa. Ofreciendo a sus clientes un enfoque único de gestión del ciclo de vida de las TI. Service Desk: el producto Service Desk de CA 5 es parte de la suite Unicenter, permite construir un centro de atención a problemas internos de una empresa con respecto a las TI utilizadas. El tener implementado un sistema que automatice la administración de incidentes y solicitudes de ámbito informático, permite que la empresa logre sus metas en tiempo y forma determinados, sin embargo el uso de este tipo de herramientas está sujeto a los diferentes estándares que existen (por ejemplo las prácticas ITIL), lo cual implica que debe desarrollarse con los conocimientos necesarios del estándar empleado, de no ser así no se alcanzarán los objetivos primordiales: gestión de incidentes y solicitudes, provocando que el personal de la empresa se vea afectado en sus actividades laborales. 1.2 DEFINICIÓN DEL PROBLEMA. A través del tiempo los especialistas de TI han comprobado que la ausencia o carencia de procedimientos ordenados que brinden una línea de servicios de soporte técnico (baseline) de las TI que se encuentran en la organización impacta en su rendimiento, lo que conlleva a: Costos mayores. Tiempos de paro continuos. Pérdidas de información. Mal uso de las TI que se encuentran en la organización. 4 Un activo es cualquier componente en hardware o software que forma parte de la infraestructura de la empresa, durante las diferentes etapas de la vida del negocio. 5 CA es la empresa propietaria del sistema Service Desk12 Capítulo 1: Antecedentes. Insatisfacción de los usuarios. Lo anterior es consecuencia de la falta de un único punto de contacto que canalice a través de un sistema Service Desk las fallas y solicitudes que tienen los usuarios. El no contar con ambos aspectos genera una imagen deteriorada del área de informática de la organización, con solicitudes informales ingresando por todas los vías posibles (teléfonos, pasillos, departamento de sistemas, correos electrónicos) sin ningún tipo de formato, orden, prioridad, lo que no sólo complica al usuario sino que tampoco garantiza el seguimiento, atención y solución oportuna de dichas solicitudes. [1] 1.3 OBJETIVOS. Desarrollar un sistema que sea empleado para la gestión de reportes generados a partir de incidentes y requerimientos del personal de medianas y/o grandes empresas que puede ser utilizado por un punto de contacto conocido como Mesa de Servicios y cuya implementación esté basada en las prácticas de ITIL lo que permitirá establecer una línea de soporte fundamentada. 1.4 ALCANCE. Implementar una aplicación que tendrá las siguientes características: Sencilla y fácil de utilizar para los usuarios de la misma. Funcionalidad enfocada al registro y seguimiento de todas las solicitudes y fallas de ámbito informático. Brinde apoyo a las funciones de baseline de la empresa para lograr un mayor aprovechamiento de las TI. 1.5 PROPUESTAS DE SOLUCIÓN. Considerando la problemática identificada, la constante evolución de las TI y la implantación de éstas en las organizaciones, surge la necesidad de establecer una línea de soporte técnico basada en alguna metodología que permita su optimización. Además de ésta, es necesario el uso de un sistema de información Service Desk que gestione y controle tanto las fallas como los requerimientos de los usuarios debido a que tales sistemas están siendo adoptados por muchas empresas por las ventajas competitivas que ofrecen y el apoyo que brindan a la optimización de los procesos en los cuales intervienen; las principales ventajas que ofrecen son: Integridad de la información. Almacenamiento ordenado de información13 Capítulo 1: Antecedentes. Centralización de la información. Claridad en los procesos. Confidencialidad de la información y seguridad. Facilidad en la generación de reportes. Disponibilidad de datos estadísticos. Seguimiento de indicadores de gestión de calidad. La implantación de una baseline, un sistema Service Desk así como la administración de ambos puede lograrse a través de dos vías: Contratación de un proveedor externo (outsourcing). Dentro de la propia empresa estableciendo un área especializada. La elección de alguna de ellas depende de diversos factores como el tipo y tamaño de la organización, los costos e inversiones a realizar, las necesidades del negocio, el tipo de TI a utilizar, entre otros. En base a lo anterior se propone desarrollar un sistema denominado Reports System cuyo enfoque esté orientado a la administración de incidentes y solicitudes, que esté basado en las prácticas de ITIL y que cuente con las siguientes características: Base de datos de conocimiento 6 cuya finalidad será almacenar soluciones a fallas reportadas. Categorización de reportes que definan si las fallas son de hardware, software u otro. Obtención de estadísticas que permitan conocer el número de fallas y solicitudes registradas. Criterio de prioridad, urgencia e impacto de los incidentes o solicitudes. 1.6 RESULTADOS ESPERADOS. El desarrollo e implementación del sistema Reports System permitirá efectuar la administración de incidentes y solicitudes realizadas en una organización como parte de la integración de una buena línea de servicios de soporte técnico. 6 En la metodología ITIL es conocida como Knowledge Data Base o KDB y constituye un repositorio de soluciones a fallas usuales reportadas por los usuarios14 CAPÍTULO 2: MARCO DE REFERENCIA.15 Capítulo 2: Marco de Referencia. 2.1 IMPORTANCIA DE LAS TECNOLOGÍAS DE INFORMACIÓN (TI). El contar con la definición de las TI no es suficiente, también es fundamental conocer el enorme papel que juegan dentro de las empresas a nivel mundial ya que son la parte medular de las organizaciones en la actualidad, sin embargo deben evolucionar continuamente para que puedan brindar una respuesta eficaz y eficiente a las necesidades de cada negocio siendo la eficacia y la eficiencia los atributos principales que brindan las TI. Realizar una buena inversión en TI es importante ya que éstas pueden dar pauta a la apertura de nuevos proyectos y sobre todo se debe considerar que brindan la oportunidad de ser competitivo. Una buena elección e implantación de TI, debe dar como resultado una mayor rentabilidad, exactitud y rapidez en la toma de decisiones de cualquier empresa así como la disminución de gastos a nivel organizacional; finalmente deben contribuir al aumento de productividad del capital humano SERVICIOS TI. 7 La finalidad de las TI, es conformar una serie de herramientas o características funcionales conocidas como servicios TI: un servicio TI, es una actividad o conjunto de actividades que ayudan a proveer valor a los clientes facilitándoles los resultados que quieren obtener evitando asumir costos y riesgos específicos. Sus principales objetivos son: Obtener los resultados deseados en un negocio. Aumentar el rendimiento de las tareas asociadas a las TI reduciendo el efecto de las limitantes como calidad, seguridad o disponibilidad GESTIÓN DE SERVICIOS TI. La dependencia del uso de las TI dentro de las organizaciones es cada vez mayor, lo anterior tiene como consecuencia que los servicios TI que son utilizados tengan las siguientes características: Confiables. Disponibles. Eficaces. Seguros. 7 Los apartados están basados en material didáctico para la gestión de TI, realizado y publicado Service Desk Institute (SDI). [2]16 ESTRATEGIA Capítulo 2: Marco de Referencia. No obstante es necesaria la implementación de una gestión de servicios de TI, para obtener mejores resultados y el mayor provecho de todos los servicios TI alojados en la organización. La gestión de servicios TI es un conjunto de habilidades organizacionales especializadas para otorgarle valor al cliente en forma de servicios; básicamente son procesos y funciones que dirigen los servicios a través de un ciclo de vida, especializándose en estrategia, diseño, transición, operación y mejoramiento continuo. En la figura 2.1 se muestra como a partir de una estrategia de gestión de servicios TI, se pueden obtener diversos niveles de resultados (graduales) que impactan en el éxito del negocio. GESTIÓN SERVICIO Fig. 2.1 Gestión de servicios TI VALOR DE UN SERVICIO TI. El valor de un servicio TI está conformado por dos atributos: Utilidad: es la adecuación del servicio TI en base al propósito del negocio; Este atributo se obtiene en base a los resultados obtenidos. La utilidad aumenta el rendimiento de un negocio. Garantía: es la adecuación al uso del servicio TI, es decir un servicio TI siempre debe estar disponible cuando sea necesario, debe ser continuo y debe ser seguro. Y se define como:17 Capítulo 2: Marco de Referencia. 2.2 INTRODUCCIÓN A ITIL. ITIL es un conjunto de prácticas que ayudan a mejorar los procesos de la administración de las TI. Esta librería fue creada debido a que las organizaciones dependían cada vez más de la tecnología informática para lograr sus objetivos, sin embargo en algunas ocasiones estas tecnologías solían ser rebasadas por la constante demanda de respuesta óptima ya que no contaban con una buena administración en los procesos que las constituían. Actualmente ITIL es utilizado en la implementación de procesos de gestión de servicios de TI y se puede adaptar a cualquier área de informática, no se limita al tamaño de la organización, es decir puede ajustarse a organizaciones pequeñas y grandes independientemente de la tecnología que emplean o bien a aquellas que tienen un proveedor de TI OBJETIVOS DE ITIL. Los principales objetivos de ITIL en cada uno de los servicios TI implementados en la organización son: Calidad Confiabilidad Disponibilidad Eficacia Eficiencia Seguridad Utilidad MÓDULOS DE ITIL. El marco de ITIL está conformado por los siguientes módulos: Planeación, implementa la administración de servicios y contempla las tareas asociadas a planificación, implementación y mejora de la administración de servicios. Perspectiva del negocio, implica asesorar al personal de TI para comprender cómo pueden contribuir a los objetivos del negocio18 Capítulo 2: Marco de Referencia. Administración de servicios, es la parte medular de ITIL puesto que conjunta las necesidades tecnológicas y del negocio de una organización. Se basa en el módulo de planeación para implementar la gestión de servicios y se compone de dos áreas: Soporte al servicio que cubre los aspectos que garantizan la continuidad, disponibilidad y calidad del servicio prestado al usuario. Entrega del servicio enfocado a cumplir los niveles de servicio requeridos además de su disponibilidad, continuidad, costos, demanda de infraestructura de TI así como de los niveles de seguridad que se requieren. Administración de la Infraestructura de TI que cubre aspectos que van desde la identificación de requerimientos de negocios hasta la instalación, entrega, operación y optimización de componentes y servicios. Administración de la seguridad mediante la planificación y gestión de los niveles de seguridad definidos para la información y servicios TI, logrando un control de los incidentes de seguridad, gestión de riesgos y vulnerabilidades. Administración de las aplicaciones lo que constituye la gestión de las aplicaciones desde el inicio de las necesidades del negocio pasando por todo el ciclo de vida hasta la eliminación de las mismas. En la figura 2.2 se muestran los módulos que integran a ITIL, los cuales han sido explicados en los párrafos precedentes. Planeación para implementar la administración de servicios E L N E G O C I O La perspectiva del negocio Administración de servicios. Entrega del servicio Soporte al servicio Administración de la seguridad Administración de la infraestructura IT L A T E C N O L O G Í A Administración de las aplicaciones Fig. 2.2 Módulos de ITIL. [3]19 Capítulo 2: Marco de Referencia BENEFICIOS DE ITIL. Se ha mencionado que ITIL provee los fundamentos de calidad de la gestión de los servicios de TI. Las TI, de manera activa, brindan apoyo a los objetivos corporativos tanto al ofrecer servicios que se basan en principios eficientes como al satisfacer los requerimientos del negocio. La infraestructura de TI puede convertirse en un generador de ganancias en lugar de ser vista como una carga inevitable de costos. [4] La introducción de ITIL en la industria como un conjunto consistente de procesos no solamente resalta las debilidades potenciales en el manejo de operaciones de TI sino que estimula de manera proactiva, mejoras en las mismas. ITIL revoluciona los servicios de TI de varias maneras: [5] Reduce los tiempos de resolución de problemáticas en la provisión de servicios de TI. Mejora el control de la gestión de TI. Provee servicios de TI confiables. Proporciona la implementación de soluciones permanentes a problemas formalmente reconocidos. Reducción de costos. Un costo total de TI se logra a través de un incremento en la eficiencia y en la productividad, un menor número de incidentes, una resolución más rápida de los mismos y una baja en la cantidad de fallas de servicio. Mejor accesibilidad a los servicios por parte de los usuarios a través de un solo punto de contacto. Mayor rapidez de respuesta a los incidentes y peticiones hechas por usuarios. Un mejorado equipo de trabajo que cuenta con un nivel mayor de comunicación. Una percepción más favorable de los servicios provistos. Una calidad mejorada de la información relacionada a las TI que favorece las tomas de decisiones y una administración óptima. Una reducción en el impacto de las actividades de negocio de la empresa. Una mejor administración y control sobre la infraestructura de los sistemas de TI. Una infraestructura de TI fortalecida20 Capítulo 2: Marco de Referencia. Erradica la pérdida y registros inconsistentes de información, incidentes y solicitudes de clientes. 2.3 CICLO DE VIDA DEL SOFTWARE. El ciclo de vida del software define todas las fases para la implementación adecuada de un sistema, permitiendo: Identificación de errores. Verificación de los procedimientos de desarrollo. Asegura la calidad del software. Las fases que integran al ciclo de vida del software son las siguientes: Ingeniería de Sistemas: se detecta un problema o necesidad que para su solución es necesario realizar un desarrollo de software. Análisis: se entiende y comprende de forma detallada la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema de tal manera que se obtenga la información necesaria y suficiente para solucionarla. Diseño: se determina la estrategia que se va a utilizar para resolver el problema. Implementación: partiendo del análisis y diseño de la solución, se procede a desarrollar el correspondiente sistema a través del uso de herramientas informáticas así como de lenguajes de programación que sean los que más se ajusten a la solución planteada. Pruebas: el desarrollo del sistema se efectúa de manera modular por lo que es necesario realizar pruebas individuales a cada uno de estos componentes para finalmente garantizar que se implementen de acuerdo a las especificaciones establecidas. Documentación: parte fundamental del desarrollo que consiste en la realización de diagramas, guías y comentarios sobre la funcionalidad de cada uno de los módulos que integran al sistema lo que ayuda a comprender su uso y facilitar futuras modificaciones en la etapa de mantenimiento. La documentación se conforma por comentarios en el código fuente y documentos que describan al problema con datos del autor, el algoritmo empleado (diagrama de flujo o pseudocódigo), diccionario de datos y manual de usuario. Mantenimiento: se permite realizar actualizaciones o correcciones del sistema debidas a las necesidades o requerimientos planteados durante toda su vida útil21 Capítulo 2: Marco de Referencia QUÉ ES UN PROCESO DE DESARROLLO DE SOFTWARE? 8 De manera general un proceso define quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo. En la Ingeniería de software el objetivo es construir un producto software o mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficiente de software de calidad. Captura y presenta las mejores prácticas que el estado actual de la tecnología permite. En consecuencia reduce el riesgo y hace el proyecto más predecible. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software, ver figura 2.3. Requisitos del usuario Proceso de desarrollo de Software Fig. 2.3 Un proceso de desarrollo de software Sistema software 2.4 RUP DE RATIONAL PARA DESARROLLO DE SOFTWARE. Rational Unified Process o simplemente RUP es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyecto. Está basado en componentes lo que quiere decir que el sistema software en construcción está formado por módulos software interconectados a través de interfaces definidas. El RUP utiliza el lenguaje unificado de modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial de RUP. Los verdaderos aspectos definitorios de RUP se resumen en tres características claves: Está dirigido por casos de uso. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. En conjunto representan los requisitos funcionales constituyendo así el modelo de casos de uso el cual describe la funcionalidad total del sistema, además guían su diseño, implementación y prueba, esto es, guían el proceso de desarrollo y seguimiento continúo 8 Los apartados y 2.4 han sido tomados del libro El Proceso Unificado de Desarrollo de Software. [6]22 Capítulo 2: Marco de Referencia. Dirigido por caso de uso indica que el proceso de desarrollo sigue una secuencia ya que avanza a través de una serie de flujos de trabajo que parten de los casos de uso, de esta forma no se desarrollan aisladamente si no de forma paralela a la arquitectura del sistema. Está centrado en la arquitectura. La arquitectura del sistema, como los casos de uso, madura según el ciclo de desarrollo y es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. Incluye los aspectos estáticos y dinámicos más significativos del sistema, surge de las necesidades de la empresa, como las perciben los usuarios y los inversores y se refleja en los casos de uso. Se ve influida por factores como: Plataforma en que tiene que funcionar el software: abarca hardware, sistema operativo, sistema de gestión de base de datos, protocolos para comunicación en red, etc. Bloques de construcción reutilizables, consideraciones de implantación, sistemas heredados y requisitos no funcionales. El valor de una arquitectura depende de las personas que se hayan responsabilizado de su creación, este proceso ayuda al arquitecto de software a centrarse en los objetivos adecuados como: Comprensión. Adaptación al cambio. Reutilización. La relación entre los casos de uso y la arquitectura está dada por el hecho de que cada sistema tiene tanto una función como una forma. En esta situación, la función corresponde a los casos de uso y la arquitectura a la forma. Dentro del diseño de la arquitectura se debe contemplar que ésta permita que el sistema evolucione, no sólo en su desarrollo sino también en su mantenimiento para que sea susceptible de posibles modificaciones o mejoras posteriores. Es iterativo e incremental. Debido a que el desarrollo de software puede llevar mucho tiempo en ser implementado, resulta práctico y aconsejable dividirlo en pequeñas partes o mini proyectos llamadas iteraciones, las cuáles finalizan en un incremento del software desarrollado. Las iteraciones hacen referencia a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto23 Capítulo 2: Marco de Referencia. Para que el desarrollo de software sea efectivo, debe haber un control sobre las iteraciones, lo cual se logra con la selección y ejecución de cada una de ellas de forma planeada. En cada iteración, los desarrolladores se enfocan a la identificación y especificación de los casos de uso relevantes empleando la arquitectura como guía, crean el diseño, lo implementan en componentes y verifican que éstos satisfagan los casos de uso. Las iteraciones sucesivas construyen los artefactos 9 del desarrollo a partir del estado en el que fueron dejados en la iteración anterior. Si una iteración cumple sus metas, el desarrollo continúa con la siguiente iteración, cuando no lo hace, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque. Las ventajas de tener iteraciones controladas son: Reducción de costos, tiempo, esfuerzo y riesgos. Permite trabajar de manera más eficiente, para así poder obtener resultados claros a corto plazo. Esto es lo que hace único a RUP ya que la arquitectura provee la estructura sobre la cual guiar las iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada iteración. La eliminación de una de ellas afectaría drásticamente el valor de RUP CICLO DE RUP: FLUJOS DE TRABAJO Y FASES. RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versión del producto para los clientes y se desarrolla a lo largo del tiempo, dividido en cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a su vez en iteraciones y finaliza con hito 10, el cual permite controlar el progreso del trabajo. Es sabido que cada fase requiere un tiempo y un esfuerzo consumido, lo cual es útil ya que permite estimar no solo el tiempo si no los recursos humanos. En la figura 2.4 se muestran las dimensiones que integran a RUP: El eje horizontal que representa las cuatro fases que lo constituyen, divididas en iteraciones a lo largo del tiempo. El eje vertical que representa los flujos de trabajo fundamentales: requisitos, análisis, diseño, implementación y pruebas. 9 Dentro de este contexto, un artefacto es un resultado tangible del proceso del desarrollo de software, por ejemplo: documentos de requisitos, especificaciones, modelos UML que ayudan a la descripción de la funcionalidad, arquitectura o diseño del software, código fuente compilado para las fases de prueba y otros. 10 Acontecimiento muy importante y significativo en el proceso de desarrollo de software24 Capítulo 2: Marco de Referencia. Fig. 2.4 Los cinco flujos de trabajo en RUP tienen lugar sobre las cuatro fases: Inicio, Elaboración, Construcción y Transición (en la figura se observa una iteración en la fase de elaboración). Fases. Inicio: comprende una descripción del producto final y sé presenta el análisis de negocio para él. Contempla las principales funciones del sistema para sus usuarios más importantes, bosqueja la posible arquitectura del sistema, define el plan y costo del proyecto. Elaboración: se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del proyecto, durante esta fase se realizan los casos de uso más críticos que se identificaron en la fase de Inicio. El resultado de esta fase es una línea base de la arquitectura. Una vez concluida, ya es posible planificar las actividades y estimar recursos necesarios para terminar el proyecto. Durante la elaboración, se cuestiona si son estables los casos de uso, la arquitectura, el plan y si hay un suficiente control de riesgo para que el desarrollo se formalice en un contrato. Construcción: se crea el producto; la línea base de la arquitectura crece hasta convertirse en el sistema completo y así poderse entregar a los usuarios, cabe mencionar que la mayor parte de los recursos es empleada durante la fase de desarrollo. Al final de esta fase se cuenta con todos los casos de uso que se hayan acordado para el desarrollo de esta versión; es importante mencionar que la versión obtenida en esta fase no está completamente libre de defectos, muchos de ellos serán descubiertos y solucionados en la fase de transición. Es decisivo cuestionarse si es posible hacer una primera entrega o no. Transición: abarca el periodo durante el cual el producto se convierte en versión beta. En esta versión se prueba el producto y se informa de defectos y deficiencias. Se corrigen los problemas e incorporan algunas de las mejoras sugeridas en una versión general dirigida a la totalidad de la comunidad de25 Capítulo 2: Marco de Referencia. usuarios. Esta fase conlleva a actividades como la fabricación, formación del cliente, proporcionar una línea de ayuda, asistencia y la corrección de defectos que se encuentren tras la entrega (estos defectos se dividen en dos categorías: los que tienen suficiente impacto para justificar una versión incrementada versión delta y los que pueden corregirse en la siguiente versión normal). 2.5 BASES DE DATOS. 11 Una base de datos es una colección de datos estructurados y relacionados entre sí, los cuales son almacenados y explotados por los sistemas de información de una empresa o negocio en particular. Existen varios tipos de bases de datos en función del modo en que almacenan y acceden a la información: relacional, jerárquica, en red, orientada a objetos, etc. En este proyecto de tesis la base de datos a crear y manejar es de tipo relacional debido a que la información será almacenada en tablas lógicamente relacionadas entre sí utilizando campos clave comunes. Los sistemas de gestión de base de datos (DBMS) 12 son programas de software que permiten a los usuarios crear y mantener bases de datos. También permiten escribir consultas a una base de datos individual para efectuar acciones requeridas como: modificación, recuperación, borrado e inserción de datos. En el mercado existen diversos DBMS s: Access, SQL Server, Oracle, DB2, Sybase, Postgres SQL, MySQL entre otros. Entre las principales características de los DBMS s se tienen las siguientes: Independencia lógica y física de los datos. Redundancia mínima, lo que evita copias duplicadas de información. Acceso concurrente por parte de múltiples usuarios previniendo anomalías de acceso al querer actualizar la información de forma simultánea. Integridad de datos, permitiendo almacenar datos de forma consistente. Consultas complejas optimizadas. Seguridad de datos lo que brinda una protección a la información contra acceso no autorizado. Procesamiento de transacciones, es decir una secuencia de operaciones representadas como una solo unidad lógica de trabajo. 11 Algunas citas de los apartados 2.5, y todas las del apartado 2.6 han sido extraídas de la misma referencia. [7] 12 DBMS: acrónimo de Data Base Management System26 Capítulo 2: Marco de Referencia. Respaldo y recuperación que garantiza que los datos puedan ser reorganizados en un estado consistente en caso de que una transacción falle o la misma base de datos se corrompa. Acceso a través de lenguajes de programación estándar SQL (Structured Query Language). Es el lenguaje estándar para interactuar con bases de datos relacionales y es soportado prácticamente por todos los sistemas de gestión de bases de datos actuales. Está diseñado exclusivamente para controlar y administrar bases de datos de una forma efectiva. SQL ayuda a la recuperación, inserción, actualización y borrado de información de la base de datos; cada DBMS ofrece su propia implementación de SQL, que se ajusta hasta cierto nivel con el estándar pero típicamente lo extiende MySQL. 13 De entre todos los gestores anteriormente mencionados, MySQL es el DBMS que mejor se adapta al desarrollo del sistema en este proyecto. Las razones de esta elección son: Soporta el lenguaje SQL. Gratuito tanto para usos privados como comerciales. Permite la conexión de varios usuarios. Su motor de datos es rápido tanto grabando, localizando y recuperando datos. Ofrece una gran seguridad sobre la integridad de los datos almacenados. Puede ser utilizado en diferentes sistemas operativos como: UNIX, Windows, OS/2, Sun Solaris, entre otros. 2.6 LA AQUITECTURA CLIENTE SERVIDOR. Tradicionalmente los sistemas corporativos se han diseñado utilizando el modelo cliente servidor, entendiendo por cliente una aplicación que inicia el diálogo con otra denominada servidor para solicitarle servicios que éste puede atender. La figura siguiente ilustra cómo se implementa este modelo: 13 Las citas de las secciones 2.5.2, 2.7 y provienen de la misma fuente. [8]27 Capítulo 2: Marco de Referencia. Cliente Servidor Aplicaciones cliente Petición Respuesta Base de datos Fig. 2.5 Arquitectura Cliente - Servidor Una aplicación cliente servidor tiene tres componentes fundamentales: presentación (interfaz de usuario), lógica del negocio y gestión de datos. La implementación de la presentación se lleva a cabo en el cliente mientras que la gestión de datos y la lógica del negocio se distribuyen en el servidor, aunque también pueden estar de forma separada. El resultado es una arquitectura de dos capas de software. Actualmente, la lógica del negocio se ha convertido también en un servicio y puede residir en cualquier otro servidor, conocido como servidor de aplicaciones, dando lugar a una arquitectura de tres capas: Cliente Servidor de Aplicaciones Servidor de datos Aplicaciones cliente Procesos Base de datos Fig. 2.6 Arquitectura de tres capas de software. Así, los componentes de una aplicación diseñada según el modelo de tres capas serán: Presentación: contiene todos los elementos que constituyen la interfaz con el usuario. Esta capa incluye todo aquello con lo que el usuario puede interactuar, como por ejemplo una interfaz gráfica basada en ventanas, un explorador, etc. Lógica de negocio: aquí se modela el comportamiento del sistema, basándose en los datos provistos por la capa de datos y actualizándolos según sea necesario. Esta capa describe los distintos cálculos y otros procesos a realizar con los datos. Datos: representa el mecanismo para el acceso y el almacenamiento de la información. Generalmente consiste en un gestor de base de datos y el esquema de datos propio de cada aplicación28 Capítulo 2: Marco de Referencia. Las aplicaciones de tres capas tienen mayor capacidad de crecimiento y son más sencillas de mantener, dadas su naturaleza altamente modular. 2.7 SITIOS DINÁMICOS. Internet, es una red de redes informáticas distribuidas por todo el mundo que intercambian información entre sí mediante la familia de protocolos TCP/IP, representándose gráficamente como una nube de computadoras interconectadas: Computadora 1 Servidor Computadora 2 Fig. 2.7 Internet. Durante muchos años Internet sirvió para que muchos departamentos de investigación de distintas universidades distribuidas por todo el mundo pudieran colaborar e intercambiar información. En la actualidad forma parte de los negocios y de nuestra vida cotidiana; ha hecho que el mundo empresarial se replantee sus sistemas de comunicación internos y externos y en la mayoría de los casos los haya encausado vía Internet. La World Wide Web, también conocida como WWW o simplemente Web, es uno de los logros más interesantes en Internet puesto que constituye un sistema hipermedia interactivo que permite conectarse a grandes cantidades de información. La forma de establecer una conexión se realiza a través de un navegador o explorador de Internet. Al acceder a la Web, se observa una gran cantidad de páginas constituidas por gráficos, listas, formularios y otros elementos más, que en conjunción constituyen lo que se conoce como páginas Web. Para la implementación de éstas se utiliza el lenguaje HTML (Hyper Text Markup Language) y otras tecnologías como JavaScript y Jquery que permiten mejoras en la interfaz de usuario, contenido y una mejor interacción. HTML utiliza una serie de etiquetas intercaladas en un documento de texto sin formato. Dichas etiquetas son posteriormente interpretadas por los exploradores encargados de visualizar la página o el documento Web con el fin de establecer el formato. Cuando se tiene una página escrita que utiliza únicamente las tecnologías del cliente (HTML y JavaScript, por ejemplo) se dice que es estática. Esto significa que sus contenidos son siempre los mismos29 Capítulo 2: Marco de Referencia. Desde el punto de vista técnico, cuando una página estática es llamada por un cliente, baja al navegador como está y se muestra como es. Por otra parte una página dinámica es aquélla cuyo contenido se genera a partir de lo que un usuario introduce o solicita de manera personalizada. Cuando el cliente llama a una página dinámica, existe un proceso en el lado del servidor que crea en ese momento la página, incorporando los contenidos que el cliente ha solicitado y sirve la página recién creada al cliente. Otro cliente que solicite la misma página con otros contenidos recibirá un resultado diferente. Lo anterior deriva en la construcción de sitios dinámicos, es decir, sitios cuyo contenido puede variar y se genera en el servidor en el momento de la solicitud IMPLEMENTACIÓN DE UN SITIO DINÁMICO. Para construir un sitio dinámico básico se requieren diversos módulos para que brinde la funcionalidad anteriormente descrita. Los bloques fundamentales son: Arquitectura Cliente Servidor. Servidor de páginas web: programa que gestiona las solicitudes hechas al servidor realizadas por el cliente. Lenguaje Intérprete: tecnología instalada en el equipo servidor que lee el código de la página solicitada y lo ejecuta dando como resultado una página HTML que es enviada al cliente. Gestor de base de datos. Reports System será una aplicación dinámica; en su implementación se emplearán las siguientes herramientas: Apache: uno de los servidores de páginas web más extendidos en Internet, es gratuito, robusto, seguro ante los ataques en la red y fácil de configurar. Lenguaje PHP: un lenguaje de instrucciones interpretados cuya principal ventaja es la certeza de que las páginas van a ser vistas en cualquier computadora independientemente del navegador que tenga instalado el equipo cliente, es gratuito y fácil de configurar. MySQL: como sistema gestor de base de datos. La figura 2.8 muestra un diagrama de bloques que describe la funcionalidad de Reports System, considerando los aspectos recién mencionados:30 Capítulo 2: Marco de Referencia. Servidor de aplicaciones Petición Apache Reports System MySQL Explorador Web Consulta a base de datos Máquina Cliente P H P Respuesta Resultado HTML Formato a código HTML Fig. 2.8 Reports System. [9] La tecnología y herramientas que se emplearán para implementar Reports System han sido seleccionadas por la complejidad, tamaño del sistema y el tipo de empresas a las que está enfocado31 C A P Í T U L O 3: MESA DE SERVICIOS, ADMINISTRACIÓN DE INCIDENTES, NIVELES DE SERVICIO.32 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. 3.1 CICLO DE SOPORTE. 14 Cuando los usuarios de una organización tienen fallas técnicas con los servicios TI disponibles en la organización, se ven en la necesidad de solicitar ayuda especializada que les brinde una solución efectiva y eficiente. Por lo anterior, los departamentos de informática siguen todo un proceso desde la detección hasta la solución de tales fallas, lo que es conocido como ciclo de vida del soporte. Dentro del ciclo de vida del soporte que se brinda a los servicios y TI, existen varios niveles para dar solución a las fallas o requerimientos reportados por los usuarios, estos son los siguientes: Primer nivel o primer punto de contacto 15 : se refiere a la atención inmediata y telefónica a los usuarios con el objetivo de atender las fallas o solicitudes. Segundo nivel o Administradores de soporte: esta área es la encargada de brindar una solución a todas las fallas reportadas por los usuarios que no puedan ser resueltas en el primer punto de contacto, por lo tanto la atención es directa con el usuario. Tercer nivel o desarrolladores y especialistas: implica la intervención de especialistas que puedan dar soporte al segundo nivel. Cuarto nivel o proveedores externos: este nivel de soporte es utilizado cuando los tres niveles anteriores no pueden dar solución a las fallas de los usuarios, generalmente se ven implicados para hacer el uso de garantías de hardware o software para la infraestructura del cliente. Este trabajo de tesis hace énfasis al primer nivel del ciclo de soporte ya que el sistema que se implementará podrá ser utilizado por una Mesa de Servicios 16, no obstante los niveles posteriores podrán también hacer uso de éste. 14 Los apartados están basados en Información provista por Pink Elephant, una compañía experta en la administración de TI y consultoría de ITIL. [10] 15 Este término también es conocido como soporte inicial o soporte de primera instancia. 16 Dentro del ámbito informático, una Mesa de Servicios también es conocida como Service Desk33 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio TIPOS DE PRIMER CONTACTO. ITIL diferencia varios tipos de primer contacto: [11] Call Center: se basa en un servicio de manejo profesional de grandes volúmenes de transacciones telefónicas con la finalidad de hacer marketing 17. Mesa de Ayuda 18 : el propósito principal es el administrar, coordinar y resolver las fallas reportadas por los usuarios tan rápido como sea posible y asegurar que ninguna sea perdida, olvidada o ignorada, recabando los datos necesarios y utilizando las herramientas apropiadas para este fin. Mesa de Servicios: extiende los servicios proporcionados por una Mesa de Ayuda, es decir, no sólo se enfoca en la solución de incidentes, problemas y dudas que tienen los usuarios sino también provee soluciones para requerimientos de cambios, puede obtener los niveles de servicio acordados e impacta en el área financiera. Una de las ventajas de la Mesa de Servicios consiste en la utilización de una base de conocimiento que permite que varios incidentes sean resueltos desde la misma Mesa de Servicios evitando escalamientos. 3.2 MESA DE SERVICIOS. La estrecha relación que existe entre las tecnologías y servicios de información con los usuarios de una organización, obliga a tener un soporte de calidad en los servicios TI implantados en la empresa. Un soporte es de calidad cuando cumple con las siguientes características. Disponibilidad. Continuidad y eficiencia (de acuerdo a las necesidades del negocio). Es brindado sin importar la ubicación geográfica. Recepción de información clara y objetiva así como el entendimiento correcto de la misma. Solución de las fallas o requerimientos reportados por el personal, invirtiendo el menor tiempo posible. Infraestructura necesaria. 17 Es decir, las transacciones solo son registradas, en ningún momento son atendidas, solamente se transfieren a otra parte de la organización. 18 También denominada Help Desk o Centro de Ayuda34 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Con el afán de tener un soporte de calidad presente en las organizaciones, surge el concepto e implementación de las Mesas de Servicios que brinda un soporte de primer nivel, gestionando adecuadamente todas las fallas reportadas 19 en los servicios TI MISIÓN DE LA MESA DE SERVICIOS. La misión de una Mesa de Servicios es brindar un soporte de calidad, usando las TI y la infraestructura necesaria para ayudar a los usuarios de una organización a resolver sus necesidades cotidianas y cumplir con sus metas en el menor tiempo posible independientemente de su ubicación geográfica VISIÓN DE LA MESA DE SERVICIOS. Ayudar a los usuarios a hacer el mejor uso de los servicios y TI que forman parte de la infraestructura de la organización, brindando asistencia técnica y funcional para sus consultas, requerimientos o problemas y así facilitar el uso de las TI OBJETIVOS DE UNA MESA DE SERVICIOS. Los objetivos principales de una Mesa de Servicios son: [12] Asegurar la calidad de los servicios TI presentes en la empresa. Atención oportuna y eficaz al cliente. Mantener los niveles de servicio requeridos y establecidos entre el cliente y el proveedor. Mantener un alto nivel de capacitación del personal que la conforma, con el fin de lograr las metas establecidas y obtener una mejora continua ACTIVIDADES DE UNA MESA DE SERVICIOS. Las actividades principales de la Mesa de Servicios son: Responder las llamadas de los usuarios. Registro y seguimiento de incidentes, solicitudes de servicio hechas por el usuario. 19 Este proceso de gestión es conocido como administración de incidentes y requerimientos35 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Análisis de incidentes, solución de los mismos (en caso de ser posible) o bien su correcto escalamiento al área correspondiente para su atención. Seguimiento del ciclo de vida de un incidente o solicitud de servicio. Óptima comunicación con otras áreas del negocio. Mejoras e identificación de fallas dentro del servicio (esto se logra con proactividad lo que implica que la Mesa de Servicios se anticipe a la solución de problemas con el uso de manuales técnicos y de la KDB). Actualización de las bases de datos relacionadas con el negocio (por ejemplo: dar de alta a un nuevo usuario que trabajará dentro de la institución a la que se dará soporte). Educación de usuarios, una de las actividades más difíciles de realizar puesto que los capacita para que posteriormente puedan dar soluciones a sus incidentes de forma independiente. Esta actividad tiene como finalidad reducir las llamadas a la Mesa de Servicios BENEFICIOS DE UNA MESA DE SERVICIOS. Los principales beneficios de una Mesa de Servicios debidamente implementada son: Reducción de costos mediante una eficiente asignación de recursos (capacitación, equipo especializado). Reducción de tiempos de atención. Centralización de procesos que mejoran la gestión de la información y la comunicación. Mejora los niveles de servicio a usuarios de TI. Permite que el personal del área de informática se ocupe de funciones críticas del negocio. Brinda soporte a usuarios en horarios fuera de oficina. Proporciona una mejora continua al contar con la medición de niveles de servicio. Una mayor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo. Apertura de nuevas oportunidades de negocio36 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio ESTRUCTURA DE LA MESA DE SERVICIOS. La Mesa de Servicios básicamente es el punto de contacto de toda la infraestructura de TI con clientes y usuarios, por lo tanto es necesario que cumpla con las siguientes características: Debe ser de fácil acceso. Ofrece un servicio de calidad sólido y homogéneo. Proporciona información precisa a los usuarios y lleva un registro de toda la interacción con los mismos. Sirve de soporte al negocio. Con el objeto de que la Mesa de Servicios cuente con tales características, la implementación de la misma sigue una estructuración tanto lógica como física. Estructura lógica. Se conforma por el personal que integra la Mesa de Servicios. Los integrantes deben: Tener pleno conocimiento de los protocolos de interacción con el cliente: scripts, check lists, etc. Tener a su alcance herramientas de software que les permita llevar un registro de la interacción con los usuarios. Saber bajo qué situaciones se requiere hacer un escalamiento a instancias superiores o considerar el cumplimiento de los acuerdos de niveles de servicio (Service Level Agreements o SLA s 20 ) Contar con un acceso ágil y dinámico a la KDB con el fin de ofrecer un servicio eficiente a los usuarios y soluciones en el menor tiempo posible. Ser capacitados sobre los productos y servicios de la organización para mantener los estándares y soporte de calidad. 20 Consultar la sección 3.8 de este mismo capítulo37 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Estructura física. Físicamente, una Mesa de Servicios puede implementarse en tres formatos diferentes lo cual depende de las necesidades de servicio y del cliente, estos pueden ser: Modelo de Mesa de Servicios Local: provee soporte óptimo para una sola ubicación. Es aquí donde se ofrece el soporte de primer nivel. Niveles adicionales de soporte se localizan dentro de ubicaciones locales e individuales y las llamadas son registradas dentro de su propia instancia de la aplicación de Mesa de Servicios sin tener conocimiento de la actividad de las otras ubicaciones. Para una organización con múltiples ubicaciones, esto significa que cada ubicación tendrá su propia unidad de Mesa de Servicios. Para garantizar que la Mesa de Servicios Local sea efectiva para una organización de TI con ubicaciones de negocio múltiples, se debe coordinar y mantener la normalización en todas las instancias de las Mesas de Servicios. Para una organización que busque una administración uniforme en todo el negocio sin importar la ubicación, la estructura de la Mesa de Servicios Local no es la mejor opción y otros modelos deben considerarse. La operatividad de esta Mesa de Servicios se muestra en la figura 3.1. Fig. 3.1 Funcionalidad de una Mesa de Servicios que es apoyada por una KDB y la administración de los niveles de servicio. Se observa que hay una Mesa de Servicios por cada ubicación38 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Ventajas: Optimización de recursos y servicios para cada ubicación de Mesa de Servicios. Independencia de una localidad de otra cuando una organización cuenta con múltiples ubicaciones. Desventajas: Implica una inversión económica mayor para implementar una Mesa de Servicio por cada ubicación. Se dificulta el flujo de datos y conocimiento entre las diferentes Mesas de Servicios. Modelo de Mesa de Servicios Centralizada: se recomienda emplear este modelo cuando se requiere que todas las llamadas, sin importar su origen y ubicación, sean registradas en una ubicación física central. Para las organizaciones de TI con múltiples ubicaciones, esto reduce los costos operacionales y provee un reporte de gestión y estadísticas consolidadas. También puede mejorar los recursos disponibles en todo el negocio sin reparar en la ubicación geográfica. Una Mesa de Servicios Centralizada también puede consolidar el segundo nivel de soporte o superiores para que todas las llamadas sean administradas en la ubicación física matriz. La manera en que trabaja este modelo de Mesa de Servicios se puede contemplar en la figura 3.2. Fig. 3.2 Modelo centralizado de Mesas de Servicios39 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Ventajas: Se reducen costos de infraestructura y operacionales a largo plazo. Uso mejorado de recursos disponibles. Se logra una simplificación en la gestión de los niveles de servicio. Desventajas: Una Mesa de Servicios Centralizada, no puede atender solicitudes mundiales, se limita solo a un país. La implementación de una Mesa de Servicios Centralizada demanda una mayor infraestructura y personal a cargo de ésta, debido a que las fallas y solicitudes se realizan en una misma ubicación. Modelo de Mesa de Servicios Virtual: una Mesa de Servicios Virtual incorpora lo mejor de los dos modelos explicados anteriormente debido a la naturaleza de su ubicación. Mientras haya una conectividad adecuada entre las ubicaciones, el tener una Mesa de Servicios Virtual es una solución óptima para una organización de TI. Por lo tanto, una sola instancia de una aplicación de software que implemente este modelo de Mesa de Servicios provee una gestión de calidad constante de los procesos, estadísticas, escalamientos y notificaciones que, en turno, administran los incidentes, problemas, cambios y peticiones de servicio. Sin embargo, cualquier ubicación puede proveer soporte al usuario. Un asunto de interés con la estructura de una Mesa de Servicios Virtual es que generalmente necesita ser una interfaz común usada para la entrada de datos desde cualquier ubicación en el mundo. Esto permite que el personal de cualquier parte del mundo busque en un conjunto común de errores conocidos coincidencias de incidentes y funciones de diagnóstico de problemas. La Mesa de Servicios Virtual actualmente es el modelo más usado por empresas robustas puesto que provee una interfaz, procedimientos, procesos y estadísticas comunes con el objetivo de reducir costos, mejorar la calidad de servicio e incrementar la satisfacción del cliente. El modo en que esta estructura de Mesa de Servicios está conformada se observa en la figura40 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Fig. 3.3 Mesa de Servicios Virtual Ventajas: El conocimiento está centralizado. Se puede ofrecer un servicio local sin incurrir en gastos adicionales. La calidad de servicio es homogénea y consistente. Desventajas: Un inconveniente que surge con este modelo se observa cuando hay usuarios que se encuentran en diversas ubicaciones geográficas y cuentan con diferentes idiomas, productos y servicios. Su implementación es costosa y debe justificarse por los objetivos y la naturaleza del negocio así como las expectativas que se tiene sobre la provisión de los servicios41 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Como puede observarse, una Mesa de Servicios Virtual aprovecha las virtudes de las Mesas de Servicios Local y Centralizada. Por lo tanto, hay varias opciones para estructurar la función de la Mesa de Servicios dentro de una organización y es importante que al habilitar las tecnologías se tenga la flexibilidad para soportar alguno de estos modelos. Se debe recordar que la estructura de la Mesa de Servicios dentro de una organización hoy en día no necesariamente será óptima en cinco años o aún dentro de un año, por lo que se deben implementar soluciones que permitan el crecimiento y el cambio de acuerdo a las necesidades del negocio así como la evolución de la infraestructura TI IMPLEMENTACIÓN DE UNA MESA DE SERVICIOS. Para poder implementar una Mesa de Servicios es necesario realizar una minuciosa planeación. Para el éxito de la Mesa de Servicios deben establecerse cuestiones de carácter técnico así como aspectos relacionados con el factor humano. Así, la implementación de la Mesa de Servicios considera dos tipos de parámetros: técnicos y humanos. Técnicos. Cuáles son las necesidades? Cuáles han de ser las funciones a realizar? Quiénes serán los responsables de la Mesa de Servicios (asignación de roles para las personas que realizarán las funciones)? Qué cualidades técnicas y profesionales poseerán los integrantes del grupo de primer contacto? Considerar si se deben externalizar (outsourcing) ciertos servicios, por ejemplo el soporte técnico del hardware. Qué estructura o modelo de Mesa de Servicios (local, central o virtual), se adapta mejor a las necesidades de los implementadores y las de sus clientes? Qué herramientas tecnológicas son necesarias? Qué métricas determinarán el rendimiento de la Mesa de Servicios?42 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Humanos. Establecer estrictos protocolos de interacción con el cliente. Motivar al personal encargado de la relación directa con el cliente. Informar a los clientes de los beneficios del servicio de atención y soporte. Asegurar el compromiso de la dirección con la filosofía de la Mesa de Servicios. Realizar sondeos a los clientes para conocer mejor sus expectativas y necesidades. Profesionalismo, es decir tratar de encontrar soluciones en base a diferentes habilidades. Conocimiento técnico. Buena comunicación y alta capacidad de comprensión. En lo referente a la implementación de la Mesa de Servicios es importante recordar que el objetivo no es hacerlo lo más rápidamente posible sino lograr que los objetivos de la implementación: Se alineen con los procesos y necesidades del negocio. Se enfoquen a mejorar la satisfacción de los clientes. Optimicen la imagen externa de la organización. Sirva de plataforma que permita identificar nuevas oportunidades de negocio. Hay varios aspectos más que considerar a la hora de implementar una Mesa de Servicios. Además de los objetivos del negocio relacionados con la Mesa de Servicios también se deben considerar los niveles de madurez del uso de las TI y del negocio mismo, también es importante la creación y publicación de directrices que documenten los niveles de soporte que se espera que la Mesa de Servicios provea al negocio a través de SLA s que contemplen los tiempos de respuesta para tipos de llamadas específicas, definición de prioridades de servicio basadas en el impacto del negocio, el establecimiento de un periodo de tiempo antes de realizar un escalamiento y muchos otros. El determinar exactamente qué servicios de TI se proveerán para el negocio es crítico para tener éxito. Una planeación adecuada es indispensable para evitar problemas en el camino. Aún la mejor función de Mesa de Servicios será inútil si los procesos que soporta son inadecuados43 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Se debe asegurar el complementar la tecnología con servicios prácticos de asesoría que estén basados en los resultados y que rápidamente indiquen los niveles de madurez y la recomendación de estrategias encaminadas al mejoramiento del servicio EQUIPO Y FORMACIÓN DE UNA MESA DE SERVICIOS. La Mesa de Servicios debe poseer una gran calidad de servicio como se ha venido mencionando ya que es la imagen de la empresa. La gente que conforma este primer nivel debe establecer protocolos de servicio como: Atención al cliente. Trabajo en equipo. Conocimiento de los servicios. El éxito que posee una empresa no siempre es generado por la infraestructura, en la mayoría de los casos la gente que forma el equipo de trabajo y la cultura laboral que poseen marcan la diferencia. 3.3 MÓDULOS DE SOPORTE AL SERVICIO La metodología ITIL propone una serie de estándares enfocados al control, operación y administración de recursos y servicios de las TI. En el capítulo 2 se ha mencionado que para lograrlo, ITIL abarca dos grandes áreas conocidas como soporte al servicio y provisión de servicio. En el soporte de servicio, ITIL contempla 6 módulos funcionales que conforman las principales características de esta área que en conjunto logran garantizar la continuidad, disponibilidad y calidad del servicio prestado al usuario. Uno de estos módulos es la Mesa de Servicios, los 5 restantes representan procesos que manejan o gestionan aspectos específicos dentro de la metodología del soporte al servicio: Administración de incidentes. Administración de problemas. Administración de cambios. Administración de versiones. Administración de configuraciones44 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. En este capítulo se abarca lo referente a la administración de incidentes que junto con la administración de problemas y una KDB apoyan a la correcta operación de la Mesa de Servicios. 3.4 INCIDENTES. Un incidente se define como una falla inesperada en los servicios TI, totalmente ajena a la operación, esta falla puede causar una interrupción o una reducción de calidad, también puede provocar una degradación de los SLA s establecidos entre el cliente y el proveedor de los servicios TI. Un ejemplo de incidente es el reporte de un usuario que tiene problemas para conectarse a Internet por lo que no puede continuar con su trabajo de manera habitual ESTADOS DE UN INCIDENTE. A continuación se enuncian los estados ideales de un incidente (véase figura 3.4). 1.- Abierto: estado inicial del incidente en el que se realiza un diagnóstico de la falla por parte del personal que conforma la Mesa de Servicios, lo anterior en base a la información que el usuario proporciona. En el estado abierto se deben confirmar los datos del usuario; sólo puede ser utilizado por el personal que integra la Mesa de Servicios. 2.- Asignado: segundo estado de un incidente, el cual especifica el área asignada para la atención correcta de la falla reportada. Consiste en el escalamiento correcto en base al diagnóstico realizado en el estado abierto. Este estado puede ser usado por cualquier nivel. 3.- En proceso: tercer estado de un incidente, en esta etapa se procede a la atención del mismo ya sea en sitio o de forma remota 21 ; se deben considerar todas las posibles soluciones para la solución oportuna de la falla. Este estado puede ser usado por cualquier nivel. 4.- Resuelto: cuarto estado de un incidente; la falla ha sido resuelta en base a la mejor opción de solución. Este estado puede ser usado por cualquier nivel. 5.- Cerrado: quinto estado de un incidente donde la Mesa de Servicios debe confirmar con el usuario: el servicio, la solución brindada y la autorización para el cierre del incidente. En caso de que la solución no haya sido exitosa, el incidente deberá ser asignado nuevamente al área correspondiente para el seguimiento del mismo. Este estado sólo puede ser utilizado por el personal de la Mesa de Servicios. 21 La atención en sitio se da cuando el personal tiene que ir al lugar en donde se encuentra el usuario, mientras que la atención remota es cuando el incidente es atendido sin acudir al lugar de la falla45 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Existen dos estados opcionales, ya que no son obligatorios en la solución de un incidente: Pendiente: se suscita cuando intervienen factores externos para dar solución a la falla, por ejemplo: garantías, ausencia del usuario, entre otros. Este estado puede ser usado por cualquier nivel y sólo puede ser utilizado después de utilizar el estado en proceso. Cancelado: es un estado que se utiliza cuando: La atención a la falla es anulada por el mismo usuario. Existe una duplicidad de incidentes, es decir, se han generado dos o más incidentes con la misma falla y por el mismo usuario. INICIO FALLA EN SERVICIO TI ABIERTO DUPLICIDAD? SI CANCELADO NO ASIGNADO EN PROCESO NO FACTORES EXTERNOS? SI PENDIENTE NO RESUELTO SERVICIO VALIDADO POR EL USUARIO? SI CERRADO FIN Fig. 3.4 Estados de un incidente46 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. 3.5 REQUERIMIENTOS. Un requerimiento es un término general que abarca una solicitud de cambio o una petición de servicio 22 en la infraestructura o en los servicios TI. Al igual que los incidentes, están compuestos por diferentes estados (véase figura 3.5) los cuales son descritos a continuación: ESTADOS DE UN REQUERIMIENTO. 1.- Autorización: este estado es primordial para continuar con el proceso de la solicitud.en caso de que no exista autorización por parte del cliente, lo anterior debe ser notificado al usuario que ha solicitado dicha petición y por lo tanto la Mesa de Servicios no iniciará ningún proceso. Por el contrario si la petición es autorizada se inicia el proceso correspondiente para su debida atención y solución. 2.- Abierto: estado inicial de la solicitud que obtiene toda la información del requerimiento que desea el usuario. Este estado sólo puede ser utilizado por el personal de la Mesa de Servicios. 3.-Asignado: consiste en el escalamiento correcto en base a la petición realizada por el usuario. Este estado puede ser usado por cualquier nivel de soporte 4.-En proceso: en esta etapa se procede a la atención de la solicitud. Puede ser usado por cualquier nivel de soporte. 5.-Resuelto: solución de la solicitud en base a los recursos disponibles. Este estado puede ser usado por cualquier nivel de soporte. 6.-Cerrado: en este estado la Mesa de Servicios debe confirmar con el usuario: el servicio, la solución brindada y la autorización para el cierre de la solicitud. En caso de que la solución no haya sido exitosa, el reporte generado para la atención del requerimiento deberá ser asignado nuevamente al área correspondiente. Sólo puede ser utilizado por el personal de la Mesa de Servicios. De la misma forma que los incidentes, existen dos estados opcionales en los requerimientos: Pendiente: se suscita cuando intervienen factores externos para dar solución al requerimiento, por ejemplo: ausencia del usuario, falta de recursos, entre otros. Este estado puede ser usado por cualquier nivel y sólo puede ser utilizado después de utilizar el estado en proceso. 22 Una solicitud de servicio abarca concesiones de nuevas licencias, requerimientos de Información o documentación, cambio de Información de acceso, entre otros, con la particularidad de que estos servicios siempre sean considerados estándar. Cuando se solicite un cambio que requiera una modificación en la infraestructura TI, tal cambio es considerado como no estándar y necesita que inicie una petición de cambio (RFC, acrónimo de Request For Change) que es tratada de acuerdo al proceso de Administración de cambios47 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Cancelado: tal estado se utiliza cuando: El requerimiento es anulado por el mismo usuario. Existe una duplicidad de requerimientos, es decir, se han generado dos o más solicitudes con la misma petición y por el mismo usuario. Cuando no se tienen los recursos para llevar a cabo la solicitud. INICIO SOLICITUD DE SERVICIO NOTIFICAR AL USUARIO EL STATUS DE SU PETICIÓN. NO CUENTA CON AUTORIZACIÓN? SI ABIERTO DUPLICIDAD? SI CANCELADO NO ASIGNADO EN PROCESO PENDIENTE NO FACTORES EXTERNOS? SI NO RESUELTO SERVICIO VALIDADO POR EL USUARIO? SI CERRADO FIN Fig. 3.5 Estados de un Requerimiento48 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. 3.6 ADMINISTRACIÓN DE INCIDENTES Y REQUERIMIENTOS. Se define como administración de incidentes y requerimientos al control que la Mesa de Servicios lleva de ellos. La Mesa de Servicios es la encargada de registrarlos en un Sistema Service Desk, para darles el debido seguimiento desde su apertura hasta su cierre, esto con el único fin de resguardar los niveles de servicio acordados y la calidad en los servicios ofertados. Los factores que influyen para que los requerimientos puedan ser manejados por medio del mismo proceso de administración de incidentes son el tamaño de la organización y la frecuencia de los requerimientos OBJETIVOS DE LA ADMINISTRACIÓN DE INCIDENTES. Los dos grandes objetivos de una gestión de incidentes son los siguientes: Restaurar la operación normal del servicio lo antes posible y minimizar el impacto adverso sobre las operaciones del negocio. Garantizar que se mantengan los niveles de servicio de alta calidad y que la disponibilidad del servicio corresponda con los requerimientos de los clientes. Para cumplir con los objetivos citados es necesario realizar una constante detección de cualquier alteración en los servicios TI, registrarla y clasificarla así como asignar el personal encargado para restaurar el servicio como se indica en el SLA correspondiente. [13] La gestión de incidentes también define los procedimientos para el escalamiento y resolución de incidentes reportados. Más adelante, en este mismo capítulo, se profundizará sobre el escalamiento de los incidentes POR QUÉ UNA ADMINISTRACIÓN DE INCIDENTES? El uso e implementación de una administración de incidentes, proporciona una base para: Registrar los antecedentes, causas y detalles de un incidente (mayor control de los procesos y monitoreo del servicio). Evaluar los riesgos. Definir las acciones a seguir para la solución del incidente. 23 En el trabajo presente, la administración de incidentes incluye de forma implícita la gestión de requerimientos49 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Evaluar los impactos que puede ocasionar el incidente. Diagnosticar y escalar el incidente a las áreas de soporte en caso de ser necesario. Documentar y dar seguimiento al ciclo completo del incidente hasta su solución. Mejorar la productividad de los usuarios. Cumplimiento de los niveles de servicio. Optimización de recursos disponibles. Integración de una base de datos más concisa, que soporte la gestión de la configuración de los activos (Configuration Management Data Base, CMDB), debido que los incidentes se registran en relación con los elementos de configuración. Satisfacción general de clientes y usuarios. Para que se logre una adecuada implementación de la administración de incidentes deben definirse de manera clara los niveles de servicio requeridos así como los productos que soportarán. También es necesario que se establezcan procedimientos que permitan registrar y resolver incidencias así como la formulación de protocolos que facilite su clasificación y determinación de situaciones de escalamiento necesario. De esta manera se evitarán efectos adversos como: Reducción de los niveles de servicio. Mayor número de personal o nivel no adecuado trabajando en la resolución del incidente. Pérdida de información sobre las causas y efectos de los incidentes que sea útil para futuras referencias. Insatisfacción de clientes y usuarios por una gestión mala o lenta de los incidentes DIFERENCIAS Y SIMILITUDES ENTRE LA ADMINISTRACIÓN DE INCIDENTES Y LA ADMINISTRACIÓN DE PROBLEMAS. En lo referente a la administración de problemas, ITIL define un problema como la causa desconocida de uno o más incidentes. La principal finalidad de este proceso es prevenir tanto problemas como incidentes que sean recurrentes, así como lograr la minimización del impacto que los incidentes que no puedan ser prevenidos tengan sobre el negocio50 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Para que la administración de problemas produzca resultados efectivos, es necesario que se implemente una forma de establecer categorías y prioridades de los problemas durante su ciclo de vida con la finalidad de que se conviertan en un error conocido y se logre su posterior solución en el menor tiempo posible. Si bien los procesos de gestión de incidentes y problemas están fuertemente interrelacionados al ocuparse de incidentes, cada uno de ellos lo hace de manera específica lo que establece la clara diferencia que existe entre ellos. Mientras que la administración de incidentes se enfoca de modo exclusivo a restaurar la operación de un servicio interrumpido (incidente), la gestión de problemas se encarga de encontrar y analizar las causas que han originado un determinado incidente o conjunto de ellos (problema) CICLO DE VIDA DE UN INCIDENTE. En una Mesa de Servicios, el ciclo vida de un incidente está constituido por 3 procedimientos básicos que son: propiedad o dueño, monitoreo/seguimiento y comunicación. Dueño o propiedad: la Mesa de Servicios retiene o es dueño de todas las incidencias o solicitudes. Para coordinar la administración de incidentes, la Mesa de Servicios los retiene y administra hasta que se resuelvan a satisfacción del cliente. Monitoreo y seguimiento: la Mesa de Servicios se encarga de monitorear el estado de los incidentes y también les da seguimiento durante todo el progreso hacia la resolución y contra los niveles de servicio de todos los incidentes activos, es decir en un estado diferente a un estado cerrado. Comunicación: durante la gestión de incidentes, la Mesa de Servicios se encarga de comunicar todo lo referente a ellos entre las TI y el cliente. Los incidentes deben administrarse sobre la base de un ciclo de vida bien definido y previamente acordado. Los SLA s establecen los criterios con que se maneja un incidente a lo largo de este ciclo de vida. Durante su ciclo de vida, el incidente podrá ser atendido por diferentes áreas y niveles de soporte. Las políticas de escalamiento y notificación deben asegurar que el incidente sea atendido y solucionado en base al ciclo de vida que se ha establecido, asegurando de esta forma la continuidad en los servicios informáticos y el menor impacto en las labores del personal de la organización que haga uso de los mismos51 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio ACTIVIDADES REALIZADAS DENTRO DEL CICLO DE VIDA DE UN INCIDENTE. El diagrama de bloques de la figura 3.6 muestra el flujo funcional de un incidente durante su ciclo de vida, cada una de las etapas son explicadas en las páginas siguientes. Detección y registro del Incidente Clasificación y soporte inicial Solicitud de Servicio? SI Procedimiento de Solicitud de Servicio Propiedad, monitoreo, seguimiento y comunicación NO Investigación y diagnóstico Resolución y recuperación Cierre de Incidente Fig. 3.6 Ciclo de vida y actividades dentro de la administración de incidentes52 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Detección y registro de incidentes. En la administración de incidentes, la primera etapa es la detección de los mismos. La detección toma lugar cuando se presenta alguna anomalía o falla lo que se traduce como un error en algún sistema o que un usuario no puede hacer algo y por lo tanto recurre a pedir ayuda o bien el usuario necesita realizar una solicitud. Los incidentes entran al proceso a través de varias fuentes como usuarios vía la Mesa de Servicios, gestión de aplicaciones, gestión de redes, soporte técnico, entre otros. El registro debe realizarse inmediatamente para evitar tiempos de paro, elevación de costos e impacto en las actividades cotidianas del usuario así como la disminución del riesgo de nuevas incidencias que demoren el proceso. Esta actividad permite alertar a los grupos de soporte especializados conforme sea necesario. El registro de incidentes se lleva a través del procedimiento de los estados explicados en los apartados y Clasificación y soporte inicial. Ya que el incidente ha sido identificado, se hace una clasificación del mismo, es decir, se determina si la falla, error o anomalía que se presenta es conocida o si nunca se ha presentado. La clasificación de un incidente es un proceso realizado por el personal que integra la Mesa de Servicios y se fundamenta en la recopilación de toda la información que pueda resultar de utilidad para la resolución del mismo. Las fases que integran la clasificación de incidentes son categorización, priorización, asignación de recursos y el monitoreo del estado y tiempo de respuesta esperado. Categorización: en esta fase, el incidente es ubicado dentro de una categoría lo que depende del tipo de falla o solicitud, del grupo de trabajo responsable de su resolución. Para determinar en qué categoría se puede ubicar un incidente se deben identificar los servicios afectados o solicitados. En el proceso de categorización, los incidentes son clasificados y comparados contra los problemas y errores conocidos. Priorización: cuando hay múltiples incidencias/peticiones concurrentes, es necesario determinar un nivel de prioridad para que así puedan resolverse. ITIL define el proceso de priorización a partir de dos parámetros principales: el impacto y la urgencia. Impacto: determina la importancia del incidente puesto que representa el nivel hasta donde se interrumpe la provisión de servicios dentro de la organización o en su defecto el impacto que tiene la atención de una solicitud, por ejemplo el alta de un usuario en directorio activo, se puede indicar de acuerdo al número de elementos de configuración afectados y/o la cantidad de interrupciones de los procesos clave de negocio53 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Urgencia: está indicada por la velocidad con la que se debe resolver el incidente y depende ya sea del tiempo máximo de demora que el cliente acepte para su resolución o del nivel de servicio acordado. También hay otros elementos que determinan la prioridad de un incidente como son: el tamaño, alcance, complejidad y recursos necesarios para su resolución. La mayoría de los consultores ITIL recomiendan el uso de una matriz que calcule la prioridad considerando una granulación de ésta cuyo rango va de 1 (prioridad crítica) hasta 4 ó 5 (prioridad baja o mínima según sea el caso), ver imagen 3.7. Fig. 3.7 Matriz de prioridades en función de los parámetros urgencia e impacto. Los casos que derivan de la matriz son los siguientes: Urgencia Impacto Prioridad Alta Alto Crítica Media Alto Alta Baja Alto Media Alta Medio Alta Media Medio Media Baja Medio Baja Alta Bajo Media Media Bajo Bajo Baja Bajo Mínima54 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Un factor auxiliar que también se debe considerar cuando ocurre un incidente es el esfuerzo esperado que contempla el tiempo de resolución estimado, la cantidad anticipada de recursos necesarios así como el costo que en conjunto permitan la restauración de los servicios interrumpidos. Asignación de recursos: la Mesa de Servicios brinda un soporte inicial para la resolución del incidente y cuando no se puede resolver en primera instancia lo asigna a un grupo especializado (realizando un escalamiento 24 ) e informa a los clientes/usuarios sobre tal situación. En el caso de los requerimientos, la Mesa de Servicios únicamente levanta, escala y da seguimiento para su debida atención. Monitoreo del estado y tiempo de respuesta esperado: una vez que el incidente se encuentra clasificado, se le asocia un estado lo cual permite a la Mesa de Servicios darle seguimiento al proceso hacia la resolución. También se hace un estimado del tiempo de resolución del incidente en base al nivel de servicio acordado que le corresponda así como la prioridad asignada. Solicitud de servicio. Cuando se hace una petición de servicio se ejecutan los pasos establecidos en un manual de procedimientos para que de este modo se llegue a la solución de manera viable y eficiente y finalmente cerrar dicha petición. Cabe mencionar que el manual especifica las áreas a las que debe ser escalada la petición. Investigación y diagnóstico. Cuando se tiene una solución poco eficiente se presenta un caso no conocido, se realiza una investigación y diagnóstico de la situación evaluando detalles de la incidencia para atacar el problema de frente y resolverlo. Si la resolución del incidente supera el alcance de la Mesa de Servicios, se canaliza a un nivel superior para su investigación por expertos asignados. Si éstos, no pudieran resolver el incidente, se siguen los protocolos de escalamiento predeterminados. Para dar seguimiento al estado del incidente durante todo su ciclo de vida, se deberá almacenar información sobre su avance en el sistema Service Desk correspondiente. Resolución y recuperación. Ya que se cuenta con el análisis del contexto de la solución se ejecuta la propuesta de solución del incidente y se realiza un estudio para saber si la incidencia es recuperable o un caso perdido (la mayoría de los casos son recuperables a menos de que el nivel de daño sea muy fuerte que es cuando un caso se da por perdido). Cuando se necesita un cambio en la infraestructura 24 El escalamiento de incidentes y los niveles de soporte son explicados en la sección55 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. de TI para la resolución de la incidencia se genera una petición de cambio (RFC). Si la incidencia fuera recurrente y no se le puede dar una solución definitiva, la gestión de problemas se encarga de la situación para estudiar detalladamente las causas subyacentes. Cierre del incidente. Cuando se genera una solicitud de servicio y se le da una solución por medio del manual de procedimientos, el siguiente paso consiste en documentarla y contabilizar el requerimiento para determinar el nivel de ocurrencia de ese caso, por último se hace una evaluación para ver si el requerimiento ha sido resuelto de forma satisfactoria y de serlo así, se cierra. En relación a los incidentes, cuando se tiene un caso no conocido o una solución anteriormente planteada pero ineficiente o poco acertada se debe hallar una solución para el incidente, se implementa y así se restaura el servicio. El personal de la Mesa de Servicios confirma la resolución al cliente o a quien lo originó e investiga si el servicio se ha restaurado como se requiere. Si es el caso, entonces se actualiza el estado y se cierra el incidente. Posteriormente, la información de la solución se almacena en la KDB para que en el momento de que el incidente vuelva a presentarse ya esté documentado, de esta forma será un caso conocido lo cual hará que su solución sea realizada más fácil, rápida, eficientemente y con el menor impacto posible ESCALAMIENTO DE INCIDENTES Y TIPOS. Una vez que el incidente ha sido clasificado, se busca información en la KDB para determinar si hay incidencias o errores conocidos con las mismas características, en caso afirmativo se puede emplear la solución ahí almacenada para restaurar el servicio (se dice que la Mesa de Servicios resuelve en primera instancia el incidente). Si la incidencia no se puede relacionar entonces se tiene una incidencia única y es muy probable que la solución no se encuentre en la Mesa de Servicios por lo que hay que referirlo al siguiente nivel de soporte (se recurre a un especialista o algún superior que esté facultado para la toma de decisiones). A este proceso se le denomina escalamiento. El escalamiento se define como el mecanismo que ayuda a la resolución de una incidencia dentro de los tiempos especificados, puede realizarse durante cualquier actividad del proceso de resolución. Básicamente, hay dos tipos de escalamiento: funcional y jerárquico. Escalamiento funcional. Requiere el soporte de un especialista de más alto nivel para resolver el incidente. Es la transferencia de una incidencia del grupo de soporte de primer nivel hacia el segundo nivel, o más allá. Esta clase de escalamiento se produce por la falta de conocimiento o experiencia por parte de la Mesa de Servicios. También se puede producir cuando los intervalos de tiempo acordados se sobrepasan. En otras palabras, si es necesario involucrar más gente, más departamentos, más conocimiento entonces56 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. se realiza el escalamiento funcional (también denominado escalamiento horizontal) para la solución de incidencias. Escalamiento jerárquico. Si la solución del incidente requiere más soporte de la dirección, más dinero, más poder, es decir, si se debe acudir a un responsable de mayor autoridad para tomar decisiones que no competan a las asignadas a la Mesa de Servicios (por ejemplo, asignar más recursos), entonces es necesario efectuar un escalamiento jerárquico (también llamado vertical). El escalamiento jerárquico se puede producir en cualquier momento durante el proceso de resolución cuando se estime que probablemente el incidente no se puede resolver en tiempo (existe la posibilidad de que se exceda el tiempo indicado en el acuerdo de nivel de servicio) o de manera satisfactoria. En la figura 3.8 [8] se muestra la forma en que se debe realizar un escalamiento dependiendo si éste implica la necesidad de una mayor competencia de personal o conocimiento o una mayor autoridad para la toma de decisiones. Fig. 3.8 Tipos de Escalamiento en base a lo que es requerido: mayor competencia o autoridad PROCESO DE ESCALAMIENTO DE INCIDENTES A TRAVÉS DE LOS NIVELES DE SOPORTE. La Mesa de Servicios provee un soporte de primera instancia cuando se tiene conocimiento de la ocurrencia de una incidencia, en caso contrario se dice que es única y es referida al siguiente nivel de soporte. Los niveles de soporte de segundo o tercer nivel están representados por personal que cuenta con más habilidades, conocimientos, especialistas, tiempo o más recursos que permitan resolver las incidencias. Recordando que la Mesa de Servicios ofrece soporte de primer nivel, el procedimiento de resolución de una incidencia es como sigue:57 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Paso 1: la Mesa de Servicios intenta resolver lo reportado por el usuario para lo cual efectúa la evaluación inicial y busca una solución, si la encuentra, se genera el reporte correspondiente y se cierra desde la Mesa de Servicios, en caso contrario lo refiere al siguiente nivel. Paso 2: se asigna el reporte de servicio generado al soporte de segundo nivel o administración de soporte. Si el soporte de segundo nivel es capaz de encontrar una solución, refiere de nuevo a la Mesa de Servicios para que cierre los reportes generados. Si no, transfiere el reporte al siguiente nivel. Paso 3: el reporte de servicio es asignado al soporte de tercer nivel. Si el soporte de tercer nivel puede encontrar una solución, regresa de nuevo a la Mesa de Servicios para que cierre los reportes generados. En caso contrario, es escalado al nivel siguiente. Paso 4: se transfiere la llamada de servicio a un proveedor externo. Si éste puede encontrar la solución, refiere de vuelta a la Mesa de Servicios para que finalice. Cuando no es del todo claro qué nivel de soporte debería investigar o resolver el incidente o solicitud, la Mesa de Servicios, como propietaria de los reportes debe coordinar el proceso de administración de incidentes o incluso puede escalarlos al equipo de administración de problemas. Tomando en cuenta los niveles de soporte mencionados, el proceso de escalamiento se puede representar gráficamente como se contempla en la figura58 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. PROCESO DE ESCALAMIENTO 1ER NIVEL MESA DE SERVICIOS 2DO NIVEL ADMINISTRACIÓN 3ER NIVEL ESPECIALISTAS Y DESARROLLADORES 4TO NIVEL PROVEEDORES DETECCIÓN Y REGISTRO CLASIFICACIÓN Y SOPORTE INICIAL PROCEDIMIENTO DE SOLICITUD DE SERVICIO SI SOLICITUD DE SERVICIO NO INVESTIGACIÓN Y DIAGNÓSTICO RESUELTO? NO INVESTIGACIÓN Y DIAGNÓSTICO SI RESOLUCIÓN Y RECUPERACIÓN RESUELTO? NO INVESTIGACIÓN Y DIAGNÓSTICO SI RESOLUCIÓN Y RECUPERACIÓN RESUELTO? NO... SI RESOLUCIÓN Y RECUPERACIÓN CERRAR INCIDENTE Fig. 3.9 Los niveles de soporte en el escalamiento de incidentes. Las responsabilidades del primer nivel de soporte incluyen: Registro del incidente. Transferir los reportes de servicio a los grupos de soporte cuando el usuario afectado no autorice el cierre. Soporte inicial (que en ocasiones implica solución directa) y clasificación. Propiedad, monitoreo y seguimiento, comunicación. Cierres de incidentes59 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. El segundo nivel de soporte estará involucrado en tareas como: Administrar las solicitudes de servicio. Monitorear los detalles del incidente, incluyendo los elementos de configuración afectados. Investigación y diagnóstico del incidente. Detección de posibles problemas y la asignación de los mismos al grupo de la administración de problemas para que generen el registro correspondiente. La resolución y recuperación de los incidentes asignados. Si el incidente no puede resolverse en el segundo nivel entonces el tercer nivel de soporte realizará las siguientes actividades: Investigación y diagnóstico del incidente. Detección de posibles problemas y la debida transferencia de éstos al grupo de administración de problemas por medio de la Mesa de Servicios. La resolución y recuperación de los incidentes asignados El cuarto nivel de soporte (y demás niveles superiores) se ocupa de realizar las mismas tareas que el tercer nivel de soporte. Se llega a este nivel cuando no se halla la solución en el nivel de soporte anterior y el incidente es referido al nivel inmediato superior CONTROL DEL PROCESO DE ADMINISTRACIÓN DE INCIDENTES Y REQUERIMIENTOS. La elaboración de informes sobre la forma en cómo se han gestionado los incidentes es vital para lograr tener un control del proceso de manejo de los mismos. La información y estadísticas sobre el número de incidencias, la eficiencia y disponibilidad sobre el proceso de gestión, todo es recabado para la creación de los informes. La información contenida en estos documentos es fundamental para: El manejo de los niveles de servicio: así los clientes tienen a su alcance información exacta sobre el cumplimiento de los SLA s y tendrán la oportunidad de implementar medidas correctivas cuando no se cumplan. Llevar a cabo el monitoreo del rendimiento de la Mesa de Servicios: permite determinar el grado de satisfacción del cliente por el servicio prestado y supervisar que el primer nivel de soporte funcione correctamente60 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Revisión de protocolos y duplicidad: los administradores deben supervisar y controlar la aplicación de protocolos preestablecidos en el proceso de escalamiento y evitar las duplicidades en el proceso de manejo de incidentes. Cuando los protocolos contemplados no sean adecuados para la estructura de la organización o las necesidades del cliente, en ambos casos se deben implementar medidas correctivas. Contar con información estadística: para situaciones futuras que incluyan la asignación de recursos, costos asociados al servicio, etc. Parte del contexto de control de la gestión de incidentes está constituida por la infraestructura necesaria para su implementación y el uso de métricas que permitan evaluar del modo más objetivo posible el funcionamiento del servicio INFRAESTRUCTURA NECESARIA PARA LA IMPLEMENTACIÓN DE LA ADMINISTRACIÓN DE INCIDENTES. Entre los elementos necesarios que facilitan una correcta implementación del manejo de incidentes, figuran los siguientes: Un sistema automatizado cuya funcionalidad se encargue del registro de incidentes, requerimientos y de la relación con los clientes. Una KDB que permita la comparación de nuevas incidencias con las ya registradas y resueltas. Las ventajas de una KDB permiten: Evitar escalamientos innecesarios. Que el conocimiento de los técnicos sobre cómo realizar un procedimiento de resolución llegue a ser un activo duradero de la empresa. Una CMDB que disponga del conocimiento de todas las configuraciones actuales y el impacto que éstas puedan tener en la resolución del incidente MÉTRICAS QUE DEBEN OBSERVARSE EN LA ADMINISTRACIÓN DE INCIDENTES. Con el objetivo de dar un eficiente seguimiento al proceso de gestión se deben emplear métricas que evalúen el funcionamiento del servicio provisto, entre las que figuran: El número total de incidentes que se han clasificado por prioridades61 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Tiempos de resolución categorizados de acuerdo al impacto y urgencia de los incidentes. Costos asociados. Uso de los recursos que estén disponibles en la Mesa de Servicios. Porcentaje de incidentes por grupos de soporte. 3.7 ADMINISTRACIÓN DEL NIVEL DE SERVICIO. La administración de niveles de servicio son los procesos de planeación, coordinación, diseño, acuerdo, monitoreo y generación de los reportes de los SLA s y la revisión continua de los logros del servicio para garantizar que la calidad requerida del mismo a un costo justificable sea mantenida y mejorada gradualmente. La administración del nivel de servicio involucra tanto al cliente como al proveedor de servicios TI, ya que ambos monitorean, negocian y definen los niveles de servicio OBJETIVOS DE LA ADMINISTRACIÓN DEL NIVEL DE SERVICIO. Sus objetivos son mantener y mejorar la calidad del servicio TI, a través de un ciclo constante de acuerdo, monitoreo y generación de reportes para satisfacer los objetivos de negocio del cliente. La administración del nivel de servicio mantiene la relación entre el cliente y el proveedor de servicios TI (que puede ser interno o externo a la organización del cliente) a través de los acuerdos de nivel de servicio (SLA s) y los Acuerdos de Nivel Operacional (OLA s) ACTIVIDADES DE LA ADMINISTRACIÓN DEL NIVEL DE SERVICIO. La administración del nivel del servicio consta de 4 fases, las cuales se muestran en la figura siguiente: Fig Etapas de la administración del nivel de servicio. 25 Un OLA, es un acuerdo interno del proveedor de servicios, lo que significa que el cliente no tiene conocimiento de este acuerdo, a menos que el proveedor sea interno a la organización62 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Planificación. Consiste en la designación de un administrador del nivel de servicio, definición de roles y responsabilidades, identificación de las capacidades del monitoreo y las herramientas de soporte. También se realiza una evaluación inicial sobre la percepción de los servicios. Dentro de esta fase, debemos considerar los siguientes aspectos: Cuáles son los servicios que se deben ofrecer al cliente? Qué necesidades tiene el cliente? Cuál es el nivel adecuado de calidad de servicio? De qué forma serán suministrados los servicios y quiénes serán los encargados de realizar esta operación? Cuáles serán los indicadores claves de rendimiento para los servicios prestados? Se disponen de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados? La fase de planificación debe concluir con la elaboración y aceptación de los acuerdos necesarios para la prestación del servicio, estos acuerdos incluyen los acuerdos de nivel de servicio (SLA) y acuerdos de niveles de operación (OLA). Implementación. En esta fase se cuantifican las actividades y se establecen los recursos, los fondos y los criterios de calidad. Abarca también la identificación de riesgos, así como la planeación del catálogo de servicios y las estructuras de los SLA s. Algunos factores vitales, de los que va a depender en gran medida la obtención de los resultados deseados son: Aspectos críticos: son la definición de procedimientos estándares y los mecanismos de evaluación y seguimiento. Puntos Clave: Definición de objetivos que contribuyan a mejorar la eficacia y reducción de costos. Identificar lo que se espera del acuerdo (sistemas soportados, servicios incluidos, entrega del servicio, horas de operación, definición de compromisos, métricas para ambas partes)63 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Adecuada planeación temporal. Las principales actividades durante la implementación de los SLA s son las siguientes: Creación del catálogo de servicios: formulación de un borrador de SLA s cuando su estructura y redacción son finalizados. Negociación: se buscan los acuerdos para los SLA s y se identifican las alternativas de monitoreo. Revisión de OLA s: para determinar la compatibilidad entre ambos (SLA s y OLA s), también contempla los forma en como habrán de definirse los procedimientos de generación de reportes y de revisión. Firma y publicación de los SLA s. Monitorización. En esta fase se deben de ejecutar los procedimientos establecidos para la obtención de reportes y métricas de los servicios entregados (reportes de logros del servicio y reportes de operación). Para poder realizar esta tarea es necesario haber establecido con anterioridad los parámetros de calidad de servicio, pues guiarán en la elaboración de informes correspondientes. Las principales fuentes de información que constituyen estos reportes son: Documentación: SLA s, OLA s. Administración de incidentes: informa de las incidencias en el servicio y los tiempos de recuperación. Mesa de Servicios: ya que tiene un trato diario con el cliente, usuarios y organización TI, lo anterior le permite supervisar la calidad de los servicios y conocer la percepción del cliente respecto a los mismos. La información que deben cubrir los reportes generados es: Cumplimiento de los SLA s, que contempla información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio. Quejas, justificadas o no de los clientes o usuarios. Disponibilidad del servicio. Tiempos de respuesta. Costos reales del servicio ofrecido64 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Problemas detectados y cambios realizados para restaurar la calidad del servicio. Revisión. La administración de niveles de servicio es un proceso continuo que requiere revisiones periódicas de la calidad de los servicios TI ofrecidos, con el único fin de mejorarlos. El resultado de este conjunto de revisiones genera un documento denominado SIP o Programa de Mejora del Servicio que toma en cuenta factores como: Nuevas necesidades del cliente. Problemas y posibles causas relacionados con el servicio TI. Avances tecnológicos. Cumplimiento de los SLA s y OLA s. Evaluación de los costos reales del servicio. Degradación de la calidad del servicio en la estructura organizacional del cliente. Evaluación del desempeño y capacitación del personal involucrado. Reasignación de recursos. Percepción del cliente y usuarios sobre la calidad del servicio. Necesidades de formación adicional a los usuarios de los servicios. La finalidad de estas revisiones es realizar un análisis de los logros obtenidos y anticiparse a cualquier problema que pueda presentarse a futuro. El proceso de revisión engloba la actualización de SLA s, contratos de servicio acordados y los OLA s. 3.8 ACUERDO DE NIVELES DE SERVICIO (SLA). Un SLA es un acuerdo entre el cliente y el proveedor de servicios TI que define los objetivos claves del servicio y las responsabilidades de ambas partes; un solo SLA puede cubrir múltiples servicios de TI. Es importante destacar que estos objetivos deben ser claramente comprendidos y acordados por ambas partes para evitar disputas y malos entendidos. [14]65 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio OBJETIVO DE LOS SLA S. Los objetivos de un SLA son: [15] Identificar qué servicios pueden ser brindados y a qué clientes. Establecer el nivel y calidad de servicio que puede esperar el cliente. Describir cómo deben ser entregados los servicios (tiempo, calidad, disponibilidad y seguridad). Estipular las penalizaciones, en caso de que los tiempos de provisión no se cumplan. Determinar la forma en que el proveedor de servicios hará el monitoreo, rastreo y reporte del desempeño. Indicar cuándo un SLA debe ser revisado y en qué situaciones puede ser modificado CATÁLOGO DE SERVICIOS. Un catálogo de este tipo representa una lista o portafolio de todos los servicios que se brindan, un resumen de sus características, los detalles de los clientes y los responsables del mantenimiento de cada uno. Se tendrá que realizar un trabajo minucioso para realizar esta lista y llegar a un acuerdo operacional con los clientes. Una CMDB o una base de datos, puede ser una valiosa fuente de información. Dentro de este listado, se define una jerarquía de servicios calificando qué tipo de servicio es y su infraestructura; el catalogó de servicios contiene 26 : Número y fecha de versión, fecha de creación. Tabla de contenidos. Perfil del proveedor de servicios TI. Horas de servicios y accesibilidad del proveedor de servicio TI. Resumen de los servicios y productos. Servicio centrado en el cliente o descripción del producto. 26 Para la implementación de Reports System se definió un portafolio de servicios básico que no incluye todas las características citadas puesto que éstas figurarán cuando se celebre un contrato de implantación del sistema en alguna organización. El catálogo de servicios de Reports System está disponible para consulta en el anexo II de esta tesis66 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Especificaciones. Entregables. Horas de mantenimiento. Horas de soporte. Horas de entrega. Objetivos de calidad (disponibilidad, confiabilidad, facilidad de uso y prioridad). Requerimientos. Solicitud y procedimiento de cambio. Política de contingencia. Determinación de penalizaciones (precios y cargos). Índice y definiciones ESTRUCTURA DE UN SLA. En base al catálogo de servicios, la administración del nivel de servicio planea una estructura apropiada del SLA para asegurar que se cubran todos los servicios en la manera que más convenga al cliente. La estructura de un SLA puede ser: Basada en el cliente: Es decir un acuerdo con un solo grupo de clientes que considere todos los servicios que utilizan. A menudo los clientes se inclinan por este tipo de estructura, en el que todos sus requerimientos se incluyen en un solo documento. Basada en el servicio. Cuando un SLA cubre un servicio para todos los clientes. Este tipo de estructura es aparentemente simple, sin embargo se dificulta cuando existen requerimientos específicos de diversos clientes para el mismo servicio o si las características de la infraestructura de TI indican que forzosamente se requiere un nivel de servicio diferente. SLA s multinivel. Algunas organizaciones han elegido adoptar una estructura SLA multinivel, lo que significa que pueden existir SLA s que midan los67 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. tiempos, la calidad y disponibilidad al cliente de los servicios TI que la organización provee CONTENIDOS DE UN SLA. El contenido de un SLA puede variar, ya que depende de las necesidades del negocio, sin embargo hay un número de características comunes que se aplican dentro del contenido de todo SLA, éstas son: Introducción: esta parte debe considerar los siguientes aspectos: Partes del acuerdo y firmantes. Título y breve descripción del acuerdo. Responsabilidades entre el proveedor de servicios TI y el cliente. Fechas de comienzo, fin y revisión. Alcance del acuerdo (qué está cubierto y qué excluye). Descripción de los servicios cubiertos. Horas de servicio. Horas en las que el servicio es requerido. Acuerdos para solicitar extensiones de servicio, incluyendo periodos de aviso necesarios. Horas especiales, tales como días feriados. Calendario de servicio. Disponibilidad. Los objetivos de disponibilidad dentro de las horas acordadas se expresan a menudo como porcentajes y deberían ser incluidos en el SLA así como el período y método de medición. Confiabilidad. Expresa por lo general el número de interrupciones de servicio. Tiempo promedio entre fallas o el tiempo promedio entre incidentes de sistema. Soporte. Identificación de horas de soporte, en particular si no son las mismas que las del servicio. Tiempo básico de respuesta, presencial o a través de otro medio68 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Rendimiento. Indicación de los volúmenes de tráfico posibles y la actividad de desempeño. Tiempos de respuesta de transacción. Se incluyen los tiempos de respuesta para promedio o máximos de las estaciones de trabajo. En general se expresan en porcentaje. Cambios. Los objetivos para probar, manejar e implementar peticiones de cambio a menudo se basan en la categoría, urgencia o prioridad del cambio. Continuidad y seguridad del servicio TI. En este punto se establecen los planes de continuidad del servicio TI y la manera de llevarla a cabo en caso de que exista una contingencia. Cobranza. Los detalles y periodos de cobranza. Si el SLA cubre una relación de subcontratación, los cargos deben detallarse en un apéndice. Generación de reportes y revisión de servicio. Contenido, frecuencia y distribución de los reportes de servicio. Frecuencia de las reuniones de revisión del servicio. Seguridad. Se detallan las responsabilidades específicas de cualquiera de las partes, en base a las políticas de seguridad establecidas en la organización. Capacidad de mantenimiento. Abarca los marcos de tiempo aceptables que puede esperar un cliente cuando un cierto servicio o componente está fuera de servicio o es restaurado; La programación del tiempo fuera de servicio debe ser reflejada en el SLA. Capacidad del servicio. La capacidad del servicio tiene que ver con los contratos de servicio acordados con proveedores TI externos69 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. 3.9 ACUERDOS DE NIVEL DE OPERACIÓN (OLA). Un OLA (acrónimo de Operational Level Agreement) es un acuerdo realizado entre dos departamentos internos de TI (por ejemplo el proveedor de servicios TI y otra parte de la misma organización) que define los servicios a proveer y las responsabilidades de ambas partes. [16] Un OLA respalda el cumplimiento de los SLA s, frecuentemente incluye horas de operación, responsabilidades, autoridades, sistemas soportados, etc. Los OLA s tienden a ser más técnicos que los SLA s pues definen el soporte de TI IMPLEMENTACIÓN DE UN OLA. La implementación de un OLA 27, puede ser complicada ya que pueden existir fallas en el desempeño de las funciones primarias o en las responsabilidades acordadas. Se debe hacer énfasis en que la meta de un OLA es la optimización de la entrega de los servicios TI al cliente; la definición e implementación deben realizarse en equipo, es decir con la cooperación de todas las partes involucradas. Para implementar un OLA, se deben realizar los siguientes pasos: Se requiere un catálogo de servicios, el mismo definido por la administración del nivel de servicio. Los servicios descritos en éste, son la base para entender los OLAS s requeridos. El siguiente paso es revisar exactamente cómo los diversos departamentos de TI y las organizaciones van a garantizar los servicios descritos en el catálogo. Para cada servicio TI, se debe preparar una hoja de trabajo que describa las actividades que las diferentes áreas deben desempeñar, incluyendo detalles y especificaciones. Se debe establecer un comité de trabajo que evalué y revise los resultados, es muy importante que todas las partes estén de acuerdo. Desarrollar un sistema de monitoreo que registre y reporte el desempeño de un OLA; esta parte es similar a la monitorización de los SLA s. La administración del nivel de servicio es la encargada de procesar la monitorización de los OLA s establecidos. Considerando los puntos anteriores, se debe generar un borrador de un OLA cuyos contenidos más comunes son: 27 El apartado ha sido traducido del artículo Solving the IT silo problem. Un silo es un centro de tecnología que cuenta con su propia administración y equipo lo que conlleva que la comunicación con otros silos genere problemas de coordinación y comunicación. La implantación de OLA s es el medio efectivo para lograr que los distintos grupos TI trabajen conjuntamente y cumplan con los requerimientos de nivel de servicio establecidos. [17]70 Capítulo 3: Mesa de Servicios, administración de incidentes, niveles de servicio. Control de documentación e información de la versión: el OLA debe estar bajo el control de la administración de cambios y residir en la CMDB. Autorizaciones, fechas y firmas: el OLA debe ser autorizado para que pueda entrar en operación, lo cual requiere la firma de las partes involucradas. Objetivos y alcance: se debe establecer claramente el propósito del OLA para lograr los servicios establecidos en el catálogo de servicios. Involucrados: las partes implicadas en las firma de un OLA. Servicios cubiertos: establece específicamente los servicios provistos por cada organización involucrada, listando los entregables de cada parte. Roles y responsabilidades: para los servicios acordados, documentar quién tiene la responsabilidad de cada paso en la entrega del servicio. Prioridades y escalamiento: están enfocadas a garantizar la entrega del servicio solicitado, tal y como ha sido acordado y acelerar el soporte de acuerdo al nivel de prioridades. Tiempos de respuesta: definir claramente y sin ambigüedad el tiempo requerido para responder a las peticiones. Reporteo, revisión y auditoria: todo acuerdo requiere de supervisión y generación de reportes. Esta sección define claramente la duración del OLA, cuándo y bajo qué condiciones debe revisarse, cómo y a quién reportar. Esta sección también incluye indicadores de desempeño clave para que el dueño del OLA pueda darle seguimiento al desempeño y si es necesario tomar alguna acción antes de que ocurra algún incumplimiento. Apéndices: incluye referencias a documentación relacionada, procedimientos, definiciones y cualquier otro recurso que facilite el seguimiento, comprensión y mantenimiento del OLA. Publicación del borrador: negociación de los detalles y aseguramiento del acuerdo entre las partes involucradas para que finalmente el OLA sea firmado. Posteriormente el OLA se pone bajo el control de la administración de cambios y se almacena en la CMDB. También debe verificarse la vigencia del OLA. Proveer entrenamiento sobre cómo emplear el OLA: para poder publicarlo y comenzar a utilizarlo71 CAPÍTULO 4: ANÁLISIS Y DISEÑO DE REPORTS SYSTEM.72 Capítulo 4: Análisis y Diseño de Reports System. 4.1 REPORTS SYSTEM: UN SISTEMA SERVICE DESK. Un sistema Service Desk es la integración de las peticiones de Help Desk, activos y administración de solicitudes (por ejemplo altas, bajas, cambios de usuarios), ayuda a administrar efectivamente la tecnología TI de una organización. Usualmente este tipo de sistemas es desarrollado bajo alguno de los marcos de referencia de procesos para la administración de TI existentes en el mercado tales como COBIT 28, etom o ITIL. Reports System integrará las características de un sistema Service Desk, con el objetivo de administrar los servicios TI (gestión de incidentes y solicitudes realizadas por los usuarios de una empresa). 4.2 ANÁLISIS PARA LA IMPLEMENTACIÓN DE REPORTS SYSTEM. Dado que se conoce y comprende la problemática a resolver, se propone Reports System como una alternativa de solución al planteamiento anterior lo que requiere recabar información necesaria y suficiente para alcanzarla, lo cual implica realizar un análisis de los requerimientos. El análisis de requerimientos especificará la funcionalidad y comportamiento de Reports System lo que permitirá conocer la arquitectura de esta aplicación, el dominio de información que tratará así como su presentación y obtención a través de interfaces LISTA DE REQUERIMIENTOS. Los requerimientos para la implementación de Reports System son los siguientes: 1.- Autenticación de usuarios usando credenciales de acceso. El ingreso al sistema debe estar controlado, por lo que el Administrador tendrá a su cargo el otorgar un nombre de usuario y contraseña a cada uno de los usuarios del sistema. Cabe mencionar que al momento de ingresar a Reports System, éste gestiona las actividades de reconocimiento de usuario considerando primer nivel, segundo nivel o Administrador. 28 Para mayor información sobre marcos de referencia de administración de TI, consultar Anexo I73 Capítulo 4: Análisis y Diseño de Reports System. 2.-Constará de tres módulos principales, los cuales deben realizar acciones específicas: Módulo de herramientas que permitirá: Efectuar Altas, Bajas y Cambios (ABC), tanto del personal que integra la Mesa de Servicios como el de los usuarios de la organización. Constituir una CMDB en la cual se cargue la información de los CI s. Conformar una KDB que permita documentar los procedimientos para solicitudes, manuales de soluciones comunes de incidencias recurrentes con la finalidad de resolver en el menor tiempo posible las fallas reportadas. Tales documentos deber ser en formato PDF ya que el visor Adobe Reader es de libre distribución y no facilita la edición de documentos a menos que se cuente con software de edición con las licencias debidas; se solicita que sean publicados únicamente por el Administrador del sistema. Módulo estadísticas el cual representará un indicador orientado al seguimiento de reportes ingresados al sistema y a la generación de información estadística conforme las siguientes categorías: Por estado: determinará la totalidad de reportes de acuerdo al estado actual en el que se encuentren. Por código de cierre: será útil para consultar el número total de reportes cerrados ya sea por la Mesa de Servicios o un grupo de soporte especialista. Por grupo de soporte: permitirá conocer y dar continuidad a los reportes asignados a los diferentes grupos de soporte. El criterio de búsqueda de reportes estará basado en un rango de fechas que delimiten el periodo en el que se desee conocer la información estadística. Módulo de reportes donde se hará el registro de todas las llamadas que reciba el personal de la Mesa de Servicios con la finalidad de clasificarlas en incidentes o solicitudes. Cuando se realice una apertura de reporte el sistema tendrá que: Mostrar los datos de usuario al realizar la apertura de un reporte. Establecer la categoría del reporte o solicitud (software, hardware, otros -telefonía, impresiones, redes, información-). Priorización de los reportes en base a la urgencia e impacto. Escalamiento de los reportes a las diferentes áreas de soporte. El sistema sólo contemplará los dos primeros niveles de soporte74 Capítulo 4: Análisis y Diseño de Reports System. Permitir cambios sobre los reportes generados cuando así se requiera. Registrar comentarios de seguimiento (aplicable solo para el estado: Pendiente y Cancelado). Actualizar estados (abierto, asignado, en proceso, resuelto, cerrado, pendiente / cancelado). 4.3 DIAGRAMAS UML. En esta sección de la tesis se presentan los diagramas UML que serán la base para el desarrollo e implementación de la aplicación Reports System. Es importante hacer notar que de manera general para el desarrollo de software no es necesario utilizar todos los tipos de diagramas UML sino solamente los requeridos. En el presente trabajo de tesis únicamente se utilizarán los diagramas de casos de uso y los de actividades puesto que facilitan y permiten una mayor comprensión del análisis, diseño e implementación del sistema DIAGRAMAS DE CASO DE USO. Los diagramas de caso de uso 29 representan de forma gráfica las características principales de cada una de las secciones de los módulos descritos en la sección 4.2.1, a continuación se muestran los diagramas realizados para tal fin. Reconocimiento del perfil de usuario (acceso al sistema). 30 Usuario Entrar <<incluir>> Reconocer perfil de usuario Cuando un usuario ingresa el sistema es necesario que se conozca su perfil (administrador, de primer o segundo nivel) lo que se hace de manera interna. 29 Los casos presentados en esta sección son a alto nivel ya que no representan a detalle la funcionalidad del sistema, ésta se explica en el manual de usuario. 30 El caso de uso Reconocer perfil de usuario será detallado en un diagrama de actividades en la siguiente sección75 Capítulo 4: Análisis y Diseño de Reports System. Módulo de Herramientas. Diagrama de caso de uso de Altas, Bajas y Cambios de personal de la Mesa de Servicios y administración o Carga, Creación y Consulta de documentos en la KDB (CCC). Dar de alta, baja o cambios (ABC). Administrador de la Mesa de Servicios * ABC del personal de la Mesa de Servicios. <<incluir>> Entrar * Administración o CCC de la KDB <<incluir>> El Administrador es el único rol con privilegios para la carga de documentos en la KDB. Diagrama de caso de uso para ABC de usuarios de la organización, administración de activos así como la creación y consulta de documentos en la KDB. Administrador de la Mesa de Servicios * ABC de usuarios de la organización <<incluir>> * * * * Administrar activos (CMDB). <<incluir>> Entrar <<incluir>> * CC de KDB El administrador de la Mesa de Servicios es una generalización de un agente, por lo que tambien puede realizar las funciones de éste76 Capítulo 4: Análisis y Diseño de Reports System. Módulo de Reportes. Diagrama de caso de uso de gestión de incidencias: Creación, Actualización y Consulta de reportes (CAC). En este módulo es empleado por los tres perfiles tal y como se describe en los siguientes diagramas de caso de uso: Administrador de la Mesa de Servicios Agente de la Mesa de Servicio. * * Admisnitración de Reportes (CAC) <<incluir>> Entrar El administrador de Reports System es una generalización de un Agente de la Mesa de Servicios, por lo tanto tambien puede realizar las actividades de perfil (CAC). * Actualización de Reportes <<incluir>> * * El Ingeniero en Sitio únicamente actualiza y consulta reportes. * Consulta de Reportes Módulo de Estadísticas. El diagrama de caso de usos indica qué tipo de perfil puede realizar la generación de reportes estadísticos (por estado, código de cierre o grupo de soporte asignado): Administrador de la Mesa de Servicios * * Generar reportes estadísticos <<incluir>> Entrar Solamente el Administrador y Analistas pueden efectuar las acciones de generación de reportes77 Capítulo 4: Análisis y Diseño de Reports System DIAGRAMA DE ACTIVIDADES. En UML, un diagrama de actividades es una secuencia de acciones que representan la realización de operaciones a seguir desde un punto de inicio hasta un punto final detallando las rutas de decisiones y/o procesamiento paralelo existentes. [18] Estos diagramas están asociados a la implementación de un caso de uso teniendo en cuenta que los casos de uso se centran en la interacción entre el actor y el sistema y no en el procesamiento interno del sistema, por lo tanto aparece la necesidad de utilizar este tipo de diagrama para evitar que la documentación de las actividades que realiza el sistema no esté limitado al texto informal de los casos de uso. De esta forma, un caso de uso puede estar acompañado por 0, 1 ó más diagramas de actividades. [19] En este apartado, se ha diseñado un diagrama de actividades general que contiene las acciones descritas en los casos de usos de la sección anterior (ingreso al sistema mediante validación, acciones específicas dependiendo del perfil del usuario así como el cierre de sesión):78 Capítulo 4: Análisis y Diseño de Reports System. Ingresar al Sistema E [no aceptado] [aceptado] Reconoce perfil [Administrador] [Ingeniero en Sitio] A Gestionar ABC de personal [Analista] B Administrar estadísticas Gestionar ABC usuarios Gestionar activos C Gestionar KDB D Cargar documentos Consultar documentos Crear documentos D C Administrar reportes D Crear reportes A [ Sí ] B Cerrar sesión E Editar reportes Consultar documentos [ No ] D79 Capítulo 4: Análisis y Diseño de Reports System. 4.4 DISEÑO DE LA BASE DE DATOS ANÁLISIS, DIAGRAMA ENTIDAD RELACIÓN Y DICCIONARIO DE DATOS. La base de datos que gestionará el sistema Reports System está constituida por 7 tablas interrelacionadas cuya estructura se describe a continuación: Diagrama Entidad Relación. Diccionario de datos. Tabla TUSUARIO Se ha construido para almacenar los datos de los usuarios que comprenden tanto los de la organización a la que se le brindan los servicios TI como del personal que administra el sistema de la Mesa de Servicios (primer nivel) y personal de segundo nivel (los Ingenieros en Sitio): -78-80 Capítulo 4: Análisis y Diseño de Reports System. CURP TUSUARIO Varchar (18) not null primary key Clave primaria de la tabla que identifica inequívocamente al usuario. NOMBRE Varchar (100) not null Nombre completo del usuario, incluye apellidos. PUESTO Varchar (30) not null Posición desempeñada por el usuario. UBICACION Varchar (60) not null Especifica la ubicación física del usuario en la empresa. TELEFONO Varchar (17) not null Número telefónico del usuario en la empresa. EXTENSION Varchar (4) null Cuando exista, indica la extensión en la que se puede contactar al usuario. CORREO Varchar (80) not null Correo electrónico del usuario, proporcionado por la empresa. TIPOUSUARIO Enum not null Identificará si el usuario trabaja en la organización ( Externo ) o forma parte de del personal de la Mesa de Servicios ( Interno ). Tabla TTIPOACTIVO Permitirá identificar fácilmente el tipo de activo al que se haga referencia, que solamente será de alguno de los tres tipos que Reports System maneja (software, hardware y otro): IDTIPO TTIPOACTIVO Integer not null primary key Identificador único para un activo (1 para hardware, 2 para software y 3 para otro tipo) TIPOACTIVO Enum not null Solamente será Hardware, Software u Otro. -79-81 Capítulo 4: Análisis y Diseño de Reports System. Tabla TPERSONAL Administra la información de aquellos usuarios que operen Reports System y por ende son los que tienen acceso al sistema, incluye al Administrador, al personal de primer nivel (Analistas) y de segundo nivel (Ingenieros en Sitio): IDPERSONAL CONTRASENA CURP (FK) TPERSONAL Varchar (15) not null primary Key Varchar (13) not null unique Varchar (18) not null foreign key Clave que se empleará para que el personal ingrese al sistema de la Mesa de Servicios. Asignada por el Administrador a cada usuario del sistema. Permitirá obtener la información de usuario de cada individuo. Hereda de la tabla TUSUARIO el campo CURP, lo que la hace una llave secundaria. ROL Enum not null Identificará la categoría del personal: Administrador ( Admin ), primer nivel ( Pn para Analistas) o segundo nivel ( Sn para los Ingenieros en Sitio). Tabla TACTIVO. Esta tabla contendrá la información de los diferentes CI s que están en la organización. SERIAL TACTIVO Varchar (30) not null primary key -80- Corresponde con el número de serie de cada CI. MARCA Varchar (20) not null Marca del CI. MODELO Varchar (20) not null Representa el modelo al que pertenece cada CI. IDTIPO CURP Integer not null foreign key Varchar (18) not null foreign Key Se hereda de la tabla TTIPOACTIVO en el campo IDTIPO lo que la hace una llave secundaria. Hereda de la tabla TUSUARIO en su campo CURP, por lo que es llave secundaria.82 Capítulo 4: Análisis y Diseño de Reports System. DESCRIPCION Varchar (500) not null. Este campo servirá para describir el activo, dependiendo de las características que tenga el mismo. FECHAASIGNACION Datetime not null. En este campo se ingresa la fecha en el que activo ha quedado a resguardo de un usuario. Tabla TKDB Se ha creado con la finalidad de llevar un control de los documentos que integran la KDB que maneja el sistema: IDDOCUMENTO TKDB Integer not null primary key auto_increment -81- Identificador del documento cargado por el Administrador. NOMBRE Varchar (60) not null Nombre del documento, no incluye la extensión que de manera predeterminada es.pdf. FECHACREACION Datetime not null Este campo indica la fecha en la que se ha generado un documento. IDTIPO Integer not null foreign key Representa el identificador del tipo de activo al que se puede aplicar la solución descrita en el documento. Hereda el campo IDTIPO de la tabla TTIPOACTIVO, es una llave secundaria. CONTENIDO Varchar (5000) not null Este campo sirve para ingresar el contenido del documento. Tabla TCATALOGOSERVICIO Almacena la información referente a la categoría general de servicios y el tiempo SLA indicados en los catálogos de servicio. IDSERVICIO TIPOSERVICIO TCATALOGOSERVICIO Integer primary key not null. Enum primary key not null Identificador para cada uno de los servicios que figuran en el portafolio de servicios. Determina si el servicio es un Incidente o Requerimiento. SERVICIO Varchar (100) not null Categoría general83 Capítulo 4: Análisis y Diseño de Reports System. contemplada en el portafolio de servicios. TIEMPOSLA Time not null El tiempo máximo en el que debe quedar solucionado el incidente o solicitud reportada. Tabla TREPORTE Contiene la información que permitirá generar tanto los reportes del módulo de estadísticas así como efectuar la administración de incidentes y solicitudes reportados: IDREPORTE TIPOSERVICIO TREPORTE Integer not null primary key auto_increment Enum not null foreign key -82- Es el identificador del reporte generado dentro del sistema. Identificador del servicio contemplado en el portafolio de servicios. Hereda del campo TIPOSERVICIO de la tabla TCATALOGOSERVICIO y por ello es una llave foránea. DESCRIPCION Varchar (500) not null Especifica la falla o petición que está reportando el usuario. IDSERVICIO Integer not null foreign key Identificador del servicio contemplado en el portafolio de servicios. Hereda del campo IDSERVICIO de la tabla TCATALOGOSERVICIO y por ello es una llave foránea. FECHACREACION Datetime not null Indica tanto la fecha como la hora en el que el reporte fue creado en el sistema. FECHASOLUCION Datetime null Representa la fecha y hora de solución del reporte. Es nulo porque al levantar el reporte no se cuenta con ella. ESTADO Enum not null default Abierto Indica el estado en el que se encuentra el incidente o solicitud en el sistema: Abierto, Asignado, En proceso, Resuelto, Pendiente o Cancelado. GRUPOSOPORTE Enum not null Este campo indicará el84 Capítulo 4: Análisis y Diseño de Reports System. grupo de soporte que atenderá el incidente o requerimiento reportado por un usuario: Administradores DA, Ingenieria en Sitio, Mesa de Servicios y Soporte Activos. CODIGOCIERE Enum null El campo indica si el incidente o solicitud ha sido resuelto por el personal de la Mesa de Servicios o por personal de segundo nivel: Resuelto en Mesa de Servicios o Resuelto especialista, respectivamente. PRIORIDAD Enum not null Contempla las prioridades manejadas por el sistema: Critica, Alta, Media, Baja y Minima. IDPERSONAL CURP Varchar (15) not null foreign key Varchar (18) not null foreign key Hereda el campo IDPERSONAL de la tabla TPERSONAL, lo que permitirá conocer el nombre de la persona que generó el reporte. Es llave secundaria. Hereda el campo CURP de la tabla TUSUARIO que se empleará para determinar los datos del usuario final (al que se le brinda el servicio). Es una llave foránea. SOLUCION Varchar (500) null Describe la solución aplicada al incidente o requerimiento realizado por el usuario. COMENTARIO Varchar (500) null Se emplea para documentar actividades realizadas en el seguimiento del incidente o solicitud. -83-85 Capítulo 5: Implementación y pruebas de Reports System. CAPÍTULO 5: IMPLEMENTACIÓN Y PRUEBAS DE REPORTS SYSTEM86 Capítulo 5: Implementación y pruebas de Reports System. 5.1 IMPLEMENTACIÓN DE REPORTS SYSTEM. En esta sección se muestran las interfaces que integran a Reports System desde su ingreso, módulos y sus apartados correspondientes INTERFAZ DE INGRESO A REPORTS SYSTEM. Presenta el formulario de captura de datos, Usuario y Contraseña, con la finalidad de autenticar a los usuarios para el uso del sistema. 5.1 Ingreso a Reports System87 Capítulo 5: Implementación y pruebas de Reports System INTERFAZ DE MÓDULOS. Para el acceso a los módulos principales de Reports System, se considera el perfil que tiene el usuario y dependiendo de éste se muestra a cuáles de ellos tiene acceso: 5.2 Módulos de Reports System88 Capítulo 5: Implementación y pruebas de Reports System INTERFAZ DE MÓDULO DE HERRAMIENTAS. En este módulo se permite la gestión de los usuarios de la organización, personal del sistema, administración activos y KDB. Sólo ingresan los perfiles Administrador y Analista y cada una de las acciones está delimitada por los privilegios que se tienen. 5.3 Módulo de Herramientas89 Capítulo 5: Implementación y pruebas de Reports System INTERFAZ DE MÓDULO ESTADÍSTICAS. Aquí se lleva a cabo la obtención de reportes estadísticos que permiten conocer la cantidad de incidentes y requerimientos registrados en la aplicación, al igual que en el módulo anterior este apartado está restringido por el perfil del usuario. 5.4 Módulo de Estadísticas90 Capítulo 5: Implementación y pruebas de Reports System INTERFAZ DE MÓDULO REPORTES. En esta sección se generarán los reportes de los servicios solicitados, también podrán ser actualizados y consultados. Cabe mencionar que la creación de reportes está habilitada para el Administrador y los Analistas únicamente. 5.2 PRUEBAS DE REPORTS SYSTEM. 5.5 Módulo de Reportes. Con la premisa de que Reports System no falle, es decir de que funcione de acuerdo a sus especificaciones, se procede a realizar esta fase en donde cada uno de los módulos desarrollados serán probados por separado tomando en cuenta la metodología RUP para detectar cualquier anomalía antes de que el sistema se encuentre en producción. Para evaluar el desempeño del sistema, en esta etapa se efectuarán únicamente los siguientes niveles de prueba 31 : 31 Existe otro nivel de pruebas llamadas de aceptación, pruebas de caja negra que requieren de la participación de usuarios finales. Sin embargo no figuran como parte del proceso de pruebas de Reports System puesto que aún no se ha contemplado la implantación del mismo en una organización específica91 Capítulo 5: Implementación y pruebas de Reports System. Funcional: prueba desde el punto de vista de los requerimientos y los diagramas UML empleados. Contempla formatos, validación y verificación de ingreso de datos requeridos en los formularios, validación de perfiles de usuario y conjunto de caracteres en formato UTF-8 tanto en el servidor Web como en el gestor de la base de datos. De Integración: prueba de interfaces que se enfocan a determinar el correcto funcionamiento del conjunto de operaciones de cada sub-módulo, es decir que la información ingresada, modificada y consultada sea correcta, coherente y libre de alteraciones PRUEBAS FUNCIONALES. El listado de pruebas comprende desde el ingreso al sistema, reconocimiento de perfil así como la verificación y validación de los datos que son ingresados en cada uno de los apartados que lo integran. Ingreso al sistema: 5.6 Acceso a Reports System92 Capítulo 5: Implementación y pruebas de Reports System. 5.7 Acceso denegado a Reports System. Reconocimiento de perfiles 5.8 Pantalla inicial para los perfiles de Administrador y Analista93 Capítulo 5: Implementación y pruebas de Reports System. 5.9 Sub-módulos de la sección de Herramientas manejados por el perfil de Administrador Sub-módulos de la sección de Herramientas manejados por el perfil de Analista94 Capítulo 5: Implementación y pruebas de Reports System Pantalla inicial para el perfil de Ingeniero en Sitio. Verificación y validación de datos. En la codificación de los archivos de instrucciones que integran al sistema se emplearon funciones propias de los lenguajes de programación empleados así como expresiones regulares para determinar que los campos de ingreso/modificación de información tuvieran el formato y longitud establecidos y que aquellos que fueran obligatorios no se mandaran al servidor sin contenido alguno. Dado que el proceso de verificación y validación es idéntico en todos los apartados del sistema, sólo se ejemplificará el proceso de alta de un usuario por el Administrador:95 Capítulo 5: Implementación y pruebas de Reports System Validación de formato en los datos ingresados Verificación de campos requeridos96 Capítulo 5: Implementación y pruebas de Reports System. Reconocimiento de caracteres en formato UT Ingreso de información con caracteres especiales Almacenamiento de la información en la base de datos Consulta de la información recién ingresada en el sistema97 Capítulo 5: Implementación y pruebas de Reports System PRUEBAS DE INTEGRACIÓN. Las pruebas de integración de Reports System se centraron en los módulos Herramientas y Reportes con la finalidad de verificar la información ingresada en cada interfaz. Operaciones realizadas en la sección de Herramientas. Alta del usuario Jorge Cruz Jiménez Datos del usuario a dar de alta en el sistema Confirmación de alta realizada satisfactoriamente98 Capítulo 5: Implementación y pruebas de Reports System. Consulta de información del usuario recién ingresado: esta operación se efectúa realizando búsquedas cuyo criterio se basa en coincidencias de Nombre, CURP o ambos con los registros almacenados en la base de datos, el resultado mostrado es el conjunto de registros que coinciden con el patrón de búsqueda introducido: 5.18 Búsqueda de usuario mediante el campo Nombre Consulta de información del usuario99 Capítulo 5: Implementación y pruebas de Reports System. Asignación de un activo TI a un usuario: para ello es necesario introducir el serial, marca, modelo, tipo de activo, su descripción y la CURP del usuario que lo resguarda: 5.20 Ingreso de datos para alta de activo Alta de activo realizada adecuadamente100 Capítulo 5: Implementación y pruebas de Reports System. Operaciones realizadas en la sección de Reportes. Para la creación de un reporte ya sea un incidente o requerimiento se requiere introducir el nombre del usuario, CURP o ambos. Así mismo el Analista debe indicar el tipo de reporte a generar y el sistema buscará los usuarios cuya información coincida con los datos proporcionados: 5.22 Búsqueda de usuario para apertura de reporte Selección de usuario para la apertura del reporte101 Capítulo 5: Implementación y pruebas de Reports System Ingreso de la información requerida para generación de reporte Reporte generado exitosamente en Reports System. En base al reporte generado anteriormente, se procede a validar el ciclo de vida de la falla o requerimiento hecho; esta acción se realiza en el apartado Actualización de Reportes especificando el número de reporte o el nombre del usuario afectado para que el sistema recupere el registro de la base de datos según el patrón de búsqueda introducido:102 Capítulo 5: Implementación y pruebas de Reports System Búsqueda del reporte que será actualizado. a) Abierto Asignado Actualización de reportes de estado Abierto a Asignado103 Capítulo 5: Implementación y pruebas de Reports System. b) Asignado En proceso Actualización de reportes de estado Asignado a En proceso c) En proceso Resuelto Actualización de reportes de estado En proceso a Resuelto104 Capítulo 5: Implementación y pruebas de Reports System. d) Resuelto Cerrado Actualización de reportes de estado Resuelto a Cerrado. Dentro del apartado Consulta de Reportes se puede verificar la información de todos los incidentes y requerimientos registrados en el sistema; para realizar la consulta se requiere conocer el número de reporte a consultar o en su defecto el nombre del usuario final que lo solicitó: 5.31 Consulta de reportes105 Capítulo 5: Implementación y pruebas de Reports System Recuperación del reporte indicado de la base de datos para efectos de consulta106 CAPÍTULO 6: SEGURIDAD107 Capítulo 6: Seguridad. 6.1 SEGURIDAD EN LOS SISTEMAS INFORMÁTICOS. La seguridad en términos informáticos y simples asegura que los sistemas, servicios y recursos de cómputo de una organización estén disponibles, es decir que no se encuentren alterados o dañados por factores externos. En un sentido más estricto, la seguridad se define como el conjunto de reglas técnicas, actividades que están destinadas a prevenir, proteger y resguardar lo que es considerado como susceptible de pérdida, daño o incluso robo. La necesidad de seguridad es un concepto que ha crecido de manera natural, basado en la idea de que la información es un recurso crítico y clave de cualquier empresa sin embargo es necesario acotar que no hay un sistema, servicio o recurso que esté totalmente seguro. La seguridad es responsabilidad de todos aquellos que están en contacto con las herramientas informáticas, se compone de tres aspectos interrelacionados, los cuales son: Físicos: hacen referencia a las instalaciones de cómputo, al equipo y software, a través de elementos físicos los cuales incluyen: Un acceso controlado a salas de cómputo. Monitoreo de las instalaciones. Respaldos frecuentes de los datos y almacenamiento correcto de éstos en medios y áreas confiables. Las decisiones referentes a la seguridad física deben realizarse en el momento mismo en que se planeen las instalaciones y la adquisición de equipo de cómputo. Lógicos: este aspecto hace énfasis a los controles establecidos dentro del software. Los controles lógicos son conocidos por la mayoría de los usuarios ya que permiten que el usuario ingrese al sistema o a una sección particular de éste, ejemplos de éstos son las contraseñas o códigos de autorización. No obstante, los controles lógicos son desdeñados en muchas organizaciones ya que en muchas ocasiones los empleados están cansados de ellos y llegan a compartirlos con personas que no están autorizadas para el uso de algún servicio o bien los anotan en papel causando así un nivel alto de vulnerabilidad en la seguridad. Éticos: los controles físicos y lógicos son relevantes no obstante para el éxito de los esfuerzos en seguridad, también es necesario establecer un código de ética que regule la conducta de los usuarios concerniente al uso de las TI108 Capítulo 6: Seguridad. 6.2 SEGURIDAD EN LOS DATOS. Los datos son los activos más importantes dentro de una organización y esto conlleva a la implementación de medidas de control y administración de los mismos que eviten poner en peligro su definición, existencia, consistencia e integridad, independientemente de la persona que los accede. [20] Las operaciones realizadas con los datos incluyen las transacciones de envío, recepción, acceso, actualización y borrado por medio de usuarios de equipos de cómputo y tareas programadas en las bases de datos de la organización. Las preocupaciones más habituales relacionadas con la seguridad son: [21] Qué tan valiosos son los datos? Qué datos deben asegurarse? Cuánto costarán los accesos ilegales? Cuáles son las implicaciones de los cambios o destrucciones de datos? Qué medidas de seguridad afectan el funcionamiento de la base de datos? Cómo pueden ocurrir los accesos no autorizados? Los mecanismos contemplados para la seguridad de los datos estructuran, controlan el acceso y la actualización de los mismos con la premisa de no alterarlos lo que implica enfocar las acciones de administración de seguridad en las bases de datos que los resguardan SEGURIDAD EN LAS BASES DE DATOS. La seguridad en las bases de datos es el factor más importante en el proceso de implementación de soluciones que trabajen con información sensible y su aseguramiento debe estar orientado a cumplir los siguientes objetivos: Acceso: la disponibilidad de los datos es restringida a los usuarios en base a los privilegios que les son asignados, determinando el nivel de acceso y operación que se les autoriza (con derechos a crear, borrar y modificar objetos). Esta es una tarea a cargo del administrador de la base de datos. Disponibilidad: es la condición donde los recursos de información pueden ser accedidos por los usuarios autorizados en cualquier momento lo que conlleva que el sistema y las bases de datos se encuentren siempre en línea y operando de forma adecuada para no afectar los objetivos de la empresa. La disponibilidad de los datos almacenados permite optimizar el Gestor de la Base de Datos109 Capítulo 6: Seguridad. Confidencialidad: referente a la protección de los datos de su revelación al definir qué usuarios pueden ver ciertos datos y ocultando aquellos que no les corresponden. Integridad: abarca las medidas necesarias para garantizar la validez de los datos, es decir, trata de protegerlos ante fallas en hardware, cambios no autorizados o cualquier otra circunstancia capaz de corromperlos. Respaldo y recuperación integrados por mecanismos que permiten la recuperación de los datos en caso de ocurrir fallas en el sistema gestor de la base de datos FACTORES EN LA SEGURIDAD DE BASES DE DATOS. 32 Con la finalidad de que las bases de datos estén protegidas de las amenazas que puedan alterar los datos que alojan, es necesario considerar los aspectos físicos y lógicos partícipes en el manejo de la información: Red: referente a los acceso remotos a la base de datos. Sistema Operativo del servidor que en el que se encuentra el gestor de la base de datos. Aplicaciones que manipulan los datos almacenados. El mismo gestor de la base de datos que los almacena y recupera FASES EN LA SEGURIDAD DE LAS BASES DE DATOS. El proceso de seguridad en las bases de datos se compone de una serie de etapas que van desde el diseño, la implementación hasta el mantenimiento de las mismas: Prevención: hace referencia a la administración de cuentas de usuario para que se efectúen debidamente las operaciones acordes los privilegios asignados (permisos asociados a las actividades de SQL como SELECT, INSERT, DELETE, CREATE, DROP, etc.). En un sistema gestor de base de datos, la asignación de permisos se puede realizar directamente modificando las tablas correspondientes, a través de las herramientas graficas que provea o mediante cláusulas grant o revoke de SQL. 32 Los apartados y han sido extraídos de una publicación web que plantea temas referentes a la seguridad y las vulnerabilidades de los sistemas de Información. [22]110 Capítulo 6: Seguridad. Auditoría: es una revisión periódica de las bases de datos, cuentas de usuario y privilegios orientada a los siguientes puntos: Eliminación de datos inactivos. Restricción de privilegios al mínimo necesario. Optimización del acceso a las bases de datos mediante la restricción de IP s o la implementación de subredes. Establecimiento de parámetros de memoria, uso de índices, espacios, etc. Monitoreo, es una inspección de las bitácoras efectuada para la detección de situaciones como: Alcance de nivel máximo en los espacios de las distintas tablas. Consultas muy lentas. Errores del gestor de la base de datos. Intentos fallidos de usuarios. 6.3 SEGURIDAD EN EL SERVIDOR WEB. Un servidor web en una organización es un punto especialmente sensible a los problemas que podemos tener con la seguridad ya que representa un punto a través del cual se puede acceder a contenidos y datos de la empresa desde el exterior. La seguridad en los sistemas es uno de los aspectos más importantes que toda empresa debe considerar ya que no solamente se trata de tener los datos seguros sino también de prevenir todas aquellas cuestiones que afecten a los mismos sistemas y servicios prestados y que puedan hacer que el servidor web deje de funcionar de manera correcta lo cual finalmente representa pérdidas económicas para la organización. Por lo anterior, los responsables de la seguridad de los sistemas alojados en los servidores web deben realizar tareas de prevención, detección y recuperación de ataques111 Capítulo 6: Seguridad PREVENCIÓN DE ATAQUES. Par evitar que los sistemas web se vean comprometidos se deben tomar en cuenta las medidas que a continuación se describen: Mantenerse informado sobre novedades y alertas de seguridad. Actualizar tanto el sistema operativo como cualquier aplicación que se tenga instalada en el servidor. Hacer respaldos de seguridad frecuentemente para evitar la pérdida de datos importantes. Utilizar software legal que ofrezca soporte y garantía. Emplear contraseñas fuertes en todos los servicios para dificultar la suplantación de usuarios. Utilizar herramientas de seguridad (antivirus, anti espías) para proteger y reparar el servidor web frente a las amenazas. Creación de usuarios diferentes con los permisos mínimos necesarios para realizar las acciones permitidas DETECCIÓN DE ATAQUES. Para detectar si una aplicación web ha sufrido un ataque se recomienda realizar las siguientes acciones de verificación: Detectar si la aplicación web presenta apariencias, características, contenidos o acciones distintas o modificadas a las programadas así como la revisión de la lista de archivos del sitio en busca de cambios no deseados. Revisar la bitácora de conexiones al sitio web y sus peticiones para determinar las conexiones recibidas mediante HTTP. Comprobar si los permisos predefinidos han sufrido algún cambio sobre los sistemas web. Revisión del código fuente en busca de la posible detección de ataques más comunes como variación en código HTML, PHP, enlaces JavaScript maliciosos, la posible inyección de archivos js almacenados en el servidor. Modificación de las bases de datos, por ejemplo la inyección de código SQL que puede alterar el funcionamiento normal de una base de datos haciendo que se ejecute el código invasor en ella112 Capítulo 6: Seguridad. Detectar la presencia de nuevos archivos de tipo ejecutable que permitan que los atacantes manejen el sistema vía remota RECUPERACIÓN DE ATAQUES. En caso de que las medidas de seguridad establecidas hayan sido corrompidas, es decir, si se sufrió un ataque de seguridad es necesario efectuar actividades de recuperación orientadas a corregir la vía de acceso al servidor tales como: Mantener las aplicaciones web fuera de internet hasta corregir el problema. Contactar a la empresa que aloja al sitio web para notificar el incidente sufrido proporcionando información como dirección IP del sistema web, hora y día del ataque entre otros. Reemplazar el código dañado por copias de seguridad para que el sitio se encuentre disponible en el menor tiempo posible. También se sugiere el hacer respaldos de los archivos dañados para su análisis posterior y conocimiento de las causas. Ejecución de antivirus y anti espías en los equipos administrados para evitar el robo de credenciales. Cambio de contraseñas para evitar de nuevo el acceso al servidor y las conexiones a las bases de datos. Revisión de permisos asignados a usuarios y archivos así como el restablecimiento correcto de los mismos para evitar que puedan ser usados como vía de acceso. Actualización del software que se utiliza en el servidor a la versión más actual. Identificación de la IP o IP s que realizaron el ataque analizando las bitácoras de acceso al servidor teniendo en cuenta que esto no garantiza que la IP detectada sea del verdadero atacante puesto que las intrusiones pueden realizarse desde equipos comprometidos. 6.4 SEGURIDAD EN REPORTS SYSTEM. En base a lo anterior, es preciso hacer énfasis que la seguridad en Reports System se enfoca al empleo de controles lógicos, delegando la definición e implementación de las medidas físicas y éticas a la organización en la cual esta herramienta sea implantada para que se ajusten a sus necesidades113 Capítulo 6: Seguridad CONTROLES LÓGICOS EN REPORTS SYSTEM. Los controles lógicos implementados en esta herramienta son dos: Autenticación: el acceso y empleo del sistema está limitado al personal que cuente con un Usuario y Contraseña. 6.1 Acceso al sistema. Gestión de acciones mediante el uso de sesiones programadas en PHP: una vez que el usuario ha sido validado se procede a verificar internamente el puesto que tiene ya que es el parámetro que determina el perfil que le corresponde al usuario y a su vez éste delimita las acciones que se pueden realizar dentro del sistema. Los tres perfiles existentes en la herramienta son: Administrador: realiza todas las acciones en el sistema, es decir no tiene ninguna restricción en sus tres módulos. Analista: tiene acceso a los tres módulos, sin embrago en la sección de Herramientas sus acciones son restringidas. Ingeniero en Sitio: este perfil sólo hace uso de algunas actividades del módulo de Reportes. A continuación se observan las pantallas de módulos correspondientes cuando ingresa un usuario con perfil de Administrador y uno con el perfil de Ingeniero en Sitio:114 Capítulo 6: Seguridad. 6.2 Perfil Administrador. 6.3 Perfil Ingeniero en Sitio115 Capítulo 6: Seguridad SEGURIDAD EN LA BASE DE DATOS. El alcance de seguridad en la base de datos de Reports System contempla los siguientes aspectos: Objetivos: Controla el acceso mediante contraseñas que son codificadas mediante un método PHP que implementa la codificación base Acceso restringido. La integridad de los datos se asegura mediante validadores implementados con código JavaScript que examinan que los datos introducidos en los formularios sean los requeridos y que estén en el formato conforme se definió en el diccionario de la base de datos. 33 Es un esquema de codificación que se emplea para transferir bytes en forma codificada por Internet116 Capítulo 6: Seguridad. 6.5 Validación de datos ingresados. 6.6 Validación de datos obligatorios117 Capítulo 6: Seguridad. Reports System contempla el aspecto de confidencialidad de información puesto que en el módulo de Herramientas existe un apartado que gestiona la administración del personal que utiliza el sistema y es solamente empleado por el Administrador ningún otro perfil tiene privilegios para consultar, modificar, realizar altas o bajas de esta información. 6.7 El perfil de Administrador es el único que gestiona los datos del personal del sistema. Factores: El sistema cuenta con interfaces que aseguran el correcto manejo de la información para que esté acorde con el diccionario de datos. El código incluye configuración del formato UTF-8, funciones que validan el manejo de acentos y el ingreso de información mediante expresiones regulares. El gestor de la base de datos también ha sido configurado para manejar el formato de codificación UTF-8 y así el sistema muestre información sin inconvenientes por el uso de caracteres como acentos y la letra ñ118 Capítulo 6: Seguridad. 6.8 Configuración del gestor de la base de datos MYSQL con UTF-8. Los códigos de construcción de las tablas implementan las relaciones entre éstas conforme lo describe el diagrama entidad-relación, en específico asegura que las operaciones de actualización y borrado de información se vean replicadas de tablas padre a tablas hijo. 6.9 Código de construcción de tablas padre e hijo que regula la replicación de las operaciones actualización y borrado119 Capítulo 6: Seguridad. Fases: En la etapa de prevención, el diseño de esta aplicación contempló el desarrollo de códigos que identificaran el perfil del usuario para gestionar las operaciones SQL DELETE y UPDATE Gestión de operaciones SQL en base al perfil de usuario: en este caso un Analista no puede dar de baja al personal del sistema. Para fortalecer el nivel de seguridad de Reports System, se sugiere que la empresa en la cual sea implantado lleve a cabo las siguientes acciones: Asegurar la disponibilidad de datos en todo momento. Realizar el respaldo y recuperación de datos. Configurar la red y el sistema operativo del servidor para controlar el acceso y protección de los datos. Contar con las medidas de seguridad que garanticen la prevención, detección y recuperación de ataques120 CONCLUSIONES.121 Conclusiones. CONCLUSIONES Una vez finalizado el presente trabajo de tesis los resultados obtenidos se resumen en las conclusiones siguientes: Se logró desarrollar el sistema Reports System en base a la metodología ITIL utilizando los siguientes parámetros: Un portafolio de servicios para categorización de los reportes. Ciclos de vida específicos para incidentes y requerimientos. Criterios de prioridad determinados tanto por el impacto y la urgencia de las peticiones realizadas por los usuarios, así como el grado de afectación de la continuidad de los servicios de las TI. A través de las pruebas a las que se sometió el sistema, se ha verificado que éste cumple con la funcionalidad establecida: Integridad, almacenamiento ordenado y centralización de la información lo que se refleja en las pruebas realizadas y que está soportado por el diseño relacional de la base de datos implementada. Claridad en los procesos. Confidencialidad de la información y seguridad a través de la asignación de perfiles de usuario para el personal que utilizará la herramienta. Facilidad en la generación de reportes debido a que los datos solicitados para su apertura son mínimos y concisos. Seguimiento de indicadores de gestión en base a la disponibilidad de reportes estadísticos que permiten verificar la cantidad de reportes: Asignados a un determinado grupo de soporte. Que se encuentran en un determinado estado. Que han sido solucionados y aquellos que no cuentan con un código de cierre. Reports System fue diseñado con interfaces que permitirán referenciar la herramienta como intuitiva y fácil de emplear para los usuarios finales. Se garantiza un refuerzo seguro para la línea de soporte técnico implantada en la organización, ya que a través de Reports System se permitirá dar un seguimiento continuo, atención y solución oportunos a las peticiones hechas y las fallas reportadas, lo que finalmente facilitará una administración adecuada de las mismas así como un mejor uso de las TI alojadas en la organización122 ANEXOS.123 Anexos. ANEXO I Existen diferentes marcos de referencia de procesos de TI que pueden ser usados para administrar la entrega del servicio TI. Sin embargo, algunos marcos únicamente cubren aspectos específicos de TI como la seguridad y la administración de riesgos. No hay alguno que cubra todos los aspectos. Los marcos más comúnmente adoptados en el mercado para la administración de las TI son COBIT, etom e ITIL que son descritos a continuación. COBIT COBIT (Control Objectives for Information Systems and related Technology) es un marco de referencia empleado para gestionar y controlar los sistemas de información y tecnología, se orienta a todos los sectores de una organización desde la dirección, gerencia, administradores TI, auditores y usuarios. COBIT es un modelo de evaluación y monitoreo que enfatiza el control de negocios, la seguridad TI y que abarca controles específicos de TI desde una perspectiva de negocios, su adecuada implementación provee una herramienta automatizada para evaluar de manera ágil y consistente el cumplimiento de los objetivos. Está basado en la filosofía de que los recursos TI necesitan ser administrados por un conjunto de procesos naturalmente agrupados para proveer la información pertinente y confiable. COBIT, también referenciado como un conjunto de lineamientos y estándares internacionales, define un marco de referencia que categoriza los procesos de las unidades de los Sistemas de información en cuatro módulos principales: Planificación y organización. Adquisición e implantación. Soporte y servicios. Monitoreo. Estos módulos agrupan objetivos de control de alto nivel que cubren tanto los aspectos de información como de la tecnología que la respalda, además facilitan la generación y procesamiento de la información. etom. Acrónimo de Enhanced Telecommunication Operations Map, se trata de un marco de referencia desarrollado por la organización Telemanagement Forum TMG. Uno de los objetivos de etom es auxiliar en la automatización de información y servicios de comunicación para negocios y procesos operacionales al emplear su marco de referencia en todo la cadena de valor incluyendo, por ejemplo, los proveedores de servicios, clientes, distribuidores de software / hardware e integradores de sistemas. Posee información fundamental para el mundo de telecomunicaciones y pretende, entre otras cosas, estandarizar y dar estructura coherente a los procesos de una empresa de este giro, dividiéndolos en tres áreas:124 Anexos. EM (Enterprise Management): área de procesos de gestión empresarial, incluye los procesos de negocio básicos requeridos para que cualquier negocio funcione. Tiene interfaces con casi todos los otros procesos en la empresa ya sean operacionales, de producto o de infraestructura. Son considerados algunas veces funciones y/o procesos corporativos como la gestión financiera, los procesos de gestión de recursos humanos, etc. SIP (Strategy, Infraestructure and Product): incluye los procesos que desarrollan la estrategia, construyen la infraestructura y gestionan los productos. Para etom, la infraestructura se refiere a algo más que sólo la infraestructura de tecnología de información y recursos que soportan los productos y servicios, puesto que incluye la infraestructura requerida para soportar los procesos funcionales, como la gestión de las relaciones con el cliente (CRM, por sus siglas en inglés). Estos procesos dirigen y hacen posible los procesos de operaciones. OPS (Operations Proccess): es el núcleo de etom debido a que incluye todos los procesos que soportan las operaciones y la gestión del cliente, así como las posibles operaciones directas con él. El panorama operacional de etom también incluye la gestión de ventas y la gestión de las relaciones con el proveedor. etom también ha definido cuatro áreas funcionales las cuales son: Los procesos de mercado, producto y cliente que incluyen aquellos relacionados con la gestión de ventas y canales, gestión de mercadeo, gestión de productos y ofertas así como también la gestión de las relaciones con el cliente, el manejo de órdenes y problemas, la gestión de acuerdos de niveles de servicio y la facturación. Los procesos de servicios que gestionan el desarrollo, configuración y tarifación de éstos así como la gestión de problemas y análisis de calidad. Los procesos de recursos que cubren el desarrollo y la gestión de la infraestructura de la empresa ya sea relacionada con los productos y servicios o con el soporte de la empresa en sí. Los procesos del proveedor que cubren la interacción de la empresa con sus proveedores. Esto involucra tanto los procesos que gestionan la cadena de suministro (que soporta los productos y la infraestructura) como aquellos que soportan la interfaz de operaciones con sus proveedores. ITIL, etom y COBIT. El proveedor de servicios outsourcing de TI es, en parte, responsable del éxito del negocio del cliente. En realidad, la infraestructura de TI es la parte medular de cada negocio. La efectividad de TI es la efectividad del negocio. A continuación se presenta un cuadro comparativo de las principales características de los tres marcos de referencia de procesos de TI con la finalidad de definir cuál es el que mejor se ajusta como gestor de la entrega de servicios TI según las necesidades que se tengan:125 Anexos. etom COBIT ITIL Normatividad Marco de referencia que es soportado por el TeleManagement Forum (TMF). Marco de referencia soportado por ISACA (Information System Control Standard), una organización sin fines de lucro para el gobierno de TI. El organismo profesional que ayuda a conducir su desarrollo es el IT Service Management Forum (ITSMF). Contexto y objetivos. Marco de referencia normativo que es ampliamente usado en la industria de las telecomunicaciones. Su objetivo es garantizar que se empleen procesos comunes sin importar el tipo de servicio provisto: datos, internet, móviles, etc. Su principal función es ayudar a la compañía a mapear sus procesos de TI conforme al estándar de mejores prácticas de ISACA. Es un conjunto normativo de directrices utilizado en la administración de servicios de TI. Sus objetivos principales son: alinear los servicios TI con las necesidades actuales y futuras del negocio y sus clientes, mejorar la calidad de los servicios TI y reducir el costo de la provisión de servicios. Alcance Identifica las características comunes de los procesos empresariales requeridos entre servicios similares como son telefonía, datos, internet, móviles, etc. para proporcionar una administración de servicios de alta calidad. Su enfoque va dirigido a la entrega de servicios a clientes externos. Los procesos que integran a este marco de referencia contribuyen a obtener un completo gobierno de TI; al integrar mecanismos de auditoria de sistemas de información, COBIT favorece un mayor control financiero de la organización. Principalmente ofrece directrices en la implementación y la entrega continua en la administración de servicios incluyendo procesos comunes de planeación, roles y actividades con una referencia apropiada. Se enfoca en la provisión de servicios a clientes internos126 Anexos. Aceptación Esquema de Certificación. Ha sido adoptado como un estándar internacional UIT 34 en el sector de telecomunicaciones y principalmente empleado por los proveedores de servicios en la industria de la información, comunicación y tecnología. La certificación de etom se logra por medio del programa de conformidad de TMF; su certificación se enfoca en herramientas no sobre organizaciones o procesos. El perfil de las organizaciones que implementan COBIT son aquellas que cotizan en bolsa, organizaciones grandes que tienen auditorías externas, puesto que la estructura de COBIT permite que organización de TI esté organizada para que cumpla con todos los requisitos necesarios de las auditorias. Se logra por medio del examen COBIT 4.1 Foundation Course por parte de ISACA, avalando que se tienen los principios, elementos y aplicaciones recomendadas en COBIT a un nivel fundamental. Es conocido y utilizado como el mejor conjunto de mejores prácticas para la administración de TI a nivel mundial. Se basa en los requisitos que necesita un profesional para desarrollar eficazmente la gestión de servicios TI en una organización. [23] Existen tres niveles: 1.- Foundation Certificate. 2.- Practitioner Certificate. 3.- Manager Certificate. Expedidos por las fundaciones EXIN (Examinations Institute) e ISEB (Information Systems Examination Board). 34 UIT, acrónimo de Unión Internacional de Telecomunicaciones. Organismo de la ONU que regula las telecomunicaciones a nivel internacional entre las distintas administraciones y empresas operadoras127 Anexos. Considerando las diferencias, similitudes y haciendo hincapié en el contexto, objetivos y alcance de los tres marcos de referencia contemplados, se concluye que las prácticas de administración de servicios TI (ITIL) frecuentemente llegan a ser el mejor criterio de aceptación cuando las compañías delegan su infraestructura de TI crítica para el negocio a los proveedores de servicio. Lo anterior justifica que la implementación de Reports System se haga conforme las prácticas ITIL. ANEXO II. Catálogo de servicios. Como se ha mencionado anteriormente, un catálogo de servicios es un portafolio de los servicios TI. Para su obtención es necesario identificar y categorizar cada servicio que contará con soporte técnico, es decir se deben asociar las diferentes fallas que se pueden presentar en los servicios TI, para lograrlo se debe establecer una referencia o categoría principal y ésta a su vez debe contener subcategorías que logren especificar a detalle la falla o solicitud que está siendo realizada por el usuario. A continuación, se describirán las categorías principales y grupos de soporte que conformarán el catálogo de servicios de la aplicación Reports System (es necesario mencionar que dichas categorías son aplicables tanto para incidentes como para requerimientos). Categorías principales: Estaciones de trabajo (ET): una estación de trabajo es un equipo de cómputo utilizada por un usuario. Servicios de administración corporativa (SAC): son aquellos servicios que brindan funcionalidad especializada a los equipos de cómputo. Servicios de atención técnica (SAT): este tipo de servicios tiene como finalidad garantizar el buen funcionamiento de cualquier activo informático de la empresa. Grupos de soporte: Los grupos de soporte son las diferentes áreas que son asignadas para la atención y solución de los reportes. Para la implementación de esta herramienta Service Desk, los grupos que se proponen son los siguientes: Mesa de Servicios: es el grupo de soporte responsable de dar solución en primera instancia a las fallas que son reportadas por los usuarios, haciendo uso de las herramientas disponibles. En el sistema Reports System, la Mesa de Servicios está conformada por el Administrador y los Analistas. En caso de que la Mesa de Servicios no pueda solucionar la falla, deberá realizar un escalamiento. Ingeniería en Sitio: es el grupo de soporte conformado por técnicos, ingenieros y especialistas que se encargan de dar solución a las fallas que son delegadas por parte128 Anexos. de la Mesa de Servicios. Habitualmente tienen una carga de trabajo mayor que otras áreas por lo que su responsabilidad aumenta. Administradores Directorio Activo (DA): independientemente del tamaño de las empresas, en el área de informática debe existir un grupo de soporte que administre el directorio activo que conforma a la organización con la finalidad de llevar un control de las cuentas de usuarios, correo electrónico, contraseñas asignadas y diversas políticas 35. Soporte Activos: esta área se enfoca en llevar un control de los activos que son suministrados a la organización. Adicionalmente, es importante mencionar que el catálogo descrito en el presente anexo sólo contempla los servicios técnicos que serán tomados en cuenta en la implementación de Reports System, dejando el listado de especificaciones y la jerarquía de servicios pendientes puesto que estos puntos se establecerán cuando se celebre un contrato de implantación del sistema en alguna organización. 35 Una política es una restricción o configuración especial que tiene un determinado grupo de objetos en el directorio activo Mostrar más
-CAPÍTULO II- INFORMACIÓN Y DATOS Es usual que se interpreten los términos datos e información indistintamente, lo cual no es correcto, existiendo una importante diferencia entre ambos conceptos que detallaremos 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 EN INFORMÁTICA DE GESTIÓN PROYECTO FIN DE CARRERA AUDITORÍA PRÁCTICA DE BASES DE DATOS BAJO INFORMIX Autor: Mª Isabel Romero Más detalles Integración de la Gestión de Clientes en la Plataforma de Negocio de OdPe
Universidad Politécnica de Valencia Escuela Técnica Superior de Ingeniería Informática Integración de la Gestión de Clientes en la Plataforma de Negocio de OdPe Proyecto Final de Carrera Ingeniería Técnica Más detalles ANÁLISIS DE LOS SISTEMAS BUSINESS INTELLIGENCE Y SU APLICACIÓN PRÁCTICA EN LOS PROYECTOS SOFTWARE
ANÁLISIS DE LOS SISTEMAS BUSINESS INTELLIGENCE Y SU APLICACIÓN PRÁCTICA EN LOS PROYECTOS SOFTWARE PROYECTO FIN DE CARRERA Ingeniería Técnica en Informática de Gestión Autor Carmen Cámara Núñez Director Más detalles CÓMO ABORDAR UN PROYECTO DE BUSINESS INTELLIGENCE EN UNA EMPRESA U ORGANIZACIÓN. Leonel Alfonso Villamizar Gutiérrez
CÓMO ABORDAR UN PROYECTO DE BUSINESS INTELLIGENCE EN UNA EMPRESA U ORGANIZACIÓN Leonel Alfonso Villamizar Gutiérrez Proyecto de Grado para optar el título de Ingeniero de Sistemas Asesor(a) Gladys Aidé Más detalles Grupo B. Sistemas y Tecnologías de la información
Grupo B. Sistemas y Tecnologías de la información Tema 1. Tema 2. Tema 3. Tema 4. Tema 5. Tema 6. Tema 7. Tema 8. Tema 9. Sistemas de Información. Análisis y desarrollo de sistemas de información. Metodologías Más detalles UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) METODOLOGIA PARA ESTANDARIZAR EL MANEJO DE PROCESOS DE RECURSOS HUMANOS Y ADQUISICIONES EN PROYECTOS DENTRO DE UN SERVICE DESK DE SOPORTE TECNICO SUSTENTANTE: Más detalles Universidad Nacional Autónoma de México. Facultad de Ingeniería
Universidad Nacional Autónoma de México Facultad de Ingeniería Fundamentos de un ERP con administración eficiente y optimización técnica de los recursos. Tesis para obtener el título de: Ingeniero en computación Más detalles SISTEMA DE GESTIÓN DEL CALL-CENTER DE SERVICIO AL CLIENTE CARLOS ARTURO AGUILAR PIMENTEL. JHON ALEXANDER DÍAZ ROJAS
SISTEMA DE GESTIÓN DEL CALL-CENTER DE SERVICIO AL CLIENTE CARLOS ARTURO AGUILAR PIMENTEL. JHON ALEXANDER DÍAZ ROJAS CORPORACIÓN UNIVERSITARIA MINUTO DE DIOS FACULTAD DE INGENIERÍA DEPARTAMENTO DE INFORMÁTICA, Más detalles ESCUELA POLITÉCNICA NACIONAL
ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS ADMINISTRACIÓN DE UN CALL CENTER DE COBRANZA PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN INFORMÁTICA MENCIÓN SOFTWARE IRINA Más detalles SISTEMA WEB DE INTEGRACIÓN DE LA BANCA PÚBLICA EN VENEZUELA, BANCO BICENTENARIO BANCO UNIVERSAL, C.A. OPERACIONES REGISTRADAS POR TAQUILLA.
SISTEMA WEB DE INTEGRACIÓN DE LA BANCA PÚBLICA EN VENEZUELA, BANCO BICENTENARIO BANCO UNIVERSAL, C.A. OPERACIONES REGISTRADAS POR TAQUILLA. Trabajo Presentado como requisito parcial para optar al Grado Más detalles DESARROLLO DE UN APLICATIVO PARA MONITOREO DE RED JOHN ENRIQUE GUAYAZÁN ORTÍZ HENRY ALBERTO MACHADO SÁNCHEZ
UNIVERSIDAD DEL AZUAY FACULTAD DE CIENCIAS DE LA ADMINISTRACIÓN ESCUELA DE INGENIERIA DE SISTEMAS Planificación, Diseño y Aplicación de Bases de Datos Distribuidas utilizando la herramienta CASE GENEXUS. Más detalles MANUAL DE IMPLANTACIÓN
MANUAL DE IMPLANTACIÓN MANUAL DE IMPLANTACIÓN Introducción Objetivo del manual Alcance del manual Parte 01 Parte 02 Parte 03 Parte 01 Parte 02 Parte 03 Introducción El proyecto constituye, para la Consejería Más detalles APLICACIÓN DEL CONCEPTO DE CADENA DE VALOR EN ORGANIZACIONES PROVEE- DORAS DE SERVICIOS INFOR- MÁTICOS. Caso de estudio: Cooperativa
COMPENDIUM, NÚMERO 27. Diciembre, 2011. 5 nvestigación APLICACIÓN DEL CONCEPTO DE CADENA DE VALOR EN ORGANIZACIONES PROVEE- DORAS DE SERVICIOS INFOR- MÁTICOS. Caso de estudio: Cooperativa SERVINF Jorge Más detalles Manual: GESTIÓN DE INCIDENTES DE SEGURIDAD INFORMÁTICA
Proyecto AMPARO Manual: GESTIÓN DE INCIDENTES DE SEGURIDAD INFORMÁTICA AMÉRICA LATINA Y CARIBE Página 1 Consideraciones Iniciales El presente manual ha sido desarrollado en el marco de las actividades Más detalles PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ
PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN DATAMART PARA EL SOPORTE DE TOMA DE DECISIONES Y EVALUACIÓN DE LAS ESTRATEGIAS SANITARIAS Más detalles SISTEMAS DE INFORMACIÓN: ASPECTOS TÉCNICOS Y LEGALES
SISTEMAS DE INFORMACIÓN: ASPECTOS TÉCNICOS Y LEGALES SISTEMAS DE INFORMACIÓN: ASPECTOS TÉCNICOS Y LEGALES JOSÉ MANUEL RODRÍGUEZ RODRÍGUEZ MARÍA JOSÉ DAUREO CAMPILLO Almería, 2003 PROLOGO El objetivo Más detalles UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE UNA METODOLOGÍA PARA EL CIERRE DE PROYECTOS PARA LA EMPRESA ADT COSTA RICA
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE UNA METODOLOGÍA PARA EL CIERRE DE PROYECTOS PARA LA EMPRESA ADT COSTA RICA JORGE LUIS ARROYO CHAVES PROYECTO FINAL DE GRADUACION PRESENTADO Más detalles Mónica Alexandra Fernández Tufiño
Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación Más detalles DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA CARRERA DE INGENIERÍA EN ELECTRÓNICA Y TELECOMUNICACIONES TESIS PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y TELECOMUNICACIONES AUTOR: YESSENIA Más detalles OPERACIÓN DEL SISTEMA DE CONTROL ESCOLAR (SICE) DEL ÁREA DE SERVICIOS ESCOLARES DEL CEMSAD NICOLÁS FLORES. MONOGRAFÍA
UNIVERSIDAD AUTÓNOMA DEL ESTADO DE HIDALGO INSTITUTO DE CIENCIAS BÁSICAS E INGENIERÍA. LICENCIATURA EN COMPUTACIÓN OPERACIÓN DEL SISTEMA DE CONTROL ESCOLAR (SICE) DEL ÁREA DE SERVICIOS ESCOLARES DEL CEMSAD Más detalles INGENIERO EN SISTEMAS E INFORMATICA
ESCUELA POLITECNICA DEL EJÉRCITO DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA DE SISTEMAS E INFORMATICA ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN DATA MART PARA LA DIRECCIÓN FINANCIERA Más detalles Tema 10.- Evaluación, calidad y gestión de calidad total en Documentación
Tema 10.- Evaluación, calidad y gestión de calidad total en Documentación 1.- La evaluación. Conceptos generales. Indicadores En términos generales, se entiende por evaluación el proceso mediante el cual Más detalles Cuaderno de trabajo SENDOTU
Cuaderno de trabajo SENDOTU Abril 2010 3 DISEÑO DE PROYECTOS SOCIALES DESDE UNA PERSPECTIVA DE GÉNERO Fundación Peñascal y Federación Sartu (www.sendotu.org) CUADERNOS DE TRABAJO SENDOTU INTRODUCCIÓN Más detalles UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE UN PLAN PARA ADQUIRIR UNA SOLUCION TECNOLOGICA QUE PERMITA LA ADMINISTRACION Y MONITOREO DE LA RED DE CAJEROS AUTOMATICOS DEL BANCO POPULAR Más detalles Facultad de Ciencias Económicas y de Administración Universidad de la República CALL CENTERS. Estrategia para atención de clientes
Facultad de Ciencias Económicas y de Administración Universidad de la República CALL CENTERS Estrategia para atención de clientes Trabajo de Investigación Monográfica Carrera Contador Público Plan 1990 Más detalles BPM (GERENCIA DE PROCESOS DE NEGOCIO) Tomado del Libro BPM AUTORES: KIRAN GARIMELLA, MICHAEL LEES, BRUCE WILLIAMS. Sumario
BPM (GERENCIA DE PROCESOS DE NEGOCIO) Tomado del Libro BPM AUTORES: KIRAN GARIMELLA, MICHAEL LEES, BRUCE WILLIAMS Sumario Introducción 1 Capítulo 1: Definición de Business Process Management (BPM).. 5 Más detalles La Calidad. en los Servicios Públicos

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 
in fine