UNIDAD III ARQUITECTURA DE PROCESOS

III.1.- Modelado de relaciones entre procesos

III.1.1.- CASE (CASE PROCESS) Todo el trabajo en una organizacin viene en episodios o casos, todas las organizaciones tienen una forma de trabajar. Las organizaciones hacen muchas cosas, venden, compran, contratan gente, almacenan productos, capacitan al personal, dan mantenimiento a sus oficinas. Sin embargo no todos los procesos son bsicos o fundamentales para la organizacin. Si somos una cadena de hamburguesas y nos llega un cliente a solicitar una hamburguesa, tendremos un mtodo estandarizado para tratarlo. Eso es lo que llamaremos el CASE PROCESS o proceso bsico o fundamental. Un proceso bsico puede dar seguimiento, tratar o manejar una situacin especfica dentro del negocio. Estos procesos bsicos o CASE PROCESS los podemos intanciar, es decir los podemos llamar a ejecucin una o mltiples veces. Volviendo a nuestro caso de la tienda de hamburguesas, tenemos un cliente que est solicitando una orden, otro que la est pagando, otro al que le estn preparando su orden, etc. Es decir cada uno est en una fase distinta del mismo proceso. Un proceso tambin puede ser instanciado en una etapa intermedia o final y no necesariamente desde el inicio. Por ejemplo si un cliente decide cambiar el sabor de su bebida, se lo puede pedir directamente a la persona que le est surtiendo la orden y no tiene que volver a hacer fila para solicitarlo al cajero que le cobr. Otro ejemplo: La oficina proveedora tiene 1222 rdenes de compra con las que debe tratar, el Call Center normalmente est Tratando con 34 llamadas, el comit est tratando Trabajando en el presupuesto anual. La compaa farmacutica de medicamentos tiene 15 compuestos en proceso, el departamento clnico esta Corriendo 87 pruebas clnicas; entonces decimos de forma normal que est operando una instancia de un CASE PROCESS. Los Case Process pueden estar en diferentes etapas en la compaa farmacutica por decir, el compuesto A pudiera estar de primera mano en pruebas con humanos voluntarios, el compuesto B pudiera estar en fase III en pruebas con miles de pacientes clnicos, el compuesto C est esperando trmites regulatorios de aprobacin al final de su proceso. Algunos Case Process se ejecutan de una sola vez. Por ejemplo si se le hacen pruebas en un laboratorio a un paciente, el paciente entra se le hacen todas las pruebas y cuando termina es el turno del siguiente paciente. III.1.1.1.- Nombrando Case Process Debido a que la base de nuestro pensamiento en cuanto al diseo de procesos es el nombre que le damos a los mismos, es muy importante el referenciarnos a ellos de una manera que fcilmente los podamos distinguir. De esta manera mientras ms utilicemos la convencin ser ms fcil el identificar y darnos una idea de lo que tratan cada uno de los tres tipos de procesos: Case Process (Procesos bsicos)

MODELADO DE PROCESOS

Case Management Process (Procesos administrativos), Case Strategic Process (Procesos estratgicos).

Para nombrar un CASE PROCESS podemos utilizar las palabras manejar un (Handle a) o preparar un (Prepare a). Se considera que en un Case Process la Unidad de trabajo (UOW) puede ser vista como la entrada al proceso o aquello que lo dispara. Por ejemplo manejar una orden de compra o manejar una queja del cliente. Se utiliza preparar un (Prepare a), cuando la UOW es la salida del proceso. Por ejemplo: Preparar una orden de produccin o preparar el reporte del proyecto Cuando la UOW no es la entrada ni la salida utilizamos tambin podemos utilizar manejar (Handle), por ejemplo manejar una campaa de mercadeo o manejar la compra de una casa En el mtodo Riva se da nombre a los Case Process de modo que se enfatice la UOW correspondiente En estos casos los nombres sugieren una sola instancia, una orden de produccin, una campaa de mercadeo, una queja de cliente. Pero tambin se pueden dar nombres que impliquen mltiples instancias cambiando un por el, por ejemplo la orden de produccin, la campaa de mercadeo, la queja de cliente. Esto es parte de los convencionalismos que poco a poco se van dando con la prctica y a los cuales nos iremos acostumbrando. Inicialmente basta con dar al proceso un nombre que nos identifique con l y que refleje la UOW. Una pregunta interesante es saber Cundo inicia un Case Process? Podemos decir que es cuando llega el caso. Pero Cmo puedo saber cuando tengo un caso?. Por ejemplo: El proceso de venta de una hamburguesa inicia cuando el cliente entra en el establecimiento, cuando se forma en la fila, o cuando compra la hamburguesa. De igual manera nos podemos preguntar dnde inicia el proceso de compra de una casa?, cuando visito la casa, cuando hago una oferta o cuando firmo los roles. dnde inicia el proceso de una queja de cliente? Cuando el cliente se forma en la fila, cuando llena la forma de queja o cuando la recibe el empleado que atiende las quejas. Tampoco es fcil determinar cundo termina el proceso. Para responder a estas preguntas es muy importante basarnos en la arquitectura de procesos (PAD) para determinar desde que punto consideraremos que inicia un proceso y donde termina. Al igual que en el caso anterior es muy importante determinar el momento en que el proceso finaliza, por ejemplo si tratamos con una queja del cliente, dnde termina el proceso? Cuando el cliente se va contento, cuando se desiste de la queja, o cuando no acepta la oferta y va a los tribunales.

MODELADO DE PROCESOS

Tambin es importante que los nombres de los procesos reflejen lo que se busca como salida de ellos. Supongamos que tenemos un proceso que se llama aprobacin del crdito pero en un momento el proceso termina cuando el crdito es rechazado. No es muy lgico nombrar un proceso de aprobacin cuando una de sus salidas es el rechazo del mismo. Un mejor nombre sera manejo de solicitudes de crdito. III.1.2. - Case Administrativos (CMP) (Case Management Process) Para cada UOW hay un case process y en cualquier momento habr muchos casos (recuerde que los casos se consideran por ejemplo, clientes, rdenes de compra, pedidos, etc.) del UOW y muchas instancias del case process en progreso y es posible que estn compartiendo recursos entre ellos. Por ejemplo un cliente (caso) puede estar en el proceso de solicitar un crdito, otro en el proceso de llevar la documentacin, otro en el proceso de aprobacin, etc. La organizacin debe controlar el flujo de case process y los recursos que estn en diferentes instancias. Se pueden estar en fases de calendarizacin, manejo de recursos, asignacin de tareas, toma de decisiones, reportando y as sucesivamente. Pero si lo vemos desde el punto de vista de Case Process trataremos estos procesos como si fuera una sola instancia de un solo case. Es decir si para nuestro proceso de manejo de solicitudes de crdito consideramos, para efectos del diseo, a un solo cliente que va pasando por las distintas etapas del proceso. Para cada UOW se espera encontrar 2 procesos, uno es el case process (el proceso de caso) y el Case Management Process (Proceso administrativo de caso). Ambos procesos interactan pero separarlos es vital para el proceso de anlisis y diseo. En los Case management process (proceso esperamos ver acciones que tratan con: Planeacin Reporteo Monitoreo Calendarizacin Asignacin de recursos Priorizacin Negociacin Reconciliacin Por lo que esperaramos ver roles como: Consejo Managers Equipos administrativos Comit administrativo Supervisor administrativo de caso)

