1. Estándares para el
Modelado de Procesos
de Negocios
Curso: Business Process Management
Grupo No. 6
 Casquero Torres, Wilfredo Aníbal
 Garayar Tito, Ana Meliza
 Mansilla Garayar, José Alfredo
 Patricio Peralta, César Hernán
 Torres Estrada, Jorge Luis
04/05/2014
Trabajo realizado por el Grupo - 6 sobre los principales Estándares de Modelado de
Negocios. Se da un énfasis especial en el estándar BPMN y se incluye un caso de éxito.

2. 1
ESTÁNDARES PARA EL MODELADO
DE PROCESOS DE NEGOCIOS
INTRODUCCIÓN
Un modelo tiene la finalidad de representar los procesos de negocio de una empresa u
organización con objeto de que puedan ser analizados y mejorados, para ello se realiza:
 La Validación: que se realizan a todas las tareas y ciclos de proceso
 La Simulación: como por ejemplo el ahorro de costos antes de la implementación
Asimismo, es necesario que todas las partes implicadas interpreten el contenido de los
modelos del mismo modo. Aquí es donde intervienen los estándares de modelado. Éstos
definen los elementos del modelo de procesos y su s ignificado. Permiten la gestión
colaborativa de los procesos de negocio (BPM) en todas las disciplinas, y en toda la
empresa.
El presente trabajo tiene con objetivo presentar los principales Estándares de Modelado
de procesos de Negocios:
 Business Process Execution Language - BPEL
 Unified Modeling Language – UML
 Event-driven Process Chain – EPC y
 Business Process Modeling Notation - BPMN
Por otro lado se incluye como parte de este trabajo un ejemplo de caso de éxito en la
Compañía RSA Seguros Generalesde Chilecon la aplicación de BPMN utilizando
herramientas proporcionadas por la compañía española AuraPortal el cual inicia con la
automatización de proceso de “Cotización de Pólizas de Seguros”, actualmente a la
fecha se trabaja en otros procesos como el de Inspecciones de Vehículos.

3. 2
BPEL
Lenguaje de Ejecución de Procesos de Negocio
BPEL;Según la definición de la organización de estándares OASIS el “Business Process
Execution Language” (BPEL) es una forma de orquestar procesos de negocio basada en
estándares, compuesto por servicios. Como lenguaje de ejecución, WS-BPEL define
como representar las actividades en un proceso de negocio, junto al control de la lógica
del flujo, datos, correlación de mensajes, manejo de excepciones, y demás.
Es un estándar diseñado para integrar una variedad de aplicaciones y conseguir los
objetivos de negocio independiente de las plataformas y tecnologías con mayor
escalabilidad y flexibilidad.
BPEL o Lenguaje de Ejecución de Procesos de Negocio puede definirse como un estándar
basado en XML diseñado para la “orquestación” de servicios Web. Esto significa que
permite el control centralizado de la invocación de diferentes servicios Web con cierta
lógica de negocios, definiéndose cuál, cómo y cuándo se ejecutará un proceso
determinado.
BPEL permite a las empresas alcanzar un alto dinamismo en su arquitectura tecnológica,
adaptándose rápidamente a los cambios, ya sean a nivel interno o externos. De esta
forma, pueden reorganizar con mayor facilidad la comunicación entre sus aplicaciones,
reduciendo ostensiblemente la complejidad de los procesos .
BPEL puede tener un alto impacto en solucionar la compleja integración tecnológica de
las empresas, contribuir a definir procesos con mayor dinamismo y de acuerdo a la lógica
de cada negocio, monitorear procesos y obtener, como consecuencia de lo anterior, un
máximo aprovechamiento de la infraestructura de TI, una mayor flexibilidad y
escalabilidad de los sistemas y, por sobre todo, una importante protección de la
inversión en tecnología, ya que se basa en estándares.

4. 3
1. Características
 Es la unión entre negocio y tecnología.
 Es un lenguaje XML que define como un proceso de negocios puede ser
ejecutado usando servicios Web.
 Al ser un estándar usado por los fabricantes:
 Permite elegir entre distintas plataformas
 Permite la interoperabilidad
 Fomenta la competitividad y la mejora de las plataformas
 BPEL es un lenguaje de ejecución
 Generalmente se realiza una conversión BPMN A BPEL
 Es el lenguaje “máquina” que permite la implementación del BPM
 Estándar soportado por la mayoría de fabricantes Físicamente es un fichero
