Gestion de Proceso Captulo:5

Se centra en los problemas de gestin de nivel empresarial, como las empresas estructuran a
sus gerentes y como los procesos de gestin estn representados en la arquitectura de procesos
empresariales de una empresa.

Cap3: Metodologa BPTrends Enterprise

Cap4: Arquitectura de Procesos de Neg. y Jerarqua de Procesos

Las empresas consideran estas cuestiones por separado: Divisin entre la arquitectura del
proceso y las cuestiones de gestin y medicin, por tanto las empresas q no comienzan una
arquitectura de proceso ya pueden tener un sistema de Balanced Scorecard para evaluar el
desempeo de la gerencia. Cuando se trabaje con la metodologa BPTrends Enterprise se ver
el establecimiento de la jerarqua de proceso bsico y el alineamiento de los recursos para
agregar las medidas y responsabilidades de gestin en un momento posterior.

Primero se ver las cuestiones generales q las empresas deben abordar, y luego, los
aspectos especficos para definir una arqui. de procesos de negocio.

Qu es la gestin?
Trata sobre la mejora de procesos de negocio, considerando cmo se puede organizar la gestin
para apoyar procesos empresariales efectivos. Un trabajo puede estar compuesto de mltiples
funciones (roles).

Hay 2 Tipos de funciones: Gestin operativa (responsabilidades continuas) y Gestin de

proyecto (proyectos limitados en el tiempo). Por ejm, un gerente de proyecto redisea un
proceso Widget, y el operacional jefe de una divisin, departamento, encargado del proceso
responsable del funcionamiento diario de Widget. Solo se tomar en cuenta gestin de proyecto
en cambios de procesos empresariales.
 Gestin operativa (divisin) -> Gerentes: responsables de las unid. Funcionales
Encargados: responsables de procesos

Gerentes Funcionales o de Unidad

Las emp. se organizan en unid. Funcionales (emp pequeas: organizaciones en departamentos

emp grandes: organizaciones en divisiones y luego en departamentos). La divisin vara segn
compaa: Centrada en la produccin de lnea de producto, Unidades geogrficas, etc. Por tanto
en una gran empresa no es infrecuente tener una mezcla de unidades divisionales y
departamentales.

Figura 5.2: Organigrama tpico para una empresa de tamao mediano

Relaciones de soporte de los gerentes de la unidad

Este organigrama muestra que los gerentes son responsables de qu funciones e indicar las
relaciones de reporte. Por ejm, el Administrador de Produccin informa al VP de Fabricacin de
Widgets, este establece el salario de gerente de produccin, con alguna orientacin de recursos
humanos, evala el desempeo del gerente, aprueba su presupuesto y es la autoridad final
sobre las polticas relacionadas con la produccin Widget.

Gerentes funcionales de nivel medio usan 2 sombreros: Gestor funcional y Gestor de Procesos.
Figura 5.3: En este sencillo ejemplo, una cadena de valor se compone de un proceso de ventas,
fabricacin y entrega. Cada uno de estos procesos es gestionado por un individuo que trabaja
dentro de una unidad funcional e informa al jefe de la unidad funcional. Por lo tanto, el mismo
gerente -el supervisor de ventas, por ejemplo- es a la vez el gestor funcional y de proceso del
proceso Widget Sales.

Gerentes funcionales que tambin son gerentes de procesos

Si surgen problemas, se producen porque las unidades funcionales a menudo defienden su
territorio y resiste cooperar con otras unidades, este tipo de pensamiento ha llevado a muchas
organizaciones a cuestionar la dependencia excesiva de las estructuras funcionales de la
organizacin.

Antes de considerar algn cambio hacia un enfoque alternativo, se debe tener claro el valor del
enfoque funcional. Los gerentes departamentales se ocupan principalmente de las normas q se
aplican a su departamento o funcin particular, en la mayora de los casos se contrat a un
gerente para ocupar un puesto de subalterno dentro de un departamento y en los ltimos aos
se especializa en esa rea funcional. Este tipo de especializacin es una caracterstica muy
valiosa del enfoque funcional.

La gestin funcional preserva valiosos conocimientos corporativos y aporta experiencia a la

supervisin de las tareas especializadas, pero a veces altos directivos prefieren centrarse solo
en un rea ignorando las dems.

Gerentes de procesos

La figura 5.3 proporciona una visin general de la funcin de un gestor de procesos ->
operacional

Se describir las diversas funciones gerenciales relacionadas con un proceso, el punto a

considerar es q una organizacin se compone de procesos, y debe haber un responsable del
funcionamiento para cada uno. En niveles bajos: El responsable es un gerente funcional en un
sombrero de un gerente de proceso. En los niveles altos: es ms complejo ya q las cadenas de
valor o grandes procesos cortan a travs de los lmites funcionales.

El encargado de proceso es responsable en cuanto se ejecuta el proceso; trabajar con

proveedores, clientes y procesos para asegurar q este tenga todos los recursos para producir el
producto q el cliente desea. Cuando se aborda la gestin de procesos:

Cuando se realice proyectos de rediseo de procesos, se encontrar hablando de

Individuo
Cuando se enfoca en los organigramas gerenciales : Papel
Cuando se centra en las competencias: Proceso

En la Figura 5.5 se ampla el cuadro de Gestin de Procesos de la Figura 5.4 e insertado algunos
procesos gerenciales tpicos. Se divide el proceso de gestin en 4 subprocesos genricos:

Uno que planifica y presupone el trabajo

Uno que organiza el flujo de trabajo
Uno que se comunica con los empleados y otras personas
Uno q supervisa el trabajo y toma medidas para que el trabajo cumpla con los criterios
de calidad

Las flechas sugieren las principales relaciones entre los 4 procesos y lo elemento q se estn
manejando.
Figura 5.4: Una visin general de los procesos genricos de gestin de procesos y subprocesos

Figura 5.5: Una visin general de alto nivel de la gestin de procesos

Los gestores de procesos estn asignados para administrar un proceso existente q ya est
organizado y funcionando, no lo organizan desde cero, pero si comprueban el proceso para
asegurar su buen funcionamiento. Similarmente, si heredan el proceso, heredarn tmb las
medidas de calidad y produccin. Si el nuevo gerente ve q todo funciona sin problemas, si hay
margen para mejorar, debe hacer un plan de mejora de proceso. Luego de eso, el gerente tiene
actividades gerenciales en el da a da y otra q se realiza en base semanal, mensual o trimestral.
Luego actividades especficas: despedir un empleado incompetente, contratar, entre otros.

A nivel empresarial, nos preocuparemos ms por cmo las empresas establecen los gestores de
procesos, cmo se relacionan los gestores de procesos con los gestores de unidades o
funcionales y cmo se evalan los procesos y los gestores de procesos.

Los gerentes de procesos (nivel de empresa) responsables de ver q todos los procesos de la
organizacin trabajan juntos para q la cadena de valor sea ms eficiente.
 Gerente Funcional: todos los procesos dentro de un dpto. funcionan eficientemente
Gerente de procesos: todos los procesos en la cadena de valor funcionen bien juntos

EL gestor de procesos necesita entender la estrategia q la compaa persigue y as controlar los

procesos en la cadena de valor para lograr el resultado deseado.

Si se tiene q elegir la nica cosa q distingue a un gestor de procesos de uno funcional sera la
preocupacin del primero por la forma en q su proceso encaja con otros procesos y contribuye
a la eficiencia general de la cadena de valor.

Gestin funcional o de procesos?

Como ya hemos visto, en los niveles ms bajos de la organizacin, es muy comn que un solo
gestor funcione como una unidad y un gestor de procesos. En niveles ms altos, sin embargo, se
vuelve ms difcil combinar los dos roles. Por lo tanto, cuando una organizacin considera su
estructura organizativa general de gestin, la organizacin a menudo debate las ventajas
relativas de un nfasis en la gestin funcional o de procesos. La Figura 5.6 ilustra una
organizacin simple que tiene dos cadenas de valor, una que produce y vende Widgets y otra
que vende un tipo de producto totalmente diferente, Smidgets. Esto hace que sea fcil ver cmo
las preocupaciones de los gerentes funcionales difieren de los gerentes de procesos. El jefe del
departamento de ventas est interesado en mantener una organizacin de ventas. l o ella
contrata a los vendedores de acuerdo a los criterios de venta, entrena a las personas de ventas
y las evala. En trminos generales, desde la perspectiva del jefe de ventas, la venta de Widgets
y la venta de Smidgets es el mismo proceso, y quiere estar seguro de que el proceso de venta se
implementa de la manera ms eficiente posible. Por otra parte, el VP para el proceso Widget se
ocupa de toda la cadena de valor de Widget y se preocupa principalmente de que los procesos
de ventas y servicio de Widget trabajen juntos sin problemas para proporcionar valor a los
clientes de Widget. El gestor de procesos de Widget estara encantado de cambiar la forma en
que funciona el proceso de ventas si, junto con otros procesos de Widget, se combinan para
proporcionar un mejor servicio a los clientes de Widget.

Las diferentes preocupaciones de los gestores funcionales y de procesos.

Por lo tanto, aunque es posible que un individuo sirva como una unidad y un gestor de procesos,
es una tensin. Sin algn apoyo externo de alguien que hace hincapi en el proceso, es casi
imposible.

Gestin de matrices

Una vez definida la gestin funcional y de procesos, consideremos cmo una organizacin podra
combinar las fortalezas de los dos enfoques en la parte superior de la organizacin.
Recientemente, las principales organizaciones han comenzado a establecer algn tipo de
jerarqua de gestin de procesos que, al menos en el nivel superior, es independiente de la
jerarqua funcional de la organizacin. La posicin superior en una jerarqua de procesos es un
administrador que es responsable de toda una cadena de valor. Dependiendo de la complejidad
de la organizacin, el administrador de la cadena de valor podra tener otros gestores de
procesos informando a l o ella. Este enfoque tpicamente resulta en una organizacin matriz
como la que se muestra en la Figura 5.7.
En la figura 5.7 mostramos una empresa como la que se muestra anteriormente con tres
unidades funcionales. En este caso, sin embargo, se ha agregado otro gerente senior y este
individuo es responsable del xito de la cadena de valor de Widget. Diferentes organizaciones
asignan autoridad de diferentes maneras. Por ejemplo, el gestor de procesos de Widget slo
puede funcionar en calidad de asesor. En este caso, l o ella convocara reuniones para discutir
el flujo de la cadena de valor de Widget. En tal situacin el supervisor de ventas todava debe su
lealtad primaria al VP de ventas y ese individuo todava sera responsable de pagar, de evaluar
y de promover al supervisor de ventas. La clave para hacer que este enfoque funcione es pensar
en la gestin de la cadena de valor de Widget como un esfuerzo de equipo. En efecto, cada
supervisor con la responsabilidad de la gestin de un proceso que cae dentro de la cadena de
valor de Widget es un miembro del equipo de gestin de la cadena de valor de Widget.

La Figura 5.8 proporciona un continuo que se modifica de uno desarrollado por el Project
Management Institute (PMI). PMI propuso este continuum para contrastar las organizaciones
que se enfocaban en estructuras funcionales y aquellas que enfatizaban proyectos. Lo utilizamos
para comparar organizaciones funcionales y de procesos. En ambos casos, el rea entre los
extremos describe el tipo de organizacin matriz que la compaa ha instituido.

Tipos de estructura organizacional (modificada a partir de la clasificacin del Instituto de Gestin

de Proyectos de cinco tipos de organizacin).

El tipo de matriz que tiene una organizacin se determina examinando la autoridad y los
recursos que la alta direccin asigna a los gerentes especficos.

La Gestin de Procesos Subcontratados

La organizacin de los gerentes est siendo complicada en muchas empresas por la

subcontratacin. Reconsidere la Figura 3.6 en la que describimos cmo Dell divide sus procesos
centrales de los que subcontrata. Dell actualmente disea nuevas computadoras que pueden
ser fabricadas por componentes fcilmente disponibles. Comercializa sus computadoras en una
variedad de formas y las vende a travs de un sitio Web que permite a los usuarios configurar
sus propios modelos especficos. Una vez que un cliente ha realizado un pedido, Dell transfiere
la informacin a un subcontratista en Asia. Los componentes, creados por otros subcontratistas,
estn disponibles en un almacn, propiedad y operado por el subcontratista, y las computadoras
son montadas y luego entregadas por el subcontratista. Si, despus de la entrega, el equipo
necesita reparaciones, es recogido por un servicio de entrega subcontratado y reparado en un
almacn operado por el subcontratista, luego devuelto al propietario.

Dejando a un lado las cuestiones involucradas en la descripcin de una cadena de valor que se
plantean cuando una empresa subcontrata lo que tradicionalmente se ha considerado procesos
centrales, Dell, despus de todo, suele clasificarse como un fabricante de equipos informticos,
considera los problemas de gestin planteados por este modelo. Dell no est haciendo la
fabricacin o la distribucin. El outsourcer es la gestin de ambos procesos y presumiblemente
tiene su propia organizacin de gestin. Por otro lado, Dell ciertamente necesita administrar
estos procesos indirectamente, ya que su xito general depende de proporcionar a un cliente
con un equipo dentro de 2-3 das de tomar la orden del cliente. En efecto, Dell no necesita
administrar los aspectos funcionales tradicionales de su proceso de fabricacin de PC / Desktop,
pero s necesita administrar el proceso, como un todo. Esta situacin, y muchas variaciones en
este tema, estn impulsando la transicin hacia una gestin de procesos ms slida.