MODELADO DE PROCESOS

Auditor del progreso del proceso Equipo de planeacin Grupos de monitoreo Un case process normalmente va directo desde su nacimiento hasta su muerte, por lo tanto lleva un iniciador (trigger) quien lo inicia y una o varias salidas correspondientes a su muerte. Por ejemplo en una solicitud para un seguro el iniciador sera la llegada de la solicitud de la aplicacin al seguro y las salidas seran la aceptacin o el rechazo de la solicitud. Por otro lado los Case Management Process rara vez tienen un iniciador y van en una forma seguida hasta el final. La naturaleza de la administracin es que responden a muchas situaciones e intervienen segn se necesite y es proactiva en muchas otras situaciones. Podramos esperar que un case management process tenga mltiples iniciadores (triggers) correspondientes a las distintas posibles situaciones que invocaran el proceso, cada uno con su propia salida o quiz compartiendo las mismas salidas. No podemos decir que todos los case management process tengan todos los componentes que los caracterizan, algunos son muy triviales o incluso nulos por lo que pueden ser eliminados e integrarlos en los case process. Enseguida mostramos una lista de los componentes tpicos de un case management process.

III.1.2.1.- Componentes tpicos de un Case Management Process (CMP)

Tratando con un requerimiento para un caso nuevo. Por ejemplo iniciar un nuevo case process. Negociando con un cliente si el requerimiento para un caso nuevo no puede lograrse (con base en las expectativas) Monitoreando el progreso de una instancia de un caso Escuchando y tratando con la terminacin de una instancia de un caso Escuchando y tratando con excepciones y errores de una instancia de un caso Determinando qu recursos debern ser asignados a los actores en una cierta instancia de un cierto case process.

III.1.2.2.- El Case Management Process toma responsabilidades del flujo de instancias de Case Process.
El encargado de arrancar una instancia de un case process es el case Management process Controla el inicio, el monitoreo, de todos los case process, administra recursos y los calendarios de ellos. Puede pasar al estado de espera a algn (os) case process hasta que sea conveniente reactivarlos (en orden de llegada), pasar recursos de un case process a otro, dar prioridad a alguno de ellos.

MODELADO DE PROCESOS

Escencialmente el case management process toma la responsabilidad para las intancias que se ejecutan en los case process. El CMP Administra el flujo de case process. En pocas palabras es un case process para administracin de case process.

III.1.2.3.- Nombrando a los Case Management Process CMP (Proceso

administrativo de caso) De la misma forma como elegimos nombres neutrales para los case process, como lo eran manejar o preparar, vamos a utilizar una regla similar para los case management process. Vamos a iniciar con el trmino Administrar el flujo de Podemos tener los siguientes nombres de procesos administrativos: Administrar el flujo de rdenes de compra Administrar el flujo de quejas de cliente Administrar el flujo de lotes de produccin Administrar el flujo de reportes de proyectos Administrar el flujo de campaas de mercadeo Administrar el flujo de compras de vivienda Se pueden dar otros nombres alternos, dependiendo de lo que queremos que se entienda del proceso. El case management process esencialmente toma responsabilidad del flujo de instancias hacia el case process. Es decir cuando una instancia del case process, por ejemplo una cambio en la lnea de produccin, necesita ser iniciado, es el case management process quien lo hace. Adicionalmente a ello, se requiere solamente una instancia de CASE MANAGEMENT PROCESS para administrar muchas instancias de CASE PROCESS. Si tomamos el caso de proceso cambio en la lnea de produccin, tenemos que un solo case management process (CMP), que en este caso convendra nombrar administrar el flujo de cambios en la lnea de produccin puede administrar mltiples instancias del case process(CP). Este proceso administrativo puede iniciar, monitorear, controlar, etc. A diferentes lneas de produccin, no solamente a una, e incluso en diferentes instancias, por ejemplo una puede estar cambiando el herramental, otra en fase de pruebas, etc. En principio cada UOW tendr un CMP quien controlara y administrara a las instancias del CP correspondiente.

III.1.2.4. - Relaciones entre case process (CP) y case management process (CMP) Vamos a suponer que estamos en una fbrica de electrodomsticos y tenemos una UOW llamada orden de trabajo o simplemente orden. Una orden de trabajo se encarga de producir o fabricar un cierto tipo de artculo por ejemplo una licuadora. Para producir esta licuadora se necesita de un proceso que permita determinar

MODELADO DE PROCESOS

donde se le agrega que componentes, donde se hacen ciertas pruebas, donde se empacan, etc., todo lo necesario para producir una licuadora de calidad. Pero despus puede venir otra orden para fabricar tostadores de pan, este es un nuevo caso pero se corre el mismo proceso de forma estandarizada solo que ahora para producir el tostador de pan. Un case process para esa UOW sera manejo de una orden. Pero, como ya dijimos, una fbrica maneja muchas rdenes distintas que se procesan por lotes y que requieren de cierta preparacin, asignacin de recursos (que componentes va a utilizar), modificaciones de la lnea, adems se requiere decirle al proceso cuando puede iniciar. Para ello necesitaramos otra UOW llamada preparacin de lotes. Claro que la fbrica maneja muchas instancias de ese proceso llamado preparacin de lotes, este proceso se encargara de iniciarlos, de controlarlos y administrarlos. Entnces tenemos un case management process al que llamaramos administracin del flujo de lotes.

Pongamos estos conceptos en vocabulario Riva:

1. - Una instancia del proceso Manejo de una orden interacta con Manejo del flujo de lotes para solicitar que una nueva orden sea producida. 2. - Administracin del flujo de lotes calendariza el lote planeado 3. - Administracin del flujo de lotes activa el proceso Preparar un lote, en el momento apropiado. 4. - Una vez satisfecha la orden Preparar un lote interacta con Manejo de una orden para reportar completa la orden y terminar el proceso.

Manejo de una orden

Entrega a

Requiere Administracin del flujo de lotes

inicia
I

Prepara un lote

Fig. 3.1 Relacin Bsica de Servicio

Simbologa:
I

Interaccin entre 2 procesos, la flecha va en el sentido del que inicia la interaccin al otro

MODELADO DE PROCESOS

Activacin de; la flecha va en el sentido del que hace la activacin al otro activado CP = Case Process CMP = Case Management Process
A

Proceso Nombres de procesos: Handle a, Prepare a = Case process Manage a Flow of = Case Management process

Segn nuestra metodologa en la que habamos comentado que cada UOW requiere de un case process y de un case management process. Estara faltando un proceso que se llame administracin del flujo de rdenes. Veamos la funcin que tendra este proceso para determinar si es o no requerido. Si suponemos que en un momento dado una orden en proceso requiere de un componente que no se tiene o bien necesita ser adelantada o alguna otra causa en donde requiera de negociar con el proceso de administracin del flujo de lotes. Entonces sera necesario el proceso de administracin del flujo de rdenes. Quien sera el responsable de llevar a cabo estas negociaciones. La forma como lo representaramos en el lenguaje Riva sera:
Manejo del flujo de rdenes

Negoca
I

Manejo de una orden

Entrega a

Requiere Manejo del flujo de lotes

Negocia
I A

