Texto Universitario NOTACION de PROCESOS

NOTACIÓN DE PROCESOS DE NEGOCIOS

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Universidad Continental Material publicado con fines de estudio Primera edición Huancayo, 2015

Pág. 2


PRESENTACIÓN Notación de Procesos de Negocio es una asignatura que proporciona conocimiento sobre los fundamentos de Business Process Management, a través de un trasfondo histórico para comprender mejor la evolución de la ingeniería de procesos. Asimismo se considera los conceptos de implementación, para conocer y entender las definiciones que facilitan comprender el alcance de BPM, la segunda parte integra a los modelos de procedimiento el apoyo tecnológico en cada una de las capas del BPM y finalmente se muestra la notación BPMN con el objetivo de aplicarlo a casos de negocios.El resultado de aprendizaje: Al finalizar la asignatura el estudiante será capaz de elaborar modelos de diversos procesos de negocio, utilizando los principios de Business Process Management (BPM) y elementos de notación de Business Process Model and Notation (BPMN), basado en una plataforma de diseño, simulación y automatización de procesos como representación estándar para las necesidades de una organización.

El presente material consta de cuatro unidades: Unidad I: ENFOQUE: BUSINESS PROCESS MANAGEMENT (BPM)n presenta conceptos, y principios básicos, la organización y estructura de BPM. Unidad II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO BUSINESS PROCESS MANAGEMENT BPM presenta conceptos y las relaciones entre estándares existentes para la gestión empresarial basada en procesos. Unidad III:

BUSINESS PROCESS

MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN presenta los elementos de notación de Business Process Model and Notation (BPMN). Unidad IV: AUTOMATIZACIÓN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN), presenta herramientas de simulación y automatización, desarrollados a partir del texto BPM: Business Process Management Fundamentos y Conceptos de Implementación (HITPASS, Bernard, 2014).

Es recomendable que el estudiante desarrolle una permanente lectura de estudio junto a la elaboración de los modelos de procesos, así como la investigación en otros textos y vía internet. El contenido del material se complementará con las lecciones presenciales y a distancia que se desarrollan en la asignatura.

Agradecemos a quienes con sus aportes y sugerencias han contribuido a mejorar la presente edición, que sólo tiene el valor de una introducción al conocimiento de las estructuras de datos para la programación en un computador. Las autoras.

Pág. 3


ÍNDICE Pág. PRESENTACIÓN ÍNDICE UNIDAD I: INTRODUCCION Y DEFINICION DEL BPM Tema Nº 1: Introducción al BPM 1.1 Antecedentes de BPM 1.2 Historia y Evolución Tema Nº 2: Conceptos Básicos de BPM 2.1 Definición de Proceso 2.2 Proceso de Negocio 2.3 ¿Gestión de o por procesos de negocio? 2.4 Gestión tradicional sin BPM 2.5 Bussiness Process Management (BPM) Tema Nº 3: Organización y Estructura del BPM 3.1 Conceptos de Gestión en BPM 3.2 La automatización de procesos (BPA) 3.3 Los participantes en BPM 3.4 Herramientas para BPM 3.5 La arquitectura del BPM y SOA 3.6 Reglas de Negocio 3.7 Gestión de Reglas de Negocio 3.8 Reglas de negocio y Reglas de ruteo 3.9 Técnicas de Mejora Continua UNIDAD II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO BUSINESS PROCESS MANAGEMENT Tema Nº 4: Arquitectura Empresarial 4.1 Definición de Arquitectura 4.2 Definición de Arquitectura Empresarial AE 4.3 Drivers y Objetivos de una AE Tema Nº 5: Áreas de una Arquitectura Empresarial 5.1 Business Process Outsourcing (BPO) 5.2 Gestión de calidad - riesgo - conocimiento - regulaciones - otras 5.3 Auditoria 5.4 Portafolio de proyectos 5.5 ITIL (Information Technology Infrastructure Library) Tema Nº 6: Modularización de Programas 6.1 Relación Arquitectura Empresarial – Business process Management - Service Oriented Architecture (AE & BPM & SOA) Tema Nº 7: Frameworks de Arquitectura Empresarial 7.1 Framework de AE 7.2 Framework de Zachman 7.3 TOGAF (The Open Group Architecture Framework) 7.4 FEA (Federal Enterprise Architecture) 7.5 ARIS (Architecture of Integrated Information Systems) 7.6 Enterprise Architecture as Strategy (Ross et al) Tema Nº 8: Modelos de Madurez de BPM 8.1 ¿Qué es un modelo de madurez? 8.2 Modelo de Madurez BPM de la OMG (BPMM: Business Process Maturity Model) 8.3 Modelo de madurez BPM de Schmelzer UNIDAD III: BUSINESS PROCESS MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN) Tema Nº 8: Evolución de Business Process Model and Notation (BPMN) 8.1 Historia de técnicas para modelado de sistemas y procesos 8.2 Clasificación de las técnicas de modelamiento 8.3 Otras Técnicas de Modelado 8.4 Business Process Model and Notation (BPMN) Tema Nº 9: Los elementos básicos de BPMN 9.1 Modelos, instancias, token y correlaciones 9.2 Categorías de los elementos de BPMN 9.3 Actividades 9.4 Flujos de Secuencia 9.5 Actividades globales 9.6 Un proceso simple en BPMN 9.7 Flujo de Procesos con Gatewatay 9.8 Eventos 9.9 Lane 9.10 Artefactos 9.11 Participantes y flujos de mensajes 9.12 Subprocesos Tema Nº 10: Diferentes vistas de un proceso Tema Nº 11: Categoría de Procesos 11.1 Orquestación 11.2 Coreografía 11.3 Colaboración. UNIDAD IV: AUTOMATIZACIÓN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN) Tema Nº 12: Automatización de Procesos 12.1 Niveles de Procesos 12.2 BPMN comparado con otras notaciones BIBLIOGRAFÍA

Pág. 4

3 4 5 5 5 5 9 9 10 13 15 16 18 18 25 26 29 31 34 35 36 38 46 46 46 46 48 52 52 53 53 54 54 55 55 58 58 58 59 60 61 62 63 63 63 64 65 65 65 67 67 68 70 70 70 71 74 75 75 75 80 87 88 88 89 90 91 91 91 92 93 93 94 99 100


UNIDAD I INTRODUCCION Y DEFINICION DEL BPM

Tema Nº 1: Introducción al BPM

1.1 Antecedentes de BPM (HITPASS, 2013) La globalización está demandando mayores exigencias, tanto a las empresas privadas como a las organizaciones públicas, en su capacidad de reacción frente a los cambios exigidos por el mercado. Éstos pueden ser cambios en el tipo de demanda o cambios de regulaciones. Existen muchas definiciones de BPM. Aunque todas ellas tienen algo en común también existen diferencias, sobre todo en el alcance. Algunos autores y expertos, en especial en Europa, restringen el BPM a una disciplina de gestión sin incluir explícitamente el apoyo de TI. Otros autores, definen BPM como el proceso hacia la automatización y operación de los procesos implícitamente con TI. El concepto de BPM es incluso más amplio, pero va a depender cuelas son los objetivos que perseguimos con BPM, que por lo general todas las escuelas los comparten. Por lo general las diferencias de las escuelas se encuentran en el concepto de cómo enfrentar el proceso hacia el logro de los objetivos y cada concepto parte por una definición, razón por la cual algunas definiciones se diferencian de otras. La descripción de los objetivos es clara y bien definida.

1.2 Historia y Evolución

Evolución de la Ingeniería de Procesos hacia el BPM Fuente: (HITPASS, 2013)

Pág. 5


1.2.1 La ingeniería de procesos nace con Frederick Taylor (HITPASS, 2013) La idea que las actividades (el trabajo) se pueden describir como un proceso no es nueva. A principios del siglo pasado Frederick Winslow Taylor (1911) desarrolló el concepto de la “Administración Científica” (Taylor publicó poco antes de morir (1915) en 1911 su obra que lo hizo tan famoso «The Principles of Scientific Management ».) [TaylorFre08]. A Taylor se le atribuye haber desarrollado los principios de la especialización y estandarización de los procesos en la producción industrial elevándolos a una ciencia que podríamos llamar «ingeniería industrial y mejora de procesos», razón por la cual muchos autores lo denominan como el padre de la ingeniería industrial. Taylor aporta en métodos de observación de buenas prácticas, de medición del trabajo y a partir de estos conocimientos de diseñar procesos industriales desagregados hasta el nivel de actividad manual (Taylor hablaba de «administración de tareas») altamente especializados para lograr mejoras sustanciales en la productividad. Los principios de la administración científica que describe Taylor en su obra pueden resumirse según (Bravo, 2011) en los siguientes cuatro pasos: 1. Desarrollar el estudio científico del trabajo, una “ciencia” según Taylor 2. Seleccionar científicamente al obrero más adecuado a la tarea, según sus capacidades, y luego instruirlo en cómo hacer correctamente la tarea, según el punto anterior. 3. Cooperar con los obreros para que todo el trabajo sea hecho de acuerdo con los principios científicos que se aplican. Se refiere a una cooperación de los investigadores y de los administradores. Armonía es la palabra principal que emplea Taylor. 4. Distribuir equitativamente el trabajo y la responsabilidad entre la administración y los obreros. Juan Bravo (Bravo, 2011) en su libro indica lo siguiente sobre Taylor: Podemos resumir que el objetivo que perseguía Taylor al reunir hechos y mediciones era proporcionar un fundamento científico para diseñar y mejorar los procesos. Con estos fundamentos pretendía terminar con la improvisación que predominaban en aquella época. En vez de hacer que cada trabajador hiciera la tarea a su manera, Taylor quería encontrar la forma óptima de hacerla y estandarizar las buenas prácticas haciéndolas más eficientes y lograr economías de escala. Este enfoque fue empleado con éxito durante toda la época de la industrialización (mercado de la oferta) durante el siglo XIX y principios del siglo XX, pero esta técnica estaba restringida a los procesos manuales y a la producción industrial y no incluía el seguimiento de los procesos de gestión.

Pág. 6


1.2.2

El cambio del mercado de la oferta al mercado de la demanda

(HITPASS, 2013) Más adelante, a principios de los 80, aparecieron enfoques estadísticos con el objetivo de mejorar los procesos de control. Así nació el enfoque TQM (Total Quality Management) basado en una gestión de control estadístico, pero aplicarlo requiere de una rigurosa disciplina en la organización que es Management) basado en una gestión de control estadístico, pero aplicarlo requiere de una rigurosa disciplina en la organización que es difícil de alcanzar. Empresas japonesas, en particular Toyota, reconocieron a principios de los 90 el cambio hacia el mercado de la demanda y enfocaron la gestión orientada hacia las necesidades del negocio (clientes). Nota: En el «mercado de la demanda», la oferta es mayor que la demanda por lo que en economía se deduce que la fuerza compradora es más influyente que el poder que pueden ejercer los proveedores en los mercados en que operan. Toyota desarrolló el concepto Toyota Production System (TPS)[ Liker06]. Este se caracterizaba por contar con una estructura organizacional muy plana, instalando equipos multidisciplinarios en centros de producción y con el encargo de resolver en forma autónoma propuestas de mejora continua en los procesos de producción. A este sistema de trabajo se le llamó también Lean Production, indicando en quitarle grasa a las estructuras organizacionales burocráticas y lentas en sus procesos de decisiones. Cuando en los años 90 muchas empresas occidentales fueron azotadas por la recesión, debido a que los mercados habían llegado a una situación de la sobre oferta (saturación, cambio hacia el mercado de la demanda) y el comienzo de la globalización, aparece el Business Process Reengineering (BPR, Hammer and Champy, 1993) (Hammer, M. y Champy, J., 1993) como medida de salvación para deburocratizar las empresas y ser más eficientes en sus procesos de negocios.

Pág. 7

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 1.2.3 La reingeniería de procesos como precursor de BPM

(HITPASS, 2013) El Business Process Reengineering BPR tiene como finalidad rediseñar y hacer más eficientes los procesos, atacando las estructuras jerárquicas funcionales y alineándolos con los objetivos del negocio, buscando alcanzar resultados de desempeño espectaculares a corto plazo. La reingeniería de procesos se basa y apoya fuertemente en la incorporación de tecnologías de la información, como elemento clave para la transformación esperada. El BPR es el primer enfoque end to end en introducir como gestión los procesos de negocios transversales a las organizaciones funcionales, centrados en las necesidades del cliente y no en los procesos de producción, pero esto no fue fácil, muchos proyectos de BPR terminaron siendo proyectos de racionalización de recursos con una fuerte reducción de personal. Perdiendo, muchas veces, la perspectiva de agregación de valor para el cliente. BPR no fue el único enfoque en aparecer en dichas décadas, a principio de los años 80 apareció Six Sigma como una opción para mejorar la eficacia y eficiencia de los procesos de negocio. Este enfoque surgió en Motorola Inc. y el caso práctico de aplicación más conocido fue General Electric en los ’90. Como TQM, Six Sigma se basa en principios estadísticos para mejorar los procesos de control y mejora. La sigla Six Sigma significa “one output defect in six Standard deviations of a probability distribution for a particular process output”. Las técnicas de Six Sigma se emplean sobre la base de episodios o eventos, los cuales debiesen estar dentro del nivel de exigencia definida para el proceso (cantidad de Sigmas), pero no incorporan un pensamiento de mejora continua. Muchas empresas combinan el enfoque de Six Sigma con TPS o Lean Production. Aún no se puede predecir cómo va a seguir evolucionando Six Sigma, pero a pesar que se detectan signos de cansancio aún está muy difundido en empresas norteamericanas (Davenport, forward BPM Jeston and Nelis, 2008) (John Jeston & Johan Nelis, 2008). A mediados de los 90 aparece la ola de los ERP’s (Enterprise Resource Planning). Los ERP’s se vendieron como la solución para todos los problemas en la organización, pero los ERP’s no generaron la eficiencia y eficacia esperada en los procesos de negocios, estaban diseñados para mejorar la eficiencia administrativa. A fines de los años 90 y a principios del 2000 aparecieron los sistemas Customer Relation Management (CRM) como medida para mejorar los servicios a los clientes, pero aún no contábamos con una integración entre los procesos del front office (CRM) con los del back office (ERP).

Pág. 8


