Recomendaciones para la Gestion de Incidencias de Tecnologas de la Informacion

Recomendaciones para la Gestion de Incidenciasde Tecnologıas de la Informacion

Verny Mora Jimenez, Paulo Viales Wahrmann, Julio Cordoba Retana yAntonio Gonzalez Torres

Escuela de Ingenierıa,Universidad Latinoamericana de Ciencia y Tecnologıa,

ULACIT, Urbanizacion Tournon, 10235-1000San Jose, Costa Rica

[[email protected],[email protected],jcordobar022,

agonzalezt899]@ulacit.ed.cr

http://www.ulacit.ac.cr

Abstract. La gestion de incidencias es un proceso crıtico en la admin-istracion de los servicios de Tecnologıas de la Informacion (TI), por elimpacto en las operaciones de las organizaciones y la relacion que se es-tablece entre los usuarios y el departamento de TI. De acuerdo con esto,este trabajo de investigacion lleva a cabo el analisis de las principales ac-tividades asociadas, conforme con los marcos de referencia ITIL, COBITy CMMI, y propone un proceso para la gestion de incidencias. El objetivoes apoyar a los administradores de TI en la definicion e implementacionde la gestion de incidencias mediante la discusion de la propuesta y elflujo de las tareas que componen el proceso.

Keywords: Gestion de Incidencias, ITIL, COBIT, CMMI

1 Introduccion

En el contexto actual, las tecnologıas de la informacion (TI) son un factor crıticopara el desempeno de las organizaciones, por lo que requieren el correcto fun-cionamiento de los sistemas de hardware y software que utilizan. Esto conllevaque las incidencias1 que se presenten deben ser resueltas de forma oportuna,tanto a usuarios internos como externos. Por lo que es necesario que las inciden-cias se gestionen de forma adecuada, para evitar que se transformen en riesgospara la continuidad de la organizacion

En este punto resulta indispensable tener en cuenta que los servicios de TIdeben ofrecer servicios de calidad con alta disponibilidad, utilizar los recursos deforma mas eficiente, ayudar a incrementar la productividad de los usuarios, re-ducir costos, tiempos de ejecucion de procesos y riesgos, y alinearse a los procesosdel 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 prestacion de unservicio que es soportado por hardware o software.

2 Mora et al.

alcanzar unicamente con fuertes inversiones en tecnologıa y personal cualificado,sino que es necesario contar con una buena gestion y planificacion a nivel em-presarial. Para esto, es recomendable implementar un Sistema de Gestion deServicios de TI (SGSTI), potenciar la labor de los gestores y utilizar metricaspara 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, ademasdel impacto que tiene en la organizacion, determina la relacion de los departa-mentos de TI con los usuarios, y en cierta forma se convierte en un reflejo dela calidad de los servicios que estos ofrecen. Cabe resaltar que la calidad de losservicios implica tanto el nivel de efectividad de la resolucion de los problemascomo la forma en que el servicio es percibido por los usuarios y el resto de laorganizacion (Persse, 2013).

De acuerdo con la experiencia de los autores, un gran numero de organiza-ciones no aplican las mejores practicas de la industria para la gestion de inci-dencias, en algunos casos por desconocimiento y en otros por que no le brindanimportancia necesaria. Tomando en cuenta lo anterior, en este trabajo se es-tudian y analizan los lineamientos y mejores practicas que son recomendadaspor COBIT, ITIL y CMMI con el fin de proponer un proceso y una lista derecomendaciones que sirvan como guıa para realizar la gestion de incidencias enservicios de TI. Dicho proceso pretende contribuir con la deteccion oportuna dedesviaciones en los procedimientos, la correcta clasificacion de las incidencias, lautilizacion de procedimientos de escalado y el cierre adecuado de las incidencias.El fin de este planteamiento es contribuir con la mejora de los porcentajes deefectividad en la resolucion de incidencias de las organizaciones, en un plazo nomayor a un ano de la puesta en marcha del proceso.

2 Marco Teorico

Una incidencia es un evento que implica la interrupcion no planificada o lareduccion de la calidad de un servicio de TI, el cual es soportado por elementosde hardware o software (ITILv3, 2011). Las incidencias pueden ser detectadaspor el personal tecnico, reportadas por herramientas de seguimiento de eventos,comunicadas por los usuarios de forma telefonica o mediante un sistema deincidencias o informadas por terceros (e.g., proveedores y socios de negocio2).En tanto, la gestion de las incidencias es el proceso responsable de administrarel ciclo de vida de cada incidencia (Persse, 2013).

