Recomendaciones para la Gesti

on de Incidencias
de Tecnologas de la Informaci
on
Verny Mora Jimenez, Paulo Viales Wahrmann, Julio Cordoba Retana y
Antonio Gonzalez Torres
Escuela de Ingeniera,
Universidad Latinoamericana de Ciencia y Tecnologa,
ULACIT, Urbanizaci
on Tourn
on, 10235-1000
San Jose, Costa Rica
[vmor80@hotmail.com,pviales@gmail.com,jcordobar022,
agonzalezt899]@ulacit.ed.cr
http://www.ulacit.ac.cr

Abstract. La gesti
on de incidencias es un proceso crtico en la administraci
on de los servicios de Tecnologas de la Informaci
on (TI), por el
impacto en las operaciones de las organizaciones y la relaci
on que se establece entre los usuarios y el departamento de TI. De acuerdo con esto,
este trabajo de investigaci
on lleva a cabo el an
alisis de las principales actividades asociadas, conforme con los marcos de referencia ITIL, COBIT
y CMMI, y propone un proceso para la gesti
on de incidencias. El objetivo
es apoyar a los administradores de TI en la definici
on e implementaci
on
de la gesti
on de incidencias mediante la discusi
on de la propuesta y el
flujo de las tareas que componen el proceso.
Keywords: Gesti
on de Incidencias, ITIL, COBIT, CMMI

Introducci
on

En el contexto actual, las tecnologas de la informacion (TI) son un factor crtico

para el desempe
no de las organizaciones, por lo que requieren el correcto funcionamiento de los sistemas de hardware y software que utilizan. Esto conlleva
que las incidencias1 que se presenten deben ser resueltas de forma oportuna,
tanto a usuarios internos como externos. Por lo que es necesario que las incidencias se gestionen de forma adecuada, para evitar que se transformen en riesgos
para la continuidad de la organizacion
En este punto resulta indispensable tener en cuenta que los servicios de TI
deben ofrecer servicios de calidad con alta disponibilidad, utilizar los recursos de
forma m
as eficiente, ayudar a incrementar la productividad de los usuarios, reducir costos, tiempos de ejecucion de procesos y riesgos, y alinearse a los procesos
del negocio. Sin embargo, los altos niveles de calidad de los servicios no se pueden
1

Se denomina como incidencia a un problema que sobreviene en la prestaci

on de un
servicio que es soportado por hardware o software.

Mora et al.

alcanzar u
nicamente con fuertes inversiones en tecnologa y personal cualificado,
sino que es necesario contar con una buena gestion y planificacion a nivel empresarial. Para esto, es recomendable implementar un Sistema de Gestion de
Servicios de TI (SGSTI), potenciar la labor de los gestores y utilizar metricas
para el seguimiento y control de la resolucion de incidencias (Bauset-Carbonell
& Rodenes-Adam, 2013; Mutafelija & Stromberg, 2008).
Tambien es conveniente tener en cuenta que la gestion de incidencias, ademas
del impacto que tiene en la organizacion, determina la relacion de los departamentos de TI con los usuarios, y en cierta forma se convierte en un reflejo de
la calidad de los servicios que estos ofrecen. Cabe resaltar que la calidad de los
servicios implica tanto el nivel de efectividad de la resolucion de los problemas
como la forma en que el servicio es percibido por los usuarios y el resto de la
organizaci
on (Persse, 2013).
De acuerdo con la experiencia de los autores, un gran n
umero de organizaciones no aplican las mejores practicas de la industria para la gestion de incidencias, en algunos casos por desconocimiento y en otros por que no le brindan
importancia necesaria. Tomando en cuenta lo anterior, en este trabajo se estudian y analizan los lineamientos y mejores practicas que son recomendadas
por COBIT, ITIL y CMMI con el fin de proponer un proceso y una lista de
recomendaciones que sirvan como gua para realizar la gestion de incidencias en
servicios de TI. Dicho proceso pretende contribuir con la deteccion oportuna de
desviaciones en los procedimientos, la correcta clasificacion de las incidencias, la
utilizaci
on de procedimientos de escalado y el cierre adecuado de las incidencias.
El fin de este planteamiento es contribuir con la mejora de los porcentajes de
efectividad en la resoluci
on de incidencias de las organizaciones, en un plazo no
mayor a un a
no de la puesta en marcha del proceso.

