proyecto de grti - gestion de incidencias service desk fia data
TRANSCRIPT
UNIVERSIDAD DE SAN MARTÍN DE PORRESFACULTAD DE INGENIERIA Y ARQUITECTURA
“Gestión de Incidencias aplicando ITIL V3.0en el área de ServiceDesk FIA – DATA”
CURSO:Gestión de Recursos de Tecnologías de la Información
PROFESOR:Ing. Augusto O. Becerra Pacherres
SECCION:
51I
INTEGRANTES:
- Pérez Huarcaya Erick 2006129859
- Salazar Mendoza Héctor 2003116169
- Valladares Castillo, Miguel 1999226189
2014-0
INDICE
1. INTRODUCCION..................................................................................................................6
2. Resumen del Proyecto.........................................................................................................7
3. Descriptores Temáticos........................................................................................................8
4. Funciones............................................................................................................................. 8
5. Alcance................................................................................................................................. 9
6. Descripción de la Problemática............................................................................................9
7. REVISIÓN CRÍTICA DE LITERATURA..............................................................................12
8. MARCO TEORICO – ITIL...................................................................................................13
8.1 ITIL (Information Technology Infrastructure Library)...................................14
8.2 Service strategy (estrategia del servicio)....................................................14
8.3 Service design (diseño del servicio).............................................................15
8.4 Service transition (transición del servicio).................................................15
8.5 Service operation (operación del servicio).....................................................16
8.6 Categorías del incidente..................................................................................16
8.7 Prioridades y SLA.............................................................................................16
8.8 Nivel de escalamientos....................................................................................17
8.9 VERSIONES DE ITIL.........................................................................................17
ITIL® versión 2..................................................................................................................17
ITIL® versión 3..................................................................................................................17
8.10PROCESOS.......................................................................................................18
8.11SERVICE DESK – FIA DATA............................................................................19
8.12FUNDAMENTOS DE LA GESTIÓN TI...............................................................20
SOPORTE AL SERVICIO.................................................................................................20
8.13VENTAJAS DE ITIL...........................................................................................23
VENTAJAS DE ITIL PARA CLIENTES/USUARIOS:...................................................23
VENTAJAS DE ITIL PARA IT:........................................................................................23
8.14CRÍTICAS A ITIL................................................................................................24
8.15LIBROS DE ITIL v3............................................................................................25
8.16 ESTRATEGIA DEL SERVICIO.........................................................................26
8.17 DISEÑO DEL SERVICIO....................................................................................26
8.18 TRANSICIÓN DEL SERVICIO..........................................................................27
8.19 OPERACIÓN DEL SERVICIO...........................................................................27
8.20 MEJORA CONTINUA DEL SERVICIO............................................................28
2
8.22CÓMO HACER EXITOSO UN PROYECTO ITIL...............................................29
8.23DIAGRAMA DE GANTT.....................................................................................30
8.24MATRIZ RACI....................................................................................................32
8.25DIAGRAMA DE PROCESOS.............................................................................34
8.27DIAGRAMA CAUSA – EFECTO........................................................................36
9 MAPA DE PROCESOS DE LA GESTION DE INCIDENCIAS DE SERVICE DESK DE LA FIA 38
10. CADENA DE VALOR DE LA FIA........................................................................................39
11. ORGANIGRAMA DE LA FIA..............................................................................................40
12. GESTION DE INCIDENCIAS.............................................................................................41
1.1. OBJETIVOS:......................................................................................................41
1.2. ALCANCE:.........................................................................................................41
1.3. Participantes y Capacitación Requerida........................................................43
1.4. Controles de Entrada.......................................................................................43
1.5. Diagrama de Contexto de Proceso de Gestión de Incidencias....................43
1.6. Diagrama del Proceso de Gestión de Incidencias.........................................44
1.7. Tabla de Descripción del Proceso..................................................................45
13. PROCESOS DE GESTIÓN DE INCIDENCIAS..................................................................48
1. PROCESO DE IDENTIFICACION REGISTRO..................................................48
i. NOMBRE DEL PROCESO:...............................................................................48
ii. ACTIVIDADES DEL PROCESO:......................................................................48
iii. OBJETIVOS:........................................................................................................48
iv. ALCANCE............................................................................................................49
v. E/S PROCESO....................................................................................................49
vi. CONTROLES:......................................................................................................49
vii. ROLES:.................................................................................................................49
viii. MECANISMO DE CONTROL:...........................................................................49
ix. FORMATO DE HOJA.........................................................................................49
x. FLUJOGRAMA IDENTIFICACIÓN REGISTRO.............................................50
xi. PLANTILLA O CARTILLA DE CONTROL DE IDENTIFICACIÓN Y REGISTRO..........................................................................................................................50
xii. DIAGRAMA DE BLOQUES DE IDENTIFICACIÓN Y REGISTRO..............50
xiii. ALMACEN DE DATOS:.....................................................................................51
xiv. RACI:.....................................................................................................................51
2. PROCESO DE CLASIFICACION Y SOPORTE.................................................51
i. NOMBRE DEL PROCESO................................................................................51
3
ii. ACTIVIDADES DEL PROCESO.......................................................................51
iii. OBJETIVOS.........................................................................................................52
iv. ALCANCE............................................................................................................52
v. E/S PROCESO....................................................................................................52
vi. CONTROLES.......................................................................................................52
vii. ROLES..................................................................................................................53
viii. MECANISMO DE CONTROL............................................................................53
ix. FORMATO DE HOJA WEB...............................................................................54
x. FLUJOGRAMA....................................................................................................54
xi. PLANTILLA O CARTILLA DE CONTROL......................................................55
xii. DIAGRAMA DE BLOQUES...............................................................................55
xiii. ALMACÉN DE DATOS.......................................................................................55
xiv. RACI......................................................................................................................56
3. PROCESO DE COMPARACION.......................................................................56
i. NOMBRE DEL PROCESO................................................................................56
ii. ACTIVIDADES DEL PROCESO.......................................................................56
iii. OBJETIVOS.........................................................................................................56
iv. ALCANCE............................................................................................................57
v. E/S PROCESO....................................................................................................57
vi. CONTROLES.......................................................................................................57
vii. ROLES..................................................................................................................57
viii. MECANISMO DE CONTROL............................................................................58
ix. FORMATO DE HOJA.........................................................................................58
x. FLUJOGRAMA....................................................................................................58
xi. PLANTILLA O CARTILLA DE CONTROL......................................................59
xii. DIAGRAMA DE BLOQUES...............................................................................59
xiii. ALMACÉN DE DATOS.......................................................................................59
xiv. RACI......................................................................................................................59
4. PROCESO DE INVESTIGACION Y DIAGNOSTICO INICIAL...........................60
i. NOMBRE DEL PROCESO................................................................................60
ii. ACTIVIDADES DEL PROCESO.......................................................................60
iii. OBJETIVOS.........................................................................................................61
iv. ALCANCE............................................................................................................61
v. E/S PROCESO....................................................................................................61
4
vi. FLUJOGRAMA....................................................................................................62
vii. DIAGRAMA DE BLOQUES...............................................................................63
5. PROCESO DE RESOLUCION Y RECUPERACION.........................................63
i. NOMBRE DEL PROCESO................................................................................63
ii. OBJETIVOS.........................................................................................................63
iii. ALCANCE............................................................................................................63
iv. ACTIVIDAD DEL PROCESO, ENTRADA, SALIDA......................................63
v. CONTROLES.......................................................................................................64
vi. ROLES..................................................................................................................65
vii. FORMATO DE HOJA.........................................................................................65
viii. FLUJOGRAMA....................................................................................................66
ix. DIAGRAMA DE BLOQUES...............................................................................66
6. PROCESO DE CIERRE.....................................................................................67
i. NOMBRE DEL PROCESO................................................................................67
ii. OBJETIVOS.........................................................................................................67
iii. ALCANCE............................................................................................................67
iv. ACTIVIDADES DEL PROCESO, ENTRADA Y SALIDA..............................67
v. CONTROLES.......................................................................................................67
vi. ROLES..................................................................................................................67
vii. FORMATO DE HOJA.........................................................................................68
viii. FLUJOGRAMA....................................................................................................69
ix. DIAGRAMA DE BLOQUES...............................................................................69
14. MÉTRICAS......................................................................................................................... 70
i. NÚMERO TOTAL DE INCIDENCIAS................................................................70
ii. NÚMERO DE INCIDENCIAS ACUMULADAS...................................................70
iii. TIEMPO MEDIO DE RESOLUCION DE INCIDENTES.....................................70
15. APÉNDICE......................................................................................................................... 71
A. GLOSARIO DE TÉRMINOS...............................................................................71
B. ACRÓNIMOS.....................................................................................................72
16. CONCLUSIONES...............................................................................................................73
17. RECOMENDACIONES......................................................................................................74
18. BIBLIOGRAFÍA...................................................................................................................75
5
GESTIÓN DE INDICIDENCIAS EN EL ÁREA DE SERVICE DESK - FIA DATA
1. INTRODUCCION
En la actualidad, muchas áreas de sistemas de las empresas no tienen una
adecuada gestión de incidencias en sus equipos productivos, es por ello
que, muchas veces el personal de soporte de sistemas que atiende estos
eventos, no tiene definido el proceso de escalamiento o los tiempos de
atención en que deben ser atendidos según la prioridad del mismo.
Muchas veces el servicio de Mesa de Ayuda llega a recuperarse, pero no se
logra investigar y descubrir las causas, se tienen incidentes que no son
resueltos en realidad. Todo esto repercute en la imagen y la capacidad del
personal de TI así como en la productividad del negocio.
Es por ello, que tomando en cuenta esta necesidad en el área de
Tecnologías de Información de las empresas, se presenta el siguiente
trabajo, para poder tener procesos definidos de Gestión de Incidencias con
una visión de organización para la atención de estos eventos. Para el
análisis de los procesos anteriormente mencionados, el presente trabajo se
basará en las mejores prácticas recomendadas por el manual de ITIL v3.
Las organizaciones dependen cada vez más de las tecnologías de la
información para alcanzar sus objetivos corporativos. La misión del
departamento de tecnologías de la información es ofrecer servicios fiables,
de alta calidad y a un coste aceptable, por lo que debe incorporar de
manera sistemática las mejores prácticas del mercado para la optimización
continua de sus procesos.
6
2. Resumen del Proyecto
La información es un recurso imprescindible para cualquier organización
que quiera ofrecer a sus clientes una mayor calidad. Las tecnologías de la
información ofrecen la posibilidad de crear una infraestructura única
mediante la que capturar, procesar, distribuir, explotar y almacenar esa
información. Se trata de una herramienta estratégica para potenciar la
eficacia de la actividad asistencial, la asimilación y puesta en práctica del
conocimiento derivado de la investigación, y la optimización en el
despliegue y consumo de recursos que esta actividad requiere.
La primera fase en todo centro asistencial es la de registrar la incidencia,
en esta fase almacenaremos información del tipo de quién informa del
problema, que síntomas se extraen del problema, cuál es el equipo
involucrado, etc.
La siguiente fase será clasificar la incidencia y asignar el trabajo a realizar
a un grupo de soporte o a un técnico, desarrollando para ello un estudio de
los niveles de información llegando hasta tres niveles de gestión.
Una tercera fase vendrá definida por la investigación de la causa de la
incidencia y comparación con otras incidencias parecidas, para ello se
necesitará tener la información bien clasificada. De esta forma se
desarrollará implícitamente una base de conocimiento (Knowledge Base)
con información no destacable por su cantidad sino por su calidad para
nuestra organización, de esta forma se conseguirá el recuperar la
información de forma rápida, fácil y eficaz.
7
3. Descriptores Temáticos
Supervisión Tipificación Detección y Registro Clasificación y Soporte Comparación Cierre
4. Funciones
Las actividades de la Gestión de ITIL – Gestión de incidencias SERVICE DESK - FIA están íntimamente ligadas con la monitorización y supervisión, al ser ésta la responsable de que la infraestructura de la organización funcione, especialmente en lo que se refiere a la prestación de servicios.
Las principales funciones de una correcta Gestión de incidencias de SERVICE DESK - FIA se resumen en:
Se gestionan adecuadamente los riesgos.
Se reduce el periodo de interrupción del servicio por causas de fuerza mayor.
Se mejora la confianza en la calidad del servicio entre clientes y usuarios.
Sirve de apoyo al proceso de Gestión de ITIL – Gestión de incidencias SERVICE DESK - FIA
Realizar Actividades de rendimiento o mantenimiento en beneficio de los equipos de Gestión Técnica o de Aplicaciones.
Creación de Back-up y restauración de archivos en beneficio de los equipos de Gestión Técnica y de Aplicaciones, así como de los usuarios.
8
5. Alcance
El primer paso necesario para desarrollar una Gestión de incidencias SERVICE DESK - FIA es establecer claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política.
La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación de la Gestión de incidencias SERVICE DESK - FIA puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión.
Es imprescindible establecer el alcance de la Gestión de incidencias SERVICE DESK - FIA en función de:
• Los planes generales de Continuidad del Negocio.
• Los servicios TI estratégicos.
• Los estándares de calidad adoptados.
• El histórico de interrupciones graves de los servicios TI.
• Las expectativas de negocio.
• La disponibilidad de recursos.
6. Descripción de la Problemática
Narrativa del Contexto del Proyecto
La mesa de ayuda por regla general por tratarse de un área de
servicio atraviesa por problemas bastante graves que dañan
la imagen de la compañía y del departamento de sistemas (IT). A
continuación se describen algunos de los problemas más comunes:
Problemas:
• No existe un proceso definido ni un procedimiento de atención
de requerimientos, la mayoría de casos se atienden conforme
ingresan a mesa de ayuda por prioridad de llamada, cuando
un técnico recibe una llamada, éste se traslada directamente
hacia donde se encuentra el usuario para poder solucionar,
dejando el resto de llamadas en cola.
9
• El mesa de ayuda carece de estándares y políticas claras de
atención de casos
• La inadecuada distribución de los recursos hace que un
usuario en ocasiones espere por tiempos prolongados
• El volumen de llamadas que ingresan a la mesa de ayuda son
no controlables.
• Como los usuarios no son atendidos se generan re-llamados,
es decir que por un mismo caso los usuarios llaman más de
una vez.
• No existe un método para evaluar a los técnicos ni
un control para organizar las labores de los mismos.
• No existen niveles de servicio, contemplados
en indicadores de gestión o acuerdos de niveles de servicio
que permitan hacer mediciones sobre el proceso.
• Los técnicos que atienden las llamadas cada día tienen más
carga de trabajo y su labor se torna agotadora por la deficiente
distribución de trabajo.
Formulación del Proyecto
Comenzando por los problemas de infraestructura y equipamiento, la
irregularidad en la entrega y calidad de los servicios, los problemas
relacionados con las incidencias, el desempeño deficiente del
personal ya sea por falta de motivación y compromiso o por
deficiencias en sus conocimientos técnicos y académicos y la grave
escasez de recursos para el financiamiento del funcionamiento de los
servicios.
Justificación y Alcances
10
Con la ejecución de este proyecto no solo buscamos mejorar los
procedimientos que actualmente se realizan para la atención de los
pacientes, si no también decrementar el número de quejas y
procesos judiciales, que SERVICE DESK - FIA suele afrontar como
consecuencia de eventos adversos.
Limitaciones
La gestión de incidencias toma como entrada el ingreso de datos
históricos a la CMDB y como centro piloto en el ambiente de pruebas
de la oficina de tecnologías de la información y comunicaciones para
luego ser extrapolado a la organización y como salida la emisión de
reportes de incidentes.
Objetivos
Los Objetivos Generales
Detectar cualquiera alteración en los servicios TI. Registrar y
clasificar estas alteraciones.
Objetivos estratégicos:
Se resumen en:
o Garantizar la pronta recuperación de los servicios (críticos) TI
tras un desastre.
o Establecer políticas y procedimientos que eviten, en la medida
de lo posible, las perniciosas consecuencias de un desastre o
causa de fuerza mayor.
o Construir soluciones innovadoras para enlazar los objetivos de
la organización con los del área de tecnología.
o Asegurar que existan procesos integrados y centralizados.
o Aclarar los roles y responsabilidades de los integrantes del
área de TI – SERVICE DESK - FIA.
11
7. REVISIÓN CRÍTICA DE LITERATURA
El cuerpo de la revisión es la única parte que varía de un estudio a otro. El cuadro 1 esquematiza la estructura a seguir dependiendo del diseño del estudio que seleccionó el revisor. Dado que todas las revistas sobre evidencia utilizan el mismo esquema.
12
8. MARCO TEORICO – ITIL
HISTORIA
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. Iniciado como una guía para el gobierno del Reino Unido (UK), la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización.
ITIL 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. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70 – 80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.
13
8.1ITIL (Information Technology Infrastructure Library)
“Conjunto de lineamientos sobre mejores prácticas para la administración
de servicios de tecnología de información. ITIL es propiedad de la OGC
(Office of Government Commerce) y consiste de una serie de publicaciones
que proporcionan lineamientos sobre el aprovisionamiento de calidad en
los servicios de TI y sobre los procesos e instalaciones necesarios para
soportarlos”
Durante muchos años, ITIL ha sido una de las mejores guías prácticas para
eldiseño y el control de sistemas de operaciones TI. Sin embargo, los
proyectos de implantación de procesos ITIL fracasaban. No se consideraba
que implicaba un cambio cultural en la organización en donde participan
personas, procesos y herramientas (Kolthof et. al 2008:15-45). Para
realizar una implantación de ITIL, se tiene que saber dónde se quiere llegar
en la gestión de procesos, apoyo de la gerencia y que la gente involucrada
en la organización se vaya formando en ITIL.
Actualmente, ITIL está en la versión 3 desde el año 2007 donde se enfoca
en el ciclo de vida del servicio, reforzando con nuevos procesos los
conceptos de soporte al servicio y la distribución del servicio en lo que se
basa la versión 2 de ITIL. En la versión con la cual se trabajará (versión
3.0), se presentan los siguientes puntos claves que se muestran en la
figura 1.1 y se describen a continuación:
8.2Servicestrategy (estrategia del servicio)
“Tiene como objetivo proporcionar a las organizaciones las habilidades para
diseñar, desarrollar e implementar la Gestión de Servicios como un acto
estratégico, así como para pensar y actuar de una manera estratégica.
Asimismo, formula las directrices y guías a seguir en la gestión dentro del
modelo de ciclo de vida del servicio”
14
Ilustración1:ITIL.
8.3Servicedesign (diseño del servicio)
“Tiene como objetivo diseñar un servicio nuevo o modificado para su
introducción en el entorno real. Asimismo, se preocupa en entregar
servicios redituables y de calidad, así como asegurar el cumplimiento de
los requerimientos del negocio”.
Establece los siguientes procesos: gestión de niveles de servicio, gestión
del catálogo de servicios, gestión de la disponibilidad, gestión de la
seguridad de información, gestión de proveedores, gestión de la
capacidad y gestión de la continuidad de los servicios de TI.
8.4Servicetransition (transición del servicio)
“Tiene como objetivo establecer las expectativas del cliente acerca de
cómo se puede utilizar el servicio para habilitar los procesos de negocio.
Asimismo, permite que el proveedor de servicios se enfrente a
volúmenes más altos de cambios sin impactar la calidad del servicio”.
15
Establece los siguientes procesos: planeación y soporte en la transición,
gestión de cambios, gestión de activos de servicio y de configuraciones,
gestión de liberaciones e implementación, validación del servicio y
pruebas, evaluación y gestión del conocimiento.
Establece los siguientes roles: Gerente de Activos de Servicio, Gerente
de Configuraciones, Gerente de Cambios, Comité Asesor de Cambios,
Gerente de Liberaciones e Implementaciones, Gerente de Paquetes y
Creación de Versiones e Implementación.
8.5 Serviceoperation (operación del servicio)
“Tiene como objetivo la gestión continua de la tecnología que se emplea
para entregar y soportar los servicios. Asimismo, ejecuta y mide los
planes, diseño y optimizaciones. Desde el punto de vista del cliente, la
operación del servicio es donde se percibe el valor real, pues la
necesidad de efectividad para ayudar a que el negocio cumpla sus
resultados es lo que impulsa la eficiencia de las operaciones”.
Establece los siguientes procesos: Gestión de Eventos, Gestión de
Incidentes, Gestión de Solicitudes del Servicio, Gestión de Problemas y
Gestión de Accesos.
8.6 Categorías del incidente
Implica tipificar el incidente según su origen y su utilidad. Se encuentra
dividido en distintos niveles desde los más genéricos hasta los más
específicos.
8.7Prioridades y SLA
Los incidentes se han priorizado según su impacto hacia el negocio.
Estas prioridades van desde la prioridad 1 (prioridad más alta) hasta la
prioridad 7 (prioridad más baja). Asimismo, cuando se genera un
16
incidente, este maneja varios umbrales de tiempo para la generación,
atención y resolución del mismo.
Cabe resaltar que estos tiempos o SLA no corresponden a un acuerdo
oficial con las áreas de negocio por lo que representan valores iniciales
que en el tiempo deben afinarse.
8.8Nivel de escalamientos
Cada tipo de incidente tiene un grupo de personas a quienes se les
notifica sobre el impacto de cada incidente. Conforme vaya avanzado el
tiempo de resolución de cada incidente, la notificación se realizará a
cargos superiores cada vez.
8.9VERSIONES DE ITIL
ITIL® versión 2
ITIL®FoundationCertificate
ITIL® v2 Foundations for Service Management
ITIL®PractitionerCertificate
ITIL® v2 PractitionerSupport&Restorer
ITIL® v2 PractitionerRelease& Control.
ITIL® Manager en IT Service Management.
IT Service Management: Service Support.
IT Service Management: ServiceDelivery.
ITIL® versión 3
ITIL®FoundationCertificate.
ITIL® v3 Foundations for Service Management.
ITIL® Foundation Bridge v2 a v3.
ITIL®IntermediateLevelCertificate.
17
ServiceLifecycle Modules.
ServiceCapability Modules.
ManagingAcrosstheLifecycle.
ITIL® Expert in IT Service Management Certificate.
8.10 PROCESOS
Los procesos asociados directamente a la fase de estrategia son:
GESTIÓN FINANCIERA: Responsable de garantizar la presentación de servicios con la correcta relación entidad – precio.
GESTIÓN DEL PORTAFOLIO DE SERVICIOS: Responsable de la inversión en servicios nuevos y actualizados que ofrezca el máximo valor al cliente minimizando a su vez los riesgos y costes asociados.
GESTIÓN DE LA DEMANDA: Responsable de la armonización de la oferta de los servicios ofrecidos con las demandas del mercado.
Ilustración 2: Siete pasos del proceso de mejora de ITIL.
18
8.11 SERVICE DESK – FIA DATA
El área de ServiceDesk, que forma parte de FIA – DATA, es el área
especializada en la gestión - solución de incidencias y requerimientos.
Manteniendo proactivamente informados a los usuarios USMP de todos los
eventos relevantes con el servicio que les pudieran afectar.Representa la
interfaz para los usuarios de todos los servicios TIC ofrecidos por la FIA con
un enfoque centrado en los procesos.
Brinda soporte de primer nivel a los usuarios en los sistemas de
información, equipos tecnológicos y herramientas ofimáticas, de acuerdo a
los procedimientos establecidos.
El área de ServiceDesk de FIA – DATA, brinda los siguientes servicios:
Servicios de hardware
Servicios de software
Servicio web
Servicio de Comunicaciones
El jefe actual del área es el Ing. Gary Galindo Guerra, y entre sus
principales funciones tiene:
Participar en la elaboración y formulación del Plan Informático de la
Facultad y la USMP.
Planificar y ejecutar la restauración de datos a partir de copias de
respaldo que STI haya realizado de las estaciones de trabajo.
Planificar la preparación de estaciones de trabajo para inicio de ciclo:
computadoras en podio de aulas antes de inicio de ciclo académico.
Renovar periódicamente el personal técnico y de apoyo, previa
capacitación a los postulantes que en su mayoría, son practicantes y
alumnos de la FIA.
Gestionar los incidentes relacionados con las TIC desde su
recepción, registro, priorización, atención y cierre; reportados por los
usuarios (alumnos, docentes y personal administrativo).
19
Gestión de informes relacionados a las funciones de la unidad.
Actualmente el SERVICE DESK de la FIA registra las incidencias a través
de los siguientes medios:
Chat
Correo
Llamada
Presencial
8.12 FUNDAMENTOS DE LA GESTIÓN TI
SOPORTE AL SERVICIO
El soporte al servicio se preocupa de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del servicio prestado al usuario.
El siguiente diagrama de los principales aspectos de la metodología de soporte al servicio según los estándares ITIL.
EMPRESA – CLIENTE – USUARIOS:
Clientes: Son los encargados de contratar los servicios TI y a los que hay que rendir cuentas respecto a los acuerdos de nivel de servicio
20
Usuarios: Son aquellos que utilizan los servicios TI para llevar a cabo sus actividades.
Organización: La propia organización TI debe considerarse como otro cliente/usuario más de los servicios TI.
SERVICE DESK:
Debe presentar el centro neurálgico de todos los procesos de soporte al servicio:
Registrando y monitorizando incidencias. Aplicando soluciones temporales a errores conocidos en
colaboración con la Gestión de problemas. Colaborando con la gestión de configuración para asegurar la
actualización de la CMDB. Gestionando cambios solicitados vía peticiones de servicio en
colaboración con la gestión de Cambios y Versiones.
KNOWLEDGE BASE (KB):
La base de conocimiento debe recoger toda la información necesaria para:
Ofrecer una primera línea de soporte ágil y eficaz sin necesidad de recurrir a escalados.
Realizar una tarea comercial y de soporte al negocio.
GESTIÓN DE INCIDENTES:
Tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.
La gestión de incidentes no debe confundirse con la gestión de problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente, sino exclusivamente a restaurar el servicio.
GESTIÓN DE PROBLEMAS
Sus funciones principales son:
21
Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
Determinar posibles soluciones Proponer las peticiones de cambio (RFC). Realizar revisiones Post Implementación (PIR) en colaboración con la
gestión de cambios.
GESTIÓN DE CAMBIOS
Sus principales funciones son:
Evaluar el impacto de los posibles cambios sobre la infraestructura de TI.
Tramitar los cambios mediante procesos y procedimientos estandarizados y consistentes.
Revisar, junto a la gestión de problemas y los usuarios los resultados Post – Implementación (PIR).
GESTIÓN DE VERSIONES
Entre sus funciones se encuentran:
Implementar los cambios. Llevar a cabo reparaciones de emergencia. Desarrollar planes de "roll – out" (lanzamiento de nuevas versiones) y
"back – out" (recuperación de versiones antiguas).
GESTIÓN DE CONFIGURACIONES
Sus principales funciones pueden resumirse en:
Llevar el control de todos los elementos de configuración de la infraestructura TI
Realizar auditorías periódicas de configuración. Proporcionar información precisa sobre la configuración TI a todos
los diferentes procesos de gestión.
8.13 VENTAJAS DE ITIL
22
VENTAJAS DE ITIL PARA CLIENTES/USUARIOS:
La provisión de Servicios IT se convierte en más "customer-oriented" y los SLA's de Calidad de Servicio mejoran la relación.
Los Servicios son descriptos más detalladamente, en idioma del usuario.
La Calidad y el Costo de los Servicios son monitoreados, ganándose control.
La Comunicación entre los usuarios y el Departamento de Sistemas se simplifica, y se hace más clara, consiguiendo una rápida mejora percibida.
VENTAJAS DE ITIL PARA IT:
El Departamento de IT desarrolla un más clara estructura, se convierte en más eficiente y más focalizada en los objetivos corporativos.
El Management es más controlado, junto con los cambios que conlleva el mismo.
El nuevo mapa de Procesos provee un framework que permite decidir la tercerización de ciertos procesos en caso ser convenientes.
Siguiendo las BestPractices ITIL, se lidera un cambio cultura hacia la Provisión de Servicios basados en el Management de Calidad de ISO 9000.
ITIL provee un uniforme marco de referencia de comunicación interna y externa hacia proveedores, junto con la estandarización e identificación de procedimientos.
Problemas Potenciales de ITIL: Cuando el Proceso de Cambio es manejado sólo con recursos internos, se corre el riesgo de no poder cambiar el "status quo", porque implicaría marcar "errores" en vez de oportunidades de mejorar y "responsables", en vez de Líderes del Cambio.
Un Proyecto sin Hitos intermedios puede llevar mucho tiempo y esfuerzo, y requerir un cambio cultural en la organización importante. Un enfoque demasiado ambicioso puede llevar a la frustración, porque los objetivos no son cumplidos.
23
Si la estructura de Procesos se transforma en un objetivo en sí mismo, la calidad del Servicio puede verse afectada. En este caso, los procedimientos se transforman en obstáculos burocráticos que quieren ser evitados.
Puede no haber mejoras, debido a la falta de entendimiento sobre el alcance de los Procesos, o los Indicadores de Performance, o como los procesos deberían ser controlados.
La mejora en la provisión de los Servicios y la reducción de costos puede ser insuficientemente visibles.
Una implementación exitosa requiere la involucración y compromiso de personal de todos los niveles de la organización. Dejando el desarrollo de las estructuras de Procesos a solo especialistas puedo provocar el aislamiento de los mismos a través de opiniones sobre nuevas direcciones que no serán seguidas por los otros departamentos. Esto puede ser fácilmente mitigado por un Liderazgo de Cambio externo a la Compañía que recomiende desde afuera de la Cultura de la Compañía.
Si hay una insuficiente inversión en Herramientas de Soporte, los procesos no van a ser mejorados, ya que requieren cierto grado de automatización. Recursos adicionales pueden ser requeridos si la organización ya tiene sobrecargados recursos para las actividades de Management de Servicios de IT.
8.14 CRÍTICAS A ITIL
ITIL ha recibido críticas de varios frentes. Entre ellas: El hecho de que muchos defensores de ITIL parecen creer que es un marco holístico y completo para el gobierno de TI. Su tendencia a convertirla en una religión.
Como señala Jan van Bon (autor y editor de muchas publicaciones de Gestión de Servicios de TI): Hay mucha confusión sobre ITIL, procedente de todo tipo de malentendidos sobre su naturaleza. ITIL, como afirma la OGC, es un conjunto de buenas prácticas. La OGC no afirma que dichas mejores prácticas describan procesos puros, ni tampoco que ITIL sea un marco diseñado como un modelo coherente. Eso es lo que la mayoría de sus usuarios hacen de ella, probablemente porque tienen una gran necesidad de dicho modelo.
24
El columnista CIO Magazine Dean Meyer también ha expuesto algunos puntos de vista cautelosos sobre ITIL, incluyendo cinco trampas típicas tales como "convertirse en esclavo de definiciones desactualizadas" y "dejar que ITIL se convierta en religión". Como Meyer señala, ITIL "no describe el abanico completo de procesos necesarios para ser líderes. Se centra en [...] gestionar servicios actuales".
La calidad de los volúmenes de la biblioteca se considera desigual. Por ejemplo, van Herwaarden y Grift señalan que "la consistencia que caracterizaba los procesos de soporte al servicio [...] se pierde en gran medida en los libros de entrega de servicio".
8.15 LIBROS DE ITIL v3
En ITIL v3 reestructura el manejo de los temas para consolidar el modelo de "ciclo de vida del servicio" separando y ampliando algunos subprocesos hasta convertirlos en procesos especializados. Esta modificación responde a un enfoque empresarial para grandes corporaciones que utilizan ampliamente ITIL en sus operaciones y aspira a consolidar el modelo para conseguir aún mejores resultados. Es por ello que los especialistas recomiendan que empresas emergentes o medianas no utilicen ITIL v3 si no cuentan con un modelo ITIL consolidado y aspiran a una expansión a muy largo plazo. ITIL v3 consta de 5 libros basados en el ciclo de vida del servicio:
1. Estrategia del Servicio
2. Diseño del Servicio
3. Transición del Servicio
4. Operación del Servicio
5. Mejora Continua del Servicio
8.16 ESTRATEGIA DEL SERVICIO
Se enfoca en el estudio de mercado y posibilidades mediante la
búsqueda de servicios innovadores que satisfagan al cliente tomando en
cuenta la real factibilidad de su puesta en marcha. Asimismo, se
analizan posibles mejoras para servicios ya existentes. Se verifican los
25
contratos con base en las nuevas ofertas de proveedores antiguos y
posibles nuevos proveedores, lo que incluye la renovación o revocación
de los contratos vigentes. Entre los procesos, tenemos lo siguiente:
Gestión Financiera.
Gestión del Portafolio.
Gestión de la Demanda.
8.17 DISEÑO DEL SERVICIO
Una vez identificado un posible servicio el siguiente paso consiste en analizar su viabilidad. Para ello se toman factores tales como infraestructura disponible, capacitación del personal y se planifican aspectos como seguridad y prevención ante desastres. Para la puesta en marcha se toman en consideración la reasignación de cargos (contratación, despidos, ascensos, jubilaciones, etc.), la infraestructura y software a implementar. Entre los procesos, tenemos:
Gestión del Catálogo de Servicios.
Gestión de Niveles de Servicio.
Gestión de la Disponibilidad.
Gestión de la Capacidad.
Gestión de la Continuidad de los Servicios de TI.
Gestión de Proveedores.
Gestión de la Seguridad de Información.
8.18 TRANSICIÓN DEL SERVICIO
Antes de poner en marcha el servicio se deben realizar pruebas. Para ello se analiza la información disponible acerca del nivel real de capacitación de los usuarios, estado de la infraestructura, recursos IT disponibles, entre otros.
26
Luego se prepara un escenario para realizar pruebas; se replican las bases de datos, se preparan planes de rollback (reversión) y se realizan las pruebas.
Luego de ello se limpia el escenario hasta el punto de partida y se analizan los resultados, de los cuales dependerá la implementación del servicio. En la evaluación se comparan las expectativas con los resultados reales. Entre los procesos, tenemos:
Gestión de la Configuración y Activos.
Gestión del Cambio.
Gestión del Conocimiento.
Planificación y Apoyo a la Transición.
Gestión de Release y Despliegue.
Gestión Validación y Pruebas.
Evaluación.
8.19 OPERACIÓN DEL SERVICIO
En este punto se monitoriza activa y pasivamente el funcionamiento del servicio, se registran eventos, incidencias, problemas, peticiones y accesos al servicio. Entre los Procesos, tenemos:
Gestión de Incidentes.
Gestión de Problemas.
Cumplimiento de Solicitudes.
Gestión de Eventos.
Gestión de Accesos.
8.20 MEJORA CONTINUA DEL SERVICIO
Se utilizan herramientas de medición y retroalimentación o feedback para documentar la información referente al funcionamiento del servicio, los resultados obtenidos, problemas ocasionados, soluciones implementadas, etc. Para ello se debe verificar el nivel de conocimiento de los usuarios respecto al nuevo servicio, fomentar el registro e
27
investigación referentes al servicio y disponer de la información al resto de los usuarios.
8.21 APLICACIONES ACTUALES DE ITIL A NIVEL INTERNACIONAL
Brian Johnson, integrante del Equipo de Prácticas Globales de Servicios Tecnológicos de CA, y quien fuera parte del equipo del Gobierno Británico que creó este modelo, señaló que "ITIL se ha transformado en un fenómeno en Europa, Asia y América; cada vez son más las empresas que buscan aplicar estas mejores prácticas, capacitando y certificando en este concepto a sus especialistas en tecnología.
28
8.22 CÓMO HACER EXITOSO UN PROYECTO ITIL
Al decidirse por ITIL, la gerencia puede realizar actividades conducentes a investigar, informarse y capacitarse. Pero lo más importante es que, al cabo de un tiempo razonable, decida qué es lo que hará y sea consecuente con eso, incluso considerando en ello a los proyectos planificados antes, como la externalización de algunos servicios.
No siempre las implementaciones ITIL son exitosas, hay varios factores que pueden incidir:
Poco o nulo compromiso de la gerencia: Ningún proyecto puede ser exitoso o desarrollado a su máximo potencial si los líderes de la organización no están comprometidos.
Realizar actividades descoordinadas o desfocalizadas: Un proyecto ITIL es un desafío para el gerente de TI, ya que su desarrollo puede remecer a toda la organización.
No revisar la infraestructura completa: Aunque hay procesos básicos de ITIL, es importante mirar la estructura completa, principalmente, los procesos de administración de seguridad e infraestructura TI, porque de ellos también depende el éxito de ITIL en los procesos de TI.
Gastar mucho tiempo en diagramas complejos: ITIL es una tentación para analistas de procesos, ya que al no existir un modelo detallado y único de implementación, el proyecto deriva en intrincados diagramas de procesos y actividades, que malgastan tiempo y recursos, desmotivando a los participantes.
Falta de instructivos de trabajo: Al tener complejos diagramas de procesos, las instrucciones de trabajo se vuelven tan engorrosas de escribir que muchas veces no se hacen, o las que se construyen son imposibles de ejecutar en el día a día. Deben ser simples e incluir reglas de escalamientos, definición de prioridades, además de ser revisadas periódicamente, ya que pueden mejorarse.
Procesos sin responsables (Rol): En general las organizaciones no están estructuradas en base a una
29
orientación de procesos, sino que en “islas”. El responsable del proceso vela por la complejidad de éste en todas sus etapas y para ello puede atravesar horizontalmente a la organización.
Concentrarse demasiado en el rendimiento: Es común que se dé mucha importancia al monitoreo, en perjuicio de la calidad y de los procesos. La calidad debe ser tan importante como el rendimiento.
Ser ambiciosos: ITIL es bastante extenso, abarca muchos procesos, algunos complejos. Intentar implementarlos todos al mismo tiempo es una tarea imposible. El consejo es evaluar la madurez que se tiene, a qué estado se desea llegar y priorizar su implementación según las necesidades del negocio.
Permitir fronteras interdepartamentales: Algunos procesos pueden atravesar horizontalmente uno o varios departamentos, lo que inevitablemente genera conflicto entre ellos. Este factor se debe contrarrestar con el sólido apoyo de la gerencia y con actividades de gestión del cambio.
8.23 DIAGRAMA DE GANTT
El diagrama de GANTT es una herramienta que le permite al usuario modelar la planificación de las tareas necesarias para la realización de un proyecto. Esta herramienta fue inventada por Henry L. Gantt en 1917.
Debido a la relativa facilidad de lectura de los diagramas de GANTT, esta herramienta es utilizada por casi todos los directores de proyecto en todos los sectores. El diagrama de GANTT es una herramienta para el director del proyecto que le permite realizar una representación gráfica del progreso del proyecto, pero también es un buen medio de comunicación entre las diversas personas involucradas en el proyecto.
Este tipo de modelo es particularmente fácil de implementar con una simple hoja de cálculo, pero también existen herramientas especializadas, la más conocida es Microsoft Project. También existen equivalentes de este tipo de software que son gratis.
30
31
8.24 MATRIZ RACI
El Mapa de Procesos ITIL utiliza una matriz RACI para visualizar las responsabilidades de los roles ITIL en los procesos ITIL.
En RASCI, una ampliación del modelo RACI, se encuentran las siguientes responsabilidades:
R – Responsible (responsable de la ejecución)
Alguien que desempeña una tarea determinada. Para cada tarea en un proceso ITIL existe normalmente un rol ITIL responsable de su ejecución.
A – Accountable (responsable del proceso en conjunto)
Alguien que asume la responsabilidad conjunta final por la correcta y completa ejecución de un proceso y que recibe las informaciones de los responsables de la ejecución del proceso. Normalmente, el Responsable de Proceso asume la responsabilidad conjunta de un proceso y para cada proceso existe un Responsable de Proceso.
C – Consulted (consultado)
Alguien que no está implicado directamente en la ejecución de un proceso pero que da algún tipo de input para el proceso y/o al cual se pide su consejo y opinión.
I – Informed (a informar)
Alguien que recibe las salidas (outputs) de un proceso o a quien se informa de los avances del proceso.
Las matrices RACI tienen sobre todo sentido si múltiples roles asumen diferentes niveles de responsabilidad en varios procesos: Ayudan como simple instrumento a comunicar responsabilidades de forma inteligible y contribuyen a evitar conflictos de competencias.
32
8.25 DIAGRAMA DE PROCESOS
33
El diagrama de flujo o diagrama de actividades es la representación gráfica del algoritmo o proceso. Se utiliza en disciplinas como programación, economía, procesos industriales y psicología cognitiva.
En Lenguaje Unificado de Modelado (UML), un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un diagrama de actividades muestra el flujo de control general.
En SysML el diagrama de actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.
Estos diagramas utilizan símbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y de fin de proceso.
8.26 CARACTERÍSTICAS:
Un diagrama de flujo siempre tiene un único punto de inicio y un único punto de término.
Las siguientes son acciones previas a la realización del diagrama de flujo:
Identificar las ideas principales a ser incluidas en el diagrama de flujo. Deben estar presentes el autor o responsable del proceso, los autores o responsables del proceso anterior y posterior y de otros procesos interrelacionados, así como las terceras partes interesadas.
Definir qué se espera obtener del diagrama de flujo. Identificar quién lo empleará y cómo. Establecer el nivel de detalle requerido. Determinar los límites del proceso a describir. Los pasos a seguir para construir el diagrama de flujo son:
34
Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente.
Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y su orden cronológico.
Si el nivel de detalle definido incluye actividades menores, listarlas también.
Identificar y listar los puntos de decisión. Construir el diagrama respetando la secuencia cronológica y
asignando los correspondientes símbolos. Asignar un título al diagrama y verificar que esté completo y
describa con exactitud el proceso elegido.
8.27 DIAGRAMA CAUSA – EFECTO
35
El Diagrama de Ishikawa, también llamado diagrama de causa-efecto o diagrama causal, se trata de un diagrama que por su estructura ha venido a llamarse también: Diagrama de espina de pez, que consiste en una representación gráfica sencilla en la que puede verse de manera relacional una especie de espina central, que es una línea en el plano horizontal, representando el problema a analizar, que se escribe a su derecha. Es una de las diversas herramientas surgidas a lo largo del siglo XX en ámbitos de la industria y posteriormente en el de los servicios, para facilitar el análisis de problemas y sus soluciones en esferas como lo son; calidad de los procesos, los productos y servicios. Fue concebido por el licenciado en química japonés Dr. Kaoru Ishikawa en el año 1943.
Este diagrama causal es la representación gráfica de las relaciones múltiples de causa – efecto entre las diversas variables que intervienen en un proceso. En teoría general de sistemas, un diagrama causal es un tipo de diagrama que muestra gráficamente las entradas o inputs, el proceso, y las salidas u outputs de un sistema (causa-efecto), con su respectiva retroalimentación (feedback) para el subsistema de control.
El problema analizado puede provenir de diversos ámbitos como la calidad de productos y servicios, fenómenos sociales, organización, etc. A este eje horizontal van llegando líneas oblicuas -como las espinas de un pez- que representan las causas valoradas como tales por las personas participantes en el análisis del problema. A su vez, cada una de estas líneas que representa una posible causa, recibe otras líneas perpendiculares que representan las causas secundarias. Cada grupo formado por una posible causa primaria y las causas secundarias que se le relacionan forman un grupo de causas con naturaleza común. Este tipo de herramienta permite un análisis participativo mediante grupos de mejora o grupos de análisis, que mediante técnicas como, por ejemplo, la lluvia de ideas, sesiones de creatividad, y otras, facilita un resultado óptimo en el entendimiento de las causas que originan un problema, con lo que puede ser posible la solución del mismo.
36
Ilustración 3: Diagrama de Ishikawa (Causa – Efecto)
37
9 MAPA DE PROCESOS DE LA GESTION DE INCIDENCIAS DE SERVICE
DESK DE LA FIA
Ilustración 4: Mapa General del Proceso de Incidencias.
38
10.CADENA DE VALOR DE LA FIA
Ilustración 5: Cadena de Valor según ITIL v3.
39
11.ORGANIGRAMA DE LA FIA
40
12.GESTION DE INCIDENCIAS
1.1. OBJETIVOS:
Restaurar la operación normal del servicio afectado lo más rápido posible, minimizando el impacto en el negocio y asegurando que se mantengan los niveles acordados de calidad y disponibilidad.
Se entiende por operación normal del servicio a lo que se haya definido dentro de los límites del SLA.
1.2. ALCANCE:
Abarca cualquier evento que impacte, o pueda impactar, a un servicio.
Existen eventos de tipo informativo, para lo cual existe un tratamiento especial en el proceso de Gestión de Eventos.
Las Peticiones de Servicio (ServiceRequest) serán derivados al proceso específico correspondiente.
41
Ilustración 6: Procesos y Funciones según ITIL v3.
Ilustración 7: Gestión de Incidencias según ITIL v3.
42
1.3. Participantes y Capacitación Requerida
Participante Capacitación RequeridaUsuario Proceso de Gestión de Incidentes, Problemas.
Gestor de IncidentesProceso de Gestión de Incidentes, Problemas y Cambios.
Soporte de 1er nivel de Incidentes
Proceso de Gestión de Incidentes, Problemas.
Soporte de N-nivel de Incidentes
Proceso de Gestión de Incidentes, Problemas y Cambios.
Tabla 1: Participantes del Proceso de Gestión de Incidentes.
1.4. Controles de Entrada
Para dar inicio al Proceso de Gestión de Incidentes se requiere que se haya detectado una ocurrencia.
1.5. Diagrama de Contexto de Proceso de Gestión de Incidencias
Ilustración 8: Diagrama de Contexto del Proceso de Gestión de Incidentes.
43
1.6. Diagrama del Proceso de Gestión de Incidencias
Ilustración 9: Diagrama del Proceso de Gestión de Incidentes.
44
1.7. Tabla de Descripción del Proceso
ID Actividad
Actividad Entrada Descripción de la Actividad
Salida Rol – Participant
e1 Reportar
OcurrenciasOcurrencia detectada
Se reporta ocurrencia a través de intranet, Correo, Teléfono, Móvil, etc.
Ocurrencia reportada
E: Usuario
2 ¿Incidente? Ocurrencia reportada
SI: Continúa con subproceso GINCI00110.NO: Continúa con actividad 16.
E: Soporte de incidentes 1o
NivelC: Usuario
GINCI00110 Registro y Clasificación
Incidente reportado
Se registra, clasifica y determina grado de severidad del incidente.
Incidente registrado
E: Soporte de incidentes 1o
Nivel
3 ¿El incidente está asociado a un problema?
Incidente registrado
SI: Continúa con subproceso GINCI00120.NO: Continúa con actividad 4.
E: Soporte de incidentes 1o
/ No Nivel
4 ¿Incidente de alto impacto o prioridad 1?
Incidente registrado
SI: Continúa con actividad 5.NO: Continúa con actividad 6.
E: Soporte de incidentes 1o
/ No Nivel5 ¿Ya existe un
problema relacionado?
Incidente registrado
SI: Continúa con actividad 7.NO: Continúa con actividad 8.
E: Soporte de incidentes 1o
/ No Nivel6 ¿Existen
múltiples incidentes similares?
Incidente registrado
SI: Continúa con actividad 5.NO: Continúa con subproceso GINCI00120.
E: Soporte de incidentes 1o
/ No Nivel
7 Asociar incidente al problema
Incidente registradoProblema relacionado
Se asocia el incidente con un problema previamente reportado.
Incidente registrado (asociado a problema)
E: Soporte de incidentes 1o
/ No Nivel
8 ¿Soporte Nivel > 1?
Incidente registrado
SI: Continúa con subproceso GINCI00120 y con proceso GPROB00100.NO: Continúa con subproceso GINCI00120.
E: Soporte de incidentes 1o
/ No Nivel
45
ID Actividad
Actividad Entrada Descripción de la Actividad
Salida Rol – Participant
eGINCI00120 Investigación y
DiagnósticoIncidente registrado
Se busca en la BDC la solución, si no se encuentra se investiga y diagnostica. Se efectúan cambios para implementar la solución, de ser necesario.
Incidente diagnosticado
E: Soporte de incidentes 1o
/ No Nivel
9 ¿Se puede resolver en el nivel actual?
Incidente diagnosticado
SI: Continúa con subproceso GINCI00130.NO: Continúa con actividad 10.
E: Soporte de incidentes 1o
/ No Nivel
10 Reasignar o escalar a nivel correspondiente
Incidente que requiere transferencia
Se reasigna o escala un incidente que no tiene solución en este nivel.
Incidente reasignado
E: Soporte de incidentes 1o
/ No Nivel
PROCITIL130
Solución, Recuperación y Documentación
Incidente diagnosticadoSolución propuesta
Se da la solución encontrada se recupera el servicio, se registra y se documenta.
Incidente solucionado
E: Soporte de incidentes 1o
/ No Nivel
11 ¿Se encontró la causa raíz?
Incidente solucionado
SI: Continúa con actividad 12.NO: Continúa con actividad 13.
E: Soporte de incidentes 1o
/ No Nivel12 ¿Soporte Nivel
> 1?Incidente solucionado
SI: Continúa con proceso GPROB00100 y actividad 13.NO: Continúa con actividad 14.
E: Soporte de incidentes 1o
/ No Nivel
13 ¿Probabilidad de Recurrencia?
Incidente solucionado
SI: Continúa con proceso GPROB00100 y actividad 14.NO: Continúa con actividad 14.
E: Soporte de incidentes 1o
/ No Nivel
46
ID Actividad
Actividad Entrada Descripción de la Actividad
Salida Rol – Participant
e14 Validar solución
de incidenteIncidente solucionado
Llamar por teléfono o enviar mail solicitando al usuario la conformidad de la atención de la incidencia reportada.Si el usuario no responde al mensaje enviado vía mail dentro de las 24 horas se asumirá como solucionado el incidente y se actualizará el Sistema.
Conformidad de atención
E: Soporte de incidentes 1o
/ No Nivel
15 ¿Usuario lo considera resuelto?
Incidente solucionado
SI: Continúa con proceso GINCI00140NO: Retorna a subproceso GINCI00120.
E: Soporte de incidentes 1o
/ No Nivel
PROCITIL140
Validación y Cierre
Incidente solucionadoConformidad del usuario
Si el usuario da su conformidad a la solución del incidente, se procede a cerrar el ticket.
Incidente cerrado
E: Soporte de incidentes 1o
/ No Nivel
PROCITIL150
Seguimiento y Verificación del proceso
Incidentes Se generan informes ejecutivos para la Gerencia de Operaciones TI para su análisis incluyendo sus recomendaciones.
Informes Ejecutivos
E: Gestor de Incidentes
16 Gestionar Solicitud de Servicio
Solicitud de Servicio reportada
Se atiende la solicitud según el Procedimiento de Solicitud de Servicio descrito en los documentos “Manual del Agente de Centro de Servicios” y “Manual del Especialista de Soporte”.
Solicitud de Servicio cerrada
E: Soporte de incidentes 1o
/ No Nivel
PROCITIL200 Gestión de Problemas
Problema detectado
Se ejecuta el proceso de Gestión de Problemas.
Problema cerrado
R: Gestor de Problemas
Tabla 2: Actividades del Proceso de Gestión de Incidentes.
47
13.PROCESOS DE GESTIÓN DE INCIDENCIAS
1. PROCESO DE IDENTIFICACION REGISTRO
i. NOMBRE DEL PROCESO:
Identificación y Registro
ii. ACTIVIDADES DEL PROCESO:
1. El usuario selecciona la opción SOLICITAR ATENCION DE MESA DE AYUDA ubicado en la parte derecha del escritorio del monitor.
2. El sistema se inicializa y muestra el formulario de registro con los siguientes campos: N° de incidencias único (deshabilitado), Fecha de creación (deshabilitado con la fecha actual), Nombre del Usuario, Área, Titulo, Descripción además de las opciones: Enviar y Salir.
3. El usuario llena los campos: Nombre del Usuario, Área, Titulo y Descripción como consiguiente selecciona la opción Enviar.
4. El sistema muestra el mensaje de satisfacción enviada y notifica el número de incidencia único.
5. El sistema notifica al usuario de TI.
6. El usuario TI completa los siguientes campos: Tipo de Incidencia, Categoría, Impacto/Urgencia, Prioridad, SLA y Fecha Estimada.
7. El usuario TI selecciona la opción EN PROCESO DE ATENCION.
iii. OBJETIVOS:
Identificación de incidencias para su clasificación según tipo, urgencias, impacto y prioridad del problema.
Centralizar la resolución de incidentes.
48
iv. ALCANCE
Registro de las incidencias de los usuarios canalizando las solicitudes y lograr una identificación eficiente de la actividad.
v. E/S PROCESO
Entrada : Administración de Incidencias. Salida : Registro de Incidencias.
vi. CONTROLES:
La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.
vii. ROLES:
Usuario.
viii. MECANISMO DE CONTROL:
No corresponde.
ix. FORMATO DE HOJA
49
Solicitud de Atención
Proceso de Identificación
Proceso de Registro
Registro de datos básicos Proceso de Identificación
x. FLUJOGRAMA IDENTIFICACIÓN REGISTRO
xi. PLANTILLA O CARTILLA DE CONTROL DE IDENTIFICACIÓN Y REGISTRO
xii. DIAGRAMA DE BLOQUES DE IDENTIFICACIÓN Y REGISTRO
50
xiii. ALMACEN DE DATOS:
Incidencia: Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar una interrupción o una reducción de la calidad de ese servicio.
Gestión de Incidencias:(Operación del Servicio) Proceso responsable de la gestión del Ciclo de vida de todos los Incidentes. El objetivo primario de la Gestión de Incidencias es recuperar el Servicio de TI para los Usuarios lo antes posible.
xiv. RACI:
ITIL PROCESOS
USUARIO TI
SERVICE DESKTECNICO NIVEL
2
PROVEEDOR
GERENTETECNIC
O
GESTOR DE
INCIDENTES
COORDINADOR SERVICE
DESK
NOTIFICACION Y ALERTA
DE INCIDENTES
R/I I I A I
REGISTRO DE INCIDENTES
I R R A I
2. PROCESO DE CLASIFICACION Y SOPORTE
i. NOMBRE DEL PROCESO
Clasificación y Soporte Inicial
ii. ACTIVIDADES DEL PROCESO
1. Conocer el nivel de impacto de la incidencia.2. Clasificar la incidencia según prioridad.3. Identificar los límites para resolver el problema.4. Criterio Típico**5. Iniciar el soporte inicial.
** El criterio típico debería incluir:
Coste potencial de la no-resolución
51
Centro de Servicios
Clasificación y Soporte Inicial Medir el impacto del servicio realizadoOperaciones Informáticas
Networking
Amenaza de lesión a clientes o empleados
Implicaciones legales
Trastorno a clientes y empleados
iii. OBJETIVOS
Asegurar el diagnóstico exacto controlando las prioridades de atención de acuerdo a la urgencia de la incidencia y también según los niveles de atención.
iv. ALCANCE
El nivel de este proceso corresponde a la Clasificación y Priorización de las incidencias registradas determinando el adecuado servicio asistido.
v. E/S PROCESO
vi. CONTROLES
Configuración de la Administración de la Base de datos de la gestión del conocimiento (CMDB).
52
vii. ROLES
Usuario TI.
viii. MECANISMO DE CONTROL
Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida.
53
ix. FORMATO DE HOJA WEB
x. FLUJOGRAMA
54
xi. PLANTILLA O CARTILLA DE CONTROL
xii. DIAGRAMA DE BLOQUES
xiii. ALMACÉN DE DATOS
Escalamiento : Nivel de resolución de incidencias.
Existen 2 tipos:
1. Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema.
2. Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.
55
KEDB : Errores conocidos en los registros de la Base de datos del conocimiento.
xiv. RACI
ITIL PROCESOS
USUARIO TI
SERVICE DESKTECNICO NIVEL 2
PROVEEDOR
GERENTETECNIC
O
GESTOR DE INCIDENTES
COORDINADOR SERVICE DESK
COMPARACION
R/I I I A I I
3. PROCESO DE COMPARACION
i. NOMBRE DEL PROCESO
Comparación.
ii. ACTIVIDADES DEL PROCESO
1. Evaluar si la solución llego abarcar en todo su funcionamiento.
2. Escalar a otro nivel si la solución no llega a abarcar lo esperado.
3. Identificar el nivel de solución adecuado.4. Comunicar al usuario la duración que abarcaría esta 5. El usuario debe de estar informado sobre el cuadro
que puede presentar la incidencia
iii. OBJETIVOS
Canalizar las incidencias sin solución a los niveles de servicio.
56
Centro de Servicios
Comparación EscalamientoOperaciones Informáticas
Networking
iv. ALCANCE
Según la complejidad que presente la incidencia deberá ser escalado de acuerdo a los niveles de servicio para su resolución.
v. E/S PROCESO
vi. CONTROLES
Configuración de la Administración de la Base de datos de la gestión del conocimiento (CMDB).
vii. ROLES
Usuario TI.
57
viii. MECANISMO DE CONTROL
ix. FORMATO DE HOJA
No corresponde.
x. FLUJOGRAMA
58
xi. PLANTILLA O CARTILLA DE CONTROL
No corresponde.
xii. DIAGRAMA DE BLOQUES
COMPARACIONINCIDENCIA SIN SOLUCION
xiii. ALMACÉN DE DATOS
Escalamiento: Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado.
KEDB : Base de datos de errores conocidos.
xiv. RACI
ITIL PROCESOS
USUARIO TI
SERVICE DESKTECNICO NIVEL
2
PROVEEDOR
GERENTETECNIC
O
GESTOR DE
INCIDENTES
COORDINADOR SERVICE
DESK
CLASIFICACION DE
INCIDENTESR/I I I A I
MEDICION DEL IMPACTO Y URGENCIA
I R R A I
DIAGNOSTICO INCIAL
I R R A I
59
4. PROCESO DE INVESTIGACION Y DIAGNOSTICO INICIAL
i. NOMBRE DEL PROCESO
Proceso de Investigación y Diagnóstico Inicial
ii. ACTIVIDADES DEL PROCESO
1. El técnico selecciona la opción “Detalle” del Formulario de Diagnóstico Inicial.
2. El formulario contiene los siguientes campos:
Origen / Fecha Creación (M/D/AAAA HH:MM:SS), Registrado Por, Notificado Por, Localización, Descripción, Estado, Comentarios de la Investigación, Lista de Soluciones.
Además de los botones Buscar Fecha, Guardar y Salir.
3. El técnico selecciona el Origen.
4. El sistema muestra el Origen.
5. El técnico selecciona el botón “Buscar Fecha”.
6. El sistema muestra la fecha.
7. El técnico selecciona al Registrador.
8. El sistema muestra al Registrador.
9. El técnico selecciona al Notificador.
10. El sistema muestra al Notificador.
11. El técnico selecciona su Localización.
12. El sistema muestra el Localización.
13. El técnico ingresa su Estado.
14. El sistema muestra el Estado.
15. El técnico ingresa comentarios sobre la Investigación.
60
16. El sistema muestra los comentarios respectivos.
17. El técnico selecciona la lista de soluciones según la base de datos del conocimiento.
18. El sistema muestra la solución elegida.
19. El técnico selecciona la opción “Guardar”.
20. El sistema muestra un mensaje “Grabación Satisfactoria”.
21. El técnico selección la opción “Salir”.
22. El proceso finaliza.
iii. OBJETIVOS
Evaluar con más detalle la información de los errores conocidos.
Resolver el incidente en un primer nivel de atención.
Entender el orden cronológico de eventos que causaron el incidente.
iv. ALCANCE
Investigación y Diagnostico de todas las incidencias ocurridas.
v. E/S PROCESO
E = Incidente Registrado.
S = Resultado de las búsqueda de soluciones en la BDC.
S= Resultado de las búsqueda de soluciones en la BDC.
E = Incidente Diagnosticado.
E = Incidente Diagnosticado.
61
vi. FLUJOGRAMA
62
Investigación de la Incidencia
Diagnóstico Inicial de la Incidencia
vii. DIAGRAMA DE BLOQUES
5. PROCESO DE RESOLUCION Y RECUPERACION
i. NOMBRE DEL PROCESO
Proceso de Resolución y Recuperación
ii. OBJETIVOS
Todas las actividades deberán documentarse completamente en el registro de incidencias
iii. ALCANCE
A través de un análisis exhaustivo dar una solución rápida y eficaz, y a su vez poder recuperar y documentar todo lo relacionado a las incidencias.
iv. ACTIVIDAD DEL PROCESO, ENTRADA, SALIDA
ID Actividad
Actividad Entrada Descripción de la Actividad
Salida Rol – Participante
1 Solucionar y Recuperar
Incidente diagnosticadoSolución propuesta
Resolver el incidente ejecutando las soluciones temporales o definitivas recuperando el servicio y minimizando el impacto en el negocio.
Servicio recuperado
E: Soporte de incidentes 1o / No Nivel
2 Actualizar el estado del incidente
Servicio recuperado
Actualizar el estado del incidente en el
Incidente solucionado
E: Soporte de incidentes 1o / No Nivel
63
ID Actividad
Actividad Entrada Descripción de la Actividad
Salida Rol – Participante
registro de Incidentes.
3 Registrar la solución del incidente
Incidente solucionado
Se debe registrar en la herramienta como se llevó a cabo la solución de dicho incidente.
Incidente solucionado (solución registrada)
E: Soporte de incidentes 1o / No Nivel
4 ¿Solución en base a documentos de la BDC?
Incidente solucionado
Si: Continúa con actividad 6No: Continúa con actividad 5
E: Soporte de incidentes 1o / No Nivel
5 ¿La solución requiere documentación?
Incidente solucionado
Si: Continúa con actividad 7No: Fin del proceso
E: Soporte de incidentes 1o / No Nivel
6 Adjuntar documento al incidente y calificarlo
Incidente solucionadoDocumento en la BDC
Se adjunta el documento al incidente y se le califica.
Incidente solucionado (documentación en BDC adjunta)
E: Soporte de incidentes 1o / No Nivel
7 Documentar la solución en la BDC
Incidente solucionado
Se documentan las soluciones de los incidentes en la BDC no solo como un sustento de la solución, si no como un repositorio de conocimiento. Para ello se sigue el Procedimiento de Gestión de Conocimiento descrito en los documentos “Manual del Agente de Centro de Servicios” y “Manual del Especialista de Soporte”.
Documento de solución creado en la BDC
E: Soporte de incidentes 1o / No Nivel
v. CONTROLES
Que se haya diagnosticado el incidente y que se haya propuesto una solución para resolverlo.
Se ha solucionado el Incidente, recuperado el servicio y registrado la solución
64
vi. ROLES
Soporte de Incidentes de 1o / No Nivel.
vii. FORMATO DE HOJA
Se realizan vía correo electrónico.
65
Resolución de la Incidencia
Recuperación de la Incidencia
viii. FLUJOGRAMA
ix. DIAGRAMA DE BLOQUES
66
6. PROCESO DE CIERRE
i. NOMBRE DEL PROCESO
ii. OBJETIVOS
El Centro de Servicios debe comprobar que la incidencia se resuelva completamente y que los usuarios estén dispuestos a acordar el cierre.
iii. ALCANCE
Cierre Formal al finalizar la Incidencia.
iv. ACTIVIDADES DEL PROCESO, ENTRADA Y SALIDA
ID ACTIVIDAD
ACTIVIDAD ENTRADA DESCRIPCIÓN DE LA
ACTIVIDAD
SALIDA ROL – PARTICIPANT
E1 Revisar validez
de datos finales y categorización
Incidente solucionadoConformidad del usuario
Se verifican los datos y la categorización para poder dar por concluido el caso.
Incidente solucionado
E: Soporte de incidentes 1o / No Nivel
2 Cerrar incidente
Incidente solucionado
Se cierra el incidente.
Incidente cerrado
E: Soporte de N Nivel
v. CONTROLES
Que el incidente haya sido solucionado y se tenga la conformidad del usuario.
Se ha cerrado el Incidente.
vi. ROLES
E: Soporte de incidentes 1o / No Nivel
67
vii. FORMATO DE HOJA
Se realiza un documento de conformidad.
ACTA DE CONFORMIDAD
Lima, xx de Enero del 2014
Mediante la presente se da la conformidad por el trabajo realizado de la incidencia……………….. de la Oficina/Gerencia………..…..de la FIA, comprobando el buen funcionamiento y realizando la pruebas debida del personal del área en mención y de la misma manera entregando el informe final.
Sin otro en particular.
Solicitante TécnicoNombres y Apellidos: Nombres y Apellidos:Cod. Planilla.: Cod. Planilla.:
68
Cierre de Incidencias
viii. FLUJOGRAMA
ix. DIAGRAMA DE BLOQUES
69
14.MÉTRICAS
i. NÚMERO TOTAL DE INCIDENCIAS
Hemos estudiado alrededor de 30 Incidencias, en la Mesa de Ayuda de la FIA con el uso del estándar ITIL Versión 3.
Las cuales son:
La impresora se quedó sin tinta.
Atasco de papel en la impresora.
La computadora de gerencia no enciende.
La red dejó de funcionar intempestivamente.
La tarjeta de red de las computadoras del Área de Administración dejaron de funcionar.
Falta de papel para la impresora.
Detección de virus en las computadoras.
El sistema operativo del servidor colapsó.
Incompatibilidad del software con el sistema operativo.
El proyector del Área de Sistemas se encuentra con una resolución demasiado baja.
Y otras incidencias comunes…
ii. NÚMERO DE INCIDENCIAS ACUMULADAS
La hemos dividido por áreas de la empresa.
iii. TIEMPO MEDIO DE RESOLUCION DE INCIDENTES
Primero se prioriza las incidencias de acuerdo a su gravedad, grado de importancia y de esta manera se puede estimar el tiempo de resolución de la incidencia a gestionar.
70
15.APÉNDICE
A. GLOSARIO DE TÉRMINOS
Acuerdo de nivel de servicio (SLA)
Un acuerdo escrito entre el proveedor de servicios y el cliente(s), este documento acuerda los niveles de servicio.
CMDB Base de datos que contiene todos los detalles relevantes de los CI’s y detalles importantes de las relaciones entre CI’s.
Centro de Servicios
Punto de contacto inicial con la organización TI para los usuarios. Aquí registran, resuelven y controlan los problemas.
Error conocido Es un problema con causa determinada.
Escalado Hacia niveles que autoricen recursos adicionales para la solución.
Impacto Grado de desviación sobre la operativa actual (número de usuarios o de procesos afectados).
Ocurrencia Incidente o Solicitud de Servicio.
Incidente Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar una interrupción o una reducción de la calidad de ese servicio.
Solicitud de Servicio
Un requerimiento de usuario por información, asesoría o acceso a un servicio de TI. Por ejemplo: reconfigurar una contraseña o proveer servicios de TI estándares para un nuevo usuario.
Prioridad Es el resultado de analizar la urgencia por el impacto. Es el esfuerzo esperado para resolver un incidente
Problema Descripción de una situación no deseada, indicando la causa raíz desconocida de uno o más incidentes existentes o potenciales
Soporte de 1o nivel
Personal de Centro de Servicios quien recibe el incidente
Soporte de Nonivel
Personal de mayor experiencia que se encarga de
71
solucionar incidentes que no pudieron ser resueltos por el 1er nivel, puede ser proveedor, fabricante o experto. No puede ser 2o o 3o nivel.
Urgencia Demora aceptable para el proceso del negocio
WorkAround Información previa de una ocurrencia ya previamente registrada
B. ACRÓNIMOS
RFC Requerimiento para cambio.
CI Ítem de configuración
CMDB Base de Datos de Administración de la Configuración
KE Errores conocidos
SLA Acuerdo de Nivel de Servicio.
CASD CA ServiceDesk
CDS Centro de Servicios
BDC Base de Datos del Conocimiento
72
16.CONCLUSIONES
Describir los procesos de administración de servicios y como se pueden mapear el ciclo de vida del servicio.
Una detallada descripción y reconocimiento de beneficios de implementar ITIL Versión 3 en una organización.
El hecho de adoptar mejores prácticas implica que no tengamos que descubrir el hilo negro y que si alguien sabe cómo hacer las cosas y explotar los recursos nos podemos apoyar en él para que nosotros también podamos hacerlo. El mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca en una buena prestación de servicios.
ITIL Versión 3 es una metodología que nos va a ayudar a que las cosas se puedan hacer de una forma más eficiente, ya que lo que se propone es que se adopten ciertas métricas y procedimientos que otros proveedores de IT adoptaron y que gracias a ellas son catalogadas como mejores prácticas.
73
17.RECOMENDACIONES
Se recomienda que el tema ITIL sea incidente de estudio en la carrera de Sistemas e Informática.
Los modelos de gestión de incidentes deben ser establecidos por los ingenieros de soporte, quienes, al fin son ellos lo que harán que funcione el ServiceDesk de la FIA.
Se debe capacitar al personal, haciendo reflexionar que con lo que cuentan al momento pueden cumplir con las expectativas del usuario, solo se necesita seguir un trabajo ordenado realizando un registro, seguimiento y cierre de los incidentes en un tiempo límite, seguir los scripts, alimentar a la Base de Conocimientos para que vaya incrementado de información.
Seguir un control de los procesos por parte de los coordinadores, informar a cada una de las Áreas los objetivos que se plantearon y deben cumplir para lograr la satisfacción del usuario.
Aprovechar los sistemas con los que cuentan, llenando y actualizando de manera correcta con información real. Mantener la Base del Conocimiento Actualizada.
74
18.BIBLIOGRAFÍA
IT Governance, Management (2008). Practical I.T. Service Management: a Concise Guide for Busy Executives. Thejendra BS.
New Horizons, Marlon Molina Rodríguez, (junio de 2006), Fundamentos de ITIL. Madrid.
BCS, Management (2010). The ITIL V3 Manager's Bridge Certificate in IT Service Man-agement: A Guide for Exam Candidates. ColinRudd.
Ernesto Vilches. Guía de Gestión de Servicios basada en Fundamentos de ITIL v3.
SAS web, IPSR LecturaPrevia Service Support Service Desk, Incident and Problem Management. Disponible en: http://www.sas.com/.
BetzabéFalfánJimenes, (enero de 2007). Disponible en: http://enterate.unam.mx/Articulos/enero/desk.htm/.
ServiceDesk, Presentación 1, (Agosto 2008). Disponible en: http://www.slideshare.net/Fernanda_chaves/Service_Desk-presentacion1-presentation/.
ServiceTonic, (2009). Disponible en: http://servicetonic.wordpress.com/category/gestion-de-servicios/itil-v3/.
OceanMist, Adrián Pérez, (Diciembre 2010). Disponible en: http://helloit.webege.com/2010/12/itil-fase-4-operacion/.
75
itilenespañol.com. (2011). ITIL EN ESPAÑOL.OGC. Disponible en: http://itilenespanol.com/index.php?option=com_content&task=view&id=25&Itemid=8.1/.
Osiatis. ITIL V3.Madrid. Disponible en: http://itilv3.osiastis.com/.
Wikimedia Foundation, Inc. (2011). Service Desk. Creative Commons Attribution-ShareAlike License. Disponible en: http://en.wikipedia.org/wiki/Service_Desk_%28ITSM%29/.
Wikidot. (2008). Proceso de la Gestión de Incidencias. Disponible en: http://itil.wikidot.com/unidad3:im-proceso/.
Addlink Software Científico. (2011). ServiceDesk (HelpDesk – Gestor de Incidentes). 08001 Barcelona. Disponible en: http://www.addlink.es/productos.asp?pid=542/.
76