La Identificación del Problema o Necesidad

La primera acción formal de la ejecución de un proyecto, cual quiera sea su tipo, es identificar el problema o necesidad que se pretende resolver. A objeto de evitar ambigüedades incluyo la definición de problema de acuerdo con los diccionarios.

Problema según el Diccionario de la RAE (Real Academia Española):

Del lat. problēma, y este del gr. πρόβλημα próblēma.

m. Cuestión que se trata de aclarar.

m. Proposición o dificultad de solución dudosa.

m. Conjunto de hechos o circunstancias que dificultan la consecución de algún  ……fin.

m. Disgusto, preocupación. U. m. en pl. Mi hijo solo da problemas.

m. Planteamiento de una situación cuya respuesta desconocida debe obtenerse a través de métodos científicos.

Problem según Concise Oxford Dictionary (1995):

“A doubtful or difficult matter requiring a solution”.

 (Una cuestión dudosa o difícil que requiere solución).

                        and

“Something hard to understand or accomplish or deal with”.

(Algo difícil de entender o lograr o trata).

Para evitar un desajuste en lo que usted entrega, y lo que el cliente desea es indispensable estar de acuerdo con la definición del problema real, entender que un problema en una empresa puede ser percibido de manera distinta según sea la persona que lo observe. A veces se confunden con los síntomas o con los deseos y gustos personales.

Un problema o nueva actividad, o nuevo producto, o nuevo proyecto en el lugar de trabajo se crea en respuesta a una necesidad del negocio. Y, que precisa ser definido de la mejor forma posible a objeto de no malgastar tiempo ni recursos.

A continuación, describiré un método para identificar el Problema o Necesidad, que en estricto rigor corresponde al Análisis de Requerimiento [1], asumiendo que las acciones necesarias para resolver el problema; es decir, la solución del Problema o Necesidad constituyen, primero un Anteproyecto y, después un Proyecto.

Identificar a las Partes Interesadas

¿Por qué son importantes?

Las Partes Interesadas –Stakeholders- son personas, grupos, u organizaciones que pueden afectar a la solución del problema o al proyecto, o pueden ser afectadas por la solución del problema, o perciben que puede ser afectadas por decisiones, actividades, o resultados del proyecto, cuyo objetivo es resolver el problema.

Las Partes Interesadas pueden estar activamente involucradas en la solución del problema o pueden tener intereses que pueden afectar negativa o positivamente el devenir del proyecto que resolverá el problema. Existen diferentes Partes Interesadas que pueden tener expectativas que entran en conflicto con la solución del problema. En definitiva, las Partes Interesadas pueden ejercer influencia sobre la identificación del problema o necesidad, sea por acción u omisión.

 ¿Quiénes son las Partes Interesadas?

Para el caso de la Identificación del Problema es necesario conocer quienes son las Partes Interesadas; es decir identificar a todas las personas relacionadas con el Problema que se pretende resolver, mediante la ejecución de un proyecto. Como también todas la entidades internas o externas que tengan intereses o relación con el problema.

Quién esté designado para ejecutar la tarea de identificación del Problema debe individualizar y calificar a las Partes Interesadas, considerando:

  • Si son internas o externas a la organización.
  • Si tienen una actitud positiva o negativa respeto del proyecto.
  • Si participarán en forma activa o como consejeros.

 Ranking de Interés e Influencia

Cada proyecto tiene “Partes Interesadas”, formando el “elemento humano” del paradigma de la gestión de proyectos. Como su nombre indica, un grupo de interés del proyecto es cualquier persona o entidad con una apuesta en el proyecto —tienen algo que perder y/o algo que ganar. Esta apuesta impulsa el comportamiento, y el comportamiento impulsa los resultados.

Para el éxito del proyecto, con un mínimo de conflictos, es necesario lograr que todos los interesados estén totalmente comprometidos y motivados. El compromiso y la participación infunden orgullo de la propiedad, lo que lleva a mejores resultados, entregados de una manera más productiva. La capacidad de enganchar comienza con una comprensión completa de la identidad de los involucrados y el papel  que tienen asignado, los intereses creados, la responsabilidad y el poder de influir en los resultados finales. En términos de procedimiento, este entendimiento se obtiene a través del análisis de los interesados.

i. Identificar las Partes Interesadas

