Las 5 mejores técnicas y metodologías de RCA para la gestión de problemas de TI

El proceso de gestión de problemas se puede establecer con una buena herramienta de mesa de servicio, pero las técnicas utilizadas para la investigación y el diagnóstico deben variar según la organización. Se recomienda que las técnicas de investigación sean flexibles en función de las necesidades de la organización en lugar de ser demasiado estrictas.

Dado que los problemas pueden tener cualquier forma o tamaño, es imposible apegarse a una sola técnica para encontrar todas las soluciones; se obtendrán mejores resultados si se combinan varias técnicas. Un simple problema de conectividad LAN podría resolverse con una sesión rápida de lluvia de ideas, pero un problema de red o VoIP podría necesitar un análisis más profundo.

Estas son algunas técnicas que puede aplicar en el proceso de gestión de problemas de su organización.

Lluvia de ideas

Al conversar con varios departamentos, puede obtener diversas perspectivas y nueva información, generando muchas soluciones potenciales.

Para tener una sesión de lluvia de ideas productiva, necesita un moderador. El moderador se encarga de lo siguiente:

• Dirigir la reunión
• Documentar la información obtenida
• Destacar las medidas que se van a tomar
• Dar seguimiento al entregable discutido
• Evitar que la sesión se prolongue demasiado

Las sesiones de lluvia de ideas son más productivas cuando se utilizan técnicas colaborativas de resolución de problemas, como el análisis de Ishikawa y el método de los cinco porqués. Estas técnicas se discutirán más adelante en esta sección.

Método Kepner-Tregoe

El método Kepner-Tregoe (K-T) es una técnica de resolución de problemas y toma de decisiones que se utiliza en muchos campos debido a su enfoque paso a paso para resolver un problema de manera lógica. Es ideal para resolver problemas complejos tanto en la gestión de problemas proactiva como reactiva.

El método sigue cuatro procesos:

• Evaluación de la situación: Evaluar y aclarar el escenario
• Análisis del problema: Relacionar la causa con el efecto
• Análisis de decisiones: Sopesar las opciones alternativas
• Análisis de problemas potenciales: Anticipar el futuro

Sin embargo, el análisis de problemas es la única parte que concierne a la gestión de problemas de TI y consta de cinco pasos.

Definir el problema

Identificar cuál es realmente el problema puede ser un problema en sí mismo. Dado que la gestión de problemas es inherentemente un esfuerzo de colaboración, definir el problema de manera exhaustiva elimina las nociones preconcebidas que podría tener algún participante, lo cual ahorra mucho tiempo.

Por ejemplo, si la copia de seguridad automática de datos de una organización en un servidor ha fallado, el problema se puede definir como:

Copia de seguridad fallida en el servidor

Esta definición de hecho describe la situación inusual, pero requiere de más preguntas e información. Un buen modelo de definición debe ser inequívoco y fácil de entender.

Para eliminar la ambigüedad, la definición se puede modificar de la siguiente manera:

La copia de seguridad de datos del 15 de noviembre falló en el servidor #34-C

Esta definición proporciona más claridad y evita que los empleados formulen preguntas redundantes. Sin embargo, esta definición puede mejorarse aún más. Imagine que la causa de la falla de la copia de seguridad de datos se puede atribuir a un evento como la aplicación de un nuevo parche; entonces el análisis inicial del problema indudablemente conduciría a este evento.

Para ahorrar tiempo y esfuerzo, modifique la definición de la siguiente manera:

La copia de seguridad de datos del 15 de noviembre falló en el servidor #34-C después de que el ingeniero Noah aplicara el parche 3.124

Esta definición detallada evita las preguntas redundantes y proporciona una buena cantidad de información sobre dónde podría estar el problema. Estos minutos adicionales dedicados a la definición inicial ahorran tiempo y esfuerzo valiosos, proporcionan un sentido lógico de dirección para el análisis y eliminan cualquier noción preconcebida sobre el problema.

