Cómo y cuándo escuchar a los usuarios

A partir de alguna entrada anterior de las de gestionar proyectos (1), parece que algunos lectores han pensado que defiendo una posición digamos que “autoritaria” de la implantación de sistemas (o sea, de las de “esto es lo que hay”), mientras que al mismo tiempo la falta de involucración y aceptación de los usuarios resulta, según toda la práctica y la investigación, la principal causa de fracaso de los proyectos TIC, tanto en su fase de realización hasta la puesta en marcha, como en su posterior utilización efectiva (2).

En realidad, lo que parece que van demostrando el saber hacer profesional y la literatura científica es que no todos los proyectos son iguales, ni todas las organizaciones ni todos los usuarios, y que probablemente se necesita, como en tantas cosas, una reflexión y un enfoque “estratégico” sobre qué clase de proyecto queremos y podemos hacer en cada caso y una dirección también «estratégica» sobre cómo y cuándo manejar las interacciones con los interesados y usuarios y corregir el rumbo a tiempo si las cosas van mal dadas. Esto es especialmente claro, por ejemplo, en las implantaciones de productos empaquetados (ERPs y otros) y en organizaciones grandes y complejas donde el poder y la influencia están muy repartidos (como hospitales, administraciones públicas, universidades o grupos empresariales con múltiples unidades de negocio).

La gestión de proyectos TIC se parece en muchas cosas al urbanismo. Mi urbanista favorita, Jane Jacobs, dice siempre que la ciudad es mucho más importante que el proyecto y que la vitalidad y variedad de usos que hacen los ciudadanos de su ciudad es mucho más importante que la elegancia y la lógica del diseño de la ciudad perfecta impuestos desde arriba (3). En el ámbito de los sistemas de información, Erica Wagner y Sue Newell, entre otros, han ido demostrando en una perspectiva digamos que “sociológica” que la empresa es más que el proyecto, y que el ciclo de vida de la implantación de sistemas, en especial en el caso de los sistemas de empresa, necesita de una aproximación más amplia y de plazos más largos, en lugar de medir el éxito en el cumplimiento de una determinada funcionalidad, plazos y costes (4, 5).

Esta visión amplia del proyecto tiene algunas consecuencias fundamentales. Por ejemplo, desmonta el concepto de “mejores prácticas” imbuido en la lógica de los sistemas de empresa paquetizados, matiza el mito de que la mejor implantación es la que más se adapta al estándar, revisa la idea de la “esponsorización fuerte” y la toma de decisiones “directiva” a lo largo del proyecto de implantación, establece una visión de implantaciones faseadas e iterativas (frente al enfoque de “big bang” y “roll out”) y, finalmente, obliga a reconsiderar el papel y la participación de los usuarios y directivos, que es lo que queríamos decir hoy.

Los usuarios se quejan con razón de que no se les ha escuchado y entendido y aspiran a que el nuevo sistema les deje hacer las cosas como ya las hacen, sólo que más rápido, amistoso y mejor (el “legacy thinking”). Los analistas se quejan con razón de que los usuarios no son capaces de mostrar sus requerimientos de forma precisa y ordenada, no saben o no saben explicar lo que quieren, no dedican tiempo y compromiso al proyecto y no quieren entender las bondades del nuevo sistema que funciona con éxito en todas partes (el “vanilla thinking”).

Lo que yo quiero decir, básicamente, es que vale la pena un ejercicio de pedagogía al principio y a lo largo del proyecto, prometiendo poco y explicando el esfuerzo y el cambio; que en las fases iniciales, suele valer la pena un trabajo más limitado y menos preciso de toma de requerimientos, con un número pequeño de usuarios clave; que es bueno llevar pronto prototipos y enseñar su uso en vivo a un número progresivamente mayor; que es mejor entregar lo antes posible una parte de la funcionalidad básica e implantarla en una parte de la empresa; y que la participación más útil e intensa de los usuarios se debe producir en la fase de post-implantación, con un diálogo y un compromiso activo y honesto de cuáles son las líneas rojas que no se pueden cruzar y de apertura a reconfigurar o customizar (sí, también, customizar, o sea desarrollar a medida) todo aquello que tiene sentido para que la gente trabaje más y mejor con los nuevos sistemas.

Los usuarios y también los analistas sensibles aprenden “haciendo”, o sea usando los sistemas, adaptándose y disfrutando de lo nuevo, y mostrando qué se debe modificar sensatamente para que su trabajo y el trabajo de todos sea más efectivo y el sistema mejor. Suele ocurrir que en este compromiso tampoco hay tantas cosas que cambiar, que la gente es bastante razonable y que los resultados de adopción y satisfacción aumentan.

Notas:
1. http://blogs.uoc.edu/informatica/2011/10/14/como-aprendi-a-gestionar-proyectos-i/

2. http://blogs.uoc.edu/informatica/2011/09/26/bromas-aparte-mas-sobre-gestion-de-proyectos/

2. Jacobs J. (1961, 1992). The Death and Life of Great American Cities (Vintage). Hay una nueva espléndida edición española de la editorial Capitán Swing (2011).

3. Puede verse, entre otros, el artículo Wagner E. y Newell S. (2011), “Changing the Story Surrounding Enterprise Systems to Improve our Understanding of What Makes ERP Works in Organizations”, en Galliers R. y Currie W.: The Oxford Handbook of Management Information Systems (Oxford University Press).

4. Entre nosotros, Joan Antoni Pastor, profesor de la UOC ya presentó esta aproximación “extendida” del ERP hace años: Esteves J. y Pastor JA. (1999). “An ERP life-cycle-based research agenda”, en 1st. International Workshop on Enterprise Management Resource and Planning Systems (Venecia, Italia).