Consiste en determinar cuáles son las personas que de alguna u otra manera participan y/o influyen en la identificación del Problema o Necesidad, y a la vez establecer cuál será el rol que desempeñaran. La siguiente es una lista con los roles comunes:

  • Los Beneficiarios: Grupo / Persona que recibe un beneficio de la solución del problema.
  • Los Líderes: Grupo / Persona responsable de la gestión de la ejecución de la solución del problema o proyecto.
  • El Equipo del Proyecto: Grupo / Persona responsable de la ejecución del proyecto.
  • El Patrocinador: Grupo / Persona responsable de la supervisión y el patrocinio.
  • Los Asesores: Grupo / Persona responsable de asesorar y supervisar la identificación del Problema.
ii. Establecer Quienes Tienen Interés en la Solución del Problema (Proyecto)

Se utilizan dos dimensiones para establecer el interés en el resultado de la solución

  • Interés determinado por el Impacto. Cada solución de un problema o necesidad tiene consecuencias, que se manifiestan en una variedad de formas y grados (operativos, financieros y personales). La solución de un problema o necesidad puede cambiar la forma en que se realiza el trabajo, disminuir la responsabilidad, añadir más responsabilidad, perder poder y similares. El impacto se puede sentir de muchas maneras, tanto obvias y como sutiles.
  • Interés determinado por la Responsabilidad. Es sabido que la responsabilidad —Accountability- es un gran motivador. La rendición de cuentas se define por el grado en el que un actor se hace responsable por su papel en la solución del problema o proyecto, ya sea para ejecutar tareas asignadas, por las decisiones que toma, por el apoyo que proporciona, por su participación, actitud y contribuciones globales. Cuanto más “responsabilidad” mayor interés.
iii. Determinar Quién Tiene el Poder de Hacer una Diferencia

Se necesita mucho esfuerzo para hacer que un proyecto sea exitoso, pero sólo se necesita un pequeño acto para deshacer ese esfuerzo y tornar las cosas en la dirección equivocada. La gente (y grupos) tienen el poder para conducir los proyectos all éxito o desviar el resultado a situaciones no deseadas. Esta es la moneda de dos caras conocida como la influencia de las Partes Interesadas. En la parte positiva, la participación activa de los interesados; sin duda, tendrá una influencia positiva en el proyecto y / o proceso, y esta posibilidad debe ser cultivada. En el lado negativo, los interesados también tienen la capacidad de influencia negativa, por medio de: falta de cumplimiento, indecisión, falta de apoyo, dilación, retención de información, y similares. Para facilitar el análisis de los interesados, la influencia potencial está determinada en gran parte por la fuerza de las consecuencias probables para cada persona.

Asegúrese de que su lista esté completa: recuerde, las Partes Interesadas afectadas por el Problema o con la Necesidad podrían estar todos en una división o departamento, o podrían estar repartidos entre varios departamentos o niveles de la organización.

iv. Validar la lista de las Partes Interesadas a Entrevistar

Una vez identificadas las Partes Interesadas validar la lista con el Patrocinador —Sponsor- de la Iniciativa y/o con los Ejecutivos que autorizaron ejecutar las acciones para identificar el Problema, así mismo establecer con ellos con quienes se hará la verificación, revisión y generación de la versión final de la Definición del Problema.

Situación Actual

Para que las Partes Interesadas —Stakeholders– comprendan el problema o la necesidad es indispensable que, en primer lugar, que conozcan y entiendan como se están haciendo las cosas ahora en el área afectada de su organización. Esto es lo que en proceso de negocios se denomina as-is.

Es común que las Partes Interesada conozcan sólo una parte del proceso asociado con el problema, en particular cuando el problema afecta a varios departamentos o gerencias.

La primera tarea es precisar la situación actual del entorno donde se está produciendo el problema o la oportunidad de mejoramiento, como ser:

  • Operación as-is. Procedimientos. Reglas de Negocios
  • Procesos de Negocios afectados.
  • Personal involucrado.
  • Estructura organizacional. Gerentes. Supervisores y Operativos.
  • Sistemas o aplicaciones computacionales.
  • Infraestructura, Tecnología.
  • Países donde se opera.
  • Adquisición de otra empresa.
  • Apertura de una nueva locación.
  • Obligaciones Legales.
  • Clientes afectado.s.
  • Sobre gastos, mermas, pérdida de venta, etc.

