Patrones de Procesos de Gestión
Compartiendo Conocimiento para Aumentar la Productividad
Indíce del Capítulo
4.1-. Prácticas de trabajo
4.2-. Coordinación entre actividades
4.3-. Asignación de responsabilidades
4.4-. Apoyo computacional
4-. APLICACIÓN DE PATRONES
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:
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.