universidad tÉcnica particular de loja -...
TRANSCRIPT
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ÁREA TÉCNICA
TITULO DE INGENIERO EN INFORMÁTICA
Análisis, diseño y plan de implementación del proceso de
Cobit 5 DSS02: “Gestionar peticiones e incidentes de servicios”
para la mesa de servicios tecnológicos de la empresa
“ORTEGACOM Cía. Ltda.”
TRABAJO DE TITULACIÓN
AUTORA: Cueva Ullauri, Ximena Michelle
DIRECTORA: Romero González, Karla Alexandra, Ing.
CENTRO UNIVERSITARIO LOJA
2016
ii
APROBACIÓN DE LA DIRECTORA DEL TRABAJO DE TITULACIÓN
Ingeniera.
Karla Alexandra Romero González
DOCENTE DE LA TITULACIÓN
De mi consideración:
El presente trabajo de titulación: Análisis, diseño y plan de implementación del proceso de
Cobit 5 DSS02: “Gestionar peticiones e incidentes de servicios” para la mesa de servicios
tecnológicos de la empresa “Ortegacom Cía. Ltda.” realizado por Cueva Ullauri, Ximena
Michelle ha sido orientado y revisado durante su ejecución, por cuanto se aprueba la
presentación del mismo.
Loja, Enero de 2016
_________________________
Karla Alexandra Romero González
CI: 1104233729
iii
DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS
Yo, Cueva Ullauri, Ximena Michelle declaro ser autora del presente trabajo de titulación:
Análisis, diseño y plan de implementación del proceso de Cobit 5 DSS02: “Gestionar
peticiones e incidentes de servicios” para la mesa de servicios tecnológicos de la empresa
“Ortegacom Cía. Ltda.”, de la titulación de Ingeniero en Informática, siendo Romero González,
Karla Alexandra directora del presente trabajo; y eximo expresamente a la Universidad
Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones
legales. Además certifico que las ideas, conceptos, procedimientos y resultados vertidos en
el presente trabajo investigativo, son de mi exclusiva responsabilidad.
Adicionalmente declaro conocer y aceptar la disposición del Art. 88 del Estatuto Orgánico de
la Universidad Técnica Particular de Loja, que en su parte pertinente textualmente dice:
“Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones,
trabajos científicos o técnicos y tesis de grado o trabajos de titulación que se realicen con el
apoyo financiero, académico o institucional (operativo) de la Universidad”.
___________________________
Cueva Ullauri, Ximena Michelle
Cédula: 1104183478
iv
DEDICATORIA
Con mucho cariño dedico la presente tesis:
A Dios, el ser supremo que me ha permitido llevar a cabo una más de
mis metas.
A mi madre, quien ha sido el pilar fundamental en mi vida y quien me
ha dado el ejemplo para salir adelante ante todas las adversidades.
Por su valor y cariño hacia sus hijos le dedico este trabajo en el que
se ve reflejado el fruto del amor y esfuerzo brindado hacia mí y mis
hermanos en todas circunstancias.
A mi esposo, hija y hermanos, todo lo que soy se lo debo a mi familia
quien es el motor para triunfar cada día.
Ximena
v
AGRADECIMIENTO
Agradezco de todo corazón a las personas que han contribuido de una
u otra manera a mi formación, tanto personal como profesional; en
especial a la Directora de Tesis, Karla Romero, gracias a su
orientación, motivación y paciencia, he podido culminar con éxito el
presente trabajo de investigación.
Ximena
vi
ÍNDICE DE CONTENIDOS
Carátula .................................................................................................................................. i
Aprobación del trabajo de titulación ........................................................................................ ii
Declaración de autoría y cesión de derechos ........................................................................ iii
Dedicatoria ............................................................................................................................ iv
Agradecimiento ...................................................................................................................... v
Índice de contenidos .............................................................................................................. vi
Índice de tablas ...................................................................................................................... x
Índice de figuras .................................................................................................................... xi
Resumen ejecutivo ................................................................................................................ 1
Abstract ................................................................................................................................. 2
Introducción ........................................................................................................................... 3
CAPÍTULO I: VISIÓN GENERAL DEL PROYECTO
1.1. Título del proyecto .......................................................................................................... 5
1.2. Definición y justificación del problema ............................................................................ 5
1.3. Objetivos ........................................................................................................................ 5
1.3.1. Objetivo General .................................................................................................. 5
1.3.2. Objetivos Específicos .......................................................................................... 5
1.4. Estrategia o metodología de desarrollo .......................................................................... 6
1.5. Resultados esperados .................................................................................................... 6
CAPÍTULO II: DESCRIPCIÓN DE LA EMPRESA ORTEGACOM CIA. LTDA.
2.1. Historia de la empresa .................................................................................................... 9
2.2. Misión ............................................................................................................................. 9
2.3. Visión ............................................................................................................................. 9
2.4. Objetivos ...................................................................................................................... 10
2.5. Estructura Organizacional ............................................................................................ 10
2.6. Organigrama del Área de Tecnologías de la Información (TI) ....................................... 11
2.7. Software e Infraestructura ............................................................................................ 11
2.8. Gestión de las peticiones y los incidentes de servicio en Ortegacom Cía. Ltda. ........... 12
2.9. Problemas encontrados en la Gestión actual de Peticiones e Incidentes de servicios .. 13
2.10. Peticiones e incidentes más comunes que son reportados a la Mesa de Servicios .. 13
vii
CAPÍTULO III: MARCO TEÓRICO 3.1. Evolución de COBIT ..................................................................................................... 16
3.2. Visión General de COBIT 5 .......................................................................................... 16
3.3. Principios de COBIT 5 .................................................................................................. 17
3.3.1. Principio 1: Satisfacer las Necesidades de las Partes Interesadas .................... 18
3.3.2. Principio 2: Cubrir la Empresa Extremo-a-Extremo ............................................ 18
3.3.3. Principio 3: Aplicar un marco de referencia único integrado ............................... 18
3.3.4. Principio 4: Hacer posible un enfoque holístico .................................................. 19
3.4. El modelo de procesos de COBIT 5.............................................................................. 21
3.4.1. Prácticas de Gestión: ......................................................................................... 22
3.4.2. Actividades ........................................................................................................ 23
3.5. Modelo ......................................................................................................................... 24
3.6. Proceso: “Gestionar Peticiones e Incidentes de Servicio” ............................................. 27
3.6.1. Objetivos y métricas del proceso ....................................................................... 28
3.6.2. Prácticas y Actividades del Proceso .................................................................. 29
3.7. Nivel de capacidad del proceso .................................................................................... 32
3.8. Herramientas informáticas para la gestión de una Mesa de Servicios Tecnológicos .... 34
3.8.1. OsTicket ............................................................................................................ 34
3.8.2. RT (Request Tracker) ........................................................................................ 36
3.8.3. OTRS: Open Ticket Request System................................................................. 39
CAPÍTULO IV: DISEÑO DEL PROCESO “GESTIONAR PETICIONES E INCIDENTES DE SERVICIOS” PARA LA MESA DE SERVICIOS TECNOLÓGICOS DE LA EMPRESA “ORTEGACOM CÍA. LTDA.” EN BASE A COBIT 5, DSS02 4.1. Alcance del diseño ....................................................................................................... 44
4.2. Proceso actual para “gestionar peticiones e incidentes de servicios” ............................ 44
4.3. Desarrollo de actividades para cumplir con las prácticas del proceso “Gestionar
Peticiones e Incidentes de Servicio” .................................................................................... 45
4.3.1. Práctica DSS02.01: Definir esquemas de clasificación de incidentes y
peticiones de servicio ................................................................................................... 46
4.3.2. Práctica DSS02.02: Registrar, clasificar y priorizar peticiones e incidentes ....... 48
4.3.3. Práctica DSS02.03: Verificar, aprobar y resolver peticiones de servicio. ........... 49
4.3.4. Práctica DSS02.04: Investigar, diagnosticar y localizar incidentes. .................... 50
4.3.5. Práctica DSS02.05: Resolver y recuperarse ante incidentes. ............................ 51
4.3.6. Práctica DSS02.06: Cerrar peticiones de servicio e incidentes .......................... 52
4.3.7. Práctica DSS02.07: Seguir el estado y emitir de informes ................................. 53
viii
4.4. Diagrama propuesto del proceso .................................................................................. 53
4.5. Roles y sus responsabilidades que participan en el nuevo proceso.............................. 56
4.5.1. Usuario .............................................................................................................. 56
4.5.2. Dueño del proceso ............................................................................................ 56
4.5.3. Analista de Service Desk (Nivel 1) ..................................................................... 57
4.5.4. Analista de Soporte (Nivel 2) ............................................................................. 58
4.5.5. Equipo Técnico / Analista de Soporte, Administrador (Nivel 3) .......................... 58
4.5.6. Coordinador de Incidentes y Escalamiento ........................................................ 59
4.5.7. Incident Manager ............................................................................................... 60
4.6. Descripción paso a paso del proceso diseñado ............................................................ 62
4.7. Indicadores del proceso ................................................................................................ 68
4.8. Evaluación de Herramientas para la Implementación del Proceso ............................... 70
4.8.1. Definición de parámetros a evaluar ....................................................................... 70
4.8.1.1. Aspectos Técnicos ...................................................................................... 70
4.8.1.2. Funcionalidades: ......................................................................................... 71
4.8.1.3. Aspecto Generales ...................................................................................... 74
4.8.2. Método de evaluación ............................................................................................ 75
4.8.3. Evaluación de las herramientas ............................................................................. 76
4.8.3.1. Aspectos Técnicos: ..................................................................................... 77
4.8.3.2. Funcionalidades: ......................................................................................... 77
4.8.3.3. Aspectos Generales: ................................................................................... 78
4.8.4. Resultado final de la evaluación ............................................................................ 79
CAPÍTULO V: PLAN DE IMPLANTACIÓN DEL PROCESO “GESTIONAR PETICIONES E INCIDENTES DE SERVICIOS” PARA LA MESA DE SERVICIOS TECNOLÓGICOS DE LA EMPRESA “ORTEGACOM CÍA. LTDA.” EN BASE A COBIT 5 5.1. El ciclo de vida del Proceso .......................................................................................... 82
5.1.1. Planificar ............................................................................................................ 82
5.1.2. Diseñar .............................................................................................................. 83
5.1.3. Construir / Implementar ..................................................................................... 83
5.1.4. Utilizar / Operar ................................................................................................. 84
5.1.5. Evaluar / Monitorizar .......................................................................................... 84
5.1.6. Actualizar / Eliminar ........................................................................................... 85
5.2. Resultados entregados a Ortegacom Cía. Ltda. ........................................................... 85
ix
CONCLUSIONES…………………………………………………………………………….. ........ 87
RECOMENDACIONES………………………………………………………………………. ........ 88
BIBLIOGRAFÍA……………………………………………………………………………………. .. 89
ANEXOS……………………………………………………………………………….. .................. 91
x
ÍNDICE DE TABLAS
Tabla 1: Metas de TI a las cuales apoya el proceso DSS02 de COBIT 5 ............................. 28
Tabla 2: Objetivos y métricas del proceso DSS02 de COBIT 5 ............................................ 28
Tabla 3: Cuadro Comparativo de Herramientas ................................................................... 42
Tabla 4: Escala de puntuación para la evaluación ............................................................... 76
Tabla 5: Detalle de URLs demo de las herramientas evaluadas .......................................... 76
Tabla 6: Evaluación de las Herramientas de acuerdo a Aspectos Técnicos ......................... 77
Tabla 7: Evaluación de las Herramientas de acuerdo las funcionalidades ........................... 77
Tabla 8: Evaluación de las Herramientas de acuerdo a Aspectos Generales ...................... 78
Tabla 9: Resultado final de la evaluación a las Herramientas .............................................. 79
Tabla 10: Planificación de Actividades ................................................................................. 83
xi
ÍNDICE DE FIGURAS
Figura 1: Organigrama de la empresa Ortegacom Cía. Ltda ................................................ 10
Figura 2: Organigrama del Área de Sistemas de la empresa Ortegacom Cía. Ltda. ............ 11
Figura 3: Diagrama del proceso para gestión de problemas e Incidentes ............................ 12
Figura 4: Evolución de COBIT ............................................................................................. 16
Figura 5: Principios de Cobit 5 ............................................................................................. 17
Figura 6: Catalizadores corporativos de COBIT 5 ................................................................ 19
Figura 7: Catalizadores de Cobit 5: Procesos ...................................................................... 22
Figura 8: Las áreas clave de Gobierno y Gestión de Cobit 5. .............................................. 25
Figura 9: Modelo de referencia de Procesos de Cobit 5. ...................................................... 26
Figura 10: Modelo de Capacidad de Cobit 5 Cobit 5 ............................................................ 33
Figura 11: Pantalla de inicio de una instalación por defecto de la Herramienta OsTicket ..... 36
Figura 12: Pantalla de inicio de una instalación por defecto de la Herramienta RT .............. 38
Figura 13: Pantalla para ingreso de tickets en la Herramienta OTRS .................................. 39
Figura 14: Página de Inicio de la Herramienta HESK ........................................................... 41
Figura 15: Relaciones entre procesos, según COBIT 5 ....................................................... 44
Figura 16: Diagrama del proceso para gestión de problemas e Incidentes .......................... 45
Figura 17: Definición de niveles de escalamiento ................................................................ 48
Figura 18: Formulario para el registro de peticiones e incidentes de servicio ....................... 49
Figura 19: Formulario para la asignación de peticiones e incidentes de servicio ................. 51
Figura 20: Diagrama propuesto del proceso para gestión de peticiones e Incidentes .......... 54
Figura 21: Diagrama propuesto del proceso para gestión de peticiones e Incidentes .......... 55
Figura 22: Propuesta de Organigrama del Área de Sistemas de la empresa Ortegacom Cía.
Ltda. .................................................................................................................................... 69
Figura 23: Resultado de la evaluación de las funcionalidades de las Herramientas para la
gestión de requerimientos e incidentes de servicios para la empresa “Ortegacom CIA.
LTDA” .................................................................................................................................. 80
Figura 24: Resultado de la evaluación de las Herramientas para la gestión de requerimientos
e incidentes de servicios para la empresa “Ortegacom CIA. LTDA” ..................................... 80
Figura 25: Ciclo de vida de un proceso en Cobit 5 ............................................................... 82
Figura 26: Cronograma de Actividades ................................................................................ 86
1
RESUMEN
En este trabajo se pretende identificar en la empresa Ortegacom Cía Ltda. el proceso de cómo
se gestionan actualmente las peticiones y los incidentes de servicios en su mesa de servicios
tecnológicos, para analizar, diseñar e implementar un nuevo proceso basado en COBIT 5 –
en su dominio “DSS02 Gestionar Peticiones e Incidentes de Servicio”, estructurando para ello
las actividades necesarias que permitan cumplir con cada una de las prácticas para la
implementación de este proceso.
Se estudia y analizan las herramientas Open Source que permiten la gestión de peticiones e
incidentes de servicios, la herramienta con los mejores criterios de evaluación, los mismos
que son propuestos y que será implementada en “Ortegacom Cía. Ltda”, esta herramienta
será un apoyo tecnológico para el equipo de mesa de servicios tecnológicos de la empresa.
Finalmente, se establece un plan de implementación del Proceso ya diseñado, apoyado en su
ciclo de vida e implementando la herramienta evaluada.
PALABRAS CLAVE: Cobit 5, peticiones, servicios, tecnológicos, proceso, gestión, incidente,
OsTicket, Request Tracker, OTRS, Hesk
2
ABSTRACT
In this project, we identify the company Cia Ltda Ortegacom the process of how they currently
manage requests and service incidents at their technology service desk, to analyze, design
and implement a new process based on COBIT. 5 - in your domain "DSS02 Manage Service
Requests and Incidents" structuring to do the necessary activities to meet each of the practices
for the implementation of this process.
We study and analyze Open Source tools for managing service requests and incidents, the
tool with the best evaluation criteria, they are proposed and will be implemented in "Ortegacom
Cia. Ltda ", this tool will be a support for technology service desk. Finally, an implementation
plan process designed and supported in their life cycle and implementing the tool set
evaluated.
KEYWORDS: Cobit 5, process, management, incident, OsTicket, Request Tracker, OTRS,
Hesk
3
INTRODUCCIÓN
El presente trabajo consiste en el Análisis, Diseño y Plan de Implementación de un proceso
basado en de COBIT 5 - DSS02: “Gestionar Peticiones e Incidentes de Servicios” para la
mesa de servicios tecnológicos de la Empresa “Ortegacom Cía. Ltda. Para ello se presenta
la situación actual de la empresa Ortegacom Cía Ltda, cómo surge y qué busca como
compañía, la misión y visión de la misma; se muestra cuál es la estructura organizacional, el
organigrama de la compañía y cómo se gestionan actualmente las peticiones y los incidentes
de servicios, las mismas que permiten establecer las dificultades y problemas que tiene el
proceso de petición e incidentes de servicios, por lo que es sumamente relevante la
implementación del proceso COBIT 5: DSS02.
Luego, se muestra el marco teórico de la investigación. A rasgos generales hace una
introducción de lo que es COBIT 5, y los procesos que este marco de referencia ofrece.
Posteriormente, se centra en el proceso “DSS02 Gestionar Peticiones e Incidentes de
Servicio”, a fin de poder caracterizar las actividades, procesos, metas y contribuciones que
dicho proceso hace al objetivo de la investigación y sobre todo, a las demandas y necesidades
que tiene la empresa Ortegacom Cía. Ltda. con respecto a este tema.
Una vez identificados las actividades actuales de la empresa y el marco teórico, se procede
con el diseño del proceso “Gestionar Peticiones e Incidentes de Servicio”, estableciendo
inicialmente las actividades necesarias que permitan cumplir con cada una de las prácticas
del proceso, según Cobit 5 – DSS02. Como resultado se presenta el diseño, el mismo que
dará la solución a los problemas que tiene la empresa con el proceso actual.
Se estudia y analizan las herramientas Open Source que permiten la gestión de peticiones e
incidentes de servicios para una mesa de servicios tecnológicos, se definen y califican los
criterios de evaluación de las herramientas y de esta manera escoge cuál es la mejor para la
implementación del proceso “Gestionar Peticiones e Incidentes de Servicios” para la mesa de
servicios tecnológicos de la Empresa “Ortegacom Cía. Ltda” con base a COBIT 5: DSS02.
Finalmente, se describe un plan de implementación del Proceso de COBIT 5: DSS02 -
“Gestionar Peticiones e Incidentes de Servicios” para la mesa de servicios tecnológicos de la
Empresa “Ortegacom Cia. Ltda.”, apoyado en el ciclo de vida del proceso, definido por COBIT
5.
CAPÍTULO I
VISIÓN GENERAL DEL PROYECTO
5
1.1. Título del proyecto
Análisis, Diseño y Plan de Implementación del proceso de COBIT 5 DSS02: “Gestionar
Peticiones e Incidentes de Servicios” para la Mesa de Servicios Tecnológicos de la Empresa
“Ortegacom Cía. Ltda.”
1.2. Definición y justificación del problema
La empresa “Ortegacom Cía. Ltda.” posee una mesa de servicios tecnológicos, a través de la
cual brinda sus servicios a los empleados de la empresa de una manera muy incipiente, pues
no tiene los procesos debidamente definidos, ni posee herramientas informáticas que
permitan automatizar y controlar procesos de peticiones y cumplimiento de las mismas. No
se conoce con exactitud la cantidad de peticiones que recibe la mesa de servicios
tecnológicos, ni el tiempo que se demoran en resolverlas, por lo tanto es mejor proponer un
proceso basado en una buena práctica que consta en el dominio DSS02 de Cobit 5.
Ante dicha problemática se hace necesario realizar el análisis, diseño y plan de
implementación del proceso de COBIT 5 DSS02: “Gestionar Peticiones e Incidentes de
Servicios” para la Mesa de Servicios Tecnológicos de la empresa “Ortegacom Cía. Ltda.”, con
lo que se gestionará mejor las actividades, se llevará un control sobre ellas y sobre todo se
optimizará y automatizará el proceso con herramientas informáticas Open Source, generando
así una mayor eficiencia, productividad y rentabilidad para la empresa local “Ortegacom Cía.
Ltda.” a nivel de este nuevo proceso.
1.3. Objetivos
1.3.1. Objetivo General
Analizar, Diseñar y Crear el Plan de Implementación del proceso de COBIT 5 DSS02:
“Gestionar Peticiones e Incidentes de Servicios” para la Mesa de Servicios Tecnológicos
de la empresa “Ortegacom Cía. Ltda.”
1.3.2. Objetivos Específicos
1. Analizar y evaluar la situación actual del negocio, aplicaciones de TI, actividades
y servicios de la empresa “Ortegacom Cía. Ltda.”
6
2. Diseñar el nuevo proceso basado en COBIT 5: DSS02 -“Gestionar Peticiones e
Incidentes de Servicios” para la mesa de servicios tecnológicos de la empresa
“Ortegacom Cía. Ltda.”
3. Evaluar las distintas herramientas Open Source que permitan la implementación
del proceso diseñado para gestionar peticiones e incidentes de servicios para la
mesa de servicios tecnológicos de la empresa “Ortegacom Cía. Ltda.”.
4. Elaborar un plan de implantación del proceso basado en COBIT 5: DSS02 -
“Gestionar Peticiones e Incidentes de Servicios” para la mesa de servicios
tecnológicos de la empresa “Ortegacom Cia. Ltda.”
1.4. Estrategia o metodología de desarrollo
Para la realización del presente trabajo de titulación se iniciará investigando el proceso actual
que realiza la mesa de servicios tecnológicos de la empresa Ortegacom Cía. Ltda,
identificando sus debilidades y fortalezas. Se hará una revisión exhaustiva del marco de
referencia COBIT 5 – Dominio DSS02: “Gestionar Peticiones e Incidentes de Servicios”, con
el objetivo de definir los aspectos más relevantes a tener en cuenta para la propuesta del
nuevo proceso, el cual debe cumplir con todos los requerimientos que necesita la empresa en
la gestión de Peticiones e Incidentes de Servicios, con sus respectivos actores, indicadores y
actividades.
Se analizará cuantitativamente las herramientas Open Source más populares, de acuerdo a
las funcionalidades que se necesiten para el proceso ya diseñado. Para proponer la
herramienta ideal se tendrá en cuenta la participación del usuario de manera constante y
activa y se basará en criterios de evaluación.
Finalmente se elaborará un Plan de Implementación del Proceso de COBIT 5: DSS02 -
“Gestionar Peticiones e Incidentes de Servicios” para la mesa servicios tecnológicos de la
Empresa “Ortegacom Cía. Ltda.”.
1.5. Resultados esperados
1. La empresa “Ortegacom Cía. Ltda.”, contará con el diseño del nuevo proceso
“Gestionar Peticiones e Incidentes de Servicios en su Mesa de” basado en COBIT 5,
DSS02.
7
2. Selección de una herramienta Open Source que más se ajuste al proceso diseñado
para gestionar peticiones e incidentes de servicios en la empresa “Ortegacom Cía.
Ltda.”.
3. La empresa “Ortegacom Cía. Ltda.”, contará con un plan de implementación del
Proceso del “Gestionar Peticiones e Incidentes de Servicios” para su mesa de
servicios tecnológicos, con base a COBIT 5: DSS02.
CAPÍTULO II
DESCRIPCIÓN DE LA EMPRESA ORTEGACOM CÍA. LTDA.
9
2.1. Historia de la empresa
La empresa Ortegacom Cía. Ltda. nace de la familia Ortega Ullauri, con el fin de consolidar
una empresa comercializadora de productos de primera necesidad, tales como: aceites, arroz,
azúcar, harina, granos, enlatados, productos de aseo personal y limpieza para el hogar, entre
otros, que satisfagan las necesidades de las personas que viven en la ciudad de Loja. En el
año 2005 abren su primer local, el mismo ha logrado convertirse y posicionarse en el mercado
de la provincia de Loja de manera sólida y eficaz.
Por el año 2012, se inaugura su moderno edificio administrativo y de bodegaje, ubicado en la
ciudad de Loja, en las calles Eduardo Mora Moreno e Ibarra, respondiendo así al gran
crecimiento de la compañía y a las necesidades de la demanda constante de los servicios que
brinda.
Actualmente, la empresa está conformada por un total de 72 empleados directos, los cuales
se encuentran distribuidos en la ciudad de Loja y en los alrededores de la provincia, además
cuenta con alrededor de 32 proveedores.
Ortegacom Cía. Ltda. cuenta con una Gerencia de Tecnologías de la Información, la cual se
encarga de todo lo referente a Software y Hardware de la empresa, así como en la
capacitación de nuevas tecnologías. Como parte de la Gerencia de Tecnologías de la
Información, la empresa posee una Mesa de Servicios Tecnológicos, la misma que se encarga
de la resolución de problemas e incidentes relacionados con los Sistemas de Información.
2.2. Misión
“Ofrecer a la ciudadanía una gran variedad en productos de consumo masivo de calidad, a
precios competentes, por medio de nuestro personal capacitado que da el mejor servicio,
comodidad y seguridad”.
2.3. Visión
“Ser la empresa distribuidora líder en la Región Sur del Ecuador, que ofrezca la mejor calidad
y variedad de productos, generando un valor agregado en el servicio para así contar con la
confianza que el cliente deposita en la empresa a la hora de elegir dónde comprar”.
10
2.4. Objetivos
1. Posicionar la empresa en la ciudad y ganar el reconocimiento por la calidad en ventas
y servicio.
2. Expandir la distribución de productos hacia la provincia de Loja y en la Región Sur
del País.
3. Obtener una rentabilidad que permita a la Empresa competir en el mercado a nivel
regional.
4. Asumir conciencia y responsabilidad social, contribuyendo con el desarrollo social de
la comunidad.
2.5. Estructura Organizacional
En la figura 1 se muestra el diagrama organizacional de la empresa Ortegacom Cía Ltda. el
mismo que está conformado por seis áreas o gerencias, que reportan directamente al
Presidente Ejecutivo; existe un asistente de gerencia que no reporta a ninguna gerencia sino
que está bajo el mando directo del Presidente Ejecutivo. Cada área tiene su gerente y a la vez
está al mando de otras sub-áreas o Jefaturas, dependiendo del caso.
Figura 1: Organigrama de la empresa Ortegacom Cía. Ltda. Fuente: Departamento de RRHH de la empresa Ortegacom Cía. Ltda.
Ortegacom Cía Ltda. maneja las siguientes líneas de Negocio:
Alimentos: aceite, manteca, mantequilla, arroz, azúcar, pastas, enlatados, aliños, yogurt,
Confites, snacks y Galletas: Caramelos, galletas, chocolates, chupetes, todo tipo de
golosinas.
Cuidado Personal: Pasta dental, cepillo, desodorantes, afeitadoras, cremas, shampoo,
enjuague bucal, hilo dental.
Limpieza para el Hogar: detergentes, cepillos, escobas, guantes
11
2.6. Organigrama del Área de Tecnologías de la Información (TI)
El área de Soporte Técnico de la empresa Ortegacom Cía Ltda. está conformado por dos
sub-áreas, tal como se muestra en la figura 2:
1. Técnico Primario - Asistencia
2. Técnico de Apoyo
Figura 2: Organigrama del Área de Sistemas de la empresa Ortegacom Cía. Ltda. Fuente: Departamento de RRHH de la empresa Ortegacom Cía. Ltda.
2.7. Software e Infraestructura
Las aplicaciones de software que se utilizan en la empresa son:
Mónica
Microsoft Office (Word, Excel, Power Point, Outlook)
Skype
Mozilla Firefox, Internet Explorer
Active Directory
Josephus (desarrollado en la empresa)
NetBeans
Microsoft SqlServer
Visual Studio.
Dentro de la empresa existen alrededor de 42 computadores (entre portátiles y equipos de
escritorio), 4 proyectores. Todos los computadores utilizan Windows 7 como Sistema
12
Operativo. En cuestión de redes cuenta con una WAN y WLAN, los computadores tienen
acceso a internet con restricciones a algunas páginas web.
Para el almacenamiento de datos del sistema Mónica y Josephus se utiliza la base de datos
Sql Server.
2.8. Gestión de las peticiones y los incidentes de servicio en Ortegacom Cía. Ltda.
Actualmente, la mesa de servicios tecnológicos de la empresa Ortegacom Cía. Ltda. no posee
un proceso definido para la gestión de peticiones y los incidentes de servicios, pues se los
tramita de forma rutinaria conforme cada técnico crea conveniente.
Normalmente, el proceso funciona de la siguiente manera: cuando un empleado de la empresa
tiene alguna petición o incidente con el sistema o su equipo informático, se comunica con el
analista de Service Desk y le reporta su problema; el analista es quién analiza si el problema
puede solventarlo él mismo, caso contrario lo redirecciona a quien crea que pueda solventarlo
(Soporte, Desarrollo, Infraestructura). La persona encargada del incidente o petición acude
al lugar de trabajo del empleado para solucionar el problema, en otras ocasiones lo hace
remotamente mediante “Escritorio Remoto” o por teléfono (ver figura 3). No se lleva un
registro de las peticiones e incidentes reportados ni resueltos, tampoco se utiliza ninguna
herramienta informática que facilite la gestión.
Figura 3: Diagrama del proceso para gestión de problemas e Incidentes. Fuente: Jefatura de Service Desk de la empresa Ortegacom Cía. Ltda. Elaborado por: Ximena Cueva, 2015
13
2.9. Problemas encontrados en la Gestión actual de Peticiones e Incidentes de
servicios
Se realizaron sesiones de trabajo conjuntamente con el personal de la mesa de servicios
tecnológicos y algunos de los empleados que alguna vez reportaron problemas o incidentes,
y mediante una lluvia de ideas se pudo identificar los problemas más comunes en la gestión
actual de peticiones e incidentes de servicios, los cuales se describe a continuación:
Hay ocasiones en que el Analista de Service Desk está ocupado atendiendo otros
incidentes por lo que no puede responder a las peticiones o llamadas de los
empleados, esta situación genera inconformidad e impide el desarrollo y cumplimiento
de las actividades normales de los datos, aplicaciones e infraestructura que tiene la
empresa.
La falta de un registro sistematizado y eficiente lleva a que a en algunas ocasiones,
las personas a las que les fueron asignados incidentes o peticiones, se olviden de
estas, por ende no llegan a ser atendidas a tiempo y no se registra quién cumplió o
quién no cumplió con dicha tarea.
No se puede obtener estadísticas que indiquen el trabajo que se ha realizado, la
cantidad de peticiones e incidentes solucionados por la mesa de servicios
tecnológicos de la empresa.
No existen indicadores que permitan mejorar o corregir el servicio, los procesos o las
aplicaciones de la empresa.
Los requerimientos e incidentes no son clasificados ni priorizados, el primero en
ingresar es el primero en ser atendido.
No se tiene documentadas las soluciones a los problemas reincidentes.
2.10. Peticiones e incidentes más comunes que son reportados a la Mesa de Servicios
Como ya se dijo anteriormente en el sucapítulo 2.8, actualmente en Ortegacom Cía. Ltda. no
se tiene un registro de los problemas más comunes que son reportados a TI, es por ello que
mediante sesiones de trabajo con los empleados que conforman la “Mesa de Servicios
Tecnológicos” se listaron los problemas e incidentes de mayor concurrencia, durante el lapso
14
de una semana.
Una vez identificados los problemas más comunes, se procedió con su clasificación, en tres
grandes grupos, de la siguiente manera:
Problemas de Software
Olvido de contraseña del usuario de red
Olvido de contraseña del sistema de ventas e inventarios
Instalación y ejecución de antivirus.
Instalación y configuración del sistema de ventas e inventarios
Capacitación del sistema de ventas e inventarios
El buzón de correo electrónico se llena, no se envían los correos electrónicos
El computador no permite instalar aplicaciones externas.
Instalación de herramientas de ofimática (Word, Excel, Power Point, Project, Visio)
Soporte con el aplicativo Power Point al realizar presentaciones.
Soporte con respecto a fórmulas o manejo de Excel.
Problemas de Redes
No se puede conectar a la red inalámbrica
Configuración del proxy para acceder a internet.
Problemas con asignación de IP y acceso a la red física.
Problemas de Hardware
Conexión y configuración del proyector (Videobeam).
El computador no enciende.
Algún periférico (ratón, teclado, pantalla) del computador no funciona correctamente.
CAPÍTULO III
MARCO TEÓRICO
3.1. Evolución de COBIT
En el año de 1996 COBIT empezó con la versión 1.0, enfocándose a la Auditoría de TI, luego
en abril 1998 presentó una versión desarrollada y mejorada, que cubría la versión anterior e
incluía un conjunto de herramientas de Implementación y Control. Como se puede observar
en la figura 4, COBIT fue evolucionando paulatinamente, hasta presentar su última versión
5.0 en el año 2012, permitiendo así que las tecnologías de la información y relacionadas se
gobiernen y administren la organización como un todo.
Figura 4: Evolución de COBIT Fuente: Cobit 5 Elaborado por: Ximena Cueva 2016
3.2. Visión General de COBIT 5
ISACA (2012), da la siguiente definición de COBI 5:
COBIT 5 es un marco de trabajo integral que ayuda a las empresas a alcanzar sus objetivos
para el gobierno y la gestión de las TI corporativas. Dicho de una manera sencilla, ayuda a las
empresas a crear el valor óptimo desde IT manteniendo el equilibrio entre la generación de
beneficios y la optimización de los niveles de riesgo y el uso de recursos. COBIT 5 permite a
las TI ser gobernadas y gestionadas de un modo holístico para toda la empresa, abarcando al
negocio completo de principio a fin y las áreas funcionales de responsabilidad de TI,
considerando los intereses relacionados con TI de las partes interesadas internas y externas.
(ISACA, COBIT 5, Un marco de negocio para el Gobierno y la Gestión de las TI de la Empresa,
2012, pág. 13)
Auditoría
Cobit 1 Cobit 2 Cobit 3 Cobit 4.0 / 4.1 Cobit 5
1996 1998 2000 2005/7 2012
EVO
LUC
IÓN
Gobierno de las TI de la Empresa
Gobierno de TI
Gestión
Control
17
La palabra COBIT proviene del acrónimo: “Control Objectives for Information Systems and
related Technology”, en español: “Objetivos de Control para Sistemas de Información y
Tecnologías Relacionadas”; es desarrollado por ISACA (Information Systems Audit and
Control Association), la versión 5 fue lanzada al público el 10 de abril del 2012.
COBIT 5 es actualmente a última versión, que tiene particularmente la edición del framework,
basado en COBIT 4.1. Esta nueva versión ha tenido una aceptación a nivel mundial ya que
sin desestimar el trabajo de otras versiones anteriores, en esta se encuentran fusionadas
procesos y normas enfocándolas para mejorar el trabajo y funciones según las necesidades
empresariales gracias a su facilidad para el acceso y manejo. Tiene un enfoque mayormente
empresarial dentro de la actual Tecnología de Información, y tomando en cuenta las
necesidades de las empresas en la era digital y el valor que requiere sus peticiones y servicios.
3.3. Principios de COBIT 5
COBIT 5 puede ser utilizado en empresas de cualquier tamaño, de cualquier tipo; se basa en
5 principios claves para el gobierno y la gestión de TI (ver figura 5).
Figura 5: Principios de Cobit 5 Fuente: (ISACA, COBIT 5, Un marco de negocio para el Gobierno y la Gestión de las TI de la Empresa, 2012) Elaborado por: ISACA, 2012
Estos cinco principios se describen a continuación:
18
3.3.1. Principio 1: Satisfacer las Necesidades de las Partes Interesadas
Cada empresa opera en un contexto distinto, determinado por factores externos e
internos, y requiere un sistema de gobierno y gestión personalizado.
Las necesidades de las partes interesadas deben transformarse en una estrategia
corporativa factible, por ello las empresas deben crear valor para sus accionistas
3.3.2. Principio 2: Cubrir la Empresa Extremo-a-Extremo
Tanto el Gobierno como la Gestión de la información y la tecnología son contempladas
por COBIT 5, desde una perspectiva de extremo a extremo, para toda la empresa; es
decir:
Integra el gobierno de la empresa TI en el gobierno corporativo. Es decir, el sistema
de gobierno para la empresa TI propuesto por COBIT 5 se integra sin problemas
en cualquier sistema de gobierno. COBIT 5 se alinea con las últimas visiones sobre
gobierno.
Cubre todas las funciones y procesos necesarios para gobernar y gestionar la
información corporativa y las tecnologías relacionadas donde quiera que esa
información pueda ser procesada. Dado este alcance corporativo amplio, COBIT 5
contempla todos los servicios TI internos y externos relevantes, así como los
procesos de negocio internos y externos. (ISACA, 2012).
3.3.3. Principio 3: Aplicar un marco de referencia único integrado
Se considera que COBIT es un marco de referencia único e integrado, porque:
Se alinea con otros estándares y marcos de referencia relevantes y, por tanto,
permite a la empresa usar COBIT 5 como el marco integrador general de gestión
y gobierno.
Es completo en cuanto a la cobertura de la empresa, proporcionando una base
para integrar de manera efectiva otros marcos, estándares y prácticas utilizadas.
Un marco general único sirve como una fuente consistente e integrada de guía en
un lenguaje común, no-técnico y tecnológicamente agnóstico.
Proporciona una arquitectura simple para estructurar los materiales de guía y
producir un conjunto consistente.
19
Integra todo el conocimiento disperso previamente en los diferentes marcos de
ISACA. (ISACA, 2012).
3.3.4. Principio 4: Hacer posible un enfoque holístico
Al referirse a “enfoque holístico”, se analiza a la empresa como un todo, mayor a la suma
de todas sus partes, de forma global e integrada.
ISACA (2012), define a los Catalizadores como “factores que, individual y
colectivamente, influyen sobre si algo funcionará – en este caso, el gobierno y la gestión
de la empresa TI. Los catalizadores son guiados por objetivos de alto nivel relacionados
con TI”. Algunos catalizadores necesitan ser gestionados y gobernados.
COBIT 5 describe siete categorías de catalizadores, mostrados en la figura 6, cada uno
se orienta a:
Figura 6: Catalizadores corporativos de COBIT 5 Fuente: (ISACA, COBIT 5, Un marco de negocio para el Gobierno y la Gestión de las TI de la Empresa,
2012) Elaborado por: ISACA, 2012
a. Catalizador: Principios, Políticas y Marcos de Referencia
Se refiere a los diferentes mecanismos de comunicación que permiten transmitir
dirección e instrucciones entre el gobierno y la dirección.
b. Catalizador: Procesos
Un proceso es “‘una colección de prácticas influenciadas por las políticas y
procedimientos de la empresa que toma entradas de un número dado de fuentes
20
(incluyéndose otros procesos), manipulando las entradas y produciendo salidas (p.
ej., productos, servicios)” (ISACA, 2012).
c. Catalizador: Estructuras Organizativas
Las estructuras organizativas permiten definir Niveles de Autoridades, procedimiento
de escalamiento y su objetivo final es la toma de decisiones.
d. Catalizador: Cultura, Ética y Comportamiento
Dentro de la empresa hace referencia a un conjunto de conductas o comportamientos
individuales y colectivos
e. Catalizador: Información
Este catalizador considera a la información (formal o informal, estructura o no
estructurada) como uno de los activos primordiales para la empresa.
f. Catalizador: Servicios, Infraestructura y Aplicaciones
Se refiere a la Infraestructura y aplicaciones que se utilizan para la prestación de
servicios de TI. Se definen principios de arquitectura, niveles de servicio.
g. Catalizador: Personas, Habilidades y Competencias
Considera a las personas como el objetivo más importante de empresa; define roles,
habilidades y responsabilidades para un efectivo desempeño de las actividades.
3.3.5. Principio 5: Separar el Gobierno de la Gestión
Tanto el Gobierno como la gestión contienen diferentes tipos de actividades, requieren
estructuras organizativas diferentes y sirven para diferentes propósitos.
Generalmente el Gobierno es responsabilidad del consejo de administración bajo la
dirección de su presidente, mientras que la Gestión es responsabilidad de la dirección
ejecutiva.
Por lo antes mencionado, es importante diferenciar entre lo que es Gobierno y lo que es
gestión:
Gobierno: El Gobierno asegura que se evalúan las necesidades, condiciones
y opciones de las partes interesadas para determinar que se alcanzan las
21
metas corporativas equilibradas y acordadas; estableciendo la dirección a
través de la priorización y la toma de decisiones; y midiendo el rendimiento y
el cumplimiento respecto a la dirección y metas acordadas. (ISACA, 2012)
Gestión: La gestión planifica, construye, ejecuta y controla actividades
alineadas con la dirección establecida por el cuerpo de gobierno para alcanzar
las metas empresariales. (ISACA, 2012)
3.4. El modelo de procesos de COBIT 5
Según ISACA (2012), define un proceso como “una colección de prácticas influidas por las
políticas y procedimientos de empresa que toma entradas de una serie de recursos
(incluyendo otros procesos), manipula las entradas y produce salidas (p. ej., productos,
servicios)” (pág. 19).
El modelo de procesos se divide en:
Partes Interesadas: Los procesos tienen partes interesadas internas y externas, con
sus propios roles; las partes interesadas y sus niveles de responsabilidad se hallan
documentados en matrices que muestran quién realiza, quién es responsable, a quién
se consulta o a quién se informa (RACI). Las partes interesadas externas incluyen
clientes, socios de negocio, accionistas y entidades reguladoras. Las partes
interesadas internas incluyen al Consejo de Administración, la dirección, el personal y
los voluntarios.
Metas: Las metas del proceso se definen como ‘una declaración que describe el
resultado deseado de un proceso. Un resultado puede ser cualquier elemento, un
cambio significativo de estado o una mejora significativa de la capacidad de otros
procesos’. Son parte de la cascada de metas, es decir, las metas de proceso apoyan
las metas TI, que a su vez apoyan las metas corporativas. (ISACA, COBIT 5, Procesos
Catalizadores, 2012).
Las metas de proceso se pueden categorizar en:
a) Metas intrínsecas: Cuando el proceso tiene calidad específica, es preciso y está en línea
con las buenas prácticas, además debe cumplir con las reglas internas y externas.
b) Metas contextuales: El proceso debe estar adaptado al cliente y a la situación específica
22
de la empresa, es entendible y fácil de aplicar.
c) Metas de accesibilidad y seguridad: El proceso mantiene la confidencialidad, cuando
se requiere, y es conocido y accesible por aquéllos que lo necesitan.
Para conocer hasta qué punto las metas son alcanzadas, se definen métricas; según ISACA
(2012), define una métrica como “una entidad cuantificable que permite medir el logro de las
metas de proceso. Las métricas deberían ser: específicas, medibles, practicables, pertinentes
y oportunas’ (SMART)”
Cada proceso de COBIT tiene un ciclo de vida con fases en donde: se define, crea, opera,
supervisa y ajusta/actualiza o retira. En la figura 7 se muestra el ciclo como una dimensión del
catalizador proceso.
Figura 7: Catalizadores de Cobit 5: Procesos Fuente: (ISACA, COBIT 5, Procesos Catalizadores, 2012) Elaborado por: ISACA, 2012
Cada proceso de COBIT contiene un conjunto de prácticas de gestión, cada práctica a la
vez contiene un conjunto de actividades a las que debe ajustarse el proceso de la empresa.
3.4.1. Prácticas de Gestión:
En los procesos COBIT 5, las prácticas de gobierno/gestión facilitan un conjunto de
requerimientos de alto nivel para un gobierno y gestión de la TI corporativa eficaces y
23
prácticos. Éstas son:
Declaraciones de acciones para obtener beneficios, optimizar el nivel de riesgo y
optimizar el uso de recursos - Alineadas con los pertinentes estándares y buenas
prácticas generalmente aceptados.
Genéricas y en consecuencia, con necesidad de ser adaptadas a cada compañía.
Que den cobertura a aquéllos que desempeñan un cargo de negocio y de TI en el
proceso (extremo a extremo). (ISACA, 2012, pág. 20).
Los organismos de gobierno y dirección de la compañía deben tomar decisiones relativas
a estas prácticas de gobierno y gestión de la siguiente forma:
Seleccionando aquéllas que son aplicables y decidiendo sobre aquéllas que serán
implantadas.
Añadiendo y/o adaptando prácticas donde sea necesario.
Definiendo y añadiendo prácticas no relacionadas con TI para su integración en los
procesos de negocio.
Eligiendo cómo implantarlas (frecuencia, alcance, automatización, etc.).
Aceptando el riesgo de no implantar aquellas que puedan aplicar. (ISACA, 2012, pág.
20)
3.4.2. Actividades
Son las principales acciones para operar un proceso, ISACA (2012) las define como
“orientación para alcanzar prácticas de gestión para un gobierno y gestión exitosos de la
TI de la compañía. Las actividades de COBIT 5 proporcionan el cómo, porqué y qué
implantar para cada práctica de gobierno o gestión para mejorar el desempeño de TI y/o
tratar el riesgo en la entrega de soluciones y servicios TI”. (pág. 20).
Todas las actividades de los procesos, que se muestran en ISACA (2012) son de mucha
utilidad para distintas partes interesadas:
La Dirección/Gerencia, proveedores de servicio, usuarios finales y profesionales TI
que necesitan planificar, construir, ejecutar o supervisar en un área de TI.
Profesionales de seguridad de la Información, a quienes se les puede pedir opinión
en relación con implantaciones actuales o propuestas o mejoras necesarias.
24
Las actividades
Describen un conjunto de pasos de implantación orientados a la acción, necesarios y
suficientes para alcanzar las prácticas de Gestión y de Gobierno.
Se Consideran las entradas y salidas de los procesos.
Se basan en estándares y buenas prácticas generalmente aceptadas.
Apoyan el establecimiento de cargos y responsabilidades claros.
No son prescriptivas y necesitan ser adaptadas y desarrolladas como procedimientos
específicos adaptados a la compañía. (ISACA, 2012, pág. 20).
Las entradas y salidas de una Práctica de Gestión, son necesarios porque apoyan la
operación del proceso. Según ISACA (2012): “Posibilitan las decisiones clave, proveen
un registro y traza de auditoría de las actividades de los procesos y posibilitan el
seguimiento en caso de incidente. Se definen al nivel de práctica clave de
gobierno/gestión, pueden incluir algunos productos de trabajo utilizados en el proceso y,
a menudo, son entradas esenciales para otros procesos.”.
3.5. Modelo
Las empresas pueden organizar sus procesos según como crean conveniente; dependiendo
del tamaño de la empresa, algunas pueden tener menos procesos, otras más, pero el fin es
cubrir los mismos objetivos básicos de Gobierno y de Gestión.
Cada empresa debe definir su propio conjunto de procesos, teniendo en cuenta sus
necesidades y su situación particular.
COBIT 5 sirve de apoyo para que las empresas implementen un gobierno y una gestión de
los procesos de forma que sus principales áreas estén cubiertas, tal como se muestra en la
figura 8.
25
Figura 8: Las áreas clave de Gobierno y Gestión de Cobit 5. Fuente: (ISACA, COBIT 5, Procesos Catalizadores, 2012) Elaborado por: ISACA, 2012
COBIT 5 divide sus procesos en dos grandes grupos: Gestión y Gobierno; cada grupo a la
vez contiene sus dominios y cada dominio un conjunto de procesos, como se muestra en la
figura 9.
Dominios de Gobierno:
Evaluar, Orientar y Supervisar (EMD)
Los dominios de gobierno implican varios procesos de Gobierno, que tratan de los “objetivos
de gobierno de las partes interesadas – entrega de valor, optimización del riesgo y de recursos
– e incluye prácticas y actividades orientadas a evaluar opciones estratégicas, proporcionando
la dirección de TI y supervisando la salida (Evaluar, orientar y supervisar)” (ISACA, 2012).
Dominios de Gestión:
Alinear, Planificar y Organizar (APO)
Construir, Adquirir e Implementar (BAI)
Entregar, dar Servicio y Soporte (DSS)
Supervisar, Evaluar y Valorar (MEA)
Los Dominios de Gestión traen consigo los Procesos de Gestión, los mismos que “cubren las
áreas de responsabilidad de TI de la empresa y tienen que proporcionar cobertura de TI
26
extremo a extremo” (ISACA, 2012).
El modelo de referencia de proceso de COBIT 5 es sucesor del modelo de proceso de COBIT
4.1. En la figura 9 muestra el conjunto completo de los 37 procesos de gobierno y gestión
dentro de COBIT 5.
Figura 9: Modelo de referencia de Procesos de Cobit 5. Fuente: (ISACA, COBIT 5, Procesos Catalizadores, 2012) Elaborado por: ISACA, 2012
A continuación se enumeran cada uno de los procesos de COBIT 5:
1. EDM01 Asegurar el establecimiento y mantenimiento del marco de gobierno
2. EDM02 Asegurar la entrega de beneficios
3. EDM03 Asegurar la optimización del riesgo
4. EDM04 Asegurar la optimización de los recursos
5. EDM05 Asegurar la transparencia hacia las partes interesadas
6. APO01 Gestionar el marco de gestión de TI
7. APO02 Gestionar la estrategia
8. APO03 Administrar la arquitectura empresarial
9. APO04 Gestionar la innovación
27
10. APO05 Gestionar la cartera
11. APO06 Gestionar el presupuesto y los costes
12. APO07 Gestionar los recursos humanos
13. APO08 Gestionar las relaciones
14. APO09 Gestionar los acuerdos de servicio
15. APO10 Gestionar los proveedores
16. APO11 Gestionar la calidad
17. APO12 Gestionar el riesgo
18. APO13 Gestionar la seguridad
19. BAI01 Gestionar los programas y proyectos
20. BAI02 Gestionar la definición de requisitos
21. BAI03 Gestionar la identificación y la construcción de soluciones
22. BAI04 Gestionar la disponibilidad y la capacidad
23. BAI05 Gestionar la habilitación del cambio organizativo
24. BAI06 Gestionar los cambios
25. BAI07 Gestionar la aceptación del cambio y de la transición
26. BAI08 Gestionar el conocimiento
27. BAI09 Gestionar los activos
28. BAI010 Gestionar la configuración
29. DSS01 Gestionar las operaciones
30. DSS02 Gestionar las peticiones y los incidentes del servicio
31. DSS03 Gestionar los problemas
32. DSS04 Gestionar la continuidad
33. DSS05 Gestionar los servicios de seguridad
34. DSS06 Gestionar los controles de los procesos de la empresa
35. MEA01 Supervisar, evaluar y valorar rendimiento y conformidad
36. MEA02 Supervisar, evaluar y valorar el sistema de control interno
37. MEA03 Supervisar, evaluar y valorar la conformidad con los requerimientos externos.
(ISACA, COBIT 5, Procesos Catalizadores, 2012)
3.6. Proceso: “Gestionar Peticiones e Incidentes de Servicio”
El proceso “Gestionar Peticiones e Incidentes de Servicio” es un proceso de gestión, el
segundo dentro del dominio “Entregar, dar Servicio y Soporte (DSS)” (ver figura 8); como parte
de los procesos de COBIT 5 recibe la etiqueta “DSS02”.
ISACA (2012) menciona que este proceso busca “Proveer una respuesta oportuna y efectiva
a las peticiones de usuario y la resolución de todo tipo de incidentes. Recuperar el servicio
normal; registrar y completar las peticiones de usuario; y registrar, investigar, diagnosticar,
28
escalar y resolver incidentes” (pág 177).
Su propósito principal es minimizar las interrupciones de servicio con la rápida solución a las
peticiones e incidentes, con ello se logrará una mayor productividad.
Este proceso también apoya la consecución de un conjunto de principales metas TI, descritas
en la sd 1:
Tabla 1: Metas de TI a las cuales apoya el proceso DSS02 de COBIT 5
Meta TI Métricas Relacionadas
04 Riesgos de negocio
relacionados con las TI
gestionados
• Porcentaje de procesos de negocio críticos, servicios TI y
programas de negocio habilitados por las TI cubiertos por
evaluaciones de riesgos.
• Número de incidentes significativos relacionados con las
TI que no fueron identificados en la evaluación de riesgos.
• Porcentaje de evaluaciones de riesgo de la empresa que
incluyen los riesgos relacionados con TI.
• Frecuencia de actualización del perfil de riesgo
07 Entrega de servicios de TI
de acuerdo a los requisitos
del negocio
• Número de interrupciones del negocio debidas a incidentes
en el servicio de TI
• Porcentaje de partes interesadas satisfechas con el
cumplimiento del servicio de TI entregado respecto a los
niveles de servicio acordados
• Porcentaje de usuarios satisfechos con la calidad de los
servicios de TI entregados
Fuente: (ISACA, COBIT 5, Procesos Catalizadores, 2012) Elaborado por: ISACA 2015
3.6.1. Objetivos y métricas del proceso
Tabla 2: Objetivos y métricas del proceso DSS02 de COBIT 5
Objetivos del proceso Métricas Relacionadas
1. Los servicios
relacionados con TI están
disponibles para ser
utilizados.
• Número y porcentaje de incidentes que causan
interrupción en los procesos críticos de negocio
• Tiempo promedio entre incidentes de acuerdo con el
servicio facilitado por TI
29
2. Los incidentes son
resueltos según los niveles
de servicio acordados.
• Porcentaje de incidentes resueltos dentro de un periodo
acordado/
Aceptable
3. Las peticiones de
servicio son resueltas
según los niveles de
servicio acordados y la
satisfacción del usuario.
• Nivel de satisfacción del usuario con la resolución de las
peticiones de servicio
• Tiempo promedio transcurrido para el tratamiento de
cada tipo de petición de servicio
Fuente: (ISACA, COBIT 5, Procesos Catalizadores, 2012) Elaborado por: ISACA 2015
3.6.2. Prácticas y Actividades del Proceso
Según ISACA 2012, el proceso “DSS02 Gestionar Peticiones e Incidentes de Servicio”
contiene las siguientes Prácticas Clave de gestión:
DSS02.01: Definir esquemas de clasificación de incidentes y peticiones de servicio.
DSS02.02: Registrar, clasificar y priorizar peticiones e incidentes.
DSS02.03: Verificar, aprobar y resolver peticiones de servicio.
DSS02.04: Investigar, diagnosticar y localizar incidentes.
DSS02.05: Resolver y recuperarse de incidentes.
DSS02.06: Cerrar peticiones de servicio e incidentes.
DSS02.07: Seguir el estado y emitir informes. (ISACA, COBIT 5, Procesos Catalizadores,
2012)
Cada práctica de Gestión a la vez contiene un conjunto de actividades, que indican
cómo, por qué y qué implementar para cada práctica, con el fin de mejorar el desempeño
de TI.
Práctica DSS02.01: Definir esquemas de clasificación de incidentes y peticiones de
servicio
ISACA 2012, menciona que esta práctica debe definir esquemas y modelos de
clasificación de incidentes y peticiones de servicio que la empresa utilizará. Contiene las
siguientes actividades:
30
Definir esquemas de clasificación y priorización de incidentes y peticiones de
servicio y criterios para el registro de problemas, para asegurar enfoques
consistentes en el tratamiento, informando a los usuarios y realizando análisis de
tendencias.
Definir modelos de incidentes para errores conocidos con el fin de facilitar su
resolución eficiente y efectiva.
Definir modelos de peticiones de servicio según el tipo de petición de servicio
correspondiente para facilitar la auto-ayuda y el servicio eficiente para las
peticiones estándar.
Definir reglas y procedimientos de escalamiento de incidentes, especialmente para
incidentes importantes e incidentes de seguridad.
Definir fuentes de conocimiento de incidentes y peticiones y su uso. (ISACA, 2012,
pág. 178)
Práctica DSS02.02: Registrar, clasificar y priorizar peticiones e incidentes
“Las peticiones e incidentes de servicio se deben identificar, registrar y clasificar,
adicionalmente se debe asignar una prioridad según la criticidad del negocio y los
acuerdos de servicio” (ISACA, 2012, pág. 178). Contiene las siguientes actividades:
Registrar todos los incidentes y peticiones de servicio, registrando toda la
información relevante de forma que pueda ser manejada de manera efectiva y se
mantenga un registro histórico completo.
Para posibilitar análisis de tendencias, clasificar incidentes y peticiones de servicio
identificando tipo y categoría.
Priorizar peticiones de servicio e incidentes según la definición de impacto en el
negocio del ANS y la urgencia. (ISACA, 2012, pág. 178)
Práctica DSS02.03: Verificar, aprobar y resolver peticiones de servicio
En esta práctica de Gestión se “debe seleccionar los procedimientos adecuados para
peticiones y verificar que las peticiones de servicio cumplen los criterios de petición
definidos” (ISACA, 2012, pág. 178). Contiene las siguientes actividades:
Verificar los derechos para realizar peticiones de servicio usando, cuando sea
posible, un flujo de proceso predefinido y cambios estándar.
Obtener aprobación financiera y funcional o firmada, si se requiere, o aprobaciones
predefinidas para cambios estándar acordados.
Completar las peticiones siguiendo el procedimiento de petición seleccionado,
31
utilizando, cuando sea posible, menús automáticos de autoayuda y modelos de
petición predefinidos para los elementos solicitados frecuentemente. (ISACA,
2012, pág. 178)
Práctica DSS02.04: Investigar, diagnosticar y localizar incidentes
“Identificar y registrar síntomas de incidentes, determinar posibles causas y asignar
recursos a su resolución” (ISACA, 2012, pág. 178). Posee las siguientes actividades:
Identificar y describir síntomas relevantes para establecer las causas más
probables de los incidentes. Hacer referencia a los recursos de conocimiento
disponibles (incluyendo errores y problemas conocidos) para identificar posibles
resoluciones de incidentes (soluciones temporales y/o soluciones permanentes).
Registrar un nuevo problema si un problema relacionado o error conocido no existe
aún y si el incidente satisface los criterios acordados para registro de problemas.
Asignar incidentes a funciones especialistas si se necesita de un conocimiento más
profundo, e implicar al nivel de gestión apropiado, cuando sea necesario. (ISACA,
2012, pág. 178)
Práctica DSS02.05: Resolver y recuperarse ante incidentes
Para que el proceso se ajuste a esta práctica, se debe “documentar, solicitar y probar las
soluciones identificadas o temporales y ejecutar acciones de recuperación para restaurar
el servicio TI afectado” (ISACA, 2012, pág. 178). Contiene las siguientes actividades:
Seleccionar y aplicar las resoluciones de incidentes más apropiadas (soluciones
provisionales y/o soluciones permanentes).
Registrar si se usaron soluciones temporales para resolver los incidentes.
Ejecutar acciones de recuperación, si se requieren.
Documentar la resolución del incidente y evaluar si puede usarse como una fuente
de conocimiento en el futuro. (ISACA, 2012, pág. 178)
Práctica DSS02.06: Cerrar peticiones de servicio e incidentes
Se debe “verificar la resolución de incidentes y/o satisfactorio cumplimiento de
peticiones” (ISACA, 2012, pág. 179). Posee las siguientes actividades:
Verificar con los usuarios afectados (si lo han acordado) que la petición de servicio
32
ha sido completada o el incidente ha sido resuelto de manera satisfactoria.
Cerrar peticiones de servicio e incidentes. (ISACA, 2012, pág. 179)
Práctica DSS02.07: Seguir el estado y emitir de informes
En esta la última práctica del proceso, se debe “hacer seguimiento, analizar e informar
de incidentes y tendencias de cumplimiento de peticiones, regularmente, para
proporcionar información para la mejora continua” (ISACA, 2012, pág. 179). Contiene las
siguientes actividades:
Supervisar y hacer seguimiento del escalado de incidentes y de resoluciones y de
los procedimientos de gestión de resoluciones para progresar hacia la resolución
o cumplimentación.
Identificar la información para las partes interesadas y sus necesidades de datos o
informes. Identificar la frecuencia y el medio para informarles.
Analizar incidentes y peticiones de servicio por categoría y tipo para establecer
tendencias e identificar patrones de asuntos recurrentes, infracciones de ANSs
(Acuerdos de Niveles de Servicio) o ineficiencias. Utilizar la información como
entrada a la planificación de la mejora continua.
Producir y distribuir informes en tiempo o proporcionar acceso controlado a datos
online. (ISACA, 2012, pág. 179).
3.7. Nivel de capacidad del proceso
Según ISCACA (2012), el Nivel de Capacidad del Proceso “mide tanto la consecución de
metas como la aplicación de buenas prácticas. Apoya a la mejora del proceso, es decir, que
proporcionará un medio para medir el desempeño de cualquiera de los procesos de gobierno
o de gestión, y permitirá identificar áreas de mejora.”
Existen seis niveles de capacidad que se pueden alcanzar por un proceso (ver figura 10),
incluida la designación de “proceso incompleto” si las prácticas definidas en el proceso no
alcanzan la finalidad prevista:
33
Figura 10: Modelo de Capacidad de Cobit 5 Cobit 5 Fuente: (ISACA, 2012) Elaborado por: Ximena Cueva, 2015
0 Proceso incompleto: El proceso no está implementado o no alcanza su propósito. A este
nivel, hay muy poca o ninguna evidencia de ningún logro sistemático del propósito del proceso.
1 Proceso ejecutado (un atributo): El proceso implementado alcanza su propósito.
2 Proceso gestionado (dos atributos): El proceso ejecutado descrito anteriormente está ya
implementado de forma gestionada (planificado, supervisado y ajustado) y los resultados de su
ejecución están establecidos, controlados y mantenidos apropiadamente.
3 Proceso establecido (dos atributos): El proceso gestionado descrito anteriormente está
ahora implementado usando un proceso definido que es capaz de alcanzar sus resultados de
proceso.
4 Proceso predecible (dos atributos): El proceso establecido descrito anteriormente ahora
se ejecuta dentro de límites definidos para alcanzar sus resultados de proceso.
5 Proceso optimizado (dos atributos): El proceso predecible descrito anteriormente es
mejorado de forma continua para cumplir con las metas empresariales presentes y futuros.
(ISACA, COBIT 5, Procesos Catalizadores, 2012)
Cada nivel de capacidad puede ser alcanzado sólo cuando el nivel inferior se ha alcanzado
por completo. Por ejemplo, un nivel 3 de capacidad de proceso (establecido) requiere que los
atributos de definición y despliegue del proceso se hayan alcanzado ampliamente, sobre la
consecución completa de los atributos del nivel 2 de madurez de procesos (proceso
34
gestionado).
El nivel de capacidad brinda un perfil a través del cual la evolucionan las empresas para la
administración y el control de los procesos de TI.
3.8. Herramientas informáticas para la gestión de una Mesa de Servicios Tecnológicos
Existen muchas herramientas en el mercado que permiten la Gestión de una mesa de
servicios tecnológicos, algunas de pago y otras gratuitas. Como ya se ha revisado
anteriormente, para el presente trabajo de investigación se analizarán las herramientas Open
Source que más se acoplen a las necesidades de la empresa y al proceso diseñado, entre
las cuales se tiene:
1. OsTicket
2. RT (Request Tracker)
3. OTRS: Open Ticket Request System
4. HESK
A continuación se describe brevemente cada una de estas herramientas, sus principales
funcionalidades y sus aspectos técnicos.
3.8.1. OsTicket
OsTicket es una herramienta de tickets de código abierto ampliamente utilizado y de
confianza; permite crear los tickets a través de correo electrónico, formularios web y
llamadas telefónicas, en su plataforma web fácil de usar y multi-usuario. OsTicket
contiene más funciones y herramientas que muchos de los sistemas de pago de ticket en
el mercado. En su página web en inglés se muestran varias de sus funcionalidades.
(OsTicket:: Support Ticket System, 2015).
Principales funcionalidades:
Campos personalizados: Personalizar los datos recogidos de los usuarios al
momento de ingresar un ticket, con el fin de ayudar a conseguir información más
exacta del problema en cuestión.
Texto HTLM: texto enriquecido o correo electrónico HTML, permite al staff marcar e
35
ingresar notas internas personalizadas en formato HTML.
Filtros: permite definir reglas para que los tickets se enrruten directamente a los
departamentos adecuados o miembros del personal.
Temas de ayuda: Permite configurar temas de ayuda, de los problemas más
comunes y ponerlos a disposición de los usuarios, dando así la solución al problema
sin que el usuario tenga que generar un nuevo ticket.
Agente de prevención de colisiones: mecanismo de bloqueo de tickets para
permitir que el personal bloquee los tickets mientras lo responde y así evitar
respuestas contradictorias o dobles.
Asignar y Transferencia: transferencia de tickets entre los departamentos para
asegurarse de que está siendo manejado por el personal correcto.
Auto-Responder: respuesta automática configurable cuando se abre un nuevo
ticket o cuando se recibe un mensaje.
Notas internas: Permite al personal añadir notas internas a los tickets. Los registros
de actividades le permiten ver los eventos o acciones que se han tomado, cuando se
llevaron a cabo, y por quién.
Acuerdos de Nivel de Servicio: Los ANS’s permiten realizar un seguimiento de los
tickets y las fechas de vencimiento sin ningún problema.
Portal del cliente: Todas los tickets y sus respuestas son guardados en línea. El
usuario puede iniciar sesión utilizando el correo electrónico y el ID de ticket. No se
requiere cuentas de usuario para registrar un ticket.
Informes Dashboard: Obtiene información general del sistema y estadísticas
históricas basadas en el conteo de tickets, por estado, departamento, personal y
temas de ayuda.
36
Aspectos Técnicos:
Sistema Operativo: Indistinto
Tecnología: PHP 5.3 o superior
Base de Datos: MySQL 5 o superior
Servidor Web: Apache2
En la figura 11, se puede observar la pantalla de inicio de una instalación por defecto de
la herramienta OsTicket, esta plantilla puede ser editada con el usuario de Administrador
sin necesidad de tener conocimientos de programación.
Figura 11: Pantalla de Inicio de una instalación por defecto de la Herramienta OsTicket Fuente: http://www.osticket.com/features Elaborado por: Enhancesoft
3.8.2. RT (Request Tracker)
RT (Request Tracker) es un sistema para la gestión de problemas probado que miles de
organizaciones utilizan para el seguimiento de errores, help desk, venta de entradas,
servicio al cliente, los procesos de flujo de trabajo, gestión del cambio, operaciones de
red, servicios de orientación e incluso más. Organizaciones de todo el mundo han estado
utilizando RT durante más de 10 años, sin inconvenientes.
37
No hay necesidad de esperar para una cita o para una persona de ventas que
le envíe una demo. La versión completa, lista para la empresa de RT está
siempre disponible sin ningún costo bajo una licencia de código abierto. Eso
significa que es suyo para usar y personalizar como quieras. RT está construido
desde el principio para ser fácil de adaptar a su organización y sus
necesidades. (Best Practical Solutions LLC., 2015).
Principales Funcionalidades:
Interfaz móvil-optimizada para dispositivos móviles del staff: iPhone, Android y
WebOS.
Dashboards y gráficos de relación.
Búsqueda de usuarios y ver los resúmenes personalizados de ellos.
Edición de texto enriquecido dar formato fácilmente a los tickets.
Sistema de seguimiento y reportes, incluyendo soporte para el apoyo a los acuerdos
de nivel de servicio.
Construcción de gráficos que resumen su actividad por el tiempo.
Integración con el sistema de inicio de sesión de usuario existente.
Fácil personalización y cambio de tema de la interfaz con el editor de temas.
Una interfaz de autoservicio para que los que no son usuarios puedan interactuar con
sus tickets.
Incorporación de artículos en el almacén respuestas y una base de conocimientos del
personal.
38
Aspectos Técnicos:
Sistema Operativo: Linux, Mac OS X server, FreeBSD, Solaris u otro Sitema
Operativo como Unix.
Base de datos: MySQL, PostgreSQL, Oracle.
Servidor Web: Apache, Lighttpd, nginx, u otro servidor que soporte FastCGI.
En la figura 12 se puede observar la pantalla de inicio de la instalación por defecto de
RT (Request Tracker).
Figura 12: Pantalla de Inicio de una instalación por defecto de la Herramienta RT Fuente: https://www.bestpractical.com/rt Elaborado por: Best Practical Solutions, LLC.
39
3.8.3. OTRS: Open Ticket Request System
Según (OTRS , 2015), 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 abierta, 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. Se han realizado más de 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.
OTRS tiene un diseño muy simple, muestra de ello lo podemos ver en la Figura 13, donde
se muestra un formulario para el ingreso de tickets.
Figura 13: Pantalla para ingreso de tickets en la Herramienta OTRS Fuente: https://www.otrs.com/software/?lang=es Elaborado por: OTRS Group
40
Principales Funcionalidades:
Asistencia de escritorio a nivel empresarial
Gestión de procesos
Administración de Incidencias / Problemas
Base de datos de clientes
Autoservicio/portal de clientes
Estadísticas
Base de datos de conocimientos
Encuestas
Acuerdos de Nivel de Servicio
Aspectos Técnicos:
Sistema Operativo: Windows/Linux
Tecnología: PHP 5.3 o superior
Base de Datos: MySQL 5 o superior
Prerrequisitos: Apache2 + mod_perl2
3.8.4. HESK
HESK es una herramienta de ticket de soporte gratuito y aplicación de base de
conocimiento. Inicialmente lanzado en 2009, HESK ha crecido y se ha convertido en una
de las soluciones de apoyo gratuitos más populares.
Funcionalidades
Base de conocimientos: permitiendo a los usuarios resolver por sí solos problemas
comunes.
Ingreso de tickets a través del sistema web.
Consulta de tickets
Organización de los tickets por categorías
Priorización de tickets.
Agregar notas, archivos y modificar detalles de los tickets.
Multi-idioma
41
Personalización de campos para el ingreso de tickets.
Generación de reportes por fecha, categoría, usuario.
Bloqueo de IPs para el acceso al sitio web.
Configuración de Notificaciones
Reasignación de tickets.
Aspectos Técnicos
Sistema Operativo: Windows/Linux
Tecnología: PHP 5.3 o superior
Base de Datos: MySQL 5 o superior
Servidor Web: Apache2
HESK posee una simple pero muy intuitiva página de inicio, como se puede visualizar en
la figura 14.
Figura 14: Página de Inicio de la Herramienta HESK Fuente: https://www.otrs.com/software/?lang=es Elaborado por: OTRS Group
42
A continuación se presenta un cuadro comparativo de las Herramientas describiendo sus
fortalezas y debilidades en las que se diferencian:
Tabla 3: Cuadro Comparativo de Herramientas
Herramienta Fortalezas Debilidades
Permite que el usuario pueda ver en cualquier momento el avance de su consulta.
Permite crear alertas.
Herramienta multi-
usuario permite crear, clasificar, manejar peticiones y respuestas en un solo lugar.
No permite reapertura de ticket, se debe crear un ticket como nuevo caso.
Genera Reportes
Generalizados presentando de una manera global todos los tickets abiertos y concluidos.
Al crear un nuevo ticket cuenta con las opciones d clasificar, priorizar el ticket por parte del usuario.
Permite adjuntar archivos
de cualquier tipo para una mejor explicación del problema o incidente.
No genera Reportes específicos que muestren a la mesa de servicios tecnológicos los resultados de los tickets.
Su interfaz no es muy
amigable (grafica) por lo que dificulta el acceso que tengan los usuarios y requiere una mayor capacitación del personal.
Asignación y reasignación de tickets a personas encargadas o especialistas para una pronta solución.
Asignación de tiempo
estimado de solución y contador de tiempo de respuesta.
No presta una completa ayuda para la clasificación especifica de tickets.
No cumple con los
requisitos necesarios para el ANS (Acuerdo de Nivel de Servicios).
Cuenta con una interfaz gráfica realmente amigable con el usuario que facilita el uso y el acceso a la herramienta.
Incluye aplicación móvil y
chat en vivo para comunicarse con el personal
Tiene mediana cobertura para personalización de formularios de ingreso.
En reapertura de tickets se
genera nuevamente un código de caso, no permite seguir con el mismo lo que dificulta el control del mismo.
Fuente: Ximena Cueva Elaborado por: Ximena Cueva 2015
43
CAPÍTULO IV
DISEÑO DEL PROCESO “GESTIONAR PETICIONES E INCIDENTES DE SERVICIOS”
PARA LA MESA DE SERVICIOS TECNOLÓGICOS DE LA EMPRESA “ORTEGACOM
CÍA. LTDA.” EN BASE A COBIT 5, DSS02
44
4.1. Alcance del diseño
En la empresa Ortegacom Cía Ltda. “Gestionar Peticiones e Incidentes de Servicios” será el
primer proceso que se implementará con base a COBIT 5, es decir, no existen más procesos
con los cuales se pueda interrelacionar. A medida que se vayan implementando más
procesos, se podrán realizar las modificaciones necesarias para establecer dichas relaciones.
Así por ejemplo, una salida del proceso A puede servir como entrada del proceso B; y una
salida del proceso B puede servir como entrada de los procesos X y Z (ver figura 15), para
nuestro caso no existirán estas relaciones.
PROCESO A PROCESO B
PROCESO X
PROCESO Z
entrada
salida
salida
Figura 15: Relaciones entre procesos, según COBIT 5 Fuente: COBIT 5 Elaborado por: Ximena Cueva, 2015
Se establecerán las actividades necesarias que permitan cumplir con cada una de las
prácticas del proceso, detallados en el capítulo III.
Se mostrará un diagrama del proceso actual y se elaborará un diagrama del proceso con base
a Cobit 5, en el que se muestren cada uno de los pasos que deberán cumplirse.
4.2. Proceso actual para “gestionar peticiones e incidentes de servicios”
Como se mencionó en el Capítulo II, literal 2.7, no existe un proceso definido para gestionar
las peticiones e incidentes de servicio. En la figura 16 se muestra un diagrama del proceso
que lleva a cabo la mesa de servicios tecnológicos de la empresa “Ortegacom Cía. Ltda.”, en
el cual uno de los principales actores es el Analista de Service Desk, quien es el que se pone
en contacto con el empleado y da solución a los problemas más conocidos.
45
Reporta incidente
Resuelve Incidente
Analista de Service Desk
SoporteDesarrollo
Infraestructura
Resuelve Incidente
Redireccionar incidente
Figura 16: Diagrama del proceso para gestión de problemas e Incidentes. Fuente: Jefatura de Service Desk de la empresa Ortegacom Cía. Ltda. Elaborado por: Ximena Cueva, 2015
Descripción del proceso actual: un empleado de la empresa reporta un incidente al Analista
de Service Desk, éste resuelve el problema en caso de que pueda hacerlo, caso contrario lo
redirecciona a quien crea que pueda solventarlo (soporte, desarrollo, infraestructura).
El proceso actual contiene varios problemas, descritos en el subcapítulo 2.8, que de forma
resumida son:
No se responde las llamadas de los empleados para reportar peticiones o incidentes.
No existe un registro sistematizado, ni se sabe quién tiene asignado cierto incidente
o petición.
No se puede obtener estadísticas del trabajo realizado, la cantidad de peticiones e
Incidentes que soluciona el área de TI.
No existen métricas que permitan medir el trabajo.
Los requerimientos e incidentes no son clasificados ni priorizados
No se tiene un registro de los problemas más comunes, tampoco se tienen
documentadas las soluciones a los problemas.
Estos problemas se intentan erradicar con el nuevo proceso con base a Cobit 5.
4.3. Desarrollo de actividades para cumplir con las prácticas del proceso “Gestionar
Peticiones e Incidentes de Servicio”
Para que un proceso de TI se ajuste al marco de referencia COBIT 5, éste debe cumplir con
ciertas prácticas de proceso (ver Capítulo III, sección 3.6), cada práctica contiene un conjunto
de actividades que indican cómo, por qué y qué implementar.
A continuación se desarrolla/diseña cada práctica del proceso “Gestionar Peticiones e
46
Incidentes de Servicio” para que se ajuste a lo que dice COBIT 5.
4.3.1. Práctica DSS02.01: Definir esquemas de clasificación de incidentes y
peticiones de servicio
En esta práctica se debe definir esquemas y modelos de clasificación de incidentes y
peticiones de servicio que la empresa utilizará.
Actividades:
A continuación se describen las actividades que establece Cobit 5 para esta práctica de
gestión:
1. Definir esquemas de clasificación y priorización de incidentes y peticiones de
servicio y criterios para el registro de problemas, para asegurar enfoques
consistentes en el tratamiento, informando a los usuarios y realizando análisis de
tendencias.
2. Definir modelos de incidentes para errores conocidos con el fin de facilitar su
resolución eficiente y efectiva.
3. Definir modelos de peticiones de servicio según el tipo de petición de servicio
correspondiente para facilitar la auto-ayuda y el servicio eficiente para las
peticiones estándar.
4. Definir reglas y procedimientos de escalamiento de incidentes, especialmente para
incidentes importantes e incidentes de seguridad.
5. Definir fuentes de conocimiento de incidentes y peticiones y su uso. (ISACA, 2012,
pág. 178)
Desarrollo:
Se define el siguiente esquema de clasificación de peticiones e incidentes (ver capítulo
II, sección 2,9):
Software (sistema comercial e inventarios, ofimática)
Hardware
Redes
Otros.
Se definen los siguientes esquemas de priorización de incidentes y peticiones:
47
Prioridad Baja: No tiene ninguna afectación a los sistemas de la empresa o al
correcto desempeño.
Prioridad Media: Afecta a un pequeño grupo de usuarios, no impide que desarrollen
sus actividades normalmente.
Prioridad Alta: Afecta a parte de la empresa, el negocio sigue funcionado aunque no
al 100%.
Prioridad Crítica: Considerado aquel incidente que detenga la marcha normal de la
empresa.
De acuerdo a la complejidad de la solución de los incidentes y a los conocimientos que
posee el personal de TI, se definen los siguientes niveles de escalamiento:
Nivel 1: Analista de Service Desk, Analista de soporte
Nivel 2: Administrador de aplicaciones
Nivel 3: Desarrolladores, proveedores, expertos externos.
Estos roles serán cubiertos por el personal de TI que actualmente labora en la empresa,
de acuerdo a sus conocimientos y experiencia; no se contratará personal adicional. Cabe
señalar que un empleado puede cubrir más de un perfil, y un perfil puede ser cubierto por
más de un empleado.
Reglas y procedimientos de escalamiento de incidentes:
1. Todo incidente será atendido y analizado directamente por el Nivel 1.
2. Si el Nivel 1 no puede resolver el incidente, deberá escalarlo a Nivel 2 con su
respectivo análisis o nota en la herramienta informática.
3. Si el incidente depende exclusivamente de la solución de proveedores, desarrollador
o expertos, Nivel 2 escalará a quien corresponda de Nivel 3 (ver figura 17).
48
Nivel 2
Nivel 1
Nivel 3
empleado
Reporta incidente
escala
escala
Figura 17: Definición de niveles de escalamiento. Fuente: Jefatura de Service Desk de la empresa Ortegacom Cía. Ltda. Elaborado por: Ximena Cueva, 2015
Para facilitar la auto-ayuda y el servicio eficiente de las peticiones, se documentará y
clasificará la solución de estas peticiones, y estará al alcance de todos los empleados a
través de la herramienta informática que Ortegacom Cía Ltda. implemente.
La fuente de conocimientos de incidentes y peticiones será la herramienta que
Ortegacom Cía. Ltda. implemente para su mesa de servicios tecnológicos (ver capítulo
V).
4.3.2. Práctica DSS02.02: Registrar, clasificar y priorizar peticiones e incidentes
Las peticiones e incidentes de servicio se deben identificar, registrar y clasificar,
adicionalmente se debe asignar una prioridad según la criticidad del negocio y los
acuerdos de servicio.
Actividades:
1. Registrar todos los incidentes y peticiones de servicio, registrando toda la
información relevante de forma que pueda ser manejada de manera efectiva y se
mantenga un registro histórico completo.
2. Para posibilitar análisis de tendencias, clasificar incidentes y peticiones de servicio
identificando tipo y categoría.
3. Priorizar peticiones de servicio e incidentes según la definición de impacto en el
negocio del ANS y la urgencia. (ISACA, 2012, pág. 179)
49
Desarrollo:
El empleado que identifique un incidente deberá registrarlo en la herramienta de
software que implemente la empresa (ver capítulo V), ingresando toda la información
relevante, anexando archivos en caso de ser necesario. En la figura 18 se muestra
un formulario básico propuesto para el registro de peticiones e incidentes de Servicio.
Figura 18: Formulario para el registro de peticiones e incidentes de servicio Fuente: Jefatura de Service Desk de la empresa Ortegacom Cía. Ltda., Hesk Elaborado por: Klemen Stirn, 2015
Cuando el empleado registre el incidente, debe clasificarlo de acuerdo a la definición
establecida en el desarrollo del ítem 4.3.1. El analista de service desk validará este
dato y de ser el caso puede cambiar su clasificación.
Cuando el empleado registre el incidente, debe priorizarlo de acuerdo a lo definido en
el desarrollo del ítem 4.3.1. El analista de service desk validará este dato y de ser el
caso puede cambiar su prioridad.
4.3.3. Práctica DSS02.03: Verificar, aprobar y resolver peticiones de servicio.
En esta práctica de Gestión se debe seleccionar los procedimientos adecuados para
peticiones y verificar que las peticiones de servicio cumplen los criterios de petición
definidos.
50
Actividades:
1. Verificar los derechos para realizar peticiones de servicio usando, cuando sea
posible, un flujo de proceso predefinido y cambios estándar.
2. Obtener aprobación financiera y funcional o firmada, si se requiere, o aprobaciones
predefinidas para cambios estándar acordados.
3. Completar las peticiones siguiendo el procedimiento de petición seleccionado,
utilizando, cuando sea posible, menús automáticos de autoayuda y modelos de
petición predefinidos para los elementos solicitados frecuentemente. (ISACA,
2012, pág. 179)
Desarrollo:
El analista de service desk verificará que la petición de servicio fue correctamente
reportada con la respectiva justificación y/o documentación, caso contrario será
rechazado.
Para el caso de peticiones de hardware, el empleado que realiza dicha petición
financiera requiere adjuntar un aval de su jefe inmediato, esta acción se puede
realizar a través de un mail, oficio o formulario firmado.
En caso de peticiones de servicio que requieran hardware, licenciamiento de software
u otro recurso financiero, el analista de service desk debe verificar las políticas de la
empresa y de acuerdo a ello aceptar o rechazar la petición. (Ver anexo 2)
4.3.4. Práctica DSS02.04: Investigar, diagnosticar y localizar incidentes.
Identificar y registrar síntomas de incidentes, determinar posibles causas y asignar
recursos a su resolución.
Actividades:
1. Identificar y describir síntomas relevantes para establecer las causas más
probables de los incidentes. Hacer referencia a los recursos de conocimiento
disponibles (incluyendo errores y problemas conocidos) para identificar posibles
resoluciones de incidentes (soluciones temporales y/o soluciones permanentes).
2. Registrar un nuevo problema si un problema relacionado o error conocido no existe
aún y si el incidente satisface los criterios acordados para registro de problemas.
3. Asignar incidentes a especialistas si se necesita de un conocimiento más profundo,
51
e implicar al nivel de gestión apropiado, cuando sea necesario. (ISACA, 2012, pág.
179)
Desarrollo:
El analista de service desk debe investigar que el incidente reportado efectivamente
exista y corresponda con la información proporcionada.
El analista de soporte verificará en el repositorio de conocimientos si el incidente ya
ha sido reportado anteriormente y cuál fue su solución.
El analista de soporte debe asignar el incidente o petición a la respectiva área y/o
persona que pueda solventarlo, según corresponda.
Figura 19: Formulario para la asignación de peticiones e incidentes de servicioFuente: Jefatura de Service Desk de la empresa Ortegacom Cía. Ltda., Hesk
En caso de incidentes altos o críticos se debe escalar directamente al Nivel 2.
4.3.5. Práctica DSS02.05: Resolver y recuperarse ante incidentes.
Para que el proceso se ajuste a esta práctica, se debe documentar, solicitar y probar las
soluciones identificadas o temporales y ejecutar acciones de recuperación para restaurar
el servicio TI afectado.
Actividades:
1. Seleccionar y aplicar las resoluciones de incidentes más apropiadas (soluciones
provisionales y/o soluciones permanentes).
2. Registrar si se usaron soluciones temporales para resolver los incidentes.
52
3. Ejecutar acciones de recuperación, si se requieren.
4. Documentar la resolución del incidente y evaluar si puede usarse como una
fuente de conocimiento en el futuro. (ISACA, 2012, pág. 179)
Desarrollo:
Aplicar una solución provisional, que permita continuar parcial o totalmente con las
actividades que realiza el empleado, cuando la solución al incidente se tome mucho
tiempo.
Buscar la solución más adecuada al incidente, en caso de ser necesario se puede
generar una Orden de Trabajo para el desarrollador y/o proveedores.
Una vez solventado el incidente, se debe recuperar el servicio o ejecutar acciones de
recuperación (recuperar información, respaldos, datos perdidos, etc).
Se debe documentar todo lo sucedo en un documento al que se llamará “Análisis de
Incidente (ADI)” (ver anexo 1), en el mismo debe constar todo el seguimiento
realizado, desde cuando se reportó el incidente hasta cuando fue solventado (cuando
aplique, incidentes de priorización alta y crítica).
4.3.6. Práctica DSS02.06: Cerrar peticiones de servicio e incidentes
Se debe verificar la resolución de incidentes y/o satisfactorio cumplimiento de peticiones.
Actividades:
1. Verificar con los usuarios afectados (si lo han acordado) que la petición de servicio
ha sido completada o el incidente ha sido resuelto de manera satisfactoria.
2. Cerrar peticiones de servicio e incidentes. (ISACA, 2012, pág. 180)
Desarrollo:
Una vez solventado el incidente, la persona que lo tiene asignado debe cerrarlo a
través de una opción que presente la herramienta informática.
Para el caso de equipos computacionales, el empleado solicitante deberá firmar el
acta de entrega recepción (ver anexo 2).
El empleado que reportó el incidente o petición debe verificar que efectivamente fue
resuelto, caso contrario deberá reabrirlo y/o crear un incidente nuevo.
53
4.3.7. Práctica DSS02.07: Seguir el estado y emitir de informes
En esta la última práctica del proceso, se debe hacer seguimiento, analizar e informar de
incidentes y tendencias de cumplimiento de peticiones, regularmente, para proporcionar
información para la mejora continua.
Actividades:
1. Supervisar y hacer seguimiento del escalado de incidentes y de resoluciones y de
los procedimientos de gestión de resoluciones para progresar hacia la resolución
o cumplimentación.
2. Identificar la información para las partes interesadas y sus necesidades de datos o
informes. Identificar la frecuencia y el medio para informarles.
3. Analizar incidentes y peticiones de servicio por categoría y tipo para establecer
tendencias e identificar patrones de asuntos recurrentes, infracciones de ANSs o
ineficiencias. Utilizar la información como entrada a la planificación de la mejora
continua.
4. Producir y distribuir informes en tiempo o proporcionar acceso controlado a datos
online. (ISACA, 2012, pág. 180)
Desarrollo:
Se deben realizar reuniones quincenales para analizar los incidentes que se han
reportado durante un lapso de tiempo.
Se debe generar reportes de las peticiones e incidentes de servicio por categoría,
prioridad; cumplimiento y satisfacción con el fin de identificar patrones recurrentes o
ineficiencia en la solución brindada.
Se deben obtener los respectivos indicadores establecidos para este proceso (ver
sección 4.7)
4.4. Diagrama propuesto del proceso
En la sección 4.3. se definió, diseñó y desarrolló un conjunto de actividades para cada Práctica
de Gestión, estos fueron los insumos que se necesitaba para ahora proponer el proceso
“Gestión de Petición de Incidentes de Servicios”, para la mesa servicios tecnológicos de la
empresa Ortegacom Cía.. Ltda. que se muestra en la figura 19.
54
Figura 20: Diagrama propuesto del proceso para gestión de peticiones e Incidentes. Fuente: Ximena Cueva, Mesa de servicios tecnológicos de la empresa Ortegacom Cia. Ltda. Elaborado por: Ximena Cueva, 2015
55
Figura 21: Diagrama propuesto del proceso para gestión de peticiones e Incidentes . Fuente: Ximena Cueva, Mesa de servicios tecnológicos de la empresa Ortegacom Cia. Ltda. Elaborado por: Ximena Cueva, 2015
56
4.5. Roles y sus responsabilidades que participan en el nuevo proceso
Conjuntamente con el Jefe de la Mesa de Servicios Tecnológicos se redefinieron los
siguientes roles y responsabilidades, basándose en los ya existentes, definidos por la
empresa. Estos roles son los que intervienen dentro del proceso propuesto:
a) Usuario
b) Dueño del proceso
c) Analista de service desk
d) Analista de soporte
4.5.1. Usuario
Es el empleado de Ortegacom Cía. Ltda. que reporte la petición o incidente de servicio,
es quien inicia el flujo del proceso.
Responsabilidades:
a) Solicita la apertura de una petición o incidente de servicio.
b) Reabre el ticket de la petición o incidente.
c) Valida la solución recibida.
d) Recibe la solución de la petición o incidente.
4.5.2. Dueño del proceso
Es la persona tiene el control sobre el proceso desde el principio hasta el final. Este rol
será asignado a un directivo; se apoya en un equipo o en otra persona que tenga un
conocimiento importante sobre el proceso. Es vital que el dueño del proceso esté
informado de las acciones y decisiones que afectan al proceso
Responsabilidades:
a) Definir el proceso, sus roles, responsabilidades, indicadores de desempeño y
asegurar su cumplimiento.
b) Mantener actualizada, aprobada y publicada toda la documentación relativa al
proceso.
57
c) Establecer los mecanismos de análisis y búsqueda de oportunidades de mejora
continua del proceso en base a los indicadores de desempeño.
d) Planificar y gestionar los recursos requeridos para la operación y mejora del proceso.
e) Capacitar a las áreas involucradas en el proceso.
f) Mantener actualizados los indicadores de gestión del proceso.
g) Gestionar para que cada paso del proceso cumplan con las especificaciones
definidas, facilitando el análisis de los incidentes y las peticiones.
4.5.3. Analista de Service Desk (Nivel 1)
El rol de Analista de Service Desk es el primero que interactúa con el usuario en la etapa
inicial del proceso y corresponde al Nivel 1 de Soporte.
Responsabilidades:
a) Aceptar llamadas /emails/tickets de los usuarios.
b) Registrar todas las peticiones e incidentes ya sean provenientes de alarmas, o de
notificaciones de usuarios.
c) Contribuir o actualizar conocimientos en el repositorio de conocimientos
d) Ejecutar las actividades necesarias para la resolución inmediata de las peticiones e
incidentes.
e) Resolver peticiones e incidentes o escalarlos a los Ingenieros de Soporte de Nivel 2
o Nivel 3 para su resolución.
f) Realizar las verificaciones correspondientes para aislar el incidente.
g) Establecer contacto con el usuario final para lograr la conformidad acerca de cierre
de la petición o incidente, si aplica.
h) Brindar adecuada información a las áreas del negocio.
i) Hacer sugerencias para mejorar el servicio.
j) Completar adecuadamente los registros de peticiones o incidente.
k) Transferir (escalar) los incidentes y requerimientos que no pueden ser tratados en su
nivel de gestión lo más ágilmente posible, registrando detalladamente toda la
información obtenida o analizada.
l) Registrar todas las acciones realizadas cronológicamente en la herramienta de
gestión de incidentes.
m) Registrar la solución identificada para resolver el incidente en la herramienta de
gestión de incidentes.
n) Notificar oportuna y claramente los incidentes.
58
4.5.4. Analista de Soporte (Nivel 2)
Es la segunda línea de soporte puede manejar la mayoría de peticiones e incidentes y
menos complicados, dejando a los grupos de soporte más especializados (nivel 3) que
se concentren en las peticiones e incidentes que requieren conocimientos más profundos.
Responsabilidades:
a) Ejecutar soluciones alternativas (workarounds).
b) Ejecutar las actividades necesarias para la inmediata resolución de las peticiones e
incidentes o para que el usuario final pueda continuar trabajando tan rápido como sea
posible luego de la interrupción del servicio.
c) Proveer adecuada información para contribuir a la calidad del soporte.
d) Hacer sugerencias para mejorar el proceso, una vez solucionado el incidente o
requerimiento.
e) Completar adecuadamente los registros del incidente o requerimiento.
f) Determinar la prioridad del incidente y establecer si la prioridad debe ser cambiada a
partir de información adicional.
g) Transferir (escalar) los incidentes y requerimientos que no pueden ser tratados en su
nivel de gestión lo más ágilmente posible, registrando detalladamente toda la
información posible acerca del incidente y de las acciones de revisión ejecutadas
(Workarounds).
h) Registrar todas las acciones realizadas cronológicamente en la herramienta de
gestión de incidentes.
i) Registrar la solución identificada para resolver el incidente en la herramienta de
gestión de incidentes.
j) Generar reportes, estadísticas e informes de incidentes y requerimientos.
k) Velar por el cumplimiento de los tiempos de notificación.
4.5.5. Equipo Técnico / Analista de Soporte, Administrador (Nivel 3)
Corresponde al Nivel 3 de soporte, puede incluir equipos de otras áreas (desarrollo de
software) u otras empresas (consultores, especialistas, proveedores). Este nivel tiene
experiencia en la resolución de incidentes y requerimientos y las habilidades técnicas
requeridas.
59
Responsabilidades:
a) Proveer soluciones alternativas (workarounds) al Analista de Soporte (Nivel 1) y
Analista de Service Desk (Nivel 2).
b) Generar Requerimientos Funcionales (RFs) cuando la solución al incidente requiere
desarrollo o configuración de Software.
c) Ejecutar las actividades necesarias para la inmediata resolución de los incidentes y
requerimientos o para que el usuario final pueda continuar recibiendo el servicio tan
rápido como sea posible luego de la interrupción del mismo.
d) Proveer adecuada información para contribuir a la calidad del soporte.
e) Hacer sugerencias para mejorar el proceso, una vez solucionado la petición o
incidente.
f) Completar adecuadamente los registros de petición o incidente de servicio.
g) Determinar la prioridad del incidente y establecer si la prioridad debe ser cambiada a
partir de información adicional.
h) Registrar todas las acciones realizadas cronológicamente en la herramienta de
gestión de incidentes.
i) Registrar la solución identificada para resolver el incidente en la herramienta de
gestión de incidentes.
4.5.6. Coordinador de Incidentes y Escalamiento
Mantiene la responsabilidad de la gestión todos los incidentes a su cargo, a través del
ciclo de vida. Es responsable por las actividades y recursos requeridos para escalar y
solucionar incidentes en los tiempos comprometidos. Este rol lo desempeñará el Jefe de
la Mesa de Servicios Tecnológicos.
Responsabilidades:
a) Dar seguimiento a los incidentes a su cargo.
b) Entender el impacto en el negocio de los incidentes.
c) Revisar la prioridad de los incidentes y determinar si es necesario ajustarla (debido a
la antigüedad o cambios en el impacto).
d) Coordinar la resolución de los incidentes con varios grupos de trabajo.
e) Coordinar la comunicación al usuario y las áreas afectadas sobre el avance de la
resolución del incidente.
60
f) Proveer los datos sobre la historia del escalamiento y publicación de apertura,
actualización, cancelación y cierre de los incidentes.
g) Manejar todos los requerimientos de información y publicación acerca del incidente
escalado.
h) Evaluar y administrar el proceso de escalamiento.
i) Asegurar los contactos para planificar y disponer el escalamiento.
j) Coordinar la creación de grupos de escalamiento.
k) Conducir la revisión del procedimiento de escalamiento, revisar su estado, evaluar al
finalizar el proceso luego de la aprobación del usuario
l) Verificar la transferencia del incidente a instancias de nivel superior de soporte
coordinando su atención.
m) Liderar el grupo de escalamiento y asegurar que los miembros del grupo tengan las
habilidades necesarias para resolver el incidente escalado.
n) Coordinar el escalamiento jerárquico identificando el nivel de influencia y liderazgo
requerido para solventar el incidente en la organización.
o) Ejecutar, documentar y hacer el seguimiento de las acciones determinadas en el
proceso de escalamiento.
p) Planificar y ser facilitador en las reuniones o conferencias de escalamiento.
q) Asegurar que la comunicación al usuario sobre el escalamiento es adecuada y
oportuna.
r) Utilizar la revisión posterior a la acción para registrar lo aprendido y gestionar los
incidentes de mejor manera cuando se repitan.
s) Asegurar el cumplimiento de los criterios de desempeño y los compromisos
contractuales conforme con lo establecido en los acuerdos de servicio buscando la
satisfacción de los usuarios.
t) Asegurar el registro de todas las acciones realizadas, durante la ocurrencia del
incidente y cronológicamente en la herramienta de gestión de incidentes.
u) Evaluar el tratamiento del incidente validando las acciones pendientes e identificando
posibles acciones de mejora que faciliten la atención y resolución de los incidentes.
4.5.7. Incident Manager
Es importante describir este rol debido a que si bien es cierto no se encuentra dentro del
flujo del proceso pero se encuentra encargado del control del mismo, es decir, Incident
Manager es el responsable por el éxito o fracaso del proceso y tiene la autoridad sobre
el mismo. Debe asegurar la efectiva coordinación de actividades para restaurar el
61
servicio. Maneja y coordina todas las actividades necesarias para registrar y resolver
todos los Incidentes y requerimientos.
Tiene una visión general de todo el proceso, sus funciones y documentación. Debe
asegurar que el proceso sea seguido dentro de la organización. Debe identificar cuando
y donde no se está siguiendo. Es quien identifica acciones correctivas y aprueba todos
los cambios al proceso. Este rol también será desempeñado por el Jefe de la Mesa de
Servicios Tecnológicos.
Responsabilidades:
a) Asegurar que se cumplan los lineamientos estratégicos del proceso de incidentes.
b) Revisar la efectividad y la eficiencia del proceso, identificando y realizando mejoras
al proceso alineadas a las necesidades del negocio.
c) Establecer y comunicar el proceso, los roles y las responsabilidades
d) Administrar el proceso de incidentes y asegurar que toda la organización conozca y
adhiera al proceso.
e) Evaluar el tratamiento de los incidentes y requerimientos identificando posibles
acciones de mejora que faciliten la atención y resolución, así como aquellas que
faciliten la resolución en la primera línea de soporte.
f) Definir los requerimientos de métricas, requerir y revisar la obtención de las esas
métricas.
g) Proveer información sobre la satisfacción de los usuarios.
h) Asegurar que el personal de soporte tiene las habilidades técnicas necesarias.
i) Planificar y administrar recursos y evaluar la carga de trabajo entre los niveles de
soporte.
j) Revisar los incidentes y requerimientos que no se hayan resuelto mediante el proceso
formal de incidentes.
k) Administrar el desempeño del grupo de trabajo, creando y ejecutando planes para
asegurar la mejora continua.
l) Conocer cómo recurrir a los siguientes niveles de soporte.
m) Monitorear los servicios entregados al usuario por el grupo que está trabajando con
el incidente.
n) Asegurar la integración del proceso de gestión de incidentes con los demás proceso
que posea la Gerencia de Tecnología de la Información.
o) Facilitar la disponibilidad y la funcionalidad de las herramientas usadas en la gestión
del proceso.
62
p) Desarrollar y mantener el proceso y los procedimientos de la Gestión de Incidentes.
q) Generar estadísticas de peticiones e incidentes.
4.6. Descripción paso a paso del proceso diseñado
A continuación se describen cada uno de los pasos del proceso, mostrados en la sección 4.4:
“Diagrama propuesto del proceso”:
1. Registrar petición o incidente de Servicio
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades: Recibir y atender la petición o incidente del usuario vía teléfono, correo
electrónico. El usuario también podrá registrar por si solo las peticiones e incidentes
de servicios a través de herramienta de gestión de incidentes.
Se registran los siguientes datos:
a) Número de Ticket
b) Usuario
c) Fecha y hora del pedido
d) Tipo de requerimiento
e) Servicio afectado
f) Método de notificación
g) Descripción de los síntomas
2. Clasificar y categorizar los incidentes
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Clasificar el problema presentado y registrar el mayor detalle posible.
b) Determinar si el problema identificado es masivo o puntual.
c) Categorizar el requerimiento considerando la clasificación en la herramienta de
gestión de incidentes (Nivel 1, Nivel 2 y Nivel 3).
d) Conforme a clasificación y categorías definidas, realizar el tratamiento del
requerimiento, pudiendo ser:
63
- Incidente: evento que no forma parte de la operación estándar de un servicio y
que causa o puede causar una interrupción o una reducción de la calidad de
servicio.
- Petición de servicio: solicitudes de cambios pequeños estándar.
- Pedido no soportado: si el servicio solicitado no está detallado en el catálogo
de servicios.
3. Comunicar pedido no soportado
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades: Notificar al usuario la imposibilidad de atención del pedido y cerrar el la
petición o incidente (ticket) en la herramienta para que el usuario gestione su
necesidad en la instancia adecuada.
4. Priorizar los incidentes
Responsable: Analista de Soporte (Nivel 2)
Actividades: Confirmar el grado de afectación del incidente detectado según la
prioridad, en la cual se toma en cuenta la criticidad del servicio y el impacto, con la
finalidad de asegurar su correcta gestión, comunicación, publicación y escalamiento.
5. Ejecutar el diagnóstico inicial
Responsable: Analista de Soporte (Nivel 2)
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Ejecutar los scripts de diagnóstico inicial (Checklist). Comparar con la Base de
Errores Conocidos
b) Validar la relación de los errores y su solución con el tipo de problema tecnológico
detallado en el incidente.
c) Identificar las alternativas de solución, el tiempo que tomaría dichas alternativas, y
el perfil tecnológico requerido para manejar la aplicación.
d) Determinar si se requiere escalamiento a Nivel 2.
e) Actualizar el estado del incidente en la herramienta.
6. Resolver el incidente y recuperar el servicio
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades:
64
a) Si el incidente es solucionable a Nivel 1, ejecutar workarounds o procesos
operativos que permitan la solución del incidente.
b) Verificar la solución a través de pruebas de restablecimiento de servicio.
7. Gestionar de Incidente Mayor
Responsable: Analista de Service Desk / Coordinador de incidentes y escalamiento
Actividades:
a) Coordinar la notificación a las áreas del negocio afectadas.
b) Gestionar el seguimiento del incidente.
c) Coordinar los recursos necesarios para la resolución de los incidentes (humanos y
tecnológicos).
d) Realizar los escalamientos jerárquicos y funcionales necesarios.
e) Consultar recurrentemente al personal de soporte sobre el estado del incidente
(causa, consecuencia, tiempo de solución, áreas involucradas).
f) Garantizar la actualización de la información en la herramienta de gestión de
Incidentes.
g) Coordinar las notificaciones de actualización de la incidencia.
8. Asignar y escalar el incidente
Responsable: Analista de Service Desk / Analista de Soporte (Nivel 3)
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Asignar (transferir) el ticket al personal apropiado (Nivel 2 o 3) con el análisis y
diagnóstico recogido por Nivel anterior. Además, añadir información de tareas
ejecutadas.
b) Si es necesario, realizar el escalamiento jerárquico que acuerdo al Procedimiento
de Escalamiento de Incidentes.
9. Investigar y diagnosticar el incidente
Responsable: Analista de Soporte de Incidentes Tercera Línea
Actividades:
a) Establecer exactamente qué es lo que está sucediendo y la percepción de usuario.
Entender el orden cronológico de eventos.
b) Confirmar el impacto real del incidente, incluyendo número y rango de usuarios
afectados.
c) Identificar los eventos que podrían haber disparado el incidente, por ejemplo:
cambios recientes, acciones de usuario. Buscar ocurrencias previas en: repositorio
65
de conocimientos, errores conocidos, incidentes y problemas o en las bases de
proveedores y fabricantes.
10. Resolver el incidente y recuperar el servicio (Nivel 2)
Responsable: Analista de Soporte de Incidentes Tercera Línea
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Implementar solución potencial y probarla.
b) Realizar pruebas mínimas de restablecimiento del servicio.
c) Registrar los pasos realizados en el ticket de atención abierto en la herramienta de
gestión de Incidentes.
11. Validar solución
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Contactar al usuario y solicitar su verificación del restablecimiento del servicio
afectado.
b) Solicitar al usuario que registre su aceptación en la aplicación, mediante una
comunicación que deberá contener información detallada de la solución que se ha
dado al incidente, causa real, afectación total, duración del incidente.
c) En caso de no tener confirmación del usuario en más de 24 horas, se asumirá que
la solución está aceptada.
d) Siempre que los resultados obtenidos en la validación sean positivos, la gestión
continúa en la actividad 13: “Cerrar incidente”, caso contrario, en la actividad 12
“Re-abrir el incidente”.
12. Re-abrir el Incidente
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Cuando el incidente no se considere solventado, registrar los motivos de rechazo
de solución.
b) Contactar al usuario solicitante para validar criterios:
Que el motivo de reapertura de ticket validando sea el mismo por el que se
originó el incidente.
66
En caso de que se trate de un pedido no resuelto por razones válidas que
describe el usuario, reasignar el ticket, coordinar nuevamente la atención
inmediata de pedido en el nivel de atención que ingresó la solución del
incidente.
c) Cuando la re-apertura se da por nuevo pedido con características similares al
pedido original pero que puede originarse por nueva causa, notificar a los usuarios
razones técnicas de la diferencia del nuevo inconveniente y coordinar el cierre del
incidente, y el ingreso de uno nuevo.
13. Cerrar el incidente
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Registrar el cierre del incidente en la herramienta de gestión de incidentes.
b) Cuando un pedido ha sido atendido y su solución aceptado por el usuario, la
aplicación cierra automáticamente el incidente (ticket).
c) Cuando el usuario no ha registrado la aceptación luego de 24 horas calendario
exceptuando fines de semana y feriados, la aplicación cierra automática el ticket.
14. Documentar el incidente
Responsable: Coordinador del Incidente
Actividades: Al cierre de la gestión, el Coordinador del Incidente deberá generar el
informe de Análisis de Incidente (ADI) mostrado en el ANEXO 1, que permita dar
seguimiento a futuros problemas. Debe registrar la información cronológica y técnica
del incidente en este documento y enviarlo al Incident Manager vía correo electrónico.
15. Analizar la causa del incidente
Responsable: Incident Manager
Actividades: Dependiendo de la priorización usada y el impacto presentado, el
Incident Manager deberá solicitar al personal que corresponda que analice la causa
raíz para prevenir que el incidente vuelva a ocurrir en el futuro.
16. Validar la necesidad de aprobación del requerimiento
Responsable: Analista de Service Desk
Sistema: Herramienta de Gestión de Incidentes
67
Actividades: Determinar si el servicio requiere aprobación y ticket cambio de
hardware de acuerdo a las políticas de aprobación de requerimientos; si es así debe
crear un requerimiento de hardware.
17. Crear el requerimiento de cambio de hardware
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades: Clasificar el ticket como de requerimiento de cambio de Hardware.
18. Gestionar la aprobación
Responsable: Analista de Service Desk / Incident Manager
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Realizar la validación financiera, de inventario y técnica de la información.
b) Si la petición es rechazado, se le comunicará al usuario mediante correo
electrónico.
19. Asignar y escalar el requerimiento
Responsable: Analista de Service Desk / Analista de Soporte (Nivel 2 o 3)
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Asignar (transferir) el ticket al nivel apropiado (Niveles 2 o 3) con el análisis y
diagnóstico recogido por Nivel anterior. Además añadir información de tareas
ejecutadas.
b) Si es necesario, realizar el escalamiento jerárquico que acuerdo al procedimiento
de escalamiento de Incidentes.
20. Resolver el ticket
Responsable: Analista de Soporte
Actividades: Implementar solución y probarla.
21. Validar la solución
Responsable: Analista de Service Desk
Actividades:
a) Contactar al usuario y solicitar su verificación de la solución de la petición.
b) Solicitar al usuario que registre su aceptación en la herramienta de gestión,
mediante una comunicación que deberá contener información detallada de la
68
solución que se ha dado la petición o con la firma del documento "Acta Entrega -
Recepción" (ver anexo 2).
c) En caso de que la confirmación exceda el tiempo de respuesta (24 horas) se
asumirá que la solución está aceptada.
d) Siempre que los resultados obtenidos en la validación sean positivos, la gestión
continúa en actividad 23: “Cerrar la peticion”, caso contrario la gestión se desarrolla
en 22: “Re-abrir la petición”.
22. Re-abrir la petición
Responsable: Analista de Service Desk
Sistema: Herramienta de gestión de incidentes
Actividades:
Cuando la petición no se considere solventada, se debe registrar los motivos de
rechazo de solución, para ello se contacta al usuario solicitante para validar los
siguientes criterios:
a) Motivo de re-apertura de ticket, validando que se trate de la misma razón por la
que se originó la petición.
b) En caso de que se trate de un pedido no resuelto por razones válidas que describe
el usuario, reasignar el ticket, coordinar nuevamente atención inmediata de pedido
en el nivel de atención que ingresó la solución del requerimiento.
23. Cerrar la petición
Responsable: Usuario
Sistema: Herramienta de gestión de incidentes
Actividades:
a) Registrar el cierre del requerimiento.
b) Cuando un pedido ha sido atendido y su solución aceptada por el usuario, la
aplicación cierra automáticamente el ciclo del requerimiento.
c) Cuando el usuario no ha registrado la aceptación luego de 24 horas calendario
exceptuando fines de semana y feriados, la aplicación cierra automática y
definitivamente el ciclo de atención.
4.7. Indicadores del proceso
Conjuntamente con el Jefe de la mesa de servicios tecnológicos, se establecieron los
siguientes indicadores:
69
1. Número de peticiones: Número de tickets puntuales gestionados por la mesa de
servicios tecnológicos.
2. Porcentaje de incidentes erróneamente escalados: (Número de tickets escalados
erróneamente cancelados / Total de tickets) * 100
3. Porcentaje de incidentes en estado abierto mayor a 15 días: (Número de tickets
que han permanecido abiertos por más de 15 días dentro de cada mes / Total de tickets
puntuales gestionados por la mesa de servicios tecnológicos por mes) * 100, donde se
considera solamente el mes en cual se abrieron.
4. Tiempo medio de recuperación del servicio: Sumatoria (fecha de cierre - fecha de
inicio) /Total de incidentes
Los indicadores serán medidos con frecuencia mensual.
Para poder incluir todos los indicadores antes mencionados y que la implementación del
proceso propuesto tenga un resultado óptimo se sugiere un organigrama nuevo con personal
que cumpla los roles propuestos en el proceso, de esta manera el nuevo organigrama
quedaría:
Gerencia de
TECNOLOGÍAS DE LA INFORMACIÓN
Mesa de Servicios
Tecnológicos
Analista de Service Desk
Administrador de
Aplicaciones
Proyectos y Desarrollo
Desarrollador
Figura 22: Propuesta deOrganigrama del Área de Sistemas de la empresa Ortegacom Cía. Ltda. Fuente: Departamento de RRHH de la empresa Ortegacom Cía. Ltda.
70
4.8. Evaluación de Herramientas para la Implementación del Proceso
Para la evaluación de las herramientas en las que se piensa implementar el proceso para
gestionar peticiones y servicios en la empresa Ortegacom Cia. Ltda se ha tomado en
cuenta las herramientas descritas anteriormente Osticket, RT (Request Tracker), OTRS
y Hesk en las cuales se evaluara diferentes parámetros que se describen a continuación
con el fin de satisfacer necesidades y requerimientos presentados por los empleados en
sus actividades diarias.
4.8.1. Definición de parámetros a evaluar
Conjuntamente con el Jefe de la mesa de servicios tecnológicos de Ortegacom Cía. Ltda., se
definieron los parámetros a evaluar de acuerdo a las necesidades que tiene la empresa y al
proceso diseñado y descrito en el capítulo IV. Para una evaluación más efectiva, los
parámetros se clasificaron en tres grupos:
a. Aspectos Técnicos
b. Funcionalidades
c. Aspectos Generales
4.8.1.1. Aspectos Técnicos
Tiene que ver con el hardware y software que posee o requiere la herramienta para su
correcto funcionamiento e implementación. Para la evaluación se tomará en cuenta las
herramientas que resulten más económicas para la empresa, sin que esto afecte a la
funcionalidad o rendimiento.
Dentro de este grupo se tienen los siguientes parámetros:
a. Sistema Operativo en el que se puede implementar:
La herramienta se adapta al Sistema Operativo con el que trabaja la empresa.
b. Facilidad de instalación:
Para dar un valor a este parámetro, se puede realizar las siguientes preguntas:
¿Qué tan fácil es la instalación de la herramienta?
¿Necesita personal técnicos especializado para su instalación?
71
¿Posee algún ayudante para la instalación?
¿Se encuentra dentro de alguna aplicación de instalación automática como
“Installatron” o “Softáculous”?.
c. Facilidad de configuración
Se evalúa qué tan fácil es la configuración de la herramienta para su funcionamiento.
Algunas herramientas se instalan con una configuración por defecto y no necesitan
configuración posterior, otras necesitan personal técnico especializado para la
actualización de la configuración.
d. Requerimientos de hardware
Permiten evaluar el costo del hardware que la herramienta requiere para su correcto
funcionamiento en caso de necesitarlo.
e. Requerimientos de Software
Se evalúa los prerrequisitos de Software que necesita la herramienta y si dicho
software es pagado o gratuito. Las herramientas que tengan más prerrequisitos se
considerarán en desventaja.
f. Facilidad de personalización
Una vez que se haya instalado la herramienta, se requiere realizar alguna
personalización de acuerdo a las necesidades de la empresa, por ejemplo: cambiar
logotipos, colores, fuentes, plantillas, estilos, formularios, cambiar ubicación de
objetos, inserción de imágenes, etc. Se evalúa qué tan fácil o intuitiva es realizar esta
personalización y si necesita personal técnico especializado.
4.8.1.2. Funcionalidades:
Se definen los parámetros de acuerdo a las funcionalidades visibles que debe tener la
herramienta, tanto para el usuario (empleado), como para el equipo que resuelve las
peticiones e incidentes de servicios. El desarrollo del capítulo IV, en el cual se realizó el
diseño y descripción del proceso sirvió mucho a la hora de definir los parámetros
(funcionalidades) a evaluar dentro de este grupo.
Para definir los siguientes parámetros conjuntamente con el Jefe de Mesa de Servicios
tecnológicos se ha evaluado, además de comprobar la presencia o no de la funcionalidad,
se tomó en cuenta qué tan fácil y qué tan amigable resulta su uso.
72
Como resultado se han definido los siguientes parámetros:
a. Ingreso de tickets
La herramienta debe permitir el ingreso de tickets (problemas o incidentes de
servicio).
b. Clasificación de tickets
Se evalúa que la herramienta permita clasificar un ticket, ya sea al momento de
ingresarlo o posteriormente por el Analista de Service Desk. La herramienta debe
permitir que se configuren categorías incluso subcategorías, esto permite
redireccionar el ticket de una mejor manera al personal que corresponda.
c. Priorización de tickets
Un ticket ingresado deberá ser priorizado de acuerdo a lo definido en el proceso, esto
permitirá agilizar la atención. Las prioridades deben ser configurables.
d. Consulta de estado de tickets
La herramienta debe permitir a empleados o analistas de service desk la consulta de
tickets. Dentro de la información que debe mostrar la herramienta debe constar al
menos: estado del ticket, persona asignada, rastreo (tracking), entre otros.
e. Adjuntar archivos a los tickets
Como parte del ingreso del ticket, se debe permitir que se adjunte uno o varios
archivos de cualquier tipo (documentos, hojas de cálculo, correos electrónicos,
formularios, imágenes, etc) como respaldo de la petición o incidente de servicio.
Adicionalmente el resolutor (Nivel 1, Nivel 2, Nivel 3) también podrá ingresar archivos
como parte del seguimiento o solución al ticket.
f. Personalización de formularios de ingreso
Generalmente los campos que se tiene para el ingreso de tickets son estáticos, sin
embargo por la naturaleza del negocio se puede requerir agregar o eliminar alguno/s
de ellos. La herramienta debe permitir que se personalicen, agreguen o eliminen los
campos que se tienen en el formulario de ingreso de tickets. Por ejemplo: de acuerdo
al tipo de petición o requerimiento se pueden presentar campos adicionales.
73
g. Asignación y reasignación de tickets
La herramienta debe asignar automáticamente los tickets a un resolutor (Nivel 1, Nivel
2, Nivel 3) de acuerdo a su clasificación y/o prioridad; adicionalmente los resolutores
pueden reasignar el ticket a otra persona dentro del mismo Nivel de servicio o entre
distintos niveles.
h. Posibilidad de agregar notas según el avance de la solución del ticket
Un ticket puede ser asignado a distintas personas y/o Niveles de Servicio antes de
ser solucionado definitivamente. La herramienta debe permitir que se agreguen notas
de avances a los tickets; de esta manera cuando un empleado consulte un ticket
puede saber qué actividades se realizaron o están realizando para solventarlo y
quiénes son los actores de dichas actividades.
i. Notificaciones/mensajes de alerta
La herramienta debe enviar notificaciones automáticas (generalmente correos
electrónicos) sobre acciones importantes que se realicen sobre un ticket. Por
ejemplo: Creación de un ticket, asignación de un ticket, solicitud de información,
vencimiento de acuerdo de nivel de servicio, resolución de ticket. El contenido de las
notificaciones debe ser configurado en plantillas dentro de la herramienta.
j. Reapertura de tickets
De acuerdo al proceso definido en el capítulo IV, el empleado que reportó la petición
o incidente de servicio tiene la posibilidad de aceptar o rechazar la solución. La
herramienta debe poseer una opción que permita reabrir un ticket cuando el empleado
rechazó la solución.
k. Generación de reportes
La herramienta debe permitir la generación de reportes personalizados relacionados
con los tickets, por ejemplo: cantidad de tickets resueltos, cantidad de ticket abiertos,
tickets creados por categoría o departamento, etc. Se dará una mayor puntuación
cuando la herramienta genere gráficos o permita exportar el reporte.
l. Manejo de ANS
Los Acuerdos de Nivel de Servicio (ANS) es un convenio entre la mesa de servicios
tecnológicos y el cliente (empleados) con el fin de fijar la calidad y tiempos de
resolución de peticiones e incidentes de servicios. Estos ANSs deberían ser
configurados en la herramienta y ser mostrados como reportes, o enviarse como
74
notificación. Ejemplo de ANS: el tiempo máximo de resolución de un ticket de
prioridad alta debe ser 24 horas. Ejemplo 1 de funcionalidad: Si un ticket incumple el
ANS acordado, se envía una notificación a la persona que tiene asignado dicho ticket.
Ejemplo 2 de funcionalidad: la herramienta muestra un reporte con el porcentaje de
tickets que incumplieron el ANS.
m. Base de conocimientos
Consiste en un repositorio dentro de la misma herramienta que permite la gestión de
conocimientos relacionados a los tickets, útiles para las personas que reportan las
peticiones e incidentes de servicios y para quienes resuelven los tickets. Este
repositorio generalmente almacena conocimientos con respecto a los problemas más
comunes que son reportados a la mesa de servicios tecnológicos.
n. Facilidad de uso
De manera general, se evalúa qué tan amigable, fácil e intuitivo es el manejo de la
herramienta luego de evaluar las funcionalidades de este grupo.
4.8.1.3. Aspecto Generales
Son aquellos parámetros que pueden o no ser visibles en la herramienta y que facilitan
directa o indirectamente su utilización. También hace referencia a costes directos o
indirectos para la puesta para la operación de la herramienta.
Dentro de este grupo se tienen los siguientes parámetros a evaluar:
a. Compatibilidad con diferentes navegadores web
La herramienta permite ser utilizada en los navegadores web más comunes (chrome,
safari, internet explorer, firefox, opera) en cualquier sistema operativo. No requiere
de algún plug-in adicional para su funcionamiento.
b. Autenticación / seguridad
La herramienta puede funcionar en protocolo seguro (https). Almacena las
contraseñas de forma encriptada en su base de datos. No posee vulnerabilidades
susceptibles a ser hackeadas; para evaluar este parámetro también se toma en
cuenta los comentarios o experiencias previas que tengan otros usuarios de la
herramienta. Se debe controlar el acceso a las distintas funcionalidades según los
perfiles o grupos de usuarios.
75
c. Integración con LDAP/AD
La herramienta permite la integración con Active Directory de Microsoft, esto facilita
el acceso y mantenimiento de los usuarios.
d. Tipos de usuarios / organización / jerarquía
La herramienta debe permitir la organización de usuarios de acuerdo a lo requerido
por la empresa; por ejemplo: Grupo de usuarios de Nivel 1, Grupo de usuarios de
Nivel 2, Grupo de usuarios de Nivel 3, Grupo Administradores, etc.
e. Tipo de licencia
Ortegacom Cía. Ltda. busca que el tipo de licencia que posee la herramienta permita
realizar modificaciones a su código fuente y no requiera costos para su
implementación y operación.
f. Recuperación de contraseña
La herramienta debe permitir que el usuario por si solo pueda recuperar la contraseña
en caso de olvido.
g. Costes en administración/mantenimiento
La empresa busca que para la administración y mantenimiento los costos sean
mínimos; este parámetro que viene relacionado directamente con la complejidad de
la herramienta.
h. Documentación, manuales en español
Existe suficiente documentación que facilite el aprendizaje a los usuarios para el
correcto uso, implementación y personalización de la herramienta. Se considera una
ventaja la presencia comunidades de usuarios en la web que ayudan a otros usuarios
a solventar las dudas o colaboran continuamente con el mejoramiento de la
herramienta.
4.8.2. Método de evaluación
Se definió una escala de 1 a 5 para puntuar a cada parámetro o aspecto a evaluar (ver tabla
4), en la que uno (1) indica que la herramienta no cumple con el parámetro, que es inseguro
o difícil de manejar y cinco (5) indica que la herramienta cumple a cabalidad o cubre totalmente
con el parámetro evaluado.
76
Tabla 4: Escala de puntuación para la evaluación
Nivel de Cobertura Puntuación
Sin Cobertura / No cumple 1
Baja Cobertura 2
Mediana Cobertura 3
Cobertura Casi Total 4
Cobertura Total / Cumple 5
Fuente: Ximena Cueva Elaborado por: Ximena Cueva, 2015
Por cada herramienta se realizará la sumatoria de los resultados de la evaluación y aquella
que obtenga el mayor puntaje será elegido a ser implementada.
4.8.3. Evaluación de las herramientas
Cada uno de los parámetros definidos en la sección 5.1 fueron evaluados en las herramientas
más utilizadas para la implementación de una mesa de servicios tecnológicos (OsTicket, RT,
OTRS y Hesk).
La evaluación de las herramientas se la realizó en los respectivos ambientes de demostración
ofrecidos a través de la página web del fabricante (ver tabla 5):
Tabla 5: Detalle de URLs demo de las herramientas evaluadas
Herramienta URL donde se encuentra el demo de la herramienta
OsTicket http://www.ostickethacks.com/demo/demo_info.php
RT (Request Tracker) http://rt.easter-eggs.org/demos/4.2/
OTRS https://www.otrs.com/try/
HESK http://www.hesk.com/demo.php
Fuente: OsTicket (2015), Best Practical, OTRS, Hesk ticket system (2015) Elaborado por: Ximena Cueva, 2015
No se realizaron pruebas de rendimiento ni de estrés, únicamente se evaluó los parámetros
definidos conjuntamente con el personal de la mesa de servicios tecnológicos de Ortegacom
Cía. Ltda.
77
A continuación se muestran los resultados de la evaluación por cada grupo de parámetros:
4.8.3.1. Aspectos Técnicos:
En la tabla 6 se muestra el resultado de la evaluación de las herramientas con respecto
a Aspectos Técnicos; OsTicket es la herramienta que más se destaca, pues cumple
totalmente con todos los parámetros evaluados, mientras que OTRS obtiene el puntaje
más bajo.
Tabla 6: Evaluación de las Herramientas de acuerdo a Aspectos Técnicos
Parámetro a evaluar OsTicket RT OTRS HESK
Facilidad de instalación 5 4 4 5
Facilidad de configuración 5 4 4 4
Requerimientos de hardware 5 5 4 5
Requerimientos de software 5 5 4 5
Facilidad de personalización 5 4 4 5
TOTAL 25 22 20 24
Fuente: Ximena Cueva Elaborado por: Ximena Cueva 2015
4.8.3.2. Funcionalidades:
Tabla 7: Evaluación de las Herramientas de acuerdo las funcionalidades
Parámetro a evaluar OsTicket RT OTRS HESK
Ingreso de tickets 5 5 5 5
Clasificación de tickets 5 5 4 4
Priorización de tickets 5 5 5 5
Consulta de estado de tickets 5 5 5 5
Adjuntar archivos a los tickets 5 5 5 5
Personalización de formularios de ingreso 5 4 3 3
Asignación y reasignación de tickets 5 5 5 5
Posibilidad de agregar notas según el
avance de la solución del ticket 5 5 4 4
Notificaciones/mensajes de alerta 3 5 4 4
78
Reapertura de tickets 1 2 3 3
Generación de reportes 3 3 5 4
Manejo de ANS 1 3 4 1
Base de conocimientos 5 5 5 5
Facilidad de uso 5 4 4 5
TOTAL 58 61 61 58
Fuente: Ximena Cueva Elaborado por: Ximena Cueva 2015
En la evaluación de acuerdo a las funcionalidades, RT y OTRS obtienen el puntaje más
alto, mientras que OsTicket y HESK obtienen el puntaje más bajo, con una diferencia de
3 puntos, como se puede observar en la tabla 7. Las evidencias que respaldan los
resultados de la esta evaluación pueden ser observadas en los Anexos 3, 4, 5 y 6.
4.8.3.3. Aspectos Generales:
En la evaluación de Aspectos Generales (ver tabla 8), se muestra que OsTicket toma
ventaja con respecto a las demás herramientas; por otro lado OTRS es el menos valorado
con una diferencia de 6 puntos con respecto al más alto.
Tabla 8: Evaluación de las Herramientas de acuerdo a Aspectos Generales
Parámetro a evaluar OsTicket RT OTRS HESK
Compatibilidad con diferentes navegadores
web 5 5 5 5
Autenticación / seguridad 5 5 5 5
Integración con LDAP/AD 4 2 1 1
Tipos de usuarios / organización / jerarquía 4 4 3 3
Tipo de licencia 5 5 3 5
Recuperación de contraseña 4 5 5 5
Costes en administración/mantenimiento 5 4 4 4
Documentación, manuales en español 4 4 4 3
TOTAL 36 34 30 31
Fuente: Ximena Cueva Elaborado por: Ximena Cueva 2015
79
4.8.4. Resultado final de la evaluación
Para decidir cuál es la herramienta que se debe implementar para la gestión de requerimientos
e incidentes de servicios en la mesa de sercicios tecnógicos de Ortegacom Cía. Ltda, todos
los parámetros tuvieron la misma escala de evaluación (de 1 a 5); por ende la herramienta
que obtenga el mayor puntaje de la sumatoria, será el elegido (Ver tabla 9).
Tabla 9: Resultado final de la evaluación a las Herramientas
Grupo de Parámetros evaluados OsTicket RT OTRS HESK
Aspectos Técnicos 25 22 20 24
Funcionalidades 58 61 61 58
Aspectos Generales 36 34 30 29
TOTAL 119 117 111 113
Fuente: Ximena Cueva Elaborado por: Ximena Cueva 2015
OsTicket es la herramienta que ha obtenido un mayor puntaje en la evaluación con respecto
a las demás herramientas, basados en Aspectos Técnicos, Funcionalidades y Aspectos
Generales; siendo esta la más idónea que debe ser implementada para el en la Mesa de
servicios tecnológicos de la empresa “Ortegacom Cía. Ltda.” para “Gestionar Peticiones e
Incidentes de Servicios”.
En la figura 23 se puede observar el resultado de la evaluación de funcionalidades de cada
una de las herramientas.
80
Figura 23: Resultado de la evaluación de las funcionalidades en las Herramientas para la gestión de requerimientos e incidentes de servicios para la empresa “Ortegacom CIA. LTDA” Fuente: Ximena Cueva Elaborado por: Ximena Cueva, 2015
En la figura 24 se puede observar el resultado final de la evaluación, apilando los tres grupos
de evaluación.
Figura 24: Resultado de la evaluación de las Herramientas para la gestión de requerimientos e incidentes de servicios para la empresa “Ortegacom CIA. LTDA” Fuente: Ximena Cueva Elaborado por: Ximena Cueva, 2015
0
123
4
56
Funcionalidades
Resultado de Evaluacion de Funcionalidades en cada Herramienta
OsTicket RT OTRS HESK
119117
111113
100
105
110
115
120
125
130
OsTicket RT OTRS HESK
Resultado de la evaluación de las Herramientas
CAPÍTULO V
PLAN DE IMPLANTACIÓN DEL PROCESO “GESTIONAR PETICIONES E INCIDENTES
DE SERVICIOS” PARA LA MESA DE SERVICIOS TECNOLÓGICOS DE LA EMPRESA
ORTEGACOM CIA. LTDA., BASADO EN COBIT 5
82
5.1. El ciclo de vida del Proceso
Actualmente la empresa tiene un equipo de Soporte Técnico, los cuales no se encuentran
regidos bajo ninguna norma para dar soporte, por lo cual se sugiere adoptar e implementar el
framework de COBIT 5 para la gestión y gobierno de la Tecnología de Información en su
Empresa, el próximo paso es la implementación del proceso, el mismo que viene derivado del
ciclo de vida (ver Figura 25), que contiene los siguientes elementos:
1. Planificar
2. Diseñar
3. Construir / adquirir / crear / implementar
4. Utilizar / operar
5. Evaluar / monitorizar
6. Actualizar / eliminar
Figura 25: Ciclo de vida de un proceso en Cobit 5 Fuente: (ISACA, 2012) Elaborado por: Ximena Cueva, 2015
5.1.1. Planificar
La planificación del presente proceso (ver tabla 10) se la ha realizado conjuntamente con
Planificar
Diseñar
Construir/ Implementar
Utilizar / Operar
Evaluar / Monitorizar
Actualizar / Eliminar
83
el personal de la mesa de servicios tecnológicos de la Empresa Ortegacom Cía. Ltda.
tomando en cuenta su ciclo de vida en un periodo de tiempo de un año, haciendo énfasis
en la etapa de Implementación.
A continuación se especifica el tiempo propuesto para llevar a cabo las actividades
correspondientes:
Tabla 10: Planificación de Actividades
Detalle Tiempo Planificado Tarea
Predecesora
1. Planificar 2 semanas
2. Diseñar 8 semanas 1
3. Construir/Implementar 4 semanas 2
4. Utilizar/Operar 10 meses 3
5. Evaluar / Monitorizar 10 meses 4
6. Actualizar/Eliminar 2 semanas 5
Fuente: Ximena Cueva, 2015 Elaborado por: Ximena Cueva, 2015
5.1.2. Diseñar
El diseño del proceso se lo realizó en el capítulo IV tomando en cuenta lo siguiente:
Definir partes interesadas.
Definición de Métricas del Proceso (ver Capítulo IV, sección 4.7).
Desarrollo de actividades para cumplir cada una de las Prácticas de Gestión, de
acuerdo a la realidad de la empresa.
5.1.3. Construir / Implementar
Esta etapa del proceso se la ha divido en dos partes:
Construir:
Aquí se elaboró el diagrama del proceso descrito en el capítulo IV, donde se detalla cada
uno de los pasos con sus respectivos actores.
84
Implementar:
Para la implementación del proceso se debe realizar lo siguiente:
Capacitar a los usuarios que pueden generar peticiones e incidentes de
servicio.
Escoger e Implementar la herramienta de software que se utilizará para la
gestión de peticiones e incidentes de servicio. En el capítulo V se estudió,
analizó y escogió las herramientas informáticas para la Mesa de Servicios
Tecnológicos de la empresa Ortegacom Cía. Ltda., cuyo resultado fue que
OsTicket es la herramienta que más se adapta a las necesidades y la que se
debe implementar. .
Capacitar al/los usuarios que administrarán la herramienta de Software
Implementada OsTicket.
Publicar/distribuir los documentos del proceso DSS02 para que estén al
alcance de todos los usuarios.
5.1.4. Utilizar / Operar
Hace referencia a la utilización del nuevo proceso a través de la herramienta ya
implementada, es decir, que las partes interesadas (actores internos y externos) lo usan
en las actividades y operaciones diarias.
Cualquier petición o incidente de servicio que se reporte debe seguir con respectivo flujo
del proceso (detallado en el capítulo IV).
5.1.5. Evaluar / Monitorizar
Una vez que el proceso está operativo, se esperan resultados positivos de su aplicación
y uso. Para gestionar el rendimiento del proceso, las siguientes preguntas tendrán que
ser contestadas y supervisadas –basadas en métricas- de forma regular:
• ¿Se atienden las necesidades de las partes interesadas?
• ¿Se alcanzan las metas de los catalizadores?
• ¿Se gestiona el ciclo de vida del catalizador?
• ¿Se aplican buenas prácticas?
85
El objetivo es que el presente proceso al finalizar el primer año tenga un Nivel de
capacidad 3.
5.1.6. Actualizar / Eliminar
Este es el último paso que cierra el ciclo de vida del proceso, en donde se debe tomar
una de las siguientes decisiones:
Actualizar: El proceso funciona, logra su objetivo, pero puede mejorarse. Se
retroalimenta del resultado de la Evaluación y Monitoreo para encontrar puntos
de mejora, corregir errores o incrementar pasos, actores, actividades según sea
necesario.
Eliminar: El proceso no es necesario y debe darse de baja; no aporta a los
objetivos que persigue TI y la empresa.
5.2. Resultados entregados a Ortegacom Cía. Ltda.
Como resultado el presente trabajo, se entrega a Ortegacom Cía. Ltda. los siguientes
resultados:
1. Análisis de la Situación actual del proceso “Gestionar Peticiones e Incidentes de
Servicios” de la Mesa de Servicios Tecnológicos. (Capítulo II).
2. Diseño del Proceso “Gestionar Peticiones e Incidentes de Servicios”. (Capítulo IV).
3. Selección de la Herramienta Open Source a Implementarse para la Gestión de
Peticiones e Incidentes de Servicios. (Capítulo IV, las evidencias de la evaluación se
encuentran en los anexos 3, 4, 5 y 6)
4. Cronograma de actividades a seguir por Ortegacom Cía. Ltda. (Ver tabla 10),
enfocadas en el ciclo de vida del proceso (capítulo V). Las primeras actividades: 1.
Planificar, 2. Diseñar y 3.1. Construir ya se encuentran desarrolladas; restarían la 3.2...
Implementar, 4: Utilizar, 5: Evaluar y 6: Actualizar.
De acuerdo al cronograma de actividades (ver figura 26), en el lapso de un año se completará
el Ciclo de vida el proceso, concluyendo con la evaluación y actualización o eliminación del
proceso. El escenario esperado es que el proceso vaya evolucionando y madurando luego
de cada periodo.
86
Figura 26: Cronograma de Actividades
Fuente: Ximena Cueva, 2016 Elaborado por: Ximena Cueva, 2016
ACTIVIDADES
1. Planificar
2. Diseñar
3. Construir
3.1. Construir
3.2. Implementar
4. Utilizar
5. Evaluar
6. Actualizar
Mes 7 Mes 8 Mes 9 Mes 10 Mes 11 Mes 12Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6
87
CONCLUSIONES
1. La mesa de servicios tecnológicos de la empresa Ortegacom Cía. Ltda. no posee un
proceso bien definido para la “gestión de peticiones e incidentes de servicios” y tiene
muchos problemas que impiden mejorar el servicio.
2. El marco de trabajo COBIT 5 permite a las organizaciones implementar un conjunto
de prácticas con el fin de mejorar la calidad, eficacia y eficiencia de TI; fue adoptado
por Ortegacom Cía. Ltda. para gestionar problemas o requerimientos, proceso que
poseía muchos problemas.
3. El proceso de COBIT 5: DSS02 “Gestionar Peticiones e Incidentes de Servicio” ha sido
tomado por Ortegacom Cía Ltda. para la gestión de los problemas o requerimientos
reportados por los empleados y que actualmente son resueltos por la mesa de
servicios tecnológicos.
4. Para el diseño del proceso “Gestionar Peticiones e Incidentes de Servicio” se debió
analizar el proceso y las necesidades que tenía la Mesa de servicios tecnológicos,
luego examinar lo que indica el proceso DSS02 del Marco de Referencia COBIT 5.
5. Se ha seleccionado la herramienta Open Source, OsTicket, la cual al ser evaluada
bajo los parámetros funcionales, técnicos y generales alcanzó un mayor puntaje,
destacándose como una herramienta de fácil uso y no requiere mayor estudio previo
su utilización, aspecto que beneficia al empleado de la empresa para adaptarse de
mejor manera al nuevo proceso.
6. El Plan de Implantación del Proceso DSS02 basado en Cobit 5 ”Gestionar Peticiones
e Incidentes de Servicios” automatizará el sistema para resolver conflictos en las
actividades de la empresa Ortegacom Cia. Ltda optimizando el trabajo de la mesa de
servicios tecnológicos.
7. La capacitación y participación constante del personal del TI así como el monitoreo de
la herramienta seleccionada por parte del mismo resulta una parte esencial para el
éxito del proceso; pues permite encontrar los problemas y establecer puntos de
mejora.
88
RECOMENDACIONES
Es importante conocer la situación actual de la empresa Ortegacom Cia. Ltda. y el
propósito por el cual se necesita implementar el proceso DSS02 basado en el Marco de
Referencia Cobit 5 esto permitirá encontrar las debilidades y fortalezas, útiles en el diseño.
Si se selecciona la herramienta de código abierto recomendada en este trabajo es
necesario capacitar al personal que va a estar en continuo contacto con la herramienta,
de esta manera se aprovechara todo el diseño del proceso creado específicamente para
las necesidades encontradas dentro de la empresa Ortegacom. Cia Ltda.
Utilizar la herramienta de código abierto recomendada (OS Ticket) para implementarla
dentro de la Empresa Ortegacom. Cia. Ltda. para favorecer el rendimiento de la empresa
y la eficacia de los servicios y nivel de rendimiento.
Continuar con la monitorización del proceso DSS02 implementado para de esta manera
asegurar una óptima utilización de los recursos y actividades que diariamente realiza la
empresa Ortegacom Cia. Ltda.
Es recomendable medir constantemente el rendimiento de la herramienta y el uso que
represente dentro de la empresa, puesto que puede en un futuro requerir la
implementación de otros procesos para complementarse según las necesidades que
varíen en la empresa.
Actualizar periódicamente al personal mediante capacitaciones para poder llevar un
análisis y seguimiento del proceso implementado y en caso de requerirse incorporar otros
procesos que se complementen entre sí con el fin de conseguir los mejores resultados.
89
BIBLIOGRAFÍA
Arteaga León, M. D. J., & Ramírez Velastegui, M. R. (2013). Implementación de mesa de
servicios, gestión de incidentes y gestión de cambios, caso de aplicación DIRECTV
(Doctoral dissertation, Quito: EPN, 2013).
Bautista Bastidas, J. E., & Espinoza Torres, G. M. (2015). Diseño e implementación de
una guía para evaluar los Sistemas Informáticos que se ejecutan en el área de Estadística
del Hospital Provincial General “Julius Doepfner” – Zamora. Zamora, Ecuador: UTPL.
Bermeo Castillo, J. Z. (2014). Análisis y estudio de la Universidad Politécnica Salesiana
en base a COBIT 5 e implementación de un prototipo para el área administrativa de las
TI.
Bestpractical.com. (2016). RT: Request Tracker - Best Practical. Recuperado: Octubre
2015, https://www.bestpractical.com/rt/
Coronel Castro, K.M. (2012), Auditoría Informática orientada a los procesos críticos de
crédito generados en la Cooperativa de Ahorro Y Crédito “Fortuna” aplicando el marco de
trabajo COBIT. Loja, Ecuador. UTPL.
Díaz, C., & Roberto, D. (2014). Implementación de un sistema para administración de
mesa de servicio e incidentes basado en ITIL V3. 0 para la empresa Seguros Oriente sa
utilizando el SOFTWARE OPEN SOURCE OTRS(Doctoral dissertation, Universidad
Internacional SEK).
Dulanto Ramírez, R. M., & Palomino Vidal, C. E. (2014). Propuesta de Implementación
de Gestión de Servicios de TI en una Empresa Farinacea.
Hesk ticket system, Recuperado de: http://hesk.com/
ISACA (2012), COBIT 5, Procesos Catalizadores, Estados Unidos: Editorial ISACA.
ISACA (2012), COBIT 5, Un Marco de Negocio para el Gobierno y la Gestión de las TI de
la Empresa, Estados Unidos: Editorial ISACA.
90
OsTicket (2015). Recuperado de: http://osticket.com/
OTRS: Open Ticket Request System (2015), Recuperado de:
https://www.otrs.com/company/about-us/?lang=es.
Quality and Technology, (2015) Recuperado de:
http://www.calidadytecnologia.com/2014/11/herramientas-ticketing-open-source.html
Salazar Espinoza, K. S. (2015). Guía para la implementación de Seguridad de la
Información en aplicaciones web de pequeñas empresas, tomando como referencia
“COBIT 5 para la seguridad de la información”. Loja, Ecuador. UTPL.
Sevilla, D. L., Mauricio, G., Allqui, C., & Elizabeth, V. (2015). Estudio de operación de los
servicios de tecnología de la Información mediante el estándar ITIL con el aplicativo
“Software para la Gestión de Incidentes de Tecnologías de la Información” en el
Departamento de Sistemas del Gobierno Autónomo Descentralizado Municipal del
Cantón Santiago de Quero.
Torres Díaz, P. D (2014). Automatización del proceso de Gestión de normatividad
universitaria y análisis del uso e importancia de prácticas de Gestión del Conocimiento
(GC) en dicho proceso. Loja, Ecuador. UTPL.
91
ANEXO 1
Formato de Documento de “Análisis de Incidente” (ADI)
ANÁLISIS DE INCIDENTE
[Título del Incidente Reportado]
Fecha de elaboración: [aaaa/mm/dd]
Modificaciones al Documento
FECHA MODIFICACIÓN REALIZADA POR:
[aaaa/mm/dd] Creación del documento [Nombres y Apellidos]
92
1. Aplicación afectada
2. Afectación al Negocio
3. Causas del ingreso del Incidente
ANTECEDENTES:
CAUSA RAÍZ:
SOLUCIÓN:
4. Oportunidades de mejora
1. 2. 3.
5. Anexos
93
ANEXO 2
ACTA DE ENTREGA RECEPCIÓN DE EQUIPOS COMPUTACIONALES
Hoy, ____ del mes de ____________ de ________ en las oficinas de la Ortegacom Cía. Ltda., mediante el presente documento se realiza la entrega formal de los equipos computacionales que se indican el punto 2, para el desempeño de las actividades laborales del FUNCIONARIO, quién declara recepción de los mismos en buen estado y se compromete a cuidarlos y hacer uso de ellos para los fines pertinentes. 1.- FUNCIONARIO RESPONSABLE
Nombres, Apellidos
Número de Cédula
Cargo
2.- EQUIPOS COMPUTACIONALES ASIGNADOS
MODELO DEL EQUIPO
NUMERO DE SERIE
NUMERO DE INVENTARIO
Descripción Marca Referencia Características Serial
Procesador
Disco Duro
Memoria RAM
Teclado
Monitor
Unidad Óptica
S.O.
WIFI
Web Cam
Accesorios:
Funda
Maletín
Mouse
Adaptador
Candado
Otro:………..
94
3.- PRUEBAS DE FUNCIONALIDAD
Descripción Calificación Descripción Calificación
4.- TIEMPO ESTIMADO DE USO Se determina que el FUNCIONARIO RESPONSABLE poseerá los equipos computaciones por el lapso de _______ meses, por lo que la fecha estimada de DEVOLUCIÓN es ____________________. 4.- ENTREGA
FECHA ENTREGA:
Entregado por: Recibido por:
Jefe de Mesa de Servicios Tecnológicos
Nombre y Cargo
5.- DEVOLUCIÓN
FECHA DEVOLUCIÓN:
Entregado por: Recibido por:
Nombre y Cargo Jefe de Mesa de Servicios Tecnológicos
95
ANEXO 3
EVALUACIÓN DE LAS FUNCIONALIDADES DE OSTICKET
Parámetro: Ingreso de Ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Cumple con todos los requisitos para la creación de un nuevo ticket.
96
Parámetro: Clasificación de tickets
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Herramienta presenta selección para clasificar tickets pero se debe crear
primero la categoría donde se desea clasificar y asignar el ticket a la misma.
97
Parámetro: Priorización de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Se puede Clasificar ticket con prioridad critico, alto y baja.
98
Parámetro: Consulta de Estado de Tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite consultar el estado del proceso del ticket.
99
Parámetro: Adjuntar Archivos a los tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite al usuario adjuntar archivos de cualquier formato para una mejor
explicación del problema.
100
Parámetro: Personalización de Formularios de Ingreso
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Permite al usuario modificar los parámetros de tickets en general no se puede
modificar o personalizar para un solo ticket.
101
Parámetro: Asignación y reasignación de tickets
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Permite asignar el caso del incidente a una persona una sola vez antes o
después de creado el ticket.
102
Parámetro: Posibilidad de agregar notas según el avance de la solución del ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite agregar nota en el transcurso del proceso del ticket.
103
Parámetro: Notificaciones/Mensajes de Alerta
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Notificación al administrador de la herramienta cuando un ticket es asignado a
la persona, cuando alguien agrega una nota a un ticket pero no permite crear alertas durante
el proceso del ticket.
104
Parámetro: Reapertura de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite reabrir un ticket resuelto y seguir nuevamente con el proceso.
105
Parámetro: Generación de Reportes
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite crear reportes personalizado si desea recibir los reportes se puede
seleccionar el intervalo de fechas y el tipo de informe que se desea recibir.
106
Parámetro: Manejo de ANS (Acuerdo de Nivel de Servicios)
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: No permite Acuerdo de Nivel de Servicios para tickets abiertos ni cerrados.
107
Parámetro: Base de conocimientos
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Permite llevar un registro de los tickets y el proceso que llevo resolverlos,
también permite que estos tickets se puedan publicar o mantenerlos como privado pero para
archivar o publicar se lo debe hacer manualmente, es decir la herramienta no guarda
automáticamente en su Base de conocimiento.
108
Parámetro: Facilidad de Uso
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Fácil de usar, presenta varios menús y una interfaz gráfica amigable para mejor
entendimiento de la persona que maneja la herramienta, tiene la opción de ayuda para
información acerca del manejo de la herramienta.
109
ANEXO 4
EVALUACIÓN DE LAS FUNCIONALIDADES DE RT (REQUEST TRACKER)
Parámetro: Ingreso de Ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Cumple con campos de información necesarios para el ingreso.
110
Parámetro: Clasificación de Ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Cumple con campos de información necesarios para la categorización del
problema o incidente suscitado.
111
Parámetro: Priorización de Tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Se jerarquiza según la prioridad del incidente o problema ingresado.
112
Parámetro: Adjuntar Archivos
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite al usuario adjuntar archivos de cualquier formato para una mejor
explicación del problema o ticket.
113
Parámetro: Personalización de Formularios de Ingreso
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Permite al usuario modificar parámetros del ticket creado.
114
Parámetro: Asignación y reasignación de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite asignar o reasignar a una o varias personas encargadas del ticket o
del caso.
115
Parámetro: Posibilidad de agregar notas según el avance de la solución del ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite agregar notas o comentarios en el caso mientras se encuentre abierto.
116
Parámetro: Notificaciones/Mensajes de Alerta
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite crear alarmas para seguir el avance y proceso del ticket.
117
Parámetro: Reapertura de tickets
Evidencia: Captura de Pantalla
Calificación: 2
Justificación: No cumple con múltiples opciones para reabrir el mismo ticket otra vez. Se
tiene que crear ticket nuevo con otro número de caso
118
Parámetro: Generación de Reportes
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Permite crear reportes pero no son específicos y no brindan la información del
proceso con exactitud, se brinda información general del ticket.
119
Parámetro: Manejo de ANS (Acuerdo de Nivel de Servicios)
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: No permite Acuerdo de Nivel de Servicios para tickets generados ni cerrados
120
Parámetro: Base de conocimientos
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite llevar un registro de los tickets y categorizarlos para usarlos como guía
en un incidente futuro o como prevención.
121
Parámetro: Facilidad de Uso
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: No es tan fácil de usar, presenta menús desplegables para mejor
entendimiento pero la mayoría de las instrucciones, comandos y procedimientos se realizan
en inglés y requiere que la persona que maneje la herramienta tenga conocimientos de este.
122
ANEXO 5
EVALUACIÓN DE LAS FUNCIONALIDADES DE OTRS
Parámetro: Ingreso de Ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Cumple con todos los requisitos para la creación de un nuevo ticket.
123
Parámetro: Clasificación de tickets
Evidencia: Captura de Pantalla
Calificación: 1
Justificación: Herramienta no presenta selección para clasificar tickets
124
Parámetro: Priorización de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Se puede Clasificar ticket con prioridad muy baja, baja, normal, alta y muy alta.
125
Parámetro: Consulta de Estado de Tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite consultar el estado del proceso del ticket.
126
Parámetro: Adjuntar Archivos a los tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite al usuario adjuntar archivos de cualquier formato para una mejor
explicación del problema.
127
Parámetro: Personalización de Formularios de Ingreso
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite al usuario modificar los parámetros del ticket creado.
128
Parámetro: Asignación y reasignación de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite reasignar el caso del incidente a una o varias personas antes o
después de abierto el ticket.
129
Parámetro: Posibilidad de agregar notas según el avance de la solución del ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite agregar nota en el trascurso del proceso del ticket.
130
Parámetro: Notificaciones/Mensajes de Alerta
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Permite agregar recordatorio o notificación en un tiempo determinado pero no
permite alertas cuando el proceso del ticket avanza.
131
Parámetro: Reapertura de tickets
Evidencia: Captura de Pantalla
Calificación: 2
Justificación: No permite reabrir el caso, sin embargo permite ponerlo como pendiente con
un mensaje de alerta.
132
Parámetro: Generación de Reportes
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Permite crear reportes pero generales mediante estadisticas, no presenta
informes detallados de cada caso.
133
Parámetro: Manejo de ANS (Acuerdo de Nivel de Servicios)
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: No permite Acuerdo de Nivel de Servicios para tickets abiertos ni cerrados.
134
Parámetro: Base de conocimientos
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Guarda un registro de los tickets mostrando el estado en el que se encuentra
actualmente, aunque no muestra el proceso que llevo resolverlo.
135
Parámetro: Facilidad de Uso
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Muy fácil de usar, presenta varios menús desplegables para mejor
entendimiento y tiene la selección de algunos idiomas para mejor comprensión además que
tiene la opción de ayuda para información acerca del manejo de la herramienta.
136
ANEXO 6
EVALUACIÓN DE LAS FUNCIONALIDADES DE HESK
Parámetro: Ingreso de Ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Cumple con todos los requisitos para la creación de un nuevo ticket.
137
Parámetro: Clasificación de tickets
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Herramienta presenta selección para clasificar tickets pero se debe crear
primero la categoría donde se desea clasificar y asignar el ticket a la misma.
138
Parámetro: Priorización de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Se puede Clasificar ticket con prioridad crítico, alto y baja.
139
Parámetro: Consulta de Estado de Tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite consultar el estado del proceso del ticket.
140
Parámetro: Adjuntar Archivos a los tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite al usuario adjuntar archivos de cualquier formato para una mejor
explicación del problema.
141
Parámetro: Personalización de Formularios de Ingreso
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Permite al usuario modificar los parámetros de tickets en general no se puede
modificar o personalizar para un solo ticket.
142
Parámetro: Asignación y reasignación de tickets
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: Permite asignar el caso del incidente a una persona una sola vez antes o
después de creado el ticket.
143
Parámetro: Posibilidad de agregar notas según el avance de la solución del ticket
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite agregar nota en el trascurso del proceso del ticket.
144
Parámetro: Notificaciones/Mensajes de Alerta
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Notificación al administrador de la herramienta cuando un ticket es asignado a
la persona, cuando alguien agrega una nota a un ticket pero no permite crear alertas durante
el proceso del ticket.
145
Parámetro: Reapertura de tickets
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite reabrir un ticket resuelto y seguir nuevamente con el proceso.
146
Parámetro: Generación de Reportes
Evidencia: Captura de Pantalla
Calificación: 5
Justificación: Permite crear reportes personalizados, si desea recibir los reportes se puede
seleccionar el intervalo de fechas y el tipo de informe que se desea recibir.
147
Parámetro: Manejo de ANS (Acuerdo de Nivel de Servicios)
Evidencia: Captura de Pantalla
Calificación: 3
Justificación: No permite Acuerdo de Nivel de Servicios para tickets abiertos ni cerrados.
148
Parámetro: Base de conocimientos
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Permite llevar un registro de los tickets y el proceso que llevo resolverlos,
también permite que estos tickets se puedan publicar o mantenerlos como privado pero para
archivar o publicar se lo debe hacer manualmente, es decir la herramienta no guarda
automáticamente en su Base de conocimiento.
149
Parámetro: Facilidad de Uso
Evidencia: Captura de Pantalla
Calificación: 4
Justificación: Fácil de usar, presenta varios menús y una interfaz gráfica amigable para mejor
entendimiento de la persona que maneja la herramienta, tiene la opción de ayuda para
información acerca del manejo de la herramienta.