La gestion de incidencias requiere brindar respuesta oportuna y efectiva a laspeticiones de los usuarios relacionadas con la resolucion de problemas asociadosa los servicios de TI, esto con el fin de no afectar los procesos de la organizaciony cumplir con los compromisos con terceros (Forrester, Buteau, & Shrum, 2011).En terminos generales, este proceso contempla registrar las peticiones de servi-cio, diagnosticar el problema de forma precisa (i.e., identificar y describir los

2 Conocidos como partners por su acepcion en ingles.

Recomendaciones para la gestion de incidencias de TI 3

sıntomas de las incidencias, ası como asignar los recursos necesarios para su res-olucion), determinar la prioridad de la incidencia, resolver las incidencias (i.e.,determinar las posibles causas, efectuar escalaciones y recuperar el servicio, encaso necesario), documentar y registrar de forma exhaustiva la resolucion de laincidencia, cerrar las incidencias y mantener un registro historico (ver procesosDSS02 y DSS03 de COBIT 5) (?, ?; O’Toole, 2015).

El registro de las peticiones de servicio requiere verificar que estas cumplencon los criterios mınimos establecidos y que los usuarios que las realizan estandebidamente autorizados. Cada incidencia debe contar con un numero unico dereferencia, hora y fecha de registro, identificacion de la persona que realizo elregistro de la incidencia, metodo de notificaciones del estado de la incidencia,descripcion de los sıntomas.

En cuanto al diagnostico, es necesario contar con toda la informacion disponiblepara efectuar una mejor evaluacion del problema para efectuar su categorizacion,determinar el impacto en el negocio (i.e., nivel de perdida financiera, el posibleefecto en la reputacion del negocio y las regulaciones del paıs) y la urgenciade su resolucion, efectuar una correcta asignacion de la prioridad, obtener laaprobacion financiera y si se requiere, el cambio de procedimientos o estandares.

Como parte este proceso se requiere require utilizar la base de datos deconocimiento, si existe, para determinar si el problema esta asociado a un errorconocido, o si este ha sido resuelto anteriormente. Este paso se debe realizarantes de asignar a un especialista para realizar un analisis de mayor profundidado que se realicen acciones para restaurar los servicios afectados, con ayuda deotros especialistas.

En los casos en los que la incidencia es reportada por telefono, se recomiendaefectuar un diagnostico inicial e intentar ofrecer una solucion de forma inmediata,trabajando junto con el usuario, si es factible. Si no es posible ofrecer una solucioninmediata, entonces se debe informar al interesado sobre el procedimiento quese seguira, y darle un numero de incidencia para que le pueda dar seguimiento.

En lo que respecta a la resolucion de incidencias, conviene tener en cuanta laposibilidad de seguir el procedimiento para efectuar el escalado de la incidencia.Este tipo de procedimiento usualmente contempla el escalado funcional (se so-licita el apoyo de un especialista de mas alto nivel para resolver el problema) ojerarquico (se acude a un responsable de mayor autoridad para tomar decisionespor encima del nivel del personal tecnico involucrado, como la asignacion derecursos adicionales para la resolucion del incidencia).

En todo caso, es recomendable resolver cada incidencia en el menor tiempoposible, para restaurar o normalizar el servicio y salvaguardar los intereses de laorganizacion. Pero ademas, es necesario que en el transcurso de la resolucion sele brinde seguimiento al estado de las incidencias hasta que se realice el cierrede esta. El proceso de seguimiento involucra documentar y revisar las accionesrealizadas, escalar las incidencias segun se requiera y comunicar el estado de laincidencia a las partes interesadas.

En el transcurso de la resolucion de una incidencia puede ser necesario efec-tuar procedimientos de recuperacion de los servicios, los cuales dependeran de la

4 Mora et al.

naturaleza de esta, y podrıan involucrar la participacion activa del usuario en larealizacion de actividades concretas, de forma similar se podrıa requerir la par-ticipacion de otros especialistas e incluso de consultores o proveedores externos.