Inicia
I

Preparar un lote
Fig. 3.2 Relacin Bsica de Servicio con Negociacin

MODELADO DE PROCESOS

Supongamos ahora que deseamos agregar la parte de monitoreo de los lotes para determinar si estn trabajando en forma apropiada o si requieren ser detenidos por cuestiones de calidad. En el siguiente diagrama se muestra la representacin de ese monitoreo que se estara realizando. Administrar el flujo de ordenes

Negocia
I

Manejo de una orden Entrega a

I

Requiere

Negocia
I A

Administrar el flujo de lotes

Inicia
-Monitorea -Interviene -Detiene

Preparar un lote
I

Reporta

Fig. 3.3 Relacin General de Servicio

Ahora supongamos que esta relacin tambin es utilizada por otras UOW dentro de la organizacin. En esta caso tenemos un departamento de investigacin y desarrollo que desea probar los diseos de nuevos productos en la lnea de produccin, los requerimientos y lotes que manejan son distintos a los de la produccin de artculos de lnea, pero de cualquier manera necesita negociar con el proceso Administrar el flujo de lotes, para que se le permita ingresar sus productos potenciales a la lnea de produccin. La UOW sera producto potencial. Traduciendo al lenguaje Riva, la representacin quedara como sigue:

MODELADO DE PROCESOS

Manejo de un producto potencial Entrega un lote

I

Inicia
I A

Requiere

Manejo del flujo de productos potenciales

Negocia con

Negocia
I

Maneja un lote
I

Inicia Negocia con

Requiere
I

I A

Administraci n del flujo de lotes

Entrega un lote Maneja una orden

Negoca con
A

Adminsitraci n del flujo

Inicia
Fig. 3.4 Contencin para un servicio

MODELADO DE PROCESOS

III.1.3.- CASE ESTRATGICOS (CSP) (CASE STRATEGY PROCESS)

Toman la vista estratgica de los UOWS y coordinan a los CP y a los CMP Un CSP tiene sus CP y CMP

El CSP responde a preguntas como:

Qu est sucediendo en el negocio que pueda afectar al UOW y cmo tratar con eso? (Ejemplo. Cmo afectar al call center si se aumenta la cantidad de medidores de agua, en una empresa que vende agua, respecto de las llamadas pidiendo apoyo) Qu est sucediendo fuera de la empresa que afecte al UOW? (Ejemplo. Una oficinas reguladora del gobierno quieren saber cmo se desarrolla el software que se usa en Investigacin y desarrollo (R & D) en la industria farmacutica) Est cambiando la naturaleza del UOW? Los clientes de bancos estn aumentando su tendencia a cambiar sus cuentas a otro banco debido a cambios en el cobro de comisiones. Cmo se cambiar el manejo de las cuentas de los clientes para contrarrestar esa tendencia?. Estn cambiando los rangos volmenes en el UOW? Hay cambios en los tipos de cursos que toman los alumnos para su currcula. Qu est sucediendo en el proceso de administracin de cursos que los hace ms populares? Cul es el rendimiento del CP y del CMP? Es adecuado y puede mejorarse?. Hemos recolectado mediciones en el proceso. Se necesita un acercamiento para la calendarizacin en el CMP, combinado con la reorganizacin de responsabilidades en CP? Se estn operando el CP y CMP de acuerdo a los procedimientos de la empresa? La regulacin de la industria tiene inters en la manera que el software se desarrolla en la empresa; debemos permitir que nos auditen en las instancias en el CP y CMP y que comprueben que estamos arriba del promedio? Nota: La implementacin del CSP se hace mediante el aadido de hilos en los roles, relacionados con los temas estratgicos.

MODELADO DE PROCESOS

III.1.3.1 Nombrando Case estratgicos (Naming case strategy process) Se pueden denominar: Maintain a stretegic view of Purchase Orders Maintain a stretegic view of Customer complaints Maintain a stretegic view of Production Batches Maintain a stretegic view of Project reports Maintain a stretegic view of Marketing campaigns Maintain a stretegic view of House purchases Nota: Se recomienda enfocarse en el rea exacta de inters de este proceso y no preocuparse de los detalles de CP y CMP.

10

MODELADO DE PROCESOS

III.2.- PREPARANDO LA ARQUITECTURA DEL PROCESO III.2.1.- Introduccin

Al recorrer una empresa estamos rodeados de muchas instancias de muchos procesos, todos operando al mismo tiempo, algunos activando otros y algunos interactuando entre s En cualquier momento hay una red de instancias de procesos que interactan al trabajar. Process Architecture.- Nos muestra la pelcula que dice qu tipos de procesos hay en la organizacin y cules relaciones dinmicas hay entre ellos. No nos interesa una descomposicin jerrquica esttica como aparece en un organigrama jerrquico tradicional, porque as no es el mundo real. El mundo es una red dinmica de instancias que interactan Al desarrollar mdulos de software se busca tener en ellos alta cohesin y bajo acoplamiento para reducir las dependencias entre ellos al mnimo y reducir la propagacin de errores; pero eso es porque el software es sinttico. Y se hace al gusto y saber del diseador. Un proceso de negocios tpicamente no es sinttico, se ha desarrollado organicamente, resultado de algo de diseo y mucho de azar, y no se espera que sea predecible (como el mundo no lo es). Al partir la actividad organizacional, se espera que sea natural, sea de modularidad latente; partir en trozos la actividad organizacional es as porque as tiene que ser, porque la organizacin est en este negocio en particular. Es como si al tallar el mrmol para una escultura se buscara la veta o lnea de falla natural y la seguimos, al partir madera seguimos el sentido de las fibras (longitudinalmente) y no hacemos corte transversal. Se busca conservar al mximo posible las conexiones, se desea explotar cualquier cohesin existente en el mundo real. Debemos buscar la fibra natural. Los procesos que existen en nuestra empresa, porque estamos en este negocio, tienen unidades de trabajo Unit of Work (OUW) esenciales y los procesos que estn porque decidimos trabajar en una cierta forma son procesos diseados; estos ltimos son candidatos a reingeniera, no los primeros. El error de alguien con experiencia en Ingeniera de Software, es que pretende partir un proceso sucesivamente en subprocesos y estos a su vez en otros subprocesos. Hasta llegar a una estructura jerrquica. Pero el mundo no es tan ordenado y los procesos en una organizacin invariablemente estn conectados en una red, ms que estar contenidos en otra. (Como los subprocesos del Ing. De software). Por lo tanto los peligros de pensar jerrquicamente no deben desecharse al tratar con procesos y llegar a construir un organigrama as:

11

MODELADO DE PROCESOS

The business

Plan the Business

Carrying out the Business

Monitor The business

Staff Allocation

Sales Prediction

Plant Planning

Fig. 3.5 No es una arquitectura de procesos, es ms una particin arbitraria

Segn la figura diramos que el mdulo Plan the Business es la suma de los resultados de sus mdulos subordinados (dependientes). Lo cul no nos dice qu relaciones dinmicas existen entre esos procesos. Las relaciones dinmicas son cruciales para el entendimiento de cmo trabaja una organizacin Es pues la organizacin: Dinmica en red en vez de Composicin jerrquica arbitraria Otra concepcin igual de peligrosa que la anterior respecto de los procesos, auque nos da alguna idea de dinamismo es la siguiente:

