En varios documentos previos [1, 2, 3] hemos mostrado que todos los procesos comparten una arquitectura com�n. Aqu� el t�rmino arquitectura se utiliza para denotar la existencia de estructuras de componentes, las cuales incluyen tipos de componentes, relaciones gen�ricas entre ellos y rol de los mismos. Una arquitectura es tambi�n un espacio de posibilidades que permite la derivaci�n de dise�os particulares, a partir de su estructura y filosof�a, siguiendo reglas bien definidas.

La arquitectura que proponemos es normativa, en el sentido de que los componentes, relaciones y roles que definimos a continuaci�n son los que deber�a tener cualquier proceso para cumplir con su prop�sito.

Como ya dijimos, un proceso es un conjunto de actividades �ntimamente interrelacionadas que existen para generar un bien o servicio, el cual tiene un cliente interno o externo a la empresa en que opera. De aqu� se puede observar que un elemento fundamental de cualquier proceso es el producto o servicio que genera; por ejemplo: un producto manufacturado entregado a un cliente externo, un servicio financiero provisto por un banco, un servicio de vuelo provisto por una l�nea a�rea, un servicio de selecci�n de personal realizado internamente en una empresa a un �rea que lo solicita, las especificaciones y prototipo de un nuevo producto realizados a pedido de gerencia, una campa�a de marketing generada a petici�n de la gerencia comercial, etc.

Las actividades que participan en el proceso de generaci�n de un producto o servicio se pueden diferenciar en dos clases: una que contiene las actividades que est�n claramente asociadas a la transformaci�n de ciertos insumos en el producto o servicio final y otra que incluye las actividades que dirigen o regulan la transformaci�n. Esta distinci�n es muy clara en empresas productivas. Por ejemplo, en la manufactura de muebles se toma como materia prima a la madera en bruto y por medio de varias operaciones de transformaci�n y ensamblaje se generan mesas, sillas, etc., siendo tales actividades dirigidas por otras –que podemos llamar de gesti�n– que determinan cu�ndo comprar materias primas, qu� producir con ellas, cu�ndo despachar productos terminados, etc. La diferenciaci�n es claramente entre actividades ejecutantes que manejan recursos econ�micos –materiales, dinero, personal, bienes de capital– para producir un bien o servicio y actividades de toma de decisiones que dirigen o regulan, insumiendo y generando informaci�n.

En actividades de servicios es m�s dif�cil visualizar la diferenciaci�n anterior, pero sin embargo existe. Por ejemplo, el proceso de manejo financiero de una empresa, que es un servicio, el cual opera para asegurar la disponibilidad de recursos monetarios en ella, transforma recursos disponibles como cuentas por cobrar, l�neas de cr�dito y otras fuentes de financiamiento en pagos a los proveedores, empleados, y otros factores. Para que ello ocurra existen actividades de gesti�n que deciden acerca de pol�ticas y acciones de cobranza, selecci�n de opciones de financiamiento y a qui�n pagar. Asimismo, en un proceso de cr�dito hipotecario en un banco, la transformaci�n consiste en tomar documentos –escrituras, t�tulos, tasaciones, estado de situaci�n del cliente, etc., que pueden considerarse como recursos de informaci�n– y generar pagar�s, letras y escrituras que formalizan el cr�dito. En este caso tambi�n existen actividades de gesti�n que deciden si otorgar cr�dito o no, montos asociados y condiciones. Por �ltimo, un servicio de atenci�n en un hospital "transforma" un paciente enfermo en, idealmente, un paciente sano, insumiendo varios recursos, como medicinas, pabellones, etc. Aqu� las actividades de toma de decisiones son el establecer los tratamientos m�s adecuados, de acuerdo a un diagn�stico, asignar recursos disponibles para los tratamientos y "rutear" al paciente.

La trascendencia de la distinci�n entre actividades de manejo o transformaci�n de recursos y actividades de gesti�n o toma de decisiones es que las primeras son el fin �ltimo de tal proceso: en ellas se aporta valor al producto del mismo y all� se puede medir si se cumplen o no sus objetivos. Por otro lado las actividades de gesti�n son un medio para conseguir que el manejo o transformaci�n ocurra de la mejor manera posible.