Una vez que la incidencia ha sido resuelta, se deben hacer las comprobacionesnecesarias con el usuario para cerrar el caso, medir la satisfaccion, tener encuenta los requerimientos de informes de las partes interesadas en la gestion deincidencias y utilizar criterios de calidad del servicio (Forrester et al., 2011).

El cierre de la incidencia debe contemplar la documentacion de las activi-dades que se realizaron para resolverla, la fecha de resolucion, la categorıa decierre, la fecha en que se esta efectuando el cierre y la resolucion de las causassubyacentes a la incidencia (Kenett & Baker, 2010). Ademas, se requiere docu-mentar las soluciones identificadas, registrar si se usaron soluciones temporaleso acciones de recuperacion de servicios, determinar las acciones incorrectas quese llevaron a cabo y comprender el proceso que se siguio durante la resolucion.Esta informacion permite efectuar el analisis, evaluacion y clasificacion de inci-dencias para establecer tendencias, encontrar patrones de asuntos recurrentes einfracciones a los procedimientos, reducir la ocurrencia de incidencias similaresen el futuro, mejorar su resolucion y apoyar la busqueda de mejores practicas.

3 Proceso para la Gestion de Incidencias

La definicion de un proceso para la gestion de incidencias requiere que, en primerlugar, se determinen de forma clara las polıticas, procedimientos y definicionesque seran considerados por este. Conforme con lo anterior, se recomienda tomaren cuenta los elementos que se presentan en la siguiente lista.

Definicion de una incidencia: Es necesario diferenciar de forma clara entreuna incidencia y una solicitud de servicio. Una incidencia es la interrupcionno planificada o la reduccion de la calidad de un servicio de TI. Si bienlas solicitudes de servicio deben ser reportadas de forma similar que lasincidencias a la mesa de servicio, la diferencia es que estas no representan lainterrupcion de un servicio (ITILv3, 2011).

Categorıas: La definicion de categorıas es otro elemento fundamental en lagestion de incidencias, para ubicar y asignar los recursos humanos y materi-ales de forma correcta cuando una incidencia es reportada. Sobre este par-ticular, tanto ITIL como CMMI ofrecen recomendaciones para realizar uncatalogo de categorıas de incidencias (ITILv3, 2011; Forrester et al., 2011).Como recomendacion, se sugiere realizar una lluvia de ideas con el personalinvolucrado en la gestion de incidencias (e.g., los tecnicos de soporte, su-pervisores de gestion de incidencias y administradores), para crear una listapreliminar de categorıas, que se ponga a prueba por un periodo corto detiempo. De forma posterior, se recomienda analizar las incidencias repor-tadas durante un periodo de tiempo para afinar la lista de categorıas deincidencias. Como buena practica, el catalogo de categorıas debe ser anal-izado de forma periodica, cada 3 o 5 meses, para realizar actualizaciones ymantenerlo adecuado a las necesidades del negocio.


Responsable de incidencias: La asignacion de responsabilidades es otro ele-mento a tener en cuenta. En este aspecto, tanto COBIT (IT Governance In-stitute, 2013) como CMMI (Forrester et al., 2011) especifican varios lin-eamientos importantes. En general, es necesario especificar cuales son lasresponsabilidades del tecnico al que se le asigna una incidencia, ası comoquien es el responsable de supervisar, dar seguimiento al estado de las in-cidencias, efectuar los procesos de escalado y realizar la transferencia deresponsabilidades entre pasos o procesos.

Asignacion de prioridad: La resolucion de las incidencias requiere contar condiferentes niveles de prioridad, en funcion de la relevancia e impacto en elnegocio. De acuerdo con el analisis de COBIT 5, ITIL y CMMI se recomiendael uso de 5 niveles de prioridad usando valores numericos (e.g., 1 a 5) ocategoricos (baja, media, alta, grave, crıtica).

Reporte de incidencias: Es importante definir de forma clara los mecanis-mos para el reporte de las incidencias y seguimiento de las incidencias, sinimportar si se realiza de forma manual o automatizada. En todo caso, laspersonas que reportan las incidencias deben encontrarse autorizadas, excep-tuando los casos en que se demuestre que peligra la vida de las personas oque la continuidad del negocio esta siendo afectada.En general, se recomienda contar con un sistema que facilite el reporte de in-cidencias a los usuarios (Forrester et al., 2011), la actualizacion de los estados(e.g., abierta, en progreso, resuelta y cerrada) (ITILv3, 2011) y seguimientode las acciones realizadas durante el ciclo de vida de las incidencias.