Cadenas de Valor y Normalizacin de Procesos

Hay que considerar otra tendencia en la gestin de los procesos. Cuando discutimos los tipos de
alineacin que las compaas podran buscar documentar, mencionamos que la identificacin
de procesos estndar era una meta popular. En efecto, si una empresa est haciendo la misma
actividad en muchos lugares diferentes, debera considerar hacerlo de la misma manera. Un
ejemplo trivial sera obtener una aprobacin de tarjeta de crdito. Esto ocurre cuando un cliente
enva una tarjeta de crdito y el vendedor procede a pasarlo a travs de un "lector" y luego
espera la aprobacin y un boleto de ventas para ser impreso. El flujo que describimos depende
del software que transmite informacin sobre la tarjeta de crdito a la agencia de aprobacin
de tarjetas de crdito y devuelve la informacin necesaria para generar el resbaln de ventas.
Hacer este proceso de una manera estndar reduce la capacitacin de los empleados, simplifica
los requisitos de informacin y facilita el traslado de empleados entre diferentes operaciones,
todo lo que hace que la empresa sea ms gil y eficiente. Hacerlo con el mismo software reduce
la necesidad de desarrollar o comprar un nuevo software. Si se utiliza una aplicacin de software
empaquetado (ERP), un proceso estandarizado reduce el costo de actualizar el mdulo ERP y
asegura que el mismo mdulo ERP se puede usar en todas partes donde se realiza la aprobacin
de la tarjeta de crdito.

Muchas empresas instalaron aplicaciones ERP sin primeros procesos de estandarizacin. Esto
result en mdulos ERP que fueron adaptados de diferentes maneras para apoyar diferentes
procesos especficos. Cuando se actualiza el mdulo ERP bsico, esto significa que el nuevo
mdulo tiene que ser adaptado, de nuevo, para cada proceso especfico diferente que admita.
Si todos los procesos estn estandarizados, esto reducir enormemente el costo de desarrollar
y mantener las aplicaciones ERP de la organizacin. As, varias grandes empresas han lanzado
programas diseados para identificar y estandarizar los procesos en todas las organizaciones.

La mayora de las empresas, cuando se establecen sobre la normalizacin de sus procesos, la

estructura del esfuerzo mediante el establecimiento de un proceso de gestin de la estructura
organizativa. Por lo tanto, crean una organizacin matricial y asignan a los individuos para
gestionar "reas de proceso estndar". A estos individuos (responsables de procesos) se les pide
que examinen todos los departamentos de la empresa e identifiquen todos los lugares donde se
llevan a cabo las actividades que podran estandarizarse. La figura 5.9 muestra la matriz
desarrollada en el curso de un esfuerzo de este tipo.

En la figura 5.9 hemos convertido a la organizacin funcional tradicional en su lado, de modo

que las divisiones y departamentos de la compaa funcionan de izquierda a derecha. En la parte
superior nos imaginamos a los gerentes de procesos y mostramos cmo sus preocupaciones
recorren todas las divisiones y departamentos. A primera vista, esto podra parecer una
organizacin matriz que se organiza alrededor de unidades funcionales y procesos. Considere,
sin embargo, que la compaa tiene ms de una cadena de valor. Una divisin vende artculos
de los productos bsicos a los hospitales mientras que otro construye las plantas de la refinera,
que entonces vende a otras organizaciones. Estas actividades son tan diferentes que tienen que
ser cadenas de valor separadas. Si queremos seguir a Porter y Rummler, trataremos de integrar
todos los procesos dentro de una nica cadena de valor alrededor de una nica estrategia para
asegurar que la cadena de valor, como un todo, sea lo ms eficiente posible. Para lograr esto, el
gestor de procesos es el responsable de toda la cadena de valor. En el ejemplo mostrado en la
Figura 5.10, el gerente de divisin responsable de la divisin de Ingeniera de Refinera de
Clientes est mejor posicionado para perseguir esa meta que el Gerente de Proceso de Ventas.
Del mismo modo, el gerente de divisin responsable de Productos Hospital estn mejor
posicionados para optimizar la cadena de valor del Producto Hospital que el gerente de Proceso
de Ventas.

Gestin funcional o de procesos?

Como ya hemos visto, en los niveles ms bajos de la organizacin, es muy comn que un solo
gestor funcione como una unidad y un gestor de procesos. En niveles ms altos, sin embargo, se
vuelve ms difcil combinar los dos roles. Por lo tanto, cuando una organizacin considera su
estructura organizativa general de gestin, la organizacin a menudo debate las ventajas
relativas de un nfasis en la gestin funcional o de procesos. La Figura 5.6 ilustra una
organizacin simple que tiene dos cadenas de valor, una que produce y vende Widgets y otra
que vende un tipo de producto totalmente diferente, Smidgets. Esto hace que sea fcil ver cmo
las preocupaciones de los gerentes funcionales difieren de los gerentes de procesos. El jefe del
departamento de ventas est interesado en mantener una organizacin de ventas. l o ella
contrata a los vendedores de acuerdo a los criterios de venta, entrena a las personas de ventas
y las evala. En trminos generales, desde la perspectiva del jefe de ventas, la venta de Widgets
y la venta de Smidgets es el mismo proceso, y quiere estar seguro de que el proceso de venta se
implementa de la manera ms eficiente posible. Por otra parte, el VP para el proceso Widget se
ocupa de toda la cadena de valor de Widget y se preocupa principalmente de que los procesos
de ventas y servicio de Widget trabajen juntos sin problemas para proporcionar valor a los
clientes de Widget. El gestor de procesos de Widget estara encantado de cambiar la forma en
que funciona el proceso de ventas si, junto con otros procesos de Widget, se combinan para
proporcionar un mejor servicio a los clientes de Widget.
Las diferentes preocupaciones de los gestores funcionales y de procesos.

Por lo tanto, aunque es posible que un individuo sirva como una unidad y un gestor de procesos,
es una tensin. Sin algn apoyo externo de alguien que hace hincapi en el proceso, es casi
imposible.

Gestin de matrices

Una vez definida la gestin funcional y de procesos, consideremos cmo una organizacin podra
combinar las fortalezas de los dos enfoques en la parte superior de la organizacin.
Recientemente, las principales organizaciones han comenzado a establecer algn tipo de
jerarqua de gestin de procesos que, al menos en el nivel superior, es independiente de la
jerarqua funcional de la organizacin. La posicin superior en una jerarqua de procesos es un
administrador que es responsable de toda una cadena de valor. Dependiendo de la complejidad
de la organizacin, el administrador de la cadena de valor podra tener otros gestores de
procesos informando a l o ella. Este enfoque tpicamente resulta en una organizacin matriz
como la que se muestra en la Figura 5.7.

En la figura 5.7 mostramos una empresa como la que se muestra anteriormente con tres
unidades funcionales. En este caso, sin embargo, se ha agregado otro gerente senior y este
individuo es responsable del xito de la cadena de valor de Widget. Diferentes organizaciones
asignan autoridad de diferentes maneras. Por ejemplo, el gestor de procesos de Widget slo
puede funcionar en calidad de asesor. En este caso, l o ella convocara reuniones para discutir
el flujo de la cadena de valor de Widget. En tal situacin el supervisor de ventas todava debe su
lealtad primaria al VP de ventas y ese individuo todava sera responsable de pagar, de evaluar
y de promover al supervisor de ventas. La clave para hacer que este enfoque funcione es pensar
en la gestin de la cadena de valor de Widget como un esfuerzo de equipo. En efecto, cada
supervisor con la responsabilidad de la gestin de un proceso que cae dentro de la cadena de
valor de Widget es un miembro del equipo de gestin de la cadena de valor de Widget.

La Figura 5.8 proporciona un continuo que se modifica de uno desarrollado por el Project
Management Institute (PMI). PMI propuso este continuum para contrastar las organizaciones
que se enfocaban en estructuras funcionales y aquellas que enfatizaban proyectos. Lo utilizamos
para comparar organizaciones funcionales y de procesos. En ambos casos, el rea entre los
extremos describe el tipo de organizacin matriz que la compaa ha instituido.
Tipos de estructura organizacional (modificada a partir de la clasificacin del Instituto de Gestin
de Proyectos de cinco tipos de organizacin).

El tipo de matriz que tiene una organizacin se determina examinando la autoridad y los
recursos que la alta direccin asigna a los gerentes especficos.

La Gestin de Procesos Subcontratados

La organizacin de los gerentes est siendo complicada en muchas empresas por la

subcontratacin. Reconsidere la Figura 3.6 en la que describimos cmo Dell divide sus procesos
centrales de los que subcontrata. Dell actualmente disea nuevas computadoras que pueden
ser fabricadas por componentes fcilmente disponibles. Comercializa sus computadoras en una
variedad de formas y las vende a travs de un sitio Web que permite a los usuarios configurar
sus propios modelos especficos. Una vez que un cliente ha realizado un pedido, Dell transfiere
la informacin a un subcontratista en Asia. Los componentes, creados por otros subcontratistas,
estn disponibles en un almacn, propiedad y operado por el subcontratista, y las computadoras
son montadas y luego entregadas por el subcontratista. Si, despus de la entrega, el equipo
necesita reparaciones, es recogido por un servicio de entrega subcontratado y reparado en un
almacn operado por el subcontratista, luego devuelto al propietario.

Dejando a un lado las cuestiones involucradas en la descripcin de una cadena de valor que se
plantean cuando una empresa subcontrata lo que tradicionalmente se ha considerado procesos
centrales, Dell, despus de todo, suele clasificarse como un fabricante de equipos informticos,
considera los problemas de gestin planteados por este modelo. Dell no est haciendo la
fabricacin o la distribucin. El outsourcer es la gestin de ambos procesos y presumiblemente
tiene su propia organizacin de gestin. Por otro lado, Dell ciertamente necesita administrar
estos procesos indirectamente, ya que su xito general depende de proporcionar a un cliente
con un equipo dentro de 2-3 das de tomar la orden del cliente. En efecto, Dell no necesita
administrar los aspectos funcionales tradicionales de su proceso de fabricacin de PC / Desktop,
pero s necesita administrar el proceso, como un todo. Esta situacin, y muchas variaciones en
este tema, estn impulsando la transicin hacia una gestin de procesos ms slida.

Cadenas de Valor y Normalizacin de Procesos

Hay que considerar otra tendencia en la gestin de los procesos. Cuando discutimos los tipos de
alineacin que las compaas podran buscar documentar, mencionamos que la identificacin
de procesos estndar era una meta popular. En efecto, si una empresa est haciendo la misma
actividad en muchos lugares diferentes, debera considerar hacerlo de la misma manera. Un
ejemplo trivial sera obtener una aprobacin de tarjeta de crdito. Esto ocurre cuando un cliente
enva una tarjeta de crdito y el vendedor procede a pasarlo a travs de un "lector" y luego
espera la aprobacin y un boleto de ventas para ser impreso. El flujo que describimos depende
del software que transmite informacin sobre la tarjeta de crdito a la agencia de aprobacin
de tarjetas de crdito y devuelve la informacin necesaria para generar el resbaln de ventas.
Hacer este proceso de una manera estndar reduce la capacitacin de los empleados, simplifica
los requisitos de informacin y facilita el traslado de empleados entre diferentes operaciones,
todo lo que hace que la empresa sea ms gil y eficiente. Hacerlo con el mismo software reduce
la necesidad de desarrollar o comprar un nuevo software. Si se utiliza una aplicacin de software
empaquetado (ERP), un proceso estandarizado reduce el costo de actualizar el mdulo ERP y
asegura que el mismo mdulo ERP se puede usar en todas partes donde se realiza la aprobacin
de la tarjeta de crdito.

Muchas empresas instalaron aplicaciones ERP sin primeros procesos de estandarizacin. Esto
result en mdulos ERP que fueron adaptados de diferentes maneras para apoyar diferentes
procesos especficos. Cuando se actualiza el mdulo ERP bsico, esto significa que el nuevo
mdulo tiene que ser adaptado, de nuevo, para cada proceso especfico diferente que admita.
Si todos los procesos estn estandarizados, esto reducir enormemente el costo de desarrollar
y mantener las aplicaciones ERP de la organizacin. As, varias grandes empresas han lanzado
programas diseados para identificar y estandarizar los procesos en todas las organizaciones.

La mayora de las empresas, cuando se establecen sobre la normalizacin de sus procesos, la

estructura del esfuerzo mediante el establecimiento de un proceso de gestin de la estructura
organizativa. Por lo tanto, crean una organizacin matricial y asignan a los individuos para
gestionar "reas de proceso estndar". A estos individuos (responsables de procesos) se les pide
que examinen todos los departamentos de la empresa e identifiquen todos los lugares donde se
llevan a cabo las actividades que podran estandarizarse. La figura 5.9 muestra la matriz
desarrollada en el curso de un esfuerzo de este tipo

En la figura 5.9 hemos convertido a la organizacin funcional tradicional en su lado, de modo