Marco Te
orico

Una incidencia es un evento que implica la interrupcion no planificada o la

reducci
on de la calidad de un servicio de TI, el cual es soportado por elementos
de hardware o software (ITILv3, 2011). Las incidencias pueden ser detectadas
por el personal tecnico, reportadas por herramientas de seguimiento de eventos,
comunicadas por los usuarios de forma telefonica o mediante un sistema de
incidencias o informadas por terceros (e.g., proveedores y socios de negocio2 ).
En tanto, la gesti
on de las incidencias es el proceso responsable de administrar
el ciclo de vida de cada incidencia (Persse, 2013).
La gesti
on de incidencias requiere brindar respuesta oportuna y efectiva a las
peticiones de los usuarios relacionadas con la resolucion de problemas asociados
a los servicios de TI, esto con el fin de no afectar los procesos de la organizacion
y cumplir con los compromisos con terceros (Forrester, Buteau, & Shrum, 2011).
En terminos generales, este proceso contempla registrar las peticiones de servicio, diagnosticar el problema de forma precisa (i.e., identificar y describir los
2

Conocidos como partners por su acepci

on en ingles.

Recomendaciones para la gesti

on de incidencias de TI

sntomas de las incidencias, as como asignar los recursos necesarios para su resoluci
on), determinar la prioridad de la incidencia, resolver las incidencias (i.e.,
determinar las posibles causas, efectuar escalaciones y recuperar el servicio, en
caso necesario), documentar y registrar de forma exhaustiva la resolucion de la
incidencia, cerrar las incidencias y mantener un registro historico (ver procesos
DSS02 y DSS03 de COBIT 5) (?, ?; OToole, 2015).
El registro de las peticiones de servicio requiere verificar que estas cumplen
con los criterios mnimos establecidos y que los usuarios que las realizan estan
debidamente autorizados. Cada incidencia debe contar con un n
umero u
nico de
referencia, hora y fecha de registro, identificacion de la persona que realizo el
registro de la incidencia, metodo de notificaciones del estado de la incidencia,
descripci
on de los sntomas.
En cuanto al diagn
ostico, es necesario contar con toda la informacion disponible
para efectuar una mejor evaluacion del problema para efectuar su categorizacion,
determinar el impacto en el negocio (i.e., nivel de perdida financiera, el posible
efecto en la reputaci
on del negocio y las regulaciones del pas) y la urgencia
de su resoluci
on, efectuar una correcta asignacion de la prioridad, obtener la
aprobaci
on financiera y si se requiere, el cambio de procedimientos o estandares.
Como parte este proceso se requiere require utilizar la base de datos de
conocimiento, si existe, para determinar si el problema esta asociado a un error
conocido, o si este ha sido resuelto anteriormente. Este paso se debe realizar
antes de asignar a un especialista para realizar un analisis de mayor profundidad
o que se realicen acciones para restaurar los servicios afectados, con ayuda de
otros especialistas.
En los casos en los que la incidencia es reportada por telefono, se recomienda
efectuar un diagn
ostico inicial e intentar ofrecer una solucion de forma inmediata,
trabajando junto con el usuario, si es factible. Si no es posible ofrecer una solucion
inmediata, entonces se debe informar al interesado sobre el procedimiento que
se seguir
a, y darle un n
umero de incidencia para que le pueda dar seguimiento.
En lo que respecta a la resolucion de incidencias, conviene tener en cuanta la
posibilidad de seguir el procedimiento para efectuar el escalado de la incidencia.
Este tipo de procedimiento usualmente contempla el escalado funcional (se solicita el apoyo de un especialista de mas alto nivel para resolver el problema) o
jer
arquico (se acude a un responsable de mayor autoridad para tomar decisiones
por encima del nivel del personal tecnico involucrado, como la asignacion de
recursos adicionales para la resolucion del incidencia).
En todo caso, es recomendable resolver cada incidencia en el menor tiempo
posible, para restaurar o normalizar el servicio y salvaguardar los intereses de la
organizaci
on. Pero adem
as, es necesario que en el transcurso de la resolucion se
le brinde seguimiento al estado de las incidencias hasta que se realice el cierre
de esta. El proceso de seguimiento involucra documentar y revisar las acciones
realizadas, escalar las incidencias seg
un se requiera y comunicar el estado de la
incidencia a las partes interesadas.
En el transcurso de la resolucion de una incidencia puede ser necesario efectuar procedimientos de recuperacion de los servicios, los cuales dependeran de la

