Manual 2013-II Modelado de Negocios (1350)

Modelado de
Procesos de
Negocio

MODELADO DE PROCESOS DE NEGOCI OS 2

CARRERAS PROFESIONALES CIBERTEC


CIBERTEC CARRERAS PROFESIONALES
ndice

Pgina
Presentacin 5
Red de contenidos 7

Unidad de Aprendizaje 1
LA IMPORTANCIA DEL MODELADO 9
1.1 Introduccin 11

1.2 Clasificacin de los Procesos en las Organizaciones 13
1.2.1. Procesos Estratgicos 13
1.2.2. Procesos operativos o clave 13
1.2.3. Procesos apoyo 14

1.3 Mapa de procesos en las Empresas 15

1.4 Determinacin de las tipos de los procesos en las empresas 17
1.4.1. Orquestacin 17
1.4.2. Coreografa 18
1.4.3. Colaboracin 19

LOS PROCESOS EN LAS ORGANIZACIONES 23
2.1 Introduccin 25

2.2 La importancia de la comunicacin en el modelado de los procesos 26

2.3 El modelado de procesos y su importancia 28

2.4 Modelado de procesos usando notacin BPMN 29

2.5 La historia y objetivos de BPMN 30

2.6 Dificultades en la implantacin del modelado en las organizaciones 32
2.6.1 Naturaleza de los procesos y complejidad de los mismos 32
2.6.2 Definicin del alcance del proceso 34
2.6.3. Complejidad de la notacin de BPMN 35

BUSINESS PROCESS MANAGEMENT EN LAS ORGANIZACIONES 41
3.1 Introduccin 43

3.2. La construccin de un proceso con BPMN 43
3.2.1 Manejo de Eventos 43

3.2.2 Manejo de Actividades 46
3.2.3 Manejo de Decisiones 48
3.2.4 Manejo de Flow 49
3.2.5 Manejo de Swimlanes o Partitions 50
3.2.6 Manejo de Artefactos 52

3.3. Uso de prctico de notacin BPM 53

3.4. Ajuste de los temporizadores 53

FUNDAMENTOS DE UML 61
4.1 UML (Unified Modeling Language) Definiciones 63
4.1.1 Nociones Generales de UML 63
4.1.2 Importancia de uso de UML 65
4.1.3 Aplicacin de UML en las Organizaciones de TI 68

4.2 UML (Unified Modeling Language) Uso de Diagramas 70
4.2.1 Diagramas de UML 70
4.2.2 Interaccin de UML con el modelado de Procesos de Negocio (Business
Process Modeling)
81
4.2.3 Notaciones usadas en el modelado de Procesos de Negocio (Business
Process Modeling)
81

4.3 UML (Unified Modeling Language) Uso de Elementos 84
4.3.1 Uso de elementos del tipo Flow 84
4.3.2 Uso de elementos del tipo Swimlanes (Partitions) 85
4.3.3 Uso de elementos del tipo Artifacts 86


Presentacin

El curso de Modelado de Procesos de Negocio es un curso que pertenece al rea de
anlisis de negocios y gerenciamiento administrativo de las organizaciones y/o proyectos y
se dicta en las carreras afines a Tecnologas de la informacin.
Brinda a los alumnos los conocimientos necesarios sobre el flujo de los procesos en las
diferentes organizaciones, sirve adems para identificar los procesos propios de cada
organizacin graficndolos adecuadamente. Adems prev la utilizacin de herramientas
especializadas para su notacin y despliegue.
Adems se impartirn a los alumnos un conjunto de herramientas de anlisis gerencial que
permite a los alumnos identificar los procesos administrativos organizacionales, con la
finalidad de llegar a automatizar o sistematizar dichos procesos mediante el uso de
Tecnologas de informacin.
El curso es de carcter Terico prctico y consiste en el dictado de una serie de mdulos.
El curso presenta conceptos, estrategias y prcticas para el rediseo de la organizacin con
las tcnicas usadas por el Business Process Management (BPM). El programa es prctico y
de aplicacin inmediata en las organizaciones. Se proporcionan, adems, las metodologas
y ejemplos que permitirn desarrollar talleres con casos reales aplicables a las
organizaciones de los participantes.
En primer lugar, tomando como base la identificacin de los alcances de los procesos se
proceder a impartir conocimientos sobre las organizaciones y los procesos haciendo
nfasis en la importancia de los mismos. Luego se impartirn conocimientos referidos a la
mejora de los procesos organizacionales a fin que los alumnos sean capaces de identificar
las oportunidades de innovacin o reingeniera de los mismos. Con los conocimientos
impartidos hasta este punto se proceder al Modelamiento de los procesos para el cual se
prev el uso de herramientas del tipo BPM. Los modelamientos en la empresas son
elementos dinmicos por ende se proceder a impartir conocimientos sobre la
problemologia organizacional y su impacto en la mejora de los procesos. Por ltimo se hace
un estudio de los Fundamentos de UML (Unified Modeling Language) que es un lenguaje
de modelado de sistemas de software ms conocido y utilizado en la actualidad.




Red de contenidos

MODELADO DE
PROCESOS DE
NEGOCIO
LOS PROCESOS EN
LAS
ORGANIZACIONES
Introduccin
Clasificacin de los
Procesos en las
Organizaciones
Mapa de procesos en
las Empresas
Determinacin de las
tipos de los procesos
en las empresas
LA IMPORTANCIA
DEL MODELADO
Introduccin
La importancia de la
comunicacin en el
modelado de los
procesos
El modelado de
procesos y su
importancia
Modelado de
procesos usando
notacin BPMN
La historia y objetivos
de BPMN
Dificultades en la
implantacin del
modelado en las
organizaciones
BUSINESS PROCESS
MANAGEMENT EN
LAS
ORGANIZACIONES
Introduccin
La construccin de un
proceso con BPMN
Uso de prctico de
notacin BPM
Ajuste de los
temporizadores
Ejercicios para
desarrollo en clases
FUNDAMENTOS
DE UML
UML (Unified
Modeling Language)
Definiciones
UML (Unified
Modeling Language)
Uso de Diagramas

UML (Unified
Modeling Language)
Uso de Elementos



LOS PROCESOS EN LAS
ORGANIZACIONES
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, el alumno a partir del correcto entendimiento de la
importancia del modelado de los procesos.

TEMARIO
1.1 Introduccin
1.2 Clasificacin de los Procesos en las Organizaciones
1.2.1. Procesos Estratgicos
1.2.2. Procesos operativos o clave
1.2.3. Procesos apoyo
1.3 Mapa de procesos en las Empresas
1.4 Determinacin de las tipos de los procesos en las empresas
1.4.1. Orquestacin
1.4.2. Coreografa
1.4.3. Colaboracin

ACTIVIDADES PROPUESTAS
Los alumnos debern interactuar en el aula virtual y comentar los casos
planteados.

UNIDAD
1




1.1 INTRODUCCIN

El propsito de esta unidad de aprendizaje es explorar las
diversas definiciones del Proceso reconocidas por las
organizaciones antes de pasar a presentar un diagrama
BPMN, sealando los elementos claves que se presentan.

Hay una gran cantidad de definiciones de procesos empresariales. En efecto, la nocin de
un proceso de negocio es un concepto abstracto en el mejor de los casos.
En nuestras organizaciones solemos pedir a la gente que escriba su propia definicin y
estn continuamente sorprendidos por la amplitud de las respuestas que son brindadas por
ellas mismas. Ejemplos ofrecidos se encuentran:
1. Una secuencia de actividades llevadas a cabo en una o ms entradas a ofrecer una
salida.
2. Un conjunto sistemtico de actividades que tienen un "evento" para un resultado
exitoso.
3. Una coleccin de actividades que crean valor para un cliente.
4. Una serie de funciones colaborando e interactuando para lograr una meta.
5. Una coleccin organizada de los comportamientos empresariales que satisfacen una
negocio definido propsito, funcionando de acuerdo a los objetivos especificados.
6. Justo como se hacen las cosas por aqu.
La actual definicin de Wikipedia es: "Una empresa de proceso o mtodo de negocio es un
conjunto de tareas relacionadas entre s, que cumplen un objetivo determinado."
El problema, en dar con una definicin para el trmino del proceso, es que hay
(definiciones) que muchos de ellos, cada uno tiene una interpretacin sutilmente diferente.
Por otra parte, todos usamos la misma palabra y muchas veces no se dan cuenta de que
puede significar cosas diferentes.
As que, aunque todas estas definiciones tienen sus mritos, tenemos que optar por una de
las definiciones como base para este manual. En un proceso BPMN representa lo que una
organizacin hace en su trabajo cotidiano, con el fin de lograr un propsito u objetivo
determinado. En la lista de vietas ms arriba, las definiciones segundas y terceras son
probablemente ms cercanas. Es decir las que sealan:
1. Un conjunto sistemtico de actividades que tienen un "evento" para un resultado
exitoso.
2. Una coleccin de actividades que crean valor para un cliente.
Dentro de una organizacin, hay muchos tipos de procesos, tanto en cuanto a su objeto y
cmo se llevan a cabo. La mayora de los procesos que requieren algn tipo de entrada (ya

sea electrnico o fsico), el uso y/o consumo de recursos, y producir algn tipo de salida (ya
sea electrnico o fsico). La mayora de las organizaciones realizan cientos o miles de
diferentes procesos en el curso de proporcionar valor a los clientes, el personal, o
regulaciones satisfactorias.
Algunos procesos son formales, repetible, bien estructurado, y puede incluso automatizarse.
A menudo nos referimos a este tipo de procesos como "Procedimientos". Los ejemplos
incluyen:
Salud procesamiento de reclamaciones
Crear una nueva cuenta
Transacciones Bancarias
Gastos de tramitacin de reclamos

Fig. 1.1.Ejemplo de uso de notacin BPM

Otros procesos son informales, muy flexibles, impredecibles (altamente variables), y difcil
de definir o repetir. A veces nos referimos a este tipo de procesos como "prcticas". Los
ejemplos incluyen:
Redaccin de un manual de usuario
Desarrollar una estrategia de ventas
La preparacin de un programa de la conferencia
La ejecucin de un contrato de consultora
BPMN utiliza un conjunto de elementos grficos especializados para representar una
Proceso y la forma en que se lleva a cabo (vase la Figura 1.1). Los elementos principales
de un proceso BPMN son los "objetos de flujo"; Events, y Gateways, y Secuencia de flujo.


1.2. CLASIFICACIN DE LOS PROCESOS EN LAS
ORGANIZACIONES
Las organizaciones tienden a clasificar los procesos en tres grandes grupos los cuales
procedemos a detallar.
1.2.1 Procesos Estratgicos
Procesos destinados a definir y controlar las metas de la empresa, sus polticas y estrategias.
Estos procesos son gestionados directamente por la alta direccin en conjunto.

Fig. 1.2. Ejemplo de Procesos Estratgicos

1.2.2 Procesos Operativos o Clave
Procesos destinados a llevar a cabo las acciones que permiten desarrollar las polticas y
estrategias definidas para la empresa para dar servicio a los clientes. De estos procesos se
encargan los directores funcionales, que deben contar con la cooperacin de los otros
directores y de sus equipos humanos.

Fig. 1.3. Ejemplo de Procesos Clave


1.2.3 Procesos De apoyo
Procesos no directamente ligados a las acciones de desarrollo de las polticas, pero cuyo
rendimiento influye directamente en el nivel de los procesos operativos.

Fig. 1.4. Ejemplo de Procesos de Apoyo

En suma el mapa de procesos representa de manera orgnica las funciones organizacionales
de las empresas.
A continuacin se presenta el mapa de procesos en forma integral en donde se puede
apreciar la forma como las diferentes funciones de la organizacin se integran de forma tal
que se hace fcil su entendimiento.

Fig. 1.5. Ejemplo de Mapa de Procesos integrado


Fig. 1.6. Sinopsis de los tipo de procesos organizacionales

1.3. MAPA DE PROCESOS EN LAS EMPRESAS
Los procesos se consideran actualmente como la base operativa de gran parte de las
organizaciones y gradualmente se van convirtiendo en la base estructural de un nmero
creciente de empresas.
Esta tendencia llega despus de las limitaciones puestas de manifiesto en diversas soluciones
organizativas, en sucesivos intentos de aproximar las estructuras empresariales a las
necesidades de cada momento.
As las organizaciones de tipo funciona generaron altos niveles de eficacia en las operaciones
especializadas abordadas por cada funcin, a menudo a costa de la eficacia global de la
empresa y de una comunicacin poco fluida entre las distintas funciones.
Las organizaciones de tipo matricial, un gran avance en teora, diseadas para optimizar el
empleo de las capacidades humanas, integrarlas en equipos ad hoc para cada proyecto o
nueva actividad, y para reforzar y emplear a fondo los conocimientos disponibles en la
empresa, encontraron muchas dificultades en su aplicacin prctica.
Probablemente una informacin insuficiente sobre los requisitos exigibles a la cultura de la
empresa, junto con el problema siempre presente de la falta de tiempo (para explicar, para
experimentar) hiciera fracasar muchos intentos de este tipo de organizacin, que pocas veces
lleg a probarse en condiciones adecuadas para garantizar el xito.
El xito de las industrias japonesas, bien patente a partir de los aos setenta y ochenta,
propici la aplicacin de modelos de organizacin productiva, como just in time o Kankan.
T
I
P
O
S

D
E

P
R
O
C
E
S
O
S

Procesos Estrategicos
Destinados a definir y controlar las
metas de la empresa
Procesos Operativos
Destinados a llevar a cabo las
acciones que permiten desarrollar
las polticas
Destinados a estrategias definidas
para la empresa para dar servicio a
los clientes
Procesos Apoyo
Destinados no directamente a las
acciones de desarrollo de las
polticas

Su aplicacin ha producido resultados econmicos sorprendentes en los pases occidentales,
pero son modelos limitados, principalmente por centrarse en empresas manufactureras de
grandes series, y por requerir proveedores de piezas estrechamente ligados a las fbricas
productoras de los equipos o sistemas finales. Tanto el modelo matricial como los de origen
japons ya apuntaban a la importancia de los procesos como base sobre la que desarrollar
polticas y estrategias operativas slidas.
Esto dio origen a estudios sobre las posibilidades de los procesos como base de gestin de la
empresa, que fueron poniendo de manifiesto su adecuacin a los mercados actuales, cada
vez ms cerca del mercado global y, como consecuencia, su capacidad de contribuir de forma
sostenida a los resultados, siempre que la empresa disee y estructure sus procesos
pensando en sus clientes. (Ver Fig. 1.7)
Los procesos, se pueden definir como secuencias ordenadas y lgicas de actividades de
transformacin, que parten de unas entradas (informaciones en un sentido amplio pedidos
datos, especificaciones, ms medios materiales, mquinas, equipos, materias primas,
consumibles, etctera), para alcanzar unos resultados programados, que se entregan a
quienes los ha solicitado, los clientes de cada proceso.

Fig. 1.7. Ejemplo de mapa de procesos

Estos procesos, al requerir un conjunto de entradas materiales e inmateriales y componerse
de actividades que van transformando estas entradas, cruzan los lmites funcionales
repetidamente.
Por cruzar los lmites funcionales, fuerzan a la cooperacin y van creando una cultura de
empresa distinta, ms abierta, menos jerrquica, ms orientada a obtener resultados que a
mantener privilegios.
A estas ventajas de preparacin para el entorno actual, incierto y cambiante, se debe aadir la
importante caracterstica de que los procesos son altamente repetitivos.

1.4. DETERMINACION DE LAS TIPOS DE LOS PROCESOS EN LA
EMPRESAS
Desde su creacin, BPMN ha tratado de apoyar a tres categoras principales de los
procesos:
o Orquestacin
o Coreografa
o Colaboracin
Estos trminos han variado, con frecuencia contradictoriamente, tienen significados a travs
de los muchos contextos diferentes empresas en las que se aplican. Hemos buscado para
definir, a efectos de BPMN, y luego aplicar de forma coherente a lo largo de este manual.
Futuro versiones de BPMN a distinguir ms claramente entre estos tipos de procesos,
incluyendo soporte robusto para diagramtica cada aspecto.
1.4.1. Orquestacin
Dentro de BPMN, los modelos de orquestacin tienden a implicar una sola perspectiva de
coordinacin, es decir, representan un negocio especfico o una vista de la organizacin del
proceso. Como tal, un proceso de orquestacin describe cmo una unidad econmica va
sobre las cosas. Utilizado principalmente en la comunidad tcnica, "Proceso de
orquestacin" a menudo se alinean con los lenguajes de servicios web tales como BPEL.
La mayor parte de este manual explora orquestacin proceso orientado modelos. Tanto es
as, que se har referencia a las orquestaciones simplemente como Procesos. La Figura 1.8
presenta un modelo simple orquestacin.
Sin embargo, un diagrama de BPMN puede contener ms de una orquestacin. Si es as,
cada orquestacin aparece dentro de su propio contenedor llama la piscina. As,
orquestaciones (es decir, los procesos) siempre contenida dentro de una piscina. Esta
distincin es importante a la hora de comprender la diferencia entre orquestacin y
coreografa.

