Los patrones se pueden aplicar en casos espec�ficos partiendo de un dominio o subdominio que incluya el caso en cuesti�n. Obviamente, si se parte de un subdominio, por ser �ste m�s espec�fico, el trabajo ser� m�s directo.

La aplicaci�n se centra en detallar o dise�ar una serie de aspectos que discutimos a continuaci�n.

4.1-. Pr�cticas de trabajo

Cada una de las actividades del patr�n debe caracterizarse entregando la pr�ctica espec�fica de trabajo que se propone para realizarla. Dependiendo del caso, esto puede ir desde una rutina o algoritmo totalmente estructurado –implementada parcial o totalmente con apoyo computacional– hasta s�lo una descripci�n general de lo que se espera de la actividad, quedando los detalles al criterio de la persona que la ejecuta.

Consideremos como ejemplo de situaci�n altamente estructurada, el proceso de cr�dito hipotecario especificado en 3.3 y, en particular, la actividad An�lisis preliminar de la Figura 3.13. Esta puede llevarse a una automatizaci�n casi total, por medio de especificar un algoritmo de evaluaci�n. El algoritmo debe incluir las variables a considerar en tal evaluaci�n; por ejemplo –tomando, para simplificar, el caso de cr�dito hipotecario a particulares– el ingreso de la persona, su deuda con el sistema financiero, los bienes que posee –autos, propiedades, etc.–, el tama�o de su grupo familiar, etc. Adem�s debe indicar reglas y criterios asociados a variables o combinaciones de variables que determinan si el cr�dito es viable o no^*; por ejemplo:

Regla 1: El ingreso l�quido de la persona debe ser mayor a un monto dado.

Regla 2: El servicio mensual de su deuda con el sistema financiero no debe sobrepasar un porcentaje dado del ingreso l�quido.

Regla 3: El dividendo proyectado para el cr�dito no debe sobrepasar un porcentaje dado del ingreso l�quido, el cual depende del tama�o del grupo familiar.

El algoritmo combina estas y otras reglas en un procedimiento l�gico que puede ser implementado computacionalmente y constituye lo que tambi�n se denomina l�gica del negocio. Entonces la pr�ctica de trabajo queda descrita de la siguiente manera.

Con la informaci�n del cliente debidamente recolectada por Entrega de informaci�n y solicitud de antecedentes, ya ingresada al sistema computacional en Mantenci�n estado y que se alimenta a An�lisis preliminar por medio de Estado prospectos y clientes, el responsable de esta �ltima actividad invoca un sistema computacional de apoyo que ejecuta el algoritmo anteriormente descrito y le entrega una conclusi�n respecto a la viabilidad de cr�dito. El responsable procede a revisar que todos los antecedentes utilizados sean los apropiados y a verificar la correcci�n general de la conclusi�n respecto del cr�dito, la cual se informa al cliente. Adem�s actualiza como cambio de estado la conclusi�n final y rutea la carpeta f�sica o electr�nica al que sigue en el proceso.

El ejemplo anterior puede representarse gr�ficamente como se muestra en la Figura 4.1. Esta implica que se ha optado por una carpeta f�sica con papeles.

Figura 4.1. Especializaci�n de An�lisis preliminar

N�tese que el dise�o propuesto en la Figura 4.1. implica una cierta arquitectura computacional, que consiste en una base de datos central en Mantenci�n estado y una ejecuci�n, posiblemente descentralizada –al estilo cliente/servidor–, de un programa que, utilizando los datos de la base de datos, ejecuta un algoritmo que apoya la evaluaci�n del cr�dito. Tambi�n podr�a haberse propuesto una arquitectura alternativa con todo centralizado y un terminal "tonto" de apoyo a la actividad o una arquitectura tambi�n centralizada con un servidor Web y un browser como interfaz de apoyo a la actividad.

El dise�o propuesto tambi�n deja perfectamente definidos los requerimientos que se desprenden de esta actividad para la base de datos de Mantenci�n de estado, que son los valores de las variables (atributos) que se consideran en el algoritmo para cada uno de los clientes que solicitan cr�dito, los cuales precisan el contenido del flujo Estado prospectos y clientes.

Como ejemplo de pr�ctica de trabajo en casos no estructurados, consideremos Tasar bien a hipotecar de la Figura 3.15. En este caso, en vez de dise�ar un procedimiento detallado de c�mo tasar, se conf�a en el conocimiento y experiencia de un experto y s�lo se le indica que el valor tasado debe reflejar el precio de venta en el mercado de la propiedad en cuesti�n.

4.2-. Coordinaci�n entre actividades

La coordinaci�n entre actividades de un proceso se establece en varias partes del mismo.