Mora et al.

naturaleza de esta, y podran involucrar la participacion activa del usuario en la

realizaci
on de actividades concretas, de forma similar se podra requerir la participaci
on de otros especialistas e incluso de consultores o proveedores externos.
Una vez que la incidencia ha sido resuelta, se deben hacer las comprobaciones
necesarias con el usuario para cerrar el caso, medir la satisfaccion, tener en
cuenta los requerimientos de informes de las partes interesadas en la gestion de
incidencias y utilizar criterios de calidad del servicio (Forrester et al., 2011).
El cierre de la incidencia debe contemplar la documentacion de las actividades que se realizaron para resolverla, la fecha de resolucion, la categora de
cierre, la fecha en que se esta efectuando el cierre y la resolucion de las causas
subyacentes a la incidencia (Kenett & Baker, 2010). Ademas, se requiere documentar las soluciones identificadas, registrar si se usaron soluciones temporales
o acciones de recuperaci
on de servicios, determinar las acciones incorrectas que
se llevaron a cabo y comprender el proceso que se siguio durante la resolucion.
Esta informaci
on permite efectuar el analisis, evaluacion y clasificacion de incidencias para establecer tendencias, encontrar patrones de asuntos recurrentes e
infracciones a los procedimientos, reducir la ocurrencia de incidencias similares
en el futuro, mejorar su resolucion y apoyar la b
usqueda de mejores practicas.

Proceso para la Gesti

on de Incidencias

La definici
on de un proceso para la gestion de incidencias requiere que, en primer
lugar, se determinen de forma clara las polticas, procedimientos y definiciones
que ser
an considerados por este. Conforme con lo anterior, se recomienda tomar
en cuenta los elementos que se presentan en la siguiente lista.
Definici
on de una incidencia: Es necesario diferenciar de forma clara entre
una incidencia y una solicitud de servicio. Una incidencia es la interrupcion
no planificada o la reduccion de la calidad de un servicio de TI. Si bien
las solicitudes de servicio deben ser reportadas de forma similar que las
incidencias a la mesa de servicio, la diferencia es que estas no representan la
interrupci
on de un servicio (ITILv3, 2011).
Categoras: La definici
on de categoras es otro elemento fundamental en la
gesti
on de incidencias, para ubicar y asignar los recursos humanos y materiales de forma correcta cuando una incidencia es reportada. Sobre este particular, tanto ITIL como CMMI ofrecen recomendaciones para realizar un
cat
alogo de categoras de incidencias (ITILv3, 2011; Forrester et al., 2011).
Como recomendaci
on, se sugiere realizar una lluvia de ideas con el personal
involucrado en la gesti
on de incidencias (e.g., los tecnicos de soporte, supervisores de gesti
on de incidencias y administradores), para crear una lista
preliminar de categoras, que se ponga a prueba por un periodo corto de
tiempo. De forma posterior, se recomienda analizar las incidencias reportadas durante un periodo de tiempo para afinar la lista de categoras de
incidencias. Como buena practica, el catalogo de categoras debe ser analizado de forma peri
odica, cada 3 o 5 meses, para realizar actualizaciones y
mantenerlo adecuado a las necesidades del negocio.

Recomendaciones para la gesti

on de incidencias de TI

