See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/256198812

Consideraciones para proyectos de implementación de procesos utilizando

plataformas BPMS

Conference Paper · November 2012

CITATIONS READS

0 1,819

2 authors:

Diego Moya Bernhard Hitpass

Universidad Técnica Federico Santa María Universidad Técnica Federico Santa María
2 PUBLICATIONS   0 CITATIONS    31 PUBLICATIONS   57 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MOPAIOSIP Ontological and metamodelling support for collaborative business processes in a Process-Aware Inter-organizational Service-Based interoperability platform for
e-government View project

BaaS-SE Blockchain as a Service for Stock Exchange View project

All content following this page was uploaded by Bernhard Hitpass on 28 May 2014.

The user has requested enhancement of the downloaded file.

 Consideraciones para proyectos de implementación de procesos utilizando
plataformas BPMS
Diego Moya
Universidad Técnica Federico Santa Marı́a
Departamento de Informática
BPM Center
Santiago, Chile
diego.moya@outlook.com
Abstract—La competitividad y dinamismo del mercado
obliga a las organizaciones a responder y adaptarse frente a
las más variadas necesidades de sus stakeholders. Las múltiples
relaciones y la variedad en modelos de negocio, ha impulsado
a muchas organizaciones a incorporar disciplinas como la
Gestión por Procesos de Negocio (BPM), con el objetivo de
ser más eficientes, eficaces y ágiles. La consolidación de las
Tecnologı́as de la Información (TI) como agente transformador
y central para la automatización y crecimiento de todas las
organizaciones, ha redefinido muchos modelos de negocio. Las
soluciones para BPM han madurado tanto a nivel de sus
funcionalidades como su presencia en el mercado, sin embargo,
las plataformas BPMS aún no logran posicionarse como la
componente central para el desarrollo e implementación de los
procesos de negocio crı́ticos de las organizaciones. La ausencia
de una guı́a para la ejecución de este tipo de proyectos, ha
limitado la exploración y valorización de estas plataformas,
dejándolas muchas veces asociadas a procesos de caracter
administrativos y/o fuera del core del negocio. Comprender los
desafı́os de implementar procesos con una plataforma BPMS
considerando aspectos de gestión de proyectos, es el objetivo
de este trabajo, entregando un conjunto de recomendaciones
que permitan una implementación correcta, más ágil y segura.
Keywords-Business Process Management (BPM); Project
Management (PM); Plataformas BPMS;
I. I NTRODUCCI ÓN
A. Motivación
Cada dı́a son más las organizaciones que optan por
adquirir e incluir plataformas BPMS en sus eco-sistemas
de soluciones tecnológicas. A pesar de las funcionalidades
avanzadas que estas poseen, existen desafı́os importantes
asociados a cómo y quién las utilizará. En el caso de las
plataformas BPMS, el objetivo es brindar a la organización
la flexibilidad y rapidez en la implementación o modificación
de los procesos de negocio. ¿Cuáles son las consideraciones
que deben ser analizadas para asegurar una implementación
correcta, más ágil y segura?, es la pregunta central de este
paper para las principales dimensiones que todo proyecto
debe abarcar: costos, tiempos (plazos), calidad y la gestión
de riesgos.
Bernhard Hitpass
Universidad Técnica Federico Santa Marı́a
Departamento de Informática
BPM Center
Santiago, Chile
bernhard.hitpass@usm.cl
Al igual que todo proyecto de desarrollo de software,
no sólo de la capacidad técnica de los programadores
dependerá el éxito de los proyectos. Diversos autores [8]
dedicados al estudio de BPM han publicado modelos y
patrones sugeridos para implantar BPM como disciplina de
gestión, sin embargo, hasta la fecha no existe un modelo de
referencia que se haga cargo de guiar la implementación
de sistemas utilizando plataformas BPMS, de una forma
integrada con las otras dimensiones de las iniciativas de
la Gestión por Procesos, análisis (BPA: Business Process
Analysis) y monitoreo y control (Process Controlling).
La contribución de este paper, radica en la formalización
de un conjunto de recomendaciones asociadas a la gestión
de proyectos de implementación de sistemas utilizando
plataformas BPMS, que permiten anticipar los riesgos y
amenazas asociadas a la gestión de proyectos y a la adopción
de esta nueva forma de desarrollar aplicaciones.
B. Contextualización
La evolución de las tecnologı́as y la globalización ha
repercutido en la forma de hacer negocios. La aparición de
internet como la principal red de comunicación y difusión
de información ha impulsado a las empresas a replantearse
sus estructuras y procesos de negocio. Para enfrentar el
escenario antes relatado, muchas disciplinas han emergido
para apoyar la gestión de las organizaciones, cada una de
ellas asociadas a un objetivo particular de su época, por
ejemplo: en la década de 1980 el foco fue la calidad, en
1990 fue la globalización y desde el año 2000 en adelante
ha sido la velocidad [2]. Tanto la industria como la academia
han reconocido que hoy en dı́a son dos las principales
disciplinas que permiten a las organizaciones aumentar su
rentabilidad, estas son: la Gestión de Proyectos (PM - Project
Management) y la Gestión de Procesos de Negocio (BPM -
Business Process Management).
Desde la consolidación de BPM en las organizaciones,
muchas herramientas tecnológicas han emergido con el
propósito de disminuir la brecha que existe entre los re-
querimientos del negocio y las funcionalidades que son
implementadas por los departamentos de Tecnologı́as de la
Información (TI) [1]. En este ámbito las tecnologı́as de
BPM se han agrupado bajo la denominación de BPMS
(BPM suites o systems), las cuales permiten tanto la im-
plementación como el monitoreo y control de los procesos
de negocio.
Qué es una plataforma BPMS y qué la hace distinta
a los frameworks de desarrollo de software tradicionales,
son las primeras interrogantes que deben ser clarificadas.
Dependiendo de la fuente, es posible hallar diversas defini-
ciones y propuestas del alcance que una plataforma BPMS
debiese tener, dado lo anterior, fue necesario homologar y es-
tandarizar su definición, para lo cual se considerará lo escrito
en [10], “BPMS es la infraestructura técnica para gestión
de procesos que extiende el modelado y ejecución de los
sistemas de workflow con potencialidades para el monitoreo
y control en lı́nea de procesos”. De forma complementaria,
vale la pena recalcar las diferencias que otros autores [9]
les atribuyen versus los tı́picos sistemas de workflow, ellos
indican que la gran potencialidad que deben desarrollar los
BPMS es la capacidad de diagnóstico de los procesos de
negocio, y que solo esto permitirá su diferenciación de las
tecnologı́as y sistemas de workflow presentes hace décadas
en la industria tecnológica.
A pesar del avance en las tecnologı́as asociadas a BPM,
las prácticas en gestión de proyectos y los niveles de
madurez de las organizaciones impiden o limitan el éxito
esperado. Si a lo anterior se suma que existen diversos mode-
los de operación y organización al interior de las empresas,
y que los proveedores tecnológicos venden soluciones que
no siempre se adecuan a las necesidades prioritarias de
los negocios, se logra mantener y/o aumentar el porcentaje
histórico de fracasos en la implementación de proyectos TI,
el cual alcanza un escaso 20-30% [6] de éxito. En [15], los
autores indican que ”Construir sistemas es difı́cil y cada
dı́a está aumentando su complejidad. Muchos proyectos son
cancelados y muchos otros no otorgan el valor de negocio
esperado. Estadı́sticamente, la industria de las TI no han
mejorado a pesar de los esfuerzos por hacer de esta más
confiable y predictiva.”
C. Gestión de proyectos de implementación y BPM
Hoy en dı́a muchas organizaciones continúan utilizando
las clásicas metodologı́as vinculadas a la Ingenierı́a de
Software para la gestión de proyectos de implementación de
procesos utilizando las plataformas BPMS, sin embargo ex-
isten muchas diferencias, una de las principales radica en que
un esquema puro de BPM no requerirı́a de programadores
para modificar un sistema que soporte un proceso de negocio
[17]. Para entender qué es un proyecto de implementación
de procesos usando BPMS se debe comprender cuál es el
ciclo de vida de un proceso y acotar el alcance que fue
utilizado. El modelo más común en la gestión de proyectos
de desarrollo de software, es el waterfall lifecycle, que define
las siguientes etapas:
• Especificación y análisis de requerimientos
• Diseño de la arquitectura
• Implementación e integración
• Verificación
• Operación y mantención
El fundamento central de este enfoque es la rigidez que
existe para pasar de una etapa a la siguiente. Las ventajas
están relacionadas a que el perı́odo de análisis por lo
general es extenso, lo cual permite identificar con claridad
los alcances del sistema, evitando cambios posteriores. La
experiencia ha demostrado que el costo de modificaciones
es infinitamente menor al inicio de un proyecto que en
etapas de construcción y/o explotación. Dado lo anterior, este
tipo de enfoque es sumamente recomendable para proyectos
que implementarán procesos estables en el tiempo y que
no requieren muchos cambios y/o para proyectos en que la
aparición de algún defecto sea tan grave como para impactar
el éxito del mismo. Otra caracterı́stica positiva es que para
nuevos integrantes siempre existirá extensa documentación.
A pesar que lo anterior podrı́a hacer suponer que el ciclo
de vida de proyectos en cascadas es una excelente opción,
se debe prevenir respecto a sus desventajas. Comúnmente
los usuarios al momento de ver un sistema desearán cam-
bios y nuevas funcionalidades, principalmente debido a la
brecha de tiempo entre que definió lo que deseaba versus
lo que realmente se construyó. Desde la perspectiva de la
implementación misma, los desarrolladores suelen descubrir
al momento de terminar de construir que ciertas decisiones
pudiesen haber sido optimizadas, por lo que si no existen
nuevas fases, el costo del cambio será superior. La mayor
consideración es que los procesos de negocio son dinámicos,
debido a su relación directa con los clientes, por lo cual
tanto modificaciones en la economı́a como en leyes y regu-
laciones, pudiesen impactar en modificaciones relevantes, a
los cuales las organizaciones deben responder en el menor
tiempo posible para mantener su posición en el mercado y/o
para cumplir con normativas.
Como alternativa a la metodologı́a en cascada han surgido
distintos modelos, tales como: iterativo, incremental y ágiles
[12] [5]. En el caso del enfoque ágil, un principio básico
es la entrega incremental de software estable, integrado y
certificado a los usuarios, de modo de obtener feedback
que pueda generar nuevos requerimiento o cambios en ellos.
Las organizaciones que han madurado en los métodos ágiles
asignan gran relevancia al proceso de captura de requerim-
ientos y la estimación de impacto frente a las solicitudes de
cambio. En lo que refiere a testing del software desarrollado,
es recurrente el uso de Test-Driven Development (TDD)
[4], el cual define relatos de usuarios (User Stories) para
validar y comprobar que los requerimientos del sistema estén
siendo cumplidos en cada iteración. La literatura también
ha comenzado a estudiar y discutir cómo la agilidad es
lograda en el contexto de BPM, indicando que la concepción
actual de automatización de procesos operacionales no está
directamente relacionada con la agilidad de la organización,
puesto que esta sólo es alcanzada a través de ciclos rápidos
de creación de conocimiento y la aplicación del mismo en
la modificación de los procesos, transformando muchos de
los procesos de negocio en un conjunto de actividades no-
estructuradas [11].
Quizás el error más recurrente entre las organizaciones en
lo que respecta a las nuevas tecnologı́as es su adquisición
previa a un análisis profundo de los beneficios y desafı́os
que esto traerá a cada compañı́a. El caso de las plataformas
BPMS no es distinto, tal y como se señala en [18], dicho
autor indica que la compra previa de software como una
de las peores prácticas en lo que respecto a proyectos
BPM/SOA se refiere. El adquirir la tecnologı́a inicialmente
no permite maximizar su rentabilidad, dado que las inicia-
tivas y proyectos tratarán de explotar las potencialidades de
la misma en lugar de buscar la herramienta o solución que
mejor se adapte a la estrategia y necesidades del negocio.
II. A N ÁLISIS DEL CONTEXTO
A. Clasificación de proyectos BPM
La gran variedad de enfoques e iniciativas asociadas a
BPM, hacen necesarias distintas configuraciones y estruc-
turas organizacionales, tanto para su gestión y ejecución.
Lo anterior, genera distintos esquemas de colaboración y tra-
bajo, algunas pueden optar por equipos internos o externos,
contar o no con asesores y especialistas, sub-contratación
de personal experto por un plazo definido para adquirir el
know-how o simplemente, como un soporte permanente.
El desafı́o inicial en toda organización involucrada en una
iniciativa BPM, consta en la identificación del alcance y
complejidad, y ası́ ser capaz de estimar y definir el plan que
permita conseguir los recursos necesarios para su ejecución,
el tamaño de la organización y de sus procesos, tal como se
menciona en [3], es un factor que incide directamente en la
forma de comprender la iniciativa a desarrollar.
Respecto a la gestión de proyectos BPM, los escollos y
complicaciones más recurrentes son:
• Insuficiente definición del alcance del proyecto
• Falta de competencias en BPM de las personas que
participan en éste
• Inadecuada gestión de riesgos
• Error al identificar y definir supuestos
• Falta de preparación, experiencia y formación de lı́deres
de proyectos
• Ausencia de metodologı́as y estrategias globales para
abordar el proceso a implementar
• Ausencia de un plan de comunicación efectiva que
involucre todos los niveles de la organización
Complementariamente a lo antes mencionado, existen
factores que influyen directamente en la forma que debiese
ser concebido y gestionado un proyecto BPM, entre éstos
están:
• BPM en sı́ debe estar basada en una visión global
de colaboración de cada organización, tanto en su di-
mensión interna como externa, permitiendo identificar
cómo los procesos de estas pueden gatillar y alcanzar
los beneficios deseados mediante el apalancamiento y
mejora continua de sus procesos [13].
• Documentación incompleta de modelos de procesos
o inadecuada lectura e interpretación de los mismos,
sin una perspectiva global, impiden obtener el máximo
provecho de BPM. Los procesos ocultan ineficiencias,
puesto que pocas personas conocen cómo realmente
operan, generando sobre producción, tiempos de espera
superiores a los deseados, errónea gestión de inventar-
ios, entre otros factores [9].
• La falsa creencia consistente en asumir que todos
los procesos deben ser ejecutados internamente y no
mirar ni adoptar alternativas al quehacer actual de cada
organización, inyectando ideas nuevas y cambios en los
esquemas tradicionales, podrı́a impedir que una cultura
orientada al mejoramiento continuo en BPM pueda
nacer y madurar.
Con la finalidad de recabar la situación actual en diversas
empresas, a comienzos de año, el centro especializado en
BPM de la Universidad Técnica Federico Santa Marı́a, BPM
Center, realizó una encuesta para conocer el estado de BPM
en el mercado local. Los resultados, sobre una muestra
de 20 organizaciones distintas, entregó valiosa información
referida al estado actual y madurez de BPM.
Figure 1. Encuesta BPM - Tipos de iniciativas en el mercado local
El primer hallazgo relevante, es que un 21% de organi-
zaciones declara estar realizando alguna iniciativa de im-
plementación de procesos utilizando una plataforma BPMS,
sin embargo misma proporción indica que cuentan con
iniciativas de implementación de procesos sin la utilización
de plataformas BPMS. Dicho similitud induce a cuestionar
¿por qué existe un número importante de organizaciones que
no optan por plataformas BPM?, ¿Existe real conocimientos
de dichas plataformas y sus ventajas?, ¿Existen las compe-
tencias suficientes para liderar dichos proyectos?. Respecto
a la complejidad de lo proyectos de implementación BPM,
la percepción de ellos es que son más simples que aquellos
que son gestionados bajo las metodologı́as tradicionales de
desarrollo de software.
Figure 2. Encuesta BPM - Elementos claves gestión proyectos BPM
Al igual que en resultados de otros estudios acerca de
la gestión de proyectos, el atributo con mayor ponderación
para el éxito de un proyecto BPM es: Obtener y contar con
el respaldo de la alta dirección. Una valoración relevante
obtiene Disponer con proveedores con experiencia, lo ante-
rior sugiere que gran parte de las organizaciones cuenta con
apoyo externo para la gestión de estas iniciativas.
B. Desarrollo
El core definido para la elaboración y construcción del
Modelo de Referencia para proyectos BPM se basa en la
categorización para iniciativas BPM expuestas por Hitpass
en [7]. Lo anterior presenta una división de proyectos BPM
en dos grandes bloques:
• BPM Governance
• BPM Operacional
Al modelo allı́ expuesto, se recomienda incluir una tercera
agrupación, asociada a Proyectos de Implementación de
plataformas base. Este grupo de proyectos es transversal e
independiente de los proyectos que decidan ejecutarse, por
ejemplo, un proyecto de análisis y re-diseño de procesos. La
siguiente figura muestra la agrupación de proyectos BPM
sugerida por los autores:
Dado el alcance de este trabajo, sólo se detallan los
proyectos en el ámbito de BPM Operacional. En este sub-
grupo se han definido dos tipos de proyectos:
1) Implementación de flujos:
• Sistemas legados para soporte BPM: este tipo de
proyecto tiene por finalidad brindar las interfaces nece-
sarias para integrarse con los motores de workflow que
traen las plataformas BPMS. Las grandes corporaciones
cuentan con sistemas robustos y complejos, basados
comúnmente en tecnologı́as no orientadas a servicios,
por lo cual este tipo de iniciativas de modernización
Figure 3. Tipos Proyectos BPM
es fundamental para mantener controlado el riesgo tec-
nológico y la continuidad de negocio. Es común incluir
algún proyecto de SOA (Service Oriented Architecture)
debido a la necesidad (ventaja) de contar con una
arquitectura normada y estandarizada que facilite la
integración de y entre aplicaciones.
• Nuevos procesos: este tipo de proyecto es en sı́ el
menos riesgoso, dado que la continuidad de negocio
no implica una amenaza. El proceso de negocio pu-
diese ya existir pero sin ejecución automática ni semi-
automatizada de las tareas que componen su flujo.
• Modificación de flujos: este tipo de iniciativas es la
más recurrente puesto que involucra la modificación
permanente y constante de aquellos procesos que ya
cuentan, total o parcialmente, con soporte tecnológico.
No siempre será a través de una suite BPMS, pero la
implementación a través de éstas provee las potenciali-
dades bases: control del flujo, integraciones a través de
servicios, derivaciones y escalamientos, indicadores de
tiempos de ciclo, entre otras.
2) Monitoreo y control:
• Estos proyectos consisten en la elaboración de herra-
mientas de control y monitoreo de indicadores claves de
desempeño del negocio, mediante la supervisión de los
tiempos, uso de recursos, identificación de cuellos de
botella y complicaciones que pueden estar ocurriendo
durante la ejecución de una instancia de un proceso.
La realidad de muchas organizaciones consta en el
análisis post-mortem de la información, mediante la
utilización de planillas de cálculo MS Excel y/o MS
Access, en las cuales se realizan todo tipo de cruce de
información, tales como tablas dinámicas, entre otras.
En el ámbito de proyectos de BPM Operacional, las
herramientas de control y monitoreo deben permitir al
dueño del proceso contar con información real y en
 lı́nea del estado de las distintas instancias de cada uno