Market Review

Product Design

Product Development

Sales

Support

Fig. 3.6 No es una arquitectura de proceso; es ms una lista de silos.

Buscamos una arquitectura de procesos que sea derivada nicamente de un entendimiento de: En qu negocio est la organizacin

12

MODELADO DE PROCESOS

Podemos decir Si la organizacin est en este negocio luego entonces debe tener estos procesos, Esta es la fibra de la organizacin, si la organizacin cambia el negocio en que est, luego entonces se espera que cambien tambin los procesos. Si cambia la estructura de la organizacin de jerrquica a Matriz, no tiene porque cambiar la lista de procesos. Solo se debiera cambiar el cmo se hacen esos procesos. No cambia la lista de procesos aunque cambie la organizacin estructuralmente, sea un cambio de cultura fusin de departamentos. Para dividir adecuadamente la organizacin en procesos, requerimos hacer primero Arquitectura de procesos. y que lo que se vea un proceso lo sea, no que ste sea una suma de varios trozos de procesos reunidos arbitrariamente.

III.2.2.- En qu negocio estamos?

III.2.2.1.- Entidades esenciales del negocio (Essential Business Entities) El primer paso para construir la arquitectura de procesos es: Caracterizar el negocio en que est la organizacin esto se hace en trminos de sus Essential Business Entities (EBES) Ejemplos de entidades: En una empresa farmacutica de Investigacin y Desarrollo (R&D) se reconocen entidades como: Compuestos de medicinas, Pruebas clnicas, Lotes de componentes en bruto, etc. Esas son la esencia del negocio. Al administrar un programa modular en una facultad de una universidad se veran entidades como: Module Award Student assessment External Examiner Curriculum Appeal

Sin dichas entidades no existira el negocio correspondiente. Una entidad puede ser algo fsico: Un lote de compuesto para medicina, en donde pueda usted introducir la mano en el barril que lo contenga. Algo abstracto: Una prueba clnica (se ve que progresa pero no se toca) Totalmente Abstracto: Un cambio a una prueba clnica (doblar la potencia de las tabletas del compuesto).

13

MODELADO DE PROCESOS

Una factura no es una entidad esencial, es una entidad diseada si estamos hablando de una empresa que fabrica coches. Pero una empresa que se dedica a cobrar facturas si sern para ella entidades esenciales.

III.2.3.- Encontrando EBES

Podemos reunir a varias personas de la empresa y hacer una lluvia de ideas para que identifiquen las EBES del negocio mediante preguntas como: Qu hacemos? (What do we make?) Cars, Packs of biscuits, radios furnitures, bottled drinks. Qu vendemos? (What do we sell?) Cars, Pallets of pockets of biscuits, water, electricity, insurance policies, items of furnitures, packs of tablets. Qu lneas de productos tenemos? (What product lines do we have?) These models of cars, these range of biscuits, these designs of furniture. Qu cosas no podemos obtener fcilmente del exterior? (What things can we simply not get away from?) Estamos desarrollando medicinas, no las podemos obtener de las autoridades regulatorias. Construimos mquinas areas, no las podemos obtener del organismo regulador de seguridad. Somos una empresa acotada tenemos accionistas. Tenemos miembros del staff Las polticas de la empresa nos requieren que sigamos ciertos estndares de calidad. Quines son nuestros clientes internos? (who are our internal customers?) Investigadores, project managers, staff members, the board. Hay cosas que nuestros clientes tienen, o quieren o hacen, que pudieran ser EBES para nosotros? (Are there things that our customers have, or want, or do, that might be EBES for us?) Quejas de cliente, compras, saldos deudores, cuentas, prestamos, tarjetas de lealtad Qu cosas pensamos que hacen la diferencia de nuestra organizacin con la de otros en el mismo negocio? (What things do we think differentiate our organization from others in the same Business?)

14

MODELADO DE PROCESOS

Nuestro enfoque de calidad, nuestra cultura, nuestro expertis, nuestros precios, nuestra marca, nuestro enfoque al cliente. Qu suerte de cosas tratamos da a da? (What sort of things do we deal with dayin, dayout?) Maquinas de autos, proveedores de pisos, taladros, estaciones de potencia, quejas de cliente, fallas de maquinas, estndares de calidad. A qu eventos en el mundo exterior es decir fuera de la organizacin, necesitamos responder? (What events in the Outside world, the World outside our organization do we need to respond to?) Fallas de energa, drenajes tapados, quejas de clientes, cambios importantes en precios, nuevos aos financieros. Qu entidades de negocio se listan en nuestro modelo de datos corporativo? (What Business entities are listed in our corporate data model?) De que cosas guardan informacin nuestros sistemas de informacin? (what things do our information Systems keep information on?) Una vez que se obtiene la lista de EBES, la pasamos por varios filtros que comprueban que las entidades son esenciales para el negocio. Se recomienda guardar la lista original de EBES, antes de depurarla. En un futuro pudiramos reintegrar una de las EBES de la lista original a la lista depurada, agregar una nueva. Se supone que todas las EBES de la lista original son EBES (entidades) pruebe cada una anteponiendo a the. Si no tiene sentido encirrela entre corchetes [entidad] y as sucesivamente cada entidad. Pudiera ser desconcertante eliminar una entidad que para nosotros lo era; si somos una empresa que vende agua electricidad no sonara bien a water an electricity, an as encirrelas en corchetes para sealarlas como entidades no esenciales. Ponga corchetes a cualquier entidad diseada. Las facturas pudieran ser el pan de cada da del departamento de facturacin, pero para la empresa como un todo, no lo son. La organizacin no est en el negocio de emitir facturas, solo son un medio para cobrar. Las entidades con corchetes son solo roles, y ellas no son la esencia del negocio. El departamento de contabilidad es una entidad y es alguien para el negocio (al menos para el mismo departamento lo es) y diran la empresa no funcionara sin el departamento de contabilidad, es esencial. S, son esenciales pero NO SON LA ESENCIA, no estamos en el negocio de hacer cuentas; hacemos carros, entonces el departamento de contabilidad no es una EBE, es un rol.

15

MODELADO DE PROCESOS

III.2.4.- Cules EBES representan trabajo para la organizacin