Reapertura de incidencias: En algunos casos es posible que una incidenciano haya sido resuelta por completo y sea necesario reabrirla. Por lo quese requiere definir las reglas para reabrir incidencias, asignarles una nuevacategorıa y prioridad, y determinar quien sera el responsable que trabajaraen la solucion.

En general, los modelos relacionados con la gestion de las tecnologıas de lainformacion coinciden en cuanto a las principales tareas que requiere el procesode gestion de incidencias, siendo esas tareas las siguientes:

1. Registro de incidencias.2. Resolucion de incidencias.3. Cierre de incidencias.4. Seguimiento y analisis de incidencias.

En consecuencia, este trabajo ha tomado en cuenta la lista de tareas enun-ciadas y las mejores practicas de COBIT (IT Governance Institute, 2013), ITIL(ITILv3, 2011) y CMMI (Forrester et al., 2011), para proponer el proceso que semuestra en la Figura 1. Las tareas ordinarias de dicho proceso son representadaspor cajas rectangulares y las decisiones por rombos, en tanto que las lıneas decolor rojo indican el flujo ordinario de las tareas y las lıneas punteadas de colornegro muestran la secuencia alternativa, en donde el flujo puede seguir uno uotro camino con base en las decisiones que se han tomado.

6 Mora et al.

El proceso propuesto comienza con la identificacion de las incidencias, porparte de los usuarios de la organizacion o los miembros del departamento deTI (i.e., por observacion en el campo o por medio del uso de sistemas para eseproposito). Una vez que la incidencia ha sido identificada, se procede a regis-trarla, para luego efectuar el diagnostico (i.e., de forma opcional se puede usarla base de conocimientos), categorizacion y asignacion de prioridad. Con base enel diagnostico, se determina si la resolucion de la incidencia requiere de recursosextraordinarios, y en caso necesario se solicita la aprobacion de esos recursos alcomite 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 casode que la incidencia se haya resuelto de forma efectiva, se realiza la verificaciony aceptacion de la solucion con el usuario. Sin embargo, cuando la incidenciano ha sido resuelta, se verifica si el personal tecnico a cargo puede terminar desolucionarla o si es necesario solicitar el escalado de la incidencia. En caso de quesea necesario escalar la incidencia, se determina si el escalado que se requiere esfuncional o jerarquico. Cuando el proceso de escalado ha terminado, se verificasi la incidencia ha sido resuelta, y si es ası, se procede a realizar la verificacion yaceptacion con el usuario. En caso de que la incidencia no haya sido resuelta trasel proceso de escalado, se determina si el equipo de la mesa de servicio puedeterminar de resolverla o si es necesario volver a seguir el proceso de escalado.Una vez que la resolucion de la incidencia ha sido resuelta de forma definitiva,tras efectuar la verificacion y aceptacion con el usuario, se procede a cerrarla ydocumentarla.

La descripcion de cada una de las tareas que conforman el proceso propuestose detalla en a continuacion.


Fig.1.

Pro

ceso

para

lages

tion

de

inci

den

cias

de

tecn

olo

gıa

sde

lain

form

aci

on.

8 Mora et al.

Identificacion de incidencias: En un escenario ideal, se brinda seguimientoconstante a los recursos y servicios crıticos de la organizacion para prevenir laocurrencia de incidencias o bien, un gran numero de incidencias es detectadopor el departamento de TI en el momento en que se presentan, incluso antesde que los usuarios se den cuenta de los eventos. Sin embargo, como muestrala Figura X, la identificacion de las incidencias, por lo general, es realizadatanto por los usuarios de la organizacion como por el departamento de TI.

Registro de incidencias: El proceso para registrar las incidencias debe ponera disposicion de los usuarios autorizados tantos medios como sea posible, in-cluyendo llamadas telefonicas, registro web y mensajerıa instantanea. Caberecalcar que tanto el reporte como el registro de incidencias debe ser efec-tuado por usuarios que se encuentren autorizados, conforme a lo establecidopor las polıticas y reglamentos de la organizacion.Algunos de los principales elementos de informacion para registrar una inci-dencia son los siguientes:

1. Nombre de quien registra y quien reporta la incidencia2. Datos de contacto3. Descripcion detallada de la incidencia4. Fecha y hora del reporte (tomada por el sistema)5. Numero de referencia (generado por el sistema)6. Prioridad y categorıa inicial (ingresada por quien registra la incidencia)7. Notas sobre el impacto en el negocio

Diagnostico, categorizacion y prioridad: El diagnostico, dependiendo dela naturaleza de la incidencia, se puede realizar de forma paralela a su reg-istro. En algunos casos es posible que durante este proceso, con asistenciade una base de datos de conocimiento, el problema sea solucionado por elusuario que esta efectuando el reporte o por quien esta registrando la inci-dencia (e.g., tambien es posible que la incidencia sea resuelta al momento dehacer el diagnostico, en el momento en que se recibe el reporte por telefono).Pero tambien en algunos casos, podrıa ser necesario solicitar aprobacion paraproceder, por razones financieras, de riesgo en los procedimientos o para so-licitar apoyo adicional de otras areas. En todo caso, en esta etapa del procesodebe asignar la categorıa y prioridad definitiva a la incidencia, en funciondel tipo de incidencia, urgencia e impacto.

Autoayuda- BD conocimiento: Los sistemas modernos de gestion de inci-dencias utilizan el registro historico de las incidencias, y toda la informacionrelacionada con el seguimiento, para crear bases de datos de conocimientoque orientan al usuario sobre las posibles acciones que pueden seguir pararesolver las incidencias por su cuenta. antes de realizar un reporte. Deforma similar, este tipo de sistemas permite que los tecnicos realicen losdiagnosticos y resolucion de incidencias de forma mas efectiva, por mediode informacion relacionada con casos similares que han sido resueltos. En elcaso del proceso propuesto, esta actividad se encuentra ligada al diagnostico,categorizacion y asignacion de prioridad a las incidencias, ası como a la re-cuperacion y resolucion de la incidencia, tomando en cuenta lo anterior.


Aprobacion del comite ejecutivo: Cuando se considera que es necesario uti-lizar recursos o procedimientos extraordinarios para la resolucion de unaincidencia, se debe contar con la aprobacion del comite ejecutivo. Todaaprobacion debe ser documentada en formato papel o digital, y se debeevidenciar la firma del responsable del comite (i.e., se recomienda el uso defirma digital).

Recuperacion y resolucion de incidencias: Para realizar esta tarea, el per-sonal de la mesa de servicio debe contar con el personal capacitado con elconocimiento y herramientas para determinar el mejor curso de accion parala resolucion de la incidencia. Entre las tareas que pueden ser necesariasdurante la resolucion de las incidencias se encuentran las siguientes:

1. Realizar la recuperacion de uno o varios servicios asociados2. Efectuar el reemplazo de equipos, dispositivos o partes (i.e., en algunas

ocasiones puede ser necesario cambiar los estandares sobre caracterısticasde equipos de la empresa para resolver una incidencia)

3. Cambiar procedimientos internos o utilizar procedimientos extraordinar-ios

4. Solicitar personal de otras areas o personal adicional5. Revisar las bitacoras y acciones que fueron realizadas antes y despues de

reportada la incidencia. Esto tiene como fin determinar los cambios quehan sufrido tanto el servicio afectado como otros servicios asociados, asıcomo determinar cuales acciones adicionales pueden ser requeridas

Escalado de incidencias: En el transcurso de la resolucion de incidencias, esfrecuente que cuando no pueden ser resueltas por la mesa de servicio, serecurra a los procedimientos de escalado.Las reglas de escalado y gestion de incidencias deben encontrarse especifi-cadas en las polıticas, procedimientos o acuerdos formulados por la orga-nizacion (e.g., acuerdo de nivel de servicio, acuerdo de nivel operacionaly contrato de apoyo) con los grupos de apoyo internos y externos. En elcaso concreto de este trabajo, se toman en cuenta el escalado funcional yjerarquico (ITILv3, 2011), como se muestran en la Figura X y es descrito acontinuacion.