Responsable de incidencias: La asignacion de responsabilidades es otro elemento a tener en cuenta. En este aspecto, tanto COBIT (IT Governance Institute, 2013) como CMMI (Forrester et al., 2011) especifican varios lineamientos importantes. En general, es necesario especificar cuales son las
responsabilidades del tecnico al que se le asigna una incidencia, as como
quien es el responsable de supervisar, dar seguimiento al estado de las incidencias, efectuar los procesos de escalado y realizar la transferencia de
responsabilidades entre pasos o procesos.
Asignaci
on de prioridad: La resolucion de las incidencias requiere contar con
diferentes niveles de prioridad, en funcion de la relevancia e impacto en el
negocio. De acuerdo con el analisis de COBIT 5, ITIL y CMMI se recomienda
el uso de 5 niveles de prioridad usando valores numericos (e.g., 1 a 5) o
categ
oricos (baja, media, alta, grave, crtica).
Reporte de incidencias: Es importante definir de forma clara los mecanismos para el reporte de las incidencias y seguimiento de las incidencias, sin
importar si se realiza de forma manual o automatizada. En todo caso, las
personas que reportan las incidencias deben encontrarse autorizadas, exceptuando los casos en que se demuestre que peligra la vida de las personas o
que la continuidad del negocio esta siendo afectada.
En general, se recomienda contar con un sistema que facilite el reporte de incidencias a los usuarios (Forrester et al., 2011), la actualizacion de los estados
(e.g., abierta, en progreso, resuelta y cerrada) (ITILv3, 2011) y seguimiento
de las acciones realizadas durante el ciclo de vida de las incidencias.
Reapertura de incidencias: En algunos casos es posible que una incidencia
no haya sido resuelta por completo y sea necesario reabrirla. Por lo que
se requiere definir las reglas para reabrir incidencias, asignarles una nueva
categora y prioridad, y determinar quien sera el responsable que trabajara
en la soluci
on.
En general, los modelos relacionados con la gestion de las tecnologas de la
informaci
on coinciden en cuanto a las principales tareas que requiere el proceso
de gesti
on de incidencias, siendo esas tareas las siguientes:
1.
2.
3.
4.

Registro de incidencias.
Resoluci
on de incidencias.
Cierre de incidencias.
Seguimiento y an
alisis de incidencias.

En consecuencia, este trabajo ha tomado en cuenta la lista de tareas enunciadas y las mejores pr
acticas de COBIT (IT Governance Institute, 2013), ITIL
(ITILv3, 2011) y CMMI (Forrester et al., 2011), para proponer el proceso que se
muestra en la Figura 1. Las tareas ordinarias de dicho proceso son representadas
por cajas rectangulares y las decisiones por rombos, en tanto que las lneas de
color rojo indican el flujo ordinario de las tareas y las lneas punteadas de color
negro muestran la secuencia alternativa, en donde el flujo puede seguir uno u
otro camino con base en las decisiones que se han tomado.

Mora et al.

El proceso propuesto comienza con la identificacion de las incidencias, por

parte de los usuarios de la organizacion o los miembros del departamento de
TI (i.e., por observaci
on en el campo o por medio del uso de sistemas para ese
prop
osito). Una vez que la incidencia ha sido identificada, se procede a registrarla, para luego efectuar el diagnostico (i.e., de forma opcional se puede usar
la base de conocimientos), categorizacion y asignacion de prioridad. Con base en
el diagn
ostico, se determina si la resolucion de la incidencia requiere de recursos
extraordinarios, y en caso necesario se solicita la aprobacion de esos recursos al
comite ejecutivo. A partir de ese punto, se inicia la recuperacion de servicios
(cuando se requiera) y la resolucion de la incidencia.
Cuando la incidencia ha sido resuelta, de acuerdo con el personal tecnico,
se realizan las pruebas tecnicas necesarias para validar la resolucion. En caso
de que la incidencia se haya resuelto de forma efectiva, se realiza la verificacion
y aceptaci
on de la soluci
on con el usuario. Sin embargo, cuando la incidencia
no ha sido resuelta, se verifica si el personal tecnico a cargo puede terminar de
solucionarla o si es necesario solicitar el escalado de la incidencia. En caso de que
sea necesario escalar la incidencia, se determina si el escalado que se requiere es
funcional o jer
arquico. Cuando el proceso de escalado ha terminado, se verifica
si la incidencia ha sido resuelta, y si es as, se procede a realizar la verificacion y
aceptaci
on con el usuario. En caso de que la incidencia no haya sido resuelta tras
el proceso de escalado, se determina si el equipo de la mesa de servicio puede
terminar de resolverla o si es necesario volver a seguir el proceso de escalado.
Una vez que la resoluci
on de la incidencia ha sido resuelta de forma definitiva,
tras efectuar la verificaci
on y aceptacion con el usuario, se procede a cerrarla y
documentarla.
La descripci
on de cada una de las tareas que conforman el proceso propuesto
se detalla en a continuaci
on.