Otra consecuencia importante de la distinci�n se�alada es que para poder gestionar se requiere conocer el estado de las actividades de transformaci�n de recursos. En situaciones simples, tal estado se conoce de manera trivial; por ejemplo, en un supermercado la venta o no venta se determina por la disponibilidad en estanter�a y en un taller peque�o la fabricaci�n de un producto se decide observando la disponibilidad de materia prima in situ. Pero en empresas de alguna magnitud, existe un tercer grupo de actividades que existen s�lo para registrar e informar sobre el estado de las actividades de transformaci�n. La m�s tradicional de estas actividades, que existe en todas las empresas, es la contabilidad. Esta se encarga de registrar y procesar todas las transacciones asociadas al manejo del dinero para informar el estado financiero de la empresa: activos circulantes en bancos, cuentas por cobrar y otros, pasivos circulantes en cuentas por pagar y deudas de corto plazo, otros activos y pasivos, p�rdida o utilidad, etc. Este estado alimenta una serie de decisiones o acciones de gesti�n que act�an sobre el manejo monetario; por ejemplo, activar cobranza, pedir un pr�stamo, pagar a un proveedor.

Figura 2.1. Arquitectura general de un proceso

Todo lo dicho puede resumirse en el modelo gr�fico de la Figura 2.1. En ella se muestran los tres grandes grupos de actividades, representados como funciones gen�ricas en la forma de rect�ngulos. Entre ellas existen tambi�n flujos de informaci�n gen�ricos que implementan las relaciones descritas en la definici�n de actividades. As�, Actividades de Gesti�n recibe Informaci�n estado de Mantenci�n estado y genera Instrucciones acci�n hacia Producci�n y provisi�n bien o servicio. El ciclo se cierra al fluir informaci�n de Cambios de estado desde las funciones de gesti�n y producci�n a Mantenci�n estado.

Existe una serie de otros flujos que completan el modelo: un flujo de Entradas f�sicas que se transforma en el Bien o servicio al cliente; Requerimientos e informaci�n de clientes, que inicia la satisfacci�n de una necesidad o la contestaci�n a una consulta, lo cual genera Informaci�n a clientes y/o Instrucciones acci�n; Flujo de informaci�n entre actividades, que representa el hecho de que, en un caso espec�fico, pueden existir muchas actividades diferentes de gesti�n y �stas interactuar por medio de flujos de informaci�n; Flujo de productos o servicios entre actividades producci�n, lo cual se�ala la posible existencia de varias de estas actividades y su interrelaci�n por medio de flujos f�sicos, diferentes de informaci�n; Flujo de informaci�n entre actividades producci�n, que se�ala lo mismo que lo anterior, pero para flujos de informaci�n; Necesidades e Informaci�n y control, flujos que permiten que las actividades de producci�n soliciten recursos a las de gesti�n y entreguen informaci�n directa –no mediada por Mantenci�n estado– para efectos de la verificaci�n del cumplimiento de las acciones solicitadas; Informaci�n de otros procesos e Informaci�n a otros procesos, flujos que toman en cuenta la interacci�n entre un proceso con los otros que existen en la empresa; y Otros recursos, que representan el uso de medios que facilitan la ejecuci�n de las tareas de la funci�n, como infraestructura, sistemas computacionales, etc.

El modelo reci�n presentado est� dibujado utilizando una t�cnica de diagramaci�n que se conoce como IDEF0. En ella las flechas de flujo tienen una interpretaci�n diferente dependiendo de la manera que ingresan a una caja o salen de ella. As�, las flechas que entran o salen horizontalmente a una caja corresponden al concepto habitual I/O: algo entra para transformarse en una salida; las flechas que entran verticalmente desde arriba son flujos de control, que dirigen, restringen e instruyen a las actividades de una funci�n, entregando pol�ticas, reglas, decisiones espec�ficas, etc.; y las flechas horizontales, que ingresan desde abajo, son recursos que apoyan una funci�n, pero no son parte de la transformaci�n I/O.

Como ya dijimos, el modelo presentado es una arquitectura gen�rica, a partir de la cual pueden dise�arse instancias que representan situaciones o procesos espec�ficos. Como arquitectura provee, entonces, un espacio de posibilidades, en cuanto a que las funciones y flujos presentados pueden dar origen a muchas instancias diferentes. Sin embargo, cualquier instancia debe respetar la "filosof�a" del modelo que indica claramente c�mo debe derivarse; en particular debe respetarse la estructura de componentes y relaciones.