III.2.4.1.- Dejando fuera de la lista Units of work (UOW) Despus de los primeros filtros a la lista de EBES original la hemos reducido posiblemente a la mitad. Los EBES que quedan son EBES verdaderas. Son cosas que tiene el negocio y son su materia prima. Ellas definen y caracterizan la organizacin. Nuestro segundo paso es decidir cules de esas EBES son entidades que tiene un tiempo de vida, durante el cul debemos darles seguimiento. Ellas son nuestras unidades de trabajo (UOWS) Units of Work. las EBES pueden ser UOWS esenciales y las entidades de negocio diseadas pueden ser UOWS diseadas. Por ejemplo, una prueba clnica es un UOW para una empresa farmacutica de investigacin y desarrollo: Inicia, procede y para, y despus le damos seguimiento. Un compuesto de medicina es un UOW: es inventado, probado y desarrollado, puesto en el mercado y posteriormente retirado del mercado. Y se le debe dar seguimiento durante todo su tiempo de vida y despus de l. Se requiere un conjunto de filtros posteriores para ayudarnos a desmembrar las EBES para dejar solo las que son UOWS. Encierre entre corchetes las EBES que claramente no sean UOWS para nosotros. La compra de un boleto de teatro ser un EBE para una oficina de correos. El boleto podra estar en nuestra lista de EBES candidatas pero podemos ponerlo entre corchetes porque el boleto no tiene un tiempo de vida en s mismo que sea de inters para nosotros. No nos interesa cmo est diseado, impreso y distribuido, solo es un mecanismo que se usa en el contrato. Existe para una compra exitosa y tiene derecho a ocupar un lugar en el rendimiento del proceso. A todo esto, rendimiento es un UOW y est en la lista. Es un UOW Para la oficina de correos? Encierre entre corchetes los EBES que no son UOWS para nosotros aun cuando lo sean para alguien. Un estndar de calidad tiene claramente un tiempo de vida si somos el grupo de control de administracin de calidad, que tiene responsabilidad de manejar los estndares del sistema de gestin de calidad. Ellos (los estndares) son nuestro pan de cada da y su tiempo de vida es un UOW para nosotros. Para alguien que utilice los estndares de calidad ellos son EBES, pero no UOWS. sea no sern componentes de sus procesos. Encierre entre corchetes los EBES que solo son roles que toman parte en el proceso.

16

MODELADO DE PROCESOS

El organismo regulador de seguridad es un EBE para una empresa que produce sealizaciones. Por ejemplo para el ferrocarril. Para nosotros no tiene sentido su tiempo de vida, es decir no nos preocupamos de l despus de su funcin de regulacin. Es un rol en nuestro proceso. Es tpico encontrar todo tipo de EBES en la lista de candidatos referentes a ttulos y puestos en la organizacin: CEO, Project manager, sales person etc. Es cierto que la empresa no podra operar sin el CEO, pero l no tiene tiempo de vida que debamos administrar. Encierre entre corchetes cualquier EBE que solo sea parte de otro EBE y no tenga tiempo de vida separado. Si fabricamos DVDS ellos probablemente son EBES y UOWS, pero el empaque de los DVD no es probablemente un EBE para nuestra empresa. Cada disco compacto que hacemos va en su empaque. Solo lo compramos y se lo ponemos al DVD. El disco s tiene un tiempo de vida, desde que es un trozo de plstico hasta el momento en que se reproduce en un aparato reproductor de DVDS. Algunos EBES pudieran no ser EBES en s mismos, pero s pudieran apuntar a otros EBES como sucede con las colecciones de cosas que forman otras cosas. Una empresa distribuidora de electricidad a la que llamamos El sistema de transmisin, considera a este un EBE sin el cul no estara en el negocio. Y tiene un real tiempo de vida de inters para nosotros, pero debemos darnos cuenta que el sistema de transmisin es una coleccin de activos, y un activo podra tambin estar en la lista. Entonces estaran en la lista de EBES: El sistema de transmisin y activo. Nuestra experiencia expertis debe estar en la lista, se puede pensar respecto a su tiempo de vida? Tal vez no. Pero el expertis est formado por los expertis individuales de los empleados y cada uno de ellos debe ser: seleccionado, desarrollado, mantenido y tal vez eliminado al final. Por tal motivo; expertis est en la lista. Como empresa de desarrollo farmacutico nos preocupamos de tener una buena tubera (Pipeline). Es un buen flujo de nuevas medicinas potenciales que van a travs de investigacin y desarrollo, esa tubera aparecer en nuestra lista de EBES, as como Compuesto de medicina. Podemos ver ambas EBES tambin como UOWS, la tubera es solo una pero est compuesta de muchos elementos.

17

MODELADO DE PROCESOS

III.2.5.- Encontrando EBES no visibles

Como en cualquier ejercicio de determinacin de requerimientos cmo sabremos que ya terminamos?, cmo sabremos que encontramos todo lo que tenemos? Hay varias maneras de saber si ya detectamos todas las UOWS. Examine los nombres de grupos y departamentos Un departamento existe a veces para tratar con varias UOWS, podemos observar que el departamento de anlisis qumicos trata con anlisis. Es anlisis un EBE y una UOW para la organizacin? El equipo de respuesta a emergencias trata con emergencias. El help desk trata con reportes de fallas. Debemos tener cuidado al buscar UOWS de esta manera, pudieran ser UOWS diseados. Utilice la frase Cambia a (Change to) frente a cada UOW candidata y vea si crea otro UOW. En una empresa farmacutica los empleados piensan que su UOW ha tratado con requerimientos de clnicas para el paquete de pacientes (de medicinas) para pruebas clnicas. Al observar encontramos que ellos en verdad lo hacan y tenan una UOW llamada Requerimientos para suministros para una prueba clnica (Request for supplies for a clinical trial) pero lo ms importante fue que pasaban mucho tiempo en realizar cambios de conciencia en los empleados de anlisis clnicos de modo que tenan otra UOW: Cambio a Requerimientos para suministros para una prueba clnica (Change to Request for supplies for a clinical trial). Un cambio llegaba, se trataba con el y finalmente deba incorporarse en la calendarizacin ajustada. Para cada requerimiento original podra haber varios cambios. Ponga la palabra coleccin de frente a cada UOW candidata y vea si crea otra UOW. Hay una sensacin en la cual la coleccin de cosas tiene su propia existencia? Como el portafolio de compuestos de medicina en una empresa farmacutica el rango de productos en una empresa fabricante de software. la lista de libros en impresin de un editor. Un editor no trata solo con ttulos aislados, maneja una lista de carcter y contenido en especial, es decir, la lista tiene su propio tiempo de vida y existencia aparte de los ttulos que maneja. Puntos clave: Un UOW es un EBE que tiene un tiempo de vida al cual le damos seguimiento, esos son EBES esenciales Otros UOW crecen desde entidades de negocio diseadas ms que de EBES, esos son UOWS diseadas. Algunos UOW son colecciones de otras cosas cambios a otras cosas.

18

MODELADO DE PROCESOS

III.2.6.- Consejos para la lluvia de ideas de la arquitectura de procesos

Trabaje con un rotafolio, ms que con un pizarrn blanco. As podr consultar la lista original de entidades, si escribi en el pizarrn ya la habr borrado. Trate la lluvia de ideas de EBES candidatas como verdadera lluvia de ideas, escrbalas todas sin discusin. La nica excepcin es aplicar la regla de a / the Para verificar si algo es una entidad. Cuando inicie el filtrado de EBES reales empiece con unas sencillas para que la gente entienda la idea; si hacemos carros, carro es un EBE real. Si diseamos carros, diseo de carro es un EBE real, pero CEO es un rol. Haga lo mismo cuando filtre EBES que tambin son UOWS. si hacemos carros, el carro es un UOW, si estamos en una industria reguladora, regulador es un EBE no una UOW. Escriba una oracin describiendo cada UOW, en particular para capturar su alcance. Es una tcnica de memorizacin para un trabajo posterior y para que lo entiendan otros lectores.

III.2.7.- Qu son las relaciones dinmicas entre UOWS

