Modelado Unidad 3

UNIDAD III ARQUITECTURA DE PROCESOS

III.1.- Modelado de relaciones entre procesos

III.1.1.- CASE (CASE PROCESS)

Todo el trabajo en una organización 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 básicos o fundamentales para la organización. Si somos una cadena de hamburguesas y nos llega un cliente a solicitar una hamburguesa, tendremos un método estandarizado para tratarlo. Eso es lo que llamaremos el CASE PROCESS o proceso básico o fundamental.

Un proceso básico puede “dar seguimiento”, “tratar” o “manejar” una situación específica dentro del negocio. Estos procesos básicos o CASE PROCESS los podemos intanciar, es decir los podemos llamar a ejecución una o múltiples 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 están preparando su orden, etc. Es decir cada uno está en una fase distinta del mismo proceso. Un proceso también 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 compañía farmacéutica de medicamentos tiene 15 compuestos en proceso, el departamento clínico esta “Corriendo” 87 pruebas clínicas; entonces decimos de forma normal que está operando una instancia de un CASE PROCESS.

Los Case Process pueden estar en diferentes etapas en la compañía farmacéutica 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 clínicos, el compuesto C está esperando trámites regulatorios de aprobación 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 diseño de procesos es el nombre que le damos a los mismos, es muy importante el referenciarnos a ellos de una manera que fácilmente los podamos distinguir. De esta manera mientras más utilicemos la convención será más fácil el identificar y darnos una idea de lo que tratan cada uno de los tres tipos de procesos: Case Process (Procesos básicos)

MODELADO DE PROCESOS

Case Management Process (Procesos administrativos), Case Strategic Process (Procesos estratégicos).

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 producción” o “preparar el reporte del proyecto”

Cuando la UOW no es la entrada ni la salida utilizamos también podemos utilizar manejar (Handle), por ejemplo “manejar una campaña de mercadeo” o “manejar la compra de una casa”

En el método 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 producción”, “una campaña de mercadeo”, “una queja de cliente”. Pero también se pueden dar nombres que impliquen múltiples instancias cambiando un por el, por ejemplo “la orden de producción”, “la campaña de mercadeo”, “la queja de cliente”. Esto es parte de los convencionalismos que poco a poco se van dando con la práctica 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 ¿Cuándo inicia un Case Process? Podemos decir que es cuando llega el caso. Pero ¿Cómo 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 ¿dónde inicia el proceso de compra de una casa?, cuando visito la casa, cuando hago una oferta o cuando firmo los roles. ¿dónde 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 fácil determinar cuándo 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, ¿dónde 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.

1


También 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 “aprobación del crédito” pero en un momento el proceso termina cuando el crédito es rechazado. No es muy lógico nombrar un proceso de aprobación cuando una de sus salidas es el rechazo del mismo. Un mejor nombre sería “manejo de solicitudes de crédito”.

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 estén compartiendo recursos entre ellos. Por ejemplo un cliente (caso) puede estar en el proceso de solicitar un crédito, otro en el proceso de llevar la documentación, otro en el proceso de aprobación, etc.

La organización debe controlar el flujo de case process y los recursos que están en diferentes instancias. Se pueden estar en fases de calendarización, manejo de recursos, asignación 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 crédito” consideramos, para efectos del diseño, 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 interactúan pero separarlos es vital para el proceso de análisis y diseño.

En los Case management process (proceso administrativo de caso) esperamos ver acciones que tratan con:

PlaneaciónReporteoMonitoreoCalendarizaciónAsignación de recursosPriorizaciónNegociaciónReconciliación

Por lo que esperaríamos ver roles como:

ConsejoManagersEquipos administrativosComité administrativoSupervisor

2


Auditor del progreso del procesoEquipo de planeaciónGrupos 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 sería la llegada de la solicitud de la aplicación al seguro y las salidas serían la aceptación 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 administración es que responden a muchas situaciones e intervienen según se necesite y es proactiva en muchas otras situaciones. Podríamos esperar que un case management process tenga múltiples iniciadores (triggers) correspondientes a las distintas posibles situaciones que invocarían 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 típicos de un case management process.

III.1.2.1.- Componentes típicos 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 casoEscuchando y tratando con la terminación de una instancia de un caso Escuchando y tratando con excepciones y errores de una instancia de un