que las divisiones y departamentos de la compaa funcionan de izquierda a derecha. En la parte
superior nos imaginamos a los gerentes de procesos y mostramos cmo sus preocupaciones
recorren todas las divisiones y departamentos. A primera vista, esto podra parecer una
organizacin matriz que se organiza alrededor de unidades funcionales y procesos. Considere,
sin embargo, que la compaa tiene ms de una cadena de valor. Una divisin vende artculos
de los productos bsicos a los hospitales mientras que otro construye las plantas de la refinera,
que entonces vende a otras organizaciones. Estas actividades son tan diferentes que tienen que
ser cadenas de valor separadas. Si queremos seguir a Porter y Rummler, trataremos de integrar
todos los procesos dentro de una nica cadena de valor alrededor de una nica estrategia para
asegurar que la cadena de valor, como un todo, sea lo ms eficiente posible. Para lograr esto, el
gestor de procesos es el responsable de toda la cadena de valor. En el ejemplo mostrado en la
Figura 5.10, el gerente de divisin responsable de la divisin de Ingeniera de Refinera de
Clientes est mejor posicionado para perseguir esa meta que el Gerente de Proceso de Ventas.
Del mismo modo, el gerente de divisin responsable de Productos Hospital estn mejor
posicionados para optimizar la cadena de valor del Producto Hospital que el gerente de Proceso
de Ventas.

Nuestro modelo general representa una funcin de gestin operativa y describe las actividades
que un gestor de procesos debe realizar. El proyecto se extiende agregando un proceso para
definir la naturaleza del proyecto especfico a ser gestionado (Iniciacin) y otro que critica el
proyecto y recoge las cosas que fueron aprendidas en el curso del proyecto (Cierre).

El modelo CMMI de SEI

El ms conocido de todos los modelos de madurez es el Capability Maturity Model Integrated

(CMMI) del Instituto de Ingeniera de Software. Aunque CMM fue desarrollado originalmente
para evaluar departamentos de TI, la versin extendida, CMMI, est diseada para ayudar a las
empresas a evaluar y mejorar cualquier tipo de proceso de negocio. CMMI apoya dos formas de
organizar su esfuerzo. Puede analizar las capacidades de un departamento o grupo de
profesionales o puede centrarse en la madurez general de una organizacin. La primera, que se
centra en Capability Levels, busca ver qu habilidades estn presentes y luego se enfoca en
ensear a los gerentes o profesionales del proceso las habilidades que faltan. La segunda, que
se centra en los niveles de madurez, asume que las organizaciones se vuelven ms expertas en
procesos de una manera sistemtica y organizada y se enfoca en identificar el estado en el que
la organizacin est ahora y luego proporcionar las habilidades que la organizacin necesita para
pasar a la siguiente etapa superior. Obviamente, si se enfoca en la madurez organizacional,
entonces CMMI funciona como una metodologa de mejora de procesos empresariales que
proporciona una receta para una secuencia de cursos de capacitacin de procesos diseados
para proporcionar a los gerentes de procesos las habilidades que necesitan para administrar su
proceso ms eficazmente. Si se centra en la unidad de trabajo individual y hace hincapi en las
capacidades, CMMI proporciona un conjunto de criterios para evaluar cmo son sofisticados los
gestores de procesos especficos y determinar qu procesos de gestin necesitan dominar para
gestionar ms eficazmente el proceso especfico que est intentando mejorar.

Independientemente del enfoque que utilice, una vez completada la evaluacin bsica, se centra
en los procesos de gestin que deben ser adquiridos por los gerentes de la organizacin o en las
actividades que necesitan las personas responsables de mejorar los procesos existentes de la
organizacin.

Aunque CMMI no pone tanto nfasis en los tipos de administracin como podramos, una forma
de organizar sus procesos se basa en el tipo de gerente que necesitar dominar el proceso. As,
definen algunos procesos de gestin para los gestores de operaciones (que denominan gestin
de procesos), un segundo conjunto de procesos para gestores de proyectos y un tercer conjunto
para gestores de ingeniera y soporte que gestionan procesos de habilitacin o soporte. La figura
5.11 muestra cmo CMMI definira los diversos procesos de gestin y mostrar en qu nivel de
madurez organizacional los administradores de la empresa normalmente requeriran la
capacidad de utilizar dichos procesos. Esto ayudar a entender la clasificacin de CMMI si se
tiene en cuenta que los gerentes operacionales cotidianos necesitan administrar mejoras de
rutina en los procesos, pero que se llevan a cabo cambios importantes como proyectos y que un
grupo de BPM que mantena una arquitectura o proporcionaba Black Belts para un esfuerzo
especfico del proyecto seran un grupo de apoyo. Dicho de otro modo, el objetivo de CMMI es
mejorar los procesos, pero su principal suposicin es que los procesos se mejoran a medida que
se definen, se ejecutan de manera consistente, se mide y, como resultado de la medicin, se
mejora sistemticamente. En ltima instancia, poner estos elementos en su lugar y ejecutarlos
en el da a da es la responsabilidad de la persona que est administrando el proceso.

Estas son las definiciones que CMMI proporciona para su proceso de gestin "reas de proceso".

OPD ~ Proceso de Definiciones de Procesos Organizativos. Establecer y mantener un

conjunto utilizable de activos de procesos de organizacin y estndares de ambiente de
trabajo.
OPF ~ Proceso Organizacional Proceso de enfoque. Planificar, implementar e
implementar mejoras de procesos organizacionales basadas en un conocimiento
profundo de las fortalezas y debilidades actuales de los procesos y activos de proceso
de la organizacin.
OT - Proceso de formacin organizacional. Proporcionar a los empleados con las
habilidades y conocimientos necesarios para desempear sus funciones de manera
eficaz y eficiente. Incluye: identificar la capacitacin que necesita la organizacin,
obtener y proporcionar capacitacin para atender esas necesidades, establecer y
mantener la capacidad de capacitacin, establecer y mantener los registros de
capacitacin, y evaluar la efectividad de la capacitacin.
OPP ~ Proceso Organizacional Proceso de desempeo. Establecer y mantener una
comprensin cuantitativa del desempeo del conjunto de procesos estndares de la
organizacin en apoyo de los objetivos de calidad y rendimiento del proceso, y
proporcionar los datos de rendimiento del proceso, las lneas de base y los modelos para
gestionar cuantitativamente los proyectos de la organizacin.
OID ~ Innovacin Organizacional y Proceso de Implementacin. Seleccionar e
implementar mejoras incrementales e innovadoras que mejoren de manera
cuantificable los procesos y tecnologas de la organizacin.

Si asignramos este subconjunto particular de los procesos de gestin operativa a nuestro

modelo de gestin general, parecera algo como lo que representamos en la figura 5.12. Hemos
colocado nmeros al frente de los procesos para sugerir que en el nivel de madurez 3 se
esperara que un gerente tuviera las capacidades identificadas como (3). A medida que el
individuo o la organizacin madur y alcanz el nivel 4, se supone que el gerente haba
dominado los procesos (4) y en el nivel 5 que l o ella habra dominado los (5) procesos.
El Marco SCOR del SCC

El Consejo de la Cadena de Suministros se centra principalmente en definir los procesos bsicos

que conforman un sistema de cadena de suministro. Al mismo tiempo, sin embargo, tienen un
proceso genrico llamado Plan. Para cada proceso de la cadena de suministro, como Fuente,
Marca, Entrega o Devolucin, requieren que el modelador agregue un proceso del Plan. De
hecho, requieren una jerarqua de los procesos del Plan, creando de hecho una imagen del
esfuerzo de gestin del proceso requerido para un proceso de cadena de suministro.

La figura 5.13 muestra cmo los analistas de SCOR modelaran una cadena de suministro simple.
Para simplificar las cosas, slo mostramos los procesos de Plan para la fila superior de procesos.
Dentro de Alpha hay dos departamentos, que estn separados por la lnea de trazos. Dentro de
cada departamento hay procesos de origen, fabricacin y entrega. Hay un proceso de Plan para
cada uno. Adems, hay un proceso de Plan para todos los procesos de Plan Source, Plan Make y
Plan Deliver dentro de un departamento dado.
El SCC define cuatro subprocesos para su proceso de Plan, que varan ligeramente, dependiendo
del proceso central que estn soportando. Los subprocesos Plan Make incluyen:

PM1. Identificar, priorizar y agregar los requisitos de produccin

PM2. Identificar, evaluar y asignar recursos de produccin
PM3. Balance de los recursos del producto y los requisitos
PM4. Establecer planes de produccin

Aunque no representan los procesos en sus diagramas de subprocesos, el marco SCOR de SCC
tambin define un proceso de habilitacin y luego define los subprocesos habilitados. Estos son
los ocho subprocesos Habilitar hacer:

EM1 Administrar reglas de produccin

EM2 Gestin del rendimiento de la produccin
EM3 Gestionar datos de produccin
EM4 Gestionar inventario de produccin en proceso
EM5 Manejo de equipos e instalaciones
EM6 Administrar Hacer Transporte
EM7 Gestionar Red de Produccin
EM8 Manejo de Cumplimiento Normativo de Produccin

La lista de subprocesos refleja el papel ms especializado del gestor de la cadena de suministro.

Adems, mientras que un gestor de proceso de proceso de nivel inferior podra no estar
preocupado por algunos de estos subprocesos, los administradores de cadenas de suministro
de nivel superior lo haran y esto refleja el hecho de que SCOR describe no slo el trabajo de los
gerentes inmediatos de un proceso, El trabajo que el jefe del gerente tendr que hacer.

El SCC decidi centrarse en los procesos de gestin que son ms intensivos en el conocimiento
y, por lo tanto, no incluye cosas como asignar a las personas a las tareas, el seguimiento de la
produccin o proporcionar a los empleados retroalimentacin.

En la figura 5.14 se presenta una visin general de cmo se correlacionan los procesos de gestin
de SCOR con nuestro modelo general. Aunque no hemos intentado mostrarlo en la Figura 5.14,
los procesos de gestin de SCOR son un poco ms sutiles, ya que los desarrolladores de SCOR
saban exactamente qu proceso central cada conjunto de procesos Plan y Enable acabara
soportando. Por lo tanto, podramos haber intentado mostrar cmo los subprocesos especficos
de Plan y Habilitar SCOR, de hecho, apoyan la planificacin de insumos para Hacer o tratar de
gestionar la relacin entre Hacer y apoyar procesos.

El Marco COBIT de ITGI

El IT Governance Institute (ITGI) desarroll su marco de procesos para organizar la gestin de

los procesos de TI. Sus procesos de gestin de TI de alto nivel se asignan fcilmente a nuestro
modelo de gestin general. (Vea la Figura 5.15.)

El ITGI ha definido subprocesos para cada uno de sus procesos y los subprocesos tambin
reflejan nuestro modelo general. As, por ejemplo, los subprocesos ITGI para Planear y Organizar
(PO) incluyen:

PO 1 Definir un plan estratgico de TI

PO2 Definir una arquitectura de TI
PO3 Definir Direccin Tcnica
PO4 Definir Procesos de TI, Organizacin y Relaciones
PO5 Administrar la inversin en TI
 PO6 Comunique los Objetivos y Direcciones de la Direccin
PO7 Gestin de Recursos Humanos de TI
PO8 Gestionar la calidad
PO9 Administrar Proyectos

Al examinar los subprocesos, nos damos cuenta de que los procesos de gestin de COBIT son
ms apropiados para un CIO o un administrador senior de TI y no para el administrador de las
aplicaciones de mantenimiento de ERP, y mucho menos para el responsable del proceso de
mantenimiento de ERP para la contabilidad.

Por otra parte, una revisin de la documentacin de COBIT muestra que COBIT no slo define
procesos de gestin de TI de alto nivel, sino que define metas para la organizacin de TI como
un todo y luego muestra cmo los diferentes procesos de gestin de TI pueden vincularse a los
objetivos de TI y Procede a definir mtricas para cada proceso de gestin.

No hemos entrado en ninguno de los diversos marcos de gestin de procesos en ningn detalle.
Para nuestros propsitos, basta con que los lectores deben saber que muchos grupos diferentes
estn trabajando para definir los procesos que los gerentes utilizan cuando manejan procesos
especficos. Algunos grupos se han centrado en las actividades, habilidades y procesos que un
administrador necesitara para gestionar un proceso en curso, y otros se han centrado en las
actividades, habilidades y procesos que un administrador necesitara para gestionar un
proyecto. Algunos se han centrado en las actividades de los gerentes de procesos y otros se han
centrado en los gerentes que son responsables de procesos bsicos muy especficos. Como
sugerimos anteriormente, la definicin de la gestin de procesos es difcil. Diferentes personas
han seguido enfoques alternativos. Algunos simplemente diagnostican lo que los gerentes
especficos estn haciendo mal mientras buscan maneras de mejorar el desempeo de un
proceso defectuoso. Otros se enfocan en los procesos y actividades reales que los gerentes
efectivos necesitan dominar para planificar, organizar, comunicar y monitorear y controlar el
proceso que son responsables de administrar.

Las organizaciones que se centran en los procesos gerenciales por lo general tienden a
establecer programas de capacitacin en gestin de procesos para ayudar a sus gerentes a
adquirir las habilidades que necesitan para desempearse mejor.

Documentacin de procesos de gestin en una arquitectura

La mayora de las organizaciones no documentan el proceso de gestin en su arquitectura formal

de procesos de negocio. Si piensa en todos los procesos operativos como siempre teniendo un
proceso de gestin asociado, entonces parece innecesario documentar los procesos de gestin.
Si los procesos de gestin cotidiana estn documentados, por lo general se documentan como
procesos estndar genricos que se supone que cada administrador utilizar. Si este es el
enfoque de la empresa, entonces usar uno de los marcos descritos como una fuente de
informacin y definiciones es una manera razonable de proceder. La mayora de las
organizaciones identifican procesos de gestin de alto nivel que son independientes de
cualquier cadena de valor especfica y los documentan de forma independiente. Por lo tanto,
una organizacin podra documentar el proceso de formulacin de estrategias o los procesos de
un grupo de apoyo de gestin de procesos de negocio. Otros tratan estos procesos
especializados como procesos de soporte y los documentan de la misma manera que
documentan otros procesos de soporte. Sin embargo, su empresa decide abordar la
documentacin, los procesos de gestin describen conjuntos de actividades que los
administradores de procesos deben dominar, y por lo tanto, deben proporcionar una buena
base para un programa de capacitacin de gestor de procesos.

