Prévia do material em texto
Notación de Procesos de Negocio Manual Autoformativo Interactivo María Gabriela Camborda Zamudio Notación de Procesos de Negocio. Manual Autoformativo Interactivo María Gabriela Camborda Zamudio Primera edición Huancayo, febrero 2017 De esta edición © Universidad Continental Av. San Carlos 1980, Huancayo-Perú Teléfono: (51 64) 481-430 anexo 7361 Correo electrónico: recursosucvirtual@continental.edu.pe http://www.continental.edu.pe/ Versión e-book Disponible en http://repositorio.continental.edu.pe/ ISBN electrónico N.° 978-612-4196-38-6 Dirección: Emma Barrios Ipenza Edición: Eliana Gallardo Echenique Asistente de edición: Andrid Poma Acevedo Asesoría didáctica: Luisa Aquije de Lozano Diseño y diagramación: Francisco Rosales Guerra Todos los derechos reservados. Cada autor es responsable del contenido de su propio texto. Este manual autoformativo no puede ser reproducido, total ni parcialmente, ni registrado en o transmitido por un sistema de recuperación de información, en ninguna forma ni por ningún medio sea mecánico, foto- químico, electrónico, magnético, electro-óptico, por fotocopia, o cualquier otro medio, sin el permiso previo de la Universidad Continental. CAMBORDA ZAMUDIO, María Gabriela Notación de procesos de negocio: manual autoformativo interactivo / María Gabriela Camborda Zamudio. -- Huancayo: Universidad Continental, 2017 ISBN electrónico 978-612-4196-38-6 1. Gestión de empresas 2. Reingeniería 3. Reingeniería de procesos 658.40352 (SCDD) Datos de catalogación del Cendoc Datos de catalogación bibliográfica mailto:recursosucvirtual@continental.edu.pe http://www.continental.edu.pe http://repositorio.continental.edu.pe Índice inTROdUcciÓn 7 diAGRAMA de PReSenTAciÓn de LA ASiGnATURA 8 ReSULTAdO de APRendiZAJe: 8 UnidAdeS didAcTicAS 8 TieMPO MÍniMO de eSTUdiO 8 UNIDAD I inTROdUcciÓn Y deFiniciÓn deL BUSSineSS PROceSS MAnGMenT(BPM) 9 diAGRAMA de PReSenTAciÓn de LA UnidAd i 9 TeMA n° 1: FUndAMenTOS deL BPM 12 1. inTROdUcciÓn AL BPM. HiSTORiA Y evOLUciÓn 12 2.-cOncePTOS BáSicOS SOBRe (PROceSO, GeSTiÓn, BPM) 16 videOS 23 AcTividAd FORMATivA n° 1 25 videOS 26 LecTURA SeLecciOnAdA nº 1: 28 AcTividAd FORMATivA n° 2 29 TeMA n° 2: ORGAniZAciÓn Y eSTRUcTURA deL BPM 30 1. ORGAniZAciÓn Y eSTRUcTURA deL BPM. 30 videOS 53 LecTURA SeLecciOnAdA nº 2: 54 AcTividAd FORMATivA n° 3 54 videOS 55 RÚBRicA PARA evALUAR Un cUAdRO cOMPARATivO 56 AcTividAd FORMATivA n° 4 57 GLOSARiO de LA UnidAd i 58 BiBLiOGRAFÍA de LA UnidAd i 59 AUTOevALUAciÓn de LA UnidAd i 60 UNIDAD II ARQUTecTURA eMPReSARiAL en eL cOnTeXTO BPM 63 diAGRAMA de PReSenTAciÓn de LA UnidAd ii 63 TeMA n° 1: inTROdUcciÓn A LA ARQUiTecTURA eMPReSARiAL 66 1 HiSTORiA Y evOLUciÓn - cOncePTOS BáSicOS 66 2 cOncePTOS BáSicOS de ARQUiTecTURA eMPReSARiAL (Ae) 67 3 áReAS de UnA ARQUiTecTURA eMPReSARiAL 69 videOS 71 LecTURA SeLecciOnAdA nº 1: 71 AcTividAd FORMATivA n° 1 72 RÚBRicA PARA evALUAR Un cUAdRO cOMPARATivO 73 AcTividAd FORMATivA n° 2 74 TeMA n° 2: eSTándAReS de GeSTiÓn eMPReSARiAL 75 1 ReLAciÓn Ae & BPM & SOA 75 2 FRAMewORkS de ARQUiTecTURA eMPReSARiAL 78 videOS 87 LecTURA SeLecciOnAdA nº 2: 87 AcTividAd FORMATivA n° 3 88 RÚBRicA de evALUAciÓn deL inFORMe eScRiTO 89 AcTividAd FORMATivA n° 4 90 GLOSARiO de LA UnidAd ii 91 BiBLiOGRAFÍA de LA UnidAd ii 92 AUTOevALUAciÓn de LA UnidAd ii 93 UNIDAD III BUSineSS PROceSS MAnAGeMenT (BPM) Y eL MOdeLAdO BUSineSS PROceSS MOdeL And nOTATiOn (BPMn) 97 diAGRAMA de PReSenTAciÓn de LA UnidAd iii 97 TeMA n° 1: BUSSineSS PROceSS MOdeL Y LA nOTAciÓn BPMn 99 LecTURA SeLecciOnAdA nº 1: 129 AcTividAd FORMATivA n° 1 130 LecTURA SeLecciOnAdA nº 2: 130 AcTividAd FORMATivA n° 2 131 RÚBRicA PARA eL MOdeLO deL PROceSO 132 GLOSARiO de LA UnidAd iii 133 BiBLiOGRAFÍA de LA UnidAd iii 134 AUTOevALUAciÓn de LA UnidAd iii 135 UNIDAD IV AUTOMATiZAciÓn de PROceSOS cOn BPMn. 139 diAGRAMA de PReSenTAciÓn de LA UnidAd iv 139 TeMA n° 1: deSARROLLO de cASOS 142 1. AUTOMATiZAciÓn de PROceSOS cOn PBMn 2.0 142 2. BPMn cOMPARAdO cOn OTRAS nOTAciOneS 163 videOS 170 AcTividAd FORMATivA n° 1 172 RÚBRicA cASO de MOdeLO 173 AcTividAd FORMATivA nº 2 174 RÚBRicA cASO de MOdeLO 175 GLOSARiO de LA UnidAd iv 176 AUTOevALUAciÓn nº 4 177 AneXO n°1 180 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 7 inTROdUcciÓn n uestra era actual de la globalización se carac-teriza por un entorno cada vez más competi-tivo, ha inducido a que las organizaciones se replanten los conceptos de calidad. Actualmente los modelos de excelencia basados en los conceptos de gestión por calidad total se utilizan para introducir la mejora continua y la innovación, para mejorar el des- empeño de la organización y en especial los resulta- dos económicos, a través de sus procesos. Introducir procesos en las organizaciones que les permita entrar en un círcu¬lo vir-tuoso de mejora continua para dar cumplimiento a estas exigencias a tra¬vés del tiempo, son los desafíos actuales a los que se encuentran sometidas las organiza-ciones La asignatura de Notación de procesos proporciona conocimiento sobre los funda-mentos de Business process management, a través de un trasfondo his¬- tórico para comprender mejor la evolución de la inge- niería de procesos. Asimismo se considera los con- ceptos de implementación, para conocer y entender las definicio¬nes que faci-litan comprender el alcan- ce de BPM, la segunda parte integra a los modelos de pro-cedimiento el apoyo tecnológico en cada una de las capas del BPM y finalmente se muestra la no- tación BPMN con el objetivo de aplicarlo a casos de negocios. Mg. Ing. MARIA GABRIELA CAMBORDA ZAMUDIO CIP. N°91636 8 diAGRAMA de PReSenTAciÓn de LA ASiGnATURA ReSULTAdO de APRendiZAJe: Al finalizar la asignatura, el estudiante será capaz de elaborar modelos de diversos procesos de negocio, utilizan- do los principios y elementos del 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. UnidAdeS didAcTicAS UNIDAD I UNIDAD II UNIDAD III UNIDAD IV INTRODUCCION Y DEFINICION DEL BPM ARQUTECTURA EMPRESARIAL EN EL CONTEXTO BPM MODELADO DE PROCESOS CON LA NOTACION BPMN AUTOMATIZACIÓN DE PROCESOS CON BPMN El estudiante será capaz de identificar los conceptos y principios básicos del BPM, de forma clara y precisa Diferenciar los diferentes tipos de estándares existentes para la gestión empresarial basada en procesos, de forma precisa y contextualizándolos con situa- ciones de la reali-dad. Diseñar un modelo de proceso, utili-zando los elementos de notación de BPMN, para un caso de estudio de la realidad. Elabora un modelo de proceso con BPMN, utilizando una herramienta de simulación y automatización. TieMPO MÍniMO de eSTUdiO UNIDAD I UNIDAD II UNIDAD III UNIDAD IV 1ra. Semana y 2da. Semana 16 Horas 3ra. Semana y 4ta. Semana 16 Horas 5ta. Semana y 6ta. Semana 16 Horas 7ma. Semana y 8va. Semana 16 Horas NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 9 UNIDAD I inTROdUcciÓn Y deFiniciÓn deL BUSSineSS PROceSS MAnGMenT(BPM) diAGRAMA de PReSenTAciÓn de LA UnidAd i Al finalizar la unidad, el estudiante será capaz de identificar los conceptos y principios básicos del BPM, de forma clara y precisa. 10 CONTENIDOS ACTIVIDADES FORMATIVAS (hAbILIDADes y AcTITUDes) SISTEMA DE EVALUACIÓN (TécNIcAs y cRITeRIOs) Tema N° 1 : Fundamentos del BPM 1 Introducción al Business Process managementBPM. Historia y evolución. 2 Conceptos básicos sobre (Proceso, gestión, BPM) Tema N° 2: Organización y Estructura del BPM 1 Organización y Estruc-tura del BPM. • Reconoce los conceptos básicos del (BPM) su histo-ria y evolución . Desarro-lla una prueba objetiva sobre el tema. • Lee y analiza “El cuento de la eficacia y eficiencia”y prepara un comentario crítico. • Identifica conceptos de gestión y la organización del BPM. Elabora un cuadro comparativo entre las técnicas de mejora continua. • Describir que es un Proce-so y desarrolla una prueba mixta sobre el tema Procedimientos e indicadores de evaluación permanente: • Entrega puntual del trabajo realizado. • Calidad, coherencia y Pertinencia de contenidos desarrollados: Individual o equipo. • Prueba teórico-práctica individual. • Actividades desarrolladas en sesiones Tutorizadas. Criterios de evaluación para la prueba objetiva y prueba mixta: • Conceptos y terminología • Conocimiento de las rela-ciones entre conceptos • Desarrollo del tema con evidencias y ejemplos. NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 11 RECURSOS: Videos: Tema Nº 1: • Video Introducción al BPM (Resumen conceptos previos) https://www.youtube.com/watch?v=RRy_73ivcms • Video Qué es un proceso https://www.youtube.com/watch?v=boh_PBEyLEM • Videos Gestión por procesos 1 de 3 (Resumen conceptos previos) haz un clic en el siguiente link ) https://www.youtube.com/watch?v=aA07Lu5h3js&index=2&list=PLcdm03s_hqxkTvx6iife8mXf2_8VwVKpG • Video Introducción Gestión por procesos 2 de 3 https://www.youtube.com/watch?v=lPkYqX-ATvo&list=PLcdm03s_hqxkTvx6iife8mXf2_8VwVKpG&index=1 • Video Introducción Gestión por procesos 3 de 3 https://www.youtube.com/watch?v=IiNpbLjaqjQ&list=PLcdm03s_hqxkTvx6iife8mXf2_8VwVKpG&index=3 Tema Nº 2: • Vídeo, Qué es un proceso? https://www.youtube.com/watch?v=boh_PBEyLEM • vídeo: Proceso Mejora continua https://www.youtube.com/watch?v=OO9jtaADrpY DIAPOSITIVAS ELABORADAS POR EL DOCENTE: Lectura complementaria: Lectura Seleccionada Nº 1 El cuento de la eficacia y la eficiencia Lectura seleccionada N°2 Modelo de éxito Toyota- Claves de éxito INsTRUMeNTO De eVALUAcIóN Rúbrica para evaluar el organizador del conocimiento Prueba objetiva N°1 Prueba Mixta N° 1 bIbLIOgRAFíA (básIcA y cOMpLeMeNTARIA) BASICA HITPASS, Bernard, BPM: Business Process Management Fundamen-tos 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. RecURsOs eDUcATIVOs DIgITALes Qué es un BPM [en línea]. [Consulta: 03 de junio de 2015] Disponible en Web: http://downloads.tuxpuc.pucp.edu.pe/linuxweek2012/03_Miercoles/01_Fernando-Espinoza. pdf U N id a d i t eM a N ° 1 12 TeMA n° 1: FUndAMenTOS deL BPM Apreciados estudiantes actualmente las empresas necesitan constantemente adaptar y mejorar sus procesos, pero frecuentemente están frenadas por aplicaciones y sistemas que no están preparados para explotar nue- vas oportunidades y adaptarse a los cambios de forma ágil. El BPM, con sus enfoques evolucionados y sus tecnologías punta, ha emergido como el elemento clave para proveer a las organizaciones de la “Agilidad” y “Flexibilidad” necesaria para responder de forma rápida a los nuevos cambios y oportunidades de mercado, es por ello que es transcendental este primer tema donde se les brinda un enfoque sobre el Business process ma- nagement, que nos servirán para entender como esta nueva forma de gestionar actividades en una organización se ha convertido en una tendencia que apunta a la mejora continua. 1. inTROdUcciÓn AL BPM. HiSTORiA Y evOLUciÓn 1.1 introducción Actualmente La capacidad que tienen las organizaciones de adaptar sus ofertas de bienes y servicios es parte fundamental del nuevo concepto de valor que solicitan los clientes. Los productos en sí mismos ya no son lo suficientemente atractivos porque generalmente existe una sobre oferta y el elemento diferenciador son so- bre todo los servicios alrededor de estos productos. Estos desafíos incluyen el cumplimiento de regulaciones internas, externas e internacionales enfocadas en el control de calidad (trazabilidad), prevención del fraude y el cuidado del medio ambiente entre otros, pero aún hay mayores desafíos. Nuestra era actual de la globalización se caracteriza por un entorno cada vez más competitivo, ha inducido a que las organizaciones se replanteen los conceptos de calidad. Actualmente los modelos de excelencia basados en los conceptos de gestión por calidad total se utilizan para introducir la mejora continua y la innovación, para mejorar el desempeño de la organización y en especial los resultados económicos, a través de sus procesos. (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 auto- matización y operación de los procesos implícitamente con TI. El concepto de BPM es incluso más amplio, pero va a depender cuales 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 en- cuentran 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. Cuando hablamos de objetivos de negocio podemos mencionar a: (HITPASS, 2013). A pesar de que los objetivos son claros, lograrlos y dar cumplimiento a ellos no es materia sencilla. El concepto de creación de valor para el cliente está relacionado con los atributos calidad, tiempo y costos. ¿Los productos y servicios tienen la calidad exigida por el cliente?, ¿cumplen con los tiempos espera- dos?, ¿el costo es razonable? ¿Cumplen con las regulaciones exigidas? La mayoría de las organizaciones hoy en día no se esfuerzan en dar algún grado de cumplimiento a estas altas exigencias que demandan los ciudadanos y mercados globalizados. Lograr o mejorar la «agilidad de negocio» en una organización. El concepto de agilidad de negocio se entiende como la capacidad que tiene una organización de adaptarse a los cambios del entorno a través de los cambios U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 13 en sus procesos integrados. Lograr mayor «eficacia». El concepto de eficacia se entiende como la capacidad que tiene una organización para lograr en mayor o menor medida los objetivos estratégicos o de negocio. Mejorar los niveles de «eficiencia». Eficiencia es la relación entre los resultados obtenidos y los recursos utili- zados, es decir el grado de productividad de un resultado. El término eficiencia está relacionado con todos los indicadores de productividad en cuanto a calidad, costos y tiempos. Hoy en día, no basta que una organización sea sólo eficiente como lo podría haber sido en el pasado, porque si no es capaz de adaptarse ante los frecuentes cambios impulsados por la globalización no es eficaz, dicho de otra forma no logra cumplir con los objetivos en el tiempo y calidad exigidos por los mercados. Sobre todo la agilidad de negocio ha cobrado mayor importancia en nuestros tiempos de la globalización. La empresa que pueda adap- tarse 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. 1.2 Historia y evolución 1.2.1 La ingeniería de procesos nace con Frederick Taylor (HITPASS, 2013) La idea que las actividades (el trabajo) se pueden describir comoun 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 co- nocimientos 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: «Su método de investigación científica buscaba superar la improvisación generalizada como forma de trabajo, no contratando a las personas más extraordinarias, sino que trabajando con personas comunes a quienes se las preparaba en la forma científica de hacer el trabajo. Con esto lograba típicamente incrementos de varias veces en la productividad, en un tipo de cambio que hoy llamaríamos “rediseño de procesos”». Podemos resumir que el objetivo que perseguía Taylor al reunir hechos y mediciones era proporcionar un funda- mento científico para diseñar y mejorar los procesos. Con estos fundamentos pretendía terminar con la impro- visación que predominaban en aquella época. En vez de hacer que cada trabajador hiciera la tarea a su manera, U N id a d i t eM a N ° 1 14 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. 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 me- jorar 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 organiza- cionales 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 mer- cados 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 eficien- tes en sus procesos de negocios. 1.2.3 La reingeniería de procesos como precursor de BPM (HITPASS, 2013) El 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 espec- taculares a corto plazo. La reingeniería de procesos se basa y apoya fuertemente en la incorporación de tecno- logí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 per- sonal. 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 U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 15 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 es- perada en los procesos de negocios, estaban diseñados para mejorar la eficiencia administrativa. En este sentido ayudaron a ordenar las funcionalidades e integrar sin redundancia los datos corporativos, pero los procesos de negocios están sobre los sistemas o aplicaciones. 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). Ilustración 1 Evolución de la Ingeniería de Procesos hacia el BPM Fuente: HITPASS, 2013 Desde principios del siglo XX, caracterizado por el comienzo dela economía moderna y la industrialización, y hasta la década de los 70, la economía mundial encuentra su apogeo aplicando los principios de especialización de la escuela de Taylor, logrando grandes capacidades de producción y economías de escala. Todo lo que se producía encontraba su demanda (mercado de la oferta). A partir de los años 80 se saturan los mercados y la tijera se abre; existe mayor producción que demanda. Las empresas centran sus esfuerzos en mejorar el grado de competitividad mejorando la calidad de sus productos. Aparecen entonces enfoques tendientes a mejorar la calidad de los productos como Six Sigma y finalmente TQM (Total Quality Management). Competir por calidad se vuelve tan importante que la gestión corporativa se concentra en los indicadores de calidad (Gestión por Calidad Total = TQM). Pero optar por calidad total bajo los principios Taylorianos tiene un precio muy alto (la burocracia aumenta), que los clientes por lo general no están dispuestos a pagar. La industria asiática, en su tiempo liderada por Japón, comprende esta debilidad sistémica de la organización de la industria de los países occidentales y desarrollan a través del tiempo conceptos de mejora continua centrados en los procesos con bajo grado de jerar- quización y alta participación en las decisiones de sus empleados. Estos conceptos se siguieron perfeccionando y se conocieron como Toyota Production System (TPS), KAIZEN y Lean Management. Algunas de las técnicas de mejora continua se presentarán en la sección 2.9. La eficiencia de la industria asiática provoca a principio de los años 90 un shock en los mercados industrializados occidentales y amenaza a muchos sectores con peligro a desaparecer, de tal forma que las economías occidentales entran en una prolongada recesión. La respuesta a esta amenaza la encontramos con la reingeniería de procesos (BPR , Business Process Reengineering), que en su esencia introduce dos conceptos fundamentales que prevalecen hasta hoy en día, los procesos de negocio y el concepto de valor para los clientes. Pero la reingeniería debido a su enfoque radical no fue fácil de aplicar y muchos proyectos fracasaron. En la dé- cada de los 90 la industria occidental se centra en mejorar la administración de los recursos empresariales. Así U N id a d i t eM a N ° 1 16 aparecen soluciones verticales altamente especializadas como los ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) y BSC (Balanced Scorecard). A partir del año 2000 el tema de gestión por procesos de negocio empieza lentamente a cobrar importancia en círculos profesionales y académicos y a partir de los años 2005 y 2006 se instala definitivamente como una disciplina de gestión integrada basada en procesos de negocio. 2.-cOncePTOS BáSicOS SOBRe (PROceSO, GeSTiÓn, BPM) 2.1 ¿Qué es un 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, impulsa- das 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 activi- dades en un proceso. Las actividades en un proceso están encadenadas a través de una secuencia lógica que determinan en su con- junto las condiciones del negocio. Estos elementos básicos describen en su conjunto los procesos y están contenidos en la mayoría de las nota- ciones 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. 2.1.1. ¿Qué es un 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 U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 17 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 represen- taciones 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 respon- der 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 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, produc- ción, bodega, venta, etc. Ningún cliente externo va a gatillar un proceso en el área de abastecimiento y los pro- cesos 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 abstrac- ción, y justamente éstos no son los procesos de negocio. ¿Cómo se pueden identificar entonces los procesos de negocio? Para estos efectos se recomiendarealizar un análisis del contexto y hacer un listado de todos los eventos inicia- dos 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 Hipote- cas, 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 prin- cipio de finalidad, que sería la compra del pasaje. Ingreso de un nuevo empleado al sistema de RRHH U N id a d i t eM a N ° 1 18 • 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» El lector también 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 Ilustración.2 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. Ilustración 2. Estructura de Cadena de Valor según Porter Fuente: HITPASS, 2013 La Ilustración.3 muestra la transversalidad de los procesos de negocio que son impulsados por clientes y cuyos resultados tienen que volver a ellos. U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 19 Ilustración 3. 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). 2.2.- ¿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é esta- do 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 debi- dos 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. La Ilustración 4 muestra esta diferencia: Gestión por procesos significa incluir los procesos de planificación y alineamiento a la gestión de procesos. U N id a d i t eM a N ° 1 20 Ilustración 4. Diferencias entre Gestión “de” y “por” procesos Fuente: HITPASS, 2013 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 ha- blamos de «gestión por procesos» y en su definición más amplia en inglés de Business Process Management (BPM). 2.3.-Gestión tradicional sin BPM Para conceptualizar y entender la diferencia entre gestión de y por procesos es importante realizar una retros- pectiva, 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 transversa- les 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. U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 21 Ilustración 5. Gestión tradicional sin BPM Fuente: HITPASS, 2013 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 estan- darizado 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. 2.4. Business Process Management (BPM) Es una metodología corporativa y disciplina de gestión, cuyo objetivo es mejorar el desempeño (eficiencia y efi- cacia) 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 deuna 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, aplica- tivos, eventos de negocio y organizaciones. BPM se puede relacionar con otras disciplinas de mejora de procesos como Six Sigma. Los procesos de nego- cio deberían estar documentados (actualizados), para ayudar a entender a la organización que están haciendo a través de su negocio. U N id a d i t eM a N ° 1 22 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 organizacio- nes. 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 pro- cesos de negocio.» Finalmente Jeston y Nelis (John Jeston & Johan Nelis, 2008) concluyen, BPM es: Más que sólo un software, 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 implemen- tación y ejecución de los procesos, los cuales requieren ser analizados y mejorados. 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 Conti- nua 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 Profesio- nales 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, di- señ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écni- cas 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 defini- U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 23 ció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. videOS Video 01: Breve evolución del BPM (Business Process Management). Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: BPM (Business Process Management) por Jose Ramon Pais Curto URL: https://www.youtube.com/watch?v=Wfd4g4xsdQQ Duración: 9:02 min Autor(a): José Ramón Pais Curto Año: Publicado el 9 abr. 2013 Reseña: Recorrido histórico de las diferentes teorías de mana- gement y la evolución de las tecnologías de la información hasta llegar a BPM. Licencia: YouTube estándar Video 02: Entendiendo el papel de la Reingeniería Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: La Reingeniería URL: https://www.youtube.com/watch?v=WkVXfBY8PgA Duración: 9:58 min Autor(a): Carolina Piñango Año: Publicado el 21 mar. 2013 Reseña: La Reingeniería es reinventar o rediseñar los procesos de una empresa de una manera radical. Licencia: YouTube estándar Video 03: Comprendiendo la idea de proceso Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: ¿Qué es un proceso? [Abiztar] URL: https://www.youtube.com/watch?v=PDl8z896s7g Duración: 9:58 min Autor(a): Abiztar Año: Publicado el 29 sept. 2014 Reseña: Ambientes de aprendizaje en PMP, CAPM, UML, BPMN, SCRUM. Licencia: YouTube estándar U N id a d i t eM a N ° 1 24 Video 04: Fundamentos de la Gestión por procesos de negocio Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Gestión por procesos de negocio (BPM) - Openclass UNIR URL: https://www.youtube.com/watch?v=hNxdbLJ6RPc Duración: 6:54 min Autor(a): Abiztar Año: Publicado el 29 sept. 2014 Reseña: Ambientes de aprendizaje en PMP, CAPM, UML, BPMN, SCRUM. Licencia: YouTube estándar Video 05: Fundamentos del BPM (Business Process Management). Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: BPM (Business Process Management) por Jose Ramon Pais Curto URL: https://www.youtube.com/watch?v=Wfd4g4xsdQQ Duración: 6:11 min Autor(a): José Ramón Pais Curto Año: Publicado el 9 abr. 2013 Reseña: Se presentan conceptos importantes como la orienta- ción a procesos, se describe el modelado de procesos en BPMN (Business Process Modeling Notation). Licencia: YouTube estándar U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 25 AcTividAd FORMATivA n° 1 Desarrolla una prueba objetiva sobre sobre la historia, evolución y conceptos básicos de business pro- cess management (BPM). inSTRUcciOneS 1. Lee y analiza los contenidos referidos los fundamentos y conceptos básicos de Business Process Ma- nagement(BPM). 2. Complementa tu estudio, visualizando los videos: Video Introducción Gestión por procesos 1 de 3 https://www.youtube.com/watch?v=aA07Lu5h3js&index=2&list=PLcdm03s_hqxkTvx6iife8mXf2_8Vw- VKpG Video Introducción Gestión por procesos 2 de 3 https://www.youtube.com/watch?v=lPkYqX-ATvo&list=PLcdm03s_hqxkTvx6iife8mXf2_8VwVKpG&in- dex=1 Video Introducción Gestión por procesos 3 de 3 https://www.youtube.com/watch?v=IiNpbLjaqjQ&list=PLcdm03s_hqxkTvx6iife8mXf2_8VwVKpG&in-dex=3 3. Lee las preguntas detenidamente 4. Selecciona la aternativa que consideres correcta. SUGERENCIA: Las respuestas a las siguientes preguntas de la prueba objetiva N°1 le permitirán verificar su aprendizaje de esta unidad. Le recomiendo que las resuelva cuidadosamente y envíe sus respuestas al aula virtual U N id a d i t eM a N ° 1 26 videOS Video Actividad 01A : Introducción Gestión por procesos 1 de 3 Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Gestión por Procesos, parte 1 de 3 URL: https://www.youtube.com/watch?v=aA07Lu5h3js Duración: 7:03 min Autor(a): Euskalit Kudeaketa Aurreratua Año: Actualizado el 28 sept. 2009 Reseña: Principios básicos de la gestión por procesos y la meto- dología de implantación. Licencia: YouTube estándar Video Actividad 01B : Introducción Gestión por Proce- sos, parte 2 de 3 Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Introducción Gestión por Procesos, parte 2 de 3 URL: https://www.youtube.com/watch?v=lPkYqX-ATvo Duración: 7:32 min Autor(a): Euskalit Kudeaketa Aurreratua Año: Actualizado el 28 sept. 2009 Reseña: Principios básicos de la gestión por procesos y la meto- dología de implantación. Licencia: YouTube estándar Video Actividad 01C : Introducción Gestión por Proce- sos, parte 3 de 3 Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Introducción Gestión por Procesos, parte 3 de 3 URL: https://www.youtube.com/watch?v=IiNpbLjaqjQ Duración: 3:08 min Autor(a): Euskalit Kudeaketa Aurreratua Año: Actualizado el 28 sept. 2009 Reseña: Principios básicos de la gestión por procesos y la meto- dología de implantación. Licencia: YouTube estándar U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 27 Video Actividad 02 : Formula 1 Pit Stops 1950 & Today Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Formula 1 Pit Stops 1950 & Today URL: https://www.youtube.com/watch?v=RRy_73ivcms Duración: 2:03 min Autor(a): CpatainCanuck Año: Publicado el 12 abr. 2014 Reseña: Observe how the art of the Pit Stop has evolved since 1950. Licencia: YouTube estándar U N id a d i t eM a N ° 1 28 LecTURA SeLecciOnAdA nº 1: eL cUeNto de La eFicieNcia Y La eFicacia EL CUENTO DE LA EFICIENCIA Y LA EFICACIA H abía una vez 2 hermanos que tenían nego-cios muy parecidos, que habían heredado de su padre. El consultor, que trabajaba para los dos, les sugirió a primeros de año, que deberían ha- cer un esfuerzo en la comunicación con el cliente, dado que en el sector estaban entrando empresas de bajo coste que les podían quitar cuota de mercado, si no lo hacían. El hermano mayor, que acababa de hacer un curso de eficiencia y gestión del tiempo, le envió un correo electrónico a su secretaria pidiéndole que le prepa- rara un modelo de correo electrónico, que pareciera muy personalizado y una lista de distribución de to- dos los empleados de la empresa, para notificarles, en un mismo acto, que a partir de ahora la comuni- cación con el cliente era lo más importante. Mientras tanto él dedicó su tiempo a preparar la estrategia de captación de un posible nuevo cliente. La secretaria, que era muy eficaz, hizo un modelo perfecto, que una vez revisado por su jefe, mando a todos los emplea- dos y haciendo el seguimiento correspondiente para confirmar que todos lo habían leído. El hermano pequeño, que acababa de ir a un taller de comunicación eficaz, escucho que según parece las palabras solo representan el 7% de la comunica- ción siendo el restante 93% comunicación no verbal (tono de voz y signos corporales). Le pidió a su secre- taria, que también era muy eficaz, que preparara un pequeño evento, en el que debían participar todos los empleados, para un mediodía de la próxima semana y que cancelara todas sus visitas durante dos días. A continuación fue a saludar uno por uno a sus emplea- dos y a recordarles que era muy importante asistir al evento. Estuvo dos días preparando personalmente el discurso y el día del evento, antes de la comida, leyó su discurso en el que les decía, que en el sec- tor estaban entrando empresas de bajo coste que les podían quitar cuota de mercado, si no hacían un es- fuerzo en la comunicación con el cliente y que sabía que podía confiar en que ellos harían todo lo posible. Fuente: Recuperado de http://www.automatizar.org/2012/01/top-5-de-las-tendencias-de.html U N id a d i teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 29 AcTividAd FORMATivA n° 2 Lee y analiza la lectura N° 1“El cuento de la eficacia y eficiencia”. Complementa la información observan- do el vídeo “Formula 1 Pit Stops 1950l” y prepara un comentario crítico. inSTRUcciOneS: 1. Lee y analiza los contenidos de la lectura seleccionada N° 1 El cuento de la eficacia y eficiencia” 2. Observa el Vídeo “Formula 1 Pit Stops 1950”, y complementa la información obtenida en la lectura y análisis del tema N°1; (haz clic en el siguiente link https://www.youtube.com/watch?v=RRy_73ivcms 3. Prepara un comentario sobre: ¿Qué están haciendo las empresas para lograr mayor agilidad? 4. Envíe su comentario al aula virtual adjuntando sus datos. U N id a d i t eM a N ° 2 30 TeMA n° 2: ORGAniZAciÓn Y eSTRUcTURA deL BPM Apreciados estudiantes continuamos con un tema que nos servirá para entender cómo se organiza el business process management y cuál es su estructura, es tema es vital para que nosotros podamos diseñar modelos basados en procesos, por esa razón debemos leer detenidamente y tratar de relacionarlos con lo que vemos o qué recibimos en una empresa u organización. 1. ORGAniZAciÓn Y eSTRUcTURA deL BPM. 1.1. conceptos de Gestión en BPM (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 El concepto de BPM Governace es un modelo de gestión corporativo orientado a procesos, mientras que el concepto de BPM Operacional abarca todo el ciclo de gestión por cada proceso o línea de negocio por separado. Cada proceso puede encontrarse en un nivel de madurez diferente en cuanto a su implementación de BPM, en cambio el BPM Governance es un solo modelo de gestión para todas las áreas de la organización. A continuación se van a describir y analizar estos dos conceptos fundamentales para el entendimiento de BPM. 1.1.1 BPM Governance (HITPASS, 2013)BPM Governance, también llamado gobierno corporativo, como un modelo de gestión corpora- tivo orientado a procesos, pero integrado con todas las capas de una organización (capa de dirección, operacio- nal 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 defi- nición de perfiles y cargos, la gestión en operaciones, apoyo tecnológico hasta el alineamiento con el portafolio de proyectos corporativo. (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 «governan- ce» 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. U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 31 1.1.2.-BPM Operacional (HITPASS, 2013)El BPM Operacional abarca la gestión del ciclo BPM por proceso y no los mecanismos de alinea- miento con las otras capas de la organización que, es dominio de un modelo que incorpora BPM Governance. El ciclo presentado en este libro 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. Ilustración 6. El ciclo de BPM por proceso Fuente: HITPASS, 2013 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 En la etapa de «Documentación del Proceso» el conocimiento adquirido en la etapa de levantamiento se docu- menta 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). U N id a d i t eM a N ° 2 32 La etapa de «Implementación del Proceso» abarca tanto la implementación técnica como también las adaptacio- nes 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 recur- sos 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 ope- raciones, 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 pro- cesos. 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-Governan- ce). 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. 1.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 dife- rencia 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 com- pleja 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 argumen- ta 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 se- cuencial 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 U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 33 tareas o procesos pueden ser creados. Los eventos internos incluyen las asignaciones y reglas del negocio. Los trabajadores de casos asignan tarease 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 automati- zadas 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. 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 estan- darizació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 Ilustración 7. Ejemplo Gestion de caso – Clinica Fuente: http://www.elsevier.es/es-revista-enfermeria-clinica-35-articulo-gestion-casos http://www.elsevier.es/es-revista-enfermeria-clinica-35-articulo-gestion-casos U N id a d i t eM a N ° 2 34 1.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 identifi- cando patrones respecto a las acciones, pero dada la naturaleza de la gestión de casos, no debiese estructurar- se, 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 habili- ta 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 pro- cesos 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 accio- nes 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». 1.2 La automatización de procesos La Automatización de Procesos de Negocio también llamado 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, abas- tecimiento 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. Todo proceso de negocio que por lo general sea iniciado por una actividad rutinaria tal como el llenado de un formulario, el cual debe seguir una serie de pasos predefinidos dentro de un flujo dado, y que concluye con la aprobación de dicha operación puede ser automatizado por medio del uso de un BPA. El objetivo del BPA no es simplemente el automatizar los procesos de negocios, sino también el simplificar y mejorar los flujos operativos en su totalidad. (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 ries- go 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 U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 35 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 auto- matizado: Si hablamos de automatización de procesos no significa que este se encuentre completamente automatizado. La componente central de la automatización de procesos es el Process Engine (automatización del flujo de con- trol). 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). 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 losusuarios. 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. En la Ilustración n°8 encontrará una representación genérica de la automatización de un proceso con un Process Engine. Ilustración 8. Automatización de un proceso con un Proceso Engine Fuente: HITPASS, 2013 Modelo de procesos técnico Modelo ejecutable Monitoreo y reporte Orquestación de servicios Process Engine (BPMS) Medición del tiempo de ciclo Asignación de actividades Participante ParticipanteSistema TI Sistema TI Integración automática Decisión automatizada Integración automática Asignación de actividades Human Workflow Management U N id a d i t eM a N ° 2 36 Ilustración 9. Ejemplo de caso de automatización Fuente: Recuperado de http://www.automatizar.org/2012/01/top-5-de-las-tendencias-de.html 1.3.-Los participantes en BPM (HITPASS, 2013)Si admitimos que BPM como disciplina de gestión integrada abarca todas las capas de una orga- nizació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 proyec- tos, 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. Ilustración 10. Roles en BPM Fuente: HITPASS, 2013 http://www.automatizar.org/2012/01/top-5-de-las-tendencias-de.html U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 37 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 directa- mente 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 proce- so, 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 respon- sables 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 conoci- mientos de BPM en general, conocimientos del negocio y de la técnica de 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 habi- lidad 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 em- patí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 reali- zarse 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 desa- rrollo, 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 U N id a d i t eM a N ° 2 38 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. 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 Inge- niero de Procesos Arquitecto SOA e Ingeniero de Desarrollo 1.3.1. 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 espe- cialidad 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 se- gundo caso de Motores de Reglas llamados BRMS (Business Rules Management Systems). Como el lector se habrá dado cuenta el tan conocido BPMS es sólo una componente de todas las áreas de aplicación en BPM, el de implementación técnica o de automatización de procesos. 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 pla- taformas 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 • 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 tiem- po 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óri- cos 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.). U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 39 • Todas estas herramientas las podemos posicionar en tres niveles o capas de un marco de Arquitectura Em- presarial moderno como lo muestra la Ilustración 11. Ilustración 11. 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 con- trol 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. (HITPASS, 2013) Nos comenta que: El lector no debe confundir BPA Tools con herramientas que fueron concebi- das para modelar e implementar procesos como la tan difundida herramienta libre de licencia Bizagi (es un mo- delador 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 si- mulació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 Architec- ture) 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 requie- re 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? U N id a d i t eM a N ° 2 40 1.3.2 La arquitectura del BPM y SOA La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido creadas para satis- facer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad. Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusiva- mente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. (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 Traditionally Business Process Management (BPM) and Service Oriented Architecture (SOA) have been pursued as two independent initiatives. Recently, the BPM-SOA combination is being advocated as the best approach, enterprises have, to bring a closer alignment between business processes and IT resources and reach the desi- red business agility and responsiveness to changing business requirements. Fuente: Kamoun, ACM Publication,April 2007 En general la orientación al servicio proporciona la capacidad de interoperar con aplicaciones y con agentes ex- ternos (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 servi- cios 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. El capítulo 11 está dedicado específicamente a describir las componentes y las funcionalidades de la capa tecnológica de SOA. 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 miran- do 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. . . . . . ..? (Ocu- rren cambios en las variables del entorno, como demanda, competencias, nuevos productos, etc.), de otra forma, simular cómo las variables 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 es- pecificació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. U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 41 En la capa BPE nos encontramos con los famosos BPMS (Business Process Management Suite) los cuales se- gú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. Ilustración 12. Arquitectura del BPM y SOA Fuente: HITPASS, 2013 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 Manage- ment 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 su- bá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áfi- cas, 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. U N id a d i t eM a N ° 2 42 1.4. el mundo de las reglas de negocio 1.4.1. definición 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.» De acuerdo al manifestó de reglas de negocio publicado por esta misma comunidad [BRG10]( Business Rules Manifestó), las Reglas de Negocio describen qué decisión tomar o que acción realizar ante una situación de ne- gocio determinada. Representan la lógica principal en una combinación de factores del negocio e indican lo que una organización “debe hacer” en la toma de decisiones. Aunque las reglas sientan las bases para la dirección de las actividades del negocio, no representan procesos ni procedimientos y tampoco pueden estar contenidas dentro de éstos [Faundes-Hitpass-Astudillo10]. 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. Correlación de factores para la detección de fraude Correlación de factores para anticiparse ante ocurrencias de riesgos 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 condicio- nes, 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». Al respecto existen principalmente tres técnicas para expre- sar reglas de negocio de manera formal: 1. Lenguaje estructurado 2. Árboles de decisión 3. Tablas de decisión En un ejemplo simple para la determinación de una tarifa de un seguro automotriz se van a ilustrar las tres for- mas de expresión. El lenguaje estructurado es un pseudocódigo muy parecido a un lenguaje de programación, pero más sencillo y restringido a la aplicación de reglas. Se permite la construcción «if-then-else» y el administrador de reglas debe definir las variables. Ejemplo: «Si el conductor es > a 40 años y < a 65 años U Nid a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 43 ......... aplica descuento de 15 % sino aplica tarifa BN5» Los árboles de decisión funcionan por el principio de descarte. Cada rama del árbol describe condiciones y al final de cada rama se encuentra especificada la acción. Ejemplo: «Si el conductor es hombre se deriva a rama A .. Si el conductor es mujer se deriva a rama B» Las Tablas de decisiones son matrices que combinan condiciones, reglas y acciones. La Ilustración 13 muestra para nuestro ejemplo una tabla de decisión. Ilustración 13. Tabla de negocio Fuente: HITPASS, 2013 La tabla muestra las condiciones de entrada en las primeras filas. Las columnas expresan las reglas de decisión, es decir las entradas de acciones. Dependiendo de la combinación de condiciones y reglas se aplican las accio- nes expresadas al final de la tabla. U N id a d i t eM a N ° 2 44 Ilustración 14. Ejemplo de Regla de negocio Fuente: Extraído de: http://desarrollosoa.blogspot.com/2013/05/las-reglas-de-negocio-automatizadas-en.html 1.4.2. Gestión de reglas de negocio Los Procesos de Negocio son grupos actividades coordinadas que tienen el objetivo de conseguir un fin. Estas actividades deben plantearse siguiendo unos principios y normas que se denominan Reglas. Aunque las Reglas de Negocio no son vinculantes para la Gestión por Procesos, la potencian enormemente y aumentan sus beneficios. Las Reglas de Negocio se deben definir de manera independiente de los Procesos con los que la empresa fun- ciona, ya que, aunque están muy relacionadas, no están supeditadas a éstos ni a los cambios que éstos puedan sufrir. (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. Tanta es la importancia que se les da en algunos rubros a las reglas de negocio, que hace un tiempo ya se han formado comunidades de reglas de negocio, que incluso publicaron un «Manifesto de Reglas de Negocio», como indicado en este párrafo. 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 formu- lació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. http://desarrollosoa.blogspot.com/2013/05/las-reglas-de-negocio-automatizadas-en.html U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 45 Algunas Suite de BPM (BPMS) traen motores de reglas incorporados, en otros casos existen BRMS indepen- dientes 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. Al lector que le interese profundizar sobre las funcionalidades que debieran soportar los Sistemas de Gestión de Reglas de Negocio y cómo se pueden clasificar, comparar y evaluar los BRMS que se ofrecen en el mercado puede consultar un estudio que realizaron [Faundes-Hitpass-Astudillo10] y que fue presentado en la Conferencia Latinoamericana de Informática (CLEI) el año 2010. 1.4.3. 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 codi- ficadas 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 ilustra- ción 15 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. Ilustración 15. 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 Ilustración16. U N id a d i t eM a N ° 2 46 Ilustración 16. 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. Segu- ramente el lector estará ya pensando en las consecuencias que tendría la ampliación para el modelo: 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 coti- zació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 clara- mente 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 unmodelo de procesos? Para estos efectos volvemos a nuestro ejemplo de la «Orden de Com- pra». 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 2.10. Ilustración 17. Proceso orden de compra con actividad del tipo regla de negocio Fuente: HITPASS, 2013 U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 47 A continuación se describen las diferencias de ambos tipos de reglas: Reglas de ruteo son evaluadas por com- puertas 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». 1.5. Técnicas de mejora continua 1.5.1. Six Sigma Six Sigma es una metodología de mejora continua que fue desarrollada por Motorola en los años 80 con el obje- tivo 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úme- ro 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 acepta- ción o desempeño meta. Obtener 3,4 defectos en un millón de oportunidades es un objetivo bastante ambicio- so. 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) U N id a d i t eM a N ° 2 48 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. Ocurre que en la vía de alcanzar un desempeño Six Sigma, o habiéndolo alcanzado, las especificaciones de aceptación (requisitos) del producto o servicio cambian debido a que lo que lo que antes era six sigma hoy ya podría no serlo, entonces se requerirán nuevos esfuerzos de mejora para alcanzar el nivel 6 sigma. Muchas ve- ces esto ocurre por condiciones de mercado, lo que antes era aceptable para los clientes hoy podría no serlo, progresivamente nos encontramos con clientes más exigentes, ya sea por acción propia, de la competencia, o comparaciones con otras industrias. (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 manufac- tureras utilizando Six Sigma, pero se debe mencionar que existen muy pocas empresas que han alcanzado el nivel de Six Sigma. Ilustración 18. Metodologia DMAIC - SixSigma Fuente: Extraido de http://aacarsa.com/calidad.php 1.5.2. kAiZen 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 (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 con- tinua». La filosofía de Kaizen concibe errores y problemas como pequeños «tesoros» que esconden oportunida- des 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: http://aacarsa.com/calidad.php U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 49 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 traba- jo (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 es- fuerzos 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 participanteen 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 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. Ilustración 19. Ciclo de mejora Kaizen Fuente: Extraído de http://filosofia5s.blogspot.com/p/filosofia-5s-kaizen-kamban.html http://filosofia5s.blogspot.com/p/filosofia-5s-kaizen-kamban.html U N id a d i t eM a N ° 2 50 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 1.5.3. Lean Management (HITPASS, 2013) La metodología Lean Management surge de la necesidad de eliminar pasos innecesarios en el cadena de pro- ducció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, 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 importan- te 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 des- cubrirá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 proporcio- nar 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 compar- tir 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. U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 51 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 momen- to 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 pro- ductos, 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. LEAN Mayor Calidad, Menor Coste, Menor Lead Time Just-in-time Heijunka VSM 5 S QDF TPM KANBAN SMED Estandarización Kaizen Continuous �ow Takt Time Pull System Parada y noti�cación de fallos Separación Hombre - Máquina Jidoka Ilustración 20. Características - Lean Managment. Fuente: Extraído de http://bit.ly/2hNaobO 1.5.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 centra- dos 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 denomina- do 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. http://bit.ly/2hNaobO U N id a d i t eM a N ° 2 52 (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 procesospropios. A continuación se citan algunas definiciones de reconocidos autores: 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 meto- dologí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. Ilustración 21. Tipos de benchamarking Fuente: Extraído de http://es.slideshare.net/yohadriana/presentacin-benchmarking http://es.slideshare.net/yohadriana/presentacin-benchmarking U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 53 videOS Video 06: Introducción a la automatización de procesos - Caso de estudio. Datos del Video seleccionado Tema: El valor de la automatización de procesos URL: https://www.youtube.com/watch?v=i7iJ06SbXmo Duración: 4:42 min Autor(a): T21 Año: Publicado el 7 ene. 2013 Reseña: Expertos a T21 comparten los beneficios de la auto- matización de procesos en almacenes durante época de crisis económica. Licencia: YouTube estándar Video 07: Como surge el Six Sigma. Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Seminario gratuito de fundamentos del Six Sigma 1 URL: https://www.youtube.com/watch?v=M4Omc5Gpu68 Duración: 4:13 min Autor(a): Centro de e-Learning. UTN FRBA. Cursos a distancia Año: Actualizado el 13 may. 2010 Reseña: Expertos de UTN FRBA comparten los beneficios de los fundamentos del Six Sigma. Licencia: YouTube estándar U N id a d i t eM a N ° 2 54 LecTURA SeLecciOnAdA nº 2: Viviana.E. (2014). El Modelo de Producción Toyota - Claves del Éxito [Publicación en el blog]. Disponible en http://bit.ly/2gZYgEs AcTividAd FORMATivA n° 3 Elabora un cuadro comparativo sobre las técnicas de mejora continua estu-diadas, considerando sus características principales los métodos utilizados por cada técnica etc. inSTRUcciOneS: • Analiza detenidamente los contenidos desarrollas en el tema N° 2 sobre las técnicas de mejora continua y extrae las características de cada una. • Completa la información con el análisis de la Lectura N° 2 • Busque mayor información acerca de la metodología que cada técnica utiliza, en páginas web de reconocida procedencia. • Observe el vídeo: Proceso Mejora continua https://www.youtube.com/watch?v=OO9jtaADrpY • Diseñe un cuadro comparativo, adecuándolo a las necesidades de la informa-ción analizada. • Envía tu cuadro completo a través del aula virtual. http://bit.ly/2gZYgEs U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 55 videOS Video Actividad 03: Proceso Mejora Continua Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Proceso Mejora continua URL: https://www.youtube.com/watch?v=OO9jtaADrpY Duración: 2:33 min Autor(a): Prodial Comunicación Integral Año: Publicado el 29 abr. 2014 Reseña: Video que explica el proceso de la mejora continúa. Licencia: YouTube estándar Video Actividad 4A : ¿Qué es un proceso? Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: ¿Qué es un proceso? URL: https://www.youtube.com/watch?v=boh_PBEyLEM Duración: 2:02 min Autor(a): BizagiEspanol Año: Publicado el 2 feb. 2015 Reseña: Video que explica que es un proceso. Licencia: YouTube estándar. Video Actividad 04B: Proceso Mejora Continua Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Proceso Mejora continua URL: https://www.youtube.com/watch?v=OO9jtaADrpY Duración: 2:33 min Autor(a): Prodial Comunicación Integral Año: Publicado el 29 abr. 2014 Reseña: Video que explica el proceso de la mejora continua. Licencia: YouTube estándar U N id a d i t eM a N ° 2 56 RÚBRicA PARA evALUAR Un cUAdRO cOMPARATivO Nombre del estudiante: ________________________________________ Sección: _______________________ Fecha: ______________________ INDICADORES CRITERIOS 4 EXCELENTE 3 BUENO 2 REGULAR TOTAL eLeMeNTOs A cOMpARAR. Identifica todos los elementos de comparación de acuerdo a la información presentada Faltan algunos elementos esenciales para la comparación, No hay precisión de los en los enunciados descritos cARAcTeRísTIcAs. Las características elegidas son suficientes y pertinentes. Las características elegidas son mínimas No enuncia las características a comparar. IDeNTIFIcAcIóN De seMejANzAs y DIFeReNcIAs. Identifica de manera clara y precisa las semejanzas y diferencias entre los elementos comparados. Identifica algunas de las semejanzas y diferencias entre los elementos comparados. No identifica las semejanzas y diferencias de los elementos comparados. RepReseNTAcIóN esqUeMáTIcA. La organización gráfica del cuadro, presenta los elementos centrales y sus relaciones en forma clara y precisa. La organización gráfica representa los elementos solicitados aunque no es del todo claro y preciso La organización gráfica no representa esquemáticamente los elementos a los que hace alusión el tema. pReseNTAcIóN DeL cUADRO cOMpARATIVO La presentación/exposición fue hecha en tiempo y forma, de acuerdo a un formato pre establecido en digital, sugerida por el docente La presentación/ exposición fue hecha en tiempo y forma, aunque la entrega no fue en el formato pre establecido, por el docente. La presentación/ exposición no fue hecha en tiempo y forma. La entrega no se dio en la forma pre establecida por el docente. cALIFIcAcIóN De LA AcTIVIDAD U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 57 AcTividAd FORMATivA n° 4 Describe Que es un proceso. Desarrolla una prueba mixta. inSTRUcciOneS: 1. Lee y analiza La Unidad I 2. Complementa tu estudio con la visulaizacion del video N°1 Vídeo, ¿Qué es un proceso? • https://www.youtube.com/watch?v=boh_PBEyLEM Vídeo: Proceso Mejora continua • https://www.youtube.com/watch?v=OO9jtaADrpY 3. Lee las preguntas detenidamente 4. Selecciona la aternativa que consideres correcta y/o desarrolla y explica lo solicitado. SUGERENCIA: Las preguntas siguientes le permitirán verificar su aprendizaje de esta unidad. Le recomiendoque las resuelva cuidadosamente. U N id a d i t eM a N ° 2 58 GLOSARiO de LA UnidAd i B BPM Business process management BPR reingeniería de los procesos de negocios. Es el rediseño de los procesos empresariales e implementación de cambios c CALIDAD Conjunto de propiedades inherentes a una cosa que permite caracterizarla y valorarla con respecto a las restan- tes de su especie. CRM es aquel que da apoyo a la gestión de las relaciones con los clientes, a la venta y al marketing. e ERP son sistemas de información gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía en la producción de bienes o servicios. P PROCESOS PROCESS ENGINE Platforma de software que ejecuta y da mantenimiento a un flujos de procesos. T TRAZABILIDAD Serie de procedimientos que permiten seguir el proceso de evolución de un producto en cada una de sus eta- pas w WORKFLOW flujo de trabajo es el estudio de los aspectos operacionales de una actividad de trabajo cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de estas actividades. U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 59 BiBLiOGRAFÍA de LA UnidAd i Bravo, J. (2011). Gestión de procesos. Santiago de Chile: Evolución S.A. Cuatrecasas, L. (2010). Gestión Integrada de la calidad -Implanración, control y certificación. Barcelona: Inmobi- liaria S.L. Hammer, M. y Champy, J. (1993). Reingenieria. Bogotá: Norma. Harmon, P. (2007). Business Process Change A guide for Business managers and BPM and Six Sigma Profesio- nals Second Edition. USA: MK. HITPASS, B. (2013). BPM Business Process management Fundamentos y Conceptos de Implementación 3ra. Edición actualizada y ampliada. Santiago de Chile: Edición hispana. John Jeston & Johan Nelis. (2008). Business Process Management. Practical Guidelines to Successful Imple- mentations. Sydney Australia: BPM Consultants. SIGMA, P. O. (15 de 07 de 2015). PAGINA OFICIAL ORGANIZACION SIX SIGMA. Obtenido de http://www.6sig- ma.com 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). Guía de referencia de la Asociación Inter- nacional de Profesionales de BPM 3ra Edición. USA. U N id a d i t eM a N ° 2 60 AUTOevALUAciÓn de LA UnidAd i Las preguntas siguientes le permitirán verificar su aprendizaje de esta unidad. Le recomiendo que las resuelva cuidadosamente. 1. Cuál es el del nuevo concepto de valor para los clientes: A) La capacidad que tiene las organizaciones de adaptar sus ofertas de bienes y servicios. B) La capacidad que tiene las organizaciones de adaptar sus ofertas de sus productos. C) La capacidad que tiene las organizaciones de adaptar sus ofertas de acuerdo a la demanda. D) La capacidad que tiene la organizaciones de verificar la trazabilidad E) La capacidad que tiene la organizaciones de adaptar conceptos de calidad. 2. La siguiente afirmación es falsa o verdadera: Introducir procesos en las organizaciones que les permita entrar en un círculo virtuoso de mejora continua para dar cumplimiento a estas exigencias a través del tiempo, son los desafíos actuales a los que se encuentran sometidas las organizaciones. A) Falso B) Verdadero 3. Quién desarrollo el concepto de la administración científica? A) Adam Smith. B) F. Thailor . C) Paul Harmon D) Jeston y Neils E) Edward Demming 4. Las siglas TQM, significa: A) Total Quality Management B) Total Quality Modeling C) Total Quality Metrical D) Total Quality Methodology E) Total Quality Manufacturing U N id a d i teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 61 5. BPM se puede concebir como la tercer gran ola en la evolución de la ingeniería de procesos después de TQM, SixSigma y BPR. A) Falso B) Verdadero 6. Marque la alternativa que complete la definición: Un proceso de negocio es un conjunto de actividades que impulsadas por ___________y ejecutándolas en una cierta __________ crean valor para un cliente (interno o externo. A) Características - serie B) Negocios- lógica C) Procesos - secuencia D) eventos-secuencia. E) Actividades – producción. 7. Como se define el BPM Governance: A) Modelo de gestión corporativo orientado a métodos. B) Modelo de gestión corporativo orientado a resultados C) Modelo de gestión corporativo orientado a tecnología D) Modelo de gestión corporativo orientado a operaciones E) Modelo de gestión corporativo orientado a procesos 8. Cuáles son las herramientas del BPM: A) SOA,BAM,BPA,PMC,ERP. B) SOA,BAM,BPA,PMC,SIX SIGMA. C) SOA,BAM,KAIZEN,PMC,ERP. D) S-S,BAM,BPA,PMC,ERP. E) SOA,8-V,BPA,PMC,ERP. U N id a d i t eM a N ° 2 62 9. Es un proceso para medir la calidad de los productos y servicios o el desempeño de los procesos compa- rándose con competidores más fuertes: A) Kayzen. B) 5 s. C) Six sigma. D) Benchmarking . E) Lean Management. 10. El objetivo principal de Six Sigma es ________ y _________los procesos de tal forma que los resultados de los procesos tengan una mínima variación y mejore su rendimiento promedio sin errores. A) Diseñar - gestionar B) Planificar - controlar C) Implementar - mejorar D) Observar – medir E) Analizar - estandarizar NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 63 UNIDAD II ARQUTecTURA eMPReSARiAL en eL cOnTeXTO BPM diAGRAMA de PReSenTAciÓn de LA UnidAd ii Al finalizar la unidad, el estudiante será capaz de diferenciar los tipos de estándares existentes para la gestión empresarial basada en procesos, de forma precisa y contextualizándolos con situaciones de la realidad 64 CONTENIDOS ACTIVIDADES FORMATIVAS (hAbILIDADes y AcTITUDes) SISTEMA DE EVALUACIÓN (TécNIcAs y cRITeRIOs) Tema N° 1 : Introducción a la Arquitectura Empresarial 1 Historia y Evolución -¿Qué es una Arquitectu-ra? 5 Conceptos básicos de Arquitectura Empresarial (AE) 3 Áreas de una Arquitectu-ra Empresarial: Business Process Outsourcing (BPO), Gestión de la Caldiad, Auditoría, In-formation Technology Infraestructure Libraary (ITIL) Tema N° 2: Estándares de Gestión empresarial 1 Relación AE & BPM & SOA 2 Framenworks de Ar-quitectura Empresaria ZACHMAN, TOAGAF, FEA. • Reconocer los conceptos utiliza-dos en Arquitectura empresa-rial. Elabora un cuadro com-parativo sobre los drivers in-ternos y externos de una ar-quitectura empresarial. Resuelve la prueba Mixta N°2. • Identificar los estándares re- lacionados a la gestión em-presarial basada en proce-sos. Participa en el foro de debate dando una expli- cación sobre cómo se re-lacionan BPM y SOA. Resuelve la prueba de desarrollo N°1. Procedimientos e indicado-res de evaluación perma-nente: • Entrega puntual del trabajo realizado. • Calidad, coherencia y Pertinencia de conteni-dos desarrollados: Indi-vidual o equipo. • Prueba teórico-práctica individual. • Actividades desarrolla-das en sesiones Tutori-zadas. Criterios de evaluación para la prueba mixta y prueba de desarrollo: • Conceptos y terminolo-gía • Conocimiento de las re-laciones entre conceptos • Desarrollo del tema con evidencias y ejemplos RECURSOS: Videos: Tema Nº 1: • Video: Qué es la gestión de calidad y la norma ISO 9001 https://www.youtube.com/watch?v=fWvEWODtmok Tema Nº 2: • Video: Implementación SOA https://www.youtube.com/watch?v=9xYOUtxiql4 DIAPOSITIVAS ELABORADAS POR EL DOCENTE: Lectura complementaria: Lectura Seleccionada Nº 1 Drivers Internos Y Externos Lectura seleccionada N°2 ¿Qué es SOA? NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 65 INsTRUMeNTO De eVALUAcIóNPrueba Mixta N°2 Prueba de desarrollo N°1 bIbLIOgRAFíA (básIcA y cOMpLeMeNTARIA) BASICA HITPASS, Bernard, BPM: Business Process Management Fundamen-tos 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.. RecURsOs eDUcATIVOs DIgITALes Qué es un BPM [en línea]. [Consulta: 03 de junio de 2015] Disponible en Web: http://downloads.tuxpuc.pucp.edu.pe/linuxweek2012/03_Miercoles/01_Fernando-Espinoza. pdff U N id a d ii t eM a N ° 1 66 TeMA n° 1: inTROdUcciÓn A LA ARQUiTecTURA eMPReSARiAL Apreciados estudiantes para entender y controlar la complejidad organizacional es necesario distinguir y ad- ministrar la información de todas las áreas empresariales, a través de modelos definidos en una arquitectura empresarial, en diferentes niveles de abstracción. El ciclo de vida de los modelos de la arquitectura empresarial se administran por separado, pero luego se integran por medio de relaciones de negocio. Podemos resumir que el término arquitectura se refiere a un todo estructural. Se trata de mostrar la relación entre las partes en un entorno complejo, más que el detalle. 1 HiSTORiA Y evOLUciÓn - cOncePTOS BáSicOS (HITPASS, 2013) El concepto de arquitectura en general se remonta hace más de siete mil años atrás si pensamos cuando se construyeron las pirámides egipcias. Uno de los tratados más conocidos sobre arquitectura se remonta a la épo- ca romana hace dos mil años atrás: Marcus Vitruvius Maximus Pollio 80 – 10 aC (ver www.thelatinlibrary.com) definió el concepto del arquitecto y la arquitectura de la siguiente forma: «El arquitecto debe estar equipado con el conocimiento de muchas disciplinas y diferentes tipos de sabidurías, porque es por su juicio (su obra) que por las otras artes es juzgado. Su arte es la experticia de la práctica y el conocimiento de la teoría. La práctica es el regular y continuo ejercicio del arte en donde se modela la materia de acuerdo al diseño de un bosquejo. Por el otro lado, la teoría es la habilidad de explicar, mostrar y demostrar los productos ejemplares, basándose en los principios de las proporciones». 1.1 ¿Qué es una arquitectura? Cuando escuchamos la palabra arquitectura por lo general pensamos en la estructura y en los planos de un edi- ficio, como se muestra en la ilustración 22, 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 define el término de arquitectura como: «the fundamental organization of a sys- tem 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 princi- ples system includes application, system, platform, system-of-systems, enterprise, product line, ... environment is developmental, operational, programmatic, . . . context of the system Ilustración 22. Diseño Arquitectónico Fuente: Extraído de: http://www.aricolarquitectura.com/ U N id a d ii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 67 2 cOncePTOS BáSicOS de ARQUiTecTURA eMPReSARiAL (Ae) Para entender ¿qué es una arquitectura empresarial y para qué sirve? se va a usar el 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 instala- ció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. 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 dónde van los ductos!». Si esta situación la comparamos con una organización o empresa y ésta requiere realizar un cambio, en simili- tud 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 an- te-proyecto reconstruye los planos y se puede pasar directamente a la etapa del estudio de factibilidad. Ilustración 23. Componentes de la arquitectura empresarial Fuente: Extraído de http://www.colombiadigital.net/actualidad/articulos-informativos/item/8123-que-es-arquitectura-empre- sarial.html U N id a d ii t eM a N ° 1 68 (Molano, 2015) “La Arquitectura Empresarial es una metodología que, basada en una visión integral de las organizaciones – o en este caso, de todo el Estado –, permite alinear procesos, datos, aplicaciones e infraestructura tecnológica con los objetivos estratégicos del negocio o con la razón de ser de las entidades. (...) Su principal objetivo es garantizar la correcta alineación de la tecnología y los procesos de negocio en una organización, con el propósito de alcanzar el cumplimiento de sus objetivos estratégicos” 2.1 drivers y Objetivos de una Ae (Zachman, 1987) 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 Nada es mágico: La excelencia se va construyendo paulatinamente. La tecnología juega un rol importante en esto. Como se ha visto anteriormente, las organizaciones son sistemas complejos por lo que se da la necesidad de abstracción, pero no es la única razón que justifica el empleo o la existencia de una arquitectura empresarial. Existe una serie de «drivers» (utilizamos el término en inglés porque engloba una serie de significados en con- junto que son difíciles de traducir como, hilo conductor, motivador, gatillador, justificador, necesidad, etc.) tanto internos como externos que requieren de mando y control. La ilustración 3 muestra estos drivers que son im- pulsados desde el interior de la organización (drivers internos) o requerimientos que impactan desde afuera a la organización (driversexternos). Todos estos drivers los podemos administrar por medio de un repositorio integrado de una herramienta de AE. Veamos a continuación el significado de cada uno de estos drivers. Ilustración 24. Drivers de una AE Fuente: HITPASS, 2013 U N id a d ii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 69 3 áReAS de UnA ARQUiTecTURA eMPReSARiAL Hasta el momento se trató 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 como lo muestra Ilustración 25. Business Process Outsourcing (BPO) (Tobón, 2012) Bajo BPO se entiende 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 medi- da (workflow), Seguridad y mesa de ayuda. EL BPO constituye una relación muy estrecha entre el cliente y el proveedor. Sus principales características son: Generalmente se trata de relaciones de largo plazo Integración compleja entre proveedor y cliente Entrega del servicio es altamente dependiente de TI La entrega de servicio es repetitiva Es habitual que sea globalizada. Ilustración 25. Áreas de una arquitectura empresarial Fuente: HITPASS, 2013 Empresas analistas estiman que el outsourcing de procesos es uno de los segmentos del mercado que tendrá las mayores tasas de crecimiento. Las razones de este mercado con gran perspectiva de crecimiento son: Para algunos procesos altamente estandarizados (Callcenter, reservas de hoteles, tarjetas de crédito) se pueden lograr servicios de alta calidad con mejores prácticas y seguridad transaccional Los proveedores globales pueden alcanzar un alto grado de especialización y de excelencia en sus servicios Sin embargo, no se debe confundir que con el BPO se externaliza la administración de la solución, no la ope- ración misma del negocio. La gestión del proceso es el core del negocio y debe seguir bajo control del dueño del negocio. Por consiguiente queda claro que 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 U N id a d ii t eM a N ° 1 70 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. Gestión de calidad - riesgo - conocimiento - regulaciones - otras El principio de la mejora continua en la gestión de calidad está fuertemente relacionada con BPM. 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. Si admitimos que los procesos de negocio representan en forma figurativa la «columbra vertebral» de una organización, entonces podemos relacionar cualquier ámbito de gestión a los procesos de negocio, modelos que debieran de existir sólo una vez (libre de redundancia). 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. Justamente la funcionalidad principal de una plataforma de AE es la flexibilidad en la administración de modelos y sus respectivas relaciones de negocio bajo un repositorio común. Auditoría Originalmente la auditoría estaba limitada a la revisión de la contabilidad de una empresa o de una sociedad, realizada por auditores externos que dan fe pública de la veracidad y exactitud sobre los registros contables y los estados financieros (véase definición en el diccionario de la Real Academia Española). Sin embargo, el concepto de auditoría es empleado hoy en día como un 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 eficien- temente 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. 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. ¿Qué relación puede tener la auditoría interna con una AE? El auditor necesita una referencia para evaluar y me- dir 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 implementa- dos 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. 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 depen- dencias que existen en y entre las capas de negocio, de integración y tecnologías de información. Este hecho U N id a d ii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 71 aumenta la complejidad si consideramos que existen también estados actuales y deseados en cada una de las capas y entre ellas. La arquitectura empresarial debiera mostrar las dependencias naturales entre los modelos y las diferencias en- tre la situación actual y la deseada. Por ejemplo, un sistema que suministra información a otro sistema, debería desarrollarse antes que los sistemas que dependen de esta información. Sin este conocimiento difícilmente podrán implementarse procesos de negocios integrados con los sistemas actuales y por consiguiente, tampoco podrán crearse nuevos servicios suficientemente integrados sobre la base de los sistemas existentes. 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 pro- cedimientos 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 representadoen 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. videOS LecTURA SeLecciOnAdA nº 1: Freund, J., Rücker, B., & Hitpass, B. (2014). Drivers internos y externos. En BPMN 2.0 Manual de Re- ferencia y Guía Práctica (4ta Ed.). Santiago de Chile. disponible en el aula virtual. Video 09: Arquitectura Empresarial y la organización. Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Arquitectura Empresarial 1 de 3. URL: https://www.youtube.com/watch?v=pEQBXG9pl8Q Duración: 4:46 min Autor(a): Devi Ramírez Año: Publicado el 18 abr. 2012 Reseña: fundamentos para una Arquitectura Empresarial. Licencia: YouTube estándar U N id a d ii t eM a N ° 1 72 AcTividAd FORMATivA n° 1 Elabora un cuadro comparativo sobre los drivers internos y externos de una arquitectura empresarial. inSTRUcciOneS: • Analiza detenidamente los contenidos desarrollas en el tema N° 1 sobre Arquitectura empresarial • Completa la información con el análisis de la Lectura seleccionada N° 1 • Complementa tu estudio observando el video: Qué es la gestión de calidad y la norma ISO 9001 https://www.youtube.com/watch?v=fWvEWODtmok • Busque mayor información acerca de este tema, en páginas web de reconocida procedencia. • Diseñe un cuadro comparativo, adecuándolo a las necesidades de la información analizada. • Envía tu cuadro completo a través del aula virtual. U N id a d ii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 73 RÚBRicA PARA evALUAR Un cUAdRO cOMPARATivO Nombre del estudiante: ________________________________________ Sección: _______________________ Fecha: ______________________ INDICADORES CRITERIOS 4 EXCELENTE 3 BUENO 2 REGULAR TOTAL eLeMeNTOs A cOMpARAR. Identifica todos los elementos de comparación de acuerdo a la información presentada Faltan algunos elementos esenciales para la comparación, No hay precisión de los en los enunciados descritos cARAcTeRísTIcAs. Las características elegidas son suficientes y pertinentes. Las características elegidas son mínimas No enuncia las características a comparar. IDeNTIFIcAcIóN De seMejANzAs y DIFeReNcIAs. Identifica de manera clara y precisa las semejanzas y diferencias entre los elementos comparados. Identifica algunas de las semejanzas y diferencias entre los elementos comparados. No identifica las semejanzas y diferencias de los elementos comparados. RepReseNTAcIóN esqUeMáTIcA. La organización gráfica del cuadro, presenta los elementos centrales y sus relaciones en forma clara y precisa. La organización gráfica representa los elementos solicitados aunque no es del todo claro y preciso La organización gráfica no representa esquemáticamente los elementos a los que hace alusión el tema. pReseNTAcIóN DeL cUADRO cOMpARATIVO La presentación/exposición fue hecha en tiempo y forma, de acuerdo a un formato pre establecido en digital, sugerida por el docente La presentación/ exposición fue hecha en tiempo y forma, aunque la entrega no fue en el formato pre establecido, por el docente. La presentación/ exposición no fue hecha en tiempo y forma. La entrega no se dio en la forma pre establecida por el docente. cALIFIcAcIóN De LA AcTIVIDAD U N id a d ii t eM a N ° 1 74 AcTividAd FORMATivA n° 2 inSTRUcciOneS: 1. Lee y analiza La Unidad II 2. Lee las preguntas detenidamente 3. Selecciona la aternativa que consideres correcta y/o desarrolla y explica lo solicitado. SUGERENCIA: Las preguntas siguientes le permitirán verificar su aprendizaje de esta unidad. Le recomiendo que las resuelva cuidadosamente U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 75 TeMA n° 2: eSTándAReS de GeSTiÓn eMPReSARiAL Describir la estructura de una organización (estrategia, personas, negocio, procesos, aplicaciones, tecnología). Detectar el impacto de un nuevo requerimiento en todas las capas de una organización Administrar las versio- nes de los modelos de la situación actual y futuros Planificar los proyectos del cambio organizacional Gestionar el ciclo de mejora continua La arquitectura empresarial ofrece justamente un marco estructural para describir y administrar los modelos y sus debidas relaciones que se requieren en la gestión por procesos. Para el autor es impensable, intentar de introducir un sistema de gestión integral orientado a procesos, sin apoyo de un concepto estructural de arquitectura. 1 ReLAciÓn Ae & BPM & SOA Los conceptos de Arquitectura Empresarial, BPM y modelos de servicios SOA persiguen los mismos objetivos generales de dejar disponibles técnicas de planificación, modelamiento, alineamiento y control, pero en diferen- tes 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. En el contexto de un concepto combinado de modelos AE-BPM-SOA nos encontramos con una serie de arte- factos (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 deno- minar «modelos esenciales» que comparten y traspasan información entre las capas. La Ilustración 27 muestra las principales intersecciones de modelos entre las áreas EA, BPM y SOA. Ilustración 27. Modelos esenciales en la intersección de un concepto integrado EA, BPM y SOA Fuente: [Stähler-etal-09] U N id a d ii t eM a N ° 2 76 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 des- cribir 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. 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. La Ilustración 28 muestra los niveles de abstracción de modelos en las capas de EA - BPM y SOA. Ilustración 28. Niveles de abstracción de modelos en capas de EA - BPM – SOA Fuente: Figura adaptada de [Stähler-etal-09] A continuación vamos a analizar el grado abstracción que requiere cada modelo en su respectiva capa y las re- laciones que existen entre ellos. La Ilustración 8 muestra una tabla con los principales modelos que se utilizan en el contexto de EA - BPM - SOA. Nota: El área de SOA en EA y BPM sólo se utiliza como instrumento de especificación y alineamiento. Una ar- quitectura orientada aservicios abarca más modelos y otros aspectos netamente técnicos. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 77 Lo primero que se dará cuenta el lector es que el grado de abstracción de modelos es siempre mayor hacia EA, como lo vimos en la figura anterior. 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 (véase primera columna de la tabla –Ilustración 29). Ilustración 29. Grado de abstracción de modelos EA - BPM – SOA Fuente: Figura adaptada de [Stähleretal 09] Veamos un ejemplo del sector financiero: «La solicitud de aprobación de un crédito hipotecario» sería el alcance del proceso de negocio definido en las categorías: «desde la solicitud de aprobación –> hasta la decisión de aprobación o rechazo»; Por consiguiente, el proceso de negocio «Solicitud de crédito» no abarca la elaboración del contrato y administración de un crédito aprobado. No obstante, el proceso de negocio es parte del eslabón de la cadena de valor del negocio de crédito, que continúa con la propuesta de elaboración de un contrato de una solicitud aprobada y finalmente con la administración de la cartera de créditos. Con el objetivo de evitar redundancias y de lograr un modelo de arquitectura integrado se deben definir clara- mente 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 con- tiene 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 represen- tado 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. U N id a d ii t eM a N ° 2 78 2 FRAMewORkS de ARQUiTecTURA eMPReSARiAL Bajo un framework de AE se entiende un marco estructural que define los modelos, los tipos de objetos perte- neciente 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. La primera propuesta de un framework de arquitectura empresarial lo desarrolló Zachman en el año 1987 [Zach- man87], publicación muy famosa en el «IBM Systems Journal» bajo el título de «A Framework for Information Systems Architecture». Si bien es cierto, el propósito inicial de desarrollar un framework no estaba pensado para administrar un modelo integrado de arquitectura empresarial, es decir corporativa, como se concibe hoy en día, si no más bien por el encargo de IBM de presentar un marco para alinear la estrategia de la empresa con las inversiones de TI. A pesar que, como ha sido descrito anteriormente, el primer framework se presentó a mediados de los años 80 no tuvo entrada la aplicación de AE frameworks hasta una década después. En el año 1996 el Gobierno de EEUU promulgó una ley para sus agencias federales, llamada «Clinger-Cohen Act», también llamada «Informa- tion Technology Management Reform Act of 1996» que tiene por objetivo mejorar la gestión de los procesos de inversiones en proyectos de TI, basados en un framework de arquitectura empresarial. Como consecuencia del «Clinger-Cohen Act» las agencias federales del gobierno norteamericano fueron ex- hortadas a implementar un enfoque holístico, apoyados por un framework de AE. El Gobierno Federal creó un consejo de directores de informática (CIO Council) que se encargó de desarrollar un framework de AE para estos fines y que más tarde se denominó FEAF (Federal Enterprise Architecture Framework, www.whitehouse.gov/ omb/ e-gov/ fea). Este framework se utiliza hoy en día como modelo de referencia para las agencias estatales de EEUU y también está disponible para la industria privada (ver sección 3.4.3). También se desarrollaron otros frameworks en el área pública: TAFIM (Tecnical Architecture Framework for Information Management) encargado por el Ministerio de Defensa, DoDAF (Department of Defence), TEAF (Treasury Architecture Framework) y otros no mencionados. A partir de mediados de los 90 el enfoque de arquitectura empresarial como instrumento público de mejor pla- nificación, alineamiento y control de gestión llama la atención a la industria privada, la que a través de diferentes iniciativas desarrollan sus propias propuestas de EA frameworks. La más difundida de ellas es TOGAF (The Open Group Architecture Framework), desarrollada por un consorcio de empresas y profesionales de TI. Existe una abundante literatura tanto científica como profesional sobre EA frameworks, razón por la cual no se seguirá profundizando en este trabajo el tema. El lector interesado puede consultar entre otros [Franke et al 09, Lankhorst09, Minoli08, Schekkerman04 , Schekkerman06, Takaaki05]. Los EA Frameworks no se pueden adoptar sin un estudio detallado de ellos y compararlos con la realidad or- ganizacional 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. 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á nom- brado 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. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 79 2.1 Zachman El framework de Zachman llamado “The Zachman Framework” es un marco de trabajo para Enterprise Archi- tecture (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 El framework de Zachman sirve fundamentalmente para implementar una arquitectura empresarial en las com- pañías. Todacompañía, grande o pequeña, necesita aplicar conceptos de arquitectura independientemente de sus características. Para implementar una AE, Zachman considera diferentes perfiles, roles y habilidades que deben participar en el proceso, e incide especialmente en los problemas de comunicación y entendimiento existentes entre dichos perfiles. 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 or- ganización de la compañía y los flujos de trabajo existentes ¿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á relacio- nado 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: U N id a d ii t eM a N ° 2 80 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 posi- ble reusar los modelos No incluye un proceso de análisis 2.2 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. Nacido a mediados de los 90, The Open Group ha trabajado de forma continua en la definición y evolución del framework . 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 recur- sos 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. Al framework de TOGAF se le reconocen los siguientes beneficios y ventajas: TOGAF es muy flexible y se adapta fácilmente a una organización TOGAF ofrece también un modelo de procedimiento llamado ADM (Architecture Development Method) Entre las desventajas nos encontramos con los siguientes aspectos: La arquitectura de negocio es débil y no menciona los objetos y modelos a utilizarse La documentación es muy abundante pero no siempre concreta, por lo que el usuario tiene que interpretar como usarla U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 81 2.3 FeA (Federal enterprise Architecture) FEA se compone de varios modelos de referencias que crean una taxonomía y ontología común para la descrip- ció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 Entre las ventajas de poseer una FEA se encuentran: Organizar la información gubernamental a un nivel general de Gobierno Promover el intercambio de información entre los entes del Estado Apoyar a los entes gubernamentales en el desarrollo de sus arquitecturas Apoyar a las organizaciones gubernamentales a desarrollar sus procesos de inversión en TI Satisfacer a los clientes de Gobierno sus necesidades en mejor forma, en menos tiempo y con un menor costo Al framework de FEA se le reconocen los siguientes beneficios y ventajas: FEA ofrece un enfoque muy completo para la arquitectura de una organización Entrega en detalle una descripción de las vistas y actividades que se necesitan para construir una AE FEA no impone metodologías de modelado por lo que es fácilmente adaptable a cualquier tipo de organización Entre las desventajas nos encontramos con los siguientes aspectos: La perspectiva estratégica es débil y no menciona los objetos y modelos a utilizarse No cuenta con un metamodelo 2.4 ARiS (Architecture of integrated information Systems) ARIS 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 in- formació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 U N id a d ii t eM a N ° 2 82 Tres Niveles Definición de requerimientos Diseño y especificación Implementación La Ilustración 30 muestra el esquema del ARIS House con sus cinco vistas y tres niveles. A diferencia de otros marcos metodológicos, ARIS fue diseñado desde un principio con un metamodelo documentado en, con un modelo de datos entidad-relación (ERM). Ilustración 30. ARIS House Fuente: HITPASS, 2013 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). EPC (desde los años 90 EPC se ha convertido en un «cuasi» estándar industrial en los países desarrollados) fue desarrollado en los años 80 por Scheer en Alemania, en el contexto de integrarlo en su concepto de una arquitectura de pro- cesos de negocio y sistemas de información (ARIS). Scheer fue pionero en el sentido de descubrir la importancia que tienen los procesos para la gestión empresarial y el diseño de los sistemas de información. En ARIS son los procesos los elementos centrales (vista de control en el ARIS House) que se alinean con la estrategia corporativa y determinan el corte de los sistemas de información. Este concepto queda claro si se revisa la vistaprincipal del metamodelo EPC (la técnica del EPC la trataremos con mayor profundidad en la sección 6.3) en el modelo de arquitectura de ARIS. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 83 Ilustración 31. Metamodelo eEPC de ARIS Fuente: HITPASS, 2013 La Ilustración 31 muestra la vista del metamodelo EPC (el metamodelo muestra también objetos del modelo EPC extendido, razón por la cual lleva la letra «e = extended» para diferenciarlo del modelo esencial) en la nota- ción Entidad-Relación: El tipo de objeto «función (es equivalente a una actividad en otras nataciones como en BPMN)» es el elemento central de todo el metamodelo. Las funciones son las que transforman insumos en bienes de valor, formalmente inputs en outputs. La función que puede ser en ARIS agregada (proceso o subproceso) o desagregada hasta su máximo nivel de descomposición, se puede relacionar con los principales objetos de las diferentes vistas de la arquitectura como lo indica el metamodelo eEPC. La función se relaciona por consiguiente con: Un cargo o rol organizacional «es responsable» de la ejecución de la función. Un evento «inicia» una función y la función «crea» como resultado un nuevo evento, o nuevo estado del objeto de negocio. Una función «apoya» en algún grado directo o indirecto el cumplimiento de un objetivo de negocio. Una función «apoya» en forma intermedia o final la creación de algún producto o servicio. Una función puede crear un documento. Una función «utiliza» en su proceso de transformación datos que se agrupan conceptualmente en Datacluster. Una función es implementada o es «utilizada» por una aplicación o sistema de información. ARIS fue sin duda uno de los mejores conceptos de arquitectura empresarial orientada a procesos que se desa- rrollaron en los años 90. El éxito y la cobertura de mercado que logró lo demuestra y hasta hoy en día sigue lide- rando los cuadrantes de firmas analistas como Gartner y Forrester. Scheer vendió su participación hace un tiem- po atrás a Software AG, por lo que la empresa que él fundó IDS Scheer, ya no es independiente de proveedores U N id a d ii t eM a N ° 2 84 de BPMS o ERP s. Otro aspecto de no menor importancia es que el fundamento se basa en el conocimiento y estándares de la década de los noventa y los conceptos cambiaron fuertemente a partir de la década del dos mil: De sistemas propietarios a estándares abiertos (XML, BPMN, SOA, etc.) De cliente servidor a aplicaciones web De infraestructura propia a servicios en la nube Si bien es cierto los fundamentos estructurales de ARIS son sólidos, no es menos cierto que aún el marco me- todológico y la plataforma tecnológica no han sido adaptados a los nuevos conceptos, estándares y tendencias tecnológicas. Entre ellos puedo enumerar: EPC no ha sido reemplazado por el estándar BPMN. La notación BPMN fue incluida como un modelo adicional en ARIS, pero el core del metamodelo sigue siendo EPC. La arquitectura sigue muy centrada en el proceso de desarrollo de procesos hacia la implementación por medio de sistemas. Las vistas están descompuestas en los niveles del proceso de desarrollo (requerimientos, especificación e implementación). En una arquitectura empresarial moderna, los niveles del proceso de desarrollo son sólo un aspecto de lo que se requiere para administrar un modelo de BPM Governance. La capa de SOA (Gobernabilidad de servicios) no se encuentra integrada en el metamodelo del repositorio de ARIS. Tecnológicamente la arquitectura de software de ARIS aún es cliente-servidor (con emulación web). El concepto de arquitectura de ARIS, sólo se ha implementado en su propia herramienta. El futuro de ARIS es incierto, habrá que esperar cómo reaccionará su nuevo dueño Software AG respecto de los puntos enumerados recientemente. Demás está de considerar que las alianzas que había creado IDS Scheer con Oracle, SAP y otros son actualmente competidores de Software AG. 2.5 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]. En este concepto se han basado muchas empresas interna- cionales para introducir BPM en sus organizaciones en los últimos años. 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 estanda- rizació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 au- sencia de clientes y proveedores globales. Se replican modelos de procesos altamente estandarizados, pero administran sus propias bases de clientes y reglas de negocio. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 85 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. Esta es la primera fase de un proyecto de arquitectura empresarial de acuerdo a esta metodología, que debe seguir el siguiente principio: «Antes de implementar la estrategia, construya primero la base o el fundamento del negocio». El entregable de esta fase es el llamado «modelo operacional». Según Ross et al, el modelo operacional es el fundamento y al mismo tiempo el input para definir una arquitectura empresarial adaptada a la empresa. Un modelo de arquitectura empresarial, desarrollado de acuerdo a esta metodología constituye la base para implementar la estrategia sobre este concepto, que de acuerdo al modelo de Ross et al corresponde a la tercera fase llamada «Implementación del modelo operacional a través de la arquitectura empresarial». La Ilustración 32 muestra el marco de referencia para implementar el modelo operacional orientado a procesos con apoyo del concepto de arquitectura empresarial: Ilustración 32. Marco de Referencia de Arquitectura Empresarial Fuente: [Ross et al 06], traducido por el autor El modelo presentado enla ilustración 32 consta de tres disciplinas o conceptos claves que Ross et al definen de la siguiente forma: 1. Modelo Operacional: El modelo operacional representa el compromiso de cómo la empresa quiere realizar su modelo de negocio. Representa el nivel de necesidades de integración y estandarización de los procesos de negocio para la creación de valor de sus clientes. 2. Arquitectura Empresarial: La arquitectura empresarial representa la lógica organizacional para los procesos de negocio y la infraestructura de TI, especificando los requerimientos de integración y de estandarización de los procesos de negocio definidos en el modelo operacional. U N id a d ii t eM a N ° 2 86 3. Modelo de BPM Governance: Es un modelo que define los mecanismos de gobernancia que asegure que los proyectos de BPM y de TI cumplan con los objetivos de negocio en todos los niveles de la organización. El modelo operacional se entiende como la definición de la visión de la empresa. Si las iniciativas estratégicas se focalizan y materializan en el modelo operacional, le entrega a la organización una guía facilitadora para desarro- llar mejores capacidades y mecanismos de alineamiento en proyectos de BPM y TI. A partir de esta definición el modelo operacional permite la planificación de una estrategia de negocio a través de la arquitectura empresarial plasmada en los procesos. Si una organización cuenta con varias líneas de negocio, se debe definir por cada una de éstas un modelo operacional propio. La arquitectura empresarial, como repositorio corporativo integrado, puede administrar cada uno de estos modelos por separado y mostrar la relaciones de integración que puedan existir entre ellos. El modelo de [Ross et al 06] considera 9 fases para implementar la estrategia empresarial orientada a procesos: 1. Antes de implementar la estrategia, construya primero la base o el fundamento del negocio 2. Defina el modelo operacional de acuerdo a los cuatro tipos de modelos operacionales (diversificación, coor- dinación, replicación, unificación) 3. Implemente el modelo operacional a través de la arquitectura empresarial adaptada a la empresa 4. Navegue a través de los diferentes estados del modelo de madurez de la arquitectura empresarial 5. Aproveche la capacidades aprendidas 6. Construya la base del fundamento proyecto por proyecto 7. Utilice el modelo de arquitectura empresarial como referencia para la externalización de servicios 8. Suba al siguiente nivel de madurez de la arquitectura empresarial 9. Planifique su mapa de ruta para lograr y asegurar el liderazgo En esta sección fueron descritas las primeras tres fases del modelo de Ross et al, las más importantes del modelo que las diferencia sustancialmente de todos los otros frameworks de AE, porque muestra mecanismos efectivos para plasmar las iniciativas estratégicas en un modelo de negocio orientado e integrado a los procesos de negocio. El resto de las fases no se diferencia conceptualmente de otros modelos clásicos de frameworks de AE y modelos de madurez, razón por la cual se desiste de su descripción en este capítulo. Al lector interesado se le recomienda de todas formas, no sólo la lectura sino el estudio del trabajo original. Los autores analizan y describen además varios casos reales de empresas que han implementado esta metodología. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 87 videOS LecTURA SeLecciOnAdA nº 2: Freund, J., Rücker, B., & Hitpass, B. (2014). BPMN 2.0 Manual de Referencia y Guía Práctica (4ta Ed.). Santiago de Chile. pp. 204-205. disponible en el aula virtual. Video 10: ¿Qué es BPMN? Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: ¿Qué es BPMN? URL: https://youtu.be/x5k67iBzSYg?t=7s Duración: Autor(a): Bizagi Lmtd. Año: 2015 Licencia: YouTube estándar U N id a d ii t eM a N ° 2 88 AcTividAd FORMATivA n° 3 Participa activamente en el Foro de discusión o debate, dando una explicación sobre cómo se relacionan BPM y SOA y elabora un informe inSTRUcciOneS PARA eL FORO de deBATe 4. Lee y analiza el tema N° 2 y la lectura seleccionada N° 2 5. Complementa la información consultando páginas Web, de reconocida procedencia 6. Observa el vídeo, Implementación SOA https://www.youtube.com/watch?v=9xYOUtxiql4 7. Participa en el Foro de debate opinando sobre el tema en discusión, en el día y hora programado 8. Realiza análisis crítico a las opiniones o planteamientos de sus compañeros. 9. Realiza planteamientos, sobre sobre cómo se relacionan BPM y SOA inSTRUcciOneS PARA LA eLABORAciÓn deL inFORMe: Realizar un resumen sobre los frameworks existentes para la arquitectura empresarial • Leer y analizar el tema N°2 especificamente el tema 2.2 • Complementa tu análisis con la lectura seleccionada N°2 • Extraer las ideas y hechos importantes • Relacionar estos hechos con el desarrollo de la tecnología actual • Responder la siguiente interrogante: ¿Qué framework eligiría Ud. Y porqué? Sugerencia: Revisa la RÚBRICA en donde se encuentran los criterios con que se evaluará tu trabajo para que obtengas el mejor resultado U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 89 RÚBRicA de evALUAciÓn deL inFORMe eScRiTO Nombre del estudiante: ________________________________________ Sección: _______________________ Fecha: ______________________ pUNTAje cRITeRIO 4 eXceLeNTe 3 bUeNO 2 MeDIANAMeNTe LOgRADO 1 NO LOgRADO TOTAL INTRODUccIóN Plantea clara y ordenadamente el tema del trabajo y su importancia Plantea en forma clara y ordenada, pero muy breve el tema del trabajo y su importancia Plantea en forma confusa el tema del trabajo y su importancia No se plantea la introducción cANTIDAD De INFORMAcIóN Todos los temas tratados y todas las preguntas fueron contestadas en al menos 2 oraciones Todos los temas tratados y la mayor parte de las preguntas fueron contestadas en al menos 2 oraciones Todos los temas tratados y la mayor parte de las preguntas fueron contestados en 1 oración. Uno o más temas no están tratados cALIDAD De INFORMAcIóN La información está claramente relacionada con el tema principal y proporciona varias ideas secundarias y/o ejemplos La información da respuesta a las preguntas principales y 1-2 ideas secundarias y/o ejemplos La información da respuesta a las preguntas principales, pero no da detalles y/o ejemplos La información tiene poco o nada que ver con las preguntas planteadas DIAgRAMAs e ILUsTRAcIO- Nes Los diagramas e ilustraciones son ordenados, precisos y añaden al entendimiento del tema Los diagramas e ilustraciones son precisos y añaden al entendimiento del tema Los diagramas e ilustraciones son ordenados y precisos y algunas veces añaden al entendimiento del tema Los diagra- mas e ilustra- ciones no son precisos o no añaden al entendi- miento del tema cONcLUsIONes La conclusión incluye los descubrimientos que se hicieron y lo que se aprendió del trabajo La conclusión incluye solo lo que fue aprendido del trabajo La conclusión incluye solo los descubrimientos que hicieron No hay conclusión incluida en el informe cALIFIcAcIóN De LA AcTIVIDAD U N id a d ii t eM a N ° 2 90 AcTividAd FORMATivA n° 4 Resuelve la prueba de desarrollo N°1. inSTRUcciOneS: 1. Lee y analiza La Unidad II 2. Lee las preguntas detenidamente 3. Desarrolla y explica lo solicitado. SUGERENCIA: La resolución de las preguntas siguientes le permitirán verificar su aprendizaje de esta unidad. Le recomiendo que las resuelva cuidadosamente U N id a d ii teM a N ° 2 NotacióN deProcesos de Negocio MANUAL AUTOFORMATIVO 91 GLOSARiO de LA UnidAd ii A AE Arquitectura Empresarial ARQUITECTURA Arte y técnica de diseñar, proyectar y construir edificios y espacios públicos ARQUITECTURA EMPRESARIAL es una metodología de mejora continua a mediano plazo, que basada en una visión integral AUDITORíA La auditoría es el examen crítico y sistemático que realiza una persona llamese auditor o grupo de personas independientes del sistema auditado B BPM Business Process Management BPO Business Process Outsourcing F FRAMEWORK (marco de trabajo) define, en términos generales, un conjunto estandarizado de conceptos, prácticas y crite- rios. i ITIL Biblioteca de Infraestructura de Tecnologías de Información O OUTSOURCING La subcontratación, externalización de la mercadotecnia o tercerización de una actividad S SOA La Arquitectura Orientada a Servicios T TOGAF The Open Group Architecture Framework U N id a d ii t eM a N ° 2 92 BiBLiOGRAFÍA de LA UnidAd ii Bravo, J. (2011). Gestión de procesos. Santiago de Chile: Evolución S.A. Cuatrecasas, L. (2010). Gestión Integrada de la calidad -Implanración, control y certificación. Barcelona: Inmobi- liaria S.L. Hammer, M. y Champy, J. (1993). Reingenieria. Bogotá: Norma. Harmon, P. (2007). Business Process Change A guide for Business managers and BPM and Six Sigma Profesio- nals Second Edition. USA: MK. HITPASS, B. (2013). BPM Business Process management Fundamentos y Conceptos de Implementación 3ra. Edición actualizada y ampliada. Santiago de Chile: Edición hispana. John Jeston & Johan Nelis. (2008). Business Process Management. Practical Guidelines to Successful Imple- mentations. Sydney Australia: BPM Consultants. Molano, A. (2015). ¿Qué es Arquitectura Empresarial? Colombia Digital, 24-25. SIGMA, P. O. (15 de 07 de 2015). PAGINA OFICIAL ORGANIZACION SIX SIGMA. Obtenido de http://www.6sig- ma.com Tobón, L. F. (2012). Evolución de la Gestión por Procesos. Colombia: ICONTEC. 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). Guía de referencia de la Asociación Inter- nacional de Profesionales de BPM 3ra Edición. USA. Zachman, J. A. (1987). A. framework for nformation System Arqutecture. IBM System Journal, 3. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 93 AUTOevALUAciÓn de LA UnidAd ii Las preguntas siguientes le permitirán verificar su aprendizaje de esta unidad. Le recomiendo que las resuelva cuidadosamente. 1. ¿Que es Business Process Outsourcing (BPO)? a) La externalización de uno o más métodos de negocio incluyendo el de TI que los soporta. b) La externalización de uno o más procesos de negocio incluyendo el de TI que los soporta. c) La externalización de uno o más procesos de acción incluyendo el de TI que los soporta. d) La externalización de uno o más conocimientos de negocio incluyendo el de TI que los soporta. 2. ¿Que es Calidad?. a) Es una propiedad o un atributo del bien y el conjunto de propiedades definidas de forma que se pue- dan medir. b) Es una propiedad o un atributo del bien y el conjunto de propiedades definidas de forma que se pue- dan calcular. c) Es una pertenencia o un atributo del bien y el conjunto de propiedades definidas de forma que se puedan medir. d) Es una propiedad o un atributo del bien y el conjunto de propiedades definidas de forma que se pue- dan computar. 3. ¿Qué es Auditoría informática? a) Es un proceso de control para determinar si un sistema de información mantiene la realación de los datos b) Es un proceso de control para determinar si un sistema de información mantiene la integridad de los procesos. c) Es un proceso de planificación para determinar si un sistema de información mantiene la integridad de los datos d) Es un proceso de control para determinar si un sistema de información mantiene la integridad de los datos 4. ¿Como se define ITIL (Information Technology Infrastructure Library)? a) Es un modelo referencial de buenos procesos para la gestión de servicios de tecnologías de la infor- mación en operaciones. U N id a d ii t eM a N ° 2 94 b) Es un modelo referencial de buenas prácticas para la gestión de servicios de tecnologías de la infor- mación en operaciones. c) Es un proceso referencial de buenas prácticas para la gestión de servicios de tecnologías de la infor- mación en operaciones. d) Es un modelo referencial de buenas prácticas para la organización de servicios de tecnologías de la información en operaciones. 5. identifica el concepto «time to market» a) 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. b) 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 compra. c) El proceso que se requiere para introducir un nuevo producto o servicio (innovación) al mercado des- de que es concebido hasta que esté disponible para la venta. d) La metodología 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. 6. Los Drivers externos son: a) Factores que impactan desde dentro a la organización y ésta no los puede influenciar, pero si debe responder a ellos. b) Factores que impactan desde afuera a la organización y ésta no los puede influenciar, pero si debe responder a ellos. c) Procesos que impactan desde afuera a la organización y ésta no los puede influenciar, pero si debe responder a ellos. d) Técnicas que impactan desde afuera a la organización y ésta no los puede influenciar, pero si debe responder a ellos. 7. ¿Cuál es el objetivo de la capa de SOA? a) Diseñar una arquitectura de hardware basada en el concepto de servicios para implementar técnica- mente los procesos de negocio. b) Diseñar un proceso de software basada en el concepto de servicios para implementar técnicamente los procesos de negocio. c) Diseñar una arquitectura de software basada en el concepto de servicios para implementar técnica- mente los procesos de la organización. d) 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. U N id a d ii teM a N ° 2 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 95 8. Es un marco estructural que define los modelos, los tipos de objetos perteneciente a un modelo, las rela- ciones 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. a) Framework b) La Relación AE & BPM & SOA c) EA. d) BPM 9. Los Tres Niveles lo define Definición de requerimientos Diseño y especificación Implementación a) FEA (Federal Enterprise Architecture). b) ARIS (Architecture of Integrated Information Systems) c) Enterprise Architecture as Strategy (Ross et al). d) TOGAF (The Open Group Architecture Framework) 10. Es un modelo que define los mecanismos de gobernancia que asegure que los proyectos de BPM y de TI cumplan con los objetivos de negocio en todos los niveles de la organización. a) Arquitectura Empresarial b) Modelo de BPM Governance. c) Modelo Operacional d) La capa de SOA (Gobernabilidad de servicios) 96 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 97 UNIDAD III BUSineSS PROceSS MAnAGeMenT (BPM) Y eL MOdeLAdO BUSineSS PROceSS MOdeL And nOTATiOn (BPMn) diAGRAMA de PReSenTAciÓn de LA UnidAd iii Al finalizar la unidad, el estudiante será capaz de diseñar un modelo de proceso, utilizando los elementos de notación de BPMN, para un caso de estudio de la realidad.. 98 CONTENIDOS ACTIVIDADES FORMATIVAS (hAbILIDADes yAcTITUDes) SISTEMA DE EVALUACIÓN (TécNIcAs y cRITeRIOs) Tema N° 1 : Bussiness Process Model y la Notación BPMN 1 Evolución de Business Process Model and Notation (BPMN). 2 Los elementos bási-cos de BPMN. 3 Diferentes vistas de un proceso. 4 Un proceso simple en BPMN 5 Participantes y flujos de mensajes. • Reconocer el origen y evolución del BPMN Y analizar la importancia de sus elementos bá-sicos. Desarrolla una prueba mixta aplicada al tema. • Aplicar la notación BPMN a diferentes si-tuaciones de estudio, Diseña un modelo de proceso utilizando los elementos de la notación BPMN. Procedimientos e indicadores de evaluación permanente: • Entrega puntual del trabajo realizado. • Calidad, coherencia y Pertinencia de contenidos desarrollados: Individual o equipo. • Prueba teórico-práctica individual. • Actividades desarrolladas en sesiones Tutorizadas. Criterios de evaluación para el modelado del caso: (RÚBRICA) • Propuesta de modelo • Cantidad de participantes • Uso de los elementos de la notación • Coherencia en el proceso RECURSOS: Videos: Tema Nº 1: • Video Presentamos Visagi Studio https://www.youtube.com/watch?v=tORvGT7-1pQ Tema Nº 2: • Video Presentamos Bizagi Modeler https://www.youtube.com/watch?v=QJfv-oJ5jcY DIAPOSITIVAS ELABORADAS POR EL DOCENTE: Lectura complementaria: Lectura Seleccionada Nº 1 La Notación en Detalle- AUTOR: Jackob Freund pag. 40-41 Lectura seleccionada N°2 Caso de Estudio: Proceso de Contratación de Personal- Autor . (Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014) pag. 140 INsTRUMeNTO De eVALUAcIóN Rúbrica para evaluar el organizador del conocimiento Prueba Mixta N° 3 bIbLIOgRAFíA (básIcA y cOMpLeMeNTARIA) BASICA HITPASS, Bernard, BPM: Business Process Management Fundamen-tos 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. RecURsOs eDUcATIVOs DIgITALes Qué es un BPM [en línea]. [Consulta: 03 de junio de 2015] Disponible en Web: http://downloads.tuxpuc.pucp.edu.pe/linuxweek2012/03_Miercoles/01_Fernando-Espinoza. pdff U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 99 TeMA n° 1: BUSSineSS PROceSS MOdeL Y LA nOTAciÓn BPMn Apreciados estudiantes esta unidad tiene como objetivo mostrar las diferentes técnicas de modelado de procesos que se han ido desarrollando a través del tiempo, describirlas y compararlas con los requerimientos del BPM actual. Se analiza la importancia que han tenido estas técnicas en los ciclos evolutivos de la ingeniería y la relevancia que puedan tener actualmente, sobre todo si la evolución ha separado en la última década las técnicas para modelar sistemas (ingeniería de software) de las técnicas para modelar procesos de negocio (ingeniería de procesos). 1.1 evolución del Business Process Model and notation (BPMn) (Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014) 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. Desde un principio, el principal objetivo fue disponibilizar una notación gráfica, estandarizada, que per- mitiera 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 pro- veedores 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 (Object Management Group, 1997-2015)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. Es importante saber qué hay detrás o qué significa este misterioso acrónimo BPMN, se lo puedo explicar: BPMN es una especificación que se encuentra documentada en un manual no muy fácil de entender y que lo puede bajar sin costo alguno como PDF del sitio web de la OMG. En la versión 1.2 consta de 320 páginas y la versión 2.0 de más de 500 páginas. Ambas versiones sólo están disponibles en el idioma inglés. Todos los objetos, sus descripciones y sus respectivas reglas de utilización, se encuentran definidos en estos documentos. 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 meta- modelo 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: Para las organizaciones aumenta el grado de independencia de las herramientas de BPM, porque si cambian de herramientas no tienen que volver a capacitar en otras notaciones. 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 profesiona- les 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. U N id a d ii i t eM a N ° 1 100 1.2 Los elementos básicos de BPMn Cualquier objeto que se utilice de BPMN en sus diagramas, puede relacionarse con las categorías mostradas en la Ilustración 34. A estas categorías se les llama en BPMN elementos básicos de la notación. A los tipos de objetos actividades, gateways (compuertas) y eventos se les denomina en BPMN objetos de flujo y se conectan por medio de un flujo de secuencia, pero sólo dentro de un pool, o lanes dentro de un pool. Si se requiere una relación entre dos o más pools se utilizan flujos de mensaje. Además, existen objetos llamados «artefactos» los cuales enriquecen de información la descripción de un pro- ceso, pero los cuales no tienen ninguna influencia en la lógica del proceso. Cada artefacto puede relacionarse con cualquier objeto de flujo a través de objetos del tipo «asociación». También está permitido utilizar símbolos propios como artefactos. En BPMN 2.0 se incluyó una nueva categoría de objetos, la categoría datos. Si en un proceso es importante mostrar cómo va cambiando de estado (información) un objeto de negocio (so- licitud, contrato etc.) podemos utilizar el objeto de datos y relacionarlo con el objeto de tipo «asociación» a las actividades. Ocasionalmente también se puede asociar a otros tipos de objetos de flujo. Pues bien, se podría terminar aquí diciendo que este es el esquema básico de BPMN, pero en realidad faltan algunas consideraciones importantes para entender BPMN:• Las reglas sintácticas que se esconden detrás de este simple esquema • La clasificación de los objetos • Responder a las preguntas de cómo se utiliza toda esta combinatoria en proyectos reales Ilustración 34. Elementos básicos de BPMN Fuente: HITPASS, 2013 U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 101 1.2.1 Actividades simples y eventos indefinidos La figura 35 muestra un proceso muy simple. El proceso es gatillado cuando alguien manifiesta su hambre, por lo que gatilla la actividad de comprar alimentos y en secuencia lógica le sigue la acti- vidad de preparar una cena. Al final la cena se lleva a cabo y los participantes se manifiestan satisfechos. En este diagrama podemos identificar fácilmente los siguientes objetos y su semántica: Ilustración 35. Nuestro primer proceso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Actividades: Las actividades son la espina dorsal de los procesos, debido a que son las actividades las que transforman el estado de un objeto de negocio para que el proceso puede llegar a producir valor para los clientes. Las actividades se pueden definir como «acción sobre un objeto», es decir una actividad se denomina siempre con un verbo (acción) y un sustantivo (objeto). Por ejemplo «comprar alimentos» y no «primero hay que comprar los alimentos». Eventos: Eventos indican que al inicio, en forma intermedia o al final del proceso algo significativo ocurrió. Por el momento hablaremos sólo de eventos indefinidos, más adelante vamos a conocer otros tipos de eventos. 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 represen- ta 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.Junto a esta clasificación fundamental tenemos otros aspectos que diferenciar en los eventos: Eventos de inicio son eventos de captura (en inglés: catching events), es decir algo independiente del proceso ocurrió, pero el proceso tiene que reaccionar o esperar. Eventos intermedios pueden ser del tipo de captura o pueden ser impulsados por alguna actividad del mismo proceso (en inglés: throwing events). El evento intermedio indefinido representa un estado intermedio que ha alcanzado un proceso, por consiguiente se trata de un evento del tipo impulsado. Más adelante vamos a conocer otros tipos de eventos intermedios, los cuales vamos clasificar como del tipo de captura. U N id a d ii i t eM a N ° 1 102 Eventos finales ocurren de forma que el proceso ya no puede reaccionar a ellos, por lo tanto los clasificamos como del tipo impulsados. Eventos representan ocurrencias, es decir algo ocurrió (tiempo pasado)en forma independiente del proceso o bien eventos impulsados por alguna actividad del proceso. Debido a esta definición denominamos los eventos con el objeto y ocupamos el verbo en participio, por ejemplo «orden recibida». La especificación de BPMN no obliga usar un evento de inicio y de fin, usted los puede omitir. Pero si decide utilizar un evento de inicio está obligado a usar uno de término y vice versa. Nosotros utilizamos siempre eventos de inicio y de fin, porque de esta forma podemos retener la causa del inicio y podemos indicar las diferentes trayectorias como termina. Sólo en los subprocesos desistimos de esta posibilidad, pero más adelante explicaremos por qué. Flujo de Secuencia: El flujo de secuencia describe la secuencia temporal y lógica en el cual se combinan los elementos de flujo, es decir las actividades, eventos y Gateways (los cuales explicaremos en seguida). El flujo de secuencia es también la trayectoria del proceso por el cual marcha el token. El token «nace» junto a una instancia con el evento de inicio. A través del flujo de secuencia se llega a las actividades, a los estados intermedios y al evento final, donde es «consumido» y desaparece, al mismo tiempo «muere» nuestra instancia. Si usted quiere, puede diagramar los modelos de procesos en forma vertical (hacia abajo), en vez de como en todos nuestros ejemplos en forma horizontal. No es normal diagramar la línea de tiempo hacia abajo, pero no está prohibido. Nosotros Indicamos la línea de tiempo, como la mayoría, de izquierda a derecha. 1.2.2 Flujo de Procesos con Gateways Gateway exclusivo de datos (XOR) Casi ningún proceso tiene un flujo uniforme. En la mayoría de los casos, las instancias recorren diferentes tra- yectorias, dependiendo de las condiciones y reglas que apliquen. En nuestro ejemplo simple ilustración 36 queremos entretenernos con el arte de cocinar. Impulsados por el hambre, pensamos que queremos comer hoy. Debido a que sólo conocemos tres recetas, nos decidimos por una de ellas, que puede ser cocinar pasta, freír un steak (trozo de carne frita) o preparar una ensalada. Estas tres posibilidades son excluyentes, es decir sólo una opción es válida. Usted pensará ¿pero y si queremos un plato de fondo y la ensalada también? ¡Tenga paciencia ya hablaremos al respecto! U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 103 Ilustración 36. XOR-Gateway o gateway exclusivo de datos Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 La compuerta en que tenemos que tomar la decisión en BPMN se denomina Gateway. Como esta decisión la tomamos de acuerdo a la información recibida (la receta escogida) y la compuerta permite recorrer sólo una alternativa, hablamos de un «Gateway exclusivo de datos», también en forma abreviada de un «Gateway XOR» (XOR = Exclusive OR). ¡Cuidado, 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 Ga- teway. Esto parece ser un principio diferenciador común, pero a usted no se le olvide cuando esté modelando Nuestro Tip en BPMN Sobre el Gateway posicionamos la pregunta sobre la cual tiene que tomarse la decisión. Los diferentes respues- tas que pueden darse la posicionamos en los flujos de salida que se dan. La especificación indica que sólo los flujos deben nombrarse. La pregunta aclaratoria es parte de nuestra recomendación. La cantidad de flujos de salida es según la especifi- cación ilimitada y no importa donde se posicionen estos flujos, en el vértice o arista del Gateway. En BPMN existen para el XOR-Gateway dos símbolos que tienen el mismo significado (ver ilustración 37). En este libro ocupamos el símbolo que contiene el «X» porque lo consideramos más expresivo, pero usted puede escoger el que mejor le parezca o el que apoye su herramienta. De todas formas no recomendamos mezclar ambos símbolos en los diagramas; decídase a utilizar uno de ellos por convención. Ilustración 37. Símbolos equivalentes a XOR-Gateway Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 U N id a d ii i t eM a N ° 1 104 No es inusual que un proceso tenga varios eventos de término, como en la ilustración 36. En este caso el proceso puede producir tres estados diferentes de término. En diagramas complejos ayuda bastante a comprender que un proceso puede terminar con diferentes estados. Más adelante vamos a conocer otras razones de porque tiene mucho sentido emplear diferentes eventos de término. Si los diferentes recorridos tienen su término individual o si hay que unirlos a un término común depende de la lógica del proceso. BPMN permite ambas situaciones. Si queremos unir los recorridos porque le sigue una actividad que debe emplearse para todos los estados anteriores también podemos usar el XOR-Gateway como unión técnica. La unión técnica asegura que el token que viene de cualquiera de los recorridos, sea guiado haciaun flujo común (ver ilustración 38). Ilustración 38. Modos de utilización de XOR-Gateway Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 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 (vea ilustración 39). Ilustración 39. Utilización de XOR-Gateway como a) XOR-Split y XOR-Join de forma separada Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Seleccionar receta Cocinar pasta Comer preparación Freir Steak Preparar ensalada Deseo de comer ¿Tipo de comida? Plena satisfacción Pasta Steak Gateway exclusivo de datos (del tipo de unión) Ensalada Gateway exclusivo de datos (del tipo de unión y bifurcación) Gateway exclusivo de datos (bifurcación) Gateway exclusivo de datos (unión) ¿K valido? ¿x valido? = a) b) Si Si... ...... ... ... ...... ... ... ... ... ... No No U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 105 Si quiere utilizar esta posibilidad de modelamiento para compactar sus diagramas, tiene que decidirlo usted. Nosotros desistimos de esta posibilidad y usamos mejor dos XOR-Gateways seguidos para evitar interpretaciones ambivalentes. Gateway paralelo ¿Cómo podemos modelar el caso que queremos la ensalada como acompañamiento?. Representemos el caso más sencillo que queremos, el acompañamiento de todas formas, entonces podemos modelar el proceso como muestra la ilustración 40. Ilustración 40. Preparación de ensalada y plato de fondo Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 En esta ocasión aprovechamos de incluir un nuevo objeto, el comentario de texto. Este objeto pertenece a la categoría de los «artefactos», el que podemos asociar a cualquier objeto de flujo (en este caso a una actividad). En este ejemplo indicamos el tiempo promedio que demora cada actividad. La suma de los tiempos de cada una actividad nos arroja el tiem- po de ciclo del proceso completo, en este caso 48 minutos, si nos decidimos por cocinar pasta y 43 minutos si nos decidimos por los steaks. ¡Felicitaciones!, acaba de realizar su primer análisis de indicadores de tiempo de ciclo. Según este proceso, requerimos entonces de 23 a 28 minutos, hasta que podamos sentarnos a comer. Si tuvieramos mucha hambre, podría volverse un calvario tener que esperar tanto para comer. ¿Qué podemos hacer? Lógicamente un rediseño del proceso. Podríamos pensar en paralelizar la preparación de la comida y de esta forma acelarar el proceso en general, es decir preparar la ensalada al mismo tiempo que el plato de fondo. El objeto que vamos a usar para este caso se denomina «AND-Gateway» el cual apreciamos en la ilustración 41. 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. El diseño de la ilustración 40 obliga a preparar la ensalada antes de comenzar a cocinar, lo que no necesariamente tiene que ser así, por ejemplo mientras la pasta está en la olla, podemos preparar la ensalada. De acuerdo a nuestro nuevo cálculo podríamos acortar el tiempo Seleccionar receta Preparar ensalada Cocinar pasta Freir steak Comer preparación Deseo de comer [3 minutos [10 minutos [10 minutos [15 minutos 20 minutos Plena satisfacción ¿Tipo de comida? Asociación Comentario Pasta Steak U N id a d ii i t eM a N ° 1 106 de ciclo en 10 minutos. Como usted se puede imaginar, este caso es clásico en la optimización de procesos, en el sentido de intentar de paralelizar al máximo posible. En el ejemplo descrito el proceso no sólo se paraleliza (AND-Split), sino que más adelante se sincronizan los dos flujos (AND-Join). La razón debería quedar clara: sólo al estar lista todas las preparaciones, podemos sentarnos a comer, de lo contrario y según el proceso iría- mos comiendo cada preparación en cuanto esté lista, lo que no tiene mucho sentido. Ilustración 41. Preparación de ensalada junto con plato de fondo Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 ¿Cómo se comportaría en una instancia de este proceso el concepto de token? El token nace con el evento de inicio, luego recorre la actividad seleccionar receta y llega al Gateway paralelo (AND-Split). En un Gateway paralelo se dividen (nacen) tantos token como salidas tiene la compuerta, en este caso son dos. El primer token se dirige al XOR-Gateway, en donde según la receta escogida la compuerta lo dirige a la actividad correspondiente; en este caso asumi- remos que será cocinar pasta en donde permanecerá 15 minutos (el tiempo de cocción). Al mismo tiempo el segundo token se dirige a la actividad preparar ensalada donde permanece 10 minutos, es decir el tiempo que nos demoramos en preparar la ensalada. Pasado estos 10 minutos se dirige al próximo AND-Join en donde es- pera 5 minutos hasta que llegue el token de cocinar pasta. Es decir la instancia espera en el AND-Join hasta que lleguen ambos token y los fusiona en uno sólo. Enseguida el token fusionado se dirige a la siguiente actividad. ¿Le parece esta descripción del token muy técnico o abstracto? En realidad no lo es, porque se comporta igual que en la realidad: La preparación de la ensalada se demora menos, entonces esperamos hasta que el proceso de cocinar la pasta haya concluido; recién entonces nos sentaremos a la mesa a comer todo lo preparado. ¿Por qué se necesita entonces el concepto del token? Piense entonces en el caso de los 90 millones de transac- ciones que se realizan al año en el registro de infracciones. Estas consultas no se realizan en forma secuencial, sino en forma concurrente, cada instancia con diferentes flujos. ¿Cómo podríamos reconstruir en caso de error las transacciones fallidas sin un concepto de token? ¿Se habrá dado cuenta que instancias y tokens no son lo mismo? En una instancia pueden haber varios tokens activos y fuera de registrar todo lo que sucede nos indican dónde y en que estado se encuentra la instancia. Seleccionar receta Cocinar pasta Comer preparación Freir steak Preparar ensalada Deseo de comida [3 minutos [10 minutos [10 minutos [15 minutos 20 minutos Plena satisfacción ¿Tipo de comida? Gateway Paralelo (paralelizar) Gateway Paralelo (sincronizar) Pasta Steak U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 107 En las siguientes dos preguntas de control queremos probar su grado de entendimiento con respecto al con- cepto de tokens. Pregunta 1: En la ilustración 42 le mostramos el mismo proceso descrito anteriormente, pero hemos eliminado el AND-Join y el flujo de la actividad preparar ensalada se dirige ahora directamente al XOR-Join. ¿Cómo reaccio- na el proceso si creamos una instancia (nos decidimos por cocinar pasta)? Ilustración 42. Caso And-Split sin And-Join Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Respuesta: 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 eje- cuta la tarea, es decir la ensalada se consume sin esperar la pasta. Lo mismo ocurre cuando más tarde la pasta stá lista, es decir la actividad comer preparación se ejecuta dos veces, no es precisamente el comportamiento que esperábamos. Pregunta 2: En la ilustración 43 verá un proceso con sólo dos actividades. El proceso es instanciado. ¿Cuanto tiempo «vive» la instancia? Respuesta: La instancia «vive» 45 días, que corresponde con el tiempo de ciclo del proceso. 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. Ilustración 43. Revisión de tiempo de duración de instancias con AND-Split Fuente:Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Seleccionar receta Cocinar pasta Comer preparación Freir steak Preparar ensalada Deseo de comer [3 minutos [10 minutos [10 minutos [15 minutos 20 minutos Plena satisfacción ¿Tipo de comida? Pasta Steak Actividad 1 Actividad 2 Inicio [30 días [45 días Fín Fín U N id a d ii i t eM a N ° 1 108 Recuerde: Mientras exista en un proceso un token activo, vive también la instancia del proceso. Recién cuando «todos» los tokens se hayan consumido, termina o muere la instancia Gateway inclusivo de datos (OR) Para explicar este Gateway más complejo, vamos a ampliar nuestro ejemplo y suponer que queremos diseñar nuestro proceso menos rígido o dicho de otra forma más flexible. Si se da el deseo de comer, queremos modelar la siguiente situación: sólo preparar una ensalada o, una ensalada y un plato de fondo, que podría ser pasta o steak o alguna otra com- binación Con los tipos de objetos que usted conoció anteriormente, podría modelarse como lo muestra la ilustración 44. Si queremos modelarlo en forma más compacta, podemos utilizar el Gateway inclusivo de datos, también llama- do OR-Gateway (vea ilustración 45). 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. Es decir esta compuerta la podemos utilizar para reducir la complejidad y reemplazar preguntas sofisticadas en la combi- nación de los XORGateway y el AND-Split Gateway. El OR-Gateway también lo utilizamos como unión técnica de todas las combinaciones que se pueden dar con las instancias. Ilustración 44. Diferentes opciones en la selección de nuestra cena Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Seleccionar receta Cocinar pasta Comer preparación Freir steak Preparar ensalada Deseo de comer Plena satisfacción [3 minutos [10 minutos [10 minutos [15 minutos [20 minutos ¿Otra combinación? ¿Tipo de comida? Pasta Steak ¿Ensalada deseada? X 9 X 9 X 9 U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 109 Ilustración 45. Utilización de OR-Gateway como OR-Split y OR-Join Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 En ambos modelos existe si una diferencia semántica. En la ilustración 44 tenemos la posibilidad de no preparar la ensalada, como también de no escoger ningún plato de fondo, posibilidad que no se da en el modelo de la ilustración 45, pero en el primer caso este posible flujo lleva también al absurdo porque tiene que pasar por la última actividad que obliga a comer lo preparado, a pesar que se desistió de preparar algo para comer. En el caso del OR-Gateway este caso sin sentido no se da, porque la lógica obliga a decidirse por alguna de las alternativas propuestas. Una simulación por medio de Token, arrojaría en el primer caso un error porque la última actividad no puede ser ejecutada. Este es un caso sencillo, pero en lógicas complejas ha de tenerse cuidado con el uso del OR-Gateway, sobre todo con las reglas de sincronización, porque pueden darse constelaciones en que no se puede testear fácilmen- te toda la casuística. Analicemos como ejemplo el caso en la ilustración 46. Dependiendo si después del OR-Split se recorren uno o más flujos, el OR-Join debe sincronizar o no. Ilustración 46. Revisión de tiempo de duración de instancias con OR-Gateway en el Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Seleccionar receta Cocinar pasta Comer preparación Freir steak Preparar ensalada Deseo de comer [3 minutos [10 minutos [10 minutos [15 minutos 20 minutos Plena satisfacción ¿Componentes deseadas? ¿Tipo de comida? Gateway inclusivo de datos (bifurcador paralelizador) Gateway inclusivo de datos (unir, sincronizar) PastaOtro plato Steak Ensalda Actividad 1 Actividad 2 Actividad 3 Deseo de comer [30 días [45 días Plena satisfacción Fín 1 era pregunta 2 da pregunta Respuesta 1 Respuesta 1 Respuesta 2 Respuesta 2 U N id a d ii i t eM a N ° 1 110 En la ilustración 46 llega el primer token a los 30 días al OR-Join. Suponiendo que también fue válida la respuesta 2 en el OR-Split, se generó un segundo token que aún permanece 15 días en la actividad 2. Ahora puede suceder que terminada la actividad 2 la decisión en el XOR-Split sea la respuesta 1 y el segundo token sea consumido por el evento de fin. ¿Qué pasa ahora con el primer Token que se queda esperando el la sincronización en el OR-Join? El OR-Gateway tiene que registrar, que el segundo token fue consumido y liberar el primero para que pueda continuar el proceso. Si se da un caso como este, la especificación no sabe como resolverlo y arroja un error tipo «exception». Al lector no podemos más que aconsejarle de usar con mucho cuidado el OR-Gateway y si lo hace debe comprobar por medio del concepto de Token, que la casuística no lleve en algunos casos al absurdo. Sigamos con nuestro caso de cocina y tratemos de modelar todas las opciones de las que hablabamos anterior- mente. Si usamos el OR-Gateway tenemos muchas opciones de combinación como lo muestra la ilustración 47, pero también se dan algunas casos absurdos o que no queremos representar. Ilustración 47. Una versión compacta con muchas opciones Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 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. Las últimas dos alternativas no corresponden con lo que queremos representar o modelar. 1.2.3 Lanes Hasta el momento hemos hablado sólo como fluye el proceso o «qué» es lo que hay que hacer en el proceso, pero 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. En la ilustración 48 vemos en nuestro ejemplo que a las actividades se le han asignado nombres de personas. De acuerdo a esta nomenclatura podemos deducir que si Cristian tiene deseo de comer, selecciona una receta en su libro de cocina. De acuerdo al modelo presentado, él sólo cocina pasta, pero si quiere freír steaks, tendría que invitar a otro amigo para que cocine. Según el modelo, al término del proceso de cocina, Cristian puede comerse la preparación. Las tres personas que aparecen en este modelo comparten este proceso en una resi- Actividad 1 Cocinar pasta Cocinar pasta Cocinar pasta Actividad 3 Deseo de comer [3 minutos [16 minutos [10 minutos [10 minutos [20 minutos Plena satisfacción ¿Tipo de comida? Steak Ensalada Pasta U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 111 dencia, quienes al mismo tiempo representan los posibles participantes del proceso descrito. En BPMN se les denomina a estos participantes «pools». En este ejemplo asignamos lanes a personas, pero la especificación de BPMN no hace ningún tipo de clasifica- ción al respecto. Por lo general se usan lanes en la práctica para: Cargo de algún área (como gerente, supervisor, etc.) Roles (como auditor, usuario de negocio, ejecutivo, etc.) Roles generalizados (como cliente, proveedor, fiscalizador, etc.) Departamentos (como contabilidad, ventas, etc.) Aplicaciones o sistemas (como CRM, SAP, etc.) Ilustración 48. Utilización de Lanes Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 El término «lane» tiene su historia en las notaciones de modelamiento de procesos. Muchas notaciones se han apoyado de esta forma de representar participantes en los modelos de procesos. El término se utilizó en analogía a los carriles en las piscinas de natación, en el cual cada nadador tiene su propio carril, separado por las bandas de boyas flotantes. En la versión anterior a BPMN 2.0 también se podía estructu- raruna jerarquía de lanes dentro de un poolcomo lo muestra la ilustración 49. Ilustración 49. Estructura jerárquica de lanes Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Seleccionar receta Cocinar pasta Freir steak Preparar ensalada Comer preparación Deseo de comer Pasta ¿Comida con o sin ensalada? ¿Tipo de comida? Plena satisfacción C ris tia n Fa lk o R es id en ci a R ob er to Steak Ensaldada Lane Actividad 1 Actividad 2 Actividad 3 Actividad 4 Inicio La ne 1 La ne 2 Po ol La ne 3 La ne 3 .2 La ne 3 .1 U N id a d ii i t eM a N ° 1 112 En la práctica a veces no es fácil encontrar la estructura adecuada de lanes. Seguramente en nuestro ejemplo reciente ya se dio cuenta, que Cristian invita a cocinar pero no a comer, pero el modelo final que queremos re- presentar es que todos los participantes vayan a cenar juntos. 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. Ilustración 50. Uso incorrecto de actividad en Lanes Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 La solución para este escenario, sería crear la actividad tantas veces como personas participan en la cena (ver ilustración 51). Esta forma de representación corresponde también con la realidad, porque cada persona come en su plato, pudiendo terminar unos antes que otros. Ilustración 51. Uso correcto de actividad en lanes Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Seleccionar receta Cocinar pasta Freir steak Preparar ensalada Deseo de comer Pasta ¿Comida con o sin ensalada? ¿Tipo de comida? Plena satisfacción C ris tia n Fa lk o R es id en ci a R ob er to Steak Ensaldada ERROR Esta forma de representación no esta permitida Comer preparación Seleccionar receta Cocinar pasta Freir steak Preparar ensalada Deseo de comer Pasta ¿Comida con o sin ensalada? ¿Tipo de comida? Plena satisfacción Plena satisfacción Plena satisfacción C ris tia n Fa lk o R es id en ci a R ob er to Steak Ensaldada Comer preparación Comer preparación Comer preparación U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 113 Qué hacer o cómo representar cuando un grupo de personas trabaja en una tarea en conjunto, como es el caso de las comisiones, comités, directorios etc. Para estos casos se recomienda crear un lane propio con el nombre del grupo. Cabe recordar que los diagramas y ejemplos de lanes presentados en este libro corresponden a la nueva espe- cificación de BPMN 2.0 en donde ya no se ilustración 52). Ilustración 52. Estructura de lane prohibida a partir de la versión BPMN 2.0 Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 1.2.4 eventos Con las actividades y los Gateways conocimos dos de los tres elementos de flujos en BPMN: Las tareas (activi- dades) cambian el estado de un objeto, bajo ciertas condiciones (Gateways). Uno de los elementos principales de flujo que nos falta conocer son cosas que ocurren (eventos). Estos elementos de flujo no son de menor im- portancia que las actividades o los Gateways en BPMN. Existen varios tipos de eventos: los eventos: Eventos de captura y eventos disparadores Eventos de inicio, even- tos intermedios y eventos de término 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 (nuevo en BPMN 2.0). Los eventos del tipo disparador se les denomina en BPMN «throwings events» e indican eventos creados den- tro 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). Actividad 1 Actividad 2 Actividad 3 Actividad 4 Inicio La ne 1 La ne 2 Po ol La ne 3 La ne 3 .1 La ne 3 .2 Esta linea o enmarcación solo estaba permitida hasta la versión 1.2 de BPMN U N id a d ii i t eM a N ° 1 114 Podemos clasificar entonces todos los eventos de inicio como eventos de captura. Sería contradictorio si un proceso pudiese crear un evento antes que haya sido iniciado. La forma más sencilla de representar un evento de inicio lo podemos apreciar en la ilustración 53. Apenas ocurra el evento, el proceso se inicia. Ilustración 53. Un evento gatillante de proceso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Cabe recordar que el signo de interrogación indica que este evento podría obedecer a una clasificación deter- minada por BPMN. Hasta el momento hemos conocido sólo los eventos del tipo indefinido, pero más adelante vamos a conocer como BPMN clasifica eventos. También es posible que varios eventos puedan iniciar un proceso, como lo muestra la ilustración 54. Es impor- tante entender que cada evento inicia una nueva instancia de proceso. Ilustración 54. Dos eventos que independientemente pueden gatillar un proceso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Ilustración 55. Dos eventos que producirían un punto muerto (deadlock) en interpretadores de BPMN Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Si quisieramos modelar el caso que varios eventos tienen que suceder para que pueda iniciarse el proceso, mu- chos analistas lo representarían en forma intuitiva como muestra la ilustración 55. Desgraciadamente esta no es la forma verdaderamente correcta de representar este patrón en BPMN. Para que un proceso que está en espera pueda continuar, puede hacerse necesario que ocurra un evento intermedio, como lo muestra la ilustracion 56. El flujo se interpreta de la siguiente forma: Si la actividad 1 ha terminado, tiene que ocurrir primero el evento 1, antes que puede iniciarse la actividad 2. De acuerdo a nuestro concepto de token, espera el token tanto tiempo en el evento 1 hasta que ocurra y sólo al finalizar el token sigue su camino y gatilla el inicio de la actividad 2. El evento 1 de la ilustración 56 pertenece a la categoría de eventos del tipo disparador y no a los de captura. Actividad 1 Evento 1 ? ... Actividad 1 Evento 1 Evento 2 ? ? ... Actividad 1 Evento 1 Evento 2 ? ? ... U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 115 Ilustración 56. Utilización de evento intermedio Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Pero, ¿cómo podemos ahora representar que un proceso tiene que esperar la ocurrencia de dos eventos? No se le ocurra modelarlo como muestra la ilustración 57. ¿Por qué? Cuando la actividad 1 haya concluido, el token avanza hacia el evento 1 y espera que este ocurra. Supongamos ahora que el evento 2 sucede antes que el evento 1, entonces al ocurrir más tarde el evento 1, el token avanza al evento 2 y espera que este suceda, a pesar que ya ocurrió. Como el evento 2 ya se «esfumó», el token quedará indefinidamente esperando que este suceda, lo que técnicamente produciría un deadlock. Po- dríamos admitir que usuarios de negocio lo interpretarían bien, si modelamos así el caso, pero técnicamente el concepto de token no lo puede interceptar, por lo que se haría necesario cambiar el diseño en el modelo técnico. Si necesitamos modelar el caso de tener que esperar la llegada de dos eventosque suceden en forma indepen- diente, y cuya condición es necesaria para que continue el proceso, lo modelamos como muestra la ilustración 57. Ilustración 57. Utilización de dos eventos intermedios continuos Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Ilustración 58. Utilización de AND-Gateway con eventos intermedios Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 En BPMN también podemos representar casos en que existe un flujo normal, pero puede ocurrir un evento in- esperado que interrumpa una actividad o un subproceso. A estos eventos intermedios se les llama «sobrepues- tos» (en inglés: attached), ya que van superpuestos a un costado de la actividad (ver ilustración 59). Si sucede un evento de este tipo, interrumpe la marcha de la actividad, cualesquiera que sea su estado intermedio. En este caso el token tendría el siguiente comportamiento: 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. Actividad 1 Actividad 2 Evento 1 ?... ... Actividad 1 Actividad 2 Evento 2Evento 1 ??... ... Actividad 1 Actividad 2 Evento 1 Evento 2 ? ? ... ... U N id a d ii i t eM a N ° 1 116 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». En este caso el token tiene otro comportamiento como muestra la ilustración 60: El token inicia, como en el caso anterior, la actividad 1. Ilustración 59. Utilización de evento intermedio y sobrepuesto (attached) Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 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 ejecu- tada. 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, igual que en el caso anterior. Ilustración 60. Utilización de evento intermedio y sobrepuesto del tipo “no interrupción” Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Eventos intermedios del tipo «disparador» son gatillados por el proceso mismo, es decir un token que llega a un evento de este tipo, lo gatilla y avanza inmediatamente al siguiente elemento en el flujo. Eventos del tipo disparador, no interrumpen una actividad, razón por la cual nunca se deben sobreponer en un objeto, sino que deben usarse asociados al flujo de secuencia. Hasta ahora conocemos el evento intermedio del tipo indefinido, con el cual podemos indicar que hemos alcanzado un estado. También este caso es un evento del tipo disparador. Existen diferentes tipos de eventos que se pueden utilizar en BPMN: Actividad 1 Actividad 2 Actividad 2 Evento 1 ? ... ... ... Actividad 1 Actividad 2 Actividad 2 Evento 1 ? ... ... ... U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 117 Eventos de mensaje Eventos de tiempo Eventos de error Eventos de condición Eventos de señal Eventos de término Eventos de conexión (link) Eventos de compensación Eventos múltiples Eventos de cancelación 1.2.5 Subprocesos Reducción de complejidad Los ejemplos que tratamos en este libro los mantenemos sencillos con una doble finalidad, primero por aspec- tos pedagógicos y segundo para que alcancen en una hoja de libro. Si nos transportamos a la realidad, no nos podemos permitir este lujo. Usted tiene que cumplir con el desafío de mantener por un lado los mapas de procesos abstraídos de la com- plejidad con el fin de no perder la visibilidad y por el otro lado tiene que describir toda la lógica operacional en detalle para que puedan ser implementados y para identificar potenciales de mejora. Justamente el juego entre descomposición top-down y agregación bottom-up distingue buenos modelos de procesos de diagramas de flujo banales y también buenas herramientas de BPM de herramientas triviales. En BPMN tenemos para estos fines el objeto de flujo llamado subproceso. Un subproceso describe en su inte- rior 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 (ver ilustración 61). Tenemos que admitir que un buen balanceo de diferentes niveles de abstracción, depende fuertemente de como una herramienta de BPMN apoye las siguientes funcionalidades: 1. Representación del subproceso en un diagrama propio: El signo (+) debe estar relacionado con un nuevo diagrama de proceso. Por ejemplo si su herramienta de BPMN trabaja full web, entonces podría abrir una ventana browser por cada diagrama (ver ilustración 62 en la página siguiente). Ilustración 61. Una actividad y un subproceso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 U N id a d ii i t eM a N ° 1 118 2. Expandir un subproceso en un mismo diagrama del proceso superior: La especificación de BPMN define un subproceso con el signo más (+), como un subproceso cerrado. El signo más indica que si uno hace clic sobre él, debería de expandirse o abrirse. la ilustración 63 muestra en forma ejemplar como BPMN indica que debería ser, pero por razones técnicas que vamos a ver más adelante, los proveedores de herramien- tas prácticamente no apoyan esta tecnología. A pesar de las buenas intenciones que pueden haber detrás de este objetivo, de expandir y comprimir los detalles de los modelos de los subprocesos, en la práctica esto no es viable para subprocesos complejos. Al expandir un subproceso tienen que reposicionarse todos los demás objetos del diagrama para hacer lugar al subproceso expandido. Como consecuencia, se debe disminuir el tamaño de los objetos tanto como tenga lugar el o los subprocesos expandidos, lo que tampoco puede ser el objetivo de los creadores de este concepto. Lo que si podemos hacer, y en la práctica se usa, es modelar subprocesos simples en forma expandida en el diagrama principal, de forma que no perturbe el orden del diagrama de flujo en ge- neral. Esto se hace en subprocesos que tienen eventos de excepción sobrepuestos. En ambos casos termina el flujo de secuencia del proceso superior en la línea izquierda del subproceso y conti- núa por fuera por el lado derecho, es decir el flujo de secuencia no debe ingresar al subproceso, lo que a algún principiante le cuesta entender cuando trabajamos con subprocesos expandidos. Si aplicamos el concepto de token, tendríamos el siguiente comportamiento: 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 tokendel subproceso. Ilustración 62. Caso con representación de subproceso en un diagrama propio por Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 119 Ilustración 63. Caso con representación de subproceso en el mismo diagrama principal del proceso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Cuando el subproceso gatilla su evento de finalización es consumido, el subproceso ha terminado y el token del proceso superior continúa hasta llegar a su propio fin. Lógicamente que la cantidad de niveles que puedan tener procesos superiores e inferiores (todos las jerarquías representadas a través de subprocesos) no se restringe sólo a dos niveles. El proceso superior puede a su vez ser subproceso, es decir inferior a otro superior, etc.. BPMN no hace ninguna limitación en cuanto a la cantidad de niveles de abstracción. BPMN permite también posicionar los eventos de inicio y de término de los subprocesos directamente en los límites del subproceso, como lo muestra ilustración 64. Lógicamente que esto sólo funciona si el subproceso se encuentra expandido en el proceso superior. En la práctica no conocemos herramientas que apoyen esta funcio- nalidad y nosotros tampoco vemos algún beneficio en este tipo de diagramación, por lo que tampoco lo reco- mendamos. Ilustración 64. Caso con posicionamiento de eventos de inicio y término en los límites del subproceso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 BPMN permite modelar sin eventos de inicio y de término. Uno podría aprovechar esta posibilidad para hacer más compactos algunos diagramas y convertirlos en subprocesos como muestra la ilustración 65. Un subpro- ceso también puede reemplazar una construcción de AND-Gateways como muestra la figura, pero nosotros no recomendamos esta práctica por los siguientes dos motivos: Actividad Actividad Actividad Inicio Inicio Fín Fín Subproceso Pr oc es o su pe rio r El signo menos no es parte del estándar, pero algunas herramientas lo realizan así Actividad Actividad Actividad Inicio Fín Subproceso Pr oc es o su pe rio r U N id a d ii i t eM a N ° 1 120 1. Aumenta el peligro que lectores que no sean expertos en BPMN se confundan. 2. Uno podría confundir rápidamente esta representación con los subprocesos del tipo ad-hoc, como lo va- mos a ver más adelante. Por otro lado, los subprocesos del tipo ad-hoc se emplean bastante en la práctica. Ilustración 65. Equivalencia entre a) Caso con utilización de AND-Gateway y b) Caso Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Como usted puede deducir hasta el momento, los subprocesos en BPMN no sólo se utilizan como medio de abstracción metodológica, sino también como medios y técnicas de diseño (estilo) de los diagramas. Las si- guientes secciones van a reforzar lo dicho. Modularizar y reutilizar En la versión anterior de BPMN 1.2 se diferenciaba entre subprocesos «incrustados» y subprocesos «reutili- zables». En un principio permanece aún esta diferenciación, pero con la salvedad que en BPMN 2.0 todos los subprocesos tienen la características de ser «incrustados» y sólo pueden tomar la propiedad como «reutilizable» si se declara como subproceso «global» y es referenciado como una actividad «invocable». A continuación nos referimos entonces a subprocesos incrustados y globales. Un subproceso incrustado sólo puede existir en un proceso superior, dicho de otra forma le pertenece al proceso superior. Un subproceso incrustado tampoco puede poseer pools o lanes propios, sino que sólo puede estar relacionado con el pool o lane en donde está asociado al proceso superior. Otra regla estricta es que un subpro- ceso incrustado sólo puede iniciarse con un evento indefinido, otros eventos de inicio como de mensajería o de tiempo no están permitidos. Dicho de otra forma, un subproceso incrustado, no es otra cosa que una especie de dominio delimitado (en inglés: «scope») dentro del dominio superior, que obedece a dos objetivos: 1. Abstracción de complejidad. 2. Una agrupación de actividades del proceso superior, al cual se pueden relacionar marcadores o eventos en general. Estos aspectos los vamos a tratar más adelante. En cambio subprocesos globales pueden reutilizarse en varios procesos superiores. U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 121 En los procesos industriales existen muchos subprocesos que se utilizan en forma global, como por ejemplo la adquisición de un artículo debido al pedido de un cliente o la reposición de stock de bodega. Otros ejemplo de subproceso global es la facturación representada en la ilustración 66, para la venta de productos o servicios de reparación. En este ejemplo también reconocemos que las actividades invocables están marcadas en su contorno con negrita. En diferencia a los subprocesos incrustados, los de tipo global no están ligados al proceso superior, por lo tanto si pueden poseer sus propios pools y lanes. Los subprocesos globales se pueden comparar con un servicio ex- terno (que también lo puede ser), es decir como una especie de «Shared-Service-Center». Ilustración 66. Ejemplos para la reutilización de subprocesos Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 El bajo acoplamiento de los subprocesos globales también se manifiesta en la forma de traspaso de datos a los procesos superiores. BPMN parte de la base que los procesos incrustados tienen acceso a toda la información requerida del proceso superior, en cambio para los subprocesos globales es necesario declarar la forma de traspaso de datos. Esto pareciera ser sólo un aspecto técnico, pero no lo es; también tiene una componente de negocio. Si le pedimos por ejemplo al departamento de finanzas que emita una factura, tenemos que enviarle los datos de facturación y estos en un formato estructurado como lo necesita el área de finanzas. Este formato estructurado se denomina en BPMN «data-mapping» o la interfaz de datos entre procesos superiores y sub- procesos globales. Hablando sobre estos aspectos, usted ya se habrá dado cuenta que BPMN al hacer estas Revisar disponibilidad Enviar perdida Gestión financiera Adquisición de artículo Adquisición de artículo Cotizar artículos Emisión de factura Gestión financiera Realizar reparación Orden de compra recibida Orden de reparación recibidaStock mínimo alcanzado Inicio Inicio Pago recibido Fecha de pago sobrepasada Artículo repuesto Fin Fin ¿Artículo disponible? Pr oc es o su pe rio r A dm in is tr ac ió n de a rt íc ul os Ta lle r de r ep ar ac ió n A dq ui si ci ón d e ar tíc ul os G es tió n fin an ci er a Si No Este no es un símbolo de BPMN, se utiliza solo para mostrar la relación entre los diagramas ... ... ... U N id a d ii i t eM a N ° 1 122 analogías trata de construir puentes entre el mundo de negocio y mundo técnico. ¿Cómo piensa BPMN lograr esta integración? BPMN intenta obligar al modelador a ser formal en su expresión. Si no fuese así, ¿cómo nos vamos a entender en nuestro mundo cada vez más integrado en sus procesos (complejos) y cambiantes? Propiedades de Subprocesos Las propiedades que pueden asumir actividades, como loop, instancias múltiples y compensación también aplican de igual forma para los subprocesos. De esta forma se pueden modelar loops complejos en forma más compacta como muestra la ilustración 67 en la cual ambos modelos son idénticos. La propiedad especial denominada «ad-hoc» sólo puede utilizarse en subprocesos, símbolo que se reconoce como una «tilde» que se posiciona al centro inferior del subproceso (ver ilustración 68 ). Las actividades o sub- procesos contenidos en un subproceso con propiedad de ad-hoc pueden: no terner una secuencia determinada en su ejecución,pueden ejecutarse n veces, o se ejecutan algunas o ningunade ellas. Ilustración 67. Equivalencia entre a) Subproceso con propiedad de loop y b) Flujo con actividades y XOR-Gateway que se comportan como loop Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Revisar disponibilidad Actividad 2 Actividad 1 Actividad 2 Actividad 5 Actividad 3 Actividad 4 Actividad 3 Actividad 4 Actividad 5 Inicio Inicio ¿Condición 1 valida? ¿Condición 1 valida? ¿Condición 2 valida? [Hasta que se cumpla condición 2 a) b) Fin Fin Si Si Si No No No U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 123 Ilustración 68. Caso con uso de subproceso con propiedad Ad-Hoc Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 La decisión de cuales de estas opciones se realizan, las toma el responsable o encargado del subproceso. De cierta forma esta componente nos lleva a pensar, que el modelamiento de procesos sería absurdo si tenemos este grado de libertad, pero la realidad nos muestra que existen muchos procesos, que requieren de este grado de libertad, porque dependiendo de la situación se necesita actuar de una forma u otra. Pensemos en los proce- sos clínicos de un hospital. Cuando usted entra a urgencia, el médico tiene que hacerle primero un diagnóstico y luego dependiendo de este resultado, lo va a derivar a una sección u otra. El flujo no está determinado y se va construyendo a medida que se va adquiriendo conocimiento sobre el caso. También puede darse el caso que un proceso, sea un candidato a estandarizarse pero que aún no se encuentre bien estructurado, entonces ¿Cómo representamos la situación actual si no existe un flujo pre determinado? BPMN 2.0 definió reglas sintácticas para el uso de subprocesos ad-hoc: Obligación: Deben existir al menos dos actividades o subprocesos Opcional: Objetos de datos, flujos de secuencia, asociaciones, agrupaciones, flujo de mensajes, Gateways y eventos intermedios Prohibido: Eventos de inicio y de fin, objetos de conversación y coreografía (definición de estos objetos más adelante) Considerando no infringir estas reglas se pueden modelar con subprocesos ad-hoc, procesos con poca o ningu- na estructuración (ver ejemplo en ilustración 69). Ilustración 69. Caso con uso de subproceso con propiedad Ad-Hoc con poca estructuración interna Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Revisar disponibilidad Crear manuscrito Estructurar contenido Investigar materia Desarrollar gráficos Relacionar gráficos y texto Revisión final Redactar contenido Demanda por libro técnico Definir aporte Instrucciones Ideas Figuras Borrador de texto Resultados de investigación Texto definitivo Obra terminada [Cada autor U N id a d ii i t eM a N ° 1 124 1.2.6 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. Comentarios y agrupación Existen dos tipos de artefactos que pueden servir para mejorar la interpretación y la legibilidad de los diagramas. El artefacto tipo «comentario» que se relaciona con los objetos de flujo por medio del elemento de asociación simple (línea interpunteada). En la ilustración 70 vemos el uso del artefacto tipo comentario para explicar donde se cocina y en qué lugar se realizará la cena, pero también para revelar el origen de la receta. Para demarcar el lugar donde se cocina y donde se realizará la cena ocupamos el elemento tipo agrupación, pero habrá que tener cuidado de confundir este signo de agrupación con uno del tipo subproceso abierto, que si tiene un significado en BPMN. El signo de agrupación lo puede ocupar libremente, incluso puede agrupar elementos que van más allá de los límites de uno o varios pools. El elemento de agrupación puede ser de gran utilidad para demarcar ciertos dominios en los procesos. Nosotros vamos a emplear a menudo este signo en los próximos capítulos, con la finalidad de explicar mejor nuestros ejemplos. Ilustración 70. Caso con utilización de Comentarios y Agrupaciones Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Artefactos y simbología propia La notación de BPMN también permite introducir simbología propia como artefactos. Con esta posibilidad se pueden enriquecer los diagramas con artefactos ilustrativos típicos de un negocio. En la ilustración 71 introdu- cimos en nuestro ejemplo una bicicleta para el servicio de entrega y un computador, para indicar los recursos que utilizan algunas actividades. Estos artefactos propios se relacionan igual que los demás, con el elemento de asociación a los objetos del modelo. Seleccionar receta Cocinar pasta Freir steak Preparar ensalada Comer preparación Comer preparación Comer preparación ¿Comida con o sin ensalada? ¿Tipo de comida? Plena satisfacción Plena satisfacción Plena satisfacción [En la cocina [En el comedor Deseo de comer C ris tia n Fa lk o R es id en ci a R ob er to Origen de la receta Comentario Agrupación Pasta Steak Ensalada U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 125 La posibilidad de usar artefactos propios depende de si las herramientas que está utilizando apoyan esta funcionalidad. Hasta el momento hemos visto pocas herramientas que permitan ampliar el metamodelo. Ilustración 71. Artefactos propios Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 1.3 La esencia de BPMn - diferentes vistas de un proceso Si alguien ha modelado procesos con otras notaciones, al comienzo le va a ser difícil acostumbrarse a un princi- pio importante de BPMN: «Todo es un aspecto de la perspectiva». BPMN parte de la base que en un diagrama pueden representarse uno o más participantes, pero el lector 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). 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á or- ganizado 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 (ver ilustración 72). Si se sabe utilizar bien los pools, se habrá entendido uno de los principios más importantes del modelamiento de procesos con BPMN, por lo menos si persigue el objetivo de lograr una integración entre la capa de negocio y la de tecnología. U N id a d ii i t eM a N ° 1 126 La especificación de BPMN no sólo define los símbolos que se utilizan en el modelamiento de procesos, sino que además existen una serie de atributos que se pueden relacionar o asignar a los objetos. Muchos de estos atributos no se muestran o visualizan en los diagramas y se encuentran en los atributos de descripción de los objetos. La razón de porqué no se muestran siempre o sólo a pedido, si la herramienta de modelado lo permite, es porque estos atributos apoyan la implementación técnica de los procesos. 1.4 Un proceso simple en BPMn La ilustración 106 muestra el mismo subproceso modelado en eEPC y UML en notación BPMN. En este diagra-ma podemos identificar fácilmente los siguientes objetos y su semántica: Ilustración 72. Diagrama en notación BPMN Actividades: Las actividades son la espina dorsal de los procesos, debido a que son las actividades las que transforman el estado de un objeto de negocio para que el proceso puede llegar a producir valor para los clientes. Las actividades se pueden definir como «acción sobre un objeto», es decir una actividad se denomina siempre con un verbo (acción) y un sustantivo (objeto). Por ejemplo «revisar solicitud» y no «primero hay que revisar la solicitud». Eventos: Eventos 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 represen- ta 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. Junto a esta clasificación fundamental tenemos otros aspectos que diferenciar en los eventos: Solicitud Solicitud recibida U su ar io E xp er to ¿Datos correctos? Solicitud rechazada Solicitud ingresada Administración de solicitudesA dm in is tr ac ió n de s ol ic itu de s Solicitud procesada Revisar solicitud Rechazar solicitud Ingresar solicitud Pool Artefacto Asociación Lane Evento de inicio Objeto de datos Flujo de secuencia Evento intermedio Evento de término Actividad Gateway No Si U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 127 Eventos de inicio son eventos de captura (en inglés: catching events ), es decir algo independiente del proceso ocurrió, pero el proceso tiene que reaccionar o esperar. Eventos intermedios pueden ser del tipo de captura o pueden ser impulsados por alguna actividad del mismo proceso (en inglés: throwing events). El evento intermedio indefinido representa un estado intermedio que ha alcanzado un proceso, por consiguiente se trata de un evento del tipo impulsado. Eventos finales ocurren de forma que el proceso ya no puede reaccionar a ellos, por lo tanto se clasifican como del tipo impulsados. Flujo de Secuencia: El flujo de secuencia describe la secuencia temporal y lógica en el cual se combinan los elementos de flujo, es decir las actividades, eventos y Gateways. El flujo de secuencia es también la trayectoria del proceso por el cual marcha una marca de control de flujo llamada también en inglés «token». El token «nace» junto a una instancia con el evento de inicio. A través del flujo de secuencia llega a las actividades, a los estados intermedios y al evento final, donde es «consumido» y desaparece, al mismo tiempo «muere» la instancia. 1.5 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 ilustración 73 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. Ilustración 73. 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éc- nicas de modelamiento no se interpreta así. En muchas ocasiones no es necesario separar a todos los parti- cipantes 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 U N id a d ii i t eM a N ° 1 128 procesos a partir de los diagramas. El lector habrá escuchado hablar de orquestación de servicios en el contexto de arquitecturas orientadas a servicios (SOA). BPMN persigue el mismo principio, con la única diferencia que la orquestación de servicios es completamente automática y en el caso de un motor de workflow interviene principalmente el ser humano (human-workflow). La siguiente pregunta que se da en este contexto es ¿qué pasa con aquellos procesos que por diversas razones no van a ser automatizados? o lo que también sucede mucho en la práctica, ¿qué parte de los procesos de nego- cio son procedimientos manuales? Justamente la separación de pools permite separar la lógica de los procesos manuales de los procesos automatizados, lo que es una gran ventaja ya que deja en claro qué parte del proceso pasará al diseño técnico de implementación y qué parte pasará a ser procedimiento manual. Un ingeniero tiene la libertad de modelarlo como quiera ; puede modelar el proceso dentro de un gran pool con lanes (subdivisiones dentro de un pool), pero a más tardar en el diseño técnico tendrá que separar estos aspectos , lo que sin duda alguna significa doble trabajo, mayor coordinación y separación entre las capas. Por otro lado, si se quiere lograr una mejor integración o alineamiento entre la capa de negocio y la de TI, el modelo de (separación de pools) que propone BPMN aporta justamente a lograr este objetivo. U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 129 LecTURA SeLecciOnAdA nº 1: La Notación en Detalle Freund, J., Rücker, B., & Hitpass, B. (2014). BPMN 2.0 Manual de Referencia y Guia Práctica (4ta Ed.). p. 20. Santiago de Chile. ¿Qué sabe el mono del gusto del Ingwer?» Este refrán de la India hace alusión a que «si alguien no puede entender algo, tampoco lo puede valorar». Suponemos que el equivalente sería: «tirarle perlas a los chanchos». Podríamos suponer que también BPMN es una perla que no cualquiera sabe valorar porque no cualquiera lo puede entender. Por esta razón le pedimos tomar- se algo de tiempo, para afianzarse con los principios fundamentales de este estándar, no se arrepentirá. Una vez que haya entendido realmente lo que BPMN es, va a disponer de un entorno poderoso que le será de gran beneficio en proyectos de BPM. Si usted ya conoce la especificación de BPMN, no va a encontrar muchas cosas nuevas en este capítulo. Lo que si encontrará son explicaciones e interpreta- ciones que no encontrará en la especificación original y que describimos en forma más extensa y con ejem- plos las convenciones de la simbología. Si usted piensa que conoce BPMN bien o si ya cuen- ta con experiencia práctica en el uso de la notación, le será útil la lectura de este capítulo. La experiencia nos ha mostrado, que muchos aún no han asimilado los principios básicos de la notación, como por ejem- plo que los flujos de secuencia no se deben utilizar como conexiones entre los pools. Lo que BPMN debe cumplir y lo que no BPMN fue desarrollado para modelar procesos. Esta afirmación suena banal, pero en muchas ocasiones se critica que BPMN no puede representar las si- guientes estructuras: Mapas de procesos Estructuras organizacionales Estructuras de datos Estrategias y modelos de negocio Reglas de negocio Infraestructura de TI BPMN se concentra en el modelamiento de los pro- cesos y no de otras estructuras organizacionales. BPMN no fue concebida como una notación para mo-delar otras estructuras de la arquitectura empresarial. Nos parece bien que así sea; imagínese la compleji- dad que tendría, fuera de la que tiene, si pretendiese abarcar la metodología y las reglas sintácticas para todos los otros modelos que describen una organi- zación. También nosotros estamos concientes que no es su- ficiente aplicar sólo BPMN para introducir BPM en una organización. Muchos expertos de BPM, sobre todo aquellos que vienen del mundo de ARIS y han utilizado la técnica de «event process chain (EPC)» se quejan que BPMN no es suficiente. Esta falta de entendimiento se debe principalmente a que no com- prendieron los objetivos del estándar de BPMN: Modelos de BPMN pueden relacionarce con otros modelos de una arquitectura empresarial. BPMN ofrece la posibilidad de ampliarse, por ejem- plo de incluir símbolos propios o de relacionarse con otros objetos de una arquitectura empresarial. Admitimos que sería mejor si es que existiera una convención que fuera más allá de sólo contemplar la vista de los procesos. La integración a una arqui- tectura empresarial no lo considera el estándar, pero tampoco lo impide. Así algunas empresas han hecho esta integración en sus plataformas de arquitectura empresarial. U N id a d ii i t eM a N ° 1 130 AcTividAd FORMATivA n° 1 Desarrolle la prueba mixta N°3 aplicado al tema inSTRUcciOneS PARA eL deSARROLLO de LA PRUeBA MiXTA n°3 1. Lee y analiza La Unidad III y complementa el estudio con la lectura seleccionada N° 1 2. Lee las preguntas detenidamente 3. Desarrolla cada pregunta de acuerdo a lo solicitado. LecTURA SeLecciOnAdA nº 2: Caso de Estudio: Proceso de Contratación de Personal Freund, J., Rücker, B., & Hitpass, B. (2014). BPMN 2.0 Manual de Referencia y Guia Práctica (4ta Ed.). pp. 137-139. Santiago de Chile. Disponible en el aula virtual. U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 131 AcTividAd FORMATivA n° 2 Diseña un modelo de proceso utilizando los elementos de la notación BPMN. inSTRUcciOneS: 1. Lee y analiza los contenidos referidos a la notación BPMN. 2. Complementa tu análisis, con la lectura seleccionada n°2 : Caso de estudio” 3. Elije un proceso que considere que no marcha bien dentro de su entorno laboral. 4. Observa el vídeo: Presentamos Visagi Studio https://www.youtube.com/watch?v=tORvGT7-1pQ 5. Observa el vídeo: Video Presentamos Bizagi Modeler https://www.youtube.com/watch?v=QJfv-oJ5jcY 6. Modela el proceso identificado, utilizando los elementos de la notación. 7. Utiliza el software visio de Microsoft office – opcional para realizar el modelo. Plantilla Diagrama de flujo/ Diagrama BPMN. 8. Envía tu modelo por el aula virtual. Sugerencia: Revisa los criterios de la rúbrica con que se evaluará tu traba jo, para que obtengas un excelente trabajo. U N id a d ii i t eM a N ° 1 132 RÚBRicA PARA eL MOdeLO deL PROceSO Nombre del estudiante: ________________________________________ Sección: _______________________ Fecha: ______________________ INDIcADORes cRITeRIOs 3 bUeNO 2 RegULAR 1 INsUFIcIeNTe TOTAL pROpUesTA De MODeLO Define con claridad la propuesta del modelo del proceso y el tipo de negocio Claridad del tipo de negocio no en el modelo del proceso Falta de claridad en la propuesta del modelo. cANTIDAD De pARTIcIpANTes Plantea de 2 a mas participantes en el modelo. Plantea solo 1 participante en el modelo. No define con claridad los participantes. UsO De LOs eLeMeNTOs De LA NOTAcION Usa de 3 a más elementos de la notación BPMN. Usa 1 o dos elementos de la notación BPMN. No utiliza elementos de la notación BPMN. cOheReNcIA eN eL pROcesO Existe coherencia en el proceso en las entradas y salidas. Existe coherencia en el proceso. No existe coherencia en el modelo. U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 133 GLOSARiO de LA UnidAd iii A ARIS Arquitectura de sistemas integrados, e EPC Cadenas de procesos impulsadas por eventos, Event driven Process Chains - Técnica de modelado de ptocesos de los años 90. ESTRUCTOGRAMAS muestran el control de un proceso por medio de la descomposición de bloques estructurados, G GATEWAY La compuerta en que tenemos que tomar la decisión en BPMN, i IDEF Integrated Definition for Function Modeling) es una familia de técnicas de modelamiento., M MODULARIZAR denotar algo que se divide en módulos, O OMG Object Management Group, OOA Analisis orientado a objetos, S SUBPROCESOS es una opción para encapsular los pasos relacionados lógicamente dentro de un proceso padre, U N id a d ii i t eM a N ° 1 134 T TI Tecnología de la información, TOKEN Un token o también llamado componente léxico es una cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación, U UML Unified Modeling Language) pertenece a una familia de 13 tipos de diagramas, BiBLiOGRAFÍA de LA UnidAd iii Bravo, J. (2011). Gestión de procesos. Santiago de Chile: Evolución S.A. Cuatrecasas, L. (2010). Gestión Integrada de la calidad -Implanración, control y certificación. Barcelona: Inmobi- liaria S.L. Hammer, M. y Champy, J. (1993). Reingenieria. Bogotá: Norma. Harmon, P. (2007). Business Process Change A guide for Business managers and BPM and Six Sigma Profesio- nals Second Edition. USA: MK. Hitpass, B. (2013). BPM Business Process management Fundamentos y Conceptos de Implementación 3ra. Edición actualizada y ampliada. Santiago de Chile: Edición hispana. Jakob Freund, Bernd Rücker, Bernhard Hitpass. (2014). BPMN 2.0 Manual de Referencia y Guía de Práctica. San- tiago de Chile: Hispana Cuarta edición actualizada. John Jeston & Johan Nelis. (2008). Business Process Management. Practical Guidelines to Successful Imple- mentations. Sydney Australia: BPM Consultants. Molano, A. (2015). ¿Qué es Arquitectura Empresarial? Colombia Digital, 24-25. Object Management Group, I. A. (1997-2015). OMG. Recuperado el 28 de 07 de 2015, de http://www.omg.org/ SIGMA, P. O. (15 de 07 de 2015). Pagina oficial Organizacion Six Sigma. Obtenido de http://www.6sigma.com Tobón, L. F. (2012). Evolución de la Gestión por Procesos. Colombia: ICONTEC. 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). Guía de referencia de la Asociación Inter- nacional de Profesionales de BPM 3ra Edición. USA. Zachman, J. A. (1987). A. framework for nformation System Arqutecture. IBM System Journal, 3. U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 135 AUTOevALUAciÓn de LA UnidAd iii Las preguntas siguientes le permitirán verificar su aprendizaje de esta unidad. Le recomiendo que las resuelva cuidadosamente. 1. «acción sobre un objeto» es a) Actividad. b) Evento. c) Gateway d) Datos 2. El Grafico es: a) XOR-Gateway o gateway exclusivo de da- tos. b) Gateway paralelo c) Gateway inclusivo de datos (OR) d) Caso And-Split sin And-Join 3. Son consideraciones de : • Las reglas sintácticas que se esconden detrás de este simple esquema • La clasificación de los objetos • Responder a las preguntas de cómo se utiliza toda esta combinatoria en proyectos reales a) BMP b) SOA c) BPMN d) BPEL 4. Los carriles son: a) Los eventos b) Las actividades. U N id a d ii i t eM a N ° 1 136 c) Lanes d) Sub procesos. 5. El Grafico es: a) Evento de inicio. b) Evento disparador c) Evento de fin d) Evento intermedios. 6. ¿ Que es un sub proceso? a) Describe en su interior la lógica del evento. b) Describe en su interior las actividades de sistema c) Describe en su interior la lógica del proceso d) Describe en su interior la lógica en detalle 7. Qué representa el grafico: a) Caso con uso de subproceso con propiedad. b) Eventodisparador c) Eventos intermedios d) Caso con uso de subproceso sin propiedad. 8. Cuáles son los tipos de artefactos a) De tipo comentario y agrupaciones. b) De tipo condición y señal. c) De tipo conexión y compensación d) De tipo inicio y final. U N id a d iii teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 137 9. Qué representa el siguiente gráfico: a) La reutilización de subprocesos b) La reutilización de actividades c) La reutilización de eventos d) La reutilización de artefactos 10. Qué representa el grafico: a) Utilización de un evento intermedio b) Utilización de un evento disparador c) Utilización de un subproceso d) Utilización de un artefacto intermedio. 138 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 139 UNIDAD IV AUTOMATiZAciÓn de PROceSOS cOn BPMn. diAGRAMA de PReSenTAciÓn de LA UnidAd iv Al finalizar la unidad, el estudiante será capaz de elaborar un modelo de proceso con BPMN, utilizando una herramienta de simulación y automatización. 140 CONTENIDOS ACTIVIDADES FORMATIVAS (hAbILIDADes y AcTITUDes) SISTEMA DE EVALUACIÓN (TécNIcAs y cRITeRIOs) Tema N° 1 : Desarrollo de casos 1 Automatización de procesos con PBMN 2.0 2 BPMN comparado con otras notaciones. • Reconoce y aplica la notación BPMN a un caso de estudio. • Elabora un modelo de proceso con BPMN realizando la simulación y automatización. Procedimientos e indicadores de evaluación permanente: • Entrega puntual del trabajo realizado. • Calidad, coherencia y Pertinencia de contenidos desarrollados: Individual o equipo. • Prueba teórico-práctica individual. • Actividades desarrolladas en sesiones Tutorizadas. Criterios de evaluación para el modelado del caso: (RÚBRICA) • Introducción integral. • Desarrollo del tema con evidencias y ejemplos • Conclusiones centradas en el tema • Gramática y ortografía • Fuentes bibliográficas Criterios de evaluación para el modelado con simulación del caso: (RÚBRICA) • Propuesta de simulación • Simulación plateada según restricciones del caso modelado • Propuesta de mejora a las condiciones planteadas. NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 141 RECURSOS: Videos: Tema Nº 1: Video Nº1: Entendiendo los procesos como un todo https://www.youtube.com/watch?v=DbgGYjO6cHo&index=1&list=PLQLSO6-MzUYVIU9BNWRLFvT4oEmsMlFrf Video Nº2: la importancia de modelar procesos https://www.youtube.com/watch?v=UGf3ZDQjmJ4&list=PLQLSO6-MzUYVIU9BNWRLFvT4oEmsMlFrf&index Video Nº3: Modelando nuestros procesos https://www.youtube.com/watch?v=qPGIFWKVyWM&index=3&list=PLQLSO6-MzUYVIU9BNWRLFvT4oEmsMlFr Tema Nº 2: Video Nº3: Simulación en detalle https://www.youtube.com/watch?v=we5pIdNumAM Video Nº4: Ejemplo Bizagi Automatización proceso de solicitud de vacaciones https://www.youtube.com/watch?v=YOHRqW-XbAw (del minuto 0 al minuto 4:57) DIAPOSITIVAS ELABORADAS POR EL DOCENTE: INsTRUMeNTO De eVALUAcIóN Rúbrica para evaluar el organizador del conocimiento bIbLIOgRAFíA (básIcA y cOMpLeMeNTARIA) BASICA 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. RecURsOs eDUcATIVOs DIgITALes Técnicas para el Modelado de Procesos de Negocio en Cadenas de suministro [en línea], [Consulta: 03 de junio de 2015]. Disponible en Web http://www.scielo.cl/scielo.php?script=sci_arttext&pid=S0718-07642009000200005 • Procesos de negocio y técnicas [en líne] , [Consulta: 03 de junio de 2015]. Disponible en Web: http://es.slideshare.net/sgfranco25/procesos-de-negocio-y-tecnicas • BPMN 2.0 Best Practices https://camunda.org/bpmn/examples/ U N id a d iV t eM a N ° 1 142 TeMA n° 1: deSARROLLO de cASOS Apreciados estudiantes un modelo es una representación gráfica acerca dela realidad, de acuerdo al modelo que deseamos representar los modelos toman diversos nombres, cuando se desea representar gráficamente los procesos de los negocios estos se denominan modelamiento de procesos. IDEF0 es una forma de modelar los procesos, la vista que nos muestra acerca de los procesos con sus respecti- vos elementos de entradas, controles, recursos y salidas nospermiten tener un conocimiento global del proce- so. En el mercado además existen una infinidad de notaciones para los procesos, pero ya desde hace un tiem- po se estableció un estándar denominado BPMN (Business Process Modeling Notation) que viene a ser una no- tación para el Modelamiento de procesos que se convirtió en estándar internacional. 1. AUTOMATiZAciÓn de PROceSOS cOn PBMn 2.0 BPMN es un estándar para el modelamiento de procesos basado en diagramas de flujo de los proce- sos el cual nos permite modelar y definir el proceso. Además esta notación se amplía en la gestión de proce- sos de negocio ya que permite la integración con datos, interfaces y otras herramientas de automatización que permiten generar interfaces de software que gestionen el proceso analizado. El objetivo que persigue BPMN es el de tener una notación estándar para los procesos que sea fácil y compren- sible a todos los interesados del proceso de negocio. Dentro de los interesados podríamos considerar a los ana- listas de procesos del negocio, los diseñadores e implementadores de procesos y los que gestionan los procesos. Por lo que BPMN persigue el fin de ser un lenguaje de notación común de tal forma que sirva para una mejor co- municación en la implementación de los procesos. 1.1 elementos de BPMn 2.0.- Los elementos de BPMN son nueve y se listan a continuación: a) Actividades En todo proceso se realizan actividades, estas representan trabajos o tareas que se lle- van a cabo por responsables asignados en la organización. La forma de ejecución puede ser manual o au- tomática (aquellas tareas que se realizan por un sistema externo o de usuario) y pueden ser atómi- cas o compuestas (no atómicas). Las actividades se pueden clasificar en tareas y sub procesos (compuestas). eLeMeNTO DescRIpcIóN NOTAcIóN Tarea Es una actividad atómica dentro de un flujo de proceso. Se utiliza cuando el trabajo en proceso no puede ser desglosado a un nivel más bajode detalle Tarea de Usuario Es una tarea de workflow típica donde una persona ejecuta con la asistencia de una aplicación de software U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 143 eLeMeNTO DescRIpcIóN NOTAcIóN Tarea de Servicio Es una tarea que utiliza algún tipo de Servicio que puede ser Web o una aplicación automatizada Tarea de Recepción Es una tarea diseñada para esperar la llegada de un mensaje por parte de un participante externo (relativo al proceso). Tarea de Envío Es una tarea diseñada para enviar un mensaje a un participante externo (relativo al proceso). Tarea de Script Es una tarea que se ejecuta por un motor de procesos de negocio. El usuario define un script en un lenguaje que el motor pueda interpretar Tarea Manual Es una tarea que espera ser ejecutada sin lasistencia de algún motor de ejecución de procesos de negocio o aplicación. Tarea de Regla de Negocio Ofrece un mecanismo para que el Proceso provea una entrada a un motor de Reglas de Negocio y obtenga una salida de los cálculos que realice el mismo. Ciclo Multi-Instancia Las tareas pueden repetirse secuencialmente comportándose como un ciclo. El ciclo multi- instancia permite la creación de un número deseado de instancias de actividad que pueden ser ejecutadas de forma paralela o secuencial Ciclo Estándar Las tareas pueden repetirse secuencialmente comportándose como un ciclo.Esta característica define un comportamiento de ciclo basado en una condición booleana. La actividad se ejecutará siemprey cuando la condición booleana sea verdadera Fuente: Bizagi Process Modeler - Guia de Usuario. 2013 http://help.bizagi.com/processmodeler/es/ U N id a d iV t eM a N ° 1 144 b) Subproceso Un sub proceso viene a ser una actividad que se descompone en más actividades es de- cir es una actividad compuesta que se incluye dentro de los procesos. Compuesta quiere decir que pue- de desglosarse a niveles más bajos, lo que significa que incluye figuras y elementos en dicha descompo- sición. eLeMeNTO DescRIpcIóN NOTAcIóN Sub-proceso Es una actividad cuyos detalles internos han sido modelados utilizando actividades compuertas, eventos y flujos de secuencia Sub-proceso Reusable Identifica un punto en el flujo donde se invoca un proceso pre-definido. Los procesos reusables se conocen como Actividades de Llamada en BPMN. Sub-proceso de Evento Un sub proceso es definido como de Evento cuando es lanzado por un evento. Un sub proceso de evento no es parte del flujo normal de su proceso Padre - no hay flujos de entrada o salida Transacción Es un sub proceso cuyo comportamiento es controlado a través de un protocolo de transacción. Este incluye los tres resultados básicos de una transacción: Terminación exitosa terminación fallida y evento intermedio de cancelación Ad-Hoc Subproceso Es un grupo de actividades que no requieren relaciones de secuencia. Se puede definir un conjunto de actividades, pero su secuencia y número de ejecuciones es determinada por sus ejecutantes Ciclo Estándar Los sub procesos pueden repetirse secuencialmente comportándose como un ciclo. Esta característica define un comportamiento de ciclo basado en una condición booleana. La actividad se ejecutará siempre y cuando la condición booleana sea verdadera. Ciclo Multi- Instancia Los sub procesos pueden repetirse secuencialmente comportándose como un ciclo. El ciclo multi-instancia permite la creación de un número deseado de instancias de actividad que pueden ser ejecutadas de forma paralela o secuencial. Fuente: Bizagi Process Modeler - Guia de Usuario. 2013 http://help.bizagi.com/processmodeler/es/ U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 145 c) Compuertas Una compuerta involucra una secuencia que debe ser revisada ya que se considera como di- vergente o convergente en los flujos entre actividades. eLeMeNTO DescRIpcIóN NOTAcIóN Compuerta exclusiva De divergencia: Se utiliza para crear caminos alternativos dentro del proceso, pero solo uno se selecciona Compuerta basada en eventos De convergencia: Se utiliza para unir caminos alternativos. Representa un punto de ramificación en los procesos donde los caminos alternativos que siguen la compuerta están basados en eventos que ocurren. Compuerta exclusiva basada en eventos Cuando el primer evento se dispara, el camino que sigue a ese evento se usará. Los caminos restantes serán deshabilitados. Es una variación de la compuerta basada en eventos que se utiliza únicamente para instanciar procesos. Compuerta Paralela basada en eventos Si uno de los eventos de la configuración de la compuerta ocurre, se crea una nueva instancia del proceso. No deben tener flujos de entrada A diferencia de la Compuerta Exclusiva Basada en Eventos, se crea una instancia del proceso una vez que TODOS los eventos de la configuración de la compuerta ocurren. No deben tener flujos de entrada. Compuerta paralela De convergencia: Se utiliza para unir caminos alternativos. Las compuertas esperan todos los flujos que concurren en ellas antes de continuar Compuerta compleja De divergencia: Se utiliza para controlar puntos de decisión complejos en los procesos. Crea caminos alternativos dentro del proceso utilizando expresiones.. De convergencia: Permite continuar al siguiente punto del proceso cuando una condición de negocio se cumple Compuerta Inclusiva De divergencia: Representa un punto de ramificación en donde las alternativas se basan en expresiones condicionales. La evaluación VERDADERA de una condición no excluye la evaluación de las demás condiciones. Todas las evaluaciones VERDADERAS serán atravesadas por un token. De convergencia: Se utiliza para unir una combinación de caminos paralelos alternativos. Fuente: Bizagi Process Modeler - Guia de Usuario. 2013 http://help.bizagi.com/processmodeler/es/ U N id a d iV t eM a N ° 1 146 d) Eventos Un evento viene a ser la ocurrencia de algo que sucede en el proceso, de tal forma que afec- ta el flujo y genera un resultado eLeMeNTO DescRIpcIóN NOTAcIóN Evento de inicio Indica dónde se inicia un proceso. No tiene algún comportamiento particular. Evento de inicio de mensaje Se utiliza cuando el inicio de un proceso se da al recibir un mensaje de un participante externo. Evente de inicio de Temporalización Se utiliza cuando el inicio de un proceso ocurre en una fecha o tiempo de ciclo específico. (e.j, todos los viernes) Evento de inicio condicional Este tipo de evento dispara el inicio de un proceso cuando una condición se cumple. Evento de inicio de señal El inicio de un proceso se da por la llegada de una señal que ha sido emitida por otro Proceso Tenga en cuenta que la señal no es un mensaje; losmensajes tienen objetivos específicos, la señal no Evento de inico paralelo multiple Indica que se requieren múltiples disparadores parainiciar el proceso. TODOS los disparadores deben ser lanzados para iniciarlo. Evento de inicio múltiple Significa que hay múltiples formas de iniciar el Proceso. Solo se requiere una de ellas. Fuente: Bizagi Process Modeler - Guia de Usuario. 2013 http://help.bizagi.com/processmodeler/es/ U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 147 e) Eventos Intermedios eLeMeNTO DescRIpcIóN NOTAcIóN Finalización simple Indica que el flujo finaliza. Finalización de mensaje Indica que un mensaje se envía una vez finaliza el flujo. Finalización escalable Indica que es necesario realizar un escalamiento una vez finaliza el flujo. Finalización de error Indica que se debe generar un error. Todas las secuencias activas del proceso son finalizadas. El error será recibido por un evento intermedio de captura de error. Finalización de cancelación Se utiliza dentro de un sub-proceso de transacción e indica que éste debe ser cancelado Finalización de compensación Habilita el manejo de compensaciones. Si una actividad se identifica y fue exitosamente completada, ésta será compensada. Finalización de señal Indica que una señal es enviada una vez finaliza el flujo. Finalización Multiple Significa que hay múltiples consecuencias de finalizar el flujo. Todas ellas ocurrirán Finalización Terminar Finaliza el proceso y todas sus actividades de forma inmediata. Fuente: Bizagi Process Modeler - Guia de Usuario. 2013 http://help.bizagi.com/processmodeler/es/ U N id a d iV t eM a N ° 1 148 f) Datos eLeMeNTO DescRIpcIóN NOTAcIóN Pool Un pool es un contenedor de procesos simples contiene flujos de Secuencia dentro de las actividades). Un proceso está completamente contenido dentro de un pool. Siempre existe por lo menos un pool Lane Es una sub-partición dentro del proceso. Los lanes se utilizan para diferenciar roles internos, posiciones, departamentos, etc. Fase Es una sub-partición dentro del proceso Puedeindicar diferentes etapas durante el mismo. g) Conectores eLeMeNTO DescRIpcIóN NOTAcIóN Flujo de secuencia Un flujo de secuencia es utilizado para mostrar el orden en el que las actividades se ejecutarán dentro del proceso. Asociación Se utiliza para asociar información y artefactos con objetos de flujo. También se utiliza para mostrar las tareas que compensan una actividad. Flujo de mensaje Se utiliza para mostrar el flujo de mensajes entre dos entidades que están preparadas para enviarlosy recibirlos. Fuente: Bizagi Process Modeler - Guia de Usuario. 2013 http://help.bizagi.com/processmodeler/es/ U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 149 1.2 Modelamiento de Proceso Usando Bizagi Bizagi es una suite ofimática con dos productos complementarios, un Modelador de Procesos y una Suite de BPM. Bizagi Process Modeler es un Freeware utilizado para diagramar, documentar y simular procesos usando la no- tación estándar BPMN (Business Process Modeling Notation).1 Bizagi BPM Suite es una solución de Gestión de procesos de negocio (BPM) que le permite a las organizaciones ejecutar/automatizar procesos o flujos de trabajo (workflows). Existe una edición de nivel de entrada (Xpress Edition2 ) y dos ediciones corporativas (Enterprise .NET y Enterprise JEE El primer paso para crear soluciones Bizagi es diseñar el flujo de trabajo (o flujo de Proceso). El flujo de tra- bajo, conocido como una cadena de actividades, es la estructura fundamental del proyecto, al cual se inclu- yen las variables y elementos necesarios de acuerdo a los requerimientos de la organización. Bizagi Process Modeler Bizagi Process Modeler es un freeware para diagramar, documentar y simular procesos de manera gráfica en un formato estándar conocido como BPMN (Business Process Modeling Notation). Los procesos y su docu- mentación correspondiente pueden exportarse a Word, PDF, Visio, la web o SharePoint3 para compartirlos y comunicarlos. Si embargo es importante saber que Se tienen dos opciones para Diseñar sus procesos para automatización: a. Diagramar procesos usando Bizagi Modeler (recomendado) Utilice Bizagi Modeler para diseñar y documentar sus diagramas de Proceso. Bizagi Modeler es una aplicación gra- tuita, independiente de Bizagi Studio, dedicada a brindarle la mejor experiencia al momento de diseñar y docu- mentar flujos de trabajo bajo el estándar BPMN (Business Process Model and Notation). BPMN es un están- dar de reconocimiento mundial para el modelamiento de Procesos. Escoja esta opción si usted está interesado en diagramar y documentar procesos, adicional a su documentación. Una vez su proceso está completo y listo para automatizar, presione el botón Ejecutar Workflow en la pesta- ña Inicio del Modelador. Esto exportará su modelo automáticamente al ambiente de construcción, Bizagi Studio. Esta suite nos proporciona su Guía de usuario de Bizagi que la podemos acceder desde este link: Modeler U N id a d iV t eM a N ° 1 150 b. Diagramar procesos usando el Modelador de Procesos incluido en Bizagi Studio Utilice el modelador de Procesos en Bizagi Studio. Este Modelador de Procesos está orientado a diseño de pro- cesos para automatización. Se debe escojer esta opción si se está interesado exclusivamente en automatización de procesos, sin documen- tación. Crearemos nuestro primer proceso con Bizagi Lo primero que hacemos es ingresar a la aplicación y nos pmuestra una pantlla de inicio tal como se muestra en la ilustración 75. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 151 Ilustración 74. Pantallaso de entorno de inicio Visagi Fuente: Elaboración propia Es muy fácil y rápido crear un diagrama de procesos en Bizagi. Para demostrar la facilidad con la que se hace va- mos usar el proceso de Solicitud de Compras. Los siguientes son los pasos necesarios para crear el proceso: • Una Orden de Compras es creada • El Supervisor inmediato del empleado aprueba, rechaza o solicita cambios a la Orden (en Bizagi, El • supervisor inmediato será direccionado a “Boss” para este ejemplo). • Se deben solicitar cotizaciones para seleccionar el Proveedor. • Se crea una Orden de Compra. • El jefe administrativo aprueba, rechaza o modifica la Orden. • La Orden de Compra es enviada al Proveedor. • La Orden de Compra es creada en el ERP de la compañía. U N id a d iV t eM a N ° 1 152 1. Para crear un nuevo proceso dé clic en la opción Nuevo Proceso en el paso 1 (Modelo de Proceso) del asisten- te, tal como se muestra en la ilustración 2. Ilustración 75. Pantallazo eEligiendo Nuevo Proceso 2. Nombre su proceso y luego dé clic en Ok. En el momento que abra la ventana del modelador, usted estará listo para empezar a diagramar. El primer carril (Lane) del contenedor (Pool) es creado de forma automática. Ilustración 76. Pantallazo Nuevo proceso asignando nombre U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 153 3. Adicione carriles (Lanes) para incluir participantes dentro del proceso.(Vea ilustración 4) Arrastre y suelte, desde la paleta del lado izquierdo, un carril por cada participante. En nuestro ejemplo, hemos incluido tres carriles: Uno por el Supervisor Inmediato (Jefe), otro por el solicitan- te y el último para el Departamento de Compras. Ilustración 77. Pantallazo Adicionando carriles o lanes 4. Incluya un punto de inicio dentro del proceso. .(Vea ilustración 5) Arrastre y suelte un Evento de inicio desde la paleta. Ilustración 78. Pantallazo Incluyendo punto de inicio al carril U N id a d iV t eM a N ° 1 154 5. Continúe diagramando su proceso usando el Menú Circular. Seleccione el siguiente elemento y arrástre- lo y suéltelo donde desea localizarlo. (Vea ilustración 6) Ilustración 79. Pantallazo-añadiendo elementos 6. Para conectar dos elementos en el flujo de secuencia, seleccione el objeto desde le Menú Circular y arrástre- lo sobre el segundo elemento, realizando esta acción se conectarán de forma automática. (Vea ilustración 7). Ilustración 80. Pantallazo- conectando elementos 7. Continúe seleccionaándo las formas necesarias hasta que su diagrama este completo. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 155 8. Para redimensionar el contenedor, seleccione el borde de la esquina apropiada y arrastre hasta encontrar el ta- maño deseado. Ilustración 81. Pantallazo- redimensionando elementos La siguiente imagen (ilustracion 83) se muestra el diagrama del proceso Solicitud de Compra. Ilustración 82. Pantallazo - modelo terminado solicitud de compra U N id a d iV t eM a N ° 1 156 Editar un proceso Una vez haya diagramado su proceso, usted podría necesitar cambiar elementos, por ejemplo, incluir conecto- res adicionales o agregar más figuras para mejorar y completar el modelo. Continuemos con nuestro proceso de Solicitud de Compras para ejemplificar como realizar estos cambios de for- ma sencilla. En el primer paso del asistente, dé clic en la opción Editar Proceso. Esto abrirá modeladorcon el proceso. (Vea Ilustración 84) Ilustración 83. Pantallazo - editando proceso Moviendo elementos Si usted necesita mover elementos del diagrama de un lugar a otro, dé clic sobre él y arrástrelo hasta la nue- va posición. Eliminando elementos Si necesita eliminar un elemento del diagrama, dé clic sobre el y presione el botón Delete. Cambiar / Transformar elementos La siguiente imagen (ilustración 85) muestra el proceso inicial de Solicitud de compra que diseñamos. Sin em- bargo,necesitamos hacer algunos ajustes. Ya que existen correos electrónicos que se deben enviar de forma automática dependiendo de la deci- sión del jefe inmediato, es necesario cambiar la tarea de Notificación a una tarea de Script. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 157 La tarea Cotizaciones es un subproceso donde se deben realizar varias actividades para poder escoger un pro- veedor. La tarea Orden de Compra también es un subproceso donde la Orden de Compra es enviada al proveedor y crea- da en el sistema ERP. Ilustración 84. Pantallazo – proceso inicial solicitud de compra El modelador permite cambiar elementos de la misma categoría. Usted no necesita incluir otro elemento al pro- ceso, solamente debe cambiar el elemento existente. 1. Para cambiar la tarea de Notificacióna una tarea de Script, dé clic derecho sobre el elemento del diagra- ma y seleccione Tipo de Tarea del menú que se ha desplegado. U N id a d iV t eM a N ° 1 158 Escoja el tipo apropiado para la tarea de la lista desplegable. (Vea ilustración 86 y 87) Ilustración 85. Pantallazo - esocgiendo el tipo apropiado 2. Realice el mismo procedimiento para las otras dos tareas de Notificación. La siguiente imagen muestra el pro- greso hasta este momento. Ilustración 86. Pantallazo - escogiendo el tipo apropiado U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 159 3. Para transformar la tarea Cotizaciones en un subproceso, dé clic derecho sobre la tarea y seleccione la op- ción Transformar en subproceso del menú. Repita el procedimiento en la tarea Orden de Compra. Ilustración 87. Pantallazo - transformando en subprocesos Incluir fases (Milestones) Las fases (Milestones) son sub divisiones del proceso, las cuales son utilizadas como puntos de referen- cia. Ellas ayudan a los lectores ha entender las diferentes etapas que conforman el proceso. Vamos a incluir tres fases para determinar el estado de cada actividad dentro del proceso. U N id a d iV t eM a N ° 1 160 1. Para incluir una fase, arrastre el elemento desde la paleta y ubíquelo sobre el diagrama. Arrastre y suel- te otras dos fases. (Vea ilustración 15). Ilustración 88. Pantallazo - incluyendo fases 2. Arrastre y suelte los elementos que pertenecen a la fase. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 161 3. Para renombrar una fase dé doble clic sobre ella, presione la tecla F2 o dé clic derecho sobre ella y seleccio- ne la opción editar texto del menú. (Vea ilusttración 90) . Ilustración 89. Pantallazo - renombrando una fase Importar un proceso Si su proceso ha sido modelado utilizando Bizagi Modeler, éste puede ser importado a Bizagi Studio para ser uti- lizado dentro del proyecto. Para importar sus diagramas siga los pasos mencionados a continuación. 1. En el primer paso del asistente dé clic en la opción Importar Proceso. Ilustración 90. Pantallazo -importando proceso U N id a d iV t eM a N ° 1 162 2. En la nueva ventana, seleccione el modelo que desea importar al proyecto actual. Ilustración 91. Pantallazo -asignando nombre y tipo de archivo ASEGÚRESE DE QUE EL PROCESO HAYA SIDO GUARDADO EN EL FORMATO EXPORTAR A MODELO DE DIAGRAMAS DE BIZAGI V1.6 ANTES DE IMPORTAR. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 163 3. Defina un nombre para su proyecto y seleccione la Aplicación donde desea crearlo. Luego dé clic en OK. 4. Su proceso será abierto en modo de edición. Ahora usted está listo para automatizarlo. Modelado para ejecución Para asegurar diagramas precisos, es importante familiarizarse con el estándar de notación para modela- do de procesos BPMN. La siguiente es una breve explicación sobre las figuras que utiliza el estándar BPMN. 2. BPMn cOMPARAdO cOn OTRAS nOTAciOneS Muchos interesados por BPMN conocen algunas otras notaciones para modelar procesos. Seguramente tam- bién se preguntarán si tiene sentido cambiarse a BPMN y qué aspectos hay que considerar en esta nueva téc- nica de modelamiento. Según la región donde uno radica y la escuela por la que ha pasado, habrá conocido o aplicado diferentes no- taciones. En algunas regiones nos encontramos con una mayor influencia del pensamiento europeo y en otras con una mayor influencia de la escuela norteamericana, razón por la cual se ha escogido para una comparación, aquellas técnicas más representativas de ambas regiones 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, UML EDOC Business Processes, IDEF, ebXML BPSS, Ac- tivity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains (EPCs)[Obj11]. Algunas de estas notaciones que se revisaron son de carácter técnico e influyeron en el desarrollo del concepto de colabo- ración y coreografía (UML EDOC, ebXML BPSS, RosettaNet). ebXML BPSS (Electronic business using XML ), UML EDOC (Profile for Enterprise Distributed Object Compu- ting (EDOC)), RosettaNet (Metodología estándar para supply chain), LOVeM (Técnica para modelar interfaces de IBM). Otras notaciones más orientadas al negocio se revisaron para extraer ideas en la parte conceptual del modela- miento de procesos de negocio, como EPC, IDEF y UML Activity Diagram. Con el fin de entender la evolución que han tenido en las últimas cuatro décadas las técnicas de modelamiento, le presentamos al lector en la siguiente sección una breve reseña histórica de estas técnicas y notaciones, sobre todo enfocado a explicar los supuestos cambios de paradigmas. U N id a d iV t eM a N ° 1 164 Finalmente comparamos con BPMN las dos notaciones más difundidas actualmente para modelar procesos de negocio La mayor debilidad de las notaciones comparadas con BPMN, es la insuficiencia estructural para modelar la ló- gica entre los participantes autónomos de los procesos, es decir de modelar la colaboración entre los procesos. Este aspecto conceptual de colaboración y coreografía se convierte hoy en día en un factor crítico, si pensamos que los desafíos actuales tienden a un grado cada vez mayor de integración de los procesos en una organización y sobre todo con sus agentes externos (proveedores, clientes, entes gubernamentales, entes reguladores, etc.). 2.1 clasificación de las técnicas de modelamiento A a lo largo del tiempo se han desarrollado muchas técnicas de modelado, de las cuales sólo presentamos algu- nas, las más conocidas. Cuando el lector se encuentre con una de ellas será importante saber clasificarlas, de lo contrario será difícil de evaluarlas para un fin determinado o para compararlas con otras notaciones. Formalmente podemos hacer la primera gran división en metodologías basadas en técnicas de lenguaje estruc- turado (script) y metodologías basadas en técnicas de diagramación. Las notaciones del tipo de script están muy cercas de los lenguajes de programación (Ejemplos: BPEL o lenguajes propietarios de herramientas de softwa- re), son formalmente precisas, pero su expresividad visual es prácticamente nula, por lo que sería muy difícil de emplearlas con usuarios de negocio. 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. (ver ilustración ): Ilustración 92. Clasificación de algunas técnicas de diagramación para modelamiento Fuente: HITPASS, 2013 U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 165 El uso de técnicas orientadas al flujo de datos se están empleando cada vez menos,de hecho actualmente para la especificación de desarrollo de sistemas se utilizan los diferentes diagramas de UML. Una Red de Petri está formada por lugares (círculos), transiciones (rectángulo) y arcos dirigidos (flechas), así como por fichas que ocupan posiciones. Los lugares representan estados en los procesos (documentos, datos, recursos,etc.) y las transiciones la transformación de información (funciones, procesos, actividades, etc.). Los arcos relacionan lugares y transiciones. A diferencia de los modelos EPC, las redes de Petri no utilizan nodos de conexión (decisión), las conexiones se entienden como implícitas. Las redes de Petri se utilizan bastante en algunas organizaciones para modelar sistemas de workflow y procesos. Los estructogramas (debido a la estructura de bloques recibió esta técnica el nombre de estructogramas) mues- tran el control de un proceso por medio de la descomposiciónde bloques estructurados, que se van descom- poniendo cada vez más, hasta llegar al nivel de actividad. Los bloques van disminuyendo de tamaño dentro del mismo diagrama a medida que se van descomponiendo los procesos. Los estructogramas son isomorfos con los diagramas de flujo. Todo lo que se puede representar con este tipo de diagramas se puede representar con un diagrama de flujo de control. Las únicas excepciones se dan en las instrucciones «goto, break y continue». La técnica de diagramación de estructogramas (técnica de diagramas en bloque para la programación estructurada desarrollada en los años 70 por Nassi-Scheinerman) que fue heredado de la ingeniería de software, no logró mayor difusión, razón por la cual no la seguiremos tratando. Gran difusión logró la notación EPC, razón por la cual le dedicaremos una sección propia a esta técnica que po- demos clasificarla dentro del grupo de las técnicas orientadas al flujo de control. Los diagramas de swimlane fueron desarrollados a principios de los 90 por H.F.Binner bajo el nombre «RPO: Representación de Procesos Organizacionales (en alemán ODP: Organisationsprozessdarstellung). El nombre «swimlane» se utiliza en analogía a los carriles para nadar, en los cuales los actores de los procesos que repre- sentan una unidad organizacional o un rol, intercambian información a través de un flujo de secuencia (control) durante la ejecución de los pasos de un proceso hasta que llegue a término. Parte de esta notación fue adoptada en muchas otras técnicas de modelamiento, así también en BPMN. Los diagramas del tipo Picture utilizan dispositivos con imágenes de objetos reales, para representar tipos de actividades en procesos. Esta técnica fue desarrollada en el año 2007 por el «European Research Center for Information Systems»[Gad10] con el propósito de diagramar mapas de procesos para la administración pública. Existen alrededor de 24 dispositivos de imágenes y otros elementos para modelar procesos. A diferencia de otras notaciones, la cantidad de tipos de objetos se reduce notablemente, también debido a que muchos elementos descriptivos se integran a través de atributos a los dispositivos. Sin embargo, esta técnica no alcanza un grado de formalización que sea suficiente para modelar procesos a nivel operacional. Antes que apareciera BPMN se difundieron bastante algunas técnicas orientadas al objeto para modelar pro- cesos, 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 organizacio- nales). La técnica de Statechart Diagram fue desarrollada por Harel en los años 90 como propuesta para modelar relacio- nes complejas en los flujos de los procesos. El flujo de control entre las actividades de un proceso se describe con ayuda de arcos dirigidos. El correspondiente diagrama Activitychart describe el flujo de datos. El flujo de con- trol se define entre estados y actividades. Statecharts reaccionan a reglas del tipo Event-Condition-Action-Rules (ECA). La especialidad de esta técnica es el modelamiento de flujo de control considerando el flujo de datos. (Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014) En una encuesta realizada en el año 2007 por Gadatsch[Gad10] a grandes organizaciones se pudo constatar, que la técnica EPC, la de Swimlane Diagram y UML, eran relativamente las más utilizadas para el modelamiento de procesos: U N id a d iV t eM a N ° 1 166 EPC (43,1 %) Swimlane (38,8 %) UML (21,6 %) BPMN (16,4 %) Redes de Petri (3,4 %) SADT (44,0 %) IDEF (2,6 %) Encuestas más recientes muestran un rápido o mejor dicho explosivo crecimiento hacia BPMN y junto a ello una disminución de las otras técnicas de modelamiento. La razón principal es porque BPMN se convirtió en un estándar oficial de la industria para modelar procesos que además ahora en la nueva versión contiene un meta- modelo para intercambiar modelos entre herramientas y para implementar directamente estos con TI. Otra de las razones no menos importante es que es apoyado por casi todos los grandes fabricantes y proveedores de tecnología a nivel mundial. También en el ámbito científico y académico en BPMN se están desarrollando cada día más proyectos de investigación y conferencias. Cadenas de procesos impulsadas por eventos (eEPC) La notación de «Event driven Process Chain» (EPC) fue desarrollada en los años ’80 por Keller, Nüttgens y Scheer en la Universidad de Saarland, Alemania y desde los años 90 se ha convertido en un estándar industrial en los países desarrollados, sobre todo en los de habla alemana. El EPC tiene su origen en las redes de Petri que define que todos los procesos se pueden explicar a través de los elementos « Estado - Transición -nuevo Estado ». El Prof. August Wilhem Scheer fundó una empresa llamada IDS-Scheer que desarrolló una herramienta mundialmente conocida como ARIS (Architecture of Integrated Systems) y en la cual integró en su vista principal «la vista de control» la notación para modelado de procesos EPC. En el año 1992 la empresa IDS-Scheer hizo una cooperación con SAP AG para documentar e integrar los procesos de negocio de la solución de ERP de SAP. La integración de ARIS con SAP fue una de las principales razones que ARIS y EPC se hicieran mundialmente conocidas, más allá de los países de habla alemana. Hasta el año 2008 EPC fue la notación más difundida para el modelamiento de procesos, sobre todo en los países de habla alemana, pero con la aparición del estándar BPMN la situación cambió. Hasta el 2010, podemos constatar consultando varios medios, que el interés por BPMN ha sobrepasado al de EPC. Muchos analistas que emplearon EPC por muchos años se están preparando para cambiarse a la nueva notación, lo que no a todos los expertos de EPC les resulta fácil debido al distinto enfoque que tienen ambas notaciones. También IDS-Scheer reconoció la importancia del estándar e incluyó rápidamente la notación a su plataforma de ARIS (Nota: La empresa IDS Scheer fue adquirida en el año 2010 por Software AG). Un proceso de negocio puede modelarse (a nivel funcional) con la estructura y diagrama del modelo EPC, que se componen de los elementos, eventos, funciones (actividades en BPMN), conectores (nodos de decisión) y unidades de la organización. Los conectores en EPC, (XOR-OR-AND) tienen casi el mismo significado que los Gateways en BPMN, con la diferencia que EPC no hace diferencia entre compuertas basadas en datos o even- tos como en BPMN. En la versión extendida de EPC, conocida como eEPC (extended EPC), pueden utilizarse elementos que enriquecen el diagrama con mayor información como datos, aplicaciones, data cluster, documen- tos, materiales y objetivos. EPC permite al igual que BPMN la agregación de funciones como subprocesos o la conexión de diagramas a través de links. Existen reglas para convertir procesos modelados en EPC a BPMN. Este ejercicio lo hicimos a modo de ejemplo que usted puede apreciar en la ilustración 20. Algo de cuidado tiene que tener al mapear los eventos a BPMN, porque desde el punto de vista estructural EPC no hace ninguna clasificación con respecto a los diferentes tipos de eventos. EPC por ejemplo, no conoce la diferencia entre eventos de inicio, intermedios, de término y tam- poco hace la diferencia entre eventos de tiempo y de mensaje. Tampoco se puede utilizar en EPC el concepto U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 167 de eventos sobrepuestos que permiten modelar situaciones como interrupciones, tratamiento de errores o de escalación. Debido a su historia, la notación EPC aún tiene una gran difusión a nivel global y en general podemos concluir que el modelo EPC es simple y adecuado a la terminología del usuario final, pero inadecuado para llevarlo a un diseño de implementación técnica, razón por la cual no recomendamos seguir usándola a partir del nivelopera- cional. UML Diagrama de actividades El diagrama de actividades de UML (Unified Modeling Language) pertenece a una familia de 13 tipos de diagra- mas que existen en la versión actual 2.0. UML es administrado al igual que BPMN por la OMG (Object Mana- gement Group) como estándar, con la diferencia que UML es bastante más antiguo que BPMN (desde el año 1997). Sin embargo no hay que mal interpretar que BPMN reemplazaría a UML, porque UML fue desarrollado como técnica para el desarrollo de sistemas, mientras que BPMN para el modelamiento de procesos. A pesar de esta diferencia, se ha empleado mucho y sobre todo antes que apareciera BPMN, la técnica de diagramas de actividades de UML para modelar procesos. Se ha empleado preferentemente como técnica de especificación para el desarrollo del workflow embebido en sistemas de TI. La notación de diagrama de actividades de UML es más amplia que la de EPC. Existen en UML objetos muy técnicos que ni siquiera se conocen en BPMN, sobre todo en el ámbito de especificación de parámetros y re- glas para el procesamiento de objetos. En los aspectos relevantes para el modelamiento de procesos pueden traspasarse casi todos los elementos del diagrama de actividades de UML a BPMN, con la salvedad de las áreas de interrupción en UML que pueden modelarse por encima de los roles (o lanes en BPMN). Este caso no se puede traspasar uno a uno a BPMN, por ejemplo como subproceso, sino que en BPMN habría que modelarlo como subproceso global para que impacte sobre cada uno de los lanes afectados en BPMN (ver ilustracion 21 ). Para efectos de una especificación técnica de flujos en el desarrollo de sistemas, los diagramas de actividades de UML, especificando casos de uso, van a seguir siendo importantes, pero para la implementación de procesos de negocio BPMN es el estándar declarado y su notación es muy superior a la de UML. La definición técnica de procesos que van a ser interpretados directamente por un motor de workflow es el dominio de BPMN y no existe ninguna otra notación hasta el momento que supere en grado de expresividad a este nuevo estándar. U N id a d iV t eM a N ° 1 168 Ilustración 93. Mapeo de EPC hacia BPMN Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 Usuario Usuario Usuario Solicitud recibida Revisar solicitud Ingresar solicitud Solicitud ingresada Solicitud procesada Solicitud rechazada Administración de solicitudes Rechazar solicitud Datos correctos Datos incompletos Solicitud XOR XOR Unidades organizacionales se representan BPMN con lanes Eventos de inicio tienen el mismo significado en BPMN El nodo de decisión o conector de XOR en EPC lo representamos como XOR Gateway en BPMNDocumentos en EPC pueden representarse como objetos de datos en BPMN Para aplicaciones no existe en BPMN un símbolo propio, pero en BPMN tenemos diferentes posibilidades de representarlo: como un atributo, como comentario a la actividad o como un artefacto y símbolo propio. El último evento en un proceso EPC es al mismo tiempo el evento final. En BPNM ocupamos el evento de término En EPC las funciones siempre generan un evento como salida. Estos eventos se pueden omitir en BPNM si son triviales, pero es el evento es portador de un estado lo modelamos como un evento intermedio (indefinido) Solicitud Solicitud recibida U su ar io E xp er to ¿Datos correctos? Solicitud rechazada Solicitud ingresada Administración de solicitudesA dm in is tr ac ió n de s ol ic itu de s Solicitud procesada Revisar solicitud Rechazar solicitud Ingresar solicitud No Si U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 169 Ilustración 94. Mapeo de UML diagrama de actividades a BPMN Fuente: Jakob FREUND, Bernd RÜCKER, Bernhard HITPASS, 2014 La actividad principal describe en el entendido de BPMN el proceso por lo que podemos traducirlo como un pool (nombre en el pool. header) Particiones las podemos representar como lanes en BPMN Señales de recepción que inicianel flujo, se convierten en BPMN en eventos de inicio, en este caso del tipo mensajería. Un Objeto de nodo corresponde en este caso a un objeto de datos. Como elemento de control utiliza UML el Bifurcador - XOR y el AND - para paralelizar o sincronizar. Una bifurcación del tipo y/o (OR) no existe en UML. Acciones son Actividades en BPMN. Aplicaciones en UML 2 también se representan como Objetos de nodo. En BPMN podemos usar las alternativas descritas en el ejemplo EPC. Igual que en EPC. UML. necesita una unión técnica para unir los flujos en un nodo. En BPMN no siempre necesitamos una unión técnica. El modo de término en UML corresponde al evento terminal en BPMN. El nodo de término se utiliza mucho en UML, a pesar de que también se conoce el nodo sencillo de término. Nosotros recomendamos de utilizar el evento sencillo de término en BPMN y solo utilizar el evento terminal si es necesario. Señales de interrupción pueden representarse en diagramas de BPMN de diferentes formas - en este caso como mensaje, que es sobrepuesto sobre un subproceso (area). Un área de interrupción en UML, correspondería a un subproceso embebido en BPMN, pero si el subproceso traspasa los límites de un lane habría que utilizar subprocesos globales. Solicitud recibida Solicitud retirada Revisar solicitud Rechazar solicitud Confirmar retiro Admin solicitudes Ingresar solicitud Solicitud Administración de solicitudes Usuario (Datos correctos) Solicitud procesada Experto (Datos incompletos) Solicitud Solicitud recibida Solicitud retirada U su ar io E xp er to A dm in is tr ac ió n de s ol ic itu de s - U su ar io A dm in is tr ac ió n de s ol ic itu d - á re a de in te rr up ci ón ¿Datos correctos? Administración de solicitudes Solicitud procesada Revisar solicitud Confirmar retiro Rechazar solicitud Ingresar solicitud No Si U N id a d iV t eM a N ° 1 170 videOS Video 10: ¿Qué es BPMN? Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: ¿Qué es BPMN? URL: https://youtu.be/x5k67iBzSYg?t=7s Duración: Autor(a): Bizagi Lmtd. Año: 2015 Licencia: YouTube estándar Video 11: Bizagi Modeler Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Bizagi Modeler URL: https://youtu.be/QJfv-oJ5jcY?t=7s Duración: Autor(a): Bizagi Lmtd. Año: 2015 Licencia: YouTube estándar Video 12: Entendiendo los procesos como un todo. Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: Entendiendo los procesos como un todo. URL: https://youtu.be/DbgGYjO6cHo?t=13s Duración: Autor(a): Bizagi Lmtd. Año: 2015 Licencia: YouTube estándar. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 171 Video 13: La importancia de modelar procesos Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional. Datos del Video seleccionado Tema: La importancia de modelar procesos URL: https://youtu.be/UGf3ZDQjmJ4?t=5s Duración: Autor(a): Bizagi Lmtd. Año: 2015 Licencia: YouTube estándar. Video 14: Modelando nuestros procesos. Este material de video ha sido seleccionado solo y únicamente con fines de estudio académico y todos sus derechos correspon- den a sus autores en el ámbito local, regional e internacional.Datos del Video seleccionado Tema: Modelando nuestros procesos. URL: https://youtu.be/qPGIFWKVyWM?t=5s Duración: Autor(a): Bizagi Lmtd. Año: 2015 Licencia: YouTube estándar. U N id a d iV t eM a N ° 1 172 AcTividAd FORMATivA n° 1 Reconoce y aplica la notación BPMN a un caso de estudio instrucciones: • Lee y analiza los contenidos referidos a la notación BPMN. • Observa los siguientes vídeos: Entendiendo los procesos como un todo https://www.youtube.com/watch?v=DbgGYjO6cHo&index=1&list=PLQLSO6-MzUYVIU9BNWRLFv- T4oEmsMlFrf Observa el vídeo: la importancia de modelar procesos https://www.youtube.com/watch?v=UGf3ZDQjmJ4&list=PLQLSO6-MzUYVIU9BNWRLFvT4oEmsMlFr- f&index=2 Observa el vídeo: Modelando nuestros procesos https://www.youtube.com/watch?v=qPGIFWKVyWM&index=3&list=PLQLSO6-MzUYVIU9BNWRLFv- T4oEmsMlFrf • Lee el caso • Plantea el modelo para el proceso de solicitud de vacaciones. utilizando los elementos de la notación. • Utiliza el software visagi. • Envía tu modelo por el aula virtual. CASO DE ESTUDIO El proceso se inicia cuando un trabajador desea hacer una solicitud de vacaciones. Para esto el trabajador debe llenar la solicitud y enviársela a un encargado en el departamento de Recursos Humanos para que verifique los días disponibles con que cuenta el trabajador, y en base a esto aprobar o desaprobar la solicitud. En caso de que el trabajador tenga días acumulados, el jefe inmediato del trabajador debe recibir la solicitud para analizarla y aprobarla. En caso de que el jefe inmediato apruebe la solicitud, debe imprimir una copia, a la vez que el encarga- do en Recursos Humanos registra la solicitud aprobada en un documento de office Word (Plantilla de solicitud de vacaciones). Luego el encargado de Recursos Humanos imprime una copia de la solicitud y concluye el proceso una vez que el empleado haya regresado de las vacaciones solicitadas. En todos los casos que se desapruebe la solicitud, se debe notificar al solicitante. Sugerencia: Revisa los criterios de la rúbrica con que se evaluará tu trabajo, para que obtengas un excelente nota. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 173 RÚBRicA cASO de MOdeLO Nombre del estudiante: ________________________________________ Sección: _______________________ Fecha: __________________________ INDIcADORes cRITeRIOs 3 bUeNO 2 RegULAR 1 INsUFIcIeNTe TOTAL pROpUesTA De MODeLO Define con claridad la propuesta del modelo del proceso y el tipo de negocio Claridad del tipo de negocio no en el modelo del proceso Falta de claridad en la propuesta del modelo. cANTIDAD De pARTIcIpANTes Plantea de 2 a mas participantes en el modelo. Plantea solo 1 participante en el modelo. No define con claridad los participantes. UsO De LOs eLeMeNTOs De LA NOTAcION Usa de 3 a más elementos de la notación BPMN. Usa 1 o dos elementos de la notación BPMN. No utiliza elementos de la notación BPMN. cOheReNcIA eN eL pROcesO Existe coherencia en el proceso en las entradas y salidas. Existe coherencia en el proceso. No existe coherencia en el modelo. U N id a d iV t eM a N ° 1 174 AcTividAd FORMATivA nº 2 Elabora un modelo de proceso con BPMN realizando la simulación y automatización inSTRUcciOneS: • Lee y analiza los contenidos referidos a la notación BPMN. • Observa los siguientes vídeos: Video N°3 : Simulación en detalle https://www.youtube.com/watch?v=we5pIdNumAM Video N°4 : Ejemplo Bizagi Automatización proceso de solicitud de vacaciones https://www.youtube.com/watch?v=YOHRqW-XbAw (del minuto 0 al minuto 4:57) • Del modelo planteado en la actividad formativa n°1, realice la simulación. • Utiliza el software visagi. • Envía tu modelo con la simulación planteada por el aula virtual. Sugerencia: Revisa los criterios de la rúbrica con que se evaluará tu trabajo, para que obtengas un excelente nota. U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 175 RÚBRicA cASO de MOdeLO Nombre del estudiante: ________________________________________ Sección: _______________________ Fecha: __________________________ INDIcADORes cRITeRIOs 3 bUeNO 2 RegULAR 1 INsUFIcIeNTe TOTAL pROpUesTA De sIMULAcION Define con claridad la propuesta del modelo del proceso y el tipo de negocio Claridad del tipo de negocio no en el modelo del proceso Falta de claridad en la propuesta del modelo. sIMULAcION pLATeADA segÚN ResTRIccIONes DeL cAsO MODeLADO Cumple con todas las restricciones. Cumple parte de las restricciones. No cumple con las restrcciones. pROpUesTA De MejORA A LAs cONDIcIONes pLANTeADAs Plantea y valida propuesta de mejora. Plantea propuesta de mejora. No platea ni valida propuesta de mejora U N id a d iV t eM a N ° 1 176 GLOSARiO de LA UnidAd iv A AUTOMATIZACIÓN Aplicación de máquinas o de procedimientos automáticos en la realización de un proceso o en una industria., 4 b BIZAGI MODELER es un poderoso modelador de procesos de negocio compatible con el estándar BPMN 2.0, 13 c COMPUERTA Una compuerta involucra una secuencia que debe ser revisada ya que, 7 e EPC La notación de «Event driven Process Chain, 33 EVENTO Un evento viene a ser la ocurrencia de algo que sucede en el proceso, de, 8 m MODELO representación de procesos, modelos o sistemas que conforman un conglomerado mayor o supra-sistema, que pretende el análisis de interacción de ellos, a fin de mantener una relación flexible que les permita cumplir su función particular y coadyuvar para cumplir la función del supra-sistema., 4 o OMG Object Management Group, 34 r RPO Representación de Procesos Organizacionales, 32 s SUBPROCESO Un Subproceso es un conjunto de actividades que tienen una secuencia lógica para cumplir un propósito, 6 U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 177 AUTOevALUAciÓn nº 4 1. ¿Qué es BPMN? a) Es un sistema para el modelamiento de procesos basado en diagramas de flujo de los procesos el cual nos permite modelar y definir el proceso. b) Es un estándar para la sistematización del proceso basado en diagramas de flujo de los procesos el cual nos permite modelar y definir el proceso. c) Es un sistema para el modelamiento de procesos basado en elementos de los procesos el cual nos permite modelar y definir el proceso. d) Es un estándar para el modelamiento de procesos basado en diagramas de flujo de los procesos el cual nos permite modelar y definir el proceso. 2. ¿Qué es una actividad? a) Representan trabajos o tareas que se llevan a cabo por responsables en la organización. b) Representan trabajos o tareas que se llevan a cabo en una automatización. c) Representan diagramas de flujos que se llevan a cabo en un proceso. d) Representan diagramas de flujo que se llevan a cabo en un modelamiento. 3. La notación de una tarea de servicios es: a. c.- b. d.- 4. ¿Qué es un sub proceso? a) Es una actividad que se descompone en más tareas. b) Es una actividad que se descompone en más actividades. c) Es una sub función del proceso. d) Es una sub tarea de un proceso. U N id a d iV t eM a N ° 1 178 5. ¿Cuál es la notación Ad-hoc Subproceso? a. b.- c.- d.- 6. ¿Qué es una compuerta? a) Es un flujo de datos que debe ser revisada ya que se considera como divergente o convergente en los flujos entre actividades. b) Es una secuencia que debe ser revisada ya que se considera como divergente o convergente en los flujos entre actividades. c) Es una secuencia que debe ser revisada ya que se considera como divergente en los flujos entre actividades. d) Es una secuencia que debe ser revisada ya que se consideracomo convergente en los flujos entre actividades. 7. Cuál es la notación de Compuerta paralela a. b. c. d. 8. ¿Qué es un evento? a) Es la ocurrencia del algo que sucede en el proceso de tal forma que afecta el flujo y genera un pro- ceso. b) Es la ocurrencia del algo que sucede en el proceso de tal forma que afecta el flujo y genera un siste- ma. c) Es la ocurrencia del algo que sucede en el proceso de tal forma que afecta el flujo y genera un resul- tado. d) Es la ocurrencia del algo que sucede en la actividad del proceso de tal forma que afecta el flujo y genera un resultado. 9. ¿Cuál es la notación de Evento de inicio de señal? U N id a d iV teM a N ° 1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 179 a. b.- c.- d.- 10. ¿Cuál es la notación de un lane? a.- b.- c.- d.- U N id a d iV a N eX o N °1 180 AneXO n°1 Respuestas de la Autoevaluación de la Unidad i NÚMeRO RespUesTA 1 a 2 b 3 b 4 a 5 b 6 d 7 f 8 a 9 d 10 a Respuestas de la autoevaluación de la unidad ii NÚMeRO RespUesTA 1 b 2 a 3 d 4 b 5 a 6 b 7 c 8 a 9 b 10 b U N id a d iV a N eXo N °1 NotacióN de Procesos de Negocio MANUAL AUTOFORMATIVO 181 Respuestas de la Autoevaluación de la Unidad iii NÚMeRO RespUesTA 1 a 2 a 3 c 4 c 5 b 6 d 7 a 8 a 9 a 10 a Respuestas de la autoevaluación de la iv unidad NÚMeRO RespUesTA 1 d 2 a 3 b 4 a 5 c 6 b 7 c 8 c 9 a 10 b MANUAL AUTOFORMATIVO INTeRACTIVO Este manual autoformativo es el material didác-tico más importante de la presente asignatu-ra. Elaborado por el docente, orienta y facilita el auto aprendizaje de los contenidos y el desarrollo de las actividades propuestas en el sílabo. Los demás recursos educativos del aula virtual complementan y se derivan del manual. Los con- tenidos multimedia ofrecidos utilizando videos, presentaciones, audios, clases interactivas, se corresponden a los contenidos del presente ma- nual. La educación a distancia en entornos vir- tuales te permite estudiar desde el lugar donde te encuentres y a la hora que más te convenga. Basta conectarse al Internet, ingresar al campus virtual donde encontrarás todos tus servicios: aulas, videoclases, presentaciones animadas, bi- blioteca de recursos, muro y las tareas, siempre acompañado de tus docentes y amigos. El modelo educativo de la Universidad Continen- tal a distancia es innovador, interactivo e integral, conjugando el conocimiento, la investigación y la innovación. Su estructura, organización y fun- cionamiento están de acuerdo a los estándares internacionales. Es innovador, porque desarrolla las mejores prácticas del e-learning universitario global; interactivo, porque proporciona recursos para la comunicación y colaboración síncrona y asíncrona con docentes y estudiantes; e integral, pues articula contenidos, medios y recursos para el aprendizaje permanente y en espacios flexi- bles. Ahora podrás estar en la universidad en tiempo real sin ir a la universidad.  INTRODUCCIÓN  DIAGRAMA DE PRESENTACIÓN DE LA ASIGNATURA  RESULTADO DE APRENDIZAJE:  UNIDADES DIDACTICAS  TIEMPO MÍNIMO DE ESTUDIO  INTRODUCCIÓN Y DEFINICIÓN DEL BUSSINESS PROCESS MANGMENT(BPM)  DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I  TEMA N° 1: FUNDAMENTOS DEL BPM 1. Introducción al BPM. Historia y evolución 2.-Conceptos básicos sobre (Proceso, gestión, BPM)  VIDEOS  ACTIVIDAD FORMATIVA N° 1  VIDEOS  LECTURA SELECCIONADA Nº 1:  ACTIVIDAD FORMATIVA N° 2  TEMA N° 2: ORGANIZACIÓN Y ESTRUCTURA DEL BPM 1. Organización y Estructura del BPM.  VIDEOS  LECTURA SELECCIONADA Nº 2:  ACTIVIDAD FORMATIVA N° 3  VIDEOS  RÚBRICA PARA EVALUAR UN CUADRO COMPARATIVO  ACTIVIDAD FORMATIVA N° 4  GLOSARIO DE LA UNIDAD I  BIBLIOGRAFíA DE LA UNIDAD I  AUTOEVALUACIÓN DE LA UNIDAD I  ARQUTECTURA EMPRESARIAL EN EL CONTEXTO BPM  DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD II  TEMA N° 1: INTRODUCCIÓN A LA ARQUITECTURA EMPRESARIAL 1 Historia y evolución - Conceptos Básicos 2 Conceptos básicos de Arquitectura Empresarial (AE) 3 Áreas de una arquitectura empresarial  VIDEOS  LECTURA SELECCIONADA Nº 1:  ACTIVIDAD FORMATIVA N° 1  RÚBRICA PARA EVALUAR UN CUADRO COMPARATIVO  ACTIVIDAD FORMATIVA N° 2  TEMA N° 2: ESTÁNDARES DE GESTIÓN EMPRESARIAL 1 Relación AE & BPM & SOA 2 Frameworks de Arquitectura Empresarial  VIDEOS  LECTURA SELECCIONADA Nº 2:  ACTIVIDAD FORMATIVA N° 3  RÚBRICA DE EVALUACIÓN DEL INFORME ESCRITO  ACTIVIDAD FORMATIVA N° 4  GLOSARIO DE LA UNIDAD Ii  BIBLIOGRAFíA DE LA UNIDAD Ii  AUTOEVALUACIÓN DE LA UNIDAD II  BUSINESS PROCESS MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN)  DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD III  TEMA N° 1: Bussiness Process Model y la Notación BPMN  LECTURA SELECCIONADA Nº 1:  ACTIVIDAD FORMATIVA N° 3  LECTURA SELECCIONADA Nº 2:  ACTIVIDAD FORMATIVA N° 2  RÚBRICA PARA EL MODELO DEL PROCESO  GLOSARIO DE LA UNIDAD IiI  BIBLIOGRAFíA DE LA UNIDAD IiI  AUTOEVALUACIÓN de la unidad iii  AUTOMATIZACIÓN DE PROCESOS CON BPMN.  DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD IV  TEMA N° 1: DESARROLLO DE CASOS 1. Automatización de procesos con PBMN 2.0 2. BPMN comparado con otras notaciones  VIDEOS  ACTIVIDAD FORMATIVA N° 1  RÚBRICA CASO DE MODELO  ACTIVIDAD FORMATIVA Nº 2  RÚBRICA CASO DE MODELO  GLOSARIO DE LA UNIDAD Iv  AUTOEVALUACIÓN Nº 4  ANEXO N°1
Mais conteúdos dessa disciplina
Questão 1/10 - Modelagem de Processos e Negócios Ler em voz alta Qual dos seguintes benefícios da modelagem no ciclo de vida do software está dir...- Questão 7: De acordo com Giglio (2002), observações informais e pesquisas de psicologia social têm demonstrado que, ao sentir dissonância cognitiva, a
- quais sao os estilos comnhecidos da pintura nos vasos gregos desse periodo
- Para analisar a pintura do periodo helenistico , quais são os estilos conhecidos da pintura vasos gregos desse periodo
- em relação a emergencia ambiental de barragem de mineradora quais são os passos que devemos adotar
- O processo de transformação caracteriza a efetiva transformação dos recursos de entrada de produtos e serviços . Ele se divide em três estampas ent...
- Questionário - Gestão Contemporânea [GCSA1068] É correto afirmar sobre o processo de tomada de decisão em uma organização. 0,500 PONTOS É correto a...
- eia o texto a seguir. O fluxograma é uma importante ferramenta da qualidade para se entender o fluxo dos procedimentos, das atividades e das informaçõ
- Durante uma avaliação organizacional, foi observado que os líderes estavam adotando uma postura excessivamente permissiva. Afirmativa I: A lideranç...
- Uma empresa está em processo de reestruturação estratégica e deseja definir seu propósito fundamental para alinhar as decisões de longo prazo de to...
- Uma empresa está em processo de reestruturação estratégica e deseja definir seu propósito fundamental para alinhar as decisões de longo prazo de to...
- A identidade também é parte fundamental da constituição humana. A qual conceito está associado o termo identidade? Escolha uma: a. Ao de ser idêntico
- quais tartarugas pode ter em casa
- Fundamentação Histórica dos Direitos Humanos
- Introdução à Sociologia