Fig. 1.8. Ejemplo de Proceso de Orquestacin

Adems, el hecho de que orquestaciones estn contenidas dentro de una piscina indica que
consisten en elementos de proceso que existen juntos dentro de un contexto bien definido, o
focos de control. Un modelo de orquestacin ejecutado por una Suite BPM ciertamente se
ajusta a esta descripcin, pero tambin se aplica a situaciones que no son parte de un
sistema semiautomtico. A consecuencia del "contexto bien definido" para una orquestacin
es que hay datos disponibles para todos los elementos del modelo.
1.4.2. Coreografa
Un modelo de proceso coreografa es una definicin de la conducta que se espera (un tipo
de contrato de procedimiento o protocolo) entre los participantes interactan entre s. Estos
participantes pueden ser de negocios en general roles (por ejemplo, un cargador) o es una
entidad comercial especfica (por ejemplo Cibertec).
Al igual que la definicin de un ballet, una coreografa en BPMN describe la interaccin de
los participantes. En BPMN, una coreografa define la secuencia de interacciones entre dos
o ms participantes. En BPMN, las interacciones son la comunicacin, en la forma de
intercambio de mensajes entre dos participantes.
En BPMN acciones coreografa modela muchas de las caractersticas de los modelos de
orquestacin en que tiene una forma de diagrama de flujo. Incluye caminos alternativos y
paralelos, as como los subprocesos. Por lo tanto, los objetos de flujo (Actividades, Eventos
y puerta de enlace) de orquestacin.

Fig. 1.9. Ejemplo de Proceso de Coreografa

Los modelos tambin son aplicables a los modelos de coreografa. Sin embargo, existen
diferencias dramticas entre orquestacin y modelos coreografa:

Una orquestacin est contenido dentro de una piscina y normalmente tiene un contexto
bien formado.
Una coreografa no existe dentro de un contexto bien formada o foco de control. No hay
ningn mecanismo central que conduce o realiza un seguimiento de una coreografa.
Por lo tanto, hay no compartir datos a disposicin de todos los elementos de la
coreografa.
Para realizar la coreografa en diagramas de BPMN es poner entre ellos las piscinas.
La primera versin de BPMN (ahora 1.1) incluye algunos de los conceptos que los modelos
de la coreografa de apoyo. Y si bien es posible derivar el comportamiento esperado de la
coreografa, los elementos necesarios para la definicin completa an no se han definido.
BPMN 2.0 incluye un completo soporte para diagramas de coreografa (distinta de
orquestacin diagramas).
La Figura 1.9 presentada anteriormente demuestra las capacidades actuales para la
definicin de coreografa en BPMN 1.1. El diagrama muestra dos piscinas, cada uno con
orquestaciones. Los conectores entre los Pools son el flujo de mensajes. La combinacin de
las Actividades y otros elementos dentro de las piscinas y el flujo de mensajes entre las
piscinas definen una coreografa implcita.
En lugar de tener que derivar la coreografa del mensaje cambio, ser posible modelar como
"stand-alone" o colquelo entre las piscinas.
1.4.3. Colaboracin
La colaboracin tiene un significado especfico en BPMN. Se define el conjunto ordenado
(un protocolo) de las interacciones entre los participantes, una colaboracin simplemente
muestra a los participantes y sus interacciones. Una colaboracin tambin puede contener
una coreografa (Cuando est disponible en BPMN) y orquestaciones uno o ms.
Para ser ms especficos, una colaboracin es cualquier diagrama BPMN que contiene dos
o ms participantes, como se muestra en piscinas. Las piscinas tener el flujo de mensajes
entre ellos. Cualquiera de las piscinas puede contener una orquestacin (un proceso), pero
no son necesarios.
La Figura 1.10 muestra un diagrama de colaboracin ejemplo. Contiene dos piscinas y el
flujo de mensajes entre ellos. Otras colaboraciones diagramas podra mostrar
orquestaciones dentro de las piscinas (como en la figura 1.9, ms arriba).


Fig 1.10. Ejemplo de Proceso de Colaboracin


Resumen

Los procesos son conjunto de operaciones ejecutadas de manera paralela y/o
secuencial, con el objeto de obtener un resultado, estas operaciones son realizadas con
la utilizacin de distintos medios disponibles llamados factores.
Las organizaciones cada vez ms complejas y por ende desarrollo mayor en procesos.
Es por ello que las organizaciones obstante por clasificar sus procesos de manera que
les permitan identificar los procesos que le genera valor dentro de la cadena de
organizacin.
Esta organizacin se resume en tres elementos procesos de tipo estratgico, procesos
de tipo principal y procesos de apoyo.
Por lo tanto el proceso debe ser:
Claramente definido
Para poder ser analizado y evaluado
Para poder ser controlado y mejorado.
Pginas de Inters
www.tcpsi.com/servicios/modelado.htm
o En este link encontrar informacin relacionada al modelamiento de procesos
de negocio.
www.elprisma.com/apuntes/curso.asp?id=6034
o En este link encontrar informacin relacionada a la importancia del correcto
modelado de los procesos en las empresas.
www.advice-business.com/es/consejos-1918931.htm
o En este link encontrar informacin relacionada al manejo de procesos de
negocio en la empresas
www.uv.mx/usbi_ver/docs/manuales/man_docum_procesos_usbi.pdf
o En este link encontrar un manual que hace referencia a los tipos de procesos
organizacionales.





LA IMPORTANCIA DEL MODELADO
Al trmino de la unidad, el alumno a partir del correcto entendimiento de los alcances
de los procesos en las organizaciones identificar las oportunidades de negocio para
el correcto modelamiento de los procesos de negocios partiendo de la gestin
organizacional.
TEMARIO
2.1 Introduccin
2.2 La importancia de la comunicacin en el modelado de los procesos
2.3 El modelado de procesos y su importancia
2.4 Modelado de procesos usando notacin BPMN
2.5 La historia y objetivos de BPMN
2.6 Dificultades en la implantacin del modelado en las organizaciones
2.6.1 Naturaleza de los procesos y complejidad de los mismos
2.6.2 Definicin del alcance del proceso
2.6.3. Complejidad de la notacin de BPMN

Los alumnos debern analizar un caso planteado.

UNIDAD
2



2.1. INTRODUCCIN
En esta Unidad de aprendizaje se describe la funcin
de modelado de procesos en general, tanto como una
ayuda para la comunicacin y tambin para conducir la
manera en que el trabajo que ocurre en la organizacin
moderna.
A continuacin, va a discutir un poco sobre la historia
de BPMN.

Todas las organizaciones estn en un viaje, un viaje que nunca termina donde la atencin
se centra en mejorar la forma de hacer las cosas (no obstante, que es medido) para el
beneficio de los dueos, accionistas, partes interesadas y / o beneficio en especial del
cliente. Esta idea est en el corazn de Business Process Management (BPM), una manera
de pensar, una filosofa de gestin centrada en la mejora de los procesos operativos de la
organizacin.
Cuanto ms largo sea el tiempo que una organizacin ha estado viajando por este camino,
ms madura sus procesos, estos se hacen ms repetible y escalables en sus operaciones y
mejor ser su rendimiento empresarial global. En efecto, existen muchos libros de gestin
que estn llenos de ejemplos de empresas que han seguido en este camino por algn
tiempo-Dell, General Electric, Toyota, Nokia, Cisco, Federal Express, por nombrar slo
algunos.
Dondequiera que uno mire, no es fcil encontrar cualquier nmero de artculos o libros que
las empresas participan en la innovacin operacional (con el objetivo de aplastar la
competencia). Y, sin embargo, todos los estos ejemplos tienen una cosa en comn: un
nfasis fundamental en la comprensin de los procesos de negocio de la empresa con el fin
de mejorarlos. Se podra argumentar que se trata de un derecho fundamental principio de la
disciplina de gestin.
En todo el mundo, en casi todas las empresas y organizaciones, las personas estn
luchando para comunicarse entre s sobre cmo organizar mejor el trabajo. Ellos estn
explorando cuestiones como:



Qu pasos son realmente necesarios?
Quin debe hacerlo?
En caso de que se mantenga en la empresa o
subcontratado?
Cmo se debe hacer?
Qu capacidades se necesitan?
Qu resultados podemos esperar y cmo van a
ser monitoreados?
Si bien las respuestas a estas preguntas son siempre alguna situacin especfica; es
necesario que todos entendamos que es lo que busca el proceso dentro de la organizacin.
2.2. LA IMPORTANCIA DE LA COMUNICACIN EN EL MODELADO
DE LOS PROCESOS
Los competidores se empean en sacar nuevos productos, los clientes exigen ms rpido
los plazos de entrega y precios ms bajos, las regulaciones cambian. Cada vez que un
programa de organizacin comienza a abordar este tipo de desafos, la gente se encuentra
la construccin de procesos de negocios modelos para ilustrar el flujo de actividad de trabajo
y relacionadas (ver Figura 2.1.).

Fig. 2.1. Ejemplo de un Modelo de Proceso Bsico

Las personas suelen utilizar estos modelos para apuntalar sus conversaciones, estos
apoyan a la comunicacin y la comprensin, que acta como teln de fondo de casi todos
los programas de mejora. Tales modelos a menudo formar la base de una referencia integral
de negocios, detallando cmo toda la operacin encajan. Cuentan en los materiales de
capacitacin y actuar como una base para el intercambio de las mejores prcticas dentro de
la empresa.
Como se representa en la figura 2.2, los modelos de proceso que normalmente se crean,
examinando las operaciones comerciales tal como estn. Posibles entradas que deben

determinarse aqu son los objetivos, la estrategia y reglas (o normas) de la organizacin.
Algn tipo de anlisis se lleva a cabo antes de rediseo.
Las organizaciones pueden elegir entre muchas metodologas sofisticadas para la captura y
el diseo de modelos de procesos para adaptarse a su propsito.
Este manual no pretende proporcionar una metodologa, pero se proporcionar una base
para la comprensin de los modelos resultantes.
Hasta este punto, se supone que los seres humanos son los principales consumidores de
estos modelos. Como veremos ms adelante, estos procesos tambin pueden actuar como
entradas primarias a un soporte de negocio del entorno que les rodea, de su medio
ambiente.

Fig. 2.2. Organizacin de la empresa y las operaciones de negocio

Inicialmente, estos modelos hacen posible el conducir la comunicacin con compaeros de
trabajo dentro de la organizacin, ayudndoles a formar un entendimiento compartido. En
una organizacin pequea, esto es relativamente fcil de hacer ya que los empleados
tienden a compartir una cultura comn y un conjunto de valores compartidos. Pero en una
organizacin ms grande, sobre todo cuando los empleados estn repartidos en varias
ubicaciones fsicas diferentes, logrando una interpretacin comn acordada de lo que las
palabras significan realmente es a menudo difcil.
Pero al compartir modelos de procesos con proveedores, clientes y / o socios, es decir,
hacia arriba y debajo de la cadena de valor, esta cuestin problema se agrava
interpretacin. Los participantes ya no tienen las referencias culturales que ayudan a fijar el
significado de la diagrama.
Los modelos de proceso tambin proporcionan el marco en el que las mtricas (medidas de
rendimiento de los procesos) tienen un significado. Por ejemplo, sin una nocin de negocio
proceso, conceptos como la del alcance del proceso (Donde inicia el proceso y donde
termina el mismo, cuanto el costo de la ejecucin del proceso, cuales son los riesgos de no
realizarlos) no tienen puntos de referencia.

2.3. EL MODELADO DE PROCESOS Y SU IMPORTANCIA
Pero despus de haber construido esos
modelos, algunos dan cuenta de que tambin es
posible utilizarlos para impulsar las actividades
de la empresa. Observe que la Figura 2.2
muestra cmo el rediseo de procesos alimenta
el Soporte de Procesos. A lo largo del manejo
de los datos, documentos y reglas, el Modelo de
Proceso es ahora el apoyo a las operaciones de
la empresa.
Interpretado por sistemas de software sofisticados (Suites de BPM o Productos de flujo de
trabajo), los modelos de procesos ejecutables llevan las instrucciones de cmo debera
ocurrir, quin debe hacerlo, la progresividad condiciones, si no se hace a tiempo, enlaces a
otros sistemas, etc. Los productos se mueven en torno a la organizacin de trabajo,
asegurando el correcto rendimiento de los pasos crticos y que los elementos de trabajo no
generan valor para la empresa.
Si el trabajo tiene que cambiar entonces en vez de escribir nuevos programas informticos,
slo cambia el soporte modelos y el comportamiento de la organizacin se adaptar en
consecuencia.
Estos entornos de software orientados a procesos son cada vez ms populares, ya que
proporciona un mtodo directo de traducir el entorno estratgico y la intencin tctica en los
procesos operativos. Ellos proporcionan un amplio banco de conocimientos para el largo
viaje de transformacin organizacional. El manejo adecuado permite a toda la organizacin
a ser mucho ms gil de lo que sera el caso.
El factor esencial aqu es que los modelos de procesos requieren ms rigor si son para
apoyar este comportamiento ejecutable (en lugar de depender de la interpretacin humana).
El problema es que, sin precisin y la estructura, ms nos fijamos en cajas y flechas,
menos que significan. A fin de que un modelo para comunicar sustancia real, las cajas y
flechas que representar algo.
Para una persona que no conoce el valor de la notacin adecuada de los procesos resultara
no tener valor el solo dibujar un recuadro con una tarea dentro (ver fig. 2.3 actividad de
aprobacin). O simplemente notara que existe una flecha antes y despus de la misma. (Ver
fig. 2.3 flecha). Sin embargo esto denota informacin importante la cual nos indica que de no
presentar la solicitud de correccin de notas esta no puede aprobarse.


Fig. 2.3. Ejemplo de un Modelo de Proceso Bsico

La realidad es que, a la hora de modelar el multifactico mundo del trabajo, todos los
modelos de procesos de negocios necesitan un cierto grado de rigor. De lo contrario, no
tienen sentido. Esto es especialmente cierto cuando el modelo est diseado para la
interpretacin por los equipos.
2.4. MODELADO DE PROCESOS USANDO NOTACIN BPMN
En BPMN, un proceso empresarial consiste en la captura de informacin de una secuencia
ordenada de las actividades comerciales y de apoyo. Modelar un proceso de negocio
consiste en representar cmo una empresa realiza sus objetivos generales, los objetivos s
son importantes, pero en este momento no son capturados en la notacin. Con BPMN, slo
los procesos se modelan.
En el desarrollo de BPMN, existen diferentes niveles de modelado de procesos:
a) Proceso de Nivel de Mapas
Simples diagramas de flujo de las actividades, un flujo diagrama sin muchos detalles que no
sean los nombres de las actividades y tal vez las condiciones de la Poltica Uniforme.

b) Proceso a Nivel de Descripciones
Proporcionan informacin ms amplia en el proceso, como las personas involucradas en la
realizacin del proceso (roles), los datos, informacin y as sucesivamente.

c) Proceso a Nivel de modelos
Detallada diagramas de flujo que abarca la informacin suficiente de tal manera que el
proceso es susceptible de anlisis y simulacin. Adems, este estilo ms detallado de
modelo tambin permitira bien la ejecucin directa de mismo dentro de un modelo o
importar a otras herramientas que podran ejecutar que proceso (con ms trabajo).

Actividad o
Tarea
Flecha o
Conector

BPMN cubre todos estos tipos de modelos y soporta cada nivel de detalle. Como tal, BPMN
es un diagrama de flujo basado en la notacin para definir los procesos de negocio a partir
de la simple contemplacin del mismo; es decir de la captura de datos cotidianos que se
hace en la organizacin (por ejemplo, vase la Figura 2.1) para los modelos ms complejos
y sofisticados requeridos para apoyar la ejecucin del proceso.
BPMN es capaz de representar diferentes niveles de grupos de informaciones simples y
complejas y los hace con el uso de diferentes tipos de diagramas para diferentes propsitos.
2.5. LA HISTORIA Y OBJETIVOS DE BPMN
En 2001 comenz a desarrollar BPMI.org4 BPML (Business Process Modeling Language, un
lenguaje XML proceso de ejecucin) y realizarlos haba una necesidad de una
representacin grfica.
Se solicit informacin sobre las necesidades de lo que se quera plasmar en los flujos de
los procesos plantear a los individuos y proveedores involucrados en el tema de gestin de
procesos. Cabe indicar que se la informacin solicitada se originaba los requerimientos
propios del mercado. Esto significara que la traduccin se necesitaba de la notacin
orientada a los negocios al lenguaje de ejecucin tcnica. BPML ms tarde fue sustituido por
BPEL como lenguaje de ejecucin de destino.
El Grupo de Trabajo Notacin (quien originalmente cre en BPMN BPMI.org) se form en
agosto de 2001. Estaba compuesta por 35 empresas de modelacin, organizaciones e
individuos que les entre trajo una amplia gama de perspectivas. Este grupo desarroll BPMN
1,0. Cuando se comenz el desarrollo de BPMN haba-y hay todava- una amplia gama de
notaciones de modelado de procesos, incluso existan diferentes herramientas que
efectuaban esta funcin, y estas podran utilizarse dentro de una amplia variedad de
metodologas.
Lo interesante de BPMN fue el gran nmero de vendedores que se reunieron con el objetivo
comn de consolidar- los principios subyacentes de la modelizacin de procesos. Su
objetivo era acordar una notacin simple (representacin) que otras herramientas y los
usuarios pueden adoptar. Por lo tanto, BPMN no era un ejercicio acadmico elevado, sino
ms bien una solucin prctica tanto para los proveedores de herramientas de modelado de
procesos y los usuarios de las herramientas de modelado de procesos.
El razonamiento era que este enfoque ayudara a los usuarios finales, dndoles una
notacin simple, estuvo de acuerdo. Esto permitira consistente formacin, utilizando
cualquier nmero de herramientas. Las empresas no tendran que reciclar cada vez que se
compr una nueva herramienta o contratado a personas que tenan estudiado otras
herramientas y notaciones. En definitiva, se hicieron las habilidades transferibles.
Otro objetivo de BPMN fue que sera proporcionar un mecanismo para generar ejecutable
procesos-inicialmente en BPML (ms tarde sustituido con BPEL). Por lo tanto, BPMN
proporciona una asignacin de vlido BPMN a BPEL diagramas, de tal manera que el