de los procesos bajo su control, pertimiéndole mejorar
su proceso de toma de decisiones.
• Otro tipo de iniciativas orientadas al control y moni-
toreo son los cubos de información presentes en los
data warehouse de las compañı́as, sobre dichas fuentes
de datos se aplican diversas técnicas para extraer infor-
mación relevante y, comúnmente, consolidada desde los
sistemas transaccionales. En el ámbito de BPM, la exis-
tencia de herramientas para Business Intelligence (BI),
es un complemento que permite recabar información
una vez que las instancias ya hayan finalizado su flujo,
dicho de otra forma, corresponderá al análisis ex-post
del proceso.
Acorde a [7], un proyecto del grupo anterior está in-
serto en la capa de BPE (Business Process Execution),
la cual asume la existencia un modelo operacional de
proceso que permitirá a las áreas tecnológicas, a cargo de
la implementación, la configuración del proceso sobre una
plataforma BPMS. La capa BPE contempla las siguientes
etapas:
1) Recepción del modelo operacional desde la capa de
negocio
2) Diseño de arquitectura, de workflow y capa de pre-
sentación
3) Configuración y desarrollo de la solución BPMS
4) Fase de pruebas y puesta en marcha
5) Capacitación
6) Traspaso a producción
Figure 4. Capa BPE: Business Process Execution
Este modelo asume que una vez recibido el modelo de
procesos operacional, se inicia la etapa de diseño, donde se
definen cuáles actividades serán manuales, semi-automáticas
o automáticas, además de identificar las métricas e indi-
cadores deseadas. A lo anterior, se añade la confección del
diseño fı́sico, analizando la plataforma TI que soportará el
proceso y finalmente se define un plan de implementación.
III. R ECOMENDACIONES EN PROYECTOS DE
IMPLEMENTACI ÓN CON BPMS
Las recomendaciones han sido identificadas gracias a
la experiencia adquirida tanto en la implementación como
gestión de proyectos con diversas plataformas BPMS, es-
pecialmente Oracle BPMS 11g e Intalio—BPMS. Dichos
proyectos han sido implementados en el sector público y
privado, en algunos de ellos dentro del marco de un proyecto
global de adopción de BPM como disciplina de gestión
corporativa, y también, en casos en que algunas institu-
ciones han deseado conocer las funcionalidades de este
tipo de soluciones. Las buenas prácticas (recomendaciones)
aquı́ mencionadas, son divididas en dos grupos, el primero
asociado a las actividades previas a la implementación y
configuración misma de los procesos sobre la plataforma
BPMS, y la segunda respecto a las particularidades propias
de la implementación y los resguardos necesarios para que
el proceso realmente permita y facilite el establecimiento de
BPM como una disciplina que agregue valor a la compañı́a
y no transformar la plataforma BPMS en una nueva her-
ramienta de desarrollo de software.
A. Previas a la implementación
• Identificación de procesos candidatos a ser soportados
sobre la plataforma BPMS
• Selección y evaluación de proveedores para imple-
mentación utilizando suite BPMS
B. Durante la implementación de procesos
• Identificar lo que se requiere y desea controlar
Sin una adecuada y temprana identificación de los
elementos a medir es difı́cil elaborar un modelo de
proceso que permita entregar el conjunto de indicadores
base para los reportes y elementos de control sobre las
instancias. Una práctica reiterativa entre los analistas de
procesos es que se dedican a confeccionar un modelo
de proceso (diagrama) basado en el control del flujo de
actividades, postergando el levantamiento y definición
de indicadores. Levantar en forma conjunta con el
analista de negocio y el lı́der del proyecto por parte
de TI, y previamente a la elaboración del modelo de
proceso a nivel técnico, el conjunto de indicadores y
reportes que debiesen ser parte del flujo a implementar.
• Aunar distintas excepciones de un proceso en un
único modelo
Suele suceder que las áreas o unidades de procesos
se dedican prolijamente a definir modelos de procesos
con amplia documentación. Sin embargo, vislumbrar un
proceso reusable para implementación de un sistema
informático difiere tanto en el grado de complejidad
como en los niveles de abstracción de los modelos
que se utilizan para capturar la lógica de sistemas e
integraciones. Cuando un proceso posea alta comple-
jidad y baja estructuración del flujo, es recomendable
abstraer su lógica y concebir una versión simplificada
que permita al usuario final operar el sistema y ver
como ir mejorándolo paulatinamente, a través de nuevas
iteraciones.
• Lograr una rápida implementación
Todo nuevo sistema genera expectativas y anhelos en
los usuarios de negocio, ya que esperan que dicho
desarrollo les facilite las tareas diarias y operativas
 de sus labores. Es importante recalcar que muchos