Para ello debe ejecutar entrevistas a las Partes Interesadas con o sin interés en resolver el problema, esto permite comprobar si el problema es una necesidad del negocio o un requerimiento personal. Tener en cuenta que producto de las entrevistas pueden evidenciarse situaciones conflictivas entre las Partes Interesadas, que es necesario considerar con el debido cuidado.

i. Entrevistas a Las Partes Interesadas para establecer la situación as-is

El objetivo principal de las entrevistas es obtener de las Partes Interesada cual es el Problema o Necesidad de negocio que se precisa solucionar, averigüe que quieren y que esperan de la solución del Problema. [2]

Puede utilizar varios métodos para comprender y capturar la información de las Partes Interesadas, como ser:

  • Uso de entrevista. Converse con cada Parte Interesada individualmente. Esto le permite entender las opiniones y necesidades específicas de cada persona.
  • Realizar talleres. Esto le ayuda a entender cómo fluye la información entre las diferentes divisiones o departamentos o personas y, asegurarse de que las transferencias y coordinaciones se gestionarán sin problemas.

Al usar estos dos métodos, es una buena idea seguir preguntando “¿Por qué?” para cada requisito. Esto puede ayudarle a eliminar los requisitos no deseados o innecesarios. [3]

Recuerde, cada persona considera el Problema o Necesidad desde su perspectiva particular. Usted debe entender estas diferentes perspectivas y reunir los distintos requisitos para construir un cuadro completo del Problema.

ii. Validar la información recopilada en las Entrevistas y/o Talleres

Para cada una de las Entrevista o Talleres generar una minuta con los puntos tratados con las Partes Interesadas y, una descripción del Problema según la visión del entrevistado o de los participantes del Taller.

Enviar el documento formalmente a cada entrevistado o participante del Taller, para la validación de la descripción del Problema o Necesidad. Según las prácticas de su organización podrá enviarse por mail, por escrito, requerir firma, enviar copia al Patrocinador, etc.

Análisis Situación as-is

i. Generar la Lista de Necesidades

Compilar una Lista de Necesidades detectadas en las distintas Entrevistas y Talleres, teniendo en cuenta que esta necesidad pude corresponder al problema completo, a un cuello de botella, a indefiniciones, a puntos de mejoras o carencias, para ello utilizar una tabla como la siguiente:

Identificación Necesidad 1

ii. Validar la Lista de Necesidades

Distribuir a todos los entrevistado y/o participantes de los Talleres la Lista de Necesidades y pedirles que:

  • Validen si las necesidades identificadas corresponden o no con su punto de vista.
  • Ajusten el Ranking de las Necesidades según el criterio de cada uno de los entrevistados.
  • Incluyan comentarios si lo estiman pertinente.
  • Devolver la copia con sus respectivas modificaciones.
iii. Generar la Definición del Problema

A partir de la Listas de Necesidades, devueltas por las Partes Interesadas, generar un ranking de Necesidades general y, considerando las Necesidades que ocupan los primeros lugares establecer una primera formulación del problema. A continuación generar la definición del problema usando un formato como el siguiente:

Identificación Necesidad 2

iv. Validar la Definición del Problema con el Negocio

La Validación de la Definición del Problema y la generación de la versión final se hará con la participación de la gente del Negocio y, utilizando el procedimiento acordado al momento de validar la lista de las Parte Interesadas a entrevistar.

Comentario

En general, el aplicar un método como el propuesto es considerado, en el mejor de los casos, como una actividad que no corresponde al tamaño de la empresa y, en otros casos, que es simplemente una pérdida de tiempo. No obstante, mi experiencia señala que todo tiempo que se ocupa en las definiciones, previas a la ejecución de un proyecto, tales como: Identificación del Problema, Definición del Alcance o Producto, Anteproyecto y Plan de Proyecto son inversiones en tiempo y recursos que redundarán en una mayor probabilidad de lograr un proyecto que cumpla con los objetivos y expectativas del Negocio.

Referencias

[1] https://en.wikipedia.org/wiki/Requirements_analysis

[2] https://www.mindtools.com/pages/article/newPPM_77.htm

[3] https://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/

