INTRODUCCION
Parece natural que el conocimiento sobre los patrones de proceso sea gestionado por universidades o institutos de investigación sin fines de lucro. En esta dirección, este documento proporciona una primera propuesta de patrones de proceso que resume la experiencia del autor en la materia.
PATRONES DE PROCESOS DE NEGOCIOS
La arquitectura general de un proceso
Otra consecuencia importante de la distinción antes mencionada es que para la gestión es necesario conocer el estado de las actividades de transformación de recursos. Así, las actividades de gestión reciben información sobre el estado del mantenimiento y crean instrucciones de acción para la producción y provisión de un bien o servicio.
Patrones de procesos
Entonces, la Figura 2.3 muestra un desglose o más detalles de la función de Gestión de Relaciones con el Cliente. Pasando al detalle del macroproceso, en la Figura 2.4 se muestra la descomposición de la actividad de Gestión de la Producción y Abastecimiento.
ESPECIALIZACION DE PATRONES
Jerarquía de patrones
Alternativamente, varias empresas de un dominio o subdominio pueden colaborar para crear un patrón para uso compartido. Naturalmente, esto irá tomando forma y enriqueciéndose con el tiempo a medida que se disponga de más conocimientos sobre los distintos ámbitos.
Patrones para dominios específicos
- Patrón para crédito
- Patrón para hospitales
En las Figuras 3.3, 3.4 y 3.5 mostramos una descomposición del 1er nivel de las actividades de Macro1c. Allí se muestran las actividades típicas de interacción con el cliente: Ventas, que se centra en adquirir nuevos clientes de forma proactiva; La Figura 3.7 muestra los detalles de Decidir Crédito, que involucra dos actividades crediticias típicas: Generar antecedentes de evaluación, que garantiza que toda la información de antecedentes necesaria para decidir sobre un crédito esté disponible; y Análisis de Riesgos, que implica una evaluación formal de la facilidad para otorgar crédito.
La idea que surge de Macro1 es, por tanto, la que se presenta en la Figura 3.8. A un nivel más detallado, la Figura 3.9 muestra el desglose de Gestión de Relación con el Paciente, que también es una especialización de la correspondiente actividad Macro1, con los siguientes cambios: Análisis de Demanda y Capacidad de Utilización es una versión más limitada de la actividad original, que tiene la finalidad de procesar información de mercado sobre demanda y análisis de demandas con tendencias de diferentes tipos de patologías para tomar acciones en materia de adecuación de capacidades y generar una Proyección de demandas de corto plazo, la cual se registra en estado de Mantenimiento; Ingreso, donde se verifica el estado del paciente, tanto desde el punto de vista médico como de su capacidad de pago, para determinar si el servicio puede prestarse o no; y se adaptan los flujos al caso, especialmente los relacionados con el estado y situación del paciente y la disponibilidad de recursos médicos para su tratamiento. La Figura 3.11 muestra la especialización de Tratamiento y alta de pacientes con: Tratamientos médicos, que son las intervenciones que se realizan al paciente; Alta, que es el acto físico de salida del paciente del hospital; y los flujos adaptados a este caso.
Finalmente, en la Figura 3.12 se muestra el detalle de la Decisión de ingreso, donde se verifica un análisis de la situación personal, financiera y clínica del paciente para determinar si es atendido o no.
Especialización a subdominios
Por lo tanto, ilustraremos la especialización del subdominio sólo con un caso especial, que es un ejemplo de un préstamo hipotecario en el caso de que se emitan facturas para su financiación*. Así, en la Figura 3.13 se muestra el desglose de la recopilación de antecedentes y análisis preliminar, donde los detalles más importantes son la existencia de una instancia preliminar de calificación crediticia para asegurar una respuesta rápida al cliente y la creación y gestión de carpetas físicas o registros electrónicos que contienen registros. que no pueden registrarse en el mantenimiento estatal. En la Figura 3.14 se muestra un desglose de la opción Decidir Crédito, y en la Figura 3.15 se muestra un desglose de los antecedentes para realizar un avalúo, que incluye las actividades necesarias en un crédito hipotecario, como asegurar que el bien a hipotecar no tenga problemas legales y realizar una tasación para determinar su valor. en el mercado, incluyendo la información generada en la carpeta del cliente.
La Figura 3.16 muestra el desglose de la Programación de Operaciones, siendo el aspecto más importante la existencia de actividades explícitas de Solicitud de Asignación, las cuales generan un cronograma de actividades de producción, el cual determina quién estará a cargo de cada operación, las prioridades de ejecución y las fechas esperadas de finalización; y controlar la producción, para garantizar que el préstamo se produzca según los plazos y otras condiciones predeterminadas. La Figura 3.17 muestra el desglose de la producción de préstamos, que muestra las actividades típicas y esenciales involucradas en la generación de un préstamo hipotecario. Finalmente, en la Figura 3.18 se muestra el desglose de la Entrega del Préstamo, donde se crean los documentos que materializan el préstamo y se realiza su distribución física.
Más detalles sobre las actividades y flujos de las figuras anteriores se muestran en el glosario del Apéndice 3.
APLICACIÓN DE PATRONES
Prácticas de trabajo
Cada actividad del empleador debe caracterizarse por ofrecer la práctica laboral específica que se propone realizar. Dependiendo del caso, esto puede variar desde una rutina o algoritmo completamente estructurado –implementado total o parcialmente con soporte computacional– hasta simplemente una descripción general de lo que se espera de la actividad, dejando los detalles a discreción de la persona que la realiza. eso.realiza. Como ejemplo de una situación altamente estructurada, considere el proceso de préstamo hipotecario especificado en 3.3 y, en particular, la actividad de Análisis preliminar en la Figura 3.13.
El algoritmo debe incluir las variables a considerar en dicha evaluación; Por ejemplo -para simplificar el tema de las hipotecas para particulares-, los ingresos de la persona, su deuda con el sistema financiero, los activos que posee -coches, propiedades, etc.-, el tamaño de su grupo familiar, etc. El funcionario continúa revisando la idoneidad de toda la información de antecedentes utilizada y verificando la exactitud general de la conclusión crediticia informada al cliente. Como ejemplo de práctica de trabajo en casos no estructurados, se puede considerar la valoración del bien prendario de la figura 3.15.
En este caso, en lugar de crear un proceso de tasación preciso, nos basamos en el conocimiento y experiencia de un experto y solo indicamos que el valor de tasación debe reflejar el precio de venta de mercado de la propiedad.
Coordinación entre actividades
El diseño propuesto también deja los requerimientos que surgen de esta actividad para la base de datos de mantenimiento del estado, los cuales son los valores de las variables (características) consideradas en el algoritmo para cada uno de los clientes solicitantes de crédito. , que especifica. el contenido de los flujos de estado del cliente potencial y del cliente. Esto se logra en Macro1 y sus especializaciones a través de dos mecanismos: una base de datos centralizada en el mantenimiento del estado y mensajes requeridos entre actividades. Por lo tanto, la forma en que se implementen la base de datos y los mensajes afectará significativamente a la coordinación.
Si la base de datos no tiene la dinámica adecuada y no se conoce en el tiempo el estado del proceso y los mensajes no están estructurados adecuadamente, se producirán retrasos en el flujo del proceso por desconocimiento de una actividad que debe actuar. . Pero la interfaz que ve el cliente es solo una, es decir, el flujo de trabajo, que pasa a través de la base de datos de registros para proporcionar otra información al usuario. El soporte de flujo de trabajo es responsable 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 seguro de propiedad, declaraciones de sueldo y otros documentos digitalizados.
Este soporte es lo que implementa la coordinación basada en flujo, ya que desencadena la acción del usuario (en Verificar carpetas) cuando ocurren condiciones en el flujo que implican acción (recuperar una carpeta, por ejemplo) y es lo que aplica mensajes a otras actividades para desencadenar su acción. mientras se actualizan las bases de datos.
Asignación de responsabilidades
Aunque esto va en detrimento de la especialización, tiene ventajas en cuanto a evitar la rutinización, aumentar la motivación, favorecer la atención al cliente -por una menor división de responsabilidades- y facilitar el funcionamiento del proceso. Sin embargo, hay situaciones en las que, por razones de volumen y necesidad de una alta eficiencia operativa, la balanza puede inclinarse a favor de una especialización extrema. Por lo tanto, el equilibrio entre riqueza de tareas versus especialización debe elegirse caso por caso.
De hecho, al diseñar una solución para las actividades de Decidir crédito en la Figura 3.14 en un banco local, se decidió asignar completamente las actividades –con excepción de revisiones y aprobaciones– a las actividades de Generar evaluación de antecedentes, incluyendo su desglose, y análisis de riesgos. a un analista de crédito. Se requiere, por tanto, de una actividad que genere criterios para la asignación de operaciones -por tipo de empresa, por ejemplo- y ejecute y controle la tarea, lo que garantice que la carga entre los distintos analistas esté equilibrada y que se cumplan los plazos definidos para ello. Los requerimientos para las bases de datos de Mantenimiento del Estado se establecen así a partir de la unión de las necesidades que se expresan en todas las corrientes que - desde abajo, en los modelos gráficos - alimentan con información gubernamental a las actividades.
Los requisitos de procesamiento de soporte específicos para cada actividad se desprenden claramente de la lógica de negocios asociada que forma parte del diseño, como se ejemplifica en el caso del crédito hipotecario en la sección 4.1.
DESARROLLO DE SOFTWARE DE APOYO
Modelos de datos genéricos y su especialización
Cliente = “ID de cliente” + nombre o nombre de la empresa + ubicación + estado del cliente + estado de los requisitos del producto o servicio generados + “ID de contacto” + puesto de trabajo + teléfono + fax + dirección de correo electrónico. Producto o servicio generado = “código de producto o servicio generado” + nombre del producto o servicio generado + disponibilidad del producto o servicio generado + análisis de los requisitos del producto o servicio generado + requisito del producto o servicio generado + plan e instrucciones de producción y entrega. Producto o servicio supuesto = "código de producto o servicio supuesto" + descripción del producto o servicio supuesto + disponibilidad del producto o servicio supuesto + requisito esperado del producto o servicio supuesto.
Producto o servicio generado = disponibilidad del producto o servicio generado + análisis de necesidades del producto o servicio generado + necesidad prevista para el producto o servicio generado + plan e instrucciones para producción y entrega. En segundo lugar, hay referencias de una entidad a otra; Por ejemplo, un atributo de estado de solicitud de producto o servicio de un cliente creado se refiere a los productos o servicios específicos contenidos en la entidad correspondiente. Finalmente, existen relaciones arbitrarias, por ejemplo, un producto o servicio de entrada se utiliza en un producto o servicio generado.
Por ejemplo, en la Figura 5.1, la entidad Estado de Requisito se refiere al Producto o Servicio Generado, en el sentido de que ciertos antecedentes de los productos o servicios contenidos en el Estado de Requisito existen en el Producto o Servicio Generado.
Diseño e implementación computacional
Las herramientas también apoyarían en la generación del código que permita implementar el soporte computacional para el nivel de especialización para un caso determinado. En este caso, las clases estarían definidas a nivel de Macro1, un dominio o un subdominio, que contiene los datos y los métodos. Estas clases y sus relaciones también se pueden especificar basándose en un esquema formal soportado por herramientas de software, que permiten la generación automática de código [9].
Por tanto, la especificación, diseño e implementación del soporte informático de un proceso de negocio para un caso concreto se puede realizar basándose en trabajos previos realizados para el nivel de especialización más bajo disponible.
CONCLUSIONES
Aplicabilidad del enfoque
Factibilidad de colaboración
Utilidad como instrumento académico