Tema Nº 2: Conceptos Básicos de BPM 2.1 Definición de Proceso (HITPASS, 2013) En principio, un proceso corresponde a la representación de un conjunto de acciones (actividades) que se hacen, bajo ciertas condiciones (reglas) y que puede gatillar o ejecutar cosas (eventos). En forma genérica se puede definir un proceso como: «Una concatenación lógica de actividades que cumplen un determinado fin, a través del tiempo y lugar, impulsadas por eventos.» Esta definición contiene los principales elementos que describen un proceso: Los eventos son ocurrencias externas que inician un proceso, es decir un proceso no se inicia por sí sólo, algo tiene que ocurrir y el proceso reacciona ante el suceso. El proceso debe cumplir un determinado fin, en las ciencias económicas destinadas a producir bienes y servicios. A diferencia de los eventos, las actividades en un proceso consumen tiempo y recursos. Una actividad se puede definir como una «acción sobre un objeto», es decir el proceso de transformación ocurre a través de las actividades en un proceso. Las actividades en un proceso están encadenadas a través de una secuencia lógica que determinan en su conjunto las condiciones del negocio. Estos elementos básicos describen en su conjunto los procesos y están contenidos en la mayoría de las notaciones para modelarlos, así también en el estándar BPMN. La definición es pura, no dice nada respecto para qué objetivos se levantan y modelan procesos en una organización. Ejemplo de proceso: Proceso de Matrícula Universidad (Fuente: http://www.universidad.continental.edu.pe/sobre-matriculas/)

Pág. 9


Ejemplo de proceso: Proceso de Elaboración de calzado artesanal (Fuente: http://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.html) Paso 1: Selección y adquisición del material. Paso 2: Selección del modelo y corte a realizar. Paso 3: Armado de la Pala. Paso 4: Montado. Paso 5: Desmontado. Paso 6: Terminado. Paso 7: Empaquetado y distribución.

2.2 Proceso de Negocio (Hammer, M. y Champy, J., 1993) Introducen en su obra de Reingeniería de Procesos en el año 93, el concepto de proceso de negocio: «Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de inputs y crean un output que es de valor para un cliente.» Los procesos de negocio son los que crean valor para un cliente, es decir la definición está ligada al concepto de creación de valor para el cliente. Siguiendo la definición propuesta en este trabajo de un proceso en forma general, se definirá un proceso de negocio como: «Un proceso de negocio es un conjunto de actividades que impulsadas por eventos y ejecutándolas en una cierta secuencia crean valor para un cliente (interno o externo).» Un proceso de negocio se reconoce por el tipo de evento que lo gatilla. Una de las principales características de un proceso de negocio es que es gatillado por el cliente y los resultados de la ejecución del proceso tienen que volver al cliente, entendiéndose en el sentido más amplio que el cliente también puede ser interno, por ejemplo un área de negocio o externo un proveedor. En Ingeniería Industrial se le conoce como Pull Process, el cliente tira el proceso de negocio. A diferencia de Push Process, donde se “empuja” los objetos a través del proceso para llegar al cliente. El concepto de Pull y Push Process está relacionado con la forma en que se planifican, distribuyen y reponen los productos en bodega (logística). Existen dos formas que cubren este ciclo: 1. En el concepto push, se calcula la demanda sin conocer los pedidos de los clientes (por ejemplo las representaciones de autos en Chile funcionan así). Importan autos y luego los venden. 2. En el concepto de pull, solo se planifica y produce bienes bajo demanda real y está muy relacionado con el concepto de just in time, es tratar de bajar al mínimo los procesos de bodegaje intermedio. Dell por ejemplo se hizo famoso en los años 90 aplicando este concepto al extremo. Sólo se produce a pedido real (orden de compra) del cliente. Es normal encontrar en muchas compañías combinaciones de ambos tipos de flujos, en particular para responder con mayor oportunidad a los requerimientos de los clientes. El proceso de negocio es transversal a las áreas y atraviesa la cadena de valor de principio a fin (también se usa mucho el término anglosajón «end Pág. 10

Asignatura: NOTACION DE PROCESOS DE NEGOCIO to end»). Este principio es indistinto si se trata de un cliente externo (cliente final) de la empresa o cliente interno. Muchas veces se confunden los macroprocesos con los procesos de negocio. Por lo general corresponden los macroprocesos con las grandes áreas de negocio de una empresa como por ejemplo abastecimiento, producción, bodega, venta, etc. Ningún cliente externo va a gatillar un proceso en el área de abastecimiento y los procesos en esta área tampoco atraviesan la cadena de valor de la empresa.

A pesar que estas áreas pueden ser muy grandes y muy complejas no tienen relación directa con el concepto de proceso de negocio: gatillado por el cliente, de principio a fin y el resultado tiene que ser de valor para el cliente.

Los procesos de negocio se encuentran debajo de los macroprocesos y los atraviesan. Al mapear los procesos de una organización en muchas ocasiones se cometen grandes errores al respecto. Si se descomponen «top down» los macroprocesos se van a mapear los procesos internos de las áreas en diferentes grados de abstracción, y justamente éstos no son los procesos de negocio.

¿Cómo se pueden identificar entonces los procesos de negocio? Para estos efectos se recomienda realizar un análisis del contexto y hacer un listado de todos los eventos iniciados por el cliente. A continuación se nombran ejemplos de procesos de negocio: Solicitudes de créditos, préstamos, devoluciones Solicitud de apertura de cuenta bancaria Compra de pasajes Procesos de reclamaciones Seguimiento de resolución de problemas en Servicio a Clientes Gestión de Hipotecas, Multas,... Recepción y pago de factura Recepción y confirmación de orden de compra Elaboración de ofertas

Los siguientes ejemplos no se pueden clasificar como procesos de negocio. Partida doble en contabilidad: • Se trata de una función contable, que le sigue a un movimiento contable. Reserva de pasajes: • Se trata de un subproceso del proceso de negocio «compra de pasajes». En este caso no se cumple el principio de finalidad, que sería la compra del pasaje. Ingreso de un nuevo empleado al sistema de RRHH: • Actividad manual del proceso de negocio «contratación de personal». El cliente interno es el área de negocio, quién gatilla la solicitud de contratación. Ingreso de una orden de compra: • Actividad manual del proceso de negocio «compra de un producto o servicio». Envío de email: • Actividad técnica sin significado de negocio Emitir una póliza: • Emitir puede significar imprimir, generar o extender una póliza de seguros, pero de todas formas el proceso de negocio sería la «solicitud de un contrato de seguros»

Pág. 11

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Debe tener cuidado en no confundir el concepto de «cadena de valor» propuesto por Porter con el concepto de «proceso de negocio» que está ligado al concepto de valor para el cliente. La figura muestra la típica estructuración de una cadena de valor descompuesta en procesos de dirección, procesos primarios y procesos de soporte, siendo los procesos primarios los procesos de la «cadena de valor» porque están directamente relacionados con la creación de bienes y servicios para el cliente externo, pero la cadena de valor no es lo mismo que los servicios que solicitan los clientes.

Figura Estructura de Cadena de Valor según Porter FUENTE: (HITPASS, 2013)

La siguiente figura muestra la transversalidad de los procesos de negocio que son impulsados por clientes y cuyos resultados tienen que volver a ellos.

Figura Estructura de procesos de negocio FUENTE: (HITPASS, 2013)

La cadena de valor muestra las dependencias en los pasos de producción, mientras que los procesos de negocio muestran las dependencias de las políticas de negocio para atender las peticiones de los clientes y llevarlos a un resultado satisfactorio que tiene una expresión de mercado, es decir el cliente está dispuesto a pagar (creación de valor). Pág. 12

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 2.3 ¿Gestión de o por procesos de negocio? Actualmente es muy utilizado ambos términos tanto Gestión por procesos como Gestión de procesos, y es importante saber si existe diferencia entre ambos términos:

(HITPASS, 2013) En una organización existen muchos procesos de negocio. Si nos referimos a gestionar un proceso en particular hablamos de «gestión de proceso». Generalmente el primer objetivo en las organizaciones es lograr un mayor control y desempeño sobre los procesos. Mayor control significa tener conocimiento en tiempo real en qué estado se encuentra cada uno de los procesos instanciados. Por ejemplo saber sobre la carga de trabajo de cada uno de los usuarios y saber cuáles procesos se encuentran estancados por alguna razón. Esta información le permite al supervisor (gestor del proceso) detectar problemas antes que impacten sobre los resultados. Al tener mayor control sobre lo que está sucediendo podemos mejorar el desempeño de los procesos, por ejemplo acortar los tiempos de ciclo y en general mejorar el grado de satisfacción de cliente. Al introducir «gestión de procesos» en una organización tenemos la posibilidad de mejorar el grado de cumplimiento de objetivos funcionales, pero no es un instrumento suficiente para alinear la gestión de procesos con la estrategia de la organización y sus debidos objetivos de negocio. La gestión de procesos se focaliza en medir y analizar el desempeño de los procesos en operaciones, pero no incluye los conceptos de alineamiento con otras capas de la organización, por ejemplo la integración a los procesos de alineamiento con la estrategia y la capa de tecnología. Gestión por procesos significa incluir los procesos de planificación y alineamiento a la gestión de procesos.

Pág. 13

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Entre académicos y profesionales de BPM es ampliamente conocido el principio que «los procesos deben seguir la estrategia» y que «la tecnología debe seguir a los procesos ». Gestión de procesos no incluye estos ciclos de planificación y de alineamiento a los procesos como lo pide la disciplina de gestión BPM, pero si ampliamos el concepto de gestión e integramos las otras disciplinas empresariales a la gestión de procesos, entonces hablamos de «gestión por procesos» y en su definición más amplia en inglés de Business Process Management (BPM).

En la gestión de procesos nos centramos en el resultado de cada proceso y las acciones a realizar (mejora continua, reingeniería o innovación). 1. Identificación de los procesos y planificación de los Objetivos a conseguir con cada proceso. (Fase de Modelización y Planificación de Procesos) 2. Medición de los resultados de los indicadores en la ejecución o funcionamiento de los procesos (Fases de Automatización y Ejecución de Procesos) 3. Control de la consecución de los indicadores al compararlos con los objetivos y definición de acciones correctoras (Fase de Monitorización) En la Gestión Por Procesos nos centramos en la alineación de la gestión de procesos con la estrategia empresarial y con el resto de gestiones empresariales: 1. La gestión DE procesos para que cada proceso produzca el resultado esperado 2. La alineación de cada proceso con la Estrategia Empresarial, de esta forma sabremos qué aporta cada proceso a cada objetivo estratégico, y definido un objetivo estratégico a qué procesos afecta y si es necesario optimizarlos 3. La cultura de la empresa será coherente con un sistema de gestión de procesos 4. La gestión y dirección del personal se realizará con enfoque a procesos 5. Las diferentes gestiones de la empresa se alinearán con la gestión por procesos

Fuente: http://pedrorobledobpm.blogspot.com/2014/07/gestion-de-procesos-versus-gestion-por.html

Pág. 14


2.4 Gestión tradicional sin BPM

Para conceptualizar y entender la diferencia entre la gestión de y por procesos es importante realizar una retrospectiva, y saber cómo funcionaba una organización sin BPM.

(HITPASS, 2013) Para responder a esta pregunta fundamental vamos a analizar primero cómo funciona la gestión tradicional centrada en consolidar planes de negocio por área y no por procesos de negocio que son transversales a la organización. Por lo general, la formulación de la estrategia de una empresa es amplia y define los grandes hitos que se deben lograr y sobre todo en que hay que centrarse para cumplir con la misión de la empresa y los objetivos de negocio que se formulan a través del ciclo presupuestario en un año comercial, pero la estrategia es transversal a las áreas de negocio, igual que los procesos de negocio. Aquí nos encontramos en la gestión empresarial tradicional con la primera brecha.

De alguna forma se traspasan los objetivos de negocio desde la alta dirección a la capa de operaciones y a su vez operaciones formula, por medio de una especificación, los requerimientos de cambio a la capa de tecnología, pero este proceso no está estandarizado y menos integrado bajo una metodología común. Al no estar estandarizado ni integrado ocurren fricciones y por lo tanto pérdida de valor. Como la estrategia es transversal y no existe un cargo que se responsabilice por el rendimiento del proceso completo, vale decir de principio a fin, los procesos de alineamiento son lentos y de alto costo. Así se produce pérdida de valor en tres grandes ámbitos de la gestión empresarial tradicional, a saber: 1. Cómo plasmar la estrategia en la organización 2. Cómo lograr que los procesos se implementen con tecnología 3. Pérdida de valor en la estructuración misma de los procesos Estas son las tres grandes razones (oportunidades) para implementar gestión por BPM. El aporte del concepto de BPM como disciplina integrada es cerrar estas brechas. Pág. 15


2.5 Bussiness Process Management (BPM)

Es una metodología corporativa y disciplina de gestión, cuyo objetivo es mejorar el desempeño (eficiencia y eficacia) y la optimización de los procesos de negocio de una organización, a través de la gestión de los procesos que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. Por lo tanto, puede ser descrito como un proceso de optimización de procesos. El modelo de administración por procesos, se refiere al cambio operacional de la empresa, al migrar de una operación funcional a una operación administrada por procesos. El BPM es el entendimiento, visibilidad y control de los procesos de negocio de una organización. Un proceso de negocio representa una serie discreta de actividades o pasos de tareas que pueden incluir personas, aplicativos, eventos de negocio y organizaciones. BPM se puede relacionar con otras disciplinas de mejora de procesos como Six Sigma. Los procesos de negocio deberían estar documentados (actualizados), para ayudar a entender a la organización que están haciendo a través de su negocio.

Detallamos otros conceptos de BPM:

(John Jeston & Johan Nelis, 2008): «BPM es el logro de los objetivos empresariales a través de la mejora, la gestión y el control de los procesos de negocio.» En esta definición, se abstrae explícitamente, que la tecnología va a solucionar los problemas a las organizaciones.

Paul Harmon (Harmon, 2007) también define BPM como: «Una disciplina de gestión focalizada en la mejora del rendimiento corporativo por medio de la gestión por procesos de negocio.»

Finalmente Jeston y Nelis (John Jeston & Johan Nelis, 2008) concluyen, BPM es: Más que sólo software, más que solo la mejora o la reingeniería de los procesos, no es solamente una moda, es parte integral del management, más que sólo levantamiento y modelado de procesos, también es la implementación y ejecución de los procesos, los cuales requieren ser analizados y mejorados.

Pág. 16

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Factores críticos del BPM según Jeston y Nelis:  El logro de la estrategia organizacional  La organización está alineada con los procesos end to end  Los objetivos están alineados con la estrategia organizacional  Los procesos deben mejorar en su eficiencia y ser eficaces Gestión orientada a procesos (Management)  Controlar el ciclo completo de BPM  Seleccionar los procesos críticos, no todos los procesos contribuyen al logro de los objetivos estratégicos

Implementar BPM tiene que tener impacto en los beneficios del negocio Nuestra definición tiene un alcance amplio y abarca tanto la disciplina de gestión como la incorporación de TI para la automatización de los procesos. Definimos en forma abreviada BPM como: «Disciplina de Gestión por Procesos de Negocio y de Mejora Continua apoyada fuertemente por las Tecnologías de la Información»

Una definición más amplia la encontramos en la guía de referencia de la Asociación Internacional de Profesionales de BPM (BPM Common Body of Knowledge, ABPMP (Association of BPM Professionals) (Tony Benedict, Nancy Bilodeau, Phil Vitkus, Emmett Powell, Dan Morris, Marc Scarsig, Denis Lee, Gabrielle Field, Todd Lohr, Raju Saxena, Michael Fuller, Jose Furlan, 2013):

«Business Process Management (BPM) es un enfoque sistemático para identificar, levantar, documentar, diseñar, ejecutar, medir y controlar tanto los procesos manuales como automatizados, con la finalidad de lograr a través de sus resultados en forma consistente los objetivos de negocio que se encuentran alineados con la estrategia de la organización. BPM abarca el apoyo creciente de TI con el objetivo de mejorar, innovar y gestionar los procesos de principio a fin, que determinan los resultados de negocio, crean valor para el cliente y posibilitan el logro de los objetivos de negocio con mayor agilidad.» Como lo indica (HITPASS, 2013) la definición de la ABPMP, BPM es una disciplina integradora que engloba técnicas y otras disciplinas organizacionales, que abarca las capas de negocio y tecnología, que se comprende como un todo integrado en gestión a través de los procesos. Nos inclinamos por esta definición porque diferencia entre procesos manuales y automatizados, pero integra ambos casos a la disciplina de BPM. Con esta definición pretendemos lograr un entendimiento común que es necesario para tener éxito en introducir BPM en una organización. Para lograr los objetivos que se persiguen en BPM es necesario sincronizar e integrar los procesos manuales con los implementados con apoyo de TI o los que se van a automatizar.

Pág. 17


Tema Nº 3: Organización y Estructura del BPM 3.1 Conceptos de Gestión en BPM BPM ataca la automatización de procesos por toda la empresa, pero con total adherencia a las modificaciones de negocios que un mercado de fuerte competición exige. No existe una combinación única y exacta de los procesos, metodologías e indicadores, y en muchos casos estos existen aisladamente. Una herramienta de BPM debe soportar las actividades básicas de la gestión, que pueden ser resumidas en: •Definir una estrategia para conducir el performance; •Traducir la estrategia en objetivos, indicadores y metas; •Acompañar el progreso en relación a las metas; •Analizar los motivos en caso de metas no alcanzada y •Seleccionar e implementar acciones correctivas. Sistemas de BPM sirven para ayudar la empresa a controlar mejor sus propios procesos, a reformarlos cuando es necesario y a realizar tareas importantes con más eficiencia. Estos sistemas dan al usuario más control sobre la automatización de procesos, lo que alivia el trabajo de la informática. El BPM impone a la empresa un desafío muy grande, pues obliga el usuario a dos acciones que, casi siempre, a él no le gusta hacer: repensar en las tareas del día-a-día y, al menos en la fase de implementación, trabajar lado a lado con el personal de informática.

(HITPASS, 2013) BPM como disciplina de gestión orientada a procesos abarca dos grandes áreas de la gestión empresarial: BPM Governance y BPM Operacional.

3.1.1 BPM Governance (HITPASS, 2013) BPM Governance, también llamado gobierno corporativo, como un modelo de gestión corporativo orientado a procesos, pero integrado con todas las capas de una organización (capa de dirección, operacional y de tecnología), las fases del ciclo de gestión, la gestión del cambio de nuevos requerimientos (en inglés: Change Management), la estructura organizacional y todos los instrumentos de alineamiento de y entre las estructuras corporativas. BPM Governance abarca el alineamiento con todo el ciclo de gestión organizacional desde la planificación y gestión estratégica, la definición de planes de negocio, el ciclo presupuestario, la definición de perfiles y cargos, la gestión en operaciones, apoyo tecnológico hasta el alineamiento con el portafolio de proyectos corporativo.

Pág. 18

Asignatura: NOTACION DE PROCESOS DE NEGOCIO (Harmon, 2007) En la literatura se encuentran varias definiciones de BPM Governance, (John Jeston & Johan Nelis, 2008), la mayoría de ellas muy amplias pero todas coinciden que se trata de un concepto definido para una organización de cómo debe aplicarse «Gestión por Procesos» y que integra instrumentos y disciplinas existentes en torno a los procesos de negocio.

Harmon (Harmon, 2007)] discrimina primero entre «governance» y «management», explicando que «governance» es la organización del «management». Resumiendo a su entender cuando hablamos de governance nos referimos a un modelo específico de gestión, mientras que «gestión» es una actividad humana.

Para Jeston y (John Jeston & Johan Nelis, 2008)(pags. 323-324) en un modelo de BPM Governance son clave la definición de roles y responsabilidades, los procesos de alineamiento con la estrategia de la empresa, el control de gestión orientado a procesos y finalmente la estandarización de los procesos de gestión.

Fuente: https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Go bierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650

Pág. 19


3.1.2 BPM Operacional (HITPASS, 2013)El BPM Operacional abarca la gestión del ciclo BPM por proceso y no los mecanismos de alineamiento con las otras capas de la organización que, es dominio de un modelo que incorpora BPM Governance. El ciclo presentado está pensado para ser aplicado para cada proceso por separado o en forma independiente. Cada proceso puede encontrarse en un estado diferente del ciclo. El ciclo comienza a partir de dos posibles constelaciones: Un proceso actual que debe levantarse y documentarse y/ o rediseñarse. Se debe introducir un nuevo proceso, no existente en la organización.

En la fase de «Levantamiento del Proceso » primero se debe recoger la información sobre cómo está organizado el flujo de trabajo. Esto se realiza con la ayuda de técnicas de moderación, talleres, entrevistas, recolección de documentación, etc. Para esto en el proceso a levantar se debe:  Delimitar claramente desde procesos anteriores o posteriores  Describir los servicios que produce para los clientes y qué prioridad tiene desde el punto de vista de los objetivos de negocio  Representar tanto el flujo de trabajo como los roles que intervienen en cada uno de los pasos, los recursos que se utilizan y los sistemas de información que lo apoyan

Pág. 20

Asignatura: NOTACION DE PROCESOS DE NEGOCIO En la etapa de «Documentación del Proceso» el conocimiento adquirido en la etapa de levantamiento se documenta en un modelo de procesos que refleja la situación actual. La documentación resultante comprende los diagramas de los flujos, fichas de descripción, políticas de negocio y procedimientos que se utilizan para ejecutar el trabajo. Las debilidades identificadas en la fase de «Análisis de mejora» o las desviaciones que muestra el «Monitoreo del Proceso» son por lo general el punto de partida para un rediseño de procesos. Eventualmente, se pueden evaluar diferentes variantes o escenarios con ayuda de simuladores. Esto aplica también si se está diseñando un proceso nuevo. En ambos casos el resultado o entregable es un modelo de procesos deseado (To be).

La etapa de «Implementación del Proceso» abarca tanto la implementación técnica como también las adaptaciones organizacionales que se requieren. La gestión del cambio (en inglés: Change Management) y la estrategia de comunicación constituyen elementos fundamentales a considerar para el éxito del proyecto. El modelo técnico puede implementarse por medio de una Suite de BPM (en inglés: Business Process Management Suite, BPMS) o a través de un clásico desarrollo de software. El resultado final de la implementación técnica del proceso es la situación actual (As is) automatizada y documentada, corresponde con el modelo de proceso deseado (To be).

Las fases desde el «Levantamiento del Proceso» hasta la «Implementación del Proceso» se administran por lo general por medio de la organización de un proyecto, mientras que el «Monitoreo del Proceso» (inglés: Process Controlling) se concibe como un proceso continuo y forma parte de todas las operaciones. Las actividades más importantes de «Monitoreo del Proceso» son el control constante de las operaciones (técnicamente hablamos del control de instancias de los procesos reales) y su respectiva evaluación de los indicadores. De acuerdo a la escuela de BPM, si se detectan problemas puntuales debieran corregirse de inmediato o en línea. Si hay recursos disponibles es posible solucionar problemas estructurales sin necesidad de formular un proyecto, pero si sus causas no están claras o son complejas, se hace necesario planificar e implementar un proyecto de mejora y rediseño. La decisión sobre si es necesario formular un proyecto nuevo o instalar un equipo de trabajo en operaciones, debiera tomarla el responsable del proceso de común acuerdo con los participantes.

El ciclo BPM muestra en sus principales fases cómo funciona el círculo virtuoso de mejora continua de los procesos. Para aplicarlo es necesario:

Asignar responsabilidades a los procesos y a cada uno de sus pasos Emplear métodos de análisis y gestión en él Contar con el apoyo de soluciones adecuadas de TI Lograr una coordinación fluida entre estas tres componentes es tarea de gestión por procesos (BPM-Governance). Gestión por procesos se encuentra por sobre cualquier proyecto de modelamiento y tiene por consiguiente la misión de apoyar la «Gestión de Procesos», para el cumplimiento de los objetivos estratégicos.

Pág. 21


3.1.3 Gestión de Casos - Case Management La gestión de casos es una forma de avanzar y mejorar la atención integrada, coordinada y continuada, centrado en la responsabilidad compartida de coordinar los cuidados, recursos, servicios y profesionales. Nos dice:

(HITPASS, 2013) Un caso, como un proceso de negocio, consiste en un conjunto de actividades o tareas. Sin embargo, a diferencia de un flujo predeterminado, el proceso de un caso desde su inicio hasta la finalización no está limitado a una secuencia del proceso como lo entendemos normalmente, de principio a fin, aunque con una lógica compleja de anidación y encadenamiento. ¿Qué actividades se deben realizar para completar el caso? Depende de los detalles de cada caso. Por lo general, el encargado del caso, o tal vez todos los participantes de una tarea, tomarán esta decisión. Las "reglas", por así decirlo, son conocimiento experto de los usuarios. En la literatura también se habla de «adaptive case management (ACM) o dynamic case management», en donde se argumenta que el foco se centra más en el tratamiento del caso que en el proceso mismo [Lamont12]. Por ejemplo en un hospital toda la atención se centra en el paciente y el caso es lo que está sucediendo con él. Los procesos clínicos apoyan la atención del caso, pero el médico o el equipo médico decide qué procesos de diagnóstico o de apoyo terapéutico se van a emplear y cuándo recurrir a ellos. El caso específico determina la secuencia. Sin embargo, en la industria de la salud a medida que ha aumentado el conocimiento se han desarrollado guías de práctica clínica que orientan la toma de decisiones por parte del equipo de salud, facilitando la estandarización de los procesos clínicos. En algunos tratamientos, hoy en día lo normal es encontrarse con un proceso conocido de principio a fin. En todo caso, el mismo proceso debe considerar en sus reglas la opción de no continuar con el flujo estandarizado.

La gestión de casos no suele trabajar por la carpeta de enrutamiento del caso a la siguiente tarea de forma secuencial en la línea. En su lugar, los avances son a través de eventos, tanto externos como internos:

Los eventos externos afectan el caso. El contenido de ese mensaje se agrega a la carpeta del caso y nuevas tareas o procesos pueden ser creados. Los eventos internos incluyen las asignaciones y reglas del negocio. Los trabajadores de casos asignan tareas e inician los procesos que consideren necesarios en su trabajo sobre el caso. Las reglas del negocio pueden crear y asignar tareas o llevar a cabo plenamente las acciones automatizadas sobre la base de cualquiera de los eventos externos, la realización de las tareas de los demás casos, o el vencimiento de los plazos de trabajo.

Pág. 22

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Así, de un flujo determinado, el modelo conceptual de un caso es una colección visible de tareas en conjunto con los documentos y carpetas de cada caso. El estado del caso en su conjunto está determinado por el estado combinado de todas sus tareas y documentos.  Las típicas áreas en donde nos encontramos procesos del tipo de «gestión de casos» son: Área salud  Trabajo social  Soporte  Educación  Proyectos que inducen al cambio  Exploraciones mineras

En general todos los negocios que requieren de conocimiento experto que aún no han alcanzo un nivel de estandarización ¿Cuáles son las funcionalidades específicas que se requieren para apoyar tecnológicamente la gestión de casos en el contexto de BPM? Tomando en consideración las principales características que tiene la gestión de casos se requiere:  Derivación del caso a otros especialistas  Decisiones grupales Gestión de contenidos  Administración de documentos  Funcionalidades de búsqueda y filtros  Configuración de atributos  Adjudicación de recursos

Ejemplo Gestion de caso – Clinica FUENTE:http://www.elsevier.es/es-revista-enfermeria-clinica-35-articulo-gestion-casos

Pág. 23


3.1.4 ¿Case Management versus BPM? (HITPASS, 2013) Luego de revisar las características distintivas de ambos enfoques, podemos indicar que, BPM normalmente se focaliza en procesos repetitivos con flujos muy estrictos. La abstracción necesaria debe gestionar tareas más complejas. Por su parte, la gestión de casos ofrece una flexibilidad mucho mayor, pero falla cuando se dirige al usuario de negocio y dificulta el cumplimiento de las normas reguladoras. Se pueden complementar y puede ser útil su trabajo en conjunto. Sin embargo, las decisiones recurrentes en la gestión de casos, permiten ir identificando patrones respecto a las acciones, pero dada la naturaleza de la gestión de casos, no debiese estructurarse, pero es posible generar manuales o guías de ejecución.

La gestión de casos aporta flexibilidad y directrices. Se centra en información de casos, no en los procesos determinados. Un caso recoge toda la información necesaria para gestionarlo: los actores (usuarios/ roles que participan en el caso), datos/ contenido, reglas y, por supuesto, procesos y tareas. La gestión de casos habilita a los trabajadores calificados dándoles la posibilidad de tomar decisiones dentro de las restricciones de las estrategias de negocio. La gestión de casos define negocios y objetivos realizables, y los comunica de forma transparente mientras que los propios usuarios añaden tareas para lograr esos objetivos. Esto lleva a un modo “design-by-doing” que permite a los usuarios crear, modificar y analizar los procesos sobre la marcha. Los procesos adaptables, a pesar de no tener una progresión predecible y repetitiva, se mueven de un estado menos ordenado a otro más ordenado por medio de la acción del usuario. Las decisiones tomadas por los usuarios son compartidas al ser almacenadas en plantillas y están disponibles para otros actores de la compañía como acciones propuestas. Este es el caso de lo que se llama ficha clínica única en la historia de un paciente en un hospital que siempre se puede volver a retomar y crear una nueva instancia de proceso. Finalmente podemos resumir que Case Management es un caso especial en la disciplina de BPM, pero igualmente se trata de gestionar un proceso, en este caso llamado «gestión de un proceso de casos».

Fuente: http://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukasz Pág. 24


3.2 La automatización de procesos (BPA)

Implica la utilización de sistemas tecnológicos para automatizar las actividades y/o servicios de una función o unidad de negocio determinada. De esta manera, procesos de negocio tales como los que desempeñan las áreas de ventas, administración, operaciones, abastecimiento y distribución, cobranzas, recursos humanos o TI pueden ser automatizados mediante la utilización de paquetes informáticos especializados para desarrollar tal función. En consecuencia, el BPA permite liberar al personal de labores rutinarias para que en contraste éstos se concentren en actividades que maximicen el valor agregado de toda la operación.

(HITPASS, 2013) Para entender que puede abarcar la automatización, se va a describir primero un proceso simple de solicitud de crédito organizado en forma manual y luego se va a describir como hoy en día se automatizan (implementan técnicamente) este tipo de procesos. El proceso se inicia cuando se hace ingreso de una solicitud de crédito por correo y es derivada a un ejecutivo de negocio en el banco. El ejecutivo revisa primero la solicitud en forma visual para luego ingresar algunos datos del solicitante en un sistema de análisis de riesgo. Si el índice de riesgo es positivo o aceptable, ingresa los datos de la solicitud en un sistema de crédito financiero y luego envía la solicitud evaluada a su superior para que la apruebe. La automatización de este proceso podría resultar de la siguiente forma: El arribo de la solicitud de crédito por correo, se digitaliza y vía un programa de OCR (Optical Character Recognition ó reconocimiento de texto automático) se extraen ciertas variables del formulario y se ingresan a un sistema de evaluación de crédito. Luego se crea un documento electrónico que gatilla la creación de una orden de trabajo en el Process Engine (motor de procesos) y es depositada en la bandeja de entrada de actividades nuevas del ejecutivo correspondiente. El ejecutivo selecciona de la lista la solicitud correspondiente y visualiza la solicitud de crédito en el Process Engine, la revisa formalmente y luego el Process Engine por medio de un servicio web invoca el sistema de análisis de riesgo enviándole (técnicamente se traspasan las variables) la información correspondiente. Si el resultado del análisis es positivo, el Process Engine deriva automáticamente la solicitud de aprobación a su superior, ingresando los datos en el sistema de crédito financiero por medio de un servicio web y depositándolo en la bandeja de entrada de él para su debida aprobación. Podríamos discutir si este proceso podría ser mejorado, pero este caso describe la diferencia entre un proceso manual y uno automatizado:

El Process Engine controla el proceso, a través del cual dirige a los usuarios que participan en las diferentes actividades y sus respectivos resultados (Human Workflow Management) y controla las interfaces internas y externas con los sistemas que participan en el proceso (Orquestación de servicios).

Pág. 25

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Las decisiones sobre qué tipo de actividades o servicios deben invocarse, las toma el Process Engine a través de la lógica técnica implementada (modelo de procesos técnico) y los puntos de intervención de los usuarios. Dicho de otra forma, no siempre la lógica del proceso implementada es mandatoria, en ciertas circunstancias puede ser influenciada por los participantes del proceso, con la salvedad que debe quedar todo registrado.

Automatización de un proceso con un Proceso Engine FUENTE: (HITPASS, 2013)

3.3 Los participantes en BPM

(HITPASS, 2013) Si admitimos que BPM como disciplina de gestión integrada abarca todas las capas de una organización desde la alta dirección hasta la tecnología que se encarga de implementar y dar soporte a los procesos de negocio, queda claro que tanto para los procesos de BPM Governance como para gestionar los ciclos de BPM deben participar muchos actores en un gobierno corporativo por procesos.

Los roles de participantes que se describen a continuación debieran estar presente de alguna forma en proyectos, gestión u operaciones de BPM. La figura 2.3 muestra los principales roles que asumen los participantes en las capas de negocio y de TI.

Se ha podido constatar que empresas que cuentan con mayores niveles de madurez en BPM también cuentan con roles bien definidos y estructuras orientadas a procesos. En el capítulo 9 se va describir como se insertan estos roles en estructuras organizacionales orientadas a procesos.

Pág. 26


Dueño de Proceso (Process Owner): El dueño de proceso es un miembro de la alta dirección de la empresa y responsable de una línea de negocio. Él es el responsable de plasmar la estrategia en sus procesos de negocio. Él aprueba y disponibiliza parte o gran parte del presupuesto para un proyecto de BPM. Él debiera tener el mayor interés de todos los participantes en promover BPM como un instrumento de gestión.

Gestor de Proceso (Process Manager): El gestor del proceso es el responsable en operaciones, reporta directamente al dueño de proceso y es él quien normalmente impulsa las propuestas de mejora. Él es responsable de mantener la comunicación con los clientes y/ o proveedores. Normalmente al gestor de proceso lo encontramos inserto en un nivel de jerarquía intermedia, como subdirector, subgerente, jefe de sucursal o jefe de grupo.

Usuario de Negocio o Ejecutivo de Negocio (Process Participant): Es el que trabaja en operaciones con el proceso, es decir parte integrante de la cadena que crea valor para los clientes. Se puede relacionar de muy diferentes maneras con el gestor de proceso. En la mayoría de las organizaciones son usuarios de un área funcional, como ventas, finanzas o logística. En estos casos no existe un gestor de proceso o actúa en su parte del proceso como tal y el usuario reporta directamente al encargado del área. Si la empresa está organizada en forma matricial, lo que en empresas globales es bastante común, pueden surgir conflictos entre el gestor de proceso y los responsables de áreas. En estructuras matriciales se requiere de un modelo de decisiones colaborativo para evitar el conflicto de intereses que surge en el punto de intersección.

Analista de Proceso (Process Analyst): Las competencias que se esperan del analista de procesos son conocimientos de BPM en general, conocimientos del negocio y de la técnica de Pág. 27

Asignatura: NOTACION DE PROCESOS DE NEGOCIO modelamiento de procesos que se va a utilizar. El analista de procesos apoya al gestor de proceso como asesor interno o externo en todas las fases del ciclo de BPM. Él puede representar como experto al gestor de proceso ante consultores externos o formar parte del equipo de proyectos de BPM. El analista de procesos puede ser miembro de un área de negocio, de un área de procesos o pertenecer como analista al departamento de informática de la empresa. En muy pocas ocasiones será el responsable de la implementación de los procesos, a pesar que posee buenos conocimientos o una gran afinidad con las tecnologías de la información. El analista de procesos debiera de tener una gran habilidad en materias de desarrollo organizacional y técnicas de comunicación. Pero sobre todo es, como lo indica su rol, un analista. Se espera un gran dominio de la técnica de modelamiento y como coordinador entre personas de negocio y de TI es un rol clave en cualquier proyecto de BPM. De acuerdo a observaciones y experiencias del autor, muchas personas que ocupan este rol no cuentan con las competencias suficientes para cumplir con este objetivo. En la mayoría de los casos porque les faltan las habilidades para este perfil. La calificación más importante de un analista de procesos no es el comunicar sino el captar o escuchar a los participantes. Buenos analistas de negocio sienten la necesidad de querer atender todo en detalle. Al mismo tiempo poseen la empatía, como para poder ponerse en el lugar del cliente y representar sus inquietudes. A ellos no se les escapa ningún detalle, pero al mismo tiempo poseen un buen sentido de abstracción y pueden reducir los modelos a su esencia. El perfil de un jefe de proyecto es diferente, él está centrado en cumplir las metas del proyecto y por lo general prioriza las metas técnicas del proyecto, como fechas de entrega y mantención del presupuesto de costos del proyecto, ante aspectos de calidad y eficiencia. Por esta razón no se aconseja mezclar ambos roles en el sentido que un jefe de proyectos actúe como analista o vice versa.

Ingeniero de Proceso (Process Engineer): El ingeniero de procesos implementa un modelo técnico a partir de la especificación y el diseño operacional validado por él y los analistas de procesos. El diseño técnico debe realizarse en el mismo entorno (process engine o BPMS) en donde se implementarán los procesos. El ingeniero de procesos está bien capacitado en el entorno de implementación, configura y construye la solución de BPM en la suite escogida. El ingeniero de procesos también puede actuar como asesor en la fase de modelamiento de la lógica operacional.

Ingeniero de Desarrollo y Servicios (EAI Developer): Un programador puede asumir el rol de ingeniero de desarrollo, si la solución requiere de ampliaciones o adaptaciones de desarrollo por medio de programación (Servicios web, Java, C# u otros lenguajes).

Arquitecto SOA (SOA Architect): El arquitecto SOA es responsable de diseñar una arquitectura de software que cumpla con los requerimientos técnicofuncionales de los procesos y servicios que se van a automatizar y orquestar con los sistemas de información. La mayoría de los procesos de negocio deben integrarse con los sistemas de información del back-office, desarrollar interfaces B2B e integrar el BPMS a un portal corporativo.

Pág. 28


En empresas y organizaciones de menor tamaño, muchos de estos participantes tendrán que asumir varios roles a la vez. Los siguientes roles en conjunto podrían por ejemplo asumir los participantes en empresas Pyme: Dueño de Proceso y Gestor de Proceso Analista de Negocio y Ejecutivo de Negocio Analista de Negocio e Ingeniero de Procesos Arquitecto SOA e Ingeniero de Desarrollo

3.4 Herramientas para BPM Si se está pensando en diseñar o modelar procesos, se trata de un proceso de análisis. Si se está pensando en BPM Governance, se trata de una metodología de gestión. Si se está pensando realizar un prototipo, se trata de probar un entorno de implementación o de automatización de procesos. Y si se está pensando en acortar el ciclo de duración de un proceso, se trata de técnicas de optimización y control a través de indicadores.

Todos estos objetivos se refieren a diferentes áreas de aplicación en BPM. Cada área de aplicación es una especialidad en BPM y se apoyan en diferentes conceptos. Entonces difícilmente se va a encontrar una herramienta universal que cubra todos estos ámbitos; por el contrario sería una aberración intentar de construir una suite universal para BPM.

(HITPASS, 2013) Como comparación analicemos un ejemplo práctico: Un Ferrari o un Porsche no nos va a servir para jeepear y es impensable que un Jeep o un Land Roover gane una carrera de Fórmula 1.

Así es también en BPM, una suite de BPMS no nos va a servir para representar un mapa estratégico y alinearlos con los procesos de una empresa. Tampoco nos va a servir para describir las políticas y reglas de negocio en forma independiente de los procesos que las utilizan.

En el primer caso estamos hablando de una suite BPA (Business Process Analysis) y en el segundo caso de Motores de Reglas llamados BRMS (Business Rules Management Systems).

En general se puede segmentar el mercado de herramientas para BPM en:  Herramientas que apoyan los procesos de análisis y Gobierno Corporativo (BPM Governance) llamadas plataformas BPA (Business Process Analysis) o también EA (Enterprise Architecture Tools)  Herramientas que apoyan la implementación técnica o automatización de los procesos llamadas BPMS

Pág. 29

Asignatura: NOTACION DE PROCESOS DE NEGOCIO  Herramientas que apoyan la administración y ejecución de reglas de negocio en forma independiente de los sistemas que las utilizan, llamados Motores de Reglas o BRMS (Business Rules Management Systems)  Herramientas que permiten implementar junto a los procesos los indicadores de control de gestión en tiempo real, llamadas BAM (Business Activity Monitoring)  Herramientas que permiten la orquestación de servicios entre los BPMS con cualquier tipo de sistemas, principalmente los del back office, llamadas SOA Suite Herramientas que permiten analizar los datos históricos de los procesos ejecutados para detectar desviaciones del comportamiento deseado o descubrir nuevos patrones. A estos entornos analíticos se les llaman herramientas de Minería de Procesos o Process Mining Tools en inglés.  Los expertos de BPM saben que dependiendo de la exigencias o la complejidad de una organización puede hacerse necesario una descomposición más fina aun, por ejemplo de separar la capa de presentación de un BPMS o de descomponer una SOA-Suite en varios entornos especializados (ESB, SOA-Repository, etc.).  Todas estas herramientas las podemos posicionar en tres niveles o capas de un marco de Arquitectura Empresarial moderno como lo muestra la figura.

Plataformas y herramientas para BPM FUENTE: (HITPASS, 2013) La capa de negocio abarca todo el ciclo de planificación, análisis, gestión y control de la estrategia y del modelo de negocio. Herramientas que apoyan todas las funcionalidades para planificar, analizar, modelar y llevar el control de cambios de requerimientos bajo modelos integrados en una base de datos común, se les denomina en inglés EA (Enterprise Architecture) o BPA (Business Process Analysis) Tools.

Pág. 30

Asignatura: NOTACION DE PROCESOS DE NEGOCIO (HITPASS, 2013) Nos comenta que: El lector no debe confundir BPA Tools con herramientas que fueron concebidas para modelar e implementar procesos como la tan difundida herramienta libre de licencia Bizagi (es un modelador de procesos BPMN de libre licencia). Tampoco se debe confundir herramientas de diagramación como MS Visio con herramientas BPA. Con MS Visio se puede diagramar lo que se le ocurra al analista y los diagramas tienen una buena calidad de impresión, pero no tiene ninguna otra funcionalidad que se necesitan para BPM Governance como administración de versiones, de atributos, de usuarios, análisis de impacto, animación y simulación, etc.

¿Cuáles herramientas se pueden clasificar como verdaderos BPA Tools? En el mercado podemos encontrar herramientas como: ARIS, Idungu, IBM Coporate Modeler, y Troux entre otras.

La segunda y tercera capa llamada en inglés BPE (Business Process Execution) abarca tanto la ejecución técnica de los procesos como la orquestación e integración de servicios en la capa de SOA (Service Oriented Architecture) con aplicativos del back office. Aquí nos encontramos con los tan conocidos BPMS como la BPM Suite de Oracle, Tibco, AuraPortal, Intalio, Lombardy (IBM) entre muchos otros. Algunas de estas plataformas incluyen una SOA Suite o motores de reglas, pero algunos proveedores sólo ofrecen entornos para «Human Workflow» es decir orquestar procesos con usuarios, pero no orquestar servicios con el back office (SOA). Si bien es cierto la mayoría de los BPMS incluyen modeladores de procesos, pero al lector le tiene que quedar claro que estas componentes no reemplazan un entorno de BPA. Los modeladores de procesos de los BPMS fueron diseñados para la especificación de un proceso que se va a ejecutar técnicamente, razón por la cual son muy técnicos y no sirven como ambientes analíticos o para gente de negocio. Muchos vendedores de BPMS declaran que su oferta tecnológica es universal, que cubre todas las capas y funcionalidades, pero no lo son. Los BPMS son entornos especializados para especialistas de TI, no para usuarios de negocio. En resumen se puede concluir que en BPM existen muchas áreas de aplicación y cada área de aplicación requiere de una herramienta especializada que apoye las funcionalidades requeridas. Herramientas para BPM existen muchas y la pregunta esencial es ¿Con que finalidad fueron diseñadas y que área o especialidad del BPM apoya? 3.5 La arquitectura del BPM y SOA

(HITPASS, 2013) BPM como disciplina de gestión de procesos y como conjunto de herramientas tecnológicas que apoya su análisis y operaciones. SOA como arquitectura tecnológica que puede implementar o automatizar procesos aportando flexibilidad y reutilización de infraestructura de TI existente y en el desarrollo de nuevas componentes.

Pág. 31

Asignatura: NOTACION DE PROCESOS DE NEGOCIO En general la orientación al servicio proporciona la capacidad de interoperar con aplicaciones y con agentes externos (Instituciones, clientes, proveedores, etc...) de forma flexible e invocarlos mediante llamadas de servicios. SOA estandariza las funciones genéricas utilizadas por muchas aplicaciones expresándolas en forma de servicios reutilizables. Uno de los objetivos principales del concepto de SOA es que cualquier futuro cambio se realice de forma transparente, afectando sólo a las funciones y unidades afectadas. Si se logra esta capacidad aumenta la agilidad de negocio de una organización. Por el momento se va a trabajar con esta definición para entender el modelo estructural de BPM y SOA como una arquitectura integrada de la capa de negocio y de TI.

SOA como arquitectura tecnológica que puede implementar o automatizar procesos aportando flexibilidad y reutilización de infraestructura de TI existente y en el desarrollo de nuevas componentes

Arquitectura del BPM y SOA FUENTE: (HITPASS, 2013)

En el contexto de BPM tenemos una capa que la vamos a llamar BPG (Business Process Governance) que define la estrategia, una subcapa de diseño y control y una parte de la capa de implementación, que la vamos a llamar BPE (Business Process Execution). La primera capa define la estrategia y la redefine. Los estrategas están mirando el entorno y van adaptando los productos y servicios de la empresa a la demanda del entorno. Si la adaptación es exitosa hablamos de eficacia. En este sentido la eficacia no es otra cosa que adaptación exitosa al entorno. La segunda capa define cómo lo hago (el qué) que es la etapa de diseño. El diseño tiene como input dos aspectos que considerar, la estrategia y el análisis del comportamiento del negocio. En el diseño, por sí o como parte del comportamiento del negocio se puede considerar la simulación de procesos, es decir, ¿qué pasa si ..? (Ocurren cambios en las variables del entorno, como demanda, competencias, nuevos productos, etc.), de otra forma, simular cómo las variables Pág. 32

Asignatura: NOTACION DE PROCESOS DE NEGOCIO que llevaron a redefinir la estrategia afectan la gestión de los procesos. Puede ocurrir que se requiera de una adaptación de los sistemas reales o que se requiera de una adaptación de la estrategia. La segunda capa BPE abarca la implementación tecnológica de los procesos diseñados de acuerdo a la estrategia. Esta capa tiene una responsabilidad compartida. La capa de negocio tiene la responsabilidad de entregar una especificación (modelo de procesos independiente de la tecnología) automatizable (lógica de negocio) y la capa de tecnología tiene la responsabilidad de llevarlo a un modelo técnicamente ejecutable (BPE). La figura 2.5 muestra la relación entre las componentes de las capas en el marco estructural de la arquitectura descrita.

En la capa BPE nos encontramos con los famosos BPMS (Business Process Management Suite) los cuales según el producto como lo indica la palabra «Suite» contienen varias componentes, el más importante el motor de procesos (inglés: process engine) el cual ejecuta los modelos técnicos de los procesos. Las plataformas o suites más completas e integradas incluyen todas las componentes necesarias para:  modelar el flujo de procesos que se va a ejecutar (Modelador técnico o Process Modeler),  crear formularios dependiente o independiente del modelador técnico (Interfaz de usuario),  ejecutar las instancias del modelo representado con un motor de procesos, configurar el cuadro de mando (BAM: Business Activity Monitoring), editar y ejecutar reglas de negocio (BRMS: Business Rules Management System),  invocar y orquestar servicios con aplicaciones a través de un bus de servicios (ESB: Enterprise Service Bus)

(HITPASS, 2013) Finalmente podemos incorporar a una arquitectura de BPM y SOA un ambiente analítico de minería de procesos que le vamos a llamar «Process Mining and Controlling (PMC)». Process Mining se puede concebir como subárea del Data Mining. El objetivo del Data Mining es extraer de grandes fuentes de datos (data) conocimiento (mining). El objetivo específico del Process Mining es descubrir el comportamiento de los procesos en la realidad y compararlo con los modelos. A partir de este conocimiento se pueden crear nuevos modelos más asertivos y eficientes. Generalmente se descargan los registros (inglés: log files) que dejan los motores de procesos y se cargan en un sistema analítico en donde se aplican diferentes algoritmos de minería de procesos para descubrir el comportamiento real de las instancias que se han procesado. Con el tiempo la base histórica de los registros va creciendo lo que permite analizar tendencias, patrones que se repiten, comparar diferentes prácticas geográficas, sucursales, usuarios y muchos otros factores más. El término «controlling» en este contexto nos indica que los resultados analíticos son un input para el análisis de control de gestión y que junto a los indicadores del BAM (Business Activity Monitoring) sirven para descubrir porqué suceden desviaciones frente al comportamiento deseado y de esta forma obtener información de cadenas de causa y efecto que permiten un nuevo análisis de un rediseño tendiente a mejorar la calidad y el desempeño de los procesos.

Pág. 33


3.6 Reglas de Negocio Las Reglas del Negocio o Conjunto de Reglas de Negocio (Business Rules, por su descripción en inglés) describe las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar los objetivos misionales. Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000".

(HITPASS, 2013) «Una Regla de Negocio es una declaración que define o restringe algún aspecto del negocio; intenta definir, controlar o influenciar el comportamiento y la estructura del negocio.»

Ejemplos de aplicación de reglas de negocio las encontramos en: Reglas para la determinación del precio de un producto o servicio Reglas para la aplicación de descuentos Reglas para acceder a becas, subsidios, etc. Factores de riesgo para la tarificación de planes de seguros

Si una política de negocio se puede expresar formalmente como una acción asociada a un conjunto de condiciones, entonces se puede transformar en una regla de negocio automatizable. En general toda regla de negocio sigue el esquema «condición»,«regla» y «acción». existen principalmente tres técnicas para expresar reglas de negocio de manera formal:

1. Lenguaje estructurado (pseudocódigo parecido a un lenguaje de programación, pero más sencillo y restringido a la aplicación de reglas) Ejemplo: «Si el conductor es > a 40 años y < a 65 años ......... aplica descuento de 15 % sino aplica tarifa BN5» 2. Árboles de decisión (Cada rama del árbol describe condiciones y al final de cada rama se encuentra especificada la acción) Ejemplo:

Pág. 34


3. Tablas de decisión (matrices que combinan condiciones, reglas y acciones, las condiciones de entrada están en las primeras filas. Las columnas expresan las reglas de decisión, es decir las entradas de acciones) Ejemplo:

3.7 Gestión de Reglas de Negocio (HITPASS, 2013) Gestión de Reglas de Negocio (Business Rules Management) es una disciplina independiente y como el nombre lo indica reglamenta las condiciones del negocio. En BPM la administración centralizada e independiente de las reglas de negocio toma la importancia de un factor crítico de éxito para el negocio. Debido a que las reglas son uno de los componentes más versátiles de cualquier organización, es indispensable para los expertos de negocio contar con las herramientas adecuadas para la formulación, verificación, validación y gestión de las reglas. Producto de esto, desde hace varios años se puede observar una fuerte tendencia en la gestión de forma centralizada y sistemática de estas reglas a través de Sistemas de Gestión de Reglas de Negocio (Business Rules Management System o BRMS).

Un BRMS es un sistema que permite a los usuarios determinar y escribir la lógica del negocio mediante la formulación de reglas. En estos entornos los usuarios pueden definir, representar, ejecutar, monitorear y actualizar las reglas de negocio, para que sean utilizadas por las aplicaciones que realizan toma de decisiones automatizadas. De esta manera, se otorga mayor control a los analistas sobre la lógica del negocio y mayor independencia del personal de TI, al externalizar las reglas del código de las aplicaciones.

Algunas Suite de BPM (BPMS) traen motores de reglas incorporados, en otros casos existen BRMS independientes que pueden ser invocados por sistemas de software. Cualesquiera que sean las opciones por las que una organización se decida, lo importante es que no será necesario, o mejor dicho no se recomienda, modelar las reglas en un flujo de proceso, sino sólo identificar donde se utilizan e invocar éstas en las actividades que las requieran.

Pág. 35

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 3.8 Reglas de negocio y Reglas de ruteo Muchos analistas de negocio cometen el error de especificar con ayuda de los elementos de la notación de una técnica de modelamiento las reglas de negocio. La notación no impide hacerlo, pero si las reglas son complejas llenan gran parte del diagrama y los hacen ilegibles. Por otro lado, si las reglas representan el estado actual de ciertas políticas de negocio, queda claro que se espera un cambio frecuente de éstas. Si las reglas están codificadas en el flujo, cada cambio requiere pasar por un proceso de liberación de versiones en operaciones. En cambio si las reglas se administran en un motor de reglas en forma independiente, se pueden efectuar cambios de reglas en tiempo real sin afectar la lógica de control de los procesos implementados. Las reglas de ruteo (en inglés routing: guiar, enrutar) definen como lo indica su nombre la lógica de control de un flujo de procesos.

Para mostrar la diferencia entre reglas de negocio y reglas de ruteo se analizará a continuación un ejemplo simple de un proceso del tipo «Aprobación de Orden de Compra (OC)» aplicando la regla «revisión de credibilidad» en la notación BPMN (este caso fue descrito en [FreRueHit11]). ¿Bajo qué condiciones habrá que revisar la credibilidad del cliente, antes de confirmar la OC? Vamos a suponer que la respuesta a esta pregunta va a depender del tipo de cliente y el volumen del pedido, expresado en dólares. Entonces podemos definir como lo muestra la figura el primer pasó en el proceso como una actividad de «Revisión de datos de la OC» y en esta actividad se va a decidir, si es necesario hacer una evaluación de credibilidad o no.

Proceso orden de compra con revisión de credibilidad FUENTE: (HITPASS, 2013)

En el siguiente paso tenemos que conocer las condiciones concretas para representar las reglas de negocio: Habrá que revisar la credibilidad del cliente, si el valor del pedido es mayor a $ 300.000. Si se trata de un cliente nuevo, habrá que revisar la credibilidad del cliente a partir de los $ 50.000. Si se trata de un cliente VIP, no es necesario revisar la credibilidad del cliente. Con esta información podemos modelar la regla de negocio como lo muestra la figura.

Pág. 36


Proceso de orden de compra con regla de negocio modelada en BPMN FUENTE: (HITPASS, 2013)

Supongamos ahora que cambian las políticas de negocio y habrá que incluir otras condiciones adicionales. Cada nueva condición implica un nuevo Gateway y flujos de secuencia. El problema aumenta, si las condiciones están entrelazadas, como lo es nuestro caso de tipo de cliente y valor del pedido. El diagrama del proceso se vuelve rápidamente ilegible. Si cambian las reglas frecuentemente habrá que estar adaptando el modelo a la nueva situación. Si además tenemos que revisar la credibilidad del cliente en otros procesos, por ejemplo para entregar una cotización, habrá que modelar y administrar estas condiciones en forma redundante.

Se puede concluir entonces, que modelar condiciones que representan «reglas de negocio» no es una «buena práctica» en el modelamiento de procesos. Para evitar que esto suceda, el analista debe aprender a diferenciar entre «reglas de negocio» y «reglas de ruteo». En el modelamiento de procesos tenemos que distinguir claramente entre reglas de negocio y reglas de ruteo, siendo sólo estas últimas las que se deben modelar. Para editar y mostrar reglas de negocio por lo general se usan tablas de decisión. ¿De qué forma se tratan entonces reglas de negocio en un modelo de procesos? Para estos efectos volvemos a nuestro ejemplo de la «Orden de Compra». Traspasamos las condiciones y las reglas de nuestro ejemplo a una actividad del tipo “Regla de Negocio” como el lector puede apreciar en la figura.

Proceso orden de compra con actividad del tipo regla de negocio FUENTE: (HITPASS, 2013) Pág. 37

Asignatura: NOTACION DE PROCESOS DE NEGOCIO A continuación se describen las diferencias de ambos tipos de reglas: Reglas de ruteo son evaluadas por compuertas exclusivas (XOR-Gateways), compuertas condicionales (OR-Gateways) o flujos de secuencia. Las reglas de ruteo son generalmente estables, simples y no entrelazadas.

Reglas de negocio pueden ser muy complejas y se administran en forma independiente del modelo de proceso. La regla de negocio puede entregar la variable que controla el flujo de la regla de ruteo. Con la finalidad de diferenciar estos casos el nuevo estándar BPMN 2.0 ha definido una actividad especializada del tipo «regla de negocio». En nuestro ejemplo sería nuestra actividad «Aplicar regla de negocio» justamente una actividad de este tipo que podríamos asignar a partir de la nueva versión. La OMG (Object Management Group) introdujo justamente este tipo de actividad para promover la separación de «modelos de procesos» y «modelos de reglas». 3.9 Técnicas de Mejora Continua

3.9.1 Six Sigma Es una metodología de mejora continua que fue desarrollada por Motorola en los años 80 con el objetivo de mejorar la calidad de los productos y servicios basado en un concepto estadístico de gestión de calidad tendiente a reducir errores en el proceso de producción de una empresa manufacturera. El objetivo principal de Six Sigma es diseñar y gestionar los procesos de tal forma que los resultados de los procesos tengan una mínima variación y mejore su rendimiento promedio sin errores. El objetivo del método de Six Sigma (6 sigma) es lograr estadísticamente 3,4 errores o defectos por millón de eventos u oportunidades (DPMO).

(HITPASS, 2013)DPMO es el acrónimo de Defectos Por Millón de Oportunidades. Medida de la eficiencia de un proceso cuyo significado literal es Defectos Por Millón de Oportunidades y se calcula con la siguiente formula: DPMO = (1.000.000 x Número de defectos) / (Número de unidades x Número de oportunidades) Donde: Número de defectos, es la cantidad de unidades o no conformidades fuera de especificación encontradas en una cierta cantidad de unidades tomadas como muestra. Número de unidades, es la cantidad de piezas o elementos de muestra producidos. Número de oportunidades, es la cantidad de defectos posible dentro de una misma pieza o unidad. Fuente: Wikipedia

El sistema de medición se basa en la unidad «error por millón de oportunidades» y la variación. Se entiende por error cuando el resultado (medido a través del indicador respectivo) del proceso está fuera del rango de aceptación o desempeño meta. Obtener 3,4 defectos en un millón de

Pág. 38

Asignatura: NOTACION DE PROCESOS DE NEGOCIO oportunidades es un objetivo bastante ambicioso. Se puede clasificar la eficiencia de un proceso en base a su nivel de sigma: (Cuatrecasas, 2010)

1sigma = 690.000 DPMO = 69 % tasa de error (31 % de eficiencia) 2sigma = 308.538 DPMO = 30,8 % tasa de error (69,2 % de eficiencia) 3sigma = 66.807 DPMO = 6,7 % tasa de error (93,3 % de eficiencia) 4sigma = 6.210 DPMO = 0,62 % tasa de error (99,38 % de eficiencia) 5sigma = 233 DPMO = 0,02 % tasa de error (99,98 % de eficiencia) 6sigma = 3,4 DPMO = 0,00003 % tasa de error (99,9997 % de eficiencia) Si se lograra la meta de Six Sigma se alcanzaría una calidad de resultados de producción sin errores de 99,9997 %, es decir matemáticamente una curva de producción que asintóticamente tiende a la perfección o dicho de otra forma productos y servicios casi sin defectos o errores. Obtener 3,4 defectos en un millón de oportunidades es una meta bastante ambiciosa pero lograble. Motorola alcanzó en 1991 6 Sigma [Schmelzer08]. En la práctica esto significa que las posibilidades de mejorar significativamente los resultados son ilimitadas.

(SIGMA, 2015)Hoy en día Six Sigma es un método de mejora continua muy difundido en todos los rubros a nivel mundial. El método nació en la industria con el objetivo de mejorar la calidad de los productos en el rubro de manufactura, sin embargo actualmente en EEUU hay más organizaciones de servicios que compañías manufactureras utilizando Six Sigma, pero se debe mencionar que existen muy pocas empresas que han alcanzado el nivel de Six Sigma.

Metodologia DMAIC - SixSigma FUENTE: Extraido de http://aacarsa.com/calidad.php

3.9.2 Kaizen

Es una filosofía de gestión japonesa de calidad total cuyo objetivo principal es el dominio de los procesos de producción por medio del mejoramiento continuo focalizándose principalmente en las capacidades de las personas

Pág. 39


(HITPASS, 2013)Kaizen se podría traducir del japonés «Kai = cambio» y «zen = lo bueno». En el sentido figurado se puede interpretar como «cambio para mejorar»; el uso común de su traducción al español sería «mejora continua». La filosofía de Kaizen concibe errores y problemas como pequeños «tesoros» que esconden oportunidades de mejora y potenciales de innovación. Dicho de otra forma, si no se transparentan los problemas no podrán inducirse mejoras. En este sentido se trata de una metodología de trabajo tanto individual como colectiva.

«¡ Hoy mejor que ayer, mañana mejor que hoy!» [Imai97](« How can we do the job better tomorrow then we’re doing it today?») es la base de la filosofía Kaizen, ningún día debe pasar sin una cierta mejora. Dicho de otra forma el principio alude a que siempre es posible hacer mejor las cosas. En un seminario realizado en octubre de 2013 en Santiago de Chile, Masaaki Imai presentó los principios fundamentales de la filosofía de KAIZEN:

Mejoras todos los días Mejoras de todos los colaboradores Mejoras en todos los lugares de la empresa y la vida Desde pequeñas mejoras incrementales a mejoras estratégicas drásticas

Kaizen busca principalmente centrar sus esfuerzos en generar lo que llaman «un flujo lean en el puesto de trabajo (operaciones)». La optimización se lleva a cabo en el «Gemba (puesto de trabajo)». En el concepto de Kaizen, un flujo lean elimina las actividades que no agregan valor. Generalmente los enfoques tradicionales centran sus esfuerzos en mejorar la eficiencia, mientras que Kaizen busca principalmente eliminar aquellas actividades que no agregan valor (muda = desperdicio) y minimizar aquellas actividades que son necesarias pero no agregan valor añadido.

Desde el punto de vista de BPM, calza muy bien el principio fundamental de Kaizen que hay que centrar los esfuerzos en mejorar los procesos, antes que simplemente la orientación al resultado. Kaizen se focaliza en captar la demanda y los requerimientos de los clientes que les son de valor. La mejora se dirige tanto a los clientes internos como a los externos (el cliente manda!), sólo lo que al cliente le sirve tiene «valor». Kaizen contempla el próximo paso de un proceso como actividad dirigida al cliente y el paso que le antecede como proveedor. Cada usuario participante en el proceso se identifica como proveedor interno y cliente al mismo tiempo. Se compromete con sus clientes de entregar sus productos y servicios de acuerdo a los requerimientos de calidad y tiempos de entrega. Los actores de la mejora continua son las personas en todos los niveles de la organización por igual. El éxito de Kaizen depende fuertemente que las personas involucradas apliquen sus conocimientos expertos y capacidades. Las personas deben trabajar en grupos (teams), aplicar y compartir conocimiento, analizar en forma abierta, proponer como grupo de trabajo mejoras, y tomar responsabilidad sobre sus decisiones. Los grupos de trabajo actúan como pequeñas empresas autónomas dentro de la organización. Ellos planifican, analizan, toman

Pág. 40

Asignatura: NOTACION DE PROCESOS DE NEGOCIO decisiones, implementan mejoras y se comunican en forma independiente con sus proveedores y clientes. Como consecuencia se simplifican y acortan los procesos de decisiones al interior de la organización. Los dirigentes de niveles superiores pueden concentrarse a realizar su verdadera función, la gestión estratégica.

Principios generales de Kaizen

Orientación hacia el proceso, antes que simplemente orientación al resultado Involucrar a todos los participantes de una cadena de producción o servicio Compromiso de los altos niveles gerenciales Una comunicación vertical y horizontal eficaz y sin trabas Mejoramiento continuo de todos los productos y procesos, internos y externos El cliente manda La inversión en personal La gestión de calidad se inicia y concluye con la capacitación Dos cabezas piensan mejor que una Todos participan en la determinación y comunicación de las metas

Ciclo de mejora Kaizen FUENTE: Extraído de http://filosofia5s.blogspot.com/p/filosofia-5s-kaizen-kamban.html

3.9.3

Lean Management

(HITPASS, 2013) La metodología Lean Management surge de la necesidad de eliminar pasos innecesarios en el cadena de producción, controlar las actividades primarias y dar control al que hace el trabajo como apoyo a la cadena de valor. Es así como su nombre nos indica claramente la dirección a la cual se dirige: “Manufactura esbelta o ágil”. Su mayor aporte está en que, al ser correctamente aplicada, se disminuyen costos, además de mejorar los procesos y eliminar los desperdicios, lo que se traduce directamente en el aumento de la satisfacción de los clientes y la mantención del margen de utilidad. Como toda metodología,

Pág. 41

Asignatura: NOTACION DE PROCESOS DE NEGOCIO cuenta con principios que son clave para llevar cabo de manera exitosa, las cuales apuntan a lo siguiente:[ Cautre10]

1. Calidad perfecta a la primera: Es decir, búsqueda de cero defectos, detección y solución de los problemas en su origen, evitando así las dificultades que podrían afectar al proceso de producción. Por esto es tan importante la identificación de la totalidad del flujo de valor para cada producto, concretamente el análisis del flujo de valor mostrará casi siempre la existencia de tres tipos de acciones a lo largo del mismo. Antes de seguir en los pasos de producción, se descubrirán muchos pasos cuya creación de valores es inequívoca, también se descubrirán muchos otros pasos que no crean valor alguno, pero que son inevitables de acuerdo a la tecnología actual y los activos de producción disponibles; y luego se logra descubrir los pasos adicionales que no crean valor alguno y pueden evitarse de modo inmediato. 2. Minimización del despilfarro: Esto se refiere a la eliminación de todas las actividades que no son de valor añadido y redes de seguridad, también la optimización del uso de los recursos escasos, como son el capital, recursos humanos y espacio. Permitir un flujo continuo y una operación más eficiente ayuda y facilita a que las cosas funcionan mejor cuando se concentra en el producto y sus necesidades, en lugar de hacerlo en la organización o la maquinaria, de forma que todas las actividades necesarias para diseñar, solicitar y proporcionar un producto se realicen en un flujo continuo. 3. Mejora continua: Apunta a la reducción de costos, mejora de la calidad, aumento de la productividad y compartir la información entre los miembros del grupo de producción. Se busca la perfección en el producto, y para lograrlo es fundamental la transparencia, el hecho que todos los que están involucrados en el proceso, como son subcontratistas, proveedores de primer nivel, integradores de sistemas, distribuidores, consumidores, empleados, pueden ver todo de forma que resulta más fácil descubrir mejores metodologías para la creación de valor. 4. Procesos "pull": Esto quiere decir que los productos son tirados, es decir solicitados por el cliente final, no empujados por el final de la producción, para asegurar la satisfacción total de quien solicitó el producto. Para lograr esto es necesario diseñar, programar y hacer exactamente lo que el consumidor desea y en el momento que lo desea, dejando que el cliente sea quien atraiga el producto de acuerdo a sus necesidades, en lugar de empujar productos, a menudo no deseados, hacia el consumidor. 5. Flexibilidad: Esto apunta a la capacidad de producir rápidamente diferentes mezclas de gran variedad de productos, sin sacrificar la eficiencia debido a volúmenes menores de producción. 6. Construcción y mantenimiento de una relación a largo plazo con los proveedores tomando acuerdos para compartir el riesgo, los costes y la información, lo que podría definirse como la clave del pensamiento lean, es decir, el valor del producto, el cual sólo puede ser definido por el cliente final, y sólo es significativo cuando se expresa en términos de un producto específico que satisface las necesidades del consumidor a un precio concreto, en un momento determinado.

Pág. 42


Ilustración 1 Características - Lean Managment. FUENTE:

Extraído

de

http://www.eoi.es/blogs/nayellymercedeslazala/2011/12/18/lean-

manufacturing-y-sus-herramientas/ 3.9.4

Benchmarking

El benchmarking es un proceso para medir la calidad de los productos y servicios o el desempeño de los procesos comparándose con competidores más fuertes o de alguna otra industria que muestra un excelente desempeño de sus procesos relacionados con los que se quieren medir. Desde el punto de vista de BPM el benchmarking puede servir como un argumento para fundamentar la necesidad de introducir gestión orientada a procesos en la organización. Benchmarking es un instrumento muy valioso para determinar objetivos centrados en mejorar la competitividad a través de la medición del desempeño de los procesos propios y compararlos continuamente con los competidores. El benchmarking no tiene un origen preciso, se conocen algunos antecedentes en Japón a través del denominado shukko o préstamo de empleados entre empresas para mejorar las prácticas; otra teoría indica que comenzó en centros de investigación en Estados Unidos a través de la comparación de diagramas y también existen otras hipótesis. En el mundo de los negocios se comenzó a ver en Estados Unidos a inicios de los 80, cuando Xerox inició un proceso denominado benchmarking competitivo a raíz de una crisis que impulsó la búsqueda de mejoras en sus procesos productivos, buscando el porqué la competencia vendía al mismo precio cuando los productos que manufacturaba Xerox eran de calidad.

(HITPASS, 2013)En la literatura nos encontramos con diferentes conceptos de benchmarking. Las definiciones más antiguas lo describen como un instrumento de comparación, mientras que actualmente se utiliza más para observar las buenas prácticas de otras organizaciones y adaptarlas a los procesos propios. A continuación se citan algunas definiciones de reconocidos autores:

Pág. 43

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Robert Camp [Camp89] define Benchmarking como «un proceso continuo para medir productos, servicios y prácticas contra los competidores más duros o aquellas compañías reconocidas como líderes en la industria». Michael Spendolini [Spendolini05] define Benchmarking: como «un proceso sistemático y continuo para evaluar los productos, servicios y procesos de trabajo de las organizaciones que son reconocidas como representantes de las mejores prácticas, con el propósito de realizar mejoras organizacionales». Robin Mann [Mann08] define Benchmarking como «aprender de la experiencia positiva de otros». Según Robin Mann [Mann08-1]: Las organizaciones están constantemente buscando nuevas formas y metodologías para mejorar su desempeño y obtener una ventaja competitiva. Mientras buscan la mejora de sus propios procesos de negocio, muchas organizaciones reconocen la importancia del aprendizaje de las mejores prácticas que han logrado otras organizaciones. Al eliminar la necesidad de reinventar la rueda y que proporciona la posibilidad de adoptar prácticas de eficacia probada, el benchmarking comparativo se ha convertido en una importante metodología para proporcionar una vía rápida de alcanzar la excelencia organizacional. Existen dos tipos de benchmarking, el informal y el formal, por lo general se utiliza el benchmarking informal, pero se debe trabajar en diseñar y ejecutar benchmarking formal en todas las organizaciones.

Tipos de benchamarking FUENTE. Extraído de http://es.slideshare.net/yohadriana/presentacin-benchmarking 3.9.5

El modelo EFQM

Es un marco de trabajo (referencia) estandarizado y un modelo de gestión que busca la satisfacción de todos los Grupos de Interés (stakeholders): Clientes, Personas, Inversionistas, Alianzas y Proveedores en concordancia con el medio ambiente a través de sus Personas, Procesos, Recursos, Conocimiento y Tecnología.

Pág. 44

Asignatura: NOTACION DE PROCESOS DE NEGOCIO El Modelo EFQM se fundamenta en que el rendimiento general de una organización depende del «Liderazgo» que dirige e impulsa la estrategia, la cual se materializa a través de las «Personas», las «Alianzas» y sobre todo el control de sus «Procesos de Negocio».

Estructura del modelo EFQM

Pág. 45


UNIDAD II ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO BUSINESS PROCESS MANAGEMENT

Tema Nº 4: Arquitectura Empresarial 4.1 Definición de Arquitectura

(HITPASS, 2013) La palabra arquitectura por lo general pensamos en la estructura y en los planos de un edificio, pero en realidad el concepto de arquitectura está relacionada con cualquier tipo de obra, puentes, barcos, carreteras, monumentos y no sólo construcciones físicas sino también abstractas como organizaciones, aplicaciones y sistemas de software. La norma 1471-2000 del IEEE[ Hilliard00] define el término de arquitectura como: «the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution, where: fundamental organization means essential, unifying concepts and principles system includes application, system, platform, system-of-systems, enterprise, product line, ... environment is developmental, operational, programmatic, . . . context of the system

Podemos resumir que el término arquitectura se refiere a un todo estructural. Se trata más que el detalle de mostrar la relación entre las partes en un entorno complejo. Se responde por consiguiente a la pregunta de ¿por qué? se necesita una arquitectura: Los sistemas organizacionales son complejos y por lo general dinámicos, es decir están sometidos al cambio de requerimientos, la mejora y la actualización. 4.2 Definición de Arquitectura Empresarial AE

Ejemplo de la construcción de un edificio: Antes de empezar a construir un edificio, la empresa constructora requiere de todos los planos comenzando por los planos estructurales que define la estructura fundamental de la obra sobre los cuales los fundamentos se sustentan, pilares fundamentales, estática y estabilidad del edificio. Luego por cada planta y por cada departamento existen planos que muestran la distribución de los espacios. Además, por cada instalación como electricidad, gas, calefacción, cañerías de agua fría y caliente, desagüe, red húmeda, red seca, red de cableado de televisión y teléfono, existen planos individuales.

Pág. 46

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Todos estos planos tienen puntos de conexión: el edificio con sus proveedores externos, provisión de áreas comunes, distribución entre plantas y departamentos y finalmente por cada departamento debe existir un plano por cada instalación. Ahora formulamos la pregunta, si usted como dueño de un departamento quiere agregar un interruptor de luz a la salida de la cocina al comedor, porque sólo se puede prender y apagar a la entrada de la cocina que es por hall principal. Bueno, tendrá que llamar a un electricista y lo primero que hará es pedirle los planos para estudiarlos y hacerle una propuesta de un proyecto eléctrico. ¿Qué sucedería si los planos se perdieron o ya no existen? En términos vulgares diríamos «¡ hay que entrar a picar para ver por donde van los ductos!». Si esta situación la comparamos con una organización o empresa y ésta requiere realizar un cambio, en similitud al caso del edificio, podríamos preguntar, ¿dónde están los planos para estudiar que podemos aprovechar y dónde impactan los cambios? Es aquí entonces, donde por general nos encontramos con una triste realidad: «¡ los planos no existen!», «¡ hay que entrar a picar!». En una organización «entrar a picar» significa realizar un ante-proyecto y levantar toda la información necesaria para el estudio de factibilidad técnica y económica. Si tuviéramos los planos empresariales podríamos ahorrarnos gran parte del ante-proyecto, en este sentido el ante-proyecto reconstruye los planos y se puede pasar directamente a la etapa del estudio de factibilidad. Literatura sobre el arquitectura empresarial es abundante y se encuentran muchas definiciones al respecto, pero la mayoría de ellas coinciden que una AE es un conjunto de modelos y sus relaciones, que describen la empresa como una estructura coherente. Su principal funcionalidad es de proveer de un fundamento para lograr mayor agilidad y control en la gestión del cambio en las empresas. Si buscamos un denominador común de todas estas definiciones podríamos resumir: Una Arquitectura Empresarial es un conjunto de modelos que describe la empresa como una estructura coherente, documenta el estado actual de la organización, el estado deseado y la brecha entre ambos. Con el objetivo de abstraer y sintetizar la complejidad de un sistema organizacional es necesario distinguir y gestionar los niveles y vistas de la Arquitectura Empresarial por separado. Para lograr la separación de las capas de Negocio, Integración y Aplicaciones, es necesario diseñar y construir una Arquitectura Empresarial que cumpla con los siguientes requisitos: Cada capa tiene sus objetos y lógica propios. Cada capa debe gestionarse en forma separada, pero en coherencia con las demás. Desde el punto de vista estructural, una arquitectura empresarial es: un mapa del negocio y de la organización, la descripción de los objetivos del negocio, la descripción de los procesos de la organización, la descripción a nivel funcional de los servicios de la organización, la descripción de las interfaces a nivel macro de los sistemas de la organización, la descripción de los sistemas reales implementados y la descripción de sus productos, servicios y sus mercados.

Pág. 47


Componentes de la arquitectura empresarial FUENTE: http://www.colombiadigital.net/actualidad/articulos-informativos/item/8123-que-esarquitectura-empresarial.html

4.3 Drivers y Objetivos de una AE

(HITPASS, 2013) Zachman describió acertadamente las razones de por qué se justifica o hace necesario trabajar con un concepto de una arquitectura empresarial en una organización:

1. Levantar y construir los modelos: Si la empresa existe también existen los modelos Es necesario invertir en construir los modelos 2. La empresa es el sistema: La suma de los procesos manuales y automatizados son la empresa AE no es un problema técnico, es un problema empresarial 3. La realidad organizacional es la necesidad de estructuración: Todas las necesidades que requieren un buen funcionamiento de los procesos y sistemas son necesidades empresariales Existe una serie de «drivers» (utilizamos el término en inglés porque engloba una serie de significados en conjunto que son difíciles de traducir como, hilo conductor, motivador, gatillador, justificador, necesidad, etc.) tanto internos (son impulsados desde el interior de la organización) como externos (requerimientos que impactan desde afuera a la organización) que requieren de mando y control.

Pág. 48


Drivers de una AE FUENTE: (HITPASS, 2013) Necesidad de Abstracción Como la realidad universal es para nosotros infinitamente compleja, para comprenderla se da la necesidad de abstraer y sintetizar el objeto de observación. Las principales características de un modelo son: La representación simplificada de un objeto real o abstracto Sólo descrito hasta un cierto nivel de detalle Descrito para representar sólo el aspecto de interés Descrito para cumplir un objetivo declarado Estandarización Contar con un estándar en BPM y en TI facilita la comunicación, la interoperabilidad, la independencia de plataformas tecnológicas, la transparencia, la formación de profesionales, la certificación de habilidades, las reglas de modelado, la documentación de modelos referenciales y por ende los costos de operación y la agilidad de negocio. La arquitectura empresarial, si cuenta con un metamodelo que pueda representar estos estándares, aporta a la integridad de los datos en los modelos que siguen los estándares. BPM Governance Definimos BPM-Governance como un modelo de gestión corporativa orientada a procesos, pero integrada con todas las capas de una organización, las fases del ciclo de gestión, la gestión del cambio de nuevos requerimientos, la estructura organizacional y todos los instrumentos de alineamiento de y entre las estructuras corporativas. BPM Governance abarca el alineamiento con todo el ciclo de gestión corporativa desde la planificación y gestión estratégica, la definición de planes de negocio, el ciclo presupuestario, la definición de perfiles y cargos, la gestión en operaciones, apoyo tecnológico hasta el alineamiento con el portafolio de proyectos corporativo. La pregunta clave que se da en este contexto es cómo podemos cumplir con los requerimientos de integración de modelos sin una plataforma que permita relacionarlos y mantener miles de relaciones de negocio, que se conocen y aplican en un repositorio integrado como ARIS. Otra pregunta clave es cómo mantener el control en la dinámica del cambio empresarial sin el apoyo de una plataforma que mantenga relacionados los objetos de un modelo con otro. Se agrava la Pág. 49

Asignatura: NOTACION DE PROCESOS DE NEGOCIO situación aún más si incorporamos la dimensión del tiempo. La situación actual de un modelo es una dimensión, pero ¿cómo controlamos las «n» dimensiones que están destinadas al cambio (futuro)? Si además se considera que cada capa tiene su propio ciclo de vida y que tienen que ser coordinadas con las otras en n dimensiones de tiempo, ¿cómo mantenemos el control? Conocimiento experto puede ser una respuesta, pero aunque dudo que un experto pueda controlar todas las variables en su mente, queda por responder si la evolución no tiende a estandarizar las buenas prácticas. Time to market Es el tiempo que se requiere para introducir un nuevo producto o servicio (innovación) al mercado desde que es concebido hasta que esté disponible para la venta. Empresas que mantienen un área de investigación y desarrollo (I + D) cuentan con un proceso en la cadena de valor llamado «Product Lifecycle Management (PLM)», entonces el time to market es el tiempo de ciclo del proceso PLM que se intenta constantemente reducir al máximo. Por lo general el PLM comienza con el estudio de mercado, demanda estudiada que se combina con ideas de innovación. La I + D en el PLM está fuertemente anclado con el concepto de creación de valor para el cliente.

Product Lifecycle Management (PLM)

La arquitectura empresarial puede contribuir en dos aspectos importantes a reducir los tiempos de ciclo del PLM: 1. Identificar los elementos que se pueden reaprovechar de las estructuras existentes 2. Evitar iteraciones en las etapas de planificación y especificación, aprovechando la buena documentación que entrega una base de modelos integrada de una arquitectura empresarial Si la empresa tiene documentado en un repositorio integrado sus procesos, productos y servicios, mapa estratégico y objetivos de negocio, aplicaciones e infraestructura de TI, entonces puede revisar en qué componentes impacta el nuevo producto. Se ahorra el tiempo de levantar y validar toda esta información. Por otro lado, muestra relaciones de negocio documentadas que fácilmente se olvidarían al levantar por primera vez la información requerida. Gestión de calidad Los modelos que se desarrollan en el marco de una arquitectura empresarial facilitan la comunicación y el entendimiento común sobre los requerimientos entre las capas de estrategia, negocio y tecnología con los diferentes stakeholders. El empleo de los modelos de una AE

Pág. 50

Asignatura: NOTACION DE PROCESOS DE NEGOCIO conlleva a una mejora sustancial de los procesos de planificación y permite detectar y evitar redundancias y aprovechar sinergias de otros proyectos en curso. Otros aspectos como cumplimiento de regulaciones, seguridad y mejor control se complementan positivamente con los atributos de calidad de productos y servicios. La Globalización La empresa que pueda adaptarse más rápido a los constantes cambios en el mercado, que son además cada vez más frecuentes, tendrán mayores ventajas competitivas que aquellas que no logran adaptarse al ritmo que la globalización exige. BPM en sí no ofrece ningún instrumento para administrar la complejidad del cambio frecuente. BPM se puede apoyar del concepto de administración del cambio que ofrece una AE. El apoyo a la estandarización y la integración de componentes es el fuerte de las arquitecturas empresariales. Cumplimiento de regulaciones Regulaciones son el conjunto de procedimientos y reglas que adoptan las instituciones en el marco de políticas de negocio, sean éstas de carácter legal, financiero contable, seguridad, arancelario, sanitarias, medio ambiente, u otros aspectos de interés no nombrados. El seguimiento de cumplimento de regulaciones se puede complementar perfectamente con el seguimiento de procesos de negocio, porque están directamente relacionados. Para identificar en qué etapas de un proceso de negocio influyen las regulaciones, se pueden desarrollar vistas especializadas en una AE en la cual se relacionan las actividades de un proceso o un subproceso con las materias de regulación. Relación con externos Es importante para las organizaciones coordinar y diseñar las relaciones de negocio con su mundo externo en forma objetiva y formal. El estándar de BPMN 2.0 cuenta un con diagrama especial llamado «diagrama de coreografía» para diseñar el flujo de mensajería con los participantes externos de un proceso de negocio. La AE se presta especialmente para documentar vistas individuales y relacionarlas con otras. Se evita redundancia, se facilita la comunicación y prevalece la integridad. Fusiones y adquisiciones Si dos empresas se fusionan o una adquiere otra de un mismo rubro queda claro que también se deben fusionar y estandarizar los procesos de ambas compañías. Migrar sistemas de información y armonizar procesos de negocio constituyen proyectos complejos y de alto riesgo. Así debiera ser posible documentar los procesos y los sistemas de cada empresa por separado, desarrollar modelos referenciales y luego referenciar las componentes de cada empresa con los modelos referenciales. Estas vistas permiten planificar proyectos integrados que consideran dependencias lógicas y temporales.

Pág. 51


Tema Nº 5: Áreas de una Arquitectura Empresarial Se ha definido la arquitectura empresarial en el contexto de BPM, pero el concepto de AE se puede concebir y aprovechar para integrar la planificación de otras áreas o disciplinas empresariales.

Áreas de una arquitectura empresarial 5.1 Business Process Outsourcing (BPO)

Es la externalización de uno o más procesos de negocio incluyendo el de TI que los soporta. El BPO es el servicio más completo que se pueda recibir como externalización porque incluye Data Center, Servicios de Comunicaciones, Application Management , Configuración de los procesos a medida (workflow), Seguridad y mesa de ayuda. EL BPO constituye una relación muy estrecha entre el cliente y el proveedor. El cliente de BPO se concentra en la gestión estratégica y en el diseño y rediseño de los procesos y comunica los requerimientos de adaptación y cambio al proveedor de BPO. La pregunta clave es entonces ¿qué instrumentos va a utilizar el cliente para especificar y documentar la lógica de negocio, definir los niveles de servicio (SLA: Service Level Agreement), llevar a cabo los procesos de alineamiento y control de cambio? Una plataforma de AE se convierte en el instrumento predestinado para estos fines. Se pueden administrar en forma integrada todas las funcionalidades mencionadas anteriormente y sobre la misma plataforma se pueden gestionar los mecanismos de coordinación con el proveedor.

Pág. 52


5.2 Gestión de calidad - riesgo - conocimiento - regulaciones - otras La gestión de calidad debiera orientarse a los procesos de negocio, porque la calidad de los procesos está directamente relacionada con la calidad de los productos y servicios. La calidad es una propiedad o un atributo del bien y el conjunto de propiedades definidas de forma que se puedan medir, representan al grado de «calidad» de un producto o servicio. La gestión de riesgo tiene como objetivo manejar la incertidumbre relativa a la ocurrencia de un suceso negativo (amenaza) que puede, si sucede, afectar, parar o destruir la marcha de uno, varios o todos los procesos organizacionales. Por consiguiente, la gestión de riesgo se centra primero en identificar y evaluar los posibles riesgos. Al igual que en calidad, el riesgo es una propiedad de una actividad o de un proceso completo relacionado con los productos y servicios destinados al cliente. La gestión de conocimiento es controlar la curva de aprendizaje de las personas en una organización. La gestión del conocimiento está muy relacionada con la gestión del cambio (cultural) en una organización. Las personas, para cumplir con sus roles de gestores, requieren de diferentes materias de conocimiento. Por lo tanto, para detectar la brecha del grado de conocimiento requerido, con el grado de conocimiento existente, se da la necesidad de levantar la estructura del conocimiento requerido y representarlo en modelos, igual que en las otras disciplinas de gestión. En gestión de regulaciones habrá que identificar cuáles actividades o procesos están sujetos al cumplimiento de regulaciones y cuáles son las variables que deben monitorearse para lograr una trazabilidad que lleve el registro de cumplimiento de ellas. Cada área de gestión debe recurrir como fuente y fundamento al mismo modelo de procesos y relacionar los objetos y atributos de sus modelos (calidad, riesgo, conocimiento, etc.) con el modelo central de procesos. Esto prácticamente no es posible sin una plataforma integrada con un repositorio común.

5.3 Auditoría Proceso de control de gestión en diferentes ámbitos (se denomina también auditoría interna) como: Auditoría informática, proceso de control para determinar si un sistema de información mantiene la integridad de los datos, se cumplen los niveles de servicio, detectar fraudes, grados de vulnerabilidad y si se utilizan eficientemente los recursos. Auditoría medioambiental, cumplimento de regulaciones medioambientales de una organización. Auditoría jurídica, cumplimento de las cláusulas de los contratos sujeta a penalidades, infracciones y garantías. Auditoría de innovación, proceso de comparación de la situación actual con la innovación esperada.

Pág. 53

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Auditoría presupuestaria y de operaciones (control de gestión), proceso que monitorea el cumplimiento del ciclo presupuestario y los objetivos de negocio. En general, cualquier proceso de control interno de una organización es coercitiva y su eficiencia puede evaluarse por medio de una auditoría. El auditor necesita una referencia para evaluar y medir si existen desviaciones de los objetivos de la auditoría. Los modelos documentados en una AE presentan un excelente punto de partida para estos fines. El auditor puede verificar si las aplicaciones y procesos implementados en operaciones corresponden con los modelos validados por la dirección de la empresa. Recordemos que la auditoría consiste en apoyar a los miembros de la empresa en el desempeño de sus actividades, objetivos que debieran estar documentados en una AE. 5.4 Portafolio de proyectos

Hoy en día es común en las organizaciones desarrollar portafolios de proyectos para usarlos como medio de evaluación. Sin embargo, estos portafolios carecen de fundamento si éstos no consideran las múltiples dependencias que existen en y entre las capas de negocio, de integración y tecnologías de información. Este hecho aumenta la complejidad si consideramos que existen también estados actuales y deseados en cada una de las capas y entre ellas[ Hitpass-Richter93]. 5.5 ITIL (Information Technology Infrastructure Library)

ITIL es un modelo referencial de buenas prácticas para la gestión de servicios de tecnologías de la información en operaciones. ITIL describe procedimientos detallados de las actividades en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía facilitadora que abarque toda la infraestructura, el traspaso de desarrollo a producción y las operaciones de TI. En una AE se puede documentar el modelo específico de ITIL adoptado a la organización de la misma forma como se documentan los modelos referenciales de los procesos de negocio. El modelo de ITIL representado en la AE sirve como especificación de implementación, como manual de procedimiento, material de capacitación, manual de referencia para auditorías y documentación para el control de cambio de requerimientos.

Pág. 54


Tema Nº 6: Estándares de Gestión Empresarial. 6.1 Relación Arquitectura Empresarial – Business process Management - Service Oriented Architecture (AE & BPM & SOA)

Persiguen los mismos objetivos generales de dejar disponibles técnicas de planificación, modelamiento, alineamiento y control, pero en diferentes grados de abstracción y objetivos específicos. No obstante, estos tres conceptos no son independientes, encajan como un engranaje que debe sincronizarse para su buen funcionamiento.

Modelos esenciales en la intersección de un concepto integrado EA, BPM y SOA Fuente: [Stähler-etal-09]

AE-BPM-SOA nos encontramos con una serie de artefactos (en AE se entiende como artefacto, cualquier elemento, o modelo que representa un objeto real físico o abstracto, como cargo, proceso, datos, servicios, objetivo, topología de red, etc.) comunes; los podríamos denominar «modelos esenciales» que comparten y traspasan información entre las capas. Para satisfacer los objetivos específicos de la dirección de la empresa, operaciones y TI se deben coordinar los puntos de intersección. La integración de las vistas específicas de EA, BPM y SOA tiene por objetivo trabajar sobre un solo modelo integrado. Ha de considerarse que no es fácil reducir los filtros de cada capa a los puntos de intersección entre ellos, pero si tenemos en cuenta qué responsabilidad tiene cada una de las áreas podemos concluir:

La capa de AE es una representación abstracta y descriptiva de la organización en general. Su objetivo es describir las componentes de la organización y sus relaciones a muy alto nivel. La descomposición y descripción en detalle no es el ámbito de una AE.

La capa de BPM se focaliza en la descripción de los procesos y su respectiva lógica de flujo. La lógica de negocio se describe en detalle.

Pág. 55

Asignatura: NOTACION DE PROCESOS DE NEGOCIO La capa de SOA tiene el objetivo de diseñar una arquitectura de software basada en el concepto de servicios para implementar técnicamente los procesos de negocio. Podemos resumir que hacia el ámbito de una AE el nivel de abstracción de los modelos de negocio es mayor, y hacia la capa de SOA aumenta el nivel de detalle. Encontramos complejidad en la capa de AE en las relaciones de negocio entre objetos de modelos y complejidad en la interacción de componentes de servicios en la capa de SOA. La complejidad en la capa de BPM la encontramos en la lógica operacional de los procesos.

Niveles de abstracción de modelos en capas de EA - BPM - SOA

El grado de abstracción de modelos es siempre mayor hacia EA. A nivel de línea de negocio o corporativo se trabaja con mapas, es decir no perder la visión global. Lo que se busca es delimitar el contexto de los procesos, expresado en «desde - hasta» y como se relacionan los procesos con los otros tipos de objetos de negocio.

Grado de abstracción de modelos EA - BPM - SOA

Pág. 56

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Con el objetivo de evitar redundancias y de lograr un modelo de arquitectura integrado se deben definir claramente qué tipo de modelos pertenecen a qué capa y cuáles tipos de objetos son los que integran las siguientes capas. En nuestro ejemplo, tendríamos como modelos de la AE los mapas de la cadena de valor de los procesos y el tipo de proceso «cadena de valor» se sigue descomponiendo y describiendo en la capa de BPM. La capa de BPM conoce dos niveles de descomposición por proceso de negocio, el nivel descriptivo y el nivel operacional.

El nivel descriptivo describe la lógica de negocio a muy alto nivel, por lo general a nivel de subprocesos y no contiene casos de excepción. Representa un modelo abstraído de la complejidad y sirve para delimitar el contexto y la funcionalidad a nivel ejecutivo.

El nivel operacional (representado en la tabla por el tipo de objeto «actividad») abarca toda la lógica de negocio en detalle, incluyendo los casos de excepción, identificando las reglas de negocio, y la interacción en detalle con todos los participantes. Es independiente de la tecnología, pero sirve como especificación para la implementación.

El tipo de objeto «actividad» es el qué se sigue especificando en el nivel técnico y en este concepto representado por el nivel y modelo SOA.

Es importante de mencionar, que en una arquitectura de modelos integrados, no es imperativo modelar todo los tipos de objetos. Aquí rigen los mismos principios que para levantar y diseñar un modelo de datos, sólo se definen de acuerdo a los requerimientos de negocio las propiedades que describen un objeto de dato. Así por ejemplo si a una compañía de seguros generales no le interesa saber el color del vehículo a asegurarse, no se define como atributo en el modelo de datos.

Pág. 57


Tema Nº 7: Frameworks de Arquitectura Empresarial 7.1 Framework de AE Marco estructural que define los modelos, los tipos de objetos pertenecientes a un modelo, las relaciones de negocio entre los tipos de objetos y las relaciones entre los modelos del marco para un área de planificación, especificación y análisis. Un framework de AE es por consiguiente un modelo de referencia, pero estructural no procedural; define la estructura de un modelo, no los procesos. Los EA Frameworks no se pueden adoptar sin un estudio detallado de ellos y compararlos con la realidad organizacional de cada caso. Por esta razón, muchas empresas se orientan en alguno de ellos, pero finalmente definen su propio marco estructural de arquitectura empresarial; resulta más fácil que entender y adoptar estos compendios en detalle. El Gobierno de EEUU promulgó una ley en el año 1996 para sus agencias federales, llamada «Clinger-Cohen Act». Esta ley obliga a organizaciones estatales en EEUU a desarrollar y mantener una Arquitectura Empresarial (CIO Council, 2001 ). Un estudio realizado en el año 2007 , revela que los frameworks más utilizados en la práctica son el framework de Zachman (28 %), TOGAF (27 %) y FEA (8 %) de todas las encuestas realizadas a empresas[ Schwarzer09], razón por la cual vamos a presentar en forma muy resumida estos Frameworks. A pesar que ARIS, no está nombrado en el estudio, lo vamos a presentar en el marco de este trabajo, porque es reconocidamente uno de los frameworks más utilizados en Europa y empresas globales sobre todo aquellas que son usuarias de SAP.

7.2 Framework de Zachman

Es un marco de trabajo para Enterprise Architecture (EA), creado y soportado por el instituto que lleva su nombre «Zachman International (anteriormente se llamó ZIFA: Zachman Institute for Framework Advancement)». Este framework emplea modelos y vistas de los diferentes elementos que forman parte de la arquitectura empresarial, contemplando dos dimensiones:

Perspectivas de participantes o modelos Preguntas esenciales a responder o puntos de vista

Zachman sostiene que cada sistema (una organización también es un sistema) se puede describir en forma completa respondiendo a las siguientes preguntas:

¿Qué? Los datos, sus relaciones y significados ¿Cómo? Los procesos y funciones de la corporación ¿Dónde? La red, tecnologías, distribución y localización de procesos, funciones y sistemas ¿Quién? La gente que forma parte de la compañía, considerando aspectos como seguridad y roles hasta la organización de la compañía y los flujos de trabajo existentes Pág. 58

Asignatura: NOTACION DE PROCESOS DE NEGOCIO ¿Cuándo? El tiempo, representando ciclos, estructuras de proceso, de control y eventos de negocio ¿Por qué ? Las motivaciones en los diferentes segmentos de la compañía: objetivos de negocio, planes estratégicos, diseño y especificación de reglas, etc.

Las perspectivas captan todos los modelos requeridos para el desarrollo de sistemas. Cada modelo está relacionado con un determinado perfil dentro de la compañía:

Alcance: perfil Visionario o Planificador Negocio: perfil Propietario Sistema: perfil Diseñador Tecnología: perfil Constructor Representación Detallada: perfil de ejecución (Adjudicatario de Contrato) Configuración de componentes: perfil Implementador Instancias funcionales de la empresa: perfil Trabajador

De las preguntas del negocio y las perspectivas de los participantes, Zachman desarrolló una matriz, llamada “The Zachman Framework”. Lo que la matriz busca es ordenar la arquitectura y que haya definiciones para cada uno de estos aspectos. Al framework de Zachman se le reconocen los siguientes beneficios y ventajas: Es simple y fácil de entender Contempla la Empresa como un todo Es independiente de herramientas y modelos Presupone que se requieren multimodelos para describir la organización desde sus diferentes perspectivas

Entre las desventajas nos encontramos con los siguientes aspectos: El framework está muy orientado hacia TI, no cuenta con una perspectiva estratégica No incluye los procesos de alineamiento No cuenta con metamodelo Los modelos son independientes, no existe asociación entre ellos El framework es sólo descriptivo, no es posible reusar los modelos No incluye un proceso de análisis

7.3 TOGAF (The Open Group Architecture Framework)

TOGAF son las siglas de «The Open Group Architecture Framework» y, por tanto, pertenece a The Open Group, un consorcio que está formado por empresas y profesionales del sector TI, con el objetivo de marcar directrices, independientes de fabricantes, en el mundo de la Arquitectura TI.

Pág. 59

Asignatura: NOTACION DE PROCESOS DE NEGOCIO TOGAF, a diferencia de otros frameworks, cuenta con un marco estructural y una metodología de procedimiento (ADM: Architecture Development Method) para la configuración y el uso del framework.

TOGAF está compuesto de cuatro dimensiones:

Arquitectura de Negocios (o de Procesos de Negocio), la cual define la estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de la organización.

Arquitectura de Aplicaciones, la cual provee un plano (blueprint , en inglés) para cada uno de los sistemas de aplicación que se requiere implantar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio centrales de la organización.

Arquitectura de Datos, la cual describe la estructura de los datos físicos y lógicos de la organización y los recursos de gestión de estos datos.

Arquitectura Tecnológica, la cual describe la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales, de misión crítica, de la organización. 7.4 FEA (Federal Enterprise Architecture)

El Gobierno de EEUU obliga a organizaciones estatales en EEUU a desarrollar y mantener una Arquitectura Empresarial. El objetivo principal del framework es lograr el desarrollo y mantención de una plataforma de entendimiento común en la integración de procesos y sistemas de información entre las agencias estatales. La utilización del framework propone el uso de términos comunes para la construcción de las arquitecturas de las diferentes instituciones pertenecientes al Gobierno. FEA Se compone de varios modelos de referencias que crean una taxonomía y ontología común para la descripción de los recursos TI, generando la arquitectura empresarial. Entre estos modelos se incluyen:

Performance Reference Model Business Reference Model Service Component Reference Model Data Reference Model Technical Reference Model

Pág. 60

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 7.5 ARIS (Architecture of Integrated Information Systems)

Es un marco estructural desarrollado por Scheer[ Scheer92] a principios de los años 90, cuyo foco principal fue el desarrollo de una arquitectura que permitiera relacionar y describir procesos de negocio y sistemas de información en forma integrada. Para estos efectos Scheer presenta en su concepto estructural la descomposición de modelos en niveles y vistas en el marco de una arquitectura llamada «ARIS House», que distingue: Cinco Vistas Vista organizacional Vista de datos Vista funcional Vista de control Vista de productos y servicios Tres Niveles Definición de requerimientos Diseño y especificación Implementación

ARIS House Este mismo metamodelo fue implementado en una herramienta de AE que lleva el mismo nombre de ARIS. El corazón de ARIS es una técnica para modelar procesos llamada EPC (Event driven Process Chains).

Pág. 61

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 7.6 Enterprise Architecture as Strategy (Ross et al)

Los expertos en gestión estratégica del MIT (Ross - Weill) y el Instituto de Gestión Estratégica St Gallen en Suiza (Robertson) publicaron una metodología de cómo plasmar la estrategia de una empresa en los procesos críticos para introducir BPM en organizaciones, basado en un marco de arquitectura empresarial (Enterprise Architecture as Strategy, Harward Press 2006)[ Ross et al 06]. La idea principal de este concepto es identificar primero el tipo de modelo de procesos o configuración de valor que tiene la empresa, de los cuales existen según Ross et al fundamentalmente cuatro tipos, diversificación, coordinación, replicación y unificación. Cada uno de estos modelos de negocio determina un diferente grado de estandarización y grado de integración que se necesita en los procesos para lograr un rediseño de los modelos de negocio que cumplan con un alto grado de eficiencia operacional en los procesos de negocio. A continuación se presentan en forma resumida los cuatro tipos de modelos operacionales, con las siguientes características:

1. Diversificación: Bajo grado de estandarización e integración de procesos de negocio. Ejemplo: Holding que agrupa diferentes empresas de un rubro o negocios complementarios, que tienen necesidad de integración en su logística de transacciones, pero que son independientes en sus operaciones y modelos de negocio. 2. Coordinación: Alto grado de integración de la información que se requiere compartir y bajo grado de estandarización en los procesos de negocio. Ejemplo: Rubro financiero, en el cual se concentran alrededor del cliente múltiples canales de venta de diferentes productos. 3. Replicación: Alto grado de estandarización de los procesos de negocio y bajo grado de integración entre ellos. Ejemplo: Empresas de un holding que operan en mercados independientes, es decir, se caracteriza por la ausencia de clientes y proveedores globales. Se replican modelos de procesos altamente estandarizados, pero administran sus propias bases de clientes y reglas de negocio. 4. Unificación: Alto grado de estandarización e integración de los procesos de negocio. Ejemplo: Industria química con la característica de poseer tanto clientes y proveedores locales como globales. Centralización de los procesos de manufactura, gestión de orden de compra, finanzas, recursos humanos, etc. El modelo diseñado de acuerdo a estas dimensiones claves, que son la combinación de los diferentes grados de necesidades de estandarización e integración de procesos, se convierte en la base y el fundamento de un modelo referencial y a la vez una guía para todos los proyectos de BPM que se desarrollen en el futuro.

Pág. 62

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Tema Nº 8: Modelos de Madurez de BPM

8.1 ¿Qué es un modelo de madurez?

Representa una guía facilitadora que permite evaluar el estado de desarrollo de un área en especial. La aplicación de estas guías permite a las organizaciones: Conocer su nivel actual de madurez Identificar elementos ausentes y que son necesarios para alcanzar niveles superiores de madurez Identificar las fortalezas ya establecidas en la organización Poseer un mapa general de los elementos necesarios para mejorar 8.2 Modelo de Madurez BPM de la OMG (BPMM: Business Process Maturity Model)

BPMM se considera como un mapeo directo con el CMMI, sin embargo, los modelos presentan orientaciones distintas: el primero se enfoca en los «workflows» y procesos de la organización y su administración, mientras que el segundo tiene su foco en la administración de proyectos.

Los cinco niveles de madurez del modelo BPMM Fuente: [OMG08]

Cada etapa o nivel de madurez cimienta requerimientos con el cual futuras mejoras pueden ser construidas Al igual que los otros modelos de madurez, BPMM está compuesto por niveles de madurez, los cuales son (ver figura 4.1):

Nivel 1 - Inicial: Donde los procesos de negocios son ejecutados algunas veces de forma inconsistente, con resultados difíciles de predecir. Nivel 2 - Gestionado: Donde la administración de los procesos se liga a procedimientos particulares dentro de unidades de trabajo, que aseguran que los procesos pueden ser ejecutados en repetidas ocasiones satisfaciendo los compromisos asumidos por el grupo de trabajo. Sin embargo, unidades de trabajo que ejecutan tareas similares pueden usar diferentes procedimientos. Nivel 3 - Estandarizado: Donde procesos comunes y estándares están sintetizados desde las mejores prácticas identificadas en el grupo de trabajo y guías de adaptación son provistas para dar

Pág. 63

Asignatura: NOTACION DE PROCESOS DE NEGOCIO soporte a distintas necesidades del negocio. La estandarización de procesos provee de una economía de escala y del principio para aprender desde comunes medidas y experiencias. Nivel 4 - Predecible: Donde las capacidades que se disponen por procesos estándares son explotadas y proveen retorno a las unidades de trabajo. El desempeño de los procesos es gestionado estadísticamente a través de “workflow” para comprender y controlar la variación, de modo que las salidas (o productos) de los procesos pueden ser predecidas desde estados intermedios. Nivel 5- Innovando: Donde tanto acciones de mejoramiento pro-activas como oportunas buscan innovaciones que pueden acercar las brechas entre las capacidades actuales de la organización y las requeridas para el logro de los objetivos del negocio. 8.3 Modelo de madurez BPM de Schmelzer

Tiene como base el modelo de madurez del EFQM (European Foundation for Quality Management)

Modelo de Madurez de BPM para los procesos (Schmelzer)

Nivel 1: Definición de los procesos • El proceso de negocio está identificado, documentado y validado. Nivel 2: Responsabilidad de los procesos • Existe un dueño de proceso, roles y responsabilidades definidas • El proceso se encuentra insertado en la estructura organizacional Nivel 3: Planificación de los procesos • Planificación y alineamiento de los procesos con los objetivos estratégicos de la organización Nivel 4: Monitoreo y control de los procesos • El proceso se controla por medio de KPI (indicadores claves del proceso) y se mide el grado de cumplimiento con los objetivos • Desviaciones inducen procesos de mejora Nivel 5: Optimización de los procesos • Gestión orientada al proceso y mejora continua • El directorio apoya en forma activa la optimización permanente de los procesos de negocio Pág. 64


UNIDAD III BUSINESS PROCESS MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN)

Tema Nº 8: Evolución de Business Process Model and Notation (BPMN) 8.1 Historia de técnicas para modelado de sistemas y procesos

(HITPASS, 2013) A partir de los años 60 se empezaron a desarrollar técnicas de modelado sobre todo orientadas al desarrollo de sistemas y la mayoría de éstas, enfocadas al modelamiento de datos y funciones. Lo que se buscaba encontrar eran vistas de datos normalizadas que debían ser administradas por la funcionalidad que se requería para el negocio, razón por la cual dominaban las técnicas centradas en flujos de datos, como lo fue el análisis estructurado (en inglés: Structured Analysis). El método de análisis estructurado se convirtió en su época en sinónimo del análisis de flujo de datos. Se desarrollaron herramientas para documentar y administrar los flujos de datos. Las herramientas eran esenciales para documentar los sistemas existentes y para determinar los requerimientos de información por medio del método estructurado.

Los analistas deseaban conocer las respuestas a cuatro preguntas especificas: ¿Qué funciones integran el sistema? ¿Qué datos necesita cada función? ¿Qué datos deben ser almacenados? ¿Qué datos ingresan y abandonan el sistema? De lo dicho anteriormente queda claro que se daba gran importancia a los datos.

Objetos del Diagrama Análisis Estructurado según Yourdon o Gane y Sarson Pág. 65


Ejemplo de Diagrama de Contexto con IDEF

Ejemplo de Descomposición del Diagrama de Contexto con IDEF

Pág. 66

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 8.2 Clasificación de las técnicas de modelamiento

(HITPASS, 2013) Formalmente podemos hacer la primera gran división en metodologías basadas en técnicas de lenguaje estructurado (script) y metodologías basadas en técnicas de diagramación. Las metodologías basadas en técnicas de diagramación, las podemos clasificar en técnicas orientadas al flujo de datos, al flujo de control y orientadas al objeto.

Clasificación de algunas técnicas de diagramación para modelamiento de procesos

8.3 Otras Técnicas de Modelado

(HITPASS, 2013) Antes que apareciera BPMN se difundieron bastante algunas técnicas orientadas al objeto para modelar procesos, sobre todo UML Activity Diagram (diagramas de los procesos a nivel descriptivo) y diagramas UML Use Case (Casos de uso en un nivel más detallado que describen el flujo entre actividades y unidades organizacionales).

Pág. 67

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Ejemplo de Use Case de UML

Ejemplo de Activity Diagrama de UML

8.4 Business Process Model and Notation (BPMN)

(HITPASS, 2013) La primera versión de la Business Process Modeling Notation (BPMN) fue desarrollada por el instituto Business Process Management Initiative (BPMI) principalmente bajo la tutela de Stephan A. White profesional de la IBM en 2004.

Pág. 68

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Desde un principio, el principal objetivo fue disponibilizar una notación gráfica, estandarizada, que permitiera automatizar los procesos a partir del diseño gráfico. En el año 2005 fue trasladado el proyecto a la Object Management Group (OMG ), debido a que el BPMI no era un instituto que administra estándares. La OMG es muy conocida en el mundo informático porque administra, entre otros, el estándar del lenguaje para el diseño de software llamado Unified Modeling Langauge (UML). A través de la OMG, de la cual son miembros la mayoría de los proveedores más importantes de TI, BPMN se difundió rápidamente a nivel mundial y casi todos los proveedores sean grandes o pequeños, académicos o consultores empezaron a adoptar este estándar. La última versión oficial 1.2 fue publicada en enero 2009 [OMG09]. La versión 2.0, completamente nueva y ampliada, se terminó a mediados del año 2010 y a finales de éste, el equipo de la OMG encargado de revisar y finalizar la nueva versión, llamada Finalization Task Force (FTF), dio la recomendación al gremio de decisión de oficializar la versión 2.0. A partir de la versión 2.0 la sigla BPMN cambia levemente de nombre a: Business Process Model and Notation. Paradojalmente hasta la versión 1.2 no se podían mapear los modelos directamente en un entorno técnico, porque aún no estaban definidos los atributos técnicos. Debido a esta falencia existieron muchos problemas en convertir (mapear) los modelos a lenguajes de ejecución como BPEL. Recién con la versión 2.0 existe un metamodelo que permite ejecutar directamente los modelos de BPMN. Estos dos hechos importantes de la nueva versión, es decir estandarización y habilidad de ejecución directa conlleva a los siguientes beneficios: Al 2011 existen más de 70 herramientas de modelación de BPMN (tendencia en aumento) y muchas de ellas se pueden adquirir gratis. La comunicación con otros socios de negocio que hayan aprendido BPMN (clientes, consultores, proveedores, etc.) será más rápida, fluida y expresiva. Se puede esperar que nuevo personal traiga el conocimiento de BPMN. Institutos de capacitación, universidades y empresas consultoras van a invertir recursos para formar profesionales en esta notación. Empresas privadas van a desarrollar soluciones basadas en este estándar, y proveedores de tecnología se encuentran desarrollando herramientas para ejecutar directamente el código gráfico de BPMN.

Fuente: http://bpmn-bayard.blogspot.com/2011/03/5-historia-del-bpmn.html Pág. 69

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Tema Nº 9: Los elementos básicos de BPMN 9.1 Modelos, instancias, token y correlaciones Como un diagrama puede Como un diagrama puede contener varios pools, se entiende que un diagrama puede contener n procesos. Modelo de procesos: En un diagrama pueden representarse uno o más modelos de procesos. Cada modelo constituye la descripción de un proceso. Instancia de proceso: Se entiende un proceso concreto en la realidad, es decir casos reales como por ejemplo la reclamación de un cliente crea una instancia del proceso de reclamaciones. Algunos procesos se instancian sólo un par de veces al año y otros más a menudo. Token (marca): Se utiliza para visualizar y probar el comportamiento de los procesos diseñados. Las marcas recorren en forma de una animación la lógica por los flujos normales y los de excepción. Correlación: Seguramente usted ha recibido muchas veces correspondencia de instituciones que contienen un número de referencia, número de acta, número de ticket, etc.. Si usted responde a la institución tiene que indicar esta referencia para que pueda ser identificada. A esta asignación en forma de un identificador se le llama correlación. Un caso siempre debe estar bien correlacionado para que no ocurran errores o pérdidas de datos. 9.2 Categorías de los elementos de BPMN Los elementos gráficos en BPMN se encuentran clasificados dentro de 4 categorías:

Fuente: http://bpmn-bayard.blogspot.com/2011/05/8-fundamentos-de-bpmn_28.html

Pág. 70


9.3 Actividades

Es cualquier trabajo que realiza la organización. Pueden ser atómicas o compuestas Las actividades las que transforman el estado de un objeto de negocio para que el proceso puede llegar a producir valor para los clientes.

Fuente: http://bpmn.16mb.com/conexionActividad.php

9.3.1 Tipos de Actividades

(HITPASS, 2014) Hasta la versión BPMN 1.2 no existía una simbología reservada para diferenciar los tipos de actividades. Esta falencia se superó a partir de BPMN 2.0, dando a las actividades indefinidas una simbología en su respresentación. a. Actividad Manual Es ejecutada por una persona, cuyo control no lo lleva un sistema de workflow o Process Engine.

Ejemplos: El guardar un acta en un archivo físico El aclarar por teléfono una factura mal emitida La conversación de un ejecutivo con su cliente b. Actividad Usuario También es ejecutada por una persona (usuario), pero en este caso el control lo lleva el sistema de workflow o Process Engine. Ejemplos: Revisar una factura Aprobar una solicitud de vacaciones Administrar una solicitud de soporte

Pág. 71

Asignatura: NOTACION DE PROCESOS DE NEGOCIO c. Actividad Servicio Es una actividad automática que es ejecutada completamente por algún software. BPMN parte normalmente de la base, que se trata de un servicio web, pero no es mandatorio. De todas formas se trata de una componente de integración de aplicaciones, con lo cual tenemos por esta vía la entrada al puente con las arquitecturas orientadas al servicio (SOA).

Ejemplo de servicios de integración: Solicitud de clasificación de riesgo crediticio a un sistema interbancario Verificación de stock de bodega para una orden de compra Disponibilidad de asiento para una reserva de pasajes d. Actividad Enviar y Recibir La recepción de un mensaje en BPMN puede modelarse como una actividad aunque exista un tipo de evento para estos fines. Si se desea que un proceso sea instanciado por una actividad de tipo recepción y de esta forma reemplazar un evento del tipo mensaje al inicio de un proceso, se debe utilizar el símbolo de tipo de carta con un círculo. El mismo principio tiene validez para las actividades del tipo envío. Este tipo de actividades son solamente técnicas y se usan para invocar interfaces asincrónicas de servicios web en colas de mensajería (en inglés: message queues), etc., por lo que no se recomienda de usarlas en modelos de negocio. e. Actividad Script Un script es un pequeño programa que puede interpretar y ejecutar directamente el sistema de workflow. El script tiene que estar escrito en el lenguaje que pueda interpretar el entorno de implementación. f. Actividad Regla de Negocio Este tipo de actividad también es nuevo a partir de BPMN 2.0 y se interpreta de tal forma que sólo está destinada para ejecutar una regla de negocio, ya sea invocándola a un sistema independiente (BRMS: Business Rule Management System) o ejecutando un motor de reglas que viene incluido en el Process Engine.

Pág. 72


9.3.2 Propiedades de actividades

A las actividades, podemos marcarlas con ciertas propiedades (marcas), tales como repetitivas (loop), múltiples (más de una instancia), o compensación. Estas marcas pueden combinarse con los tipos de actividades, convirtíendose de cierta forma en actividades complejas.

a. Loop Una actividad con la propiedad de loop (bucle) se va a repetir tantas veces hasta que se cumpla, o no se cumpla la condición especificada.

También podemos modelar la condición repetitiva con ayuda de Gateways, en combinación con Gateways o sin ellos.

Pág. 73

Asignatura: NOTACION DE PROCESOS DE NEGOCIO b. Actividad múltiple La actividad con propiedad de múltiple ejecuta en forma simultánea la actividad tantas veces como instancias existan.

c. Actividad de compensación Esta propiedad se utiliza exclusivamente en el contexto del evento intermedio de compensación y se relaciona con el evento a través del flujo de asociación y nunca a través del flujo de secuencia.

9.4 Flujos de Secuencia Los Conectores vinculan dos objetos en u n diagrama. Existen tres diferentes tipos de conectores de BPMN: a. Flujo de Secuencia Define el orden

de los objetos de flujo en

un Proceso (Actividades, Eventos y

Gateways). b. Flujo de Mensaje Define el flujo de comunicación entre dos participantes o entidad e s (p. ej., una organización y sus proveedores). El objeto de la comunicación es u n me n s aje. c. Asociaciones Se utilizan par a vincular Artefactos (d a tos e información) con otros objetos del diagrama, incluyen do objetos de flujo (Actividades, Eventos y Gateways).

Pág. 74


9.5 Actividades globales

A partir de la versión BPMN 2.0 podemos definir actividades globales, las cuales se diferencian de las actividades normales, en que las primeras pueden reutilizarse. Las actividades globales no se diferencian gráficamente de las normales. Sólo las reconocemos al ver la existencia de actividades invocables que llevan el mismo nombre que las globales, pero tienen una línea de contorno más gruesa, es decir en negrita.

9.6 Un proceso simple en BPMN

9.7 Flujo de Procesos con Gatewatay

(HITPASS, 2014) Casi ningún proceso tiene un flujo unifome. En la mayoría de los casos, las instancias recorren diferentes trayectorias, dependiendo de las condiciones y reglas que apliquen.

Pág. 75

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 9.7.1 Gateway exclusivo de datos (XOR)

La compuerta en que tenemos que tomar la decisión en BPMN se denomina Gateway. No confunda un Gateway con una Actividad. El Gateway requiere de un hecho (una variable). La actividad es la encargada de producir este hecho y disponibilizar la variable para el Gateway.

Como esta decisión la tomamos de acuerdo a la información recibida y la compuerta permite recorrer sólo una alternativa.

La posibilidad que tenemos de utilizar el XOR-Gateway como elemento de bifurcación (XOR-Split) o unión (XOR-Join) puede que al principiante lo confunda. La notación permite incluso usar el XOR-Gateway como una unión de entrada y bifurcador de salida con un sólo símbolo.

9.7.2 Gateway paralelo

Por ejemplo indicamos el tiempo promedio que demora cada actividad. La suma de los tiempos de cada una actividad nos arroja el tiempo de ciclo del proceso completo. (análisis de indicadores de tiempo de ciclo)

Pág. 76

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Podríamos pensar en paralelizar la preparación de la comida y de esta forma acelarar el proceso en general.

El paralelismo no significa que obligatoriamente las actividades tienen que ejecutarse exactamente en forma simultánea, pero pueden comenzar cuando la condición se de. Con la instancia del proceso se crea simultáneamente el token, el cual es clonado como en el caso anterior en el AND-Split. Apenas esté lista la ensalada se dirige el token a la actividad comer preparación y ejecuta la tarea, es decir la ensalada se consume sin esperar la pasta, como se muestra en la figura:

Otro caso en que la instancia «vive» el tiempo que corresponde con el tiempo de ciclo del proceso (ejemplo 45 días). A pesar que el primer token se consume luego de 30 días, el segundo token aún está activo durante 15 días más en la actividad 2.

Pág. 77

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 9.7.3 Gateway inclusivo de datos (OR)

Con un OR-Gateway podemos formular una situación que responde a las preguntas «y/o», en la cual podemos escoger uno, muchos o simplemente todos los flujos de salida (Para consumir tokens de una o más ramas de entrada (Inclusive Merge) o para propagar tokens a, al menos, una de las ramas de salida (Inclusive Desicion).

Podemos Seguir compactando el modelo, con las diferentes opciones:

Veamos las opciones: Comemos sólo pasta. Comemos sólo steaks. Comemos sólo ensalada. Comemos pasta y ensalada Comemos steak y ensalada. Comemos pasta y steaks. Comemos pasta, steaks y ensalada.

Pág. 78

Asignatura: NOTACION DE PROCESOS DE NEGOCIO El flujo por defecto

Nos protege ante situaciones indeseadas. Primero se contemplan todos los flujos salientes con sentido de negocio; sólo si ninguna de las opciones anteriores es válida se emplea el flujo por defecto.

9.7.4 Gateway complejo

Se utiliza cuando un caso de negocio no se puede representar con ningún otro Gateway. Se da en un punto del proceso donde aparecen varios caminos y solo uno de ellos es válido. Esta decisión esta basada en la información registrada en Metadata. En el ejemplo, en el momento de tomar la decisión, por cualquiera de ambas alternativas, pedimos la pizza y desechamos la otra opción.

Vamos a suponer que vamos a ejecutar cuatro actividades en forma simultánea. La quinta actividad debe ejecutarse apenas se disponga del resultado de tres actividades, independiente de algún orden correlativo. Este tipo de comportamiento de sincronización se puede representar con un Gateway complejo, agregándole si la condición en forma de un artefacto del tipo comentario.

Pág. 79


9.8 Eventos

Las tareas (actividades) cambian el estado de un objeto, bajo ciertas condiciones (Gateways).

Eventos son cosas que ocurren. Indican que al inicio, en forma intermedia o al final del proceso algo significativo ocurrió. Eventos de inicio nos indican que tipo de ocurrencias suceden para que un proceso comience. Eventos intermedios muestran un estado que el proceso ha alcanzado y que en el modelo por alguna razón lo queremos retener. No se utilizan muy a menudo, pero pueden ser muy útiles, por ejemplo si el estado representa un hito y se quiere medir el tiempo transcurrido hasta alcanzar el hito. Eventos finales indican que se logró al finalizar una trayectoria del proceso.

Los eventos de captura se les denomina en BPMN «catching events» e indican ocurrencias que vienen de afuera y a los que un proceso debe reaccionar cuando estos suceden, independiente si este tipo de eventos «gatillan» (en inglés: trigger) el inicio de un proceso o suceden durante un proceso.

Lo importante de entender es que este tipo de sucesos tienen un impacto sobre el proceso y que este debe reaccionar. Eventos de captura pueden tener el siguiente impacto sobre los procesos: Inician el proceso, el proceso o el flujo del proceso continúa, una actividad o un subproceso que se encuentra en ejecución es interrumpida o cancelada, durante la ejecución de una actividad o un subproceso, impulsa el inicio de otra actividad o subproceso

Los eventos del tipo disparador se les denomina en BPMN «throwings events» e indican eventos creados dentro del proceso. Es decir a diferencia a los eventos del tipo de captura a los cuales el proceso debe reaccionar, en este caso el mismo proceso actúa como gatillador de nuevos eventos. Eventos del tipo disparador: pueden crearse durante el proceso, o al final del proceso (eventos de término).

Para que un proceso que está en espera pueda continuar, puede hacerse necesario que ocurra un evento intermedio, como lo muestra la figura, Si la actividad 1 ha terminado, tiene que ocurrir primero el evento 1, antes que puede iniciarse la actividad 2.

En BPMN también podemos representar casos en que existe un flujo normal, pero puede ocurrir un evento inesperado que interrumpa una actividad o un subproceso. A estos eventos intermedios Pág. 80

Asignatura: NOTACION DE PROCESOS DE NEGOCIO se les llama «sobrepuestos» (en inglés: attached), ya que van superpuestos a un costado de la actividad. Primero avanza hacia la actividad 1, la cual se inicia. Si sucede el evento 1, durante la ejecución de la actividad 1, esta se interrumpe inmediatamente y el token sigue su flujo en la actividad 3 (caso de excepción). Si no sucede el evento 1, la actividad 1 se ejecuta en forma normal y el token sigue su flujo regular e inicia la actividad 2. Si sucede el evento 1, después que se haya ejecutado la actividad 1, el suceso no impacta en el proceso.

En BPMN hasta la versión 1.2 los eventos sobrepuestos (a excepción de los eventos del tipo de compensación), siempre cancelan la actividad en ejecución. Este comportamiento no siempre refleja la realidad, por lo que en la versión 2.0 se introdujo un nuevo símbolo: un evento intermedio sobrepuesto, pero del tipo «no interrupción». El token inicia la actividad 1. Si sucede el evento 1, durante la ejecución de la actividad 1, el token es clonado: La actividad 1 sigue en proceso, pero al mismo tiempo avanza el segundo token (el clonado) a la actividad 3, la cual también es iniciada y ejecutada. Este evento puede suceder incluso en forma repetitiva, y el token vuelve a clonarse hasta que la actividad 1 haya terminado. Si no sucede el evento 1, la actividad 1 se ejecuta en forma normal y el token sigue su flujo regular e inicia la actividad 2. Si sucede el evento 1, después que se haya ejecutado la actividad 1, el suceso no impacta en el proceso.

9.8.1 Evento de Mensaje

Eventos que portan información (no se restringe a ciertos portadores de información como cartas, emails o llamadas, sino a cualquier objeto que porte información: orden de compra, guía de despacho, boleta o factura.)

Pág. 81

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Ejemplo:

O también:

Otro ejemplo, el cliente nos llama haciendo un reclamo que el sitio no responde o está abajo. El operador busca el problema o verifica si existe algún error. Es posible que el cliente se haya equivocado y el problema lo tenga él, porque en algún instante se le haya caído internet. Él llama nuevamente para que no nos preocupemos. Este llamado entra al proceso como un evento de mensaje del tipo interrupción, al ocurrir todas las demás actividades se cancelan y el flujo sigue a la actividad asignada por el evento de interrupción.

9.8.2 Evento de tiempo

También llamado temporizador, se utiliza cuando una condición de tiempo ocurre. Como evento de inicio se puede utilizar para: iniciar cada ciertos intervalos un proceso, iniciar un proceso regularmente en una fecha y hora indicada, iniciar un proceso en una relación temporal con otro evento e iniciar un proceso por única vez en una fecha y hora determinada. Como evento intermedio el temporizador puede detener el proceso, hasta que: un tiempo definido se haya alcanzado, un período de tiempo haya transcurrido, se haya alcanzado un tiempo, que se encuentre en relación a otro evento.

Pág. 82


Un evento de tiempo no puede ser impulsado por un proceso, porque sobre el tiempo no tenemos influencia, razón por la cual este evento existe sólo en forma de «evento de captura».

Muy a menudo se utiliza el temporizador sobrepuesto como «timeout», tiempo máximo permitido para la ejecución de una actividad.

También se pueden utilizar temporizadores sobrepuestos que no interrumpen la actividad.

9.8.3 Evento de error

Si usted identifica los puntos donde pueden ocurrir errores, los puede interceptar utilizando este tipo de eventos. En BPMN se considera un error como un evento excepcional, razón por la cual sólo se puede modelar como evento intermedio sobrepuesto y que además requiere de un tratamiento excepcional. Como tipo disparador sólo se debe usar como evento final, indicando que el proceso ha sido cancelado por error, o bien el evento es capturado por un subproceso superior que lo lleva a un tratamiento especial.

Pág. 83


9.8.4 Evento Condicional

Un proceso puede iniciarse o continuar bajo «ciertas condiciones». La condición debe ocurrir en forma independiente del proceso. Este evento es junto al evento de tiempo el único tipo que sólo existe en forma de evento de captura.

9.8.5 Evento de señal

Tienen un cierto parecido con los de mensajes, razón por la cual en BPMN las reglas de modelamiento para ambos eventos son iguales. La única y gran diferencia es que los mensajes tienen un destino definido, por ejemplo un e-mail indica una dirección a quién se dirige y una llamada telefónica indica un número identificador, mientras que una señal es un mensaje con destino indefinido. Un anuncio en el diario, un reclame en la televisión, o un llamado de emergencia por radio son ejemplos de señales. Cualquiera persona o sistema que capte la señal puede reaccionar si es que quiere.

El ejemplo que al ver un comercial en la televisión nos abrió el apetito de probar la pizza tras el anuncio. Entonces llamamos y hacemos el pedido de la pizza (reacción a la señal), pero sólo la comemos cuando tengamos deseo de probarla (evento de condición). Luego evaluamos si nos gustó la pizza en un sitio web de gourmes. Es decir, también los comensales envían una señal (destino indefinido) al evaluar la pizza en un sitio público.

Pág. 84

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 9.8.6 Evento de término

El evento terminador luego de consumir todos los tokens activos se encarga también de finalizar la instancia del proceso. Como consecuencia este evento especial sólo debe usarse como evento final, debido a que termina todos los tokens activos del proceso, independiente de donde se encuentren.

9.8.7 Evento de conexión

Conexión o de vínculo (en inglés: link) es un evento técnico, no tiene ningún significado de negocio. El evento no tiene otra finalidad que poder dividir diagramas muy grandes, sin perder el vínculo de un flujo de secuencia.

9.8.8 Evento de compensación

Compensar en BPMN significa volver al estado inicial de una actividad. En la práctica utilizamos el evento de compensación sólo en el contexto de transacciones que tienen que ser reversadas. Un ejemplo de un proceso de una persona que desea organizar una salida el día viernes después de su jornada laboral. La persona se pone de acuerdo con su pareja después de medio día (13:00 hrs) de organizar una salida al teatro o de invitar a unos amigos a salir. En ambos casos tenemos que comprometernos a reservar las entradas el teatro o de llamar a amigos para invitarlos. Al atardecer o al llegar a la casa, puede darse la situación de estar muy cansados, cambiar de parecer y quedarnos en casa

Pág. 85

Asignatura: NOTACION DE PROCESOS DE NEGOCIO viendo televisión. Entonces tenemos que cancelar las entradas o llamar a los amigos para manifestarles que no habrá salida.

9.8.9 Evento Múltiple

Con el evento múltiple podemos incluir la captura de varios eventos alternativos con un símbolo. Si se utiliza como evento de captura, inicia o continúa el proceso, con el sólo hecho de ocurrir uno o el primero de los eventos posibles. Como evento del tipo disparador reacciona como un disparador múltiple, es decir impulsa todos los eventos contenidos.

9.8.10 Evento de Gateway exclusivo basado en eventos

En BPMN contamos con una posibilidad adicional para diseñar comportamientos especiales, como es el «evento de Gateway exclusivo basado en eventos (abreviado: Event-Gateway)». Este Gateway no reacciona ante datos sino a eventos, específicamente al primer evento que suceda. ¿Qué situaciones se pueden dar para utilizar este Event-Gateway? Para este efecto

Pág. 86

Asignatura: NOTACION DE PROCESOS DE NEGOCIO REVISAR:

1.

Evento Múltiple Paralelo

2.

Evento de Escalación

3.

Evento de Cancelación

4.

Evento de Gateway paralelo basado en eventos

9.9 Lane

Aún no hemos visto quién o quienes son los responsables de ejecutar las actividades. BPMN utiliza carriles llamados «lanes» para la asignación de responsables.

Según las reglas de BPMN, un objeto de flujo (actividad, evento, Gateway) sólo se puede posicionar dentro de un lane y no entre ellos. La solución para este escenario, sería crear la actividad tantas veces como personas participan.

Pág. 87

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 9.10 Artefactos

BPMN contiene también una categoría de elementos que sirven para una mejor explicación o visualización gráfica, pero que de ninguna forma tiene alguna influencia en la lógica de los procesos, por lo cual los «artefactos» no son interpretados por un motor de workflow.

9.11 Participantes y flujos de mensajes

Si se hace necesaria una coordinación entre participantes en un proceso de negocio, la metodología de BPMN obliga a separar los pools y la comunicación entre ellos se lleva a cabo a través de flujos de mensajes. Entonces tendríamos en el ejemplo que ilustra la figura 6.9 cuatro dirigentes, cada uno con su propio mini-proceso y su propio flujo de control. Entre ellos no pueden hacer otra cosa que intercambiar información a través de flujos de mensajes. Es posible que un proceso dependa de un mensaje externo para que pueda continuar, pero eso lo define el propio proceso (pool) dentro de su lógica.

Figura 6.9: Flujo de cuatro participantes en pools propios Fuente: [FreRueHit11]

Es posible que el analista no se sienta muy cómodo con este principio de modelamiento porque en otras técnicas de modelamiento no se interpreta así. En muchas ocasiones no es necesario Pág. 88

Asignatura: NOTACION DE PROCESOS DE NEGOCIO separar a todos los participantes para representar una determinada lógica en un proceso, eso va a depender fundamentalmente si el «dirigente» tiene el control sobre ellos. Si un pool o dirigente no tiene control sobre un participante, entonces sí tiene que obligadamente separarlo y representarlo como un pool propio, por ejemplo clientes y proveedores.

¿Por qué BPMN introdujo este principio de separar los participantes a pools propios para representar la lógica en sus diagramas? El objetivo principal que tienen los autores del BPMN en mente es la automatización de los procesos a partir de los diagramas.

9.12 Subprocesos

Un subproceso describe en su interior la lógica en detalle, pero en el diagrama del proceso superior no toma más lugar que una propia actividad. Ambos elementos, la actividad y el subproceso, pertenecen a la clase de las actividades y se representan en forma de rectángulo con esquinas redondeadas. La única característica que los diferencia es un signo más (+) en la actividad del tipo subproceso, que indica la existencia de una lógica dentro de este.

El proceso superior se inicia y nace un nuevo token. El token pasa por la actividad y llega al subproceso. Esto conlleva a que el proceso superior cree una instancia del subproceso. Dentro del subproceso se crea un nuevo token que sigue la lógica del flujo del subproceso desde el evento de inicio hasta el evento que termina el subproceso. El token del evento superior espera el arribo del token del subproceso.

Pág. 89


Tema Nº 10: Diferentes vistas de un proceso BPMN parte de la base que en un diagrama pueden representarse uno o más participantes.

Ha de tener cuidado de no confundir un participante con un rol, un departamento o usuario. Un participante es para BPMN en primer lugar un elemento lógico, cuya aplicación obedece a las siguientes reglas:

En un proceso existe un sólo participante (Este principio confunde a menudo al lector) Este participante posee el control absoluto sobre la lógica del proceso Otros participantes no pueden influenciar este proceso, en algunas ocasiones ni siquiera saben cómo está organizado El participante es por definición el responsable del proceso Si varios participantes deben interactuar con otros procesos, deben de hacerlo por medio del intercambio de información (flujo de mensaje), información que lógicamente apoya la operación del proceso Debido a estos principios, se da que cada participante tenga su propia vista sobre el proceso general, es decir diferentes perspectivas. Este hecho nos lleva a deducir que un proceso de negocio puede y por lo general tiene varios modelos de procesos, tantos procesos como participantes existan. El objeto que en BPMN representa un participante es un pool.

Pág. 90

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Tema Nº 11: Categoría de Procesos

(White 20009) Des de su descripción, BPMN ha tratado de dar soporte a tres categorías principales de Procesos:



Orquestación



Coreografía



Colaboración

Estos términos han variad o, usualmente con conflictivos significados en los distintos contextos de negocio en los que son aplicados.

11.1 Orquestación

Los modelos de orquestación tienden a implicar una perspectiva única de coordinación. Por ejemplo, representan una vista específica del negocio u organización del Proceso. Como tal, un Proceso de orquestación describe cómo una única entidad de negocio lleva a cabo las cosas.

Sin embargo, un diagrama BPMN puede contener m ás de una orquestación. En tal caso, cada orquestación aparece dentro su propio con tenedor llamado Pool.

11.2 Coreografía

Un modelo de proceso de coreografía es una definición del comporta miento esperado (una clase de

contrato

procedimientos

o protocolo)

entre

los participantes que

interactúa n . Estos participantes pueden ser roles de negocio generales (por ejemplo, un despachador) o una entidad específica de negocio (por ejemplo, FedEx como empresa de transporte).

Una coreografía describe las interacciones de los participantes. Incluye tantos caminos alternativos y paralelos, así como Sub Procesos. De esta man e r a, los objetos de flujo (Actividades, Eventos, y Gateways) de los modelos de orquestación también aplica n a los modelos de coreografía.

Pág. 91

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Los conectores entre los Pools son el Flujo de Mensajes.

11.3 Colaboración

Mientras que la coreografía muestra el conjunto ordenado (protocolo) de interacciones entre los participantes. Un a colaboración puede contener también una coreografía (cuando esté disponible en BPMN) y una o más orquestaciones. Una colaboración es cualquier diagrama BPMN que contenga dos o m ás participantes como se muestra con los Pools. Los Pools tienen Flujo de Mensajes entre ellos. Cualquiera de los Pools puede llegar a contener una orquestación (un Proceso), pero no está requerido.

Pág. 92


UNIDAD IV AUTOMATIZACIÓN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN)

Tema Nº 12: Automatización de Procesos (HITPASS, 2013) Una de las mayores novedades que trae la nueva versión 2.0 de BPMN [OMG11] es la introducción de la definición de una «semántica de ejecución» como también un «formato de serialización de XML». ¿Qué significado tienen estas expresiones? Los modelos de BPMN pueden almacenarse en un archivo de XML, pero la especificación norma como hacerlo. Existen dos tipos de esquemas de XML: Para el intercambio de modelos: El XML contiene toda la información que se necesita para exportar e importar modelos de una herramienta a otra. La definición incluye información gráfica sobre el posicionamiento de los objetos (layout). Para la ejecución de la semántica: La especificación norma cómo deben archivarse todos los detalles técnicos del proceso. La especificación norma cómo deben ser almacenados los esquemas de XML para que se pueda interpretar la sintáctica, pero también la interpretación de la semántica y el metamodelo.

Pág. 93

Asignatura: NOTACION DE PROCESOS DE NEGOCIO 12.1 Niveles de Procesos 12.1.1 Nivel 1: Modelo de Procesos Descriptivos Describe la lógica de negocio lo más compacta posible. El objetivo principal en este nivel es describir el alcance que tienen los procesos de principio a fin. Le sirve al propietario del negocio. Los principales objetivos relacionados con el primer nivel son: Definición del alcance de los procesos (Límites definidos en los términos desde/hasta ) Asignación de las responsabilidades y recursos del proceso Definición de los principales KPI’s (Key Performance Indicators: Indicadores críticos del negocio), por ejemplo tiempos de ciclo máximo por proceso Requerimientos generales que se esperan para mejorar el rendimiento de los procesos

¿Cuándo requerimos o se hace necesario modelar los procesos en el nivel descriptivo? Si tenemos que levantar por primera vez la situación actual de un proceso, si tenemos que diseñar un proceso nuevo o rediseñar uno existente.

La siguiente pregunta es si es necesario modelar la lógica de los subprocesos que se encuentran cerrados. Por lo general desistimos de ello en el nivel descriptivo, porque no es objetivo del nivel 1 conocer los detalles de la lógica de negocio.

Ejemplo: Modelo de proceso de contratación de personal con cada participante en Pool propio.

Pág. 94

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Ejemplo: Caso de modelo de colaboración utilizando Pool cerrado

12.1.2 Nivel 2: Modelo de Procesos Operacional

Es la esencia del BPMN-Framework. Este nivel abarca toda la lógica de negocio en detalle, incluyendo los casos de excepción, identificando las reglas de negocio, y la interacción en detalle con todos los participantes. El modelo operativo le sirve al usuario de negocio (Process Participants) como guía o manual de procedimiento en su trabajo diario. Al analista de proceso (Process Analyst) le sirve como input para evaluar la eficiencia del proceso y poder desarrollar propuestas de mejora. Por último, el modelo operativo constituye la base y el punto de partida para el diseño de una implementación técnica por medio de TI.

Su pregunta esencial es: ¿Cómo se trabaja y cómo podría hacerse mejor? El usuario de negocio en cambio sólo se interesa en aquellos aspectos del proceso que le conciernen a él. Su pregunta esencial es: ¿Cómo tengo que trabajar? Llegado el momento de querer implementar técnicamente el proceso, entra en juego el ingeniero de procesos (Process Engineer). El ingeniero de procesos no es parte integrante del equipo para el modelamiento en el segundo nivel, su rol activo comienza en el tercer nivel, pero él debe enterarse sobre los requerimientos funcionales que deberán implementarse. Su pregunta esencial en este nivel es: ¿Qué debe cumplir el sistema de TI? Uno de los desafíos principales en el nivel operativo es de coordinar satisfactoriamente estos tres roles principales contestando a cada una de sus preguntas. Nada de sencillo, pero si lo logra, obtendrá una serie de beneficios: El modelo operativo corresponde en su lógica principal completamente a la lógica que será implementada técnicamente. Logramos un buen alineamiento entre la capa de negocio y la capa de TI. La documentación elaborada no se deja de lado y se empieza de nuevo a modelar como sucede en muchos proyectos.

Pág. 95

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Los diagramas de proceso tienen que estar en nivel 2 sintácticamente correctos igual que en el nivel 1, pero adicionalmente al nivel 1 su semántica debe ser consistente. En el nivel 2 se describe como realmente se trabaja, razón por la cual no se pueden aceptar contradicciones o faltas formales, como lo admitimos en el nivel 1, pero tampoco debe llevarse a un grado de complejidad tan alto que se torne inentendible: «A cada rol le asignamos una vista propia del proceso completo».

Ejemplo: Diagrama de colaboración para proceso de licitación de cargo

Preparación de la Automatización de los Procesos La descripción de la lógica de negocio es sólo uno de los objetivos en el nivel operativo de nuestro framework de BPMN. El asunto es el traspaso o el mapeo sin variaciones de aquella parte de la lógica de negocio que se quiere implementar por un sistema de workflow, es decir el traspaso del nivel 2 (diseño lógico) al nivel 3 (diseño técnico). Pág. 96

Asignatura: NOTACION DE PROCESOS DE NEGOCIO Ejemplo: Representación del proceso de licitación en un sistema de workflow

Otros requerimientos

Pág. 97


12.1.3 Nivel 3: Modelo de Procesos Técnico

Es finalmente automatizar los procesos por medio de software. Modelos técnicos bien diseñados pueden ejecutarse directamente en el nivel 3 con un Process Engine. Dicho de otra forma, el modelo técnico (diagrama técnico) es sinónimo de código fuente para el Process Engine, lo que tiene una importante implicancia: Los modelos tienen que estar sintácticamente y semánticamente correctos y lo suficientemente detallados como para ejecutarse. Lo que en el modelo no está formalmente claro, no lo puede interpretar el Process Engine.

El procedimiento incluye por lo general los siguientes pasos: 1. Aclarar y validar el modelo de proceso «to be» en el nivel 2. Este punto lo tratamos extensamente en el capítulo anterior. 2. Decisión sobre una plataforma y arquitectura tecnológica (Nota: Normalmente la definición y disposición de una plataforma tecnológica debería ser un proyecto separado de informática y ser un input dado para un proyecto de BPM). 3. Si se utiliza una Engine BPMN 2.0, sólo debería ampliarse el modelo de procesos en aspectos técnicos. Si se utiliza otro tipo de modelo técnico (BPEL, XPDL u otro) se hará necesario incluir una nueva capa y realizar un mapping entre el nivel 2 y el nivel 3. 4. Rediseño iterativo del modelo del nivel operativo en caso que surgan problemas que no permitan implementar el modelo de negocio. 5. Testear y ejecutar marcha blanca de acuerdo a los métodos tradicionales del ciclo de desarrollo de software.

Forma de trabajo de un Process Engine Pág. 98


12.2 BPMN comparado con otras notaciones

(HITPASS, 2013) Muchos lectores que se interesan por BPMN conocen algunas otras notaciones para modelar procesos. Seguramente también se preguntarán si tiene sentido cambiarse a BPMN y qué aspectos hay que considerar en esta nueva técnica de modelamiento. Según la región donde esté radicado el lector y la escuela por la que ha pasado, habrá conocido o aplicado diferentes notaciones.

Cuando se empezó a desarrollar BPMN se revisaron muchas otras notaciones de modelamiento. Los miembros de la OMG aportaron con sus conocimientos y experiencias con muchas notaciones existentes, de las cuales algunas de ellas influyeron en el desarrollo del estándar, como por ejemplo UML Activity Diagram, IDEF, ActivityDecision Flow (ADF) Diagram, y Event-Process Chains (EPCs)[ OMG11]. Otras notaciones más orientadas al negocio se revisaron para extraer ideas en la parte conceptual del modelamiento de procesos de negocio, como EPC, IDEF y UML Activity Diagram.

Pág. 99


REFERENCIAS BIBLIOGRÁFICAS Y DIRECCIONES ELECTRÓNICAS

Básica HITPASS, Bernard, BPM: Business Process Management Fundamentos y Conceptos de Implementación, Segunda Edición. Chile: Editorial BHH Ltda, 2013.

Complementaria BERND RUKER, Jakob. Manual de Referencia y Guía Práctica BPMN 2,0. Cuarte Educion, Chile: Editorial Dimacofi, 2014.Joyanes Aguilar, Luis. Estructura de Datos. 1ra. ed. España: McGraw-Hill; 2000. BPMN 2.0, Bizagi Suite [en línea]. [Consulta: 20 de junio de 2015]. Disponible en Web: https://www.bizagi.com/docs/BPMNbyExampleSPA.pdf Guía especificación BPMN [en línea], [Consulta: 03 de junio de 2015].Disponible en Web: http://www.bpmn.org

Pág. 100

Texto Universitario NOTACION de PROCESOS

Recommend Documents