motor puede ejecutar el proceso. Esto no quiere decir que cada modelo de procesos BPMN
es ejecutable, pero para aquellos procesos destinados a la ejecucin, BPMN proporciona los
mecanismos para ir desde el diseo inicial hasta la ejecucin. Esta trazabilidad es parte de
la meta original de la desarrollo de BPMN.
BPMN tena dos objetivos contradictorios para proporcionar un fcil utilizar la notacin de
modelado de procesos, accesible a los usuarios de negocios; y dar facilidades a traducir los
modelos en un archivo ejecutable formar como BPEL.
En mayo de 2004, la especificacin BPMN 1.0 fue lanzado al pblico. Desde entonces, ms
de 50 empresas han desarrollado aplicaciones de la norma. En febrero de 2006, la
especificacin BPMN 1.0 fue adoptado como un estndar OMG.

Fig. 2.4. Evolucin de BPM

Tenga en cuenta que el Grupo de Trabajo de notacin no tena la intencin de especificar un
mecanismo de almacenamiento acordado (serializacin) para BPMN. Es tanto una bendicin
como una maldicin, que permita a los vendedores adoptar la notacin sin tener que
cambiar sus propios formatos de almacenamiento interno (Un factor que contribuye a la
adopcin generalizada de la norma).
Pero tambin significa que los archivos de diagrama no eran porttiles entre herramientas
de modelado.

BPMN originalmente no especifica un formato de almacenamiento, lo que permite una
amplia seccin transversal de los proveedores para adoptar la portabilidad estndar, sin
embargo, limitando de modelos.
En febrero de 2008, el OMG liberados al final de BPMN 1.1, que es disponible para su
descarga pblica (ver www.bpmn.org). La mayora de los cambios en la versin 1.1 aclar el
documento de especificacin en s, haciendo que el significado ms explcito.
Sin embargo, unos pocos cambios grficos se hicieron para BPMN en la versin 1,1 (todas
cubiertas en este libro). Dnde se han producido cambios, se han resaltado?
El OMG pronto lanzar BPMN 1.2. Esta versin no incluye cambios grficos significativos;
modificaciones fueron meramente editorial (es decir, la limpieza de la lengua de la
especificacin s mismo).
BPMN 2.0 est actualmente est en uso esta versin la misma que ofrece una amplia gama
de notacin que permite un acceso detallado a las aplicaciones organizacionales.

2.6 DIFICULTADES EN LA IMPLANTACION DEL MODELADO EN
LAS ORGANIZACIONES

2.6.1 Naturaleza de los procesos y complejidad de los mismos
Hay generalmente un gran nmero de formas
de modelar un comportamiento deseado, en
cualquier nmero de niveles de precisin.
Mucha gente asume que siempre hay un
modelo correcto (y que de alguna manera los
otros modelos estn equivocados), sin
embargo, rara vez hay un solo modelo correcto.
Por otro lado, los modelos pueden sern
vlidos (en que incorrectamente utilizar una
notacin dada).
Adems, a menudo hay muchos ms detalles potencial de capturar que es necesario. Si
tuviramos que modelar cmo se debe hacer una taza de t, y luego una sola actividad
puede ser suficiente. Alternativamente, se podra describir la necesidad de hervir el agua
primero, coloque una bolsa de t en una taza y, opcionalmente, aadir la leche. Pero y si
nos gustaba la preparacin de t para varias personas con un vaso de agua y las hojas de
t, o debemos incluir los pasos involucrados en el llenado que se hace dentro de la cocina o
comedor, o la adicin de azcar?
El modelador siempre la toma de decisiones sobre qu incluir y qu dejar fuera. As que uno
tiene que mantener una perspectiva sobre los usos de la modelo y que lo interpretar.

Si las audiencias (los que van a leer e interpretar el modelo) no estn interesados en los
detalles finos, y luego no lo incluya en el modelo. En otras situaciones, tales como cuando el
modelo ser compatible dentro de una simulacin de ejecucin en una Suite BPM o donde
es el objetivo, entonces es que se requieren detalles significativos del proceso se requiere
normalmente.
Imagnese que una organizacin, el gerente, rene a todos sus empleados de una
determinada rea, y pasa por un muy ejercicio simple. Se les pide a los empleados una
lluvia de ideas de todas las cosas que les gustara representar en modelos de procesos. No
pasa mucho tiempo antes de que se proponga graficar un par de procesos, flujo, insumos,
salidas, responsabilidades, costos, ubicacin, calidad, normas, interacciones, escalada, etc.
Cuando le preguntaron si querran todas estas dimensiones para aparecer en un solo
proceso, los delegados de repente se dan cuenta es una cuestin de remover las cosas de
los modelos para hacer til.
El modelador est constantemente tomando decisiones sobre la modelizacin propsito del
modelo y el pblico destinatario.
Una historia anecdtica lleva al punto de inicio. Durante los das de Reingeniera de
Procesos de Negocio (BPR fue referido a veces como mayores reducciones de Personas),
un gigante de productos qumicos tena como principal empleada una de las firmas lderes
de consultora para ayudar en la reingeniera de sus procesos de ventas de Amrica del
Norte. Despus de varios meses de trabajo, se hizo una presentacin (ya que este era un
proyecto muy importante). A un lado de la sala de reuniones era papelgrafo un ochenta
centmetros diagrama de flujo (como es el modelo). En la otra pared, una diagrama de flujo
de sesenta centmetros de cmo debe Ser proceso. El entonces Presidente permiti que el
Socio de Consultora para completar su presentacin antes de hacer una pregunta muy
simple. "Es un buen proceso y si es as, por favor explique por qu.?". Y ah radicaba el
ncleo del problema.
El detalle entregado era totalmente inapropiado para la audiencia deseada.
Estas son algunas de las caractersticas de un buen modelo:
Saliente
Debido a que ningn modelo puede representar todo, debe selectivamente representan
aquellas cosas que son ms relevantes para la tarea en cuestin.

Preciso
El modelo debe codificar con precisin el actual estado de cosas y no una visin
errnea o sesgada.

Completo
El modelo debe ser como simple como sea posible, pero no ms simple, y debe ser
completo.


Comprensible
Una vez que percibimos el modelo que debe ser capaz de darle sentido, no debera ser
demasiado complicado o desconocido para nosotros de entender.
Se debe indicar que algunos de los problemas de evolucin y adaptabilidad alrededor de
modelado es que o se siguen la pautas establecidas anteriormente, es decir, no son
salientes, precisos, completos y comprensibles. "Como todos los modelos son, en cierta
medida, inexacta, irrelevante, errnea, sensible al tiempo, etc., deben ser abiertos a revisin
recursiva para reflejar nuevos datos, nuestra creciente comprensin, o nuestras
necesidades en evolucin. "
En el extremo, los modelos necesitan ser tiles. Su "Utilidad es la suma de las propiedades
anteriores y el grado en el que se combinan para promover el entendimiento y la accin
efectiva. Es importante sealar que el ms preciso, o la ms completa o el modelo ms
elegante no es necesariamente es el ms ptimo o el ms til. Todos Los modelos son
incompletos. Todos los modelos son un compromiso.
A fin de ser til, todos los modelos selectivamente representan algunos elementos del
mundo real. El modelador excluye diferentes dimensiones del dominio (a fin de lograr el
modelado goles).
2.6.2 Definicin del alcance del proceso
La tentacin es siempre de saltar directamente y empezar a modelar. Sin embargo, un
enfoque ms considerado normalmente paga dividendos significativos.
El verdadero problema es que a medida que la gente comienza a describir cmo funcionan
las cosas ocurrir en un rea de su organizacin, asumen que todo es un proceso grande. A
menudo lo vemos en nuestros talleres. Los estudiantes tratan de conectar todo junto en una
descripcin del proceso amorfo que captura toda posible permutacin.
Muy a menudo, es extraordinariamente difcil de modelar un "end-to-end" proceso por un
problema de negocio determinado. E incluso si fuera posible, es difcil hacer ese modelo
flexible y adaptable.
Por lo general es mucho mejor para romper un problema en un dominio dado nmero de
discretas "trozos" o entendimiento por partes. Es por ello que es necesario que en el anlisis
de los procesos estos se construyan bajo la base de un mapa de procesos, que trabajando
juntos resolver el problema. As que la cuestin se convierte en uno de cmo llegar a los
trozos rectos. Pero cuando se busca tcnicas, se encuentra notablemente pocos.
Para una discusin ms amplia sobre los diferentes enfoques para la organizacin, modelos
de alcance, consulte el apndice "Tcnicas para la Arquitectura de Procesos". A
continuacin se plantean una serie de planteamientos que, entre ellas, una traduccin de la
estrategia de negocio nivel adecuado a travs de una arquitectura de procesos robustos
(independiente de la estructura de informacin de la organizacin). Potencialmente, estas

tcnicas podran extender en una pila de servicios de TI (como parte de un Service Oriented
Architecture).
Las organizaciones suelen tener una metodologa preferida para la captura y el desarrollo de
sus procesos de negocio. No es el papel de BPMN para dictar cmo la informacin se
recoge de procesos de negocio o cmo modelar se realizan proyectos. Por lo tanto, BPMN
soporta mltiples metodologas (por ser tan simple o tan complejo como debe ser). Lo no
especifica el nivel de detalle de los modelos confeccionados por el modelador, herramienta
de modelado u organizacin que toma estas decisiones. De hecho, como veremos con el
modelado de procesos en general, por lo general existen muchas diversas maneras de
modelar la misma situacin, con cualquier nmero de diferentes niveles de detalle.
BPMN no proporciona ningn consejo sobre cmo estructurar un modelo principal o llegar a
una arquitectura apropiada para una determinada rea. Sin embargo, proporciona
capacidades que pueden soportar muchos mtodos diferentes.
2.6.3. Complejidad de la Notacin de BPMN
As como se puede ver de lo anterior, los procesos de negocio pueden convertirse en
complejo, muy complejo (cubierto en mayor profundidad en el Apndice).
Sin embargo, la mayora de los desarrolladores y los lectores de modelos de procesos
quieren un lenguaje sencillo y grfico para representar los procesos de negocio. En hecho,
la mayora de todos los modelos de procesos son diagramas de flujo (simples cajas de
actividad, los diamantes de decisiones, y los conectores entre ellos). Al mismo tiempo, los
modeladores necesitan flexibilidad suficiente para representar nuevos niveles de
complejidad si es necesario.
El objetivo de la mayora de los proyectos de modelado de procesos es documentar
(Entender) y analizar los procesos de las organizaciones de una clave del negocio. Sin
embargo, estos mismos modelos pueden entonces convertirse en la base para un conjunto
ms detallado de descripciones de procesos para otros usos. Elaborado y construido sobre
con ms detalle, que luego puede convertirse en ejecutable (en una Suite BPM o
herramienta de flujo de trabajo).
Por ejemplo, un modelo bastante simplista (originalmente desarrollado para una discusin
del modelo de negocio), puede llegar a ser adaptado para su uso en establecimiento de
relaciones con los socios adecuados (la definicin de las interfaces), que es despus
refinado y adaptado para el uso dentro de la organizacin de sus respectivos entornos de
ejecucin de procesos.
Dado que cada compaa o modelista lo desea, puede mostrar diferentes niveles o reas de
complejidad, la notacin necesita flexibilidad suficiente para manejar virtualmente todas las
situaciones posibles del negocio o los requisitos de modelado. Pero el problema es que tal
notacin de modelado, uno que es capaz de representar todas las situaciones de negocios,
hay ms simple, es complejo.

Esta cuestin apunta a la tensin dinmica que existe entre los dos objetivos principales de
BPMN:
Por un lado, la facilidad de uso para el usuario de negocios y analista de negocios;
Y en los otros procesos ejecutables.
Para cumplir con los requisitos de la primera meta, BPMN se estructura con un pequeo
conjunto de elementos (por ejemplo, Actividades, Eventos y Gateways) que tienen formas
distintivas (por ejemplo, rectngulo, crculo, y diamante). El pequeo conjunto de elementos
principales apoya la sencillez y la legibilidad de los modelos.
Para cumplir con los requisitos de la segunda meta, los elementos principales estn
especializadas para propsitos especficos, cada uno de los cuales llevan ms informacin y
/ o apoyado con ms elementos para que el modelizacin del comportamiento requerido.
Adems, la estructura semntica de BPMN informacin debe ser rigurosa, es decir se debe
respetar todas las notaciones establecidas en el diagrama, o al menos establecer la
escenario para otras herramientas para completar el desarrollo y despliegue.
La especificacin BPMN incluye una gran cantidad de informacin y las capacidades que
hacen que parezca complicado. Sin embargo, es poco probable que el analista de negocio o
el usuario final necesiten ms de estas caractersticas (como se relacionan con la semntica
de ejecucin). En este manual, vamos a sealar los elementos bsicos de BPMN que
debera atraer a los negocios.
El rol del Analista es importante, mientras que tambin proporciona una descripcin
exhaustiva de los ms avanzados elementos BPMN.
Si bien la tcnica de modelado BPMN puede parecer un poco intimidante para los no
iniciados, es slo tan complejo como necesario ser con el fin de soportar tanto la facilidad de
uso para el analista de negocio y el usuario final, y al mismo tiempo, permitir la elaboracin
de modelos que apoyen la ejecucin del proceso.


EJERCICIOS PRCTICOS
EJERCICIO 1
Justificacin de inasistencia
1. Regularizacin de Asistencia: Usted podr solicitar a Secretara Acadmica
regularizar la asistencia de sus alumnos ingresando al siguiente aplicativo. Cuenta
para ello con la solicitud de regularizacin de asistencia de sus alumnos en Scrates.
Agradeceremos revisar el manual de instrucciones que se encuentra en la parte
inferior.
Los alumnos solicitarn directamente a sus profesores la subsanacin de sus
inasistencias. Los docentes analizarn el caso y determinarn si la solicitud procede.
Los motivos de justificacin de inasistencia pueden ser:
Por motivo de salud: presentando el sustento necesario como certificados mdicos,
ticket atencin Essalud, anlisis clnicos a nombre del alumno, constancias de
hospitalizacin, etc.
Como dato referencial deseamos informarles que se han recibido en procesos
anteriores un mnimo porcentaje de documentos falsos, los ponemos en alerta a fin
de detectar alguna situacin en particular.
Por motivo laboral: presentando el sustento necesario como una constancia de
trabajo, este documento debe acreditar que el alumno se encuentre trabajando en
una empresa, debe indicar la fecha de trabajo y debe estar en hoja membretada. Es
importante recalcar que el alumno que labora debe asistir a clases regularmente y
que cuenta con este motivo para cubrir cualquier contingencia.
Carta de Federacin Deportiva respectiva o de la entidad encargada: Este
documento debe exponer las fechas en las que el alumno no asistir por encontrarse
en un posible evento deportivo.
Por otros motivos: casos vistos slo por Consejeros y/o Bienestar Estudiantil quienes
solicitarn al profesor del curso la correccin de alguna inasistencia por casos
especiales.
2. Registro de Tardanza en Intranet: Tiene a disposicin el marcado de tardanza en
Intranet. Aqu puede visualizar adicionalmente al marcado de asistencia e
inasistencia, la opcin tardanza. Podr utilizar esta opcin (Tardanza) vencido el
plazo de tolerancia para el ingreso a clases dispuesto en Manual del alumno que es
de 15 minutos y hasta 1 minuto antes de finalizar la clase. Cada tres tardanzas es 1
inasistencia y el alumno podr visualizar en Intranet / alumno /inasistencias efectivas
la siguiente pantalla.
En la medida que recomendemos a nuestros alumnos tomar en cuenta la hora de
ingreso y tolerancia, evitaremos la necesidad de realizar el marcado por concepto de
tardanza. Sin embargo, de presentarse el caso, usted cuenta con el aplicativo para
ser utilizado en clase. En caso tenga un percance en la regularizacin de una

