El secreto del éxito reside en subir la escalera, en lugar de un simple salto hacia el cielo. Dar un paso a la vez requiere que el conocimiento se almacene, se aproveche y se mejore. En ITIL®, una de esas herramientas que ayuda a las organizaciones a lograr este éxito es la Base de Datos de Errores Conocidos (KEDB).
Aquí encontrarás todo lo que necesitas saber sobre KEDB, junto con ejemplos reales de mi experiencia como consultor.
¿Qué es KEDB?
Hay tres términos ITIL® con los que debes estar familiarizado para entender KEDB. Estos incluyen incidente, problema y error conocido.
Cuando te enfrentas a una interrupción imprevista de un servicio informático, se denomina incidente. Por ejemplo, si tu servicio de correo electrónico se interrumpe sin que tu proveedor te avise, esto podría ser etiquetado como un incidente.
Un problema es la causa subyacente de un incidente. En pocas palabras, esto es lo que causó el problema en primer lugar. En el ejemplo anterior, la razón detrás de la interrupción del correo electrónico es el problema. Digamos que se identifica la causa fundamental de un problema. Ahora ya no es un problema, sino un error conocido. En el caso del incidente del correo electrónico, la causa raíz se identifica como uno de los servicios críticos del servidor de correo electrónico que estaba en modo colgado . Así que, lo que antes era un problema ahora es un error conocido.
Un KEDB es una base de datos de todos los errores conocidos, registrados como son y cuando ocurrieron – y se mantienen a lo largo del tiempo.
¿Por qué necesitas KEDB?
¿Cómo justifica exactamente una empresa el gasto de capital y los costos operativos en la base de datos?
Volviendo al incidente del correo electrónico, digamos que el servicio crítico estaba en modo colgado después de ejecutar una serie de diagnósticos y realizar una serie de pruebas. Después de identificarlo, la resolución podría haber sido más rápida cuando el servicio fue detenido y reiniciado. Pero para llegar a la resolución, se necesitó mucho esfuerzo y, más importante aún, se recortó un tiempo precioso. Mientras se aplicaban los diagnósticos y la resolución, el servicio de correo electrónico estaba parado. Esto podría resultar en penalizaciones impuestas por los clientes, y pérdidas intangibles como futuras oportunidades de negocio y satisfacción del cliente.
Sin embargo, esta organización que proporciona servicios de correo electrónico a sus clientes mantiene un KEDB, y este incidente en particular fue registrado. Cuando el servicio de correo electrónico se cae de nuevo, el equipo de soporte técnico puede simplemente referirse a la interrupción anterior en el KEDB, y puede comenzar el diagnóstico con el servicio que causó el problema la última vez. Si resulta ser el mismo servicio que causó el problema, la resolución ahora ocurre en una fracción del tiempo. Como puede ver, esto reduce en gran medida el tiempo de inactividad y todos los demás efectos negativos que se derivan de las interrupciones del servicio. ¡Esto es KEDB en acción!
Un registro de la KEDB tendrá detalles del incidente, cuándo ocurrió el apagón y qué se hizo para resolverlo. Sin embargo, para una rápida resolución, el KEDB debe ser lo suficientemente potente como para recuperar registros relevantes usando filtros y palabras clave de búsqueda. Sin un KEDB, las organizaciones de gestión de servicios tienden a reinventar la rueda una y otra vez, en lugar de trabajar para construir una organización madura que asigne sus fondos a la mejora de los servicios.
Solución provisional y permanente
Cuando hay cortes de servicio, hay dos maneras de restaurarlos. La primera, y la más ideal, es una solución permanente. Una solución permanente implica un arreglo que garantice que no haya más interrupciones, al menos en un cierto nivel. La segunda, y más común, es la restauración, que busca una solución temporal y alternativa. Por lo general, la solución alternativa va seguida de la identificación y aplicación de una solución permanente en una fecha posterior.
En el corte del servicio de correo electrónico, reiniciar el servicio es una solución. El personal técnico sabe que esto resolverá el problema por el momento (lo cual es de gran importancia), pero que está destinado a repetirse en el futuro. Antes de que el incidente se repita, corresponde al equipo técnico investigar por qué el servicio no responde y encontrar una solución permanente.
Veamos otro ejemplo clásico que he usado una y otra vez durante los entrenamientos – este realmente lleva a casa los conceptos de solución de problemas y solución permanente. Imagina que la impresora de tu cabina deja de funcionar y la necesitas de inmediato. Registras un incidente con tu personal técnico, diciendo que estás a punto de entrar en una reunión con un cliente y necesitas imprimir algunos documentos. La persona de apoyo determina que no puede arreglar la impresora a tiempo y le proporciona una solución para enviar sus archivos a una impresora común en el vestíbulo.
La solución ayuda, ya que tu objetivo es conseguir las huellas y llegar a una reunión. Pero, no hay manera de que quieras la molestia de tener que hacer esto cada vez que necesites imprimir. Así que, cuando la reunión termine, presionas por una solución permanente. Cuando regresas, tu impresora está funcionando y hay una nota del personal de apoyo que dice que el cable de alimentación estaba defectuoso y ha sido reemplazado. Esta es una solución permanente. Y aunque existe la posibilidad de que el nuevo cable también pueda fallar, las probabilidades están a tu favor.
En pocas palabras: La solución es un arreglo temporal. La solución permanente es, como dice el término, permanente.
¿Por qué discutí sobre la solución permanente en un puesto que está dirigido a la KEDB? Los errores conocidos existen porque la solución es temporal. La base de datos de errores conocidos consiste en registros donde no existe una solución permanente, pero sí una solución alternativa. En el caso de un registro de errores conocidos, si se implementara una solución permanente, entonces el registro puede ser eliminado o archivado como evidencia. Los registros de errores conocidos con una solución permanente implementada no deben ser parte de la KEDB en principio.
Este concepto se desarrolla más adelante en la siguiente sección donde hablaremos de los diversos árboles de procesos para crear, utilizar y archivar los registros de errores conocidos.
KEDB en acción
Ahora que sabes lo que es un KEDB y lo que contiene, hablemos de cómo y cuándo se graba, se usa y se mantiene.
Estos son los tres arroyos en los que se aprovecha el KEDB:
1. Cuando un incidente se resuelve por medios temporales, se crea un registro de errores conocidos con el resumen del incidente, la descripción, los síntomas y todos los pasos necesarios para resolverlo.
Supongamos que un usuario ha informado de que la aplicación MS Outlook se bloquea cuando los correos electrónicos empiezan a descargarse. El personal técnico, con el fin de minimizar la interrupción del servicio, aconsejó al cliente que accediera al webmail hasta que se resolviera el problema. Los detalles del incidente, junto con los síntomas y los pasos de resolución temporales, deben registrarse en un nuevo registro de errores conocidos.
2. Cuando se informa de un incidente, el equipo de apoyo se dirige primero a la KEDB para comprobar si existe una solución en la base de datos. Si es así, se referirán al registro de errores conocidos y seguirán los pasos de resolución correspondientes. Suponiendo que la solución proporcionada sea inexacta, el equipo de apoyo puede recomendar pasos de resolución alternativos para asegurar que el KEDB sea de alta calidad.
Digamos que en otro momento y lugar, la aplicación de MS Outlook empieza a fallar. El personal técnico puede referirse a la KEDB para comprobar lo que se ha hecho en ocasiones anteriores, y puede recomendar la solución al cliente hasta que se establezca una solución permanente.
3. Si se identifica y aplica una solución permanente a un error conocido, el incidente no debe volver a ocurrir. Entonces, el registro del error conocido se saca del KEDB o se archiva con un estatus diferente. Esto se hace para asegurar que la base de datos se optimice sólo con los errores conocidos, y que el acceso a los registros no se vuelva engorroso debido a un alto volumen de registros de errores conocidos.
Mientras el usuario accede al servicio de correo electrónico a través del webmail, se está investigando el asunto para identificar que una extensión de Bluetooth está haciendo que la perspectiva se desplome. La solución permanente es deshabilitar la extensión o incluso desinstalarla. Esta solución se implementa no sólo en el Outlook que se ha colgado, sino en todos los sistemas que acceden al Outlook, para asegurar que no vuelva a ocurrir el mismo incidente. Después de implementar y probar la solución permanente, el registro de error conocido puede ser archivado con un estado predefinido o eliminado.
ITIL® es una marca registrada de la Oficina del Gabinete.