6 mar'11

10 problemas habituales en el Análisis de Procesos de Negocio (I)

Rara vez el análisis de procesos de negocio es un camino de rosas. A la complejidad de determinadas tareas, se le suma las especificidades del modelo de negocio de la empresa analizada, las peculiaridades de su cultura organizativa y, sobre todo, los efectos de la condición humana y la comunicación.

Ya sea porque se está analizando los procesos de negocio para implantar un sistema informático (como un ERP o un CRM, por ejemplo), ya sea porque se está realizando una labor de consultoría de negocio para mejorar la productividad o aplicar innovación, ya sea porque se está recabando información para una certificación de calidad o porque simplemente se intenta detectar puntos de bajo rendimiento en la empresa,… A pesar de que el análisis de los procesos de negocio de una organización puede venir motivado por diversos objetivos, muchas veces se encuentra con las mismas dificultades. En este post, se comenzará la exposición de 10 problemas sumamente comunes, y algunas posibles soluciones.

1. No diferenciar lo real de lo ideal
Es frecuente que los usuarios (stakeholders*) con los que realizas entrevistas para recabar información, no diferencien adecuadamente lo real (qué haces en tu trabajo) con lo ideal (qué es lo que deberías hacer o te gustaría que se hiciera).
* Nota: si bien la definición formal de stakeholder es mucho más amplia, abarcando también al propio equipo de proyecto, al patrocinador e incluso a otras organizaciones, es frecuente simplificar la definición haciendo referencia específica a los usuarios clave de un proyecto.
Los usuarios a veces tendemos a hablar de nuestra labor de una forma hipotética, haciendo eco de las políticas de procedimientos establecidas por niveles superiores de la jerarquía, omitiendo de forma intencionada aquellos problemas o situaciones que las hacen impracticables. Otra causa común es que en muchas ocasiones el modelo que presentan los usuarios obedecen únicamente a opiniones personales, no apoyadas en datos objetivos o estudios formales. Dicho de otra manera, expresamos la situación como nos gustaría que fuese, aunque no sea la mejor para los objetivos de la compañía.

El problema que surge para el analista de negocios es que se mezcla realidad con utopía, las imperfecciones cotidianas con la teoría abstracta. El resultado: un análisis alejado de la realidad.

Algunas posibles acciones destinadas a solucionar este problema son las siguientes:

  • Expresa de forma clara los objetivos del análisis: se trata de estudiar cómo estamos haciendo las tareas hoy en día.
  • Acuerda este enfoque con la directiva de la organización previamente a las reuniones con usuarios, y procura asegurarte de que se transmite desde dicha directiva a todos los implicados de las reuniones. Esto puede conseguirse fácilmente incluyéndolo en la reunión de comienzo de proyecto, en la que se expone a todos los implicados qué objetivos tendremos en las sesiones de análisis.
  • Inclúyelo en la introducción de las sesiones de análisis, para que sirva como recordatorio para todos. Recuerda expresarlo de forma cordial.
  • Contrasta lo comentado entre usuarios que comparten parte de un proceso encadenado. Por ejemplo, si el responsable de almacén asegura que hace un análisis semanal de los stocks y suministra una lista de las cantidades requeridas al responsable de compras, cuando entrevistemos a éste último debemos validar que efectivamente recibe dicha lista.
  • Comprobar los resultados de los procesos a través del rastro documental (ojo, sin que derive en una fiscalización agresiva de los procesos) . En el ejemplo anterior, además de preguntarle al responsable de compras, solicitaremos unos cuantos ejemplos de dichas listas de cantidades a pedir, o pediremos consultar el archivo de esos documentos semanales.
2. Resistencia al cambio
La resistencia al cambio es uno de los principales obstáculos en el desarrollo de cualquier proyecto, como si las organizaciones quisieran llevar al terreno corporativo la primera Ley de Newton.
La resistencia al cambio puede manifestarse de muchas y diversas formas, pero casi siempre es sutil y artificiosa, para ralentizar o detener el proceso de cambio sin que se observe claramente quién lo produce o sus verdaderas intenciones. En algunas ocasiones es el resultado de la malicia puesta en práctica, pero en la mayoría de las veces que lo he observado es una respuesta instintiva: la suma del miedo a lo desconocido más el concepto de supervivencia llevada al terreno laboral.
Diversos síntomas que manifiestan una resistencia al cambio son:
  • Enumerar numerosos problemas o excusas, sin aportar solución a ninguna de ellas. El objetivo es frenar todo lo posible con objeciones.
  • Presentar dualidad frente al equipo de proyecto (ante los que hay escasa cooperación) y a sus responsables (ante los que se manifiesta ingenua receptividad).
  • Proporcionar excusas para dificultar las reuniones de análisis, produciendo retrasos, aplazamientos e interrupciones.
  • Manifestar negatividad a las propuestas que se reciban, especialmente haciendo referencia a que no son aplicables en esa compañía, o alegando a que existe una tradición de procedimientos que las hacen inviables.
  • Pasividad o silencios conscientes, para dificultar la comunicación con el equipo de análisis.

 