En primer lugar hay actividades cuya misi�n es coordinar. Estas tienen que ver con asegurar –en el contexto de Macro1– que los requerimientos por bienes y/o servicios se satisfacen con los recursos disponibles. T�picamente, son actividades que caen bajo el concepto de Gesti�n producci�n y entrega de Macro1 (Figura 2.2). M�s concretamente tiene que ver con la Planificaci�n y control de producci�n del mismo proceso. Las pr�cticas de trabajo que uno defina para estas actividades afectar�n de manera fundamental la calidad del servicio que se le entrega al cliente. Por ejemplo, volviendo a cr�dito hipotecario, consideremos Asignar requerimientos de la Figura 3.15. Si elegimos una pr�ctica en la cual la asignaci�n es impl�cita –como es com�n en la realidad– en cuanto a que las operaciones de cr�dito fluyen entre los puestos de trabajo que ejecutan las actividades del proceso y se atacan en orden de llegada, sin programaci�n ni control alguno de que no se queden rezagadas, el servicio al cliente ser� deficiente. Esto porque no habr� garant�a alguna de que una operaci�n termine en un plazo especificado, ni se conocer� en qu� situaci�n se encuentra cada operaci�n. Por el contrario, si se dise�a una pr�ctica de trabajo en que se programa expl�citamente cada operaci�n, por medio de identificar la disponibilidad de personal en cada una de las actividades –por ejemplo, confecci�n de escrituras, inscripci�n, producci�n de letras–, y se asigna expl�citamente a cada persona una cantidad de operaciones y se genera un compromiso de cumplimiento de prioridades y fechas, s� se puede garantizar un plazo para el procesamiento de un cr�dito. Una consecuencia adicional de esta pr�ctica es que se puede asegurar tambi�n un uso pleno de recursos disponibles. Esto debe ser complementado con una rutina apropiada para Controlar producci�n, que asegure que los compromisos asignados en los programas se cumplan.

En segundo lugar, la coordinaci�n tambi�n se ejerce por medio de los flujos, particularmente aquellos que tienen que ver con secuencia, vale decir que una actividad no puede ocurrir antes que otra. Esto se consigue en Macro1 y sus especializaciones por medio de dos mecanismos: una base de datos centralizada en Mantenci�n de estado y mensajes de requerimientos entre actividades. El primero asegura que la situaci�n de procesamiento de cualquier requerimiento es conocida en todo momento –y, posiblemente, en l�nea– por todo el que participa en el proceso y en particular por el que tiene que actuar en una fase del mismo. La segunda explicita a una actividad subsecuente que una precedente ha realizado su trabajo y que puede o debe realizar su tarea. La manera en que se implemente la base de datos y mensajes afectar�, por lo tanto, vitalmente la coordinaci�n. Si la base de datos no tiene la din�mica apropiada y no se conoce el estado del proceso en forma oportuna y los mensajes no est�n estructurados de manera apropiada, se producir�n demoras en el flujo del proceso por falta de conocimiento de una actividad de que debe actuar. Por el contrario si el estado y los mensajes llevan a la actuaci�n en el momento apropiado y, adem�s, se controla que esto ocurra, habr� garant�as de la satisfacci�n de requerimientos en plazos definidos. Las tecnolog�as disponibles para la coordinaci�n por flujo permiten la implementaci�n de la idea anterior, particularmente la de workflow [6]. Esta apoya la interacci�n por medio de mensajes y flujos electr�nicos. Ilustramos las ideas anteriores y el uso de la tecnolog�a con la actividad Preparar carpeta para an�lisis de riesgo de la Figura 3.13. Una descomposici�n de esta actividad con un dise�o que le saca m�ximo partido a la tecnolog�a se muestra en la Figura 4.2. La figura muestra que existen dos tipos de bases de datos: de registros tradicionales de bases de datos con la informaci�n de los clientes y sus requerimientos y otra de tipo workflow con la informaci�n de estado del flujo y la historia del mismo, junto con informaci�n de tiempos de ejecuci�n de actividades, fechas, etc. Pero la interfaz que ve el cliente es una sola, vale decir la del workflow, la cual se alimenta de la base de datos de registros para proveer otra informaci�n al usuario. El Apoyo workflow, es el que se encarga de presentar la informaci�n requerida, incluyendo carpetas electr�nicas –que fluyen entre actividades– que contienen documentos no registrados en ninguna de las bases de datos; por ejemplo, escrituras, p�lizas de seguros de propiedades, liquidaciones de sueldos y otros documentos digitalizados. Este apoyo es el que implementa la coordinaci�n por flujo, ya que gatilla la actuaci�n del usuario –en Verificar carpetas– cuando se dan las condiciones en el flujo que implican acci�n –la recepci�n de una carpeta, por ejemplo– y es la que implementa mensajes a otras actividades para gatillar su actuaci�n, al mismo tiempo que actualiza las bases de datos. El dise�o presentado corresponde a una idea de workflow habilitado por correo, vale decir los documentos digitalizados "fluyen" entre estaciones en una red que implementa el apoyo. Existe una alternativa en la cual toda la informaci�n –documentos digitalizados e informaci�n del estado del flujo– se mantiene en un servidor centralizado y no "fluye" realmente, sino que se le presenta a un usuario cuando lo requiere. Este servidor implementar�a una extensi�n de la Base datos workflow de la Figura 3.20.