Fig. 1. Proceso para la gesti

on de incidencias de tecnologas de la informaci
on.

Recomendaciones para la gesti

on de incidencias de TI
7

Mora et al.

Identificaci
on de incidencias: En un escenario ideal, se brinda seguimiento
constante a los recursos y servicios crticos de la organizacion para prevenir la
ocurrencia de incidencias o bien, un gran n
umero de incidencias es detectado
por el departamento de TI en el momento en que se presentan, incluso antes
de que los usuarios se den cuenta de los eventos. Sin embargo, como muestra
la Figura X, la identificacion de las incidencias, por lo general, es realizada
tanto por los usuarios de la organizacion como por el departamento de TI.
Registro de incidencias: El proceso para registrar las incidencias debe poner
a disposici
on de los usuarios autorizados tantos medios como sea posible, incluyendo llamadas telef
onicas, registro web y mensajera instantanea. Cabe
recalcar que tanto el reporte como el registro de incidencias debe ser efectuado por usuarios que se encuentren autorizados, conforme a lo establecido
por las polticas y reglamentos de la organizacion.
Algunos de los principales elementos de informacion para registrar una incidencia son los siguientes:
1. Nombre de quien registra y quien reporta la incidencia
2. Datos de contacto
3. Descripci
on detallada de la incidencia
4. Fecha y hora del reporte (tomada por el sistema)
5. N
umero de referencia (generado por el sistema)
6. Prioridad y categora inicial (ingresada por quien registra la incidencia)
7. Notas sobre el impacto en el negocio
Diagn
ostico, categorizaci
on y prioridad: El diagnostico, dependiendo de
la naturaleza de la incidencia, se puede realizar de forma paralela a su registro. En algunos casos es posible que durante este proceso, con asistencia
de una base de datos de conocimiento, el problema sea solucionado por el
usuario que est
a efectuando el reporte o por quien esta registrando la incidencia (e.g., tambien es posible que la incidencia sea resuelta al momento de
hacer el diagn
ostico, en el momento en que se recibe el reporte por telefono).
Pero tambien en algunos casos, podra ser necesario solicitar aprobacion para
proceder, por razones financieras, de riesgo en los procedimientos o para solicitar apoyo adicional de otras areas. En todo caso, en esta etapa del proceso
debe asignar la categora y prioridad definitiva a la incidencia, en funcion
del tipo de incidencia, urgencia e impacto.
Autoayuda- BD conocimiento: Los sistemas modernos de gestion de incidencias utilizan el registro historico de las incidencias, y toda la informacion
relacionada con el seguimiento, para crear bases de datos de conocimiento
que orientan al usuario sobre las posibles acciones que pueden seguir para
resolver las incidencias por su cuenta. antes de realizar un reporte. De
forma similar, este tipo de sistemas permite que los tecnicos realicen los
diagn
osticos y resoluci
on de incidencias de forma mas efectiva, por medio
de informaci
on relacionada con casos similares que han sido resueltos. En el
caso del proceso propuesto, esta actividad se encuentra ligada al diagnostico,
categorizaci
on y asignacion de prioridad a las incidencias, as como a la recuperaci
on y resoluci
on de la incidencia, tomando en cuenta lo anterior.