XML
 La ejecución de las funciones de negocio se gestiona a través de servicios Web.
 BPEL es un lenguaje de especificación de procesos de negocio
completamente ejecutable que otorga orquestación a los Servicios Web. Un
modelo de orquestación provee un ámbito específicamente enfocado en la
vista de un participante en particular.
2. Cómo se aplica BPEL?
Un típico ejemplo es cuando se recibe una orden de compra, en donde hay
acciones que pueden incluir el chequeo del status de crédito de un cliente,
verificación de stocks, ratificación de la orden internamente, programación del
envío, confirmación de la entrega y recepción o envío del pago correspondiente.
Cuando un proceso de negocios es ejecutado por servicios Web significa que
gracias a BPEL existirá una interfaz única para soportar mensajes XML,
independiente de las plataformas asociadas, con lo cual se evita tener que usar
múltiples protocolos y formatos e interfaces distintas. Y, aunque no todas las
actividades están actualmente implementadas como servicios Web en las
organizaciones, sus efectos a nivel interno son tangibles, puesto que ayudan a

5. 4
simplificar y hacer más veloz la interacción y la ejecución de un proceso de
negocio.
La aplicación de BPEL puede darse en el caso de la reserva de un ticket aéreo y
de un hotel en forma simultánea, a través de una agencia de viajes. En este caso,
existen muchas actividades asociadas a un mismo proceso, especialmente desde
el punto del cliente, independiente de los socios de negocios que participen en
el evento. Con BPEL, la coordinación y ejecución de las actividades puede
definirse de tal manera que el resultado para el cliente y las empresas
involucradas sea siempre óptimo.

6. 5
UML
Lenguaje Unificado de Modelado
Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la
actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje
gráfico para visualizar, especificar, construir y documentar un sistema.
Prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas
orientados a objetos, y describe la semántica esencial de lo que estos diagramas y
símbolos significan.
El Lenguaje Unificado de Modelado (Unified Modeling Language) es un estándar
completo para describir sistemas de software. Facilita el acercamiento entre el diseño
de soluciones más favorables para la empresa y el diseño detallado de sistemas de
software.
1. Características de UML
 Lo fundamental de una herramienta UML es la capacidad de diagramación, y
los diferentes tipos de diagramas que soporta la herramienta. Sus esquemas
de apoyo de diseño, documentación, construcción e implantación de sistema
 Su flexibilidad para admitir cambios no previstos durante el diseño o el
rediseño.
 UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real.
2. Diagramas UML
Se utilizan para dar diferentes perspectivas del problema según lo que nos interesa
representar en un determinado momento los diagramas que UMLson:
 Diagrama de casos de uso
 Diagrama de clases
 Diagrama de secuencia
 Diagrama de colaboración
 Diagrama de estado
 Diagrama de actividad

7. 6
 Diagrama de componente
 Diagrama de despliegue
2.1. Diagrama de Caso de Uso.
El diagrama de casos de uso representa la forma como un Cliente (Actor) opera
con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactúan (operaciones o casos de uso).
Elementos:
Actor; Un Actor es un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente representa a
una persona en particular, sino más bien la labor que realiza frente
al sistema.
Caso de Uso; Es una operación/tarea específica que se realiza tras
una orden de algún agente externo, sea desde una petición de un
actor o bien desde la invocación desde otro caso de uso.
Relaciones:
Asociación; Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra operación (caso de
uso). Dicha relación se denota con una flecha simple.
Dependencia o Instanciación; Es una forma muy particular de
relación entre clases, en la cual una clase depende de otra, es
decir, se instancia (se crea). Dicha relación se denota con una
flecha punteada.

8. 7
Generalización; Este tipo de relación es uno de los más utilizados,
cumple una doble función dependiendo de su estereotipo, que
puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este
tipo de relación está orientado exclusivamente para casos de uso
(y no para actores). extends: Se recomienda utilizar cuando un
caso de uso es similar a otro (características). uses: Se recomienda
utilizar cuando se tiene un conjunto de características que son
similares en más de un caso de uso y no se desea mantener
copiada la descripción de la característica.
2.2. Diagrama de Clase.
Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
consentimiento. Un diagrama de clases está compuesto por los siguientes
elementos:
Clase atributos, métodos y visibilidad.
Relaciones Herencia, Composición, Agregación Asociación y Uso.
Clase;Es la unidad básica que encapsula toda la información de un
Objeto (un objeto es una instancia de una clase). A través de ella
podemos modelar el entorno en estudio (una Casa, un Auto, una
Cuenta Corriente, etc.). En UML, una clase es representada por un
rectángulo que posee tres divisiones:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa
el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