La Solución de Problemas – DS10 Gestión de Problemas

Trataré en esta artículo la Solución de Problemas que se presentan en un ambiente informático, es decir problemas que tienen que ver con el software o con el uso del software, para la COBIT esta función corresponde a la DS10 Gestión de Problemas [1].

Luego en este artículo se trata el tema sobre como el área de informática debe organizarse para tratar la Solución de Problemas,  para ver métodos para la solución de problemas revisar en este blog  el artículo  “Solución de Problemas de Operación de un ERP”. 

Este artículo corresponde al cuarto y último de la serie “El Soporte, El Mantenimiento y la Solución de Problemas”

Diferencia entre Soporte y Solución de Problemas
El proceso DS8 Administrar la mesa de servicios e incidentes de la COBIT dice “El Soporte debe responde de manera oportuna y efectiva a las consultas y problemas de los usuario TI “, en otras palabras debe hacerse cargo de la necesidad inmediata del usuario, dejando muchas veces la solución del problema técnico de fondo para otra oportunidad y otro grupo de especialistas. Es para la búsqueda de la solución del problema técnico de fondo donde entrar a tallar la Solución de Problemas y en el marco de la metodología COBIT es el proceso DS10 Gestión de Problemas.

Procedimiento de Escalamiento
No todos los problemas tienen el mismo de grado de dificultad, de hecho la mayor parte de los problemas que recibe el mesón de ayuda son simples; los que personal con una capacitación adecuada puede resolver. Por otra parte, los problemas complejos necesitan personal con mayor experiencia y capacidades técnicas, y, que además es personal más caro y escaso. Por eso resulta conveniente organizar la solución de problemas por niveles, de modo que el nivel de partida o nivel 1 atiende soluciones problemas típicos, el nivel 2 o soporte provee la atención personalizada y los niveles 3 y superiores se concentren en la solución de problemas técnicos de mayor complejidad, que además toman más tiempo resolver. El proceso que organiza esta forma de trabajo se llama Escalamiento.

Solucion Problemas Escalamiento

Escalamiento.

El proceso de Escalamiento o Escalada [2] consiste en resolver paso a paso un problema, de modo que cada paso asume un cierto nivel de complejidad, por lo general se definen 3 a 4 niveles, así se tiene:

  • Nivel 1, que corresponde al Mesón de Ayuda, el que provee atención remota por teléfono o por captura de la pantalla de usuario. Por lo general este nivel resuelve problemas simples, por ejemplo: password, bloqueo de cuentas, registros de problemas con hardware, etc.. Los problemas que no resuelve este nivel son derivados al Nivel 2.
  • Nivel 2, este es provisto por el grupo área de Soporte propiamente tal, mediante la visita de un técnico al usuario. El objetivo es buscar primero una solución al problema de la persona (usuario) y, en segundo lugar resolver el problema técnico específico. La acción de soporte cubre problemas del usuario, que normalmente tienen que ver con el uso del software. En este nivel normalmente se resuelve entre el 50 y 60% de los requerimientos de Soporte. Cuando el problema no es resuelto, sea por su complejidad técnica, o porque el usuario precisa capacitación o porque se requiere incorporar una nueva función, o porque es necesario instalar una nueva versión del software, etc, el problema es derivado al Nivel 3.
  • Nivel 3, es el último nivel dentro de la empresa y está constituido por personas de mayor competencia técnica en temas específicos, por ejemplo: programadores, expertos en sistemas operativos, consultores funcionales de ERP, CRM, SCM o BI, etc. Y, por lo general son problemas con el software, como ser instalaciones, parametrizaciiones, actualizaciones, parches, etc. Dependiendo de su especialidad es el problema que se les asigna y el modo de resolverlo. Es en el Nivel 3 donde se cumple la función de “Solución de Problemas” con el proceso “Gestión de Problemas”. Si en este nivel no es posible encontrar la solución ser recurre a un soporte externo.
  • Nivel 4 o Soporte Externo, se recurre a este servicio cuando el problema está directamente relacionado con un producto de software, por ejemplo: Sistema Operativo, Comunicaciones, Administrador de Base de Datos, ERP, etc. O, cuando el problema necesita de un especialista que la empresa no tiene. Este es el último nivel de soporte y si no encuentra una solución al problema, por lo general propondrá otras alternativas de solución tal que el problema se resuelva usando herramientas y/o enfoques distintos. Una respuesta suele ser: “este problema se resuelve en el próximo release”.

