ANALISIS DE DESICIONES
Enviado por villafer • 13 de Febrero de 2012 • 6.784 Palabras (28 Páginas) • 636 Visitas
6 La Metodología de Kepner Tregoe
El nombre real es Resolución de Problemas y Toma de Decisiones Kepner Tregoe. El Análisis de Problemas ayuda al profesional de la administración a hacer decisiones racionales sólidas. Proporciona un proceso para identificar y ordenar todas las cuestiones en torno a una decisión. Como herramienta de solución de problemas, el Análisis de Problemas ayuda a prevenir el saltar a conclusiones.
Administradores inmaduros hacen uso de corazonadas, instinto e intuición. Estos actos individuales de heroísmo pueden parecer brillantes, pero también pueden dar lugar a más problemas, ya que llegar a conclusiones a menudo complica o extiende los problemas en lugar de resolverlos.
El Análisis de Problemas nivela la influencia combinada de los conocimientos, la experiencia, la intuición, y el juicio de un equipo, resultando en más rápidas y mejores decisiones. Usando el Análisis de Problemas para ayudar en el manejo de los problemas no solo ayuda a unir el equipo de trabajo, sino que ayuda a identificar la causa real del mismo.
El Análisis de Problemas es una estructura de trabajo para analizar problemas y tomar decisiones.
El proceso de Análisis de Problemas se divide en cinco pasos:
a) Definir el Problema
b) Describir el Problema
c) Establecer las posibles causas
d) Prueba de la causa más probable
e) Verificar la verdadera causa
a) Definición del Problema
El Análisis de Problemas comienza con la definición del problema. El equipo de administración del problema no puede pasar por alto este paso crítico. El hecho de no comprender exactamente el problema a menudo da lugar a perder valioso tiempo. Muchos solucionadores de problemas inexpertos consideran este paso como esfuerzo inútil, ya que creen que saben lo que van a hacer, y este es el error fundamental cometido por muchos. Ideas preconcebidas a menudo dan lugar a un aumento de la duración del proceso e incluso limitan el resultado debido a la mala definición.
Dado que la administración de problemas es por sí mismo un ejercicio de equipo, es importante contar con un grupo que entienda bien el problema. Considere los siguientes ejemplos. Una mala definición del problema podría aparecer de la siguiente manera:
"El servidor se tronó".
Una mejor definición del problema debería incluir más información
"El sistema de correo electrónico falló después de que el ingeniero de soporte del 3er turno actualizó el programa de aplicación de correo electrónico."
b) Describiendo el problema
Con una clara definición del problema, el siguiente paso es describir el problema en detalle. En el siguiente gráfico se observa una plantilla para esta actividad. En la Tabla 1 se describe la hoja de trabajo básica utilizada en el proceso.
La hoja de trabajo describe los cuatro aspectos de un problema: lo que es, donde se produce, cuando ocurrió, y la medida en que se haya producido. La columna ES proporciona espacio para describir detalles sobre el problema -- lo que el problema ES. El cuadro PODRÍA SER pero NO ES proporciona espacio para anotar lo que está relacionado y podría ser, pero se ha excluido, -- lo que PODRÍA SER, pero NO ES. Estas dos columnas ayudan en la eliminación de suposiciones "intuitivas pero incorrectas" sobre el problema. Con las columnas uno y dos completas, la tercera columna proporciona espacio para detallar las diferencias entre la de ES y la de PODRÍA SER pero NO ES. Estas diferencias constituyen la base de la solución de problemas. La última columna proporciona espacio para incluir una lista de los cambios realizados que podrían explicar las diferencias.
ES PODRIA SER pero NO ES DIFERENCIAS CAMBIOS
QUE Falla en el Sistema Sistemas/situaciones similares sin fallas ? ?
DONDE Localización de la falla Otros lugares donde no hubo fallas ? ?
CUANDO Hora de la falla Otras horas donde no ocurrieron fallas ? ?
EXTENSION Falla en otros sistemas Otros sistemas sin fallas ? ?
Tabla 1. Hoja de trabajo de Análisis de Problemas
c) Establecer las posibles causas
Cualquier persona que ha dedicado tiempo a la solución de problemas para ver sabe "lo que ha cambiado desde que empezó", y empezar a resolver problemas mediante la comprobación de los cambios. El problema es que muchos cambios pueden ocurrir, y eso complica las cosas. El Análisis de Problemas puede ayudar aquí describiendo cuál es el problema y lo que el problema podría ser, pero no lo es. Por ejemplo:
Problema: "El sistema de correo electrónico falló después de que el ingeniero de soporte del 3er turno actualizó el programa de aplicación de correo electrónico".
ES PODRIA SER pero NO ES DIFERENCIAS CAMBIOS
QUE Sistema de correo electrónico falló después de que el ingeniero de soporte del 3er turno actualizó el programa de aplicación de correo electrónico Otros sistemas de correo electrónico con el programa actualizado Diferente personal realizó la actualización del sistema Discos de actualización de cada ingeniero
DONDE Edificio C Edificios A y B Sólo tienen apoyo de ingeniero de soporte en 1er turno Sólo un juego de discos en edificios A y B
CUANDO 1:35 hrs 20/11/2007 Cuando se tenga que hacer actualización del sistema No se ha percibido ninguna
EXTENSION Todas las cuentas de correo del Edificio C Cuentas de correo no principales Sólo en cuentas de correo del dominio de la empresa
Tabla 2. Hoja de trabajo de Análisis de Problemas
La experiencia (y las mejores prácticas) dice que la causa fundamental de los problemas es probablemente a alguno de los recientes cambios.
Con la hoja de trabajo concluida, algunas de las nuevas posibles soluciones se han puesto de manifiesto. En la hoja de trabajo se muestra que alguna de las causas principales son los discos de actualización diferentes que cada ingeniero utiliza.
d) Prueba de la causa más probable
Con una breve lista de posibles causas (cambios recientes evaluados y enlistados), el siguiente paso es pensar a través de cada posible problema. Las siguientes ayudas pueden ayudar en este proceso. Hacer la pregunta:
"Si ____ es la causa fundamental de este problema, explica lo que el problema ES y lo que el problema PODRIA SER, pero NO ES?"
Si esta posible solución es la causa fundamental entonces la posible solución ha de "encajar"
...