proyectos fracasan por incorporar niveles de detalle
y complejidad aspirando a revertir o mejorar todas
las debilidades de los procesos actuales. En el marco
de proyectos con BPMS la recomendación es dividir
el alcance en el flujo principal del proceso para una
primera iteración y sobre dicha versión ir añadiendo
las funcionalidades y particularidades requeridas.
• Analizar y definir mejoras deseables pero no ur-
gentes
En todo proyecto informático es normal que los usua-
rios soliciten modificaciones a las especificaciones ini-
ciales y/o recuerden funcionalidades no identificadas
al inicio del proyecto. Estas solicitudes comúnmente
son recibidas durante la ejecución de las fases de
construcción y pruebas. En el caso de los proyectos
BPM, es recomendable indicar a los usuarios que estos
son incrementales, basados en la mejora continua, por
lo cual no conciban estos hechos como algo negativo.
Sin embargo al igual que todo proyecto, estas iniciativas
deben tener un inicio y un término, por lo cual lo
sugerido es identificar las mejoras y documentarlas, sin
embargo explicar que su implementación se realizará en
una próxima versión del proceso. Lo anterior, permite
inculcar un estilo de trabajo orientado en la mejora
continua, basado en un ciclo de vida para procesos que
incluya: análisis, diseño e implementación, y, luego, el
monitoreo y optimización como mejora continua.
• No forzar la adaptación de metodologı́as tradi-
cionales de ingenierı́a de software
Concebir un proyecto de implementación utilizando
una suite BPMS con las mismas prácticas no permite
obtener el mayor beneficio posible. ¿Por qué? La re-
spuesta es simple, pero no siempre evidente. En la
ingenierı́a de software muchas veces se utiliza la fase
de análisis para levantar la situación actual y vislumbrar
recién las mejoras (funcionalidades) que el sistema
deberá soportar.
En el caso de BPM, se asume un modelo ya mejo-
rado y que incluye al menos el flujo de control y la
definición de pantallas del sistema. La composición a
nivel de roles también sufre modificaciones [16], pues
es recomendado contar con profesionales especialistas
con el perfil de: Analista de Negocio, Arquitecto de Ne-
gocio, Jefe de Proyectos, Arquitectos de la Solución y,
finalmente, los implementadores y encargados de cali-
dad. Lo anterior permitirá unificar el diseño del proceso
tanto a las capas de Negocio superiores (Arquitectura
Empresarial) como elaborar un diseño reutilizable y que
cumpla con los patrones de diseño de la arquitectura en
las soluciones de la organización.
• El modelo de procesos es y debe ser el diagrama
principal para comprender el sistema a construir
Con la aparición de plataformas BPMS capaces de eje-
cutar directamente flujos de procesos en BPMN 2.0, la
confección de artefactos de software complementario,
tales como diagramas UML, pudiese o no ser requerida.
La práctica ha permitido validar que solo un diagrama
general de casos de usos es suficiente para permitir
la definición inicial de requerimientos funcionales que
deberán ser contemplados en el proceso. La simplicidad
de BPMN permite validar con los propios usuarios
de negocio la lógica del proceso y a la vez ser el
documento inicial de construcción (implementación).
Hay que advertir que la elaboración de un proyecto
requiere contar con servicios capaces de abstraer la
complejidad de las operaciones CRUD mı́nimas que
relacionen los datos del proceso.
• Evitar mezclar roles de administración de sistemas
en los modelos de procesos
En la implementación de sistemas suele convivir la
lógica misma de la aplicación y las funcionalidades que
permiten la administración de esta, tales como: creación
de usuarios, asignación de perfiles, modificación de
información de contacto, configuración de parámetros,
entre otras. En la práctica, la administración de sistemas
es gestionada por las áreas TI, lo anterior impide una
entrega total de los sistemas, generando una dependen-
cia natural con las áreas técnicas.
La correcta implementación de un proceso sobre BPMS
debe distinguir dos capas mı́nimas: administración de
usuarios sobre BPMS y administración de usuarios
del proceso. El primer tipo de administración debe
focalizarse en la habilitación de credenciales y perfiles
asociados a los usuarios de uno o más de los procesos
disponibles en la suite. El segundo tipo dice relación
con la gestión de roles y usuarios de un proceso en
particular, lo que incluye las relaciones de dependencia
para la correcta ejecución de las tareas vinculadas en
el proceso.
• Separar y parametrizar reglas de negocio
Las reglas de negocio debiesen ser modificables sin
necesidad de alterar la versión del proceso en pro-
ducción. La recomendación incluye utilizar motor de
reglas de negocio o implementar una componente inde-
pendiente desde la perspectiva tecnológica, que pueda
ser consultado mediante la invocación de un servicio
en la implementación técnica del flujo del proceso.
Si las reglas de negocio se entrelazan con las reglas
del flujo del proceso, cada modificación, por ejemplo
en los montos máximos para un proceso de aprobación
crediticia, obligará a los usuarios finales a solicitar
una modificación sobre el flujo de proceso al área de
procesos, impactando negativamente en el atributo de
agilidad esperado para BPM.
 IV. VALIDACI ÓN 1) Cumplimiento en plazos: el término y entrega del