Describir el problema

El siguiente paso es establecer una descripción detallada del problema. El método K-T proporciona las preguntas que se deben formular sobre cualquier problema para ayudar a identificar las posibles causas.

Las siguientes preguntas ayudan a describir cuatro partes de cualquier problema:

• ¿Cuál es el problema?
• ¿Dónde ocurrió el problema?
• ¿Cuándo ocurrió el problema?
• ¿Cuál es el alcance del problema?

Cada una de estas preguntas exige dos tipos de respuestas:

ES: Como en "¿Cuál es el problema?" o "¿Dónde está el problema?"

y

PODRÍA SER pero NO ES: Como en "¿Dónde podría estar el problema pero no está?"

Este ejercicio ayuda a comparar y resaltar el "qué, dónde, cuándo y cómo" de la desviación que está ocurriendo en el rendimiento normal de los procesos comerciales.

Establecer las posibles causas

La comparación entre el rendimiento normal y el rendimiento anormal del paso anterior ayuda a crear una lista de las posibles causas del problema. Hacer una tabla con toda la información en un solo lugar puede ser útil para hacer la comparación.

Las nuevas causas posibles se hacen evidentes cuando la información se analiza en conjunto. Para nuestro problema de ejemplo, la causa raíz se puede reducir a:

Error de procedimiento causado por la transferencia de conocimiento inadecuada por parte de los ingenieros de Nivel 3.

Cualquiera que sea el problema, se puede realizar un análisis detallado de las posibles causas con base en la comparación relevante.

Probar la causa más probable

El penúltimo paso es hacer una pequeña lista de las causas probables y someterlas a prueba antes de sacar una conclusión. Cada causa probable se debe probar con esta pregunta:

Si _______ es la causa raíz de este problema, ¿explica cuál ES el problema y cuál PODRÍA SER el problema pero NO ES?

Nuevamente, es mejor completar toda la información en una tabla.

Comprobar la verdadera causa

El último paso es eliminar todas las causas improbables y buscar evidencia para las causas más probables. Con esta verificación, es hora de proponer una solución al problema. Si no hay evidencia de la posible causa raíz, no se debe intentar implementar la solución.

Análisis de Ishikawa, o análisis de diagrama de causa y efecto

El análisis de Ishikawa utiliza el diagrama de causa y efecto (también llamado "diagrama de espina de pescado") para enumerar la causa y los efectos de un problema y se puede combinar con las sesiones de lluvia de ideas y el método de los cinco porqués. Que no lo engañe la simplicidad del diagrama de Ishikawa al realizar un RCA, ya que resulta muy útil para manejar problemas complejos.

Para comenzar el análisis, defina el problema y úselo como la "cabeza del pescado" en el diagrama. Dibuje la "columna vertebral" y agregue las categorías desde las cuales podría originarse el problema ilustrándolas como las "espinas" del diagrama de pescado.

En general, es más fácil comenzar las categorías con las cuatro dimensiones de la gestión de servicios: socios, procesos, personas y tecnología. Sin embargo, estas categorías pueden ser cualquier cosa que sea relevante para su problema, entorno, organización o industria.

Una vez que estas categorías formen las espinas del pescado, comience a asociar las posibles causas de cada categoría. Cada posible causa también se puede ramificar para detallar la razón de esa ocurrencia. Esto podría convertirse en un diagrama complejo con cuatro a cinco niveles de causas y efectos, que posteriormente se derivan en la causa raíz del problema.

Se recomienda dividir las espinas densas en espinas adicionales según sea necesario. Alternativamente, combinar las espinas vacías con otras espinas relacionadas permite ordenar y comprender mejor el diagrama. Además, debe asegurarse de que las espinas estén llenas de causas, no solo síntomas del problema.

