La Sentencia de problema

La resolución de problemas siempre comienza con una sentencia de problema bien escrita. Siempre. Desea eliminar cualquier confusión y ambigüedad sobre el problema al que se enfrenta describiendo con detalle exactamente lo que ocurrió.

Esto mantiene a su equipo enfocado precisamente en su problema. También ayudará a sus equipos a resolver de manera consistente las preocupaciones dentro de su organización y mantener a raya al temido «scope creep».

La declaración del problema nunca debe detallar la causa del problema en cuestión. Después de todo, si conocieras la causa, no necesitarías crear esta declaración. No necesitarías esta metodología. Tomarías medidas para eliminar la causa. Un último consejo… recuerde que es poco probable que un individuo haya causado su problema. Es más probable que el problema sea el resultado de un proceso deficiente. Deming ha determinado que el 85% de los problemas son el resultado de procesos mal definidos o inadecuados y que solo el 15% de los problemas son realmente errores del operador.

 reglas de declaración de problemas

Ejemplos mal escritos –

El widget es demasiado largo.

Hay demasiados errores en nuestros informes.

Nuestro tiempo de entrega es horrible.

Estos ejemplos no detallan adecuadamente la profundidad del problema. Los 3 son un comienzo decente, pero se requiere más información antes de que tu equipo entre para averiguar qué pasó. La adición de cómo su empresa no cumplió con los requisitos es una necesidad en las declaraciones de problemas.

Buenos ejemplos:

El widget excede el requisito del cliente de 38 cm (define el requisito y cómo la organización no lo cumplió).

Los informes de calidad mensuales (define dónde se encuentra el problema) contienen más de 2 errores en promedio, mayores que los 0 errores esperados (define el requisito interno)

La entrega a tiempo ha promediado el 92%, menos que el objetivo del 98,5% (de nuevo, esto define el incumplimiento del requisito).

Mejores ejemplos –

Las últimas 10 tiradas de producción (define cuándo se produce el problema) muestran que el widget mide un promedio de 41 cm (el problema), que supera el requisito del cliente de 38 cm +/- 2 cm.

dado de resolución de problemas

Los últimos 2 meses (cuando) los informes de calidad contienen más de 2 errores en promedio, mayores que los 0 errores esperados.

La entrega a tiempo al Cliente X (donde se produce el problema) ha sido solo del 92% en los últimos 4 meses, menos del 98,5% requerido.

Estos mejores ejemplos le dan a sus equipos los detalles necesarios para investigar el problema y definir dónde debe enfocar sus recursos. Por ejemplo, no hay necesidad de buscar más allá de las últimas 10 ejecuciones de producción en la investigación de widgets. Las conclusiones preliminares del equipo indican que el problema no existía antes de esas corridas.

468 X 60 Estática

Inicio «»Estrategias de resolución de problemas «» Declaraciones de problemas

Deja una respuesta

Tu dirección de correo electrónico no será publicada.