Modelos informáticos

Regresar al índice

En el mundo de los arquetipos, la definición de los elementos de un sistema es imprecisa, y no sabemos con exactitud qué pautas de conducta producirán los sistemas. En el modelo informático de un sistema, podemos ver lo que sucede cuando llevamos nuestras premisas a sus conclusiones lógicas. Esto convierte la modelación en una valiosa herramienta de indagación, pues permite verificar las hipótesis antes de aplicarlas y nos brinda la base para diseñar "laboratorios de aprendizaje" que sirven como entornos transformadores para un equipo u organización. En la práctica, se han usado modelos para:

• Mostrar cómo las estructuras sistémicas generan pautas de conducta.
• Verificar si una estructura reproduce el desempeño que se observó  en el mundo real.
• Explorar cómo cambiará la conducta cuando se alteren diversos  aspectos de la estructura.
• Revelar puntos de abordaje que de otra manera se pasarían por  alto.
• Inducir a los equipos a sumirse más profundamente en el aprendizaje de sistemas y permitirles experimentar con las consecuencias de su pensamiento.

Para ver qué pueden lograr los modelos, pensemos en un sencillo ciclo compensador cuyos actos son guiados por un objetivo explícito. Una empresa se ha fijado una meta para la cantidad de empleados que necesita. Ajusta (aumenta o disminuye) su personal según la brecha entre su personal actual y su objetivo. Pero el sistema implica significativas demoras: el tiempo que se tarda en reconocer la brecha, tomar medidas y contratar o despedir personal:

El ciclo brinda una descripción general del proceso, pero no da indicios de sus efectos a través del tiempo. Por ejemplo, si la compañía tiene un personal demasiado reducido, ¿habrá una transición sin sobresaltos hacia el nivel deseado?. Aquí utilizamos el ordenador para rastrear sin ambigüedades las implicaciones que las interrelaciones que hemos creado tendrán para la conducta, y para dar vida a los ciclos. Pero para ello, es preciso traducir rigurosamente esta descripción general a las condiciones que impone el software. ¿Qué cantidad exacta de empleados deseamos? Digamos dos mil. ¿Cuántos empleados tenemos? Mil quinientos. Indicamos al ordenador que deseamos aumentar el personal un 30 por ciento cada mes, para aproximarnos al objetivo buscado, y suponemos que se tardarán tres meses en sentir los efectos de las contrataciones o despidos.

Más aún, cada vínculo entre los elementos contiene una relación matemática, la cual debemos definir dentro del programa. Algunos elementos se convierten en stocks -"depósitos" o "continentes"-, como la cantidad de empleados actuales (a menudo aparecen en pantalla como un rectángulo). Los stocks son influidos por los flows -"flujos"-, como la cantidad de contrataciones y despidos (a menudo se presentan como una flecha con una válvula circular adosada). Los flujos son como los chorros de un grifo, y controlan el contenido que entra o sale del continente. También existen otras influencias, que aparecen como flechas sólidas que eslabonan los elementos.

Especificamos las relaciones utilizando fórmulas matemáticas (aquí, la "brecha" se define como “personal deseado” menos “personal actual”, y se incluye en la fórmula una demora de tres meses para contrataciones o despidos"). Cuando ejecutamos la simulación, podemos representar diversas posibilidades y ver un diagrama de pautas de conducta que muestra cómo se desempeña el sistema con el correr del tiempo. En el modelo que creamos aquí, los niveles actuales de personal tienden a oscilar hacia nuestro objetivo, siguiendo las pautas típicas de un ciclo compensador con demora: al principio demasiada gente (al cabo de seis meses), luego demasiado poca (al cabo de doce).

¿Por qué la cantidad de empleados oscila en torno del nivel deseado? ¿Por qué no va directamente hacia nuestro objetivo? Con el modelo, podemos aprender más al eliminar las demoras de la estructura. Esto reduce las oscilaciones (algo que resulta fácil de hacer en el ordenador, pero no tanto en la realidad).

¿Qué ocurre si eliminamos un tercio del personal? Así como nos "extralimitamos" en la contratación, el nuevo objetivo provocará una extralimitación en la dirección contraria. La demora significa que se eliminará más gente de la necesaria, y habrá que volver a tomar empleados. Es una sorpresa costosa y desalentadora, que no resulta obvia en los bocetos del ciclo compensador que dibujamos con papel y lápiz.
El concepto de "aplicación de palancas" con miras a introducir un cambio deriva de los modelos informáticos. Como descubrió Jay Forrester en su trabajo sobre dinámica industrial, los ejecutivos que se proponen introducir cambios valiéndose de un modelo informático habitualmente agravan la situación. Continúan con las acciones más obvias y no saben dónde aplicar la palanca, o saben dónde aplicarla pero la orientan en dirección contraria a la deseada.

La dificultad de la modelación de sistemas no consiste tanto en aprender a utilizar el software, sino en aprender a representar fielmente la realidad actual, verificando continuamente nuestras premisas hasta que el modelo informático refleje nuestra mejor comprensión y se comporte en forma aceptablemente verosímil. Mucha gente cree que el uso del ordenador ofrece una solución mágica, pero sucede lo contrario. Cuando utilizamos un ordenador, debemos hacer muchos más supuestos, y debemos expresarlos en términos cuantitativos, numéricos. A veces las fórmulas son directas y evidentes., pero en la mayoría de los problemas empresariales debemos expresar normas y actos ambiguos en relaciones cuantitativas. En ese sentido, si un arquetipo es como el boceto de un edificio hecho por un artista, un modelo informático es como un conjunto de planos, junto con los coeficientes técnicos, los detalles de la fontanería y el análisis de la tolerancia de los materiales.

Esto implica una notable curva de aprendizaje. Alguien puede aprender a usar una aplicación como ¡think! en pocas horas, ¿pero cuánto se tarda en aprender a diseñar un modelo que produzca resultados utilizables y mejore el aprendizaje en equipo? Traducir un complejo problema empresarial a un modelo que tenga sentido es una delicada artesanía, y los programas de modelación no contienen criterios intrínsecos para ayudar a distinguir si un modelo es creíble o apropiado. John Sterman dice: "Estos programas son ideales para elaborar rápidamente modelos erróneos". Más aún, ni siquiera un magnífico modelo permite sortear el trabajo con las disciplinas, a pesar de su atracción. Uno de los requisitos para la creación de buenos modelos es la capacidad de los equipos para analizar sus supuestos y poner en tela de juicio sus creencias.



Espero haber ayudado en algo. Hasta la próxima oportunidad!

Regresar al índice