tardanza que fue originalmente considerada como inasistencia deber remitir la
solicitud a secretaria el mismo da de ocurrido el inconveniente tomando en cuenta
los siguientes datos:
Datos completos del alumno
Nombre del curso
Fecha de la clase
Seccin
Asimismo, para mantener uniformidad en el control sobre la hora de ingreso a
clases, agradeceremos tomar en cuenta lo dispuesto en el Manual del alumno:
Se considera alumno asistente si es que est presente dentro de los primeros
15 minutos de iniciada la clase. (segn horario)
Se considera alumno con tardanza si ingresa despus de los 15 minutos y
antes de computarse los primeros 30 minutos de clase. (Cada 3 tardanzas= 1
inasistencia).
Se considera alumno inasistente pasados los 30 minutos de iniciada la clase.
Una vez pasado este lmite, es decir, 30 minutos, el alumno no debera ingresar a
clases por respeto al profesor y sus compaeros. Dejamos a su criterio el mejor
manejo de casos que por motivos laborales puedan llegar fuera del plazo sealado.

EJERCICIO 2
La empresa Paradise
La Empresa de transporte Paradise tours S.A. es una empresa dedicada al servicio
especializado de transporte de pasajeros y traslado de encomiendas, convirtindose en muy
poco tiempo en lder en su rubro.
Paradise Tours S.A. fue fundada el 05 de Mayo de 1982, incorporndose exitosamente al
exigente mercado internacional con agencias ubicadas en las principales ciudades de
Sudamrica siendo la principal sede el Per.
Paradise Tours S.A. se caracteriza por su calidad en el servicio y por qu cuenta con la flota
ms moderna en el mercado nacional que se encuentra respaldada por las marcas Volvo,
Scania y Mercedes-Benz contando con una moderna flota de ms de 80 unidades que
obliga a cumplir con un excelente mantenimiento preventivo y correctivo que asegure la
prestacin de los servicios y la seguridad en ruta.
La empresa cuenta con un servicio de transporte de pasajeros durante las 24 horas del da,
los 7 das de la semana y los 365 das del ao, cubriendo las necesidades de transporte a
toda hora.

Los servicios de Paradise tours S.A. que ofrece son Paradise Vip, Business Class, y
Econmico, ya que cuenta con la infraestructura y tecnologa necesaria para entregar un
servicio gil y eficiente pensando en todas las necesidades de sus clientes.
Los diversos talleres de mantenimiento tcnico distribuidas estratgicamente en toda
Sudamrica permiten brindar el mejor servicio tcnico de las unidades siendo su
mantenimiento ms rpido, seguro, completo y efectivo. Incorpora en sus unidades
tecnologa GPS que permite tener la ubicaron exacta de nuestras unidades a toda hora a lo
largo de todas nuestras rutas y as tener permanente control y monitoreo de las unidades
para brindar el mejor servicio y garantizar la seguridad de sus clientes.
Actualmente, Paradise Tours S.A. busca la automatizacin de sus procesos, ya que en su
mayora stos se realizan de forma manual o a travs de archivos Excel, tal es el caso de la
programacin de itinerarios y programacin de viajes, procesos que al ser de gran impacto
para el cliente interno, necesitan de informacin oportuna y sobre todo confiable.
El sistema a desarrollar se centrar en la programacin de itinerarios y de viajes.
Procesos Identificados
Programacin de Itinerarios
Se inicia cuando el Jefe de Marketing solicita la programacin de un itinerario de viaje, en
dicha solicitud indica la ruta con los tramos a ser recorridos (agencia origen y destino, y
escalas si las hubiera), el tipo de unidad a ser asignado y la frecuencia de viaje. El Jefe de
Operaciones consulta el registro de rutas y verifica si existe ruta solicitada, si esta no se
encuentra registrada procede a crearla, para lo cual consulta el registro de tramos y verifica
la existencia las agencias origen y destino y escalas si las hubiera. Luego de haber
verificado la existencia de las rutas y sus tramos procede a registrar el itinerario asignndole
la ruta, el tipo de unidad y el tipo de tripulacin necesario. Adems registra la frecuencia de
viaje para el itinerario.
Finalmente el Jefe de Operaciones elabora una constancia de solicitud atendida y la enva al
Jefe de Marketing, el cual da su conformidad. El proceso termina cuando el Jefe de
Operaciones archiva la solicitud y la constancia con la conformidad del Jefe de Marketing.
Programar Viaje
El proceso comienza cuando Jefe de Ventas solicita la programacin de viajes, en dicha
solicitud indica el itinerario de viaje y la fecha de salida. El Jefe de Operaciones de acuerdo
al itinerario elegido procede a verificar unidades y personal disponibles para poder
asignarlos al viaje. En el caso de no contar con la disponibilidad de algunos de los recursos
antes mencionados El Jefe de Operaciones proceder a elaborar la constancia de solicitud
no atendida. En caso contrario registrar el viaje y le asignar el itinerario y fecha y hora de
salida, el nmero de unidad y el personal requerido.
Finalmente el Jefe de Operaciones elabora una constancia de solicitud atendida y la enva al
Jefe de Ventas, el cual da su conformidad. El proceso termina cuando el Jefe de
Operaciones archiva la solicitud y la constancia con la conformidad del Jefe de Ventas.


Resumen

Es importante definir en las organizaciones la forma como se hace la captura de las
actividades o tareas que se realizan, por eso es importante determinar si todas las
actividades son necesarias, si es que es la forma correcta de hacer las cosas, es que los
resultados esperados son los que se han obtenido despus de haber realizado el
proceso.
Cada diagrama de procesos transfiere informacin muy importante es por eso que es
necesario de que sean detallados respecto a la funcionalidad que se estima en el
proceso.
El uso de la notacin hace de que los procesos se enriquezcan respecto a la informacin
que nos brindan un para su ejecucin y control. La notacin nos brinda informacin
detallada sobre la cadena de valor del negocio.
Es necesario por lo tanto que los procesos sean definidos tanto a nivel de mapas,
descripciones y niveles de modelos.

Pginas De Inters
www.tcpsi.com/servicios/modelado.htm
o En este link encontrar informacin relacionada al modelamiento de procesos
de negocio.
www.elprisma.com/apuntes/curso.asp?id=6034
o En este link encontrar informacin relacionada a la importancia del correcto
modelado de los procesos en las empresas.
www.advice-business.com/es/consejos-1918931.htm
o En este link encontrar informacin relacionada al manejo de procesos de
negocio en la empresas
www.uv.mx/usbi_ver/docs/manuales/man_docum_procesos_usbi.pdf
o En este link encontrar un manual que hace referencia a los tipos de procesos
organizacionales.



BUSINESS PROCESS
MANAGEMENT EN LAS
ORGANIZACIONES
Al trmino de la unidad, el alumno, a partir del correcto entendimiento de la
importancia de un Modelado de Negocio y el uso adecuado de su notacin, podr
identificar los diferentes elementos que se requieren para modelar procesos de
Negocio
TEMARIO
3.1 Introduccin
3.2. La construccin de un proceso con BPMN
3.2.1 Manejo de Eventos
3.2.2 Manejo de Actividades
3.2.3 Manejo de Decisiones
3.2.4 Manejo de Flow
3.2.5 Manejo de Swimlanes o Partitions
3.2.6 Manejo de Artifacts
3.3. Uso de prctico de notacin BPM
3.4. Ajuste de los temporizadores

Los alumnos debern analizar un caso planteado.

UNIDAD
3



3.1. INTRODUCCIN

Diseado para los que vienen a BPMN por primera vez, permite que se familiaricen con las
caractersticas bsicas de la Notacin sin ser abrumados por la complejidad de algunos de
los aspectos ms ocultos.
La mayor parte de la funcionalidad se limita al "ncleo" conjunto de BPMN elementos con
los que un analista de negocios debe estar familiarizado. Este concepto de la coleccin
bsica se ampla en la seccin de referencia.
3.2. LA CONSTRUCCIN DE UN PROCESO CON BPMN
En el modelamiento de negocio se usan tres tipos de notaciones
Las de eventos
Las de actividades
Las decisivas

3.2.1 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 travs de crculos con centro vaco, lo cual permite incluir
diferentes marcadores para diferenciarlos entre s.
Los tipos de eventos se clasifican dependiendo de cundo ellos afectan el flujo:

En esta unidad brindaremos una pequea una introduccin
gradual a la especificacin de BPMN, teniendo un escenario
de fcil comprensin y poco a poco construir sobre ella
procesos cada vez ms complejos.

TIPO DE
EVENTO
DEFINICIN
Inicio Como su nombre lo indica, representa el punto de inicio de
un proceso.

Intermedio Ocurren entre un evento de inicio y de fin. Afectar el
proceso pero no lo iniciar o directamente finalizar.

Fin Indica cuando un proceso termina.

Adicionalmente existen una variedad de eventos, los mismos que podemos dividir en:
Eventos de Inicio
NOMBRE
BPMN
USO NOTACIN
MessageStart Un proceso activo enva un mensaje a otro proceso
especfico para activar su inicio.

Timer Start Se puede fijar una hora-fecha especfica (e.g. todos los
lunes a las 9am) en la que se activar el inicio del
proceso.

SignalStart

Un proceso activo enva una seal y causa el inicio del
proceso. La seal se enva a cualquier proceso que
pueda recibir la seal, pero no es un mensaje (el cual
tiene una fuente especfica y un objetivo).

Eventos de Fin
NOMBRE BPMN USO NOTACIN
Terminador Es el fin del proceso. Solo existe uno por flujo. Si el
proceso alcanza este evento, ste ser cerrado.

Cancelacin Este tipo de Fin es usado dentro de un subproceso de
transaccin. ste indicar que la transaccin debe ser
cancelada y causar un Evento Intermedio de
Cancelacin adjunto a la frontera del subproceso.


Error

Esta figura se usa para capturar errores, si estn definidos
o no. Todos los threads activos actualmente en un
subproceso particular son en consecuencia terminados. El
error ser tomado por un Evento Intermedio de Error con
el mismo Nombre, que est en la frontera de la actividad
pariente ms cercana.

Mensaje

Este tipo de Fin indica que un mensaje se enva a un
proceso o caso de actividad especfica, al concluir el
proceso...

Seal

Este tipo de Fin indica que la seal ser transmitida
cuando el Fin haya sido alcanzado. Note que la seal es
enviada a cualquier proceso que pueda recibir la seal y
pueda ser enviada a travs de los niveles del proceso,
pero no es un mensaje (el cual tiene una fuente y un
objetivo).

Evento Intermedio
NOMBRE
BPMN
USO NOTACIN
Temporizador Esta figura representa un mecanismo de retraso dentro
del proceso. Este tiempo puede ser definido en una
Expresin o como parte de la informacin del proceso
(Fecha o duracin en cualquier unidad de tiempo).

Compensacin El Evento Intermedio indica que es necesaria una
compensacin. Entonces, se usa para "lanzar" el evento
de compensacin. Si una actividad es definida y sta fue
completada exitosamente, entonces la actividad ser
compensada.
Error

Caminos de excepcin del flujo ocurren fuera del flujo
normal del proceso y se basa en un evento intermedio
que ocurre durante el curso del proceso. En la figura me
muestra el uso de lnea de excepcin con un subproceso
y una actividad.


Error

Un Evento de Captura de Error Intermedio puede ser
unido solamente a la frontera de una actividad. Notar que
un Evento de Error siempre interrumpe la Actividad a la
que est unido.

Mensaje

Un Evento Intermedio de Mensaje puede ser usado tanto
para enviar como para recibir un mensaje. Cuando se usa
para "lanzar" el mensaje, un marcador DEBE ser llenado.
Cuando se usa para "atrapar" el mensaje el marcador
DEBE estar sin llenar. Esto causa que el proceso contine
si ste estaba esperando por el mensaje o cambia el flujo
para manejo de excepciones. Para atrapar y lanzar
mensajes debe tener el mismo nombre.

Enlace

Un Enlace es un mecanismo para conectar dos secciones
de un Proceso. Los Eventos de Enlace pueden ser
usados para crear situaciones de bucle o para evitar
lneas de Secuencia de Flujo largas. Los usos de los
Eventos de Enlace son limitados a un solo nivel de
proceso.

Seal

Las seales son usadas para enviar o recibir
comunicaciones generales dentro y a travs de los niveles
de Proceso y entre Diagramas de Proceso de Negocio.
Una seal BPMN es similar a una seal de bengala que
se dispara al cielo para cualquiera que pudiera estar
interesado y luego reaccionara. Entonces hay una fuente
de la seal, pero ningn objetivo especfico.

3.2.2 Actividades
Las actividades representan trabajo o tareas realizadas por miembros de la organizacin.
Este elemento simboliza tareas manuales o automticas llevadas a cabo por un usuario o un
sistema externo.
Las actividades pueden ser atmicas o no atmicas (compuestas).
Una actividad es representada por un rectngulo con bordes redondeados.
Se clasifican en tareas y subprocesos. Los subprocesos se distinguen por un signo ms en
la parte inferior central de la figura. Los siguientes son los tipos de actividades:

NOMBRE
BPMN
USO NOTACIN
Tarea de
Usuario
Es una tarea de flujo de trabajo donde un
humano realiza una tarea que tiene que ser
completada en cierta cantidad de tiempo. Se usa
cuando el trabajo durante el proceso no puede ser
descompuesto en un nivel ms fino dentro del
flujo. Tarea de usuario

Tarea de
Servicio
Una Tarea de Servicio es una tarea que usa algn
tipo de servicio, que podra ser un servicio Web o
una aplicacin automtica. Tarea de Servicio.

Tarea de Recibir
Una Tarea de Recibir es una tarea simple para
que llegue un mensaje. Una vez el mensaje haya
sido recibido, la tarea es completada. Tarea de
Recibir.
Tarea de Enviar

Una tarea de Enviar es una tarea simple que es
designada para enviar un mensaje a un proceso o
caso especfico. Una vez el mensaje haya sido
enviado, la tarea es completada. Tarea de Enviar.

Script

Una tarea de Script es una tarea automtica en la
que el servidor ejecuta un script. No tener
interaccin humana y no se conecta con ningn
servicio externo. Tarea
Manual

sta es una Tarea que se espera que sea
realizada sin la ayuda de algn motor de
ejecucin de proceso de negocio o alguna
aplicacin. Un ejemplo de esto puede ser una
secretaria archivando documentos fsicos. Tarea
Manual.

Subproceso

Un subproceso es una actividad compuesta
incluida dentro de un proceso. ste es compuesto
dado el hecho que esta figura incluye un conjunto
de actividades y una secuencia lgica (proceso),
que indica que la actividad mencionada puede ser
analizada a un nivel ms fino. Se puede colapsar


o expandir. Subproceso.
Subproceso
Mltiple

Esta propiedad del subproceso permite la
creacin de instancias mltiples. Cada instancia
representa una relacin 1-N dentro del proceso.
Subprocesos mltiples aplican slo para procesos
no embebidos. Subproceso Mltiple.

Subproceso
Transaccional

Un Subprocesos Transaccional facilita la
implementacin de escenarios de negocio con
transacciones cuyas ejecuciones podran durar
muchos das o semanas hasta que el conjunto de
actividades sea completado. Una transaccin es
realizada exitosamente cuando los cambios a ser
implementados (actualizacin, adicin o
eliminacin de registros) son grabados en la base
de datos. Transaccional.

Subproceso
Embebido

Contiene un conjunto de actividades que no son
independientes del proceso pariente, y por esto,
comparten la misma informacin o datos.

3.2.3 Decisiones
Las Decisiones son usadas para controlar la divergencia y convergencia del flujo. stas
determinan ramificaciones, bifurcaciones, combinaciones y fusiones en el proceso.
Son utilizadas por una figura de diamante. Marcadores internos mostrarn el tipo de control
que se usa.
Iconos en la figura de diamante indica el tipo de comportamiento del control de flujo.
Tipos de control incluyen:
TIPO DE
DECISIN
DEFINICIN NOTACIN
Decisin
Exclusiva
Decisin basada en datos del sistema.
El mismo elemento se usa para sincronizar esta
figura. Decisin Exclusiva


Decisin
Basada
en Evento
Puntos en el proceso en el que la decisin no
est basada en los datos del proceso sino en
eventos. Decisin Basada en Evento.

Decisin
Inclusiva

Inclusiva o multi-decisin. Uno o ms caminos
pueden ser activados. Uno o ms caminos
deben sincronizarse dependiendo de las
actividades anteriores de la misma figura.
Decisin Inclusiva

Decisin
Compleja

Elemento para controlar puntos de una decisin
compleja. Por ejemplo, cuando 3 de 5 caminos
deben esperar. Decisin Compleja.

Decisin
Paralela

