Texto Universitario NOTACION de PROCESOS

8/18/2019 Texto Universitario NOTACION de PROCESOS

1/100

NOT CIÓN DE

PROCESOS DE NEGOCIOS


2/100

Pág. 2

Asignatura: NOTACION DE

PROCESOS DE NEGOCIO

Universidad ContinentalMaterial publicado con fines de estudioPrimera ediciónHuancayo, 2015


3/100

Pág. 3


PROCESOS DE NEGOCIO

PRESENT CIÓN

Notación de Procesos de Negocio es una asignatura que proporciona conocimiento sobre

los fundamentos de Business Process Management, a través de un trasfondo histórico para

comprender mejor la evolución de la ingeniería de procesos. Asimismo se considera los conceptos

de implementación, para conocer y entender las definiciones que facilitan comprender el alcance de

BPM, la segunda parte integra a los modelos de procedimiento el apoyo tecnológico en cada una de

las capas del BPM y finalmente se muestra la notación BPMN con el objetivo de aplicarlo a casos de

negocios.El resultado de aprendizaje: Al finalizar la asignatura el estudiante será capaz de

elaborar modelos de diversos procesos de negocio, utilizando los principios de Business

Process Management (BPM) y elementos de notación de Business Process Model and

Notation (BPMN), basado en una plataforma de diseño, simulación y automatización de

procesos como representación estándar para las necesidades de una organización.

El presente material consta de cuatro unidades: Unidad I: ENFOQUE: BUSINESS

PROCESS MANAGEMENT (BPM)n presenta conceptos, y principios básicos, la organización y

estructura de BPM. Unidad II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO

BUSINESS PROCESS MANAGEMENT BPM presenta conceptos y las relaciones entre estándares

existentes para la gestión empresarial basada en procesos. Unidad III: BUSINESS PROCESS

MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN

presenta los elementos de notación de Business Process Model and Notation (BPMN). Unidad IV: AUTOMATIZACIÓN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN),

presenta herramientas de simulación y automatización, desarrollados a partir del texto BPM:

Business Process Management Fundamentos y Conceptos de Implementación (HITPASS, Bernard,

2014).

Es recomendable que el estudiante desarrolle una permanente lectura de estudio junto a la

elaboración de los modelos de procesos, así como la investigación en otros textos y vía internet. El

contenido del material se complementará con las lecciones presenciales y a distancia que se

desarrollan en la asignatura.

Agradecemos a quienes con sus aportes y sugerencias han contribuido a mejorar la presente

edición, que sólo tiene el valor de una introducción al conocimiento de las estructuras de datos para

la programación en un computador.

Las autoras.


4/100

Pág. 4


PROCESOS DE NEGOCIO

ÍNDICE

Pág.PRESENTACI N 3NDICE 4UNIDAD I: INTRODUCCION Y DEFINICION DEL BPM 5Tema Nº 1: Introducción al BPM 51.1 Antecedentes de BPM 51.2 Historia y Evolución 5Tema Nº 2: Conceptos Básicos de BPM 92.1 Definición de Proceso 92.2 Proceso de Negocio 102.3 ¿Gestión de o por procesos de negocio? 132.4 Gestión tradicional sin BPM 152.5 Bussiness Process Management (BPM) 16Tema Nº 3: Organización y Estructura del BPM 183.1 Conceptos de Gestión en BPM 183.2 La automatización de procesos (BPA) 253.3 Los participantes en BPM 263.4 Herramientas para BPM 293.5 La arquitectura del BPM y SOA 313.6 Reglas de Negocio 343.7 Gestión de Reglas de Negocio 353.8 Reglas de negocio y Reglas de ruteo 36

3.9 Técnicas de Mejora Continua 38UNIDAD II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO BUSINESS PROCESS MANAGEMENT 46Tema Nº 4: Arquitectura Empresarial 464.1 Definición de Arquitectura 464.2 Definición de Arquitectura Empresarial AE 464.3 Drivers y Objetivos de una AE 48Tema Nº 5: reas de una Arquitectura Empresarial 525.1 Business Process Outsourcing (BPO) 525.2 Gestión de calidad - riesgo - conocimiento - regulaciones - otras 535.3 Auditoria 535.4 Portafolio de proyectos 545.5 ITIL (Information Technology Infrastructure Library) 54Tema Nº 6: Modularización de Programas 556.1 Relación Arquitectura Empresarial – Business process Management - Service Oriented Architecture (AE & BPM & SOA) 55Tema Nº 7: Frameworks de Arquitectura Empresarial 587.1 Framework de AE 587.2 Framework de Zachman 587.3 TOGAF (The Open Group Architecture Framework) 597.4 FEA (Federal Enterprise Architecture) 607.5 ARIS (Architecture of Integrated Information Systems) 617.6 Enterprise Architecture as Strategy (Ross et al) 62Tema Nº 8: Modelos de Madurez de BPM 638.1 ¿Qué es un modelo de madurez? 638.2 Modelo de Madurez BPM de la OMG (BPMM: Business Process Maturity Model) 638.3 Modelo de madurez BPM de Schmelzer 64UNIDAD III: BUSINESS PROCESS MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN) 65Tema Nº 8: Evolución de Business Process Model and Notation (BPMN) 658.1 Historia de técnicas para modelado de sistemas y procesos 658.2 Clasificación de las técnicas de modelamiento 678.3 Otras Técnicas de Modelado 678.4 Business Process Model and Notation (BPMN) 68Tema Nº 9: Los elementos básicos de BPMN 709.1 Modelos, instancias, token y correlaciones 709.2 Categorías de los elementos de BPMN 709.3 Actividades 71

9.4 Flujos de Secuencia 749.5 Actividades globales 759.6 Un proceso simple en BPMN 75

9.7 Flujo de Procesos con Gatewatay 759.8 Eventos 809.9 Lane 879.10 Artefactos 889.11 Participantes y flujos de mensajes 889.12 Subprocesos 89Tema Nº 10: Diferentes vistas de un proceso 90Tema Nº 11: Categoría de Procesos 9111.1 Orquestación 9111.2 Coreografía 9111.3 Colaboración. 92UNIDAD IV: AUTOMATIZACI N DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN) 93

Tema Nº 12: Automatización de Procesos 9312.1 Niveles de Procesos 9412.2 BPMN comparado con otras notaciones 99BIBLIOGRAF A 100


5/100

Pág. 5


PROCESOS DE NEGOCIO

UNIDAD I

INTRODUCCION Y DEFINICION DEL BPM

Tema Nº 1: Introducción al BPM

1.1 Antecedentes de BPM

(HITPASS, 2013)

La globalización está demandando mayores exigencias, tanto a las empresas privadas como a las

organizaciones públicas, en su capacidad de reacción frente a los cambios exigidos por el

mercado. Éstos pueden ser cambios en el tipo de demanda o cambios de regulaciones.Existen muchas definiciones de BPM. Aunque todas ellas tienen algo en común también existen

diferencias, sobre todo en el alcance. Algunos autores y expertos, en especial en Europa,

restringen el BPM a una disciplina de gestión sin incluir explícitamente el apoyo de TI. Otros

autores, definen BPM como el proceso hacia la automatización y operación de los procesos

implícitamente con TI.

El concepto de BPM es incluso más amplio, pero va a depender cuelas son los objetivos que

perseguimos con BPM, que por lo general todas las escuelas los comparten. Por lo general las

diferencias de las escuelas se encuentran en el concepto de cómo enfrentar el proceso hacia el

logro de los objetivos y cada concepto parte por una definición, razón por la cual algunas

definiciones se diferencian de otras. La descripción de los objetivos es clara y bien definida.

1.2 Historia y Evolución

Evolución de la Ingeniería de Procesos hacia el BPM

Fuente: (HITPASS, 2013)


6/100

Pág. 6


PROCESOS DE NEGOCIO

1.2.1 La ingeniería de procesos nace con Frederick Taylor

(HITPASS, 2013)

La idea que las actividades (el trabajo) se pueden describir como un proceso no es nueva. A

principios del siglo pasado Frederick Winslow Taylor (1911) desarrolló el concepto de la

“Administración Científica” (Taylor publicó poco antes de morir (1915) en 1911 su obra que lo hizo

tan famoso «The Principles of Scientific Management ».) [TaylorFre08]. A Taylor se le atribuye

haber desarrollado los principios de la especialización y estandarización de los procesos en la

producción industrial elevándolos a una ciencia que podríamos llamar «ingeniería industrial y

mejora de procesos», razón por la cual muchos autores lo denominan como el padre de la

ingeniería industrial. Taylor aporta en métodos de observación de buenas prácticas, de medición

del trabajo y a partir de estos conocimientos de diseñar procesos industriales desagregados hasta

el nivel de actividad manual (Taylor hablaba de «administración de tareas») altamenteespecializados para lograr mejoras sustanciales en la productividad.

Los principios de la administración científica que describe Taylor en su obra pueden resumirse

según (Bravo, 2011) en los siguientes cuatro pasos:

1. Desarrollar el estudio científico del trabajo, una “ciencia” según Taylor

2. Seleccionar científicamente al obrero más adecuado a la tarea, según sus capacidades, y luego

instruirlo en cómo hacer correctamente la tarea, según el punto anterior.

3. Cooperar con los obreros para que todo el trabajo sea hecho de acuerdo con los principios

científicos que se aplican. Se refiere a una cooperación de los investigadores y de los

