Pensar en los problemas: Kepner-Tregoe

Se describen los pasos del método de análisis de causa raíz de Kepner-Tregoe - Definir y describir el problema, establecer las posibles causas, prueba de la causa más probable, y verificar la verdadera causa.

Tan simple como suena, la mayoría de los técnicos y técnicas no siguen actualmente las ideas de Kepner-Tregoe. Se basan en cambio en las ideas preconcebidas y muchas veces saltan pasos importantes. Entonces, sin un plan y en su desesperación caen en la vieja técnica "en caso de duda mejor es intercambiar"

Tomarse el tiempo para el uso de Kepner-Tregoe puede dar lugar a importantes mejoras en la solución de problemas, y ofrecer soluciones permanentes para prevenir problemas futuros.

Siguiendo con esto se proporcionará una plantilla para el uso de las ideas de Kepner-Tregoe para que los gerentes y el personal pueden utilizar para acelerar el análisis de causa raíz como vía hacia la solución de los problemas.

Se proporciona un proceso para identificar y ordenar todas las cuestiones relativas a una decisión. Como una herramienta de solución de problemas, análisis de problemas ayuda a evitar sacar conclusiones precipitadas.

Solucionadores de problemas inmaduros usan corazonadas, el instinto y la intuición. Estos actos individuales de heroísmo pueden parecer brillantes, pero también pueden dar lugar a más problemas, ya que saltar a conclusiones a menudo amplía o combina los problemas en lugar de resolverlos.

El proceso de análisis de problemas de toma de decisiones se divide en cinco pasos:

1. Definir el problema2. Describa el problema3. Establecer las posibles causas4. Prueba de la causa más probable5. Compruebe la verdadera causa

Definición del Problema

Análisis del problema comienza con la definición del problema. El equipo de administración de problemas no puede pasar por alto este paso crítico. El no entender exactamente cuál es el problema a menudo resulta en pérdida de tiempo precioso. Muchos solucionadores de problemas inmaduros considerar este paso como un esfuerzo inútil, ya que saben lo que van a hacer - y este es el error crítico

hecho por muchos. Nociones preconcebidas a menudo resultan en aumento de duración de los apagones e incluso la expansión de interrupciones debido a la falta de juicio.

Desde la administración de problemas es inherente el ejercicio de equipo, es importante tener un grupo que entienda el problema. Considere los siguientes ejemplos. Una mala definición del problema podría aparecer como sigue:

"El servidor se falló"

Una mejor definición del problema debe incluir más información. Un buen modelo para la aclaración de las declaraciones de todos los tipos es el método de la Meta Pregunta Indicador (Goal Question Metric GQM). El resultado es una declaración con un objeto claro, el objetivo, enfoque, Medio Ambiente, y un Punto de vista. Esto da lugar a una declaración inequívoca y fácil de entender. Una definición del problema claro podría ser:

"El sistema de correo falló después del tercer turno el ingeniero de soporte aplicó una corrección urgente XYZ al servidor de intercambio 123"

Cuando desarrolle la definición de un problema utilice siempre la técnica de las cinco S para llegar al punto en que no hay una explicación para el problema. Con 5 porqués de Kepner-Tregoe sólo acelera el proceso.

Describir el problema

Con una clara definición del problema, el siguiente paso es describir el problema en detalle. El siguiente cuadro proporciona una buena plantilla para esta actividad. Usted puede hacer esto utilizando una tarjeta de presentación, papel, o software de común oficina. La Tabla 1 describe la hoja de cálculo básico que se utiliza en el proceso.

En la hoja de trabajo se describen los cuatro aspectos de un problema: qué es, dónde ocurre, cuándo ocurrió, y la medida en que se produjo. La columna ES proporciona espacio para describir detalles sobre el problema - ¿qué ES el problema?. La columna PUEDE SER pero NO ES provee el espacio para listar los detalles o especificaciones relacionadas pero excluidas - lo que el problema PODRÍA SER, pero NO ES. Estas dos columnas ayudan en la eliminación "intuitiva pero incorrecta" de suposiciones sobre el problema. Con las columnas uno y dos completadas, la tercera columna proporciona el espacio para detallar las diferencias entre el ES y el PODRÍA SER pero NO ES. La última columna proporciona espacio para enumerar los cambios realizados que podrían explicar las diferencias.

LO QUE ES

PODRÍA SER pero NO ES

DIFERENCIAS

CAMBIOS

¿QUÉ?(La identidad que

falla)

Fallo del Sistema

Sistemas similares/ o situaciones que

no han fallado? ?

¿DÓNDE?(El lugar donde

ocurre)

Fallo en la ubicación

Otras localidades que no fallaron

? ?

¿CUÁNDO?(Su ubicación en el

tiempo)

Tiempo de fallo

Otros veces en las que no se

produjeron fallos? ?

¿Cuánto? MEDIDA

(La magnitud o tamaño)

Otros sistemas fallando

Otros sistemas sin fallo

? ?

Tabla 1. Análisis de problemas Hoja Explicación

Establezca las posibles causas