Todos estos son síntomas de que hay personas que no desean cooperar en el análisis. Sin embargo, resulta más importante averiguar por qué:
  • En gran medida se debe a un problema de falta de comunicación o de confianza. Muchas veces no se aclara con los trabajadores de qué trata el análisis, qué objetivos tiene y qué se espera de ellos… Sin información adecuada, es comprensible que vean al equipo consultor como un auditor frente al que hay que defenderse.
  • Muchas veces la resistencia al cambio está coordinada, sujeta a directrices informales de su responsable de área, y transmitidas de forma que sea francamente difícil averiguarlo. En este caso, la gestión del cambio debe realizarse sobre la verdadera raíz del problema.
  • En ocasiones la resistencia es la reacción instintiva producida por el miedo. Miedo a perder el puesto de trabajo, miedo a ser desplazado o miedo a no ser capaz de adaptarse y perder privilegios. Un elemento clave en todo proyecto es saber gestionar adecuadamente la ansiedad que produce todo cambio en las personas.
Posible acciones destinadas a solucionar este problema:
  • Trata abiertamente la gestión del cambio con la directiva de la organización. Hay que tratar este elemento sin dramatismos, sino simplemente como un elemento más a gestionar. La participación directa y evidente de la directiva en este aspecto puede disminuir enormemente las dificultades producidas por el cambio. Se trata, ante todo, de una cuestión de liderazgo.
  • Comunica, comunica, comunica,… Es necesario tratar constantemente los objetivos del proyecto, la necesidad del cambio y qué se espera obtener con la labor de análisis. Recuérdalo constantemente, como elemento más de la introducción en las reuniones y entrevistas. La mayoría de las personas necesitan recibir una Visión clara para mantenerse motivadas: no basta con decirlo al comienzo y esperar que las personas compartan tu punto de vista. Hay que insistir en comunicar dónde está la meta.
  • Frente al miedo al cambio, manifiesta tranquilidad y transmítela. Genera confianza, a través de emplear mucha comunicación, ser positivo y escuchar a todos los implicados.
  • En algunos proyectos es frecuente establecer, como una primera fase de por sí, la propia gestión del cambio: comunicar a todos la necesidad de abolir el status quo. Incluso en proyectos de cierta envergadura, es frecuente que haya personal dedicado específica e íntegramente a la Gestión del Cambio. Por lo tanto, no subestimes esta pieza clave de todo proyecto.
  • Apóyate en los líderes informales de la organización. Hay personas que son más escuchadas que otras, por cuestiones de carisma o experiencia. Apóyate en dichas personas, tratándolas con deferencia, suministrándoles más información específica, dedicando más tiempo con ellas,… y tendrá un efecto en cadena con el resto.
  • Recuerda que rara vez el conflicto es personal. Los usuarios no suelen tener ninguna animadversión hacia el equipo de consultores, sino que se trata simplemente de que proyectan sobre ellos su frustración o su miedo. Trata y haz referencia a las actitudes, no a las personas.
  • Considera siempre que el principal impacto negativo de la resistencia al cambio es la propia persona que lo produce y su organización. No lo veas como un ataque hacia ti, es un comportamiento auto-destructivo que tienes que ayudar a reconducir. Educa, asesora y comunica… pero no te defiendas.
  • Comienza siempre con un punto de partida comprensivo. Sólo se debe pensar que las personas están actuando así por malicia, cuando haya evidencias claras de esas intenciones negativas. En cambio, cuando no sea así, es preferible partir siempre de la perspectiva de que se actúa así por miedo o falta de comunicación.
  • Trata abierta y educadamente las resistencias al cambio que se observen, en privado y con las personas afectadas. Generalmente, la exposición franca de la realidad obliga a las personas a posturarse, manifestando muchas veces las motivaciones que producen esas actitudes. Una conversación madura y adulta, junto con una adecuada respuesta a las motivaciones de dichas actitudes, suele ser suficiente para disminuir la resistencia.
  • Cuando observes resistencias al cambio, no te precipites. Dedica un poco de tiempo a observar, a reflexionar y a tratarlo directamente con la persona, antes de escalarlo a sus responsables. No pongas en evidencia un problema actitudinal hasta tener claro que no puedes resolverlo previamente con diálogo.
  • Considera la gestión del cambio como un elemento más en la metodología. Por tanto, debería tener su propio espacio en la planificación, en la ejecución y en el seguimiento de todo proyecto.
  • Cultiva la gestión del cambio. Lee obras y asesórate. Un buen comienzo son las de John Kotter, especialmente su artículo “Leading Change: Why Transformation Efforts Fail” (Harvard Business Review, Marzo-Abril 1995).
Puedes consultar otros posts relacionados con análisis de procesos de negocio: aquí

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *