La resolución de problemas es una forma de resolución de problemas , que a menudo se aplica para reparar productos o procesos fallidos en una máquina o sistema. Es una búsqueda lógica y sistemática del origen de un problema para solucionarlo y volver a poner operativo el producto o proceso. Es necesario solucionar problemas para identificar los síntomas. Determinar la causa más probable es un proceso de eliminación : eliminar las causas potenciales de un problema. Finalmente, la resolución de problemas requiere confirmación de que la solución restablece el producto o proceso a su estado de funcionamiento.
En general, la resolución de problemas es la identificación o diagnóstico de "problemas" en el flujo de gestión de un sistema causado por una falla de algún tipo. El problema se describe inicialmente como síntomas de mal funcionamiento y la resolución de problemas es el proceso de determinar y remediar las causas de estos síntomas.
Un sistema puede describirse en términos de su comportamiento esperado, deseado o previsto (normalmente, en el caso de los sistemas artificiales, su propósito). Se espera que los eventos o entradas al sistema generen resultados o salidas específicos. (Por ejemplo, seleccionar la opción "imprimir" desde varias aplicaciones informáticas tiene como objetivo dar como resultado una copia impresa de algún dispositivo específico). Cualquier comportamiento inesperado o indeseable es un síntoma. La resolución de problemas es el proceso de aislar la causa o causas específicas del síntoma. Con frecuencia, el síntoma es una falla del producto o proceso para producir algún resultado. (No se imprimió nada, por ejemplo). Luego se pueden tomar medidas correctivas para evitar más fallas de tipo similar.
Los métodos de ingeniería forense son útiles para rastrear problemas en productos o procesos, y está disponible una amplia gama de técnicas analíticas para determinar la causa o causas de fallas específicas . Luego se pueden tomar medidas correctivas para evitar futuras fallas de tipo similar. La acción preventiva es posible utilizando el modo y efectos de falla (FMEA) y el análisis de árbol de fallas (FTA) antes de la producción a gran escala, y estos métodos también se pueden usar para el análisis de fallas .
Hay dos elementos principales necesarios para permitir que se lleve a cabo un diagnóstico de resolución de problemas: el conocimiento del dominio a priori y las estrategias de búsqueda. [1] Estos son interdependientes, y aquí es donde podemos identificar fundamentalmente dos tipos diferentes de problemas, con enfoques coincidentes para su diagnóstico. Rasmussen [2] sugirió que existe una estrategia guiada por las características del correcto funcionamiento del dispositivo (estrategia topográfica) y una estrategia guiada por las características del funcionamiento anormal (estrategia sintomática). El segundo es realmente preguntar "¿qué pasa?" el primero es preguntar "¿qué está pasando?"
Una estrategia es un conjunto organizado de actividades que expresan una forma plausible de lograr una meta. Las estrategias no deben verse como algoritmos, seguidos inflexiblemente para encontrar soluciones. Los solucionadores de problemas se comportan de manera oportunista, ajustando actividades dentro de una estrategia y cambiando estrategias y tácticas en respuesta a información e ideas. [3]
Una estrategia sintomática (también conocida como razonamiento basado en casos o razonamiento superficial) requiere conocimiento de dominio a priori que se obtiene de experiencias pasadas que establecieron conexiones entre síntomas y causas. Este conocimiento se denomina conocimiento superficial, compilado, probatorio, basado en la historia y basado en casos. Esta es la estrategia más asociada al diagnóstico por los expertos. El diagnóstico de un problema se produce como un proceso rápido de reconocimiento en el que los síntomas evocan categorías de situación apropiadas. [4] Un experto conoce la causa en virtud de haber encontrado previamente casos similares. El razonamiento basado en casos es la estrategia más poderosa y la que se utiliza con mayor frecuencia. Sin embargo, la estrategia no funcionará de forma independiente con problemas verdaderamente novedosos o cuando se busque una comprensión más profunda de lo que está sucediendo. Una estrategia topográfica cae en la categoría de razonamiento profundo. Con el razonamiento profundo se utiliza un conocimiento profundo de un sistema. Topografía en este contexto significa una descripción o un análisis de una entidad estructurada, que muestra las relaciones entre sus elementos. [5] También conocido como razonamiento a partir de primeros principios, [6] el razonamiento profundo se aplica a fallas nuevas cuando los enfoques basados en la experiencia no son viables. Por lo tanto, la estrategia topográfica está vinculada al conocimiento de dominio a priori que se desarrolla a partir de una comprensión más fundamental de un sistema, posiblemente utilizando conocimientos de primeros principios. Este tipo de conocimiento se denomina conocimiento profundo, causal o basado en modelos. [7]
Hoc [8] señaló que los enfoques sintomáticos pueden necesitar estar respaldados por enfoques topográficos porque los síntomas pueden definirse en diversos términos. Lo contrario también es cierto: el razonamiento superficial se puede utilizar de manera abductiva para generar hipótesis causales y deductivamente para evaluar esas hipótesis en una búsqueda topográfica.
Por lo general, la solución de problemas se aplica a algo que repentinamente dejó de funcionar, ya que su estado de funcionamiento anterior forma las expectativas sobre su comportamiento continuo. De modo que la atención inicial suele centrarse en los cambios recientes del sistema o del entorno en el que existe. (Por ejemplo, una impresora que "estaba funcionando cuando estaba enchufada por allí"). Sin embargo, existe un principio bien conocido de que correlación no implica causalidad . (Por ejemplo, la falla de un dispositivo poco después de haber sido enchufado a un tomacorriente diferente no significa necesariamente que los eventos estuvieran relacionados. La falla podría haber sido una cuestión de coincidencia ). Por lo tanto, la resolución de problemas exige pensamiento crítico en lugar de magia. pensamiento .
Es útil considerar las experiencias comunes que tenemos con las bombillas. Las bombillas se "funden" más o menos al azar; eventualmente, el calentamiento y enfriamiento repetidos de su filamento y las fluctuaciones en la energía que se le suministra hacen que el filamento se agriete o se vaporice. El mismo principio se aplica a la mayoría de los demás dispositivos electrónicos y principios similares se aplican a los dispositivos mecánicos. Algunas fallas son parte del desgaste normal de los componentes de un sistema.
El primer principio básico en la resolución de problemas es poder reproducir el problema cuando se desee. El segundo principio básico en la resolución de problemas es reducir el "sistema" a su forma más simple que aún muestre el problema. El tercer principio básico en la resolución de problemas es "saber lo que está buscando". En otras palabras, comprender completamente la forma en que se supone que funciona el sistema, para poder "detectar" el error cuando ocurra.
Un solucionador de problemas podría verificar cada componente de un sistema uno por uno, sustituyendo los componentes en buen estado por cada uno potencialmente sospechoso. Sin embargo, este proceso de "sustitución en serie" puede considerarse degenerado cuando los componentes se sustituyen sin tener en cuenta una hipótesis sobre cómo su falla podría resultar en el diagnóstico de los síntomas.
Los sistemas simples e intermedios se caracterizan por listas o árboles de dependencias entre sus componentes o subsistemas. Los sistemas más complejos contienen dependencias o interacciones cíclicas ( bucles de retroalimentación ). Estos sistemas son menos susceptibles a las técnicas de resolución de problemas de "bisección".
También ayuda comenzar desde un buen estado conocido, siendo el mejor ejemplo un reinicio de la computadora . También es bueno probar un recorrido cognitivo . La documentación completa producida por escritores técnicos competentes es muy útil, especialmente si proporciona una teoría de funcionamiento para el dispositivo o sistema en cuestión.
Una causa común de problemas es el mal diseño , por ejemplo, el mal diseño de factores humanos , donde un dispositivo podría insertarse al revés o al revés debido a la falta de una función de fuerza adecuada ( restricción de configuración del comportamiento ) o a la falta de un diseño tolerante a errores. . Esto es especialmente malo si va acompañado de habituación , donde el usuario simplemente no nota el uso incorrecto, por ejemplo si dos piezas tienen funciones diferentes pero comparten un caso común de modo que no es evidente en una inspección casual qué pieza se está utilizando.
La solución de problemas también puede tomar la forma de una lista de verificación sistemática , un procedimiento de solución de problemas, un diagrama de flujo o una tabla que se elabora antes de que ocurra un problema. Desarrollar procedimientos de solución de problemas con anticipación permite pensar lo suficiente sobre los pasos a seguir para solucionar problemas y organizar la solución de problemas en el proceso de solución de problemas más eficiente. Las tablas de resolución de problemas pueden computarizarse para hacerlas más eficientes para los usuarios.
Algunos servicios computarizados de resolución de problemas (como Primefax, más tarde rebautizado como MaxServ), muestran inmediatamente las 10 soluciones principales con la mayor probabilidad de solucionar el problema subyacente. El técnico puede responder preguntas adicionales para avanzar en el procedimiento de solución de problemas, reduciendo cada paso la lista de soluciones, o implementar inmediatamente la solución que crea que solucionará el problema. Estos servicios ofrecen un reembolso si el técnico da un paso adicional después de resolver el problema: informar la solución que realmente solucionó el problema. La computadora utiliza estos informes para actualizar sus estimaciones sobre qué soluciones tienen la mayor probabilidad de solucionar ese conjunto particular de síntomas. [9] [10]
La resolución de problemas metódica y eficiente comienza con una comprensión clara del comportamiento esperado del sistema y los síntomas que se observan. A partir de ahí, el solucionador de problemas formula hipótesis sobre las posibles causas y diseña (o quizás hace referencia a una lista de verificación estandarizada) pruebas para eliminar estas posibles causas. Este enfoque suele denominarse " divide y vencerás ".
Dos estrategias comunes utilizadas por los solucionadores de problemas son verificar primero las condiciones que se encuentran con frecuencia o que son fáciles de probar (por ejemplo, verificar que la luz de una impresora esté encendida y que su cable esté firmemente asentado en ambos extremos). A esto se le suele denominar "ordeñar el panel frontal". [11]
Luego, "divide" el sistema (por ejemplo, en un sistema de impresión en red, verificando si el trabajo llegó al servidor para determinar si existe un problema en los subsistemas "hacia" el extremo del usuario o "hacia" el dispositivo).
Esta última técnica puede ser particularmente eficiente en sistemas con largas cadenas de dependencias serializadas o interacciones entre sus componentes. Es simplemente la aplicación de una búsqueda binaria en toda la gama de dependencias y, a menudo, se la denomina "media división". [12] Es similar al juego de las " veinte preguntas ": cualquiera puede aislar una opción entre un millón dividiendo el conjunto de alternativas por la mitad 20 veces (porque 2^10 = 1024 y 2^20 = 1.048.576).
Uno de los principios básicos de la resolución de problemas es que los problemas reproducibles se pueden aislar y resolver de manera confiable. A menudo, se pone un esfuerzo y énfasis considerables en la resolución de problemas en la reproducibilidad... en encontrar un procedimiento para inducir de manera confiable la aparición del síntoma.
Algunos de los problemas más difíciles de solucionar se relacionan con síntomas que ocurren de manera intermitente . En electrónica, esto suele ser el resultado de componentes que son térmicamente sensibles (ya que la resistencia de un circuito varía con la temperatura de los conductores que contiene). Se puede usar aire comprimido para enfriar puntos específicos de una placa de circuito y se puede usar una pistola de calor para elevar las temperaturas; por lo tanto, la resolución de problemas de sistemas electrónicos frecuentemente implica la aplicación de estas herramientas para reproducir un problema.
En la programación informática, las condiciones de carrera a menudo provocan síntomas intermitentes que son extremadamente difíciles de reproducir; Se pueden usar varias técnicas para forzar que la función o módulo en particular se llame más rápidamente de lo que sería en funcionamiento normal (análogo a "calentar" un componente en un circuito de hardware), mientras que se pueden usar otras técnicas para introducir mayores retrasos. o forzar la sincronización entre otros módulos o procesos que interactúan.
Los problemas intermitentes se pueden definir así:
Un intermitente es un problema para el cual no existe un procedimiento conocido para reproducir consistentemente su síntoma.
—Steven Litt, [13]
En particular, afirma que existe una distinción entre la frecuencia de ocurrencia y un "procedimiento conocido para reproducir consistentemente" un problema. Por ejemplo, saber que un problema intermitente ocurre "dentro" de una hora de un estímulo o evento particular... pero que a veces ocurre en cinco minutos y otras veces tarda casi una hora... no constituye un "procedimiento conocido" incluso si el estímulo aumenta la frecuencia de las manifestaciones observables del síntoma.
Sin embargo, a veces los solucionadores de problemas deben recurrir a métodos estadísticos... y sólo pueden encontrar procedimientos para aumentar la aparición del síntoma hasta un punto en el que la sustitución en serie o alguna otra técnica sea factible. En tales casos, incluso cuando el síntoma parece desaparecer durante períodos significativamente más largos, hay poca confianza en que se haya encontrado la causa raíz y que el problema esté realmente resuelto.
Además, se pueden ejecutar pruebas para estresar ciertos componentes para determinar si esos componentes han fallado. [14]
Aislar fallas de un solo componente que causan síntomas reproducibles es relativamente sencillo.
Sin embargo, muchos problemas sólo ocurren como resultado de múltiples fallas o errores. Esto es particularmente cierto en el caso de los sistemas tolerantes a fallas o aquellos con redundancia incorporada. Las características que agregan redundancia, detección de fallas y conmutación por error a un sistema también pueden estar sujetas a fallas, y suficientes fallas de componentes diferentes en cualquier sistema lo "derribarán".
Incluso en sistemas simples, el solucionador de problemas siempre debe considerar la posibilidad de que exista más de una falla. (Reemplazar cada componente, utilizar la sustitución en serie y luego cambiar cada componente nuevo por el antiguo cuando se descubre que el síntoma persiste, puede no resolver estos casos. Más importante aún, el reemplazo de cualquier componente por uno defectuoso puede en realidad aumentar el número de problemas en lugar de eliminarlos).
Tenga en cuenta que, si bien hablamos de "reemplazar componentes", la resolución de muchos problemas implica ajustes o afinaciones en lugar de "reemplazo". Por ejemplo, es posible que simplemente sea necesario limpiar y/o apretar las roturas intermitentes en los conductores o los "contactos sucios o sueltos". Toda discusión sobre "reemplazo" debe entenderse como "reemplazo o ajuste u otra modificación".