TESIS CAMBIOS FINAL v3dspace.utpl.edu.ec/bitstream/123456789/1701/3/Díaz Cueva Diana Rosa.pdf · y...

Implementación de un Help Desk en el GDS utilizando la metodología ITIL

I

CERTIFICACIÓN

Ing. Audrey Romero

DIRECTORA DE TESIS

Certifica:

Que el presente trabajo de investigación ha sido dirigido, supervisado y revisado en todas sus fases, constatando que cumple con los requisitos establecidos por la Escuela de Ciencias de la Computación, en consecuencia autoriza su presentación.

Loja, julio del 2008

Ing. Audrey Romero

DIRECTORA DE TESIS


II

CESION DE DERECHOS

Yo, Diana Rosa Díaz Cueva declaro ser autor del presente trabajo y eximo expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales.

Adicionalmente declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice: “Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la universidad”.


III

AUTORÍA

Los conceptos, ideas y opiniones expuestas en el presente proyecto de tesis, son de exclusiva responsabilidad de la autora.

La información de otros autores empleada en el presente trabajo de investigación está especificada en fuentes de referencia y apartados bibliográficos.

Diana Rosa Díaz Cueva


IV

AGRADECIMIENTO

Quiero agradecer a la Universidad Técnica Particular de Loja, al personal docente de la Escuela de Ciencias de la Computación los que supieron compartir sus conocimientos hasta lograr mi carrera profesional.

De manera especial mi profundo agradecimiento a mi directora de tesis Ing. Audrey Romero y mi codirectora Ing. María Paula Espinoza por su apoyo y asesoramiento en el desarrollo de este proyecto.

Además quiero agradecer al Grupo de Desarrollo de Software, a las personas que de una u otra manera contribuyeron para la realización y culminación de este proyecto de tesis.

LA AUTORA


V

DEDICATORIA

A Dios por ser mi fortaleza en mis momentos difíciles y permitirme culminar con éxito uno más de los retos en mi vida profesional.

A mis padres Luis y Ana quienes siempre me han dado su apoyo incondicional, por su sacrificio y entrega, les debo lo que soy, a mis hermanos Diego y Ulises a Alexandra que siempre ha estado conmigo en todo momento y a Miguel Alejandro quien es mi alegría.

Finalmente dedico este trabajo a todos mis amigos y familiares que estuvieron dándome su apoyo cuando lo necesitaba.

Diana


VI

PLANTEAMIENTO DEL PROBLEMA

La Universidad Técnica Particular de Loja, UTPL, es una institución ecuatoriana que brinda educación superior a más de 26.000 estudiantes a nivel local, nacional e internacional, de Modalidad Presencial y Modalidad Abierta y a Distancia, para ofrecer una educación de calidad, entre otros aspectos, requiere continuamente renovar, actualizar y/o mejorar sus procesos y recursos tecnológicos; por tanto, uno de los medios para conseguir sus objetivos es la inversión y aplicación de Servicios y Tecnologías de Información TI.

La UTPL cuenta con unidades dedicadas a la investigación, extensión y servicios a la sociedad, llamadas CITTES (Centros de Investigación y Transferencia de Tecnología); uno de los CITTES del área técnica es la UPSI (Unidad de Proyectos y Sistemas Informáticos), a su vez está conformada por equipos de trabajo como: Telecomunicaciones, Desarrollo de Software, Electricidad y Sistemas Electrónicos, Soporte e Investigación Tecnológica, Sistemas de Información Geográfica y Cursos Especializados.

El Grupo de Desarrollo de Software, área de la UPSI, tiene entre uno de sus objetivos la implementación y mantenimiento de Sistemas Informáticos; uno de los principales y de más alta trascendencia es el Sistema de Gestión Académica SYLLABUS, implementado a mediados del 2004. Actualmente es utilizado aproximadamente por 26.000 usuarios entre: secretarias de centros asociados y de carrera, centros extranjeros, departamento de contabilidad, profesores, estudiantes; el considerable número de usuarios, más la cobertura, servicios y procesos que cubre, genera una continua, grande y compleja tarea en el tema de soporte del sistema, especialmente en períodos de matrícula, ingreso de notas de modalidad abierta y clásica, registro de trabajos de modalidad abierta, entre otros, este proceso se vuelve tedioso por las frecuentes llamadas de los usuarios solicitando ayuda en cuanto a la operatividad del sistema.

A medida que se ha ido incrementando el número de usuarios también se ha incrementado el servicio de soporte al sistema, algunos de los inconvenientes suscitados se detallan:

• Hardware, software y redes: la pérdida de conexión a Internet en los equipos de los usuarios, impide su trabajo por cuanto la aplicación trabaja en web.

• El cliente web (Internet Explorer) que utiliza el usuario para conectarse a la aplicación no está actualizado, ya que la aplicación trabaja sobre la versión 6.0 o superior, el usuario desconoce configuración de las herramientas sobre las que opera el sistema.

• Restricción o falta de permisos de red para acceder al sistema.

• Infecciones de virus u otro software malicioso.


VII

Procesos críticos como:

• Congestión y/o sobrecarga en los servidores de aplicaciones y de base de datos que ofrecen el servicio; especialmente cuando coinciden algunos procesos críticos o de uso intensivo del sistema.

• Por el dinamismo y complejidad del negocio no se cuenta con el tiempo y los recursos necesarios para poder desarrollar y asegurar la calidad del sistema, por lo que: algunos usuarios son quienes detectan los errores e issues no detectados, lo que hace que la versión cargada mantenga problemas al ser utilizada, además por la omisión de algunas de las configuraciones necesarias en la aplicación, el usuario final se ve limitado al momento de utilizar la aplicación, por requerimientos urgentes de los usuarios se suben versiones en caliente, lo que provoca la falla en algunas funcionalidades y causa inconvenientes al utilizar la aplicación.

• Por errores y fallas en los sistemas informáticos con los que se relaciona el sistema académico se ven afectadas ciertas funcionalidades, lo que impide el trabajo de las personas que utilizan la aplicación.

Desconocimiento de funcionalidades y desorganización en el proceso:

• Desconocimiento por parte de los usuarios sobre el funcionamiento de algunas opciones del sistema, ya sea porque es la primera vez que utiliza la funcionalidad o por cambios en la misma.

• Falta de análisis por parte del usuario para determinar si el problema es causado por el sistema, el equipo o la herramienta sobre la que trabaja.

• Falta de agilidad en el proceso de soporte por no existir una base de conocimiento en la cual se vayan registrando todos los incidentes y las soluciones.

• Falta de disponibilidad en la resolución de problemas por parte de técnicos o desarrolladores, y que no pueden ser resueltos por el personal de soporte.

A medida que se han ido incrementando el soporte al usuario final se ve la necesidad de tener un grupo especializado para la atención de todos los incidentes presentados, el mismo que con ayuda de una herramienta realizará el registro de incidentes, lo que permitirá ir alimentando una base de conocimiento donde se vayan almacenando todas las soluciones respecto de los incidentes presentado y que sirvan como herramienta de ayuda al personal de soporte.

El Centro de Servicio será el punto de contacto definido específicamente para recoger los requerimientos de los usuarios y será responsable de atender cada incidente y darle el seguimiento necesario, hasta llegar a la solución del mismo.


VIII

OBJETIVOS DEL PROYECTO

Objetivo General:

Implementar un Centro de Soporte en el Grupo de Desarrollo de Software para brindar a los usuarios un servicio de calidad frente al Sistema de Gestión Académica utilizando la metodología ITIL.

Objetivos Específicos:

• Analizar la metodología ITIL en cuanto a procesos, recomendaciones, gestión de servicios de TI.

• Definir un proceso formal que permita mejorar la entrega del servicio a los usuarios finales para tener un mayor control de los requerimientos de soporte.

• Ofrecer un servicio de calidad al usuario, al menor costo posible y con el mayor aprovechamiento del recurso humano.

• Implementar procesos ITIL en la organización, de acuerdo a su estructura y necesidades.


IX

INDICE

CERTIFICACIÓN ................................................................................................................................................................. I

CESION DE DERECHOS ................................................................................................................................................... II

AUTORÍA ........................................................................................................................................................................... III

AGRADECIMIENTO ...........................................................................................................................................................IV

DEDICATORIA ....................................................................................................................................................................V

Objetivo General: .............................................................................................................................................................VIII

Objetivos Específicos: ......................................................................................................................................................VIII

1.1 Historia de ITIL .................................................................................................................. 2

1.2 EVOLUCION DE ITIL ........................................................................................................ 2

1.3 ESTRUCTURA DE ITIL .................................................................................................... 4

1.3.1 Objetivos: ......................................................................................................................................... 4

1.3.2 Filosofía de ITIL ................................................................................................................................ 4

1.4 Detalle de las Áreas que componen ITIL versión 2 .......................................................... 6

1.4.1 Planeación para implementar la Administración de Servicios (Planning to implement Service Management) ............................................................................................................................................... 6

1.4.2 Perspectiva de Negocios (The Business Perspective) ..................................................................... 7

1.4.3 Administración de servicios .............................................................................................................. 8

1.4.4 Administración de la Infraestructura de TIC (ICT Infrastructure Management) .............................. 18

1.4.5 Administración de la Seguridad (Security Management) ................................................................ 18

1.4.6 Administración de Aplicaciones (Application Management) ........................................................... 18

1.5 Certificaciones en la Metodología ITIL ............................................................................ 19

1.6 RESUMEN ...................................................................................................................... 20 Marco teórico fundamentos ITIL ........................................................................................................................................ 22

2.1 Centro de Servicio (Service Desk) .................................................................................. 22

2.1.1 Denominaciones del Centro de Atención al Usuario ...................................................................... 23

2.1.2 Tipos de Centros de Servicio ......................................................................................................... 23

2.1.3 Consideraciones para seleccionar el tipo de Centro de Servicio .................................................... 25

2.1.4 Funciones del Centro de Servicio ................................................................................................... 26

2.1.5 Métricas del Centro de Servicio ...................................................................................................... 28

2.1.6 Capacidades del Personal del Centro de Servicio ......................................................................... 28

2.1.7 Formas de reportar incidentes al Centro de Servicio ..................................................................... 29

2.1.8 Mecanismos de acceso al Centro de Servicio ................................................................................ 29

2.1.9 Beneficios del Centro de Servicio hacia la organización ................................................................ 30

2.1.10 Factores que influyen en la calidad del servicio ofrecido por el Centro de Servicio .................... 31

2.2 Gestión de Nivel de Servicio ........................................................................................... 32

2.2.1 Beneficios de la Gestión de Nivel de Servicio ................................................................................ 32


X

2.2.2 Proceso de la Gestión de Nivel de Servicio.................................................................................... 32

2.2.3 Acuerdo de Nivel de Servicio (SLA) ............................................................................................... 33

2.3 Gestión de Incidentes ..................................................................................................... 34

2.3.1 Objetivos de la Gestión de Incidentes ............................................................................................ 34

2.3.2 Beneficios de una correcta Gestión de incidentes. ......................................................................... 35

2.3.3 Clasificación del Incidente .............................................................................................................. 35

2.3.4 Escalado y Soporte ........................................................................................................................ 35

2.3.5 Proceso de la Gestión de Incidentes .............................................................................................. 36

2.4 Gestión de Problemas .................................................................................................... 39

2.4.1 Detalle del proceso de la gestión de problemas ............................................................................ 40

2.5 Gestión de Cambios ....................................................................................................... 41

2.5.1 Detalle del proceso de la gestión de Cambios ............................................................................... 42

2.6 Situación Actual en el GDS ............................................................................................. 43

2.6.1 Estructura del Grupo de Desarrollo de Software ............................................................................ 43

2.6.2 Inventario de usuarios .................................................................................................................... 45

2.6.3 Módulos con los que cuenta el SGA Syllabus ................................................................................ 46

2.6.4 Infraestructura utilizada en la operación del SGA Syllabus ............................................................ 49

2.6.5 Esquema de soporte para el proceso de matrículas ...................................................................... 50

2.6.6 Proceso actual para el manejo de incidentes en el GDS ............................................................... 51

2.6.7 Resumen de Incidentes .................................................................................................................. 54

2.7 Propuesta para implementar el Centro de Servicio en el GDS ........................................ 55

2.7.1 Definición del tipo de estructura del Centro de Servicio del GDS ................................................... 56

2.7.2 Desarrollo del SLA para el Centro de Servicio ............................................................................... 64

2.7.3 Propuesta para la gestión de Incidentes en el GDS ....................................................................... 67

2.7.4 Propuesta para la Gestión de Problemas ....................................................................................... 73

2.7.5 Propuesta para la Gestión de Cambios .......................................................................................... 75

2.8 Relación entre el Centro de Servicio, Gestión de Incidentes, Problemas y Cambios ...... 78

2.9 RESUMEN ...................................................................................................................... 79

3.1 Descripción de Herramientas de Help Desk .................................................................... 82

3.1.1 OneOrZero ..................................................................................................................................... 82

3.1.2 SysAidServer .................................................................................................................................. 84

3.1.3 ManageEngine ServiceDesk .......................................................................................................... 85

3.2 Comparación entre las herramientas .............................................................................. 86

3.3 Parametrización de la herramienta ................................................................................. 89

3.4 RESUMEN ...................................................................................................................... 89

4.1 Planificación del piloto .................................................................................................... 92

4.1.1 Objetivos ........................................................................................................................................ 92


XI

4.1.2 Alcance .......................................................................................................................................... 92

4.1.3 Requerimientos .............................................................................................................................. 94

4.2 Ejecución del plan de piloto ............................................................................................ 95

4.2.1 Identificación de usuarios ............................................................................................................... 96

4.2.2 Inicio de pruebas ............................................................................................................................ 96

4.3 Análisis de resultados ..................................................................................................... 98

4.3.1 En relación al proceso - herramienta .............................................................................................. 98

4.3.2 Métricas obtenidas de la herramienta en relación al proceso de gestión de incidentes llevado en el Centro de Servicio GDS .......................................................................................................................... 100

4.4 RESUMEN .................................................................................................................... 105 CONCLUSIONES ............................................................................................................................................................ 107

RECOMENDACIONES ................................................................................................................................................... 108

GLOSARIO DE TERMINOS ............................................................................................................................................ 109

BIBLIOGRAFIA: .............................................................................................................................................................. 111

ANEXO [A] Definición del SLA ........................................................................................................................................ 114

ANEXO [B] : ESQUEMA DE SOPORTE PARA EL PROCESO DE MATRÍCULAS PERÍODO DEL PERÍODO OCTURE 2005-FEBRERO 2006 DE LA MODALIDAD ABIERTA Y A DISTANCIA ....................................................................... 125

ANEXO [C]: INFORME DE MATRÍCULAS PERÍODOS OCTO7 – FEB 08 Y ABRIL-AGOSTO 2008 ............................ 130

ANEXO [D] Manual de Instalación de la herramienta ..................................................................................................... 139

ANEXO [E]: Manual de usuario de la herramienta para gestión de incidentes OneorZero ............................................ 142

ANEXO [F]: Manual del Administrador de la herramienta para gestión de incidentes OneorZero ................................. 153

ANEXO [G] Encuestas realizadas a los técnicos que utilizaron la herramienta OneOrZero para gestión de incidentes y Tabulación de Resultados ............................................................................................................................................... 165

ANEXO [H]: Anteproyecto de Tesis ................................................................................................................................ 171


XII

INDICE DE TABLAS

TABLA 1.1. ELEMENTOS DE LA VERSIÓN 2 INCLUIDOS EN LA VERSIÓN 3 DE ITIL ................................................. 4

TABLA 1.2. PUNTOS CLAVE A CONSIDERAR AL IMPLEMENTAR ITIL ......................................................................... 7

TABLA 1.3. DETALLE DEL PROCESO DE LA GESTIÓN DE NIVEL DE SERVICIO ........................................................ 9

TABLA 2.1. FUNCIONALIDADES DEL MÓDULO DE MATRÍCULA ................................................................................ 47

TABLA 2.2. FUNCIONALIDADES DEL MÓDULO DE GESTIÓN ACADÉMICA .............................................................. 47

TABLA 2.3. FUNCIONALIDADES DEL MÓDULO DE GESTIÓN FINANCIERA .............................................................. 48

TABLA 2.4. FUNCIONALIDADES DEL MÓDULO DE CONFIGURACIÓN ...................................................................... 48

TABLA 2.5. DETALLE DE LAS CATEGORÍAS DE SOPORTE DEFINIDAS .................................................................... 50

TABLA 2.6. ELEMENTOS DE EVALUACIÓN DEL DESEMPEÑO DE LOS TÉCNICOS ................................................. 62

TABLA 2.7. HORARIO DE PRESTACIÓN DE SERVICIO ................................................................................................ 65

TABLA 2.8. ASIGNACIÓN TIEMPOS DE SOLUCIÓN ..................................................................................................... 69

TABLA 2.9. TIPOS DE INCIDENTES FRECUENTES ...................................................................................................... 70

TABLA 2.10. DETALLE DEL PROCESO PARA LA GESTIÓN DE INCIDENTES ............................................................ 71

TABLA 2.11. TABLA DE NIVELES DE PRIORIDAD PARA REALIZAR CAMBIOS ......................................................... 77

TABLA 3.1. DETALLE DE LAS CARACTERÍSTICAS A EVALUAR PARA SELECCIÓN DE LA HERRAMIENTA .......... 86

TABLA 3.2. INDICADORES CUANTITATIVOS APLICADOS PARA LA SELECCIÓN DE LA HERRAMIENTA .............. 87

TABLA 3.3. CRITERIOS PARA SELECCIÓN DE LA HERRAMIENTA ........................................................................... 87

TABLA 3.4. ELEMENTOS DE CONFIGURACIÓN EN LA HERRAMIENTA .................................................................... 89

TABLA 4.1 PROCESO PARA LA GESTIÓN DE INCIDENTES ........................................................................................ 93

TABLA 4.2 FUNCIONALES DE LA HERRAMIENTA ONEORZERO................................................................................ 93

TABLA 4.3. PARTICIPANTES EN EL PILOTO - ROLES Y RESPONSABILIDADES .................................................... 94

TABLA 4.4. AGENDA DE TRABAJO ................................................................................................................................ 94

TABLA 4.5. RECURSOS HUMANOS, MATERIALES Y TÉCNICOS ............................................................................... 95

TABLA 4.6. TÉCNICOS PARA LA EJECUCIÓN DEL PLAN PILOTO .............................................................................. 96

TABLA 4.7. DETALLE DEL PROCESO DE LA GESTIÓN DE INCIDENTES .................................................................. 96

TABLA 4.8. DETALLE DE PRIORIDAD ............................................................................................................................ 97

TABLA 4.9. RELACIÓN HERRAMIENTA / PROCESO .................................................................................................... 97

TABLA 4.10. RANGO DE ACEPTACIÓN ......................................................................................................................... 98

TABLA 4.11. DETALLE DE PARTICIPANTES EN PLAN PILOTO ................................................................................... 98

TABLA 4.12. CRITERIOS CONSIDERADOS PARA DETERMINAR NIVEL DE SATISFACCIÓN .................................. 98

INDICE DE FIGURAS

FIGURA 1.1. ELEMENTOS BÁSICOS DE ITIL VERSIÓN 2 [ASSIRATI, 2002] ................................................................ 5

FIGURA 1.3. ELEMENTOS DE LA ADMINISTRACIÓN DE SERVICIOS .......................................................................... 8

FIGURA 1.4. PROCESO DE GESTIÓN DE NIVELES DE SERVICIO ............................................................................... 9

FIGURA 2.1. CENTRO SERVICIO LOCAL ...................................................................................................................... 23


XIII

FIGURA 2.2. CENTRO DE SERVICIO CENTRAL ............................................................................................................ 24

FIGURA 2.3. CENTRO DE SERVICIO VIRTUAL ............................................................................................................. 25

FIGURA 2.4. PROCESO DE GESTIÓN NIVEL DE SERVICIO ........................................................................................ 33

FIGURA 2.5. ELEMENTOS PARA DETERMINAR PRIORIDAD DE UN INCIDENTE ..................................................... 35

FIGURA 2.6. GESTIÓN DE INCIDENTES COMO PROCESO HORIZONTAL ................................................................ 36

FIGURA 2.7. PROCESO DE GESTIÓN DE INCIDENTES ............................................................................................... 37

FIGURA 2.8. PROCESO GESTIÓN DE PROBLEMAS .................................................................................................... 40

FIGURA 2.9. PROCESO GESTIÓN DE CAMBIOS .......................................................................................................... 41

FIGURA 2.10. ESTRUCTURA GENERAL DE GDS ......................................................................................................... 43

FIGURA 2.11. DISTRIBUCIÓN DE PERSONAL ADMINISTRATIVO POR CENTROS ................................................... 45

FIGURA 2.12. INFRAESTRUCTURA UTILIZADA EN LA OPERACIÓN DEL SGA SYLLABUS ...................................... 49

FIGURA 2.13. ESTADO ACTUAL DE LA GESTIÓN DE INCIDENTES ........................................................................... 53

FIGURA 2.14. GRÁFICA DEL SOPORTE DE INCIDENTES POR FUNCIONALIDAD .................................................... 55

FIGURA 2.15. ESTRUCTURA DEL CENTRO DE SERVICIO CENTRAL EN EL GDS .................................................... 56

FIGURA 2.16. ESTRUCTURA ORGANIZACIONAL DEL CENTRO DE SERVICIO ....................................................... 58

FIGURA 2.17. PROCESO PROPUESTO PARA LOS MIEMBROS DEL CENTRO DE SERVICIO GDS ........................ 60

FIGURA 2.18. DEFINICIÓN DE NIVELES DE ESCALADO ............................................................................................. 68

FIGURA 2.19. SISTEMA DE PRIORIDADES ................................................................................................................... 69

FIGURA 2.20. PROCESO DEFINIDO PARA LA GESTIÓN DE INCIDENTES ................................................................ 71

FIGURA 2.21. PROCESO DE LA GESTIÓN DE PROBLEMAS ...................................................................................... 74

FIGURA 2.22. PROCESO DE GESTIÓN DE CAMBIOS .................................................................................................. 76

FIGURA 2.23. RELACIÓN ENTRE CENTRO DE SERVICIO, GESTIÓN DE INCIDENTES, PROBLEMAS Y CAMBIOS .......................................................................................................................................................................................... 78

FIGURA 3.1. PÁGINA PRINCIPAL HERRAMIENTA ONEORZERO ................................................................................ 83

FIGURA 3.2. PÁGINA PRINCIPAL HERRAMIENTA SYSAID .......................................................................................... 84

FIGURA 3.3 PÁGINA PRINCIPAL HERRAMIENTA MANAGEENGINE SERVICEDESK ................................................ 85

FIGURA 3.4. CRITERIOS DE SELECCIÓN DE LA HERRAMIENTA ............................................................................... 88

FIGURA 3.5. PORCENTAJE DE LA HERRAMIENTA EN RELACIÓN A LOS CRITERIOS EVALUADOS ..................... 88

FIGURA 4.1. CRITERIOS PARA DETERMINAR PRIORIDAD........................................................................................ 97

FIGURA 4.2. ANÁLISIS DEL NIVEL DE SATISFACCIÓN DE LOS USUARIOS FRENTE A LA HERRAMIENTA ......... 99

FIGURA 4.3. TIEMPO PROMEDIO DE REGISTRO POR INCIDENTE EN LA HERRAMIENTA .................................... 99

FIGURA 4.4. ADAPTACIÓN AL PROCESO PROPUESTO DE GESTIÓN DE INCIDENTES ....................................... 100

FIGURA 4.5. NÚMERO DE CASOS ABIERTOS, PENDIENTES Y CERRADOS .......................................................... 101

FIGURA 4.6. NÚMERO DE CASOS POR USUARIO ..................................................................................................... 102

FIGURA 4.7. CASOS POR GRUPO DE USUARIOS ..................................................................................................... 102

FIGURA 4.8. CASOS POR FUNCIONALIDAD ............................................................................................................... 103

FIGURA 4.9. NÚMERO DE CASOS POR ÁREA ............................................................................................................ 104


FASE 1 1 Estudio de ITIL


2

1.1 Historia de ITIL

ITIL (Biblioteca de Infraestructura de Tecnologías de la Información) desarrollada por el gobierno británico específicamente la OGC Oficina Gubernativa de Comercio Británica (Office of Goverment Comerce) a finales de 1980 , al observar la progresiva dependencia de las TI y al examinar que sin prácticas estándar las instituciones del gobierno como del sector privado creaban sus propios procesos, lo que daba como resultado esfuerzos duplicados dentro de sus proyectos TIC, errores comunes y mayores costos [Gobierno TIC].

Al considerar todos estos aspectos nació la idea de empezar a desarrollar una serie de recomendaciones de cómo se debía organizar una área de informática alrededor del concepto de servicio TIC y orientando la provisión de servicios al usuario final.

Así surgió un conjunto de libros que resumen y recogen un número de mejores prácticas del sector público como del sector privado a las que se llamó ITIL, [Gobierno TIC] estas prácticas se dan en base a toda la experiencia adquirida con el tiempo en una determinada actividad, encaminadas a ayudar a las empresas a lograr calidad y eficiencia en las operaciones cotidianas que realizan.

A mediados de los noventa, ITIL fue reconocido como el estándar más utilizado en la Gestión de Servicios TI a nivel mundial [Gobierno TIC], y actualmente es considerado como una de las mejores prácticas en la administración y explotación de la infraestructura de tecnologías de la información.

1.2 EVOLUCION DE ITIL

Desde el origen de ITIL a finales de 1980 el número de libros publicados creció rápidamente la versión 1 llegó hasta unos 30 libros que cubrían una diversidad de temas, desde el cableado hasta la gestión de la continuidad del negocio.

Se realizó una revisión de la biblioteca a partir del año 2000, en ésta revisión ITIL agrupó los libros según los procesos de administración que cubre cada uno, es así como la versión 2 de ITIL gira en torno a los conceptos de Entrega de Servicios y Soporte de Servicios [GobiernoTIC], los libros de ITIL versión 2 son:

1. Gestión de Servicios de TI: contiene actividades para la administración del servicio que se va a proveer al cliente.

• Provisión de Servicios: determina que servicio necesita el negocio para proveer un soporte adecuado.


3

• Soporte de Servicios: define procesos y funciones para asegurar que el cliente tiene acceso a los servicios ofrecidos.

2. Gestión de la infraestructura de TI: describe procesos para la administración de toda la infraestructura tecnológica de la empresa.

3. Gestión de la seguridad: trata de aspectos a considerar para proteger la infraestructura de tecnologías de la información de acciones incorrectas.

4. Perspectiva de negocio: orientado a los administradores para que comprendan la gestión del servicio dentro del negocio.

5. Gestión de aplicaciones: se centra en el ciclo de vida del desarrollo de aplicaciones.

6. Planeación para implementar Administración del Servicio: prescribe guías y los pasos requeridos para la implementación de ITIL.

En mayo del 2007 fue publicada la versión 3 de ITIL, la misma que consta de 5 libros su estructura gira en torno al concepto del ciclo de vida del servicio. Se detalla los libros de ITIL versión 3:

1. Estrategia de Servicio (Service Strategy): pretende buscar el alineamiento entre las TI y el negocio que cada uno aporte lo mejor al otro.

2. Diseño del Servicio (Service Design): define como desarrollar e implementar políticas, arquitectura y documentos para el diseño de servicios y procesos de TI.

3. Transición del Servicio (Service Transition): se centra en los riesgos, beneficios, mecanismos de entrega y en la visión a largo plazo de los servicios a prestar.

4. Operación del Servicio (Service Operation): explica como proveer y dar soporte al servicio para mantener un estado estable de los servicios prestados.

5. Mejora Continua del Servicio (Continual Service Improvement): ofrece pautas claras y definidas sobre cómo mejorar el servicio.

Los procesos de ITIL pueden ajustarse a cualquier tipo de organización sea grande o pequeña, pública o privada, con servicios internos o suministrados por terceros, lo que se espera que el servicio prestado sea confiable, de alta calidad, estable y de coste aceptable.

Aunque la versión 3 de ITIL aún está siendo liberada en el mercado, si hacemos un pequeña comparativa entre las dos versiones, la versión 3 mantiene los mismos principios que su versión anterior enfocada un poco más en la mejora continua del servicio, si una empresa quiere adoptar prácticas ITIL debe comenzar estudiando los fundamentos de ITIL que se


4

encuentran en las dos versiones, y dependiendo de los procesos que vaya a adoptar la organización, seleccionar la versión que mejor se adapta a sus necesidades.

En la versión 2 el proceso principal de ITIL es la Gestión de Servicios y en la mayoría de casos no se consideraba los demás procesos, en la nueva versión 3 de ITIL se enfoca en el ciclo de vida del servicio, incluyendo en cada ciclo de vida del servicio procesos ITIL de la versión 2.

En la Tabla 1.1 se muestra la inclusión de elementos de la versión 2 en la versión 3 de ITIL: [Pink Elephant]

Tabla 1.1. Elementos de la versión 2 incluidos en la versión 3 de ITIL ITIL versión 2 ITIL versión 3

Gestión de Cambio Transición del Servicio

Gestión de Configuración Transición del Servicio

Gestión de Incidentes Operación del Servicio

Gestión de Problemas Operación del Servicio

Gestión de Versiones Transición del Servicio

Centro de Servicio Operación del Servicio

Gestión de la Disponibilidad Diseño del Servicio

Gestión de Cambio Diseño del Servicio

Gestión Financiera Estrategia de Servicio

Gestión de la Continuidad del Servicio Diseño del Servicio

Gestión del Nivel de Servicio Mejora Continua del Servicio

1.3 ESTRUCTURA DE ITIL

1.3.1 Objetivos:

• El principal objetivo de ITIL es alinear los servicios de tecnologías de la información con las necesidades actuales y futuras de los clientes.

• Mejorar la calidad de los servicios prestados

• Reducir los costes del servicio a largo plazo

1.3.2 Filosofía de ITIL

La filosofía de ITIL consiste en:

• Capturar las mejores prácticas de la industria.


5

• Ser escalable, adaptándose a los requerimientos y complejidad de las organizaciones.

• Ser independiente de la tecnología.

• Ser más descriptivo que prescriptivo.

ITIL recoge un conjunto de guías que buscan lograr que las organizaciones puedan reducir costes, mejorar la calidad del servicio tanto de clientes internos como externos y aprovechar al máximo las destrezas, el conocimiento y la experiencia del personal, mejorando su productividad. ITIL versión 2 cubre 6 disciplinas o áreas y cuenta con un libro por área que se detalla en la Figura 1.1 que se muestra a continuación:

Figura 1.1. Elementos básicos de ITIL versión 2 [Assirati, 2002]

1. Planeación para implementar Administración de Servicios (Planning to Implement Service Management)

2. La Perspectiva del Negocio (The Business Perspective)

3. Administración de Servicios (Service Management)

4. Administración de Infraestructura (ICT Infrastructure Management)

5. Administración de la Seguridad (Security Management)

6. Administración de Aplicaciones (Application Management)


6

1.4 Detalle de las Áreas que componen ITIL versión 2

1.4.1 Planeación para implementar la Administración de Servicios (Planning to implement Service Management)

Se enfoca en cómo y cuándo comenzar a implementar ITIL en la organización, proporciona los elementos claves y los pasos requeridos para la implementación tomando como base las necesidades del negocio en relación a las TI, garantizando de ésta manera que los servicios proporcionados se ajusten a los requerimientos del negocio y contribuyan al logro de su misión.

Para implementar ITIL en una organización o departamento hay que empezar por hacer un estudio de las ventajas que se obtendrán, y saber cómo se pueden conseguir esas ventajas. Con la planificación para implementar la administración de servicios ayuda a identificar los puntos fuertes y débiles que tiene la organización.

Para la implementar ITIL es necesario:

• Establecer claramente los principales objetivos que se esperan conseguir con la implementación de ITIL.

• Implementar un Centro de Servicio alineado con ITIL, que implemente la Gestión de Incidencias, Problemas, Cambios y Gestión de la Configuración.

• Elaborar un plan de implementación de ITIL con objetivos claramente definidos a corto y a largo plazo, lo que ayuda a las empresas a permanecer orientadas en su visión y objetivos, en los pasos parciales, pero sin perder el objetivo final a conseguir.

Al momento de planificar la implementación de ITIL es necesario que la empresa considere los siguientes puntos clave mostrados en la Figura 1.2, lo que permitirá mantenerla orientada a sus objetivos finales y a implementar ITIL con éxito [Assirati, 2002]:

Figura 1.2. Puntos clave a considerar para implementar ITIL


7

Para conseguir una correcta implementación de ITIL hay que tener presentes los aspectos detallados en la Tabla 1.2:

Tabla 1.2. Puntos clave a considerar al implementar ITIL

PUNTOS CLAVE DETALLE

1) Cuáles son nuestros objetivos

Hay que definir la visión y objetivos de alto nivel a los que se quiere llegar. Estos objetivos ayudarán a definir los logros parciales.

2) Dónde nos encontramos en este momento?

Realizar una “foto” de los principales indicadores o KPI (Key Performance Indicator), para lo que debe realizarse una evaluación.