caso Determinando qué recursos deberán 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 algún (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.

Escencialmente el case management process toma la responsabilidad para las intancias que se ejecutan en los case process. El CMP Administra el flujo de

3


case process. En pocas palabras es un case process para administración 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 término “Administrar el flujo de”

Podemos tener los siguientes nombres de procesos administrativos:

Administrar el flujo de órdenes de compraAdministrar el flujo de quejas de clienteAdministrar el flujo de lotes de producciónAdministrar el flujo de reportes de proyectosAdministrar el flujo de campañas de mercadeoAdministrar 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 línea de producción, 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 línea de producción”, tenemos que un solo case management process (CMP), que en este caso convendría nombrar “administrar el flujo de cambios en la línea de producción” puede administrar múltiples instancias del case process(CP). Este proceso administrativo puede iniciar, monitorear, controlar, etc. A diferentes líneas de producción, 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 fábrica de electrodomésticos 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 artículo por ejemplo una licuadora. Para producir esta licuadora se necesita de un proceso que permita determinar 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

4

Manejo de una orden

Prepara un lote

Administración del flujo de lotes

IRequiere

A

inic

ia

I

Entrega a


después 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 sería “manejo de una orden”. Pero, como ya dijimos, una fábrica maneja muchas órdenes distintas que se procesan por lotes y que requieren de cierta preparación, asignación de recursos (que componentes va a utilizar), modificaciones de la línea, además se requiere decirle al proceso cuando puede iniciar. Para ello necesitaríamos otra UOW llamada “preparación de lotes”.

Claro que la fábrica maneja muchas instancias de ese proceso llamado “preparación de lotes”, este proceso se encargaría de iniciarlos, de controlarlos y administrarlos. Entónces tenemos un case management process al que llamaríamos “administración del flujo de lotes”.

Pongamos estos conceptos en vocabulario Riva:

1. - Una instancia del proceso “Manejo de una orden” interactúa con “Manejo del flujo de lotes” para solicitar que una nueva orden sea producida.

2. - “Administración del flujo de lotes” calendariza el lote planeado3. - “Administración del flujo de lotes” activa el proceso “Preparar un lote”, en el

momento apropiado.4. - Una vez satisfecha la orden “Preparar un lote” interactúa con “Manejo de una

orden” para reportar completa la orden y terminar el proceso.

Fig. 3.1 Relación Básica de Servicio

Simbología:

Interacción entre 2 procesos, la flecha va en el sentido del que inicia la interacción al otro

I

A

5

Manejo de una orden

Preparar un lote

Manejo del flujo de lotes

IRequiere

A

Inic

ia

I

Entrega a

Manejo del flujo de órdenes

I

Negocia

I

Negocía


Activación de; la flecha va en el sentido del que hace la activación al otro activado

CP = Case ProcessCMP = Case Management Process

Proceso

Nombres de procesos:

Handle a, Prepare a = Case processManage a Flow of = Case Management process

Según nuestra metodología en la que habíamos comentado que cada UOW requiere de un case process y de un case management process. Estaría faltando un proceso que se llame “administración del flujo de órdenes”. Veamos la función que tendría 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 “administración del flujo de lotes”. Entonces sería necesario el proceso de “administración del flujo de órdenes”. Quien sería el responsable de llevar a cabo estas negociaciones. La forma como lo representaríamos en el lenguaje Riva sería:

Fig. 3.2 Relación Básica de Servicio con Negociación

6


Supongamos ahora que deseamos agregar la parte de monitoreo de los lotes para determinar si están trabajando en forma apropiada o si requieren ser detenidos por cuestiones de calidad. En el siguiente diagrama se muestra la representación de ese monitoreo que se estaría realizando.

Fig. 3.3 Relación General de Servicio

Ahora supongamos que esta relación también es utilizada por otras UOW dentro de la organización. En esta caso tenemos un departamento de investigación y desarrollo que desea probar los diseños de nuevos productos en la línea de producción, los requerimientos y lotes que manejan son distintos a los de la producción de artículos de línea, 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 línea de producción. La UOW sería “producto potencial”. Traduciendo al lenguaje Riva, la representación quedaría como sigue:

ReportaI

-Monitorea-Interviene

-DetieneI

Negoci

I

Negocia

I

Administrar el flujo de ordenes

Entrega a

I

IniciaA

RequiereI

Administrar el flujo de

lotes

Preparar un lote

Manejo de una orden

7


Fig. 3.4 Contención para un servicio

Negocía con

I

Adminsitración del flujo

Negocia con

Entrega un lote

I

Inicia

RequiereI

Inicia

AManejo de

un producto potencial

IniciaA

Requiere

I

Negocia

I

Negocia con

A

Manejo del flujo de

productos potenciales

Entrega un lote

II

I

Administración del flujo

de lotes

Maneja una orden

Maneja un lote

8


III.1.3.- CASE ESTRATÉGICOS (CSP) (CASE STRATEGY PROCESS)

Toman la vista estratégica de los UOW’S 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 cómo tratar con eso? (Ejemplo. Cómo 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 cómo se desarrolla el software que se usa en Investigación y desarrollo (R & D) en la industria farmacéutica)

¿Está cambiando la naturaleza del UOW?

Los clientes de bancos están aumentando su tendencia a cambiar sus cuentas a otro banco debido a cambios en el cobro de comisiones. ¿Cómo se cambiará el manejo de las cuentas de los clientes para contrarrestar esa tendencia?.

¿Están cambiando los rangos ó volúmenes en el UOW?

Hay cambios en los tipos de cursos que toman los alumnos para su currícula. ¿Qué está sucediendo en el proceso de administración de cursos que los hace más populares?

¿Cuál 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 calendarización en el CMP, combinado con la reorganización de responsabilidades en CP?

¿Se están operando el CP y CMP de acuerdo a los procedimientos de la empresa?

La regulación de la industria tiene interés 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 implementación del CSP se hace mediante el añadido de hilos en los roles, relacionados con los temas estratégicos.

9


III.1.3.1 Nombrando Case estratégicos (Naming case strategy process)

Se pueden denominar:

Maintain a stretegic view of Purchase OrdersMaintain a stretegic view of Customer complaintsMaintain a stretegic view of Production BatchesMaintain a stretegic view of Project reportsMaintain a stretegic view of Marketing campaignsMaintain a stretegic view of House purchases

Nota: Se recomienda enfocarse en el área exacta de interés de este proceso y no preocuparse de los detalles de CP y CMP.

10


III.2.- PREPARANDO LA ARQUITECTURA DEL PROCESO

III.2.1.- Introducción

“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 interactúan al trabajar.

Process Architecture.- Nos muestra la película que dice qué tipos de procesos hay en la organización y cuáles relaciones dinámicas hay entre ellos.

No nos interesa una descomposición jerárquica estática como aparece en un organigrama jerárquico tradicional, porque así no es el mundo real.

“El mundo es una red dinámica de instancias que interactúan”

Al desarrollar módulos de software se busca tener en ellos alta cohesión y bajo acoplamiento para reducir las dependencias entre ellos al mínimo y reducir la propagación de errores; pero eso es porque el software es sintético. Y se hace al gusto y saber del diseñador. Un proceso de negocios típicamente no es sintético, se ha desarrollado organicamente, resultado de algo de diseño 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 organización está en este negocio en particular.

Es como si al tallar el mármol para una escultura se buscara la veta o línea 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 máximo posible las conexiones, se desea explotar cualquier cohesión 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 están porque decidimos trabajar en una cierta forma son procesos diseñados; estos últimos son candidatos a reingeniería, no los primeros.

“El error de alguien con experiencia en Ingeniería de Software, es que pretende partir un proceso sucesivamente en subprocesos y estos a su vez en otros subprocesos. Hasta llegar a una estructura jerárquica”. Pero el mundo no es tan ordenado y los procesos en una organización invariablemente están conectados en una red, más que estar contenidos en otra. (Como los subprocesos del Ing. De software). Por lo tanto los peligros de pensar jerárquicamente no deben desecharse al tratar con procesos y llegar a construir un organigrama así:

11

Market Review

Product Design

Product Development Sales Support


Fig. 3.5 No es una arquitectura de procesos, es más una partición arbitraria

Según la figura diríamos que el módulo Plan the Business es la suma de los resultados de sus módulos subordinados (dependientes). Lo cuál no nos dice qué relaciones dinámicas existen entre esos procesos.

“Las relaciones dinámicas son cruciales para el entendimiento de cómo trabaja una organización”

Es pues la organización: “Dinámica en red” en vez de “Composición jerárquica arbitraria”

Otra concepción igual de peligrosa que la anterior respecto de los procesos, auque nos da alguna idea de dinamismo es la siguiente:

Fig. 3.6 No es una arquitectura de proceso; es más una lista de silos.

Buscamos una arquitectura de procesos que sea derivada únicamente de un entendimiento de: En qué negocio está la organización

The business

Plan the Business

StaffAllocation

SalesPrediction

PlantPlanning

Carrying out the Business

MonitorThe business

12


Podemos decir “Si la organización está en este negocio luego entonces debe tener estos procesos”, “Esta es la fibra de la organización”, si la organización cambia el negocio en que está, luego entonces se espera que cambien también los procesos.

Si cambia la estructura de la organización de jerárquica a Matriz, no tiene porque cambiar la lista de procesos. Solo se debiera cambiar el cómo se hacen esos procesos. No cambia la lista de procesos aunque cambie la organización estructuralmente, sea un cambio de cultura ó fusión de departamentos.

Para dividir adecuadamente la organización 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 organización” esto se hace en términos de sus Essential Business Entities ó (EBE’S)

Ejemplos de entidades:

En una empresa farmacéutica de Investigación y Desarrollo (R&D) se reconocen entidades como: Compuestos de medicinas, Pruebas clínicas, Lotes de componentes en bruto, etc. Esas son la esencia del negocio.

Al administrar un programa modular en una facultad de una universidad se verían entidades como:

Module Award Student assessment External Examiner Curriculum Appeal

Sin dichas entidades no existiría el negocio correspondiente.

Una entidad puede ser algo físico: Un lote de compuesto para medicina, en donde pueda usted introducir la mano en el barril que lo contenga.Algo abstracto: Una prueba clínica (se ve que progresa pero no se toca)

Totalmente Abstracto: Un cambio a una prueba clínica (doblar la potencia de las tabletas del compuesto).

13


Una factura no es una entidad esencial, es una entidad diseñada si estamos hablando de una empresa que fabrica coches. Pero una empresa que se dedica a cobrar facturas si serán 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 furniture’s, packs of tablets.

¿Qué líneas 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 fácilmente del exterior? (What things can we simply not get away from?)

Estamos desarrollando medicinas, no las podemos obtener de las autoridades regulatorias.

Construimos máquinas aéreas, no las podemos obtener del organismo regulador de seguridad.

Somos una empresa acotada tenemos accionistas. Tenemos miembros del staff Las políticas de la empresa nos requieren que sigamos ciertos estándares de

calidad.

¿Quiénes 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 EBE’S for us?)Quejas de cliente, compras, saldos deudores, cuentas, prestamos, tarjetas de lealtad…