sistema fue en la fecha inicialmente comprometida.
La metodologı́a de validación consideró dos casos de
2) Cantidad de re-planificaciones: cuántas veces el
proyectos reales de implementación de procesos. En ambos
proyecto fue replanificado.
casos la decisión de la empresa fue la utilización de una
3) Satisfacción usuaria: percepción del cliente interno
plataforma BPMS para la automatización de estos proce-
respecto al valor entregado al negocio y, complemen-
sos de negocio. Previo a estas iniciativas, la organización
tariamente, si la plataforma le permite contar con
(compañı́a de seguros) contaba con una metodologı́a basada
información para controlar su proceso.
en un conjunto de documentos bases para la gestión y
4) Costo real vs inicial: comparación entre el presupuesto
control de sus proyectos, sin embargo no existı́a un rol
inicial estimado y el real.
encargado de velar por la correcta aplicación de cada una de
5) Iteraciones etapa de pruebas: cantidad de certifica-
las etapas ni en el contenido de los documentos generados.
ciones por el usuario, permite validar si el requer-
Por ejemplo: un mismo jefe de proyectos asumı́a roles de
imiento inicial fue o no rápidamente entendido e
analista, diseñador, arquitecto y tester. Algunos proyectos
implementado de forma correcta.
eran desarrollados internamente y el resto con empresas
externas. A continuación se presentan los resultados de la com-
paración entre los proyectos:
A. Casos de muestra
Table I
A continuación se explica brevemente el alcance de C OMPARACI ÓN DE PROYECTOS
cada uno de los procesos de negocio que gatillaron la Cumplimiento Cantidad re- Satisfacción Costo real vs Iteraciones
elaboración de dos proyectos de implementación sobre la plazos [d] planificaciones usuaria inicial etapa
pruebas
de