3) Dónde queremos estar?

Definir objetivos específicos para mejorar los indicadores obtenidos, basados en estadísticas resultantes de la evaluación. Las mejoras de los indicadores pueden considerarse como objetivos a “corto plazo” para mejorar la calidad del servicio. Llegando a efectuar una reingeniería.

4) Cómo llegar a donde queremos estar?

Se debe implementar procesos ITIL o los procesos requeridos de acuerdo a estructura de la organización, ayudará a conseguir objetivos a corto plazo.

5) Cómo saber que hemos llegado?

Especificar métricas para verificar que nos estamos moviendo en el sentido correcto para alcanzar los objetivos perseguidos por la organización.

1.4.2 Perspectiva de Negocios (The Business Perspective)

La perspectiva de negocios pretende familiarizar a la empresa con la administración del negocio, proporcionando el diseño, la arquitectura y los componentes fundamentales para definir las tecnologías de la información necesarias para apoyar y promover los procesos estratégicos del negocio, basándose en normas y mejores prácticas definidas para la administración del servicio.

Además ayuda a las empresas a comprender los beneficios de las mejores prácticas de la Administración de Servicios, al mismo tiempo ayuda al proveedor de servicios a hablar sobre el nivel de condiciones con la empresa. Abarca los siguientes aspectos:

• Administración de la continuidad del negocio

• Alianzas y Outsourcing

• Sobrevivir al cambio

• Alineación del negocio y TIC


8

1.4.3 Administración de servicios

La Administración de Servicios es el principal elemento de ITIL, se centra en aspectos operativos de la administración de los servicios que se va a ofrecer al cliente. Como se muestra en la Figura 1.3, se subdivide en dos actividades bien definidas: [Assirati, 2003a]

• Provisión del servicio: encargado de la planificación y mejora de la entrega del servicio.

• Soporte del servicio: se concentra en la operación y soporte a los servicios de TI.

Figura 1.3. Elementos de la Administración de Servicios

1.4.3.1 Provisión del servicio

Esta área ayuda a establecer qué servicio necesita la empresa y proyecta a largo plazo la planificación para proporcionar un soporte adecuado a estos servicios.

Esta área está compuesta por cinco procesos implicados detallados a continuación:

1.4.3.1.1 Gestión de Niveles de Servicio

Este proceso se centra en identificar los servicios que requiere el cliente, a más de definir la calidad y cantidad en los que deben ser proporcionados y a un costo razonable. Su objetivo es mejorar la calidad del servicio y la satisfacción del cliente [OSIATIS, 2007].

La Gestión de Niveles de Servicio tiene un proceso que se detalla en la Figura 1.4:


9

Figura 1.4. Proceso de Gestión de Niveles de Servicio

En la Tabla 1.3 se muestra más a detalle el proceso de la Gestión de Nivel de Servicio:

Tabla 1.3. Detalle del proceso de la Gestión de Nivel de Servicio

Procesos Detalle

Planificación

Identificar las necesidades del cliente. Definición de los Requisitos de Nivel de Servicio (SLR) que permite determinar quién y cómo se va a ofrecer el servicio. Establecer parámetros de rendimiento para verificar la calidad del servicio.

Implementación

Formular los Acuerdos de Nivel de Servicios (SLA) en colaboración con los clientes, estos contienen el detalle de los servicios ofrecidos. Establecer los contratos con el proveedor y los Acuerdos de Nivel de Operación (OLAs) en los que se determina procesos y procedimientos para la correcta provisión del servicio.

Monitorización Elaborar informes de rendimiento que contengan: tiempos de respuesta, # quejas de clientes, costo del servicio, etc. Elaborar métricas que permitan evaluar los niveles de calidad del servicio.

Revisión

Elaborar el Plan de mejora del servicio (SIP) que contiene nuevos requerimientos del cliente, reasignación de recursos, etc, y en base a este definir propuestas para mejoras del servicio y modificar los SLAs definidos si fuera necesario.

1.4.3.1.2 Gestión Financiera

Se orienta a identificar, calcular y controlar el costo de la entrega de servicios TI, de manera que permita ofrecer un servicio de calidad a los clientes con el uso eficiente de los recursos TI.

Las principales actividades de la Gestión Financiera se detallan en la Figura 1.5:


10

Figura 1.5. Proceso de la Gestión Financiera

Determinar el costo del servicio es una tarea compleja puesto que intervienen variables tangibles e intangibles, como las siguientes:

Tangibles

• Hardware (computadoras, impresoras)

• Software (herramientas de manejo de incidentes)

• Infraestructura tecnológica y de comunicaciones

• Recursos humanos del personal del centro de servicio

• Recursos materiales

Intangibles

• Conocimientos que controla el Centro de Servicio

• Experiencia del Centro de Servicio

Además es importante determinar si es conveniente externalizar el servicio o mantener el personal dentro de la empresa.

1.4.3.1.3 Gestión de la Capacidad

Es responsable de proporcionar al negocio los recursos informáticos necesarios para el desempeño eficiente de las tareas pero sin caer en costes excesivos.

En la Figura 1.6 se especifica el proceso de la Gestión de la Capacidad:


11

Figura 1.6. Proceso de Gestión de la Capacidad

En este proceso se deben definir las necesidades desde el punto de vista del negocio, del servicio y de los recursos, ya que para dar un servicio eficiente no solo se necesita de personal preparado sino de contar con una buena infraestructura que vaya acorde con la marcha del negocio.

El propósito es evitar inversiones innecesarias en tecnología que no vayan a la par con las necesidades reales del negocio, a su vez que por la falta de tecnología se vea una deficiente productividad.

1.4.3.1.4 Gestión de la Continuidad del servicio

Encargado de asegurar que existan políticas, procedimientos y planes de contingencia para los servicios TIC y que éstos se pueden ejecutar de forma apropiada en caso de ser necesario, para impedir una grave interrupción del servicio debido a desastres naturales u otras causas.

Este proceso debe contar con procedimientos:

Proactivos: para minimizar o evitar en lo posible la interrupción del servicio.

Reactivos: cuyo propósito es aplicar medidas que permitan restablecer el servicio lo más rápido posible.

Los beneficios de este proceso son percibidos a largo plazo, ya que su eficacia se demuestra al momento que ocurren interrupciones en el servicio y la velocidad con la que éste es restaurado con el mínimo de impacto en las operaciones del negocio.

Se detalla el proceso de la Gestión de la Continuidad del Servicio en la Figura 1.7:


12

Figura 1.7. Proceso de Gestión de Continuidad del Servicio

1.4.3.1.5 Gestión de la Disponibilidad

Proceso encargado de garantizar la operación ininterrumpida de los servicios de TI eficientemente, asegurando que estos estén disponibles y funcionen de forma correcta al momento que el usuario los quiera utilizar, todo esto a un coste razonable.

El proceso de la Gestión de la Disponibilidad se describe a continuación en la Figura 1.8:

Figura 1.8. Proceso de Gestión de la Disponibilidad

La administración de disponibilidad se encarga de:

• Negociar los contratos con proveedores de servicios internos o externos.


13

• Asegurar la operación ininterrumpida de la infraestructura de TI.

• Elaborar informes sobre la disponibilidad de los servicios: número de fallos del sistema, tiempo promedio de fallos, etc.

• Monitorear el rendimiento de informes en relación al número de incidentes pendientes, arreglados, tiempos de respuestas, detalle de costos del servicio, tiempos de resolución.

1.4.3.1.6 Gestión de la Seguridad

La gestión de la Seguridad tiene como misión velar porque la información que maneja la organización este siempre disponible, sea correcta y sea utilizada por personas autorizadas para hacerlo.

La Figura 1.9 mostrada a continuación se describe el proceso de la Gestión de la Seguridad:

Figura 1.9. Proceso de Gestión de la Seguridad

1.4.3.2 Soporte del servicio

Área encargada de asegurar principalmente que el cliente tenga acceso adecuado a los servicios que presta el negocio.

El soporte del Servicio definido por ITIL ayuda a la empresa a gestionar el hardware, software y los recursos humanos para asegurar la continuidad y no interrupción de los servicios del negocio, provocados por incidentes presentados.

Incidente es: cualquier evento que no es parte de la operación normal de un servicio y que causa o puede causar una interrupción o reducción de la calidad del servicio [ITIL]. Cada incidente genera una cadena de procesos: Administración de Incidentes, Administración del Problema, Administración de Cambios, Gerencia de implementación o puesta en producción y Administración de Configuración. Esta cadena es monitoreada utilizando la CMDB (Base de datos de administración de la configuración), en la que se almacena cada proceso y crea los documentos de salida.


14

Soporte del Servicio tiene una función clave que es el Centro de Servicio y algunos procesos involucrados que se detallan a continuación:

1.4.3.2.1 Centro de Servicio (Service Desk)

El Centro de servicio como función del Soporte de Servicio, cumple con el papel de servir de punto de contacto entre el usuario y la organización, dando soporte de primer nivel registrando y monitorizando llamadas e incidentes y tratando de dar solución y redireccionar o escalar si el incidente no puede ser resuelto.

Existen varias denominaciones para un Centro de Atención al usuario:

Call Center: básicamente recibe un gran volumen de llamadas telefónicas y las redireccionar a la persona correspondiente.

HelpDesk: trata de resolver los incidentes en el menor tiempo posible.

Service Desk: además de manejar incidentes, problemas y consultas, ofrece servicios adicionales como: administrar contratos de licencias de software, supervisa niveles de servicio y contratos, cambios de clave, es aquí donde se recogen la mayoría de incidentes presentados por el usuario y se escala de acuerdo a la complejidad del mismo, en la Figura 1.10 se resume el proceso:

Figura 1.10. Proceso Service Desk

1.4.3.2.2 Gestión de Incidentes

Proceso responsable de la resolución de incidentes reportados por los usuarios en el menor tiempo posible y de forma eficaz.

Se detalla el proceso de la Gestión de Incidentes en la Figura 1.11:


15

Figura 1.11 Proceso Gestión de Incidentes

1.4.3.2.3 Gestión del Problema

La Gestión del Problema trata de identificar las causas reales que originaron los incidentes recurrentes que se desconocen sus causas, recomendar posibles soluciones sean temporales o definitivas, proponer RFC (Petición de Cambio) para restablecer la calidad del servicio y realizar evaluaciones a los cambios para verificar que han surtido efecto sin crear problemas secundarios.

En la Figura 1.12 se detalla los procesos de la Gestión de Problemas:

Figura 1.12. Proceso de Gestión de Problemas

1.4.3.2.4 Gestión de la Configuración:

Este proceso permite llevar un registro actualizado de la infraestructura física y lógica con la que cuenta la organización y la relación entre componentes como: hardware, software, documentación de aplicaciones y de procesos, SLAs, y demás elementos relacionados con la infraestructura de TI, esto permite tener un entorno global de la organización, además de proveer información precisa y fiable a toda la organización. Los elementos que se definen en la Gestión de la configuración son:

CI (Elementos de Configuración): es cualquier componente TI de la organización. Cada CI registra información referente a:

• Atributos: datos descriptivos de un CI.

• Relaciones: definir relación lógica o física con otros componentes.

• Profundidad: indicar nivel de detalle de los elementos de configuración.


16

La CMDB (Base de Datos de la Gestión de Configuración): contiene información detallada de cada elemento de configuración como se muestra en la Figura 1.13.

Figura 1.13. Elementos de Configuración

Detalle del proceso de la Gestión de Configuración mostrado en la Figura 1.14:

Figura 1.14. Proceso Gestión de la Configuración

1.4.3.2.5 Gestión del Cambio

La Gestión de Cambio se encarga de planificar el proceso de cambio de software y hardware requerido y trata de minimizar el riesgo y el impacto en la calidad y continuidad del servicio al momento de realizar los cambios.

En este proceso intervienen:

Gestor de Cambios: es el responsable del proceso del cambio.

CAB (Consejo Asesor del Cambio): grupo interno formado por el Gestor de Cambios y representantes de las áreas de servicios TI, son quienes aprueban los cambios.

Si el cambio fue aceptado se debe considerar algunos aspectos como:

Prioridad: determina la importancia de la RFC con respecto a otras, este dato determina el calendario de cambios a realizar, entre los rangos de prioridades tenemos:

• Baja: el cambio no es significativo y se realiza junto con otros.

• Normal: si el cambio no obstaculiza a otro cambio más importante.


17

• Alta: se realiza el cambio lo más pronto posible ya que afecta a la calidad del servicio.

• Urgente: se realiza el cambio inmediato ya que se ve interrumpido el servicio.

Categoría: determina la complejidad e impacto de la RFC lo que permite definir los recursos y plazos para el cambio y nivel de autoridad para implementar el cambio.

En la Figura 1.15 se detalla el proceso de la Gestión de Cambios:

Figura 1.15. Proceso Gestión de Cambios

1.4.3.2.6 Gestión de Versiones

Se encargada de implementar y formular mecanismos que certifiquen y controlen la calidad del hardware y software instalado en el entorno de producción.

Los elementos que intervienen en la Gestión de Versiones son:

DSL (Biblioteca de Software Definitivo): contiene la copia de todo el software instalado como: controladores, aplicaciones, etc.

DHS (Depósito de Hardware Definitivo): debe agregar los repuestos funcionales para los elementos de configuración.

Las versiones pueden clasificarse según su impacto en:

• Mayores: abarcan modificaciones importantes en la aplicación tanto software como hardware.

• Menores: incluye pequeñas modificaciones de errores conocidos.

• De emergencia: son correcciones que reparan de forma rápida un error conocido.

Se detalla el proceso de la Gestión de Versiones en la Figura 1.16:


18

Figura 1.16. Proceso Gestión de Versiones

1.4.4 Administración de la Infraestructura de TIC (ICT Infrastructure Management)

Abarca aspectos para la administración de toda la infraestructura tecnológica de la organización, desde la identificación de los requerimientos tecnológicos del negocio, por medio del análisis y definición de alternativa de solución, hasta la prueba, instalación, liberación, soporte de operación, y mantenimiento de los componentes y servicios de las TIC.

Incluye actividades como:

• Gestión de servicios de red.

• Gestión de operaciones.

• Gestión de centros distribuidos.

• Aprobación e instalación de ordenadores.

1.4.5 Administración de la Seguridad (Security Management)

Se concentra en el proceso de satisfacer los requerimientos de seguridad identificados en los acuerdos de niveles de servicio de las TI, y en establecer los mecanismos necesarios para brindar soporte técnico a los usuarios, con el propósito de garantizar la continuidad de los servicios de TI dentro de la organización.

1.4.6 Administración de Aplicaciones (Application Management)

Tiene la misión de dirigir las complejas tareas para administrar las aplicaciones a lo largo de su ciclo de vida, desde la identificación de las necesidades del negocio hasta su propio retiro, centrándose sobre todo en la definición de requisitos e implementación de soluciones. Incluye actividades como:

• Soporte del ciclo de vida del Software.

• Prueba de un servicio de Tecnologías de Información para uso operacional.


19

1.5 Certificaciones en la Metodología ITIL

Existen certificaciones ITIL para profesionales, el obtener una certificación acredita que la persona tiene un conocimiento profundo sobre el tema de ITIL, para las empresas contar con personal capacitado en esta área representa una ventaja competitiva frente a las demás, y se constituye un activo más para la empresa, para certificarse es necesario aprobar un examen en cualquiera de las dos instituciones acreditadas:

(1) ISEB (The Information Systems Examination Board) pertenece a la British Computer Society; y

(2) EXIN (Examination Institute for Information Science in the Netherlands).

Las dos instituciones disponen de una lista de centros de formación acreditados y ambas son igual de válidas para obtener los certificados ITIL.

Se detallan los tres niveles de certificación ITIL para profesionales:

1. Foundation Certificate (Certificado Básico): acredita un conocimiento básico de ITIL en gestión de servicios de TI y conocer las mejores prácticas recomendadas por ITIL.

2. Practitioner’s Certificate (Certificado de Responsable): para quienes tienen responsabilidad de la planificación y diseño de procesos, y de la administración de departamentos de TI.

3. Manager’s Certificate (Certificado de Director): certifica que quien lo posee dispone de profundos conocimientos en todas las materias relacionadas con la administración de departamentos de TI, y lo faculta para dirigir la implantación de soluciones basadas en ITIL.


20

1.6 RESUMEN

Con ITIL se definieron modelos de proceso que fueron probados antes de llevarlos a la práctica y que al día de hoy son consideradas como las mejores prácticas para la Gestión de Servicios de TI. Estos lineamientos de ITIL están en continua evolución a medida que surgen nuevos retos en la organización.

Adoptar buenas prácticas ITIL versión 2 no implica que se vayan a implementar todos los grupos de procesos a la vez, ITIL es un proceso flexible ya que permite escoger los procesos que requiere el negocio independientemente de su tamaño o de la tecnología que disponga.

En conclusión, los conceptos plasmados en la documentación de ITIL son esenciales para una correcta administración de las TI, ya que proporcionan a los profesionales de la informática los conocimientos y recursos necesarios para administrar y mantener una infraestructura tecnológica de forma efectiva, con el principal objetivo de cubrir las necesidades de los clientes mediante la mejor utilización de los recursos disponibles.

Conocer y aplicar las mejores prácticas de ITIL, brinda a la empresa una gran ventaja competitiva, ya que aprovecha las recomendaciones y experiencias aprendidas por otras personas en entornos y situaciones diferentes y durante varios años, estas cualidades convierten al profesional en informática en un agente de cambio, capacitándolo para generar soluciones creativas e innovadoras que mejoren las operaciones del negocio.

Se consideró a ITIL como una buena alternativa para formar el Centro de Servicio del GDS porque actualmente tiene las mejores prácticas probadas a nivel mundial, y de acuerdo a los requerimientos y retos que la UTPL espera cubrir en cuanto al soporte a los usuarios, ITIL brinda la flexibilidad necesaria para adaptar los procesos requeridos y adoptar las mejores prácticas requeridas.


21

FASE 2 2 Diseño de Procesos para el

Centro de Servicio del GDS


22

Introducción

Considerando que el Grupo de Desarrollo de Software de la UTPL tiene como principal producto al Sistema de Gestión Académica SYLLABUS, debido a la criticidad de los procesos que implica y su cobertura se pretende la implementación de un Centro de Servicio que sirva como punto único de contacto entre el usuario y los procesos de negocio, con la finalidad de que éstos sepan exactamente a quien dirigir sus consultas, reclamos, dudas e incidentes presentados en el día a día, para mostrar al usuario que existe un responsable en dar solución a los incidentes reportados.

En este capítulo se analizará más a detalle sobre la función del Centro de Servicio, la Gestión de Incidentes, Problemas y Cambios, se definirán los procesos para el funcionamiento del Centro de Servicio en el Grupo de Desarrollo de Software y el escalamiento entre los diferentes niveles de soporte para los casos requeridos.

Entre los objetivos que se espera obtener en este capítulo es formalizar el primer nivel de soporte de TI entre el usuario final y el Centro de Servicios del GDS, mediante el establecimiento de un proceso de gestión de incidentes y la definición de un acuerdo del nivel de servicio, lo que permitirá mejorar la satisfacción del cliente procurando optimizar el tiempo de respuesta en la solución de cada incidente.

Marco teórico fundamentos ITIL

2.1 Centro de Servicio (Service Desk)

Los usuarios cada vez exigen un servicio rápido, continuo y de calidad, por esta razón se debe mostrar a los usuarios donde acudir cuando requieren ayuda sobre algún incidente, el Centro de Servicio también llamado como SPOC (Single Point of Contact) ya que sirve de primer punto de contacto entre el usuario y la organización, atiende todas las llamadas entrantes de los usuarios ya sea por malfuncionamiento de la aplicación o solicitando un servicio, de esta manera se garantiza al cliente que siempre haya una persona responsable de la llamada y del seguimiento del incidente.

El Centro de Servicio da un soporte de primer nivel tratando de resolver el mayor número de incidentes recogidos en el menor tiempo posible y sin necesidad de redireccionar a otro departamento o escalar el incidente.

Los objetivos de un Centro de Servicio básicamente son:


23

• Servir como punto de contacto inicial al usuario.

• Lograr mayor satisfacción al cliente brindando una atención eficaz y oportuna.

• Reducir los costes mediante la eficiente asignación de recursos.

• Resolver el mayor número de incidentes en el menor tiempo posible.

2.1.1 Denominaciones del Centro de Atención al Usuario

El Centro de Atención al usuario es conocido bajo varias denominaciones como:

• Call Center: gestión gran cantidad de llamadas y redirige al usuario correspondiente.

• Centro de Soporte (Help Desk): primera línea de soporte para resolver interrupciones del servicio.

• Centro de Servicio (Service Desk): maneja incidentes y escala según se requiera.

2.1.2 Tipos de Centros de Servicio

Dependiendo de las necesidades del servicio que se quiere proveer, existen 3 tipos de estructuras del Centro de Servicio: [Assirati, 2003a]

2.1.2.1 Local

Las organizaciones crean centros de servicio locales para satisfacer necesidades locales del negocio, se atienden llamadas de una ubicación local como se observa en la Figura 2.1.

Este modelo puede ser muy costoso ya que existe duplicidad de recursos humanos y conocimientos, puede suceder que un usuario reporte el mismo incidente a dos centros de servicio local lo que produce duplicidad de esfuerzo, tiempo y recursos, si mantiene varios centros de servicio locales es necesario introducir estándares de operación para proveer el servicio.

Figura 2.1. Centro Servicio Local


24

2.1.2.2 Central

Existe una ubicación física central responsable de aceptar, registrar y resolver todas las solicitudes de servicio de varios lugares ya sea departamentos, ciudades o países.

Los principales beneficios de esta estructura es que permite reducir los costes operativos y optimizar recursos disponibles.

Combina actividades con otros departamentos como el Centro de Soporte como se muestra en la Figura 2.2, ésta comunicación permite una respuesta rápida a incidentes que el Centro de Servicio no pueda resolver, estos departamentos deben estar físicamente cercanos.

Figura 2.2. Centro de Servicio Central

2.1.2.3 Virtual

Es un modelo mejorado de los Centros de Servicio anteriores, con el uso de las telecomunicaciones y las redes hacen que la ubicación geográfica de los centros de servicio no sea un factor muy considerable, ya que al tener soporte en diversos lugares con diferentes zonas horarias se pueda brindar soporte las 24 horas, como muestra la Figura 2.3.


25

Figura 2.3. Centro de Servicio Virtual

2.1.3 Consideraciones para seleccionar el tipo de Centro de Servicio

Los criterios para decidir la mejor configuración del Centro de Servicio para su organización son varios, se debe considerar. [Assirati, 2003a]

• Objetivos de la organización

• Madurez y habilidad en los niveles de soporte existentes en la organización

• Tamaño de la organización y naturaleza del negocio

• Estructura de la organización simple, múltiple o global, número de clientes para ser apoyados por el soporte, horas de trabajo a ser cubiertas, …

• Nivel, número y tipo de aplicaciones a ser soportadas puede ser: estándar, especializada o hecha a la medida.

• Infraestructura de la red.

• Cantidad y tipo de equipos/tecnología para el apoyo al servicio.

• Niveles de habilidad de los usuarios.

• Niveles de habilidad del personal de soporte.

• Número del personal de soporte (primera y segunda línea).

• Volumen de llamadas.

• Dependencia con otras organizaciones.


26

2.1.4 Funciones del Centro de Servicio

Entre las funciones más comunes que realiza un Centro de Servicio están: [Assirati, 2003a]

2.1.4.1 Atender las llamadas

Toda llamada que ingrese al Centro de Servicio debe ser registrada para poder llevar el control del progreso y obtener métricas en cuanto al proceso llevado en la resolución del incidente. Existen dos clases de llamadas:

Por solicitar información

Corresponde a llamadas recibidas por los usuarios simplemente solicitando ayuda al personal del Centro de Servicio como puede ser:

• Atención de quejas y reclamos por parte de los usuarios.

• Información sobre el uso de ciertas funcionalidades que está utilizando.

• Solicitud de manuales de usuario.

• Información del proceso que se debe llevar para algún trámite en la aplicación que está utilizando el usuario.

Por Incidentes

Son las llamadas recibidas por fallas en el aplicativo que el usuario está utilizando, puede ser:

• Actualización de datos a nivel de base de datos.

• Errores en el sistema ya sea de hardware o software.

• Fallas en la ejecución de procesos de la aplicación que está utilizando el usuario.

Por Cambios

Son incidentes que no pueden ser resueltos en una primera línea de soporte lo que conlleva que se escale al nivel superior y se tenga que realizar una RFC.

• Por cambios a nivel de aplicación o de datos.

• Construcción de nuevas funcionalidades no existentes y requeridas por el usuario.


27

2.1.4.2 Proporcionar información y recomendaciones para mejora del servicio

El Centro de Servicio es la principal fuente de información de los usuarios, ya que es quien da la cara al usuario, debe ser quien informe acerca de posibles errores y sobre nuevos cambios si los hubiere, además debe ser quien proporcione información sobre los SLAs (Acuerdos de Nivel de Servicio).

2.1.4.3 Administrar el ciclo de vida de un incidente

Realizar una evaluación inicial de la solicitud y dar la solución en ese momento si es posible o escalar a otro nivel si fuera necesario, además de monitorear el proceso de escalamiento hasta el cierre del incidente y su confirmación con el usuario.

2.1.4.4 Coordinación con la segunda y tercera línea de soporte

Si el incidente no fue resuelto en la primera línea debe aplicar el procedimiento de escalamiento de incidentes a los siguientes niveles de soporte, para que analicen más a fondo el porqué del incidente y encuentren la solución al mismo.

2.1.4.5 Identificación de problemas

Debe ocuparse de identificar problemas, es decir si un incidente ocurre en repetidas ocasiones y solamente se da una solución temporal, está ante un posible problema al que debe tratárselo como tal, éste pasa a la Gestión de Problemas quien se encarga de buscar las causas que originaron el problema y buscar la posible solución al mismo.

2.1.4.6 Identificar necesidades de capacitación y entrenamiento para el usuario

El Centro de Servicio debe identificar en que temas se debe profundizar o instruir a los usuarios para minimizar el número de peticiones de servicio, y con esto lograr que el usuario pueda explotar al máximo los recursos con los que cuenta.

2.1.4.7 Satisfacción de usuarios

Otra de las funciones del Centro de Servicio es lograr la satisfacción del usuario final en relación al servicio brindado por parte de los miembros del Centro de Servicio, con lo que se irá formando un buen ambiente de trabajo fortaleciendo las relaciones laborales y permitirá lograr un trabajo eficiente de todos los miembros de la organización.


28

2.1.4.8 Relación con los proveedores

Debe existir una estrecha relación y un contacto directo con los proveedores del servicio en el caso que el soporte sea provisto por personas externas.

2.1.5 Métricas del Centro de Servicio

Se deben establecer objetivos medibles, de manera que al hacer una evaluación post-implementación sobre el rendimiento del Centro de Servicio se pueda comparar los objetivos propuestos con la realidad.

Los informes que se obtengan del Centro de Servicio permitirán medir la eficacia con la que está operando en la resolución de incidentes, las métricas que se consideran básicas están:

• Porcentaje de incidentes que pueden cerrarse sin recurrir a otros niveles de soporte.

• Número de llamadas recibidas por todo el equipo del Centro de Servicio

• Número de llamadas recibidas por cada miembro del equipo.

• Tiempo de resolución promedio de incidentes en periodos críticos y en períodos normales.

• Cantidad de casos resueltos por cada técnico del Centro de Servicio.

• Satisfacción de usuarios.

2.1.6 Capacidades del Personal del Centro de Servicio

Lo que toda empresa persigue es dar un servicio continuo y de alta calidad es lo que marca el éxito de una empresa, esto depende en gran medida de la cultura organizacional que adopte el personal del Centro de Servicio, el que debe adquirir habilidades interpersonales y tener un perfil profesional para la comunicación con el usuario tales como: [Assirati, 2003a]

• Compartir la filosofía de atención al cliente.

• Servicial con el usuario.

• Capacidad de trabajar en equipo.

• Conocer a profundidad los servicios ofrecidos por la organización.

• Manejar las herramientas tecnológicas necesarias para la solución de incidentes.

• Adquirir un lenguaje no técnico con el usuario, de manera que él pueda entender en términos claros la solución del incidente.

• Tener un alto grado de profesionalismo centrándose en el desempeño de sus tareas.


29

• Aprender a escuchar, el personal del Centro de Servicio a más de ser un buen comunicador debe ser un oyente activo, para poder comprender la situación desde el punto de vista del usuario.

• Aptitud técnica, debe poseer un profundo conocimiento de las características y funcionamiento de la aplicación que maneja

• Proactividad, ser capaz de tomar la iniciativa para dar soluciones a los incidentes.

2.1.7 Formas de reportar incidentes al Centro de Servicio

Existen dos formas básicas de reportar los incidentes al Centro de Servicio:

2.1.7.1 Escrita

Fax, correo electrónico, mensajería instantánea, portal de servicios, herramientas tecnológicas para el registro de incidentes.

2.1.7.2 Verbal:

Teléfono o en forma personal del usuario hacia el personal del Centro de Servicio.

2.1.8 Mecanismos de acceso al Centro de Servicio

La preferencia de un mecanismo sobre otro dependerá de la eficiencia y urgencia para poder comunicar los incidentes presentados. Se detalla cada uno de los medios de comunicación que pueden ser utilizados por los usuarios para el reporte de incidentes:

2.1.8.1 Teléfono

Es el medio más eficiente y más común para reportar incidentes ya que permite dar una clara definición y a detalle del problema sucedido.

2.1.8.2 Correo electrónico

Es recomendable definir una plantilla para reportar el incidente a detalle y no exista confusión por parte del personal del Centro de Servicio, se recomienda para solicitudes de información como: claves de acceso, reportes de funcionalidades o petición de requerimientos.


30

2.1.8.3 Asistencia en el lugar

Es muy costoso ya que demanda de recursos que posiblemente no estén disponibles, pero se puede considerar para los usuarios que tengan mayor rango organizacional.

2.1.8.4 Fax

Su principal ventaja es la rapidez de transferencia de comunicación escrita desde cualquier lugar hacia otro, recomendable para solicitar información o enviar una copia física de algún documento requerido para su verificación.

2.1.8.5 Mensajería Instantánea

Aunque es un medio de comunicación rápido de un lugar a otro pero a pesar de que exista información por escrito no tiene el carácter de formal como lo sería un correo electrónico.

2.1.8.6 ACD (Distribuidor Automático de llamadas)

Es recomendable cuando se espera recibir una considerable cantidad de llamadas y se maneja varias aplicaciones, lo más indicado es la utilización de un sistema de respuesta automático junto con un distribuidor automático de llamadas (ACD), al tiempo que filtra la llamada al ofrecer opciones de servicio, puede conducir la llamada al miembro más idóneo de la organización.

2.1.9 Beneficios del Centro de Servicio hacia la organización

Entre los beneficios que el Centro de Servicio puede entregar a la organización tenemos:

• Se centraliza la función de atención al usuario, ya que toda solicitud de soporte ingresa por el Centro de Servicio.

• Se puede establecer requerimientos de capacitación en base a los incidentes reportados.

• Se puede detectar funcionalidades con poca usabilidad y poder atacar el punto débil de la aplicación.

• Con el proceso definido facilita el escalamiento y seguimiento de incidentes cuando no pueden ser resuelto en la primera línea de soporte.

• Aumenta la productividad de los grupos de 2da y 3ra línea de soporte, ya que el usuario adquirirá la cultura de acudir primeramente al Centro de Servicio y ya no reportar los incidentes directamente al personal de las otras líneas de soporte.


31

• Concentra el conocimiento en un solo punto y trata de propagarlo atendiendo y explicando al usuario la solución de los incidentes que se presentan, para lograr que si vuelve a suceder otra vez el usuario sepa cómo resolverlo.

• Apoya a que los usuarios puedan conseguir información rápida sobre la solución a los incidentes reportados.

• Mejorar el ambiente de trabajo, los usuarios se sentirán más tranquilos al saber que tienen el apoyo necesario para el soporte.

• Responsabilidad mejor definida, siempre habrá una persona responsable de dar solución a los incidentes que se presenten.

2.1.10 Factores que influyen en la calidad del servicio ofrecido por el Centro de Servicio

Entre los factores principales a considerar en la calidad del servicio ofrecido están: [Assirati, 2003a]

• Nivel de conocimiento del personal del Centro de Servicio: el personal del Centro de Servicio debe tener un conocimiento profundo sobre el sistema informático al que provee soporte, lo que permitirá ganar la confianza de todos los usuarios, viéndose reflejado en el prestigio que vaya adquiriendo este departamento, ya que sabrán a quien acudir exactamente cuando se presente un incidente.

• Actitud de servicio del personal del Centro de Servicio: como es el punto de contacto entre los usuarios y la organización, el personal debe transmitir un ambiente de confianza y amabilidad con cada uno de los usuarios, ya que la mayoría de usuarios acudirán al personal del Centro de Servicio por ayuda

• Herramientas de registro de incidentes: se debe contar con herramientas que permitan el registro de incidentes, lo que permitirá tener un registro casi real de todo el trabajo diario del personal del Centro de Servicio, además se podrá obtener reportes que permitirán obtener información y conocimiento que apoyen a la toma de decisiones.

• Capacitación al personal: es importante que el personal del Centro de Servicio esté capacitado en nuevas metodologías y herramientas que contribuyan a obtener un mejor nivel de calidad en cuanto al servicio brindado al usuario.

• Establecer un sistema de incentivos profesionales a los miembros del Centro de Servicio, lo que provocara que cada uno se esfuerce por desempeñar mejor su trabajo diario.

• Herramientas de monitoreo de interacciones con el usuario: permite mostrar el desempeño real de la atención a los usuarios y descubrir donde focalizar los


32

esfuerzos, existen distintos tipos de monitoreo como: “On site” o junto al analista, de intercepción de llamada (permite la corrección inmediata), por grabación de llamada (para análisis posterior junto al analista) y mediante análisis de registro (para verificar lo que se registro durante una llamada).

2.2 Gestión de Nivel de Servicio

Este proceso es el encargado de definir, negociar y supervisar la calidad del servicio entregado al cliente.

La Gestión de Nivel de Servicio se encarga de:

• Documentar todos los servicios TI ofrecidos.

• Establecer acuerdos entre clientes y proveedores para ofrecer los servicios requeridos.

• Monitorizar la calidad de los servicios establecidos.

• Colaborar con el cliente para proponer servicios ajustados a sus necesidades.

2.2.1 Beneficios de la Gestión de Nivel de Servicio

Los principales beneficios que se obtiene son: [ITIL]

• Establecer responsabilidades claras de los clientes y proveedores del servicio.

• Los servicios TI son diseñados con el objetivo de cubrir las necesidades del cliente.

• La monitorización permite identificar áreas débiles para su mejora.

• Los SLAs ayudan a calcular los costos como a justificar precio del servicio ante los clientes.

2.2.2 Proceso de la Gestión de Nivel de Servicio

Las principales actividades de la Gestión de Nivel de Servicio se detallan en la Figura 2.4:

• Planificación

• Implementación

• Supervisión

• Revisión


33

Figura 2.4. Proceso de Gestión Nivel de Servicio

Planificación

Se elaboran documentos de carácter interno y otros accesibles a los clientes, estos documentos deben incluir los productos y servicios ofrecidos de acuerdo a las necesidades de los clientes.

Implementación

Se negocia el servicio a prestar y se elabora un SLA que contiene desde los aspectos más generales hasta los más específicos del servicio a proveer.

Supervisión

A través de la monitorización de los niveles se puede mejorar la calidad del servicio prestado y permite elaborar programas de mejora del servicio.

Revisión

La revisión de la calidad de los servicios ofrecidos debe realizarse en base a parámetros y objetivos medibles, como resultado de la medición se elabora un programa de mejora del servicio.

2.2.3 Acuerdo de Nivel de Servicio (SLA)

Es un acuerdo escrito entre el proveedor del servicio y el cliente, en el que se definen los objetivos del servicio a alcanzar, los servicios que serán provistos los que no se atenderá, y las responsabilidades de cada una de las partes involucradas, de manera que sea un acuerdo beneficioso para ambas partes.


34

El contenido del SLA varía de acuerdo a cada situación, pero existen algunos aspectos comunes a incluir en el SLA, se detallan a continuación: [Assirati, 2003b]

• Descripción de quienes establecen el acuerdo

• Período cubierto por el acuerdo

• Detalle de los servicios que serán provistos

• Horario de servicio

• Responsabilidades de los clientes

• Como acceden los clientes al servicio

• Definición de prioridades y tiempos de respuesta

• Reportes que deben ser generados

• Políticas del servicio.

A través del establecimiento del Acuerdo de Nivel de Servicio (SLA) se especifica generalmente los servicios que serán provistos y los que se excluyen, cada punto del acuerdo del SLA debe ser claramente especificado, entre más detalle, habrá menos oportunidades de malos entendidos y de expectativas no cumplidas.

2.3 Gestión de Incidentes

El principal objetivo de la Gestión de Incidentes es restaurar el funcionamiento normal del servicio lo antes posible y minimizando el impacto negativo en las operaciones de la empresa con el fin de mantener los mejores niveles posibles de calidad y disponibilidad de servicio [Technet, Microsoft], lo que permite que el usuario pueda volver a trabajar lo más pronto posible sin interrupciones en el servicio.

ITIL define un incidente como: “Cualquier evento que no es parte de la operación normal de un servicio y que causa o puede causar una interrupción o reducción en la calidad del servicio. [ITIL]

No todo incidente puede ser resuelto en el primer nivel de soporte, por lo que si el usuario solicita algún cambio en la infraestructura esto requiere el inicio de una petición de cambio.

2.3.1 Objetivos de la Gestión de Incidentes

Se detallan los principales objetivos: [ITIL]

• Detectar cualquier alteración en los servicios TI.

• Restaurar la operación normal del servicio lo antes posible.


35

• Minimizar el impacto de los incidentes en el negocio.

• Asignar personal necesario para la restauración del servicio.

2.3.2 Beneficios de una correcta Gestión de incidentes.

Los principales beneficios que se obtienen son:

• Mejora la productividad con los usuarios.

• Cumplimiento de los niveles de servicio acordados en el SLA.

• Optimización de los recursos disponibles.

• Mejora la satisfacción de clientes y usuarios.

2.3.3 Clasificación del Incidente

La prioridad de un incidente se define considerando la gravedad con que afecta a la organización y al usuario, se basa en dos criterios:

• Impacto: depende de cómo afecta a los procesos del negocio y al número de usuarios afectados.

• Urgencia: velocidad con la que se debe resolver el incidente.

Para resolver cada incidente se determina cierta cantidad de recursos y se designa la persona responsable de resolverlo y se considera el tiempo que tarde en dar la solución.

Figura 2.5. Elementos para determinar prioridad de un incidente

La prioridad de un incidente puede cambiar durante su ciclo de vida, ya que se pueden hallar soluciones temporales para restaurar el nivel de servicio hasta hallar la solución final al incidente.

2.3.4 Escalado y Soporte

No siempre va hacer posible resolver todos los incidentes en un primer nivel de servicio, por esto se debe recurrir a la ayuda de otra persona perteneciente a un nivel superior a este proceso se denomina escalar. Existen 2 tipos de escalado:


36

2.3.4.1 Funcional (horizontal):

Incluye personal especializado o que tiene autoridad técnica para dar solución al incidente.

Figura 2.6. Gestión de incidentes como proceso horizontal

2.3.4.2 Jerárquico (vertical)

Se debe recurrir a personal de mayor autoridad para tomar decisiones que se escapan de las atribuciones asignadas a ese nivel. [CentroServicio]

2.3.5 Proceso de la Gestión de Incidentes

En este punto se define el proceso a utilizar para el tratamiento y solución de cada incidente que llegue al Centro de Servicio.

Aquí intervienen los diferentes niveles de escalado, además se debe contar con el apoyo de la Base de Conocimiento que es la principal herramienta para el personal del Centro de Servicio donde se encuentran descritas soluciones prácticas y rápidas para restaurar el servicio en el menor tiempo posible.

Si no se encuentra solución al incidente debe ser apartado para darle un tratamiento diferente y evaluar su solución, y ser asignado a los especialistas de los otros niveles de soporte.

Los principales procesos de la administración de incidentes son: [Assirati, 2003a]

• Registro de incidentes.

• Clasificación y soporte inicial.

• Investigación y diagnóstico.

• Resolución y recuperación.

• Cierre del incidente y confirmación con el usuario.


37

Figura 2.7. Proceso de gestión de incidentes

El proceso de la Gestión de Incidentes inicia cuando:

El usuario reporta una interrupción en las aplicaciones que está utilizando al Centro de Servicio, que es el primer punto de contacto de la organización.

Luego se realiza el registro y clasificación del incidente con información referente a: prioridad, categoría y recursos a utilizar para su solución.

Si el incidente solo es solicitando información se provee la información al usuario y se cierra el incidente.

Si el incidente es por problemas en alguna funcionalidad se investiga y diagnostica la solución con ayuda de la Base de Conocimiento.

Si se encontró la solución se asignan los recursos necesarios, caso contrario se escala el incidente.

Finalmente cuando se ha resuelto el incidente satisfactoriamente se registra la solución encontrada al incidente y se confirma con el usuario que lo reportó.

Registro de incidentes

Este es el primer paso para el tratamiento de un incidente reportado, el registro de cada incidente debe ser sencillo y preciso, los datos mínimos que se debe registrar son:


38

• # de incidente: número único que permitirá identificar de manera más rápida el incidente ya sea en procesos internos como en comunicaciones al usuario.

• Registrar datos del cliente como nombre, teléfono, ubicación.

• Registro inicial para detallar el incidente, se introduce información básica como: hora, descripción precisa del incidente, funcionalidad afectada.

• Tiempo estimado para dar solucionar al incidente.

• Información de apoyo: puede incluir información relevante para solucionar el incidente, puede ser solicitada al usuario a través de un formulario o ser obtenida de otras fuentes.

• Notificación del incidente: si el incidente afectará a otros usuarios debe comunicarse como puede afectar al proceso normal de trabajo.

Clasificación de incidentes

Su principal función es recopilar toda la información útil para poder dar solución al incidente. Se detalla la información mínima a registrar:

• Categorización: es asignado de acuerdo al tipo de incidente como: servicio no disponible, solicitud de servicio, problemas con software o hardware, solicitud de un consejo, entre otros.

• Establecer nivel de prioridad: dependiendo del impacto y la urgencia del incidente.

• Asignación de recursos: si el incidente no puede ser resuelto en la primera línea de soporte debe ser asignado al siguiente nivel.

• Verificar estado y tiempo de respuesta asignado: asignar un estado al incidente permite saber la posición que se encuentra en su ciclo de vida, algunas categorías de estado pueden ser: abierto, asignado, en espera, resuelto, cerrado y se debe asignar un tiempo de resolución del incidente de acuerdo al SLA y a la prioridad.

Investigación y Diagnóstico (Análisis)

Una vez obtenida toda la información posible del incidente, se consulta en la Base de Conocimiento si existe alguna incidencia ya resuelta de ese tipo para aplicar el procedimiento detallado.

Si el incidente no puede ser resuelto en la primera línea de soporte, debe ser redireccionado al siguiente nivel de soporte para que sea analizado por el técnico asignado, si este no puede resolver el incidente se seguirá escalando, si el incidente es recurrente y no se encuentra una solución definitiva al mismo, se debe informar a la Gestión de Problemas para que estudien las causas del mismo o si es necesario emitir un RFC (Petición de Cambio).


39

Resolución y Cierre de Incidentes

Si el incidente pudo ser resuelto debe:

• Confirma al usuario la solución del incidente

• Alimentar la Base de Conocimiento con el proceso aplicado para dar solución al incidente.

• Reclasificar el incidente en caso necesario

• Actualizar información en la CMDB (Base de Datos de la Gestión de Configuraciones) sobre los elementos de configuración implicados en el incidente.

• Cerrar el incidente.

2.4 Gestión de Problemas

La Gestión de Problemas a diferencia de la Gestión de Incidentes se ocupa principalmente de determinar y encontrar las causas que provocaron el incidente, y encontrar su resolución y prevención. Hay que hacer una diferencia entre problema y error conocido:

Problema: es un incidente recurrente de alta importancia y se desconoce sus causas.

Error conocido: es un problema que se ha podido determinar sus causas.

La Gestión de Problemas debe proporcionar a la Gestión de Incidentes soluciones temporales para minimizar el impacto de los problemas o errores conocidos en los servicios.

Los incidentes pueden coincidir con los “Problemas Conocidos” (sin una causa raíz conocida) o “Errores Conocidos” (con una causa raíz conocida) y bajo el control de la Gestión de Problemas y su registro en la base de datos de Errores Conocidos, donde pueden haber sido desarrolladas soluciones temporales que permitirán al Centro de Servicio dar soluciones fáciles y rápidas para restaurar el servicio.

Si un incidente no se encuentra dentro de los Problemas Conocidos o los Errores Conocidos, deberá ser aislado y requiere que la Gestión de Problemas se involucre, posiblemente registrando un nuevo tipo de problema.

Los principales procesos de la gestión de problemas son:

• Investigación, registro y clasificación.

• Diagnóstico.

• Solución, Emitir RFC. [ITIL]


40

Figura 2.8. Proceso Gestión de Problemas

2.4.1 Detalle del proceso de la gestión de problemas

Investigación, registro y clasificación

Se encarga de identificar el problema, para ello debe basarse de algunas fuentes de información como la Base de Datos de Incidentes que tiene el registro de los incidentes consecutivos y se ha cerrado mediante una solución temporal pero aun no se ha solucionado en su totalidad.

Si este incidente es considerado un problema debe registrar información referente a: ítems afectados, causas del problema, síntomas, soluciones temporales aplicadas, nivel de prioridad y el impacto que tiene en el proceso de negocio, esta información permite clasificar el problema y asignar los recursos necesarios para asegurar un tratamiento eficaz al mismo.

Diagnóstico

En esta fase se determinan las causas del problema y se proponen soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema, hasta que se implementen los cambios que darán la solución definitiva, estos deben ser registrados en la Base de Errores Conocidos donde se almacenan las posibles soluciones.

Solución

Se deben evaluar varias soluciones para el error considerando siempre el impacto en la infraestructura TI, sus costos asociados e influencia en los SLAs.

Una vez determinada la solución óptima al problema se emite un RFC a la Gestión de Cambios, quien es la responsable de implementar los cambios propuestos en la infraestructura.


41

Es necesario realizar una PIR (Revisión post-implementación) del cambio realizado, si los resultados son satisfactorios se cierra el proceso y se emiten los informes correspondientes. Se registra en la base de datos de Errores conocidos las soluciones al problema, los RFC y los informes de la PIR.

2.5 Gestión de Cambios

El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio, asegurando que se lleve a cabo de la forma más eficiente posible y asegurando la calidad y la continuidad del servicio en todo momento.

Los principales motivos por los que se realizan cambios en la infraestructura de tecnologías de información son:

• Solución de errores conocidos

• Desarrollo de nuevos servicios

• Mejoramiento de servicios existentes

• Requerimiento legal

Se detalla el proceso para la gestión de cambios:

Figura 2.9. Proceso gestión de cambios

• Registro

• Clasificación


42

• Planificación y Pruebas

• Coordinar proceso implementación

• Cierre

2.5.1 Detalle del proceso de la gestión de Cambios

Registro

El primer paso de la Gestión de Cambios es el registro de los RFC, este puede provenir de:

• Gestión de Problemas cuando propone una solución a un error conocido.

• Requerimiento de nuevos servicios lo que requiere cambios en la infraestructura TI.

• Nace una nueva estrategia empresarial que por lo general requiere cambios de hardware, software y procesos.

• Cualquier usuario, cliente o proveedor puede sugerir mejoras en los servicios lo que implica cambios en la infraestructura TI.

El registro del RFC requiere información como: fecha de recepción, número de identificación, descripción del cambio, elementos implicados, estimación de recursos, tiempo implicado.

Clasificación

Si el cambio es aceptado se debe asignar prioridad y categoría, es importante definir la categoría ya que establecerá la asignación de recursos necesarios, además determina el impacto sobre la organización y el esfuerzo requerido para su implementación.

Planificación y Pruebas

Luego de aprobado el cambio se debe planificar el cambio, ya que todo cambio implica un riesgo es conveniente disponer de planes de “back-out” que permita la recuperación de la última configuración antes de realizar el cambio, en el caso que no funcione la implementación del cambio realizado.

Además debe evaluarse si el cambio ha de ser implementado individualmente o en un paquete de cambios, este último permite optimizar recursos y evitar incompatibilidades entre cambios.

Implementación

La gestión de cambios no se encarga de implementar el cambio pero si debe monitorizar el proceso para que el software y hardware se adapten a las especificaciones solicitadas, que se


43

cumpla los calendarios previstos y la asignación de recursos fue adecuada, los planes de “back-out” van a permitir la recuperar la última versión.

Cierre

Si los objetivos previstos se cumplieron y la evaluación final determina que los resultados son satisfactorios se cierra el cambio y se incluye esta información en el documento de PIR (Revisión post-implementación).

2.6 Situación Actual en el GDS

El Grupo de Desarrollo de Software es el encargado de proveer, desarrollar y mantener los sistemas informáticos que posee la UTPL, los que sirven para soportar los procesos que día a día se desarrollan por la naturaleza de la organización, como bien se conoce la UTPL es una institución que brinda servicios de educación superior en la modalidad de estudios Presencial y modalidad Abierta y a Distancia.

Se detalla una visión más a detalle de la estructura funcional del GDS, y los procesos llevados para dar el soporte a uno de los más grandes proyectos que maneja actualmente que es el Sistema de Gestión Académica Syllabus, debido a la cantidad de información que maneja se requiere brindar un servicio de calidad y continuo a los usuarios del mismo, entre los que están: secretarias, personal de contabilidad, coordinadores de los diferentes centros universitarios, docentes y estudiantes.

A continuación se muestra una visión general de la estructura del GDS.

2.6.1 Estructura del Grupo de Desarrollo de Software

El GDS se ha estructurado internamente en áreas de trabajo dirigidas por un responsable.

A continuación, la estructura general del GDS:

Figura 2.10. Estructura general de GDS


44

El GDS está formado por 5 grupos, se detallan las funciones generales de cada uno de estos grupos:

2.6.1.1 User Experience (2 personas)

Se encarga principalmente de la interacción entre el usuario y los sistemas. Las tareas principales son:

• Diseño de interfaces de usuario

• Entrenamiento y capacitación a los usuarios

• Soporte a los usuarios

• Usabilidad de las aplicaciones

• Documentación

2.6.1.2 Release Management (2 personas)

Su tarea principal es liberar versiones. Entre las tareas que realiza están:

• Configuración de la infraestructura y el ambiente de trabajo para el despliegue del producto

• Monitoreo de servidores

• Administración de la Base de Datos

• Gestión de respaldos

2.6.1.3 Control Quality (3 personas)

Encargado de evaluar la calidad del producto que se está desarrollando tratando de que se libere con cero errores.

• Generar y ejecutar casos de prueba

• Detección y corrección de errores

• Verificar que los requerimientos tengan su apropiada implementación

• Desarrolla planes para la validación del aplicativo en producción

2.6.1.4 Developers (3 personas)

Este grupo se encarga de la construcción de los componentes de acuerdo a las especificaciones funcionales y de acuerdo al plan de desarrollo especificado. Entre sus principales tareas están:


45

• Transformar los requisitos al diseño del sistema

• Evaluación de la tecnología a utilizar para el desarrollo del producto

• Desarrollo de los módulos de la aplicación

2.6.1.5 Architect (2)

Se encarga básicamente de definir la arquitectura que guiará el desarrollo del software. Entre sus tareas principales están:

• Construcción de prototipos necesarios

• Desarrollar una arquitectura para el sistema

• Definir lineamientos generales del diseño y la implementación

2.6.2 Inventario de usuarios

Actualmente la UTPL ha expandido los servicios del SGA Syllabus a varios lugares a nivel nacional, es por ello que la cantidad de usuarios ha crecido considerablemente, se estima en 27.000 usuarios los que se encuentran distribuidos en grupos de usuarios detallados a continuación:

2.6.2.1 Personal Administrativo-Secretarias

Es el personal encargado de realizar las matriculas de los estudiantes de modalidad clásica y abierta, se subdividen en varios grupos:

Distribución de Centros

1 5

18

59

30

10203040506070

1

Centro SedeCentros RegionalesCentros Provinciales Centros AsociadosCentros Extranjeros

Figura 2.11. Distribución de personal administrativo por Centros

• Secretarias de carrera de modalidad clásica: Ubicad@s en la sede y se encarga de la problemática de los procesos académicos de modalidad clásica.


46

• Secretarias de carrera de modalidad abierta: Ubicad@s en la sede y se encarga de la problemática de los procesos académicos de modalidad abierta.

• Coordinadores y Secretarias de centros regionales (5 centros): personal encargado de las matrículas en los centros de Quito, Quito Villafora, San Rafael, Guayaquil y Cuenca.

• Coordinadores y Secretarias centros provinciales (18 centros): personal encargado de matrículas de estudiantes de centros regionales del país.

• Coordinadores y Secretarias centros asociados (59 centros): es el personal administrativo encargado de las matrículas en todos los centros asociados del país.

• Coordinadores y Secretarias de centros extranjeros (3 centros): personal encargado de matriculas en los centros extranjeros: Madrid, Roma y New York.

2.6.2.2 Personal de Contabilidad (10 personas)

Generalmente para realizar la facturación de los diferentes tipos de derechos y verificar el expediente económico del estudiante.

2.6.2.3 Personal Docente (800 docentes)

Personal docente que accede al SGC Syllabus para pasar notas de estudiantes de modalidad clásica y abierta.

2.6.2.4 Estudiantes (26000 estudiantes)

Estudiantes de modalidad clásica aproximadamente 3000 estudiantes, en modalidad abierta y a distancia 17000 estudiantes de centros nacionales y extranjeros, y postgrados aproximadamente 6000 estudiantes que hacen uso de sistema a través de los servicios en línea permitiendo: consultar notas, ver expediente académico, realizar evaluación al docente, descargar cuadernillos de preguntas y hojas de respuesta de asignatura de calificación automática.

2.6.3 Módulos con los que cuenta el SGA Syllabus

Se muestra un detalle de las principales funcionalidades del SGA Syllabus las que se encuentran organizadas en módulos, detallados a continuación:


47

2.6.3.1 Matrícula

Se encuentran las funcionalidades que permiten realizar y modificar la matrícula de un estudiante de modalidad clásica, abierta o virtual, entre sus principales funcionalidades se detallan:

Tabla 2.1. Funcionalidades del módulo de Matrícula

Funcionalidad Descripción

Ingreso de Matrícula Permite realizar matrícula a estudiantes de la UTPL.

Mantenimiento de Matrícula

Para realizar eliminación e inserción de asignaturas o eliminación de matrícula.

Facturas Masivas Imprimir facturas de acuerdo a criterios requeridos por el usuario

Cambios de Paralelo Para cambios de paralelo a estudiantes de modalidad clásica.

Ingreso Matriculación Créditos

Permite el registro de matrículas para estudiantes de modalidad clásica con el modelo ECTS.

Envío e-mail matrículas créditos

Permite enviar al correo de estudiantes de modalidad clásica la confirmación de su matrícula.

Consulta Matrícula Permite ver datos de la matrícula del estudiante

2.6.3.2 Gestión Académica

Permite verificar y obtener información académica de los estudiantes, consta de algunas funcionalidades:

Tabla 2.2. Funcionalidades del módulo de Gestión Académica


Justificación de Asistencias

Permite justificar asistencia para estudiantes de modalidad clásica previa autorización del director de carrera.

Reportes

Contiene un conjunto de reportes que pueden ser impresos entre los principales: certificados de materias de estudiantes, listas de estudiantes, notas de estudiantes, generar datos de número de estudiantes matriculados por carrera, período académico, etc.

Trámites Lleva un registro automático de trámites como: cambios de centros de evaluación, anulación de asignaturas, anulación de matrícula, asentamiento de notas, entre otros.

Adaptaciones Créditos Permite la ejecución de reglas de adaptación al modelo de créditos UTPL-ECTS para estudiantes de modalidad clásica.

Autorizaciones Permite el registro de autorizaciones para: tercera matrícula,


48

cambios de paralelo, descuentos, modificar notas y asistencias.

Convalidaciones Módulo que permite realizar el registro automático del estudio de convalidaciones externas para estudiantes que viene de otras universidades.

Expediente Académico Contiene todo el historial académico y económico del estudiante, puede verificar información relacionada a: asignaturas, matrículas, impedimentos, saldos.

Ingreso y Consulta Notas y Asistencias

Permite el registro y la consulta de notas de estudiantes matriculados en modalidad abierta, clásica o virtual

Hojas de Respuesta Permite la impresión de hojas de respuesta de las asignaturas de calificación automática.

Entrega, devolución y consulta de material

A través de estas funcionalidades se puede registrar la entrega, devolución y consulta del material bibliográfico de cada estudiante.

2.6.3.3 Gestión Financiera

Permite verificar y manejar la situación financiera del estudiante dentro de la UTPL.

Tabla 2.3. Funcionalidades del módulo de Gestión Financiera


Pagos y Cobros Estudiantes

Permite ver el historial de todos los pagos de cada estudiante en los diferentes periodos académicos que se ha matriculado.

Facturación y Consulta de Derechos

Permite la facturación de derechos al estudiante como: derechos de grado, derechos para convalidación, para ubicaciones de asignaturas, entre otros.

Recaudaciones Permite ingresar el pago de deudas pendientes de pago de cuotas de matrícula.

Revisión Pagos y deudas por estudiante

Visualiza deudas pendientes del estudiante por pagar en el banco.

2.6.3.4 Configuración

Permite realizar configuraciones necesarias como: oferta académica, parámetros, definir costos en el SGA Syllabus, para estar listo para el ingreso de matrículas en cada período académico.

Tabla 2.4. Funcionalidades del módulo de Configuración


Mantenimiento de Permite crear los diferentes planes de estudio con sus asignaturas.


49

Planes Estudio

Mantenimiento Oferta Planes Estudio

A través de la cual se realiza la configuración de paralelos,profesores, número de estudiantes, costos.

Mantenimiento Convenios

Registra la configuración de los diferentes convenios que mantienela UTPL con otras entidades.

Mantenimiento de Parámetros

Permite configurar parámetros como costo del crédito para cadacarrera, formas de pago, entre otros.

2.6.4 Infraestructura utilizada en la operación del SGA Syllabus

Se muestra gráfico con la infraestructura tecnológica necesaria para el acceso al SGA Syllabus:

Figura 2.12. Infraestructura utilizada en la operación del SGA Syllabus

El personal encargado de proveer soporte al usuario final debe tener un conocimiento básico de la aplicación e infraestructura sobre la cual trabaja el SGA SYLLABUS, permitiéndole estar en capacidad de determinar las causas comunes del incidente y resolver problemas relacionados a estos, como pueden ser configuraciones básicas del navegador, problemas de red (intranet, VPN, enlaces directos con los centros universitarios), configuración errónea de impresoras con las que trabaja el usuario.

Cuando se lanzó el proyecto en producción en octubre del 2004, se recibía a diario un considerable número de llamadas, ya que al ser la primera experiencia en el uso del SGA Syllabus la mayoría de usuarios no estaban familiarizados con la interfaz ni con las


50

funcionalidades del sistema, y faltaba liberar algunas funcionalidades que aún estaban desarrollándose, al ser una aplicación que trabaja en web requería de algunas configuraciones particulares en el equipo de cada usuario, las personas encargadas de proveer el soporte tenían que tener un conocimiento más profundo sobre las configuraciones y de cada una de las funcionalidades para poder dar una solución eficaz a cada uno de los usuarios que reportaban incidentes.

Como ya se tuvo una primera experiencia y se determinaron algunas de las deficiencias del soporte, para los siguientes períodos de matrículas se definió un esquema de soporte para el proceso de matrículas que involucraba a más grupos de usuarios relacionados en el proceso de matrículas.

2.6.5 Esquema de soporte para el proceso de matrículas

Con la experiencia adquirida en los períodos anteriores de matrículas, el nivel de soporte se estructuró de manera que implique otros grupos de soporte, es así como se muestra un detalle de los procesos que abarcaba cada uno de los niveles y los grupos responsables de ayudar a solucionar los incidentes reportados:

Tabla 2.5. Detalle de las categorías de soporte definidas

# Aspecto Descripción Dependencia

1 Académico

Aspectos propios de las escuelas y profesores, se consideran: notas, convalidaciones, exámenes de ubicación, autorizaciones académicas, y otros procesos académicos.

Coordinación Académica y respaldado por las Escuelas (Directores, Secretarias, Profesores)

2 Contable

Relacionado con deudas, papeletas de depósito, saldos a favor, cobros no realizados, autorizaciones económicas, reactivaciones de matrícula.

Departamento de Contabilidad, Personal de soporte de BAAN

3 Procesos

Manejo de cambios o autorizaciones en los procesos normales como: gestión de pagos en bancos, fechas de matrículas, nuevos convenios, cambios convenios, comunicaciones, autorizaciones globales, problemas con definiciones, etc.

Unidad de Procesos y Departamento de Atención al Estudiante.

4 Sistema Dificultad y desconocimiento en la operación de funcionalidades, mensajes de error, interpretación de resultados.

Proyecto Phantom (actualmente Syllabus) (User Experience)


51

5 Tecnológico Problemas con funcionamiento de equipos, de la red, impresoras.

Proyecto Phantom (Release Management), además de Departamento de Soporte Técnico y Grupo de Redes.

Éste proceso incluía la distribución del personal responsable de dar la solución a los incidentes reportados en un horario establecido y con un nivel apoyo superior para los casos que no podían resolverse en el nivel anterior.

El esquema de soporte definido en la Tabla 2.5 duró aproximadamente 1 año ya que por los constantes cambios en la aplicación y las actividades asignadas a cada uno de los miembros de los grupos de soporte no se logro continuar con el proceso detallado anteriormente, estos cambios han provocado que se recurran a establecer nuevos esquemas informales de soporte para la gestión de incidentes reportados por los usuarios. Para ver más a detalle el proceso definido vaya al ANEXO [B] en la sección de Anexos.

Actualmente no se lleva ningún proceso definido para el proceso de matrícula, a continuación se detalla el proceso actual que se maneja.

2.6.6 Proceso actual para el manejo de incidentes en el GDS

A lo largo de estos 3 años de experiencia en el soporte del SGA Syllabus se ha trabajado con varios esquemas de soporte para la gestión de incidentes, es así que cuando arrancó el proyecto del SGA Phantom (actualmente Syllabus), el equipo de User Experience y algunos miembros de las diferentes áreas del GDS eran los encargados de apoyar al usuario; por ser un sistema nuevo y que se encontraba en desarrollo de nuevas funcionalidades requeridas para apoyar las tareas de los usuarios. A continuación se mencionan algunos inconvenientes que frecuentemente los usuarios presentaban al momento de hacer uso del nuevo sistema:

• Resistencia de parte del usuario al utilizar el nuevo sistema.

• Confusión por parte de los usuarios en funcionalidad y operación del nuevo sistema.

• Datos incompletos en la base de datos heredados desde los sistemas antiguos por problemas de migración de datos y que los usuarios acusaban al nuevo sistema.

• Características no existentes en los sistemas antiguos que se implementaron en el nuevo sistema y que saltaron en la implantación sintiéndose afectados los usuarios más numerosos del sistema como son los estudiantes; hablemos del caso de deudas pasadas ya incobrables para la Universidad y que con esta nueva característica en el sistema se pudo efectuar recuperación de cartera, ya que si el estudiante no pagaba deudas pasadas no podía registrarse su matrícula en el nuevo sistema académico.


52

• Errores en las funcionalidades del nuevo sistema.

• Requerimientos no contemplados en el nuevo sistema, pero que son vitales en el negocio o proceso académico de la Universidad.

• Requerimientos nuevos que toman tiempo para su implementación.

• Desconocimiento de los procesos académicos por parte de los usuarios, y que algunos de esos procesos ya se habían implementado en el sistema. Incluso desconocimiento de las personas responsables de dichos procesos.

• Falta de algún proceso académico que se requería y que no estaba establecido por parte de la universidad, ya que tenían que definir como registrarlo en el nuevo sistema académico.

• Análisis deficiente del incidente presentado.

• Incidentes producidos por problemas técnicos en la infraestructura sobre la que está implantado el sistema, y que afectan a su normal funcionamiento.

• Problemas con la interacción con otros sistemas con los que se relaciona, como: Sistema Financiero BAAN, Sistema de Distribución de Material CEDIB, Sistema de Recursos Humanos, entre otros.

Al ser un sistema nuevo los usuarios reportaban constantemente los mismos incidentes incluso pudiendo solucionarlos directamente en el sistema o a través de algún trámite administrativo de su responsabilidad. Además como observamos en la lista de aspectos que motivaban a los usuarios a solicitar soporte, algunos casos escapan de la implantación del nuevo sistema, pero se reportaban recurrentemente. Con el transcurso del tiempo, la experiencia del usuario, capacitación permanente y personalizada, capacitación de procesos académicos, motivación institucional al uso de las nuevas herramientas de trabajo frente a sus objetivos institucionales, entre otros; el número de peticiones de servicio de soporte se han visto disminuidas.

El volumen de soporte ha bajado en forma considerable, y las razones actuales de petición de servicios que tienen mayor frecuencia son las siguientes:

Originados por la funcionalidad del sistema:

• Errores en las funcionalidades, provocadas por el desarrollo y/o modificación de funcionalidades en el sistema.

• Problemas en usuarios y contraseñas.

Problemas de usuario final:

• Análisis deficiente del incidente presentado.

• Usuarios nuevos en un rol, y deficiente capacitación en sus nuevas funciones.


53

• Deficiente conocimiento/dominio en funcionalidades existentes y/o nuevas.

• Deficiente actualización del usuario frente a las nuevas tecnologías.

Originados por la Infraestructura:

• Incidentes producidos por problemas técnicos en la infraestructura sobre la que está implantado el sistema, y que afectan a su normal funcionamiento.

• Problemas con la interacción con otros sistemas con los que se relaciona, como: Sistema Financiero BAAN, Sistema de Distribución de Material CEDIB, Sistema de Recursos Humanos, entre otros.

A pesar de que se han definido algunas estructuras para soportar las peticiones de servicio en el GDS, el proceso de la gestión de incidentes se ha visto afectado por:

• Incumplimiento del proceso de gestión de incidentes por parte de los usuarios.

• Incoherencia con el proceso por parte de los miembros de las áreas del GDS, que asumen atribuciones que no les corresponden, como es el soporte al usuario.

Actualmente algunos usuarios aún siguen contactándose con los miembros de los otros equipos del GDS, lo que provoca retardo en el cumplimiento de tareas asignadas, o se reporta el mismo incidente a varias personas que hace que se desperdicien recursos.

Figura 2.13. Estado actual de la gestión de incidentes


54

Se procede a describir los pasos que se lleva en el GDS cuando el usuario reporta un incidente producido al trabajar con el SGA Syllabus:

• El usuario del SGA Syllabus llama a reportar ya sea por: mail, oficios, telefónicamente o a través del Messenger sobre el detalle del incidente sucedido a los miembros generalmente de los grupos de User Experience, Release y QA.

• Si el incidente es de consulta o sobre el uso de alguna funcionalidad, es registrado en un archivo de Excel en el computador del miembro de User Experience.

• Si éste tiene la solución informa inmediatamente al usuario y se cierra el incidente.

• Caso contrario el caso es transferido a otro miembro del equipo de Release o QA, quienes evalúan el incidente y si puede resolverse informan al usuario su solución.

• Si los miembros de los equipos anteriores no pueden dar solución al incidente, éste pasa a algún miembro del equipo de Desarrollo para que evalúe la causa del incidente.

• Si es solucionado se informa al grupo de User Experience para que comunique la solución al usuario y se cierra el incidente.

• Si el incidente se convierte en un problema el arquitecto de software analiza la solución, luego de implementado el cambio se realizan las pruebas respectivas para confirmar que se soluciono el incidente.

• Finalmente se comunica a uno de los miembros del grupo responsable del caso o directamente al usuario y finalmente se cierra el incidente.

A partir de abril del 2007 se empezó a llevar un registro más minucioso de los incidentes reportados por cada uno de los usuarios, con ésta información se pudo determinar con mayor detalle los procesos y las funcionalidades que provocan más inconveniente en cuanto a su uso. Se muestra un resumen de los incidentes más frecuentes.

2.6.7 Resumen de Incidentes

Se muestra un gráfico que resume el soporte provisto en los períodos académicos Oct07-Feb08 y Ab-Ag08, para obtener la gráfica la información se obtuvo de registros en hojas de Excel y se consideraron las principales funcionalidades sobre las que se brindo soporte:


55

Registro de Incidentes por período académico

1 6 8

96

13

95

38

63

12 114 6 7

129

10

121

5

113

41

110

20

40

60

80

100

120

140

Actualización en BBDD

Convalidaciones

Facturación de Derechos

Gestión Académica

Gestión Financiera

Matriculación

Migración de Notas

Parametrización

Reportes

Servicios Online al Profesor

Sitio Online a los Centros

Ab‐Ag 2008

Oct07‐Feb08

Figura 2.14. Gráfica del soporte de incidentes por funcionalidad

Como se muestra en la Figura 2.14 que recoge en resumen el soporte proporcionado en los dos últimos periodos académicos, se puede ver el volumen de incidentes por funcionalidad reportados por los usuarios, los mismos que son resueltos principalmente por miembros del grupo de User Experience y de Release Management. Generalmente el volumen de soporte crece en los procesos críticos para la UTPL como son: matriculas, ingreso de notas, carga de evaluaciones, evaluación al docente, solicitud de matrícula en línea, lo que provoca que el personal de los grupos de User Experience y de Release Management no sea suficiente para abastecer el soporte requerido por todos los usuarios que lo solicitan, lo que provoca que miembros de otros grupos como QA y los desarrolladores ayuden a recoger incidentes y darles solución. Puede apoyarse viendo el ANEXO [C].

2.7 Propuesta para implementar el Centro de Servicio en el GDS

Para empezar con la implantación del Centro de Servicio en el GDS se debe:

• Definir el tipo de estructura del Centro de Servicio con el que va a trabajar el GDS.

• Elaborar el Acuerdo de Nivel de Servicio entre el proveedor del servicio y el cliente.

• Definir el proceso para la gestión de incidentes, problemas y cambios.


56

2.7.1 Definición del tipo de estructura del Centro de Servicio del GDS

Haciendo referencia al punto 2.1.2 donde se muestra información más a detalle sobre los tipos de Centro de Servicio, de acuerdo con la estructura y los procesos de negocio con los que cuenta la UTPL, se va a utilizar la estructura de Centro de Servicio Central, ya que debe existir un único Centro de Servicio responsable en la matriz Loja encargado de recibir, registrar y resolver los incidentes reportados por los usuarios a nivel local, nacional e internacional, y los departamentos de apoyo con los se va a relacionar son Soporte Técnico y Redes los mismos se encuentran ubicados en una misma localidad.

Figura 2.15. Estructura del Centro de Servicio Central en el GDS

2.7.1.1 Objetivos del Centro de Servicio del GDS

Los objetivos que debe cumplir el Centro de Servicio son:

• Ser el punto de entrada de requerimiento de soporte por parte de los usuarios que utilizan el SGA Syllabus.

• Resolver el mayor número de incidentes posibles en el primer nivel de soporte.

• Gestionar una base de conocimiento que contenga las soluciones a los problemas más frecuentes.

• Conseguir que los incidentes reportados por los usuarios sean cerrados en el tiempo establecido de acuerdo a su prioridad.

• Proporcionar informes a la Dirección sobre el rendimiento del Centro de Servicio.

• Conseguir la satisfacción del usuario en un 70% en relación al proceso de gestión de incidentes propuesto con ayuda de la herramienta para el registro de incidentes.


57

2.7.1.2 Funciones del Centro de Servicio del GDS

Entre las funciones que debe cumplir el personal del Centro de Servicio tenemos:

• Servir de contacto entre el usuario y la gestión de servicios.

• Ser el punto principal de todos los procesos de servicio, donde se manejan todos los servicios que serán provistos a los usuarios del SGA Syllabus.

• Atender quejas y solicitudes de información por parte de los usuarios.

• Permitir el registro y monitorización de incidentes reportados por los diferentes grupos de usuarios mediante medios de comunicación como: oficios, e-mail, teléfono, fax, herramientas de mensajería instantánea como: messenger y skype.

• Aplicar soluciones temporales a errores conocidos, para mitigar en parte la baja calidad del servicio que se produce por incidentes presentados en el SGA Syllabus.

• Elaborar informes y estadísticas sobre los incidentes reportados a cada miembro del Centro de Servicio, apoyando a la Administración.

• Identificar nuevas oportunidades para mejorar el servicio ofrecido a los usuarios.

2.7.1.3 Definición del personal involucrado en el Centro de Servicio GDS

En el Centro de Servicio intervienen varios tipos de usuarios los que deben adquirir y desempeñar diferentes papeles como:

Usuarios: secretarias, personal de contabilidad, coordinadores, estudiantes, docentes de los diferentes centros universitarios, que llaman a reportar los incidentes.

Personal del Centro de Servicio: personal que recepta las llamadas de los usuarios e investiga toda la información referente al incidente, además informa al usuario sobre posible soluciones y los mantiene informados del avance hasta llegar a la solución del incidente reportado en el menor tiempo posible.

Grupos de apoyo: existen algunos grupos con los que la mayoría de veces se tendrá que interactuar como: Soporte Técnico para dar solución a problemas de hardware es decir de los equipos de los usuarios, Redes para solucionar problemas con los enlaces de la intranet y el Internet y Desarrollo de Software como ayuda de 2do nivel donde podemos escalar los incidentes a nivel de datos y fallas en el software, que se tendrán que resolver con ayuda de estos grupos.


58

2.7.1.4 Estructura organizacional del Centro de Servicio

Para brindar el servicio de soporte a los usuarios del SGA Syllabus se ha estructurado un Centro de Soporte cuya organización se detalla en el siguiente diagrama:

Figura 2.16. Estructura organizacional del Centro de Servicio

2.7.1.5 Responsabilidades del personal del Centro de Servicio GDS

Las principales responsabilidades de cada miembro que compone el Centro de Servicio son:

2.7.1.5.1 Administrador del Centro de Servicio

Es el encargado de dirigir, controlar, planificar y tomar decisiones para alcanzar los objetivos del Centro de Servicio.

Entre sus principales funciones están:

• Controlar que el material que utilizan los técnicos sea el correcto y esté actualizado.

• Reunirse con los integrantes del Centro de Servicio por lo menos 1 vez al mes, con el objetivo de evaluar el desempeño de cada miembro y si se están cumpliendo los objetivos del Centro de Servicio o que factores dificultan alcanzarlos.

• Llevar seguimiento de incidentes pendientes con áreas encargadas de dar solución.

• Controlar horas de trabajo, extras, ausencia de los integrantes del Centro de Servicio

• Asignar equitativamente la cantidad de trabajo entre los miembros.

• Seguir las tareas asignadas a cada técnico del Centro de Servicio.

• Contribuir a la elaboración de normas y procedimientos para el Centro de Servicio.

• Promover el marketing del Centro de Servicio.

• Detectar necesidades de capacitación de los miembros.


59

2.7.1.5.2 Técnicos del Centro de Servicio

Las responsabilidades que debe adquirir el personal del Centro de Servicio son:

• Servir como único punto de entrada para receptar las llamadas de los usuarios que soliciten servicios o reporten incidentes.

• Atender las peticiones de servicio por otros medios como: e-mail, fax o chat.

• Registrar en la herramienta de gestión de incidentes el registro inicial del incidente y su solución.

• Realizar el análisis y diagnóstico inicial del incidente reportado.

• Resolver incidentes que puedan ser solucionados en la primera línea de soporte.

• Mantener informado al usuario sobre el avance o solución del incidente reportado.

• Escalar el incidente si no puede ser resuelto en la primera línea de soporte.

2.7.1.5.3 Técnicos de segundo nivel

Las responsabilidades de los técnicos de segundo nivel se detallan a continuación:

• Servir como recurso en el escalamiento del problema.

• Ser responsable del problema reportado.

• Mantener informado al técnico que reporto el incidente.

• Comunicará la solución del problema a los miembros de primer nivel.

• Trabajará con los miembros del siguiente nivel si no puede dar solución al incidente.

2.7.1.5.4 Técnicos de tercer nivel

Las principales responsabilidades de los miembros del tercer nivel son:

• Servir como recurso en el escalamiento del problema.

• Investigar para encontrar la solución al incidente reportado en el menor tiempo posible.

• Trabajar conjuntamente con la Administración para buscar la solución al incidente.

• Registrar con exactitud la solución a los problemas resueltos.

• Mantener informado al técnico que reportó el incidente.

2.7.1.6 Detalle del proceso propuesto para los miembros del Centro de Servicio GDS

El proceso actual que se va a llevar en el Centro de Servicio del GDS se detalla a continuación:


60

Figura 2.17. Proceso propuesto para los miembros del Centro de Servicio GDS

• Los usuarios del SGA Syllabus ya sean coordinadores o secretarias de los diferentes centros universitarios, estudiantes o docentes llaman a reportar sobre el incidente producido a los miembros del Centro de Servicio, por medio de: e-mail, oficio, teléfono o herramientas de mensajería. Si el servicio solicitado está dentro del SLA se provee ayuda a lo requerido por el usuario, que puede ser una solicitud de servicio o una petición de información.

• El personal del Centro de Servicio debe obtener toda la información posible sobre el incidente y los datos del usuario que lo reporta.

• El personal del Centro de Servicio debe registrar el incidente con ayuda de la herramienta de registro automático de incidentes.

• Determinar la prioridad del incidente.

• Si el incidente no puede ser resuelto en la primera línea de soporte, debe escalar el incidente a otro nivel de soporte quienes evalúan el incidente.

• Si se pudo resolver el incidente se informa al personal del Centro de Servicio para que comunique al usuario la solución encontrada.

• El personal del Centro de Servicio comunica la solución al usuario que lo reportó y confirma que el incidente ha sido solucionado.

• Finalmente registra la solución encontrada en la herramienta de registro automático y cierra el incidente.

El Centro de Servicio también se apoya con otros grupos como Redes y Soporte Técnico, ya que algunos de los incidentes pueden originarse por errores en la red o por problemas en los


61

equipos de los usuarios, y con la ayuda de estos dos grupos se puede dar solución a algunos de los incidentes reportados.

2.7.1.7 Métricas para determinar el rendimiento del Centro de Servicio GDS

Entre las métricas a obtener por el Centro de Servicio están:

• Número de casos solucionados en el tiempo máximo establecido de acuerdo a la prioridad del incidente.

• Número de incidentes resueltos por cada técnico.

• Total de casos registrados por cada técnico del Centro de Servicio.

• Número de casos reportados por cada usuario del SGA Syllabus.

• Casos registrados por categorías.

• Satisfacción del usuario frente a la herramienta.

2.7.1.8 Aptitudes del personal del Centro de Servicio GDS

Entre las aptitudes o destrezas que el personal del Centro de Servicio del GDS debe adquirir se detalla a continuación: [Foro-Help]

Para los técnicos de primera, segunda y tercera línea de soporte.

Personales:

• Estar alineado con la misión y visión de la UTPL.

• Ser servicial con el usuario, iniciar una comunicación amable y con educación hacia el usuario.

• Tener capacidad de trabajar en equipo.

• Utilizar un lenguaje no técnico con el usuario, de manera que él pueda entender en términos claros la solución del incidente.

• Ser responsable y tener iniciativas personales, logrando calidad en el trabajo y ser responsable de su propio aprendizaje.

• Tener capacidad de adaptabilidad a nuevos cambios, nuevos procedimientos y retos de la organización.

• Establecer relaciones profesionales armoniosas con el resto del personal del Centro de Servicio.

• Ser proactivo, debe ser capaz de tomar la iniciativa para dar soluciones a los incidentes y en lo posible prevenir las fallas antes de que sucedan.


62

Técnicas:

• Conocer a profundidad los servicios ofrecidos por el GDS.


• Manejar las herramientas tecnológicas utilizadas en el Centro de Servicio necesarias para la solución de incidentes.

• Aprender a escuchar, el personal del Centro de Servicio a más de ser un buen comunicador debe ser un oyente activo, lo que le permitirá comprender la situación desde el punto de vista del usuario.

• Ser creativo para resolver problemas, el técnico debe investigar, analizar y seleccionar la mejor solución y aplicarla para dar solución al incidente reportado, además de identificar problemas y buscar soluciones racionales.

• Tener aptitud técnica, debe poseer un profundo conocimiento de las características y funcionamiento de la aplicación que maneja y del equipo que la soporta.

Para el Administrador del Centro de Servicio

Personales:

• Tener aptitudes de liderazgo.

• Fortalecer la relación interna entre los miembros del Centro de Servicio.

• Demostrar capacidades de comunicación positiva entre usuarios, personal del Cetro de Servicio, y otros miembros.

Técnicas:

• Ser responsable de capacitaciones y motivación de los integrantes del Centro de Servicio.


• Desarrollar juicio y criterio para usar estrategias apropiadas para alcanzar los objetivos de la organización.

2.7.1.9 Evaluación del desempeño de los técnicos del Centro de Servicio GDS

Para evaluar el desempeño del personal que compone el Centro de Servicio puede considerar los siguientes criterios: [Foro-Help]

Tabla 2.6. Elementos de evaluación del desempeño de los técnicos


63

Elementos de evaluación Importancia

Velocidad de atención de las llamadas

Contribuye a la liberación de llamadas e incide en la percepción del usuario sobre el nivel de respuesta del Centro de Servicio.

Capacidad de resolución Incide en el porcentaje de resolución en el primer contacto, loque minimiza pasar incidentes a otros niveles de soporte.

Volumen de trabajo La cantidad de incidentes atendidos por cada técnico serádeterminado por su horario de trabajo, debe buscarse una reglade medición compatible con cualquier técnico.

Capacidad de diagnóstico Si el técnico determina que la solución está o no dentro de sus posibilidades permitirá ahorrar tiempo, este elemento se veráreflejado en la duración promedio de llamadas.

Duración promedio de llamadas

Las llamadas cortas se suponen son más eficientes que las largas, en cualquier caso se determina un tiempo máximo de resolución previo al escalamiento del incidente.

2.7.1.10 Actividades de inducción al nuevo personal del Centro de Servicio

Todo personal que formará parte de la estructura funcional del Centro de Servicio debe recibir capacitación acerca del hardware/software sobre el que se provee el servicio. Entre algunas actividades a considerar se detallan:

• Introducción a la misión, visión objetivos y valores de la UTPL.

• Revisión de la misión y objetivos del Centro de Servicio.

• Revisión de acuerdos de niveles de servicio existentes.

• Estudio de procedimientos específicos para la gestión de incidentes.

• Capacitación sobre servicios que serán provistos a los usuarios del SGA Syllabus.

• Entrenamiento sobre las tecnologías de TI que maneja el Centro de Servicio.

• Realizar actividades de soporte bajo supervisión de un técnico con más experiencia.

• Desarrollo de habilidades de comunicación con el usuario.

2.7.1.11 Consideraciones para la selección de herramientas de soporte

A medida que se incrementan las tecnologías de información, las empresas se ven en la necesidad de adquirir una herramienta que apoye la optimización de los procesos, por ello al adquirir herramientas para la implementación de procesos ITIL se debe considerar algunos puntos como: [Foro-Help]

• Seguridad en el manejo de datos.

• Posibilidad de monitorear el estado de los incidentes.


64

• Escalabilidad.

• Usabilidad, interfaces amigables al usuario.

• Respaldo de datos.

• Integrar herramientas de otros proveedores y poder agregar nuevos componentes.

La necesidad de adquirir una herramienta se da por algunas razones como:

• El negocio depende cada vez más de los servicios de TI.

• Incremento de la complejidad de la infraestructura de TI.

• Mejorar el servicio al cliente.

• Costo de licencias, capacitación y mantenimiento de la herramienta.

• Obtención de reportes de la aplicabilidad del proceso por parte de la Administración.

2.7.2 Desarrollo del SLA para el Centro de Servicio

En este documento se puntualizará el alcance, los servicios que serán provistos y los que no se contemplarán, las responsabilidades de las partes involucradas como son el usuario (usuarios del Sistema de Gestión Académica) y el proveedor en este caso el Centro de Servicio del GDS.

2.7.2.1 Contenido del SLA

Entre los aspectos que debe incluir el acuerdo establecido entre el proveedor del servicio y el usuario se listan:

• Descripción de quienes establecen el acuerdo.

Académica:

Modalidad Clásica: Dr. José Barbosa Vicecanciller

Dr. Roberto Beltrán Director General Académico

Modalidad Abierta: Dra. María José Rubio Directora Modalidad Abierta y a Distancia

Financiera:

Dr. Ramiro Cárdenas y Econ. Ramiro Armijos


65

• El período cubierto por el acuerdo.

El acuerdo establecido entre el Centro de Servicio del GDS y los usuarios del SGA Syllabus de la UTPL cubre hasta que existan algunas modificaciones en el servicio provisto y se requiera realizar cambios en el acuerdo establecido.

• Las mejores prácticas a utilizar.

El Centro de Servicio básicamente está enfocado en la solución de incidentes reportados por usuarios del SGA Syllabus, por ello algunas de las “mejores prácticas” consideradas, nos ayudarán a proveer los servicios establecidos en el SLA.

• Los servicios que serán provistos por el Centro de Servicio.

Entre los principales servicios que serán provistos por el Centro de Servicio están:

Proveer de soluciones a los incidentes. Asesoría en la instalación, configuración del hardware y del software estándar

involucrado en la operación del SGA SYLLABUS. Guiar en la utilización de las diferentes funcionalidades del SGA SYLLABUS. Proveer información digital e impresa de las funcionalidades del SGA

SYLLABUS requeridas por el usuario.

• Los servicios no cubiertos.

Entre los servicios que no serán provistos están:

Problemas con el hardware y el software no contemplados en éste acuerdo. Proveer información a usuarios externos sobre los productos o procesos

llevados en la UTPL. Soporte a los usuarios fuera del horario de trabajo y de actividades

relacionadas con la UTPL. Servicios en el lugar. Instalación y configuración de herramientas que no influyen en el

funcionamiento del SGA Syllabus.

• El horario de operaciones normales y el servicio opcional fuera del horario.

Tabla 2.7. Horario de prestación de servicio

Servicio Diario Semanal

Centro de Servicio 08:00 a 13:00 horas y15:30 a 18:30 horas

De lunes a viernes


66

• Como los clientes pueden acceder al servicio.

El Centro de Servicio debe ser identificado como el primer punto de contacto y no como un grupo apartado al que se contacta como último recurso, las formas de reportar incidentes y problemas básicamente son dos:

Escrita (faxes, correo-e, página en intranet o internet, herramienta automática, comunicados, msn) y

Verbal (por teléfono o en forma directa en el lugar), está siempre tiene que estar respaldada de información por escrito para evitar confusiones en la petición de requerimientos.

• Definición de las prioridades de las llamadas y los tiempos de respuesta requeridos.

Determinar prioridades permite asignar la cantidad adecuada de recursos al problema según sea el impacto en la operación normal del SGA Syllabus.

• Los estándares de desempeño que el servicio debe alcanzar.

Se deben establecer objetivos medibles entre los que se espera obtener tenemos:

Se debe lograr cerrar el 80% de los incidentes reportados por los usuarios en el primer nivel de contacto.

Disminuir el número de incidentes reincidentes. Al realizar una evaluación interna del servicio, se espera lograr obtener una

calificación de 4 en una escala de 1-5.

• Los reportes que deberán ser generados por el Centro de Servicio.

Los reportes que deben ser emitidos por un responsable del Centro de Servicio son:

Total de llamadas y su desglose porcentual por tipo, como: llamadas por solicitud de servicio o quejas, reporte de incidentes.

Tiempo de respuesta promedio de la llamada. Porcentaje de llamadas reincidentes en cada mes. Resultados de encuestas sobre la calidad del servicio entregado al final de

cada período académico.

• Los elementos informáticos soportados.

Sistema administrador de registro de incidentes del centro de servicio.


67

El correo electrónico. Configuración en todas las computadoras del personal de la UTPL que

interactúa con el SGA Syllabus.

• Las políticas del servicio.

Para que un Centro de Servicio funcione correctamente debe definir políticas claras y comunicarlas a todos los interesados (usuarios, personal, empresa), las políticas son normas que rigen diversos aspectos del servicio, y aplican para todos los que de él se benefician o participan; cubren el cuándo, el dónde, y el cómo acceder a los servicios.

Para ver más a detalle cada punto que contiene el SLA están descritos en el ANEXO [A].

2.7.3 Propuesta para la gestión de Incidentes en el GDS

Conocida la problemática en el proceso de soporte al SGA Syllabus se procede a especificar el proceso definido para facilitar la gestión de incidentes en el GDS.

Al decidir crear el Centro de Servicio para el usuario, se lo hizo con la finalidad de atender las necesidades de los clientes, para que todo se canalice a través de un único punto de contacto y que el usuario tenga una visión clara a quien tiene que dirigirse el momento en que sucede un incidente, lo que permitió:

• Definir los niveles de escalado para los casos requeridos.

• Establecer tiempos de resolución para cada incidente de acuerdo a la prioridad asignada.

• Definir tipos de incidentes más comunes.

• Establecer el proceso para el tratamiento de los incidentes.

• Proceso a llevar en cada fase del ciclo de vida de un incidente.

En esta fase es importante:

• Aprovechar el capital intelectual con el que cuenta la organización.

• Proveer respuestas consistentes a los usuarios.

• Contar con una Base de Conocimiento centralizada para compartir la información con el equipo de técnicos, ya que servirá como un método de inducción en el caso de que se incluya un nuevo técnico, y éste tenga una visión clara del proceso llevado.


68

La Gestión de Incidentes será la responsable de conseguir una solución al incidente reportado y minimizar en lo posible la interrupción en los procesos del negocio. El proceso definido debe permitir resolver la mayor parte de incidentes en el primer nivel de soporte y ser escalado a los otros niveles de soporte solo en casos muy necesarios.

2.7.3.1 Definir niveles de escalado

Es conveniente realizar la definición y creación de los niveles de soporte, los que permite escalar a especialistas de otros niveles para encontrar la solución al incidente, los mismos que están conformados por miembros de los grupos del GDS.

Figura 2.18. Definición de niveles de escalado

2.7.3.2 Descripción de los niveles de escalado

• Nivel 1: se encuentran los miembros del grupo de User Experience quienes son los que dan la cara al usuario y sirven como punto único de contacto entre el usuario y la organización.

• Nivel 2: está conformado por miembros del equipo de Release Management y QA, quienes son los que están más relacionados con los aspectos técnicos y de configuraciones de la aplicación.

• Nivel 3: están involucrados los desarrolladores y el arquitecto de software quienes buscarán más a detalle la causa del incidente suscitado.

• Nivel 4: están involucrados personal del nivel directivo, quienes darán definiciones para dar solución a los incidentes reportados.

2.7.3.3 Determinar nivel de prioridad para el incidente

De acuerdo a la naturaleza de la UTPL, hay temporadas críticas donde se tiene que atender y resolver múltiples incidentes al mismo tiempo, lo que obliga a definir prioridades para la atención de cada incidente ya que no se pueden resolver todos a la vez.


69

Es importante asignar a cada incidente una prioridad la misma que indica si el incidente es grave o leve y en que magnitud puede afectar a los procesos del negocio.

2.7.3.3.1 Sistema de Prioridades

El sistema de prioridad es una tabla que permite relacionar el impacto y la urgencia de cada incidente.

Figura 2.19. Sistema de prioridades

2.7.3.3.2 Tiempos de solución a las prioridades

Una vez que se ha determinado el impacto es necesario asignar tiempos de resolución a las prioridades, los que se describen en la Tabla 2.8:

Tabla 2.8. Asignación tiempos de solución

Tiempo Prioridad Detalle

1 – 15 minutos 1 Crítico

16 – 60 minutos 2 Alto

1 hora – 24 horas 3 Medio

24 horas – 48 horas 4 Bajo

Planeando 5 Planeando

Se detalla el nivel de prioridad:

Prioridad 1 (Crítico-Componente fuera de servicio).- se trata de un problema que afecta a varios usuarios, o a un solo cliente muy importante. Estos problemas pueden derivarse por la falla en el enlace de comunicación puede estar roto o en mal estado, servidores fuera de servicio, caída de la red o de la base de datos, corte generalizado de energía, seguridad violada, invasión de virus, etc.

Prioridad 2 (Alto- Componente degradado).- Un problema que afecta a múltiples usuarios, o a un usuario importante, pero existe un modo alterno de seguir prestando un servicio equivalente o degradado. Estos problemas pueden derivarse de fallas de energía aisladas, tiempos lentos de respuesta de la aplicación por múltiples conexiones a la base de datos, la conexión a Internet está lenta.


70

Prioridad 3 (Medio-Importante).- Problema que afecta a un solo usuario, por fallas técnicas en el equipo del usuario, dudas en el funcionamiento de operación de la aplicación o necesidad de configuración del navegador donde funciona la aplicación.

Prioridad 4 (Informativo).- Necesidad de información o servicio, no hay nada que arreglar.

Prioridad 5 (Planeado).- petición de requerimiento que debe ser analizado y planeado para una futura implementación del requerimiento.

2.7.3.4 Identificación de Tipos de incidentes frecuentes

Entre los tipos de incidentes más comunes de detallan:

Tabla 2.9. Tipos de incidentes frecuentes

Software Detalle

Aplicación el sistema está caído Caída del servidor de datos

Configuración de las herramientascon las que interactúa el usuario

Configuración del Internet Explorer

Problemas con la red de la UTPL La conexión a la Red está lenta

Hardware Detalle

Problemas en los equipos de losusuarios

Problemas de virus o en alguno de los dispositivos del computador como impresoras, discos, etc.

Datos Detalle

Olvido de contraseña Olvido contraseña para acceder a la aplicación

Quejas, reclamos o sugerencias delos usuarios

Atención de quejas, reclamos o sugerencias de los usuarios

Generación automática de alerta desde el sistema

Mensajes de alerta o advertencia por alguna acción ejecutada o dato incorrecto ingresado

Proceso no ejecutado Fallas en la ejecución de algún proceso

2.7.3.5 Proceso definido para la gestión de incidentes GDS

Se detallan los pasos requeridos para el manejo de incidente desde su registro hasta llegar al cierre del incidente reportados al Centro de Servicio del GDS, mostrado en la Figura 2.20.


71

Figura 2.20. Proceso definido para la Gestión de Incidentes

Tabla 2.10. Detalle del proceso para la gestión de incidentes

Subproceso Empieza Termina

Registrar y clasificar

El usuario solicita un servicio

Personal del Centro de Servicio recepta petición, la registra y clasifica de acuerdo al tipo de incidente reportado.

Investigar El grupo de soporte investigasolución del incidente

Se conoce solución al incidente reportado por el usuario.

Resolver Se explica al cliente la solución encontrada o se escala al nivel superior si no puede resolverse.

Encontrada la solución se explica solución del incidente al usuario.


72

Cerrar incidente

Se verifica con el cliente que elincidente haya sido resuelto

El usuario acepta solución y expresa que ya no requiere más ayuda del Centro de Servicio

2.7.3.6 Detalle del proceso definido en cada fase de la gestión de incidentes

Cuando el usuario llama por algún incidente presentado, el equipo de soporte debe recibir una clara definición de su necesidad, si el usuario no puede dar una explicación exacta del inconveniente presentado, se debe ir indagando con el usuario hasta obtener una definición clara del incidente.

Registro y Clasificación

Éste es el primer paso a realizar cuando el usuario comunica algún malfuncionamiento en alguna de las funcionalidades del SGA Syllabus o en algún componente de infraestructura física, o solicita información al personal del Centro de Servicio del GDS, es muy importante el registro de cada incidente ya que de éste proceso depende el obtener la mayor cantidad de información posible acerca del incidente, lo que permitirá tener claro el incidente presentado al usuario y dar la solución más efectiva.

Se detalla el proceso a seguir:

• Asignar un número específico para cada incidente reportado.

• Detalle de información básica del incidente como: fecha de registro, detalle del incidente, funcionalidad afectada.

• Datos del usuario que reporta como: número de extensión, área de trabajo, departamento, etc.

• Asignar estado: abierto, escalado, reportado, etc.

• Asignar categoría dependiendo del tipo de incidente originado.

• Información de apoyo: que incluye información relevante para solucionar el incidente, la misma que puede ser solicitada al usuario a través de un formulario o ser obtenida de otras fuentes.

• Monitorizar estado y tiempo de respuesta esperado: se debe asociar un estado al incidente como: activo, asignado, ingresado, resuelto, y se debe estimar un tiempo de resolución de acuerdo a la prioridad definida.

Investigación y Diagnóstico

En esta fase se realiza un análisis del incidente para determinar si puede ser resuelto, se debe:


73

• Determinar la prioridad del incidente basada sobre el impacto en el negocio y la urgencia del caso.

• Investigar en la Base de Conocimiento si existe un incidente similar y se puede aplicar el proceso de solución determinado.

• Si no puede ser resuelto en el primer nivel de soporte hay que escalar el incidente a los especialistas de los otros niveles para encontrar la solución del mismo.

Resolución

Cuando se ha encontrado la solución al incidente se debe:

• Contestar solicitud de información por parte del usuario aclarando dudas sobre algún proceso o funcionalidad que no tenga muy clara.

• Añadir el proceso de solución a la Base de Conocimiento, incluyendo: detalles de la solución, nombre del técnico a quien se asignó el incidente, tiempo empleado para cerrar el incidente.

• Reclasificar el incidente si así lo requiere.

Cierre del Incidente

Luego de resuelto el incidente debe cerrarlo, para ello realice lo siguiente:

• Confirmar con el usuario la solución al incidente ya sea mediante una llamada telefónica o a través de un correo electrónico.

• Cerrar el incidente.

Debe haber un monitoreo frecuente del estado de los incidentes, de manera que no queden incidentes abiertos o sin resolver, cada técnico será el responsable directo de cerrar su incidente, caso contrario si se convierte en un problema, aplicar el procedimiento para el tratamiento de problemas con la información mínima requerida.

2.7.4 Propuesta para la Gestión de Problemas

En ésta fase se definirá el proceso para la Gestión de Problemas reportados desde la Gestión de Incidentes, su objetivo principal es reducir al mínimo el impacto que el error pueda causar al proceso normal de trabajo, y prevenir la repetición de incidentes relacionados con el error, para logar esto la Gestión de Problemas es la encargada de encontrar la causa del error y proponer la solución.