Recomendaciones para la gesti

on de incidencias de TI

Aprobaci
on del comit
e ejecutivo: Cuando se considera que es necesario utilizar recursos o procedimientos extraordinarios para la resolucion de una
incidencia, se debe contar con la aprobacion del comite ejecutivo. Toda
aprobaci
on debe ser documentada en formato papel o digital, y se debe
evidenciar la firma del responsable del comite (i.e., se recomienda el uso de
firma digital).
Recuperaci
on y resoluci
on de incidencias: Para realizar esta tarea, el personal de la mesa de servicio debe contar con el personal capacitado con el
conocimiento y herramientas para determinar el mejor curso de accion para
la resoluci
on de la incidencia. Entre las tareas que pueden ser necesarias
durante la resoluci
on de las incidencias se encuentran las siguientes:
1. Realizar la recuperacion de uno o varios servicios asociados
2. Efectuar el reemplazo de equipos, dispositivos o partes (i.e., en algunas
ocasiones puede ser necesario cambiar los estandares sobre caractersticas
de equipos de la empresa para resolver una incidencia)
3. Cambiar procedimientos internos o utilizar procedimientos extraordinarios
4. Solicitar personal de otras areas o personal adicional
5. Revisar las bit
acoras y acciones que fueron realizadas antes y despues de
reportada la incidencia. Esto tiene como fin determinar los cambios que
han sufrido tanto el servicio afectado como otros servicios asociados, as
como determinar cu
ales acciones adicionales pueden ser requeridas
Escalado de incidencias: En el transcurso de la resolucion de incidencias, es
frecuente que cuando no pueden ser resueltas por la mesa de servicio, se
recurra a los procedimientos de escalado.
Las reglas de escalado y gestion de incidencias deben encontrarse especificadas en las polticas, procedimientos o acuerdos formulados por la organizaci
on (e.g., acuerdo de nivel de servicio, acuerdo de nivel operacional
y contrato de apoyo) con los grupos de apoyo internos y externos. En el
caso concreto de este trabajo, se toman en cuenta el escalado funcional y
jer
arquico (ITILv3, 2011), como se muestran en la Figura X y es descrito a
continuaci
on.
Escalado funcional: Este tipo de escalado es utilizado para resolver una
incidencia de forma apropiada, en el tiempo requerido, y tiene como fin
apoyar al grupo que tiene a cargo una incidencia cuya complejidad y
prioridad demanda la participacion de otros grupos con un nivel mas
alto de especializaci
on, experiencia y capacitacion. Los grupos de apoyo
pueden ser internos o externos, como proveedores de software, fabricantes
de hardware o personal de mantenimiento.
Por lo general, la mesa de servicio es la encargada de escalar las incidencias al nivel funcional apropiado, pero se recomienda que sea la
responsable de darles seguimiento, mantener informados a los usuarios
y efectuar el cierre de estas, sin importar el grupo al que hayan sido
referidas para su resolucion.

10

Mora et al.

