Business Process Management (BPM) Fundamentos y Conceptos de Implementación Bernhard Hitpass Primera Edición 2012 Business Process Management (BPM) Fundamentos y Conceptos de Implementación Derechos reservados 2012 - BPM Center Prof. Bernhard Hitpass Depto. Informática Universidad Técnica Federico Santa María Santiago de Chile Edición internacional hispana Primera edición Junio 2012 Todas las marcas y nombres mencionados en este libro son marcas registradas o marcas de sus respectivas organizaciones. Cualquier omisión o mal uso no debe ser interpretado como un intento de infringir la propiedad de otros. El publicado reconoce y respeta todas las marcas usadas por las organizaciones como un instrumento para distinguir sus derechos de productos. Ninguna parte de este libro puede ser reproducida o usada de ninguna forma, gráfica, electrónica, fotocopiado, sin el permiso expreso y por escrito del publicador, excepto en los casos de breves reseñas y referencias en artículos, publicaciones científicas y conferencias. Copyright BPM Center (www.bpmcenter.cl) Layout: Autor con LATEX Diseño carátula: Felipe Espinoza Guerraty, ZAGUE Diseño Encuadernación: Hotmelt CScod120622 Editorial: BHH Ltda. - Santiago de Chile Impresión: PoD Copyright © (RPI Chile): N° 215482 ISBN: 978-956-345-977-7
Presentación La Informática como disciplina tiene su origen en la conversación de la Computación y la Organización; la una habla del diseño, construcción y análisis sistemáticos de sistemas computacionales, y la otra habla del examen, representación y diseño sistemáticos de grupos humanos con propósito. Este diálogo fecundo tiene larga data, y a lo largo del tiempo ha dado origen a áreas como Cibernética, Teoría de Sistemas, Análisis de Sistemas, y como corolario reciente, Modelado y Gestión de Procesos de Negocios. Dice mucho sobre nuestro mundo hispanoparlante que esta última disciplina sea conocida por sus siglas en inglés (BPM: Business Process Management). La adquisición sistemática de técnicas modernas, sea como educación en pregrado, postgrado, postítulos o capacitación, requiere que muchos conceptos clave sean descritos, explicitados y ejemplificados en la lengua de los receptores. Pero hasta ahora hemos contado fundamentalmente con traducciones de textos en lenguas extranjeras, más avanzadas en la senda del desarrollo metodológico. Es por tanto con mucho agrado que constato que Bernhard Hitpass ha escrito un libro sobre este tema, no sólo con contenido original en español, sino también con casos reales de aplicación en organizaciones hispanoamericanas. Esto es especialmente valioso, ya que nos permite tratar de emular (con las debidas diferencias) el aprender-haciendo: el alumno que aprende viendo cómo su maestro resuelve un problema, un problema que le es relevante y comprensible.
Creo por lo tanto que el valor de este texto es dual: por una parte una sistematización creativa del conocimiento de un experto del área, y por otra una oportunidad para que lectores hispanoparlantes vean los conceptos aplicados a problemas cercanos. Estoy cierto de que este libro será un recurso permanente y valiosísimo para la enseñanza de la disciplina en nuestro idioma. Prof. Dr. Hernán Astudillo Universidad Técnica Federico Santa María Abril 2012 - Chile La gestión de procesos de negocio (BPM, por sus siglas en inglés) es un ámbito de gestión que ha crecido significativamente en los últimos años, debido a que las empresas se han dado cuenta que para responder a los desafíos de flexibilidad, orientación al cliente, productividad y competitividad que imponen los actuales entornos de negocio, ya no se puede gestionar las organizaciones en base al organigrama. Se requiere una mirada transversal, que traspase los límites entre las distintas áreas del negocio; se requiere pensar en cómo la empresa crea valor para sus clientes. Esta mirada transversal requiere una orientación hacia los procesos de negocios críticos, aquellos que responden a una demanda concreta del cliente por los productos o servicios que la organización entrega. Este libro describe BPM desde un punto de vista amplio. Describe tanto las metodologías de gestión que permiten mejorar los procesos de negocios como aquellas mejores prácticas que permiten orientar el quehacer de la gerencia o área de procesos, entidad responsable de impulsar una visión de procesos en la organización y entregar servicios que permitan mejorar los distintos procesos que en ella existen. También presenta las tecnologías de información que permiten automatizar la ejecución y el control de los procesos de negocios. Por último, describe cómo poner en prácticas estas metodologías de gestión y herramientas tecnológicas, para lograr implementar desde una arquitectura empresarial orientada a procesos, en una perspectiva más estratégica, hasta la automatización y mejoramiento continuo de cada proceso individual, en una perspectiva más operacional. Bernhard Hitpass ha sido un gran impulsor de la adopción de BPM en las empresas; es además, de las escasas personas que conozco que equilibra bien su sólido conocimiento académico del área, con experiencia práctica en organizaciones de diversas industrias, donde ha trabajado en impulsar temas de arquitectura de procesos y mejora de procesos de negocios, participando de proyectos de gran envergadura y amplitud de alcance. Compartimos el desafío de difundir buenas prácticas de gestión y uso de las tecnologías para contribuir a mejorar la gestión de procesos de las organizaciones. En tal sentido, creo que este libro plasma una mirada amplia acerca de los conceptos y metodologías fundamentales de BPM, que toda persona interesada en impulsar la gestión de procesos en su organización debe conocer. Deberían leer este libro todos aquellos que tengan a su cargo liderar iniciativas de mejora de procesos: gerentes de áreas o centros de excelencia de procesos, analistas de procesos, consultores, y todos aquellos que creemos que mejorar las prácticas de gestión de procesos requiere tener un marco conceptual y metodológico sólido, que impulsen el mejoramiento sostenido de los procesos de negocio en todo tipo de organizaciones. Prof. Dr. Marcos Sepúlveda Pontificia Universidad Católica de Chile Abril 2012 - Chile
Prólogo En reiteradas ocasiones he pensado si tiene sentido y relevancia escribir un libro sobre Business Process Management (BPM) al ya existir bastante literatura al respecto, la mayoría de ésta, sin embargo, en inglés. Si bien es cierto, que para estudiantes, profesionales e incluso académicos no debería ser un problema estudiar la literatura anglosajona, en el mundo hispano aún sigue siendo una barrera importante para adentrarse en las profundidades de la rama de una ciencia. También existe literatura de BPM en el idioma alemán no traducida a otras lenguas, por consiguiente no accesibles para personas que no dominan el idioma. Otro aspecto que llama la atención en la clásica literatura de BPM es que tratan los temas de gestión, ingeniería de procesos y tecnología con diferentes profundidades, algunos sólo se limitan a presentar conceptos de gestión de procesos y otros lo presentan desde el punto de vista informático. Para entender BPM desde el punto de vista holístico, un libro que introduce a BPM debiera tratar las capas de negocio, integración, tecnología y las fases del ciclo de vida de BPM en forma balanceada, lo que generalmente no se encuentra. Este ha sido uno de los desafíos mas relevantes, para desarrollar este trabajo y se presenta en la primera parte de este con el subtítulo «Fundamentos del BPM». Otro de los desafíos ha sido desarrollar para cada uno de los grandes conceptos teóricos que están detrás del BPM, un modelo referencial para implementarlos. La segunda parte de este trabajo se presenta como «Conceptos de Implementación», razón
por la cual el tratado lleva el título de «Fundamentos y Conceptos de Implementación». Este trabajo es el resultado de muchos años de experiencia profesional, de investigación académica y sistematización a través de discusiones con profesionales, colegas, alumnos, consultorías y proyectos reales. A través de los años se fue desarrollando y mejorando en estructura y contenido una cátedra académica que lleva el mismo nombre. Este conocimiento ha sido transferido en el curso de los años a cientos de profesionales de empresas, alumnos de pregrado, postitulo y postgrado a través de cursos y talleres. La estructura del libro consta de dos grandes partes: La «Parte I Fundamentos del BPM» describe el estado del arte de los grandes conceptos teóricos del BPM que acompañan en parte como ramas especializadas de otras disciplinas empresariales como la teoría de administración de empresas y modelos de la ciencia de la informática. En este sentido BPM se entiende como una disciplina que engloba otras disciplinas empresariales hacia un modelo integrado de planificación, de gestión y plataformas tecnológicas. La « Parte II Conceptos de Implementación para BPM» de esta obra está dedicada a presentar conceptos de implementación, en gran parte desarrollados por el autor, entendiéndose como un proceso de planificación del cambio para poner en funcionamiento la gestión correspondiente en cada una de las capas de la organización. Esta segunda parte integra a los modelos de procedimiento y el apoyo tecnológico en cada una de las capas del BPM. El libro está dirigido a todos los profesionales de distintas organizaciones, sean estas públicas o privadas, que requieran o quieran interiorizarse en esta disciplina de gestión por procesos. También está dirigido a estudiantes y académicos de las ciencias industriales e informáticas y en general a escuelas de negocios y administración de empresas. Notas generales para el lector: Este trabajo presenta la primera edición del libro. BPM es aún una disciplina nueva, razón por la cual actualmente el impulso y la dinámica en investigación académica, investigación aplicada y desarrollo de nuevas tecnologías se encuentran en su mayor apogeo. El objetivo del autor es mantener actualizado el conocimiento documentado sobre este tema, razón por la cual nuevas ediciones debieran cumplir con este desafío. En algunas ocasiones se hacen citas originales en inglés sin ser traducidas con el objetivo de dar a conocer la fuente original a algunos lectores interesados. Sin embargo, la comprensión de la cita no es necesaria para entender el contexto del párrafo pertinente.. Algunos capítulos y secciones fueron adoptados con pequeñas modificaciones del libro de la versión hispana BPMN 2.0, Manual de Referencia y Guía Práctica [FreRueHit11], del mismo autor por tratarse de intersecciones que son necesarias para la comprensión de ambos trabajos. Se adoptaron principalmente algunas partes de la introducción, las secciones 2.2, 2.3, 2.7, 9.4 y los capítulos 6 «Técnicas de modelado de Procesos» y 7 «Técnicas de Análisis y Mejora». Bernhard Hitpass, Director Ejecutivo BPM Center, Depto Informática, Universidad Técnica Federico Santa María, Santiago, Chile, email:
[email protected]
Agradecimientos Mis agradecimientos para mi colega y Subdirector de Informática UTFSM, Prof. Dr. Hernán Astudillo, por sus aportes a la sección ESB (Enterprise Service BUS) y sobre todo por su gran apoyo en el fomento del desarrollo científico y profesional de BPM-SOA, permitiendo en el año 2008 la creación del BPM Center (perteneciente a la UTFSM), un centro de competencia académico y profesional dedicado exclusivamente a este tema. Agradezco también muy especialmente a mi alumno y asistente, Ingeniero Civil Informático Diego Moya, cursando el programa de Magíster del Departamento de Informática de la Universidad Técnica Federico Santa María (UTFSM), por sus valiosos aportes de investigación de Modelos de Madurez para BPM y por el arduo trabajo de revisión del manuscrito. Igualmente, quisiera reconocer el aporte de mi colega Ingeniero Civil Matemático y MBA Patricio Veloz, un colaborador con mucha experiencia en análisis, simulación y costeo de actividades, por sus valiosos aportes al capítulo 7, en especial las secciones de análisis de tiempo de ciclo y análisis de costeo de actividades.
No puedo dejar de mencionar a nuestros colegas de la Pontificia Universidad Católica de Chile Prof. Dr. Marcos Sepúlveda y Javier Bermúdez Ingeniero Civil Industrial de la UC, con quienes colaboramos intensamente en el ámbito académico y profesional, tanto en investigación, intercambio de experiencia, formación continua y difusión de la disciplina BPM a través de nuestros centros de extensión. Finalmente quiero agradecer a todos mis alumnos, que a lo largo de los años han contribuido con sus observaciones y espíritu analítico a consolidar las materias de los cursos impartidos.
Índice general I Fundamentos del BPM 1 1. Introducción y Definición del BPM 3 1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Trasfondo histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. La ingeniería de procesos nace con Frederick Taylor . . . . . . . 5 1.2.2. El cambio del mercado de la oferta al mercado de la demanda . . 6 1.2.3. La reingeniería de procesos como precursor de BPM . . . . . . . 7 1.3. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.1. ¿Qué es un proceso? . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.2. ¿Qué es un proceso de negocio? . . . . . . . . . . . . . . . . . . . 10 1.3.3. ¿Gestión de o por procesos de negocio? . . . . . . . . . . . . . . 14 1.3.4. Gestión tradicional sin BPM . . . . . . . . . . . . . . . . . . . . 15 1.3.5. Definiciones: Business Process Management (BPM) . . . . . . . . 16 1.3.6. ¿BPM una nueva moda que se va a desinflar? . . . . . . . . . . . 19 2. La Organización y la Estructura del BPM 21 2.1. Conceptos de Gestión en BPM . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.1. BPM Governance . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1.2. BPM Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.3. Gestión de Casos - Case Management . . . . . . . . . . . . . . . 25 2.1.4. ¿Case Management versus BPM? . . . . . . . . . . . . . . . . . . 28 2.2. La automatización de procesos . . . . . . . . . . . . . . . . . . . . . . . 30 2.3. Los participantes en BPM . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4. Herramientas para BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.5. La arquitectura del BPM y SOA . . . . . . . . . . . . . . . . . . . . . . 39 2.6. Control de gestión y monitoreo . . . . . . . . . . . . . . . . . . . . . . . 43 2.6.1. Control de gestión orientada a procesos . . . . . . . . . . . . . . 43 2.6.2. Monitoreo de procesos en línea . . . . . . . . . . . . . . . . . . . 45 2.6.3. Los factores críticos de la medición del desempeño . . . . . . . . 45 i ii ÍNDICE GENERAL 2.7. El mundo de las reglas de negocio . . . . . . . . . . . . . . . . . . . . . . 54 2.7.1. Definición reglas de negocio . . . . . . . . . . . . . . . . . . . . . 54 2.7.2. Gestión de reglas de negocio . . . . . . . . . . . . . . . . . . . . . 56 2.7.3. Reglas de negocio y reglas de ruteo . . . . . . . . . . . . . . . . . 57 2.8. Técnicas de mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.8.1. Six Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.8.2. KAIZEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.8.3. Lean Management . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3. Arquitectura Empresarial en el Contexto de BPM 71 3.1. Trasfondo histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.2. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.2.1. ¿Qué es una arquitectura? . . . . . . . . . . . . . . . . . . . . . . 72 3.2.2. ¿Qué es una Arquitectura Empresarial (AE)? . . . . . . . . . . . 73 3.2.3. Drivers y Objetivos de una AE . . . . . . . . . . . . . . . . . . . 77 3.2.4. Áreas de una arquitectura empresarial . . . . . . . . . . . . . . . 85
3.3. La relación AE & BPM & SOA . . . . . . . . . . . . . . . . . . . . . . . 90 3.4. Frameworks de Arquitectura Empresarial . . . . . . . . . . . . . . . . . 93 3.4.1. Zachman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.4.2. TOGAF (The Open Group Architecture Framework) . . . . . . . 97 3.4.3. FEA (Federal Enterprise Architecture) . . . . . . . . . . . . . . 98 3.4.4. ARIS (Architecture of Integrated Information Systems) . . . . . 99 3.4.5. Enterprise Architecture as Strategy (Ross et al) . . . . . . . . . . 104 4. Modelos de Madurez para BPM 109 4.1. ¿Qué es un modelo de madurez? . . . . . . . . . . . . . . . . . . . . . . 109 4.2. Capability Maturity Model Integration (CMMI) . . . . . . . . . . . . . . 110 4.3. Modelos de Madurez Específicos para BPM . . . . . . . . . . . . . . . . 111 4.3.1. Business Process Maturity Model - OMG . . . . . . . . . . . . . 112 4.3.2. Modelo de Madurez BPM de Jeston y Nelis . . . . . . . . . . . . 115 4.3.3. Modelo de Madurez de Harmon . . . . . . . . . . . . . . . . . . . 119 4.3.4. Modelo de madurez BPM de Rosemann y Bruin . . . . . . . . . 121 4.3.5. Modelo de madurez BPM de Schmelzer . . . . . . . . . . . . . . 123 4.4. Importancia de los modelos de madurez para BPM . . . . . . . . . . . . 125 5. Desarrollo Organizacional en el Contexto de BPM 127 5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.2. Trasfondo histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.3. Los cambios en la organización . . . . . . . . . . . . . . . . . . . . . . . 129 5.3.1. El concepto de desarrollo organizacional . . . . . . . . . . . . . . 130 5.3.2. La organización como sistema complejo y dinámico . . . . . . . . 130 ÍNDICE GENERAL iii 5.3.3. La cultura organizacional . . . . . . . . . . . . . . . . . . . . . . 131 5.3.4. El clima organizacional . . . . . . . . . . . . . . . . . . . . . . . 131 5.3.5. Cambio de la cultura y el clima organizacional . . . . . . . . . . 131 5.3.6. El crecimiento y desarrollo del negocio . . . . . . . . . . . . . . . 132 5.4. La gestión del conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . 133 6. Técnicas de Modelado de Procesos 137 6.1. Historia de técnicas y notaciones para modelado de procesos . . . . . . . 137 6.2. Clasificación de las técnicas de modelamiento . . . . . . . . . . . . . . . 142 6.3. Cadenas de procesos impulsadas por eventos (EPC) . . . . . . . . . . . 145 6.4. UML Diagrama de actividades . . . . . . . . . . . . . . . . . . . . . . . 148 6.5. Business Process Model and Notation (BPMN) . . . . . . . . . . . . . . 150 6.5.1. Historia del BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.5.2. Los elementos básicos de BPMN . . . . . . . . . . . . . . . . . . 151 6.5.3. La esencia de BPMN - Diferentes vistas de un proceso . . . . . . 152 6.5.4. Un proceso simple en BPMN . . . . . . . . . . . . . . . . . . . . 153 6.5.5. Participantes y flujos de mensajes . . . . . . . . . . . . . . . . . 155 6.5.6. Automatización de procesos con BPMN 2.0 . . . . . . . . . . . . 156 6.5.7. BPMN comparado con otras notaciones . . . . . . . . . . . . . . 157 7. Técnicas de Análisis y Mejora 159 7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 7.2. Reingenieria, Rediseño y Mejora . . . . . . . . . . . . . . . . . . . . . . 160 7.3. Clasificación y Tipos de Mejora . . . . . . . . . . . . . . . . . . . . . . . 163 7.3.1. Análisis de estructura . . . . . . . . . . . . . . . . . . . . . . . . 163 7.3.2. Análisis de ciclo . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.3.3. Análisis de costeo de actividades . . . . . . . . . . . . . . . . . . 169 7.3.4. Análisis de responsabilidades . . . . . . . . . . . . . . . . . . . . 170 7.4. Modelos de referencia de procesos . . . . . . . . . . . . . . . . . . . . . . 174
II Conceptos de Implementación 179 8. Conceptos Generales 181 8.1. Que se entiende por conceptos de implementación . . . . . . . . . . . . . 181 8.2. El círculo mágico de la BPM Suite . . . . . . . . . . . . . . . . . . . . . 181 8.3. Plataformas y herramientas de BPM y SOA . . . . . . . . . . . . . . . . 184 9. Capa BPG: Business Process Governance 191 9.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 9.2. Un concepto de implementación para BPM Governance . . . . . . . . . 192 9.2.1. Supuestos y entendimiento de los objetivos . . . . . . . . . . . . 192 9.2.2. Fundamentos conceptuales y metodológicos . . . . . . . . . . . . 193 9.2.3. Descripción del concepto de implementación de BPM Governance 194 9.2.4. Modelo estructural de BPM Governance . . . . . . . . . . . . . 195 9.2.5. Definición del marco metodológico . . . . . . . . . . . . . . . . . 198 9.2.6. Implementación de un Centro de Excelencia de BPM . . . . . . . 198 9.2.7. Modelo de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.2.8. Modelo de productos y servicios . . . . . . . . . . . . . . . . . . 204 9.2.9. Modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . 204 9.2.10. Estructuras organizacionales orientadas a procesos . . . . . . . . 205 9.2.11. Modelos de sistemas e Infraestructura de TI . . . . . . . . . . . . 210 9.2.12. Modelo de portafolio de proyectos . . . . . . . . . . . . . . . . . 213 9.2.13. Modelo de integración de capas . . . . . . . . . . . . . . . . . . . 216 9.2.14. Modelo de gestión sobre la arquitectura empresarial . . . . . . . 220 9.2.15. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 9.3. Gestión Operacional en BPM . . . . . . . . . . . . . . . . . . . . . . . . 221 9.3.1. Implementación del Ciclo-BPM . . . . . . . . . . . . . . . . . . . 221 9.3.2. Planificación de un proyecto de diseño de procesos . . . . . . . . 225 9.4. Selección de herramientas BPA . . . . . . . . . . . . . . . . . . . . . . . 226 9.5. Caso real: Introducción de BPM en Lufthansa Cargo AG . . . . . . . . 228 10.Capa BPE: Business Process Execution 231 10.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 10.2. Planificación de proyectos BPE . . . . . . . . . . . . . . . . . . . . . . . 236 10.2.1. Recepción de modelo operacional de la capa de negocio BPG . . 237 10.2.2. Diseño de arquitectura, de workflow y capa de presentación . . . 241 10.2.3. Configuración y desarrollo de la solución BPMS . . . . . . . . . . 242 10.2.4. Fase de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 10.2.5. Capacitación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 10.2.6. Traspaso a producción . . . . . . . . . . . . . . . . . . . . . . . . 246 10.3. Selección de herramientas BPMS . . . . . . . . . . . . . . . . . . . . . . 247 10.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 10.3.2. Caso de estudio del proceso de selección de un entorno BPMS . . 248 10.3.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 ÍNDICE GENERAL v 11.Capa SOA: Service Oriented Architecture 257 11.1. ¿Qué es SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
11.2. Servicios SOA desde el punto de vista técnico . . . . . . . . . . . . . . . 259 11.3. ¿Por qué existe SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 11.4. Modelo de una arquitectura SOA . . . . . . . . . . . . . . . . . . . . . . 261 11.5. Enterprise Service Bus (ESB) . . . . . . . . . . . . . . . . . . . . . . . . 264 11.6. Arquitectura SOA para BPM . . . . . . . . . . . . . . . . . . . . . . . . 274 12.Apéndice 277 12.1. Tendencias Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 12.2. Agradecimientos al lector . . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.3. Sobre el autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.4. BPM Terminología Inglés-Español . . . . . . . . . . . . . . . . . . . . . 281
Parte I Fundamentos del BPM Capítulo 1 Introducción y Definición del BPM 1.1. Introducción 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. Estos pueden ser cambios en el tipo de demanda o cambios de regulaciones. La capacidad que tienen las organizaciones de adaptar sus ofertas de bienes y servicios es parte fundamental del nuevo concepto de valor para los clientes. Los productos en si mismos no son lo suficientemente atractivos porque generalmente existe una sobre oferta y el elemento diferenciador son sobre 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. 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[Hitpass09]. Mucha gente se confunde con qué es realmente BPM y no es sorprendente si consideramos que la comunidad de BPM no ha logrado ponerse de acuerdo en una definición común[Hitpass08]. Actualmente 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, específicamente en Norteamerica, definen BPM como el proceso hacia la automatización y operación de los procesos implícitamente con TI. ¿Podemos entonces concluir que no existe un entendimiento común sobre BPM? El concepto de BPM es incluso más amplio que ambas visiones descritas recién, pero el entendimiento común se puede lograr a través de los objetivos que se persiguen con BPM, que por lo general todas las escuelas los comparten. Por lo general las diferencias de las escuelas se encuentra 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: 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 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 utilizados, 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 adaptarse mas rápido a los constantes cambios en el mercado, que son además cada vez mas frecuentes, tendrán mayores ventajas competitivas que aquellas que no logran adaptarse al ritmo que la globalización lo exige. La pregunta crucial es entonces: ¿Qué instrumentos están utilizando las empresas para lograr mayor agilidad, eficacia y eficiencia? La
respuesta es mayor control y eficiencia en la capacidad de cambio en sus procesos de negocio, porque a través de los procesos se crea valor para los clientes, ¿como hacerlo? A partir de principios de las años 90 nace la idea en los países industrializados de integrar las diferentes disciplinas de gestión corporativas directamente con la operación de los procesos. En una publicación de Smith and Fingar en el año 2002 con el título BPM Third Wave[SmithFingar02], aparece por primera vez el acrónimo BPM. Académicos, profesionales y proveedores de TI captan rápidamente la importancia y el interés por BPM. La tendencia ha ido creciendo día a día y se han hecho grandes inversiones en el desarrollo de técnicas, metodologías y soluciones para BPM. BPM es una disciplina integradora que engloba técnicas y disciplinas, que abarca las capas de estrategia, negocio y tecnología, que se comprende como un todo integrado en gestión a través de los procesos. BPM en este trabajo se va a explicar y tratar en dos grandes partes: 1. Fundamentos de BPM, que introduce al tema a través de un trasfondo histórico para comprender mejor la evolución de la ingeniería de procesos hacia el BPM actual. Se dedica una sección para conocer y entender las definiciones que facilitan comprender el alcance de BPM. Los últimos capítulos de esta parte del libro, presentan el estado del arte de los conceptos teóricos vinculados con BPM. 2. Conceptos de Implementación BPM, capítulos que analizan y tratan formas de implementación, entendiéndose los conceptos presentados como procesos planeados del cambio para poner en funcionamiento la gestión correspondiente de BPM en cada una de las capas de la organización. La segunda parte integra a los modelos de procedimiento el apoyo tecnológico en cada una de las capas del BPM.
1.2. Trasfondo histórico 1.2.1. La ingeniería de procesos nace con Frederick Taylor La idea de que las actividades (el trabajo) se pueden describir como un proceso no es nueva. A principios del siglo pasado Frederick Winslow Taylor (1911) desarrolló el concepto de la “Administración Científica” [TaylorFre08]1. A F.W. Taylor se le atribuye haber desarrollado los principios de la especialización y estandarización de los procesos en la producción industrial elevándolos a una ciencia que podríamos llamar «ingeniería industrial y mejora de procesos», razón por la cual muchos autores lo denominan como el padre de la ingeniería industrial. Taylor aporta en métodos de observación de buenas prácticas, de medición del trabajo y a partir de estos conocimientos de diseñar procesos industriales desagregados hasta el nivel de actividad2manual 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 [Bravo09]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. 1 Taylor publicó poco antes de morir (1915) en 1911 su obra que lo hizo tan famoso «The Principles of Scientific M anagement». 2Taylor hablaba de «administración de tareas»
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 [Bravo09]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 fundamento científico para diseñar y mejorar los procesos. Con estos fundamentos pretendía terminar con la improvisación que predominaban en aquella época. En vez de hacer que cada trabajador hiciera la tarea a su manera, Taylor quería encontrar la forma óptima de hacerla y estandarizar las buenas prácticas haciéndolas mas 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 Mas adelante, a principios de los 80, aparecieron enfoques estadísticos con el objetivo de mejorar los procesos de control. Así nació el enfoque TQM (Total Quality Management) basado en una gestión de control estadístico, pero aplicarlo requiere de una rigurosa disciplina en la organización que es difícil de alcanzar. Empresas japonesas, en particular Toyota, reconocieron a principios de los 90 el cambio hacia el mercado de la demanda3 y enfocaron la gestión orientada hacia las necesidades del negocio (clientes). 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 3 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 mas influyente que el poder que pueden ejercer los proveedores en los mercados en que operan.
procesos de producción. A este sistema de trabajo se le llamó también Lean Production, indicando en quitarle grasa a las estructuras organizacionales burocráticas y lentas en sus procesos de decisiones. Cuando en los años 90 muchas empresas occidentales fueron azotadas por la recesión, debido a que los mercados habían llegado a una situación de la sobre oferta (saturación, cambio hacia el mercado de la demanda) y el comienzo de la globalización, aparece el Business Process Reengineering (BPR, Hammer and Champy, 1993)[HamCham93] como medida de salvación para deburocratizar las empresas y ser mas eficientes en sus procesos de negocios.
1.2.3. La reingeniería de procesos como precursor de BPM 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 espectaculares a corto plazo. La reingeniería de procesos se basa y apoya fuertemente en la incorporación de tecnologías de la información, como elemento clave para la transformación esperada. El BPR es el primer enfoque end to end de introducir como gestión procesos de negocios transversales a las organizaciones funcionales, centrados en las necesidades del cliente y no en los procesos de producción, pero esto no fue fácil, muchos proyectos de BPR terminaron siendo proyectos de racionalización de recursos con una fuerte reducción de personal. Perdiendo, muchas veces, la perspectiva de agregación de valor para el cliente. BPR no fue el único enfoque en aparecer en dichas décadas, a principio de los años 80 apareció Six Sigma como una opción para mejorar la eficacia y eficiencia de los procesos de negocio. Este enfoque surgió en Motorola Inc. y el caso práctico de aplicación más conocido fue General Electric en los ’90. Como TQM, Six Sigma se basa en principios estadísticos para mejorar los procesos de control y mejora. La sigla Six Sigma significa “one output defect in six Standard deviations of a probability distribution for a particular process output”. Las técnicas de Six Sigma se emplean sobre la base de episodios o eventos, los cuales debiesen estar dentro del nivel de exigencia definida para el proceso (cantidad de Sigmas), pero no incorporan un pensamiento de mejora continua. Muchas empresas combinan el enfoque de Six Sigma con TPS o Lean Production. Aún no se puede predecir como va a seguir evolucionando Six Sigma, pero a pesar de que se detectan signos de cansancio aun está muy difundido en empresas norteamericanas (Davenport, foreword BPM Jeston and Nelis, 2008)[JestonNelis08]. A mediados de los 90 aparece la ola de los ERP’s (Enterprise Resource Planning). Los ERP’s se vendieron como la solución para
todos los problemas en la organización, pero los ERP’s no generaron la eficiencia y eficacia esperada en los procesos de negocios, estaban diseñados para mejorar la eficiencia administrativa. 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 aun no contábamos con una integración entre los procesos del front office (CRM) con los del back office (ERP). Según Smith and Fingar [SmithFingar02]BPM se puede concebir como la tercera gran ola en la evolución de la ingeniería de procesos, después de TQM, Six Sigma y BPR. La figura 1.1 muestra en el eje del tiempo los principales hitos que fueron marcando la evolución de la ingeniería de procesos hasta el BPM actual.
Figura 1.1: Evolución de la Ingeniería de Procesos hacia el BPM Desde principios del siglo XX, caracterizado por el comienzo de la 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 jerarquizació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 clientes4. 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í 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.
1.3. Definiciones 1.3.1. ¿Qué es un proceso? En principio, un proceso corresponde a la representación de un conjunto de acciones (actividades) que se hacen, bajo ciertas condiciones (reglas) y que puede gatillar o ejecutar cosas (eventos). En forma genérica se puede definir un proceso como: «Una concatenación lógica de actividades que cumplen un determinado fin, a través del tiempo y lugar, impulsadas por eventos5.» 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 si 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 destinados a producir bienes y servicios. 4Estos conceptos se explicarán en la sección 1.3.25Estas definiciones fueron desarrolladas por el autor para sus cátedras de BPM
A diferencia de los eventos, las actividades en un proceso consumen tiempo y recursos. Una actividad se puede definir como una «acción sobre un objeto», es decir el proceso de transformación ocurre a través de las actividades en un proceso. Las actividades en un proceso están encadenadas a través de una secuencia lógica que determinan en su conjunto las condiciones del negocio. Estos elementos básicos describen en su conjunto los procesos y están contenidos en la mayoría de las notaciones para modelarlos, así también en el estándar BPMN. La definición es pura, no dice nada respecto para que objetivos se levantan y modelan procesos en una organización.
1.3.2. ¿Qué es un proceso de negocio? Hamer y Champy introducen en su obra de Reingeniería de Procesos en el año 93 [HamCham93]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 de que es gatillado por el cliente y los resultados de la ejecución del proceso tiene que volver al cliente. 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. Es normal encontrar en muchas compañías combinaciones de ambos tipos de flujos, en particular para responder con mayor oportunidad a los requerimientos de los clientes. El proceso de negocio es transversal a las áreas y atraviesa la cadena de valor de principio a fin6. Este principio es indistinto si se trata de un cliente externo (cliente final) de la empresa o cliente interno. 6También se usa mucho el término anglosajón «end to end».
Muchas veces se confunden los macroprocesos con los procesos de negocio. Por lo general corresponden los macroprocesos con las grandes áreas de negocio de una empresa como por ejemplo abastecimiento, producción, bodega, venta, etc.. Ningún cliente externo va a gatillar un proceso en el área de abastecimiento y los procesos en este área tampoco atraviesan la cadena de valor de la empresa. A pesar de que estas áreas pueden ser muy grandes y muy complejas no tienen relación directa con el concepto de proceso de negocio: gatillado por el cliente,
de principio a fin y el resultado tiene que ser de valor para el cliente. Los procesos de negocio se encuentran debajo de los macroprocesos y los atraviesan. Al mapear los procesos de una organización en muchas ocasiones se cometen grandes errores al respecto. Si se descomponen «top down» los macroprocesos se van a mapear los procesos internos de las áreas en diferentes grados de abstracción, y justamente estos no son los procesos de negocio. ¿Cómo se pueden identificar entonces los procesos de negocio? Para estos efectos se recomienda realizar un análisis del contexto y hacer un listado de todos los eventos iniciados por el cliente. A continuación se nombran ejemplos de procesos de negocio: Solicitudes de créditos, préstamos, devoluciones Solicitud de apertura de cuenta bancaria Compra de pasajes Procesos de reclamaciones Seguimiento de resolución de problemas en Servicio a Clientes Gestión de Hipotecas, Multas, ... Recepción y pago de factura Recepción y confirmación de orden de compra Elaboración de ofertas Los siguientes ejemplos no se pueden clasificar como procesos de negocio. Partida doble en contabilidad • Se trata de una función contable, que le sigue a un movimiento contable Reserva de pasajes • Se trata de un subproceso del proceso de negocio «compra de pasajes». En este caso no se cumple el principio de finalidad, que sería la compra del pasaje. Ingreso de un nuevo empleado al sistema de RRHH • Actividad manual del proceso de negocio «contratación de personal». El cliente interno es el área de negocio, quién gatilla la solicitud de contratación. Ingreso de una orden de compra • Actividad manual del proceso de negocio «compra de un producto o servicio». Envío de email • Actividad técnica sin significado de negocio Emitir una póliza • Emitir puede significar imprimir, generar o extender una póliza de seguros, pero de todas formas el proceso de negocio sería la «solicitud de un contrato de seguros» 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 cliente7. 7 En el foro de BPTrends en Linkedin Paul Harmon comenta en el debate «Value chain diagram?» al respecto: «Porter, when he first defined a Value Chain, included "all activities that must be performed to generate the desired value..." and showed management and support processes – but that was in 1985. (Keep in mind, too, that Porter was primarily focused on accounting models and not on a process architecture.)», revisado 06-03-12.
Figura 1.2: Estructura de Cadena de Valor según Porter La figura 1.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. La figura 1.3 muestra la transversalidad de los procesos de negocio que son impulsados por clientes y cuyos resultados tienen que volver a ellos.
Figura 1.3: Estructura de procesos de negocio 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).
1.3.3. ¿Gestión de o por procesos de negocio? El lector seguramente muchas veces habrá escuchado hablar de «gestión de procesos» pero también de «gestión por procesos». ¿Se habrá preguntado alguna vez si existe alguna diferencia? 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 que estado se encuentra cada uno de los procesos instanciados. Por ejemplo saber sobre la carga de trabajo de cada uno de los usuarios y saber cuales procesos se encuentran estancados por alguna razón. Esta información le permite al supervisor (= gestor del proceso) detectar problemas antes de que impacten sobre los resultados. Al tener mayor control sobre lo que está sucediendo podemos mejorar el desempeño de los procesos, por ejemplo acortar los tiempos de ciclo y en general mejorar el grado de satisfacción de cliente. Al introducir «gestión de procesos» en una organización tenemos la posibilidad de mejorar el grado de cumplimiento de objetivos funcionales, pero no es un instrumento suficiente para alinear la gestión de procesos con la estrategia de la organización y sus debidos objetivos de negocio. La gestión de procesos se focaliza en medir y analizar el desempeño de los procesos en operaciones, pero no incluye los conceptos de alineamiento con otras capas de la organización, por ejemplo la integración a los procesos de alineamiento con la estrategia y la capa de tecnología. La figura 1.2 muestra esta diferencia: Gestión por procesos significa incluir los procesos de planificación y alineamiento a la gestión de procesos.
Figura 1.4: Diferencia entre: Gestión «de» y «por» Procesos Entre académicos y profesionales de BPM es ampliamente conocido el principio de que «los procesos deben seguir la estrategia» y de que «la tecnología debe seguir a los procesos». Gestión de procesos no incluye estos ciclos de planificación y de alineamiento a los procesos como lo pide la disciplina de gestión BPM, pero si ampliamos el concepto de gestión e integramos las otras disciplinas empresariales a la gestión de procesos, entonces hablamos de «gestión por procesos» y en su definición mas amplia en inglés de Business Process Management (BPM).
1.3.4. Gestión tradicional sin BPM
En la sección anterior describimos la diferencia entre gestión de y por procesos, pero aun no hemos dicho en que aporta para la gestión empresarial introducir BPM en una organización. Para responder a esta pregunta fundamental vamos a analizar primero como funciona la gestión tradicional centrada en consolidar planes de negocio por área y no por procesos de negocio que son transversales a la organización. Por lo general la formulación de la estrategia de una empresa es amplia y define los grandes hitos que se deben lograr y sobre todo en que hay que centrarse para cumplir con la misión de la empresa y los objetivos de negocio que se formulan a través del ciclo presupuestario en un año comercial, pero la estrategia es transversal a las áreas de negocio, igual que los procesos de negocio. Aquí nos encontramos en la gestión empresarial tradicional con la primera brecha.
Figura 1.5: Gestión tradicional sin BPM De alguna forma se traspasan los objetivos de negocio desde la alta dirección a la capa de operaciones y a su vez operaciones formula, por medio de una especificación, los requerimientos de cambio a la capa de tecnología, pero este proceso no está estandarizado y menos integrado bajo una metodología común. Al no estar estandarizado ni integrado ocurren fricciones y por lo tanto pérdida de valor. Como la estrategia es transversal y no existe un cargo que se responsabilice por el rendimiento del proceso completo, vale decir de principio a fin, los procesos de alineamiento son lentos y de alto costo. Así se produce pérdida de valor en tres grandes ámbitos de la gestión empresarial tradicional, a saber: 1. Como plasmar la estrategia en la organización (primer gap) 2. Como lograr que los procesos se implementen con tecnología (segundo gap) 3. Pérdida de valor en la estructuración misma de los procesos (tercer gap) 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.
1.3.5. Definiciones: Business Process Management (BPM) A partir de principios de las años 90 nace la idea en los países industrializados de integrar las diferentes disciplinas de gestión corporativas directamente con la operación de los procesos. En una publicación de Smith and Fingar en el año 2002 con el título BPM Third Wave[SmithFingar02], aparece por primera vez el acrónimo BPM. Académicos, profesionales y proveedores de TI captan rápidamente la importancia y el interés por BPM. La tendencia ha ido creciendo día a día y se han hecho grandes inversiones
en el desarrollo de técnicas, metodologías y soluciones para BPM. Volviendo entonces a nuestra pregunta inicial si existe a nivel global un entendimiento común respecto de lo que es BPM, podemos concluir que si, aunque las definiciones de algunos autores se diferencien en algunos aspectos. Jeston y Nelis [JestonNelis08]definen BPM como: «BPM es el logro de los objetivos empresariales a través de la mejora, la gestión y el control de los procesos de negocio8.» En esta definición, se abstrae explícitamente de la tecnología con el fin de no confundir al lector, de que la tecnología le va a solucionar los problemas a las organizaciones. Paul Harmon [Harmon07] también define BPM como: «Una disciplina de gestión focalizada en la mejora del rendimiento corporativo por medio de la gestión por procesos de negocio9.» Finalmente Jeston y Nelis [JestonNelis08]concluyen, BPM es: mas que solo software, mas que solo la mejora o la reingeniería de los procesos, no es solo una moda, es parte integral del management, mas que solo levantamiento y modelado de procesos, también es la implementació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 8 Cita original: BPM is the achievement of an organization s objectives through the improvement, management and control of essential business process. 9Cita original: «a management discipline focused on improving corporate performance by managing a company s business process».
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 una «Disciplina de Gestión por Procesos de Negocio y de Mejora Continua apoyada fuertemente por las Tecnologías de la Información» Una definición mas amplia la encontramos en la guía de referencia de la Asociación Internacional de Profesionales de BPM (BPM Common Body of Knowledge, ABPMP10)[ABPMP09]11: «Business Process Management (BPM) es un enfoque sistemático para identificar, levantar, documentar, diseñar, ejecutar, medir y controlar tanto los procesos manuales como automatizados, con la finalidad de lograr a través de sus resultados en forma consistente los objetivos de negocio que se encuentran alineados con la estrategia de la organización. BPM abarca el apoyo creciente de TI con el objetivo de mejorar, innovar y gestionar los procesos de principio a fin, que determinan los resultados de negocio, crean valor para el cliente y posibilitan el logro de los objetivos de negocio con mayor agilidad.» Como lo indica la definición de la ABPMP, BPM es una disciplina integradora que engloba técnicas y disciplina parciales, 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 10 Association of BPM Professionals11Cita original: “Business Process M anagement” (BPM ) is a disciplined approach to identify, design, execute, document, measure, monitor, and control both automated and non-automated business processes to achieve consistent, targeted results aligned with an organization’s strategic goals. BPM involves the deliberate, collaborative and increasingly technology-aided definition, improvement, innovation, and management of end-to-end business processes that drive business results, create value, and enable an organization to meet its business objectives with more agility. BPM enables an enterprise to align its business processes to its business strategy, leading to effective overall company performance through improvements of specific work activities either within a specific department, across the enterprise, or between organizations.
inclinamos por esta definición porque diferencia entre procesos manuales y automatizados, pero integra ambos casos a la disciplina de BPM. Con esta definición pretendemos lograr un entendimiento común que es necesario para tener éxito en introducir BPM en una organización. Para lograr los objetivos que se persiguen en BPM es necesario sincronizar e integrar los procesos manuales con los implementados con apoyo de TI o los que se van a automatizar.
1.3.6. ¿BPM una nueva moda que se va a desinflar? Sin lugar a dudas BPM es una tendencia en el mercado que aparece como «marca» hace aproximadamente una década atrás tomando cada vez mas fuerza y que se ha convertido en «moda». Según Jeston y Nelis [JestonNelis08] se han descubierto 4 fases que describen como se desarrollan estas tendencias: 1. Los vendedores y empresas analistas promueven un tema con mucha publicidad, investigaciones, estudios de mercado y casos de éxito (the next big thing). 2. Los promotores tienden a desprestigiar todas las modas pasadas (the old big things) que los precedían y predican que lo nuevo es indudablemente lo mejor. 3. El próximo paso es difundir que lo nuevo es “muy simple”, de forma que los ejecutivos puedan entenderlo. El mensaje que transmiten es que la nueva técnica o solución no tiene complicaciones y es fácil de implementar. 4. Finalmente los proveedores o vendedores en particular ofrecen sus productos nuevos o existentes bajo el sello de la nueva marca (en este caso BPM). Generalmente la nueva marca comienza a comercializarse y simultáneamente empiezan a emerger los mismos problemas. Efectivamente podemos constatar que en la actualidad el tema BPM es uno de los más importantes en las agendas de las organizaciones. Por tanto, ¿Podemos escapar de ello? ¡Por lo general no! Es parte de la evolución de la tecnología. El problema radica, en que los vendedores lo plantean como algo simple, que reemplaza las soluciones pasadas y ese es justamente el mensaje errado. Las nuevas tendencias integran soluciones pasadas y no las reemplazan y por otro lado no son más simples sino por lo contrario, al ser integradoras son más complejas. BPM no es un concepto simple y no es fácil de implementar, es extremadamente complejo y difícil según [JestonNelis08], pero crea valor para los clientes y para el negocio. Además responde a los desafíos de los mercados globales con un alto impacto en el logro de los objetivos empresariales (eficacia). No hay alternativas o escapatorias, es el grado de evolución en el que nos encontramos. El mercado globalizado exige cercanía individual hacia los clientes y eficiencia operacional con bajos márgenes. Empresas que no sean capaces de realizar esta eficiencia no van a subsistir en los mercados globalizados.
Capítulo 2 La Organización y la Estructura del BPM 2.1. Conceptos de Gestión en BPM BPM como disciplina de gestión orientada a procesos abarca dos grandes áreas de la gestión empresarial: BPM Governance1 y BPM Operacional El concepto de BPM Governance 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 diferente nivel de madurez en cuanto a su implementación de BPM, en cambio el BPM Governance es un solo modelo de gestión corporativo 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. En el capítulo 9 se presentará un concepto de implementación para estos dos modelos de gestión en BPM, como modelos de referencia. 1 La palabra inglesa «governance» se viene utilizando hace un tiempo como sinónimo de «dirección política o empresarial», también como componente de un «gobierno corporativo», por ejemplo ITGovernace que busca alinear la estrategía de TI con el negocio.
21
2.1.1. BPM Governance Vamos a definir BPM Governance, también llamado gobierno corporativo, como un modelo de gestión corporativo orientada a procesos pero integrada con todas las capas de una organización2, las fases del ciclo de gestión, la gestión del cambio de nuevos requerimientos3, la estructura organizacional y todos los instrumentos de alineamiento de y entre las estructuras corporativas. BPM Governance abarca el alineamiento con todo el ciclo de gestión corporativa desde la planificación y gestión estratégica, la definición de planes de negocio, el ciclo presupuestario, la definición de perfiles y cargos, la gestión en operaciones, apoyo tecnológico hasta el alineamiento con el portafolio de proyectos corporativo. En la literatura se encuentran varias definiciones de BPM Governance [Harmon08, Khusidman10, Spanyi08, Kirchmer09, JestonNelis08], la mayoría de ellas muy amplias pero todas coinciden que se trata de un concepto definido para una organización de como debe aplicarse «Gestión por Procesos» y que integra instrumentos y disciplinas existentes en torno a los procesos de negocio. Harmon [Harmon08]discrimina primero entre «governance» y «management», explicando que «governance» es la organización del «management». Resumiendo a su entender cuando hablamos de governance nos referimos a un modelo específico de gestión, mientras que «gestión» es una actividad humana. Para Jeston y Nelis [JestonNelis08] 4en un modelo de BPM Governance son clave la definición de roles y responsabilidades, los procesos de alineamiento con la estrategia de la empresa, control de gestión orientado a procesos y finalmente la estandarización de los procesos de gestión. Kirchmer [Kirchmer09] define Business Process Governance como un conjunto de medidas y procedimientos orientados a alinear todos los servicios de BPM que apoyen la gestión por procesos de negocio. El entregable de este conjunto de medidas e instrumentos es un framework o marco estructural y metodológico que sirve como manual y guía de referencia que orienta a los gestores en introducir y operar bajo el concepto de BPM.5 2 Capa de dirección, operacional y capa de tecnología3en inglés: Change M anagement4Véase sección Governance en [JestonNelis08], pags. 323-3245Business Process Governance (BPG) is a set of guidelines focused on organizing all BPM activities and initiatives of an organization to manage all of its business processes. The resulting governance framework provides the frame of reference to guide organizational units of an enterprise and ensure responsibility and accountability for adhering to the
BPM approach. In its simplest terms, BPG can be considered the “definition” layer of BPM and contributes to the definition and allocation of power and authority in the enterprise by specifying the governance framework.
2.1.2. BPM Operacional En el entendimiento del autor el BPM Operacional abarca la gestión del ciclo BPM por proceso y no los mecanismos de alineamiento con las otras capas de la organización que es dominio de un modelo de 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.
Figura 2.1: El ciclo de BPM por proceso Fuente: [FreRueHit11] 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 de 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 documenta en un modelo de procesos que refleja la situación actual. La documentación resultante comprende los diagramas de los flujos, fichas de descripción, políticas de negocio y procedimientos que se utilizan para ejecutar el trabajo. Las debilidades identificadas en la fase de “Análisis de mejora” o las desviaciones que muestra el “Monitoreo del Proceso” son por lo
general el punto de partida para un rediseño de procesos. Eventualmente, se pueden evaluar diferentes variantes o escenarios con ayuda de simuladores. Esto aplica también si se está diseñando un proceso nuevo. En ambos casos el resultado o entregable es un modelo de procesos deseado (To be). La etapa de “Implementación del Proceso” abarca tanto la implementación técnica como también las adaptaciones organizacionales que se requieren. La gestión del cambio (en inglés: Change Management) y la estrategia de comunicación constituyen elementos fundamentales a considerar para el éxito del proyecto. El modelo técnico puede implementarse por medio de una Suite de BPM (en inglés: Business Process Management Suite, BPMS)6 o a través de un clásico desarrollo de software. El resultado final de la implementación técnica del proceso en la situación actual (As is) automatizado y documentado, 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” (en 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 operaciones7y su respectiva evaluación de los indicadores. De acuerdo a la escuela de BPM, si se detectan problemas puntuales debieran corregirse de inmediato o en línea. Si hay recursos disponibles es posible solucionar problemas estructurales sin necesidad de formular un proyecto, pero si sus causas no están claras o son complejas, se hace necesario planificar e implementar un proyecto de mejora y rediseño8. La decisión sobre si es necesario formular un proyecto nuevo o instalar un equipo de trabajo en operaciones, debiera tomarla el responsable del proceso de común acuerdo con los participantes. Con esta breve explicación de cómo funciona el ciclo de BPM, el lector se dará cuenta de la importancia que tienen los modelos de procesos en BPM y junto a ello 6 En la literatura y en el mercado se utilizan varios términos para sistemas que implementan procesos: sistema de workflow (WfM ), Business Process M anagement Suite (BPM S), motor de workflow y Process Engine. Por lo general la Suite de BPM (BPM S) es el entorno mas completo que trae todas componentes integradas (modelador técnico, motor de workflow, panel de control, interfaz de usuario, APIS de integración y en algunos casos Enterprise Service Bus (ESB). 7Técnicamente hablamos del control de instancias de los procesos reales 8Ver capítulo 7 Técnicas de Análisis y M ejora
la importancia que puede adquirir un estándar de modelamiento y ejecución como BPMN (Business Process Model and Notation)9. El lector puede constatar también que el modelamiento de procesos no es una etapa del ciclo de BPM, sino que es más bien una actividad transversal, porque de facto se aplica en casi todas las fases del ciclo, sobre todo en las fases de “Documentación del Proceso”, “Diseño As is” y “Diseño To be”. Desgraciadamente, siempre nos volvemos a encontrar con gente que confunden la “Documentación del Proceso” con el modelamiento del proceso y lo incluyen como una fase en el ciclo; esto es una equivocación. El ciclo BPM muestra en sus principales fases cómo funciona el círculo virtuoso de mejora continua de los procesos. Para aplicarlo es necesario: Asignar responsabilidades a los procesos y a cada uno de sus pasos Emplear métodos de análisis y gestión en él Contar con el apoyo de soluciones adecuadas de TI Lograr una coordinación fluida entre estas tres componentes es tarea de gestión por procesos (BPM-Governance). Gestión por procesos se encuentra por sobre cualquier proyecto de modelamiento y tiene por consiguiente la misión de apoyar la «Gestión de Procesos», para el cumplimiento de los objetivos estratégicos.
2.1.3. Gestión de Casos - Case Management Un caso, como un proceso de negocio, consiste en un conjunto de actividades o tareas. Sin embargo, a diferencia de un flujo predeterminado, el proceso desde su inicio hasta la finalización no está limitado a una secuencia del proceso como lo entendemos normalmente, de principio a fin, aunque con una lógica compleja de anidación y encadenamiento. ¿Qué actividades se deben realizar para completar el caso? Depende de los detalles de cada caso. Por lo general, el encargado del caso, o tal vez todos los participantes de una tarea, tomarán esta decisión. Las "reglas", por así decirlo, son conocimiento experto de los usuarios. En la literatura también se habla de «adaptive case management (ACM) o dynamic case management» , en donde se argumenta que el foco
se centra mas 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 que procesos de diagnóstico o de apoyo terapéutico se van a emplear y cuando 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 9Ver sección 6.5
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 característica esencial y distintiva en la gestión de casos es su ausencia de estructura y rigidez en la secuencia o progresión desde el inicio hasta su estado final. En un flujo determinado, por definición, una instancia de proceso avanza a través de una secuencia de pasos que se puede describir explícitamente como caminos en una ruta, que va desde un solo punto al comienzo a uno o más puntos finales. La lógica de ruta puede ser determinada por la lógica de negocio, acontecimientos externos, y reglas del negocio, pero los pasos, la lógica de bifurcación, y los caminos son una excepción y definidos de antemano. En el manejo de casos, por el contrario, la lógica de flujo no se puede expresar en una lógica que se define con antelación. Dado lo anterior son actores preponderantes el juicio humano, acontecimientos (eventos) externos y reglas propias del negocio que intervienen libremente sin un patrón único de flujo. En cambio los factores determinan en tiempo de ejecución las actividades que se deben llevar a cabo y qué medidas adicionales son necesarias, ya sea elegido de un menú predefinido o concebido sobre la marcha. A pesar de su carácter semi-estructurado o por decirlo de otra forma no predecibles, los procesos de casos tienen los mismos problemas que los procesos estructurados: Toman demasiado tiempo en completarse Los recursos no son utilizados de manera eficiente La información está fuera de lugar o no aceptada No hay estandarización en toda la organización Dificultad en el cumplimiento de las políticas, regulaciones y mejores prácticas Falta de visibilidad del rendimiento, ya sea a nivel de casos individuales en tiempo real o las tendencias históricas La gestión de casos no suele trabajar por la carpeta de enrutamiento del caso a la siguiente tarea de forma secuencial en la línea. En su lugar, los avances son a través de eventos, tanto externos como internos: Los eventos externos afectan el caso. El contenido de ese mensaje se agrega a la carpeta del caso y nuevas tareas o procesos pueden ser creados. Los eventos internos incluyen las asignaciones y reglas del negocio. Los trabajadores de casos asignan tareas e inician los procesos que consideren necesarios en su trabajo sobre el caso. Las reglas del negocio pueden crear y asignar tareas o llevar a cabo plenamente las acciones automatizadas sobre la base de cualquiera de los eventos externos, la realización de las tareas de los demás casos, o el vencimiento de los plazos de trabajo. Así, de un flujo determinado, el modelo conceptual de un caso es una colección visible de tareas en conjunto con los documentos y carpeta 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 aun no han alcanzo un nivel de estandarización ¿Cuales 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: *