Alguien que haya pasado un tiempo solucionando problemas sabe ver "Que ha cambiado desde que este estaba trabajando" y empezar a solucionar problemas mediante el control de cambios. El problema es que muchos cambios pueden ocurrir, y esto complica las cosas. El Análisis de problemas puede ayudar aquí describiendo que es el problema y cuál problema podría ser, pero no lo es. Por ejemplo:

Problema: El sistema de correo falló después del tercer turno el ingeniero de soporte aplicó un parche (hotfix) XYZ al Servidor de intercambio 123

ESPODRÍA

SER pero NO ES

DIFERENCIAS CAMBIOS

QUÉ

El servidor de intercambio cayó al aplicar la corrección urgente (parche hotfix) XYZ

Otro Servidor de intercambio obteniendo corrección urgente (parche hotfix) XYZ

Personal diferente (tercer turno) aplicando este parche (hotfix)

Nuevo procedimiento de parche del proveedor.

DÓNDE Tercer piso de la sala de producción sin proveedor/ contratista de soporte y

En cualquier otro lugar con el proveedor o contratista de soporte y apoyo.

Normalmente se hace por el proveedor

Nuevo procedimiento, primera vez el tercer turno aplica corrección urgente (parche hotfix).

apoyo.

CUÁNDO

Ayer por la noche, 1:35 am

En cualquier otro momento o lugar.

Ninguno tomó nota.

MEDIDA

Cualquier servidor de intercambio en el tercer piso

Otros servidores

Tabla 2. Análisis de problemas Hoja de Ejemplo

La historia (y mejores prácticas) dice que la causa raíz del problema se debe probablemente a un cambio reciente.

Con la hoja de trabajo completa, algunas posibles nuevas soluciones llegan a ser evidentes. Arriba se muestra como llegar a ser claro que la causa raíz es probablemente de procedimiento y debido a que el proveedor no aplique el parche (Hotfix) sino que dio el procedimiento para el parche (Hotfix) a la compañía.

Prueba de la causa más probable

Con una corta lista de posibles causas (cambios recientes evaluados que se convirtieron en una lista), el siguiente paso es pensar a través de cada posible problema. Las siguientes ayudas pueden ayudar en este proceso. Haga la pregunta:

"Si _____ es la causa raíz de este problema lo explica el problema ES y cuál es el problema que PODRÍA SER, pero NO LO ES?"

Si esta solución potencial es la causa de la raíz entonces la posible solución tiene que "mapear" o "encajar " todos los aspectos de la hoja de cálculo de análisis de problemas (figura 2). Utilice una hoja de cálculo como la mostrada en la figura 3 para ayudar a organizar su pensamiento en torno a las posibles soluciones.

Potencial Causa Raíz Verdad Si:Causa Raíz Probable?

Servidor de Intercambio 123 tiene algo de malo en este

Sólo el Servidor de Intercambio tiene el problema

Puede ser

Procedimiento IncorrectoEl mismo procedimiento

bloquea otro servidorProbablemente

Error técnicoEl problema no vuelve a

ocurrir siempreProbablemente

noTabla 3. Aclaración de Análisis de Problemas

Verify the True Cause

The next step is to compare the possible root causes (Table 3) against

the problem description (Table 2). Eliminate possible solutions that

cannot explain the situation, and focus on the remaining items.

Before making any changes, verify that the proposed solution could be

the root cause. Failure to verify the true cause invalidates the entire

exercise and is no better than guessing. After verifying the true cause,

you can propose the action required repair the problem.

It is important here as well to think about how to prevent similar

problems from occurring in the future. The Problem Manager should

consider how the issue arose in the first place by asking some questions:

Where else might this problem appear?

Are there other occurrences of this problem in the past?

Do any procedures need to change?

The goal is to try to eliminate future occurrences of the problem.

Summary

Kepner-Tregoe is a mature process with decades of proven capabilities.

There are worksheets, training programs, and consulting firms all

schooled in the process. You can take courses at many local colleges as

well.

Kepner-Tregoe Problem Analysis was used by NASA to troubleshoot

Apollo XIII – even though the technicians did not believe the results, they

followed the process and saved the mission. The rest of the story, as

they say, is history...

Even without a lot of time available, using Kepner-Tregoe Problem

Analysis can result in the most efficient problem resolutions. Armed with

tools like 5 Whys and Ishikawa diagramming, a Problem Manager can

capture the combined experience and knowledge of a team. When used

with Kepner-Tregoe Problem Analysis the result is amazing.

SOLUCIÓN RACIONALDE PROBLEMAS.Identificar el problema.Analizar el problemapara encontrar las causas:Un problema es unadesviación de un estándarde actuación.Esta desviación debe serlocalizada y descrita conprecisión.Siempre hay algo quedistingue lo que ha sidoafectado por la causa.La causa de un problemaes siempre un cambiopara producir un efectonuevo e indeseado.Las posibles causas deuna desviación se deducende esos cambiosrelevantes.La causa más probablede una desviación esaquella que explica exactamentetodos loshechos en la especificacióndel problema.