Completar la Hoja de trabajo de arquitectura de procesos empresariales

Recuerde que la hoja de trabajo Anlisis de Arquitectura de Nivel 1 proporciona un espacio en

la parte superior para el nombre del gestor de la cadena de valor (vea la Figura 4.2). A
continuacin, se le pidi que introdujera cada proceso de Nivel 1 e identificara al gerente de
cada uno de los procesos del Nivel 1. Luego se le pidi que completara una hoja de trabajo para
cada proceso de Nivel 1 en el que list los procesos de Nivel 2 que conforman el proceso de
Nivel 1 y se le pidi que identificara a los gerentes responsables de cada proceso de Nivel 2. En
nuestra experiencia, la mayora de las empresas pueden identificar a los gerentes de sus
procesos de Nivel 2 o Nivel 3 sin demasiados problemas. Tienen problemas con la identificacin
de los gerentes responsables de las cadenas de valor y de los procesos de Nivel 1. Si usted
recuerda a nuestro supervisor de ventas en la Figura 5.7, ese individuo era tanto un gerente de
unidad como un gerente de proceso, y l o ella sera fcil de identificar en la mayora de las
organizaciones. Es el encargado del proceso quien es responsable de los procesos que cruzan
los lmites tradicionales que son ms difciles de identificar. En muchos casos, no existen. Sin
embargo, son los nicos administradores que pueden asegurar que los procesos a gran escala
de su organizacin funcionen como deberan. Son los administradores que se concentran en
integrar toda la cadena de valor y alinear la cadena de valor con la estrategia de su organizacin.
Son los gestores que estn realmente centrados en las medidas externas de la cadena de valor
y satisfacen al cliente. La mayora de las organizaciones estn comenzando a ordenar cmo van
a manejar los procesos en los niveles ms altos de la organizacin, pero es en estos niveles que
se van a obtener grandes ganancias y que se obtendr una ventaja competitiva. En ltima
instancia, este es el trabajo de los altos ejecutivos de su organizacin. Si creen en el proceso,
entonces este es un desafo que deben abordar.

Notas y referencias

Una vez ms, muchas de las ideas incorporadas en la metodologa BPTrends se derivan de las
conversaciones que Roger Burlton y yo hemos tenido. Y la mayora de mis ideas sobre la relacin
entre los gerentes de procesos y los procesos derivan de conversaciones an ms tempranas
con Geary Rummier.

Hay muchas maneras de clasificar las tareas bsicas que un gerente debe realizar. Trabaj por
un tiempo para Louis Allen y me familiaric mucho con su sistema. Ciertamente he estudiado a
Drucker, y mi favorito personal es Mintzberg. Y, por supuesto, he estudiado los papeles de Geary
Rummler sobre la gestin de procesos. Todos ellos segmentan las tareas de manera ligeramente
diferente, pero el punto clave es que los gerentes realizan actividades para facilitar y controlar
el trabajo de los dems.

Drucker, Peter E, Management: Tasks, Responsibilities, Practices, Collins, 1993.

Allen, Louis A., Principles of Professional Management, Louis Mien Associates (2nd), 1978. En
los mediados de los aos 70 trabaj brevemente para Louis A. Allen, entonces consultor de
gerencia popular. Por lo que s, sus libros ya no estn impresos, pero me present la idea de
que los gerentes deben planificar, organizar, dirigir y controlar. He simplificado en este captulo
la planificacin y el control.

Mintzberg, Henry, The Nature of Managerial Work, Prentice Hall, 1973.

Muchas empresas intentaron la gestin de la matriz en los aos setenta y le result muy difcil
coordinar, y la dejaron caer. La mayora de las empresas lo estn haciendo hoy ~ gerentes
individuales estn informando a ms de un jefe ~, pero nadie parece querer llamarlo gestin de
la matriz. Pero no parece haber otro nombre popular para la prctica, por lo que he denominado
gestin de la matriz.

El Project Management Institute (PMI) ha desarrollado un excelente marco para la gestin de

proyectos. Confiamos en ellos para su descripcin de la estructura organizativa, que sugieren
que va desde la gestin funcional a la gestin de proyectos, con etapas de gestin de la matriz
en el medio. Y tambin discutimos su modelo de madurez de gestin PMI. Para obtener ms
informacin, consulte su sitio Web: www.pmi.org. El mejor libro para una descripcin general
de su modelo de madurez es:

Bolles, Dennis L. and Darrel G. Hubbard, The Power of Enterprise-Wide Project Management,
AMACOM, 2007 Entre otros.
Captulo 6

CHAPTER 6: Medicin del rendimiento del proceso

Este captulo se centra en la medicin del rendimiento del proceso en toda la organizacin.
Cada organizacin realiza un seguimiento de su rendimiento de alguna manera. Algunos tienen
sistemas de medicin de desempeo muy elaborados que les permiten determinar lo que est
ocurriendo en tiempo real, mientras que la mayora rastrea una amplia variedad de medidas y
las revisa al final de cada semana o mes. Se sostiene extensamente que la informacin del
funcionamiento es un diferenciador dominante y que las organizaciones que pueden obtener y
utilizar la informacin sobre sus mercados y sus procesos en una manera oportuna pueden
funcionar mejor. Por lo tanto, no es sorprendente que las empresas estn invirtiendo grandes
cantidades de dinero en el desarrollo de nuevos y ms elaborados sistemas de monitoreo del
desempeo.

Histricamente, hubo una gran desconexin entre lo que los ejecutivos estaban preocupados y
en lo que los gerentes operacionales se enfocaban. Como una generalizacin, los ejecutivos
estaban interesados en los informes financieros y en el rendimiento de las acciones de la
compaa.
Todos estn de acuerdo en que estos son indicadores de desempeo clave, pero surgen
problemas cuando la organizacin intenta traducir estas medidas en medidas ms concretas
que se pueden aplicar a la comercializacin, la fabricacin o la contabilidad. Los gerentes
operacionales estn ms centrados en la eficiencia y eficacia de actividades especficas, en la
calidad de los productos y servicios, y en la satisfaccin del cliente. Las unidades funcionales se
establecieron, histricamente, porque representan formas lgicas de dividir el trabajo y
administrar las habilidades especializadas que las empresas necesitan para alcanzar sus metas.
Sin embargo, no existe una relacin clara entre las unidades departamentales que existen en la
mayora de las empresas y los resultados y medidas que la mayora de los ejecutivos siguen
con mayor cuidado. Esta es una de las razones para el cambio a los directores de divisin y de
lnea de productos y para la instalacin de gestores de procesos que son responsables de
cadenas de valor enteras. Cuando uno mira una lnea completa de productos o una cadena de
valor completa, uno est en una posicin mucho mejor para ver cmo los cambios en el
resultado de trabajo en aumento o disminucin de costos o ventas.

QU ES LA MEDICIN?
Empezaremos con algunas definiciones de los trminos de medicin populares, y luego
procederemos a una discusin sobre cmo se pueden medir los procesos.

Metas, mtricas, medidas y KPIs

La mayora de las empresas comienzan su trabajo de estrategia con una declaracin de
visin. Luego escriben un documento ms detallado que describe su declaracin de
estrategia en una serie de objetivos. Los objetivos definen las cosas especficas que la
empresa tendr que hacer para realizar su estrategia. Estos objetivos estratgicos a
menudo se llaman factores crticos de xito. As, por ejemplo, la estrategia puede
requerir crecimiento del mercado. Un objetivo especfico puede requerir un aumento del
15% en las ventas en el prximo ao fiscal.
Ya hemos mencionado el hecho de que a menudo hay un problema para traducir los objetivos
estratgicos en objetivos funcionales. Un aumento del 15% en las ventas es un objetivo
relativamente fcil de alinear, pero todava requiere un cierto pensamiento. Por ejemplo, si
vamos a aumentar las ventas de Widget en un 15%, vamos a tener que fabricar un 15% ms de
Widgets para cumplir con los pedidos, lo que significa que necesitaremos adquirir un 15% ms
de piezas para el montaje de Widget. Tambin puede significar que el grupo financiero del
Widget debe estar preparado para financiar un inventario mayor por un tiempo. En otras
palabras, debemos estar seguros de que alineamos los objetivos a lo largo de toda la cadena
de valor. Considerar qu sucedera si un objetivo exiga un aumento del 15% en las ventas y
otro requera una reduccin del 10% en los costos de la manufactura. En el peor de los casos,
el grupo de fabricacin podra decidir recortar el inventario, que siempre es caro, y encontrar
que es incapaz de cumplir con un fuerte aumento en las ventas de Widget al final del
trimestre, cuando todas las nuevas rdenes de venta lleguen.

La mayora de las organizaciones comienzan con una serie de objetivos estratgicos y luego
generan muchas metas y medidas adicionales. A menudo, el departamento de ventas puede
tener una serie de medidas diferentes que utiliza para determinar si los vendedores estn
haciendo su trabajo en la forma prescrita por los procedimientos de ventas del departamento
manual.

El seguimiento medidas cuesta dinero y lleva tiempo y, finalmente, demasiada informacin es

tan confuso como demasiado poco. La mayora de las empresas tienen alguna forma de
discriminar entre todas sus medidas de rutina y las que son realmente importantes. Las
medidas importantes se denominan a veces indicadores clave de rendimiento (Key
performance indicator) (KPIs). Es importante considerar una amplia variedad de medidas
diferentes y luego establecerse en unos KPIs para ver muy de cerca.

Por ltimo, es fundamental que los ejecutivos entiendan que normalmente obtendrn lo que
decidan medir. Los gerentes y los empleados saben qu nmeros los ejecutivos senior
consideran ms importantes. Todo el que quiera salir adelante se centrar en "hacer los
nmeros". Si una medida es mal elegida o si tiene efectos secundarios no deseados, entonces
el rendimiento corporativo sufrir. Por lo tanto, el tiempo dedicado a desarrollar y seleccionar
buenas medidas y alinearlas con los objetivos corporativos suele ser un tiempo bien empleado.

Medidas internas y externas (Internal and External Measures)

Hay muchas, muchas formas diferentes de hablar de mtricas y medidas. Queremos comenzar
con una distincin crtica, y usar trminos simples para asegurar que la distincin sea clara. Las
medidas externas (medidas desde el exterior) le informan sobre los resultados obtenidos por
un proceso o cadena de valor. Las medidas internas (medidas desde el interior) le informan
sobre los resultados obtenidos por los subprocesos o las actividades dentro del proceso o de la
cadena de valor.
La figura 6.1 proporciona una visin general de la distincin. Obsrvese que el nfasis est en
la cadena de valor, y no en los procesos en general. El proceso C en la cadena de valor que se
muestra en la figura 6.1 tiene una salida. Podramos medir la produccin del Proceso C, aparte
de cualquier medida que pudiramos establecer con respecto a las actividades internas del
Proceso C, pero esa medida de la produccin no es una medida externa como estamos usando
el trmino aqu.
Figura 6.1 Medidas externas e internas del desempeo del proceso

Si estamos centrados en la organizacin, entonces el cliente est fuera de la organizacin.

Podemos aplicar este mismo concepto dentro de una organizacin, si consideramos
simplemente cualquier proceso que recibe los productos de otro proceso como su cliente. As,
en la figura 5.3, vemos que los procesos pueden ser tanto el proveedor de un proceso como el
cliente de otro.
En este caso, el Proceso D tiene dos clientes externos, Procesos E y F. Antes de que el gerente
del Proceso D considere examinar cualesquiera medidas internas que se usen para evaluar el
Proceso D, debe asegurarse de que los productos del Proceso D satisfagan a sus clientes. E y el
proceso F. La lgica aqu es la misma que en el nivel de la empresa. No tiene sentido disminuir
el costo o aumentar la productividad del Proceso D si, como resultado, el proceso ya no es
capaz de entregar los productos o servicios que proporciona a los Procesos E y F. Una vez que
las medidas externas son Definido y est claro que el Proceso D puede cumplir
constantemente con sus compromisos externos, entonces, mientras mantiene sus medidas
externas constantes, el gerente de procesos debe enfocarse en mejorar las medidas internas.

Figure 6.2 Los "clientes" internos son externos a los procesos que los suministran.

Las medidas externas son las medidas definitivas de si su empresa o proceso tiene xito.
Centrndose en la compaa por el momento, ejemplos de medidas que podramos querer
examinar incluyen:
 Medidas externas
Medidas de ingresos
Medidas de satisfaccin del cliente
Medidas de crecimiento del mercado
Satisfaccin de los accionistas u otras medidas externas de la confianza del mercado burstil
en lo que la empresa est haciendo
Medidas internas
Eficiencia y efectividad de funciones o subprocesos especficos
Costos de produccin del producto o servicio
Calidad de las salidas internas