Indica puntos en el proceso en el que varias
ramas se desprenden o convergen en paralelo.
El mismo elemento se usa para sincronizar esta
figura. Decisin Paralela .

3.2.4 Elementos del tipo Flowo Lneas de Secuencia
Las lneas de secuencia son usadas para mostrar el orden en que las actividades sern
llevadas a cabo en el proceso.
Son representadas por una flecha indicando desde y hasta.
Los tipos de lneas de secuencia incluyen:
TIPO DE
LNEA
NOMBRE
ORIGINAL
DEFINICIN NOTACIN
Lnea
normal
Normal
Flow
La lnea normal se refiere al flujo que se
originan en el inicio, contina a travs
de actividades hasta terminar en un
evento de salida (por ejemplo el FIN).

Flujo
Condicional
Conditional
Flow
Este flujo tiene una condicin asignada
que define si el flujo es usado. Se
puede asignar a cualquier figura en el
proceso que requiera evaluar una
condicin para seguir cierto camino.

Lnea por
Default
Default
Flow
Para decisiones basadas en datos o
decisiones inclusivas, un tipo de
camino del flujo es el de condiciones


por default. Este tipo de transiciones
se presenta nicamente si todas las
otras condiciones son no verdaderas en
un mismo instante.
Una vez asignada la condicin Else a
la transicin, se ver la flecha como
aparece en el dibujo a la derecha.

3.2.5 Elementos del tipo Swimlanes o Partitions
Los Swimlanes tambin conocidos como carriles representan participantes en un
proceso.
En ciertas ocasiones, hay un diagrama de actividad que se expande a lo largo de ms de
una entidad o actor. Cuando esto ocurre, el diagrama de actividad es particionado en
canales (swimlines), donde cada carril representa el responsable (rea o actor) que est
llevando a cabo la actividad.
Los carriles son utilizados como un mecanismo para organizar actividades en categoras
visuales separadas para ilustrar las diferentes responsables.

Fig. 3.1. Ejemplo de la grafica de un proceso en BMP

Otro elemento que puede presentarse dentro de modelado de proceso de negocio son las
Fases que son una sub-particin dentro de un carril y se extiende sobre ste verticalmente.
Las Fases son usadas para organizar y categorizar actividades que muestran los posibles
estados que puede tener un proceso durante su ciclo de vida.
En general, una fase define el estado macro del negocio. Cada fase representa un estado
del proceso.

Fig 3.2. Ejemplo de la grfica de un proceso en BMP desarrollado a detalle

3.2.6 Elementos del tipo Artefactos
Artefactos
Los Artefactos son objetos grficos que proveen informacin de soporte sobre el Proceso o
elementos dentro del proceso. Sin embargo, estos no afectan directamente el flujo del
proceso.
Un Artefacto NO DEBE ser un objetivo para el Flujo de Secuencia.
Existen tres tipos de artefactos:
Los grupos,
Las anotaciones,
Objetos de datos

Grupos
Se utiliza para agrupar un conjunto de actividades, ya sea para efectos de
documentacin o anlisis, sin embargo, no afecta la secuencia del flujo.
Se representa mediante un Rectngulo redondeado dibujado con lnea
segmentada.
Anotaciones
Son mecanismos para que un modelador pueda proveer informacin adicional
en un diagrama de BPMN.
Se representa mediante un cuadro para incluir informacin.
Objetos de Datos
Provee informacin sobre cmo los documentos, datos y otros objetos son
usados y actualizados durante el proceso. Se puede usar para representar
objetos electrnicos y fsicos.
Se representa mediante un icono de documento.

3.3. USO PRCTICO DE NOTACION BPM
El escenario central que se utiliza en esta unidad gira en entorno a una organizacin ficticia
Ciber SAC. Se reciben solicitudes de los clientes potenciales, hacer una evaluacin si
ofrecer o no la hipoteca, y luego rechazar cualquier la aplicacin o realizar la oferta.

Fig. 3.3. Desarrollo del Flujo de Proceso estndar

Claramente, esta es una imagen bastante simplista de cmo un proceso podra operar. Pero
va a ser suficiente para proporcionar el contexto para nosotros para introducir la
funcionalidad de BPMN. A travs del resto de esta parte del manual, que sistemticamente
se basar en este caso.
El proceso comienza por la izquierda con un Evento de Inicio (crculo lnea fina), con dos
actividades (rectngulos redondeados) conectado a la Start Evento con flujo de secuencia
(las flechas). La primera actividad es una tarea y el segundo representa un sub-proceso. A
raz de una decisin, representada por el diamante (llamado compuerta exclusiva), la
Proceso, entonces las ramas ya sea en "Ciber Oferta" o "Enviar Rechazo" (ambos
representados aqu como tareas simples). Ambas ramas conducir a un evento final (crculo
de grosor).
Eventos de Inicio representan los lugares que el proceso puede comenzar, fin Eventos
representan resultados diferentes, algunas de las cuales podran ser deseados y otros no.
Una compuerta exclusiva representa un binario de decisin solamente una secuencia de
flujo saliente puede evaluar como verdadera. Para los efectos de este modelo, las tres
tareas representan sencillo "Atmicas" pasos, mientras que el colapso Sub-Proceso tiene un
mayor nivel de detalle.

3.4. AJUSTE DE LOS TEMPORIZADORES
Ahora, supongamos que queremos representar el hecho de que nuestro cliente potencial
contacto Ciber SAC pedir una formulario de solicitud de hipoteca. Por el momento, no lo
haremos preocuparse precisamente la forma en que contact a la empresa, pero vamos a
suponer que era un "mensaje" de algn tipo. Adems, hemos deseado establecer un reloj en

marcha para enviarles un recordatorio despus siete das si Ciber SAC no recibe su solicitud
formar parte posterior.

Fig 3.4. Desarrollo del Flujo de Proceso estndar con uso de temporizador

El proceso comienza ahora con un Evento de Inicio Mensaje que representa el mensaje
recibido por Ciber Hipotecarios que a continuacin, enva el formulario de solicitud; un
temporizador se coloca en la tarea de espera para interrumpir y enviar un recordatorio antes
de regresar de nuevo a esperar a que el formulario de solicitud de nuevo.
Hay muchos tipos de eventos de arranque en BPMN, aqu hemos utilizado un mensaje de
inicio del evento para indicar que este proceso comience. Los eventos intermedios
colocados en el lmite de una tarea significa que s.
Se desencadena el evento, entonces se interrumpir la tarea y enve el proceso por su
secuencia de flujo saliente.
Si la tarea se completa antes de tiempo se desencadena el evento intermedio, entonces el
proceso se mueve con normalidad (Siguiendo el flujo normal del proceso). El bucle se crea
explcitamente con flujo de secuencia, aunque, como descubriremos ms tarde, hay
alternativas (es decir, el uso de una tarea Loop).
Hay otra forma de modelar este escenario usando un proceso de Sub-proceso para enviar el
formulario de solicitud y esperar la respuesta.
El evento de temporizador intermedio se muestra de acuerdo con la secuencia de Flujo, y
desencadena inmediatamente el proceso de Sub-comienza (el subproceso se muestra en su
forma expandida). Se espera durante siete das antes de que el hilo se mueva de actividad
para el " Enviar Recordatorio" que es una Tarea. Antes de regresar a esperar otros siete
das. Cuando un evento intermedio es usado en lnea (como en este caso), entonces puede
tener slo un flujo de salida de secuencia entrante y uno. Por lo tanto, la fusin de la
secuencia de flujo entrante antes que el evento de temporizador Intermedio requiere una
compuerta exclusiva.
Al combinar secuencias de flujo, una compuerta exclusiva inmediatamente pasa a travs de
cualquier secuencia de flujo entrante de modo que en este caso sirve para limpiar el flujo de
secuencia (pero no representa ningn tipo de retraso).


Fig. 3.5. Desarrollo del Flujo de Proceso estndar con el uso de un subproceso y
compuerta inclusiva

Por supuesto, otros objetos de flujo (Actividades o Gateways) normalmente puede ser un
Flujo de Secuencia tener mltiples entradas y salidas. Mientras que el Sub-Proceso podra
haber incluido una puerta de enlace paralelo para crear la dividir (vase la figura 3.5), no es
necesario que la secuencia de flujo realizada no requieren de control.
La Figura 3.4 y la Figura 3.5 describen exactamente el mismo comportamiento. Una regla
general es que las puertas de enlace slo se requieren donde Secuenciar el flujo y esto
requiere de control.
El subproceso termina con un evento Terminate End. El Evento de Fin provoca el cese
inmediato del Proceso en su nivel actual (y abajo) incluso si todava hay actividad en curso.
Efectivamente, esto mata el lazo recordatorio.

Fig 3.6. Desarrollo del Flujo de Proceso estndar con el uso de un subproceso y
compuerta paralela


EJERCICIOS PARA DESARROLLO EN CLASE
EJERCICIO 01
Trate de modelar este proceso, que le ayudar a asegurarse de que las tcnicas
presentadas hasta ahora:
Todas las maanas entre semana, en la base de datos se copian los datos de los morosos,
luego se comprueba para ver si su estado es de "Moroso en cuenta", estos datos estn
registrados en una tabla de nuestra base de datos debido a que se registran como datos
nuevos. Si no hay registros que sean nuevos, entonces el proceso debe comprobar en el
Sistema de CRM para ver si los clientes han presentado nuevos requerimientos de deudas.
Si se vuelve a existir nuevas deudas, a continuacin, registrar todas en las cuentas de
morosos y clientes. Si los datos de los clientes son nuevos, es decir no se han registrado
anteriormente, los datos deben registrarse en la tabla de morosos en cuenta, esta
informacin debe de enviarse a la administracin de cuentas a fin de registrar sus datos.
Todo esto se debe completar antes de las 2:30 pm, si no lo es, entonces se debe generar
una alerta la misma que debe ser enviada al supervisor. Una vez que el nuevo informe de
incumplimiento en cuenta se ha completado, compruebe el sistema CRM para ver si las
nuevas declaraciones de deuda han sido presentadas. Si se vuelve a presentarse nuevas
cuentas por cobrar, se debe actualizar la tabla de los morosos. Esto debe ser completado
antes de las 4:00 pm de otra manera que un supervisor debe enviar un mensaje, terminando
all el proceso.
EJERCICIO 02
En una empresa se realizan instalacin de equipos de audio se ha decidido hacer uso de la
metodologa BPM, debido a esto es que se le solicita hacer el diagrama de flujo segn la
entrevista realizada
Flujo Bsico
1. El cliente solicita la instalacin de un equipo de audio adjuntando el equipo a instalar.
2. El supervisor elabora un diagrama de instalacin y solicita al tcnico instalador la
revisin del automvil.
3. El tcnico instalador realiza la revisin del automvil.
4. Si es factible la instalacin, el tcnico instalador informa al supervisor a travs del
informe de instalacin de los pasos a realizar para la instalacin adems de los insumos
necesarios.
5. El supervisor elabora la cotizacin y se la presenta al cliente.
6. El cliente evala la cotizacin.
7. Si el cliente acepta la cotizacin, el supervisor indica al tcnico instalador que proceda
con la instalacin.
8. El tcnico instalador procede con la instalacin y realiza las correcciones necesarias.
9. El supervisor revisa la instalacin realizada y prueba el equipo de audio.

10. Si est bien instalado el equipo de audio, el supervisor hace entrega del automvil al
cliente.
11. El cliente se dirige a caja y realiza el pago.
12. El cajero le entrega el comprobante de pago al cliente.
13. El cliente procede a retirar su auto.

Flujos Alternativos
1. En el punto 4, si no es factible la instalacin:
1.1. El tcnico instalador le informa al supervisor indicndole los motivos a travs del
informe de instalacin.
1.2. El supervisor se lo indica al cliente y el proceso termina.
2. En el punto 7, si el Cliente no acepta la cotizacin:
2.1. El Cliente se lo indica al supervisor y el proceso termina.
3. En el punto 10, si se requiere realizar ajustes en la instalacin:
3.1. El supervisor le indica al tcnico instalador que debe realizar ajustes en la
instalacin y se reinicia el proceso desde el paso 8.
EJERCICIO 03
Otro rompecabezas, pero pensar cuidadosamente acerca de todas las cosas cubiertas en el
manual hasta el momento:
En noviembre de cada ao, la Unidad de Coordinacin de la Planificacin Urbana elabora un
calendario de reuniones para el prximo ao calendario y agrega fechas proyectos de todos
los calendarios. El oficial de apoyo comprueba las fechas y sugiere modificaciones.
La Unidad de Coordinacin luego vuelve a verificar todas las fechas y busque posibles
conflictos. La lista definitiva de las fechas de reunin se enva a todos los miembros del
Comit independientes por correo electrnico, a continuacin, se debe comprobar que sus
agendas estn disponibles y asesorar a la Unidad de Coordinacin de cualquier conflicto.
Una vez que las fechas han sido finalizadas por la Unidad de Coordinacin, el Oficial de
Apoyo actualiza todos los calendarios de grupo y crea reunin carpetas para cada reunin y
asegura que todos los documentos pertinentes estn cargados en el sistema. Los miembros
del Comit se aconsejan una semana antes cada reunin de leer todos los documentos
relacionados. Los miembros del Comit celebrar su reunin, y la Oficina de Apoyo minutos
despus produce incluidos los puntos de accin para cada miembro del comit. Dentro de
los 5 das hbiles a la Unidad de Coordinacin debe llevar a cabo una verificacin de control
de calidad en los minutos que luego se envan a todos los miembros del Comit. El oficial de
apoyo luego actualiza todos los registros departamentales.
EJERCICIO 04
Despus de que el informe de gastos se recibe una nueva cuenta debe ser creado si el
empleado no tiene ya uno. El informe es revisado para la aprobacin automtica. Las
cantidades de menos de $200 se aprueban automticamente, mientras que cantidades
iguales o superiores a $ 200 requieren la aprobacin del supervisor.

En caso de rechazo, el empleado debe recibir un aviso de rechazo por correo electrnico. El
reembolso va al banco del empleado de depsito directo cuenta. Si la solicitud no se
completa en 7 das, entonces el empleado debe recibir una "aprobacin en curso" e-mail.
Si la solicitud no ha terminado dentro de 30 das, entonces el proceso es detenido y el
empleado recibe una notificacin de cancelacin y de correo electrnico debe volver a
presentar el informe de gastos.
EJERCICIO 05
Despus de iniciado el proceso, una tarea que se realiza para localizar y distribuir los
diseos existentes pertinentes, tanto elctricas y fsicas. A continuacin, el diseo de los
sistemas elctricos y fsicos comienza en paralelo. Cualquier existente o diseos previos
elctricas y fsicas son las entradas a las dos actividades.
Desarrollo de cualquiera de los diseos es interrumpido por una actualizacin correcta del
otro diseo. Si se interrumpe, entonces todo el trabajo actual se detiene y que el diseo
debe reiniciar.
En cada departamento (Diseo Elctrico y diseo fsico), cualquier existente diseos son
revisados, dando lugar a un plan de actualizacin para sus respectivos trazado (es decir,
uno de cada elctricos y otro en Fsica). Usando la actualizacin Plan y el Proyecto actual
del Diseo Elctrico / Fsica, una versin revisada del diseo es creado. Una vez
completado el diseo revisado se prueba. Si el diseo no pasa la prueba, entonces se enva
de nuevo a la primera actividad (en el departamento) para revisar y crear un plan de
actualizacin de nuevo. Si el diseo pasa el examen y luego le dice al otro departamento
que tenga que reiniciar su trabajo.
Cuando ambos de los diseos han sido revisados, que se combinan y se probado. Si el
diseo combinado no supera la prueba, y luego ambos se enviaron volver al principio para
iniciar otro ciclo de diseo. Si los diseos pasar la prueba, entonces se considerar
completa y luego se envan a la Proceso de fabricacin [un proceso separado]
EJERCICIO 06
La empresa SECURITY S.A. tiene en su equipo comercial la difcil tarea de obtener
contratos de servicios de Seguridad, esta tarea se inician cuando un cliente se pone en
contacto con la empresa; es atendido por un vendedor quien le genera un presupuesto,
verificando previamente si el cliente se encuentra registrado. Si no se encuentra lo registra.
Cuando el cliente est de acuerdo con el presupuesto, el Supervisor de Ventas registra un
contrato, realizando una bsqueda de Presupuestos. Todos los contratos son entregados al
Gerente General para su evaluacin quin registra el resultado de la evaluacin,
previamente realiza una bsqueda de contratos.

El Gerente General entrega copias de los contratos al Departamento de Cobranza, la
Secretaria de Cobranza emite los Comprobante de pagos (facturas), previamente realiza
una bsqueda de contratos.
Cada viernes la Secretaria asigna un cobrador a cada Comprobante emitido, realizando una
bsqueda de comprobantes. Al final del da registrar el pago de los comprobantes,
realizando una bsqueda de comprobantes para realizar la cancelacin del comprobante. La
secretaria de cobranza puede adicionalmente actualizar los datos de los clientes como
telfono, correo, direccin, etc.


