Embed Size (px)
Citation preview
UNIVERSIDAD DISTRITAL
“FRANCISCO JOSE DE CALDAS”
TRABAJO FINAL
ESPECIALIZACION EN PROYECTOS INFORMATICOS
DISEÑO DEL PROCESO DE GESTIÓN DE INCIDENCIAS EN EL AREA
DE TECNOLOGIAS DE LA INFORMACIÓN: CASO EMPRESA
ALPHACREDIT
Autores
Eduardo Luis Daza Castilla - 20172199004
German Humberto López Ospina - 20172199009
Director
Victor Hugo Medina
Revisor
Jhon Jairo Londoño
Bogotá 2018
2
Nota de aceptación
_______________________________
_______________________________
_______________________________
_______________________________
_____________________________
Firma del Director del Proyecto
_____________________________
Firma del Revisor del Proyecto
Bogotá, 15 de mayo de 2018
3
Tabla de Contenido:
RESUMEN .................................................................................................................................................................... 7
ABSTRACT .................................................................................................................................................................. 8
INTRODUCCIÓN: ...................................................................................................................................................... 10
PARTE I: FUNDAMENTACIÓN DE LA INVESTIGACIÓN ................................................................................. 11
CAPITULO 1 DESCRIPCIÓN DE LA INVESTIGACIÓN ...................................................................................... 11
1.1 PLANTEAMIENTO DEL PROBLEMA ....................................................................................................... 11
1.2 PREGUNTA DE INVESTIGACION ............................................................................................................. 12
1.2.1 SISTEMATIZACIÓN DEL PROBLEMA ................................................................................................ 12
1.3 OBJETIVOS ................................................................................................................................................... 13
1.3.1 OBJETIVO GENERAL ............................................................................................................................. 13
1.3.2 OBJETIVOS ESPECÍFICOS ..................................................................................................................... 13
1.4 JUSTIFICACIÓN ........................................................................................................................................... 14
1.5 HIPÓTESIS .................................................................................................................................................... 15
1.6 ALCANCES Y LIMITACIONES .................................................................................................................. 16
1.6.1. LIMITACIONES ...................................................................................................................................... 16
1.6.2 ALCANCE ................................................................................................................................................ 16
1.7 METODOLOGÍA........................................................................................................................................... 17
1.8 ORGANIZACIÓN DEL TRABAJO .............................................................................................................. 18
PARTE II FUNDAMENTACIÓN DE LA INVESTIGACIÓN ................................................................................. 19
CAPITULO 2 MARCO TEORICO ............................................................................................................................ 19
2.1 HISTORIA DE ITIL .............................................................................................................................................. 19
2.2 OBJETIVO DE ITIL ............................................................................................................................................. 21
2.3 CICLOS DE VIDA ................................................................................................................................................ 22
2.4 COBIT ................................................................................................................................................................... 39
2.5 MARCO CONCEPTUAL ..................................................................................................................................... 49
2.6 ESTADO DEL ARTE .......................................................................................................................................... 53
CAPITULO 3 ANALISIS Y DIAGNOSTICO DE SITUACIÓN ACTUAL .............................................................. 57
3.1 ESTADO ACTUAL DEL AREA DE TECNOLOGIA ......................................................................................... 57
3.2 HERRAMIENTA DE APOYO PARA GESTIÓN DE INCIDENCIAS FRESHDESK ....................................... 60
3.3. ESTADISTICAS DESTACADAS DE LA GESTIÓN DE INCIDENCIAS ACTUAL ....................................... 62
3.4 DESCRIPCIÓN DEL PROCESO ACTUAL ....................................................................................................... 64
PARTE III DESARROLLO DE LA INVESTIGACIÓN ........................................................................................... 68
CAPITULO 4 ESTRATEGIAS Y DISEÑO A IMPLEMENTAR PARA LA GESTIÓN DE INCIDENCIAS ........ 68
4.1 ESTRATEGIA DE SERVICIO DEL MODELO .................................................................................................. 68
4.2 DISEÑO DE SERVICIO DEL PROCESO ........................................................................................................... 72
4.3 MODELO PROPUESTO ..................................................................................................................................... 79
4
4.3.1 Descripción del Proceso de atención de incidencias ................................................................................... 82
4.3.2.1 Identificación del Incidente ..................................................................................................................... 82
4.3.2.2 Registro, Clasificación y Soporte Inicial del Incidente ............................................................................ 83
4.3.2.3 Proceso de Investigación y Diagnóstico del Incidente ............................................................................. 85
4.3.2.4 Solución, Recuperación y Cierre del Incidente ........................................................................................ 85
PARTE III CIERRE DE LA INVESTIGACIÓN ....................................................................................................... 88
CAPÍTULO 7 RESULTADOS DE ENCUESTAS .................................................................................................... 88
CONCLUSIONES ....................................................................................................................................................... 94
VERIFICACIÓN, CONTRASTE Y EVALUACIÓN DE LOS OBJETIVOS .... ¡Error! Marcador no definido.
SÍNTESIS DEL MODELO PROPUESTO .......................................................... ¡Error! Marcador no definido.
APORTES ORIGINALES ................................................................................... ¡Error! Marcador no definido.
TRABAJOS O PUBLICACIONES DERIVADAS ............................................. ¡Error! Marcador no definido.
LÍNEAS DE INVESTIGACIÓN FUTURAS ...................................................... ¡Error! Marcador no definido.
TRABAJOS DE INVESTIGACIÓN FUTUROS ................................................ ¡Error! Marcador no definido.
BIBLIOGRAFÍA ......................................................................................................................................................... 95
5
Tabla de Figuras:
Figura 1 Evolucion de ITIL ......................................................................................................................................... 20
Figura 2 Objetivos de ITIL. ......................................................................................................................................... 21
Figura 3 Ciclo de vida de Itil ....................................................................................................................................... 22
Figura 4 ITIL Operacion del servicio .......................................................................................................................... 27
Figura 5 Proceso de Gestion de incidencias ................................................................................................................ 28
Figura 6 Evolucion de COBIT ..................................................................................................................................... 39
Figura 7 Principios COBIT 5 ....................................................................................................................................... 41
Figura 8 Procesos de Cobit 5.0 .................................................................................................................................... 45
Figura 9 Estructura de la Gerencia de IT & Soporte ................................................................................................... 58
Figura 10 Mapa de relaciones. ..................................................................................................................................... 59
Figura 11 Muestra de fechas tomada de Freshdesk ................................................................................................... 62
Figura 12 Listado de prioridades tomada Freshdes ..................................................................................................... 62
Figura 13 Listado de categorias tomada Freshdesk ..................................................................................................... 63
Figura 14 Informe respuesta de agentes versus respuestas de clientes tomada Freshdesk .......... ¡Error! Marcador no
definido.
Figura 15 Etapas de gestión de Incidencias actual ....................................................... ¡Error! Marcador no definido.
Figura 16 Estructura de la gerencia de Tecnologia Actual. ......................................................................................... 70
Figura 17 Clasificación de Pink Elephant para herramientas de Service Desk ........................................................... 71
Figura 18 Modelo propuesto de la investigación ......................................................................................................... 80
6
Índice de Tablas:
Tabla 1 Metricas ITIL ................................................................................................................................................. 37
Tabla 2 Plan de capacitación propuesto en la estrategia del modelo .......................................................................... 70
Tabla 3 Roles de la Gestión de Incidencias ................................................................................................................ 72
Tabla 4 Matriz RACI para la Gestión de Incidencias ................................................................................................. 73
Tabla 5 Categorias para la Gestión de Incidencias .................................................................................................... 76
Tabla 6 Niveles de escalamiento para la Gestión de Incidencias ................................................................................ 77
Tabla 7 Tiempos de respuesta inicial y solución definitiva ........................................................................................ 78
Tabla 8 Estados de Incidentes del Modelo de Gestión de Incidentes ......................................................................... 87
7
RESUMEN
Este proyecto plantea la creación del proceso de gestión de incidencias para el área de
Tecnologías de la Información (TI) de la empresa AlphaCredit partiendo del hecho de que no
existe un proceso de este tipo en la actualidad y que se hace necesario para disminuir los tiempos
de respuesta en la resolución de incidencias en las áreas consideradas críticas para la
organización, por el tipo de funciones que ejercen.
Como producto de esta investigación se obtiene un documento, basado en los estándares de ITIL
y COBIT, los cuales son un conjunto de conceptos y buenas prácticas usadas para la gestión de
servicios de tecnologías de la información, que facilita a el área de Tecnologías de la
información poder contar con un procedimiento para atender las solicitudes de sus clientes
internos y externos, con una categorización y con tiempos de respuestas adecuados que estén
alineados a los objetivos misionales de la organización, el cual fortalezca y genere un valor
agregado a la operación tecnológica en función de las necesidades de los demás áreas de la
organización.
PALABRAS CLAVE: Gestión de Incidencias, Entidad Financiera, Universidad, Gobierno de
TI, ITIL, COBIT, Arquitectura Empresarial.
8
ABSTRACT
This project proposes the creation of the incident management process for the information
technology (IT) area of the company AlphaCredit that is in the process of extinction and that has
not been modified. the response times in the resolution of incidents in the areas considered
critical for the organization, by the type of functions they perform.
The product of this research is based on a model based on the standards of ITIL and COBIT,
which are based on the standards of information technology, which help the management of
information technology services. information to have a procedure to meet the requests of internal
and external customers, with a categorization and with adequate response times that are aligned
with the mission objectives of the organization, which strengthens and generates added value to
the technological operation in function of the needs of the other sectors of the organization.
KEY WORDS: Incident Management, Financial Entity, University, IT Government, ITIL,
COBIT, Enterprise Architecture.
9
AGRADECIMIENTOS
Las autores expresan sus agradecimientos a:
En primer lugar gracias a Dios quien ha permitido culminar con éxito este proyecto.
A nuestro Director de Proyecto por brindarnos su apoyo durante la ejecución de este proyecto.
A nuestras familias que con su paciencia y amor han aportado sacrificio.
A la empresa AlphaCredit por suministrarnos la información necesaria para llevar a cabo nuestro
proyecto y poder mostrarlo como nuestro caso, con fines académicos.
10
INTRODUCCIÓN:
En la actualidad donde estamos viviendo la ―ERA DE LA INFORMATICA‖, en la cual la
información en todas sus dimensiones constituyen para las organización uno de los activos más
importantes, ya que en esta se ven representados una adecuada y acertada toma de decisiones, las
cuales son cruciales no solo para el sostenimiento en el mercado sino el futuro de la misma
creando una ventaja competitiva en el medio.
El poseer la información disponible en todas las áreas es uno de los aspectos más importantes de
cualquier tipo de organización, generando una confianza a sus clientes internos como externos y
todo esto conlleva a que los esfuerzos para tenerla siempre disponible se han venido
incrementando y los estudios y creación de procesos estandarizados se hacen necesarios.
Por todo lo anteriormente mencionado, en la empresa AlphaCredit y el área de tecnología de la
información se ve la necesidad de crear un proceso de gestión de incidencias donde se puedan
dar solución con calidad a todos las incidencias generadas en las diferentes área y que involucren
la información estandarizando con las mejores prácticas basadas en ITIL y COBIT, teniendo en
cuenta aspectos tan importantes como la categorización de los incidencias y generando un
tiempo de respuesta para su solución efectivo, contribuyendo a la confiabilidad de los sistemas
de información de la empresa para generar ventaja competitiva.
Como resultado de este proyecto se creó un documento donde se compila un proceso basado en
las mejores prácticas de tecnología que permite la gestión de incidencias en la empresa
AlphaCredit.
11
PARTE I: FUNDAMENTACIÓN DE LA INVESTIGACIÓN
CAPITULO 1 DESCRIPCIÓN DE LA INVESTIGACIÓN
A continuación, se exponen los aspectos que le dan sentido al estudio del problema de
investigación de la organización ALPHACREDIT.
1.1 PLANTEAMIENTO DEL PROBLEMA
El área de Tecnología juega un papel fundamental en el desarrollo de los objetivos
organizacionales, sin embargo, no ha sido siempre de esa forma. Con el pasar del tiempo,
diferentes investigaciones se han esmerado por dar una posición al recurso tecnológico como un
área estratégica que brinda componentes de valor a la razón de ser de las empresas. Por esto, se
han venido realizando distintos estudios basados en estándares que permiten dar un horizonte
sobre cómo deben ser tratadas las distintas incidencias que se generan en ellas, así poder empezar
a fundamentarse con un área de apoyo transversal para los diferentes procesos de la
organización.
Para lograr la adopción de este tipo de procesos en una compañía, se hace necesario primero
contar con un análisis de la situación actual, seguidamente realizar una revisión profunda de la
misión, la visión y las directrices del área donde se estará ejecutado el caso de estudio, y es por
eso que la elaboración de este tipo de proceso se ha convertido en una responsabilidad de todas
las áreas de tecnología en las organizaciones.
En la actualidad en la empresa AlphaCredit al interior de su área Tecnología de la Información
no cuenta con un proceso para la Gestión de Incidencias establecido y oficializado, lo cual no le
permite tener un panorama general sobre la oportunidad en los tiempos de respuestas, la
clasificación, priorización, la eficiencia y eficacia del área de Tecnología para la compañía. Así
mismo surge la necesidad de que exista un proceso como este, que esté alineado a los objetivos,
estrategias del negocio y que permita definir unos indicadores de esta gestión.
12
1.2 PREGUNTA DE INVESTIGACION
De esta manera, resultó la siguiente pregunta de investigación:
¿Cómo diseñar un proceso para la gestión de incidencias del área de tecnología de información
de la empresa AlphaCredit con el fin de consolidar la gestión técnica y operativa?
1.2.1 SISTEMATIZACIÓN DEL PROBLEMA
Para entender el estudio del problema de investigación, se propone una sistematización mediante
los siguientes cuestionamientos:
¿Cómo realizar un mapa del proceso de gestión de incidencias basado en previo levantamiento
de estado actual del área?
¿Porque establecer un proceso de gestión de incidencias que permita consolidar la administración
técnica y operativa del área de Tecnología de la empresa AlphaCredit?
¿De qué forma alinear las políticas y procedimientos del proceso de gestión de incidencias con
los estándares de buenas prácticas?
13
1.3 OBJETIVOS
Los objetivos por cumplir en este proyecto se presentan a continuación:
1.3.1 OBJETIVO GENERAL
Diseñar un modelo de gestión de incidencias para el área de Tecnologías de la Información de la
empresa AlphaCredit basado en estándares y en buenas prácticas de tecnologías que incluya
procesos, instrumentos de medición, documentación .
1.3.2 OBJETIVOS ESPECÍFICOS
Identificar el estado actual del proceso de gestión de incidencias en el área de TI.
Definir los instrumentos para la clasificación y evaluación de los tipos de incidencias.
Elaborar el mapa del proceso de gestión de incidencias para el área de TI.
Proponer un procedimiento alineado a los estándares de buenas prácticas de tecnología.
14
1.4 JUSTIFICACIÓN
La organización ALPHACREDIT en estos momentos está en una etapa de crecimiento, la cual
ha ampliado su visión comercial y con esto surge la necesidad de crear nuevas estrategias de
negocio, incorporando el desarrollo de Tecnologías de Información como un punto estratégico.
Dado este cambio en la arquitectura empresarial y la importancia dada a esta área se necesita dar
gestión al manejo de incidencias generados en la nueva estrategia de desarrollo institucional de la
entidad.
Esta gestión de incidencias se basa en:
Apoyar a las diferentes áreas en los distintos casos generados.
Dar gestión a las incidencias bajo los estándares de buenas prácticas.
Establecer las soluciones pertinentes alineadas a la visión de la organización.
Generar el proceso de gestión de incidencias alineados con la nueva estrategia
empresarial, basadas en las buenas prácticas y estándares como ITIL y COBIT
Respaldar a las áreas dando gestión y solución a las incidencias dentro de los tiempos
oportunos y soluciones pertinentes.
Cabe indicar que el alcance inicial del proyecto es el de mejorar la gestión de incidencias.
Adicionalmente, este documento de investigación entrega las pautas necesarias para mejorarlas y
que permite impactar de manera positiva la entidad.
Esta investigación se presenta con una justificación de tipo Práctico, dado que permite ayudar a
resolver un problema específico descubierto en una organización financiera, con una estrategia
basada en estándares de buenas prácticas de tecnologías de la información.
15
1.5 HIPÓTESIS
La gestión de incidencias es dentro de las arquitecturas empresariales un proceso muy
importante, que genera un incremento en la productividad y dando un valor agregado a la
competitividad empresarial.
Debido a esto se genera la siguiente hipótesis:
―Un proceso de gestión de incidencias basado en estándares de buenas prácticas ITIL y COBIT,
aplicándole categorización y tiempos de respuesta a cada uno de los casos facilita la recuperación
del nivel habitual de operación y disminuye el impacto negativo de fallas en la organización, de
tal manera que la calidad del servicio y la disponibilidad de la información se mantenga‖.
16
1.6 ALCANCES Y LIMITACIONES
1.6.1. LIMITACIONES
El presente proyecto se limitó a la creación de un diseño para la gestión de incidencias
específicamente tomando como caso de estudio la empresa ALPHACREDIT.
Estará limitado también por los responsables de parte de la empresa ALPHACREDIT el nivel de
acceso y apoyo al proyecto por parte de la empresa.
1.6.2 ALCANCE
El alcance del presente proyecto, es generar un modelo (procesos, instrumentos de medición,
documentación) para la gestión de incidencias en el área de Tecnologia de la empresa
ALPHACREDIT basado en ITIL Y COBIT.
17
1.7 METODOLOGÍA
A continuación se presenta los aspectos metodológicos empleados para la ejecución de este
proyecto.
1.7.1 TIPO DE INVESTIGACION
De acuerdo al contexto dado por el presente proyecto, este se abordó bajo un tipo de
investigación descriptiva la cual se adapta al escenario planteado y el desarrollo del problema. La
investigación descriptiva busca caracterizar una situación, elemento o fenómeno mirando sus
características más importantes, debilidades y problemas que contiene. Así mismo se utilizó la
investigación Aplicada, adaptando el uso del conocimiento sobre el contexto planteado en busca
de la solución del problema.
1.7.2 METODO DE INVESTIGACION
El desarrollo del presente proyecto se llevó a cabo tomando como métodos de obtención y
recolección, la información actualizada de la organización y la información de los diferentes
estándares y buenas prácticas sobre procesos para el manejo de incidencias, de las cuales nos
permite crear un diseño para la gestión de incidencias en el área de tecnología de la Información
en la empresa ALPHACREDIT Específicamente se realizó la investigación tomando como
fuentes los estándares ITIL Y COBIT.
18
1.8 ORGANIZACIÓN DEL TRABAJO
PARTE I:
CAPITULO 1
En este capítulo se presenta la estructura inicial de la investigación en la que se basó y desarrolló
el proyecto, donde podemos ver: la descripción de la investigación, el planteamiento del
problema, la pregunta de investigación, los objetivos, la Justificación, Hipótesis de la
investigación, los alcances y limitaciones, la metodología usada.
PARTE II:
CAPITULO 2
En esta sección del proyecto se definen los conceptos básicos que se tomarán como referencia
dar soporte al proyecto y al resultado del mismo, donde se plasma todos las definiciones,
conceptos y procesos que se tienen en cuenta para el desarrollo de la investigación.
CAPITULO 3
En este capítulo se plasmo la investigación hecha del caso de estudio propuesto en el proyecto
sobre la organización Alpha Capital S.A.S, donde se reúnio información relevante de la situación
actual del área de tecnología con la cual se hace un diagnóstico y análisis de esta.
PARTE III:
CAPITULO 4
En el capítulo de desarrollo de la investigación se procede a una vez hecho el diagnóstico y
conocido la situación actual se confronta contra los estándares investigados en el capítulo dos (2)
- Marco Teórico y se propone los nuevos lineamientos a seguir según el hallazgo obtenido.
19
PARTE II FUNDAMENTACIÓN DE LA INVESTIGACIÓN
CAPITULO 2 MARCO TEORICO
A continuación, se establece el marco referencial constituido por un marco teórico y conceptual,
donde se fundamentará el objetivo general del problema de investigación. Esta investigación esta
enfocada en teorías que están estructuradas con los estándares internacionales de buenas
prácticas ITIL y COBIT, que permiten dar una visión global de servicios de tecnología y su
definición en las organizaciones.
2.1 HISTORIA DE ITIL
ITIL (IT Infrastructure Library, biblioteca de infraestructura de TI) = Marco de referencia que
describe un conjunto de mejores prácticas y recomendaciones para la administración de servicios
de TI, con un enfoque de administración de procesos. (Magazcitum, 2010)
En 1987 la CCTA, un organismo del gobierno británico (ahora llamado la OGC) inició un
proyecto llamado GITIMM (Government IT Infrastructure Management Method), en el cual
involucraron a varias firmas de consultoría para investigar y documentar las mejores prácticas
para planear y operar la infraestructura de TI. Poco después, conforme el proyecto evolucionaba
de administración de infraestructura a administración de servicios de TI, se le cambió el nombre
a ITIL. (Magazcitum, 2010)
Como marco de referencia, ITIL se creó como un modelo para la administración de servicios de
TI e incluye información sobre las metas, las actividades generales, las entradas y las salidas de
los procesos que se pueden incorporar a las áreas de TI.
Desde sus inicios ITIL fue puesta a disposición del público en forma de un conjunto de libros, de
ahí su nombre, para que las organizaciones de todo el mundo pudieran adoptarlo. La primera
versión consistía de 10 libros principales que cubrían dos grandes temas: ―Soporte al servicio‖ y
―Entrega del servicio‖, amén de una serie de libros complementarios que cubrían temas tan
disímbolos como la administración de la continuidad o cuestiones relacionadas con cableado.
20
Posteriormente, en 2001 se hizo una reestructura importante que reunió los 19 libros principales
en sólo 2, mientras que otros temas siguieron en libros separados, dando así un total de 7 libros
para la segunda versión de ITIL:
Soporte al servicio (1).
Entrega del servicio (2).
Administración de la seguridad (3).
Administración de la infraestructura ICT (4).
Administración de las aplicaciones (5).
La perspectiva del negocio (6).
Planeación para implantar la administración de servicios (7).
Precisamente con la versión 2, a mediados de los años 90, ITIL fue reconocido como un
―estándar de facto‖ para la administración de servicios de TI, el cual, como siempre, tuvo que
seguir evolucionando para considerar las nuevas escuelas de pensamiento y alinearse mejor a
otros estándares, metodologías y mejores prácticas, lo que llevó en 2007 a la liberación de la
versión 3 de ITIL. (Magazcitum, 2010)
ITIL V3 sólo consta de cinco libros, que están estructurados en torno al ciclo de vida del
servicio:
Estrategia de servicios.
Diseño de servicios
Transición de servicios.
Operación de servicios.
Mejora continua de servicios.
Figura 1. Evolucion de ITIL (Molina, Marlon, 2011)
21
2.2 OBJETIVO DE ITIL
Figura 2 Objetivos de ITIL. (Magazcitum, 2010)
El objetivo que persigue ITIL es diseminar las mejores prácticas en la gestión de servicios de
Tecnologías de Información de forma sistemática y coherentemente. El planteo principal se basa
en la calidad de servicio y el desarrollo eficaz y eficiente de los procesos.
La idea subyacente es que, sin importar el rubro, la tecnología es cada vez más crítica para el
negocio de cualquier empresa. Esto quiere decir que si la tecnología no es administrada
eficientemente, el negocio no funciona, lo que se vuelve más cierto al ser más dependiente de la
infraestructura tecnológica.
En este sentido, los estándares ITIL exigen un replanteamiento del área tecnológica y la
definición de los elementos y procesos "críticos" dentro de la empresa. Esta metodología está
especialmente desarrollada para reducir los costos de provisión y soporte de los servicios de TI,
al mismo tiempo que se garantizan los requerimientos de la información en cuanto a seguridad
manteniendo e incrementando sus niveles de fiabilidad, consistencia y calidad.
Las normas ISO son demasiado rígidas para los negocios, ya que lo que se ajusta bien a una
empresa no lo hace a otra. En cambio, la incorporación de mejores prácticas (ITIL) es una forma
22
sencilla de mejorar y estandarizar la calidad de los procesos corporativos. Las guías generales de
mejores prácticas les sirven a todas las compañías. (Universidad de Chile, 2006)
2.3 CICLOS DE VIDA
El Ciclo de Vida de los Servicios TI, que divide en cinco fases, integrándolas como muestra la
Ilustración.
Figura 3Ciclo de vida de ITIL (Bit Computer Training, 2012)
En particular, cada división contiene sus procesos y términos que explican y definen la actividad
a desempeñar para lograr los objetivos. A continuación, se repasan las principales características
de todos ellos. (Universidad Rey Juan Carlos, 2012)
2.3.1 Estrategia del servicio
Es la primera fase del ciclo del servicio donde se comienza a entrever si la operativa tendrá
efecto y su rendimiento. Por tanto, las decisiones tomadas aquí se valorarán a largo plazo, así
como sus consecuencias. Es la etapa de las preguntas, sobre qué se quiere ofrecer, cómo
diferenciarse del resto o qué pautas de mejora escoger. Para tener éxito, las organizaciones deben
tener la habilidad de pensar y actuar estratégicamente.
23
La Estrategia del Servicio se compone de cuatro actividades principales:
Definición del Mercado: fijándose en el cliente, para definir el valor del servicio a
realizar.
Desarrollo de la Oferta: entendiendo el mercado del cliente y los resultados que
espera para definir los servicios, asegura una ejecución que generará valor al
cliente.
Desarrollo de Activos Estratégicos: se debe entender como activo, la
responsabilidad de los gestores del servicio, la habilidad para gestionar los propios
recursos estratégicos.
Preparación para la implementación: llevando a cabo una evaluación estratégica
sobre diferentes puntos, y establecer los objetivos claros para hacer que las
decisiones sean fáciles, consistentes y minimicen conflictos.
Como se comentan en la introducción de estas fases, todas ellas contienen diferentes procesos.
Los de ésta primera son:
Gestión Financiera: provee la información necesaria (presupuesto, contabilidad,
etc.) sobre el valor de los Servicios de TI, el valor de los activos y de lo que se
espera a futuro.
Gestión de la Demanda: para contar con los recursos necesarios, ya que una
demanda mal gestionada puede derivar en: exceso de capacidad generando costos
adicionales, o por el contrario, no cubrir las necesidades del servicio.
Gestión del Porfolio de Servicios: donde se articulan las necesidades del negocio y
la respuesta en forma de Servicio.
24
2.3.2 Diseño del servicio
Es la fase donde se diseña la estrategia previamente vista, y prepara o esboza todos los
requerimientos para entregar servicios de calidad, a precios acordes y con un impacto positivo en
el negocio. Para ello los objetivos de esta parte se enfocan en mantener un equilibrio entre la
funcionalidad requerida y los objetivos de rendimiento. En este apartado las actividades se
disparan, debido a la gran cantidad de peticiones de cambio en busca de una mayor calidad, por
esto hay que estructurar el enfoque orientado a los resultados, así se satisfarán los deseos y
necesidades del cliente. (Universidad Rey Juan Carlos, 2012)
Las cinco actividades que encontramos:
Diseño de una solución de servicio: alineando el diseño de un nuevo servicio a un precio
adecuado, definiciones de calidad, con la funcionalidad deseada y dentro del ámbito
correcto.
Diseño del portfolio de servicio: se describe en él la entrega de los servicios en términos
de valor para los clientes. Es el punto crítico de la gestión, sirve de apoyo para todos los
procesos.
El porfolio es la fuente de consulta principal para los requerimientos de los servicios, y
debe diseñarse al igual que se diseña un servicio. Es el sistema de información más
crítico para la gestión y también sirve como apoyo a los demás procesos.
Diseño de la arquitectura: desarrollo y mantenimiento de las políticas, estrategias,
arquitecturas, diseños, documentos, planes y procesos de TI; para después tratar su
implantación, instalación, mejora y mantenimiento.
Diseño de procesos: como se ha visto, son parte de los principios de ITIL. Aquí se
diseñarán sus inputs y outputs, y las actividades que los proveerán a su vez.
25
Diseño de los sistemas de medición y de las métricas: es muy importante realizar esta
tarea de forma regular. Ayudan a comprobar si se está siguiendo el camino correcto del
proceso y su desarrollo. Se pueden medir cuatro elementos: Progreso, Cumplimiento,
Efectividad y Eficiencia. (Universidad Rey Juan Carlos, 2012)
2.3.3 Transición del servicio
Para que esta fase se considere como exitosa, debe basarse en un correcto y efectivo
entendimiento y aplicación de la Gestión de Cambios. Es prioritario hacer un seguimiento muy
exhaustivo de cada etapa, confirmar el avance, revisar el diseño y que se cumplen los requisitos
acordados. Además, se debe trabajar estrechamente con la Operación del Servicio, dando soporte
y apoyo inicial a los servicios que se implanta en esta parte del servicio. (Universidad Rey Juan
Carlos, 2012)
Aquí aparecen la mayoría de las relaciones entre los procesos y las etapas de todo el ciclo de vida
del servicio TI, además de poder ver como los diseños se convierten en servicios preparados para
la productividad. Por estas particularidades, los procesos de esta fase se dividen en los que dan
apoyo al ciclo de vida de los servicios en general, y los de la transición del servicio propiamente
dicha. De los primeros tenemos:
Gestión de Cambios: siendo uno de los procesos más delicados de toda la gestión, ya que
un control deficiente del asunto, seguramente provocará incidentes con mayor frecuencia
e impacto. Para ayudar en esta tarea, se aconseja la utilización de herramientas y
metodologías.
Gestión de Activos y Configuración del Servicio: sobre la primera, se puede decir que
tiene como objetivo prioritario el apoyar a los demás procesos, Evaluación y mejora de
un servicio TI mediante ITIL gestionando los activos de todos ellos. Se lidera un
inventario de los activos y quién es responsable de su control desde el momento que
entran a formar parte del servicio, hasta su salida del mismo. En cuanto a la gestión de la
26
configuración, se fija para que los elementos de un servicio, sistema o aplicación de
configuración estén identificados, no sólo como están en el momento, sino el historial de
cambios sufridos. Además, debe asegurar que estas modificaciones se hagan siguiendo la
gestión de cambios correctamente.
Gestión del Conocimiento: el proceso encargado de que la información correcta esté en el
sitio adecuado o se entregue a la persona a cargo de ello. En cuanto a los procesos
propiamente dichos de la fase de transición del servicio, contamos con:
Planificación y apoyo de la transición: realiza el establecimiento y coordinación de los
recursos que son necesarios para todos los procesos de la transición. Así, se mejora
sustancialmente el manejo de un gran número de cambios. Al igual, realizando un buen
trabajo en el que se integren el cliente, el proveedor y los planes de proyectos para
cambios del negocio.
Gestión de Versiones y Despliegues: es la encargada de construir, probar y desplegar
tanto los CIs de software, como los de hardware en el entorno de producción. Requiere de
una cuidadosa planificación y coordinación con el resto de procesos. Un elemento útil
para mostrar los diferentes niveles de construcción, y posterior validación de la capacidad
de un servicio es el modelo en V.
Validación y Prueba del Servicio: asegurar la calidad del servicio entregado, y que por
supuesto, se ajusta al propósito y al uso esperado. Para ello se debe probar el
comportamiento de los servicios nuevos o de los cambios sobre los existentes. De esta
manera se pretende evitar los errores que puedan dañar el negocio. Es mucho más
económico destinar presupuesto en pruebas y verificaciones en las etapas previas, que en
correcciones cuando el servicio se encuentra en producción.
Evaluación: consiste en revisar y analizar el rendimiento de un cambio o nuevo servicio,
y la desviación de lo que se propone antes de que se efectúe. Además, debe proveer
informes para tomar decisiones sobre si llevarlo o no a cabo. (Universidad Rey Juan
Carlos, 2012)
27
2.3.4 Operación del servicio
Es el conjunto de servicios en producción, es decir, de las actividades ―del día a día‖.
Responsable de entregar el servicio al cliente y los diferentes usuarios, además de hacerlo
cumpliendo con los acuerdos de los niveles acordados. Si no existe una estructura que soporte y
apoye, todo lo que en las fases previas se diseña e implementa, no se entregaría el valor
suficiente. Por otro lado, es necesario desarrollar, controlar y gestionar continuamente la
operación, para que sea posible la mejora del servicio. Los objetivos de este punto se pueden
resumir en proporcionar y entregar servicios TI. (Universidad Rey Juan Carlos, 2012)
Figura 4 ITIL Operacion del servicio (Wikipedia, 2016)
28
La disciplina ITIL V3 "Operación del Servicio (Service Operation)" abarca los procesos
siguientes:
Gestión de Eventos:
Objetivo Procesal: Asegurar que los Elementos de Configuración (CI) y los servicios sean
monitoreados constantemente, así como descartar y categorizar Eventos antes de decidir qué
acciones son las adecuadas. (Wikipedia, 2016)
Gestión de Incidentes:
Las actividades y los objetivos del proceso de Gestión de Incidentes son fundamentalmente
idénticos en ITIL V 2 e ITIL V3 (Wikipedia, 2016).
La versión 3 de ITIL establece una diferencia entre "Incidentes" (interrupciones del servicio) y
"Solicitudes de Servicio" (consultas estándars de los usuarios, como por ejemplo sobre la
reposición de contraseñas, etc). De las Solicitudes de Servicio ya no se encarga la Gestión de
Incidentes sino el proceso "Cumplimiento de la Solicitud". En ITIL V3 se ha añadido un proceso
para tratar los casos urgentes, los llamados Incidentes Graves. También se ha añadido un interfaz
de procesos entre la Gestión de Eventos y la Gestión de Incidentes, de tal modo que los eventos
significativos desencadenan el dispositivo de incidentes. (Wikipedia, 2016).
ITIL define la gestión de incidentes como el proceso responsable de administrar el ciclo de vida
de todos los incidentes para asegurar que la operativa normal del servicio se restablezca lo más
rápidamente posible y que el impacto en las operaciones de negocio sea mínimo. (Genius it
training, 2018).
Figura 5 Proceso de Gestion de incidencias (Blog Elevenpaths, 2015)
29
El gestor de incidencias es el responsable de restablecer el servicio a su estado normal lo más
pronto posible, ante interrupciones o desviaciones, reduciendo al máximo el impacto en el
negocio. Los procesos implicados en esta gestión se muestran y quedan más claros en la
Ilustración 4. En este punto toman presencia los SLAs, ya que un servicio normal es considerado
al actuar de acuerdo a ellos, o lo más cerca posible mientras se restaura el servicio durante una
indisponibilidad. Si durante una afectación, se detecta un problema, hay que tener en cuenta que
este proceso no es encargado de resolverlo. En los SLAs también se recoge la forma de asignar la
prioridad de las incidencias, y viene a ser la combinación por un lado del impacto, que es el
grado de desviación sobre la operativa normal, y de la urgencia, la demora aceptable para el
usuario o el proceso. Para el trabajo en la resolución de las incidencias se realiza por equipos de
soporte, que se establecen en niveles. A este proceso se le denomina escalado, que puede ser:
Funcional: usado cuando hay una falta de experiencia o de conocimiento, y se requiere un
especialista de mayor nivel para resolver la incidencia.
Jerárquico: usado en cualquier momento durante el proceso de resolución, para tomar
decisiones importantes al considerar que la solución no será la esperada o el tiempo de
resolución. El objetivo es disminuir los porcentajes de resolución en los niveles altos del
escalado, y que se aumenten en los inferiores. Se logrará si el conocimiento vaya siendo
adquirido o esté disponible por los niveles más bajos. (Universidad Rey Juan Carlos,
2012)
Exiten tres conceptos básicos sobre la Gestión de Incidencias
Escala de tiempos
A partir del SLA se establecen los tiempos máximos en los que se deben responder y
resolver las incidencias.Debemos usar herramientas de gestión para el cálculo y la
asignación de estas escalas de tiempo, así como para utilizar alertas y escalados para
facilitar la respuesta/resolución de las incidencias dentro del tiempo máximo definido.
30
Modelos de incidencia
Los modelos de incidencia permiten optimizar el proceso de resolución. Existen
incidencias que no son nuevas, sino que ya se han producido anteriormente y que se
volverán a producir en el futuro. Muchas empresas encuentran útil la definición de
modelos de incidencia que se puedan aplicar a incidencias recurrentes del servicio.
Un modelo de incidencia debería incluir:
- Los pasos a seguir para la resolución de la incidencia.
- El orden cronológico de estos pasos y sus dependencias si las hubiera.
- Responsabilidades: quién debe hacer qué.
- Plazos para la realización de las actividades.
- Procedimientos de escalado: quién debería ser contactado y cuando.
Incidencias graves
Cada servicio debe definir cuáles son los criterios para que una incidencia se considere grave.
Las incidencias graves deben tener asociado su propio procedimiento de resolución y
escalado, y tener una escala de tiempos menor que el resto. La actividad de priorización, que
veremos más adelante, debe tener en cuenta estos criterios. (Servicetonic, 2017)
El proceso ITIL gestión de Incidentes abarca los siguientes subprocesos
Soporte a Gestión de Incidentes
Objetivo Procesal: Proveer y mantener las herramientas, los procesos, las destrezas y las
reglas para un manejo de Incidentes efectivo y eficiente.
Registro y Categorización de Incidentes
Objetivo Procesal: Registrar y asignar prioridades a los incidentes con la diligencia
adecuada, de manera que se faciliten soluciones efectivas e inmediatas.
31
Resolución de Incidentes por el Soporte de Primera Línea
Objetivo Procesal: Resolver un Incidente (interrupción del servicio) en el período
acordado. La meta es el restablecimiento temprano del servicio de TI, con alguna Solución
Temporal de ser necesaria. Una vez se constate que el Soporte de Primera Línea no puede
resolver el Incidente o cuando se exceda el periodo límite propuesto para dicho nivel, el
Incidente es transferido a un grupo adecuado en el Soporte de Segunda Línea.
Resolución de Incidentes por el Soporte de Segunda Línea
Objetivo Procesal: Resolver un Incidente (interrupción del servicio) en el período
acordado. La meta es el restablecimiento temprano del servicio de TI, con alguna solución
temporal de ser necesaria. En caso de que se requiera, podrán involucrarse grupos de soporte
especiales o proveedores externos (Soporte de Tercera Línea). Si no es posible corregir la
raíz del problema, se crea un Registro de Problema y se transfiere el caso a la Gestión de
Problemas.
Gestión de Incidentes Graves
Objetivo Procesal: Solucionar un Incidente Grave. Los Incidentes Graves causan
interrupciones considerables en las actividades de la empresa y deben resolverse con mayor
urgencia. Se aspira al restablecimiento temprano de los servicios, aunque haya que recurrir a
soluciones temporales. En caso de que se requiera, podrán involucrarse grupos de soporte
especiales o proveedores externos (Soporte de Tercera Línea). Si no se puede corregir la raíz
del problema, se crea un Registro de Problema respectivo y se remite a la Gestión de
Problemas.
Monitorización e Escalado de Incidentes
Objetivo Procesal: Monitorizar constantemente el estatus del procesamiento de Incidentes
pendientes, para que inmediatamente se tomen medidas que contrarresten efectos adversos
en caso de que peligren los niveles de servicio.
32
Cierre y Evaluación de Incidentes
Objetivo Procesal: Someter el Registro de Incidente al control de calidad final antes de
que se dé un cierre. La meta es asegurarse de que el incidente se haya resuelto y que toda la
información requerida para describir el ciclo de vida del incidente haya sido sometida con
suficiencia de detalles. Además, los hallazgos de la resolución se registrarán para referencia
futura.
Información Pro-Activa a Usuarios
Objetivo Procesal: Informar a los usuarios de fallos en el servicio tan pronto como se
conozcan en el Service Desk, de modo que los usuarios se encuentren en posición de hacer
ajustes ante las interrupciones. La información proactiva dada a usuarios ayuda a reducir las
solicitudes sometidas por los usuarios.
Informes de Gestión de Incidentes
Objetivo Procesal: Proveer información relacionada con los Incidentes para uso en otros
procesos de Gestión de Servicios, y para asegurar que los Incidentes previos sirvan para
potenciar las mejoras. (Wikipedia, 2016)
Actividades principales de la Gestión de Incidencias según ITIL
Detección
Cuanto antes se detecte una incidencia, menor será su impacto en el negocio. Por lo tanto, es
importante monitorizar los recursos con el objetivo de detectar incidencias potenciales y
normalizar el servicio antes de que se produzca un impacto negativo en los procesos de negocio
o, si esto no es posible, que el impacto sea mínimo. (Servicetonic, 2017)
33
Registro
Todas las incidencias del servicio deben ser registradas, y cada incidencia debe registrarse de
forma independiente. La información a registrar generalmente incluye:
– Identificador único.
– Categorización.
– Urgencia, impacto y prioridad.
– Fecha y hora.
– Persona/grupo que registra la incidencia.
– Canal de entrada.
– Datos del usuario.
– Síntomas.
– Estado.
– CIs (Configuration Items, elementos de configuración) asociados.
– Persona/grupo asignado para la resolución.
– Problema/Known error asociado.
– Actividades realizadas para la resolución.
– Fecha y hora de la resolución.
– Categoría del cierre.
– Fecha y hora de cierre.
Categorización
En esta actividad se establece el tipo exacto de la incidencia. Generalmente se establece una
categorización multinivel con dependencias entre niveles. El número de niveles dependerá de la
granularidad con la que necesitemos tipificar las incidencias. A veces, no se categoriza
adecuadamente una incidencia en el momento del registro. Si esto sucede, debemos asegurarnos
de que en el momento del cierre la categorización queda correctamente establecida.
34
Priorización
Generalmente, la prioridad de la incidencia nos indica cómo se ha de gestionar.
La prioridad de la incidencia suele depender de:
- La urgencia: rapidez con que la incidencia necesita ser resuelta.
- El impacto: generalmente se determina por el número de usuarios afectados, aunque lo
realmente importante es la criticidad para el negocio de los usuarios afectados por la
incidencia.
Al final, lo que realmente determina el impacto son los aspectos adversos que la incidencia tiene
en el negocio. Además de la urgencia y el impacto, la prioridad también puede depender de otros
factores como si el usuario es VIP, el departamento del usuario, etc. Es muy conveniente que la
herramienta de soporte utilizada sea capaz de calcular la prioridad en base a reglas. En cualquier
caso, el equipo de soporte debe conocer estas reglas para poder priorizar adecuadamente.
Diagnóstico inicial
Cuando el personal de soporte de primer nivel recibe una incidencia, la diganostica en base a los
síntomas y, si está capacitado para ello, la resuelve.
Escalado
Existen dos tipos de escalado:
1. Funcional: el soporte de primer nivel se ve incapaz de resolver la incidencia y la asigna al
grupo resolutor correspondiente o especialistas.
2. Jerárquico: en caso de que se den ciertas circunstancias (incidencias graves o críticas, riesgo
de incumplimiento del SLA) que se deban notificar a los responsables del servicio
correspondiente.
A pesar de que se produzca un escalado, la incidencia sigue perteneciendo al equipo de Service
Desk, y es éste es el responsable de hacer el seguimiento de la misma y mantener informados a
los usuarios hasta su cierre.
35
Investigación y diagnóstico
Si la incidencia hace referencia a un fallo en el sistema, lo más probable es que se necesite
investigar la causa del fallo. Las tareas más comunes dentro de esta actividad son las siguientes:
(Servicetonic, 2017)
Establecer exactamente qué es lo que no funciona correctamente y para qué secuencia de
acciones del usuario (casuística).
Establecer el impacto potencial de la incidencia.
Determinar si la incidencia está producida por la implantación de un cambio.
Buscar en la base de datos de conocimiento (base de datos de errores conocidos, registro
de incidencias, etc.) posibles soluciones y/o workarounds.
Resolución
Cuando se detecta una solución potencial, ésta debería ser aplicada y testeada. Una vez
comprobada la resolución, la incidencia se da por resuelta y se asigna al equipo de Service Desk
para su cierre. Asi mismo, se deben registrar todas las acciones realizadas para resolver la
incidencia en el historial de la misma.
Cierre
Antes de cerrar la incidencia el equipo del Service Desk debería validar lo siguiente:
Si el usuario está satisfecho con la resolución de la incidencia.
Si el cierre ha sido categorizado.
Si se han cumplimentado todos los datos necesarios.
Si es un problema recurrente. En este caso, generar un problema.
Eventualmente, se puede pasar una encuesta de satisfacción al usuario.
36
Roles ITIL
Gestor de Incidentes - Propietario de Proceso
El Gestor de Incidentes es responsable de la implementación efectiva del proceso de Gestión de
Incidentes y prepara los informes correspondientes. Ofrece representación durante la primera
fase de escalado de incidentes, cuando no se pueden solucionar en el marco de los niveles de
servicio acordados.
Equipo de Incidentes Graves
Se trata de un equipo de gestores de TI y técnicos expertos establecido dinámicamente,
generalmente bajo el mando de un Gestor de Incidentes, y formulado para concentrarse en la
solución de un Incidente grave.
Soporte de Primera Línea
La responsabilidad del Soporte de Primera Línea es registrar y clasificar los Incidentes
reportados y llevar a cabo esfuerzos inmediatos para restaurar lo antes posible un servicio de TI
que ha fallado. Si no se encuentra una solución adecuada a estos fines, el Soporte de Primera
Línea refiere el incidente a grupos de apoyo técnico especializado (Soporte de Segunda Línea).
El Soporte de Primera Línea también mantiene informados a los usuarios acerca del estatus de
los Incidentes cada cierto tiempo.
Soporte de Segunda Línea
El Soporte de Segunda Línea se hace cargo de los Incidentes que no pueden ser resueltos con los
recursos del Soporte de Primera Línea. De ser necesario, requerirá apoyo externo de
manufactureros de programados y de hardware. La meta es restaurar un servicio de TI fallido en
el menor tiempo posible. Si no se encuentra solución, el Incidente debe ser referido a Gestión de
Problemas. (Wikipedia, 2016)
37
Metricas ITIL
KPI (Métrica de CSI) Descripción
Cantidad de incidentes repetidos Cantidad de incidentes repetidos (con métodos para su
resolución ya conocidos)
Incidentes resueltos a distancia Cantidad de incidentes resueltos a distancia por el
Service Desk (p.ej. sin acudir al lugar del usuario)
Cantidad de escalados Cantidad de escalados de incidentes no resueltos en el
tiempo acordado
Cantidad de incidentes Cantidad de incidentes registrados por el Service
Desk, agrupados por categorías
Tiempo de resolución de
incidente
Tiempo medio para resolver un incidente, agrupados
por categorías
Tasa de Resolución de Primera
Llamada
Porcentaje de incidentes resueltos en el Service Desk
durante la primera llamada, agrupados por categorías
Resolución dentro del SLA Porcentaje de incidentes resueltos durante el tiempo
acordado en el SLA, agrupados por categorías
Esfuerzo de resolución de
incidente
Promedio de esfuerzo de trabajo para resolver
Incidentes, agrupados por categorías
Tabla 1Metricas ITIL (Wikipedia, 2016)
38
2.3.5 Mejora Continua del Servicio
Es la fase que engloba el conjunto de todas y el significado de ―ciclo‖ con el resto de actividades,
poniendo foco en la mejora de los servicios para mantener la idea principal de alinear la
tecnología con el negocio. Para lograrlo es necesario identificar oportunidades de mejora y
realizar las tareas necesarias para conseguir dichas mejoras. Por lo que se adoptarán y adaptarán
los procesos de Negocio para alinear los servicios y proveer beneficios justificados.
Referente a los beneficios, aparecen dos términos en esta fase a tener en cuenta, por un lado el
Retorno de Inversión (ROI – Return Of Inversion) que refleja la diferencia entre los beneficios y
la cantidad invertida; y por otro, Valor de la Inversión (VOI – Value Of Inversion) es la cuantía
adicional a partir de los resultados del servicio que no constituyen un beneficio económico, y que
se obtiene a largo plazo. Los objetivos a alcanzar en esta fase se pueden deducir de las líneas
anteriores, aún se pueden concretar más en:
Revisar, analizar y hacer las recomendaciones de mejora para cada una de las etapas.
Revisar y analizar los resultados de los Niveles de Servicio y compararlos con los SLAs
establecidos.
Identificar e implementar mejoras que aumenten el ROI y VOI de los servicios TI, sin
sacrificar la satisfacción del cliente.
Mejorar la calidad de los servicios, incorporando nuevos procesos adaptados a los
requisitos del cliente, aumentando la eficiencia y efectividad. (Universidad Rey Juan
Carlos, 2012).
39
2.4 COBIT
2.4.1 Historia COBIT
El marco de referencia Cobit en sus primeras versiones se definía como un marco de auditoría y
control para auditores de TI. (Años 1996 Cobit1 y 1998 Cobit2). Posteriormente ISACA en las
revisiones del año 2000 genera Cobit3 incluyendo un documento o guía de gestión para la
dirección, con una acercamiento al concepto de Gobierno de TI Luego aparece la versión 4.0 de
Cobit (año 2005-2007) la cual define un marco general de Gobierno TI y definiciones como Val
IT (valor de las TI) o RISK IT (riesgos). Finalmente en el año 2012 Cobit 5.0 donde su principal
principio es el de separar el Gobierno de la Gestión.
Figura 6 Evolucion de COBIT (Emaze, 2017)
2.4.2 Definición
Objetivos de Control para Información y Tecnologías Relacionadas (COBIT, en inglés: Control
Objectives for Information and related Technology) es una guía de mejores prácticas presentada
como framework, dirigida al control y supervisión de tecnología de la información (TI).
Mantenida por ISACA (en inglés: Information Systems Audit and Control Association) y el IT
GI (en inglés: IT Governance Institute), tiene una serie de recursos que pueden servir de modelo
de referencia para la gestión de TI, incluyendo un resumen ejecutivo, un framework, objetivos de
control, mapas de auditoría, herramientas para su implementación y principalmente, una guía de
técnicas de gestión. (Wikipedia, 2017)
40
COBIT es un marco de referencia globalmente aceptado para el gobierno de TI basado en
estándares de la industria y las mejores prácticas. Una vez implementado, los ejecutivos
pueden asegurarse de que se ajusta de manera eficaz con los objetivos del negocio y dirigir
mejor el uso de TI para obtener ventajas comerciales. COBIT brinda un lenguaje común a
los ejecutivos de negocios para comunicar las metas, objetivos y resultados a los
profesionales de auditoría, informática y otras disciplinas. (Isaca, 2008)
COBIT brinda las mejores prácticas y herramientas para el monitoreo y la gestión de las
actividades de TI. El uso de las TI es una inversión importante que debe ser gestionado.
COBIT ayuda a los ejecutivos a comprender y gestionar las inversiones de TI durante su
ciclo de vida y proporciona un método para evaluar si los servicios de TI y las nuevas
iniciativas satisfacen los requisitos empresariales y sea probable que entreguen los beneficios
esperados. Existe una tremenda diferencia entre las empresas que realizan una buena gestión de
TI y las que no lo hacen, o no pueden.
COBIT permite el desarrollo de políticas claras y mejores prácticas para la
administración de TI. El marco ayuda a aumentar el valor obtenido de TI. También
ayuda a las organizaciones a gestionar los riesgos relacionados con TI y a asegurar el
cumplimiento, la continuidad, seguridad y privacidad.
Debido a que COBIT es un conjunto de herramientas y técnicas probadas y aceptadas
internacionalmente, su implementación es una señal de buena gestión en una organización.
Ayuda a los profesionales de TI y a usuarios de empresas a demostrar su competencia
profesional a la alta dirección. Como ocurre con muchos procesos de negocio genéricos,
existen estándares y mejores prácticas de la industria de TI que las empresas deberían seguir
cuando utilizan las TI. COBIT se nutre de estas normas y proporciona un marco para
implementarlas y gestionarlas. Una vez que se identifican e implementan los principios clave de
COBIT para una empresa, los ejecutivos ganan confianza en que la utilización de las TI puede
ser gestionada de forma eficaz. (Isaca, 2008)
41
COBIT 5 está pensado para empresas de todo tipo y tamaño, incluyendo el sector público y sin
ánimo de lucro y está diseñado para ofrecer beneficios a las empresas, incluyendo:
Creación de valor incrementado a partir del uso de TI; satisfacción del usuario con los
servicios y compromisos de TI; riesgo reducido relacionado con TI; y cumplimiento con
las leyes, regulaciones y requisitos contractuales
El desarrollo de más servicios y soluciones basadas en TI
Aumento de la participación de toda la empresa en las actividades relacionadas con TI
2.4.3 El marco de referencia COBIT 5: Basa su metodología en cinco principios claves para el
gobierno la gestión de las TI a nivel organizacional.
Figura 7 Principios COBIT 5 (PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR, 2013)
Principio 1. Satisfacer las Necesidades de las Partes Interesadas—Las empresas existen para
crear valor para sus partes interesadas manteniendo el equilibrio entre la realización de
beneficios y la optimización de los riesgos y el uso de recursos. COBIT 5 provee todos los
procesos necesarios y otros catalizadores para permitir la creación de valor del negocio mediante
el uso de TI. Dado que toda empresa tiene objetivos diferentes, una empresa puede personalizar
COBIT 5 para adaptarlo a su propio contexto mediante la cascada de metas, traduciendo metas
corporativas de alto nivel en otras metas más manejables, específicas, relacionadas con TI y
mapeándolas con procesos y prácticas específicos.
42
Principio 2: Cubrir la Empresa Extremo-a-Extremo: COBIT 5 integra el gobierno y la
gestión de TI en el gobierno corporativo:
Cubre todas las funciones y procesos dentro de la empresa; COBIT 5 no se enfoca sólo en
la ―función de TI‖, sino que trata la información y las tecnologías relacionadas como
activos que deben ser tratados como cualquier otro activo por todos en la empresa.
Considera que los catalizadores relacionados con TI para el gobierno y la gestión deben
ser a nivel de toda la empresa y de principio a fin, es decir, incluyendo a todo y todos
internos y externos, los que sean relevantes para el gobierno y la gestión de la
información de la empresa y TI relacionadas.
Principio 3: Aplicar un Marco de Referencia Único Integrado: Hay muchos estándares y
buenas prácticas relativos a TI, ofreciendo cada uno ayuda para un subgrupo de actividades de
TI. COBIT 5 se alinea a alto nivel con otros estándares y marcos de trabajo relevantes, y de este
modo puede hacer la función de marco de trabajo principal para el gobierno y la gestión de las TI
de la empresa.
Principio 4: Hacier Posible un Enfoque Holístico: Un gobierno y gestión de las TI de la
empresa efectivo y eficiente requiere de un enfoque holístico que tenga en cuenta varios
componentes interactivos. COBIT 5 define un conjunto de catalizadores (enablers) para apoyar
la implementación de un sistema de gobierno y gestión global para las TI de la empresa. Los
catalizadores se definen en líneas generales como cualquier cosa que puede ayudar a conseguir
las metas de la empresa. El marco de trabajo COBIT 5 define siete categorías de catalizadores:
Principios, Políticas y Marcos de Trabajo
Procesos
Estructuras Organizativas
Cultura, Ética y Comportamiento
Información
Servicios, Infraestructuras y Aplicaciones
Personas, Habilidades y Competencias
43
Principio 5: Separar el Gobierno de la Gestión—– El marco de trabajo COBIT 5 establece
una clara distinción entre gobierno y gestión. Estas dos disciplinas engloban diferentes tipos de
actividades, requieren diferentes estructuras organizativas y sirven a diferentes propósitos. La
visión de COBIT 5 en esta distinción clave entre gobierno y gestión es:
Gobierno
El Gobierno asegura que se evalúan las necesidades, condiciones y opciones de las partes
interesadas para determinar que se alcanzan las 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.
En muchas corporaciones, el gobierno global es responsabilidad del comité de dirección bajo el
liderazgo del presidente. Algunas responsabilidades de gobierno específicas se pueden delegar en
estructuras organizativas especiales al nivel apropiado, particularmente en las corporaciones más
grandes y complejas.
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.
En muchas empresas, la gestión es responsabilidad de la dirección ejecutiva bajo el liderazgo del
Director General Ejecutivo (CEO).
Juntos, estos cinco principios habilitan a la empresa a construir un marco de gestión de gobierno
y gestión efectivo que optimiza la inversión y el uso de información y tecnología para el
beneficio de las partes interesadas. (Auditoria Informatica, 2014)
44
2.4.4 Dominios de COBIT 5.0
El marco de referencia Cobit 5 define varios procesos de gobierno y gestión todos con el
objetivo de cubrir las metas tanto de empresas grandes en las que se maneja un considerable
número de procesos o empresas pequeñas que manejan un número reducido de procesos.
Este modelo proporciona un marco integral para supervisar y medir el desempeño de TI en las
organizaciones integrando buenas prácticas de gestión y representando todos los procesos que
regularmente se encuentran en las mismas relacionados con las actividades de TI Existen dos
dominios principales de procesos que divide Cobit 5 detallados a continuación:
Gobierno: contiene un dominio con cinco procesos de gobierno, y dentro de cada uno de
ellos se establecen prácticas de evaluación, orientación y supervisión (EDM).
Gestión: contiene cuatro dominios e igualmente dentro de cada uno de ellos se
establecen prácticas de planificación, implementación, soporte y evaluación de las TI. –
Alinear, Planificar y Organizar (Align, Plan and Organise, APO) – Construir, Adquirir e
Implementar (Build, Acquire and Implement, BAI) – Entregar, dar Servicio y Soporte
(Deliver, Service and Support, DSS) – Supervisar, Evaluar y Valorar (Monitor, Evaluate
and Assess, MEA).
Los dos dominios principales de procesos que divide Cobit 5 detallados anteriormente se
clasifican en un número de 37 procesos de gobierno y gestión, los cuales son una guía integra y
referencial para evaluar y diagnosticar el estado actual de cómo se encuentra la gestión de las TI
en las empresas. A continuación se detallan los 37 procesos contenidos en los cinco dominios
principales de COBIT.
45
Figura 8 Procesos de Cobit 5.0 (Magazcitum, 2010)
2.4.4.1 Evaluar, Orientar y Supervisar (EDM)
Asegurar el establecimiento y mantenimiento del marco de referencia de gobierno.
Asegurar la entrega de beneficios.
Asegurar la optimización del riesgo.
Asegurar la optimización de recursos.
Asegurar la transparencia hacia las partes interesadas.
2.4.4.2 Alinear, Planificar y Organizar (APO)
Gestionar el marco de gestión de TI.
Gestionar la estrategia.
Gestionar la arquitectura empresarial.
Gestionar la innovación.
Gestionar el portafolio.
Gestionar el presupuesto y los costes.
Gestionar los recursos humanos.
46
Gestionar las relaciones.
Gestionar los acuerdos de servicio.
Gestionar los proveedores.
Gestionar la calidad.
Gestionar el riesgo.
Gestionar la seguridad.
2.4.4.3 Construir, adquirir e implementar (BAI )
Gestionar programas y proyectos.
Gestionar la definición de requisitos.
Gestionar la identificación y construcción de soluciones.
Gestionar la disponibilidad y la capacidad.
Gestionar la introducción del cambio organizativo.
Gestionar los cambios.
Gestionar la aceptación del cambio y la transición.
Gestionar el conocimiento.
Gestionar los activos.
Gestionar la configuración.
2.4.4.4 Entrega, Servicio y Soporte (DSS)
Gestionar operaciones.
Gestionar peticiones e incidentes de servicio.
Gestionar problemas.
Gestionar la continuidad.
Gestionar servicios de seguridad.
Gestionar controles de procesos de negocio.
2.4.4.5 Supervisar, Evaluar y Valorar (MEA)
Supervisar, evaluar y valorar el rendimiento y la conformidad.
Supervisar, evaluar y valorar el sistema de control interno.
47
Supervisar, evaluar y valorar la conformidad con los requerimientos externos.
2.4.4.6 Entrega, Servicio y Soporte (DSS)
Gestionar operaciones.
Gestionar peticiones e incidentes de servicio.
Gestionar problemas.
Gestionar la continuidad.
Gestionar servicios de seguridad.
Gestionar controles de procesos de negocio. (PONTIFICIA UNIVERSIDAD
CATÓLICA DEL ECUADOR, 2013)
DSS01 Gestionar operaciones. Coordinar y ejecutar las actividades y los procedimientos
operativos requeridos para entregar servicios de las TI tanto internos como externalizados,
incluyendo la ejecución de procedimientos operativos estándar predefinidos y las actividades de
monitorización requeridas.
DSS02 Gestionar peticiones e incidentes de servicio. 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, escalar y resolver incidentes.
DSS03 Gestionar problemas. Identificar y clasificar problemas y sus causas raíz y proporcionar
resolución en tiempo para prevenir incidentes recurrentes. Proporcionar recomendaciones de
mejora.
DSS04 Gestionar la continuidad. Establecer y mantener un plan para permitir al negocio y a TI
responder a incidentes e interrupciones de servicio para la operación continua de los procesos
críticos para el negocio y los servicios TI requeridos y mantener la disponibilidad de la
información a un nivel aceptable para la empresa.
48
DSS05 -Gestionar servicios de seguridad. Proteger la información de la empresa para mantener
aceptable el nivel de riesgo de seguridad de la información de acuerdo con la política de
seguridad. Establecer y mantener los roles de seguridad y privilegios de acceso de la información
y realizar la supervisión de la seguridad.
DSS06 -Gestionar controles de procesos de negocio. Definir y mantener controles apropiados
de proceso de negocio para asegurar que la información relacionada y procesada dentro de la
organización o de forma externa satisface todos los requerimientos relevantes para el control de
la información. Identificar los requisitos de control de la información y gestionar y operar los
controles adecuados para asegurar que la información y su procesamiento satisfacen estos
requerimientos. (Martinez, 2014)
49
2.5 MARCO CONCEPTUAL
Para la realización del presente anteproyecto, se expone una conceptualización que establecerá
una propuesta sólida y enfocada en la solución del problema.
COBIT: Está orientado a ser utilizado para organizaciones que deseen garantizar una
adecuada estructura de Gobierno, es decir busca definir una estructura que comprenda,
implante y evalúe capacidades, rendimiento y riesgos de TI para fundamentalmente cumplir
los requisitos del negocio, ISACA (2018).
ITIL: Puede describirse como aquella gestión capaz proporcionar las mejores prácticas para
la Gestión de Servicios de TI y con ello entrega una serie de procesos integrados para
brindar con alta calidad la provisión y el soporte de los servicios de TI, lo pueden adoptar las
organizaciones que quieran normalizar los procesos de Gestión de Servicios de TI de
acuerdo a un marco de mejores prácticas mundialmente reconocido, B. Johnson & J. Higgin
(2007).
Proceso: Por lo general, un conjunto de procedimientos influenciados por las políticas y
estándares de la organización, que toma las entradas provenientes de un número de fuentes,
incluyendo otros procesos, manipula las entradas, y genera salidas, incluyendo a otros
procesos, para los clientes de los procesos. Los procesos tienen razones claras de negocio
para existir, dueños responsables, roles claros y responsabilidades alrededor de la ejecución
del proceso, así como los medios para medir el desempeño, (ISACA, 2012).
Tecnologías De La Información (TI): Las Tecnologías de la Información proponen los
elementos tecnológicos que apoyan la implementación y correcto funcionamiento de los
sistemas de información (SI), contribuyendo de manera activa a la consecución de los
objetivos de negocio de las empresas, (Larry Klosterboer, 2008).
50
Incidencia: Una interrupción no planificada de un Servicio de TI o una reducción de la
Calidad de un Servicio de TI. (Wikipedia, 2016)
Reglas de Escalado de Incidentes: Se usan para establecer la jerarquía en caso de escalado
de Incidentes. Sus indicadores se basan en la gravedad de los Incidentes y en los períodos de
resolución. (Wikipedia, 2016).
Escalado por Parte del Usuario: Se trata de un escalado relacionada con el procesamiento
de un Incidente; se origina luego de que un usuario experimenta retrasos o fallos durante la
restauración de un servicio. (Wikipedia, 2016)
Preguntas Frecuentes de los Usuarios: Información de autoayuda para los usuarios,
provista por el Service Desk como parte de las Páginas de Apoyo o de una red interna.
(Wikipedia, 2016)
Informe de Gestión de Incidentes: Provee información relacionada con Incidentes a los
procesos de Gestión de Servicio. (Wikipedia, 2016)
Modelo de Incidentes: Contiene pasos predefinidos que deben tomarse para manejar cierto
tipo de Incidentes. Es un modo de asegurar que los Incidentes que ocurren de manera
rutinaria se manejen eficiente y efectivamente. (Wikipedia, 2016)
Registro de Incidente: Es un conjunto de datos con todos los detalles de un Incidente, que
documenta la historia de los mismos desde su registro hasta su resolución. Un Incidente se
define como una interrupción no planificada o como la reducción de calidad de algún
servicio de TI. Cualquier evento con potencial de interrumpir un servicio de TI en el futuro
también se considera un Incidente (por ejemplo, el fallo de un disco duro). (Wikipedia,
2016)
51
Información sobre Estado de Incidente: Es un mensaje que contiene el estatus actual de
un Incidente, generalmente enviado a un usuario que lo reportó inicialmente. (Wikipedia,
2016)
Preguntas sobre Estado de Incidentes: Cualquier pregunta sobre el estatus actual de un
Incidente, generalmente provienen de un usuario que lo reportó inicialmente. (Wikipedia,
2016)
Notificación de Fallos al Servicio: Es el informe de un fallo en el servicio al personal del
Service Desk, que puede llegar por vía telefónica o por correo electrónico de parte de un
usuario, o a través de alguna herramienta de monitorización de sistemas. (Wikipedia, 2016).
Información Pro-Activa al Usuario: Es una notificación de que se avecinan fallos en el
servicio cuando los usuarios no estén al tanto de las mismas, para darles la oportunidad de
que se preparen para un período de indisponibilidad del servicio. (Wikipedia, 2016).
Solicitud de Apoyo: Es una solicitud de apoyo en la solución de un Incidente o problema,
usualmente generado como parte de los procesos de Gestión de Incidentes o Problemas
cuando se requiere de más ayuda por parte de técnicos expertos. (Wikipedia, 2016).
Cumplimiento de la Solicitud: Cumplir las Solicitudes de Servicio, que en la mayoría de
los casos son menores; por ejemplo, solicitudes de cambio de contraseña o información.
(Wikipedia, 2016)
Gestión del Acceso: Otorgar el derecho a un servicio a usuarios autorizados, mientras se
previene el acceso de usuarios no autorizados. Los procesos de Gestión del Acceso ponen en
práctica las políticas definidas por la Gestión de Seguridad de TI. La Gestión del Acceso
también es conocida como Gestión de Derechos o Gestión de Identidad. (Wikipedia, 2016)
52
Gestión de Problemas: Es la prevención de Incidentes y la minimización del impacto de
aquellos Incidentes que no pueden prevenirse. La Gestión Proactiva de Problemas analiza
los Registros de Incidentes y utiliza datos de otros procesos de Gestión del Servicio de TI
para identificar tendencias o problemas significativos. (Wikipedia, 2016)
Gestión de las Operaciones de TI: Monitorear y controlar los servicios e infraestructuras
de TI. La Gestión de Operaciones de TI lleva a cabo tareas diarias relacionadas con la
operación de componentes y aplicaciones de infraestructura. Esto incluye la programación
de trabajos en un calendario, actividades de soporte y restauración y el mantenimiento
rutinario. (Wikipedia, 2016).
Gestión de Instalaciones de TI: Gestionar el entorno físico en que se ubica la
infraestructura de TI. La Gestión de Instalaciones de TI incluye todos los aspectos de la
gestión del entorno físico, como por ejemplo las fuentes de energía y sistemas de
enfriamiento, la gestión del acceso a dependencias y el monitoreo de ambientes. (Wikipedia,
2016)
53
2.6 ESTADO DEL ARTE
En la actualidad, varias empresas han desarrollado proyectos con el fin de optimizar los procesos
de gestión de incidencias, dichas implementaciones no se dan solo en las áreas de Tecnologías de
la Información sino también para áreas de Servicios al Cliente, áreas de Mercadeo y áreas
Administrativas que requieren tener un punto de contacto central para sus solicitudes y
requerimientos. A continuación, se describirán algunos casos donde se evidencia el impacto que
tiene en los procesos de Gestión de Incidencias:
El primer caso que se mencionará la empresa financiera Banco Falabella, quien estaba en un
proceso de crecimiento en el número de usuarios a nivel nacional, para lo cual se hizo necesario
empezar a gestionar los servicios de tecnología de forma eficiente para garantizar a todos
empleados la ejecución de sus funciones con normalidad. En este proyecto permitió mejorar la
productividad y utilizar eficientemente los recursos para este proceso. Algunas de las mejoras
que Banco Falabella experimentará gracias a este proyecto son:
Conseguir un proceso formal y facilitar que todos los funcionarios trabajen de forma
conjunta en la entrega y soporte de los incidentes alineados con los objetivos y políticas
de la Subgerencia de Sistemas.
Proporcionar información de Gestión a la alta Gerencia mediante los informes que surgen
por el control del proceso diseñado.
Mejorar la calidad y fiabilidad de los servicios proporcionados a los usuarios. Como
consecuencia directa se obtiene una mayor satisfacción y mejora continua.
Incremento de la productividad y eficacia, reduciendo riesgos.
Crecer sólidamente en principios metodológicos y de calidad acorde a os requerimientos
del Banco Falabella.
54
Avanzar en el camino de la Gestión de Calidad.
Organizar el trabajo estandarizado, delimitando responsabilidades.
Mejorar comunicación interna con seguimiento continuo de resultado. (Torres &
Machado, 2016)
El segundo caso se expone la implementación de un proceso de gestión de incidentes para una
entidad financiera en Perú, la cual presentaba varios síntomas visibles que indican que el área de
TI de una empresa no cumple con las expectativas que espera el negocio. Los síntomas
presentados son: (i) inadecuada gestión de la infraestructura, (ii) excesos de gastos, (iii) fallas en
el cumplimiento a las regulaciones de los distintos organismos, (iv) incumplimiento de los
niveles de servicio con los clientes internos y externos, (v) quejas recurrentes por parte de los
clientes, entre otros.
Uno de los principales problemas es que en la entidad financiera posee varios centros de atención
al usuario final. El usuario es el encargado de conocer las funciones de cada área de sistemas y
saber a quién llamar. Así, por ejemplo, si tiene un problema con su PC, llamará a Help Desk; si
tiene lentitud en las aplicaciones, llamará a Administración de Redes o de Telecomunicaciones;
si necesita aumentar su cuota de impresiones,
Llamará nuevamente a Help Desk, pero si necesita aumentar los recursos de su PC o tener una
aplicación nueva en su PC, llamará al área de Instalaciones. Al ver que hay varios puntos de
recepción, esto origina que los tiempos de atención aumenten y que cada área sea muy
independiente de otra.
Los aspectos positivos que trajo este proyecto de investigación al área de tecnología de la entidad
financiera son los siguientes:
Con la implementación de ITIL, se alienta el cambio cultural hacia la provisión de
servicios.
Se mejora la relación con los clientes y usuarios pues existen acuerdos de calidad.
A través de la implementación de procesos ITIL, se desarrollan procedimientos
estandarizados y fáciles de entender que apoyan la agilidad en la atención, logrando de
esta forma visualizar el cumplimiento de objetivos corporativos.
55
Con los procesos de gestión de incidentes y la gestión de problemas ya maduros, se
reducen los tiempos de indisponibilidad de los sistemas. (Gomez, 2012)
Dado que este proyecto de investigación se está desarrollando específicamente en el área de
Tecnologías, se hace mencionar este tercer caso, que se da en la empresa Soporte Lógico LTDA,
la cual presta servicios de desarrollo y soporte de software a nivel nacional. La empresa requiere
estandarizar sus procesos de tal manera que logren proporcionar una adecuada gestión de la
calidad del servicio prestado, alinear los procesos del negocio con la infraestructura de
tecnologías de información y reducir los riesgos asociados a los servicios que se ofrecen, con el
fin de aumentar la eficiencia de los procesos y así poder dar un mejor servicio a un mayor
número de clientes a nivel nacional.
Los beneficios que se ha concluido de este proyecto de investigación son los siguientes:
La empresa Soporte Lógico Ltda está en capacidad de adoptar el estándar ITIL
sin hacer cambios mayores en su estructura ni en su planta de personal.
Con la mesa de ayuda se solucionaron las dificultades de contacto entre los clientes y la
empresa.
Las especificaciones del estándar ITIL son propuestas en su mayoría para mejorar la
gestión de servicios en la empresa Soporte Lógico.
Con la estructura de gestión de procesos propuesta se da mayor agilidad a la solución de
problemas además, se logra minimizar y controlar los riesgos.
Las dificultades en la atención el cliente se superan con la propuesta de gestión de
servicios
Las mejores prácticas de ITIL se adaptan a cualquier tipo de empresa sin importar el
tamaño de su planta de personal ni su infraestructura. (Paredes, 2008)
Por último nos hemos dispuesto a incluir en este estado del área el caso de una empresa grande
en el sector de las telecomunicaciones y que cada día viene innovando y mostrando adecuaciones
en sus procesos corporativos, es Claro Soluciones quien ha permitido llevar su caso para que sea
estudio de investigación con fines netamente académicos.
56
A pesar que existen unos acuerdos de niveles de servicio (Service Level Agreement, SLA) entre
la empresa Claro Colombia S.A. y sus clientes, herramienta que ayuda a ambas partes a llegar a
un consenso en términos del nivel de calidad del servicio, en aspectos tales como el tiempo de
respuesta, disponibilidad horaria, documentación disponible, personal asignado al servicio, etc.
Aspectos que el equipo de la mesa de servicio debe tener en cuenta para la solución de
incidencias. Se hace necesario realizar ajustes en el proceso actual para que el servicio prestado
cumpla con los estándares de calidad y la normativa de tiempos ya mencionados.
Un análisis preliminar muestra indicios que las principales razones por las que se generan tal
cantidad de incidentes en primera instancia esta relacionados con eventos que producen
interrupciones o reducción de la calidad en las herramientas de TI que los empleados necesitan
para realizar su labor y en segunda instancia por la clasificación incorrecta de la línea del
servicio, que implica retrasos en el funcionamiento del servicio debido a que el equipo de la
mesa de servicio a cargo no tenga claridad en el tipo de falla. Estas situaciones hacen que los
tiempos de respuesta actuales no puedan ser mejores, lo que hace que el servicio no se
restablezca lo antes posible. El ajuste realizado al modelo de gestión de incidentes de la empresa
Claro Colombia S.A. le proporciona al proceso de operación de servicio y en específico a la
gestión de incidencias una mayor efectividad y simplicidad, en particular cuando los clientes
internos creen un incidente en la mesa de servicio mejorando así el servicio prestado y
reduciendo los tiempos de respuesta.
Con los cambios propuestos al modelo actual de gestión de incidentes se espera mejorar la
calidad del servicio con menores tiempos de respuesta y facilidad en el proceso de solicitud del
servicio por parte de los clientes internos. También facilitaría a los especialistas encargados de
solucionar los incidentes reportados identificando con mayor rapidez el tipo de falla y de esta
manera poder dar solución con mayor eficiencia. Los datos recolectados en la base de datos de la
mesa de ayuda de la empresa permitieron identificar el tipo de falla que más crearon los clientes
internos de la empresa durante el tiempo establecido de investigación, facilitando direccionar el
análisis para encontrar las causas de las fallas en la creación y diligenciamiento de los incidentes
por parte de los clientes internos. (Cifuentes, 2017)
57
CAPITULO 3 ANALISIS Y DIAGNOSTICO DE SITUACIÓN ACTUAL
En este capitulo revisaremos el estado actual de nuestro caso de estudio, asi mismo se nombraran
algunas conceptos establecidos en el área, un mapa del entorno de la compañía, la descripción
del sistema de información usado para la gestión de incidencias y el proceso actual con sus
respectivas actividades.
3.1 ESTADO ACTUAL DEL AREA DE TECNOLOGIA
Actualmente la Gerencia IT y Soporte se encuentra bajo la potestad de la Dirección General en
Colombia, su principal función es el apoyo de la operación de las áreas de negocio en sus
distintas actividades, asi mismo el área en mención es la responsable planificar y dirigir las
actividades relacionadas con el desarrollo de sistemas de información e implementación de
soluciones de infraestructura que garanticen el soporte transversal de los proceso e integración
con quienes componen el entorno organacional incluyendo clientes internos y proveedores.
Misión de la Gerencia IT y Soporte:
Servir en el logro de los objetivos estratégicos de AlphaCredit a través de la promoción,
evaluación e implantación de tecnología que facilite la toma de decisiones, simplifique y apoye
la operación diaria superando las expectativas de nuestros clientes que son nuestra razón de ser, a
través de los más altos estándares de calidad, honestidad, respeto y compromiso.
Visión de la Gerencia IT y Soporte:
Ser un área estratégica con el mejor talento humano, enfocada en servicios y soluciones de
excelencia para nuestros clientes internos, basándonos en innovación y tecnologías de punta,
apoyando de forma eficiente y eficaz a los procesos Comerciales, de Fabrica de Crédito y
Cartera; agregando valor a través de estrategias alineadas a contribuir que AlphaCredit sea
reconocida como líder en originación de créditos de libranza en el año 2020 a nivel nacional.
58
La Gerencia de IT y Soporte se divide en dos grandes areas y cada de una de ella presta un
servicio que soporta la operación diaria del negocio.
Coordinación de Desarrollo: Establece soluciones y proyectos de desarrollo que
facilitan el acceso a la información a los usuarios basados en el uso de los sistemas de
información de la organización, dando respuesta oportuna a los requerimientos y
solicitudes que puedan surgir desde las distintas áreas de la empresa.
Coordinación de Infraestructura y Soporte IT: Establece definiciones, planes y
proyectos enfocados en fortalecer la infraestructura tecnologíca que soporta los servicios
de la empresa, orienda a resolver las solicitudes y requerimientos de las distintas área del
negocio, asegurando para ellas la disponibilidad, integridad, confidencialidad de la
información generada.
Gererencia de IT & Soporte
Coordinación de Desarrollo Coordinación de Infraestructura
y Soporte IT
Lenovo Fortinet Microsoft HP Colsof
Gerencia
Subgerencia IT Subgerencia
Coordinaciones
Proveedores de Servicios
Figura 9 Estructura de la Gerencia de IT & Soporte(Fuente: Autores)
59
Proveedores de servicios: Ayudan a soportar la operación desde el punto de vista de la
ejecución, después de un primer contacto con el cliente luego garantizando que el
producto o servicio proveeido este funcionando sin inconvenientes y cumpliendo la
función para lo que fue adquirido, con un soporte optimo eficiente permiten cumplir los
niveles de servicios que se establecieron de forma verbal con las distintas áreas.
Áreas de negocio: Usuario o grupo de usuarios dentro de un área de negocio, pero
están relacionados con los servicios que ocupa al interior de la compañia. Su
responsabilidad es reportar la incidencia que lo afecta a la Mesa de Ayuda de manera de
que el proceso de resolución de incidencia se lleve a cabo.
Comerciales externos (Free Lance): Usuario o grupo de usuarios que no están
vinculados directamente con la compañía pero afectan con una incidencia los servicios de
sistemas de información e infraestructura tecnológica que les ofrece la compañía para
operar.
Areas del Negocio
Mesa de ayuda
Soporte de aplicaciones e Infraestructura
Desarrollo
Comerciales Externos
(Free Lance)
Figura 10 Mapa de relaciones.( Fuente: Autores)
60
Mesa de ayuda: Único punto de contacto para reportar casos. Su misión es atender las
llamadas de los usuarios que reportan una incidencia y/o detectar proactivamente una
incidencia. Estos pueden suministrar el soporte via telefónica, via remota o en sitio según
sea el caso.
Desarrollo: Son los encargados de mantener los ambientes de pre producción (pruebas) y
producción en óptimo estado, para que la operación del negocio fluya en las mejores
condiciones y se generé la originación de créditos de libranza.
Soporte de aplicaciones e infraestructura: grupo que se encarga de recibir, investigar y
resolver las incidencias de segundo y tercer nivel; en la organización son los encargados
del mantenimiento de aplicaciones e infraestructura TI.
3.2 HERRAMIENTA DE APOYO PARA GESTIÓN DE INCIDENCIAS FRESHDESK
La compañía AlphaCredit se encuentra en un crecimiento constante desde hace dos años y medio
que empezó su operación en el país, la Gerencia de IT y Soporte desde entonces se ha
preocupado por buscar soluciones que se adapten y sean acordes a la etapa en que se encuentra la
empresa, es por eso que desde hace más de un año se genera la necesidad de centralizar las
solicitudes y requerimientos tecnológicos de las demás áreas del negocio, con esto se realiza la
adquisición de una aplicación comercial llamada Freshdesk.
Esta herramienta es un software basado en la nube que le permite dar soporte a sus clientes a
través de canales tradicionales como el teléfono, el correo electrónico y por medio de canales
sociales como Facebook y Twitter. Debido a que la solución se basa totalmente en la nube, Esta
ayuda a administrar múltiples grupos, flujos de trabajo y procedimientos de escalamiento.
También es compatible con múltiples productos y marcas e incluye capacidades multi-idioma y
multizona. Su económico modelo de precios mensuales lo hace adecuado para la mayoría de las
industrias, incluidas TI, seguros, hospitalidad, venta minorista, servicios públicos y más.
61
Dentro de sus principales características se encuentran las siguientes:
En primer lugar, está la bandeja de entrada del equipo tecnico, esta permite que el equipo
colabore y resuelva problemas sin estorbarse. Cada solicitud enviada al correo electrónico de
soporte se convierte en un ticket en el helpdesk. Se puede categorizar y priorizar tickets
fácilmente, y asignarlos a las personas adecuadas del equipo. Así mismo, la herramienta permite
la creación de acuerdos de nivel de servicios, es decir, establece, administra y satisface las
expectativas de los clientes a través de Acuerdos de nivel de servicio (SLA) para el soporte. Con
Freshdesk, se puede definir prioridades y requisitos de tickets para los tiempos de resolución,
para que los agentes sepan exactamente qué problemas abordar primero y qué tan rápido el
cliente espera una respuesta.
Cuando se revisó Freshdesk el año pasado, lo clasificamos entre las mejores soluciones de
servicio de asistencia en el mercado, especialmente para organizaciones más pequeñas que se
dedican directamente a atender a los clientes. Desde entonces, Freshdesk se sometió a un lavado
de cara masivo, obtuvo un nuevo apodo (" Freshdesk Mint ") y mejoró tanto que ahora es digno
de una designación de Editors 'Choice en la categoría de soporte. Hay herramientas de mesa de
ayuda que siguen las directrices de la Biblioteca de Infraestructura de Tecnología de la
Información (ITIL) y aquellos que no. El software que sigue ITIL atiende a empresas más
grandes que trabajan en la gestión de servicios, empresas que supervisan centros de datos o
grandes corporaciones en las que se deben seguir acuerdos de nivel de servicio (SLA) bajo sus
interpretaciones más estrictas. (Referencia, año)
Por el contrario, las herramientas como Freshdesk están diseñadas para procesar tickets de
servicio de clientes externos y, a la vez, proporcionar a los agentes información y recursos de
manera rápida y fácil de encontrar. En esta clase, encontrará herramientas como nuestro ganador
de otros Editors 'Choice, HappyFox , así como Cayzuy, Zendesk Support.
62
3.3. ESTADISTICAS DESTACADAS DE LA GESTIÓN DE INCIDENCIAS ACTUAL
Estadisticas de Ticket Creados
Para extraer la estadística actual de la gestión de incidencias en la organización, se tomó una
muestra de los últimos cinco meses del año inmediatamente anterior, donde se verá el
comportamiento en sus
estados, tipos y prioridades.
Se comienza mostrando en la herramienta las cuarto prioridades de las incidencias, como se
puede notar no se tiene una correcta selección de dichas prioridades en su gran mayoría todas
aparecen en ―Baja‖.
Figura 12 Listado de prioridades tomada Freshdesk (Fuente: Autores)
Seguidamente, se puede notar en los ticket creados las diez principales Categorias usadas en la
herramienta, donde hay un numero bastante elevado en la categoría ―Otros‖ eso quiere decir que
al no tener bien definidas estas categorías el administrador de Help desk no tiene mas opción que
Figura 11 Muestra de fechas tomada de Freshdesk (Fuente: Autores)
63
ir a la categoría ―Otros‖ y asignarle un tipología a la incidencia generadas.
Figura 13 Listado de categorias tomada Freshdesk (Fuente: Autores)
Por ultimo, se echará un vistazo a la interacción de los usuarios finales con los agentes de la
mesa de ayuda, en los cuales inicialemente se puede confirmar que los agentes no interuaban
con los clientes dándole una primera respuesta o solicitándole mas información para resolver
de formas las rápida y efectiva las incidencias generadas.
Figura 14 Informe respuesta de agentes versus respuestas de clientes tomada Freshdesk (Fuente: Autores)
64
3.4 DESCRIPCIÓN DEL PROCESO ACTUAL
La Gestión de Incidencias tiene la responsabilidad de resolver incidencias para restablecer la
operación normal de los servicios lo antes posible y minimizar el impacto adverso en las
operaciones del negocio, asegurar la disponibilidad y niveles de calidad, ya sea a través de una
solución temporal o definitiva de una incidencia.
Figura 15 Etapas de gestión de Incidencias actual(Fuente: Autores)
Este proceso se compone de tres grandes macro etapas, Registro y clasificación, Análisis y
resolución del incidencia, en la primera etapa es la más importante del proceso ya que es cuando
se toman las necesidades de los usuarios finales para posterior clasificación por ende si no está
tomada bien la necesidad puede producir demoras y posibles malas resoluciones, dentro segunda
etapa están las actividades de entendimiento y cuando el error se hace conocido y en la tercera
etapa están dentro las actividades de solución.
Descripción de las actividades del proceso
Registro y Clasificación:
La admisión y registro de la incidencia es el primer y necesario paso para una correcta gestión del
mismo. Las incidencias pueden provenir de diversas fuentes tales como usuarios que levantan a
través de mesa de Ayuda, incidencias de errores conocidos e incidencia levantadas por el grupo
de supervisión por alertas en los sistemas de monitoreo.
Las actividades del subproceso son las siguientes:
65
Admisión a trámite de la incidencia: La mesa de ayuda debe de ser capaz de evaluar en
primera instancia si el servicio requerido se incluye en el SLA (Acuerdos de Niveles de
Servicio) del cliente y en caso contrario renviarlo al jefe o área competente.
Comprobación de que esa incidencia aún no ha sido registrado: Es usual que más de un
usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones
innecesarias.
Registro Inicial: Se han de introducir en la base de datos asociada la información básica
necesaria para el procesamiento del incidencia (nombre del usuario, hora, descripción del
incidente, sistemas o herramienta afectada).
Notificación del incidencia: En los casos en que el incidencia pueda afectar a otros
usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar
su flujo habitual de trabajo.
La clasificación de un incidencia: tiene como objetivo principal el recopilar toda la
información que pueda ser de utilizada para la resolución del mismo.
Categorización: Se asigna una categoría dependiendo del tipo de incidencia o del grupo
de trabajo responsable de su resolución. Se identifican los servicios afectados por el
incidencia.
Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se
determina, según criterios prestablecidos, un nivel de prioridad.
Asignación de recursos: si la Mesa de Ayuda no puede resolver el incidencia en primera
instancia escalará al personal de soporte técnico (aplicaciones e infraestructura)
responsable de su resolución.
Monitorización del estado y tiempo de respuesta esperado: se asocia un estado a la
66
incidencia y se estima el tiempo de resolución de la incidencia en base al SLA (Acuerdos
de Niveles de Servicio) correspondiente y la prioridad. Se realiza el monitoreo de las
incidencias durante todo el ciclo de vida de una incidencia.
Análisis
En primera instancia, para realizar un adecuado diagnóstico, se examina la incidencia con los
responsables a cargo, ya sean grupos de agentes o usuarios generadores de incidencias. Con esta
información se trabaja para determinar si se puede identificar con alguna incidencia ya resuelta y
aplicar el procedimiento asignado.
Si la solución de la incidencia se escapa de las posibilidades de la Mesa de Ayuda y ésta re
direcciona el mismo a un nivel superior para su investigación por los expertos asignados, como
pueden ser los grupos de especialistas o coordinadores. Si estos expertos no son capaces de
resolver la incidencia se seguirán los protocolos de escalado predeterminados. Pudiendo escalar
a proveedores externos si existen riesgos de incumplimiento con los SLA (Acuerdos de Niveles
de Servicio) comprometidos. Durante todo el ciclo de vida de la incidencia se debe actualizar la
información almacenada en las correspondientes bases de datos para que los agentes implicados
dispongan de la información sobre el estado del mismo.
Resolución
En esta etapa el agente asignado resuelve la incidencia y registra en Freshdesk los comentarios
asociados a la resolución.
67
Diagnóstico del Proceso actual de gestión de incidencias
Una vez levantada la situación actual donde se identificaron los actores relevantes en el proceso
de gestión de incidencias actual en la organización, se ha podido identificar algunos puntos de
mejoras, si bien es cierto el proceso es cambiante de acuerdo a las actividades, pero no se
visualizan algunos elementos relevantes para el proceso como son los siguientes:
NO hay procedimientos referentes a la gestión de incidencias
No se realiza una priorización de las incidencias generadas.
NO se da una retroalimentación oportuna al usuario sobre el estado del caso.
se escalen inadecuadamente los incidencias y produzca un desgaste innecesario
NO se cumplan los niveles de servicio propuesto a los clientes internos
NO hay listado coherente de categorias en los servicios ofrecidos.
NO hay lineamientos según la categoría, priorización o tipo de usuario.
No se tienen definido los tiempos de proveedores en la herramienta actual
Los proveedores NO tienen interacción con la herramienta de Mesa de Ayuda
NO existe una base de conocimientos que permita optimizar la clasificación y
priorización.
NO hay visibilidad del proceso y no hay conocimiento de la productividad de forma clara
(indicadores del área).
NO hay conocimiento necesario por parte del usuario para hacer seguimiento de los casos
en la plataforma de Mesa de Ayuda.
Generalmente sin el control y seguimiento se pierde valiosa información sobre las causas de las
incidencias, los tiempos y calidad de atención lo que produce en los usuarios insatisfacción por
la mala y/o lenta gestión de sus incidencias.
68
PARTE III DESARROLLO DE LA INVESTIGACIÓN
CAPITULO 4 ESTRATEGIAS Y DISEÑO A IMPLEMENTAR PARA LA
GESTIÓN DE INCIDENCIAS
El modelo que se propone se fundamenta en la fase de Operación del Servicio de ITIL y el
marco de referencia integral proporcionado por COBIT 5, este se encontrará soportado en las
buenas prácticas aplicadas para la Gestión de Incidencias. Esta iniciativa conlleva
significativos cambios tecnologicos y organizacionales, para lo cual se require el aval de la
persona con mas responsabilidad en la organización (CEO), esto será transcendental para
implementar el modelo propuesto.
Adicionalmente, dicha implementación y pruebas se efectuaran con la herramienta
tecnologica adquirida por la empresa, la cual posibilitará la aplicación del proceso de Gestión
de Incidencias planteado y asi mismo se sugieren unos indicadores que permitan analizar los
resultados de la propuesta.
4.1 ESTRATEGIA DE SERVICIO DEL MODELO
A continuación se mencionaran las estrategias para establecer una Gestión de Incidencias
basado en las mejores practicas de tecnologia:
Determinar que el equipo de Mesa de Ayuda sea un exclusivo punto de contacto con
los usuarios finales, con el objetivo de definir un orden adecuado para la atención de
incidencias durante las diferentes estados que enmacan cada incidencia y que el usuario
tenga la posiblidad de estar informado de la trazabilidad de la incidencia generada.
Diseñar un proceso de gestión de incidencias, acorde a las necesidades actuales de la
organización y a los objetivos estratégicos de la misma.
69
Poseer una base de datos de conocimientos, para ofrecer una atención rápida a los
usuarios finales que solicitan dentro del soporte de primer nivel.
Crear un nuevo catálogo de servicios que permita delimitar las funciones y
compromisos de la mesa de ayuda con respecto a los servicios de TI que se brindan y
que estos se adapten a las necesidades que presenten los usuarios de la empresa
AlphaCredit El nuevo catalogo.
Establecer un plan de capacitación para los implicados en el proceso ITIL, que les
permita adaptarse a los cambios propuestos. Se hace indispensable capacitar al personal
de Mesa de Ayuda en como dar manejo ante eventos que se puedan generar en las
distintas áreas de la empresa. A continuación se presenta el plan de capacitación
propuesto:
Plan de Capacitación
Curso Objetivos Personal Suministrado
Fundamentos de
ITIL
Obtener conocimientos sobre las
buenas prácticas en fundamentos
ITIL Versión 3.
Equipos de Soporte
de Especialistas
Equipo de Mesa de
ayuda.
Proveedor
de servicios de
capacitaciones.
Proceso de
Gestión de
Incidencias.
Conocer el proceso diseñado para
la Gestión de Incidentes.
Entender las responsabilidades
asumidas por cada equipo de trabajo.
Equipos de Soporte
de Especialistas
Equipo de Mesa de
ayuda
Coordinadores
Personal
interno con
conocimiento,
(gestor del
proceso)
Servicio al
Cliente
Desarrollar habilidades
comunicativas hacia los usuarios,
manejo de tiempos y consensos
que mejoren la calidad de
atención.
Equipo de Mesa de
ayuda
Proveedor
de servicios de
capacitaciones.
70
Uso basico
herramienta de
Mesa de Ayuda
Conocer las opciones necesarias
que ofrece la herramienta para el
seguimiento de los casos
generados.
Usuarios Finales
Personal
interno con
conocimiento
(gestor del
proceso)
Tabla 2 Plan de capacitación propuesto en la estrategia del modelo (Fuente:Autores)
Sugerir una nueva organización para el área de Tecnologias de Información y
Comunicaciones de la empresa Alpha Capital S.A.S, que permita llevar un adecuado
control de las incidencias.
Esta nueva estructura propone implementar la subárea de Mesa de Ayuda, la cual estará
liderado por el Coordinador de Infraestructura y Soporte IT, este nuevo esquema permite
tener a una persona con el perfil indicado para cubrir temas relevantes de la Gestión de
Incidencias y darle el apoyo necesario al coordinador del área.
Proveedores de Servicios
Subgerencia IT
Gererencia de IT & Soporte
Coordinación de Desarrollo
Coordinación de Infraestructura y
Soporte IT
Lenovo Fortinet Microsoft HP Colsof
Gerencia
Subgerencia
Coordinaciones
Mesa de Ayuda
Figura 14 Estructura de la gerencia de Tecnologia Actual. (Fuente: Autores)
71
Cambiar platoforma actual de gestión de incidencias (Freskdesk), por otra que cumpla
con al menos diez (10) procesos de ITIL y pueda cubrir elementos carentes encontrados
en el levantamiento de la situación actual. Se sugiere que sean herramientas clasificadas
por la entidad Pink Elephant, relacionadas a continuación:
Figura 15 Clasificación de Pink Elephant para herramientas de Service Desk (Pink Elephant, 2011)
72
4.2 DISEÑO DE SERVICIO DEL PROCESO
En esta fase se busca diseñar un proceso de Gestión de Incidencias basado en ITIL y COBIT,
para rediseñar los servicios y mejorar la situación actual antes descrita en este trabajo de
investigación.
Identificación de roles para la Gestión de Incidencias
A continuación en la tabla 3 se determinan los roles para el modelo propuesto de Gestión de
Incidencias.
Rol Descripción
Usuario
final
Todas las personas de la organización (areas del negocio y freelace
comercial) que utilizan los servicios de aplicaciones y recursos
informaticos ofrecidos desde el area de Tecnología.
Soporte
primer nivel
Agentes de primer contacto en la línea de soporte que realizan el
diagnostico o solución según sea el caso.
Soporte
segundo nivel
Agentes especializados que se encargan de recibir los casos de
aplicaciones especificas e infraestructura tecnológica.
Soporte
de proveedor
Proveedores de servicios o personas expertas que están subcritos a la
compañía para dar solución en caso de un evento que impacte a los
procesos de la empresa.
Encargado
mesa de ayuda
Será el responsable de la Gestión de Incidencias durante todo el
ciclo de vida en la organización. Asi mismo se encargará del correcto
funcionamiento y el analisis de las metricas del proceso.
Tabla 3 Roles de la Gestión de Incidencias (Fuente:Autores)
73
4.2.2 Definición de Matriz RACI
Con la definición de esta matriz, permitirá aclarar roles operativos, responsabilidades y
relaciones para la Gestión de Incidencias en ALPHACREDIT. Esto proporcionará lo siguiente:
Especificar las actividades por cada rol
Precisar y concertar responsabilidades.
Optimar la comunicación.
Lograr mejorar la atención de incidencias dentro de los tiempos establecidos.
A continuación en la tabla 4 ilustraremos la matriz los roles para el modelo propuesto en la
organización.
Actividades Roles
Usuario
final
Soporte
primer nivel
Soporte
segundo nivel
Soporte
de proveedor
Encargado
mesa de ayuda
Identificación C R A/C/I
Registro,
Clasificación y
Soporte inicial
C R I A/C/I
Investigación,
Diagnóstico C I/R R R A/C/I
Solución,
Recuperación I I/R R R A/C/I
Cierre C R A/C/I
R=Responsable; A=Encargado; C=Consultado; I=Informado
Tabla 4 Matriz RACI para la Gestión de Incidencias (Fuente:Autores)
74
4.2.3 Indicadores propuestos del modelo
Es necesario definir algunos indicadores que permitan medir el nivel de madurez que vaya
adquiriendo el modelo, a continuación se muestra un listado de indicadores propuestos:
Tiempo mínimo de atención de una incidencia en un mes
Tiempo máximo de atención de una incidencia en un mes
Porcentaje de reducción de incidencias
Número total de incidencias comunes.
Total de incidencias agrupados por tipo de prioridad.
Incidencias derivados a equipos de trabajo clasificados por tipo de prioridad.
Cantidad de incidencias agrupados por categoría.
Cantidad de incidencias repetidos solucionados con métodos conocidos.
Número de incidencias que se convirtieron en problemas:
Las métricas mostraran valores que nos permitirán analizar como el modelo propuesto está
impactando en la compañia. Se busca con estas métricas iniciales encontrar una línea base de
indicadores que permitan identificar los ajustes a realizar.
A continuación, se definiran cada uno de los puntos establecidos para los indicadores
propuestos en el modelo:
Tiempo minimo de atención de una incidencia en un mes: Será el promedio del tiempo
minimo de atención de todas las categorías y prioridades que son resueltas en un mes.
Tiempo máximo de atención de una incidencia en un mes: Será el promedio del tiempo
maximo de atención de todas las categorías y prioridades que son resueltas en un mes.
Porcentaje de reducción de incidencias: Será el calculo del procentaje actual
comparado contra el porcentaje inmediamente anterior del total de incidencias
generadas.
75
Número total de incidencias comunes: Será el calculo total de los estados mas
recurrentes en el listado de categorías de toda la gestión de incidencias.
Total de incidencias agrupados por tipo de prioridad: Será el total de incidencias
agrupadas los tipos de prioridades expuestos anteriormente (Critico, Alto, Medio y Bajo).
Incidencias derivados a equipos de trabajo clasificados por tipo de prioridad: Sera la
cantidad de incidencias asignadas a cada uno de los grupos de trabajos y serán
clasificadas pro las prioridades (Critico, Alto, Medio y Bajo).
Cantidad de incidencias agrupados por categoría: Cantidad de incidencias
agrupados por categoría: Será el promedio del tiempo minimo de atención de todas las
categorías y prioridades que son resueltas de forma mensual.
Cantidad de incidencias repetidos solucionados con métodos conocidos: Será la cantidad
de incidencias que han sido agrupadas y que su resolución se basó en una sola acción
técnica.
Número de incidencias que se convirtieron en problemas: Será el numero de
incidencias que luego de una revisión por cada uno de los niveles se categoriza como un
problema que debe ser escalado a un proveedor o fabricante del producto o servicio.
76
4.2.4 Categorización de Incidencias:
Las siguientes categorías son basadas en lo establecido por los estándares COBIT e ITIL,
adicionalmente a la experiencia existente en los procesos de la organización.
Categoría Subcategoria Nivel 1 Nivel 2 Proveedor (*)
Seguridad Antivirus x
Seguridad Firewall x x
Seguridad Acceso de usuarios x
Hardware Computadores x x
Hardware Perifericos x
Hardware Impresoras x x
Software Comerciales x x
Software Open Source x
Comunicaciones Red Local x
Comunicaciones Red Inalambrica x
Comunicaciones Internet x x x
Comunicaciones Telefonia IP x x x
Servidores Aplicaciones x
Servidores Base de datos x
Aplicaciones Optimus x x
Aplicaciones Contpaq x
Aplicaciones Orus x
Aplicaciones AIS x
Tabla 5 Categorias para la Gestión de Incidencias (Fuente:Autores)
77
4.2.5 Niveles de Escalamiento por prioridad
A continuación, se describen los niveles de prioridad propuestos para el modelo de Gestión de
Incidencias basados en lo establecido en los estándares COBIT e ITIL, adicionalmente a la
experiencia existente en los procesos de la organización.
Prioridad Descripción
Prioridad 1 - Crítica
Incidencia de alta prioridad en las funciones críticas de la compañía por
indisponibilidad o degradación excesiva del rendimiento de las
aplicaciones y/o servicios, que requiere solución inmediata. Sin alta
disponiblidad.
Prioridad 2 - Alta
Incidencia de prioridad significativa en alguna de las funciones de la
compañía por indisponibilidad o degradación de rendimiento en las
aplicaciones y/o servicios. El suceso está controlado dado que existe una
alta disponibilidad, por lo tanto no requiere de una solución definitiva
inmediata o los usuarios pueden esperar la restauración del servicio. La
solución definitiva debe estar programada.
Prioridad 3 - Media
Incidencia de prioridad moderada en alguna de las funciones de la
compañia o por degradación ligera del rendimiento de las aplicaciones
y/o servicios. El suceso involucra un número reducido de usuarios
finales afectados. Existe un plan de contingencia y puede esperar la
solución definitiva.
Prioridad 4 – Baja
Incidencia de baja prioridad en las funciones NO críticas del negocio y
el usuario puede esperar a una fecha determinada para la solución
definitiva. El usuario de final puede continuar con sus tareas críticas de
la operación, se mantiene la funcionalidad y el rendimiento de las
aplicaciones y/o servicios.
Tabla 6 Niveles de escalamiento para la Gestión de Incidencias (Fuente:Autores)
78
4.2.6 Definición de tiempos de respuesta inicial y solución definitiva
A continuación, se describen los tiempos de respuesta y solución definitiva por cada una de las
prioridades definidas para el modelo de Gestión de Incidencias basados en lo establecido en los
estándares COBIT e ITIL, adicionalmente a la experiencia existente en los procesos de la
organización.
Prioridad Tiempo de Respuesta Inicial Tiempo de Solución Definitiva
Prioridad 1 - Crítica 75 % de incidencias dentro de 20
minutos 95% de incidencias dentro de 4 horas
Prioridad 2 - Alta 75% de incidencias dentro de 35
minutos
95% de incidencias dentro de 8 horas
Prioridad 3 - Media 75% de incidencias dentro de 9 horas 95% de incidencias dentro de 3 días
hábiles
Prioridad 4 - Baja 75% de incidencias dentro de 1 día hábil 95% de incidencias dentro de 5 días
hábiles
Tabla 7 tiempos de respuesta inicial y solución definitiva(Fuente:Autores)
79
4.3 MODELO PROPUESTO
El modelo propuesto entrega un marco en detalle para la gestión de incidentes, con el propósito
de adaptar las buenas prácticas de ITIL en la organización. El modelo se complementa con
actividades de monitoreo que suplen algunas carencias ante la ausencia de procesos necesarios.
A continuación se describirán las actividades de monitoreo que servirán de soporte al modelo
propuesto.
Figura 16 Resumen de modelo propuesto de la investigación ( Fuente:Autores)
Figura 17 Modelo propuesto de la investigación( Fuente:Autores)
81
4.3.1 Descripción del Proceso de atención de incidencias
En el modelo propuesto de la gestión de incidencias se contemplan todos los canales de
comunicación existentes y proyectados para los usuarios finales en la organización, esto con el
fin de garatizar la cobertuna en toda la organización y mitigar todas las limitantes.
4.3.2.1 Identificación de la Incidencia
El modelo presenta 2 formas de notificar una incidencia:
Portal de incidencias
Correo Electrónico
Las incidencias que llegue por el portal de incidencias o por correo electrónico, tendrán el
mismo SLA, teniendo en cuenta que todas las notificaciones llegaran directamente al mismo
sitio.
El siguiente paso es verificar si es una solicitud de requerimiento, si fuera el caso se deriva a
los responsables de la Gestión de Requerimientos, caso contrario se continúa con el flujo.
Luego se verifica si cumple los niveles de acuerdo de servicio, si fuese el caso se pasa a la
siguiente actividad de registro, caso contrario se le comunica al usuario que regularice la forma
de ingresar la incidencia de acuerdo al SLA. El soporte de primer nivel tendrá que evaluar
varios detalles que permitan una correcta identificación de las incidencias.
83
4.3.2.2 Registro, clasificación y soporte inicial de la incidencia
Las incidencias serán registrados de acuerdo al siguiente formato propuesto en la herramienta:
- Tipo de Incidencia
- Fecha
- Origen de Notificación (correo o plataforma de clientes)
- Nombre del usuario
- Prioridad
- Asignado a
- Estado
- Categoría
- Sub Categoría
- Código de identificación
- Descripción
- Teléfono o celular del usuario
- Email del usuario.
- Indicador relacionado con otro incidente.
- Registro de Cambio de Impacto (Indicar el sentido).
- Indicador de Registro por Excepción del SLA
Dentro de la Priorización de los Incidentes se debe considerar los siguientes parámetros:
Impacto: Determinará la importancia del incidente dependiendo de cómo éste afecta a
los procesos de negocio.
Urgencia: Estará determinado por los tiempos acordados en el SLA (acuerdo de nivel
de servicios).
Las incidencias de fácil resolución deberán ser atendidos inmediatamente. De acuerdo a lo
identificado y acordado con las personas del área de TI, para tener una referencia inicial, la
cual puede ser ajustada de acuerdo a las necesidades de la compañia.
84
Hay que tener presente que la prioridad del incidente puede cambiar durante su ciclo de vida.
Matriz Impacto-Urgencia
3 2 1
4 3 2
5 4 3
Fuente: OGC - ITIL v3, Service Operation, Pág. 51
Con los datos registrados se procederá a verificar si la incidencia presenta casos similares, si
no tuviera ninguna coincidencia se procederá a buscar una solución en la base de datos del
conocimiento, caso contrario se verifica si la incidencia llega a ser un problema (impacto
crítico), si es el caso se deriva al proceso de Gestión de Problemas que se encargará de
determinar detalladamente las causas que lo originan, de otra manera continuará con la
búsqueda de la solución en la BDC (Base de Datos del Conocimiento).
Luego se verifica si existe una solución similar registrada en la base de datos del conocimiento
, si existe la solución para el incidente se procede a verificar si puede ser resuelto en el
presente nivel, si es el caso se pasa a la actividad de ―Solución y Recuperación‖ , de lo
contrario se hará el escalamiento respectivo. En caso sea requerido un escalamiento jerárquico,
se hará a partir del segundo nivel, esto como parte de la regla de negocio del área responsable.
85
4.3.2.3 Proceso de investigación y diagnóstico de la incidencia
A partir de la información recogida del soporte inicial, se buscará reponer el servicio tan
rápido como sea posible, dependiendo del grado de severidad que presente la incidencia. En
caso de que la incidencia no sea resuelto en el primer nivel, se procederá a buscar una
solución en el siguiente nivel técnico de soporte de la compañia considerando a los grupos del
mismo nivel involucrados en la incidencia. En caso de no ser resulto por los grupos del
segundo nivel se procederá a escalar al tercer nivel donde estarían considerados los expertos
y proveedores de servicios. Toda información registrada servirá para obtener indicadores
referentes a los tiempos de investigación y diagnóstico.
4.3.2.4 Solución, Recuperación y Cierre del Incidente
Cuando se haya solucionado la incidencia, se procede a:
Confirmar con los usuarios la solución satisfactoria del mismo.
Incorporar el proceso de resolución al sistema de gestión de conocimiento del
servicio.
Reclasificar el incidente si fuera necesario.
Actualizar la información en la base de datos de gestión de configuraciones (CMDB)
sobre los elementos de configuración (CIs) implicados en la incidencia.
Medir el grado de satisfacción del usuario. En el caso que no sea satisfactoria la
respuesta del usuario se procederá de nuevo con la actividad de Investigación y
Diagnóstico hasta encontrar la solución definitiva para la incidencia.
86
4.3.2.5 Estados de Incidentes del Modelo de Gestión de Incidentes
El modelo propuesto presenta los siguientes estados de incidencias:
Comportamiento incorporados en el flujo
Estado solucionado: En este compartamiento se ha dado una solución parcial o total para la
incidencia, este comportamiento en el modelo propuesto solo aplica para el estado resuelto.
Calcular tiempo: En este compartamiento se hará medición de tiempo de la gestión de los
agentes de la mesa de ayuda, con el fin de tener un indicar de cada paso del flujo, este
comportamiento aplica para los estados registrado, asiginado y en proceso.
Permitir Enrutamiento: En este comportamiento tendrá la posibilidad de cambiar el estado
durante el flujo de una incidencia, con el fin llegar a una efectiva resolución de la misma. Este
comportamiento aplica para los estados registrado, asignado, en proceso y en espera.
Estado Anulado: En este comportamiento la incidencia estará totalmente cerrada, ya sea por
cualquiera de los motivos determinados por el encargo de la mesa de ayuda, este
comportamiento solo aplica para el estado Anulado.
REGISTRADO
ASIGNADO
RESUELTO
CERRADO
FLUJO DE ESTADOS PARA INCIDENTES
EN ESPERA
ANULADO
EN PROCESO
87
ESTADO DESCRIPCIÓN
ESTADO
SOLUCIONADO
CALCULAR
TIEMPO
PERMITIR
ENRUTAMIENTO
ESTADO
ANULADO
Registrado
Estado inicial que se le asigna a
un incidente que ha sido
registrado por el usuario a través
de los diferentes medios. El
incidente contiene información
inicial, por lo tanto el especialista
deberá validar y completar la
misma.
X X
Asignado
Cuando el especialista de la Mesa
de Servicios valida y
complementa la información
mínima requerida para la
atención, el incidente es asignado
a un grupo de soporte para su
gestión.
X X
En Proceso
En este estado se inicia la
ejecución de las actividades
definidas para la gestión del
incidente.
X X
Anulado
Si por algún motivo el incidente
no se puede o no se debe atender,
pasará al estado de ANULADO.
X
En Espera
Si el incidente no puede
desarrollarse por alguna causa
relacionada al usuario, éste pasará
a un estado EN ESPERA.
X
Resuelto Es el estado que se asigna cuando
se ha solucionado el incidente. X
Cerrado
Es el estado que se asigna al
incidente después de que el
especialista de Mesa de Servicios
ha validado con el usuario que
está satisfecho con la solución.
Este es el estado final de un
incidencia.
Tabla 8 Estados de Incidentes Vs Comportamientos del Modelo de Gestión de Incidentes(Fuente:Autores)
88
PARTE III CIERRE DE LA INVESTIGACIÓN
CAPÍTULO 5 RESULTADOS DE ENCUESTAS
Este capitulo tiene como finalidad buscar la opinión de personas que están involucradas en el
proceso de Gestión de Incidencias en distintas empresas y asi mismo pedirle su punto de vista
sobre el modelo de gestión de incidencias propuesto en esta investigación.
La preguntas de la encuenta fueron las siguientes:
Proyecto_Grado_Final_2018_1 (1) (08-05-2018)- 111
89
90
91
92
93
Conclusión de la encuesta: Podemos determinar que el modelo de gestión de incidencias propuesto es
viable para cualquier area de tecnologias que requiera una reorganización de este procedimiento,
adicionalmente con la estandarización ITIL y COBIT permite dar una referencia conceptual significativa
que da la tranquila a cualquier involucrado en el proceso de estar haciendo las cosas de la mejor manera.
Asi mismo, los resultados de la encuesta permiten determinar que para los interesados en el proceso es
importante tener unos indicadores que midan los tiempos en que están siendo resueltas las solicitudes del
área y el tiempo que toma en cada subarea la resolución de la misma.
94
CAPITULO 6 CONCLUSIONES
El conocimiento del Core del negocio se hizo indispensables para lograr un buen análisis
y el estado actual del proceso de gestión de incidencias, ya que gracias a este, se pudo
determinar las verdaderas necesidades y requerimientos que cubren el nuevo modelo de
gestión de incidencias.
Para que el análisis del estado actual del proceso del gestor de incidencias y en si para el
conocimiento real de la situación del área de TI fue imprescindible obtener toda la
disponibilidad y ayuda de los directivos de la organización, sin ello no se puede llegar a
obtener el máximo acercamiento a la realidad y sin ello el resultado obtenido del estudio y la
nueva propuesta del modelo no cumpliría con las expectativas propuestas en la hipótesis
inicial.
El uso de un software, que aparte de ayudar a la gestión de incidencias este enmarcando
dentro de las referencias y las buenas prácticas de Itil ayudara a garantizar la continuidad del
proceso, ya que se puede parametrizar todos los requerimientos que se han de tener en cuenta
como lo dice Itil y COBIT de allí la importancia del estudio de las aplicaciones que cumplen
con este requisito.
Una buena categorización de los incidentes, con sus tiempos de respuestas, definición de
roles, capacitación del modelo obtenido siempre nos llevara una implantación exitosa del
gestor de incidencia, es decir nos ayuda a garantizar la continuidad de los procesos ya que
nos reducen a lo mínimo los tiempos de respuestas en las incidencias pudiendo restablecerse
de forma rápida cualquier proceso involucrado.
La Creación de indicadores, el seguimiento de estos, nos proporciona una
retroalimentación al proceso muy valiosa para la toma de decisiones, son una herramienta
primordial para el proceso y el resultado de estos siempre nos ayudaran al proceso de mejora
continua, dándole a la empresa una ventaja competitiva sobre otras del mismo sector que no
lo tengan contemplado dentro de su plan de negocios, de allí la importancia de la escogencia
de ellos.
Se propuso la encuesta como herramienta de validación de resultados del nuevo modelo
propuesto a profesionales del área involucrados en el proceso de gestión de incidencias el
cual nos convalidan la eficiencia y la ayuda que proporciona el modelo de gestión de
incidencias basado en Itil y Cobit como una herramienta Util para el mejoramiento y el
alcance de las metas propuestas que ratifica la Hipótesis propuesta en este proyecto.
95
BIBLIOGRAFÍA
Baltopoulos, I. G. (2005). Introduction to Web Services. Web Services Related Standards.
Geneve, Switzerland.
BOGOTA, A. (1992). Recuperado el 2016, de alcaldiabogota.gov.co:
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=2107
Date, C. (2001). Introducción a los sistemas de bases de datos. Pearson Prentice Hall.
Dointech. (s.f.). Obtenido de http://www.dointech.com.co/control-acceso-vehicular.html
elevenpaths. (s.f.). http://blog.elevenpaths.com. Obtenido de http://blog.elevenpaths.com:
http://blog.elevenpaths.com/2016/02/gestion-de-incidentes-i.html
Garcia, M. M. (2014). Modelos de proceso del software. Universidad de Salamanca, Salamanca.
Obtenido de http://avellano.usal.es/~mmoreno/ASTema2.pdf
http://www.magazcitum.com.mx/. (s.f.). magazcitum. Obtenido de
http://www.magazcitum.com.mx:
http://www.magazcitum.com.mx/?p=50#.Wq7xoSjwbIU
Huang, J., Gupta, V., & Huang, Y. (2012). Scheduling Algorithms for PHVE Charging in Shared
Parking Lots. American Control Conference.
Ingeniería MCI Ltda. (s.f.). Arduino. Recuperado el 26 de 09 de 2016, de http://arduino.cl/que-
es-arduino/
INTECO. (2004). LA TECNOLOGÍA NFC: APLICACIONES Y GESTIÓN DE SEGURIDAD.
LUZ, F. L. (2013). SISTEMA PARA LA ADMINISTRACIÓN DE UN ESTACIONAMIENTO
PÚBLICO. MEXICO: UNIVERSIDAD NACIONAL AUTÓNOMA DE MEXICO.
magazcitum. (s.f.). http://www.magazcitum.com.mx. Obtenido de
http://www.magazcitum.com.mx:
http://www.magazcitum.com.mx/?p=50#.WrnTXojwbIU
Molina, M. (s.f.). http://www.marlonmolina.com. Obtenido de http://www.marlonmolina.com:
http://www.marlonmolina.com/2011/04/
OCDE. (2015). Perspectivas de la OCDE sobre la economía digital 2015. Paris.
Perez, D. R. (2016). Implementación de un prototipo para la gestión de parqueaderos en la
universidad de las Americas. Santiago, Chile.
96
Pupiales, P. W. (2009). Diseno de un Sistema de Control de Acceso utilizando la tecnologia de
Identificacion RFID para la empresa soluciones G Cuatro del Ecuador CIA. LTDA.
Quito: Escuela Politecnica Nacional.
Ramos, A., Sánchez, P., Ferrer, J., Barquín, J., & Linares, P. (2010). Modelos Matemáticos de
Optimización. Madrid.
Ribas Lequerica, J. (2003). Web Services (edición especial).
Robinson, R. (1999). Welcome to or Territory OR MS Today.
Sandoval, R. (26 de Abril de 2016). Linkedin. Obtenido de https://www.linkedin.com/pulse/para-
que-sirve-un-sistema-de-control-acceso-rovillel-sandoval
Semana. (2015). Colombia, el país de los ‗smartphones‘. Semana.
servicetonic. (s.f.). https://www.servicetonic.es. Obtenido de https://www.servicetonic.es:
https://www.servicetonic.es/itil/itil-v3-gestion-de-incidencias/
Tarjetas Inteligentes. (s.f.). Negocios de Seguridad.
Tatiana Naranjo, J. M. (4 de Marzo de 2009). Obtenido de http://server-
die.alc.upv.es/asignaturas/PAEEES/2008-09/Sensor%20Infrarrojo%20-
%20Grupo%20Naranja.pdf
Torrente Artero, O. (2013). ARDUINO Curso práctico de formación. Ciudad de México: Alfa
Omega Grupo Editor.
Universidad de Chile. (s.f.). http://repositorio.uchile.cl. Obtenido de http://repositorio.uchile.cl:
http://repositorio.uchile.cl/tesis/uchile/2006/donoso_f/sources/donoso_f.pdf
Universidad Distrital "Francisco José de Caldas". (26 de marzo de 1999). SISGRAL. Obtenido
de Sistema de Información de Secretaría General - UD:
https://sgral.udistrital.edu.co/xdata/sisgral.php?qry=on&id_doc=2143
Universidad Distrital "Francisco José de Caldas". (29 de julio de 2002). SISGRAL. Obtenido de
Sistema de Información de Secretaría General - UD:
http://sgral.udistrital.edu.co/xdata/rec/res_2002-1101.pdf
Universidad Distrital "Francisco José de Caldas". (23 de marzo de 2010). SISGRAL. Obtenido
de Sistema de Información de Secretaría General - UD:
http://sgral.udistrital.edu.co/xdata/sisgral.php?qry=on&id_doc=5520
97
Universidad rey Juan Carlos. (s.f.). https://eciencia.urjc.es. Obtenido de https://eciencia.urjc.es:
https://eciencia.urjc.es/bitstream/handle/10115/11616/Memoria%20PFC.pdf?sequence=1
&isAllowed=y
VENKATARAMANAN, M., & BORNSTEIN, M. (1991). A DECISION SUPPORT SYSTEM
FOR PARKING SPACE ASSIGNMENT. MATHL COMPUT MODELING. págs. 71-
76.
Vilanoveta, P. I. (2015). Tecnología NFC, modalidades operativas y aspectos técnicos. FQ
Ingenieria Electronica. Obtenido de
http://www.fqingenieria.com/es/conocimiento/tecnologia-nfc-modalidades-operativas-y-
aspectos-tecnicos-47
Villegas, J. (22 de Febrero de 2009). TECNOSeguro. Obtenido de
https://www.tecnoseguro.com/faqs/control-de-acceso/%C2%BF-que-es-un-control-de-
acceso.html
wiki. (s.f.). https://wiki.es.it-processmaps.com/. Obtenido de https://wiki.es.it-processmaps.com/:
https://wiki.es.it-processmaps.com/index.php/ITIL_Operaci%C3%B3n_del_Servicio