Escalado funcional: Este tipo de escalado es utilizado para resolver unaincidencia de forma apropiada, en el tiempo requerido, y tiene como finapoyar al grupo que tiene a cargo una incidencia cuya complejidad yprioridad demanda la participacion de otros grupos con un nivel masalto de especializacion, experiencia y capacitacion. Los grupos de apoyopueden ser internos o externos, como proveedores de software, fabricantesde hardware o personal de mantenimiento.Por lo general, la mesa de servicio es la encargada de escalar las in-cidencias al nivel funcional apropiado, pero se recomienda que sea laresponsable de darles seguimiento, mantener informados a los usuariosy efectuar el cierre de estas, sin importar el grupo al que hayan sidoreferidas para su resolucion.

10 Mora et al.

Escalado jerarquico: Este tipo de escalado se realiza cuando es necesarioque los mandos superiores esten al tanto de la situacion por el impactoen el negocio, cuando se requiere su apoyo para coordinar con otrosdepartamentos o es necesario contar con recursos adicionales, internos oexternos.

Verificacion y aceptacion: Cuando la incidencia ha sido resuelta, la mesa deservicio procede a realizar la verificacion, junto con los usuarios afectados, deque el problema se ha solucionado de forma satisfactoria. Si el usuario aceptala resolucion de la incidencia, se procede a efectuar el cierre y documentacionde esta, de lo contrario, se procede a trabajar en los aspectos necesarios pararesolver la incidencia a satisfaccion del usuario.

Cierre y documentacion: El cierre y documentacion de una incidencia cierrael ciclo de gestion de incidencias, para esa incidencia en particular. Sin em-bargo, la gestion de incidencias es un proceso continuo que comprende laresolucion de las incidencias, la documentacion de todas las acciones real-izadas y el uso de la informacion que se genera para obtener conocimientoque permita mejorar la atencion de lo usuarios. De acuerdo con lo anterior, elcierre de la incidencia requiere verificar y corregir, si es el caso, la categorıay prioridad asignada, y la documentacion de las tareas realizadas.Aunque algunas organizaciones implementan mecanismos para el cierre au-tomatico de incidencias despues de un determinado periodo de tiempo, eneste trabajo se recomienda que el cierre de las incidencias sea realizado deforma explıcita por la mesa de servicio. El cierre automatico de las inciden-cias no es adecuado porque puede ocasionar distorsiones sobre las incidenciasque han sido resueltas de forma satisfactoria y las que se pueden haber dejadoen el olvido por su baja prioridad.

El seguimiento de las incidencias es una tarea que se encuentra presente entodo el proceso de gestion de incidencias. Es preciso registrar todos los detallesde 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 personaltecnico cuando sea necesario, y tambien para brindarles informacion constantesobre el estado de las incidencias, ası como sobre las interrelaciones e interac-ciones que tienen entre sı.

De forma posterior al cierre de las incidencias se deben estudiar y analizarlos problemas recurrentes, su naturaleza y causa. Pero ademas se recomiendadeterminar, con los grupos de soporte involucrados, si las causas de este tipode incidencias han sido resueltas, y la posibilidad de que se vuelvan a presentarotras incidencias relacionadas con esas mismas causas. Esto tiene como fin, tomarmedidas para eliminar o reducir el numero de incidencias por una misma causa.

Un elemento de gran importancia en este proceso es asegurar la satisfaccionde los usuarios, por lo que se recomienda efectuar encuestas (por medio de correoo telefono) para determinar su nivel de satisfaccion con los servicios de gestionde incidecias y tomar las medidas necesarias para corregir los problemas que sedetecten. En lınea con esto, es necesario contar con una polıtica y procedimientosclaros en torno a la reapertura de incidencias, en caso necesario. Por lo que es


importante que se brinde capacitacion constante a todo el personal de la mesade servicio, tanto sobre aspectos tecnicos como de procedimientos y servicio alcliente.

4 Conclusiones

Las organizaciones se enfrentan a retos diversos que requieren el uso de lasmejores practicas existentes, sobre todo cuando se trata de la gestion de inciden-cias de TI, por la alta dependencia que tienen sus actividades de los sistemas dehardware y software. Por eso la definicion de un proceso de gestion de incidenciascon base en los marcos de referencia COBIT, ITIL y CCMI es de gran impor-tancia. Sin embargo, es importante considerar que la definicion de un proceso deesa naturaleza debe tomar en cuenta las particularidades de cada organizacioncon respecto a metas, objetivos y recursos. Conforme con lo anterior, el fin deeste trabajo ha sido orientar a los administradores de TI en la definicion delproceso de gestion de incidencias, mediante la propuesta de un proceso basadoen las mejores practicas de los marcos de referencia mencionados.