Figura 4.2. Especializaci�n de Preparar carpeta para an�lisis de riesgo

Por �ltimo, la coordinaci�n tambi�n se puede establecer por colaboraci�n, usando tecnolog�a del tipo groupware [6]. Esta es relevante en procesos donde la mayor parte de las actividades es no estructurada, vale decir no se pueden dise�ar rutinas expl�citas para su realizaci�n y �stas quedan a criterio de los ejecutantes. En tal caso sigue siendo v�lida la idea de una Mantenci�n estado centralizada que consolida toda la informaci�n que requieren y generan las diferentes actividades. Por ejemplo, consideremos el proceso de llevar a cabo el desarrollo de un nuevo producto. La informaci�n relevante en este caso es estudios de mercado, dise�o preliminar del producto, estudio de factibilidad, dise�os de detalle, dise�o del proceso productivo, etc. Si toda esta informaci�n se maneja en papel y fluye entre los participantes –de Marketing a Ingenier�a a Estudio a Operaciones a etc. – en esa forma, lo m�s probable es que haya serios problemas de coordinaci�n, particularmente asociados a cambios y versiones de los diferentes documentos. As�, por ejemplo, se puede estar dise�ando el proceso productivo para una versi�n desactualizada del dise�o del producto y se puede estar cotizando y comprando maquinaria para una versi�n desactualizada del proceso productivo. Por lo tanto, una alternativa de dise�o del proceso en la cual se comparte toda la informaci�n relevante en un servidor central groupware –que permite manejar documentos de cualquier tipo: planos, texto, gr�ficos, fotos, etc.– por todas las actividades que participan en el proceso, evitar� los problemas de coordinaci�n anteriormente se�alados, por medio de una colaboraci�n inducida entre los participantes por el hecho de que cada uno de ellos siempre conoce en forma actualizada, lo que los otros est�n haciendo y lo que han producido.

4.3-. Asignaci�n de responsabilidades

Un dise�o de proceso establecido para un caso particular –a partir de un modelo de un dominio o subdominio– tiene m�ltiples posibilidades de materializaci�n en cuanto a la asignaci�n de tareas a diferentes unidades o personas y la organizaci�n que �stas adoptan. Por ejemplo, en el proceso de cr�dito hipotecario, las tres actividades de la Figura 3.13 –correspondientes a la partici�n de Recopilaci�n de antecedentes y an�lisis preliminar– podr�an estar asignadas a una sola persona; posiblemente un ejecutivo de cuentas. Pero tambi�n podr�an ser realizadas por diferentes personas e incluso diferentes unidades. Por lo tanto, los flujos entre actividades tienen interpretaciones alternativas, dependiendo del caso: "flujo virtual" en el mismo escritorio o estaci�n de un persona o flujo real entre personas o estaciones.

Cuando participan diferentes personas en un proceso, �stas pueden ser de una misma unidad funcional, de diferentes unidades funcionales, o ser parte de un grupo de proceso.

La decisi�n de dise�o de asignaci�n y organizaci�n est� obviamente limitada por una estructura actual. Dentro de las restricciones que �sta impone, la tendencia de cambio debe ser a la de funcionamiento por proceso. En t�rminos ideales, de acuerdo a las ideas modernas de organizaci�n, esto implicar�a la creaci�n de un grupo de proceso aut�nomo y autocoordinado –con alg�n tipo de liderazgo natural– que maneje integralmente el proceso. Como esto es muy dif�cil de llevar a la pr�ctica, se puede intentar crear un grupo virtual en el cual ciertas actividades y la tecnolog�a –workflow, groupware u otra–, coordinan las personas del grupo que se ubican en diferentes �reas funcionales e incluso fuera de la empresa –cual es la situaci�n de los tasadores y abogados externalizados en el caso de cr�dito hipotecario. Lo anterior conduce a una estructura virtual de procesos que funciona sobre una estructura funcional cl�sica.