¿Qué cosas pensamos que hacen la diferencia de nuestra organización con la de otros en el mismo negocio? (What things do we think differentiate our organization from others in the same Business?)

14


Nuestro enfoque de calidad, nuestra cultura, nuestro expertis, nuestros precios, nuestra marca, nuestro enfoque al cliente.

¿Qué suerte de cosas tratamos día a día? (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, estándares de calidad.

¿A qué eventos en el mundo exterior es decir fuera de la organización, necesitamos responder? (What events in the ‘Outside world’, the World outside our organization do we need to respond to?)

Fallas de energía, drenajes tapados, quejas de clientes, cambios importantes en precios, nuevos años 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 información nuestros sistemas de información? (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 pudiéramos 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 enciérrela 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 sonaría bien ‘a water’ ó ‘an electricity’, aún así enciérrelas en corchetes para señalarlas como entidades no esenciales.

Ponga corchetes a cualquier entidad diseñada. Las facturas pudieran ser el pan de cada día del departamento de facturación, pero para la empresa como un todo, no lo son. La organización 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 dirían “la empresa no funcionaría 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


III.2.4.- Cuáles EBES representan trabajo para la organización

III.2.4.1.- Dejando fuera de la lista Units of work (UOW)

Después 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 organización.

Nuestro segundo paso es decidir cuáles de esas EBES son entidades que tiene un tiempo de vida, durante el cuál debemos darles seguimiento. Ellas son nuestras unidades de trabajo (UOW’S) ó Units of Work. las EBES pueden ser UOW’S esenciales y las entidades de negocio diseñadas pueden ser UOW’S diseñadas.

Por ejemplo, una prueba clínica es un UOW para una empresa farmacéutica de investigación y desarrollo: Inicia, procede y para, y después 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 después de él. Se requiere un conjunto de filtros posteriores para ayudarnos a desmembrar las EBES para dejar solo las que son UOW’S.

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 podría 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 interés para nosotros.No nos interesa cómo está diseñado, 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 estándar de calidad tiene claramente un tiempo de vida si somos el grupo de control de administración de calidad, que tiene responsabilidad de manejar los estándares del sistema de gestión de calidad. Ellos (los estándares) son nuestro pan de cada día y su tiempo de vida es un UOW para nosotros. Para alguien que utilice los estándares de calidad ellos son EBES, pero no UOW’S. ó sea no serán componentes de sus procesos.

Encierre entre corchetes los EBES que solo son roles que toman parte en el proceso.

16


El organismo regulador de seguridad es un EBE para una empresa que produce señalizaciones. Por ejemplo para el ferrocarril. Para nosotros no tiene sentido su tiempo de vida, es decir no nos preocupamos de él después de su función de regulación. Es un rol en nuestro proceso.

Es típico encontrar todo tipo de EBES en la lista de candidatos referentes a títulos y puestos en la organización: CEO, Project manager, sales person etc. Es cierto que la empresa no podría 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 DVD’S ellos probablemente son EBES y UOW’S, 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 plástico hasta el momento en que se reproduce en un aparato reproductor de DVD’S.

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 transmisión”, considera a este un EBE sin el cuál no estaría en el negocio. Y tiene un real tiempo de vida de interés para nosotros, pero debemos darnos cuenta que el sistema de transmisión es una colección de activos, y un activo podría también estar en la lista. Entonces estarían en la lista de EBES: “El sistema de transmisión” 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 farmacéutico nos preocupamos de tener una buena tubería (Pipeline). Es un buen flujo de nuevas medicinas potenciales que van a través de investigación y desarrollo, esa “tubería” aparecerá en nuestra lista de EBES, así como “Compuesto de medicina”. Podemos ver ambas EBES también como UOWS, la tubería es solo una pero está compuesta de muchos elementos.

17


III.2.5.- Encontrando EBES no visibles

Como en cualquier ejercicio de determinación de requerimientos ¿cómo sabremos que ya terminamos?, ¿cómo 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 UOW’S, podemos observar que el departamento de análisis químicos trata con análisis. ¿Es análisis un EBE y una UOW para la organización? El equipo de respuesta a emergencias trata con… emergencias. El help desk trata con reportes de fallas. Debemos tener cuidado al buscar UOW’S de esta manera, pudieran ser UOW’S diseñados.

Utilice la frase “Cambia a” (Change to) frente a cada UOW candidata y vea si crea otro UOW.

En una empresa farmacéutica los empleados piensan que su UOW ha tratado con requerimientos de clínicas para el paquete de pacientes (de medicinas) para pruebas clínicas. Al observar encontramos que ellos en verdad lo hacían y tenían una UOW llamada “Requerimientos para suministros para una prueba clínica” (Request for supplies for a clinical trial) pero lo más importante fue que pasaban mucho tiempo en realizar cambios de conciencia en los empleados de análisis clínicos de modo que tenían otra UOW: “Cambio a Requerimientos para suministros para una prueba clínica” (Change to Request for supplies for a clinical trial). Un cambio llegaba, se trataba con el y finalmente debía incorporarse en la calendarización ajustada. Para cada requerimiento original podría haber varios cambios.

Ponga la palabra “colección de” frente a cada UOW candidata y vea si crea otra UOW.

¿Hay una sensación en la cual la colección de cosas tiene su propia existencia?

Como el portafolio de compuestos de medicina en una empresa farmacéutica ó el rango de productos en una empresa fabricante de software. Ó la lista de libros en impresión de un editor. Un editor no trata solo con títulos aislados, maneja una lista de carácter y contenido en especial, es decir, la lista tiene su propio tiempo de vida y existencia aparte de los títulos 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 diseñadas más que de EBES, esos son UOW’S diseñadas.

Algunos UOW son colecciones de otras cosas ó cambios a otras cosas.

18


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

Trabaje con un rotafolio, más que con un pizarrón blanco. Así podrá consultar la lista original de entidades, si escribió en el pizarrón ya la habrá borrado.

Trate la lluvia de ideas de EBES candidatas como verdadera lluvia de ideas, escríbalas todas sin discusión. La única excepción 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 diseñamos carros, diseño de carro es un EBE real, pero CEO es un rol.

Haga lo mismo cuando filtre EBES que también 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 oración describiendo cada UOW, en particular para capturar su alcance. Es una técnica de memorización para un trabajo posterior y para que lo entiendan otros lectores.

III.2.7.- Qué son las relaciones dinámicas entre UOW’S

Nuestra lista ya está realizada respecto a esas EBES que son también UOWS, en seguida se analizarán las relaciones entre esas UOWS por ejemplo:

El proceso de revisión anual del portafolio de productos quizás necesitaba información del proceso de anual de conciliación de cuentas. Esos 2 procesos necesitan interactuar para intercambiar información, la pregunta es ¿Cuáles relaciones son de interés? De modo que estamos interesados en las relaciones dinámicas entre los procesos, es decir concentrarnos en las relaciones dinámicas 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 clínicas para implementarse. Habrá veces en que varias pruebas estarán en proceso para el mismo compuesto. Cada prueba clínica requiere pacientes, ellos deben ser reclutados, se les deberá dar la medicina o un placebo ú otra medicina comparativa y ser monitoreados y registrados. Según las necesidades de la prueba podrán ser necesarios varios “paquetes de pacientes” para asignar a cada uno diferentes dosis. Habrá millares de pacientes repartidos en esos paquetes.

Compuesto, prueba clínica, paciente y paquete de pacientes todas son UOWS en la empresa farmacéutica de Investigación y desarrollo. Y existen relaciones dinámicas importantes entre ellos. Se resumen esas relaciones con la palabra neutra “genera”:

Un compuesto candidato de medicina “genera” pruebas clínicas.Una prueba clínica “genera” pacientes.Un paciente “genera” paquetes de pacientes.Un proyecto “genera” paquetes de trabajo.

19


Un miembro del staff “genera” reclamos de gastos.Una orden “genera” lotes.

La palabra “genera” quizás 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 serán necesitados/llamados para/... etc.” De modo que durante el ciclo de vida de pruebas clínicas 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 clínicas deberán ser completadas antes de que el desarrollo del compuesto de medicina sea completado.

A veces los casos de B generados viven después de que la generación del caso A ha concluido. Un proyecto generará facturas para el cliente. Y su manejo puede mantenerse después 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 clínica genera un reporte de prueba clínica, una prueba clínica genera muchos pacientes.

Un tercer paso para construir la arquitectura del proceso es ir a través de la lista de UOWS filtrada y determinadas las relaciones dinámicas, se construye un diagrama UOW en el que se ven las UOWS y las relaciones dinámicas 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 clínicas.

20


Utilizamos las siguientes convenciones:

Cada UOW se muestra como un hexágono conteniendo el nombre de la UOW en singular.

Cada relación “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 organización 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 administración de una universidad

21


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

Iniciamos este capítulo con la aseveración de que la verdadera arquitectura de procesos debería ser una invariante de la organización, determinada solo por el negocio en que está la organización.

Se ha desarrollado una caracterización de aquél negocio en términos de UOWS esenciales y sus relaciones dinámicas lo cuál puede verse en el diagrama UOW de la figura 6.4.

El próximo paso es producir el primer corte de la arquitectura del proceso. Es puramente mecánico y se utiliza el conocimiento de los 2 capítulos anteriores. (4.- Relaciones entre procesos y 5.- Tres tipos básicos de procesos).

III.2.8.1.- Primero.- establecemos la hipótesis 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 aparecerán todas en alguna parte de la arquitectura del proceso. Por definición si Customer Call es una UOW, debemos darle seguimiento durante su tiempo de vida. Es como se ve en el CP después 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 diseñarlo, en alguna parte necesitamos tomar una vista estratégica de todo; es lo que hace el CSP.

III.2.8.2.- Segundo.- Establecemos la hipótesis de que relación “genera” entre 2 UOWS en el diagrama UOW, puede ser traducida en relaciones entre los procesos correspondientes. Aquí utilizamos el resultado del capítulo 5, examinamos cada relación “genera” y decidimos si es un “Task Force” o una “Service Relationship”. Si A genera B y es una relación de servicio entonces se utiliza la regla de traducción de la fig. 3.8:

22


Fig. 6.4.- Traduciendo una relación de servicio entre UOWS, entre procesos

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

Fig. 6.5 Traduciendo una relación de Fuerza de tarea entre UOWS, entre procesos

23


La figura 6.6 muestra el diagrama UOW que pudiéramos dibujar para el área de una compañía, para realizar el soporte al sistema de información que atiende los requerimientos del negocio.

Fig. 6.6 Un diagrama UOW para el soporte al sistema de información 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. Igualándolo a un sistema que también 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 dinámica de la organización.

Sabiendo cómo trabajar con fuerzas de tarea (task forces) y relaciones de servicio (service relationships), podemos de manera mecánica transformar el modelo UOW de la figura 6.6 en el Primer corte de arquitectura de la figura. 6.7

24


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 CSP’S (Case Strategy Process) de la arquitectura del proceso, a menos que tengamos un interés específico en ellos para nuestro propósito.

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

El último paso fue puramente mecánico, 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 práctica a menudo demuestra que existen más. 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


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

Donde se ha transformado una relación 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 sería una relación 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 relación de la UOW “Proyecto A genera paquete de trabajo” y de un reconocimiento de que la relación es una relación 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 administración 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 propósitos.

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 relación 1: 1. Podríamos haber esbozado:

Una compra de cliente genera Una facturaUna prueba clínica genera un diseño de Case Report Form.Un documento en borrador genera un documento aprobadoUn solicitante de empleo genera un miembro del Staff.

26


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

III.2.9.3.- Tratando con interacciones de liberación y cadenas de liberación

La transformación estándar siempre produce interacciones de liberación 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 relación “genera” es más de “dispara y olvida”, de modo que cuando tengamos el primer corte de arquitectura frente a nosotros, se puede hacer otra revisión de la interacción “libera” (deliver) y hacer la pregunta ¿Esto sucede en realidad? ¿Algo se libera realmente?, si la respuesta es NO, se puede borrar esa interacción.

Viendo otra situación, 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 liberación 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 liberación mencionada se corto-circuita y que la relación actual se muestra al extremo inferior de la figura 6.9. (Diagrama refinado).

Fig. 6.9 Algunas cadenas de liberación pueden ser Corto-Circuitadas

27


III.2.9.4.- Tratando con colecciones

Vimos anteriormente lo que es una colección y que una UOW puede ser una colección de otras UOW’S.

Un sistema de tubería en una empresa farmacéutica genera medicinas candidatas

Un proyecto genera paquetes de trabajoUn 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 tubería y su medicina candidata

Pensamos que el proceso Manage the flow of candidate drugs es cercano a la figura, entre más 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 atómico es el mismo o al menos está contenido en él. El CP para la colección. Y de nuevo estamos en la situación de encapsular el CMP dentro del CP de la colección quedándonos el diagrama:

Fig. 6.12 Proceso reducido para una Tubería y su medicina candidata.

28


III.2.9.5.- Tratando con CMP vacías

Es poco común para un CMP estar vacío. Algunos casos no necesitan o no obtienen case Management.

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

Estamos en la posición de reducir el Primer corte de arquitectura de la figura 6.7 a un segundo corte más realista en la figura 6.13, podrá notar que gran parte de la reducción (ó simplificación) ha ocurrido alrededor del Handle the system, no siendo sorprendente que haya solo uno y por eso es mucho del case Management mismo; tal reducción se puede hacer para pequeños UOW’S 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, también se tienen corto-circuitadas 2 cadenas de liberación (Delivery) para reflejar la realidad.

III.2.9.7.- Entidades de negocios Diseñadas y UOWS (Designed Business Entities And UOW’S)

Cuando revisamos las EBES candidatas buscando UOWS encerramos varias entre corchetes (paréntesis cuadrados) para señalarlas como no útiles en ese momento. Siendo en esa ocasión consideradas EBES diseñadas. Al no seleccionarlas no aparecerían en el diagrama UOW, por la razón de que si queremos una arquitectura de proceso solamente basada en el negocio de la organización y este es independiente de cómo se escoge hacer negocio, entonces debemos eliminar de la lista las EBES diseñadas.

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 estén ahí por alguna decisión acerca de cómo debemos hacer nuestro negocio.

Esto da a nuestra arquitectura de procesos una pureza muy útil en muchas situaciones. Si queremos hacer una reingeniería no debemos estar aislados por los mecanismos normales.

Del otro lado si estamos construyendo una vista “Tal cual” de la organización, entonces querremos ver procesos en la arquitectura que existen debido a que es la manera en que decidimos hacer el negocio (EBES diseñadas), de modo que podemos tomar las EBES encerradas en corchetes de las UOW’S diseñadas y dejarlas generar procesos en la arquitectura.

29


Puntos clave:

Para construir una arquitectura de procesos:

1. - Identificar las EBES2.- Usar los filtros para extraer las UOW’S3.- Hacer el mapa de las relaciones entre UOW’S4.- Transformar el diagrama UOW en el primer corte de arquitectura de procesos

usando las 2 transformaciones estándar (Task Force y Service Relationship).5.- Considerar agrupar (encapsular) algunos procesos, principalmente donde están

consideradas relaciones Task Force.6.- Comparar la arquitectura resultante contra el mundo real para validar las

relaciones.7.- Restaurar las UOW’S Diseñadas si fuera necesario.8.- Hacer cualquier reducción ó simplificación 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:

ClienteContacto (por un cliente)TrabajoMuestra (de agua)InspecciónNotificación del clienteRequisición de materialesActivoHistoria de un activo[Notificación estatutaria][Evento/ Incidente][Junta][Medidor]

Esto nos lleva al diagrama modelo de UOW de la figura 6.16, no sorprendiéndonos que debido al alcance del estudio el faro que nos alumbra es “Trabajo” y sus UOW’S 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 según nuestros intereses. Ellos eran del negocio de los ingenieros quienes los especificaron, procuraron y los mantuvieron funcionando.

30


Varias fuentes de requerimientos para “Trabajos” (incluyendo el mantenimiento periódico 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 interés para nosotros para nuestra arquitectura.

Todos los UOW’S 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 ubicación geográfica, determina todos los clientes a quienes se debe enviar la notificación, entonces envía una notificación a cada uno. Posiblemente no se enriquece el diagrama si separa Manage Notifications Flow y Handle a Customer Notification, el proceso resultante es pequeño. Ellos han sido reemplazados por un solo proceso: Handle Customer Notifications, el cual toma una ubicación geográfica y envía todas las notificaciones para esa ubicación. Eso se muestra en el segundo corte de arquitectura del proceso.

Note también cómo Handle a Job no se interesa en saber el resultado de la notificación 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 también Manage Customer Flow y Handle a Customer.

Alguna reducción es posible si se conoce la situación real, en particular todos los contactos se hacen por teléfono y es el sistema telefónico mismo el que hace tal : “Contact Flow Management” según se requiere. Por esa razón “Manage Contact Flow” se ha eliminado.

Se muestra el resultado del segundo corte de arquitectura del proceso en la fig. 6.18.

31


Fig. 6.16 Modelo UOW para una compañía utilitaria de administración de puestos.

Fig. 6.17 Primer corte de Arquitectura de proceso para una compañía utilitaria de administración de puestos.

32


Fig. 6.18 Segundo corte de Arquitectura de proceso para una compañía utilitaria de administración de puestos.

Puntos clave:

La arquitectura de procesos es un faro o reflector que enfoca nuestra atención en el área de la actividad organizacional en la que estamos interesados.

Incluyendo unidades de trabajo más débiles (diseñadas) se incrementa la intensidad del reflector.

No tiene sentido el trabajo en el cual se están sucesivamente descomponiendo procesos.

Estamos agregando más nodos a la red de procesos.

33


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 versión del producto. Una lluvia de ideas de EBES nos daría.

Producto (product)Propuesta de Cambio (Change proposal)Version (Release)Venta (sale)Cliente (Customer)

¿Cuales de ellos son UOW’S? en otras palabras, dicho de otro modo, ¿Cuál de ellos tiene un tiempo de vida que puede ser atendido por la organización? Para este ejercicio pudiéramos decidir que no nos han preocupado las ventas y mercadotecnia, solo la generación del producto para venderlo. De ahí la lista de UOW’S 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, quizás una función 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 administración del producto mismo. El diagrama UOW se vería como la figura 6.19.

Fig. 6.19 Diagrama UOW para un grupo de desarrollo en una empresa de productos de softwareDe ahí se puede deducir el primer corte de arquitectura del proceso como la figura 6.20.

34


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 administración de cambios.

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

35


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

Fig. 6.22 Parte de Handle a Product

36


Fig. 6.24 Parte de Manage the flow of Change Proposals

37


Fig. 6.25 Parte de Handle a Change Proposal

38

Modelado Unidad 3

Documents

Transcript of Modelado Unidad 3