La definicion de un proceso de gestion de incidencias requiere estudiar endetalle cada organizacion y analizar los servicios de TI con los cuales cuenta.En general, para implementar de forma exitosa y eficiente un proceso de estanaturaleza, es necesario comprender los procesos de negocio y la forma en queson soportados por los servicios de TI, para definir de forma adecuada las tareasy actividades que se requieren. En todo caso, cuando el numero de servicios esreducido, o cuando estos no son complejos, no es necesario definir un procesocomplejo o costoso.

El uso de bibliografıa complementaria para definir y justificar la definicione implantacion de un proceso de gestion de incidencias, adaptado a las necesi-dades de la organizacion, puede ser de gran ayuda. En la literatura se encuentradocumentado que el uso de buenas practicas ayuda a eliminar el trabajo redun-dante, mejora los tiempos de respuesta (i.e., indicadores de soporte al negocio),y contribuye con la definicion de departamentos de TI mejor estructurados, maseficientes y enfocados en los objetivos de la empresa (Realtimepublishers.com &Herold, 2007). Pero, las justificaciones basadas en la literatura (e.g., modelos dereferencia, y casos de estudio) suelen ser insuficientes, porque es necesario jus-tificar con evidencia sustancial la razon costo/beneficio, ante la administracion.Ademas, se debe tener en cuenta que la divulgacion, aceptacion y reconocimientodel proceso por parte de la organizacion toma tiempo y recursos (Quesnel, 2012).Por esa razon, podrıa ser necesario implementar un plan piloto que permita de-mostrar el impacto del proceso cuando se presentan incidencias que implican lainterrupcion de servicios en departamentos estrategicos.

Finalmente, cabe mencionar que los marcos de referencia, aunque tienen ob-jetivos similares, sugieren estrategias diferentes para alcanzarlos. Por ejemplo,las organizaciones con un nivel de madurez bajo, pueden utilizar ITIL como ref-erencia, debido al grado de detalle que ofrece y el enfoque orientado a tomaren 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 enla gestion de incidencias y el uso de buenas practicas. Lo anterior, debido a queofrece recomendaciones (e.g., implementar sistemas de software para la gestionde incidencias) que no se adaptan a organizaciones con niveles de madurez bajo.

Referencias

Bauset-Carbonell, m., Marıa-Carmen1, & Rodenes-Adam, m., Manuel2. (2013).GestiOn de los servicios de tecnologIas de la informaciOn: Modelo deaporte de valor basado en itil e iso/iec 20000. (spanish). El Profesional de laInformacion, 22 . Retrieved from http://search.ebscohost.com/login

.aspx?direct=true&db=aci&AN=92774922&lang=es&site=ehost-live

pages 2Forrester, 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, 10IT Governance Institute, I. (2013). Cobit 5. Rolling Meadows. pages 5ITILv3, F. (2011, Jul). Itil v3 2011. Retrieved from http://itilv3.osiatis

.es/ pages 2, 4, 5, 9, 10Kenett, R., & Baker, E. (2010). Process improvement and cmmi R© for systems

and software. CRC Press. Retrieved from https://books.google.co.cr/

books?id=a7XS1GmuhWYC pages 4Mutafelija, B., & Stromberg, H. (2008). Process improvement with cmmi R© v1.2

and iso standards. CRC Press. Retrieved from https://books.google

.co.cr/books?id=ErVuWU\ U0SwC pages 2O’Toole, 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 3Persse, J. (2013). The it service management process manual. van Haren

Publishing. Retrieved from https://books.google.co.cr/books?id=

0FZeAgAAQBAJ pages 2Quesnel, J. (2012). Entender itil 2011: Normas y mejores practicas para avanzar

hacia iso 20000. Ed. ENI. Retrieved from https://books.google.com/

books?id=Tn2vJvQ3bwwC pages 11Realtimepublishers.com, & Herold, R. (2007). The shortcut guide to improving

it service support through itil. Realtimepublishers.com. Retrieved fromhttps://books.google.com/books?id=BT2bNZ0qYjAC pages 11

Recomendaciones para la Gestion de Incidencias de Tecnologas de la Informacion

Documents

Transcript of Recomendaciones para la Gestion de Incidencias de Tecnologas de la Informacion