Por lo general, es ms fcil definir o medir mtricas internas que medir resultados externos.
Adems, la mayora de las unidades funcionales tienden a centrarse en medidas internas. De
hecho, como veremos en un momento, uno se centra a menudo en medidas internas porque
son indicadores principales y proporcionan a los gerentes informacin valiosa. En ltima
instancia, sin embargo, para evaluar eficazmente el desempeo de una organizacin, debe
centrarse en las medidas externas. Una vez que "bloquear" las medidas externas, entonces
usted puede comenzar a centrarse en la mejora de sus medidas internas, con la confianza de
que cualquier eficiencia que se logra resultar en un beneficio real para la organizacin. Sin
embargo, si no bloquea las medidas externas primero, corre el riesgo de mejorar la eficiencia
interna o reducir los costos de produccin a expensas de la satisfaccin del cliente, el
crecimiento del mercado o el precio de la accin de la organizacin. Sabemos de una empresa
que hizo exactamente eso. Anunciaron que los bonos dependeran de un recorte del 20% en
los costos. Los costos disminuyeron y las quejas de los clientes se dispararon.Los productos se
entregaron tarde, tenan ms defectos, y el servicio se hizo ms difcil de obtener. La compaa
rpidamente detuvo su campaa para reducir los costos e instituy un programa que mide la
satisfaccin del cliente. Una vez que el programa estaba en su lugar y los gerentes estaban
recibiendo informes mensuales sobre la satisfaccin del cliente, la compaa restableci la
unidad de reduccin de costos, dejando claro que la satisfaccin del cliente era primero, y los
recortes de costos eran deseables, pero los bonos slo se dara para las unidades que Reducir
costos y mantener la satisfaccin del cliente.

Indicadores Principales (Lideres) y Retardados (Retrasados o Rezagados)

Existen los indicadores principales que son medidas que informan sobre situaciones sobre las
que se puede realizar una accion y los indicadores rezagados que describen situaciones que no
pueden ser cambiadas.

Imagine que es un gerente de ventas de Widgets, Inc. La junta directiva tiene un objetivo
especfico: La compaa aumentar sus ventas en un 15% cada trimestre del ao. Puede
esperar hasta el final del trimestre y luego determinar cuntos Widgets ha vendido. Esta
medida es un indicador rezagado. Una vez que el trimestre haya terminado usted no sabr si
logr su objetivo o no, pero no podr cambiar los resultados. Ahora supongamos que usted ha
estado rastreando sus ventas de Widget durante algn tiempo y sabe que aproximadamente el
10% de sus clientes potenciales normalmente dan lugar a prospectos calificados y que sus
vendedores normalmente pueden organizar llamadas con la mitad de las perspectivas
calificadas. Tambin sabes que tus vendedores venden Widgets al 20% de los clientes a los que
llaman. La Figura 6.3 ilustra el ciclo de ventas Widget que acabamos de describir.
Seguimiento -> entiendase como el trato cte a los clientes

Si usted sabe que sus vendedores estn programados para hacer 100 llamadas de ventas este
trimestre, puede predecir que va a hacer alrededor de 20 ventas. Por lo tanto, las llamadas de
ventas programadas es un indicador lder de ventas exitosas. Sin embargo puede que no le d
mucho tiempo para hacer correcciones. El mejor indicador lder, en este caso, sera rastrear
las derivaciones. Un clculo rpido muestra que para aumentar sus ventas en un 15% en un
trimestre, tendr que aumentar su seguimiento en un 15%. Si realiza un seguimiento de los
clientes potenciales por mes, lo sabr al final del primer mes del trimestre si est en camino. Si
no lo es, tendr que aumentar drsticamente la eficacia de su proceso de generacin de
seguimiento en el segundo mes o ser poco probable que cumpla su objetivo.

Balanced Scorecard y medidas del proceso

El enfoque Balanced Scorecard (Kaplan y Norton) es muy popular como una herramienta para
definir las responsabilidades de gestin y para alinear las metas y medidas utilizadas para
evaluar el desempeo de los gerentes.

Kaplan y Norton argumentaron que los altos ejecutivos deberan establecer un cuadro de
mando que tomara en cuenta mltiples medidas. Propusieron un Balanced Scorecard que
consideraba cuatro tipos de medidas:

Medidas financieras: Cmo miramos a los accionistas?

Medidas internas de negocios: Qu deberiamos hacer en Excel?
Innovacin y medidas de aprendizaje: Podemos continuar mejorando y creando
valor?
Medidas del cliente: Cmo nos ven los clientes?

La figura inferior ilustra un cuadro de mando de una compaa hipottica discutido en el

artculo de enero-febrero de 1992 de Kaplan y Norton en Electronic Circuits Inc (ECI).
Muchos de los primeros tericos del proceso de negocios enfatizaron la importancia de la
medicin, pero no proporcionaron detalles sobre cmo lograrlo. Luego, se hizo popular para
los gurs de los procesos de negocios el mencionar el Balanced Scorecard cuando se les peda
explicar cmo alinear las estrategias, los procesos y las medidas.

Kaplan y Norton ofrecieron una visin general de cmo se podra vincular el cuadro de mando
integral con las estrategias corporativas. El patrn general es familiar para cualquiera que haya
trabajado en estrategia y medicin. El aspecto particular que refleja la contribucin de Kaplan
y Norton es el nfasis en definir cuatro tipos diferentes de estrategias y generar cuatro tipos
diferentes de medidas como se observa en la siguiente imagen.

Figura 6.5

En los aos noventa muchos gerentes de alto nivel estaban dependiendo demasiado de las
medidas financieras, y el Balanced Scorecard surgi como un modelo ordenado que sugiri
cmo podran confiar en otras medidas, incluidas las medidas del proceso y la satisfaccin del
cliente.

En 2000, Kaplan y Norton ampliaron su descripcin de cmo alinear medidas y objetivos

estratgicos. Sugieren lo que denominan "Mapas de Estrategias de Balanced Scorecard". En
esencia, introducen un modelo jerrquico que sugiere que algunas medidas contribuyen a
otras y se resumen en el valor para el accionista. La Figura 6.5 resume la idea detrs de los
Mapas de Estrategia de Balanced Scorecard.

Un problema que tenemos con la Figura 6.5 es que hemos pasado de la idea de que los altos
directivos no deben basarse exclusivamente en medidas financieras, sino en cuatro conjuntos
equilibrados de medidas, en la idea de que hay una jerarqua de medidas y de que las medidas
financieras estn en la cima. Es fcil imaginar que algunos ejecutivos examinarn la figura 6.5 y
concluirn que simplemente pueden monitorear las medidas financieras y dejar el resto a los
gerentes de nivel inferior. La idea bsica del Balanced Scorecard es muy til, pero debera estar
ms estrechamente vinculada a una visin de proceso de la organizacin. Desde una
perspectiva de proceso, las actividades estn directamente relacionadas con la satisfaccin del
cliente. Romperlos y ordenarlos de una manera jerrquica refleja una mentalidad funcional o
departamental. Vale la pena sealar que muchas organizaciones que han adoptado el enfoque
de Balanced Scorecard por lo general lo hacen mediante la conceptualizacin de los diferentes
cuadros en la tarjeta de puntuacin como la responsabilidad de las diferentes unidades
funcionales. As, las ventas y la comercializacin generan los objetivos y las medidas para la
perspectiva del cliente mientras que las operaciones, manufactura generalmente generan las
metas y las medidas para la perspectiva interna del negocio (o del proceso). La Tabla 6.1 ilustra
algunas medidas funcionales y de proceso tpicas.

Comparacin de algunas medidas funcionales y de proceso.

Typical departmental
Department or function Typical process measures
measures
Sales department Cost of sales Timely and accurate submission
Revenue($) of orders
Timely and accurate entry of new
orders
Cost of processing orders

Production department Cost of inventory Timely order scheduling

Cost of labor Timely and accurate production
Cost of materials of orders
Cost of shipping Timely shipment of orders
Cost of unit production and
shipping costs

Finance department Percent of bad Timely and accurate invoice

debt preparation
Mean labor budget Timely and accurate credit
checks for new accounts
 Cost of processing an invoice

External organizational Gross revenue Percent of on-time delivery

measures Cost of sales Percent of rejects
Growth of Customer satisfaction as
customer base measured on survey or index
Price of stock

Resumen:

Balanced Scorecard tiende a apoyar y consolidar la especializacin funcional. Hay un enfoque

donde las organizaciones orientadas al proceso han comenzado a explorar el uso del Cuadro de
Mando Integral este enfoque supone que un solo gerente est siendo evaluado y responsable
para un proceso esto requiere que el mismo gerente tenga dos partes para cada rea de
perspectiva. Una parte de cada rea de perspectiva refleja las preocupaciones de la unidad
funcional. La otra parte de la zona refleja las preocupaciones del gestor de procesos o de la
cadena de valor.

Una vez que una organizacin comienza a dividir las medidas de desempeo la organizacin est
en una posicin mucho mejor para decidir qu tipo de metas y responsabilidades un gerente
debe lograr para cumplir su funcin como gerente de proceso y de la unidad.

Alinear las medidas del proceso

Enfoque completamente diferente para alinear las metas y medidas del proceso, la organizacin
tiene una divisin que se centra en la produccin de una lnea de productos especficos o puede
ser una empresa que se organiza en torno a emprender proyectos

Figura
6.9

Usando un diagrama como el que se muestra en la Figura 6.9 podemos alinear nuestras medidas
de proceso "respaldando" en el proceso y escribiendo "contratos" que definen las relaciones
entre cada uno de los procesos y subprocesos en la cadena de valor. La figura 6.10 muestra cmo
podramos descomponer los procesos representados en la figura 6.9.

Figura 6.10
Una visin general de una cadena de valor de Boeing que produce aviones C-17 para la Fuerza
Area de Estados Unidos, descompuestos en niveles.

Este proceso de alineacin puede ser conducido a cualquier nivel arbitrario en la jerarqua del
proceso. Toda una cadena de valor y todos sus procesos y subprocesos pueden estar vinculados
por conjuntos de contratos que definen lo que cada proceso operacional debe hacer para
asegurar que el proceso descendente (cliente). Otros gestores de procesos pueden escribir otros
contratos para definir qu apoyo necesitan para cumplir con sus acuerdos de produccin.

Pone todo el nfasis en asegurar que cada gestor de procesos y subprocesos sabe exactamente
lo que se requiere y genera medidas de salida para cada proceso y subproceso. Cualquier
proceso (o gestor de procesos) que no cumpla con su contrato puede ser identificado
inmediatamente y la accin correctiva iniciada. No todas las organizaciones pueden adoptar este
enfoque, sin embargo, hace posible crear un sistema muy riguroso de medidas, todas
cuidadosamente alineadas.

Derivar medidas de los marcos de procesos empresariales

SCOR como VRM proporcionan medidas para cada uno de sus procesos. La Figura 6.11 ofrece
una visin general de las medidas para el proceso de cadena de suministro de SCOR. Las cinco
medidas SCOR de alto nivel se dividen entre medidas externas (de cara al cliente) e internas.

Figura 6.11

Si una empresa utiliza un marco como SCOR entonces puede proceder a derivar las medidas
apropiadas de los materiales de referencia de SCOR. El manual contiene las definiciones de todos
los procesos incluidos en el marco SCOR, las mtricas apropiadas para evaluar cada proceso en
cada nivel y las definiciones de cmo se calcula cada medida. SCOR define cinco atributos de
rendimiento genricos y luego sugiere mtricas apropiadas para cada atributo.

El Consejo de la Cadena de Suministro proporciona un conjunto completo de medidas para los

procesos incluidos en su Cadena de Suministro, Cadena de Diseo y Marcos de Ventas y
Marketing y trabajan con una agencia de benchmarking exterior para que las empresas que
utilizan las medidas del Consejo de Supply Chain puedan obtener Informacin de las medidas.
Para utilizarlas la organizacin necesita unirse al Consejo de la Cadena de Suministro. Una vez
hecho esto la empresa tiene libre acceso a un sistema de medicin de procesos que puede
utilizar para desarrollar rpidamente su propia arquitectura de procesos de negocio.

Poniendolo todo junto

Sistema de medicin de procesos que va desde la parte superior derecha hasta el proceso ms
pequeo de la organizacin. Utilizando contratos, el sistema Boeing GMS conecta todo y hace
posible una rastreabilidad rigurosa. . La Figura 6.12 ilustra cmo podemos alinear las medidas
financieras de alto nivel del sistema de Balanced Scorecard con medidas de nivel inferior
proporcionadas por el marco SCOR.

Figura 6.12

La figura 6.12 tambin sugiere cmo podemos superar la naturaleza en capas del modelo de
estrategia de Balanced Scorecard.

Cualquier problema con la satisfaccin del cliente se puede remontar a los productos y servicios.
A su vez, las cuestiones de aprendizaje y crecimiento se conceptualizan como recursos utilizados
por procesos especficos para producir resultados. Este enfoque proporciona un conjunto de
medidas mucho ms orientado al proceso y desva el sesgo del Cuadro de Mando Integral para
procesar y alejarse de las unidades funcionales. El uso de SCOR en conjuncin con un sistema de
Balanced Scorecard proporciona a la organizacin los medios necesarios para crear un sistema
de medicin del desempeo del proceso para alinear la evaluacin del desempeo de los
gerentes de procesos con la evaluacin general del desempeo organizacional.

Completar la Hoja de trabajo de arquitectura de procesos empresariales

Comenzamos estructurando todas Las hojas de trabajo con procesos operativos. Las hojas de
trabajo de nivel 1 definir los procesos y la de nivel 2 definir subprocesos para cada proceso de
nivel 1. En cada caso, una vez definidos los procesos, debemos identificar al gestor responsable
de cada proceso especfico y definir las mtricas o medidas que utilizaremos para determinar si
el proceso cumple sus objetivos y si el gestor hace su trabajo con eficacia.
Lectura 8