Escalado jer
arquico: Este tipo de escalado se realiza cuando es necesario
que los mandos superiores esten al tanto de la situacion por el impacto
en el negocio, cuando se requiere su apoyo para coordinar con otros
departamentos o es necesario contar con recursos adicionales, internos o
externos.
Verificaci
on y aceptaci
on: Cuando la incidencia ha sido resuelta, la mesa de
servicio procede a realizar la verificacion, junto con los usuarios afectados, de
que el problema se ha solucionado de forma satisfactoria. Si el usuario acepta
la resoluci
on de la incidencia, se procede a efectuar el cierre y documentacion
de esta, de lo contrario, se procede a trabajar en los aspectos necesarios para
resolver la incidencia a satisfaccion del usuario.
Cierre y documentaci
on: El cierre y documentacion de una incidencia cierra
el ciclo de gesti
on de incidencias, para esa incidencia en particular. Sin embargo, la gesti
on de incidencias es un proceso continuo que comprende la
resoluci
on de las incidencias, la documentacion de todas las acciones realizadas y el uso de la informacion que se genera para obtener conocimiento
que permita mejorar la atencion de lo usuarios. De acuerdo con lo anterior, el
cierre de la incidencia requiere verificar y corregir, si es el caso, la categora
y prioridad asignada, y la documentacion de las tareas realizadas.
Aunque algunas organizaciones implementan mecanismos para el cierre autom
atico de incidencias despues de un determinado periodo de tiempo, en
este trabajo se recomienda que el cierre de las incidencias sea realizado de
forma explcita por la mesa de servicio. El cierre automatico de las incidencias no es adecuado porque puede ocasionar distorsiones sobre las incidencias
que han sido resueltas de forma satisfactoria y las que se pueden haber dejado
en el olvido por su baja prioridad.
El seguimiento de las incidencias es una tarea que se encuentra presente en
todo el proceso de gesti
on de incidencias. Es preciso registrar todos los detalles
de las acciones que se realizan en torno a las incidencias (Forrester et al., 2011;
ITILv3, 2011) y contar con las herramientas apropiadas para alertar al personal
tecnico cuando sea necesario, y tambien para brindarles informacion constante
sobre el estado de las incidencias, as como sobre las interrelaciones e interacciones que tienen entre s.
De forma posterior al cierre de las incidencias se deben estudiar y analizar
los problemas recurrentes, su naturaleza y causa. Pero ademas se recomienda
determinar, con los grupos de soporte involucrados, si las causas de este tipo
de incidencias han sido resueltas, y la posibilidad de que se vuelvan a presentar
otras incidencias relacionadas con esas mismas causas. Esto tiene como fin, tomar
medidas para eliminar o reducir el n
umero de incidencias por una misma causa.
Un elemento de gran importancia en este proceso es asegurar la satisfaccion
de los usuarios, por lo que se recomienda efectuar encuestas (por medio de correo
o telefono) para determinar su nivel de satisfaccion con los servicios de gestion
de incidecias y tomar las medidas necesarias para corregir los problemas que se
detecten. En lnea con esto, es necesario contar con una poltica y procedimientos
claros en torno a la reapertura de incidencias, en caso necesario. Por lo que es

Recomendaciones para la gesti

on de incidencias de TI

11

importante que se brinde capacitacion constante a todo el personal de la mesa

de servicio, tanto sobre aspectos tecnicos como de procedimientos y servicio al
cliente.

Conclusiones

Las organizaciones se enfrentan a retos diversos que requieren el uso de las

