UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS
Y MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
ANÁLISIS Y DISEÑO DEL PROCESO DE INCIDENTES Y
PROBLEMAS EN LA EMPRESA “ATIJAGUAR” UTILIZANDO
COMO MARCO DE REFERENCIA ITIL Y COBIT
TRABAJO DE GRADUACIÓN PREVIO LA OBTENCIÓN DEL TÍTULO DE
INGENIERO INFORMÁTICO
AUTOR: Carvajal Carrillo Mónica Fernanda
TUTOR: Ing. Rosas Lara Mauro Leonardo
Quito-Ecuador
2015
ii
DEDICATORIA
Ser mamá y estar en proceso de elaborar una tesis, es difícil porque sabes que alguien
más se está sacrificando para que tú puedas lograr tu sueño, por eso gracias Camila
por tu amor y comprensión te amo hija.
Mami, gracias por tu apoyo incondicional eres la mejor.
A todos los que de una u otra forma estuvieron siempre apoyándome, mil gracias.
iii
AGRADECIMIENTO
A mi tutor Ing. Mauro Rosas por guiarme en el desarrollo de ésta tesis, al Ing. Jairo
Navarro y al Mat. Jorge Lara gracias por los aportes, conocimiento, experiencia y su
motivación han logrado en mi culminar con éxito ésta tesis.
Agradezco a todos los Ingenieros que forman parte de la Escuela de Ingeniería
Informática, por todo el conocimiento impartido.
iv
v
vi
INFORME SOBRE LA CONCLUSIÓN DEL TRABAJO DE
GRADUACIÓN
“ANÁLISIS Y DISEÑO DEL PROCESO DE INCIDENTES Y PROBLEMAS
EN LA EMPRESA “ATIJAGUAR” UTILIZANDO COMO MARCO DE
REFERENCIA ITIL Y COBIT”
1.- Antecedentes
Con el oficio 251-2014-DC del 20 de agosto 2015, el Director de la Carrera de
Ingeniería de Informática designa al Ing. Mauro Leonardo Rosas Lara, que en
calidad de TUTOR, analice, dirija y oriente el trabajo de graduación titulado
“ANÁLISIS Y DISEÑO DE EL PROCESO DE INCIDENTES Y PROBLEMAS DE
LA EMPRESA ATIjguarUTILIZANDO COMO MARCO DE REFERENCIA ITIL
y COBIT”, presentado por la Señora Mónica Fernanda Carvajal Carrillo con el
objetivo de tener obtener el título Ingeniera Informática, y que emitan un informe
sobre la ejecución del mismo a su finalización.
2.- Desarrollo del Trabajo de Graduación
Para dar cumplimiento al anterior oficio mencionado se procedió a revisar el avance
de la ejecución del trabajo, posteriormente el graduado realizó bajo mi supervisión
las siguientes actividades:
Se cumplió con las horas de tutoría, planificadas con la mencionada alumna
con reuniones.
Revisión de los distintos capítulos que conforman esta tesis.
Seguimiento de la metodología desarrollada en el plan de tesis.
Revisión del Certificado de conformidad brindado por la Empresa para quien
se realizó la mencionada tesis.
vii
viii
NOTAS DE REVISORES
ix
CONTENIDO
Contenido DEDICATORIA ............................................................................................................................ii
AGRADECIMIENTO ................................................................................................................... iii
INFORME SOBRE LA CONCLUSIÓN DEL TRABAJO DE GRADUACIÓN ....................................... vi
NOTAS DE REVISORES ............................................................................................................ viii
LISTA DE CUADROS .................................................................................................................. xi
LISTA DE GRÁFICOS ................................................................................................................ xiv
RESUMEN ................................................................................................................................ xv
ABSTRACT ....................................................................................................................... xvi
INTRODUCCIÓN ................................................................................................................ 1
CAPÌTULO 1 ...................................................................................................................... 2
1. PRESENTACION DEL PROBLEMA ..................................................................... 2
1.2. Objetivos. ................................................................................................................ 3
1.3. Alcance del Proyecto .............................................................................................. 3
1.4. Limitaciones ............................................................................................................ 4
1.5. Comparación de ITIL V3 vs. ITIL V3 actualización 2011 ................................. 5
CAPITULO 2 .................................................................................................................... 20
2. METODOLOGÍA .................................................................................................... 20
2.1. Antecedente ........................................................................................................... 20
2.2. Método de Análisis ............................................................................................... 20
Estructura lógica.- Los integrantes del Centro de Servicios deben: .................... 24
Estructura física.- Dependiendo de las necesidades de servicio: locales, globales,
24/7,...se debe de optar por una estructura diferente para el Centro de Servicios.......... 24
2.3. Método Estadístico ............................................................................................... 40
2.4. Técnicas de Investigación .................................................................................... 40
CAPITULO 3 .................................................................................................................... 41
3. ELABORACIÓN DEL DISEÑO DEL CENTRO DE SERVICIOS EN EL
ÁREA DE TECNOLOGÍA DE LA INFORMACIÓN DE LA EMPRESA ATIjaguar
41
3.1. Filosofía Empresarial ........................................................................................... 41
3.2. Estructura Organizacional .................................................................................. 42
x
3.3. Diseño de la Solución Centro de Servicio en la Empresa ATIjaguar utilizando
como marco de referencia ITIL V3 actualización 2011 y COBIT 5.0 ......................... 52
3.4. Lineamientos para la implementación de un Centro de Servicios................... 95
CAPITULO 4 ....................................................................................................................... 116
4. CONCLUSIONES Y RECOMENDACIONES ................................................... 116
4.1. Conclusiones ....................................................................................................... 116
4.2. Recomendaciones ............................................................................................... 116
xi
LISTA DE CUADROS
Tabla 1. Resumen global de la actualización
Tabla 2. Resumen de la actualización del libro Estrategia del Servicio
Tabla 3. Resumen de la actualización del libro Diseño del Servicio
Tabla 3. Resumen de la actualización del libro Diseño del Servicio
Tabla 4. Resumen de la actualización del libro Transición del Servicio
Tabla 5. Resumen de la actualización del libro Operación del Servicio
Tabla 6. Resumen de la actualización del libro Mejora Continua del Servicio
Tabla 7. Nuevos Principios
Tabla 8. Nuevo Modelo de Referencia de Procesos
Tabla 9. Procesos Nuevos y Modificados
Tabla 10. Objetivos y Métricas
Tabla 11. Entradas y Salidas
Tabla 12. Cuadros RACI
Tabla 13. Gerencia de TI
Tabla 14. Asistente Técnico de TI
Tabla 15. Área de Administración de Aplicativos
Tabla 16. Área de Administración de Aplicativos
Tabla 17. Área de Administración de Aplicativos
Tabla 18. Área de Administración de Redes y Comunicaciones
Tabla 19. Área de Administración de Redes y Comunicaciones
Tabla 20. Área de Administración de Base de Datos
Tabla 21. Área de Administración de Base de Datos
Tabla 22. Servicios Tecnológicos por el Área de TI
Tabla 23. Tabla de Servicio
Tabla 24. Roles Gestión de Incidentes
Tabla 25. Procedimiento para la investigación y diagnóstico de incidentes
xii
Tabla 26. Procedimiento para la resolución y recuperación de un incidente.
Tabla 27. Procedimiento para el cierre de incidentes
Tabla 28. Matriz RACI para Gestión de Incidentes
Tabla 29. Registro incidente
Tabla 30. Tipos de Solicitud
Tabla 31. Categorización
Tabla 32. Criterios para el establecimiento del impacto de un incidente
Tabla 33. Criterios para el establecimiento de la urgencia de un incidente
Tabla 35. Matriz de asignación de prioridades y tiempo de resolución promedio a
solicitudes.
Tabla 36. Servicios, Tiempo de respuesta y Prioridad
Tabla 40. Roles de Gestión de Problemas
Tabla 41. Matriz RACI para Gestión de Problemas
Tabla 42. Procedimiento para detectar, registrar y categorizar el problema
Tabla 43. Registro de Problema
Tabla 44. Procedimiento para priorizar problemas
Tabla 45. Procedimiento para investigar y diagnosticar el problema
Tabla 46. Procedimiento para Levantar registro de Error Conocido
Tabla 47. Procedimiento para la Resolución y Cierre del problema
Tabla 48. Niveles de soporte para atención de solicitudes de servicio
Tabla 49. Tipo de Solicitudes al Centro de Servicio
Tabla 50. Roles del Centro de Servicio
Tabla 51. Matriz RACI para el Centro de Servicios
xiii
Tabla 52. Actividades del Centro de Servicio
Tabla 53. Procedimiento para la asignación de un caso
Tabla 54. Criterios de clasificación de casos para definición
Tabla 55. Procedimiento para el escalamiento de casos
Tabla 56. Procedimiento para el monitoreo de acuerdos de nivel de servicio (SLA).
Tabla 57. Procedimiento para el monitoreo de OLA‟s o UC‟s
Tabla 58. Procedimiento para el cierre de caso
xiv
LISTA DE GRÁFICOS
Ilustración 2. Procesos oficiales ITIL edición 2011
Ilustración 3. Áreas de Cambio
Ilustración 4. Mayor Foco en Facilitadores
Ilustración 1. Mapeo de ITIL v3 con COBIT 4.1
Ilustración 6. Ciclo de Vida del Servicio
Ilustración 7. Interfaces de la Gestión de Incidentes
Ilustración 8. Evolución de COBIT
Ilustración 9. Familia de Productos COBIT 5
Ilustración 10. Principios de COBIT 5
Ilustración 11. Procesos Habilitadores
Ilustración 12. Las 7 Fases de la Implementación del Ciclo de Vida
Ilustración 13. Estructura Organizacional de la Empresa ATIjaguar
Ilustración 14. Procedimiento para la investigación y diagnóstico de incidentes
Ilustración 15. Procedimiento para la resolución y recuperación de un incidente.
Ilustración 16. procedimiento para el cierre de incidentes.
Ilustración 17. Procedimiento para detectar, registrar y categorizar problemas
Ilustración 18. Procedimiento para priorizar problemas
Ilustración 19. Procedimiento para investigar y diagnosticar el problema
Ilustración 20. Procedimiento para Levantar registro de Error Conocido
Ilustración 21. Procedimiento para la Resolución y Cierre del problema
Ilustración 22. Procedimiento para la recepción y registro de caso
Ilustración 23. Asignación de caso
Ilustración 24. Escalamiento de casos
Ilustración 25. Monitoreo de SLA.
Ilustración 26. Procedimiento manejo de quejas.
Ilustración 27. Procedimiento cierre de casos
xv
RESUMEN
ANÁLISIS Y DISEÑO DE LOS PROCESOS DE INCIDENTES Y PROBLEMAS
DE LA EMPRESA “ATIjaguar” UTILIZANDO COMO MARCO DE
REFERENCIA ITIL Y COBIT
Esta tesis tiene como objetivo realizar el análisis y diseño de los procesos de
Incidentes y Problemas de la empresa ATIjaguar utilizando como referencia ITIL V3
actualización 2011 y COBIT 5.0.
Para esto se analizará, desarrollará y documentara el modelo del Centro de Servicios
basados en los diseños de los procesos de Gestión de Incidentes y Gestión de
Problemas, detallando sus fases, entradas y salidas, actividades roles y
responsabilidades, matriz RACI, procedimientos para el registro, diagnóstico y cierre
de incidentes y problemas, además se realizará la documentación de los servicios de
la empresa, tiempos de respuesta y prioridad de los servicios.
El Centro de Servicios sería el primer paso para entrar en el concepto de mejora
continua de ITIL, y con COBIT ayudará a la empresa a crear el valor óptimo,
manteniendo el equilibrio entre la generación de beneficios y la optimización de los
niveles de riesgo.
DESCRIPTORES
PROCESOS ITIL/ PROCESOS COBIT/ SERVICIO ITIL/ SERVICIO
COBIT/ MEJORA CONTINUA ITIL/ ROLES ITIL
xvi
ABSTRACT
ANALYSIS AND DESIGN OF PROCESSES INCIDENTS AND PROBLEMS OF
THE COMPANY "ATIjaguar" USING AS A REFERENCE FRAMEWORK ITIL
and COBIT
The objective of this thesis is to analyze and design the processes of incidents and
problems in the ITjaguarcompany using as reference ITIL V3 update 2011 and
COBIT 5.0.
To do this, it is necessary to develop and document the Service Center Model, based
on the designs of the processes of Incident Management and Problem Management,
by detailing the phases, inputs and outputs, activities, roles and responsibilities,
RACI matrix, registration procedures, diagnosis and closure of incidents and
problems, as well as the documentation of the company services, response times end
services priorities.
The Service Center will be the first step to enter the ITIL Continual Service
Improvement, and using COBIT help to create optimum value of the company,
mantaining a balance between generating profits and optimizing risk levels.
DESCRIPTORS
PROCESSES ITIL / PROCESSES COBIT / ITIL SERVICE / SERVICE COBIT /
ITIL CONTINUOUS IMPROVEMENT / ROLES ITIL
xvii
CERTIFICACIÓN
A petición de Mónica Fernanda Carvajal Carrillo con CC. 1715798334. Yo, Paola
Salomé Ponce Campana con el título de Licenciado en Ciencias de la Educación
mención: Inglés otorgado por la Universidad Técnica Particular de Loja, he realizado
la traducción del resumen de trabajo de graduación sobre el tema:
“ANÁLISIS Y DISEÑO DEL PROCESO DE INCIDENTES Y PROBLEMAS
DE LA EMPRESA ATIJAGUAR UTILIZANDO COMO MARCO DE
REFERENCIA ITIL Y COBIT”
Dado que poseo los conocimientos necesarios para realizar dicho trabajo y certifico
lo mencionado con el documento adjunto-
Quito, 14 de mayo 2015.
Atentamente
Paola Salomé Ponce Campana
CC. 1721106373
xviii
1
INTRODUCCIÓN
ITIL1 “fue desarrollada al reconocer que las organizaciones dependen cada
vez más de la Informática para alcanzar sus objetivos corporativos. Esta dependencia
en aumento ha dado como resultado una necesidad creciente de servicios
informáticos de calidad que se correspondan con los objetivos del negocio, y que
satisfagan los requisitos y las expectativas del cliente”. Con este pensamiento
podemos deducir que la adecuada gestión de las Tecnologías de la Información
promueve a una empresa mayores oportunidades de desarrollo, competitividad y
mayor capacidad de alcanzar sus objetivos como negocio.
Se pretende diseñar los procesos de Gestión de Incidentes y Problemas
considerando que este es un primer paso que se realiza para entrar en el concepto de
mejora continua planteado por ITIL.
1ITIL(InformationTechnologyInfraestructureInformation)(Biblioteca de Infraestructura de Tecnología
de la Información)
2
CAPÌTULO 1
1. PRESENTACION DEL PROBLEMA
1.1. Antecedentes.
La empresa Aplicaciones Tecnológicas Inteligentes ATIjaguarCia. Ltda., la
cual está situada en la ciudad de Quito es una empresa que crea soluciones y
servicios informáticos.
ATIjaguar cuenta con el área de tecnología de la información, cuya misión es
la de gestionar todos los recursos tecnológicos, garantizando la entrega de
servicios de calidad.
Actualmente el área no cuenta con procesos y procedimientos acordados con
sus usuarios finales y por tanto sus requerimientos no están formalmente
aprobados de tal manera que permitan dar seguimiento al soporte técnico que
brindan, y debido a esto se tiene una baja disponibilidad de los servicios
prestados.
Bajo demanda de la gerencia de TI, se establece este proyecto de tesis, el
requerimiento del diseño del Centro de Servicios, apoyados en los procesos
de Gestión de Incidentes y Problemas basados en el marco de teórico de ITIL
V3 actualización 2011 y COBIT 5. La implementación de los demás procesos
que menciona ITIL, serán contemplados en una futura oportunidad.
3
1.2. Objetivos.
1.2.1. Objetivo General
Analizar y diseñar los procesos de Incidentes y Problemas en la Empresa
“ATIjaguar” utilizando como marco de referencia ITIL V3 actualización
2011 y COBIT5.0.
1.2.2. Objetivos Específicos
Diagnosticar y analizar la información obtenida de la situación actual
de la Empresa.
Plantear un diseño con sus respectivos procedimientos para la gestión
de TI, basados en las mejores prácticas de ITIL V3 actualización
2011.
Diseñar un Centro de Servicios únicamente con los procesos de
Incidentes y Problemas.
1.3. Alcance del Proyecto
Para la elaboración de los diseños de Gestión de Incidentes y Problemas se
tomará como fundamento de trabajo ITIL V3 actualización 2011, utilizando
esta guía como mejores prácticas para la gestión de servicio, además de
utilizar COBIT 5.
Se analizará, desarrollará y documentara el modelo del Centro de Servicios
basados los diseños de los procesos de Gestión de Incidentes y Gestión de
Problemas, detallando sus fases, entradas y salidas, actividades roles y
responsabilidades, matriz RACI, procedimientos para el registro, diagnóstico
y cierre de incidentes y problemas, se realizo documentación de los servicios
4
de la empresa, además de tiempos de respuesta y prioridad de los servicios,
para escoger la versión más adecuada tanto de ITIL y COBIT se realizo una
comparación entre las versiones de cada uno de ellos con la finalidad de
escoger la más adecuada. En el caso de ITIL la comparación fue entre la
Versión 3 y la Versión 3 actualización 2011, COBIT se hizo la comparación
entre la Versión 4.1 y la Versión 5.0. Esta comparación se la puede ver en el
inciso 1.5.
1.4. Limitaciones
En este trabajo solo tomamos en cuenta los procesos de Gestión de Incidentes
y Problemas tanto para el estudio como para el análisis y diseño, a pesar de
que en una mesa de ayuda intervienen más procesos. Cabe destacar los
procesos que no se tomaron en cuenta para esta tesis los citaremos a
continuación:
Estrategia.- Gestión Financiera, Gestión de Portafolio de Servicios, Gestión
de la Demanda.
Diseño.- Gestión de Catálogo de Servicios, Gestión de Niveles de Servicio,
Gestión de la Disponibilidad, Gestión de la Continuidad de los Servicio TI,
Gestión de la Seguridad de la Información, Gestión de Proveedores, Gestión
de Capacidad.
Transición.- Planificación y soporte a la Transición, Gestión de Cambios,
Gestión de Configuración y Activos de Servicio, Gestión de Entregas y
Despliegues, Validación y Pruebas, Evaluación, Gestión de Conocimiento
Operación.- Gestión de Eventos, Petición de Servicios, Gestión de Acceso a
los Servicios.
5
Mejora.- Procesos de Mejora, Informes de Servicio TI.
1.5. Comparación de ITIL V3 vs. ITIL V3 actualización 2011
Debido al sinnúmero de errores presentados en la edición 2007 de los libros
de ITIL, en septiembre del 2009 tomaron la decisión de actualizar los libros
centrales considerando tres aspectos fundamentales:
1. Inconsistencias planteadas en el registro de control de cambios.
2. Asesoría del Comité de Cambios.
3. Retroalimentación por parte de la comunidad de capacitación.
El proyecto estuvo enfocado en todo momento en corregir errores, eliminar
inconsistencias así como mejorar la claridad y estructura de los libros
(Corona, 2011, pág. 3).
6
Ilustración 2. Procesos oficiales ITIL edición 2011
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio
Corona
Fuente:http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-
conceptos-de-itil-ed-2011
Cambios Generales
Entre los cambios generales los más destacados son los siguientes, que se
muestran en la Tabla 1. :
Área de
Actualización
Descripción
Capítulo 6
Identifica los roles y responsabilidades organizacionales que
deberían estar considerados para manejar cada una de las fases del
ciclo de vida del servicio. Incluye los roles genéricos,
responsabilidades y competencias que aplican a lo largo del ciclo de
vida del servicio y los aspectos específicos de los procesos descritos
en cada publicación.
Roles
En esta edición se clarifican los roles y cuentan con una mayor
consistencia asegurando que las actividades aplican a un solo rol.
7
Estructura de
los Procesos
A todos los procesos se les ha dado un tratamiento en común,
asegurando que cada uno tiene un propósito y conjunto de objetivos,
alcance, valor al negocio, políticas, principios y conceptos básicos,
actividades del proceso, métodos y técnicas, disparadores, entradas,
salidas e interfaces, información gerencial, factores críticos de éxito,
indicadores clave de desempeño, retos y riesgos
No más
gerente del
producto
Todas las referencias hacia el gerente del producto se han
remplazado por dueño del servicio
Tabla 1. Resumen global de la actualización
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona
Fuente: http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-conceptos-de-
itil-ed-2011
Cambios al libro de Estrategia de Servicio
Entre los cambios generales los más destacados son los siguientes, que se
muestran en la Tabla 2. :
Área de
Actualización
Descripción
Procesos
Se definieron y nombraron claramente los procesos: Gestión de la
Estrategia para los Servicios de TI, Gestión del Portafolio de
Servicios, Gestión Financiera de Servicios de TI, Gestión de la
Demanda y Gestión de Relaciones con el Negocio
Estrategia del
Negocio y
Estrategia de TI
Ahora estos son 2 conceptos diferentes por lo que se describen de
manera separada y explican las relaciones entre los dos; la estrategia
del negocio define la estrategia de TI y la estrategia de TI soporta la
8
estrategia del negocio
Creación de
Valor
Se provee una mayor clarificación respecto a cómo los servicios
agregan y logran valor. Se incluyeron nuevos conceptos para
describir cómo se crea el valor y como diferenciar el valor agregado
y valor realizado. Se incluyó una nueva tabla que provee ejemplos de
utilidad y garantía
Gestión de la
Estrategia para
los Servicios de
TI
Este nuevo proceso es responsable de desarrollar y mantener las
estrategias de TI alineadas a las del negocio (más no las del negocio)
Gobierno
Ahora existe más detalle sobre el concepto de Gobierno, incluyendo
una definición de lo que significa el gobierno o gobernanza y la
gestión como tal, el marco de referencia de gobierno y cómo la
gestión de servicios se relaciona con el gobierno
Cómputo en la
Nube
Se agregaron algunos comentarios respecto a cómo la gestión de
servicios es impactada por la relevancia de esta tendencia mundial y
se agregó un nuevo apéndice específicamente cubriendo la estrategia
del servicio y la nube como lo son: características, tipos, tipos de
servicio y componentes de la arquitectura de la nube
Tipos de
Implementación
de la Gestión de
Servicios
Se han agregado algunos tipos de implementación como lo son
„evenkeel‟ que no es más que un modismo para demostrar un balance
adecuado, problema, crecimiento y cambio radical
9
Tabla 2. Resumen de la actualización del libro Estrategia del Servicio
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona
Fuente: http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-conceptos-de-
itil-ed-2011
Cambios al libro de Diseño de Servicio
Entre los cambios generales los más destacados son los siguientes, que se
muestran en la Tabla 3. :
Área de
Actualización
Descripción
Procesos
Se definieron y nombraron claramente los procesos: Coordinación
del Diseño, Gestión del Catálogo de Servicios, Gestión de Niveles de
servicio, Gestión de Disponibilidad, Gestión de Capacidad, Gestión
de Continuidad de Servicios de TI, Gestión de Seguridad de la
Información, Gestión de Proveedores
Transición de un
Servicio desde los
Servicios
Potenciales hasta el
Catálogo con
Servicios retirados
Se clarificaron los puntos de transición entre la Estrategia del
Servicio y el Diseño del Servicio así como los lugares adecuados
para el establecimiento de políticas
Proceso de
Coordinación del
Diseño
Se agregó este proceso con la finalidad de clarificar el flujo de la
actividad en la fase del ciclo de vida del Diseño
Terminología del
Catálogo de
Se revisó el lenguaje utilizado para referirse al catálogo de servicios
relacionados con las vistas del cliente y la vista técnica de los
10
Servicios servicios de TI
Tabla 3. Resumen de la actualización del libro Diseño del Servicio
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona
Fuente: http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-conceptos-de-
itil-ed-2011
Cambios al libro de Transición del Servicio
Entre los cambios generales los más destacados son los siguientes, que se
muestran en la Tabla 4. :
Área de
Actualización
Descripción
Procesos
Se definieron y nombraron claramente los procesos: Planeación y
Soporte a la Transición, Gestión de Cambios, Gestión de Activos de
Servicio y Configuraciones, Gestión de Liberaciones e
Implementaciones, Validación y Pruebas del Servicio, Evaluación
del Cambio, Gestión del Conocimiento
Gestión de Cambios
Se modificó el diagrama de flujo de alto nivel y los títulos de la
sección para generar mayor consistencia entre los mismos
Registro de
Configuración,
Elemento de
Configuración (CI),
CMS, SKMS
Se clarificaron todos estos conceptos con la finalidad de evitar
ambigüedades existentes en las versiones anteriores
Evaluación
El nombre del proceso se cambió por „Evaluación del Cambio‟ y se
clarificaron el alcance y el propósito
11
Gestión de Activos
de Servicio y
Configuraciones
Se agregaron diferentes conceptos para explicar aspectos de la
gestión de servicios de una mejor manera
Tabla 4. Resumen de la actualización del libro Transición del Servicio
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona
Fuente: http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-conceptos-de-
itil-ed-2011
Cambios al libro Operación de Servicio
Entre los cambios generales los más destacados son los siguientes, que se
muestran en la Tabla 5. :
Área de
Actualización
Descripción
Procesos
Se definieron y nombraron claramente los procesos: Gestión de
Eventos, Gestión de Incidentes, Cumplimiento de Solicitudes,
Gestión de Problemas, Gestión de Accesos
Solicitud de
Servicio
El concepto se ha mejorado de manera significativa para proveer una
definición más clara incluyendo ejemplos y diagramas para ilustrar
cómo las solicitudes de servicio se ligan con los servicios que
soportan. Se resalta la relación entre las solicitudes de servicio,
modelos de solicitud y cambio estándar
Modelo de Solicitud
Se expandió este concepto con la finalidad de clarificar cómo cada
solicitud de servicio debe ser ligada a un modelo de solicitud que
documente los pasos y tareas, así como los roles y responsabilidades
necesarios para cumplir con la solicitud
12
„Matching‟ de
Incidentes
Se agregó un procedimiento que provee ejemplos respecto a cómo
los incidentes deberían ser comparados contra los registros de error
conocido entes de escalarlos. Se proporciona un flujo detallado para
comparar incidentes y escalarlos a Gestión de Problemas
Flujo del Proceso de
Cumplimiento de
Solicitudes
Se integró un nuevo flujo del proceso que muestra un conjunto de
actividades y pasos sugeridos para llevar a cabo este proceso.
También incluye puntos de decisión para escalar solicitudes a la
Transición del Servicio como propuestas de cambio o a la Gestión de
Incidentes como incidentes.
Técnicas de
Análisis de
Problemas
Se incluyen más técnicas para encontrar la causa raíz de los
problemas. Adicionalmente cada técnica indica los tipos de
situaciones e incidentes donde puede resultar ventajoso usar una
técnica particular
Investigación y
Análisis de
Problemas
Se agregó un concepto para recrear problemas cuando estos están
siendo investigados
Gestión de
Servidores y
Mainframes
El concepto de que las actividades y procedimientos para administrar
mainframes no precisamente son diferentes de la de servidores se ha
agregado. El cómo estás actividades deben ser ejecutadas puede
cambiar, pero los resultados y tipos de tareas de gestión son
esencialmente las mismas
Gestión Proactiva
de Problemas
Se agregó el concepto y descripción de estas actividades
13
Gestión de
Aplicaciones vs.
Desarrollo de
Aplicaciones
Se clarifican las diferencias de estas dos actividades. Se agregó un
diagrama para mostrar las actividades clave que forman parte durante
cada fase del ciclo de vida de la Gestión de Aplicaciones para
mostrar la diferencia entre dichas actividades.
Gestión de
Instalaciones
Se modificó y mejoró considerablemente este apéndice
Tabla 5. Resumen de la actualización del libro Operación del Servicio
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona
Fuente: http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-conceptos-de-
itil-ed-2011
Cambios al libro Mejora Continua del Servicio
Entre los cambios generales los más destacados son los siguientes, que se
muestran en la Tabla 6. :
Área de
Actualización
Descripción
Introducción al
registro de CSI
Este registro contendrá todas las oportunidades de mejora. Cada
oportunidad deberá ser categorizada como menor, mediana o grande.
Se deberá colocar también la cantidad de tiempo estimado para llevar
a cabo la iniciativa de mejora junto con los beneficios asociados.
Toda esta información ayudará a producir una lista clara de
prioridades en las iniciativas. Se provee una descripción completa del
registro de CSI dentro del capítulo 3 y se agregan ejemplos en el
apéndice C.
14
Medición del
Servicio y Reporte
del Servicio
Se clarificó el tratamiento que se le da a estos dos conceptos. Debido
a que todos los procesos tienen un elemento de medición y reporte
embebido dentro de los mismos, estos dos aspectos NO SON
CONSIDERADOS COMO PROCESOS
Proceso de Mejora
de los 7 pasos
Se clarifica que este proceso solo tiene 7 pasos. Algunos nombres de
pasos y actividades se modificaron, pero el propósito general del
proceso se ha mantenido sin cambios. Se han clarificado las
interfaces con el ciclo de Deming y el proceso de Gestión del
Conocimiento
El enfoque de CSI
Se renombró el modelo de CSI por el enfoque de CSI ya que este es
un enfoque de la mejora continua, más no un modelo.
Tabla 6. Resumen de la actualización del libro Mejora Continua del Servicio
Autor: Mauricio Corona. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona
Fuente: http://es.slideshare.net/mccmcculsa/dr-itil-presentando-los-conceptos-de-
itil-ed-2011
De acuerdo a Mauricio Corona (2011), se puede observar que se hicieron
varias modificaciones a lo largo de los cinco libros que representan el ciclo de
mejora continua del servicio.
Por esta razón y para efectos de aplicación del marco de trabajo ITIL en el
desarrollo de este proyecto de tesis, se tomo como guía la versión 3
actualización 2011.
15
Comparación de COBIT 4.1 vs. COBIT 5.0
Áreas de Cambio
Ilustración 3. Áreas de Cambio
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente: http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
Nuevos Principios
Val IT y Risk IT son marcos de trabajo basados en principios, los cuales son
fáciles de entender y aplicarlos al contexto empresario, permitiendo derivar
valor de las guías de soporte más efectivamente. ISO/IEC 38500 incorpora
principios para potenciar sus mensajes, los cuales no son los mismos que
COBIT 5 2
Tabla 7. Nuevos Principios
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de Carlos
Francavilla
Fuente:http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-con-
COBIT-41
2Carlos Francavilla. (2012). Comparación de COBIT4.1 . mayo, de Carlos Francavilla Sitio web:
http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-con-COBIT-41
16
Mayor Foco en Facilitadores
Ilustración 4. Mayor Foco en Facilitadores
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente: http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
Nuevo Modelo de Referencia de Procesos
COBIT 5 El Nuevo Modelo puede utilizarse como una guía para ajustar el
propio modelo de procesos de la empresa como sea necesario 3
Está basado en:
Un nuevo Modelo de Referencia de procesos
Un nuevo Dominio de Gobierno
Varios Procesos Nuevos y Modificados que cubren la
3Carlos Francavilla. (2012). Comparación de COBIT4.1 . mayo, de Carlos Francavilla Sitio web:
http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-con-COBIT-41
17
empresa de extremo a extremo
Funciones de TI y Negocio
Tabla 8. Nuevo Modelo de Referencia de Procesos
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente:http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
Procesos Nuevos y Modificados
COBIT 5 introduce 5 nuevos procesos de Gobierno aplacando y mejorando
COBIT 4.1
Val IT 2.0
Risk IT
COBIT 5 ha clarificado los procesos del nivel de Gestión .
Ahora cubren la empresa de extremo a extremo y las
actividades de TI
Una visión completa de la empresa
Tabla 9. Procesos Nuevos y Modificados
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente:http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
Objetivos y Métricas
(Francavilla, 2012) Indicó que los mismos conceptos de COBIT 4.1, Val IT y
Risk IT se renombran como:
Objetivos empresariales
Objetivos Relacionados con TI
Objetivos de Procesos
Cascada de Objetivos
18
Basada en Objetivos empresariales que impulsan objetivos
relacionados con TI y son soportados por procesos Crítico
Tabla 10. Objetivos y Métricas
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente:http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
Entradas y Salidas
Provistas para cada práctica de Gestión en COBIT 5, mientras que en 4.1
solo lo hace a nivel de procesos. Entrega detalles adicionales para el diseño
de procesos, incluye productos de trabajo esenciales y asiste en la integración
de interprocesos
Tabla 11. Entradas y Salidas
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente:http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
Cuadros RACI
Similares a COBIT 4.1, Val It y Risk IT, describen roles y responsabilidades
Roles
Completos, detallados y más claros
Roles genéricos de negocio y TI
Para cada práctica de gestión mejora la definición de:
Responsabilidades
Nivel de participación
Tabla 12. Cuadros RACI
Autor: Carlos Francavilla. (2012). Comparación de COBIT 4.1 .mayo, de
Carlos Francavilla
Fuente:http://es.slideshare.net/CarlosFrancavilla/COBIT-5-comparacion-
con-COBIT-41
19
Mapeo de ITIL v3 con COBIT 4.1
Ilustración 5. Mapeo de ITIL v3 con COBIT 4.1
Fuente:http://www.itsm.hr/baza%20znanja/Mapping%20ITILV3%20COBIT41.pdf
20
CAPITULO 2
2. METODOLOGÍA
2.1. Antecedente
En este capítulo se profundizará los conceptos teóricos tanto de ITIL como
COBIT, ya que son esenciales para el desarrollo del diseño de los procesos de
la empresa ATIjaguar, Además indicamos que metodología se utilizo
Existen varias metodologías de investigación como por ejemplo: Método
Inductivo, Deductivo, Científico, de Análisis, Estadístico, Empíricos,
Teóricos.
Para esta tesis los métodos utilizados para fundamentar la investigación son:
2.2.Método de Análisis
Este método será utilizado para la revisión de información en relación a los
procesos de Gestión de Incidentes y Problemas en base a ITIL y COBIT en
un marco de buenas prácticas, los cuales proporcionan un conjunto de
estándares para prestar servicios de Tecnología de la Información de calidad.
Además se realizó una comparación entre las versiones de cada uno de ellos
con la finalidad de escoger la más adecuada. Como se pudo ver en el inciso
1.5.
Fundamentación Teórica
Para tener claras las ideas, el marco teórico se ha realizado en dos partes:
ITIL V3 actualización 2011
COBIT 5.0
21
ITIL V3 actualización 2011
Ciclo de Vida del Servicio
Es un enfoque de la Gestión de Servicio de TI (ITSM) que destaca la
importancia de la coordinación y el control a través de las diversas funciones,
procesos y sistemas necesarios para gestionar el Ciclo de Vida de los
Servicios de TI al completo.
La arquitectura del núcleo de ITIL está basada en el Ciclo de vida del
Servicio.A continuación el gráfico del Ciclo de Vida del Servicio.
Ilustración 6. Ciclo de Vida del Servicio Autor: Adoptado de The ITIL Service Lifecycle Copyright 2011
Fuente: ITPreneurs Nederland B.V. (2013). Manual del Alumno. Nederland
:TPreneursNederland B.V.
22
Centro de Servicios (ServiceDesk)
Visión General
El objetivo primordial, aunque no único, del Centro de Servicios es servir de
punto de contacto entre los usuarios y la Gestión de Servicios TI.
Debe ser el único punto de contacto para usuarios TI en el día a día
Tramitará todos los Incidentes y Peticiones de Servicio, utilizando por lo
general, software y herramientas especializadas para registrar y gestionar
dichos eventos.
Un Centro de Servicios, en su concepción más moderna, debe funcionar como
centro neurálgico de todos los procesos de soporte al servicio:
Registrando y monitorizando incidentes.
Aplicando soluciones temporales a errores conocidos en
colaboración con la Gestión de Problemas.
Colaborando con la Gestión de Configuraciones para asegurar
la actualización de las bases de datos correspondientes.
Gestionando cambios solicitados por los clientes mediante
peticiones de servicio en colaboración con la Gestión de
Cambios y Versiones
23
Pero también debe jugar un papel importante dando soporte al negocio
identificando nuevas oportunidades en sus contactos con usuarios y clientes. 4
Los objetivos del ServiceDesk se encierran en un amplio y multidisciplinar
contexto cuya premisa es restaurar el servicio normal de los usuarios tan
pronto como sea posible.
Esto no solo quiere decir arreglar una falla de tipo de técnico aunque sea
posible que con eso baste para mantener la continuidad del servicio, sino que
igualmente puede involucrar diligenciar una solicitud de servicio o responder
una consulta. Específicamente hablando las responsabilidades que debe
cumplir incluyen:
Registrar detalles de incidentes o peticiones de servicio
relevantes, así como su categorización y priorización
Escalar incidentes que no han podido ser solucionados en una
escala de tiempo
Mantener a los usuarios informados del progreso
Investigar las causas y proveer diagnósticos de primera línea
Resolver rápidamente las interrupciones del servicio.
Emitir peticiones de servicio.5
Informarse sobre el cumplimiento de los SLAs.
Recibir información comercial en primera instancia.
4osiatis. (2013). Gestión de Servicios TI. 20 mayo, de osiatis Sitio web:
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/service_desk/vision_general_service_desk/visio
n_general_service_desk.php 5 Carlos Vargas. (2012). ServiceDesk. 17 septiembre, de Carlos Vargas Sitio web: http://servicedesk-
sosw.blogspot.com/2012/09/justificacion-y-objetivos-del-service.html
24
Estructura del Centro de Servicios
Sea fácilmente accesible.
Ofrezca un servicio de calidad consistente y homogénea.
Mantenga puntualmente informados a los usuarios y lleve un
registro de toda la interacción con los mismos.
Sirva de soporte al negocio.
Para cumplir estos objetivos es necesario implementar la adecuada
estructura física y lógica.
Estructura lógica.- Los integrantes del Centro de Servicios deben:
Conocer todos los protocolos de interacción con el cliente: guiones,
checklists.
Disponer de herramientas de software que les permitan llevar un registro
de la interacción con los usuarios.
Saber cuándo se debe realizar un escalado a instancias superiores o entrar
en discusiones sobre cumplimiento de SLAs.
Tener rápido acceso a las bases de conocimiento para ofrecer un mejor
servicio a los usuarios.
Recibir formación sobre los productos y servicios de la empresa.
Estructura física.- Dependiendo de las necesidades de servicio:
locales, globales, 24/7,...se debe de optar por una estructura diferente
para el Centro de Servicios.
25
Existen tres formatos básicos:
Centralizado
Distribuido
Virtual6
Roles del Centro de Servicios
Director del Centro de Servicios.
Supervisor del Centro de Servicios
Analista del Centro de Servicios
Entradas y Salidas
A continuación se menciona las entradas que inicializan el flujo de
funcionamiento del Centro de Servicios y los elementos que se obtienen como
salidas al culminar con el flujo:
Entradas
Peticiones de servicio del usuario solicitud de la
información (recordatorio de claves, manuales de
procedimientos, manuales de usuario), cambio de sistemas
o hardware (modificación a módulos de sistemas,
reemplazo de partes o pieza), atención a incidentes
Implementación a nuevos sistemas o procesos que afectan
al fluyo de trabajo de los usuarios.
6Osiatis S.A. (2008). Centro de servicios (ServiceDesk) Implementación. 4 agosto, de Osiatis S.A
Sitio web:
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/service_desk/introduccion_objetivos_service_d
esk/implementacion_service_desk.php
26
Detención programada de servicios (mantenimientos
preventivos y correctivos)
Salidas
Soluciones temporales (workaround)
Peticiones de Cambio
Soluciones definitivas, registradas en KEBG
Comunicación A los usuarios, por detención de los
servicios o por la implementación de nuevos sistemas o
procesos.
Informe de análisis de soluciones y cumplimientos,
satisfacción del usuario.
Sugerencias para la gerencia para motivar cambios y
estimular la mejora continua del servicio.
Gestión de Incidentes
La Gestión de Incidentes es uno de los procesos que forman parte de la parte
de la fase de Operación del servicio que plantea ITIL v3 actualización 2011
en el Ciclo de Vida del Servicio.
Finalidad
Recuperar la operación normal del servicio lo antes posible
Minimizar los efectos adversos en las operaciones de negocio
Asegurar que se mantienen los niveles acordados de calidad
del Servicio.
27
Escalas de Tiempo
Es importante que se acuerden plazos para todas las fases de
tramitación de incidentes. Los mismos se basan en los objetivos
globales de respuesta y resolución de incidentes de los SLAs y son
captados como objetivos de los OLAs y UCs. Todos los grupos de
soporte deben haber sido informados sobre dichos plazos.7
Identificación de Incidentes
Todo el proceso empieza con la Identificación del Incidente. Una
organización debe tratar de identificar y resolver los incidentes antes
de que estos afecten a los usuarios.
Registro del Incidente
Cuando un usuario informa sobre un incidente, se debe registrar el
mismo con la fecha y hora de la notificación.8
Clasificación de Incidentes
Después de identificar el incidente hay que clasificarlo durante el
registro. Este paso es crucial ya que se usa mientras se establecen las
tendencias para otros procesos.
Priorización de Incidentes
Es la combinación del Impacto y de la Urgencia. Después de registrar
y clasificar los Incidentes, también se los deben asignar los códigos de
prioridad adecuados.
Diagnóstico Inicial
Una vez registrado un Incidente, es importante registrar todos los
síntomas para diagnosticar y rectificar el problema rápidamente. Para
7ITPreneursNederland B.V. (2013). Manual del Alumno. Nederland :TPreneurs Nederland B.V.
8ITPreneursNederland B.V. (2013). Manual del Alumno. Nederland :TPreneurs Nederland B.V.
28
ello el analista del Centro de Servicios debe llevar a cabo el
diagnóstico inicial mientras el usuario está al teléfono. Las guías de
diagnóstico y la información de los Errores Conocidos resultan útiles
en esta fase y ayudan a realizar un diagnóstico exacto.
Escalado del Incidente
Funcional.- Aplica cuando es necesario transferir un incidente
a un equipo con mayor experiencia, cuando el conocimiento
básico no es suficiente para la resolución.
Jerárquico.- Aplica cuando se debe acudir a un responsable
de mayor grado de autoridad a fin de tomar decisiones que no
están atribuidas a nivel inferior.
Investigación y Diagnóstico de Incidentes
Mientras se investiga los incidentes, el Centro de Servicios puede
entender que el usuario simplemente busca información, en dichos
casos el Centro de Servicios debe facilitar la información necesaria y
resolver la Petición de Servicio, no obstante si se notifica un fallo este
se califica como incidente y requiere una investigación y diagnóstico
adecuado.
Resolución y Recuperación de Incidentes
Cuando se ha identificado una posible resolución, se debe aplicar y
probar la misma. Se pueden llevar a cabo las siguientes actividades
genéricas:
Comenzar pidiendo a los usuarios que realicen actividades en
su propio escritorio o equipo siguiendo las actividades
29
Se pueden controlar los escritorios de los usuarios para
diagnosticar e implementar una resolución
Se puede pedir a los grupos especializados de soporte que
implementen medidas de recuperación concretas
Si fuese necesario, se puede pedir a un proveedor externo o al
encargado de mantenimiento que resuelva el fallo
Cierre de Incidentes
El Centro de Servicios debe asegurase de que el Incidente se resuelva
por completo y de que los usuarios están dispuestos a aceptar el cierre
del Incidente. Asimismo el Centro de Servicio debe comprobar lo
siguiente:
Clasificación del cierre
Encuesta de satisfacción del usuario
Documentación del Incidente
Problema continuo o recurrente
Cierre formal
Interfaces de la Gestión de Incidentes
Gestión de Accesos
Interfaces
con la
Gestión de
Incidentes
Gestión de Problemas
Gestión de la Seguridad del
Información
Gestión de la Configuración y los
Activos de Servicio
Gestión de Cambio
Gestión del Nivel de Servicio
Gestión de la Capacidad
Gestión de la Disponibilidad
Ilustración 7. Interfaces de la Gestión de Incidentes
Autor:Manual del Alumno
Fuente: ITPreneursNederland B.V. (2013). Manual del Alumno. Nederland :TPreneursNederland B.V.
30
Gestión de Problemas
Finalidad
Gestionar el Ciclo de Vida de todos los problemas desde la
primera identificación a través de mas investigación,
documentación y supervisión final.
Minimizar el Impacto negativo de los Incidentes y Problemas
Llegar a la causa raíz de los Incidentes documentar y
comunicar los errores conocidos y emprender medidas para
mejorar o corregir la situación.
Evitar proactivamente la repetición de los Incidentes
Determinar la solución para el problema
Implementar la solución deseada para solucionar el Problema.
La solución se implementa mediante procedimientos de
control, como la Gestión del Cambio y la Gestión de
Versiones.
Conservar la información sobre los Problemas. Para futura
referencia, se puede conservar la información del diagnóstico
de los Incidentes y las soluciones recomendadas en la Gestión
de Conocimiento o en herramientas como la Base de Datos de
Errores Conocidos (KEBD), esta información ayuda a reducir
el número de los Incidente en el futuro.
La Gestión de Problemas puede ser:
31
Reactiva.- Se centra en dar solucionar Problemas que
se desencadenan debido a Incidentes. Las actividades
se realizan como reacción ante los incidentes.
Proactiva.- Se ocupa de identificar y resolver
Problemas antes de que los Incidentes relacionados
vuelvan a ocurrir. Las actividades proactivas apuntan a
mejorar la disponibilidad y la satisfacción del usuario
con los Servicios TI.
Detección de Problemas.- El Centro de Servicios plantea un
registro de un Problema en dos situaciones:
Cuando se resuelve un Incidente pero es incapaz de
determinar la causa.
Cuando desde el principio resulta obvio que un
Incidentes ha sido causado por un Problema serio.
Registro de Problemas.- Es una buena práctica conservar los
Incidentes en los registros de los Problemas, así como en los
registros de los Incidentes.
Clasificación de Problemas.- Después de detectar y registrar
los Problemas, se lo clasifica:
Averigua la naturaleza del Problema en el futuro
Obtiene información valiosa sobre la gestión
Priorización de Problemas.- Los problemas no son lo mismo
que los incidentes, en consecuencia hay que tener en cuenta
32
que es necesario un conjunto diferente de definiciones y
orientación para priorizar un Problema.9
Investigación y Diagnóstico.- Juega un papel muy importante
a la hora de diagnóstica la causa raíz de un Problema. No
obstante, la velocidad y la naturaleza de la investigación varían
dependiendo del Problema, su Impacto, su gravedad y su
Urgencia.
Soluciones Temporales.- A veces las organizaciones adoptan
soluciones temporales a un Problema para continuar operativa.
Plantear un Registro de Error Conocido.- Además también
habrá que registrarlos en el Registro de Errores Conocidos e
incluirlos en la KEDB para utilizarlos como referencias
futuras. Cuando los Incidentes o Problemas se vuelven a
producir es posible identificarlos y restablecer el Servicio
rápidamente.
Resolución de Problemas.- Cuando se descubra la causa raíz
y se desarrolla una solución la misma se implementa o se
aplica con el fin de solucionar el Problema subyacente. Es
importante que la solución no cause más problemas, por lo que
deberá probarse, si fuese necesario un Cambio, se enviará una
RFC a la Gestión de Cambios.
Cierre de Problemas.- Una vez que la solución final se
aplicado se cierra el registro del Problema. Si existen tickets de
9ITPreneursNederland B.V. (2013). Manual del Alumno. Nederland :TPreneurs Nederland B.V.
33
Incidentes relacionados también se deberían cerrar. Todos los
registros de deberán revisar para garantizar que los datos son
completos y exactos.
Revisión de Problemas Importantes.- La gestión de
problemas no concluye después de resolver y cerrar un
Problema, el proceso incluye una revisión de todos los
Problemas importantes de forma que la organización aprenda
de los errores cometidos en el pasado.10
COBIT
Versiones deCOBIT
Ilustración 8. Evolución de COBIT
Autor: ISACA
Fuente: http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
10
ITPreneursNederland B.V. (2013). Manual del Alumno. Nederland :TPreneurs Nederland B.V.
34
Un Marco de Negocio para el Gobierno y la Gestión TI de la Empresa
El marco COBIT 5 se construye sobre cinco principios básicos, que quedan
cubiertos en detalle e incluyen una guía exhaustiva sobre los catalizadores
para el gobierno y la gestión de las TI de la empresa.11
La familia de productos de COBIT 5 incluye los siguientes productos.
Ilustración 9. Familia de Productos COBIT 5
Autor: ISACA
Fuente:http://www.isaca.org/COBIT/Documents/COBIT5-Framework-
Spanish.pdf
COBIT 5 provee de un marco de trabajo integral. Dicho de una manera
sencilla, ayuda a las empresas a crear el valor óptimo desde IT manteniendo
el equilibrio entre la generación de beneficios y la optimización de los niveles
de riesgo y el uso de recursos.12
11
http://www.isaca.org/COBIT/Documents/COBIT5-Framework-Spanish.pdf 12
http://www.isaca.org/COBIT/Documents/COBIT5-Framework-Spanish.pdf
35
Ilustración 10. Principios de COBIT 5
Autor: ISACA
Fuente: http://www.isaca.org/COBIT/Documents/COBIT5-Framework-
Spanish.pdf
Procesos Habilitadores
Procesos Habilitadores complementa COBIT 5 y contiene una guía detallada
de referencias a los procesos definidos en el Modelo de Referencia de
Procesos de COBIT 5. Contiene la información detallada de procesos para
todos los 37 procesos de COBIT 5 en el Modelo de Referencias de
Procesos.13
13
ISACA. (2012). INTRODUCCION. 10 DE ABRIL, de ISACA Sitio web:
http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
36
Ilustración 11. Procesos Habilitadores
Autor: ISACA. (2014). INTRODUCCION. 10 DE ABRIL, de ISACA
Fuente: http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
El Modelo de Referencia de Procesos de COBIT 5 subdivide las actividades y
prácticas de la Organización relacionadas con la TI en dos áreas principales –
Gobierno y Administración – con la Administración a su vez dividida en
dominios de procesos:
El Dominio de GOBIERNO contiene cinco procesos de
gobierno; dentro de cada proceso se definen las prácticas
para Evaluar, Dirigir y Monitorear (EDM).
Los cuatro dominios de la ADMINISTRACIÓN están
alineados con las áreas de responsabilidad de Planificar,
Construir, Operar y Monitorear (PBRM por su sigla en
inglés). 14
14
ISACA. (2012). INTRODUCCION. 10 DE ABRIL, de ISACA Sitio web:
http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
37
Implementación
Los marcos, mejores prácticas y normas son útiles solamente si son adoptados
de manera efectiva. Hay que superar muchos retos y resolver varios asuntos
para poder implementar GEIT de manera exitosa.15
Ilustración 12. Las 7 Fases de la Implementación del Ciclo de Vida
Autor: ISACA. (2014). INTRODUCCION. 10 DE ABRIL, de ISACA
Fuente: http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
15
ISACA. (2012). INTRODUCCION. 10 DE ABRIL, de ISACA Sitio web:
http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx
38
Modelo de Capacidad de los Procesos
Existen seis niveles de capacidad que se pueden alcanzar por un proceso,
incluida la designación de “proceso incompleto” si las prácticas definidas en
el proceso no alcanzan la finalidad prevista:
0 Proceso incompleto.- El proceso no está implementado o no
alcanza su propósito. A este nivel, hay muy poca o ninguna evidencia
de ningún logro sistemático del propósito del proceso.
1 Proceso ejecutado (un atributo).- El proceso implementado alcanza
su propósito.
2 Proceso gestionado (dos atributos).- El proceso ejecutado descrito
anteriormente está ya implementado de forma gestionada (planificado,
supervisado y ajustado) y los resultados de su ejecución están
establecidos, controlados y mantenidos apropiadamente.
3 Proceso establecido (dos atributos).- El proceso gestionado descrito
anteriormente está ahora implementado usando un proceso definido
que es capaz de alcanzar sus resultados de proceso.
4 Proceso predecible (dos atributos).- El proceso establecido descrito
anteriormente ahora se ejecuta dentro de límites definidos para
alcanzar sus resultados de proceso.
5 Proceso optimizado (dos atributos).- El proceso predecible descrito
anteriormente es mejorado de forma continua para cumplir con los
metas empresariales presentes y futuros.
Cada nivel de capacidad puede ser alcanzado sólo cuando el nivel
inferior se ha alcanzado por completo. Por ejemplo, un nivel 3 de
39
capacidad de proceso (establecido) requiere que los atributos de
definición y despliegue del proceso se hayan alcanzado ampliamente,
sobre la consecución completa de los atributos del nivel 2 de madurez
de procesos (proceso gestionado).
Evaluación de la Capacidad de los Procesos
Revisión de los resultados del proceso tal y como se describen para cada
proceso en sus descripciones detalladas, y usando las escalas y ratios de la
ISO/IEC 15504 para asignar un ratio para el grado en el que cada objetivo es
alcanzado.16
Esta escala consiste en los siguientes ratios:
N (No alcanzado).- Hay muy poca o ninguna evidencia
de que se alcanza el atributo definido en el proceso de
evaluación. (0 al 15 por ciento de logro).
P (Parcialmente alcanzado).- Hay alguna evidencia
de aproximación a, y algún logro del atributo definido
en el proceso evaluado. Algunos aspectos del logro del
atributo pueden ser impredecibles. (15 a 30 por ciento
de logro).
L (Ampliamente alcanzado).-Hay evidencias de un
enfoque sistemático y de un logro significativo del
atributo definido en el proceso evaluado. Pueden
encontrarse algunas debilidades relacionadas con el
atributo en el proceso evaluado. (50 a 85 por ciento de
logro).
16
http://www.isaca.org/COBIT/Documents/COBIT5-Framework-Spanish.pdf
40
F (Completamente alcanzado).- Existe evidencia de
un completo y sistemático enfoque y un logro completo
del atributo definido en el proceso evaluado. No existen
debilidades significativas relacionadas con el atributo
en el proceso evaluado. (85 a 100 por ciento de
logro).17
2.3.Método Estadístico
Se realizará una encuesta para determinar los incidentes de la empresa y
registrarlos.
2.4.Técnicas de Investigación
Se utilizará las técnicas de investigación descritas a continuación.
2.4.1. Revisión Teórica
Se fundamenta la investigación en las buenas prácticas de ITIL, que
se encuentra descrito en cinco libros y toda la información
proporcionada por otros textos. Al igual que COBIT 5 proporcionada
por ISACA.18
2.4.2. Revisión de Internet
Información entregada por fuentes fiables de información sobre las
buenas prácticas de ITIL y COBIT.
17
http://www.isaca.org/COBIT/Documents/COBIT5-Framework-Spanish.pdf 18
(InformationSystemsAudit and Control Association) (Asociación de Auditoría y Control de Sistemas
de Información)
41
CAPITULO 3
3. ELABORACIÓN DEL DISEÑO DEL CENTRO DE SERVICIOS EN EL
ÁREA DE TECNOLOGÍA DE LA INFORMACIÓN DE LA EMPRESA
ATIjaguar
De acuerdo a lo citado en los capítulos anteriores de ésta tesis, vamos a continuar con
el desarrollo del diseño del Centro de Servicios para la empresa, ayudados de los
procesos de Incidentes y Problemas.
3.1.Filosofía Empresarial
Visión.- Ser una empresa líder en el desarrollo de software con un equipo
multidisciplinario actualizado en el manejo tecnología de punta, ofrecer a
nuestros clientes soluciones tecnológicas inteligentes de gran valor, innovadoras
y con estándares internacionales.
Misión.- Crear la mejor solución tecnológica a su problema .
Principios y valores Empresariales
Trabajamos en equipo.
Disfrutamos de lo que hacemos
Actuamos con integridad.
Cumplimos con los objetivos empresariales.
Somos socialmente responsables
42
3.2. Estructura Organizacional
Presidente
Asesoría Jurídica
Gerencia de
Operaciones de
Servicios
Gerencia
Administrativa
Gerencia de
Tecnología
Gerencia
Financiera
Gerencia Provincial
Marketing
Talento
Humano
Logística
Aplicativos
Redes y
Comunicaciones
Base de Datos
Contabilidad
Tesorería
Esmeraldas
Los Ríos
Guayas
Pichincha
Cotopaxi Ilustración 13. Estructura Organizacional de la Empresa ATIjaguar
Autor: Empresa ATIjaguar
Fuente: Presidencia Ejecutiva de la Empresa ATIjaguar
43
3.2.1. Gerencia de la Tecnología de la Información de la Empresa ATIjaguar
La Gerencia de Tecnología de la Información es un socio estratégico y de apoyo de la
Empresa ATIjaguar, cuyo objetivo principal es mantener una infraestructura
tecnológica adecuada y competente que apoye al negocio.
3.2.1.1. Procesos de la Gerencia de TI
El área de TI está constituida por 3 procesos claves para la gestión dirigida por
un especialista que gestiona el proceso. A continuación se detallan los procesos:
Administración de Aplicativos.- Mantener activos los aplicativos
claves, minimizando la inactividad.
Administración de Redes y Comunicaciones.- Encargada de
mantener una red operativa, segura, eficiente constantemente
monitoreada.
Administración de Base de Datos.- Encargada de participar en el
diseño inicial de la base de datos y su puesta en marcha, asi como
también debe controlar y administrar sus requerimientos ayudandoa
evaluar alternativas.
3.2.1.2. Composición funcional de la Gerencia de TI
A continuación se describe las actividades por cargo de cada uno de los
empleados:
44
Nombre del Cargo Gerente de Tecnología de la Información
Nombre del
Empleado Nelson López
Dirigir y controlar la gestión del área de tecnología
de la información de la empresa ATIjaguar
Evaluar y garantizar la implementación de los
procesos tecnológicos en ATIjaguar
Proporcionar soporte técnico ATIjaguar
Elaborar la planificación estratégica del área de TI de
ATIjaguar
Asesorar ATIjaguar en las decisiones sobre provision
de información
Descripción del
Cargo
Tabla 13. Gerencia de TI
Autor:Tesista
Fuente: Empresa ATIjaguar
Nombre del Cargo Asistente técnico de TI
Nombre del
Empleado XXXX
Controlar y dar seguimiento de los soportes
técnicos del áera de TI
Cordinar actividades del área de TI
Elaborar, controlar y dar seguimiento a la
documentación interna y externa del departamento
de TI
Mantener y organizar el archivo físico del área
Tramitar los procedimientos logísticos del área de TI
Descripción del
Cargo
Tabla 14. Asistente Técnico de TI
Autor:Tesista
Fuente: Empresa ATIjaguar
45
Nombre del Cargo Especialista de administración de aplicativos
Nombre del
Empleado XXXX
Administrar y dar soporte a los aplicativos de
ATIjaguar
Dirigir proyectos necesarios para el funcionamiento
de aplicativos de ATIjaguar
Cordinar y organizar la ejecuión de manuales,
procedimientos y políticas de seguridad de los
aplicativos
Recomendar y asesorar en soluciones tecnológicas
en aplicativos a ATIjaguar
Dirigir y supervisar las actividades del equipo a su
cargo en los planes y proyectos a ejecutarse
Descripción del
Cargo
Tabla 15. Área de Administración de Aplicativos
Autor:Tesista
Fuente: Empresa ATIjaguar
Nombre del Cargo Técnico de administración de aplicativos
Nombre del
Empleado XXXX
Administrar, dar soporte, analizar y configurar a los
aplicativos de ATIjaguar
Realizar y mantener un esquema de
implementación de aplicativos
Cordinar el mantenimiento de los aplicativos
Recomendar y asesorar en soluciones tecnológicas
en aplicativos a ATIjaguar
Detectar y analizar requerimientos de aplicativos
Descripción del
Cargo
Tabla 16. Área de Administración de Aplicativos
Autor:Tesista
Fuente: Empresa ATIjaguar
46
Nombre del Cargo Asistente de administración de aplicativos
Nombre del
Empleado XXXX
Desarrollar, administrar y mantener los sitios web,
portales, intranet de ATIjaguar
Ejecutar políticas de respaldos de información de
los aplicativos web
Cordinar el mantenimiento de los aplicativos
Administrar, dar soporte, anlaizar y configurar los
aplicativos de ATIjaguar
Descripción del
Cargo
Tabla 17. Área de Administración de Aplicativos
Autor:Tesista
Fuente: Empresa ATIjaguar
Nombre del Cargo
Especialista de administración de redes y
comunicaciones
Nombre del
Empleado XXXX
Evaluar y organizar la red corporativa
Cordinar la implementación y mantenimiento de
redes y comunicaciones
Recomendar en soluciones tecnológicas en redes y
comunicaciones
Gestión y administración de seguridades
Administrar la infraestructura corporativa
Diseñar y cordinar planes de contingencia del
proceso de redes y comunicaciones
Descripción del
Cargo
Tabla 18. Área de Administración de Redes y Comunicaciones
Autor:Tesista
Fuente: Empresa ATIjaguar
47
Nombre del Cargo
Técnico de administración de redes y
comunicaciones
Nombre del
Empleado XXXX
Analizar, configurar y actualizar los equipos y redes
de comunicación
Ejecutar actividades de instalaciòn de redes y
comunicaciones
Recomendar en soluciones tecnológicas en redes y
comunicaciones
Realizar y controlar los inventarios de los equipos de
comunicaciòn
Garantizar la disponibilidad de los servicios de datos
e internet
Brindar soporte tècnico en redes y comunicaciones
Descripción del
Cargo
Tabla 19. Área de Administración de Redes y Comunicaciones
Autor:Tesista
Fuente: Empresa ATIjaguar
Nombre del Cargo Especialista en la administración de base de datos
Nombre del
Empleado XXXX
Administrar y controlar el desempeño de la base de
datos
Realizar planes de contingencia necesarios para el
funcionamiento del servicio de base de datos
Administrar, analizar dar soporte y configurar
Descripción del
Cargo
Tabla 20. Área de Administración de Base de Datos
Autor:Tesista
Fuente: Empresa ATIjaguar
Nombre del Cargo Tècnico en la administración de base de datos
Nombre del
Empleado XXXX
Supervisar, analizar y configurar la base de datos de
ATIjaguar
Dar soporte tècnico en la administraciòn de la base
de datos
Realizar y mantener un esquema de seguridad de la
base de datos
Descripción del
Cargo
Tabla 21. Área de Administración de Base de Datos
Autor:Tesista
48
Fuente: Empresa ATIjaguar
3.2.1.3. Servicios Tecnológicos que brinda la Gerencia de TI
El área de TI de ATIjaguar cuenta con un amplio portafolio de servicios
brindados por el personal técnico de la empresa y otros son contratados
externamente.
Servicios de TI solventados por el personal de ATIjaguar
Área de Ti que
provee del servicioServicio
Administrar sistemas operativos,
aplicaciones o sistemas informáticos
Asesorar técnicamente con respecto al uso
de herramients de software
Cordinar la administraciòn de portales web
e intranet
Implementar y administrar cableado
estructurado
Administrar el servicio de Internet,
intranet, mail
Manejo de las seguridades y control de
acceso
Administración de computadores,
portátiles y servidores, UPS, impresoras,
scaners, routers, equipos periféricos
Realizar respaldos de la base
Administrar y controlar seguridades de la
base de datos
Servicios Tecnológicos por el área de TI
Administraciòn de
Aplicativos
Administraciòn de
Redes y
Comunicaciones
Administración de
Base de Datos
Tabla 22. Servicios Tecnológicos por el Área de TI
Autor:Tesista
Fuente: Empresa ATIjaguar
49
3.2.1.4. Detalle de los Servicios de ATIjaguar por Departamentos
Departamentos Servicios Descripciòn
Asientos Contables
Egresos
Retenciones
Cheques
Registro de facturas
Estado Contable
Registro de cuentas
Registro de Proveedores
Financiero
Estos servicios se los
da con la utilizaciòn
de un sistema contable
el cual tiene una base
de datos que permite
almacenar la información,
que se encuentra instalado
en el sistema operativo
Windows server 2008,
además se comunican
mediante LAN
50
Registro de Clientes
Asignaciòn de tareas
Sistema de Administraciòn
Forestal (SAF)
Este servicio se brinda
al Ministerio del Ambiente
Creaciòn de usuarios de
correo
Utilizaciòn de Microsoft
outlook 2010 instalado en cada
una de las PC's de la empresa
Creaciòn de cuentas
Mediante la utilizaciòn
del SAF y el Sistema de
Facturación de Notarias
Mantenimiento de
servidores
Instalaciòn de software y
hardware
Windows 7 service pack
1, office 2010, aplicativos
propios, sistema de facturación
Antivirus, PDF, software para
descomprimir archivos,
instalación de impresora
instalación de controladores
Instalación y
mantenimiento de la red
Switches, routers,
cableado estructurado,
acces point
Creación de claves
Mediante la utilizaciòn
del SAF y el Sistema de
Facturación de Notarias
Administración de Página
Web
Contiene documentos HTML,
imágenes, archivos de texto,
escrituras, y demás material
web compuesto por datos
Sistema de Facturaciòn
para Notarias
Este servicio se brinda
a las Notaria 9
Marketing/ Ventas
Tecnología de
Informaciòn
Estos servicios se los
da con la utilizaciòn
de un CRM
el cual tiene una base
de datos que permite
almacenar la información, que
se encuentra instalado en el
sistema operativo Windows
server 2008, además se
comunican mediante LAN
51
Talento Humano Resgistro de empleados
Utilizaciòn de Microsoft
office 2010 instalado en cada
una de las PC's de la empresa
Registro de compras
Utilizaciòn de Microsoft
office 2010 instalado en cada
una de las PC's de la empresa
Registro de transporte
Utilizaciòn de Microsoft
office 2010 instalado en cada
una de las PC's de la empresa
Provincial Registro de usuarios
Logìstica
Tabla 23. Tabla de Servicio
Autor:Tesista
Fuente: Empresa ATIjaguar
52
3.3. Diseño de la Solución Centro de Servicio en la Empresa ATIjaguar utilizando como
marco de referencia ITIL V3 actualización 2011 y COBIT 5.0
Esta función estará respaldad por la Gestión de Incidentes y Problemas, según sea el caso de la
solicitud por parte del usuario. Se tomará en cuenta el tipo de caso, la categorización,
siguiendo el proceso de resolución con el fin de determinar si es catalogado como incidente o
problema .
3.3.1. Diseño del Proceso Gestión de Incidentes
La Gestión de Incidentes es uno de los procesos que forman parte de la fase Operación
del Servicio que plantea ITIL V3 actualización 2011 en el Ciclo de Vida del Servicio.
3.3.1.1. Roles en Gestión de Incidentes
ROL EMPLEADO TI DE ATIjaguar
Operador del Centro de Servicio Asistente Técnico
Analista y Gestor de Incidentes
Técnicos: Aplicativos, Redes y
Comunicaciones y Base de
Datos
Especialista: Aplicativos,
Redes y Comunicaciones y
Base de Datos
Coordinador del Incidente
Asistente Técnico
Especialista: Aplicativos,
Redes y Comunicaciones y
Base de Datos
Tabla 24. Roles Gestión de Incidentes
Autor:Tesista
Fuente: Empresa ATIjaguar
53
3.3.1.2. Proceso para Gestión de Incidentes
Investigación y diagnóstico de incidentes
ID del
Proceso
Procedimiento o
Decisión
Descripción Rol
INI.1 Revisar incidente
El Analista de Incidentes monitorea la cola
de incidentes asignados y revisa los
incidentes que llegan.
Analista
de
incidentes
INI.2
¿Solicitud de
información?
El Analista de Incidentes evalúa el incidente
para ver si se categoriza como solicitud de
información (RFI), o si es una interrupción
de servicio. En caso afirmativo, vaya a
INI.11. Caso contrario, vaya a INI.3.
Analista
de
incidentes
INI.3
Buscar/reunir
información
El Analista de Incidentes empieza a
investigar y diagnosticar la causa del
incidente. El estado del incidente cambia a
“Trabajo en Progreso”.
Analista
de
incidentes
INI.4
¿Es posible
reproducir
incidente?
El analista trata de reproducir el incidente.
En caso afirmativo, vaya a INI.5. Caso
contrario, vaya a INI.8.
Analista
de
incidentes
INI.5
¡Relacionar
problema/error
conocido?
El Analista de Incidentes busca en la base de
conocimientos si ya existe un problema o
error conocido definido para este incidente.
En caso afirmativo, vaya a INI.9. Caso
contrario, vaya a INI.6.
Analista
de
incidentes
INI.6 ¿Incidentes El Analista de Incidentes busca en el Analista
54
causados por un
cambio?
incidente si un cambio reciente pudo haber
causado la interrupción del servicio. Si el
ítem de configuración asociado con el
incidente es listado, el Analista de
Incidentes puede también mirar cualquier
cambio que haya sido realizado
recientemente en ese ítem de configuración.
El Analista de Incidentes puede también ver
el árbol del ítem de configuración para
descubrir si hay ítems relacionados que
puedan causar el incidente. En caso
afirmativo, vaya a INI.10. Caso contrario,
vaya a INI.7.
de
incidentes
INI.7
¡Solución
encontrada?
El analista trata de reproducir el incidente.
En caso afirmativo, vaya a INI.5. Caso
contrario, vaya a INI.8.
Analista
de
incidentes
INI.8
Documentar
resolución/solución
El Analista de Incidentes documenta la
solución o workaround en el ticket del
incidente
Analista
de
incidentes
INI.9
Relacionar
incidente al
problema/error
conocido
Cuando un incidente coincide con un
problema o error conocido, el ticket del
incidente es relacionado al ticket del
problema o registro de error conocido.
Analista
de
incidentes
INI.10
Relacionar
incidente al cambio
Cuando el incidente es causado por un
cambio previo, el ticket del incidente es
Analista
de
55
relacionado al requerimiento del cambio.
Una solución aún necesita ser encontrada
para solucionar el incidente. Continuar con
INI.11.
incidentes
INI.11
Buscar y entregar
información
El Analista de Incidentes busca información
para proveer al requerimiento del usuario.
Analista
de
incidentes
Tabla 25. Procedimiento para la investigación y diagnóstico de incidentes
Autor: Tesista
Fuente: ATIjaguar
56
NO
SI
NO
NO
NO
SI
SI SI
Ilustración 14. Procedimiento para la investigación y diagnóstico de incidentes
Autor:Tesista
Fuente:ATIjaguar
SI
¿Incidentes
causados
por un
cambio?
INI.6 Ver
¿Solución
encontrad
a INI.7
Relacionar incidente al cambio INI.10 Ver tabla 37
Buscar y
entregar
información
INI.11
FIN
NO ¿Relacionar
problema/err
or conocido?
INI.5 Ver tabla
Relacionar incidente al problema/error conocido INI.9
Inicio
¿Es posible
reproducir
incidente?
Buscar/reunir
información INI.3 Ver tabla 29.
¿Solicitud
de
información
INI.2 Ver
Documentar resolución/solución INI.8 Ver tabla 37
Revisar
incidente INI.1
57
Resolución y recuperación de incidentes
ID del
Proceso
Procedimiento o
Decisión
Descripción Rol
IN2.1 Revisar incidente
El Analista de Incidentes revisa la
información del incidente por la solución
brindada o workaround.
Analista
de
incidentes
IN2.2 ¿Cambio requerido
para resolver
incidente?
El Analista de Incidentes determina si la
resolución necesita ser implementada
utilizando un cambio. En caso afirmativo,
revise el procedimiento de Escalamiento de
incidentes SD3.1. Caso contrario, vaya a
IN2.3.
Analista
de
incidentes
IN2.3 ¿La solución está al
alcance del
analista?
El Analista de Incidentes debe juzgar si
tiene los permisos para implementar la
solución. En caso afirmativo, vaya a IN2.4.
Caso contrario, vaya a IN2.7.
Analista
de
incidentes
IN2.4 Implementar la
solución
El Analista de Incidentes prueba la solución
y la implementa en el ambiente de
producción
Analista
de
incidentes
IN2.5 ¿Ha ocurrido un
error?
Cuando hay errores durante la
implementación de una solución, en analista
reversa la solución y el incidente es
regresado a la fase de investigación y
diagnóstico. En caso afirmativo vaya a
IN2.6. Caso contrario, vaya al
Analista
de
incidentes
58
procedimiento de cierre de incidentes IN3.1.
IN2.6 ¿Requiere
escalamiento?
Determine si el escalamiento al Coordinador
de Incidentes es requerida a este punto en el
proceso de resolución. En caso afirmativo,
vaya al proceso de Escalamiento de
Incidentes SD3.1. Caso contario, vaya al
procedimiento investigación y diagnóstico
de incidentes INI.1.
Analista
de
incidentes
IN2.7 Reasignar a otro
grupo
Cuando el Analista de Incidentes no está
autorizado para implementar la solución, el
analista debe reasignar el incidente al grupo
de soporte que pueda implementar la
solución
Analista
de
incidentes
Tabla 26. Procedimiento para la resolución y recuperación de un incidente.
Autor:Tesista
Fuente:ATIjaguar
59
Ilustración 15. Procedimiento para la resolución y recuperación de un incidente.
Autor:Tesista
Fuente:ATIjaguar
Inicio
Revisar incidente
2.1 Ver tabla 37.
¿Cambio requeriré para
resolver incidente?
Ver
¿La solución está al alcance del analista?
Procedimiento Resolución
de incidentes Ver tabla53
SD 3.1
Revisar incidente
2.1 Ver tabla 37.
FIN ¿Ha ocurrido un error?
IN 2.5
Procedimiento Cierre de
incidentes IN3.1
FIN
Investigación y
diagnóstico de
incidentes IN1.1 Ver
Tabla 29.
NO NO
NO
SI SI
SI
Reasignar a otro
grupo IN2.7 Ver
tabla 39.
Requiere escalamientoIN2.6Ver 3.3.1.4 c.
60
Cierre de Incidentes
Las condiciones bajo las cuales se puede iniciar el procedimiento de cierre de
incidentes (Tabla), son:
Un arreglo permanente relacionado al incidente ha sido
implementado.
Una solución alternativa (“workaround”), ha sido
implementada, reduciendo el impacto del incidente, dando
como resultado un nuevo incidente de menor severidad.
El incidente no puede ser reproducido.
El incidente se convierte en un problema y/o requerimiento
de cambio.
El usuario y el analista de Service Desk acuerdan que no se
pueden hacer esfuerzos adicionales, obteniéndose la
conformidad del usuario.
ID del
Proceso
Procedimiento o
Decisión
Descripción Rol
IN3.1 Revisar incidente
El Analista de Incidentes revisa la
descripción de la solución el incidente
Analista
de
incidentes
61
IN3.2
Verificación y
confirmación de
resolución
El Analista de Incidentes verifica que la
resolución es correcta y completa, y
confirma la resolución. Si es necesario, el
Analista de Incidentes es el encargado de
contactar al usuario para validar la
resolución
Analista
de
incidentes
IN3.3
¿El incidente está
resuelto?
¿Se resuelve el incidente con la solución
ofrecida? Caso afirmativo, vaya al IN3.4.
Caso contario, vaya a IN3.5.
Analista
de
incidentes
IN3.4
Cierre de ticket de
incidente
El Analista de Incidentes cierra el ticket del
incidente y selecciona el código de
resolución aplicable
Analista
de
incidentes
IN3.5 Reabrir el incidente
Si la solución entregada no resuelve el
incidente, se reabre el incidente
devolviéndolo al procedimiento resolución y
recuperación de incidentes IN 2.1.
Analista
de
incidentes
Tabla 27. Procedimiento para el cierre de incidentes
Autor:Tesista
Fuente:ATIjaguar
62
Ilustración 16. procedimiento para el cierre de incidentes.
Autor:Tesista
Fuente:ATIjaguar
3.3.1.3.Matriz RACI para Gestión de Incidentes
A continuación se detalla la matriz RACI (Tabla 28.) para la
determinación de roles y responsabilidades en Gestión de Incidentes.
Procedimiento
Ges
tor
de
Inci
den
tes
Coord
inad
or
de
Inci
den
te
An
ali
sta d
e
Inci
den
te
Op
erad
or
de
Cen
tro d
e
Ser
vic
ios
Usu
ari
o
Investigación y diagnóstico
de incidente
A C/I R C/I
Resolución y recuperación de A C/I R C/I
Inicio
Revisar
incidentes IN3.1
Verificación y
confirmación de
resolución IN3.2
ver tabla 27.
¿El
incidente
está
Cierre de ticket
de incidente
IN3.4
Reabrir el
incidente IN3.5 FIN
SI
NO
63
incidente
Cierre de incidente A C/I R I I
Tabla 28. Matriz RACI para Gestión de Incidentes
Autor:Tesista
Fuente: Empresa ATIjaguar
3.3.1.4.Actividades del Proceso de Gestión de Incidentes
a. Identificación y Registro del incidente
Para el registro del incidente se tomará en cuenta el siguiente
formato:
Nombre
del
usuario
Tipo
SolicitudFecha Hora
Descripción
Incidente
Tabla 29. Registro incidente
Autor:Tesista
Fuente: Empresa ATIjaguar
64
Tipo Solicitud Descripción Ejemplos
Interrupciones de
Servicio
Cualquier falla del servicio
que afecte a la operación
del usuario
Equipo no enciende
Mensaje de error
Caída de la red
Solicitudes de
ServicioSolicitud que requiere
planeación para su
ejecución,
Cambio de tóner
Instalación de
software
Cambio de
periféricos
Solicitudes de
Información
Cuando los usuarios
preguntan como realizar
alguna operación a un
aplicativo
Actividades
ofimáticas
Cambio de
contraseñas
aplicativos
Quejas y ReclamosInconformidad reportadas
por parte del usuario
Solución no
satisfactoria para el
usuario
Tiempo de respuesta
no satisfactorio
Tabla 30. Tipos de Solicitud
Autor:Tesista
Fuente: Empresa ATIjaguar
b. Categorización y Priorización del incidente
A fin de agrupar las incidencias por categorías, según las áreas
responsables, se determinan los siguientes ámbitos o servicios:
Área Categoría
Administración de aplicativos Software
Intranet
Portales web
Administración de redes y
comunicaciones
Conectividad (Internet y datos)
Cuentas de correo electrónico
Accesos físicos
65
Accesos lógicos
Hardware
Administración de base de
datos
Conectividad a bases de datos desde
los sistemas.
Reportes
Respaldos diarios
Tabla 31. Categorización
Autor:Tesista
Fuente: Empresa ATIjaguar
Criterios para el establecimiento del impacto de un
incidente
Impacto Criterio
Alto Afecta al negocio
Medio Afecta a un departamento
Bajo Afecta a un usuario
Tabla 32. Criterios para el establecimiento del impacto de un
incidente
Autor:Tesista
Fuente: Empresa ATIjaguar
Criterios para el establecimiento de la urgencia de un
incidente
Urgencia Criterio
Alta Requerimiento de soluciòn inmediata
Media
El incidente no representa una alta
afectacióny puede ser atendido en tiempo
moderado
Baja
El incidente no representa una importante
afectación y podrá esperar para ser
atendido dentro de lo establecido
Tabla 33. Criterios para el establecimiento de la urgencia de un
incidente
Autor:Tesista
Fuente: Empresa ATIjaguar
66
Criterios para el establecimiento de la prioridad de un
incidente
Para determinar la prioridad del incidente registrado por el
ServiceDesk se plantea la siguiente matriz de prioridades,
formulando la prioridad y el tiempo de resolución promedio
en función de la urgencia e impacto del incidente (Prioridad =
Impacto * Urgencia):
Prioridad Definición y Aplicación
Media
Un incidente que afecta la capacidad de los usuarios
de
realizar operaciones normales, impide productividad
pero existe un woraround disponible, el problema no
es sensible al tiempo
Un incidente que afecta documentación, procesos
o procedimientos. No tiene impacto en la capacidad
de los usuarios en realizar operaciones normales. Por
ejemplo un usuario que requiere acceso a una
aplicación
Alta
Baja
Un incidente que afecta aplicaciones crìticas del
negocio, es sensible al tiempo tiene impacto
indirecto con el usuario final, pero existe una solución
temporal disponible
Tabla 34. Criterios para el establecimiento de la prioridad de un
incidente.
Autor:Tesista
Fuente: Empresa ATIjaguar
Para la selección de la prioridad y por ende, el tiempo de
resolución máximo para cada requerimiento, se establece la
siguiente matriz de limites.
67
IMPACTO
PRIORIDAD
TIEMPO DE
RESOLUCIÓN
PROMEDIO
Alta Media Baja
UR
GE
NC
IA
Alta Alta
>=1min <=1 hora
Alta
>=1min<= 1 hora
Alta
>=1 hora < 2 horas
Media Alta
>=1min<=1hora
Media
>= 1hora < 2 horas
Baja
>= 2 horas <= 5 horas
Baja Media
> 1 hora < 2 horas
Alta
>= 2 horas <= 5 horas
Baja
>= 2 horas <= 5 horas
Tabla 35. Matriz de asignación de prioridades y tiempo de resolución promedio a
solicitudes.
Autor:Tesista
Fuente: Empresa ATIjaguar
Los rangos definidos en la tabla serán los tiempos límite de respuesta
para los casos de prioridad que el Service Desk clasifique al incidente
repòrtado.
Servicios brindados por ATIjaguar con tiempo máximo de respuesta y
estableciendo prioridad
Para establecer la prioridad de los servicios que brida ATIjaguar, tomamos en
cuenta las tablas 24. y23. Con la finalidad de tener un registro de los servicios y su
tiempo máximo de respuesta.
68
Servicios Tiempo máximo
de respuesta
Impacto Urgencia Prioridad
Asientos Contables 4 horas Bajo Bajo Bajo
Egresos 4 horas Bajo Bajo Bajo
Retenciones 4 horas Bajo Bajo Bajo
Cheques 4 horas Bajo Bajo Bajo
Registro de facturas 4 horas Bajo Bajo Bajo
Estado Contable 4 horas Bajo Bajo Bajo
Registro de cuentas 4 horas Bajo Bajo Bajo
Registro de Proveedores 4 horas Bajo Bajo Bajo
Registro de Clientes 4 horas Medio Bajo Medio
Asignaciòn de tareas 2 horas Medio Bajo Medio
Sistema de Administraciòn
Forestal (SAF)1 horas Alto Alto Alto
Creaciòn de usuarios de
correo
2 horas Medio Medio Medio
Creaciòn de cuentas 2 horas Medio Medio Medio
Mantenimiento de
servidores1 horas Alto Alto Alto
Instalaciòn de software y
hardware2 horas Medio Medio Medio
Instalación y
mantenimiento de la red1 horas Alto Alto Alto
Creación de claves 1 horas Medio Medio Medio
Administración de Página
Web
1 horas Medio Medio MedioSistema de Facturaciòn
Sistema de facturación
para Notarias 1 horaAlto Alto Alto
Resgistro de empleados 5 horas Bajo Bajo Bajo
Registro de compras 5 horas Bajo Bajo Bajo
Registro de transporte 5horas Bajo Bajo Bajo
Registro de usuarios 5 horas Bajo Bajo Bajo
Capacitación 4 horas Bajo Bajo Bajo
Registro de Clientes 4 horas Bajo Bajo Bajo
Inventario 4 horas Bajo Bajo Bajo
Adquisiciones 4 horas Bajo Bajo Bajo
Tabla 36. Servicios, Tiempo de respuesta y Prioridad
Autor: Tesista
Fuente: ATIjaguar
Diagnóstico Inicial (Incidentes y Posibles soluciones )
Para tener conocimiento de los incidentes más frecuentes se realizo una encuesta a
los empleados de ATIjaguar, de la cual se obtuvo el siguiente resultado:
69
Incidentes Posibles Soluciones
Verificar si el cable de red se encuentra conectado
en lugar correcto
Verificar si esta correctamente puesta la IP de la PC
Verificar que la tarjeta de red funcione
Identificar aplicación
Word ha dejado de funcionar reinicie la Pc
Excel ha dejado de funcionar reinicie la Pc
Power Point ha dejado de funcionar reinicie la Pc
Un virus afectado el programa
Falta algún archivo esencial, biblioteca, DLL o plugin
Falsa alarma de antivus y bloquea
No hay permisos suficientes para la ejecuciòn
El sistema está corrupto
Ver si la impresora se encuentra encendida
Verificar que el cable de la impresora esté conectado
Verificar que no se encuentre nada en la bandeja
de salida de la impresora
Verificar conexión inalambrica (impresora inalámbrica)
Verificar si el equipo está conectado a la red
Verificar si los puertos del correo son los correctos
Verifica si se encuentra escrito correctamente el mail
Verificar si el firewall bloquea la conexión con el
servidor saliente
Verificar configuración de correo están correctas
Verificar si la contraseña son correctas
Entren en modo a prueba de errores, inician
sesion con el administrador, van a inicio, panel de
control, cuentas de usuarios, seleccionan su cuenta
y le dan a borrar contraseña. reinician el pc
Asegúrse que el cable eléctrico esté conectado
Verifique que el suministro de energía esté en la
posición “prendido” (on).
Verifique que el cable de alimentación esté firmemente
conectado a la salida de toma de corriente
Asegúrese de que su computador arranque en forma
normal y que todas las típicas luces indicadoras estén
prendidas.
Verifique que el monitor esté enchufado
Verifique que el botón de encendido del monitor esté
en la posición “prendido” (on).
La Computadora Prende pero el Monitor
queda en Blanco o negro
Sin acceso a la red/internet
Apliación no funciona
No se puede imprimir
No se puede recibir ni enviar correos
No puedo ingresar a mi equipo
La computadora no se enciende
70
Incidentes Posibles Soluciones
Asegúrese que no haya ningún medio de arranque
(bootable) en su disco de discos floppy o de CD.
Indique claramente el o los mensajes que le
aparecen en la pantalla
Desconecte y vuelva a conecta
Reinicie el equipo
Pida el remplazo
Windows no Arranca o se Cae
el Sistema
El mouse o teclado no funcionan.
Tabla 37. Base de Conocimiento
Autor: Tesista
Fuente: ATIjaguar
c. Escalamiento de incidente
Para el proceso de escalado se tomará en cuenta Tabla 38. Niveles de
soporte para atención de solicitudes de servicio.
1ª línea de Soporte.- Corresponde al Centro de Servicio, quien
debe registrar los datos del incidente reportado, la mayor parte de
soluciones a incidentes a deben estar en este nivel.
2ª línea de Soporte.- Son especialistas con conocimientos y
recursos específicos en la infraestructura para solución de
incidentes.
3ª línea de Soporte.- Corresponde a los proveedores y
fabricantes. Cuando el 2 nivel de soporte no puede solucionar los
incidentes.
Reasignación a otro grupo
Hora
Asignación
Incidente
Fecha
Asignación
Incidente
Diagnóstico
Preliminar
Recursos
Asignados
Diagnóstico
Final
Incovenien
te que
Persiste
Hora y Fecha
Escalamiento
Tabla 39. Reasignación de Grupo
Autor: Tesista Fuente: ATIjaguar
71
d. Investigación y diagnóstico de incidentes
En la tabla 25.
e. Resolución y recuperación de incidentes
En la tabla 26.
f. Emisión de Petición de Cambio (RFC)
Si el caso lo amerita, se procederá a emitir un RFC cuando se
requiera un cambio de software, hardware, configuración,
conectividad. Esta petición será emitida por la Gestión de
Cambios; para esta tesis este proceso no se encuentra dentro del
alcance.
g. Cierre de Incidentes
En la tabla 27.
72
3.3.2. Diseño del Proceso Gestión de Problemas
La Gestión de Problemas trata el ciclo de vida de los problemas, previene su
ocurrencia y la posibilidad de futuros inconvenientes asociados al mismo. Elimina
problemas repetidos y reduce al mínimo el impacto de aquellos problemas que no
pueden ser prevenidos.
El siguiente análisis presenta la caracterización del proceso de Gestión de Problemas
presentando sus objetivos, beneficios, entradas y salidas, roles, indicadores claves de
desempeño y la matriz RACI para la segregación de funciones.
3.3.2.1.Roles de la Gestión de Problemas
ROL ROLES
Gestor de Problemas Asistente técnico
Coordinador de Problemas Especialistas:
Aplicativos
Base de Datos
Redes Comunicaciones
Analista de Problemas Técnicos:
Aplicativos
Base de Datos
Redes Comunicaciones
Tabla 40. Roles de Gestión de Problemas
Autor:Tesista
Fuente:ATIjaguar
73
3.3.2.2.Matriz RACI para la Gestión de Problemas
Procedimiento
Gestor de
problema
Coordinador
de problema
Analista de
problema
Detectar, registrar y categorizar el
problema
A/I R
Planificar y priorizar problemas A/R C
Investigar y diagnosticar el problema A I R
Registrar y categorizar Error Conocido A R
Investigar Error Conocido A R
Tabla 41. Matriz RACI para Gestión de Problemas
Autor:Tesista
Fuente:ATIjaguar
3.3.2.3.Actividades del proceso Gestión de Problemas
a. Detectar, registrar y categorizar el problema
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
GP 1.1 Revisar
incidentes
cerrados
Periódicamente, el coordinador de problemas
debe revisar los incidentes cerrados para detectar
nuevos problemas o encontrar problemas que no
han sido resueltos. El análisis de los datos de los
incidentes revelará la recurrencia de los
incidentes presentados y permitirá la búsqueda
de soluciones permanentes para los mismos.
Seleccione los incidentes desde la última
revisión utilizando el siguiente criterio.
Coordinador
de problemas
74
Incidentes mayores (alto impacto)
Incidentes resueltos a través de
workaround o la solución no encaja con
el problema.
Sospecha de problemas identificados por
los diseños de los procesos
Candidatos a problemas: todos los
incidentes cerrados no resueltos por una
corrección permanente, corrección
temporal o workaround, tienen que ser
emparejados a problemas existentes o un
nuevo problema debe ser creado.
El personal de manejo de incidentes podría ya
tener incidentes vinculados a problemas
existentes (Ej: si un workaround fue aplicado).
GP1.2 ¿Hay incidentes
causados por el
problema?
Verifique si el incidente es causado por un
problema excepcional o por un Error Conocido.
Si es así, vaya a GP1.3. si nos vaya a GP1.4.
Es importante vincular los incidentes a
problemas existentes para supervisar el número
de incidentes asociados al mismo. La cuenta de
incidente es el número de veces que este
problema particular ha causado un incidente.
Este conteo permite calcular la frecuencia con la
que se presentan los incidentes. Esto sirve para
Coordinador
de problemas
75
identificar problemas no resueltos.
GP 1.3 Relacionar el
incidente al
problema
pendiente
Si el incidente es causado por un problema
excepcional, el incidente debe ser vinculado al
ticket del problema. De ser necesario, el ticket de
problema es puesto al día y el Analista de
Problemas es notificado (por ejemplo, cuando un
workaround ha sido aplicado)
Coordinador
de problemas
GP 1.4 Crear nuevo
problema
Si no se ha establecido el ticket del problema, un
nuevo ticket de problema es generado (por
ejemplo, basado en el ticket del incidente
seleccionado). Los detalles del incidente son
copiados al ticket de problema. Un nuevo
problema puede ser generado de un incidente
certificado (reactivamente), o proactivamente
identificando problemas y errores conocidos
antes de que los incidentes ocurran.
Coordinador
de problemas
GP 1.5 Capturar datos
del problema
Después de que un problema es identificado o
descubierto con exactitud, debe ser registrado. El
Gestor de Problemas llena los detalles del
problema (algunos campos son copiados del
incidente relacionado). Una breve descripción y
la descripción detallada son puestas al día para
definir el problema más detalladamente. El
problema debe ser descrito en términos de
síntomas e impacto del problema desde una
Coordinador
de problemas
76
perspectiva de negocio. El registro de Problemas
consta de las actividades siguientes:
Determinar el servicio afectado y los
ítems de configuración.
Determinar el impacto sobre el negocio
Proporcionar un código de impacto y la
descripción.
Determinar el modelo, la versión, o los
tipos de CI que tienen este problema
particular.
Determinar la frecuencia/recurrencia del
incidente presentado.
Determinar las condiciones específicas en
las cuales una interrupción de servicio
puede ocurrir.
GP 1.6 Categorizar
problema
Determinar la categoría correcta para el ticket
del problema según su nivel de impacto y
urgencia
Coordinador
de problemas
GP 1.7 Vincular
incidentes al
problema
subyacente
Buscar los incidentes que están generando este
problema. Asociar los incidentes al nuevo
problema y continúe con GP 1.8.
Coordinador
de problemas
/ Personal de
Gestión de
Incidentes
GP 1.8 ¿Soluciones
temporales
Verifique la existencia de una solución temporal.
Si es así, vaya a GP1.9. si no lo es, diríjase a
Coordinador
de problemas
77
disponibles? GP1.10.
GP 1.9 Documentar
tareas alternas
Documentar la solución temporal (workaround),
aplicada para el incidente presentado
Coordinador
de problemas
GP1.10 Presentar
problema
Repase y complete los detalles del ticket del
problema, incluyendo la descripción. Guarde el
ticket del problema y actualice la fase en la que
se encuentra, la asignación y la planificación
GP1.11 Analizar
comportamiento
de tendencias
Revisar los eventos y monitorear los datos.
Identificar potenciales problemas como
inconvenientes de capacidad y de rendimiento.
Analizar los datos provistos por la
disponibilidad, capacidad y seguridad para
determinar potenciales problemas
Coordinador
de problemas
GP1.12 Revisión de
fallas reportadas
por los
proveedores
Revisar la información de proveedores
periódicamente para identificar problemas y
errores conocidos.
Coordinador
de problemas
GP1.13 ¿Relacionados
con problemas
pendientes?
Después de que un potencial problema ha sido
detectado a través del análisis o de la
información provista por los proveedores y
equipo de desarrollo, determine si el
inconveniente ha sido guardado como un
problema o como un error conocido. Si esto es
así, vaya al GP1.1.4 si no vaya al GP1.4.
Coordinador
de problemas
GP1.14 Actualización de Actualizar el ticket del problema, con toda la Coordinador
78
problemas
pendientes
información y detalle. Después de la
actualización, los interesados y el analista
responsable necesitarán esta información para
ser analizada.
de problemas
Tabla 42. Procedimiento para detectar, registrar y categorizar el problema
Autor:Tesista
Fuente:ATIjaguar
Nombre
del
usuario
Tipo
SolicitudFecha Hora
Descripción
Incidente
Descripción
del Problema
Soluciones
Temporales
Tabla 43. Registro de Problema
Autor:Tesista
Fuente:ATIjaguar
79
Ilustración 17. Procedimiento para detectar, registrar y categorizar problemas
Autor:Tesista
Fuente:ATIjaguar
Inicio
Revisar incidentes cerrados GP1.1
¿Hay incidentes causados por el
problema? GP1.2
Relacionar el incidente al problema pendiente GP1.3 Ver
tabla 37.
Crear nuevo problema GP1.4 Ver tabla 43.
Captura datos del problema GP1.5
Categorizar problema GP1.6 Ver
tabla 31.
Vincular incidentes al problema subyacente
GP1.7
¿Soluciones temporales
disponibles? GP1.8
Documentar tareas alternas GP1.9 Ver tabla
37.
Presentar problema
GP1.10
Analizar comportamiento de tendencias GP1.11ver
tabla 42.
Revisión de fallas reportadas por los
proveedores GP1.12
¿Relacionados por problemas
pendientes? GP1.13ver tabla
42.
FIN
SI
NO
SI
SI
Actualización de problemas pendientes
GP1.14ver tabla 42.
NO
80
b. Priorizar problemas
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
GP 2.1 Evaluar la
prioridad del
problema
La prioridad del problema es evaluada en base al
impacto, urgencia, severidad, frecuencia y
riesgo. Debido a restricciones, es importante
enfocarse en los problemas que tengan más
impacto para el negocio.
Gestor de
problemas
GP2.2 Discutir el
problema con
los interesados
Discutir el problema con los dueños del servicio
para la aprobación en la asignación de la
prioridad para resolver el problema.
Gestor de
problemas
GP2.3 ¿El problema
está
correctamente
documentado?
Basados en la revisión con los dueños del
servicio, determinar si el problema está
correctamente documentado y categorizado. Si
esto es así, vaya al punto GP2.4, caso contrario,
vaya al procedimiento para detectar, registrar y
categorizar problemas GP1.5 y actualice los
detalles del problema.
Gestor de
problemas
GP2.4 ¿El problema
requiere una
investigación?
Después de la revisión con los dueños del
servicio, determinar si se continúa con la
investigación del problema o prorrogarlo. Si
continúa con la investigación, vaya al GP2.5,
caso contrario, vaya a GP2.7.
Gestor de
problemas
GP2.5 Calendarización Determinar las fechas para la atención del Gestor de
81
del problema problema. Las fechas son determinadas en base a
la prioridad y el impacto de los servicios
afectados. Este plan también considera los
parches y soluciones temporales disponibles. El
problema se asigna al responsable del grupo.
problemas
GP2.6 Informar a los
interesados
Informar a los dueños del servicio sobre la
planeación y los recursos asignados a la
investigación del problema. Actualizar al
Coordinador de Problemas sobre el mismo
Gestor de
problemas
GP2.7 ¿El problema no
es tan relevante?
Determinar si se cierra el problema o se aplaza
por un tiempo específico. Es posible que el
problema no requiera de una cantidad de
esfuerzo elevado para su investigación. Si el
problema no es reconocido como el inicio de un
inconveniente por los dueños del servicio, cierre
del caso siguiendo el procedimiento de cierre de
caso SD7.1 y documente la razón. Si el problema
aún es relevante, vaya al punto GP2.8
Gestor de
problemas
GP2.8 Aplazar el
problema y
documentar las
razones
Aplazar el problema por un tiempo específico.
Documentar la razón y actualizar el estatus del
problema al estado aplazado. Periódicamente, el
Gestor de Problemas debe revisar los problemas
diferidos para determinar acciones apropiadas.
Gestor de
problemas
Tabla 44. Procedimiento para priorizar problemas
Autor: Tesista
Fuente:ATIjaguar
82
Ilustración 18. Procedimiento para priorizar problemas
Autor: Tesista
Fuente:ATIjaguar
Evaluar la prioridad del problema GP2.1
Ver tabla 35
¿El problema
está correctam
ente document
Calendarización del problema GP2.5 Ver tabla 43.
Informar a los
interesados GP2.6
Aplazar el problema y documentar las
razones GP2.8
¿El problema no es tan
relevante?
SI
NO
SI
Inicio
Discutir el problema con
los interesados GP2.2.
¿El problema requiere una investigación
? GP2.4
Procedimiento para detectar, registrar y categorizar problemas GP1.5 Ver tabla 31
Cierre de caso SD7.1
FIN
NO
NO
SI
SI
83
c. Investigar y diagnosticar el problema
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
GP 3.1 Coordinador de
análisis de
Causa Raíz
Determine las aptitudes requeridas y los recursos
para la investigación del problema. Definir y
asignar las tareas para la resolución, al Analista
de Problemas quién será responsable de
encontrar la Causa Raíz del mismo. La fecha
asignada a la atención del problema será fijada
por el Coordinador de Problemas. Recursos
adicionales pueden ser utilizados para este
análisis. Monitoree las salidas de las tareas
asignadas al Analista de Problemas.
Coordinador
de problemas
GP3.2 Diagnosticar e
investigar
El Analista de Problemas revisa la tarea del
problema e investiga y diagnostica. Determina
una solución temporal y trabaja por encontrar la
Causa Raíz.
Analista de
Problemas
GP3.3 ¿Causa Raíz
encontrada?
Si es así, continúe al GP3.4; si no, vaya al GP3.5 Analista de
Problemas
GP 3.4 Documentar la
Causa Raíz
Documente la Causa Raíz, y dicha tarea puede
ser cerrada. El Coordinador de Problemas
informará sobre el progreso. Continúe al proceso
GP3.10
Analista de
Problemas
GP 3.5 ¿Solución Si es así, continúe al GP 3.6. si no, vaya al GP Analista de
84
temporal
identificada?
3.9. Problemas
GP 3.6 Test de solución
temporal
Pruebe la solución temporal para verificar la
factibilidad de su solución a los incidentes
relacionados.
Analista de
Problemas
GP 3.7 ¿Solución
exitosa?
Si es así, vaya al GP 3.8: si no vaya al GP3.9. Analista de
Problemas
GP 3.8 Documentar
soluciones
temporales
Actualice la solución temporal e informe a los
diseños del servicio
Analista de
Problemas
GP 3.9 ¿Continuar con
el análisis de la
Causa Raíz?
El Analista de Problemas determina si tiene la
habilidad para investigar y determinar la Causa
Raíz del problema. Si es así, continúe al GP 3.2;
SI NO, VAYA AL GP 3.10.
Analista de
Problemas
GP 3.10 Cerrar tareas del
problema
El Analista de Problemas cierra la tarea y
documenta las razones por las que la Causa Raíz
no fue encontrada. Si el Analista de Problemas
no puede encontrar la Causa Raíz, cierra la tarea.
Continúe a GP 3.11.
Analista de
Problemas
GP 3.11 ¿La causa Raíz
está
determinada?
El Coordinador de Problemas valida los
resultados de la tarea. Si la Causa Raíz es
determinada, vaya al GP 3.14, si no, vaya al GP
3.12 y determine qué recursos adicionales serán
necesarios o si el escalamiento es requerido
Coordinador
de Problemas
GP 3.12 ¿Recursos Determinar qué recursos adicionales serán Coordinador
85
adicionales
necesarios?
necesarios para investigar la Causa del
Problema. Si es así, vaya al GP 3.13; si no, vaya
al GP 3.14.
de Problemas
GP 3.13 Notificar al
Gestor de
Problemas
Escalar al Gestor de Problemas. Informar al
Gestor de Problemas que existen recursos
adicionales necesarios para la resolución del
problema y modifique la fase del problema a un
estado previo. Si es necesario, vaya al
procedimiento para planificar y priorizar
problemas GP 2.1.
Coordinador
de Problemas
GP 3.14 ¿La causa es por
un error
conocido
pendiente?
Determinar si la Causa Raíz de este problema
está relacionada a la salida de un Error
Conocido. Si es así, vaya al GP 3.15; si no,
adelante el problema a la fase de registrar y
categorizar un Error Conocido GP 4.1.
Coordinador
de Problemas
GP 3.15 Informar al
Gestor de
Problemas
Informar al Gestor de Problemas de la Causa
Raíz y de cualquier dependencia con otro
registro de Error Conocido. La resolución del
problema dependerá de la salida de Error
Conocido.
Coordinador
de Problemas
Tabla 45. Procedimiento para investigar y diagnosticar el problema
Autor: Tesista
Fuente:ATIjaguar
86
Ilustración 19. Procedimiento para investigar y diagnosticar el problema
Autor:Tesista
Fuente:ATIjaguar
Inicio
Controlar
análisis de
Causa Raíz
GP3.1
Diagnosticar
e investigar
GP 3.2 Ver
tabla 43.
Causa
Raíz
Encontra
Causa
Raíz
Encontra
Causa
Raíz
Encontra
Documentar
la Causa Raíz
GP 3.4 Tabla
37.
Test de
solución
temporal
GP3.6
¿Solución
exitosa?
GP3.7
Documentar
soluciones
temporales
GP 3.8 Ver
tabla 43.
Cerrar
tareas del
problema
GP3.10
La Causa
Raíz está
determin
ada?
GP3.11
¿Recurso
s
adicional
¿La causa
es por un
error
conocido
pendient
Informar al
Gestor de
Problemas
GP3.15. Ver
tabla 45.
FIN
Notificar al
Gestor de
Problemas
GP3.13 Ver
tabla 45.
Procedimient
o registrar y
categorizar
un Error
Conocido
GP4.1
Ver tabla 31 y
37.
NO
NO
SI
NO
NO
SI
SI SI
NO
SI
SI
NO NO
SI
87
d. Levantar registro de Error Conocido
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
GP 4.1 Crear nuevo
Error Conocido
Después de que el problema ha sido
exitosamente diagnosticado, un nuevo registro
de Error Conocido es creado usado detalles del
Error Conocido, incluyendo la Causa Raíz y los
CI que están fallando.
Coordinador
de problemas
GP 4.2 Determinar
categorización
Capture la categorización de la Causa Raíz que
se determinó inicialmente en el ticket del
problema
Coordinador
de problemas
GP 4.3 ¿Identificar
soluciones?
Si es aplicable, un workaround temporal también
se documenta. Si un workaround es identificado,
vaya a GP4.4. Caso contrario, continúe con
GP4.6.
Coordinador
de problemas
GP 4.4 ¿La solución ha
sido probada?
Validar si la solución ya ha sido probada. Si lo
fue, continúe con GP4.5. caso contrario, vaya a
GP4.6.
Coordinador
de problemas
GP 4.5 Publicar la
solución
temporal
Actualice la solución documentada en el ticket
del Error Conocido y problema, e informe a las
partes interesadas.
Coordinador
de problemas
GP 4.6 ¿El error es
causado por un
Validar si el error es causado por un cambio
recientemente implementado o liberado (esto es,
Coordinador
de problemas
88
cambio? errores resultantes de un cambio o la incorrecta
aplicación de un cambio). Si el error es
introducido por la reciente aplicación de un
cambio, el cambio podría necesitar ser regresado
(“rollback”). Si el error es causado por un
cambio, continúe con GP4.7. caso contrario,
vaya a GP4.8.
GP 4.7 Asociar el Error
Conocido al
cambio
Registrar los detalles de la implementación del
cambio al Error Conocido.
Coordinador
de problemas
GP 4.8 ¿Continuar con
la investigación
Determine cuando el error conocido debe ser
investigado en más detalle para hablar una
solución o workaround. Si el error conocido
requiere una investigación más a fondo, continúe
con el procedimiento para investigar más a
fondo, continúe con el procedimiento para
investigar el Error Conocido GP5.1. si no, aplace
el problema de acuerdo con la acción GP4.9. se
determina una estimación de los recursos y
habilidades que son necesarios. Esto incluye el
número de días que se requiere, personal,
duración y costos adicionales. Se verifica cuando
la solución modifica la prioridad o planificación
para la resolución del problema. Si una solución
efectiva es encontrada, las fechas objetivo para
Gestor de
problemas
89
resolver el Error Conocido pueden ser
modificadas. Si una solución no es encontrada, la
prioridad del Error Conocido debe
incrementarse. Actualice la planificación para la
investigación y la línea de tiempo de la solución.
Si se requiere, la planificación se discute con las
partes interesadas. Si el Error Conocido no se
resuelve, se debe tomar la decisión de continuar
con la definición de otra solución candidata, o si
se aplaza el problema.
GP 4.9 Aplazar
problema y
explicar las
razones
El problema y Error Conocido son aplazados por
un tiempo específico, asignándole la prioridad
más baja. Después del periodo, el problema es
revisado para determinar los pasos a seguir
Gestor de
problemas
Tabla 46. Procedimiento para Levantar registro de Error Conocido
Autor:Tesista
Fuente:ATIjaguar
90
Ilustración 20. Procedimiento para Levantar registro de Error Conocido
Autor:Tesista
Fuente:ATIjaguar
Inicio
Revisar
incidente 2.1
¿Identificar
soluciones?
¿El Error es
causado por un
Asociar el Error
Conocido al Cambio GP4.7 Ver tabla 37.
Publicar la solución
temporal GP4.5 Ver tabla 43.
¿La solución ha sido
probada
Determinar
categorización
GP4.2 Ver
tabla 31.
Requiere
escalamient
FIN
Aplazar
problema y
explicar las
razones GP4.9
NO
NO
NO
SI
SI
Procedimiento para investigar el Error Conocido GP5.1
SI
NO
91
e. Resolución y Cierre del problema
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
GP 5.1 Coordinar la
investigación
del Error
Conocido
El Coordinador de Problemas asigna una o más
tareas a los analistas de problemas para
investigar y determinar las soluciones apropiadas
o reparaciones para el Error Conocido.
Coordinador
de problemas
GP 5.2 Investigar y
diagnosticar
Determine las posibles soluciones o reparaciones
temporales para el Error Conocido. Dependiendo
de la prioridad e impacto del error conocido,
enfóquese en definir una solución temporal que
pueda ser propuesta o implementada dentro de
un corto plazo de tiempo. Determine las
soluciones candidatas para resolver el Error
Conocido. El analista de problemas determina si
está en condiciones de resolver el error, o si se
requiere de recursos adicionales (esto es,
habilidades y tiempo).
Analista del
problema
GP 5.3 ¿Solución
identificada?
Si una solución candidata es encontrada,
continúe con GP5.4. si no, continúe con GP5.5.
Coordinador
de problemas
GP 5.4 Documento
propuesto de
solución
Finalice la documentación de la solución en la
tarea de Error Conocido. Asegúrese de incluir las
acciones necesarias para implementar la solución
Coordinador
de problemas
92
GP 5.5 Cerrar tareas de
Error Conocido
Después de terminar, el Analista de Problemas
cierra la tarea. El estado de cierre marca la tarea
como completada con éxito, o no. El
Coordinador de Problemas es notificado de este
evento.
Coordinador
de problemas
GP 5.6 Verificar y
validar el
resultado de las
tareas
Revise la solución propuesta, según lo indicado
por el Analista de Problemas. La solución se
define en la tarea. Ponga al día el Error Conocido
con las actualizaciones de la tarea. Determine si
la solución propuesta es aceptable (por ejemplo,
mediante pruebas o discusiones con otros
especialistas técnicos). Si hay varias soluciones
que están definidas, seleccione la mejor
solución. Asegúrese de que la validación del
proceso incluye las siguientes consideraciones:
Los costos y los recursos necesarios para
implementar la solución.
Riesgos para implementar la solución
Coordinador
de problemas
GP 5.7 ¿La
investigación
del Error
Conocido ha
sido
Completada?
Determine si se termina la investigación y si hay
una solución identificada y documentada. Si una
solución adecuada es identificada (incluido el
costo y las limitaciones de recursos), continúe
con el GP5.8, si no, continuar con GP5.1. si una
solución es determinada satisfactoriamente, y si
no hay un workaround todavía, el Coordinador
Coordinador
de problemas
93
de Problemas (junto con el Gestor de
Problemas), debe determinar si todavía hay una
necesidad de encontrar una solución. Si una
resolución permanente se puede implementar
rápidamente, puede que no haya necesidad de
continuar trabajando en la definición de
soluciones. Si la planificación y ejecución de una
solución permanente toma mucho tiempo o es
demasiada costosa, entonces el trabajo para
identificar una solución efectiva debe continuar.
GP 5.8 Finalizar el caso Documente la solución, de poseer, incluyendo el
impacto y relevancia del problema. Si es el caso,
detalle una estimación de los costos y los
recursos requeridos para implementar la solución
Coordinador
de problemas
Tabla 47. Procedimiento para la Resolución y Cierre del problema
Autor:Tesista
Fuente:ATIjaguar
94
Inicio
Coordinar la
investigación
del Error
Conocido GP5.1
¿Solución identificada?
GP5.3
Asociar el Error
Conocido al Cambio GP4.7
Documento propuesto de
solución GP5.4
Investigar y
diagnosticar
GP5.2
Requiere escalamientoIN2.
6
FIN
Aplazar
problema y
explicar las
razones GP4.9
NO
SI
NO
SI
Verificar y validar el resultado de las
tareas GP5.6
Ilustración 21. Procedimiento para la Resolución y Cierre del problema
Autor:Tesista
Fuente:ATIjaguar
95
3.4. Lineamientos para la implementación de un Centro de Servicios
La estructura que mejor se ajusta a la empresa es la de Centro de Servicios Centralizado, ya
que contará con un solo nodo central de contacto entre usuarios.
3.4.1. Definición de medios de contacto con el Centro de Servicios
Para el contacto del usuario con el Centro de Servicios, se definieron los siguientes medios de
contacto.
Vía telefónica
Vía correo electrónico
Vía documentación (oficio, memorándum)
3.4.2. Niveles de soporte para atención de solicitudes de servicio
Para la atención de solicitudes de servicio y requerimientos de servicios de TI, se definió el
siguiente modelo de soporte basado en 4 niveles.
Nivel
Cero
Centro de Servicios
Front – Atención telefónica
Primer
Nivel
Soporte Técnico
Segundo
Nivel
Redes
Aplicativos
Base de Datos
Especialistas
Tercer
Nivel
Fabricantes
Servicios
Socios autorizados
(partners)
Proveedores
96
Nivel de soporte Descripción
Nivel Cero:
ServiceDesk
Corresponde al Centro de Servicios, quien
debe atender y registrar las peticiones de
servicio del usuario, los datos del incidente
o requerimiento reportado. Asigna
soluciones temporales comparando el
incidente reportado con la KEDB (Tabla
37.). Deberá informar el estado de atención
al requerimiento.
Primer Nivel:
Soporte Técnico
Suministra atención de primer nivel,
soporte a problemas menores que requieren
un nivel de conocimiento menor
Segundo Nivel:
Especialistas y técnicos del área de
Tecnología de la Información
Son los especialistas y técnicos del área
con conocimientos superiores, recursos
específicos para la infraestructura,
aplicaciones, dominios tecnológicos para la
solución de incidentes y atención de
requerimientos.
Tercer Nivel:
Proveedores: Desarrolladores,
fabricantes, prestadores de
servicios (outsourcing)
Corresponden a las áreas de desarrollo
interno y externo, así como proveedores y
fabricantes. Cuando el segundo nivel de
soporte no puede solucionar los incidentes,
estos son escalados a un tercer nivel con el
conocimiento necesario para dar una
97
atención oportuna.
Tabla 48. Niveles de soporte para atención de solicitudes de servicio
Autor: Tesista
Fuente: ATIjaguar
3.4.3. Tipos de solicitudes al Centro de Servicios
Las interacciones pueden ser de diversos tipos y pueden incluir los detallados en la tabla.
Tipo de
solicitud
Descripción Ejemplos
Interrupciones
de servicio
Cualquier falla o degradación
del servicio que afecte la
operación normal del usuario.
Equipo no enciende.
Desbloqueo de usuarios
Cambio de contraseña
Caída de enlace de internet y
datos
Mensaje de error
Sistema lento
Solicitudes de
servicio
Solicitudes que implican un
cambio pero no modifican la
CMDB o solicitudes que
requieran definiciones y
planeación para su ejecución en
campo.
Instalación de software no
licenciado.
Cambio de tóner de impresora.
Cambio de un periférico.
Creación y retiro de un usuario.
Actualización plantilla de
equipos.
Solicitudes de
información
Cuando los usuarios llaman a
preguntar cómo realizar una
Aplicativos de escritorio.
Como se cambia la contraseña en
98
operación específica en un
aplicativo de escritorio y otros.
aplicativo de negocio.
Actividades básicas en
informática.
Quejas y
reclamos
Inconformidades reportadas por
parte de los usuarios asociadas a
la prestación del servicio.
Tiempo de respuesta no adecuado
a un incidente.
Solución no acorde a las
necesidades del cliente.
Tabla 49. Tipo de Solicitudes al Centro de Servicio
Autor: Tesista
Fuente: ATIjaguar
3.4.4. Horario de atención del Centro de Servicios
El horario de atención definido para el Centro de Servicios de la Corporación ATIjaguar
deberá cumplir lo siguiente:
De lunes a viernes de 8:30 a 17:30
Feriados y fines de semana: Se contará con un planificador de turnos, en el que se asigna
semanalmente una persona del grupo de trabajo de TI, quien estará a cargo de atener
incidentes de tipo urgentes solamente, es decir, que paralicen los servicios cruciales que
afecten al negocio.
3.4.5. Definición de roles en el Centro de Servicios
A continuación se presenta la definición de roles que se deberá cumplir en el Centro de
Servicios de la corporación:
99
ROL EMPLEADO DE TI
Operador del Centro de
Servicios
Operador Centro de Servicios – Asistente técnico
Usuario Contacta al Centro de Servicios para realizar una
petición de servicio (información, soporte técnica,
cambios).
Gestor de casos Especialistas de:
- Aplicativos
- Base de Datos
- Redes y Comunicaciones
Analista de casos Asistente técnico
Soporte Primer Nivel
Técnicos de:
- Aplicativos
- Base de Datos
- Redes y Comunicaciones
Manejador de Conflictos Asiste Quejas y Reclamos
Tabla 50. Roles del Centro de Servicio
Autor: Tesista
Fuente: ATIjaguar
3.4.6. Definición del perfil del Operador del Centro de Servicios
A fin de asegurar el nivel de satisfacción del cliente, se define a continuación el perfil del rol
“Operador del Centro de Servicios”, el cual debe cumplir con las siguientes actitudes y
aptitudes:
100
Atención orientada al usuario.
Metódico, organizado
Habilidad interpersonal
Capaz de entender y estar familiarizada con los objetivos de la empresa.
Capaz de comprender y aceptar que:
El problema del usuario afecta los objetivos de la empresa.
Sin el usuario no tendría objeto la implementación de un ServiceDesk
El usuario es un experto en su propio campo
3.4.7. Matriz RACI para el Centro de Servicios
En la siguiente matriz se establecen los roles y responsabilidades en la función de ServieDesk
Procedimiento
Ges
tor
de
Caso
s
An
ali
sta d
e ca
sos
Op
erad
or
de
Cen
tros
de
Ser
vic
ios
Usu
ari
o
Recepción y registro de caso I R/A C
Asignación de caso A/I C R
Escalamiento de casos R/A C I
Monitoreo SLA C I R/A 1
Monitoreo de OLA y UC C I R/A I
Manejo de quejas C C R/A C
Cierre de caso C C R/A C
Tabla 51. Matriz RACI para el Centro de Servicios
Autor: Tesista
Fuente: ATIjaguar
101
3.4.8. Actividades del Centro de Servicio
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
SD1.1 Crear nuevo
registro
Al recibir una petición de servicio se
procede a crear un nuevo caso a partir
de la interacción. Se toma datos como
fecha y hora, inicio, tipo de solicitud
(información, detención de servicio,
queja, etc).
Operador
Centro de
Servicio
SD1.2 ¿Queja o
reclamo?
El contacto con el usuario, ¿es
categorizado como una queja? En caso
afirmativo, diríjase al procedimiento
manejo de quejas SD6.1. Caso
contrario, vaya a SDI.3.
Operador
Centro de
Servicio
SD1.3 Definir título /
Descripción /CI
Proveer un título apropiado y una
descripción para el ticket. Esto podría
ser basado en el texto del evento. El
ítem de configuración afectado debe ser
determinado.
Operador
Centro de
Servicio
SD1.4 Seleccionar
categoría y
prioridad
Seleccione una categoría y prioridad
apropiada seleccionado el nivel de
impacto y urgencia.
Operador
Centro de
Servicio
SD1.5 Asignar caso al
grupo
Basado en la categorización de
prioridad y los servicios afectados, el
Operador
Centro de
102
incidente es automáticamente asignado
al grupo responsable del servicio. El
operador del Centro de Servicios
verifica que la asignación es correcta.
Servicio
SD1.6 ¿Información
completa y
correcta?
Proceder a confirmar con el usuario los
datos receptados y registrados.
Contactar nuevamente al usuario de ser
necesario. Verificar que la información
sea completa. En caso afirmativo vaya a
SDI.7, caso contrario, tomar
nuevamente la información del caso,
vaya a SD1.1.
Operador
Centro de
Servicio
SD1.7 Proporcionar
número de caso
El operador del Centro de Servicios
provee el número de caso al usuario
como referencia a su incidente.
También provee un tiempo máximo de
respuesta al caso, basado en el SI.A que
se aplique.
Operador
Centro de
Servicio
Tabla 52. Actividades del Centro de Servicio
Autor: Tesista
Fuente: ATIjaguar
103
NO
SI
Ilustración 22. Procedimiento para la recepción y registro de caso
Autor: Tesista
Fuente: ATIjaguar
3.4.9. Categorización
Esta parte se hace referencia en la Tabla 31.
3.4.10. Escalamiento del nivel de prioridad de incidentes
Esta parte se hace referencia en la Tabla 35.
3.4.11. Asignación de caso
Inicio
Crear nuevo registro SD1.1
¿Informaci
ón
correcta y
Definir título / Descripción
/ CI SD1.3
Asignar caso al grupo
SD1.5
¿Queja
o
reclamo
Seleccionar categoría y privacidad
SD1.4
Procedimie
nto manejo
de quejas
SD1.6
FIN
Proporcionar número de caso SD1.7
104
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
SD2.1 Revisar cola de
casos
registrados
El Gestor de Casos monitorea la cola de
casos y revisa todos los casos entrantes
recibidos.
Gestor de
Casos
SD2.2 ¿Información
correcta y
completa?
El Gestor de casos verifica que exista
registrada suficiente información en el
ticket del caso para diagnosticar y que
está asignado al correcto grupo de
soporte. Caso afirmativo, continúe con
SD2.3 caso contrario, vaya al
procedimiento de recepción y registro
caso SD1.6 a fin de que el Operador del
Centro de Servicios complete y/o corrija
la información registrada.
Gestor de
Casos
SD2.3 Asignar caso al
analista
El gestor acepta el caso y lo asigna al
Analista de Casos para la respectiva
investigación y diagnóstico
Gestor de
Casos
SD2.4 ¿Puede resolver
el caso?
El Analista de Casos revisa el incidente
asignado para ver si lo puede resolver.
En caso afirmativo, vaya a SD2.5. Caso
contrario, vaya a SD2.6
Analista de
Casos
SD2.5 Acepta el caso El Analista de Casos acepta el caso
cambiando el estado a “Aceptado” para
proceder al análisis y resolución del
Analista de
Casos
105
caso.
SD2.6 Rechazar caso Si el Analista de Casos determina que
no puede resolver el incidente, procede
a rechazarlo. Cambia el estado del caso
de “Asignado” a “Rechazado”, y provee
las razones del rechazo (se requiere
escalar el incidente, falta información,
no pertenece al grupo asignado, etc). El
ticket del caso es entonces retornado a
la cola de incidentes para la
reasignación por parte del Coordinador
de Incidentes. Volver a SD2.1
Analista de
Casos
Tabla 53. Procedimiento para la asignación de un caso
Autor: Tesista
Fuente: ATIjaguar
106
Inicio
Revisar cola de casos
registrados SD2.1
Asignar caso al analista SD2.3
Acepta el caso SD2.5
¿Informa
ción
completa
y correcta
Procedimiento
recepción y
registro de una
petición de
servicio SD1.6
FIN
Rechazar caso SD2.6
Si
NO
SI ¿Puede
resolve
r el
caso?
NO
Ilustración 23. Asignación de caso
Autor: Tesista
Fuente: ATIjaguar
107
Escalamiento de casos
A fin de cumplir con un mecanismo de escalamiento adecuado, se considerarán los siguientes
criterios de clasificación para asignación de casos a los grupos especializados:
Nivel de Soporte Criterio de Clasificación
Nivel Cero Solicitudes de información
Quejas
Solicitud de renombramiento de claves
Solicitud de creación de cuentas de correo y de perfil, por parte de
las gerencias o de la gerencia de Talento Humano.
Casos que puede ser resueltos mediante soluciones detalladas en la
base de datos de errores conocidos.
Primer Nivel Uso básico de aplicaciones, soporte en sistemas operativos
Problemas con cuentas de red.
Proyectos o responsabilidades asignados a un agente específico
Otros problemas que puedan ser resueltos dentro de los plazos de
tiempo estipulados para el tipo de incidente.
Segundo Nivel Problemas que requieran capacitación avanzada o atributos de
acceso específicos. Otros problemas que no puedan ser resueltos
por el Primer Nivel, dentro de los plazos de tiempo estipulados
para el tipo de incidente.
Tercer Nivel Problemas que puedan requerir cambios en aplicaiones,
componentes o en procedimientos.
Problemas crónicos que requieran una investigación para su
resolución.
108
Problemas no resueltos por el Segundo Nivel.
Tabla 54. Criterios de clasificación de casos para definición
Autor: Tesista
Fuente: ATIjaguar
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
SD3.1 ¿Resolución de
caso a tiempo?
El Gestor de Casos verifica que la
resolución esperada coincide con el
SLA objetivo. Si la resolución del caso
está cumpliendo con lo estipulado en el
SLA, se continúa con la resolución del
caso, procedimiento resolución y
recuperación de un incidente IN2.1.
caso contrario vaya a SD3.2
Gestor de
Casos
SD3.2 ¿Requiere
escalamiento de
nivel?
¿Es necesario reasignar el caso aun
grupo diferente de soporte con mayor
conocimiento o se requiere que un nivel
superior jerárquico autorice la
asignación de un mayor número de
recursos (personal, equipo, cambios en
el CI, etc)? Caso afirmativo vaya a
SD3.3. caso contrario volver a SD 3.1
Analista de
Casos
SD3.3 Escalamiento de
nivel
El Analista de Casos registra las
acciones que se han tomado hasta el
Gestor de
Casos
109
momento e informa al Gestor de Casos
quien procede a reasignar el caso a un
siguiente nivel (vertical u horizon6tal),
para agilizar el proceso de resolución.
Esta actividad es notificada al Operador
del Centro de Servicios.
Tabla 55. Procedimiento para el escalamiento de casos
Autor: Tesista
Fuente: ATIjaguar
Ilustración 24. Escalamiento de casos
Autor: Tesista
Fuente: ATIjaguar
Inicio
¿Resoluci
ón de caso a
tiempo? SD3.1
¿Requiere
escalamiento de
nivel
Escalamiento
de nivel SD3.3
Procedimiento
resolución y
recuperación
de un incidente
IN2.1
FIN
NO SI
SI
110
3.4.12. Monitoreo de los niveles de servicio
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
SD4.1 ¿Vencimiento
del SLA?
Ha excedido la fecha o tiempo límite
para esta interacción? En caso
afirmativo, recurra al Gestor de Casos
para iniciar el procedimiento de
escalamiento SD3.1. Caso contrario,
vaya a SD 4.2.
Operador de
Centro de
Servicios
SD4.2 Consultar nuevo
tiempo de
resolución
Revisar si el caso será resuelto dentro
del tiempo estipulado. Contacto al
gestor a fin de validar si el grupo
asignado puede resolver todavía el caso
a tiempo sin soporte o recursos
adicionales.
Operador de
Centro de
Servicios
SD4.3 ¿El caso se
resuelve a
tiempo
Si el Gestor de Casos del grupo
asignado estima que el caso relacionado
puede ser aún resuelto a tiempo, vaya a
SD4.4. caso contrario, vaya a SD3.1
para escalar inmediatamente.
Operador de
Centro de
Servicios
SD4.4 Comunicar
estado del caso
Identifique cuales usuarios o grupo de
usuarios son afectados por el caso
relacionado. Envíe un comunicado para
Operador de
Centro de
Servicios
111
NO SI SI
SI
NO NO
informar el estado del caso a todos los
usuarios afectados y tiempo de
resolución esperado. Vaya a SD4.5.
SD4.5 ¿Caso resuelto a
tiempo?
Caso afirmativo, no son necesarias
acciones adicionales, vaya al
procedimiento de cierre SD7.1. Caso
contrario vaya a SD4.1.
Operador de
Centro de
Servicios
Tabla 56. Procedimiento para el monitoreo de acuerdos de nivel de servicio (SLA).
Autor: Tesista
Fuente: ATIjaguar
Ilustración 25. Monitoreo de SLA.
Autor: Tesista
Fuente: ATIjaguar
Inicio
¿Venci-miento
del SLA? SD4.1
Consul-tar
nuevo tiempo
de resolu-
ción SD4.2
¿El caso se
resuelve a
tiempo? SD4.3
Comunicar
estado del
caso SD4.4
¿Caso resuelto a
tiempo?
SD4.5
Cierre de
caso
SD7.1
Escala-miento
de casos SD3.1
FIN
112
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
SD5.1 Revisar el
estado y
progreso de la
resolución de
caso
Verifique que el caso pueda ser resuelto
antes de la fecha y tiempo límite
especificados en el acuerdo de nivel
operativo (OLA), o en el contrato de
soporte (UC), según corresponda
Operador de
Centro de
Servicios
SD5.2 Analista
asignado
disponible
Circunstancias externas (por ejemplo:
finalización de un turno, enfermedad, o
día feriado), pueden causar que un
Analista de Casos no esté disponible.
Operador de
Centro de
Servicios
SD5.3 ¿Reasignación
requerida?
Caso afirmativo, vaya a SD2.3 para
asignación del caso a otro analista. Al
culminar con el procedimiento, retornar
a SD5.4. caso contrario, continúe con el
monitoreo.
Operador de
Centro de
Servicios
SD5.4 ¿Vencimiento
de OLA o UC?
Caso afirmativo, inicie el proceso de
escalamiento de caso SD3.1. caso
contrario, vaya a SD5.5
Operador de
Centro de
Servicios
SD5.5 Obtener
actualización de
estado del caso
por los analistas
(OLA) o
proveedores
Contacte al Analista de Casos para
recibir la actualización de estado del
caso. Si éste es reportado a un
proveedor, contáctelo para obtener
dicha actualización.
Operador de
Centro de
Servicios
113
(UC)
SD5.6 ¿El caso se
resolvió en el
tiempo
acordado?
Consulte con el Gestor de Casos si el
caso puede o no aún ser resuelto a
tiempo. En caso afirmativo, vaya a
SD5.7. caso contrario, vaya a SD3.1
para escalar el caso inmediatamente.
Operador de
Centro de
Servicios
SD5.7 Tomar medidas
de seguimiento
si se requiere
El Gestor de casos determina que
acciones de seguimiento son requeridas
para resolver el caso de acuerdo con el
OLA/UC. Si se requiere, realizará las
acciones necesarias. La resolución del
caso continúa hasta su cierre, vaya a SD
5.8.
Gestor de
Casos
SD5.8 ¿Cierre de
incidente?
Caso afirmativo, no hay más acciones
necesarias, vaya al procedimiento de
cierre de casos SD 7.1. Caso contrario,
vaya a SD5.1.
Operador
Centro de
Servicios
Tabla 57. Procedimiento para el monitoreo de OLA’s o UC’s
Autor: Tesista
Fuente: ATIjaguar
114
Ilustración 26. Procedimiento manejo de quejas.
Autor: Tesista
Fuente: ATIjaguar
3.4.13. Cierre de Caso
ID del
Proceso
Procedimiento
o Decisión
Descripción Rol
SD6.1 ¿Confirmación
con el usuario?
El Operador del Centro de Servicios
debe contactar al usuario a fin de
confirmar la solución satisfactoria del
caso. En caso afirmativo ir a SD7.2,
caso contrario ir a SD4.1 para controlar
el SLA y continuar con la resolución
Operador
Centro de
Servicios
SD7.2 Registrar
resolución en
KEDB
El Operador del Centro de Servicios
registra el proceso de resolución a la
KEDB
Operador
Centro de
Servicios
Inicio
Registro de
información de
queja SD 6.1
Queja aceptada
SD 6.2
Investigar
causa de
queja SD 6.3
Tomar medidas
con el usuario
SD 6.4
Actualización y
cierre de queja
SD 6.5 Inicio
115
SD7.3 Actualizar
información en
CMDB
El Operador del Centro de Servicios
actualiza la información en la CMDB
sobre los ítems de configuración (CI)
implicados en el incidente.
Operador
Centro de
Servicios
SD7.4 Cerrar caso El Operador del Centro de Servicios
provee al usuario la información de
resolución del caso y menciona el
exitoso cierre del ticket de solicitud de
atención.
Operador
Centro de
Servicios
Tabla 58. Procedimiento para el cierre de caso
Autor: Tesista
Fuente: ATIjaguar
Ilustración 27. Procedimiento cierre de casos
Autor: Tesista
Fuente: ATIjaguar
Inicio
¿Confirm
a-ción
con el
usuario?
SD7.1
Registrar
resolución en
KEDB SD7.2
Actualizar
información en
CMDB SD7.3
Cerrar caso
SD7.4
FIN
Procedimiento
monitoreo de
SLA SD4.1
116
CAPITULO 4
4. CONCLUSIONES Y RECOMENDACIONES
4.1. Conclusiones
Se planteó una alternativa de Centro de Servicio centralizado, con la finalidad de brindar
un mejor servicio a todas las áreas de la empresa y lograr cumplir objetivos empresariales.
De acuerdo a la comparación que se realizo en el inciso 1.5 de ésta tesis, se puede concluir
que es mejor utilizar la versión de ITIL 2011 y COBIT 5.0.
Si se implementara y automatizara un Centro de Servicio se reduciría costes mediante una
eficiente asignación de recursos, además de reducir el impacto negativo sobre el negocio y
sus servicios.
4.2. Recomendaciones
Adquirir una herramienta de software para la automatización de los procesos de incidentes
y problemas que se realizó en esta tesis.
Realizar capacitaciones al personal tanto de atención al cliente como a los de personal
técnico con la finalidad de asegurar que lo detallado en ésta tesis logre cumplirse.
Verificar periódicamente los contratos de servicio que se tienen con los clientes para que
de esta manera, el nivel de madurez de la empresa no se vea afectado.
117
GLOSARIO DE TÉRMINOS
A
Acuerdos de Nivel de Servicio.- Es un acuerdo por escrito firmado entre un Proveedor de
Servicios de TI y un cliente TI. Describe el servicio TI documenta los objetivos de nivel de
Servicio y específica las responsabilidades del Proveedor de Servicios de TI y el cliente. SLA
define la garantía que un Servicio debe ofrecer y describe la utilidad del Servicio.
Acuerdos de Nivel de Operación (OLA).- Acuerdo entre un Proveedor de Servicio de TI y otra
parte de la misma organización que ayuda a prestar los servicios, incluye los incumplimientos de
objetivos debido al fallo de una actividad de soporte.
B
Base de Datos de Errores Conocidos (KEDB).- Base de datos que contiene todos los registros
de Errores Conocidos creados por la Gestión de Problemas y que son utilizados por la gestión de
Incidentes y Problemas.
Base de Datos de Conocimiento.- Es en la que se almacena la información correspondiente a
soluciones de errores conocidos, workaround o soluciones temporales.
Base de Datos de Configuración (CMDB).- Es una base de datos utilizada para almacenar
registros de configuración a lo largo de todo su ciclo de vida.
C
Catálogo de Servicios.- Una base de datos o documento estructurado con información sobre todos
los Servicios TI activos, incluyendo los disponibles para el despliegue. Incluye información sobre
productos finales, precios, punto de contacto y procesos perdidos y solicitudes. Existe un catálogo
de Servicios de Negocio y un Catálogo de Servicios Técnicos.
118
Causa raíz.- La causa original o subyacente de un Incidente o Problema.
E
Elemento de Configuración (CI).-“Es un activo de servicio que tiene que ser gestionado para
ofrecer un Servicio TI”19
Evento.- Es un cambio de estado importante para un Elemento de Configuración (CI), es una
alerta o notificación creada por cualquier Servicio de TI, CI o una herramienta de supervisión.
Escalado de Incidentes.- Existen 2 tipos de escaldo:
Escalado Funcional
Escalado Jerárquico
Error Conocido.- Es un Problema que tiene una causa raíz documentada y una Solución
Temporal.
F
Función.- “Es un equipo o un grupo de personas y las herramientas que usan para realizar uno o
más procesos o actividades”.20
G
Gestión del Servicio
Según ITIL, la Gestión del Servicio de define como “Un conjunto de capacidades organizativas
especializadas para proporcionar valor a los clientes en forma de servicios”.21
19
Libro de Transición de Servicios 20
Libro Estrategia del Servicio 21
Libro Estrategia del Servicio
119
Debe transformar las capacidades y los recursos en Servicios de valor. Las organizaciones TI
deben actuar como Proveedores de Servicio para asegurarse de satisfacer las necesidades de los
clientes, para llevar a cabo la ITSM.22
Gestión de Incidentes.- Proceso responsable de gestionar todos los incidentes a través del ciclo
de vida. El objetivo primario es recuperar el Servicio TI para los usuarios lo antes posible.
I
Incidente.- Es una interrupción imprevista o una reducción en la calidad de un Servicio TI,
cualquier cosa que pueda afectar a un Servicio TI en el futuro.
Impacto.- Es una medida del efecto de un Incidente, un Problema o un Cambio en los procesos
del negocio.
ITIL
Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información
(ITIL) se ha convertido en el estándar mundial de facto en la Gestión de Servicios Informáticos.23
L
Los Indicadores Clave de Rendimiento (KPI’s).- “Se utilizan para evaluar si los procesos de
una organización de TI, los procesos de ITIL funcionan según las expectativas. Generalmente, las
definiciones exactas de los KPI‟s ITIL variarán dependiendo de la naturaleza de la organización.
Existen, sin embargo, una cantidad de KPI‟s típicos utilizados para evaluar los procesos de ITIL.
22
IT Service Management, Gestión de Servicio de TI 23
osiatis. (2013). Gestión de Servicios TI. 20 mayo, de osiatis Sitio web:
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/service_desk/vision_general_service_desk/vision_general_servi
ce_desk.php
120
Los KPI‟s cumplen con las recomendaciones de ITIL y han sido mejorados con elementos de
COBIT.”24
M
Métrica.- Son una escala de medida que se define en términos de un estándar, son los parámetros
usados para los procesos de cuantificación que requieren medidas.
Métricas de tecnología.- Se asocian por lo general a métricas basadas en componentes y
aplicaciones por ejemplo rendimiento, disponibilidad.
Métricas de procesos.- CSFs, KPIs y métricas de actividad para ayudar a determinar el buen
estado en general del proceso.
Métricas de servicio.- Son métricas para medir el rendimiento del servicio end to end.
P
Problema.- Es la causa de uno o más incidentes, aún cuando la causa no se conoce normalmente
en el momento se crea un registro del Problema.
Petición de Servicio.- Petición generada por lo general por un usuario solicitando información,
asesoramiento o un cambio de estándar. Normalmente es gestionada por un Centro de Servicios y
no requiere una Petición de Cambio (RFC), algunos ejemplos son: resetear contraseña o
proporcionar Servicios TI.
Proceso.- Según ITIL “es una serie de actividades diseñadas para lograr un objetivo específico.
Un proceso asume una o más entradas definidas y las convierte en resultados definidos”.25
24
IT Process map.(2013). Métricas ITIL - KPIs ITIL. 4 agosoto, de IT Process map Sitio web: http://wiki.es.it-
processmaps.com/index.php/M%C3%A9tricas_ITIL_-_KPIs_ITIL 25
Libro Estrategia del Servicio
121
Prioridad.- Es una categoría que se usa para identificar la importancia relativa de un Incidente, un
problema o un Cambio. Se basa en el Impacto y en la Urgencia y se usa para identificar el tiempo
necesario para tomar medidas.
R
Rol.- Es un conjunto de responsabilidades, actividades y autoridades definidas en un proceso y
asignadas a una persona o equipo.
RACI.- Ejemplo de una matriz de autoridad, que se puede utilizar en organizaciones para indicar
roles y responsabilidades en relación a procesos y actividades.
Registro de Error Conocido.- Se crea para garantizar un diagnóstico más rápido para encargarse
de dichos Problemas. Se crea para apoyar la gestión y resolución de Incidentes, guarda todos los
registros garantizando un diagnóstico más rápido.
S
Servicios de la Tecnología de la Información
Jan Van Bon, en el libro. Fundamentos de la gestión de servicios TI, define al servicio como “un
medio de entregar valor a los clientes, facilitando los resultados necesarios sin ser los propietarios
de los costes ni de los riesgos específicos”.26
Un servicio TI está formado por las tecnologías de la información, personas y procesos
Servicio de TI.- Está formado por las tecnologías de la información, personas y procesos. Un
Proveedor de Servicios TI ofrece este servicio a uno o más clientes para presentar apoyo a sus
procesos de negocio.
T
26
Jan Van Bon “fundamentos de la gestión de servicios TI”
122
Tecnología de la Información
De acuerdo a lo definido por Asociación de Tecnología de la Información de América, Tecnología
de la información es “el estudio, diseño, desarrollo implementación, soporte o dirección de los
sistemas de la información computarizados, en particular de software y hardware de
computadoras”.27
Otro concepto indica que la Tecnología de la Información se entiende como “aquellas
herramientas y métodos empleados para recabar, retener, manipular o distribuir información. La
tecnología de la información se encuentra generalmente asociada con las computadoras y las
tecnologías afines aplicadas a la toma de decisiones”.28
Tipos de Servicio
Servicios Internos.- Son servicios entregados entre departamentos o unidades de
Negocio de la misma organización
Servicios Externos.- Servicios ofrecidos a clientes externos
U
Un Contrato de Soporte (UC).- Contrato entre Proveedor de Servicios TI y proveedor tercero
(Proveedor de Servicios externos) y consta de:
Los términos y condiciones básicas del Servicio
Descripción y alcance del Servicio
La variedad de cargas de trabajo
La información de la gestión
Las responsabilidades y dependencias
27
http://www.itnews.ec/marco/000149.aspx 28
Bologna y Walsh, 1997
123
Urgencia.- Es una medida de cuánto tiempo pasará hasta que un Incidente, un Problema o un
Cambio tenga un impacto en el negocio.
124
ANEXOS
125
BIBLIOGRAFÍA
1. CORONA, Mauricio. (2011). ITIL edición 2011. 3 agosto, de Mauricio Corona.
2. FRANCAVILLA, Carlos (2012). Comparación de COBIT 4.1 mayo, de Carlos
Francavilla.
3. ITPRENEURS Nederland B.V. (2013). Manual del Alumno. Nederland :TPreneurs
Nederland B.V.
4. MAPEO DE ITIL V3 CON COBIT 4.1
5. HTTP://WWW.ITSM.HR/BAZA%20ZNANJA/MAPPING%20ITILV3%20COBIT41.PDF.
6. VARGAS, Carlos. (2012). ServiceDesk. 17 septiembre.
7. ISACA, http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx.
8. OSIATIS S.A. (2008). Centro de servicios (ServiceDesk) Implementación. 4 agosto, de
Osiatis S.A.
126
ANEXOS
En los anexos tenemos las encuestas que se realizaron al personal de la empresa.
Top Related