UNIVERSIDAD CENTRAL DEL ECUADOR … · Procedimiento para la resolución y recuperación de un incidente. ... lo mencionado con el documento ... mayor capacidad de alcanzar sus objetivos

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 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 18. Área de Administración de Redes y Comunicaciones


Tabla 20. Á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



Á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



itil-ed-2011

Cambios al libro de Diseño de Servicio



Á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




itil-ed-2011

Cambios al libro de Transición del Servicio



Á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



itil-ed-2011

Cambios al libro Operación de Servicio



Á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



itil-ed-2011

Cambios al libro Mejora Continua del Servicio



Á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



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


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:




17

empresa de extremo a extremo

Funciones de TI y Negocio

Tabla 8. Nuevo Modelo de Referencia de Procesos


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


Carlos Francavilla


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


Carlos Francavilla


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


Carlos Francavilla


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


Carlos Francavilla


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.


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


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.

http://www.isaca.org/COBIT/Pages/COBIT-5-spanish.aspx

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

tp://www.isaca.org/COBIT/Documents/COBIT5-Framework-Sp

tp://www.isaca.org/COBIT/Documents/COBIT5-Framework-Sp

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:




36

Ilustración 11. Procesos Habilitadores

Autor: ISACA. (2014). INTRODUCCION. 10 DE ABRIL, de ISACA


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




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


15



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


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


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


Autor:Tesista


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


Autor:Tesista


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


Autor:Tesista


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


Autor:Tesista


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


Autor:Tesista


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


Autor:Tesista


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


Autor:Tesista

48


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


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


office 2010 instalado en cada


Registro de compras




Registro de transporte




Provincial Registro de usuarios

Logìstica

Tabla 23. Tabla de Servicio

Autor:Tesista


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


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.



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.



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


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


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


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


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


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


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


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


Baja


Tabla 35. Matriz de asignación de prioridades y tiempo de resolución promedio a

solicitudes.

Autor:Tesista


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


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


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.

http://www.itsm.hr/baza%20znanja/Mapping%20ITILV3%20COBIT41.pdf


126

ANEXOS

En los anexos tenemos las encuestas que se realizaron al personal de la empresa.