Entendiendo y determinando el alcance de los problemas en procesos

En algunas empresas lderes, un grupo corporativo de BPM utilizar la arquitectura de procesos

de negocio y se asociar a medidas de desempeo para definir y limitar el rediseo o mejoras
en los proyectos. La mayora de las organizaciones son menos maduras. En esas organizaciones
es por lo general, un gerente senior que decide si hay un problema y crea un equipo para
determinar Que puedo hacer? En esta situacin, el equipo comienza recopilando informacin.
En un esfuerzo por comprender la naturaleza del problema que concierne al gerente. En una
situacin tan informal, no se puede suponer que quien inici el proyecto entiende realmente el
problema, el gerente sabe que algo est mal, pero l o ella puede no saber exactamente qu
actividades estn causando el problema o tener una idea clara sobre la naturaleza de los
cambios que sern necesarios para resolver el problema. En esencia, la primera tarea de
cualquier equipo del proceso es tener una buena definicin de la naturaleza y alcance del
problema. Una vez que el equipo entiende el problema, tiene que considerar, de una manera
muy general, qu tipos de cambios podra hacer una diferencia. En algunos casos, el equipo debe
estar preparado para decirle al gerente que el problema no puede ser resuelto dentro del
tiempo o el presupuesto que el gerente ha sugerido. En otras palabras, la primera fase de
cualquier cambio de proceso es definir el proyecto en s, considerar las posibles soluciones, y
luego hacer una recomendacin sobre qu nivel de esfuerzo y presupuesto ser necesario para
resolver el problema.

En este captulo queremos considerar la naturaleza de los problemas de los procesos de negocio
y sugerir algunos enfoques inteligentes para analizar un proyecto de rediseo o mejora de
procesos y empezaremos con una discusin general acerca de la naturaleza de los procesos para
establecer un vocabulario comn y procederemos a considerar la naturaleza de los problemas
en los procesos que probablemente los equipos quieren encontrar. Terminaremos con una
discusin sobre las tcnicas para definir el alcance de los procesos.

QU ES UN PROCESO?

Un proceso es un conjunto limitado de actividades que se realizan, en respuesta a algn evento,

con el fin de generar una salida. Los procesos pueden ser muy simples o extremadamente
complejos. Un ejemplo de un proceso puede ser una aplicacin de software que es iniciada por
un vendedor pasando una tarjeta de crdito a travs de un lector. La aplicacin de software
procedera a transmitir informacin a un centro principal de tarjeta de crdito para determinar
si la tarjeta es vlida y la cantidad es aceptable. Tras la recepcin de una aprobacin, la aplicacin
podra disparar la impresora para imprimir un comprobante de compra que el cliente debe
firmar.

Otro proceso podra ser iniciado por una llamada de un contribuyente para ayuda en la
determinacin qu forma de impuesto utilizar. En este caso, la llamada sera contestada por una
persona que hara preguntas y luego le dira al contribuyente qu forma usar. Podemos imaginar
una descripcin general del proceso de consulta del contribuyente y cientos de casos de ellos
como dependientes fiscales responder telfonos y emprender el proceso con diferentes
contribuyentes. Otro proceso podra ser una cadena de suministro corporativa que responda a
los pedidos de los clientes mediante la generacin y entrega de productos a los clientes. El
proceso de cadena de suministro en cualquier empresa grande es complejo y fcilmente podra
subdividirse en subprocesos que contienen cientos de actividades y miles de reglas de negocio
y son implementados por empleados ubicados en todo el mundo. Entendemos que nuestra
definicin inicial es un poco vaga, pero preferimos usar la palabra "proceso" informalmente,
como el trmino se utiliza normalmente, y luego perfeccionar nuestra comprensin con algunos
adjetivos.

Una importante distincin a considerar cuando se piensa en un proceso es si funciona como un

proceso bsico u operativo, un proceso de gestin o un proceso de soporte. Lo discutimos en el
Captulo 4 cuando consideramos arquitecturas de procesos.

Niveles de procesos y niveles de anlisis

Como una generalizacin, normalmente podemos dividir la jerarqua del proceso en tres partes
y asociar problemas y tcnicas de anlisis con niveles especficos. Ampliamente, un conjunto de
las tcnicas de anlisis de procesos se utilizan para redisear o mejorar los procesos de nivel
superior. Otro conjunto se utiliza sobre los tipos de problemas de proceso que encontramos en
la mitad de la jerarqua de procesos. Y otro conjunto de tcnicas es apropiado para procesos en
la parte inferior de la jerarqua. La figura 8.3 proporciona una visin general de esta distincin
en tres partes.
Por lo tanto, la parte superior de la jerarqua de procesos suele asociarse con la arquitectura de
problemas y problemas de coordinacin entre los departamentos o las unidades funcionales. En
este caso, nos centramos en alinear las entradas y salidas y escribir contratos para especificar
qu el Proceso A necesitar entregar a su "cliente", Proceso B.

Los problemas de tamao medio generalmente ocurren en procesos administrados dentro de

un solo departamento. Los problemas a menudo requieren que los procesos sean simplificados
o las secuencias reordenadas. Los procesos que no agregan valor deben ser removidos, algunas
actividades necesitan ser automatizado.

Procesos simples y complejos

Otra forma de comenzar el anlisis de un proceso es considerar la complejidad del proceso que
va a analizar. Los procesos sencillos usualmente siguen una tendencia consistente, una bien
definida secuencia de pasos con reglas claramente definidas. Cada paso o tarea puede ser
precisamente definida y la secuencia carece de ramas o excepciones. Los procesos ms
complejos implican ramas y excepciones, por lo general definen muchas reglas y tienden a ser
ligeramente menos bien definidos. Requieren ms iniciativa de parte de los intrpretes
humanos. Los procesos realmente complejos requieren an ms iniciativa y creatividad por
parte de los intrpretes humanos. Por lo general, son procesos que no pueden ser
automatizados utilizando las tecnologas actuales. Por lo general no entrenamos a la gente a
hacer estas tareas, pero contratar a personas que ya han demostrado las habilidades creativas
o analticas necesarias. Estos procesos estn menos bien definidos, cambian con frecuencia y
evolucionan con el paso del tiempo. El desempeo acertado requiere generalmente que el
ejecutante estudie un cuerpo en evolucin de conocimientos necesarios para estar preparado
para realizar las tareas necesarias para lograr exitosos resultados. La figura 8.5 ilustra el continuo
que va desde procesos sencillos y procesos procedurales a travs de procesos ms complejos a
procesos muy complejos.

Es popular hoy en da sugerir que la naturaleza del trabajo ha cambiado en avanzadas

economas. En el pasado, era ms probable que los trabajadores participaran en el tipo de tareas
que todava se encuentran en la fabricacin de lneas de produccin y en algunas tareas
administrativas. Cada vez ms, sin embargo, los trabajadores de hoy se dedican a tareas que
requieren ms conocimientos y muchos escritores se refieren a ellos como trabajadores del
conocimiento. Para algunos, esto implica que los trabajadores utilizan computadoras para
adquirir o manipular la informacin que necesitan para hacer su trabajo, pero para otros
simplemente se refiere al hecho de que los trabajadores se desenvuelven en procesos
complejos.

La figura 8.5 representa el espacio que resulta cuando cruzamos los niveles de anlisis con la
complejidad de procesos. En el eje horizontal colocamos el continuo de la complejidad de la
tarea. A la izquierda tenemos tareas simples y repetitivas. En el centro tenemos tareas que
requieren ms habilidad y flexibilidad. En la extrema derecha tenemos tareas que son muy
complejas y requieren una considerable creatividad. En el eje vertical, hemos colocado un
continuo que abarca desde procesos de alto nivel, muy abstractos, de alto a bajo nivel, muy
concretas actividades y tareas en la parte inferior.
Problemas en procesos de negocio

Los proyectos empiezan con problemas. El desafo es descifrar la naturaleza de los problemas y
entonces considerar que tipo de intervencin puede ser requerida para resolver el problema.
Vamos a formalizar esto un poco con un modelo de resolucin de problemas - que nos referimos
como el Modelo de Gap - que hemos ilustrado en la Figura 8.6. Formalmente, un problema es la
diferencia entre lo que existe ahora y lo que deseamos. Representamos eso con dos cajas. La
caja de la izquierda se denomina el proceso existente o As-Is. La caja de la derecha se etiquetan
como el proceso rediseado o To-Be. Podemos hablar sobre el proceso existente y el de ser de
dos formas. Podemos hablar de medidas que describen el desempeo del proceso, o podemos
describir cmo funciona el proceso As-Is o To-Be. El gerente que asigna el proyecto, por ejemplo,
podra simplemente decir que la salida del proceso necesita ser duplicada, o podra decir que
los productos defectuosos necesitan ser cortados por la mitad. Del mismo modo, el gerente
podra decir que los competidores han automatizado procesos similares y necesitamos
automatizar nuestro propio proceso. Dependiendo de la situacin, el equipo del proyecto suele
terminar trabajando entre las descripciones de lo que es y lo que podra ser y entre medidas que
definen cmo funciona el proceso hoy y proponen actividades que describen cmo debe
realizarse el proceso una vez "mejorado". Nos referimos a la diferencia entre las medidas del
desempeo del proceso As-Is y el proceso To-Be como la brecha de rendimiento. Nos referimos
a descripciones de la diferencia entre cmo se hacen las cosas ahora y cmo podran o deberan
realizarse en el proceso rediseado como la brecha de capacidades.

Un problema que cualquier equipo del proyecto encontrar ser la diferencia entre las
descripciones de problemas reales y descripciones de causas o consecuencias. La Figura 8.8
sugiere algunos de los diferentes tipos de declaraciones que puede encontrar. El equipo de
proyecto se ve obligado a preguntar, a menudo varias veces: "Por qu crees que esto sucede?"
O "Por qu es esto un problema?". Hasta que el equipo est satisfecho y pueden definir
claramente el problema. A menudo las medidas o estadsticas citadas por la direccin sern
medidas de consecuencias y el equipo necesitar trabajar hacia atrs para determinar qu
problema tienen que eliminar para mejorar la medida en que la administracin debe cambiar.
Si ampliamos el modelo Gap, podemos ver que tambin proporciona un marco para pensar en
los tipos de tcnicas analticas que podramos usar para definir el problema, e incluso puede
sugerir las tcnicas de rediseo que podramos usar para resolver el problema. La figura 8.8
ilustra la relacin entre la brecha del problema y las tcnicas de rediseo e ilustra el uso del
modelo con un proyecto real.
QU ES UN PROCESO?

En algn momento durante la determinacin del alcance del proceso, tendr que elaborar una
buena visin general del proceso existente o como es. La mayora de los equipos empiezan
preguntndole a la gerencia acerca de la naturaleza del proceso. Cmo se llama, por ejemplo?.
Supongamos, a los efectos de nuestra discusin, que la gestin de una empresa de pizza, con
varias tiendas diferentes, le pide que ayude a mejorar su proceso de entrega de pizza. Desde el
principio, usted asume que el proceso que se est discutiendo es el proceso de entrega de pizza.
(Es usual mejor definir un proceso con una frase de verbo-sustantivo, por lo que mentalmente
a su vez "Pizza Delivery" proceso en "Entrega de Pizzas"). En algn momento generalmente
adquirimos ms informacin. Como mnimo, definimos las entradas que activan el proceso y las
salidas que sealan que el proceso ha concluido con xito. Al mismo tiempo, usualmente
definimos los subpasos mayores en el proceso general. Por lo tanto, en el caso de nuestro
problema de entrega de pizza, determinamos que el proceso comienza cuando los clientes
llaman para ordenar pizzas. Sus llamadas son gestionadas por un telfono que toma llamadas
para toda la ciudad y luego las encamina al respectivo almacn. El proceso real, dentro de un
almacn determinado, comienza cuando se les notifica una orden. Proceden a cocinar la pizza.
Mientras tanto, el delivery gestiona los horarios de la entrega, agrupa rdenes para que cada
ejecucin de entrega sea lo ms eficiente posible. Si el negocio es rpido, el rea alrededor de
cada tienda se divide en regiones y los deliverys son organizados de acuerdo con la regin de
modo que los camiones de entrega viajen la distancia mnimam y las pizzas son entregadas
calientes. Cuando un vehculo de entrega est disponible y un conjunto de rdenes se monta, la
entrega tiene lugar. Comentarios hechos por los gerentes sobre la disponibilidad de camiones
de reparto nos lleva a aadir esa actividad a nuestra visin general, don inciertos, en este punto,
si es para ser incluido en nuestro proyecto o no. Si alguna medida, como el tiempo requerido
por entrega, se menciona, a menudo hacemos una nota en nuestro diagrama para sugerir lo que
queremos medir. Todo esto resulta en un diagrama muy simple que captura el proceso general,
las principales entradas y salidas, y cualquier subproceso importante o medidas, como se ilustra
en la Figura 8.10. No estamos definiendo una notacin formal o un vocabulario para este tipo
de diagrama. La clave aqu es simplemente obtener una visin til de los elementos del proceso,
tal como se entiende actualmente. A medida que se desarrolla el diagrama de alto nivel del
proceso, se comparte con todos los involucrados en el proyecto, y se pregunta a la gerencia:
Describe esto el proceso que mejorar? Deberamos considerar el mantenimiento de los
camiones de reparto Deberamos mirar los problemas con el sistema telefnico? Debemos
considerar el proceso de preparacin de comida, o slo la entrega de programacin y actividades
de entrega? Nuestro objetivo en este punto no es entrar en ningn detalle, sino simplemente
determinar lo que la direccin quiere que estudiemos.