Resumen

BPMN es un lenguaje formal que permite modelar, simular y, eventualmente, ejecutar
procesos de negocios.
Su sintaxis est basada en elementos grficos.
Los elementos de construccin determinan el comportamiento de los flujos de proceso
es por eso que es importante identificar los diferentes artefactos y su adecuado uso.
No se olvide que existen tipos de eventos, actividades y decisiones.
Fue desarrollado por la organizacin BPM Initiative, pasando posteriormente a fundirse
con los esfuerzos que en paralelo realizaba el OMG. Con esto hay grandes posibilidades
de que BPMN se convierta en el lenguaje estndar acerca de procesos de negocios, tal
como UML, bajo el auspicio de la OMG, se ha convertido en el estndar para
modelamiento de software
Pginas de Inters
www.dis.um.es/~jmolina/jis2000modeladonegocio.pdf
o En este link encontrar informacin respecto a modelamiento de negocio.
www.inf.udec.cl/~revista/ediciones/edicion9/cjimenez.pdf
o En este link encontrar informacin respecto a modelamiento de negocio con
metodologa BPM
www.vico.org/TRAD_obert/TRAD_BPM_abierto.html
o En este link encontrar informacin respecto a modelamiento de negocio con
metodologa BPM
www.upload.wikimedia.org/wikipedia/commons/a/ac/BPMN_Poster.pdf
o En este link encontrar
o informacin respecto a modelamiento de negocio con metodologa BPM,
incluye una grfica de elementos de notacin.


FUNDAMENTOS DE UML:
UNIFIED MODELING LANGUAGE
Al trmino de la unidad, el alumno, a partir del correcto entendimiento de la
importancia de Unified Modeling Language (UML)y el uso adecuado de su notacin,
podr identificar los diferentes elementos que se requieren para modelar procesos
de Negocio
TEMARIO
4.1 UML (Unified Modeling Language) Definiciones
4.1.1 Nociones Generales de UML
4.1.2 Importancia de uso de UML
4.1.3 Aplicacin de UML en las Organizaciones de TI

4.2 UML (Unified Modeling Language) Uso de Diagramas
4.2.1 Diagramas de UML
4.2.2 Interaccin de UML con el modelado de Procesos de Negocio
(Business Process Modeling)
4.2.3 Notaciones usadas en el modelado de Procesos de Negocio (Business
Process Modeling)

4.3 UML (Unified Modeling Language) Uso de Elementos
4.3.1 Uso de elementos del tipo Flow
4.3.2 Uso de elementos del tipo Swimlanes (Partitions)
4.3.3 Uso de elementos del tipo Artifacts

Los alumnos debern analizar el caso planteado.

UNIDAD
4



4.1 UML (UNIFIED MODELING LANGUAGE) Definiciones
4.1.1 Nociones Generales de UML Qu es UML?
El lenguaje UML comenz a gestarse en octubre de 1994, cuando Rumbaugh se uni a la
compaa Rational fundada por Booch (dos reputados investigadores en el rea de
metodologa del software).
El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo Booch y
el OMT (Object Modelling Tool). El primer borrador apareci en octubre de 1995. En esa
misma poca otro reputado investigador, Jacobson, se uni a Rational y se incluyeron ideas
suyas. Estas tres personas son conocidas como los tres amigos. Adems, este lenguaje se
abri a la colaboracin de otras empresas para que aportaran sus ideas. Todas estas
colaboraciones condujeron a la definicin de la primera versin de UML. (Ver fig. 4.1)
UML quiere decir Unified Modeling Language
UML es un lenguaje estndar para visualizar, especificar, construir y documentar los
artefactos de un sistema de software esto basado en un correcto diseo del Modelo de
Negocio.
UML puede usarse en las diferentes etapas del ciclo de vida del desarrollo y en
diferentes tecnologas de implementacin
UML es independiente del proceso de desarrollo de software

Fig. 4.1. Roles de modelamiento

Breve Historia de UML
Los lenguajes de modelado de objetos aparecieron en la dcada de 1980, llegando a ser
unos 50 a mediados de la dcada de 1990. Unos pocos mtodos empezaron a ganar
importancia, ente ellos: el Mtodo OMT (Object-Modeling Technique) de James Rumbaugh,
que era mejor para el anlisis orientado a objetos, el Mtodo Booch de Grady Booch, el
cual era mejor para el diseo orientado a objetos, y el Mtodo OOSE (Object-Oriented
Software Engineering) de Ivar Jacobson, que era un mtodo de ingeniera de software
orientado a objetos.
Cdigo
Matrcula
Proyecto
Aprobacin
Anteproyect
o

Procesos
Principales
Realizacin
Plan Director
Funcionalidad
Docume
ntacin
Especifi
Anlisis
Diseo
Interfaces
Bases de Datos
Componentes
Despliegue

El esfuerzo para la definicin de UML comenz en Octubre de 1994, cuando Rumbaugh
se uni a Booch en Rational Software Corporation (empresa donde trabajaba Booch).
Unificaron sus mtodos de modelado y elaboraron el borrador de la versin 0.8 de UML. En
1995 Jacobson tambin se incorpor a Rational, incorporando as OOSE a UML. En 1996 se
public la versin 0.9 de UML. Las tres personalidades que dieron el origen a UML son
conocidas como los Tres Amigos.

Fig. 4.2. Promotores de UML

Las organizaciones que contribuyeron a la definicin de 1.0 de UML fueron Digital
Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. El borrador de la
especificacin UML 1.0 se ofreci para su estandarizacin a OMG (Object Management
Group) en enero de 1997.

Luego de varios aos y varias modificaciones, OMG adopt la versin oficial de UML 2.0 a
principios del ao 2005, versin que integra varios esfuerzos para la definicin de una
semntica de la especificacin ms slida. Actualmente va por la versin 2.4.1. la cual
fue liberada en Agosto 2011. En la siguiente figura se muestra las URLs de la pgina web
de OMG que contiene las especificaciones de UML por versiones.

Versiones de UML lanzado formalmente por OMG
Versin Fecha del lanzamiento URL
2.4.1 Agosto 2011 http://www.omg.org/spec/UML/2.4.1
2.4 Marzo 2011 http://www.omg.org/spec/UML/2.4
2.3 Mayo 2010 http://www.omg.org/spec/UML/2.3
2.2 Febrero 2009 http://www.omg.org/spec/UML/2.2
2.1.2 Noviembre 2007 http://www.omg.org/spec/UML/2.1.2
2.1.1 Agosto 2007 http://www.omg.org/spec/UML/2.1.1
2.0 Julio 2005 http://www.omg.org/spec/UML/2.0
1.4 Setiembre 2001 http://www.omg.org/spec/UML/1.4
Versin en proceso de UML
Versin Fecha del lanzamiento URL
2.5 October 2012 http://www.omg.org/spec/UML/2.5

Fig. 4.3. Lanzamiento de versiones de UML por OMG

4.1.2 Importancia de UML
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y
documentar artefactos de un sistema de software. Se usa para entender, disear, configurar,
mantener y controlar la informacin sobre los sistemas a automatizar.
UML capta la informacin sobre la estructura esttica (Modelo de Negocio y sistema) y el
comportamiento dinmico de un sistema (Modelo de Anlisis). Un sistema se modela como
una coleccin de objetos discretos que interactan para realizar un trabajo que finalmente
beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de
modelado e incorporar las mejores prcticas actuales en un acercamiento estndar.
Tal como se mencion en el apartado anterior, la notacin UML se deriva y unifica los
mtodos de anlisis y diseos ms extendidas, creados por los fundadores de UML:
Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus
relaciones.
Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object
Modelling Technique).
Enfoque de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la
metodologa de casos de uso (use case).

Cules son las reas conceptuales de UML?
Los conceptos y modelos de UML pueden agruparse en las siguientes reas conceptuales:
(Ver Fig. 4.4)

Fig. 4.4. Vistas de UML

Estructura Esttica
Cualquier modelo de negocio o sistema debe primero definir su universo, esto es, los
conceptos clave de la aplicacin, sus propiedades internas, y las relaciones entre cada una
de ellas. Este conjunto de construcciones es la estructura esttica.

VISTA LOGICA VISTA DE PROCESOS
VISTA FISICA VISTA DE DESARROLLO
VISTA DE CASOS
DE USO

Los conceptos de la aplicacin son modelados como clases, cada una de las cuales
describe un conjunto de objetos que almacenan informacin y se comunican para
implementar un comportamiento.
La informacin que almacena es modelada como atributos; La estructura esttica se
expresa con diagramas de clases y puede usarse para generar la mayora de las
declaraciones de estructuras de datos en un programa.
Comportamiento dinmico
Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la
forma como interacta con el resto del mundo y la otra es por los patrones de comunicacin
de un conjunto de objetos conectados, es decir la forma en que interactan entre s.
La visin de un objeto aislado es una mquina de estados, muestra la forma en que el objeto
responde a los eventos en funcin de su estado actual. La visin de la interaccin de los
objetos se representa con los enlaces entre objetos junto con el flujo de mensajes y los
enlaces entre ellos.
Este punto de vista unifica la estructura de los datos, el control de flujo y el flujo de datos.
Construcciones de implementacin
Los modelos UML tienen significado para el anlisis lgico y para la implementacin fsica.
Un componente es una parte fsica reemplazable de un sistema y es capaz de responder a
las peticiones descritas por un conjunto de interfaces.
Un nodo es un recurso computacional que define una localizacin durante la ejecucin de un
sistema. Puede contener componentes y objetos.
Mecanismos de extensin
UML tiene una limitada capacidad de extensin pero que es suficiente para la mayora de
las extensiones que requiere el da a da sin la necesidad de un cambio en el lenguaje
bsico.
Un estereotipo es una nueva clase de elemento de modelado con la misma estructura que
un elemento existente pero con restricciones adicionales.
Organizacin del modelo
La informacin del modelo debe ser dividida en piezas coherentes, para que los equipos
puedan trabajar en las diferentes partes de forma concurrente.
El conocimiento humano requiere que se organice el contenido del modelo en paquetes de
tamao modesto. Los paquetes son unidades organizativas, jerrquicas y de propsito
general de los modelos de UML.
Pueden usarse para almacenamiento, control de acceso, gestin de la configuracin y
construccin de bibliotecas que contengan fragmentos de cdigo reutilizable.


Elementos de anotacin
Los elementos de anotacin son las partes explicativas de los modelos UML. Son
comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre
cualquier elemento de un modelo.
El tipo principal de anotacin es la nota que simplemente es un smbolo para mostrar
restricciones y comentarios junto a un elemento o un conjunto de elementos
Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia,
asociacin, generalizacin y realizacin, estas se describen a continuacin.
Dependencia
Es una relacin semntica entre dos elementos en la cual un cambio a un elemento (el
elemento independiente) puede afectar a la semntica del otro elemento (elemento
dependiente). Se representa como una lnea discontinua, posiblemente dirigida, que a veces
incluye una etiqueta.
Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones
entre objetos. La agregacin es un tipo especial de asociacin y representa una relacin
estructural entre un todo y sus partes.
La asociacin se representa con una lnea continua, posiblemente dirigida, que a veces
incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y
roles de los objetos involucrados
Generalizacin
Es una relacin de especializacin / generalizacin en la cual los objetos del elemento
especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre).
De esta forma, el hijo comparte la estructura y el comportamiento del padre. Grficamente,
la generalizacin se representa con una lnea con punta de flecha vaca.
Realizacin
Es una relacin semntica entre clasificadores, donde un clasificador especifica un contrato
que otro clasificador garantiza que cumplir.
Se pueden encontrar relaciones de realizacin en dos sitios: entre interfaces y las clases y
componentes que las realizan, y entre los casos de uso y las colaboraciones que los
realizan.
La realizacin se representa como una mezcla entre la generalizacin y la dependencia,
esto es, una lnea discontinua con una punta de flecha vaca.


4.1.3 Aplicacin de UML en las Organizaciones de TI
Por qu es importante el UML en las organizaciones?
Para todas las empresas y negocios es importante mantener una estrecha relacin con los
clientes para conocer sus gustos, hbitos y necesidades, de manera que favorezca, en la
medida de lo posible, la ya de por s compleja labor comercial.
En este sentido, la incorporacin de estrategias basadas en soluciones Tecnolgicas facilita
ese entendimiento y proporcionan resultados significativos a las empresas.
El uso de tecnologas es una estrategia que permite a las empresas identificar, atraer y
retener a sus clientes, adems de ayudarles a incrementar la satisfaccin de estos y a
optimizar as la rentabilidad de sus negocios.
Hablamos, por tanto, de tecnologas como estrategia, lo que implica no solo disponer del
software adecuado que les permita gestionar las relaciones con los clientes, sino que
adems, supone un cambio en los procesos de la empresa y la participacin de todos los
empleados de la misma, para que esta estrategia tenga xito; es all donde radica la
importancia del entendimiento del UML como piedra angular en su desarrollo.
La clave est en descubrir nuevos caminos que proporcionen una mayor proximidad con los
clientes, que generen una relacin satisfactoria y duradera para ambas partes y que
fomenten su fidelidad hacia la empresa. Cada vez ms, las organizaciones con xito son
aquellas que dan prioridad a sus clientes por encima de todo, las que utilizan sistemas
orientados al cliente y las que desarrollan procesos para innovar, atraer y dar un servicio
que satisfaga las necesidades del cliente.
Por qu es importante el uso de las Tecnologas en las organizaciones?
El uso de tecnologas es una importante estrategia de negocio, tanto para empresas de e-
business como para compaas tradicionales, a la hora de hacer frente a un mercado cada
vez ms competitivo y exigente. La evolucin de Internet ofrece infinitas oportunidades a las
empresas, pero tambin ha abierto un nuevo mundo a los clientes. (Ver fig. 4.5)
Ahora es ms fcil para estos el manejo de servicios ms sofisticados, lo que les hace estar
ms y mejor informados sobre todo lo que les rodea. Por ello, el uso de tecnologas es una
estrategia fundamental para el desarrollo de polticas de e-business en cualquier empresa.
El objetivo debe centrarse en proporcionar una serie de procesos orientados al cliente a
travs de los distintos departamentos y canales, de manera que permitan atraer y retener a
los clientes. En esta espiral por la gestin de la relacin con el cliente se han desarrollado
una amplia gama de soluciones tecnolgicas que proporcionan a las empresas la
informacin necesaria y los caminos ms adecuados para optimizar sus estrategias
comerciales.


Fig. 4.5. Efectos de la implementacin de UML

Qu son soluciones tecnolgicas?
Las soluciones tecnolgicas han evolucionado desde los sistemas para la automatizacin de
la fuerza de ventas, marketing, call-center y servicios, hacia soluciones mucho ms
complejas y desarrolladas que engloban todo el frente del negocio.
Estas recogen toda la informacin sobre referencias, clientes e interacciones en un mismo
lugar. De esta manera, los empleados deben ser capaces de compartir la informacin con
sus proveedores y distribuidores para hacer que los procesos de negocio cliente/mercado
sean lo ms eficientes posibles.
Al utilizar UML en el diseo del sistema de informacin se facilitaron algunas tareas, porque
no slo permita el desarrollo de la aplicacin, sino que tambin ofreca un modelo para
realizar pruebas, asegurar la calidad de la aplicacin y mejorar el entendimiento del
problema y de la implementacin de la solucin.

RENTABILIDAD
CALIDAD
SERVICIO

4.2 UML (UNIFIED MODELING LANGUAGE) USO DE DIAGRAMAS
4.2.1 Diagramas en UML
Para entender el concepto de Diagramas de UML debemos en primer lugar entender el
concepto de Vistas de UML. Una vista es un subconjunto de construcciones de modelado
que se enfocan en un aspecto en particular del sistema.
Las vistas pueden dividirse en tres reas: clasificacin estructural, comportamiento
dinmico, y gestin del modelo.
Cules son las Vistas de UML?
Vistas Estructurales
La clasificacin estructural describe los elementos del sistema y sus relaciones con otros
elementos.
Los clasificadores incluyen clases, casos de uso, componentes, y nodos. Los clasificadores
proveen la base sobre la que se construye el comportamiento dinmico.
Las vistas de clasificacin estructural incluyen:
Vista Esttica
o Diagrama de Clases
Vista de Casos de Uso
o Diagrama de Casos de Uso
Vista de Implementacin.
o Diagrama de Componentes
o Diagrama de Despliegue
Vistas de Comportamiento Dinmico
El comportamiento dinmico describe el comportamiento del sistema a travs del tiempo. El
comportamiento puede ser descripto como una serie de cambios a fotos del sistema
tomadas desde la vista esttica.
Las vistas de comportamiento dinmico incluyen:
Vista de la Mquina de Estados
o Diagrama de Estados (ciclo de vida de objeto)
Vista de Actividades
o Diagrama de Actividades
Vista de Interaccin
o Diagrama de Secuencia
o Diagrama de Colaboracin