2.2-. Patrones de procesos

Al aplicar la arquitectura gen�rica presentada en un dominio dado –entendi�ndose por �ste una cierta situaci�n caracter�stica abstra�da de muchos casos de la vida real– se pueden generar patrones de procesos. Estos son especies de modelos de referencia que se�alan c�mo deber�a ser la estructura y funcionamiento de toda una clase de procesos que caen bajo el dominio en cuesti�n. Por ejemplo, se podr�a establecer un patr�n de proceso para el dominio de desarrollo de nuevos productos o servicios; esto significa que generamos un modelo general de proceso que puede servir como referencia para dise�ar un proceso espec�fico para un caso particular dentro del dominio.

Para efecto de definir patrones de procesos en cualquier organizaci�n de una manera ordenada, partimos de una clasificaci�n propuesta por este autor [7] que los agrupa en cuatro grandes macroprocesos. La idea de un macroproceso es que agrega varios procesos interrelacionados que en algunos casos podr�an tomarse en conjunto, pero que, en otros, pueden abordarse en forma independiente. Los macroprocesos son:

1. Planificaci�n del negocio
2. Desarrollo de nuevos productos y servicios
3. Gesti�n, producci�n y provisi�n bien o servicio
4. Procesos de apoyo: financieros, RR.HH., infraestructura, etc.

La idea fundamental de la arquitectura del punto anterior es que el patr�n para cada uno de estos macroprocesos puede derivarse a partir de ella. Para ilustrar esta idea, nos centraremos en el Macroproceso Gesti�n, producci�n y provisi�n bien o servicio, generando su correspondiente patr�n.

Por supuesto, la arquitectura s�lo sirve como gu�a para identificar componentes, relaciones y roles y debe ser complementada con el conocimiento del dominio. Esto significa conocer un n�mero significativo de casos reales que aborden el tema del dominio en diversos contextos. En nuestro caso, el patr�n que se presentar� a continuaci�n se basa en varias decenas de casos nacionales y algunos internacionales documentados en la literatura, en �mbitos tan diferentes como manufactura, distribuci�n y servicios privados y p�blicos de variados tipos.

Es imposible describir el proceso de creaci�n de un patr�n, que necesariamente se desarrolla por aproximaciones sucesivas, lo cual incluye su validaci�n con casos no considerados en su planteamiento. Sin embargo, podemos adelantar que el que proponemos a continuaci�n ha sido utilizado extensivamente en casos totalmente diferentes a los originalmente conocidos, concluy�ndose su total aplicabilidad. Particularmente interesante es la aplicaci�n y validaci�n con el proceso de atenci�n de pacientes en un hospital, situaci�n que se tratar� en detalle m�s adelante.

Figura 2.2. Macroproceso Gesti�n, Producci�n y Provisi�n Bien o Servicio

El patr�n de proceso para el macroproceso se�alado se muestra en la Figura 2.2. El est� hecho siguiendo la arquitectura general de la Figura 2.1, vale decir identificando c�mo los elementos de ella se materializan en este caso particular. Concretamente, observamos que la funci�n Mantenci�n estado permanece inalterada en el patr�n; la funci�n Producci�n y provisi�n bien o servicio se transforma en Producci�n y entrega bien o servicio; y las Actividades de gesti�n producen tres instancias espec�ficas: Administraci�n relaci�n con el cliente, Administraci�n relaci�n con proveedores y Gesti�n producci�n y entrega. En cuanto a las relaciones por flujos es f�cil darse cuenta que los flujos de la arquitectura gen�rica tienen instancias en el patr�n de proceso.

No intentamos aqu� una descripci�n detallada de los elementos del patr�n, ya que no es dif�cil entenderlos dentro de su contexto. A cambio, damos una explicaci�n general de c�mo "funciona" el patr�n. Todo empieza con un evento que genera el flujo Requerimiento e informaci�n mercado. Este puede gatillar varias respuestas:

• Si es un requerimiento espec�fico se traspasa tanto a Gesti�n producci�n y entrega, para establecer c�mo se va a satisfacer, como a Administraci�n relaci�n proveedores, en el caso de que haya que adquirir alg�n elemento necesario para la satisfacci�n.
• Un pron�stico, que tambi�n se traspasa a las funciones reci�n mencionadas, cuando hay necesidad de anticiparse a demandas futuras.
• Si es una petici�n de informaci�n de un cliente, se genera la Informaci�n al mercado, la cual puede incluir tambi�n informaci�n espont�nea a los clientes acerca de la oferta de la empresa.
• En cualquier caso, todas las acciones realizadas en relaci�n a un cliente quedan registradas en Mantenci�n estado por medio del flujo Cambios de estado.

