Fundamentals_of_Business_Process_Management_1 en es docx (2)

Vista previa del material en texto

Introducción a la Gestión de Procesos de 
Negocio
Ab ovo usque ad mala.
Horacio (65 BCE-8 BCE)
Business Process Management (BPM) es el arte y la ciencia de la supervisión de
cómo el trabajo se lleva a cabo en una organización para asegurar resultados
consistentes y para aprovechar las oportunidades de mejora. En este contexto, el
término “mejora” puede tener diferentes significados dependiendo de los objetivos
de la organización. Los ejemplos típicos de los objetivos de mejora incluyen la
reducción de costes, la reducción de los tiempos de ejecución y la reducción de las
tasas de error. iniciativas de mejora pueden ser de una sola vez, sino también
mostrar un carácter más continuo. Es importante destacar que, BPM no se trata de
mejorar la forma en que se llevan a cabo actividades individuales. Más bien, se
trata de la gestión de cadenas enteras de eventos, actividades y decisiones que en
última instancia agregan valor a la organización y sus clientes. Estas “cadenas de
eventos, actividades y decisiones” se llaman procesos.
En este capítulo, introducimos algunos conceptos esenciales detrás de BPM.
Comenzaremos con una descripción de los procesos típicos que se encuentran en
las organizaciones contemporáneas. A continuación, se discuten los ingredientes
básicos de un proceso de negocio y proporcionamos una definición del concepto,
así como de BPM. Para colocar BPM en una perspectiva más amplia, que a
continuación ofrecemos una visión histórica de la disciplina BPM. Por último, se
discute cómo una iniciativa de BPM en una organización típicamente se desarrolla.
Esta discusión nos lleva a la definición de un ciclo de vida de BPM en torno al
cual se estructura el libro.
1.1 Procesos En todas partes
Cada organización -ya sea un organismo gubernamental, una organización sin
ánimo de lucro, o una empresa, tiene que gestionar una serie de procesos. Los
ejemplos típicos de los procesos que se pueden encontrar en la mayoría de las
organizaciones incluyen:
• Solicitar a efectivo: Este es un tipo de proceso realizado por un proveedor, que
comienza cuando un cliente envía un pedido para comprar un producto o un
servicio y termina cuando el producto o servicio en cuestión ha sido entregado
al cliente y la cliente haya realizado el pago correspondiente. Un proceso del
pedido al efectivo abarca actividades relacionadas con la compra de
verificación de la orden, el envío (en el caso de productos físicos), entrega,
facturación, recibos de pago y de acuse de recibo.
Dumas M. et al., Fundamentos de la Gestión de Procesos de Negocio, 1
DOI 10.1007 / 978-3-642-33143-5_1 , © Springer-Verlag Berlin Heidelberg 2013
http://dx.doi.org/10.1007/978-3-642-33143-5_1
http://dx.doi.org/10.1007/978-3-642-33143-5_1
2 1 Introducción a la Gestión de Procesos de 
Negocio
• Cita a la orden: Este tipo de proceso normalmente precede a un proceso de
pedido hasta el cobro. Se inicia desde el momento en que un proveedor recibe
una “Solicitud de Cotización” (RFQ) de un cliente y termina cuando el cliente
en cuestión coloca una orden de compra en base a la cotización recibida. El
proceso de pedido hasta el cobro toma el relevo a partir de ese momento. La
combinación de una orden de cita-a-y el correspondiente proceso de pedido-
tocash se llama un proceso de cotización-tocash.
• Procura pagar: Este tipo de proceso se inicia cuando alguien en una
organización determina que un determinado producto o servicio debe ser
comprado. Termina cuando el producto o servicio ha sido entregado y pagado.
Un proceso de aprovisionamiento hasta el pago incluye actividades tales como
la obtención de cotizaciones, se aprueba la compra, la selección de un
proveedor, la emisión de una orden de compra, la recepción de la mercancía (o
consumo del servicio), el control y el pago de la factura. Un proceso de
aprovisionamiento hasta el pago puede ser visto como el dual del proceso de
cotización a efectivo en el contexto de las interacciones de negocio a negocio.
Por cada proceso de aprovisionamiento hasta el pago hay un correspondiente
proceso de cotización a efectivo en el lado del proveedor.
• Cuestión a la resolución. Este tipo de proceso se inicia cuando un cliente
plantea un problema o asunto, como una queja relacionada con un defecto en un
producto o un problema encontrado al consumir un servicio. El proceso
continúa hasta que el cliente, el proveedor, o preferiblemente ambos, de acuerdo
en que el problema se ha resuelto. Una variante de este proceso se pueden
encontrar en las compañías de seguros que tienen que hacer frente a “las
reclamaciones de seguros”. Esta variante se llama a menudo reclamo-a-
resolución.
• Aplicación-a-aprobación. Este tipo de proceso se inicia cuando alguien solicita
un beneficio o privilegio y termina cuando el beneficio o privilegio en cuestión
se concede o se deniega. Este tipo de proceso es común en las agencias
gubernamentales, por ejemplo, cuando un ciudadano solicita un permiso de
construcción o cuando un empresario solicita un permiso para abrir un negocio
(por ejemplo, un restaurante). Otro proceso que entra en esta categoría es el
proceso de admisión en una universidad, que comienza cuando el estudiante
solicita la admisión en un grado. Sin embargo, otro ejemplo es el proceso para
la aprobación de vacaciones o licencia especial peticiones de una empresa.
Como ilustran los ejemplos anteriores, los procesos de negocio son lo que las
empresas hacen cada vez que entregan un servicio o un producto a los clientes. La
forma más procesos se diseñan y realizan afecta tanto a la “calidad de servicio”
que los clientes perciben y la eficiencia con que se prestan los servicios. Una
organización puede superar a otra organización que ofrece el mismo género de
servicio si tiene mejores procesos y los ejecuta mejor. Esto es cierto no sólo de los
procesos de cara al cliente, sino también de los procesos internos, tales como el
1.2Ingredientes de un proceso de negocio 3
proceso de aprovisionamiento hasta el pago, que se realiza con el propósito de
cumplir con una necesidad interna.
A medida que avanzamos este libro, utilizaremos un ejemplo concreto de un
proceso de aprovisionamiento hasta el pago para el alquiler de equipos de
construcción, tal como se describe a continuación.
Ejemplo 1.1 Procurar a pagar en el proceso de BuildIT.
BuildIT es una empresa constructora especializada en obras públicas (carreteras, puentes,
tuberías, túneles, ferrocarriles, etc.). Dentro BuildIT, a menudo sucede que los ingenieros
que trabajan en una obra de construcción (llamados ingenieros de sitio) necesitan una
pieza de equipo, tal como un camión, una excavadora, una excavadora, una bomba de
agua, etc. BuildIT posee muy poco equipo y en su lugar se alquila la mayor parte de sus
equipos a proveedores especializados.
El proceso de negocio existente para el alquiler de equipos es la siguiente. Cuando los
ingenieros de sitio necesitan alquilar una pieza de equipo, que se llenan en una forma
llamada “Alquiler de equipos demanda” y envíe esta solicitud por correo electrónico a
uno de los empleados en el depósito de la empresa. El empleado en el depósito recibe la
solicitud y, previa consulta a los catálogos de los proveedores de equipos, selecciona el
equipo más rentable que cumpla con la solicitud. A continuación, el empleado comprueba
la disponibilidad del equipo seleccionado con el proveedor a través del teléfono o correo
electrónico. A veces la opción seleccionada no está disponible y el empleado tiene que
seleccionar una pieza alternativa de equipo y comprobar su disponibilidad con el
proveedor correspondiente.
Una vez que el empleado ha encontrado una pieza adecuada de equipos disponibles para
alquiler, el empleado añade los detalles de los equipos seleccionados para la solicitud de
alquiler. Cada solicitud de alquiler tiene que ser aprobado porun ingeniero de obras, que
también trabaja en el depósito. En algunos casos, el ingeniero de obras rechaza la solicitud
de alquiler de equipos. Algunos rechazos conducen a la cancelación de la solicitud (sin
equipo es alquilado en absoluto). Otros rechazos se resuelven mediante la sustitución del
equipo seleccionado con otro equipo, tales como una pieza más barato de los equipos o
una pieza más apropiado de equipo para el trabajo. En este último caso, el empleado tiene
que realizar otra consulta de disponibilidad.
Cuando un ingeniero de obras aprueba una solicitud de alquiler, el empleado envía una
confirmación al proveedor. Esta confirmación incluye una orden de compra (PO) para el
alquiler de los equipos. El PO es producida por el sistema de información financiera de
BuildIT utilizando la información introducida por el empleado. El secretario también
registra la participación del equipo en una hoja de cálculo que se mantiene con el
propósito de rastrear todos los alquileres de equipo.
Mientras tanto, el ingeniero de la obra puede decidir que el equipo ya no es necesaria. En
este caso, el ingeniero le pide al empleado que cancelar la solicitud de alquilar el equipo.
A su debido tiempo, el proveedor suministra el equipo alquilado al sitio de construcción.
El ingeniero de la obra y luego inspecciona el equipo. Si todo está en orden, el ingeniero
acepta el compromiso y el equipo se pone en uso. En algunos casos, el equipo se envía de
nuevo, ya que no cumple con los requisitos de la ingeniero de la obra. En este caso, el
ingeniero de la obra tiene que empezar el proceso de alquiler de nuevo.
Cuando expira el período de alquiler, el proveedor viene a recoger el equipo. A veces, el
ingeniero de la obra pide una extensión del período de alquiler poniéndose en contacto
con el proveedor a través del correo electrónico o por teléfono 1-2 días antes de la
recogida. El proveedor puede aceptar o rechazar esta solicitud. Unos días después de que
el equipo se recogió, proveedor del equipo envía una factura al empleado por correo
4 1 Introducción a la Gestión de Procesos de 
Negocio
electrónico. En este punto, el empleado solicita al ingeniero de la obra para confirmar que
el equipo fue de hecho alquilado para el período indicado en la factura. El secretario
también comprueba si el precio de alquiler indicado en la factura están en conformidad
con las de la PO. Después de estas comprobaciones, el secretario envía la factura al
departamento financiero y el departamento de finanzas finalmente paga la factura.
1.2 Ingredientes de un proceso de negocio
El ejemplo anterior muestra que un proceso de negocio abarca una serie de eventos
y actividades. Eventos corresponden a las cosas que suceden de forma atómica, lo
que significa que no tienen una duración. La llegada de un equipo en un sitio de
construcción es un evento. Este evento puede desencadenar la ejecución de una
serie de actividades. Por ejemplo, cuando un equipo llega, el ingeniero de la obra
lo inspecciona. Esta inspección es una actividad, en el sentido de que se necesita
tiempo.
Cuando una actividad es bastante simple y puede ser visto como una sola
unidad de trabajo, lo llamamos una tarea. Por ejemplo, si la inspección que realiza
el ingeniero sitio es bastante simple: por ejemplo, acaba de comprobar que el
equipo recibido se corresponde con lo que se ordenó-podemos decir que la
inspección del equipo es una tarea. Si por el contrario el equipo de inspección
requiere muchos pasos, tales como comprobar que el equipo cumple con la
especificación incluida en la orden de compra, comprobar que el equipo está en
buen estado de funcionamiento, y comprobar que el equipo viene con todos los
accesorios necesarios y la seguridad dispositivos- lo llamaremos una actividad.
Además de los eventos y actividades, un proceso típico consiste en puntos de
decisión, es decir, momentos cuando se toma una decisión que afecta a la forma en
que se ejecuta el proceso. Por ejemplo, como resultado de la inspección, el
ingeniero de la obra puede decidir que el equipo debe ser devuelto o que el equipo
debe ser aceptado. Esta decisión afecta a lo que sucede más adelante en el proceso.
Un proceso también implica una serie de actores (los actores humanos,
organizaciones o sistemas de software que actúan en nombre de los actores
humanos u organizaciones), los objetos físicos (equipos, materiales, productos,
documentos de papel) y objetos inmateriales (documentos electrónicos y registros
electrónicos). Por ejemplo, el proceso de alquiler de equipos implica tres tipos de
actor humano (ventas, ingeniero de la obra y el ingeniero de Obras) y dos tipos de
actores de la organización (proveedores Buildit y equipamiento). El proceso
también implica objetos físicos (el equipo alquilado), documentos electrónicos
(solicitudes de alquiler de equipos, las OP, facturas) y registros electrónicos
(registros de compromiso equipos mantenidos en una hoja de cálculo).
Por último, la ejecución de un proceso conduce a uno o varios resultados. Por
ejemplo, el proceso de alquiler de equipos conduce a un equipo que está siendo
utilizado por BuildIT, así como un pago que se realizan para el proveedor del
equipo. Idealmente, un resultado debe ofrecer valor a los actores que participan en
1.2Ingredientes de un proceso de negocio 5
el proceso, que en este ejemplo son BuildIT y el proveedor. En algunos casos, este
valor no se alcanza, o se alcanza sólo parcialmente. Por ejemplo, cuando se
devuelve un equipo, sin valor se gana, ni por BuildIT ni por el proveedor. Esto
corresponde a un resultado negativo, en lugar de un resultado positivo que
proporciona valor a los actores involucrados.
Entre los actores que participan en un proceso, el que consume la salida del
proceso juega un papel especial, a saber, el papel del cliente. Por ejemplo, en el
proceso anterior, el cliente es el ingeniero de la obra, ya que es el ingeniero de la
obra que pone el equipo alquilado para su uso. Es también el ingeniero de la obra
que muy probablemente no estarán satisfechos si el resultado del proceso no es
satisfactorio (resultado negativo) o si se retrasa la ejecución del proceso. En este
ejemplo, el cliente es interno a BuildIT, lo que significa que el cliente es un
empleado de la organización. En otros procesos, tales como un proceso del pedido
al dinero en efectivo, el cliente es externo a la organización. A veces, hay varios
clientes en un proceso. Por ejemplo, en un proceso para la venta de una casa, hay
un comprador, un vendedor, un agente de bienes raíces, uno o varios proveedores
de hipotecas, y al menos un notario. El resultado del proceso es una operación de
venta. Este resultado proporciona un valor tanto para el comprador que queda con
la casa y para el vendedor que monetiza la casa. Por lo tanto, el comprador y el
vendedor pueden ser vistos como clientes en este proceso, mientras que los actores
restantes proporcionan diversos servicios.
ejercicio 1.1 Considere el siguiente proceso para la admisión de estudiantes
graduados en una universidad.
Con el fin de solicitar la admisión, los estudiantes de primer rellenar un formulario en
línea. Las aplicaciones en línea se registran en un sistema de información a la que todos
los miembros del personal que participan en el proceso de admisión tienen acceso.
Después de que el estudiante haya enviado el formulario en línea, se genera un documento
PDF y se solicita al estudiante para descargarlo, firmarlo y enviarlo por correo junto con
la documentación requerida, que incluyen:
• copias certificadas de grado anterior y certificados de estudios.
• Los resultados del examen de idioma Inglés.
• Curriculum vitae.
Cuando estos documentos son recibidos por la oficina de admisión, un oficial comprueba
la integridad de los documentos. Si cualquier documentono se encuentra, un correo
electrónico se envía al estudiante. El estudiante tiene que enviar los documentos que
faltan por correo. Suponiendo que la solicitud está completa, la oficina de admisiones
envía las copias certificadas de los grados a una agencia de reconocimiento académico,
que comprueba los grados y da una evaluación de su validez y equivalencia en términos
de estándares de educación locales. Esta agencia requiere que todos los documentos serán
enviados a por correo, y todos los documentos deben ser copias certificadas de los
originales. La agencia envía de nuevo su evaluación a la universidad por correo también.
Suponiendo que el grado de verificación tiene éxito, los resultados de las pruebas de
idioma Inglés se revisan en línea por un funcionario de la oficina de admisión.
6 1 Introducción a la Gestión de Procesos de 
Negocio
Una vez que han sido validados todos los documentos de un estudiante dado, la oficina de
admisión envía estos documentos por correo interno al comité académico correspondiente
responsable de decidir si ofrecer la admisión o no. El comité tome su decisión basada en
los certificados de estudios y el CV. El comité se reúne una vez cada 2 a 3 semanas y
examina todas las aplicaciones que están listos para la evaluación académica en el
momento de la reunión. Al final de la reunión del comité, el presidente del comité notifica
a la oficina de admisión de los resultados de la selección. Esta notificación incluye una
lista de candidatos admitidos y rechazados. Unos días más tarde, la oficina de admisión
notifica el resultado de cada candidato a través del correo electrónico. Además, los
candidatos seleccionados reciben una carta de confirmación por correo.
Con respecto al proceso anterior, considere las siguientes preguntas:
1. Quiénes son los actores en este proceso?
2. ¿Qué actores pueden ser considerados como el cliente (o clientes) en este
proceso?
3. ¿Qué valor tiene el proceso de entregar a su cliente (s)?
4. ¿Cuáles son los posibles resultados de este proceso?
En vista de lo anterior, definimos un proceso de negocio como una colección de
eventos interrelacionados, actividades y puntos de decisión que implican una serie
de actores y objetos, y que conducen en conjunto a un resultado que es de valor
para al menos un cliente. Figura1.1 representa los ingredientes de esta definición y
sus relaciones.
Armado con esta definición de un proceso de negocio, definimos BPM como
un conjunto de métodos, técnicas y herramientas para descubrir, analizar,
rediseñar, ejecutar y monitorear los procesos de negocio. Esta definición refleja el
hecho de que los procesos de negocio son el punto focal de BPM, y también el
hecho de que BPM implica diferentes fases y actividades del ciclo de vida de los
procesos de negocio, como veremos más adelante en este capítulo.
Otras disciplinas además de acuerdo con los procesos de negocio BPM en
diferentes formas como se explica en el cuadro “Disciplinas Relacionadas”. Una
de las características comúnmente asociadas a BPM es su énfasis en el uso de
modelos de procesos en todo el ciclo de vida de los procesos de negocio. En
consecuencia, los modelos de proceso están presentes en una forma u an-
1.2Ingredientes de un proceso de negocio 7
otra en casi todos los capítulos de este libro y dos capítulos están dedicados al
proceso de modelado.
En cualquier caso, si bien es útil saber que múltiples disciplinas comparten el
objetivo de mejorar los procesos de negocio, que debe seguir siendo pragmático y
no lanzó una disciplina contra el otro como si fueran competidores. En su lugar,
debemos abrazar cualquier técnica que nos ayuda a mejorar los procesos de
negocio, ya sea o no esta técnica se percibe como parte de la disciplina BPM (en
sentido estricto) e independientemente de si o no la técnica en cuestión utiliza
modelos de procesos.
DISCIPLINAS RELACIONADAS
BPM es de ninguna manera la única disciplina que se ocupa de la mejora del
rendimiento operativo de las organizaciones. A continuación, presentamos
brevemente algunas disciplinas relacionadas e identificar las relaciones
clave y las diferencias entre estas disciplinas y BPM.
Total Quality Management (TQM) es un enfoque que tanto históricamente
precedido e inspirado BPM. El foco de la ACT es en la mejora continua y
el mantenimiento de la calidad de los productos, y por extensión también
de los servicios. De esta manera, es similar a la de BPM en su énfasis en la
necesidad de esfuerzos de mejora continua. Pero donde la ACT pone el
énfasis en los productos y servicios propios, la vista detrás de BPM es que
la calidad de los productos y servicios puede lograrse mejor, centrándose en
la mejora de los procesos que crean estos productos y servicios. Debe
admitirse que este punto de vista es algo controvertido, como TQM adeptos
contemporáneos preferirían ver BPM como una de las diversas prácticas
8 1 Introducción a la Gestión de Procesos de 
Negocio
que se encuentran comúnmente dentro de un programa TQM. No es tanto
una distinción teórica sino una empir-
uno ica es que las aplicaciones de la ACT se encuentran principalmente en
los dominios de los productos de fabricación en donde son tangibles,
mientras BPM es más orientado a organizaciones de servicio.
Jefe de operaciones es un campo de que se trate con el manejo de las
funciones físicas y técnicas de una empresa u organización, en particular
las relativas a la producción y fabricación. La teoría de probabilidades,
teoría de colas, el análisis de decisión, el modelado matemático y
simulación son todas las técnicas importantes para la optimización de la
eficiencia de las operaciones desde esta perspectiva. Como se expondrá en
el Cap.7, Dichas técnicas también son útiles en el contexto de las
iniciativas de BPM. Lo que es bastante diferente entre la gestión de
operaciones y BPM es que la gestión de las operaciones es generalmente
involucrados en el control de un proceso existente sin necesidad de
cambiarlo, mientras que BPM es a menudo preocupado en hacer cambios
en un proceso existente con el fin de mejorarlo.
Apoyarse es una disciplina de gestión que se origina en la industria
manufacturera, en particular, la filosofía de ingeniería de Toyota. Uno de
los principales principios de Lean es la eliminación de los residuos, es
decir, las actividades que no agregan valor para el cliente como veremos en
el Cap.6. La orientación al cliente de la magra es similar a la de BPM y
muchos de los principios detrás de Lean han sido absorbidos por BPM. En
ese sentido, BPM puede ser visto como una disciplina más amplio que el
Lean. Otra diferencia es que BPM pone más énfasis en el uso de la
tecnología de la información como herramienta para mejorar los procesos
de negocio y para hacerlos más consistente y repetible.
seis Sigma es otro conjunto de prácticas que se originan en la fabricación,
en particular de las prácticas de ingeniería y producción en Motorola. La
principal característica de Seis Sigma es su enfoque en la reducción al
mínimo de los defectos (errores). Seis Sigma pone un fuerte énfasis en la
medición de la salida de los procesos o actividades, sobre todo en términos
de calidad. Seis Sigma anima a los directivos para comparar
sistemáticamente los efectos de las iniciativas de mejora en las salidas. En
la práctica, Seis Sigma no necesariamente se aplica solo, sino en
conjunción con otros enfoques. En particular, un enfoque popular es
mezclar la filosofía de magro con las técnicas de Seis Sigma, lo que lleva a
un enfoque conocido como Lean Six Sigma. Hoy en día, muchas de las
técnicas de Seis Sigma se aplican comúnmente en BPM también. En el
Cap.6, Vamos a introducir algunas técnicas de análisis de procesos de
negocio que son compartidos por Seis Sigma y BPM.
En resumen, podemos decir que el BPM heredade la filosofía de mejora
1.2Ingredientes de un proceso de negocio 9
continua de la GCT, abraza los principios y técnicas de gestión de
operaciones, Lean y Seis Sigma, y los combina con las capacidades que
ofrece la tecnología moderna de la información, con el fin de alinear de
manera óptima los procesos de negocio con los objetivos de desempeño de
una organización.
Fig. 1.2 Como el proceso se trasladó fuera de foco a través de las edades
1.3 Orígenes e historia de BPM
Para entender mejor por qué las organizaciones se involucran en BPM y cuáles son
los beneficios que aporta a ellos, vale la pena mirar las razones por las BPM ha
surgido y evolucionado con el tiempo. A continuación nos fijamos en los
conductores de la disciplina BPM desde una perspectiva histórica. Comenzamos
con el surgimiento de las organizaciones funcionales, continúe con la introducción
del proceso de pensamiento, hacia las innovaciones y los fracasos del proceso de
reingeniería de negocios. Esta discusión proporciona la base para la definición del
ciclo de vida de BPM después.
1.3.1 La organización funcional
La idea clave de BPM es centrarse en los procesos en la organización y gestión del
trabajo en una organización. Esta idea puede parecer intuitivo y sencillo a primera
vista. De hecho, si uno tiene que ver con la calidad de un producto o servicio en
particular y la velocidad de su entrega a un cliente, por qué no considerar los
mismos pasos que son necesarios para producirlo? A pesar de que intuitiva, que
dio varios pasos evolutivos antes de que esta idea se convirtió en parte integral de
las estructuras de trabajo de las organizaciones. Figura1.2 proporciona una visión
general de algunos acontecimientos históricos relevantes de BPM.
10 1 Introducción a la Gestión de Procesos de 
Negocio
En tiempos prehistóricos, los seres humanos en su mayoría apoyaron a sí
mismos o los pequeños grupos que vivían en al producir sus propios alimentos,
herramientas y otros artículos. En tales sociedades primitivas, los consumidores y
productores de un determinado bien a menudo eran las mismas personas. En
términos industriales, las personas llevan a cabo sus propios procesos de
producción. Como resultado, tenían conocimiento de cómo producir muchas cosas
diferentes. En otras palabras, eran generalistas.
En la antigüedad, en paralelo con el surgimiento de las ciudades y los estados
de ciudad, esta estructura de trabajo basada en generalistas comenzó a evolucionar
hacia lo que puede ser caracterizado como un nivel intermedio de la
especialización. La gente empezó a especializarse en el arte de la entrega
1.3 Orígenes e historia de BPM 11
un tipo específico de productos, tales como la cerámica, o la prestación de un
determinado tipo de servicios, como alojamiento para los viajeros. Este desarrollo
generalizado hacia un mayor nivel de especialización de la fuerza de trabajo
culminó en los gremios de los artesanos durante la Edad Media. Estos gremios
eran esencialmente grupos de comerciantes y artesanos que se ocupan de la misma
actividad económica, tales como barberos, zapateros, albañiles, cirujanos, y
escultores. Los trabajadores de este tiempo tendrían una buena comprensión de
todo un proceso que estaban involucrados en, pero no tanto sobre los procesos que
producen los bienes o servicios que obtienen de otros.
Este alto grado de especialización del obrero medieval desplaza hacia la una
forma de especialización pura durante la segunda revolución industrial, entre la
segunda mitad del siglo 19 y la Primera Guerra Mundial. Un nombre que está
inseparablemente ligada a ella es la de Frederick W. Taylor (1856-1915), quien
propuso una serie de principios conocidos como la gestión científica. Un elemento
clave en el enfoque de Taylor era una forma extrema de la división del trabajo. Al
estudiar meticulosamente actividades laborales, como los distintos pasos que se
requieren para manejar arrabio en las fábricas de acero, Taylor desarrolló
instrucciones de trabajo muy específicas para los trabajadores. Sólo los
trabajadores estarían involucrados con la realización de uno de los muchos pasos
en el proceso de producción. No sólo en la industria, sino también en la
configuración administrativa, como las organizaciones gubernamentales, el
concepto de división del trabajo se convirtió en la forma más dominante de
organización del trabajo. El resultado de este desarrollo es que los trabajadores se
convirtieron en especialistas puros, que se ocuparía de una única parte de un
proceso de negocio.
Un efecto secundario de las ideas de Taylor y sus contemporáneos fue la
aparición de una nueva clase por completo de profesionales, la de los gerentes.
Después de todo, alguien tenía que supervisar la productividad de los grupos de
trabajadores afectados con la misma parte de un proceso de producción. Los
gerentes eran responsables de la fijación abajo las metas de productividad para los
trabajadores individuales y asegurarse de que se cumple con dichos objetivos. En
contraste con los maestros de los gremios medievales, que solo pudo alcanzar un
rango tal sobre la base de una obra de arte producida por ellos mismos, los
gerentes no son necesariamente expertos en llevar a cabo el trabajo que
supervisan. Su interés principal es optimizar la forma de un trabajo se hace con los
recursos bajo su supervisión.
Después de la aparición de los gestores, organizaciones quedaron estructurados
según los principios de la división del trabajo. Una próxima y evidente desafío
surgió entonces: ¿Cómo diferenciar entre las responsabilidades de todos estos
gestores? La solución fue crear unidades funcionales en las que las personas con
un enfoque similar en la parte del proceso de producción se agrupan juntos. Estas
unidades fueron supervisados por los administradores con diferentes
responsabilidades. Por otra parte, las unidades y sus gerentes fueron estructuradas
jerárquicamente: por ejemplo, los grupos están bajo departamentos, los
12 1 Introducción a la Gestión de Procesos de 
Negocio
departamentos están bajo unidades de negocio, etc. Lo que vemos aquí es la raíz
de las unidades funcionales que son familiares hoy en día cuando pensamos en las
organizaciones: compras, ventas, almacenes, finanzas, marketing, gestión de
recursos humanos, etc.
La organización funcional que surgió de la mentalidad de la segunda revolución
industrial, dominaba el paisaje corporativo para la mayor parte de los siglos 19 y
20. Hacia el final de la década de 1980, sin embargo, las grandes compañías
americanas como IBM, Ford y Bell Atlantic (ahora Verizon) se dieron cuenta de
que su énfasis en la optimización funcional estaba creando ineficiencias en sus
operaciones que estaban afectando su competitividad. proyectos costosos que
introdujeron
Fig. 1.3 Proceso de compra en Ford en la etapa inicial
nuevos sistemas de TI o el trabajo reorganizado dentro de un departamento
funcional con el objetivo de mejorar su eficiencia, no fueron particularmente
ayudando a estas empresas a ser más competitivas. Parecía como si los clientes se
mantuvo ajeno a estos esfuerzos y continuaron tomando su negocio en otros
lugares, por ejemplo a los competidores japoneses.
1.3.2 El nacimiento del pensamiento Proceso
Uno de los eventos de vanguardia para el desarrollo de BPM fue adquisición de
una participación financiera grande en Mazda durante la década de 1980 de Ford.
Durante la visita a las plantas de Mazda, una de las cosas que los ejecutivos de
Ford observantes notamos fue que las unidades dentro de Mazda parecía faltarle
considerablemente en comparación con las unidades comparables dentro de Ford,
sin embargo, utilizar normalmente. Un estudio de caso famoso que ilustra este
1.3 Orígenes e historia de BPM 13
fenómeno,narró por primera vez por Michael Hammer [26] Y posteriormente
analizada por muchos otros, trata sobre el proceso de compra de Ford. Figura1.3
representa la forma de compra se realiza dentro de Ford en el momento.
Cada compra que haría necesaria Ford que pasar por el departamento de
compras. En decidir que una determinada cantidad de productos que de hecho
tenía que ser comprado, este departamento envió una orden al proveedor en
cuestión. También enviaría una copia de ese fin de cuentas a pagar. Cuando el
proveedor de seguimiento, los productos pedidos se entregan en el almacén de
recepción de Ford. Junto con la mercancía llegó un aviso de envío, que se
transmite a las cuentas por pagar. El vendedor también enviaría una factura a las
cuentas por pagar directamente.
En este contexto, se hace evidente que la tarea principal de las cuentas por
pagar era para comprobar la coherencia entre los tres documentos diferentes
(compra copia fin, aviso de envío, factura), donde cada documento consta de
aproximadamente 14 elementos de datos (tipo de producto, la cantidad, precio,
etc.). No es sorprendente que varios tipos de discrepancia se descubrieron todos
los días y el ordenamiento de estas discrepancias ocupados
Fig. 1.4 Proceso de compra en Ford después de rediseño
varios cientos de personas dentro de Ford. Por el contrario, en el Mazda sólo cinco
personas trabajaron en este departamento, mientras que Mazda no era 100 veces
más pequeño que Ford en todas las disposiciones necesarias. Fundamentalmente,
el problema es que Ford fue la detección y resolución de problemas (en este caso
discrepancias) uno por uno, mientras que Mazda lugar estaba evitando las
discrepancias en el primer lugar. Después de una comparación más detallada con
Mazda, Ford lleva a cabo varios cambios en su propio proceso de compra, lo que
lleva al proceso rediseñado se representa en la Fig.1.4.
En primer lugar, una base de datos central fue desarrollado para almacenar
información sobre las compras. Esta base de datos fue utilizado por el
14 1 Introducción a la Gestión de Procesos de 
Negocio
departamento de compras para almacenar toda la información sobre las órdenes de
compra. Esta base de datos reemplaza una de las corrientes originales en papel. En
segundo lugar, los nuevos terminales de ordenador se instalaron en el
departamento de almacén que daba acceso directo a la base de datos. Cuando
llegaron los bienes, el personal del almacén podría comprobar inmediatamente si
la entrega realidad coincidía con lo que se compró originalmente. Si este no era el
caso, las mercancías fueron simplemente no aceptadas: esto puso la
responsabilidad en el distribuidor para asegurarse de que lo que fue entregado fue
lo solicitado y nada más. En los casos donde no se encontró una coincidencia entre
los bienes entregados y la orden de compra registrada, se registró la aceptación de
la mercancía. Asi que, el único que queda por hacer por cuentas por pagar fue a
pagar lo acordado en la orden de compra original. A raíz de esta nueva puesta a
punto, Ford logró reducir su fuerza de trabajo en cuentas por pagar de
aproximadamente 500 personas a 120 personas (una reducción del 76%).
ejercicio 1.2 Considere el proceso de compra en Ford.
1. Quiénes son los actores en este proceso?
2. ¿Qué actores pueden ser considerados como el cliente (o clientes) en este
proceso?
3. ¿Qué valor tiene el proceso de entregar a su cliente (s)?
4. ¿Cuáles son los posibles resultados de este proceso?
Un elemento clave en este estudio de caso es que un problema de rendimiento
problemática (es decir, una cantidad excesiva de tiempo y recursos gastados en
comprobación de documentos en las cuentas por pagar) se acercó al considerar
todo un proceso. En este caso, el departamento de cuentas por pagar juega un
papel importante en el proceso de compra en general, pero el proceso también
implica tareas por parte del personal en el departamento de compras, el almacén, y
por el vendedor. A pesar de estas barreras, los cambios se realizan en todo el
proceso y estos cambios son en varios frentes: Incluyen cambios informativos
(Intercambio de Información), los cambios tecnológicos (la base de datos,
terminales), y los cambios estructurales (cheques, políticas).
Esta característica vista sobre la forma de observar el desempeño de la
organización fue presentada en un artículo seminal de Tom Davenport y James
Short [11]. En este artículo, los autores instaron a los gerentes a mirar a procesos
completos cuando se trata de mejorar el funcionamiento de su negocio, en lugar de
ver una función de trabajo o negocio en particular. Varios casos se discutieron
donde de hecho este enfoque particular, demostró ser un éxito. En el mismo
documento, el papel importante de la misma se enfatizó como un facilitador para
llegar a un rediseño de los procesos de negocio existentes. De hecho, cuando se
mira en el ejemplo de Ford-Mazda parece difícil cambiar el procedimiento
tradicional, sin las cualidades específicas de TI, que en general permite el acceso a
la información de una manera que es independiente del tiempo y del lugar.
1.3 Orígenes e historia de BPM 15
1.3.3 La subida y la caída de BPR
El trabajo de Davenport y Short, así como la de los demás, provocó la aparición y
la adopción generalizada de un concepto de gestión que se conoce como Rediseño
de Procesos de Negocio o Business Process Re-ingeniería, a menudo abreviado
convenientemente a BPR. Numerosos libros blancos, artículos y libros sobre el
tema aparecieron a lo largo de la década de 1990 y las compañías de todo el
mundo se reunieron los equipos de los nuevos procesos operativos para revisar y
rediseñar sus procesos.
El entusiasmo por BPR se desvaneció hacia abajo, sin embargo, a finales del
1990. Muchas empresas terminan sus proyectos BPR y dejaron de apoyar nuevas
iniciativas BPR. ¿Qué ha pasado? En un análisis retrospectivo, un número de
factores se pueden distinguir:
1. el mal uso del concepto: En algunas organizaciones, sobre todo proyecto de
programa de cambio o mejora fue etiquetado BPR incluso cuando los procesos
de negocio no eran el núcleo de estos proyectos. Durante la década de 1990,
muchas empresas iniciaron reducciones considerables de su fuerza de trabajo
(reducción) que, desde que se empaquetan a menudo como proyectos de
rediseño de procesos, desencadenó una fuerte resentimiento entre el personal
operativo y mandos medios contra la BPR. Después de todo, no era del todo
claro que la mejora operativa fue realmente impulsando este tipo de iniciativas.
2. El exceso de radicalismo: Algunos defensores tempranos de BPR, incluyendo a
Michael Hammer, enfatizaron desde el principio que el nuevo diseño tenía que
ser radical, en el sentido de que un nuevo diseño para un proceso de negocio
tuvo que revisar la forma en que el proceso se organizó inicialmente. Un
indicio revelador es uno de los primeros trabajos de Michael Hammer
sobre este tema que llevaba el subtítulo: “No automatizar, Obliterate”. Mientras
que un enfoque radical puede justificarse en algunas situaciones, es evidente
que muchas otras situaciones requieren un enfoque mucho más gradual
(incremental).
3. Apoyar la inmadurez: Incluso en los proyectos que estaban centrada en el
proceso de la Start y adoptó un enfoque más gradual a la mejora de los
procesos de negocio de que se trate, la gente se encontró con el problema de
que las herramientas y tecnologías necesarias para implementar un nuevo
diseño de este tipo no estaban disponibles o suficientemente potente . Una
cuestión particular, centrado en torno al hecho de que tanto la lógica de cómo
los procesos tuvieron que desplegarse se modificable en las aplicaciones de
soporte de TI de la época. Es comprensible que la gente vioaumentar su
frustración cuando observaron que sus esfuerzos en el rediseño de un proceso
se vieron frustrados por una infraestructura rígida.
Posteriormente, dos eventos clave revivieron algunas de las ideas detrás de
BPR y sentó las bases para el surgimiento de BPM. En primer lugar, los estudios
empíricos parecen mostrar que las organizaciones que estaban orientados al
16 1 Introducción a la Gestión de Procesos de 
Negocio
proceso, es decir, organizaciones que buscaban mejorar procesos como base para
la obtención de la eficiencia y la satisfacción de sus clientes, de hecho lo hicieron
mejor que las organizaciones no orientados a procesos. Mientras que los estudios
de caso convincente previstos del gurú inicial BPR, como el de Ford-Mazda, no
estaba claro para muchos si se trataba de excepción y no la regla. En uno de los
primeros estudios empíricos sobre este tema, Kevin McCormack [49] Investigó
una muestra de 100 empresas de fabricación de Estados Unidos y encontraron que
las organizaciones processoriented mostraron un mejor rendimiento general,
tendían a tener un mejor espíritu de cuerpo en el lugar de trabajo, y sufrieron
menos conflictos inter-funcionales. Los estudios de seguimiento confirmaron esta
imagen, dando renovada credibilidad al proceso de pensamiento.
Un segundo acontecimiento importante fue de naturaleza tecnológica. Los
diferentes tipos de sistema se puso de manifiesto, sobre todo Enterprise Resource
Planning (ERP) y sistemas de gestión de flujo de trabajo (WfMSs). Los sistemas
ERP son esencialmente los sistemas que almacenan todos los datos relacionados
con las operaciones comerciales de una empresa de una manera consistente, de
manera que todas las partes interesadas que necesitan acceso a estos datos se
pueden obtener tal acceso. Esta idea de una única base de datos compartida y
centralizada permite la optimización del uso de la información y el intercambio de
información, lo cual es un factor clave de la mejora de procesos (cf. cap.8).1
WfMSs por el contrario son sistemas que distribuyen el trabajo a diferentes actores
en una empresa sobre la base de modelos de procesos. Al hacerlo, un WFMS
hacen que sea más fácil de implementar cambios en los procesos de negocio (por
ejemplo, para cambiar el orden en que se realizan los pasos) debido a que los
cambios realizados en el modelo de proceso se pueden poner en ejecución con
relativa facilidad, en comparación con la situación en la que reglas para la
ejecución del proceso están codificadas dentro de los sistemas de software
complejos y enterrado dentro de decenas de miles de líneas de código. Además, un
WFMS apoya muy de cerca la idea de trabajar de una manera centrada en el
proceso.
1En realidad, los sistemas ERP son mucho más que una base de datos compartida. También
incorporan numerosos módulos para apoyar las funciones típicas de una organización, tales
como contabilidad, gestión de inventarios, planificación de la producción, logística, etc. Sin
embargo, desde la perspectiva de la mejora de procesos, el concepto base de datos compartida
detrás de los sistemas ERP es un elemento importante.
1.3 Orígenes e historia de BPM 17
Fig. 1.5 funciones de trabajo de un gerente responsable de un proceso (también conocido
como propietario del proceso)
Originalmente, WfMSs se ocupa principalmente con el trabajo de enrutamiento
entre los actores humanos. Más tarde, estos sistemas fueron poco a poco extendido
con módulos de vigilar y analizar la ejecución de procesos de negocio. Al mismo
tiempo, la aparición de servicios Web hace que sea más fácil para conectar un
WFMS con otros sistemas, en particular los sistemas ERP. Como WfMSs se hizo
más sofisticada y mejor integrado con otros sistemas de la empresa, se hicieron
conocidos como Sistemas de Gestión de Procesos de Negocio (BPMS). La
funcionalidad de BPMS y su papel en la automatización de procesos de negocio
será discutido en el capítulo.9.
La visión histórica anterior sugiere que BPM es un renacimiento de nuevos
procesos operativos, como de hecho BPM adopta la visión centrada en procesos en
las organizaciones. Cierta precaución se debe aunque cuando BPR y BPM se están
equiparados. La relación se comprende mucho mejor sobre la base de la Fig.1.5.
Esta figura muestra que un gerente que es responsable de una empresa proceso
también se llama el proceso por el propietario se ocupa de la planificación y la
organización del proceso, por un lado y el seguimiento del proceso en el otro. La
figura nos permite explicar las diferencias de alcance entre BPR y BPM. Si bien
ambos enfoques tienen el proceso de negocio como punto de partida, BPR se
refiere principalmente a la planificación y la organización del proceso. Por el
contrario, BPM proporciona conceptos, métodos, técnicas y herramientas que
cubren todos los aspectos de la gestión de un proceso de planificar, organizar,
supervisar, controlar, así como su ejecución real. En otras palabras, BPR debe ser
visto como un subconjunto de las técnicas que se pueden utilizar en el contexto de
BPM.
18 1 Introducción a la Gestión de Procesos de 
Negocio
Este análisis destaca que la BPM abarca todo el ciclo de vida de los procesos de
negocio. En consecuencia, la siguiente sección proporciona una visión general de
los conceptos, métodos, técnicas y herramientas que componen la disciplina BPM
a través de la lente del ciclo de vida de BPM. Esta lente proporciona una visión
estructurada de cómo un determinado proceso puede ser controlado.
1.4El ciclo de vida de BPM 19
1.4 El ciclo de vida de BPM
En general, la primera pregunta que un equipo de embarcarse en una iniciativa
BPM tiene que aclarar es “lo que los procesos de negocio estamos con la intención
de mejorar”? Justo desde el principio y antes de la posibilidad de aplicar BPM se
pone sobre la mesa, es probable que ya sea una idea de cuáles son los problemas
de funcionamiento del equipo tiene que abordar y qué procesos de negocio son
aquellos que presentan problemas de funcionamiento. En otras palabras, el equipo
no va a empezar de cero. Por ejemplo, si el problema es que los ingenieros de sitio
se quejan de que su trabajo se ve obstaculizado por las dificultades en la obtención
de equipos de construcción cuando sea necesario, y sabiendo que este equipo es en
gran medida alquilado, está claro que este problema debe ser abordado por mirar
el proceso de alquiler de equipos. Aún así, hay que delimitar este proceso. En
particular, uno tiene que responder a preguntas tales como: ¿El proceso se inicia
desde el momento en que se seleccionan los proveedores de alquiler? ¿Termina
cuando el equipo alquilado se entrega a la obra de construcción o se termina
cuando el equipo se devuelve al proveedor, o continúa hasta que la cuota por
alquiler de equipo ha sido pagado al proveedor?
Estas preguntas pueden ser fácil o difícil de responder en función de cómo se ha
llevado a cabo gran parte del pensamiento de proceso en la organización de
antemano. Si la organización ha participado en iniciativas BPM antes, es probable
que un inventario de los procesos de negocio está disponible y que el alcance de
estos procesos se ha definido, al menos en cierta medida. En las organizaciones
que no han participado en BPM antes, el equipo de BPM tiene que empezar por
identificar al menos los procesos que son relevantes para el problema sobre la
mesa, delimitar el alcance de estos procesos, e identificar las relaciones entre estos
procesos, como por ejemplo parte de las relaciones (es decir, un proceso de ser
parte de otro proceso). Esta fase inicial de una iniciativa de BPM se denomina
identificación del proceso. Esta fase da lugar a una llamada arquitectura de
procesos,
En general, el propósito de participar en una iniciativa de BPM es asegurar que
los procesos de negocio cubiertos por el plomo iniciativa BPM para
consistentementeresultados positivos y ofrecen el máximo valor a la organización
en el servicio a sus clientes. La medición del valor entregado por un proceso es un
paso crucial en BPM. Como reconocido ingeniero de software, Tom DeMarco, una
vez famoso, lo expresó así: “No se puede controlar lo que no se puede medir”. Así
que antes de empezar a analizar cualquier proceso en detalle, es importante definir
claramente las medidas de rendimiento de proceso (también llamados métricas de
rendimiento de procesos) que se utilizarán para determinar si un proceso está en
“buena forma” o en “mal estado”.
medidas relacionadas con los costos son una clase recurrente de medidas en el
contexto de BPM. Por ejemplo, volviendo al proceso de alquiler de equipos, una
posible medida de rendimiento es el costo total de todos los equipos alquilados por
BuildIT por intervalo de tiempo (por ejemplo, por mes). Otra clase amplia y
20 1 Introducción a la Gestión de Procesos de 
Negocio
recurrente de medidas son las relacionadas con el tiempo. Un ejemplo es la
cantidad promedio de tiempo transcurrido entre el momento en que una solicitud
de alquiler de equipos es presentada por un ingeniero de la obra y la entrega de los
equipos al sitio de construcción. Esta medida generalmente se denomina tiempo de
ciclo. Por último, una tercera clase de medidas recurrentes son los relacionados
con la calidad, y en concreto las tasas de error.
tasa de error es el porcentaje de veces que una ejecución del proceso termina en un
resultado negativo. En el caso del proceso de alquiler de equipos, una de esas
medidas es el número de piezas de equipo devueltos porque no son adecuados, o
debido a defectos en el material entregado. La identificación de tales medidas de
rendimiento (y objetivos de rendimiento asociados) es crucial en cualquier
iniciativa de BPM. Esta identificación se ve generalmente como parte de la fase de
identificación del proceso, aunque en algunos casos puede ser pospuesta hasta las
fases posteriores.
ejercicio 1.3 Considere el proceso de admisión de alumnos descrita en el ejercicio
1.1. Tomando el punto de vista del cliente, identificar al menos dos medidas de
rendimiento que se pueden conectar a este proceso.
Una vez que un equipo de BPM ha identificado qué procesos se están tratando
y que mide el desempeño deben ser utilizados, la siguiente fase para el equipo es
entender el proceso de negocio en detalle. Llamamos a este proceso de
descubrimiento de fase. Típicamente, uno de los resultados de esta fase es uno o
varios AS-es modelos de proceso. Estos tal cual modelos de proceso deben reflejar
el entendimiento de que personas de la organización tienen acerca de cómo se
realiza el trabajo. Los modelos de proceso tienen el propósito de facilitar la
comunicación entre los actores involucrados en una iniciativa de BPM. Por lo
tanto, tienen que ser fáciles de entender. En principio, podríamos modelar un
proceso de negocio a través de descripciones textuales, como la descripción
textual en el ejemplo1.1. Sin embargo, estas descripciones textuales son
incómodos de leer y fácil de malinterpretar debido a la ambigüedad inherente en el
texto de forma libre. Es por esto que es una práctica común el uso de diagramas
para modelar procesos de negocio. Diagramas nos permiten comprender más
fácilmente el proceso. Además, si el diagrama se hace usando una notación que se
entiende por todas las partes interesadas, hay menos espacio para cualquier
malentendido. Tenga en cuenta que estos diagramas todavía pueden
complementarse con descripciones textuales de hecho, es común ver a los analistas
de la documentación de un proceso que utiliza una combinación de diagramas y
texto.
Hay muchos lenguajes de modelado de procesos de negocio en forma de
diagrama. Tal vez una de las más antiguas son diagramas de flujo. En su forma
más básica, diagramas de flujo consisten en rectángulos, actividades que
representan, y diamantes, que representa los puntos del proceso donde se toma una
decisión. Más en general, podemos decir que, independientemente de la notación
1.4El ciclo de vida de BPM 21
específica utilizada, un modelo de proceso esquemática consiste típicamente en
dos tipos de nodo: nodos de actividad y los nodos de control. nodos de actividad
describen unidades de trabajo que se pueden realizar por los seres humanos o
aplicaciones de software, o una combinación de los mismos. Control de nodos de
capturar el flujo de ejecución entre las actividades. Aunque no todos los lenguajes
de modelado de procesos apoyan, un tercer tipo importante de los elementos de los
modelos de procesos son nodos de eventos. Un nodo evento nos dice que algo
puede o debe suceder, en el proceso o en el entorno del proceso, que requiere una
reacción, como por ejemplo la llegada de un mensaje de un cliente pidiendo a
cancelar su orden de compra. Otros tipos de nodos pueden aparecer en un modelo
de proceso, pero podemos decir que los nodos de actividades, eventos y nodos
linfáticos de control son las más básicas.
Existen varias extensiones de diagramas de flujo, como diagramas de flujo
transversal de organización, donde el diagrama de flujo se divide en los
denominados swimlanes que denotan diferentes unidades organizativas (por
ejemplo, departamentos diferentes en una empresa). Si no está familiarizado con el
Fig. 1.6 modelo de proceso para un fragmento inicial del proceso de alquiler de equipos
Unified Modeling Language (UML), que probablemente se habrá llegado a través
de diagramas de actividad UML. En su esencia, diagramas de actividad UML son
diagramas de flujo de toda la Organización. Sin embargo, diagramas de actividad
UML van más allá de los diagramas de flujo entre organizaciones, proporcionando
símbolos para capturar objetos de datos, señales y el paralelismo entre otros
aspectos. Cadenas de proceso Sin embargo, otro idioma para el modelado de
procesos están impulsados por los eventos (EPC). EPC tienen algunas similitudes
22 1 Introducción a la Gestión de Procesos de 
Negocio
con diagramas de flujo, pero se diferencian de los diagramas de flujo en el que
tratan eventos como ciudadanos de primera clase. Otros idiomas que se utilizan
para el modelado de procesos incluyen diagramas de flujo de datos y IDEF3, por
nombrar sólo dos.
Sería alucinante para tratar de aprender todos los idiomas a la vez.
Afortunadamente, hoy en día existe un estándar ampliamente utilizado para el
modelado de procesos, a saber, el Modelo de Procesos de Negocio y la notación
(BPMN). La última versión de BPMN es BPMN 2.0. Fue lanzado como un
estándar por el Grupo de Gestión de Objetos (OMG) en 2011. En BPMN, las
actividades se representan como rectángulos redondeados. los nodos de control
(llamadas pasarelas) se representan usando formas de diamante. Actividades y
nodos de control están conectados por medio de arcos (llamados flujos) que
determinan el orden en el que se ejecuta el proceso. Figura1.6 proporciona un
modelo que representa un fragmento inicial del proceso de alquiler de equipos,
hasta el punto de que el ingeniero de obras acepta o rechaza la solicitud de alquiler
de equipos. Este modelo de proceso muestra dos puntos de decisión. En el
primero, el proceso toma uno de dos caminos dependiendo de si el equipo está
disponible o no. En la segunda, la solicitud de alquiler de equipos se aprueba o
rechaza tampoco. El modelo también muestra los participantes en los procesos que
intervienen en este fragmento del proceso, a saber, el ingeniero de la obra, el
secretario y el ingeniero de obras. Cada uno de estos participantes se muestra
como un carril separado que contiene las actividades realizadas por el participante
en cuestión.
El modelo de proceso en la Fig. 1.6 se captura en un alto nivel de abstracción. A
lo sumo, puede servir paradar a una persona externa un resumen de lo que ocurre
en este proceso. En algunos casos, sin embargo, el modelo necesita más detalles
para que sea útil. ¿Qué datos adicionales deberán incluirse en un modelo de
proceso depende del propósito. A menudo, los modelos de proceso están
destinadas a servir como documentación de la forma en que funciona una
organización. En este caso, las características principales de los modelos de
procesos son la sencillez y comprensibilidad. En consecuencia, las anotaciones de
texto adicionales podrían ser añadidos al modelo de proceso para aclarar el
significado de ciertas actividades o eventos, pero más allá de estas anotaciones, se
añadirían no mucho detalle adicional. En otros casos, los modelos de proceso están
destinados a ser analizado en detalle, por ejemplo con el fin de medir el
rendimiento del proceso. En este caso, detalles adicionales pueden ser necesarios,
tales como la cantidad de tiempo que cada tarea toma (en promedio). Por último,
en algunos casos, los modelos de proceso están destinados a ser desplegados en un
BPMS con el fin de coordinar la ejecución de la secta proceso (cf..1.3.3). En el
último caso, el modelo necesita ser extendido con una cantidad significativa de
detalles con respecto a las entradas y salidas del proceso y cada una de sus
actividades.
Habiendo comprendido el proceso tal como es en detalle, el siguiente paso es
identificar y analizar los problemas en este proceso. Un problema potencial en el
1.4El ciclo de vida de BPM 23
proceso de alquiler de equipos de BuildIT es que el tiempo de ciclo es demasiado
alto. Como resultado de ello, los ingenieros de sitio no logran obtener el equipo
necesario a tiempo. Esto puede causar retrasos en diversas tareas de construcción,
que pueden repercutirán hacia abajo en los retrasos en los proyectos de
construcción. Para analizar estas cuestiones, analista tendría que recopilar
información sobre el tiempo dedicado a cada tarea del proceso, incluyendo tanto la
cantidad de tiempo que procesan los participantes pasan realmente hacer el trabajo
y la cantidad de tiempo de inactividad, es decir, la cantidad de tiempo cuando se
requiera el equipo está bloqueado, esperando que algo suceda. Este tiempo de
inactividad también se llama tiempo de espera. También, el analista necesitaría
para reunir información con respecto a la cantidad de trabajo que tiene lugar en el
proceso. Aquí, retrabajo significa que una o varias tareas se repiten porque algo
salió mal. Por ejemplo, cuando el empleado identifica una pieza adecuada de
equipo en el catálogo de un proveedor, pero más tarde se entera de que la pieza de
equipo no está disponible en las fechas requeridas, el empleado podría tener que
buscar de nuevo por una pieza alternativa de equipos de otro proveedor . valioso
tiempo que se gasta por el secretario de ir y venir entre la consulta de los catálogos
y en contacto con los proveedores para comprobar la disponibilidad de las plantas.
Con el fin de analizar esta cuestión, el analista tendría que averiguar en qué
porcentaje de casos falla la verificación de disponibilidad y por lo tanto la
frecuencia con el empleado tiene que hacer un poco de la reanudación con el fin de
identificar las piezas alternativas de equipos y comprobar su disponibilidad. Dada
esta información, un analista de procesos puede emplear varias técnicas que serán
discutidos en este libro, con el fin de rastrear por la causa (s) de largos tiempos de
ciclo e identificar maneras de cambiar el proceso con el fin de reducir el tiempo de
ciclo.
Otro problema potencial en el proceso de alquiler de equipos de BuildIT es que
a veces los equipos entregados en el lugar de la construcción no es adecuada, y el
ingeniero de la obra tiene que rechazarla. Este es un ejemplo de un resultado
negativo. Para analizar este tema, analista tendría que saber con qué frecuencia se
producen tales resultados negativos. En segundo lugar, los analistas necesitarían
para obtener información que les permita entender por qué estos resultados
negativos están sucediendo. En otras palabras, ¿de dónde las cosas van mal en el
primer lugar? A veces, este resultado negativo podría deberse a la falta de
comunicación, por ejemplo, entre el ingeniero de la obra y el empleado. De lo
contrario, podría venir de datos inexactos (por ejemplo, errores en la descripción
del equipo), o de un error en el lado del proveedor. Sólo mediante la identificación,
clasificar y en última instancia, la comprensión de las principales causas de estos
resultados negativos puede analista averiguar cuál sería la forma más adecuada de
abordar esta cuestión. La identificación y evaluación de los problemas y las
oportunidades de mejora de procesos Queda llama la fase de análisis de procesos.
Observamos que los dos problemas mencionados anteriormente están
estrechamente relacionadas con las medidas de rendimiento. Por ejemplo, el
primer problema anterior está ligado al tiempo de ciclo y el tiempo de espera, los
24 1 Introducción a la Gestión de Procesos de 
Negocio
cuales son medidas de rendimiento típicas de un proceso. Del mismo modo, el
segundo problema está ligado a la “porcentaje de rechazos de equipo”, que es
esencialmente una tasa-otra medida de rendimiento típico error. Por lo tanto, la
evaluación de la problemática de un proceso a menudo va mano a mano con la
medición del estado actual del proceso con respecto a ciertas medidas de
rendimiento.
ejercicio 1.4 Consideremos de nuevo el proceso de admisión de alumnos descrita
en el ejercicio 1.1. Tomando el punto de vista del cliente, pensar en por lo menos
dos cuestiones que este proceso pueda tener.
Una vez que se han analizado cuestiones en un proceso y, posiblemente,
cuantificado, la siguiente fase es identificar y analizar remedios potenciales para
estos problemas. En este punto, el analista tendrá en cuenta varias opciones
posibles para hacer frente a un problema. De este modo, el analista tiene que tener
en cuenta que un cambio en un proceso para hacer frente a un problema
potencialmente pueden causar otros problemas en el camino. Por ejemplo, con el
fin de acelerar el proceso de alquiler de equipos, se podría pensar en la eliminación
de los pasos de aprobación que implican el ingeniero de obras. Si llevada al
extremo, sin embargo, este cambio significaría que el equipo alquilado a veces
puede no ser óptimo desde el punto de vista ingeniero de obras no se toma en
cuenta.
Cambio de un proceso no es tan fácil como parece. La gente está acostumbrada
a trabajar de una manera determinada y pueden resistirse a los cambios. Por otra
parte, si el cambio implica modificar el sistema (s) de la información que sustenta
el proceso, el cambio puede ser costoso o puede requerir cambios no sólo en la
organización que coordina el proceso, sino también en otras organizaciones. Por
ejemplo, una forma de eliminar el retrabajo de que el empleado tiene que ver en la
comprobación de la disponibilidad de los equipos, sería que los proveedores
proporcionan información sobre la disponibilidad de las plantas. De esta manera,
el empleado podría utilizar la misma interfaz para buscar un equipo adecuado y
para comprobar la disponibilidad del equipo durante un determinado periodo de
tiempo. Sin embargo, este cambio en el proceso requeriría que los proveedores
cambien su sistema de información, por lo que su sistema expone hasta a
información actualizada a la disponibilidad del equipo BuildIT. Este cambio es al
menos parcialmente fuera del control de BuildIT. Suponiendo que los proveedores
serían capaces de realizar tales cambios, una solución más radical que se podría
considerar sería la de proporcionar dispositivos móviles y conexión a Internet para
los ingenieros de sitio, de modo que puedanconsultar el catálogo de equipos
(incluyendo información de disponibilidad) en cualquier momento y en cualquier
lugar . De esta manera, no necesitaría el empleado de estar involucrado en el
proceso durante la fase de búsqueda de equipos, evitando así problemas de
comunicación entre el ingeniero de la obra y el empleado. Sea o no este cambio
más radical es viable requeriría un análisis en profundidad de la costo de cambiar
1.4El ciclo de vida de BPM 25
el proceso de esta manera frente a los beneficios que tal cambio sería proporcionar.
Este cambio es al menos parcialmente fuera del control de BuildIT. Suponiendo
que los proveedores serían capaces de realizar tales cambios, una solución más
radical que se podría considerar sería la de proporcionar dispositivos móviles y
conexión a Internet para los ingenieros de sitio, de modo que puedan consultar el
catálogo de equipos (incluyendo información de disponibilidad) en cualquier
momento y en cualquier lugar . De esta manera, no necesitaría el empleado de
estar involucrado en el proceso durante la fase de búsqueda de equipos, evitando
así problemas de comunicación entre el ingeniero de la obra y el empleado. Sea o
no este cambio más radical es viable requeriría un análisis en profundidad de la
costo de cambiar el proceso de esta manera frente a los beneficios que tal cambio
sería proporcionar. Este cambio es al menos parcialmente fuera del control de
BuildIT. Suponiendo que los proveedores serían capaces de realizar tales cambios,
una solución más radical que se podría considerar sería la de proporcionar
dispositivos móviles y conexión a Internet para los ingenieros de sitio, de modo
que puedan consultar el catálogo de equipos (incluyendo información de
disponibilidad) en cualquier momento y en cualquier lugar . De esta manera, no
necesitaría el empleado de estar involucrado en el proceso durante la fase de
búsqueda de equipos, evitando así problemas de comunicación entre el ingeniero
de la obra y el empleado. Sea o no este cambio más radical es viable requeriría un
análisis en profundidad de la costo de cambiar el proceso de esta manera frente a
los beneficios que tal cambio sería proporcionar. una solución más radical que se
podría considerar sería la de proporcionar dispositivos móviles y conexión a
Internet para los ingenieros de sitio, de modo que puedan consultar el catálogo de
equipos (incluyendo información de disponibilidad) en cualquier momento y en
cualquier lugar. De esta manera, no necesitaría el empleado de estar involucrado
en el proceso durante la fase de búsqueda de equipos, evitando así problemas de
comunicación entre el ingeniero de la obra y el empleado. Sea o no este cambio
más radical es viable requeriría un análisis en profundidad de la costo de cambiar
el proceso de esta manera frente a los beneficios que tal cambio sería proporcionar.
una solución más radical que se podría considerar sería la de proporcionar
dispositivos móviles y conexión a Internet para los ingenieros de sitio, de modo
que puedan consultar el catálogo de equipos (incluyendo información de
disponibilidad) en cualquier momento y en cualquier lugar. De esta manera, no
necesitaría el empleado de estar involucrado en el proceso durante la fase de
búsqueda de equipos, evitando así problemas de comunicación entre el ingeniero
de la obra y el empleado. Sea o no este cambio más radical es viable requeriría un
análisis en profundidad de la costo de cambiar el proceso de esta manera frente a
los beneficios que tal cambio sería proporcionar. no necesitaría el empleado de
estar involucrado en el proceso durante la fase de búsqueda de equipos, evitando
así problemas de comunicación entre el ingeniero de la obra y el empleado. Sea o
no este cambio más radical es viable requeriría un análisis en profundidad de la
costo de cambiar el proceso de esta manera frente a los beneficios que tal cambio
sería proporcionar. no necesitaría el empleado de estar involucrado en el proceso
26 1 Introducción a la Gestión de Procesos de 
Negocio
durante la fase de búsqueda de equipos, evitando así problemas de comunicación
entre el ingeniero de la obra y el empleado. Sea o no este cambio más radical es
viable requeriría un análisis en profundidad de la costo de cambiar el proceso de
esta manera frente a los beneficios que tal cambio sería proporcionar.
ejercicio 1.5 Dados los problemas en el proceso de admisión identificado en el
ejercicio 1.4, Lo que sea posible los cambios cree usted que se podría hacer a este
proceso con el fin de abordar estas cuestiones?
Equipado con una comprensión de una o varias emisiones en un proceso y un
conjunto candidato de remedios potenciales, los analistas pueden proponer una
versión rediseñada del proceso, es decir, un proceso de a-ser que se ocupe de los
problemas identificados en el proceso tal y como está . Este proceso de ser es la
salida principal de la fase de proceso de rediseño. Aquí, es importante tener en
cuenta que el análisis y rediseño están íntimamente relacionados. Puede haber
múltiples opciones de rediseño y cada una de estas opciones tiene que ser
analizada, por lo que una decisión informada se puede hacer en cuanto a qué
opción debe ser elegido.
Una vez rediseñado, los cambios necesarios en las formas de trabajo y los
sistemas de TI de la organización deben ser implementadas de manera que el
proceso de a-ser, finalmente, se puede poner en ejecución. Esta fase se llama la
aplicación del proceso. En el caso del proceso de alquiler de equipos, la fase de
implementación del proceso significaría poner en marcha un sistema de
información para registrar y realizar un seguimiento de las solicitudes de alquiler
de equipos, las OP asociadas a las peticiones y las facturas aprobadas asociados a
estas OP. La implementación de dicho sistema de información significa no sólo el
desarrollo de los componentes de TI de este sistema. También se relacionaría con
la formación de los participantes en el proceso para que realicen su trabajo en el
espíritu del proceso rediseñado y hacer el mejor uso de los componentes de TI del
sistema.
De manera más general, la aplicación del proceso puede implicar dos facetas
complementarias: la gestión del cambio organizacional y la automatización de
procesos. la gestión del cambio organizacional se refiere al conjunto de actividades
necesarias para cambiar la forma de trabajar de todos los participantes
involucrados en el proceso. Estas actividades incluyen:
• Al explicar los cambios en los participantes del proceso hasta el punto de que
entienden lo tanto, se están introduciendo cambios y por qué estos cambios son
beneficiosos para la empresa.
• Poner en marcha un plan de gestión del cambio para que los interesados sepan
cuándo se dará a los cambios en vigor y las disposiciones transitorias que serán
empleados para hacer frente a problemas durante la transición al proceso a-ser.
1.4El ciclo de vida de BPM 27
• El entrenamiento de los usuarios a la nueva forma de trabajar y el seguimiento
de los cambios con el fin de garantizar una transición sin problemas al proceso
a-ser.
Por otra parte, la automatización de procesos consiste en la configuración o 
implantación de un sistema informático (o la re-configuración de un sistema de TI 
existente) para apoyar el proceso de “a-ser”. Este sistema debe apoyar los 
participantes del proceso en el rendimiento. Fig ciclo de vida de 1,7 BPM
de las tareas del proceso. 
Esto puede incluir la asignación de tareas para procesar los participantes, ayudando
a los participantes del proceso de priorizar su trabajo, proporcionando los 
participantes del proceso con la información que necesitan para realizar una tarea, 
y realizar verificaciones cruzadas automáticas y otras tareas automatizadas siempre
que sea posible. Hay varias maneras de implementar un sistema de este tipo. Este 
libro se centraen un enfoque en particular, que consiste en que se extiende el 
modelo de proceso a-ser obtenido a partir de la fase de rediseño de procesos con el
fin de hacer que sea ejecutable por un BPMS (Sec cf..1.3.3).
Con el tiempo, algunos ajustes podrían ser necesarios debido a que el proceso
de negocio en marcha no cumple las expectativas. Con este fin, el proceso necesita
ser monitoreado y los analistas deben examinar los datos recogidos por el
seguimiento del proceso con el fin de identificar los ajustes necesarios para
controlar mejor la ejecución del proceso. Estas actividades están abarcados por la
supervisión de procesos y la fase de control. Esta fase es importante porque
abordar uno o un puñado de temas en un proceso no es el final de la historia. En su
lugar, la gestión de un proceso requiere un esfuerzo continuo. La falta de
seguimiento y mejora de un proceso continuo conduce a la degradación. Como
Michael Hammer dijo una vez: “todo buen proceso eventualmente se convierte en
un proceso malo”, a menos que continuamente adaptado y mejorado para
28 1 Introducción a la Gestión de Procesos de 
Negocio
mantenerse al día con el paisaje siempre cambiante de las necesidades del cliente,
la tecnología y la competencia. Esta es la razón por las fases en el ciclo de vida de
BPM deben ser vistos como ser circular: la salida de monitorización y control se
alimenta de nuevo en el descubrimiento, análisis y fases de rediseño.
Para resumir, podemos ver BPM como ciclo continuo que comprende las
siguientes fases (véase la fig. 1.7):
• identificación del proceso. En esta fase, un problema de negocio se plantea,
procesos relacionados con el problema que se aborda son identificadas,
delimitadas y relacionados entre sí. El resultado del proceso de identificación es
una arquitectura nueva o actualizada proceso que proporciona una visión global
de los procesos de una organización y sus relaciones. En algunos casos, la
identificación proceso se realiza en paralelo con la identificación medida de
rendimiento. En este libro, sin embargo, vamos a asociar la identificación
medida de rendimiento con la fase de análisis de procesos, dado que las
medidas de rendimiento a menudo se utilizan para el análisis de procesos.
• descubrimiento de proceso (también llamado como está modelado de procesos).
Aquí, el estado actual de cada uno de los procesos pertinentes se documenta,
típicamente en forma de una o varias como está modelos de proceso.2
• Análisis de proceso. En esta fase, los problemas asociados a la AS-se están
identificados proceso, documentados y siempre que sea posible cuantificaron
utilizando medidas de rendimiento. El resultado de esta fase es una colección
estructurada de problemas. Estos problemas suelen ser priorizados en términos
de su impacto, ya veces también en términos del esfuerzo estimado necesario
para resolverlos.
• rediseño de procesos (También llamada la mejora de procesos). El objetivo de
esta fase es identificar cambios en el proceso que ayudaría a hacer frente a los
problemas identificados en la fase anterior y permitirá a la organización a
cumplir sus objetivos de rendimiento. Con este fin, múltiples opciones de
cambio son analizados y comparados en términos de las medidas de
rendimiento elegidos. Esto implica que el rediseño de procesos y análisis de
procesos van mano a mano: Como se proponen nuevas opciones de cambio, que
se analizan utilizando técnicas de análisis de proceso. Con el tiempo, las
opciones de cambio más prometedores se combinan, dando lugar a un proceso
rediseñado. La salida de esta fase es típicamente un modelo de proceso a-ser,
que sirve como base para la siguiente fase.
2Esta fase también se llama el diseño del proceso en la literatura. Sin embargo, el descubrimiento
de procesos es sin duda un término más apropiado, ya que el proceso ya existe, al menos de
forma implícita en las cabezas de los actores que lo realizan. El objetivo de esta fase es
generalmente para descubrir el proceso en lugar de diseñarlo. En casos raros (por ejemplo,
empresas nuevas) ningún proceso todavía está en su lugar de modo que las fases de
descubrimiento y análisis no son necesarios y el proceso tiene que ser diseñado por primera vez
en lugar de rediseñado.
1.4El ciclo de vida de BPM 29
• Implementación del proceso. En esta fase, los cambios necesarios para pasar de
proceso en que está en el proceso a-ser preparados y realizado. Implementación
del proceso abarca dos aspectos: la gestión del cambio organizacional y la
automatización de procesos. la gestión del cambio organizacional se refiere al
conjunto de actividades necesarias para cambiar la forma de trabajar de todos
los participantes involucrados en el proceso. La automatización de procesos, por
otro lado se refiere al desarrollo y despliegue de sistemas de información (o
versiones mejoradas de los sistemas de TI existentes) que apoyan el proceso a-
ser. En este libro, nuestro enfoque con respecto a la implementación de procesos
está en la automatización de procesos, como la gestión del cambio
organizacional es un campo totalmente independiente. Más específicamente,
• monitorización de procesos y el control. Una vez que el proceso rediseñado se
está ejecutando, los datos relevantes se recogen y analizan para determinar qué
tan bien está funcionando el proceso con respecto a sus medidas de rendimiento
y objetivos de desempeño. Los cuellos de botella, errores recurrentes o
desviaciones con respecto al comportamiento previsto se identifican y se llevan
a cabo las acciones correctivas. Nuevos problemas pueden surgir a
continuación, en el mismo o en otros procesos, lo que requiere que el ciclo se
repita de forma continua.
El ciclo de vida de BPM ayuda a entender el papel de la tecnología BPM. La
tecnología en general, y especialmente la tecnología de la información (TI), es un
instrumento clave para mejorar los procesos de negocio. No es sorprendente que
los especialistas de TI, tales como ingenieros de sistemas a menudo desempeñan
un papel importante en las iniciativas de BPM. Sin embargo, para lograr la
máxima eficacia, los ingenieros de sistemas deben ser conscientes de que la
tecnología es sólo un instrumento para la gestión y ejecución de los procesos. Los
ingenieros de sistemas necesitan trabajar juntos con analistas de procesos con el
fin de entender cuáles son los principales problemas que afectan a un determinado
proceso, y la mejor manera de abordar estas cuestiones, ya sea por medio de la
automatización o por otros medios. Como reconocido empresario de tecnología,
Bill Gates, una vez famoso ponerlo: “La primera regla de cualquier tecnología que
se utiliza en un negocio es que la automatización aplicada a una operación
eficiente en magnificar la eficiencia. La segunda es que la automatización aplicada
a una operación ineficiente en magnificar la ineficiencia”. Esto significa que el
aprendizaje de cómo diseñar y mejorar los procesos y no sólo cómo construir un
sistema informático para automatizar una parte estrecha de un negocio proceso es
una habilidad fundamental que debe estar en manos de cualquier graduado de TI.
Recíprocamente, graduados de negocios necesitan entender cómo la tecnología, y
en particular de TI, se pueden utilizar para optimizar la ejecución de procesos de
negocio. Este libro tiene como objetivo la reducción de estos dos puntos de vista
mediante la presentación de un punto de vista integral que cubre todo el ciclo de
vida de BPM. Esto significa que el aprendizaje de cómo diseñar y mejorar los
procesos y no sólo cómo construir un sistema informático para automatizar una
parte estrecha de un negocio proceso es una habilidad fundamental que debe estar
30 1 Introducción a la Gestión de Procesos de 
Negocio
en manos de cualquier graduado