Tenga en cuenta que la administracin podra no haber considerado todas las implicaciones de
su solicitud. Pueden suponer que el problema est en la programacin de las entregas, y no
darse cuenta de que es la frecuente falta de vehculos disponibles que hace la programacin
tan ineficiente. Empezamos por determinar qu es lo que la gerencia cree que es el problema y
luego procedemos a reunir ms informacin para determinar si su comprensin es
probablemente correcta, o si tiene sentido que sugerimos cambiar el alcance del proyecto de
alguna manera. Una vez que tengamos una descripcin inicial del problema, hablamos con las
personas involucradas con el proceso para refinar nuestra comprensin del proceso e
identificar problemas probables. En todos los casos estamos tratando de refinar nuestra
comprensin de las medidas del proceso de As-Is, de los insumos, pasos y resultados reales del
proceso, las causas de cualquier problema especfico que la administracin nos ha pedido
eliminar y de cualquier otro problema que impida que el proceso funcione tan bien como
pueda.

STAKEHOLDERS (INTERESADOS)
A medida que recopile informacin de la alta direccin sobre el proceso que se va a cambiar,
tambin debera estar elaborando una lista de todos los interesados que tienen inters en el
proceso. Las partes interesadas incluirn clientes, proveedores, gerentes, empleados y
cualquier persona que administre un proceso que interacte con el proceso que va a tratar de
cambiar. Durante la fase de anlisis del proyecto, usted querr entrevistar a todas las partes
interesadas (o al menos a los representantes) para asegurarse de que entiende cmo ven el
proceso y sus problemas.

REFINANDO UNA DESCRIPCIN DE PROCESO INICIAL

Una vez que tenga una descripcin bsica del proceso del problema, representado como un
proceso que necesita ser cambiado o como un proceso con cuatro a cinco subprocesos que
necesitan ser mejorados, est listo para refinar su comprensin del proceso, el alcance de El
problema y la naturaleza especfica de los problemas que tendr que tratar. Ahora est listo
para entrevistar a una serie de diferentes partes interesadas, incluidos clientes, empleados y
gerentes cotidianos.

En esta etapa temprana a menudo nos resulta til crear un diagrama de alcance del proceso.
Ms adelante, una vez que entendamos mejor el problema y cuando comenzamos a refinar
nuestro anlisis del problema, usualmente nos movemos a un diagrama de flujo del proceso
(ver Figura 8.11).

Figura 8.11 Pasando de un diagrama de proceso inicial, informal a un

diagrama de alcance de proyecto o un diagrama de flujo de proceso

En este captulo consideraremos los diagramas de alcance del proceso con cierto detalle. En el
prximo captulo pasaremos a procesar los diagramas de flujo. Las ideas bsicas detrs del
diagrama de alcance del proceso se originaron con la tcnica estructurada de modelado de
anlisis de software, llamada IDEF (Integrated DEFinition language), que fue desarrollada
originalmente por la Fuerza Area de los Estados Unidos y que result popular con los
proveedores de herramientas CASE (computer-assisted software engineering) Finales de los
aos ochenta. La mayora de los elementos del IDEF son demasiado tcnicos para interesar a
los modeladores de negocios, aunque los ingenieros de software todava utilizan elementos de
otros diagramas del IDEF. La idea de analizar y escanear un proceso dentro de una "caja", sin
embargo, ha sido desarrollada y popularizada por Roger Burlton y sus asociados en el Grupo de
Renovacin de Procesos (PRG) y es muy til en el anlisis de negocios.

Figura 8.12 Los elementos de un diagrama de alcance del proyecto

(modificado a partir de un diagrama originalmente desarrollado por
Process Renewal Group)

Figura 8.13 Figura de efecto de efecto con categoras de causa pre

especificadas para el alcance

El diagrama bsico se refiere, en la literatura del IDEF, como una caja de funcin. Burlton se
refiere a l como un IGOE (entradas, guas, salidas y facilitadores) diagrama. Nos referiremos a
l, de manera ms genrica, como un diagrama de alcance del proceso y desarrollarlo un poco
ms all de su uso por el IDEF o PRG. En esencia, creamos un diagrama, como el que se
muestra en la parte superior derecha de la figura 8.11, y luego colocamos el proceso o
procesos que pretendemos analizar en el centro del espacio, que denominamos rea de
proceso. El rea a la izquierda del rea de proceso est reservada para informacin sobre
entradas al proceso o procesos en el rea problemtica. El rea a la derecha del rea de
proceso est reservada para los resultados del proceso o procesos en el rea problemtica. Las
entradas y salidas pueden vincular los procesos en el rea de proceso a individuos,
documentos, productos, sistemas, organizaciones u otros procesos. Para mantener las cosas
claras, utilizamos pequeas figuras para personas, rectngulos para organizaciones o sistemas,
y rectngulos con esquinas redondeadas para procesos. El rea por encima del rea de proceso
es para guas o controles, que pueden ser individuos, organizaciones, sistemas, documentos o
procesos que manejan, limitan o controlan las actividades de los procesos en el rea de
proceso. El rea debajo del rea de proceso es donde ingresamos informacin sobre los
procesos de soporte o habilitacin o recursos que apoyan la ejecucin de los procesos en el
rea de proceso. A veces ayuda a recordar que las entradas son consumidas por los procesos,
modificadas y convertidas en salidas. Los controles y los procesos habilitadores, por otro lado,
son recursos reutilizables. La Figura 8.12 proporciona una visin ms detallada de los tipos de
problemas que nos preocupan cuando creamos un diagrama de alcance del proceso.

Los lectores ms familiarizados con los diagramas de causa-efecto (tambin denominados

diagramas de Ishikawa o de espina de pescado) podran preferir hacer su anlisis de procesos
con uno, que puede representar la misma informacin (vea la figura 8.12 y 8.13). Preferimos
el diagrama de alcance del proceso en parte porque parece proporcionar ms espacio para
registrar informacin y tambin porque nos permite mostrar cmo podramos cambiar el
alcance del proyecto. En nuestra experiencia, los diagramas causa-efecto funcionan mejor para
problemas ms pequeos, y los problemas ms grandes requieren ms espacio simplemente
porque hay ms problemas y ms oportunidades de hacer mejoras. Pero es obviamente una
cuestin de gusto personal y muchos prefieren el alcance con diagramas de causa-efecto.

Si tuviramos que utilizar un diagrama de alcance de proceso para analizar el proceso Entregar
Pizzas, empezaramos colocando el etiquetado en el cuadro central del diagrama de mbito del
proceso: Entregar pizzas. Tambin podramos insertar una lista de algunos de los subprocesos
que hemos acordado que definitivamente estn incluidos en el proceso de Entrega de Pizzas.
Entonces comenzamos a tomar notas en el rea de proceso o en las reas que rodean el rea
de proceso. Estas notas reflejaran las cosas que descubrimos acerca del proceso cuando
entrevistbamos a individuos involucrados en el proceso. En esencia, el diagrama de escopo
del proceso nos recuerda los tipos de problemas que podemos encontrar al analizar cualquier
proceso y nos proporciona espacio para tomar notas sobre los problemas reales que
encontramos. Por lo tanto, el diagrama proporciona espacio para informacin sobre las
relaciones entre el proceso en el mbito (en el rea de proceso), otros procesos, documentos o
individuos, o lo que fluye entre ellos. Al mismo tiempo, considerando estas relaciones,
podemos concentrarnos en cuatro de los seis tipos genricos de problemas de proceso que
normalmente encontramos, incluyendo:

Flujo de Procesos y Problemas de Gestin Diaria.

Problemas de salida
Problemas de entrada
Problemas con los controles
Problemas con los facilitadores
Flujo de Procesos y Problemas de Gestin Diaria
El lugar para comenzar con cualquier esfuerzo de anlisis de proceso inicial es asegurar que
usted entiende el proceso que se est describiendo. Esta rea es ms compleja porque hay dos
cosas a considerar. Hay las actividades que componen el proceso en s, y luego est el da a da
los problemas de gestin de procesos. En esencia, cada proceso o actividad debe tener alguien
que es responsable de asegurar que el proceso o la actividad se lleva a cabo. Este gerente de
proceso puede ser un lder de equipo, un supervisor o un gerente que es responsable de
asegurar que el proceso tiene los recursos que necesita, que los empleados saben y realizan
sus trabajos y que los empleados reciben retroalimentacin cuando tienen xito o cuando no
lo hacen Correctamente. Es tan probable que un proceso se rompa porque el gerente no est
haciendo su trabajo, ya que es que el proceso se rompe debido al flujo de actividades o el
trabajo de los empleados.

Comenzamos con el proceso mismo y consideramos sus subprocesos o actividades, y le

pedimos a todos los involucrados en el proceso una serie de preguntas para explorar las
siguientes posibilidades.
1.1 Problemas de flujo
1.1.1 Problemas con la integridad lgica
* Algunas actividades no estn conectadas a otras actividades relacionadas.
* Algunas salidas no tienen lugar para ir
* Algunas entradas no tienen lugar para ir
1.1.2 Problemas de secuenciacin y duplicacin
* Algunas actividades se realizan en el orden equivocado.
* Algunas actividades se realizan secuencialmente que se pueden realizar en paralelo.
* El trabajo se hace y luego se pone en inventario hasta que sea necesario
* Algunas actividades se realizan ms de una vez
* No hay reglas para determinar o priorizar flujos entre ciertas actividades o individuos.
1.1.3 Entradas y salidas de subproceso
* Las entradas y salidas de los subprocesos estn incorrectas o se especifican de manera
inadecuada.
* Las entradas o salidas de subproceso pueden ser de calidad inadecuada, cantidad
insuficiente o intempestiva.
* Los subprocesos reciben entradas o realizan salidas innecesarias.
* Algunos subprocesos hacen cosas que hacen ms trabajo para otros subprocesos.
1.1.4 Proceso de toma de decisiones
* El proceso-en-alcance, o uno de sus subprocesos, est llamado a tomar decisiones sin la
informacin adecuada o necesaria.
* El proceso en el mbito, o uno de sus subprocesos, se requiere para tomar decisiones sin
una gua adecuada o completa de la cadena de valor u organizacin. Ejemplo: las
decisiones deben ser tomadas sin polticas establecidas o sin reglas de negocio especficas.
1.1.5 Medidas de subproceso
* Existen medidas inadecuadas o inexistentes para la calidad, cantidad o oportunidad de
los productos del subproceso
* Las medidas de subproceso son medidas retardadas y no proporcionan al gerente del
proceso u otros empleados la capacidad de anticipar o planificar cambios en el ritmo o el
volumen de flujo.
 Tenga en cuenta que vamos a explorar todos estos temas con mayor detalle a medida que
avanzamos con nuestro esfuerzo de anlisis de procesos. Durante la fase inicial del
escrutinio estamos simplemente tratando de obtener una visin general de lo que podra
estar mal con el proceso. En este punto estamos buscando problemas que se destacan y
que claramente habr que abordar si queremos eliminar la brecha entre el El proceso
existente y el proceso que la direccin desea. Las Figuras 8.14 muestran nuestro diagrama
de alcance del proceso con el proceso de prestacin del servicio de entrega, subdividido en
cinco actividades, representadas en el rea de proceso.
La Figura 8.15 muestra los mismos procesos que se representan en la Figura 8.14, pero en
este caso hemos representado explcitamente el proceso de gestin asociado a cada
subproceso en el proceso Entregar Pizzas. De hecho, raramente dibujaramos tal diagrama.
Al hacer un anlisis rpido y temprano, simplemente asumimos que cada proceso
operacional tiene un proceso de gestin cotidiano asociado. Para ilustrar esta idea, sin
embargo, hemos agregado cada uno de los procesos de gestin de la Figura 8.15 para
sugerir que necesitamos Considerar cmo funcionan los procesos de gestin al mismo
tiempo que consideramos el flujo de los procesos bsicos.
Algunas de las preguntas que hacemos cuando consideramos si hay problemas con los
procesos de gestin cotidiana incluyen:
1.2 Problemas de gestin diarios
1.2.1 Problemas de planificacin y asignacin de recursos
* El encargado del proceso que trabaja en el proceso-en-alcance se da el retraso de datos,
pero no los datos principales que l o ella puede utilizar para anticipar el trabajo, planes,
horario, etc.
1.2.2 Problemas de supervisin, retroalimentacin y control
* Los empleados que trabajan en el proceso de alcance no se responsabilizan por el logro
de uno o ms objetivos clave del proceso
* Los empleados que trabajan en el proceso de alcance son castigados por perseguir una o
ms metas clave del proceso.
* Los empleados que trabajan en el proceso en el mbito no se les da la informacin
adecuada sobre el desempeo del proceso que l / ella es responsable de la gestin
* Los empleados que trabajan en el proceso en el mbito se les da datos de retraso, pero
no hay datos principales que pueden utilizar para anticipar el trabajo, planes, horarios, etc.
* Los empleados que trabajan en el proceso de alcance no son recompensados por lograr
las metas clave del proceso o son castigados por lograr los objetivos clave del proceso, por
ejemplo, el empleado que trabaja ms duro para asegurar que el proceso en el alcance
cumple con un plazo es dado ms trabajo para hacer.
1.2.3 Metas e incentivos del gerente en conflicto
* El gestor de procesos est tratando de alcanzar objetivos funcionales / departamentales
que son incompatibles con los objetivos del proceso en el mbito
* El gestor de procesos no tiene la autoridad, el presupuesto o los recursos necesarios para
gestionar eficazmente el proceso en el mbito
1.2.4 Responsabilidad del gerente
* El gestor de procesos no se responsabiliza de alcanzar uno o ms objetivos clave del
proceso
* El gerente de proceso es castigado por perseguir una o ms metas clave del proceso
* El gestor del proceso no recibe informacin adecuada sobre el desempeo del proceso
que l / ella es responsable de administrar
Figura 8.14 Un diagrama de alcance del proceso con el rea de proceso
rellenada

