Sistemas "Workflow" y BPM ("Business Process Management") como herramientas para la automatización y mejora de la productividad en las organizaciones: metodología para la implantación y casos de estudio

UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA Doctorado en Ciencias Económicas y Empresariales DEPARTAMENTO DE ECONOMÍA Y DIRECCIÓN DE EMPRESAS Programa de Gestión en la Nueva Economía TÍTULO DE LA TESIS Sistemas Workflow y BPM (Business Process Management) como herramientas para la automatización y mejora de la productividad en las organizaciones: metodología para la implantación y casos de estudio Tesis doctoral presentada por don Mario Marrero Ruiz Dirigida por el Profesor Doctor don Jacques Bulchand Gidumal y por el Profesor Doctor don Jorge M. Rodríguez Díaz Anexo II UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA Departamento/Instituto/Facultad: Economía y Dirección de Empresas Programa de doctorado: Gestión en la Nueva Economía Título de la Tesis Sistemas Workflow y BPM (Business Process Management) como herramientas para la automatización y mejora de la productividad en las organizaciones: metodología para la implantación y casos de estudio. Tesis doctoral presentada por: D. Mario Marrero Ruiz Dirigida por el Dr. D. Jacques Bulchand Gidumal Codirigida por el Dr. D. Jorge M. Rodríguez Díaz El Director El Codirector El Doctorando D. Jacques Bulchand D. Jorge Rodríguez D. Mario Marrero Gidumal Díaz Ruiz Las Palmas de Gran Canaria, a 10 de noviembre de 2015 UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA Doctorado en Ciencias Económicas y Empresariales DEPARTAMENTO DE ECONOMÍA Y DIRECCIÓN DE EMPRESAS Programa de Gestión en la Nueva Economía TÍTULO DE LA TESIS Sistemas Workflow y BPM (Business Process Management) como herramientas para la automatización y mejora de la productividad en las organizaciones: metodología para la implantación y casos de estudio Tesis doctoral presentada por don Mario Marrero Ruiz Dirigida por el Profesor Doctor don Jacques Bulchand Gidumal y por el Profesor Doctor don Jorge M. Rodríguez Díaz Este trabajo está dedicado a mis dos grandes tesoros: Eli y Nira AGRADECIMIENTOS En primer lugar agradecer este trabajo a mis dos directores de tesis, Dr. D. Jacques Bulchand Gidumal y Dr. D. Jorge Rodríguez Díaz por la enorme disposición, esfuerzo y conocimientos aportados al presente trabajo. Sin su constancia, este trabajo no hubiese visto la luz. En segundo lugar agradecer a todas aquellas organizaciones públicas y privadas donde este trabajo se ha podido poner en marcha. La experiencia adquirida en dichas implantaciones ha ayudado enormemente a la creación del presente trabajo. Por último agradecer a toda mi familia su paciencia en este periodo y su apoyo incondicional en todos los sentidos. 5.4 Comparativa entre la metodología Scrum y la propuesta ......................... 270 CAPÍTULO VI. MÉTODO DE INVESTIGACION ..................................................... 275 6.1 Método de investigación ........................................................................... 277 6.1.1 Fase de diagnóstico ........................................................................... 280 6.1.2 Fase de planificación de la acción ..................................................... 281 6.1.3 Fase de ejecución de la acción .......................................................... 282 6.1.4 Fase de evaluación de los resultados ................................................ 282 6.1.5 Fase de conocimiento adquirido ........................................................ 283 6.2 Descripción de los casos de estudio ......................................................... 283 CAPÍTULO VII. CASOS DE ESTUDIO EN ORGANIZACIONES PÚBLICAS Y PRIVADAS .............................................................................................................. 291 7.1 Caso de estudio 1: Creación de un CRM .................................................. 293 7.1.1 Necesidades reales ........................................................................... 295 7.1.2 ¿Qué es un CRM? ............................................................................. 296 7.1.3 Trabajos previos realizados y experiencias anteriores. ..................... 298 7.1.4 Entorno actual de sistemas en la empresa ........................................ 299 7.1.5 Desarrollo de la metodología y resultados obtenidos ........................ 300 7.1.5.1 Fase de análisis .......................................................................... 300 7.1.5.2 Fase de diseño rápido (mockups) ............................................... 302 7.1.5.3 Fase de creación de workflows................................................... 303 7.1.5.4 Fase de implantación .................................................................. 310 7.1.5.5 Fase de puesta en marcha y mantenimiento .............................. 314 7.1.6 Consideraciones finales al caso de estudio ....................................... 314 7.2 Caso de estudio 2: Creación de un gestor de expedientes en una administración pública local ............................................................................. 315 7.2.1 Necesidades reales ........................................................................... 316 7.2.2 ¿Qué es un gestor de expedientes? .................................................. 317 7.2.3 Trabajos previos realizados y experiencias anteriores. ..................... 319 7.2.4 Entorno actual de sistemas en la administración local....................... 321 7.2.5 Desarrollo de la metodología y resultados obtenidos. ....................... 322 7.2.5.1 Fase de análisis .......................................................................... 322 7.2.5.2 Fase de diseño rápido (mockups) .............................................. 324 7.2.5.3 Fase de creación de workflows .................................................. 325 7.2.6 Fase de implantación ........................................................................ 332 7.2.6.1 Fase de puesta en marcha y mantenimiento ............................. 334 7.2.7 Consideraciones finales al caso de estudio ....................................... 334 7.3 Caso de estudio 3: Creación de un ERP en una empresa de servicios ... 335 7.3.1 Necesidades reales ........................................................................... 336 7.3.2 ¿Qué es un sistema ERP? ................................................................ 336 7.3.3 Trabajos previos realizados y experiencias anteriores ...................... 338 7.3.4 Entorno actual de sistemas en la empresa ........................................ 339 7.3.5 Desarrollo de la metodología y resultados obtenidos. ....................... 340 7.3.5.1 Fase de análisis ......................................................................... 340 7.3.5.2 Fase de diseño rápido (mockups) .............................................. 344 7.3.5.3 Fase de creación de workflows .................................................. 344 7.3.5.4 Fase de implantación ................................................................. 349 7.3.5.5 Fase de puesta en marcha y mantenimiento ............................. 353 7.3.6 Consideraciones finales al caso de estudio ....................................... 353 7.4 Caso de estudio 4: Creación de una herramienta de gestión de proyectos en una empresa pública. ................................................................................. 354 7.4.1 Necesidades reales ........................................................................... 354 7.4.2 ¿Qué es una herramienta de gestión de proyectos? ......................... 355 7.4.3 Trabajos previos realizados y experiencias anteriores. ..................... 356 7.4.4 Entorno actual de sistemas en la empresa bajo estudio ................... 356 7.4.5 Desarrollo de la metodología y resultados obtenidos. ....................... 357 7.4.5.1 Fase de análisis ......................................................................... 358 7.4.5.2 Fase de diseño rápido (mockups) .............................................. 360 7.4.5.3 Fase de creación de workflows .................................................. 360 7.4.5.4 Fase de implantación ................................................................. 364 7.4.5.5 Fase de puesta en marcha y mantenimiento ............................. 366 7.4.6 Consideraciones finales al caso de estudio ....................................... 367 CAPÍTULO VIII. CONCLUSIONES Y LÍNEAS DE TRABAJO FUTURO ............... 369 8.1 Resultados obtenidos ............................................................................... 371 8.1.1 Arquitectura y framework creados ..................................................... 374 8.2 Contribuciones del trabajo ........................................................................ 375 8.3 Líneas de trabajo futuro ............................................................................ 376 8.3.1 Analizar la posibilidad de utilizar la metodología en grandes empresas 377 8.3.2 Evolucionar la arquitectura hacia una modalidad PaaS ..................... 377 8.3.3 Generar un constructor de formularios visual .................................... 378 8.3.4 Evaluación de la productividad .......................................................... 379 8.3.5 Realizar una evaluación en las organizaciones cliente ...................... 379 8.4 Límites de la investigación ........................................................................ 379 BIBLIOGRAFÍA ...................................................................................................... 381 ÍNDICE DE FIGURAS Figura 1. Factores propiciadores del momento de cambio actual ............................. 29 Figura 2. Teoría de Etapas de Nolan ........................................................................ 32 Figura 3. La gestión de la tecnología en una organización como motor del cambio . 34 Figura 4. El núcleo tecnológico clave ........................................................................ 35 Figura 5. Evolución de los sistemas de gestión empresarial .................................... 37 Figura 6. Alcance de los sistemas ERP .................................................................... 38 Figura 7. Transacciones no coordinadas en una organización tradicional sin workflow ............................................................................................................. 40 Figura 8. Transacciones siguiendo un flujo de trabajo predefinido ........................... 41 Figura 9. Estándares BPM y sus orígenes ................................................................ 67 Figura 10. Ejemplo Pi-calculus .................................................................................. 68 Figura 11. Ejemplo en Pi-calculus ............................................................................. 70 Figura 12. Elementos gráficos que definen una red de Petri .................................... 72 Figura 13. Ejemplo de disparo de una red de Petri ................................................... 73 Figura 14. Ejemplo diagrama de flujo UML ............................................................... 75 Figura 15. Ejemplo diagrama de estados UML ......................................................... 76 Figura 16. Tipología de aplicaciones de workflow .................................................... 77 Figura 17. Modelo de referencia de workflow por el WfMC ...................................... 80 Figura 18. Ejemplo de empresa y relaciones con su entorno ................................... 92 Figura 19. Módulos de una arquitectura BPM ........................................................... 94 Figura 20. Informe de sistemas workflow/BPM IDC MarketScape .......................... 100 Figura 21. Arquitectura de Bonita ........................................................................... 102 Figura 22. Diagramador de Bonita Workflow .......................................................... 103 Figura 23. Interfaz para los usuarios de Bonita workflow ........................................ 105 Figura 24. Arquitectura de jBoss Red Hat ............................................................... 108 Figura 25. Diseñador de procesos de jBoss Red Hat ............................................. 109 Figura 26. Creador de formularios en jBoss Red Hat ............................................. 110 Figura 27. Administración de tareas e instancias ................................................... 112 Figura 28. Cuadro de mando en jBoss ................................................................... 113 Figura 29. Arquitectura de los módulos de ProcessMaker ...................................... 116 Figura 30. Elementos del núcleo de ProcessMaker ................................................ 117 Figura 31. Diseñador de procesos .......................................................................... 119 Figura 32. Diseñador de formularios (Dynaform Builder) ........................................ 120 Figura 33. Generador de plantillas de documentos ................................................ 121 Figura 34. Generador de reglas de negocio ........................................................... 122 Figura 35. API orientado a webservices ................................................................. 122 Figura 36. Debugger ............................................................................................... 123 Figura 37. Generador de tareas .............................................................................. 124 Figura 38. Arquitectura de la solución de Bizagi ..................................................... 128 Figura 39. Bizagi Modeler ....................................................................................... 129 Figura 40. Bizagi Studio .......................................................................................... 130 Figura 41. Portal de trabajo de Bizagi ..................................................................... 131 Figura 42. Arquitectura de Tibco ActiveMatrix BPM ................................................ 135 Figura 43. Fases de una metodología general de implantación de un sistema workflow/BPM .................................................................................................. 149 Figura 44. Fases en un metodología genérica de implantación de un sistema workflow/BPM .................................................................................................. 150 Figura 45. Metodologías tradicionales ..................................................................... 153 Figura 46. Metodologías ágiles ............................................................................... 154 Figura 47. Metodología DMEMO ............................................................................. 156 Figura 48. Metodología DMAIC ............................................................................... 157 Figura 49. Metodología DMAIC con análisis previo ................................................. 158 Figura 50. Metodología Scrum ................................................................................ 162 Figura 51. El proyecto visto como secuencia de iteraciones ................................... 164 Figura 52. Modelo de la metodología BPM:RAD ..................................................... 172 Figura 53. Visión global ........................................................................................... 194 Figura 54. Arquitectura del sistema workflow/BPM propuesto ................................ 196 Figura 55. Arquitectura del sistema estructura en capas de librerías ...................... 197 Figura 56. Fases en la creación de un proceso de negocio .................................... 199 Figura 57. Transiciones permitidas y no permitidas ................................................ 200 Figura 58. Ejemplo de flujo sencillo definido ........................................................... 202 Figura 59. Ejemplo de procedimiento de expropiación (parte 1) ............................. 205 Figura 60. Ejemplo de procedimiento de expropiación (parte 2) ............................. 206 Figura 61. Ejemplo de procedimiento de expropiación (parte 3) ............................. 207 Figura 62. Ejemplo de procedimiento de expropiación (parte 4) ............................. 208 Figura 63. Extracto del fichero XML con la definición de un nodo de tipo estado ... 209 Figura 64. Extracto del fichero XML con la definición de un nodo de tipo transición. ......................................................................................................... 210 Figura 65. Modelo MVC utilizado en el framework .................................................. 213 Figura 66. Núcleo del framework ............................................................................. 214 Figura 67. Modelo MVC utilizado en el framework .................................................. 216 Figura 68. Ejemplo de rejilla creado con el framework ............................................ 217 Figura 69. Ejemplo de formulario creada con el framework .................................... 217 Figura 70. Posición de los procesos respecto a las acciones ................................. 218 Figura 71. Modelo MVC utilizado en el framework. ................................................. 223 Figura 72. Fases en la ejecución del controlador ................................................... 225 Figura 73. Ejemplo de rejilla ................................................................................... 232 Figura 74. Relación entre rejillas padre e hijo ......................................................... 234 Figura 75. Acceso a las bases de datos que extienden el modelo de datos ........... 235 Figura 76. Creación de una extensión del modelo (base de datos) ........................ 236 Figura 77. Creación de una extensión del modelo (base de datos) ........................ 238 Figura 78. Acceso a los webservices ...................................................................... 239 Figura 79. Fases de la metodología propuesta ....................................................... 244 Figura 80. Ejemplo de mockup ............................................................................... 248 Figura 81. Aplicación Pencil para el diseño de mockups. ....................................... 249 Figura 82. Fases en la definición de los procesos de negocio ................................ 250 Figura 83. Fases de las reuniones dentro de la metodología propuesta ................ 257 Figura 84. Convocatorias de las reuniones ............................................................. 258 Figura 85. Solicitud de asistencia a reunión por medios electrónicos ..................... 259 Figura 86. Ejemplo de grupo de trabajo para la implantación ................................. 261 Figura 87. Ejemplo de asignación de tareas ........................................................... 262 Figura 88. Ejemplo de tarea completada ................................................................ 263 Figura 89. Ejemplo de archivado de tarea .............................................................. 263 Figura 90. Cuadro de mando para el control de las tareas pendientes de ejecutar por participante ................................................................................................ 264 Figura 91. Interfaz para la gestión de hitos ............................................................. 265 Figura 92. Gestión del riesgo .................................................................................. 267 Figura 93. Vinculación de coste por hora para cada participante ........................... 268 Figura 94. Asignación de horas utilizadas en cada tarea ........................................ 269 Figura 95. Asignación de horas utilizadas en cada tarea ........................................ 269 Figura 96. Aplicación de la gestión del conocimiento al proyecto de implantación . 270 Figura 97. Fases del método Action Research ....................................................... 279 Figura 98. Topología de conectividad en la empresa ............................................. 299 Figura 99. Reuniones de análisis con la empresa caso de estudio 1 ..................... 302 Figura 100. Gestión documental generada ............................................................. 302 Figura 101. Ejemplo de mockup ............................................................................. 303 Figura 102. Flujo del proceso de negocio: gestión de incidencias .......................... 304 Figura 103. Inicio del workfow. Creación de una incidencia ................................... 306 Figura 104. Incorporación de los productos implicados .......................................... 307 Figura 105. Información a cumplimentar por el departamento de logística ............. 308 Figura 106. Recepción de la mercancía en el almacén .......................................... 309 Figura 107. Análisis de causas por el departamento de calidad ............................. 309 Figura 108. Abono o reposición de la mercancía y final del workflow ..................... 310 Figura 109. Interfaz principal de acceso al sistema ................................................. 311 Figura 110. Topología de sistemas en la administración ........................................ 322 Figura 111. Ejemplo de mockup para la rejilla de expedientes ............................... 325 Figura 112. Flujo del proceso de negocio: gestión de actividades clasificadas ....... 326 Figura 113. Inicio del workfow. Creación de un expediente de actividades clasificadas ...................................................................................................... 328 Figura 114. Incorporación de los titulares al expediente ......................................... 329 Figura 115. Formulario de documentos aportados al expediente ........................... 329 Figura 116. Creación de un trámite ......................................................................... 330 Figura 117. Modelo de plantilla para un decreto ..................................................... 331 Figura 118. Incorporación de datos técnicos al expediente .................................... 332 Figura 119. Ejemplo de código seguro de verificación ............................................ 334 Figura 120. Topología de la empresa ...................................................................... 339 Figura 121. Proceso principal del negocio .............................................................. 342 Figura 122. Ejemplo de mockup para la rejilla de servicios contratados ................. 344 Figura 123. Flujo del proceso de negocio: gestión comercial .................................. 345 Figura 124. Inicio del workfow. Creación de presupuesto ....................................... 347 Figura 125. Inclusión de los datos administrativos en el contrato ........................... 348 Figura 126. Bandeja de contratos pendientes de concertar .................................... 349 Figura 127. Acceso al sistema workfow/BPM ......................................................... 351 Figura 128. Actualización en el sistema workfow/BPM a través de smartphones ... 352 Figura 129. Topología de sistemas en la empresa ................................................. 357 Figura 130. Ejemplo de mockup para la rejilla de gastos aportados al proyecto ..... 359 Figura 131. Flujo del proceso de negocio: autorización de gastos .......................... 360 Figura 132. Incorporación de nueva nueva factura en el proyecto .......................... 363 Figura 133. Formulario de autorización de una factura ........................................... 364 Figura 134. Listado de proyectos y acciones sobre el mismo ................................. 366 ÍNDICE DE TABLAS Tabla 1. Estándares presentes en los sistemas workflow/BPM ................................ 61 Tabla 2. Comparativa de las arquitecturas revisadas ............................................. 142 Tabla 3. Comparativa de las metodologías revisadas ............................................ 188 Tabla 4. Elementos del modelo de datos ................................................................ 219 Tabla 5. Sintaxis de los tipos de datos .................................................................... 220 Tabla 6. Comparativa entre ProcessMaker y la arquitectura y framework propuesto ......................................................................................................... 240 Tabla 7. Comparativa entre la metodología Scrum y la propuesta ......................... 271 Tabla 8. Implantaciones realizadas por tipo de organización ................................. 284 Tabla 9. Implantaciones por tipo de sistema ........................................................... 284 Tabla 10. Desglose de los casos donde se ha implantado el sistema .................... 285 CAPÍTULO I. INTRODUCCIÓN Y OBJETIVOS Sistemas Workflow y BPM: metodología y casos de estudio 32 1.1 Motores e impactos del cambio Si bien hemos visto que existen una serie de factores que han propiciado el cambio en la situación socioeconómica actual, también existen unos elementos catalizadores que actúan de motor para la continuidad de ese cambio. Estos motores son básicamente: a) La creciente e imparable globalización de la economía, superando barreras físicas e incluso legislativas (Friedman, 2005); b) Las tecnologías de la información como infraestructura clave y c) Las redes de comunicación como base del nuevo sistema de intercambio de productos y servicios. Los motores y el proceso de cambio están provocando una serie de impactos: • Aparición de nuevos sectores industriales. El cambio tecnológico que se ha comentado ha estimulado la modificación de los sectores existentes (nuevas maquinarias, nuevos modelos de hacer negocio, etc.) y la aparición de nuevos sectores como la telefonía móvil, servicios de Internet, etc. Por otro lado, los cambios en las demandas de los clientes o usuarios aumenta progresivamente los requerimientos en nuevas tecnologías. La teoría de etapas de Nolan (figura 2) describe este proceso mediante una serie de curvas en forma de “S” creciente, a lo largo de los años (Nolan, 1992). Aprendizaje 1960 1980 1995 2010 Era DP Era Micro Era Network Fuente: Nolan (1992) Figura 2. Teoría de Etapas de Nolan Capítulo 1. Introducción y objetivos 33 • Nuevas estrategias en las organizaciones. Según Benjamin y Blunt (1992), las ventajas que las organizaciones obtendrán de la TIC dependerán más de su aptitud para identificar los apropiados objetivos estratégicos y para implementar el cambio, que del factor técnico. Aquellas organizaciones que sepan adaptarse a los cambios (y cambiar continuamente) sabrán sacar provecho de la nueva situación y aumentar su capacidad competitiva. Adicionalmente, dotar de recursos a la componente de innovación de la organización facilitará la adopción del cambio. Desde el punto de vista tecnológico, aquellas organizaciones que cuenten con unas infraestructuras adecuadas podrán realizar funciones de innovación de forma más efectiva. “La gestión de la tecnología será la clave del éxito de las empresas en cualquier parte del mundo” (Kandampully, 2002: 25). En este sentido, la gestión empresarial de la tecnología debe buscar los siguientes objetivos (figura 3): • Integrar la tecnología en los objetivos estratégicos de la organización. • Conseguir el uso eficiente de la tecnología en todas las funciones de la empresa. • Evaluar las tecnologías accesibles. • Introducir y desechar tecnologías. • Transferir tecnologías hacia y desde la empresa. • Reducir el tiempo de respuesta en el mercado de las innovaciones. Sistemas Workflow y BPM: metodología y casos de estudio 34 Dentro de la organización, se puede identificar distintos tipos de tecnologías (Castells y Pasola, 2003). Por un lado, las tecnologías clave, las cuales se definen como aquellas que aportan a la organización un claro diferencial frente a sus competidores. Por otro lado, tenemos las tecnologías base, que aunque no aportan un diferencial, deben existir para el correcto y normal funcionamiento de la organización. La inversión en este tipo de tecnologías se debe realizar de forma prudente, atendiendo a necesidades reales. Podemos definir núcleo tecnológico clave como la Transferir Innovar Integrar Fuente: Palvia (1992) Evaluar Uso eficiente Proceso de Cambio Gestión de la Tecnología Estado Estado Motor Introducir/Desechar Figura 3. La gestión de la tecnología en una organización como motor del cambio Capítulo 1. Introducción y objetivos 35 suma de las tecnologías base y las tecnologías clave (figura 4). Para poder evaluar, analizar, definir y servir de base a la implantación de estas tecnologías en una organización, es necesario crear el plan tecnológico de la misma, siempre teniendo en cuenta que el éxito en cualquier organización depende no sólo de la tecnología, sino del área organizativa. • Nuevas formas de estructurar las organizaciones. La situación de cambio, también se traduce en las organizaciones desde el punto de vista de: a) su estructura (Drucker, 1988), caracterizándose por una mayor horizontalidad, creatividad, flexibilidad, etc.; b) su funcionalidad (Drucker, 2007), caracterizándose por nuevos modelos de comunicación, una mayor delegación en el trabajo, etc.; c) nuevos perfiles profesionales; d) cambios en la naturaleza del trabajo; y d) nuevos estilos de dirección (Drucker, 1995). Fuente: Orlikowski (1992) Tecnología base Tecnología clave Núcleo tecnológico clave Figura 4. El núcleo tecnológico clave Sistemas Workflow y BPM: metodología y casos de estudio 36 1.2 Los sistemas de gestión empresarial Tal y como se ha comentado, las organizaciones deben disponer de todas aquellas herramientas necesarias para no dejar de ser competitivos en el mundo actual. Esta evolución, desde un punto de vista tecnológico, conlleva la puesta en marcha de sistemas de información modernos que ayuden a maximizar la gestión que se realiza de la información y el conocimiento en las organizaciones. Previo a la llegada de los sistemas de información informatizados, las organizaciones realizaban todas sus actividades de manera manual utilizando sus recursos humanos. Los ciclos de trabajo para crear un producto eran largos y, simultáneamente, los productos creados eran poco variados. A modo de ejemplo, en esta etapa, los inventarios en las empresas se realizaban bajo la premisa de tener de todo un poco (Ptak y Schragenheim, 2003). En los años 60, con la llegada de los primeros ordenadores se fueron creando las primeras aplicaciones informáticas orientadas a generar inventarios. Los ordenadores comenzaban a manejar un gran volumen de datos y a velocidades impensables en aquella época. No obstante, en estos inicios las metodologías utilizadas seguían siendo las mismas que en los casos donde no se utilizaba la informática. A las herramientas que se construían en esta época se les denominó gestores de listas de materiales (BOM: Bill Of Materials). El verdadero cambio sucedió en los años 70 con la creación de los sistemas de planificación de necesidades de materiales (MRP: Material Requirements Planning) donde se introducían los conceptos de procedimientos, reglas de decisión y registros. Estos sistemas tenían por objetivo conocer qué tenía la empresa para calcular qué va a necesitar y cuándo. La evolución del MRP fueron los sistemas MRP a ciclo cerrado donde se introducían los conceptos de carga de trabajo y capacidad de cada centro de trabajo para obtener unos resultados más precisos. En esta etapa se integraba compras con fabricación. En los años 80 los sistemas MRP II se abrieron paso incorporando información financiera y contable. Ya en los años 90 con los procesos de división de empresas en departamentos o servicios y el Capítulo 1. Introducción y objetivos 37 incremento en la necesidad de cumplir plazos de entrega hizo necesario tener un sistema de planificación empresarial que abarcase todos los aspectos de la organización. Las aplicaciones ERP (Enterprise Resource Planning) fueron introduciéndose en la cultura de trabajo de todas las organizaciones. A mediados de los años 90 y comienzos del 2000 los sistemas ERP fueron incorporando otras tecnologías específicas para ciertos departamentos tales como SCM (Supply Chain Management), CRM (Client Relationship Management) o gestor de proyectos hasta llegar a los sistemas workflow/BPM (Andonegi et al., 2005). En la figura 5 podemos observar la evolución de estos sistemas como círculos donde cada tecnología asume los conceptos de la anterior. Fuente: Ptak y Schragenheim (2003) Figura 5. Evolución de los sistemas de gestión empresarial Sistemas Workflow y BPM: metodología y casos de estudio 38 1.3 Los sistemas de planificación de recursos empresariales ERP Bajo las siglas ERP se sitúan todas aquellas soluciones informáticas que tratan de integrar todos los procesos de trabajo en una organización de forma completa presentando de una forma holística toda la información que posee la organización a partir de la arquitectura de sus sistemas informáticos (Klaus y Rosemann, 2000). La mayoría de las organizaciones (independientemente de su tamaño) han adoptado este tipo de sistemas para gestionar su información. En la figura 6 se representa el alcance de los sistemas ERP (Chen, 2001). Los sistemas ERP se sitúan en el interior de la organización vinculando las solicitudes (compras) que se realizan a los proveedores con las solicitudes (ventas) que realizan los clientes. Existen cuatro aspectos fundamentales en todo sistema ERP: Fuente: Chen (2001) Figura 6. Alcance de los sistemas ERP Capítulo 1. Introducción y objetivos 39 • Aspecto financiero. Incluyendo funcionalidades relativas a gestión de facturación, cobros y pagos, gestión de cajas, contabilidad, análisis de rentabilidades informes hacia la dirección. • Operaciones y logística. Incluyendo los procesos de compras, gestión de inventario, gestión de la calidad, gestión de proyectos, evaluación de los proveedores, etc. • Recursos humanos. Incluyendo procesos de nóminas, calendarios del personal, gestión de la formación, etc. • Ventas y marketing. Incluyendo gestión de pedidos de clientes, administración de ventas, planificación de los departamentos comerciales, gestión de precios y ofertas, etc. A medida que avanza el tiempo, los sistemas ERP necesitaron evolucionar hacia aplicaciones más específicas e integrar nuevas tecnologías tales como los sistemas workflow/BPM. 1.4 La llegada de los sistemas workflow Antes de la llegada de los sistemas workflow, los procesos en las organizaciones se realizaban de una forma enteramente manual (podrían ser utilizandos equipos informáticos, pero no dejaba, por esta razón, de ser manual). Cualquier tarea exigía la presencia de un usuario humano, o participante del proceso que debía dar las órdenes correctas al sistema para poder continuar con el siguiente paso o tarea. En la actualidad siguen existiendo múltiples procesos que, a pesar de las inversiones tecnológicas realizadas por administraciones y empresas, siguen siendo claramente manuales. La forma de actuar de estos procesos consiste en formar a los participantes en las reglas que se deben cumplir, de manera que dichas personas las ejecuten. Sistemas Workflow y BPM: metodología y casos de estudio 40 En la figura 7 se muestra cómo en dichas organizaciones las transacciones se realizan sin un orden preestablecido. Aunque dichas organizaciones funcionan con normalidad no es posible alcanzar un grado de eficiencia óptimo (ni introduciendo las nuevas tecnologías). Tal y como indica Gates (2006), en aquellas organizaciones donde se automatizan los procesos de trabajo bien definidos se logrará aumentar la velocidad con la que se ejecutan dichos procesos. No obstante, si se automatizan unos procesos mal definidos, se aumentará la velocidad de mala ejecución de los mismos. De ahí la enorme importancia de analizar los procesos de trabajo previamente a la introducción de un sistema que los automatice. Una vez analizados los procesos de trabajo, podremos realizar transacciones siguiendo un orden predeterminado y definido en el workflow (figura 8). Acciones técnicas Acciones comerciales Transacciones Acciones gerenciales Fuente: Elaboración propia Figura 7. Transacciones no coordinadas en una organización tradicional sin workflow Capítulo 1. Introducción y objetivos 41 Aquellas empresas e instituciones públicas que han invertido enormes sumas presupuestarias para modernizarse y todavía no han llegado al punto explicado anteriormente, aun deben recorrer un camino para obtener los beneficios de la automatización y de esta forma aumentar la productividad. También es cierto que algunas empresas y administraciones han dado los pasos necesarios en este sentido. Por otra parte, aquellas organizaciones que no tienen el grado de automatización previamente citado tendrán que luchar con el siguiente conjunto de problemas: • Gran dependencia del papel al no poder automatizar todo el proceso. Aún teniendo buenas aplicaciones informáticas, sin un workflow, el papel sigue presente (Riempp, 2012). • Pérdidas de documentos por su alto grado de utilización (Agostini et al., 1993). • Lentitud de respuesta de los procesos (ante demandas de clientes, internos o externos o ciudadanos) así como a las solicitudes o requerimientos de información del estado de tramitación de cada uno de los procesos. Adicionalmente, experimentan una fragmentación de las Figura 8. Transacciones siguiendo un flujo de trabajo predefinido Acciones técnicas Acciones comerciales Transacciones Acciones gerenciales Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 48 • Permitir describir de una forma clara, sencilla y comprensible los procesos que se deben ejecutar dentro de la organización. • Permitir ejecutar los procesos definidos en un software adaptable a la organización existente. • Permitir la gestión del cambio en los usuarios ofreciéndoles una forma alternativa de ejecutar sus tareas diarias de forma integrada con el sistema y sin necesidad de utilizar otro software alternativo. • Permitir la conectividad con otros sistemas mediante la aplicación de webservices. • Reducir los costos de inversión de forma directa mediante la reducción de horas de trabajo en la puesta en marcha del sistema. 1.6 Organización del presente trabajo Con la intención de responder a los objetivos mencionados en el apartado anterior hemos abordado el trabajo que seguidamente presentamos. Lo hemos estructurado en ocho capítulos cuyo contenido describimos brevemente a continuación. En el capítulo dos realizaremos una introducción a los sistemas workflow y BPM, sus orígenes teóricos y su evolución futura. Adicionalmente analizaremos la conceptualización, estructura, componentes y arquitectura de un sistema de workflow definido por el WfMC. Esta definición nos ayudará a centrar las bases de la estructura que debe cumplir todo sistema de workflow. En el capítulo tercero se realiza una revisión de los sistemas workflow y BPM que existen en la actualidad, centrándonos en aquellos más utilizados para empresas de tamaño pequeño/mediano. Para cada una de las soluciones presentamos las ventajas que aportan pero también los inconvenientes detectados. Capítulo 1. Introducción y objetivos 49 En el capítulo cuarto se estudian las metodologías existentes en la actualidad para la implantación de un sistema workflow/BPM. Dentro de este capítulo comprobaremos como existen dos grandes grupos: metodologías tradicionales y metodologías ágiles. Para cada una de ellas presentamos sus ventajas y sus inconvenientes. El capítulo quinto se dedica a presentar la metodología ágil de implantación que proponemos. Esta metodología está muy vinculada a un modelo o entorno tecnológico (framework) que se ha creado para este trabajo. El framework permite la construcción rápida de aplicaciones siguiendo los pasos definidos en la metodología ágil. En el capítulo sexto se expone la metodología de investigación aplicada en el presente trabajo, el número de casos donde se ha implantado y la selección de cuatros casos reales donde se ha aplicado. En el séptimo capítulo presentamos los casos de estudio reales donde se ha implantando un sistema workflow/BPM siguiendo la metodología propuesta. Se han seleccionado casos diferentes en función del software concreto que cada organización requería por lo que encontraremos aplicaciones directas para la construcción de ERPs, CRMs, herramientas de gestión de proyectos y gestores de expedientes electrónicos en la administración pública. El trabajo finaliza con una sección dedicada a resumen y conclusiones que pretende sintetizar los resultados y las características más relevantes de nuestra aportación y las líneas futuras de investigación, así como sus limitaciones. Por último se incluye una relación bibliográfica que permitirá identificar las referencias citadas en el trabajo. CAPÍTULO II. LOS SISTEMAS WORKFLOW Y BPM (BUSINESS PROCESS MANAGEMENT) Capítulo 2. Los sistemas workflow/BPM 53 En el capítulo anterior iniciamos el presente trabajo con una introducción al mundo en cambio en el que nos encontramos debido a los avances en la tecnología. Las organizaciones públicas y privadas no pueden ser ajenas a estos avances y deben innovar para adaptarse al nuevo momento. Desde un punto de vista tecnológico, las organizaciones deben utilizar sistemas de información que les ayuden a gestionar los datos que manejan y que son necesarios para el correcto funcionamiento de las mismas. Como hemos visto, dichos sistemas han evolucionado en el tiempo (desde las listas de materiales BOM a los sistemas workflow/BPM) siendo necesario que las organizaciones se adapten a las nuevas formas de funcionamiento. Desde el punto de vista de la gestión en las organizaciones, la aplicación de sistemas workflow permite incorporar numerosas ventajas que harán que la organización aumente su capacidad competitiva. En el presente capítulo definiremos de forma más detallada los sistemas workflow y BPM, revisaremos sus orígenes, estándares y profundizaremos en sus ventajas para las organizaciones. 2 Los sistemas workflow Tal y como afirma The (1995), si se pide a diez personas que definan el concepto de flujo de trabajo, obtendríamos once respuestas posibles. Con esta afirmación el autor quiere mostrar la complejidad que representa querer obtener una definición uniforme y estándar para dicho concepto (González, 2006). A pesar de ello, a continuación hacemos una revisión de las definiciones más extendidas en los entornos científicos y técnicos. Según ESTROFA (Especificaciones para el Tratamiento de Flujos administrativos Automatizados) (en Figueroa, 1995), un sistema workflow es el que permite definir, ejecutar y gestionar procesos y tareas según unas reglas, considerando un proceso como un conjunto de tareas ordenadas, bien temporalmente, bien cumpliendo condiciones obtenidas en reglas que son realizadas por personas o de una forma automática. Por su parte, para la WfMC (Workflow Management Coalition) (en Hollingsworth, 1995), se define workflow como la automatización de un proceso de negocio, total o parcialmente, en Sistemas Workflow y BPM: metodología y casos de estudio 54 el que la información de cualquier tipología llega al usuario adecuado en el momento adecuado, sobre la base de un conjunto de reglas inteligentes, que permite que la mayoría del trabajo sea realizado informáticamente, mientras que las personas se ocupan solamente de las excepciones (Georgakopoulos et al., 1995). La WfMC es una organización internacional sin ánimo de lucro formado por usuarios analistas y distribuidores del área del workflow, con el objetivo de normalizar los conceptos, tecnologías e interoperabilidad de este tipo de tecnologías. A su vez, (Marshak, 1994) indica que una aplicación de workflow automatiza la secuencia de acciones, actividades o tareas que se utilizan para ejecutar un proceso comercial, incluido el control de estado de cada instancia del proceso, así como las herramientas para gestionar el proceso en sí. Como hemos visto, las definiciones tratadas incluyen conceptos como: a) definir procesos; b) ejecutar procesos; c) gestionar procesos; d) visualizar los procesos como una entidad que agrupan tareas o actividades ordenadas normalmente en el tiempo o siguiendo unas reglas específicas; e) poder automatizar de procesos con el ánimo de ejecutar tareas o actividades directamente por acción de los sistemas y sin interacción humana; f) fluir la información a través de los distintos participantes siguiendo las reglas definidas; y g) proporcionar herramientas que ayuden a la creación, ejecución, administración y monitorización de los procesos. Por lo tanto, en este trabajo, aportamos la siguiente definición: un sistema workflow es aquel sistema que permite crear, ejecutar, administrar y monitorizar procesos automáticos o manuales que ayudan a que fluya la información entre distintos participantes de una organización (humanos o no), siguiendo un conjunto de reglas inteligentes definidas. 2.1 Relación de los sistemas workflow con otros sistemas A continuación vamos revisar la relación que existe entre los sistemas workflow y otros sistemas ya existes que pudiesen estar operativos en las organizaciones en la actualidad. Como se ha mencionado anteriormente, una de las características Capítulo 2. Los sistemas workflow/BPM 55 principales de los sistemas workflow es tener capacidad de integración con otros sistemas para poder obtener o distribuir datos e información. 2.1.1 Sistemas de gestión documental Los sistemas de gestión documental (Sprague,1995) se encargan de gestionar la documentación que obra en una determinada tarea o en un expediente en el caso de una administración pública, por lo tanto la relación entre el workflow y los gestores documentales es notable. Es incluso posible que los gestores documentales, por sí mismos, tengan un workflow sencillo para conocer el estado y evolución de cada uno de los documentos que obren en su interior. La idea central de un gestor documental es posibilitar el almacén seguro de los documentos y poder ponerlos a disposición de las personas o los sistemas que requieran conocerlos según las funciones que posean en la organización. El almacén de documentos puede adoptar cualquier formato: hojas Excel, documentos en Word, ficheros XML, HTML, códigos fuentes, formularios electrónicos, etc. La organización de los documentos en el sistema se establece de manera jerárquica (a partir de árboles) o también en base a etiquetas (propiedades) las cuales ayudan a relacionar los documentos por conceptos mucho más variados (Dourish et al., 2000). 2.1.2 Sistemas de correo electrónico En muchas ocasiones los sistemas workflow son necesarios en una organización debido al mal uso que se da al correo electrónico en la misma. En la mayoría de las organizaciones se tiende a gestionar las actividades o tareas de los usuarios vía Sistemas Workflow y BPM: metodología y casos de estudio 56 correo electrónico, cuando esta herramienta precisamente no es apta para dichos menesteres, por su falta de seguridad, control, auditoría y capacidades de gestión u obtención de informes (Sproull y Kiesler, 1986). De hecho, en 2014 por primera vez el número total de correos electrónicos enviados a lo largo del planeta se redujo en varios millones (Jackson y Russell, 2015) aún con los esfuerzos de las grandes compañías de software en crear nuevas interfaces que permitan gestionar de una forma más cómoda dichos emails como por ejemplo Google Inbox (Castelluccio, 2014; Smith, 2014), IBM Verse (Mendiola, 2014) o WorkMail de Amazon (Kepes, 2015). Los sistemas de workflow también se nutren de los sistemas de correo electrónico como canal para el envío de notificaciones, alertas o avisos a los participantes de un proceso. Adicionalmente, las interfaces que proporcionan las herramientas de workflow hacia los usuarios donde se visualizan las actividades pendientes de realizar por los mismos están claramente influenciadas por las aplicaciones de gestión de correos electrónicos (donde normalmente encontramos una bandeja de entrada y una bandeja de salida de mensajes). 2.1.3 Gestión de proyectos La gestión de proyectos trata de planificar, organizar y gestionar recursos orientados a conseguir uno o varios objetivos (Duncan, 1996). La gestión de proyectos en cualquier organización supone un desafío para llegar a un consenso entre las restricciones de alcance a lograr, el tiempo, la calidad y los recursos económicos que se necesitan para abordarlo (Raftery, 2003). Dado que la gestión de proyectos tiene por objetivo la comunicación, distribución y organización de las tareas que se han de realizar en cada una de las fases de un proyecto (Kerzner, 2013), se establece una relación directa con el workflow. De hecho las herramientas modernas disponen de un pequeño motor de workflow para Capítulo 2. Los sistemas workflow/BPM 57 hacer efectivo ese movimiento de tareas. Estos pequeños motores de workflow tienen algunas limitaciones como, por ejemplo, no permitir la reasignación de tareas. 2.1.4 Gestión de Procesos de Negocio (BPM) Una evolución de los sistemas workflow es su utilización como parte fundamental de los sistemas BPM (Business Process Management). Los sistemas BPM implican la modelización, automatización, gestión y optimización de los procesos con el fin de incrementar su productividad (Reijers, 2006). Se trata de una sinergia entre los sistemas workflow, los sistemas ERP y las aplicaciones implantadas de forma adhoc en las organizaciones. Una de las definiciones más integradoras es la de Jeston y Nelis (2008): BPM significa alcanzar los objetivos de una organización mediante la mejora, gestión y control de sus procesos de negocio esenciales. Dado que los sistemas BPM son la continuación natural de los sistemas workflow, en este trabajo trataremos el concepto de workflow y BPM de manera unificada (workflow/BPM). Una de las características más importantes de los sistemas BPM es que permiten su modelado, configuración o incluso cambio radical del funcionamiento de la aplicación informática sin tener grandes conocimientos tecnológicos (Knolmayer et al., 2000) y sin que exista una clara dependencia sobre un tipo de tecnología determinada. Este hecho, unido a las tecnologías web, proporciona a la organización una herramienta eficaz para tener un mayor control de sus sistemas informáticos y de negocio. Este concepto no es nuevo, dado que las organizaciones siempre han querido tener una cierta independencia de la tecnología con la cual se desarrollen sus sistemas. Para conseguir este propósito, las herramientas BPM suelen proporcionar herramientas gráficas que permiten al usuario esquematizar sus procesos de trabajo de una forma intuitiva en un lenguaje gráfico comprensible tanto por el diseñador como por la máquina. Sistemas Workflow y BPM: metodología y casos de estudio 64 denominado XPDL (Shapiro, 2002) con el objetivo de que las herramientas de modelado gráfico puedan generar una información textual de los procesos. También han creado un estándar para poder realizar una interacción entre distintos sistemas denominado Workflow API (Moreno et al., 2009) y un estándar para la definición de la coreografía entre distintos sistemas, entendiendo por ésta la necesidad de tener un protocolo de comunicación entre las distintas aplicaciones con las que el sistema workflow/BPM debe interactuar. Por otro lado la organización OMG (Object Management Group) realizó en 1997 una especificación sobre el lenguaje de modelado unificado (UML) (Dumas y Hofstede, 2001). Este lenguaje describe varias tipos de notaciones o diagramas para modelar sistemas orientados a objetos en general (sistemas workflow/BPM en particular). Esta organización también ha definido un metamodelo para definir procesos de negocio denominado BPDM (Lautenbacher y Bauer, 2007) y un interfaz para la ejecución de dichos procesos BPRI. Una tercera organización es BPMI (Business Process Management Initiative). Se trata de una organización sin ánimo de lucro creada en el año 2000 y enfocada en promocionar la estandarización de los procesos de negocio con una orientación hacia el e-business y los sistemas B2B. Esta organización ha creado la notación para el modelado de proceso BPMN (White, 2004a) y el lenguaje que utiliza dicha notación BPML (Thiagarajan et al., 2002). Por último, empresas desarrolladoras de software tales como Microsoft o IBM han creado sus propios estándares tales como XLANG (Thatte, 2001) o WSFL (Leymann, 2001) ambos como lenguajes de ejecución de procesos de negocio en las herramientas propietarias de Microsoft e IBM respectivamente. A continuación revisaremos el origen teórico de los sistemas workflow/BPM para poder comprender los flujos de trabajo que visualizaremos en el capítulo 3 del presente trabajo. Capítulo 2. Los sistemas workflow/BPM 65 2.4 Origen teórico de los sistemas workflow/BPM El nacimiento del workflow es fruto de una evolución de distintas tecnologías anteriores en el ámbito de la informática (e incluso de la telemática). El desarrollo del software ha ido evolucionando e integrándose cada vez más con aspectos organizativos de las personas en cualquier empresa o administración pública. Además de este origen evolutivo, las tecnologías workflow se sustentan en una base teórica (Ramage, 1994), la cual posee los siguientes aspectos: a) el workflow se ha nutrido de los conocimientos relacionados con la gestión científica y con el análisis de sistemas y ha evolucionado hasta constituirse en una tecnología por sí misma; b) su razón de ser principal es la búsqueda de la mejora de la productividad en las organizaciones mediante la automatización de tareas y c) adicionalmente otra de las bases teóricas versa en el intento de tener organizaciones empresariales más horizontales y menos jerarquizadas, pues dado que estas tecnologías permiten conocer para cada uno de los participantes el número, prioridad, fechas de comienzo y finalización estimadas de cada tarea, no es necesario para el empleado recibir órdenes directas de un superior. Los orígenes de los sistemas BPM se remontan a la teoría de procesos. Podemos citar los siguientes argumentos que demuestran la importancia que tiene conocer dicha teoría cuando se trata de definir o utilizar una metodología de trabajo así como un framework para estos sistemas: • Normalmente se conecta la teoría de procesos con los sistemas BPM. En múltiples referencias se vincula la ejecución de sistemas BPM (BPEL) con el pi-calculus y las redes de Petri. Ambos casos son precursores de los sistemas BPM. • Los sistemas BPM son relativamente inmaduros (nuevos en el tiempo), por lo que se benefician de las ideas y la formalidad matemática de la teoría de procesos. Sistemas Workflow y BPM: metodología y casos de estudio 66 • Una de las funcionalidades más importantes de los sistemas BPM en la actualidad es tener la posibilidad de integrarse con otros sistemas. Es aquí donde los módulos de coreografía entran en juego, permitiendo definir de forma precisa las interacciones y conversaciones que los distintos sistemas deben mantener. Los sistemas de coreografía como el WS-CDL también están basados en el pi-calculus (Smith, 2003). Tanto el Pi-calculus como las redes de Petri (o una combinación de ambas) son precursoras de los estándares más importantes dentro de los sistemas BPM. En concreto: • WS-CDL • WSCI • BPML • XLANG • BPMN • WSFL Por otro lado, BPEL es la unión de los estándares XLANG y WSFL. En la figura 9 se ilustra este hecho. Capítulo 2. Los sistemas workflow/BPM 67 2.4.1 Pi-Calculus Pi-calculus es un lenguaje formal orientado a la definición de sistemas concurrentes que incluyen procesos que se comunican entre ellos interaccionando de forma dinámica (Milner, 1993). Fue definido por Milner en los años 90. Cada proceso realiza una o más acciones las cuales pueden ejecutarse en orden secuencial, paralelo (tomando caminos condicionados) o recurrentes. Una acción envía o recibe información a través de un canal. Cuando un proceso envía información a otro, indica el nombre del canal mediante el cual espera a su vez una respuesta. Figura 9. Estándares BPM y sus orígenes Fuente: Havey (2005) Sistemas Workflow y BPM: metodología y casos de estudio 68 En el siguiente ejemplo (Havey, 2005) se representa un ejemplo de sistema donde se especifica la compra de un billete de avión y donde se realizan interacciones entre un cliente, una agencia de viajes y una compañía aérea. En las primeras dos líneas tenemos la definición del proceso Customer el cual se relaciona con el resto de procesos a través de los canales: createorder y customer. En el interior del proceso nos encontramos las siguientes notaciones: • p<q>: Significa enviar q poner el canal p. • p(q): Significa recibir q por el canal p. Figura 10. Ejemplo Pi-calculus 1 Customer(createorder, customer)= 2 createorder<customer>.customer(result) 3 Agent(createorder,agentok, agentfail, airline)= 4 createorder(customer).airline<agentok, agentfail>. 5 Agent1(agentok, agentfail, customer) 6 Agent1(agentok, agentfail, customer)= 7 agentok(result).customer<result>+ 8 agentfail(result2).customer<result2> 9 Airline(airline, agentok, agentfail)= 10 airline(agentok, agentfail).agentok<”conf num 121”> 11 End2End= 12 (new corder, cust, ok, fail, air) 13 Customer(corder,cust)|Agent)corder,ok,fail,air)|Airline(air, ok, fail) Capítulo 2. Los sistemas workflow/BPM 69 Adicionalmente nos encontramos con un punto separando las expresiones createorder<customer> y customer(default). Este punto es el operador de secuencialidad por lo que ambas expresiones se ejecutan por orden (primero createorder<customer> y después customer(default). Leyendo de forma completa la línea 2 tenemos que el proceso Customer primero envía a través del canal createorden los datos de customer y a continuación espera recibir una respuesta result por el canal customer. El proceso a ejecutar por la agencia de viajes se describe entre las líneas 3 y 8. Se divide en dos partes (procesos Agent y Agent1). El proceso Agent recibe la orden desde el proceso Customer, a continuación realiza una llamada al proceso Airline esperando sincronizarse en los canales agentok y agentfail (simbolizando una reserva correcta o incorrecta). A continuación realiza una llamada al proceso Agent1. Este proceso contiene el operador + el cual simboliza una estructura condicional (o se procede la expresión de la izquierda o la expresión de la derecha del símbolo +). Ambas expresiones simbolizan la recepción de un resultado positivo o negativo desde la compañía aérea y a continuación se le remite al cliente (proceso Customer). El proceso Airline (líneas 9 y 10) escucha por el canal airline y a continuación envía un agentok con un número de confirmación. Por último, el proceso End2End une todos los procesos anteriores definiendo un comportamiento concurrente de los mismos (mediante el operador |). En la figura 11 podemos visualizar una representación de los procesos del ejemplo así como las acciones que se pueden producir entre los mismos. Sistemas Workflow y BPM: metodología y casos de estudio 70 Una de las características más importantes de Pi-calculus es la movilidad, es decir, poder cambiar la topología de los canales de forma dinámica en función de situaciones cambiantes en el sistema. Este hecho está asociado a sistemas modernos donde cada canal viene identificado por una dirección, la cual, puede ser dinámica. Los sistemas BPM toman prestado de Pi-calculus las siguientes características clave: • Flujo de control. Los operadores que hemos visto de secuencialidad, paralelismo, condicionalidad y comportamiento recursivo. Todo sistema BPM debe proveer estas funcionalidades. • Comunicación entre procesos basado en el paso de mensajes. Picalculus ofrece una sintaxis y semánticas claras para el envío y recepción de información entre los procesos. • Mobilidad. Los sistemas BPM deben proporcionar puntos de comunicación cambiantes (en función de direcciones dinámicas) que permitan adecuar la ejecución de un sistema a las características de cada entorno. Figura 11. Ejemplo en Pi-calculus Fuente: Havey (2005) Capítulo 2. Los sistemas workflow/BPM 71 2.4.2 Redes de Petri Las redes de Petri (Murata, 1992) fueron introducidas en 1962 por el matemático Carl Adam Petri. Se trata de un lenguaje formal y gráfico para el modelado de sistemas. Los sistemas BPM se benefician de las redes de Petri en su semántica para el flujo de los procesos en escenarios complicados. Como lenguaje gráfico que es, sus elementos fundamentales se pueden dibujar como círculos, rectángulos, flechas y puntos negros (tokens). Adicionalmente, las redes de Petri comparten con las máquinas de estado precisamente el concepto de estado. Murata (1989) expone una introducción a las redes de Petri muy amplia. De manera formal, una red de Petri se define como una tupla de 5 elementos: RdP=(P, T, F, w, M0) donde: P = {P1, ..., Pm} es un conjunto finito de lugares T = {t1, ..., tn} es un conjunto finito de transiciones F ⊆ (P × T) ∪ (P × T) es el conjunto de arcos w: F → {1, 2, ...} es la función de pesos M0: P → {0, 1, 2, ...} número de tokens en cada nodo tipo lugar; con (P ∩ T) = ∅ ψ (P ∪ T) ≠ ∅. En una red de Petri, los estados se asocian a los lugares, y los eventos a las transiciones. Una transición t está activada si cada lugar de entrada Pi ∈ t se marca con al menos w(Pi,t) tokens, donde w(Pi,t) es el peso asociado al arco entre Pi y t. Una vez activada, la transición se disparará cuando su evento asociado se produzca. Al disparar una transición t, w(Pi,t) tokens se eliminan de cada lugar Pi de entrada a dicha transición y w(Pi,t) tokens se añaden a los lugares de salida de la transición t. Sistemas Workflow y BPM: metodología y casos de estudio 72 También se utilizan arcos inhibidores que conectan un lugar Pi con una transición t, y sólo activa t cuando P no tiene tokens. En la figura 12 podemos visualizar la representación de cada uno de los elementos de la red de Petri: Cuando realizamos una red de Petri debemos tener en cuenta las siguientes normas: • Un arco sólo puede unir lugares con transiciones (nunca lugares o transiciones entre sí). • Un lugar puede ser el destino de una o varias transiciones. • Una transición puede ser destino de uno o varios lugares. • En el interior de los lugares incluimos los tokens (marcas). Aquellos lugares que tienen marcas en su interior se les considera activos. Figura 12. Elementos gráficos que definen una red de Petri Fuente: Elaboración propia Capítulo 2. Los sistemas workflow/BPM 73 • Con carácter general, a las transiciones se les asocian eventos. Una transición estará sensibilizada cuando todos los lugares que tiene como origen tienen al menos una marca en su interior. En este momento, la transición puede ser disparada. En la figura 13 podemos visualizar la evolución de una red de Petri en tres instantes de tiempo distintos. Figura 13. Ejemplo de disparo de una red de Petri Fuente: Elaboración propia Se dispara la transición T0 Sistemas Workflow y BPM: metodología y casos de estudio 80 Cada bloque define un modulo dentro del modelo. Estos módulos son: • Módulo 1: Definición de los procesos. • Módulo 2: Aplicaciones workflow cliente. • Módulo 3: Aplicaciones invocadas. • Módulo 4: Interoperabilidad con otros sistemas de workflow. • Módulo 5: Herramientas para la administración y monitorización. • Módulo 6: Entorno para la generación de flujos de trabajo. 2.6.1 Módulo 1. Definición de los procesos (process definition) El WfMC define proceso como una red de actividades y sus relaciones, la especificación de su inicio y conclusión y la información referente a sus actividades individuales como participantes, recursos tecnológicos y datos asociados (WfMC, 1999). PROCESS DEFINITION Figura 17. Modelo de referencia de workflow por el WfMC ADMINISTRATION AND MONITORING OTHER WORKFLOW WORKFLOW CLIENT INVOKED APPLICATIONS Fuente: WfMC (1999) Capítulo 2. Los sistemas workflow/BPM 81 Es decir, la definición de un proceso es toda aquella información necesaria para una posterior interpretación (y ejecución) del mismo. En este sentido existen múltiples formas de definir un proceso pero se debe tener muy en cuenta que no todas las definiciones son ejecutables. De ahí la enorme importancia de seguir una definición gráfica que pueda integrarse posteriormente en un motor de workflow. Adicionalmente a lo citado, disponer de la definición de procesos en una forma estandarizada permite la compartición de dichos procesos de trabajo o flujos. Estandarizar esta definición permitirá obtener las siguientes ventajas: • Establecer una independencia entre el diseño del proceso y su posterior ejecución, independientemente del motor de workflow que exista en la organización. Esto significaría que desaparecerían los problemas de compatibilidad dentro de una organización. En la actualidad, esta ventaja es más un deseo que una realidad dado que la mayoría de las herramientas de workflow utilizan objetivos o componentes propios de cada uno de los motores de workflow. • Permitir exportar la definición de un proceso de un sistema a otro, independientemente de sus características técnicas de manera que todos los procesos puedan cooperar. De igual forma, cada una de las empresas desarrolladoras de sistemas de workflow intentan crear componentes que abstraigan determinado conjunto de acciones para que sea más sencillo y rápido el desarrollo de prototipos de procesos. Para conseguir el objetivo de la estandarización en la definición de los procesos de trabajo, la WfMC estableció un metamodelo precisamente para la definición de los procesos. Los elementos de este metamodelo son: • Definición del flujo de trabajo: numero del proceso de workflow, numero de versión, condiciones de inicio y conclusión del proceso y por último datos de control, seguridad y auditoria. • Actividad: nombre, tipo de actividad, condiciones previas y posteriores a la actividad. Sistemas Workflow y BPM: metodología y casos de estudio 82 • Condiciones de transición. condiciones relevante a la ejecución del flujo de trabajo. • Datos relevantes al flujo de trabajo: nombre y ruta de los datos, tipo de los datos. • Roles: nombre y funciones asignadas. • Aplicaciones invocadas: nombre genérico, parámetros de ejecución y localización o ruta de acceso. La especificación WfMC, en lo que respecta a la importación y exportación de la definición de los procesos, define además del meta modelo descrito anteriormente, un lenguaje formal para la definición de los procesos WPDL (workflow process definition language) y además un API (application program interfaz) que permite acceder y manipular los elementos de la definición de un proceso. Dentro de este módulo, la herramienta cobra una importancia relevante ya que permite a los diseñadores crear dibujando los flujos de trabajo que ellos requieren en sus organizaciones. Los diagramas gráficos son posteriormente traducidos a ficheros en un formato asumible por el motor de workflow con el que se esté operando en dicho momento. Otra de los objetivos de la WfMC es la estandarización de dicha interfaz de forma que un proceso diseñado por cualquier herramienta de modelado de procesos (process analisis modelling and definition tool) pueda ser interpretada por cualquier motor de workflow. 2.6.2 Módulo 2. Aplicaciones cliente (workflow client application) La aplicación cliente es el software que utiliza el usuario para interactuar con el motor de workflow y poder participar en los procesos definidos con el fin de que pueda completar las actividades o tareas que le han asignado. Capítulo 2. Los sistemas workflow/BPM 83 La aplicación cliente debe permitir a los participantes realizar las siguientes funciones: • Seleccionar las actividades que va a realizar. • Añadir nuevas actividades. • Suspender temporalmente la ejecución de determinadas actividades (si se permite). • Eliminar actividades (si se le permite). • Otras. 2.6.3 Módulo 3. Aplicaciones invocadas (invoked applications) El sistema de workflow, a medida que se van ejecutando actividades o tareas dentro de un proceso, puede requerir la utilización de aplicaciones externas a las cuales, el motor de workflow debe invocar. Algunos ejemplos de esta aplicaciones pueden ser el paquete de ofimática de Microsoft (Word, Excel, Access o Powerpoint), Autocad, etc. Para posibilitar la comunicación entre el motor de workflow y las aplicaciones invocadas pueden existir dos métodos: • Utilizar un agente de aplicación el cual provee un conjunto de mecanismos basados en protocolos de comunicación estandarizados OSI, TCP o X.400. • Utilizar aplicaciones que estén preparadas para la interconexión con el motor de workflow. Las aplicaciones que están preparadas para interactuar directamente con el motor de workflow no necesitan ninguna capa intermedia de integración (agente de aplicación). Normalmente, en la integración de una aplicación invocada con el motor de workflow se deben tener en cuenta las siguientes funcionalidades: • Establecimiento de la sesión: conexión y desconexión de la sesión con la Sistemas Workflow y BPM: metodología y casos de estudio 84 aplicación. • Gestión de las actividades del motor de workflow hacia la aplicación inicio de la actividad, suspender, reanudar o abordar la actividad. • Gestión de actividades (de la aplicación al motor del flujo): notificación de la actividad completada, eventos de señalización o aviso (por ejemplo, sincronización) y petición de los atributos de una actividad. • Función de manejo de los datos posibilidad de envío de los datos sobre el flujo de trabajo. 2.6.4 Módulo 4. Interoperabilidad con otros sistemas workflow (other workflow enactment services) Los distintos sistemas de workflow deben tener la posibilidad de sincronizase y comunicarse de una forma fluida e intercambiar información sobre la definición de los procesos que se han realizado en cada uno de los sistemas, intercambiar datos sobre el control y estado de las actividades y procesos, coordinarse conjuntamente para la realización de algún proceso determinado y poder invocar actividades y subprocesos que se encuentren en el otro motor de workflow. La WfMC ha definido un conjunto de escenarios para la interoperabilidad e integración de distintos motores de workflow: • Conexión discreta (enlace simple). Este escenario se produce cuando los flujos de trabajo de dos procesos en sistemas distintos se sincronizan y comunican por un único punto. Es en ese punto donde intercambian información. • Conexión jerárquica (subprocesos anidados). En este caso la ejecución de una acción en un proceso puede conllevar la llamada a otro subordinado, de forma que cuando finalice su ejecución, pueda retornar al proceso llamante. Capítulo 2. Los sistemas workflow/BPM 85 • Conexión punto a punto. En este caso existen dos o más motores de workflow trabajando sobre las actividades de un mismo proceso, lo que presenta una serie de dificultades añadidas en el sentido de que ambos sistemas han de ser totalmente compatibles así como definir cuál de los sistemas se encargará de las tareas globales de administración, establecimiento de prioridades, gestión de la tolerancia a fallos, gestión de la recuperación del sistema, etc. • Sincronización paralela. En este caso los dos procesos o flujos de trabajo se ejecutan de forma completamente independiente, salvo en un punto de sincronización y comunicación establecido donde ambos intercambiarán información. Aquí se debe aplicar las técnicas de sincronización entre procesos concurrentes. (con buffer, intermedio, sin buffer, mensajes, monitores, etc). 2.6.5 Módulo 5. Herramientas de administración y monitorización (administration and monitoring tools) El objetivo es que se puedan crear herramientas de administración y monitorización de procesos independientemente del motor de workflow que exista en el nivel inferior (Hol, 1995). Este interfaz permite que los usuarios puedan conocer de una forma objetiva la evolución de todos los procesos, las tareas que están pendientes, las tareas que se ha realzado, su histórico, los participantes que han ejecutado alguna acción sobre ellas, etc. Para conseguir este objetivo, se deben definir con conjunto de WAPIs (workflow API and interchange formats) como formatos de intercambio de APIs y flujos de trabajo, de forma que estas herramientas de administración y monitorización puedan controlar a dichos los motores de workflow. Las funciones que suele incluir este modulo son las siguientes: Sistemas Workflow y BPM: metodología y casos de estudio 86 • Gestión de usuarios y establecimiento de permisos sobre dichos usuarios. • Gestión de los roles o perfiles. Establecimiento de grupos de usuarios. Poder asignar o modificar atributos de permisos sobre cada uno de los grupos de usuarios definidos. • Operaciones de gestión de auditorías. Posibilidad de la solicitud impresión o comienzo de una nueva auditoría. Posibilidad de buscar por eventos, intervalos de fechas, etc. • Operaciones de control de los recursos. Poder gestionar los recursos utilizados por cada uno de los procesos. Poder conocer o controlar el grado de concurrencia de los distintos procesos implicados. • Funciones de supervisión de los procesos implicados: Modificar el estado de definición de un proceso. Poder modificar el estado de todas las tareas implicadas en cada proceso. Poder asignar atributos a todas las tares de cada uno de los procesos. Poder finalizar una tarea o instancia de un proceso. • Funciones sobre los estados de los procesos. poder crear un nueva instancia/tarea o modificar alguna existente. Realizar búsquedas y filtrar instancias o tareas. 2.6.6 Módulo 6. Entorno para la generación de flujos de trabajo (workflow enactment service) La WfMC define este módulo como aquel servicio software que consiste en uno o varios motores de workflow encargados de crear, gestionar y ejecutar los flujos de trabajo. Es aquel modulo donde es posible la ejecución del flujo, mediante la interpretación de los procesos diseñados con los módulos analizados anteriormente. Este motor es también el encargado de gestionar las llamadas a otros motores de workflow o a un conjunto de aplicaciones invocadas. Entre las funciones que realiza el motor de workflow tenemos: Capítulo 2. Los sistemas workflow/BPM 87 • Interpretar el flujo diseñado de forma grafica o textual. • Poder controlar todas las llamadas o instancias del proceso para cada uno de los casos que estén en ejecución en cada instante. • Gestión de las tareas o actividades que se ejecutan secuencialmente o en paralelo. • El control de las actividades que se envían a los participantes, así como el control del estado de cada una de ellas y los posibles caminos o flujos futuros que tendrán dichas actividades. • Controlar y mantener todos los datos de control necesarios para la correcta ejecución del flujo de trabajo. • Seguimiento automático de los usuarios. 2.7 Características de una buena arquitectura workflow/BPM A continuación introducimos las características que toda arquitectura BPM debe poseer. Aunque cada plataforma de desarrollo BPM tiene su diseño distintivo y sus conjuntos de características específicas, es este apartado profundizaremos en el análisis de dichas características concentrándonos en aquellas que sean conceptualmente claras y permitan implementar los requerimientos de una aplicación en el mundo real. Una buena arquitectura utiliza la técnica de divide y vencerás (Carmona et al., 2009; van der Aalst, 2009), de forma que podamos descomponer la implantación de un sistema workflow/BPM en pequeños módulos que juntos permitan conseguir el éxito del proyecto. Esta aproximación nos permite, de igual forma, reutilizar bloques de código de un proyecto a otro, logrando una mayor agilidad en la puesta en marcha de un sistema. Esta técnica, como veremos en el capítulo 5, se usará en la metodología planteada dado que nos basamos para la construcción de módulos en bloques ya pre-construidos. Sistemas Workflow y BPM: metodología y casos de estudio 88 Es importante conocer bien la arquitectura del sistema BPM que estemos utilizando para implantar nuestros flujos de negocio. Las razones son las siguientes: • BPM es una tecnología emergente y por lo tanto existen múltiples implantaciones, estándares, desarrolladores, etc. Tener un control exhaustivo de la arquitectura nos permitirá profundizar en la personalización del producto a la organización concreta (Tyree, 2005). • Normalmente los usuarios de un sistema workflow/BPM conocen algunos aspectos esenciales de las tecnologías tales como la base de datos, sistemas operativos, routers de Internet, etc., pero estos mismos usuarios ven la arquitectura de un sistema BPM como algo difuso. En estos casos necesitan ayuda de un experto para aconsejarles qué solución workflow/BPM es la óptima para su caso concreto (Kim y Moon, 1997). • La documentación aportada por la mayoría de aplicaciones BPM trazan una línea muy fina entre las características definidas en el estándar el que se basan y las características más propietarias de su solución. Normalmente los clientes, cuando adquieren un producto, desconocen que posteriormente sobre dicho producto se realizan desarrollos para personalizarlo a sus requerimientos específicos y que dichos desarrollos pueden no ser compatibles con versiones futuras del producto adquirido (Carlsen et al., 1997). 2.7.1 Diseñando una solución BPM Para diseñar una buena solución BPM, primero es necesario observar el entorno del proyecto concreto: comprender el problema a resolver, dimensionar el problema y buscar la solución óptima para el caso concreto. El principal requerimiento de un sistema BPM es que permita diseñar, ejecutar, monitorizar y administrar un proceso Capítulo 2. Los sistemas workflow/BPM 89 de negocio en el cual van a interactuar tanto los usuarios (humanos) como otros procesos automáticos (máquinas). Una buena solución BPM debe proveer: • Diseño. Debe contener características para poder modelar los procedimientos de forma intuitiva (y lo más sencilla posible). La herramienta debe proveer algún diseñador gráfico (o diagramador) para dibujar los flujos de los correspondientes procesos. Al contrario que muchos diseños y análisis orientados a objetos que tienen una perspectiva más técnica, los flujos en BPM permiten que especialistas técnicos y consultores de negocio puedan trabajar de forma conjunta para resolver el problema. Los diagramas de flujo BPM permiten acercar los requerimientos del cliente a las capacidades de la tecnología. Adicionalmente, tener la capacidad para dibujar los procesos en un lenguaje cercano al sistema permite acelerar el proceso de implantación real de los mismos (White, 2004b). • Ejecución. Hace años, se pensaba que era impensable generar un proceso en ejecución a partir de un diagrama gráfico de un flujo. En la actualidad, esta funcionalidad es casi obligatoria en cualquier sistema BPM que se precie. El diagrama debe ser ejecutable, es decir, debe poder compilarse para generar aquellas piezas de código necesarias para ponerlo en ejecución. En muchos casos (sobre todo en proceso de alta complejidad) una vez compilado el diagrama es necesario completar el resultado con código creado específicamente para el problema que se desea resolver (Pandey et al., 2011). • Monitorizar. El sistema BPM debe proporcionar funcionalidades para visualizar el progreso del proceso definido. Normalmente esta visualización se realiza como una sucesión o secuencia de estados por donde dicho proceso ha pasado (histórico de su ejecución o auditoría del mismo). Pero adicionalmente, la monitorización incluye el control de excepciones (casos no contemplados en el diseño original del proceso), visualización en tiempo real CAPÍTULO III. REVISIÓN DE LOS SISTEMAS WORKFLOW Y BPM EN LA ACTUALIDAD Capítulo 3. Revisión de los sistemas workflow/BPM 99 En el capítulo anterior se realizó una introducción a los sistemas workflow y BPM como base fundamental del presente trabajo. Dado que un sistema de estas características tiene un alto grado de complejidad es importante conocer cómo se deben articular las distintas piezas que lo conforman de manera que la implantación en una organización sea un éxito. En el presente capítulo realizamos una revisión de aquellos sistemas ya existentes en la actualidad y su adecuación a organizaciones de tamaño medio o pequeño. 3 Revisión de sistemas BPM existentes En el presente capítulo vamos a describir las principales herramientas que hemos seleccionado y que operan en el mercado. En la revisión tendremos en cuenta los parámetros de arquitectura global del sistema que incluyen: diseño, ejecución, monitorización, administración, interacción humana e interacción con el sistema. En la figura 20 se recoge el resultado del estudio realizado por IDC MarketScape sobre las mayores plataformas de BPM existentes en la actualidad. Este informe ha sido realizado evaluando diez empresas del mercado (IBM, Oracle, TIBCO, Pegasystems, OpenText, SAP, EMC, Bosch, Bisagi y K2). Según este informe, las empresas líderes en suministrar plataformas BPM son IBM, Oracle y TIBCO. No obstante, las plataformas desarrolladas y comercializadas por estas empresas son de difícil aplicación para el tipo de organización objeto de este trabajo fundamentalmente por la dimensión de la inversión a realizar, ya que las empresas analizadas por el informe de IDC tienen por destinatarios a multinacionales, grandes corporaciones o gobiernos. Veamos a continuación las herramientas analizadas en este trabajo y que pueden ser usadas por pequeñas y medianas empresas u organizaciones. En concreto se estudiarán aquellas más reconocidas (han recibido un reconocimiento en forma de premio) o conocidas en el sector de la implantación de sistemas workflow/BPM. En Sistemas Workflow y BPM: metodología y casos de estudio 100 concreto revisaremos Bonita BPM, Red Hat jBoss BPM, ProcessMaker, Bisagi BPM, Tibco ActiveMatrix BPM y SAP. 3.1 Bonita BPM La solución Bonita BPM (Miguel y Charoy, 2003) consiste en un conjunto de aplicaciones basadas en código abierto que permiten automatizar los procesos de negocio en una organización. Ha sido considerado el mejor software opensource del año 2014 (InfoWorld, 2014). Esta solución permite conectar personas con los sistemas mediante la definición de flujos de trabajo, los cuales se diseñan con un modelador BPMN 2.0. Figura 20. Informe de sistemas workflow/BPM IDC MarketScape Fuente: IDC (2014) Capítulo 3. Revisión de los sistemas workflow/BPM 101 Bonita BPM permite (Bonita, 2015): • Colaborar. Vinculando a los consultores del negocio con el equipo de desarrollo tecnológico durante la fase del modelado. • Construir, optimizar y probar. Los modelos construidos pueden ser probados en entornos de explotación reales y simulados para obtener una realimentación que permitan optimizar los procesos modelados. • Conectar. Proporcionan un repertorio de webservices que permiten la conexión del sistema con otros alternativos. Los webservices permiten conectar distintas aplicaciones con Bonita BPM minimizando el código específico que se debe programar. • Desarrollar. A partir de un modelo de proceso, puede construirse una aplicación que siga dicho flujo. • Monitorizar. Una vez puesto en marcha el proceso modelado, existen herramientas para la creación de informes sobre los pasos que sigue cada caso en el proceso. Estos informes permiten comprobar que tanto las personas como el sistema operan con garantías de productividad. • Desplegar. Permite desplegar Bonita BPM en clústers de servidores que ofrezcan una mayor redundancia y tolerancia a fallos. 3.1.1 Arquitectura de Bonita BPM En la figura 21 se representa la arquitectura de componentes de Bonita BPM (Bonita, 2015). En la parte central nos encontramos con el motor de workflow/BPM del sistema el cual contiene módulos divididos en servicios genéricos y servicios BPM. Dentro del primer grupo encontramos los sistemas de autenticación, gestión documental, manejador de eventos y módulos de identidad y persistencia para la comunicación con la base de datos. Dentro del segundo grupo encontramos la administración de procesos, de usuarios y tareas, así como la gestión de indicadores Sistemas Workflow y BPM: metodología y casos de estudio 102 y conectores con otros sistemas. Al igual que otras herramientas la conexión con aplicaciones externas se basa en webservices. Una característica interesante de la arquitectura la encontramos en parte superior donde a través de un API se puede acceder al motor vía aplicaciones desarrolladas por Bonita pero también otras aplicaciones desarrolladas por terceras empresas, lo cual, junto a la comunidad de usuarios existente en Internet, le amplía las posibilidades de adaptación a cualquier organización. Bonita posee un entorno de trabajo denominado Open Studio que incluye tres componentes: a) Bonita BPM Studio orientado a modelar los procesos de negocio: b) Bonita BPM Engine dedicado a la ejecutar los procesos previamente modelados y c) Bonita BPM Portal utilizado por los usuarios como interfaz para acceder a los procesos y trabajar con los mismos. Veamos a continuación cada uno de los citados componentes. Figura 21. Arquitectura de Bonita Fuente: Bonita (2015) Capítulo 3. Revisión de los sistemas workflow/BPM 103 3.1.2 Open Bonita BPM Studio Desde un punto de vista de diseño procesos, la solución de Bonita es muy completa. Posee un diagramador denominado Open Bonita BPM Studio el cual permite ir escribiendo el flujo que deseamos crear (ver figura 22). Además de poder dibujar de una forma sencilla los procesos, una de las características más notables y diferenciadoras respecto a otros productos es la posibilidad de conectarnos con otras aplicaciones que tengamos en nuestra organización (ERPs, CRMs, etc). Esta funcionalidad se basa en la creación de formularios web que pueden ser incrustados en otras aplicaciones como método para obtener o visualizar datos. Figura 22. Diagramador de Bonita Workflow Fuente: Bonita (2015) Sistemas Workflow y BPM: metodología y casos de estudio 104 3.1.3 Open Bonita BPM Engine Desde el punto de vista de la ejecución, el motor de Bonita está programado en Java J2EE. Proporciona a los desarrolladores un API en Java mediante el cual podemos interactuar con el motor pudiendo incluso llegar a utilizarlo dentro de nuestras propias aplicaciones sin necesidad de usar el resto de componentes de Bonita. El motor permite además realizar cambios en los procesos en tiempo real (sin necesidad de pararlos o esperar a que finalicen). Crear tareas ad-hoc sobre la marcha sobre los procesos o incluso detectar errores y tener la posibilidad de corregirlos modificando los flujos dibujados. 3.1.4 Open Bonita BPM Portal Respecto a la interacción humana, bonita proporciona una herramienta de visualización de actividades con capacidad de personalizar su apariencia y funcionalidades así como tener la posibilidad de ejecutarla desde dispositivos móviles. La interfaz posee una apariencia de aplicación cliente de correo electrónico pero enfocada a la resolución de las actividades o tareas que el usuario debe realizar. Capítulo 3. Revisión de los sistemas workflow/BPM 105 En la figura 22 se representa la visual de la interfaz donde se puede apreciar la opción principal ToDo (por hacer) la cual permite visualizar las tareas pendientes de ejecución por parte del usuario ordenadas por el plazo disponible para ejecutarlas. Seleccionando una de las tareas la interfaz nos abre el formulario correspondiente donde debemos incorporar la información que se nos está solicitando. Esta herramienta incluye también la posibilidad de monitorizar los procesos en los cuales estamos implicados junto con un cuadro de mando que permite conocer el estado de las tareas realizadas en todo momento. 3.1.5 Tipo de licencia Bonita workflow se ofrece en dos versiones diferentes: • Edición para la comunidad. Bajo licencia opensource se pueden utilizar las funcionalidades básicas de la herramienta Open Bonita BPM Studio así como Figura 23. Interfaz para los usuarios de Bonita workflow Fuente: Bonita (2015) Sistemas Workflow y BPM: metodología y casos de estudio 112 3.2.5 Monitorización de la actividad del negocio jBoss ofrece una herramienta para confeccionar cuadros de mando orientados no sólo a la escala directiva de la organización sino también a los consultores de negocio, analistas y usuarios en general. La herramienta permite componer una pantalla con gráficas y tablas de datos respecto a indicadores que se hayan definido en el sistema. Algunas de las funcionalidades incluidas en esta herramienta son: a) posibilidad de exportar las tablas de datos hacia Excel o fichero CSV (leíbles con cualquier versión de Excel); b) poder realizar filtros sencillos tales como búsquedas y filtros más avanzados basados en consultas SQL; c) tener la posibilidad de definir los cuadros de mando por perfiles o roles de los usuarios. En la figura 28 se muestra un ejemplo de cuadro de mando definido. Figura 27. Administración de tareas e instancias Fuente: jBoss (2015) Capítulo 3. Revisión de los sistemas workflow/BPM 113 3.2.6 Tipo de licencia jBoss Red Hat se ofrece bajo licencia opensource de forma que cualquier desarrollador puede descargarse el software completo y utilizarlo. Por otro lado, la empresa Red Hat proporciona consultoría a las organizaciones que estén interesadas en un nivel de diseño de procesos o en el mantenimiento completo de los sistemas donde funcionaría el software. 3.2.7 Resumen final de jBoss de Red Hat Uno de los aspectos positivos de jBoss es tener la capacidad para desarrollar nuestras propias aplicaciones en Java o ejecutarlas como webservice sobre el motor de jBoss. Esta funcionalidad aporta mucha flexibilidad y por tanto se adapta bien a situaciones complejas reales. Figura 28. Cuadro de mando en jBoss Fuente: jBoss (2015) Sistemas Workflow y BPM: metodología y casos de estudio 114 Adicionalmente al núcleo interno proporciona una combinación de reglas de negocio o procesamiento de eventos que lo convierten en una solución potente. Por otro lado, jBPM tiene algunas carencias en la asignación de actividades a los usuarios. Teóricamente, jBPM posee las primitivas de usuario, grupo y perfil, pero en la práctica la consola web no da accesos a gestionar la posibilidad de mover actividades desde un grupo de usuarios a otros (Wohed y Rusell, 2009). Aún siendo relativa la importancia del problema anterior (dependería del proceso concreto a implantar), nuestra opinión es que jBPM está demasiado próximo al perfil tecnológico y resulta complejo de usar por un consultor de negocio (el cual necesitaría una herramienta de diseño más amigable). De hecho, tener el diseñador de procesos como plug-in de Eclipse (herramienta de programación Java utilizada por los diseñadores) hace que sea muy complicado de usar para los usuarios que participan en el análisis de los procesos de negocio. 3.3 ProcessMaker ProcessMaker es un conjunto completo de herramientas orientadas a proporcionar un sistema BPM a las organizaciones creado en el año 2000 por la empresa ProcessMaker inc. La herramienta está en continua evolución y ha recibido varios premios a lo largo de su historia tales como la mención Bossie Awards 2013 como el mejor software open source publicado por InfoWorld (InfoWorld, 2013). Consta de las siguientes funcionalidades principales: • Diseñador de mapa de procesos. • Constructor de formularios (Dynaform Builder). • Generador de plantillas de documentos. Capítulo 3. Revisión de los sistemas workflow/BPM 115 • Generador de reglas de negocio. • API orientado a webservices. • Debugger. • Administración de usuarios. • Gestor de tareas. • Gestor documental. • Gestión de notas. 3.3.1 Arquitectura de ProcessMaker En la figura 29 se representa la arquitectura de ProcessMaker. Los módulos se dividen en dos partes: el entorno de diseño y el motor de ejecución. El primer grupo engloba las herramientas para diseñar los procesos, definir las reglas de ejecución, crear los formularios y por último definir los documentos tanto de entrada como de salida. El segundo grupo engloba todo lo necesario para poner en ejecución los procesos previamente definidos. Se incluye el administrador de casos el cual permite comprobar la situación de ejecución de cada uno de los procesos y administrarlos y por último, un módulo para la generación de Cuadros de Mando. En la parte inferior de la arquitectura, ProcessMarker se sustenta sobre una pila de WAMP (Windows, Apache, MySQL y PHP) o LAMP (Linux, Apache, MySQL y PHP) y el framework Gulliver (ProcessMaker, 2015). En este caso, Windows o Linux es el sistema operativo, Apache es el servidor web, MySQL es el motor de bases de datos y PHP es el lenguaje de programación. En la parte superior de la arquitectura, ProcessMarker es accesible vía navegadores web aunque está optimizado para Mozilla Firefox. Además cuenta con la posibilidad Sistemas Workflow y BPM: metodología y casos de estudio 116 de sincronizarse con un LDAP (Light Directory Authentication Protocol) (Howes et al., 2003) para poder autenticar a los usuarios. Por último, también contempla la posibilidad de conectarnos vía webservices con otros sistemas (u otros webservices) tales como CRMs, herramientas de gestión de proyectos, etc). En la figura 30 se recogen los componentes del núcleo de ProcessMarker. Podemos visualizar la relación entre los elementos que deben estar presentes en el servidor donde ProcessMarker esté instalado y los principales componentes e interfaces con el resto de usuarios. Figura 29. Arquitectura de los módulos de ProcessMaker Fuente: Process Marker (2015) Capítulo 3. Revisión de los sistemas workflow/BPM 117 Como se mencionó anteriormente, en la parte inferior de la arquitectura encontramos un entorno WAMP o LAMP. Para la relación con el motor de bases de datos ProcessMarker utiliza Propel (Propel, 2015) el cual permite mapear los distintos objetos que contienen los datos con las tablas existentes en la base de datos. Esta capa intermedia permite utilizar ProcessMarker con otros motores de bases de datos conocidos tales como: PostgreSQL (Postgresql, 2015), Oracle (Oracle, 2015), and SQL Server (Microsoft, 2015) y Sybase (SAP, 2015). Por encima de esta capa nos encontramos con el framework opensource Gulliver. Por encima de Gulliver se sitúan todas aquellas librerías de terceras instancias que utiliza ProcessMarker: RBAC (Ferraiolo et al., 1995) para la administración de los perfiles de usuario, librerías para el envío de notificaciones como mail o PHP Mailer, Figura 30. Elementos del núcleo de ProcessMaker Fuente: Process Marker (2015) Sistemas Workflow y BPM: metodología y casos de estudio 118 etc. Por último, utiliza PHP SOAP (Box et al., 2000) para poder administrador los servicios web que permiten la comunicación con otros sistemas. A continuación revisaremos las características de las herramientas que proporciona ProcessMarker. 3.3.2 Diseñador de mapa de procesos Orientado a los consultores de negocio, este módulo permite diagramar los flujos en una aplicación totalmente basada en web. La herramienta es bastante intuitiva pudiendo diseñar los procesos de manera rápida y, adicionalmente, proporciona un control de versiones de cada uno de los procesos definidos (ver figura 31). El formato de los diagramas sigue el estándar BPMN 2.0 (Business Process Modeling and Notarion) de forma similar a los diagramas de estado descritos en el capítulo 2. Las características de la interfaz incluyen de forma destacada: a) drag&drop de las distintas actividades en pantalla; b) poder definir puertas de comunicación entre los distintos procesos y establecer condiciones para la sincronización y comunicación de los mismos; c) conectar con el resto de herramientas de Process Marker para crear formularios online y plantillas de documentos imprimibles. Capítulo 3. Revisión de los sistemas workflow/BPM 119 3.3.3 Constructor de formularios (Dynaform Builder) Gracias al constructor de formularios, los consultores de negocio pueden crear formularios específicos y unirlos a cualquier proceso. Se basa en un interfaz drag&drop que permite la creación de elementos tales como cajas de texto, check boxes, selects (dropdowns), rejillas, datepickers, campos para la subida de ficheros, etc. Adicionalmente contiene estructuras condicionales para que se habiliten o deshabiliten campos del formulario. Figura 31. Diseñador de procesos Fuente: Process Marker (2015) Sistemas Workflow y BPM: metodología y casos de estudio 120 Por otro lado, los usuarios con mayor cualificación tecnológica pueden optimizar la visual del formulario incluyendo hojas de estilo específicas para el mismo (CSS) o códigos javascript que deben ejecutarse en el navegador. En la figura 32 se puede apreciar el aspecto general del diseñador de formularios. 3.3.4 Generador de plantillas de documentos Esta herramienta permite la creación de plantillas para todo tipo de documentos necesarios para el funcionamiento de la aplicación (facturas, recibos, cartas, mensajes de confirmación, contratos, etc.). Esta herramienta está orientada a Figura 32. Diseñador de formularios (Dynaform Builder) Fuente: Process Marker (2015) Capítulo 3. Revisión de los sistemas workflow/BPM 121 facilitar la creación de cualquier tipo de documento impreso, los cuales se pueden vincular a actividades donde se generarán sustituyendo las variables genéricas de la plantilla por aquellas que obran en la actividad concreta (ver figura 33). 3.4 Generador de reglas de negocio Esta herramienta permite definir puntos de decisión vinculados a los flujos diseñados para cada uno de los procesos en función de condiciones que cada una de las organizaciones quiera establecer. En estos puntos se puede incluir una lógica de forma que la actividad siga uno u otro camino dentro del proceso. En la figura 34 se representa un ejemplo de reglas de negocio dentro del interfaz de creación de las mismas. Figura 33. Generador de plantillas de documentos Fuente: Process Marker (2015) Sistemas Workflow y BPM: metodología y casos de estudio 128 La capa de proceso se centra en la definición de widgets (elementos que componen la interfaz de cada usuario), formularios y reglas de negocio. Por debajo de la capa de datos encontramos la posibilidad de integrarnos con otras aplicaciones así como con la base de datos. Figura 38. Arquitectura de la solución de Bizagi Fuente: Bizagi (2015) Capítulo 3. Revisión de los sistemas workflow/BPM 129 3.5.2 Creación de procesos de negocio con Bizagi Modeler Bizagi Modeler es una herramienta que le permite modelar y documentar procesos de negocio que está basada en el estándar BPMN (Business Process Model and Notation). Además de modelar, permite generar los formatos de documentos de salida y establecer integraciones con otros sistemas (tipo Visio o fichero XML). La interfaz es bastante intuitiva y amigable. Cada archivo generado con la herramienta se denomina modelo y puede contener uno o más diagramas, de tal forma que puede ser para toda la organización, o un departamento o un proceso específico. En la figura 39 se representa el modelador de Bizagi. 3.5.3 Bizagi Studio Bizagi Studio convierte los modelos de proceso diseñados con la herramienta anterior en aplicaciones ejecutables que pueden ser distribuidas por toda la organización. En principio, no requiere ningún código de programación adicional (es Figura 39. Bizagi Modeler Fuente: Bizagi (2015) Sistemas Workflow y BPM: metodología y casos de estudio 130 decir, el proceso es si mismo la aplicación), lo que implica las siguientes ventajas: a) la velocidad de puesta en marcha de la herramienta BPM es alta; b) permite generar reglas o condiciones de negocio sin salirse del editor gráfico; c) permite asignar cargas de trabajo de los usuarios y posibilitar cambios de rutas de la actividades con poco esfuerzo: d) permite una fácil integración con otras aplicaciones existentes en la organización mediante. En la figura 40 podemos visualizar el interfaz de Bizagi Studio. Figura 40. Bizagi Studio Fuente: Bizagi (2015) Capítulo 3. Revisión de los sistemas workflow/BPM 131 3.5.4 Bizagi Engine Bizagi Engine permite ejecutar los procesos y entregarlos a las aplicaciones de escritorio (o móviles) de los usuarios participantes. Este motor es capaz de manejar proyectos BPM críticos donde los requisitos de rendimiento son importantes (abarcan miles de usuarios y millones de casos simultáneamente). Adicionalmente cuenta con una herramienta para visulizar el nivel de ejecución de los procesos, establecer prioridades, etc. Dispone de herramientas que pueden permitir anticiparse a problemas futuros mediante un análisis de los datos históricos. 3.5.5 Portal de trabajo de Bizagi La herramienta donde los usuarios pueden acceder a las tareas asignadas o crear nuevos casos de un proceso concreto se denomina portal de trabajo, el cual es el resultado de la compilación del diagrama del proceso realizado por Bizagi Studio. Una las características más notables reside en que en el momento en que se cambia el diagrama del proceso y se cambia también la aplicación que ejecuta el usuario de forma transparente. Figura 41. Portal de trabajo de Bizagi Fuente: Bizagi (2015) Sistemas Workflow y BPM: metodología y casos de estudio 132 Dependiendo de los permisos de los que disponga el perfil del usuario, el portal permite administrar los procesos y reasignarlos a otros usuarios en los casos que lo requieran (por ejemplo, cuellos de botella a la hora de ejecutar una determinada actividad). En la figura 41 se muestra la interfaz del portal de trabajo. 3.5.6 Tipos de licencia Bizagi no es una solución opensource por lo que requiere el pago de licencias por su utilización. Estas pueden ser de dos tipos: • Perpetua. Se realiza un único pago y se puede utilizar la versión adquirida de forma permanente. • Suscripción. Se realiza un pago por usuario de forma anual. Esta modalidad da derechos a nuevas actualizaciones y versiones del software. 3.5.7 Resumen de Bizagi BPM Bizagi es una solución potente para automatizar procesos de negocio en las organizaciones utilizando herramientas workfow/BPM. No obstante, estimamos que no es apta para organizaciones de tamaño mediano y pequeño por las razones siguientes: • Costes de inversión. El modelo de pagos por licencias de uso de software no se adapta a las empresas pequeñas de nuestro entorno (que adicionalmente deben invertir en la consultoría y mantenimiento para la puesta en marcha del software). Por otra parte, como se ha comentado anteriormente en este trabajo, existen soluciones opensource que no requieren de inversión alguna en materia de licencias. Capítulo 3. Revisión de los sistemas workflow/BPM 133 • Modelo de generación de aplicaciones. El software se genera automáticamente a partir del modelado de los procesos y su posterior compilación con Bizagi Studio, por lo que en un caso ideal no es necesaria ninguna programación adicional. No obstante, en las etapas de integración con otros software existentes en necesaria la elaboración de código de programación basados en APIs ejecutables sobre webservices. 3.6 Tibco ActiveMatrix BPM TIBCO Software Inc.es un proveedor de software para organizaciones y una de sus soluciones es Active Matrix BPM la cual es una de las líderes en el mercado (habiendo sido probada para altos volúmenes de datos y de usuarios trabajando simultáneamente). Una característica destacada de esta herramienta es la capacidad de ser ejecutada en dispositivos móviles (smartphones) lo que permite conseguir que los flujos de trabajo se ejecuten independientemente de la ubicación del usuario (Tibco, 2015). Las características más importantes son las siguientes: • Sistema de informes configurable por el propio usuario. • Administración de recursos vinculados a cada una de las tareas. • Orientado a la automatización de procesos en el mundo real. • Sistema rápido de diseño de procesos a partir de patrones previamente configurados. • Posibilidad de crear modelos flexibles para cada una de las organizaciones consiguiendo lo que se denomina organización elástica. • Soporte muchos estilos de trabajo basados en la misma herramienta. Sistemas Workflow y BPM: metodología y casos de estudio 134 • Posibilidad de integrarse con webservices. • Basada en un framework flexible. 3.6.1 Arquitectura de Tibco ActiveMatrix BPM En la figura 42 podemos ver la arquitectura de ActiveMatrix, la cual se basa en un conjunto de componentes independientes integrados dentro del entorno de ejecución que se agrupan en nodos lógicos de diferentes tipos. Un nodo lógico se define como un grupo de aplicaciones heterogéneas que tienen en común la necesidad de ejecutarse en el mismo nodo físico (o servidor). Los elementos de la arquitectura son los siguientes: a) los componentes web proporcionan las interfaces mediante las cuales los usuarios acceden y trabajan con el sistema; b) los servicios de procesos, los cuales ejecutan las aplicaciones de negocio diseñadas por la herramienta; c) los servicios de recolección de eventos encargados de obtener y enviar los eventos que se producen en el sistema a los componentes que requieran conocerlos; d) los servicios de calendario, que proporcionan elementos relacionados con el tiempo a cada uno de los procesos; e) os servicios de administración de los recursos de negocio, responsables de distribuir y administrar las actividades o tareas a cada uno de los participantes; f) los servicios de directorio que mantienen la estructura de la organización y proporcionan los elementos necesarios para la autenticación y autorización de acceso; g) los servicios de presentación de trabajo; h) los servicios de flujo de página, y, por último; i) los servicios de negocio. 3.6.2 Herramienta de modelado Tibco Business Studio La herramienta para poder diseñar procesos de negocio se denomina Tibco Business Studio. Se trata de un módulo que se coloca sobre el entorno de desarrollo Eclipse en el cual los analistas de negocio pueden capturar, diseñar y modelar todos los aspectos de los procesos, así como confeccionar los modelos de datos que se Capítulo 3. Revisión de los sistemas workflow/BPM 135 utilizarán dentro de dichos procesos. A partir de esta herramienta se generará una aplicación ejecutable que se puede desplegar en la organización correspondiente para ser ejecutada con el motor de ActiveMatrix. 3.6.3 Capacidades para las empresas Dentro de las características de la herramienta orientadas a la empresa podemos citar: • Totalmente orientado a modelar. La herramienta de Tibco permite modelar en tiempo de diseño todo tipo de procesos, formularios, flujos de página o Figura 42. Arquitectura de Tibco ActiveMatrix BPM Fuente: Tibco (2015) Sistemas Workflow y BPM: metodología y casos de estudio 136 asistentes, datos, organizaciones y perfiles, sin necesidad de codificar líneas de programación. Por lo tanto proporciona un diseño rápido de aplicaciones para una mejor comprensión de los procesos implantados para el negocio. • Ha sido diseñado para poder crear todo tipo de procesos independientemente de su complejidad. • Flexible e independiente de la complejidad de la organización. Las organizaciones raramente operan de una forma estrictamente jerárquica. No obstante así es como típicamente están estructurados los organigramas de las empresas en el mundo real. Muchas compañías operan a través de relaciones complejas (muchas veces cambiantes) entre los distintos departamentos, personas, sistemas, perfiles del equipo de trabajo e incluso oficinas separadas geográficamente. Dentro de la herramienta podemos crear el modelo de la organización y definir relaciones diversas entre los distintos participantes de los procesos, lo que permite a los administradores del negocio a cambiar la estructura de su organización a través de la modificación de perfiles y permisos sobre las distintas opciones, lo cual tiene un efecto inmediato sobre las instancias de los procesos que se encuentren en ejecución en el momento del cambio. • Sistema de generación de informes. Active Matrix posee un módulo para la generación de informes configurable por el propio usuario basados en Jasper Reports. Utilizando este asistente los usuarios pueden configurarse su propio dashboard. 3.6.4 Características técnicas Dentro de las características técnicas destacamos las siguientes: • Proporciona un sistema basado en cluster para mejorar la seguridad y prestaciones del sistema, el cual ha sido probado ejecutando cientos de miles de procesos. Capítulo 3. Revisión de los sistemas workflow/BPM 137 • Posee la capacidad de aislar recursos y datos dentro de una misma instalación para distintas empresas. Esto significa que múltiples empresas pueden utilizar el mismo servidor garantizándose en todo momento que los datos de una no interfieren en los de la otra. • Posee una interfaz flexible con opciones parametrizables. • Proporciona un API para extender el funcionamiento de la herramienta. 3.6.5 Interfaces del usuario Las interfaces construidas con la herramienta se basan en gadgets que se conectan a un escritorio de usuario, lo que permite una completa flexibilidad a la hora de configurarlos. El escritorio de la herramienta recibe el nombre de OpenSpace, el cual está basado en AJAX para dar una mayor sensación de ejecución en entornos locales. Dentro de OpenSpace se crean los formularios automáticos los cuales permiten fluir la información entre cada uno de los participantes. 3.6.6 Tipo de licencia Tibco ActiveMatrix se sumistra bajo licencia de uso por lo que no se contempla la posibilidad de opensource en alguno de los componentes o herramientas. 3.6.7 Resumen de la solución ActiveMatrix BPM de Tibco Como resumen, ActiveMatrix es una de las mayores aplicaciones de workflow/BPM existentes. Sus ventajas se pueden resumir en: a) tener una única solución para Sistemas Workflow y BPM: metodología y casos de estudio 144 (que pueda realizarlo un usuario sin poseer conocimientos técnicos del sistema). • Incorpora cuadro de mandos (dashboard). Se revisa si permiten la creación de un cuadro de mando gráfico con múltiples indicadores y la posibilidad de definir nuevos. • Incorpora gestión de usuarios. Se compara la existencia o no de una gestión de usuarios desglosados en perfiles. • Incorpora gestión de tareas. Se revisa la existencia de una herramienta de gestión de tareas accesible a través de un interfaz hacia el usuario. • Incorpora gestión de mensajes y alertas. Se revisa la existencia de una gestión de alertas configurables pudiendo crear nuevos tipos y dando la posibilidad de ser enviadas no sólo por email sino también por Google Talk o SMS. CAPÍTULO IV. METODOLOGÍAS PARA LA IMPLANTACIÓN DE UN SISTEMA WORKFLOW/BPM EN UNA ORGANIZACIÓN Capítulo 4. Metodologías para la implantación de un sistema workflow/BPM 147 En los capítulos anteriores hemos realizado una introducción a los sistemas workflow/BPM, así como una revisión de los principales sistemas que podrían ser susceptibles de ser implantados en una organización de tamaño mediano/pequeño. Una vez la organización ha decidido qué solución tecnológica utilizará, llega el momento de planificar la implantación del sistema, es decir, de diseñar los procesos de negocio y ponerlos en marcha en todos los departamentos incluidos en el alcance del proyecto. El presente capítulo expone las principales metodologías utilizadas para la implantación de los sistemas workflow/BPM en las organizaciones profundizando en aquellas consideradas ágiles y que serán de una mayor utilidad para los objetivos del presente trabajo dado que deseamos implantar un sistema workflow/BPM en plazos de tiempo alcanzables por la organización. 4 Introducción a las metodologías de implantación Como se ha tratado en el capítulo 2, una de las principales funciones de todo sistema workflow/BPM es alinear los objetivos de la organización con los procesos de trabajo, tratando de buscar su mejora continua y establecer medidas para monitorizar las acciones de los usuarios y los resultados objetivos en la ejecución de dichos procesos. Teóricamente, la implantación de un sistema workflow/BPM debería formar parte de la estrategia global de la organización, aunque también es viable aplicar el sistema a un único proceso o departamento (por ejemplo, enfocado sólo a un departamento comercial o a un departamento de logística, etc.). Para tener éxito en el proceso de implantación es necesario contar con una metodología de trabajo que indique los pasos a seguir (Rosemann y Zur Muehlen, 1998; Dehnert, 2003; Medina-Mora et al., 1992). Con carácter general, todas las metodologías deben contar con: Sistemas Workflow y BPM: metodología y casos de estudio 148 • Fase 1, análisis del proceso. La primera actividad a realizar consiste en documentar aquellos procesos que se desean automatizar tratando de prestar atención a aquellos que aportan mayor valor hacia el cliente (o ciudadano en el caso de una administración pública). Es muy conveniente establecer una normalización de dicha documentación para crear un repositorio central en esta fase inicial. • Fase 2, mejora de los procesos. La metodología debe sugerir una forma de análisis de cada uno de los procesos con el ánimo de localizar puntos redundantes, no operativos o simplemente innecesarios para el objetivo final. Esta fase debe generar un documento de recomendaciones de actividades a eliminar o cambiar para conseguir esa mejora del proceso. • Fase 3, automatización y optimización de los procesos. En esta fase se implantan los procesos sobre la herramienta de workflow/BPM seleccionada y se analiza su ejecución y los resultados obtenidos. En esta fase podemos utilizar distintas tecnologías para ayudarnos en nuestra búsqueda de la máxima eficiencia y productividad. Por ejemplo, usando herramientas de monitorización para obtener datos tales como reducción en el tiempo de ejecución, eliminación de cuellos de botella o bucles infinitos. En la figura 43 se representa de forma global los pasos generales que debe seguir una metodología de implantación de un sistema workflow/BPM. Estas fases se repetirían de forma que estemos inmersos en un proceso de mejora continua de los procesos creados. Muchas de las metodologías existentes pueden resultar complejas debido a que poseen muchas fases y tareas a realizar, siendo tan sólo útiles en determinados entornos. Sin embargo, cuando tratamos con organizaciones de tamaño mediano pequeño, aplicar una metodología no apropiada puede acabar con el objetivo de mejora continua (Aksu et al., 2010). No obstante, es importante tener en cuenta que aunque en este tipo de organizaciones se necesite una operatoria más ágil, esto no significa que debamos dejar de aplicar una metodología determinada. Capítulo 4. Metodologías para la implantación de un sistema workflow/BPM 149 Todas las metodologías poseen similitudes en sus técnicas y objetivos. Cualquier metodología genérica (Elzinga et al., 1995) trata de responder a las siguientes preguntas respecto a la implantación de un sistema workflow/BPM: a) ¿Cómo se realizan los procesos en la actualidad? Por ejemplo, si estuviésemos automatizando Figura 43. Fases de una metodología general de implantación de un sistema workflow/BPM Fuente: StraightForward Methods LLC (2012) Sistemas Workflow y BPM: metodología y casos de estudio 150 un proceso de facturación ¿Qué pasos concretos se están siguiendo? ¿Quién debe firmar las facturas? ¿Cómo deben ser entregadas? b) ¿Por qué estamos haciendo el proceso de esta manera? ¿Podemos hacerlo mejor? ¿Podemos eliminar alguno de los pasos, unir dos actividades en una única o automatizar algunas partes del proceso? ¿Existe algún tipo de restricción jurídica o económica al mismo que debamos tener en cuenta y nos limite la optimización en el proceso que perseguimos?. Los pasos descritos dentro de esta metodología genérica los podemos representar en la figura 44. La selección de una metodología u otra será una parte importante de la implantación de un sistema workflow/BPM. En esta decisión debemos tener en cuenta la cultura empresarial y las habilidades de los equipos de trabajo que se Figura 44. Fases en un metodología genérica de implantación de un sistema workflow/BPM Fuente: Adaptado de Openasoft (2015) Capítulo 4. Metodologías para la implantación de un sistema workflow/BPM 151 pueden formar y, además, las herramientas concretas que vamos a utilizar y los sistemas que tenemos en la actualidad. Dentro de este aspecto, un fuerte liderazgo por parte de la dirección es vital para garantizar el éxito del proyecto (Kozlowski et al., 2015). 4.1 Metodologías ágiles frente a las tradicionales Las metodologías tradicionales se basan en estructurar la ejecución de un determinado proyecto en fases y tareas con un alto nivel de detalle orientando las mismas a conseguir un determinado objetivo (Martin, 2003), mientras que las metodologías ágiles se basan en planificar en función de los objetivos de la organización, priorizando actividades que aporten más valor a la misma y definiendo el detalle de las tareas a medida que se avanza en el proyecto (Neur et al., 2005). Sin embargo, los objetivos muchas veces son cambiantes y producen una indeterminación que, a medida que avanza el proyecto, va desapareciendo. Por lo tanto, existe una gran diferencia entre la utilización de un tipo de metodología u otra en relación con el tiempo de planificación ya que las metodologías ágiles tratan de reducirlo al mínimo y crear una dinámica en cortos periodos en donde dicha planificación se va conformando a medida que se avanza en el desarrollo del proyecto. Existen una serie de conceptos que son comunes a ambas metodologías tanto ágiles como las tradicionales, que conviene tener presente: • El triángulo de objetivos, coste y tiempo. Cualquier cambio en uno de los aspectos anteriores provoca irremediablemente la variación de los otros dos. En aquellos casos donde se fuerce no mover los otros dos parámetros se producirá un impacto en la calidad de proceso de implantación del sistema workflow/BPM en que estemos inmersos (Atkinson, 1999). Sistemas Workflow y BPM: metodología y casos de estudio 152 • Los riesgos asociados a la implantación. Debe existir una gestión de los riesgos que permita delimitarlos tanto en el tiempo como en el alcance que puedan tener (Chapman y Ward, 1996). • Gestión de hitos. Se deben definir cuáles son los puntos de entrega parcial y el momento en el que se producirán, por ejemplo, la implantación de cada uno de los procesos de negocio en el sistema workflow/BPM (Larson, 2011). • Dependencias de otros sistemas. Se deben tener en cuenta los puntos de comunicación y sincronización con otros sistemas tanto de una manera funcional como de integración utilizando webservices (Alonso et al., 2004). En la figura 45 se representan los anteriores conceptos en el caso de una metodología tradicional. En el vértice del tiempo se crea el plan del proyecto de implantación que, en el caso de las metodologías tradicionales, se basa en un control predictivo mediante el cual: a) se identifican inicialmente las fases y tareas a ejecutar, si bien esta planificación podría ser modificada a medida que la implantación avance; b) se realizan pocas entregas de los procesos implantados (productos) en el tiempo (incluso una única entrega) y, por lo tanto, el feedback que se pueda generar suele llegar tarde y después de haber realizado muchos avances, por lo que aquellas modificaciones que sea necesario acometer pueden afectar enormemente a los plazos y al coste; y c) se realiza una gestión del conocimiento una vez finalizado el proyecto de implantación, por lo que todas aquellas formas de hacer (know-how) que se hayan aprendido no se pueden aplicar en el propio proyecto. Capítulo 4. Metodologías para la implantación de un sistema workflow/BPM 153 En la figura 46 se representan los conceptos anteriores pero en el caso de una metodología ágil, en la que la planificación es el control empírico donde se produce una inspección continua y una adaptación de dicha planificación. En este caso, los objetivos de la implantación se realizan de forma iterativa e incremental por lo que los objetivos van cambiando en función de aquello que aporte valor y sea prioritario para la organización. Como se puede apreciar en la figura, en estas metodologías se realizan múltiples entregas a lo largo del tiempo en la que se va conformando el producto final mediante una alineación gradual con las expectativas del proyecto final. En cada uno de los pequeños avances se definen en detalle las tareas a ejecutar para el siguiente paso, pero no se realiza un detalle de todas las tareas al comienzo del proyecto de implantación tal y como hacen las metodologías tradicionales. Figura 45. Metodologías tradicionales Fuente: Proyectos Ágiles (2015) Sistemas Workflow y BPM: metodología y casos de estudio 256 • Personas con capacidad de decisión que no han sido convocadas a las reuniones o no han podido acudir debido a algún motivo. En muchas ocasiones existen reuniones donde se deben tomar decisiones importantes y, sin embargo, las personas clave en la organización que las deben tomar no han acudido a la reunión (Nicolás y Turbé, 1991). • Personas que acuden a la reunión pero que no conocen muy bien el motivo por el cual se les ha convocado. Es más, muchas veces incluso desconocen el orden del día a tratar en la reunión (Jarvenpaa et al., 1988). • Reuniones que, aun siendo conocido el orden del día, se desvían de su objetivo inicial y acaban siendo una sucesión de ideas, comentarios o quejas relativos a problemas que están surgiendo en el proyecto. • Reuniones que finalizan, pero en la que los integrantes de la misma no conocen muy bien qué tareas se deben realizar ni cuáles son exactamente los acuerdos que se han tomado (Bellotti et al., 2003). • Reuniones donde no se realiza un acta de la sesión que incluya los acuerdos tomados. • Reuniones que se alargan en el tiempo de forma exagerada. • Reuniones donde los puntos tratados en la misma ya han sido analizados con anterioridad. Por lo tanto, se repiten los contenidos a tratar en las reuniones debido a que no se toman las decisiones correspondientes. La gestión de reuniones suele incluir un conjunto de habilidades para jefes de proyecto, directivos y gerentes que a menudo se ignora. Una errónea planificación en las reuniones provoca grandes costes en la organización (temporales o económicos). En la figura 83 se representan las fases concretas que se debe abordar en toda reunión dentro de la metodología propuesta. Capítulo 5. Propuesta: metodología ágil, arquitectura y framework 257 Se debe realizar acciones previas a la celebración de la reunión, durante la reunión y posteriores a la reunión. Con carácter previo se debe preparar la misma confeccionando el orden del día el cual debe incluir al menos: la revisión de todas las tareas asignadas en la reunión anterior, la comprobación de los avances en las mismas, la discusión de las dificultades encontradas y sus posibles soluciones con carácter general y la asignación las tareas para el periodo siguiente. Una vez preparado el orden del día se deben convocar a los participantes utilizando medios tecnológicos (tacnetting, Google Calendar o cualquier otra herramienta similar) que permitan lanzar la invitación y recibir las confirmaciones de asistencia a la misma, o en su caso, la comunicación de que el convocado no podrá asistir. Figura 83. Fases de las reuniones dentro de la metodología propuesta Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 258 Es fundamental que todos los participantes tengan claras cuáles son las reglas a seguir durante la reunión. Estas reglas, a su vez, se habrán definido en la primera reunión de lanzamiento del proyecto. Además, las reuniones no deben extenderse más allá de dos horas de duración en las cuales, simultáneamente, se va elaborando el acta de los temas tratados y acuerdos alcanzados. Estos acuerdos se traducirán en tareas concretas que se introducirán en el sistema, de manera que al terminar la reunión todos los participantes cuentan ya con el listado actualizado de tareas a ejecutar y con el acta final de la reunión. En la figura 84 se muestra un ejemplo de convocatoria de reunión utilizando medios digitales. Al utilizar este medio, todas las reuniones quedan registradas en el sistema incluyendo los participantes de las mismas y los acuerdos alcanzados. En la figura 85 se recoge un ejemplo de envío de mensaje que el sistema realiza automáticamente con la invitación a participar en una reunión. El usuario debe Figura 84. Convocatorias de las reuniones Fuente: Elaboración propia Capítulo 5. Propuesta: metodología ágil, arquitectura y framework 259 confirmar su asistencia activando el botón correspondiente desde su aplicación de correo electrónico. Las reuniones deben mantenerse al menos una vez en semana para mantener el carácter ágil de la metodología. 5.3.10 Gestión de tareas e hitos Difícilmente podremos gestionar la implantación de un sistema workflow/BPM en una organización si no conocemos exactamente las tareas que debe hacer cada participante implicado en el proyecto y el estado de las mismas. Los objetivos de la gestión de tareas son: • Que cada participante, empleado y colaborador sepa exactamente las tareas que debe realizar, incluyendo las fechas límite para su realización. Figura 85. Solicitud de asistencia a reunión por medios electrónicos Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 260 • Que cada participante entienda que su tarea forma parte de un “todo” en la organización y tome conciencia de que su trabajo influye en el trabajo de los demás. • Que cada participante pueda asignar, en función de sus atribuciones, tareas a otros participantes. • Que los mandos intermedios o superiores a cargo de grupos de trabajo puedan gestionar de forma sencilla y eficaz la carga de trabajo que tienen cada uno de sus participantes. Adicionalmente, las propias tareas para la implantación del sistema deben seguir un flujo o secuencia de estados sencilla que identifique la situación real de cada una de ellas. En este sentido, toda tarea puede estar en cuatro estados distintos: a) inactivo; b) desarrollo; c) realizado y d) histórico. El significado de cada uno de los estados es el siguiente: • Inactivo. Aún no se ha empezado a realizar la tarea. Cuando asignemos una tarea a un participante, este será el estado del punto de partida. • Desarrollo. Se está trabajando con la tarea. Cuando un participante reciba la tarea y va a comenzar con su ejecución debe indicar este estado de forma que el resto de compañeros sepa que está trabajando en la misma. • Realizado. Se ha finalizado la tarea. Cuando un participante haya terminado de hacer una tarea, debe pasarla a este estado, de forma que la persona que la asignó, sepa que está terminada. • Histórico. La tarea se ha finalizado y se ha supervisado correctamente. Cuando el creador de la tarea recibe una tarea realizada, puede pasarla al estado histórico simbolizando que es correcta. Si no fuese correcta, volvería a remitirla al usuario destinatario para que lo corrija. Capítulo 5. Propuesta: metodología ágil, arquitectura y framework 261 Para comprender mejor el uso de la gestión de tareas dentro de la metodología consideremos el siguiente ejemplo práctico. Supongamos un proyecto donde el objetivo es la implantación de un sistema workflow en una organización. El proyecto cuenta con cuatro participantes en el que Antonio es el líder y María, Juan e Isabel participan con perfiles de consultor de negocio y logística, analista de sistemas y programadora respectivamente. En la figura 86 se puede visualizar los participantes del proyecto y sus perfiles concretos. En determinada fase de la implantación es necesario adquirir un sistema informático que actúe como servidor de desarrollo para la implantación. Esta adquisición se debe realizar solicitando varios presupuestos para la toma en consideración posterior y seleccionar el más conveniente. Figura 86. Ejemplo de grupo de trabajo para la implantación Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 262 Para poder asignar dicha tarea Antonio accedería al proyecto y crearía la tarea denominada “búsqueda de proveedores” donde la responsable es María indicando una fecha límite de realización para completarla. El estado inicial de la tarea es inactivo, simbolizando que María aún no ha empezado a trabajar en la misma. Esta situación se representa en la figura 87. Cuando se asigna la tarea a María, ésta recibe un correo electrónico automático alertándola de que tiene una tarea nueva pendiente para el proyecto. María puede entrar en la herramienta y seleccionar la vista mediante la cual puede ver todas las tareas que están pendientes de su ejecución. Si María decide empezar a trabajar en esta tarea avanzaría en el flujo hacia el estado desarrollo, manteniendo la tarea en su bandeja de pendientes. Antonio recibiría automáticamente una notificación indicando que se ha empezado a trabajar en dicha tarea por lo que está permanentemente informado de la evolución de la misma. Una vez María ha terminado de trabajar con dicha tarea, la pasaría al estado realizado (ver figura 88). De esta forma, la tarea se mueve hacia la bandeja de Antonio para que pueda comprobar si la tarea se ha realizado correctamente o no. A continuación Antonio podría comprobar que María finalizó su trabajo. Si es correcto, Figura 87. Ejemplo de asignación de tareas Fuente: Elaboración propia Capítulo 5. Propuesta: metodología ágil, arquitectura y framework 263 Antonio podría pasar dicha tarea a histórico. En caso de no ser correcto, podría volver a remitírsela a María para su corrección (ver figura 89). Trabajar en este nivel de automatismo permite la minimización de reuniones y conversaciones entre los participantes que desvíen la atención de los objetivos propuestos y de igual forma, aumenta la transparencia entre todos los participantes dado que poseen acceso a toda la información vinculada a la evolución del proyecto. Figura 89. Ejemplo de archivado de tarea Fuente: Elaboración propia Figura 88. Ejemplo de tarea completada Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 264 Por otro lado, los usuarios disponen de un cuadro de mando que les permite conocer de manera gráfica el nivel de carga de trabajo que tienen en todo momento (ver figura 90). Adicionalmente la gestión de hitos permite a todos los participantes del proyecto conocer en todo momento los objetivos parciales que se deben conseguir y que están muy presentes en todos los avances que se ejecutan. En la figura 91 se representa la interfaz de introducción de hitos. Figura 90. Cuadro de mando para el control de las tareas pendientes de ejecutar por participante Fuente: Elaboración propia Capítulo 5. Propuesta: metodología ágil, arquitectura y framework 265 5.3.11 Gestión de riesgos Todo proyecto está sujeto a eventos aleatorios que pueden causar dificultades para lograr los objetivos planteados. Los principales riesgos a los que nos enfrentamos en un proyecto de workflow/BPM aunque pueden ser múltiples normalmente se vinculan a retrasos en la ejecución de algunas de las fases y que afectan al plazo acordado. Por otro lado, conviene recordar que uno de los objetivos de la implantación de un sistema workflow/BPM es la simplificación de los procesos actualmente en funcionamiento (es decir, afecta al cómo hacer actual en la organización). Este tipo de cambios tiene un coste en la organización que a veces es difícil de evaluar, dado que sólo cuando se esté inmerso dentro del proyecto de implantación se conocerá el alcance real de dicho cambio. Por lo tanto, dentro de la metodología es vital considerar la manera en la que se van a gestionar en tiempo real los riesgos asociados a la implantación, así como vincular estos riesgos a tareas concretas que se deben realizar para evitarlos o minimizar el impacto negativo que pudiesen tener. Gracias a la gestión del riesgo, la falta de certeza en algunos aspectos de la implantación se administra de forma disciplinada Figura 91. Interfaz para la gestión de hitos Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 272 procesos de negocio. En la metodología propuesta se han incorporado dichos pasos. • Contempla la gestión de proyectos. La metodología Scrum contiene mucho de los conceptos de la gestión de proyectos al igual que nuestra propuesta. • Contempla gestión de reuniones. Ambas metodologías contemplan la gestión de reuniones, si bien en Scrum las reuniones forman parte del eje troncal de la misma, mientras que en la metodología propuesta se intentan minimizar (eliminando las reuniones de sincronización diarias). La baja necesidad de reuniones se sustituye por una alta definición en la forma de ejecutar las tareas dentro de la metodología propuesta. • Contempla gestión de tareas e hitos. En la metodología propuesta la gestión de tareas es de vital importancia y su grado de concreción en la forma de trabajar por parte de los equipos participantes es alto indicando para cada tareas responsabilidades, flujo de trabajo a seguir y plazos. En la metodología Scrum, la gestión de tareas se resume en un listado obtenido a partir de las reuniones (Scrum meetings). • Contempla la gestión de costes por actividad. En la metodología Scrum no se contemplan la evaluación de costos por cada una de las tareas ejecutadas. Sin embargo, en la metodología propuesta se ha tenido en cuenta, ya que se entiende que es un elemento importante para predecir dificultades posteriores por falta de inversión. • Contempla la gestión de riesgos. Si bien en la metodología Scrum se nombra la necesidad de contemplar en los Scrum meetings las dificultades que aparecen en la evolución del proyecto, a nuestro juicio no se profundiza lo suficiente en la necesidad de identificar y gestionar los riesgos vinculándolos a tareas concretas, tal y como se hace en la metodología propuesta. Capítulo 5. Propuesta: metodología ágil, arquitectura y framework 273 • Contempla el prototipado de la solución a crear. La metodología Scrum está claramente enfocada a la creación de prototipos cada vez más refinados a medida que se realizan las iteraciones. La metodología propuesta también se basa en dicho concepto. • Curva de aprendizaje reducida para la utilización de la metodología. Tanto la metodología Scrum como la propuesta son fáciles y rápidas de aprender. Con una jornada de trabajo de pocas horas cualquier participante puede comprender cómo se utiliza. • Requiere el uso de herramientas electrónicas. La metodología Scrum se puede aplicar en equipos de trabajo utilizando sólo el papel y lápiz para la gestión completa del proyecto. En el caso de la metodología propuesta requiere el uso de herramientas electrónicas para aumentar la capacidad de comunicación y coordinación de los participantes del proyecto. • Preferencia por equipos de trabajo unidos presencialmente. La metodología Scrum tiene preferencia por equipos de trabajo unidos físicamente en el entorno dado el nivel de reuniones que exige (diarias). En el caso de la metodología propuesta este no es un requerimiento. Adicionalmente, podemos afirmar que, si bien muchas metodologías no llegan a la definición concreta en la forma que se deben utilizar estas herramientas, la metodología propuesta lo hace con un alto nivel de concreción y detalle. CAPÍTULO VI. MÉTODO DE INVESTIGACION Capítulo 6. Método de investigación 277 En los capítulos anteriores hemos revisado el concepto de sistema workflow/BPM, sus ventajas y sus inconvenientes. Adicionalmente hemos realizado una revisión de aquellas plataformas que existen en la actualidad y que pueden utilizarse para la creación de un software de estas características realizando una comparación entre las mismas. De igual forma, hemos revisado las metodologías de creación e implantación de un sistema workflow/BPM comparándolas entre ellas. Posteriormente, hemos aportado en este trabajo una nueva metodología basada en Scrum que, al ser utilizada junto a la arquitectura y framework que hemos creado, aporta ventajas para organizaciones de tamaño mediano/pequeño. En el presente capítulo presentamos el método de investigación en el que nos hemos basado y con los resultados más importantes. 6.1 Método de investigación El método que elegido para desarrollar y constrastar los resultados del presente trabajo es Action Research (Avison et al., 1999) el cual es ideal para el caso que nos ocupa de implantación de un sistema de información de tipo workflow/BPM. Varios autores como Baskerville (1999) o McKay y Marshall (2001) han indicado la idoneidad de utilizar este método de investigación para el caso de sistemas de información como el que nos ocupa. La base del método se fundamenta en probar la teoría planteada sobre situaciones reales que en nuestro caso corresponden a empresas públicas o privadas y administraciones públicas. Tener la capacidad de probar los resultados de la investigación en organizaciones reales nos aporta la capacidad de conocer si las hipótesis que formulamos son válidas. Aunque Action Research se ha utilizado inicialmente en entornos de ciencias médicas o sociales, a partir de los años 90 se ha incrementado notablemente su utilización en el ámbito de las TIC. Sistemas Workflow y BPM: metodología y casos de estudio 278 Este método de investigación proporciona resultados muy relevantes respecto a otro dado que está muy vinculado a la acción práctica en entornos reales. Según Hult y Lennung (1980), podemos definir Action Research como aquel método que asiste de forma simultánea a la resolución de problemas de manera práctica y expandir el conocimiento científico y las competencias de los participantes mediante la utilización de un proceso cíclico (o iterativo). Esta técnica se basa en iterar a través de cinco fases: • Diagnóstico. • Planificación de la acción. • Ejecución de la acción. • Evaluación de los resultados. • Conocimiento adquirido. En la figura 97 se representan las fases de las iteraciones de este método las cuales están englobadas en los requerimientos del cliente. Éstos definen las especificaciones y los acuerdos para poder constituir el entorno donde se va a realizar la investigación. Adicionalmente se establece las expectativas que se espera alcanzar y que supondrán el beneficio que desea obtener el cliente final. Capítulo 6. Método de investigación 279 La fase inicial se corresponde con un diagnóstico donde se identificarán los principales problemas que justifican la realización de un proyecto de implantación del sistema workflow/BPM. El diagnóstico se basa en una interpretación subjetiva donde se trata de tener una visión holística sin tratar de simplificar o reducir el problema. A partir del diagnóstico se desarrollan hipótesis de trabajo que abarquen la naturaleza de la organización y el alcance del problema. Figura 97. Fases del método Action Research Fuente: Baskerville (1997) Sistemas Workflow y BPM: metodología y casos de estudio 280 En la fase de planificación de la acción se establecen los pasos a abordar para poder resolver los problemas anteriormente descritos. Para ello, se deben definir el estado final que se quiere alcanzar y qué se debe realizar para alcanzar dicho estado. La tercera fase corresponde con la ejecución de la planificación realizada anteriormente. En esta fase se colabora activamente con la organización cliente realizando todos los cambios necesarios para alcanzar el nuevo estado. La manera de intervenir puede tomar dos formas: directiva, donde el equipo de investigadores indican al resto de la organización los cambios a realizar o no directiva, donde se instruye de forma indirecta para que se realizan los cambios precisos. Una vez se han completado las acciones definidas se debe evaluar los resultados obtenidos. Esta evaluación va encaminada a comprobar si los efectos estudiados en el marco teórico se han conseguido o no. En función de los datos obtenidos es posible que sea necesaria otra iteración del ciclo reformulando, si es necesario, las hipótesis lanzadas. La última fase corresponde a revisar el conocimiento adquirido de las fases anteriores. Veamos a continuación los pasos seguidos según este método de investigación para los casos de estudio que se plantean en este trabajo. 6.1.1 Fase de diagnóstico Dentro de la fase de diagnóstico hemos obtenido información en base a nuestra propia experiencia donde, a lo largo de varios años, ya que hemos tenido la oportunidad de participar en la implementación de múltiples sistemas de información. Esta experiencia ha ayudado a reconocer los problemas de una manera más eficaz. Capítulo 6. Método de investigación 281 El diagnóstico de la implantación del sistema workflow/BPM difiere entre una organización pública o una privada dado que la problemática a la que se enfrentan estas organizaciones diariamente es distinta en ambos casos. En las organizaciones privadas se persigue en todo momento maximizar los beneficios, lo que induce a buscar una mayor productividad entre todos los actores (empleados, clientes y proveedores). Por lo tanto sus esfuerzos tratan de alcanzar entre otros objetivos el aumento en la velocidad de ejecución de las acciones y la disminución en los errores que provoquen repeticiones en los procesos. Por otro lado la mecánica que guía el funcionamiento de una administración pública es diferente. Estas organizaciones buscan en un sistema workflow/BPM la garantía de funcionamiento de los procedimientos administrativos siguiendo en todo momento los pasos definitivos por la diversa normativa (leyes, reglamentos, etc.). En este caso, no se presta tanta atención a la interacción con otras administraciones públicas. 6.1.2 Fase de planificación de la acción Una vez realizado el diagnóstico de la organización donde se va a implantar el sistema, se aborda la planificación de la creación del sistema y su posterior puesta en marcha. Esta fase se ha correspondido con la confección de un proyecto aprobado por el cliente donde se establecen los pasos a seguir para la introducción de la nueva metodología y su uso para la creación del nuevo sistema. Por los tanto, estas acciones están consensuadas con cada una de las organizaciones donde se ha implantado el sistema. Toda la planificación de la acción se estructuró en una herramienta de gestión de proyectos donde, tanto el equipo desarrollador como equipo del cliente, colaboran en Sistemas Workflow y BPM: metodología y casos de estudio 288 insular actualidad Administración pública 18 Administración insular 19/12/2011 Continua en la actualidad Administración pública 19 Administración local 05/11/2013 Continua en la actualidad Empresa pública 1 Empresa pública nacional 01/09/2015 Continua en la actualidad Empresa pública 2 Empresa pública autonómica 01/007/2014 Continua en la actualidad Empresa pública 3 Empresa pública autonómica 22/06/2010 Continua en la actualidad Empresa pública 4 Empresa pública insular 05/09/2015 Continua en la actualidad Empresa pública 5 Empresa pública local 16/09/2015 Continua en la actualidad Empresa pública 6 Empresa pública autonómica 01/04/2012 Continua en la actualidad Empresa pública 7 Empresa pública insular 13/03/2012 Continua en la actualidad Empresa pública 8 Empresa pública local 01/05/2012 Continua en la actualidad A partir de las implantaciones realizadas, seleccionamos un caso de cada uno de los tipos de sistema más implantados (los más representativos), de forma que podamos describir los resultados obtenidos en los mismos. Adicionalmente dentro de los casos seleccionados se contemplan implantaciones en organizaciones diferentes. Los casos analizados son los siguientes: • Caso de estudio 1. Creación de un CRM en una empresa multinacional española dedicada fundamentalmente a la fabricación de elementos de construcción para obras de ingeniería. Esta empresa está especializada en determinados productos concretos para lo cual es la primera fábrica a nivel Capítulo 6. Método de investigación 289 europeo, poseyendo una planta de producción propia. El proyecto de implantación comenzó en junio de 2014 y finalizó en mayo de 2015. • Caso de estudio 2. Creación de un gestor de expedientes en una administración pública local situada en el sureste de la isla de Gran Canaria con el objeto de automatizar un departamento de urbanismo. El proyecto de implantación comenzó en enero de 2012 y finalizó en diciembre de 2012. • Caso de estudio 3. Creación de un ERP en una empresa de servicios. Desde sus inicios la empresa ha efectuado acciones tendentes a satisfacer los requisitos de calidad de sus clientes, si bien el aumento de los recursos ha permitido intensificar estas acciones en los últimos tiempos. El proyecto de implantación comenzó en marzo de 2014 y finalizó en marzo de 2015. • Caso de estudio 4. Creación de una herramienta de gestión de proyectos en una empresa pública de carácter público y autonómico en nuestro país dedicado al diseño industrial. El proyecto de implantación comenzó en abril de 2012 y finalizó en marzo de 2015. CAPÍTULO VII. CASOS DE ESTUDIO EN ORGANIZACIONES PÚBLICAS Y PRIVADAS Capítulo 7. Casos de estudio 293 En el presente capítulo describiremos los casos prácticos donde se ha puesto en marcha la metodología para la implantación propuesta en el presente trabajo en conjunción con la arquitectura y framework expuestos en el Capítulo 5 para construir el sistema workflow/BPM requerido por la organización. Exponemos los resultados más importantes obtenidos en dichos casos seleccionando un workflow determinado para cada caso donde haya una mayor implicación de diferentes departamentos. Para lograr una mayor amplitud en la exposición de los casos prácticos donde se ha implantado, se han seleccionados tanto empresas privadas como administraciones públicas. Tal y como se comentó en el capítulo anterior, con el objetivo de ver la utilidad de la metodología en distintos escenarios, se han seleccionado casos que abarcan diferentes sistemas de información. En concreto: • Creación de un CRM (Customer Relationship Management) (Kumar, 2010; Berry y Linoff, 2004; Payne y Frow, 2006; Kracklauer et al. 2004; Hollensen, 2015).en una empresa privada. • Creación de un gestor de expedientes electrónico en una administración pública. • Creación de un sistema ERP (Enterprise Resource Planning) (Chen, 2001) en una empresa privada. • Creación de una herramienta de gestión de proyectos en una empresa pública. 7.1 Caso de estudio 1: Creación de un CRM La empresa bajo estudio es una multinacional española con sede en Barcelona dedicada fundamentalmente a la fabricación de elementos de construcción para Sistemas Workflow y BPM: metodología y casos de estudio 294 obras de ingeniería. Esta empresa está especializada en una serie productos concretos para los cuales es la primera fábrica a nivel europeo, poseyendo una planta de producción propia. Esto permite a la empresa generar sus propios materiales, tener un control total de la calidad de éstos, así como investigar y desarrollar constantemente nuevas composiciones de productos enfocados a la mejora y evolución constante de los mismos. Los puntos fuertes de la empresa son la fabricación de materiales basados en especificaciones técnicas modernas, (siguiendo estándares internacionales) que le permite suministrar a una red de distribuidores por todo el planeta llegando a exportar a más de 40 países; poseer un amplio catálogo que aporta variedad al producto; y contar con una superficie cercana a los 15.000 metros cuadrados para distintos almacenes. Desde siempre, la empresa ha estado enfocada en la especialización de la producción de forma que se ha invertido en maquinaria y tecnología de fabricación semiautomática. Ello le permite alcanzar unos niveles de productividad y control de calidad adecuados a las normativas europeas. Desde un punto de vista histórico, se marcan los siguientes hitos en la vida de la empresa: • 1995: Se crea la empresa por un grupo de accionistas con larga experiencia en el campo de la manguera y el tubo flexible. • 2001: Se establece como empresa distribuidora en Francia. • 2004: Se da un paso más hacia la internacionalización, implantando la planta de producción en la República Checa. Se amplía así la capacidad productiva y se establece un punto estratégico de suministro para la zona centro de Europa y países del Este. • 2005: Se establece como empresa distribuidora en Alemania. Capítulo 7. Casos de estudio 295 • 2009: Se amplían instalaciones de la central de España destinadas a aumentar la capacidad de almacenamiento. • 2011: Construcción de las nuevas instalaciones del grupo en Francia. • 2012: La empresa se establece también en Portugal como empresa distribuidora. Adicionalmente, la empresa cuenta con un gran equipo humano con altos conocimientos técnicos en cada uno de los departamentos. 7.1.1 Necesidades reales En el momento del inicio del proyecto, en junio de 2014, la empresa necesitaba una solución software que solventara dos problemas fundamentales: • La gestión relativa a todas las incidencias producidas en sus almacenes desde el punto de vista de la distribución del material. Esta problemática afectaba a los departamentos de logística, calidad, comercial, exportaciones, etc. • Disponer de una herramienta CRM que ayudase a la gestión comercial con los clientes y representantes de sus productos en cada una de las zonas de trabajo (nacionales e internacionales). Esta herramienta debería proporcionar módulos para: o Gestionar los clientes tanto potenciales como reales. o Tener un cuadro global (gráfico) orientado a los comerciales mediante el cual se visualice el volumen de ventas comparativo con el ejercicio anterior marcando, en todo momento, el objetivo trazado para el presente ejercicio. Sistemas Workflow y BPM: metodología y casos de estudio 296 o Gestionar las direcciones de cada uno de los clientes. o Gestionar la cartera, descuentos, ofertas y documentación relativa a las relaciones con los clientes. o Tener la posibilidad de crear boletines electrónicos que permitieran la creación de una estrategia de marketing electrónica directo y personalizado a cada uno de los clientes. o Tener una agenda comercial completa, separada por cada uno de los comerciales que permita establecer una hoja bien definida de las acciones que se realizan con los clientes. A partir de dichas acciones, poder tener un sistema de gestión de tareas y alertas para cada empleado de la empresa. Las necesidades requeridas por la empresa se corresponden en un alto porcentaje con las funcionalidades de un sistema CRM. Veamos a continuación en qué consiste este tipo de sistemas. 7.1.2 ¿Qué es un CRM? Toda organización moderna necesita gestionar y explotar su base de clientes así como las tareas que los departamentos comerciales realizan con los mismos. Esta base de datos debe estar actualizada y vincular a la misma los productos y servicios ofrecidos, contactos, presupuestos, oportunidades, incidencias y en definitiva cualquier tipo de acción comercial realizada.. Los sistemas CRM (Customer Relationship Management) permiten de forma colaborativa lograr lo siguiente: • Alcanzar una visión de 360 grados sobre las relaciones con los clientes. Capítulo 7. Casos de estudio 297 • Automatizar los procesos de negocio más comunes en las relaciones con los clientes reduciendo tareas manuales (eliminar agendas en papel e individuales). • Ofrecer a los clientes una información más consistente y profesional. • Proporcionar a la dirección informes en tiempo real de forma que puedan tomar decisiones estratégicas para mejorar la organización. Estos informes deben orientarse a contestar preguntas tales como: ¿cuántas veces le hemos visitado? ¿cuántas y qué gestiones le hemos realizado?, etc. • Permitir trabajar colaborativamente con los compañeros, buscando la máxima productividad. • Gestionar los clientes potenciales (leads) y convertirlos en oportunidades de negocio. • Transformar oportunidades de negocio en proyectos y servicios reales con los clientes. • Organizar toda la documentación relativa a los clientes: contratos, presupuestos, facturas, etc. • Trabajar orientado a tareas. Disponer una hoja de ruta para los comerciales. • Crear campañas de marketing. Controlar en todo momento los contactos establecidos con los clientes. La relación entre las aplicaciones CRM y los sistemas workflow/BPM es notable dado que todas las actividades realizadas por el departamento comercial pueden describirse mediante procesos de negocio con el objetivo de automatizarlos (Davis, 2002). Por ejemplo, podría existir un proceso para la generación de presupuestos (con su flujo definido) que incluyese desde la elaboración del mismo hasta la Sistemas Workflow y BPM: metodología y casos de estudio 304 El proceso de negocio se desglosa en: • Identificación de los participantes. Los perfiles de participantes implicados en participar en el proceso de gestión de incidencias son: perfil comercial, logística, almacén y calidad. • Identificación de los estados. Se definen seis estados en el workflow: a) apertura_incidencia, simbolizando que se ha iniciado un nuevo caso; b) pendiente_recogida, representando que la mercancía que ha generado la incidencia aún está pendiente de ser recogida para analizar las causas; c) pendiente_aceptacion, significando que la incidencia aún está pendiente de ser aceptada por la empresa; d) pendiente_revision que simboliza que la mercancía está pendiente de ser revisada con el objeto de comprobar si la Figura 102. Flujo del proceso de negocio: gestión de incidencias Fuente: Elaboración propia Capítulo 7. Casos de estudio 305 incidencia se puede solventar o no; e) pendiente_cierre donde la incidencia requiere la introducción de una información final; y, por último: e) incidencia_cerrada simbolizando que el caso se archiva. • Identificación de las transiciones o cambios de estado. Todas las transiciones permitidas se definen en el diagrama de la figura 102. El movimiento principal de todos los casos sigue la secuencia apertura, recogida, aceptación, revisión, cierre y cerrada, pudiendo existir bifurcaciones hacia atrás en el flujo. • Identificación de los formularios. Los formularios implicados son: creación de incidencias, incorporación de gamas de productos implicados en la incidencia, formulario de logística, formulario de almacén, formulario de calidad, formulario de abono al cliente y por último formulario para la incorporación de documentos adjuntos a la incidencia. • Identificación de los modelos de impresos o documentos de salida. Se identifican dos documentos de salida: a) un modelo de salida en formato pdf que resume todo lo acontecido con una incidencia concreta y b) un fichero en formato Excel que incluya todos los campos de información a partir de la rejilla de las incidencias. Los formularios diseñados van apareciendo a las personas implicadas en cada incidencia para que puedan ir incorporando la información necesaria para continuar con su trámite. En la figura 103 se representa el proceso de creación de una incidencia nueva, que se describe a continuación. En primer lugar, se debe acceder al botón de creación seleccionando como campos más importantes los siguientes: • La fecha de comunicación por parte del cliente. Sistemas Workflow y BPM: metodología y casos de estudio 306 • A continuación se debe buscar dentro de la base de datos cuál es el nombre del cliente que abierto la incidencia y vincularlo. • Se debe indicar el tipo de incidencia dentro del grupo de exportación o nacional. • A continuación se puede describir el motivo por el cual se ha abierto la incidencia, se puede categorizar entre grave o normal y se puede indicar si corresponde a una devolución de material. Una vez abierta la incidencia debe procederse a incluir la gama de productos que están implicados. El administrativo debe seleccionar los productos de la base de datos importada desde el ERP hacia el CRM. Adicionalmente, se debe incluir la cantidad de cada uno de los productos que se han visto afectados en el problema tal y como se indica en la figura 104. Figura 103. Inicio del workfow. Creación de una incidencia Fuente: Elaboración propia Capítulo 7. Casos de estudio 307 El siguiente paso, avanzando dentro del flujo de trabajo, corresponde al departamento de logística el cual debe proceder a la recogida del material. Se debe incluir campos de información tales como: gasto de transporte, fecha de la orden de recogida, tipo de recogida (si se ha utilizado una agencia de transporte, si se han utilizado los propios medios del cliente, si se ha utilizado un servicio de paquetería, etc.). En el caso de que se haya utilizado una agencia debe indicarse el nombre de la misma de igual forma se deben indicar el número de bultos y un motivo (extravío o rotura). En la figura 105 se puede visualizar la pantalla del departamento de logística para poder gestionar una incidencia. El siguiente paso en el flujo corresponde a la persona perteneciente al almacén que debe recibir la mercancía con los problemas remitidos por el cliente. Esta mercancía debe entrar en el almacén e incluir la siguiente información: fecha de entrada, producto y cantidad, ubicación en el almacén y marcar si el producto afecta o no al stock (en función del estado de la mercancía). La figura 106 muestra en formulario en este paso del workflow. Figura 104. Incorporación de los productos implicados Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 308 A continuación el departamento de calidad debe cumplimentar también dentro del flujo de trabajo el destino, observaciones y causas relativas a la cual se ha producido dicha incidencia. Este mismo listado de incidencias forma parte de las no conformidades dentro del sistema de gestión de calidad que posee la organización. Se debe indicar también el o los responsables de dicha incidencia así como los gastos de material y los metros imputables por la incidencia que debe asumir la organización. En la figura 107 podemos visualizar la interfaz del departamento de calidad respecto a las incidencias. Figura 105. Información a cumplimentar por el departamento de logística Fuente: Elaboración propia Capítulo 7. Casos de estudio 309 Figura 107. Análisis de causas por el departamento de calidad Fuente: Elaboración propia Figura 106. Recepción de la mercancía en el almacén Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 310 Como información complementaria a cada una de las incidencias, el administrativo puede adjuntar documentación a la misma en cualquier tipo de formato de fichero (documento Word, documentos PDF, imágenes o fotografías de los desperfectos incluidos, etc.). En todo momento, como se ha recogido en el flujo de trabajo el personal de administración puede mover los estados de cada una de las incidencias hacia atrás hacia pendiente de recogida o pendiente de revisión, tal y como se diagramó en el flujo para aquellos casos donde la mercancía no entra completa (viene en varios envíos). 7.1.5.4 Fase de implantación Una vez finalizadas todas las fases anteriores se unieron todas las piezas y se construyó el software completo. Adicionalmente se programaron funcionalidades específicas requeridas por la empresa y que eran muy necesarias para la labor diaria del departamento comercial. En la figura 109 podemos visualizar la interfaz a la que accede un usuario una vez se haya validado. Figura 108. Abono o reposición de la mercancía y final del workflow Fuente: Elaboración propia Capítulo 7. Casos de estudio 311 En la zona izquierda de la pantalla se encuentra el menú de opciones principales mientras que en la zona central existe un conjunto de gráficas y datos resumen de informes que aportan valor al perfil del usuario que se está conectando. Dentro de Las opciones encontramos accesos a: • Cuadro global. Acceso a los informes más importantes de usuario en formato de gráficas y tablas de datos numéricos. • Mi perfil. Acceso a la información propia del usuario incluyendo la posibilidad de cambiarse la contraseña. • Clientes. Acceso al listado de clientes tanto potenciales como reales que se encuentran dentro de la organización. Figura 109. Interfaz principal de acceso al sistema Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 312 • Crear visita. Acceso directo a la posibilidad de programar una visita con un determinado cliente. • Representante. Acceso al listado de empresas que representan los productos en las distintas zonas de trabajo o influencia. • Incidencias. Gestión de todas aquellas incidencias que se producen dentro del departamento de logística al crear, almacenar y distribuir mercancías hacia los clientes. Esta será la opción donde profundizaremos para analizar el flujo de trabajo que se diseñó en este caso práctico concreto. • Agenda comercial. Calendario colaborativo entre todos los miembros de la organización mediante la cual se pueden visualizar todas aquellas visitas programadas con los clientes así como aquellos eventos importantes para toda la empresa. • Tareas. Posibilidad de crear o ejecutar aquellas tareas que se van asignando los usuarios entre ellos o tareas automáticas que va creando el propio sistema. • Reuniones. Posibilidad de programar reuniones dentro de la propia organización incluyendo un sistema de invitación a participar, envío del orden del día y envío de las actas finales de la reunión. • Mailing. Generación de listas de distribución mediante la segmentación de los distintos clientes que existen dentro de la empresa. Desde esta opción vamos a tener la posibilidad de enviar boletines electrónicos a un determinado grupo de clientes. • Informes. Listado de todos aquellos informes que te proporciona el CRM. • Ofertas. Posibilidad de confeccionar ofertas específicas sobre uno o varios productos para determinados clientes. Capítulo 7. Casos de estudio 313 • Notificaciones. Dentro del sistema se pueden enviar mensajes interno a otros usuarios. Estos mensajes se consideran notificaciones ya que existe el control para poder conocer si un mensaje ha sido leído o no. • Noticias. Dentro del CRM existe un completo gestor de contenidos de forma que los administradores de la empresa pueden publicar información de interés hacia los usuarios del sistema. Esta opción permite que el CRM se convierta adicionalmente en una intranet. • Documentación. Dentro del CRM se incorpora un gestor documental de forma que se pueden subir todos aquellos documentos importantes para la organización. • Configuración. Acceso a todas las tablas maestras del sistema. De esta forma se puede personalizar el uso del programa a la organización concreta. El sistema construido también incluye una agenda comercial donde se registran todas y cada una de las visitas que se realizan con los clientes. Adicionalmente se incluyó una gestión de tareas individuales para cada uno de los usuarios. Las tareas se crean manualmente desde un usuario creador hacia un usuario responsable de ejecutarla. Todas las tareas se encuentran en estado: pendiente de ejecutar y tarea cerrada. Las tareas se notifican a cada uno de los usuarios bien por el sistema de notificación interna o bien por correo electrónico, pudiendo acceder cada uno de los usuarios desde su teléfono móvil. El sistema creado permite gestionar todas y cada una de las reuniones que se realizan dentro de la organización. Se puede realizar la convocatoria de la reunión incluyendo un asunto, un tipo de la reunión (reunión presencial, telefónica, videoconferencia, o webconference), fecha y hora de celebración, y lugar. Además, y como información importante para la convocatoria, el usuario debe incluir el orden del día de la reunión. También puede incluirse una estimación de la duración de la reunión y un listado de participantes internos o externos a los cuales va a llegar una invitación vía correo electrónico. La persona que convoca la reunión estará Sistemas Workflow y BPM: metodología y casos de estudio 320 • No disponía de elementos para asignar trámites o expedientes a empleados concretos. Todos los usuarios accedían de forma compartida a la aplicación sin ningún control respecto a los cambios que podían hacer dentro de los expedientes. • Los trámites no se hacían a través de plantillas por lo que cada informe, decreto, notificación o licencia final podrían tener diferencias respecto a su estructura (no al contenido). • No guardaba los documentos generados en cada uno de los trámites. Por lo tanto, los usuarios debían guardar la información generada en una estructura de archivos separada de la aplicación. • No permitía evolucionar sin tener conocimientos de programación. Cuando existía una modificación legislativa, el comportamiento del programa debía alterarse pero no existían herramientas para hacerlo que no fuese mediante cambios en la programación. Por lo tanto, la administración decidió dar el cambio e introducir un sistema workflow/BPM que se comportase como un gestor de expedientes. Dicho paso se inició realizando la contratación de un sistema de una reconocida firma tecnológica multinacional. No obstante, durante el proceso de implantación se percibió como un gran hándicap las pocas capacidades de personalización del software a la casuística presente en el departamento del la administración local. Este hándicap fue el motivante principal para no lograr el éxito en el proyecto. A continuación iniciaron un nuevo proyecto de implantación del sistema workflow/BPM a partir de la arquitectura, metodología y framework propuestos en el presente trabajo. Este sistema es el que ha perdurado hasta la actualidad. Capítulo 7. Casos de estudio 321 7.2.4 Entorno actual de sistemas en la administración local La administración pública objeto de este caso de estudio posee una infraestructura centralizada de servidores en un centro de proceso de datos (CPD) incluido en el edificio principal. El resto de edificios se conectan al CPD vía fibra óptica y sólo en pocos casos, se realiza a través de conexiones ADSL. En el CPD se sitúa el servidor principal siendo un servidor físico. También cuentan con servidores en la nube virtualizados. Los servidores físicos se comunican con los correspondientes en la nube configurando así un entorno de red híbrido donde los usuarios final desconocen (no necesitan saber) a ubicación real de los sistemas. Todos aquellos departamentos implicados en participar en los flujos definidos acceden vía local de forma que tengan una mayor velocidad de respuesta desde el sistema central. En la figura 110 se muestra el diagrama de conexiones existente. Sistemas Workflow y BPM: metodología y casos de estudio 322 7.2.5 Desarrollo de la metodología y resultados obtenidos. A continuación realizamos una revisión de las actividades seguidas en cada una de las fases de la metodología y el resultado obtenido. 7.2.5.1 Fase de análisis El punto de partida inicial contenía deficiencias desde un punto de vista de infraestructuras tecnológicas y organizativas que aconsejaban la realización de un análisis más extenso (no sólo vinculado al propio sistema workflow/BPM a Figura 110. Topología de sistemas en la administración Fuente: Elaboración propia Capítulo 7. Casos de estudio 323 implantar). Por este motivo se enviaron cuestionarios a tres perfiles de usuarios: empleados concejales, altos cargos y jefes de servicio y por último hacia el departamento de informática. Adicionalmente se obtuvo información relativa a la estructura de la organización y el entorno operacional informático, incluyendo información relativa la arquitectura de los sistemas hardware, los servicios básicos de red, el registro de activos e inventario, etc. Adicionalmente, se mantuvieron reuniones de trabajo con el departamento más vinculado al sistema actual para obtener el listado de requerimientos para el proyecto. Desde un punto de vista de la migración se estableció la necesidad de importar todos los expedientes existentes en los sistemas anteriores, los cuales almacenaban la información en distintos formatos de bases de datos (desde Access hasta Microsoft SQL Server). La migración fue un apartado crítico dado que se debía garantizar que el nuevo sistema contenía de forma íntegra todos los expedientes obrantes en el departamento. Al igual que el caso de estudio anterior, todos los documentos de análisis (incluidos los formularios de toma de datos) se estandarizaron en formato. Para cada uno de los módulos desarrollados en la aplicación se obtuvo: a) nombre de la rejilla de datos y formularios vinculados a la misma ; b) campos de información de cada rejilla y sus formularios; c) buscadores permitidos en la rejilla; d) procesos a ejecutar vinculados a la misma; e) información de cabecera o pie de la rejilla; y f) acciones a realizar con cada uno de los registros de información de la rejilla. Por ejemplo, para la rejilla principal de expedientes de actividades clasificadas se decidió incluir los siguientes datos: • Nombre de la rejilla: index_tareas_new y formulario para la creación, modificación y borrado. Sistemas Workflow y BPM: metodología y casos de estudio 324 • Campos de información en la rejilla: Número del expediente, funcionario creador del mismo, siguiente técnico en realizar algún trámite en el expediente, estado del expediente, observaciones y fecha de la licencia otorgada. • Búsquedas permitidas en la rejilla: Por cualquier campo obrante en el expediente de tipo texto y por estado del expediente. • Procesos vinculados a la rejilla: No se aplican en esta rejilla. • Información de cabecera y pie: No se aplica en esta rejilla. • Acciones a realizar con los rejistros de la rejilla: Acceso al control de documentos aportados por el ciudadano titular de la industria, acceso al gestor documental de los ficheros incluidos en el expediente, acceso al histórico de los titulares, acceso a todos los trámites realizados en el expediente, acceso a los datos técnicos y por último modificar o borrar. A continuación se procedió a la fase de diseño rápido de la aplicación mediante la creación de los mockups. 7.2.5.2 Fase de diseño rápido (mockups) En la figura 111 se representa el ejemplo de mockup generado para la rejilla de los expedientes de actividades clasificadas. En la misma se sitúan en el boceto la posición de todos los elementos de interfaz. Tal y como se concluyó en la fase de análisis se incluyeron las columnas de datos vinculadas a cada uno de los expedientes. Capítulo 7. Casos de estudio 325 Los prototipos se modificaron sucesivas veces hasta definir los definitivos 7.2.5.3 Fase de creación de workflows En la fase de diseño de los procesos se diagramaron aquellos correspondientes a los procedimientos administrativos que se implantaron en la herramienta: actividades clasificadas, obras mayores, obras menores, actividades inocuas, etc. En la figura 112 se representa el diagrama para el proceso de gestión de actividades clasificadas. Figura 111. Ejemplo de mockup para la rejilla de expedientes Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 326 El proceso de negocio se desglosa en: • Identificación de los participantes. Los perfiles de participantes implicados en participar en el proceso son: perfil administrativo (incluyendo auxiliares administrativos y jefe de sección del departamento), ingenieros del departamento, técnicos del departamento jurídico y por último técnicos del departamento de intervención. • Identificación de los estados. Se definen cinco estados en el workflow: a) iniciado, simbolizando que se ha iniciado un nuevo expediente; b) pendiente_informar, representando que el expediente ha sido enviado hacia algún otro departamento (técnico, jurídico o intervención) para generar un informe al respecto; c) pendiente_interesado, significando que el expediente ha sido notificado hacia el ciudadano o titular y se está a la espera de que aporte más información; d) informado, que simboliza el hecho de que el expediente ha sido informado por la persona a la cual se envió. Este estado Figura 112. Flujo del proceso de negocio: gestión de actividades clasificadas Fuente: Elaboración propia Capítulo 7. Casos de estudio 327 puede repetirse tantas veces como informes sean necesarios en el expediente y por último ; e) archivado simbolizando que el expediente se ha terminado. • Identificación de las transiciones o cambios de estado. Todas las transiciones permitidas se definen en el diagrama de la figura 112. Existen bucles que pueden repetirse tanto en la solicitud de datos adicionales al interesado como en la solicitud de informes a los distintos departamentos. • Identificación de los formularios. Los formularios implicados son: creación del expediente, formulario de indicación de documentos aportados, formulario para la incorporación de titulares, formulario para la creación de trámites y realización de los mismos y formulario para la incorporación de datos técnicos al expediente. • Identificación de los modelos de impresos o documentos de salida. Esta fase fue la más compleja en el desarrollo del proyecto debido a variedad diferente de trámites que se pueden realizan con expediente. Se identificaron 112 tipos distintos de trámites y plantillas asociadas. Los tipos de trámite se englobaron en los siguientes grupos: a) caducidad del expediente; b) cambios de titularidad; c) cesión de derechos; d) citaciones; e) comunicaciones; f) decretos; g) diligencias; h) informes de ingeniería, jurídicos y económicos; i) notificaciones; j) oficios a la administración insular; k) publicaciones y requerimientos. Los formularios diseñados van apareciendo a las personas implicadas en cada expediente para que puedan ir incorporando la información necesaria para continuar con su trámite. En la figura 113 se representa el proceso de creación de expediente nuevo donde los campos más importantes son: • Número del expediente, que se crea automáticamente dentro del sistema. Sistemas Workflow y BPM: metodología y casos de estudio 328 • Datos relativos al registro de entrada a partir del cual el ciudadano ha realizado la petición. • Tipo de actividad que se va a realizar y datos de ubicación de la misma. • Dentro del mismo formulario se irán incorporando datos relativos a la evolución del expediente. Por ejemplo, número de licencia, decreto de licencias de funcionamiento y apertura, información relativa a alegaciones, etc. Una vez creado el expediente se debe vincular a un titular nuevo o ya existente. Para ello se aporta los datos de identificación y contacto del mismo diferenciando el caso donde el titular sea una persona jurídica tal y como se indica en la figura 114. Figura 113. Inicio del workfow. Creación de un expediente de actividades clasificadas Fuente: Elaboración propia Capítulo 7. Casos de estudio 329 El usuario administrativo debe incorporar y marcar los documentos aportados por el ciudadano al expediente. En la figura 115 se puede visualizar dicho formulario. El siguiente paso dependerá de los datos obrantes en el expediente iniciado. Puede darse el caso que la información aportada sea insuficiente o errónea. Este caso se realizaría un trámite de petición de información y una notificación al ciudadano. Sin embargo podría suceder que la documentación está completa por lo que se procedería a realizar un trámite de diligencia para informar al departamento técnico que debe revisar el proyecto aportado. En la figura 116 se representa el formulario de creación trámites. Figura 115. Formulario de documentos aportados al expediente Fuente: Elaboración propia Figura 114. Incorporación de los titulares al expediente Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 336 una primera y única vez; la prevención de errores es prioritaria frente a la corrección. El trabajo sin calidad sólo provoca el aumento de los costes; c) Desarrollar un proceso permanente de mejora de los servicios prestados y d) Innovar y adecuar de forma permanente los métodos de actuación. 7.3.1 Necesidades reales La empresa requería un sistema informático que permitiese trabajar de forma colaborativa a todos los empleados de la organización siguiendo flujos de trabajo definidos e independientemente de su ubicación. De hecho, la mayoría de los empleados del departamento comercial y técnico debían acceder al sistema desde sus tablets o teléfono móviles. Adicionalmente centralizar todos los datos en una única base de datos relacional eliminando bases de datos distribuidas que cada departamento necesitaba crear por funciones específicas que realizaban. Otro objetivo era poder disponer de un sistema modular que creciese a medida que crece la organización y, en la medida de lo posible, poder alternar el comportamiento del programa sin tener que cambiar la programación interna del mismo. Por último, tener la posibilidad de integrar el sistema con los procedimientos de calidad definidos en las normas ISO9001, ISO14001 y OSHAS 18001. 7.3.2 ¿Qué es un sistema ERP? Los sistemas ERP son aplicaciones software que permiten a la organización automatizar e integrar la mayor parte de sus procesos de trabajo o negocio, compartir datos no solo entre los distintos empleados sino también con los clientes y proveedores y producir y acceder a la información en tiempo real (Chen, 2001). Capítulo 7. Casos de estudio 337 Como objetivos de un sistemas ERP podemos citar los siguientes (Klaus et al., 2000) a) optimización de los procesos de negocio mediante una informatización de los mismos; b) acceso a la información confiable, precisa y oportuna basándose en el concepto del dato único donde el mismo aparece en aquellos sitios donde sea requerido sin necesidad de copiarlo en diferentes lugares; c) alto nivel de integración de datos con otros sistemas que existan en la misma organización o con los sistemas de sus clientes o proveedores; d) eliminación de datos y operaciones innecesarias dado que todas las funcionalidades necesarias para una empresa estarían contempladas dentro del ERP; e) reducción de tiempos y de costes de los procesos al poder automatizar múltiples tareas; y f) poseer una estructura modular, por lo que se favorece su desarrollo por etapas. Algunas características que deben tener los sistemas ERP son los siguientes: • Flexibilidad. El ERP debe poder adaptarse a las necesidades de la organización actuando sobre opciones de configuración que permitan alterar su comportamiento. • Modularidad. Software ERP dividido en módulos (componentes identificables y tratables por separado), con una funcionalidad específica e integrados. Los módulos deben proveer: a) La misma interfaz de usuario; b) El mismo acceso a los usuarios y c) La misma gestión del flujo de trabajo. Tener un software de gestión divido en módulos nos permite reducir la complejidad, facilitar los cambios y la implementación de desarrollo paralelo de otras partes del sistema. • Integración. Los módulos deben de estar integrados de manera que la información actualizada fluya automáticamente por todo el sistema, es decir, la información se introduce una sola vez en el sistema y el resto de módulos se actualiza automáticamente. • Seguridad. El ERP debe ser seguro desde los puntos de vista de privilegios de acceso al interfaz del usuario y privilegios de acceso a datos . Sistemas Workflow y BPM: metodología y casos de estudio 338 7.3.3 Trabajos previos realizados y experiencias anteriores Antes de comenzar con el nuevo proyecto de implantación de un ERP basado en workflow/BPM, la empresa ya contaba con un sistema informático que permitió el crecimiento de la organización, pero a un coste elevado. Las dificultades existentes en el anterior software se resumen en los siguientes puntos: • Utilización de una base de datos propietaria y no relacional. Este hecho imposibilitaba la explotación de los datos desde otras herramientas que no fuesen las originalmente diseñadas para el software. En la empresa se requería disponer de un cuadro de mando integral para definir objetivos y comprobar su cumplimiento, por lo que poder explotar la información del sistema era necesario. • Integración con los dispositivos móviles del personal técnico para cumplimentar los partes de trabajo. Se requería tener la posibilidad de que los técnicos rellenaran los partes de trabajo desde sus teléfonos móviles en las instalaciones del cliente. El sistema actual no proporcionaba dicha funcionalidad. • Posibilidad de innovar y crear en tiempo real. El sistema actual no permitía hacer modificaciones en el código y ponerlas en marcha sin necesidad de parar todo el sistema. Este problema provocaba unos tiempos altos de implantación de cualquier mejora en el sistema. • Necesidad de definir los flujos de trabajo de los departamentos comercial, atención al cliente, administración y técnico de una forma clara. En el sistema actual dichos procedimientos no estaban suficientemente claros. Estos problemas hicieron que la empresa plantease la creación de un software personalizado y basado en un motor de workflow/BPM. Capítulo 7. Casos de estudio 339 7.3.4 Entorno actual de sistemas en la empresa La empresa cuenta con un servidor situado en las instalaciones centrales de Gran Canaria al cual se conectan los usuarios externos incluidos los correspondientes a las islas de Fuerteventura y Lanzarote. En el interior de dicho servidor se encuentran dos máquinas virtualizadas separando las aplicaciones de contabilidad de la de gestión. En la figura 120 se representa la topología actual. Figura 120. Topología de la empresa Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 340 7.3.5 Desarrollo de la metodología y resultados obtenidos. A continuación realizamos una revisión de las actividades seguidas en cada una de las fases de la metodología y el resultado obtenido. 7.3.5.1 Fase de análisis En la empresa ya se habían realizado labores de análisis de sus procesos de negocio creando diagramas de flujo para una mayor comprensión. Los procesos más importantes se corresponden a: a) proceso de medida de satisfacción de los clientes; b) proceso de gestión comercial; c) proceso de atención al cliente telefónica; d) procesos técnicos relativos a las labores realizadas en cada una de las instalaciones de los clientes; e) procesos de facturación y gestión de cobros; f) proceso de gestión de compras y evaluación de los proveedores; g) proceso de formación; h) proceso de gestión de los medios de producción y por último i) proceso de gestión del almacén. A continuación vamos a concentrarnos en el proceso de gestión comercial por tener un carácter horizontal y ser el primero en ejecutarse cuando se contacta con un cliente. Durante la fase de análisis se detectó que dicho proceso afecta a las siguientes áreas de la empresa: • Dirección. Debe verificar que los presupuestos, contratos y renovaciones cumplen con los requisitos establecidos. • Director técnico. Se responsabiliza de verificar la capacidad técnica de la empresa para satisfacer los requerimientos de los clientes, así como de establecer la programación para el control de los servicios contratados. Sobretodo actúa cuando un presupuesto tiene un marcado carácter específico para el cliente. Capítulo 7. Casos de estudio 341 • Coordinación técnica. Se responsabiliza de realizar la programación en las dependencias contratadas del cliente. • Coordinación comercial. Se responsabiliza del seguimiento de la actividad comercial, y de la distribución de nuevos presupuestos o clientes potenciales. • Comerciales. Son los responsables de identificar las necesidades y requerimientos de los clientes y negociar las condiciones de los presupuestos y renovaciones. Además deben identificar en el vencimiento de los contratos las acciones a realizar mientras se negocia la renovación. Asimismo, deben informar a los clientes de las características y condiciones del servicio que se va a prestar. • Atención al cliente. Colabora en la realización de los presupuestos solicitados por teléfono, en el ámbito de su competencia. Durante esta fase analizaron los diagramas de flujo que la empresa había realizado y que si bien podrían ayudar a la compresión de los pasos a seguir, no eran suficientes. En la figura 121 se representa el proceso general de negocio en el cual podemos ver la secuencia de estados que sigue todo contrato realizado con un cliente: venta, negociación, no firmado, aceptado, gestión, administración y en vigor. Los pasos iniciales parte de una venta realizado por un comercial (o atención al cliente vía telefónica). En este caso, el comercial debe dar de alta el nuevo presupuesto en el sistema pasando al estado negociación. Este presupuesto puede ser aceptado o no por el cliente. En el caso de no aceptación pasaría a un estado de no firmado concluyendo el proceso. En el caso de aceptar por parte del cliente pasaría a un estado de aceptado (el presupuesto se convertiría así en un contrato). Dependiendo de las especificidades del contrato puede ser necesaria una verificación por parte de la dirección técnica o no. En el caso se compruebe que técnicamente existen problemas para ejecutar el contrato, se volvería al estado de negociación. Si todo es correcto el contrato estaría en el estado gestión donde el departamento de atención al cliente debe concertar con el cliente la primera visita Sistemas Workflow y BPM: metodología y casos de estudio 342 para prestar el servicio. Existe una particularidad donde el sistema no haya podido crear los recibos de manera automática, llevando el contrato al estado administración donde se deben crear de manera manual. El análisis de cómo realizaban hasta ahora el procedimiento ayudó en las siguientes fases a mejorar simplificando los pasos que se daban. De igual forma, en esta fase se definieron todas las rejillas y formularios necesarios para el nuevo sistema workfow/BPM. Por ejemplo, para la rejilla principal de servicios contratos se decidió incluir los siguientes datos: Figura 121. Proceso principal del negocio Fuente: Elaboración propia Capítulo 7. Casos de estudio 343 • Nombre de la rejilla: index_rejilla_contratos_locales_de_un_local_new y formulario para la creación, modificación y borrado. • Campos de información en la rejilla: Fecha de vencimiento del contrato, estado del contrato, nombre del local del cliente donde se van a prestar los servicios, dirección y municipio del local, codificación de los servicios que se prestarán, importe total del contrato e importe de costo para la empresa. • Búsquedas permitidas en la rejilla: Se debe permitir realizar búsquedas por el estado de contrato, por el importe, por el nombre del local, por el nombre de la empresa, por parte del número de teléfono, por el nombre de algún contacto vinculado al contrato y por intervalo de fechas. • Procesos vinculados a la rejilla: Vinculado a la rejilla se debe poder acceder al formulario del contrato donde se debe permitir: a) ver el certificado expedido al local una vez los servicios se hayan prestado; b) Poder remitir el certificado expedido por email; c) Poder visualizar los planos y fotos del local donde se han realizado los servicios: d) Acceder al gestor documental donde se almacenen todos los archivos vinculados al contrato y e) Tener la posibilidad de imprimir la planificación de los servicios en el local (cuántas veces y en qué fechas se acudirá para la revisión de los servicios prestados). • Información de cabecera y pie: En la cabecera de la rejilla se debe mostrar la empresa con la que estamos trabajando en este momento. Como información del pie de la rejilla se debe posibilitar la exportación a ficheros Excel, txt o imprimir el listado. • Acciones a realizar con los rejistros de la rejilla: Acceso a los datos administrativos y económicos del contrato. A continuación se procedió a la fase de diseño rápido de la aplicación mediante la creación de los mockups. Sistemas Workflow y BPM: metodología y casos de estudio 344 7.3.5.2 Fase de diseño rápido (mockups) En la figura 122 se representa el ejemplo de mockup generado para la rejilla de los servicios contratados. Los elementos detectados en la fase de análisis se ubicaron en el prototipo para una mejor comprensión por parte de los participantes del proyecto del sistema workflow/BPM a construir en las siguientes fases. Como es normal, los prototipos se modificaron sucesivas veces hasta obtener los definitivos 7.3.5.3 Fase de creación de workflows Dentro de la fase de creación de los diagramas de los flujos se realizó una labor de simplificación respecto a cómo se estaban realizando las tareas hasta el momento. Por ejemplo, se eliminó el estado de venta visto en la figura 121 dado que no Figura 122. Ejemplo de mockup para la rejilla de servicios contratados Fuente: Elaboración propia Capítulo 7. Casos de estudio 345 aportaba valor añadido y se prestó suficiente atención a los datos que cada participante debía aportar para no repetir pasos. En la figura 123 se representa el diagrama para el proceso de gestión comercial. El proceso de negocio se desglosa en: • Identificación de los participantes. Los perfiles de participantes implicados en participar en el proceso son: perfil comercial, perfil de dirección técnica y perfil de administración. • Identificación de los estados. Se definen cinco estados en el workflow: a) negociación, simbolizando que se ha iniciado un nuevo presupuesto y se están manteniendo las conversaciones necesarias con el cliente encaminadas a la aceptación o no del presupuesto; b) no firmado, representando que no se ha llegado a un acuerdo con el cliente y por tanto el presupuesto no se ha Figura 123. Flujo del proceso de negocio: gestión comercial Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 352 Uno de los apartados más interesantes implantado en este sistema de workflow/BPM es la posibilidad de tener participantes de los procesos que actúan en movilidad. En este caso, los técnicos encargados de realizar los partes de trabajo en las ubicaciones de los clientes pueden conectarse desde las mismas para actualizar en tiempo real los datos obtenidos en la prestación del servicio. Esta actualización permite a las oficinas centrales tener la posibilidad de planificar las siguientes acciones a realizar sin ningún retraso además de asegurar que los datos incorporados son accesibles de forma inmediata por los clientes a través de la extranet habilitada a tal efecto. En la figura 128 se representa el acceso en movilidad a un parte de trabajo por parte de un técnico. Figura 128. Actualización en el sistema workfow/BPM a través de smartphones Fuente: Elaboración propia Capítulo 7. Casos de estudio 353 7.3.5.5 Fase de puesta en marcha y mantenimiento Esta fase se impartieron acciones formativas presenciales a cada uno de los grupos de perfiles de usuario y se puso en marcha el sistema comenzando con el periodo de mantenimiento evolucionando el mismo. 7.3.6 Consideraciones finales al caso de estudio Al igual que en los casos anteriores, el principal motivo a destacar para el éxito del proyecto es la personalización completa donde el software implantado se adapta a las características de la empresa y no al revés. Adicionalmente permitió completar los objetivos planteados inicialmente en el proyecto. Las líneas de trabajo futura en la organización incluyen: • Crear una aplicación móvil que permita el almacén de los datos de los partes técnicos en el móvil cuando no existe ninguna cobertura. Algunos casos en los que los técnicos deben realizar el trabajo en sótanos o garajes donde no existe cobertura. En la actualidad los técnicos deben salir de la instalación y a continuación proceder a la actualización del parte. Por lo tanto el objetivo consistiría en que la aplicación almacenase los datos en local hasta que el teléfono encuentre cobertura y los transmita. • Incorporar la firma electrónica (o digital) de los clientes sobre el dispositivo y activar el envío automático por email del parte de trabajo realizado al cliente. En la actualidad, una vez el técnico sale de las instalaciones, el cliente ya tiene acceso a la información del trabajo realizado a través de la extranet. En algunos casos, el cliente solicita que se pueda firmar el parte por la persona encargada en el local, por lo que sería necesaria esta funcionalidad de firma. Sistemas Workflow y BPM: metodología y casos de estudio 354 7.4 Caso de estudio 4: Creación de una herramienta de gestión de proyectos en una empresa pública. El siguiente caso de estudio de implantación de la metodología, arquitectura y framework se corresponde a una empresa de carácter público y autonómico dedicado al diseño industrial. En esta empresa se requería la puesta en marcha de un sistema de gestión de proyectos con un marcado acento en la definición de los procesos de negocio que deben llevar a cabo los distintos participantes. La empresa cumple con los estándares de calidad y se encuentra certificada por Aenor en tanto la ISO9001 como la ISO14001 (medio ambiente). La estructura departamental se divide en administración, desarrollo de negocio, departamento económico, departamento técnico y colaboradores externos. 7.4.1 Necesidades reales La organización requería una solución que potenciara sus actividades tanto comerciales como técnicas, estructurándolas bajo el prisma de la gestión de proyectos. En concreto, se necesitaba: • Poder gestionar oportunidades de negocio con los clientes y convertirlas en proyectos reales. • Gestionar una agenda colaborativa entre todos los participantes de los proyectos. • Incorporar un workflow para las distintas fases que los proyectos deben ejecutar de manera que se normalicen las actividades realizadas en la empresa. Capítulo 7. Casos de estudio 355 • Incluir la planificación temporal y económica de los proyectos dentro del workflow. • Centralizar las solicitudes de gasto para cada uno de los proyectos en el sistema a través de un proceso de negocio que solicite las distintas aprobaciones de los cargos intermedios de la organización. 7.4.2 ¿Qué es una herramienta de gestión de proyectos? Una herramienta de gestión de proyectos busca en todo momento gestionar y controlar todas las actividades o tareas enfocadas a conseguir un objetivo (Kerzner, 2013) que, en el caso de la empresa bajo estudio, se traduzca en un buen servicio a los clientes. La herramienta de gestión de proyectos proporciona información concreta sobre: a) número de proyectos, presupuestos o tareas distintas se están realizando simultáneamente; b) información relativa a la planificación, inversión/coste, beneficio, incidentes, riesgos y en definitiva el estado actual de cada uno de estos proyectos; c) volumen de recursos que se están utilizando para realizar cada una de las tareas o servicios prestados; c) informes que nos ayudan a comprobar si los recursos se están optimizando en su uso o no; d) información para comprobar si los presupuestos que se están creando se aproximan a la realidad o por si el contrario los costes están superando a los beneficios; e) conocimiento exacto que quién dentro de la empresa es responsable de hacer cada una de las tareas y qué tiempo tienen asignado para completarlas; f) información de monitorización para comprobar si existen proyectos o tareas bloqueados dentro de la organización debido a una mala asignación y g) información orientada a la optimización de los tiempos de respuesta de las tareas dentro de la organización de forma que podamos conocer dónde hay pasos suprimibles o tareas repetitivas y redundantes. Sistemas Workflow y BPM: metodología y casos de estudio 356 7.4.3 Trabajos previos realizados y experiencias anteriores. La empresa ya contaba con un sistema de gestión antes del comienzo del desarrollo en el nuevo sistema. En concreto se trataba de una aplicación realizada a medida para la organización con funcionalidades que la aproximaban a un ERP. No obstante, como se ha comentado, la organización requería potenciar el trabajo dentro de la organización basándose en una cultura de gestión de proyectos siendo más próximo al funcionamiento interno real de los distintos departamentos. La herramienta adolecía de las siguientes dificultades: • Al ser un desarrollo personalizado (totalmente programado en código), era complejo de abordar modificaciones en su interior dado que dependía totalmente del programador que la desarrolló. Adicionalmente, existía muy poca información de su estructura interna. • La herramienta actual no contaba con procesos de negocio con diagramas de flujos bien definidos. • Se requería integrar bajo la misma herramienta de gestión de proyectos todas las fases de los mismos incluyendo la planificación temporal y económica así como realizar un seguimiento en tiempo real del cumplimiento de plazos, ingresos y gastos realizados a lo largo de la ejecución del proyecto. La herramienta actual no proporcionaba ninguna de esas características. Debido a estas dificultades se decidió dentro de la organización abordar un nuevo proyecto basado en un sistema workflow/BPM. 7.4.4 Entorno actual de sistemas en la empresa bajo estudio Todos los sistemas hardware de la empresa se encuentran externalizados en la nube. Esto incluye los sistemas de correo electrónico y espacios para los portales web de la empresa y el sistema que alberga al gestor de proyectos. Capítulo 7. Casos de estudio 357 Todas las delegaciones de la empresa y los empleados que trabajan en departamentos que exigen movilidad se conectan de forma remota a dichos sistemas. En la figura 129 se representa este hecho: 7.4.5 Desarrollo de la metodología y resultados obtenidos. En los siguientes apartados se realiza una revisión de las actividades seguidas en cada una de las fases de la metodología y el resultado obtenido. Figura 129. Topología de sistemas en la empresa Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 358 7.4.5.1 Fase de análisis En esta fase se recopiló toda la información necesaria relativa a la estructura orgánica y procesos de negocio que se deseaban implantar. Adicionalmente y como hecho a destacar, una de las preocupaciones mayores de la empresa a la hora de abordar el nuevo sistema era la migración de todos los datos que contenían los sistemas que estaban utilizando. Éstos contenían muchos errores e inconsistencias debido a que: • El sistema que utilizaban no tenía controles relativos a campos obligatorios o formatos permitidos en la entrada. De esta forma, en la base de datos existían campos numéricos donde no deberían estar (por ejemplo, número de teléfono dentro de campos de dirección). • Falta de criterio en el dato único. En múltiples casos existían campos de información que se repetían (por ejemplo, nombres de provincias escritos de tres o cuatro formas distintas) lo cual provocaba una inconsistencia y falta de realidad respecto a los informes que se obtenían cuando se filtraba por alguno de estos campos. A continuación vamos a concentrarnos en el proceso de aprobación de facturas dentro de un proyecto en el cual participan distintos departamentos de la organización: • Nombre de la rejilla: index_facturas_new y formulario para la creación, modificación y borrado. • Campos de información en la rejilla: Identificador del gasto, nombre del proyecto donde se aplica el gasto, nombre del proveedor, número de la factura, fecha de la factura, importe, partida económica dentro del proyecto donde se debe aplicar el importe y estados de aprobación del gasto por cada uno de los departamentos de: dirección de proyecto, operaciones y administración. Capítulo 7. Casos de estudio 359 • Búsquedas permitidas en la rejilla: Se debe permitir realizar búsquedas por el nombre del proyecto donde el gasto ha sido aplicado, por el nombre del proveedor, por cualquier campo de texto de la factura y por intervalo de fechas. • Procesos vinculados a la rejilla: Vinculado a la rejilla se debe poder validar o rechazar el gasto (en función del momento donde se esté del workflow) por parte del responsable del proyecto, el responsable de operaciones y el responsable de administración. • Información de cabecera y pie: En la cabecera de la rejilla no se incorpora ninguna información adicional. En el pie de la rejilla se debe mostrar un sumatorio de los gastos aplicados según el filtro. • Acciones a realizar con los rejistros de la rejilla: Se deben incluir botones de acción para ejecutar validaciones, rechazos, modificar o borrar el gasto. A continuación se procedió a la fase de diseño rápido de la aplicación mediante la creación de los mockups. Figura 130. Ejemplo de mockup para la rejilla de gastos aportados al proyecto Fuente: Elaboración propia Sistemas Workflow y BPM: metodología y casos de estudio 360 7.4.5.2 Fase de diseño rápido (mockups) En la figura 130 se representa el ejemplo de mockup generado para la rejilla de a incorporación de gastos al proyecto donde se representan los elementos detectados en la fase de análisis (buscadores, columnas de datos y botones de acción que aparecerán a medida que avanza el flujo). 7.4.5.3 Fase de creación de workflows En la figura 131 se representa el diagrama para el proceso de autorización de gastos. El proceso de negocio se desglosa en: • Identificación de los participantes. Los perfiles de participantes implicados en el proceso son: técnicos que ejecutan las actividades del proyecto y que Figura 131. Flujo del proceso de negocio: autorización de gastos Fuente: Elaboración propia Capítulo 7. Casos de estudio 361 en determinado momento obtienen las facturas de los proveedores, el responsable del proyecto que debe autorizar los gastos de los proyectos que gestiona, el responsable de operaciones (cargo intermedio que supervisa todos los proyectos en marcha en la empresa) y, por último, el responsable de de administración el cual, en última instancia, comprueba la disponibilidad económica para aprobar o rechazar el gasto. • Identificación de los estados. Se definen siete estados en el workflow: a) pendiente_responsable: cualquier nuevo gasto que se produzca en un proyecto debe ser introducido en el sistema llegando una notificación al responsable del proyecto apara autorizarlo o no: b) denegado_resp_proyecto, si el responsable del proyecto comprueba que el gasto no procede en el proyecto actual pasa la solicitud a estado de denegación; c) pendiente_responsable_operaciones: una vez el gasto ha sido aprobado por el responsable del proyecto concreto debe ser aprobado por el responsable de operaciones, el cual revisa desde un punto de vista operatorio que los gastos que se producen en todos los proyectos son necesarios: d) denegado_responsable_operaciones: en el caso de que el gasto no sea procedente, se deniega; e) pendiente_administracion: los gastos llegan en un última instancia al departamento de administración, el cual vela por la existencia de partida suficiente para hacer frente al gasto. f) denegado_responsable_administracion: el responsable de administración puede decidir denegar el gasto y pasar la solicitud a este estado y, por último, g) aprobado: todos los gastos que hayan superado las validaciones anteriores llegan al último estado de aprobación. • Identificación de las transiciones o cambios de estado. En la figura 131 se representan todas las transiciones permitidas. Existen transiciones hacia atrás dentro del diagrama que simbolizan una solicitud de más información a la persona anterior dentro del flujo. Por ejemplo, el responsable del proyecto CAPÍTULO VIII. CONCLUSIONES Y LÍNEAS DE TRABAJO FUTURO Capítulo 8. Conclusiones y líneas de trabajo futuras 371 En el presente trabajo hemos realizado un análisis de los sistemas workflow/BPM, definiendo en qué consisten. Se ha comprobado que estas tecnologías se constituyen en un elemento clave para las organizaciones de forma que aquellas que cuenten con dichos sistemas podrán ser más competitivas en el mundo rápidamente cambiante en el que nos hallamos inmersos. Posteriormente se realizó una revisión de las arquitecturas existentes en la actualidad y que son propicias para organizaciones de tamaño mediano y pequeño realizando un cuadro comparativo de las mismas. A continuación se analizaron las metodologías más importantes desde el punto de vista de creación e implantación de sistemas workflow/BPM obteniendo también un resumen de las principales características de las mismas y sus inconvenientes. En el Capítulo 5 se profundizó en la metodología que aportamos en el trabajo incidiendo en la resolución de los inconvenientes planteados por las anteriores metodologías. Por último en el Capítulo 7 se revisaron cuatro casos de estudio donde se ha aplicado la metodología propuesta. En el presente capítulo platearemos las principales conclusiones del trabajo desglosadas en los resultados más importantes que hemos obtenido, así como las contribuciones que aportamos. Finalizaremos con una exposición de las líneas de trabajo futuro que se abren a partir del presente trabajo y un último apartado dedicado a describir las principales limitaciones del mismo. 8.1 Resultados obtenidos La metodología propuesta (combinada con la arquitectura y el framework) presenta las siguientes características: • Es de rápida asimilación e implantación por todos y cada uno de los departamentos de una organización, permitiendo la conexión entre los Sistemas Workflow y BPM: metodología y casos de estudio 372 mismos y reduciendo las islas de la automatización y la pérdida de agilidad en el tratamiento de los datos. • Está enfocado a organizaciones de tamaño mediano y pequeño las cuales no pueden realizar grandes inversiones para adquirir un software de workflow consolidado (como SAP o TIBCO) y necesitan una solución que les aporte las ventajas del workflow. • Posibilita la descripción de flujos mediante diagramas gráficos de fácil creación y comprensión. Estos diagramas ayudan a la comprensión por parte de todos los participantes de qué se debe realizar en cada momento. Adicionalmente, para cada uno de los datos incorporados al sistema se podrá conocer por dónde debe fluir. • Plantea una descripción clara de las actividades a realizar por cada perfil de usuario, describiendo los elementos necesarios para que cada participante sepa de una forma clara qué actividades o tareas deben realizar. • Posibilita la creación de un sistema workflow/BPM que se adapta a la organización concreta (y no al revés). De esta forma la organización no debe cambiar sus pautas de funcionamiento debido a que adquiere uno u otro software. • El framework propuesto permite no dar un gran salto dentro de la organización en lo que a gestión del cambio se refiere. Nuestra aportación se basa en introducir sistemas similares a aquellos que los usuarios están acostumbrados en la actualidad (procesadores de texto y utilización de plantillas de forma masiva). • Proporciona una forma sencilla de integración (vía webservices en línea) con otras aplicaciones de forma que el sistema workflow/BPM logre un entendimiento con otros sistemas, mediante la aplicación de unas Capítulo 8. Conclusiones y líneas de trabajo futuras 373 pautas de trabajo, y aún en el caso donde los otros sistemas, no estén preparados para interactuar con otros sistemas siendo este último caso el más típico que podemos encontrar en organizaciones medianas o pequeñas. • Desde un punto de vista de los costes, la metodología que planteamos reduce drásticamente la inversión por dos motivos: a) la adaptación del software a cada organización no se basa en la construcción de un software completamente nuevo, sino que existen múltiples piezas fundamentales ya previamente construidas que sólo deben asociarse y encajarse para la construcción del sistema definitivo adaptado a la organización y este hecho de no construir desde cero reduce el tiempo de trabajo en el sistema y por tanto también los costes; b) nuestra metodología se basa en los principios de las organizaciones ágiles y no en la creación de un proyecto estándar. • Es útil para el desarrollo rápido de aplicaciones. La metodología propuesta está enfocadas a un desarrollo ágil de aplicaciones entre las cuales se incluyen los sistemas workflow/BPM. Adicionalmente, se concreta qué pasos se deben dar para la creación de los procesos de negocio. En la metodología propuesta se han incorporado dichos pasos. • Contempla la gestión de proyectos. La metodología propuesta contiene mucho de los conceptos de la gestión de proyectos. • Contempla gestión de reuniones. La metodología propuesta, al igual que en Scrum, contempla la gestión de reuniones, pero mientras en Scrum forman parte del eje troncal de la misma en la metodología propuesta se intentan minimizar eliminando las de sincronización diarias. La baja necesidad de reuniones, que ahorra tiempo y dinero, se consigue gracias a una alta definición en la forma de ejecutar las tareas dentro de la metodología propuesta. Sistemas Workflow y BPM: metodología y casos de estudio 374 • Contempla la gestión de tareas e hitos. En la metodología propuesta la gestión de tareas es de vital importancia y su grado de concreción en la forma de trabajar por parte de los equipos participantes es alto, indicando para cada tarea responsabilidades, flujo de trabajo a seguir y plazos. • Contempla la gestión de costes por actividad. En la metodología propuesta se ha considerado como un elemento importante para predecir dificultades posteriores por falta de inversión. • Contempla la gestión de riesgos. En la metodología propuesta se profundiza lo suficiente en la necesidad de identificar y gestionar los riesgos vinculándolos a tareas concretas. • Contempla el prototipado de la solución a crear. La metodología propuesta está claramente enfocada a la creación de prototipos cada vez más refinados a medida que se realizan las iteraciones. • Presenta una curva de aprendizaje reducida para la utilización de la metodología. La metodología propuesta posee un aprendizaje fácil y rápido. Con una jornada de trabajo de pocas horas cualquier participante puede comprender cómo se utiliza. • Requiere el uso de herramientas electrónicas. La metodología propuesta requiere el uso de herramientas electrónicas para aumentar la capacidad de comunicación y coordinación de los participantes del proyecto. 8.1.1 Arquitectura y framework creados Para poder conseguir los objetivos planteados y los resultados anteriormente descritos se ha construido una arquitectura y un framework que permite: Capítulo 8. Conclusiones y líneas de trabajo futuras 375 • Diseñar los procesos de negocio de manera gráfica a través de tres elementos: estados, participantes y transiciones. • Incorporar un constructor de formularios con el que se pueda construir de una forma rápida elementos para introducir datos en el sistema los cuales se incluyen las interfaces de los usuarios. • Monitorización y auditoría. • Implantación con una curva de aprendizaje reducida. • Integración con un framework que permita construir (no parametrizar) la solución de workflow/BPM. • Extensión del modelo de datos por parte del usuario final. • Incorporación un cuadro de mandos (dashboard), una gestión de usuarios, una gestión de tareas y una gestión de mensajes y alertas. 8.2 Contribuciones del trabajo Entendemos que el presente trabajo contribuye al conocimiento general de esta materia específica en los términos que seguidamente se exponen, y además, puede generar un beneficio concreto a aquellas organizaciones que decidan implantar un sistema workflow/BPM usando la metodología y arquitectura/framework propuestos. El presente trabajo contribuye generando un beneficio a aquellas organizaciones que lo implanten de la siguiente forma: • Análisis de la definición de un sistema workflow/BPM, sus ventajas y sus inconvenientes a la hora de aplicarlo en una organización. Sistemas Workflow y BPM: metodología y casos de estudio 376 • Revisión de las soluciones existentes en la actualidad que son propicias para ser utilizadas por una organización de tamaño mediano y pequeño, y análisis comparado de sus ventajas e inconvenientes. • Revisión de las distintas metodologías de implantación y desarrollo de software (tanto ágiles como tradicionales) y análisis comparado de sus ventajas e inconvenientes. • Creación de una nueva metodología ágil de implantación partiendo de la metodología ágil Scrum, la cual hemos modificado para que, utilizando un framework, sea aún más ágil en el desarrollo de una aplicación. • Creación de un nuevo framework (incluida la arquitectura) enfocado a sistemas workflow/BPM que permite una rápida y muy eficiente construcción de las aplicaciones más utilizadas en las organizaciones desde el punto de vista de gestión, como son: ERPs, CRMs, gestores de proyectos, etc. 8.3 Líneas de trabajo futuro A partir del trabajo realizado se abren nuevas vías de investigación entre las que destacamos: • Analizar la posibilidad de utilizar la metodología, la arquitectura y el framework diseñados en empresas de gran tamaño. • Evolucionar la arquitectura y el framework hacia la nube bajo la modalidad de plataforma como servicio (PaaS, Platform as a Service). • Generar un constructor de formularios visual basándose en la parametrización desarrollada en el presente trabajo. • Evaluar la productividad al utilizar la metodología propuesta frente a otras metodologías. Capítulo 8. Conclusiones y líneas de trabajo futuras 377 • Evaluar los sistemas implantados sobre la base de la experiencia de los usuarios con el sistema. A continuación se profundiza en cada una de las líneas propuestas. 8.3.1 Analizar la posibilidad de utilizar la metodología en grandes empresas Si bien el enfoque que hemos dado al trabajo actual ha sido hacia organizaciones de tamaño mediano y pequeño a las cuales hemos tenido acceso, una línea de trabajo futuro consistiría en estudiar la viabilidad en una organización de grandes dimensiones donde el sistema se utilice por un número muy elevado de usuarios. Este caso ayudará a evaluar: • La agilidad de metodología en el caso de varios grupos de trabajo trabajando simultáneamente con el objetivo de la implantación de un sistema workflow/BPM común a múltiples departamentos. • Conocer los requisitos técnicos necesarios para que dicho sistema pueda operar con buenas prestaciones. 8.3.2 Evolucionar la arquitectura hacia una modalidad PaaS Cada vez es más extendido el concepto de nube (cloud) entre las organizaciones mediante el cual el software que adquieren no es una aplicación a instalar en los servidores locales de la empresa. La aplicación se convierte en un servicio prestado vía Internet donde la empresa adquiere derecho de uso (no el software) incluyendo en el mismo cualquier concepto relativo a máquinas, espacios de almacenamiento, ancho de banda de conexión, etc. (Armbrust, 2010). Sistemas Workflow y BPM: metodología y casos de estudio 384 Atkinson, S. R., & Moffat, J. (2005). The agile organization: From informal networks to complex effects and agility (p. 245). CCRP Publication Series. Avison, D. E., Lau, F., Myers, M. D. y Nielsen, P. A. (1999). Action research. Communications of the ACM, 42(1), 94-97. Avison, D. E. y Fitzgerald, G. (2003). Where now for development methodologies? Communications of the ACM, 46(1), 78-82. Bannerman, P. L., Hossain, E. y Jeffery, R. (2012, January). Scrum practice mitigation of global software development coordination challenges: A distinctive advantage? En System Science (HICSS), 2012 45th Hawaii International Conference on (pp. 5309-5318). IEEE. Baskerville, R. L. (1997). Distinguishing action research from participative case studies. Journal of systems and information technology, 1(1), 24-43. Baskerville, R. L. (1999). Investigating information systems with action research. Communications of the AIS, 2(3es), 4. Barney, J. B. (1986). Organizational culture: can it be a source of sustained competitive advantage? Academy of management review, 11(3), 656-665. Bellotti, V., Ducheneaut, N., Howard, M. y Smith, I. (2003). Taking email to task: the design and evaluation of a task management centered email tool. En Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 345-352). ACM. Benjamin, R. I. y Blunt, J. (1992). Critical IT issues: The next ten years. MIT Sloan Management Review, 33(4), 7. Berry, M. J. y Linoff, G. S. (2004). Data mining techniques: for marketing, sales, and customer relationship management. John Wiley & Sons. Gates, B. y Huber, M. B. (2006). How I Work. Bill Gates. Bibliografía 385 Bizagi (2015). Suite BPM. Disponible en http://www.bizagi.com/es/. Accedido el 02/11/2015. Bonita workflow (2015). Portal Web de documentación. Disponible en http://es.bonitasoft.com/. Accedido el 02/11/2015. Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F. y Winer, D. (2000). Simple object access protocol (SOAP) 1.1. W3C. Brynjolfsson, E. y Hitt, L. M. (2000). Beyond computation: Information technology, organizational transformation and business performance. The Journal of Economic Perspectives, 23-48. Carmona, J., Cortadella, J. y Kishinevsky, M. (2009). Divide-and-conquer strategies for process mining. En Business Process Management (pp. 327-343). Springer Berlin Heidelberg. Casati, F., Ceri, S., Pernici, B. y Pozzi, G. (1996). Workflow evolution. En Conceptual Modeling—ER'96 (pp. 438-455). Springer Berlin Heidelberg. Casati, F., Castano, S. y Fugini, M. (2001). Managing workflow authorization constraints through active database technology. Information Systems Frontiers, 3(3), 319-338. Castells, M. (2002). La galaxia internet. Plaza & Janés. Castells, M. (2004). La era de la información: economía, sociedad y cultura. (Vol. 3). Siglo XXI. Castells, M. y Andrade, J. A. (2010). La sociedad red: una visión global. Enl@ce, 7(1). Castells, P. E. y Pasola, J. V. (2004). Tecnología e innovación en la empresa (Vol. 148). Universidad Politécnica de Cataluña. Sistemas Workflow y BPM: metodología y casos de estudio 386 Castelluccio M. (2014). Computer-enabled Hoarding. Strategic Finance, 96(6), 59. Castro, S. J. B., Crespo, R. G. y García, V. H. M. (2011). Antipatterns: a compendium of bad practices in software development processes. IJIMAI,1(4), 41-46. Carlsen, S., Krogstie, J., Sølvberg, A. y Lindland, O. I. (1997, January). Evaluating flexible workflow systems. In System Sciences, 1997, Proceedings of the Thirtieth Hawaii International Conference on (Vol. 2, pp. 230-239). IEEE. Chaffer, J. (2009). Learning JQuery 1.3: Better Interaction and Web Development with Simple JavaScript Techniques. Packt Publishing Ltd. Chapman, C. y Ward, S. (1996). Project risk management: processes, techniques and insights. John Wiley. Chen, I. J. (2001). Planning for ERP systems: analysis and future trend. Business Process Management Journal, 7(5), 374-386. Chesbrough, H. (2013). Open business models: How to thrive in the new innovation landscape. Harvard Business Press. Club BPM (2015). Metodología BPM-RAD. Disponible en http://www.clubbpm.com/Metodologia-BPM-RAD.htm. Accedido el 02/11/2015. Cochran, D. (2012). Twitter Bootstrap Web Development How-To. Packt Publishing Ltd. Cohn, M. (2010). Succeeding with agile: software development using Scrum. Pearson Education. Comisión Europea (2002). E-Europe, una sociedad de la información para todos. Disponible en http://goo.gl/EVSloD. Accedido el 02/11/2015. Cooper, R. y Kaplan, R. S. (1992). Activity-based systems: Measuring the costs of resource usage. Accounting Horizons, 6(3), 1-13. Bibliografía 387 Covey, S. R. (2014). The 7 habits of highly effective families. St. Martin's Press. Cumberlidge (2007) Business Process Management with Jboss Jbpm. Packt Publishing Ltd. Davis, R. (2002). The Wizard of OZ in Crmland: Crm's Need for Business Process Management. Information Systems Management, 19(4), 43-48. Dehnert, J. (2003). A Methodology for Workflow Modeling: From business process modeling towards sound workflow specification. Technische Universität Berlin. Delgado, J. y Marín, F. (2000). Evolución en los sistemas de gestión empresarial. Del MRP al ERP. Economía industrial, 331, 51-58. De Mast, J. y Lokkerbol, J. (2012). An analysis of the Six Sigma DMAIC method from the perspective of problem solving. International Journal of Production Economics, 139(2), 604-614. Dingsøyr, T., Hanssen, G. K., Dybå, T. Anker, G. y Nygaard, J. O. (2006). Developing software with scrum in a small cross-organizational project. En Software Process Improvement (pp. 5-15). Springer Berlin Heidelberg. Dourish, P., Edwards, W. K., LaMarca, A., Lamping, J., Petersen, K., Salisbury, M. y Thornton, J. (2000). Extending document management systems with user-specific active properties. ACM Transactions on Information Systems (TOIS), 18(2), 140-170. Duipmans, E. F., Pires, L. F., y da Silva Santos, L. O. B. (2012). Towards a BPM cloud architecture with data and activity distribution. En Enterprise Distributed Object Computing Conference Workshops (EDOCW), 2012 IEEE 16th International (pp. 165-171). IEEE. Dumas, M. y Ter Hofstede, A. H. (2001). UML activity diagrams as a workflow specification language. En UML 2001—The Unified Modeling Language. Modeling Languages, Concepts, and Tools (pp. 76-90). Springer Berlin Heidelberg. Sistemas Workflow y BPM: metodología y casos de estudio 388 Duncan, W. R. (1996). A guide to the project management body of knowledge. Project Management Institute. Peter, D. y Jorge, C. (2004). La sociedad postcapitalista. Editorial Norma. Drucker, P. F. (1988). The coming of the new organization. Harvard Business Review. Drucker, P. F. (1995). People and performance: The best of Peter Drucker on management. Routledge. Drucker, P. F. (2007). Management challenges for the 21st century. Routledge. Elzinga, D. J., Horak, T., Lee, C. Y. y Bruner, C. (1995). Business process management: survey and methodology. Engineering Management, IEEE Transactions on, 42(2), 119-128. Ferguson, D. F. y Stockton, M. L. (2005). Service-oriented architecture: Programming model and product architecture. IBM Systems Journal, 44(4), 753-780. Ferraiolo, D., Cugini, J. y Kuhn, D. R. (1995). Role-based access control (RBAC): Features and motivations. En Proceedings of 11th annual computer security application conference (pp. 241-48). Figueroa, V. (1995). Proyecto ESTROFA, Especificaciones para Tratamiento de Flujos Administrativos Automatizados. Novática: Revista de la Asociación de Técnicos de Informática, (115), 12. FlowMark, I. B. M. (1995). Modeling Workflow, Release 2.1. International Business Machines Corp. Friedman, T. (2005). The world is flat. New York: Farrar, Straus and Giroux. Gambardella, A. y McGahan, A. M. (2010). Business-model innovation: General purpose technologies and their implications for industry structure. Long range planning, 43(2), 262-271. Bibliografía 389 Garcês R., de Jesus, T, Cardoso J y Valente P. (2009). Open Source Workflow Management Systems: A Concise Survey. Disponible en http://michaelgrassmann.de/tools/WorkflowHandbook09-Open-Source-WfMS.pdf. Accedido el 02/11/2015. Garimella, K. y Lees, M. (2008). Introducción a BPM. New York: Jacques Boussard. Georgakopoulos, D., Hornick, M. y Sheth, A. (1995). An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and parallel Databases, 3(2), 119-153. Giaglis, G. M. (2001). A taxonomy of business process modeling and information systems modeling techniques. International Journal of Flexible Manufacturing Systems, 13(2), 209-228. González Lorca, J. (2006). Sistemas workflow, Funcionamiento y metodología de implantación. Ediciones Trea. González Lorca, J. y Rodríguez-Muñoz, J. V. (2002). La tecnología de flujo de trabajo en el contexto de la biblioteca digital. En Anales de documentación (Vol. 5, pp. 157-175). Servicio de Publicaciones, Universidad de Murcia (Spain). Goodman, D. (2002). Dynamic HTML: The Definitive Reference: A Comprehensive Resource for HTML, CSS, DOM & JavaScript. O'Reilly Media, Inc. Grande, J. I. C., Araujo, M. C. R. y Serna, M. S. (2002). La necesidad de teoría (s) sobre gobierno electrónico. Una propuesta Integradora. XVI Concurso de Ensayos y Monografías del CLAD sobre Reforma del Estado y Modernización de la Administración Pública. Caracas. Gulledge Jr, T. R. y Sommer, R. A. (2002). Business process management: public sector implications. Business Process Management Journal, 8(4), 364-376. Sistemas Workflow y BPM: metodología y casos de estudio 390 Hales, K. (1998). Workflow in context. En Workflow handbook 1997 (pp. 27-32). John Wiley & Sons, Inc.. Harrer, S., Lenhard, J. y Wirtz, G. (2013). Open source versus proprietary software in service-orientation: The case of BPEL engines. En Service-Oriented Computing (pp. 99-113). Springer Berlin Heidelberg. Havey, M. (2005). Essential business process modeling. O'Reilly Media, Inc. Highsmith, J. y Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 34(9), 120-127. Hirst, P., Thompson, G. y Bromley, S. (2015). Globalization in question. John Wiley & Sons. Hollensen, S. (2015). Marketing management: A relationship approach. Pearson Education. Hollingsworth, D. (1995). The workflow reference model. The Workflow Management Coalition. Hossain, E., Babar, M. A., Paik, H. Y. y Verner, J. (2009, December). Risk identification and mitigation processes for using scrum in global software development: A conceptual framework. En Software Engineering Conference, 2009. APSEC'09. Asia-Pacific (pp. 457-464). IEEE. Howes, T. A., Smith, M. C. y Good, G. S. (2003). Understanding and deploying LDAP directory services. Addison-Wesley Longman Publishing Co., Inc.. Hult, M. y Lennung, S. Å. (1980). Towards a definition of action research: a note and bibliography. Journal of Management Studies, 17(2), 241-250. Ianni, O. (1996). Teorías de la globalización. Siglo XXI Editores. IDC (2014). IDC Marketscape. Disponible en: http://www.idc.com/MarketScape/. Accedido el 10/11/2015. Bibliografía 391 Infoworld (2013). Bossies 2013: The Best of Open Source Software Awards. Disponible en http://www.infoworld.com/article/2606353/open-sourcesoftware/119652-Bossie-Awards-2013-The-best-open-source-applications.html. Accedido el 02/11/2015. Infoworld (2014). Bossies 2014: The Best of Open Source Software Awards. Disponible en http://www.infoworld.com/article/2688104/open-sourcesoftware/article.html. Accedido el 02/11/2015. Jackson, T. y Russell, E. (2015). Four email problems that even titans of tech haven't resolved. The Conversation. Jackson, S. E., Joshi, A. y Erhardt, N. L. (2003). Recent research on team and organizational diversity: SWOT analysis and implications. Journal of management, 29(6), 801-830. Jarvenpaa, S. L., Rao, V. S. y Huber, G. P. (1988). Computer support for meetings of groups working on unstructured problems: A field experiment. MIS Quarterly, 645666. jBoss (2015). JBossDeveloper Documentation. Disponible en http://www.jboss.org/technology/. Accedido el 02/11/2015. Jeston, J. y Nelis, J. (2008). How to Demystify BPM?. BPTrends. Kandampully, J. (2002). Innovation as the core competency of a service organisation: the role of technology, knowledge and networks. European Journal of Innovation Management, 5(1), 18-26. Kaplan, R. S. y Norton, D. P. (1995). Putting the balanced scorecard to work. Performance measurement, management, and appraisal sourcebook, 66. Kaplan, R. y Anderson, S. R. (2013). Time-driven activity-based costing: a simpler and more powerful path to higher profits. Harvard Business Press. Sistemas Workflow y BPM: metodología y casos de estudio 392 Kauffeld, S. y Lehmann-Willenbrock, N. (2012). Meetings Matter Effects of Team Meetings on Team and Organizational Success. Small Group Research,43(2), 130158. Kepes B. (2015). Amazon Changes The Game Again—AWS Introduces WorkMail. Forbes Tech. Disponible en http://www.forbes.com/sites/benkepes/2015/01/28/amazon-changes-the-game-againaws-introduces-workmail/. Accedido el 02/11/2015. Kephart, J. O. y Chess, D. M. (2003). The vision of autonomic computing. Computer, 36(1), 41-50. Kerzner, H. R. (2013). Project management: a systems approach to planning, scheduling, and controlling. John Wiley & Sons. Khoshafian, S. y Buckiewicz, M. (1995). Introduction to groupware, workflow, and workgroup computing. John Wiley & Sons, Inc.. Kim, J. y Moon, J. Y. (1997). An AHP & survey for selecting workflow management systems. Intelligent Systems in Accounting, Finance and Management, 6(2), 141161. Klaus, H., Rosemann, M. y Gable, G. G. (2000). What is ERP?. Information systems frontiers, 2(2), 141-162. Knolmayer, G., Endl, R. y Pfahrer, M. (2000). Modeling processes and workflows by business rules. En Business Process Management (pp. 16-29). Springer Berlin Heidelberg. Ko, R. K., Lee, S. S. y Wah Lee, E. (2009). Business process management (BPM) standards: a survey. Business Process Management Journal, 15(5), 744-791. Kozlowski, S. W., Grand, J. A., Baard, S. K. y Pearce, M. (2015). Teams, teamwork, and team effectiveness: Implications for human systems integration. The handbook of human integration. Disponible en http://goo.gl/jnaVUq. Accedido el 11/11/2015. Bibliografía 393 Kracklauer, A. H., Mills, D. Q. y Seifert, D. (2004). Collaborative customer relationship management: taking CRM to the next level. Springer Science & Business Media. Kueng, P. (2000). The effects of workflow systems on organizations: A qualitative study. En Business Process Management (pp. 301-316). Springer Berlin Heidelberg. Kumar, V. (2010). Customer relationship management. John Wiley & Sons, Ltd. Larson, E. W. y Gray, C. F. (2011). Project management: The managerial process. McGraw-Hill. Lautenbacher, F. y Bauer, B. (2007). A Survey on Workflow Annotation & Composition Approaches. En SBPM. Laurentiis, G. (2011). Metodología BPM: RAD®–Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM. En el Libro del BPM: Tecnologías, Conceptos, Enfoques Metodológicos y Estándares. Madrid, España: Club-BPM. Lepak, D. P. y Snell, S. A. (1998). Virtual HR: Strategic human resource management in the 21st century. Human resource management review, 8(3), 215234. Levasseur, R. E. (2001). People skills: Change management tools—Lewin's change model. Interfaces, 31(4), 71-73. Leymann, F. (2001). Web services flow language (WSFL 1.0). Lin, F. R., Yang, M. C. y Pai, Y. H. (2002). A generic structure for business process modeling. Business Process Management Journal, 8(1), 19-41. Lorenzi, N. M. y Riley, R. T. (2000). Managing change. Journal of the American Medical Informatics Association, 7(2), 116-124. Sistemas Workflow y BPM: metodología y casos de estudio 400 Smith, H. (2003). Business process management—the third wave: business process modelling language (bpml) and its pi-calculus foundations. Information and Software Technology, 45(15), 1065-1069. Star, S. L. (1990). Power, technology and the phenomenology of conventions: on being allergic to onions. The Sociological Review, 38(S1), 26-56. Stefik, M., Foster, G., Bobrow, D. G., Kahn, K., Lanning, S. y Suchman, L. (1987). Beyond the chalkboard: computer support for collaboration and problem solving in meetings. Communications of the ACM, 30(1), 32-47. Sutton, R. I. y Hargadon, A. (1996). Brainstorming groups in context: Effectiveness in a product design firm. Administrative Science Quarterly, 685-718. Szyperski, C., Bosch, J. y Weck, W. (1999). Component-oriented programming. In Object-oriented technology ecoop’99 workshop reader (pp. 184-192). Springer Berlin Heidelberg. Teece, D. J. (2010). Business models, business strategy and innovation. Long range planning, 43(2), 172-194. Thatte, S. (2001). XLANG: Web services for business process design. Microsoft Corporation, 13. The, L. (1995). Workflow tackles the productivity paradox. Datamation-Highlands Ranch, 41(15), 65-66. Thiagarajan, R. K., Srivastava, A. K., Pujari, A. K. y Bulusu, V. K. (2002, June). BPML: a process modeling language for dynamic business models. En Advanced Issues of E-Commerce and Web-Based Information Systems, 2002 (WECWIS 2002). Proceedings. Fourth IEEE International Workshop on (pp. 222-224). IEEE. Tibco (2015). Tibco ActiveMatrix. Disponible en http://www.tibco.com/products/automation/application-integration/activematrixbusinessworks. Accedido el 02/11/2015. Bibliografía 401 Trætteberg, H. y Krogstie, J. (2008). Enhancing the usability of bpm-solutions by combining process and user-interface modelling. En The practice of enterprise modeling (pp. 86-97). Springer Berlin Heidelberg. Tyree, J. y Akerman, A. (2005). Architecture decisions: Demystifying architecture. IEEE software, (2), 19-27. van der Aalst, W. y van Hee, K. M. (2004). Workflow management: models, methods, and systems. MIT press. van der Aalst, W. M., Mans, R. S. y Russell, N. C. (2009). Workflow Support Using Proclets: Divide, Interact, and Conquer. IEEE Data Eng. Bull., 32(3), 16-22. Vom Brocke, J. y Rosemann, M. (2010). Handbook on business process management. Heidelberg: Springer. Voorhoeve, M. y Van der Aalst, W. (1997, September). Ad-hoc workflow: problems and solutions. En Database and Expert Systems Applications, 1997. Proceedings., Eighth International Workshop on (pp. 36-40). IEEE. Wang, M., Wang, H. y Xu, D. (2005). The design of intelligent workflow monitoring with agent technology. Knowledge-Based Systems, 18(6), 257-266. Weske, M. (2012). Business process management: concepts, languages, architectures. Springer Science & Business Media. WfCM (1999). Workflow Management Coalition. Disponible en: http://www.wfmc.org/. Accedido el 10/11/2015. White, S. A. (2004a). Introduction to BPMN. IBM Cooperation, 2(0). White, S. A. (2004b). Process modeling notations and workflow patterns.Workflow handbook, 2004, 265-294. Sistemas Workflow y BPM: metodología y casos de estudio 402 Wohed, Russell (2009). Patterns-based evaluation of open source BPM systems: The cases of jBPM, OpenWFE, and Enhydra Shark. Information and Software Technology, 51(8), 1187-1216 yED (2015). yED graphical editor. Disponible en http://www.yworks.com/en/products/yfiles/yed/. Accedido el 02/11/2015. Zur Muehlen, M. (2004). Organizational management in workflow applications–issues and perspectives. Information Technology and Management, 5(3-4), 271-291. Zur Muehlen, M. y Indulska, M. (2010). Modeling languages for business processes and business rules: A representational analysis. Information systems, 35(4), 379390.