Dentro de una estructura virtual de procesos, persiste el problema de asignaci�n de tareas, en el cual se tiende a favorecer, modernamente, la asignaci�n m�ltiple de tareas dentro de un proceso a una sola persona. Si bien esto va en desmedro de la especializaci�n, tiene ventajas en cuanto a evitar la rutinizaci�n, aumentar la motivaci�n, favorecer el servicio al cliente –por menor disgregaci�n de responsabilidades– y facilitar el funcionamiento por proceso. Sin embargo, hay situaciones en que, por razones de volumen y de necesidad de alta eficiencia operativa, la balanza puede inclinarse a favor de la especializaci�n extrema. Este es el caso en servicios de alto volumen, como servicios de comida r�pida, arriendo de autos, etc.

Por lo tanto, el balance entre riqueza de la tarea versus especializaci�n hay que resolverlo caso a caso.

Cuando se adoptan soluciones de enriquecimiento del trabajo –con m�ltiples actividades asignadas a una persona– en situaciones de alto volumen, se generan muchas l�neas paralelas de producci�n o servicio y un problema de asignaci�n y programaci�n del trabajo de ellas. Esto incluso puede significar la creaci�n de nuevas actividades que realicen esta coordinaci�n. Un caso real de aplicaci�n del modelo Macro1chi lleg� a esta soluci�n. En efecto, al dise�arse una soluci�n para las actividades de Decidir cr�dito de la Figura 3.14 en un banco de la plaza, se opt� por asignar integralmente –excepto por revisiones y aprobaciones– las actividades Generar antecedentes evaluaci�n, incluyendo su partici�n, y An�lisis de riesgo a un analista de cr�dito. Esto significa tener muchos analistas que trabajan en paralelo, ya que se trata de un banco que maneja un gran volumen de estas operaciones. Por lo tanto, se requiere una actividad que genere criterios de asignaci�n de operaciones –por tipo de negocio, por ejemplo– e implemente y controle la asignaci�n, velando que la carga entre los diferentes analistas est� equilibrada y que se respeten los plazos definidos para esta fase. Esto requiere la creaci�n de una actividad adicional de programaci�n y control de las evaluaciones

de cr�dito, que no existir�a en la medida que las operaciones se movieran en una l�nea con mayor especializaci�n, en la cual ellos se transfieren de puesto en puesto de trabajo en forma autom�tica. Por supuesto, la funci�n de programaci�n y control requiere de informaci�n acerca del estado de los requerimientos por operaciones de cr�dito y la situaci�n en que �stos se encuentran, la cual debe ser provista a trav�s de Mantenci�n estado.

Este tema de asignaci�n del trabajo y estructura organizacional tiene muchas m�s facetas que las presentadas, particularmente en lo que se refiere al impacto en la conducta de los participantes en el proceso. Sin embargo, est� fuera del alcance de este documento profundizar este tema.

4.4-. Apoyo computacional

El apoyo computacional a las actividades del proceso est� presente tanto en los patrones como en su aplicaci�n. Las conclusiones fundamentales que se desprenden de lo ya dicho son que:

1. Existe un apoyo gen�rico a todas las actividades que se manifiesta en una Mantenci�n de estado centralizada, en uno o varios servidores, que provee toda la informaci�n –a partir tanto bases de datos tradicionales como de bases de datos documentales tipo workflow o groupware y otras– necesaria para la realizaci�n de ellas.
2. Existe la posibilidad de procesamientos de apoyo espec�fico a cada actividad –automatizando rutinas de trabajo de toma de decisiones, facilitando el intercambio de mensajes y otros–, los cuales se pueden implementar descentralizadamente en un equipo cliente en el lugar de trabajo o centralizadamente en un servidor.

Los requerimientos que definen sin ambig�edad los apoyos anteriores se desprenden directamente del patr�n especializado a un caso particular. As� los requerimientos para las bases de datos de Mantenci�n de estado se establecen a partir de la uni�n de las necesidades expresadas en todos los flujos que alimentan –desde abajo, en los modelos gr�ficos– con informaci�n de estado a las actividades. Como estos flujos detallan los atributos acerca de los cuales debe proveer datos Mantenci�n de estado, un inventario de los atributos, organizados por entidad, define un modelo de datos que resume los requerimientos. La forma de este modelo se tratar� en el cap�tulo siguiente.

Los requerimientos de procesamiento de apoyo espec�fico a cada actividad se desprenden claramente de la l�gica de negocio asociado, la cual es parte del dise�o, tal como se ejemplific� en el caso de cr�dito hipotecario en la Secci�n 4.1.

Por lo tanto, el redise�o basado en patrones considera y resuelve integralmente la especificaci�n de los requerimientos de apoyo computacional a un proceso.