Figura 8.15 Diagrama de alcance del proyecto que muestra tanto los
procesos en su alcance como los procesos de gestin cotidiana
asociados

Hay una distincin importante entre la gestin cotidiana de los procesos y los procesos de
gestin ms genricos y de nivel superior que se incluyen bajo control. As, por ejemplo, un
gerente cotidiano es responsable de asegurar que los empleados conozcan y apliquen Las
reglas de negocio que se aplican a un proceso determinado. En la mayora de los casos, ese
gestor no es responsable de crear, mantener o cambiar las reglas de negocio. Si las reglas de
negocio no se estn aplicando, nos centramos en el gestor de procesos cotidiano. Si las reglas
de negocio estn equivocadas o deben cambiarse , Probablemente vamos a tener que mirar el
proceso de gestin de alto nivel que establece la poltica y define las reglas de negocio.

Problemas de salida
Se producen problemas de salida cuando el "cliente" del proceso no est consiguiendo lo que
se necesita. Es posible que las salidas sean poco realistas o innecesarias y deberan ser
cambiadas, pero como estn las cosas, si la calidad, cantidad o oportunidad de los productos
de la Proceso en el alcance no estn satisfaciendo a sus clientes, usted tiene problemas. Tenga
en cuenta que los "clientes" pueden ser otros procesos.
Del mismo modo, puede haber otros interesados que tengan inters en los resultados de un
proceso. As, por ejemplo, los reguladores del gobierno local podran estar interesados en
productos que no cumplan con las leyes locales de servicio de alimentos. Del mismo modo, los
empleados del servicio de entrega podran ser partes interesadas si el programa de entrega
exiga que excedieran las leyes de velocidad para realizar las entregas requeridas en el tiempo
permitido. Los productos pueden adoptar diferentes formas, incluyendo entidades fsicas,
informacin o datos, o decisiones / aprobaciones.

2.1 Calidad de la produccin

La salida es rechazada por un proceso de control de calidad aguas abajo (nmero, relacin de
rechazos).
El proceso descendente rechaza aceptar la salida del proceso en su alcance.
Se devuelve la salida (relacin de devoluciones a la salida).
2.2 Cantidad de producto
El proceso no produce el nmero de salidas requeridas.
El proceso no puede reducirse rpidamente cuando se requiere un nmero menor de salidas.
El proceso no puede escalarse rpidamente cuando se requiere un mayor nmero de salidas.
2.3 Oportunidad del producto
Algunas o todas las salidas necesarias no se producen cuando se requiere.
En el caso de nuestro ejemplo de pizza, los clientes obvios son los individuos pidiendo pizzas.

Problemas de entrada
Este tipo de problema se debe a que los "proveedores" del proceso en el mbito no estn
produciendo lo que necesita el proceso en su alcance. Los proveedores pueden incluir
empresas, individuos u otros procesos y los "insumos" pueden incluir cosas, informacin,
dinero o incluso empleados temporales. Al igual que con la produccin, los insumos del
proceso en su alcance pueden ser deficientes en calidad, cantidad o oportunidad. Del mismo
modo, los insumos pueden adoptar diferentes formas, incluyendo entidades fsicas,
informacin o datos, o decisiones / aprobaciones.

3.1 Calidad de las Entradas

Las entradas son rechazadas porque no cumplen con los estndares de calidad del proceso
en su alcance.
Las entradas deben devolverse al proceso ascendente o proveedor (relacin de devoluciones
a la entrada).
3.2 Cantidad de entradas
El proveedor no produce el nmero de entradas necesarias.
El proveedor no puede disminuir rpidamente cuando se requiere un nmero menor de
entradas.
 El proveedor no puede escalar rpidamente cuando se requiere un mayor nmero de
entradas.
3.3 Puntualidad de los insumos
Algunas o todas las entradas necesarias no llegan cuando es necesario.
Las entradas llegan en lotes y deben ser almacenadas hasta que sean necesarias.

La Figura 8.16 muestra un diagrama de alcance del proceso para el proceso Entregar Pizzas con
algunas entradas y salidas bsicas.

Hasta ahora estamos describiendo slo algunas de las personas y procesos que generan
entradas o aceptan productos. Ms adelante enumeraremos algunos de los problemas
especficos que podran ocurrir en cada seccin del diagrama.

Figura 8.16 Un diagrama de alcance del proceso con algunas entradas y

salidas mostradas.

Problemas con los controles: Los controles definen o limitan como se realiza un proceso. En la mayora
de los casos, los controles se crean mediante procesos de gestin de nivel superior y luego se liberan a los
administradores y empleados del proceso-en-alcance. Existen 4 tipos de problemas:

4.1 Proceso-en-Alcance no alineado con la organizacin o la estrategia de cadena de valor

Problema de alineacin de estrategia. Los procesos implementan estrategias igual que las organizaciones.
Los procesos deben llevar a cabo estrategias compatibles con la estrategia de la organizacin declarada. Si
no ocurre esto, las estrategias de proceso deben ser cambiadas para asegurar que realmente implementan
estrategias organizacionales y de cadena de valor.

4.2 Problemas con las polticas o reglas de negocio

Las reglas de negocio deben derivarse y alinearse con las polticas de la organizacin. Los empleados
individuales que trabajan en el proceso en el mbito ignoran una o ms polticas especficas o reglas de
negocio. El proceso de alcance se encarga de implementar objetivos o polticas incompatibles

4.3 Problemas con la documentacin, manuales, etc.

Normalmente surgen porque la documentacin est desactualizada, y las polticas o reglas de la
documentacin son incorrectas o porque dos o ms fuentes de informacin son incompatibles.

4.4 Problemas con los procesos de administracin externos

Este tipo de problema es el resultado de la informacin proporcionada o requerida por un proceso de gestin
que no est dentro del alcance del esfuerzo de anlisis.

En el caso de nuestro proceso de pizza, sabemos que hay una serie de leyes federales, estatales y locales
que rigen cualquier negocio y muchas leyes particulares que regulan la preparacin de los alimentos. Todas
estas leyes deben ser obedecidas y cualquier poltica de gestin o reglas de negocio que contradigan estas
leyes externas crea un problema inmediato.

Problemas con los habilitadores: Los problemas con los procesos de habilitacin o soporte surgen cuando
esos procesos no proporcionan o mantienen los recursos necesarios para el proceso en el mbito. Categoras:

5.1 Problemas de empleados

Los empleados necesitan capacitacin. Los empleados carecen del tiempo, el espacio o las
herramientas necesarias para algunas de las tareas involucradas en el proceso-en-mbito.
Los empleados carecen de las habilidades necesarias para realizar el trabajo requerido para llevar
a cabo el proceso de alcance.
Los trabajos o roles definidos para los empleados asignados al proceso no coinciden con las
necesidades / requisitos del proceso en el mbito
5.2 Problemas de TI
Las aplicaciones o herramientas de TI requieren entradas o producen resultados que son difciles
de interpretar y, por lo tanto, interfaces de usuario inadecuadas conducen a ineficiencias o errores.
Las aplicaciones o herramientas de TI soportan un procesamiento normal pero no soportan
adecuadamente el manejo de excepciones, lo cual es un problema especial siempre que el nmero
de picos de excepciones

5.3 Instalaciones, equipos y problemas de ubicacin

Los recursos o herramientas requeridos por el proceso de alcance no estn disponibles cuando son
necesarios
El proceso de alcance est geogrficamente distribuido y esto provoca ineficiencias

5.4 Problemas contables

Los requerimientos de contabilidad imponen pesadas cargas al proceso de alcance

La Figura 8.17 ilustra un diagrama de alcance del proyecto con algunos controles y procesos de soporte
definidos. En la Figura 8.18 hemos incluido una Hoja de Trabajo de Anlisis de Procesos que preparamos
al hablar con los grupos de inters en el Proceso Entregar Pizzas. La hoja de trabajo enumera algunos de
los problemas que encontramos. La Figura 8.19 muestra cmo transferimos las notas de nuestra hoja de
clculo al diagrama de alcance del proyecto.
Figura 8.17 Un diagrama de alcance del proyecto con algunos controles y habilitadores definidos.

Figura 8.18 Una hoja de trabajo con informacin reunida sobre el proceso de Entrega de Pizza.
Figura 8.19 Un diagrama de alcance del proyecto con los problemas indicados y con una lnea en negrita
para sugerir procesos adicionales que deben ser incluidos en el alcance del proyecto para maximizar las
probabilidades de un resultado exitoso. En muchos casos sigue siendo el alcance cuando terminamos el
diagrama de alcance del proyecto, y el diagrama simplemente documenta las relaciones y problemas con el
proceso de alcance. En otros casos, sin embargo, podemos decidir que un proyecto exitoso requiere ampliar
nuestro alcance y analizar y redisear procesos que estn fuera del alcance original y el diagrama de alcance
del proyecto nos ayuda a documentar y explicar por qu nos gustara ampliar el alcance del proyecto. En
algunos casos, la incapacidad de ampliar el alcance de un proyecto sugiere fuertemente que el proyecto
probablemente no puede ser exitosamente emprendidas y no deben ser ejecutadas.
Lo importante del diagrama de alcance del proyecto es su informalidad. Proporciona una manera de
recopilar y registrar informacin acerca de todos los posibles problemas que pueda encontrar sin requerir
una definicin formal de cmo los procesos estn relacionados o cmo se crean las polticas o se mantienen
los manuales. Es un diagrama muy til cuando primero intenta decidir qu se incluir en un proyecto y qu
tipo de problemas puede encontrar. El diagrama de alcance del proyecto es til precisamente porque no
requiere precisin, al mismo tiempo que permite al equipo del proyecto captar todos los diferentes
problemas que pueden afectar al proyecto. Y proporcionan una buena manera de subrayar cundo el alcance
de un proyecto probablemente tendr que ser ampliado para asegurar que el equipo del proyecto pueda
cumplir con las metas del proyecto establecidas por la administracin

Rediseo, mejora y Lean Six Sigma

Muchos practicantes Lean y Six Sigma encontrarn nuestra discusin sobre la gestin, el rendimiento
humano, y los problemas de alcance ms all de lo que normalmente consideran cuando se acercan a un
proyecto de mejora de procesos. Esperemos que sean desafiados por la idea de que pueden agregar nuevas
dimensiones a su prctica y vern formas de combinar este material con los conceptos y tcnicas que ya
estn utilizando.

Creacin de un caso comercial para un proyecto de cambio de proceso

Para concluir nuestra discusin, consideremos lo que implica crear un caso de negocio para un proyecto de
cambio de procesos empresariales.
Uno comienza con una declaracin del problema. A continuacin, se refina la declaracin del problema y
se describe la brecha de rendimiento. Se discute las medidas que describen el proceso actual o tal y como
es y se consideran medidas que definiran un proceso rediseado aceptable. Luego, el caso de negocios
debera describir la brecha de capacidad, caracterizando el proceso actual y sugiriendo qu tipo de cambios
se requerirn para crear un nuevo proceso que ser capaz de generar las medidas deseadas de To-Be. Se va
ms all y se considera cmo se podra estudiar la brecha e indicios de las tcnicas de rediseo que podran
utilizarse para eliminar el rendimiento y las brechas de capacidad.

Los pasos para definir un caso preliminar de negocios incluyen:

1. Defina el proceso As-Is (lo que est dentro y fuera del mbito de aplicacin).
2. Determinar qu es o no est haciendo el proceso de As-Is (medidas concretas).
3. Definir lo que el proceso de To-Be debe o no debe hacer cuando se completa (el
Objetivo del proyecto).
4. Considere los medios que utilizar para salvar la brecha de capacidad.
5. A continuacin, considere lo que el puente de la brecha va a costar en trminos de tiempo, costo y
esfuerzo.
6. Finalmente, considere los riesgos y la "poltica" y revise si es necesario.

Estas son algunas directrices y un esquema para una propuesta de caso de negocio:

Mantenlo simple.
Estado claramente:
Cul es el problema?
Qu proceso queremos cambiar?
Por qu queremos cambiarlo?
Describir las medidas de la situacin actual.

Cul es el objetivo o objetivo del proyecto?

Cmo sera el nuevo proceso?
Qu medidas esperamos del nuevo proceso?

Qu implica la creacin del nuevo proceso?

Anlisis y Diseo.
Implementacin.
 Desenrollar.
Qu recursos, tiempo y costo se requerirn para resolver este problema?
Qu riesgos o costos de oportunidad se requerirn?
Qu resultados y qu retorno debemos esperar de este esfuerzo?

Las hojas de trabajo representadas en la figura 8.21 proporcionan una forma de estructurar el desarrollo de
un caso de negocio inicial. En este punto, sin embargo, simplemente desea establecer el alcance general y
sugerir lo que podra estar involucrado, mejor y peor caso.

Figura 8.21 Hojas de trabajo para el desarrollo de un caso de negocio de proyecto de cambio de proceso
inicial.