mejores pr
acticas existentes, sobre todo cuando se trata de la gestion de incidencias de TI, por la alta dependencia que tienen sus actividades de los sistemas de
hardware y software. Por eso la definicion de un proceso de gestion de incidencias
con base en los marcos de referencia COBIT, ITIL y CCMI es de gran importancia. Sin embargo, es importante considerar que la definicion de un proceso de
esa naturaleza debe tomar en cuenta las particularidades de cada organizacion
con respecto a metas, objetivos y recursos. Conforme con lo anterior, el fin de
este trabajo ha sido orientar a los administradores de TI en la definicion del
proceso de gesti
on de incidencias, mediante la propuesta de un proceso basado
en las mejores pr
acticas de los marcos de referencia mencionados.
La definici
on de un proceso de gestion de incidencias requiere estudiar en
detalle cada organizaci
on y analizar los servicios de TI con los cuales cuenta.
En general, para implementar de forma exitosa y eficiente un proceso de esta
naturaleza, es necesario comprender los procesos de negocio y la forma en que
son soportados por los servicios de TI, para definir de forma adecuada las tareas
y actividades que se requieren. En todo caso, cuando el n
umero de servicios es
reducido, o cuando estos no son complejos, no es necesario definir un proceso
complejo o costoso.
El uso de bibliografa complementaria para definir y justificar la definicion
e implantaci
on de un proceso de gestion de incidencias, adaptado a las necesidades de la organizaci
on, puede ser de gran ayuda. En la literatura se encuentra
documentado que el uso de buenas practicas ayuda a eliminar el trabajo redundante, mejora los tiempos de respuesta (i.e., indicadores de soporte al negocio),
y contribuye con la definici
on de departamentos de TI mejor estructurados, mas
eficientes y enfocados en los objetivos de la empresa (Realtimepublishers.com &
Herold, 2007). Pero, las justificaciones basadas en la literatura (e.g., modelos de
referencia, y casos de estudio) suelen ser insuficientes, porque es necesario justificar con evidencia sustancial la razon costo/beneficio, ante la administracion.
Adem
as, se debe tener en cuenta que la divulgacion, aceptacion y reconocimiento
del proceso por parte de la organizacion toma tiempo y recursos (Quesnel, 2012).
Por esa raz
on, podra ser necesario implementar un plan piloto que permita demostrar el impacto del proceso cuando se presentan incidencias que implican la
interrupci
on de servicios en departamentos estrategicos.
Finalmente, cabe mencionar que los marcos de referencia, aunque tienen objetivos similares, sugieren estrategias diferentes para alcanzarlos. Por ejemplo,
las organizaciones con un nivel de madurez bajo, pueden utilizar ITIL como referencia, debido al grado de detalle que ofrece y el enfoque orientado a tomar
en cuenta los factores internos de cada entidad. Por su parte, CMMI puede ser

12

Mora et al.

usado por empresas con un nivel de madurez mas alto, con mayor experiencia en
la gesti
on de incidencias y el uso de buenas practicas. Lo anterior, debido a que
ofrece recomendaciones (e.g., implementar sistemas de software para la gestion
de incidencias) que no se adaptan a organizaciones con niveles de madurez bajo.

Referencias
Bauset-Carbonell, m., Mara-Carmen1, & Rodenes-Adam, m., Manuel2. (2013).
de los servicios de tecnologIas de la informaciOn:
Modelo de
GestiOn
aporte de valor basado en itil e iso/iec 20000. (spanish). El Profesional de la
Informaci
on, 22 . Retrieved from http://search.ebscohost.com/login
.aspx?direct=true&db=aci&AN=92774922&lang=es&site=ehost-live
pages 2
Forrester, E., Buteau, B., & Shrum, S. (2011). Cmmi for services: Guidelines
for superior service. Pearson Education. Retrieved from https://books
.google.co.cr/books?id=ywvSVLmQmjoC pages 2, 4, 5, 10
IT Governance Institute, I. (2013). Cobit 5. Rolling Meadows. pages 5
ITILv3, F. (2011, Jul). Itil v3 2011. Retrieved from http://itilv3.osiatis
.es/ pages 2, 4, 5, 9, 10
R for systems
Kenett, R., & Baker, E. (2010). Process improvement and cmmi
and software. CRC Press. Retrieved from https://books.google.co.cr/
books?id=a7XS1GmuhWYC pages 4
R v1.2
Mutafelija, B., & Stromberg, H. (2008). Process improvement with cmmi
and iso standards. CRC Press. Retrieved from https://books.google
.co.cr/books?id=ErVuWU\ U0SwC pages 2
OToole, D. (2015). Incident management for i.t. departments. On Demand
Publishing, LLC-Create Space. Retrieved from https://books.google
.co.cr/books?id=M2RargEACAAJ pages 3
Persse, J. (2013). The it service management process manual. van Haren
Publishing. Retrieved from https://books.google.co.cr/books?id=
0FZeAgAAQBAJ pages 2
Quesnel, J. (2012). Entender itil 2011: Normas y mejores pr
acticas para avanzar
ENI. Retrieved from https://books.google.com/
hacia iso 20000. Ed.
books?id=Tn2vJvQ3bwwC pages 11
Realtimepublishers.com, & Herold, R. (2007). The shortcut guide to improving
it service support through itil. Realtimepublishers.com. Retrieved from
https://books.google.com/books?id=BT2bNZ0qYjAC pages 11