Para generar todas las respuestas anteriores, Administraci�n relaci�n con el cliente cuenta con el recurso Informaci�n estado, que le permite saber en todo momento la situaci�n de carga de la actividad producci�n, para determinar la posibilidad y fecha de satisfacci�n de un requerimiento y el estado de procesamiento de un requerimiento. Asimismo cuenta con Otros recursos, necesarios para desarrollar su tarea, y ve dirigida su acci�n por Planes que vienen de otros macroprocesos.

El proceso sigue con Administraci�n relaci�n con el proveedor, el cual se preocupa de interactuar con proveedores para conseguir los factores constitutivos del producto o servicio. Este es m�s relevante cuando el producto o servicio se genera en forma particular para un cierto requerimiento; por ejemplo, un proyecto de consultor�a que se arma recurriendo a especialistas externos a la empresa que se contratan s�lo para el mismo.

A continuaci�n, Gesti�n producci�n y entrega, a partir de Requerimientos productos o servicios y pron�stico, genera un Plan e instrucciones producci�n y entrega que le indica a la funci�n Producci�n y entrega bien o servicio qu�, c�mo y cu�ndo producir y entregar. Tambi�n genera, esta funci�n, Ideas cambio productos y procesos producci�n que van a ser evaluadas como posibles mejoras por otros macroprocesos. Asimismo, entrega a Administraci�n relaci�n con proveedores necesidades de insumos y otros factores necesarios para llevar los planes de producci�n a la pr�ctica. Esta funci�n informa tambi�n los Cambios de estado y se auxilia en todo momento de la informaci�n que Mantenci�n estado genera respecto a la situaci�n de los requerimientos, la producci�n y la entrega. Cuenta, tambi�n, con Otros recursos y ve su acci�n dirigida por Planes y Nuevos productos y servicios, provenientes de otros macroprocesos.

Producci�n y entrega bien o servicio satisface las necesidades de los clientes, generando los Productos y servicios al mercado a partir de Insumos y otros recursos proveedores, cumpliendo con las instrucciones provenientes de Gesti�n Producci�n y entrega, y respetando indicaciones de Nuevos productos y servicios. Se apoya en Informaci�n de estado –requerimientos, planes de producci�n, etc.– y Recursos productivos necesarios para desarrollar su labor. Informa de cualquier cambio de estado en la producci�n y entrega a Mantenci�n estado y de Necesidades e informaci�n control, a Administraci�n relaci�n con proveedores –necesidades puntuales de insumos, por ejemplo– y Administraci�n relaci�n con el cliente –situaci�n espec�fica de un requerimiento, por ejemplo.

Por �ltimo, Mantenci�n estado registra la situaci�n de todas las entidades que intervienen en el proceso: clientes, requerimientos de �stos, proveedores, relaciones con �stos, recursos productivos, etc. Tambi�n recibe informaci�n de otros procesos –por ejemplo, situaci�n de cuenta corriente de un cliente, del proceso de manejo financiero– y entrega informaci�n a ellos –por ejemplo, informaci�n para facturar un requerimiento ya satisfecho.

Como ya dijimos, el patr�n de proceso descrito establece c�mo un proceso espec�fico "deber�a" ser estructurado. Al nivel de detalle que hemos presentado, algunos aspectos significativos que norman un dise�o espec�fico son los siguientes.

Debe hacer una mantenci�n consolidada o integrada –obviamente con apoyo computacional– del estado de todas las entidades relevantes al proceso y este estado debe estar disponible –posiblemente en l�nea– para el resto de las funciones participantes del proceso. Esto aterriza la idea de integrar proceso con tecnolog�a y asegura que la actuaci�n de cada una de las funciones es congruente con una visi�n global del estado en que encuentra el proceso y no se basa en visiones funcionales parciales t�picas de la burocracia-funcional.

Otro aspecto normativo importante es que el proceso funciona a base de anticipaci�n, en vez de responder a las presiones del minuto. Esto se ve reflejado en que existe un pron�stico de requerimientos y que se trabaja a base de planes de producci�n y entrega.