administradores. Armonía es la palabra principal que emplea Taylor.4. Distribuir equitativamente el trabajo y la responsabilidad entre la administración y los obreros.

Juan Bravo (Bravo, 2011) en su libro indica lo siguiente sobre Taylor:

Podemos resumir que el objetivo que perseguía Taylor al reunir hechos y mediciones era

proporcionar un fundamento científico para diseñar y mejorar los procesos. Con estos

fundamentos pretendía terminar con la improvisación que predominaban en aquella época. En vez

de hacer que cada trabajador hiciera la tarea a su manera, Taylor quería encontrar la forma óptima

de hacerla y estandarizar las buenas prácticas haciéndolas más eficientes y lograr economías de

escala. Este enfoque fue empleado con éxito durante toda la época de la industrialización

(mercado de la oferta) durante el siglo XIX y principios del siglo XX, pero esta técnica estaba

restringida a los procesos manuales y a la producción industrial y no incluía el seguimiento de

los procesos de gestión.


7/100

Pág. 7


PROCESOS DE NEGOCIO

1.2.2 El cambio del mercado de la oferta al mercado de la demanda

(HITPASS, 2013)

Más adelante, a principios de los 80, aparecieron enfoques estadísticos con el objetivo de mejorar

los procesos de control. Así nació el enfoque TQM (Total Quality Management) basado en una

gestión de control estadístico, pero aplicarlo requiere de una rigurosa disciplina en la organización

que es Management) basado en una gestión de control estadístico, pero aplicarlo requiere de una

rigurosa disciplina en la organización que es difícil de alcanzar.

Empresas japonesas, en particular Toyota, reconocieron a principios de los 90 el cambio hacia el

mercado de la demanda y enfocaron la gestión orientada hacia las necesidades del negocio

(clientes).

Nota: En el «mercado de la demanda», la oferta es mayor que la demanda por lo que en economíase deduce que la fuerza compradora es más influyente que el poder que pueden ejercer los

proveedores en los mercados en que operan.

Toyota desarrolló el concepto Toyota Production System (TPS)[ Liker06]. Este se caracterizaba

por contar con una estructura organizacional muy plana, instalando equipos multidisciplinarios en

centros de producción y con el encargo de resolver en forma autónoma propuestas de mejora

continua en los procesos de producción. A este sistema de trabajo se le llamó también Lean

Production, indicando en quitarle grasa a las estructuras organizacionales burocráticas y lentas en

sus procesos de decisiones.

Cuando en los años 90 muchas empresas occidentales fueron azotadas por la recesión, debido a

que los mercados habían llegado a una situación de la sobre oferta (saturación, cambio hacia el

mercado de la demanda) y el comienzo de la globalización, aparece el Business Process

Reengineering (BPR, Hammer and Champy, 1993) (Hammer, M. y Champy, J., 1993) como

medida de salvación para deburocratizar las empresas y ser más eficientes en sus procesos de

negocios.


8/100

Pág. 8


PROCESOS DE NEGOCIO

1.2.3 La reingeniería de procesos como precursor de BPM

(HITPASS, 2013)

El Business Process Reengineering BPR tiene como finalidad rediseñar y hacer más eficientes

los procesos, atacando las estructuras jerárquicas funcionales y alineándolos con los objetivosdel negocio, buscando alcanzar resultados de desempeño espectaculares a corto plazo. La

reingeniería de procesos se basa y apoya fuertemente en la incorporación de tecnologías de la

información, como elemento clave para la transformación esperada. El BPR es el primer enfoque

end to end en introducir como gestión los procesos de negocios transversales a las

organizaciones funcionales, centrados en las necesidades del cliente y no en los procesos de

producción, pero esto no fue fácil, muchos proyectos de BPR terminaron siendo proyectos de

racionalización de recursos con una fuerte reducción de personal. Perdiendo, muchas veces, la

perspectiva de agregación de valor para el cliente. BPR no fue el único enfoque en aparecer en

dichas décadas, a principio de los años 80 apareció Six Sigma como una opción para mejorar la

eficacia y eficiencia de los procesos de negocio. Este enfoque surgió en Motorola Inc. y el caso

práctico de aplicación más conocido fue General Electric en los ’90. Como TQM, Six Sigma se

basa en principios estadísticos para mejorar los procesos de control y mejora. La sigla Six Sigma

significa “one output defect in six Standard deviations of a probability distribution for a particular

process output”. Las técnicas de Six Sigma se emplean sobre la base de episodios o eventos, los

cuales debiesen estar dentro del nivel de exigencia definida para el proceso (cantidad de Sigmas),

pero no incorporan un pensamiento de mejora continua. Muchas empresas combinan el enfoque

de Six Sigma con TPS o Lean Production. Aún no se puede predecir cómo va a seguirevolucionando Six Sigma, pero a pesar que se detectan signos de cansancio aún está muy

difundido en empresas norteamericanas (Davenport, forward BPM Jeston and Nelis, 2008) (John

Jeston & Johan Nelis, 2008). A mediados de los 90 aparece la ola de los ERP’s (Enterprise

Resource Planning). Los ERP’s se vendieron como la solución para todos los problemas en la

organización, pero los ERP’s no generaron la eficiencia y eficacia esperada en los procesos d e

negocios, estaban diseñados para mejorar la eficiencia administrativa. A fines de los años 90 y a

principios del 2000 aparecieron los sistemas Customer Relation Management (CRM) como medida

para mejorar los servicios a los clientes, pero aún no contábamos con una integración entre los

procesos del front office (CRM) con los del back office (ERP).

http://www.bpr.es/http://www.bpr.es/


9/100

Pág. 9


PROCESOS DE NEGOCIO

Tema Nº 2: Conceptos Básicos de BPM

2.1 Definición de Proceso

(HITPASS, 2013)En principio, un proceso corresponde a la representación de un conjunto de acciones (actividades)

que se hacen, bajo ciertas condiciones (reglas) y que puede gatillar o ejecutar cosas (eventos). En

forma genérica se puede definir un proceso como:

«Una concatenación lógica de actividades que cumplen un determinado fin, a través del tiempo y

lugar, impulsadas por eventos.» Esta definición contiene los principales elementos que describen

un proceso: Los eventos son ocurrencias externas que inician un proceso, es decir un proceso no

se inicia por sí sólo, algo tiene que ocurrir y el proceso reacciona ante el suceso. El proceso debe

cumplir un determinado fin, en las ciencias económicas destinadas a producir bienes y servicios.

A diferencia de los eventos, las actividades en un proceso consumen tiempo y recursos. Una

actividad se puede definir como una «acción sobre un objeto», es decir el proceso de

transformación ocurre a través de las actividades en un proceso.

Las actividades en un proceso están encadenadas a través de una secuencia lógica que

determinan en su conjunto las condiciones del negocio.

Estos elementos básicos describen en su conjunto los procesos y están contenidos en la mayoría

de las notaciones para modelarlos, así también en el estándar BPMN. La definición es pura, no

dice nada respecto para qué objetivos se levantan y modelan procesos en una organización.

Ejemplo de proceso: Proceso de Matrícula Universidad