plataforma BPMS. El primer proyecto no hizo uso de Proyecto 1

las recomendaciones expuestas en este trabajo, fue guiado
bajo la metodologı́a de gestión de proyectos tradicional
de la compañı́a, orientada a desarrollo de software sobre
tecnologı́as Cobol y .NET. En el segundo caso, el proyecto
fue orientado desde una perspectiva de gestión de proce-
sos, aplicándose las recomendaciones desde el proceso de
selección de proveedores hasta su finalización, que incluyó
un ciclo de mantenciones periódicas que permiten ajustar el
proceso de negocio a los cambios del negocio.
1) Proyecto 1:: El alcance del proceso es: Controlar la
gestión de los estudios de abogados que prestan apoyo
a la compañı́a en las tareas asociadas a la recuperación
de dineros vinculados a siniestros. Desde la perspectiva de
sistema, el requerimiento consistı́a en habilitar un canal web
que permita a cada estudio de abogado enterarse de los casos
asignados, describir los pasos ejecutados y el resultado de
sus acciones.
2) Proyecto 2: El alcance del proceso es: Controlar las
acciones relativas al proceso de liquidación de siniestros de
vehı́culos una vez que se han decretado pérdidas totales, con
foco en la gestión de activos y stock de vehı́culos en casas
de remate. Desde la perspectiva de sistema, el requerimiento
consistı́a en contar con un sistema que permita conocer y
controlar de manera eficiente cada una de las actividades del
proceso de liquidación, concentrando toda la información de
los siniestros y gestionar el stock de vehı́culos.
B. Evaluación y resultados
La comparación y evaluación entre los proyectos fue
realizado tomando en cuenta un subconjunto de elementos
que dan cuenta de los criterios emergentes para la evaluación
de desarrollos de software adaptativos presentados en [14]:
Proyecto 2
±180
±20
5
1
Baja
Alta
+30%
+0%
4
2
V. B ENEFICIOS ESPERADOS
Las recomendaciones base para el modelo de refencia
para proyectos de implementación de procesos en BPMS,
trae consigo un conjunto de beneficios en distintas dimen-
siones, estas corresponden a: Costos, Tiempos, Calidad y en
Gestión de Riesgos. A continuación se presenta una breve
descripción estas:
A. Reducción de costos
• Disminución en la cantidad de iteraciones de revisión
durante la etapa de testing y certificación usuaria,
gracias a una mayor participación y validación con el
usuario/cliente.
• Menor utilización de recursos para la documentación,
gracias a la simplicidad y unificación de la misma a
través del modelo de procesos en su nivel técnico.
B. Ahorro en tiempos
• La identificación de métricas e indicadores, en conjunto
con las reglas de negocio, en una etapa inicial y como
restricción para el inicio de la implementación, evitará
modificaciones posteriores sobre lo desarrollado.
C. Aumento en la calidad
• La inclusión de etapas incrementales de funcionali-
dades sobre el sistema, inicialmente proceso y luego
funciones complementarias, permitirá la realización de
variadas iteraciones de validación, mejorando la calidad
final
 D. Reducción de riesgos
