1.1.

4 Procesos automatizados

Se habla de un proceso simple, en el cual un cliente envia una solicitud de crédito en papel, a un
banco, y esta queda en un escritorio del mismo, para ser evaluado por un contador, este contador
verifica la solvencia económica del cliente en un sitio web para calificación crediticia .

Los resultados son positivos, así que el contador lo registra en una aplicación especial y reenvía la
documentación a un gerente para su aprobación.

Se hace mención del mismo proceso pero de manera automatizada, el cliente envia la solicitud al
banco, un emplado escanea esta información en formato electrónico, el motor del flujo de trabajo
asume el documento y lo enruta a la lista de tareas del contador, el contador accede a su lista de
tareas, examina la solicitud en pantalla, hace clic en un botón, El motor de flujo de trabajo accede
a la agencia de calificación crediticia, transfiere los detalles pertinentes y recibe el informe. Dado
que el informe es positivo, el motor pasa la información a BankSoft y crea una tarea de aprobación
en la lista de tareas del gerente.

PRINCIPIOS DE AUTOMATIZACIÓN DE PROCESOS

La automatización de procesos no necesariamente significa que todo el proceso deba estar

totalmente automatizado.

El componente centrar de la automatización de procesos es el motor de flujo de trabajo que ejecuta

un modelo de proceso ejecutable.

El motor de flujo de trabajo controla el proceso, informando al recurso humano de las tareas que
estos deben hacer y se encarga del resultado de lo que hacen las personas, también se comunica
con sistemas informáticos externos o interno. (Orquestación de Servicios)

El motor de flujo de trabajo decide qué tareas o llamadas de servicio deben llevarse a cabo o no,
bajo qué condiciones, y de acuerdo a el resultado de la ejecución de la tarea o llamada de servicio.
Por lo tanto, las personas involucradas todavía pueden influir en la secuencia operativa de un
proceso automatizado.
 Ilustración de los principios

Modelo de proceso ejecutable, en el cual opera el motor de flujo de trabajo, se inicia con una
asignación de tareas en donde se tiene un participante del proceso, que puede ser un trabajador,
seguido de ello, tenemos una llamada de servicio automatizado en donde interviene un sistema
informatico (Es la mencionada orquestación de servicios), seguido de ello se obtiene una decisión
automática, que nos puede llevar al final del proceso, o bien, llamar a otro servicio automatizado el
cual dará como resultado una tarea para la asignación de tareas, donde interviene otro participante
del proceso. Es importante mencionar que se mide el tiempo de ejecución, el cual debe ser
monitoreado y reportado, y tenemos la gestión del flujo de trabajo humano, referida al recurso
humano que participa en el modelo.

Entonces la automatización de procesos, puede ser considerada como un tipo de desarrollo de

software. Y el motor de flujo de trabajo es el compilador o interprete, y el modelo de proceso
ejecutable es el código de programa.

-El motor de flujo de trabajo se especializa en representar la lógica de procesos, los servicios que
presta, habrían requerido una extensa programación, el motor puede hacer que realizamos el
trabajo de una manera considerablemente más productiva.

-El MFT, combina la gestión del flujo de trabajo con integración de aplicaciones, esto lo convierte en
una poderosa herramienta para implementar todo tipo de procesos de principio a fin,
independientemente de otras aplicaciones o la ubicación de las personas. En algunas soluciones de
software BPM, podemos agregar un Enterprise Service Bus (ESB) u otro componente para el motor
de flujo de trabajo para hacer el conjunto más versátil.
-A medida que el motor de flujo de trabajo controla el proceso, realiza un rastreo de todo, esto
quiere decir, que siempre se conoce la etapa actual del proceso y cuanto tiempo tardó en
completarse cada tarea, supervisa los indicadores clave de rendimiento, proporciona un medio para
analizar el rendimiento, ofrece un enorme potencial para un control exitoso del proceso.

-El motor de flujo de trabajo funciona sobre la base de un modelo de proceso ejecutable, en los
mejores casos este modelo puede ser desarrollado o por lo menos comprendido por alguien que no
es un técnico, esto promueve la comunicación realmente buena entre negocios y sistemas
informáticos, y puede resultar en documentación de procesos que corresponden a la realidad.

