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.

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.

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.

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

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.

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

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.

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).

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.

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.

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.

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.

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”,…

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.

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.

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.

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

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)

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.

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

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.

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.

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ó.

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.

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