Cuando una organización toma la decisión de adoptar las mejores prácticas de ITIL, tienden a preferir la implementación de procesos de cara al cliente para ofrecer valor a su organización inmediatamente. De esta forma, sus usuarios pueden aprovechar la inversión de tiempo y esfuerzo lo más pronto posible y utilizar el éxito de la implementación como plataforma para justificar una inversión mayor en otros procesos de ITIL.

Dentro de las fases del ciclo de vida de ITIL, la fase de Operación al Servicio ofrece las interfaces principales de contacto con el cliente a través de la función de Service Desk y los procesos de Incident Management y Request Fulfillment. La recomendación general es que el Service Desk ejecute casi totalmente ambos procesos, por lo cual hay ocasiones en que las organizaciones tienen el proceso de Incident Management de manera informal, por la herencia de parte del Service Desk, sin saberlo.

Incident Management va más allá de la aportación del Service Desk, y existen mecanismos para asegurar que se obtiene todo el valor potencial que el proceso puede ofrecer. Durante este articulo me gustaría mostrarte algunos aspectos de Incident Management que asegurarán que obtengas el mayor beneficio posible para tu operación y tus usuarios finales.

Incident Management es el proceso que se dedica a gestionar los incidentes en nuestra operación. Un incidente es una interrupción total o parcial en un determinado servicio. Es decir, cuando un servicio no opera de manera “normal” (siendo normal lo que se define en los acuerdos de niveles de servicio) tenemos un incidente en nuestras manos.

El objetivo del proceso es reestablecer la operación lo más rápido posible para minimizar el impacto hacia el negocio al que servimos, por lo que todas las actividades que realicemos dentro de este proceso deben estar orientadas a reparar nuestro servicio en el menor tiempo.

Leer: El indicador más importante

Entradas del proceso

Como todo proceso, Incident Management requiere de un detonador claramente identificable. Los detonadores más comunes son:

• Una llamada al Service Desk
• Un correo electrónico al Service Desk
• El registro de un ticket en el portal web

Estas 3 vías ofrecen una variedad de opciones al usuario final que cubren la mayoría de los escenarios. Sin embargo, dependen de que el usuario perciba el incidente, y por consecuencia ya hubo un impacto hacia la organización y la reputación de TI.

Una cuarta vía frecuentemente ignorada es el proceso de Eventos. De manera práctica, deseamos monitorear la infraestructura utilizada para la entrega de los servicios de manera activa para que cuando un incidente se presente, TI tenga conocimiento incluso antes de que algún usuario se dé cuenta. Más aún, con un monitoreo activo, el resolver el incidente antes que cualquier persona externa al departamento de TI se vuelve una posibilidad.

Por ejemplo, en un escenario donde una aplicación se vuelve lenta por saturación en un servidor, podríamos programar un monitoreo activo para que al cruzar un cierto umbral (idealmente menor al que pudiera representar lentitud), seamos notificados proactivamente y podamos actuar y resolver la saturación antes de que afecte a la operación.

Aunque no es posible detectar toda clase de incidentes antes de que sucedan, nos pueden ayudar a identificar los incidentes de más alta criticidad para atenderlos en un costo reducido.

Leer: ¿Me conviene tercerizar parte de mi operación de TI?

Prioridad de Incidentes

Todas las organizaciones tienen recursos finitos. No importa su tamaño, la intención de cada uno de los colaboradores debe ir siempre orientada a provocar ahorros directos e indirectos. Es importante que tengamos presente que cada peso que se invierte en TI de manera innecesaria, es un peso que una organización deja de invertir en otra área que pudiera eventualmente restarles competencia en su mercado.

Una de las maneras en cómo podemos aportar al ahorro de la organización es a través de la optimización de nuestros recursos de manera que podamos hacer más con lo mismo. Incident Management puede aportar a la operación a través de la correcta identificación de la prioridad de los Incidentes, de manera que los roles encargados de atenderlos tengan claro cuáles deben atenderse primero y cuáles pueden esperar.

La prioridad de los incidentes idealmente debe determinarse antes de que el incidente se presente. Queremos evitar dejar en la interpretación del usuario, del Service Desk o del mismo analista a cargo de atenderlo cuál es la prioridad para el negocio, por lo que es preferible que esté definida por roles que tengan una visión integral de las operaciones de TI y su relación con las operaciones del negocio.

ITIL nos dice que la prioridad es un factor entre el Impacto y la Urgencia, donde el Impacto es la afectación que representa para el negocio y sus operaciones un determinado incidente. Por su lado la urgencia nos habla del tiempo que pasaría antes de que ese impacto se presente en la organización.

Una manera sencilla de establecer la prioridad es a través de una matriz de prioridades como la siguiente:

Teniendo la matriz de factorización de urgencia e impacto, podemos proceder a establecer una lista de posibles prioridades y sus respectivos objetivos de resolución como en este ejemplo:

De esta forma quien esté a cargo de atender un incidente sabe inmediatamente qué representa para el negocio y cuál es la expectativa que debe procurar cumplir, efectivamente organizando la carga de trabajo de acuerdo a los intereses del negocio y no de un usuario en particular.

Leer: TI y el factor humano

Incidente Crítico o Mayor

Identificando la prioridad de los incidentes también se abre la posibilidad de darle un tratamiento especial a incidentes que consideremos de interés particular por su impacto en la organización. Usualmente los incidentes críticos son los que reciben un tratamiento especial por lo que representan para la organización (alto impacto y alta urgencia).

Con los incidentes críticos usualmente tenemos un objetivo de resolución bastante agresivo, sin embargo, lo ideal es establecer procedimientos que aumenten la probabilidad de que ese objetivo pueda ser alcanzado.

El subproceso de incidentes críticos puede estar compuesto por pequeñas variantes sobre el proceso de incidentes regular, por ejemplo:

• Notificaciones a roles ejecutivos de TI
• Involucramiento de proveedores desde su detección
• Apertura de conferencias para información y atención del incidente

Una consideración sumamente importante es que si se decide establecer un subproceso, este sea seguido de manera consistente, casi religiosa. El único criterio para determinar el arranque de proceso es la prioridad. Si una vez que se determine que un incidente es crítico por algún motivo decidimos no iniciar el subproceso, ponemos en riesgo que el futuro ese criterio sea torcido y empleado incorrectamente, disminuyendo su efectividad.

Leer: Mitos y Realidades del Outsourcing

Conclusión

Uno de los procesos más populares para implementar es el de Incident Management, por su alto valor para el negocio y su contribución a una reputación positiva por parte de TI hacia la organización. Sin embargo, un proceso de Incident Management mal implementado nos podría hacer tropezar en el viaje hacia la implementación de mejores prácticas.

La posibilidad de detectar incidentes antes de que afecten al usuario, asignarles una prioridad que determine su orden de importancia y la atención a incidentes particulares con subprocesos, nos ofrecen oportunidades para obtener aún más valor y ofrecer mejores resultados.

Si estas por iniciar un proyecto de TI, Service Desk, Soporte Técnico o tienes dudas sobre el tema te invito a que nos contactes.