Vistas de modelo de Gestin
La gestin del modelo describe la organizacin de los modelos mismos en unidades
jerrquicas. El paquete es la unidad de organizacin para los modelos. Tipos especiales de
paquetes son los modelos y subsistemas.
Vista de Gestin
Diagrama de Clases (paquetes, subsistemas, modelos)
En resumen:
AREA VISTA DIAGRAMAS
Estructural Vista Esttica Diagrama de Clases
Vista de Casos de Uso

Diagrama de Casos de
Uso
Vista de
Implementacin

Diagrama de
Componentes
Vista de
Despliegue
Diagrama de
Despliegue
Dinmica Vista de Maquina
de Estados

Diagramas de Estados
(ciclo de vida de
objeto)
Vista de
Actividades

Diagrama de
Actividades

Vista de
Interaccin
Diagrama de
Secuencia
Diagrama de
Colaboracin
Gestin del
Modelo
Vista de Gestin
del Modelo
Diagrama de clases
Extensibilidad Todos Todos

Cules son los Diagramas UML?
Los Diagramas del UML
Se clasifican en tres clases:
Diagramas de comportamiento: Permiten exhibir comportamientos de un sistema
o de los procesos de las organizaciones. Incluyen los diagramas de actividad,
estado, caso tpico y de interaccin.
Diagramas de interaccin: Es un subconjunto de los diagramas de
comportamiento que permiten enfatizar las interacciones entre los objetos.
Incluyen comunicacin, vista general de interacciones, secuencia y diagrama de
tiempo.

Diagramas de estructura: Muestran los elementos de una especificacin que
sean independientes del tiempo. Incluyen clase, estructura de componentes,
componente, despliegue, objeto y diagramas de paquetes.
Diagrama de Clases
Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un
sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de
clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se
crea el diseo conceptual de la informacin que se manejar en el sistema, y los
componentes que se encargaran del funcionamiento y la relacin entre uno y otro

Realizado en Rational Architect
Software
Fig. 4.6. Diagrama de clases de anlisis

Realizado en Rational Architect Software
Fig. 4.7. Diagrama de clases de diseo

Diagrama de componentes
Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre
componentes software, sean stos componentes de cdigo fuente, binarios o ejecutables.
Desde el punto de vista del diagrama de componentes se tienen en consideracin los
requisitos relacionados con la facilidad de desarrollo, la gestin del software, la
reutilizacin, y las restricciones impuestas por los lenguajes de programacin y las
herramientas utilizadas en el desarrollo
Los elementos de modelado dentro de un diagrama de componentes sern componentes y
paquetes. En cuanto a los componentes, slo aparecen tipos de componentes, ya que las
instancias especficas de cada tipo se encuentran en el diagrama de despliegue

Fig. 4.8. Diagrama de componentes

Diagrama de objetos
Se puede considerar un caso especial de un diagrama de clases en el que se muestran
instancias especficas de clases (objetos) en un momento particular del sistema.
Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de
clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su
notacin es similar a los diagramas de clase

Fig. 4.9. Diagrama de objetos


Diagrama de estructura compuesta
Este tipo de diagrama fue especficamente diseado para la representacin de patrones de
diseo, y es una de las modificaciones de mayor impacto dentro de UML 2.0. Esta
modificacin al UML hace que ahora todos los Clasificadores puedan tener una estructura
compuesta.
Mediante una composicin de estructuras, el comportamiento de las instancias de otros
Clasificadores contenidos (estructura interna) en un Clasificador determinado, puede
especificarse como Colaboraciones. Los conceptos principales para describir la estructura
interna son: Partes, Puertos y Conectores.

Fig. 4.10. Diagrama de estructura compuesta

Diagrama de despliegue
Describen la configuracin del entorno de mquinas y redes sobre el que se distribuyen
componentes y procesos del sistema.

Fig. 4.11. Diagrama de despliegue

Diagrama de paquetes
Este tipo de diagrama se usa para dividir el modelo en contenedores lgicos (paquetes) y
describen las interacciones entre ellos a un nivel ms alto. Los paquetes ofrecen un
mecanismo general para la organizacin de los modelos/subsistemas/capas agrupando

elementos de modelado. Cada paquete se corresponde a un submodelo
(subsistema) del modelo (sistema), se pueden anidar paquetes.
Por ltimo, puede crearse relaciones de dependencia. Esto se da cuando un componente de
un paquete necesita un componente de otro paquete.

Fig. 4.12. Diagrama de paquetes

Diagrama de actividades
Muestra un flujo ordenado de actividades. Los diagramas de actividades tienen un
amplio nmero de usos: desde definir un flujo de programa bsico hasta capturar los
puntos de decisin y acciones dentro de cualquier proceso generalizado.


Fig. 4.13. Diagrama de actividades


Diagrama de casos de uso
El diagrama de casos de uso permite realizar la especificacin del alcance funcional
del producto software que se construye y de los actores, entes que interactan con el
producto software, que requieren los diferentes casos de usos.
Los diagramas de casos de uso son usados para representar los procesos de negocio
de la organizacin objetivo y las funcionalidades que representan la arquitectura del
sistema por cada proceso de negocio.

Fig. 4.14. Diagrama de actividades

Diagrama de mquina de estados
Tpicamente, este diagrama se utiliza para representar todos los posibles estados
que los objetos de una clase puedan tener. Los diagramas de estado no se hacen
para todas las clases, es slo para aquellas que tengan un nmero de estados bien
definidos y en donde el comportamiento de la clase es afectado y cambiado por los
distintos estados.

Fig. 4.15. Diagrama de mquina de estados


Diagrama de secuencia
Muestra una secuencia ordenada de mensajes pasadas entre los objetos usando una lnea
de tiempo vertical.

Fig. 4.16. Diagrama de secuencia

Diagrama de comunicacin
Antes, era conocida como diagrama de colaboracin. Muestra la red y la secuencia de
mensajes de comunicaciones entre objetos en tiempo de ejecucin durante una instancia
de colaboracin.

Fig. 4.17. Diagrama de comunicacin


Diagrama de tiempo

El diagrama de Tiempo define el comportamiento de los diferentes objetos con una
escala de tiempo. Provee una representacin visual de los objetos cambiando de estado
e interactuando a lo largo del tiempo
Puede usar diagramas de tiempos para definir componentes de software dirigidos
por hardware o embebidos; por ejemplo, aquellos usados en un sistema de inyeccin de
combustible, un controlador de microondas. Tambin, puede usar diagramas de tiempo para
especificar procesos de negocio dirigidos por tiempo
"Los Diagramas de Tiempos se usan para mostrar las interacciones cuando el propsito
primario del diagrama es razonar acerca del tiempo. Los diagramas de Tiempos
enfocan sobre las condiciones de cambio con y entre las Lneas de Vida a lo largo de un
eje lineal de tiempo.
Los diagramas de Tiempos describen el comportamiento de los clasificadores individuales
y de las interacciones de los clasificadores, enfocando la atencin sobre el tiempo de la
ocurrencia de los eventos causando los cambios en las condiciones de modelado de la
Lneas de Vida."

Fig. 4.18. Diagrama de tiempo


Diagrama de descripcin de la interaccin
Es un diagrama que muestra cmo interactan varios diagramas de interacciones (por
ejemplo, de secuencias). Este tipo de diagramas es muy til para mostrar de qu manera
distintos escenarios se combinan.
Son una variante de los diagramas de actividades, la mayor parte de la notacin es
similar, al igual que el proceso de construccin del diagrama. Los puntos de decisin,
bifurcacin, unin, puntos de inicio y final son los mismos.
En lugar de actividades, se usan elementos rectangulares. Existen dos tipos de estos
elementos
Los elementos de interaccin muestran un diagrama de interaccin en lnea, el cual
puede ser un diagrama de secuencias, comunicaciones, de tiempos o de descripcin
de las interacciones
Los elementos de ocurrencia de interaccin son referenciados a un diagrama de
interaccin existente. Ellos son visualmente representados por un marco, con ref. en el
espacio del ttulo del marco. El nombre del diagrama est indicado en el contenido
del marco.

Fig. 4.19. Diagrama de interaccin


4.2.2 Interaccin de UML con el modelado de Procesos de Negocio
Las organizaciones y los procesos
Los procesos se consideran actualmente como la base operativa de gran parte de las
organizaciones y gradualmente se van convirtiendo en la base estructural de un nmero
creciente de empresas.
Esta tendencia llega despus de las limitaciones puestas de manifiesto en diversas soluciones
organizativas, en sucesivos intentos de aproximar las estructuras empresariales a las
necesidades de cada momento.
As las organizaciones de tipo funciona generaron altos niveles de eficacia en las operaciones
especializadas abordadas por cada funcin, a menudo a costa de la eficacia global de la
empresa y de una comunicacin poco fluida entre las distintas funciones.
Las organizaciones de tipo matricial, un gran avance en teora, diseadas para optimizar el
empleo de las capacidades humanas, integrarlas en equipos ad hoc para cada proyecto o
nueva actividad, y para reforzar y emplear a fondo los conocimientos disponibles en la
empresa, encontraron muchas dificultades en su aplicacin prctica.
Los procesos, se pueden definir como secuencias ordenadas y lgicas de actividades de
transformacin, que parten de unas entradas (informaciones en un sentido amplio pedidos
datos, especificaciones, ms medios materiales mquinas, equipos, materias primas,
consumibles, etctera), para alcanzar unos resultados programados, que se entregan a
quienes los han solicitado, los clientes de cada proceso.
Estos procesos, al requerir un conjunto de entradas materiales e inmateriales y componerse
de actividades que van transformando estas entradas, cruzan los lmites funcionales
repetidamente. Por cruzar los lmites funcionales, fuerzan a la cooperacin y van creando una
cultura de empresa distinta, ms abierta, menos jerrquica, ms orientada a obtener
resultados que a mantener privilegios.
A estas ventajas de preparacin para el entorno actual, incierto y cambiante, se debe aadir la
importante caracterstica de que los procesos son altamente repetitivos.

4.2.3 Notaciones usadas en el modelado de Procesos de Negocio
Modelo de casos de uso de Negocio


ARTEFACTO DESCRIPCIN

Describe el valor deseado de una medida en
particular a futuro, y se utiliza para planea y
administrar las actividades del negocio. El objetivo
debe ser claro, mesurable, alcanzable, realista y
sensible al tiempo.

Describe un proceso de negocio desde un punto de
vista externo que percibe algn tipo de valor.

Representa un rol que algo o alguien externo
desempea en relacin con el negocio.
Puede iniciar el proceso o participar en l debido a
que recibir algn resultado de valor del proceso

Modelo de anlisis de Negocio

ARTEFACTO DESCRIPCIN

Representa un rol interno al negocio. Colabora con
trabajadores de otro sector, es notificado de
acontecimientos del negocio y manipula entidades
de negocio para realizar sus responsabilidades.

Ente manipulado por actores del negocio y
trabajadores del negocio.
Coleccin de diagramas que muestra cmo los
trabajadores del negocio y entidades del negocio
llevan a cabo el caso de uso del negocio.
Por ejemplo: diagramas de clases y diagramas de
actividades para realizar el detalle de cada proceso
de negocio.

EJERCICIO PROPUESTO
CASO 01
El Archivo Central de Planillas (ACP) que obra en poder de la Oficina de
Normalizacin Previsional (ONP) se encarga de administrar la informacin y libros entregados
a la ONP por las empresas, entidades y custodios no autorizados al Archivo Central de
Planillas.
Uno de los procesos iniciales en la ACP es contemplar los pasos para el registro de los libros
de planillas. Para esto se realiza la recepcin de los libros que vienen de Mesa de Partes de la
ONP. La identificacin respectiva (tipos), evaluacin tcnica y ubicacin fsica de los mismos
es realizado por el tcnico de archivo y el registro de los libros es realizado por el digitador de
archivo.
Por otro lado, se contemplan actividades para la gestin de atencin al usuario del ACP, en lo
que se refiere a los servicios de prstamos y devoluciones de libros de planillas. Dichos
usuarios deben estar registrados para acceder a los servicios y son atendidos por el digitador
y tcnico de archivo.


4.3 UML (UNIFIED MODELING LANGUAGE) USO DE ELEMENTOS

4.3.1 Uso de elementos del tipo Flow
Artefacto Descriptor
1

Conector de flujo entre acciones o acciones y
almacn de datos.
2

Flujo de control utilizado para representar
relaciones entre acciones.
3

Flujo de objeto utilizado para representar
relaciones INPUT y/o OUTPUT entre una accin
e instancia de entidad de negocio

1
2
3
l
e
m
e
n
t
a
c
i
n
C
e
r
t
i
f
i
c
a
c
i
n

4.3.2 Uso de elementos del tipo Swimlanes (Partitions)
1

Particin asignada para cada
rol

1
1

4.3.3 Uso de elementos del tipo Artifacts

1

Nodo inicial que indica el inicio del Diagrama
de Actividades
2

Define una accin de la actividad. Es
conveniente nombrar las actividades con
verbos en tercera persona.
3

Este nodo representa un punto en una
actividad donde un flujo de entrada se divide
en varios flujos de salida.
4

Este nodo representa un punto en una
actividad donde varios flujos de entrada
estn sincronizados en un nico flujo de
salida.
5

Control de decisin a partir del cual se
especifica una pregunta que lleva a dos o
ms flujos de acciones.
6

Almacn de datos que representa la instancia
de una clase persistente.
7

Nodo Final que indica finalizacin de una
secuencia de actividades. Un diagrama de
actividades puede tener ms de un tipo de fin.



1
2
4
5
6
7
1

EJERCICIOS PROPUESTOS
Lea detenidamente y desarrolle los siguientes casos

CASO 01: "VIBRANT SOUND EQUIPOS DE AUDIO"
VibrantSound es una empresa dedicada a la venta e instalacin de equipos de sonido para autos
deportivos, se ha establecido en el mercado local y esperan convertirse en nmero uno en
calidad de su servicio este ao, para ello se han planteado ganar el campeonato de calidad de
sonido organizado por la compaa Kenwood as como disminuir considerablemente el tiempo de
atencin a los clientes.
Esta empresa se encarga de vender equipos de audio. Para que se lleve a cabo esta venta el
cliente solicita al representante comercial cierta marca de un equipo, en caso no haya stock el
vendedor solicita al representante de marca el despacho inmediato del equipo, de acuerdo a los
contratos que VibrantSound ha suscrito. Segn estos contratos los administradores de cada local
deben efectuar, a fin de mes, una transferencia bancaria a cada representante de marca por el
monto de todas las entregas realizadas durante ese mes.
Otra de las lneas de negocio se refiere a la instalacin de equipos para ello el cliente debe
adjuntar el equipo a instalar al supervisor de taller quien en coordinacin con el tcnico
presentarn una cotizacin de servicio para la decisin del cliente.
ESPECIFICACION REALIZAR INSTALACIN DE EQUIPOS DE AUDIO
Objetivo: Lograr que el cliente acepte las cotizaciones en un 85%
Flujo Bsico
1. El cliente solicita la instalacin de un equipo de audio adjuntando el equipo a instalar.
2. El supervisor elabora un diagrama de instalacin y solicita al tcnico instalador la
revisin del automvil.
3. El tcnico instalador realiza la revisin del automvil.
4. Si es factible la instalacin, el tcnico instalador informa al supervisor a travs del
informe de instalacin de los pasos a realizar para la instalacin adems de los insumos
necesarios.
5. El supervisor elabora la cotizacin y se la presenta al cliente.
6. El cliente evala la cotizacin.
7. Si el cliente acepta la cotizacin, el supervisor indica al tcnico instalador que proceda
con la instalacin.
8. El tcnico instalador procede con la instalacin y realiza las correcciones necesarias.
9. El supervisor revisa la instalacin realizada y prueba el equipo de audio.

10. Si est bien instalado el equipo de audio, el supervisor hace entrega del automvil al
cliente.
11. El cliente se dirige a caja y realiza el pago.
12. El cajero le entrega el comprobante de pago al cliente.
13. El cliente procede a retirar su auto.
Flujos Alternativos
- En el punto 4, si no es factible la instalacin
i. El tcnico instalador le informa al supervisor indicndole los motivos a
travs del informe de instalacin.
ii. El supervisor se lo indica al cliente y el proceso termina.
- En el punto 7, si al Cliente no acepta la cotizacin se lo indica al supervisor y el
proceso termina.
- En el punto 10, si el supervisor determina que hay que realizar ajustes en la
instalacin le indica al tcnico instalador y se reinicia el proceso desde el paso 8.


