Mucho se ha hablado de este tema y hay muchos documentos y tratados del mismo, así que no es mi intención profundizar en lo ya dicho sino que darle una mirada un poco más práctica y analizar su impacto en implementaciones de soluciones de negocio en empresas.
Para esto, comienzo definiendo "resistencia al cambio" como la oposición por parte de las personas a un cambio en la organización. Claramente esto nos dan un marco mucho más acotado, ya que esta resistencia como tal es parte de la naturaleza humana y bien puede aplicarse a un sinnúmero de situaciones y escenarios, pero justamente mi interés es, tal como lo mencioné anteriormente, es exponer mis conclusiones de situaciones empíricas derivadas de proyectos TI en empresas.
Aclarado esto, comento que en muchas empresas se ve con mayor naturaleza y regularidad el uso de especialistas y profesionales que forman equipos encargados de resolver los problemas derivados de la resistencia al cambio en cada proyecto. Si bien esto es válido en muchas situaciones, esta decisión depende de cada proyecto, porque en muchos proyectos esto más que una ayuda puede ser un nuevo problema, al poner un problema que tal vez no estaba latente sobre la mesa, generando así la instancia para "resistirse al cambio". Además, no todas las empresas pueden asumir los costos (que pueden ser exponenciales) al tener un área dedicada a este tema dentro del "paquete de proyecto", sobre todo si consideramos que no todas las implementaciones de soluciones de negocios es "la implementación del BIGERP" de la década y no tenemos todo el presupuesto corporativo para gastarlo de una vez. La realidad es mucho más austera que esto y en la mayor cantidad de veces nos veremos enfrentados a un presupuesto muy ajustado que debemos, por todos los medios, tratar de respetar.
Por lo anterior y según mi experiencia, un buen punto de partida en todo proyecto es entrevistar a los usuarios claves del proyecto uno a uno y, si es posible, entrevistar al resto de usuarios en grupos de no más de 5 personas (este no es un número antojadizo, pero en esta caso no me dilataré detallando los porqués de él). En estas entrevistas (personales o grupales) podremos exponer que se pretende hacer en el proyecto, pedir su colaboración explicándoles la importancia de su participación y hacer una sesión final de preguntas y respuestas (clave) en donde les aclaremos todas sus dudas. Lo anterior es muy importante, ya que tal como cualquier sicólogo explicará (mejor que yo por supuesto), cuando una persona no tiene suficiente información, tiende naturalmente a rellenar esos espacios vacíos con sus conjeturas que normalmente son basadas en sus miedos e inseguridades, ya que un tema fuerte que genera la resistencia al cambio es justamente la amenaza de inestabilidad y la incertidumbre que acompaña al cambio. En otras palabras, se llenará su cabeza de ideas negativas hacia el proyecto y habremos generado, al omitir este proceso de A&Q, grandes opositores al cambio organizacional. Es por esto que son tan importantes estas entrevistas, las cuales son para mi un requisito obligatorio.
También es importante explicar durante este proceso cuales son las ventajas y beneficios que obtendrán los usuarios (ya sean usuarios clave o usuarios finales) con este cambio. Normalmente hay ventajas como la mayor productividad, por ejemplo, que se genera con la implementación de una solución de negocios, pero ¿como traducimos la mayor productividad en un beneficio para el usuario? ya que muchas veces el ser más productivo no se refleja directamente en un beneficio para el empleado. Es entonces cuando vemos que parte de nuestra labor es el traducir esto en beneficios para el trabajador, lo cual debemos tomarnos el tiempo para hacerlo bien y así generar un ambiente facilitador para el cambio ya que este es nuestro Az que debemos jugar muy bien. Algunas ejemplos de esto pueden ser que el empleado hará su trabajo en menos tiempo y por ende tendrá más tiempo libre. Si traducimos esto en que podrá estar menos horas en la empresa (en vez que se traduzca en tiempo ocioso simplemente), verán (con sorpresa) los muchos interesados en tal beneficio y por ende en que un proyecto que les genere tal beneficio sea llevado a cabo con éxito. Otras formas más usuales de compensación son el "bono de producción" del cual no es necesario detallar porque todo el mundo lo conoce ampliamente, pero yo particularmente les insto a los empresarios a ser creativos y, por que no, encuestar (si es posible) que beneficio le gustaría recibir a cada persona, de forma que se genere una participación de los usuarios y así ellos verán que son parte activa de la definición del proyecto, lo cual los motivará más aún. La empresa por otro lado verá sus números, montos de inversión del proyecto y sus expectativas de ROI para finalmente analizar que beneficios puede entregar y cuales no, pero en síntesis, es importante gastarse su tiempo en este hito. El no hacerlo tarde o temprano nos pasará la cuenta.
Otro punto relevante en la resistencia al cambio es la definición de metas del proyecto. Cuando se fijan metas muy irreales o difíciles de cumplir, éstas suelen gatillar la frustración de los usuarios cuando no se logran alcanzar y finalmente generan una gran resistencia por el éxito del proyecto, ya que cual electrón inestable en la estructura atómica, el usuario buscará su posición más cómoda dentro de la estructura organizacional y abogará por la cancelación del proyecto y la prosecución de las "antiguas prácticas". Es por esto fundamental que quienes definan el proyecto fijen metas alcanzables y si el proyecto es muy largo, lo dividan en etapas alcanzables (dividir para reinar), comenzando por las etapas más alcanzables si es posible (en algunos casos estas etapas no van de la mano con las necesidades de la empresa, pero hay que buscar un equilibrio) y así cuando estas etapas menos difíciles sean alcanzadas, generará un ambiente colectivo de éxito y sacará la gran nube de fracaso generadora de los pequeños temores del día a día, consiguiendo así usuarios más confiados, seguros y con más energía para sacar adelante el resto del proyecto.
Finalmente y lamentablemente, en algunos casos, a pesar del apoyo y motivación que reciben los usuarios, puede que algunos sigan oponiéndose al cambio. De ser así, tal como lo diría un doctor, hay que evaluar una posible cirugía. Yo diría que esto hoy en día es un tema que casi no se da, sobre todo con las evaluaciones psicológicas a las que son sometidos los empleados y usuarios antes de empezar a trabajar, pero lamentablemente en algunos casos se da y lo que debe hacer la empresa es asumir el costo del cambio que significará en algunos casos el reemplazo del personal. En este punto hago dos observaciones:
- Si la empresa no evaluó psicológicamente a los usuarios en el momento que se contrataron, que pudo haber sido mucho tiempo antes siquiera de pensar en realizar un proyecto de cambio tecnológico, el comienzo del proyecto es un buen momento para hacerlo. De esta forma podremos tal vez ahorrarnos nosotros y el empleado un despido no esperado y cambiar esta desagradable opción por una mucho más atractiva: la reubicación. Esta opción (la reubicación) será incluso una buena noticia, dándole a la persona que se resistirá al cambio más adelante una opción de un trabajo que si le acomode y por otro lado dándole a otra persona que si quiera el cambio la oportunidad de participar y beneficiarse de él.
- Si el reemplazo de personal fue algo inevitable, tenemos la opción que no podemos desaprovechar, de contratar a alguien altamente capacitado para el cargo, que se adapte al nuevo escenario cómodamente y, por que no, que sepa y tenga práctica en las herramientas que estamos implementando. De esta forma nos veremos doblemente beneficiados, incorporando la experiencia de otros proyectos y la visión de otras realidades en nuestra empresa, ya que normalmente la única visión de las "otras realidades" u "otras implementaciones" viene dado del equipo implementador, el cual no es parte de nuestra empresa y una vez terminado el proyecto ya no estará tan a mano.
En síntesis, para mí los puntos fundamentales para tratar en forma práctica la resistencia al cambio son:
- Sesiones con los usuarios antes del proyecto, en donde se liman las posibles asperezas que se podrán generar más tarde.
- Definir los beneficios para los usuarios, estableciendo claras motivaciones al éxito.
- Definición de metas (o hitos) del proyecto en forma realista.
- Evitar en lo posible la rotación, pero enfrentarla adecuadamente si es necesario.
Como lo mencioné en un inicio, hay muchos tratados y documentación al respecto, muy largos en muchos casos lo que hace que este tema sea difícil de abordar. Mi intención es aportar de esta forma con mis años de experiencia en algo muy resumido y práctico que puede bien ser tomado como orientación, entregando herramientas prácticas.
Esperando sea de utilidad para muchos, pero feliz si logro ayudar solo a uno,
Neil Reyes
