Embed Size (px)
Citation preview
UNIVERSIDAD POLITÉCNICA SALESIANA
SEDE GUAYAQUIL
CARRERA: INGENIERÍA DE SISTEMAS
Proyecto previo a la obtención del título de:
INGENIERO DE SISTEMAS
TEMA:
REESTRUCTURACIÓN DE LA MESA DE SERVICIOS PARA MEJORAS EN EL
CONTROL DE INCIDENTES, BASADAS EN ITIL V3
AUTORES:
JOEL ELÍAS MOSCOSO VILLALVA
JULIO JOSEPH MANOBANDA HERRERA
TUTOR:
ING. GALO VALVERDE
Guayaquil, febrero 2016
1
DECLARATORIA DE RESPONSABILIDAD Y AUTORIZACIÓN DE USO DEL
TRABAJO DE GRADO
Nosotros, Joel Elías Moscoso Villalva y Julio Joseph Manobanda Herrera, autorizamos a
la Universidad Politécnica Salesiana la publicación total o parcial de este trabajo de
grado y su reproducción sin fines de lucro.
Además declaramos que los conceptos, análisis desarrollados y las conclusiones del
presente trabajo son de exclusiva responsabilidad de los autores.
Joel Elías Moscoso Villalva Julio Joseph Manobanda Herrera
CI: 9019759159 CI: 0927355289
Guayaquil, febrero del 2016
2
Tabla de contenido
Resumen ............................................................................................................................. 7
Abstract .............................................................................................................................. 8
Introducción ....................................................................................................................... 9
Objetivos .......................................................................................................................... 10
Objetivo general ........................................................................................................... 10
Objetivos específicos .................................................................................................... 10
Desarrollo del proyecto .................................................................................................... 11
1. El problema .............................................................................................................. 11
2. Análisis del problema ............................................................................................... 11
2.1 Registro manual de novedades ....................................................................... 11
2.2 Falta de clasificación ...................................................................................... 12
2.3 Manejo de criterios de prioridad y criticidad sin una matriz .......................... 12
2.4. Falta de documentación de procedimientos, diagramas de flujo de atención
de incidentes, escalamiento y solución. .............................................................. 12
2.5. Falta de definición de responsabilidades y roles de cada actor ..................... 13
3. Solución ................................................................................................................... 13
3.1. Ciclo de vida del servicio .............................................................................. 16
3.1.1. Estrategia del servicio .................................................................... 16
3.1.2. Diseño del servicio ......................................................................... 16
3.1.3. Transición del servicio ................................................................... 17
3.1.4. Operación del servicio ................................................................... 17
3.1.5. Mejora Continua del Servicio ........................................................ 17
3.2. Generación de documentación ..................................................................... 17
3.3. Definición de roles y responsabilidades ........................................................ 18
3.4. Definición del Catálogo de Servicios ............................................................ 18
3.5. Definición de Procesos .................................................................................. 18
3.6. Uso de herramienta para automatización ...................................................... 19
4. Desarrollo ................................................................................................................ 19
5. Implementación OTRS ............................................................................................ 30
3
5.1. Requisitos de hardware y software generales ............................................... 30
5.1.1. Requisitos de software específicos en Servidor .............................. 31
5.1.2. Requisitos a nivel de base de datos ................................................ 31
5.1.3. Navegadores Web ........................................................................... 31
5.2. Modelo Entidad Relación .............................................................................. 32
5.3. Modelo V-C (Vista – Controlador) .............................................................. 32
5.3.1. Modelo ............................................................................................ 32
5.3.1. Vista ................................................................................................ 32
5.3.3. Controlador .................................................................................... 33
5.4. Cronograma ................................................................................................... 33
5.4.1. Planificación ................................................................................... 33
5.4.2. Implementación y Ejecución ........................................................... 33
5.4.3. Cierre .............................................................................................. 38
6. Métricas ................................................................................................................... 39
7. Resultados ............................................................................................................... 40
8. Conclusiones ........................................................................................................... 45
9. Recomendaciones .................................................................................................... 47
10. Trabajos futuros ..................................................................................................... 48
11. Referencias bibliográficas ..................................................................................... 49
12. Glosario ................................................................................................................. 50
13. Codificación de documentos ................................................................................. 55
4
Índice de Tablas
Tabla 1.- Información de caso de uso para gestión de incidencias (general) ................... 21
Tabla 2.- Información de caso de uso para gestión de incidencias (detallado) ................ 24
Tabla 3.- Comparativo características técnicas recomendadas vs producción ................ 34
Tabla 4.- Definición de Métricas de Mesa de Servicios ................................................. 39
5
Índice de figuras
Figura 1. Causas y Efectos del manejo de un Departamento de TI sin Help Desk ................ 133
Figura 2. Creación de valor en una empresa .......................................................................... 155
Figura 3. Ciclo de vida del Servicio ....................................................................................... 166
Figura 4. Estructura actual del departamento de Sistemas en la empresa FARLETZA ........ 199
Figura 5. Estructura propuesta para la Reestructuración de la Mesa de Servicios ................... 20
Figura 6.- Diagrama de caso de uso OTRS .............................................................................. 23
Figura 7.- Inicio de sesión en sistema OTRS ......................................................................... 355
Figura 8.- Cierre del ticket en la herramienta OTRS ............................................................. 366
Figura 9.- Confirmación de registro automático mediante correo ......................................... 366
Figura 10.- Asignación de ticket generado mediante correo electrónico ............................... 377
6
Índice de Anexos
ANEXO 1.-FAR-DIA-TI-001 Procedimiento de atención de llamadas.
ANEXO 2.-FAR-DIA-TI-002 Procedimiento de atención y escalamiento.
ANEXO 3.-FAR-DIA-TI-003 Procedimiento para la documentación de
soluciones.
ANEXO 4.- FAR-DIA-TI-004 Procedimiento para Gestión de Incidentes.
ANEXO 5.- FAR-INS-TI-001 Instructivo para clasificación de correos.
ANEXO 6.- FAR-MAN-TI-001 Manual de instalación sistema OTRS.
ANEXO 7.- FAR-MAN-TI-002 Manual de integraciones.
ANEXO 8.- FAR-MAN-TI-003 Manual de parametrización y configuración.
ANEXO 9.- FAR-MAN-TI-004 Manual de usuario OTRS.
ANEXO 10.- FAR-PRO-TI-001 Procedimiento de atención de llamadas.
ANEXO 11.- FAR-PRO-TI-002 Procedimiento de atención y escalamiento.
ANEXO 12.- FAR-PRO-TI-003 Procedimiento para la documentación de
soluciones.
ANEXO 13.- FAR-VAR-TI-001 Matriz de priorización de incidentes (SLA).
ANEXO 14.- FAR-VAR-TI-002 Esquemas de trabajo por nivel.
ANEXO 15.- FAR-VAR-TI-003 Responsabilidades por nivel.
ANEXO 16.- FAR-VAR-TI-004 Catalogo de Servicios.
ANEXO 17.- FAR-VAR-TI-005 Modelo Entidad-Relación.
ANEXO 18.- FAR-VAR-TI-006 Modelo Vista-Controlador.
ANEXO 19.- Cronograma de actividades.
7
Resumen
En las observaciones realizadas dentro del departamento de Sistemas, se encontraron
varias necesidades, entre las cuales, la prestación de servicios de mejor calidad a sus
clientes internos es una de las principales. Con la reestructuración de la actual Mesa de
Servicios, se pretende lograr una mejor coordinación, organización, seguimiento y
resolución de los incidentes, previniendo la problemática que puede generar la falta de
uso de herramientas asociadas a buenas prácticas ITIL.
Para la reestructuración de la Mesa de Servicios se utilizará la metodología de
investigación basada en la observación. La Mesa de Servicios se debe establecer como
el único punto de contacto entre el departamento de Sistemas y las áreas operativas de la
empresa, para mejorar el registro de incidentes, así como el seguimiento de la solución y
la comunicación entre el departamento de Sistemas y el usuario.
Los procesos a implementarse son:
Gestión de incidentes: Identificar los agentes, grupos solucionadores,
asignación de la prioridad de atención entre otros indicadores basados en ITIL
v3.
Ciclo de atención: Definir el ciclo de atención, desde que se recibe la novedad
o incidencia hasta que se brinde una solución, sea esta temporal (Workaround)
o definitiva.
La Mesa de Servicios está encargada de receptar solicitudes de atención y viabilizar
la ayuda ante los diferentes grupos (N1 “Agente de atención remota”, N2 “Agente de
soporte en sitio” o N3 “Especialistas”), dar seguimiento a los casos abiertos y mantener
informado a los usuarios. Para la reestructuración de la Mesa de Servicios utilizaremos
una herramienta Open Source OTRS (Open Technology Real Services).
8
Abstract
In the comments made within the Systems Department, they met various needs;
including the provision of better quality services to its internal customers is a major.
With the restructuring of the current Bureau of Services, it is to achieve better
coordination, organization, tracking and resolution of incidents, preventing problems
that can lead to a lack of use of tools associated with ITIL best practices.
For the restructuring of the service desk methodology based on observation
investigation shall be used. The Service Desk should be established as the single point of
contact between the IT department and the operating areas of the company, to improve
the recording of incidents and monitoring the solution and communication between the
Department of Systems and user.
The processes are implemented:
• Incident Management: Identify the agents solvers groups, assigning priority
attention among other indicators based on ITIL v3.
• Cycle Care: Defining a cycle of attention from the novelty or incident is received
until a solution is provided, be it temporal (Workaround) or permanent.
The Service Desk its responsible for both receive, applications for incident response
and facilitate the assistance to different groups of specialists (N1 "Remote Agent care,"
N2 "Agent site support" or N3 "Specialists"), also responsible for following up on the
open cases and keeping users informed about new reported. For the restructuring of the
Bureau of Services will use an open source OTRS tool (Open Technology Real
Services).
9
Introducción
ITIL v3 define buenas prácticas para el manejo de la gestión con el cliente interno y
externo al área de TI, esto permite brindar un servicio de calidad, reduciendo el impacto
y el tiempo de respuesta ante las novedades que se presentan a diario en una empresa.
La compañía FARLETZA cuenta con un departamento de Sistemas estructurado de la
siguiente manera:
Soporte técnico
Coordinador
La gestión de incidencias es manejada por dos recursos de soporte a usuarios, que
realizan la función de agentes telefónicos, para la recepción de llamadas de los clientes
internos y externos del área de TI. El trabajo de los agentes se detalla a continuación:
Recepción de llamadas
Registro de novedades en un documento de Excel
Atención de novedades.
Notificación de solución a los usuarios
Existen muchos casos de éxito sobre la implementación de Mesa de Servicios y de
ITIL, ya que ITIL tiene las siguientes funcionalidades:
Alinea TI con el negocio
Mejora la calidad del servicio de TI
Reduce los costos de provisión del servicio
Promueve el trabajo en equipo
El uso de buenas prácticas nos permite ofrecer un servicio efectivo, muy por encima
de lo que significaría brindar un servicio eficaz o eficiente.
10
Objetivos
Objetivo general
Utilizar las mejores prácticas recomendadas por ITIL V3 en la empresa, a través de la
reestructuración de la Mesa de Servicios.
Objetivos específicos
Levantar métricas basadas en ITIL.
Fortalecer líneas de comunicación entre el área de TI con las áreas operativas
Establecer las responsabilidades de cada rol en el área de Sistemas
11
Desarrollo del proyecto
1. El Problema.
El actual proceso de atención, refleja las siguientes particularidades:
Registro de novedades de manera manual en un documento de Excel.
Falta de clasificación de correos.
Manejo de criterios de prioridad y criticidad sin una matriz.
Falta de documentación en cuanto a procedimientos, diagramas de flujo de
atención.
Falta de definición de responsabilidades y roles de cada actor.
Se depende únicamente del criterio de las personas que receptan las novedades que
genera la empresa, sin contar con un esquema de servicio estructurado ni automatizado
2. Análisis del problema
Se revisa de manera puntual todas las novedades encontradas en el levantamiento de
información:
2.1. Registro manual de novedades.
Los agentes de soporte llevan un registro manual de las incidencias generadas por el
negocio, lo que limita la obtención de estadísticas reales en los tiempos de atención, de
solución, búsqueda de casos y documentación de la solución, registros duplicados,
omisión de generación de tickets o en el peor de los casos, omisión de registro, lo que
provoca una no atención en muchas ocasiones.
12
2.2. Falta de clasificación.
Los correos que llegan no tienen una adecuada clasificación, esto provoca que existan
correos de incidencias que no han sido considerados para atención; se depende
demasiado de la memoria de los agentes de soporte que receptan las novedades.
Los correos que llegan a esta cuenta común son consumidos por dos personas de
soporte y un Coordinador, al no estar clasificados, conlleva a cometer errores de
duplicación u omisión de atención, esto aumenta los tiempos de atención y solución.
2.3. Manejo de criterios de prioridad y criticidad sin una matriz.
No contar con una matriz de definición de prioridades y criticidad, no permite
priorizar la atención de los incidentes por parte del personal de soporte.
Se depende del criterio personal del agente receptor, lo que representa un riesgo, el
cual debe ser remediado estableciendo una única matriz, socializada para los agentes
actuales y documentada para que los futuros agentes, tengan claro cómo proceder ante
una incidencia.
2.4. Falta de documentación de procedimientos, diagramas de flujo de atención
de incidentes, escalamiento y solución.
Se identifica que existe una falencia en la documentación utilizada para procesos de
atención de incidentes, definición de prioridades, entre otros documentos, que son
necesarios para evitar la dependencia de criterios personales, los cuales se encuentran
establecidos actualmente por factores como la costumbre; las personas llegan a entrar en
una zona de confort.
13
2.5. Falta de definición de responsabilidades y roles de cada actor.
Se necesita definir roles específicos sobre cada actor y sus responsabilidades dentro
del ciclo de vida del servicio, desde su notificación hasta su solución.
Dentro del análisis se definen las necesidades, esto ayuda a identificar las soluciones
a implementar y los entregables del proyecto que se presentarán en el apartado de
anexos.
3. Solución
En la Figura 1 se muestra un resumen que contiene las causas principales y efectos,
que representan las diferentes problemáticas de trabajar sin una Mesa de Servicios
alineada a las buenas prácticas de ITIL. Los departamentos de TI que laboran sin la
implementación de una Mesa de Servicios están expuestos a proyectar una imagen de
bajo rendimiento, poca productividad y lentitud en la resolución de incidentes y
requerimientos.
Figura 1. Causas y Efectos del manejo de un Departamento de TI sin Help Desk
Elaborado por: Autores
14
La prestación de servicios tecnológicos sin una guía de buenas prácticas como ITIL,
provoca inconformidades en los usuarios finales y los responsables de sistemas. A
continuación se detalla una lista de los inconvenientes que se presentan:
Trabajo sin una metodología comprobada de resolución de incidentes.
Poca cooperación entre los departamentos (Operación, Desarrollo y Usuario
final).
Jornadas extendidas de trabajo.
Conflictos entre el personal de sistemas por fallas.
Poca escalabilidad en la prestación del servicio ante el crecimiento del
negocio.
Gastos de inversión tecnológica innecesarios
Todos los aspectos negativos se deben a la falta de implementación de herramientas
de Help Desk, alineadas a normas como ITIL.
El uso de una Mesa de Servicios basada en ITIL tiene como principales objetivos la
alineación de las áreas operativas al departamento de TI, llámese áreas operativas a los
diferentes departamentos de: Ventas, Marketing, Producción, Administración, etc.
ITIL usa un marco de trabajo asociado a diferentes librerías de referencia de buenas
prácticas para el manejo de gestión de tecnologías informáticas. ITIL tuvo sus inicios en
el Reino Unido en al año de 1987 por los funcionarios de la CCTA (Central Computer
and Telecommunications Agency) debido a la dependencia que se estaba generando
entre las organizaciones y las tecnologías de la información. Debido a esta dependencia
surgió la idea de desarrollar un marco de referencia para ayudar a las organizaciones a
gestionar su infraestructura tecnológica con eficacia y eficiencia proporcionando
servicios de calidad (IBPI, 2013).
15
Uno de los aspectos importantes que ofrece ITIL es la creación de valor en la
empresa, los servicios son definidos en ITIL como un medio de aportar valor al cliente
sin que éste deba asumir los riesgos y costes específicos de su prestación, Figura 2.
El valor al que nos referimos no depende del valor económico asociado al resultado
específico de cada servicio. Un servicio, por ejemplo, puede ofrecer una interesante
utilidad a buen precio pero si el cliente percibe una alta sensación de riesgo no lo
contratará (OSIATIS S.A).
Es importante lograr transmitir al cliente los beneficios del uso de ITIL en una
empresa ya que como se vio anteriormente, a pesar de ofrecer una reducción de costos y
una mejora en la calidad del servicio, esto no implica que la gerencia pueda tomar como
viable una propuesta.
Figura 2. Creación de valor en una empresa
Elaborado por: Osiatis.S.A
16
3.1. Ciclo de vida del servicio.
ITIL V3 estructura la gestión de los servicios TI sobre el concepto de Ciclo de Vida
de los Servicios, este enfoque tiene como objetivo ofrecer una visión global de la vida de
un servicio desde su diseño hasta su eventual abandono, sin por ello ignorar los detalles
de todos los procesos y funciones involucrados en la eficiente prestación del mismo,
Figura 3.
El Ciclo de Vida del Servicio consta de cinco fases:
3.1.1. Estrategia del Servicio.
Propone tratar la gestión de servicios no sólo como una capacidad sino como un
activo estratégico.
3.1.2. Diseño del Servicio.
Cubre los principios y métodos necesarios para transformar los objetivos estratégicos
en portafolios de servicios y activos.
Figura 3. Ciclo de vida del Servicio
Elaborado por: Osiatis.S.A
17
3.1.3. Transición del Servicio.
Cubre el proceso de transición para la implementación de nuevos servicios o su
mejora.
3.1.4. Operación del Servicio.
Cubre las mejores prácticas para la gestión del día a día en la operación del servicio.
3.1.5. Mejora Continua del Servicio.
Proporciona una guía para la creación y mantenimiento del valor ofrecido a los
clientes a través de un diseño, transición y operación del servicio optimizado (OSIATIS
S.A).
3.2. Generación de documentación.
La evidente falta de documentación debe ser solventada con la generación de
información, para el uso de la Mesa de Servicios, que debe estar publicada en un
repositorio único, con acceso para todos los actores de cada nivel de atención, desde el
N1 hasta el N3.
La documentación generada en este proyecto es:
ANEXO 5.- FAR-INS-TI-001Instructivo para clasificación de correos.
ANEXO 10.- FAR-PRO-TI-001 Procedimiento de atención de llamadas.
ANEXO 13.- FAR-VAR-TI-001 Matriz de priorización de incidentes (SLA).
ANEXO 11.- FAR-PRO-TI-002 Procedimiento de atención y escalamiento
ANEXO 12.- FAR-PRO-TI-003 Procedimiento para la documentación de
soluciones
ANEXO 14.- FAR-VAR-TI-002 Esquemas de trabajo por nivel
18
3.3. Definición de roles y responsabilidades.
La definición de los roles y responsabilidades han sido documentados con base en los
niveles de atención, actividades identificadas y personal disponible en el departamento
de Sistemas.
Los roles de todos los actores presentes en el ciclo de vida del servicio son:
Agente de Mesa de Servicios (Nivel 1).
Agente de Soporte en sitio (Nivel 2).
Especialista (Nivel 3)
Coordinador de Servicios.
El detalle se encuentra en el apartado de anexos. Revisar anexo 15.
3.4. Definición del Catálogo de Servicios.
Se toman en cuenta los procesos de negocio identificados en la empresa, para la
elaboración del Catálogo de Servicios. Estos servicios son parametrizados dentro de la
herramienta OTRS en combinación con la Matriz de Priorización de incidentes, para
automatizar el registro de tiempos de atención y solución. Revisar anexo 9.
3.5. Definición de Procesos.
Los procesos originados a partir de la definición de los procedimientos se encuentran
estructurados en los siguientes diagramas:
ANEXO 1.- FAR-DIA-TI-001 Procedimiento de atención de llamadas
ANEXO 2.- FAR-DIA-TI-002 Procedimiento de atención y escalamiento
ANEXO 3.- FAR-DIA-TI-003 Procedimiento para la documentación de
soluciones
ANEXO 4.- FAR-DIA-TI-004 Procedimiento para Gestión de Incidentes
19
3.6. Uso de herramienta para automatización.
Para solventar la problemática planteada en el proyecto, se debe utilizar la
herramienta OTRS, utilizando el modulo de Gestión de incidencias cuyo proceso está
certificado en ITIL V3.0, lo que va en sintonía con el marco de buenas prácticas que se
utiliza para la reestructuración de la Mesa de Servicios. Todos los documentos
mencionados en cada solución se encuentran en el apartado de anexos.
4. Desarrollo
En la Figura 4 se muestra la distribución del personal actual en el departamento de
Sistemas de la empresa Farletza. Como se muestra, el departamento cuenta con dos
personas de Soporte Técnico que brindan asistencia de manera remota y en sitio, así
como de un Coordinador, quien se encuentra encargado de supervisar las actividades del
personal y recoger las necesidades o incidencias de los clientes.
Figura 4. Estructura actual del departamento de Sistemas en la empresa FARLETZA
Elaborado por: Autores
20
Las actividades asignadas al personal de atención al usuario se distribuyen de la
siguiente manera:
Soporte técnico
o Encargado del soporte infraestructura tecnológica:
Redes
Servidores
Equipos de computo
Soporte técnico
o Encargado de soporte aplicaciones
En la Figura 5, se muestra la propuesta con una estructura basada en roles de ITIL
V3, en donde se definen las responsabilidades específicas que cada nivel debe ejercer.
Figura 5. Estructura propuesta para la Reestructuración de la Mesa de Servicios
Elaborado por: Autores
21
Sin embargo, este esquema depende de la demanda actual de la empresa, que cuenta
con 120 usuarios internos, motivo por el cual sugerimos que la persona que debe cumplir
el rol de Agente N1, sea considerada para contratar en caso que la demanda de atención
aumente.
Por ahora, los Agentes N2 y N3, asumen las funciones del Agente N1, de esta manera
se mantiene el concepto de la Mesa de Servicios como único punto de contacto, sin
descuidar la recepción de solicitudes o incidencias vía telefónica y vía correo,
incluyendo el correcto registro de cada caso en la herramienta de gestión.
Para el desarrollo del proyecto se han considerado los siguientes casos de uso, Tablas
1 y 2:
Gestión de incidencia con el sistema OTRS (Diagrama general)
Detalle: La gestión de incidencias se la realiza con la herramienta OTRS, a
continuación se procede a indicar paso a paso el ciclo de atención
Secuencia Ideal
Usuario, reporta a la Mesa de
Servicio.
Soporte N1, atiende solicitud.
Soporte N1, brinda solución.
Soporte N1, registra solución en la
herramienta, Soporte N1, comunica
la valida con el usuario la atención.
Usuario, confirma atención.
Soporte N1, cierra incidencia.
Secuencia más frecuente
Usuario reporta a la Mesa de
Servicio.
Soporte N1, atiende solicitud.
Tabla 1.- Información de caso de uso para gestión de incidencias (general)
22
Soporte N1, escala a soporte en
sitio.
Soporte N2, revisa cola de atención.
Soporte N2, atiende incidente y
confirma atención con usuario
Soporte N2, registra solución en la
herramienta y cierra ticket.
Secuencia de atención Soporte N3
Usuario, reporta a la Mesa de
Servicio.
Soporte N1, atiende solicitud.
Soporte N1, escala a soporte en
sitio.
Soporte N2, revisa cola de atención.
Soporte N2, revisa incidencia.
Soporte N2, escala a especialistas.
Soporte N3, atiende incidente.
Soporte N3, comunica a Soporte N1
de la atención.
Soporte N3, registra solución en la
herramienta y cierra ticket.
Soporte N1, valida con el usuario la
atención.
Usuario, valida la correcta atención.
Soporte N1, no registra novedades
en el sistema.
Secuencia con excepción por causa de
problemas
Usuario, reporta a Soporte N1 o
Soporte N2 la inconformidad de
atención
Soporte N1, abre nuevamente el
ticket.
23
Soporte N1, informa la
inconformidad del usuario al soporte
que dio solución del ticket.
Soporte N2/SoporteN3, revisa cola
de atención.
Soporte N2/SoporteN3, revisa
incidencia.
Soporte N2/SoporteN3, atiende la
incidencia e informa a la mesa.
Soporte N1, verifica la correcta
atención.
Usuario, confirma la correcta
atención.
Documentación de cada Caso de Uso detallado en el diagrama, Figura 6.
Elaborado por: Autores
Figura 6.- Diagrama de caso de uso OTRS
Elaborado por: Autores
24
Caso de Uso Paso a Paso
Reporta incidente
(Usuario reporta
incidencia vía
teléfono o e-mail)
Flujo normal:
Usuario, reporta incidencia por llamada telefónica.
Soporte N1, recepción de incidencia.
Usuario, detalla información del incidente
Soporte N1, sugiere una solución a lo reportado.
Soporte N1, confirma con el usuario si la solución
sugerida resuelve lo reportado
Usuario, confirma atención.
Flujo Alternativo:
Alternativa 1
Usuario, reporta incidencia por un e-mail.
Soporte N1, verifica el correo.
Soporte N1, verifica si la información es completa.
Soporte N1, sugiere una solución a lo reportado.
Soporte N1, confirma con usuario si la solución
sugerida resuelve lo reportado.
Usuario, confirma atención
Alternativa 2
Usuario, reporta incidencia por un e-mail.
Soporte N1, verifica el correo.
Soporte N1, verifica si la información es completa.
Soporte N1, solicita mayor información al usuario
Soporte N1, sugiere una solución a lo reportado.
Soporte N1, confirma con usuario si la solución
sugerida resuelve lo reportado
Usuario, confirma atención.
Tabla 2.- Información de caso de uso para gestión de incidencias (detallado)
25
Registro de atención
(Registra en el
sistema la incidencia
reportada por el
usuario)
Flujo normal (Usuario reporta incidencia vía teléfono):
Soporte N1, consulta al usuario el detalle del incidente
y datos básicos para brindar la atención.
Usuario, brinda información solicitada.
Soporte N1, registra incidencia en el sistema.
Flujo Alterno:
Alternativa 1 (usuario reporta incidencia por e-mail)
Soporte N1, verifica la solicitud vía correo.
Soporte N1, valida si la información es completa.
Soporte N1, registra en el sistema lo reportado por e-
mail.
Alternativa 2 (usuario reporta incidencia por e-mail)
Soporte N1, verifica la solicitud vía correo.
Soporte N1, valida si la información es completa.
Soporte N1, se comunica con el usuario para conseguir
más detalle del incidente reportado.
Usuario, brinda información solicitada.
Soporte N1, registra en el sistema lo reportado por e-
mail.
Canaliza incidente
(Escala incidente
en OTRS, se asigna
propietario para la
atención)
Flujo normal:
Soporte N1, analiza el incidente reportado.
Soporte N1, asigna propietario para la revisión en el
sistema para la revisión en sitio del incidente.
Flujo Alterno
Alternativa 1 (soporte N1 puede atender incidente)
Soporte N1, analiza el incidente reportado.
Soporte N1, asigna propietario para la revisión en el
sistema.
Soporte N2, analiza el incidente y determina que la
solución requiere de la atención de soporte N3.
26
Soporte N2, cambia de propietario y asigna
especialista.
Mantenimiento del
ticket
(Ingreso de
estados, prioridad o
notas con avances de
atención en el sistema
OTRS)
Flujo normal:
Soporte N1, asigna en el ticket la prioridad, el estado,
SLA y servicio para la atención del ticket.
Flujo Alternativo.
Alternativa 1
Soporte N1, asigna en el ticket la prioridad, el estado,
SLA y servicio para la atención de la incidencia.
Soporte N2, detecta que uno de los parámetros de
atención está incorrecto.
Soporte N2 cambia en la herramienta el parámetro de
atención correcto.
Alternativa 2
Soporte N1, asigna en el ticket la prioridad, el estado,
SLA y servicio para la atención de la incidencia.
Soporte N2, no puede brindarle solución al ticket.
Soporte N2, ingresa los avances de solución en la
herramienta.
Alternativa 3
Soporte N1, asigna en el ticket la prioridad, el estado,
SLA y servicio para la atención de la incidencia.
Soporte N3, detecta que uno de los parámetros de
atención está incorrecto.
Soporte N3, cambia en la herramienta el parámetro de
atención correcto.
Alternativa 4
Soporte N1, asigna en el ticket, prioridad, estado, SLA
y servicio para la atención de la incidencia.
Soporte N3, no puede brindarle solución al ticket. .
27
Verificación de cola
de atención
(Monitoreo en la
herramienta de ticket
asignados para una
solución)
Flujo normal:
Soporte N2/N3, monitorea la cola de atención en el
sistema.
Soporte N2/N3, toma el ticket según su el orden de
llegada.
Flujo Alterno:
Alternativa 1
Soporte N2/N3, monitorea la cola de atención en el
sistema.
Soporte N2/N3, toma el ticket según la prioridad de
atención.
Registro de cierre
(Registra en el
sistema la incidencia
reportada por el
usuario)
Flujo normal:
Soporte N1, confirma con el usuario la solución
sugerida.
Usuario, confirma atención.
Soporte N1, ingresa solución al sistema.
Soporte N1, cierra el ticket en la herramienta.
Usuario, recibe notificación de cierre.
Flujo Alterno:
Alternativa 1
Soporte N2, brinda solución del incidente.
Usuario, confirma atención.
Soporte N2, ingresa solución al sistema.
Soporte N2, cierra el ticket en la herramienta.
Usuario, recibe notificación de cierre.
Alternativa 2
Soporte N3, brinda solución del incidente.
Soporte N3, registra solución brindada en el sistema.
Soporte N3, cierra incidencia en el sistema.
Usuario, recibe notificación de cierre.
28
Soporte N1, valida con el usuario la atención de lo
reportado.
Usuario, confirma atención
Alternativa 3
Soporte N2, brinda solución del incidente.
Soporte N2, valida con el usuario la solución aplicada.
Usuario, confirma la atención.
Soporte N2, registra solución brindada en el sistema.
Soporte N2, cierra incidencia.
Usuario, recibe notificación de cierre.
Alternativa 4
Soporte N3, brinda solución del incidente.
Soporte N3, registra solución aplicada para la
incidencia. Soporte N3, cierra ticket en la herramienta.
Usuario, recibe notificación de cierre.
Usuario, confirma la atención a la Mesa de Servicio.
Alternativa 5
Soporte N3, brinda solución del incidente.
Soporte N3, registra solución aplicada para la
incidencia.
Soporte N3, cierra ticket en la herramienta.
Usuario, reporta inconformidad en la atención a la
Mesa de Servicio.
Soporte N1, abre nuevamente el ticket en la
herramienta y asigna al especialista para que resuelva
la incidencia.
Soporte N3, cierre del ticket en la herramienta.
Usuario, recibe notificación de cierre.
29
Consulta de reportes
(Coordinador
monitorea la atención
de la incidencia y
brinda información al
Usuario)
Flujo normal
Coordinador de Soporte, monitorea las incidencias
abiertas.
Coordinador de Soporte, emite reportes diarios y
elabora estadísticas de atención.
Flujo Alterno
Alternativa 1
Coordinador de Soporte, monitorea las incidencias
abiertas.
Coordinador de Soporte, detecta incidentes con mucho
tiempo sin resolver.
Coordinador de Soporte, gestiona la incidencia.
Coordinador de Soporte, se comunica directamente
con usuario para brindar una mejor comunicación.
Coordinador de Soporte, elabora informe del caso con
todo el detalle de atención.
Elaborado por: Autores
30
5. Implementación OTRS
OTRS es uno de los proyectos de código abierto más duraderos y de mayor éxito a
nivel mundial en el sector de la asistencia de escritorio y la gestión de la asistencia
informática. Más de 5.000 miembros activos de la comunidad mejoran el software de
gestión de la asistencia con cada versión informando acerca de fallos, añadiendo mejoras
o nuevas funcionalidades desarrolladas por ellos mismos así como manteniendo y
extendiendo los 35 idiomas.
Debido al código fuente abierto, que es constantemente revisado por el fabricante y
por la comunidad, el software de código abierto OTRS no solo es más seguro que el
software propietario, sino también más flexible. Dan fe de ello sus 150.000 instalaciones
en diferentes sectores industriales, como la informática y las telecomunicaciones, el
gobierno, el sector sanitario, la fabricación, la educación y los productos de consumo.
(Steinbild, 2001)
5.1. Requisitos de hardware y software generales.
OTRS se puede instalar en muchos sistemas operativos diferentes, tales como Linux y
otros derivados de UNIX. También puede ejecutarlo en Windows.
OTRS no tiene requisitos de hardware excesivas. Se recomienda el uso de una
máquina con al menos un procesador de 2 GHz o Xeon comparables, 2 GB de RAM y
un disco duro de 160 GB.
Para ejecutar OTRS, también tendrá que utilizar un servidor web y un servidor de
base de datos, se debe instalar perl y / o instalar algunos módulos Perl adicionales en la
máquina OTRS.
31
El servidor web y Perl deben estar instalados en la misma máquina que OTRS. La
base de datos de fondo se puede instalar localmente o en otro host. Para el servidor web,
se recomienda utilizar Apache HTTP. Esto le permite ejecutarse en cualquier servidor
web compatible con ejecución de scripts de perl.
Puede implementar OTRS en diferentes bases de datos como, MySQL, PostgreSQL,
Oracle o Microsoft SQL Server.
5.1.1. Requisitos de software específicos en Servidor.
Perl 5.10 o superior
Soporte de servidor Web
Apache2 + mod_perl2 o superior (recomendado)
Servidor web con soporte CGI (no se recomienda CGI)
Microsoft Internet Information Server (IIS) 6 o superior
5.1.2. Requisitos a nivel de base de datos.
MySQL 5.0 o superior
PostgreSQL 8.0 o superior (8.2 o superior)
Oracle 10g o superior
Microsoft SQL Server 2005 o superior
5.1.3. Navegadores web.
Para utilizar OTRS, se debe utilizar un navegador moderno con soporte JavaScript
habilitado:
Internet Explorer antes de la versión 9 o superior.
Firefox de la versión 11 o superior.
Safari de la versión 6 o superior.
32
5.2. Modelo Entidad Relación
En este modelo encontramos las tablas principales del sistema que contienen toda la
información de un incidente, la misma que se relaciona con tablas auxiliares necesarias
para el proceso. Revisar anexo 17.
5.3. Modelo V-C (Vista – Controlador).
El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la
organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el
usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación).
De esta forma, dividimos el sistema en tres capas donde, como explicaremos más
adelante, tenemos la encapsulación de los datos, la interfaz o vista por otro y por último
la lógica interna o controlador (Rodríguez, 2012).
5.3.1. Modelo.
Nos referimos con modelo a las representaciones que se construyen, basadas en la
información con la que opera una aplicación. El modelo que se elija depende
obviamente de las necesidades de información que tiene una aplicación. En el caso de
OTRS es SQL y Active Directory.
5.3.2. Vista.
La vista no es más que la interfaz con la que va a interactuar el usuario. En el caso de
OTRS las interfaces están construidas en HTTP y Perl.
33
5.3.3. Controlador
Finalmente nos topamos con el controlador que son todas esas clases que ayudan a
darle vida a las interfaces que normalmente conocemos y que nos permiten desplegar y
consumir información para el usuario. Estos controladores son el core de la aplicación.
En el caso de OTRS es Mod_Perl. Revisar anexo 18.
5.4. Cronograma
La implementación del proyecto se encuentra detallad dentro de las tareas del
cronograma que se muestran en los siguientes literales.
5.4.1. Planificación
Las actividades enlistadas se encuentran detalladas en los apartados 1, 2, 3 y 4
del capítulo “Desarrollo del proyecto”:
Levantamiento de Información actual
Análisis y Diagramación del proceso actual
Definición de proceso de atención orientado a ITIL V3
Análisis y Diagramación del proceso propuesto
5.4.2. Implementación y ejecución
Preparación del ambiente
Antes de la instalación del producto OTRS en los servidores asignados se hace una
revisión de las características técnicas y funcionales para identificar si cumple con las
características básicas del aplicativo de esta manera evitamos tiempos de latencia, Tabla
3.
34
En la tabla 3 se detallan las características recomendadas por el desarrollador del
aplicativo a nivel de hardware y software, así como las características con las que
actualmente cuenta a nivel de tecnología la empresa Farletza.
Tabla 3. Comparativo de características técnicas recomendadas vs producción
Elaborado por: Autores
35
Posterior a la revisión realizada se agregaron recomendaciones/sugerencias para
mitigar las necesidades que ayudan a mejorar los tiempos de respuesta en el uso del
aplicativo OTRS.
Parametrización y configuración del aplicativo. Revisar anexo 8.
Pruebas pre-producción
Se realizan las pruebas mediante generación de incidentes simulados:
o Confirmación del correcto registro en la interfaz web
o Confirmación de la transición de estados del caso desde su reporte hasta
su solución.
o Confirmación de las alertas emitidas hacia los agentes y usuario final
o Confirmación del uso correcto de las asignaciones
o Confirmación del cierre del ticket y sus respectivas alertas
Prueba de implementación OTRS en Farletza (Registro de atención por llamada
telefónica)
En este caso de prueba el Soporte N1 recibe una llamada telefónica solicitando
soporte, para el Soporte N1 brindarle atención ingresa a la herramienta OTRS, Figura 7.
Figura 7.- Inicio de sesión en sistema OTRS
Elaborado por: Autores
36
Soporte N1, consulta al usuario detalles del problema, Usuario, responde las
preguntas realizadas, Soporte N1, ingresa en el sistema la información del incidente,
para este caso de prueba el usuario no puede ingresar a la aplicación de sustento
tributario, para lo que se cambia la contraseña del aplicativo y le indica al usuario probar
nuevamente.
Usuario, prueba nuevamente sin novedad alguna.
Soporte N1, crea el ticket con estado cerrado, finalizando la atención, Figura 8.
Figura 8.- Cierre del ticket en la herramienta OTRS
Elaborado por: Autores
Prueba de implementación OTRS en Farletza (Registro de atención por e-mail)
Soporte N1, verifica la solicitud vía correo en la aplicación OTRS, Figura 9.
Figura 9.- Confirmación de registro automático mediante correo
Elaborado por: Autores
37
Soporte N1, valida si la información registrada en la herramienta es completa y toma
el ticket para la atención, Figura 10.
Figura 10.- Asignación de ticket generado mediante correo electrónico
Elaborado por: Autores
Soporte N1, confirma con el usuario la atención brindada y cierra el ticket en la
herramienta.
Elaboración de manuales para el uso de la aplicación
Previo a la capacitación, se elaboró un manual de usuario para facilitar la adaptación
de los clientes al uso del sistema OTRS, Revisar anexo 9.
Capacitaciones y entrega de documentación
Todos los documentos entregados, se encuentran detallados en el apartado de anexos,
adicional a esto, los tópicos tratados en la capacitación brindada al personal de
Farletza son:
o ¿Qué es OTRS – ITSM?
o Características del Software
o Administración de Tickets con OTRS – ITSM
o Roles OTRS, Administrador, Mesa y Agente
o Demostración del Software
38
5.4.3 Cierre
Puesta en producción
Para la salida a producción del aplicativo OTRS se establecen 6 actividades
principales:
o Lista de agentes con sus respectivos grupos.
o Asignación de permisos para el ingreso de los agentes en OTRS.
o Logon de todos los agentes que usarán OTRS.
o Asignación de rol en la herramienta OTRS.
o Difusión de link OTRS a todos los agentes y Mesa de Servicios.
o Uso de la herramienta de Gestión OTRS
El 08 de noviembre de 2015 se define la lista de usuarios finales que deben usar el
aplicativo OTRS para ejercer las funciones de nivel 1, 2 y 3 respectivamente, lo que
permite definir los grupos o colas de atención dentro de la herramienta.
El 13 de noviembre de 2015 se tiene lista las asignaciones de permisos para todos los
agentes con sus respectivos roles, por lo cual se solicita que los agentes realicen el logon
en la herramienta para proceder a realizar las asignaciones de colas de atención, tarea
que fue realizada del 15 al 17 de noviembre de 2015.
El 06 de enero de 2016, se comunica a los agentes la publicación de la dirección web
en la red interna, para el acceso a la herramienta OTRS, indicando que desde el día 07 de
enero del año en curso, todo incidente deberá ser registrado exclusivamente dentro de la
herramienta, omitiendo el uso del antiguo archivo de registro que se llevaba en excel.
El 07 de enero del 2016, inician las actividades de registro de los incidentes
reportados por los usuarios, dentro de la herramienta OTRS.
39
Monitoreo del proceso de atención
Se revisa durante una semana la transaccionalidad dentro del sistema de los
incidentes registrados en la herramienta OTRS, tomando en cuenta todas las fases por
las que pasa un incidente desde su reporte hasta la solución. La información generada en
esta etapa, sirve para alimentar las métricas definidas.
6. Métricas
El levantamiento de las métricas forma parte de los objetivos del proyecto. Se
entregan 6 métricas que cubren las necesidades de información encontradas en la
empresa cumplir con el proceso de mejora continua, Tabla 4.
Código Descripción Objetivo estratégico
KPI-Mesa-001 Incidentes registrados
por fecha
Identificar el número de incidentes registrados
en la herramienta OTRS entre departamentos
en un periodo de fechas establecido.
KPI-Mesa-002 Incidentes cerrados por
fecha
Identificar el número de incidentes cerrados en
la herramienta OTRS en un periodo de fechas
establecido.
KPI-Mesa-003 % de Incidentes
Cerrados por Nivel 1
Identificar el porcentaje de incidentes
atendidos por los agentes de nivel 1
KPI-Mesa-004 % de Incidentes
Cerrados por Nivel 2
Identificar el porcentaje de incidentes
atendidos por los agentes de nivel 2
KPI-Mesa-005 % de Incidentes
Cerrados por Nivel 3
Identificar el porcentaje de incidentes
atendidos por los agentes de nivel 3
KPI-Mesa-006 % de efectividad en la
atención de incidentes
Efectividad en la gestión de los casos
registrados
Tabla 4. Definición de Métricas de Mesa de Servicios
Elaborado por: Autores
40
7. Resultados
La Mesa de Servicios se puso en producción el día 07 de enero de 2016, utilizando la
herramienta OTRS y teniendo como alcance, el uso del módulo de gestión de
incidencias. Los resultados mostrados se encuentran con corte al 14 de febrero de 2106.
El primer objetivo declarado en el proyecto, es el levantamiento de métricas
basadas en ITIL. Estas métricas no existían dentro de la empresa Farletza, antes de la
reestructuración de la Mesa de Servicios no era posible medir de manera cuantitativa la
gestión que realiza el área de Sistemas.
KPI-Mesa-001 (Incidentes registrados por fecha)
Objetivo: Identificar el número de incidentes registrados en la herramienta OTRS
entre departamentos en un periodo de fechas establecido.
Formula: Total de incidentes registrados en un rango de fechas establecidas.
Esta métrica permite tener información necesaria para el análisis de la demanda de
atenciones, permitiendo identificar un patrón en fechas estratégicas para decidir si es
necesario tener personal adicional para atención de los incidentes.
Fecha inicio: 08 de enero de 2016.
Fecha de corte: 14 de febrero de 2016.
Resultado: 17 incidentes registrados.
41
KPI-Mesa-002 (Incidentes cerrados por fecha)
Objetivo: Identificar el número de incidentes cerrados en la herramienta OTRS en un
periodo de fechas establecido.
Formula: Total de incidentes cerrados en un rango de fechas establecidas.
Esta métrica permite tener información necesaria para el análisis de la efectividad en
la atención y solución de los incidentes registrados.
Fecha inicio: 08 de enero de 2016.
Fecha de corte: 14 de febrero de 2016.
Resultado: 17 incidentes cerrados.
KPI-Mesa-003 (% de incidentes cerrados por Nivel 1)
Objetivo: Identificar el porcentaje de incidentes atendidos por los agentes de nivel 1.
Formula: (Número de casos registrados para el nivel 1 / Total de casos
registrados)*100.
Esta métrica permite identificar el porcentaje de casos que han sido atendidos por el
nivel 1, para identificar si existe la necesidad de aumentar recursos de dicho nivel para la
atención de incidentes. Es recomendable que el primer nivel tenga el mayor porcentaje
de atención, ya que la solución de los incidentes en su mayoría, debe darse en el nivel 1.
Fecha de inicio: 08 de enero de 2016.
Fecha de corte: 14 de febrero de 2016.
Resultado: (11/17)*100 = 64,70 %.
42
KPI-Mesa-004 (% de incidentes cerrados por Nivel 2)
Objetivo: Identificar el porcentaje de incidentes atendidos por los agentes de nivel 2.
Formula: (Número de casos registrados para el nivel 2 / Total de casos
registrados)*100.
Esta métrica permite identificar el porcentaje de casos que han sido atendidos por el
nivel 2, para identificar si existe la necesidad de aumentar recursos de dicho nivel para la
atención de incidentes. Es recomendable que el segundo nivel tenga el menor porcentaje
de atención, ya que la solución de los incidentes en su mayoría, debe darse en el nivel 1.
Fecha de inicio: 08 de enero de 2016.
Fecha de corte: 14 de febrero de 2016.
Resultado: No se registran casos registrados al nivel 2 en la fecha de corte.
KPI-Mesa-005 (% de incidentes cerrados por Nivel 3)
Objetivo: Identificar el porcentaje de incidentes atendidos por los agentes de nivel 3.
Formula: (Número de casos registrados para el nivel 3 / Total de casos
registrados)*100.
Esta métrica permite identificar el porcentaje de casos que han sido atendidos por el
nivel 3, para identificar si existe la necesidad de aumentar recursos de dicho nivel para la
atención de incidentes. Es recomendable que el tercer nivel tenga el menor porcentaje de
atención, ya que la solución de los incidentes en su mayoría, debe darse en el nivel 1.
Fecha de inicio: 08 de enero de 2016.
Fecha de corte: 14 de febrero de 2016.
Resultado: (6/17)*100 = 35,30%.
43
KPI-Mesa-006 (% de efectividad en la atención de incidentes)
Objetivo: Efectividad en la gestión de los casos registrados.
Formula: (Número de casos cerrados / Total de casos registrados)*100.
Esta métrica permite identificar la efectividad en la atención de los incidentes
registrados tomando en cuenta todos los niveles de atención.
También permite identificar la efectividad por nivel cambiando las variables de
generación del reporte.
Esta información nos ayuda a realizar ajustes al proceso de atención ya que un valor
bajo de efectividad implicaría un no cumplimiento de la meta, por cualquier factor que
pueda afectar la métrica, Se recomienda un mínimo de 60%.
Fecha de inicio: 08 de enero de 2016.
Fecha de corte: 14 de febrero de 2016.
Nivel: Todos
Resultado: (17/17)*100 = 100%.
El segundo objetivo declarado en el proyecto, es fortalecer líneas de comunicación
entre el área de TI con las áreas operativas.
Este objetivo depende mucho de la percepción, por tal motivo, se establece con la
empresa, que a los 2 meses de operación se iniciará un proceso de encuestas mensuales,
durante 3 meses, a los usuarios internos de todas las áreas para medir el impacto del
cambio que generó la reestructuración de la Mesa de Servicios. Las preguntas que se
deben realizar en la encuesta son:
44
¿Cómo califica usted la atención brindada por la Mesa de Servicios?
¿Está usted conforme con las alertas y actualizaciones de estado que llegan a su
correo, sobre los incidentes que ha reportado?
¿Ha reportado últimamente alguna incidencia que no haya sido considerada por
la Mesa de servicios (Recepción de alerta por correo)?
El tercer objetivo declarado en el proyecto corresponde al establecimiento de
responsabilidades de cada rol en el área de Sistemas, las cuales se encuentran
detalladas en el literal 3.3 del documento del proyecto.
45
8. Conclusiones
El número de incidentes cerrados por cada nivel de atención, se encuentran dentro de
un margen aceptable respecto al porcentaje de atención que debe existir entre cada
nivel.
Los resultados en cuanto a la efectividad en la atención de los incidentes, no refleja
valores por debajo del porcentaje recomendado, pero es necesario generar esta
información de manera mensual, para que la misma sea confiable y permita determinar
tendencias.
Los resultados en cuanto a la carga de trabajo, no reflejan aun la necesidad de
aumentar el número de recursos de atención.
Los datos que arrojen las encuestas realizadas a partir del segundo mes de operación
ayudan a medir el fortalecimiento de comunicación entre las áreas operativas.
Los datos de los reportes generados por OTRS evidencian una falta de registro y
cierre de las atenciones a los incidentes. Es necesario que se cree una cultura de registro
en el personal que fue capacitado y se establezcan revisiones semanales de la carga de
trabajo.
En la implementación del proyecto se obtuvo un mayor conocimiento técnico de
herramientas de gestión, de procesos internos de la empresa, así como de los niveles de
atención que se brinda hacia un usuario desde el departamento de sistemas.
46
Se observa reticencia al cambio de parte de los empleados, ya que en su mayoría
estaban acostumbrados a trabajar de manera manual.
Se pudo conocer temas gerenciales con las autoridades, que fueron compartidos en las
reuniones de definiciones que se tuvieron al inicio del proyecto.
47
9. Recomendaciones
Todos los incidentes deben ser resueltos en un mayor porcentaje por el primer nivel
de atención, por lo tanto se recomienda usar un margen de 80% para el primer nivel y
20% para el segundo nivel.
Se identifica la necesidad de contar con un software de grabación de llamadas para el
control de calidad en la atención, así como la grabación de las llamadas para futuros
reclamos de parte de los usuarios.
Mantener la frecuencia de generación de reportes de manera mensual, para realizar
cuadros comparativos trimestrales, semestrales y anuales. Con esta información se
aportaría al proceso de mejora continua tal como lo recomienda ITIL V3.
Evaluar el proceso de requerimientos en la empresa para identificar si es necesario
implementar esta funcionalidad que se encuentra disponible en la herramienta OTRS.
Implementar el módulo de encuestas que se encuentra disponible en la herramienta
OTRS, para automatizar el proceso manual y poder manejar estadísticas generadas
directamente desde la herramienta.
Brindar capacitaciones internas respecto a los procesos de atención para que toda la
información quede clara para todos los participantes/actores de cada proceso.
Brindar capacitaciones sobre fundamentos de ITIL como parte de la mejora continua
para que los actores conozcan a fondo los procesos no solo de forma operativa.
48
Realizar una campaña mediante correo e informativos para incentivar el uso de la
Mesa de Servicios, así podemos evitar que los usuarios busquen directamente a los
especialistas.
Es necesario generar de manera mensual la emisión de los reportes de métricas para
evaluar la información de forma comparativa entre cada mes, desde el inicio del uso de
la herramienta.
10. Trabajos futuros
Los siguientes son los procesos sobre los que se podría realizar una evaluación para
una posible implementación:
Gestión de problemas
Gestión de peticiones
Base de Conocimiento.
Gestión de Calidad
Mejora Continua.
49
11. Referencias bibliográficas
Iberosys S.A. (30 de Mayo de 2007). Acerca de nosotros: Proveemos servicios de alta
calidad basados en mejores prácticas de tecnología y de negocio asi como
diseño e implementación e tecnologías de Información (IT) modernas, que
incrementan el valor de profesionales y de las organizaciones, 2.1. Obtenido de
http://iberosys.net/ITILV3-Glosario-LATAM-v21.pdf
IBPI. (Febrero de 2013). About: The Internaional Best Practice Institute aims to further
professionalism in information management by promoting industry-leading best
practice standards. Obtenido de sitio Web de IBPI:
https://internationalbestpracticeinstitute.wordpress.com/category/itil/
OSIATIS S.A. (s.f.). Acerca de notros: OSIATIS, multinacional europea especialista en
ingeniería, outsourcing y mantenimiento de sistemas TI distribuidos, cuenta con
una experiencia acumulada de más de 25 años en el mercado español, 3.0.
Obtenido de sitio Web de OSIATIS S.A.: http://itilv3.osiatis.es
Rodríguez, A. (10 de Mayo de 2012). Acerca de nosotros: Androideity es una
comunidad mexicana orientada al aprendizaje y enseñanza en el desarrollo de
aplicaciones en Android. Obtenido de sitio Web de Condesa-sama:
http://androideity.com/2012/05/10/la-importancia-del-mvc-en-android/
Steinbild, A. M. (2001). Acerca de nosotros: OTRS Group tiene sus raíces en la
Comunidad de Código Abierto y cuenta con fuertes lazos con la gestión de
servicios de clase empresarial y operaciones globales. Obtenido de sitio Web de
OTRS Inc: http://www.otrs.com/?lang=es
White, A. A. (2009). From Comfort Zone to Performance Management. (C. Schoolbook,
Ed.) Bélgica: White & MacLean.
50
12. Glosario (Iberosys S.A., 2007)
A continuación se detallan términos utilizados en ITIL necesarios para la
comprensión de los conceptos a utilizarse en la implementación de la mesa de servicio:
Agentes N1 [Primer nivel]: Recursos técnicos y de gestión presentes dentro de la
Mesa de Servicios que permiten resolver rápidamente las incidencias sencillas (Quesnel,
2012).
Agentes N2 [Segundo nivel]: Recursos técnicos de atención en sitio, a quienes son
escalados los casos, cuando no han podido ser resueltos por el primer nivel.
Agentes N3 [Tercer nivel]: Recursos técnicos de atención en sitio o remota, a
quienes son escalados los casos, cuando no han podido ser resueltos por el primer y
segundo nivel (incluye proveedores).
Acuerdo de Nivel de Servicio [Service Level Agreement] (SLA): Acuerdo entre un
Proveedor de Servicio de TI y un Cliente. El SLA describe el Servicio de TI, documenta
los Objetivos de Nivel de Servicio y especifica las responsabilidades del Proveedor de
Servicio de TI y del Cliente. Un único SLA puede cubrir varios Servicios de TI o varios
Clientes.
Buena Práctica [Best Practice]: Actividades o Procesos que se han usado con éxito
por más de una Organización. ITIL es un ejemplo de Buenas Prácticas.
Cadena de Valor [Value Chain]: (Estrategia del Servicio) Una secuencia de
Procesos que crea un producto o Servicio que proporciona valor a un Cliente. Cada paso
de la secuencia se apoya en los pasos anteriores y contribuye al conjunto del producto o
Servicio.
51
Calidad [Quality]: Característica de un producto, Servicio o Proceso para
proporcionar su propio valor. Por ejemplo, un Componente hardware puede ser
considerado de alta Calidad si rinde según lo esperado y proporciona la Fiabilidad
requerida.
La Calidad de un Proceso requiere la capacidad para medir su Eficacia y Eficiencia, o
incluso para mejorarlas si resultase necesario.
Cambio [Change]: (Transición del Servicio) Adición, modificación o eliminación de
algo que podría afectar a los Servicios de TI. El Alcance debería incluir todos los
Servicios de TI, Elementos de Configuración, Procesos, Documentación etc.
Catalogo de Servicios [Diseño del Servicio]: Una base de datos o un Documento
estructurado con información sobre todos los Servicios de TI en vivo, incluyendo
aquellos que están disponibles para la Implementación. El catálogo de servicios es
solamente una parte del Portafolio de Servicios que se publica para los Clientes, y se usa
con el fin de dar apoyo a las ventas y a la prestación de los Servicios de TI. El catálogo
de servicios cuenta con información sobre los Servicios a Prestar, los precios, los puntos
de contacto, y el encargo y la solicitud de Procesos.
Centro de Atención al Usuario [Help Desk]: (Operación del Servicio) Un punto de
contacto para Usuarios para registrar Incidentes. Un Centro de Atención al Usuario está
normalmente más técnicamente focalizado que un Centro de Servicio al Usuario y no
proporciona un Punto Único de Contacto.
Centro de Servicio al Usuario [Service Desk – Mesa de Servicios]: (Operación del
Servicio) Punto Único de Contacto entre el Proveedor de Servicio y los Usuarios. Un
Centro de Servicio al Usuario típico gestiona Incidentes, Peticiones de Servicio, y
también maneja la comunicación con los Usuarios.
52
Ciclo de Vida de Gestión del Servicio [Service Management Lifecycle]:
Aproximación a la Gestión del Servicio de TI que pone énfasis la importancia de la
coordinación y el Control a través de las diferentes Funciones, Procesos y Sistemas
necesarios para gestionar el Ciclo de Vida total de los Servicios de TI. La aproximación
del Ciclo de Vida de la Gestión del Servicio incluye la Estrategia, Diseño, Transición,
Operación y Mejora Continua de los Servicios de TI.
Cliente interno [Internal Customer]: Cliente que trabaja para el mismo Negocio
que el Proveedor del Servicio de TI. Ver Proveedor Interno de Servicio, Cliente Externo.
Escalabilidad: La habilidad de un Servicio de TI, un Proceso, un Elemento de
Configuración, etc. de realizar la Función acordada al cambiar la Carga de Trabajo o el
Alcance.
Escalamiento [Operación del Servicio]: Una Actividad que obtiene Recursos
adicionales cuando se necesitan estos para satisfacer las Metas de Niveles de Servicio o
las expectativas de los Clientes. El escalado puede ser necesario en el seno de cualquier
Proceso de Gestión del Servicio de TI, pero es asociado con más frecuencia a Gestión de
Incidentes, Gestión de Problemas y la Gestión de las quejas de los Clientes. Hay dos
tipos de Escalados, Escalado Funcional y Escalado Jerárquico.
Gestión de incidentes [Operación del Servicio]: El Proceso encargado del control
del Ciclo de Vida de todos los Incidentes. El Objetivo primario de la Gestión de
Incidentes es devolverles el Servicio de TI a los Usuarios tan rápido como sea posible.
Incidente [Operación del Servicio]: Una interrupción no planificada de un Servicio
de TI o una reducción de la Calidad de un Servicio de TI. El Fallo de un Elemento de
Configuración que no haya impactado aún sobre un Servicio es considerado también un
Incidente. Por ejemplo, el Fallo de un disco en un arreglo en espejo.
53
ITIL: Un conjunto de directrices de Buenas Prácticas para Gestión del Servicio de
TI. ITIL es propiedad de OGC y consta de una serie de publicaciones que sirven de guía
en la prestación de Servicios de TI de calidad, y en los Procesos e instalaciones que se
necesitan para darles soporte.
KPI [Mejoramiento Continuo del Servicio]: Una Medida que se usa para ayudar a
gestionar un Proceso, un Servicio de TI o una Actividad. Muchas Medidas deben ser
mensuradas, pero sólo la más importante de estas son definidas como KPIs y usadas
activamente para gestionar e informar sobre el Proceso, el Servicio de TI o la Actividad.
Los KPIs deben ser seleccionados para asegurar que se gestionen Eficiencia, Eficacia, y
Rentabilidad.
Métricas [Mejoramiento Continuo del Servicio]: Algo que es medido y sometido a
informes y se usa para ayudar a gestionar un Proceso, un Servicio de TI o una Actividad.
Consulte KPI.
Open Source [Código abierto]: es el término con el que se conoce
al software distribuido y desarrollado libremente. El código abierto tiene un punto de
vista más orientado a los beneficios prácticos de compartir el código que a las cuestiones
éticas y morales las cuales destacan en el llamado software libre.
Rol: Un conjunto de responsabilidades, Actividades y autoridades concedidas a una
persona o a un equipo. El Rol se define en un Proceso. Una persona o un equipo puede
tener múltiples Roles, por ejemplo, los Roles de Gestor de la Configuración y de Gestor
del Cambio pueden ser llevados a cabo por una única persona.
Servicio: Una forma de proporcionar valor a los Clientes facilitando los Resultados
que los Clientes quieren alcanzar sin ser propietarios de Costos y Riesgos específicos.
54
TI Tecnología Informática: El uso de la tecnología para el almacenamiento, la
comunicación o el procesamiento de información. La tecnología habitualmente
comprende las computadoras, las telecomunicaciones, las Aplicaciones y otros
programas de software. La información puede comprender datos del Negocio, voz,
imágenes, vídeo, etc. La Tecnología Informática suele ser usada para dar soporte a los
Procesos del Negocio mediante los Servicios de TI.
Workaround [Operación del Servicio]: Reducción o eliminación del Impacto de un
Incidente o Problema para el cual no hay disponible aún una Resolución total. Por
ejemplo, mediante el reinicio de un Elemento de Configuración. Las soluciones para los
Problemas se documentan en los Registros de Errores Conocidos. Las soluciones para
Incidentes que no tienen asociados Registros de Problemas se documentan en el registro
de Incidentes.
Zona de confort: En el ámbito de la psicología, la zona de confort es un estado de
comportamiento en el cual la persona opera en una condición de "ansiedad neutral",
utilizando una serie de comportamientos para conseguir un nivel constante de
rendimiento sin sentido del riesgo (White, 2009).
55
13. Codificación de documentos
Los documentos entregados fueron codificados con las siglas que la empresa facilitó
y se encuentran estructurados de la siguiente manera:
Estructura: Siglas de la empresa – Tipo de documento – Área/Departamento –
Secuencia + Nombre del documento.
Ejemplo: FAR-DIA-IT-001 Procedimiento de atención de llamadas
El significado de la codificación utilizada en cada documento que se entrega a la
empresa se detalla a continuación para un mejor entendimiento:
Siglas de la empresa: FAR – Farletza
Tipos de documento:
DIA – Diagramas
INS – Instructivos
MAN – Manuales
PRO – Procedimientos
VAR – Documentos varios
Área/Departamento: TI – Tecnología de la Información
Nombre del documento: Breve descripción a manera de resumen del asunto del
documento.
56
ANEXOS
57
ANEXO 1.- FAR-DIA-TI-001 Procedimiento de atención de llamadas
Elaborado por: Autores
58
ANEXO 2.- FAR-DIA-TI-002 Procedimiento de atención y
escalamiento
Elaborado por: Autores
59
ANEXO 3.- FAR-DIA-TI-003 Procedimiento para la documentación de
soluciones
Elaborado por: Autores
60
ANEXO 4.- FAR-DIA-TI-004 Procedimiento para Gestión de
Incidentes
Elaborado por: Autores
61
Anexo 5.- FAR-INS-TI-001 Instructivo para clasificación de correos
1.- Antecedentes
El personal de Soporte no maneja actualmente estados para marcar los correos de
novedades enviados por los usuarios, este tipo de organización no permite diferenciar la
gestión de atención de correos recibidos por parte de los dos agentes de soporte.
2.- Acciones a tomar:
Todos los correos recibidos deberán ser marcados y organizados conforme a la
siguiente distribución:
2.1.- Carpeta “Bandeja de entrada” / Estado “Pendiente de registro”
2.2.- Carpeta “Registrados” / Sin estado.
2.3.- Carpeta “No corresponden a IT” / Sin estado
2.1.- Pendiente de Registro
Todos los correos de los cuales tengamos la certeza que van a ser atendidos por IT
estarán enmarcados dentro del estado “Pendiente de registro”, lo que significa que la
solicitud, sea incidente o requerimiento está pendiente para ser registrada en la
herramienta OTRS.
Todos estos correos deberán permanecer en la Bandeja de entrada hasta su registro.
2.2.- Registrado – Sin estado
Cuando el caso sea creado en la herramienta, se desmarcará el correo y se lo
archivará en la carpeta Registrados.
62
Cualquier correo de actualización del usuario o consulta por parte del agente que se
desprenden del inicial, deberán pasar a la carpeta Registrados para evitar que el buzón
se llene, y se manejará la vista en modo de conversación.
2.3.- No corresponden a TI – Sin estado
Todos los correos que sean identificados fuera del área de acción de TI, serán
respondidos indicando que lo solicitado no se encuentra dentro del alcance de atención.
El correo de origen y la respuesta deberá pasar a la carpeta No corresponden a IT y en
caso de haber tener un estado serán desmarcados.
2.4.- Administración de correos
A continuación se detalla la descripción de lo que debe contener cada carpeta para
administrar los correos que se manejan en mesa:
2.4.1.- Bandeja de entrada
En esta carpeta deberán permanecer solo los correos Pendientes de Registro en la
herramienta.
2.4.2.- Registrados
En esta carpeta se almacenaran todos los correos de casos registrados y cualquier
correo de actualización del mail inicial
63
2.4.3.- No corresponden a TI
En esta carpeta deberán permanecer todos los correos cuya atención no es
responsabilidad de TI.
3.- Beneficios
La correcta clasificación de los correos nos brinda:
Disminución en el tiempo de atención y solución
Evitar el descuido de los casos y mantener al usuario informado.
64
Anexo 6.- FAR-MAN-TI-001 Manual de instalación sistema OTRS
Inicio del proceso de instalación
Para la instalación del producto OTRS se descargó el aplicativo con la versión 3.3.13-
win-installer-3.0.6 del siguiente link http://ftp.otrs.org/pub/otrs/. Figura 1.
Figura 11.- Acceso al instalador
Elaborado por: Autores
Luego de la descarga, se copia el archivo en el servidor (Faresenod), para la
instalación respectiva.
Para la instalación local se necesita seguir los siguientes pasos:
Paso 1.- Ejecutar el instalador, seleccionar idioma. Figura 2.
Figura 12.- Selección de idioma
Elaborado por: Autores
65
Paso 2.- Instalar el activestate perl. Figura 3
Figura 13.- Activar perl
Elaborado por: Autores
Paso 3.- Aceptar el acuerdo de las licencias. Figura 4.
Figura 14.- Aceptar el acuerdo
Elaborado por: Autores
66
Paso 5.- Ingresamos el lugar donde estará ubicada la aplicación en nuestro caso será
C:/OTRS. En este punto es importante que primero se instale el aplicativo nativamente,
con su respectiva base Mysql, para después realizar la integración con la base SQL.
Figura 5.
Figura 15.- Instalación MySql
Elaborado por: Autores
Paso 6.- Iniciar con la parametrización web. Figura 6.
Figura 16.- Finalización
Elaborado por: Autores
67
Paso 7.- Se continúa el proceso de instalación mediante el navegador predeterminado
(http://localhost/otrs/installer.pl)
Culminación del proceso de instalación
Paso 1.- Ajuste de base de Datos.
Crear la base de datos con sus respectivas tablas, permisos y componentes lógicos
que usará OTRS sobre la base de datos Mysql. Figura 7.
Figura 17.- Instalación web
Elaborado por: Autores
Paso 2.- Indicaciones Generales y ajustes del correo
ID de sistema (se ingresa 01 ya que es el identificador de la aplicación, en caso que
exista más de un OTRS en la misma empresa).
FQDN del sistema (se ingresa el nombre del servidor alojado OTRS seguido por el
dominio de la empresa).
Organización (se ingresa el nombre de la empresa en nuestro caso es Farletza S.A.)
68
Idioma – Español, verificar los registros MX (se ingresa “NO” ya que no vamos a
ingresar correos de forma manual). Figura 8.
Figura 18.- Ajustes generales
Elaborado por: Autores
Paso 3.- Configuración de correo
Se omite este paso ya que posteriormente realizaremos la configuración de correo
electrónico. Figura 9.
Figura 19.- Configuración del correo
Elaborado por: Autores
69
Paso 4.- Finalizar
El sistema nos detalla cual es el usuario y contraseña para poder ingresar a la base
creada para OTRS. Figura 10.
Figura 20.- Finalización
Elaborado por: Autores
70
Anexo 7.- FAR-MAN-TI-002 Manual de integraciones
1.- Integración Base de Datos
Antes de proceder con la integración se tiene que verificar en configuración del SQL
server que los protocolos TCP/IP se encuentre habilitado para que pueda existir la
comunicación a la base SQL. Figura 1.
Figura 21.- Habilitación del protocolo TCPI/IP
Elaborado por: Autores
2.- Creación de base de datos en SQL 2008
Ingresar a SQL Server Management Studio.
Conectar con el servidor de base de datos.
Hacer clic en Database y seleccione New Database. Figura 2.
Figura 22.- Crear una nueva base de datos
Elaborado por: Autores
71
Crear una nueva base de datos llamada OTRS y haga clic en OK.
Figura 23.- Definición del nombre de la base nueva
Elaborado por: Autores
Dar clic en Archivo/Abrir y seleccione el archivo (OTRS\
scripts\Database\OTRS-schema.mssql.sql).
Asegúrese de seleccionar la base de datos 'OTRS' en la lista desplegable.
Haga clic en Ejecutar.
Repita este proceso con los siguiente script, sin cambiar el orden.
1. OTRS\scripts\database\otrs-initial_insert.mssql.sql
2. OTRS\scripts\database\otrs-schema-post.mssql.sql.
3.- Creación de usuarios
En SQL Server Management Studio, se realiza clic derecho al
botón Seguridad y seleccione Nuevo > Ingresar.
Crear una nueva cuenta de base de datos para OTRS.
Proporcione un nombre y seleccione Autenticación de SQL Server. Figura 4.
72
Proporcione una contraseña.
Desmarcara la casilla verificación Exigir directivas de contraseña.
Establecer la base de datos de OTRS como base de datos predeterminada para
el usuario.
Figura 24.- Creación de los usuarios
Elaborado por: Autores
Seleccione Asignación de usuarios en el lado izquierdo.
Seleccione la base de datos de OTRS y db_owner rol.
Esto hace que la nueva cuenta tenga permisos de propietario en la nueva base
de datos.
Haga clic en Aceptar. Figura 5.
Figura 25.- Verificación de casillas y finalización de creación de usuarios
Elaborado por: Autores
73
4.- Configuración de archivo config de OTRS
Para completar con la integración de la Base SQL, se tiene que modificar el
archivo config, ubicado en la ruta C:\otrs\OTRS\Kernel. Figura 6.
Figura 26.- Ruta archivo config
Elaborado por: Autores
Al ingresar el archivo config, agregar las siguientes líneas de DatabaseHost,
Base de Datos, DatabaseUser y DatabasePw. Justo por encima de directorio
raíz fs.
$ Self-> {'DatabaseDSN'} = "DBI: ODBC: Driver = {SQL Server}; Servidor =
$Self-> {} DatabaseHost de 1433, la base de datos = $ self-> {Base de datos}";
$ Self-> {'bases de datos :: Type'} = 'mssql';
Establezca el directorio raíz fs de C:/otrs
# ------------------------------------------------- --- #
Directorio root # fs
# ------------------------------------------------- --- #
$ Self-> {Inicio} = 'c :/ otrs'; “dirección de donde se instala OTRS en el C”
74
Ajustar el logmodule presentar, agregar estos valores después de insertar su
propia configuración :
$ Self-> {'LogModule'} = 'Kernel :: System :: Conectarse :: Archivo';
$ Self-> {'LogModule :: Archivo de registro'} = "$ self-> / {Inicio} var
/ log / otrs.log";
“Para validar si la integración a la Base SQL fue un éxito se tiene que instalar el
Active Perl 5.12 y ejecutar en el cmd checkmodules, esta consulta debe regresar Ok”.
Ejecutar en el CMD la ruta:
c: \ otrs> perl bin \ otrs.CheckDB.pl
Se tiene que mostrar el siguiente Mensaje:
Tratando de conectar con la base de datos
DSN: DBI: ODBC: Driver = {SQL Server}; Servidor = localhost, 1433,
base de datos = otrs
DatabaseUser: otrs
Se ve bien!
75
5.- Integración AD con OTRS
Para la integración del Directorio Activo se tiene que modificar el archivo config,
ubicado en C:\otrs\OTRS\Kernel.
Ingresar el siguiente código, después de “ingrese código aquí” y antes del corchete.
Figura 7.
Figura 27.- Modificación del código en config
Elaborado por: Autores
#Activa la autenticación contra el AD
$Self->{'AuthModule1'} = 'Kernel::System::Auth::LDAP';
#Configura el servidor de dominio contra el cual se va a autenticar los usuarios.
$Self->{'AuthModule::LDAP::Host1'} = 'ip del servidor OTRS';
#Configura el BaseDN, el ámbito de búsqueda del usuario.
$Self->{'AuthModule::LDAP::BaseDN1'} = 'dc=dominio de la empresa';
#El atributo que se tomará del usuario dentro del AD.
76
$Self->{'AuthModule::LDAP::UID1'} = 'sAMAccountName';
#Configuración de pertenencia a un grupo
$Self->{'AuthModule::LDAP::GroupDN1'} = 'CN=ruta está alojado el usuario
AD';
$Self->{'AuthModule::LDAP::AccessAttr1'} = 'member';
$Self->{'AuthModule::LDAP::UserAttr1'} = 'DN';
#El usuario de conexión al AD (usuario de lectura de AD)
$Self->{'AuthModule::LDAP::SearchUserDN1'} = 'CN= ruta está alojado
el usuario AD ';
$Self->{'AuthModule::LDAP::SearchUserPw1'} = 'contraseña del usuario AD';
#Parámetros de conexión ldap.
$Self->{'AuthModule::LDAP::Params1'} = {
port => 389,
timeout => 120,
async => 0,
version => 3,
};
#Sincronización de usuario autenticado con la bd, crea el usuario dentro de BD.
$Self->{'AuthSyncModule1'} = 'Kernel::System::Auth::Sync::LDAP';
$Self->{'AuthSyncModule::LDAP::Host1'} = 'servidor OTRS';
$Self->{'AuthSyncModule::LDAP::BaseDN1'} = 'dc=dominio de la empresa';
$Self->{'AuthSyncModule::LDAP::UID1'} = 'sAMAccountName';
$Self->{'AuthSyncModule::LDAP::SearchUserDN1'} = 'CN=Ruta del AD
donde está creado el usuario de lectura';
$Self->{'AuthSyncModule::LDAP::SearchUserPw1'} = 'contraseña usuario AD';
$Self->{'AuthSyncModule::LDAP::UserSyncMap1'} = {
UserFirstname => 'givenName',
77
UserLastname => 'sn',
UserEmail => 'mail',
};
Terminada esta configuración el sistema estará integrado al AD, y todos los agentes
podrán ingresar con su usuario y contraseña de dominio, para continuar con la
integración también se integrará la interfaz cliente para que los usuarios puedan ingresar
con su usuario de dominio y puedan reportar los incidentes por la interfaz.
Integración Cliente AD
Después del código agente se ingresa el siguiente código.
$Self->{'Customer::AuthModule'} =
'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host'} = 'Servidor OTRS';
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=dominio de
la empresa';
$Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'CN=ruta del
del usuario AD';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'contraseña AD';
$Self->{CustomerUser} = {
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => 'servidor OTRS',
BaseDN => 'dc=dominio',
SSCOPE => 'sub',
UserDN => 'CN=ubicación en el AD del usuario',
78
UserPw => 'contraseña del usuario AD',
},
CustomerKey => 'sAMAccountName',
CustomerID => 'sAMAccountName',
CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown, required, storage-type
# [ 'UserSalutation', 'Title', 'title', 1, 0, 'var' ],
[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
[ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
[ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],
# [ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var' ],
[ 'UserComment', 'Comment', 'description', 1, 0, 'var' ],
],
};
Luego de esta integración el usuario podrá ingresar en el portal cliente e ingresar un
ticket o darle seguimiento a una solicitud realizada a sistemas.
6.- Integración Servidor de Correo
79
Para ingresar al modulo administrador se tiene que realizar los siguientes pasos:
Ingreso con el usuario Administrador a OTRS.
Ingresamos en la pestaña administrador, hacemos clic en la opción configuración
del sistema.
Una vez ingresado al modulo administrador se tiene que realizar dos
configuraciones diferentes para que se pueda remitir y recibir correos por medio
de la interface OTRS.
7.- Configuración para habilitar el envío de correo en la aplicación OTRS
Para que se puedan enviar las notificaciones y cualquier tipo de correo desde la
aplicación se tiene que configurar el servidor de correo de la siguiente manera:
En configuración del sistema seleccionar en el combo izquierdo framework,
para luego hacer un click al sub grupo Core:SendMail. Figura 8.
Ingresar el protocolo que usa el servidor de correo en nuestro caso es SMTPS,
ingresamos el host de correo y el puerto que usa para el envío de correos.
8.- Configuración para habilitar la recepción de correo en la aplicación OTRS
Figura 28.- Selección de Framework y Senmail
Elaborado por: Autores
80
Para que se puedan receptar los correos en la aplicación se tiene que configurar el
servidor de correo de la siguiente manera:
En Ajustes del correo electrónico, se realiza clic en la opción PostMaster Mail
Accounts. Figura 9.
Figura 29.- Selección de PostMaster Mail
Elaborado por: Autores
En esta opción podemos añadir nuestra configuración haciendo click en add
mail account. Figura 10.
Figura 30.- Gestión de cuentas
Elaborado por: Autores
Configurar el servidor de correo con su respectivo protocolo de recepción en
nuestro caso será IMAPS
Ingresar una cuenta de correo con su respectiva contraseña.
En el campo host ingresar el nombre del server de correo
81
Área Responsable Rol Dirección de correoParametrizado
en OTRS
AREA DE TECNOLOGIA GONZALEZ EDWARD Administrador [email protected]
Especialista de
Desarrollo
GONZALEZ EDWARD
Agente
Especialista de
Infraestructura
AVILES VICTOR
Especialista de
Soporte
PINARGOTE
CHRISTIAN [email protected]
Supervisor de
Gestión
SEMPERTEGUI
VANESSA Supervisor de Gestión
Para finalizar la configuración, presionar el botón enviar, de esta manera
tendremos integrado la recepción de correo. Figura 11.
Figura 31.- Finalización de la configuración del correo
Elaborado por: Autores
9.- Parametrización y configuración del aplicativo
Basado en el documento de parametrización “Parametrización OTRS Farletza”
levantado con la empresa, se ingresa al sistema lo requerido.
Tabla 1.- Lista de usuarios
Elaborado por: Autores
Ingresa en el modulo administrador de OTRS. Figura 12.
Figura 32.- Grupos de Agentes
Elaborado por: Autores
82
Tras hacer clic en la opción grupo podemos ingresar los grupos solicitados por
la empresa.
El sentido de tener un grupo es para segmentar los repositorios de los ticket ya que
cada grupo tiene asignado un rol y una cola. En el momento que se crea los grupos
procedemos con la creación de roles.
Una vez creados los roles y los grupos se tienen que relacionar para que sea
una manera más fácil de la administración de permisos.
Para que este procesa tenga sentido se tiene que agregar los roles por cada conjunto
de permisos otorgados a los grupos.
La relación de cada rol con los grupos se realiza en la opción “Role-Group
Relations”
Figura 33.- Relación de roles
Elaborado por: Autores
Seleccionar el rol creación y se procede a asignar los permisos respectivos que
requiera según la definición del negocio.
En nuestro caso los roles serán los siguientes. Tabla 2:
Tabla 2.- Roles
Se sugiere los siguientes roles
Rol de Administrador Todos los permisos para administrar la
herramienta
Rol de Agente según su
grupo Permiso de crear ticket y reasignar
Rol Supervisor de Gestión Poder visualizar la reporteria del sistema
Elaborado por: Autores
83
El rol administrado tiene permiso total al grupo admin.
El rol Agente tiene permiso al grupo de especialistas.
El rol Supervisor solo visualiza tickets, no puede crear, ni manipular la
información.
Una vez creados los roles podemos asignarle a los agentes por medio de la opción
“Agents - Roles”.
Seleccionar al agente y por medio de un chek asignar el rol según la necesidad
del negocio. Figura 14.
Figura 34.- Selección de agente
Elaborado por: Autores
Para crear las colas y asignar a los grupos creados se tiene que ingresar en la opción
Colas. Figura 15
Figura 35.- Ajuste de las colas
Elaborado por: Autores
84
Añadir una cola, ingresando el nombre y el grupo a que corresponde.
Las colas se generan con el mismo nombre de los grupos que en la realidad son los
departamentos resolutores de TI.
Luego del ingreso de la cola se procede a enviar dicha parametrización para
que sea registrada en el sistema.
10.- Creación de estados de un incidente
Se configura los estados en la herramienta según las definiciones de la empresa.
Tabla 3.
Tabla 3.- Lista de estados
Estados Descripción
Abierto Ticket ingresado por el usuario que registra el incidente
Atendiéndose Ticket recibido por el agente y que se encuentra en atención
Cerrado sin
solución Ticket cerrado por el agente sin solución
Cerrado con
solución Ticket cerrado con la confirmación del usuario final
Elaborado por: Autores
11.- Prioridades de los incidentes
En nuestro levantamiento de información la empresa decidió trabajar con las mismas
prioridades que tiene el sistema de manera predeterminada.
85
12.- Notificaciones de tickets
Para configurar las notificaciones se define con la empresa lo siguiente. Tabla 4.
Tabla 4.- Tipos de notificaciones
Notificaciones para agentes y responsables
Tipos de Notificaciones Agente
asignado Usuario
Notificar cuando asignas propietario X
Notificar cuando un ticket se abre X X
Notificar cuando un ticket se cierra X X
Elaborado por: Autores
En la opción respuestas automáticas podemos configurar las notificaciones solicitadas
por el negocio que son las siguientes:
Cuando se asigna un propietario se genera de forma automática un correo con el
detalle del ticket.
Cuando un ticket se abre se notifica al usuario que será atendido asignando un
numero de ticket.
Cuando un ticket se atiende se genera de forma automática un correo notificando
al usuario que ya fue atendida su solicitud y que informe cualquier novedad en caso que
no esté conforme con la solución.
86
13.- Ingreso de Servicios en OTRS
Se configuran los servicios solicitados por Farletza estén disponibles en el aplicativo
OTRS, a continuación se detalla en una tabla los servicios parametrizados. Tabla 5.
Tabla 5.- Lista de servicios
Nivel 1 (Servicios) Nivel 2 (Proceso de Negocio) Nivel 3 (Soporte)
Comercial
Exportación
Mantenimiento Tecnológico Infraestructura Tecnológica
Investigación y Desarrollo Organización y Métodos
Marketing y Publicidad Desarrollo
Venta Pruebas
Servicio al Cliente Ajustes
Post Venta Liberación o Producción
Soporte a usuarios
Comercial
Importación
Mantenimiento Tecnológico Infraestructura Tecnológica
Investigación y Desarrollo Organización y Métodos
Marketing y Publicidad Desarrollo
Venta Pruebas
Servicio al Cliente Ajustes
Post Venta Liberación o Producción
Soporte a usuarios
Operaciones
Importación
Mantenimiento Tecnológico Infraestructura Tecnológica
Reserva Organización y Métodos
Documentación Desarrollo
Aduana Pruebas
Facturación Ajustes
Servicio al cliente Liberación o Producción
Soporte a usuarios
Operaciones
Exportación
Mantenimiento Tecnológico Infraestructura Tecnológica
Reserva Organización y Métodos
Documentación Desarrollo
Aduana Pruebas
Facturación Ajustes
Servicio al cliente Liberación o Producción
Recursos Humanos Mantenimiento Tecnológico Infraestructura Tecnológica
87
Selección Organización y Métodos
Contratación Desarrollo
Nómina Pruebas
Capacitación Ajustes
Bienestar Social Liberación o Producción
Desvinculación Soporte a usuarios
Adquisición
Mantenimiento Tecnológico Infraestructura Tecnológica
Evaluación de Proveedores Organización y Métodos
Compras Desarrollo
Inspección Pruebas
Producto no conforme Ajustes
Liberación o Producción
Soporte a usuarios
Administrativo
Mantenimiento Tecnológico Infraestructura Tecnológica
Aspectos legales activos fijos Organización y Métodos
Aspectos legales seguros Desarrollo
Proyectos y obras Pruebas
Control Presupuestario Ajustes
Servicios Generales Liberación o Producción
Soporte a usuarios
Contable
Mantenimiento Tecnológico Infraestructura Tecnológica
Registro Contable Organización y Métodos
Impuestos Desarrollo
Contabilidad Pruebas
Preparar documentación Ajustes
Liberación o Producción
Soporte a usuarios
Financiero
Mantenimiento Tecnológico Infraestructura Tecnológica
Inversiones Organización y Métodos
Cuentas por cobrar Desarrollo
Tesoreria Pruebas
Presupuesto Ajustes
Planificiación Financiera Liberación o Producción
Elaborado por: Autores
88
El ingreso de estos servicios se realiza a través de la opción “Servicios”. Figura 16.
Figura 36.- Ingreso de servicios
Elaborado por: Autores
Una vez terminado el ingreso de los servicio se asigna el SLA. Tabla 6.
Tabla 6.- Definición de SLA
SLAS INCIDENTES
Servicio Prioridad Tiempo de
atención
Tiempo de
Actualización
Tiempo de
cierre
SLA general Muy Alta 1 hora 1 hora 4 horas
SLA general Alta 2 horas 2 horas 8 horas
SLA general Normal 1 día 1 día 3 días
SLA general Baja 2 días 2 días 5 días
Elaborado por: Autores
Se los configura en la opción “acuerdos de niveles de servicios” se procede añadiendo
un SLA, se ingresa el nombre (SLA GENERAL, según la tabla 6). Figura 17.
Figura 37.- Ingreso de SLA
Elaborado por: Autores
89
Luego se tiene que seleccionar los servicios, asignar un calendario “se trabaja con el
predeterminado por OTRS” y finalmente se procede con el ingreso de los tiempos de
respuesta.
90
ANEXO 8.- FAR-MAN-TI-003 Manual de parametrización y
configuración
El sentido de tener un grupo es para segmentar los repositorios de tickets, ya que cada
grupo tiene asignado un rol y una cola:
En el momento que se crea los grupos procedemos con la creación de
roles.
Una vez creados los roles y los grupos, se tienen que relacionar, para
facilitar la administración de permisos.
Para que este procesa tenga sentido se tiene que agregar los roles por cada conjunto
de permisos otorgados a los grupos, la relación de cada rol con los grupos se realiza en
la opción Role-Group Relations. Figura 1.
Figura 1.- Asignación de grupos
Elaborado por: Autores
Se selecciona el rol creación y se procede a asignar los permisos respectivos que
requiera según la definición del negocio. En nuestro caso los roles serán los siguientes:
Rol de Administrador - Todos los permisos para administrar la
herramienta
Rol de Agente según su grupo - Permiso de crear ticket y reasignar
Rol Supervisor de Gestión - Poder visualizar reportes del sistema
Una vez creados los roles podemos asignarle a los agentes por medio de la opción
Agents - Roles, seleccionas al agente y por medio de un check se asigna el rol.
91
Para crear las colas y asignar a los grupos creados se tiene que ingresar en la opción
Colas. Figura 2
Añadir una cola, ingresando el nombre y el grupo a que corresponde.
Las colas se generan con el mismo nombre de los grupos que en la realidad son los
departamentos resolutores de TI.
Luego del ingreso de la cola se procede a enviar dicha parametrización
para que sea registrada en el sistema.
10.- Creación de estados de un incidente
Se configura los estados en la herramienta según las definiciones de la empresa.
Tabla 1.
Tabla 1.- Lista de estados
Estados Descripción
Abierto Ticket ingresado por el usuario que registra el incidente
Atendiéndose Ticket recibido por el agente y que se encuentra en atención
Cerrado sin solución Ticket cerrado por el agente sin solución
Cerrado con solución Ticket cerrado con la confirmación del usuario final
Elaborado por: Autores
Figura 2.- Ajuste de las colas Elaborado por: Autores
92
11.- Prioridades de los incidentes
En nuestro levantamiento de información la empresa decidió trabajar con las mismas
prioridades que tiene el sistema de manera predeterminada.
12.- Notificaciones de tickets
Para configurar las notificaciones se define con la empresa la siguiente tabla 2.
Tabla 2.- Tipos de notificaciones
Notificaciones para agentes y responsables
Tipos de Notificaciones Agente
asignado Usuario
Notificar cuando asignas propietario X
Notificar cuando un ticket se abre X X
Notificar cuando un ticket se cierra X X
Elaborado por: Autores
En la opción respuestas automáticas podemos configurar las notificaciones solicitadas
por el negocio que son las siguientes:
Cuando se asigna un propietario se genera de forma automática un correo con el
detalle del ticket.
Cuando un ticket se abre se notifica al usuario que será atendido asignando un
numero de ticket.
Cuando un ticket se atiende se genera de forma automática un correo notificando
al usuario que ya fue atendida su solicitud y que informe cualquier novedad en caso que
no esté conforme con la solución.
13.- Ingreso de Servicios en OTRS
Se configuran los servicios solicitados por Farletza para que estén disponibles en el
aplicativo OTRS.
93
El ingreso al sistema de estos servicios se tiene que realizar a través de la opción
“Servicios”. Figura 3.
Figura 3.- Ingreso de servicios
Elaborado por: Autores
Se ingresa el nombre del servicio y el sub servicio en caso de que tenga varios
niveles, en nuestro caso son tres niveles que se tiene que ingresar.
Una vez terminado el ingreso de los servicio se asigna el SLA, los cuales fueron
definidos de forma general. Tabla 4.
Tabla 4.- Definición de SLA
SLAS INCIDENTES
Servicio Prioridad Tiempo de
atención
Tiempo de
actualización
Tiempo de
cierre
SLA general Muy Alta 1 hora 1 hora 4 horas
SLA general Alta 2 horas 2 horas 8 horas
SLA general Normal 1 día 1 día 3 días
SLA general Baja 2 días 2 días 5 días
Elaborado por: Autores
94
Se los configura en la opción “acuerdos de niveles de servicios” se procede añadiendo
un SLA, se ingresa el nombre (SLA GENERAL, según tabla definida por la empresa).
Figura 4.
Luego se tiene que seleccionar los servicios, asignar un calendario “se trabaja con el
predeterminado por OTRS” y finalmente se procede con el ingreso de los tiempos de
respuesta.
Figura 4.- Ingreso de SLA
Elaborado por: Autores
95
Figura 1.- Creación de tickets
Elaborado por: Autores
Anexo 9.- FAR-MAN-TI-004 Manual de Usuario OTRS
1.- Creación de Ticket.
La opción “Nuevo Ticket” sirve para la creación de tickets y permite que un usuario
pueda registrar un requerimiento de servicio o de información o cualquier comunicación
que necesite realizar, a otro usuario mediante la emisión de un “ticket”.
Los campos a completar para crear un ticket son:
Tipo
Cliente
Cola
Servicio
Acuerdo de Servicio
Propietario
Asunto
Texto
Adjunto
Prioridad
Pasos para crear un ticket (Figura 1)
El usuario debe presionar en el icono “nuevo ticket”.
96
Figura 2.- Campos para la creación de tickets
Elaborado por: Autores
Se visualiza una pantalla llamada “nuevo ticket” (Figura 2)
Para, se refiere al lugar (por ejemplo área) donde se prestará el servicio o se analizará
lo solicitado en el ticket.
Asunto, corresponde al título del ticket.
Texto, permite ingresar el detalle del ticket para ser emitido.
Adjunto, permite adjuntar archivos (doc, xls, zip, rar, png, bmp, dbf, cdx y otros).
Prioridad, establece el nivel de importancia del ticket a crear siendo éstas las
siguientes:
BAJA: Prioridad baja dentro de todos los tickets registrados.
NORMAL: Prioridad normal, queda dentro de los tickets registrados, pero tiene
mayor prioridad frente a los tickets del tipo “bajo”.
ALTA: Prioridad alta sobre los tickets ya registrados en el sistema.
97
Figura 3.- Detalle del ticket
Elaborado por: Autores
Figura 4.- Agregar notas
Elaborado por: Autores
URGENTE: Prioridad urgente, se debe tomar inmediatamente, después que se
registra el ticket
2.- Panel Agente
Detalle del Ticket –Notas adjuntas a un Tickets (Figura 3)
El ticket original se presenta siempre en un primer nivel del cual se le despliega, en
otros niveles inferiores todas las notas realizadas en el mismo.
El detalle del ticket muestra el ticket conjuntamente con sus notas y a continuación
los campos en blanco “asunto” , “texto” , “anexo” , “estado” y “prioridad” para que el
usuario si desea realice alguna modificación o agregado al ticket original.
Siempre las modificaciones quedan registradas en una nueva nota que se anexa a las
ya existentes permitiendo realizar un seguimiento detallado de los cambios registrados al
ticket.
Para realizar un cambio o agregar una nota el usuario debe llenar los campos
correspondientes y seleccionar el botón “enviar”. Figura 4
98
Figura 5.- Ticket bloqueado
Elaborado por: Autores
Campo Nota.
La modificación que se realice en los datos de un ticket se registra mediante una nota
que se adjunta al ticket original.
Campo Cerrado.
Permite el cierre del ticket describiendo una solución válida para justificar el cierre, el
estado del cierre es cerrado con éxito.
Pendiente recordatorio
En este campo podemos cambiar el estado de abierto a pendiente, para realizar este
cambio tenemos que justificar porque aun no se ha cerrado el ticket.
Cambiar propietario
En el mismo panel tiene la opción de mover cola, la cual nos muestra todas las colas
para mover ese ticket y después de ingresar el ticket a la cola nueva cola proceder con la
asignación de un nuevo propietario “campo propietario”
3.- Ticket Bloqueado
La opción “Mi bloqueado”, permite consultar todos los tickets emitidos por el usuario
que se encuentre conectado en el sistema y usted es propietario. Para ingresar a esta
opción solo se debe hacer click sobre el ícono, este ícono se encuentra en el menú
horizontal superior. (Figura 5)
99
Figura 6.- Búsqueda
Elaborado por: Autores
Los tickets se pueden ordenar en forma ascendente o descendente por:
Número del ticket: Identificación del ticket
Antigüedad: Tiempo transcurrido desde que se creó el ticket.
Asunto: Título del ticket.
Estado: Situación en la que se encuentra el ticket.
Cola: Área, agente o grupo al que está dirigido el ticket para su resolución.
Propietario: El que creó el ticket
4.- Búsqueda
La opción “Búsqueda”, (Figura 6) permite realizar exploraciones de los tickets
emitidos bajo distintos filtros y los resultados pueden ser exportados a formato xls
(Excel), formato impresión o como tabla normal.
Para ingresar a la opción “Búsqueda” el usuario debe hacer click sobre el ícono
“buscar”
Para seleccionar el formato de salida el usuario debe elegir la opción “Formato de
resultado”.
Los formatos que permite generar son:
Normal: Muestra los tickets en el sistema OTRS.
CSV: Exporta los resultados de la búsqueda a un archivo Excel.
Imprimir: Opción que realiza una conexión con la impresora y muestra una
tabla con los campos principales del ticket.
100
Figura 7.- Enlazar
Elaborado por: Autores
Figura 8.- Crear relación
Elaborado por: Autores
4.- Enlazar Ticket
Para enlazar un ticket tienes que ubicarte en uno de los ticket que quieras hacer dicha
actividad.
En el panel del ticket (Figura 7) en la opción enlazar podemos relacionar este ticket
con otros.
En el campo ticket (Figura 8) ingresamos el número de ticket que queremos crear una
relación, y buscamos.
101
Figura 9.- Elegir la relación
Elaborado por: Autores
Figura 10.- Campos Libres
Elaborado por: Autores
Al momento de buscar en la parte inferior de la pantalla se mostrara un pequeño
menú con el ticket encontrado en donde podrás poner la relación padre/hijo/normal del
ticket encontrado (Figura 9).
5.- Campos Libres
En la opción de campos libres (Figura 10) podemos modificar los siguientes campos
si necesitamos realizar una corrección.
Titulo del Ticket.
Tipo
Servicio
SLA
102
ANEXO 10.- FAR-PRO-TI-001 Procedimiento de atención de llamadas
1. El procedimiento empieza cuando el usuario llama a la Ext. 555 que es la
extensión predefinida para comunicarse a la mesa de ayuda de FARLETZA.
2. Al contestar la llamada, el agente debe responder de la siguiente manera: “Mesa
de Servicios, buen(a) (día/tarde/) “NN” le saluda, ¿en qué le puedo ayudar?”
3. Una vez que el usuario describe el inconveniente que posee, el agente debe
confirmar el inconveniente reportado para tener claro el tema.
4. El agente debe solicitar al usuario los datos generales (Nombres, área, extensión)
y dependiendo de los casos, datos adicionales.
5. El agente sugerirá una solución conocida y guiará al usuario paso a paso en el
proceso para solucionar el inconveniente.
6. Si se trata de un incidente que el agente pudo solucionar, este deberá ser
registrado en la herramienta de gestión, detallando la solución dada y poniendo el ticket
en estado resuelto.
7. Si se trata de un incidente que no pudo ser solucionado por el agente telefónico y
requiere un servicio externo u otro nivel, el agente deberá reasignar el caso registrado en
la herramienta de gestión, especificando el detalle de lo realizado en la atención de 1er
nivel.
8. Cuando el agente termina de solventar la solicitud del usuario, ya sea por su
ayuda o creando tickets a terceros, se debe finalizar la llamada diciendo: “Un gusto
haberle atendido, ¿le puedo ayudar en algo más?”
103
ANEXO 11.- FAR-PRO-TI-002 Procedimiento de atención y
escalamiento
AGENTE N1
1.- Verificar si incidente se puede solucionar
El Nivel 1 verifica si puede solucionar el incidente y crea el caso en la herramienta. Si
no pude solucionar el incidente debe reasignar el caso, ir al paso #4
a) Si identifica que el caso corresponde al Agente N2, registra el caso
correspondiente, ir al paso #5
b) Si identifica que el caso corresponde al Agente N3, registra el caso
correspondiente, ir al paso #7
2.- Ejecutar solución remota para el incidente
Ejecutar y confirmar la solución para el incidente, ir al paso #3.
3.- Cerrar atención en la herramienta de gestión
Cerrar caso en la herramienta, automáticamente se genera un correo para el usuario
confirmando la solución del incidente, indicando que se atendió lo reportado y se
procederá a finalizar al caso. El correo generado es enviado con copia al Coordinador de
Servicios.
Nota: Seguir el “Procedimiento para la documentación de soluciones”.
4.- Reasignar agente para resolución del incidente
Se reasigna en la herramienta de gestión el incidente al Agente N2 para su atención.
Se genera un correo automático para el Agente N2
104
AGENTE N2
5.- Recibir notificación para atención
Recibe por correo electrónico la notificación para la atención del incidente. Revisa la
información del caso ingresada en la herramienta de gestión.
Si puede resolver de manera remota, ir al paso #2
Si debe asistir a sitio, ir al paso #6
6.- Ir a sitio donde se origina el incidente
Acude al puesto de trabajo del usuario que reportó el incidente, verifica y ejecuta la
solución del incidente verificando conformidad de usuario, ir a paso #3.
a) Si identifica que el caso corresponde al Agente N3, reasigna el caso
correspondiente, ir al paso #7
AGENTE N3
Recibe por correo electrónico la notificación para la atención del incidente. Revisa la
información del caso ingresada en la herramienta de gestión y atiende de manera remota,
ir al paso #2
Nota: Todos los niveles superiores pueden reasignar el caso hacia un nivel inferior
en caso de considerarlo necesario o escalado in
105
ANEXO 12.- FAR-PRO-TI-003 Procedimiento para la documentación
de soluciones
NIVEL QUE ATIENDE
1.- Posterior a la ejecución del paso #3 del anexo 11, se documenta la solución nueva,
aplicada para resolver el incidente, ir al paso #2.
2.- Validar con el Coordinador de Servicios si la solución amerita ser publicada. La
publicación será realizada si cumple los siguientes criterios:
Solución nueva.
Solución de alto impacto.
Solución tomó un tiempo considerable de revisión.
Solución no amerita ser publicada: fin del procedimiento.
Solución amerita ser publicada, ir al paso #3.
3.- Publicar la solución nueva, fin del procedimiento.
Información de solución
La solución debe contener la siguiente información:
Descripción del incidente.
Servicio Afectado.
Aplicación afectada.
Grado de afectación (usuario, área, departamento).
Instrucciones para ejecución de solución.
Rutas de ejecutables (en caso de necesitar ejecutar alguno).
Tiempo de solución.
106
ANEXO 13.- FAR-VAR-TI-001 Matriz de priorización de incidentes
(SLA)
Consideraciones para el tratamiento de incidentes
En el documento se detallan los niveles de prioridad, basados en la criticidad y el
impacto. Tablas 1 al 6. A continuación se detallan los servicios y aplicaciones actuales
que se consideran críticas para el negocio, así como la matriz de prioridad.
Tabla 1.- Lista de servicios críticos
Servicios Críticos de Negocio
Comercial Exportación
Comercial Importación
Operaciones Importación
Financiero
Elaborado por: Autores
Tabla 2.- Lista de servicios críticos
Descripción Prioridad Tiempo de
atención
Tiempo de
cierre
Prioridad muy alta 1 1 hora 4 hora
Prioridad alta 2 2 horas 8 horas
Prioridad media 3 1 día 3 día
Prioridad baja 4 2 días 5 días
Elaborado por:
Autores
Detalle de afectación Afectación
Afectación a un área Área
Afectación a un
departamento Departamento
Afectación a un usuario Un solo usuario
Elaborado por:
Autores
107
IMPACTO
Nivel de impacto Muy alta Alta Normal Baja
URGENCIA
Nivel de Urgencia Muy alta Alta Normal Baja
URGENCIA / IMPACTO
(Prioridad) Muy alta Alta Normal Baja
Muy alta 1 1 2 2
Alta 1 2 2 3
Media 2 2 3 4
Baja 3 4 4 4
108
Anexo 14.- FAR-VAR-TI-002 Esquemas de trabajo por nivel
Elaborado por: Autores
109
ANEXO 15.- FAR-VAR-TI-003 Responsabilidades por nivel
Es importante definir las actividades de cada rol presente en la propuesta, para
mejorar la organización, gestión y calidad de la atención brindada a todos los casos
reportados, pues cada persona conocer perfectamente lo que debe hacer, como hacerlo y
cuando hacerlo.
La lista de roles y actividad propuesta es la siguiente:
Agente de Mesa de Servicios (Nivel 1)
o Registro
o Clasificación
o Análisis
o Escalamiento o Resolución
o Cierre
Agente de Soporte en sitio (Nivel 2)
o Atención en sitio
o Instalación y configuración
o Soporte aplicativos
o Soporte estaciones de trabajo
Especialista (Nivel 3)
o Soporte aplicativos inHouse
o Soporte infraestructura tecnológica
Coordinador de Servicios
o Resolución de conflictos con el usuario
o Recepción y análisis de proyectos
o Elaboración y revisión de indicadores mensuales
o Entrega de informes a la Gerencia
110
ANEXO 16.- FAR-VAR-TI-004 Catalogo de Servicios
Nivel 1 (Servicios) Nivel 2 (Proceso de Negocio) Nivel 3 (Soporte)
Comercial Exportación
Mantenimiento Tecnológico Infraestructura Tecnológica
Investigación y Desarrollo Organización y Métodos
Marketing y Publicidad Desarrollo
Venta Pruebas
Servicio al Cliente Ajustes
Post Venta Liberación o Producción
Soporte a usuarios
Comercial Importación
Mantenimiento Tecnológico Infraestructura Tecnológica
Investigación y Desarrollo Organización y Métodos
Marketing y Publicidad Desarrollo
Venta Pruebas
Servicio al Cliente Ajustes
Post Venta Liberación o Producción
Soporte a usuarios
Operaciones Importación
Mantenimiento Tecnológico Infraestructura Tecnológica
Reserva Organización y Métodos
Documentación Desarrollo
Aduana Pruebas
Facturación Ajustes
Servicio al cliente Liberación o Producción
Soporte a usuarios
Operaciones Exportación
Mantenimiento Tecnológico Infraestructura Tecnológica
Reserva Organización y Métodos
Documentación Desarrollo
Aduana Pruebas
Facturación Ajustes
Servicio al cliente Liberación o Producción
Soporte a usuarios
Recursos Humanos
Mantenimiento Tecnológico Infraestructura Tecnológica
Selección Organización y Métodos
Contratación Desarrollo
Nómina Pruebas
Capacitación Ajustes
Bienestar Social Liberación o Producción
Desvinculación Soporte a usuarios
Adquisición
Mantenimiento Tecnológico Infraestructura Tecnológica
Evaluación de Proveedores Organización y Métodos
Compras Desarrollo
Inspección Pruebas
Producto no conforme Ajustes
Liberación o Producción
Soporte a usuarios
Administrativo
Mantenimiento Tecnológico Infraestructura Tecnológica
Aspectos legales activos fijos Organización y Métodos
Aspectos legales seguros Desarrollo
Proyectos y obras Pruebas
Control Presupuestario Ajustes
Servicios Generales Liberación o Producción
111
Soporte a usuarios
Contable
Mantenimiento Tecnológico Infraestructura Tecnológica
Registro Contable Organización y Métodos
Impuestos Desarrollo
Contabilidad Pruebas
Preparar documentación Ajustes
Liberación o Producción
Soporte a usuarios
Financiero
Mantenimiento Tecnológico Infraestructura Tecnológica
Inversiones Organización y Métodos
Cuentas por cobrar Desarrollo
Tesoreria Pruebas
Presupuesto Ajustes
Planificiación Financiera Liberación o Producción
Soporte a usuarios
112
ANEXO 17.- FAR-VAR-TI-005 Modelo Entidad-Relación
Elaborado por: Autores
113
ANEXO 18.- FAR-VAR-TI-006 Modelo Vista-Controlador
Elaborado por: Autores
114
ANEXO 19.- Cronograma de actividades