Gráficamente el procedimiento de Escalamiento es:

Al igual que en los artículos anteriore les incluyo un Copy / Paste de lo que propone para la solución de problemas la COBIT, que corresponde al proceso “DS10 Gestión de Problemas” [1]. Una efectiva administración de problemas requiere la identificación y clasificación de problemas, el análisis de las causas desde su raíz, y la resolución de problemas. El proceso de administración de problemas también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros de problemas y la revisión del estatus de las acciones correctivas. Un efectivo proceso de administración de problemas mejora los niveles de servicio, reduce costos y mejora la conveniencia y satisfacción del usuario.

Control sobre el proceso TI de:
Administrar de los problemas,

que satisface el requisito de negocio de TI para:
garantizar la satisfacción de los usuarios finales con ofrecimientos de servicios y niveles de servicio, reducir el retrabajo y los defectos en la prestación de los servicios y de las soluciones.,

enfocándose en:
registrar, rastrear y resolver problemas operativos; investigación de las causas raíz de todos los problemas relevantes y definir soluciones para los problemas operativos identificado,

Se logra con:

Realizando un análisis de causas raíz de los problemas reportados

– Analizando las tendencias

Tomando propiedad de los problemas y con una resolución de problemas progresiva

y se mide con:

 Número de problemas recurrentes con impacto en el negocio

Porcentaje de problemas resueltos dentro del período de tiempo solicitado

 Frecuencia de los reportes o actualizaciones sobre un problema en curso, con base en la severidad del problema

 

DS10.1 Identificación y clasificación de problemas Implementar procesos para reportar y clasificar problemas que han sido identificados como parte de la administración de incidentes. Los pasos involucrados en la clasificación de problemas son similares a los pasos para clasificar incidentes; son determinar la categoría, impacto, urgencia y prioridad. Los problemas deben categorizarse de manera apropiada en grupos o dominios relacionados (por ejemplo, hardware, software, software de soporte). Estos grupos pueden coincidir con las responsabilidades organizacionales o con la base de usuarios y clientes, y son la base para asignar los problemas al personal de soporte.

DS10.2 Rastreo –seguimiento- y resolución de problemas El sistema de administración de problemas debe mantener pistas de auditoría adecuadas que permitan rastrear, analizar y determinar la causa raíz de todos los problemas reportados considerando:

 

  • Todos los elementos de configuración asociados.

  • Problemas e incidentes sobresalientes.

  • Errores conocidos y sospechados.

Identificar e iniciar soluciones sostenibles indicando la causa raíz, incrementando las solicitudes de cambio por medio del proceso de administración de cambios establecido. En todo el proceso de resolución, la administración de problemas debe obtener reportes regulares de la administración de cambios sobre el progreso en la resolución de problemas o errores. La administración de problemas debe monitorear el continuo impacto de los problemas y errores conocidos en los servicios a los usuarios. En caso de que el impacto se vuelva severo, la administración de problemas debe escalar el problema, tal vez refiriéndolo a un comité determinado para incrementar la prioridad de la solicitud del cambio (RFC) o para implementar un cambio urgente, lo que resulte más pertinente. El avance de la resolución de un problema debe ser monitoreado contra los SLAs.

 

DS10.3 Cierre de problemas Disponer de un procedimiento para cerrar registros de problemas ya sea después de confirmar la eliminación exitosa del error conocido o después de acordar con el negocio cómo manejar el problema de manera alternativa.

DS10.4 Integración de las administraciones de cambios, configuración y problemas Para garantizar una adecuada administración de problemas e incidentes, integrar los procesos relacionados de administración de cambios, configuración y problemas. Monitorear cuánto esfuerzo se aplica en apagar fuegos, en lugar de permitir mejoras al negocio y, en los casos que sean necesarios, mejorar estos procesos para minimizar los problemas.

Referencias

[1] Cobit 4.0,

http://www.isaca.org/AMTemplate.cfm?Section=Overview&Template=/ContentManagement/ContentDisplay.cfm&ContentID=22940

[2] Ejemplo de Procedimiento de Escalamiento http://www.niehs.nih.gov/guide/policies/escalate.htm

    

 

