Pensar en los problemas: Kepner-Tregoe Se describen los pasos del mtodo de anlisis de causa raz de Kepner-Tregoe Definir y describir

el problema, establecer las posibles causas, prueba de la causa ms probable, y verificar la verdadera causa. Tan simple como suena, la mayora de los tcnicos y tcnicas 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 desesperacin caen en la vieja tcnica "en caso de duda mejor es intercambiar" Tomarse el tiempo para el uso de Kepner-Tregoe puede dar lugar a importantes mejoras en la solucin 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 anlisis de causa raz como va hacia la solucin de los problemas. Se proporciona un proceso para identificar y ordenar todas las cuestiones relativas a una decisin. Como una herramienta de solucin de problemas, anlisis de problemas ayuda a evitar sacar conclusiones precipitadas. Solucionadores de problemas inmaduros usan corazonadas, el instinto y la intuicin. Estos actos individuales de herosmo pueden parecer brillantes, pero tambin pueden dar lugar a ms problemas, ya que saltar a conclusiones a menudo ampla o combina los problemas en lugar de resolverlos. El proceso de anlisis de problemas de toma de decisiones se divide en cinco pasos: 1. 2. 3. 4. 5. Definir el problema Describa el problema Establecer las posibles causas Prueba de la causa ms probable Compruebe la verdadera causa

Definicin del Problema

Anlisis del problema comienza con la definicin del problema. El equipo de administracin de problemas no puede pasar por alto este paso crtico. El no entender exactamente cul es el problema a menudo resulta en prdida de tiempo precioso. Muchos solucionadores de problemas inmaduros considerar este paso como un esfuerzo intil, ya que saben lo que van a hacer - y este es el error crtico

hecho por muchos. Nociones preconcebidas a menudo resultan en aumento de duracin de los apagones e incluso la expansin de interrupciones debido a la falta de juicio. Desde la administracin de problemas es inherente el ejercicio de equipo, es importante tener un grupo que entienda el problema. Considere los siguientes ejemplos. Una mala definicin del problema podra aparecer como sigue: "El servidor se fall" Una mejor definicin del problema debe incluir ms informacin. Un buen modelo para la aclaracin de las declaraciones de todos los tipos es el mtodo de la Meta Pregunta Indicador (Goal Question Metric GQM). El resultado es una declaracin con un objeto claro, el objetivo, enfoque, Medio Ambiente, y un Punto de vista. Esto da lugar a una declaracin inequvoca y fcil de entender. Una definicin del problema claro podra ser: "El sistema de correo fall despus del tercer turno el ingeniero de soporte aplic una correccin urgente XYZ al servidor de intercambio 123" Cuando desarrolle la definicin de un problema utilice siempre la tcnica de las cinco S para llegar al punto en que no hay una explicacin para el problema. Con 5 porqus de Kepner-Tregoe slo acelera el proceso.

Describir el problema
Con una clara definicin 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 presentacin, papel, o software de comn oficina. La Tabla 1 describe la hoja de clculo bsico que se utiliza en el proceso. En la hoja de trabajo se describen los cuatro aspectos de un problema: qu es, dnde ocurre, cundo 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 PODRA SER, pero NO ES. Estas dos columnas ayudan en la eliminacin "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 PODRA SER pero NO ES. La ltima columna proporciona espacio para enumerar los cambios realizados que podran explicar las diferencias.

LO QUE ES QU?
(La identidad que falla)

Fallo del Sistema Fallo en la ubicacin Tiempo de fallo

DNDE?
(El lugar donde ocurre)

CUNDO?
(Su ubicacin en el tiempo)

PODRA SER pero NO ES Sistemas similares/ o situaciones que no han fallado Otras localidades que no fallaron Otros veces en las que no se produjeron fallos

DIFERENCIAS CAMBIOS ? ? ? ? ? ?

Cunto? MEDIDA
(La magnitud o tamao)

Otros Otros sistemas sin sistemas ? fallo fallando Tabla 1. Anlisis de problemas Hoja Explicacin

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 Anlisis de problemas puede ayudar aqu describiendo que es el problema y cul problema podra ser, pero no lo es. Por ejemplo: Problema: El sistema de correo fall despus del tercer turno el ingeniero de soporte aplic un parche (hotfix) XYZ al Servidor de intercambio 123 ES El servidor de intercambio cay al aplicar la correccin urgente (parche hotfix) XYZ Tercer piso de la sala de produccin sin proveedor/ contratista de soporte y apoyo. PODRA SER pero NO ES Otro Servidor de intercambio obteniendo correccin urgente (parche hotfix) XYZ En cualquier otro lugar con el proveedor o contratista de soporte y apoyo. En cualquier DIFERENCIAS CAMBIOS

QU

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

Nuevo procedimiento de parche del proveedor.

DNDE

Normalmente se hace por el proveedor

Nuevo procedimiento, primera vez el tercer turno aplica correccin urgente (parche hotfix).

CUNDO Ayer por la

Ninguno tom

MEDIDA

noche, 1:35 otro momento nota. am o lugar. Cualquier servidor de Otros intercambio servidores en el tercer piso Tabla 2. Anlisis de problemas Hoja de Ejemplo

La historia (y mejores prcticas) dice que la causa raz 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 raz 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 compaa.

Prueba de la causa ms probable

Con una corta lista de posibles causas (cambios recientes evaluados que se convirtieron en una lista), el siguiente paso es pensar a travs de cada posible problema. Las siguientes ayudas pueden ayudar en este proceso. Haga la pregunta: "Si _____ es la causa raz de este problema lo explica el problema ES y cul es el problema que PODRA SER, pero NO LO ES?" Si esta solucin potencial es la causa de la raz entonces la posible solucin tiene que "mapear" o "encajar " todos los aspectos de la hoja de clculo de anlisis de problemas (figura 2). Utilice una hoja de clculo como la mostrada en la figura 3 para ayudar a organizar su pensamiento en torno a las posibles soluciones. Potencial Causa Raz Servidor de Intercambio 123 tiene algo de malo en este Verdad Si: Causa Raz Probable?

Slo el Servidor de Intercambio tiene el Puede ser problema El mismo procedimiento Procedimiento Incorrecto Probablemente bloquea otro servidor El problema no vuelve a Probablemente Error tcnico ocurrir siempre no Tabla 3. Aclaracin de Anlisis 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.
SOLUCIN RACIONAL DE PROBLEMAS. Identificar el problema. Analizar el problema para encontrar las causas: Un problema es una desviacin de un estndar de actuacin. Esta desviacin debe ser localizada y descrita con precisin. Siempre hay algo que distingue lo que ha sido afectado por la causa. La causa de un problema es siempre un cambio para producir un efecto nuevo e indeseado. Las posibles causas de una desviacin se deducen de esos cambios relevantes. La causa ms probable de una desviacin es aquella que explica exactamente todos los hechos en la especificacin del problema.