Nuestra lista ya est realizada respecto a esas EBES que son tambin UOWS, en seguida se analizarn las relaciones entre esas UOWS por ejemplo: El proceso de revisin anual del portafolio de productos quizs necesitaba informacin del proceso de anual de conciliacin de cuentas. Esos 2 procesos necesitan interactuar para intercambiar informacin, la pregunta es Cules relaciones son de inters? De modo que estamos interesados en las relaciones dinmicas entre los procesos, es decir concentrarnos en las relaciones dinmicas entre UOWS. Al revisar las relaciones diferentes que pueden existir entre procesos, vemos que esas aumentan cuando algunas UOWS necesitan de otras UOWS. Por ejemplo: Compuestos de medicinas candidatas, requieren de pruebas clnicas para implementarse. Habr veces en que varias pruebas estarn en proceso para el mismo compuesto. Cada prueba clnica requiere pacientes, ellos deben ser reclutados, se les deber dar la medicina o un placebo otra medicina comparativa y ser monitoreados y registrados. Segn las necesidades de la prueba podrn ser necesarios varios paquetes de pacientes para asignar a cada uno diferentes dosis. Habr millares de pacientes repartidos en esos paquetes. Compuesto, prueba clnica, paciente y paquete de pacientes todas son UOWS en la empresa farmacutica de Investigacin y desarrollo. Y existen relaciones dinmicas importantes entre ellos. Se resumen esas relaciones con la palabra neutra genera: Un compuesto candidato de medicina genera pruebas clnicas. Una prueba clnica genera pacientes. Un paciente genera paquetes de pacientes. Un proyecto genera paquetes de trabajo.

19

MODELADO DE PROCESOS

Un miembro del staff genera reclamos de gastos. Una orden genera lotes. La palabra genera quizs choca en ciertos casos pero se usa para significar necesita, requiere, llama para y activa. Y al decir A genera B significa que durante el ciclo de vida de un caso de la UOW A, casos de la UOW B sern necesitados/llamados para/... etc. De modo que durante el ciclo de vida de pruebas clnicas se necesitan pacientes, durante el tiempo de vida de un cliente se colocan ordenes por ese cliente. Durante el tiempo de vida de un portafolio nuevos productos son considerados y as sucesivamente. En ciertas ocasiones durante el tiempo de vida de un caso de UOW B, todos son contenidos dentro del tiempo de vida del caso de UOW A. pruebas clnicas debern ser completadas antes de que el desarrollo del compuesto de medicina sea completado. A veces los casos de B generados viven despus de que la generacin del caso A ha concluido. Un proyecto generar facturas para el cliente. Y su manejo puede mantenerse despus de terminado el proyecto. (Cobranza). La cardinalidad de las relaciones entre dos UOWS puede variar. cada caso de A genera ninguno, uno o muchos casos de B. una prueba clnica genera un reporte de prueba clnica, una prueba clnica genera muchos pacientes. Un tercer paso para construir la arquitectura del proceso es ir a travs de la lista de UOWS filtrada y determinadas las relaciones dinmicas, se construye un diagrama UOW en el que se ven las UOWS y las relaciones dinmicas entre ellas. Se nombran esas relaciones y se identifica su cardinalidad (uno a uno), (uno a muchos). Por ejemplo: el compuesto A requiere muchas pruebas clnicas.

20

MODELADO DE PROCESOS

Utilizamos las siguientes convenciones: Cada UOW se muestra como un hexgono conteniendo el nombre de la UOW en singular. Cada relacin genera se muestra como una flecha que va desde la UOW generadora a la UOW generada y adecuadamente etiquetada. Cuando se genera una UOW por un agente fuera de la organizacin de referencia indicamos la flecha viniendo de una nube que sugiere el mundo exterior. La figura 3.7 nos da un ejemplo de diagrama UOW que podemos realizar, indica las UOWS de un programa de una universidad y sus relaciones.

Fig. 3.7 El diagrama UOW para una facultad de administracin de una universidad

21

MODELADO DE PROCESOS

III.2.8.- PRODUCIENDO EL PRIMER CORTE DE ARQUITECTURA DEL PROCESO

Iniciamos este captulo con la aseveracin de que la verdadera arquitectura de procesos debera ser una invariante de la organizacin, determinada solo por el negocio en que est la organizacin. Se ha desarrollado una caracterizacin de aqul negocio en trminos de UOWS esenciales y sus relaciones dinmicas lo cul puede verse en el diagrama UOW de la figura 6.4. El prximo paso es producir el primer corte de la arquitectura del proceso. Es puramente mecnico y se utiliza el conocimiento de los 2 captulos anteriores. (4.- Relaciones entre procesos y 5.- Tres tipos bsicos de procesos).

III.2.8.1.- Primero.- establecemos la hiptesis de que para cada UOW en el

diagrama UOW hay tres procesos: Case Process (CP), Case Mangement Process (CMP) y Case Strategy Process (CSP). As para la UOW Customer Call, sabemos que Handle a Custome Call, Manage the Flow of Customer Call y Maintain a Strategic view of Customer Call aparecern todas en alguna parte de la arquitectura del proceso. Por definicin si Customer Call es una UOW, debemos darle seguimiento durante su tiempo de vida. Es como se ve en el CP despus de que corre una instancia, debido a que habr muchas en proceso en cualquier momento, se requiere administrar ese flujo de instancias, labor que realiza el CMP debido a que es esencial para el negocio o lo suficientemente importante para disearlo, en alguna parte necesitamos tomar una vista estratgica de todo; es lo que hace el CSP.

III.2.8.2.- Segundo.- Establecemos la hiptesis de que relacin genera entre 2

UOWS en el diagrama UOW, puede ser traducida en relaciones entre los procesos correspondientes. Aqu utilizamos el resultado del captulo 5, examinamos cada relacin genera y decidimos si es un Task Force o una Service Relationship. Si A genera B y es una relacin de servicio entonces se utiliza la regla de traduccin de la fig. 3.8:

22

MODELADO DE PROCESOS

Fig. 6.4.- Traduciendo una relacin de servicio entre UOWS, entre procesos

Si la relacin entre A y B es una Fuerza de tarea (Task Force) entonces se utiliza la regla de traduccin de la figura 6.5. Note que en ambos casos hemos dibujado el conjunto completo de relaciones entre CP y CMP: Inicio, Monitoreo, intervencin, parada, negociacin y reporteo.

Fig. 6.5 Traduciendo una relacin de Fuerza de tarea entre UOWS, entre procesos

23

MODELADO DE PROCESOS

La figura 6.6 muestra el diagrama UOW que pudiramos dibujar para el rea de una compaa, para realizar el soporte al sistema de informacin que atiende los requerimientos del negocio.

Fig. 6.6 Un diagrama UOW para el soporte al sistema de informacin que atiende los requerimientos del negocio.

Hay un requerimiento del sistema, el cual tiene un tiempo de vida al que se le da seguimiento y durante el cual aumentan los cambios. Igualndolo a un sistema que tambin tiene un tiempo de vida. Durante el tiempo de vida del sistema hay nuevas versiones que se liberan, el seguimiento requiere nuevos productos de trabajo a ser generados, y as sucesivamente. Dedique un tiempo a analizar esta dinmica de la organizacin. Sabiendo cmo trabajar con fuerzas de tarea (task forces) y relaciones de servicio (service relationships), podemos de manera mecnica transformar el modelo UOW de la figura 6.6 en el Primer corte de arquitectura de la figura. 6.7

24