Caso 02: COMEX- UNA TENTADORA INNOVACIN
ANTECEDENTES
Para aplicar una estrategia de e-Business no hay una sola combinacin. En la firma de
pinturas la solucin para sacarle ms color al asunto fue dividirla en tres sitios. Una decisin
que hasta ahora ha mantenido contentos a los usuarios.
A la empresa mexicana Comex le ha pintado bien el e-Business. Con tres sitios destinados a
diferentes usuarios, la empresa de pinturas ofrece una gama de servicios en lnea que la
han favorecido al conseguir mayor eficiencia en el servicio a los clientes y ahorros en los
costos de operacin que han mejorado significativamente con el uso de la Red.
Esta empresa mexicana cre el rea de e-Business convencida de que la tecnologa es una
herramienta que debe ser aprovechada. Pero antes de dar un mal brochazo a la Red,
decidieron igualar su tono al de los mejores sitios de empresas de pintura ms importantes
del mundo, como Sherwin Williams de Estados Unidos y Sudfrica, Optimus de Mxico, ICI
de Inglaterra, Dupont de Estados Unidos y otras empresas de Israel, Espaa, Portugal, Italia
y Canad, con el fin de constatar lo que las empresas ms representativas ofrecan en
cuanto a navegacin.
El rea de e-Business es un proyecto con tres iniciativas: Internet, con un sitio para el
pblico en general, Extranet, con una pgina para los concesionarios, e Intranet, con un sitio
para los empleados, que requiri de una inversin inicial de alrededor de 250 mil dlares y
seis personas dedicadas totalmente a este proyecto.
Sin embargo, Comex est consciente de que la tecnologa no viene a sustituir al hombre ni
al contacto humano. Simplemente ayuda a las empresas a ser ms eficientes y ms rpidas,
a la vez que genera ahorros en recursos.
TRES PINTAN MEJOR QUE UNO
Comex.com.mx, fue la primera pgina de la empresa que apareci en la Red en diciembre
del 2000 con una estrategia B2C (negocio a consumidor), y fue diseada para el pblico en
general, con formato de revista electrnica y con contenidos dirigidos a amas de casa,
arquitectos, diseadores, contratistas e industriales. En el sitio se encuentran una serie de
consejos tiles para remodelaciones, para arreglar problemas de humedad o de oxidacin,
por ejemplo, dando a cada quin la informacin que necesita.
El objetivo es cultivar a un cliente, a sabiendas de que este generar ms ventas.
Comexnet.com.mx, el otro sitio, aparece en abril del 2001, como una extranet para los ms
de 2,700 concesionarios en todo el pas, con la estrategia B2B (negocio a negocio).
Los beneficios del e-Business se han concentrado sobre todo en este sitio, ya que el
concesionario puede solicitar sus pedidos, revisar su crdito y las listas de precios, hacer
consultas en lnea, obtener informacin de nuevos productos, conocer comunicados de la
compaa en cualquier momento, los 365 das del ao, las 24 horas, generando ahorros en
llamadas de larga distancia y en horas hombre, as como en insumos y servicio de
mensajera.

"Comex tiene cuatro bodegas: Mxico, Guadalajara, Monterrey y Minatitln. Cuando un
concesionario de Puerto Vallarta se surte, lo hace de la bodega de Guadalajara. Si fuera por
telfono, sera una llamada de larga distancia que le tomar varios minutos, ya que la
operadora debe revisar la existencia del producto que solicite el cliente, tomar el pedido y
verificar la orden. Ahora, a travs de este sitio, el concesionario puede ver los inventarios,
los precios y hacer su pedido de una manera ms eficiente, adems de ahorrar en
llamadas", explica Juan Manuel Vega, gerente de e-Business de Comex.
A travs de este sitio han crecido los pedidos, porque el cliente tiene oportunidad de ver
todos los productos, aun los que no conoca.
VEGA: "Internet NO VIENE a sustituir al hombre ni el contacto humano. Slo ayuda a las
empresas a ser ms eficientes".
Al ser un sitio con acceso restringido se garantiza la confidencialidad y la seguridad de la
informacin, tanto del corporativo como de los concesionarios. "Tenemos un contrato
firmado con nuestros clientes en el que nos comprometemos a responder ante un eventual
fallo del sistema, as como ellos a responder por un mal uso de las claves que se les
asignan", subraya Vega.
El ejecutivo explica que, a la fecha, 50 % de sus clientes concesionarios estn registrados
en el portal, de los cuales 10 % realizan sus pedidos en lnea. "El servicio de pedidos por
Internet es nueve y hemos detectado que las caractersticas de los clientes que usan el sitio
son jvenes (la segunda generacin de las familias que estn manejando el negocio), la
mayora residen en zonas urbanas y est creciendo el nmero de usuarios que estn fuera
de las ciudades donde estn las bodegas".
La tercera pgina fue diseada para la familia Comex, es decir, para los casi tres mil
empleados que tiene el corporativo, cuyo objetivo es eliminar el criterio de divisin y acercar
a los empleados a travs de una Intranet que difunde informacin diversa, desde temas
laborales hasta de inters general. Otra funcionalidad es que ya hay ciertos trmites internos
que se pueden realizar desde la pgina de manera ms efectiva dejando atrs a los
formatos impresos. La disminucin en el nmero de materiales impresos ha incidido tambin
en el rengln de los ahorros.
Cuando una empresa conocida comercialmente posiciona una pgina, o ms de una, se
hace imperativo estar alerta ante eventuales cibernautas, sobre todo si no quiere perder la
confianza hacia el medio de sus actuales usuarios, y planea ofrecer cada vez ms servicios
en lnea. A esto, Vega responde que en cuestiones de seguridad estn protegidos con
firewalls. "Hasta el momento no hemos sufrido un intento de hackeo; sin embargo, si
llegarn a entrar a la pgina pblica slo afectaran al sitio y no a la informacin privada, ni a
las operaciones del grupo".
Se puede decir que el pensamiento estratgico de Comex, apuesta por el uso de
Tecnologas, sin embargo ellos aclaran que INTERNET NO ES PARA TODO, NI PARA
TODOS
Las tecnologas de la informacin ya estn adheridas a los negocios, aunque algunos la
consideren suntuarias, como si fuera un afn mantenerla slo al alcance de una minora. Y
al respecto, Vega reconoce que prevalecen las limitaciones para mal de muchos. "El Internet
no es para todo, ni es para todos. No puedes comparar todos los productos que ofrece la
Web. La ropa, por ejemplo, es muy difcil que la compres por la Red. Y no es para todos

porque no toda la gente tiene dinero para comprar un equipo de cmputo. En general,
tenemos un retraso tecnolgico muy grande y una infraestructura telefnica que no alcanza
a cubrir todo el territorio".
No obstante, el ejecutivo subraya la importancia de seguir alentando el uso de la tecnologa
como parte de sus planes a corto y mediano plazo. "En la pgina de concesionarios,
queremos incentivar el uso de Internet a travs de premios, como sorteos entre clientes que
hayan realizado 80 % de sus pedidos en lnea, o regalar una Palm al cliente que gaste
determinada cantidad en productos, para que pierdan el temor hacia la tecnologa. Otra
iniciativa es hacer un foro en lnea, para que se conozcan entre s los concesionarios y
compartan experiencias que puedan enriquecer sus puntos de vista."
Para la pgina pblica hay planes en la oferta de nuevos servicios, como un decorador
virtual: adems, incluir un chat para consultas de cmo aplicar sus productos y, por ltimo,
mejorar en todo lo posible los mdulos que ya tienen. Con ello aseguran que todos los
esfuerzos del rea de e-Business estn en funcin de sus clientes.
"Consideramos que hemos hecho un buen trabajo con los recursos necesarios. Pero hay
que estar vivos en Internet y renovarse todos los das. Tenemos muchos planes y una
inversin para el rea de dos a tres millones de pesos durante este ao", puntualiza Vega.
"Generamos ahorros en llamadas de larga distancia y horas hombre as como en insumos y
servicio de mensajera".
Comex, un E-business bien pintado

Qu consigui COMEX con la aplicacin de TI en sus procesos?
Es as que el caso propuesto se puede determinar que se ha logrado avances significativos
en el uso de la Tecnologas de la Informacin para la mejora de sus procesos y desarrollo
de las polticas de la organizacin
Facilitar a los clientes el fcil acceso a la informacin de los productos y/o servicios
junto a sus respectivos detalles y especificaciones para que puedan tener un
conocimiento ms completo y oportuno que les ayudaran a tomar mejores
decisiones.
Permitir un mayor conocimiento de los clientes y de sus necesidades como
consumidores.
COMPETIDORES
PODER DE NEGOCIACIN
CON LOS CLIENTES
PRODUCTOS SUSTITUTOS PROVEEDORES
SECTOR
TECNOLGICO

Permitir almacenar, administrar, controlar y supervisar las estadsticas de
rendimiento de su fuerza de ventas.
Suministrar por medio del sistema un anlisis del pronstico de ventas de la empresa
para una toma de decisiones ms precisa y confiable.
Permitir el seguimiento del estado de las cotizaciones de los clientes.
Apoyar en el mejoramiento de las relaciones con los clientes.
Apoyar en el control de las ventas.
Permitir obtener las estadsticas en las principales reas de las organizaciones como
los son los clientes, vendedores y productos.
Permitir la administracin de polticas y reglas de negocio en sus ventas.
Permitir a las empresas el control y reconocimiento de la competencia y de los
productos que ofrece para tomar decisiones correctivas que permitan buscar
soluciones ms efectivas y de esta manera ser ms competitivos en el mercado en el
que acten.


Resumen

UML es un lenguaje de modelado visual que se usa para especificar, visualizar, construir
y documentar artefactos de un sistema de software.
La importancia de un lenguaje de modelamiento, radica en el entendimiento del modelo
de negocio y su posible transformacin en una arquitectura de tecnologas.
Los diagramas UML representan diferentes perspectivas sobre las cuales trabaja el
analista con la finalidad de lograr un entendimiento cabal de los procesos de negocio.
Los diferentes diagramas estn organizados en vistas estticas y dinmicas las mismas
que nos dan una visin general de remodelamiento que debe ser entendida por el
analista con la finalidad no slo de capturar la informacin sino tambin de hacerla til en
el uso de las tecnologas de informacin.

Pginas De Inters
www.uml.org
o En este link Ud. encontrar informacin relaciona a UML, dentro de ella se
ubican mas link de inters
www.sparxsystems.com/uml-tutorial.html
o En este link Ud. encontrar informacin relaciona al manejo de UML
www.omg.org/gettingstarted/what_is_uml.htm
o En este link Ud. encontrar informacin relaciona a OMG y UML
www.ibm.com/software/rational/uml
o En este link Ud. encontrar informacin relaciona a RUP y su importancia.


Anexo

GUIA RPIDA DE
MANEJO DE SOFTWARE
Biz Agi


MODELADO BPMN
INTRODUCCION: BPMN (Business Process Modeling Notation)
BPMN es una notacin grfica estndar diseada para crear modelos que todos
los participantes en un proceso de negocio puedan entender: usuarios, analistas,
clientes, gerentes, etc.
La idea es que usando una cantidad limitada de smbolos podamos crear
modelos entendibles que nos ayuden a optimizar y eventualmente a optimizar-
los procesos
BPMN ha sido desarrollado para cubrir la brecha entre el diseo y la
implementacin de un sistema. Fue formado por la Business Process
Management Initiative con el Object Management Group
Elementos del BPMN: Eventos
Disparador Evento
Evento de inicio
Evento intermedio
Evento final


A los eventos especficos se les
puede agregar un icono que
muestre su significado
Un evento intermedio tipo
mensaje, por ejemplo, puede
tener dos instancias: enviando o
recibiendo. Los eventos que
envan se anotan con un icono
relleno, mientras que los que
reciben con un ncleo claro
En la figura se pueden ver
distintas clases de eventos

BPMN: Eventos intermedios
Disparador Descripcin Smbolo
Ninguno No se muestra el tipo de evento

Mensaje El proceso queda en espera hasta que
llegue el mensaje (recepcin) o se usa
para enviar mensajes (envo), tambin se
usa para desviar excepciones (*)

Timer Dispara el proceso en un da/hora
determinados, tambin se usa para
desviar excepciones

Error Se dispara cuando se produce un
determinado error. Solo se puede poner
en el extremo de una actividad

Cancelar Se puede poner solo en el extremo de un
sub proceso. Se dispara cuando recibe un
evento Cancelar


Compensacin Activa eventos que compensan alguna
accin, puede afectar a una actividad si
esta se especifica o a todas las
susceptibles de ser compensadas

Condicional Es el evento que se dispara cuando una
condicin tiene valor True

Link Conecta dos secciones de un proceso, se
puede usar por ejemplo- para crear
loops. Puede tener mltiples fuentes pero
solo un destino

Seal Enva y recibe seales que se comunican
a lo largo de todo un flujo a quien pueda
interesar

Mltiple Es cuando un evento tiene mltiples
disparadores, ya sea para recepcin
como para envo

BPMN: Gateways (compuertas)
Las Gateway son puntos de decisin para canalizar el flujo

Exclusive Data-Based: Una o varias salidas son posibles pero solo una
condicin dirigir el flujo
Exclusive Event-Based: Igual que el caso anterior pero escoger la primera
condicin que le llegue (race)
Inclusive: Evala dos o ms condiciones, el flujo puede salir por una o ms
ramas en paralelo
Complex: Sirve para combinaciones de las otras gateways, se escribe en un
detalle aparte su comportamiento en cada caso particular
Paralel: Sincroniza los flujos que salen de manera paralela


BPMN: Swimlanes y Pools

Pools (piscinas) y swimlanes
(pistas) se usan para organizar
dentro de un bloque actividades
afines y mostrar la colaboracin
entre ellas.
Tpicamente se usan para
organizar un subproceso, una
unidad de negocios especfica,
etc.


Ejemplos
Ejemplo de trazabilidad


Proceso intermedio bsico: Races



BPMN: Interrupciones

USANDO LA HERRAMIENTA BIZAGI MODELER
Introduccin.
El mundo del desarrollo informtico est cambiando. Construir sistemas
monolticos que no tengan capacidad de encajar en arquitecturas orientadas a
servicio (SOA) tiene sus das contados.
Las arquitecturas basadas en servicios son el primer paso para construir de
sistemas basados en procesos (BPM).
La idea es modelar procesos de negocio de un modo comprensible para los
usuarios finales (en una notacin llamada BPMN) y luego ser capaz de
automatizarlos, a fin de hacerlos prcticos para la arquitectura de servicios (a
travs de servicios Web). As se puede tener la capacidad de simular el
comportamiento de un sistema (para ver cuanta gente nos hace falta en cada
rol empresarial), medirlo (obteniendo indicadores) y optimizarlo (viendo el
impacto cuantitativo de los cambios propuestos).
Entonces el primer paso es elegir una herramienta para modelar un primer
nivel. Luego el automatizarlo es otra guerra, esto debido que uno se puede
hacer dependiente de la herramienta que elijamos. Es bueno recordar que el
modelamiento de un proceso es independiente al uso de la herramienta con el
que lo ejecutemos.
En el curso de Modelado de Negocios para las carreras de Tecnologas,
enseamos muchas cosas pero tambin las aprendemos sobre el
comportamiento de las empresas. Para entender mejor este comportamiento
es bueno graficar los q sucede al interior de la organizacin es por ello que
vamos a utilizar la herramienta BizAgi con esta finalidad.
Instalando
Lo primero que hacemos en bajar la herramienta de
http://www.bizagi.com/esp/productos/ba-modeler/modeler.html.
MODELADO DE PROCESOS DE NEGOCI OS
104


No ocupa demasiado (para lo que estamos acostumbrados), 17 Mbyte.

La instalacin es sencilla: ok, ok, ok.


106

Y al arrancarla, elegimos el espaol como lenguaje de utilizacin.

Trabajando en BizAgi
Podemos ya empezar a pintar nuestros diagramas con la notacin BPMN. Es
rpido y sencillo. Hacer clic sobre el elemento en la barra de herramientas y
arrastrar a las reas de trabajo. Con el botn derecho, modificamos los tipos de
elementos.


En el siguiente enlace podemos encontrar una pequea gua para entender el
significado de cada smbolo BPMN:
http://www.bizagi.com/esp/descargas/BPMNbyExample.pdf?token=1.3.0.0
Lo mejor es acceder al video-tutorial y vern lo intuitivo que es:
http://www.bizagi.com/esp/productos/ba-modeler/demo-
modeler/ModelarEsp_demo/ModelarEsp_demo.htm

Nosotros nos vamos a saltar estos pasos y disear un diagrama un poquito
ms complejo para ver si nos encontramos algn problemita.

108

Exportando la informacin
Word
Vamos a ver cmo queda nuestra documentacin podemos exportar a Word.

Elegimos nuestro diagrama y los elementos a exportar (digo todos).


Y nos queda un documento Word para su eleccin.

Visio
Tambin lo vamos a exportar a Visio para ver cmo queda. La gracia es que
el proceso normal es justo lo contrario (tambin tienen un video-tutorial). No
est mal pero de momento me quedo con Bizagi Modeler.

Para terminar, un recurso imprescindible: Un tutorial muy sencillo sobre el uso de
BPMN
http://www.bpmn.org/Documents/OMG%20BPMN%20Tutorial.pdf:

Manual 2013-II Modelado de Negocios (1350)

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual 2013-II Modelado de Negocios (1350)

Încărcat de

Drepturi de autor:

Formate disponibile

Modelado de

S-ar putea să vă placă și