Adem�s, integra en un s�lo proceso las relaciones con el cliente y los proveedores, junto con la producci�n y entrega y su gesti�n, lo cual hace posible coordinar actividades que, en algunos casos, es vital que funcionen en sincron�a –por ejemplo, en producci�n a pedido tanto industrial como en servicios–, lo cual rara vez se da en la pr�ctica.

Figura 2.3. Detalle de Administraci�n Relaci�n el Cliente

Por supuesto, el patr�n de proceso puede detallarse para llevarlo m�s cerca todav�a de procesos espec�ficos, lo que significa que vamos acotando las posibilidades de especializaci�n. As�, en la Figura 2.3, se muestra una descomposici�n o mayor detalle de la funci�n Administraci�n relaci�n con el cliente. Notamos que las actividades de detalle se hacen m�s espec�ficas y, nuevamente, aparece el elemento normativo en cuanto a dise�os espec�ficos de estructura y relaciones. As�, por ejemplo, aparece Marketing y an�lisis mercado como una actividad fundamental que inicia acciones –Informaci�n al mercado–, genera requerimientos, y, asimismo, est� permanentemente analizando el comportamiento de �stos para tomar medidas correctivas cuando sea inadecuado; por ejemplo, si

bajan las ventas, iniciar campa�as de marketing. Tambi�n es importante la aparici�n de la funci�n Decidir satisfacci�n requerimientos, la cual formaliza ciertas actividades que ocurren en varias unidades de una empresa y que participan en la decisi�n de si procesar o no un requerimiento. Tambi�n es resultado de experiencias con buenas pr�cticas, que, al tomar esta decisi�n, se tenga a la mano toda la informaci�n de estado del cliente y de las actividades de producci�n, para que ella tenga base en cuanto a que el cliente es confiable y que se va a poder satisfacer responsablemente su necesidad. Por �ltimo, cabe mencionar que en

Ventas y atenci�n al cliente, cualquier consulta del cliente va a tener una respuesta precisa, por contarse en todo momento con el Estado de procesamiento requerimientos.

Figura 2.4. Detalle de gesti�n, producci�n y entrega

Siguiendo con el detalle del macroproceso, en la Figura 2.4, se entrega la descomposici�n de la actividad Gesti�n producci�n y entrega. En ella aparece la funci�n Implementaci�n nuevos productos y servicios, la cual crea las condiciones para ejecutar las nuevas ofertas de la empresa; Planificaci�n y control producci�n, que lleva a la pr�ctica la idea fundamental de adelantarse a los requerimientos de los usuarios, tanto en el uso de las instalaciones productivas como en necesidades de insumos, para lo cual cuenta con informaci�n de estado que analiza el comportamiento hist�rico de la demanda e incluye las proyecciones de requerimientos de Marketing y an�lisis de mercado; y Decidir entrega producto o servicio, que es la encargada de programar el detalle de la satisfacci�n de los requerimientos de los clientes.

Figura 2.5. Detalle de Producci�n y entrega bien o servicio

Por �ltimo, en la Figura 2.5, se muestra el detalle de Producci�n y entrega bien o servicio, que corresponde a las actividades "f�sicas" de ejecutar el requerimiento del cliente, las cuales se pueden clasificar en producci�n y entrega.

Todas las actividades y los flujos del modelo presentado pueden describirse de una manera m�s formal por medio del uso de un diccionario, lo cual es tambi�n apoyado por el software utilizado para confeccionar los modelos. En el caso de las actividades, el diccionario puede llegar a incluir la l�gica del negocio que rige el desarrollo de una actividad y, en el caso de los flujos, los atributos que determinan los datos que intercambian las actividades. Por supuesto un modelo general como el Macro1, cuyo diccionario se encuentra en el Anexo 1, no puede tener un grado de detalle extremo de precisi�n, ya que intenta representar muchos procesos espec�ficos en dominios muy diferentes. Sin embargo, ya a este nivel de generalidad, es posible, por ejemplo, identificar atributos asociados a varios de los flujos, particularmente aquellos que apoyan con informaci�n de estado a las actividades. Al especializar un patr�n, como lo detallaremos en la pr�xima secci�n, se va precisando la l�gica y los atributos para dominios y situaciones espec�ficas.