En la Gestión de problemas se van a manejar dos conceptos:


74

• Problema: causa aún no identificada de una serie de incidentes significativo.

• Error conocido: es un problema al que se ha encontrado una solución.

2.7.4.1 Procedimiento para la Gestión de Problemas

Cuando un incidente se vuelve recurrente y tiene un alto impacto en la infraestructura de TI, es donde interviene la Gestión de Problemas para determinar las causas y encontrar la posible solución. Los pasos definidos para la Gestión de Problemas se detallan en la Figura 2.21:

Figura 2.21. Proceso de la gestión de problemas

Registro y Clasificación

En este paso requiere que el problema sea notificado y registrado en una Base de Problemas, el proceso a seguir se detalla a continuación:


75

• Identificación del problema: Si el mismo incidente ha ocurrido en repetidas ocasiones y el tiempo de respuesta sobrepasa el tiempo límite para brindar la solución, se busca en la Base de Problemas una solución temporal que se remite a la Gestión de Incidentes, sino se recupera la incidente debe ser tratado como un problema, donde se debe levantar un nuevo registro de problema.

• Datos sobre los elementos afectados debe incluir: elementos implicados, causas del problema, síntomas asociados, soluciones temporales proporcionadas.

• Determinar nivel prioridad como afecta al proceso normal del negocio.

• Asignar estado al problema: abierto, error conocido, cerrado.

Diagnóstico

En este paso lo que se pretende conseguir es determinar la causa del problema y proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto hasta que se implemente la solución que dará solución al problema.

No siempre el origen de un problema es un error de hardware o software, también pueden ser problemas en el aplicativo desarrollado, es conveniente establecer contacto directo con el entorno de desarrollo, para que nos ayuden a determinar las causas de error. Si la solución es encontrada se registra en la Base de Errores Conocidos.

Solución

Una vez analizado el problema y encontrado el error, este se convierte en un error conocido, en esta fase se emite un RFC (Requerimientos de cambios) a la Gestión de Cambios quien es la responsable de la implementación de los cambios propuestos en la infraestructura.

Encontrada la solución se debe realizar una PIR (Revisión post-implementación), se evalúa el impacto del cambio, si los cambios son adecuados se cierra el problema.

2.7.5 Propuesta para la Gestión de Cambios

Una vez que se ha encontrado la solución al problema tratado en la Gestión de Problemas, se levanta un RFC a la Gestión de Cambios quien será la responsable directa de gestionar la implementación del cambio. El proceso a seguir se muestra en la Figura 2.22:


76

Figura 2.22. Proceso de Gestión de Cambios

Registro

Se debe registrar adecuadamente los RFC con información referente a:

• Fecha de recepción.

• Asignar número identificador de RFC (Requerimiento de Cambio).

• Descripción del cambio propuesto: propósito, elementos involucrados.

• Asignar estado al problema.

Este registro debe ser actualizado constantemente para llevar un seguimiento desde su aprobación hasta su evaluación y cierre, debe incluir información referente a: estado, fecha de aceptación, evaluación preliminar del cambio, prioridad y categoría, planes de “back-out”, cronograma, revisión post-implementación, fecha de cierre.


77

Clasificación

Luego de aceptar el RFC (Requerimiento de Cambio) se debe asignar la prioridad y categoría dependiendo de la urgencia y el impacto de la misma sobre el proceso normal de la UTPL, estos dos parámetros permiten determinar:

• Estimación de recursos humanos.

• Plazos previstos para implementar el cambio.

• Nivel de autorización requerido para poder implementar el cambio.

Se debe determinar una tabla con valores de niveles de prioridad, lo que permitirá estimar la complejidad del cambio. Para realizar cualquier cambio en la aplicación debe considerar la prioridad del cambio de acuerdo a los valores de la Tabla 2.11.

Tabla 2.11. Tabla de niveles de prioridad para realizar cambios

Criterios Prioridad Detalle

El cambio es inaplazable ya que está provocando la interrupción o decremento grave del servicio

1 Urgente

El cambio se debe realizar cuanto antes ya que está afectando en la calidad del servicio y a la productividad de la aplicación

2 Alta

Es favorable realizar el cambio, siempre que este no entorpezca algún proceso llevado en la UTPL en períodos críticos

3 Normal

Realizar el cambio cuando se vaya a actualizar algún paquete de software

4 Baja

Planificación y Pruebas

Antes de realizar cualquier cambio en la aplicación es indispensable contar con planes de back-out ya que por cualquier situación que desencadene el cambio, permita la recuperación de la última configuración estable.

Una vez que el cambio es aprobado se debe evaluar como deber ser implementado si individualmente o dentro de un paquete de cambios, esto depende de la prioridad del cambio.

Implementación

Es tarea de la Gestión de Cambios monitorear y coordinar todo el proceso más no el implementar el cambio esto es tarea de la Gestión de Versiones. Debe supervisar el proceso para asegurar:


78

• Se cumplan los tiempos previstos en calendarios y la asignación de recursos es la adecuada.

• El entorno preparado para las pruebas es similar al entorno de producción.

• Están listos los planes de back-out para permitir la recuperación de la última versión en el caso requerido.

Cierre

Es necesario la colaboración del Centro de Soporte para que se encargue de informar a los usuarios del SGA Syllabus sobre los cambios aceptados, para que al momento de implementarlos no les tome por sorpresa y esto genere un nuevo proceso de incidentes fruto de la desinformación de los cambios realizados, luego que el cambio ha sido implementado se procede al cierre del problema este se convierte en un error conocido, debe alimentar la Base de Conocimiento con el detalle de la solución encontrada.

2.8 Relación entre el Centro de Servicio, Gestión de Incidentes, Problemas y Cambios

En el siguiente diagrama mostrado en la Figura 2.23 se quiere detallar la relación existente entre los componentes que se han analizado a través del desarrollo de este proyecto de tesis.

Figura 2.23. Relación entre Centro de Servicio, gestión de incidentes, problemas y cambios


79

Como se muestra en el gráfico existe una estrecha relación entre los componentes, es así que el Centro de Servicio constituye el punto central de todos los procesos de soporte del servicio, ya que se encarga del registro de incidentes y de dar solución a los mismo apoyándose en la Base de Conocimiento, si el incidente persiste se debe investigar las soluciones a errores conocidos a través de la Gestión de Problemas quien es responsable de investigar las causas que provocaron el problema para proponer una posible solución, una vez encontrada la solución se registra en la base de datos de Problemas, si el incidente persiste se debe proponer los cambios a través de las solicitudes de cambio (RFC), las mismas que son llevadas a la Gestión de Cambios quien es la encargada de evaluar el impacto del cambio sobre la infraestructura TI y verificar con la Gestión de Problemas los resultados de la PIR (Revisión post-implementación).

2.9 RESUMEN

Para esta fase fue necesario hacer un estudio sobre la metodología ITIL para la implementación del Centro de Servicio en el Grupo de Desarrollo de Software, como ITIL es una metodología muy flexible que permite utilizar los módulos requeridos por la organización, esto permitió seleccionar los procesos como son: Gestión de Incidentes, Gestión de Problemas, Gestión de Cambios y la función de Service Desk, para adaptarlos al Centro de Servicio.

De acuerdo con la estructura y los procesos de negocio con los que cuenta la UTPL, se adoptó la estructura de Centro de Servicio Central, ya que debe existir un único Centro de Servicio responsable en la matriz Loja, encargado de recibir, registrar y resolver los incidentes reportados por los usuarios a nivel local, nacional e internacional, además puede apoyarse en los departamentos de Soporte Técnico y Redes si se requiere, los cuales se encuentran ubicados en una misma localidad.

Una vez definida la estructura del Centro de Servicio se debe establecer un SLA (Acuerdo de Nivel de Servicio) que es un acuerdo escrito entre el proveedor del servicio y el cliente, en el que se determinan las condiciones que el Centro de Servicio se compromete a cumplir, se especifican los objetivos del servicio a alcanzar, detalle de servicios que serán provistos, los que no se atenderá, y las responsabilidades de cada una de las partes involucradas, de manera que sea un acuerdo beneficioso para ambas partes.

Además se ha definido la infraestructura sobre la que funciona el Sistema de Gestión Académica Syllabus y se preciso sus potenciales usuarios entre los que están: secretarias, coordinadores de centro sede, centros adjuntos, centros provinciales, centros nacionales e internacionales, personal de contabilidad, docentes y estudiantes tanto de modalidad clásica


80

como abierta, a los que se brinda soporte sobre temas relacionados al Sistema de Gestión Académica.

Con la definición de procesos formalizados para la gestión de incidentes se pretende mejorar la atención al usuario a través de la resolución oportuna de incidentes mediante un punto único de contacto quien será el responsable directo de dar solución al incidente reportado, lo que permitirá al GDS conseguir un mayor desempeño en sus tareas, ya que no estará pendiente de tareas adicionales como es el soporte a los usuarios.

Al Centro de Servicio llegan las peticiones de todos los usuarios del SGA Syllabus, para poder proveer un servicio de calidad se requiere que el personal que lo conforma se encuentre, y este presto a cooperar y comprometido con los objetivos que persigue el Centro de Servicio.

El definir procedimientos y políticas para la gestión de incidentes permitirá asegurar que cada incidente recibirá la atención adecuada y la asignación de recursos necesarios para su solución.

Es importante destacar que el Centro de Servicio que se encarga de la administración del soporte a los usuarios debe presionarse fuertemente para optimizar la eficiencia en la atención a los mismos y buscar como implementar las mejores prácticas para alcanzar mayor satisfacción a los usuarios.


81

FASE 3 3 Estudio de Herramientas


82

3.1 Descripción de Herramientas de Help Desk

Llevar actividades de un centro de servicio sin el apoyo de una herramienta de software es una tarea que se convierte en algo incierto y en ocasiones resulta ser una trabajo tedioso para quien está encargado de registrar la información de las llamadas reportadas, pues no se puede tener control de la misma, ni hacer seguimiento, ni obtener indicadores, y al momento de querer elaborar informes y hacerlo de forma manual implica mucho tiempo y los resultados no son inmediatos.

Existe una gran variedad de herramientas en el mercado que permiten manejar temas de helpdesk, encontrar una herramienta que se adapte completamente a las necesidades del negocio no es tarea sencilla, ya que cada una tiene características diferentes y razón por la cual se debe evaluar el funcionamiento de algunas de estas herramientas que mejor se adapte a las necesidades de la organización y encontrar la herramienta adecuada.

A continuación se muestra un detalle de las tres herramientas evaluadas para el centro de servicios del GDS:

• OneOrZero

• SysAidServer

• ManageEngine ServiceDesk

A estas herramientas se las instaló, evaluó y probó en un ambiente de pruebas, donde se pudo establecer sus características y funcionalidades principales, considerando criterios de evaluación como en criterios como: agilidad en el registro de incidentes, facilidad de uso, permita el seguimiento del ciclo de vida de un incidente, entre otras.

3.1.1 OneOrZero

Es una herramienta gratuita de acceso vía web que permite el registro de incidentes para empresas con pequeños o grandes grupos de usuarios, es de acceso rápido, prácticamente funciona sobre cualquier plataforma, es de código abierto y puede ser personalizada de acuerdo a los requerimiento de la organización que la adquiere.


83

Figura 3.1. Página principal herramienta OneOrZero

3.1.1.1 Funcionalidades

• Opciones de Caso: permite crear casos, buscarlos y administrar casos con estado abierto, cerrado, no asignado, recientes y por grupos.

• Contactos: permite la fácil búsqueda de contactos requeridos.

• Preguntas Frecuentes: permite la creación y el manejo de preguntas las que sirven para alimentar la Base de Conocimiento.

• Documentación de Usuario: contiene toda la información sobre el uso de la herramienta

• Agregar Anuncio: permite enviar anuncios a usuarios específicos o a grupos de usuarios.

• Reportes: permite la generación de reportes prediseñados en relación a la información de los incidentes reportados en la herramienta.

3.1.1.2 Aspectos Técnicos:

• Sistema Operativo: Linux o Windows

• Tecnología: PHP 4.0 o superior

• Base de Datos: MySQL v4.1 o superior

• Servidor Web: Apache


84

3.1.2 SysAidServer

Es un software comercial fácil y sencillo de utilizar, es de acceso vía web, es multiplataforma, se encarga de automatizar el manejo de los servicios de llamadas para reducir el tiempo de respuesta y mejorar el servicio, permite la configuración del hardware, las licencias de software, permite el control del equipo del usuario en forma remota para resolver incidentes, tiene una interfaz intuitiva que permite manejar datos de usuarios, historial de peticiones y el inventario de hardware y software, además la herramienta es personalizable.

Figura 3.2. Página principal herramienta SysAid


• Software Help Desk basado en Web: permite registrar solicitudes de servicio, asignación de tareas a usuarios, cambiar prioridad o fecha de finalización. Las peticiones pueden ser colocadas en una base de Conocimiento a la que se puede acceder fácilmente.

• Gestión de Activos: permite el seguimiento y administración del software y hardware y guardar en un servidor todos los cambios que pueden existir, pueden controlar remotamente las máquinas de los usuarios.

• Monitorización: se puede monitorizar los recursos de la red para prevenir la caída del sistema, si esto ocurre se notifica mediante e-mail, incluso SMS, permite visualizar datos en forma gráfica.

• Informes y Análisis: permite generar informes de las actividades del Help Desk y calidad del servicio.

• Manager portal: permite programar, personalizar y modificar informes de acuerdo a sus necesidades.


85

• Gestión de Proyectos y Tareas: permite crear, listar y gestionar proyectos.

• SysAid CMDB: guarda registros de elementos significativos de TI de acuerdo al estándar ITIL.

3.1.2.2 Aspectos Técnicos

• Sistema Operativo: Linux/UNIX o Windows: NT, XP, 2003, Vista

• Tecnología: Java 1.5 o superior

• Base de Datos: My SQL

• Navegador: IE v5 o superior, Netscape v6 o superior o Firefox v2 o superior.

3.1.3 ManageEngine ServiceDesk

Es un software comercial, se accede a través de la web, es multiplataforma, permite administración de activos y el registro, evaluación, solución y cierre de peticiones generadas por los usuarios por el uso de los recursos de tecnología de información, además permite personalizar la herramienta de acuerdo a los requerimientos del centro de servicio.

Figura 3.3 Página Principal herramienta ManageEngine ServiceDesk


• Solicitudes: a este modulo llegan todas la solicitudes de servicio de los usuarios, permite añadir datos relevantes de la petición que está siendo manejada, y el detalle de la solución. Si el incidente fue resulte puede almacenarse en un historial de peticiones.

• Soluciones: en este modulo se encuentra la Base de Conocimiento de soluciones, se puede asignar privilegios de acceso a varios técnicos para la sección de soluciones.


86

• Admin: se puede realizar todos los tipos de configuraciones para la personalización de la herramienta, para poder acceder a este modulo es necesario que se conecte con un usuario administrador.

• Informes: permite generar informes con los datos registrados en la herramienta.

• Soporte: aquí encuentra los medios por donde puede solicitar ayuda en caso requerido e intercambiar ideas con otros usuarios de centro de servicio.

3.1.3.2 Aspectos Técnicos

• Sistema Operativo: Solaris 8, Win NT o Red Hat Linux 7.1

• Tecnología: Java 1.5 o superior

• Base de Datos: My SQL

• Navegador: IE v6 o superior, Netscape v4.76 o Firefox v2 o superior.

3.2 Comparación entre las herramientas

Luego de haber instalado y realizado pruebas con las tres herramientas seleccionadas, se procedió a elaborar un análisis comparativo entre las características que debe cumplir la herramienta, el mismo que permitió seleccionar la herramienta que se utilizará en el Centro de Servicios del GDS para el registro, resolución y cierre de los incidentes reportados.

Tabla 3.1. Detalle de las características a evaluar para selección de la herramienta

CRITERIOS DESCRIPCIÓN

Fácil e intuitivo de usar La herramienta debe ser fácil de aprender

Ágil en el registro de incidentes Rapidez para registrar incidente en la herramienta

Entorno amigable Interfaz de la herramienta es agradable al usuario

Confiabilidad La información registrada en la herramienta debe ser consistente.

Portabilidad Funciona independientemente de la plataforma a utilizar.

Costo de adquisición Costo asequible para adquirir la herramienta

Generación de Estadísticas Permita obtener reportes sobre la información registrada en la herramienta

Seguimiento de ciclo de vida del incidente

Debe permitir visualizar como va cambiando el estado de cada incidente como: abierto, en espera o cerrado.

Manejo de Anuncios masivos Poder subir anuncios o avisos a los grupos de usuarios.

Adaptación de la herramienta al Debe estar alineado al proceso definido de gestión de


87

proceso de gestión de incidentes incidente: registro, investigación y cierre.

Parametrización de la herramienta

La herramienta tiene un proceso simple o extenso para ser parametrizada a las necesidades de la UTPL, como son: usuarios, departamentos, casos, entre otros.

Costo de licencia por equipo Compra de licencias por cada cliente/usuario que se acceda a la herramienta.

Costo de actualización y soporte de la herramienta

Si se requiere pagar un valor adicional por actualización o soporte de la herramienta.

Personalización de la herramienta Se tiene acceso al código fuente para la personalización a las necesidades del negocio de la UTPL.

Se utilizó indicadores cuantitativos en escala de 1 a 3, donde 3 es el valor más alto y 1 el valor más bajo:

Tabla 3.2. Indicadores cuantitativos aplicados para la selección de la herramienta

Para evaluar las herramientas se definieron algunos criterios detallados en la siguiente tabla:

Tabla 3.3. Criterios para selección de la herramienta

CRITERIOS OneOrZero SysAid ManageEngine ServiceDesk

Fácil e intuitivo de usar 3 2 3

Ágil en el registro de incidentes 3 3 2

Entorno amigable 2 2 3

Confiabilidad 3 3 3

Portabilidad 3 3 3

Bajo costo de adquisición 3 1 1

Generación de Estadísticas 2 3 3

Seguimiento ciclo de vida del incidente 3 3 3

Manejo de Anuncios masivos 3 3 3

Adaptación de la herramienta al proceso de gestión de incidentes

3 3 3

Parametrización de la herramienta 3 3 3

Costo de licencias por equipo 3 2 2

VALOR DETALLE

1 Regular

2 Bueno

3 Muy Bueno


88

Costo de actualización y soporte 3 1 1

Personalización de la herramienta 3 1 1

39 33 34

Figura 3.4. Criterios de selección de la herramienta

Una vez evaluadas las herramientas como se observa en la Figura 3.4 en el puntaje obtenido de acuerdo a los criterios de evaluación definidos, la diferencia más significativa para la selección de la herramienta es su bajo costo y el permitir acceder al código fuente para poder personalizarla a las necesidades del negocio; entre otras de las características que han permitido seleccionar la herramienta son: facilidad en el uso de la herramienta, agilidad en el registro de incidentes, ya que este proceso no puede tardar más que la solución, así mismo no se requiere pagar un costo adicional para actualización y soporte por la herramienta.

Figura 3.5. Porcentaje de la herramienta en relación a los criterios evaluados


89

Como se observa en la Figura 3.5 el porcentaje obtenido en cada una de las herramientas demuestra que la que obtuvo el mayor porcentaje sobre las demás, es la herramienta OneOrZero.

Cabe mencionar que para efectos de implementación de la herramienta y de acuerdo a los requerimientos y tamaño del Centro de Servicio del GDS se utilizó la herramienta OneOrZero, sin embargo si se quiere ampliar el campo de acción a todos los servicios ofrecidos por la UPSI se puede optar por comprar la herramienta ManageEngine ServiceDesk, la que tiene mayor funcionalidad y puede adaptarse a las necesidades de cada departamento.

3.3 Parametrización de la herramienta

Una vez determinada la herramienta a utilizar por los técnicos del Grupo de Desarrollo de Software es necesario parametrizar algunos elementos de la herramienta para que pueda ser adaptada a las necesidades de la institución. Entre los elementos que fueron configurados en la herramienta se detalla en la Tabla 3.4. Además puede apoyarse en el ANEXO [F].

Tabla 3.4. Elementos de configuración en la herramienta

Nombre Elementos de configuración en la herramienta

Caos de Opciones Definir categorías, prioridad, estado, proyectos, grupo detécnicos

Opciones/Usuarios Agregar usuario, crear grupos de usuarios y de técnicos

Conocimiento Agregar y editar casos para la base de conocimiento

3.4 RESUMEN

El desarrollo de esta fase ha permitido seleccionar la herramienta OneOrZero de registro de incidentes que va a ser utilizada por los técnicos del Grupo de Desarrollo de Software, al existir una diversidad de herramientas en el mercado que permiten manejar el registro de incidentes, encontrar una herramienta que se adapte a las necesidades del grupo no fue tarea sencilla, ya que cada una tiene características diferentes, por lo que se ha tomado para efectos de evaluación tres herramientas: OneOrZero, SysAidServer y ManegeEngine ServiceDesk, se realizó una evaluación que permitió la sección de una de éstas, entre los principales criterios que se consideraron en este proceso de selección se tiene:

• Fácil e intuitiva de usar

• Ágil en el registro de incidentes


90

• Confiabilidad

• Portabilidad

• Bajo costo de adquisición

• Generación de Estadísticas

• Seguimiento de ciclo de vida del incidente

• Adaptación de la herramienta a las necesidades del negocio

• Parametrización de la herramienta

• Costo de licencias por equipo

• Costo de actualización y soporte de la herramienta

• Personalización de la herramienta

Obtenidos los resultados se observaron ciertas diferencias significativas en el puntaje conseguido por cada herramienta frente a los criterios de evaluación, lo que permitió seleccionar la herramienta OneOrZero fue su bajo costo y tener acceso al código fuente para poder personalizarla a las necesidades del negocio; entre otras características que han permitido seleccionar la herramienta están: facilidad en el uso de la herramienta, agilidad en el registro de incidentes, ya que este proceso no puede tardar más que la solución, así mismo no se requiere pagar un costo adicional para actualización y soporte por la herramienta.

Para poder manejar la resolución de incidentes reportados diariamente por parte de los usuarios al Centro de Servicio, es necesario delimitar el software de soporte o herramienta automática para la gestión de incidentes, para lo que es necesario conocer las necesidades de manejo de información que tiene la empresa, y encontrar una herramienta que se adecue a sus necesidades y al procesos definido para la gestión de incidentes.

Al tener seleccionada la herramienta se puede realizar la parametrización de la misma adecuándola a los elementos con los que trabaja el negocio, lo que obtendremos con esto es que los técnicos tengan un ambiente real para que empiecen con el registro de incidentes utilizando la herramienta de gestión de incidentes.


91

FASE 4 4 Plan Piloto


92

Introducción

Esta fase es muy importante en el desarrollo del proyecto de tesis. Para poder determinar si los resultados obtenidos de la aplicación del plan piloto son satisfactorios o no se procede a realizar las pruebas de aceptación del usuario en cuanto al uso de la herramienta y aplicación del proceso de gestión de incidentes. Esta fase incluye los siguientes ítems:

• Planificación del Piloto

• Ejecución del Piloto

• Análisis de Resultados

• Métricas

4.1 Planificación del piloto

Se realiza una programación de todo el proceso que se llevará a cabo para la ejecución del piloto utilizando la herramienta OneOrZero. Se detallan los elementos que incluye la planificación:

4.1.1 Objetivos

• Instruir a los técnicos en el proceso de gestión de incidentes.

• Verificar que la herramienta definida para la gestión de incidentes se adapte al proceso propuesto.

• Identificar el nivel de aceptación de los técnicos del GDS en cuanto a la herramienta seleccionada para el registro de incidentes.

• Medir resultados del proceso de gestión de incidentes

4.1.2 Alcance

Las pruebas del piloto se enfocan al trabajo de los técnicos del GDS que apoyan al registro y resolución de incidentes. El alcance del piloto comprende:

• Capacitación básica en cuanto al proceso definido para la gestión de incidentes.

• Capacitación básica en la herramienta de gestión de incidentes OneOrZero.

• Registro de casos prácticos de incidentes en la herramienta OneOrZero.

• Evaluación de la herramienta y del proceso de gestión de incidentes definido.

• Obtención de métricas de la herramienta


93

En relación al proceso definido se revisarán los siguientes aspectos detallados en la Tabla 4.1:

Tabla 4.1 Proceso para la gestión de incidentes

PROCESO DETALLE

1. Registro

Obtener datos básicos para registrar incidentes, como: quien reporta, detalle de incidente, estado, técnico responsable

2. Clasificación Indicaciones para determinar tipo de incidente

3. Investigación Buscar solución al incidente

4. Resolución y Cierre Detalle de la solución y como confirmar solución con el usuario

En relación a la herramienta OneOrZero se revisarán las siguientes funcionalidades detalladas en la Tabla 4.2:

Tabla 4.2 Funcionales de la herramienta OneOrZero

MODULO FUNCIONALIDAD

1. Opciones de Casos

Crear caso

Mis casos abiertos

Mi grupo de técnicos

Caso no asignado

Mis casos recientes cerrado

Tareas de mis grupos

Buscar Caso

2. Contactos Buscar contactos

3. Preguntas Frecuentes

Conocimientos

Técnico Conocimientos

Agregar a Conocimientos

Conocimientos status

4. Documentación de usuario Permite tener acceso a informaciónacerca de la herramienta

5. Opciones del Técnico Editar Perfil

Ver grupo

6. Reportes

Estadísticas de Tiempo

Estadísticas de Casos

Estadísticas de Técnicos

Estadísticas de Grupo

Nivel de Calificación


94

4.1.3 Requerimientos

Se requiere elementos como: participantes y recursos humanos, técnicos y materiales a utilizar.

4.1.3.1 Participantes

El recurso humano que participará en las pruebas piloto son los que se detalla en la Tabla 4.3:

Tabla 4.3. Participantes en el piloto - Roles y Responsabilidades

PARTICIPANTE ROL RESPONSABILIDAD

Diana Díaz

USER EXPERIENCE

Administrador de laherramienta

Configurar datos mínimos requeridos y prestar un entrenamiento básico a los técnicos en utilización de la herramienta

Técnicos

UPSI-GDS

Técnicos de diferentesáreas del GDS

Adquirir el conocimiento y destreza en la utilización de la herramienta para el proceso de registro de incidentes.

4.1.3.2 Agenda de trabajo

Se detalla la agenda de trabajo en la Tabla 4.4.

Tabla 4.4. Agenda de trabajo

ACTIVIDAD TIEMPO ESTIMADO

SUBACTIVIDAD LUGAR

Capacitación del proceso para gestión de incidentes

20 minutos

Registro

UPSI-GDS Clasificación

Investigación

Resolución y Cierre

Capacitación de la herramienta

30 minutos

Caso opciones

UPSI-GDS

Contactos

Preguntas Frecuentes

Usuario documentación

Técnico opciones

Reportando

Sugerencias y comentarios finales

Evaluación de capacitación

Ejecución 2 semanas Registro y gestión de incidentes UPSI-GDS

Evaluación 30 minutos Aplicación de encuestas antes de UPSI-GDS


95

utilizar la herramienta.

Evaluación sobre uso de laherramienta.

4.1.3.3 Recursos a utilizar

Los recursos humanos, técnicos y materiales a utilizar se detallan en la Tabla 4.5:

Tabla 4.5. Recursos humanos, materiales y técnicos

ESPECIFICACION CANTIDAD RECURSOS

Humanos 1 Capacitador

4 Técnicos del GDS

Materiales

1 Agenda de trabajo

4 Manual del proceso definido, impreso del plan piloto, encuestas, evaluación

Varios: correo-e, teléfono, Chat

Casos prácticos para el registro de incidentes

Técnicos

1 Equipo servidor de la aplicación

4 Computadores de los técnicos

Software: Internet Explorer o Firefox

4.1.3.4 Evaluación de las pruebas con la herramienta

Al cabo del tiempo estimado para el registro y gestión de incidentes del piloto, los técnicos aplicarán la evaluación de gestión de incidentes utilizando la herramienta OneOrZero, tomándose en cuenta la percepción de los usuarios en cuanto a la aplicación seleccionada y la agilidad en el registro de incidentes, a través de un ejercicio práctico.

4.2 Ejecución del plan de piloto

En esta fase se ejecutará la planificación realizada para el plan piloto definido en el punto 4.1 y 4.2, a continuación se detalla el proceso de la ejecución del piloto:


96

4.2.1 Identificación de usuarios

Los usuarios que intervinieron en el plan piloto se detallan en la Tabla 4.6:

Tabla 4.6. Técnicos para la ejecución del plan piloto

Nombre Rol

Carlina Rueda QA

Diana Cuenca QA

Viviana Montaño Release

Rodrigo Guarderas User Experience

Diana Díaz Administrador de la herramienta

4.2.2 Inicio de pruebas

A continuación se muestra a detalle el proceso de la ejecución del plan piloto con la utilización de la herramienta OneOrZero seleccionada para registro de incidentes recogidos del SGA-Syllabus, se requirió de:

4.2.2.1 Utilización de recursos

• 4 técnicos pertenecientes al GDS

• Equipo informático con navegador Internet Explorer o Firefox

• 1 equipo servidor donde está instalada la herramienta

4.2.2.2 Capacitación del proceso de gestión de incidentes

Se brindo una capacitación para dar una breve explicación del proceso definido para la gestión de incidentes el que incluye el siguiente proceso detallado en la Tabla 4.7:

Tabla 4.7. Detalle del proceso de la gestión de incidentes

PROCESO ACTIVIDAD

Registro de incidentes

Asignar prioridad

Estado

Técnico responsable del incidente

Quién reporta incidentes

Detalle del incidente

Clasificación Identificar la categoría o tipo de incidente

Investigación y Diagnóstico Buscar solución al incidente

Resolución y Cierre Confirmar solución con el usuario


97

Para la asignación de la prioridad es importante que el técnico considere los siguientes criterios detallados en la Figura 4.1 y en la Tabla 4.8:

Figura 4.1. Criterios para determinar prioridad

Tabla 4.8. Detalle de prioridad

PROCESO ACTIVIDAD

1 Crítico 1 – 15 minutos

2 Alto 16 – 60 minutos

3 Medio 1 hora – 24 horas

4 Bajo 24 horas – 48 horas

5 Planeando Planeando

La Tabla 4.8 detalla los tiempos mínimos de solución de cada incidente de acuerdo a la prioridad con que debe ser resuelto el incidente reportado, esto permitirá determinar que incidentes son los más primordiales en resolver, ya que no todos los incidentes pueden ser resueltos al mismo tiempo.

4.2.2.3 Capacitación en la herramienta / proceso

Una vez que se tiene la infraestructura montada para utilizar la herramienta realice lo siguiente:

• Abra un navegador e ingrese a la siguiente dirección: http://helpdesk.utpl.edu.ec, en la página mostrada ingresa su usuario y contraseña para la acceder a la herramienta

• Una vez dentro de la herramienta empieza a registrar cada incidente

• Si existe solución registre solución y cierre el incidente y confirme solución al usuario

Tabla 4.9. Relación Herramienta / Proceso

Proceso Funcionalidad Herramienta Tarea

Registro Crear Caso Asignar prioridad, estado, técnico responsable, proyecto

Clasificación Crear Caso->Información de caso Seleccionar categoría del incidente

Investigación Conocimiento Buscar solución en Base de Conocimiento

Solución Mis Casos Abiertos Información de casos abiertos, registrar solución, cambiar estado al incidente.


98

4.2.2.4 Referencia de casos a registrar por cada técnico en la herramienta

Los casos que fueron reportados en la herramienta de gestión de incidentes por parte de los técnicos llegaron por varios medios como teléfono, mail o Chat.

4.3 Análisis de resultados

4.3.1 En relación al proceso - herramienta

Luego de realizar la tabulación de los datos obtenidos de la evaluación aplicada a los técnicos (Ver ANEXO G), en relación a la gestión de incidentes utilizando la herramienta OneOrZero, se analizan los datos obtenidos y se verifica a través de estos si el proceso de gestión de incidentes definido en la Fase II se adapta a la realidad del negocio.

Es necesario establecer un rango de aceptación que se muestra en la Tabla 4.10, para poder medir el nivel de satisfacción de los técnicos, basado en las tareas definidas para evaluar la herramienta y su adaptación al proceso definido.

Tabla 4.10. Rango de aceptación

Porcentaje Descripción

0% - 70% No aceptable

71% - 100% Aceptable

Se ha considerado una muestra de 4 técnicos del GDS para la evaluación, lo que equivale al 100%, si más del 70% de la muestra arroja resultados positivos la herramienta para la gestión de incidentes es adecuada.

Tabla 4.11. Detalle de participantes en plan piloto

Nombre Rol

Carlina Rueda QA

Diana Cuenca QA

Viviana Montaño Release

Rodrigo Guarderas User Experience

• Criterios evaluados para determinar nivel de satisfacción

Tabla 4.12. Criterios considerados para determinar nivel de satisfacción

Criterios Descripción

Facilidad de uso Fácil e intuitiva de usar

Rapidez Ágil en el registro de incidentes


99

