LibroBPM Sergio

BPM (Business Process Management).
Cmo alcanzar la agilidad y eficiencia operacional a travs

de BPM y la empresa orientada a procesos.
Jos Ramn Pais Curto
Coleccin Conceptos Clave BPM

Editorial:
BPM (Business Process Management). Cmo alcanzar la agilidad y efi-
ciencia operacional a travs de BPM y la empresa orientada a procesos.
Edicin original en espaol
Jos Ramn Pais Curto, 2013. Todos los derechos reservados.
Foto cubierta: Jos Ramn Pais Curto
Editor: Pedro Robledo, 2013

BPMteca.com, 2013 www.BPMteca.com
email: pedrorobledo@bpmteca.com
Todas las marcas y nombres de productos mencionados en este libro son

marcas comerciales o marcas de servicio de sus respectivas compaas.
Cualquier omisin o mal uso no debe ser considerada como la intencin de
infringir la propiedad de otros. El editor reconoce y respeta todas las marcas
utilizadas por las empresas, los fabricantes y los desarrolladores como un
medio para distinguir sus productos. Ni el editor, ni el autor, ni BPMte-
ca.com, aceptan ninguna responsabilidad por prdidas o daos ocasionados
a cualquier persona o propiedad mediante el uso del material, instrucciones,
mtodos o ideas contenidas en el presente, o actuar o dejar de actuar como
consecuencia de dicho uso.
Todos los derechos reservados. Fabricada la versin digital en espaol en

Espaa. Queda rigurosamente prohibida, sin la autorizacin escrita de los
titulares del copyright, bajo las sanciones establecidas en las leyes, la repro-
duccin total o parcial de esta obra por cualquier mtodo o procedimiento,
comprendidos la reprografa y el tratamiento informtico, excepto en el caso
de citas breves incluidas en artculos crticos y revisiones. Queda prohibida
tambin la distribucin de ejemplares de ella mediante alquiler o prstamos
pblicos. Este libro est publicado en formato digital. El contenido completo
de este libro est protegido por derechos de autor y no debe ser distribuido o
sus datos extrados sin autorizacin por escrito del publicador.
Usted est autorizado a imprimir una copia para uso personal.
Informacin sobre Catalogacin por el Editor
ISBN: 978-84-616-3854-3 Versin Digital

A Sandra, Aida y Malena.
INDICE
ACERCA DEL AUTOR ..................................................................................... 11

INTRODUCCIN............................................................................................ 13
Acerca de la Certificacin OCEB. .......................................................... 31
ESTRUCTURA DEL LIBRO............................................................................... 23
PARTE 1. FUNDAMENTOS DE LA GESTIN POR PROCESOS ......................... 29
Captulo 1. La gestin de procesos........................................................... 31
La empresa como sistema.................................................................... 31
Gestin de procesos............................................................................. 42
Tcnicas y Herramientas de anlisis de procesos. ............................... 66
Captulo 2. Los caminos hacia BPM.......................................................... 77
Orgenes de la gestin empresarial:..................................................... 78
TQM (Total Quality Management)....................................................... 83
Six Sigma............................................................................................... 85
BPR (Business Process Reenginering)................................................... 90
Teora de las Limitaciones. (TOC). ........................................................ 97
Hacia una teora unificada.................................................................. 101
Captulo 3. Tecnologa, Innovacin y Modelos de Negocio. .................. 107
Evolucin tecnolgica:........................................................................ 107
Innovacin.......................................................................................... 118
Modelos de negocio ........................................................................... 126
PARTE 2. BPM (BUSINESS PROCESS MANAGEMENT)................................. 135
Captulo 4. BPM (Business Process Management)................................. 137
Qu es BPM ........................................................................................ 137
Ciclo de Vida de BPM.......................................................................... 138
Componentes principales de BPM ..................................................... 141
Principios, prcticas y ventajas de BPM. ............................................ 146
El Modelo de Madurez para la gestin de procesos. ......................... 155
La organizacin Orientada a Procesos................................................ 159
El Pensamiento Sistmico................................................................... 166
Captulo 5. Modelado de Negocios. ....................................................... 173
Valor y Ventaja competitiva. .............................................................. 175
La Cadena de Valor. ............................................................................ 178
Estrategia, procesos y tecnologa. ...................................................... 186
Arquitectura empresarial. .................................................................. 189
Frameworks, Estndares y Modelos de Referencia. .......................... 193
El Business Motivation Model (BMM)................................................ 204
Captulo 6. Modelado de procesos. BPMN............................................. 215
Elementos principales de BPMN. ....................................................... 217
Tipos de Modelos BPMN: ................................................................... 233
BPMN ANALTICO: .............................................................................. 234
BPMN 2.0:........................................................................................... 252
PARTE 3. IMPLEMENTACIN DE BPM. ....................................................... 253
Captulo 7. IMPLEMENTACIN DE BPM. ................................................ 255
Entorno de Negocio............................................................................ 259
Levantamiento de procesos. .............................................................. 261
Datos del proceso y Reglas de negocio. ............................................. 284
Mejora de procesos............................................................................ 289
Medidas, indicadores y anlisis del proceso: ..................................... 302
Simulacin de procesos:..................................................................... 302
Implementar el proceso: .................................................................... 325
Puesta en Marcha del proceso:.......................................................... 327
Control del proceso y Mejora Continua. ............................................ 328
TOC, Lean y Six Sigma dentro de un proyecto de BPM...................... 331
Gestin del proyecto:......................................................................... 337
Factores crticos de xito de un proyecto BPM.................................. 348
Captulo 8. Tecnologa BPM. BPMS........................................................ 352
Mdulos principales de un BPMS:..................................................... 357
Modelador grfico de procesos. ........................................................ 361
Entorno de Integracin. (Integration Developer) .............................. 368
Servidor de procesos.......................................................................... 371
Ejecucin del proceso......................................................................... 374
Monitorizacin de procesos............................................................... 377
Arquitectura tecnolgica. BPM y SOA................................................ 379
Gestin de casos................................................................................. 387
Bibliografa ................................................................................................. 390
ACERCA DEL AUTOR
Jos Ramn Pais Curto tiene una larga experiencia en la implantacin de
sistemas de informacin, gestin de la innovacin, la aceleracin del cam-
bio a travs de TI y la gestin por procesos en diferentes empresas y admi-
nistraciones pblicas. Es Certified Expert in Business Process Management
por Object Management Group (OMG).
Adems de autor, ofrece servicios de consultora y acompaamiento a

las organizaciones en la implementacin de proyectos de BPM as como de
distintos tipos de formacin en esta materia, en la que se pone en prctica
los conceptos tericos de este libro con casos reales y prcticos sobre dis-
tintas plataformas software de BPM.
Para contactar con el autor o realizar cualquier tipo de consulta o co-

mentario:
Mail: josepaiscurto@gmail.com
Linkedin: http://es.linkedin.com/in/josepaiscurto
Twitter: @josepaiscurto
Introduccin
INTRODUCCIN
Cualquier tecnologa lo bastante avanzada
es indistinguible de la magia.
Arthur C. Clarke
La necesidad de adecuacin a nuevos modelos de negocio y mercados,

exige de las empresas ms y mejores innovaciones y formas de hacer las
cosas que slo podrn ser realizadas adoptando una nueva forma de pensar
las organizaciones. BPM (Business Process Management), es un conjunto de
mtodos y tecnologas estructuradas para la gestin de procesos de nego-
cio, usado por organizaciones de todos los tipos y sectores, que considera
que los procesos son los activos ms importantes de la empresa para crear
valor a nuestros clientes. Esta perspectiva ha existido siempre en todas las
organizaciones y teoras de la gestin empresarial, sin embargo, no ha sido
hasta ahora que las empresas han dedicado la atencin y cuidado necesa-
rios a sus procesos de negocio, con los cuales, podemos afrontar la gestin
del cambio, la innovacin, el aprovechamiento de la tecnologa y la eficien-
cia de nuestras operaciones empresariales a travs del rediseo o la mejora
de los procesos con los que las empresas ejecutan sus estrategias de nego-
cio.
BPM nos descubre una nueva forma de gestionar las organizaciones

desde la perspectiva de que stas sern tan eficientes como lo sean sus
procesos, por lo que el diseo, la medicin, la mejora, simulacin, control y
13
BPM (Business Process Management)
monitorizacin de estos procesos de negocio, se ha convertido en el reto

principal para la mejora de las organizaciones y asegurar su xito en un
entorno altamente cambiante y competitivo.
Todas las organizaciones desean mejorar sus beneficios, mejorar los

productos y servicios ofrecidos a sus clientes, reducir sus costes y mantener
satisfechos a sus empleados y esto slo podr ser realizado si todos los
procesos de la empresa funcionan de forma eficiente y sincronizada. BPM
es una metodologa sistemtica y holstica para la mejora de los procesos
de negocio de la organizacin que se apoya en la gestin unificada de pro-
cesos de negocio, personas y tecnologa como forma de alcanzar y mejorar
los resultados empresariales. BPM nos proporciona la forma de disear
nuestra empresa a partir de la visin de negocio que tengamos de la misma
para sobre esta visin, construir todas las herramientas (Procesos, Personas
y Tecnologa) que nos permitan llevar esta visin adelante de forma que
todos los sistemas y personas dentro de la organizacin sepan lo que tienen
qu hacer, cundo y cmo hacerlo, de forma lgica y coordinada y con la
capacidad de poder rectificar y adaptar nuestros procesos al entorno cam-
biante en cualquier momento sin incurrir en proyectos de reestructuracin
a largo plazo. Imaginemos cmo nos gustara que fuese nuestro negocio y
con BPM podremos implementar esa visin.
Muchas veces entendemos BPM como una nueva herramienta o produc-

to software. Sin embargo, BPM no es slo tecnologa sino una nueva forma
de entender cmo la tecnologa da soporte a la verdadera razn de ser de
las empresas, que es hacer negocio a travs de una serie de operaciones y
procesos de negocio. Hoy en da no concebimos ningn negocio que no se
apoye o est directamente basado en la tecnologa y en el caso de BPM,
para poder alinear los proceso de negocio con las estrategias empresariales,
necesitaremos herramientas tecnolgicas para medir y controlar los mis-
mos en tiempo real y poder monitorizar el desempeo y grado de cumpli-
miento de nuestros procesos de negocio con los objetivos de negocio plan-
teados, de forma que podamos trabajar en la mejora continua y en la opti-
mizacin de nuestro modelo y procesos de negocio que operamos. En BPM
siempre trabajaremos antes con papel y post-its para entender y mejorar
nuestros procesos para finalmente, como ltimo eslabn de la cadena,
apoyarnos en la tecnologa para automatizar y poder entre otras cosas me-
dir, monitorizar, gestionar y redisear los procesos diseados. Aunque mu-
chas veces se usen las herramientas tecnolgicas de BPM sin encuadrarlas
dentro del contexto de la gestin tradicional de las empresas o de la gestin
por procesos, no debemos olvidar que BPM es la tecnologa aplicada de
14
Introduccin
forma racional a como ejecutamos nuestro negocio y creamos valor,

haciendo uso no slo de los componentes tecnolgicos, sino de todas las
tcnicas y herramientas necesarias para el negocio (Reingeniera, gestin
empresarial, finanzas, TQM, Six Sigma, TOC, modelos y estndares de nego-
cio, arquitecturas empresariales, etc.), sobre las cuales diseamos y cons-
truimos nuestros negocios apoyndonos en las personas y la tecnologa
para obtener un todo coordinado e integrado que permita transformar la
visin empresarial en realidad.
Esta perspectiva y posicionamiento de BPM como modelo de gestin or-

ganizacional orientado a la gestin por procesos, ha llevado al Gartner
Group, la multinacional lder en investigacin tecnolgica, a manifestar que
el modelo BPM y sus tecnologas asociadas son los de mayor crecimiento y
el de mayor proyeccin de futuro y son el motivo por el que compaas tan
relevantes como IBM, Oracle, Microsoft o SAP estn dirigiendo hacia BPM
todas sus inversiones en plataformas de gestin empresarial.
El haberme dedicado estos ltimos aos a profundizar en BPM y los

BPMS (Business Process Management Systems) y el haberme decidido a
escribir este libro, viene del profundo convencimiento de que estos siste-
mas y la metodologa que los soporta, son la manera ms efectiva y racional
de alinear el negocio y la tecnologa y de gestionar conjuntamente los pro-
cesos de negocio empresariales y la tecnologa dentro de las organizacio-
nes, para generar valor, optimizar las infraestructuras de TI, poder innovar y
adaptarse al cambio y trabajar en la mejora continua.
Sin embargo, debo reconocer mi escepticismo inicial. Cuando los siste-

mas BPM empezaron a desarrollarse, me parecieron demasiado buenos
como para ser reales. Hasta entonces, todas las herramientas y metodolo-
gas que conoca estaban asociadas a la implementacin de la tecnologa
desde una perspectiva tecnolgica y no de negocio. La aproximacin de
BPM a los procesos me pareci una forma inteligente de asociar estos dos
mundos, hasta entonces aislados uno del otro. Tecnolgicamente, la posibi-
lidad de disear visualmente un proceso y poder aadirle datos de recursos,
costes, tiempos y medidas e indicadores para analizar su funcionamiento;
integrar los procesos diseados con los dems sistemas informticos para
orquestar personas y sistemas en torno a los procesos; poder simular el
funcionamiento de los mismos y realizar modificaciones sobre el modelado
que se trasladasen en tiempo real al entorno de ejecucin sin tener que
escribir una sola lnea de cdigo; me pareci pura magia, pretenciosa e
incluso amenazadora para la gente de TI.
15
Durante varios aos, he dirigido y desarrollado soluciones TIC en distin-

tos mbitos, muchas veces sin considerar el entorno organizacional, los
objetivos o planes estratgicos de las empresas sobre la que deba imple-
mentar la solucin tecnolgica. Estos aspectos no estaban incluidos en el
proyecto, la empresa deseaba implementar un software, muchas veces
porque el gerente de la empresa haba visto la misma implementada en
otra organizacin, ledo sobre ella, o simplemente haba sido convencido
por un comercial. De cualquier de las maneras, esta solucin no siempre
estaba alineada con los objetivos de la empresa; nos abstraamos de esa
parte. Las soluciones software no eran vistas y analizadas como un brazo
ms de la empresa, sino como un organismo aparte del mismo y sobre el
que se esperaban unos resultados extraordinarios. En estos casos, un ana-
lista o comercial realizaba la toma de requisitos de una persona de la em-
presa y traduca estos a cdigo fuente ejecutable y que cumpla con las
especificaciones dadas por el cliente, fuesen stas las ms apropiadas y
correctas o no.
Con la aparicin de internet esta situacin se ha agravado todava ms.

Las empresas, en su afn de adaptacin al nuevo medio como forma de
incrementar sus ingresos, se han lanzado al desarrollo de plataformas en
internet sin tener su gestin y sistemas preparados para afrontar las exi-
gencias que este nuevo medio demanda. Con los aos he comprobado que
faltaba planificacin desde la base misma de las organizaciones en su orien-
tacin estratgica, de forma que internet fuese una herramienta ms de la
empresa, el resultado de una lgica empresarial que permitiese aprovechar
este medio para la consecucin de sus objetivos de negocio. Son muchas las
empresas que todava hoy disean sus estrategias comenzando por las re-
des sociales, dejndose llevar por modas y tendencias, que si bien pueden
producir satisfaccin a corto plazo, pronto se revelarn como actuaciones
aisladas, no alineadas con la empresa y con la forma en que esta crea valor
a sus clientes. Internet no slo ha producido nuevas oportunidades y mode-
los de negocio, sino que ha desvelado las debilidades e ineficiencias en las
infraestructuras y sistemas de informacin de muchas organizaciones. Mu-
chas veces, las actuaciones en redes sociales obedecen a campaas de mar-
keting y promocin debido a los efectos de la estrategia y las tcticas em-
presarial que vemos en las redes sociales, unos efectos a veces buenos y a
veces malos, pero que no atacamos mirando hacia las causas de los pro-
blemas que vemos en estas redes y que al final se encuentran en las estra-
tegias y sistemas que estn por debajo. No podremos, por ejemplo, gestio-
nar las reservas online de nuestro hotel o pretender introducirnos en cana-
les de comercializacin online, si por debajo gestionamos las reservas y la
16
Introduccin
ocupacin de nuestro hotel en un libro fsico de reservas. O tal vez poda-

mos hacerlo al principio, pero con un poco de volumen de reservas que
tengamos, con sus cancelaciones, pre-reservas y anulaciones, la gestin de
stas se volver ingestionable y no produciremos ms que insatisfaccin en
nuestros clientes y serios problemas dentro de nuestra empresa, difciles de
solucionar por muchas campaas de comunicacin que hagamos y que da-
arn seriamente la imagen de nuestra empresa en un entorno tan compe-
titivo como el de las reservas hoteleras online. Lo mismo cabe decir de mu-
chas plataformas de comercio electrnico, donde internet les ha lanzado a
vender online, o sea, a vender en cualquier parte del mundo o un territorio
donde el volumen de clientes y su diversidad es mucho mayor, por lo que
muchas empresas han fracasado al no disponer de sistemas informticos,
de gestin logstica o capacidad de atender las demandas de los clientes.
Pero no son slo los modelos de internet los que descubren estas ineficien-
cias, sino tambin los modelos organizacionales y culturas empresariales.
Hoy ninguna empresa puede prescindir de la tecnologa y en muchos otros
casos, los proyectos tecnolgicos han fracasado al pretender implementar
soluciones y tecnologas avanzadas sobre modelos de negocio y filosofas
organizacionales ms propias del siglo XIX, sobre las que la automatizacin
y la tecnologa, no ha hecho otra cosa que automatizar y replicar esas inefi-
ciencias.
Las necesidades de acceso a la informacin, de interconexin de datos y

aplicaciones entre empresas, clientes, partners y colaboradores, se han
convertido tambin en un prerrequisito para cumplir con los requerimien-
tos de prcticamente cualquier tipo de negocio y han provocado el desarro-
llo de nuevas arquitecturas informticas como arquitecturas orientadas a
servicios y aplicaciones en la nube, heredadas de los sistemas Middleware,
y que los sistemas BPM recogern en su arquitectura, no slo para dar res-
puesta a estas necesidades de almacenamiento, gestin y comparticin de
datos, sino tambin para darles su razn de ser, la cual vendr dictada por
la lgica de los procesos de negocio sobre los que se sustenta la organiza-
cin, pues sin un contexto para la interpretacin de estos datos y un prop-
sito, no tendrn valor ni sern de utilidad para la organizacin, sus clientes
y colaboradores.
Con BPM se reduce el distanciamiento entre negocio y tecnologa y las

personas de estos dos mundos, encontrarn en BPM un punto en el que
trabajar conjuntamente en el diseo de procesos. Ya no hablamos de apli-
caciones, departamentos y tareas independientes, sino de procesos. Todo
est enlazado, aplicaciones, sistemas, datos, personas, procesos y tecnolo-
17
gas. La informtica ha cambiado de las estructuras de datos a la estructura

de procesos.
BPM presenta muchas ventajas para las organizaciones que decidan

adoptarla en trminos de flexibilidad y capacidad de adaptacin al cambio,
reduccin de costes, eficiencia, integracin, visibilidad y control de los pro-
cesos y resultados operacionales, pero requerir de una serie de retos y
condiciones para poder realizar esta transicin.
En primer lugar las empresas debern reconocer a los procesos como ac- /RVSURFHVRVVRQ$FWLYRV
tivos fundamentales de la empresa para aportar valor a sus clientes. Que )XQGDPHQWDOHVGHOD
estos procesos son transversales a la organizacin y atraviesan mltiples HPSUHVD
unidades de negocio, departamentos y sistemas informticos de la organi-
zacin, por lo que ser necesario el intercambio de informacin entre los
mismos y romper con los silos departamentales y de informacin, afron-
tando sin tapujos el reto de convertir las organizaciones departamentales y
orientadas a funciones en organizaciones orientadas a clientes y a procesos.
La perspectiva de BPM exigir tambin del alineamiento de negocio y

tecnologa, de forma que ambos aspectos de la organizacin y las personas
que los integran, colaboren conjuntamente en el diseo e implementacin
de los procesos de negocio de la organizacin, rompiendo con el tradicional
aislamiento existente entre estos dos mundos.
BPM requerir tambin de un compromiso con las personas, pues stas

sern al final las que utilizarn los procesos y ejecutarn las actividades
especificadas en los mismos para que estos funcionen y por ello BPM pres-
tar especial atencin a este aspecto as como al del liderazgo de estas per-
sonas en los proyectos que emprendamos. Deberemos asumir tambin un
compromiso con las metodologas de gestin de proyectos que garanticen
el buen gobierno de los proyectos, con la necesidad de innovacin y la
adaptacin al cambio como algo natural e intrnseco a las organizaciones.
Este carcter multidisciplinar, requerir de nuevos roles relacionados

con la gestin de procesos y con BPM, as como la adaptacin de muchos de
los roles existentes en las organizaciones a esta disciplina, exigindose de
los trabajadores, que conozcan no slo las tareas bajo su responsabilidad o
de su departamento concreto, sino que tengan una visin general de todo
el proceso de negocio que genera valor para el cliente.
Este libro refleja la naturaleza holstica de BPM desde un planteamiento

de creacin de valor hacia el mercado y sus clientes, la cual comienza con la
18
Introduccin
empresa como Sistema y con los Modelos de Negocio y Arquitecturas Em-

presariales que sustentan la estrategia de la empresa, contina con el sis-
tema de creacin de valor, el diseo de los procesos que soportarn esa
estrategia y finalmente las tareas y actividades que ejecutarn el diseo
realizado en los procesos. En este camino, se repasan teoras como TQM,
Six Sigma o la Reingeniera de Procesos, sobre las que se asientan las bases
tericas de BPM. La Cadena de Valor, los Modelos de Negocio, las Arquitec-
turas Empresariales o la evolucin de las Tecnologas de la Informacin (TI).
Se estudian entre otros, distintos frameworks y estndares de negocio co-
mo SCOR o TOGAF, el BMM (Business Motivation Model), la notacin BPMN
(Business Process Model Language) para el modelado de procesos, los sis-
temas BPMS (Business Process Management Systems) y las arquitecturas
tecnolgicas como SOA, sobre las que basar nuestros proyectos de BPM.
Pero adems, aadimos disciplinas como la gestin de la Innovacin, la
Teora de las Limitaciones (TOC) de Goldratt , metodologas de gestin de
proyectos as como otras disciplinas relacionadas: el pensamiento sistmico
o la impredecibilidad inherente a todo proceso empresarial, como concep-
tos importantes y relacionados a la hora de gestionar nuestros procesos y
proyectos en BPM. Este recorrido permitir que el lector comprenda como
enfocar el anlisis y diseo de procesos as como la estrategia para gestio-
nar unificadamente Procesos, Personas y Tecnologas y tomar las riendas de
nuestros negocios a travs de la gestin de sus procesos y el control de sus
resultados.
El libro se dirige a estudiantes y profesionales interesados en BPM: res-

ponsables de calidad, de organizacin, de procesos, de innovacin y de
sistemas. Consultores, jefes de proyecto, analistas y empleados de diferen-
tes reas de la empresa que busquen gestionar sus organizaciones de una
forma mucho ms integrada a travs de una visin de las organizaciones
centrada en los procesos, como palanca sobre la que actuar para conseguir
agilidad empresarial, mejorar sus resultados y adaptarse al cambio.
Mi objetivo no es adoctrinar sobre esta materia y convertirla en un

dogma o en la nueva sigla de moda, sino acercar al lector al pensamiento
de la organizacin orientada a procesos, para una vez visualizada esta pers-
pectiva, que el lector pueda comprobar sus potencialidades a travs de las
capacidades de modelizacin (desvelar como funcionan nuestros procesos
de negocio), mejorar nuestros procesos actuales, realizar simulaciones (de
datos y escenarios para saber cmo se comportarn los prototipos de pro-
cesos que diseemos) y las capacidades de control y monitorizacin de
procesos que nos permitirn analizar de nuevo estos procesos para volver a
19
mejorarlos. El lector entender como enfocar metodolgicamente el anli-

sis y diseo de procesos as como la estrategia para gestionar unificada-
mente procesos, personas y tecnologas, involucrar la estrategia en el dise-
o de procesos, detectar fuentes de ventaja competitiva y oportunidades
de mejora en los procesos antes de proceder a su automatizacin, realizar
el diseo y modelado de procesos en la notacin BPMN y desplegar solu-
ciones BPM con las plataformas BPMS.
El reto formativo es grande, pues BPM es multidisciplinar y requerir de

conocimientos en distintas materias relacionadas, tanto de gestin de ne-
gocios como de aspectos tcnicos, adems de la adopcin de nuevas habili-
dades, tcnicas, herramientas y filosofas de gestin, como la negociacin,
la gestin de personas, de proyectos y la gestin del cambio, que de forma
holstica, nos permitirn entender qu hacemos, como camino para mejo-
rar y dirigirnos hacia nuestros objetivos empresariales.
Este libro ha sido el resultado de la preparacin de distintos cursos de

formacin en BPM para distintos organismos pblicos y privados, que co-
menzando como breve manual para estos cursos, ha evolucionado a medi-
da que profundizaba en esta materia y creo que servir tanto para iniciarse
y disponer de una perspectiva global de BPM, como para preparar el exa-
men de certificacin OCEB (OMG Certified Expert in BPM) de OMG (Object
Management Group).
20
Introduccin
Acerca de la Certificacin OCEB.

La certificacin OCEB (OMG Certified Expert in Business Process Mana-
gement) otorgada por OMG (Object Management Group) es la ms presti-
giosa certificacin actualmente en el campo de BPM (Business Process Ma-
nagement Gestin de Procesos de Negocio). El programa OCEB consiste
en cinco exmenes que conceden cinco certificaciones y donde cada nivel
tiene su propio examen.
El primer examen cubre los elementos bsicos y los puntos esenciales

en: Gestin de Negocio, Modelizacin de Negocio, Gestin de Procesos de
Negocio, Modelizacin de Procesos y los frameworks y estndares ms
utilizados en la industria. Los que consiguen la certificacin OCEB Funda-
mental, han demostrado que poseen el conocimiento y las habilidades de
modelizacin para ser miembros de un equipo de proyecto BPM, tanto
desde el punto de vista de negocio como tcnico.
El examen se realiza online a travs de un centro Pearson VUE. El conte-

nido del examen est en ingls. El examen contiene 90 preguntas y dura 90
minutos (en Espaa la duracin se alarga hasta 120 minutos por razones
lingsticas).
21
Estructura del libro
ESTRUCTURA DEL LIBRO

La primera parte del libro est formada por tres captulos en los
que se introducen una serie de conceptos y teoras importantes previas a la
introduccin del concepto de BPM.
Captulo 1: La gestin de procesos.
Este captulo comienza describiendo los sistemas y las organizacio-

nes como sistemas. BPM involucra una gran cantidad de mdulos, solucio-
nes software, disciplinas de management y otras tcnicas y herramientas
que nos harn ver la empresa como un sistema formado por distintas par-
tes y que slo tendrn sentido y aportarn valor bajo la perspectiva de la
organizacin como un sistema cuyo resultado es mayor que la suma de sus
partes por separado. Los modelos y arquitecturas empresariales que vere-
mos en el resto de captulos, se basarn en la premisa de entender la orga-
nizacin como un sistema, que existe para producir una salida de valor y la
necesidad de adaptacin al medio en el que se desenvuelve. Veremos dis-
tintas caractersticas de los sistemas que nos ayudarn a comprender su
comportamiento, las bases del pensamiento sistmico y el indeterminismo
como entorno tanto de la teora general de sistemas como filosofa alrede-
dor de la cual giraran bastantes aspectos de BPM. Se describen en este ca-
23
ptulo las bases de la Gestin de Procesos, sus caractersticas y propiedades,

como identificarlos, clasificarlos y mejorarlos y la importancia de su correc-
to diseo, ejecucin y monitorizacin de forma que estos sean lo ms efi-
cientes posibles. Al final del captulo se hace un repaso a las principales
tcnicas y herramientas estadsticas utilizadas en la gestin y control de
procesos y que constituirn la base para la toma de medidas y estableci-
miento de indicadores de rendimiento y eficiencia de los procesos para el
posterior monitorizacin, anlisis y mejora de los procesos en BPM.
Captulo 2: Los caminos hacia BPM.
BPM puede ser visto como las ramas de un rbol cuya parte visible
se levanta frondosa pero que se sustenta en sus races subterrneas, las
cuales le proporcionan la estabilidad y elementos vitales que necesita y que
sern las que veremos en este captulo, en el que realizaremos un repaso
histrico de las principales ideas sobre eficiencia organizacional sobre las
que se basa BPM, a fin de entender cmo se ha llegado hasta esta teora de
gestin por procesos de negocio. Estas races son las Teoras de Organiza-
cin de Adam Smith, Frederick Taylor y Henry Ford, la Teora de la Calidad
total (TQM), Six Sigma, la Reingeniera de Procesos de Negocio (BPR, en
ingls) y la Teora de las Limitaciones (TOC) de Goldratt. Finalmente acaba-
remos esta revisin histrica poniendo de manifiesto como en todas estas
teoras subyace la orientacin a procesos y la necesidad de un modelo de
gestin que tome los procesos como base y condicin imprescindible para
el diseo y gestin de modelos empresariales de xito, adecuados a las
necesidades actuales de unos clientes cada vez ms exigentes y necesitados
de mayores innovaciones que slo podrn ser satisfechas a travs de la
capacidad de nuestra empresa de adoptar e implementar esos cambios.
Captulo 3: Tecnologa, Innovacin y Modelos de Negocio.
Este captulo resume la evolucin de las Tecnologas de la Informa-

cin (TI) para comprender la evolucin de estos sistemas y tecnologas y
cmo a lo largo de los ltimos aos, estas han realizado el acercamiento y
las adaptaciones necesarias hacia los aspectos de negocio hasta converger
finalmente en BPM como disciplina y los BPMS (Business Process Manage-
ment Systems) como la tecnologa software que los hace posible. Dedica-
mos un apartado tambin a la innovacin, de vital importancia para la ges-
tin del cambio, la diferenciacin y la bsqueda de ventajas competitivas y
que estar estrechamente ligada a la mejora de procesos. Para finalizar
24
veremos la importancia de los modelos de negocio sobre los que se susten-

tarn las estrategias, las tcticas, las metas y los objetivos empresariales
que conformarn el diseo de nuestros procesos y que segn lo creativos e
innovadores que hayamos sido en el diseo de estos modelos, depender el
xito o fracaso de la empresa.
En la segunda parte del libro, se introduce la disciplina de BPM as

como al modelado de negocios y de procesos a travs de diferentes meto-
dologas y estndares.
Captulo 4: BPM (Business Process Management)
De la convergencia de las teoras de gestin de las organizaciones y

de la tecnologa, surge una nueva forma de ver la empresa bajo el prisma
de los procesos. Bajo la mirada de este prisma surgir una nueva teora, el
BPM, a travs de la cual podremos disear, modelar, implementar y medir
los procesos de negocio de nuestra organizacin para la mejora del rendi-
miento, la eficiencia y la excelencia empresarial. Este captulo nos introduce
el concepto de BPM con sus principios y ventajas. Estudiaremos el ciclo de
vida de BPM y los componentes principales sobre los que se asienta esta
disciplina y veremos importantes aspectos relacionados con BPM como la
organizacin orientada a procesos, el pensamiento sistmico, estudiaremos
los cinco niveles del modelo de madurez de BPM, el papel que deben jugar
los departamentos de TI dentro de esta nueva visin empresarial y como a
travs de BPM podemos reducir el distanciamiento existente entre negocio
y tecnologa.
Captulo 5: Modelado de Negocios.
En este captulo abordamos el diseo de modelos y arquitecturas

de negocio a partir de la estrategia empresarial, como paso previo a la de-
finicin de los procesos operativos que ejecutarn la estrategia. La reco-
mendacin ser la de comenzar los proyectos por la visin y la estrategia y
alinear sta con los procesos en una estrategia Top-Down. Repasaremos la
importancia de la creacin de valor a nuestros clientes y la bsqueda de
ventajas competitivas sostenibles a travs de la cadena de valor de Porter y
los distintos niveles de detalle (estratgico, tctico y operacional), con los
que describir nuestros procesos de negocio. Veremos las arquitecturas em-
presariales que nos permitir alinear negocio y tecnologa y dentro de ellas
diferentes estndares, frameworks y modelos de referencia como TOGAF,
que nos ayudarn en la especificacin de nuestros procesos de negocio.
Para finalizar, analizaremos el BMM (Business Motivation Model) como
25
estndar de OMG (Object Management Group) para el establecimiento de

la estrategia empresarial.
Captulo 6. Modelado de procesos. BPMN.
Este captulo se dedica ntegramente a la descripcin de la notacin

BPMN (Business Process Model Notation) como estndar para la descrip-
cin de procesos. A lo largo del captulo se describen los distintos elemen-
tos que forman parte de BPMN y se muestran ejemplos de su utilizacin en
distintos escenarios de forma que el lector pueda a travs de esta notacin,
implementar distintos tipos de procesos en base a los ejemplos y plantillas
de uso ms comn.
La tercera parte del libro se ocupa de la implementacin de un pro-

yecto BPM y los puntos que debemos considerar en esta implementacin.
Si antes hemos visto como alinear la estrategia con los procesos ahora ali-
nearemos los procesos con la tecnologa a travs de las herramientas BPMS
(Business Process Management Systems) que utilizaremos para implemen-
tar los proyectos de BPM.
Captulo 7. Implementacin de BPM.
Este es el captulo ms extenso del libro, pues en el recopilamos to-

do lo visto con anterioridad de una forma prctica y dirigida hacia la im-
plementacin de un proyecto de BPM. En base a un ciclo de aprendizaje y
mejora continua, describimos las distintas fases de este ciclo de implemen-
tacin, las actividades y herramientas a utilizar en cada fase, los objetivos a
alcanzar en cada fase e indicaremos las tareas de gestin de proyecto ms
importantes que deberemos considerar en cada una de ellas. Al final del
captulo hablaremos un poco ms de la importancia de la gestin de pro-
yectos y describiremos algunas de las reas de esta disciplina que deben ser
gestionadas globalmente para todo el proyecto, independientemente de la
etapa del mismo en que nos encontremos y veremos los principales facto-
res crticos de xito para un proyecto de BPM.
Captulo 8. Tecnologa BPM. BPMS.
En este captulo describiremos los BPMS (Business Process Mana-

gement Systems) y las tecnologas y arquitecturas informticas que hacen
posible la implementacin de estas soluciones. Entenderemos la evolucin
de las plataformas de workflow y sistemas EAIs y Middleware y su conver-
gencia en los BPMS. Atendiendo al ciclo de vida de los procesos, se descri-
26
ben los principales mdulos de estos sistemas: el modelador grfico de

procesos, el entorno de integracin con aplicativos y sistemas informticos,
el servidor de procesos, la ejecucin de los procesos y su simulacin y la
monitorizacin de los procesos implementados. El captulo termina con un
repaso a la arquitectura SOA (Service Oriented Architecture) y su sinergia
con BPM.
Para entender como se ha llegado a BPM, representamos en forma

de rbol los principales conceptos, teoras, estndares, modelos y herra-
mientas que han conducido a BPM y que desarrollaremos a lo largo del
presente libro.
27
PARTE 1. FUNDAMENTOS DE
LA GESTIN POR PROCESOS
Cap. 1. La gestin por procesos.

Cap. 2. Los caminos hacia BPM.
Cap. 3. Tecnologa, Innovacin y Modelos de Negocio.
Captulo 1. La gestin de procesos
Captulo 1. La gestin de procesos.
La empresa como sistema.
Uno de los principios fundamentales de BPM es que los procesos de ne-

gocio son activos fundamentales de la empresa para aportar valor a nues-
tros clientes y que analizando, midiendo y controlando estos procesos,
podemos proveer a nuestra organizacin de mejora continua y flexibilidad
en la adopcin del cambio. Vamos ahora a visualizar y entender una organi-
zacin desde el prisma de BPM. La idea fundamental es pensar en nuestra
organizacin como una organizacin orientada a procesos, donde dejare-
mos atrs la visin departamental de la misma, en la que cada departamen-
to tiene sus propias funciones y responsabilidades. Para ello, pensaremos
holsticamente, es decir, pensaremos en la organizacin como un todo, en
el que las actividades y departamentos de nuestra organizacin estn rela-
cionados unos con otros en un sentido lgico y con el nico objetivo de
alcanzar unos objetivos de negocio y proveer de valor a nuestros clientes.
En esta visin, veremos los procesos de negocio como un conjunto de acti-
vidades y decisiones que se inician por la ocurrencia de un evento especfi-
co y que ejecutadas de forma coordinada, permiten alcanzar ese objetivo
de negocio. BPM (Business Process Management) o gestin por procesos de
negocio, es una disciplina de management (gestin) que se basa en la coor-
dinacin y colaboracin de todas las actividades y tareas necesarias para
realzar un proceso de negocio que entiende que diseando, analizando,
31
gestionando y monitorizando los procesos que opera nuestra organizacin,

podemos influir sobre ellos y en consecuencia sobre sus resultados.
El no centrarnos en las partes o reas funcionales del sistema por sepa-

rado, como cadenas de causa-efecto y centrarnos por el contario en el con-
junto, en el estudio de las relaciones e interacciones entre las partes del
sistema, nos permitir extraer propiedades esenciales y caractersticas que
no tienen las partes del sistema cuando las consideramos aisladamente, y
nos conducir a esta visin holstica y sistmica, que nos introducir en el
cambio de paradigma que implicar BPM.
Por definicin, un sistema es algo compuesto por partes independientes,

cuya existencia se mantiene a travs de la interaccin mutua entre las par-
tes que lo componen y en el que la comprensin de estos sistemas, slo se
produce cuando se estudian globalmente. Esta teora aplicada al mundo de
la organizacin empresarial, significa que una empresa est compuesta por
una serie de partes, pero que del anlisis de estas partes, no podemos ex-
plicar suficientemente el funcionamiento de toda la empresa. Es decir, que
aunque nuestra empresa tenga un magnfico departamento de produccin,
pero esta falla en la venta de sus productos, no servir de nada lo bien que
produzcamos nuestros productos, pues estos no llegarn a los clientes que
deberan pagar por ellos y nuestra empresa fracasar estrepitosamente.
De la Teora General de Sistemas (TGS), los sistemas se clasifican en sis-

temas abiertos y cerrados. Los sistemas abiertos, son aquellos que se co-
munican con el entorno y que precisan de ste para subsistir. De este en-
torno, los sistemas abiertos reciben una serie de entradas (recursos finan-
cieros, recursos humanos, materias primas, electricidad, etc.), que a travs
de unos procesos de transformacin, convierten estas entradas en unas
salidas que devuelven al entorno en forma de servicios o productos termi-
nados y que suelen adems convertirse en entradas para otros sistemas.
Los sistemas cerrados, por el contrario, son aquellos autosuficientes, que
no precisan de realizar intercambio con el entorno para subsistir, y esta
caracterstica los hace ser determinsticos, es decir, que conociendo su es-
tado en un momento determinado, podemos predecir su estado futuro. La
visin de la organizacin como sistema cerrado y determinstico ha sido la
visin de la teora estructuralista tradicional, sin embargo, los sistemas em-
presariales no son cerrados y determinsticos, sino abiertos, probabilsticos,
dinmicos e indeterminados y al igual que los seres humanos que gobiernan
estos sistemas, slo pueden aspirar a una racionalidad limitada, debido a la
incertidumbre de un entorno en el que no podemos disponer de toda la
32
informacin. Estos sistemas abiertos marcarn el entorno en el que nos

movamos en el presente libro, pues comparten con las organizaciones mu-
chas propiedades y caractersticas que sobrevolaran a lo largo del libro, las
cuales describiremos para ayudar a entender este tipo de sistemas y su
comportamiento.
Holismo:
El todo es superior a las suma de las partes, el sistema no puede expli-

carse sino en su totalidad. Las organizaciones son partes de una sociedad o
sistema mayor y frecuentemente son vistas como sistemas dentro de sis-
temas mayores o sper-sistemas, formando un todo que no puede ser
comprendido tomando las partes independientemente y donde el cambio
en una de las partes del sistema afectar al todo. Esta visin holstica globa-
lizadora que toma en cuenta la interaccin entre las partes, se opone al
enfoque analtico tradicional y ser un concepto muy ligado a la disciplina
de BPM.
Retroalimentacin:
La retroinformacin es una caracterstica indispensable para la supervi-

vencia de los sistemas abiertos y para que estos puedan desarrollarse en su
entorno modificando su comportamiento en funcin de las exigencias del
entorno. La retroalimentacin (feedback, en ingls), se produce cuando las
salidas del sistema vuelven a ser entradas del sistema, permitiendo el con-
trol por parte del mismo, para que este tome medidas de correccin en
base a la informacin retroalimentada. La retroalimentacin constituye el
concepto fundamental sobre el que se basar otro aspecto importante en
BPM como es la automatizacin.
En la retroalimentacin, la salida de un proceso puede modificar o influir

en aquello que lo causa y por las propiedades de los sistemas, si un elemen-
to modifica su condicin, se modificar en consecuencia las condiciones de
los dems elementos que componen el sistema y en consecuencia tambin
el conjunto del sistema, por lo que la operativa en la retroalimentacin
deber ser de tal forma que el sistema regule las entradas en funcin de la
33
informacin producida por la retroalimentacin y de esta forma, ajustar las

salidas a los criterios y estndares establecidos o deseados en lo que de-
nominamos un bucle de retroalimentacin.
Existen dos tipos de retroalimentacin:
- Retroalimentacin negativa: cuando el sistema se desva de su nor-

mal comportamiento, la retroalimentacin advierte de esta varia-
cin al sistema y toma las medidas necesarias para corregir su com-
portamiento.
- Retroalimentacin positiva: ms proactiva que la negativa, y que ac-
ta sobre las entradas para prevenir desviaciones en la salida. Este
tipo de retroalimentacin tambin se denomina Feed-forward
(alimentacin hacia delante, en espaol) donde el control se realiza
a la entrada del sistema, asegurndonos de que este no tenga en-
tradas corruptas o malas y de esta forma, los errores no sern con-
secuencia de las entradas sino de los procesos mismos que compo-
nen el sistema. Esta retroalimentacin positiva ser la que permita
la transformacin radical en las organizaciones.
Trasladando la retroalimentacin de los sistemas a los procesos, po-

demos presentar un grfico ms elaborado del comportamiento de los
procesos en el que vemos la retroalimentacin circulando de los clientes
y partners al proceso as como del proceso a los proveedores para opti-
mizar las entradas:
Entropa:
La teora de sistemas toma este concepto de la segunda ley de la Ter-

modinmica para medir el equilibrio de un sistema. La entropa es la ten-
dencia natural de los sistemas a consumirse, desorganizarse y morir, y me-
34
dir el desgaste que el sistema presenta por su funcionamiento en el trans-

curso del tiempo. Debido a la entropa, los sistemas deben ser permanen-
temente controlados debido a la tendencia natural de estos a aumentar su
entropa y el grado de desorden cuando son dejados a su aire. A diferen-
cia de los sistemas cerrados, en los cuales la entropa es siempre positiva,
en los sistemas abiertos sta puede ser estabilizada o reducida a travs del
intercambio con el entorno, por lo que para sobrevivir, las organizaciones
deben asegurarse una provisin continua de entropa negativa en forma de
recursos materiales y humanos.
Morfognesis:
Relacionado con la retroalimentacin y el aumento de entropa, algunos

sistemas disponen de la capacidad de modificar sus estructuras bsicas para
adaptarse al entorno y sobrevivir en l y es por ello, una de las principales
caractersticas identificadoras de los sistemas abiertos.
Neguentropa:
Como fuerza que se opone a la Entropa y a la accin del segundo princi-

pio de la termodinmica, tenemos la Neguentropa, que es el uso de la in-
formacin como medio o instrumento para producir mayores niveles de
orden y aumentar las probabilidades de supervivencia de los sistemas
abiertos.
Cuando aadimos informacin a un sistema, lo que estamos haciendo es

ordenando los elementos que lo componen, de forma que a travs del in-
tercambio de informacin con el entorno, el sistema se auto-regula, orde-
nando y controlando la tendencia al caos, a diferencia de los sistemas ce-
rrados, sin intercambio de informacin con su entrono y que acaban mu-
riendo debido al aumento de la entropa, del desorden y el caos. Las herra-
mientas de gestin de la informacin desempearn un importante papel
en esta tarea de reducir la entropa y la mejora de la eficiencia de la organi-
zacin, tanto a nivel de procesos y recopilacin de datos para ser converti-
dos en informacin como a nivel de la necesaria comunicacin de la visin y
misin de la organizacin desde el nivel estratgico y directivo a los niveles
intermedios y ms bajos de la misma.
Recursividad:
Concepto muy utilizado en matemticas y computacin y que se refiere

a cmo obtener conceptos nuevos empleando el mismo concepto que in-
35
tenta describir. La recursividad la utilizamos para resolver problemas redu-

ciendo estos a uno o ms sub-problemas que son idnticos en su estructura
al problema original, pero ms simples de resolver. Se dice que un proceso
es recursivo si forma parte de s mismo, es decir, se define en funcin de s
mismo.
Isomorfismo:
Que significa de igual forma, para referirse a la construccin de mode-

los de sistemas similares al original, pudindose reducir el estudio de un
sistema al estudio de su isomorfo, pues los principios que rigen el compor-
tamiento de uno en algunos aspectos pueden regir el comportamiento de
otro.
Homomorfismo:
Concepto similar al anterior pero en el que dos sistemas son iguales pero
slo probabilsticamente. Este modelo se aplica en sistemas muy complejos
y probabilsticos.
Homeostasis:
Es la propiedad de un sistema que define su nivel de respuesta o adap-

tacin al contexto. La Homeostasis o estado de equilibrio es una caracte-
rstica de los sistemas mediante la cual estos regulan su funcionamiento
interno para mantener una condicin estable y constante de sus variables
(disminuir su entropa), manteniendo el equilibrio por ajuste constante o
anticipacin y cambiando parmetros de su estructura interna mediante
mecanismos de auto-regulacin en los que participan todos los sistemas de
un organismo vivo o de una organizacin. Atendiendo a esta propiedad de
determinados sistemas podemos hablar de un tercer tipo de clasificacin de
los sistemas como adaptativos y que al final del libro describiremos al
hablar de la gestin de casos (Adaptive Case Management).
Teleologa:
O doctrina de las causas finales, es la atribucin de una finalidad u obje-

tivo ltimo a procesos concretos. En la explicacin teleolgica, el resultado
de un sistema se explica por aquello que produce, por sus efectos y no por
sus causas.
36
Equifinalidad:
Es una caracterstica de los sistemas abiertos en los que el resultado

puede alcanzarse por diversos caminos. Existen diversas formas en que los
sistemas pueden producir un resultado u objetivo y en consecuencia mu-
chos sistemas no se caracterizan en su comportamiento por las condiciones
inciales de las entradas para producir unos resultados sino por como dise-
emos el camino en el proceso de transformacin.
Emergencia:
Otra caracterstica importante y que veremos ms adelante en el libro,

es la de la emergencia como una caracterstica de los sistemas complejos
por la cual los elementos ms simples constituyentes del sistema se auto-
organizan para formar sistemas ms complejos.
Ciberntica:
Hemos visto al hablar de la entropa de los sistemas, como estos siguen

la segunda ley de la Termodinmica, segn la cual, estos presentan una
tendencia creciente hacia estados cada vez ms desorganizados o de caos
cuando no existe ninguna intervencin o control sobre los mismos. Vimos
tambin la Neguentropa como el uso del intercambio de informacin para
reducir este desorden. Relacionado con ambos conceptos tenemos la ci-
berntica.
La ciberntica (del griego Kybernos: timn, gobierno, control), se refiere

a los sistemas autnomos capaces de ser guiados o controlados por alguien
o algo fuera del sistema. La ciberntica es la disciplina que estudia la comu-
nicacin y el control en animales y mquinas y su lnea de estudio y trabajo
es como obtener la respuesta deseada de los humanos y de las mquinas a
travs de proporcionar a estos las instrucciones y guas precisas para tomar
futuras acciones mediante mecanismos de control y de autocorreccin,
principalmente a travs de la Retroalimentacin, de forma que contrarres-
temos la tendencia natural hacia la desorganizacin. La circularidad que se
da en la retroalimentacin, ser una caracterstica de todo ser vivo que se
auto-regule o tenga la capacidad de reorientarse o replantearse continua-
mente su funcionamiento para llegar a una meta u objetivo (principio de
equifinalidad), o de mantenerse en unos rangos limitados (principio de
homeostasis), a pesar de verse estos sistemas sometidos a las presiones del
entorno.
37
La ciberntica, desarrollada por Norbert Wiener (1894-1964), estudia los

problemas y comportamientos de la organizacin y los procesos de control
y transmisin de informacin en las mquinas y los seres vivos para permitir
a los sistemas auto-dirigirse, auto-regularse y cambiar de estados en fun-
cin del comportamiento y los cambios en el entorno y de esta forma man-
tener su equilibrio Homeosttico. Wiener pretenda encontrar las razones
que permitan el automatismo en las mquinas al igual que ocurre en los
seres vivos, mediante el control de una mquina por otra a travs de senso-
res instalados en la segunda para retroalimentar a la mquina controladora.
Esta ciberntica de Wiener se basaba en la retroalimentacin negativa para
adaptarse al medio conservando su estructura, pero Magoroh Maruyama
fue un paso ms all al ampliar la ciberntica con la retroalimentacin posi-
tiva y permitir a los sistemas adoptar nuevas organizaciones, transformarse
radicalmente y cambiar sus estructuras (Morfognesis) en lo que ha dado
en llamarse ciberntica de segundo orden.
Los mecanismos de control que utilizan los sistemas cibernticos cons-

tan de cuatro elementos:
- Una meta u objetivo deseado.

- Un mecanismo de medicin del estado actual del sistema.
- Un mecanismo de comparacin.
- La toma de decisiones para emprender acciones que afectarn al
funcionamiento del sistema.
La ciberntica, basndose en los organismos vivos como modelo ideal de

comportamiento, se dedicar al estudio del comportamiento de las mqui-
nas y los seres vivos para producir procesos cada vez ms automticos,
eficientes y adaptables, y en este sentido, estar ntimamente relacionada
con la automatizacin de procesos que veremos a lo largo del presente libro
y con la adaptacin al cambio, hasta tal punto que algunos autores deno-
minan a la ciberntica como la ciencia de control del cambio. Resulta obvio
que si los sensores de nuestra mquina no mostrasen ninguna variacin
(Retroalimentacin nula), el sistema no deber hacer nada y en consecuen-
cia la base de la ciberntica ser el cambio y las variaciones que se produz-
can en el entorno.
Esta propiedad es la que observamos en los conocidos sistemas de au-

tomatizacin industrial denominados SCADA (acrnimo de Supervisory Con-
trol And Data Adquisition), sistemas software para el control y supervisin
de procesos industriales que facilitan la retroalimentacin en tiempo real y
38
el control e intervencin de estos procesos productivos de forma automti-

ca.
Adems de las propiedades ya vistas, otras caractersticas y propiedades

importantes de los sistemas son:
- Sinergia: Es el grado de concertacin de las partes de un sistema.

Expresa el grado de organizacin de los elementos del sistema y es
funcin del tipo de relaciones que los vinculan. Cuanto ms armo-
niosamente un sistema logre su funcin ms sinrgico ser.
- Permeabilidad: La permeabilidad de un sistema mide la interaccin
que ste recibe del medio y en consecuencia a mayor permeabilidad
el sistema ser ms abierto.
- Integracin: Un sistema es integrado cuando un cambio en cualquie-
ra de sus partes produce cambios en las dems partes del sistema.
- Centralizacin: Un sistema se dice centralizado cuando tiene un n-
cleo que dirige a todos los dems y estos dependen para su activa-
cin del primero, ya que por s solos no son capaces de generar nin-
gn proceso. En los sistemas descentralizados este n
- cleo est formado por varias partes del sistema.
- Adaptabilidad: Es la propiedad que tiene un sistema para aprender y
modificar un proceso o estado, a travs de un mecanismo de adap-
tacin y en funcin de las modificaciones del entorno. La adaptabili-
dad no podemos conseguirla sin tener una relacin de intercambio
con el entorno.
- Mantenibilidad: Es la propiedad de un sistema de mantenerse cons-
tantemente en funcionamiento.
- Estabilidad: Un sistema es estable cuando puede mantenerse en
equilibrio a travs del flujo continuo de entradas y salidas del siste-
ma.
- xito: Es la medida en que los sistemas alcanzan sus objetivos.
Sistemas y necesidad de adaptacin al cambio.
En todas las caractersticas y propiedades que hemos visto de los siste-

mas, vemos como para mantener un sistema abierto en equilibrio, debe-
mos luchar constantemente contra el desorden entrpico, reduciendo el
mismo de manera neguentrpica y a travs de una retroalimentacin nega-
tiva, de forma que el sistema no pierda su organizacin. Trasladado a los
sistemas empresariales, es fcil deducir que una de las principales caracte-
39
rsticas de estos sistemas ser el cambio constante, debido a las condicio-

nes del entorno y la influencia que este entorno puede tener sobre el sis-
tema, por lo que la empresa estar obligada a cambiar y adaptarse constan-
temente a este nuevo entorno para alcanzar el equilibrio deseado y poder
sobrevivir.
El cambio existe, no podemos hacer otra cosa que aceptarlo, pues igno-
rarlo nos conducir al fracaso. Ante este cambio, podemos adoptar tres
tipos de posturas o actuaciones, una postura reactiva reaccionando ante
el mismo cuando aparezca, una postura proactiva, anticipndonos al
mismo y previendo la nueva situacin que se avecina para posicionarnos
ventajosamente ante el nuevo entorno o tambin podemos ser nosotros los
inductores del cambio y dirigirlo para convertirnos en los lderes y controla-
dores del cambio. De todas ellas la mejor sin duda alguna es la tercera, pero
esta requiere de experiencia, un fuerte liderazgo y una actitud innovadora
en toda la organizacin, no siempre fcil de conseguir. El poder llegar a esta
ltima posicin es en lo que la disciplina de BPM puede ayudarnos y alre-
dedor de esta idea de adaptacin al cambio de forma gil y flexible, girarn
prcticamente todas las partes y captulos de este libro.
Niveles de Actividad organizacional.
En la concepcin de las organizaciones como sistemas, todos los ele-

mentos de la misma estn conectados e interrelacionados: clientes, pro-
veedores, estructura organizativa, tecnologa, etc. Para poder abarcar esta
comprensin, podemos dividir esta estructura o sistema en tres niveles de
actividad interconectados:
- El nivel organizacional: el cual especifica la estructura bsica y las

funciones que la integran as como el ambiente en el que acta la
organizacin.
- El nivel de procesos: especificar la forma en que se realiza el traba-
jo y se producen los bienes y servicios que la organizacin ofrece a
sus clientes. Este nivel describir el flujo de tareas o secuencia de ac-
tividades necesarias para realizar las funciones de la organizacin.
- El nivel de puesto de trabajo: es el nivel donde los empleados ejecu-
tan las tareas descritas en los procesos de la organizacin. Las per-
sonas y el cmo realicen sus tareas reflejar finalmente la calidad de
la organizacin y los procesos.
40
Los tres niveles son importantes para el xito de nuestra organizacin y

al principio del captulo ya comentbamos que si nuestra empresa es muy
buena en el proceso de produccin, pero no consigue llevar los productos a
sus clientes, la excelencia y los esfuerzos en produccin no sern suficientes
para evitar el fracaso de la empresa como un Todo. De igual manera, la
queja de un cliente puede tener su causa en cualquiera de los tres niveles
que acabamos de describir: un empleado que no cumpli su tarea en el
nivel de Puesto de Trabajo, el mal funcionamiento o diseo de un proceso
interno de la empresa en el nivel de Procesos o la falta de objetivos claros
por parte de la empresa en el nivel Organizacional. Al igual que en los sis-
temas, una empresa no puede ser descrita por sus partes independientes,
la empresa es un sistema abierto y su comprensin se produce al estudiarla
globalmente, por lo que la ineficiencia en uno de los niveles provocar la
ineficiencia del conjunto.
A lo largo del presente libro, nos moveremos continuamente entre estos

tres niveles. Hablaremos de la Estrategia de las organizaciones, de la impor-
tancia de la misma y de la necesidad de disponer de una metas, objetivos y
estructuras organizacionales claras y bien definidas; de las Personas, que
finalmente son las que ejecutarn las tareas definidas en los procesos y de
la correcta gestin de estas personas y su importancia para el xito de la
empresa, pues es en este punto donde fallan muchos proyectos empresa-
riales y de BPM. Y por supuesto, hablaremos tambin de los Procesos y de
estos como nexo de unin entre la estrategia y la ejecucin, siendo en este
nivel de procesos donde centremos toda nuestra atencin, al ser los proce-
41
sos, en ltima instancia, los responsables de cumplir con la estrategia de

nuestra organizacin y de alcanzar los resultados esperados por nuestros
clientes.
Gestin de procesos.
Si definimos un negocio como una serie de recursos humanos, materia-

les y econmicos que organizados en base a una serie de procesos, realizan
unas transacciones que generan un valor al cliente y un beneficio a la em-
presa, podemos extraer que un proceso, al igual que los sistemas, es un
conjunto de actividades que recibiendo una serie de entradas (inputs) pro-
duce unas salidas (outputs) que producen un beneficio para la organizacin
que ejecuta el proceso y generan un valor a quin recibe esas salidas.
El que un trabajo o serie de pasos operativos necesarios para realizarlo,

se puedan describir como un proceso que podemos mejorar, no es algo
nuevo y casi sin pretenderlo, este procedimiento se ha ido imponiendo en
todas las prcticas de gestin empresariales de los ltimos aos. La gestin
de procesos ha estado siempre presente a lo largo de la historia de la ges-
tin moderna de las organizaciones y de alguna forma, todas las empresas
se estructuran entorno a procesos ms o menos formales.
En la poca de Frederick Taylor y hasta bien entrado el siglo XX, los pro-
cesos se perciban como acciones independientes dentro de reas funciona-
les de la organizacin, relacionados por un principio de causa-efecto para
producir un determinado producto o servicio. Con el desarrollo de las dis-
tintas teoras y prcticas de gestin empresarial, el escenario ahora es el de
una visin holstica de los procesos de negocio y su reconocimiento como
claves para lograr la eficiencia operacional, la excelencia, la mejora conti-
nua, la adaptacin al cambio y en definitiva el xito empresarial. Esta evolu-
cin ha dado origen a una disciplina especfica para la gestin por procesos
denominada BPM.
En el da a da de nuestras organizaciones, no pensamos en cmo reali-

zamos el negocio en nuestra empresa. Por ejemplo, si queremos crear una
empresa para vender tomates y obtener un beneficio con ello, hemos de
disear los procesos que ejecutar esa empresa para producir valor a sus
clientes, es decir, el beneficio lo obtenemos a travs de una serie de tran-
sacciones para las cuales diseamos los procesos que han de soportar esas
42
transacciones: compramos las semillas, preparamos la tierra, plantamos las

semillas, regamos y despus y si el tiempo nos acompaa, recogemos los
tomates, los almacenamos y distribuimos a nuestros clientes obteniendo un
beneficio. Una vez diseados estos procesos que nos conducirn a poder
vender los tomates, adquirimos los recursos econmicos y materiales nece-
sarios para poder ejecutar todos estos pasos as como contratar a las per-
sonas que nos harn falta para poder realizar las tareas asociadas a estos.
Este negocio de tomates, aunque ideal, no es trasladable a la gran mayora
de negocios que operan hoy en da, ni resultarn tan obvios en su ejecu-
cin, ni tan siquiera para un negocio de venta de tomates, dominado por las
grandes cadenas de alimentacin y donde vender tomates obteniendo un
beneficio por ello puede resultar hasta ilusorio. Sin pretender desalentar a
nadie que desee cultivar y vender tomates, la realidad es que los procesos,
funciones y secuencias de tareas que debemos ejecutar para crear valor y
cmo debemos ejecutar estos procesos, son cada vez ms complejos y ocu-
rren cada vez ms, fuera de los lmites de nuestra empresa, por lo que re-
queriremos de mejores funciones, ms optimizadas y eficientes as como de
procesos cada vez ms complejos, para poder llevar nuestro negocio a buen
puerto.
La gestin por procesos ha surgido como una forma de dominar esta

creciente complejidad a partir de una serie de teoras y prcticas de gestin
que comenzando con Adam Simith y su teora de la especializacin del tra-
bajo, llegan hasta nuestros das, pasando por las teoras de la calidad total,
six sigma, la reingeniera, las tecnologas de la informacin (TI) y un largo
etctera que veremos en el siguiente captulo.
Los procesos en la poca industrial, fueron utilizados para la mejora de

la eficiencia en entornos de produccin y fabricacin, pero han evoluciona-
do hacia la bsqueda de la mejora en los niveles tcticos y estratgicos, en
los cuales, mucho ms que en los niveles operacionales, radican las posibili-
dades de mejora de los resultados empresariales. El poner el foco no slo
en los resultados operacionales, tradicionalmente asociados a metodologas
como Six Sigma, sino tambin en los estratgicos, nos conducir a la nece-
sidad de alinear el diseo de los procesos con los modelos de negocio. Ve-
mos pues como los procesos son algo intrnseco a las empresas, aunque no
siempre sean percibidos como tales, y que estas no hacen otra cosa sino
ejecutar procesos de negocio, que pueden estar ms o menos diseados y
automatizados, pero lo que si sabemos con certeza, es que las empresas
deben ejecutar estos procesos y gestionarlos, lo cual implica disearlos de
acuerdo a los modelos de negocio, vincular a los actores que participan en
43
los mismos y seguir la evolucin de los indicadores de negocio asociados a

estos procesos.
En este primer captulo nos centramos en la base de la teora de proce-

sos y en cmo estos conforman lo que nuestra organizacin hace y cmo lo
hace, hasta el punto que podemos decir que una empresa es tan eficiente
como lo son los procesos que sta opera.
El poner el foco en los procesos de negocio y la importancia de centrar la

atencin en estos, fue apareciendo de forma gradual a medida que se avan-
zaba en los modelos organizativos y de gestin empresarial, por su capaci-
dad de responder a los requisitos del mercado y atender a los cambios que
se producen en el entorno de la empresa. De esta forma, en cada avance y
evolucin en las prcticas de gestin empresarial y en cada evolucin de los
mercados, estas teoras se fueron aproximando cada vez ms hacia la idea
de centrase en los procesos de negocio, al principio, viendo los procesos de
forma individualizada y centrando la atencin sobre aquellos de mayor im-
portancia para la operativa de las empresas, generalmente los procesos
relacionados con la produccin y manufactureros, para ms tarde, pasar a
un pensamiento integral de la empresa, vista como un sistema, en lo que se
ha venido en llamar process thinking o pensamiento orientado a proce-
sos, que ve la empresa de forma holstica (el todo es ms que la suma de las
partes que lo componen) y que conforma la organizacin orientada a pro-
cesos.
Desde la poca de la produccin en masa, se ha establecido una cultura

empresarial encaminada a producir el mayor nmero de unidades de pro-
ducto en el menor tiempo y con el menor coste posible. Para alcanzar estos
niveles de productividad, las organizaciones han sido gestionadas de acuer-
do a principios basados en la divisin del trabajo y la especializacin en
departamentos o unidades funcionales, en las que el organigrama organiza-
cional estableca la cadena de mando de forma descendente, las mquinas
marcaban el ritmo de produccin y las personas se agrupaban en departa-
mentos segn el tipo de trabajo que realizasen. Esta divisin configur em-
presas departamentales o funcionales, ms preocupadas de los objetivos de
sus departamentos que de los flujos y procesos de negocio que atraviesan
toda la organizacin y cuyo resultado es el que finalmente perciben los
clientes. En la nueva visin de la orientacin a procesos, esta organizacin
jerrquica no nos permitir producir mejoras hacia unos clientes que no
podemos situar en ningn punto de nuestro diagrama organizacional, pues
44
las unidades departamentales rompen la secuencia de actividades que pro-

ducen valor a estos clientes.
Para romper con esta orientacin a funciones y antes de dirigirnos hacia

BPM y la organizacin orientada a procesos, que sern dos de los aspectos
fundamentales de este libro, podemos realizar una aproximacin a este
entorno, viendo los departamentos como sistemas o procesos con sus res-
pectivas entradas, salidas, procedimientos internos y con sus clientes y pro-
veedores, que pueden ser internos (otros departamentos) o externos (don-
de pueden estar incluidos los clientes finales).
Ampliando ms el estudio, podemos simplificar todava ms esta visin

organizacional y reducirla a uno o varios procesos transversales, que sern
los procesos de negocio centrales de la empresa, sobre los cuales aadire-
mos y estableceremos las mismas relaciones cliente-proveedor, con los
procesos de apoyo (financiero, recursos humanos, tecnolgicos, etc.) que
aunque no aporten valor al cliente final, sern necesarios para el funciona-
miento de estos procesos y de la empresa, pues estos procesos tambin
tiene clientes, aunque en este caso son clientes internos de la organizacin
y como procesos que son tambin crean valor.
Para estos procesos centrales de negocio, deberemos, adems de la ne-

cesaria identificacin de los mismos, identificar sus entradas y salidas, los
responsables de cada uno de los procesos, los clientes, la misin y objetivos
del proceso, los procedimientos internos, instrucciones de funcionamiento,
tareas que deber desarrollar as como los subprocesos que pueda conte-
45
ner e identificar los indicadores que nos permitan realizar el seguimiento de

la eficiencia de estos procesos.
Hemos avanzado en este apartado muchas de las ideas que se desarro-

llarn en los siguientes captulos, en especial la idea de la organizacin
orientada a procesos, donde se reconoce la existencia de la transversalidad
de los procesos y donde el trabajo se orienta hacia la satisfaccin de las
necesidades y expectativas de los clientes mediante el diseo y optimiza-
cin de los procesos de negocio que crearan valor aadido a estos clientes.
En este cambio, se trastocarn las estructuras de la organizacin tradicional
hacia un nuevo tipo de organizacin en el que las reas funcionales pasarn
de ser sistemas cerrados a sistemas abiertos, los flujos de informacin pasa-
rn de ser verticales y manuales a horizontales y automatizados, donde se
sustituirn las rdenes de trabajo por reglas de negocio que guiarn el
comportamiento de los procesos y donde el control del trabajo y del des-
empeo se realizar en base a indicadores medibles y en tiempo real y no
mediante la presencia fsica de supervisores. Estos cambios en la estructura
organizacional supondrn tambin una reestructuracin de las tradicionales
arquitecturas informticas aisladas del negocio, que dejarn de servir a
departamentos concretos y pasarn a formar parte de los procesos.
Esta orientacin a procesos, no es algo nuevo. En los ltimos aos y gra-

cias al desarrollo de los sistemas ISO de calidad, se ha desarrollado la visin
de la empresa orientada a procesos y los modelos y metodologas de ges-
tin por procesos como capacitadores no solo para alcanzar la excelencia
empresarial, sino tambin la capacidad innovadora y de adaptacin al cam-
bio que el nuevo entorno empresarial requiere.
Los avances en gestin empresarial del pasado siglo, especialmente los

modelos japoneses de mejora continua, la innovacin, la reingeniera, la
orientacin al cliente y la adecuacin de los modelos operacionales de las
empresas a las actuales necesidades de los mercados, ya apuntaban la im-
46
portancia de los procesos como base para la gestin organizacional y su

capacidad de contribuir a los resultados. Este abordaje que comenz con
TQM (Total Quality Management) y la mejora continua, comenz a ser insu-
ficiente en un entorno donde las exigencias de los clientes y sus necesida-
des estn en continuo cambio. En los modelos anteriores, la orientacin al
cliente y el cmo satisfacer sus necesidades y expectativas cobran especial
importancia y la gestin por procesos es incluida en todos ellos como bue-
nas prcticas o principios de excelencia para conseguir una visin gil para
producir productos y servicios que no slo se adapten a las necesidades de
los clientes, sino que puedan responder a las cambiantes necesidades y
expectativas de los mismos.
En la norma ISO 9001:2000 se especifica en el apartado 4.1a: identificar

los procesos necesarios para el sistema de gestin de la calidad y su aplica-
cin a travs de la organizacin. En el apartado 4.1b: determinar la se-
cuencia e interrelacin de estos procesos y en el apartado 7.1: la organi-
zacin debe planificar y desarrollar los procesos necesarios para la realiza-
cin del producto. El Modelo Europeo de Excelencia (EFQM) dedica nte-
gramente unos de sus mdulos a la gestin de procesos enunciado: La
satisfaccin del cliente, la satisfaccin de los empleados y un impacto posi-
tivo en la sociedad se consigue mediante el liderazgo en poltica y estrate-
gia, una acertada gestin de personal, el uso eficiente de los recursos y una
adecuada definicin de los procesos, lo que conduce finalmente a la exce-
lencia de los resultados empresariales, y en el punto nmero 5, el EFQM
establece como la organizacin disea, gestiona y mejora sus procesos con
objeto de apoyar su poltica y su estrategia y para generar valor de forma
creciente a sus clientes y sus otros actores.
De la orientacin al cliente como catalizadora de la gestin de procesos,

surge la idea de ver la organizacin en s misma como un proceso, la cual
realiza una serie de operaciones encaminadas a satisfacer a esos clientes y
se plantea el diseo de procesos orientados al cliente, independientemente
de la estructura organizacional de la empresa. La gestin de procesos se
conforma como una herramienta capaz de alcanzar los objetivos expuestos
por TQM en un entorno como el descrito, es decir, permite implementar de
forma rpida y gil estos problemas de adaptacin al cambio y focalizacin
en el cliente.
Los procesos son extremadamente importantes para la empresa y el

cuidado en su diseo y funcionamiento operativo resulta crucial para el
funcionamiento de las empresas, pues son repetitivos, lo que implica que si
47
su funcionamiento no es todo lo eficiente que podra ser, provocarn inefi-

ciencias tambin repetitivas y de igual manera, si estos son eficientes, pro-
vocarn que la empresa sea tambin cada vez ms eficiente y es por ello
que adoptaremos un planteamiento de mejora continua de nuestros proce-
sos mediante la mejora o transformacin radical de estos y prestaremos
especial cuidado en el diseo y vigilancia de su funcionamiento, de forma
que la operativa empresarial de estos procesos de negocio sea lo ms efi-
ciente posible.
Para hacernos una idea de su importancia y como las empresas se con-

forman entorno a procesos, podemos enumerar algunos de los procesos
empresariales ms comunes en las organizaciones:
- Gestin de rdenes de venta,

- Gestin de devoluciones.
- Gestin de gastos de viajes.
- Gestin de Reclamaciones.
- rdenes de compra.
- Gestin de recursos compartidos.
- Generacin de Informes de gastos.
- Solicitudes de reembolso.
- Facturacin a clientes.
- Diseo de nuevos productos.
- Encuestas de empleados, clientes.
- Evaluaciones de personal.
- Solicitud y gestin de vacaciones.
- Hojas de tiempo.
- Solicitudes de empleados (vacaciones, permisos, etc.)
- Informes de control de calidad, certificaciones.
- Preparacin de presupuestos.
- Gestin de proyectos, etc.
De la importancia que para las empresas tiene la gestin de procesos,

surge la necesidad de entenderlos, documentarlos y conocer su funciona-
miento para poder hacer estos procesos lo ms eficientes y competitivos
posible respecto a los de nuestra competencia, por lo que necesitaremos
adems mejorarlos continuamente mediante la mejora de procesos, el redi-
seo y reingeniera de estos, as como automatizarlos y monitorizar su ope-
rativa en base a indicadores de gestin y rendimiento e integrarlos con
nuestra infraestructura de TI (Tecnologas de la Informacin). Sobre todo
este camino es sobre lo que trata BPM, pero antes describiremos algunas
48
caractersticas bsicas de la Teora General de Procesos como son el cmo

definir los procesos de nuestra organizacin, las principales caractersticas y
propiedades de estos, cmo identificarlos y clasificarlos para poder trabajar
en su mejora, pues identificar y modelar los procesos ser el primer paso
para que estos puedan ser analizados. Para ello deberemos saber qu per-
sonas estarn involucradas en el proceso, qu tecnologa usan, donde co-
mienzan y terminan los procesos y las interrelaciones que tienen con otros
procesos, quin se ver afectado por el funcionamiento del proceso y una
serie de datos del proceso que nos ayudarn a su identificacin y entendi-
miento. Las personas con las que deberemos contar para la realizacin de
esta tarea sern aqullas que trabajan directamente sobre el proceso o
aqullas que se puedan ver afectadas por su funcionamiento, pues estos
perfiles sern ms sensibles a los distintos pasos y operativas del proceso
que los perfiles ms gerenciales.
Definicin de proceso:
Existen varias definiciones sobre qu es un proceso, por lo que diremos

varias de estas definiciones que nos ayudarn a entenderlos:
- Conjunto de actividades organizadas para conseguir un fin, des-

de la produccin de un objeto o prestacin de un servicio hasta
la realizacin de cualquier actividad interna.
- Conjunto de recursos y actividades interrelacionados que trans-
forman elementos de entrada en elementos de salida.
- Secuencia de actividades que van aadiendo valor mientras se
produce un determinado producto o servicio.
- Conjunto de actividades relacionadas que transforman entradas
en salidas o resultados.
- Conjunto de acciones y tareas que se realizan de forma secuen-
cial y que en su conjunto, proporcionan valor aadido a los
clientes.
- Un proceso es la mezcla o transformacin de unas entradas en
un rendimiento de mayor valor.
En todas ellas observamos como subyacente el mismo concepto: que los

procesos son un conjunto de tareas para ofrecer un producto o servicio con
mayor valor aadido a un cliente y que un proceso es una secuencia orde-
nada y lgica de actividades de transformacin que parten de unas entra-
das para alcanzar unos resultados programados que se entregan a clientes.
49
Caractersticas, Propiedades y Requisitos de los procesos:
Dos son las propiedades ms caractersticas y observables en los

procesos: su variabilidad y repetitividad como clave para su mejora.
Variabilidad de los procesos:
Cada vez que repetimos un proceso, ste presenta variaciones tan-

to en la ejecucin de sus actividades como en las salidas del proceso que
pueden repercutir en la satisfaccin del cliente. Todos los procesos tienen
una variabilidad inherente que puede evaluarse por mtodos estadsticos y
mostrarse en forma de grficos de control que nos muestren la variabilidad
y de esta forma poder trabajar en la mejora del proceso para reducir y con-
trolar su variabilidad y mejorar sus niveles de eficacia y eficiencia:
Repetitividad del proceso:
En ltima instancia los procesos se crean para poder ser repetidos y

esta caracterstica nos permitir trabajar sobre el proceso para su mejora
de forma que cuantas ms veces repitamos el mismo, ms conoceremos su
funcionamiento y las posibles variaciones sobre el mismo para poder mejo-
rar sus resultados esperados.
50
De la definicin de proceso, inferimos que esta serie de actividades

ha de ser repetitiva y medible de forma que podamos predecir la transfor-
macin de las entradas en salidas y alcanzar los niveles de estabilidad re-
queridos por el proceso.
Otras caractersticas importantes de los procesos son:
- Responden a alguna accin o evento especfico.

- Producen resultados especficos que son entregados a clientes
o stakeholders (personas que puedan verse afectadas positiva
o negativamente por el desarrollo de un proyecto o del propio
proceso)
- Cruzan uno o varios departamentos o lmites funcionales de la
organizacin.
- Se pueden describir sus entradas y sus salidas.
- Pueden ser medidos para evaluar la eficiencia y rendimiento de
los mismos.
- Los procesos describen como se realiza el trabajo y son obser-
vables, medibles, mejorables y repetitivos.
Los procesos tambin presentan una serie de propiedades como

por ejemplo:
- Capacidad: es la carga mxima que puede soportar el proceso.

- Productividad: la relacin entre las entradas y las salidas.
- Eficacia: es la medida con la que los resultados cumplen con los
objetivos especificados para el proceso y que el cliente reciba lo
que espera.
- Flexibilidad: medida de la adaptabilidad a las circunstancias y
los cambios imprevistos que puedan surgir en el proceso.
Entre los requisitos que deben ofrecer los procesos podemos enu-
merar:
- Todos los procesos deben tener un responsable asignado que

asegure su cumplimiento y eficacia.
- Todos los procesos deben cubrir el ciclo PDCA (Plan-Do-Check-
Act) que veremos en este captulo y en captulos posteriores.
- Un sistema de indicadores que permita evaluar la eficacia de los
procesos.
- Una estructura coherente de procesos que describa el funcio-
namiento de la organizacin o de una parte de la misma.
51
- Los procesos tienen que ser fcilmente comprendidos por cual-

quier persona de la organizacin, sin importar a que departa-
mento pertenezca o funcin que desempee en la organizacin
y sean estas personas perfiles de negocio o tcnico de dentro
de la organizacin. En este sentido y como veremos a la hora de
identificar los procesos en la fase de levantamiento de proce-
sos, es importantsimo conseguir la implicacin y participacin
de las personas de la organizacin desde las fases ms tempra-
nas para conseguir su implicacin tambin en las fases posterio-
res, evitando imposiciones, buscando acuerdos y conciliando las
distintas soluciones y problemas.
Modelado de procesos.
Un modelo es una representacin esquemtica o conceptual de los pro-

cesos de la organizacin y de las relaciones entre estos, que representa de
forma secuencial, como funcionarn los procesos y como se realizan las
tareas que producirn la salida de un producto o servicio. Con esta repre-
sentacin simplificada a alto nivel de los procesos, se pretende disponer del
conocimiento de las actividades que producen valor a nuestros clientes e
identificar aquellas que no aporten valor o sean ineficientes en su funcio-
namiento as como comprender su operativa para poder reducir costes,
tiempos de proceso, optimizar el uso de los recursos, coordinar las activida-
des de los participantes en el proceso y trabajar en la mejora de los mis-
mos. El modelado nos ayudar a pensar ms clara y coherentemente y a
visualizar las mejores opciones y oportunidades de que disponemos en los
procesos que ejecuta nuestra empresa. Sin embargo, y aunque los modelos
nos resulten idneos para entender muchas situaciones y escenarios, de-
bemos partir de la premisa de que los modelos empresariales y organiza-
cionales no sern siempre perfectamente explicables, como puedan ser los
modelos matemticos o fsicos, pues en los modelos empresariales, ten-
dremos que contar con el componente humano que forma parte de todos
estos sistemas y los humanos, aprendemos, nos adaptamos, mejoramos,
interaccionamos y experimentamos sin seguir unas reglas fijas, provocando
un comportamiento ms probabilstico que determinista, por lo que nunca
podremos construir modelos que cubran todas estas posibilidades y debe-
remos hacer uso de nuestra inteligencia, visin e intuicin para predecir el
comportamiento de estos sistemas y procesos.
52
Para realizar el modelado, deberemos realizar una serie de tareas como

son la identificacin de los procesos, su seleccin y clasificacin, con objeto
de disponer de un mapa de procesos de la organizacin que ser lo primero
que deberemos tener para implantar la gestin por procesos. Este mapa de
procesos ser como nuestra hoja de ruta, la cual deber ser lo suficiente-
mente detallada para poder entender los procesos, pero sin perdernos en
detalles que puedan dificultar su comprensin.
El sustituir muchas veces todo el conocimiento, procedimientos y nor-

mativas escritas por un modelo grfico y visual como el mapa de procesos
facilitar la comprensin de los mismos en todos los niveles de la organiza-
cin.
La recomendacin para realizar este mapa de procesos es centrarse en

las actividades y procesos que aporten valor al cliente, seleccionar procesos
que empiecen y finalicen en el cliente y no tanto en los procesos de produc-
cin o aquellos dirigidos a corregir errores, en su lugar deberemos atacar
las causas de esos errores, pues como clientes, por ejemplo, siempre prefe-
riremos no tener problemas con los productos que adquiramos a disponer
de un buen servicio de atencin de reclamaciones. La mejora de procesos
consistir precisamente en cmo hacer las cosas mejor y no en ser capaces
de apagar los fuegos cuando estos aparezcan, para lo cual trabajaremos en
la coordinacin entre los diferentes procesos, suprimiendo aquellos proce-
sos o pasos de los mismos que no aporten valor, la eliminacin de errores,
ineficiencias y la reduccin de los ciclos de proceso y la incorporacin de las
TI para mejorar su grado de gestin y control.
El identificar los procesos ser una tarea primordial y previa a cualquier

proyecto encaminado hacia la mejora de procesos o de BPM. Esta tarea se
encaminar a conocer los procesos sobre los que queremos trabajar, por lo
que deberemos hacernos una idea sobre qu trata de resolver el proceso,
qu pretende alcanzar y por qu existe el proceso, as como el grado de
importancia que ste tiene para la organizacin y para sus clientes. Indaga-
remos tambin en cmo funciona el proceso actualmente (lo que ms tarde
veremos como el As-Is, en la fase levantamiento de procesos) y especifica-
remos el mapa de procesos conjunto de la organizacin, dnde comienza y
termina cada proceso, quines son los participantes y unidades de negocio
que participan en los distintos procesos y cules son sus responsabilidades,
las razones por las que se pretende analizar y/o trabajar en la mejora del
proceso, as como el valor que se pretende conseguir con este trabajo. Ana-
lizaremos la informacin que fluye por los distintos procesos y cmo se
53
produce el intercambio de sta, con qu sistemas internos y externos inter-

actan los procesos, las reglas de negocio que rigen el comportamiento de
los procesos y en general, toda la informacin que podamos recabar sobre
los procesos objeto de nuestro proyecto. Aunque en captulos posteriores
profundizaremos en muchos de estos puntos dentro de BPM, listaremos
ahora una serie de puntos necesarios para una correcta identificacin y
especificacin previa de los procesos.
Entradas y Salidas:
En todo proceso hay dos importantes agentes que no podemos olvidar:

clientes y proveedores. Los rendimientos o salidas del proceso pueden ser
un producto, un servicio o la conclusin de una tarea. Las entradas del pro-
ceso pueden ser: personas, materiales, equipo, informacin, tcnicas, m-
todos, procedimientos, polticas, tiempo, dinero, etc.
A travs de los procesos de transformacin, el proceso producir los

productos y servicios que constituirn la salida de los procesos. La salida de
todo proceso va a los clientes, sean estos internos (que trabajan en nuestra
empresa) o externos (que trabajan fuera de ella). Los clientes son la parte
ms importante de cualquier proceso, pues son quienes comprarn o reci-
birn las salidas de nuestro proceso y la satisfaccin de sus necesidades y
expectativas ser la razn ltima de los procesos y el motivo por el que
trabajaremos en su mejora. Cuando trabajamos con procesos, debemos
concentrarnos en el resultado ofrecido al cliente priorizndolo sobre las
tareas y actividades individuales que realicemos para producir ese resultado
y considerar los requisitos de calidad exigidos a los productos o servicios
producidos por los procesos de forma que estos cumplan con las exigencias
establecidas. De los clientes debemos escuchar sus opiniones y retroali-
mentar el proceso en funcin de stas, mientras que de los proveedores
debemos tambin obtener retroalimentacin pero debemos entre otras
cosas vigilar atentamente la calidad para asegurarnos correctas entradas en
nuestros procesos.
Adems de a los clientes, no debemos olvidar a los dems stakeholders

(promotores, partners, socios o personas involucradas o afectadas por el
proceso), sobre las cuales debemos prestar atencin pues stas pueden
afectar o influenciar sobre el proceso positiva o negativamente y en conse-
cuencia deben ser tenidos en cuenta para no generar insatisfaccin y prdi-
das de eficiencia.
54
La misin:
Esta ser la razn de ser y el motivo por el cual se asignen recursos y es-
fuerzos para poner en marcha un proceso. Para qu hacemos el proceso?,
Para quin lo hacemos? y Cmo la hacemos?
Objetivos del proceso:
Los resultados que queremos alcanzar con el proceso. En la medida en

que cada proceso se realiza para cumplir con unos objetivos, debemos ase-
gurar la consistencia entre lo que los procesos hacen, los objetivos y metas
organizacionales y las salidas del proceso.
Los Clientes:
Aunque ya hemos hablado de su importancia, los clientes sern perso-

nas u organizaciones que utilizarn los productos y servicios fruto del pro-
ceso y que en funcin de sus necesidades y expectativas aprobaran final-
mente su resultado y es por ello que ser imprescindible tener claramente
identificados a estos clientes y gestionar sus necesidades y expectativas. Las
expectativas de los clientes son las creencias que estos tienen sobre las
salidas del proceso (que para ellos sern entradas) y pueden ser muy diver-
sas y no siempre ajustadas a lo que el proceso producir.
Los anlisis de variabilidad y control de los procesos as como otras tc-

nicas y herramientas para la medicin de los procesos, sern de gran impor-
tancia a la hora de cumplir con los requerimientos exigidos y las necesida-
des de los clientes.
Propietario del proceso:
Designado por el promotor y que actuar como director de proyecto

siendo responsable de la gestin del proceso y de la mejora continua del
55
mismo. Este responsable debe conocer en profundidad el proceso que va a

liderar, poseer conocimientos de calidad, six sigma, reingeniera, gestin de
procesos y gestin empresarial y estar ms centrado en los aspectos de
Negocio que en los de TI (Tecnologas de Informacin). Adems debe tener
capacidad para la toma de decisiones y para asignar o retirar recursos as
como habilidades interpersonales de liderazgo, comunicacin y negocia-
cin.
Promotor del proceso:
Ser la persona que asignar los recursos necesarios, definir la misin y

objetivos del proceso y realizar el seguimiento y evaluacin del mismo.
Actividades:
Es la descripcin de las acciones y tareas que deber realizar el proceso

para conseguir los resultados y salidas esperadas por el cliente. A travs de
estas tareas y actividades transformaremos las entradas en salidas del pro-
ceso. Las actividades las identificamos, desglosamos en paquetes de traba-
jo, secuenciamos, estimamos los recursos necesarios para las mismas, esti-
mamos su duracin y las controlamos.
Recursos:
Todos aquellos elementos materiales o de informacin que el proceso

consume o necesita para ejecutar sus actividades y producir la salida del
proceso.
Alcance y lmites del proceso:
Definir el alcance del proceso (qu est incluido en el mismo y que no lo

est) y garantizar que incluya todo el trabajo requerido para completarlo
con xito y producir los resultados esperados. Esto incluye tambin definir
los lmites del proceso, dnde empieza y termina la secuencia de activida-
des relacionadas con el proceso y definir los lmites de entrada y de salida.
Indicadores:
Los indicadores nos permitirn hacer una medicin y seguimiento de

cmo opera el proceso y si ste se orienta hacia su cumplimiento y objeti-
56
vos, conocer su evolucin y tendencia y de esta forma planificar los valores

deseados para el proceso.
El establecimiento de indicadores alineados con los objetivos del proyec-

to nos servir para medir el rendimiento del proceso, gestionar, controlar y
mejorar los mismos y medir el grado de cumplimiento de los objetivos plan-
teados siendo anticipadores de los resultados en las salidas de los procesos
y la variabilidad de los mismos. Estos indicadores deben ser claros, fciles
de entender, importantes, medibles, consistentes en el tiempo de ejecucin
del proceso, fciles de obtener, objetivos, fiables, comparables, representa-
tivos del proceso que miden y deben ser explicados a los miembros del
equipo, para que todos entiendan qu medimos y porqu lo medimos. En-
tre otros tipos, los indicadores pueden ser de eficacia, de eficiencia, que
analizar los resultados alcanzados (salidas) en relacin a los recursos inver-
tidos (entradas), de percepcin de clientes o de adaptabilidad y nos propor-
cionarn el grado con que el proceso ha contribuido a la consecucin de los
objetivos estratgicos de la organizacin. Otro indicador muy frecuente e
importante es el de la adaptabilidad del proceso el cual nos dar una medi-
da de la capacidad para el cambio y anticipacin al mismo con la que cuenta
el proceso.
Los indicadores nos permitirn medir las variaciones que se producen en

el proceso y comprobar que se encuentran en el rango de tolerancia permi-
tido para los mismos. La medida de la variabilidad ser importante en la
medida en que repercutir en las salidas del proceso y en consecuencia en
los clientes. Para las medidas de variabilidad y el establecimiento de mr-
genes de tolerancia se utilizan los grficos de control y otras herramientas
de anlisis estadstico que veremos al final de este captulo.
Variables de Control:
Las variables de control sern aquellos parmetros sobre los que tene-
mos capacidad de poder modificar y alterar el funcionamiento o compor-
tamiento del proceso.
Una vez documentada toda la informacin sobre los procesos, podemos

realizar la representacin grfica de los mismos, las entradas, salidas y el
conjunto de actividades y tareas necesarias para la ejecucin del proceso.
Esta representacin visual del proceso nos ayudar a asignar recursos, se-
cuenciar actividades, identificar hitos y puntos de medida de indicadores,
pudiendo realizar simulaciones y suposiciones que nos orienten a la hora de
mejorar estos procesos mediante la variacin de las variables de control
57
internas y externas del proceso, pudiendo tomar decisiones sobre los pa-
rmetros de actuacin. Para esta representacin se suele usar la metodolo-
ga IDEF en 5 niveles pero que no analizaremos aqu por ser el objeto de
este libro la disciplina BPM, el cual cuenta con su propia notacin para la
representacin de procesos (BPMN). El lector puede consultar en otras
fuentes informacin sobre la metodologa IDEF.
Clasificacin de los procesos.
Tras realizar la identificacin y definicin de los procesos, realizaremos la

clasificacin de los mismos. Puesto que no todos los procesos que ejecuta
una empresa tienen la misma influencia en los costes o en la satisfaccin de
los clientes, podemos clasificar los procesos en funcin del impacto de los
mismos sobre la organizacin en: Procesos Estratgicos, Operativos y de
Apoyo:
- Procesos Estratgicos: estn orientados a las actividades estra-

tgicas de la empresa para planificar, organizar y controlar los
recursos y guiar a las organizaciones para incrementar la calidad
de sus servicios. Se realizan para cumplir los objetivos estratgi-
cos de la organizacin, dar valor a sus clientes, orientacin al
modelo de negocio y directrices para el resto de procesos.
- Procesos Operativos: son los ms cercanos al cliente y los que
finalmente producen valor aadido a los mismos y en conse-
cuencia, sern los de mayor impacto sobre la satisfaccin de los
clientes al pertenecer a la parte principal del negocio.
- Procesos de Apoyo: generan los recursos que necesitan los de-
ms procesos, apoyando a los procesos operativos y ayudando
en su coordinacin.
58
Otra clasificacin que podemos hacer de los procesos y a la que recurri-

remos en distintas partes del libro es la siguiente:
- Centrados en Humanos (human-centric), usados para guiar las

actividades desarrolladas por personas (que son los tpicos usa-
dos por las herramientas de workflow),
- Centrados en Documentos (document-centric), basados en do-
cumentos y su procesamiento,
- Centrados en Decisiones (decisin-centric), basados en decisio-
nes tomadas por personas.
Cuando veamos el estndar BPMN (Business Process Model Notation), la

notacin estndar en BPM para modelar procesos de negocio y los BPMS
(Business Process Management Systems), los entornos software a travs de
los cuales modelaremos e implementaremos los procesos, veremos que
podremos clasificar nuestros procesos de distintas maneras simultaneando
las clasificaciones que acabamos de ver. A la hora de trabajar con BPM y en
especial en las fases de modelado, nos centraremos ms en que lo procesos
estn bien definidos, que estn estandarizados segn el tipo de industria en
la que estemos desarrollando el proceso y que estos se basen en la cadena
de valor. Por ejemplo, la American Productivity and Quality Centres Pro-
cess Classification Framework (APQC) clasifica los procesos en procesos
centrales o que aaden valor, como procesos operacionales y el resto de
procesos como de gestin y apoyo, siguiendo el modelo de cadena de valor
de Porter.
Mejora de procesos:
El objetivo de la identificacin y clasificacin de los procesos que hemos

visto, es realizar un mapa de procesos, que ser una representacin grfica
que refleje con claridad la secuencia de tareas, la informacin que compar-
ten, la estructura de los procesos y las interacciones ms importantes entre
ellos, para a travs de este mapa, poder trabajar en el anlisis y la mejora
de los procesos que actualmente opera la organizacin.
El trabajar en la simplificacin y mejora de los procesos es algo que las

organizaciones siempre han realizado convencidas de que incrementando la
eficiencia de estos procesos alcanzarn mejores formas de hacer las cosas
y una mayor satisfaccin de clientes y empleados.
59
Trabajar en la mejora de los procesos significar ejecutar y poner a fun-

cionar los procesos segn el diseo establecido para comprobar que este
opera segn se ha especificado y medir las desviaciones y variaciones que
se produzcan de forma que si en la operativa del mismo detectamos varia-
ciones, puntos fuera de control en el grfico de control, no satisfacciones de
clientes, despilfarro de recursos, tiempos fuera de lo establecido o cual-
quier otra incidencia no deseable para el comportamiento del proceso,
podamos adaptar el mismo aplicando mejoras que solventen estos proble-
mas o mejoren los indicadores de rendimiento del proceso.
Aunque veremos ms adelante dentro de BPM distintas tcnicas y

herramientas para la mejora de procesos, en este captulo podemos apun-
tar como metodologa las siguientes etapas indicadas por Kaoru Ishikawa
como Mtodo Sistemtico para la mejora de procesos, en el que resalta el
continuo llamamiento a la medicin de los procesos como mtodo cientfi-
co para la mejora de los mismos y que ser una constante tanto en la Ges-
tin de Procesos como en la disciplina de BPM:
1. Identificacin y definicin del proceso real: detectar lo que desean y

necesitan nuestros clientes. Describir el proceso y las medidas que
soporta el mismo.
2. Medicin y anlisis del proceso: analizar las medidas y detectar
oportunidades de mejora.
3. Identificar oportunidades de mejora: disear el proceso mejorado y
medir los resultados para comprobar que se produce la mejora en
los resultados.
4. Normalizacin del proceso: ajustar el proceso y documentar las me-
joras.
5. Plan de revisin y mejora continua: disear medidas para el segui-
miento del proceso y las acciones para la mejora de los resultados.
De forma general y antes de proceder con la mejora de los procesos

identificados, a la hora de disear nuestros procesos, deberemos tener en
cuenta los siguientes criterios:
- Eliminar todas las actividades y tareas que no aporten valor.

- Buscar los datos asociados con los procesos, pues sin ellos no
podremos realizar las mediciones sobre las que basar las mejo-
ras sobre los procesos.
- Evitar la departamentizacin de los procesos y verlos de forma
horizontal atravesando a toda la organizacin.
60
- Hacer los procesos simples y entendibles.

- Considerar todos los aspectos internos y externos que puedan
afectar a los procesos: medioambientales, tcnicos, legales, de
negocio, etc.
Para la mejora de procesos existen un sinfn de herramientas y tcnicas

derivadas principalmente de TQM y Six Sigma. En este captulo describire-
mos dos de las metodologas ms usadas para la mejora general de proce-
sos: PDCA (Plan-Do-Check-Act; por sus siglas en ingls) y DMIAC derivada de
Six Sigma.
Metodologas PDCA y DMIAC:
Los resultados de un proceso dependern no slo de la correcta identifi-

cacin y definicin de los mismos sino tambin de la correcta gestin de
estos. Para esta gestin podemos utilizar la metodologa PDCA (Plan, Do,
Check, Act), asociada a casi todos los proyectos de mejora continua y que
ser como veremos la columna vertebral del ciclo de vida y de implementa-
cin de los proyectos de BPM. El mtodo PDCA, tambin conocido como
ciclo de Shewhart, es una metodologa de resolucin de problemas con un
enfoque de ensayo-error muy apropiado cuando abordamos proyectos de
mejora continua y de mejora de procesos. El mtodo PDCA consta de las
siguientes fases:
- Planificar (Plan): definir qu, quin y cundo se van a realizar las

actividades. Definir los objetivos del proceso y los datos e in-
formacin del proceso as como medidas de su rendimiento ac-
tual para poder con posterioridad compararlo con las acciones
de mejora que llevemos a cabo, identificar stakeholders (intere-
sados), costes, tiempos, recursos necesarios, riesgos, adquisi-
ciones y en general definir el curso de accin necesario para al-
canzar los objetivos.
- Desarrollar (Do): llevar a cabo las actividades y completar el
trabajo definido en la fase de planificacin. Esta fase implica
coordinar personas y recursos y realizar las actividades planifi-
cadas.
- Controlar (Check): analizar los resultados obtenidos mediante el
procesado y anlisis de los datos obtenidos en las mediciones,
comprobar y evaluar las desviaciones y grado de cumplimiento
61
de los objetivos con el fin de tomar medidas correctoras o de

mejora de la operativa de los procesos.
- Actuar (Act): ajustar y llevar a cabo acciones de mejora segn
las mediciones obtenidas en la fase de control, las cuales sern
enviadas a la fase de planificacin para evaluar el impacto de
las mismas sobre el proceso para su aprobacin o rechazo.
Otra metodologa para la gestin de procesos es DMIAC, propuesta por

la metodologa Six Sigma y que consta de los siguientes pasos:
- Definir: el cometido del proceso, su representacin grfica y la

operativa del proceso para poder evaluarlo antes de su implan-
tacin.
- Medir: obtener informacin de los indicadores que se hayan de-
finido.
- Analizar: a partir de la informacin proporcionada por los indi-
cadores, el comportamiento del proceso y su grado de cumpli-
miento respecto a los objetivos planteados.
- Mejorar: los procesos en funcin de las medidas de rendimien-
to.
- Controlar: la ejecucin del proceso interviniendo si es necesario
para asegurar su eficacia y eficiencia.
62
Ventajas de la gestin de procesos:
El enfoque basado en procesos en las organizaciones es la forma ms

eficaz de desarrollar acciones que satisfagan a usuarios internos de la orga-
nizacin y a los clientes de la misma, de una forma coherente y estructura-
da y permitir la mejora continua por medio de la monitorizacin de los pro-
cesos. Pero adems, la organizacin que implemente la gestin de proce-
sos, obtendr ventajas como: la medicin del desempeo organizacional y
de la satisfaccin de los clientes, la identificacin de redundancias y activi-
dades que no aportan valor, dirigir y enfocar la organizacin a alcanzar una
metas y objetivos comunes y orientar a la organizacin a resultados y no a
tareas departamentales.
Pero en la implementacin de la gestin por procesos, nos encontrare-

mos con que los procesos cruzan los lmites organizativos y funcionales de
la empresa, transitando por la misma horizontal y verticalmente e interac-
tuando por el camino con otros procesos y recursos necesarios para su ope-
racin. Esta evidencia en el comportamiento de los procesos nos obligar a
considerar el cambio cultural y de paradigma que representa para la organi-
zacin el pasar de una organizacin funcional a una organizacin orientada
a procesos, en la que todos los esfuerzos y cultura corporativa se centrarn
en maximizar el valor aportado a los clientes a travs del proceso y no los
distintos pasos o etapas individuales que atraviesa el proceso en su flujo
hacia el cliente.
La gestin por procesos y el ver la empresa no ya desde una perspectiva

funcional y departamental, sino bajo el prisma de los procesos que la orga-
nizacin ejecuta para producir valor a sus clientes, nos proporcionar nu-
merosos beneficios internos y tambin nuevos retos para las empresa que
la implanten, como ser la reduccin del protagonismo de los departamen-
tos en pos de una visin ms comunicativa y participativa de forma que se
coordinarn todos los esfuerzos en la consecucin de un objetivo final co-
mn, ms all de los intereses particulares de cada departamento y que
permitir simplificar la gestin y agilizar la empresa aumentando su capaci-
dad de adaptacin al cambio. Al mismo tiempo, las personas que trabajan
en la organizacin bajo esta orientacin a procesos, adquieren un conoci-
miento mayor de la empresa, al necesitar conocer y comprometerse con los
procesos de principio a fin, y no slo con partes concretas del mismo, lo que
requerir de estas personas mayor interdisciplinaridad, habilidades y cono-
cimientos en la organizacin orientada a procesos que las requeridas en las
organizaciones jerrquicas y funcionales. Adems, la gestin por procesos
63
nos permite centrarnos en los clientes y en los procesos que aportan valor a
estos, por lo que del rendimiento que obtengamos en la gestin de nues-
tros procesos obtendremos en consecuencia no slo mayor satisfaccin de
nuestros clientes sino tambin una mayor rentabilidad econmica.
La estrategia de reduccin de costes.
Una de las tendencias ms comunes al implantar la gestin por procesos

es el de usarla para la reduccin de costes. La rentabilidad de una empresa
la podemos definir como input/output, lo que ingresamos dividido entre
lo que nos cuesta producirlo y entregarlo a nuestros clientes. Lo normal, y
sobre la parte de la ecuacin sobre la que normalmente han trabajado las
empresas, es trabajar sobre el denominador de esta ecuacin, sobre los
costes. Pero en este libro, aunque no descartamos ni menospreciamos esta
perspectiva, consideraremos tambin la otra perspectiva, que considera-
mos como la realmente importante para poder alcanzar ventajas competiti-
vas a largo plazo como es la de incrementar el numerador de la ecuacin, o
sea, las ventas.
Esta tendencia a centrase en el denominador y en la reduccin de cos-

tes, es la tendencia a centrarse sobre lo que creemos que tenemos control,
en la parte que podemos controlar y no sobre el mercado, las ventas, la
bsqueda de nuevas fuentes de ventaja competitiva y la innovacin, que
vemos como incgnita sobre la que tenemos poco control, pero sin las cua-
les ninguna empresa existira.
Este es el caso de las empresas perfectamente organizadas, estructura-

das y dnde todo est perfectamente controlado y gestionado para que no
se escape ni un solo cntimo, pero que luego, al no actuar sobre los merca-
dos con productos y soluciones innovadoras y competitivas, acaban per-
diendo cuota de mercado e ingresos, por lo que ese modelo de control se
viene abajo por su propio peso. Estas estrategias de reduccin de costes,
pueden producir resultados positivos a corto plazo, pero con ellas, tenemos
un lmite por debajo del cual no podremos reducir ms y a largo plazo, pre-
sentarn poco margen de mejora y se convertirn en estrategias de super-
vivencia y no de crecimiento, por lo que la mejora de procesos, no debe ser
usada slo y exclusivamente para implementar estrategias de reduccin de
costes, pues estos representan slo una parte de la ecuacin, importante,
sin duda alguna, pero no lo suficientemente seguras y valiosas como para
centrarnos y poner todos nuestros esfuerzos en slo esta faceta y descartar
las oportunidades que en la mejora de procesos se nos presentarn para
64
proporcionar mayor valor a nuestros clientes, innovar y afrontar nuevos

mercados y modelos de negocio.
En las estrategias de reduccin de costes, siempre haremos cosas que no

beneficiarn a nuestros clientes y que de alguna manera siempre tendrn
efectos negativos sobre estos. Este es el motivo por el que estas estrategias
estn siendo cada vez ms cuestionadas y vistas no ya como estrategias,
sino como tcticas de supervivencia. Vivimos en un mundo sistmico en el
que las decisiones que tomamos no slo nos afectan internamente sino
tambin al entorno que nos rodea. Las polticas de reduccin de costes, si
bien producen en primera instancia un aumento de los beneficios, estas
deterioran la calidad y en consecuencia se reducirn las ventas, lo que im-
plicar una reduccin de ingresos y de beneficios, al tiempo que incremen-
tarn la ineficiencia de nuestras operaciones, que redundar en un aumen-
to de costes. Es el flujo mostrado en el siguiente grfico, el cual deberemos
valorar a la hora de tomar decisiones sobre la aplicacin de este tipo de
estrategias.
Por el contrario, en las estrategias de crecimiento, innovacin y desarro-

llo, se marcar la diferencia en la rentabilidad que las empresas obtienen a
travs de la correcta e innovadora manera que tengan stas de gestionar
sus procesos y producir salidas de los mismos que aporten valor y ventajas
competitivas duraderas. Bajo esta consideracin, asumimos que diseando
y gestionado las transformaciones y secuencias de actividades en nuestros
procesos, seremos capaces de producir salidas de valor, dado que las en-
tradas, en un mundo globalizado como el actual, estn al alcance y son
prcticamente las mismas para todos. Como veremos al estudiar la cadena
de valor de Porter, el Valor y no el Coste, deber ser lo que usemos al dise-
ar nuestra estrategia y analizar nuestra posicin competitiva en el merca-
do y de la eleccin que hagamos a la hora de gestionar nuestra empresa
65
(trabajar sobre el numerador o el denominador de la ecuacin, la reduccin

de costes o la diferenciacin), depender el modelo y el estilo de gestin
con el que gestionaremos nuestra empresa.
El propio Deming, padre del concepto de Calidad Total, nos adverta que:
los costos no son la causa, son la consecuencia de una forma de hacer. El
centrar la visin en los balances y cuentas de resultados, o sea sobre los
efectos de nuestra gestin y no sobre las causas que producen estos resul-
tados econmicos, se demuestra cada vez ms como un error, cuya subsa-
nacin pasa por entender como todos los recursos de la empresa se interre-
lacionan entre s en una visin sistmica y orientada a procesos.
Tcnicas y Herramientas de anlisis de procesos.

Antes de avanzar en la gestin por procesos y en BPM, daremos un re-
paso a las diferentes tcnicas y herramientas estadsticas utilizadas para el
control y monitorizacin de procesos, de forma que el lector tenga presente
la existencia de las mismas y de sus capacidades a la hora de evaluar y mo-
nitorizar los procesos. Estas herramientas nos permitirn obtener datos e
informacin sobre los procesos, identificar problemas en los mismos, de-
terminar las causas que generan estos problemas y el impacto que la modi-
ficacin o mejora de estos pueda tener.
Aunque no pretendemos profundizar en las distintas tcnicas y herra-

mientas para control de procesos, s queremos que el lector no familiariza-
do con el uso de stas, tenga una idea de las ms utilizadas, para que se-
pamos en qu entorno nos moveremos y qu fundamentos estadsticos
estarn detrs de muchas de las soluciones que utilizamos cuando analiza-
mos y monitorizamos el rendimiento de los procesos en un BPMS (Business
Process Management System). Estos BPMS, son el software que empleare-
mos para el diseo, gestin y monitorizacin de nuestros procesos en BPM,
en los cuales, haciendo uso de muchas de las tcnicas y herramientas que
analizaremos y partiendo de medidas y clculos estadsticos, haremos uso
de las herramientas de generacin de indicadores, medicin de resultados y
rendimientos de los procesos para evaluar y diagnosticar los mismos, y ob-
tener datos e informacin confiable que nos permita identificar los proble-
mas, los cuellos de botella y las causas que los generan.
Gran parte de estas tcnicas y herramientas de anlisis estadstico para

el control de procesos, surgieron en los aos 60 con el incremento de la
66
capacidad tecnolgica y especialmente en los aos 70 y 80 con el uso de los

ordenadores y el desarrollo en Japn de los mtodos de calidad, el Just in
Time y el cambio de paradigma hacia la orientacin a procesos con la con-
siguiente necesidad de medir y evaluar los mismos. El origen de prctica-
mente todas las tcnicas y herramientas que veremos se encuentran en los
entornos industriales de produccin y en el control estadstico de procesos.
Estos sistemas de control se basan en sistemas de retroalimentacin de
informacin cuyo foco es la recogida y anlisis de la informacin sobre el
proceso para poder mejorar el mismo. En estos sistemas de control, medi-
remos parmetros de una muestra de la salida generada por el proceso y
sobre estas medidas, realizaremos los ajustes sobre el mismo para corregir
el proceso y evitar que estos errores vuelvan a producirse. Existe tambin el
control adaptativo de procesos, que veremos la final de este libro, basado
en el anlisis de series temporales y utilizado para predecir futuros valores
en las variables del proceso y ajustar el mismo antes de que estas variables
se encuentren fuera de control.
El lector encontrar suficientes tratados y manuales sobre estas herra-

mientas en fuentes de internet y libros especficos sobre la materia y en
especial en aquellos dedicados a Six Sigma. Aunque existen un gran nmero
de tcnicas, en este captulo daremos un repaso a las principales tcnicas y
herramientas para la medida y anlisis de procesos. Segn Ishikawa, otro de
los padres de la Calidad Total (TQM), con el uso de un grupo de sencillas
herramientas podemos resolver el 80% de los procesos de una organiza-
cin. Ishikawa identifico siete herramientas bsicas:
- Diagrama de Pareto
- Diagrama Causa-Efecto
- Histograma
- Hoja de datos
- Grfico de control
- Diagrama de dispersin
- Estratificacin
A las que posteriormente se aadieron otras herramientas como:
- Diagrama de flujo
- Tormenta de ideas (o Brainstorming)
- Diagrama de Gantt, de afinidad, de rbol, matricial, etc.
Las tcnicas y herramientas vistas en este apartado sern utilizadas en

distintas fases de nuestros proyectos BPM, algunas en fase de levantamien-
67
to y diseo de procesos (como el brainstorming o diagramas de Ishikawa) y

otras bajo el uso de herramientas software de anlisis de datos dentro de
los BPMS y ms concretamente en las herramientas de que estos disponen
de Business Analisys (BA).
A la hora de analizar nuestros procesos, y aunque al final ser el equipo

de direccin de proyecto el que decida que tcnicas y herramientas sern
ms apropiadas en cada caso, en una primera etapa es aconsejable utilizar
tcnicas como el Brainstorming, el diagrama de procesos, de afinidades,
interrelaciones o el de causa y efecto, con las que podremos abordar los
problemas mediante una aproximacin consensuada con los participantes
en el proceso e identificar desviaciones o problemas que pueden resultar
obvios y/o necesiten de anlisis numricos y estadsticos.
Brainstorming:
Tambin llamada lluvia o tormenta de ideas, es una tcnica utilizada pa-

ra generar un gran nmero de ideas de forma rpida con el objetivo de
identificar, comprender y dimensionar los problemas as como determinar
sus causas y posibles soluciones. El brainstorming se realiza en dos etapas,
en la primera se desarrollan las ideas y en la segunda se mejoran las mis-
mas. Esta tcnica, utilizada para generar ideas sobre un tema y obtener
informacin sobre ese tema o proceso, se realiza tomando las ideas del
personal que est ms familiarizado con la operativa del proceso que tra-
tamos, promoviendo la participacin y generando entusiasmo al hacer par-
tcipe al personal en la identificacin de problemas, las reas de mejora, la
resolucin de problemas o el diseo de los procesos y planes de accin.
El brainstorming se basa en la generacin de ideas en un ambiente de

trabajo en grupo en el que no se permite la crtica. El objetivo es que los
comentarios de otras personas acten como estmulos de las propias ideas.
Todas las ideas son bienvenidas, pues no se busca la crtica de estas ni su
evaluacin durante el proceso de brainstorming, sino el generar el mayor
nmero de ideas posibles hasta que estas se agoten. Es importante que en
estas sesiones haya un responsable principal del proceso as como otra
persona que dirija y coordine estas sesiones. El que dirige la sesin formula
el problema y estimula los comentarios del resto del grupo en busca de la
generacin de ideas.
El brainstorming los podemos realizar de dos formas:
68
- Estructurado: en este mtodo, cada persona del grupo debe dar al-
guna idea cuando le toca el turno de participar. Este sistema fuerza
a participar a personas tmidas, pero a su vez crea cierta presin a
contribuir.
- Desestructurado: donde los miembros del grupo aportan ideas tan
pronto como les vienen a la cabeza, creando una atmosfera ms re-
lajada pero donde corremos el riesgo de que participen slo los ms
extrovertidos.
Benchmarking:
El Benchmarking nos proporcionar informacin sobre las actividades en

otras reas o sectores iguales o similares a los que opera nuestra organiza-
cin y nos permitir identificar, comparar, comprender, evaluar lo que es-
tamos haciendo y nuestras capacidades con respecto a los de la competen-
cia, de forma que podamos adaptar las mejores prcticas y procesos que
sabemos que funcionan en otras organizaciones.
El Benchmarking es muy recomendable hacerlo siempre que vayamos a

trabajar en la mejora de nuestros procesos, pues constituye una excelente
fuente de ideas y aprendizaje. Existen tres tipos de benchmarking para
comparar y medir continuamente a una organizacin y tomar las medidas
necesarias para mejorar sus procesos:
- Benchmarking interno, basado en el anlisis y comparacin de pro-

cesos similares dentro de la organizacin.
- Benchmarking competitivo, basado en la comparacin de nuestros
procesos con los de otras organizaciones similares.
- Benchmarking de lderes, en el que comparamos nuestros procesos
con los de las organizaciones lderes que han alcanzado altos nive-
les de excelencia.
Histograma:
El histograma es un grfico que vuelve visible la dispersin de datos de

un proceso y nos ayuda a definir posibles acciones requeridas para su con-
trol. Los histogramas sumarizan en un grfico de barras verticales la distri-
bucin de los datos en busca de datos atpicos o distribuciones anormales
no esperadas en el comportamiento de los procesos.
69
Diagrama de Pareto:
Tambin llamado curva 80-20, estos diagramas son utilizados para re-
presentar la contribucin relativa de cada causa o componente al problema
que estudiemos por lo que esta tcnica puede ser usada para analizar las
ideas surgidas en las sesiones de brainstorming e identificar los principales
problemas que causan el mayor impacto en nuestros problemas.
Los diagramas de Pareto son histogramas cuyas frecuencias se encuen-

tran en orden descendente de izquierda a derecha y que contienen en el
mismo grfico de barras una curva de frecuencias acumuladas en porcen-
tuales.
El grfico de Pareto es un tipo de histograma que se construye dividien-

do el alcance de los datos en grupos. El eje vertical es el porcentaje acumu-
lativo y el horizontal son las variables de respuesta de los grupos. La grfica
de Pareto nos permite asignar un orden de prioridades para la toma de
decisiones dentro de una organizacin y est relacionada con la ley de Pare-
70
to que establece que un nmero relativamente pequeo de causas provoca

la gran mayora de los problemas o defectos, conocido este principio como
el de 80/20, donde el 80 por ciento de los problemas son debidos al 20 por
ciento de las causas, lo que significa que hay unas pocas variables vitales y
muchas triviales. Esta regla del 80/20 es usada para conseguir grandes me-
joras, identificando las mayores causas de problemas, de forma que poda-
mos dirigir nuestra atencin y esfuerzos a los problemas realmente impor-
tantes.
Al realizar el anlisis de Pareto debemos tener en cuenta que hay varia-

bles que no pueden ser controlables (el tiempo, la inflacin, etc.) que aun-
que puedan repercutir en el resultado no deben formar parte del anlisis
por no ser controlables.
Para elaborar un Diagrama de Pareto podemos seguir los siguientes pa-

sos:
1. Identificar las causas que estn provocando un problema o defecto.

2. Seleccionar el nmero de veces que ocurre el problema, nmero de
defectos, nmero de rechazos, etc.
3. Seleccionar un rango de tiempo a ser estudiado.
4. Ordenar las causas de mayor a menor frecuencia o importancia y
calcular el porcentaje que representa sobre el total.
5. Construir el grfico de barras y la curva acumulada.
Diagramas de Causa-Efecto:
Tambin conocidos como diagramas de Ishikawa o de espina de pesca-

do, son usados para ilustrar como diferentes factores pueden estar vincula-
dos con un problema o defecto potencial.
Estos diagramas se utilizan para representar la relacin entre algn efec-

to y todas las posibles causas que lo influyen. Para su construccin se sita
el efecto o problema en el lado derecho del diagrama y las influencias o
causas a su izquierda, trazando una lnea horizontal a la cual, y como espi-
nas de pez, van llegando lneas oblicuas que representan las causas valo-
radas como tales por las personas que participan en el anlisis del problema
en cuestin. Estas lneas de posibles causas pueden a su vez recibir otras
lneas de causa o causas secundarias.
71
Esta tcnica permite un anlisis participativo en grupos de mejora o gru-

pos de anlisis, que reunidos pueden abordar la resolucin de un problema
y de las causas que lo originan.
Diagramas de Control:
Basados en la recopilacin y anlisis de datos para indicar el estado de

calidad de los procesos, el modo en que estos se comportan a lo largo del
tiempo y las posibles variaciones que estos procesos puedan tener. Los
grficos de control se usan para medir si el proceso se encuentra dentro de
los lmites deseados, en cuyo caso decimos que estn bajo control. Aunque
su aplicacin es muy frecuente en procesos industriales, estos grficos nos
servirn para otros muchos tipos de procesos. Los diagramas o grficos de
control, son una herramienta fundamental en el control de procesos para
vigilar la variacin de los mismos, controlar y mejorar su rendimiento. Su
objetivo es medir variables de salida de los procesos, para comprobar que
estos estn funcionando consistentemente, para ello buscamos puntos
fuera de control, valores fluctuantes, saltos repentinos o tendencias que
puedan ser causa de desviacin de los valores esperados para el proceso.
En los diagramas de control, se establecen unos lmites superiores e in-

feriores de la especificacin y lmites superior e inferior de control. Cuando
las medidas estn dentro de estos lmites, se dice que el proceso est bajo
control y si las medidas quedan fuera de estos lmites, el proceso deber ser
ajustado. Se establece la regla que dice que si un punto excede un lmite de
control o si tenemos siete puntos consecutivos por encima o por debajo de
la media, el proceso est fuera de control.
72
Donde los crculos nos indican:
- Un punto fuera de control (en el crculo pequeo).

- 7 puntos fuera de la media (en el crculo grande). Es la Regla del
7, segn la cual, 7 puntos o ms cerca de los lmites de control,
exige una revisin de los mismos.
Los diagramas de control recopilan y analizan los datos monitorizando

las salidas del proceso para evaluar en qu medida las salidas del proceso
se ajustan a los requerimientos de calidad. Estos diagramas representan el
comportamiento de un proceso a lo largo del tiempo y cuando un proceso
tiene puntos fuera de control, saltos repentinos o una tendencia hacia la
variacin. Estas medidas pueden ser utilizadas para la toma de decisiones
en el anlisis y diseo de procesos, evaluar o comparar procesos, corregir
variaciones en los procesos que puedan afectar a la calidad, reducir des-
hechos, etc.
Cuando un proceso est dentro de los lmites aceptables, se dice que es-
t bajo control y no requiere de ajustes. Por otra parte, si tenemos puntos
por encima o por debajo de los lmites de control o una sucesin de puntos
consecutivos fuera de los lmites, entonces el proceso debe ser ajustado.
Normalmente los lmites superior e inferior se fijan en siendo 1 una
desviacin estndar.
Adems de los diagramas de control, existen tambin los diagramas de

comportamiento, que son como los diagramas de Control, pero sin estable-
cer lmites al proceso, de forma que slo se muestran los puntos de datos
medidos para mostrar tendencias o variaciones en los procesos.
73
Diagramas de Dispersin:
Son una representacin grfica de los datos recogidos sobre dos varia-
bles para poder estudiar si existe relacin de causa efecto entre ellas y
muestran la tendencia entre estas dos variables para identificar la posible
relacin entre ambas.
Matriz de Valor Agregado:
Permite analizar cada una de las actividades del proceso a partir de dos
dimensiones:
- Agrega valor al proceso.

- Es o No es necesaria para el proceso.
Las combinaciones de estas dos dimensiones son:
- S agrega valor y S es necesaria.

- No agrega valor pero S es necesaria.
- S agrega valor pero No es necesaria.
- No agrega valor y No es necesaria.
Y utilizamos la siguiente tabla para determinar si una actividad agrega o

no valor al proceso y que hacer en cada caso.
74
Diagramas de Flujo:
Muy utilizados en las fases de anlisis y levantamiento de procesos para

compartir con distintos usuarios involucrados en el proceso, dibujar conjun-
tamente el flujo de ste y poder visualizar mejoras o defectos sobre los
procesos de forma grfica.
Los diagramas de flujo representan las relaciones entre las etapas de un

proceso donde lo importante es mostrar los puntos de decisin (mediante
rombos), las actividades (cuadrados) y la secuencia de estos, ayudndonos
a anticipar problemas que puedan ocurrir en los procesos.
75
76
Captulo 2. Los caminos hacia BPM
Captulo 2. Los caminos hacia BPM.
El cmo se ha llegado hasta BPM es fruto de un largo recorrido tanto en

disciplinas de gestin y organizacin de empresas, como tecnolgicas, de
desarrollo de estndares y de metodologas, donde la columna vertebral de
esta evolucin, o el ADN que la ha dirigido, ha sido la innovacin y la focali-
zacin en el cliente. Haciendo una comparacin con la teora de la evolu-
cin de Darwin, si sta ha sido dirigida por la seleccin natural, la evolucin
en las teoras de gestin que han llevado al desarrollo de BPM ha sido diri-
gida principalmente por la orientacin a un cliente cada vez ms valioso
pero tambin ms exigente.
Howarth Simth y Peter Fingar en su importante libro Business Process

Management: The Third Wave, describen el camino hasta llegar a BPM
como el resultado de tres olas:
- Primera Ola: que comenz en la primera parte del siglo XX y

centrada en la bsqueda de eficiencia en las operaciones del da
a da. Los trabajos de Frederick Taylor y de Henry Ford en las l-
neas de montaje con la especializacin del trabajo.
- Segunda Ola: con la paquetizacin de las aplicaciones de soft-
ware empresarial (ERP, CRM, SCM, HR, etc.) y la utilizacin de
los procesos de negocio en estas aplicaciones.
77
- Tercer Ola: con la integracin de los esfuerzos anteriores y la

creacin del BPM como visin holstica para la comprensin y
gestin del comportamiento y operativa de las empresas para
ganar en eficiencia y competitividad. Pasando en esta tercera
ola de la visin centrada en los datos y funcional de las organi-
zaciones, a la visin de esta tercera ola centrada en los procesos
de negocio y en la organizacin orientada a procesos.
Orgenes de la gestin empresarial:
Como hemos visto en el captulo anterior, la gestin por procesos es al-

go que consciente o inconscientemente todos hacemos en nuestras organi-
zaciones y la idea de tomar el control de las actividades empresariales a
travs de los procesos que sta ejecuta para alcanzar sus objetivos, no es
nueva y muchos aspectos del actual BPM comenzaron a gestarse ya en el
siglo XVIII con el famoso economista Adam Smith (1723-1790) y su teora de
la especializacin del trabajo. Posteriormente, Frederick Taylor (1856-1915)
introdujo los principios inciales de los mtodos de gestin cientficos y
Henry Ford (1863-1947), la idea de la cadena de montaje para la produccin
en masa. Alrededor del ao 1950, los ordenadores comenzaron a influen-
ciar sobre los procesos de negocio, lo que result en un gran cambio en la
organizacin del trabajo que facilit nuevas formas de hacer negocios pero
tambin, una mayor dependencia de los sistemas informticos y la tecnolo-
ga por la creciente complejidad de los nuevos modelos de negocio que iban
surgiendo.
Con el avance de las teoras de gestin, los procesos iban al mismo

tiempo adquiriendo mayor relevancia como disciplina a travs de la cual
gestionar la complejidad de las organizaciones y su entorno cada vez ms
cambiante. Al principio, las primeras aproximaciones a BPM fueron muy
simples y estaban centradas bsicamente en la mejora de procesos produc-
tivos y de manufactura, hasta que en los aos 90, se produjo un salto im-
portante de acercamiento a BPM con la aparicin de BPR (Business Process
Reenginering) y su bsqueda de la reduccin de tiempos, costes y la elimi-
nacin de las tareas que no aportaban valor al cliente. Pero los problemas
en la implementacin de BPR, por su falta de visin global, alejamiento de
las personas y la dificultad de trasladar los requerimientos de negocio a
especificaciones de TI (Tecnologas de la Informacin), contribuyeron a ace-
78
lerar el camino hacia una aproximacin ms holstica y conjugadora de BPR

con otras teoras de gestin que finalmente conduciran a BPM.
Adam Smith.
La teora de Adam Smith es la teora de la especializacin del trabajo a

travs de la definicin de puestos y tareas desempeados por diferentes
personas. Adam Smith, entendi que la produccin en masa requera de
nuevos mtodos de organizacin del trabajo. En su libro The Wealth of
Nations (1776), Smith reconoca que la divisin del trabajo era esencial
para incrementar la productividad de los trabajadores. Sus teoras se gesta-
ron mientras observaba a los trabajadores en una fbrica de alfileres en
Francia. Smith observo que si en lugar de que un trabajador hiciera todos
los alfileres, divida el trabajo, especializando a los trabajadores en diferen-
tes tareas especficas del proceso de produccin, consegua mejoras en la
produccin, debido principalmente a la mayor destreza de los trabajadores
en sus tareas y obteniendo como resultado de ese cambio producir 240
alfileres ms en el mismo tiempo y con el mismo nmero de trabajadores.
Adam Smith fue uno de los primeros en describir los procesos sealando
los mtodos de produccin, los objetivos y medidas en los procesos. Sus
teoras transformaron completamente los mtodos productivos creando
una autntica revolucin en la reorganizacin de empresas e industrias que
todava sobrevive despus de ms 200 aos.
Frederick Taylor.
La siguiente gran revolucin en las teoras de gestin fue la de Frederick

Taylor. Taylor expandi la idea de la especializacin del trabajo de Smith
con la introduccin de mtodos cientficos para la medida de los procesos
productivos y de manufactura. En su libro The Principles of Scientific Ma-
nagament (1911), Taylor coment la necesidad de las empresas de elimi-
nar ineficiencias de produccin y mejorar la divisin del trabajo, proponien-
do tcnicas y herramientas de gestin cientficas para distintos aspectos de
la gestin empresarial: estandarizacin de procesos y tiempos productivos,
estandarizacin de materiales, equipamientos y mtodos de trabajo, mto-
dos para seleccionar a los mejores trabajadores para cada tarea, proporcio-
narles la formacin necesaria y el entrenamiento especfico para los distin-
tos perfiles de trabajadores, de forma que estos ejecuten las tareas repeti-
tivas que cada uno tiene que realizar en el proceso de la forma ms eficien-
79
te y proponiendo el alineamiento del salario de los trabajadores a sus nive-

les de produccin.
Taylor abogaba por la simplificacin de los procesos, por la experimen-

tacin e investigacin sobre estos y por la toma de medidas para su evalua-
cin en la bsqueda del mejor camino para ejecutar los negocios, centrn-
dose en las tareas de manufactura y en el uso de herramientas estadsticas
para evaluar estas tareas con objeto de maximizar los beneficios, mejorar la
eficiencia y minimizar los costes.
Al igual que las ideas de Adam Smith, las propuestas de Taylor fueron
abordadas por prcticamente todas las empresas del mundo y sus ideas
todava se siguen utilizando. Sin embargo, la realidad hoy, es que las teoras
de Smith y Taylor fueron muy tiles en el siglo XIX, donde los productos
necesitaban pocos pasos para ser elaborados, pero usar las teoras de Smith
y Taylor en las empresas modernas ha resultado ser ineficiente, principal-
mente por la interrelacin entre los distintos pasos para elaborar un pro-
ducto o servicio al cliente. Actualmente los trabajadores necesitan de un
conocimiento global de los distintos pasos, mayores habilidades y compe-
tencias y donde la informacin sobre la totalidad del proceso resulta vital
para poder atender las demandas de produccin y servicio al cliente.
Henry Ford.
Henry Ford encontr distintos usos para las teoras de Taylor. Cuando
fund Ford Motor Company en 1913, Ford se propuso llevar el automvil a
las masas ofreciendo un coche competitivo y asequible. Para lograr este
objetivo, ofreci un slo modelo de coche para todos los clientes, el Mode-
lo T de color negro, igual para todos. Esta idea junto con la adopcin de la
cadena de montaje en la que se mova el coche en lugar de moverse los
trabajadores, el diseo de un proceso (una secuencia de actividades) que le
permita fabricar coches ms rpidamente y a precios asequibles, revolu-
cion el sector del automvil, permitiendo fabricar grandes cantidades de
automviles que rpidamente se popularizaron y le permitieron llegar a un
gran mercado de masas.
80
Teoras Modernas de Gestin de Procesos.
Las ideas de Adam Smith y la especializacin del trabajo, de Henry Ford y

la cadena de montaje, y de Frederick Taylor con sus mtodos cientficos de
produccin, fueron exitosas en la era industrial, dominada por los monopo-
lios de mercado y la produccin en masa, en la que los clientes no tenan
acceso a la informacin de otros productos y servicios existentes en el mer-
cado y la competencia apenas exista. Estos modelos productivos fueron
exitosos en su poca pero no resultan eficientes para las empresas de hoy
en da donde superada la era industrial, nos enfrentamos a nuevos retos de
mercados mucho ms competitivos en los que los clientes son cada vez ms
exigentes y demandan mayores niveles de calidad e innovacin. Los nuevos
mercados requieren de organizaciones ms flexibles y rpidas en adaptarse
a las exigencias constantes del mercado, la competencia y los clientes.
Despus de la Segunda Guerra Mundial, los Estados Unidos de Amrica,

con el Plan Marshall, lograron convertirse en la primera economa mundial,
proveyendo de productos y servicios a una Europa devastada por la guerra.
Se fabricaba y venda de todo y en grandes cantidades, por lo que apenas
haba requerimientos de calidad. Pero este perodo de crecimiento en los
Estados Unidos, termin con la crisis de los aos 70, el entorno econmico
cambi, y la competencia se increment principalmente por parte de em-
presas japonesas y alemanas. La economa mundial estaba en crecimiento y
el nmero de personas con poder adquisitivo aument extraordinariamen-
te, por lo que los consumidores comenzaron a demandar productos y servi-
cios cada vez ms innovadores y de mayor calidad. Los consumidores ya no
estaban satisfechos con lo que les vendan las empresas (la idea del coche
Modelo T de color negro para todos, de Henry Ford, ya no era vlida para
estos nuevos clientes).
Esta nueva situacin produjo cambios en la forma en que las empresas

operaban hasta entonces, pues requera de la orientacin a un cliente que
demanda cada vez mayores niveles de servicio, atencin, tiempos de entre-
ga ms cortos y productos de alta calidad que satisfagan sus necesidades y
experiencias de compra. Es en este nuevo entorno donde se produjo el giro
de las empresas hacia un replanteamiento de sus organizaciones y procesos
de negocio para hacer frente a estas exigencias en un camino que todava
hoy no ha finalizado.
En este camino del desarrollo empresarial que sigui a la segunda guerra

mundial, aparecen teoras como la de Peter Drucker en 1954, sobre los
81
trabajadores del conocimiento, en contraste a los trabajadores especializa-

dos de Taylor y sus teoras sobre la direccin por objetivos. Se desarrollan
los conceptos de gestin de la calidad de William Edwards Deming, que ms
que centrarse en el enfoque productivo, se centraban en el aprovechamien-
to y mejora de la calidad. En 1985 Michael E. Porter introdujo por primera
vez el concepto de cadena de valor, mediante el cual se descompone la
empresa en sus partes constitutivas, buscando identificar fuentes de venta-
ja competitiva en aquellas actividades que generan valor y las cuales se
consiguen cuando la empresa desarrolla e integra las actividades de su ca-
dena de valor de forma menos costosa y ms diferenciada que sus rivales.
Otra persona, cuyos estudios aportaron importantes teoras sobre cmo

organizar las empresas, disear los procesos y los puestos de trabajo y ava-
laron fuertemente la orientacin a procesos fue Geary Rummler en los aos
80. Rummler era un psiclogo que investigaba sobre temas de mejora de
las capacidades de las personas en las empresas, llevando sus conclusiones
hacia la necesidad de ver las organizaciones como sistemas y la necesaria
orientacin a procesos para evitar los problemas que surgen en las organi-
zaciones funcionales.
Las teoras de Rummler y en especial la de la organizacin de la empresa

entorno a procesos, fueron la primera aproximacin hacia la revolucionaria
propuesta de Michael Hammer y James Champy de la reingeniera de pro-
cesos o BPR (Business Process Reenginering), aparecida en los aos 90.
Segn Hammer y Champy, la reingeniera es: la revisin fundamental y el
rediseo radical de procesos para alcanzar mejoras espectaculares en me-
didas crticas y contemporneas de rendimiento, tales como costos, calidad,
servicio y rapidez.
La reingeniera surge como herramienta para la mejora de procesos par-

tiendo de un cambio radical en los mismos. Esta teora fue la precursora en
sealar la necesidad de la tecnologa y de las TI en particular, para la mejora
de los procesos, la automatizacin de los mismos y el aumento de la pro-
ductividad. Hoy en da a nadie escapa esta necesidad de las TI para la com-
petitividad de todo tipo de negocios, en especial con el avance de internet y
el surgimiento de nuevos modelos de negocios surgidos a travs de esta
tecnologa, pero en el momento en que apareci la reingeniera, las TI no
estaban tan evolucionadas como hoy en da y sus posibilidades en conse-
cuencia eran mucho menores. La reingeniera, sin embargo, junto con la
cadena de valor de Porter, sentaron las primeras bases de la necesidad de
82
una visin holstica de los procesos para la obtencin de ventajas competi-

tivas.
Otro personaje importante en recalcar la necesidad de las TI para hacer

frente a este nuevo entorno es Tomas H. Davenport, el cual demostr el
importante papel e importancia que las Tecnologas de la Informacin ofre-
cen como facilitadoras y conductoras de la innovacin, la reingeniera de
procesos y la mejora continua.
TQM (Total Quality Management).
Total Quality Management (TQM) ha sido una de las principales teoras

que ayudaron a las empresas a competir en este nuevo mercado orientado
a los clientes. Propuesta por William Demming en1940, TQM desarroll los
mtodos de control de calidad haciendo uso de las teoras de control esta-
dstico e identificando la gestin por procesos como uno de los mtodos de
gestin fundamentales.
Demming no pudo convencer a los americanos sobre la importancia de

sus teoras de gestin de la calidad, por lo que se fue a Japn como asesor
de un grupo de americanos para ayudar a levantar el pas nipn tras la se-
gunda guerra mundial y fue en este pas, donde Demming consigui imple-
mentar sus mtodos, consiguiendo que en los aos 70, las empresas japo-
nesas comenzaran a obtener muy buenos resultados, por lo que recabo el
inters de las empresas americanas que comenzaron a prestar atencin a
sus mtodos y prcticas relacionadas con la Gestin de la Calidad Total (en
ingls, TQM: Total Quality Management), relacionadas entre otras con la
importancia de la direccin general, el foco en el cliente, los crculos de
calidad, la mejora continua, las aproximaciones bottom-up y el compromiso
de todos los miembros de la organizacin en la mejora de la calidad, los
procesos y productos ofrecidos a clientes.
Los principios fundamentales sobre los que se asienta TQM son:
- Foco en los procesos de trabajo.

- Analizar la variabilidad: las variaciones incontroladas son la primera
causa de problemas de calidad y deben ser controladas por los tra-
bajadores en primera lnea.
83
- Management by fact: los sistemas de calidad deben estar basados

en datos reales y recogidos sistemticamente.
- Aprendizaje y mejora continua: el entrenamiento de los trabajado-
res es una de las bases de la mejora de la calidad y de la mejora
continua.
- Satisfaccin del cliente: el principio ms importante en TQM.
- Mejora continua: esencial para el sostenimiento de la empresa de
forma que la empresa est constantemente mejorando su calidad,
productividad y eficiencia.
- El coste de una baja calidad es mucho mayor que el de su imple-
mentacin.
- La direccin general es la que tiene la responsabilidad de la gestin
de la calidad y su compromiso es crucial para el xito de implemen-
tar polticas de calidad en la empresa.
- Empleo de mtodos cientficos para monitorizar la calidad e identi-
ficar reas de mejora. (Pareto: usado para determinar los pocos fac-
tores que contribuyen de forma significativa a los problemas de ca-
lidad, diagramas de flujo, brainstorming, diagramas causa-efecto,
benchmarking, mtodo Delphi, etc.)
- Crear un entorno donde no exista el miedo al error o la vergenza.
Eliminar las recompensas a los trabajadores (en TQM estas se ven
como denigrantes para el trabajador).
- Sin requerimientos de clientes (internos o externos), es muy difcil
alcanzar los requisitos de calidad que estos requieren.
- Eleccin de proveedores en funcin de su calidad y no de su precio.
- Deben existir equipos en la empresa que atraviesen todos los de-
partamentos en busca de mejoras de calidad de toda la organiza-
cin, segn Demming muchos de los problemas de las empresas es-
tn en estos cross-boundaries, y es en estos donde se generan los
principales problemas de los clientes.
Un principio fundamental de TQM es el papel de los clientes como rbi-

tros de la calidad. La calidad total busca la satisfaccin de los clientes y me-
diante sta su fidelizacin. Como consecuencia, el diseo de los productos y
servicios, su fabricacin, sistema de entrega a los clientes y servicios de
atencin a los mismos, han de ser considerados de mxima importancia y
cuidados en extremo. Pero puesto que las necesidades de los clientes cam-
bian cada vez con mayor frecuencia, por la presin entre otras de la compe-
tencia, los procesos con los que proveemos de esta calidad deben ser cons-
tantemente modificados para adaptarse a los nuevos requisitos. Kaoru Is-
hikawa, uno de los mentores de la calidad total, ideo un Mtodo sistemti-
84
co de mejora de procesos basado en su famoso diagrama de espina de

pez o diagrama de Ishikawa, en busca de las causas posibles de defectos
para su posterior perfeccionamiento y con el cual numerosas empresas han
conseguido mejorar sus resultados. El esquema de este mtodo es el mos-
trado en el siguiente grfico:
Six Sigma.
Six Sigma es una metodologa para la identificacin y eliminacin de de-

fectos en procesos de manufactura y procesos de negocio, cuyo objetivo es
obtener un 99,99966% de salidas del proceso sin defectos. Esta disciplina
tambin es utilizada para la mejora de procesos, a travs de la reduccin de
la variabilidad de los mismos, consiguiendo reducir o eliminar los defectos
en la entrega de un producto o servicio al cliente.
Six Sigma fue desarrollada por Motorola en los 80 mientras introducan

TQM, a veces es llamada como TQM con esteroides y se convirti en una
muy popular teora de management cuando fue adoptada por Jack Welch
85
en General Electric. Six Sigma es una metodologa para la resolucin de

problemas basada en tcnicas estadsticas y en este sentido puede ser vista
como una evolucin de TQM.
Aunque las teoras para la mejora de las operaciones comenzaron ya con

Frederick Taylor, el cual estaba obsesionado con las medidas de todos los
pasos del proceso productivo y con experimentar nuevas formas de llevar a
cabo estos procesos, estas teoras continuaron evolucionando principal-
mente tras el xito en Japn de las teoras de calidad de Demming y sus
prcticas de control y aseguramiento de la calidad, las cuales se extendie-
ron a todas las organizaciones, desarrollndose iniciativas de control de
calidad como el Control Estadstico de Procesos (SPC: Statistical Process
Control), TQM y Just-in-Time (JIT).
Six Sigma, aunque es una metodologa basada en el control de calidad,

se nos presenta actualmente como la ms completa y ms moderna de las
metodologas anteriores y ha evolucionado no slo hacia el control de cali-
dad, sino tambin hacia la mejora de procesos. Six Sigma es muy buena en
identificar defectos y buscando soluciones para mejorar los procesos. Su
fuerte es analizar muchos factores que puedan influir en un defecto o pro-
blema, buscando el factor exacto que lo produce y encontrando la solucin
y es por ello que se integra perfectamente con BPM, resultando en una
combinacin perfecta usando por ejemplo Six Sigma para la mejora de pro-
cesos que luego sern automatizados y gestionados en BPM y utilizando el
potencial de las herramientas de medicin de Six Sigma, para determinar
medidas e indicadores de los procesos. Adems BPM se alinea perfecta-
mente con Six Sigma adquiriendo conjuntamente un gran potencial, al agili-
zar las herramientas de BPMS una de las tareas ms tediosa y difcil de Six
Sigma como es la recoleccin de datos y donde las plataformas de BPMS
disponen de potentes soluciones para la realizacin de esta tarea.
Como vemos, la premisa principal para Six sigma es el uso del anlisis ri-
guroso de datos en busca de las fuentes de error que provocan variaciones
en los procesos. La metodologa ms empleada por Six Sigma es DMAIC, por
sus siglas en ingls de Define, Measure, Analyze, Improve y Control:
- Define: Definir los requerimientos de clientes para el proceso.

Qu debemos conseguir con el proyecto, el alcance del mismo y
los objetivos a alcanzar, para lo que deberemos entender el
proceso sobre el que trabajaremos y las mejoras que se esperan
del mismo, poniendo especial nfasis en como satisfacer los re-
86
querimientos de los clientes. En esta fase el equipo de mejora

de procesos llega a acuerdos sobre en qu rea centrarse, sobre
los problemas existentes y como los actuales procesos y sus sa-
lidas fallan en satisfacer las necesidades de los clientes.
- Measure: Medir los resultados existentes y compararlos con los
requerimientos de clientes. Las medidas establecidas nos debe-
rn permitir conocer en qu medida satisfacemos los requeri-
mientos de los clientes. El objetivo principal de esta fase es
identificar la localizacin o el origen de los problemas, para lo
que debe entender todo el proceso y las distintas condiciones
en las que opera, de forma que acote los problemas para identi-
ficar el problema y se desarrolle una lnea base de mnimos exi-
gidos al proceso a partir de la cual se identifiquen los problemas
que se salgan de esa lnea base.
- Analyze: Analizar los procesos existentes y el valor que cada ac-
tividad del proceso aporta al mismo, buscando las causas de los
problemas y realizando anlisis estadsticos de los datos para
conocer que variables aportan ms valor, reducen errores e in-
crementan la calidad y eficiencia de los procesos. En esta fase
analizamos las races de las causas de los problemas, que pasa-
rn a ser mejoradas en la siguiente fase.
- Improve: Mejorar el diseo de los procesos e implementarlos,
por lo que primero deberemos comprobar que las mejoras
planteadas en la fase anterior resuelven los problemas identifi-
cados.
- Control: Controlar los resultados. Las soluciones implementadas
pueden resolver los problemas en un momento puntual, pero
mediante el control, nos aseguraremos de que los problemas
no vuelvan a producirse y de esta forma podamos seguir traba-
jando en la mejora de los procesos.
La metodologa DMAIC de Six Sigma es una metodologa iterativa que

nos muestra el camino a seguir para la mejora de procesos. Esta metodolo-
ga ha sido aplicada a todo tipo de organizaciones y se centra en hacer los
procesos de negocio ms predecibles y estables, minimizando las variacio-
nes en las salidas de los procesos y siendo por tanto su misin principal la
mejora de los procesos.
Aunque esta metodologa se centra en la mejora de los procesos exis-

tentes, existe otra metodologa denominada DFSS (Design for Six Sigma),
que se centra en el diseo completo de nuevos procesos o en el total redi-
87
seo de los procesos existentes. Muchos autores y consultores de Six Sigma

recomiendan BPM utilizando Design for Six Sigma (DSS) para el rediseo de
procesos y DMIAC para la mejora de procesos.
Lean Six Sigma.
Six Sigma se asienta sobre una serie de tcnicas estadsticas para la me-
dida de mejoras en los procesos, basndose en las medidas tomadas en las
salidas de estos y realizando modificaciones sobre los mismos para com-
probar las mejoras. Sin embargo, el hecho de que Six Sigma se centre slo
en el control de calidad y en la consistencia de las salidas de los procesos,
siempre ha sido criticado por no abordar la mejora de procesos, por lo que
ha surgido un movimiento que adems de estas actividades de mejora,
centra tambin su atencin en la mejora del flujo de procesos y en la gene-
racin de valor al cliente a travs de la reduccin de los tiempos de entrega
y de los costes de los procesos mediante la eliminacin de desperdicios.
Mientras TQM y Six Sigma se centran en procesos individuales, la metodo-
loga Lean lo hace en toda la cadena de valor, o sea, en todas las actividades
que una empresa debe realizar para producir y entregar sus productos y
servicios a clientes. Este movimiento, denominado Lean, se mantuvo de
forma independiente a Six Sigma, aunque ambos parecen ahora ir de la
mano bajo la denominacin de Lean Six Sigma.
Lean Six Sigma dispone de una empresa llamada Flow Kaizen que se
encarga del rediseo y mejora de procesos de alto nivel en la organizacin a
travs de una visin de su cadena de valor y una metodologa denominada
Process Kaizen para la eliminacin de estos desperdicios en las activida-
des y de las tareas en los procesos que no aportan valor. Kaizen, del japo-
ns Kai que significa continua, y Zen que significa mejora, ms que una
tcnica es una filosofa para la mejora continua, constante e incremental.
Metodologa Lean.
La metodologa Lean es una de las metodologas ms en boga hoy en da

y su objetivo es reducir el tiempo desde el pedido de un cliente hasta el
cobro (time-to-cash), eliminando todos los desperdicios (waste) que no
produzcan valor. Existen 7 tipos de desperdicios que aparecen en los siste-
mas:
1. Sobreproduccin: producir ms de lo necesitado o demandado por

los clientes.
88
2. Esperas: el tiempo durante el cual ningn valor es aportado al pro-

ducto o servicio.
3. Transporte: el movimiento innecesario de piezas o movimientos re-
petitivos que tampoco aportan valor al producto o servicio.
4. Inventario: materia prima innecesaria o almacenamiento de pro-
ductos terminados.
5. Movimiento innecesario de personas que tampoco aade valor.
6. Sobre-procesado: aadir pasos o procesos que no aportan valor,
creyendo que por trabajar ms en algo tendremos ms calidad.
7. Defectos: el trabajo que debe volver a hacerse.
El empleo de la metodologa Lean nos ayuda a entender e identificar

estos desperdicios que pueden ayudarnos en los esfuerzos de mejora de
procesos.
Los 5 principios de Lean son:
1. Especificar el valor. El valor es el punto crtico de comienzo para el

Lean Thinking. El valor slo puede definido a travs del cliente y s-
lo toma significado cuando es expresado en trminos de un produc-
to especfico que cubre las necesidades del cliente en un momento
y a un precio especfico. La pregunta que nos deberemos hacer es:
entendemos verdaderamente el valor desde la perspectiva del
cliente?
2. Identificar los pasos en la cadena de valor. El mapeo de la cadena
de valor es el proceso de detallar y analizar el flujo de materiales e
informacin para producir un producto o servicio al cliente. De esta
cadena de Valor, podremos identificar que acciones producirn va-
lor y cuales no. Las que produzcan valor pueden ser definidas como
aquellas por las cuales el cliente pagara por ellas si conociese los
procesos internos de nuestra organizacin. Las que no produzcan
valor sern aquellas que consuman tiempo, recursos o espacio y no
aadan valor al producto y en consecuencia, tampoco al cliente.
Identificar la cadena de valor expondr muchas actividades que no
aportan valor.
3. Crear un flujo. Una vez entendamos los pasos para la creacin de
valor, el siguiente paso es crear un flujo continuo que reduzca el
tiempo y los desperdicios.
89
4. El principio Pull. Una vez conseguidos los tres principios anteriores,

podemos poner el sistema para producir lo que el cliente requiera,
el Pull System en oposicin al Push basado en predicciones.
5. Buscar la perfeccin. Lean dice que debemos entender continua-
mente el valor a travs de los ojos de nuestros clientes y refinar
nuestra cadena de valor para incrementar el flujo basado en la de-
manda de los clientes. Deberemos movernos hacia la perfeccin. El
proceso de mejora nunca termina.
BPR (Business Process Reenginering)
El planteamiento que veremos ahora es ms radical que los anteriores

de TQM y Six Sigma. Aunque estas ltimas son metodologas que tienen
varias dcadas de recorrido en las empresas y han evolucionado hacia una
aproximacin ms integral basada en procesos, ambas tienen sus races en
los procesos industriales y de manufactura, muy orientados a costes y cen-
tradas en tareas y estructuras organizativas ms que en procesos. Mientras
estas metodologas han abordado tradicionalmente la mejora de procesos
mediante la erradicacin de errores y a travs de mejoras incrementales de
los mismos, la reingeniera de procesos o BPR que veremos en este aparta-
do, propuesta a finales del siglo XX por Hammer y Champy, supone una
revisin fundamental de las estructuras de la empresa a travs de los pro-
cesos, del rediseo radical de estos y el replanteamiento de los procesos
que ejecuta la empresa para conseguir mejoras espectaculares en el rendi-
miento de las organizaciones.
En ocasiones las empresas debemos plantearnos objetivos ambiciosos,

no alcanzables mediante la mejora continua y que suponen un cambio radi-
cal en los procesos de nuestra empresa que afectarn a las actividades que
realizamos y a los recursos que utilizamos. Este cambio puede suponer un
cambio radical dentro de la organizacin y del posicionamiento estratgico
de la misma, pero puede proporcionar mejoras espectaculares en los resul-
tados de la empresa. Este es el punto de partida de la reingeniera de pro-
cesos (BPR), cuya base fundacional, al igual que en la gestin de procesos
parte del anlisis de las necesidades de los clientes y la transformacin de
la empresa para dar soporte a los procesos, de forma que estos maximicen
el valor aportado a los clientes y minimice todo aquello que no aporta valor.
El BPR se orienta fundamentalmente en aspectos relacionados con los

procesos de la empresa y su mejora como la bsqueda sistemtica de cam-
bios que hagan a los procesos cada vez ms eficientes y eficaces o el reem-
90
plazo de procesos secuenciales en procesos paralelos de forma que concen-

tremos los recursos en un solo punto, reduzcamos el nmero de transfor-
maciones, simplifiquemos el proceso y eliminemos los cuellos de botella y
tiempos muertos.
BPR es la metodologa preferida por aquellos que quieren realizar cam-

bios radicales en sus organizaciones mediante el rediseo o reingeniera.
Muchas empresas han optado por la reingeniera o el rediseo completo de
sus procesos empresariales con la idea de que los procesos empresariales
con los que operan son ms el resultado de un accidente, de un cmulo de
circunstancias o de la herencia histrica de la empresa que el resultado de
una planificacin lgica y consciente. El BPR se suele utilizar para repensar
los modelos de negocio de las empresas, implementar nuevas tecnologas o
introducir nuevos procesos, enfatizando mucho el aprovechamiento de
oportunidades y bsqueda de ventajas competitivas a travs de una visin
Top-Down, en lugar de centrarse en el ahorro de costes y en la mejora de
las actividades de bajo nivel.
Para conseguir la reingeniera de los procesos empresariales, se siguen

una serie de prcticas y principios como los siguientes:
- Organizarse en torno a los resultados y a como estos se generan

y no en torno a las tareas.
- Hacer que los que utilizan las salidas del proceso sean quienes
trabajen en el rediseo del mismo.
- Llevar los puntos de decisin al lugar donde se realiza el traba-
jo, para evitar interrupciones en el flujo de trabajo por la nece-
sidad de aprobaciones que se encuentran fuera de donde real-
mente se realiza el trabajo.
- Capturar la informacin en el origen y una sola vez para evitar
la duplicidad de informacin.
- Evitar el realizar el rediseo de procesos empresariales como un
re-empaquetado de lo que ya exista en la empresa.
El BPR puede ser de dos formas:
- Fundamental: donde pensamos en por qu hacemos las cosas, si

existen formas mejores de hacerlas y nos cuestionamos los fun-
damentos sobre los que se asienta nuestra empresa.
- Radical: donde nos planteamos hacer las cosas de forma com-
pletamente diferente y abandonamos los antiguos procesos, lo
que implica transformar la organizacin para realizar las cosas
91
de forma completamente distinta: abandonamos lo viejo, des-

cartamos lo existente y transformamos los procesos existentes
de forma radical para llegar a formas completamente nuevas de
hacer las cosas.
Muchos autores recomiendan usar BPR slo para realizar cambios radi-
cales ms que para hacer arreglos en los cuellos de botella o problemas que
podamos encontrar en los procesos, y dejar estas tareas para metodologas
como Six Sigma. Autores como Peter Drucker y Tom Peters abogaron por la
Reingeniera de Procesos como herramienta para lograr el xito en un
mundo dinmico, pero fueron Thomas Davenport y James R. Short quienes
ms desarrollaron esta metodologa y la enlazaron con las Tecnologas de la
Informacin, afirmando que de esta combinacin de TI y reingeniera de
procesos, se podra transformar las organizaciones y mejorar sus procesos
de negocio a un nivel parecido al que supusieron las teoras cientficas de
Taylor un siglo antes.
Davenport y Short elaboraron una metodologa en 5 pasos para BPR:
1. Establecer la visin de negocio y los objetivos de procesos: en

lugar de racionalizar las tareas para eliminar problemas y cuellos
de botella, como se haca en anteriores rediseos de procesos,
ellos sugieren que el rediseo se debe realizar en los procesos
para alcanzar la visin de negocio y los objetivos planteados.
2. Identificar los procesos que deben ser rediseados: parecido al
anlisis de Pareto practicado en TQM y consistente en no redi-
sear todos los procesos, sino por el contrario, centrarse en los
procesos clave que mayor impacto tienen en la organizacin.
3. Entender y medir los procesos existentes: entender los proble-
mas y crear una lnea base para medir las futuras mejoras.
4. Identificar como podemos apoyarnos en las TI para el rediseo
de procesos.
5. Implementar un prototipo del proceso: antes de su implementa-
cin, el cual deber servir como base para las futuras mejoras.
Al mismo tiempo que Davenport y Short publicaban sus ideas sobre TI y

reingeniera de procesos, Michael Hammer publicaba su radical concepcin
de BPR sentenciando: la racionalizacin de procesos y esfuerzos de auto-
matizacin de los pasados aos no han significado grandes mejoras en la
productividad. Hammer crea que las empresas estaban slo automatizan-
do procesos diseados con anterioridad al uso de los ordenadores y este
92
tipo de automatizacin tiene limitaciones, por lo que las empresas necesi-

tan cambiar radicalmente sus procesos de negocio para sacar todas las ven-
tajas de los ordenadores. Al mismo tiempo, Hammer consideraba que la
mayor parte del trabajo que estaban haciendo las empresas no agregaba
valor a los clientes, por lo que estas tareas y procesos deban ser eliminados
y no ser acelerados en su desarrollo a travs de la automatizacin. Hammer
abogaba por que la reingeniera fuese cross-functional (atravesar las unida-
des funcionales de la empresa) y utilizar las TI para poder obtener benefi-
cios de los esfuerzos de reingeniera.
En el libro Reenginering the Corporation: A Manifesto for Business Re-

volution escrito por Hammer conjuntamente con Champy, estos autores
desmitificaban la teora de la especializacin del trabajo de Adam Smith y la
organizacin funcional jerrquica inherente a sta. Establecan que la nueva
economa post-industrial que comenz en los aos 80, es diferente a la
economa de produccin en masa anterior y en esta nueva economa, los
clientes tiene la sartn por el mango, la competencia se ha intensificado y el
cambio constante es algo normal en la gestin de las empresas. Hammer y
Champy afirmaban que para competir en esta nueva economa, las empre-
sas deben reinventar el cmo realizan sus tareas y en lugar de abordar me-
joras incrementales en sus procesos de negocio, necesitan inventar mejores
formas de realizar estos, para lo que es necesario realizar cambios radicales
que les permitan alcanzar grandes mejoras en aspectos como costes, cali-
dad, servicio, velocidad y agilidad para poder llegar al mercado y sobrevivir
en este.
El objetivo ltimo de BPR era la organizacin orientada a procesos, la

empresa organizada alrededor de los procesos y no de las tareas, funciones
o departamentos. En estas organizaciones, los trabajadores deben ser pre-
parados y formados para desarrollar todas las tareas del proceso y no slo
las de los pasos intermedios del mismo. En otras palabras, la especializacin
del trabajo expuesta por Smith, Taylor y Ford, deba ser desmantelada. En
su forma ms radical, la empresa centrada en los procesos es aquella que
elimina la estructura funcional a favor de una estructura exclusivamente
basada en procesos, en la que desaparecen los departamentos en beneficio
de los equipos de procesos y donde la excelencia funcional de los departa-
mentos, las unidades de negocio y la especializacin del personal de los
departamentos, es sustituida por la mejora de la comunicacin y colabora-
cin entre las personas involucradas en el proceso de negocio y la sensibili-
dad a los requerimientos del cliente.
93
En esta visin de la reingeniera, podemos ver reflejada la visin holstica

de la empresa que nos conducir a BPM, a travs del prisma de la organiza-
cin horizontal y orientada a procesos, donde los procesos se convierten en
los principales instrumentos de la empresa para proporcionar los productos
y servicios a sus clientes. Para la reingeniera, el rediseo radical de estos
procesos es el camino hacia el xito en las empresas, el camino de la dife-
renciacin, de la agregacin de valor y de la bsqueda de ventajas competi-
tivas a travs de la atencin a los requerimientos del mercado.
BPR Revisionista:
La reingeniera, como vemos, es una metodologa apropiada no slo pa-

ra revisar y redisear procesos enfocndose en agregar valor a cada uno de
los pasos de un proceso y eliminar aquellos que no aporten valor, sino tam-
bin para catalizar la generacin de organizaciones horizontales y orienta-
das a procesos. Sin embargo, BPR no consigui cumplir en muchas de sus
implementaciones con las grandes mejoras que prometa en las empresas.
Aunque en las implementaciones donde tuvieron xito, este fue impresio-
nante, muchas de las soluciones de reingeniera fracasaron o fueron sim-
plemente empleadas para justificar el despido de personas en base a la
optimizacin de los procesos. Visto en el tiempo, la principal causa de fraca-
so de BPR ha sido el no acompaar estos cambios radicales propuestos con
prcticas de gestin de personas, gestin del cambio, de mentalidad y cul-
tura corporativa, comprobndose en especial, la fuerte resistencia de los
trabajadores de primer nivel y mandos intermedios a los cambios propues-
tos por la reingeniera. La falta de foco en el lado humano del cambio (la
gestin del cambio y las personas) ha sido el mayor problema para afrontar
los proyectos de BPR con garantas suficientes de xito. De este lado huma-
no y de gestin del cambio no fue consciente Michael Hammer en sus estu-
dios y ser un aspecto que recoger con fuerza BPM hasta el punto de con-
siderarlo ms importante incluso que las propias soluciones BPM que se
vayan a implementar.
De los fracasos ocurridos en las implementaciones de BPR, surgi el lla-

mado BPR Revisionista, el cual prestaba ms atencin al entorno cultural de
la empresa y en especial a las personas y la gestin del cambio, envolviendo
en los proyectos de BPR a la reingeniera, la tecnologa y el entorno cultural
de la empresa. Este BPR Revisionista limit tambin el alcance de las solu-
ciones e implementaciones a realizar con BPR. Mientras BPR piensa en
94
cambiar toda la organizacin y en el rediseo completo de la misma y la

forma en que esta realiza su negocio, lo cual muchas veces ha sido visto
como demasiado arriesgado y radical, el BPR Revisionista tiene menor al-
cance, se centra en proyectos ms pequeos y piensa slo en cambiar una
pequea parte o aspecto de la organizacin.
Sobre la conveniencia de uno u otro (BPR vs. BPR Revisionista), podemos

hablar largo y tendido, pero todo depender del entorno y la necesidad de
cambio que requiera cada negocio o empresa. En algunos casos nos bastar
con el BPR Revisionista para mejorar la eficiencia de algn aspecto o proce-
so especfico de la organizacin y en otros, generalmente por las circuns-
tancias y exigencias del mercado, requeriremos de cambios ms profundos
que rediseen y re-posicionen nuestra empresa en el mercado, transfor-
mando radicalmente sus productos, servicios y procesos. Lo que s es segu-
ro, es la necesidad de contar con las personas y una correcta gestin del
cambio, algo simple de decir pero muy difcil de implementar, pues muchas
veces se requerir para ello de un cambio cultural e incluso de mentalidad,
que no todas las organizaciones sern capaces de afrontar.
Con frecuencia hablamos de innovacin en las empresas, pero esta in-

novacin requerir de dinmicas innovadoras, hablamos tambin de cam-
bio, pero no nos planteamos cambios estructurales, an sabiendo de su
necesidad como nica salida a una situacin del entorno completamente
nueva y diferente en la que no encaja nuestro modelo de negocio tradicio-
nal. Los cambios no son siempre bienvenidos, o lo son slo cuando los plan-
teamos de arriba hacia abajo en la estructura organizacional, pero no cuan-
do estos ataen a las bases mismas de la empresa, sus modelos de negocio,
su cultura y estructura organizacional, y en esta barrera de los niveles supe-
riores de la empresa es donde el BPR tambin ha chocado, pues no slo
encontr dificultades en los empleados y mando intermedios como antes
comentbamos, sino tambin en los niveles directivos y gerenciales, que lo
utilizaron para transformar las estructuras intermedias y bajas de la organi-
zacin donde esta metodologa result idnea para la optimizacin de sus
procesos y la eliminacin de puestos de trabajo.
La irrupcin de la Tecnologa:
Aunque Michael Hammer critic el uso de las TI para la automatizacin

de procesos cuando ste se realizaba previamente a la creacin primero de
ms modernos y eficientes procesos, tanto Hammer como Davenport y el
95
movimiento de BPR en general, enfatizaron la tecnologa y ms concreta-

mente la informtica, como imprescindible para la gestin de procesos y la
gestin del cambio, considerndola esencial en la nueva era industrial.
Anteriormente, e incluso durante la poca en la que se desarroll el BPR,

las Tecnologas de la Informacin estaban diseadas para satisfacer a de-
partamentos concretos o unidades de negocio a travs de soluciones espe-
cficas para cada una de stas. Esta especializacin tecnolgica por depar-
tamentos cre barreas organizacionales, pues los datos quedaban en silos
departamentales, ocultos al resto de la organizacin, que adems compli-
caban enormemente las arquitecturas informticas necesarias para el esta-
blecimiento de las necesarias comunicaciones entre datos y aplicativos des-
arrollados ad hoc y aislados unos de otros. El desarrollo de las bases de
datos relacionales y el uso de bases de datos comunes ayud a eliminar
estas barreras y ofreci la posibilidad de redisear los procesos completos
de la empresa sin las limitaciones de los sistemas informticos y departa-
mentos funcionales, dejando las TI de ser percibidas nicamente como el
back-office y el repositorio de datos que no contribua a la mejora y la com-
petitividad de las empresas.
El empujn definitivo a las TI como actores importantes para la gestin

de las organizaciones y de los procesos, lo dio Michael Hammer en sus lti-
mos trabajos, donde hablaba de la gestin por procesos como el paraguas
bajo el cual TQM, Six Sigma y BPR podan trabajar juntos, afirmando que el
paraguas bajo el que se producir esta convergencia seria BPM, en el que
las tres metodologas se unirn a las TI para dar inicio a un nuevo paradig-
ma tecnolgico, donde los diseadores de procesos de negocio estaran
directamente involucrados en el diseo de sistemas y soluciones de TI y
viceversa.
En BPM, nos encontramos con diferentes perspectivas que ms que fu-

sionar o centrarnos en alguna de ellas (TQM, Six Sigma, BPR, BPR Revisionis-
ta, TI, etc.), deberemos escoger lo mejor de cada una de ellas segn lo que
necesitemos hacer en cada momento y escenario. Cuando corren tiempos
difciles, las metodologas de ahorro de costes adquieren protagonismo y
cuando la economa est en crecimiento, las empresas lanzan nuevos pro-
yectos, compran empresas y se introducen en nuevos mercados, sin em-
bargo, debemos tomar la recomendacin de Michael Hammer de que hay
momentos en los que son necesarios grandes cambios y en otros cambios
graduales, y en funcin de ello, podremos optar por una u otra perspectiva
y combinar por ejemplo perspectivas Bottom-Up de Six Sigma, con otras
96
Top-Down como en BPR y aadiendo metodologas de TI. En la prctica, la

gente de TI se ha sentido ms cmoda con BPR, pues es una tendencia de
los analistas y programadores el preferir hacer las cosas desde cero que
modificar o corregir lo ya realizado (especialmente cuando son otros lo que
lo han realizado) y el rediseo radical y centrado en nuevos proyectos plan-
teado por BPR, result ms abarcable y realizable desde el punto de vista
de la ingeniera de software.
No me gustara dejar este recorrido sin hablar de la Teora de las Limita-

ciones, que si bien no suele acompaar a BPM en los manuales sobre esta
disciplina, si considero que puede ayudar al lector a disponer de una pers-
pectiva ms amplia sobre la gestin por procesos.
Teora de las Limitaciones (TOC).
La Teora de las Limitaciones (TOC - Theory of Constraints), fue creada en

1970 por el fsico Eliyahu M. Goldratt en su famosa novela empresarial La
Meta. TOC ha sido aplicado con xito en multitud de empresas y organiza-
ciones, habindose obtenido muy buenos resultados con su aplicacin en la
reduccin de inventarios, incremento de ventas, cumplimiento de fechas de
entrega y otros mbitos relacionados con la gestin y mejora de procesos.
Las enseanzas y libros de Goldratt son extremadamente ilustrativos al

respecto, en La Meta, a la pregunta de cul es el objetivo de cualquier
empresa, se deja claro que no se puede mejorar si no se sabe cul es el
objetivo ltimo que se persigue con la mejora y resolviendo que la meta de
una empresa es ganar dinero ahora y en el futuro y que todo lo que se haga
para acercarnos a esa meta estar bien y todo lo que se aleje, ser negativo
para la misma.
Goldratt analiza los obstculos que impiden a una empresa acercarse a

esos objetivos y que son las restricciones o cuellos de botella que marcan el
ritmo del proceso. El objetivo de esta teora es que las empresas ganen
dinero para lo cual:
- Las empresas deben maximizar sus ventas (throughput) asegu-

rando su presencia en el mercado.
- Reducir los inventarios (el coste de los materiales almacena-
dos).
97
- Minimizar los gastos operacionales (los gastos asociados a

transformar los inventarios en throughput), que incluye los cos-
tes directos, indirectos y de los activos de la empresa.
Goldratt expone en su teora los pasos a seguir en orden correlativo, que

nos permitirn alcanzar ese objetivo:
1. Identificar las restricciones del sistema y que limitan el proceso.

Estos son los recursos con capacidad limitada y segn Goldratt,
slo existe un nico recurso con la capacidad ms pequea. Para
identificarlo, analizaremos el cociente entre la carga (la suma del
tiempo de procesamiento) y la capacidad de los recursos (el
tiempo del que dispone el recurso para realizar esa tarea).
2. Decidir como explotar estas restricciones y como obtener el ma-
yor rendimiento posible de estas y de los cuellos de botella, de
forma que estos pasen a operar al 100% de su capacidad.
3. Subordinar todo a la decisin anterior, de forma que todo el
proceso vaya al ritmo (Drum; Tambor, en ingls) de la restriccin
y utilizando un Buffer de tiempo para proteger al cuello de bote-
lla.
4. Elevar la capacidad de las restricciones del sistema, por ejemplo
comprando ms maquinaria o contratando ms personal, para
aumentar la capacidad de la restriccin.
5. Si en los pasos anteriores se ha eliminado una restriccin, como
era el objetivo, regresar al paso 1 en busca de nuevas restriccio-
nes, pero nunca permitir la inercia del proceso, trabajar en la
mejora continua de los procesos y seguir buscando los siguien-
tes cuellos de botella.
Como vemos, en TOC se trabaja en la optimizacin de la produccin y los

recursos en base a los cuellos de botella o restricciones y en la forma en
que estos se gestionan. En lugar de maximizar el rendimiento individual de
todos los recursos (pensamiento cartesiano), opta por el pensamiento sis-
tmico, segn el cual, el rendimiento mximo de un sistema no se alcanza
mediante el rendimiento individual de cada uno de los recursos, sino que
slo unos pocos tendrn que funcionar al mximo de su capacidad para
obtener todo lo que se espera del sistema, de forma que maximicemos los
ingresos (el throughput), al tiempo que reducimos los inventarios y los gas-
tos operativos (al no tener que tener todas las unidades de negocio y recur-
sos al mximo de su capacidad), ya que slo algunos de los recursos, los
cuellos de botella o restricciones, condicionarn la salida de toda la produc-
98
cin. Estas restricciones o cuellos de botella son los llamados Drums (tam-
bores), pues sern ellos los que marcarn el ritmo de produccin.
Para entender esta operativa, podemos recurrir a un ejemplo bastante

ilustrativo narrado por Goldratt en su primer libro titulado La Meta, don-
de se cuenta la experiencia de un grupo de Boy Scouts que deben realizar
una marcha con un inicio y un final en un determinado tiempo. El problema
que se les presenta es que uno de los nios presenta sobrepeso, su marcha
es ms lenta que la de los dems, por lo que siempre va el ltimo y el resto
de compaeros deben esperar por l. Como el objetivo es que lleguen to-
dos al mismo tiempo, Goldratt demuestra que la mejor solucin es poner al
nio ms lento como el primero en la marcha, pues este es el que marca el
ritmo, y por muy rpido que los dems vayan, si este primero no llega, no
se cumplir el objetivo de la misin de llegar todo el grupo junto. Para qu
hacer correr al resto de miembros del grupo (sobre-produccin), si cada
cierto tiempo estos deben esperar por el nio ms lento (cuello de botella)?
Este ejemplo lo compara Goldratt con lo que ocurre en muchas fbricas en
su ritmo de produccin, por ejemplo, en los retrasos por falta de material o
debidos a una avera, que se convierten en los cuellos de botella o restric-
ciones del proceso.
Segn la teora de Goldratt existen dos tipos de limitaciones en los sis-

temas:
- Limitaciones polticas: todas aquellas que evitan que la empresa

alcance su meta (restricciones laborales que no nos permitan
hacer horas extras o restricciones comerciales como no poder
vender a plazos). Para identificar y resolver estas limitaciones el
Instituto Goldratt propone varias tcnicas como son:
o El rbol de realidad: para mostrar los efectos indesea-
bles observados en el proceso por medio de relaciones
de causa-efecto.
o Exploracin en nubes: para eliminar conflictos, en los
que no se busca la negociacin a un problema sino
identificar los cambios que pueden eliminar el conflicto
(evaporar la nube).
o rboles de realidad futura: que utiliza el ciclo de De-
ming para evaluar soluciones.
o rboles de pre-requisitos: para identificar y relacionar
los obstculos que se encontraron al implementar la so-
lucin
99
o rboles de transicin: para una vez identificadas las

causas raz de los efectos indeseables y sabiendo donde
queremos estar en el futuro, se determinan las acciones
necesarias para alcanzar los objetivos y se establecen
los objetivos intermedios. El rbol de transicin es el
rbol de como haremos para pasar del estado actual
al futuro deseado.
- Limitaciones fsicas: como equipos, instalaciones, escasez de
materias primas o recursos humanos que evitan que el sistema
cumpla con su meta de negocio y se identifican despus de las
restricciones polticas. Existen dos maneras de explotarlas:
o Aadir mayor capacidad (contratar ms personal o ad-
quirir ms equipos).
o Aprovechar al mximo la capacidad del sistema (mejo-
rar la eficiencia en la gestin)
TOC dispone tambin de indicadores para los procesos como son el

throughput para el dinero que ingresa, indicadores para para el inventario y
para los gastos operativos. Estos indicadores nos permitirn medir el avan-
ce hacia los objetivos en la medida que se aumente el throughput y se dis-
minuyan el Inmovilizado y los gastos operativos.
- Throughput: es la velocidad a la cual es sistema genera dinero a

travs de las ventas. Tambin denominado Valor Generado (VG).
- Inventario: es todo el dinero que el sistema ha invertido en
comprar cosas que espera vender o tiene la posibilidad de ven-
der.
- Gastos de operacin: el dinero que la empresa gasta en trans-
formar el inventario en througput.
Como vemos, TOC tiene una estrecha relacin con la gestin por proce-
sos, tanto a nivel de indicadores de medida de procesos, como en el esta-
blecimiento de reglas de negocio. Adems, las tcnicas para identificar cue-
llos de botella en nuestras tareas y procesos, nos ayudarn en la tarea de
mejorar estos procesos. El throughput, visto como la salida del proceso
menos las entradas del mismo, puede ser utilizado para maximizar el ren-
dimiento de nuestros procesos y si vemos que el throughput es menor de lo
esperado o requerido por el proceso, identificar en que partes del proceso
se estn consumiendo tiempo o dinero, utilizando las metodologas y
herramientas de TOC, de forma que consigamos obtener buenos procesos
100
funcionando y que segn TOC, sern aquellos capaces de producir un alto

throughput por unidad de tiempo sin consumir excesivos recursos.
Hacia una teora unificada.
Desde un punto de vista terico, todas las teoras y disciplinas vistas en

este captulo, tienen al cliente como foco principal y se centran en la mejora
de procesos como el camino que las empresas deben usar para su mejora
competitiva. En todas las teoras analizadas anteriormente subyace la orien-
tacin a procesos, en las ms antiguas de forma tmida y como crticas a las
teoras de Taylor de la organizacin del trabajo, pero a medida que avan-
zamos en el tiempo y las teoras se adaptan y desarrollan, esta orientacin,
como si de una epifana se tratase, parece consolidarse.
Una de las primeras filosofas que empez a cuestionarse la tradicional

organizacin funcional propuesta por Frederick Taylor fue el Just in Time,
que mediante su bsqueda de la excelencia mediante la continua elimina-
cin de todo lo que no agrega valor al producto, propona el eliminar el
desperdicio en los procesos por la reduccin del tiempo de ciclo, defectos,
inventarios, etc. Ms tarde se vuelve a hablar de procesos con la Calidad
Total, en donde Ishikawa replanteaba el viejo concepto de Control Total de
la Calidad por el concepto de Control de Calidad Total a lo largo y ancho
de toda la empresa. Ishikawa dice: la siguiente etapa en el proceso es su
cliente y no se trata de inspeccionar totalmente los productos al final de
la lnea, lo que se necesita es el control de los procesos.
El control estadstico de procesos dio otro fuerte impulso a la gestin

por procesos, Deming dijo: Escuchar la voz de los procesos, comenz el
control estadstico de los procesos que hoy sigue con Six Sigma. Hammer y
Champy ofrecieron la reingeniera, que no era otra cosa que hacer de los
procesos el centro de todo. Despus de su famoso libro, Hammer y Champy
reconoceran la poca importancia que haban dado a los procesos en Be-
yond Reengineering donde se decan cosas como: estaba equivocado, la
palabra clave en la definicin de reingeniera es proceso y no radical, las
empresas tienen que hacer de los procesos el centro de atencin, para
una organizacin centrada en procesos todo tiene que ser replanteado.
En la Norma ISO 9000 se retoma el tema de procesos. En la 9004:2000

se aplica el principio de enfoque basado en procesos: Un resultado desea-
101
do se alcanza ms eficientemente cuando las actividades y los recursos

relacionados se gestionan como un proceso, principio este que se refuerza
con el de Identificar, entender y gestionar los procesos interrelacionados
como un sistema, contribuye a la eficacia y eficiencia de una organizacin
en el logro de sus objetivos. En la norma ISO 9001:2000 se dice promueve
la adopcin de un enfoque basado en procesos cuando se desarrolla, im-
plementa y mejora la eficacia de un sistema de gestin de la calidad, para
aumentar la satisfaccin del cliente mediante el cumplimiento de sus requi-
sitosPara que una organizacin funcione de manera eficaz, tiene que iden-
tificar y gestionar numerosas actividades relacionadas entre s.
En la teora de Balance Scorecard o Cuadro de Mando Integral, en donde

se busca establecer una relacin de causa efecto entre las diferentes pers-
pectivas: financiera, clientes, procesos, aprendizaje y crecimiento, se reco-
noce que el valor de una organizacin se crea en los procesos, y que estos
son un activo intangible de las empresas que en combinacin con sus recur-
sos humanos, potenciar las competencias organizacionales. Norton y Ka-
plan, los desarrolladores de esta teora de Cuadro de Mando Integral, dicen:
cada empresa tiene un conjunto nico de procesos para crear valor para
los clientes y optimizar resultados financieros y es aqu donde consiguen
los objetivos financieros y se hace realidad la propuesta de valor que dar
diferenciacin ante los clientes.
El punto de vista de este libro es el de integrar todas las metodologas de

gestin en una visin que recoja las mejores prcticas y experiencias de
partes del mismo, en funcin de las necesidades y requisitos que tengamos
en cada momento o proyecto. En este sentido puede ser de aplicacin una
determinada teora para el anlisis de un proyecto o partes del mismo y
otras teoras para la implementacin, otras para la medicin y otras para el
anlisis de resultados, pues debido a la complejidad en la que se mueven
actualmente las organizaciones, sera ilgico que toda la gestin recayese
sobre una nica metodologa y que esta fuese la panacea o solucin a todos
nuestros problemas.
Al igual que en el mundo de la fsica, no existe teora integradora que

explique el funcionamiento del universo a todas las escalas y segn en qu
dimensin nos encontremos, dispondremos de una teora que explica los
fenmenos observables y funciona en esa rea concreta, por lo que si-
guiendo a los cientficos, usaremos unas teoras u otras segn nos encon-
tremos en el mundo de la fsica de partculas o en el de la cosmologa, se-
gn necesitemos unas cosas u otras en nuestro proyecto, pues de lo contra-
102
rio, no lograremos alcanzar las mejoras que cada una de ellos nos puede
aportar e incurriremos en errores, al tratar determinados problemas con
metodologas no aplicables a ese mbito de actuacin. En este sentido, por
ejemplo, podremos usar TOC para identificar y mejorar las limitaciones de
nuestros sistemas o procesos, Six Sigma para eliminar la variabilidad de las
salidas producidas por nuestro proceso o BPR para redisear completamen-
te los mismos. Esta visin integradora no producir conflictos cuando la
realicemos de forma armnica y por el contrario producir sinergias entre
las distintas teoras y prcticas utilizadas, que aumentarn el valor de nues-
tro proyecto y resultar ms recomendable que adoptar una nica meto-
dologa, sea esta TQM, Six Sigma o BPR, pues ninguna de ellas por si solas
dispone de todas las soluciones y herramientas para sostener la completa
gestin y mejora de los procesos. Ms an, las interdependencias entre
teoras de mejora de procesos como TOC, Lean y Six Sigma se complemen-
tan perfectamente con la metodologa BPM y los BPMS a la hora de contro-
lar, monitorizar y automatizar las acciones y prcticas que estas teoras
desarrollan, al tiempo que BPM, puede aprovecharse de estas para trabajar
en la mejora de procesos. De esta forma, bajo el paraguas de BPM, pode-
mos aprovechar estas sinergias para unificar los esfuerzos de mejora de
procesos, resultando esta opcin mucho ms ventajosa que la de escoger
una nica teora o metodologa para solucionar un problema concreto. As
por ejemplo, podemos usar TOC en el inicio de los proyectos para identifi-
car y tratar las restricciones de la empresa y centrar el trabajo en lo que
realmente importa, Lean para mejorar el flujo de los procesos, identificar
desperdicios (waste), eliminar las actividades que no aportan valor y en-
contrar vas de mejora para hacer nuestros procesos ms efectivos y Six
Sigma para reducir o eliminar la variabilidad y defectos de nuestros proce-
sos y hacerlos de esta forma ms sostenibles. BPM actuar como metodo-
loga integradora que nos permitir aprovechar las potencialidades de cada
una de las metodologas en las distintas fases del proyecto de mejora de
procesos, haciendo adems que todo el equipo sepa que tiene que hacer,
cuando y como hacerlo y nos ayudar a desarrollar la solucin propuesta, a
implementarla, automatizarla, gestionarla y monitorizarla.
BPM tendr su origen en estos intentos de gestionar los procesos en las

organizaciones, pero lo har sin sustituir a todas estas teoras anteriores,
sino complementndolas, unificndolas e integrndolas tambin con las
modernas teoras de gestin del cambio, de la innovacin y de la gestin de
personas, as como con los avances tecnolgicos basados en web services,
las arquitecturas orientadas a servicios (SOA), los sistemas de workflow, los
ERPs, los sistemas de integracin de aplicaciones y otras tecnolgicas y
103
conocimientos como la orquestacin de servicios, los cuadros de mando y

el uso de mtricas y reglas de negocio, de forma que dispongamos de todos
los ingredientes para operar los procesos de negocio de nuestra organiza-
cin.
En el siguiente grfico mostramos un recorrido histrico de las principa-

les teoras y aproximaciones, reas y disciplinas que han conducido a BPM.
Integracin de BPM con las teoras de TOC, Lean y Six Sigma (TLS).
La integracin de la metodologa BPM con las metodologas TLS, parece

ser uno de los caminos en los que ms se est trabajando actualmente de-
ntro de BPM. Estas teoras tienen en comn con BPM el foco en los proce-
sos, la mejora continua, reducir costes, aumentar beneficios, mejorar rela-
ciones con clientes y las tres creen que el trabajo de una organizacin est
en los procesos y que estos son su negocio. Estas teoras, fundamentales
para las tareas de identificacin, descripcin, anlisis y mejora de procesos
se integran perfectamente dentro del ciclo de vida de un proyecto de BPM,
haciendo uso de TOC para disponer de una visin global e identificar y tra-
tar las restricciones de la empresa para centrar los esfuerzos de mejora en
los procesos que realmente importan, Lean para mejorar el flujo de los pro-
cesos, identificar desperdicios, eliminar las actividades que no aportan valor
y encontrar vas de mejora para hacer nuestros procesos ms eficientes y
Six Sigma y su ciclo DMAIC para reducir o eliminar las variaciones y defec-
tos en nuestros procesos y hacerlos de esta forma ms sostenibles.
104
Al mismo tiempo que BPM se beneficia de estas teoras para trabajar en

la mejora de procesos, estas tres teoras pueden beneficiarse de BPM a a la
hora de controlar, monitorizar y automatizar las acciones y prcticas que
estas desarrollan de forma que bajo el paraguas de BPM podemos aprove-
char las sinergias entre estas teoras para integrar y unificar los esfuerzos de
mejora de procesos.
105
106
Captulo 3. Tecnologa, Innovacin y modelos de negocio
Captulo 3. Tecnologa, Innovacin y

Modelos de Negocio.
Para completar el recorrido de aproximacin a BPM de esta primera par-

te del libro, veremos tres aspectos fundamentales que debemos conocer
para comprender el recorrido hacia BPM y que ya hemos apuntado en el
captulo anterior. Estos son: la tecnologa, la innovacin y los modelos de
negocio.
Evolucin tecnolgica:
El rpido camino de las TI.
Al tiempo que surga y se desarrollaba la reingeniera de procesos (BPR),

las tecnologas de la informacin (TI) tuvieron un amplio desarrollo y resul-
taron claves para la gestin de las organizaciones y de sus procesos de ne-
gocio. Este camino tecnolgico comenz con el uso de los primeros orde-
nadores en los aos 70, utilizados para la automatizacin de tareas hasta
entonces desarrolladas de forma manual y basadas enteramente en las
personas (programas de nminas, pedidos, facturas, etc.). Estas automati-
107
zaciones de procesos empresariales se realizaban en ordenadores de vlvu-

las de vaco, con rels y enormes discos duros magnticos como elementos
electrnicos principales hasta que con el desarrollo de la microelectrnica y
la incorporacin de los transistores, microchips y circuitos integrados, los
ordenadores fueron ganando en eficiencia y reduciendo su tamao. Parale-
lamente se fueron desarrollando los lenguajes de programacin y el softwa-
re utilizado por los ordenadores, los cuales tuvieron tambin su propia evo-
lucin desde los primeros lenguajes de bajo nivel (por su cercana al hard-
ware), como el lenguaje en cdigo mquina, basado en el lenguaje binario
de ceros y unos que es el nico que entiende el hardware, hasta los lengua-
jes de alto nivel, ms cercanos al lenguaje de los humanos, que nos permi-
ten abstraernos del hardware con lenguajes como Pascal o Cobol hasta los
denominados lenguajes de cuarta generacin como los RAD (Rapid Applica-
tion Development) y los orientados a objetos como Java o C++ .
Las bases de datos para almacenar datos y poder acceder a ellos tam-
bin pasaron de un modelo de simple archivo plano, al gran salto en la
ciencia informtica que supuso el modelo relacional de bases de datos.
Antes del modelo relacional, las aplicaciones informticas almacenaban los
datos en ficheros externos, por lo que los aplicativos tenan muchos de
estos datos replicados, al tiempo que consuman gran cantidad recursos
informticos para el almacenaje y acceso a estos ficheros. Con la aparicin
del modelo relacional, adems de disponer de una base de datos global y
estructurada de la organizacin, pudimos separar los datos de las aplicacio-
nes (arquitectura en dos capas), por lo que mantenamos los datos aislados
y salvaguardados, pudiendo desarrollar y modificar las aplicaciones que
accedan a estos datos sin necesidad de tocar los sistemas de archivos
especficos para esas aplicaciones. A travs del desarrollo de SQL (Structu-
red Query Language), como lenguaje comn de comunicacin con casi to-
das las bases de datos, disponamos adems de independencia para usar
distintas bases de datos y de esta forma, poder acceder a travs de este
lenguaje a los datos que ahora podan ser utilizados por mltiples aplicacio-
nes cuando as lo precisasen.
Los ERPs y las soluciones de integracin.
El salto al modelo relacional de bases de datos provoc que el desarrollo

de aplicaciones se volviese ms rpido y eficiente, permitiendo el desarrollo
de las complejas aplicaciones tal y como las conocemos hoy en da. Comen-
108
zaron de esta manera el desarrollo de aplicaciones ms avanzadas y espec-

ficas para distintas reas funcionales de la empresa (finanzas, nminas y
gestin de almacenes principalmente), pero que por la falta de integracin
entre ellas, se traducan en altos costes de implementacin y de formacin
a las personas encargas de gestionar estos sistemas. Para paliar este aisla-
miento entre aplicativos, surgen a principios de los aos 90 los ERP (Enter-
prise Resurce Planning), como soluciones globales para la gestin de em-
presas. Sin embargo, los ERP, aunque comercializados como la panacea
para todos los problemas de la empresa, no resultaron en las grandes mejo-
ras de productividad y eficacia que las empresas esperaban, principalmente
por la falta de adaptacin de estos sistemas a las necesidades particulares
de las empresas, resultando ms bien en todo lo contrario y siendo las em-
presas las que finalmente deban adaptarse a los ERP de los distintos fabri-
cantes.
Hoy la tecnologa se ha socializado y cualquier empresa o competidor

puede acceder a soluciones informticas impensables hace apenas unos
aos. Sin embargo, los principales vendedores de soluciones ERP siguen
basando hoy su estrategia en ofrecer en sus soluciones software los mismos
procesos predefinidos y de forma empaquetada para los distintos sectores
y mercados, resultando que todos las empresas disponen de los mismos
procesos y opciones en cuanto a la gestin de los mismos que los de su
competencia, limitando enormemente las posibilidades de innovar en mo-
delos de gestin, modelos de negocio, adaptacin al cambio y mejora de
procesos.
Para agravar an ms las cosas, si queremos realizar nuestros propios

procesos, modelos de gestin, de negocio o nuevas formas de hacer las
cosas, somos nosotros los que tenemos que disear los modelos en funcin
de los mdulos a los que tenemos acceso, ponindonos adems los fabri-
cantes de estas soluciones paquetizadas, grandes trabas econmicas y de
tiempo de implementacin para realizar esos cambios y adaptaciones nece-
sarias sobre nuestros sistemas, modificaciones estas que no son siempre
bienvenidas por parte de los fabricantes, por lo que la mayora de las em-
presas optan por amoldarse a sus sistemas ERP y no estos al modelo de
negocio y de gestin que desea o ejecuta la empresa como parecera lgico.
Este es el motivo por el cual cualquier implantacin de un sistema de ges-
tin en nuestra empresa necesita de grandes partidas dedicadas a forma-
cin, para que nuestro personal pueda operar y adaptarse a los modelos y
procedimientos estndar del fabricante software. Toda esta operativa se
pone en contra de la innovacin, de la mejora de procesos y de la posibili-
109
dad de alcanzar ventajas competitivas para nuestra empresa a travs de un

arma tan estratgica para la consecucin de estas como es el diseo de
procesos personalizados y particularizados para nuestra empresa y su mo-
delo de negocio y el poder adaptar nuestros sistemas informticos a los
cambios y nuevos modelos a los que nuestra empresa deba hacer frente.
La situacin descrita llev a que a las empresas ya no les bastase slo

con soluciones ERP, sino que fuesen adquiriendo otras soluciones especfi-
cas de distintos fabricantes para gestionar distintas reas organizacionales.
De esta forma surgieron los CRM (Customer Resource Manager) para la
gestin de las relaciones con los clientes, soluciones financieras, de gestin
de la cadena de valor y de provisin, soluciones de gestin de compras, de
comercio electrnico, de recursos humanos y as un largo etctera de apli-
cativos para satisfacer las necesidades particulares de determinados depar-
tamentos y unidades de negocio, pero el taln de Aquiles de todos ellos,
estaba en su funcionamiento como partes aisladas y no como un todo regi-
do por la estrategia y objetivos de negocio comunes, en funcin de los cua-
les se disease toda la cadena de valor, de forma que no hubiera cuellos de
botella, falta de integracin, de coherencia y unificacin entre los distintos
sistemas de informacin que conformaban la organizacin.
Todos estos sistemas, funcionando en las empresas de manera simult-

nea, agravan adems el problema de la redundancia de datos distribuidos
en diferentes sistemas y la falta de integridad de la informacin. Cada apli-
cativo de los mencionados accede a su propia fuente de datos, producin-
dose una rplica a nivel aplicativos y sistemas informticos de la organiza-
cin funcional, donde cada departamento dispone de su propio silo de da-
tos y donde cada aplicacin ha sido personalizada para cada departamento.
Aunque los sistemas estn conectados, no lo estn en su lgica de datos y
esta visin puede ser comparada con la estructura Taylorista de las empre-
sas separadas en departamentos funcionales, impidiendo ver el flujo de
datos que atraviesan los distintos departamentos y que conforma el proce-
so de negocio completo.
En los aos 90, con la reingeniera de procesos, las empresas comenza-

ron a resolver la problemtica de los procesos que atravesaban la organiza-
cin de forma horizontal, por lo que comenzaron a desarrollar sistemas
para que estas aplicaciones se comunicasen entre ellas. Comenz entonces
el desarrollo de herramientas para conectar sus distintos mdulos y poder
as desplegar sus procesos de negocio, introduciendo sobre los ERP de que
disponan, de capas de integracin de datos para solucionar los problemas
110
de esa falta de integracin. De esta forma, la complejidad de los sistemas

de informacin empresariales creci y se hizo ms heterognea, coexistien-
do en ellas diferentes sistemas y aplicativos utilizados para gestionar distin-
tas reas de la empresa, junto con soluciones para la integracin de datos y
sistemas: Middleware, EAI (Enterprise Application Integration) y capas de
intermediacin as como soluciones y procesos de estandarizacin de datos
y protocolos de comunicacin entre sistemas que permitiesen a los siste-
mas compartir informacin entre ellos para permitir la coexistencia de los
diferentes aplicativos. Las soluciones basadas en EAI y Middlewares, aun-
que solucionasen el problema de la falta de integridad de datos, presenta-
ban el problema de la multiplicacin en los canales de comunicacin o el
denominado problema de NxN cuando hacemos conexiones punto a pun-
to, donde el nmero de interfaces a desarrollar es el cuadrado del nmero
N de aplicaciones que deben ser integradas, y aunque no siempre tengamos
que comunicar a todos con todos, el esfuerzo en desarrollo y mantenimien-
to de estos sistemas es muy elevado, debido a las tareas de reprogramacin
cuando cambia alguno de los aplicativos. Esta es la situacin expuesta en el
siguiente grfico para conectar cinco tipos de aplicativos empresariales.
Donde el nmero de canales de comunicacin es: N x (N-1)/2, siendo N

el nmero de aplicativos a conectar, que en el caso del ejemplo ser: 5 x (5-
1)/2, resultando en 10 canales de interconexin de datos.
La solucin para minimizar el nmero de canales de comunicacin nece-

sarios fue el trasladarlo a un modelo de Hub o concentrador:
111
El cual resulta en tan slo 5 canales de comunicacin, la mitad que el an-

terior y esto slo para cinco aplicativos, por lo que si este nmero aumenta,
el nmero de requerimientos de conexin crecer exponencialmente por lo
que vemos que en las conexiones punto a punto, debemos establecer un
nmero mucho mayor de sistemas de comunicacin entre aplicativos que
en las soluciones en Hub, donde la mayor dependencia la tendremos de los
adaptadores para conectar el Hub con las aplicaciones existentes en la em-
presa. Las soluciones de integracin basadas en Hub son en este sentido
mucho ms giles y eficientes, permitindonos minimizar el nmero de
conexiones a realizar y son una seria aproximacin a los sistemas BPMS, las
as arquitecturas informticas orientadas a servicios (SOA) y los ESB (Enter-
prise Service Bus) utilizados por SOA y con la misma filosofa que los HUB,
en cuanto a la lgica de hacia dnde dirigir las soluciones informticas en la
empresa en cuanto a soluciones de integracin y que combinadas con las
soluciones de workflow y las teoras de gestin de procesos, confluirn en
los BPMS y las arquitecturas SOA tal y como las conocemos hoy en da.
Internet y las nuevas arquitecturas informticas:
A finales de los aos 90 se desarrollan las tecnologas basadas en inter-

net y con ellas las necesidades de atender a los clientes en este nuevo en-
torno, as como aprovechar las capacidades que esta tecnologa ofreca
para la comunicacin entre aplicaciones en entornos geogrficamente dis-
persos. Los negocios crecen y las peticiones de informacin en el ecosiste-
ma empresarial e inmediatez en la prestacin de servicios crecen tambin
112
con ellos. Surgen nuevos y variados modelos de negocio, aparecen nuevos

clientes, partners y oportunidades de negocio que exigen mayor interco-
nexin e inmediatez en el intercambio de datos y aplicaciones. Surgen los
portales de internet, el despegue del comercio electrnico y las necesida-
des de integracin entre plataformas web y los aplicativos de la empresa,
los negocios se abren al mundo y surge todo un abanico de soluciones (B2C:
Business To Consumer, B2B: Business To Business, B2E: Business To Emplo-
ye, etc).
Es en este entorno donde se retoma la perspectiva de la gestin por

procesos y se desarrolla la disciplina de BPM para ayudar a dar respuesta a
esta complejidad creciente y permitir a las organizaciones aportar nuevos
productos y servicios al mercado de forma ms rpida, adaptando los mo-
delos y los procesos de negocio y tecnologas que sustentan estos modelos
a los cambio o demandas del mercado.
De las soluciones EAI y de integracin, pasamos con internet a las comu-

nicaciones y conectividades muchos-a-muchos, por lo que se desarrollan
nuevos estndares y protocolos de comunicacin para este nuevo canal
(HTTP, HTML, XML, SOAP, etc.) que proporcionarn de los servicios de co-
municacin y la flexibilidad necesaria para la transformacin y el entendi-
miento entre aplicativos y datos de diferentes sistemas, convirtiendo a
internet en el medio por excelencia para las comunicaciones entre sistemas
y negocios, tanto a nivel interno como externo. Esta evolucin de internet y
sus sistemas de comunicacin lleg hasta la tecnologa de los web services y
las arquitecturas orientadas a servicio SOA (Service Oriented Architecture),
siendo la perspectiva de estos ltimos una perspectiva de negocio y basada
en las arquitecturas empresariales, de forma que son estas arquitecturas las
que definirn las funcionalidades y servicios ofrecidos por los sistemas in-
formticos y los servicios web. Ms concretamente, podemos decir que
sern los procesos los que dirigirn la operativa de SOA y los web services y
los que describirn como estos deben producir valor. Haciendo una compa-
racin con la programacin orientada a objetos, podemos decir que los web
services y las arquitecturas SOA son como los objetos y los procesos como
los mtodos.
SOA surge para posibilitar la flexibilidad de los sistemas informticos en

los entornos tecnolgicos actuales, donde la interoperabilidad de datos
entre empresas y sistemas independientemente de la tecnologa utilizada
por cada de ellos es un imperativo. Con SOA y el uso de web services, se
facilitar y racionalizar enormemente las posibilidades de integracin y
113
comunicacin eficiente entre servicios de diferentes sistemas informticos,

de tal forma que estos pueden ser invocados por clientes o consumidores
de estos servicios sin necesidad de conocer la lgica interna del servicio al
que invocan. El disponer y poner al servicio de nuestros clientes, partners,
proveedores y en general, a cualquier otro sistema con el cual nuestra em-
presa interaccione, la informacin necesaria para interactuar con nuestro
negocio y el permitirnos exponer slo aquello que deba ser expuesto por
parte de nuestra empresa (datos o servicios), as como hacerlo slo con
quien corresponda, segn los derechos y permisos de que dispongamos
para acceder a estos servicios, simplificar las comunicaciones y la provisin
de informacin de nuestra empresa de una forma totalmente racional y
segura. El entorno tpico en el que se presentan estas arquitecturas orien-
tadas a servicios, es el de dar solucin a los requerimientos de negocio a
empresas con diversidad de aplicativos y sistemas heredados, operando en
un mismo entorno y que en muchos casos no fueron construidos para ope-
rar fuera de los muros de la empresa y a las que no les resulta fcil integrar
en ellos a partners, clientes y proveedores con distintas tecnologas cada
uno de ellos y en el que cada integracin o cambio en las necesidades de
negocio o comunicacin, requiere de duros esfuerzos tcnicos, humanos y
financieros para afrontar estos retos y oportunidades.
Para ayudar en esta bsqueda del orden tecnolgico en las organizacio-

nes, SOA se presentar como el principal aliado tecnolgico a la hora de
afrontar las necesarias integraciones informticas asociadas a nuestros
procesos de negocio y es por ello que los proyectos de BPM y SOA, sern
abordados generalmente de forma conjunta y como iniciativas de trans-
formacin global y no como proyectos aislados de TI, de forma que nos
beneficiemos de una arquitectura de sistemas racional, alineada con la es-
trategia de la empresa y capaz de afrontar los cambios y requerimientos de
negocio. Este alineamiento partir del principio de que de nada nos servirn
las inversiones en Tecnologa de la Informacin, si no tenemos unos proce-
sos de negocio perfectamente definidos, optimizados y medibles (parte
esta de la que se encarga BPM), de forma que nuestros sistemas estn al
servicio de estos procesos y no a la inversa, disponiendo de unos magnficos
sistemas informticos pero que operan sobre procesos y organizaciones
ms propias del siglo XIX y que resultarn en un desaprovechamiento de la
inversin en TI y de oportunidades de negocio.
A partir del ao 2004 disponemos ya de todo tipo de soluciones inform-

ticas que sustentan todas las actividades de negocio de las empresas en un
entorno altamente competitivo y complejo, el cual requiere de inversiones
114
en el soporte de los sistemas de informacin sobre los que se sustentan de

forma ineludible las empresas y sus nuevos modelos de negocio. En este
ambiente, adems de las arquitecturas orientadas a servicios (SOA), se des-
arrollan tambin la computacin en la nube y nuevas arquitecturas empre-
sariales para dar soporte a los requisitos de negocio. Hasta aqu, las empre-
sas se apoyaban en la tecnologa para gestionar sus negocios y hacer crecer
los mismos, pero ahora, las empresas retoman la direccin y el control de
sus negocios y definen la arquitectura tecnolgica para dar soporte a sus
negocios y es en este entorno de ver los recursos tecnolgicos de la empre-
sa como un todo homogneo e integrado al servicio del negocio, donde
aparecen las Suites BPMS (Business Process Management Suites), en las
que la gente de negocio define y modela sus procesos y los implementa en
la misma plataforma, reducindose la brecha entre los requerimientos del
negocio y la solucin tecnolgica final.
Alineamiento de negocio y tecnologa. Los BPMS.
Con el cambio de siglo, comenzaron a surgir las soluciones a esta com-

plejidad de sistemas distribuidos e interconectados a travs de distintas
capas de intermediacin. Este camino de ordenacin vino del reconoci-
miento de la arquitectura empresarial y los procesos de negocio que rigen
su comportamiento, como los verdaderos conductores de las arquitecturas
tecnolgicas.
De la evolucin de las plataformas de workflow (desarrolladas para ges-

tionar procesos de gestin documental y de seguimiento del flujo de tareas
de empleados) y de los sistemas EAI (desarrollados para resolver la falta de
comunicacin entre aplicativos departamentales e integrar los datos de los
mismos), surgieron las primeras concepciones de los BPMS que nos permiti-
rn gestionar procesos en los que intervienen personas (heredados de los
workflow) y aplicativos (heredados de los sistemas de integracin de los
Middleware y los EAI). Sobre estos sistemas de workflow e integracin, se
aadieron capacidades de anlisis de datos asociados a las actividades de
los procesos (completando de esta forma a los workflow), capacidades de
modelado de procesos as como otras tecnologas y funcionalidades orien-
tadas a la gestin por procesos de negocio, su control y monitorizacin y
una notacin especfica para modelar los procesos y poder convertir estos
modelos en aplicaciones de software ejecutables.
115
Las plataformas de Workflow, predecesoras de los actuales BPMS, ges-

tionan una secuencia de tareas ejecutadas en serie o en paralelo por dos o
ms individuos y proveen de soluciones de automatizacin en procesos
basados principalmente en la gestin documental, controlando el flujo de
un documento de un punto a otro y conservando todos los estados por los
que este ha pasado y que suele tener una representacin como la del si-
guiente grfico.
Los workflow tienen innumerables beneficios en la representacin de

procesos, sin embargo, su evolucin se encuentra ahora dentro de los
BPMS, que adems de las capacidades de modelado y workflow, permiten
la ejecucin y control de los procesos as como la integracin con aplicati-
vos e interfaces humanas para la gestin del ciclo de vida completo de los
procesos.
De forma resumida, las herramientas BPMS permitirn disear los pro-

cesos de negocio en un entorno grfico, especificando los pasos y activida-
des a realizar, los puntos de control sobre este flujo de tareas y actividades,
las reglas de negocio que regirn su comportamiento, las alertas que im-
pondremos sobre el flujo del proceso y condiciones del mismo, los roles y
personas asignados a cada actividad y las integraciones con otros sistemas y
aplicativos necesarios para el funcionamiento del proceso. Adems, en los
BPMS podremos simular el comportamiento de los procesos, para una vez
validados, asegurarnos de que su comportamiento se ajusta a lo esperado,
implementarlos en un entorno de produccin y monitorizar su comporta-
miento en base a indicadores. En los BPMS, como podemos vislumbrar, los
usuarios de negocio tienen ahora la posibilidad de definir y modelar sus
procesos y traducirlos directamente a software ejecutable para que realice
las acciones requeridas a travs de distintos motores de procesos (de work-
flow, de reglas de negocio y de integracin), que ejecutarn el cdigo gene-
rado a partir del modelado en tiempo real. De esta forma, y a diferencia de
116
los anteriores sistemas informticos, difciles de modificar una vez imple-

mentados, el negocio ya no depende de la informtica ni de tener que es-
perar por ella para implementar cambios en los procesos que estemos eje-
cutando y podr abordar nuevos modelos y procesos de negocio, simular el
comportamiento de determinadas modificaciones en la operativa de nego-
cio y mejorar los procesos existentes de forma rpida y sin interrumpir el
normal funcionamiento de estos. Los inconvenientes que deberemos afron-
tar para poder disfrutar de todas estas ventajas sern principalmente las
personas y la gestin del cambio organizacional que supondr el nuevo
paradigma de la organizacin orientada a procesos.
Sobre el cambio, sabemos desde los griegos que ste existe y es inevita-
ble: todo cambia, nada permanece, por lo que la mejor estrategia que
podemos abordar ante este es asumirlo y aceptarlo. Sobre las personas,
incidiremos en diferentes partes del libro sobre su importancia y necesidad
de gestin del cambio en las personas para afrontar los proyectos con xito.
Como ya hemos visto al hablar de BPR, muchas veces los problemas de las
personas con las TI vienen por cmo estas se han implantado en las organi-
zaciones, usando a las personas para dar soporte a los sistemas de informa-
cin y no a la inversa, de forma que los niveles gerenciales dispusiesen de
mayor informacin y control de las personas para la toma de decisiones y
no haciendo a las personas partcipes del diseo de los sistemas y de los
procesos de negocio, de forma que ellos tambin puedan verse beneficia-
dos en sus tareas diarias del sistema a implementar. La perspectiva que
abordaremos en este libro respecto a las personas y los sistemas, es que
estos ltimos deben ayudar y apoyar en su da a da al usuario y facilitar sus
tareas, de forma que los usuarios y los sistemas se entiendan y convivan en
armona y no imponiendo el uso y adecuacin a una determinada herra-
mienta informtica.
Como vemos, los BPMS representan un cambio radical al pasar de las

aplicaciones basadas en funciones y objetos a la orientacin a procesos,
integrando personas, aplicaciones y datos en torno a procesos y proveyen-
do de las capacidades para poder disear e implementar los mismos. Con
este paso, pasaremos de la eficiencia a la agilidad, de la eficiencia operacio-
nal proporcionada por los ERP, a la agilidad de negocio, suponiendo este
paso un cambio de paradigma al pasar los sistemas informticos de la em-
presa de estar centrados en la informacin y trabajar a partir de esta, a
estar centrados en los procesos de negocio que rigen y gobiernan el nego-
cio. Esto no significa ni mucho menos la desaparicin de los ERP o cualquier
otro software utilizado por la empresa, a da de hoy es muy difcil por no
117
decir imposible que un BPMS pueda realizar las funciones de un ERP. Los
BPMS vienen de alguna manera, a aadir una nueva capa, la capa de proce-
sos de negocio, a travs de la cual podemos gestionar el resto de sistemas y
capas (de aplicaciones, datos y presentacin) pero manteniendo el mapa de
procesos de negocio como referencia para cumplir con los objetivos y estra-
tegias de la empresa y poder modificar estos mapas de forma rpida y flexi-
ble para trabajar en la mejora continua y la bsqueda de ventajas competi-
tivas.
Los BPMS, a diferencia de otros sistemas como los ERP, son lo que se
denominan sistemas PAIS (Process-Aware Information System), es decir,
sistemas de informacin conscientes de los procesos, a diferencia de los
anteriores sistemas como los ERP, CRM, SCM, etc. donde cualquier modifi-
cacin en el proceso requiere reprogramar las aplicaciones y testear el re-
sultado consumiendo gran cantidad de recursos. Aunque en muchos ERP
dispongamos de un sistema de workflow integrado en los mismos para
facilitar la personalizacin de los procesos de negocio dentro de estos sis-
temas, estos sistemas de workflow son componentes del propio ERP y es-
tn diseados para poder realizar algunas funciones, pero siempre dentro
de un campo limitado de posibilidades predefinidas dentro del propio en-
torno del ERP.
Innovacin.
La gestin de la innovacin y la actitud innovadora ser un tema que tra-

taremos en distintos puntos de este libro, como necesaria para alcanzar
resultados satisfactorios tanto en la gestin y mejora de nuestros procesos
de negocio como en la gestin del cambio y su liderazgo dentro de nuestras
organizaciones. En el libro abordamos la orientacin a procesos y clientes y
ponemos el foco en estos, no slo como base para alcanzar los objetivos y
estrategias empresariales, sino tambin como forma ms eficiente de abor-
dar los cambios e innovaciones a las que ineludiblemente tendremos que
hacer frente a travs del rediseo, la reingeniera y la mejora de los proce-
sos de la empresa.
La propia gestin por procesos, como ya hemos visto, cruza las barrearas
funcionales y departamentales de las organizaciones, forzando en este
trnsito a la cooperacin entre las partes, al establecimiento de una cultura
ms abierta y participativa, ms orientada al cliente, a la obtencin de re-
118
sultados y a la innovacin constante que al mantenimiento de estructuras

funcionales estticas y de privilegios dentro de ellas.
El entorno econmico.
Todas las empresas necesitan de la innovacin para crecer. La innova-

cin no es algo nuevo y la historia social y econmica del mundo est pla-
gada de claros ejemplos de cmo esta ha sido la catalizadora del progreso
de la sociedad y su bienestar.
Transcurridos varios siglos de historia econmica, social y poltica,

acompaadas de sendas revoluciones en la forma de gestionar las empre-
sas, (revolucin industrial, revolucin de los mtodos productivos en los
aos 70 y revolucin en las formas de gestin de las organizaciones), nos
encontramos actualmente en la revolucin que viene dirigida por el cono-
cimiento, el talento de las personas y la tecnologa.
Las fuentes de ventaja competitiva actuales ya no estn en la utilizacin

de mano de obra barata o en la obtencin de recursos naturales a bajo cos-
te. Los tiempos de una sociedad de masas vida de consumir todo tipo de
productos y servicios como era la sociedad despus de la segunda guerra
mundial y que precisaba de empresas manufactureras capaces de producir
todo lo que consuman estos mercados, han sido sustituidos por un nuevo
entorno en el que la oferta es mayor que la demanda y donde los recursos
con los que contamos hoy para poder hacer frente a esta situacin son el
talento de las personas, el conocimiento con el que cuenten estas personas,
la creatividad y la innovacin para poder convertir las ideas en valor y el
conocimiento (know-how) en resultados (cash-flow).
En la poca de la produccin en masa de la segunda mitad del siglo XX,

las empresas recurren a la tecnologa y a la automatizacin para hacer fren-
te a las necesidades de produccin a gran escala, pero a finales de siglo el
mercado de muchos de estos productos comienza a dar signos de agota-
miento, provocando que empresas perfectamente optimizadas y con altsi-
mos ndices de productividad, se encuentren con una demanda en claro
descenso. Esta situacin se ve agravada por la competencia de los pases
emergentes (los BRIC: Brasil, Rusia, India y China principalmente), que con
sus bajos costes de produccin provocan la saturacin del mercado y el
despertar de un cliente cada vez ms exigente y sensible al precio y que
119
adems dispone, gracias a internet, de informacin de distintos precios y

productos en todo el mundo.
Competencia destructiva:
Ante esta situacin nada alentadora para muchas empresas, que hasta
ahora haban funcionado sin problemas, este nuevo escenario socio-
econmico en el que nos encontramos provoca incertidumbre en las em-
presas, que no saben muy bien qu lnea seguir. La solucin abordada por la
mayora de empresas ha sido el de la reduccin drstica de costes con obje-
to de poder mantener sus productos en el mercado en base a unos bajos
precios que les permitan conservar a unos clientes cada vez ms escurridi-
zos y difciles de conservar, pero esta reduccin de e costes se hace a costa
de reducir la calidad y los mrgenes de beneficio sobre sus productos y
servicios. Esta situacin es la denominada competencia destructiva, en la
que las empresas basan su supervivencia en el mercado exclusivamente en
el precio a base de reducir costes. Otra denominacin para este tipo de
mercados, es la descrita por W. Chan Kim en su libro Blue Ocean Strategy
y que en contraposicin a los ocanos azules donde es fcil pescar peces,
Chan nos habla de Ocanos Rojos, para referirse al color de la sangre
surgida de la lucha encarnizada en un ocano infestado de competidores
que se desangran entre ellos por unos pocos peces (clientes), para los cua-
les el precio se ha convertido en el principal factor de eleccin entre una u
otra empresa. Estos ocanos rojos o escenarios de competencia destructiva
presentan adems una particularidad que debera hacernos reflexionar y es
que en la guerra de bajos costes slo puede ganar uno (el que sea capaz de
ofrecer el precio ms barato), siendo la misma situacin que en los deno-
minados juegos de suma nula (donde para que uno gane, otro debe perder;
como en el ajedrez o en el tenis).
Retomando las ideas de Goldratt, el mundo del coste es el que predomi-

na a la hora de actuar en las empresas y el que lleva a las empresas a esa
competencia destructiva y a los ocanos rojos. En TOC, al igual que en BPM
y prcticamente en todas las teoras de management, el objetivo de cual-
quier empresa es ganar dinero y segn lo libros de Goldratt, para alcanzar-
lo, tenemos tres flujos de dinero que podemos manejar:
- Gastos Operativos (GO): todos los gastos de la empresa necesa-

rios para mantener la actividad de la misma: salarios, alquileres,
maquinaria, etc.
120
- Inversiones (I) que se realizan en la empresa y que no se pue-

den recuperar a corto plazo.
- Valor Generado (VG): el dinero que genera la empresa con la
venta de sus productos y que calculamos restando al precio de
venta de un producto o servicio todos los costes imputables a
ese producto o servicio.
Al final de un periodo obtenemos un beneficio (B) con nuestras opera-

ciones que es la diferencia entre el Valor Generado (VG) y los gastos opera-
tivos (GO):
B=VG-GO
Para mejorar el beneficio de una empresa podemos actuar de dos mane-

ras:
- Aumentando el Valor Generado (VG)

- Disminuyendo los Gastos Operativos (GO)
Como ya hemos visto en el primer captulo, la variable sobre la que de-

cidamos actuar para aumentar los beneficios dir mucho sobre la forma
que tenemos de gestionar nuestra empresa. Como ya vimos, normalmente
las empresas escogen actuar sobre los gastos (GO), por ser esta la opcin
sobre la que tenemos un mayor control, mientras que la mayora rechaza
actuar sobre los ingresos (VG). Sin embargo, esta decisin de actuar sobre
los gastos operativos lleva a las empresas a obtener buenos resultados slo
en el corto plazo, pues a medio y largo plazo, los mrgenes de mejora se
estrechan, pues llega un momento en el que ya no podemos actuar ms
sobre los costes sin perder en otros aspectos como la calidad. Es la situa-
cin descrita en la Triple Restriccin del Project Management (Tiempo-
Costes-Alcance), pero aplicada a los costes: no podemos aumentar los be-
neficios, reducir los costes y mejorar el servicio al mismo tiempo. Mejorar el
servicio aumenta los costes, aumentar los ingresos aumenta los costes y si
reducimos costes, el servicio prestado empeora.
La salida a esta situacin, sobre la que ya alertamos en el primer captu-

lo, pasa por la bsqueda de los Ocanos Azules, esos ocanos donde no
existe todava la competencia y se pueden todava pescar peces (clientes),
sin tener que imitar lo que los dems hacen o seguir la peligrosa estela de
los bajos costes. Estos ocanos azules o parasos de mercado para cualquier
empresa existen, pero pasan ineludiblemente por la innovacin y la dife-
renciacin, por la predisposicin al cambio y por la velocidad con la que
121
adoptemos el mismo, por la bsqueda constante de ventajas competitivas,

de nuevos nichos de mercado y clientes que en la saturacin de mercado
actual, todava pueden ser sorprendidos por nuevos y mejorados productos
y servicios, pues esta ser la nica forma de dejar que el cliente slo vea el
precio.
Gestin de la innovacin:
Podemos ver la innovacin como el encuentro entre los problemas y el

conocimiento y de esta visin extraer que si estamos de acuerdo en que los
problemas que afectan a nuestra empresa pasan por hacer frente a este
entorno descrito de competencia destructiva y que nunca tanto conoci-
miento y talento a estado a nuestra disposicin como lo est ahora, enton-
ces este es el momento idneo para que surjan nuevos modelos e ideas
innovadoras.
Lo que tendremos que hacer en nuestras organizaciones es provocar es-

te encuentro entre los problemas y el conocimiento para que se produzca la
colisin generadora de innovacin. Para ello, deberemos crear los meca-
nismos y usar las metodologas, tanto para que el conocimiento pueda des-
arrollarse como para acercar los problemas al conocimiento y no mantener-
los aislados de este en los niveles directivos de la empresa como si estos
fuesen los nicos poseedores del conocimiento. Esta actitud y visin de
buscar el conocimiento en todas las partes de la organizacin, tanto en los
niveles directivos, como mandos intermedios y operativos de los niveles
ms bajos de la organizacin, ser una caracterstica de los proyectos de
BPM. Hace unos aos se crea que la innovacin era algo Top-Down, los de
arriba piensan y los de abajo ejecutan, el departamento de I+D disea y la
cadena de montaje implementa, pero ahora sabemos que esto ya no fun-
ciona as. En nuestros proyectos de BPM, mezclaremos la visin Top-Down
con la Bottom-Up, con el nimo de recabar toda la informacin necesaria y
conocimientos de la organizacin y su entorno, independientemente de
donde esta se encuentre, para confrontarla con los problemas que hayamos
encontrado.
Pero lograr este encuentro entre los problemas y el conocimiento, re-

querir de un cambio de mentalidad y de cultura organizativa para poder
llevarlo a buen puerto y ser necesario el desarrollo de nuevos estilos de
liderazgo, ms abiertos y participativos y donde prime la transparencia, el
conceder mayor importancia a las personas, que son las poseedoras del
122
conocimiento y en consecuencia las que disponen de la capacidad de resol-

ver los problemas e identificar nuevas oportunidades y mejoras. Debere-
mos crear los mecanismos que permitan recabar, comprender y compartir
la informacin de forma transparente y abierta, en un entorno creativo y de
participacin constructiva, donde se prime la participacin y el aporte de
ideas y no donde estas ideas se escondan por miedo a las consecuencias.
As mismo, deberemos aprovechar tambin el potencial de las nuevas tec-
nologas para recabar informacin sobre los problemas y las posibles solu-
ciones, y en especial, aquellas relacionadas con la web 2.0 y que nos permi-
tan convertir el conocimiento tcito en conocimiento implcito y aprovechar
de esta forma todo el potencial con el que cuenta nuestra empresa.
El proceso para abordar estos cambios comienza en la llamada innova-

cin en procesos, donde las empresas se plantean el hacer las cosas de
forma diferente y que fruto de colisionar conocimientos y problemas, nos
conducir con posterioridad a la innovacin en modelos de negocio y la
innovacin en mercados, que conformarn la denominada Innovacin Tri-
dimensional (procesos, negocios y mercados). Estos tres tipos de innova-
cin se presentan en ese orden por no empezar la casa por el tejado: no
afrontar un nuevo mercado sin un modelo de negocio slido que pueda
hacerle frente y no disear un modelo de negocio cuyos procesos no son
todo lo eficientes y rentables que pudieran ser. Sin embargo los tres tipos
de innovacin se refuerzan unos a otros y al final, no innovamos en una sola
rea, sino que lo hacemos en todas al mismo tiempo, unas se llaman a otras
y una innovacin que nos permita reducir los tiempos de entrega, nos per-
mitir por ejemplo abordar nuevos mercados y modelos de negocio no con-
siderados hasta entonces.
Innovacin en Procesos.
En el entorno econmico descrito anteriormente, altamente competitivo

y sobrecargado de productos y servicios, la innovacin en procesos (como
hacemos las cosas), ser tan importante como la innovacin que realicemos
en los productos y la innovacin en mercados.
Por definicin, la innovacin en procesos es la revisin fundamental y el

rediseo radical de procesos a travs de las TIC para alcanzar mejoras es-
pectaculares en medidas crticas de rendimiento, tales como costos, cali-
dad, servicio y rapidez. Esta definicin de innovacin en procesos, tiene una
diferencia respecto a la reingeniera y es la palabra espectacular. Las me-
123
joras que implican innovacin en procesos deben ser espectaculares, cru-

zando los problemas con el conocimiento para encontrar nuevas formas de
hacer las cosas que supongan grandes saltos en el rendimiento y la mejora
de la eficiencia de nuestras operaciones. Con BPM contaremos con una
poderosa herramienta para disear, gestionar y monitorizar nuestros pro-
cesos de negocio en base a datos y al anlisis de los mismos. Sin embargo
en este libro, aunque damos importancia a la monitorizacin y control de
procesos, consideraremos otras vas ms all de las del anlisis y control,
que si bien conformarn la base sobre la que gestionar, analizar y proponer
mejoras en nuestros procesos, no sern las nicas, y dejaremos una va
para la innovacin, la creatividad y la valenta a la hora de plantear nuevos
modelos de negocio y de procesos. Como deca Peter Drucker: el mejor
medio de predecir el futuro es crendolo.
Este planteamiento nos obligar a replantear no slo la forma en que

hacemos las cosas, sino tambin replantearnos las bases estructurales de
muchas empresas operando con esquemas y prcticas heredados del Taylo-
rismo, donde muchas de las actividades implementadas son realizadas ni-
camente para satisfacer exigencias internas de la propia organizacin y que
nada tienen que ver con la orientacin al cliente y los mercados. Estas es-
tructuras de hace ms de doscientos aos, no hacen sino ponernos barreras
ante los retos a los que actualmente debemos hacer frente, por lo que de-
beremos empezar de cero, para generar nuevos modelos organizativos bajo
los que nos replanteemos los diseos y operativas de nuestros procesos y el
cmo hacemos las cosas, pues ms que en los productos, ser en el cmo
hagamos esos productos donde radicar la diferencia entre una y otra em-
presa.
En esta transicin, innovar en procesos significar replantearnos nues-

tros procesos desde las bases, partiendo de una clara orientacin hacia los
clientes, de forma que los procesos se adapten y estn totalmente dirigidos
a la satisfaccin de sus necesidades, eliminando ineficiencias y todo lo que
no aporte valor a ese cliente para satisfacer sus necesidades y expectativas.
Para conseguir la innovacin en procesos debemos considerar dos as-

pectos que se han demostrado como grandes catalizadores de la innova-
cin: el uso de las tecnologas de la informacin y la presin de la compe-
tencia.
Hoy todos conocemos como el uso de las TI ha supuesto autenticas re-

voluciones en infinidad de modelos de negocio y empresas que han sabido
124
adoptar las mismas para innovar en procesos y mercados y no slo han

utilizado las mismas para el ahorro de costes y mejora de procesos. Sin em-
bargo, y segn ha demostrado en un estudio la consultora McKinsey, es la
presin de la competencia la que fuerza realmente a las empresas hacia la
innovacin que haciendo uso de las TI permiten alcanzar esos resultados
espectaculares.
La presin de la competencia se ha revelado como la gran catalizadora

de la innovacin y que en su ausencia, las empresas no innovan, se dejan
llevar por la inercia, sin plantearse la introduccin de cambios. Edgar
Schein, revela en sus estudios como las organizaciones slo cambian cuan-
do sienten que este es el nico camino que tienen para poder sobrevivir.
Schein compara este proceso con los prisioneros de un campo de concen-
tracin y la diferencia entre la mentalidad conservadora de los que aceptan
la situacin y no afrontan los riesgos y repercusiones de una posible fuga y
los que se resisten a esta situacin y buscan constantemente como escapar
de ella, conscientes de que si no la hacen, jams saldrn vivos del campo.
Las comparaciones de esta metfora del campo de concentracin, son apli-
cables a entornos como el aprendizaje, donde este se produce slo cuando
la ansiedad de supervivencia es mayor que la necesidad de aprendizaje, o
en el entorno empresarial, donde el aprendizaje y la innovacin slo se
producen ante la presin de la competencia, de los mercados y la necesidad
de supervivencia de las empresas, por lo que si queremos provocar la inno-
vacin tan necesaria en las empresas, deberemos desarrollar el ambiente y
entorno adecuado para provocar la urgencia y ansiedad de supervivencia.
En la innovacin en procesos deberemos tambin tener en cuenta que el

conocimiento de nuestra organizacin asociado hoy a un proceso, puede
quedar obsoleto maana. Aunque hablemos de estandarizar procesos, es-
tos debern ser constantemente repensados y analizados. Peter Drucker,
afirmaba: el conocimiento es distinto a todos los dems recursos. Este se
hace obsoleto constantemente, por lo que el conocimiento avanzado de
hoy es la ignorancia de maana. Al igual que el cambio, la obsolescencia
del conocimiento inyectado en nuestros procesos de negocio es otra reali-
dad que deberemos vigilar, pero para ello, contaremos con el compromiso
de nuestra organizacin en la mejora continua y la mejora constante de
procesos a travs de una disciplina como BPM, que nos permitir de una
forma rpida y no traumtica la adaptacin al cambio y la adopcin de nue-
vos conocimientos mejorados de nuestra organizacin en los procesos de
negocio que regirn el funcionamiento de la misma.
125
Modelos de negocio
Para la consecucin de nuestros objetivos empresariales, comenzaremos

nuestro camino no trabajando directamente sobre nuestros procesos, sino
en una parte mucho ms creativa que se iniciar con el diseo del modelo
de negocio y que continuar con el diseo de las estrategias, tcticas, metas
y objetivos de negocio, las cuales trasladaremos finalmente al diseo de los
procesos que soportarn en su operativa los propios modelos de negocio
que hayamos definido y permitirn la permanencia de estos modelos en el
mercado as como el poder adaptarlos a los cambios y a las necesidades
cambiantes de nuestros clientes y mercados.
Los modelos de negocio podemos definirlos como el sistema interconec-

tado e interdependiente de actividades que determinan como una empresa
hace negocio creando valor a sus clientes. El modelo de negocio es la repre-
sentacin resumida de una empresa, son los planos generales en los cuales
aparecen aquellos elementos relevantes para que el negocio exista y en el
que se describe que ofrecemos a nuestros clientes, como nos relacionamos
con ellos, como ganamos dinero y como crearemos valor.
Veamos el Ciclo de Vida de la empresa:
1. Planificar que voy a hacer en mi negocio. El modelo.

2. Qu voy a necesitar para implementar ese modelo.
3. Transformar los recursos (inputs), para convertirlos en el re-
sultado de mi negocio (outputs).
4. Entregar los productos y/o servicios.
5. Monitorizar y evaluar qu hemos comprado, transformado
y entregado y verificar que esto se ajusta a lo planificado
para retroalimentar al punto primero.
En todo este ciclo tenemos varios flujos que conformaran el modelo de

negocio de nuestra organizacin: financieros (cuanto me cuestan los recur-
sos y que dinero percibo por los productos que vendo), flujos de compras,
de productos, de ventas, tecnolgicos, etc. y que conjuntamente conforma-
rn nuestro modelo de negocio. Normalmente partimos de una idea de
negocio, pero que tendremos que conformar para pasar del qu vamos a
hacer, al ms difcil de cmo vamos a hacerlo.
Existen varias herramientas y metodologas para ayudarnos a disear

nuestros modelos de negocio, pero probablemente la herramienta ms
126
influyente sea el Business Model Canvas del libro Business Model Genera-
tion de Alexander Osterwalder y Yves Pigneur. Este modelo parte de nueve
bloques bsicos relacionados entre s, que describen diferentes aspectos de
la idea de negocio necesarios para que una empresa pueda aspirar a ganar
dinero, estos nueve bloques cubren las cuatro reas principales de un ne-
gocio: clientes, oferta, infraestructura y financiera conformando el plano
general de la estrategia a implementar a travs de las capacidades y estruc-
turas de la organizacin. Los nueves bloques sobre los que se basa este
modelo son: segmento de clientes, propuesta de valor, canales, relaciones
con clientes, corrientes de ingresos, recursos clave, actividades clave, part-
ners clave y estructura de costes. El uso de esta herramienta es ms que
recomendable para la generacin de modelos de negocio y es recomenda-
ble dedicar algo de tiempo a completar este Canvas (lienzo) para tener una
idea mucho ms clara de nuestras ideas de negocio. Para profundizar en el
Business Model Canvas podemos recurrir a la lectura del libro de sus crea-
dores: Business Model Generation.
Nuevos modelos para nuevos mercados:
Para muchos la poca del marketing tradicional ha llegado a su fin. Los

negocios de hoy en da requieren que una vez analizada la posicin que
queremos en una determinada cadena de valor, podamos hacer experimen-
tos de mercado, pues no podremos saber a ciencia cierta que va a tener
xito y que no lo va a tener, necesitamos poder prototipar modelos de
negocio, evaluar muchas variables y entornos y jugar con los modelos de
negocio antes de lanzar una idea o empresa.
El diseo del modelo de negocio que realicemos para nuestra empresa

ya no es, segn hemos aprendido en las escuelas de negocio, un proceso
lineal en el que podemos analizar numricamente el plan de negocio y los
resultados esperados, de forma que podamos predecir claramente el xito
o el fracaso de un proyecto. Incluso las grandes empresas que han crecido
en base a un modelo de negocio concreto, ahora se estn dando cuenta
que estos modelos estn agotndose e intentan crear nuevos modelos de
negocio que les permitan mantener sus posiciones en el mercado, pero el
error ocurre cuando se pretende realizar este cambio basndose en la mis-
ma mentalidad y cultura corporativa que las hizo desarrollarse y crecer, por
lo que fracasan en la generacin de estos nuevos modelos.
127
El diseo de los nuevos modelos de negocio requiere no slo del anlisis,

sino tambin de una nueva cultura corporativa, la predisposicin a la inno-
vacin en todas sus reas y a la creatividad aplicada al diseo de negocios,
pues son en estas facetas en las que ms tiempo y habilidades debemos
emplear si queremos llegar a buen puerto con el proyecto o modelo de
negocio que emprendamos.
En este camino, debemos recordar lo visto en el apartado anterior de

innovacin sobre como el precio y los productos son hoy en da fcilmente
imitables por su homogenizacin. La diferencia hoy se encuentra en las
experiencias de usuario que proporcionemos a nuestros clientes con nues-
tros nuevos y mejorados productos, capaces de sorprender a los clientes y
en como analicemos e identifiquemos las necesidades y expectativas de
estos clientes para encontrar nuevas oportunidades y posibilidades de me-
jora.
Escuchar a los clientes:
Una de las principales caractersticas que distingue a las personas que

estn detrs de muchos de los productos ms exitosos es su capacidad de
ver sus productos y procesos de negocio a travs de los ojos de sus clientes,
hacindose constantes preguntas sobre su eficiencia y grado de cumpli-
miento con las necesidades y expectativas de estos clientes. Esta orienta-
cin marcar el funcionamiento de toda la empresa para adaptar nuestros
productos y servicios a estos clientes mediante la eliminacin de los puntos
dbiles e ineficiencias en los procesos productivos para obtener productos
que enamoren y seduzcan a sus clientes. Las preguntas que nos podemos
hacer son: qu odio de este producto o de la empresa que lo comerciali-
za?, qu me resulta irritante? por qu escojo a esta empresa y no a otra?,
qu mejorara mi experiencia como usuario?. La clave estar en diferenciar
a los distintos tipos de clientes, reconocer sus particularidades y en obser-
varlos y conocerlos en profundidad, pues estos no siempre transmiten lo
que sienten u opinan sobre nuestra empresa y sus productos, de forma que
podamos reducir el gap entre lo que nuestros clientes compran y lo que
realmente desean.
Las empresas invertimos el 90% de los presupuestos en dirigirnos a los

clientes en lugar de escucharlos. Una vez cerramos la venta, dedicamos
poco o ningn esfuerzo para continuar al lado del cliente y prestamos poca
o nula atencin a proveerle de un buen servicio post-venta. Es como si una
128
vez realizada la venta, huysemos del cliente para no mantener una rela-
cin duradera con este en el tiempo que nos permita aprender de l, reca-
bar informacin sobre sus nuevos gustos y expectativas y mantener abier-
tas nuevas oportunidades de venta.
La gran innovacin del marketing actual reside en la transformacin del

mismo de un enfoque outbound (saliente): de la empresa hacia el cliente, a
un enfoque inbound (entrante): de los clientes hacia la empresa. En estas
segundas, las inbound, existe un elemento diferenciador de gran valor: la
atencin y predisposicin del cliente que ha tenido la voluntad de iniciar el
contacto y dirigirse a nuestra empresa y este movimiento debemos aprove-
charlo, pues tiene todava ms valor que el producido por nuestra empresa
para acercarnos al cliente. Bajo esta perspectiva se han desarrollado nuevos
paradigmas como SCO (Succesful Customer Outcomes), en el que el princi-
pio fundamental es que todo lo que hace la empresa debe contribuir al SCO
y lo que no contribuya, es susceptible de ser eliminado. SCO pone al cliente
en el centro del mapa, es una filosofa de management que rechaza la idea
de que toda actividad debe ser vista como una lnea de produccin de iz-
quierda a derecha con los clientes al final o fuera del grfico, e incluye m-
todos como CEMMEthod (Customer Expectation Management Method) y
conceptos como Enterprise Process Maturity. El cliente es cada vez ms el
centro de nuestros procesos y las empresas debern dejar de ver solo hacia
sus procesos productivos y la mejora de los rendimientos empresariales y
extender la visin hacia afuera, para abarcar e involucrar en los procesos a
los clientes ms all de los lmites de la organizacin.
Escoger Modelos de negocio:
Existen infinidad de empresas con diferentes modelos de negocio que

han sido probados con xito, por lo que dispondremos de infinidad de mo-
delos en los que encontrar patrones que adaptar, modificar y mejorar para
nuestros propios modelos. A continuacin presentamos algunos modelos
genricos que pueden ser de aplicacin:
1. Long tail:
O lo que es lo mismo, vender ms cantidad aunque los beneficios sean

menores. Hasta la irrupcin de Internet, la mxima era que pocos produc-
tos daban la mayora de los beneficios. El paradigma de long tail o "cola
larga", introducido por Chris Anderson, lo que nos dice es que lo que impor-
129
ta es vender muchos productos de nicho que al final sern los que nos da-
rn los mayores beneficios, y esto es posible gracias a la tecnologa que
conecta oferta y demanda y que permite nuevos modos de distribucin.
Un ejemplo de este tipo de modelo de negocio es el de Amazon donde el

negocio se hace disponiendo de acceso a millones de libros de todas la te-
mticas, como Amazon guarda stock mnimo y la mayora de pedidos los
tramita desde el proveedor, la verdadera ventaja sobre el negocio tradicio-
nal de libros est en vender mucho, aunque sean ediciones muy cortas.
2. Plataformas:
Es el negocio de entre otros Google. Es decir poner en comunicacin una

oferta con una demanda. Pero tambin es el modelo de las redes sociales
como Facebook, ebay, etc.
3. Gratuito:
Este es el modelo de negocio que actualmente triunfa en Internet. Los

clientes que no pagan por el contenido. En este caso se puede financiar esta
gratuidad por medio de la publicidad o por el modelo freemium, es decir, el
cliente no paga por servicios bsicos pero paga por servicios Premium.
4. Abiertos:
Son los modelos de negocio en los que se hace uso de las relaciones con
otras entidades para generar valor. Tiene mucho que ver con el concepto
de innovacin abierta. Se puede hacer uso de ideas, propiedad intelectual,
productos que vengan de entidades externas, o se puede explotar los pro-
ductos propios, sean intelectuales o tecnolgicos ofrecindolos al mercado.
Pero no debemos de ver estos patrones de modelos de negocio como is-

las. La combinacin es tambin un patrn reconocible. Qu tal si juntamos
los modelos gratuitos con los basados en plataformas? o el modelo Long
tail y el abierto? Este juego puede reportarnos muchas ideas sobre a dnde
dirigirnos al plantear nuevos modelos de negocio y pueden ser unidos tam-
bin a los nuevos modelos basados en la movilidad y que nos ayudarn a
atender a clientes independientemente de su localizacin geogrfica, o
modelos basados en la nube o en redes sociales.
130
Otra recomendacin que podemos hacer es el probar los modelos de

negocio antes de su lanzamiento, para comprobar su validez, realizar los
ajustes necesarios sobre el mismo y minimizar los riesgos y la incertidumbre
asociados al lanzamiento de cualquier negocio. En BPM haremos un uso
intensivo de las herramientas de simulacin de procesos, las cuales nos
podrn ayudar a evaluar los procesos antes de su implementacin y nos
podrn servir de aproximacin al comportamiento de estos procesos. Sin
embargo, en el rea de simulacin de modelos de negocio, no existe una
herramienta que podamos adquirir para comprobar el grado de xito de un
modelo de negocio, el cual requerir adems de este anlisis, de otros mu-
chos factores internos y externos y habilidades (liderazgo, visin, empren-
dimiento, innovacin, intuicin, oportunidad y suerte). Creemos de todas
maneras que pronto aparecern herramientas basadas en teora de juegos
que nos permitirn jugar con estos modelos a la hora de simular los mis-
mos y ayudarnos a la eleccin del modelo ms adecuado para nuestro ne-
gocio y que servirn de complemento a las ideas y modelos de Canvas (lien-
zos, pizarras) de nuestros modelos de negocio, que al final, son slo eso:
ideas y pizarras de un modelo de negocio diseado, pero que desde luego
no aseguran su xito. Pero mientras estas herramientas no se desarrollan,
la traslacin de nuestro modelo de negocio a procesos, puede servirnos
para probar el comportamiento de estos modelos en base a procesos, ade-
ms, veremos en los siguientes captulos, varias utilidades, herramientas y
estndares que nos permitirn avanzar en la idea y del modelo de negocio a
una especificacin ms detallada de este modelo (arquitecturas empresa-
riales, modelos de madurez, de referencia y mejores prcticas) tanto en lo
relativo a procesos como a entornos de negocio.
Accin y velocidad:
Aunque las ideas y modelos de negocio que desarrollamos no nos pue-

den asegurar cientficamente su xito, existe un componente fundamental
para cualquiera de estos modelos que si juega un papel fundamental en las
posibilidades de xito o fracaso de estas ideas y modelos que es la predis-
posicin a la accin y la velocidad con la que ejecutemos estos modelos.
Por desgracia, muy pocas personas y empresas en la historia toman las

riendas de su destino para lanzar una empresa de xito y la razn principal
suele encontrase en la falta de accin. Son muchas las empresas que a pe-
sar de disponer de una magnfica estrategia, metas y objetivos de negocio,
estos nunca llegan a materializarse. Algunas veces, esta inaccin ocurre por
131
exceso de dedicacin a los detalles previos a un lanzamiento que nunca

llega a materializarse y por la necesidad de tener todo perfectamente con-
trolado. Como deca Mario Andretti, el famoso piloto de Frmula 1: si todo
est bajo control, es que vas demasiado lento. Pero la mayor parte de las
veces, esta parlisis es debida a que no se toman las medidas para que las
cosas ocurran y se lleven a cabo los objetivos planificados. A pesar de con-
tar con un buen modelo de negocio, una estrategia para llevarlo a cabo y
unos procesos perfectamente definidos para obtener los resultados espe-
rados, la falta de accin lleva a que todo este trabajo se pierda en el tiempo
sin llegar nunca a materializarse.
Muchas veces desglosamos todas las fases y paquetes de trabajo de

nuestro proyecto de forma perfectamente definida y estudiada, estimamos
los recursos, los tiempos y las actividades necesarias para alcanzar las me-
tas que nos hemos propuesto y luego dejamos caer estas actividades en el
saco de los olvidos. Los conocimientos e inteligencia que ponemos en plani-
ficar y saber cmo hacer las cosas resultan intiles, si luego no implemen-
tamos las acciones necesarias para llevarlas a cabo.
El implementar la gestin por procesos o innovar se hace actuando, y

para poder actuar con la energa necesaria, necesitamos motivacin, creer
en lo que estamos dispuestos a hacer (primero fue el pensamiento) y esta
es la nica manera de realizar nuestros sueos personales y empresariales,
por encima de los conocimientos e inteligencia que aportemos a los mis-
mos.
En el reconocido como mejor libro de gestin de todos los tiempos En

Busca de la Excelencia de Tom Peters, el lema principal del libro deca: La
excelencia tiene que ver con el enfoque en las Personas, los Clientes y la
Accin. Tom Peters revis 20 aos despus este libro donde actualiz y
replante los 8 principios de la excelencia, afirmando que la idea de per-
manencia est muerta y que cualquier modelo de negocio o estructura or-
ganizativa basada en la permanencia est condenada al fracaso. Tom Peters
vaticinaba la necesidad de una decidida apuesta por el talento, por la bs-
queda constante de la innovacin, de la excelencia en todo lo que hacemos
y de las ilimitadas posibilidades que ofrece internet. En este libro, Peters
avanza que ya no valen las antiguas reglas, hay que reinventarse da a da y
conclua que la ausencia de una predisposicin a la accin sigue siendo hoy
en da el mayor problema de las grandes organizaciones, que piensan y
planifican demasiado.
132
Al hablar de los modelos de negocio, resaltbamos la importancia de la

parte creativa sobre la de anlisis y de la necesidad de habilidades humanas
asociadas a esta para el diseo de modelos de negocio exitosos. Esta prcti-
ca o necesidad es necesaria no slo en el diseo de los modelos de negocio,
sino en todos los aspectos tanto de negocio como de la vida y as, por
ejemplo, la solucin a una mala situacin econmica dentro de nuestra
empresa tiene muchas veces ms que ver con la actitud y predisposicin a
la accin que tengamos para resolver el problema que con el anlisis de los
nmeros y variables econmicas que podamos analizar.
Como hemos visto las organizaciones innovadoras convierten las ideas

(mediante la confrontacin de los problemas con el conocimiento) en valor.
Pero esta capacidad ya no es suficiente por si sola si no somos capaces de
hacerlo con velocidad y de forma constante. No se puede concebir la inno-
vacin sin velocidad y constancia, porque sin estas, las ideas resultarn
efmeras o sern copiadas por alguna otra empresa ms rpida que noso-
tros y no seremos capaces de mantener las ventajas competitivas alcanza-
das mediante la innovacin. Innovar no es tan sencillo como parece y tan
importante como innovar y ser capaces de generar valor, es ser capaces de
hacerlo de forma permanente y ms rpido que nuestros competidores.
Tanto la necesidad de accin como la velocidad para lanzar nuestras in-

novaciones y proyectos requerirn de un liderazgo innovador y efectivo.
Hablaremos ms adelante de este liderazgo as como del necesario com-
promiso de los niveles directivos con los proyectos que emprendamos, pues
requeriremos de ambos para nuestros proyectos de BPM y sin estos, resul-
tarn intiles todos nuestros esfuerzos por extraer lo mejor de las personas
de nuestra organizacin para generar ideas, innovar, trabajar en la mejora
de procesos o adaptarnos al cambio.
Pero ha llegado el momento de adentrarnos en BPM, donde todas las

ideas vistas en esta primera parte del libro nos ayudarn a entender esta
nueva disciplina y a extraer el mayor partido de los proyectos que empren-
damos.
133
PARTE 2. BPM (BUSINESS
PROCESS MANAGEMENT)
Cap. 4. Qu es BPM.
Cap. 5. Modelado de Negocios.
Cap. 6. Modelado de procesos. BPMN
Captulo 4. BPM (Business Process Management)
Captulo 4. BPM (Business Process Ma-

nagement).
Qu es BPM
Al igual que con la definicin de procesos, existen numerosas definicio-

nes de qu es BPM. Esto es debido en gran parte a que BPM es muchas
cosas al mismo tiempo y abraza un gran nmero de prcticas, teoras de
management y tecnologas, por lo que proporcionaremos una definicin
global de BPM como:
La metodologa que orienta los esfuerzos para la optimizacin de los

procesos de negocio de la empresa, en busca de la mejora de la productivi-
dad, la eficacia y la eficiencia de la misma por medio de la gestin sistem-
tica de los procesos que deben ser modelados, automatizados, integrados,
monitorizados y optimizados de forma continua.
Como creo que esta definicin, es tan completa como extensa y para
consolidar un poco ms el trmino, proponemos algunas definiciones com-
plementarias:
- BPM tambin puede ser visto como una filosofa de gestin que
tomando como foco los procesos, propone la gestin, medicin y
mejora de los mismos para la mejora del rendimiento y la excelen-
cia empresarial.
137
- BPM es una estrategia para gestionar y mejorar la operativa de ne-

gocio mediante la mejora continua de los procesos de negocio que
permite modelar, automatizar, ejecutar, gestionar, optimizar los
mismos y medir los resultados.
- BPM es una filosofa de management que maximiza la agilidad de
negocio, facilitando la planificacin estratgica de los objetivos de
negocio, la mejora continua de procesos y la aplicacin de la tecno-
loga.
- BPM es un conjunto de mtodos, herramientas y tecnologas utili-
zados para disear, representar, analizar y controlar procesos de
negocio operacionales, combinando las tecnologas de la informa-
cin con metodologas de gestin por procesos.
- Para Johan Nelis, BPM es: Alcanzar los objetivos de una organiza-
cin a travs de la mejora, la gestin y el control de los procesos
esenciales de negocio.
Como vemos, todas estas definiciones son una tautologa, donde el n-

cleo duro, el objetivo ltimo de BPM es la mejora de los productos y servi-
cios que comercializa una empresa mediante una aproximacin estructura-
da a la realizacin de mejoras, centrada en el diseo sistemtico y en la
gestin de los procesos de negocio.
Ciclo de Vida de BPM.
El ciclo de vida de BPM es parecido al ciclo de vida de Six Sigma (DMAIC)

que hemos visto anteriormente. Este ciclo de vida permite a las organiza-
ciones crecer y evolucionar en sus procesos sobre la base de que los proce-
sos deben cambiar, pues los negocios cambian, crecen y evolucionan. En
BPM asumimos la realidad de que en los procesos de negocio y en los nego-
cios de hoy en da, cada vez se involucran un mayor nmero de actores:
distintas personas, agentes, partners, colaboradores y tecnologas, que
implican la gestin de distintos tipos de relaciones persona a persona, sis-
temas a sistemas y personas a sistemas, por lo que la gestin de nuestros
procesos debe involucrar todos estos tipos de transacciones.
Las fases del ciclo de vida de BPM que seguiremos son:
- Disear: entender los procesos actuales y los sistemas de in-

formacin involucrados para disear y mejorar los procesos que
138
reducirn los problemas actuales y prevendrn los futuros. Esta

fase debe basarse en un anlisis efectivo y definicin clara de
requerimientos e incluir las reglas de negocio, los interfaces y
enlaces con otros sistemas involucrados en los procesos.
- Modelado: la mejor forma de entender los procesos ser me-
diante el modelado de los mismos y su simulacin, donde anali-
zaremos los escenarios posibles para analizar cmo estos afec-
tan al resultado o salida del proceso.
- Ejecutar: implementar la solucin en un entorno de produccin.
- Monitorizar: monitorizar los procesos determinando que de-
bemos monitorizar y medir en los procesos durante su ejecu-
cin: tiempos, costes, retrasos, rendimiento, etc.
- Optimizar: analizando los datos monitorizados, identificar posi-
bles fuentes de problemas y mejoras sobre los procesos para
trabajar en la mejora continua de los procesos.
Modelar
Disear Ejecutar
Optimizar Monitorear
BPM como paraguas de otras teoras:
BPM retomar las teoras de gestin empresarial anteriores de autores

como Taylor, Drucker, Hammer, Porter, Davenport, Demming y otros auto-
res para hacer uso de los resultados alcanzados por la evolucin en el desa-
rrollo de los sistemas de informacin empresarial y construir un modelo
139
sobre el cual desarrollar los fundamentos de la organizacin y gestin em-

presarial, que poniendo el foco en la gestin de los procesos, permitir el
uso a travs de ella de todo tipo de prcticas, mtodos y teoras de gestin
empresarial como puedan ser Six Sigma, TQM o Reingeniera, adaptndose
perfectamente al uso de estas teoras, no porque haya sido diseado para
ello, sino porque al centrarse en los procesos ha resultado que todas estas
teoras han encontrado en ellos una va no slo de expresin sino tambin
de implementacin.
Vimos en el captulo anterior como el propio Deming ya hablaba de la

gestin por procesos como uno de los siete conceptos centrales de TQM y
como Michael Hammer afirmaba que la gestin por procesos es el paraguas
sobre el que TQM, Six Sigma y BPR podran trabajar conjuntamente. Aun-
que BPM permita englobar a todas estas teoras, el catalizador principal y lo
que constituy el fundamento para el desarrollo y la adopcin de BPM co-
mo disciplina, ha sido la capacidad de este no slo de adaptarse a estas
teoras segn fuese necesario en distintos puntos de un proyecto, sino la
flexibilidad y agilidad para adaptarse al cambio y aprovechar las oportuni-
dades de mercado, al permitir la monitorizacin, la modificacin y la mejora
de los procesos en tiempo real.
BPM y los sistemas de Workflow:
Adems de las teoras anteriores, a nivel tecnolgico los sistemas work-

flow se presentan como los herederos tecnolgicos ms naturales de las
actuales plataformas de BPM, los BPMS. Los workflow utilizados para la
automatizacin de procesos en donde los documentos, informacin o ta-
reas se pasan de un participante a otro para que realicen alguna accin de
acuerdo a un conjunto de reglas definidas en el flujo, han evolucionado
hasta las actuales plataformas de BPM que incluyen a estos sistemas de
workflow en una visin mucho ms amplia.
Aunque visualmente las herramientas de workflow y los sistemas BPM

puedan resultarnos parecidas, BPM es mucho ms que un workflow y mu-
chas veces se les considera una evolucin de estos sistemas a los que se les
han aadido las funcionalidades de las que estos carecan:
- Soporte no slo para personas sino tambin integracin con aplica-

tivos y web services. Las soluciones de workflow se limitaban al flu-
jo de tareas realizadas por personas y documentos.
140
- Incorporacin de un motor de reglas de negocio.

- Arquitectura web.
- Ejecucin paralela.
- Ejecucin dinmica.
- Capacidad de simulacin.
- Estndar en la notacin: BPMN.
- Lenguaje BPEL para transformar el modelado en aplicaciones ejecu-
tables.
Como hemos visto en captulos anteriores, la gestin por procesos no es

algo nuevo y antes del advenimiento de BPM a principios del siglo XXI, ya se
usaban los procesos, sin embargo, su uso se limitaba a la mera representa-
cin de los mismos para mejorar la comprensin y el entendimiento de los
procesos por parte de las personas que participaban en su diseo. Era un
uso a nivel de comunicacin, sin las capacidades de gestin, monitorizacin
y control que tenemos actualmente en BPM.
Componentes principales de BPM
Tradicionalmente, los componentes sobre los que se basa BPM son: Pro-
cesos, Personas y Tecnologa.
Sin embargo en este libro y siguiendo a Johan Nelis, aadiremos un cuar-

to componente: la gestin de proyectos. Si en BPM analizamos y estudia-
mos los procesos como cclicos y repetibles, cuando hablamos de imple-
mentar BPM hablaremos de un proyecto, que como tal, ser nico, con un
inicio y un final y en el que reuniremos recursos durante un periodo de
tiempo determinado para conseguir un propsito determinado. El uso de
esta metodologa de gestin de proyectos ser sobre la que se asienten los
procesos, las personas y la tecnologa para el xito de nuestro proyecto
BPM.
141
Partiendo del axioma que el xito de cualquier proyecto radica en su co-

rrecta gestin, los proyectos BPM son tambin proyectos que deben ser
gestionados de forma metodolgica. Los proyectos de BPM, por involucrar
a personas, procesos y tecnologas, son proyectos complejos y sin una co-
rrecta gestin del proyecto, ms all de los aspectos directamente relacio-
nados con BPM, ser difcil conseguir el xito en su implementacin. Por su
importancia, trataremos los aspectos relacionados con la gestin de proyec-
tos y la metodologa del PMI (Project Management Institute) en el Captulo
7 dedicado a la implementacin de proyectos BPM.
Johan Nelis ilustra la importancia de la gestin de proyectos en BPM

como un taburete de tres patas (procesos, personas y tecnologa), en el que
la gestin de proyectos representa el sustento para las tres patas del tabu-
rete y sin la cual todo el proyecto se derrumbara.
Otros autores y/o empresas amplan este nmero de elementos princi-

pales a otros aspectos no menos importantes y relevantes como son:
- La estrategia: pues de esta partir el diseo y mejora de nuestros

procesos y marcar todo el ciclo de vida de estos, por lo que siem-
pre deberemos velar por el correcto alineamiento de esta estrate-
gia con nuestros procesos para pasar de la gestin de procesos a la
gestin por procesos.
- Gobernanza: la cual establecer los roles y responsabilidades en la
ejecucin y seguimiento de los procesos.
- Mtodos: el conjunto de mtodos, tcnicas y herramientas que nos
permitirn el desarrollo de las actividades a lo largo del ciclo de vida
de los procesos como las herramientas de modelado de procesos,
Six Sigma, TOGAF, etc.
142
- Cultura: asociada a la empresa y su orientacin a procesos y que se

ha demostrado como de vital importancia para el xito de los pro-
yectos de BPM.
No discutiremos cuales son ms o menos importantes, desde luego que

todas lo son y tal vez los elementos primeros: procesos, personas y tecno-
logas puedan y deban ser siempre tenidos en cuenta, pero sin obviar al
resto de elementos que debern tambin ser considerados, dependiendo
de la organizacin y del proyecto en que trabajemos, sabiendo que son
igual de importantes, aunque por ligereza, consideremos los tres bsicos
como centrales y sern los que describamos a continuacin con ms deta-
lle.
Procesos:
Para el xito de un proyecto de BPM debemos reconocer la importancia

de los procesos dentro de la organizacin, la necesidad de su correcto dise-
o y medicin de su operativa para poder afrontar la posterior mejora de
los mismos.
Aunque variando el alcance y el punto de vista utilizado, muchos de los

trminos y teoras de la gestin por procesos vistos en el Captulo 1 forman
parte tambin de BPM en la medida en que BPM trata principalmente so-
bre la gestin de procesos de negocio. Si en el Captulo 1 nos centramos
nicamente en el enlace entre las actividades realizadas por personas y
sistemas para proporcionar una salida que aporte valor al cliente, en BPM
proporcionamos un marco de trabajo a partir de una estrategia y orienta-
cin hacia la mejora continua a travs de la optimizacin de sus procesos de
negocio, siguiendo un ciclo de vida de modelado, ejecucin y medida de los
procesos y en consecuencia, elevaremos BPM a la categora de disciplina de
gestin.
Bajo una perspectiva ms amplia que la vista para la gestin de proce-

sos, trabajaremos a partir de ahora con la definicin de un proceso de ne-
gocio como una serie de actividades realizadas para implementar una estra-
tegia o alcanzar un resultado u objetivo empresarial.
143
Personas:
Las personas sern sobre las que se sustent el proyecto y marcarn el

grado de xito del proyecto antes, durante y despus de su implementa-
cin. La importancia de las personas radica en que stas sern los usuarios
del proyecto y como es lgico, todo el esfuerzo realizado en el proyecto no
tendr sentido si finalmente los usuarios no utilizan y ejecutan las tareas y
operaciones especificadas en el proceso. Ms an, en BPM no slo necesi-
taremos de su compromiso para ejecutar estas tareas con diligencia y res-
ponsabilidad, sino que buscaremos su implicacin en los resultados del
proceso y del proyecto desde las fases ms tempranas del mismo para co-
laborar, participar y recompensar el trabajo en la bsqueda de soluciones y
mejoras de los procesos. El compromiso de las personas de nuestro equipo,
ser el principal atributo capaz de realizar la transformacin de la visin en
un proyecto real con resultados. Los proyectos de BPM no son proyectos
sencillos y tienen asociado un fuerte componente de cambio y de nuevas
formas de hacer las cosas dentro de las organizaciones en que se implanta,
por lo que ser necesaria una actitud proactiva frente a bsqueda de solu-
ciones y mejoras y no reactiva a la espera de que surjan los problemas o el
proyecto fracase.
Otro aspecto caracterstico e importante en los proyectos de BPM es el

de la colaboracin entre el personal de negocio y el personal de TI en los
proyectos. En los proyectos de BPM pueden y deben colaborar conjunta-
mente la gente de negocio y de tecnologa para producir procesos de nego-
cio ms eficientes, giles, veloces y transparentes. BPM unifica los depar-
tamentos de negocio y tecnologa para trabajar conjuntamente entorno a
los procesos de negocio de la empresa, de forma que ambos colaboren en
el diseo, implementacin, anlisis y optimizacin de los procesos de nego-
cio. Esta colaboracin se producir principalmente a travs de la herramien-
ta de modelado de procesos y por la comparticin de un lenguaje de nota-
cin de procesos entendible tanto para los perfiles tcnicos como de nego-
cio, de forma que ambos puedan colaborar en el diseo, el anlisis y mejora
de procesos y pudiendo desde la propia herramienta de modelado imple-
mentar estos procesos sin necesidad de conocimientos de programacin.
Sobre esta herramienta de modelado, podemos establecer las reglas de
negocio que regirn el comportamiento de los procesos, establecer los indi-
cadores y medidas sobre los procesos y los datos y valores asociados a los
mismos para posteriormente ser evaluados para analizar su eficacia y una
vez analizados, aprobados y puestos en produccin, poder ser monitoriza-
dos y controlados a travs de la misma herramienta.
144
Esta colaboracin entre los perfiles de negocio y de TI para alinear nego-

cio y tecnologa para la consecucin de los objetivos y el cumplimiento de
las estrategias empresariales, proporcionar una nueva dimensin llena de
posibilidades para reducir el histrico gap existente entre estos dos aspec-
tos de la empresa y ser una de las claves fundamentales sobre las que se
basarn los proyectos de BPM.
Tecnologa:
La tecnologa por s sola no implica la mejora en la gestin empresarial ni

en la gestin de procesos de negocio, en la competitividad o en los resulta-
dos empresariales. Esta tecnologa deber estar alineada con el negocio y
de ah que BPM adopte este alineamiento como punto de partida para to-
das sus iniciativas de mejora de los resultados empresariales a travs de los
procesos de negocio como hilo conductor.
En los proyectos de BPM no seguiremos el camino directo de implemen-

tar las TI a machete para la mejora del negocio, repitiendo errores del
pasado en la implantacin de TI sin considerar los aspectos de negocio ni la
colaboracin con el personal de esta rea de conocimiento de la organiza-
cin. En BPM, sin perder la perspectiva tecnolgica, alinearemos previa-
mente las soluciones de TI con los aspectos de negocio, no slo para la op-
timizacin y rentabilizacin de nuestras inversiones en TI, sino para que
estas hagan lo que deben hacer: dar soporte y mejorar los modelos y estra-
tegias de negocio. Este camino es el ilustrado en el siguiente grfico.
BPM es una disciplina basada en pensar primero en como ejecutar co-

rrectamente los procesos y objetivos de negocio para posteriormente utili-
zar la tecnologa para automatizar y controlar los procesos diseados. Esto
145
implica que la tecnologa ser imprescindible para BPM y si ella no podr

realizarse BPM. A menudo se dice que un proyecto BPM es un 60% estrate-
gia y un 40% tecnologa.
Las herramientas tecnolgicas que posibilitarn BPM son los BPMS (Bu-
siness Process Management Systems), que sern las herramientas tecnol-
gicas que herederas de los avances en tecnologas de la informacin, de la
orientacin a procesos y del entendimiento de estas como necesarias para
alcanzar los objetivos y estrategias empresariales, nos permitirn modelar,
automatizar, gestionar, medir y mejorar los procesos de negocio. Los BPMS
nos facilitarn las necesarias tareas de integracin con los sistemas ya exis-
tentes en la empresa: ERP, CRM, etc. sin necesidad de reemplazar la in-
fraestructura de TI existente en nuestra empresa ni realizar modificaciones
sobre estos sistemas, por lo que minimizamos en consecuencia el impacto
econmico de los cambios producidos por los proyectos de BPM. Tal vez la
caracterstica visualmente ms atractiva de los BPMS es que al igual que
hace unos aos tenamos los sistemas WSIWYG (What You See Is What You
Get) en las Suites para desarrollo de aplicaciones informticas, con BPM
tenemos WYMIWYR (What You Model Is What You Run), pues no slo te-
nemos el modelo de proceso y la posibilidad de evaluar y analizar su com-
portamiento, sino que adems podemos ejecutarlo y modificarlo en un
entorno visual tantas veces como queramos, sin necesidad de crear un nue-
vo proyecto informtico para cada cambio o modificacin en nuestras nece-
sidades de negocio.
Principios, prcticas y ventajas de BPM.
Como espero que el lector descubra a largo del presente libro, BPM
ofrece a las organizaciones de cualquier tipo de una completa disciplina
para la mejora de los resultados empresariales. Como hemos visto en las
estrategias de reduccin de costes, la evaluacin de una empresa a partir
del anlisis de los resultados financieros, suele ser comparado como condu-
cir mirando constantemente por el espejo retrovisor, observando por don-
de ya hemos pasado. La perspectiva de BPM es ms parecida a encender los
focos de nuestro coche para visualizar el camino por el que deberemos ir, y
donde estos focos que iluminan el camino sern representados por la bs-
queda de la excelencia, la eficiencia y la mejora de procesos. Pero para po-
der encender estos focos, deberemos entender primero los principios sobre
los que se asienta BPM y las ventajas que esta disciplina pueden aportar.
146
Principios de BPM:
- Los procesos son los activos ms importantes de nuestra em-

presa y crean valor a nuestros clientes lo que justifica su exis-
tencia en la empresa.
- Las empresas deben invertir en los procesos como la hacen en
otros activos de la empresa.
- Midiendo, monitorizando, controlando y analizando los proce-
sos de negocio, una empresa puede dar valor a sus clientes de
forma continua y dispondr de la base para la mejora de proce-
sos y su reutilizacin.
- Es necesaria la involucracin de la gente de negocio y no slo
de TI, en el diseo de soluciones de automatizacin y mejora de
procesos.
- La simulacin del comportamiento de los procesos ayuda a la
optimizacin de estos.
- BPM lo podemos usar para mejorar procesos, optimizar nues-
tras inversiones en TI, implementar arquitecturas SOA o trans-
formar el negocio.
- Al igual que en TQM y Six Sigma, cuando los procesos son moni-
torizados, podemos identificar las variaciones que producen in-
consistencias.
- Puesto que los procesos son activos clave de la empresa, estos
deben ser gestionados y mejorados constantemente para pro-
veer valor continuamente a los clientes.
- Las TI son esenciales para implementar BPM, al proveer de in-
formacin en tiempo real de la operativa de los procesos.
Prcticas de BPM:
- Buscar una estructura de la organizacin orientada a procesos:

una organizacin proceso cntrica es aquella que reconoce la
centralizacin de sus procesos para la mejora de su negocio, los
valora, invierte en ellos y los mejora constantemente. En una
organizacin orientada a procesos los empleados son parte de
los procesos y la meta de la organizacin orientada a procesos
es crear valor a sus clientes.
147
- Los proyectos ms exitosos de BPM resultan cuando estos son

alineados con las metas y objetivos de la empresa. Una vez que
conocemos estas metas y objetivos es posible determinar los
procesos que mejor se alinean con ellos para luego disearlos,
implementarlos y gestionarlos con BPM. Para conseguir este
alineamiento es necesaria la implicacin de la alta direccin de
la empresa que debe apoyar y dirigir la ejecucin estos proyec-
tos.
- Utilizar una aproximacin bottom-up para identificar los proce-
sos, tener en cuenta a los empelados desde el primer momento
nos ayudar a que el proyecto sea ms exitoso al haber disea-
do desde el principio los procesos con estos trabajadores que
tras la implementacin debern mantener los procesos y parti-
cipar en su mejora.
- Establecer quines son los responsables de los procesos.
- Trabajar en colaboracin con los partners de negocio, provee-
dores y colaboradores, conscientes de que los procesos atravie-
san no slo a nuestra organizacin, sino que tambin traspasan
los lmites de esta.
- Adems de involucrar a los empleados, velar por su formacin y
preparacin constante, ser clave para el xito del proyecto.
- Alinear las recompensas a empleados con la realizacin de los
procesos.
- Utilizar tanto metodologas incrementales (Six Sigma) como ra-
dicales (BPR) para implementar la mejora de procesos.
- Disear los procesos alrededor de las salidas de los mismos y no
de las tareas.
- Corregir y mejorar los procesos antes de automatizarlos.
- Estandarizar procesos en la empresa.
Ventajas de BPM:
Con BPM y las tecnologas que le dan soporte, los BPMS (Business Pro-
cess Management Suites) podremos:
- Modelar los procesos de nuestra organizacin abarcando la ca-

dena de valor y coordinar los roles, personas, sistemas y recur-
sos que participan en los mismos.
- Ganar en visibilidad de los procesos.
148
- Mayor flexibilidad y agilidad para adaptarse al cambio.

- Integrar informacin de distintas fuentes.
- Dirigir los esfuerzos de la empresa de forma planificada y ali-
neada con los objetivos y estrategias empresariales.
- Reducir costes. Cuando los procesos son eficientes, estos ven
reducido el coste requerido para obtener las salidas del proce-
so.
- Mejorar la eficiencia. Mediante la reduccin de las prdidas de
tiempo, mano de obra o exceso de trabajo en el funcionamien-
to del proceso.
- Mejorar la satisfaccin de clientes. Ejecutando nuestros proce-
sos de forma ms rpida, eficiente y efectiva, los clientes recibi-
rn no slo mejores productos y servicios, sino tambin una
mejor experiencia de compra.
- Integrar sistemas de informacin y aplicativos externos y de
terceros.
- Ejecutar y convertir los modelos en aplicaciones ejecutables.
- Monitorizar y realizar el seguimiento y control del rendimiento
de los procesos en base a indicadores.
- Controlar y responder a eventos de procesos dependiendo de
las distintas situaciones.
Estas funcionalidades proporcionarn importantes ventajas a distintos

perfiles de la empresa, que sin BPM seran difciles de lograr:
- Directores de TI: de forma que estos puedan aplicar sus habili-

dades y recursos de forma ms directa en las operaciones de
negocio.
- Directores de negocio: que podrn ms directamente controlar
y responder a todos los aspectos de los procesos de negocio,
acortando el Gap existente entre negocio y TI y en conse-
cuencia, hacer que los sistemas respondan de forma ms efi-
ciente a los requerimientos de negocio.
- Empleados: que podrn alinear mejor sus esfuerzos y mejorar
su productividad y rendimiento, al disponer de medidas y resul-
tados visibles de las tareas que ejecutan asociadas a los proce-
sos globales de la empresa y en las que han participado desde
el inicio en la definicin de estas tareas, de los procesos de las
que forman parte y en la mejora de su eficiencia y rendimiento.
- La empresa en general: podr responder ms rpido a los cam-
bios para cumplir sus objetivos de negocio.
149
La adopcin de BPM como disciplina y la implementacin de solu-

ciones BPM es utilizada dentro de las organizaciones para:
- Ganar en eficiencia, reduccin de costes, reducir los ciclos de

proceso, eliminar o reducir la entrada manual de datos y los
errores provocados por estas entradas manuales as como la
eliminacin de costes rutinarios a travs de la automatizacin
de los procesos de negocio.
- Mejorar el diseo de productos. Desarrollar productos ms in-
novadores y mejorar la calidad de estos, haciendo uso de las
herramientas de simulacin de BPM para comprobar su eficien-
cia y comportamiento y asegurndonos de que nada falle antes
de su lanzamiento.
- Mayor efectividad en nuestras operativas de negocio. Las em-
presas ven que pueden incrementar beneficios si mejoran sus
procesos o crean un nuevo proceso que les ahorre costes y au-
mente el beneficio y la satisfaccin de sus clientes.
- Alinear procesos y TI optimizando la inversin en estas ltimas y
racionalizando los sistemas informticos de la empresa para
trabajar en base a procesos y objetivos de negocio.
- Poder trabajar realmente en la mejora continua de procesos.
- Ganar en agilidad, aumento de productividad y competitividad,
alcanzar el liderazgo en productos y servicios, aumentar la velo-
cidad en la creacin e implementacin de nuevos procesos y
modelos de negocio y mayor alineamiento de los mismos con
los procesos ya existentes.
Aunque son muchas las ventajas que podemos obtener de la adopcin

de BPM, el lector ir configurando su propio cuadro de ventajas a medida
que profundicemos en los detalles de BPM y su implementacin y adaptan-
do stas a las particularidades de cada organizacin para aprovechar las
distintas posibilidades que BPM pueda ofrecerles.
Reducir el Gap entre tecnologa y negocio.
En su libro Business Process Management: The Third Wave, Peter Fin-

gar y Howard Smith decan: Dont bridge the business-IT divide, obliterate
it, que traducido de forma libre viene a significar: No establezcas un
150
puente entre el negocio y las TI, elimnalo. Esta frase produjo que algunos
profesionales de TI lo considerasen una ofensa, interpretando que esto
significaba hacer desaparecer las TI, cuando lo que realmente pretendan
decir los autores y que explicaron en un artculo posterior, es que elimine-
mos el puente que divide el negocio y las TI. El reducir este distanciamiento,
ser uno de los objetivos y caractersticas principales sobre las que se basa-
rn los proyectos de BPM.
Esta divisin entre negocio y TI ha prevalecido desde las primeras im-

plantaciones informticas hasta nuestros das. Estas implementaciones de
TI tradicionales en las que los analistas de TI y los de negocio vivan en
mundos paralelos pero distintos y en la que unos dicen lo que hay que
hacer y otros lo traducen a cdigo ejecutable, se encuentran cada vez ms
alejadas de la realidad.
Las empresas no quieren tecnologa, sino resultados de negocio y esto

es algo que tanto el personal de negocio como el de TI tienden a olvidar,
centrndose cada uno en sus respectivos mundos y preocupados por sus
propios resultados individuales ms que por los resultados globales de la
empresa. Con BPM la contribucin de las TI debe ser distinta a la tradicio-
nal, en la que los analistas de TI capturan los requerimientos tecnolgicos,
pasando por alto los requerimientos de negocio. Los sistemas de informa-
cin representan un importante papel en la gestin de las empresas y orga-
nizaciones en la actualidad y cada vez ms actividades de negocio se basan
en estos sistemas para ser ejecutados. Ambos mundos: el de negocio y el de
TI, deben aliarse, entenderse y comprenderse para trabajar conjuntamente
en las soluciones y problemas empresariales y al igual que en la innovacin,
el problema no estar en cmo abordar y desarrollar nuevas ideas, sino en
cmo olvidar las viejas y conseguir que ambos perfiles comprendan y asu-
man este necesario acercamiento.
Hoy no concebimos una empresa en la que el negocio pueda ir por de-

lante de la tecnologa o viceversa. Si el negocio va por delante y la tecnolo-
ga no le acompaa, difcilmente el negocio alcanzar los resultados espe-
rados y de igual manera, si la tecnologa va por delante y el modelo de ne-
gocio no le sigue, resultar en un despilfarro y desaprovechamiento de una
oportunidad tecnolgica y en cualquiera de los casos, se producir un
Gap entre lo que el negocio quiere y como las TI implementan lo que el
negocio quiere.
151
Esta situacin es similar a la conocida en el mundo del desarrollo softwa-

re en la toma de requisitos, donde lo que los clientes tienen en mente no
suele coincidir con la imagen de la solucin segn la entienden los progra-
madores y que tantos problemas, revisiones, depuraciones, re-
especificaciones y retrasos provocan en los proyectos de software.
Peter Fingar hace referencia a los programadores, que haciendo uso de

lenguajes no entendibles por el personal de negocio, como puedan ser Co-
bol, C++, Java o UML, pertenecen a una poca totalmente alejada de la
realidad actual de los negocios, en la que estos lenguajes y metodologas de
abstraccin, no facilitan ni provocan el acercamiento entre TI y negocio.
Michael Hammer iba un poco ms lejos y deca que los profesionales de TI
estaban demasiado enfrascados dentro del mundo de los sistemas, sin ser
capaces de reconocer nuevas oportunidades, enfatizando ms lo que no se
puede hacer que lo que se puede hacer y recomendaban apartar a estos
profesionales de TI de las primeras fases en el diseo de procesos de nego-
cio. Recientemente, David Chappell afirmaba en una entrevista: Creo que
en los prximos aos, muchas personas trabajando en TI deben involucrar-
se en los procesos de negocio de forma mucho ms explcita, sino, mejor
que hagan sus maletas y se vayan a Bangalore en India.
La aceleracin de nuevas y diferentes formas de hacer negocio, cada vez

ms basadas en la tecnologa, la comunicacin, la colaboracin y el inter-
cambio de datos entre empresas y donde prima la velocidad y la automati-
152
zacin de actividades frente al desempeo manual de las mismas, hace

necesaria la coordinacin entre personas, recursos y sistemas de informa-
cin y con ellas una adaptacin a nuevas estructuras y modelos de forma
gil para poder mantenerse en los mercados. Independientemente de la
existencia de negocios basados exclusivamente en la tecnologa o pure
players, el reducir el Gap entre negocio y tecnologa es cada vez ms nece-
sario en la medida en que el entorno en el que se desarrollan los negocios
es cada vez ms cambiante a la vez que basado en la tecnologa. No pode-
mos dejarnos llevar por la tecnologa y perder el foco en los aspectos de
negocio, por el contrario, debemos extraer de la tecnologa el verdadero
valor que debe aportar y ponerla al servicio del negocio, sea este la explo-
tacin de una nueva tecnologa o el comercio de plantas ornamentales.
En este camino, los negocios no pueden encontrar trabas y cuellos de

botella a su desarrollo en los sistemas informticos (vitales para la consecu-
cin de estos objetivos), donde cada cambio o modificacin en los sistemas
de informacin es costosa, requiere tiempo y no siempre es capaz de tradu-
cir los requerimientos de negocio de forma gil y veraz. BPM busca eliminar
ese GAP involucrando a los directivos de negocio y personal de TI en el di-
seo conjunto de los procesos de negocio y de las soluciones tecnolgicas
que soportarn estos procesos y proporciona el marco para conjuntar la
forma en que se relacionan el negocio y la tecnologa y reducir lo que la
consultora Gartner denomina el Gap de Rigidez.
Con BPM podemos reducir este Gap entre lo que el negocio necesita y lo
que las tecnologas de la informacin son capaces de proporcionar a estos
153
requerimientos de negocio, poniendo al personal de negocio y de TI a anali-

zar, disear, implementar y monitorizar conjuntamente los procesos de
negocio, haciendo uso de la metodologa de BPM, de sus herramientas de
modelado, que pueden ser entendidas tanto por personal tcnico como de
negocio, de forma que ambos puedan colaborar conjuntamente en la dia-
gramacin y diseo de procesos, en su implementacin, monitoreo y mejo-
ra a travs de las plataformas de gestin de procesos (BPMS). De esta for-
ma, BPM permitir que los negocios sean gestionados por quienes tienen el
conocimiento de los negocios, para desde su definicin, realizar de forma
gil y flexible, la informatizacin, automatizacin y los cambios necesarios
sobre los sistemas para dar soporte en todo momento a las necesidades de
mercado y requerimientos de negocio y clientes.
Cundo implementar BPM
Los objetivos y motivaciones por las que una empresa adopta la discipli-
na de BPM pueden ser muy distintos. Algunas empresas lo harn centrn-
dose en la eficiencia que supone el poder ejecutar sus actividades y proce-
sos de negocio con objeto de conseguir los mismos resultados con menos
recursos de tiempo, materiales o econmicos. Otras empresas lo harn con
objeto de conseguir mayor agilidad y capacidad de respuesta al cambio, o
por pasar de una operativa funcional a una basada en procesos. Sea por
estos u otros motivos, existen multitud de situaciones en los que la adop-
cin de BPM puede ayudar a las empresas a alcanzar sus objetivos. Entre
estos posibles escenarios podemos citar los siguientes:
- Cuando existe un alto volumen de tareas simultneas y repetiti-

vas.
- Necesidad de hacer muchos clculos en tiempo real.
- La existencia de tareas crticas en el tiempo.
- Tareas o transacciones que necesitan ser accesibles por varios
participantes y/o sistemas al mismo tiempo.
- Fusiones o adquisiciones de empresas, en las que se suele nece-
sitar conjugar procesos de varias organizaciones.
- Reorganizacin de empresas o cambios en la direccin opera-
cional.
- Cuando los objetivos y metas de la empresa no son alcanzados.
- Cumplimiento de nuevas normas o regulaciones: Sarbanes, Ba-
sel II, RSC (Responsabilidad Social Corporativa), etc.
154
- La necesidad de dar mayor agilidad al negocio para responder a

cambios y oportunidades.
- Necesidad de mayor control en operaciones y procesos.
- Necesidad de maximizar el ROI y las inversiones en TI.
- Necesidad de ajustes debidos a recortes en los presupuestos.
- Necesidad de aumentar las capacidades del personal para el
desempeo de sus tareas.
- Falta o poca calidad en los productos y servicios.
- Falta de procesos de negocio y mtodos estandarizados.
- Ante la introduccin de un nuevo software, arquitectura de TI,
nuevas inversiones en tecnologa o cuando estas no producen
los resultados esperados o sus costes estn fuera de control.
- Ante la Introduccin de arquitecturas basadas en web services,
cloud computing o SOA, para racionalizar los procesos, como
paso previo y necesario a este tipo de implementaciones tecno-
lgicas si queremos racionalizar y sacar el mximo provecho de
las mismas.
El Modelo de Madurez para la gestin de procesos.

Muchas organizaciones emplean los modelos de madurez (Maturity Mo-
dels) para comprobar como de bien sus organizaciones gestionan sus pro-
cesos. Uno de los modelos de madurez ms populares es CMMI (Capability
Maturity Model Integration), el cual identifica cinco niveles de madurez,
sugiriendo en que tareas deben enfocarse en sus siguientes pasos las em-
presas para avanzar en este modelo de madurez.
CMMI fue inicialmente un modelo para la mejora de los procesos de de-

sarrollo software. Este modelo defina cinco estados, a travs de los cuales,
una organizacin poda pasar de un modelo inmaduro, a un modelo maduro
en el desarrollo de software, permitiendo a las organizaciones definir en
qu punto se encuentran y ayudarles a llegar al estado en el que les gusta-
ra estar.
Basndose en el modelo del CMMI, el OMG (Object Management

Group) desarroll el BMM (Business Maturity Model) para guiar a las orga-
nizaciones en la Gestin por Procesos. Este modelo puede ser seguido como
gua por las empresas y organizaciones de cualquier tipo para identificar el
155
estado en que se encuentran en cuanto a la gestin de sus procesos y ayu-

darles a madurar en la gestin y la mejora de estos.
Los 5 niveles de madurez del BMM.
Al igual que en CMMI y prcticamente todos los dems modelos de ma-

durez, el BMM se divide en 5 niveles que representan los diferentes esta-
dios a travs de los cuales una organizacin mejora en sus capacidades de
gestin de procesos. Estos niveles son los indicados en el siguiente grfico:
Nivel 1. Inicial (Initial):
Los procesos de negocio son implementados de forma inconsistente, al-

gunas veces de forma ad hoc, con resultados que son difciles de predecir.
El alcance de las iniciativas de BPM es muy limitado, los empleados estn
poco involucrados en la gestin por procesos y la empresa tiene pocos pro-
cesos automatizados. Aunque existan algunos procesos automatizados, se
acta de forma reactiva, apagando fuegos cuando estos aparecen, ms
que controlando los procesos de forma proactiva. En este primer nivel, los
procesos existentes no son medidos para evaluar su calidad y necesidades
de mejora y el xito en estas organizaciones depende de las competencias y
esfuerzos individuales de personas de la organizacin y no de la eficacia y
eficiencia debida a procesos bien diseados.
156
Nivel 2. Gestionada (Managed):
La empresa consigue estabilizar el trabajo dentro de una unidad de tra-

bajo o departamento, asegurando que el trabajo pueda ser realizado de
forma repetitiva y cubriendo las exigencias del grupo o departamento en el
que se implanta. Sin embargo, unidades de trabajo dentro de la organiza-
cin que realizan tareas similares, pueden estar usando diferentes proce-
dimientos a los de estas unidades. En esta fase las empresas reconocen la
importancia de BPM, se automatizan procesos principalmente relacionados
con la gestin documental en las unidades de trabajo que se involucran en
la gestin por procesos y adoptan metodologas y el uso de estndares.
Nivel 3. Estandarizada (Standarized):
Se estandarizan y sintetizan los procesos con los procedimientos y prc-

ticas identificadas en las unidades de trabajo del nivel anterior. Estos proce-
sos estandarizados pasan a proveer de economas de escala y la base para
aprender y mejorar.
Nivel 4. Predecible (Predictable):
Las capacidades de los procesos estandarizados son explotadas e inte-

gradas en las unidades de trabajo. Los procesos son manejados estadsti-
camente siguiendo el workflow de los mismos para entender y controlar las
variaciones de forma que las salidas de los procesos pueden ser predichas
de los estadios intermedios.
Nivel 5. Innovacin (Innovating):
En este ltimo nivel, la empresa busca innovaciones que acorten el GAP

entre las actuales capacidades de la empresa y las capacidades para alcan-
zar sus objetivos de negocio.
Cada nivel de los anteriores, est diseado para alcanzar objetivos con-
cretos e incluyen para cada uno de ellos las mejores prcticas para indicar
qu se debe realizar en cada nivel. Aunque se describe el estado a alcanzar
en cada nivel, este modelo permite que cada organizacin pueda definir sus
propios mtodos para alcanzar los objetivos en cada uno de los niveles. El
sentido de este modelo de madurez en la gestin por procesos es que a
medida que una organizacin asciende en los niveles de madurez, la in-
fraestructura y la cultura de la empresa se vayan transformando para dar
soporte a los mtodos y prcticas establecidos en cada uno de los niveles y
157
alcanzar mayores niveles de madurez y excelencia en la gestin de sus pro-

cesos de negocio.
Excepto para el nivel 1, para el resto de niveles en el BMM, se describe

en la especificacin del OMG, el propsito de cada nivel, las metas que se
persiguen y las buenas prcticas que la empresa necesita implantar para
alcanzar las metas y propsitos establecidos en cada fase. Para avanzar en
los niveles de madurez en la gestin de procesos, nuestra empresa debe ser
capaz de implementar las prcticas asociadas a cada nivel para alcanzar los
objetivos del mismo, movindonos de los niveles de inmadurez e inconsis-
tencia en la gestin de procesos, a niveles de madurez y disciplina de forma
incremental a travs de los cinco niveles, de tal manera que cada nivel sien-
ta las bases para poder alcanzar el siguiente nivel.
El BMM es un magnfico modelo que debemos considerar a la hora de

iniciar cualquier proyecto de gestin por procesos, de mejora de los mismos
o proyecto de BPM y puede ser usado por las organizaciones para:
- Describir el estado de cmo est nuestra organizacin, sus for-

talezas y debilidades en relacin a la gestin por procesos.
- Prescribir el camino que debemos seguir para avanzar en la ges-
tin por procesos y la mejora de los mismos.
- Comparar el estado de nuestra organizacin respecto a estn-
dares y a otras organizaciones y como herramienta de bench-
marking.
Los principios sobre los que se basa el BMM son:
- Los atributos de los procesos pueden ser evaluados para de-

terminar la capacidad de los mismos y para contribuir a los ob-
jetivos organizacionales.
- Los procesos no pueden sobrevivir en la organizacin a no ser
que esta sea suficientemente madura como para soportarlos.
- La mejora en procesos se realiza mejor dentro de un programa
de cambio de la empresa, en el que sucesivamente se alcancen
nuevos estadios de predictibilidad.
- Cada estadio o nivel de madurez requiere de una base en su es-
tadio anterior sobre la cual construir las futuras mejoras.
158
La organizacin Orientada a Procesos.
Una organizacin orientada a procesos es aquella que, siguiendo los

principios de BPM, reconoce la importancia de los procesos para su nego-
cio, se ocupa de la gestin de los mismos y los trata como activos de la em-
presa que deben ser cuidados, mantenidos y gestionados correctamente,
consciente de que es su objetivo ltimo, crear valor a sus clientes a travs
de los procesos que ejecuta.
Una de las causas principales de la insatisfaccin de los clientes y sobre

la que no siempre solemos reparar, es la debida a la falta de comunicacin
entre los departamentos de nuestra empresa. La experiencia final de nues-
tros clientes est basada en muchas transiciones y actividades distintas que
atraviesan la empresa, y este flujo, continuo o discontinuo, eficiente o inefi-
ciente, no es percibido por el cliente, ni tiene porque ser comprendido por
l. Al cliente no le importa si no nos hablamos con el departamento finan-
ciero o si los departamentos de marketing y de servicio tcnico tienen una
visin distinta sobre cmo solucionar sus problemas. El cliente, slo quiere
el mejor servicio, calidad y atencin a sus problemas y demandas. A ningu-
no de nosotros nos interesan los procesos internos que debe recorrer nues-
tra solicitud a un banco cuando pedimos un prstamo, lo que queremos es
una rpida respuesta a esa solicitud, para poder tomar nuestras decisiones.
Para conseguir esta orientacin al cliente, precisaremos del compromiso y
la cooperacin de todos los departamentos y unidades de negocio de la
empresa, trabajando de forma alineada y orientada, hacia la prestacin del
mejor servicio y no cuando estas reas funcionales estn ms inmersas en
sus pequeas parcelas, con trabajadores centrados exclusivamente en sus
tareas atmicas y comprometidos con mantener sus estatutos y privilegios
que en los procesos globales de la empresa que son los que finalmente
darn respuesta a las necesidades y expectativas de sus clientes. La gestin
por procesos y BPM implicarn analizar las organizaciones desde un punto
de vista funcional, entendiendo estas como un conjunto de procesos vincu-
lados entre s y superando la imagen departamental a la que estamos acos-
tumbrados. Esta organizacin funcional no presentar la orientacin a clien-
tes requerida separando drsticamente en unidades funcionales la secuen-
cia de actividades para aadir valor y los adecuados niveles de servicio a
nuestros clientes. Para proveer de estos niveles de servicio a clientes resul-
tar mucho ms lgico tomar una perspectiva entorno a la secuencia de
actividades que van aadiendo valor y hacen avanzar al proceso desde el
proveedor al cliente. Para conseguir esta orientacin, las organizaciones de
159
todo tipo deben reconocer la necesidad de alinear a los trabajadores de

todos los niveles y departamentos con la estrategia de la organizacin, de
forma que entiendan su trabajo y como este contribuye a los resultados de
la compaa, visualizando no las pequeas parcelas de trabajo sino el Big
Picture de toda la empresa.
Comenzamos as a ver la organizacin de forma holstica (el todo es ms

que la suma de las partes), pasamos a pensar en la empresa en trminos de
sistemas, procesos de negocio y cadenas de valor, ms que en departamen-
tos aislados. Esta visin tendr implicaciones en las estructuras organiza-
cionales y en los trabajadores de la empresa, los cuales no debern pensar
en cmo realizar mejor las tareas que actualmente realizan, sino en por qu
y para quien hacen ese trabajo, pues la satisfaccin del cliente y la eficiencia
del proceso, vendr determinada por la coherencia en el desarrollo del pro-
ceso completo y no en la de cada una de sus partes constituyentes por se-
parado. Las organizaciones tambin debern abordar cambios en sus es-
tructuras en la adopcin de esta visin, en la que la importancia del proceso
en su conjunto es mayor que la organizacin que los sustenta y muchas
veces, esta estructura organizacional no coincidir o ser la ms apta para
el desarrollo del proceso, por lo que con frecuencia deberemos redisear y
reunificar las actividades del proceso que fueron fragmentadas por la pro-
pia estructura de la organizacin.
Empresa funcional vs. Orientada a procesos.
Las empresas tradicionalmente se han organizado en torno a departa-

mentos basados en las funciones que realiza cada uno de ellos y dirigidos
por directivos especializados en las reas de conocimiento necesarias para
el departamento que dirigen. Estas organizaciones herederas de las teoras
de Adam Smith y que han sobrevivido por ms de 200 aos, se asientan
sobre el organigrama de la empresa como modelo funcional del negocio.
Este tipo de organizacin empresarial divide la organizacin en departa-
mentos o silos funcionales, cada uno de los cuales dispone de sus propios
recursos, presupuestos y objetivos, independientes de los de otros depar-
tamentos y donde las tareas y responsabilidades de cada departamento se
encuentran perfectamente definidas.
160
Esta forma de ver la empresa se conoce tambin como pensamiento o

cultura de silos y es la generadora de que los trabajadores asignados a de-
partamentos de la empresa se pregunten: Por qu debera ocuparme de
lo que hacen los otros, cuando ya tengo bastantes problemas con lo mo?.
De esta cultura se deriva el considerar a unos departamentos ms impor-
tantes que otros (generalmente al que nosotros pertenecemos), cuando la
realidad es que todos los departamentos dentro de la empresa son impor-
tantes; los de ventas, suelen pensar que son ellos la pieza fundamental que
sostiene la empresa, pero si otros departamentos no fabrican, distribuyen y
prestan servicio a los clientes, el castillo se desmoronar y los clientes no
recibirn el valor esperado de la funcin de ventas. Suele ocurrir que estos
departamentos que se consideran insustituibles, son los que ms pegas
ponen a la implementacin de la gestin por procesos y generalmente aqu
radica el principal problema para llevar a delante las iniciativas de BPM: las
personas y su actitud ante el cambio, por lo que al igual que para conseguir
muchas de las innovaciones en las empresas, en ocasiones no nos quedarn
ms remedio que seguir las estrategias del palo o de la zanahoria para re-
compensar la adaptacin al cambio.
Las organizaciones funcionales presentan ventajas respecto a las orien-

tadas a procesos como la concentracin del saber hacer, la mxima eficien-
cia y los menores costes dentro de cada departamento. Sin embargo, como
comentaba Rummler de forma muy visual, en este tipo de organizaciones
funcionales y ms concretamente en sus organigramas, vea el flujo de in-
formes y responsables, pero no vea al cliente en esos organigramas, ni el
161
flujo necesario entre los distintos departamentos que componen la empre-

sa para proveer de valor a ese cliente. Adems y como ya hemos visto, los
sistemas informticos dentro de estas estructuras funcionales, generalmen-
te proveen de soluciones para estos departamentos, muchas veces sin inte-
gracin o comunicacin con otros departamentos, lo que complica e inter-
fiere todava ms con el cliente.
La realidad es que para ejecutar un proceso de negocio (por ejemplo

vender un producto), la informacin asociada a esa transaccin atraviesa
distintos departamentos y sistemas informticos de forma horizontal, y al
estar cada departamento centrado en sus propias tareas, no existe visibili-
dad para todo el proceso desde el inicio del proceso hasta su fin. Dicho de
otra manera, el proceso se encuentra fragmentado y requiere del inter-
cambio de informacin entre los sistemas aislados. Esta situacin se agrava
an ms con el crecimiento en el nmero de interfaces con clientes (mail,
web, redes sociales, telfono, sms, etc.), el aumento de los aplicativos es-
pecializados en funciones concretas de la empresa y el nmero de interme-
diarios con los que colaboran las empresas.
El mercado actual, caracterizado por altos niveles de exigencia de los

clientes en cuanto a niveles de servicio, tiempos de entrega y calidad, con-
vierten al cliente no ya en el rey, sino en un tirano (esto es lo que quiero y
lo quiero ahora), los clientes chocan constantemente con los silos de in-
formacin departamentales de las empresas funcionales, provocando du-
162
plicados de informacin, incoherencias e ineficiencias, debido a la rotura de

los procesos y de la cadena de valor interna de la empresa. Todos los depar-
tamentos tienen alguna parte del proceso, pero ninguno lo tiene o contem-
pla en su totalidad, pues el proceso original ha sido fraccionado dentro de
la propia estructura departamental. En esta situacin, los silos slo son
buenos para almacenar grano, pero no para mantener una arquitectura
organizacional competitiva y orientada a procesos y clientes.
Ante la realidad de unos procesos que atraviesan la organizacin, surge

la gestin por procesos y BPM como disciplina para tomar esta perspectiva
proceso-cntrica, orientada al cliente y a la satisfaccin del mismo. La visin
de procesos resulta sumamente poderosa al proporcionar una perspectiva
acorde con la lgica con la que realizamos el negocio y satisfacemos a nues-
tros clientes, hacindonos cargo de la totalidad del proceso de principio a
fin, en contraste con el modelo funcional, en el que nadie tena la respon-
sabilidad de todo el proceso y que ms bien, si algo fallase, nos dedicara-
mos a buscar un departamento culpable del fallo, cuando la realidad es que
la gran mayora de los fallos se producen por no considerar los procesos en
su totalidad.
Los procesos que utilizaremos en nuestros proyectos de BPM atravesa-

rn generalmente las unidades departamentales de la organizacin en
cuanto a tareas, funciones, personas y sistemas de informacin involucra-
dos, proveyendo en todo el proceso no slo de la visin estratgica, organi-
zativa y cultural necesarias para afrontar este reto, sino tambin de las tc-
nicas, herramientas y metodologas para disear, modelar, medir, monitori-
zar y controlar estos procesos. La orientacin a procesos y ms concreta-
mente BPM y su idea principal de que una organizacin es la suma de todos
sus procesos de negocio, significaran un cambio de paradigma en la forma
de pensar las organizaciones e implicarn un cambio estructural para rein-
ventar la forma en que llevamos a cabo los procesos de negocio y es la ra-
zn por la que empresas como GE, Google, Virgin, Toyota, Dell, eBay, Ama-
zon, Samsung y muchas otras han llevada adelante este cambio.
El planteamiento de esta visin de procesos no es tan radical como pue-

da parecer en un principio y ambos planteamientos, el funcional y el de
procesos, pueden ser complementarios y de hecho lo son en la mayora de
implementaciones de BPM, en las que mantenemos la estructura departa-
mental de la empresa, pero reorganizando las estructuras y los recursos,
para que estos adopten un compromiso con la totalidad del proceso de
inicio a fin bajo la consideracin de que el proceso en su conjunto es ms
163
importante que sus partes por separado. En estos proyectos, ser impor-
tante asignar un responsable del proceso completo y transmitir el compro-
miso y la necesidad de esta visin a todo el equipo involucrado, de forma
que todos remen en la misma direccin de empujar el proceso para produ-
cir una salida que sea lo ms eficiente posible y aporte el mayor valor al
cliente.
Como vemos en el grfico anterior, la gestin de procesos de negocio se

origina con el cliente, atravesando distintos departamentos funcionales
dentro de la compaa y finalmente regresando de nuevo al cliente. En este
viaje, el proceso completo atraviesa no slo los departamentos de la em-
presa, sino tambin los sistemas y aplicaciones existentes en estos depar-
tamentos. Al igual que en los proyectos de BPM comentbamos la no nece-
sitaremos eliminar toda la estructura de la empresa para su implementa-
cin, BPM tampoco elimina las aplicaciones informticas asociadas a cada
departamento, sino que las integra. En este sentido, BPM adems de mane-
jar el flujo del proceso y actividades, las personas involucradas y la monito-
rizacin del proceso, acta tambin como un Middleware o EAI de aplicati-
vos y sistemas informticos, proveyendo de una capa de proceso, la cual
integra aplicaciones independientes que necesitan ser ejecutadas dentro
del proceso o de las cuales podemos precisar datos y consultas. La evolu-
cin que haremos con BPM en cuanto a la integracin de sistemas, es pasar
de un modelo de datos a un modelo en el que los datos se encuentran inte-
grados y consolidados entorno a los procesos.
Para ilustrar la orientacin a procesos, podemos usar como ejemplo el

proceso de Alta de un nuevo empelado en una empresa y los posibles cana-
les de interconexin que tiene este proceso:
164
En este caso, podemos replicar el problema de los NxN canales de co-

municacin que vimos al hablar de los sistemas Middleware, pero aplicado
ahora a un proceso que atraviesa varios departamentos de una organiza-
cin como es este caso de Alta de un nuevo empelado.
Para el desarrollo del proceso y la integracin de sus sistemas, podemos

organizar las tareas de cada departamento con las correspondientes conec-
tividades entre ellos, lo que resultara en una tarea enorme, o podemos
ordenar nuestra organizacin desde la perspectiva de procesos, simplifi-
cando y ganando con ello muchas ventajas, para lo cual aadiremos una
capa de procesos, encargada de esta integracin de datos, tareas y aplica-
ciones, donde en lugar de definir y establecer todas las interrelaciones en-
tre departamentos y sistemas, lo organizamos entorno a procesos.
Las organizaciones de tipo funcional resultaron altamente eficaces para

abordar las operaciones especializadas en empresas manufactureras, indus-
165
triales y de produccin en masa, pero han chocado con la visin de una

organizacin orientada a procesos, que requiere de la cooperacin entre
todos los departamentos de la empresa y de una cultura distinta, ms
abierta, participativa y menos jerrquica y donde el foco se encuentre en
ofrecer resultados a los clientes.
El cambio hacia la orientacin a procesos implicar un cambio cultural y

en la forma de pensar y trabajar y que frecuentemente resultar en una
nueva estructura organizacional. Esta visin, implicar romper con la visin
atmica y departamental de empleados y unidades ad hoc, especializadas
slo en determinadas tareas puntuales, con poca e ineficiente comunica-
cin entre departamentos y que han conducido a la poca eficiencia global
de la empresa y de sus procesos as como a trabajadores ms ocupados de
defender sus privilegios que del resultado global de los procesos de negocio
que ejecuta la empresa. En este recorrido hacia la organizacin orientada a
procesos, al principio se opt por escoger determinados procesos, gene-
ralmente de produccin o manufactureros, para analizar y mejorar estos
procesos individuales, pero todava no se pensaba en la empresa como
sistema integral de procesos y es esta ltima aproximacin, la que veremos
en los siguientes apartados a travs del pensamiento sistmico primero y
las teoras de Peter Fingar despus.
El Pensamiento Sistmico.
Enlazando con muchos de los conceptos vistos de la organizacin orien-
tada a procesos, el System Thinking o Pensamiento Sistmico, es una visin
tambin centrada en el todo y no en las partes que conforman un sistema.
Es de nuevo la visin holstica como herramienta para alcanzar resultados
que sumen ms que las partes que los componen, mediante el anlisis a
partir de los lmites de los componentes, la organizacin de estos y en el
estudio de las conexiones de unas partes con otras.
El pensamiento sistmico surgi tras la segunda guerra mundial, como

un anhelo por mejorar la condicin humana ante la complejidad de los pro-
blemas que la humanidad afrontaba tras la devastadora II Guerra Mundial.
Su origen se encuentra en el campo de los sistemas dinmicos, estudiados
por Jay Forrester en 1956, quien alegaba la necesidad de estudiar los siste-
mas sociales como sistemas de ingeniera, de forma que pudisemos en-
166
tenderlos para poder mejorarlos. Esta nueva forma de pensar pretenda

unificar las ciencias bajo un modo de pensar holstico que permitiera com-
prender el mundo como una totalidad armnica.
W. Edward Deming, el padre de la calidad, ya puntualiz hace muchos

aos que: el problema es el sistema. Al igual que en un coche no se mue-
ven cada una de sus partes por separado, sino que se mueve el coche en su
conjunto por la interrelacin entre sus diferentes partes (carrocera, motor,
sistema elctrico, etc.), los procesos de negocio que atraviesan horizontal-
mente una organizacin son tambin sistemas dinmicos, pero las personas
que dirigen y ejecutan los procesos en estas organizaciones, no estamos
preparados para comprender este pensamiento sistmico. El objetivo del
pensamiento sistmico es resolver la complejidad y aplicado a la gestin de
empresas, resolver la complejidad debida a un entorno de mercado cada
vez ms complejo. La relacin de este pensamiento con BPM viene de la
necesidad de dominar este tipo de pensamiento para poder construir orga-
nizaciones gestionadas por procesos, obtener una comprensin ms pro-
funda de los sucesos y sus relaciones y poder de esta manera influir o inter-
actuar con ellos.
Una de las principales diferencias entre el pensamiento tradicional y el

sistmico es que el tradicional usa una visin lineal, mientras que el sistmi-
co hace uso de una visin circular para ayudarnos a establecer las relacio-
nes entre las partes.
167
El pensamiento sistmico es distinto del tradicional en la medida en que

no estudia las partes separadas que componen un sistema sino que se cen-
tra en las interacciones entre las partes del sistema. En lugar de aislar y
reducir a piezas cada vez ms pequeas las distintas partes del sistema para
poder entenderlo, se centra en las interacciones entre las partes. Este foco
en las interacciones entre las partes, viene de reconocer la importancia de
estas interrelaciones para el comportamiento del sistema en su conjunto, a
sabiendas de que del estudio de las partes de forma aislada, no podemos
extraer informacin relevante para comprender el sistema en su conjunto.
La vida misma encuentra muchas veces su entendimiento y explicacin
cuando es vista desde la perspectiva del intercambio de materia, energa e
informacin entre las partes que la forman. Traducido a un entorno empre-
sarial, conscientes de que las empresas no pueden existir aisladamente ni
son sistemas cerrados, su comprensin slo toma sentido cuando analiza-
mos cmo interactan sus partes componentes, con otras empresas, con la
competencia y con los mercados.
El pensamiento tradicional basado en la lgica del anlisis, la descompo-

sicin y sntesis de las distintas partes de un sistema en partes cada vez ms
pequeas y que ha marcado el pensamiento analtico y cientfico, ha fun-
cionado en la mayora de situaciones en que lo hemos empleado, cuando
trabajamos con procesos o sistemas lineales y con secuencias simples de
causa y efecto. Sin embargo, cuando trabajamos con personas o con siste-
mas dinmicos, donde las variables del sistema se influyen mutuamente,
estos anlisis no son tan fciles de realizar o de reducir a expresiones ma-
temticas exactas. Estos sistemas pueden ser comparados con un puzle, en
el que todas las piezas encajan de una nica forma posible, lo que facilita su
composicin, pero en los que si introducimos en alguna pieza la posibilidad
de poder combinarse con ms de una sola pieza (lo convertimos en un sis-
tema dinmico), aumentamos exponencialmente el nmero de soluciones
posibles, pasando este a una complejidad dinmica, donde las soluciones
analticas tradicionales ya no nos sirven para explicar y encontrar soluciones
rpidas y efectivas a esta complejidad.
El pensamiento sistmico nos ofrece una nueva visin de las cosas, o por
lo menos nos recuerda la posibilidad de hacerlo, de abordar nuevas pers-
pectivas para la comprensin de los sistemas y resolver los problemas. Mu-
chas veces se compara con la visin de que dispone un astronauta de la
tierra desde el espacio, o las distintas visiones que podemos tener de un
sistema si ascendemos en helicptero a distintas alturas para observar el
168
mismo, donde a cada nueva altura que alcancemos, tendremos una visin
distinta del problema pues cada vez involucraremos a un entorno mayor.
Puesto que como sistema puede ser visto prcticamente cualquier cosa,
esta visin sistmica a veces traspasa los lmites de la matemtica y del
comportamiento de sistemas dinmicos para ser llevada a numerosos esce-
narios, algunos familiares para el lector como el concepto de Gaia (el plane-
ta Tierra visto como un sistema biolgico) o a visiones ms msticas y filos-
ficas, como ampliar esta visin al Cosmos, las relaciones de pareja, la psico-
loga, la salud, la economa, la ecologa, la naturaleza, etc. bajo la premisa
de que todo est conectado.
Entender la complejidad del mundo que nos rodea es un primer paso

para poder cambiar el mismo y el pensamiento sistmico afronta de forma
decidida esta complejidad a travs de una perspectiva novedosa y una serie
de tcnicas y herramientas tericamente fundamentadas, para afrontar los
problemas que nos rodean. Para entender un poco ms esta teora citamos
a continuacin algunas ideas y principios surgidos del mismo:
- Todo sistema se basa en la interaccin entre sus partes y esta

propiedad es ms determinante que la cantidad de partes que
lo compongan y su tamao.
- Lo obvio, a veces no es tan obvio, ni los criterios mayoritarios
son siempre los ms acertados.
- Para poder influir sobre el sistema, debemos conocer su estruc-
tura, lo cual pasa por comprender la complejidad de los proce-
sos que lo conforman.
- Causa y efecto no siempre estn relacionados en el tiempo y en
el espacio, por lo que no podemos actuar como si as fuese,
tendiendo relaciones lineales de causa y efecto y pasando por
alto otras muchas interacciones.
- Con la descomposicin de un sistema en sus partes esenciales
no siempre podremos comprender ni predecir su comporta-
miento.
- Un sistema no puede crecer indefinidamente sin ajustar el
mismo en su funcionamiento. Lo que funciona bien en una
magnitud, no siempre funciona bien aumentando esa magnitud
y un mayor tamao no implica un mejor funcionamiento. Los
sistemas tienen su tamao ptimo.
169
- Nos es difcil determinar las consecuencias de nuestras acciones

si estas no se visualizan a corto plazo, lo cual nos crea proble-
mas a largo plazo.
- De igual manera, el no tener una visin global, la tendencia a
estructurar y simplificar, nos causa problemas en otras reas de
la empresa que no hemos predicho.
- Las propiedades emergentes son intrnsecas a todo sistema
complejo y pueden afectar al sistema en distintos sentidos.
- Considerar siempre los distintos puntos de vista es fundamental
para comprender los sistemas.
- Cuantas ms partes e interconexiones tenga un sistema ms es-
table ser el mismo.
- Cuantas ms conexiones entre sistemas tengamos, ms esta-
bles y redundantes sern los mismos.
- Los sistemas mantienen su estabilidad en base al feedback que
obtienen de su entorno.
- Influenciamos y somos influenciados por los sistemas de los que
formamos parte.
El tener en cuenta esta visin del pensamiento sistmico nos ayudar a

disponer de nuevas perspectivas a la hora de analizar y pensar tanto nues-
tras organizaciones como sus procesos de negocio y puede que de esta
visin salgan nuevas soluciones a los entornos econmicos y empresariales
que nos rodean. Como deca Albert Einstein no podemos hacer siempre lo
mismo y esperar resultados diferentes.
Peter Fingar y la empresa como sistema.
Antes vimos como BPM puede ayudar a eliminar el Gap entre negocio y
TI en lo que Peter Fingar y Howard Smith denominaban eliminar el puente
que los divide. As mismo vimos como algunos autores recomendaban in-
cluso el apartar a los programadores y personal de TI de las fases de diseo
y anlisis de procesos de negocio, afirmacin esta que seguramente haya
enervado a ms de un lector e inducirle a abandonar la lectura de este li-
bro. Sin embargo, en un artculo posterior de Peter Fingar en BPTrends titu-
lado The Core Competency for BPM, Fingar ahondaba en la necesidad de
una visin de la empresa como sistema y sealaba a los programadores y
profesionales de TI como los principales poseedores de esta visin a la hora
de pensar en sistemas globales de la empresa, pues consideraba que los
170
perfiles de personal de otros departamentos como el de marketing, legal o

financiero, se encuentran limitados a tareas especficas de la empresa y no
preparados en consecuencia para este tipo de pensamiento global y sist-
mico.
Para Peter Fingar, los trabajadores de hoy en da continan la senda Tay-

lorista de la especializacin en el trabajo, viendo slo partes de la empresa,
privados de la visin global de negocio y de los resultados de sus acciones
individuales, por lo que Fingar reclamaba para ellos una perspectiva de
astronauta (los cuales pueden ver toda la tierra), de forma que conozcan los
efectos de su trabajo y dispongan de una visin de los procesos de principio
a fin y del modelo de negocio del cual forman parte.
Fingar llamaba en este artculo a abrazar el Pensamiento Sistmico (Sys-

tem Thinking), como medio para manejar la complejidad tecnolgica y de
los negocios para entender el entorno en el que nos movemos a travs del
estudio de las interconexiones e interrelaciones entre las partes. Fingar
abogaba por BPM, como el conjunto de herramientas que permitirn im-
plementar esta visin: descubrir las mltiples interrelaciones entre las par-
tes y sistemas de la empresa y comprender las variables que afectan a los
procesos de negocio y los efectos a largo plazo de los mismos, mediante la
poderosa herramienta de simulacin de procesos en BPM, que nos permiti-
r descubrir errores y posibles implicaciones en los procesos antes de su
ejecucin en el mundo real. Para Fingar, no podemos tratar ms a los pro-
cesos y actividades de negocio dinmicos como repositorios de datos y al-
goritmos de clculo, coincidiendo con otro autor de BPM, Martyn Ould,
quien afirmaba que nos movemos de la Era de la Informacin a la Era de los
Procesos, del procesamiento de informacin al procesamiento de procesos,
donde el objetivo es el negocio y no el manejo de datos e informacin.
La empresa gestionada por procesos no es una nueva Killer application

y requiere de una nueva visin de los sistemas de informacin y de los de-
partamentos de informtica y su papel en la empresa. Los analistas y pro-
gramadores software no pueden hablar de negocios en trminos de dia-
gramas entidad-relacin, diagramas de clases o UML. A pesar de ser el per-
sonal informtico los mejor adaptados para disponer de esa visin global de
la empresa, necesitan explotar esa capacidad y complementarla con la vi-
sin de negocio, de forma que puedan alcanzar nuevos niveles de abstrac-
cin y abandonar la visin exclusiva de la empresa como un sistema de in-
formacin. Al igual que el resto de los trabajadores, el personal y departa-
mentos de TI, deben abordar el pensamiento sistmico, en el que todo est
171
conectado con todo y reconocer que forman parte de un sistema mayor, en

el que su trabajo slo tiene sentido al verse en conjunto y no de manera
individualizada.
Ahora que hemos introducido qu es BPM as como las bases metodol-

gicas y de pensamiento sobre las que basar nuestros proyectos, podemos
pasar a disear y modelar las organizaciones y los procesos que darn co-
bertura a la implementacin de esta visin, y que formarn el contenido de
los siguientes dos captulos.
172
Captulo 5. Modelado de Negocios
Captulo 5. Modelado de Negocios.
Normalmente nos encontramos con problemas y situaciones complejas

que escapan a nuestra comprensin o capacidad de entender y resolver los
mismos y es por ello que construimos modelos simplificados que nos per-
mitan estudiar estos problemas y realizar simulaciones. El modelado y simu-
lacin suelen ser operaciones seguidas en un ciclo iterativo: desarrollamos
el modelo, lo simulamos, aprendemos de su comportamiento y refinamos
el modelo en funcin de lo que hayamos aprendido, volviendo a desarrollar
el modelo y repitiendo este ciclo tantas veces como sea necesario, hasta
llegar a un nivel de entendimiento y comportamiento del modelo que con-
sideramos adecuado. La realizacin de este ciclo ser todava ms til
cuando tratemos con sistemas dinmicos, debido a que la influencia del
tiempo en los mismos, dificultar poder predecir su comportamiento y
evolucin.
Los modelos de negocio, como los mapas, nos guiarn a nuestro desti-
no estratgico, nos mostrarn rutas alternativas y posibilidades, nos mar-
carn obligaciones y restricciones con las que tenemos que contar en nues-
tro camino y nos ayudarn a comunicar a nuestros compaeros de viaje el
recorrido que pretendemos realizar, para consensuar con ellos la ruta y los
motivos del viaje. Al igual que los turistas con los mapas, las organizaciones
usarn el modelado para entender, controlar y describir la complejidad as
como para poder planificar y tomar las decisiones ms acertadas en cada
momento.
173
El comenzar nuestro recorrido en BPM por el diseo y modelado de los

modelos y no directamente de los procesos de negocio, se fundamenta en
la realidad del entorno empresarial actual en el que las empresas pueden
ganar ms dinero diseando sus arquitecturas, sistemas empresariales y
modelos de negocio que diseando los procesos manufactureros y de pro-
duccin y que la base sobre la que deberemos disear nuestros distintos
procesos operativos, deber fundamentarse y ser fiel reflejo de este mode-
lo de negocio. Este es el caso de conocidas empresas como Apple, Nike y
muchas otras que gana ms dinero pensando que fabricando: Designed in
California; Assambled in China. En la visin de BPM, los gerentes de em-
presas, ms que ser responsables del diseo, produccin y venta de los
productos, sern diseadores de modelos de empresas y responsables de
crear y mantener estos modelos, sobre los cuales las empresas disean sus
productos, los producen y los venden, por lo que estos directivos debern
encargarse de que estos modelos y procesos se encuentren siempre perfec-
tamente optimizados, continuamente mejorados, coordinados, que todo el
personal sepa lo que tiene que hacer en cada momento y de que las tecno-
logas den el mayor soporte a estos modelos para aumentar la eficiencia de
los mismos.
Los modelos de negocio son la representacin de la realidad de una or-

ganizacin y son utilizados para entender cmo se organiza una empresa,
cmo interacta, que objetivos y estrategias persigue, cules son las tareas
y el trabajo que debe realizar para conseguir esos objetivos y como la em-
presa crear valor a sus clientes. BPM har uso de las herramientas de mo-
delado de negocios porque son una herramienta perfecta para analizar,
planificar y tomar decisiones sobre la estrategia, la tctica, los objetivos,
operaciones y actividades que realiza la empresa y como alinear estas me-
tas y objetivos empresariales con el diseo de los procesos que darn so-
porte a esta estrategia y la tecnologa que a su vez dar soporte a los proce-
sos.
A travs de los modelos que realicemos, podremos comprender como

operamos y se desarrollan nuestros procesos y modelos de negocio y me-
diante la transformacin de estos modelos, podremos identificar oportuni-
dades y mejoras sobre estos procesos en trminos de eficiencia, rendimien-
to y adaptacin al cambio. El modelado de negocio nos resultar adems
una herramienta muy valiosa en nuestros proyectos de BPM para comuni-
car a otros miembros de la organizacin, otras empresas, clientes y partners
con los que interactuemos, acerca de lo que pretendemos con el proyecto y
buscar el consenso con estos actores para la ejecucin del modelo.
174
Los modelos de negocio representan de forma grfica o verbal uno o

ms aspectos de una empresa como:
- Su propsito.
- Estructura.
- Funcionalidad.
- Dinmica.
- Lgica de negocio.
- Componentes: fines, procesos, reglas de negocio, actores, etc.
En este captulo nos adentraremos en los modelos de negocio y en espe-

cial en los frameworks y modelos de referencia utilizados por diferentes
sectores industriales para planificar, definir y disear los distintos elemen-
tos que necesitaremos para alinear nuestra estrategia con los procesos y la
tecnologa.
Al contar BPM con una notacin especfica para modelar procesos como
es BPMN y al disponer en las plataformas software de BPM de herramien-
tas visuales de modelado de procesos para esta notacin, muchos usuarios
tiene como primer impulso el ir directamente a esta herramienta de mode-
lado, sin embargo, debemos advertir que modelar un proceso de negocio
no es algo sencillo, requiere de habilidades y conocimientos no slo tcni-
cos y de la notacin BPMN, sino tambin de lo que est por encima de estos
procesos y que constituye la razn final de por qu trabajamos en ellos y
que marcarn el camino a seguir por los procesos de forma que estos sean
un fiel reflejo de lo que queremos alcanzar. Este espacio previo al diseo de
procesos se refiere al cmo se conforman las estrategias y arquitecturas
empresariales, la cadena de valor, las tecnologas y su relacin con los pro-
cesos que opera la empresa y ser el contenido nico de este captulo.
Valor y Ventaja competitiva.

El actual entorno econmico, altamente dinmico, competitivo y turbu-
lento nos obliga a cambios y transformaciones constantes para poder adap-
tarnos a los requerimientos de los nuevos y viejos clientes (pues estos tam-
bin cambian). Ningn negocio va a tener xito haciendo las cosas de forma
estndar. Necesitamos buscar ventajas competitivas que nos diferencien
respecto a la competencia y dems productos y servicios del mercado y en
esta bsqueda, el Valor que aportemos a nuestros clientes por esos pro-
175
ductos y servicios y que constituir la razn ltima por la que nos paguen
nuestros clientes, resultar importantsima para poder sobrevivir y tener
xito en este entorno.
Hoy no existe tolerancia con el error y la ineficiencia, ya no nos vale con

hacer las cosas bien o hacer ms de lo mismo bajo la premisa de que esto
siempre nos ha funcionado. Las empresas deben ahora hacer ms con me-
nos e incrementar el valor aportado a los clientes, a los empleados (para
poder retener el talento), a los accionistas, y a la sociedad en general. Ya no
nos basta con ser slo el ms barato o el que ms calidad aporta, como si
de por s, esto fuese sencillo, ahora, adems de precio y calidad, debemos
ofrecer a nuestros clientes la mejor de las experiencias en cuanto a calidad
de servicio, tiempos de entrega y servicio post venta.
Para poder competir en este entorno, es preciso realizar importantes

cambios, repensar y redisear la forma de trabajar, de forma que esta sea
lo ms inteligente y eficiente posible. La cada de la demanda y los requisi-
tos para hacer frente a periodos de decrecimiento y falta de financiacin,
requiere de personas y organizaciones ms orientadas a resultados, capaces
de adaptar y modificar sus procesos de negocio o incluso reinventarlos
completamente, en funcin del entorno en el que operan en cada momen-
to. Es necesaria una mirada innovadora sobre los procesos de negocio, ase-
gurndonos de que estos aporten valor y el pensar constantemente en
nuevos modelos de negocio, mercados y oportunidades. Ser capaces de con
los recursos que tenemos, gestionar los nuevos proyectos, cambios e inicia-
tivas que nos planteamos de una forma correcta y eficiente, centrndonos
en lo que realmente importa y no en pretender ser ms grandes, con ms
empleados o mayor facturacin, sino centrarnos en aquello que aporte
valor al cliente, que es por lo que obtenemos finalmente un beneficio como
empresa.
A lo largo de la historia, han existido diferentes formas de aportar valor

a los clientes, pero hoy en da, existe un mecanismo importantsimo para
poder aportar valor y es el disponer de una ventaja competitiva, es decir,
que para poder tener xito, nuestra empresa debe hacer algo mejor que
otras empresas, pudiendo encontrarse esta ventaja en la orientacin al
cliente, en la mayor calidad de sus productos, en precios de venta ms ba-
ratos o en una posicin de monopolio en el mercado.
Sobre qu podemos hacer mejor que otros, debemos recordar a Tracey

y Weisman (1997) cuando decan que una empresa, para poder ser compe-
176
titiva debe escoger de entre alguno de estos aspectos, aquellos que le per-
mitan ser mejor que ninguna otra:
- Cercana al cliente. Liderazgo en clientes: con altos grados de

calidad y servicio hacia los clientes y su satisfaccin.
- Excelencia operacional. Liderazgo en Costes. Alta eficiencia y
mejora continua y en consecuencia, menores costes de produc-
cin de los productos y servicios ofrecidos a los clientes.
- Liderazgo en producto. Tener el mejor producto, con mejores
caractersticas e innovaciones que los de la competencia.
Pero segn estos mismos autores, no es posible ser buenos en las tres
estrategias al mismo tiempo. Debemos escoger el liderazgo en alguna de
ellas, pues de otra forma, segn Michael Porter, nos estrellaremos irreme-
diablemente. Adems de esta eleccin entre alguna de estas fuentes de
ventaja competitiva, debemos tener en cuenta que debido a la presin de
los mercados y la competencia, muchas de las antiguamente consideradas
ventajas competitivas, son consideradas hoy en da por los clientes como
algo que se debe dar obligatoriamente, por lo que la nica solucin que nos
queda es la rapidez con que seamos capaces de encontrar y adaptarnos
constantemente a nuevas ventajas competitivas diferenciadoras, haciendo
uso de la capacidad creativa y de gestin de la innovacin de la que dispon-
ga nuestra empresa.
En los proyectos de BPM que emprendamos, la propuesta de valor del

proyecto nos asegurar que el beneficio de la implementacin de un proce-
so este alineado con los objetivos de negocio, que los procesos aporten
valor a nuestros clientes y stakeholders (personas que de alguna u otra
forma puedan verse afectadas por el funcionamiento del proceso), en tr-
minos de aumento de ingresos, reduccin de costes, mayor grado de inno-
vacin en la organizacin, fidelizacin y satisfaccin de clientes. Los proce-
sos en s mismos, pueden ser considerados como cadenas de aportacin de
valor, en el sentido de que en la secuencia de tareas de nuestro proceso,
dirigidas a obtener un producto o servicio de valor para nuestros clientes,
cada uno de estos pasos o tareas debe aadir valor al paso precedente. Si
no conseguimos aportar valor a travs de los procesos que implementamos,
no habremos conseguido los objetivos del proceso, por lo que ser obliga-
cin del equipo de proyecto y de sus promotores, asegurar y comprobar
que estos cumplan con la propuesta de valor especificada en el modelo de
negocio y la estrategia.
177
La Cadena de Valor.
Segn Michael Porter (1985), la ventaja competitiva de una empresa ra-

dica en las muchas actividades que esta desarrolla en el diseo, produccin,
marketing y venta de sus productos, donde cada una de estas actividades
puede crear la base para la diferenciacin. Segn Porter, para analizar las
fuentes de ventaja competitiva, es necesario examinar todas estas activida-
des y cmo interactan entre ellas, disgregando la empresa de sus activida-
des estratgicas para comprender los orgenes de esta diferenciacin. Para
la realizacin de este anlisis de las fuentes de ventaja competitiva, Porter
introduce el concepto de Cadena de Valor, como el conjunto de actividades
que realiza la empresa para disear, producir, llevar al mercado, entregar y
apoyar sus productos. Las Cadenas de Valor, segn Porter, son la forma en
que la empresa desempea sus actividades individuales, son un reflejo de
su historia, de su estrategia, de su enfoque para implementar la estrategia y
las economas fundamentales para las actividades de la misma.
Segn Porter, quien proporciona la ventaja competitiva son los procesos

que ejecuta la empresa y es por ello que estas buscan siempre nuevas for-
mas de realizar sus procesos mejor que sus rivales. La clave del xito para
alcanzar ventajas competitivas en una empresa, radica en escoger bien su
estrategia y centrase en ella, no desviando su atencin hacia otras estrate-
gias, de forma que en la estrategia que escoja, optimice sus procesos y sea
lder en la estrategia escogida, diseando su propia cadena de valor y unos
procesos que sean nicos y difciles de replicar por otras empresas, de for-
ma que as, esta pueda mantener sus ventajas competitivas en el tiempo.
Sobre la eleccin de la estrategia y los procesos que la soportarn, po-

demos recordar la pregunta que le hicieron a Ricardo Reti, un gran maestro
de ajedrez, sobre cuantas jugadas poda calcular de una vez en el tablero, a
lo que este respondi: Ninguna. Con esta respuesta, Reti se refera a que
la eficacia del ajedrez no reside en calcular variantes de muchsimos movi-
mientos posibles, que por supuesto ha de saber realizar, sino centrarse en
las que realmente tienen importancia y vale la pena analizar, pues son estas
de las que podr extraer valor y ventajas en la partida. Lo que los grandes
maestros del ajedrez hacen es elegir una estrategia cribando las ramas y
posibilidades estriles y en las que no vale la pena ahondar. En esta capaci-
dad de saber identificar las variantes ganadoras, radica la diferencia entre
los grandes jugadores y los aficionados. Los aficionados, no tienen la capa-
cidad o el arte de poder seleccionar qu lneas son las ms interesantes,
178
con mayores posibilidades de xito y en las que vale la pena profundizar en

su anlisis, por lo que al no hacer esta criba o seleccin inteligente de las
ramas o variantes, no les quedar otro remedio que hacer uso de la fuerza
bruta de la capacidad de clculo de nuestro cerebro o de los ordenadores
para calcular todas las posible jugadas y valorar las ventajas y desventajas
de cada una de ellas. Este ha sido el caso de Blue Deep, el superordenador
de IBM que consigui vencer a Kasparov a fuerza del podero de clculo de
sus procesadores. En el anlisis de nuestros procesos, podremos hacer uso
tambin de la fuerza bruta de nuestros ordenadores y herramientas de
anlisis matemtico, pero siguiendo la regla de Pareto, el 80% de lo que
observemos ser producido por el 20% de las fuentes, y es en este 20%
hacia el que deberemos dirigir no slo el anlisis matemtico y estadstico
sino tambin nuestras habilidades creativas y de intuicin que apliquemos a
los procesos.
La Cadena de Valor, es un modelo terico que permite describir las acti-

vidades de una organizacin para generar valor al cliente final y a la propia
empresa. Describiremos a continuacin la Cadena de Valor y los distintos
elementos que la forman para poder escoger y disear una buena estrate-
gia sobre la que basar nuestros procesos. La Cadena de Valor de una em-
presa se representa por una serie de funciones de negocio (gestin de
compras, recursos humanos, etc.), las cuales se pueden descomponer en
unidades funcionales ms pequeas. La Cadena de Valor se basa en la orga-
nizacin funcional de la empresa, donde las actividades estn organizadas
en funciones de negocio. Las funciones de negocio pueden ser divididas en
funciones primarias (que contribuyen directamente a alcanzar una ventaja
competitiva en la empresa) y funciones de soporte a estas funciones prima-
rias.
La cadena de Valor bsica est formada por:
- Actividades Primarias: son aquellas que tienen que ver con el

desarrollo del producto, su produccin, su venta, la logstica y
comercializacin as como los servicios de post-venta.
o Logstica Interna: almacenamiento, inventarios, recibos.
o Operaciones: actividades de transformacin.
o Logstica externa: actividades de recopilacin, almace-
namiento y distribucin fsica, procesamiento de pedi-
dos y entrega.
o Marketing y ventas: actividades para facilitar los medios
de compra.
179
o Servicio Postventa: actividades para realizar y mantener

valor.
- Actividades de Apoyo: que sustentan las actividades primarias y
se apoyan entre s, como las de recursos humanos, compras de
bienes, materias primas y servicios, el desarrollo tecnolgico,
etc.
o Aprovisionamiento: funcin de compras de abasteci-
mientos.
o Recursos Humanos: seleccin, contratacin, formacin
y desarrollo de personal.
o Tecnolgicos: procedimientos, equipamiento, I+D, etc.
o Infraestructura: que apoyan a la cadena completa: ad-
ministracin, finanzas, contabilidad, calidad, sistemas
de informacin, legal, etc.
Grficamente la Cadena de Valor se representa de la siguiente forma:
Infraestructura
Recursos Humanos
Tecnologa
Aprovisionamiento
MARGEN
Logstica de Logstica de Marketing y Servicio
Operaciones
Entreda Externa Ventas Psotventa
Este grfico de la Cadena de Valor nos muestra lo que ocurre en la em-

presa entre el momento en que recibimos un pedido de un cliente y el mo-
mento en que le entregamos ese producto. Todas las funciones que partici-
pan en la elaboracin de ese producto, tanto las funciones principales como
las de apoyo, conforman la cadena de valor y es esta cadena la que deter-
mina cuanto nos cuesta producir el producto y que margen obtenemos tras
su venta. En la cadena de valor, todas las actividades que la forman aaden
valor al producto final para conseguir la satisfaccin del cliente y de alguna
forma, a la pregunta de si el cliente conociese todos los pasos de esta ca-
dena de valor, estara de acuerdo en pagar por todos y cada uno de los pa-
180
sos incluidos en ella? Podramos quedarnos tranquilos, sabiendo que todas

ellas son necesarias y eficientes en su operativa y el cliente las aceptara
como necesarias para producir los productos y servicios que satisfagan sus
necesidades.
El sentido ltimo de esta visin de la cadena de valor de Porter es identi-

ficar actividades que no aportan valor y que deben ser eliminadas. Para
Porter, el recorrido que va del pedido del cliente a su entrega, es un proce-
so completo en el que la empresa debe centrarse y no debemos pensar esta
cadena como procesos separados que ocurren en distintos departamentos
de la empresa, pues este es un error que no optimiza la cadena de valor. En
la teora de Porter, una empresa es mucho ms que la suma de sus activi-
dades (otra vez la visin holstica), donde la cadena de valor es un sistema
de actividades interrelacionadas entre s (pensamiento sistmico) por lo
que adquirir una ventaja competitiva exige que la Cadena de Valor se ges-
tione como un sistema y no de forma separada.
En la teora de Porter, adems de la Cadena de Valor de una empresa,

tenemos que contemplar tambin las cadenas de otras empresas, pues las
empresas colaboran unas con otras en sistemas abiertos, en la que cada
una intenta alcanzar sus objetivos y en consecuencia, sus Cadenas de Valor
tambin estn interrelacionadas. A este ecosistema de Cadenas de Valor
interrelacionadas lo denominamos Sistema de Valor y estar formado por
Cadenas de Valor interrelacionadas, cada una de las cuales est asociada
con una empresa.
Este Sistema de Valor, considera que la empresa est envuelta en un

conjunto de actividades realizadas por un gran nmero de actores diferen-
tes: proveedores que tienen sus propias Cadenas de Valor y crean y entre-
gan insumos en nuestra Cadena de Valor, diferentes canales de distribucin
en su camino hacia el cliente, a travs de los que entregamos los productos
y que generalmente afectan a estos clientes y a sus propias cadenas cuando
el producto pasa a formar parte de este, etc. y en donde todos ellos con-
formarn el denominado Sistema de Valor.
Desde el punto de vista del sistema de valor, podemos tener:

181
- Cadena de valor de los proveedores: crean y aportan los abas-

tecimientos o insumos que nuestra empresa necesita. El costo y
la calidad de estos abastecimientos influyen en los costos y la
calidad de nuestra cadena de valor y en consecuencia en su ca-
pacidad para adquirir ventajas competitivas.
- Cadenas de valor de los canales: a travs de los cuales entre-
gamos los productos a nuestros clientes y cuyos costos y mr-
genes de distribucin, forman parte del precio que pagar fi-
nalmente el cliente y afectarn por tanto a la satisfaccin de es-
te.
- Cadenas de valor de compradores: son la fuente de diferencia-
cin por excelencia, puesto que en ellas la funcin del producto
determinar las necesidades del cliente.
Los pasos generales a seguir para la construccin de la cadena de valor

son los siguientes:
1. Disear la cadena de valor: capturando todo lo que se realice dentro

de la empresa. Dividiendo y aislando las actividades, atendiendo a
las que tengan economas diferentes, tengan un alto potencial de di-
ferenciacin o aquellas que tengan un alto impacto en el costo.
2. Analizar las conexiones: puesto que la cadena de valor no est for-
mada por actividades independientes, sino que estas son interde-
pendientes, analizaremos las conexiones y relaciones entre ellas,
buscando las ventajas competitivas en la optimizacin y coordina-
cin de las distintas actividades y que nos puede conducir a la elimi-
nacin de actividades innecesarias.
3. Realizar benchmarking con nuestros competidores.
4. Evaluar el sistema de valor en su conjunto y las conexiones de nues-
tra cadena de valor con las de proveedores y canal, pues en este
anlisis pueden aparecer oportunidades de mejora, reduccin de
costes y diferenciacin para aumentar nuestra ventaja competitiva
coordinando y optimizando sus interrelaciones.
5. Analizar la cadena de valor del cliente, pues la diferenciacin y crea-
cin del valor de una empresa estar en como esta se relacione con
la cadena de valor del cliente.
El diseo de nuestra cadena y sistema de valor nos resultar de gran uti-

lidad a la hora de definir los procesos de nuestra empresa cuando iniciemos
un proyecto de BPM y nos facilitar la tarea de entender las relaciones en-
tre las distintas actividades internas y externas de la empresa y como estas
182
estn conectadas con otros recursos y actividades. En especial, este anlisis

de la Cadena de Valor ser ms til cuando la informacin se encuentra
distribuida en diferentes hojas de clculo, documentos, personas y siste-
mas, en diferentes herramientas y metodologas y atravesando diferentes
unidades de negocio y silos de informacin, ya que requerir de una visin
holstica e integrada de toda esta informacin para poder priorizar y selec-
cionar las reas y actividades con mayor potencial de agregacin de valor,
diferenciacin y ventajas competitivas.
Niveles de detalle en los Procesos de Negocio.
Los buenos modelos de procesos deben disponer de diferentes vistas, de

forma que al comunicar los mismos al resto de la organizacin, podamos
mostrar diferentes niveles de detalle. No es lo mismo mostrar a un operario
de los niveles ms bajos de la organizacin el nivel ms alto, con la estrate-
gia de posicionamiento en la Cadena de Valor sobre la cual poco podr
aportar para su mejora, que mostrar esta a un analista de negocio o ejecu-
tivo de la empresa, conocedor del da a da de cmo opera esa Cadena de
Valor. De igual manera, mostrar detalles operacionales sobre las tareas de
una determinada actividad desarrollada por un operario, no tendr inters
ni aportar conocimiento si se la mostramos para su opinin a un directivo
de la empresa, por lo que dependiendo de nuestro puesto en la organiza-
cin, visualizaremos mejor unos niveles u otros.
A la hora de modelar los procesos de negocio, podemos hacerlo con di-

ferentes niveles de detalle, donde la suma de todos ellos, con su descom-
posicin, conformar el mapa de procesos.
- En el nivel estratgico definimos los procesos que son necesa-

rios, los procesos ms generales, la arquitectura y coordinacin
ente los mismos y con otros procesos.
- En el nivel tctico nos centramos en como disear y gestionar
los procesos, generalmente son procesos que se encuentran
dentro de un departamento o unidad de negocio.
- En el nivel operacional, vemos ya toda la complejidad y varia-
ciones de los procesos, detallamos las actividades a nivel de
personas o sistemas que debern realizar las actividades y que
sern el nivel ms detallado del modelado. En este punto pa-
samos de describir un proceso a describir las tareas finales que
deber realizar una persona o un software.
183
El anlisis de la Cadena de Valor es el proceso ms amplio del que po-

demos hablar en la empresa. Es un proceso de negocio de alto nivel que
realizamos a nivel estratgico:
Como hemos visto, la Cadena de Valor cubre todas las interacciones con
clientes desde que recibimos el pedido, nos proveemos de materiales, los
procesamos, los vendemos, hasta que cobramos y emitimos la factura, por
lo que incluye las principales actividades que producen valor a nuestros
clientes. La Cadena de Valor la ponemos a nivel estratgico porque en BPM
no podemos hacer nada sin que la direccin defina la estrategia y nos diga
que cosas queremos hacer.
A nivel tctico, decidimos como disear y gestionar los procesos as co-

mo la coordinacin entre los mismos. Aqu es donde se definen los proce-
sos, siguiendo la lgica de la cadena de valor: qu hacer, como lo hacemos,
quines son los responsables de hacerlo y como se comunican entre ellos.
De esta forma, determinamos los procesos de negocio que cubrirn todas
las actividades de principio a fin para generar valor a nuestros clientes y
definirn como hacemos el trabajo dentro de nuestra organizacin. En este
proceso, vamos desgranando la cadena de valor, definiendo los procesos de
negocio que descompondremos en procesos operacionales y sub-procesos
ms pequeos as como la coordinacin entre estos y que conjuntamente,
184
mostrarn la operativa de las diferentes reas de la empresa. Esta descom-

posicin llegar hasta el nivel de actividades o tareas, que sern los elemen-
tos ms pequeos que podamos describir. El resultado de esta descomposi-
cin conformar la arquitectura de procesos, como la mostrada en el si-
guiente grfico a partir de la descomposicin de la Cadena de Valor, donde
vemos la jerarqua de procesos y los tres niveles de detalle.
El proceso de descomposicin a partir de la cadena de valor para crear la

arquitectura de procesos sigue los siguientes pasos:
- Identificar una cadena de valor

- Determinar los objetivos estratgicos que pretende la cadena
de valor.
- Determinar cmo vamos a medir esos objetivos.
- Subdividir la cadena de valor en procesos.
- Determinar para cada proceso como lo mediremos, los recursos
necesarios para el mismo y dems detalles del proceso.
Aunque Porter no identifica en la tarea de descomposicin el papel de

los procesos, estos encajan perfectamente en la Cadena de Valor, siendo las
funciones de negocio que desarrolla la empresa en el contexto de un Siste-
185
ma de Valor, identificadas como procesos de negocio. BPM como disciplina

nos permitir gestionar esta Cadena de Valor, ganando en agilidad y adap-
tabilidad, al poder gestionar, monitorizar y controlar de forma continua la
Cadena de Valor en tiempo real.
El modelo de referencia para la gestin de la Cadena de Valor y donde

podremos encontrar estas cadenas aplicadas a distintos tipos de empresas
y sectores para la mejora de nuestra propia cadena de valor es el Value
Reference Model (VRM), en el que se describen Cadenas de Valor horizon-
tales con las interdependencias entre los distintos procesos: estratgicos,
tcticos, operacionales, actividades y tareas para distintos tipos de empre-
sas y sectores. En la pgina web del VRM (www.value-chain.org), podremos
encontrar valiosa informacin sobre distintas cadenas de valor y detalles de
cada una de ellas que nos ayudarn al diseo de nuestra propia Cadena de
Valor.
Estrategia, procesos y tecnologa.
La estrategia define como una empresa va a competir, como crear valor

a sus clientes, que metas tendr y que polticas desarrollar para alcanzar
sus objetivos. Su importancia para BPM es tal, que ningn proyecto debera
comenzar sin una definicin clara de la estrategia que se pretende.
La estrategia de la empresa no siempre se tiene en cuenta y esto es algo

que solemos olvidar cuando implementamos no slo distintos tipos de pro-
yectos empresariales, sino tambin proyectos de gestin por procesos. Al
inicio de cualquier proyecto de BPM, debemos preguntarnos por las metas
y objetivos que tenemos para los procesos y por lo menos, los objetivos
deberan estar definidos, pues sin ellos, no podemos trabajar en la mejora
de los procesos asegurando que aadan valor o contribuyan a la organiza-
cin. Sin esta definicin previa, ni tan siquiera sabremos si vamos en la di-
reccin correcta. Lo recomendacin en estos casos es relegar la mejora de
procesos hasta conocer la estrategia y objetivos de la empresa y no iniciar
ningn proyecto sin esta definicin previa. Otro aspecto importante rela-
cionado con la estrategia es que esta debe ser entendida por todos los
miembros del equipo de proyecto y de la organizacin, por lo que debe ser
comunicada y vendida a todos los miembros del proyecto, de forma que
estas personas comprendan y vivan la estrategia que se pretende con pa-
sin.
186
ntimamente ligada con la estrategia se encuentra la tctica. Mientras la

estrategia transfiere la visin en un plan a largo plazo, la tctica definir los
pasos especficos para implementar dicha estrategia, pero veamos los pasos
generales para realizar una correcta planificacin estratgica:
- Definir objetivos: de forma amplia para considerar todas las po-

sibilidades.
- Analizar el entorno: econmico, de mercado, regulatorio, anali-
zar todas las oportunidades y amenazas.
- Considerar los recursos: analizndolos por fortalezas y debilida-
des: beneficios por productos, personas, educacin, habilida-
des, capacidades de produccin, canales de venta, etc.
- Identificar acciones: o lista de tareas que deber llevar a la
empresa a cumplir sus objetivos. Implementar el Plan. Calenda-
rizar, monitorizar y seguir hitos.
- Implementar acciones.
- Monitorizar el progreso.
Este paso de la estrategia a la tctica para la implementacin del proyec-

to, puede todava ser extendido hacia una arquitectura de la organizacin,
que incluya el conjunto de elementos (objetivos, estrategias, modelos de
negocio, procesos, etc.) que alineados entre s, permitirn conformar la
Cadena de Valor entregada a los clientes. Esta alineacin comienza con los
niveles ms altos (estratgicos) hasta los ms bajos (operativos) siguiendo
un camino como el siguiente:
- Misin: es el nivel ms alto y explica por qu existe la empresa.

- Estrategia: lo que tenemos que hacer para cumplir con la mi-
sin. Se suele hacer uso del anlisis SWOT de fortalezas, debili-
dades, oportunidades y amenazas, para decidir cul es el mejor
camino que debe seguir la estrategia.
- Modelo de negocio: cmo vamos a hacer el negocio para obte-
ner un beneficio ofreciendo una propuesta de valor a nuestros
clientes. Nuestra propia propuesta de valor.
- Procesos de negocio: estos son las secuencias de actividades
que relacionadas entre s reciben unas entradas y producen
unas salidas. Estos procesos pueden ser automatizados.
- Tecnologa: necesaria para apoyar los procesos.
En este despliegue de la estrategia, vemos como para alcanzar sus obje-

tivos, todas estas reas deben actuar en armona y perfectamente alineadas
187
entre s y donde cada vez ms, nos encontramos con la necesidad de alinear
el negocio y la tecnologa a partir de la estrategia empresarial, para no im-
plementar las tecnologas de la informacin de forma aislada, como si en la
tecnologa por s misma, en un ERP, en el desarrollo de un aplicativo espec-
fico, una aplicacin para dispositivos mviles o una campaa en redes so-
ciales, estuviese la nica clave o tabla de salvacin de nuestra empresa.
Hoy en da asistimos al surgimiento de las denominadas redes sociales,

que las empresas estn usando de una forma programtica. Tratamos de
introducirlo en nuestros negocios a travs de nuevos modelos tecnolgicos
asociados al marketing online, pero no cambiando nuestros procesos, mo-
delos y estructuras organizacionales para orientarlas a esta nueva realidad y
aprovechar todas sus oportunidades. En las redes sociales, por ejemplo
suelen verse los efectos de nuestros procesos empresariales, a veces en
forma de alabanzas y otras en forma de crticas. Cuando estas ltimas exce-
den lo razonable para la empresa, esta suele optar por contratar una cam-
paa en redes sociales, de mejora de reputacin online o a un community
manager que resuelva el problema, pero lo que est haciendo la empresa
es actuar sobre los efectos visibles y no sobre las causas que originan ese
problema, el cual estar relacionado a un mal producto o servicio prestado
por la empresa, que a su vez estar asociado a un proceso ineficiente que
de no fallar, y si este cumpliese con aquello para lo que fue diseado, no
generara el problema que vemos reflejado en las redes sociales. El atacar el
problema por arriba, por los efectos y no por las causas del mismo, sera
como comprar un coche, no por su calidad o garantas de buen funciona-
miento, sino que lo hicisemos por disponer la empresa de un magnfico
servicio de reparaciones, cuando lo ideal sera que nuestro coche no fallase
nunca. Alguien dijo en cierta ocasin: "there are not it projects, only busi-
ness process that relay on it para que no olvidemos las bases sobre las que
se asienta nuestro negocio, la necesidad de una estrategia y unos buenos
procesos que la soporten, pues en su correcto funcionamiento, nos ahorra-
remos muchos problemas, que a veces intentamos resolver mediante par-
ches en otras batallas que no atacarn el origen del problema, por lo que
este es probable que vuelva a reproducirse. Esta tendencia a recurrir a la
solucin tecnolgica como salvavidas de urgencia para muchos problemas
empresariales, sin analizar los aspectos de negocio, es un error en el que
caen muchas empresas, invirtiendo grandes cantidades de dinero y recur-
sos en soluciones no alineadas con el negocio y que si bien a corto plazo
pueden camuflar los problemas, a medio y largo plazo conducirn a estruc-
turas de TI y culturas organizacionales totalmente desestructuradas.
188
No quisiera dejar este apartado sobre la estrategia sin llamar la atencin

sobre la importancia de su implementacin. Uno de los mtodos ms usa-
dos para la eleccin de la estrategia, la especificacin y medicin de los
objetivos, el modelo de negocio y los principios que debern regir el com-
portamiento de la organizacin es el Balanced Score Card. Aunque habla-
remos ms adelante de esta metodologa, recordaremos aqu a Kaplan, uno
de los autores que crearon esta metodologa, cuando afirmaba que por un
lado las empresas tienen que definir sus estrategias y por otro lado tienen
que implementarlas, y que es en esta segunda parte donde las empresas
tienen las mayores dificultades. A pesar de que resulte obvio, al igual que
las buenas intenciones, las buenas estrategias, si no se implementan, no
sirven de nada y no pasarn de ser simplemente un conjunto de buenas
intenciones. En muchas ocasiones culpamos a la estrategia cuando nuestro
proyecto fracasa, cuando lo que casi siempre falla es la implementacin de
esa estrategia, o lo que es lo mismo, los procesos, pues son estos los encar-
gados de implementar la estrategia en la organizacin y el xito de nuestro
modelo de negocio estar en unos pocos procesos, que alineados con la
estrategia y objetivos de la empresa y haciendo uso de la tecnologa y las
herramientas de mejoras de procesos, permitirn que la empresa desarrolle
todas sus capacidades y potencial.
Sobre como alinear la estrategia con los procesos y la tecnologa es so-

bre lo que trataremos en los restantes apartados de este captulo.
Arquitectura empresarial.
De la necesidad de alinear la estrategia con la tecnologa y conseguir que

los procesos de negocio de la empresa sean soportados y facilitados por la
tecnologa para que estos sean ms eficientes y poder alcanzar las metas de
negocio, surgen las Arquitecturas Empresariales (AE). El desarrollo de estas
arquitecturas y los frameworks que nos ayudarn en su diseo y definicin,
se dirigen tanto a orientar las iniciativas tecnolgicas, de forma que estas
apoyen el cumplimiento del los procesos y la estrategia, como tambin nos
sirvan como referencia para las empresas que quieran implantar una solu-
cin informtica que integre el negocio, los datos, las aplicaciones y la tec-
nologa, para cubrir las necesidades actuales y futuras del negocio y reducir
la brecha que anteriormente comentbamos entre las reas de negocio de
las de TI.
189
La AE englobar a todos los aspectos de la organizacin para disear

como los distintos bloques de esta, junto a los elementos que la componen,
pueden de forma sistmica, estructurarse y organizarse para ejecutar la
estrategia en forma de procesos operacionales, que sern en ltima instan-
cia los que conviertan en realidad esa estrategia. En este proceso, la Estra-
tegia decide la direccin que debe tomar la organizacin, la Arquitectura de
Negocio especifica el diseo organizacional necesario para cumplir con esa
estrategia y los Procesos y operaciones de la empresa ejecutarn esta ar-
quitectura de negocio.
Las Arquitecturas Empresariales (AE) representan un acercamiento hols-

tico e integral a las organizaciones que cubre los procesos de negocio, los
sistemas de informacin, la infraestructura tecnolgica y las personas, para
describir como estas se integran y trabajan conjuntamente como un todo y
servirn de ayuda para gestionar la creciente complejidad tecnolgica de
las organizaciones. Esta visin integral proporcionada por las AE, nos permi-
tir capturar la complejidad asociada a las empresas, identificando todos y
cada uno de los componentes que la forman, para producir un todo cohe-
rente y articulado, con el cual afrontar los cambios sin temor a adoptar los
procesos y tecnologas necesarios para poder llevar adelante estos cambios,
as como el diseo de la configuracin que precisaremos para convertir esta
estrategia en iniciativas claras y concretas.
Las AE, inicialmente se plantean desde una perspectiva en tres niveles:

estrategia, procesos y sistemas de informacin, en el que la estrategia defi-
ne sus mercados, productos, servicios, objetivos y metas qu se quieren
alcanzar, los procesos proporcionan los medios operativos para alcanzar los
objetivos definidos en la estrategia y en el nivel de los sistemas de informa-
190
cin se automatizan estos procesos apoyndose para ello en la infraestruc-

tura tecnolgica. Sin embargo, actualmente se divide la AE en cuatro vistas
o perspectivas:
- Arquitectura de Negocio: que traduce las estrategias y objetivos

de alto nivel en requerimientos para el negocio y describe la es-
tructura organizacional, de procesos, sistemas de planeacin y
control, mecanismos de gobierno, polticas y procedimientos.
- Arquitectura de Informacin: referida a los activos fsicos y lgi-
cos de los datos, fuentes y tipos de informacin que existen en
la empresa para garantizar la calidad de estos datos y que cual-
quier persona de la organizacin pueda acceder a estos y la in-
tegre a su propio conocimiento. Esta arquitectura ser la que
permita la gestin de los recursos de informacin y representa-
r el flujo y modelado de la informacin en toda la organizacin
a travs del diseo de los modelos entidad-relacin y de bases
de datos.
- Arquitectura de Sistemas: o de aplicativos funcionales de apoyo
al negocio, que define que aplicaciones son relevantes para la
empresa.
- Arquitectura Tecnolgica: el marco tecnolgico de plataformas
hardware, servidores, redes, firewalls, de bases de datos y dis-
positivos de almacenamiento y copias de seguridad que sopor-
tarn a las distintas soluciones de negocio.
Estas cuatro perspectivas permiten entender los distintos elementos que

forman una empresa y como estos se interrelacionan para crear un entorno
de TI unificado que de soporte a la estrategia de la empresa.
Para la definicin de la AE, detallaremos los elementos que compondrn

la misma y especificaremos las relaciones entre estos componentes, identi-
ficando y definiendo qu hacemos y que productos y servicios ofrecemos a
nuestros clientes y como los producimos. En este proceso, traduciremos la
visin de la empresa y su estrategia, a travs de la conformacin de una AE
que describa la manera en que la organizacin y la tecnologa operarn para
ejecutar las operaciones de negocio. Esta arquitectura incluir la estrategia
y objetivos de la organizacin, objetivos organizados jerrquicamente, las
capacidades de los que disponga la organizacin, los procesos y las salidas
que producen, modelaremos la cadena de valor que ejecuta la empresa y
en especial los procesos que representan su core de negocio, la estructu-
ra de la organizacin, el modelo de datos, las aplicaciones e infraestructura
191
de TI de toda la empresa de una forma sencilla y fcil de entender, de for-

ma que dispongamos de los componentes principales de la organizacin y la
relacin entre los mismos para conseguir los objetivos de negocio.
Las Arquitecturas de Procesos Empresariales son usadas muchas veces

como gua en muchos proyectos de calidad, Six Sigma y Lean, as como de
punto de partida de proyectos en BPM. La Arquitectura de Negocio y BPM
pueden operar conjuntamente para llevar adelante una estrategia empre-
sarial, donde la Arquitectura de Negocio proporcionar el contexto para
indicar qu se debe hacer y BPM, como disciplina centrada en los procesos
de la empresa, recoger esta orientacin e implementar la definicin de la
estrategia en iniciativas, de forma que se cierre la brecha entre la estrategia
y su ejecucin.
Adems de las Arquitecturas de Negocio para describir cmo operan los

negocios va su estructura organizativa y acciones que deben ser realizadas,
existen tambin otros tipos de arquitecturas y especificaciones que nos
pueden ayudar a definir y especificar nuestras arquitecturas organizaciona-
les y de procesos como la Business Process Architecture (BPA), la cual defi-
ne la arquitectura a alto nivel de todos los procesos de negocio y las rela-
ciones entre ellos. BPA es mucho ms amplio que los modelos e incluye los
subprocesos y actividades de negocio a travs de la cadena de valor, las
interacciones entre procesos y los recursos humanos y materiales as como
los indicadores para la medicin de los procesos. De esta forma BPA conec-
ta la estrategia de negocio con los procesos, proveyendo no slo de un en-
tendimiento de cmo realmente funciona el negocio sino tambin de un
marco sobre el cual sugerir mejoras.
Para la realizacin de las Arquitecturas Empresariales, veremos a conti-

nuacin distintos frameworks, estndares y modelos de referencia que nos
ayudarn en este proceso.
192
Frameworks, Estndares y Modelos de Referencia.
Dependiendo del tamao de nuestra organizacin y si esta es pequea,

es posible que una sola persona o un reducido nmero de ellas puedan
realizar el modelado de procesos de nuestra organizacin, pero si nuestra
empresa es ms grande y adems interacta con otras, necesitaremos de
modelos organizacionales y de procesos con indicadores de medidas sobre
los mismos para orientarnos en como operar y disear nuestros propios
procesos.
El modelado de negocios no est enfocado a la generacin de un solo

modelo capaz de representar toda la empresa, por lo que existen tipos de
modelos o vistas, centradas cada una de ellas en alguna dimensin especfi-
ca de la empresa: procesos, organizacional, de sistema de informacin, etc.
Para el desarrollo de nuestros propios modelos, deberemos realizar
benchmarking y buscar modelos de Arquitecturas Empresariales dentro de
los numerosos marcos de referencia (frameworks), estndares y modelos
de referencia, los cuales deberemos integrar para la definicin de nuestras
propias arquitecturas y modelos de negocio y seguir la cascada, para desde
la definicin de la estrategia, definir y acelerar el despliegue de la arquitec-
tura de procesos de negocio de nuestra organizacin.
Los Frameworks definen un conjunto estandarizado de conceptos, prc-

ticas y criterios para enfocar una problemtica concreta, que sirven de refe-
rencia para enfrentar y resolver problemas similares. Por otra parte, los
Modelos de Referencia son una representacin grfica, matemtica o ver-
bal, de forma simplificada, de un concepto, fenmeno, relacin o estructura
de algn aspecto del mundo real y que tambin nos servirn para represen-
tar los procesos de negocio. Los Modelos de Referencia contienen concep-
tos, axiomas y relaciones relacionados con un dominio particular de un
problema y es independiente de estndares, tecnologas o cualquier otro
detalle.
La complejidad de cualquier empresa o sector hoy en da es enorme. En

los negocios y a pesar de la tecnologa, se cumple la paradoja de la produc-
tividad, segn la cual, existe una gran brecha entre el desarrollo de la po-
tencia en los ordenadores y el relativamente lento aumento de la producti-
vidad empresarial. Las empresas son cada vez ms complejas de gestionar y
cada vez es ms difcil controlar todos los procesos en los que interviene
nuestra empresa. Recordando lo que Peter Senge entenda por complejidad
dinmica: cuando una accin tiene una serie de consecuencias locales y
193
otras muy diferentes en otras partes del sistema, estamos hablando de

complejidad dinmica, o sea, cuando acciones obvias en una parte tiene
consecuencias no obvias. y lo que un colega de Senge, John Sterman, en-
tenda como necesario para solucionar esta complejidad: solucionar la
complejidad consiste en encontrar la mejor solucin entre un nmero ilimi-
tado de posibilidades, el nmero de componentes o combinaciones que
debemos considerar en un sistema para tomar una decisin. Si asumimos
el entorno empresarial actual como de una complejidad dinmica, enton-
ces, una de las mejores prcticas que podemos llevar a cabo para reducir
esta complejidad y no realizar experimentos empresariales arriesgados con
una infinidad de posibilidades, ser el recurrir a los estndares y modelos
de referencia para conocer las mejores prcticas emprendidas por otras
empresas en distintos sectores, para a travs de su experiencia, disear
nuestros negocios y nuestras propias Arquitecturas Empresariales.
Frameworks:
Los procesos generalmente no son diseados desde cero sino que se

identifican en la propia organizacin o se extraen de mejores prcticas y
estndares existentes como los que veremos a continuacin. Los Business
Process Frameworks son parte de las BPA y describen como las cadenas de
valor de una empresa son expresadas va una red de procesos de negocio.
Estos Frameworks son una descripcin de un conjunto de actividades y
procesos de alto nivel asociados con mtricas para poder medir su rendi-
miento, buenas prcticas de gestin y que describen como opera un nego-
cio en una determinada cadena de valor e incluyen un desglose hasta los
niveles ms bajos de actividades, convirtindose en una valiosa herramien-
ta para organizar un negocio y describir sus procesos y tareas de forma ms
rpida y eficiente, basndonos en las mejores prcticas de distintos secto-
res.
Existen varias metodologas, frameworks y especificaciones de procesos

para la realizacin de estas Arquitecturas Empresariales, de forma que po-
damos conceptualizar y describir los elementos que la componen como el
framework de Zachman, desarrollado en 1980 en IBM y uno de los primeros
en abordar la especificacin de las Arquitecturas Empresariales. Este fra-
mework, que todava sigue siendo de los ms utilizados, mapea en una ma-
triz las preguntas: Qu, Dnde, Cuando, Por qu, Quien y Cmo, para facili-
tar la comprensin de la empresa, y representar su arquitectura pero es un
194
framework que no est orientado a procesos. En los primero aos del siglo
XXI, comenzaron a desarrollarse otros framewoks, no slo enfocados en TI
sino tambin en como las TI deberan dar soporte a los procesos de nego-
cio. Los CIO (Chief Information Office), pasaron a involucrarse en las reas
de negocio y en la forma en que la tecnologa poda mejorar de los procesos
de negocio. Comenzaron as a desarrollarse los frameworks ms conocidos
y que veremos a continuacin.
La idea con todos ellos es que no reinventemos la rueda y nos basemos

para el diseo de nuestros procesos en las mejores prcticas y procesos ya
probados, para aplicarlos en nuestra organizacin, pues seguro que de to-
dos ellos sacamos ideas para nuestros procesos de negocio por lo que de-
beran siempre ser consultados antes de disear nuestros propios procesos.
Modelos de Referencia:
Un modelo de referencia es algo que contiene la idea bsica de algo y

que se puede establecer como referencia para mltiples propsitos. Los
Process Reference Models integran los conceptos de reingeniera de pro-
cesos, benchmarking y mejoras prcticas dentro de un ambiente especfico
como se muestra en el siguiente grfico.
Process
BPR Benchmarking Best Practices Reference Model
Capturar el estado Capturar el estado actual
actual de los de los procesos de
procesos de negocio y obtener el
negocio y obtener como deberan ser
el como deberan mejorados.
ser mejorados. Cuantificar las
mejoras Cuantificar las mejoras
operacionales de operacionales de
empresas empresas similares.
similares. Conocer Conocer los que mejor
los que mejor hacen sus procesos.
hacen sus
procesos.
Conocer las
mejores prcticas Conocer las mejores
de gestin y prcticas de gestin y
soluciones soluciones software
software existentes.
existentes.
195
TOGAF:
TOGAF (The Open Group Arquitectural Framework), presenta una me-

todologa y procesos detallados para el diseo y especificacin de Arquitec-
turas Empresariales, la cual mostramos de forma resumida en el siguiente
grfico:
TOGAF se basa en cuatro dimensiones:
- Arquitectura de Negocios o de procesos de negocio: la cual de-

fine la estrategia de negocio, la gobernabilidad y los procesos
clave de la organizacin.
- Arquitectura de aplicaciones: la cual provee de un plano para
cada uno de los sistemas de aplicacin que se quieran imple-
mentar, las interacciones entre estos sistemas y sus relaciones
con los procesos de negocio.
- Arquitectura de Datos: la cual describe la estructura de los da-
tos fsicos y lgicos y los recursos de gestin de estos datos.
- Arquitectura tecnolgica: que describe la estructura de hardwa-
re, software y redes requerida para dar soporte a la implemen-
tacin de las aplicaciones principales.
Para TOGAF, la Arquitectura Empresarial es un requisito previo para po-

der trabajar en la arquitectura de empresa desde otros puntos de vista y es
por ello la primera que debe ser analizada antes que otras arquitecturas
196
como la de la informacin, de datos, aplicaciones, tecnolgicas, organiza-

cionales o de recursos.
TOGAF es un modelo de referencia que puede ser usado libremente (sin

costo) por cualquier organizacin.
APQC Process Classification Framework:
APQC (American Productivity & Quality Center), utilizado para conocer

mejores prcticas, investigacin y benchmarking. Dispone de modelos es-
tndar de industrias especficas. Tiene 12 niveles de categora de procesos
(5 operacionales y 7 de soporte a procesos) y 4 niveles de detalle:
- Categora 1.0
- Grupo de procesos 1.1
- Procesos 1.1.1.
- Actividad 1.1.1.1
197
Los procesos se agrupan en dos categoras: Operacionales y de Gestin y

Soporte. Como vemos en el diagrama, donde hay 12 procesos de negocio
identificados.
Es bastante recomendable el visitar su pgina web para cada proceso

que iniciemos en nuestra organizacin, en busca de procesos y buenas
prcticas que nos puedan ayudar e inspirar en la definicin y diseo de
nuestros procesos.
SCOR:
Es un marco de referencia y una metodologa para la evaluacin y

construccin de cadenas de sumninistro en la que interviene varias
empresas.
El modelo SCOR (Supply Chain Operations Reference model, SCOR-

model) nos permite representar, analizar y configurar una cadena de
sumnistro. Desarrollado en 1996 por el Supply-Chain Council, SCOR se
centra en la definicin de los procesos centrales de la organizacin y une los
procesos de negocio, los indicadores de gestin, las mejores prcticas y las
tecnologas, en una estructura unificada para apoyar la comunicacin entre
los intervinientes en una cadena de suministro y sus actividades
relacionadas y puede ser utilizado tanto para cadenas simples como las
muy complejas.
El modelo SCOR dispone adems de KPIs (Key Performmance Indicators)

o Indicadores de rendimiento, para comparar diferentes alternativas y
estrategias de los participantes en la cadena de suministro.
SCOR est organizado entorno a cinco procesos principales de gestin:

Planificacin (Plan), Aprovisionamiento (Source), Manufactura (Make),
Distribucin (Deliver) y Devolucin (Return), de forma que el modelo abarca
todas las interacciones con clientes, las transacciones de materiales con los
proveedores hasta los clientes de los clientes e interacciones con el
mercado.
SCOR contiene tres niveles de detalle:
- Nivel Superior (Tipos de Procesos): se analizan las bases

competitivas (Basis of Competion) y se establecen los objetivos
de rendimiento competitivo (Competitive Performance
198
Targets), se comparan estos indicadores con los de otras

empresas y sectores y se califican como: iguales, con ventaja o
superiores, de forma que podamos situar nuestra organizacin
y como se encuentra esta para priorizar los proyectos en que
debemos trabajar.
- Nivel de Configuracin (Categoras de Procesos): en este nivel
existen 26 categoras de procesos: 5 de Plan, 3 de
Aprovisionamiento, 3 de Manufactura, 4 de Distribucin, 6 de
Devolucin y 5 de Apoyo. En este nivel se representa el estado
actual de los procesos, para despus establecer, como estos
deberan ser, el estado deseado, usando las 26 categoras de
procesos y los Diagrams de Hilos (Thread Diagram) tambin
denominado Mapa de Procesos de SCOR.
- Nivel de elementos de Procesos (Descomposicin de los
Procesos): en este nivel se descomponen las categoras en
elementos de procesos (Process Elements) que se presentan en
secuencia lgica con sus entradas y salidas para cada uno de
ellos y se evala el rendimeinto de cada proceso mediante el
uso de indicadores.
Para los tres niveles, SCOR proporciona indicadores de rendimeinto

asociados a: Fiabilidad (Reliability), Flexibilidad (Flexibility), Velocidad de
atencin (Responsiveness), Coste (Cost) y Activos (Assets).
SCOR no incluye los siguientes aspectos: ventas y marketing, desarrollo

de producto, Investigacin y desarrollo y algunos elementos de servicio
post-venta.
El uso del modelo SCOR nos puede ayudar a identificar indicadores,

encontrar oportunidades de mejora e identificar mejores prcticas antes de
desarrollar nuestros propios procesos. Adems, SCOR ofrece amplias
descripciones en sectores industriales que pueden ayudar a una empresa a
comparar sus medidas con las de otras empresas. SCOR, aunque diseado
para la optimizacin de la cadena de valor, es generalmente utilizado para
describir procesos en muchos tipos de organziaciones. Existe una
aproximacin alternativa a SCOR que es el VRM (Value Reference Model).
199
CobIT:
Control Objectives for Information and related Technologies (CobIT),

creado por el IT Governance Institute (ITGI), es una serie de guas para ayu-
dar a las organizaciones en la mejora de la gobernanza de TI con la creencia
de que la gestin efectiva de TI producir mejoras en el desarrollo de las
empresas.
Todas las organizaciones tienen la necesidad de informacin, la cual es

utilizada por los procesos de negocio para alcanzar los objetivos de negocio
y quien provee de esta informacin son los sistemas de TI gestionados por
los proceso de TI. CoBIT establecer que procesos debo gestionar de TI en
mi organizacin y cmo puedo controlarlos, para lo cual y partiendo de una
alineacin con los procesos de negocio define y especifica los objetivos que
deben tener los procesos de TI y los controles que debo tener sobre estos
procesos, estableciendo adems que criterios debe tener esa informacin,
que recursos deben existir en la organizacin, que procesos se deben ejecu-
tar, que requerimientos y validaciones deber tener para el ingreso de da-
tos en el proceso, la transformacin y salida de estos para impedir que la
informacin sea errnea o que los datos pasados no puedan ser manipula-
dos o modificados.
CobIT, siguiendo el ciclo de Demming, presenta 4 niveles o dominios de

control por objetivos de TI: Planificacin y organizacin, Adquisicin e im-
plementacin, Entrega y soporte y Monitorizacin, sobre los cuales se pue-
den establecer objetivos de control e implementar controles automatiza-
dos. Este control por objetivos es un propsito o resultado deseable como
por ejemplo: garantizar la continuidad de las operaciones ante contingen-
cias, para la cual, podremos implementar uno o varios controles indicados
en el modelo, por ejemplo: realizar copias de seguridad, realizar copias
redundantes, etc.
En CobIT se organizan las actividades dentro de un marco general acep-

tado que establece los controles de gestin sobre los objetivos perseguidos,
enlazando TI con requerimientos de negocio. CobIT tiene 34 objetivos de
alto nivel que cubren 215 objetivos de control, clasificados en los cuatro
niveles que hemos visto, con los cuales determina un conjunto de mejores
prcticas para la seguridad, la calidad, la eficacia y la eficiencia de TI, ali-
neando la tecnologa con el negocio al tiempo que nos permite identificar
riegos, dar valor al negocio con las TI, gestionar los recursos y medir su des-
empeo. CobIT proporciona adems indicadores, procesos y mejores prc-
200
ticas para ayudar a maximizar la inversin en TI, su control y gobernanza en

la empresa.
CobIT se ha convertido en un estndar para el buen gobierno de los sis-

temas de informacin, se ofrece gratuitamente y est realizado con el es-
fuerzo de cientos de voluntarios de todo el mundo.
Objetivos de Negocio
CoBIT
INFORMACIN
MONITOREAR Y
EVALUAR
PLANEAR Y
RECURSOS
ORGANIZAR
ENTREGAR Y DAR
SOPORTE
ADQUIRIR E
IMPLANTAR
CobIT proporciona, como ya comentamos, indicadores para valorar la

madurez de la organizacin y presenta unos niveles para la misma:
- Nivel 0: proceso incompleto, no existe o no cumple con los ob-

jetivos.
- Nivel 1: proceso ejecutado.
- Nivel 2: proceso gestionado, el proceso no slo se encuentra en
funcionamiento, sino que es planificado, monitorizado y ajusta-
do.
- Nivel 3: proceso definido, el proceso, los recursos, lo roles y
responsabilidades se encuentran documentados y formalizados.
- Nivel 4: proceso predecible, se han definido tcnicas de medi-
cin de resultados y controles.
201
- Nivel 5: proceso optimizado, todos los cambios son verificados

para determinar el impacto, se han definido mecanismos para
la mejora continua, etc.
Balance Score Card (BSC):
En 1992, Robert Kaplan y David Norton introdujeron la idea del Cuadro

de Mando como medio para monitorizar y ayudar en la gestin de los nego-
cios. Estos mismos autores desarrollaron la idea de los mapas estratgicos,
para ayudar en la creacin de los cuadro de mando, estos mapas muestran
los objetivos estratgicos para la generacin de valor, mostrando las causas
y efectos de esos objetivos sobre la estrategia. Estos objetivos eran clasifi-
cados segn las cuatro reas del Cuadro de Mando o Balance ScoreCard.
Balance Scorecard (BSC), provee de un marco para traducir la visin y es-

trategia de la empresa en datos reales. Est organizada en cuatro niveles o
perspectivas: financiera (beneficio, cash-flow), clientes (satisfaccin, reten-
cin, nuevos clientes, mercados), procesos internos de negocio (procesos
crticos, innovacin en procesos, nuevos procesos), aprendizaje y crecimien-
to (personas, sistemas, procedimientos organizacionales).
En el entorno de BPM, usaremos Balanced Scorecard, pero siempre par-

tiendo de la estrategia y de la alineacin de BSC con los objetivos de nego-
cio, definiendo previamente la arquitectura de procesos para usar BSC co-
mo herramienta ideal para las medidas de cumplimiento de los objetivos
tanto de los procesos individuales como de toda la cadena de valor.
Otros estndares:
Basel II:
Muy de moda ahora en Espaa, es un estndar internacional sobre los

requisitos mnimos de capital y el dinero que un banco tiene que guardar y
no prestar para ser solventes.
Sarbanes-Oxley:
A pesar de ser una normativa de obligado cumplimiento para organis-

mos financieros, representa una oportunidad para las empresas para la
mejora y entendimiento de sus procesos.
202
Sarbanes-Oxley formaliza los controles internos y procesos que deben

regular la informacin financiera que publica una empresa, con objeto de
proteger a sus inversores, socios y clientes, de tal manera que estos orga-
nismos dispongan de procesos exactos sobre como manejan esta informa-
cin, asegurando que esta informacin que publiquen sea cierta y que no
ocurran casos como Enron, Worldcom o Tyco donde la manipulacin de los
sistemas de informacin permiti un gran fraude que resultaron en grandes
prdidas y crisis en la confianza de los inversores.
La informacin de los estados financieros y del balance de una organiza-

cin so hoy en da proporcionados por los sistemas de informacin. Si los
sistemas de informacin son los que proveen de los datos financieros, a
quien vamos a auditar para saber si estos datos son ciertos y no han sido
modificados o manipulados, pues obviamente a TI, por lo que el instrumen-
to que usamos hoy para asegurar que la informacin dentro de una organi-
zacin sea la que tiene que ser: correcta, exacta, fiable, confiable, disponi-
ble, etc. es CoBIT que nos proporcionar gobierno y control de las TI. De
hecho CoBIT comenz como una herramienta de auditora que ha ido evo-
lucionando hasta convertirse en una herramienta de management.
Regulaciones como Sarbanes-Oxley requieren que las empresas sean ca-

paces de controlar sus procesos e indicadores precisos de los mismos para
cumplir con estas regulaciones gubernamentales y reglas de negocio. Entre
las regulaciones que establecen se encuentran por ejemplo, el que los in-
formes financieros sean revisados y firmados y que estos representen la
situacin real de la compaa, de sus resultados y situacin financiera. Sar-
banes Oxley obliga a que las empresas provean tambin de informacin
detallada de sus sistemas de control y auditoras, la obligacin de comuni-
car y hacer pblica cualquier cambio en su situacin financiera y otras regu-
laciones cuyo incumplimiento pueden acarrear penas de prisin.
Otros Frameworks que pueden resultar de utilidad en determinados sec-

tores son: eTOM (eBusiness Telecom Operations Map) en empresas de
telecomunicaciones, VRM para la cadena de valor, ACORD para el sector de
los seguros, EFQM el cual es un estndar de calidad europeo para las
empresas, el SEi (Software Engineering Institute) o ITIL y CMMI (Capability
Maturity Model) para la evaluacin de procesos de TI.
Estos estndares y framewoks deben ser consultados en busca de

acelerar la adpocin de los procesos y arquitecturas de procesos que ms
se ajusten a nuestro negocio, pues al igual que un mdico no prescribe la
203
misma receta a distintos tipos de pacientes, no todas las organizaciones son

iguales y todas tienen sus particularidades, por lo que los modelos vistos en
este captulo, nos servirn de inspiracin para desarrollar nuestros propios
frameworks en base a que hacen otras organizaciones y a modelos que han
sido probados y considerados como buenas prcticas.
Modelos organizacionales.
Las Arquitecturas Empresariales, incluyen tambin las estructuras orga-

nizativas, por lo que en su especificacin incluiremos un modelado de la
organizacin, de cmo esta se organiza en unidades de negocio y como se
relaciona con otras empresas, pero no en como realiza su trabajo, pues esto
lo haremos en procesos. En los modelos organizacionales describiremos los
grupos de trabajo y departamentos, quien interacciona con quien, jerarqu-
as en el reporte de informacin (quien informa a quien), los roles de las
personas involucradas en la misma, sus responsabilidades y que hace cada
una dentro de la organizacin. Con toda esta informacin crearemos un
Modelo Organizacional que puede ser usado para representar como es
actualmente la organizacin as como la descripcin de cmo ser tras el
cambio o la realizacin de un proyecto de BPM, lo cual nos ayudar para la
gestin del cambio y la comunicacin durante el desarrollo del proyecto.
Para la realizacin de estos modelos organizacionales, no existen estn-

dares y cada organizacin uso sus propios modelos. El modelo tal vez ms
aproximado a un estndar es el de Rummler-Brache.
El Business Motivation Model (BMM).
El Business Motivation Model (BMM), es una especificacin del OMG

(Object Management Group) establecida en el ao 2006 y convertida en
estndar para capturar y definir la estrategia empresarial como paso previo
al diseo y modelado de los procesos de negocio.
El BMM es un meta-modelo que define los principales elementos que in-

tegran un plan de negocio y que proporciona las bases para planificar nues-
tros procesos de negocio, asegurando que estos estn alineados con la es-
trategia y los objetivos de negocio. Para ello el BMM, desde una perspectiva
de negocio, permite identificar y definir los principales factores que moti-
204
van el desarrollo de un plan de negocio y las interrelaciones entre estos

como paso previo al diseo de soluciones tcnicas y como base sobre la que
desarrollar las mismas.
En el BMM podremos definir los elementos que integraran nuestros pla-

nes de negocio y establecer unas relaciones claras entre las polticas, las
reglas, los fines y los medios que emplear la empresa para conseguir sus
objetivos empresariales.
Como ya venimos indicando, uno de los problemas al que nos enfrenta-

mos a la hora de comenzar un proyecto de BPM es por donde empezar el
proyecto y aqu nuestra recomendacin es comenzar por arriba, por la vi-
sin y la estrategia de la organizacin, para alinear esta estrategia con el
diseo de los procesos, las personas y la tecnologa. EL BMM est desarro-
llado desde una perspectiva de negocio y de esta forma, los planes de ne-
gocio que generemos con el BMM, sern la base fundacional para el diseo
de sistemas y el desarrollo tcnico, conectando la solucin tecnolgica con
la de negocio. Al comenzar con nuestro proyecto, las preguntas que debe-
mos hacernos y que nos ayudar a contestar el Motivation Model son: por
qu existe nuestra empresa?, cul es su razn de ser?, qu metas desea
alcanzar? y qu usar nuestra empresa para conseguir estos resultados?
Estas preguntas sobre el por qu, qu, cmo, cundo y dnde, deberamos
realizarlas en cualquier organizacin que desee alinear sus implantaciones
de TI con la visin, las metas, los objetivos, estrategias, tcticas, reglas y
procesos de su negocio, de forma que estos aspectos de negocio se conec-
ten con las especificaciones software y de sistemas de una forma coordina-
da y estructurada.
Esta sincronizacin entre negocio y TI toma ahora ms importancia que

nunca con la aparicin de las arquitecturas orientadas a servicios (SOA), los
web services y la computacin en la nube, donde a partir del BMM podre-
mos trazar las relaciones de negocio con los servicios y arquitecturas soft-
ware que les darn soporte.
Los siguientes apartados que describen el BMM nos ayudarn a disear

y entender la estrategia sobre la que fundamentar la implementacin de
una gestin por procesos, de forma que pasemos de ser unos observadores
de los resultados, que con posterioridad modifican y redisean estos proce-
sos, a tomar las riendas de nuestro negocio y gestionar los procesos y pos-
teriormente controlar los resultados.
205
El Business Motivation Model tendr tambin un importante valor co-

mo herramienta para comunicar la estrategia a los stakeholders, al equipo
de proyecto y al resto de la organizacin, as como para analizar y comparar
esta estrategia con la de otras empresas e incluso simular el funcionamien-
to de la misma para buscar mejoras, estrategias alternativas o problemas
en el diseo realizado.
NOTA: en toda la descripcin del BMM, hemos preferido mantener las

siglas y conceptos en ingls utilizadas en el BMM por el OMG, por ser mejor
entendidas de esta forma los conceptos descritos en el mismo y por conside-
rar que con la descripcin dada de cada uno de ellos, se entendern perfec-
tamente los trminos y conceptos descritos en este modelo.
La estructura general del BMM es la mostrada en el siguiente diagrama:
Los puntos bsicos del modelo son:
- Ends (Finalidades): cosas que la empresa quiere alcanzar: Visin,

Goals and Objectives.
- Means (Significados): cosas que la empresa emplear para al-
canzar esos Ends: Mission, Strategy, Tactics, Business Policies
and Business Rules. Maneras para lograr esas cosas. Cosas que
nos influyen.
206
- Influencers (Influenciadores): cosas que nos pueden influir y que

dan forma a los elementos del Business Plan.
- Assesments (Valoraciones): decisiones que tomamos sobre los
Influencers. Los conforman los impactos que los Influencers tie-
nen en los Ends y los Means. Evaluaciones, opiniones, anlisis.
Lo que aplicamos a los Influencers en funcin del impacto que
estos pueden tener sobre los objetivos.
Ends, Means e Influencers estn conectados unos con otros para res-
ponder a la siguiente pregunta: qu necesito para alcanzar lo que la em-
presa desea alcanzar?
A continuacin vemos en detalle cada uno de las partes del modelo.
Ends.
Los Ends describen el estado ideal futuro de la empresa: incluyen Vision

y Desired Result, que contiene Goals y Objectives.
207
Vision (Visin):
Es un estado futuro que desea alcanzar la empresa, probablemente inal-

canzable. Podra ser visto como lo que otras personas nos gustara que vie-
sen de nuestra empresa, por ejemplo, ser lderes de mercado, innovadores,
etc.
Desired Results (Resultados Deseables): al contrario que la Visin, los

resultados deseables deben ser alcanzables y ms especficos. Incluyen los
Goals y Objectives.
Goals (Metas):
Una Meta es simplemente algo que la empresa desea alcanzar, un resul-

tado final de la estrategia. Las Metas son aspiraciones ms especficas de la
empresa, soportan a la Visin y suelen ser vistas a largo plazo, concretas, de
forma que podamos definir objetivos sobre estas metas. Pueden tener una
descomposicin jerrquica y se definen de forma cualitativa ms que cuan-
titativa.
Objectives (Objetivos):
Los objetivos son los pasos para alcanzar las metas y el progreso hacia
estas, deben tener fechas de finalizacin y criterios para determinar si son
alcanzados o no, por lo que deben ser alcanzables, medibles y con un tiem-
po definido para su realizacin. Las metas por s mismas no son suficientes,
pues estas no son precisas en cuanto a los tiempos en que deben ser alcan-
zadas y es por ello que las metas son completadas por los objetivos. Los
objetivos son resultados finales deseados como las metas, pero cambian
con ms frecuencia que estas, son especficos en cuanto a tiempos y deben
ser medibles. Los objetivos los crearemos pensando en las metas y en las
medidas que deberemos asociar a los mismos y pueden ser descompuestos
tambin jerrquicamente.
Comparados con los objetivos, las metas son a largo plazo, cualitativas
(ms que cuantitativas) y generales (ms que especficas). Comparadas con
las metas, los objetivos son a corto plazo y cuantitativos. Los objetivos se
diferencian en que siempre tienen una fecha para su cumplimiento, son
medibles y nos dan la medida de si nos acercamos o no a la meta. Los obje-
tivos deben ser SMART (Specific, Measurables, Attainable, Relevant y Time-
Based; o sea: Especficos, Medibles, Alcanzables, Relevantes y Basados en el
tiempo). Los Desired Result son soportados por los Courses Of Action, que
208
pueden ser Estratgicos o Tcticos. Generalmente las Metas son soportadas

por la estrategia y los objetivos por la Tctica.
Ejemplos de Meta y Objetivo:
- Poner en marcha una tienda on-line para aumentar las ventas de

mquinas. (META)
- Conseguir 100 nuevos clientes y 300 ventas en los primeros tres
meses con la tienda online (Objetivo)
Ejemplos de Objetivos:
- Financieros:
o Obtener una cuota de mercado del X% en Y meses.
o Aumentar las ventas en la regin X un Y% en Z meses.
o Alcanzar un ROI del X% en Y meses.
- No financieros:
o Alcanzar una satisfaccin de clientes de al menos el X%
en Y meses.
o Reducir los tiempos de respuesta a X en Y% de llamadas.
Means.
Lo que una empresa a decidido hacer para ser lo que desea ser. Son los
mecanismos mediante los cuales los Ends son alcanzados. Los componentes
de los Means son: La Misin, la Estrategia, la Tctica y las Directivas.
209
Mision (Misin):
Estado general de la empresa, una generalizacin del valor que quiere

producir. La Misin indica lo que una empresa hace. (Ejemplo: proporcionar
material de oficina a empresas). Debe ser lo suficientemente amplia para
que cubra todo el rango de actividades que pueda realizar la empresa. En su
definicin debe contener slo los siguientes puntos (1 Accin (proveer), 1
Producto o Servicio (pizzas), 1 mercado o clientes (oficinas de ciudad))
Course of action (Curso de Accin):
Los Course of Action son similares a los resultados deseados (metas y

objetivos) en el sentido en que ambos son algo que la empresa desea alcan-
zar, pero los Course of Action son los medios con los que la organizacin
alcanzar sus metas y objetivos para alcanzar unos fines determinados. Los
Courses of Action pueden ser Estrategias o Tcticas. Las estrategias son ms
largas y difciles de cambiar que las tcticas. Las empresas establecen estra-
tegias y tcticas al tiempo que definen metas y objetivos. Las tcticas y es-
trategias tambin pueden ser descompuestas jerrquicamente.
Los Course of Action que incluye estrategias y Tcticas, representan los

elementos bsicos del Plan para alcanzar los Desired Results. Los Course of
Actions definen lo que se debe hacer, no lo bien que se deben hacer (esto
ir en objetivos). Cada estrategia (a largo plazo) es implementada por las
tcticas, que suelen ms cortas. Las estrategias son seleccionadas para mo-
ver a la empresa hacia sus metas y son implementadas por la tcticas que
deben ser seleccionadas para asegurar que se cumplen los objetivos.
Strategy (Estrategia):
Es un plan o aproximacin para soportar la Misin y alcanzar los Ends.

Particularmente con foco en los Goals.
Tactics (Tcticas):
Especficos, acciones a corto plazo que soportan las estrategias. Las Tc-
ticas normalmente se centran en los objetivos.
Directives (Directivas):
Definen restricciones o requerimientos en cmo debemos dirigir nuestro

negocio. Incluyen Policies y Rules.
210
Business Policies (Polticas de Negocio):
Reglamentos de alto nivel. Existen para gobernar, controlar, guiar y dar

forma a las Estrategias y Tcticas definiendo que se puede hacer y los lmi-
tes de lo que se puede hacer.
Rules (Reglas):
Reglas o Restricciones especficas en las operaciones de nuestro nego-

cio. Deben ser concretas y derivadas de las Business Policies.
Influencers (Influenciadores):
Fuentes u orgenes de efectos que deben ser considerados en Asses-

ments y planificados, pues afectan a la empresa. Los Influencers pueden
afectar a la direccin del negocio positiva o negativamente, pero no tiene
accin directa o control. Son las cosas que pueden suceder en el entorno de
la empresa y pueden tener un impacto sobre la misma y que pueden incluir
tendencias, competidores, activos o hbitos de la empresa. Una empresa
puede tener cientos de Influencers potenciales, por lo que no podremos
tenerlos todos en cuenta y deberemos seleccionar aquellos con mayor po-
tencial de acontecer y que ms relevancia tengan sobre nuestras tcticas y
estrategias, metas y objetivos de negocio.
Estos Influencers pueden ser Internos (de dentro de la empresa; recur-

sos, calidad, infraestructura, hbitos) o Externos (de fuera de la empresa;
clientes, mercados regulaciones, competencia).
211
Internal Influencing:
Cosas dentro de la empresa, como la cultura, actitudes, infraestructura,

creencias y capacidades que influencian la direccin del negocio.
External Influencing:
Pueden ser de una gran variedad como competidores, clientes, reglas

gubernamentales o tecnolgicos. Los cambios en estos influencer pueden
tener un gran impacto sobre la empresa, en las oportunidades de negocio o
la viabilidad de la empresa.
Influencing Organization:
Una organizacin externa que puede afectar a nuestra empresa.
Assessments (Valoraciones):
Potential
Assessment Influencer
Risk
Potential Reward
Assessment
Se encarga de la evaluacin de los impactos (positivos o negativos) y fac-

tores que pueden influir en la empresa. Los Influencers, junto con las estra-
tegias, tcticas y planes de transformacin, son entradas a estos Asses-
ments para su evaluacin y consideracin. Un Assesment determinar el
potencial impacto de los Influencers, que incluirn evaluaciones de riesgos
y recompensas potenciales. Los Assesment se basan en un juicio acerca de
la influencia en la empresa de los Influencers y a menudo son asesorados
por herramientas de Business Intelligence, SWOT y de anlisis de riesgos.
Las salidas de estos Assesments son decisiones acerca de los Ends y los
Means.
212
Potential Influencer:
Captura el resultado de los Assesments potenciales considerando sin son

para ganar o perder.
Risk:
No todos los Influencers que afectan a las metas o estrategias de la em-

presa pueden considerarse oportunidades. Una amenaza o Threat puede
ser como una oportunidad pero que puede ser negativo para la empresa,
un Threat juzga un Influencer sobre como el Influencer puede afectar al
negocio. La empresa reconoce un Influencer y juzga si este es un Threat. Un
influencer es simplemente algo que puede estar pasando pero las oportu-
nidades Threats (amenazas) son juicios acerca de cmo un Influencer afecta
a la empresa.
Potential Reward:
Son situaciones favorables para nuestros negocios para alcanzar sus ob-
jetivos y que pueden ser explotadas para alcanzar estos objetivos.
Assessment:
Amenazas y oportunidades son muy parecidos, ambos son juicios. Un

juicio es una evaluacin de un Influencer que puede afectar a la empresa.
Los Assessments pueden ser SWOT (Stregth, weakness, opportunity, threat)
por lo que usaremos con frecuencia este anlisis. Strengths y Weaknesses
son internos a la organizacin. Un influencer interno puede ser juzgado
como Strength si ayuda a la organizacin a alcanzar sus metas y estrategias
o Weakness si no lo hace.
El BMM y los estndares vistos en este captulo, nos servirn para eva-
luar nuestra empresa y comprobar cmo se encuentra la misma ahora,
como podra ser en cuanto a su arquitectura estratgica y las transforma-
ciones que podemos llevar adelante para la mejora de su propuesta de
valor y los riesgos que podemos tener en el camino.
213
214
Captulo 6. Modelado de procesos. BPMN
Captulo 6. Modelado de procesos.

BPMN.
Tal vez una de las partes ms atractivas de BPM y de las plataformas

BPMS ms concretamente, sea la capacidad de reducir el distanciamiento
existente entre los requerimientos de negocio y los de desarrollo de soft-
ware a travs de una notacin de modelado de procesos de negocio comn
y fcilmente entendible, tanto para los perfiles de negocio como los de TI.
Esta notacin es BPMN (Business Process Model Notation), que integrada
en la gran mayora de soluciones BPMS, nos permitir modelar y ejecutar
los procesos de negocio para su posterior monitorizacin y control en un
entorno grfico.
Una vez vistos los distintos modelos para la definicin de la estrategia y

los modelos de negocio, pasamos al modelado de procesos, los cuales des-
cribirn como debern ser realizadas las distintas tareas necesarias para la
ejecucin del proceso, la secuencia de ejecucin de las mismas, qu trabajo
ser preciso realizar, con qu sistemas deber integrase para su funciona-
miento y cundo y quin realizar ese trabajo. Este modelo de procesos
ser fundamental para comunicar a la organizacin y especialmente a los
trabajadores que trabajarn sobre el proceso, cmo se deber realizar el
trabajo especificado en el diseo.
Para coordinar esta secuencia de tareas, procesos y mensajes fluyendo

entre distintos agentes y participantes, se ha diseado BPMN, una notacin
215
especfica para el modelado de los procesos de negocio, que describe la

lgica de los pasos dentro de un proceso de negocio. BPMN provee de una
notacin comn para que las personas relacionadas con los procesos pue-
dan expresarlos grficamente de una forma ms clara, estandarizada y
completa, facilitando no slo la estandarizacin de los procesos dentro de
la organizacin, sino que adems, ampla el campo de accin para que estos
puedan ser compartidos y entendidos entre los diferentes socios de nego-
cio y perfiles de la empresa tanto tcnicos como de negocio.
El estndar BPMN fue publicado en el ao 2004 por el Business Process
Management Initiative (BPMI) y posteriormente adoptado por el OMG co-
mo especificacin en el ao 2006, habiendo sido adoptado como estndar
por todo tipo de organizaciones y fabricantes de software.
El modelado de procesos es una de las bases y caractersticas fundamen-

tales de los proyectos de BPM. Durante los ltimos aos se han realizado
grandes esfuerzos para consensuar una notacin o lenguaje de modelado
capaz de describir los requisitos de negocio y que a la vez fuese trasladable
a sistemas informticos para su ejecucin. Dos estndares parecen haberse
posicionado como estndares para esta misin: BPMN y BPEL, los cuales se
han convertido en estndares usados por prcticamente todos los fabrican-
tes de soluciones BPMS. De esta forma, BPMN es un lenguaje formal que
permite modelar, simular y eventualmente, ejecutar procesos de negocios.
Su sintaxis est basada en elementos grficos, pero tales elementos tienen
una relacin uno a uno con instrucciones del lenguaje BPEL, lo cual permiti-
r generar cdigo ejecutable BPEL a partir de un modelo en la notacin
BPMN as como modificar este cdigo haciendo uso del modelado grfico
en BPMN.
Una vez analizados y entendidos los procesos de negocio que operar
nuestra organizacin, el lenguaje BPMN nos ayudar a expresar formalmen-
te los procesos y describir los mismos segn el grado de detalle que se re-
quiera. Aunque su principal objetivo es ser simple y fcil de usar tanto para
gente de negocio como tcnica, BPMN nos permitir expresar procesos
complejos y poder ejecutarlos directamente en una solucin BPMS hacia un
lenguaje ejecutable como BPEL.
Otras notaciones para modelar procesos de negocio son:
- Redes de Petri: es el lenguaje de modelado ms antiguo. Son la

base formal y matemtica sobre la que se asienta BPMN. Las re-
216
des de Petri pueden ser ejecutadas y existen diversas tcnicas

para analizarlas.
- YAWL (Yet Another Workflow Language): es un lenguaje de
modelado y un software open source de workflow.
- EPC (Event-Driven Process Chains): es la notacin soportada por
fabricantes como ARIS y SAP R/3. EPC cubre un subconjunto de
BPMN y YAWL, pero usa una notacin grfica dedicada.
Niveles de Uso en BPMN.
- Nivel 1. Descriptivo: usado para comunicar procesos a travs de

la organizacin. Esta descripcin de alto nivel, describe los flujos
esenciales del proceso de negocio ignorando complejidades e
incluso las reglas de negocio.
- Nivel 2. Analtico: describe todas las actividades, decisiones y ex-
cepciones necesarias para analizar un proceso completamente y
crear requerimientos detallados. Expresar toda la lgica de ne-
gocio y las reglas de negocio.
- Nivel 3. Ejecutable: modelar a este nivel depende mucho de las
capacidades del BPMS que utilicemos. Actualmente para ejecu-
tar se utiliza el lenguaje BPEL.
Elementos principales de BPMN.
NOTA: al igual que hicimos con BMM, para la descripcin de la notacin

BPMN, hemos preferido mantener las siglas en ingls utilizadas en la especi-
ficacin del BPMN por OMG, incluyendo entre parntesis su traduccin re-
comendada por BPMteca.com.
Para la representacin de la notacin BPMN se han utilizado los smbolos

de Bizagi Process Modeler, una herramienta de modelado de procesos gra-
tuita que forma parte de la plataforma de BPMS de Bizagi.
Los elementos principales que usaremos para diagramar nuestros

modelos de procesos en BPMN son:
- Flow Objects (objetos de flujo): que sern los elementos princi-

pales del diagrama.
217
o Event (evento)
o Activity (actividad)
o Gateway (compuertas de decisin)
- Connecting objects (objetos de conexin): elementos de comu-
nicacin entre objetos de flujo.
o Sequence flow (flujo de secuencia)
o Message flow (flujo de mensaje)
o Association (asociacin)
- Swimlanes (canales): para organizar los procesos.
o Pool (contenedor)
o Lane (calle)
- Artifacts (artefactos): para documentar el modelo.
A continuacin pasamos a describir en detalle cada uno de estos

elementos acompandolos de ejemplos sencillos sobre su uso.
Flow Objects (Objetos de Flujo):
Son los elementos que definen el comportamiento bsico de los proce-

sos.
Eventos:
Event Algo que ocurre durante el proceso de

(Evento) negocio. Los eventos afectan al flujo del pro-
ceso y suelen tener una causa (trigger) o un
impacto (resultado) y se representan con un
crculo. Todo proceso de negocio tiene un
principio y un fin. Todos los procesos co-
mienzan con un evento de Inicio y finalizan
con un evento de Fin, entre los cuales ocu-
rren todas las actividades con las que cuente
el proceso. Tambin pueden existir eventos
intermedios, generalmente asociados a re-
trasos. Los eventos tienen descripciones de
los mismos y atributos como por ejemplo de
qu manera son iniciados. Los eventos de
Inicio generalmente se inician con la recep-
218
cin por parte del evento de un mensaje.
De acuerdo con el momento en que los eventos afectan al flujo en

BPMN disponemos de tres tipos de eventos: inicio, intermedio y fin:
Evento de Para indicar cuando comienza el proceso y

Inicio se inicia su flujo y activacin. Se representa
por un crculo con una sola lnea. Ningn flujo
puede llegar a un evento de inicio. Existen seis
tipos de eventos de inicio que pueden iniciar
un proceso.
Evento Un evento que ocurre entre el inicio y le fi-

intermedio nal del proceso y que se representa por un
circulo con dos lneas. Los eventos interme-
dios indican donde ocurre algo durante la
ejecucin del proceso y afectan al flujo del
proceso.
Evento Indica donde finaliza el proceso y se repre-

de fin senta por una lnea gruesa. Los eventos de fin
no tiene ninguna salida de flujo y son usados
adems de para indicar el final de un proceso,
para enviar un mensaje.
Actividades:
Las actividades representan trabajo o tareas realizadas por miembros de

la organizacin, las cuales pueden ser manuales o automticas, realizadas
por un usuario o por un sistema externo. Una Actividad es un pieza de tra-
bajo que tiene un principio y un final, es realizada una o varias veces en un
proceso y normalmente son pasos de un proceso de negocio mayor.
Las actividades muestran un nombre y opcionalmente el tipo de activi-

dad de que se trata. Toda actividad tiene atributos que describen los deta-
lles del trabajo que realizan, como puede ser la descripcin de la actividad,
el tiempo que se necesita para completar la actividad, si puede tener re-
219
trasos o tiempos de espera, la persona que realizar la actividad, el coste de

ejecutar la actividad, si es ejecutada por un software, etc.
Una actividad puede ser atmica o compuesta. Los tipos de actividades

que tenemos son: Procesos, Sub-procesos y Tareas.
Activity or Actividad o tarea simple uti-

Task lizada cuando el trabajo que
(Actividad o representa en el proceso no
Tarea)
puede desglosarse en un nivel
mayor de detalle o unidades
ms pequeas. Estas tareas son
realizadas por humanos y tie-
nen que ser realizadas en una
determinada cantidad de tiem-
po.
Automatic Desarrollada por un ordena-

Activity (Ac- dor, programa informtico o
tividad Au- web service.
tomtica)
Receive Task Es una tarea simple para que

(Tarea Reci- llegue un mensaje. Una vez que
bir) el mensaje es recibido la tarea
es completada.
Tambin existe la tarea en-

viar (send task), para el envo de
mensajes y una vez enviados la
actividad est completada.
User Activity Desarrollada por una perso-

(Actividad na.
Usuario)
220
Manual Task Desarrollada por una perso-

(Tarea Ma- na manualmente, por ejemplo,
nual) archivar informes manualmen-
te.
Script Task Es una tarea que ejecuta una

(Tarea Cdi- pieza de cdigo en un lenguaje
go) definido.
Rule Task Tarea de Reglas de Negocio.

(Tarea Regla) Es una tarea que verifica una
regla de negocio del proceso.
Sub Process Es un conjunto de activida-

(Subproceso) des incluidas dentro de un pro-
ceso. Puede desglosarse en
diferentes niveles de detalle
denominados tareas. Los su-
procesos, son actividades des-
compuestas dentro del proceso
que usamos para organizar y
simplificar los modelos.
Algunas actividades son bas-

tante simples y no requieren de
demasiado detalle sobre su
implementacin, pero si que-
remos extender una actividad,
de forma ms detallada por su
complejidad lo podemos hacer
con subprocesos que pueden
ser descritos como procesos.
Los subprocesos se distin-

guen de las actividades por te-
221
ner un signo + que nos indica

que la actividad se pude des-
componer y pulsando sobre el
signo nos desplegara el proceso
completa que encierra en deta-
lle.
Sub Process Representan un grupo de ac-

Ad Hoc tividades en un subproceso que
(Subproceso no tienen relacin entre ellas,
ad hoc)
son actividades aisladas que el
responsable de ejecutarlas de-
cide como se llevarn a cabo.
Veamos un ejemplo de cmo usar los subprocesos:
Y el mismo proceso con el primer subproceso desplegado:
Niveles de Precisin:
Segn hemos visto en los niveles de uso de BPMN al principio del captu-
lo, a la hora de modelar los procesos solemos empezar con actividades de
alto nivel, para luego ir bajando hacia mayores niveles de detalle. Por ejem-
plo es normal comenzar un modelado a alto nivel representando subproce-
sos que luego vamos desplegando para indicar el nivel de detalle de cada
uno de ellos, o representar en un primer modelo los Pools sin detallar las
actividades de los mismos que luego detallaremos.
222
Gateways
Los gateways (o compuertas de decisin), los usamos para modelar al-

ternativas en el flujo de secuencia del proceso dependiendo de una condi-
cin. Se representan por un diamante y se emplean para controlar la diver-
gencia o convergencia de la secuencia de flujo que determinarn bifurca-
ciones, combinaciones y fusiones en el proceso. Existen varios tipos y com-
binaciones para estos gateways, pero los dos tipos ms simples y usados
que veremos ahora son:
Gateway Donde slo una de las alternativas

Exclusive puede ser escogida. Equivalen a la
Decisin sentencia lgica OR.
(Compuerta
Decisin
Exclusiva)
Gateway Donde todas las opciones deben ser

Pararellel activadas. Todos los flujos que salgan
Decision deben ser realizados para que el pro-
(Compuerta ceso pueda continuar. Estos gateways
Decisin se usan para sincronizar los flujos
Paralela) cuando todos los brazos o caminos
deben ser realizados antes de la si-
guiente actividad y equivalen a la sen-
tencia lgica AND.
El modelo para representar un Gateway exclusivo en el que slo una de

las alternativas debe ser escogidas es de la siguiente forma:
223
Veamos un modelo para el Gateway paralelo en el que los dos caminos

deben ser escogidos y ambos deben finalizar para poder continuar el proce-
so. Este modelo de Gateway paralelo puede ser expresado de las dos for-
mas que mostramos a continuacin y ambas son equivalentes, sin embargo
muchas herramientas de modelado consideran una buena prctica el usar
la notacin con el diamante para este tipo de flujos.
El Gateway paralelo podemos usarlo tambin para realizar sincroniza-

cin de tareas, como en el siguiente modelo:
224
Conecting Objects (Objetos de Conexin):
Que usaremos para conectar los Flow Objets. Estas conexiones pueden
ser de tres tipos:
Sequence Flujo de secuencia para indicar el

Flow (Flujo orden de las actividades que sern
de Sequen- realizadas en el proceso. Es la co-
cia)
nexin ms comn para representar la
secuencia entre dos Actividades y
mostrar que una es realizada antes
que otra. Este flujo se representa co-
mo una lnea slida con una flecha.
Message Para mostrar el flujo de mensajes

Flow (Flujo entre los participantes en el proceso.
de Mensaje) Estos flujos de mensajes sern los
nicos medios de comunicacin entre
los participantes o entre procesos en
diferentes pools.
Association Para asociar informacin a travs

(Asociacin) de los Artifacts (texto y otros objetos)
a los objetos de flujo y proporcionar
informacin adicional sobre distintos
puntos del proceso.
Ahora que disponemos de los principales elementos con los que mode-
lar procesos, podemos mostrar un ejemplo del uso conjunto de los mismos
para describir un proceso simple de recibir un pedido, realizar el trabajo y
decidir si lo enviamos al cliente o este lo recoge en nuestra tienda:
225
En el cual tenemos un evento de inicio, un flujo de proceso que sale de

este a la tarea de recibir el pedido, del cual sale a un Gateway exclusivo
(uno u otro, pero no los dos a la vez), en el cual se toma la decisin de si el
pedido se enva al cliente o se recoge en la tienda, por lo que salen dos po-
sibles flujos del proceso y finalmente, tenemos un evento de fin con el cual
concluye el proceso.
Veamos ahora el mismo ejemplo con un Gateway paralelo, donde para

finalizar el proceso se debe enviar el pedido y la factura al cliente:
En este caso, para que el proceso pueda finalizar, las dos actividades que
salen del Gateway (Enviar pedido y Enviar factura) deben ser realizadas
y finalizadas de forma que el proceso no finaliza hasta que ambas son com-
pletadas.
Podemos ver otro ejemplo en el que combinamos los dos tipos de Ga-
teway (exclusivo y paralelo) en el caso de un proceso para el procesamiento
de pedidos:
226
En este ejemplo, una vez recibimos el pedido, tenemos un Gateway en el

que decidimos si se acepta o no el pedido. Si el pedido es aceptado, prepa-
ramos el mismo, tras lo cual el flujo despus de esta actividad se divide en
dos, por un lado enviamos el pedido y por otro enviamos factura y realiza-
mos el cobro. Slo cuando estos dos caminos se han completado en el Ga-
teway paralelo puede continuar el proceso para el cierre del pedido.
Swimlanes (Canales):
Que usaremos para agrupar los elementos del proceso mediante Pools y
Lanes.
Pool Representan un proceso desde el

punto de vista de un participante en el
mismo (generalmente una empresa) y
es un contenedor de las actividades que
esa empresa realiza. Los Pool represen-
tan todo el proceso.
Lane Los Lanes en el proceso de negocio

representan los roles de las personas u
organizaciones que realizan las activida-
des.
Es una particin dentro de un Pool

(grficamente puede ser vertical u hori-
zontal) y los usamos para organizar y
categorizar las actividades en roles o
departamentos. Grficamente un mode-
227
lo de proceso de negocio muestra quien

realiza las actividades. Cada Rol que
realiza estas actividades tiene un Lane.
Algunas veces las actividades dentro de un proceso deben interactuar

con otros procesos, las interacciones entre estos procesos las modelamos
usando Pools. Un Pool es un contenedor de procesos que contiene activi-
dades, eventos y gateways. Los Pools son como los Lanes, excepto que los
Pool pueden contener Lanes.
Veamos el uso de un Pool que engloba todo un proceso con los Lanes
dentro del mismo para indicar que hace cada uno dentro del proceso:
En este ejemplo una incidencia en un producto es recibida y registrada

por el servicio de atencin al cliente, si el problema es conocido, se comuni-
228
ca al cliente y finaliza el proceso. Si el problema no es conocido, se enva al

departamento tcnico que identifica el problema y si este es conocido se
documenta y si no lo es, se recurre a soporte tcnico.
Veamos ahora otro ejemplo para un proceso de solicitud de vacaciones

que el lector podr interpretar fcilmente por s mismo:
Artifacts (Artefactos):
Son usados para proporcionar informacin adicional acerca del proceso,

aunque no afectan al flujo de estos. Existen tres tipos estndar de Artifacts,
pero podemos aadir tantos como sean necesarios para aportar esa infor-
macin adicional aunque no recomendamos esta prctica.
Data Proveen de informacin acerca de

Objects documentos y datos.
(Objetos
de Datos)
Groups Proporcionan una relacin visual de

(Grupos) un conjunto de actividades.
229
Text Proporciona informacin adicional

Anotation del modelo. Es un texto aadido para
(Anotacin ayudar a comprender alguna parte o
textual)
actividad del proceso.
Hasta aqu hemos descrito los elementos bsicos de BPMN. A continua-

cin ampliaremos distintos elementos y tcnicas de modelado.
Event Type Message (Mensaje Tipo Evento):
Son eventos de inicio como los vistos anteriormente pero asociados al

intercambio de mensajes. Su principal uso es para establecer las comunica-
ciones con los participantes del proceso que estn fuera del mismo (en
diferentes Pools) para lo que disponemos de los eventos de tipo mensaje y
distinguimos entre mensajes recibidos y enviados. Los eventos de mensaje
indican una comunicacin sin especificar si esta es por va telefnica, mail o
verbal.
Start Recibe el mensaje y se inicia el proce-

Message so.
(Mensaje
de Inicio)
End Se enva el mensaje y se acaba el pro-

Messsage ceso.
(Mensaje
de Fin)
Debemos tener en cuenta un punto muy importante: que la comunica-

cin entre Pools es siempre y nicamente a travs de mensajes. Veamos un
ejemplo de esta comunicacin:
230
En este ejemplo vemos la comunicacin entre Pools a travs de mensa-

jes (Message Flow). Cada reclamacin de incidencia de un cliente inicia el
proceso en la empresa. El proceso termina cuando la incidencia es resuelta
y enviada al cliente. El subproceso Gestionar incidencia desplegado, bien
podra ser el ejemplo usado anteriormente.
Una buena prctica de modelado es que cuando comencemos un proce-

so con un mensaje de un cliente finalicemos tambin con un mensaje a
este.
Veamos ahora otro ejemplo en el que usaremos algunos Artifacts para

documentar el proceso y comunicacin a travs de mensajes entre distintos
Pools:
231
En este ejemplo vemos como el proceso en el Dept. de RR.HH se inicia

con la llegada de un mensaje que incluye un CV (Curriculum Vitae) el cual es
visto por el personal del departamento que decide si es aceptado o no. En
las dos salidas del Gateway, tanto si el CV es aceptado como si no, se inclu-
ye un evento intermedio de mensaje al candidato, tras lo cual finaliza el
proceso. En este ejemplo adems hemos aadido dos Artefactos de texto
para documentar el envo de los mensajes de aceptacin o denegacin.
Otro ejemplo parecido puede ser el siguiente entre un profesor y sus

alumnos para recomendar libros de lectura, que el alumno haga un resu-
men de los mismos, el profesor comente el resumen, el alumno lo mejore y
finalmente el profesor asigne una nota. A travs de todo el proceso ten-
dremos dos Artifacts de Objetos de Datos para indicar el libro y el resumen:
Event Type Timer (Temporizador Tipo Evento):
Timer Para los eventos de tipo Timer, slo te-

(Tempo- nemos evento de inicio e intermedio pero
rizador) no de finalizacin, estos ltimos no estn
permitidos en BPMN, por lo que slo po-
dremos recibir un evento de tipo de Ti-
mer.
Un Evento de inicio Timer inicia a una

hora y fecha especificada un proceso de
forma automtica
232
Veamos un ejemplo de evento tipo Timer:
En este caso el proceso se inicia el da 2 de cada mes, por lo que se inicia

el subproceso de generar facturas y finaliza el proceso con el envo de la
factura al cliente.
Tipos de Modelos BPMN:
Private (Privado):
Procesos internos dentro de una organizacin. Cada proceso est dentro

de un nico Pool.
Abstract (Abstracto):
Procesos pblicos que incluyen interacciones entre un proceso del tipo

Private y otros procesos o participantes y en el que slo vemos las activi-
dades del proceso privado y las comunicaciones con otro proceso, pero sin
saber que realiza este otro proceso internamente.
233
Collaboration (Colaboracin):
Procesos globales. Todos los procesos son visibles y todo el mundo sabe
lo que hacen los dems.
BPMN ANALTICO:
Hasta aqu hemos visto los elementos principales de BPMN. Ahora ve-
remos BPMN en mayor detalle, pasando al BPMN analtico en el que des-
cribiremos en detalle los procesos, todas las actividades, decisiones y ex-
cepciones que puedan ocurrir en el proceso.
Start Events (Eventos de Inicio):
Evento de inicio sin especificar.
234
Message (Mensaje):
Un mensaje llega de un participante.
Timer (Temporizador):
Un ciclo de una hora o fecha especfica, por ejemplo:

todos los das a las 16:00 h, a la que se activar el proce-
so.
Conditional (Condicional):
Lanzado cuando una determinada condicin es verda-

dera.
Parallel (Paralelo):
Evento de inicio paralelo. Este evento crea e inicia una

instancia de un proceso por todos los eventos de inicio
definidos.
Signal (Seal):
Una seal es difundida por otro proceso para que to-

dos los procesos puedan usarla para arrancar. No es un
mensaje.
Multiple (Mltiple):
Existen mltiples formas de lanzar el proceso y slo

una de ellas ser necesaria para lanzarlo.
235
End Events (Eventos de Fin):
Evento de fin sin especificar.
Message (Mensaje):
Un mensaje se enva a un participante.
Error (Error):
Un error debe ser generado y este debe ser recepcio-

nado por alguien.
Signal (Seal):
Se lanza una comunicacin.
Terminate (Terminador):
Todas las actividades del proceso deben finalizar in-

mediatamente.
Multiple (Mltiple):
Mltiples sucesos de finalizacin del proceso. Todos

ellos deben ocurrir. Por ejemplo: avisar al cliente, al pro-
veedor y enviar factura a cliente.
236
Eventos Intermedios:
Los eventos intermedios se encuentran entre los eventos de inicio y final

del proceso. Los eventos intermedios pueden esperar por algo (por ejem-
plo a recibir un mensaje) o lanzar algo (enviar un mensaje).
Espera Lanza
Message (Mensaje):
Usado para esperar por un mensaje que

debe llegar o para enviar un mensaje a un
participante.
Timer (Temporizador):
Usado para retrasar el flujo del proceso

hasta una hora y fecha especficas. Como
vemos no tiene lanzador, pues el tiempo
pasa independientemente de lo que haga.
Error (Error):
Se usa siempre en el borde de una acti-

vidad para recoger un error generado de-
ntro de otra actividad o subproceso.
Conditional (Condicional):
Lanzado cuando una determinada con-

dicin es cierta.
Signal (Seal):
Usado para esperar por una seal

cuando lo ponemos en el borde de una
actividad o para lanzar una seal.
237
Multiple (Mltiple):
Usado para esperar cuando lo ponemos

en el borde de una actividad (y slo una
condicin es suficiente para lanzarlo) o
para lanzar mltiples consecuencias.
Link (Enlace):
Usado como un go to (ir a) para co-

nectar dos secciones de un proceso o entre
pginas de un proceso cuando no todo el
diseo del proceso entra en una sola pgi-
na.
Veamos un ejemplo de evento intermedio del tipo Timer:
En este ejemplo vemos un proceso para recordarnos que debemos en-

viar un informe de ventas en el cual si la actividad elaborar informe de
ventas se realiza en menos de 7 das, el evento intermedio Timer no es
activado y no se ejecuta la actividad enviar recordatorio, pero si la tarea
no se realiza en 7 das, entonces se activa la ruta de excepcin y el recorda-
torio es enviado.
238
Ejemplo de evento intermedio de Error:
En este ejemplo, si la actividad Recibir harina se completa antes de 8

horas no se activa la ruta de excepcin, sin embargo si la harina no se recibe
antes de las 8 horas necesarias para realizar la actividad Fabricar pan,
entonces se activa la ruta de excepcin y se prosigue con la actividad Noti-
ficar a proveedor.
Ejemplo de evento de Error o Excepcin:
En este caso vemos una excepcin de negocio como es el que la tarjeta

sea rechazada por la entidad bancaria y el pago no pueda realizarse nor-
malmente y en consecuencia se activa la ruta de excepcin generando el
error.
239
Ejemplo evento Mltiple:
En este ejemplo, el proceso se inicia con un evento mltiple que puede

ser iniciado todos los meses o a peticin de la Direccin y como se trata de
un evento mltiple, con el solo cumplimiento de una de las condiciones, se
activar el proceso. Este evento mltiple lo documentamos con un Artefac-
to de Texto, al igual que el evento mltiple de fin, para expresar que accio-
nes se llevarn a cabo.
Ejemplo evento Signal:
En este ejemplo, cuando entra un nuevo coche para ser reparado, el sis-
tema lanza una seal. Esta seal es recibida para proceder al envo de pie-
zas para la reparacin del coche.
240
Decision Gateways (Compuertas de Decisin):
Exclusive Basado en eventos, slo uno de las

(Exclusivo) rutas asociada con el evento ser acti-
vada. El comportamiento para las
entradas en este Gateway es el mismo
que en el Gateway exclusivo normal,
pero en las salidas, la decisin est
basada en eventos que ocurren en ese
punto del proceso, generalmente en
funcin de mensajes que llegan a es-
tas rutas de salida y determinan cual
de las rutas se seguir. Por ejemplo si
la respuesta que llega de un cliente es
Si o No.
Inclusive or Todas las alternativas o ninguna de

Conditional las alternativas deben ser considera-
(Inclusivo o das, sin embargo se debera marcar
Condicional)
alguna como la opcin por defecto,
pues si ninguna de las condiciones es
verdadera, el modelo se considerar
No Vlido.
Complex Usada en situaciones complejas

(Complejo) cuando varias alternativas deben ser
combinadas.
241
Ejemplo de uso de eventos intermedios para un proceso tpico de toma

de decisin basada en Eventos:
En este ejemplo, una de las tpicas situaciones para gestionar respues-

tas, hacemos uso de la decisin exclusiva basada en eventos para decidir
qu hacer en funcin de los diferentes tipos de respuesta que podamos
obtener.
En el punto 1: si llega mensaje de aceptacin se prepara el pedido y fina-

lizamos el proceso.
En el punto 2: si llega mensaje de denegacin analizamos las causas de la

no aceptacin y finalizamos el proceso con el envo de un mensaje a al-
guien.
En el punto 3: si pasan ms de 7 das y no tenemos respuesta de acepta-

cin o denegacin decidimos que hacer y finalizamos tambin con un even-
to de finalizacin tipo mensaje.
Veamos otro ejemplo en el que solicitamos ofertas a tres proveedores

distintos y escogemos la del primero que responda, pero en este caso, su-
pongamos que nos importa ms el tiempo de respuesta que otras caracte-
rsticas de la oferta. En este ejemplo haremos uso de dos tipos de Gatways,
el paralelo y el basado en eventos.
242
Flujo por defecto y condicional:
Flujo por Se escoger un camino si

defecto ninguno de los otros caminos
es verdadero.
Flujo Es un flujo de secuencia con

condicional una condicin que debe cum-
plirse para poder seguir ese
camino. Este flujo se represen-
ta con un pequeo diamante al
inicio. Si el flujo sale de un Ga-
teway, no se indica el diaman-
te, pues ya establecemos las
condiciones en el Gateway.
243
Ejemplo Decisin Condicional usando un Inclusive gateway:
En este ejemplo tenemos varias opciones que el cliente puede escoger

para configurar su mvil y en el que pueden ser activados varios caminos
segn los deseos del cliente. As mismo indicamos la opcin con cmara
como camino por defecto, mediante la raya en su flujo de secuencia, lo que
significa que si ninguna otra opcin es escogida, se escoge por defecto esta
y nos aseguramos de que el modelo sea vlido.
El Gateway inclusive o condicional es como vemos en el ejemplo ante-

rior usado tambin para sincronizar distintas rutas.
El modelo para el flujo condicional es equivalente al que hemos usado

en el Gateway Condicional, pero en el siguiente ejemplo, usamos el flujo
condicional para expresar las condiciones de cada uno de los posibles cami-
nos:
244
En el siguiente ejemplo, mostramos dos modelos equivalentes para ex-

presar una decisin condicional.
Loops (Bucles) y Multiple Instance (Instancia Mltiple):
Loop Un subproceso Loop, repite las

(Bucle) actividades varias veces. Los atri-
butos que indiquemos en el proce-
so determinan las condiciones de
las repeticiones. Tambin podemos
crear Loops conectando un flujo de
secuencia a un objeto predecesor.
Multiple Indica que una actividad es re-

Instance petida varias veces y se indica con
(Instancia unas rayas paralelas.
Mltiple)
245
Seguir el testigo (Token):
Los procesos diseados en BPMN haciendo uso de una herramienta de

BPMS se ejecutarn en el motor de procesos. Este motor de procesos segui-
r el flujo del proceso como un testigo que se ir pasando a travs de los
objetos de nuestro diagrama, desde el evento de inicio hasta el evento de
fin. Cuando el proceso comienza, se activan todos los caminos y el testigo
comienza a recorrer los caminos diseados hasta alcanzar el evento de fin.
Los procesos son iniciados manual o automticamente, pero requieren

de un lanzador (trigger, en ingls) de informacin, el cual es aadido o ma-
nipulado por el proceso hasta que este se completa. Algunas veces este
lanzador sern datos o actividades automatizadas por sistemas software,
otras acciones fsicas realizadas por una persona o un mail que recibimos y
otras veces sern acciones que ocurran durante la ejecucin del proceso.
Como ejercicio proponemos al lector seguir el testigo del siguiente

proceso colaborativo para un servicio de urgencias sanitarias.
Distintos tipos de Flujo:
Hasta aqu hemos visto los flujos normales de proceso, como el anterior
en los que seguimos el testigo (Token) de forma secuencial desde el even-
to de inicio a travs de las actividades y gateways hasta el evento de fin.
Este es el denominado Flujo normal de proceso y que podemos representar
de la forma:
246
Sin embargo podemos tener otros tipos de flujo que describiremos a

continuacin.
Exception Flow (Flujo de Excepcin):
Es el flujo que ocurre fuera del flujo normal del proceso y que suele ocu-
rrir debido a un evento intermedio que aparece durante el proceso. Estos
eventos intermedios, que usamos por ejemplo para esperar por un mensa-
je, los asociamos a una actividad o un subproceso, en el borde de la activi-
dad, crean una ruta de excepcin.
En este ejemplo creamos un evento intermedio que interrumpe el flujo

normal y el funcionamiento del proceso. Si en 2 das no pedimos los sumi-
nistros, entonces se activa la ruta de excepcin y tendremos que ir a la acti-
vidad Revisar Suministros.
Otro ejemplo de ruta de excepcin puede ser con un error:
247
En Este caso, cuando la actividad automtica genera un error, se invoca

la ruta de excepcin para generar manualmente la factura.
Transaction Subprocess (Subproceso de Transaccin):
Las transacciones son un tipo especial de subprocesos que aseguran que

todas las partes de un proceso de negocio sern completadas y si no es as
(no todas las actividades se completan de forma exitosa), todas sern can-
celadas y revisadas hacia atrs en el flujo. Las transacciones se usan cuando
diferentes partes del sistema (por ejemplo partners y proveedores) son
necesarios para completar las actividades del proceso.
Las transacciones estn basas en el principio de todo o nada de la ges-

tin de bases de datos. Deberemos finalizar todas las tareas con todo com-
pletado y si no es as deberemos deshacer todo lo realizado si alguna de las
partes no ha completado su parte. Nada debe quedar en una inconsisten-
cia.
Los subprocesos de Transaccin se representan como subprocesos pero

con doble lnea en los bordes.
Este proceso se realiza en combinacin con el Compensation Subprocess

y el Cancellation Event que veremos a continuacin.
248
Compensation Subprocess (Subproceso de Compensacin):
Describe las acciones que se deben realizar cuando una actividad de una
Transaccin debe ser cancelada. Es como el deshacer, que genera un
movimiento de compensacin. Estas compensaciones podramos hacerlas
sin usar el mecanismo de compensacin que describiremos, pero tendra-
mos que llenar nuestro modelo con una cantidad enrome de gateways
tras cada una de las actividades.
Algunas actividades producen efectos o salidas complejas. Si estas sali-

das pueden tener efectos no deseados como pueda ser una cancelacin,
entonces ser necesario deshacer las actividades realizadas hasta ese
punto, que es lo que denominamos compensacin.
Una actividad que pueda necesitar compensacin necesitar de una ac-

tividad aparte que ser usada para almacenar los efectos de la actividad
inicial y que denominaremos la actividad de compensacin. Esta actividad
de compensacin no tendr ningn flujo de entrada ni de salida, ya que no
seguir el flujo del proceso, sino que ser una actividad aparte (de ah que
se asocie con la actividad que puede requerir de compensacin mediante
un flujo de asociacin y no de secuencia de flujo normal). En este caso aso-
ciamos un evento intermedio de compensacin al borde de la actividad
para indicar que una compensacin puede ser necesaria para esa actividad.
Para que una actividad pueda ser compensada, esta debe estar completa-
mente finalizada, no se puede producir la compensacin antes de que esta
finalice.
249
Ejemplo Transaccin:
En este ejemplo, supongamos que tenemos que reservar habitaciones

de hotel para varias personas y posteriormente aprobar el presupuesto
para estas habitaciones. Si se aprueba el presupuesto, finaliza el proceso,
pero si este no se aprueba entonces deberemos cancelar las habitaciones
que hemos solicitado y notificar al cliente las malas noticias.
Ejemplo de compensacin:
250
En esta transaccin de un Sistema de Reservas de vuelo y hotel, tene-

mos tres posibles finalizaciones:
1. Que se finalice normalmente la transaccin, en el ejemplo:

que haya disponibilidad de vuelo y de hotel, entonces la transaccin
transcurre de forma normal y se procesa la reserva.
2. Si alguna de las actividades Reservar Vuelo (punto 2) o
Reservar Hotel (punto 3) que pueden necesitar compensacin,
necesitan esta compensacin por no poder reservarse cualquiera
de ellas, entonces se cancelar la transaccin en el punto 4. Este
Evento intermedio de cancelacin slo puede ser usado en subpro-
cesos de transacciones y no en actividades o subprocesos normales.
Supongamos que se ha podido reservar el vuelo pero no el hotel, en
este caso ser necesario deshacer las dos actividades. El evento in-
termedio de compensacin asociado a las actividades Reservar Vue-
lo y Reservar Hotel, se utiliza para activar el flujo de excepcin. Por
ejemplo si se ha podido reservar el vuelo pero no el hotel el evento
de compensacin se activar y se activarn las actividades de la
compensacin para cancelar el vuelo y el hotel. Al compensar las
actividades del subproceso, el proceso principal no seguir el flujo
normal y se activar el evento intermedio de cancelacin una vez
finalizadas las actividades de compensacin y se habilita un flujo de
excepcin para el proceso principal.
3. Error en el punto 5. Esto quiere decir que algo ha ido mal y
que ni tan siquiera la cancelacin es posible. Cuando ocurre este
error, las actividades quedan interrumpidas sin compensacin y el
flujo continuar desde el evento intermedio de error.
Como vemos, el final de un subproceso de transaccin es muy diferente

de un subproceso normal, pues el subproceso transaccional debe verificar
que todos los participantes han completado sus actividades.
En la realidad, los modelos de procesos que modelemos, sern no ms

complejos que los casos vistos en este captulo, pero si mucho ms exten-
sos y en general, podemos decir que el 80% del trabajo en un proyecto de
BPM ser empleado en las tareas de realizar este modelado.
251
BPMN 2.0:
En Junio de 2010 el Object Management Group (OMG) lanz la nueva

versin BPMN 2.0. En este captulo hemos descrito los elementos de BPMN
1.1 y mostrado varios ejemplos sobre su utilizacin con los que el lector
puede manejar los principales elementos de BPMN para modelar sus proce-
sos. Aunque hemos introducido algunos de los principales elementos de la
versin 2.0, esta presenta algunos cambios significativos que describiremos
en este apartado.
En la nueva versin, BPMN 2.0, recogiendo demandas de la comunidad

de usuarios de BPMN, se recogen algunos nuevos elementos de actividades,
eventos y subprocesos para soportar tanto modelos de negocio generales
como verticales (seguros, finanzas, etc.). Los principales esfuerzos sin em-
bargo se han hecho en estandarizar esta notacin, que parece dirigirse en
un futuro cercano a poder ejecutar directamente desde BPMN de los mode-
los diseados. En este sentido, en esta nueva versin se encuentra el poder
hacer los diagramas directamente ejecutables en un motor de procesos.
Con la versin anterior de BPMN 1.1, trasladar un modelo de procesos de
una plataforma a otra pasaba por exportar el XML generado (BPEL, XPDL,
JPDL) a partir del modelo en BPMN, lo que implicaba tener que dibujarlo de
nuevo. En la nueva versin disponemos de un nuevo meta-modelo de inter-
cambio basado en diagramas de clases de UML para el intercambio de los
modelos BPMN que resuelve este problema.
Otra importante incorporacin en la nueva versin es la de un nuevo ti-

po de tareas, las Business Rule Task, que proporcionan un mecanismo en el
que se puede enviar o invocar y recibir datos de reglas de negocio estable-
cidos en un motor de reglas de negocio. Este nuevo tipo de actividades
representan unas tareas automatizadas que no realizan ninguna accin en
el modelo del proceso y slo devuelven el resultado de la regla de negocio
que ser usado dentro del flujo del proceso.
En la versin BPMN 2.0 se aaden algunos nuevos elementos adems de

los ya comentados, como un nuevo tipo de actividades, las Service Task,
como tareas que utilizan algn tipo de servicio como pueda ser un web
service o aplicacin, las Call Activities y algunos nuevos tipos de eventos.
Para una descripcin completa de esta nueva especificacin, el lector

puede recurrir a la pgina del OMG indicada al final del libro.
252
PARTE 3.
IMPLEMENTACIN DE BPM.
Cap. 7. Implementacin de BPM.

Cap. 8. BPMS (Business Process Management
Systems)
Captulo 7. Implementacin de BPM
Captulo 7. IMPLEMENTACIN DE BPM.
Como hemos visto, es a travs de los procesos como las organizaciones

realizan el trabajo especificado en la estrategia de la organizacin, agregan-
do valor a sus productos y servicios. Los procesos, tienen en consecuencia
un fuerte impacto en la eficiencia y los resultados de la empresa por lo que
stas deben analizar y mejorar continuamente sus procesos a travs de un
ciclo de vida que permita definir, ejecutar, monitorizar y optimizar sus pro-
cesos de negocio.
Este ciclo de vida en un proyecto de BPM seguir el siguiente camino

clsico:
255
- Definicin: donde se definen los modelos, mtricas y reglas de

los procesos. Esta fase requerir de la colaboracin entre el per-
sonal de negocio y de TI, as como hablar e intercambiar opinio-
nes con expertos sobre la materia y el proceso que estemos tra-
tando, recogiendo la especificacin de los procesos en una nota-
cin como BPMN, hasta alcanzar un modelo validado por todos.
En esta fase suele ser la gente de negocio la que domina en la
definicin, especificando lo que se debe hacer.
- Ejecucin: aunque la gente de negocio y de TI colaboran a lo lar-
go de todo el proyecto, en esta fase, la gente de TI implementa
la especificacin realizada en la fase anterior, implementndola
en un motor de procesos de un BPMS, el cual ejecutar y contro-
lar el flujo de los procesos, nos proveer de informacin sobre
cmo funcionan, su rendimiento, tiempos de ejecucin, donde
estn los cuellos de botella y los problemas, etc.
- Monitorizacin: donde tambin a travs de un BPMS, controla-
mos los procesos y asignamos alertas a eventos de estos para
controlar su funcionamiento para utilizar estos datos y medidas
de rendimiento en la mejora de nuestros procesos de negocio.
- Optimizacin: donde vemos, qu podemos hacer para mejorar
las cosas en una bsqueda contina de la excelencia de nuestros
procesos y bsqueda de ventajas competitivas, utilizando en es-
ta bsqueda la informacin de los datos y medidas de los proce-
sos recabados en la fase anterior para redefinirlos y volver de
esta forma de nuevo a la primera fase de definicin para conti-
nuar el ciclo.
Ciclo de aprendizaje y mejora continua.
En este captulo dedicado a la implementacin de BPM, usaremos las fa-

ses principales del ciclo clsico que acabamos de presentar, pero ampliando
el mismo para dar cabida a todas las fases y subfases que podemos realizar
en una implementacin completa de BPM, en un ciclo que denominamos
de aprendizaje y mejora continua de procesos. Este ciclo es el representado
en la siguiente grfica.
256
A continuacin describimos brevemente cada una de estas fases que

ampliaremos y detallaremos en el resto de este captulo.
1. Entorno de negocio. Partiendo del modelo de negocio, de la es-

trategia, del Business Motivation Model (BMM) y de la arqui-
tectura empresarial, desarrollaremos las metas y objetivos de
negocio que deben cumplir nuestros procesos.
2. Levantamiento de procesos. Conocer el As-Is o como son los
procesos actuales de la organizacin, para lo cual realizaremos
el levantamiento de procesos para realizar el inventario de los
procesos existentes en la empresa, identificaremos los proble-
mas y requisitos de estos, los modelaremos, identificaremos las
medidas asociadas a estos procesos y documentaremos para
proceder a ordenarlos por importancia y clasificarlos en funcin
de su impacto y valor que aportan a la organizacin.
3. Datos y reglas de negocio. Sobre los procesos seleccionados in-
troduciremos datos e informacin asociada a los mismos as
como las reglas de negocio que rigen su comportamiento.
4. Mejora de procesos. Realizar el To-Be, o como deberan ser los
procesos, rediseando los procesos, para lo que emplearemos
diversas tcnicas de mejora de procesos.
5. Medidas, indicadores y anlisis del proceso. Establecer medidas
e indicadores de negocio que nos permitan evaluar el compor-
tamiento y rendimiento de los procesos.
257
6. Simulacin. Simular la operativa de los procesos, para evaluar

su comportamiento y si las medidas e indicadores se ajustan a
los valores deseados para el proceso.
7. Implementacin. Desarrollar e Implementar el proceso redise-
ado en un entorno de desarrollo, comprobar el correcto fun-
cionamiento de las integraciones con sistemas transaccionales,
realizar pruebas de carga y estrs y testear el funcionamiento
del proceso.
8. Puesta en marcha del proceso, en un entorno de produccin.
9. Control del proceso y mejora continua, a travs de cuadros de
mando que nos permitan seguir y monitorizar el comporta-
miento y eficiencia del proceso en busca de mejoras en su ren-
dimiento.
Al tratarse de un ciclo, continuamos el mismo volviendo al punto 2, pues

los negocios cambian y en consecuencia, los procesos tambin, por lo que
debern ser de nuevo analizados pues pueden existir cambios tcticos o
estratgicos que afecten al proceso.
En la implementacin de este ciclo que acabamos de describir para una

implementacin de BPM, ser importante aprender a gestionarlo sin perder
nunca la bsqueda de la mejora continua de nuestros procesos y evitar
quedarnos en la zona de confort. Generalmente cuando hemos alcanzado
un nivel razonable de desempeo en alguna materia o proyecto, tendemos
a estancarnos, considerando que hacemos suficientemente bien las cosas y
nos instalamos en esa zona de confort en la cual consideramos que tene-
mos las condiciones suficientes para satisfacer nuestras necesidades y de-
jamos de espolearnos para ir ms all en la bsqueda de mejoras, de expe-
rimentar nuevas formas de hacer las cosas o evaluar nuevas oportunidades.
Consideramos aceptables los resultados alcanzados, nos fijamos slo en lo
que funciona, aprendemos slo de los xitos alcanzados y no de los fracasos
que pasamos por alto y nuestra capacidades y habilidades corren el riesgo
de quedarse obsoletas desplazndonos del mercado.
Esta actitud, la podemos ver reflejada en el diagrama del ciclo de vida

de implementacin de BPM que acabamos de dibujar, el cual debe ser visto
bajo una perspectiva de bsqueda continua de nuevas oportunidades para
nuestra empresa. En este grfico vemos como las lneas punteadas nos
indican que desde cualquier punto del ciclo de vida, podemos volver al pun-
to 2, para el modelado de los procesos, es decir, el ciclo de vida se debe
retroalimentar constantemente, recogiendo datos, analizndolos e imple-
258
mentando nuevas teoras de lo que funciona o de lo que no, y esta impor-

tante prctica es fcilmente realizable en las soluciones BPMS en las que
siempre podremos volver al modelado para modificar o corregir aspectos
del funcionamiento del proceso as como seguir las distintas versiones que
tengamos de los procesos para recuperar o modificar versiones anteriores.
Es decir, los BPMS nos permitirn chatarrear con los procesos, sin miedo
a incurrir en sobre-costos para poder implementar las soluciones experi-
mentales que consideremos.
A continuacin pasamos a describir las distintas fases de este ciclo de

BPM ms detalladamente.
Entorno de Negocio.
En esta primera parte del ciclo de vida de la implementacin de la ges-

tin de procesos y antes de capturar, definir y mejorar los procesos actuales
con los que opera la empresa nos aseguraremos de disponer de la visin, de
la estrategia, las metas y objetivos de negocio, de forma que todos los
miembros del equipo y stakeholders del proyecto dispongan de un claro
entendimiento de esta estrategia y objetivos as como del modelo de nego-
cio que guiar y sustentar el proyecto para lo cual podremos hacer uso del
Business Motivation Model (BMM) que vimos en el captulo 5.
Los proyectos son creados para crear valor, y si el proyecto no dispone

de esta propuesta de valor, no debera existir como proyecto. Como ya
hemos comentado al hablar de la estrategia, generalmente pasamos por
alto la definicin y desarrollo de la estrategia y de su propuesta de valor,
centrndonos en el anlisis de variables tcnicas y no de negocio y enfo-
cndonos desde las primeras etapas en las soluciones tcticas, con la inten-
cin de resolver los problemas cuanto antes. El seguir este camino rpido
en busca de la solucin y obviar la estrategia, provocar el que no seamos
capaces de resolver los problemas e ineficiencias en el medio y largo plazo,
por lo que siempre estaremos actuando a corto plazo, retocando los proce-
sos en una estrategia de apagar fuegos y desconociendo el origen ltimo
de los problemas e ineficiencias que observamos en nuestros procesos.
259
El enfoque de como realizamos la toma de requerimientos al trabajar

con procesos, es completamente distinto al utilizado en la perspectiva del
desarrollo software, en el que existe la tendencia a dirigirnos demasiado
rpidamente a la solucin tcnica. En BPM modelaremos los procesos des-
componiendo los mismos siempre a partir de la estrategia y del anlisis de
la cadena de valor de la organizacin, para desarrollar productos y servicios
que cumplan con los objetivos organizacionales. Aunque las metodologas
de ingeniera software han evolucionado hacia una orientacin a servicios,
las herramientas usadas como casos de uso y diagramas entidad-relacin
son slo comprendidas por personal tcnico y de TI de la organizacin, por
lo que no nos servirn a la hora de comunicar el proyecto al resto de miem-
bros de la organizacin y alcanzar el necesario acuerdo entre los miembros
de la organizacin que finalmente debern trabajar con los procesos y par-
ticipar en su mejora continua.
Muchas veces ocurre que los planes de empresa derivados del anlisis
del entorno quedan en el cajn del olvido pero no se siguen los mismos y
resultan en documentos estticos e inamovibles en aos. Con la disciplina
de BPM, tenemos la obligacin de ponerlos en marcha y ejecutarlos, pues
de su definicin y desarrollo partiremos para con el lenguaje de cuadrados,
flechas y rombos de los procesos, poder descubrir muchas cosas tiles so-
bre nuestra empresa, describir como operamos, cmo podemos mejorar y
nos permitirn descubrir nuevos procesos y nuevas formas de hacer nego-
cios, hasta el punto de poder cambiar la cultura y la tecnologa de la organi-
zacin.
Al anlisis del entorno de negocio y de los cambios u oportunidades que

puedan suceder en ste, as como de los nuevos stakeholders que puedan
surgir en el transcurso del proyecto, siempre volveremos en el ciclo de im-
plementacin de BPM, en busca de la orientacin estratgica y redefinicin
de metas y objetivos para nuestros procesos. El retorno a esta fase ser
ineludible, bien sea por la naturaleza cambiante y dinamismo existente en
los entornos de negocio o el debido los cambios que surjan en el mercado o
aquellos provocados por el propio funcionamiento de los procesos, pues, en
ambos casos, el modelo de procesos requerir de cambios, adaptaciones,
mejoras y de la implementacin de nuevas necesidades demandadas por el
cliente y el negocio. Esta necesidad de adaptacin al cambio se ver facili-
tada enormemente por las capacidades de los sistemas BPMS y del lenguaje
BPMN, a la hora de gestionar de forma flexible y en tiempo real las modifi-
caciones y cambios sobre nuestros procesos.
260
Puesto que hemos detallado en los captulos anteriores bastantes deta-

lles sobre el entorno de negocio y el Motivation Model sobre los que se
asentarn nuestros procesos de negocio, no nos detendremos ms en esta
fase y pasaremos a la fase de levantamiento de procesos.
Levantamiento de procesos.
Esta fase es probablemente la ms importante dentro del ciclo de vida

de BPM, el levantamiento de procesos es la fase en la que desvelaremos los
detalles y operativa de los procesos que actualmente ejecuta la empresa y
sobre los que se fundamentarn las posteriores mejoras. Aunque es una
imagen demasiado utilizada, la situacin que nos encontraremos a la hora
de llevar adelante esta fase en las organizaciones, puede ser comparada
con un iceberg en el que slo vemos lo que est por encima, el 10% de la
realidad, sta es la parte visible de los procesos que coincide con la parte
que ven nuestros clientes como salidas de nuestros procesos y no la parte
oculta, que representa el 90% de los procesos y que dificultar el poder
conocer todos los detalles de los procesos que operan la empresa. Pero si
bien es cierto que a nuestros clientes no les importa la parte oculta, y lo
que quieren es que seamos capaces de darles el resultado de lo que hace-
mos por debajo del agua, a nosotros, como responsables de la mejora de
los procesos de la empresa, nos importa y mucho lo que acontece en la
parte sumergida y el desvelar la realidad de lo que ocurre por debajo ser
una de las tareas ms importantes que asumiremos para limitar los riesgos
y conseguir el xito en nuestros proyectos de BPM.
261
Las empresas muchas veces no saben o no son capaces de describir c-

mo hacen las cosas de forma precisa y detallada. La realidad sobre cmo
funcionan las cosas y las excepciones que puedan acontecer en su funcio-
namiento, estn normalmente escondidas dentro de determinadas perso-
nas o programas informticos dentro de la organizacin, pero ocultas para
el analista de procesos y para gran parte de los miembros de la organiza-
cin, por lo que es difcil descubrir estos procesos con todos los detalles de
su operativa. En la gran mayora de las organizaciones, los trabajadores
conocen slo las actividades que realizan y son de su responsabilidad, pero
carecen o no disponen de una visin global de todos los procesos y opera-
ciones de la compaa de principio a fin, estando estos fraccionados en las
mentes individuales de distintas personas, donde cada una de ellas dispone
de una visin local de una parte del proceso. Ni tan siquiera el omnisciente
director general fundador de la empresa, ni el responsable de sistemas,
disponen del nivel de detalle y del conocimiento de cmo se realizan todas
las tareas de la empresa.
El principal reto en esta fase de levantamiento de procesos, consistir en

hacer explcitos los procesos, el desvelar los procesos y sacarlos a la superfi-
cie, de forma que tengamos un entendimiento global de toda la estructura
de procesos, para lo que tendremos que recabar todo el conocimiento exis-
tente en la organizacin y convertir ste de tcito en explcito para poder
incorporarlo a la organizacin, retenerlo, monitorizarlo y gestionarlo.
Obtener el As Is.
Durante el Levantamiento de Procesos (Process Discovery, en ingls), es

donde especificaremos la arquitectura de procesos de la organizacin y las
reglas y principios que rigen los procesos a travs de los cuales la empresa
implementa actualmente su modelo de negocio.
Los modelos As-Is (Cmo es actualmente) y To-Be (Cmo debera ser),

funcionan y podrn ser utilizados para cualquier tipo de modelado que rea-
licemos, tanto para el modelado de procesos como del Motivation Model o
del modelo organizacional. El modelado del As-Is nos permitir conocer
dnde estamos y el To-Be describir donde nos gustara estar, de forma que
comparando ambos, podamos evaluar que actividades son diferentes, cua-
les no son necesarias o que nuevas actividades debemos aadir al modelo
para mejorar su rendimiento y eficiencia. Cuando analizamos los procesos
de nuestra organizacin y describimos el As-Is, describimos lo que est su-
262
cediendo en la misma para una vez que dispongamos del entendimiento y

descripcin de este modelo, generar alternativas al mismo, que llamaremos
los Could-Be (Podran Ser), que cuando escojamos los que satisfacen los
objetivos y resultados del proceso, convertiremos en To-Be que pasarn
entonces a convertirse en los nuevos As-Is.
La realidad hoy es que este ciclo del As-Is al To-Be es cada vez ms corto,
debido al constante cambio en el que las organizaciones se ven inmersas,
las mejoras obtenidas sobre los procesos tienen cada vez una menor vida
media y en consecuencia, nos vemos obligados a revisar los nuevos As-Is y
repetir este ciclo iterativo de mejora continua. Capturamos el As Is de los
procesos existentes para una vez obtenido, analizarlo para descubrir debili-
dades o cuellos de botella y basndonos en este diagnstico, diseamos el
To Be, que corrige esas debilidades. En este punto realizamos un nuevo
anlisis para comparar los procesos del To Be con los del As Is, si este
anlisis indica que los beneficios justifican el coste, la organizacin imple-
menta el To Be, que se convierte ahora en el nuevo As Is, con lo que
iniciamos de nuevo el proceso.
Aunque veremos las distintas partes de este ciclo, el Levantamiento de

Procesos marcar el inicio del mismo y en el realizaremos el inventario de
los procesos actuales de la organizacin, con el objeto de priorizar los mis-
mos e identificar en cules de ellos debemos centrarnos en primer lugar
para trabajar en su mejora. Para ello y al igual que hicimos en el captulo 1,
haremos la lista de procesos, crearemos los criterios de priorizacin y apli-
caremos estos criterios a cada proceso identificado, con lo que obtendre-
mos una lista de procesos priorizados y sabremos por dnde empezar a
trabajar. Para la identificacin de procesos revisaremos las actividades de
nuestra empresa, hablando con los trabajadores o realizando cuestionarios.
Aunque en el levantamiento de procesos cualquier metodologa es vli-

da para el objetivo de identificar los procesos, las sesiones de levantamien-
to de procesos para obtener el As-Is sern una tcnica de especial utilidad
que deberemos aplicar para obtener los mejores resultados de una forma
eficiente y estructurada. Estas sesiones se organizan generalmente en torno
a reuniones de trabajo con el equipo de proyecto en las que un analista va
dibujando en papel, o mejor an, modelando sobre una herramienta de
modelado en BPMN, los procesos que entre todo el equipo se van descri-
263
biendo y detallando, de forma que sobre este mismo modelo, los miembros
del equipo puedan realizar modificaciones y depuraciones sobre la informa-
cin recolectada por todos ellos. En el modelado del As-Is, podremos ir
introduciendo adems del flujo de procesos, datos e informacin relativos
al proceso, como tiempos para cada actividad, coste asociado a cada una de
ellas, recursos necesarios, etc. Estos datos nos servirn para ir tomando
medidas de comportamiento del proceso actual, el As-Is, y evaluar la efi-
ciencia del mismo. Como hemos comentado en el captulo anterior, la gran
ventaja de modelar sobre un lenguaje como BPMN es que en estas reunio-
nes, as como en las que veremos en mejora de procesos, todo el equipo,
sea este de negocio o de TI, puede entender lo que estamos modelando,
colaborar conjuntamente en el levantamiento de procesos y reducir el dis-
tanciamiento entre los requerimientos de negocio y los de TI a la hora de
modelar los procesos existentes en la empresa.
Existen diferentes metodologas y aproximaciones a la hora de realizar el

levantamiento de procesos:
Centralizada vs. Descentralizada:
- Centralizada: El analista de procesos invita a los expertos a se-

siones en grupo y acta como un facilitador buscando el consen-
so entre los participantes.
- Descentralizada: El analista habla con los expertos por separado,
donde este captura las partes del proceso que cada uno de estos
conoce.
Top-Down vs. Bottom-Up:
- Top-Down: Realiza el anlisis comenzando a un alto nivel (la ca-

dena de valor) y descompone los procesos hacia abajo hasta lle-
gar a las tareas.
- Bottom-Up: Comienza el anlisis por abajo, recopilando infor-
macin local y construye el modelo hacia arriba.
Forma Libre vs. Estructurada:
- Forma libre: Aplica tcnicas como el brainstorming, donde se

deja a los expertos describir libremente los procesos y los pro-
blemas para luego compilar la informacin de forma estructura-
da.
264
- Estructurada: Los expertos responden a preguntas predefinidas

en base a un cuestionario o entrevista.
De estas tres posibles metodologas u orientaciones, a la hora de realizar

el levantamiento de procesos, la recomendacin a seguir es la mostramos
en el siguiente grfico:
Donde para obtener el mayor aprovechamiento de la fase de Levanta-

miento de Procesos seguiremos tanto una perspectiva Top-Down (de arriba
hacia abajo) como Bottom-Up (de abajo hacia arriba) y no slo la perspecti-
va tradicional Top-Down, alejada del compromiso con la innovacin en la
que los de arriba slo piensan y los de abajo ejecutan las ordenes que viene
de arriba.
Esta fase de levantamiento de procesos es como comentbamos tal vez

la ms importante y en la que ms tiempo emplearemos en el proyecto y
no slo nos servir para describir el As-Is de los procesos, sino que aprove-
charemos la misma para ir conociendo detalles e informacin sobre la me-
jora de los procesos, medidas que podamos utilizar o estrategias a seguir
para la mejora del rendimiento de los procesos, por lo que la actitud inno-
vadora, el contar con todos las personas involucradas en los procesos y el
barajar las distintas posibilidades y formas de hacer las cosas, deben tam-
bin ser tenidas en cuenta en esta fase de levantamiento de procesos. En
este sentido debemos mantener reuniones tanto con los miembros del
equipo como con SMEs (Subject Matter Expert: Expertos en un determina-
265
do campo) y trabajadores del nivel ms bajo, para obtener todos los deta-
lles de los procesos. En estas reuniones de equipo o en las entrevistas indi-
viduales que mantengamos, deberemos estar atentos no slo a describir el
As-Is visto por cada uno de los miembros que entrevistemos, sino tambin
identificar las quejas de estos sobre la operativa de los procesos y las posi-
bles mejoras que estos puedan sealar, aprovechando estas sesiones de
levantamiento de procesos para recabar informacin para la fase de mejora
de procesos. Como comentbamos, este aspecto de involucrar a todas las
personas, no es slo funcional sino tambin psicolgico, a la hora de gestio-
nar el cambio e involucrar a todas las personas de la organizacin en el le-
vantamiento y futura mejora de los procesos, pues son estas personas las
que al final debern usar el proceso, por lo que buscaremos su complicidad
con el proyecto desde las fases inciales del mismo.
Para obtener el As-Is comenzaremos por los procesos de alto nivel y de

forma parecida a una estructura de desglose del trabajo, que utilizamos
para subdividir los paquetes de trabajo del proyecto, desglosaremos estos
procesos de alto nivel en subprocesos ms pequeos y manejables hasta
llegar a las actividades, de forma que los procesos modelados puedan ser
entendidos por todo el equipo y podamos observar las posibilidades de
mejora a realizar sobre estos o las deficiencias con que cuentan los proce-
sos en el As-Is. Tras este desglose y llegados al nivel ms bajo de activida-
des, deberemos dar un nombre a cada una de stas, describir su operativa,
de forma que todos los miembros del equipo la entiendan, especificar las
reglas de negocio aplicables a los procesos, si van a ser realizadas por una
persona, automatizadas por un software o una combinacin de ambas y
quien ser en ltima instancia el responsable de gestionar la actividad o
subproceso en el da a da de su operativa. As mismo, deberemos identifi-
car las actividades clave, los responsables, los problemas que afectan al
trabajo y las metas y objetivos afectados por los procesos as como los atri-
butos de estos procesos segn vimos en la gestin de procesos del primer
captulo. Esta especificacin ser importante pues sin ella no podremos
medir y comparar con posterioridad las mejoras o avances logrados sobre
los procesos. Todas estas tareas requerirn de un duro trabajo, en el cual
deberemos enfrentaremos a la organizacin y perseguir los datos e infor-
macin relevante asociada a los procesos, buscando debilidades o cuellos
de botella en los mismos, entendiendo las interrelaciones e integraciones
de cientos de datos y documentos existentes en la empresa, procurando
crear procesos estandarizados para nuestra cadena de valor y la convergen-
cia de mltiples procesos paralelos ejecutados por distintos departamentos
en un nico proceso estndar de toda la empresa.
266
Una vez tengamos todos los procesos clasificados, el siguiente paso ser
determinar que procesos sern crticos para la organizacin, en el sentido
de la capacidad que tengan de proporcionar una ventaja competitiva a la
misma y crear valor. Por esta razn, los procesos no deben ser slo descri-
tos y definidos, sino que necesitan tambin ser demostrados, por lo que
pasaremos a definir los criterios para su priorizacin y estableceremos una
forma para medir cada uno de estos criterios que pueden estar clasificados
por:
- Impacto: en la organizacin y como afectan a la misma.

- Facilidad de implementacin: o de poder realizar cambios y me-
joras sobre el proceso.
- Estado actual: como est funcionando actualmente el proceso.
- Valor: de retorno para la empresa, que podemos obtener mejo-
rando el proceso.
Estos u otros criterios pueden ser definidos para priorizar los procesos,
cada organizacin usar aquellos criterios ms adecuados segn los inter-
eses que esta tenga en el proyecto, pero el objetivo es hacer la clasificacin
de los procesos para identificar, del largo listado de procesos, los criterios
que nos dirn que procesos aportarn ms valor a la organizacin.
A continuacin nombramos algunos ejemplos de medidas sobre los cri-

terios de priorizacin:
- Impacto:
o Personas afectadas por el proceso: si afecta a muchos
empleados tendr ms impacto que si afecta a pocos.
o Nivel de las personas afectadas.
- Implementacin:
o El tiempo que tardaremos desde que concebimos el
producto o servicio hasta que lo sacamos al mercado. El
Time to Market.
o Complejidad en el proceso.
o Problemas con los que nos podemos encontrar.
o Disponibilidad de recursos para la mejora del proceso.
o Presupuesto que necesitaremos para implementar el
proceso, etc.
- Estado actual:
o Satisfaccin de las personas con el proceso actual.
o Cmo de bien funciona el proceso en la actualidad.
267
- Valor:
o Beneficio de la implementacin del proceso
o ROI
Sobre estos criterios de clasificacin de procesos, determinaremos la es-

cala que vamos a usar para medir cada criterio y desarrollaremos la plantilla
en forma de tabla que usaremos para evaluar los distintos procesos, donde
apuntaremos los valores para cada criterio y obtendremos el total de las
medidas para los distintos procesos.
Una vez tengamos esta lista de procesos priorizados, puede ser que ten-
gamos que aplicar pesos relativos a los mismos, debido a influencias de la
organizacin, en el sentido de dar ms peso a unos procesos que a otros.
Podemos usar medidas porcentuales o valoraciones numricas para dar
ms peso a unos u otros criterios.
Como resultado final de este proceso de priorizacin, tendremos la tabla

de procesos claramente priorizados y sabremos por dnde empezar a tra-
bajar, mostraremos a nuestros superiores y al resto de personal involucrado
en el proyecto los criterios y valorizaciones que hemos realizado para selec-
cionar los procesos y dispondremos adems de un buen documento de
trabajo para empezar a hablar sobre los procesos con el resto del equipo
del proyecto.
Uno de los beneficios que obtendremos con la implementacin de BPM,

ser el poder medir la mejora de los procesos, por lo que para medir con
posterioridad las mejoras, deberemos medir primero los As-Is, para conocer
de donde partimos y saber si mejoraremos o no con el rediseo de los pro-
cesos.
Una vez finalizado el As-Is y antes de su aprobacin y paso a la fase de

rediseo, revisaremos el mismo para buscar su aprobacin y repasaremos
su alineacin con los objetivos y metas de negocio, las restricciones que
podamos incumplir, las reglas de negocio que hayamos podido pasar por
alto, las medidas utilizadas y los supuestos que se puedan dar en el mismo y
no hayamos considerado en esta fase.
Como veremos en la fase de implementacin, algunas veces y en organi-

zaciones conservadoras y que no deseen asumir excesivo riesgo en los pro-
yectos de BPM, ser conveniente escoger proyectos de pequeo alcance
primero o procesos concretos sobre los que podamos demostrar las capaci-
dades de mejora con BPM, de forma que nos aseguremos su xito por la
268
importancia que pueda tener esta primera implementacin para la realiza-

cin de futuros proyectos de BPM.
Llegados a este punto y al igual que hicimos en Gestin de Procesos en

el Captulo 1, procederemos ahora a describir el proceso sobre el cual
hemos decidido centrar nuestros esfuerzos. Esta descripcin se convertir
en la lnea base del proceso, servir como gua para su desarrollo e imple-
mentacin e incluir entre otros informacin bsica del proceso como:
- Nombre del proceso.

- Propietario del proceso: la persona responsable del desarrollo y
mejora del proceso.
- Cliente y sus necesidades, quien recibir el resultado del proce-
so y que necesidades y expectativas hemos identificado que
debemos satisfacer con el resultado del proyecto.
- Descripcin del proceso, de forma resumida, clara y sencilla, pa-
ra que cualquier persona pueda entender el proceso.
- Personal interesado en el proceso (stakeholders), adems de los
clientes, qu otras personas u organizaciones pueden verse
afectados por el desarrollo del proceso, por su implementacin
y por los resultados de este.
- Alcance del proceso y lmites del mismo (Inicio y Final): que est
incluido y que no en el trabajo necesario para desarrollar el
proyecto.
- Medidas que vamos a emplear para medir el proceso.
Una de las tareas que realizaremos en esta fase ser la asignacin de

personas o equipos a actividades o subprocesos, para la cual nos ser til la
utilizacin de una matriz de asignacin de responsabilidades, donde se
muestren todas las actividades asociadas con una persona a fin de evitar
confusiones. Un ejemplo de esta matriz es la matriz RACI, cuyas siglas en
ingls significan:
- Responsible (R): la persona responsable de realizar el trabajo,

tarea o funcin.
- Accountable (A): slo puede ser una, que es la que rinde cuen-
tas y aprueba el trabajo. Debe ser el CEO, el cual tiene toda la
responsabilidad y delega autoridad para ejecutar determinadas
funciones y actividades.
- Consulted (C): que debe ser consultada de la realizacin de los
trabajos.
269
- Informed (I): informada de los trabajos.
Un ejemplo de esta matriz puede ser la siguiente:

Persona
Actividad Alberto Carlos Sandra Jorge
Analizar A R I I
Implementar C A C R
El uso de esta matriz es importante y debemos realizarla al inicio de

nuestros proyectos, pues si no lo hacemos, la echaremos en falta cuando
implementemos el proyecto y comencemos el despliegue de portales e
informes asociados a los procesos.
Sesiones de Levantamiento de Procesos.
Las sesiones para el levantamiento de procesos y la metodologa y lide-

razgo que como responsables del proyecto utilicemos en estas sesiones,
sern una actividad fundamental para alcanzar los objetivos pretendidos en
la fase de levantamiento de procesos. El director del proyecto deber dis-
poner de especiales habilidades y conocimiento de la metodologa de estas
sesiones para sacar el mximo provecho de las mismas y poder desvelar el
funcionamiento y operativa de los procesos que ejecuta la empresa.
La importancia de una correcta planificacin y conduccin de estas se-

siones tomar ms relevancia considerando que no slo las utilizaremos
para el levantamiento de procesos sino que aprovecharemos las mismas
para ir adelantando trabajo en cuanto a la recopilacin de la informacin
para la mejora de procesos, su posterior implementacin y la implicacin de
los trabajadores y personal involucrado en el proyecto de mejora de proce-
sos, por lo que el resultado de estas sesiones lo utilizaremos durante todo
el proyecto y no slo durante la fase de levantamiento de procesos.
Las sesiones o workshops de levantamiento de procesos, son reuniones

en las que trabajaremos con grupos de personas: SMEs, stakeholders, tra-
270
bajadores y partners relacionados con los procesos sobre los cuales esta-
mos trabajando, para obtener informacin sobre los procesos actuales de la
empresa y su mejora, buscando alcanzar acuerdos consensuados con todos
los miembros de la organizacin. Estas sesiones requerirn de gestin y
moderacin de las mismas y para ello debern ser dirigidas por una perso-
na, normalmente el jefe del proyecto, que gestionar y liderar a los parti-
cipantes y escuchar las opiniones de todos los miembros para alcanzar los
objetivos de estas sesiones y obtener el modelado de los procesos, tanto de
los As-Is como de los posibles Could-Be y el To-Be final, por lo que ser im-
portante dirigir las reuniones hacia la consecucin de estos resultados,
hablando con todos los participantes y describiendo la informacin que
recibimos en un modelo que iremos puliendo con los participantes para
obtener finalmente su validacin final. Estas sesiones o workshops, las po-
dremos usar tanto para modelar, recoger informacin, evaluar alternativas
tanto de procesos como estratgicas, alinear la tecnologa con la estrategia,
buscar soluciones para la mejora de procesos, tomar especificaciones, re-
querimientos y reglas de negocio como para comunicar y validar resultados,
conseguir que todos comprendan la importancia del proyecto y el impacto
que este supone para la organizacin, as como tambin para proporcionar
formacin a los participantes.
Para aprovechar todas las ventajas que nos ofrecen los workshops y da-
da su importancia para el resto de tareas que nos quedarn por hacer en el
proyecto de BPM, deberemos ser metodolgicos en su realizacin, por lo
que planificaremos y preparemos las mismas desarrollando tcnicas,
herramientas y nuestras propias habilidades personales para la gestin de
estas sesiones.
Antes del workshop realizaremos la planificacin del mismo, definiremos

los objetivos que queremos de la reunin, el alcance de la misma y que
queremos conseguir con ella y prepararemos el material necesario que
usaremos durante el workshop. En esta fase, especificaremos los perfiles,
roles y personas que debern asistir y prepararemos una agenda previa de
la reunin, la cual habremos enviaremos previamente a los participantes.
Algunos de los participantes en estas sesiones pueden ser los siguientes

perfiles:
- Sponsor: ejecutivo que define el alcance del proyecto, los obje-

tivos, explica los problemas con que nos podemos encontrar,
identifica los procesos que no funcionan o pueden ser mejora-
271
dos, establece el calendario y proporciona los recursos para al-

canzar los objetivos del proyecto.
- SME (Subject Matter Expert): directores o trabajadores que rea-
lizan determinadas tareas involucradas en los procesos y po-
seen conocimientos especficos sobre determinados aspectos
de los procesos que tratamos.
- Analista: responsable de compilar, organizar, analizar y presen-
tar la informacin reunida de los SMEs.
Como jefes de proyecto dirigiremos las sesiones en busca de consenso

sobre las soluciones y gestionaremos los conflictos, recordando lo que vi-
mos al hablar de innovacin sobre la importancia de estos conflictos o pro-
blemas como potenciales generadores del cambio. Nuestra actitud como
lderes en estas sesiones no ser la de fagocitar las reuniones con nuestro
conocimiento, sino que esta ser de escucha activa, detectivesca, sin actuar
como expertos en el proceso o alguna parte del mismo. Nuestro objetivo es
recabar todos los datos y posibles soluciones a los procesos planteados, por
lo que seremos ms investigadores que expertos en la materia y la nica
materia en la que deberemos ser expertos ser en la de dirigir estas reunio-
nes y a sus participantes para alcanzar los objetivos planteados: gestionar la
reunin, a los participantes, los tiempos, la recopilacin de informacin y el
modelado de los procesos y soluciones que surjan durante las reuniones. Es
una buena prctica, ya comentada, el utilizar una herramienta de modelado
de procesos o la propia de modelado de un BPMS, para recoger la informa-
cin de los modelos y sus diferentes versiones de forma que podamos con-
servar las mismas para futuras revisiones. El modelado debera ser realiza-
do por otra persona, un analista de procesos o alguien con conocimientos
de modelado y BPMN, de forma que el jefe de proyecto pueda centrarse en
dirigir la reunin mientras esta persona modela por detrs.
El jefe de proyecto debe tambin actuar como un psiclogo en las reu-

niones y sesiones de trabajo durante el levantamiento de procesos, cono-
ciendo las diferentes personalidades de los participantes y moderando la
participacin de estos, tanto si son demasiado activos y pretenden conver-
tirse en los expertos que conocen todas las partes del proceso y no necesi-
tan de la ayuda de nadie para definir o mejorar los mismos (situacin esta
nada deseable), como si se mantienen en la sombra, apenas participan y
dejan el peso de las especificaciones del proceso a los dems participantes.
Liderar estas reuniones a lo largo del proyecto no es algo fcil, pero es una
tarea crtica para el proyecto y en la que empelaremos el mayor nmero de
horas durante el desarrollo del proyecto. Generalmente, un solo workshop
272
no ser suficiente en un proyecto y estos sern iterativos, recogiendo in-

formacin en los primeros, para en los siguientes pulir y depurar esta in-
formacin recabada en forma de modelos elaborados y realizando los in-
formes sobre las reuniones, para con posterioridad, realizar nuevos works-
hops para mejorar y validar los modelos planteados en los primeros.
Por la importancia que tiene para el proyecto y por el tiempo que dedi-
caremos en estas reuniones, deberemos ser muy hbiles en la gestin de
stas y en especial en la gestin de las personalidades que participan en las
mismas. Debemos recordar que lo ms importante en un proyecto de BPM
es la gestin del cambio organizacional y las personas implicadas (People
in the trenches, las personas en las trincheras, en expresin de Michael
Hammer), pues son estas personas las que van a determinar el xito o el
fracaso del proyecto. Al igual que con otros muchos proyectos (de TI por
ejemplo), podemos tener los mejores procesos en nuestra organizacin,
pero si las personas que los van a usar no estn implicados con la importan-
cia y necesidad de estos, si no entienden su lgica y la razn de su uso, no
podremos esperar su responsabilidad a la hora de usarlos y comprometerse
con su mejora para sacar la mxima eficiencia de los mismos y en conse-
cuencia, no tendremos nada, el resultado de toda la estrategia de negocio y
los esfuerzos en la mejora de los procesos de negocio, no habrn valido
para nada.
Para hacer levantamiento de procesos debemos buscar el consenso en

que los procesos que escojamos para su diseo o mejora, cuentan con la
aprobacin de toda la organizacin y no slo en su diseo, sino tambin en
que estos los ms importantes para implementar. Deberemos evitar la si-
tuacin tantas veces repetida en los proyectos de TI donde la direccin
estima la necesidad de un desarrollo o aplicativo, que una vez ya contrata-
do, debe ser asumido por los trabajadores de la empresa, con los cuales no
se cont ni para su eleccin ni para su especificacin, por lo que ser difcil
el compromiso de estos con su utilizacin y mejora y que en muchos casos
resultar en una actitud de sabotaje por parte de estos usuarios forzados a
su utilizacin. De lo bien que lo hagamos y del consenso que alcancemos
con las personas que formarn parte de los procesos y de lo en cuenta que
las tengamos en el diseo y mejora de los mismos, nos estaremos asegu-
rando el xito futuro en la implementacin del proyecto de BPM.
En general, en la fase de levantamientos de procesos, los principales

problemas con los que nos encontraremos estarn relacionados con el c-
mo llevemos a cabo estas sesiones de trabajo y en conseguir la participa-
273
cin activa de las personas implicadas en su posterior utilizacin. Entre es-

tas dificultades, las ms comunes suelen ser la Imposibilidad de hablar con
todos los SMEs implicados o los problemas de agenda para poder sentarlos
en sesiones conjuntas o el recelo de algunos participantes a la hora de
compartir la informacin secreta que conocen sobre su tarea especfica.
Este secretismo se debe muchas veces por miedo al cambio, otras veces por
no desvelar que lo que hacen es una tontera o que no tiene sentido para el
buen funcionamiento de la organizacin y otras, porque saben que lo que
hacen lo realizan de forma ineficiente (pero es como siempre lo he
hecho) y temen por su reputacin.
Por todo la anterior, si queremos llevar adelante nuestro proyecto de

mejora de procesos, u optamos por la va del BPR (Reingeniera) y no per-
demos el tiempo con esta fase de levantamiento de procesos, rompiendo
con todo, diseando todos los procesos desde el principio y empezando
desde cero, o nos comprometemos con el proyecto y las personas, aplican-
do todos nuestros conocimientos y habilidades para sacar lo mejor de estas.
Existe una realidad en los proyectos de BPM y es la relacionada con la

automatizacin de procesos y en consecuencia de puestos de trabajo. Hoy
en da, en un momento de grave crisis econmica mundial y de recesin, las
empresas y los gobiernos han comprendido la necesidad de dar un giro de
180 grados a los planteamientos y actuaciones de las anteriores pocas de
bonanza econmica y no omos otra cosa ms que necesidad de eficiencia,
rentabilidad en las operaciones, optimizacin del gasto, competitividad,
austeridad y ahorro. Sin embargo, las personas no parecen atender a este
nuevo planteamiento, nos aferramos a lo que tenemos y no queremos per-
der privilegios y ventajas, ocultando nuestras ineficiencias, no velando por
el bien comn o el de la mejora de nuestras empresas, pretendiendo que
nada cambie, por si nuestras condiciones laborales puedan verse afectadas.
Tanto en el levantamiento de procesos como en todas las fases del ciclo de
vida de nuestros proyectos en BPM y en general en cualquier proyecto diri-
gido a la mejora de la eficiencia operacional de una empresa, nos encontra-
remos con la paradoja de que nadie en su sano juicio propondr ideas de
mejora que puedan hacer peligrar su puesto de trabajo o el de algn com-
paero e incluso, si las mejoras han sido impuestas, encontrarnos con prc-
ticas de sabotaje. Ante esta situacin slo podemos luchar con una actitud
abierta al dilogo, al compromiso con nuestros trabajadores, hacindoles
ver el big picture y procurando que entiendan la realidad de la actual
economa, en la cual, debido a las altas exigencias de eficiencia y racionali-
zacin, los puestos de trabajo son sensibles al cambio, lo que pueda ser
274
automatizado ser automatizado, el cambio ser una constante y oponerse

al mismo por mantener el status quo, slo acelerar este cambio, al sacar
ms rpidamente a la luz las posibles ineficiencias. Los trabajadores de la
nueva economa deben comprender esta situacin y as debemos transmi-
tirla haciendo ver que en ella tambin existen nuevas oportunidades, pero
que stas pasan por la preparacin, el compromiso por los buenos resulta-
dos globales y la actitud innovadora y participativa sin temores en la bs-
queda de soluciones y mejoras en los procesos de la empresa y que cuanto
antes abordemos esta actitud, menos sufriremos en el cambio.
Podemos encontrar infinidad de libros y consejos sobre cmo extraer el

mximo provecho de estas reuniones, sobre las dinmicas de las mismas y
sobre la gestin de personas, no trataremos aqu en detalle estas teoras y
tcnicas, pero si me gustara como mejor consejo, recomendar las palabras
de Carl G. Jung: Conozca todas las teoras. Domine todas las tcnicas. Pero
al tocar un alma humana, sea apenas otra alma humana.
Preguntas a cliente para empezar:
Son muchas las preguntas con las que abordaremos a los participantes
en las sesiones de trabajo y que buscarn principalmente conocer detalles
acerca de los clientes de la empresa, del As-Is y de cmo debera ser el futu-
ro To-Be. Estas preguntas sern del tipo:
- Cmo es actualmente el proceso y qu se pretende conseguir
con l? Para ayudarnos a comprender los procesos y su rele-
vancia.
- Cmo funciona el proceso? Para obtener informacin ms de-
tallada de su funcionamiento.
- Qu personas, sistemas o unidades de negocio participan en el
proceso? Para identificar stakeholders, roles o sistemas con los
que interaccione el proceso.
- Cmo debera ser el proceso? Donde ya nos adentramos en el
To-Be, para comenzar a recabar datos sobre las posibilidades de
mejora del proceso.
- Cmo empieza y termina el proceso? Para conocer los lmites
del mismo y donde nos encontraremos con que la gente tiene
ideas diferentes de donde termina el mismo en funcin de la vi-
sin local o ms global que tengan del proceso.
275
- Cul es la informacin y datos que se manejan en el proceso y

que reglas de negocio sigue?
- Qu informes y burocracia siguen los procesos?, etc.
La perspectiva Bottom-Up y los sistemas emergentes.
Hemos recomendado para el Levantamiento de procesos el comenzar

con una perspectiva Top-Down y continuar con una Bottom-Up. Para la
primera, seguiremos una visin ms estratgica desde la direccin de la
organizacin pero la segunda perspectiva de Bottom-Up, resultar funda-
mental para el xito del proyecto e implicar escuchar y entender tambin
a las partes de ms abajo de la organizacin.
No debemos caer en la creencia de pensar que las personas en niveles

operacionales de la organizacin no tienen nada que aportar a la estrategia,
objetivos de la empresa, mejora de procesos o actividades necesarias para
desarrollar los procesos. La historia de la innovacin est llena de ejemplos
de lo contrario y no slo debemos buscar la implicacin de estos perfiles en
el proyecto, pues como venimos diciendo, son los que finalmente debern
usar el proceso y en consecuencia formarn el taln de Aquiles para el xito
del mismo, sino tambin por la importante informacin que estos nos pue-
dan proporcionar, al ser unos stakeholders de primer orden para el proyec-
to y a no ser que todas las personas en la organizacin conozcan y nos
transmitan su opinin sobre los procesos y el proyecto, no podremos cono-
cer las implicaciones del cambio que pretendemos realizar.
La perspectiva Bottom-Up, nos ayudar no slo a entender y ver la orga-

nizacin desde otro punto de vista, sino que adems, podremos encontrar
con mayor facilidad que en ninguna otra parte, la impredecibilidad, la se-
rendipia o la solucin sorprendente y de alto impacto, propia de los sis-
temas emergentes, en las que al igual que en las colonias de hormigas, las
reglas y comportamientos de d las entidades ms simples regirn el com-
portamiento del sistema en los niveles ms altos basndose en la auto-
organizacin formar algo ms complejo.
La propiedad de emergencia, caracterstica de todo sistema, significa

que de las interacciones entre las partes que componen un sistema, surgen
nuevas caractersticas y propiedades que no pueden ser encontradas en las
partes individuales del sistema. Esta situacin es similar a la del comporta-
miento emergente de muchos sistemas, como le de las hormigas y en cmo
276
stas, pensando localmente dentro de la colonia, producen un comporta-

miento global en el que la inteligencia deriva del conocimiento local. El es-
tudio del comportamiento emergente, ha sido perfectamente descrito por
Steven Johnson en su libro: Sistemas emergentes: o qu tiene en comn
hormigas, neuronas, ciudades y software. En el cual el autor enumera cin-
co principios que se deben seguir para construir un sistema que aprenda
desde los niveles ms bajos y que nos pueden servir de advertencia y orien-
tacin:
1. Ms es mejor. A mayor cantidad de individuos, mayor nmero de in-

teracciones y mejor apreciaremos el comportamiento colectivo. Si
observamos dos hormigas no apreciaremos el comportamiento
emergente pero observando a miles de ellas s que podremos perci-
birlo.
2. La ignorancia es til. Es mejor construir un sistema con elementos
simples y altamente interconectados y dejar que aparezcan conduc-
tas paulatinamente. Aunque el lenguaje de feromonas de las hormi-
gas nos parezca sencillo, es perfectamente vlido y a veces compli-
cando.
3. Fomentar los encuentros casuales. Los sistemas descentralizados
dependen fuertemente de las interacciones casuales, sin rdenes
especficas y predefinidas, como los encuentros arbitrarios entre
hormigas.
4. Buscar patrones en los signos. Sin contar con un vocabulario y len-
guaje sintctico elaborado, las hormigas dependen de los patrones
qumicos que detectan.
5. Prestar atencin a tus vecinos. La informacin local conduce a la
sabidura global. El mecanismo primario de la colonia de hormigas
es la interaccin entre vecinos que entrecruzan sus rastros de fero-
monas.
El aspecto fundamental de estos sistemas emergentes est en que son

capaces de generar conductas o procesos innovadores y disponen de un
mayor poder de adaptacin a los cambios que los sistemas jerrquicos o
ms rgidos. Estos sistemas, aparentemente complejos y desorganizados,
pueden dar lugar a un comportamiento colectivo, coherente y consistente,
propios de sistemas auto-organizados: las hormigas crean colonias, los
habitantes de una ciudad crean barrios, un software aprende a recomendar
viajes o libros, dos clulas reproductivas crean una clula que a su vez crea
un organismo completo, etc. Y en este sentido, cabe preguntarse si las fuer-
zas ascendentes y no las descendentes son las que rigen el comportamiento
277
de las organizaciones y si resultan finalmente determinantes para el xito

de estas.
Muchos de estos patrones emergentes pueden encontrarse tambin en

conductas sociales, redes sociales y ecosistemas digitales y empresariales y
podremos tambin tenerlos en consideracin al tratar la organizacin
orientada a procesos, des-jerarquizada y flexible, pues de estas organiza-
ciones resultarn tambin propiedades emergentes, capaces de resolver
sus problemas y de auto-organizarse a pesar del aparente desorden y asi-
lamiento de sus partes componentes y que no requerirn de una inteligen-
cia centralizada en forma de leyes o instrucciones, sino que podrn funcio-
nar de forma ascendente (Bottom-Up) a partir de elementos relativamente
simples.
Las Personas.
Como venimos advirtiendo en distintos apartados de este libro, las per-

sonas sern la piedra angular sobre la que se sostenga nuestro proyecto,
pudiendo adems ser consideradas como una herramienta competitiva ms
en los proyectos de BPM, donde partiremos de la consideracin de que si
cuidamos a la gente, la gente cuidar de la organizacin, por lo que como
jefes de proyecto, dedicaremos la mayor parte del tiempo a las tareas de
comunicacin entre las personas involucradas en el mismo.
El negocio lo mueven los procesos y las tareas, pero quin lo ejecuta son
las personas, partners y proveedores de la empresa y el xito del proyecto
no estar en tener los mejores modelos de procesos o la mejor automatiza-
cin de estos, el xito de un proyecto, estar en que las personas de nues-
tra organizacin usen la solucin desarrollada y que nuestros clientes se
beneficien de esa soluciones en los productos y servicios que reciban. Como
deca Michael Hammer, tener las ideas es fcil, pero hacer las tareas que
tenemos que hacer, es la parte ms difcil. El lugar donde estas reformas
mueren es abajo, en las trincheras y los que estn en las trincheras, son las
personas de la organizacin, que finalmente son las que tendrn que im-
plementar el trabajo.
Los recursos humanos, las personas, como prefiero llamarlas, son el cen-
tro y la clave de todo proyecto, no slo de BPM sino de cualquier otro tipo
de proyecto y no s por qu razn, pero esto es algo sobre lo que nos per-
catarnos siempre demasiado tarde, tal vez slo con la experiencia o mejor
278
dicho, con las malas experiencias de no haber dado a las personas la impor-
tancia que en todo proyecto deben tener, caemos en la cuenta de su impor-
tancia.
Ya hemos hablado de la necesidad de implicar desde las primeras fases

del proyecto a las personas, que con su implicacin y compromiso las nece-
sitaremos en todas las fases del proyecto, desde el levantamiento de proce-
sos, su mejora, la implementacin y por supuesto la puesta en marcha de
los procesos, pues al final, cuando hayamos implementando los procesos,
sern las personas las que da a da estarn con l y si hemos contado con
ellas y nos hemos asegurado su implicacin, ejecutarn correctamente los
procesos implementados, buscarn su mejora continua y la catalizacin de
nuevas ideas y proyectos. Para conseguirlo, las personas deben ser consul-
tadas, escuchadas, formadas y preparadas, para que desde las primeras
aproximaciones que la organizacin realice hacia el proyecto, estas com-
prendan el mismo, su importancia y los motivos por los que se lleva adelan-
te.
Una situacin muy comn en los proyectos de BPM es, por la naturaleza
misma de este tipo de proyectos, la relacionada con que las personas se
sientan vigiladas. BPM y la gestin por procesos significa gobernanza de las
tareas, actividades y procesos que ejecuta la organizacin as como el con-
trol y seguimiento del rendimiento de los procesos y en consecuencia de la
organizacin, por lo que se establecern indicadores y medidas de este
rendimiento que no siempre pueden ser bien percibidos por los trabajado-
res. La necesidad de esta medicin debe ser transmitida a las personas co-
mo algo necesario, como algo no destinado para vigilar su actividad y resul-
tados (que tambin), sino para poder conocer el rendimiento global de la
organizacin y si esta est en el camino correcto y cumpliendo con sus obje-
tivos estratgicos. Para ello deberemos establecer un dilogo honesto acer-
ca de lo que est pasando en el mercado y con los competidores y dar razo-
nes convincentes para que la gente participe en las mejoras y est abierta a
los cambios.
En BPM esta consideracin de la importancia de las personas como fac-

tor clave del xito o fracaso de un proyecto, toma mayor importancia al
considerar a las personas antes, durante y despus del proyecto como cla-
ves en todo el proceso. Antes, porque son las personas y no los sistemas y
las organizaciones las que disponen del conocimiento sobre los procesos de
la empresa. No tener en cuenta en el proyecto y en el modelado de proce-
sos a los usuarios e interesados en el proceso, ser una de los ms graves
279
errores que podemos cometer en un proyecto de BPM. Durante, porque

sern las personas las encargadas de llevar a cabo y ejecutar los procesos
que hemos diseado y despus, pues son las personas las que debern con-
trolar, medir, evaluar y mejorar los procesos en marcha en la organizacin.
Y despus, porque como ya hemos comentado, al final sern las personas
las que ejecutarn el trabajo establecido en los procesos.
La capacitacin y formacin as como el coaching, resultarn tambin

decisiva. La implementacin de BPM implica nuevos roles y puestos, los
cuales deben comprender e interiorizar la filosofa subyacente a BPM y
conocer los distintos aspectos que componen un proyecto de este tipo, de
forma que toda la empresa comprenda que se va a hacer y porqu. As
mismo, los perfiles de personal involucrado en un proyecto de BPM debe-
rn conocer todas las partes del proceso en el cual estn involucrados y no
slo las partes del mismo en el cual estn implicados, requirindose en
consecuencia de estos perfiles un mayor abanico de conocimientos, habili-
dades y polifacetismo, para comprender todas las partes constituyentes del
proceso. Toda la organizacin debe conocer y estar formada en BPM, pues
no es slo tecnologa o la adquisicin de una herramienta software de BPM
(BPMS) lo que conducir al xito del proyecto, sino que estos proyectos
implican un conjunto de conocimientos, tcnicas de modelizacin, de dise-
o, anlisis, monitorizacin, gestin del cambio y metodologas, que deben
ser entendidas e interiorizadas por todo el equipo, que debern estar abier-
to al cambio y a compartir sus conocimientos y experiencia, a pensar y re-
flexionar mucho sobre el sentido de por qu se hacen las cosas, el porqu
se hacen de una forma determinada y si es posible hacerlas de otras formas
distintas.
Como sabemos, los procesos atraviesan los departamentos y los bordes

mismos de la organizacin, lo cual tiene consecuencias sobre los roles, los
puestos de trabajo, las comunicaciones y las medidas del desempeo. Los
niveles de participacin y colaboracin entre equipos y personas se tornan
distintos a los de la empresa departamental, en la que cada uno tiene fun-
ciones claras y definidas. En BPM y en las organizaciones orientadas a pro-
cesos, exigiremos a las personas entender esta transversalidad de los pro-
cesos. Dentro de estas nuevas exigencias para estos nuevos trabajadores
comprometidos con la gestin por procesos, el personal de TI, por la idio-
sincrasia de su puesto en la organizacin y la necesidad de estos de dispo-
ner de una compresin global de los procesos de la empresa, debe com-
prender que ya no es un ente aislado que recibe unos requisitos y genera
cdigo fuente, sino que debe implicarse en el diseo y mejora de los proce-
280
sos globales de negocio de la empresa, siendo participativo sobre todo a la

hora de aportar soluciones tambin en el rea de negocio y no limitarse al
anlisis, desarrollo y mantenimiento del software de la empresa nicamen-
te en su vertiente tcnica. Este personal de TI deber romper con la tradi-
cional divisin entre gente de negocio y gente de TI en las organizaciones,
pues esta lnea divisoria ser cada vez ms difusa a medida que las herra-
mientas TI y las filosofas de management se aproximan ms a la realidad
de los nuevos entornos de negocio. De esta forma los CIO (Chief Informa-
tion Officer) y los responsables de TI de las organizaciones, deben ser trans-
formados en gestores de mejora de procesos, ms alineados con los objeti-
vos de la empresa y ser capaces de proporcionar y optimizar las herramien-
tas de negocio que permitan la gestin, control y monitorizacin de esos
procesos de negocio. En este libro abogamos en muchos puntos sobre la
necesaria adaptacin y acercamiento sin complejos de la gente de negocio
a las TI as como de estas a las reas de negocio, de forma que ambos cru-
cen la frontera que los separa como va para afrontar la realidad de los ne-
gocios y mercados actuales. No hay nada que ms alejado de la realidad
que la del programador en su torre de marfil al que la gente de negocio
pasa unas especificaciones por debajo de la puerta. La popularizacin de la
informtica y su fcil disponibilidad, la han convertido en un commodity,
en el que el valor ya no se encuentra en el propio software, en el manteni-
miento de las infraestructuras informticas o en los procesos de soporte a
operaciones y gestin del da a da que se supone deben encontrarse re-
sueltos y automatizados, sino que ese valor estar en cmo la informtica
sea capaz de servir a los procesos que dan soporte al crecimiento y bsque-
da de ventajas competitivas en las organizaciones.
Por ltimo, no debemos olvidar otro elemento clave como es la implica-

cin de la gente de negocio y de la direccin de la empresa. Los proyectos
de BPM significarn en muchas ocasiones cambios importantes en la orga-
nizacin y en su estructura, que deben ser apoyados por la direccin de la
empresa, por lo que no deberamos iniciar un proyecto sin el apoyo de los
CEO (Chief Executive Officer). Los CEO debern atender al proyecto, pro-
porcionar los recursos y dinero necesario para la ejecucin de los proyectos
y prestar apoyo e implicacin al mismo. Deben ser conscientes del esfuerzo
y energa necesarios para implementar un proyecto de BPM y de que estos
proyectos deben ser mantenidos en el tiempo. Este apoyo de los niveles
ms altos de la organizacin al proyecto, resultar en el aumento de las
probabilidades de xito o fracaso del mismo, siendo muy difcil que un pro-
yecto alcance sus objetivos sin el apoyo y entendimiento del proyecto por
parte de estos niveles ejecutivos de la organizacin.
281
Liderazgo.
Para extraer lo mejor del proyecto y de las personas, ser necesario un

fuerte liderazgo del proyecto por parte del responsable del mismo, un lide-
razgo moderno e innovador, basado en la influencia y no en la autoridad,
capaz de escuchar a todas las partes e involucrarlas en la bsqueda conjun-
ta de soluciones a los procesos y la mejora de los mismos.
El liderazgo en los proyectos de BPM no ser del CEO, del cual ya hemos
indicado su importante papel y funcin en el proyecto, sino que correspon-
der al jefe de proyecto liderar el mismo, definir, planear, guiar, asistir y
asesorar el trabajo del resto de miembros del equipo y del personal, pro-
veedores y partners de la empresa, pues ser el responsable ltimo de los
resultados del proyecto.
Entre otras funciones, un lder o director de proyecto debe dirigir y cata-

lizar las polticas y estrategias organizacionales, los recursos, las personas y
los propios procesos. Debern crear un ambiente que facilite el trabajo en
equipo, motivar, gestionar la comunicacin y retroalimentacin entre los
miembros, convertir el conocimiento de la organizacin en valor, asegurar-
se de que todos sepan su papel y lo que tienen que hacer en cada momen-
to, resolver los conflictos de manera constructiva con objeto de lograr un
mejor desempeo del proyecto, e inspirar a las personas para alcanzar los
objetivos del proyecto.
S que todo lo que acabo de decir es de superhroe, pero esto y mu-

cho ms es precisamente lo que es y debe ser un Jefe de Proyecto y habla-
remos todava ms al final del captulo sobre otras cuestionas relativas a la
gestin del proyecto que este superhroe deber tambin gestionar.
Gestin del conocimiento:
La gestin del conocimiento implica la identificacin y retencin de in-

formacin relevante para el negocio y de su correcta gestin, depender el
que seamos capaces de incorporar el mismo a nuestros procesos. Para Pe-
ter Drucker, el conocimiento debe ser constantemente mejorado, cuestio-
nado e incrementado o de lo contrario desparecer.
282
El conocimiento est en las personas y otra vez son las personas, en l-

tima instancia, de donde extraeremos la informacin sobre la operativa de
los negocios, los procesos y las tareas. En el transcurso del proyecto, debe-
remos identificar a las personas con los conocimientos que precisemos y
aplicar tcnicas de motivacin e incentivos si fuese necesario, para asegu-
rarnos la colaboracin y participacin de estas personas relevantes en el
proyecto. La informacin y el conocimiento necesario para nuestros proce-
sos, generalmente se encuentra dispersa en la organizacin, en las cabezas
de sus trabajadores y en distintos formatos a lo largo de la organizacin
(mails, hojas de clculo documentos, bases de datos, aplicativos, etc.). Du-
rante las reuniones de trabajo y especialmente en las de levantamiento de
procesos, una de nuestras tareas ms importantes ser la de recopilarla y
darle la coherencia necesaria para ponerlo a disposicin de las personas de
la organizacin. As mismo no deberemos olvidar el usar buenas prcticas
de gestin de proyectos como recoger al finalizar cada proyecto de BPM, las
lecciones aprendidas durante el mismo y que nos permitirn en sucesivos
proyectos no repetir errores y aprovechar el conocimiento y experiencias
de anteriores proyectos.
En este proceso de modelado del To-Be, modelaremos los procesos co-

mo nos gustara que fuesen. Este camino es lo que denominamos el Happy
Day, el camino feliz o escenario perfecto en el que el flujo del proceso nos
lleva a cumplir nuestros objetivos. Sin embargo, existirn excepciones a
este camino Happy Day en el que las cosas no siempre acaben bien y que
denominamos los Rainy Day o das lluviosos, en los que el flujo del proce-
so no cumple sus objetivos y este termina con un error o un camino de ex-
cepcin. Como vimos en los ejemplos descritos en el captulo anterior de
BPMN, estos casos son contemplados por la propia notacin, pudiendo ser
descritos y modelados, sin embargo existen otros posibles Rainy Day que
pueden encontrase fuera del modelo diseado. Este es el caso, por ejem-
plo, de algunas corporaciones que habiendo sustituido a todo el equipo que
anteriormente gestionaba una infraestructura para externalizar su gestin,
todo fall en este paso y nada funcion segn lo esperado, creando grandes
problemas a la organizacin, pues esta no tena todos los Rainy Days do-
cumentados, el conocimiento sobre la gestin de la infraestructura tambin
estaba en las personas y este no estaba representado en los modelos de la
infraestructura a gestionar.
283
Datos del proceso y Reglas de negocio.
Llegamos en este punto, en el que tenemos la definicin del As-Is, con

los procesos seleccionados y modelados, al momento en el que debemos
asignar datos e informacin a los mismos para poder conocer el rendimien-
to del As-Is y poder compararlo con posterioridad con el proceso mejorado
o To-Be y decidir sobre la conveniencia o no de realizar el cambio o mejora
del proceso. Los datos del As-Is los habremos ya recopilado durante el le-
vantamiento de procesos, aunque si estos no estn completos o nos falta
alguna informacin o dato necesario para la completa especificacin del
proceso, este ser el momento de recabarla. Si disponemos de una herra-
mienta BPMS (que es lo recomendable), pulsando sobre cada una de las
actividades de nuestro proceso, podremos introducir estos datos de forma
rpida y sencilla.
Datos del proceso.
Asignaremos recursos a las actividades y subprocesos y realizaremos el

clculo de tiempo y costes del proceso As-Is para calcular las lneas base de
Tiempo y Costes. Estas lneas base nos sern de gran utilidad a la hora de
realizar mejoras sobre los procesos para reducir su duracin y/o su coste.
En este apartado revisaremos las principales tcnicas y herramientas pa-

ra el clculo de costes y tiempos. Estas tcnicas derivadas de metodologas
de gestin de la calidad, six sigma y de la gestin de proyectos, nos permiti-
rn poder realizar estos clculos con la mayor exactitud, a fin de disponer
de una descripcin lo ms fiel posible de la realidad. Estas tcnicas debe-
mos conocerlas y usarlas para posteriormente y sobre los BPMS que vere-
mos en el captulo siguiente, poder introducir los datos de tiempo y costes
sobre el modelado del proceso y poner en marcha toda la potencia de BPM
en la herramienta de simulacin y de ejecucin de procesos, para analizar
bajo distintos escenarios los resultados de estos tiempos y costos y poder
tomar decisiones para sus mejoras.
Roles:
La asignacin de roles al proceso asignar responsabilidades y conducir

a los usuarios en el cumplimiento de sus tareas de forma que todos sepan
284
lo que tiene que hacer, cundo y cmo hacerlo. De esta forma, al estar el
proceso gobernado por estados, transiciones, flujos, responsables y reglas
de negocio, operar tal cual ha sido especificado su comportamiento y
donde el proceso dirigir el desempeo de los trabajadores asignados al
proceso.
La asignacin de roles al proceso, puede realizarse en la fase de modela-

do junto con las tareas que cada uno de estos roles deben ejecutar y permi-
tirn al trabajador disponer de la informacin y retroalimentacin necesaria
para el desempeo de sus tareas y la coordinacin de las mismas con el
resto de roles participantes en el proceso. Para ayudarnos en esta tarea de
asignacin de roles, podremos hacer uso de la informacin recogida en la
matriz RACI de asignacin de roles a los distintos perfiles y usuarios del
proyecto.
Debemos tener en cuenta que estos roles pueden ser realizados por
personas o sistemas informticos. Para las tareas ejecutadas por personas,
los BPMS usarn formularios web para interactuar con estas personas, al
estar prcticamente todas las soluciones BPMS desplegadas en portales
web y para los ejecutados por sistemas, dispondremos de las herramientas
de integracin que veremos un poco ms adelante en este captulo al
hablar de las integraciones. Estos distintos tipos de roles pueden colaborar
producindose interacciones entre ellos del tipo persona-persona, persona-
sistema y sistema-sistema, que a su vez pueden ser de la misma empresa o
unidad de negocio o de otras distintas, producindose en estos casos mo-
delos basados en coreografa y orquestacin de las que hablaremos en el
siguiente captulo.
Para la asignacin de roles o recursos humanos para la ejecucin de las

tareas, muchos BPMS disponen de funcionalidades para la gestin de recur-
sos y capacidad de asignacin de criterios, por ejemplo asignaciones por
carga de trabajo, secuenciales o por primero disponible.
Tiempos:
Haciendo un recorrido por las actividades del proceso que hemos mode-
lado, podemos hacer el clculo de la lnea base del tiempo que llevar el
proceso y sobre la cual podremos hacer mejoras de tiempos en el proceso.
285
Las dificultades en el clculo de tiempos suelen venir de las personas a

las que consultamos sobre la duracin de las actividades, pues las personas
suelen cubrirse en sus estimaciones y quedarse tanto por encima como por
debajo de las duraciones reales, por lo que con frecuencia, solemos pregun-
tar sobre la duracin de una determinada actividad a varias personas y rea-
lizar luego una media de las estimaciones recogidas. Adems de estas esti-
maciones, disponemos tambin de distintas tcnicas para el clculo de
tiempos como el basado en histricos de tiempos de las distintas activida-
des para estimar su duracin o el Mtodo de Montecarlo, implementado
perfectamente por los BPMS en las herramientas de simulacin, para ejecu-
tar la actividad repetidas veces por parte del motor de procesos y estimar
las medias de tiempos empleadas por las mismas.
Una vez sepamos el tiempo de cada actividad por los distintos mtodos
que hayamos escogido, podremos sumar los mismos segn el modelo de
procesos que hayamos dibujado y calcular el tiempo total de ejecucin de
un ciclo del proceso de Inicio a Fin, sobre el cual, todava deberemos aadir
tiempos de espera y retrasos que hayamos introducido en el proceso.
Costes:
El coste total del proyecto ser la suma de costes de las personas que
realizarn el trabajo, el coste de los recursos que emplearemos en el mismo
y costes varios de soporte al proyecto. Generalmente emplearemos la me-
todologa ABC (Activity-Based Costing), mediante la cual se asignan costes a
las actividades que realiza la organizacin, para luego calcular los costes
totales de ejecutar todas las actividades. El coste podremos asignarlo a los
procesos como un atributo ms, contabilizando el costo de las distintas
actividades, los cuales sern monitorizados como indicadores del proceso al
igual que el tiempo de ciclo de proceso.
Una vez hayamos finalizado con el clculo de tiempo y costes del proce-
so, dispondremos de una valiosa herramienta para sentarnos de nuevo con
el equipo para confirmar la exactitud del flujo de actividades, los tiempos y
costes asociados al proceso.
286
Documentacin del proceso.
En el modelado del proceso podremos incluir tambin la documentacin

asociada al mismo y llevar una completa gestin documental asociada al
proceso, de forma que esta gestin documental pase de ser un archivo ma-
sivo sin utilidad a convertirse en una herramienta de anlisis de la informa-
cin y gestin del conocimiento. Estas soluciones de gestin documental,
pueden estar dentro de los BPMS o enlazadas con aplicativos externos,
pero en cualquiera de los casos, deben proporcionar gestin de archivos y
documentos electrnicos y fsicos, imgenes, sonidos, vdeo, e-mail, fiche-
ros ofimticos, informes, etc. as como capacidades de firma electrnica,
seguimiento de circuitos de aprobacin y verificacin, confidencialidad y
seguridad de los archivos y documentos.
Reglas de negocio.
Otro aspecto a modelar ser el de las reglas de negocio, las cuales regi-
rn el comportamiento del negocio, indicando qu estar permitido y qu
no lo estar, as como las consecuencias de la violacin de estas reglas.
En todo negocio u organizacin tenemos reglas de negocio que debemos

tener en cuenta en nuestros modelos, tanto a la hora de disear la estrate-
gia como al realizar los modelos organizacionales o los de procesos. En to-
dos los casos, existen reglas de negocio asociadas a la prevencin de riesgos
laborales, la salud de los trabajadores, al trato con clientes, las legislaciones
aplicables a cada negocio y un largo etctera de reglas que debemos respe-
tar. Las reglas de negocio se formarn como construcciones semnticas
(ordenes o consejos) que regirn el comportamiento del negocio: esto no
se puede hacer, aquello debe ser tenido en cuenta, etc. Estas reglas nos
indicarn, qu es necesario hacer, que es imposible que hagamos o qu es
posible hacer bajo ciertas condiciones y vendrn casi siempre derivadas de
las Polticas de negocio establecidas en el Business Motivation Model, don-
de recordemos que las reglas de negocio gobiernan los Course of Action del
Maturity Model y gobiernan y limitan la estrategia en la medida en que dan
forma a como la estrategia puede ser lograda, por lo que trasladada esta
estrategia a nuestros modelo de procesos, cuando establezcamos las reglas
de negocio que debemos respetar en las actividades o gateways de nuestro
diseo en BPMN, estas reglas marcarn el diseo de nuestros procesos y en
consecuencia de nuestra estrategia.
287
De esta forma, regidas por la estrategia, las reglas de negocio pueden, y

en muchos casos suele ser as, contener todo el conocimiento de la organi-
zacin, necesario para implementar completamente los procesos de la
misma y es por ello necesaria una completa definicin de las mismas para
disponer de un correcto modelado de los procesos de negocio. Modelar los
procesos basndonos en las reglas de negocio, permite a la gente de nego-
cio entender y expresar los requerimientos, asegurando la consistencia en
las operaciones y cumplimiento de las legislaciones y nos permitir expresar
un proceso sin necesidad de definir todas sus configuraciones posibles,
pues las reglas marcarn el camino. La consideracin de las reglas de nego-
cio tendr un importante papel en la mejora de procesos que veremos en la
siguiente fase de este captulo, en la que deberemos asegurarnos de que las
mejoras a implementar no contraponen aspectos legales y/o normativos,
pues de no hacerlo, corremos el riesgo de que la mejora no pueda ser im-
plementada o cause graves prejuicios a la organizacin.
Para la composicin de reglas de negocio existe un estndar SBVR (Se-

mantics of Business Vocabulary and Business Rules), en el cual podremos
ver la semntica de las distintas reglas de negocio que a diferencia de otros
tipos de modelado de negocios, no tiene una representacin grfica. SBVR
es un estndar traducible a software, es tambin un estndar del OMG
desde el ao 2008 e incluye versiones en distintos idiomas.
Existen seis formas de reglas de negocio:
- Obligatorias: son las ms comunes de las reglas de negocio y

son usadas cuando queremos asegurar que algo sea verdad.
- Prohibitivas: realizadas para prevenir determinadas actuacio-
nes. Est prohibido hacer esto.
- Restrictivas: permite algo excepcionalmente, pero establece
una restriccin bajo ciertas condiciones en cuyo caso no puede
ser permitida.
- Necesarias: cuya estructura es de la forma: es necesario que,
ocurra una situacin si se establece una condicin.
- Imposibles: con la estructura semntica: es imposible que
ocurra algo que no debe suceder si una condicin.
- Posiblemente restrictivas: que describen que puede ser verda-
dero pero slo bajo determinadas condiciones: es posible que
una situacin ocurra slo si restriccin.
288
A la hora de escribir nuestras reglas de negocio deberemos escoger de

entre estos tipos las ms convenientes para cada situacin.
Mejora de procesos.
Ahora que disponemos del As-Is del proceso de nuestra organizacin

con su modelado, roles, tiempos, costes y reglas de negocio, estamos en
disposicin de producir el To-Be del mismo, efectuando mejoras en la
eficacia y eficiencia del proceso. Durante el levantamiento de procesos del
As-Is, ya habremos sin duda recogido informacin e ideas sobre cmo
mejorar posteriormente el proceso. Toda esta informacin, junto con la
descripcin del proceso y en especial la informacin sobre el alcance del
proyecto, requisitos de stakeholders y del proceso, nos servirn de hoja de
ruta sobre la cul encaminar nuestros pensamientos a la hora de mejorar el
proceso en cuestin.
Un aspecto muy importante ser el moverse rpidamente desde la fase

de levantamiento de procesos hacia esta fase de mejora, para que el pro-
yecto no se duerma en el cajn del olvido y aprovechar los esfuerzos reali-
zados en la fase anterior y la inercia ejercida sobre el proyecto, la organiza-
cin y las personas, para continuar el mismo rpidamente hacia la mejora
de procesos. Es ms fcil ir rpido ahora que pasado el tiempo, y aprove-
char ahora la disposicin del equipo de proyecto, las ideas y oportunidades
recogidas en la fase de levantamiento de procesos para saltar rpidamente
hacia el camino de la mejora de estos. Como deca el famoso fsico Erwin
Schrodinger, los sistemas dejados a su aire durante mucho tiempo acaban
inmovilizndose y uniformando su temperatura y al final todo el sistema se
disuelve en una masa material totalmente inerte. En las empresas, solemos
pasar la mayor parte del tiempo en las actividades del da a da, dejando
poco tiempo para analizar el funcionamiento de nuestros procesos, medir-
los, mejorarlos, optimizarlos o buscar soluciones innovadoras sobre los
mismos que redunden en beneficio de nuestros clientes y en la eficiencia de
la organizacin. En BPM, cambiamos esta actitud por otra en la que los res-
ponsables de negocio debern pasar ms tiempo trabajando en la monitori-
zacin, mejora y optimizacin de los procesos de la organizacin, en la me-
dida que consideran a los procesos como activos fundamentales de la em-
presa para alcanzar sus objetivos de negocio y en consecuencia son cons-
cientes de la necesidad de su mejora y optimizacin continua.
289
Al igual que en la fase anterior, esta fase se realizar tambin en base a

reuniones de trabajo, siguiendo el modelo que utilizamos durante el levan-
tamiento de procesos, para que con la colaboracin de todo el equipo de
proyecto y la ayuda de un analista que rena las opiniones de todo el equi-
po y modele y documente las aportaciones de los mismos, vayamos diri-
giendo y modelando el To-Be.
Una vez conocido y desvelado el As Is lo descomponemos y analizamos

los procesos en detalle y diagnosticamos las debilidades, cambiando a un
mejor modelo de procesos que corrija esas debilidades. Luego comparamos
el To-Be con el As-Is para ver si mejoramos. Al igual que en la fase anterior
deberemos cargar sobre el modelo los datos, informacin y medidas sobre
los procesos mejorados que vayamos diseando, con objeto de ir compa-
rando los resultados con el As-Is y los Could-Be realizados y analizar las me-
joras alcanzadas. En este punto podremos hacer uso de las herramientas de
simulacin como las proporcionadas por las plataformas BPMS que descri-
biremos en las siguientes fases.
Finalmente una vez alcanzado el To-Be, desarrollaremos un plan de ac-

cin para evaluar los costes de implementar el nuevo modelo, conseguir el
entendimiento y la comprensin sobre las mejoras propuestas en el proce-
so por parte de todo el equipo, las ventajas que este nuevo modelo ofrece y
la necesidad de su implementacin para obtener la aprobacin y apoyo de
los patrocinadores del proyecto y, si los beneficios de su implementacin
superan a los costes, procederemos a implementar el nuevo modelo con lo
cual ya tenemos un nuevo y mejorado As-Is.
El levantamiento de procesos, como ya explicamos, es un proceso itera-

tivo y no es un ejercicio que se haga una sola vez. Una vez que hemos em-
pezado a implementar procesos, estaremos constantemente trabajando en
su mejora y en consecuencia, tambin en el nuevo To-Be consensuado por
la organizacin que pasar a ser el nuevo As-Is.
El procedimiento a seguir en esta fase, una vez seleccionado el proceso

sobre el que trabajaremos, atendiendo a los criterios vistos en la fase de
levantamiento de procesos, ser obtener el acuerdo de los miembros del
equipo y de los sponsor sobre la eleccin del proceso a mejorar, para luego
dar por iniciada la fase y los trabajos para la mejora de procesos o el diseo
de un nuevo proceso. Esta fase puede ser vista y gestionada como un nuevo
proyecto, para el cual deberemos elaborar un plan de proyecto aparte, que
incluya cuando menos los objetivos y el alcance de la mejora que se pre-
290
tende llevar a cabo, as como los tiempos, los costes, los recursos necesa-
rios para ejecutarla y un anlisis del el impacto de estas mejoras sobre la
organizacin. Como acompaamiento a este plan de proyecto de mejora de
procesos, deberamos disponer de un diagrama que muestre el modelado
del nuevo proceso y si es posible, una simulacin del comportamiento de
este y de los posibles resultados que se obtendrn con su implementacin.
As mismo, deberamos tener ya establecidas las medidas e indicadores que
utilizaremos para el control y monitoreo del proceso, pues estas nos ayuda-
rn a determinar si las mejoras sobre el proceso satisfacen los requerimien-
tos de la organizacin y de sus clientes en cuanto a eficacia y eficiencia.
Un aspecto importante al entrar en esta fase, es el de no tener la ten-

dencia a ir directamente a la herramienta de modelado o a un BPMS a dise-
ar los rectngulos y diamantes de los procesos sin haber dedicado el tiem-
po suficiente a las tareas de diseo de la estrategia y el desglose de la mis-
ma, segn hemos visto en el Motivation Model. Este es el caso de los pro-
gramadores software con poca experiencia en proyectos, que tras una con-
versacin de requisitos globales con un cliente, se lanzan directamente a
escribir lneas de cdigo sin haber diseado, contrastado, analizado y con-
sensuado previamente la solucin final con el cliente, con el consiguiente
riesgo de prdida de tiempo y calidad en el proyecto.
Muchas veces las mejoras y soluciones sobre nuestros procesos, al igual

que le ocurre al intrpido programador de antes, nos parecen obvias y
creemos saber perfectamente qu nuevos procesos o mejoras sobre los
existentes son necesarias realizar. Estas mejoras surgirn sin mayor esfuer-
zo por el propio personal de la empresa cuando identifican un problema
crtico y conocido, una oportunidad potencial de cambio o una nueva ma-
nera de hacer las cosas, por lo que ya en la fase de Levantamiento de Pro-
cesos, tendremos identificado o una aproximacin muy cercana al To-Be
deseado. En estos casos, las fases de levantamiento y mejora de procesos
pueden ser realizadas al mismo tiempo, sin embargo este no ser el caso
normal, sino que estas fases se realizarn por separado. De todas formas y
aunque estas mejoras tan directas resulten obvias, deberemos revisar las
mismas, en especial en la alineacin de estas mejoras con los objetivos or-
ganizacionales, asegurndonos de que estos son alcanzables y derivan de la
estrategia de la organizacin. Deberemos pensar no slo en los procesos
sino tambin en trminos de Arquitectura de Procesos, que es algo mucho
ms amplio e incluye a toda la organizacin, su modelo de negocio, la estra-
tegia y los objetivos de negocio, as como todos los procesos y las relacio-
nes entre ellos. Es de nuevo el pensamiento sistmico e integrador bajo el
291
que debemos considerar los distintos elementos, las relaciones entre los
mismos y el entorno que conforman en lo que denominamos sistema. En
esta visin, surge la variedad interpretativa, de forma que pueden existir
diversas visiones de la organizacin dependiendo de quien la vea y como la
vea y comprenderemos con mayor profundidad los problemas de la esta,
sus mltiples causas y consecuencias, pues todos los departamentos de la
empresa, tecnologas, clientes, proveedores y sistemas que la conforman,
estn interrelacionados y en consecuencia, existen muchos procesos que la
sustentan, donde la suma de todos ellos y no los procesos aislados, es lo
que conformar su cadena de valor.
Esta fase de anlisis del As-Is en la bsqueda de mejoras sobre el mismo,

es la fase ms creativa y en la que mayores dosis de innovacin sern re-
queridas de los miembros del equipo y de toda la organizacin en general
para intentar alcanzar los resultados ms espectaculares posibles. El papel
del director de proyecto en esta fase ya no ser el de la fase anterior de
guiar hacia la consecucin del objetivo de obtener el As-Is que refleje lo
ms fielmente posible la realidad de los procesos de la organizacin, sino
que ahora el director de proyecto deber ser un motivador, con habilidades
en direccin de equipos creativos e innovadores, que sea capaz de dirigir el
mismo hacia las mejores transformaciones posibles sobre el proceso y no
se quede en las mejoras obvias, alcanzadas rpidamente, sino que procure
persistentemente nuevas y mejores soluciones. Para esta tarea, el poseer
experiencia en la gestin de la innovacin y metodologas de gestin de
equipos innovadores, resultar de especial importancia.
Adems de las mejoras sobre los procesos, es decir sobre el modelado

de la secuencia de actividades que debern ser ejecutadas para que el pro-
ceso pueda ser implementado y por la naturaleza cambiante de las empre-
sas, deberemos revisar y analizar tambin los procesos al ms alto nivel de
la organizacin, como el modelo de negocio sobre el cual consideraremos
distintos tipos de anlisis:
- Anlisis de mejora: los negocios pueden ser siempre mejorados,

los negocios cambian y las oportunidades y amenazas pueden
ser aprovechadas o deben ser controladas. Con el anlisis de
mejora del negocio se busca mejorar el modelo de negocio y
no el modelado del proceso, para ello haremos uso extensivo
del Motivation Model, que puede llevarnos a tener que realizar
cambios en la estrategia, definicin de metas, objetivos o tcti-
cas necesarias para conseguir los resultados esperados.
292
- Anlisis de Transformacin: para apoyar una trasformacin o

reingeniera en la empresa debido a cambios en el modelo de
negocio.
- Anlisis de impacto: conocer las consecuencias de un cambio
propuesto sobre el negocio, para lo cual usaremos tcnicas co-
mo las de anlisis de riesgos, identificacin de los mismos y su
anlisis cualitativo y cuantitativo para medir y evaluar su impac-
to.
- Anlisis de adquisicin: para ayudar en la toma de decisiones
sobre adquisiciones o fusiones de empresas, que suelen tener
amplias repercusiones tanto en las estructuras organizacionales
de las mismas, como en los modelos de negocio surgidos de es-
tas fusiones y adquisiciones y las nuevas reglas y procesos inte-
grados que sern necesarios para la operativa de la nueva or-
ganizacin.
Tcnicas de mejora de procesos.
A continuacin describimos las seis tcnicas de mejora de procesos en

forma de rueda de mejora de procesos descritas por Susan Page, las cuales
deben ser realizadas comenzando con la Burocracia y continuando con las
restantes en el sentido de las agujas del reloj, con el fin de ir avanzando en
un proceso lgico hasta la ltima de las tcnicas que es la Automatizacin.
293
1. Eliminar la burocracia:
La burocracia es la administracin que realizan las unidades funcionales

mediante el procesamiento de informacin y que ha alcanzado tan mala
fama que en los diccionarios nos encontramos con una definicin de la
misma en la que se dice que es la influencia excesiva de los empleados p-
blicos en los negocios del estado.
La mayor parte de los procesos con los que nos encontremos y que no
funcionan correctamente son debidos bien a que los procesos funcionan en
silos departamentales, donde no existe un responsable de todo el proceso
en su conjunto y los problemas debidos a la burocracia con la que se en-
cuentran los trabajadores en su da a da y que consume gran parte de sus
jornadas laborales, pero que es en muchos casos de obligado cumplimiento
a pesar de las quejas de estos. Estas tareas burocrticas frecuentemente
consisten en cargas de datos o en la elaboracin de documentos, siguiendo
una serie de pasos para reportar a niveles superiores de la organizacin. A
la hora de analizar el impacto de la burocracia sobre nuestros procesos,
debemos pensar como Jack Welch, quien denominaba a la burocracia como
la enemiga de la productividad y en este sentido, pensar en ella como el
enemigo a eliminar de nuestros procesos de negocio, por lo que el proce-
dimiento que seguiremos con esta tcnica ser el identificar en nuestro
modelo de procesos las tareas burocrticas, haciendo a los usuarios partici-
pes en la identificacin de estas tareas y fijarnos en casos tpicos de buro-
cracia como los informes y necesidades de aprobacin.
En la eliminacin de la burocracia debemos indagar sobre aprobaciones,

pues algunas pueden ser reducidas o eliminadas en el caso de que se en-
cuentren fuera de los lmites del proceso sobre el que estamos trabajando,
si se toman las decisiones en los lugares adecuados y si estas son necesarias
para el proceso, el nmero de copias de documentos que circulan por el
proceso, a cuantas personas necesitamos enviarlos, si esta informacin que
enviamos es realmente necesaria y no es redundante y si las reglas y regu-
laciones que acatamos son necesarias para el proceso. La actitud es la de
preguntarse constantemente por la necesidad de los procedimientos buro-
crticos, si se encuadran en los lmites del proceso, su necesidad real, si
consumen tiempo y dinero y valorar si aportan valor al cliente. En el proce-
so de eliminar tareas burocrticas, la mayor dificultad la encontraremos en
la costumbre de la organizacin de realizar muchos de estos pasos, por lo
que los consideraran necesarios y nos dificultar el convencer a la misma
para su eliminacin.
294
En esta eliminacin de la burocracia deberemos prestar especial aten-

cin y evaluar las actividades denominadas SALT (Statutory; Audit; Legal;
Tax) pues ests no deberan ser eliminadas y permanecer en la proceso.
- Statutory (Estatutaria): que la actividad sea una legislacin o es-

tatuto de algn gobierno.
- Audit (Auditora): para chequear el cumplimiento con determi-
nadas reglas.
- Legal (Legal): que la actividad est relacionada con el cumpli-
miento de una ley.
- Tax (Impuestos): que la actividad implique el pago de tasas o
impuestos.
2. Generar Valor:
Analizar la cadena de valor del negocio e identificar actividades que no

aporten valor o satisfagan las necesidades de nuestros clientes, siendo im-
placables en la eliminacin de las actividades que no aporten valor.
Para decidir que tareas no aportan valor, debemos pensar en las necesi-
dades o demandas de nuestros clientes en trminos de calidad, costo,
tiempo de entrega y servicio y revisar las actividades de la cadena de valor.
El procedimiento para la identificacin de estas actividades puede ser

parecido al siguiente:
295
Muchas veces en BPM pensaremos a la hora de definir procesos en qu

pensara el cliente sobre el proceso si conociese el funcionamiento interno
del mismo? y nos haremos la pregunta: si el cliente conociese estos deta-
lles del proceso, pagara por el producto o servicio? Al cliente slo le inter-
esa el producto o servicio resultado del proceso y no los pasos intermedios
y procesos internos que la empresa realiza para proporcionarle ese produc-
to o servicio. La gestin por procesos, el anlisis de la cadena de valor que
realicemos y de cmo cada actividad contribuye a la generacin de valor a
nuestros clientes para la eliminacin de las actividades que no aportan va-
lor, nos permitir tener la seguridad de que toda la organizacin se dirige
hacia la optimizacin de sus procesos y en consecuencia a la satisfaccin de
sus clientes.
Para la generacin de valor, deberemos facilitar que los procesos reci-

ban o aporten datos de su operativa y de los sistemas con los que se inte-
gran, analizando las medidas e indicadores establecidos para el proceso,
analizando las tareas repetitivas y que no aportan valor y centrndonos en
las tareas productivas para reducir los tiempos de operacin.
296
3. Eliminar duplicados:
Generalmente estas duplicidades las encontraremos en el reporte de in-

formacin, la carga de datos o en las tareas desempeadas por mquinas,
sistemas o personas que realizan la misma tarea.
En otros casos los duplicados ocurren en las organizaciones funcionales y

departamentales, donde varios de estos departamentos se ven involucra-
dos en un proceso sin integracin entre ambos departamentos y donde
cada uno gestiona sus datos sin ser conscientes de que los datos son re-
dundantes con otros departamentos o por el hecho de que cada departa-
mento quiera conservar sus propios datos. En este caso, tenemos adems
de la posibilidad de reducir y simplificar el proceso, la oportunidad de traba-
jar hacia una integracin de datos o de evolucionar administrativamente
hacia una organizacin orientada a procesos.
4. Simplificar:
Reducir o eliminar la complejidad de las actividades o del proceso en su

conjunto de forma que este sea ms eficiente, que eliminemos la compleji-
dad con la que tendemos a disear nuestros procesos y negocios, convir-
tindolos en autnticos dinosaurios y que provocar que en muchos casos,
para eliminar la complejidad pueda ser necesario redisear completamente
el proceso o subdividir el mismo.
Los modelos que diseemos deben ser simples, pero manteniendo todo
su significado y sin prdidas de informacin. Desde luego que crear mode-
los simples es mucho ms difcil que crearlos complejos, pero la simplicidad,
la necesitaremos para que todo el mundo entienda lo que estamos mode-
lando y describiendo, desde los modelos organizacionales, a los estratgicos
y los modelos de procesos. Para esta simplicidad nos centraremos en lo
importante de los modelos, omitiendo los elementos innecesarios y que no
aporten valor. Entre las tcnicas para realizar la simplificacin se encuen-
tran: la revelacin selectiva y la descomposicin jerrquica, la primera usa-
da para mostrar los diagramas por partes, de forma que en cada uno de
ellos mostremos parcelas de realidad en lugar de mostrar todo sobre un
mismo diagrama que lo har mucho ms ininteligible y la segunda para
simplificar la representacin mediante el agrupamiento en niveles jerrqui-
cos.
297
Esta simplificacin la llevaremos no slo al diseo de los procesos, sino

tambin a las arquitecturas empresariales, la estrategia y el Motivation
Model, de forma que todos puedan entender estos modelos y podamos
usarlos como herramientas efectivas de comunicacin en las distintas ver-
siones de los modelos durante el desarrollo del proyecto.
En BPM, como en la arquitectura, y recordando la frase del famoso ar-

quitecto Ludging Mies van der Rohe, que revolucion el diseo arquitect-
nico a nivel mundial: menos es ms o la versin de Bertrand Russel sobre
la Navaja de Ockham: La explicacin ms simple suele ser la mejor.
5. Reducir el Tiempo:
Los tiempos de ejecucin del proceso son percibidos tanto por la empre-
sa ejecutante del proceso como por los clientes, siendo ambos bastante
sensibles a largos tiempos y esperas. El objetivo en esta fase de la mejora
de procesos es buscar y reducir la duracin de aquellas actividades que
consuman demasiado tiempo y responder de forma ms rpida a nuestros
clientes, buscando las causas de los retrasos e identificando alternativas
que puedan implicar un aumento del personal y de los costes para poder
hacer frente a tiempos de entrega y de proceso ms cortos.
En este punto, y antes de pasar a la automatizacin, podremos retomar

la aplicacin de las tcnicas de Lean Six Sigma que nos ayudarn en estas
tareas de reduccin de tiempos y complementarn a otras actividades para
la mejora de procesos. Como vimos al hablar de Lean Six Sigma, esta meto-
dologa, adems de centrarse como Six Sigma en el control de procesos,
aborda tambin el diseo y mejora de los procesos en base a una metodo-
loga para la eliminacin de las tareas que no aportan valor y que denomina
desperdicios, analizando las actividades y tareas en los niveles ms bajos
del proceso en busca de estos desperdicios y centrndose en actividades
del tipo:
- actividades de Superproduccin: que por falta de feedback de

otras actividades, continan produciendo salidas una vez han
sido paradas.
- actividades En Espera: tiempos de inactividad en las actividades
debidos a los tiempos de entrega de otras actividades.
- actividades de Transporte: debidos al innecesario movimiento
de materiales o almacenamiento innecesario de los mismos.
298
- actividades de Extra-procesado: actividades extra realizadas por

el proceso.
- actividades de Inventariado: exceso de materia prima o bienes
terminados.
- actividades de Movimiento: debidos a pasos ejecutados que no
son necesarios en el proceso o actividad.
- actividades de Defectos: productos no conformes que provocan
que se tenga que volver a realizar una actividad o todo el pro-
ceso.
6. Automatizacin:
Analizaremos qu puede ser automatizado para hacer el proceso ms

eficaz y eficiente a travs de la tecnologa, atendiendo a si es la tecnologa
la que dirigir el proceso o es el proceso quien dirigir la tecnologa.
Bill Gates, el gran apologista de las TIC reconoci en cierta ocasin la im-
portancia de los procesos como paso previo a la automatizacin y el empleo
de las TI, segn Gates: La primera regla de cualquier tecnologa es que la
automatizacin aplicada a una operacin eficiente magnifica su eficiencia.
La segunda regla es que aplicada a una operacin ineficiente la har ms
ineficiente.
Este enunciado de Bill Gates, pasar a convertirse en una de las mximas

de los proyectos de BPM y del fundamento de la necesidad de la correcta
optimizacin y gestin por procesos como paso previo a su automatizacin
y no como suele ocurrir en muchos proyectos de BPM, donde la primera
tendencia es automatizar el As-Is, escogiendo adems el proceso ms im-
portante de la empresa. Aunque esto nos pueda funcionar, donde obten-
dremos los mejores resultados ser corrigiendo los cuellos de botella, du-
plicados de procesos e informacin y otras medidas de mejora de procesos,
ms que en la simple automatizacin. Si un proceso por s mismo es err-
neo, automatizarlo slo conseguir producir errores con mayor rapidez.
Con BPM disponemos de una herramienta nica para la automatizacin
pero no debemos olvidar hacerlo slo cuando estos se encuentren perfec-
tamente optimizados y probados. En los ltimos aos hemos automatizado
todo lo que hemos podido en las empresas: facturas, inventarios, ventas,
sistemas de workflow y de gestin documental. La tendencia es a automati-
zar todo lo posible o automatizable en las organizaciones (soluciones sim-
ples a problemas complejos), pero esta automatizacin aplicada a procesos
299
no eficientes, har fracasar la automatizacin y esta ya no ser la solucin a

nuestros ineficientes procesos. Tal vez un buen recordatorio de esta nece-
sidad de disponer de unos procesos perfectamente definidos, optimizados y
derivados de la estrategia y metas empresariales como paso previo a su
automatizacin, la tendremos recordando lo ocurrido en las masivas im-
plementaciones de ERPs y porque estas no han significado los aumentos de
eficiencia, productividad y competitividad esperados.
Por qu las soluciones software fallan en muchos casos y no se obtie-

nen los resultados esperados? La respuesta puede recaer en lo que deca
Bill Gates. Automatizar algo no resuelve los problemas de ese algo, slo
ayuda a que ese algo ocurra ms rpidamente y con ms frecuencia, pues
esta es la base de la automatizacin. Si automatizamos un proceso inefi-
ciente, este se ejecutar automtica e ineficientemente todas las veces que
recurramos a l. En los procesos o sistemas se dice que Garbage in, Garba-
ge out (Basura entra, basura sale), para indicar que si las entradas son
basura, saldr basura y los resultados que producirn el caos y la inefi-
ciencia automatizada sern catastrficos para la organizacin.
Entonces por qu las organizaciones no resuelven sus procesos antes

de mirar hacia la automatizacin? Principalmente porque estas organiza-
ciones, las personas y los procesos que la sustentan, se han mantenidos
inmutables durante dcadas. El pensamiento es que da lo mismo que los
procesos no sean muy eficientes, funcionan y ya est, para qu vamos a
cambiar algo que funciona y correr el riesgo de que deje de funcionar? La
consecuencia de este pensamiento es que no se trabaja en la optimizacin
y mejora de los procesos previamente a su automatizacin, se automatiza
sin ms, como una apuesta a ciegas. Muchas veces, esta automatizacin se
realiza para apartar a personas de determinados procesos, es la solucin
sencilla, compro una solucin software y me quedo tranquilo, ya no tengo
que preocuparme del proceso ni de las personas, he pagado por una solu-
cin! y me desvinculo del problema. Es el comportamiento del consumista y
su visin idealizada de lo que necesita frente a lo que realmente contrata.
La palabra automatizacin viene del griego automatos que significa

semejante a la forma en que trabaja tu mente. La automatizacin es lo
primero que nos viene a la cabeza cuando pensamos en mejorar y simplifi-
car los procesos, sin embargo, la gran mayora de mejoras pueden ser al-
canzadas sin automatizacin, simplemente centrndonos en pensar en
nuestra organizacin, en su arquitectura, modelo de negocio y analizando y
300
mejorando los procesos que desarrolla, buscando las causas de los proble-
mas y no poniendo tiritas sobre los sistemas observados en el da a da.
La automatizacin, no significa cambiar o sustituir todos los sistemas ac-

tuales que operan en la empresa, sino de dotar a los mismos de la capaci-
dad de integrarse con el proceso de negocio, de forma que esta automati-
zacin hable y se entienda con el proceso. Al hablar de automatizacin,
realizaremos una reflexin profunda sobre la necesidad y ventajas de la
misma y como llevarla a cabo, analizando los costes asociados, si se har en
varias fases o de golpe, subcontratando o hacindola internamente, etc. En
este sentido, podemos seguir la recomendacin seguida en la implantacin
de sistemas TI y ERPs de no hacer la automatizacin de golpe y permitir la
evolucin de los sistemas y automatizaciones desde las ms bsicas y fun-
cionales a las ms complejas.
De la lectura de este apartado, el lector puede quedarse en una situa-

cin de estancamiento respecto a la automatizacin, o pensar que existen
dudas sobre la conveniencia de realizar o no la misma. No es esta nuestra
intencin y por supuesto, abogamos por la automatizacin de procesos
como el factor ms relevante a la hora de mejorar la competitividad de las
empresas y en BPM en particular, dispondremos de las herramientas para
esta automatizacin, pero la intencin es transmitir al lector la premisa
bsica de la automatizacin de que esta debe ser realizada slo sobre pro-
cesos eficientes. A partir de aqu y si los procesos son correctos, nos enca-
minaremos hacia la automatizacin que nos permitir dar el gran salto en la
composicin de nuestros procesos y negocios gracias a unas capacidades
tecnolgicas cada vez ms fiables y avanzadas.
Otro aspecto al hablar de automatizacin es el del papel de las personas.

Deca Warren G. Bennis, que las empresas del futuro tendrn dos emplea-
dos: un hombre y un perro. El hombre estar all para alimentar al perro; el
perro estar para que el hombre no toque los equipos y sistemas. Pero
mientras este hipottico futuro no ocurre, deberemos prestar especial
atencin a las personas, pues con la automatizacin, tendemos a olvidarnos
a no considerarlas y sean los procesos manuales o automticos, sern las
personas en ltima instancia las que van a hacer que los procesos funcionen
o no, sin importar el grado de automatizacin de los mismos. Sino implica-
mos a las personas que disponen del conocimiento de los procesos en el
anlisis y diseo de los mismos, la automatizacin no ser tampoco todo lo
eficiente que debera ser.
301
Visin holstica
A la hora de optimizar el proceso no debemos perder la visin de mejora

de todo el proceso y no slo de determinadas partes del mismo. Recurri-
mos de nuevo a la visin holstica de la organizacin, a la visin de la orga-
nizacin orientada a procesos y no a la organizacin departamental orien-
tada a funciones especficas.
La mejora de determinadas partes del proceso, actividades o aspectos

locales del proceso propuestas por los expertos (SMEs) de determinados
departamentos, no implicar siempre la mejora del proceso global, que es
la meta que perseguimos. Esta situacin es parecida al Equilibrio de Nash,
que debe su nombre al matemtico John Forbes Nash y sobre el que se
rod la pelcula protagonizada por Rusell Crow Una mente maravillosa. En
el equilibrio de Nash, se describe una situacin en que todas las partes in-
tentan maximizar sus beneficios sin cooperar ni tener en cuenta las consi-
deraciones de las otras partes y donde vemos, al igual que en el dilema del
prisionero, que esta estrategia en la que las ganancias de uno implican
grandes prdidas para otro, no siempre es la mejor solucin (juegos de
suma Nula, donde la victoria de un jugador implica la derrota de otro) y
existen opciones para que todos puedan ganar si cooperan en la solucin
de problema.
Para alcanzar el consenso, el equilibrio de Nash o que el resultado del

proceso global sea lo ms eficiente posible para todas las partes, todos los
involucrados en las distintas partes del proceso deben colaborar, y el direc-
tor de proyecto, a travs de las reuniones de trabajo que realice, debe fo-
mentar esta colaboracin, y no los intereses particulares de unos departa-
mentos especficos, o que unos ms que otros, fagociten las reuniones o
centren toda la atencin del proceso global en su parcelas de especializa-
cin, pues esta es una tendencia muy comn y fcilmente observable en
muchas de las personas desde las primeras reuniones de trabajo que lleve-
mos acabo en el proyecto.
Medidas, indicadores y anlisis del proceso:
Llegamos al punto en el que hemos mejorado nuestro proceso, habien-

do obtenido un nuevo As-Is mejorado. El siguiente paso ser aplicar las
medidas que vamos a tomar para medir y controlar que el proceso se com-
302
porta segn los objetivos planteados sobre el mismo y alcanzamos los resul-
tados esperados. Para ello, tendremos que identificar y desarrollar esas
medidas, medirlas en el proceso, ver que podemos hacer para mejorar esas
medidas, si existen desviaciones en las mismas e implementar los cambios
para volver a medir y decidir si los resultados son conforme a lo esperado o
tenemos que redisear el proceso.
El proceso de medicin lo deberemos contemplar desde las fases ms

tempranas, tanto en el Levantamiento de Procesos, identificando las medi-
das e indicadores de los mismos, como en la fase de mejora de procesos, al
ser las medidas e indicadores el nico medio por el cual podemos diagnos-
ticar y evaluar el funcionamiento del proceso y sus resultados en relacin
con el cumplimiento de los objetivos por los que fue diseado.
El medir el rendimiento de los negocios no es algo nuevo y ha sido siem-

pre utilizado desde hace siglos para el control de las operaciones por parte
de individuos, departamentos y empresas y revisar el cumplimiento de ob-
jetivos respecto a lo inicialmente planificado. El tipo de medidas utilizadas
por las organizaciones ha evolucionado desde las ms simples y las mera-
mente financieras, a medidas ms desarrolladas que nos permitan hacer
frente a los retos de futuro de la empresa, seleccionando para ello los indi-
cadores no slo financieros sino tambin aquellos necesarios para alcanzar
los objetivos estratgicos.
Estas medidas e indicadores asociados a las operaciones, rendimiento y

cumplimiento de la estrategia de la organizacin, son de vital importancia
para la misma y su seleccin debe ser cuidadosamente realizada y comuni-
cada a los miembros de la organizacin de forma que todos comprendan
como sus comportamientos, actitudes y actividades afectan a los buenos
resultados de estas medidas.
Otro aspecto a tener en cuanto en la elaboracin de medidas, es que

muchas de estas, y tal vez las ms importantes, se establecen sobre los
resultados globales de la empresa y el cumplimiento de su estrategia, por lo
que tenemos aqu una estrategia ms para derribar los silos de informacin
de la empresa funcional, estableciendo medidas e indicadores conjuntos del
proceso y no recabando estas medidas asociadas a departamentos o per-
sonas concretas de la organizacin. Esto implica que los indicadores que
definamos para nuestros procesos deben estar directamente relacionados
con algn aspecto de la estrategia de la empresa siguiendo el camino: Indi-
cador-> Metas -> Objetivos -> Estrategia.
303
La informacin sobre los resultados y rendimiento de las organizaciones

es como sabemos fundamental para el control de la misma y de alguna
manera, todas las organizaciones miden y monitorizan su actividad con ms
o menos indicadores de rendimiento y beneficio y con ms o menos fre-
cuencia. Todas las empresas son conscientes de que disponer de esta in-
formacin lo ms actualizada y fiel posible a la realidad, es importantsimo
para la gestin de la misma y poder corregir a tiempo los problemas, erro-
res o malos resultados que obtengamos de esas medidas. De la herencia de
la contabilidad de costes, las empresas estn acostumbradas a medir slo
sus resultados financieros, pero este tipo de medidas, a pesar de seguir
siendo importantes para evaluar los resultados econmicos de la empresa,
no son suficientes cuando queremos evaluar el rendimiento de los procesos
asociados a nuestra cadena de valor y de los cuales dependen los resulta-
dos financieros. Kaplan y Norton, los creadores del concepto de Balanced
Scorecard, apuntaban que estos indicadores financieros podan incluso
llevarnos a error, cuando enfocamos nuestros objetivos en aspectos como
la mejora continua y la innovacin.
El establecimiento de mtricas y la recogida sistemtica de informacin

sobre los procesos, debe centrarse en los focos de los problemas y por ello,
las mediciones deben ser sobre aspectos relacionados con el negocio. Estas
mediciones debern ser analizadas y comparadas para establecer tenden-
cias, informes estadsticos de los procesos, identificar cuellos de botella o
comportamientos no deseados para optimizar su ejecucin y aplicar cam-
bios al modelo que favorezcan la mejora continua.
Indicadores de negocio.
No podemos gestionar lo que no medimos. Sin las medidas no pode-

mos controlar los procesos, sino controlamos los procesos, no podemos
gestionarlos y si no podemos gestionarlos no podemos mejorarlos.
Los Indicadores de Negocio (KPI: Key Performmance Indicators, en in-

gls) son medidas cuantificables que reflejan las metas de negocio e indican
si cumplimos o no los objetivos planteados para la organizacin. Los indica-
dores estn asociados a los procesos, que a su vez estn asociados a los
objetivos que queremos alcanzar, por lo que sobre los indicadores estable-
ceremos qu queremos medir cualitativa y cuantitativamente (por lo que
deben ser SMART: Specific, Measurable, Achievable, Relevant y Timely) y
304
poder de esta forma analizar estos indicadores, su grado de avance, sus

variaciones y ajustar los procesos en consecuencia.
Los KPIs son esenciales para entender los procesos, su comportamiento,

los riesgos asociados a los mismos y las posibilidades de mejora que tene-
mos sobre ellos. Con los indicadores podemos monitorizar la actividad de
los procesos, los niveles de servicio, diagnosticar el comportamiento de un
proceso y gracias a ellos podemos comunicar los resultados de los procesos
a toda la organizacin, motivarla e involucrarla en la mejora de los indica-
dores y en consecuencia de los procesos y del negocio.
En una reciente encuesta se afirmaba que slo el 14% de los empleados

conocen la estrategia de la organizacin, reducindose esta a informes
mensuales o anuales muchas veces con resultados financieros no entendi-
bles para la gran mayora de ellos. Esta situacin de alejamiento de la reali-
dad y objetivos que persigue la empresa, hace que los trabajadores se con-
centren todava ms en sus tareas especializadas, sin participar en el cum-
plimiento de los objetivos y procesos globales de la empresa. Compartiendo
la informacin en tiempo real de las medidas e indicadores de los procesos,
proporcionaremos material para el control de sus tareas, motivos para tra-
bajar en la mejora de estos y tener una actitud abierta al cambio y a la in-
novacin en base a la retroalimentacin proporcionada por estos indicado-
res.
La visin innovadora es necesaria al analizar las mtricas asociadas a los

procesos y en este anlisis, deben participar todos los agentes internos y
externos de la organizacin implicados en el proyecto para plantear simula-
ciones de procesos, mejoras en la eficiencia de los mismos o plantear que
opciones e indicadores sern los ms adecuados.
Para establecer las medidas e indicadores, diferenciaremos, siguiendo a

Paul Harmon, entre medidas externas e internas.
- Las medidas externas: son los resultados de medidas del resul-

tado de un proceso o cadena de valor y finalmente sern estas
las medidas del xito o fracaso del proceso global. Ejemplos: in-
gresos, satisfaccin del cliente, crecimiento del mercado.
- Las medidas internas: son las que suceden dentro del proceso o
cadena de valor y son las ms fcilmente medibles. Ejemplos:
costes y tiempos de produccin, eficacia de una determinada
funcin o proceso, etc.
305
Estos dos tipos de medidas conforman un ciclo de retroalimentacin

como el siguiente:
La recomendacin para establecer las medidas es la siguiente: fijar pri-

mero las medidas externas y despus ir a mejorar las medidas e indicadores
internos, de forma que nos aseguremos de que los resultados que alcance-
mos en las medidas internas resultarn beneficiosas para la organizacin,
pues lo sern para el mercado y los clientes. Esta, sin embargo, no es la
prctica con la que normalmente actuamos al realzar nuestro trabajo, prefi-
riendo por comodidad centrarnos en los resultados internos sin abordar la
problemtica de los factores externos sobre los cuales creemos tener me-
nor control. En consecuencia, deberemos estar atentos a las seales del
mercado y los clientes, retomando la visin de la empresa orientada al
cliente, por lo que ser preferible a la hora de tomar nuestras medidas,
centrarnos en las medidas de salida del proceso, pues sern estas las que
ms directamente afectarn a la satisfaccin del cliente y no tanto en las
medidas internas del proceso, pues si el cliente no va a estar satisfecho con
el resultado, da igual lo eficientes que seamos en los distintos pasos del
proceso.
A la hora de considerar las medidas de salida del proceso, podemos usar

como referencia la clasificacin en tres categoras de los requerimientos de
los clientes realizada por el Dr. Noriako Kano, un experto en control de cali-
dad,
- Requerimientos bsicos: lo mnimo que esperan los clientes del

producto o servicio.
- Satisfactorios: medidas del servicio que agradan al cliente y de
las que cuantas ms tengamos, ms contento estar este.
- Placenteras: cosas que el cliente no se espera.
306
Respecto a que estrategia seguir para la identificacin de indicadores, al

contrario que en la fase de Levantamiento de procesos, que resaltbamos
la importancia de la perspectiva Bottom-Up, para la identificacin de indi-
cadores, inclinaremos la balanza hacia la perspectiva Top-Down. La pers-
pectiva Bottom-Up para los indicadores, utilizada para el desarrollo de sis-
temas de inteligencia de negocio y reporting, es una perspectiva muy tec-
nolgica, en la que mandan los datos y nos vemos inmersos en montones
de estos datos, de distintos orgenes y sistemas, por lo que tendremos que
movernos hacia la creacin de un modelo de datos que ordene esa maraa
y que muy probablemente no reflejar las necesidades de negocio. La pers-
pectiva Top-Down para la identificacin de medidas e indicadores, pone sin
embargo a los objetivos y requerimientos de negocio por encima de los
datos, realizando una operacin de reingeniera inversa para, en funcin del
modelo de negocio, establecer qu se necesita medir y que datos sern
necesarios recabar, identificando los orgenes de datos existentes para esas
medidas o creando nuevos orgenes de datos para poder disponer de ellos y
de sus combinaciones, lo que con frecuencia resultar en la necesidad de
modificacin de determinados procesos o partes de los mismos. Por su-
puesto que ambas perspectivas, al igual que en la fase de Levantamiento de
procesos, coexistirn durante este anlisis de medidas e indicadores, sin
embargo, en este punto se nos hace ms lgico el predominio de la pers-
pectiva Top-Down, por ser mucho ms flexible a las necesidades de negocio
y los cambios que en este puedan producirse. Recordando una cita de Mar-
tin A. Gould: Nos estamos moviendo de la sociedad de la informacin a la
sociedad de los procesos en la que la informacin (los datos) es slo el acei-
te que mueve la rueda de los procesos.
Los KPIs se monitorizan en las plataformas BPMS a partir de informacin

proveniente de mltiples fuentes, bases de datos y sistemas, presentndo-
se la misma en forma de grficos e informes denominados dashboards o
tableros de mando, orientados a diversas reas de la empresa (finanzas,
recursos humanos, gerencia, etc.) as como otros ms especficos y los rela-
cionados con la operativa de procesos concretos.
Six Sigma y Balance Scorecard.
Tal vez la metodologa ms usada para la medida de procesos es Six Sig-

ma por su especializacin en el anlisis estadstico de procesos. Six Sigma
no nos dice como analizar o disear procesos, sino que suele trabajar sobre
307
los resultados de procesos ya existentes, sin embargo, Six Sigma es tal vez la
mejor metodologa para medir los procesos a travs del anlisis estadstico
de las salidas de los procesos para poder decidir sobre su estado y necesi-
dades de mejora o correccin. Generalmente los proyectos de mejora de
procesos con Six Sigma se realizan sobre subprocesos o sobre actividades,
aplicando el ciclo DMAIC ya descrito con anterioridad al hablar de Six Sigma,
en busca de la mejora de procesos en base al establecimiento de medidas y
la captura y anlisis de las mismas para la mejora del proceso. La aplicacin
de Six Sigma debe ser vista como una meta en la reduccin de la variabili-
dad del proceso, de forma que este se ajuste a los requerimientos del clien-
te y a los resultados deseados para el mismo.
Al tomar medidas nos centraremos en:
- Inputs: medir las entradas para asegurarnos de que no tenemos

problemas con las entradas del proceso.
- Medidas del proceso: como costes, tiempos, valor, trabajo.
- Outputs: medidas de salida del proceso y satisfaccin de los
clientes.
George Eckes, un autor de Six Sigma recomienda 3 reglas a la hora de

realizar las mediciones:
- Medir slo lo que es importante para el cliente.

- Medir slo las salidas de los procesos sobre las que podamos
realizar mejoras.
- No medir una salida para la cual no disponemos de datos hist-
ricos de insatisfaccin del cliente.
Como vemos, existe una clara orientacin al cliente y a la satisfaccin del

mismo (empresas cliente cntricas) en las que las medidas que establezca-
mos para el rendimiento de los procesos adems de permitirnos evaluar la
calidad y eficiencia del proceso deben estar alineadas con esta visin cliente
cntrica como foco central.
Una vez dispongamos de las medidas asociadas a las distintas activida-

des del proceso estaremos en posicin de analizar las mismas para conocer
el grado de valor que cada una de las actividades aporta al proceso, evaluar
el grado de acercamiento a los objetivos planteados y si el proceso est
cumpliendo o no con lo esperado. Este anlisis nos resultar trivial en mu-
chos casos, en los que en la fase de levantamiento de procesos habremos
identificado ya medidas no correctas, por lo que podremos resolver el an-
308
lisis de forma rpida, sin embargo, estos casos no sern los ms frecuentes,
por lo que necesitaremos de unos anlisis ms profundos de las medidas
que obtengamos, as como realizar simulaciones para obtener la causa de
estas y sus posibles soluciones. Estas soluciones requerirn en algunos ca-
sos del rediseo de los procesos y en otros de clculos estadsticos ms
complejos, como anlisis de regresin o diagramas de dispersin, para eva-
luar el valor que cada actividad aporta al proceso, as como analizar los
resultados del mismo en funcin de distintas variables asociadas al proceso.
En muchos de estos casos utilizaremos los diagramas de espina de pez de
Ishikawa o diagramas de causa-efecto para encontrar las causas de los pro-
blemas o desviaciones en el proceso y nos encontraremos tambin con
frecuencia con la regla del 80/20 donde el 20% de las causas generan el
80% de los problemas.
Con los resultados de las medidas de los procesos y establecida tambin

una lnea base de mediciones en las que estas se encuentren en los rangos
correcto para producir los resultados esperados del proceso, volveremos a
la fase de mejora de procesos, para analizar de cada actividad, si aporta
valor al cliente, si aporta valor a otra actividad en el proceso o por el con-
trario no aporta ningn valor y es una perfecta candidata para ser elimina-
da.
Otro aspecto a considerar en las medidas e indicadores que establezca-

mos es tener cuidado con la frecuencia de estas medidas, en especial con
las que involucran medidas de tiempo, pues pueden ser recogidas en tiem-
po real, de forma diaria, mensual, anualmente o en periodos concretos de
tiempo, por lo que la recogida de estos indicadores puede y suele estar
condicionada por su disponibilidad en el tiempo.
Adems de Six Sigma, muchos de los frameworks y estndares vistos en

el captulo anterior como SCOR, en la cadena de valor, Sarbanes-Oxley, para
indicadores financieros, VRM (Value Reference Model), APQC, etc. ofrecen
multitud de medidas e indicadores para los procesos que describen cada
uno de ellos y nos pueden resultar de gran utilidad a la hora de definir las
medidas ms apropiadas para nuestros procesos y la forma de medirlas y
controlarlas en base a estndares y buenas prcticas ya contrastadas.
Uno de estos frameworks, y el ms utilizado para definir y controlar las

medidas es el Balance Scorecard (BSC), introducido por Robert Kaplan y
David Nolan en la dcada de los noventa para ayudar a las organizaciones a
alinear, comunicar y hacer un seguimiento del progreso en la estrategia,
309
metas y objetivos de negocio. Este modelo de Cuadro de Mando no susti-

tuye los mtodos de gestin existentes ni elimina las medidas e indicadores
actuales, sino que los complementa, ordena y les da una mayor coherencia.
El BSC o Cuadro de Mando Integral, en espaol, se estructura en cuatro
pasos de implementacin:
- Convertir la visin corporativa en metas de funcionamiento,

- Comunicar la visin y vincularla con el desempeo individual,
- Planificacin de negocios, y
- Retroalimentacin, aprendizaje y reajuste de la estrategia.
El Cuadro de Mando Integral propone cuatro tipos o perspectivas de

medidas: financieras, medidas internas de negocio, medidas de innovacin
y aprendizaje y medidas de clientes.
- Perspectiva financiera: basados en los indicadores financieros

de la empresa. Debido a que estos indicadores se basan en el
pasado de las empresas, algunos autores dicen que es como
conducir un coche a 100 km/h mirando por el retrovisor. Algu-
nos indicadores de este tipo son: ndice de liquidez, ndice Du-
Pont, rendimiento del capital invertido, flujo de caja, ROI, etc.
- Perspectiva del cliente: cmo ve el cliente a la organizacin y
qu debe hacer la empresa para retenerlo como cliente, inde-
pendientemente de cmo vayan los resultados financieros. Se
miden las relaciones con clientes y las expectativas que estos
tiene sobre la empresa.
- Perspectiva del proceso interno: analiza los procesos internos
usados para satisfacer a clientes y poder lograr los niveles de
rendimiento financiero, para ello se analizan en que procesos
debemos mejorar para satisfacer a clientes y accionistas. Se cla-
sifican en: Procesos de operaciones, de gestin de clientes, de
innovacin y de medioambiente y de comunidad. Ejemplos de
indicadores en esta perspectiva son: nmero de actividades, ta-
sa de oportunidad de xito, efectividad del equipamiento, etc.
- Perspectiva de innovacin y aprendizaje: basada en intangibles,
analiza cmo puede la organizacin seguir mejorando para
crear valor en el futuro, son los indicadores que dotan a la or-
ganizacin de la capacidad de mejorar y aprender. En esta
perspectiva se critica la visin de la contabilidad tradicional, que
considera la formacin como un gasto y no como una inversin.
Indicadores de este tipo son: satisfaccin de empleados, pro-
310
ductividad, necesidades de formacin, bases de datos estratgi-

cas, patentes y copyrights, iniciativa de las personas, capacidad
de trabajar en equipo, tasas de enfermedad de empleados, por-
centajes de promocin interna, rotacin de empleados, relacin
de gnero, etc.
Cada organizacin adecuar estas perspectivas de acuerdo a sus propias

estrategias, donde lo esencial no es analizarlo todo, sino la forma en que
vinculamos las distintas perspectivas de forma que tengamos un equilibrio
entre las mismas (pues las acciones sobre una variable tendrn consecuen-
cias sobre otras variables e indicadores) y en este sentido, tener unos mag-
nficos resultados en una de las perspectivas y no en otras, afectar de for-
ma negativa a los resultados globales.
El Cuadro de Mando Integral requiere por parte de la empresa para su

implementacin de una cultura participativa, transparencia en la comunica-
cin de la informacin y motivacin de los empleados.
Aunque cada empresa debe disear su propio conjunto de indicadores y

medidas, existen una serie de indicadores utilizados en la mayor parte de
los Cuadros de Mando que nos pueden servir de gua:
- Indicadores Financieros:
o ROI (Retorno de la Inversin)
o Valor Aadido econmico
o Cash Flow
- Indicadores de Clientes:
o Satisfaccin Global
o Retencin de clientes
o Penetracin de mercado
311
o Cuota de mercado
- Indicadores de Procesos Internos:
o Tiempos de respuesta
o Calidad
o Coste
- Indicadores de Innovacin y Aprendizaje:
o Innovacin
o Introduccin de nuevos productos
o Satisfaccin de empleados
o Capacidad de los empleados
o Sistemas de Informacin
BPM, a modo de Cuadro de Mando Integral, concede muchsima impor-

tancia al control y monitorizacin de la actividad empresarial, y en este
aspecto radica una de sus principales fortalezas, al permitir crear modelos
de procesos que pueden ser testeados y evaluados antes de su implemen-
tacin, monitorizar lo procesos mientras estos se ejecutan, establecer indi-
cadores y medir y analizar el rendimiento de nuestros procesos, integrando
las soluciones de cuadro de mando e inteligencia de negocio en la misma
suite donde modelamos y ejecutamos nuestros procesos. Pero dejaremos
para el ltimo captulo dedicado a los BPMS los detalles de cmo lo realiza y
trataremos en el siguiente apartado una tcnica ms para el anlisis de los
procesos como es la simulacin de los mismos y que unida a la capacidad de
establecer indicadores y medidas para los procesos, convierten a BPM y a
los BPMS en herramientas extremadamente poderosas para el anlisis y
control de la actividad empresarial.
BPM concede muchsima importancia a los indicadores y medidas del

proceso, hasta el punto que recomienda no comenzar ningn proyecto si no
podemos establecer medidas e indicadores para luego comprobar las mejo-
ras sobre los mismos. Esta perspectiva debemos sin embargo tratarla con
cautela, pues existen situaciones como puedan ser la reingeniera, trans-
formacin o cambio radical, en las que podemos partir de cero. As mismo,
trabajando incluso en mejora de procesos, no debemos perder el objetivo
final de BPM y caer en el error de convertir nuestros procesos en meras
herramientas para la recogida de datos o que las medidas no nos sirvan
para re-planificar y poder tomar decisiones sobre la estrategia y rumbo a
seguir por nuestra empresa.
312
Simulacin de procesos.
En esta fase validaremos el funcionamiento del proceso para comprobar
que este funciona y cumple con los objetivos para los que fue diseado. El
objetivo en esta fase es identificar cuellos de botella y prevenir bugs y
errores antes de su puesta en marcha, simulando la operativa del proceso y
escenarios de funcionamiento en los que incluiremos a las personas y roles
que participarn en el mismo, los datos (que en estos momentos pueden
ser reales o ficticios, si an no disponemos de los mimos), comprobar el
correcto funcionamiento de las integraciones y aplicativos externos que
necesitar el proceso para realizar su cometido, realizar pruebas de carga,
comprobar las herramientas de medicin y control y asegurarnos de que los
indicadores del proceso se ajustan a la lnea base establecida para los mis-
mos.
Cuanto ms complejos y grandes sean los procesos, ms recurriremos a

la simulacin para analizar sus resultados. En un proceso simple podremos
calcular sin mayores dificultades el tiempo total del proceso sumando las
pocas actividades con las que cuente, sin embargo en procesos ms com-
plejos, este resultado no ser tan obvio y depender de mltiples combina-
ciones, posibles retrasos e incertidumbres asociadas al proceso, por lo que
el ejecutar varias simulaciones del proceso nos permitir calcular una media
ponderada de tiempos del proceso.
Podemos hacer una comparacin del proceso de simulacin y del com-

portamiento del diseo de un proceso con el mundo de la biologa a la hora
de predecir el comportamiento de un proceso. Esta comparacin con la
biologa hace referencia a la diferencia entre genotipo y fenotipo. El
genotipo se refiere a la dotacin gentica de un individuo, a toda la in-
formacin gentica que posee un organismo, y el fenotipo es la expresin
en el individuo de ese genotipo, junto con las variaciones ambientales que
pueden influir sobre el mismo y que puede manifestarse, o no. De esta for-
ma, genotipo y fenotipo no estn siempre relacionados el uno con el otro,
algunos genotipos slo se expresan bajo determinadas condiciones y algu-
nos fenotipos pueden ser el resultado de varios genotipos. En BPM pode-
mos de alguna manera considerar al modelo en BPMN y su cdigo BPEL
como el genotipo del proceso, el cual una vez ejecutado y puesto en fun-
cionamiento, puede para un observador externo, reflejar el comportamien-
to exacto del genotipo o modelado realizado, o puede que no, y que este
no se ajuste al comportamiento esperado o diseado debido al entrono en
el que se desarrolla el proyecto, y por ello, la simulacin deber no slo
313
ajustarse al diseo del proceso (lo cual nos lo asegura la herramienta de

BPMS que utilicemos) sino que deber emular en la medida de los posible,
el entorno y ambiente en el cual se desarrollar el proceso, para que poda-
mos evaluar el mismo bajo las condiciones ms reales posibles.
La base sobre la que se apoyan los simuladores empleados en BPM es

ejecutar los procesos miles de veces, desde el evento inicial hasta el final
del proceso, recorriendo todos los posibles caminos del proceso, activida-
des y decisiones que puedan ser tomadas en los mismos y teniendo en
cuenta los recursos y personas necesarios en cada paso. En el transcurso de
la simulacin, los datos del proceso son recogidos y analizados con herra-
mientas estadsticas siendo los resultados de esta simulacin del tipo:
- Nmero de veces que cada actividad es ejecutada en un

proceso.
- Duraciones medias de las actividades.
- Costes calculados para cada actividad.
- El nmero de horas que un recurso ha trabajado en cada
actividad.
- Los tiempos de espera en las distintas actividades.
- La utilizacin de recursos.
- El trabajo realizado por cada recurso.
- El coste de los recursos utilizados.
- La distribucin de la carga de trabajo en las distintas activi-
dades.
- Los tiempos totales de ejecucin del proceso.
- Los costes totales del proceso.
La evolucin en la tecnologa y algoritmos utilizados por los simuladores

est en constante desarrollo y una de las reas que ms ha hecho evolucio-
nar estas tecnologas de simulacin es la de los videojuegos. Estos desarro-
llos comenzaron con el conocido juego de SimCity, un juego en el que de-
bemos crear y gestionar una ciudad de forma que esta sea capaz de prospe-
rar. Como toda simulacin, esta parte de un modelo, la ciudad con la que
comenzamos el juego, donde vemos como esta evoluciona a medida que
avanza el tiempo. De lo bien que gestionemos nuestra ciudad: construya-
mos carreteras, hospitales, escuelas, industrias, recogida de basuras, agua,
energa, etc. y gestionemos las entradas y salidas de dinero que tengamos,
depender el xito o fracaso de nuestra ciudad en el juego.
314
SimCity es un juego desarrollado por MAXIS y distribuido por EA Games,

que hace uso de la simulacin de las relaciones causa-efecto de un sistema
urbano y que es utilizado por numerosas universidades y urbanistas para
simular el comportamiento de las ciudades. Este juego y sus derivados
(existen mltiples versiones del juego aplicados a distintos entornos inclui-
dos los sociales: los Sims), hacen uso de las propiedades emergentes de los
sistemas, es decir, aquellos sistemas cuyo comportamiento es regido desde
los niveles ms bajos hacia los ms altos, desde la simplicidad a la sofistica-
cin. Algunos ejemplos de sistemas emergentes son: las colonias de hormi-
gas, las ciudades o el cerebro humano, en los que a partir de componentes
simples del sistema, sus interacciones, y siguiendo unas simples reglas, sur-
gen comportamientos complejos y difciles de explicar debidos a un com-
portamiento ascendente que provoca la inteligencia colectiva. En el caso de
SimCity, la ciudad y muchas de sus unidades, se auto-organizan. Aunque
nosotros como jugadores diseemos y construyamos ciudades, estas evolu-
cionan de manera impredecible a partir de algoritmos simples (ver el esta-
do del vecino y actuar en consecuencia) y dejando al ordenador hacer los
miles de clculos.
En SimCity se expresa perfectamente la complejidad auto-organizada,

como un modo de expresar la evolucin y desarrollo de las ciudades y sis-
temas urbanos, donde estas no son el resultado de un proceso planificado y
simplemente se desarrollan reconociendo patrones, aprendiendo y remo-
delndose una y otra vez como todo sistema complejo.
Las herramientas de simulacin del comportamiento de los procesos y

las organizaciones operan de forma parecida a SimCity, analizando por
ejemplo como cambiando determinadas reglas de negocio se producen
cambios en el comportamiento de los procesos. Es de esperar que las
herramientas de simulacin harn uso y alcanzarn rpidamente los niveles
utilizados en estos juegos para analizar nuestros modelos de procesos e
incluso de negocio y del Business Motivation Model, que tambin podr ser
simulado para comprobar los resultados de las estrategias definidas y que
dada la importancia que este tipo de simulaciones tiene para la empresa,
muchos fabricantes de software estn desarrollando herramientas de simu-
lacin para este tipo de modelos.
Aunque de lo descrito sobre las herramientas de simulacin podamos in-

ferir el dejar esta tarea para ser realizada enteramente por las herramientas
informticas sin apenas intervencin humana, esta intervencin humana
ser necesaria y fundamental para la toma de buenas decisiones relativas a
315
nuestros procesos y sus posibilidades de mejora. Si bien debemos recono-

cer que los humanos no somos perfectos a la hora de tomar las mejores
decisiones, estas frecuentemente se encuentran sesgadas y nos dejamos
llevar por errores de apreciacin y evaluacin. El clculo probabilstico, por
ejemplo, nos proporciona mucha informacin como los posibles resultados
o sus frecuencias, pero al mismo tiempo, esta visin, nos esconde la com-
prensin de otras partes del problema que estudiamos y a veces, es prefe-
rible disponer de menos informacin, pero que esta sea ms valiosa, como
pueda ser la del resultado ms probable. Nuestras diferencias de pensa-
miento respecto a las mquinas siguen siendo muy significativas, y muchos
planteamientos empresariales no podrn ser simulados completamente por
los sistemas informticos, pues incluso en la resolucin de algunos proble-
mas lgico-matemticos, los ordenadores no cuentan con la capacidad de
salirse del sistema y abordar nuevas perspectivas y visiones del problema
necesarias para la resolucin de muchos de estos algoritmos.
Esperar lo inesperado.
Los procesos empresariales medianamente complejos son impredecibles

debido a las expectativas que puedan tener los clientes, los cambios polti-
cos y de mercado o innovaciones tecnolgicas que nos llevarn a considerar
no slo los aspectos controlables y analticos de los procesos, sino tambin
su impredecibilidad. La mayora de los modelos son representaciones est-
ticas de una situacin, y muchas veces es difcil comprender todas las situa-
ciones e interacciones que pueden afectar a un modelo y sus consecuencias
por muchas tcnicas, herramientas y conocimientos que usemos para su
prediccin. De hecho, muchos de los grandes negocios y mejoras de proce-
sos han surgido por casualidad, o fruto del azar en la combinacin de distin-
tas posibilidades y configuraciones de modelos de negocio y diseo de pro-
cesos. Es por ello que no desperdiciaremos las posibilidades que la simula-
cin nos ofrece para conocer las distintas implicaciones, tanto internas co-
mo con otros sistemas, combinando estas con la capacidad de implementar
y simular nuestros propios modelos de negocio que nos proporcionan las
plataformas de BPM.
Durante la simulacin de nuestros procesos, entramos en terrenos alta-

mente innovadores y creativos, que requerirn del equipo de proyecto el
poner a prueba estas capacidades en la bsqueda de soluciones innovado-
ras para analizar y mejorar los procesos simulados. La enorme potencia de
316
las herramientas computerizadas de simulacin, nos permitirn ejecutar los

procesos miles de veces, para analizar los resultados y poder modificar las
variables del proceso para probar otras soluciones y configuraciones posi-
bles, lo cual nos ayudar mucho en este proceso, permitindonos chata-
rrear con las distintas posibilidades y configuraciones.
Nassim Nicholas Taleb deca en su libro Los cisnes negros que estaba
en desacuerdo tanto con los seguidores de Marx como con los de Adam
Smith, pues segn l, la razn por la que funcionaba el libre mercado es
porque permita a la gente ser afortunada gracias a la posibilidad de que
cualquiera pudiese hacer pruebas de ensayo y error, y que en este proceso
no era necesario que el estado diese incentivos o premios. La estrategia en
consecuencia es chatarrear todo lo que podamos sobre nuestros proce-
sos y modelos de negocio en busca de los cisnes negros de los que habla
Taleb, esos hechos fortuitos (como los cisnes negros), imposibles de calcu-
lar, antes de ser percibidos, en base a la informacin disponible mediante
mtodos estadsticos y probabilsticos y que sus efectos suelen ser sorpren-
dentes y de impacto desproporcionadamente grande. En este libro, alta-
mente recomendable, Taleb nos descubre los errores que cometemos en
los procesos de razonamiento cuando los humanos nos enfrentamos a la
complejidad, la incertidumbre y la aleatoriedad y nos advierte de los erro-
res en los que podemos incurrir al analizar los procesos y en cmo no sole-
mos percatarnos de las situaciones inesperadas que escapan a nuestro an-
lisis, en las soluciones innovadoras, capaces de producir esos resultados
sorprendentes y de ah la metfora del cisne negro: acostumbrados a vivir
en el hemisferio norte del planeta, pensamos que todos los cisnes son blan-
cos, sin embargo en Australia existen cisnes negros. Sobre estos errores que
cometemos, Taleb nos describe como a mayor frecuencia de ocurrencia de
un hecho, menor sensibilidad tendremos frente a lo inesperado y como
inconscientemente buscamos siempre lo que esperamos obtener, como el
borracho que habiendo perdido una moneda en un callejn oscuro, la bus-
caba debajo de una farola porque all haba ms luz. Medimos lo que espe-
ramos medir en nuestros procesos y por esta tendencia, estableceremos las
medidas e indicadores de lo que queremos medir, seleccionando nicamen-
te los hechos que encajan en nuestras teoras, pues as es como funcionan
nuestros cerebros, que necesitan tener todo perfectamente ordenado y
comprensible. Esta situacin es la vista cuando hemos analizado el estable-
cimiento de medidas e indicadores de nuestros procesos, donde la tenden-
cia tradicional era medir exclusivamente indicadores financieros, basados
en resultados pasados de la empresa y muy vulnerables a los cambios del
mercado. Si medimos nicamente resultados financieros, obtendremos
317
resultados financieros, por lo que ya en el Balanced Scorecard, hemos am-

pliado esta perspectiva financiera a otras perspectivas para alcanzar objeti-
vos ms all de los meramente financieros y que redunden en una mayor
sostenibilidad y posibilidades de supervivencia de la empresa.
En el proceso de anlisis y mejora de nuestros procesos, debemos apro-

vechar las herramientas de simulacin y todo su potencial, por el ahorro de
tiempo que producen a la hora de testear nuestros prototipos y no dejarnos
llevar por las conclusiones obvias y superficiales apoyadas en una mnima
cantidad de datos. Aunque la simplificacin es buena, para ordenar lo com-
plejo, debemos explorar tambin nuevos caminos no estructurados y com-
prensibles, pues la realidad, las empresas y los entornos en los que se des-
arrollan, son muchas veces desordenados, complejos e impredecibles. Al
hablar de mejora de procesos hemos enumerado varias prcticas, entre
ellas, la de la simplicidad, como va para reducir la complejidad. Esta prcti-
ca sigue por supuesto siendo correcta a la hora de disear y mejorar nues-
tros procesos, sin embargo, debemos tener en cuenta a la hora de analizar,
simular y buscar soluciones a problemas en nuestra organizacin, que esta
simplicidad no significa que la explicacin ms sencilla sea siempre la mejor,
por la misma razn que decirle a un nio que los bebs vienen de Pars para
explicarles porque nacen los bebs, aunque sea mucho ms sencillo de ex-
plicar que el proceso de reproduccin biolgica, no implica que esta hipte-
sis sea la correcta. En otros casos, creeremos que por disponer de un mayor
volumen de datos y medidas, dispondremos de una mayor comprensin
sobre el problema a analizar, cuando muchas veces, un mayor volumen de
datos slo implicar un mayor ruido que perturbar la eleccin de la me-
jor opcin o solucin.
A pesar de lo metodolgicos y estructurados que seamos en la gestin

de nuestros procesos, las grandes mejoras e innovaciones en nuestros pro-
cesos no siempre vendrn de una correcta planificacin, estrategia o mejor
gestin de la innovacin. Por mucho anlisis que hagamos, no existe la pre-
dicibilidad exacta en los procesos empresariales medianamente complejos,
pues aspectos como las expectativas de nuestros clientes, cambios polticos
y econmicos, innovaciones tecnolgicas o movimientos de nuestra compe-
tencia, no podrn ser siempre predichos, controlados y trasladados a nues-
tros modelos y reglas de procesos, y muchas de las soluciones y caminos
sorprendentes, sern descubiertas por casualidad (serendipia), que como a
los artistas, slo nos aparecern trabajando, chatarreando con nuestros
modelos estratgicos, con nuestros procesos y simulando escenarios en
busca siempre de la excelencia y la mejora continua y como hemos adverti-
318
do al hablar de levantamiento de procesos, escuchando a las personas y

considerando la perspectiva Bottom-Up. A la vista de la realidad econmica
y empresarial y la creciente complejidad del mundo en el que las empresas
se desarrollan, la correcta gestin y organizacin de los sistemas empresa-
riales y tecnolgicos debe ser tenida en cuenta, pero no convertida en pato-
lgica, de forma que dejemos siempre un camino abierto a lo inesperado,
ms que para predecirlo, para estar preparados por si acontece. Esta idea
que acabamos de exponer, est relacionada con el concepto cientfico y
filosfico del determinismo, segn el cual, absolutamente todos los fen-
menos de la naturaleza, incluido el comportamiento humano, pueden ser
predichos con exactitud por las leyes de Newton, es decir, que conociendo
las condiciones inciales de estos fenmenos, sean estos: eclipses solares,
que me van a regalar en mi prximo cumpleaos, cuando se me caer el
pelo o si mi nuevo negocio va a tener o no xito en el mercado. Como pre-
suponemos, las leyes de Newton son de aplicacin en algunos sistemas y
entornos, pero no en todos y una visin determinista de las personas o de
los procesos empresariales es algo que sabemos no podemos asumir como
cierto.
Como vemos, a pesar de lo bien que realicemos la mejora de procesos y

lo constantes que seamos en la mejora continua, siempre existirn factores
sobre los cuales nuestros procesos no podrn predecir su comportamiento
a partir de las variables y reglas de negocio descritas en el mismo: la com-
petencia, entorno poltico y econmico, nuevas innovaciones tecnolgicas,
etc. por lo que siempre tendremos la impredecibilidad como una espada de
Damocles sobre nuestra empresa y requeriremos no slo de mejora conti-
nua de procesos sino de la agilidad y flexibilidad para adaptarnos a los cam-
bios surgidos en el entorno. Ni BPM, aunando todas las metodologas y
disciplinas de management y tecnolgicas, ser capaz de gestionar esta
impredecibilidad, por lo que deberemos pasar ms tiempo realizando
benchmarking, analizando, evaluando, proyectando y observando nuestros
procesos, que gestionando el da a da de los mismos y utilizar la disciplina
de BPM y los BPMS, no slo como herramientas de gestin y reporte, sino
como herramientas de anlisis y de ayuda a la toma de decisiones por parte
de las personas, que son las que finalmente dirigirn los procesos. Las me-
jores innovaciones y mejoras sobre nuestros procesos vendrn de las per-
sonas, de su creatividad y capacidad dentro de la organizacin para com-
partir, experimentar y generar ideas, tanto desde los niveles ms altos co-
mo desde los intermedios y los ms bajos de la estructura de la organiza-
cin.
319
Gestin del cambio e innovacin.
En todas las organizaciones existen cosas que no funcionan, cosas que

todo el mundo conoce su ineficiencia o los problemas que causa al resto de
la organizacin, pero a las cuales no se les hace frente. La causa de este
dejar correr las cosas se encuentra principalmente en que muchas veces
desconocemos el impacto real de ese mal funcionamiento y las implicacio-
nes que tiene, no lo medimos ni analizamos (no vaya a ser peor de lo que
esperamos), por lo que continuamos trabajando con l. Otras veces es el
miedo (que surge de preguntarnos constantemente: qu pasara si?), o
la vergenza a ser nosotros quien identifiquemos un problema (no voy a
ser yo quien lo diga), la no predisposicin a solucionar el problema (que
igual me toca a mi arreglarlomejor me ocupo slo de lo mo), las tareas
del da a da o la burocracia que nos restan el tiempo y recursos necesarios
para encarar, analizar y buscar soluciones a nuestros problemas.
Las personas, sin duda alguna, pero tambin las culturas organizaciona-
les asociadas a empresas jerarquizadas, que ya hemos analizado en la orga-
nizacin orientada a procesos, ms ocupadas de la burocracia y las polticas
internas que en afrontar nuevos retos y cambios de paradigmas, tienen
mucha culpa de estos miedos, no ya al cambio, sino a reconocer y buscar
soluciones a los problemas, en especial cuando estos se salen de mi depar-
tamento y afectan a toda la organizacin (como es el caso de los proce-
sos), creando de forma inconsciente, organizaciones estticas que evitan
constantemente ser modificadas.
La realidad es que la solucin a este problema en las organizaciones es

mucho ms sencilla que tener que pasar por el miedo, el escaqueo o la ver-
genza, pues el problema raz de estas situaciones suele estar en los proce-
sos mal diseados y no en las personas que los ejecutan, por lo que si
transmitimos una cultura y compromiso con la mejora de los procesos, des-
cargamos la culpa en el diseo de estos y no en las personas, que pasarn a
ser partcipes de la mejora de procesos. Blame the process, not the peo-
ple, que traducido es culpa al proceso, no a la persona, es una frase que
omos con bastante frecuencia al hablar de procesos, pero que aunque no
tenga su falta de razn, pues aunque resulta obvio que en un buen diseo
de procesos y de la correcta definicin de las actividades y tareas que debe-
rn realizar las personas (trabajadores, directores de reas, lderes de pro-
yectos y responsables empresariales), se fundamentar la correcta imple-
320
mentacin de los procesos de negocio de la empresa, no podemos negar

que en el lado humano, en la complejidad intrnseca de las personas, en
especial cuando deben interactuar entre ellas, en las diferentes personali-
dades, escalas de valores y egos personales, se encuentran tambin muchos
de los problemas de nuestras organizaciones.
Ya hemos visto como debido a los cambios en el entorno de negocio y

por consecuencia de que las organizaciones desarrollan sus actividades en
un entorno cambiante e inestable, los procesos deben someterse a conti-
nuos cambios que deberemos asumir. Hacer cosas cambia las cosas; no
hacer nada deja las cosas como estn, y la principal resistencia para la im-
plementacin de estos cambios la encontraremos sin duda alguna en las
personas.
La resistencia de las personas al cambio es uno de los factores que ms

comnmente ponen en riesgo la implementacin de cualquier proyecto y
los de BPM en particular, por su capacidad de alterar las estructuras de la
empresa. Esta resistencia se presenta tanto en los cuadros directivos como
en los operacionales, pues los proyectos BPM afectan a todas las personas
de la organizacin.
Salir de las posiciones de comodidad en las que estamos, es algo que nos
cuesta a todas las personas, e inconscientemente, opondremos resistencia
a estos cambios, an cuando la implementacin de estos cambios produz-
can un estado ms beneficioso que el anterior. Para el xito del proyecto,
ya hemos visto como las personas no slo se vern afectadas por el cambio
que se produzca en los procesos en los que estn involucradas, sino que
adems debern participar activamente en la mejora de estos y aportar a lo
largo del ciclo de vida del proyecto, sus conocimientos e involucracin con
el mismo, y este ltimo punto es fundamental para poder especificar tanto
los procesos actuales como las mejoras sobre los mismos.
Hablar de BPM y de gestin por procesos es mucho ms que hablar ni-

camente de procesos, de entradas, transformaciones y salidas. Hablar de
BPM significa orientacin a cliente, de eficiencia operativa, flexibilidad y
adaptabilidad a los requerimientos y necesidades del mercado y en conse-
cuencia de cambio organizacional, por lo que deberemos romper con la
cultura establecida y la inercia de ocuparnos de nuestras tareas repetitivas
del da a da y abordar un pensamiento ms abierto al cambio.
BPM permite una respuesta mucho ms rpida al cambio, proporcio-

nando la agilidad necesaria para la mejora y adaptacin continua. En este
321
sentido, los sistemas BPM (BPMS) nos proporcionan un entorno sin igual en
el que visualmente modificamos los procesos, evaluamos su operativa en
un entorno de pruebas y los ponemos en produccin una vez validados.
BPM trata sobre el cambio, sobre los modelos actuales de negocio y

procesos con los que opera la empresa pero fundamentalmente, de cmo
mejorar la eficacia y eficiencia de estos procesos, de su mejora continua y
de su transformacin para adaptarse al cambio. El asegurarnos de que las
personas comprendan los cambios, las implicaciones que estos tienen para
su trabajo y que estas acepten los cambios ser el taln de Aquiles de los
proyectos en que nos embarquemos.
Muchos proyectos fracasan por la resistencia de las organizaciones al

cambio, por eso es importante conocer la gestin del cambio y de las per-
sonas para asegurar el xito del proyecto y es uno de los motivos de porqu
han fracasado muchos proyectos de BPR y por el cual muchas veces se es-
cogen proyectos de pequeo alcance al inicio de los proyectos formados
por procesos pequeos. Para gestionar el cambio, deberemos alinear el
proyecto con los objetivos y estrategia de la empresa de forma que poda-
mos dirigir el proyecto hacia un claro destino entendido por toda la organi-
zacin. Deberemos asegurarnos el compromiso de la alta direccin con el
proyecto y la involucrando a todo el equipo y stakeholders internos y exter-
nos y preparar la organizacin para el cambio, elaborando los planes de
formacin necesarios para todo el personal involucrado en el proyecto y
realizar reuniones de trabajo para explicar qu, cundo, cmo y por qu
vamos a llevar el proyecto adelante. As mismo ser importante identificar a
los lderes o personas con amplios conocimientos de la organizacin y sus
procesos y que dispongan de la suficiente influencia en la organizacin,
para que nos acompaen en la transmisin de la importancia del proyecto y
acten como lderes del cambio. Estos lderes dentro del proyecto debern
ser formados en gestin de procesos, en BPM, en metodologas, diseo y
modelado de procesos y en el uso de las herramientas BPMS.
La innovacin junto a la gestin de proyectos y la gestin del cambio la

tendremos en cuenta en todo el proyecto, pero ser en esta fase de simula-
cin de los procesos, previa a su implementacin, cuando esta actitud deba
tener mayor preponderancia, pues es en esta fase en la que realizaremos
todo tipo de anlisis tcnicos, econmicos y de negocio para determinar las
mejores opciones de implementacin y las implicaciones de los cambios. As
mismo, puede que en esta fase realicemos ajustes en los procesos, aada-
mos o modifiquemos mtricas e indicadores y en la que dispongamos de
322
una visin ms real de los que ser el proceso una vez implementado, por lo
que aprovecharemos esta fase para aplicar todas las capacidades de inno-
vacin y creatividad, haciendo uso de las herramientas de simulacin para
evaluar las mejores optimizaciones y mejoras sobre nuestros procesos.
Para la gestin del cambio y la innovacin, las teoras ms conocidas y

utilizadas son el Modelo de Kotter, para la gestin del cambio y la metodo-
loga TRIZ para la gestin de la innovacin.
Modelo de Kotter:
John Kotter, profesor de Harvard, presenta en su libro Liderando el

cambio, publicado en 1995, una metodologa en ocho pasos hacia el cam-
bio.
Paso 1: Crear sentido de urgencia:
Desarrollar un sentido de urgencia alrededor de la necesidad de cambio,

despertando la motivacin inicial para lograr el movimiento.
Paso 2: Formar una poderosa coalicin:
Bajo el liderazgo del jefe de proyecto, formar una coalicin o equipo

identificando a las personas lderes de diferentes perfiles y niveles dentro
de la organizacin, con la suficiente influencia dentro de la organizacin y
compromiso para trabajar conjuntamente en la continua construccin de la
urgencia e impulsar el cambio. Este equipo debe estar formado por diferen-
tes perfiles y niveles dentro de la empresa.
323
Paso 3: Crear una visin para el cambio:
Crear una visin que la gente pueda entender y recordar fcilmente re-
cogiendo las ideas y soluciones dispersas. Esta visin ayudar a que todos
entiendan la necesidad del cambio, determinando los valores que funda-
mentan el cambio, visualice el futuro de la organizacin y se acompae de
una estrategia para ejecutar la visin.
Paso 4: Comunicar la visin:
La visin no bastar con crearla, habr que comunicarla con fuerza y la

frecuencia suficiente para transmitirla a toda la organizacin as como
transmitirla a travs del ejemplo en nuestras actuaciones, aplicndola a
todos los mbitos en los que trabajemos.
Paso 5: Eliminar los obstculos:
Comprobar constantemente la barreras que puedan dificultar el cambio:

estructura organizacional, personas, departamentos, sistema de recompen-
sas, etc. que puedan afectar al mismo y adoptar medidas para eliminar es-
tas barreras, analizar el por qu de su resistencia y ayudarles a compartir la
visin.
Paso 6: Asegurarse triunfos a corto plazo:
Procurar pequeas victorias en las fases ms tempranas del proceso de

cambio buscando proyectos de xito asegurado y que aseguren la continui-
dad de la inversin, para motivar al equipo y a la organizacin en el cambio
y convencer a los que se oponen a este.
Paso 7: Construir sobre el cambio:
Kotter sostiene que muchos proyectos de cambio fallan porque se decla-

ra la victoria muy tempranamente, cuando las victorias son slo el comien-
zo de lo que se necesita para lograr lo cambios a largo plazo, por lo que
deberemos construir progresivamente sobre lo que sali bien y mejorarlo.
Paso 8: Anclar el cambio en la cultura de la empresa.
Asegurarnos la continuidad en los planteamientos de cambio apoyndo-

nos en los xitos anteriores y convenciendo del modelo exitoso alcanzado.
324
TRIZ (Teoriya Reshniya Izobretate Zadatch):
Ms relacionada con la innovacin y como una de las principales meto-

dologas para la gestin de esta, tenemos TRIZ surgida a partir de Six Sigma.
TRIZ es el acrnimo en ruso de Teora Inventiva de Resolucin de Proble-
mas, una metodologa para analizar los problemas y buscar soluciones in-
novadoras a los mismos que ha sido asumida por muchos consultores de Six
Sigma. TRIZ dispone de ocho marcos evolutivos para la gua de decisiones
estratgicas, 76 soluciones estndar para elementos de ingeniera en un
sistema, 39 parmetros para caracterizar problemas y 40 principios innova-
dores para solucionar contradicciones. En TRIZ hay dos metodologas, una
para problemas tcticos y otra para problemas estratgicos. Aunque es una
metodologa bastante compleja y no fcilmente aplicable para la gestin de
la innovacin en pequeas y medianas empresas, es una de las teoras ms
elaboradas y contrastadas para la gestin de la innovacin.
Implementar el proceso:
En esta fase procederemos a implementar el proceso mejorado, el To-Be

que hayamos alcanzado, que pasar a convertirse en el nuevo As-Is. Para
ello adquiriremos los recursos humanos y materiales necesarios, formare-
mos a los trabajadores y personal involucrado en el proyecto y selecciona-
remos las herramientas tecnolgicas que vamos a utilizar para implemen-
tar, gestionar y monitorizar los procesos.
Como hemos visto, el interfaz a travs del cual interactuaremos con el

proceso ser generalmente un frontal web, desplegado desde el BPMS en
forma de portal y a travs del cual los usuarios y roles asignados al proceso
podrn realizar su trabajo. Las interacciones a travs de este portal se real-
zarn principalmente en forma de lista de tareas pendientes por realizar
de los distintos usuarios. Esta lista dispone con sus correspondientes crite-
rios de priorizacin y capacidades para gestionar la lista de tareas: consultar
las tareas tanto realizadas como pendientes, gestin de alertas, estado de
cada una de las actividades y del proceso en su conjunto o el traspaso de
tareas entre distintos participantes atendiendo a reglas de negocio previa-
mente definidas.
La seguridad para el acceso a la intranet, extranet o portal web para la

gestin de los procesos por parte de los distintos usuarios se gestionar
325
normalmente desde fuera del BPMS a travs de un directorio LDAP aunque

desde dentro del BPMS tendremos la posibilidad de definir derechos y per-
misos de acceso a usuarios o grupos de estos.
Debemos recordar aqu que la implementacin no ser nicamente una

implementacin de TI o de un BPMS concreto, pues como hemos visto, un
proyecto de BPM no es slo tecnologa. Aunque es en esta fase de imple-
mentacin en la que el personal de TI estar ms involucrado y asumir
gran parte del peso de la implementacin que recaer en la plataforma
BPMS y sin la cual no podremos implementar el proyecto, lo fundamental
en toda implementacin de BPM ser entender la visin de la organizacin
orientada a procesos, interiorizarla y adaptarla a nuestra organizacin,
comprendiendo el cambio de paradigma y cultural que supone, pues este
conocimiento y experiencia supondr el 75% de las posibilidades de xito
del proyecto.
La gestin ideal por procesos o el escenario ideal en el que implementar

BPM y alcanzar resultados espectaculares, es aquel en el que los responsa-
bles de negocio y tecnolgicos de la organizacin se embarcan conjunta-
mente en la transformacin de los procesos de negocio de la empresa,
abandonando las acciones aisladas en proyectos de BPM y de mejora de los
procesos, a un proyecto de transformacin global de los procesos de nego-
cio y la empresa, dirigido y soportado por los directivos y donde estos dis-
ponen de una visin y pensamiento orientado a procesos que trasladan a lo
largo y ancho de la organizacin.
Dependiendo de cmo hayamos rediseado los procesos, dispondremos

de un modelo del proceso mejorado que queremos implementar, modela-
do en BPMN sobre una herramienta de modelado de un BPMS, en cuyo
caso la implementacin ser prcticamente inmediata. En otros casos dis-
pondremos de informacin documentada sobre el proceso a implementar,
en cuyo caso tendremos que trasladar esta especificacin a la herramienta
de modelado del BPMS.
El personal que participe en el proyecto, deber ser formado y capacita-

do tanto sobre la herramienta BPMS como sobre el proceso y su operativa,
por lo que desarrollaremos los manuales especficos para cada puesto y
proveeremos de la formacin necesaria a todo el personal involucrado, as
como de la motivacin y compromiso de estos con el proyecto, que a pesar
de haber contado con este compromiso en las fases anteriores, deberemos
mantener tambin ahora en la implementacin.
326
Realizaremos tambin los test del proceso sobre la plataforma BPMS, as

como las pruebas de carga, realizando las modificaciones y depuraciones
necesarias para comprobar que todo funciona perfectamente antes de pa-
sar a la puesta en marcha. Para ello, ser una buena prctica el realizar un
prototipado lo ms real posible, para en un entorno de pruebas, validar el
proceso operando correctamente y prestando especial atencin a las inte-
graciones y procesos automatizados que requieran de orgenes de datos
externos.
Puesto que la implementacin del proyecto recae principalmente en los

BPMS, dejaremos para el siguiente captulo dedicado a estos sistemas los
detalles de esta implementacin.
Puesta en Marcha del proceso:
Y ya tenemos todo listo para funcionar! En la puesta en marcha, debe-

remos disponer de un plan de implementacin para desplegar todos los
sistemas, planes formativos e implementacin de todos los aspectos rela-
cionados con la puesta en marcha del proyecto.
Esta es una fase delicada, en la medida en que muchas organizaciones

llegan a este punto y al final no se deciden a poner en marcha el proyecto.
Los motivos pueden ser varios, pero principalmente, la resistencia al cam-
bio, es lo que retraer a las personas a finalmente conservar lo que ya tie-
nen y no querer cambiarlo por algo nuevo, aunque este algo ofrezca venta-
jas y mejoras sobre lo ya existente. Es por ello que hemos insistido en todo
el proceso en la gestin del cambio, en la formacin y en la implicacin del
personal desde la fase de iniciacin y de levantamiento de procesos, bus-
cando su implicacin y comprensin de los motivos del cambio desde la
visin estratgica hasta los resultados de las medidas asociadas a los proce-
sos, pues son las personas en ltima instancia las que debern hacer uso del
proceso y sin la implicacin de las mismas, ser imposible sacar adelante el
proyecto e implementar los procesos mejorados en la organizacin. En este
sentido son muchas las metodologas de implementacin de procesos que
abogan por el establecimiento de incentivos entre el personal de la empre-
sa asociados al xito en la implementacin y a la adopcin, buen manejo y
continuidad de los nuevos procesos.
327
Control del proceso y Mejora Continua.
En esta fase nos aseguraremos de haber alcanzado los objetivos por los
cuales se puso en marcha el proyecto de BPM y realizaremos las comproba-
ciones e informes sobre las metas alcanzadas. As mismo, nos aseguraremos
de mantener el esfuerzo en la mejora de los procesos mediante la continui-
dad del proyecto en otros proyectos de mejora, para dar continuidad al
ciclo de vida de los procesos y no dejarnos llevar por la inercia de dejar los
procesos abandonados una vez finalizado el proyecto.
Una vez implementado el proceso, el trabajo no finalizar en este punto,

pues constantemente debemos monitorizar y controlar la operativa del
proceso. As, en esta fase de control del proceso, repasaremos cada punto
de estos para identificar que puede ir mal en el mismo y establecer en esos
puntos, medidas y alertas de control. Una vez tengamos todos los proble-
mas identificados, buscaremos la manera de evitarlos o mitigarlos, discu-
tiendo con el equipo involucrado en el proceso la forma de poder evitar la
aparicin de estos problemas.
Mejora Continua es un trmino derivado de la gestin de la Calidad que

significa que constantemente debemos monitorizar los procesos de negocio
y realizar ajustes para asegurarnos de que el proceso es continuamente
mejorado. Esto implica recoger las mediciones del proceso y los datos de
indicadores del mismo, evaluar la satisfaccin de los usuarios y clientes del
proceso, revisando sus necesidades y expectativas, motivar al equipo de
trabajo y proporcionar la formacin necesaria a los mismos, as como man-
tener las lneas de comunicacin abiertas con el equipo en busca siempre
de la mejora y la innovacin continua, a sabiendas de que siempre pode-
mos hacer mejor las cosas y por encima de todo velar por que el proceso
no caiga en el saco del olvido y que continuamente ofrezca valor y utilidad a
los clientes.
La mejora continua, como vimos al hablar de calidad, la realizaremos se-

gn el ciclo de mejora continua, en este caso dirigido a los procesos:
328
- Evaluar: todos los aspectos del proceso de negocio, identificar

oportunidades de mejora, cuellos de botella, efectividad del
proceso, revisar necesidades y expectativas de los clientes, que
las medidas e indicadores sigan siendo los apropiados, pues a
medida que los proyectos y los procesos avanzan en su da a
da, surgen nuevas necesidades, se crean nuevas expectativas y
surgen nuevas oportunidades tanto de mejora de los procesos
como de nuevos modelos de negocio y productos y servicios
ms innovadores, para todo lo cual, deberemos crear un plan
para la implementacin de los errores, debilidades y oportuni-
dades identificadas, para haciendo uso de la flexibilidad de los
BPMS poder implementarlos de manera gil.
- Planificar: testear las mejoras que vayamos a introducir en el
proceso antes de implementarlas, asegurndonos de que cum-
plen con todos los aspectos asociados con el proceso tanto tc-
nicos como de negocio.
- Verificar: vigilar que los cambios aporten valor.
- Actuar: ejecutar los cambios en la organizacin.
Este ciclo de mejora continua se realizar principalmente a travs de

TQM, Six Sigma, BPR y haciendo uso de los propios sistemas BPMS. BPR y
Six Sigma pueden ser utilizados para la mejora de procesos que no cumplen
con las especificaciones de los clientes, Six sigma y TQM son utilizados ge-
329
neralmente para la mejora de los procesos y los BPMS sern la herramienta

tecnolgica a travs de la cual podemos disear e implementar las mejoras
sobre los procesos.
La mejora continua y el control de la operativa de los procesos suele ser

costosa y consume recursos, pero es necesaria para una correcta gestin de
los procesos. Sin embargo, con BPM y la informatizacin de la gestin por
procesos, esta tarea resulta mucho ms sencilla y exacta, en especial en el
control del ciclo de vida de los procesos y el monitoreo de los mismos en
base a indicadores y medidas de cumplimiento de su eficiencia y valor ofre-
cido a clientes. Estas herramientas tecnolgicas, sin las cuales no podemos
implementar BPM sern los BPMS y son los que veremos en el siguiente
captulo.
Social BPM.
Con este trmino de Social BPM, nos referimos a las posibilidades que
en todo el ciclo de vida de BPM tienen los conceptos y herramientas de la
denominada web 2.0 y como estos pueden ser usados para el diseo y me-
jora de procesos, su implementacin y su posterior control. Estas herra-
mientas son una extensin de las herramientas de software colaborativo,
en las que haciendo uso de foros, wikis, blogs, redes sociales abiertas o
cerradas y herramientas de votacin, nos permitirn gestionar este entorno
colaborativo y sus comunicaciones. Estas herramientas tendrn especial
relevancia a la hora de gestionar el conocimiento e ideas aportadas por los
distintos miembros en entornos geogrficamente dispersos o donde poda-
mos necesitar del anonimato de los empelados , partners de negocio, clien-
tes y stakeholders del proyecto en general, para el establecimiento de esta
colaboracin y aprovechar las ventajas de las aproximaciones Bottom-Up, la
inteligencia colectiva, la mejora de la experiencia de usuario y la innovacin
en las distintas fases del proyecto. As, podemos usar estas herramientas en
la fase de levantamiento de procesos, donde tanta importancia tiene la
colaboracin que establezcamos con los miembros de la organizacin y el
equipo de proyecto a la hora de seleccionar los procesos y recabar todos los
detalles sobre estos y sus posibilidades de mejora, lo cual mejorar la pro-
ductividad en el desarrollo del proyecto y generar un entorno propicio
330
para el intercambio de ideas y la innovacin. En la fase de modelado a la

hora de discutir y aportar inteligencia colectiva al modelo. En la fase de
anlisis y mejora de procesos, donde tal vez nos sean ms tiles estas
herramientas para el aprovechamiento de esa inteligencia colectiva o en las
fases de ejecucin del proceso donde los usuarios pueden requerir de estos
entornos colaborativos a la hora de tomar decisiones o en la fase de moni-
torizacin y control de procesos, para la comparticin de opiniones y posibi-
lidades de mejora sobre los resultados obtenidos.
TOC, Lean y Six Sigma dentro de un proyecto de BPM.
A continuacin daremos un repaso a como cada una de estas teoras

(TOC, Lean y Six Sigma) se integra dentro de un proyecto de BPM. A la hora
de aplicar estas tres metodologas dentro de un proyecto BPM enlazaremos
las mismas en distintos puntos del ciclo de vida de un proyecto BPM.
TOC (Theory of Constraints):
Partiendo de la estrategia, una de las primeras acciones que llevaremos

a cabo es la seleccin de los procesos sobre los que trabajar. Con TOC
(Theory of Constraints), partimos de una visin a alto nivel de todos los
procesos para investigar donde estn los problemas e identificar las restric-
ciones existentes o potenciales. Esta visin holstica, tan utilizada por BPM,
nos permitir focalizarnos en aquellos procesos que requieran mejoras a
nivel de sistema, en contraposicin a optimizar slo determinados depar-
tamentos o reas aisladas.
La identificacin de estos procesos centrales es la clave para los activos

de negocio que son fuente de ventajas competitivas y tienen un profundo
impacto para alcanzar las estrategias y objetivos de negocio. Si no ponemos
el foco en los procesos clave, corremos el peligro de usar luego las metodo-
logas de mejora de procesos como Lean y Six Sigma slo para la mejora de
determinadas partes del proceso o trabajar en procesos irrelevantes para el
negocio y aqu TOC hace de paraguas de las metodologas Lean y Six Sigma.
TOC establece que siempre existe una restriccin que marcar las salidas de
la organizacin y que esta generalmente est relacionada con la organiza-
cin funcional, gestionada en partes y no en su globalidad y a no ser que
331
veamos la empresa como una generadora de valor en su conjunto y nos

centremos en eliminar las restricciones clave del sistema, el impacto de
nuestro trabajo en mejora de procesos no ser relevante para el conjunto
de la organizacin.
La metodologa de TOC mirar primero cuales son las causas de los pro-
blemas y har uso de la lgica de causa-efecto para entender los proble-
mas, validarlos y corregirlos. TOC buscar estas races y seguir un proceso
para dar respuesta a las siguientes preguntas: Qu cambiar?, Hacia qu
cambiar? y Cmo causar el cambio?
TOC requiere que primero entendamos el sistema, sus objetivos y medi-

das para despus aplicar los 5 pasos:
1. Identificar las restricciones

2. Decidir como explotar las restricciones.
3. Subordinar todo a estas restricciones.
4. Si es necesario elevar las restricciones del sistema.
5. Si se ha eliminado la restriccin, ir al primer paso en busca de otra
restriccin y no dejar que la inercia sea la limitacin
El concepto bsico de TOC es a menudo descrito a travs de la analoga

de la cadena: una cadena es tan fuerte como lo sea el eslabn ms dbil
de la misma. TOC se centra en el comportamiento del sistema en su con-
junto y despus en cmo las diferentes partes del sistema intervienen en el
conjunto para alcanzar mejoras en todo el sistema y no slo en determina-
das partes del mismo, por lo que tendremos primero que entender toda la
cadena y no slo sus partes aisladas, identificar las barreras o puntos dbi-
les de la cadena y aislar y fortalecer el rendimiento de ese punto dbil para
mejorar el rendimiento global. Las mejoras que no mejoren el rendimiento
de este eslabn ms dbil, debern se subordinadas a la restriccin, pues
las mejoras en estas slo nos llevarn a realizar trabajo adicional sin rele-
vancia para los objetivos de negocio.
La perspectiva de TOC proporciona predictibilidad y estabilidad al cen-

trarse en proteger y gestionar las restricciones de todo el sistema y centrar
los esfuerzos de mejora en los procesos correctos. Una vez hemos seleccio-
nado los procesos correctos sobre los que trabajar, podemos aplicar los
esfuerzos de mejora para finalmente sostener las mejoras alcanzadas en el
tiempo.
332
Lean:
Una vez escogidos los procesos clave, podemos usar Lean para centrar-
nos en las mejoras del sistema, eliminar el desperdicio de los procesos se-
leccionados y mejorar su flujo.
El objetivo de la metodologa Lean es reducir el tiempo desde la orden

de un cliente hasta el cobro (time-to-cash), eliminando todos los desper-
dicios (waste) que no produzcan valor. En Lean existen 7 tipos de desperdi-
cios que aparecen en los sistemas: sobreproduccin, esperas, transporte,
inventario, movimientos innecesarios, sobre-procesados y defectos.
Lean nos ayudar en las fases de Levantamiento de procesos y en la de

mejora de procesos para entender exactamente cmo operan los procesos
del As-Is, clasificar los procesos o actividades de estos de estos que no aa-
dan valor, generen desperdicios, ineficiencias, cuellos de botella o restric-
ciones para identificar donde fallan y asegurarnos de arreglar los procesos
errneos.
Usamos la metodologa Lean para entender e identificar estos desper-

dicios y ayudarnos en los esfuerzos de mejora.
1. Especificar el valor. La pregunta que nos deberemos hacer es: en-

tendemos verdaderamente el valor desde la perspectiva del clien-
te? El valor aadido (el esfuerzo que los clientes estn dispuestos a
pagar por estos avances), debe ser identificado a travs del mapa
de procesos de la cadena de valor.
2. Identificar los pasos en la cadena de valor. Hacemos el mapeo de la
cadena de valor para detallar y analizar el flujo de materiales e in-
formacin para producir un producto o servicio al cliente. De esta
cadena de Valor, podremos identificar que acciones producirn va-
lor y cules no. Identificar la cadena de valor expondr muchas ac-
tividades que no aportan valor. Las que no produzcan valor sern
aquellas que consuman tiempo, recursos o espacio y no aadan va-
lor al producto y en consecuencia, tampoco al cliente.
3. Crear un flujo. Una vez entendamos los pasos para la creacin de
valor, el siguiente paso es crear un flujo continuo que reduzca el
tiempo y los desperdicios.
333
4. El principio Pull. Una vez conseguidos los tres principios anteriores,

podemos poner el sistema para producir lo que el cliente requiera,
el Pull System en oposicin al Push basado en predicciones.
En este punto y paralelamente, podramos considerar tambin la apli-

cacin de las 5Ss de Lean (Sort, Simplify, Scrub,Standarize, Sustain) as co-
mo otras herramientas de Lean como puedan ser :
- Kaizen event: proyectos de mejora continua centrados en incre-

mentar el valor de los procesos y reducir desperdicios.
- Mapa de la cadena de valor: representacin grfica de los pasos en
el proceso para producir un producto o servicio.
- Lead Time Analysis: el tiempo total desde que una tarea, proceso o
servicio comienza hasta que se completa.
- Gemba: ver dnde se realiza el trabajo. Revisar por ejemplo el As-Is
de cmo se realiza actualmente el trabajo.
- 5 Whys: mtodo iterativo para preguntar por qu para obtener las
causas races. Para ver dnde estn los problemas, preguntando
por qu existen los problemas. Es una de las mejores maneras de
identificar los problemas y sus orgenes para despus trabajar en su
mejora.
- Spaguetti Diagram: para mostrar el transporte o movimiento de
productos y servicios.
- SIPOC: una evaluacin de Supplier/Input/Process/Output/Customer
para obtener una visin centrada en el cliente del proceso.
- 6 Ss: Un ejercicio usado para crear y mantener un espacio de traba-
jo organizado: Sort, Set in order, Shine, Standardize, Sustain y Safe-
ty.
Six Sigma:
Con los pasos anteriores, tendremos establecido un proceso mejorado

sobre el que podremos predecir su comportamiento y resultados esperados
y entraremos ahora en la fase de optimizacin del proceso para reducir las
variaciones en el mismo y alcanzar los resultados con el menor desperdicio
y re-trabajo. Entramos en los puntos 5 y 6 de Lean de perseguir la perfec-
cin e implementar con agilidad, refinando continuamente nuestra pro-
puesta y cadena de valor en un proceso iterativo.
334
En este punto una vez establecida la configuracin de nuestro proceso,

necesitamos estandarizar las operaciones, procedimientos y mecanismos
de control para lo que podremos usar la metodologa de Six Sigma. Esta
metodologa inicialmente usada como sistema de medicin y de reduccin
de defectos asociados a procesos manufactureros y de produccin, ha evo-
lucionado hasta convertirse en una metodologa de management para la
mejora continua y centrada en cmo las variaciones afectan a los resultados
deseados por la organizacin y la satisfaccin de clientes. El objetivo de Six
Sigma es reducir los defectos, los tiempos de ciclo y aumentar la producti-
vidad y la satisfaccin del cliente a travs de la reduccin de variaciones en
los productos y los procesos y proporcionando a las organizaciones una
ventaja competitiva. La reduccin de defectos proporcionar mayor satis-
faccin de clientes, menores costes de calidad y aumento de los beneficios.
El ciclo bsico para la resolucin de problemas y las variaciones en

nuestros procesos utilizado por Six Sigma es DMAIC, el cual nos permitir
identificar y aislar las fuentes de desviacin en los procesos para minimizar-
los o eliminarlos sistemticamente. Durante el ciclo DMAIC, podemos si-
mular y comparar unos modelos de procesos con otros para determinar
cules cumplen mejor con los objetivos de throughput, costes, tiempos y
recursos que precisamos.
Qu aporta BPM a TOC, Lean y Six Sigma:
Como vemos, TOC, Lean y Six Sigma se centra en comprender y analizar

las deficiencias en los procesos y en cmo mejorarlos mientras BPM se cen-
tra en la automatizacin, la gestin y el control de los procesos mejorados
as cmo en la recoleccin de datos e informacin, proporcionando a los
equipos de mejora de procesos de la rapidez y flexibilidad necesarias para
poder alcanzar ventajas competitivas. Y producir un matrimonio perfecto
entre todas las metodologas.
BPM ayuda adems a los equipos de TOC, Lean y Six Sigma a actuar
proactivamente y a trabajar constantemente sobre los procesos en la orga-
nizacin orientada a procesos y no en acciones de mejora de procesos ais-
ladas, proporcionando el contexto para poder realizar las tareas asociadas
al proceso, mantener a las personas informadas y proporcionando las
herramientas para poder medir y analizar la operativa de los procesos en
tiempo real.
Una de las reas de BPM en las que mayores beneficios encontrarn

TOC, Lean y Six Sigma es en la de simulacin Con las capacidades de simula-
335
cin de BPM, TOC, Lean y Six Sigma pueden modelar los procesos, evaluar y
testear alternativas de procesos en aspectos como costes, tiempos de ciclo,
cuellos de botella y restricciones que sern difciles de ver sin recoger datos
y simulando el sistema,. La simulacin facilitar tambin el anlisis de ta-
reas que no aportan valor y desperdicios que podrn ser analizados durante
la simulacin para determinar la configuracin del proceso que mejor cum-
pla con los requerimientos del negocio y minimizar los riesgos de una im-
plementacin a un coste mucho menor que realizando experimentos fsi-
cos.
Las capacidades de automatizacin de procesos en BPM, proporciona-

rn tanto durante las simulaciones como en entornos de produccin, la
retroalimentacin en tiempo real de datos, informacin y mtricas de los
procesos necesaria para las entradas de Lean y Six Sigma y que esta meto-
dologas puedan continuar sus ciclos de mejora continua, acelerando la
recogida y recepcin de datos para validar los procesos, analizar los mismos
e identificar reas de oportunidades y necesidades de mejora en menos
tiempo y con menos esfuerzo que sin BPM.
Adems la simulacin, BPM proporcionar tambin los beneficios de

disponer de un Cuadro de Mando para la monitorizacin en tiempo real de
los procesos y sistemas de alertas para eventos especficos de los procesos,
proporcionando la informacin correcta, en el momento correcto en un
entorno grfico y amigable para la monitorizacin y anlisis de los procesos
de forma que los expertos en mejora de procesos pueda aprovecharse de la
rapidez y flexibilidad para redefinir o modificar los procesos.
Otras ventajas para TOC, Lean y Six Sigma de la utilizacin de un BPM

son:
- Acceso a datos y mtricas.
- Reglas de negocio y entorno grfico en el que podemos de forma

fcil definir y modificar los procesos para simularlos y ejecutarlos,
de forma que un experto en Six Sigma podr disear e implementar
un proceso y automatizarlos sin necesidad de conocimientos de
programacin aprovechndose de las ventajas que BPM ofrece.
- Capacidades de BAM, Monitorizacin, control, estandarizacin.
- Visibilidad del proceso,
336
- Eficiencia en implementar futuros estados del proceso, gestionar y

simular versiones de procesos, pudiendo construir nuevos procesos
ms rpidamente,
- Automatizacin de workflows para gestionar interacciones huma-

nas y de sistemas,
- Edicin de reglas de negocio que reemplacen a las decisiones ma-

nuales, etc.
Gestin del proyecto:
La principal causa de fracaso de los proyectos (de cualquier tipo) se en-

cuentra principalmente en aspectos como:
- Mala especificacin de requerimientos o una mala gestin de

las expectativas de los usuarios o clientes, para traducir estas
expectativas en necesidades y requerimientos claros, precisos,
medibles, reales y alcanzables en el tiempo.
- La no implicacin de los usuarios, que ya hemos visto como lo-

grarla, principalmente a travs de su implicacin en las fases
ms tempranas del proyecto de forma que participen tambin
en el diseo del mismo, tanto para aportar conocimiento y ex-
periencia como para ganarnos su complicidad en el resto del
proyecto al haber sido participes del diseo y configuracin del
mismo.
- Falta de recursos tcnicos y humanos para poder llevar el pro-

yecto a cabo.
- Falta de planificacin.
- Falta de control de calidad, de control de los cambio en el pro-

yecto, etc.
Pero uno de los aspectos que se apunta como primordial para asegurar
el xito del proyecto es el la utilizacin de una metodologa en la gestin de
proyectos y la involucracin de un Director de Proyecto o Project Manager,
en ingls que lidere el proyecto, lo coordine, se responsabilice del mismo,
337
sirva de escudo protector del mismo y lo proteja de todo aquello que pueda
amenazar los objetivos del proyecto, sea intendente para garantizar la dis-
ponibilidad de recursos, agente de seguros, que se ocupa de la gestin de
riesgos del proyecto, perito que mida y evale el trabajo realizado, inspec-
tor del compromiso con los hitos y entregables del proyecto, entrenador
que se ocupa del desarrollo y capacitacin del equipo, concentrador de
toda la informacin, documentacin y comunicaciones del proyecto y que
junto a sus habilidades personales de liderazgo, negociacin, empata y
proactividad consiga llevar el proyecto a buen puerto. Vamos, un super-
man!, que si bien no tiene por que ser un experto en BPM o en la materia o
sector del que trate el proyecto si debe conocer estos aspectos pero actua-
r sobre todo como Jefe de Proyecto y en consecuencia sus habilidades y
conocimientos en la direccin de proyectos sern las ms importantes.
La Gestin de Proyectos (Project Management) ser un requisito esen-

cial para el xito de cualquier proyecto y en consecuencia tambin para los
proyectos que emprendamos en BPM y la mejora de procesos, pues ser la
correcta gestin del proyecto la que sustente el proyecto en s, que debe
ser gobernado, dirigido y controlado por una correcta metodologa de ges-
tin de proyectos para asegurar que el proyecto de BPM progrese adecua-
damente y alcance sus objetivos. Las metodologas de gestin de proyectos
asumen que existe un punto inicial, una serie de pasos y un resultado se-
guido de la evaluacin del mismo. Estos pasos, en concreto, sern la gestin
unificada de personas, procesos y tecnologa para convertir los inputs (mi-
sin, personas y recursos) en outputs que aporten valor (cumplir las metas
y objetivos del proyecto) y sern las principales reas que deberemos ges-
tionar en el proyecto.
Como venimos presumiendo desde el inicio de este libro, los proyectos

de BPM implican cambios en las organizaciones y las personas que deben
ser gestionados correctamente, no son slo proyectos que se basen en la
implantacin de una herramienta software, sino que esta herramienta su-
mada a cmo diseemos o rediseemos los procesos de la organizacin
para formar la arquitectura de procesos, conformaran un todo alineado con
la estrategia de la empresa para reducir el gap entre personas, procesos y
tecnologa.
Existen distintas metodologas de implementacin perfectamente des-

critas por organizaciones como BPTrends para la gestin de proyectos en
BPM. Nosotros no las describiremos todas, pero si realizaremos una breve
descripcin de la gestin de un proyecto BPM desde la perspectiva del
338
PMBOK (Project Management Book of Knowledge) del PMI (Project Mana-

gement Institute), considerando los aspectos clave que debemos gestionar
en nuestros proyectos de BPM. Estos puntos clave de cualquier proyecto
sern:
- qu vamos a hacer, qu producto o servicio vamos a producir

o entregar?, conocer el Alcance del proyecto.
- qu estndares deberemos cumplir? Calidad.
- Qu tiempo vamos a emplear en cada tarea y en la totalidad

del proyecto? Duracin prevista.
- Qu costes vamos a tener? Costo.
- Qu seguridad tenemos de poder obtener el producto o servi-

cio con el Alcance los Tiempos, y la Calidad requerida por el
proyecto? Riesgos.
- Qu necesitamos para poder llevar el proyecto adelante? Re-

cursos Humanos. Adquisiciones
- Cmo combinamos todo lo anterior? Gestin de la informa-

cin y las comunicaciones.
Basndonos en este estndar del PMI para la gestin de proyectos y de

forma resumida, pues no veremos en este apartado todas las reas de co-
nocimiento y grupos de procesos que deben ser considerados para la ges-
tin de proyectos, tendremos en cuenta los siguientes aspectos importan-
tes a la hora de realizar la implementacin:
- Seguir el ciclo de vida de gestin de los proyectos, procurando

ser metodolgicos en su cumplimiento:
339
- Acta de Constitucin del proyecto: correspondiente al grupo de

procesos de iniciacin, ningn proyecto debera comenzar sin
una aprobacin formal por parte del patrocinador o cliente que
autorizo el proyecto y el poder comenzar a dedicar recursos,
tiempo y dinero al proyecto. Esta fase de inicio al igual que la de
cierre (sobre todo en cuanto a recoger lecciones aprendidas du-
rante el proyecto), son fases que se suelen obviar o saltar en
todos los proyectos.
- Gestin de cambios o atencin al proceso denominado en el
PMBOK como Control Integrado de Cambios. Sabemos que el
cambio es algo intrnseco a todo proyecto y los de BPM sern
especialmente susceptibles de cambio, tanto por el gran nme-
ro de grupos y personas involucradas en el proyecto como por
los distintos ciclos y etapas por los que pasar el proyecto, lo
que nos obligar a ser metodolgicos y estrictos en cuanto al
tratamiento, control y gestin de los cambios que puedan surgir
durante el desarrollo del proyecto y nunca integrar ninguna so-
licitud de cambio sin analizar y evaluar el impacto que este
cambio pueda tener en el proyecto y en reas como el Alcance,
el Tiempo, el Coste del proyecto y la Calidad.
340
- Gestionar los Riesgos: como Jefes de Proyecto nos mantendre-

mos siempre alerta ante los riesgos que puedan amenazar al
proyecto, tanto los que identifiquemos en las fases ms tem-
pranas del mismo como en fases posteriores y aquellos que no
hayamos predicho, por lo que esta identificacin, clasificacin,
evaluacin y anlisis de impacto de los riesgos la realizaremos a
lo largo de todo el ciclo de vida del proyecto. Una buena prcti-
ca para la gestin de riesgos es el uso de la matriz RBS (Risk
Breakdown Structure) en la que representaremos la probabili-
dad (alta-baja) y el impacto (alto-bajo) que los distintos riesgos
puedan tener sobre el proyecto y en funcin de esta establece-
remos planes de contingencia y planes de respuesta a riesgos.
En esta gestin de riesgos, recordar que los riegos que los ries-
gos pueden ser positivos o negativos por lo que muestra misin
ser eliminar o mitigar el efecto de los riesgos negativos o ame-
nazas y explotar los positivos u oportunidades, que sern aque-
llas que puedan afectar positivamente al proyecto.
- Plan de comunicacin: importantsimo para el xito de la im-
plementacin. Ser la funcin principal del Director de Proyecto
pues en esta tarea pasar la mayor parte del tiempo dedicado a
la gestin del proyecto.
- Plan de formacin: que capacidades y habilidades sern necesa-
rias para el personal involucrado en el proceso y en el proyecto.
En todo este apartado de gestin de gestin del proyecto, debemos dis-

tinguir entre el ciclo de vida del proyecto y el ciclo de vida del producto. El
341
ciclo de vida del proyecto es la ejecucin de los trabajos necesarios para

obtener los entregables del mismo, mientras que el ciclo de vida del pro-
ducto, est referido a los procesos y se prolonga desde su concepcin (la
definicin de los procesos) hasta la retirada del mismo (cuando el proceso
es retirado, rediseado o sustituido por otro proceso). El ciclo de vida del
producto puede contener muchos proyectos.
Los proyectos de BPM normalmente son fases de un proyecto ms gran-

de y rara vez alcanzaremos los objetivos planteados en un solo proyecto.
Necesitaremos mejora continua y la implementacin de varios proyectos
para alcanzar los resultados esperados mediante la medida continua de
indicadores y la depuracin y optimizacin de estrategias y procesos.
En el recorrido descrito en este captulo hemos indicado aspectos de la

gestin del proyecto relevantes en las distintas etapas que hemos visto
como la necesidad de la realizacin y aprobacin por parte del CEO del Acta
de Constitucin del Proyecto, la elaboracin del Plan de Proyecto, etc. Sin
embargo hay reas importantes de la gestin de proyectos no descritas y
que debemos considerar para implementar el proyecto con xito y que
describimos a continuacin.
Jefe de Proyecto:
Hemos hablado mucho del jefe del proyecto en todo el libro y le hemos
atribuido demasiadas tareas, habilidades y responsabilidades, que todas
juntas nos vienen a indicar cual deber ser su papel principal en el proyec-
to.
La importancia del responsable del proceso y del gestor del proyecto,

que pueden no ser la misma persona, y debera ser as, asignando una per-
sona como gestora del proyecto y responsable ltima del xito en su im-
plementacin y que desaparecer despus de la misma, al ser el proyecto
de implementacin un proyecto con una fecha de inicio y final y no como el
responsable del proceso que deber permanecer mientras continen los
procesos en funcionamiento.
El jefe de proyecto deber mantener todas las reas y aspectos del pro-
yecto unidos, sean estas partes tecnolgicas, de procesos, de negocio o
relacionadas con aspectos externos de la organizacin. Es el super hroe
del que hablbamos antes, que sin realizar un trabajo real relacionado di-
rectamente con el proyecto, se encarga de coordinar todas sus partes y de
asegurar el xito del proyecto resolviendo los problemas y conflictos que
342
surjan durante el mismo, tomar las decisiones para que el proyecto avance
en la direccin adecuada e implicar a todos los participantes para que todos
sepan qu tienen que hacer, cuando y como para que todas las acciones
tengan sentido dentro del proyecto, se ejecuten en la secuencia adecuada y
de esta forma obtener el mayor rendimiento del proyecto y alcanzar los
resultados.
El entorno en el que se mover el jefe de proyecto ser el de una lista de

tareas (To-Dos) relacionadas con el alcance del proyecto, los tiempos y
cronogramas, los costes, los riesgos, la calidad del proyecto y el manejo de
la informacin y las comunicaciones asociadas al proyecto, realizar informes
de seguimiento, verificaciones y controles del progreso del proyecto.
El Plan de Direccin del Proyecto:
El recorrido que vamos a realizar debe comenzar, siguiendo la metodo-

loga del PMI (Project Management Institute), por la realizacin del Acta de
Constitucin del Proyecto, que autorice formalmente el mismo y el inicio de
los trabajos, identifique a los stakeholders interesados en el proyecto y los
requisitos que debe satisfacer el proyecto (no el proceso) para satisfacer a
estos stakeholders.
La aprobacin del Acta de Constitucin del proyecto debe ser realizada

por el promotor o sponsor, que es quien solicita la ejecucin del proyecto
de diseo o mejora de los procesos existentes, e indica ya en esta fase los
procesos con los que cuenta la organizacin y las mejoras que pretende
sobre estos procesos. En esta fase el director de proyecto, responsable de
cumplir con los objetivos del proyecto en tiempo, calidad y coste, debera
estar ya seleccionado y asignado al proyecto. Este director de proyecto ser
adems el interlocutor entre el equipo del proyecto y el sponsor o patroci-
nador del mismo.
El papel del director del proyecto ser el de un integrador y comunica-

dor, encargado de coordinar todas las actividades del proyecto de forma
cohesionada, de forma que se consigan los objetivos para los que fue ini-
ciado el proyecto. El Director de proyecto deber integrar adecuadamente
los elementos clave (alcance, tiempo, coste, calidad y riesgo) y disponer de
conocimientos sobe gestin de proyectos y habilidades para manejar los
recursos, la incertidumbre y los riesgos intrnsecos a todo proyecto, gestio-
nar los conflictos, motivar a los equipos de trabajo, tomar decisiones, cum-
343
plir los requerimientos del proyecto y alcanzar los objetivos del proyecto as
como mantener un cdigo tico de conducta en sus decisiones.
Al comienzo del proyecto es fundamental asegurarnos de que la estrate-

gia, la visin, las metas y objetivos del proyecto son comprendidas por to-
dos los miembros del equipo y asegurarnos su compromiso y en especial el
del CEO de la organizacin.
Un aspecto importante a analizar por el director del proyecto es la es-

tructura organizativa sobre la que vamos a implementar el proyecto. Los
proyectos de BPM son grandes generadores de cambio, pues implican el
paso de un proceso a otro proceso nuevo, con lo que nos encontraremos
con personas con mayor o menor resistencia al cambio y configuraciones
organizacionales ms o menos diseadas para aceptar estos cambios. En
captulos anteriores hemos visto la organizacin orientada a procesos. Este
tipo de organizacin facilitar mucho este proceso de cambio por la simbio-
sis entre los procesos y la estructura de la organizacin, pero normalmente
nos encontraremos organizaciones ms funcionales y departamentales
donde como directores de proyecto, tendremos serias dificultades de co-
municacin transversal y de disposicin de recursos para llevar adelante el
proyecto que en organizaciones ms orientadas a proyectos, sobre las que
podremos desarrollar el proyecto ms fcilmente.
En esta fase de iniciacin del proyecto seleccionaremos tambin al equi-

po de diseo del proyecto, el cual puede estar formado por analistas de
procesos, personal de TI y de negocio y directores de departamento o uni-
dades de negocio involucrados en los procesos sobre los que vamos a traba-
jar.
Una vez disponemos de la autorizacin formal para autorizar el proyecto

y en consecuencia, el director de proyecto tiene autoridad para asignar
recursos al proyecto, nos reuniremos con el equipo de proyecto para plani-
ficar el proyecto: conocer el alcance del mismo, definir claramente el pro-
blema que queremos resolver, saber por qu queremos realizar este cam-
bio, describir la situacin actual, los objetivos que se pretenden conseguir
con el proyecto y como estos estn alineados con la estrategia de la empre-
sa, las mediciones de las que disponemos del proyecto actualmente y que
mediciones se esperan alcanzar, o sea, la calidad que se espera del proyec-
to. Definiremos tambin cual ser el alcance del proyecto, los lmites entre
los que nos podemos mover, qu recursos sern necesarios en la organiza-
cin para ejecutar el proyecto y si estos sern internos y/o externos. Planifi-
344
caremos el tiempo en el que el proyecto debe estar finalizado y su corres-

pondiente cronograma, el presupuesto del que disponemos, si podremos
hacer todo el trabajo internamente o necesitaremos subcontratar determi-
nadas actividades, identificar y valorar todos los riesgos y oportunidades
que podemos tener y los entregables que deberemos obtener al finalizar el
proyecto, como se gestionarn los cambios a lo largo del proyecto, etc.
Todas estas preguntas conformarn el Plan de Direccin del Proyecto, el

cual nos guiar a lo largo de la fase de implementacin y definir la manera
en que se ejecutar el proyecto, se monitoriza, se controla y se cerrar el
mismo. Este Plan de Proyecto es un documento vivo a lo largo de la vida del
proyecto, el cual puede ser actualizado a travs del control integrado de
cambios al Plan de Direccin de Proyecto e incluye entre otros:
- Las lneas base del proyecto:

o Lnea base del cronograma.
o Lnea base de costos.
o Lnea base del alcance.
- El plan de gestin del alcance.
- El plan de gestin de requisitos.
- El plan de gestin del cronograma.
- El plan de gestin de costos.
- El plan de gestin de la calidad.
- El plan de gestin de recursos humanos.
- El plan de gestin de las comunicaciones.
- El plan de gestin de riesgos.
- El plan de gestin de las adquisiciones.
Para su gestin debemos tener en cuanta un aspecto fundamental de

todo proyecto como es la Triple Restriccin en el tiempo, el coste y el
alcance, de tal forma que la modificacin de una de ellas tiene un claro
impacto en las otras dos y no podremos por ejemplo aumentar la calidad
del proyecto sin aumentar su coste, o reducir el tiempo de entrega del
mismo sin por ejemplo reducir su alcance.
345
Tie
e
nc
mp
ca
o
Al
CALIDAD
Coste
Una buena prctica para el desarrollo de este Plan de Direccin del Pro-
yecto es la realizacin de la EDT (Estructura de Desglose del Trabajo), para
subdividir los entregables del proyecto en paquetes de trabajo ms mane-
jables que puedan ser asignados a personas o equipos de trabajo. La EDT es
una herramienta de descomposicin jerrquica orientada a entregables que
incluye todo el trabajo necesario para realizar el producto e incluye el pro-
pio trabajo de gestin del proyecto. A partir de la EDT nos ser ms fcil
calcular y realizar estimaciones de tiempo y costes para el proyecto.
Otro aspecto importante a tener en cuenta en la gestin de proyectos

son las restricciones y supuestos del proyecto. Las restricciones pueden
limitar las opciones del equipo en cuanto a presupuesto, hitos del crono-
grama o legislaciones gubernamentales. As mismo, los supuestos que pue-
dan acontecer deben ser identificados y documentados, para analizar el
impacto que pueden causar en el proyecto en el caso de que sean ciertos.
Entre los supuestos que suelen aparecer se incluyen: disponibilidad de re-
cursos, software, equipos o personas para la realizacin de determinadas
tareas o cambios en los precios de estos recursos y que en caso de no poder
contar con ellos, pueden causar un impacto negativo en el proyecto.
Sobre este Plan de Direccin de Proyecto deberemos alcanzar el mayor

consenso posible dentro de la organizacin para asegurarnos el compromi-
so de todos los miembros, explicarles este plan y hacer todas las correccio-
nes necesarias sobre el mismo, pues en esta fase es donde menos costosos
sern los cambios.
346
Alcance del proyecto:
El modelado de procesos tambin nos servir para comunicar el Alcance

del proyecto y delimitar donde comienza y acaba el mismo o partes del
mismo y saber de esta forma, qu est incluido y qu no lo est dentro del
proceso sobre el que estemos trabajando, que partes son subcontratadas y
cuales realizadas por la propia organizacin, etc. Tener en cuenta que un
proyecto slo se completa cuando la razn por la cual fue iniciado el pro-
yecto se alcanza o supera.
En general, para la gestin del proyecto necesitaremos conocer el es-

fuerzo que llevar realizar el As-Is y determinar el To-Be asociado con los
objetivos del proyecto, qu vamos a necesitar para conseguir este To-Be y
cuanto costar en trminos de coste, tiempo y recursos pasar del As-Is al
To-Be as como su implementacin y puesta en marcha y los riesgos que
asumimos con esta transformacin.
Gestin de las Comunicaciones:
Durante el proyecto necesitaremos un buen plan de gestin de las co-

municaciones, pues son proyectos en los que tendremos gran nmero de
stakeholders y por las caractersticas particulares de los proyectos BPM,
deberemos gestionar muy bien la gestin del cambio y de las personas invo-
lucradas en el mismo para el xito del proyecto. En este sentido, debere-
mos explicar muy bien el proyecto y, como vimos en la fase de levanta-
miento de procesos, involucrar a las personas desde el primer momento en
el diseo de procesos, hacindolas partcipes del mismo y asegurndonos
su complicidad durante las fase de implementacin y posterior puesta en
marcha del proyecto incluyendo su gestin en el da a da.
La comunicacin ser fundamental. Como vimos en el Captulo dedicado

al modelado de procesos, la principal utilidad del modelado es la comunica-
cin con nuestro equipo, el resto de miembros de la organizacin, nuestros
clientes y nuestros partners. Los modelos se crean principalmente para
comunicar, y la complejidad creciente de los negocios globalizados y alta-
mente informatizados hacen del modelado una herramienta indispensable
para representar que y como lo hacemos y cmo podemos mejorar y trans-
formar nuestras organizaciones, por lo que el modelado de procesos, los
As-Is, Could-Be y To-Be de los procesos mejorados, sern todos ellos
347
herramientas fundamentales en nuestras actividades de comunicacin an-

tes, durante y despus de la realizacin del proyecto.
En la comunicacin usaremos tambin el Business Motivation Model pa-

ra comunicar la estrategia al resto de la organizacin as como el modelado
organizacional representando la estructura de la organizacin, quien har
las tareas, a quien reportar, etc. de forma que mostremos a las personas
involucradas en el proceso los cambios que repercutirn en su da a da.
Todo este material utilizado para gestionar las comunicaciones del pro-
yecto nos servir no slo para comunicar a empleados sino tambin para
persuadir de la necesidad y ventajas del proyecto a los patrocinadores del
mismo.
La comunicacin regir toda la vida del proyecto desde su la concepcin

inicial y nos servir tambin para la gestin del conocimiento dentro de la
organizacin, documentando toda la informacin relativa al proyecto de
quien y como se realizarn los trabajos, cmo interactan las personas de-
ntro del mismo, las habilidades y conocimientos necesarios para realizar los
trabajos y los distintos procesos.
No vamos a extendernos mucho ms en este importante aspecto de la

gestin de proyectos pues el lector dispone de abundante material en in-
ternet y en otras fuentes tanto de la metodologa PMI (Project Manage-
ment Institute) como CMMI, que tambin disponen de abundante informa-
cin sobre la gestin de proyectos.
Factores crticos de xito de un proyecto BPM.
Como resumen de este captulo dedicado a la implementacin de un

proyecto de BPM, recurrir a una metfora para la implementacin de BPM
descrita por John Nelis en su libro Business Process Management. Esta
metfora representa el esfuerzo conjunto de un proyecto de BPM mediante
la imagen de un equipo de remo, comandado por un director de proyecto o
timonel.
348
Resultado
Personas
Tecnologas de
Recursos
la Informacin.
Organizacin
Procesos (TI)
Informacin
Direccin de
Proyecto /
Timonel.
Objetivo
Segn Nelis, los factores crticos de implementacin de un proyecto de

BPM son, realizando una metfora con esta embarcacin son:
- Velocidad: es crucial. El objetivo general es ganar valor y se gana si y

solo si, se es el primero y s es el primero siendo ms rpido. Ya no
nos valen aqu esas eternas e inacabables implementaciones de
ERPs tan traumticas para tantas empresas.
- Eficiencia: asegurando que toda la energa y entusiasmo disponible
sea usada ptimamente para alcanzar los resultados esperados. Ex-
traer lo mejor del equipo y las personas de la organizacin. Asegu-
rando que todos contribuyan suficientemente.
- Equilibrio: para evitar que el barco se escore hacia los lados, equili-
brando la fuerza, el peso y la experiencia de todos los participantes.
- Cohesin: entre todos los miembros del equipo para asegurar que
todos remen al mismo ritmo y tcnica, que es lo que da la veloci-
dad.
- Procesos: son lo primero y los que dictan la velocidad de los dems
remeros. En un proyecto BPM, los procesos de negocio deben lide-
rar y la tecnologa y las personas seguirles.
- Management: Project manager o Jefe de Proyecto. Hace mantener
el barco en la lnea correcta hacia la meta de forma que este no se
vaya mucho hacia las personas y la tecnologa o hacia las personas y
los procesos.
349
Adems de esta metfora de Nelis para la implementacin de BPM, po-

demos recomendar como buenas prcticas en los proyectos de BPM las
siguientes:
- Formar al equipo: BPM es una nueva disciplina que requiere de

habilidades y formacin que pueden ser difciles de conseguir, so-
bre todo a la hora de interiorizar la nueva forma de pensamiento,
combinando sus conocimientos de negocio y TI con las herramien-
tas de BPM disponibles en el mercado y la capacitacin del personal
en las mismas. Sensibilizar, informar y formar debidamente a las
personas que participarn en el proceso nos asegurar en gran me-
dida el xito del mismo.
- Involucrar al equipo directivo: a las personas responsables de resol-
ver los problemas que deben convertirse en evangelistas de BPM.
- Gestionar las expectativas: los proyectos de BPM involucran a mu-
chos stakeholders y cada uno tiene sus propias expectativas. Co-
menzar con pequeos pasos, completar los proyectos a tiempo, evi-
tar inflar las expectativas y demostrar las ventajas del proyecto.
- Seguir una metodologa: Si existe una como Six Sigma, usarla para
facilitar la introduccin de BPM. Si no existe establecer una.
- Usar una metodologa de gestin de proyectos.
- Disponer del compromiso de la Alta Direccin para la ejecucin del
proyecto, as como de la asignacin de recursos y tiempo para el
proyecto.
- Hacer una buena seleccin de la herramienta BPMS que vayamos a
utilizar.
- No implementar BPM como un sistema de gestin paralelo, es me-
jor escoger un proceso y trabajar sobre l para implementarlo.
- Acometer proyectos pequeos al principio, de forma que podamos
alcanzar resultados tangibles en reas concretas, reducir costes y
obtener resultados a corto plazo.
- No retrasar demasiado tiempo la puesta en marcha por querer con-
siderar todos los detalles.
- Planear y gestionar el cambio: lo que mata a los desarrolladores de
software son los requisitos que cambian en los proyectos. Esto
siempre va a ocurrir, acepta el cambio, BPM se monta para poder
cambiar fcilmente. BPM es un cambio en s mismo, un cambio de
filosofa y en la manera de pensar que se crea para poder adaptarse
y gestionar el cambio.
350
351
Captulo 8. Tecnologa BPM. BPMS
Los sistemas BPMS (Business Process Management Systems) suponen

una autntica revolucin en la industria del software al proveer bajo una
misma plataforma, un conjunto de servicios y herramientas que facilitan el
modelado, despliegue, gestin y seguimiento de los procesos de negocio
siguiendo el ciclo de vida de estos, con la capacidad de disear estos proce-
sos, simularlos, ejecutarlos y monitorizarlos, al tiempo que integramos es-
tos procesos con personas y con los sistemas y aplicaciones informticas
internas y externas de nuestra empresa para controlar su flujo de trabajo.
Los BPMS incluyen mdulos funcionales, capacidades tcnicas e infraes-

tructuras de apoyo integradas en un nico entorno y que convierten a los
BPMS en la herramienta tecnolgica que nos permitir implementar BPM
en nuestra organizacin, de forma gil y con la suficiente flexibilidad para
poder modificar los procesos segn cambian las necesidades de negocio.
Esta unificacin en un mismo entorno, permite por ejemplo convertir un

modelo en BPMN en ejecutable y poder modificar la lgica de negocio de
nuestros procesos en ejecucin y sus aplicaciones, sin necesidad de rehacer
el cdigo fuente.
Workflow:
Como comentamos, los BPMS contemplan soporte para interaccin

humana, e integracin de aplicaciones, y esta integracin con sistemas es
352
una de las principales diferencias con los sistemas WorkFlow existentes

hasta ahora. Los sistemas de workflow tradicionales, permiten el modelado
y ejecucin de procesos, pero no la definicin de criterios que puedan ser
usados para determinar si estamos ejecutando correctamente los procesos.
Los BPMS pueden ser vistos como una extensin de los workflow, pero
de una forma mucho ms amplia, pues las soluciones de workflow repre-
sentan slo uno de los diez mdulos interrelacionados con los que puede
contar un BPMS. En la prctica, un flujo BPM (o modelo de proceso BPM)
visualmente es muy parecido a un WorkFlow, pero la diferencia est en que
en que en los BPMS ciertas actividades son realizadas por personas, y otras
son actividades automatizadas y ambas aparecen en el flujo.
Las soluciones tradicionales del tipo WorkFlow, se limitaban a definir el

flujo de actividades humanas, o de documentos, y con esto obtener el se-
guimiento de los procesos, pero en estos casos, si un participante del pro-
ceso requera como parte de sus actividades ingresar datos de una aplica-
cin externa, deba salir del entorno del WorkFlow, ir a la aplicacin, para
despus volver al WorkFlow y registrar el cambio. En BPM todo est inte-
grado en el mismo flujo, lo que es ms natural para un participante, pues
este completa su actividad dentro del flujo BPM, y por detrs se actualizan
los sistemas necesarios para la ejecucin del proceso.
353
Menos programacin:
Otro aspecto que suele llamar la atencin, en especial para enfadar a los
programadores, es el que afirma que no es necesario escribir una sola lnea
de cdigo, cualquiera puede realizar las aplicaciones software. En BPM los
procesos no se programan, sino que se modelan grficamente, permitiendo
que sea ms sencilla su modificacin sin tener que programar o recurrir a
cdigo intermedio, pues modificando el modelo, esta modificacin se refle-
ja en la aplicacin web resultante. Otras veces, en lugar del modelado po-
dremos hacer uso de BPEL, con el cual, como hemos visto al inicio de este
captulo, podremos tambin modelar procesos de negocio sin necesidad de
programar y que gracias a BPEL4People, como una capa superior de BPEL,
podremos incluir en el modelado la interaccin humana resultando en que
los procesos modelados en BPEL al final quedarn expuestos como servicios
web (web services).
Si bien esto es cierto para algunos tipos de implementaciones y proce-

sos, no es as para todo ellos, e independientemente, siempre necesitare-
mos programadores para las integraciones que realicemos con aplicativos y
web services externos. Adems, nuestra recomendacin es la de contar
siempre con el equipo de sistemas, por la visin ya comentada que estos
tienen sobre el conjunto de la organizacin.
Al igual que con la notacin BPMN, un BPMS puede ser usado por prc-
ticamente cualquier perfil dentro de la organizacin, tanto personal de TI
como de negocio y aqu radica otra de sus ventajas. La gente de negocio y
los analistas crean conjuntamente los modelos y definen los datos a ser
usados para gestionar y monitorizar un proceso, reduciendo la brecha entre
los requerimientos de negocio y como estos son implementados por la tec-
nologa, al reducir y prcticamente eliminar las necesidades de programa-
cin de cdigo fuente, tanto en la concepcin inicial del sistema, como en
posteriores fases de mejora, depuracin y mantenimiento, involucrando a
la gente de negocio en estas tareas hasta ahora restringidas a analistas y
programadores expertos en desarrollo software y pudiendo generar cdigo
ejecutable directamente desde los requerimientos de negocio modelados
en un entorno grfico.
Los BPMS pueden ser definidos como herramientas de desarrollo de alto

nivel orientadas al desarrollo rpido de aplicaciones, alineadas con los pro-
cesos de negocio de la empresa, sin embargo la orientacin de los BPMS es
que el propio proceso sea la aplicacin. Los BPMS, adems de cmo entor-
354
no de desarrollo e integracin para aplicaciones orientadas a procesos de

negocio, se estn convirtiendo (mediante la estandarizacin de procesos),
en aplicaciones empresariales per se que ofrecen innumerables ventajas
frente a los entornos tradicionales de desarrollo en cuanto a tiempos de
implementacin, alineacin con objetivos empresariales, flexibilidad, mayor
capacidad de diseo funcional de las aplicaciones, modificacin de las apli-
caciones en tiempo real y donde no es necesario el conocimiento de un
lenguaje de programacin sino de un lenguaje de notacin como BPMN. En
este aspecto del desarrollo software, no debemos confundirnos y creer que
los BPMS son herramientas de desarrollo software, BPM no trata de desa-
rrollo de aplicaciones y su inters es la gestin de procesos de negocio y
para poder gestionar estos, BPM debe apoyarse y alinearse con la tecnolo-
ga, pero no es slo tecnologa y en consecuencia no debemos perder el
foco y saber que debemos centrarnos tambin en la parte de negocio y en
cmo sta har uso de la tecnologa. BPM ayudar a la toma de los reque-
rimientos tecnolgicos y sobre todo nos ayudar tras la implementacin
tecnolgica a medir y evaluar el uso de la misma en nuestros procesos.
El mayor reto que afrontaremos con nuestros proyectos de BPM ser

equilibrar los tres pilares sobre los que se sustentar el proyecto: Personas,
Tecnologa y Procesos y suele ocurrir que normalmente uno de estos siem-
pre sobresale y suele ser el tecnolgico. Los BPMS son en este sentido una
nueva categora de software, una tecnologa implcita a BPM sobre la que
se sustenta la gestin de procesos, que permiten a las organizaciones mo-
delar, implementar y gestionar sus procesos de negocio, que cumplen con
todos los requerimientos de escalabilidad, seguridad, flexibilidad, agilidad,
tolerancia a fallos y calidad de servicio, pero no deben ser vistos como en-
tornos de desarrollo software. As mismo, los BPMS no vienen a reemplazar
los sistemas de informacin existentes en las empresas sino que coordina-
rn estos sistemas para la ejecucin y control de los procesos empresaria-
les.
En BPM, el modelo del proceso se convierte en el ncleo de la imple-

mentacin del proceso como solucin tecnolgica. El modelo del proceso
de negocio (su diseo), que realiza el rea de negocios de una empresa, es
en si lo que se ejecuta sobre el servidor de procesos (el motor de BPM).
Dicho en otras palabras: la lgica de negocio principal que antes bajo la
tecnologa tradicional se deba programar, y colocar sobre un servidor de
aplicaciones (tradicional), ahora se reemplaza por un modelo que se sube
al servidor de procesos con mucho menos intervencin del rea de TI
(menos programacin).
355
En la prctica, una buena solucin de BPM debera poder ejecutar un

proceso modelado por el rea de negocio, sin la necesidad de que el depar-
tamento de TI tenga que programar una sola lnea de cdigo, y obtener
como solucin algo equivalente a un WorkFlow Tradicional (sin integracin
de sistemas). Luego el rea de TI debera tomar este workflow, e imple-
mentarle los formularios de entrada (de interaccin con usuarios), y los
servicios (las actividades automatizadas e integraciones con otros siste-
mas) para completarlo en un flujo BPM.
Como espero que haya quedado claro a lo largo de los captulos anterio-
res, la adquisicin de una plataforma BPMS no implica el implementar un
proyecto BPM y sin una correcta gestin del cambio, metodologa de ges-
tin de proyectos, gestin de personas, liderazgo y alineamiento estratgi-
co de nuestros procesos eficientes y optimizados, pocas son las ventajas
que extraeremos de la implementacin de la herramienta tecnolgica.
En este punto, vuelvo a que es y que no es BPM y repasando todo lo vis-

to con anterioridad, debemos concluir que BPM no es una teora de ges-
tin, no es una herramienta de modelado de procesos, no es una metodo-
loga de gestin de personas, no es un software, no es una metodologa
para la mejora de procesos y sin embargo, es todas ellas en conjunto, vistas
desde una perspectiva holstica.
Bajo los BPMS se producir la convergencia de las teoras de gestin

empresarial y de gestin de procesos con distintas tecnologas software en
una nica plataforma.
Smith y Fingar comparaban los BPMS con los sistemas gestores de bases
de datos (SGBD). Al igual que estos gestionan los datos en bases de datos
externas a las aplicaciones para poder modificar estas sin necesidad de
modificar el modelo de datos y como esto signific un enorme salto en el
desarrollo de las aplicaciones. Un salto de magnitud similar se ha producido
con la separacin de los procesos de negocio de las aplicaciones, para que
356
cualquier cambio en la lgica de los procesos no suponga modificar las apli-

caciones. El uso de los BPMS resultar imprescindible para llevar a cabo
nuestros proyectos de BPM, pero adems de para la gestin y control de
procesos y la integracin con los sistemas existentes en la empresa, con los
BPMS obtendremos un mayor control sobre los sistemas informticos de
nuestra empresa bajo una visin unificada orientada por los procesos, au-
mentando el valor de los sistemas y recursos en la organizacin, reduciendo
los costes operativos, la optimizacin de los costes de TI, mejoras en la ges-
tin de la calidad, produccin, servicio a clientes, gestin de compras, tiem-
pos de procesos, flexibilidad en la adaptacin al cambio y requerimientos
de negocio y reduccin de errores debidos a procesamiento manual de
datos y operaciones. Los BPMS resultan en este sentido en una autntica
revolucin que nos lleva de una orientacin a datos a una orientacin a
procesos y que nos permitir arquitecturas e infraestructuras ms giles y
adaptables a los cambios en los ecosistemas empresariales.
En este captulo analizaremos primero los distintos mdulos que con-

forman las plataformas BPMS para en el siguiente apartado ver las arquitec-
turas orientadas a servicios: SOA (Service Oriented Architecture), como la
arquitectura tecnolgica que nos permitir racionalizar y agilizar este cam-
bio.
Mdulos principales de un BPMS.
Hay bastantes opiniones y no existe un consenso sobre lo que debe o no

debe incluir un BPMS y cada vendedor (Oracle, Microsoft, IBM, SAP, etc.)
ofrece sus particularidades y requisitos, por lo que en este libro describire-
mos las funcionalidades bsicas que consideramos deben contener para
poder realzar el ciclo de vida de los procesos de negocio, considerando la
capacidad de realizar este ciclo como el mnimo exigible a cualquier plata-
forma BPMS, pues en el seguimiento de este ciclo radicar toda la potencia
de los BPMS, al poder analizar, modelar los procesos, efectuar simulaciones
de los mismos, integrar aplicaciones, ejecutar los procesos, medir y monito-
rizar dichas ejecuciones y modificar los procesos ejecutados nuevamente a
travs del modelado para implementar mejoras o modificaciones en los
mismos.
En el captulo anterior sobre la implementacin de BPM hemos dado

bastantes detalles operativos de cmo ser un proyecto de este tipo, y el
357
lector seguramente se habr hecho una idea de cmo debera ser un BPMS,
siguiendo los distintos pasos descritos en la implementacin, por lo que en
este apartado, describir los BPMS y los mdulos que lo conforman cin-
dome a la herramienta software y no a los detalles de su implementacin.
Cada mdulo de un BPMS tiene una funcionalidad y todas las etapas son
importantes para el desarrollo y despliegue de un proceso, por lo que una
de las cosas que debemos exigir a un BPMS como recomendacin es que
cuente con todas las etapas o mdulos necesarios integrados en su suite.
Esto no quiere decir que no podamos realizar por ejemplo el modelado en
una herramienta especfica de modelado y luego trasladarlo a otra suite
para transformar el modelo en cdigo ejecutable o gestionar el proceso, sin
embargo, nuestra recomendacin es la de procurar la integracin de estos
mdulos y funcionalidades en un mismo producto.
Aqu debemos aplicar un pensamiento holstico similar al usado en la es-

trategia de BPM, pero est holstica la aplicamos ahora para integrar todos
los mdulos que componen el BPMS pues es en esta integracin donde
residir la verdadera potencia del BPMS y del proyecto BPM en definitiva.
Al final modelamos procesos para luego simularlos, implementarlos, medir-
los y controlarlos y ninguna de estas actividades por separado tienen la
potencia de las mismas cuando las pensamos, planeamos y ejecutamos de
forma aislada, pues el ciclo de vida de BPM est en continuo movimiento de
una fase a otra: modelando, automatizando, administrando y mejorando las
actividades y procesos de negocio. Con esta recomendacin nos referimos a
la capacidad que debe tener el BPMS de gestionar el ciclo de vida de los
procesos y mantener el contexto de trabajo entre las distintas etapas, pero
no implica que debamos adoptar un paquete cerrado al estilo ERP sobre el
cual no podamos salirnos para aprovechar las posibilidades de las mejores
herramientas especializadas en la gestin de distintas reas de la empresa a
travs de las capacidades de integracin entre las distintas soluciones. De la
misma manera, podremos por ejemplo disear una solucin BPMS inte-
grando la misma en una misma implementacin con una plataforma de
gestin documental como por ejemplo Alfresco, con una herramienta para
la gestin de reglas de negocio y con una herramienta de ETL y Business
Intelligence como Pentaho para el anlisis de datos de nuestros procesos.
Estas combinaciones son perfectamente vlidas e incluso recomendables
para aprovechar la potencia y capacidades de las mejores soluciones del
mercado o aquellas con las que nuestra empresa tenga mayor experiencia
en su manejo.
358
A la hora de seleccionar una plataforma de BPMS podemos establecer

las siguientes recomendaciones:
- Capacidad de cubrir todo el ciclo de vida de los procesos.

- Capacidad de simulacin y optimizacin de los procesos.
- Soporte para SOA.
- Soporte a tareas humanas.
La mayora de BPMS se sustentan en el ciclo de vida de los procesos de

negocio que ya hemos analizado. Atendiendo a este ciclo de vida de Disear
Modelar Ejecutar Monitorizar - Optimizar, mostraremos los diferentes
mdulos con los que cuentan las plataformas BPMS para permitir ejecutar
todas las operaciones del ciclo de vida de los procesos. De forma general,
las acciones y mdulos que utilizaremos en un BPMS son:
- Modelador de Procesos: Donde realizaremos el diseo y mode-

lado de los procesos de negocio, se crean o disean los procesos
o se modifican y mejoran los ya existentes para su optimizacin.
En esta etapa, el principal involucrado corresponde a un perfil
de negocio que generalmente es el Analista de negocio. En el
Modelador podremos validar el proceso y simular el funciona-
miento del mismo tras introducir los datos, roles y reglas de ne-
gocio necesarios para describir su funcionamiento y operativa.
- Entorno de Integracin: donde se integran los componentes ex-
ternos necesarios para la ejecucin del proceso. El principal in-
volucrado aqu corresponde a gente de TI. Dentro del motor de
integracin, tendremos tambin los Motores de Orquestacin
que permiten coordinar la secuencia de actividades segn los
flujos y reglas del modelo de procesos.
- Servidor de Procesos: para el despliegue y ejecucin de los pro-
cesos, donde se ponen a funcionar los procesos diseados y re-
colectamos informacin de los mismos.
- Monitorizacin: donde seguimos y monitorizamos los procesos
para analizar su informacin (indicadores, caminos crticos, cue-
llos de botella, rendimiento, etc.) para poder realizar la evalua-
cin y optimizacin de los procesos.
- Vuelta al primer paso de Diseo (y Re-Diseo) y Modelado de
procesos cerrando el ciclo.
359
Las fases del ciclo de vida no tienen por qu ser ejecutadas en el orden
indicado, sino que estas pueden ser concurrentes y podemos pasar de una
a otra en cualquier momento segn lo necesitemos.
No describir en este libro el uso de ninguna plataforma en concreto,

como venimos diciendo, prcticamente todas permiten realizar el ciclo de
vida de los procesos con ligeras variaciones en la arquitectura de cada
BPMS. En los siguientes apartados describir los distintos mdulos genri-
cos de una plataforma BPMS siguiendo tanto el ciclo de vida de los procesos
como el siguiente ciclo de implementacin directa en una plataforma
BPMS:
1. Modelar el proceso.
2. Introducir datos del proceso.
3. Crear los formularios web de interaccin con personas.
4. Establecer las Reglas de Negocio.
5. Asignar los recursos.
6. Integracin con otros sistemas.
7. Verificar el proceso.
8. Implementar el proceso.
360
Modelador grfico de procesos.
Para modelar el proceso que queremos implementar utilizaremos una

herramienta de modelado, haciendo uso de nuestro conocimiento y habili-
dades en BPMN. Lo ms importante es que antes de trasladar al modelador
el diseo de nuestro proceso, este modelo sea correcto, alineado con los
objetivos de la empresa, que lo hayamos seleccionado como importante
para la organizacin, hayamos trasladado al equipo la importancia de su
implementacin y que ste se encuentre perfectamente optimizado, de
forma que contemos con las mayores probabilidades de xito posibles en
su implementacin dentro de la organizacin.
Para el modelado, dispondremos en la herramienta de modelado de una

paleta con los distintos elementos de BPMN, los cuales iremos trasladando
al diagrama hasta obtener el modelo. Durante este proceso, dispondremos
de ayuda para verificar el correcto modelado en BPMN y utilidades como
drag and drop que nos harn ms rpida la tarea de modelado.
Dentro de la herramienta de modelado, pulsando sobre los distintos

elementos de BPMN de la paleta, podremos especificar los tipos de activi-
dades (automticas, manuales, etc.), eventos (inicio, fin, mensaje, etc.) y
flujos de nuestro modelo as como textos de ayuda y comentarios sobre los
distintos elementos o partes del modelo y que ayudaran al usuario final del
proceso a entender la actividad que est modelando.
Las herramientas de modelado de procesos incluidas en los BPMS nos

permitirn crear descripciones de procesos de negocio ms rpidamente,
comprobar que los modelos sean correctos y consistentes, expresar los
procesos y sus detalles, poder entender los mismos para entender su com-
plejidad y utilizarlos para comunicarnos con el resto del equipo en las dis-
tintas versiones de los modelos.
A partir de la estrategia y objetivos de la organizacin, modelaremos los

eventos, los procesos privados y pblicos, los roles, definiremos las reglas
de negocio, los indicadores para medir el rendimiento y la alineacin de
estos con la estrategia empresarial. El modelador permitir modelar los
procesos a travs del estndar BPMN (Business Process Model Notation) el
cual permite expresar de forma grfica las actividades, eventos y el flujo
que le indicarn al sistema cmo comportarse y como ejecutarse, que pasos
tendr que dar, que decisiones tomar y que hacer en caso de que ocurra
alguna excepcin. Adems podremos sobre la misma herramienta de mo-
361
delado, asociar al modelo la informacin y datos de recursos, tiempos, cos-

tes, mensajes, entradas y salidas de cada proceso, de forma que el BPMS
almacene estos datos y documentacin asociada a los modelos.
Como hemos visto en la estrategia de implementacin de BPM, el mode-

lado lo realizaremos tanto del As-Is (como son nuestros procesos actuales)
como del To-Be, para describir el proceso mejorado, en base a reuniones
con el equipo de proyecto para gradualmente ir modelando el proceso que
estemos tratando en cada momento.
La herramienta de modelado no tiene porque ser un BPMS completo,

existen en el mercado tanto soluciones de pago como open source para
realzar estos modelados, algunas dedicadas en exclusiva a esta operacin
de modelado y otras que forman parte de los BPMS. Herramientas de mo-
delado hay muchas, pero la gran diferencia entre ellas est en las que tiene
orientacin a procesos y las que no. Muchos de los BPMS ms conocidos del
mercado suelen ofrecer de forma gratuita su herramienta de modelado, sin
embargo debemos exigir a estas herramientas un mnimo de funcionalida-
des y caractersticas como son: soporte para BPMN y validez de los modelos
diseados en el mismo, posibilidad de asociar datos a procesos (entradas y
salidas de las actividades, recursos empleados por la actividad, costes, uni-
dades producidas, defectos, etc..), implementacin de reglas de negocio y
capacidad de simulacin de procesos y generacin de cdigo (algunos mo-
deladores soportan UML, de forma que los programadores puedan coger el
modelado y generar el cdigo, pero en general hoy en da a un modelador
le exigiremos capacidad de generar directamente cdigo BPEL). Adems de
estas caractersticas, podemos encontrarnos modeladores orientados a
distintos estndares o metodologas, por ejemplo, con altas capacidades de
anlisis para proyectos ms centrados en Six Sigma o con plantillas especfi-
cas por ejemplo para SCOR, de forma que nos sea mucho ms fcil y rpido
implementar este tipo de procesos y las medidas tpicas asociadas a estos
entornos de implementacin.
En la prctica el modelador de procesos nos va a permitir modificar con

facilidad el flujo, los datos y reglas de negocio de nuestro proceso. Esta
funcionalidad adquiere mayor importancia cuando la vemos desde la fase
de simulacin o ejecucin, cuando nos encontramos en una suite BPMS,
donde a partir de los resultados de una simulacin o por los cambios en los
requerimientos de un proceso, podremos modificar el proceso sobre la
herramienta de modelado, encargndose el BPMS de realizar las modifica-
ciones en los ejecutables, sin necesidad de escribir una sola lnea de cdigo.
362
Esta capacidad junto con la filosofa de gestin subyacente a BPM y el len-

guaje de modelado BPMN, confieren a BPM la posibilidad de unir al perso-
nal de negocio y de TI en el desarrollo conjunto de procesos y poder modifi-
car, de acuerdo a la naturaleza cambiante de los negocios, los procesos y
proyectos que debamos emprender.
La caracterstica principal de las herramientas de modelado es la capaci-

dad de generar aplicaciones software, integrar sistemas, datos y personas
para gestionar y controlar los flujos del proceso y la de poder remodelar
nuestros procesos sin necesidad de reprogramar los aplicativos. Esta pro-
piedad se consigue mediante la transformacin del modelo por parte de las
herramientas de modelado en cdigo BPEL, de forma que nos saltamos la
fase de desarrollo software, transformando el modelado directamente en
cdigo BPEL ejecutable y reduciendo la brecha entre el modelado de proce-
sos de negocio y su implementacin en los BPMS. Este generador de cdigo
ejecutable BPEL a partir del modelado en BPMN, viene a ser como una
herramienta de desarrollo de software de Quinta Generacin (5GL) para el
desarrollo de aplicaciones a muy alto nivel que considera los modelos de
datos, formularios, consultas e integraciones con otras plataformas, para
desarrollar la solucin de software final. Podramos hacernos la pregunta de
si una herramienta de modelado que ejecuta cdigo BPEL pasara el Test de
Touring, de forma que no podamos distinguir si es un programador humano
o la mquina quien realiza el cdigo. Esta capacidad se ver facilitada ade-
ms por la adopcin de una arquitectura tecnolgica como SOA, la cual nos
proporcionar la agilidad necesaria para movernos entre nuestras arquitec-
turas de negocio y tecnolgicas.
Una vez comenzamos a modelar en nuestro entorno grfico en el estn-

dar BPMN, el propio BPMS realiza las tareas de conversin a los lenguajes
de ejecucin. Estos lenguajes son:
- XPDL (XML Process Definition Language) que es la representa-

cin XML del proceso modelado en BPMN y que puede ser usa-
do para intercambiar modelos de procesos entre distintas
herramientas. Tiene sus races en los sistemas de workflow y de
hecho est basado en WPDL (Workflow Process Definition Lan-
guage)
- BPEL es el nombre acortado de BPEL4WS (Business Process Exe-
cution Language for web services). BPEL es un lenguaje de eje-
cucin de procesos de negocio basado en XML desarrollado por
BEA, IBM y Microsoft. BPEL es el lenguaje empleado por el mo-
363
tor de procesos para la ejecucin de los procesos y que opera a

nivel de mquina y surge del XPDL. BPEL est ampliamente di-
fundido y es soportado por la mayora de herramientas como
lenguaje de ejecucin. BPEL est inspirado en XLANG y WSFL y
es un lenguaje centrado en el proceso por lo que no considera
las interfaces humanas y es por ello que se desarroll
BPEL4People (BPEL for People) que es una extensin de IBM y
SAP, propuesta en el ao 2005 y por tanto posterior a muchos
BPMS actualmente en el mercado.
Este modelo es parecido al usado para el desarrollo de aplicaciones in-

formticas en la gestin de datos:
El estndar BPEL est centrado en el proceso (Process-centric) y no en

las tareas del usuario (user-centric), por lo que se propuso la extensin
BPEL4People en el ao 2005. Muchas plataformas BPMS no incluyen esta
364
extensin y en consecuencia para manejar interacciones humanas, cada

plataforma da una serie de extensiones para poder disear y generar inter-
faces humanas en base a formularios web, en las que los usuarios puedan
introducir datos y acciones, interaccionar con otros usuarios y aplicativos
integrados en el proceso.
Con los modeladores usados por los BPMS, podemos no slo modelar
diagramas de comportamiento y procesos de nuestra organizacin, como lo
hacamos antes, sino que podemos aadirles informacin, para luego a
travs de BPEL, ser ejecutados. Esta informacin se refiere a costos, des-
cripciones de los procesos y actividades, tiempos, roles de usuarios, formu-
larios, tareas automatizadas o humanas y reglas de negocio que nos permi-
tirn adems simular el comportamiento de los procesos previamente a su
implementacin.
Datos del proceso:
Continuando dentro de la herramienta de modelado, introduciremos los

datos requeridos por nuestro proceso. Esta es probablemente la tarea ms
ardua y laboriosa que realizaremos en el BPMS y dependiendo del tamao
del proceso, su complejidad, y del nmero de variables y datos asociados al
mismo, es la que consumir ms tiempo en la especificacin del mismo.
Entre las propiedades que podemos especificar (normalmente pulsando

el botn derecho del ratn sobre una actividad) tenemos entre otras: el
nombre del proceso, la descripcin, el coste y la duracin, para las cuales
introduciremos los datos asociados a los distintos elementos de nuestro
proceso.
Pulsando sobre las propiedades de las actividades de nuestro modelo,

podemos completar los datos de cada actividad, as como crear nuevos
atributos personalizados para el mismo y de esta forma, adems de los
datos genricos como coste y duracin de la actividad, podremos disear
nuestros propios tipos de datos como longitud, fechas, unidades vendidas y
aquellos especficos de las actividades de nuestro proceso, indicando para
cada uno de estos nuevos atributos el tipo de que se trata (Integer, String,
Date, etc.).
365
Para ayudarnos en este proceso, en algunos BPMS contaremos con un

modelador de datos, que es una representacin grfica del modelo entidad-
relacin, sobre la que podremos trabajar todos estos datos de forma visual.
Ejemplo de Lista de Atributos:

Nombre Visual Nombre Tipo
Factura Factura Archivo
Importe Importe Moneda
N Factura N Factura Nmero
Fecha Factura Fecha Fecha
Pagada? Pagada Booleano (Si-No)
Creacin de los formularios web:
Estos sern los formularios a travs de las cuales los usuarios que parti-
cipen en el proceso interactuarn con el mismo, registrando la informacin
necesaria para la ejecucin del proceso y visualizando los datos que puedan
necesitar para poder ejecutar las tareas que se le soliciten.
Durante el flujo de nuestros procesos, necesitaremos en muchas ocasio-

nes involucrar a personas en las actividades del mismo, por lo que haremos
uso de los formularios web para interactuar con estas personas. Estas inter-
venciones de personas en el proceso sern generalmente lanzadas por al-
gn tipo de alerta o notificacin que apunten a las tareas o actividades que
cada usuario deba realizar.
Para ayudarnos con este paso, los BPMS cuentan con un modelador de
formularios, en el cual podremos disear los formularios asociados a las
actividades que hayamos especificado como manuales. En el modelador de
formularios, encontraremos una paleta con los distintos elementos que
pueden formar parte de un formulario y los distintos atributos del modelo
de datos para de forma grfica, ir componiendo y asociando el formulario
con los atributos y especificar cada uno de los campos: requerido, editable
y visible, as como sus valores por defecto.
Editor de Reglas de Negocio:
Las reglas de negocio que representan la lgica en la toma de decisiones

del proceso, se definen a travs del motor de reglas en la etapa de mode-
lado. Este editor es una herramienta grfica que nos permite disear las
366
reglas de negocio que regirn el funcionamiento del proceso, de forma que

este pueda funcionar de forma distinta segn el valor de las variables de
entorno.
Estas reglas las podremos establecer en los rombos de decisin de

BPMN de nuestro modelo o en los flujos de secuencia, para verificar que se
cumple una condicin especfica y que devolvern valores de verdadero o
falso. Sobre la herramienta de modelado y pulsando sobre una compuerta
de decisin o flujo de secuencia, nos llevar a un editor de reglas de nego-
cio, donde podremos establecer las condiciones de verdadero o falso y las
expresiones booleanas asociadas a las reglas que establezcamos para nues-
tro flujo de proceso.
En el editor de reglas de negocio, adems de poder editar las reglas so-

bre las condiciones y flujos del proceso, tambin podremos establecer con-
diciones, validaciones y normas que deben seguir las actividades del mismo
mediante la asignacin de acciones al entrar o salir de las actividades y
de esta forma controlar el flujo del proceso y acciones relacionadas.
Aunque las herramientas de modelado permitan hacerlo, no es reco-

mendable modelar las reglas de negocio en el flujo de proceso, sino que es
ms recomendable identificar donde se utilizarn estas reglas y gestionarlas
en las herramientas especficas para reglas de negocio. Los BPMS incluyen
sofisticadas herramientas para la gestin de estas reglas como parte de sus
sistemas, permitiendo de esta manera la automatizacin de los procesos de
negocio. Algunos editores de reglas de negocio, en lugar de este entorno
grfico, ofrecen un entorno de programacin para la especificacin de estas
reglas y casi todos los BPMS disponen de hojas de clculo para el estableci-
miento y definicin de las mismas la cuales pueden ser de dos tipos:
- Reglas de flujo: decisiones automticas basadas en opciones del

proceso (si el pedido es superior a 3.000 entonces un gestor
debe aprobar el pedido).
- Reglas de negocio: independientes del proceso (hacemos un
descuento del 5% cuando el total de pedidos sea superior a
5.000 ).
367
Asignacin de recursos:
Esta es una fase muy importante donde definiremos y asignaremos los

recursos humanos responsables de la realizacin de cada uno de las activi-
dades as como otro tipo de recursos necesarios para la ejecucin del pro-
ceso. Para esta asignacin de recursos, los BPMS cuentan con una herra-
mienta especfica para ello a travs de la cual seleccionaremos la actividad y
asignaremos o crearemos nuevos recursos utilizados por el proceso.
Entorno de Integracin. (Integration Developer)
Los procesos rara vez operan aislados o parten de la nada, sino que ms
bien, estos deben integrarse con los sistemas existentes en los que recalan
los repositorios de datos e informacin necesaria para poder ejecutar los
procesos. Los procesos de negocio no se limitarn al modelado que reali-
cemos y generalmente, muchas partes de estos procesos se encontrarn en
aplicativos que ya existen dentro la empresa como los ERP, CRM, SCM y
otras aplicaciones informticas. Otras veces, estas partes de los procesos,
de su lgica, datos o informacin, se encontrarn dentro de capas de in-
termediacin o middleware.
Cuando en el modelado del proceso definimos una actividad como au-

tomtica, es con el motor de integracin de los BPMS con lo que provee-
mos de los datos necesarios para el funcionamiento del proceso e indica-
remos a qu sistema o base de datos deben conectarse las actividades in-
cluidas en el mismo para obtener dichos datos y poder ser ejecutadas.
Los BPMS recogen toda la evolucin de los sistemas EAI y Middelware

para proveer de mecanismos y herramientas para integrar con todo tipo de
aplicaciones empresariales existentes en la empresa o fuera de ella, invo-
cando a aplicaciones y bases de datos cuando as lo requiera el proceso
descrito en la herramienta de modelado. Entre las utilidades de integracin
de los procesos con las aplicaciones tendremos web services, conexiones
ODBC y JDBC, APIs, libreras, etc. aunque como veremos al final de este
captulo, esta integracin ser mucho ms gil y efectiva haciendo uso de
arquitecturas SOA, al permitirnos estas reutilizar componentes de software
distribuidos en mltiples aplicaciones para armar y modificar los procesos,
de manera que la integracin de aplicaciones se vuelva casi transparente y
mucho ms reutilizable.
368
Todo BPMS necesita gestionar las integraciones con aplicativos externos

asociados al proceso. Casi todos los BPMS comerciales basan su motor de
integracin en sistemas middleware como el Java Server de IBM, WebSp-
here o BizTalk de Microsoft. Adems prcticamente todos los ERP y siste-
mas CRM ofrecen APIs en sus programas para poder conectarse con ellos
como el NetWeaver de SAP para el acceso a los mdulos de SAP.
Recurriendo al mdulo de integracin de nuestro BPMS, se nos presen-

tarn las tareas indicadas como automticas para que podamos establecer
las integraciones necesarias de estas actividades, mostrndonos en una
interfaz las tablas del modelo de datos de la actividad seleccionada y la de
los datos del servicio web o aplicativo al que nos conectemos para que rea-
licemos la configuracin entre ambas y donde podremos tambin definir
qu hacer en caso de error o falta de comunicacin como pueda ser el lan-
zamiento de una excepcin.
Podemos clasificar los procesos en funcin del tipo de interaccin en:
- Sistema a Sistema: entre aplicativos y orgenes de datos. Son los

ms comunes y establecen su comunicacin a travs de mensa-
jes, conectores de bases de datos, APIs de las aplicaciones o
web services. En este ltimo caso de los web services, dispo-
nemos de la capacidad de llamar a servicios web externos u
ofrecer las funcionalidades a sistemas externos a travs de los
mismos. Los BPMS aunque permiten la integracin con orgenes
de datos (ODBC, JDBC, etc.), vienen orientados hacia la integra-
cin con aplicaciones, las cuales resultan mucho ms seguras y
trasladan la lgica de las aplicaciones a las integraciones.
- Persona a Persona: son las ms complicadas, en ellas varias per-
sonas colaboran en una transaccin.
- Persona a Sistema: de personas que crean transacciones sobre
aplicativos, en ellos, una persona desde una interfaz web pro-
voca una transaccin sobre un aplicativo como por ejemplo un
ERP.
Como vemos, con estas tres posibilidades de integracin, los motores de

integracin nos permitirn coordinar la secuencia de actividades segn los
flujos y reglas establecidas en el modelo, manejando simultneamente in-
tegraciones de sistemas informticos y humanos. En las integraciones Sis-
tema a Sistema haremos uso de las herramientas de integracin proporcio-
nadas por los propios BPMS. Para las integraciones Persona a Persona y
369
Persona a Sistema, los BPMS utilizarn herramientas de creacin de formu-

larios web, a travs de los cuales los usuarios introducen sus datos o deci-
siones que son integradas directamente en los procesos o en otros siste-
mas.
Para la integracin con sistemas externos, el motor de integracin debe

adems de proveer de capacidades de transformacin de datos que en
muchas ocasiones son herramientas ETL (de extraccin, transformacin y
carga de datos: Extract, Transformation, Load, en ingls) utilizados por mu-
chos aplicativos, cuadros de mando y sistemas de business intelligence para
proveerse de datos de otros sistemas, extraer sus orgenes de datos, reali-
zar las transformaciones necesarias sobre estos datos y la carga de los mis-
mos ya transformados al sistema que har uso de ellos, siendo en muchas
ocasiones los BPMS utilizados para integrar informacin empresarial disper-
sa en distintos sistemas empresariales.
Para la ejecucin de estas tareas de integracin, los motores de integra-

cin de los BPMS cuentan para ello con todas las APIs y protocolos de co-
municacin, estndares, drivers para bases de datos, procedimientos de
llamada remota, workflow y mensajera, para que los BPMS interoperen y
se comuniquen entre ellos y con otras aplicaciones. En este sentido, se
puede integrar prcticamente con cualquier tipo de aplicativo o base de
datos externa, invocar servicios web externos o que otros sistemas invo-
quen servicios web del BPMS, integrar con servidores de correo electrnico,
plataforma de gestin de contenidos (ECM), ERPs, CRMs, etc. As por
ejemplo podemos tener en un proceso una actividad especificada en el
modelado como automtica que contenga distintos conectores. Por ejem-
plo, supongamos un proceso para la gestin de incidencias por parte de
clientes. Dentro de nuestro proceso podemos conectar este con un CRM
para registrar y/o obtener los datos del cliente, podemos registrar el inci-
dente con una plataforma de gestin documental, podremos tambin co-
nectar el proceso con una plataforma de Business Intelligence para recoger
los datos del proceso y enlazar la misma con un motor de reglas de negocio
que puedan ser consumidas por el proceso en forma de web service ex-
puesto. Estas conectividades tpicas con estas plataformas en entornos
reales, podemos hacerlas usando los conectores nativos de las plataformas
BPMS o desarrollar nuestros propios conectores por ejemplo con en Java
con NetBeans para crear nuestros propios web services.
370
Coreografa y orquestacin:
Existen dos marcos sobre los que pueden trabajar las empresas para la
combinacin de servicios entre distintos participantes y que se realizan,
como hemos visto en BPMN, exclusivamente a travs de mensajes entre los
procesos. Estas dos formas de interaccin son la Coreografa y la Orquesta-
cin.
En la orquestacin, un conductor le dice al resto qu tiene que hacer y

se asegura de que estos lo hagan, es decir, un conjunto de servicios son
coordinados por otro que controla las interacciones, de modo que los coor-
dinados no tienen conocimiento de que forman parte del sistema. En este
caso, una empresa impone los sistemas de informacin y tecnologas que
sern utilizados para llevar a cabo el proceso, esta empresa posee el BPMS
que controla todo el proceso y hace uso de los sistemas de las dems.
La coreografa es la interaccin de dos o ms procesos de negocio e indi-

ca la ausencia de un agente central que controle las actividades. La coreo-
grafa define slo las interacciones entre los participantes y no como cada
uno de estos realiza sus actividades internamente. Son como bailarines que
deben ponerse de acuerdo en una coreografa comn: durante el baile cada
bailarn realiza su danza, pero en determinados puntos, debe ponerse de
acuerdo con otros bailarines. En la coreografa, cada participante juega su
papel de forma independiente en un plan predefinido, no existe un coordi-
nador centralizado, sino que cada servicio colabora con el resto y conoce
con quien puede interactuar. En este caso, en vez de un nico coordinador,
cada empresa dispone de su propio BPMS y colaboran conjuntamente en
un proceso.
Servidor de procesos.
El servidor o motor de procesos es el corazn de los BPMS y es el encar-

gado de interpretar el cdigo BPEL en tiempo real y automatizar los proce-
sos modelados. Este servidor de procesos es el que hace que se mueva todo
el engranaje: dirigir a los usuarios que participan en las diferentes activida-
des, gestionar el estado de los procesos y los datos asociados a estos, con-
trolan las integraciones internas y externas que participan en el proceso, la
lgica diseada en el flujo del modelado y los puntos de intervencin de los
371
usuarios y sistemas, permitiendo no slo ejecutar sino tambin poder reali-

zar cambios en tiempo de ejecucin o controlar las versiones del proceso.
El servidor de procesos recibe la definicin del proceso en cdigo BPEL

(generado por el modelador, que transforma la notacin en lenguaje ejecu-
table) y ejecuta instancias del proceso como una serie de pasos indicados
en el modelo.
El servidor de procesos nos permite monitorizar de forma dinmica el

estado de los procesos a travs de herramientas visuales (generalmente
sobre el propio diagrama visual en BPMN) que nos muestran las actividades
en ejecucin y permite acciones tpicas como el arranque, parada y elimina-
cin de actividades y procesos.
El motor de procesos, siguiendo el diseo del proceso desarrollado en el

modelador de procesos y transformado por este motor al lenguaje BPEL,
ejecuta el modelo de acuerdo al flujo especificado, identificando entradas,
salidas, roles de participantes, datos y servicios software, integrando a per-
sonas, datos y servicios, para lograr la ejecucin de cada proceso.
Es necesario antes de realizar el despliegue de nuestro modelo en el ser-

vidor de procesos, que dispongamos del diseo y estructura de los frontales
web, tanto los que usaremos para interaccin con humanos como con ser-
vicios externos, web services o aplicativos con los que nos vayamos a co-
nectar. Como comentbamos al hablar de BPEL, antes de la aparicin de
BPEL for People, los fabricantes de BPMS desarrollaron sus propias exten-
siones para suplir la falta de orientacin a humanos en el lenguaje BPEL, por
372
lo que en algunos BPMS, los formularios para interaccin con humanos se

despliegan como web services y en otros como XForm o simples formula-
rios.
El Motor de Procesos gestiona y coordina tres tipos de motores:
- Motor de Flujo de Procesos: que gestiona el flujo de ejecucin

segn el diseo del proceso.
- Motor de Integracin: el cual gestiona y coordina las aplicacio-
nes necesarias para la ejecucin del proceso y gestiona los da-
tos asociados a estas integraciones.
- Motor de Reglas de Negocio: para la gestin y mantenimiento
de las reglas de negocios descritas en el diseo.
Dentro del servidor de procesos dispondremos tambin de un adminis-

trador de usuarios con capacidades de integracin con DA y LDAP para ad-
ministrar los usuarios y sus relaciones funcionales.
Prcticamente todos los BPMS del mercado operan sobre una arquitec-
tura web como la mostrada en el siguiente grfico:
Las interacciones con usuarios son a travs de frontales web desde cual-
quier dispositivo con acceso a internet y la plataforma BPM le proporciona-
r todos los datos y la informacin necesaria para poder completar sus ta-
reas. Al ser internet un medio pasivo, para poder continuar un proceso,
muchas veces se requerir de la accin de una persona para que el proceso
373
pueda continuar, por lo que se hace uso de la mensajera para avi-

sar/alertar a esa personas sobre la accin que debe tomar, de forma que
ser el diseo de los procesos de negocio quien dirigir el motor de proce-
sos. En BPM se parte de la consideracin de que la informacin debe buscar
al actor para que este responda y se pueda continuar el flujo del proceso y
no que los actores reporten datos al sistema para que algo ocurra. Dentro
de estos flujos del proceso, disponemos tambin de mecanismos para la
asignacin de tareas por parte de una persona a otra persona o la de con-
sulta para que esa persona pueda consultar a otra sobre qu accin tomar y
el servidor web enve los mensajes de interaccin con los clientes al servi-
dor BPMS.
El servidor de procesos del BPMS tiene acceso a una base de datos pro-
pia o repositorio donde almacena datos de ejecucin de los procesos, man-
tiene los componentes y recursos de los procesos (definiciones, modelos,
reglas, etc.) y permite su disponibilidad para ser reutilizados en otros proce-
sos, al tiempo que se comunica con aplicativos y bases de datos externas
(ERP, CRM, etc.) para poder ejecutar la monitorizacin y anlisis de proce-
sos.
Como es de esperar, estos motores de los BPMS, son los que ms recur-
sos hardware consumen, en especial si los comparamos con las suites de
workflow. Esto es as principalmente por el motor de integracin, por lo que
cuando ejecutemos estos motores necesitaremos de grandes servidores
capaces de correr estos motores de procesos.
Ejecucin del proceso.

Finalmente, una vez modelado el proceso, introducidos los datos asocia-
dos al mismo, las reglas de negocio, los recursos y realizadas las integracio-
nes necesarias, estaremos en disposicin de ejecutar el proceso, el cual
podremos ejecutar en un entorno de pruebas y desarrollo o directamente
en un entorno de produccin. La ejecucin del proceso se presentar en
casi todas las plataformas en un entorno web, a travs del cual tanto los
administradores como los usuarios del proceso podrn interactuar con el
mismo. La ejecucin del proceso se realizar sobre la mquina en la que
hayamos diseado y configurado el proceso, aunque podremos indicar
otras localizaciones geogrficas para el servidor de procesos y trabajar re-
motamente.
374
Simulacin.
Los procesos generalmente no son deterministas, en el sentido de repe-

tir siempre los mismos comportamientos, sino que ms bien sern del tipo
estocstico, es decir, tienen cierto grado de incertidumbre, pues al repetir
la simulacin con los mismos datos iniciales varias veces, los resultados no
son siempre los mismos y es por ello que esta funcionalidad de simulacin
como hemos visto en el captulo anterior, es fundamental en BPM a la hora
de permitir simular procesos, de forma que podamos estudiar diferentes
alternativas para nuestros procesos, predecir su comportamiento, fallos,
cuellos de botella y posibilidades de mejora para evaluar y dar respuesta a
situaciones y escenarios antes de su implementacin, obtener explicacio-
nes, tomar decisiones y comprobar cmo se comportarn los procesos bajo
diferentes situaciones. Debemos recordar que los BPMS tuvieron su origen
en los sistemas de workflow, estos sistemas aparecidos en los aos 80 para
la automatizacin de actividades, evolucionaron hacia los actuales BPMS
por su capacidad de realizar anlisis tanto cuantitativos como cualitativos
de los datos del proceso, as como de integrar en los procesos otras aplica-
ciones.
Por lo fundamental que es para los proyectos de BPM y la potencia que

ofrecen estos simuladores, todos los BPMS incorporan o deberan incorpo-
rar esta funcionalidad de forma tal que sobre la misma herramienta de
modelado podamos simular la ejecucin y rendimiento de los procesos
modelados, variando los escenarios, los recursos, costes, tiempos etc. para
la optimizacin del proceso en funcin de los distintos parmetros y simular
un cambio en cualquier parmetro que deseemos y obtener informacin
sobre el comportamiento del proceso para decidir si cambiar o no el mismo.
Puesto que la simulacin (o Debug, como se denomina en algunos BPMS)
puede involucrar a un gran nmero de personas, agentes y sistemas infor-
mticos especificados en nuestros procesos, algunos BPMS permiten el
detener la ejecucin de los componentes que especifiquemos durante la
simulacin con objeto de no tenerlos en cuenta durante la simulacin si
todava no tenemos activados a estos agentes o por cualquier motivo, no
deseamos incluirlos en este anlisis.
En los BPMS, una vez que se introducen los datos, la simulacin produce
aleatoriedad en el modelo del proceso, ejecutando el mismo varias veces y
por diferentes caminos del flujo diseado y realizando los clculos asocia-
dos al proceso. Esta simulacin incluye el clculo de probabilidades, funcio-
nes de simulacin, de distribuciones, anlisis estadstico, clculo de tiempos
375
y recursos utilizados por las diferentes actividades del proceso, proporcio-

nndonos informes de posibles problemas, cuellos de botella, impacto y
debilidades que tengamos en el proceso diseado (tiempos de ciclos de
proceso, tiempos de espera, costes, etc.), para que podamos volver al mo-
delo y corregir estos errores.
Hay dos principales tipos de simulacin:
- Simulacin continua: donde el estado cambia a lo largo del

tiempo del proceso.
- Simulacin discreta: donde los estados del proceso no cambian
a largo del tiempo sino a travs de eventos.
Muchos BPMS permiten identificar las variaciones en los procesos au-

tomticamente as como buscar soluciones a estas variaciones y compor-
tamientos de los procesos. Una vez ponemos nuestros procesos en marcha
en la simulacin, el BPMS nos proporcionar informacin de los datos cap-
turados en los procesos, mostrndonos las discrepancias entre los datos
obtenidos y los deseados, sin embargo, no debemos olvidar que la optimi-
zacin es una tarea de las personas de negocio, ningn sistema puede to-
mar ciertas decisiones sino que debe ayudarnos a la toma decisiones y a
cmo mejorar nuestros procesos, respondiendo a preguntas del tipo:
- Cmo mejorar la eficiencia de nuestros procesos?

- Cmo identificar cual de las posibles variantes de un proceso
ser mejor para alcanzar los resultados deseados?
- Cmo predecir los requerimientos de recursos que vamos a
tener en distintos escenarios?
- Dnde estn los cuellos de botella que afectan a la experiencia
de nuestros clientes?
- Cmo podemos maximizar los beneficios?
A estas preguntas responderemos con ayuda de la herramienta de simu-

lacin analizando el comportamiento dinmico de los procesos, repitiendo
muchas veces los procesos sobre distintos escenarios, probando los To-Be y
evaluando la eficiencia de los mismos antes de incurrir en el coste y el ries-
go de implementarlos sin haberlos simulado y sin haber predecido su com-
portamiento, simulando los procesos muchas veces con diferentes datos,
testeando diferentes niveles y volmenes de carga de trabajo y ajustando
los recursos y tareas para medir los resultados, estimar costes y tiempos y
definir escenarios (inicio, fin, calendarios de trabajo, coste de los recursos,
376
duracin de las actividades, etc.), es decir, como decamos al hablar de in-

novacin: chatarreando con nuestros procesos.
Monitorizacin de procesos.
Generalmente vemos como los sistemas y aplicativos informticos no

evolucionan segn los requerimientos de negocio y de mercado por la difi-
cultad y el costo humano y monetario que implica el realizar cambios sobre
algo que ya funciona, por lo que nos adaptamos a la herramienta infor-
mtica o simplemente no monitorizamos el resultado de los procesos, pues
de antemano, sabemos que no vamos a realizar cambios. En cierta manera
podemos decir que los BPMS han venido para permitirnos salir de este agu-
jero, dando un giro de 180 grados a la forma en la que pensamos sobre
nuestros procesos de negocio y los sistemas de TI que los soportan.
El valor ms obvio de los sistemas BPMS es la monitorizacin en tiempo

real de las actividades del proceso y de los aplicativos externos integrados
con el mismo, visualizando los datos e indicadores de nuestros procesos de
forma que podamos mejorar la visibilidad de los mismos, el control de las
operaciones y la ejecucin de sus actividades en busca de ineficiencias y
cuellos de botella que puedan empeorar el servicio a clientes y el propio
negocio.
En la monitorizacin, los BPMS se comportan de forma similar a los sis-

temas SPC (Statistical Process Control) utilizados en las plantas de produc-
cin para proporcionar datos e informacin de lo que acontece en la opera-
tiva de los procesos productivos para ser analizada. En los BPMS dispone-
mos de distintas herramientas para el anlisis de negocio como los BAM
(Business Activity Monitoring), incluidos en la mayora de plataformas de
BPMS o herramientas de BI (Business Intelligence) y de Cuadro de Mando,
pero independientemente del punto de vista que definamos para medir o
de las herramientas que usemos para visualizar las medidas, el aspecto ms
importante es la capacidad de monitorizar el proceso y ver que su compor-
tamiento se ajusta a lo planeado para el mismo, as como la agilidad para
poder responder a los cambios observados, disponiendo de una herramien-
ta que nos permita tomar las mejores decisiones para la modificacin y
mejoras que exijan los procesos y poder implementarlas en la herramienta
377
de modelado de forma rpida, sin necesidad de lanzar grandes proyectos

de TI para su modificacin.
BAM (Business Activity Monitoring) es un trmino acuado por Gartner

Group que proporciona el seguimiento en tiempo real de las actividades del
proceso, los indicadores de negocio (KPIs) y los SLAs (Service Leve Agree-
ment), pudiendo adems definir alertas de acuerdo a eventos que sucedan
en el proceso de negocio o medidas del resultado del proceso que establez-
camos. Estos mdulos son muy parecidos a cuadros de mando personaliza-
dos que nos muestran el comportamiento de los procesos y sus informes
asociados derivados del monitoreo del proceso (BAM).
Un proceso diseado bajo el estndar BPMN y convertido en ejecutable

a travs de BPEL con una Suite BPMS, puede proveer de informacin en
tiempo real de la ejecucin del proceso, lo que permite una Monitorizacin
de las Actividades de Negocio (BAM, por sus siglas en ingls) por lo que los
datos estarn disponibles a partir de la informacin histrica del proceso.
Esta informacin puede venir de mtricas de calidad, Six Sigma y otros da-
tos de monitorizacin del proceso: tiempos de proceso o de etapas del
mismo, aprobaciones, capacidades del proceso, defectos, grficos de Pare-
to, etc. que vimos en las herramientas de anlisis de procesos en el Captulo
1.
Generalmente los monitores de procesos incluyen herramientas de an-

lisis as como de generacin de documentacin e informes sobre los proce-
sos. Los anlisis se realizan a partir de datos histricos almacenados en la
base de datos del servidor de procesos, para la identificacin de patrones
de comportamiento que permitan predecir resultados y mejoras en el fun-
cionamiento de los procesos. Generalmente este anlisis se realiza con
herramientas de BI (Business Intelligence) que permiten ver los datos hist-
ricos y los KPI agrupados para analizarlos en profundidad, cuadros de man-
do, hojas de Excel y todo tipo de grficas a partir de los indicadores y mtri-
cas definidas para el proceso.
Las capacidades de monitorizacin de datos de procesos son todava hoy

muy limitadas para la mayora de plataformas BPMS, limitndose esta mo-
nitorizacin a informacin relativa a las actividades del proceso. Para obte-
ner sistemas de monitorizacin de negocio ms potentes, necesitaremos
combinar la informacin de estos procesos con otras fuentes de datos,
adems de los histricos de datos, para poder desarrollar capacidades de
anlisis y prediccin sobre la monitorizacin, por lo que necesitaremos de
378
sistemas como los Data Mining, de cuadro de mando o Business Intelligen-

ce, que si bien todava no han sido implementadas en la mayora de las
plataformas BPMS, la evolucin de las mismas parece ir en este sentido, en
la medida que la mayor parte de los fabricantes que ya disponen de suites
de Business Intelligence y Cuadro de Mando como IBM, Microsoft u Oracle
estn procediendo a la integracin de stas con plataformas de BPMS.
Aunque algunas plataformas BPMS disponen ya de soluciones BPM

completamente integradas con herramientas avanzadas de monitoreo co-
mo Cuadros de Mando y Business Intelligence, en general, en todas las pla-
taformas disponemos de herramientas suficientes para monitorizar los pro-
cesos desplegados y ejecutados por el servidor de procesos, as como
herramientas visuales para la interpretacin de los resultados tanto a nive-
les altos de la empresa o niveles ejecutivos para analizar por ejemplo el
nmero de transacciones realizadas, tiempos de ejecucin y respuesta,
errores producidos, etc. as como en niveles ms bajos y operativos, por
ejemplo, para los departamentos de ventas, produccin o TI, interesados en
observar el comportamiento de los procesos y actividades a estos niveles.
Como vemos los plataforma BPMS nos permiten tanto el modelado, la

carga de datos y reglas de negocio, la integracin con los sistemas de la
empresa y la monitorizacin de los procesos, pudiendo adems ser utiliza-
dos conjuntamente con herramientas de ETL para la integracin de datos
dispersos de la empresa que puedan participar tambin en el monitoreo y
el anlisis de los datos. De esta forma los BPMS permiten realizar comple-
tamente el ciclo de vida de los procesos as como realizar automticamente
el ciclo DMIAC para la mejora de procesos que vimos al hablar de Six Sigma,
generando la documentacin de los resultados del estudio y de hecho los
BPMS son una herramienta ideal para realizar estos ciclos DMIAC de Six
Sigma, al ser estos en s mismos un proceso que puede ser implementado
en los BPMS, los cuales, adems nos facilitan la tarea de recogida de datos
gracias al uso de las herramientas de integracin y ETL con que cuentan los
BPMS.
Arquitectura tecnolgica. BPM y SOA.
La optimizacin de procesos es slo la mitad de la batalla de nuestro

proyecto, la otra parte corresponder a la implementacin del BPMS y en
especial a la parte de las integraciones con sistemas y aplicativos internos y
379
externos de nuestra empresa (ERP, CRM, conectividad con partners y pro-

veedores, etc.) y sern en estas tareas de integracin donde ms recursos
de TI y tiempo necesitaremos para implementar los BPMS y la solucin
BPM.
Como venimos comentando, debemos considerar la combinacin de

BPM como disciplina de gestin de procesos de negocio como mtodo para
modelar la realidad de las organizaciones junto con SOA (Service Oriented
Architecture o Arquitectura Orientada a Servicios) como la orientacin tec-
nolgica a servicios y como forma de integrar de forma flexible y adaptable
las aplicaciones, al ser muchas veces el entorno en el que se desarrollan y
operan los procesos de negocio complejos en cuanto a la integracin de
datos y aplicaciones. SOA es una arquitectura tecnolgica para el desarrollo
e integracin de sistemas, basada en composicin y orquestacin de servi-
cios independientes, para alcanzar agilidad, flexibilidad y reutilizacin en
nuestras implementaciones y en especial por la simplificacin que nos apor-
ta SOA en la gestin del cambio. SOA nos permitir disear, construir, des-
plegar e integrar los servicios independientemente del lenguaje en que
estn programados y de las plataformas sobre los que estos servicios se
ejecuten, de forma que podremos vincular los servicios entre s a travs de
los procesos de negocio para realizar las funciones empresariales.
La sinergia entre BPM y SOA es tal que aunque dependiendo de la en-

vergadura del proyecto y su complejidad, en especial en lo relativo a la in-
tegracin con sistemas y aplicativos, es impracticable hoy en da en un eco-
sistema de software moderno, desarrollar un proyecto de BPM sin una ar-
quitectura SOA.
La arquitectura orientada a servicios SOA es un concepto de arquitectura

de software que define la utilizacin de servicios para dar soporte a los
requisitos del negocio para permitir la creacin de sistemas de informacin
altamente escalables que reflejan el negocio de la organizacin de forma
bien definida, mediante la exposicin e invocacin de servicios web, lo cual
facilita enormemente la interaccin entre diferentes sistemas propios o de
terceros. Sin embargo no debemos pensar que SOA son web services. Lo
que SOA hace es definir un modelo para la ejecucin de un determinado
proceso, que podemos construir a travs de web services o de alguna otra
manera, pero no slo con web services, aunque con ellos nos resulte ms
sencillo adaptar los sistemas a los cambios en los procesos y los negocios y
sea esta la razn por la que son utilizados en casi todas las implementacio-
nes SOA.
380
Lo que SOA nos va a permitir es la abstraccin de los procesos, de forma

que podamos trabajar directamente sobre los procesos en un entorno de
negocio en lugar de tener que hacerlo considerando tambin los aspectos
tecnolgicos.
Como arquitectura software, SOA viene a resolver muchos de los pro-

blemas comentados en el Captulo 3 en relacin a la integracin de datos y
sistemas y la complejidad en estas integraciones en un entorno de mercado
cada vez ms interconectado. La idea principal de SOA es capturar las fun-
cionalidades ms relevantes del negocio a travs de interfaces bien defini-
dos, a travs de web services, encapsulando la funcionalidad existente en
las aplicaciones en servicios, es decir, ocultando la lgica de negocio y pro-
veyendo slo los datos o funcionalidades para los que fueron diseados los
web services, de forma que puedan ser usados para la comunicacin e inte-
gracin con otros sistemas y usuarios, interactuando proveedores y consu-
midores de servicios de forma desacoplada para realizar procesos de nego-
cio.
Como vimos en la evolucin de las herramientas tecnolgicas hasta lle-

gar a BPM en el Captulo 3, de la necesidad de integrar aplicativos departa-
mentales sin conectividad de datos entre ellos, surgieron las plataformas
EAI y el desarrollo de los Middleware. Con el avance de internet y especial-
381
mente de los protocolos de comunicacin asociados a esta tecnologa (XML,

SOAP, UDDI y WSDL), surgieron nuevas posibilidades de integracin de da-
tos y aplicaciones que ahora s podan comunicarse por la web. Este desa-
rrollo ha ido evolucionado y estandarizndose hasta llegar a SOA, basado en
estndares de interoperabilidad e independientes de la tecnologa utilizada
y que racionalizan no slo las infraestructuras informticas mediante una
orientacin a servicios, sino que permite a los negocios la realizacin de una
idea que ha sobrevolado todo este libro como es el poder de tomar decisio-
nes de negocios apoyadas en tecnologa y no determinas por las limitacio-
nes o restricciones de esta. Ganar en agilidad y capacidad de respuesta de
las TI a las necesidades de negocio escapando de la esclavitud y obsoles-
cencia de diferentes soluciones sobre diferentes plataformas, repletas de
parches para suplir una mala arquitectura de interoperabilidad e informa-
cin redundante y que resultaba tan costosa en su mantenimiento que los
departamentos de TI preferan empezar algo de cero que intentar entender
o arreglar las partes ya desarrolladas.
Pero para poder implementar SOA, lo primero que deberemos hacer es

determinar que sistemas vamos a exponer. SOA viene a ser una evolucin
de las APIs que usamos para la integracin entre aplicaciones pero basn-
dose en los web services para su despliegue. Un web service o servicio es
un componente software que puede ser invocado remotamente y que se
describen a travs de un archivo WSDL (Web Services Definition Language).
Para invocar estos servicios se usa el protocolo SOAP (Simple Object Access
Protocol) como protocolo de comunicacin y sistema de mensajera entre
web services, el cual es un documento XML para transportar los parmetros
de entrada y salida entre una aplicacin y un servicio web. Para el transpor-
te de estos mensajes se pueden utilizar otros protocolos de comunicacin
como HTTP, SMTP, FTP o mediante colas de mensaje como protocolo ms
seguro. Adems existen los UDDI (Universal Description Discovery and Inte-
gration) un estndar para la administracin de los servicios web WSDL.
382
SOAP
Solicitante de Proveedor de
Servicio Servicio
WSDL WSDL
Registro de
Servicio
- SOAP: define un protocolo de comunicacin XML para la comu-

nicacin entre servicios.
- WSDL: es un formato para especificar web services y puede
proporcionar informacin de cmo puede ser usado ese web
service.
- UDDI: provee de la infraestructura para publicar informacin
acerca de los servicios y sus proveedores.
Para los servicios que deban ser expuestos y/o consumidos por usuarios,
se utilizan generalmente los frontales web que se conectan a los servicios a
travs de un bus de servicios. En SOA, a diferencia de las integraciones tra-
dicionales a travs por ejemplo de Middleware, las integraciones se realiza-
rn mediante los ESB (Enterprise Service Bus) para convertir los aplicativos
en web services. Aunque los ESB no implementan una arquitectura orienta-
da a servicios SOA nos permite el poder implementar al ser el encargado del
enrutamiento de los mensajes a las aplicaciones apropiadas y la transfor-
macin a travs de adaptadores de los mensajes en una arquitectura SOA
Como vemos, los web services son el mecanismo a travs del cual im-
plementamos actualmente las arquitecturas orientadas a servicios SOA. Los
web services pueden ser publicados o invocados por otras aplicaciones a
travs de la web para ofrecer sus funcionalidades. Los servicios que publi-
quemos o invoquemos proveern de los datos, la lgica y las reglas de ne-
gocio relacionados con algn aspecto de este, especificando que se puede y
que no se puede realizar con ellos y con quien, por lo que a menudo se
acompaan de un contrato que establece estos permisos y restricciones.
Volviendo a uno de los ejemplos de proceso utilizados en BPMN, pode-

mos ver como un web service puede ser visto como una tarea o subproceso
383
al que recurrimos en tareas automatizadas cuando requerimos de datos o

servicios de otros aplicativos y sistemas:
Todo sistema puede interpretarse como un conjunto de servicios. SOA

no es un software o lenguaje de programacin, es un marco de trabajo con-
ceptual para la integracin de datos y la lgica de negocio de sistemas sepa-
rados a nuevos componentes en forma de servicios. La orientacin a servi-
cios, igual que la orientacin a procesos, requiere para poder tener xito,
que los analistas y desarrolladores software se orienten hacia esta mentali-
dad de crear servicios orquestados y un compromiso con el modelado y
diseo para aplicaciones orientadas a servicios.
SOA nos va a permitir agilidad en el sentido de que podemos cambiar

nuestras aplicaciones e integraciones con otros sistemas de forma rpida
sin necesidad de reprogramar nuestros aplicativos, sistemas EDI o Middle-
ware, mejorando los tiempos en la realizacin de cambios en los procesos al
poder sustituir las arquitecturas informticas sin necesidad de cambiar los
modelos de procesos, facilitarnos la evolucin ordenada a nuevos modelos
de negocio y arquitecturas informticas y permitir la integracin de nues-
tros sistemas y web services con proveedores, clientes y partner de negocio
de forma clara y segura.
La combinacin de BPM y SOA resultar en una perfecta simbiosis entre

los niveles ms altos y centrados en el negocio y los ms bajos, centrados
en las implementaciones finales de TI. BPM permitir el desarrollo y la au-
tomatizacin de los procesos de negocio, a travs de la eficiencia y mejora
de sus procesos, mientras que SOA, como nuevo paradigma para el desarro-
384
llo, paquetizacin, despliegue y consumo de funcionalidades TI, proporcio-

nar los elementos clave para la transformacin de las distintas aplicaciones
existentes en las organizaciones y en TI (como por ejemplo, ERP, CRM y
SCM), en servicios reutilizables, basados en estndares de integracin, re-
sultando la combinacin en que los procesos de negocio podrn hacer uso
(consumir) los servicios definidos en SOA.
La sinergia entre BPM y SOA ayudar en gran medida a reducir la com-

plejidad de las tecnologas de la informacin, acelerando la automatizacin
de los procesos en las organizaciones y posibilitando un desarrollo ms
rpido de las aplicaciones de negocio, a la vez que contribuye a hacer los
procesos de negocio ms giles y flexibles. Aunque podamos enumerar las
grandes ventajas que nos aportar SOA a la hora de proceder con nuestras
integraciones, debemos tener en cuenta que ser muy difcil implementar-
las de golpe e incluso este no ser el escenario ideal, sino que deberemos
interiorizar esta nueva filosofa e implementarla a pasos, mientras hacemos
nuestro camino en BPM y SOA.
BPM y SOA son totalmente independientes, BPM no requiere SOA, pero

si simplifica su implementacin, sobre todo a la hora de conectar con apli-
caciones y servicios propios y de terceros, proveyendo de mayor nivel de
control y gobernanza sobre la infraestructura TI. Como dice Paul Harmmon,
BPMS no necesita SOA pero SOA necesita BPMS, pues los servicios no tie-
nen ningn sentido sin el contexto que ofrecen los procesos de negocio.
Esto mismo puede ser de aplicacin a la tan de moda Cloud de aplicacio-
nes en la nube, donde estas aplicaciones necesitan de SOA para racionalizar
sus operaciones y proveer de las demandas de flexibilidad y escalabilidad
que estas demandan y poder aprovechar as todas las ventajas que estas
aplicaciones en la nube ofrecen.
BPM no es tecnologa y hay muchas mejoras que se pueden alcanzar con

BPM sin tecnologa. Muchas organizaciones piensan que por adquirir un
software de BPM ya tiene sus problemas solucionados. No repitamos erro-
res como los descritos en la implementacin de soluciones ERP, estas solu-
ciones son herramientas tecnolgicas, pero debemos recordar que BPM es
en esencia el anlisis y mejora de los procesos de negocio de la empresa
que podrn o no ser implementados haciendo uso de la tecnologa, pero no
pongamos todas nuestra esperanzas en una herramienta tecnolgica que
no vaya dirigida por un proyecto de BPM que tenga en cuenta los procesos
y sus posibilidades de mejora, las personas, que busque la implicacin de la
direccin, el liderazgo, la cultura y dems conceptos vistos en este libro. La
385
importancia de un proyecto de TI no se mide en funcin del precio pagado

por la herramienta o el tamao de la empresa a la que subcontratemos su
implementacin. A la hora de adquirir una solucin BPM, los vendedores
normalmente son empresas de software o tecnolgicas y son ellos los pri-
meros en decirnos que BPM es tecnologa, pero no debemos olvidar exigirle
su demostrada capacidad para ver el lado de negocio al considerar una
implementacin o estrategia de BPM y no slo el lado tecnolgico. Ya pues-
tos, podemos exigir independencia tecnolgica, que no estn atados a una
determinada herramienta o tecnologa que dirija sus anlisis de negocio,
pues en muchas ocasiones, podremos reutilizar nuestros actuales sistemas
de TI para un proyecto de BPM o escoger nuevas plataformas ms acordes
a las necesidades y capacidades de nuestra empresa y que como hemos
visto, no siempre tienen por qu incluir todos los mdulos necesarios en un
nico paquete software.
La capa de procesos:
Los BPMS incluyen una capa de procesos sobre la tradicional arquitectu-

ra en 3 capas, de forma que podemos separar las aplicaciones y sus datos
de la gestin de los procesos pudiendo realizar modificaciones rpidamente
y de forma econmica sobre los procesos sin modificar las aplicaciones.
En la arquitectura en tres capas la integracin con aplicaciones es reali-

zada punto a punto, desarrollndose interfaces de comunicacin para cada
una de las necesidades de integracin por lo que cuando precisamos de
muchas integraciones, que suele este ser el caso de la mayora de necesi-
386
dades de negocio actuales, esto se vuelve ingestionable, adems de consu-

mir una gran cantidad de recursos para las integraciones y su mantenimien-
to en cuanto a integridad de datos.
Con la capa de procesos, podemos realizar estas integraciones en base al

diseo de procesos modelado, pudiendo especificar por ejemplo una tran-
saccin en un aplicativo externo de la organizacin sin necesidad de des-
arrollar una interfaz de comunicacin con l mismo, usando los conectores
y adaptadores de que disponen los BPMS para estas integraciones con dife-
rentes aplicaciones y fuentes de datos externas. Esta capa de procesos que
separa los procesos de las aplicaciones, es la que permite a la gente de ne-
gocio participar en el desarrollo de aplicaciones software e integraciones,
modelando ellos mismos los procesos de negocio con todo lo necesario
para que estos funcionen y reduciendo el distanciamiento que comentba-
mos entre negocio y departamentos de TI, al tiempo que permite la mejora
continua de los procesos y la simulacin de los distintos escenarios para
obtener medidas de comportamiento del proceso previamente a su imple-
mentacin.
Las arquitecturas de TI tradicionales disponen de tres capas: datos (ba-

ses de datos), aplicaciones (la lgica de proceso) y presentacin (donde
interacta el usuario). En la estructura de 4 capas, la capa de procesos se
sita entre la de presentacin y la de aplicaciones. En la de 3 capas, la inter-
accin entre el usuario y las aplicaciones es realizada punto a punto. Cuan-
do una aplicacin necesita datos de otra aplicacin, se crea una nueva inter-
faz para transferir esos datos. Segn va creciendo el negocio y los requisitos
de informacin, las aplicaciones tienen que ser modificadas y se crean nue-
vas aplicaciones, por lo que el nmero de interfaces de presentacin crece
exponencialmente, surgiendo muchos problemas de sostenibilidad de estas
aplicaciones punto a punto, pues requieren de un ejrcito de programado-
res para mantenerlas y unos altos costes de mantenimiento.
Gestin de casos
En los ltimos aos se ha desarrollado y discutido en muchos foros de

internet sobre la gestin de casos como alternativa a la gestin por proce-
sos o como nueva perspectiva sobre la mirar estos proyectos, por lo que no
quisiera dejar este captulo sin comentar esta visin.
387
Un caso, al igual que los procesos, consiste en un conjunto de activi-

dades, pero donde no existe un flujo secuencial entre estas actividades,
pues este flujo viene determinado por cada caso, o por las decisiones que
tomen los encargados de realizar las actividades, y es por ello que hablamos
de Gestin Dinmica de Casos (Dynamic Case Management) o de Adaptive
Case Management. Los Casos son en consecuencia asuntos puntuales a
resolver en una organizacin en un determinado periodo de tiempo, que
provienen de solicitudes (internas o externas): incidencias, peticiones, soli-
citudes de compra, etc.
En BPM y en los procesos de negocio existe un flujo o modelo predefini-

do de comportamiento del proceso de principio a fin, pero en la gestin de
casos, desaparece esta ruta, la cual seguir las directrices de decisiones
tomadas en el transcurso del proceso por personal experto o eventos, tan-
to internos como externos, que puedan acontecer durante su desarrollo y
que determinarn en tiempo de ejecucin las actividades que se deben
desarrollar y almacenando y documentando toda la informacin referente
al caso.
El modelo genrico de BPMS que hemos visto en este captulo, puede

comportarse perfectamente para realizar la gestin de casos, pues al final,
el comportamiento del proceso depender de la intervencin de distintos
usuarios a travs de los formularios y sistemas con los que se integre el
proceso, por lo que lo que no existe tal rigidez en BPM como para impedir
la gestin de casos, sin embargo, para completar algunas funcionalidades
de esta gestin de casos, en especial la asociada a la documentacin de los
mismos, que es donde se centra la gestin de casos, algunos BPMS con-
templan ya este tipo de gestin a travs de la capacidad de un proceso de
irse configurando en torno a un caso especfico. Un aspecto concerniente a
la gestin de casos es que un simple caso puede involucrar a varios proce-
sos, por lo que los BPMS debern ser capaces desviar la corriente de unos
procesos a otros.
388
389
Bibliografa
Libros:
Addy, Rob. Effective IT Service Management to ITIL and Beyond!
Springer, 2007.
Age, Susan, The Power of Business Improvement, 2010, ISBN-13: 978-0-
8144-1478-1
Boar, Bernard H. Practical Steps for Aligning Information Technology with
Business Strategies. Wiley, 1994.
Bridgeland, David & Zahavi, Ron. Business Modeling: A Practical Guide to
Realizing Business Value.- MK/OMG Press, 2008.
Champy, James. Reengineering Management: The Mandate for New
Leadership. Harper Business Book, 1995.
Chang, James F. Business Process Management Systems- Auerbach, 2006.
ISBN-10: 084932310X
Chopra, Sunil and Peter Meindl. Supply Chain Management: Strategy,
Planning and Operations. Prentice Hall College Division, 2000.
Cummins, Fred. Building the Agile Enterprise with SOA, BPM, and MBM -
Morgan Kaufmann/OMG Press, 2009
Curtis, Bill, William E. Hefley and Sally A. Miller. The People Capability
Maturity Model: Guidelines for Improving the Workforce. Addison-
Wesley, 2002.
Damelio, Robert. The Basics of Process Mapping. 1996, ISBN 0-527-76316-0
Davenport, Thomas. Process Innovation: Reengineering Work through
Information Technology. H. Harvard Business School Press, 1993.
390
Bibliografa
Davenport, Thomas H. Mission Critical: Realizing the Promise of Enterprise

Systems. Harvard Business School Press, 2000.
Debevoise, Tom. Business Process Management with a Business Rules
Approach, 2007. ISBN 978-1-4196-7368-9
Debevoise, Tom & Geneva, Rick. The Microguide to Process Modeling in
BPMN - Tipping Point, 2008
Eckes, George The Six Sigma Revolution: How General Electric and Others
Turned Process into Profits. John Wiley. 2001.
Fischer, Layna (Ed.). The Workflow Paradigm: The Impact of Information
Technology on Business Process Reengineering (2nd Ed.). Future
Strategies Book, 1995.
Grover, Varun and William J. Kettinger. Business Process Change:
Reengineering Concepts, Methods and Technologies. Idea Group
Publishing, 1995.
Hammer, Michael & Champy, James. Reengineering the Corporation: A
Manifesto for Business Revolution. Harper Business Book, 1993.
Hammer, Michael. Beyond Reengineering: How the Process-Centered
Organization Is Changing Our Work and Our
Lives. HarperBusiness, 1997.
Harmon, Paul. Business Process Change: A Manager's Guide to Improving,
Redesigning and Automating Processes. Morgan-Kaufmann.
Harmon, Paul. Business Process Change, Second Edition - Morgan Kaufman,
2007.
Harrington, H. James. Business Process Improvement: The breakthrough
Strategy for Total Quality, Productivity, and Competitiveness.
McGraw-Hill, 1991
Hiatt, Jeffrey and Creasey, Timothy. Change Management: The People Side
of Change - Prosci, 2003.
Jeston, John & Nelis, Johan. Business Process Management Practical
Guidelines to Successful Implementations, Second Edition -
Elsevier, 2008.
Johansson, Henry J., Patrick McHugh, A. John Pendlebury and William A.
Wheeler III. Business Process Reengineering: Breakpoint Strategies
for Market Dominance. Wiley, 1993.
Kaplan, Robert S. & Norton, David P. The Balanced Scorecard: Translating
Strategy into Action - Harvard Business School Press, 1996. ISBN-
10: 0875846513
Keller, Paul, Six Sigma DeMYSTiFieD. ISBN 0-07-144544-7
Kubeck, Lynn C. Techniques for Business Process Redesign: Tying It All
Together. Wiley-QED Publichation, 1995.
Morgan, Tony. Business Rules and Information Systems: Aligning IT with

Business Goals. Addison-Wesley, 2002.
Ould, Martyn. Business Process Management: A Rigorous Approach -
Meghan-Kiffer, 2005. ISBN-10: 0929652274
Osterwalder, Alexander & Pigneur, Yves. Business Model Generation.
Wiley, 2010. ISBN: 978-0470876411
Parmenter, David. Key Performance Indicators: Developing,
Implementing,and Using Winning KPIs. Wiley, 2007
Paulk, Mark C., Charles V. Weber, Bill Curtis and Mary Beth Chrissis
(Principal contributors and Editors). The Capability Maturity Model:
Guidelines for Improving the Software Process. Addison-Wesley,
1995.
Porter, Michael E. Competitive Advantage: Creating and Sustaining
Superior Performance. Free Press, 1985.
Project Management Institute. A Guide to the Project Management Body
of Knowledge, Fourth Edition (PMBOK Guides), 2008.
Rosen, Michael. Applied SOA: Service-Oriented Architecture and Design
Strategies - Wiley, 2008
Ross, Ronald. Principles of the Business Rule Approach - Pearson, 2003.
Ross, Jeanne W. et al Enterprise Architecture as Strategy: Creating a
Foundation for Business Execution. - Harvard Business School Press,
2006
Ross, Ronald. Business Rule Concepts: Getting to the Point of Knowledge,
2nd edition - BRF, 2005.
Rummler, Geary & Alan Brache. Improving Performance: How to Manage
the White Space on the Organization Chart. (2nd Ed.). Jossey-Bass,
1990.
Sayer, Natalie & Williams, Bruce. LEAN for Dummies. - Wiley, 2007
Senge, Peter M. The Fifth Discipline: The Art & Practice of the Learning
Organization. Currency Doubleday, 1994.
Smith, Howard & Fingar, Peter. Business Process Management: The Third
Wave, Fourth Anniversary Edition - Meghan-Kiffer, 2007. ISBN-10:
0929652347
392
Bibliografa
Especificaciones de OMG:
Todas estas especificaciones podemos descargarlas en la pgina de OMG
(Object Management Group) en: www.omg.org.
- Business Process Maturity Model (BMM) Specification, V1.0

- Business Motivation Model (BMM) Specification, V 1.0
- Business Process Model Notation (BPMN), V1.1
- Organization Structure Metamodel Specification Draft
- Business Process Definition Metamodel specification, Beta 2
- Semantics of Business Vocabulary and Business Rules
Specification (SBVR), V1.0.
- Web Services Choreography Description Language Version 1.0.
Otros Frameworks y especificaciones:

Realizando una simple bsqueda en Google, podemos acceder tambin a la
consulta o descarga de distintos estndares y frameworks:
- APQC Process Classification Framework, V 5.0.3

- eTOM
- Supply Chain Council's Supply-Chain Operations Reference
model (SCOR), v9.0
- Introduction to the Value Reference Model (VRM)
- SOA Consortium case studies.

LibroBPM Sergio

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

LibroBPM Sergio

Загружено:

Авторское право:

Доступные форматы

BPM (Business Process Management).

Cmo alcanzar la agilidad y eficiencia operacional a travs

Jos Ramn Pais Curto

Coleccin Conceptos Clave BPM

Edicin original en espaol

Jos Ramn Pais Curto, 2013. Todos los derechos reservados.

Foto cubierta: Jos Ramn Pais Curto

Editor: Pedro Robledo, 2013

Todas las marcas y nombres de productos mencionados en este libro son

Todos los derechos reservados. Fabricada la versin digital en espaol en

Informacin sobre Catalogacin por el Editor

ISBN: 978-84-616-3854-3 Versin Digital

ACERCA DEL AUTOR ..................................................................................... 11

Adems de autor, ofrece servicios de consultora y acompaamiento a

Para contactar con el autor o realizar cualquier tipo de consulta o co-

La necesidad de adecuacin a nuevos modelos de negocio y mercados,

BPM nos descubre una nueva forma de gestionar las organizaciones

monitorizacin de estos procesos de negocio, se ha convertido en el reto

Todas las organizaciones desean mejorar sus beneficios, mejorar los

Muchas veces entendemos BPM como una nueva herramienta o produc-

forma racional a como ejecutamos nuestro negocio y creamos valor,

Esta perspectiva y posicionamiento de BPM como modelo de gestin or-

El haberme dedicado estos ltimos aos a profundizar en BPM y los

Sin embargo, debo reconocer mi escepticismo inicial. Cuando los siste-

Durante varios aos, he dirigido y desarrollado soluciones TIC en distin-

Con la aparicin de internet esta situacin se ha agravado todava ms.

ocupacin de nuestro hotel en un libro fsico de reservas. O tal vez poda-

Las necesidades de acceso a la informacin, de interconexin de datos y

Con BPM se reduce el distanciamiento entre negocio y tecnologa y las

gas. La informtica ha cambiado de las estructuras de datos a la estructura

BPM presenta muchas ventajas para las organizaciones que decidan

La perspectiva de BPM exigir tambin del alineamiento de negocio y

BPM requerir tambin de un compromiso con las personas, pues stas

Este carcter multidisciplinar, requerir de nuevos roles relacionados

Este libro refleja la naturaleza holstica de BPM desde un planteamiento

empresa como Sistema y con los Modelos de Negocio y Arquitecturas Em-

El libro se dirige a estudiantes y profesionales interesados en BPM: res-

Mi objetivo no es adoctrinar sobre esta materia y convertirla en un

mejorarlos. El lector entender como enfocar metodolgicamente el anli-

El reto formativo es grande, pues BPM es multidisciplinar y requerir de

Este libro ha sido el resultado de la preparacin de distintos cursos de

Acerca de la Certificacin OCEB.

El primer examen cubre los elementos bsicos y los puntos esenciales

El examen se realiza online a travs de un centro Pearson VUE. El conte-

ESTRUCTURA DEL LIBRO

Captulo 1: La gestin de procesos.

Este captulo comienza describiendo los sistemas y las organizacio-

ptulo las bases de la Gestin de Procesos, sus caractersticas y propiedades,

Captulo 2: Los caminos hacia BPM.

Captulo 3: Tecnologa, Innovacin y Modelos de Negocio.

Este captulo resume la evolucin de las Tecnologas de la Informa-

veremos la importancia de los modelos de negocio sobre los que se susten-

En la segunda parte del libro, se introduce la disciplina de BPM as

Captulo 4: BPM (Business Process Management)

De la convergencia de las teoras de gestin de las organizaciones y

Captulo 5: Modelado de Negocios.

En este captulo abordamos el diseo de modelos y arquitecturas

estndar de OMG (Object Management Group) para el establecimiento de

Captulo 6. Modelado de procesos. BPMN.

Este captulo se dedica ntegramente a la descripcin de la notacin

La tercera parte del libro se ocupa de la implementacin de un pro-

Captulo 7. Implementacin de BPM.

Este es el captulo ms extenso del libro, pues en el recopilamos to-

Captulo 8. Tecnologa BPM. BPMS.