Perfil de complejidad aplicado al Modelamiento de Procesos de Negocio Luciano Stucchi En el presente trabajo se aplica el perfil de complejidad al modelamiento de procesos de negocio, desarrollado a partir del formalismo de Event-driven Process Chain (EPC). Al ser el perfil de complejidad una función de la información mutua entre elementos de un sistema, para cada nivel de escala de este, su aplicación al modelamiento de procesos permitirá establecer cuánta información recogen estos y cómo se distribuye esta información en cada posible secuencia de sus subprocesos. Se explora, en un inicio, las características cualitativas que tiene dicho perfil según cómo se encuentre estructurado el diagrama y qué significado esconden las estructuras más básicas con las que puede construirse un proceso. En la medida en que el modelado de procesos se realiza con el objetivo de optimizar el funcionamiento de un negocio, la aplicación del perfil de complejidad podrá ofrecer también una medida cuantitativa con la cual establecer cuánto afecta en el resultado final la modificación de un subproceso. I. Introducción El perfil de complejidad es un formalismo (Bar-Yam Y. , Dynamics of Complex Systems, 1997) que cuantifica, a partir de la escala, cuánta información mutua comparten los elementos de un sistema. Esta información es capturada inicialmente a partir de la descripción que se hace de los elementos y de cuánto puede saberse de alguno de ellos a partir de los demás. El pionero en la medición de la información que describa la estructura de un sistema fue Ashby, a través de su icónico artículo sobre la variedad requerida de un sistema (Ashby, 1958). La variedad requerida cuantificaba directamente cuántas variables requería un sistema para interactuar con su entorno, a partir de la diferenciación de los escenarios —o circunstancias— que este ofrecía. Así, un entorno complejo que ofrecía muchos escenarios diversos a un sistema, lo obligaba a este a tener diferentes respuestas a dichos estímulos para garantizar una cierta adaptabilidad. Sistemas incapaces de responder de forma distinta a distintos estímulos eran incapaces de adaptarse y, por ende, fracasaban (Bar-Yam Y. , Multiscale Variety in Complex Systems, 2004). Aunque pionera en su enfoque, la variedad requerida no era capaz de cuantificar de forma diferenciada los requerimientos del entorno, según el sistema decidiera reaccionar desde todos sus elementos o alguna combinación específica de ellos (Gershenson, Requisite Variety, Autopoiesis, and Self-organization, 2014). Y esto ocurre porque aunque la variedad requerida utiliza la información que los elementos comparten, esta interdependencia no tiene restricción, de modo que no existe forma de diferenciar entre un sistema que maneje cierto nivel de complejidad a escala individual —elemento por elemento—, respecto de uno que lo haga exclusivamente nivel global —gracias a la intromisión de todos—. Para hacer esa diferenciación sería necesario, distinguir entre, por ejemplo, una oficina donde cinco analistas necesitan trabajar en conjunto para resolver un problema —su capacidad de respuesta funciona a nivel global—, entre otra oficina donde otros cinco analistas pueden resolver el problema trabajando de manera independiente —y su escala de acción sería individual—. Ambos conjuntos de analistas son capaces de manejar la misma información y reaccionar de manera exitosa ante el mismo estímulo del entorno. Sin embargo, no son sistemas equivalentes. Este siguiente paso para distinguir dos sistemas de acuerdo no a la complejidad de su funcionamiento, sino a los niveles donde se manifiesta esta complejidad, lo da Bar-Yam, a través de haber definido la variedad requerida multi- escala (Bar-Yam Y. , Multiscale Variety in Complex Systems, 2004). En este formalismo recoge la posibilidad de que un sistema, al interactuar con su entorno, pueda responder desde diferentes niveles de su estructura, definiendo para esto la escala de acción de dicha interacción. La escala recoge, en ese sentido, qué elementos están involucrados en la interacción y cómo se interconectan estos. Para poder medir la interconexión, se establece la información mutua entre elementos como un mecanismo cuantificable que, además, ha sido extensamente estudiado porque, en el nivel más pequeño, correspondiente a las interacciones entre elementos indivisibles, esta medida puede referir a la entropía de Shannon del sistema completo, siempre que la información mutua haya sido medida en bits (Bar-Yam Y. , Multiscale Complexity / Entropy, 2004). Esto, en estricto, permite derivar la entropía termodinámica del sistema, de tratarse de uno físico, bajo una sencilla conversión de unidades. El perfil de complejidad es una función intuible cualitativamente. Sin embargo, a partir de este desarrollo, es posible cuantificarla con precisión (Bar-Yam Y. , Multiscale Variety in Complex Systems, 2004). Una de las principales derivaciones que se obtienen de este perfil, a partir de dicha cuantificación, es la denominada información ponderada a escala, la cual es una cantidad que se conserva en un sistema mientras este modifique su estructura sin alterar su contenido. Esta constituye una medida posible para cuantificar la complejidad, existiendo otras como la utilidad marginal de información (Allen, Stacey, & Bar-Yam, 2014), el perfil sigma, (Gershenson, The Sigma Profile: A Formal Tool to Study Organization and its Evolution at Multiple Scales, 2011), entre otras (Binder & Plazas, 2001), (Shiner, Davison, & Landsberg, 1999). En el presente trabajo se presenta la aplicación del perfil de complejidad al modelamiento de procesos en los negocios. Esta herramienta ha mostrado una gran potencia al momento de entender, analizar y predecir el comportamiento de otros sistemas, desde casos estrictamente físicos, como por ejemplo un modelo Ising ferromagnético de gran escala (Gheorghiu-Svirschevski & Bar-Yam, 2004); un modelo Gaussiano de spines (Metzler & Bar-Yam, 2005); hasta fenómenos sociales, como la universalidad de la educación y los nuevos esquemas de transmisión masiva de conocimientos (Gershenson, Harnessing Complexity of Education with Information Technology, 2014). Aquí el enfoque que se le da está orientado al funcionamiento de los negocios, y en estricto, a los procesos con que funcionan estos. El acercamiento hacia los procesos de un negocio se hace desde la perspectiva del Event-driven Process Chain (EPC) (Gottschalk, van der Aalst, & Jansen-Vullers, 2008), el cual es un formalismo que define todo proceso a partir de la interconexión de tres tipos de elementos: eventos, funciones y conectores. Desde esta perspectiva, será posible establecer una red de nodos, a la que denominaremos diagrama de procesos. Este diagrama, en la medida en que interconecta de manera explícita todos los elementos que constituyen un proceso, estará marcando la forma cómo se relacionan los eventos con las funciones durante este, incluyendo cuánta información aportará cada elemento a aquellos con los que se conecta y cuán condicionada estará esta información. En ese sentido, cuando se aplique el perfil de complejidad sobre el diagrama de procesos, será posible determinar cuánta información maneja cada subproceso, de forma aislada y cuánta comparte con el resto del diagrama. A su vez, en la medida en que se extraiga la información ponderada a escala del sistema, se podrá verificar cuánto cambiaría este si uno o más subprocesos son modificados y cuánta flexibilidad tiene la estructura para reacomodarse sin cambiar este valor. Eso, orientado a la optimización de procesos en un negocio, permitirá tener un mejor entendimiento de cómo realizar una operación de este tipo y de los resultados que podrán obtenerse. El presente artículo se estructura de la siguiente forma: en la sección II se presenta un bosquejo de cómo funciona el perfil de complejidad y cómo este se puede obtener de un sistema arbitrario. En la sección III se introduce el formalismo EPC y se establecen las equivalencias con la teoría replicada en la sección anterior, derivando las deducciones correspondientes de ello. En la sección IV se exploran los resultados más evidentes a partir de ejemplos modelo sencillos que reflejen la utilidad del formalismo. Finalmente, en la sección V se desarrollan las conclusiones del presente trabajo y las direcciones posibles hacia donde este puede derivar. II. Perfil de complejidad Para poder definir y trabajar con el perfil de complejidad es necesario establecer algunas definiciones primeramente. El desarrollo que se hace a continuación reproduce en buena medida aquél hecho por Bar-Yam (Allen, Stacey, & Bar-Yam, 2014), aunque hemos adaptado su notación en algunos casos, por comodidad. Sistemas e información Se considera como sistema a la dupla formada por el conjunto de elementos y la función , la cual reflejará la información de los elementos y subconjuntos de , según cuál sea el argumento de la función. representa, en el caso de que su argumento sea un elemento de , la información propia que permite describir dicho elemento, es decir, aquella información que porta; en el caso, más bien, de tener como argumento a un subconjunto de , es decir, a un agrupamiento de sus elementos, representa la información que permite describir complementariamente a todos los elementos de dicho subconjunto, es decir, aquella información que se comparte como resultado de conocerlos. La función puede construirse de diferentes formas, según sea la naturaleza del conjunto . En términos generales, será una función proyectada sobre los números reales, cuya magnitud podrá medirse en bits y tendrá como características la monotonicidad y la adivitividad fuerte, es decir: ( ) ( ) ( ) ( ) ( ) ( ) Lo que será importante a tener en cuenta en la medida en que la información, dentro del sistema, solo podrá aumentar —o mantenerse constante— según se conozcan más elementos de este (monotonicidad) y que la información de un agregado de elementos nunca podrá ser mayor que la información contenida en los elementos por separado, restándole a estos la información redundante repetida entre ellos (aditividad fuerte). Esto podría parecer contradictorio si pensamos en que existen sistemas donde emergen propiedades a partir de las interacciones de los elementos, pero estas interacciones derivan justamente de características intrínsecas de estos, que se incluyen dentro de sus descripciones individuales. Lo que evita esta restricción es, básicamente, que se permita que aparezca información de la nada. Como en esto estamos requiriendo hablar de las interacciones de los elementos dentro del sistema, habrá que definir también dichas interacciones. Dependencia e información mutua Así, se le denomina dependencia de un elemento del conjunto a la estructura conectiva de dicho elemento, ( ), entre los demás elementos del sistema. Esta dependencia, para estar completa, debe referir a todas las combinaciones posibles de elementos, por lo que resulta en una descripción bastante extensa y que se escala a longitudes astronómicamente grandes cuando el número de elementos empieza a crecer. Al tratarse de una función estructural, solo proyectará valores sobre el conjunto binario {0,1}, de modo que la dependencia de un elemento no deja de ser el mapeo completo de todas las posibles conexiones entre ese elemento y el resto del sistema. La conectividad se representa por medio de dos símbolos. Por un lado ( ) representa cuánto se puede saber de a partir de , mientras que ( ) representa cuánto no se puede saber de sabiendo todo de . Es decir, el símbolo ; refleja la conexión, mientras el símbolo | refleja la desconexión entre elementos (ver Recuadro 1). Del mismo modo, la dependencia podrá referir a varios elementos en simultáneo, lo que simplemente reflejará que: ( ) ( ) ( ) Esta propiedad es importante puesto que refleja el hecho de que las dependencias son completamente conmutativas. Recuadro 1 Sea un sistema ( ), donde * +, las dependencias de serán ( ) *( ) ( )+ y las dependencias de serán ( ) *( ) ( )+. Ejemplo 1: un sistema con elementos por completo desconectados e independientes entre sí tendría ( ) * + , por lo que, necesariamente, ( ) * +. Esto significa que para poder conocer el sistema habrá que evaluar elemento por elemento porque no es posible saber nada de uno a partir de otro. En ese sentido, cada elemento siguiente del sistema aportará información nueva. Ejemplo 2: sea un sistema con dos elementos redundantes y completamente interdependientes. En este caso, ( ) * +, y naturalmente ( ) * +. Esto reflejará el hecho de que bastará conocer uno de los elementos para poder predecir completamente el otro y que el conocimiento de este segundo elemento no aportará nada al conocimiento previo que se tenía del sistema. A partir de las dependencias de un sistema será posible construir una función que cuantifique cuánta información se recoge en esas dependencias, es decir, cuánta información está contenida en la estructura conectiva del sistema. Esta magnitud complementará a justamente porque recogerá exclusivamente cuánto se puede saber de un elemento a partir de los otros, o de otro en particular. A esta función se le denomina y se proyectará sobre los elementos del conjunto de dependencias, de modo que: ( ) ∑ ( ) ( ) y a su vez se comprueba que: ( ) ( ) ( ) ( ) ( ) ( ) ( ) Estas dos últimas expresiones reflejan el hecho de que la información mutua ( ) de los elementos y de un sistema se puede obtener de la información de los elementos individuales, eliminando las redundancias entre ellos. Mientras, por otro lado, la información condicional ( ), que representa cuánto se puede saber de que no se puede decir a partir de lo que se sabe de , implica un cálculo más sencillo, que es el de restarle a todo lo que se puede saber conociendo a ambos, aquello que se sabe al conocer a . Escalas y la información estructural de un sistema Los conceptos desarrollados hasta ahora permiten recoger características de un sistema que reflejan su contenido, individual y estructural. Esta caracterización no permite, sin embargo, distinguir todavía la importancia que puede tener, o bien la información recogida en un conjunto de elementos, o bien, la estructura que constituyen dichos elementos, dentro del sistema. De esa forma, será necesario unificar ambas medidas, para lo cual se definirá una siguiente magnitud: la escala. La escala ( ) será la cantidad de elementos que constituyen aquella dependencia que describe la conectividad de algún subconjunto de elementos de . Esto no hará más que reflejar cuántos elementos se involucran en una estructura, independientemente de cómo se conecte esta. Así, se tendrá una relación de todos los elementos involucrados en todas las posibles conexiones de los elementos de un sistema. Aunque esto pueda parecer innecesario, la potencia de la definición viene justamente de recurrir a la otra medida que se tiene como función de la estructura, la información mutua ( ) A partir de estas dos definiciones, se construye la información medida a escala ( ) de un subconjunto , la cual corresponderá a toda la información que encierran las estructuras que componen los elementos de , ponderada con la cantidad de elementos que constituyen cada estructura. Así: ( ) ∑ ( ) ( ) Lo interesante de esta medida es que ( ), al recoger la información de todo el sistema, será independiente de cómo esté construido este, puesto que las redundancias en la estructura interna se habrán anulado durante la ponderación. Así, la información ponderada a escala de todo un sistema será una cantidad que se mantenga constante fuera de cómo se relacionen sus elementos internamente. Perfil de complejidad de un sistema A partir de la información mutua de los elementos de un sistema y la escala en la cual estos constituyen una estructura se puede definir el perfil de complejidad ( ) de un sistema ( ) como aquella función de la escala que va midiendo la información ponderada en ella. Y a partir de la información ponderada a escala se puede entender que la integral de dicha función, sobre todas las escalas, será una constante dentro del sistema (ver Recuadro 2). Se tiene de esta forma que: ( ) (* ( ) +) y, por tanto, que ∫ ( ) ( ). Recuadro 2 El perfil de complejidad, a pesar de lo complicada de su construcción formal, es una función bastante intuitiva de cómo se conectan los elementos de un sistema, estructuralmente. En ese sentido, por ejemplo, ( ) representará a la información mutua encerrada por todos los elementos individuales del sistema. Cuando el sistema esté constituido por elementos independientes y desconectados, ( ) recogerá casi toda la información mutua del sistema, es decir, la complejidad del sistema será la misma que la complejidad de cada elemento individual. Cuando, en cambio, el sistema esté constituido por elementos dependientes y sincronizados, ( ) no recogerá mucho más información que cualquier otro valor de ( ), ya que la interconectividad de sus elementos volverá redundante la observación a cualquier escala que se haga. En este caso, la complejidad del sistema, que nunca resulta muy grande, estará limitada justamente por la extrema dependencia de sus elementos. Fig. 1. Perfil de complejidad de tres tipos de sistema: desconectado, sincronizado y complejo. El sistema desconectado se caracteriza por casi no tener información mutua entre sus elementos, de modo que toda su complejidad se remite exclusivamente a la escala más pequeña, o individual. El sistema sincronizado, por el contrario, abunda en información mutua, que se observa desde cualquier escala, pero restringe fuertemente a sus estructuras de poder tener complejidad alguna. Un sistema complejo, en cambio, sacrifica parte de la libertad de sus elementos para poder conectarlos y lidiar con estímulos externos a escalas mayores que las de sus partes más básicos. El interés de reproducir los fundamentos de la teoría desarrollada en (Allen, Stacey, & Bar-Yam, 2014) proviene justamente de aplicar este formalismo al caso de los diagramas de procesos, según el modelo EPC, propuesto en (Gottschalk, van der Aalst, & Jansen-Vullers, 2008). III. Modelamiento de procesos En esta sección aplicamos el perfil de complejidad, desarrollado en (Allen, Stacey, & Bar-Yam, 2014) al modelamiento de procesos de negocio, con el objetivo de explorar qué propiedades generales pueden deducirse a partir de esta herramienta y qué características específicas podrían desarrollarse para casos particulares. Los procesos en un negocio describen al conjunto de funciones y eventos que se concatenan para que las actividades de este puedan llevarse a cabo. En líneas generales, toda actividad dentro de un negocio puede ser entendida como un proceso y estos se podrán agrupar de acuerdo al área estructural de la empresa. Los procesos pueden modelarse por medio de una red, denominada EPC, la cual consiste en una 5-tupla ( ), cuyos elementos y relaciones vendrán dados por la siguiente adaptación al planteamiento de Gottschalk et al. (Gottschalk, van der Aalst, & Jansen-Vullers, 2008): 1. Definición de un EPC. - ( ) es un EPC. - , el conjunto de eventos. - , el conjunto de funciones. - , el conjunto de conectores. - * ⨁ + es la función que mapea cada conector en un tipo, que puede ser cualquiera de los operadores lógicos AND, XOR u OR. - ( ) ( ) ( ) ( ) ( ) ( ) ( ) , es el conjunto de todos los conectores establecidos en el proceso descrito. 2. Notaciones de un EPC. - , es el conjunto de nodos del EPC. - Para cada se cumple que: o * ( ) + es el conjunto de los nodos de entrada. o * ( ) + es el conjunto de los nodos de salida. - * +, es el conjunto de conectores de convergencia. - * +, es el conjunto de conectores de divergencia. - La ruta dirigida desde un nodo hasta un nodo será una secuencia * +, tal que ( ) para todo . - El conjunto está formado por todas las rutas válidas que forman el EPC. - Definimos como el conjunto formado por todos los pares { } siempre que exista un * + tal que , * + , . - , tal que si y solo si existe un * + tal que , * + , , y * +. - , tal que si y solo si existe un * + tal que , * + , y * + - , tal que y si solo si existe un * + tal que , * + , , y * +. - , tal que si y solo si existe un * + tal que , * + , , y * +. 3. Definición de un EPC correctamente formado. Se considera que un ( ) constituye un EPC correctamente formado si satisface los siguientes requisitos: - Los conjuntos son disjuntos por pares, es decir , y . - Para cada se cumple que y . - El evento se cumple que y . - El evento final se cumple que y . - Para cada se cumple que y . - Para cada se cumple que y . - y dividen disjuntamente a , es decir mientras que . - y son necesariamente conjuntos vacíos, es decir . - y dividen disjuntamente a , es decir mientras que . Para poder proyectar el funcionamiento de un diagrama de procesos, entendido desde el formalismo EPC hacia el desarrollo teórico hecho en la sección anterior, habrá que detallar cómo se comportan sus diferentes elementos. Este comportamiento lo describimos a partir de cómo manejan la información dentro del EPC y qué tipo de conexión establece con los demás elementos. 1. Funciones: las funciones son la base de los procesos, porque relatan alguna acción que se realiza durante ellos, que necesariamente implica la incorporación de información externa —que podría entenderse, información propia—, la cual afectará en mayor o menor grado aquella información que le llega desde el evento o eventos anteriores, medie o no un conjunto de conectores entre ellos. Las funciones, por tanto, necesariamente estarán condicionadas por algún otro elemento del sistema, pero no podrán depender completamente. Esto significa que se encontrarán siempre en un punto intermedio entre la completa independencia y la completa interdependencia. 2. Eventos: los eventos, por el contrario, funcionan como hitos informativos dentro del diagrama de procesos, pues relatan una ocurrencia proveniente de aquella función o funciones inmediatamente anteriores —sea que medio o no un conjunto de conectores entre ellos—. En ese sentido, como en sí mismos no aportan información nueva, serán elementos totalmente dependientes. 3. Conectores: los conectores, finalmente, establecen el nivel de relación entre eventos y funciones consecutivas, que de una manera u otra guardan un nivel de interdependencia. La red y la EPC, tal como han sido construidas, establecen un conector tautológico —que vendría a ser el que conecta un evento con una función, o viceversa—, además de los tres conectores lógicos AND, OR y XOR. El nivel de interdependencia establecido por los conectores lógicos unirá, por tanto, una serie de eventos que, de acuerdo a lo establecido anteriormente, solo podrán arrastrar información de la función —o conjunto de funciones— previas, lo mismo que si la relación se da de manera inversa. Esto significa entonces, que toda interconectividad lógica obedecerá a una relación que tendrá, de entrada y de salida, un conjunto de funciones. A partir de ello, se construye el sistema ( ) en donde ={ } , mientras que será la función que refleje cuánta información incorpora un evento o una función al proceso en desarrollo. Un sistema definido a partir de las características descritas hasta ahora tendrá las siguientes propiedades: 1. La función recogerá toda la información que los elementos de ofrecen al diagrama de procesos. Dado que ningún evento aporta información nueva fuera de aquella ofrecida por la función inmediatamente anterior, se cumplirá que ( ) ( ) . 2. Todas las posibles dependencias irreducibles en están dadas por * + donde cada podrá tener la forma: ( ) que significa que los elementos comparten información entre sí, mientras que no comparten información con los elementos . 3. La información que los elementos del diagrama comparten a partir de su estructura de dependencia se recoge con la función , la cual se define como [referencia]: ( ) ∑ ( ) , teniendo la salvedad de que ( ) ( ) ( ) ( ) y que ( ) ( ) ( ), como se vio en la sección anterior. 4. Como hemos visto que todo evento siempre recoge la información de alguna función previa, ( ) mientras que ( ) para el resto de miembros de . 5. Que un EPC esté correctamente definido de acuerdo a las condiciones dadas anteriormente obliga a que todos los elementos ( | ) donde y algún serán necesariamente 0; lo mismo que si y algún . Esto significa que cada evento podrá depender de un subconjunto de funciones, pero no de otros eventos y que cada función podrá depender de un subconjunto de eventos, pero no de otras funciones. 6. Toda dependencia ( ) deberá cumplir que ( ) y necesariamente ( ) . 7. Las dependencias no hacen otra cosa que reflejar las conexiones que existen entre eventos y funciones, solo que en una notación diferente. Cada dependencia puede ser re-escrita a partir de establecer una función entre los elementos de y , como a su vez y se pueden construir a partir de las dependencias. 8. La información de cómo las conexiones condicionan la información entre elementos será algo que esté recogido por , mientras que la información que cada elemento aporta será recogido por . 9. En la medida en que el análisis no contemple subprocesos o macroprocesos, los elementos del sistema pueden considerarse todos de escala ( ) . Sin embargo, eso no significa que no existan estructuras con escala distinta, formadas a partir de una dependencia irreducible en el sistema. Esta escala, de estructuras como por ejemplo un conector ⨂ , no harán otra cosa que reflejar el número de elementos —eventos o funciones todos de escala 1— involucrados en el conector. 10. A partir de la escala y la información se puede definir la información ponderada por escala, la cual es una cantidad que se conserva cuando uno la mide en todo el sistema, así este cambie internamente de estructura. Esta idea es importante porque nos dará una forma de medir una cantidad global dentro del sistema, entendido como un diagrama de procesos, que podrá verificarse de acuerdo a posibles cambios internos planteados como propuesta en los procesos. Así, podrá medirse, de forma cuantitativa, si el contenido de información de los procesos cambia: aumenta o decrece, o se mantiene constante. Con todo este bagaje es posible definir el perfil de complejidad de un diagrama de procesos a partir de la función real ( ), la cual se aplica sobre la escala y todas las escalas mayores a ella, en . Así, el perfil de complejidad devuelve una serie de valores reales, correspondientes a cada valor de escala. La definición formal, como se vio antes, sería: ( ) (* ( ) +) Para aclarar mejor este punto, veamos en detalle cómo cada posible bloque con conectores lógicos puede funcionar, en su formato más sencillo (ver Recuadro 3): Recuadro 3 En este sencillo esquema representamos el bloque base a partir de un conector y un par evento-función de entrada con dos respectivos pares evento-función de salida. Se considera como par al conjunto evento-función —el cual funciona de manera idéntica si fuese función-evento— por las características de la interdependencia de estos elementos explicadas antes. Por comodidad trataremos a los pares evento-función como , para simplificar la notación. Esto da pie a verificar que la diferencia entre los tres posibles conectores viene dada solo por los valores de probabilidad, intrínsecos a cada posible que preceda a un , donde el obligará a cada ruta a ejecutarse, el XOR o ⨁ por su lado, obligará a que solo una de las dos rutas se ejecute, mientras el permitirá cualesquiera ambas opciones, situándose en los valores intermedios. Sin embargo, si consideramos que el diagrama de procesos muestra por una parte todos los posibles outcomes de este, la información del sistema debería considerar todas las posibles rutas y no solo aquellas que se ejecuten efectivamente. En ese sentido, la cuantificación de la información debería asumir todos los conectores como si fuesen AND, lo cual simplificará el entendimiento del diagrama, como veremos más adelante. IV. Resultados y discusión Hasta ahora la aplicación del perfil de complejidad a los diagramas de procesos se ha revisado desde la perspectiva teórica. Para ver la utilidad concreta de aplicar esta herramienta, será necesario revisar un par de ejemplos concretos. Estos ejemplos, aunque sencillos, servirán para dar una visión más específica de lo que se busca lograr. Proceso lineal Un proceso lineal es aquel en el cual no existen conectores lógicos, de modo que los pasos del proceso —eventos y funciones— se suceden uno tras otro sin mayor condicionamiento. En un proceso de este tipo, cada función introduce nueva información sobre aquella ofrecida por el elemento anterior, pero esta aplicación no necesariamente es conmutativa, por lo cual los procesos no serán necesariamente intercambiables. Este condicionamiento hará que no sea sencillo discernir entre un perfil dependiente o independiente, pues esto dependerá de cómo se apliquen las funciones una tras otra sobre el proceso. Proceso lineal Fig. 2. Ejemplo sencillo de un proceso donde cada función se aplica inmediatamente sobre las anteriores. En estos casos, la conectividad de los elementos es de a pares, por lo que el perfil de complejidad podrá manifestar monotonicidad. Es interesante la discusión alrededor de hacia dónde debe tender la curva del perfil de complejidad de un proceso lineal. Si esta se inclina hacia la forma de un sistema de elementos independientes significará que entre función y función consecutiva se comparte muy poca información, siendo el extremo el caso en el que no se comparta nada. Como hemos visto antes, un proceso formado por actividades donde una no le aporta nada significativo a la anterior en realidad es totalmente inútil. De hecho, de ser este el caso, cada función podría llevarse a cabo en paralelo, sobre elementos independientes, de modo que el proceso, así ejecutado, podría resolverse en mucho menos tiempo. Si, por otro lado, la curva se inclina hacia la forma que tiene un sistema de elementos totalmente dependientes significará que entre función y función no se está aportando nada, pues cada paso es, respecto a los anteriores, redundante. Este es el típico proceso en el que se pasa por muchas y consecutivas verificaciones para lograr un permiso o acceder a un trámite. En esos casos usualmente no se trata de un único operario que realiza cada función, sino de operarios distintos, que no comparten una misma base de datos y, por tanto, cada uno recoge —y aporta— la información repetida del —y al— proceso. Este tipo de procesos son, además, aquellos que más facilitan la aparición de saltos a largo de ellos, lo que en este contexto sería entendido como “corrupción estructural”. Este tipo de corrupción, reflejo muchas veces de la poca adaptación de un proceso a su realidad, puede pasar bastante desapercibida en procesos que justamente pueden ser puenteados con facilidad, sin tener un mayor efecto en el resultado del mismo (Portocarrero, 2005), (Huber, 2008). Perfil de complejidad de un proceso lineal Fig. 3. Diferentes perfiles de complejidad que podría tener un proceso lineal, de acuerdo a la manera en que se relacionan las funciones consecutivamente. En el caso de un proceso desarticulado, se tienen funciones que no se relacionan una con otra y podrían establecerse por operarios distintos y como actividades por separado. En el proceso redundante se tienen una serie de funciones que no aportan nada luego de aplicarse, después del aporte hecho por las funciones anteriores. Este es el típico caso de los procesos que consideramos “burocráticos” y son los que ofrecen la mayor oportunidad para la corrupción estructural. Los procesos balanceados son, en cambio, aquellos en los que se proporciona de manera equilibrada la información con la que contribuye cada función durante la actividad y la manera como aprovecha la información presente. Esto nos deja como intuición el que un perfil complejo sea el óptimo en los procesos lineales. Este perfil refleja un grado intermedio de interacción entre los diferentes elementos —funciones—, de modo que cada una de ellas aporta cierta cantidad nueva de información al proceso, sin estar esta totalmente desconectada de la información presente hasta el momento. Procesos condicionados por conectores XOR (Sí/No) Los conectores XOR tienen la particularidad de que obligan a ejecutar solo una de las posibles ramas que se abren desde ellos. Asimismo, si varias ramas convergen sobre un elemento XOR, este forzará a que solo uno de ellos active el conector y sea esa información la que prosiga a través del proceso. Un ejemplo de este tipo de procesos se observa en la Fig. 4. Lo convencional es que este tipo de conectores verifiquen preguntas de cumplimiento condicional (Sí/No), aunque siempre es posible tener toda una batería de alternativas y condicionales disponibles. Aquí cabe nuevamente una discusión alrededor de lo que ocurre con el conector XOR en la medida en que la dependencia de la información mutua entre los elementos que participan en este proceso da como resultado un valor totalmente contraintuitivo: la complejidad en la escala máxima del sistema se vuelve negativa. Proceso condicionado por conectores XOR Fig. 4. Ejemplo sencillo de un proceso sujeto a una pareja de conectores XOR. El conector importante que condiciona la actividad en realidad es el primero, pues este es el que establece la condición Si/No que determina cuál camino seguirá el proceso, que en este caso es ejecutado por dos operarios diferentes. Este caso es similar al que ocurre con el bit de paridad mencionado por Bar-Yam (Allen, Stacey, & Bar-Yam, 2014), en el sentido de que la información que fluye por las dos ramas alternativas del proceso es mutuamente excluyente. En ese sentido, lo que refleja el perfil de complejidad es que un proceso con conectores XOR debe manejar información necesariamente excluyente. Cuán negativo se volverá el perfil una vez llegada la escala donde se produce el conector dependerá de cuán divergente sea la información introducida en el resultado de por y . Perfil de complejidad para un proceso con conectores XOR Fig. 5. Perfiles diferentes para un proceso caracterizado por la presencia de un conector condicional XOR, el cual bifurca el proceso en dos ramas paralelas. Dependiendo de cuánta información recae sobre la función común o sobre las ramas paralelas, se tendrá un perfil de complejidad que se vuelva más o menos negativo una vez alcanzada la escala que involucra todos las funciones. Se observa que en el caso de tener una función con una carga importante en la ejecución del proceso, este se vuelve indiferente respecto a cuál rama se sigue posteriormente. El caso opuesto es aquel en el que las funciones que recorren las ramas, y , cargan con el mayor protagonismo del proceso, para lo cual se tienen dos alternativas contradictorias entre sí. El caso intermedio, nuevamente, es aquel que permite tener un manejo balanceado entre complejidad y escala. Eso permite cuantificar de una forma bastante clara cuán diferente resulta proceder por una u otra rama del proceso y, por tanto, cuán importante es el condicional establecido por el conector. En la Fig. 5 se aprecia cualitativamente esta diferencia. En un proceso en el cual la primera función —previa al conector condicional— juega el papel más importante en el desarrollo, la bifurcación del proceso no agregará mucha información al resultado del mismo, por lo que el manejo simultáneo de la información de las dos ramas no será muy contradictoria. En este caso, el proceso tiene una división casi irrelevante y se considera que las ramas son, por ello, indiferentes. El otro extremo lo constituye un proceso en el cual cada rama del condicional ofrece la mayor cantidad de información en el desarrollo del mismo. En este caso lo que se observa es que los procesos pueden considerarse casi independientes y las acciones previas al condicional son casi decorativas, pues es muy poca la información que se maneja dentro del proceso antes de llegar a este. Aquí, nuevamente, el proceso balanceado será aquel que compense la información que se distribuye a través de las diferentes funciones de este. En ese sentido se trata de un proceso en el cual se sacrifica poca complejidad a cambio de extender ligeramente la escala, hasta cierto límite, luego del cual la información se vuelve contradictoria. Proceso condicionado por conectores AND (y OR) El tercer caso a explorar lo constituye el de los conectores AND, pues estos requieren necesariamente la ejecución de todas las ramas involucradas en el proceso para que este se lleve a cabo. Proceso condicionado por conector AND y OR Fig. 6. Ejemplo sencillo de un proceso donde aparecen un conector AND de divergencia y un conector OR de convergencia. Este último podría ser también un conector AND y el resultado del análisis sería el mismo, pues solo se alteraría la simultaneidad de la ejecución de con la información de y . Es cierto que no tiene por qué arrojar el mismo resultado sea que reciba una, otra o ambas secuencias, pero aquí no nos interesa el resultado concreto en sí de esa parte del proceso, sino la manera como esta ha sido condicionada. El conector lógico OR puede aparecer, por ejemplo, como conector de convergencia y el tratamiento será equivalente al caso del conector AND, puesto que la diferencia con este estará solo en la simultaneidad de la utilización de la información proveniente de las dos ramas. No es el caso en el cual este conector sea de divergencia, pues esto remitirá a lo desarrollado en la sección anterior. Este caso es de peculiar importancia en el análisis de un diagrama de procesos en la medida en que la superposición de información que se presenta ahora funcionaría a la inversa de cómo se presentó en la sección anterior. El hecho de que el conector AND fuerce a ejecutar todas las ramas involucradas y que el resultado final implique tener —simultáneamente o no— la aplicación de ambas funciones y necesariamente indica que se trata de un patrón que sería imposible de observar a una escala menor a aquella que implique tener a todos los elementos articulados en la estructura. En otras palabras, la información que se obtiene de todo el sistema será observable solo a la escala más alta, pero no será deducible ni observable a partir de las escalas más bajas. Y tampoco se podrá obtener de manera aislada evaluando cada elemento, puesto que sería necesario realizar la operación lógica con ellos y operar la última función al resultado. Esto es justamente lo que se conoce como proceso emergente del tipo 2, o proceso emergente fuerte. De acuerdo a Bar-Yam (Bar-Yam Y. , A Mathematical Theory of Strong Emergence Using Multiscale Variety, 2004), los procesos emergentes del tipo 2 son aquellos que implican observar un sistema a partir de cierta escala, para poder observar un patrón de comportamiento en ellos. Perfil de complejidad para un proceso con conector AND Fig. 7. Perfil de un proceso que se caracteriza por la presencia de un conector AND, que obliga a este a ejecutarse a través de todas sus ramas posibles. Este requerimiento hace que cierta información solo sea obtenible a partir de ciertas estructuras que aparecen a escalas mayores a la individual. Dado que este patrón no es obtenible desde la información de los elementos por separado, se entiende este comportamiento como un proceso emergente. Esto, fuera de que luego, en escalas mayores, dicho patrón se vuelva redundante o contradictorio. Este tipo de procesos en los que aparecen patrones emergentes del tipo 2 abundan especialmente en la naturaleza, en sistemas biológicos y sociales, o en cualesquiera sistemas físicos con comportamiento no-lineal, como por ejemplo, aquellos donde se producen transiciones de fase. Es interesante observar, además, que dentro de este mismo sistema, más que ocurrir solamente un incremento en su complejidad a partir de cierto valor de la escala, se producen además dos caídas de esta, respectivamente en las escalas 2 y 4, es decir, las intermedias a aquella donde se alcanza el máximo. Esto ocurre porque todos los patrones del diagrama de procesos están condicionados a hasta tres elementos, de modo que la incorporación del cuarto, aunque no resulta contradictoria, tampoco cambia el patrón global, puesto que la información que adiciona no es condicional. Esta oscilación también se observó en el caso anterior, aunque ahí se resaltó el efecto negativo del conector condicional excluyente. Esta presentación de tres modelos sencillos de diagramas de procesos obedece a la intención de mostrar cuáles son los posibles resultados de aplicar el perfil de complejidad a los “bloques básicos” con los cuales se podría elaborar cualquier diagrama de procesos en general. Una de las características del perfil de complejidad es que es trata de una función que tiene aditividad. Esto queda más claramente entendido si se desarrolla matemáticamente la idea: ( ) ( ) ( ), siempre que En ese sentido, en la medida en que todo proceso puede descomponerse en subprocesos lineales o subprocesos formados por un conector AND o XOR —ya que el OR funciona como uno u otro, a partir de la probabilidad marcada por la función que lo preceda—, cualquier diagrama de procesos tendrá un perfil de complejidad estructurado a partir de unir, aditivamente, los perfiles mostrados aquí. V. Conclusiones En el presente artículo se ha aplicado el formalismo del perfil de complejidad al estudio de los procesos en un negocio, a partir del esquema del Event-driven Process Chain. La idea de apelar a este esquema proviene de que este define un formalismo matemático elegante para modelar los procesos de negocio, por medio de un diagrama que es fácilmente entendible y donde se puede proyectar sin dificultades la teoría desarrollada alrededor del perfil de complejidad. Se ha encontrado que dentro del formalismo EPC es posible diferenciar entre los elementos conocidos como evento y función, según la redundancia de información que estos ofrecen según como se relacionan con sus elementos consecutivos. Así, lo primero que se estableció es que la información mutua ( ) siempre será 0, excepto para un específico, para el cual la información mutua será 1. Por otro lado, se encontró también que la diferencia entre conectores lógicos estriba básicamente en la probabilidad con que estos fuerzan a tomar un camino u otro dentro del diagrama de procesos, lo que permite entender al conector AND como un generador de patrones dentro del sistema y al conector XOR como uno de información contradictoria, siempre que se empiece a medir la información mutua de las estructuras a partir de cierto nivel de escala. Se ha presentado precisamente cómo es que el perfil de complejidad varía en tres casos sencillos, modelados a partir de los posibles subprocesos que pueden aparecer en cualquier diagrama de procesos y a partir de la propiedad de aditividad del perfil de complejidad. El primero de estos casos es el de un proceso lineal, en el cual las funciones se aplican consecutivamente una después de otra. Aquí, las posibilidades para el perfil constituyen las que se observan en un sistema con elementos conectados entre sí por pares: el perfil es monotónico y decreciente. Dependiendo de cuánta información comparten los elementos, se tendrá un perfil con una tendencia hacia un sistema desarticulado —cuando los elementos son casi o totalmente independientes—, una tendencia hacia un sistema redundante — cuando los elementos son casi o totalmente dependientes—, y un sistema balanceado, en el caso en el que cierta independencia es sacrificada para ganar el escalamiento de la complejidad. Este tipo de sistemas, usualmente entendidos como complejos, son capaces de ofrecer diferentes tipos de respuesta a diferentes escalas y pueden, por eso, adaptarse al entorno. En el caso de un negocio, esto refleja simplemente un proceso con la suficiente capacidad de manejar la información adecuada a través de su ejecución. En el segundo y tercer caso se presentaron procesos donde aparecen conectores AND y XOR. En ambos casos el perfil se vuelve oscilante. Cuando el conector es del tipo condicional excluyente, el decremento en la complejidad va hasta valores negativos de esta, lo que refleja que la información mutua de las estructuras involucradas se vuelve contradictoria. En el caso del conector aditivo, por el contrario, existe un incremento en la complejidad observada, a partir de cierta escala de las estructuras, lo que refleja la aparición de patrones —entendidos como procesos emergentes—, que no podrían ser deducidos u observados mediante el manejo individual de sus elementos constituyentes, salvo que se realizaran las operaciones lógicas involucradas en las estructuras mayores. Con esto es posible mejorar el análisis que se hace actualmente de la estructura de los procesos cuando se busca optimizarlos en un negocio. Hay varias direcciones hacia las cuales se pueden encaminar futuros estudios de este tema. Por un lado, la manera cómo se cuantifica el efecto de cada función sobre los outcomes de las funciones anteriores, la manera cómo se proyecta la función y la estructura de dependencias, desde las cuales se calculan y obtienen la información mutua y el valor cuantitativo del perfil de complejidad. —Enero, 2015— VI. Bibliografía Allen, B., Stacey, B. C., & Bar-Yam, Y. (2014). An Information-Theoretic Formalism for Multiscale Structure in Complex Systems. arXiv:1409.4708. Ashby, W. R. (1958). Requisite variety and its implications for the control of complex systems. Cybernetica, 1(2), 83-99. Bar-Yam, Y. (1997). Dynamics of Complex Systems. Reading, Massachusetts: Addison-Wesley. Bar-Yam, Y. (2004). A Mathematical Theory of Strong Emergence Using Multiscale Variety. Complexity, 9(6), 15-24. Bar-Yam, Y. (2004). Multiscale Complexity / Entropy. Advances in Complex Systems, 7, 47-63. Bar-Yam, Y. (2004). Multiscale Variety in Complex Systems. Complexity, 9(4), 37- 45. Bar-Yam, Y. (2006). Engineering Complex Systems: Multiscale Analysis and Evolutionary Engineering. En Y. Bar-Yam, D. Braha, A. Minai, & Y. Bar-Yam (Edits.), Complex Engineered Systems (págs. 22-39). Berlin: Springer. Bar-Yam, Y., Harmon, D., & Bar-Yam, Y. (2013). Computationally Tractable Pairwise Complexity Profile. Complexity, 8(5), 20-27. Binder, P.-M., & Plazas, J. A. (2001). Multiscale anaylsis of complex systems. Physical Review E, 63(065203), 1-4. Gershenson, C. (2011). The Sigma Profile: A Formal Tool to Study Organization and its Evolution at Multiple Scales. Complexity, 16(5), 37-44. Gershenson, C. (2014). Harnessing Complexity of Education with Information Technology. Complexity, 1-5. Gershenson, C. (2014). Requisite Variety, Autopoiesis, and Self-organization. arxiv.org/1409.7475, 1-8. Gheorghiu-Svirschevski, S., & Bar-Yam, Y. (2004). Multiscale analysis of information correlations in an infinite-range, ferromagnetic Ising system. Physical Review E, 70(066115), 1-11. Gottschalk, F., van der Aalst, W. M., & Jansen-Vullers, M. H. (2008). Merging Event- driven Process Chains. Lecture Notes in Computer Science, 5331, 418-426. Huber, L. (2008). Romper la mano. Lima: Instituto de Estudios Peruanos (IEP). Metzler, R., & Bar-Yam, Y. (2005). Multiscale complexity of correlated Gaussians. Physical Review E, 71(046114), 1-11. Portocarrero, F. (2005). ima eru ed ara el esarrollo de las iencias ociales en el eru Shiner, J., Davison, M., & Landsberg, P. (1999). Simple measure for complexity. Physical Review E, 59(2), 1459-1464.