• La identificación de caracterı́sticas propias de los
proyectos de implementación con plataformas BPMS,
disminuirá eventuales riesgos graves para el éxito del
proyecto, por ejemplo: identificación tardı́a de indi-
cadores que obliguen la modificación del flujo de
control del proceso.
VI. C ONCLUSIONES
El paper ha dado cuenta de las prácticas y recomenda-
ciones necesarias para lograr un mejor desempeño durante
las principales etapas de un proyecto de implementación de
procesos sobre una plataforma BPMS. La experiencia y re-
visión de los desafı́os y problemas recurrentes en la Gestión
de Proyectos, en especial, en la industria del desarrollo del
software, permitió corroborar que parte importante de las
complicaciones son reproducibles en proyectos BPM.
Respecto a la implementación de procesos utilizando
suites BPMS fue posible corroborar que un modelo técnico
de procesos de procesos sólo será de valor cuando tenga
contempladas las dimensiones analı́ticas y de gestión re-
queridas. El estudio del mercado local, permitió identificar
un riesgo importante asociada a la asignación y preparación
de proyectos BPMS, estos últimos son comúnmente dele-
gados a jefes de proyectos que no cuentan necesariamente
con la experiencia en los procesos de negocio. Maximizar
el beneficio de la utilización de una plataforma BPMS
dependerá de conocer las potencialidades de la misma,
entendiendo que es un nuevo paradigma que modifica el
clásico proceso de desarrollo de software.
El próximo desafı́o es acoplar las recomendaciones acá
planteadas en un marco de referencia para proyectos de
implementación de procesos, el cual permita que quien
diseñe y ejecute la etapa de BPA, tome en consideración los
elementos base para la futura implementación de procesos,
y ası́ lograr entregar la agilidad, eficiencia y eficacia que la
disciplina BPM promete.
R EFERENCES
[1] Morteza Alaeddini and A. A. Kardan. Using an old technique
in a new technology — A novel method for defining the
scope of ISs in BPM projects. Computers and Information
Technology, 2009. ICCIT ’09. 12th International Conference
on, 2009.
[2] S. Azzopardi. Evolution of project management, August
2011. http://www.projectsmart.co.uk/.
[3] Jörg Bindner and Gunther Mayer-Leixner. Differences in
business process management between global players and
micro enterprises - experiences from practice. In Werner
Schmidt, editor, S-BPM ONE - Learning by Doing - Doing
by Learning, volume 213 of Communications in Computer
and Information Science, pages 256–270. Springer Berlin
Heidelberg, 2011.
View publication stats
[4] A. Fox and D. Patterson. Engineering Long-Lasting Software:
An Agile Approach Using Saas and Cloud Computing, Alpha
Edition. Strawberry Canyon LLC, 2012.
[5] Marı́a Consuelo Franky. Agile management and development
of software projects based on collaborative environments.
SIGSOFT Softw. Eng. Notes, 36(3):1–6, May 2011.
[6] Standish Group. The standish group: The chaos report 2011,
August 2011. http://blog.standishgroup.com.
[7] Bernhard Hitpass. BPM Fundamentos y Conceptos de Imple-
mentación. BPM Center, 2012.
[8] J. Jeston and J. Nelis. Business Process Management:
Practical Guidelines to Successful Implementations. Taylor
& Francis, 2012.
[9] Ryan K. L. Ko. A computer scientist’s introductory guide to
business process management (bpm). Crossroads, 15(4):4:11–
4:18, June 2009.
[10] Michael zur Muehlen Maggie Bin Lai. Information Require-
ments of Process Stakeholders- A Framework to Evaluate Pro-
cess Monitoring and Controlling Applications. ICIS workshop
on Process Management, 2004, 2004.
[11] Olivera Marjanovic. Inside agile processes: A practitioner’s
perspective. In HICSS, pages 1–10, 2009.
[12] E. Mathisen, K. Ellingsen, and T. Fallmyr. Using business
process modelling to reduce the effects of requirements
changes in software projects. In Adaptive Science Technology,
2009. ICAST 2009. 2nd International Conference on, pages
14 –19, jan. 2009.
[13] Bjoern Niehaves and Jorn Henser. Business process manage-
ment beyond boundaries? - a multiple case study exploration
of obstacles to collaborative bpm. In Proceedings of the 2011
44th Hawaii International Conference on System Sciences,
HICSS ’11, pages 1–13, Washington, DC, USA, 2011. IEEE
Computer Society.
[14] Brent Hailpern Peri Tarr, Clay Williams. Toward Governance
of Emergent Processes and Adaptive Organizations. IBM
Research, 2008.
[15] K. Schwaber and M. Beedle. Agile Software Development
with Scrum. Prentice-Hall, 2001.
[16] Venky Shankararaman and Pervez Kazmi. Unifying ea, bpm
and soa through a synergestic framework. E-Commerce
Technology, IEEE International Conference on, 0:286–293,
2011.
[17] Keith Swenson. Bpm is not software engineering, November
2008. http://social-biz.org/.
[18] W. Wood. Best and worst practices in bpm and soa, August
2011. http://www.club-bpm.com/.