1.3 Puede BPMN Cerrar la brecha.

EL DILEMA.

Primero, BPMN proporciona un conjunto de símbolos. En segundo lugar, implica una metodología
que se expresa como las reglas para combinar los símbolos gráficamente. En tercer lugar, la
definición de los simbolos y reglas para aplicarlos es llamada sintaxis.

Cuarto, el significado de los simbolos y las construcciones que se pueden modelar con los simbolos
es llamado semántica.

Se habla acerca de las experiencias con el desarrollo usando BPMN en donde se hace mención que
no basta conocer la simbología para crear un modelo funcional, además de que se han intentando
crear modelos inequívocos, lo cual dificulta mucho el trabajo, y otros se libran de esto diciendo
“Que su modelo de proceso no es realmente sintácticamente correcto y no es realmente inequivoco,
pero que eso no importa, por que la cosa principal es que el consumidor lo entienda

Pero esas palabras pueden resultar contraproducentes porque:

-Cuando se aplica BPMN de una manera sintácticamente incorrecta, se pierden todos los beneficios
de la estandarización, ya que, ¿Para que se necesita un estándar si al final todos los modelos se ven
diferentes?

-Las inconsistencias semanticas siempre corren el riesgo de que el modelo sea malinterpretado,
además de que el riesgo aumenta, si el modelo es enviado a un sistema informatico para que lo
implemente.

Ahora bien, si se desea facilitar el modelo directamente al motor de flujo de trabajo, el modelo debe
de ser correcto, consistente y preciso.

En este punto, aún se deben conciliar dos objetivos contradictorios:

1.-Los diferentes consumidores deben comprender y aceptar el modelo de proceso, haciendo el

modelo fácil de comprender para llegar a un acuerdo.
2.- Debido a que el modelo de proceso tiene que cumplir con los requisitos de modelado formal,
por lo general hay un nivel inevitable de complejidad para ello. Esto hace que sea más difícil lograr
la comprensión que conduce a un acuerdo.

La falta de conciliación de los objetivos, para cerrar la brecha en el entendimiento entre empresa y
tecnología, es la principal razón por la cual los modelos de proceso han tenido un éxito limitado en
el pasado. Esto quiere decir que BPMN, por si solo no tendrá éxito, si no que requiere de alguien
que haga un correcto uso de él.

Se hace una comparación con el lenguaje hablado, ya que cualquiera puede utilizar BPMN y fracasar
o tener éxito en el intento, al igual que con el lenguaje hablado, el éxito depende de con quien se
este comunicando y acerca de que.

Por un lado, se requieren diferentes modelos de procesos BPMN para audiencias y temas específicos
para que puedan ser entendido. Por otro lado, cada modelo debe contener todos los detalles
necesarios para el tema. BPMN puede ser un lenguaje común para negocios y TI, pero la redacción
seguirá siendo diferente.

Por lo tanto, el siguiente entendimiento es imprescindible para su trabajo con BPMN:

La precisión y la corrección formal del modelo de proceso deben variar según el objetivo del modelo
y los consumidores esperados.

1.3.2 The customers of a process model

Siempre que modelamos procesos, tenemos que trabajar de manera centrada en
el cliente. Siempre debemos tener en cuenta al consumidor de nuestro modelo.
Debemos ponernos en su lugar. Esto suena simple, pero pocos modelos de
proceso soportan esta orientación.

Como hemos estado diciendo, el conocimiento, las habilidades y los

intereses de las personas que ven nuestros modelos de procesos varían
mucho. En la siguiente lista, hemos compilado los tipos que encontramos
en nuestros proyectos BPM.

Propietario del proceso: Los propietarios del proceso tienen

responsabilidades estratégicas para sus procesos. Están vitalmente
interesados en optimizar el rendimiento. A menudo tienen autoridad
presupuestaria, pero antes de firmar, deben estar convencidos de que su
plan de mejora funcionará. En la mayoría de las empresas, los
propietarios de procesos habitan en el primer o segundo nivel
de gestión. Pueden ser miembros de comités de gestión o jefes de
divisiones importantes.