MODELADO DE PROCESOS

Fig. 6.7 El primer corte de arquitectura del proceso, del diagrama UOW de la Fig. 6.6

Hemos solamente etiquetado las relaciones encapsuladas, las otras son obvias al contexto. Por lo general omitiremos los CSPS (Case Strategy Process) de la arquitectura del proceso, a menos que tengamos un inters especfico en ellos para nuestro propsito.

III.2.9.- PRODUCIENDO EL SEGUNDO CORTE DE ARQUITECTURA DEL PROCESO

El ltimo paso fue puramente mecnico, el proceso de arquitectura resultante representa de alguna manera lo mejor que podemos esperar encontrar en la forma de procesos para los UOW que hemos identificado. La prctica a menudo demuestra que existen ms. Vamos a explorar algunas de las maneras en que podemos reducir el Primer corte de arquitectura (refinar) de procesos, al segundo corte. (Ver figura 6.7).

25

MODELADO DE PROCESOS

III.2.9.1.- Agrupando un CMP de fuerza de tarea (Task Force) dentro de un CP

Donde se ha transformado una relacin de fuerza de tarea (Task Force) y el CMP que recibe los requerimientos se muestra como encapsulado dentro del CP solicitante, podemos decidir encapsular el CMP dentro del CP particularmente si es trivial o cercanamente trivial. Por qu tiene esto sentido? Sabemos en este caso que las cosas administradas por el CMP solo han sido requeridas por ese nico CP, de otra manera sera una relacin de servicio (service relationship) , de modo que es buena idea considerar el encapsular el CMP dentro del CP. Como ejemplo el trozo del Primer corte de arquitectura a la izquierda de la figura 6.8 se encapsula para dar la parte derecha de esa misma figura.

Fig. 6.8 Encapsulando el CMP dentro del CP solicitante.

Esto surge de la relacin de la UOW Proyecto A genera paquete de trabajo y de un reconocimiento de que la relacin es una relacin tipo Task Force. El Proyecto establece paquetes de trabajo que nacen bajo su propia iniciativa, no depende de un servicio externo que realiza paquetes de trabajo. Puesto de otra manera (vea la Fig. 6.8): Handle a Project (CP) hace su propio CMP para paquetes de trabajo. Es importante resaltar que al encapsular el CMP dentro del CP no quiere decir que no exista el CMP que no se realiza ese trabajo de administracin para ese CP, solo significa que est ubicado dentro del CP y que es mejor modelarlo as. Se tiene la completa libertad de dejarlo fuera sin encapsular si as conviene a nuestros propsitos.

III.2.9.2.- Tratando con relaciones Genera de cardinalidad 1: 1

En algunos casos tendremos en nuestro diagrama UOW una instancia de un caso A que genera una instancia B a lo que llamaremos relacin 1: 1. Podramos haber esbozado: Una compra de cliente genera Una factura Una prueba clnica genera un diseo de Case Report Form. Un documento en borrador genera un documento aprobado Un solicitante de empleo genera un miembro del Staff.

26

MODELADO DE PROCESOS

En una relacin de servicio (service relationship) a diferencia de una relacin de fuerza de tarea (Task Force) se debe dejar separados el CP y el CMP.

III.2.9.3.- Tratando con interacciones de liberacin y cadenas de liberacin

La transformacin estndar siempre produce interacciones de liberacin del case requerido, al que requiere. Cuando un proyecto genera un paquete de trabajo, se supone que el paquete de trabajo libera algo hacia el proyecto y as sucede en realidad. En otras situaciones la relacin genera es ms de dispara y olvida, de modo que cuando tengamos el primer corte de arquitectura frente a nosotros, se puede hacer otra revisin de la interaccin libera (deliver) y hacer la pregunta Esto sucede en realidad? Algo se libera realmente?, si la respuesta es NO, se puede borrar esa interaccin. Viendo otra situacin, suponga que: A genera B Genera C genera D en el diagrama UOW. Esto nos lleva al primer corte de arquitectura de la figura 6.9. Note como la cadena de liberacin es de: CP (D) al CP (C), al CP (B), y al CP (A), siempre es enriquecedor pensar esto y compararlo con la realidad. A menudo se va a encontrar que la cadena de liberacin mencionada se corto-circuita y que la relacin actual se muestra al extremo inferior de la figura 6.9. (Diagrama refinado).

Fig. 6.9 Algunas cadenas de liberacin pueden ser Corto-Circuitadas

27

MODELADO DE PROCESOS

III.2.9.4.- Tratando con colecciones

Vimos anteriormente lo que es una coleccin y que una UOW puede ser una coleccin de otras UOWS. Un sistema de tubera en una empresa farmacutica genera medicinas candidatas Un proyecto genera paquetes de trabajo Un portafolio de productos genera productos Viendo el primer ejemplo nos muestra la figura 6.11.

Fig. 6.11 Primer corte de arquitectura de proceso para una tubera y su medicina candidata

Pensamos que el proceso Manage the flow of candidate drugs es cercano a la figura, entre ms lo revisamos, sospechamos que Managing the flow of candidate drugs es actualmente parecido a handling the Pipeline. De modo que el CMP para el objeto atmico es el mismo o al menos est contenido en l. El CP para la coleccin. Y de nuevo estamos en la situacin de encapsular el CMP dentro del CP de la coleccin quedndonos el diagrama:

Fig. 6.12 Proceso reducido para una Tubera y su medicina candidata.

28

MODELADO DE PROCESOS

III.2.9.5.- Tratando con CMP vacas

Es poco comn para un CMP estar vaco. Algunos casos no necesitan o no obtienen case Management.

III.2.9.6.- Del primero al Segundo corte de arquitectura

Estamos en la posicin de reducir el Primer corte de arquitectura de la figura 6.7 a un segundo corte ms realista en la figura 6.13, podr notar que gran parte de la reduccin ( simplificacin) ha ocurrido alrededor del Handle the system, no siendo sorprendente que haya solo uno y por eso es mucho del case Management mismo; tal reduccin se puede hacer para pequeos UOWS por ejemplo: Work Product y Change to Work product donde los requerimientos para ellos vienen de varios lados y el flujo se administra como servicio, tambin se tienen corto-circuitadas 2 cadenas de liberacin (Delivery) para reflejar la realidad.

III.2.9.7.- Entidades de negocios Diseadas y UOWS (Designed Business

Entities And UOWS) Cuando revisamos las EBES candidatas buscando UOWS encerramos varias entre corchetes (parntesis cuadrados) para sealarlas como no tiles en ese momento. Siendo en esa ocasin consideradas EBES diseadas. Al no seleccionarlas no apareceran en el diagrama UOW, por la razn de que si queremos una arquitectura de proceso solamente basada en el negocio de la organizacin y este es independiente de cmo se escoge hacer negocio, entonces debemos eliminar de la lista las EBES diseadas. El resultado es que nuestra arquitectura del proceso realmente se concentra en esos procesos que deben existir debido a que estamos en este negocio. No hay procesos que estn ah por alguna decisin acerca de cmo debemos hacer nuestro negocio. Esto da a nuestra arquitectura de procesos una pureza muy til en muchas situaciones. Si queremos hacer una reingeniera no debemos estar aislados por los mecanismos normales. Del otro lado si estamos construyendo una vista Tal cual de la organizacin, entonces querremos ver procesos en la arquitectura que existen debido a que es la manera en que decidimos hacer el negocio (EBES diseadas), de modo que podemos tomar las EBES encerradas en corchetes de las UOWS diseadas y dejarlas generar procesos en la arquitectura.