9. 8
2.3. Diagrama de Secuencia.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en
una aplicación a través del tiempo. Esta descripción es importante porque puede
dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos
existentes, como también muestra el uso de los mensajes de las clases diseñadas
en el contexto de una operación.
2.4. Diagrama de Colaboración.
Un diagrama de colaboración es una forma de representar interacción entre
objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de
secuencia, pueden mostrar el contexto de la operación (cuáles objetos son
atributos, cuáles temporales) y ciclos en la ejecución.

10. 9
2.5. Diagrama de Estado.
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en
una aplicación, junto con los cambios que permiten pasar de un estado a otro.
2.6. Diagrama de Actividades.
Un diagrama de actividades es un caso especial de un diagrama de estados en el
cual casi todos los estados son estados de acción (identifican que acción se
ejecuta al estar en él) y casi todas las transiciones son enviadas al terminar la
acción ejecutada en el estado anterior. Puede dar detalle a un caso de uso, un
objeto o un mensaje en un objeto. Sirven para representar transiciones internas,
sin hacer mucho énfasis en transiciones o eventos externos.
2.7. Diagrama de Componente.

11. 10
Un diagrama de componentes muestra las dependencias lógicas entre
componentes software, sean éstos componentes fuentes, binarios o ejecutables.
Los componentes software tienen tipo, que indica si son útiles en tiempo de
compilación, enlace o ejecución.
2.8. Diagrama de despliegue.
Modela la topología del hardware sobre el cual correrá nuestra aplicación y nos
indica donde se ejecutara cada uno de los componentes; esto se muestra las
relaciones físicas entre los componentes del software y el hardware de nuestro
sistema.

12. 11
Los Diagramas EPC
Event-driven Process Chain
EPC es: “Líneas de proceso gestionadas por eventos”. De esta forma, los diagramas EPC
son una técnica de modelado de procesos de negocio, principalmente utilizada para el
análisis de procesos con la intención de implementar una planificación empresarial de
recursos (ERP – Sistema usado para gestionar y coordinar todos los recursos,
información y funciones de un negocio) suponen un componente importante de los
conceptos de modelado SAP R/3 para ingeniería empresarial.
Por esto se puede decir que los diagramas EPC quedan dentro de la categoría de
herramientas para BPM (Business Process Management, o Gestión de Procesos de
Negocio).
Dentro del mundo de EPC, también podemos encontrar el “EPC MarkupLanguage”. Este es
un formato de XML para el intercambio de modelos EPC, independiente de herramientas
y plataformas.
1. Notación de los diagramas EPC
Los diagramas EPC emplean símbolos gráficos para presentar la estructura de flujo
de control de un proceso empresarial como una cadena de eventos y funciones. La
notación de este tipo de diagramas es muy sencilla, ya que sólo consta de unos
elementos. A continuación vamos a ver cuáles son:
1.1. Evento
Son elementos pasivos. Describen sobre qué circunstancias trabaja una función
o proceso, o el resultado de una función o proceso.
Algunos ejemplos: “documentación recibida”, “plazas disponibles”,…
Normalmente los diagramas EPC comienzan y terminan con un evento.

13. 12
1.2. Función
Son elementos activos. Modelan las tareas o actividades de la compañía.
Describen la transformación de un estado inicial a un estado final. En el caso de
que se puedan dar varios estados finales, la selección del correspondiente
estado final, se puede modelar explícitamente como una función de decisión,
usando conectores lógicos.
Las funciones se pueden refinar en otros diagramas EPC.
Algunos ejemplos: “solicitar documentación”, “comprobar plazas
disponibles”,…
1.3. Unidad organizativa
Determina la persona u organización, dentro de la estructura de la empresa,
que es responsable de una función específica.
Algunos ejemplos: “departamento de ventas”, “jefe de ventas”,…
Siempre va unida a una función mediante una línea continua.
1.4. Información, material o recurso
Representan objetos en el mundo real, por ejemplo objetos de negocio,
entidades,… que pueden ser datos de entrada que sirvan como base para una
función, o datos de salida producidos por una función.
Algunos ejemplos: “material”, “pedido”, “solicitud”,…

14. 13
Se unen con las funciones mediante una flecha de línea continua, donde la
punta de la flecha indica si es información de entrada o de salida.
1.5. Conector lógico
Describen las relaciones lógicas entre los elementos (eventos y funciones) en el
flujo de control.
Con la ayuda de los conectores lógicos es posible dividir el flujo de control de
un flujo a dos o más flujos, y sincronizar el flujo de control de dos o más flujos a
un único flujo.
Hay tres tipos de relaciones lógicas:
1.5.1. Branch/Merge (XOR)
 Branch: Corresponde con tomar una decisión sobre qué camino coger
entre varios flujos de control. Cuando se cumple la condición, el branch
activa sólo uno de los flujos de control de salida, y desactiva el resto.
 Merge: Puede tener dos o más flujos de entrada, y un único flujo de
control de salida. Sincroniza una única alternativa activada con el resto,
que han de estar desactivadas.
1.5.2. Fork/Join (AND)
 Fork: Activa todos los flujos de control de salida, de forma concurrente.
 Join: Sincroniza todos los flujos de controla de entrada activos.
1.5.3. Or
 Activa uno o más de los flujos de control de salida, y desactiva el resto
de los flujos de salida.
 En el Or de cierre, cuando por fin uno de los flujos de entrada es
activado, el OR le pasa el control al siguiente elemento.

15. 14
XOR AND OR
1.6. Flujo de control
Conecta eventos con funciones, caminos de procesos, o conectores lógicos,
creando secuencias cronológicas e interdependencias lógicas entre ellos.
Se representan como flechas de línea discontinua.

16. 15
BPMN
Notación para el Modelado de Procesos de Negocio
BPMN (Business ProcessModelingNotation) es la nomenclatura estándar para el
modelado de procesos de negocios. Fue diseñado como una notación de tipo diagrama
de flujo robusto, fácil de usar y completamente independiente de la implementación.
Su nomenclatura remite a conceptos propios de la programación: intercambio de
mensajes, condicionales, ciclos, manejo de excepciones, flujos en paralelo, estados y
eventos.
El principal objetivo de BPMN es proporcionar una notación estándar que sea fácilmente
legible y entendible por parte de todos los involucrados e interesados del negocio
(stakeholders). Entre estos interesados están los analistas de negocio (quienes definen
y redefinen los procesos), los desarrolladores (responsables de implementar los
procesos) y los gerentes y administradores del negocio (quienes monitorizan y gestionan
los procesos).
En síntesis BPMN tiene la finalidad de servir como lenguaje común para cerrar la brecha
de comunicación que frecuentemente se presenta entre el diseño de los procesos de
negocio y su implementación.
1. Características
 Se define como una notación gráfica que describe la lógica de los pasos en un
proceso de negocio.
 Es un lenguaje formal que permite modelar, simular y, eventualmente,
ejecutar un proceso de negocio
 Proporciona un método normalizado para representar procesos de negocio.
 Es legible, entendible y de poca complejidad.
 Propone un lenguaje común entre los usuarios de negocio y los técnicos.
 Facilita la diagramación de los procesos de negocio.
 Determina y define los requerimientos del sistema.

17. 16
2. Evolución
BPMN ha venido evolucionando a lo largo del tiempo desde su surgimiento en el
año 2001.
Su desarrollado estuvo a cargo de la organización BPM Initiative, pasando
posteriormente a manos de OMG (Object Management Group) después de la fusión
de las dos organizaciones en el año 2005. Su versión actual en el año 2011 es la 2.0.
Elementos
El modelado en BPMN se realiza mediante diagramas muy simples con un conjunto
muy pequeño de elementos gráficos. Con esto se busca que para los usuarios del
negocio y los desarrolladores sea fácil entender el flujo y el proceso.
 Objetos de flujo: Eventos, Actividades, Decisión (Gateways)
 Objetos de conexión: Flujo de Secuencia, Flujo de Mensaje,
Asociación
 Swimlanes (Carriles) Pool, Lane
 Artefactos: Objetos de Datos, Grupo, Anotación

18. 17
2.2. Objetos de flujo
Los elementos de flujo son los principales elementos gráficos que definen el
comportamiento de los procesos; están compuestos por tres elementos básicos
 Eventos un evento es algo que sucede durante el curso del proceso,
afectan el flujo de proceso y normalmente tienen una causa (trigger) o
resultado. Los eventos son representados a través de círculos con
centro vacío.
 Actividad Las actividades representan trabajo o tareas realizadas por
miembros de la organización. Este elemento simboliza tareas manuales
o automáticas llevadas a cabo por un usuario o un sistema. Una
actividad es representada por un rectángulo con bordes redondeados.
Los tipos de actividades son:
Task (tareas)
Sub-process (subproceso)

19. 18
 Decisiones (Gateway) Las Decisiones son usadas para controlar la
divergencia y convergencia del flujo. Éstas determinan ramificaciones,
bifurcaciones, combinaciones y fusiones en el proceso. Representados
por la típica figura del rombo.
2.3. Objetos de conexión Los objetos de flujo se conectan entre ellos en un diagrama
para crear el esqueleto básico de la estructura de un proceso de negocio.
 Flujo de secuencia (SequenceFlow) Está representado por línea simple
continua y flechada; y muestra el orden en que las actividades se
llevarán a cabo.

20. 19
 Flujo de Mensaje (MessageFlow) Está representado por una línea
discontinua con un círculo no relleno al inicio y una punta de flecha no
rellena al final; y se usa para mostrar el flujo de mensajes entre dos
participantes del proceso separados (entidades de negocio o roles de
negocio).
 Asociaciones (Association) Se representa por una línea segmentada
finamente con el extremo en punta. Se usa para asociar datos, textos u
otros artefactos con flujos de objetos. Las asociaciones son usadas para
mostrar las entradas y salidas de las actividades.
2.4. Canales (Swimlanes) Los canales son mecanismos de organización de las
actividades en categorías visuales separadas para ilus trar las diferentes áreas
funcionales o responsables. Los dos tipos de objetos swimlanes son:
 Pool Contiene un conjunto de actividades asociadas a una entidad del
proceso. Esta entidad puede ser un rol, división o área de la empresa,
producto o todo el proceso.
 Lane Es una partición dentro de un pool y se extiende a lo largo de todo
el pool, tanto vertical como horizontalmente. Los Lanes son usados para
organizar y categorizar actividades

21. 20
2.5. Artefactos (Artifacts) permiten a los desarrolladores llevar algo más de
información al modelo o diagrama. De esta manera, el modelo o diagrama se
hace más legible. Son tres artefactos predefinidos y son:
 Objetos de Datos Muestra al lector cual es el dato que deberá ser
requerido o producido en una actividad.
 Grupos Se representan por un rectángulo de líneas discontinuas y
vértices redondeados. El Grupo se utiliza para agrupar diferentes
actividades pero no afecta al flujo dentro de un diagrama.
 Anotación Se utiliza para darle al lector una descripción entendible del
modelo o diagrama.

22. 21
RSA Seguros Generales Chile
CASO DE ÉXITO
RSA Seguros Generales Chile, constituidaen Abril de 1905, es la sucesora deCompañía
de Seguros La República S.A.
En Noviembre de 2005, tras una serie defusiones y adquisiciones, RSA alcanza
elliderazgo del mercado chileno de segurosgenerales.
Con una tradición de 300 años y cercade 20 millones de clientes en más de140 países,
RSA es uno de los principalesgrupos aseguradores multinacionales.
Centrándose en seguros generales,tiene alrededor de 23.000 empleados yen 2012 sus
primas emitidas netas fueronde $ 14.14 bn.
En 2012 RSA Chile adquirió la suite de BPMNde la compañía española AuraPortal para
automatizar losprocesos estratégicos de la compañía y, de esta manera, implementar
unacultura de gestión por procesos que le permita a la alta dirección saber elestado en
el que se encuentra cada uno de estos y en base a los indicadoresestablecidos poder
tomar las decisiones correspondientes para lograr elóptimo desarrollo de la compañía.
LA PROBLEMÁTICA
RSA Chile, siguiendo su política de innovación constante marcada por el objetivo
deofrecer a sus clientes el mejor servicio, decidió iniciar un proyecto de
implantaciónBPM (Business Process Management) para automatizar sus procesos. En
una etapa inicial,RSA buscó la automatización de su proceso de Reserva de Negocios y
del procesode Confección de las correspondientes Cotizaciones. La realización de estas
etapas(Reserva y Cotización) se llevaba a cabo de forma manual principalmente, con
ayudade Excel, lo cual provocaba lentitud, errores y no permitía un seguimiento
histórico delas actividades realizadas.

23. 22
LA SOLUCIÓN
Después de un minucioso proceso de análisis en el que se evaluaron las aplicacionesde
software de Gestión por Procesos recomendadas por diferentesanalistas de mercado
como Gartner, Forrester y OVUM, RSA Chile decidióimplementar la suite de Gestión por
procesos de AuraPortal.
En este momento, RSA tiene una cartera de proyectos críticos que estánsiendo
implementados con AuraPortal. Esta implementación se inició conel proceso de
“Cotización de Pólizas de Seguros”, que requirió un alto gradode automatización,
manejo de documentos e integraciones con otras aplicaciones,como por ejemplo 10
puntos de integración con su AS400 de IBMsobre base de datos Oracle.
AuraPortal gestiona todo el Proceso de Cotización de Pólizas de Seguros,desde la
Solicitud de Reserva hasta el paso a emisión de la póliza correspondiente,tratando
individualmente cada producto cotizado y, cuando todaslas cotizaciones se han
realizado, unifica el resultado total del negocio porcliente según parámetros definibles
por la empresa.
El Proceso utiliza un alto grado de automatización para controlar distintosniveles de
aprobación, tanto a nivel de departamento como a nivel degerencia y para gestionar el
envío de tareas automáticas (sin intervenciónhumana) y correos electrónicos a los
usuarios involucrados, guardando unhistórico de las reservas de negocio y cotizaciones
realizadas indicando cadacambio en su estado y la fecha en que se produce.
Mediante Puntos de control situados en el Proceso, es posible tener visibilidadsobre el
estado en que se encuentra cada Reserva y cada Cotización, obteniendoreportes y
gráficos para analizar situaciones, tiempos, demoras yactuar en consecuencia, mediante
informes personalizados a demanda dela empresa.
Los comentarios realizados por los usuarios en cada fase del Proceso son registradosen
un Log (registro) indicando quién anotó el comentario, la fase,la fecha y la hora en la
cual se realizó.

24. 23
LOS RESULTADOS
Tras seis meses de implementación del proceso de Reservas y Cotizacionesen
AuraPortal, se ha alcanzado el objetivo planteado que, mediante el usode AuraPortal,
fuera posible la optimización en la automatización del proceso,con la mayor calidad y en
el menor tiempo posible, cumpliendo siemprecon los requerimientos de negocio del
Cliente.
Por medio de la implementación de la herramienta de BPM en el proceso deReservas y
Cotizaciones, ha sido posible realizar un detallado seguimientoa las razones de
obtención o pérdida de negocios para la compañía, permitiendode esta manera enfocar
los esfuerzos en la mejora del “Hit Ratio” lograndocerrar la mayor cantidad posible de
negocios.
Este resultado hace posible que RSA Chile esté comenzando la implementaciónde
nuevos procesos como el de Inspecciones de Vehículos sobre elBPM de AuraPortal,
buscando incrementar la automatización y la gestiónpor procesos dentro de la
compañía.

25. 24
Fuentes de Información
 Altova, Inc. “Notación de modelado de procesos de negocio (BPMN)” URL:
http://www.altova.com/es/umodel/business-process-modeling.html - Beverly
(Massachusetts)- USA - 2014
 Software AG. “Estándares de modelado” URL:
http://www.softwareag.com/es/product/aris_platform/modeling/default.asp,
Madrid España - 2014
 Noguera García, Manuel; Benghazi, Kawtar; Garrido Bullejos, José Luis .
“Introducción al Modelado de Procesos de Negocios”. URL:
http://www.ugr.es/~mnoguera/collaborative_systems-business_processes_10-
11.pdf - Universidad de Granada.Madrid, España, 2012
 AuraPortal. “Casos de éxito en la aplicación de BPMN - El Caso de RSA Chile”.
http://www.auraportal.com/353P698L1/Caso-de-Exito-BPM--Business-Process-
Management-Software--RSA-Chile.aspx. Madrid-España, 2012
 Wikimedia Inc. "Lenguaje Unificado de Modelado-UML". URL:
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado. Web:
Wikipedia-Enciclopedia de contenido libre - Abril 2014.
 Javier De La Fuente Sales. "Herramienta para la generación y despliegue de
composiciones de servicios Web mediante modelos BPMN". Tesina de Master.
Universidad Politécnica de Valencia-España, 2012
 Pérez García, Alejandro. "Introducción a los Diagramas EPC (Event-drivenProcessChain)",
Web patrocinada por Autentia.com,URL:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=diagramas
Epc. -Madrid, España - 2014