Solución de Problemas de Operación de un ERP

Cómo abordar un problema de la operación de un ERP
Partiendo de la tercera acepción de problema que nos indica el Diccionario de la Lengua Española, XXII Edición, que señala que problema es el “Conjunto de hechos o circunstancias que dificultan la consecución de algún fin”, tenemos que un problema del ERP es cualquier impedimento a obtener un resultado deseado. Esto se puede ejemplificar con frases tales como:

  • No me cuadran las existencias.
  • La fecha no corresponde.
  • A veces lo haces y a veces no.
  • T´a malo.

El siguiente análisis corresponde a la típica solicitud, de un Usuario al personal de Soporte (quien quiera que sea), que canónicamente comienza con “El sistema no funciona …” , que traducido significa “necesito generar un resultado y el sistema no me lo da?. Por consiguiente, de acuerdo a la definición del Diccionario estamos con un problema.
Entendiendo que existen muchas estrategias de solución de problemas (ver por ejemplo http://en.wikipedia.org/wiki/Problem_solving (Consulta 15-12-05) para este tipo de problema propongo partir dividiendo el problema (divide et impera) entre los culpables:

  • El Software, es decir el ERP.
  • El Usuario, es decir uno.

Analizando la probabilidad de falla de ambos culpables en relación al problema reportado, en mi experiencia con los ERP y con los Usuarios de ERP he comprobada que la probabilidad de fallar el ERP, es decir que tenga una error de programación o bug, es menor al 5% de los casos y que la probabilidad que la falla corresponda al Usuario es del 90% y el 5% faltante es para no ser exagerado.

¿Cómo determinamos que la falla es del ERP?
Asumiendo que la falla es del software procedemos de la siguiente manera:

  • Viendo si sistema arroja un mensaje de error relativo a una operación interna.
  • Chequeando que el resultado es comprobadamente erróneo.
  • Revisando la Base de Datos de Conocimiento del Proveedor. En caso que efectivamente estemos en presencia de un error, es casi 100% seguro que estará registrado.
  • Comprobando si el sistema ERP se comporta en desacuerdo con lo que dicen los manuales o ayudas en línea.
  • Tratando de reproducir a voluntad el error todas las veces que se quiera. Ojo, esto es lo que normalmente piden los fabricantes para asumir que el error es “real”.

¿Cómo determinamos que la falla es del Usuario?
En primer lugar entender que a nadie le agrada estar con un error que le impide terminar su trabajo como corresponde, de modo que asumiendo que se entiende, sin lugar a dudas, sobre que trata el error y, cuales son sus efectos se debe proceder como sigue:

  • Antes que nada ver si existe alguna alternativa, by pass, proceso alternativo o solución tempooral para generar los resultados deseados y salir del paso.
  • Verificando si el Usuario está operando conforme a los procedimientos establecidos por su empresa.
  • Chequeando si el Usuario a ocupado o no la documentación (manuales, help, etc.) para analizar el error.
  • Preguntando respecto a la frecuencia de ocurrencia del error. No es lo mismo un error que se genera diariamente a uno esporádico.
  • Por analogía, chequear si para operaciones similares se genera el mismo error o parecido.
  • Analizando los datos involucrados. Nótese que esta acción es parte del Control de Calidad de los datos.

Algunos comentarios
Dada la complejidad de las operaciones (transacciones) que se registran en un ERP es casi inevitable que se produzcan errores en el registro de los datos, basta una pequeña interrupción al Usuario para que se distraiga de la acción de entrada de datos. Y, esto es la causa de la mayoría de los problemas que los Usuarios reportan.

Cada vez que un Usuario no logra obtener el resultado deseado tiene un cambio de ánimo, cargado a los sentimientos negativos. Lo que es entendible y esperable. Con la complicación que estos estados de ánimos no favorecen la búsqueda de la solución al problema.

Si el Usuario concluye que tiene un problema con el ERP, sugiero usar los pasos indicados más arriba, que por lo demás es lo que hace el personal de Soporte. De esta manera ahorrará tiempo, dinero y energía anímica. Y, en la eventualidad que efectivamente el error sea del ERP podrá reportarlo más documentadamente, lo que redundará en una atención más efectiva del personal de Soporte.