Gestor de procesos: Los gestores de procesos tienen la responsabilidad

operativa de sus procesos. Reportan directa o indirectamente a los dueños del
proceso. Solicitan proyectos de mejora, actuando como parte encargada de los
servicios externos. Los gestores de procesos suelen ser gestores de nivel medio o
bajo.

Participante en el proceso: los participantes en el proceso trabajan con

los procesos y realmente crean valor. Su relación con el administrador de
procesos varía mucho. En las empresas organizadas por divisiones
funcionales (ventas, logística, etc.), un administrador de procesos es un ejecutivo
funcional de la división en la que se lleva a cabo el proceso.
Los participantes del proceso reportan directamente a ese ejecutivo funcional. Si el
proceso se lleva a cabo en todos los departamentos, lo que es común,
especialmente en la matriz de procesos, pueden surgir conflictos entre los ejecutivos
de los departamentos.
Analista de procesos: las competencias principales de los analistas de procesos
son BPM en general y BPMN en particular. Apoyan a los administradores de
procesos como proveedores de servicios internos o externos en todas las etapas
del ciclo de vida de BPM. Un analista de procesos puede ser el contacto para
proveedores de servicios externos o puede actuar como representante del
administrador de procesos. Dentro de la empresa, los analistas de procesos suelen
tener su propia esfera de competencia en BPM, como la organización empresarial,
o son parte de sus divisiones de TI. Sin embargo, es raro que un analista de
procesos sea responsable de la implementación técnica.
sus fortalezas son como organizador y comunicador. Como creador de puentes
entre negocios y TI, el analista de procesos es el centro de cada proyecto de BPM.
Alrededor del 70 por ciento de las personas que reclaman o están asignadas a este
rol, según nuestra experiencia, están poco cualificadas porque carecen de la
predisposición analítica adecuada.
Ingeniero de procesos: los ingenieros de procesos utilizan la tecnología para
implementar el proceso de estado objetivo modelado por analistas de procesos. En
el mejor de los casos, lo hacen en el motor de flujo de trabajo, que automatiza el
proceso. Puede llamar a un programador que programa la lógica del proceso en
Java, C # u otro lenguaje como ingeniero de procesos. El trabajo principal del
programador se lleva a cabo durante la etapa de implementación del ciclo de vida
de BPM, aunque el analista de procesos también puede involucrar al ingeniero de
procesos en otras etapas.
1.4 Un framework para BPMN
The camunda house

Superior:
Contenido: Vista general del proceso.
Meta: Comprensión Rapida
Semantica: Logicamente abstracto
Frente:
Contenido: Procesos operacionales
Meta: Coordinar detalles entre flujo de procesos humano y la automatización
Semantica: Fisicamente especifico

Distingue entre modelo de procesos estratégicos y operativos.

Modelo de proceso estratégico: el grupo objetivo principal para los modelos de
proceso estratégico son los propietarios de procesos y los administradores de
procesos. Un grupo secundario al inicio del proyecto puede incluir participantes del
proceso y analistas del proceso. Proporcionamos el modelo estratégico como una
representación general del proceso orientada a los resultados porque queremos
crear la comprensión más rápida posible para una audiencia que no tiene un
conocimiento especial de BPMN. Esbozamos el proceso en unos pocos pasos, pero
no mostramos errores ni variaciones.

Modelo de proceso operativo: en este nivel, investigamos los detalles

operativos del proceso real. Puede contener flujos de procesos humanos
o técnicos, y los modelamos en consecuencia. Un flujo de personas es
manejado por un participante mientras que un flujo técnico es manejado
por software, preferiblemente un motor de flujo de trabajo. Por supuesto,
los flujos humanos y técnicos pueden interactuar. Un humano puede
desencadenar un flujo técnico en el curso de su trabajo, como en el caso
de llamar a una función de software. Igualmente, un flujo técnico puede
requerir que un participante envíe un correo electrónico, asigne una
tarea, etc.

Es un marco puramente metodológico. En otras palabras, funciona

independientemente de herramientas de software particulares, aunque
ciertas funciones de la herramienta pueden facilitar su aplicación.

1.4.2 EL GRAN MAL ENTENDIDO