(Fuente: http://www.universidad.continental.edu.pe/sobre-matriculas/)

http://www.universidad.continental.edu.pe/sobre-matriculas/http://www.universidad.continental.edu.pe/sobre-matriculas/http://www.universidad.continental.edu.pe/sobre-matriculas/http://www.universidad.continental.edu.pe/sobre-matriculas/


10/100

Pág. 10


PROCESOS DE NEGOCIO

Ejemplo de proceso: Proceso de Elaboración de calzado artesanal

(Fuente: http://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.html)

Paso 1: Selección y adquisición del material.

Paso 2: Selección del modelo y corte a realizar.

Paso 3: Armado de la Pala.

Paso 4: Montado.

Paso 5: Desmontado.

Paso 6: Terminado.

Paso 7: Empaquetado y distribución.

2.2 Proceso de Negocio

(Hammer, M. y Champy, J., 1993) Introducen en su obra de Reingeniería de Procesos en el año

93, el concepto de proceso de negocio:

«Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de inputs y

crean un output que es de valor para un cliente.»

Los procesos de negocio son los que crean valor para un cliente, es decir la definición está ligada

al concepto de creación de valor para el cliente. Siguiendo la definición propuesta en este trabajo

de un proceso en forma general, se definirá un proceso de negocio como:

«Un proceso de negocio es un conjunto de actividades que impulsadas por eventos y

ejecutándolas en una cierta secuencia crean valor para un cliente (interno o externo).»Un proceso de negocio se reconoce por el tipo de evento que lo gatilla. Una de las principales

características de un proceso de negocio es que es gatillado por el cliente y los resultados de la

ejecución del proceso tienen que volver al cliente, entendiéndose en el sentido más amplio que el

cliente también puede ser interno, por ejemplo un área de negocio o externo un proveedor. En

Ingeniería Industrial se le conoce como Pull Process, el cliente tira el proceso de negocio. A

dif erencia de Push Process, donde se “empuja” los objetos a través del proceso para llegar al

cliente. El concepto de Pull y Push Process está relacionado con la forma en que se planifican,

distribuyen y reponen los productos en bodega (logística). Existen dos formas que cubren este

ciclo:

1. En el concepto push, se calcula la demanda sin conocer los pedidos de los clientes (por ejemplo

las representaciones de autos en Chile funcionan así). Importan autos y luego los venden.

2. En el concepto de pull, solo se planifica y produce bienes bajo demanda real y está muy

relacionado con el concepto de just in time, es tratar de bajar al mínimo los procesos de bodegaje

intermedio. Dell por ejemplo se hizo famoso en los años 90 aplicando este concepto al extremo.

Sólo se produce a pedido real (orden de compra) del cliente. Es normal encontrar en muchas

compañías combinaciones de ambos tipos de flujos, en particular para responder con mayor

oportunidad a los requerimientos de los clientes. El proceso de negocio es transversal a las áreasy atraviesa la cadena de valor de principio a fin (también se usa mucho el término anglosajón «end

http://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.htmlhttp://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.htmlhttp://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.htmlhttp://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.html


11/100

Pág. 11


PROCESOS DE NEGOCIO

to end»). Este principio es indistinto si se trata de un cliente externo (cliente final) de la empresa o

cliente interno.

Muchas veces se confunden los macroprocesos con los procesos de negocio.

Por lo general corresponden los macroprocesos con las grandes áreas de negocio de una

empresa como por ejemplo abastecimiento, producción, bodega, venta, etc. Ningún cliente externova a gatillar un proceso en el área de abastecimiento y los procesos en esta área tampoco

atraviesan la cadena de valor de la empresa.

A pesar que estas áreas pueden ser muy grandes y muy complejas no tienen relación directa con

el concepto de proceso de negocio: gatillado por el cliente, de principio a fin y el resultado tiene

que ser de valor para el cliente.

Los procesos de negocio se encuentran debajo de los macroprocesos y los atraviesan. Al mapear

los procesos de una organización en muchas ocasiones se cometen grandes errores al respecto.

Si se descomponen «top down» los macroprocesos se van a mapear los procesos internos de las

áreas en diferentes grados de abstracción, y justamente éstos no son los procesos de negocio.

¿Cómo se pueden identificar entonces los procesos de negocio?

Para estos efectos se recomienda realizar un análisis del contexto y hacer un listado de todos los

eventos iniciados por el cliente. A continuación se nombran ejemplos de procesos de negocio:

Solicitudes de créditos, préstamos, devoluciones Solicitud de apertura de cuenta bancaria Compra

de pasajes Procesos de reclamaciones Seguimiento de resolución de problemas en Servicio a

Clientes Gestión de Hipotecas, Multas,... Recepción y pago de factura Recepción y confirmación

de orden de compra Elaboración de ofertas

Los siguientes ejemplos no se pueden clasificar como procesos de negocio.

Partida doble en contabilidad: • Se trata de una función contable, que le sigue a un movimiento

contable.

Reserva de pasajes: • Se trata de un subproceso del proceso de negocio «compra de pasajes».

En este caso no se cumple el principio de finalidad, que sería la compra del pasaje.

Ingreso de un nuevo empleado al sistema de RRHH: • Actividad manual del proceso de negocio«contratación de personal». El cliente interno es el área de negocio, quién gatilla la solicitud de

contratación.

Ingreso de una orden de compra: • Actividad manual del proceso de negocio «compra de un

producto o servicio».

Envío de email: • Actividad técnica sin significado de negocio

Emitir una póliza: • Emitir puede significar imprimir, generar o extender una póliza de seguros, pero

de todas formas el proceso de negocio sería la «solicitud de un contrato de seguros»


12/100

Pág. 12


PROCESOS DE NEGOCIO

Debe tener cuidado en no confundir el concepto de «cadena de valor» propuesto por Porter con el

concepto de «proceso de negocio» que está ligado al concepto de valor para el cliente. La figura

muestra la típica estructuración de una cadena de valor descompuesta en procesos de dirección,

procesos primarios y procesos de soporte, siendo los procesos primarios los procesos de la

«cadena de valor» porque están directamente relacionados con la creación de bienes y serviciospara el cliente externo, pero la cadena de valor no es lo mismo que los servicios que solicitan los

clientes.

Figura Estructura de Cadena de Valor según Porter

FUENTE: (HITPASS, 2013)

La siguiente figura muestra la transversalidad de los procesos de negocio que son impulsados por

clientes y cuyos resultados tienen que volver a ellos.

Figura Estructura de procesos de negocio


La cadena de valor muestra las dependencias en los pasos de producción, mientras que los

procesos de negocio muestran las dependencias de las políticas de negocio para atender las

peticiones de los clientes y llevarlos a un resultado satisfactorio que tiene una expresión demercado, es decir el cliente está dispuesto a pagar (creación de valor).


13/100

Pág. 13


PROCESOS DE NEGOCIO

2.3 ¿Gestión de o por procesos de negocio?

Actualmente es muy utilizado ambos términos tanto Gestión por procesos como Gestión de

procesos, y es importante saber si existe diferencia entre ambos términos:

(HITPASS, 2013)

En una organización existen muchos procesos de negocio. Si nos referimos a gestionar un

proceso en particular hablamos de «gestión de proceso».

Generalmente el primer objetivo en las organizaciones es lograr un mayor control y desempeño

sobre los procesos.

Mayor control significa tener conocimiento en tiempo real en qué estado se encuentra cada uno de

los procesos instanciados.

Por ejemplo saber sobre la carga de trabajo de cada uno de los usuarios y saber cuáles procesos

se encuentran estancados por alguna razón.

Esta información le permite al supervisor (gestor del proceso) detectar problemas antes que

impacten sobre los resultados. Al tener mayor control sobre lo que está sucediendo podemos

mejorar el desempeño de los procesos, por ejemplo acortar los tiempos de ciclo y en general

mejorar el grado de satisfacción de cliente.

Al introducir «gestión de procesos» en una organización tenemos la posibilidad de mejorar el

grado de cumplimiento de objetivos funcionales, pero no es un instrumento suficiente para alinear

la gestión de procesos con la estrategia de la organización y sus debidos objetivos de negocio.

La gestión de procesos se focaliza en medir y analizar el desempeño de los procesos enoperaciones, pero no incluye los conceptos de alineamiento con otras capas de la organización,

por ejemplo la integración a los procesos de alineamiento con la estrategia y la capa de

tecnología.

Gestión por procesos significa incluir los procesos de planificación y alineamiento a la gestión de

procesos.


14/100

Pág. 14


PROCESOS DE NEGOCIO

Entre académicos y profesionales de BPM es ampliamente conocido el principio que «los procesos

deben seguir la estrategia» y que «la tecnología debe seguir a los procesos ».

Gestión de procesos no incluye estos ciclos de planificación y de alineamiento a los procesos

como lo pide la disciplina de gestión BPM, pero si ampliamos el concepto de gestión e integramos

las otras disciplinas empresariales a la gestión de procesos, entonces hablamos de «gestión porprocesos» y en su definición más amplia en inglés de Business Process Management (BPM).

Fuente: http://pedrorobledobpm.blogspot.com/2014/07/gestion-de-procesos-versus-gestion-por.html

En la gestión de procesos nos centramos en el resultado de cada proceso y las acciones a realizar(mejora continua, reingeniería o innovación).

1. Identificación de los procesos y planificación de los Objetivos a conseguir con cada proceso. (Fasede Modelización y Planificación de Procesos)

2. Medición de los resultados de los indicadores en la ejecución o funcionamiento de los procesos(Fases de Automatización y Ejecución de Procesos)3. Control de la consecución de los indicadores al compararlos con los objetivos y definición de

acciones correctoras (Fase de Monitorización)En la Gestión Por Procesos nos centramos en la alineación de la gestión de procesos con la estrategiaempresarial y con el resto de gestiones empresariales:

1. La gestión DE procesos para que cada proceso produzca el resultado esperado2. La alineación de cada proceso con la Estrategia Empresarial, de esta forma sabremos qué aporta

cada proceso a cada objetivo estratégico, y definido un objetivo estratégico a qué procesos afecta ysi es necesario optimizarlos

3. La cultura de la empresa será coherente con un sistema de gestión de procesos4. La gestión y dirección del personal se realizará con enfoque a procesos5. Las diferentes gestiones de la empresa se alinearán con la gestión por procesos


15/100

Pág. 15


PROCESOS DE NEGOCIO

2.4 Gestión tradicional sin BPM

Para conceptualizar y entender la diferencia entre la gestión de y por procesos es importante

realizar una retrospectiva, y saber cómo funcionaba una organización sin BPM.

(HITPASS, 2013)

Para responder a esta pregunta fundamental vamos a analizar primero cómo funciona la gestión

tradicional centrada en consolidar planes de negocio por área y no por procesos de negocio que

son transversales a la organización.

Por lo general, la formulación de la estrategia de una empresa es amplia y define los grandes hitos

que se deben lograr y sobre todo en que hay que centrarse para cumplir con la misión de la

empresa y los objetivos de negocio que se formulan a través del ciclo presupuestario en un año

comercial, pero la estrategia es transversal a las áreas de negocio, igual que los procesos denegocio. Aquí nos encontramos en la gestión empresarial tradicional con la primera brecha.

De alguna forma se traspasan los objetivos de negocio desde la alta dirección a la capa de

operaciones y a su vez operaciones formula, por medio de una especificación, los requerimientos

de cambio a la capa de tecnología, pero este proceso no está estandarizado y menos integrado

bajo una metodología común. Al no estar estandarizado ni integrado ocurren fricciones y por lo

tanto pérdida de valor. Como la estrategia es transversal y no existe un cargo que se

responsabilice por el rendimiento del proceso completo, vale decir de principio a fin, los procesos

de alineamiento son lentos y de alto costo. Así se produce pérdida de valor en tres grandes

ámbitos de la gestión empresarial tradicional, a saber:

1. Cómo plasmar la estrategia en la organización

2. Cómo lograr que los procesos se implementen con tecnología

3. Pérdida de valor en la estructuración misma de los procesos

Estas son las tres grandes razones (oportunidades) para implementar gestión por BPM. El aportedel concepto de BPM como disciplina integrada es cerrar estas brechas.


16/100

Pág. 16


PROCESOS DE NEGOCIO

2.5 Bussiness Process Management (BPM)

Es una metodología corporativa y disciplina de gestión, cuyo objetivo es mejorar el desempeño

(eficiencia y eficacia) y la optimización de los procesos de negocio de una organización, a través

de la gestión de los procesos que se deben diseñar, modelar, organizar, documentar y optimizar

de forma continua. Por lo tanto, puede ser descrito como un proceso de optimización de procesos.

El modelo de administración por procesos, se refiere al cambio operacional de la empresa, al

migrar de una operación funcional a una operación administrada por procesos.

El BPM es el entendimiento, visibilidad y control de los procesos de negocio de una organización.

Un proceso de negocio representa una serie discreta de actividades o pasos de tareas que

pueden incluir personas, aplicativos, eventos de negocio y organizaciones.

BPM se puede relacionar con otras disciplinas de mejora de procesos como Six Sigma. Los

procesos de negocio deberían estar documentados (actualizados), para ayudar a entender a laorganización que están haciendo a través de su negocio.

Detallamos otros conceptos de BPM:

(John Jeston & Johan Nelis, 2008): «BPM es el logro de los objetivos empresariales a través de la

mejora, la gestión y el control de los procesos de negocio.»

En esta definición, se abstrae explícitamente, que la tecnología va a solucionar los problemas a las

organizaciones.

Paul Harmon (Harmon, 2007) también define BPM como: «Una disciplina de gestión focalizada en

la mejora del rendimiento corporativo por medio de la gestión por procesos de negocio.»

Finalmente Jeston y Nelis (John Jeston & Johan Nelis, 2008) concluyen, BPM es:

Más que sólo software, más que solo la mejora o la reingeniería de los procesos, no es solamente

una moda, es parte integral del management, más que sólo levantamiento y modelado de

procesos, también es la implementación y ejecución de los procesos, los cuales requieren ser

analizados y mejorados.


17/100

Pág. 17


PROCESOS DE NEGOCIO

Factores críticos del BPM según Jeston y Nelis:

El logro de la estrategia organizacional

La organización está alineada con los procesos end to end

Los objetivos están alineados con la estrategia organizacional

Los procesos deben mejorar en su eficiencia y ser eficaces Gestión orientada a procesos(Management)

Controlar el ciclo completo de BPM

Seleccionar los procesos críticos, no todos los procesos contribuyen al logro de los objetivos

estratégicos

Implementar BPM tiene que tener impacto en los beneficios del negocio Nuestra definición tiene

un alcance amplio y abarca tanto la disciplina de gestión como la incorporación de TI para la

automatización de los procesos.

Definimos en forma abreviada BPM como: «Disciplina de Gestión por Procesos de Negocio y

de Mejora Continua apoyada fuertemente por las Tecnologías de la Información»

Una definición más amplia la encontramos en la guía de referencia de la Asociación Internacional

de Profesionales de BPM (BPM Common Body of Knowledge, ABPMP (Association of BPM

Professionals) (Tony Benedict, Nancy Bilodeau, Phil Vitkus, Emmett Powell, Dan Morris, Marc

Scarsig, Denis Lee, Gabrielle Field, Todd Lohr, Raju Saxena, Michael Fuller, Jose Furlan, 2013):

«Business Process Management (BPM) es un enfoque sistemático para identificar, levantar,

documentar, diseñar, ejecutar, medir y controlar tanto los procesos manuales como

automatizados, con la finalidad de lograr a través de sus resultados en forma consistente los

objetivos de negocio que se encuentran alineados con la estrategia de la organización. BPM

abarca el apoyo creciente de TI con el objetivo de mejorar, innovar y gestionar los procesos de

principio a fin, que determinan los resultados de negocio, crean valor para el cliente y posibilitan el

logro de los objetivos de negocio con mayor agilidad.»

Como lo indica (HITPASS, 2013) la definición de la ABPMP, BPM es una disciplina integradora

que engloba técnicas y otras disciplinas organizacionales, que abarca las capas de negocio y

tecnología, que se comprende como un todo integrado en gestión a través de los procesos. Nos

inclinamos por esta definición porque diferencia entre procesos manuales y automatizados, pero

integra ambos casos a la disciplina de BPM. Con esta definición pretendemos lograr un

entendimiento común que es necesario para tener éxito en introducir BPM en una organización.

Para lograr los objetivos que se persiguen en BPM es necesario sincronizar e integrar los

procesos manuales con los implementados con apoyo de TI o los que se van a automatizar.


18/100

Pág. 18


PROCESOS DE NEGOCIO

Tema Nº 3: Organización y Estructura del BPM

3.1 Conceptos de Gestión en BPM

BPM ataca la automatización de procesos por toda la empresa, pero con total adherencia a las

modificaciones de negocios que un mercado de fuerte competición exige. No existe una

combinación única y exacta de los procesos, metodologías e indicadores, y en muchos casos

estos existen aisladamente.

Una herramienta de BPM debe soportar las actividades básicas de la gestión, que pueden ser

resumidas en:

•Definir una estrategia para conducir el performance;

•Traducir la estrategia en objetivos, indicadores y metas;

•Acompañar el progreso en relación a las metas;

•Analizar los motivos en caso de metas no alcanzada y

•Seleccionar e implementar acciones correctivas.

Sistemas de BPM sirven para ayudar la empresa a controlar mejor sus propios procesos, a

reformarlos cuando es necesario y a realizar tareas importantes con más eficiencia. Estos

sistemas dan al usuario más control sobre la automatización de procesos, lo que alivia el trabajo

de la informática. El BPM impone a la empresa un desafío muy grande, pues obliga el usuario a

dos acciones que, casi siempre, a él no le gusta hacer: repensar en las tareas del día-a-día y, al

menos en la fase de implementación, trabajar lado a lado con el personal de informática.

(HITPASS, 2013)

BPM como disciplina de gestión orientada a procesos abarca dos grandes áreas de la gestión

empresarial: BPM Governance y BPM Operacional.

3.1.1 BPM Governance

(HITPASS, 2013)

BPM Governance, también llamado gobierno corporativo, como un modelo de gestión

corporativo orientado a procesos, pero integrado con todas las capas de una organización

(capa de dirección, operacional y de tecnología), las fases del ciclo de gestión, la gestión del

cambio de nuevos requerimientos (en inglés: Change Management), la estructura organizacional y

todos los instrumentos de alineamiento de y entre las estructuras corporativas.

BPM Governance abarca el alineamiento con todo el ciclo de gestión organizacional desde la

planificación y gestión estratégica, la definición de planes de negocio, el ciclo presupuestario, la

definición de perfiles y cargos, la gestión en operaciones, apoyo tecnológico hasta el alineamiento

con el portafolio de proyectos corporativo.


19/100

Pág. 19


PROCESOS DE NEGOCIO

(Harmon, 2007) En la literatura se encuentran varias definiciones de BPM Governance, (John

Jeston & Johan Nelis, 2008), la mayoría de ellas muy amplias pero todas coinciden que se trata de

un concepto definido para una organización de cómo debe aplicarse «Gestión por Procesos» y

que integra instrumentos y disciplinas existentes en torno a los procesos de negocio.

Harmon (Harmon, 2007)] discrimina primero entre «governance» y «management», explicando

que «governance» es la organización del «management». Resumiendo a su entender cuando

hablamos de governance nos referimos a un modelo específico de gestión, mientras que

«gestión» es una actividad humana.

Para Jeston y (John Jeston & Johan Nelis, 2008)(pags. 323-324) en un modelo de BPM

Governance son clave la definición de roles y responsabilidades, los procesos de alineamiento con

la estrategia de la empresa, el control de gestión orientado a procesos y finalmente la

estandarización de los procesos de gestión.

Fuente:

https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Gobierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650

https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Gobierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Gobierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Gobierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Gobierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Gobierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650


20/100

Pág. 20


PROCESOS DE NEGOCIO

3.1.2 BPM Operacional

(HITPASS, 2013)El BPM Operacional abarca la gestión del ciclo BPM por proceso y no los

mecanismos de alineamiento con las otras capas de la organización que, es dominio de un modelo

que incorpora BPM Governance.

El ciclo presentado está pensado para ser aplicado para cada proceso por separado o en forma

independiente. Cada proceso puede encontrarse en un estado diferente del ciclo. El ciclo

comienza a partir de dos posibles constelaciones: Un proceso actual que debe levantarse y

documentarse y/ o rediseñarse. Se debe introducir un nuevo proceso, no existente en la

organización.

En la fase de «Levantamiento del Proceso » primero se debe recoger la información sobre cómo

está organizado el flujo de trabajo. Esto se realiza con la ayuda de técnicas de moderación,talleres, entrevistas, recolección de documentación, etc. Para esto en el proceso a levantar se

debe:

Delimitar claramente desde procesos anteriores o posteriores

Describir los servicios que produce para los clientes y qué prioridad tiene desde el punto de

vista de los objetivos de negocio

Representar tanto el flujo de trabajo como los roles que intervienen en cada uno de los

pasos, los recursos que se utilizan y los sistemas de información que lo apoyan


21/100

Pág. 21


PROCESOS DE NEGOCIO

En la etapa de «Documentación del Proceso» el conocimiento adquirido en la etapa de

levantamiento se documenta en un modelo de procesos que refleja la situación actual. La

documentación resultante comprende los diagramas de los flujos, fichas de descripción, políticas

de negocio y procedimientos que se utilizan para ejecutar el trabajo.

Las debilidades identificadas en la fase de «Análisis de mejora» o las desviaciones que muestra el«Monitoreo del Proceso» son por lo general el punto de partida para un rediseño de procesos.

Eventualmente, se pueden evaluar diferentes variantes o escenarios con ayuda de simuladores.

Esto aplica también si se está diseñando un proceso nuevo. En ambos casos el resultado o

entregable es un modelo de procesos deseado (To be).

La etapa de «Implementación del Proceso» abarca tanto la implementación técnica como también

las adaptaciones organizacionales que se requieren. La gestión del cambio (en inglés: Change

Management) y la estrategia de comunicación constituyen elementos fundamentales a considerar

para el éxito del proyecto. El modelo técnico puede implementarse por medio de una Suite de

BPM (en inglés: Business Process Management Suite, BPMS) o a través de un clásico desarrollo

de software. El resultado final de la implementación técnica del proceso es la situación actual (As

is) automatizada y documentada, corresponde con el modelo de proceso deseado (To be).

Las fases desde el «Levantamiento del Proceso» hasta la «Implementación del Proceso» se

administran por lo general por medio de la organización de un proyecto, mientras que el

«Monitoreo del Proceso» (inglés: Process Controlling) se concibe como un proceso continuo y

forma parte de todas las operaciones. Las actividades más importantes de «Monitoreo del

Proceso» son el control constante de las operaciones (técnicamente hablamos del control de

instancias de los procesos reales) y su respectiva evaluación de los indicadores. De acuerdo a la

escuela de BPM, si se detectan problemas puntuales debieran corregirse de inmediato o en línea.

Si hay recursos disponibles es posible solucionar problemas estructurales sin necesidad de

formular un proyecto, pero si sus causas no están claras o son complejas, se hace necesario

planificar e implementar un proyecto de mejora y rediseño. La decisión sobre si es necesario

formular un proyecto nuevo o instalar un equipo de trabajo en operaciones, debiera tomarla el

responsable del proceso de común acuerdo con los participantes.

El ciclo BPM muestra en sus principales fases cómo funciona el círculo virtuoso de mejora

continua de los procesos. Para aplicarlo es necesario:

Asignar responsabilidades a los procesos y a cada uno de sus pasos Emplear métodos de análisis

y gestión en él Contar con el apoyo de soluciones adecuadas de TI

Lograr una coordinación fluida entre estas tres componentes es tarea de gestión por procesos

(BPM-Governance). Gestión por procesos se encuentra por sobre cualquier proyecto de

modelamiento y tiene por consiguiente la misión de apoyar la «Gestión de Procesos», para el

cumplimiento de los objetivos estratégicos.


22/100

Pág. 22


PROCESOS DE NEGOCIO

3.1.3 Gestión de Casos - Case Management

La gestión de casos es una forma de avanzar y mejorar la atención integrada, coordinada y

continuada, centrado en la responsabilidad compartida de coordinar los cuidados, recursos,

servicios y profesionales. Nos dice:

(HITPASS, 2013)

Un caso, como un proceso de negocio, consiste en un conjunto de actividades o tareas. Sin

embargo, a diferencia de un flujo predeterminado, el proceso de un caso desde su inicio hasta la

finalización no está limitado a una secuencia del proceso como lo entendemos normalmente, de

principio a fin, aunque con una lógica compleja de anidación y encadenamiento.

¿Qué actividades se deben realizar para completar el caso? Depende de los detalles de cadacaso. Por lo general, el encargado del caso, o tal vez todos los participantes de una tarea, tomarán

esta decisión. Las "reglas", por así decirlo, son conocimiento experto de los usuarios. En la

literatura también se habla de «adaptive case management (ACM) o dynamic case management»,

en donde se argumenta que el foco se centra más en el tratamiento del caso que en el proceso

mismo [Lamont12].

Por ejemplo en un hospital toda la atención se centra en el paciente y el caso es lo que está

sucediendo con él. Los procesos clínicos apoyan la atención del caso, pero el médico o el equipo

médico decide qué procesos de diagnóstico o de apoyo terapéutico se van a emplear y cuándo

recurrir a ellos. El caso específico determina la secuencia. Sin embargo, en la industria de la salud

a medida que ha aumentado el conocimiento se han desarrollado guías de práctica clínica que

orientan la toma de decisiones por parte del equipo de salud, facilitando la estandarización de los

procesos clínicos. En algunos tratamientos, hoy en día lo normal es encontrarse con un proceso

conocido de principio a fin. En todo caso, el mismo proceso debe considerar en sus reglas la

opción de no continuar con el flujo estandarizado.

La gestión de casos no suele trabajar por la carpeta de enrutamiento del caso a la siguiente tarea

de forma secuencial en la línea. En su lugar, los avances son a través de eventos, tanto externoscomo internos:

Los eventos externos afectan el caso. El contenido de ese mensaje se agrega a la carpeta del

caso y nuevas tareas o procesos pueden ser creados. Los eventos internos incluyen las

asignaciones y reglas del negocio. Los trabajadores de casos asignan tareas e inician los

procesos que consideren necesarios en su trabajo sobre el caso. Las reglas del negocio pueden

crear y asignar tareas o llevar a cabo plenamente las acciones automatizadas sobre la base de

cualquiera de los eventos externos, la realización de las tareas de los demás casos, o el

vencimiento de los plazos de trabajo.


23/100

Pág. 23


PROCESOS DE NEGOCIO

Así, de un flujo determinado, el modelo conceptual de un caso es una colección visible de tareas

en conjunto con los documentos y carpetas de cada caso. El estado del caso en su conjunto está

determinado por el estado combinado de todas sus tareas y documentos.

Las típicas áreas en donde nos encontramos procesos del tipo de «gestión de casos» son:

Área salud Trabajo social

Soporte

Educación

Proyectos que inducen al cambio

Exploraciones mineras

En general todos los negocios que requieren de conocimiento experto que aún no han alcanzo un

nivel de estandarización ¿Cuáles son las funcionalidades específicas que se requieren para

apoyar tecnológicamente la gestión de casos en el contexto de BPM? Tomando en consideración

las principales características que tiene la gestión de casos se requiere:

Derivación del caso a otros especialistas

Decisiones grupales Gestión de contenidos

Administración de documentos

Funcionalidades de búsqueda y filtros

Configuración de atributos

Adjudicación de recursos

Ejemplo Gestion de caso – ClinicaFUENTE:http://www.elsevier.es/es-revista-enfermeria-clinica-35-articulo-gestion-casos


24/100

Pág. 24


PROCESOS DE NEGOCIO

3.1.4 ¿Case Management versus BPM?

(HITPASS, 2013)

Luego de revisar las características distintivas de ambos enfoques, podemos indicar que, BPM

normalmente se focaliza en procesos repetitivos con flujos muy estrictos. La abstracción necesariadebe gestionar tareas más complejas. Por su parte, la gestión de casos ofrece una flexibilidad

mucho mayor, pero falla cuando se dirige al usuario de negocio y dificulta el cumplimiento de las

normas reguladoras. Se pueden complementar y puede ser útil su trabajo en conjunto. Sin

embargo, las decisiones recurrentes en la gestión de casos, permiten ir identificando patrones

respecto a las acciones, pero dada la naturaleza de la gestión de casos, no debiese estructurarse,

pero es posible generar manuales o guías de ejecución.

La gestión de casos aporta flexibilidad y directrices. Se centra en información de casos, no en los

procesos determinados. Un caso recoge toda la información necesaria para gestionarlo: los

actores (usuarios/ roles que participan en el caso), datos/ contenido, reglas y, por supuesto,

procesos y tareas. La gestión de casos habilita a los trabajadores calificados dándoles la

posibilidad de tomar decisiones dentro de las restricciones de las estrategias de negocio. La

gestión de casos define negocios y objetivos realizables, y los comunica de forma transparente

mientras que los propios usuarios añaden tareas para lograr esos objetivos. Esto lleva a un modo

“design-by-doing” que permite a los usuarios crear, modificar y analizar los procesos sobre la

marcha. Los procesos adaptables, a pesar de no tener una progresión predecible y repetitiva, se

mueven de un estado menos ordenado a otro más ordenado por medio de la acción del usuario.

Las decisiones tomadas por los usuarios son compartidas al ser almacenadas en plantillas y están

disponibles para otros actores de la compañía como acciones propuestas. Este es el caso de lo

que se llama ficha clínica única en la historia de un paciente en un hospital que siempre se puede

volver a retomar y crear una nueva instancia de proceso. Finalmente podemos resumir que Case

Management es un caso especial en la disciplina de BPM, pero igualmente se trata de gestionar

un proceso, en este caso llamado «gestión de un proceso de casos».

Fuente: http://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukasz

http://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukaszhttp://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukaszhttp://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukaszhttp://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukasz


25/100

Pág. 25


PROCESOS DE NEGOCIO

3.2 La automatización de procesos (BPA)

Implica la utilización de sistemas tecnológicos para automatizar las actividades y/o servicios de

una función o unidad de negocio determinada. De esta manera, procesos de negocio tales comolos que desempeñan las áreas de ventas, administración, operaciones, abastecimiento y

distribución, cobranzas, recursos humanos o TI pueden ser automatizados mediante la utilización

de paquetes informáticos especializados para desarrollar tal función. En consecuencia, el BPA

permite liberar al personal de labores rutinarias para que en contraste éstos se concentren en

actividades que maximicen el valor agregado de toda la operación.

(HITPASS, 2013)

Para entender que puede abarcar la automatización, se va a describir primero un proceso simple

de solicitud de crédito organizado en forma manual y luego se va a describir como hoy en día se

automatizan (implementan técnicamente) este tipo de procesos.

El proceso se inicia cuando se hace ingreso de una solicitud de crédito por correo y es derivada a

un ejecutivo de negocio en el banco. El ejecutivo revisa primero la solicitud en forma visual para

luego ingresar algunos datos del solicitante en un sistema de análisis de riesgo. Si el índice de

riesgo es positivo o aceptable, ingresa los datos de la solicitud en un sistema de crédito financiero

y luego envía la solicitud evaluada a su superior para que la apruebe. La automatización de este

proceso podría resultar de la siguiente forma: El arribo de la solicitud de crédito por correo, se

digitaliza y vía un programa de OCR (Optical Character Recognition ó reconocimiento de textoautomático) se extraen ciertas variables del formulario y se ingresan a un sistema de evaluación

de crédito. Luego se crea un documento electrónico que gatilla la creación de una orden de trabajo

en el Process Engine (motor de procesos) y es depositada en la bandeja de entrada de

actividades nuevas del ejecutivo correspondiente. El ejecutivo selecciona de la lista la solicitud

correspondiente y visualiza la solicitud de crédito en el Process Engine, la revisa formalmente y

luego el Process Engine por medio de un servicio web invoca el sistema de análisis de riesgo

enviándole (técnicamente se traspasan las variables) la información correspondiente. Si el

resultado del análisis es positivo, el Process Engine deriva automáticamente la solicitud de

aprobación a su superior, ingresando los datos en el sistema de crédito financiero por medio de un

servicio web y depositándolo en la bandeja de entrada de él para su debida aprobación.

Podríamos discutir si este proceso podría ser mejorado, pero este caso describe la diferencia entre

un proceso manual y uno automatizado:

El Process Engine controla el proceso, a través del cual dirige a los usuarios que participan en las

diferentes actividades y sus respectivos resultados (Human Workflow Management) y controla las

interfaces internas y externas con los sistemas que participan en el proceso (Orquestación de

servicios).


26/100

Pág. 26


PROCESOS DE NEGOCIO

Las decisiones sobre qué tipo de actividades o servicios deben invocarse, las toma el Process

Engine a través de la lógica técnica implementada (modelo de procesos técnico) y los puntos de

intervención de los usuarios. Dicho de otra forma, no siempre la lógica del proceso implementada

es mandatoria, en ciertas circunstancias puede ser influenciada por los participantes del proceso,

con la salvedad que debe quedar todo registrado.

Automatización de un proceso con un Proceso Engine


3.3 Los participantes en BPM

(HITPASS, 2013)

Si admitimos que BPM como disciplina de gestión integrada abarca todas las capas de una

organización desde la alta dirección hasta la tecnología que se encarga de implementar y dar

soporte a los procesos de negocio, queda claro que tanto para los procesos de BPM Governance

como para gestionar los ciclos de BPM deben participar muchos actores en un gobiernocorporativo por procesos.

Los roles de participantes que se describen a continuación debieran estar presente de alguna

forma en proyectos, gestión u operaciones de BPM. La figura 2.3 muestra los principales roles que

asumen los participantes en las capas de negocio y de TI.

Se ha podido constatar que empresas que cuentan con mayores niveles de madurez en BPM

también cuentan con roles bien definidos y estructuras orientadas a procesos. En el capítulo 9 se

va describir como se insertan estos roles en estructuras organizacionales orientadas a procesos.


27/100

Pág. 27


PROCESOS DE NEGOCIO

Dueño de Proceso (Process Owner): El dueño de proceso es un miembro de la alta dirección de la

empresa y responsable de una línea de negocio. Él es el responsable de plasmar la estrategia en

sus procesos de negocio. Él aprueba y disponibiliza parte o gran parte del presupuesto para un

proyecto de BPM. Él debiera tener el mayor interés de todos los participantes en promover BPM

como un instrumento de gestión.

Gestor de Proceso (Process Manager): El gestor del proceso es el responsable en operaciones,

reporta directamente al dueño de proceso y es él quien normalmente impulsa las propuestas de

mejora. Él es responsable de mantener la comunicación con los clientes y/ o proveedores.

Normalmente al gestor de proceso lo encontramos inserto en un nivel de jerarquía intermedia,

como subdirector, subgerente, jefe de sucursal o jefe de grupo.

Usuario de Negocio o Ejecutivo de Negocio (Process Participant): Es el que trabaja en

operaciones con el proceso, es decir parte integrante de la cadena que crea valor para losclientes. Se puede relacionar de muy diferentes maneras con el gestor de proceso. En la mayoría

de las organizaciones son usuarios de un área funcional, como ventas, finanzas o logística. En

estos casos no existe un gestor de proceso o actúa en su parte del proceso como tal y el usuario

reporta directamente al encargado del área. Si la empresa está organizada en forma matricial, lo

que en empresas globales es bastante común, pueden surgir conflictos entre el gestor de proceso

y los responsables de áreas. En estructuras matriciales se requiere de un modelo de decisiones

colaborativo para evitar el conflicto de intereses que surge en el punto de intersección.

Analista de Proceso (Process Analyst): Las competencias que se esperan del analista de procesos

son conocimientos de BPM en general, conocimientos del negocio y de la técnica de


28/100

Pág. 28


PROCESOS DE NEGOCIO

modelamiento de procesos que se va a utilizar. El analista de procesos apoya al gestor de proceso

como asesor interno o externo en todas las fases del ciclo de BPM. Él puede representar como

experto al gestor de proceso ante consultores externos o formar parte del equipo de proyectos de

BPM. El analista de procesos puede ser miembro de un área de negocio, de un área de procesos

o pertenecer como analista al departamento de informática de la empresa. En muy pocasocasiones será el responsable de la implementación de los procesos, a pesar que posee buenos

conocimientos o una gran afinidad con las tecnologías de la información. El analista de procesos

debiera de tener una gran habilidad en materias de desarrollo organizacional y técnicas de

comunicación. Pero sobre todo es, como lo indica su rol, un analista. Se espera un gran dominio

de la técnica de modelamiento y como coordinador entre personas de negocio y de TI es un rol

clave en cualquier proyecto de BPM. De acuerdo a observaciones y experiencias del autor,

muchas personas que ocupan este rol no cuentan con las competencias suficientes para cumplir

con este objetivo. En la mayoría de los casos porque les faltan las habilidades para este perfil. La

calificación más importante de un analista de procesos no es el comunicar sino el captar o

escuchar a los participantes. Buenos analistas de negocio sienten la necesidad de querer atender

todo en detalle. Al mismo tiempo poseen la empatía, como para poder ponerse en el lugar del

cliente y representar sus inquietudes. A ellos no se les escapa ningún detalle, pero al mismo

tiempo poseen un buen sentido de abstracción y pueden reducir los modelos a su esencia. El perfil

de un jefe de proyecto es diferente, él está centrado en cumplir las metas del proyecto y por lo

general prioriza las metas técnicas del proyecto, como fechas de entrega y mantención del

presupuesto de costos del proyecto, ante aspectos de calidad y eficiencia. Por esta razón no se

aconseja mezclar ambos roles en el sentido que un jefe de proyectos actúe como analista o vice

versa.

Ingeniero de Proceso (Process Engineer): El ingeniero de procesos implementa un modelo técnico

a partir de la especificación y el diseño operacional validado por él y los analistas de procesos. El

diseño técnico debe realizarse en el mismo entorno (process engine o BPMS) en donde se

implementarán los procesos. El ingeniero de procesos está bien capacitado en el entorno de

implementación, configura y construye la solución de BPM en la suite escogida. El ingeniero de

procesos también puede actuar como asesor en la fase de modelamiento de la lógica operacional.

Ingeniero de Desarrollo y Servicios (EAI Developer): Un programador puede asumir el rol de

ingeniero de desarrollo, si la solución requiere de ampliaciones o adaptaciones de desarrollo por

medio de programación (Servicios web, Java, C# u otros lenguajes).

Arquitecto SOA (SOA Architect): El arquitecto SOA es responsable de diseñar una arquitectura de

software que cumpla con los requerimientos técnicofuncionales de los procesos y servicios que se

van a automatizar y orquestar con los sistemas de información. La mayoría de los procesos de

negocio deben integrarse con los sistemas de información del back-office, desarrollar interfaces

B2B e integrar el BPMS a un portal corporativo.


29/100

Pág. 29


PROCESOS DE NEGOCIO

En empresas y organizaciones de menor tamaño, muchos de estos participantes tendrán que

asumir varios roles a la vez. Los siguientes roles en conjunto podrían por ejemplo asumir los

participantes en empresas Pyme:

Dueño de Proceso y Gestor de Proceso Analista de Negocio y Ejecutivo de Negocio Analista deNegocio e Ingeniero de Procesos Arquitecto SOA e Ingeniero de Desarrollo

3.4 Herramientas para BPM

Si se está pensando en diseñar o modelar procesos, se trata de un proceso de análisis.

Si se está pensando en BPM Governance, se trata de una metodología de gestión.

Si se está pensando realizar un prototipo, se trata de probar un entorno de implementación o de

automatización de procesos.

Y si se está pensando en acortar el ciclo de duración de un proceso, se trata de técnicas deoptimización y control a través de indicadores.

Todos estos objetivos se refieren a diferentes áreas de aplicación en BPM. Cada área de

aplicación es una especialidad en BPM y se apoyan en diferentes conceptos. Entonces

difícilmente se va a encontrar una herramienta universal que cubra todos estos ámbitos; por el

contrario sería una aberración intentar de construir una suite universal para BPM.

(HITPASS, 2013)

Como comparación analicemos un ejemplo práctico: Un Ferrari o un Porsche no nos va a servir

para jeepear y es impensable que un Jeep o un Land Roover gane una carrera de Fórmula 1.

Así es también en BPM, una suite de BPMS no nos va a servir para representar un mapa

estratégico y alinearlos con los procesos de una empresa. Tampoco nos va a servir para describir

las políticas y reglas de negocio en forma independiente de los procesos que las utilizan.

En el primer caso estamos hablando de una suite BPA (Business Process Analysis) y en el

segundo caso de Motores de Reglas llamados BRMS (Business Rules Management Systems).

En general se puede segmentar el mercado de herramientas para BPM en:

Herramientas que apoyan los procesos de análisis y Gobierno Corporativo (BPM

Governance) llamadas plataformas BPA (Business Process Analysis) o también EA

(Enterprise Architecture Tools)

Herramientas que apoyan la implementación técnica o automatización de los procesos

llamadas BPMS


30/100

Pág. 30


PROCESOS DE NEGOCIO

Herramientas que apoyan la administración y ejecución de reglas de negocio en forma

independiente de los sistemas que las utilizan, llamados Motores de Reglas o BRMS

(Business Rules Management Systems)

Herramientas que permiten implementar junto a los procesos los indicadores de control de

gestión en tiempo real, llamadas BAM (Business Activity Monitoring) Herramientas que permiten la orquestación de servicios entre los BPMS con cualquier tipo de

sistemas, principalmente los del back office, llamadas SOA Suite Herramientas que permiten

analizar los datos históricos de los procesos ejecutados para detectar desviaciones del

comportamiento deseado o descubrir nuevos patrones. A estos entornos analíticos se les

llaman herramientas de Minería de Procesos o Process Mining Tools en inglés.

Los expertos de BPM saben que dependiendo de la exigencias o la complejidad de una

organización puede hacerse necesario una descomposición más fina aun, por ejemplo de

separar la capa de presentación de un BPMS o de descomponer una SOA-Suite en varios

entornos especializados (ESB, SOA-Repository, etc.).

Todas estas herramientas las podemos posicionar en tres niveles o capas de un marco de

Arquitectura Empresarial moderno como lo muestra la figura.

Plataformas y herramientas para BPMFUENTE: (HITPASS, 2013)

La capa de negocio abarca todo el ciclo de planificación, análisis, gestión y control de la estrategia

y del modelo de negocio. Herramientas que apoyan todas las funcionalidades para planificar,

analizar, modelar y llevar el control de cambios de requerimientos bajo modelos integrados en una

base de datos común, se les denomina en inglés EA (Enterprise Architecture) o BPA (Business

Process Analysis) Tools.


31/100

Pág. 31


PROCESOS DE NEGOCIO

(HITPASS, 2013)

Nos comenta que: El lector no debe confundir BPA Tools con herramientas que fueron concebidas

para modelar e implementar procesos como la tan difundida herramienta libre de licencia Bizagi

(es un modelador de procesos BPMN de libre licencia).

Tampoco se debe confundir herramientas de diagramación como MS Visio con herramientas BPA.Con MS Visio se puede diagramar lo que se le ocurra al analista y los diagramas tienen una buena

calidad de impresión, pero no tiene ninguna otra funcionalidad que se necesitan para BPM

Governance como administración de versiones, de atributos, de usuarios, análisis de impacto,

animación y simulación, etc.

¿Cuáles herramientas se pueden clasificar como verdaderos BPA Tools? En el mercado podemos

encontrar herramientas como: ARIS, Idungu, IBM Coporate Modeler, y Troux entre otras.

La segunda y tercera capa llamada en inglés BPE (Business Process Execution) abarca tanto la

ejecución técnica de los procesos como la orquestación e integración de servicios en la capa de

SOA (Service Oriented Architecture) con aplicativos del back office.

Aquí nos encontramos con los tan conocidos BPMS como la BPM Suite de Oracle, Tibco,

AuraPortal, Intalio, Lombardy (IBM) entre muchos otros. Algunas de estas plataformas incluyen

una SOA Suite o motores de reglas, pero algunos proveedores sólo ofrecen entornos para

«Human Workflow» es decir orquestar procesos con usuarios, pero no orquestar servicios con el

back office (SOA). Si bien es cierto la mayoría de los BPMS incluyen modeladores de procesos,

pero al lector le tiene que quedar claro que estas componentes no reemplazan un entorno de BPA.

Los modeladores de procesos de los BPMS fueron diseñados para la especificación de un proceso

que se va a ejecutar técnicamente, razón por la cual son muy técnicos y no sirven como ambientes

analíticos o para gente de negocio. Muchos vendedores de BPMS declaran que su oferta

tecnológica es universal, que cubre todas las capas y funcionalidades, pero no lo son. Los BPMS

son entornos especializados para especialistas de TI, no para usuarios de negocio.

En resumen se puede concluir que en BPM existen muchas áreas de aplicación y cada área de

aplicación requiere de una herramienta especializada que apoye las funcionalidades requeridas.

Herramientas para BPM existen muchas y la pregunta esencial es ¿Con que finalidad fueron

diseñadas y que área o especialidad del BPM apoya?

3.5 La arquitectura del BPM y SOA

(HITPASS, 2013)

BPM como disciplina de gestión de procesos y como conjunto de herramientas tecnológicas que

apoya su análisis y operaciones.

SOA como arquitectura tecnológica que puede implementar o automatizar procesos aportando

flexibilidad y reutilización de infraestructura de TI existente y en el desarrollo de nuevas

componentes.


32/100

Pág. 32


PROCESOS DE NEGOCIO

En general la orientación al servicio proporciona la capacidad de interoperar con aplicaciones y

con agentes externos (Instituciones, clientes, proveedores, etc...) de forma flexible e invocarlos

mediante llamadas de servicios. SOA estandariza las funciones genéricas utilizadas por muchas

aplicaciones expresándolas en forma de servicios reutilizables. Uno de los objetivos principales del

concepto de SOA es que cualquier futuro cambio se realice de forma transparente, afectando sóloa las funciones y unidades afectadas. Si se logra esta capacidad aumenta la agilidad de negocio

de una organización. Por el momento se va a trabajar con esta definición para entender el modelo

estructural de BPM y SOA como una arquitectura integrada de la capa de negocio y de TI.

SOA como arquitectura tecnológica que puede implementar o automatizar procesos aportando

flexibilidad y reutilización de infraestructura de TI existente y en el desarrollo de nuevas

componentes

Arquitectura del BPM y SOA


En el contexto de BPM tenemos una capa que la vamos a llamar BPG (Business Process

Governance) que define la estrategia, una subcapa de diseño y control y una parte de la capa de

implementación, que la vamos a llamar BPE (Business Process Execution). La primera capa

define la estrategia y la redefine. Los estrategas están mirando el entorno y van adaptando los

productos y servicios de la empresa a la demanda del entorno. Si la adaptación es exitosa

hablamos de eficacia. En este sentido la eficacia no es otra cosa que adaptación exitosa al

entorno. La segunda capa define cómo lo hago (el qué) que es la etapa de diseño. El diseño tiene

como input dos aspectos que considerar, la estrategia y el análisis del comportamiento del

negocio. En el diseño, por sí o como parte del comportamiento del negocio se puede considerar la

simulación de procesos, es decir, ¿qué pasa si ..? (Ocurren cambios en las variables del entorno,como demanda, competencias, nuevos productos, etc.), de otra forma, simular cómo las variables


33/100

Pág. 33


PROCESOS DE NEGOCIO

que llevaron a redefinir la estrategia afectan la gestión de los procesos. Puede ocurrir que se

requiera de una adaptación de los sistemas reales o que se requiera de una adaptación de la

estrategia. La segunda capa BPE abarca la implementación tecnológica de los procesos

diseñados de acuerdo a la estrategia. Esta capa tiene una responsabilidad compartida. La capa de

negocio tiene la responsabilidad de entregar una especificación (modelo de procesosindependiente de la tecnología) automatizable (lógica de negocio) y la capa de tecnología tiene la

responsabilidad de llevarlo a un modelo técnicamente ejecutable (BPE). La figura 2.5 muestra la

relación entre las componentes de las capas en el marco estructural de la arquitectura descrita.

En la capa BPE nos encontramos con los famosos BPMS (Business Process Management Suite)

los cuales según el producto como lo indica la palabra «Suite» contienen varias componentes, el

más importante el motor de procesos (inglés: process engine) el cual ejecuta los modelos técnicos

de los procesos.

Las plataformas o suites más completas e integradas incluyen todas las componentes necesarias

para:

modelar el flujo de procesos que se va a ejecutar (Modelador técnico o Process Modeler),

crear formularios dependiente o independiente del modelador técnico (Interfaz de usuario),

ejecutar las instancias del modelo representado con un motor de procesos, configurar el cuadro

de mando (BAM: Business Activity Monitoring), editar y ejecutar reglas de negocio (BRMS:

Business Rules Management System),

invocar y orquestar servicios con aplicaciones a través de un bus de servicios (ESB: Enterprise

Service Bus)

(HITPASS, 2013)

Finalmente podemos incorporar a una arquitectura de BPM y SOA un ambiente analítico de

minería de procesos que le vamos a llamar «Process Mining and Controlling (PMC)». Process

Mining se puede concebir como subárea del Data Mining. El objetivo del Data Mining es extraer de

grandes fuentes de datos (data) conocimiento (mining). El objetivo específico del Process Mining

es descubrir el comportamiento de los procesos en la realidad y compararlo con los modelos. A

partir de este conocimiento se pueden crear nuevos modelos más asertivos y eficientes.

Generalmente se descargan los registros (inglés: log files) que dejan los motores de procesos y se

cargan en un sistema analítico en donde se aplican diferentes algoritmos de minería de procesos

para descubrir el comportamiento real de las instancias que se han procesado. Con el tiempo la

base histórica de los registros va creciendo lo que permite analizar tendencias, patrones que se

repiten, comparar diferentes prácticas geográficas, sucursales, usuarios y muchos otros factores

más. El término «controlling» en este contexto nos indica que los resultados analíticos son un input

para el análisis de control de gestión y que junto a los indicadores del BAM (Business Activity

Monitoring) sirven para descubrir porqué suceden desviaciones frente al comportamiento deseado

y de esta forma obtener información de cadenas de causa y efecto que permiten un nuevo análisis

de un rediseño tendiente a mejorar la calidad y el desempeño de los procesos.


34/100

Pág. 34


PROCESOS DE NEGOCIO

3.6 Reglas de Negocio

Las Reglas del Negocio o Conjunto de Reglas de Negocio (Business Rules, por su descripción en

inglés) describe las políticas, normas, operaciones, definiciones y restricciones presentes en una

organización y que son de vital importancia para alcanzar los objetivos misionales.

Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente

de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a

3.000".

(HITPASS, 2013)

«Una Regla de Negocio es una declaración que define o restringe algún aspecto del negocio;

intenta definir, controlar o influenciar el comportamiento y la estructura del negocio.»

Ejemplos de aplicación de reglas de negocio las encontramos en:

Reglas para la determinación del precio de un producto o servicio

Reglas para la aplicación de descuentos

Reglas para acceder a becas, subsidios, etc.

Factores de riesgo para la tarificación de planes de seguros

Si una política de negocio se puede expresar formalmente como una acción asociada a un

conjunto de condiciones, entonces se puede transformar en una regla de negocio automatizable.

En general toda regla de negocio sigue el esquema «condición»,«regla» y «acción».existen principalmente tres técnicas para expresar reglas de negocio de manera formal:

1. Lenguaje estructurado (pseudocódigo parecido a un lenguaje de programación, pero más

sencillo y restringido a la aplicación de reglas)

Ejemplo:

«Si el conductor es > a 40 años y < a 65 años

......... aplica descuento de 15 %

sino aplica tarifa BN5»

2. Árboles de decisión (Cada rama del árbol describe condiciones y al final de cada rama se

encuentra especificada la acción)

Ejemplo:


35/100

Pág. 35


PROCESOS DE NEGOCIO

3. Tablas de decisión (matrices que combinan condiciones, reglas y acciones, las condiciones de

entrada están en las primeras filas. Las columnas expresan las reglas de decisión, es decir las

entradas de acciones)

Ejemplo:

3.7 Gestión de Reglas de Negocio

(HITPASS, 2013)

Gestión de Reglas de Negocio (Business Rules Management) es una disciplina independiente y

como el nombre lo indica reglamenta las condiciones del negocio. En BPM la administración

centralizada e independiente de las reglas de negocio toma la importancia de un factor crítico de

éxito para el negocio.

Debido a que las reglas son uno de los componentes más versátiles de cualquier organización, es

indispensable para los expertos de negocio contar con las herramientas adecuadas para la

formulación, verificación, validación y gestión de las reglas. Producto de esto, desde hace variosaños se puede observar una fuerte tendencia en la gestión de forma centralizada y sistemática de

estas reglas a través de Sistemas de Gestión de Reglas de Negocio (Business Rules Management

System o BRMS).

Un BRMS es un sistema que permite a los usuarios determinar y escribir la lógica del negocio

mediante la formulación de reglas. En estos entornos los usuarios pueden definir, representar,

ejecutar, monitorear y actualizar las reglas de negocio, para que sean utilizadas por las

aplicaciones que realizan toma de decisiones automatizadas. De esta manera, se otorga mayor

control a los analistas sobre la lógica del negocio y mayor independencia del personal de TI, al

externalizar las reglas del código de las aplicaciones.

Algunas Suite de BPM (BPMS) traen motores de reglas incorporados, en otros casos existen

BRMS independientes que pueden ser invocados por sistemas de software. Cualesquiera que

sean las opciones por las que una organización se decida, lo importante es que no será necesario,

o mejor dicho no se recomienda, modelar las reglas en un flujo de proceso, sino sólo identificar

donde se utilizan e invocar éstas en las actividades que las requieran.


36/100

Pág. 36


PROCESOS DE NEGOCIO

3.8 Reglas de negocio y Reglas de ruteo

Muchos analistas de negocio cometen el error de especificar con ayuda de los elementos de la

notación de una técnica de modelamiento las reglas de negocio.

La notación no impide hacerlo, pero si las reglas son complejas llenan gran parte del diagrama y

los hacen ilegibles. Por otro lado, si las reglas representan el estado actual de ciertas políticas de

negocio, queda claro que se espera un cambio frecuente de éstas. Si las reglas están codificadas

en el flujo, cada cambio requiere pasar por un proceso de liberación de versiones en operaciones.

En cambio si las reglas se administran en un motor de reglas en forma independiente, se pueden

efectuar cambios de reglas en tiempo real sin afectar la lógica de control de los procesos

implementados. Las reglas de ruteo (en inglés routing: guiar, enrutar) definen como lo indica su

nombre la lógica de control de un flujo de procesos.

Para mostrar la diferencia entre reglas de negocio y reglas de ruteo se analizará a continuación un

ejemplo simple de un proceso del tipo «Aprobación de Orden de Compra (OC)» aplicando la regla

«revisión de credibilidad» en la notación BPMN (este caso fue descrito en [FreRueHit11]).

¿Bajo qué condiciones habrá que revisar la credibilidad del cliente, antes de confirmar la OC?

Vamos a suponer que la respuesta a esta pregunta va a depender del tipo de cliente y el volumen

del pedido, expresado en dólares. Entonces podemos definir como lo muestra la figura el primer

pasó en el proceso como una actividad de «Revisión de datos de la OC» y en esta actividad se va

a decidir, si es necesario hacer una evaluación de credibilidad o no.

Proceso orden de compra con revisión de credibilidad


En el siguiente paso tenemos que conocer las condiciones concretas para representar las reglas

de negocio:

Habrá que revisar la credibilidad del cliente, si el valor del pedido es mayor a $ 300.000.

Si se trata de un cliente nuevo, habrá que revisar la credibilidad del cliente a partir de los $ 50.000.

Si se trata de un cliente VIP, no es necesario revisar la credibilidad del cliente. Con esta

información podemos modelar la regla de negocio como lo muestra la figura.


37/100

Pág. 37


PROCESOS DE NEGOCIO

Proceso de orden de compra con regla de negocio modelada en BPMN


Supongamos ahora que cambian las políticas de negocio y habrá que incluir otras condiciones

adicionales.

Cada nueva condición implica un nuevo Gateway y flujos de secuencia.

El problema aumenta, si las condiciones están entrelazadas, como lo es nuestro caso de tipo de

cliente y valor del pedido.

El diagrama del proceso se vuelve rápidamente ilegible.

Si cambian las reglas frecuentemente habrá que estar adaptando el modelo a la nueva situación.

Si además tenemos que revisar la credibilidad del cliente en otros procesos, por ejemplo para

entregar una cotización, habrá que modelar y administrar estas condiciones en forma redundante.

Se puede concluir entonces, que modelar condiciones que representan «reglas de negocio» no es

una «buena práctica» en el modelamiento de procesos. Para evitar que esto suceda, el analistadebe aprender a diferenciar entre «reglas de negocio» y «reglas de ruteo». En el modelamiento de

procesos tenemos que distinguir claramente entre reglas de negocio y reglas de ruteo, siendo sólo

estas últimas las que se deben modelar. Para editar y mostrar reglas de negocio por lo general se

usan tablas de decisión. ¿De qué forma se tratan entonces reglas de negocio en un modelo de

procesos? Para estos efectos volvemos a nuestro ejemplo de la «Orden de Compra».

Traspasamos las condiciones y las reglas de nuestro ejemplo a una actividad del tipo “Regla de

Negocio

Texto Universitario NOTACION de PROCESOS

Documents

Transcript of Texto Universitario NOTACION de PROCESOS