Sistemas administrativos, software y poder.

El poder juega un papel central en la conformación de un sistema administrativo. Yendo un poco más lejos, estoy bastante convencido de que el sistema administrativo mismo no es más que el reflejo de la distribución del poder en la organización en un momento dado. Las modificaciones en la estructura o en la ubicación de las personas que la integran son en realidad fluctuaciones en la distribución del poder subyacente en la organización, y no al revés.

Es un buen momento para aclarar que hablo de sistemas administrativos y distribuciones de poder reales. Todos sabemos que los elementos formales (el organigrama, los manuales, las normas, el software de soporte) no siempre reflejan (rara vez reflejan, en realidad) el sistema administrativo real de una organización. Se dan casos extremos (y los he visto) en donde incluso las declaraciones de los integrantes de la organización sobre “cómo se hacen aquí las cosas” tampoco tiene mucho que ver con cómo se hacen realmente.

Los que participamos en el desarrollo de sistemas informáticos de gestión (software aburrido, bah) lo sabemos mejor que nadie, ya que el software que construimos pretende ser un soporte a ese sistema administrativo o  incluso el reflejo total de éste, en los casos más ambiciosos. Así que el proceso de desarrollo es extremadamente sensible a estas fluctuaciones que son, recordémoslo, fluctuaciones en la distribución de poder de la organización para la cual trabajamos. Los proyectos se paquequean, una y otra vez, se cancelan, se aplazan, se retrasan, se abandonan.

El problema radica en que el software es un elemento mucho más rígido, mucho menos maleable una vez establecido que el sistema administrativo al que pretende soportar o reflejar. Esta rigidez es un arma que utilizarán o contra la que lucharán los diferentes actores en pos de acumular poder o mantener el que han obtenido. En efecto, una vez plasmados en código determinados circuitos de información, autorización y sectores de discrecionalidad éstos se vuelven mucho más difíciles de modificar.

Así, tenemos al que ocupa una posición dominante dentro de la estructura de su organización, que desea que “todo siga igual, pero informatizado” y que en realidad ve al proyecto con cierta desconfianza y prefiere seguirlo de cerca y con mano de hierro. Otro que, percibiendo la implantación como una oportunidad, desea “establecer un sistema más racional en la distribución de las actividades” y lucha por introducir modificaciones (sabemos que la racionalidad poco y nada tiene que ver con esa distribución, aunque una racionalidad aparente ayuda a apoyarla). Y también tenemos al que, viendo el proyecto como una amenaza declarada, pone palos en la rueda retaceando tiempo, recursos e información.

A los usuarios finales, generalmente fuera del círculo de decisiones formales respecto del software, les queda la chance de evaluar su posición final dentro del circuito propuesto y apoyar o rebelarse según el resultado de esa evaluación. Se les llamará entusiastas y dinámicos a unos, estáticos o reacios al cambio a otros, o arribistas e imprudentes a unos y expertos a otros, según el lugar que ocupe el interlocutor, favorecido o amenazado por los cambios.

Pero cuidado porque, ya lo dijimos arriba, las estructuras formales poco y nada tienen que ver con las reales. Detrás de los puestos más insignificantes se esconden armas poderosas… puede ser que la empleada que ve su posición amenazada por el nuevo sistema comente al gerente general durante el viaje en que éste la acerca a su casa (en el mejor de los casos), una y otra vez, lo poco conocedores de la empresa que son los analistas del proveedor, y cómo el gerente de tal está influenciando las decisiones a su favor para quedar mejor ante los dueños.

Vemos que la “resistencia al cambio” puede ser feroz y provenir de los lugares más inesperados. Tal vez lo más difícil para el proveedor, pobre pajarito en este nido de serpientes, sea determinar de qué lado debe ubicarse, es decir, a quién escuchar y a quién no. Pero para complicar más la situación, el “pobre pajarito” puede que no lo sea tanto, que existan conexiones fuertes entre actores por fuera de las estructuras y no siempre entre los más altos representantes de ambos. Podría ser el analista funcional el que lleve a la secretaria a su casa escuchando la cantinela sobre la inutilidad del puesto de su jefe (el de la secretaria… o el del analista).

Si las estructuras de poder reales se pareciesen a los organigramas y los circuitos administrativos reales a los cursogramas programar sistemas de gestión sería juego de niños y las metodologías ágiles una verdadera pérdida de tiempo. Pero nada de eso es así, y por eso la agilidad en el proceso de desarrollo es una herramienta imprescindible para satisfacer siempre los deseos de aquél al que le toque estar (hoy) arriba y seguir cobrando… por cierto, tal vez el que está hoy arriba prefiera un contrato más tradicional y un ciclo de vida clásico, ya que éste compromete más a la organización con el diseño inicial, que es el que él puede influenciar… la idea de que todo puede cambiar en cualquier momento no es tan agradable cuando se mira el mundo desde arriba.

Es ante todo por estas lindas y por demás mensurables y calculables cuestiones que los proyectos de software de gestión suelen transitar senderos tortuosos. Cuestiones que, dependiendo del papel que juguemos dentro del desarrollo, nos quitarán más o menos el sueño, pero estarán siempre presentes ya que son las que dan origen a aquello que modelamos: sistemas administrativos. Cuando diseñamos una base de datos o codificamos estamos representando, finalmente, relaciones de poder. ¿Lo habían notado?