Facilidad de seguimiento Se pueda identificar claramenteel estado del incidente

Reportes de operación Facilidad para obtener reportes

Apoyo al trabajo diario Contribuye al trabajo de lostécnicos

Adaptación al modelo propuestoSe pueda plasmar en laherramienta el proceso para lagestión de incidentes

En la Tabla 4.12 se muestra a detalle los criterios que fueron evaluados por los técnicos en relación a la herramienta.

Nivel de satisfacción

No satisfacción

25%

Satisfacción75%

Figura 4.2. Análisis del nivel de satisfacción de los usuarios frente a la herramienta

Se puede concluir que el nivel de satisfacción de los técnicos que utilizaron la herramienta para gestión de incidentes OneOrZero es del 75% como se muestra en la Figura 4.2.

• Tiempos promedio de registro por incidente en la herramienta

0%

75%s

25%s

0%20%40%60%80%

0 a 2minutos

3 a 5minutos

mas de 10minutos

Figura 4.3. Tiempo promedio de registro por incidente en la herramienta


100

Como se muestra en la Figura 4.3 los tiempos de respuesta para el registro de cada incidente en la herramienta está entre un rango de 3 a 5 minutos, y el registro de incidentes se puede realizar mientras se está receptando la llamada con el usuario.

• Adaptación al proceso definido

Adaptación al proceso definido

0%10%20%30%40%50%60%70%80%

Cumplesatisfacción

Cumpleparcialmente

No cumple

75%

25%

Figura 4.4. Adaptación al proceso propuesto de gestión de incidentes

En la Figura 4.4 se puede observar el 75% de los técnicos están de acuerdo que la herramienta se adaptación al proceso de gestión de incidentes definido y el 25% considera que la herramienta se adapta parcialmente, por lo tanto se concluye que la herramienta seleccionada para el registro de incidentes es aceptable por los técnicos del Centro de Servicio.

4.3.2 Métricas obtenidas de la herramienta en relación al proceso de gestión de incidentes llevado en el Centro de Servicio GDS

Dentro de la ejecución del plan piloto es necesaria la obtención de métricas que permitan reflejar la aplicabilidad del proceso definido para la gestión de incidentes con apoyo de la herramienta OneOrZero, las métricas que se obtuvieron de la herramienta son:

• Total de casos abierto, pendientes y cerrados por cada técnico del Centro de Servicio.

• Número de incidentes resueltos por cada técnico.

• Número de casos reportados por cada usuario del SGA Syllabus.

• Casos registrados por categorías

• Casos registrados por área (tipos de incidentes y proyectos)

Se ha considerado las siguientes métricas basadas en los datos obtenidos de la herramienta para el registro de incidentes, se detallan a continuación:


101

4.3.2.1 Casos Abiertos, pendientes, cerrados

El objetivo de este indicador es reflejar a través de métricas el trabajo diario realizado por los técnicos del Centro de Servicio y justificar si el número de técnicos es suficiente para proveer el soporte adecuado al usuario.

Este indicador muestra la cantidad de casos registrados que se encuentran con estado de: abierto, pendiente y cerrado, se puede observar que la mayoría de los casos reportados por los usuarios han sido cerrados por los técnicos del Centro de Servicio, y existe un mínimo número de casos que están en espera de una solución, debido a que se escaló a otro nivel de soporte para que se analice y pueda ser resuelto, los casos con estado abierto son aquellos que tienen prioridad baja por lo tanto el tiempo de solución es mayor.

53

0

242

52

100 93

121

3

53

16 63 325

2 4 8 5 2 3 9 13 0 1 6 0 1 1 0 1 1 00

50

100

150

200

250

300

crued

a

dcue

nca

drdiaz

gpico

itajal

bajpo

zo

jpuren

a

lcajam

arca

mrueda

sjimen

ez

vmon

tano

CerradosAbiertosEspera

Figura 4.5. Número de casos abiertos, pendientes y cerrados

4.3.2.2 Casos por Técnico

El objetivo de este indicador es mostrar el trabajo realizado por cada técnico que opera en el Centro de Servicio, además de reflejar la experiencia adquirida de cada técnico para resolver mayor número de casos en el menor tiempo posible.

Se puede determinar que el total de casos registrados por los técnicos es de 845 registros en el transcurso de 2 meses de uso de la herramienta.

Cada técnico es el responsable directo de investigar la solución a cada incidente que registra en la herramienta, y una vez que se encuentra la solución es el encargado de notificar al usuario para poder cerrar el incidente.


102

Lo que se pretende con el registro de incidente es que cada usuario adopte la cultura de registrar cada caso reportado a él, lo que permitirá que la Administración pueda ver en términos cuantitativos el trabajo realizado por cada uno de los técnicos del Centro de Servicio como se muestra en la Figura 4.6.

Figura 4.6. Número de casos por usuario

4.3.2.3 Número de casos reportados por grupo de usuario del SGA Syllabus

Ésta métrica permite identificar los usuarios que solicitan mayor soporte a los técnicos del Centro de Servicio, esto permitirá analizar e investigar los motivos por los que el usuario solicita ayuda a la hora de trabajar con el SGA Syllabus.

Figura 4.7. Casos por grupo de usuarios

Estos informes serían de útil ayuda al grupo de desarrolladores ya que les permitirá conocer si algunas de las causas por las que los usuarios solicitan soporte al trabajar con el SGA Syllabus es por: desconocimiento de ciertas funcionalidades cuando el usuario es nuevo y no tuvo


103

ninguna capacitación previa, error de datos, poca usabilidad en la interfaz o problemas internos de la aplicación.

Esto permitirá a la Administración tomar medidas correctivas para atacar las causas que originan la mayoría de incidentes que afectan a los usuarios del SGA Syllabus.

4.3.2.4 Casos por Funcionalidad

El objetivo de esta métrica es determinar las categorías o funcionalidades que tienen mayor inconveniente al momento de ser utilizadas por los usuarios del SGA Syllabus, permitiendo determinar si el soporte requerido es porque la funcionalidad tienen poca usabilidad y hay que rediseñar la interfaz, o son problemas a nivel de datos, lo que no permiten al usuario utilizarla por sí solo y tengan que recurrir a los técnicos del Centro de Servicio para pedir asesoría sobre su funcionamiento.

Figura 4.8. Casos por funcionalidad

4.3.2.5 Casos por Área (tipos de incidente o proyecto)

Esta métrica permite visualizar el área o proyecto que presenta mayores inconvenientes al momento de interactuar con el usuario.

Actualmente el uso de la herramienta se extendió a otras áreas las que se denominan: BAAN para registrar incidentes relacionados al Sistema Financiero BAAN, REDES para reportar problemas de fallas en la Red de la UTPL, SOFTWARE para el registro de incidentes relacionados al SGA Syllabus y SOPORTE TÈCNICO para casos con problemas en los equipos de los usuarios de la UTPL.


104

Como se muestra en la Figura 4.9 el área que más casos ha reportado es el área de Software donde se registran todos los casos reportados por los usuarios del SGA Syllabus, además esto se debe a que tiene un considerable número de usuarios que hacen uso de los servicios del SGA Syllabus.

Figura 4.9. Número de casos por área

Lo que se pretende obtener con la metodología ITIL es llevar un proceso controlado y ordenado para la gestión de incidentes, lo que permitirá obtener mayor productividad en el trabajo realizado por los técnicos del Centro de Servicio ya que se dará solución a un mayor número de incidentes en el menor tiempo posible y con el mínimo uso de recursos, y especialmente el usuario sabrá exactamente a dónde dirigir sus inquietudes, reclamos, sugerencias e incidentes presentados, lo que provocará un ambiente de satisfacción ya que siempre habrá alguien que esté pendiente de dar la solución a sus peticiones.

Todo este proceso debe ser llevado con ayuda de una herramienta de registro de incidentes, esto permitirá optimizar tiempo a la Administración ya que se tiene una fuente de información digital de donde se pueden obtener reportes en el lugar, y momento requerido, y permite reflejar el trabajo realizado por los técnicos del Centro de Servicio.


105

4.4 RESUMEN

En ésta fase se desarrolló un plan piloto para realizar pruebas de la herramienta seleccionada de registro de incidentes OneOrZero, para lo que se realizó una planificación, ejecución y obtención de resultados del piloto, lo que permitió medir el nivel de satisfacción de los técnicos en relación al proceso definido para la Gestión de Incidentes con la herramienta.

Los criterios que se evaluaron corresponden a facilidad de uso, agilidad en el registro de incidentes, seguimiento del proceso de incidentes, apoyo al trabajo diario, adaptación al modelo propuesto de gestión de incidentes, con los resultados obtenidos de la evaluación aplicada se pudo determinar que existe un 75% de satisfacción de los técnicos con relación a la herramienta.

Una vez definido el proceso de gestión de incidentes, seleccionada la estructura del Centro de Servicio, y las herramientas tecnológicas con las que operarán los técnicos, es importante obtener algunas métricas a través de la herramienta de registro automático de incidentes como son: total de casos abiertos, pendientes y cerrados, número de casos registrados por usuario, por funcionalidad y por área, lo que permitirá a la Administración tener datos cuantitativos de la operación del proceso definido para la Gestión de Incidentes en el Centro de Servicio del GDS, apoyando la toma de decisiones para mitigar los inconvenientes o aplicar medidas correctivas a los incidentes que reportan los usuarios ya sea por desconocimiento de cómo operar algunas de las funcionalidades de la aplicación SGA Syllabus o por algunas fallas de la aplicación.


106

FASE 5 5 Conclusiones y Recomendaciones


107

CONCLUSIONES

Al finalizar el desarrollo del presente proyecto de tesis se puede concluir:

Con el estudio realizado se pudo determinar que la falta de un proceso controlado y formalizado para la gestión de incidentes acarrea desperdicio de recursos, es así como los técnicos del GDS invertían aproximadamente el 20% de su horario de trabajo en actividades de soporte que no les correspondían.

La adopción de algunos procesos de la metodología ITIL como son la Gestión de Problemas, Gestión de Cambios y principalmente la Gestión de Incidentes, ha contribuido a proponer procesos a seguir por el Centro de Servicio, ya que ITIL concentra las mejores prácticas probadas en varias entidades y que han podido ser adoptadas en un 80% por el Centro de Servicio de la UTPL.

Para llevar un proceso de gestión de incidente es necesario apoyarse de una herramienta que permita llevar de forma organizada el proceso de registro de incidentes, luego de un análisis de los criterios funcionales evaluados como son: facilidad de uso, agilidad en el registro de incidentes, bajo costo de adquisición y seguimiento del ciclo de vida del incidente, la herramienta más adecuada a instalar y utilizar es OneOrZero, la que obtuvo el 93% en relación a los criterios evaluados.

Los resultados del plan piloto han permitido medir el nivel de satisfacción de los técnicos el cual se estima en un 75%, en relación al proceso definido de gestión de incidentes y la adaptación de la herramienta al mismo, permitiendo llevar el registro de incidentes en forma organizada y adecuándose al proceso definido.

Con el proceso establecido para la gestión de incidentes se ha logrado que el soporte solicitado por los usuarios del SGA Syllabus sea atendido en un 85% por los técnicos del Centro de Servicio.


108

RECOMENDACIONES

Finalizado el presente trabajo se puede concluir las siguientes recomendaciones:

Antes de implementar procesos ITIL en una organización es necesario definir los procesos que se quiere mejorar, y en base a esos requerimientos determinar los módulos de ITIL a implementar en la organización.

Hacer una evaluación al término de cada período académico sobre el proceso definido para la Gestión de Incidentes por parte de los técnicos y de los usuarios, lo que permitirá conocer como ha contribuido a la operación del Centro de Servicio y sobre todo a la atención al usuario, y obtener datos para mejoras del proceso si lo requiere.

Para entregar un servicio de calidad es importante que el Centro de Servicio cuente con personal capacitado en las tareas que realiza y esté comprometido con los objetivos que persigue la empresa.

Brindar capacitación permanente a los técnicos que operan el Centro de Servicio en relación a mejoras de la Gestión de Incidentes como en nuevas tecnologías si adquiriera la empresa o si existieran nuevas versiones de la herramienta en cuanto a cambios en las funcionalidades.

Realizar de manera periódica la generación de reportes que ofrece la herramienta OneOrZero, la obtención de información de los incidentes registrados en la herramienta permitirá tener una visión real de cómo va evolucionando el proceso de gestión de incidentes.

Se recomienda tener backups de respaldos que permitan restablecer el normal funcionamiento de la herramienta en caso de que exista un problema en el servidor donde funciona la herramienta.

Si se va a extender el Centro de Servicio a todos los Departamentos de UPSI se recomienda invertir en la adquisición de la herramienta ManageEngine Service Desk ya que cuenta con más funcionalidades que se pueden adaptar a los diferentes departamentos.

El Centro de Servicio debe estar en constante actualización hacia las nuevas versiones de ITIL, ya que una nueva versión trae consigo mejoras y correcciones de versiones anteriores, y tener presente que ITIL es un proceso integral que incluye tecnología, recursos humanos y procesos.


109

GLOSARIO DE TERMINOS

Abierto: Estado inicial en el ciclo de vida de un incidente.

ACD: Distribuidor automático de llamadas

Call Centre: Centro de llamadas que maneja gran cantidad de llamadas telefónicas entrantes y salientes.

Cerrado: Estado final en el ciclo de vida de un incidente.

CAB: Consejo Asesor del Cambio.

CMDB: Base de datos de administración de la configuración.

CI: Elemento de configuración.

GDS: Grupo de Desarrollo de Software.

Help Desk: Centro de atención al usuario.

Impacto: Basado en cómo serán afectados los procesos del negocio y los usuarios respecto al incidente presentado.

ITIL: Biblioteca de Infraestructura de Tecnologías de la Información.

KeDB: Base de Datos de Errores Conocidos.

OGC: Oficina Gubernativa de Comercio Británica.

Pendiente: Estado de un incidente que está en espera de solución.

Prioridad: Característica utilizada para identificar la importancia de un incidente, se lo determina mediante la urgencia y el impacto.

Proceso de negocio: Es un proceso que pertenece y lo maneja una entidad.

QA (Control Quality): Grupo encargado de evaluar la calidad del producto que se está desarrollando y que se libere con cero errores.

RFC (Request for Change): Petición de Cambio.


110

Release Management: Área encarga principalmente de subir versiones del sistema.

SGA Syllabus: Sistema de Gestión Académica Syllabus.

Service Desk: Centro de Servicio, es el punto de contacto entre el usuario y la empresa para el registro de incidentes.

SLAs: Acuerdos de Nivel de Servicio, donde se especifican todos los servicios que va a cubrir el Centro de Servicio.

Soporte de primera, segunda y tercera línea: es una jerarquía de grupo de soporte involucrada en la resolución de incidentes. Cada nivel utiliza recursos más especializados o más capacidades.

SPOC (Single Point of Contact): Primer punto de contacto.

TI: Tecnología de Información, generalmente incluye computadores, telecomunicaciones, aplicaciones, software para almacenar, comunicar o procesar la información.

UPSI: Unidad de Proyectos y Sistemas Informáticos.

Usabilidad: Es la facilidad mediante la cual una aplicación o servicio puede usarse.

Usuario: Persona que usa el servicio del Centro de Servicio diariamente.

User Experience: Experiencia de Usuario, encargado de la relación con el usuario como capacitaciones o soporte directo al usuario.

Urgencia: velocidad con la que debe resolverse un incidente.

UTPL: Universidad Técnica Particular de Loja.


111

BIBLIOGRAFIA:

[Osiatis, 2007] Introducción a ITIL, [citado octubre del 2007]. [en línea]. Disponible en: http://itil.osiatis.es/Curso_ITIL/

[GobiernoTIC] Gobierno TIC. Qué es ITIL, IBSN 900-11-11-009. [citado a 30 de abril del 2008]. [en línea]. Disponible en: http://www.gobiernotic.es/search/label/ITIL

[EuroPortal ITIL], Como Introducir ITIL, [citado septiembre del 2007]. [en línea]. Disponible en: http://www.portal-itil.eu/consult_como.php

[Iberoamericana] Universidad Iberoamericana Campus Cuidad de México, Metodología ITIL. [citado a junio del 2007]. [en línea]. Disponible en: http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml?monosearch#conc

[Telefonica], ITIL – Information Technology Infraestructure Library, Consultado a [enero del 2008]. [en línea]. Disponible en: http://www.telefonica.net/web2/igrgavilan/tutotiales/tec_itil.htm

[Telefonica], ITIL – Information Technology Infraestructure Library, Consultado a [enero del 2008]. [en línea]. Disponible en: http://www.fi.uba.ar/materias/7546/material/ITIL%20v1.5.pdf

[TechNet] Microsoft, Proceso de Administración basado en ITIL/Cobit, [en línea], [citado enero del 2008] disponible en: http://technet.microsoft.com/es-es/library/bb821261.aspx

[ITIL] Incident Management, [en línea], [citado diciembre del 2007] disponible en: http://www.itil.com.mx/incident.htm

[CentroServicio], Libros en línea Gestión de Servicios IT, una introducción, Georges Kemmerling, Dick Pondman [en línea], [citado enero del 2008] disponible en: http://books.google.com.ec/books?id=HUaDV0SSJbwC&pg=PA118&lpg=PA118&dq=centro+de+servicios+con+itil&source=web&ots=QQ6Nbfqh8J&sig=SrTE4mocHk0HmXnwdIqjYrkNL1k&hl=es#PPA116,M1

[GestionIncidentes], Libros en línea, [en línea], [citado enero del 2008] disponible en: http://books.google.com.ec/books?id=HUaDV0SSJbwC&pg=PA41&dq=Gestion+de+incidentes+con+ITIL&sig=8EMpszd5v7vkYz_yH1_XYnzPd2s#PPA42,M1

[PinkElephant, 2006], EXPERTOS EN ADMINISTRACION DE SERVICIO TI. Flores José Manuel. 2007. Integrando TI al Negocio a través de las Mejores Prácticas de ITIL. [citado noviembre del 2007]. Disponible en: https://www.pinkelephant.com/NR/rdonlyres/349DB8CA-


112

0A99-4A19-AC0B-1ADE2020BBCA/1296/AlineandoTIalNegocioconITILv31SeptMododecompatibil.pdf

[Assirati, 2003a], Assirati Bob. (2003). ITIL SERVICE SUPPORT.

[Assirati, 2003b], Assirati Bob (2003). ITIL SERVICE DELIVERY.

[Assirati, 2002], Assirati Bob. (2002). ITIL Planning to Implement Service Management.

[Foro-Help], Foro acerca de mejores prácticas de Help Desk, [en línea], [citado julio del 2008] disponible en: http://www.foro-helpdesk.com


113

ANEXOS


114

ANEXO [A] Definición del SLA

Contenido del SLA

Entre los aspectos que debe incluir el acuerdo establecido entre el proveedor del servicio y el usuario se listan:

1. Descripción de quienes establecen el acuerdo. 2. El período cubierto por el acuerdo. 3. Las mejores prácticas a utilizar. 4. Los servicios que serán provistos por el centro de servicio. 5. Los servicios que no serán cubiertos. 6. El horario de operaciones normales y el servicio opcional fuera del horario. 7. Mecanismos de acceso al servicio. 8. Definición de las prioridades de las llamadas y los tiempos de respuesta

requeridos. 9. Los estándares de desempeño que el servicio debe alcanzar. 10. Los reportes que deberán ser generados por el centro de servicio. 11. Los elementos informáticos soportados. 12. Las políticas del servicio.

1. Descripción de quienes establecen el acuerdo

Para identificar de manera clara los actores que intervienen en el Acuerdo de Nivel de Servicio se describen cada uno de estos:

• Los usuarios de TI (personal de la UTPL): son las personas que trabajan con el Sistema de Gestión Académica, los usuarios finales a quienes se debe proveer el soporte como son: secretarias de centro, sede, coordinadores de centros, personal de contabilidad, estudiantes, docentes entre otros.

• Los proveedores (los integrantes del centro de servicio): es el personal que labora en el Centro de Servicio y quienes son responsables de proporcionarlo.

• Los clientes (los integrantes del grupo directivo de la UTPL): son las personas que solicitan requerimientos de cambios o mejora para llevara a cabo sus procesos de negocio.

Académica:

Modalidad Clásica: Dr. José Barbosa Vicecanciller


115

Dr. Roberto Beltrán Director General Académico

Modalidad Abierta: Dra. María José Rubio Directora Modalidad Abierta y a Distancia

Financiera:

Dr. Ramiro Cárdenas y Econ. Ramiro Armijos

2. Período cubierto por el Acuerdo

El acuerdo establecido entre el Centro de Servicio del GDS y los usuarios del SGA Syllabus de la UTPL será indefinido, se realizará una revisión del acuerdo, si existen algunas modificaciones en el servicio provisto y se realizarán los cambios necesarios.

3. Utilización de las “Mejores Prácticas”

Para éste estudio el Centro de Servicio del GDS básicamente está enfocado en la solución de incidentes reportados por los usuarios del SGA Syllabus, por ello algunas de las “mejores prácticas” consideradas, nos ayudarán a proveer los servicios establecidos en el SLA.

Prácticas optimizadas para la gestión de incidentes

Las prácticas optimizadas de control y conocimiento para la gestión del incidente requirieron de un software que:

• Genere un ítem por cada incidente reportado.

• Asignar el estado de las llamadas o solicitud de servicio.

• Asignar el incidente al técnico responsable.

• Registrar y reportar la solución del problema al usuario.

• Permitir cerrar los incidentes solucionados.

Para apoyarnos en el proceso de gestión de incidentes, la herramienta debe ser permitir generar tanto reportes históricos como información actual en tiempo real.

• Algunos de los reportes requeridos son:

• El volumen mensual de incidencias recibidas.

• El porcentaje de llamadas por funcionalidad especifica.

• Total de incidentes resueltos por cada técnico.

• Total de incidentes resueltos en la primera línea de soporte.


116

El software utilizado en la gestión de incidentes cuenta con una base de conocimientos que ayudará al personal del Centro de Servicio en el diagnóstico y solución de los problemas habituales.

Otras de las herramientas útiles que ayudarán al registro problemas y asignar las prioridades de servicio y grado del problema (sistema caído, función degradada, preguntas sobre alguna aplicación, etc), es el portal de servicios de todos los proyectos llevados por el GDS.

4. Servicios que serán provistos por el Centro de Servicio

Entre los principales servicios que serán provistos por el Centro de Servicio están:

• Proveer de soluciones a los incidentes. Facilitar la gestión problemas provocados por los incidentes reportados por los usuarios vía telefónica, correo electrónico, en el sitio o a través de una herramienta automática que permita el registro de incidentes.

• Asesoría en la instalación, configuración del hardware y del software estándar involucrado en la operación del SGA SYLLABUS, como son: impresora de etiquetas de código de barras, instaladores del aplicativo para generación de códigos de barra, configuración mínima del navegador.

• Guiar en la utilización de las diferentes funcionalidades del SGA SYLLABUS.

• Proveer información digital e impresa de las funcionalidades del SGA SYLLABUS requeridas por el usuario.

A continuación se detallan las tareas que el Centro de Servicio del GDS debe prestar al usuario:

• Atención de la llamada o solicitud escrita (correo-e, comunicación escrita, fax, mensajería instantánea, … ) por parte de los usuarios.

• Verificación de que los datos del usuario estén correctos.

• Asegurarse de que el servicio solicitado esté dentro de los servicios que provee el Centro de Servicio.

• Si la solicitud está dentro de los servicios provistos atenderlo, caso contrario dirigir la solicitud al departamento correspondiente.

• Creación y descripción del incidente en la herramienta automática de registro de incidentes.

• Definición de la prioridad del problema.

• Escalamiento del problema si es necesario.

• Definición de la posible solución.


117

• Actualización de la base de conocimiento con la solución encontrada al incidente reportado.

• Verificación de que el incidente haya sido resuelto.

• Confirmación de que el usuario está de acuerdo con la solución.

• Cerrar el incidente o petición de servicio.

5. Servicios no incluidos en el SLA

Entre los servicios no incluidos están:

• Problemas relacionados con el hardware y el software no contemplados en éste acuerdo.

• Proveer información a usuarios externos sobre los productos o procesos llevados en la UTPL.

• Soporte a usuarios fuera del horario de trabajo y de actividades relacionadas con la UTPL.

• Servicios en el lugar, es decir proveer soporte al equipo del usuarios o personal que se encuentre fuera de la UTPL y no tengan actividades relacionadas con el uso del SGA Syllabus.

• Instalación y configuración de herramientas que no influyen en el funcionamiento del SGA Syllabus.

6. Horarios de prestación de servicio

Tabla 1. Horario prestación de servicio

Servicio Cubrimiento Diario Cubrimiento Semanal

Centro de Servicio 08:00 a 13:00 horas y

15:30 a 18:30 horas De lunes a viernes

El horario de trabajo del Centro de Servicio del Grupo de Desarrollo de Software está afín con la jornada laboral normal del personal de la UTPL. Sin embargo habrá ocasiones en que se requiera un cubrimiento extraordinario para apoyar el trabajo del personal de los centros universitarios de todo el país y de los centros extranjeros como es el caso de Roma, Madrid y New York, en cuanto a los procesos de matrículas en línea de los centros universitarios del país, centros universitarios que trabajan tiempo extra o una sola jornada, matrículas de estudiantes de modalidad abierta y clásica; en estas situaciones y previa solicitud y autorización se coordinará entre los miembros del Centro de Servicio quien va a ser la persona encargada de brindar el soporte solicitado en la jornada extraordinaria.


118

7. Los mecanismos de acceso al servicio

El Centro de Servicio debe ser identificado como el primer punto de contacto y no como un grupo apartado al que se contacta como último recurso, las formas de reportar incidentes y problemas básicamente son dos:

• Escrita (faxes, correo-e, página en intranet o internet, herramienta automática, comunicados, msn) y

• Verbal (por teléfono o en forma directa en el lugar), está siempre tiene que estar respaldada de información por escrito para evitar confusiones en la petición de requerimientos.

La preferencia de un mecanismo sobre otro está determinada por la rapidez para comunicar los incidentes y problemas presentados, se detallan los mecanismos a utilizar:

Teléfono: es el medio más eficiente y común para comunicar incidentes, permite dar una clara definición del problema entre el usuario y el técnico de soporte, para la comunicación a través de una llamada telefónica se han definido con algunas extensiones telefónicas: 3301 o 3305.

Personalmente: el usuario puede acudir a la oficina donde opera el Centro de Servicio que se encuentra en el 4to piso del edificio de la UPSI (Unidad de Proyectos y Sistemas Informáticos) para resolver aquellos incidentes que no han podido ser resueltos telefónicamente, aunque tiene la desventaja de ser extremadamente demandante de recursos que posiblemente no estén disponibles.

• 4to. Piso, Edificio de UPSI, departamento GDS (Grupo Desarrollo de Software)

• Horario de atención definido: Lunes a viernes de 08:00 a 13:00 y 15:30 a 18:30 hrs.

Por e-mail: el usuario puede reportar incidentes y problemas a detalle, y recibir notificación de la solución a través de la casilla de correo electrónico de alguno de los miembros del Centro de Servicio, este medio es recomendable cuando se reportar problemas que requieran el envío de información adicional para poder confirmar datos del incidente.

Fax: el usuario puede enviar información física requerida por el personal del Centro de Servicio, la que servirá como evidencia en la solución de los incidentes y problemas reportados, el número de FAX a utilizar para el envío de información es: 2585978.


119

8. Definición de las prioridades

Por el constante flujo de incidentes reportados al Centro de Servicio del GDS, resulta beneficioso definir un sistema básico de prioridades con asignación de tiempos de respuesta (el tiempo que pasa desde que el usuario reporta el incidente hasta que alguien empieza a trabajar realmente en la solución de éste) y el máximo de tiempo para proceder a escalar los problemas si así lo requiere.

Determinar prioridades permite asignar la cantidad adecuada de recursos al problema según sea el impacto en la operación normal del SGA Syllabus.

Prioridad de la llamada y su tiempo de respuesta.

Los tiempos de respuesta serán determinados por la prioridad de la llamada, la que estará determinada por el impacto (nivel de prioridad) que el incidente reportado tenga en la productividad de la empresa.

Tabla 2 Los niveles de severidad

Prioridad Detalle Definición Tiempo de resolución

1 Crítico

La red, la aplicación o la base de datos no están funcionando. El negocio está parado, o hay un impacto significativo que amenaza la productividad futura.

1 – 15 minutos

2 Alto

A pesar del alto impacto del problema la producción prosigue aunque afectada; o existe una preocupación significativa por parte del cliente, o hay algún elemento que no para al trabajo pero puede afectar el rendimiento a largo plazo.

16 – 60 minutos

3 Medio

Asunto importante que no tiene impacto significativo en el proceso normal de la empresa, generalmente se refiere al problema de un solo usuario.

1 hora – 24 horas

4 Bajo Solicitud de información, incidente que requiere solo seguimiento si fuera necesario.

24 horas – 48 horas

5 Planeando Petición de requerimiento que debe ser analizado y planeado.

Planeando


120

Niveles de PRIORIDAD

Prioridad 1 (Crítico-Componente Caído).- se trata de un problema que afecta a varios usuarios, o a un solo cliente muy importante. Estos problemas pueden derivarse por la falla en el enlace de comunicación puede estar roto o en mal estado, servidores fuera de servicio, caída de la red o de la base de datos, corte generalizado de energía, seguridad violada, invasión de virus, etc.

Prioridad 2 (Alto- Componente degradado).- Un problema que afecta a múltiples usuarios, o a un usuario importante, pero existe un modo alterno de seguir prestando un servicio equivalente o degradado. Estos problemas pueden derivarse de fallas de energía aisladas, tiempos lentos de respuesta de la aplicación por múltiples conexiones a la base de datos, la conexión al Internet está lenta.

Prioridad 3 (Medio-Importante).- Problema que afecta a un solo usuario, por fallas técnicas en el equipo del usuario, dudas en el funcionamiento de operación de la aplicación o necesidad de configuración del navegador donde funciona la aplicación.

Prioridad 4 (Informativo).- Necesidad de información o de algún servicio, no hay nada que arreglar.

Prioridad 5 (Planeado).- Puede referirse a una petición de requerimiento que debe ser analizado y planeado para una futura implementación del requerimiento.

Tabla 3 Los niveles de severidad

Tiempo Prioridad Detalle

1 – 15 minutos 1 Crítico

16 – 60 minutos 2 Alto

1 hora – 24 horas 3 Medio

24 horas – 48 horas 4 Bajo

Planeando 5 Planeando

9. Estándares de desempeño que el servicio debe alcanzar

Se deben establecer objetivos medibles entre los que se espera obtener tenemos:

• Se debe lograr cerrar el 80% de los incidentes reportados por los usuarios en el primer nivel de contacto.

• Disminuir el número de incidentes reincidentes.


121

• Al realizar una evaluación interna del servicio, se espera lograr obtener una calificación de 4 en una escala de 1-5.

10. Los reportes que deberá generar el centro de servicio

Los reportes que deberán ser emitidos por un responsable del Centro de Servicio son:

• Total de llamadas y su desglose porcentual por tipo, como: llamadas por solicitud de servicio o quejas, reporte de incidentes.

• Porcentaje de llamadas resueltas en el primer contacto.

• Tiempo de respuesta promedio de la llamada.

• Porcentaje de llamadas reincidentes en cada mes.

• Resultados de encuestas sobre la calidad del servicio entregado al final de cada período académico.

11. Sistemas y componentes soportados

Los elementos informáticos críticos son:

• Sistema administrador de registro de incidentes del centro de servicio

• El correo electrónico

• Configuración en todas las computadoras del personal de la UTPL que interactúa con el SGA Syllabus.

Los elementos informáticos no críticos

Se listan el software y hardware definido como estándar que el usuario final debe manejar:

Tabla 4. Software estándar del usuario final

Internet Explorer v 6.0 o superior

PDF

Microsoft Excel

Instalador de etiquetas de código de barras

Tabla 5. Hardware estándar del usuario final

Hardware Usuarios

Computadores Todos los usuarios

Impresoras de código de barra Secretarias de los Centros: Nacionales, Regionales y en algunos centros provinciales


122

(mayor # estudiantes)

Impresoras Todos los usuarios

Lectores de código de barras Secretarias de los Centros: Nacionales, Regionales y en algunos centros provinciales (mayor # estudiantes)

Impresoras de punto de facturación Secretarias de los Centros: Nacionales, Regionales y en algunos centros provinciales con un considerable número de estudiantes.

12. Las políticas del servicio

Para que un Centro de Servicio funcione correctamente debe definir políticas claras y comunicarlas a todos los interesados (usuarios, personal, empresa), las políticas son normas que rigen diversos aspectos del servicio, y aplican para todos los que de él se benefician o participan. Cubren el cuándo, el dónde, y el cómo acceder a los servicios; servicios provistos cuando se soliciten; restricciones del servicio, los cuidados en el manejo de las herramientas, etc. Los usuarios deberán saber cuáles son los servicios que el Centro de Servicio proporcionará y como usarlos, además de conocer las obligaciones contratadas para recibir un servicio adecuado.

Las responsabilidades del cliente

Solo podrá solicitar el soporte por los medios que se han definido en la sección titulada “Mecanismos de acceso”. No serán procesados los incidentes o solicitudes de información que lleguen por otros medios.

El usuario no instalará en su equipo aplicación alguna, solamente deberá instalar aplicaciones recomendadas por el personal del Centro de Servicio las que servirán para mejorar la utilización del SGA Syllabus. Caso contrario, se le negará el servicio si llegase a necesitar ayuda sobre la instalación o funcionamiento del software instalado que este en los contemplados en el acuerdo.

Mantenimiento de la base de datos de conocimientos

El personal de soporte tiene la obligación de mantener la base de conocimientos al día con los datos relacionados a las soluciones dadas a los problemas reportados por los clientes, y a configuraciones mínimas requeridas.


123

Las notas técnicas para resolver problemas, deben estar en la base de conocimientos. Estas guías del problema tienen que estar definidas en forma clara, precisa, y en términos que cualquier persona con entrenamiento en la aplicación, o el equipo, pueda entender.

El entrenamiento

El entrenamiento al usuario será sobre todas las aplicaciones y funcionalidades del SGA Syllabus autorizadas, el entrenamiento para el personal técnico cubrirá el hardware y el software contemplados en el SLA, y es obligatorio cubrir los temas de servicio al cliente, diagnóstico y resolución de incidentes.

El mejoramiento continúo

El objetivo del Centro de Servicio del GDS es proveer un servicio de calidad para lograrlo se debe cumplir con los niveles de servicio acordados con los clientes; y el hacer todo bien a la primera. El objetivo a lograr es que todo el personal del Centro de Servicio prevenga el error o la falla siguiendo disciplinadamente los procedimientos en el tratamiento de incidentes; si hay desviaciones en el servicio, habrá que buscar las causas-raíz para su inmediata corrección.

Se deberá medir el grado de cumplimiento del servicio periódicamente, lo que ayudará a determinar el grado de satisfacción de los usuarios para cumplir con expectativas de recibir una solución eficaz al incidente.

La comunicación

El Centro de Servicio debe contar con el equipo y los medios de comunicación necesarios (teléfonos, correo-e, portal de servicio, software para reporte de incidentes, etc.) para poder responder apropiadamente al usuario. Es responsabilidad del personal probar y mantener en condiciones adecuadas de uso dichos equipos y medios para evitar que la comunicación con el Centro de Servicio del GDS se vea afectada. El correo debe ser revisado y leído cuantas veces sea necesario para estar enterados de lo que el usuario solicita, o de lo que se informa, y así poder responder a tiempo.

Manejo del personal

El personal tendrá una clara y completa descripción de los puestos y sus responsabilidades. Es responsabilidad del grupo fomentar un excelente nivel de comunicación interno orientado al desarrollo de trabajo en equipo. El desempeño del personal deberá ser evaluado periódicamente estableciendo planes de desarrollo y realizando mejoras que incrementen la calidad y eficiencia del servicio.


124

Manejo de los registros

Toda información durante el proceso de un incidente, desde el primer contacto con el usuario hasta la resolución final, debe ser registrada en el sistema de seguimiento en tiempo real. La documentación de la llamada debe empezar cuando se origine la misma, no posteriormente.

Delimitación de responsabilidades

De acuerdo a la naturaleza de la organización, el centro de servicio llegará a tener algunas relaciones con otros grupos o áreas que trabajan con la tecnología informática de la UTPL. Si alguna de estas áreas no esté bien definida, habrá oportunidad de fallar en el servicio y de provocar insatisfacción en del usuario, porque no habrá alguien que se responsabilice por solucionar el incidente.

Con el fin de evitar caer en ésta problemática, el responsable del Centro de Servicio deberá trabajar con las otras áreas involucradas, pero se deberá establecer una clara delimitación de responsabilidades en cada grupo para que tomen responsabilidad de cualquier asunto y no dejar sin atención al usuario con problemas.

La política que seguirá el personal de soporte será apropiarse del problema en primera instancia y luego buscar el apoyo de otros grupos o afines en la empresa para atacar conjuntamente la problemática del usuario en la primera línea de soporte.

Inventario de usuarios

La cantidad total estimada de usuarios que soporta el SGA Syllabus es de 27.000 usuarios entre secretarias y coordinadores de: centro sede, nacionales, regionales, asociados, y extranjeros, personal del departamento de contabilidad, docentes y estudiantes de modalidad abierta, clásica y postgrados.

La UTPL es una empresa dedicada a la educación, la mayor parte de los usuarios tienen una preparación en el manejo de la computadora y sus aplicativos.

Cada uno de los usuarios está registrado en una Base de Datos con la mayor cantidad de datos posibles tales como: datos personales, carrera, nombre del departamento en el que trabaja, role asignados al usuario, funcionalidades permitidas, entre otras.


125

ANEXO [B] : ESQUEMA DE SOPORTE PARA EL PROCESO DE MATRÍCULAS PERÍODO DEL PERÍODO OCTURE 2005-FEBRERO 2006 DE LA MODALIDAD ABIERTA Y A DISTANCIA

1. Consideraciones iniciales

Para el presente período de estudios el soporte para las matrículas del lado del sistema se realizará de manera remota por parte del personal del Proyecto Phantom y de la Universidad.

El mecanismo principal de comunicación entre los centros y la matríz de la UTPL se realizará a través de una herramienta de CHAT desarrollado por personal del proyecto. Esto evitará la congestión de las líneas telefónicas.

2. Aspectos de soporte contemplados

Dada la naturaleza de los problemas que se han presentado, hemos definido cinco categorías que requieren ser atendidas, las cuales se listan a continuación.

Nro. Aspecto Descripción Dependencia responsable

1 Académico

Todo lo relacionado con aspectos propios de las escuelas y profesores: Se consideran notas, convalidaciones, exámenes de ubicación, autorizaciones académicas, y otros procesos académicos.

Coordinación Académica y respaldado por las Escuelas (Directores, Secretarias, Profesores)

2 Contable

Todo lo relacionado con deudas, papeletas de depósito, saldos a favor, cobros no realizados, autorizaciones económicas, reactivaciones de matrícula.

Departamento de Contabilidad, Personal de soporte de BaaN

3 Procesos

Todo lo relacionado con cambios o autorizaciones en los procesos normales, tales como gestión de pagos en bancos, fechas de matrículas, nuevos convenios, cambios en convenios, comunicaciones o autorizaciones globales, problemas con definiciones, etc.

Unidad de Procesos y Departamento de Atención al Estudiante.

4 Sistema Dificultades con la funcionalidad del sistema, mensajes de error, interpretación de resultados, desconocimiento de

Proyecto Phantom (User Experience)


126

funcionalidades.

5 Tecnológico Problemas con funcionamiento de equipos, de la red, impresoras.

Proyecto Phantom (Release Management), además de Departamento de Soporte Técnico y Grupo de Redes.

3. Centros Universitarios involucrados

Para el proceso el presente período se ha incluido los siguientes centros universitarios al proceso en línea.

Grupo. Centro Tipo enlace Estado Tipo de matrícula Esquema de Pago

1

Loja – Matríz Directo OK En línea Con cédula: Banco de Loja

Quito y subcentros (San Rafael, Villaflora)

Directo OK En línea

Con cédula: Banco de Loja Con prematricula: Produbanco Servipagos

Guayaquil Directo OK En línea Con prematricula: Produbanco Servipagos

Cuenca Directo OK En línea Con prematricula: Produbanco Servipagos

2

Santo Domingo

Latacunga

Ibarra

Riobamba

Manta

Esmeraldas

Celular Por Instalar

En línea Con prematricula: Produbanco Servipagos

3 Ambato Aula virtual Ok Matrícula manual con ingreso al

Con papeleta de depósito: Banco del Pichincha


127

Machala

Puyo

Tena

Guaranda

Portoviejo

Tulcán

Zamora

Nueva Loja

Quevedo

sistema en horario diferido (Cuando no hay transmisión de aulas virtuales)

u otros Bancos, excepto Produbanco y Servipagos

Para el soporte a estos centros se ha definido los siguientes mecanismos.

GRUPO Prioridad Personal a cargo en el centro

(Primer Nivel) Mecanismo

1 1

Quito: Soraya Puetate, Verónica Galarza, Paulina Santamaría.

Guayaquil: Roxana Vera, Margarita Yépez

Cuenca: Ximena Orellana

El personal indicado resuelve los problemas del centro o se contacta con el equipo de soporte de Loja

2 1 Personal responsable de matrículas (Coordinador)

Contacto con el equipo de soporte de Loja

3 2 Personal responsable de matrículas (Coordinador)

Contacto con el equipo de soporte de Loja


128

4. Personal de Soporte en Loja

Para el soporte en Loja, se han definido las siguientes personas de acuerdo a las áreas definidas anteriormente:

Aspecto Personal

(Segundo Nivel) Disponibilidad

Personal de Apoyo

(Tercer Nivel)

Académico Yomara Jiménez 07:30 – 12:30

15:00 – 19:00 Janeth Chicaiza

Contable Noelia Navas,

Tania Simaluiza

07:30 – 12:30

14:30 – 19:00

Viviana Montaño

Pablo Sanmartín/Fausto Loja

Sistema Diana Díaz

Diana Cuenca 07:30 – 20:00 Stalin Calderón

Procesos Luís Moncada

Gioconda Riofrío

07:30 – 12:30

15:30 – 18:30

Patricio Abad

Manolo Sangoquiza

Tecnológico Víctor Poma 07:30 – 12:30

15:30 – 18:30

Soporte Técnico

Grupo de Redes

5. Esquema general de soporte

En general el soporte está estructurado en cuatro niveles:

Primer Nivel

♦ A cargo de las personas designadas en cada uno de los centros Universitarios, se entienden directamente con la problemática estudiantil.

♦ Ellos son los responsables de resolver los problemas en su centro, y en caso de requerir ayuda adicional se contactarán con el personal de soporte de Loja a través de Chat.

Segundo Nivel

♦ Personal definido de acuerdo a los aspectos establecidos, el personal de segundo nivel atiende al personal de primer nivel, cada uno en su área de competencia.


129

♦ El papel principal de las personas de este nivel es el de gestionar las soluciones con otras personas, de manera que la atención sea ágil.

♦ El mecanismo de comunicación entre estas personas y el personal de nivel 1 es a través de la herramienta de Chat. Y con el nivel 3 vía telefónica a las extensiones establecidas.

♦ Si el caso tiene resolución rápida, no se requiere registro, pero si requiere seguimiento se deberán llenar una plantilla en Excel que permitirán llevar un seguimiento.

♦ Al final del día deberán guardar las conversaciones sostenidas en un archivo de texto como registro histórico para su posterior revisión en caso de problemas.

Tercer Nivel

♦ En caso de que los problemas no se resuelvan en segundo nivel por problemas mayores, intervienen las personas de tercer nivel con el fin de dar una solución a los problemas siempre y cuando sean de su competencia.

♦ Se comunican con los niveles 2 y 4 niveles vía telefónica, correo electrónico.

Cuarto nivel

♦ Este nivel es el último, en el que finalmente se resuelve el problema o se toma alguna resolución o cambio en el sistema, está conformado por el equipo del proyecto, y puede derivar en decisiones a nivel de Direcciones de Escuela, Direcciones Generales o Autoridades.


130

ANEXO [C]: INFORME DE MATRÍCULAS PERÍODOS OCTO7 – FEB 08 Y ABRIL-AGOSTO 2008

INFORME DE MATRICULAS DEL PERIODO OCT 2007- FEB 2008

En el presente informe se detalla el proceso de matrículas del período Abril-Agosto 2007, se describen los casos puntuales a los que se dio soporte:

HERRAMIENTAS MÁS UTILIZADAS

Las herramientas que se utilizó para la recepción de casos de matricula fueron:

TELEFONO 70 %

MESSENGER 20 %

CORREO ELECTRONICO 10 %

INCOVENIENTES PRESENTADOS EN EL PROCESO DE MATRICULA

CASOS # Casos

MANTENIMIENTO DE MATRICULA

Anulación y cambios de asignaturas desde mantenimiento de matrícula. IIIIIIIIII

Anulación de asignaturas cuando el estudiante tiene nota registrada y no se ha realizado la devolución del material.

II

Mantenimiento de matrícula, añadir asignatura y pagar con gestión Banco/Tesorería.

IIIIIIIIII

Anulación de matricula III

No saben el proceso para eliminar prefacturas desde mantenimiento de matriculas. IIII

MANTENIMIENTO PLANES DE ESTUDIO

No saben cómo realizar la oferta del plan desde Mantenimiento Oferta de Planes de Estudio.

IIIIIIIIIIII

No sabe el proceso para crear planes de estudio y asignaturas desde Mantenimiento planes de estudio

IIIIII

Quitar restricción desde Mantenimiento Oferta de Asignaturas para matricular estudiantes de otras universidades en Plan Cursos Abiertos.

III

Al crear nuevos planes de estudio, no se quito de la oferta el 1er ciclo del pensum II


131

antiguo, por lo que algunas secretarias matricularon en pensum antiguo, lo que ocasionó que se tenga que eliminar esas matrículas ya que no salía material bibliográfico para las asignaturas.

Facturas de modalidad clásica pagadas con Crédito Universitario que no se facturó el valor por crédito universitario, secretaria tenía configurado el calendario de modalidad clásica con modalidad abierta.

II

AUTORIZACIONES

Autorización asignatura fuera de potencial para tomar asignatura de otro plan de estudio.

IIIIIIII

Autorización para matricula sin tasa administrativa material restringido de estudiantes de modalidad clásica que toman asignaturas en la abierta.

IIII

Inconvenientes con las autorizaciones de Material restringido sin tasa administrativa, ya que si no se utiliza la autorización al momento de matricular al estudiante en otra carrera sale como un impedimento de matricula, la secretaria que ingreso la autorización debe eliminarla.

III

EXPEDIENTE ACADEMICO

Modificar datos de cedula negativa desde Expediente Académico I

Al facturar algunos derechos de estudiantes antiguos por Facturación de Derechos, la secretaria no se percató que el estudiante tenia identificación negativa, esto ocasiona que el sistema cobre un recargo como si fuera estudiante extranjero, o no se pueda procesar la factura, en este caso hay que pedir a la secretaria que busque en archivo la identificación del estudiante y la actualice desde el expediente académico.

IIIIIIIIII

En el caso de ser estudiantes muy antiguos no se puede migrar datos y hay que crear expediente académico para matricular o facturar derechos.

IIIIII

Problemas al matricular cuando se tiene duplicado el expediente académico de un estudiante, la secretaria de hablar a una persona de Desarrollo de software para que unifique el expediente y se pueda matricular al estudiante.

III

ANULACION DE TERCERA MATRICULA

Proceso de anulación de materias reprobadas (1, 2 o 3 períodos), y luego debe ingresar la autorización de tercera matrícula.

I

CONVALIDACIONES

Convalidar asignaturas de Plan Especial a Modalidad Abierta, la secretaria no lo puede hacer desde el expediente académico y se debe hacer a nivel de base de

IIIIIII


132

datos.

Convalidación automática de asignaturas de CCHH a la carrera del estudiante. IIII

Convalidación de asignaturas de modalidad Abierta a Clásica, o de Clásica a Abierta.

III

CONFIGURACIONES

Matricular con convenio Facturación a Terceros. II

Habilitar periodos de matriculas a los usuarios (secretarias y profesores). III

Correr promoción de notas de varios esquemas de evaluación. IIIIIIIIIIIIIIIIII

IIIIIIIIIIIII

MIGRACION DE DATOS

Inconsistencia en los datos migrados de algunos estudiantes, ya que en el sistema FOX la asignatura esta como aprobada, pero en el DANTA sale como reprobada.

IIIIIII

Migración de datos del sistema FOX al DANTA o del INTEGRA AL DANTA III

MATRICULAS

Dificultad al ingresar pagos con cuota fácil. II

Inconvenientes al asignar cupos de asignaturas de Ciencias Humanas en los diferentes planes de estudio, no había un control del cupo por carrera.

IIII

Existían algunas solicitudes de matrícula de periodos anteriores, al recuperar estos datos y cambiar para el nuevo periodo académico da el inconveniente que al estudiante hay que anularle la matricula ya que no constaran en los reportes, ni se podrá registrar notas, ni realizar la entrega de material bibliográfico.

III

Se retrasaron las matriculas de modalidad clásica porque no se autorizaban para ofertar los nuevos pensum en algunas escuelas, además no se podían configurar los horarios de los demás planes de estudio porque no estaban autorizados por Dirección General Académica.

III

Al aceptar la matrícula sale error “Centro invalido para generar # de factura”, este error se da cuando la secretaria no tiene punto de facturación asignado.

II

REPORTES

Problemas al generar el reporte de: certificado de materias, listado registro de notas, acta de matriculados, pases de ciclo, lista de estudiantes, total matriculados por carrera y ciclo.

47

NOTAS

Algunos docentes tienen problemas al pasar notas, ya que a algunos de ellos no les mostraba las materias asignadas a él, o salía un error “No existe esquema de

II


133

evaluación para la asignatura”, esto se debía a que la secretaria no asignaba docente a la asignatura, o no añadía un esquema de evaluación a la misma.

Inconvenientes en el retraso de publicación de notas supletorias de modalidad abierta, ya que al matricular al estudiante sale en su potencial la asignatura que no se pasa la nota como si la tuviera reprobada, luego el estudiante exige la anulación de la asignatura.

III

Si no se pasaron notas al finalizar un periodo académico, es sistema anula la asignatura, fue por definición de Dirección General Académica.

IIII

Profesores de la carrera de Químico Biológicos no pueden pasar notas 1ro a 4to ciclo, porque son asignaturas compartidas con otras carreras, la secretaria es la encargada de pasar estas notas temporalmente.

IIII

No se puede imprimir el acta de notas desde el sitio del profesor en los centros de Zamora y Cariamanga, solamente llega hasta seleccionar la impresora y no imprime las actas.

II

PAGOS

Inconsistencia con las deudas en el banco, ya que algunos estudiantes cancelan sus cuotas pendientes o prematriculas con depósito bancario y van a legalizar sus pagos en Tesorería (Clásica) o Contabilidad (Abierta).

IIIIIIIIIIIIIII

Facturación de aranceles, cuando paga con Saldo a Favor y la diferencia con Gestión Banco/Tesorería.

III

Inconvenientes al recaudar deudas de los estudiantes, ya que al momento de ir a pagar al banco con su número de cédula, no se mostraban.

IIIIIIIIIII

ERRORES MÁS FRECUENTES:

Errores en la aplicación

- Problemas con la conexión al Produbanco, no se podía recaudar las deudas de los estudiantes.

Errores de parametrización

- Configuración de convenios. - Correr promoción de notas de varios esquemas de evaluación.

Error por desconocimiento de funcionalidades

- Mantenimiento de Matrícula: al anular, añadir o cambiar asignaturas; y para realizar anulación académica de la matrícula.


134

- Problema con las autorizaciones de Material Restringido sin tasa administrativa ya que se debe escoger el plan de la abierta en lugar de plan especial como se hacía anteriormente.

- Asignatura fuera de potencial cuando el estudiante debía tomar una asignatura de otra carrera.

- Configuración de Planes Estudio, en cada período de matrículas hay que estar informando a las secretarias para que realicen la oferta, debe pasar a responsabilidad de otra área como coordinación académica.

- La generación del reporte de pases de ciclo es lento y en algunos casos no se puedo generar el reporte.

- Anulación de períodos en el sistema y autorización para tercera matricula. - Correr Promoción de Notas de algunos esquemas de evaluación. - Quitar restricción desde mantenimiento oferta de asignaturas para matricular

estudiantes de otras universidades que tienen convenio con la UTPL.

EL INDICE DE LLAMADAS DE LOS CENTROS ASOCIADOS A DISMINUIDO NOTABLEMENTE EN COMPARACIÓN CON LAS LLAMADAS RECIBIDAS EN EL CICLO ANTERIOR.


135

Informe de Matrículas Abril-Agosto 2008

User Experience - Grupo de Desarrollo de Software – UPSI Proyectos

Se apoya a todos los proyectos que tiene el Grupo de Desarrollo de Software, en actividades concretas.

Los proyectos son los siguientes:

1. Proyecto de Gestión Académica Syllabus. En sistema de créditos ECTS y sistema tradicional.

2. Proyecto CRM para gestión de trámites para Modalidad Abierta.

3. Proyecto QlickView para explotación de información para UTPL.

Actividades

A continuación se detallan las actividades que se gestionan y realizan en cada uno de estos proyectos:

Apoyar en la fase análisis de los proyectos. Desarrollar y/o apoyar prototipos e interfaces gráficas de usuario. Desarrollar material de apoyo al usuario de cada una de las

aplicaciones: manuales, ayudas, trípticos, videos, instructivos,.. Desarrollar planes de capacitación en aplicaciones. Además, ejecutar y

monitorear las capacitaciones. Brindar soporte a los usuarios de las aplicaciones o a sus responsables

técnicos en las dependencias internas o externas. Gestionar el estudio de herramientas para apoyo de las actividades

anteriormente mencionadas. Asistencia a reuniones de los proyectos citados.

Soporte del sistema Syllabus

Los medios de soporte

Vía telefónica Correo electrónico Messenger

La problemática del soporte del sistema corresponde a los siguientes ítems:


136

- Usuarios nuevos que desconocen las funcionalidades (en este punto es importante hacer un análisis de porcentaje)

Se detalla los incidentes a los que se da soporte:

Incidentes Funcionalidad

Actualizar # identificación de estudiantes antiguos Expediente Académico

Cambios en la configuración de asignatura como: horarios, profesores, # estudiantes

Mantenimiento Oferta Planes Estudio

Creación y configuración de nuevos planes y asignaturas Mantenimiento Planes de Estudio

Configuración de asignaturas cuando son de tipo Libre Configuración y Complementarias

Excepciones de Oferta

Para realizar cambios para añadir o eliminar asignaturas Mantenimiento de Matrícula

Correr promoción de notas Proceso promoción de notas

Petición de claves para profesores nuevos o que han olvidado su clave de acceso

Crear usuarios en Base de Datos

Modificar nombres de asignaturas o agregar asignaturas para convalidaciones

Modulo de Convalidaciones

Pasar al plan correspondiente cuando se autorizada tomar asignatura fuera de potencial en otro plan de estudio

Expediente Académico

Convalidación de asignaturas de modalidad clásica a abierta y viceversa


Realizar cambios de paralelo Cambio de Paralelo

Asignar material bibliográfico por alguna falla en el sistema Asignar material des Base de Datos

Actualización de pagos en el banco ya que salen valores que no son

Actualizar valores desde Base de Datos

Eliminar prematriculas de derechos Consulta de Derechos

Asignar períodos académicos para matricular o pasar notas Restricción Catalogo

Asignación de planes de estudio a secretarias para pasar notas

Restricción Catalogo

Asignación de asignaturas a docentes para pasar notas Mantenimiento Oferta Planes

Eliminación de referencias bancarias que han sido utilizadas en prematricula

Eliminar referencia bancaria desde base de Datos

Unificar expediente duplicado para estudiantes antiguos Unificar desde Base de Datos

Asignar funcionalidades requeridas para un determinado usuario

Asignar desde Base de Datos

Migrar asignaturas de Plan Especial a Plan de modalidad abierta

Migrar desde la Base de Datos


137

Error al generar reporte de Certificado Materia y Certificado Materias Créditos

Arreglar reporte desde Report Server

Error al generar reporte de Pase de Ciclo Arreglar reporte desde Report Server

Cambiar convalidaciones externas de asignatura que han sido aprobadas por el estudiante ya que el sistema no valida que ya la tenga aprobada

Cambiar convalidación desde Base de Datos

Indicar como asignar esquema de evaluación a una asignatura

Mantenimiento Planes Estudio

Cambiar # identificación de cedula a RUC Expediente Académico

Solicitan generación de comprobantes de evaluación para postgrados

Generarlos desde Base de Datos

Modificar prerrequisito de alguna especialidad o maestría Mantenimiento Planes Estudio

Secretaria solicita volver a imprimir factura por error en la impresora

Habilitar desde Base de Datos

Solicita que se adapten asignatura al plan de créditos de asignatura tomadas en la abierta


Adaptación de asignaturas masivas al modelo de créditos Adaptación al modelo de Créditos

Pago de deudas pendientes Recaudaciones

Convalidación de asignaturas tomadas en Ciencias Humanas a la carrera del estudiantes


Migración de datos del sistema FOX al Syllabus Migración desde la B.D

Errores Comunes en el sistema Syllabus

Errores de parametrización:

- Configuración de convenios. - Correr promoción de notas de varios esquemas de evaluación. - Configuración de costo de reprobación generalmente en los niveles de inglés.

Error por desconocimiento de funcionalidades:

- Mantenimiento de Matrícula: al anular, añadir o cambiar asignaturas; y para realizar anulación académica de la matrícula.

- Problema con las autorizaciones de Material Restringido sin tasa administrativa ya que se debe escoger el plan de la abierta en lugar de plan especial como se hacía anteriormente.

- Asignatura fuera de potencial cuando el estudiante debía tomar una asignatura de otra carrera.


138

- Configuración de Planes Estudio, en cada período de matrículas hay que estar informando a las secretarias para que realicen la oferta, debe pasar a responsabilidad de otra área como coordinación académica.

- La generación del reporte de pases de ciclo es lento y en algunos casos no se puedo generar el reporte.

- Anulación de períodos en el sistema y autorización para tercera matricula. - Correr Promoción de Notas de algunos esquemas de evaluación. - Quitar restricción desde Mantenimiento Planes de Estudio para poder matricular

asignaturas a estudiantes de otras universidades que tienen convenio con la UTPL. - Excepciones de Oferta: configuración de asignaturas de Libre Configuración y

Complementarias para los planes de estudio de modalidad clásica.


139

ANEXO [D] Manual de Instalación de la herramienta

1. Prerrequisitos: - MySQL 4.1.18 - Php 5 - Apache HTTP Server 2

La versión pueden ser superior a las especificadas ya que no existe conflictos en la instalación.

Como la instalación se la realizó en sistema operativo Windows se utilizó la herramienta EasyPhp que integra los tres componentes requeridos, dicha herramienta puede ser descargada del sitio: http://easyphp.uptodown.com/

2. Instalación EasyPhp 1. Haga doble click sobre el archivo descargado. 2. Siga todos los pasos, indique la ruta de instalación (se recomienda instalarlo en C:\ ó

en Mis documentos, no en Archivos de programas, debido a que vamos a tener que ir agregando carpetas a medida que vamos probando nuestros desarrollos).

3. Finalmente una vez que hallamos terminado la instalación, EasyPHP va a abrirse. 4. La primera acción que realizará será buscar actualizaciones en Internet.

Aquí algo importante. Si poseen un firewall o cortafuegos, seguramente se mostrarán dos precauciones:

o La primera es que EasyPHP va a tratar de conectarse a Internet. o La segunda es que EasyPHP va a tratar de actuar como servidor.

Tenemos que habilitar las dos opciones para que EasyPHP funcione.

5. Esta es la apariencia del programa:

6. Las acciones seguidas que realizará el programa serán habilitar Apache y Mysql. Si los dos semáforos están en verde, es porque todo marcha correctamente.


140

7. A continuación haga click derecho sobre el icono de EasyPHP que se sitúa en la bandeja del sistema y elija la opción administración.

8. Luego se va a abrir nuestro navegador e iremos a una página como la siguiente:

Instalación de OneorZero

Para proceder con la instalación de la herramienta OneOrZero realizamos los siguientes pasos:

1. Crear la base de datos 2. Ingresar a mysql desde un administrador o línea de comandos

a. Ejecutar el comando create database helpdesk b. El comando anterior crea la base datos que utilizará la herramienta

3. Copiar el instalador oozv1657.zip descargado del sitio http://www.oneorzero.com/ en el directorio de aplicaciones del apache(Variante dependiendo del sistema operativo).

4. Extraer el archivo oozv1657.zip y colocar el nombre deseado 5. Ingresar al directorio de la aplicación, en el directorio configuración, editar el archivo

server_settings.php a. server_name = "helpdesk.utpl.edu.ec" , indica el nombre del servidor como se

referencia la aplicación b. oneorzero_web_alias = "", alias del subdirectorio en donde corre la aplicación, en este

caso funciona en la raíz. Por lo que queda en blanco el parámetro c. database = "mysql" , base de datos que se utiliza d. db_host = "localhost" , servidor de base de datos, en este caso es el mismo servidor e. db_user = "root" ,usuario de acceso a la base de datos f. db_pwd = "" , contraseña de la base de datos g. db_name = "helpdesk", nombre de la base de datos previamente creada h. table_prefix = "ooz_" , prefijo de las tablas en la base de datos

6. Ingresar a un navegador y digitar la ruta http://helpdesk.utpl.edu.ec/helpdesk/utilities/install.php para iniciar la instalación


141

7. Proceda con la instalación

8. Configurar los parámetros solicitados del administrador como: primer nombre, segundo nombre, nombre de usuario, dirección de e-mail, clave, oficina y número de teléfono.

9. Borrar o renombrar el directorio utilities que se encuentra en el directorio de la aplicación. 10. La aplicación esta lista para funcionar.

Para permitir el acceso mediante el subdomio asignado realizamos el siguiente cambio en el archivo httpd.conf del apache:

ServerName helpdesk.utpl.edu.ec


142

ANEXO [E]: Manual de usuario de la herramienta para gestión de incidentes OneorZero

Introducción

OneOrZero es una herramienta open source que permite el registro y control de incidentes durante todo el ciclo de vida del mismo.

Para ingresar a la herramienta realice lo siguiente:

1. Abra el navegador y digite http://helpdesk.utpl.edu.ec

2. Ingrese su nombre de usuario y contraseña 3. Presione el botón Enviar 4. Una vez dentro de la herramienta se muestran las siguietes iociones:

Esta herramienta contiene un conjunto de secciones o módulos, dentro de cada uno de ellos se encuentran algunas funcionalidades que se van a detallar a continuación:

ACTIVIDAD SUBACTIVIDAD

Caso opciones

Crear caso

Mis casos abiertos

Mi grupo de técnicos

Caso no asignado

Mis casos recientes

Tareas de mis grupos

Buscar Caso

Contactos Buscar contactos

Preguntas Frecuentes

Conocimientos

Técnico Conocimientos



143

Conocimientos status

Usuario documentación Permite tener acceso a información acerca de la herramienta

Técnico Opciones Editar Perfil

Ver grupo

Reportando

Estadísticas de Tiempo

Estadísticas de Casos

Estadísticas de Técnicos

Estadísticas de Grupo

Nivel de Calificación

1. Casos Opciones

Crear Caso

1. Seleccione Crear Caso donde le permite registrar el detalle del incidente reportado por los usuarios.

2. Se presenta los parámetros para crear el caso el cual consta de 3 secciones con la siguiente información:

Secciones Detalle de campos

Información del técnico

Grupo de Técnico

Técnico

Prioridad: puede ser critico, alto, medio o bajo


144

Estado: sin asignar, abierto o en espera

Severity:

Project: proyecto del que se esta registrando incidente

Información del Usuario Datos del usuario que reporta el incidente como: nombre de usuario, Email, Oficina, Teléfono, estos datos se añaden automáticamente.

Información del caso

Grupo de Técnico: Software, Redes o Soporte Técnico

Categoría: tipo de incidentes

Descripción breve: nombre del incidente

Descripción: detalle del incidente

Apéndice: adjuntar información adicional sobre el incidente si existe

3. Haga click en el botón Crear Caso para guardar el incidente, o puede utilizar el botón Limpiar para ingresar un nuevo incidente.

Mis Casos Abiertos

Permite visualizar información de los incidentes abiertos que están asignados al técnico.

1. Seleccione la opción Mis Casos Abiertos

2. Se muestra la lista de todos los incidentes abiertos asignados al técnico

Mi grupo de Técnicos

Permite visualizar todos los incidentes con estado abierto, receptados por todos los técnicos.

1. Seleccione la opción Mi Grupo de Técnicos


145

2. Se muestra la lista de todos los incidentes abiertos que están reportados.

Casos No Asignados

Se muestra la lista de todos los incidentes registrado con estado Sin Asignar

1. Seleccione la opción Casos No Asignados

2. Permite visualizar todos los incidentes que están con estado Sin Asignar

Mis Casos Recientes

Permite visualizar todos los Casos resueltos, que estén con estado Cerrados.

1. Seleccione la opción Mis Casos Recientes

2. Se muestra la lista de todos los incidentes que han sido cerrados por el técnico

Tareas de mis Grupos

Permite visualizar los incidentes del grupo.

1. Seleccione la opción Tareas de mis Grupos


146

2. Se muestra la lista de todos los incidentes del grupo

Buscar Caso

Permite buscar de acuerdo a determinados parámetros los incidentes registrados

1. Seleccione la opción Buscar Caso

2. Se presentan todos los criterios de búsqueda que se detallan a continuación:


Buscar Caso

Grupo Técnico

Técnico: nombre técnico

Caso Project: proyecto del que quiere buscar incidente

Caso Prioridad: puede ser critico, alto, medio o bajo

Caso estado

Caso categoría

Grupo de Técnicos

Nombre

Apellido


147

Usuario

Grupo de usuario

Oficina

Entre fechas

Clave

Introducción SQL

3. Para realizar la búsqueda hacer click en el botón Buscar Caso.

NOTA: Todas las listas de incidentes muestran la siguiente información:


Parámetros

ID: código del incidente

Técnico: receptor del incidente

Descripción breve:

Usuario

Prioridad

Fecha creado

Estado

Tiempo

Además en cada una de las listas de incidentes se puede actualizar la información haciendo click en el campo Descripción Breve.

2. Contactos

Permite buscar información de todos los usuarios y técnicos de la aplicación.


148

1. Seleccione la opción Contactos

2. Presenta los siguientes parámetros de búsqueda:


Parámetros

Detalle del contacto

Nombres

Apellidos

Email

Teléfono

Oficina

Dirección

Ciudad

Estado

Provincia

Código Postal

3. Presionar el botón Buscar para realizar la búsqueda

3. Preguntas Frecuentes

Permite buscar en la Base de Conocimiento acerca de la solución de un incidente reportado por el usuario.

Conocimientos

1. Vaya a la sección de Preguntas Frecuentes y seleccione la opción Conocimientos


149

2. En pantalla principal se muestran preguntas organizadas por grupos, maque en el criterio que necesita revisar información, adema tiene una sección de búsqueda para ingresar tema de búsqueda en la Base de Conocimiento.

3. En la siguiente pantalla se muestran las peguntas existentes en el grupo seleccionado anteriormente.

4. Se muestra la información asociada a la pregunta seleccionada en la Base de Conocimiento.

Agregar a Conocimiento

Permite ingresar un nuevo item a la Base de Conocimiento. Para ello realice lo siguiente:

1. Seleccione la opción Agregar a Conocimiento.


150

2. En la pantalla mostrada seleccione el Grupo de Técnicos y la Categoría. 3. Luego ingrese información referente a:

Campos Detalle

Pregunta Ingrese pregunta

Respuesta Detalle la respuesta a añadir a la Base de Conocimiento

Observable por Seleccione grupo de técnicos que puede observar pregunta

Apéndice Puede añadir un documento de solución a la Base de Conocimiento

4. Finalmente presione el botón Agregar a Conocimiento.

4. Usuario Documentación

Permite visualizar información referente a las opciones de la herramienta.

1. Vaya a la opción Usuario Documentación y seleccione la información que requiere ver.

2. En pantalla principal se muestra la información seleccionada, para ver el resto de información simplemente seleccione otra opción.


151

Puede encontrar información referente a temas de:


Usuario Documentación

Introducción

Características

Caso opciones

Preguntas frecuentes

Opciones usuario

Todo

5. Técnico Opciones

Permite editar información referente al técnico que está conectado en la aplicación.

1. Vaya a la opción Técnico Opciones y seleccione Editar Perfil

2. En la pantalla mostrada modifique los datos requeridos


Editar perfil requerido

Nombre

Apellido

Dirección Email

Contraseña

Editar perfil opcional

Titulo

Teléfono

Oficina


152

Dirección

Ciudad

Estado

País

Idioma

Tema

Recuperación de contraseña Pregunta secreta

Respuesta a la pregunta secreta

3. Presione el botón Actualizar para guardar la información ingresada.


153

ANEXO [F]: Manual del Administrador de la herramienta para gestión de incidentes OneorZero

Configuraciones en la Herramienta

Para ingresar a la herramienta realice lo siguiente:

1. Abra el navegador y digite http://helpdesk.utpl.edu.ec

2. Ingrese su nombre de usuario y contraseña de administrador 3. Presione el botón Enviar 4. Una vez dentro de la herramienta se muestran las siguientes opciones:

Para poder utilizar la herramienta se tuvo que realizar configuraciones en algunas funcionalidades de la herramienta las que se detallan a continuación:


Opciones de caso

Caso categoría

Caso Prioridades

Caso Estado

Caso Severidad

Caso Project

Grupos de técnicos

Caso evaluación

Opciones / Usuarios

Agregue nuevo usuario

Grupos de Usuarios

Grupos de Técnicos

Buscar Usuarios

Conocimientos

Grupos de Técnicos

Categoría opciones

Agregar a Conocimiento

Edita Conocimientos


154

6. Opciones de caso

Caso Categoría

Permite crear listado de tipos de problemas o categorías por las que llaman los usuarios.

1. Seleccione el módulo Opciones de Casos.

2. De la lista de funcionalidades mostrada seleccione Caso Categoría. 3. En la pantalla mostrada se muestran los tipos de problema configurados, si quiere

modificarlos escriba en el cuado de texto, puede eliminar la categoría presionando la opción Borrar.

4. Presione el botón Actualizar para que se guarden los datos. 5. Si quiere agregar una nueva categoría escriba en el campo Agregue una nueva

Categoría, e ingrese el Nivel. 6. Presione el botón Agregue una nueva Categoría. 7. Se muestra una pantalla de confirmación de actualización de datos, presione en Clic

aquí para continuar.

Para configurar el resto de funcionalidades del módulo Caso Categoría realice los mismos

pasos descritos.


155

Caso Prioridad

Permite configurar niveles de prioridad de acuerdo a tiempos de respuesta para solucionar los incidentes reportados por los usuarios.

Caso Estado

Aquí define estados por los que puede pasar un incidente puede ser: sin asignar, abierto, en espera o cerrado.

Caso Severidad

Define nivel afectación del incidente a los procesos del negocio puede ser:

- 1= Alto - 2= Medio - 3= Bajo


156

Caso Proyecto

Permite definir los diferentes proyectos que se incluyen para el soporte a los usuarios.

Grupo de Técnicos

Los grupos de Técnicos pueden ser creados para las estadísticas o para separar a los Técnicos en grupos por la lógica tipos de Casos.

Caso Evaluación

Permite definir escalas de calificación donde 1 es el valor mas alto y 5 es el valor mas bajo.


157

7. Opciones / Usuarios

Agregar nuevo usuario

Permite crear usuarios y asignarlos a un determinado grupo de usuarios.

Dentro de cada grupo se debe configurar los usuarios, es así que en la herramienta se configuró:

GRUPO Usuarios

Secretarias clásica Secretarias que pertenecen a modalidad clásica.

Secretarias abierta Secretarias que pertenecen a modalidad abierta

Técnicos Técnico

Para ello realice lo siguiente:

1. Vaya a Opciones/Usuarios

2. Seleccione la funcionalidad Agregue nuevo usuario. 3. En la pantalla mostrada ingrese la información solicitada referente a:

CAMPO DETALLE

Información del usuario Nombre

Apellido


158

Nombre de usuario

Dirección Email

Contraseña

Contraseña otra vez

Titulo

Teléfono

Oficina

Dirección

Ciudad

Estado/Provincia

Código Postal

País

Edita Conocimientos

Sitio Web

Otros

Nivel

Agregar a grupo de Técnicos Técnicos

Agregar a Grupo de usuariosSecretarias clásica

Secretarias Abierta

4. Presione el botón Agregar nuevo usuario para guardar la información del usuario creado.

Grupos de usuarios

Permite crear grupos de usuarios y añadir adherir usuarios a cada grupo. Para ello realice lo siguiente:

1. Seleccione el módulo Grupos de Usuarios.


159

2. En la pantalla mostrada se muestran los tipos de usuarios configurados, si quiere modificarlos escriba en el cuado de texto y en el Nivel asigne un número al grupo. Además puede:

Borrar: presione la opción Borrar si quiere eliminar grupo de usuarios.

Más opciones: permite configurar el grupo de usuarios permitiendo añadir o quitar usuarios al grupo. Realice lo siguiente:

1. Se muestra la lista de usuarios perteneciente al grupo de usuarios, si quiere eliminar haga clic en Borrar.

2. Para agregar un nuevo usuario al grupo, en el campo Agregar Usuario al Grupo ingrese el nombre de usuario.

3. Presione el botón Agregar Usuario al Grupo.

En pantalla principal continúe con el proceso siguiente:

3. Luego de seleccionar los usuarios al grupo presione el botón Actualizar Grupo Data. para guardar los datos.

4. Si quiere agregar un nuevo grupo escriba en el campo Agregue un Grupo el nombre del grupo a crear y en Nivel el número de grupo a asignar.

5. Presione el botón Agregue un Grupo. 6. Se muestra una pantalla de confirmación de actualización de datos.


160

Grupos de Técnicos

Permite crear grupos de técnicos y añadir técnicos al grupo. Para ello realice lo siguiente:

1. Seleccione el módulo Grupos de Técnicos.

2. En la pantalla mostrada se muestran los tipos de Técnicos configurados, si quiere modificarlos escriba en el cuadro de texto y en el Nivel asigne un número al grupo. Además puede:

Borrar: presione la opción Borrar si quiere eliminar grupo de técnicos.

Más opciones: permite configurar el grupo de técnicos permitiendo añadir o quitar usuarios al grupo. Realice lo siguiente:

1. Se muestra la lista de usuarios perteneciente al grupo de técnicos, si quiere eliminar haga clic en Borrar.

2. Para agregar un nuevo técnico al grupo, en el campo Agregar Usuario al Grupo ingrese el nombre de usuario.

3. Presione el botón Agregar Usuario al Grupo.

En pantalla principal continúe con el proceso siguiente:


161

3. Luego de seleccionar los usuarios al grupo presione el botón Actualizar. para guardar los datos.

4. Si quiere agregar un nuevo grupo escriba en el campo Agregue un Grupo el nombre del grupo a crear y en Nivel el número de grupo a asignar.

5. Presione el botón Agregue un Grupo. 6. Se muestra una pantalla de confirmación de actualización de datos.

8. Conocimientos

Permite agregar o quitar ítems de la base de Conocimiento, además permite configurar los elementos relacionados para configurar la misma.

Grupos de Técnicos

Los grupos de técnicos son iguales a los grupos de trabajo, ya que por cada grupo se tiene que tener ítems de conocimiento que serán agrupados de acuerdo al nombre del grupo de técnicos. En el sistema realice lo siguiente:

1. Seleccione la opción Grupo de Técnicos.


162

2. En la pantalla mostrada se muestran los grupos de técnicos, si quiere modificarlos escriba en el cuadro de texto, puede eliminar el grupo de trabajo presionando la opción Borrar.

3. Presione el botón Actualizar para que se guarden los datos. 4. Si quiere agregar una nueva categoría escriba en el campo Agregue nuevo grupo de

Técnicos, e ingrese el Nivel. 5. Presione el botón Agregue nuevo grupo de Técnicos

Categoría Opciones

Permite crear y modificar opciones de categoría para la Base de Conocimiento. En el sistema realice lo siguiente:

1. Seleccione la opción Categoría Opciones.

2. En la pantalla mostrada se muestran la lista de categorías, si quiere modificarla nombre de categoría opciones escriba en el cuadro de texto, puede eliminar la categoría presionando la opción Borrar.

3. Presione el botón Actualizar para que se guarden los datos. 4. Si quiere agregar una nueva categoría escriba en el campo Agregue Categoría. 5. Presione el botón Agregue Categoría.


Permite agregar o quitar ítems a la Base de Conocimiento, en el sistema realice lo siguiente:

1. Seleccione la opción Agregar a Conocimientos.


163

2. En la pantalla mostrada ingrese información referente a:

Campos Detalle

Grupo de Técnicos Seleccione el grupo al que va a añadir conocimiento

Categoría Seleccione categoría a añadir conocimiento





3. Finalmente presione el botón Agregar a Conocimiento.

Editar Conocimientos

Permite editar los ítems de conocimiento existentes en la Base de Conocimiento, en el sistema realice lo siguiente:

1. Seleccione la opción Agregar a Conocimientos. 2. En la pantalla mostrada se listan los ítems de conocimiento existentes mostrando

información referente a:


164

Campos Detalle

Grupo de Técnicos Es el grupo de Técnico al que pertenece el ítem de conocimiento

Categoría Corresponde a la categoría a la que esta añadida el ítem de conocimiento

Pregunta Muestra la pregunta de la Base de Conocimiento

Si quiere modificar información de un ítem de conocimiento presione sobre el campo Pregunta.

3. En la pantalla mostrada modifique la información requerida correspondiente a:

Campos Detalle

Grupo de Técnicos Seleccione el grupo al que va a añadir conocimiento

Categoría Seleccione categoría a añadir conocimiento





4. Finalmente presione el botón Editar Entada o Borrar Entada.


165

ANEXO [G] Encuestas realizadas a los técnicos que utilizaron la herramienta OneOrZero para gestión de incidentes y Tabulación de Resultados

ENCUESTA DE ATENCION A USUARIOS DEL SISTEMA SYLLABUS

La presenta encuesta tiene como finalidad examinar el registro de incidentes planteados por usuarios del sistema Syllabus al personal técnico del GDS. La información que se recabe será un valioso aporte para el proyecto “Implementación de un Centro de Servicio para el Grupo de Desarrollo de Software utilizando la metodología ITIL”

Se solicita responder a las siguientes preguntas:

1) Indique el (los) medio(s) como ha receptado un incidente a) Teléfono b) Personalmente c) Mediante Oficio d) Correo electrónico e) Msn f) Otro _____________________________________

2) ¿Guarda algún registro de cada incidente reportado a usted? a) Siempre b) Casi siempre c) A veces d) Nunca

3) ¿Qué medio utiliza para el registro de incidentes? Indique además el tiempo estimado que toma el registro.

Medio Tiempo estimado

4) Tiene algún formato definido para el registro del incidente?

SI NO

5) Si el incidente es resuelto ¿lleva el control del ciclo de vida del incidente?

SI NO


166

Por qué? ______________________________________________________________________

6) ¿Qué tan eficiente le resuelta el proceso llevado para el ciclo de incidentes? a) Excelente b) Muy Bueno c) Bueno d) Debe mejorar significativamente

7) ¿Ha utilizado alguna herramienta automática para el registro de incidentes?

SI NO

Indique el nombre _______________________________________________________________

8) ¿Conoce de alguna metodología para el tratamiento de incidentes?

SI NO

Indique el nombre _______________________________________________________________

Gracias por su colaboración


167

EVALUACION DE GESTION DE INCIENTES

UTILIZANDO LA HERRAMIENTA OneOrZero

La presente evaluación tiene como finalidad examinar el proceso de registro de incidentes planteado por el proyecto “Implementación de un Centro de Servicio para el Grupo de Desarrollo de Software utilizando la metodología ITIL” para técnicos del GDS que apoyan usuarios del sistema Syllabus.

Lo que se pretende es evaluar si la herramienta definida cumple con el proceso definido para el tratamiento de incidentes a través de la metodología ITIL.

Por lo que se solicita se sirva contestar las preguntas planteadas en el presente documento.

Proceso Gestión de incidentes

- Registro del incidente incluye asignar: prioridad, estado, asignado a, detalle del incidente.

- Clasificación: determinar categoría del incidente - Investigación y Diagnóstico - Resolución y Cierre del incidente (si es necesario escalar a otro nivel de soporte)

PREGUNTAS

Recepción y registro de incidentes

1. ¿Qué tiempo promedio toma el registro de cada incidente en la herramienta? 1. 0 a 2 minutos 2. 3 a 5 minutos 3. 5 a 10 minutos 4. Mas de 10 minutos

2. ¿Con qué frecuencia requiere modificar un incidente?

1. Siempre

2. Casi siempre

3. A veces

4. Nunca

3. ¿Considera que el tiempo utilizado en registrar el incidente es? 1. Adecuado 2. Medianamente adecuado 3. Parcialmente adecuado 4. Inadecuado


168

Características generales

Facilidad de uso

4. Para realizar su trabajo en el sistema, la interacción con el mismo es: 1. Muy Fácil 2. Fácil 3. Difícil 4. Muy difícil

Rapidez

5. Los tiempos de respuesta en el sistema son: • Excelentes • Muy buenos • Buenos • Malos

Completitud

6. La información del incidente que permite registrar la herramienta es:

1. Excede expectativas 2. Completa 3. Medianamente completa 4. Parcialmente completa

Seguimiento

7. La forma en que la herramienta le permite realizar el seguimiento de incidentes es: 1. Excelente 2. Muy buena 3. Buena 4. Mala

Reportes de operación

8. Los reportes que ha revisado de la herramienta le ofrecen información: 1. Excede expectativas 2. Completa 3. Medianamente completa 4. Parcialmente completa

Apoyo al trabajo diario

9. Sus actividades diarias respecto al registro de incidentes se han visto: 1. Altamente mejoradas 2. Medianamente mejoradas 3. Mejoradas 4. Siguen igual


169

Adaptación al proceso propuesto

10. La herramienta se adapta al proceso definido 1. Excede expectativas 2. Cumple Satisfactoriamente 3. Cumple parcialmente 4. No cumple

Comentarios

Indique las sugerencias/observaciones que tiene frente a la herramienta

1)

2)

3)

4)

5)

6)

Gracias por su valiosa colaboración!!!!


170

TABULACION DE RESULTADOS

CRITERIOS EVALUDOS:

CRITERIOS EVALUADOS A B C D Facilidad de uso 2 2 0 0 Rapidez 1 2 1 0 Completitud 0 2 2 0 Seguimiento 1 2 2 0 Reportes de operación 0 1 3 0 Apoyo al trabajo diario 0 3 1 0 Adaptación al modelo propuesto 0 3 1 0

ADAPTACION DE LA HERRAMIENTA AL PROCESO DE GESTION DE INCIDENTES

A B C D

excede

espectativas cumple satisf

cumple parcialment

No Cumple

1 0 1 0 0 2 0 1 0 0 3 0 0 1 0 4 0 1 0 0


171

ANEXO [H]: Anteproyecto de Tesis

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

ESCUELA DE CIENCIAS DE LA COMPUTACIÓN

ANTEPROYECTO DE TESIS

Tema:

“IMPLEMENTACIÓN DE UN CENTRO DE SERVICIO EN EL GRUPO DE

DESARROLLO DE SOFTWARE UTILIZANDO LA METODOLOGÍA ITIL”

Diana Rosa Díaz Cueva

TESISTA

Ing. Audrey Romero Peláez

DIRECTORA DE TESIS


172

1. PLANTEAMIENTO DEL PROBLEMA

La Universidad Técnica Particular de Loja, UTPL, es una institución ecuatoriana que brinda educación superior a más de 20.000 estudiantes a nivel local, nacional e internacional. Para ofrecer una educación de calidad, entre otros aspectos, requiere continuamente renovar, actualizar y/o mejorar sus procesos y recursos tecnológicos: por tanto, uno de los medios para conseguir sus objetivos es la inversión y aplicación de Servicios y Tecnologías de Información TI.

La UTPL cuenta con unidades dedicadas a la investigación, la extensión o servicio a la sociedad, llamadas Centros de Investigación y Trasferencia de Tecnología, CITTES; uno de los CITTES del área técnica es la Unidad de Proyectos y Sistemas Informáticos UPSI, a su vez esta conformada por equipos de trabajo como: Redes y Telecomunicaciones, Desarrollo de Software, Electricidad y Sistemas Electrónicos, Soporte e Investigación Tecnológica, Sistemas de Información Geográfica y Cursos Especializados.

El Grupo de Desarrollo de Software, área de la UPSI, tiene entre uno de sus objetivos la implementación y mantenimiento de Sistemas Informáticos; uno de los principales y de más alta trascendencia es el Sistema de Gestión Académica SYLLABUS, implementado a mediados del 2004. Actualmente es utilizado aproximadamente por 24.000 usuarios entre: secretarias de centros asociados y de carrera, centros extranjeros, departamento de contabilidad, profesores, estudiantes; el considerable número de usuarios, más la cobertura, servicios y procesos que cubre, genera una continua, grande y compleja tarea en el tema de soporte del sistema, especialmente en períodos de matrícula, ingreso de notas de modalidad abierta y clásica, registro de trabajos de modalidad abierta, entre otros, este proceso se vuelve tedioso por las frecuentes llamadas de los usuarios solicitando ayuda en cuanto a la operatividad del sistema.

A medida que se ha ido incrementando el número de usuarios también se ha incrementado el servicio de soporte al sistema, algunos de los inconvenientes suscitados se detallan a continuación:

Hardware, software y redes:

• La pérdida de conexión a Internet en los equipos de los usuarios, impide su trabajo por cuanto la aplicación trabaja en web.

• El cliente web (Internet Explorer) que utiliza el usuario para conectarse a la aplicación no está actualizado, ya que la aplicación trabaja sobre la versión 6.0 o superior.


173

• El usuario desconoce las configuraciones de las herramientas sobre las que opera el sistema.

• Restricción o falta de permisos de red para acceder al sistema. • Falta ayuda en línea para el usuario, esto ocasiona que esté llamando constantemente

sin tener un apoyo para solucionar el problema. • Infecciones de virus u otro software malicioso.

Procesos críticos

• Congestión y/o sobrecarga en los servidores de aplicaciones y de base de datos que ofrecen el servicio; especialmente cuando coinciden algunos procesos críticos o de uso intensivo del sistema.

• Por el dinamismo y complejidad del negocio no se cuenta con el tiempo y los recursos necesarios para poder desarrollar y asegurar la calidad del sistema, por lo que: - Algunos usuarios son quienes detectan los errores e issues no detectados, lo que

hace que la versión cargada mantenga problemas al ser utilizada. - Además por la omisión de algunas de las configuraciones necesarias en la

aplicación, el usuario final se ve limitado al momento de utilizar la aplicación. - Por los requerimientos urgentes de los usuarios se suben versiones en caliente, lo

que provoca la falla en algunas funcionalidades y causa inconvenientes al utilizar la aplicación.

• Por errores y fallas en los sistemas informáticos con los que se relaciona el sistema académico se ven afectadas ciertas funcionalidades, lo que impiden el trabajo de las personas que utilizan la aplicación.

Desconocimiento de funcionalidades y desorganización en el proceso:

• Desconocimiento por parte de los usuarios sobre el funcionamiento de algunas opciones del sistema, ya sea porque es la primera vez que utiliza la funcionalidad o por cambios en la misma.

• Falta de análisis por parte del usuario para determinar si el problema es causado por el sistema, el equipo o la herramienta sobre la que trabaja.

• Falta de agilidad en el proceso de soporte por no existir una base de conocimiento en la cual se vayan registrando todos los incidentes y las soluciones.

• Falta de asistencia por parte de los usuarios finales para la solución de problemas presentados.

• Falta de disponibilidad en la resolución de problemas por parte de técnicos o desarrolladores, y que no pueden ser resueltos por el personal de soporte.


174

A medida que se han ido incorporando diferentes actividades en cuanto al soporte al usuario se ve la necesidad de tener un grupo especializado para la atención de todos los incidentes presentados, el mismo que con ayuda de una herramienta realizarán el registro de incidentes, lo que permitirá ir alimentando una base de conocimiento donde se vayan almacenando todas las soluciones respecto de los incidentes presentado y que sirvan como herramienta de ayuda al personal de soporte.

El Centro de Servicio será el punto de contacto definido específicamente para recoger los requerimientos de los usuarios y será responsable de atender el caso, darle el seguimiento necesario, hasta llegar a la solución del mismo.

SUSTENTACION

Objetivo General:

Implementar un Centro de Soporte en el Grupo de Desarrollo de Software para brindar a los usuarios un servicio de calidad frente al Sistema de Gestión Académica utilizando la metodología ITIL.

Objetivos Específicos:

- Analizar la metodología ITIL en cuanto a procesos, recomendaciones, gestión de servicios de TI.

- Definir un proceso formal que permita mejorar la entrega del servicio a los usuarios finales para tener un mayor control de los requerimientos de soporte.

- Ofrecer un servicio de calidad al usuario, al menor costo posible y con el mayor aprovechamiento del recurso humano.

- Implantar procesos ITIL en la organización, de acuerdo a su estructura y a las necesidades.

2. ALCANCE DEL PROYECTO

Para hacer frente a la falta de un proceso de soporte formalizado, se propone la implantación de las mejores prácticas ITIL, este es un proceso que está compuesto de un conjunto de mejores prácticas reconocidas internacionalmente lo que permitirá gestionar, administrar y operar servicios de TI.

El proyecto incluirá la creación de un Centro de Soporte y Help Desk en la UTPL que aplique el proceso ITIL, con el apoyo de técnicos con los que se pretende gestionar de forma más eficiente los recursos y brindar una mejor calidad en el servicio.


175

El objetivo es implantar un Centro de Servicios cuya finalidad es mejorar la satisfacción de los usuarios del Sistema de Gestión Académica y la imagen de la organización, además permita identificar nuevas oportunidades de negocio.

Se pretende trabajar sobre el componente de Gestión de servicios, ya que lo que se persigue es implantar las actividades de:

Gestión de la Incidencia: en este componente se definirán perfiles o roles para las personas involucradas en el proceso de recabar incidentes reportados por los usuarios, además del control del flujo de los incidentes.

Se encargará de:

Detección y registro de incidencias Clasificación de incidencias y soporte inicial Resolución y cierre de incidencias Empoderamiento y seguimiento de incidencias

Gestión del Problema: encargado de identificar las causas que originaron el incidente, recomendar soluciones temporales o definitivas y evaluar los resultados de las soluciones.

Las responsabilidades principales son:

Identificación y registro de problemas Clasificación del problema Investigación y diagnóstico de problemas Revisión de problemas Informes sobre la causa de los problemas

Gestión del Nivel de Servicio: se definirá tareas de negociación, definición, manejo y mejora de la calidad de los servicios de TI a un coste aceptable.

Centro de servicio: este es el punto de contacto del cliente con la empresa, con la finalidad de solventar el problema de los usuarios, se ve la necesidad de implementar algunas funciones como:


176

Help Desk: desde el cual se gestiona, coordina y solventa los incidentes, utilizando herramientas de ayuda.

Service Desk: a más de solventar incidentes es un punto de contacto para recibir solicitudes de cambio por parte de clientes, gestión de nivel de servicio, etc, engloba aspectos relacionados con todo el proceso interno de la institución.


Recibir todas las llamadas de los usuarios Ofrecer una evaluación inicial e intentar la resolución por este primer

nivel Controlar y escalar las incidencias a los niveles adecuados Proporcionar soluciones oportunas a los usuarios

Gestión de Cambios: llevar de manera formal los requerimientos de modificación a las aplicaciones en base a la solicitud de los usuarios de forma más eficiente posible en tiempo, coste y calidad.


Elevar y registrar solicitudes de cambio Evaluar el impacto, gastos, beneficios y riesgos de un cambio Obtener la aprobación correspondiente para los cambios Gestionar la implementación de los cambios Controlar e informar acerca de la implementación Revisar y cerrar las solicitudes de cambio

Con la implementación de ITIL se está creando una cultura de servicio, que permita un manejo eficiente de recursos y lograr un grado de satisfacción para clientes y usuarios, lo que permitirá crear un clima de trabajo agradable.

Se debe tener presente que la prestación de servicios es una actividad de vital importancia dentro de una organización, ya que de la atención eficaz que se brinde depende el éxito de la misma.


177

CONTENIDOS DE CADA UNA DE LAS FASES

FASE 1.- Estudio de ITIL conceptos y mejores prácticas

Esta primera fase comprende una revisión general del tema de ITIL

Objetivos Propósito Conceptos básicos Mejores prácticas, etc.

FASE 2.- Diseño de procesos para el Centro de Servicio al usuario dentro de la organización

Se definirán las actividades por cada componente:

Service Desk Gestión de Incidencias Gestión de Problemas Gestión de Cambios

Además de la definición de un proceso aceptable para el funcionamiento del Centro de Servicio.

FASE 3.- Definir herramientas utilizadas en el Centro de Soporte al usuario

En ésta fase se analizarán algunas herramientas que ayuden al registro y administración de los incidentes presentados, y determinar una herramienta que pueda ser utilizada en el centro de servicio al usuario. Además, métricas que permitan medir las variables involucradas, para posteriores análisis y correctivos.

FASE 4.- Ejecución del Plan Piloto

Se espera la ejecución de un plan piloto donde se verá reflejado el estudio de ésta investigación. Este plan piloto incluye tomar el Sistema de Gestión Académica que está en producción en la UTPL, y sobre éste analizar el modelo propuesto y aplicar mejoras al mismo.

Luego de la aplicación del piloto se realizará la validación y refinación del mismo, con el objetivo que sea un modelo óptimo y que solucione eficientemente la problemática actual.

FASE 5.- Conclusiones y Recomendaciones

Conclusiones


178

Recomendaciones 3. CRONOGRAMA

FASE 1.- ITIL conceptos y mejores prácticas. 19 days 20/11/2007 14/12/2007

FASE 2.- PROPUESTA PARA EL DISEÑO DEL CENTRO DE SERVICIO AL USUARIO EN LA ORGANIZACIÓN 52 days 17/12/2007 26/02/2008

- Service Desk 9 days 17/12/2007 27/12/2007

- Determinar necesidades de capacitación para los clientes. 4 days 17/12/2007 20/12/2007

- Definir un proceso para proporcionar información y recomendaciones para la mejora del servicio 5 days 21/12/2007 27/12/2007

- Gestion de Incidentes 21 days 28/12/2007 25/01/2008

- Crear procesos, procedimientos e instrucciones de trabajo para la gestion de incidentes 7 days 28/12/2007 07/01/2008

- Definir procesos y procedimientos para correcta escalación de incidentes a grupos especializados 6 days 08/01/2008 15/01/2008

- Crear una Base de conocimiento con informacion de soluciones de incidentes presentados 4 days 16/01/2008 21/01/2008

- Identificación de roles y responsabilidades para la Administración de Incidentes y Problemas 4 days 22/01/2008 25/01/2008

- Gestión de Problemas 15 days 28/01/2008 15/02/2008

- Documentar las soluciones a los posibles problemas producidos en la aplicacion 8 days 28/01/2008 06/02/2008

- Definir un plan de actividades para el tratamiento de problemas 7 days 07/02/2008 15/02/2008

- Gestión de Cambios 7 days 18/02/2008 26/02/2008

- Instaurar normas y procedimientos para registrar los cambios solicitados en las aplicaciones 7 days 18/02/2008 26/02/2008

FASE 3.- Herramientas automáticas utilizadas en el Centro de soporte al usuario 22 days 27/02/2008 27/03/2008

- Investigar sobre herramientas para el manejo de incidentes. 10 days 27/02/2008 11/03/2008

- Seleccion y evaluacion de la herramienta 8 days 12/03/2008 21/03/2008

- Pruebas de la herramienta 4 days 24/03/2008 27/03/2008

FASE 4.- Ejecución del Plan Piloto 22 days 28/03/2008 28/04/2008

- Planificación del plan piloto 2 days 28/03/2008 31/03/2008

- Desarrollo de items para el plan piloto 4 days 01/04/2008 04/04/2008

- Aplicación del plan piloto 16 days 21/04/2008 28/04/2008

FASE 5.- Conclusiones y Recomendaciones 3 days 29/04/2008 01/05/2008

- Conclusiones 2 days 29/04/2008 30/04/2008

- Recomendaciones 1 day 01/05/2008 01/05/2008


179

4. PRESUPUESTO

RECURSO HUMANO

Cantidad Descripción #horas/ semana

Valor/hora Total Horas/m

es

Total

1 Director de Tesis 5

1 Tesista 20 4 80 1600,00

Total Recursos Humanos 1600,00

Recursos de Software y Hardware

Cantidad Descripción Valor Total

400 horas Servicio de Internet(horas) 1,00 400,00

1 Computador Personal (c/hora) 640,00 640,00

1 Impresora 70,00 70,00

1 Servicios Básicos(Luz, CDS, esferográficos, papel) 200,00 200,00

1 Anillados y Copias 80,00 80,00

1 Microsoft Windows XP 194,00 194,00

1 Microsoft Office 174,00 174,00

1 Microsoft Visio Pro 236,00 236,00

1 Software adicional 400,00 400,00

1 Capacitación 300,00 300,00

1 Libros 200,00 200,00

Total Recursos Software y Hardware 2894,00

Subtotal 4494,00

Imprevistos (10%) 449,40

Total del proyecto 4943,40

BIBLIOGRAFIA ANTEPROYECTO:

[1] EuroPortal ITIL, Como Introducir ITIL, [en línea], [citado septiembre del 2007] disponible en: http://www.portal-itil.eu/consult_como.php

[2] José Mª de Arce, Buscando Sentido, una introducción a ITIL, [en línea], [citado octubre del 2007] disponible en: http://www.fys.es/fys/cm_view_tpyr.asp?tipo=articulos&id=551

[3] Osiatis, Curso de ITIL, [en línea], [citado octubre del 2007] disponible en: http://itil.osiatis.es/Curso_ITIL/

TESIS CAMBIOS FINAL v3dspace.utpl.edu.ec/bitstream/123456789/1701/3/Díaz Cueva Diana Rosa.pdf · y...

Documents

Transcript of TESIS CAMBIOS FINAL v3dspace.utpl.edu.ec/bitstream/123456789/1701/3/Díaz Cueva Diana Rosa.pdf · y...