29

MODELADO DE PROCESOS

Puntos clave: Para construir una arquitectura de procesos: 1. - Identificar las EBES 2.- Usar los filtros para extraer las UOWS 3.- Hacer el mapa de las relaciones entre UOWS 4.- Transformar el diagrama UOW en el primer corte de arquitectura de procesos usando las 2 transformaciones estndar (Task Force y Service Relationship). 5.- Considerar agrupar (encapsular) algunos procesos, principalmente donde estn consideradas relaciones Task Force. 6.- Comparar la arquitectura resultante contra el mundo real para validar las relaciones. 7.- Restaurar las UOWS Diseadas si fuera necesario. 8.- Hacer cualquier reduccin simplificacin posible y finalizar el segundo corte de proceso de arquitectura.

III.2.10 Caso de estudio 2

Para una empresa que proporciona el servicio de agua Intervienen en el trabajo: Activos, Drenaje, Alcantarillas, Consumibles, Embalses, etc. Del taller de lluvia de ideas surgieron las siguientes EBES: Cliente Contacto (por un cliente) Trabajo Muestra (de agua) Inspeccin Notificacin del cliente Requisicin de materiales Activo Historia de un activo [Notificacin estatutaria] [Evento/ Incidente] [Junta] [Medidor] Esto nos lleva al diagrama modelo de UOW de la figura 6.16, no sorprendindonos que debido al alcance del estudio el faro que nos alumbra es Trabajo y sus UOWS vecinos. Sirve de base para el diagrama de arquitectura de procesos 6.17. Las discusiones en el taller de lluvia de ideas llevan a: El UOW Activo se elimin porque el proceso que involucra activos queda fuera del alcance del modelo segn nuestros intereses. Ellos eran del negocio de los ingenieros quienes los especificaron, procuraron y los mantuvieron funcionando.

30

MODELADO DE PROCESOS

Varias fuentes de requerimientos para Trabajos (incluyendo el mantenimiento peridico de activos y requerimientos planeados de Historia tienen una tendencia a caer en una rea particular) Se unieron y se diagraman como una nube que representa un recurso externo que NO representa inters para nosotros para nuestra arquitectura. Todos los UOWS fueron soportados por funciones de servicio de tal suerte que se ven en la arquitectura los CMP. Las relaciones entre Handle a Job y Manage Customer Notifications son un poco diferente de lo usual. Aqu en un requerimiento Handle a Job, requiere Manage Notifications Flow para organizar las Notificaciones para todos los clientes. Manage Notifications Flow se da para una sola ubicacin geogrfica, determina todos los clientes a quienes se debe enviar la notificacin, entonces enva una notificacin a cada uno. Posiblemente no se enriquece el diagrama si separa Manage Notifications Flow y Handle a Customer Notification, el proceso resultante es pequeo. Ellos han sido reemplazados por un solo proceso: Handle Customer Notifications, el cual toma una ubicacin geogrfica y enva todas las notificaciones para esa ubicacin. Eso se muestra en el segundo corte de arquitectura del proceso. Note tambin cmo Handle a Job no se interesa en saber el resultado de la notificacin a clientes, de modo que no hay cierre de ese requerimiento. El tiempo de vida de Clientes se quit del alcance del diagrama, luego desaparecen tambin Manage Customer Flow y Handle a Customer. Alguna reduccin es posible si se conoce la situacin real, en particular todos los contactos se hacen por telfono y es el sistema telefnico mismo el que hace tal : Contact Flow Management segn se requiere. Por esa razn Manage Contact Flow se ha eliminado. Se muestra el resultado del segundo corte de arquitectura del proceso en la fig. 6.18.

31

MODELADO DE PROCESOS

Fig. 6.16 Modelo UOW para una compaa utilitaria de administracin de puestos.

Fig. 6.17 Primer corte de Arquitectura de proceso para una compaa utilitaria de administracin de puestos.

32

MODELADO DE PROCESOS

Fig. 6.18 Segundo corte de Arquitectura de proceso para una compaa utilitaria de administracin de puestos.

Puntos clave: La arquitectura de procesos es un faro o reflector que enfoca nuestra atencin en el rea de la actividad organizacional en la que estamos interesados. Incluyendo unidades de trabajo ms dbiles (diseadas) se incrementa la intensidad del reflector. No tiene sentido el trabajo en el cual se estn sucesivamente descomponiendo procesos. Estamos agregando ms nodos a la red de procesos.

33

MODELADO DE PROCESOS

III.2.11.- Caso de estudio 3

Suponga una empresa que produce software y que tiene un rango de productos. Durante el tiempo de vida del producto se proponen cambios a l. Ocasionalmente se revisan los cambios propuestos, algunos se eliminan y otros se incorporan a la nueva versin del producto. Una lluvia de ideas de EBES nos dara. Producto (product) Propuesta de Cambio (Change proposal) Version (Release) Venta (sale) Cliente (Customer) Cuales de ellos son UOWS? en otras palabras, dicho de otro modo, Cul de ellos tiene un tiempo de vida que puede ser atendido por la organizacin? Para este ejercicio pudiramos decidir que no nos han preocupado las ventas y mercadotecnia, solo la generacin del producto para venderlo. De ah la lista de UOWS queda: Producto (product) Propuesta de Cambio (Change proposal) Version (Release) Tan lejos como el grupo de desarrollo se interese, las ideas para nuevos productos vienen del exterior, quizs una funcin de mercadotecnia dentro de la empresa. Dentro del tiempo de vida de un producto se liberan versiones. Las propuestas de cambio acerca de los productos vienen de fuera del grupo (clientes en particular, se pudiera sospechar) y surgen durante la administracin del producto mismo. El diagrama UOW se vera como la figura 6.19.

Fig. 6.19 Diagrama UOW para un grupo de desarrollo en una empresa de productos de software

De ah se puede deducir el primer corte de arquitectura del proceso como la figura 6.20.

34

MODELADO DE PROCESOS

Cada producto administra sus propias versiones y se hace una a la vez por cada producto. El CMP Manage The Flow of Releases no existe as que lo eliminaremos. Podemos asumir que el negocio de decidir en nuevos producto Manage the flow of Products est fuera del rea que ilumina nuestro reflector y se logra ver en la figura 6.21 del segundo corte de arquitectura del proceso. Ahora podemos ver dentro de los procesos individuales, de la figura 6.22 a la 6.25 son RADS incompletos. Para los 4 procesos nos hemos concentrado solo en la actividad alrededor de las relaciones entre procesos; no estamos interesados en la administracin de cambios.

Fig. 6.20 Primer corte de arquitectura de proceso de la figura 6.19

35

MODELADO DE PROCESOS

Fig. 6.21 segundo corte de arquitectura de proceso de la figura 6.20

Fig. 6.22 Parte de Handle a Product

36

MODELADO DE PROCESOS

Fig. 6.24 Parte de Manage the flow of Change Proposals

37

MODELADO DE PROCESOS

Fig. 6.25 Parte de Handle a Change Proposal

38