Este análisis también es un esfuerzo de colaboración y requiere un moderador que dirija las sesiones de lluvia de ideas de manera efectiva. Todos los participantes tienen la oportunidad de participar, proporcionando una visión integral del problema.

Análisis de Pareto

El principio de Pareto es una observación que sugiere que aproximadamente el 80 por ciento de los efectos provienen de aproximadamente el 20 por ciento de las causas. Esta observación se aplica a una amplia gama de temas, incluida la gestión de problemas.

Cuando se trata de reducir la cantidad de incidentes que ocurren en una organización, es muy útil aplicar el análisis de Pareto antes de comenzar a resolver los problemas. El análisis de Pareto prioriza las causas de los incidentes y ayuda a gestionar los problemas en función de su impacto y probabilidad.

Este análisis se lleva a cabo generando un diagrama de Pareto a partir de una tabla de Pareto. Una tabla de Pareto consiste en el recuento acumulativo de la clasificación de todos los problemas. Un diagrama de Pareto es un gráfico de barras que muestra el porcentaje acumulativo de la frecuencia de varias clasificaciones de problemas.

Para crear un diagrama de Pareto, siga los pasos que se detallan a continuación:

• Recopile datos de los tickets de problema de su herramienta de mesa de servicio.
• Remodele los datos en categorías basadas en varios atributos.
• Cree una tabla de Pareto para determinar la frecuencia de los problemas en cada clasificación durante un período de tiempo específico.
• Calcule la frecuencia de la ocurrencia de los problemas en cada categoría.
• Genere el porcentaje de frecuencia acumulativo en orden decreciente.
• Grafique los datos en un gráfico de Pareto.

El paso más importante es remodelar los datos en un conjunto contable de clasificaciones y atributos.

Este diagrama ayuda a identificar los problemas que se deben resolver primero para reducir significativamente la interrupción del servicio. Este análisis complementa los métodos de Ishikawa y Kepner-Tregoe al proporcionar una forma de priorizar la categoría de los problemas, mientras que los otros métodos analizan la causa raíz.

Es importante recordar que la regla 80/20 sugiere las causas probables y a veces podría equivocarse.

Técnica de los cinco porqués

La técnica de los cinco porqués es una técnica sencilla para el RCA. Define una declaración del problema, luego pregunta repetidamente por qué hasta que se descubre la causa raíz subyacente del problema. El número de porqués no necesariamente se limita a cinco, sino que puede basarse en el problema y la situación.

La técnica de los cinco porqués complementa muchas otras técnicas de resolución de problemas como el método Ishikawa, el análisis de Pareto y el método K-T.

Retomando el ejemplo de la falla de la copia de seguridad de los datos en un servidor, apliquemos la técnica de los cinco porqués.

Este proceso iterativo revela que no existe un formato estandarizado, lo que ha causado el problema de la falla de la copia de seguridad de datos.

En nuestro contexto, el ejemplo anterior es una ejecución simple del método. En un escenario real, la siguiente pregunta depende de la respuesta a la pregunta anterior, por lo que es imprescindible colaborar con las partes interesadas que tienen un conocimiento detallado del dominio en el que reside el problema.

Al adoptar partes del método K-T junto con la técnica de los cinco porqués, como proporcionar evidencia a cada respuesta antes de validarla con una pregunta de respuesta, puede garantizar la precisión del análisis durante las sesiones de resolución de problemas.

Otras técnicas

Además de las cinco técnicas principales, existen muchas otras, cada una con sus propias fortalezas. En general, la investigación del problema se lleva a cabo utilizando una combinación de técnicas adecuadas para la situación. Algunas otras técnicas que se usan con frecuencia en la comunidad de gestión de problemas son las pruebas cronológicas, el análisis del árbol de fallas, el método de aislamiento de fallas, las pruebas de hipótesis y el análisis de puntos débiles. Vale la pena tomarse el tiempo para aprender muchas técnicas a medida que madura el proceso de gestión de problemas de su organización.