Professional Documents
Culture Documents
Jerarquía de Procesos
Una cadena de valor es el proceso más grande del que hablamos normalmente.
Define un proceso que comienza cuando la empresa decide crear un nuevo
producto o servicio, o cuando un cliente ordena un producto y concluye cuando el
cliente tiene y está satisfecho con el producto o servicio. Hoy en día, algunas
empresas hablan de cadenas de valor que se extienden a través de varias
empresas, pero ese tipo de proceso multi-empresas todavía es relativamente raro.
Se puede crear una arquitectura de procesos de negocio en papel. Para ilustrar los
conceptos básicos y las relaciones, usaremos hojas de trabajo para explicar el
proceso. Cualquier gran empresa, sin embargo, querrá utilizar herramientas de
software para crear y mantener su arquitectura de procesos de negocio. Las
relaciones involucradas y la cantidad de datos involucrados rápidamente se vuelven
tan complejas y extensas que se requiere una base de datos para administrar la
arquitectura.
Figura 4.3 Ilustra el encabezado de una hoja de trabajo de análisis de arquitectura Una vez que comenzamos a tratar de analizar un gran número de procesos y
e indica la información que debe incluirse. subprocesos,
Es a menudo más fácil cambiar a un diagrama horizontal de la descomposición del
proceso como el que se muestra en la Figura 4.5. En este caso hemos roto una
Cadena de Valor de Widget en tres procesos principales, luego subdividimos cada
uno de ellos en subprocesos y subdividimos uno de los procesos de nivel 2 en un
conjunto adicional de subprocesos.
Cada vez más hoy en día, los gerentes se acercan al análisis de arquitecturas de
proceso de una manera diferente. Están utilizando marcos de procesos -modelos
genéricos de todos los procesos en una cadena de valor o en una parte de una
cadena de valor- para proporcionarles una descripción completa. Comenzando con
un marco, los ejecutivos lo adaptan para proporcionar una descripción de su cadena
de valor en particular. El enfoque basado en el proceso funciona porque, en los
niveles 1 y 2, la mayoría de las empresas hacen las cosas de una manera muy
similar, aunque utilizan palabras muy diferentes para describir sus procesos. Por lo
tanto, cualquiera que sea su denominación, todo el mundo tiene algún tipo de nuevo
proceso de desarrollo de productos / servicios, algún tipo de proceso de desarrollo
de productos / servicios con un proceso de adquisición asociado y algún tipo de Figura 4.6 Hojas de trabajo de análisis de arquitectura y una jerarquía de procesos.
proceso de marketing y ventas.
Completando una Hoja de Trabajo
Veremos los marcos de proceso más detalladamente en un momento; Mientras
observa nuevamente el diagrama de descomposición de la cadena de valor Trabajando en la hoja de trabajo del Nivel 1 mostrada en la Figura 4.3, puede ver
horizontal representada en la Figura 4.5, puede ver cómo nos movemos de una que la parte superior de la hoja de trabajo proporciona un espacio para el nombre
descripción de proceso a hojas de trabajo. La Hoja de trabajo 1 proporciona un de la cadena de valor y una descripción de cómo esa cadena de valor soporta la
espacio para describir los atributos y recursos que soportan los procesos de Nivel estrategia corporativa y cómo se medirá. En algunos casos esta discusión será
1 en una cadena de valor. Las diversas hojas de trabajo de nivel 2 permiten a los breve. En otros casos, la discusión llevará tiempo e involucrará a los altos directivos
analistas profundizar en cada proceso específico de nivel 1 para identificar los en discusiones muy serias sobre lo que la cadena de suministro debe procurar
atributos y recursos utilizados por los procesos de nivel 2. lograr. Algunos podrían ver la cadena de valor contribuyendo al beneficio de la
empresa. Otros podrían sentir que la cadena de valor específica se estaba llevando
a cabo para apoyar la imagen de la empresa o para generar ideas para futuras
empresas. Los objetivos de la cadena de valor deben definirse concisamente y
deben desarrollarse medidas que todos estén de acuerdo en reflejar con precisión
el éxito o el fracaso de la cadena de valor.
Hasta ahora, nos hemos centrado en los procesos básicos u operativos. Estos son
procesos que agregan valor al producto o servicio que la organización está
produciendo para sus clientes. Cuando Michael Porter definió la cadena de valor,
distinguió entre el núcleo y los procesos de apoyo. Los procesos centrales generan
productos o servicios. Los procesos de soporte no agregan valor, pero son
necesarios para asegurar que los procesos centrales continúen funcionando. Así,
en una organización manufacturera, la contabilidad es un proceso de apoyo.
Mantenemos los libros para que la administración sepa cuánto cuesta la fabricación
y para que puedan informar a los accionistas. Del mismo modo, IT es un proceso
de soporte que genera y mantiene el software y los sistemas que la fabricación
necesita para controlar su maquinaria de línea de producción. Hoy en día, es
popular dividir los procesos de soporte entre los procesos que apoyan directamente
los procesos centrales y los procesos de gestión más genéricos que planifican,
organizan, comunican, monitorean y controlan las actividades de la organización.
Los procesos de soporte a veces se llaman procesos habilitadores.
Figura 4.7 Tres tipos de procesos: Centrales, Soporte y Gestión
La figura 4.7 proporciona una forma de pensar acerca de la distinción. En este caso,
tenemos un conjunto básico de procesos que genera un producto. Por separado, ¿Deberíamos incluir procesos de soporte o habilitación en nuestra arquitectura de
tenemos un proceso de soporte -el Proceso de reorganización de existencias- que procesos de negocio y, en caso afirmativo, cómo los debemos representar? Un
repone un proceso de ensamblaje de núcleo. También tenemos un proceso de enfoque sería dividir todos los procesos de soporte y organizar los procesos de
gestión que determina qué proveedores utilizará la empresa y establecerá y soporte bajo los procesos centrales que lo permiten. Esto es conceptualmente
mantendrá relaciones con los proveedores. Obviamente, este proceso de gestión limpio, pero no es, de hecho, muy realista. En la mayoría de los casos, una empresa
podría ser una actividad emprendida por la adquisición, pero también podría ser un conceptualiza su grupo de TI como un departamento. En el mejor de los casos, el
proceso emprendido por las finanzas. grupo de TI se gestiona como una organización matricial y cuenta con algunos
gerentes responsables de funciones genéricas de TI, como el desarrollo de nuevos
productos y mantenimiento de software en curso, y otros responsables del soporte
de TI para la cadena de suministro y soporte de ventas y marketing. La clave aquí,
sin embargo, es que la TI tiene un conjunto básico de funciones, como la red de la
empresa y buenas prácticas de mantenimiento, que se aplican a todos los procesos
o departamentos que soporta; Por lo tanto, hay un argumento muy fuerte para tratar
la TI como un departamento independiente.
Un enfoque alternativo, cada vez más popular, es tratar a la TI como una necesitan una representación independiente en nuestra arquitectura de procesos
organización independiente, un centro de costos o una cadena de valor de negocio.
independiente. Esto refleja lo que ocurre cuando se externaliza la TI. En esencia, IT
se convierte en una compañía separada, una cadena de valor que produce software Siguen existiendo algunos procesos generales de gestión que realizan funciones de
y servicios que vende a los procesos centrales de la empresa matriz. planificación, organización, comunicación o supervisión de la empresa. En esencia,
Independientemente de que su empresa externaliza IT o la mantiene en casa, si la si la organización tiene un grupo de reglas de negocio que trabaja para definir las
considera como su propia cadena de valor y crea una arquitectura de procesos de políticas de la empresa y dictar las reglas de negocio que los procesos específicos
negocio independiente para describir los procesos de núcleo, soporte y deben implementar, ese grupo y los procesos que implementa constituyen una
administración de TI, verá que facilita todo. especie de proceso de gestión. Del mismo modo, el equipo que define la estrategia
corporativa sigue un proceso y el grupo BPM implementa un conjunto de procesos.
Obviamente, la misma lógica puede aplicarse a los otros procesos principales de Estos son procesos de gestión verdaderos que son independientes de los procesos
apoyo, incluidos los recursos humanos, las instalaciones y la contabilidad. Si sigue centrales en una cadena de valor normal. Las empresas sofisticadas querrán
este enfoque, dejará los procesos de soporte de las hojas de trabajo de arquitectura analizar estos procesos de gestión para asegurar que funcionen de la manera más
de procesos de negocio que crea para sus cadenas de valor fundamentales y eficiente y eficaz posible. Por lo tanto, debemos definirlos y documentar cómo
describirá cada proceso de soporte principal como una arquitectura independiente funcionan. La cuestión es dónde incluirlas. A diferencia de los procesos de soporte
con sus propias hojas de trabajo. estándar, como TI y recursos humanos, es difícil pensar en estos "procesos de
Manejar los procesos de gestión es más complicado, porque la idea de los procesos gestión" como un centro de coste o una empresa independiente. Es más fácil pensar
de gestión no ha sido muy bien pensada. Para empezar, necesitamos discriminar simplemente en ellos como actividades emprendidas por los altos directivos. Por el
entre dos tipos básicos de "procesos de gestión". En un caso, tenemos los procesos momento, probablemente es mejor pensar simplemente en todos los "procesos de
o actividades que realizan los individuos que realmente administran los procesos en gestión" que son independientes de procesos operativos específicos como su
el día a día. Por lo tanto, si consideramos la Figura 4.7, hay un individuo que es propia "cadena de valor de gestión" y documentarlos en sus propias hojas de
responsable de administrar el proceso de Relleno de la acción. Ese individuo trabajo. No es una solución muy elegante, pero es probablemente mejor que tratar
planea, organiza, comunica, monitorea y controla el proceso de llenar la orden del de asociarlos con una cadena de valor convencional.
archivo cada hora de cada día. Él o ella interactúan con los empleados que llevan
a cabo las tareas que asociamos con el proceso de llenar orden del almacén,
comunica nuevos objetivos a medida que ocurren y proporciona retroalimentación Alineación de gerentes, medidas y recursos
cuando los empleados hacen su trabajo de manera excepcional o inaceptable. No
es útil tratar la gestión cotidiana del proceso directamente asociada con el proceso A medida que se identifican los procesos, el grupo puede determinar quién es
central como un proceso separado. Cuando se busca rediseñar o mejorar el responsable de administrar ese proceso. Si la empresa está orientada
proceso, es necesario considerar las actividades de los empleados asignados al funcionalmente, en el nivel más alto será frecuente que no haya un gestor claro para
proceso y, simultáneamente, las actividades del gerente que se encarga del los procesos de nivel 1. En cambio, los procesos se dividirán entre múltiples
proceso. En la medida en que es útil discriminar estos procesos cotidianos de departamentos, sin que nadie sea responsable de la coordinación general. Vamos
gestión de procesos, se hace para definir los procedimientos estándar o de mejores a pasar por alto cualquier otra discusión de la gestión de procesos en este punto y
prácticas que deben seguir los administradores de procesos. Consideraremos las retrasarla hasta llegar al Capítulo 5. Baste decir que, si el equipo tiene problemas
prácticas de gestión de procesos estándar más adelante, cuando consideremos la para asignar los gerentes a los procesos, eso debería estimular una discusión sobre
gestión de procesos y el establecimiento de grupos de soporte de BPM. En este cómo se manejan los procesos en la organización.
punto, sin embargo, simplemente ignoraremos estos procesos de gestión A continuación, el equipo debe definir el objetivo de cada proceso de Nivel 1 y
cotidianos. Están tan estrechamente asociados con los procesos centrales que no considerar cómo debe medirse el éxito de cada uno de los procesos de Nivel 1. Al
igual que con la administración, retrasaremos la discusión de la medición hasta determinación del crédito al cliente ocurrió en varios procesos de Nivel 1 y
llegar al siguiente capítulo. 2, y que en algunos casos lo hicieron los empleados y en otros casos se
hizo con un módulo ERP. Sería bueno saber dónde se determinó el crédito
La columna final de la hoja de cálculo pide al equipo de arquitectura que enumere al cliente, para que la actividad pudiera ser estandarizada y el mismo
los recursos necesarios para soportar cada proceso de Nivel 1. Esto hace hincapié software podría ser usado siempre que sea posible. Por lo tanto, la simple
en que el desarrollo de una arquitectura de procesos de negocio es una empresa a enumeración de subprocesos y actividades que se producen en múltiples
largo plazo. Obviamente, el equipo de arquitectura no pudo identificar los trabajos procesos de Nivel 1 puede ser muy útil.
o los sistemas de software asociados con cada proceso de Nivel 1 en el transcurso
de un día o una semana. De hecho, la mayoría de las organizaciones omite la ➢ Alineamiento con políticas y reglas. Muchas organizaciones enumeran
alineación de recursos durante el primer paso, y dejarlo hasta que toda la las políticas corporativas que se aplican a procesos específicos de Nivel 1
arquitectura se entienda mejor. A medida que pasa el tiempo, la organización y los o 2. A medida que el análisis se hace más completo, las organizaciones
interesados en los procesos encontrarán que sería útil determinar cómo se alinean pueden enumerar las reglas de negocio específicas que se utilizan en
los diferentes recursos, y luego procederán a capturar información sobre la subprocesos específicos y, a continuación, comprobar que las políticas y
alineación de esos recursos. Muchas organizaciones crean una arquitectura y, a las reglas se aplican de forma coherente.
continuación, le añaden información detallada de recursos a medida que la
organización emprende proyectos de cambio de procesos empresariales. En este ➢ Alineación con recursos de TI. Muchas organizaciones indican qué
caso, nadie se propone enumerar cada aplicación ERP que utiliza cada proceso, aplicaciones de software o qué bases de datos se utilizan para estos
pero a medida que se rediseñan los procesos, se captura la información sobre el procesos. Si el esfuerzo por correlacionar los recursos de TI con procesos
soporte ERP y se agrega a la base de datos de arquitectura. empresariales específicos se vuelve muy elaborado, a menudo se
Algunos de los tipos de recursos que las organizaciones podrían tratar de alinear denomina arquitectura empresarial. Si una empresa utiliza aplicaciones
con el Nivel 1 o los procesos de Nivel 2 incluyen: ERP, la arquitectura del proceso suele estar impulsada o soportada por
arquitecturas de procesos sugeridas por los proveedores de ERP.
➢ Alineamiento con estrategias y metas corporativas. Algunas
organizaciones listan información sobre las estrategias específicas de nivel ➢ Alineación con recursos de recursos humanos. Muchas
1 y las partes interesadas observan cómo las estrategias específicas organizaciones definen qué funciones o trabajos están asociados con los
apoyan las estrategias corporativas. Otros enumeran a todos los procesos de Nivel 2 o 3. Si esto se lleva a cabo, se pueden definir las
interesados que están interesados en cada proceso específico del Nivel 1. descripciones de tareas asociadas con los procesos o definir las
competencias de los trabajos. Del mismo modo, algunas organizaciones
➢ Alineación con otros procesos. Hasta ahora hemos enfatizado procesos de la lista de los documentos de los empleados y los programas de
básicos u operativos. Una vez que se definen los procesos operativos, formación que se dan en apoyo en cada proceso específico.
algunas empresas proceden a describir los procesos de gestión y soporte
e indican qué procesos básicos u operativos dependen de qué procesos ➢ Alineación con Sarbanes-Oxley, ISO 9000 y diversos estándares de
de gestión o soporte. Vamos a considerar esto en más detalle en el gestión de riesgos. Las organizaciones son cada vez más responsables
próximo capítulo cuando hablamos de gestión. Muchas empresas están de reunir y mantener información sobre las decisiones y los riesgos
interesadas en identificar subprocesos específicos o actividades que se involucrados en procesos específicos. Esta información puede colocarse
repiten en diferentes procesos de Nivel 1 o 2. Supongamos, por ejemplo, naturalmente en la base de datos de la arquitectura de procesos de
que un proceso de nivel 1 incluye un subproceso de nivel 3 o 4 que se negocio. A medida que pasa el tiempo y se recopila más información, las
denomina: Determinar crédito de cliente. Imaginemos, además, que la organizaciones con completas arquitecturas de procesos de negocios se
encuentran invirtiendo el proceso y utilizando la base de datos de la averiguar cómo sus empresas trabajarán juntas para trasladar los materiales a los
arquitectura para generar la información requerida por las agencias fabricantes y luego a los distribuidores y, en última instancia, a los clientes. Si cada
externas. equipo tuviera que empezar intentando corregir qué términos utilizaban para
describir qué procesos, el esfuerzo llevaría mucho más tiempo. En cambio, el
Una arquitectura de procesos de negocio es una herramienta de gestión. Una vez Consejo de la Cadena de Suministros decidió definir un conjunto de alto nivel de los
que se define y luego se rellena con datos actualizados, se puede utilizar, al igual nombres de procesos de la cadena de suministro que todos podrían utilizar. Cada
que otras bases de datos, para responder a preguntas ad hoc que los ejecutivos empresa podría seguir utilizando los nombres de procesos particulares que eligiera,
necesitan respuesta. Puede ser utilizado para apoyar a aquellos involucrados en el pero en conversaciones con las otras empresas, cada una podría utilizar el
desarrollo de estrategias corporativas y puede ser utilizado por un grupo de BPM vocabulario estándar definido por SCOR. Posteriormente, el modelo SCOR se
para identificar procesos que no están cumpliendo sus objetivos y que necesitan amplió para que no sólo defina los procesos centrales, sino que también define
ser rediseñados. La información que se coloque en la base de datos de arquitectura procesos de gestión y soporte y proporciona medidas de rendimiento definidas con
de procesos de negocio dependerá de cómo lo utilice la empresa. La mayoría de precisión para cada proceso. Utilizando la información de rendimiento, las empresas
las empresas que han creado arquitecturas encuentran que facilitan a los gerentes pueden definir quién pasará qué a quién y cuándo, de una manera inequívoca. Una
la conceptualización de sus organizaciones en términos de procesos, lo que lleva a vez que se estableció el sistema, los miembros de SCC procedieron a proporcionar
solicitar más y más información sobre los procesos que soporta la empresa. información sobre el desempeño a una organización externa de evaluación
comparativa que proporciona información general a cambio. Así, una empresa
Definición de una arquitectura de procesos empresariales individual puede determinar cómo sus procesos de entrega se comparan con otros
miembros del SCC o, más específicamente, con otros en el mismo sector. Así,
SCOR comenzó como un esfuerzo para facilitar la comunicación y el modelado
Uno crea una arquitectura de proceso de negocio descomponiendo una cadena de eficaces y se convirtió en una metodología general que se puede utilizar para definir
valor en procesos y subprocesos. Como señalamos anteriormente, los esfuerzos de rápidamente una arquitectura de cadena de suministro completa con medidas de
análisis de procesos son cada vez más de alto nivel y están siendo apoyados por referencia.
el uso de marcos de procesos. En este punto, queremos ver los marcos de proceso
en un poco más de detalle. Empecemos con una mirada más detallada a la arquitectura SCOR. El SCC habla
de SCOR como compuesto de tres niveles. Ignoran el hecho de que la cadena de
El Marco SCOR del Consejo de la Cadena de Suministro: suministro es sólo uno de los principales procesos empresariales que conforman
toda la cadena de valor. Para aclarar esto, siempre nos referiremos a la cadena de
El Consejo de la Cadena de Suministro (SCC) fue establecido como un consorcio valor como Nivel 0. Luego nos referiremos a la cadena de suministro como un
sin fines de lucro en 1996. Hoy en día, es una organización mundial con más de proceso de Nivel 1. Para hacer las cosas aún más complejas, SCOR subdivide la
700 miembros. El Consejo realiza reuniones que permiten a las empresas reunirse cadena de suministro en tres "niveles", pero, de hecho, uno de los niveles no es una
para discutir problemas y oportunidades en la cadena de suministro. Además, ha descomposición del nivel superior, sino que requiere que el modelador defina el
estado trabajando en un marco estándar de la cadena de suministro o modelo de proceso de nivel superior en términos de Una de tres variaciones. El proceso de la
referencia, SCOR. fuente de nivel 1 se refiere a los productos almacenados o se refiere a los productos
hechos a la medida, o con los productos de la ingeniería a pedido. Para simplificar
Antes de considerar SCOR en sí, vamos a considerar por qué la membresía SCC las cosas, siempre hablaremos de SCOR como de tres niveles. El nivel 1 es la
fue motivado para desarrollar el marco en el primer lugar. Cada vez más, las cadena de suministro. Nivel 2 consiste en los procesos de alto nivel que componen
empresas están creando sistemas de cadena de suministro que cruzan los límites una cadena de suministro, incluyendo Fuente, Marca, Entrega y Devolución. Plan
de la empresa. Por lo tanto, no es raro que diez o veinte compañías se sienten para es un proceso SCOR adicional que describe la planificación de la gestión. Estos
procesos de Nivel 2 se definen por primera vez. Luego se especifica su variación, y
luego se descomponen en un conjunto de subprocesos de Nivel 3, como se ilustra Con SCOR, una empresa puede caracterizar rápidamente su arquitectura de
en la Figura 4.8. cadena de suministro. La figura 4.9 ilustra un mapa que los arquitectos de SCOR
usualmente dibujan para mostrar dónde se originan los materiales y cómo se
trasladan a los puntos de ensamblaje y luego se distribuyen a los clientes.
Figura 4.8.Los tres niveles de una arquitectura SCOR. Una vez que la cadena de suministro se describe mediante un mapa, se vuelve a
dibujar utilizando
El manual de referencia de SCOR define cada subproceso de Nivel 2 y Nivel 3 y La convención de diagramación SCOR ilustrada en la figura 4.10. El SCC se refiere
también indica qué procesos de planificación y soporte están típicamente a
vinculados a cada proceso o subproceso. El SCC no define un cuarto nivel, dejando El diagrama como un diagrama de hilo. En este diagrama, cada proceso de Nivel 2
la especificación de las actividades de Nivel 4 a empresas individuales. En otras en el suministro
palabras, SCOR define una arquitectura de la cadena de suministro y todos los Alimentando la cadena de suministro de la compañía Alpha. Las letras indican que
procesos de alto nivel y deja la implementación técnica de los procesos de Nivel 4 un proceso es un proceso Source (S), un proceso Make (M) o un proceso Deliver
a los miembros individuales. (D). Los números indican la variación.
Desarrollo de una arquitectura de cadena de suministro con SCOR
Por lo tanto, un S1 es un proceso de origen que se basa en productos almacenados
continuamente, mientras que un proceso de M2 es un proceso de fabricación que
se basa en la prestación de productos que están hechos a la medida. (Consulte la
Figura 4.6 para las designaciones). Un diagrama de hilos puede ser bastante más
complejo si la cadena de suministro involucra múltiples columnas de proveedores
y columnas de distribuidores. Del mismo modo, en los diagramas más completos,
también se introducen los procesos del Plan. En efecto, como Plan se refiere a un
esfuerzo de gestión de procesos. Para cada proceso básico que se muestra en el
diagrama de hilos, también hay un proceso Plan.
Observe que algunos subprocesos se producen dentro de varios procesos. Estos Otros Marcos:
subprocesos están marcados con un asterisco para resaltar el hecho. Por lo tanto,
la Gestión de Interfaz de Cliente-presumiblemente un conjunto de actividades de Apenas hemos considerado todos los marcos de arquitectura existentes
gestión de portal de clientes- es compartido por los procesos de Cumplimiento, disponibles. El gobierno de los Estados Unidos tiene uno y varios organismos
Aseguramiento y Facturación. De manera similar, un subproceso de Gestión de gubernamentales que tienen otros. El consorcio de la industria de seguros, ACORD,
Interfaz Proveedor / Asociado es compartido por estos mismos procesos. está trabajando en un marco para la industria de seguros, y probablemente hay
otros de los que aún no hemos oído hablar. El punto, sin embargo, es que las
Si no es un ejecutivo de telecomunicaciones, es posible que no esté familiarizado empresas que emprenden el desarrollo de una arquitectura de procesos de negocio
con algunos de los términos utilizados para describir los distintos subprocesos. Lo están hoy en condiciones de acelerar grandemente el proceso empezando con uno
importante es que esta arquitectura de procesos empresariales ilustra un marco de los marcos disponibles y luego adaptándolo a sus necesidades específicas.
suficientemente detallado para que un comité de arquitectura de procesos de
De las declaraciones de estrategia a una arquitectura de procesos