Casos Prácticos
Casos Prácticos
Casos Prácticos
En este capítulo se describen algunos casos de éxito en organizaciones que han llevado
adelante algún aspecto de gestión por procesos de negocio, cada una de ellas con mayor o
menor grado de adhesión, pero en todos los casos, aplicando una metodología y las herra-
mientas tecnológicas habilitantes, presentadas en este libro.
Para cada caso presentado mostraremos el objetivo y alcance del mismo, es decir el campo
del dominio al que aplica, qué resuelve y hasta dónde abarca la solución. Luego se presenta la
solución propiamente dicha, incluyendo la arquitectura tecnológica y proceso/s involucrado/s y
finalmente abordaremos la discusión y resultados de la solución.
Sistema basado en BPM para el Seguimiento del Proceso Licitatorio y la Ejecución de Pro-
yectos del Programa PMGM-UEC Ministerio del Interior y Transporte de la Nación Argentina
En el año 2013, los autores de este libro participaron en el desarrollo de este sistema y en
2014, el trabajo finalizado dio origen a la publicación en el 8vo SIE (Simposio de Informática en
el Estado), en el marco de las 43a JAIIO (Jornadas Argentinas de Informática e Investigación
Operativa) [Chedrese V. et al, 2014]
Objetivo
Es un sistema basado en BPM para el seguimiento del proceso licitatorio en una organiza-
ción pública y muestra las mejoras obtenidas como consecuencia de dicha implementación.
El objetivo general del Programa de Mejora de la Gestión Municipal PMGM (BID 1855 OC-
AR) es el de mejorar la capacidad de gestión de los gobiernos municipales, para que éstos
respondan de forma más efectiva a las necesidades locales. Sustentado por el BID (Banco
Interamericano de Desarrollo), el Programa de Mejora de la Gestión Municipal PMGM (BID
1855 OC-AR) tiene como objetivo general el de mejorar la capacidad de gestión de los gobier-
nos municipales, para que éstos respondan de forma más efectiva a las necesidades locales.
Para ello, el BID ha asignado un monto de u$s 80.000.000, por única vez, para el desarrollo e
implementación de proyectos.
El Programa propone desarrollar e implementar mecanismos replicables de fortalecimien-
to municipal en las áreas de administración interna, finanzas, tributación, catastros, servicios
de atención al ciudadano, gobierno electrónico, planificación urbana y pro moción económica
local, entre otras 3,4
Este programa contempla intervenciones coordinadas en los tres ámbitos del gobierno (na-
cional, provincial y municipal), tendientes al fortalecimiento de las capacidades de los gobiernos
municipales. Las actividades a ser financiadas son de dos tipos:
(i) Proyectos de iniciativa provincial, orientadas a mejorar el marco de las políticas de des-
centralización, ampliar el alcance de los sistemas de gestión pública desarrollados por
la provincia, implementar proyectos de apoyo a las municipalidades y desarrollar ins-
trumentos de gestión que requieren soluciones de escala.
(ii) Proyectos de desarrollo institucional identificados por los propios municipios, en temas
como planificación urbana, centros de atención de trámites, preparación de proyectos y
otros. Adicionalmente, el Programa incluye un componente de apoyo a actividades de
promoción, fortalecimiento y seguimiento del sector municipal en general, a ser ejecu-
tado por el Ministerio del Interior.
Alcances
Analizando las actividades de cada sector y la forma en que éstos se comunican, aparece
una estructura basada en los procesos funcionales. Si bien al momento de iniciar este trabajo
no existía un buen grado de formalización de los procesos dentro de la UEC, el Programa bus-
ca dentro de este contexto, implementar su funcionamiento en base a procesos de negocio.
Es posible considerar entonces al Programa constituido por cada uno de sus sectores, que
se relacionan entre sí, que intercambian documentación e información con las otras áreas de la
UEC, con la participación de entidades externas como las Provincias y el Banco, consolidando
3
http://www.uec.gov.ar/uec2009/web/index.php
4
http://xgob.blogspot.com.ar/2013/06/programa-de-mejora-de-la-gestion.html
distintos procesos operativos. Este funcionamiento integral del Programa, con el aporte de valor
de todos los participantes y basado en procesos operativos, se encuadra en lo que se denomi-
na una gestión por procesos.
Luego de un primer análisis, resultó evidente que la gestión por procesos permitiría a la
UEC mejorar la gestión de sus actividades, de los recursos utilizados, del tiempo de respuesta
de los servicios que presta y del control en general. Para comenzar este trabajo, fue necesario
identificar, estudiar y adecuar los procesos del programa con todos los participantes, internos y
externos, para que pudieran implementarse operativamente en una herramienta informática de
características colaborativas y especialmente diseñadas para la operación y administración de
los procesos.
La premisa principal fue la utilización de herramientas de software libre, tanto para la gestión
de los procesos, la administración de la documentación asociada a los mismos y el desarrollo
de las aplicaciones que, a manera de servicios, abastecieron a las actividades de los procesos.
Definición de los procesos Definición de actividades y participantes, Diseño global de los procesos
identificación de actores externos, la infor-
mación que se intercambia y las variables
de proceso involucradas.
Codificación de procesos y Construcción del diccionario de procesos, Diseño de detalle de los pro-
actividades actividades y reglas de negocio permitiendo cesos,
así catalogar los mismos e identificar su
transversalidad.
Prueba preliminar Revisión final del diseño de proceso, inte- Solución desplegada
gración de los servicios (en este caso formu-
larios) y el despliegue y ejecución de los
procesos en el BPMS.
Test, puesta a punto y pues- Etapa clásica de cualquier desarrollo de Solución en producción
ta en marcha software
La solución incluye la instalación del software de base sobre el hardware que puso a
disposición la UEC para este proyecto. Dicha instalación se realizó en base a las indicacio-
nes y supervisión directa de los responsables del Data Center de la UEC, de manera que
las instalaciones de software necesarias para el proyecto, no interfieran en el funciona-
miento operativo de la UEC.
Se instaló un ambiente tecnológico (de desarrollo, pruebas y producción) para la herra-
mienta BPMS. Este ambiente permitió realizar las pruebas operacionales de los procesos
desarrollados.
Las herramientas utilizadas para dar soporte a la solución y permitir llevar a cabo la me-
todología planteada son: Bonita Open Solution: suite BPMS (Sistema de gestión de proce-
sos de negocio).de código abierto que combina el diseño gráfico de los procesos de nego-
cio siguiendo el estándar BPMN (Notación para el modelado de procesos de negocio), un
motor de ejecución y una interfaz de usuario sencilla y configurable. El usuario puede crear
conectores que permiten comunicar Bonita con otras aplicaciones y compartirlos en forma
colaborativa a través de la gran comunidad de usuarios de Bonita. Alfresco Communit y
Edition - On-Premise: gestor documental de código abierto. Proporciona todos los servicios
de gestión de documentos, permitiendo capturar y guardar archivos electrónicos, previsua-
lizar los mismos y gestionar su versionado en distintos repositorios, admin istrando usuarios
y roles. Lenguaje PHP: lenguaje de programación orientado al desarrollo de aplicaciones
web dinámicas, que puede ser usado en la mayoría de los servidores web y en casi todos
los sistemas operativos y plataformas sin costo alguno. Tiene c apacidad de conexión con la
mayoría de los motores de base de datos, especialmente con MySQL. MySQL: sistema de
gestión de bases de datos de código abierto y uso gratuito. Apache Tomcat: como servidor
Web y servidor de aplicaciones
Como se observa en la Figura 34, la ejecución y compleción de las actividades se resol-
vió por medio de la invocación de servicios web vinculados al motor de procesos a través
de variables de proceso, conectores y validadores apropiados. El acceso al gestor docu-
mental y al servidor de correos se realizó íntegramente desde los formularios PHP, resul-
tando transparente para los usuarios que sólo deben autenticarse al ingresar a la aplica-
ción a través del motor de procesos.
El PMGM es sólo uno de los programas federales de distintos organismos financieros inter-
nacionales que lleva adelante la UEC, abarcando 24 provincias y 250 municipios. El trabajo
llevado a cabo, servirá indudablemente como prueba piloto para la futura generalización en esa
organización de la gestión por procesos.
Por otra parte, el uso de software libre se vislumbra como doblemente ventajoso en un or-
ganismo del estado, tanto desde el punto de vista de los costos como de la independencia tec-
nológica, entre otros beneficios.
Sin lugar a dudas, la representación y coordinación de las actividades de los procesos, junto
con su despliegue en una versión ejecutable realizada íntegramente en herramientas de soft-
ware libre y orientada a servicios, constituye en el PMGM un cambio tecnológico y operativo
que permitirá verdaderamente instrumentar una gestión por procesos posibilitando llevar a cabo
una tarea más ágil, mejor supervisada y más eficaz, que permita responder rápidamente a los
cambios y desafíos que se presenten en el futuro.
Los procesos instrumentados en esta solución constan de la ejecución de varias activi-
dades que involucran a distintos participantes. Estos son, la totalidad de dependencias del
PMGM, consultores especialistas, los solicitantes de los préstamos (Provincias y Munici-
pios) y el mismo BID. Todos participan efectuando actividades para alcanzar el objetivo
final del Programa.
El uso de BPMS ha posibilitado adelantos importantes en cuanto a la velocidad y agilidad
con que las organizaciones mejoran el control y rendimiento de sus procesos, logrando instru-
mentar metodologías que permiten alinear esfuerzos entre la conducción y los participantes de
las distintas actividades, mejorando la productividad y el rendimiento personal.
La implementación de esta solución con enfoque de procesos ha tenido un fuerte impacto
en la organización que se puede evaluar en torno a las siguientes mejoras obtenidas:
En el año 2013, los autores de este libro participaron en el desarrollo de un proceso de ne-
gocio que cubra el circuito de compras en un organismo de la administración pública nacional,
en Argentina.
Objetivo
El objetivo del proyecto fue definir e implementar una arquitectura para el ambiente de desa-
rrollo, prueba y producción, con componentes de software libre, integrado principalmente un
BPMS y utilizando como repositorio la base de datos Oracle del organismo.
Asimismo, se realizó la reingeniería de cinco procesos seleccionados, su posterior desarro-
llo en el BPMS y la implementación de los mismos en el ámbito del organismo.
En este libro se describe el resultado del diseño e implementación de uno de los proce-
sos seleccionados.
Alcances
Los alcances que se plantearon para el proyecto fueron los de seleccionar una herramienta
BPMS de software libre, que mejor se adapte para resolver los problemas del organismo y par-
ticularmente de los cinco procesos objeto del proyecto.
En base a dicha selección, trabajar sobre la instalación de un ambiente tecnológico (de
desarrollo, pruebas y producción) para la herramienta BPMS seleccionada, dentro del data
center que utiliza el organismo para su funcionamiento.
Asimismo, se realizó el relevamiento de los cinco procesos seleccionados, la aplicación de
una ingeniería de procesos sobre los mismos, el diseño, implementación y puesta en marcha
de la solución, para tales cinco procesos.
Por último, se desarrolló la capacitación, a las áreas pertinentes del organismo en el nuevo
modelo de gestión y en las herramientas tecnológicas utilizadas.
Los procesos involucrados en la solución y que se identificaron como prioritarios en su mo-
mento para el organismo fueron: 1 - Solicitud de Compra, 2 - Compras por Licitación Pública, 3
- Compras por Licitación Privada, 4 - Otorgamiento de Licencias para Pilotos y 5 - Transferen-
cia de Aeronaves.
Se describe en este capítulo el proceso de Solicitud de Compra.
Condiciones Particulares del bien o servicio requerido, así como la Solicitud de Gasto necesaria
para la reserva de crédito por parte de Presupuesto.
Pueden ser Requirentes cualquiera de las Direcciones del organismo que son quienes pue-
den caratular expedientes en el Sistema de Gestión de Expedientes propio del organismo.
El Requirente deberá adjuntar la documentación necesaria para iniciar la compra. Para ello
tendrá acceso al gestor documental, donde podrá incorporarse la documentación asociada al
expediente de la compra. De la misma manera, en cualquier actividad del proceso podrán ad-
juntarse informes o redactarse observaciones antes de completar la misma.
De corresponder la adquisición de productos informáticos, las Especificaciones Técnicas
deberán ser aprobadas por la ONTI.
Se deberá requerir la autorización de la Administración Nacional y de la Dirección Nacional
o General de la cual dependa el originante primario de la necesidad.
El área de Suministros analizará las Especificaciones Técnicas y, de ser necesario, solicita-
rá al Área requirente las correcciones pertinentes.
Una vez puestas a punto y autorizadas las Especificaciones Técnicas y la Solicitud de Gas-
to, el Área requirente inicia el expediente de compra y remite el pedido de autorización del gas-
to a Presupuesto.
Si Presupuesto autoriza el gasto, el proceso finaliza para comenzar la confección del pliego.
De lo contrario, vuelve al inicio para que el Área requirente quede en espera de crédito.
A continuación, describimos cada una de las actividades:
Confección ET y SG
El Área requirente redacta las Especificaciones Técnicas y la Solicitud de Gastos. Ingresa el
objeto de la contratación, el monto preventivo, la unidad requirente y realiza una fundamenta-
ción y necesidad de tramitación excepcional, si correspondiera. Adjunta los documentos redac-
tados al gestor documental.
Recepción de ET y SG
En esta instancia, es posible cancelar el proceso si por alguna razón no se continuara con la
compra; esta situación será indicada por el participante, quien deberá ingresar el motivo, que-
dando registrado el mismo junto al usuario que ordenó la cancelación. Si el proceso continúa
normalmente y no había sido ingresado anteriormente, se incluye el objeto de la contratación,
el monto preventivo y la unidad requirente. Asimismo, se indica si la Administración Nacional ya
ha autorizado la compra y si la misma requiere la intervención de ONTI. De corresponder, se
indican las direcciones intervinientes, distintas al Área Requirente.
Autorizar
En el caso en que la compra esté relacionada con una Regional o requiera la intervención
de una o más Direcciones Centrales -distintas del Área requirente-, se requerirá la autorización
de la misma por parte de cada una de ellas, pudiendo adjuntarse en cada caso los documentos
Inicio de expediente
El Área requirente inicia el expediente en el sistema de expedientes e ingresa los datos del
mismo en el sistema.
Remitir a ONTI
Cuando el objeto de la contratación está referido a Sistemas Informáticos, el área de Siste-
mas debe remitir las Especificaciones Técnicas y la Solicitud de Gastos a la ONTI para su eva-
luación. Envía documentos a la ONTI vía email.
Respuesta ONTI
El sector de Sistemas espera la recepción de un email por parte de la ONTI con el resultado
de la evaluación sobre las Especificaciones Técnicas y la Solicitud de Gastos. Si la respuesta
es positiva, el proceso continuará a pedir la autorización de C35. De lo contrario, volverá al
Área de Sistemas para que ésta realice las correcciones determinadas por el organismo.
Correcciones de ET y SG
El Área requirente realiza las correcciones indicadas por Suministros a las Especificaciones
Técnicas y/o la Solicitud de Gasto, adjuntando las nuevas versiones de los documentos al ges-
tor documental.
Afectar preventivo
Presupuesto verifica la existencia de crédito y de ser suficiente, afecta el presupuesto pre-
ventivo autorizando la Solicitud de Gasto. Indica si hay crédito o no y si el mismo está sujeto a
una modificación.
Control de ET y SG
Luego de recibir el expediente físico, Suministros controla que las Especificaciones Técni-
cas y la Solicitud de Gasto que se encuentran en el gestor documental coincidan con las con-
tenidas en el expediente físico. Controla foliatura, inicialado y firmas. Si Presupuesto indicó que
hay crédito o el mismo está sujeto a una modificación presupuestaria, el proceso finaliza para
continuar con la confección del pliego. De otra manera, el expediente permanece en el área
requirente a la espera de crédito.
Los resultados del desarrollo de este proyecto, así como las principales conclusiones han gi-
rado en torno a dos aspectos: 1 - la definición de criterio de flujo de los procesos y 2 - el análi-
sis y elección del BPMS.
Los movimientos sobre los expedientes se generan cada que vez que un participante com-
pleta una actividad, quedando registrada la información tanto del movimiento como de la infor-
mación adjunta al expediente. También se actualiza el estado del expediente que coincidirá con
el resultante de la operación efectuada.
5
Gobierno electrónico https://es.wikipedia.org/wiki/Gobierno_electr%C3%B3nico
En relación a las pautas, acordadas con la organización que se debían tener en cuenta en la
selección se encuentran:
Editor de formularios Bonita Studio (Bonita Web Appli- No tiene un editor de formularios. Sí
cation Builder) un plugin con JBPM Form Builder.
Integración para la adminis- Más de 100 conectores integra- Se deben construir todos los conec-
tración de contenidos dos (ERP, CRM, ECM, entre tores.
otros) y la posibilidad de crear los
propios con Bonita Studio. API
Java y Rest
La solución a describir fue implementada para una Caja Profesional de la provincia de Bue-
nos Aires, la cual entre sus diferentes beneficios otorga préstamos a sus afiliados, beneficiarios
y empleados. Dicha Caja no poseía aplicaciones modernas tanto para la gestión de sus trámi-
tes en general, como así tampoco en particular para los préstamos. El trabajo, entonces, inclu-
yó no solamente el desarrollo de una solución tecnológica para el circuito de otorgamiento de
préstamos, sino también aspectos de integración vinculados con aplicaciones ya existentes en
la organización y que debían ser incluidas en el desarrollo propuesto.
Objetivo
El objetivo del proyecto fue definir e implementar una arquitectura para el ambiente de desa-
rrollo, prueba y producción, con componentes de software libre, integrado principalmente por un
BPMS y utilizando como repositorio la base de datos Oracle de dicha Caja Profesional, acce-
diendo a la misma a través de servicios de integración.
Asimismo, se realizó la ingeniería de tres procesos seleccionados, su posterior desarrollo en
el BPMS y la implementación de los mismos en el ámbito de la Caja.
En este libro se describe el resultado del diseño y desarrollo de uno de los procesos se-
leccionados.
Alcances
Los alcances que se plantearon para el proyecto fueron los de seleccionar una herramienta
BPMS de software libre, que mejor se adapte para resolver los problemas de la Caja y particu-
larmente de los tres procesos objeto del proyecto.
Ingreso de solicitud
El afiliado se presenta en una delegación o ingresa por el sitio oficial de la Caja y completa
una solicitud indicando una serie de datos obligatorios. El sistema evalúa si la persona reúne
los requisitos de aptitud para el mismo y en caso contrario lo informa. Se presenta toda la do-
cumentación respaldatoria del solicitante, así como la requerida por el tipo de préstamo selec-
cionado y se avanza.
Control de la solicitud
Varias oficinas internas de la Caja realizan una serie de controles pertinentes sobre el afilia-
do y la documentación presentada, de manera de detectar algún tipo de inconveniente. Pueden
ocurrir una serie de interacciones entre ambos hasta que dichos requerimientos se cumplimen-
ten de manera completa. Una vez finalizados todos los pedidos, se completan los análisis.
Los productos de software que se consideraron para el presente proyecto son todos Open
Source, permitiendo de esta manera a la Caja reducir los costos en el licenciamiento de softwa-
re, así como su apertura hacia estándares aceptados en el mercado.
Se consideraron en un principio tres entornos, uno para desarrollo y pruebas primarias, otro
para test y otro finalmente para producción. En cada uno de estos se reprodujo de manera
exacta la misma arquitectura, integrada formalmente por los siguientes productos:
Servicios
Los servicios fueron integrados en varias APIs, de las cuales podemos distinguir:
1. API de servicios de la Caja: dicha institución posee una BD Oracle de una versión anti-
gua, que si bien ha demostrado una amplia robustez presenta el inconveniente de no
tener capacidad para ser accedida de manera estándar por los lenguajes actuales de
programación (se necesitan librerías muy específicas y discontinuadas). Por lo cual se
desarrolló una capa de servicios implementados en Java con REST para permitir el ac-
ceso a distintas funcionalidades provistas por aplicaciones legacy de la institución rela-
cionadas con la BD. Esta visión por servicios permitió por un lado acceder a los datos y
funcionalidades, así como independizar a las aplicaciones consumidoras de la versión
de la BD utilizada, permitiendo una portabilidad necesaria para migraciones futuras.
2. API de servicios del proceso: los servicios que el proceso necesita consumir (formula-
rios web, consultas, entre otros) fueron implementados en PHP con Angular. Todo esto
fue desplegado en un servidor de aplicaciones Apache.
3. API de servicios de Bonita: el BPMS presenta una API REST para acceder a cada una
de sus funcionalidades. Por razones de usabilidad, se construyó un portal de acceso
para los usuarios, de manera de personalizar los menúes y accesos sin depender de la
consola provista por el BPMS. De esta manera, se construyó una capa de servicios que
acceden a dicha API Rest permitiendo tanto al portal como a los servicios PHP acceder
a la funcionalidad necesaria del BPMS.
Servidor de aplicaciones
Se optó por un servidor Apache para aplicaciones web dentro del cual fueron desplegadas
las API desarrolladas y el portal de acceso de los usuarios.
Gestor Documental
Se seleccionó Alfresco como servidor de archivos. Este gestor posee una API Rest que permi-
te la gestión de cada uno de sus componentes, otorgando de esta manera a los servicios del
proceso la capacidad de gestionar el expediente electrónico junto con toda su documentación.
Este proyecto resultó un gran aprendizaje, no sólo desde el aspecto técnico y tecnológico
propiamente, debido a la implementación completa de una capa de servicios que permitieran
acceder a una base de datos propietaria y de versión antigua, sino también desde el punto de
vista profesional sobre la gestión del proyecto y de las contrapartes involucradas.
Desde el punto de vista tecnológico, el proyecto introdujo en la Caja una serie de mejoras:
las dentro del circuito, no había una implementación clara y controlada de un proceso
que permitiera efectuar una gestión digital de dicho trámite, así como de su documen-
tación. Mediante el presente proyecto la Caja logró formalizar por primera vez dentro de
un entorno actualizado y normalizado uno de sus circuitos de trámite.
2. Manejo de la documentación del trámite mediante un gestor documental: se permitió
digitalizar la documentación propia del circuito, y acceder a la misma desde cualquiera
de los puntos de acceso del proceso.
3. Se implementó por primera vez en la Caja el control de admisibilidad para los distintos
tipos de préstamo, cuestión que era realizada de manera manual por los empleados de
la Caja a partir de reportes y archivos Excel.
Debemos notar también que este tipo de proyectos, donde no sólo se implementa una inno-
vación tecnológica sino que se accionan mecanismos de renovación en el devenir cotidiano del
trabajo de la organización, muchas veces generan gran resistencia interna. Los usuarios se
resisten a la incorporación de nuevos hábitos ya que no solamente creen ver incrementada su
labor cotidiana por los nuevos sistemas, sino que a su vez se resisten a la incorporación de
nuevos paradigmas y buenas prácticas en pos de conservar tradiciones.
Es en este sentido donde se debe hacer un hincapié fundamental en el alineamiento de las
organizaciones con sus objetivos reales, más que con sus resultados. Muchas veces los resul-
tados diarios reflejan una lejanía con objetivos tales como la modernización, la despapeliza-
ción, la gestión ordenada de los procesos internos, entre otros objetivos fundamentales. Seguir
defendiendo internamente los paradigmas tradicionales sólo genera fricción con estas nuevas
tendencias, y es allí donde se nota la necesidad de liderazgos claros, que conduzcan a alinear
las acciones reales de la organización con sus objetivos.
Referencias
Kirchmer, M. (2017). Business process management: what is it and why do you need it? In High
Performance Through Business Process Management (pp. 1-28). Springer, Cham.
Magic Quadrant for Intelligent Business Process Management Suites. (2019
https://www.gartner.com/en/documents/3899484/magic-quadrant-for-intelligent-business-
process-manageme
Mayer, Richard J., et al. (1992). IDEF Family of Methods for Concurrent Engineering and Busi-
ness Reengineering Applications. Knowledge-Based Systems, Inc.
Morgenthal JP (2001). Enterprise Application Integration with XML and Java. Prentice Hall. 1-
86. ISBN 0-13-085135-3.
Oracle Whitepaper (2007). SOA Governance: Framework and Best Practices.
Orquestación de Servicios BPEL (2012) http://www.jtech.ua.es/j2ee/publico/servc-web-2012-
13/sesion03-apuntes.html (Abril 2020)
Rodríguez, A. S., Bazan, P., & Díaz, F. J. (2015). Características funcionales avanzadas de los
BPMS: análisis comparativo de herramientas. In XXI Congreso Argentino de Ciencias de la
Computación
Rummler, G. A., & Brache, A. P. (1995). Improving performance. San Francisco: Jossey-Bass.
Schriber, T. J. (1969). Fundamentals of flowcharting. John Wiley & Sons, Inc.
Scott McKorkle. (2007). Model-Driven SOA. Achieve Higher Productivity Gains throughout the
Design Process. Telelogic White Paper.
Sheina Dana. (2008). Realising the promise of SOA and BPM. Ovum. SearchCIO.
TEC – Technology Evaluations Center https://www3.technologyevaluation.com/store/software-
evaluation-report/business-process-management-bpm-software-evaluation-report.html (al
26/10/2020)
The Forrester Wave: BPM Suites
https://www.forrester.com/report/The+Forrester+Wave+BPM+Suites+Q1+2013/-/E-
RES88581. 2013
Unified Modeling Language (UML), Version 2.5.1 OMG https://www.omg.org/spec/UML. 2019.
(al 23/08/2019)
Von Rosing, M., Von Scheel, H., & Scheer, A. W. (2014). The complete business process
handbook: body of knowledge from process modeling to BPM (Vol. 1). Morgan Kaufmann.
Weske Mathias (2008). Business Process Management: Concepts, Languages, Architectures.
Springer. 3-67. ISBN 978-3-540-73521-2.
Yourdon, E., & De Marco, T. (1988). Structured analysis. Prentice Hall.
Zairi, M., & Sinclair, D. (1995). Business process re-engineering and process management: a
survey of current practice and future trends in integrated management. Business Process
Re-engineering & Management Journal, 1(1), 8-30.