GESTIÓN DE PROCESOS DEL NEGOCIO
procesos empresariales de diversas maneras. En este libro, utilizaremos este
CICLO 2018-I
“Capítulo 4: Arquitectura de Procesos y Alineación Organizacional”
Capítulo 4 Arquitectura de Procesos y Alineamiento Organizacional
La segunda fase de la metodología empresarial de BPTrends se centra en la
creación de una arquitectura de procesos de negocio para la organización. Como
ya hemos sugerido, creamos una arquitectura de empresa separada para cada
cadena de valor, por lo cual, efectivamente, realmente estamos hablando de crear
una arquitectura de procesos de negocio para una cadena de valor
Figura 4.1 Metodología empresarial de BPTrends
Diferentes autores y diferentes empresas utilizan el término arquitectura de
término para referirnos a un conjunto de conocimientos sobre los procesos de
negocio que forman parte de una cadena de valor. El conocimiento está organizado
por una descomposición jerárquica de los procesos que conforman la cadena de
valor. A su vez, los procesos organizan información sobre las medidas de
rendimiento, los gestores de procesos y los recursos organizativos utilizados por los
distintos procesos.
Toda la arquitectura del proceso de negocio está organizada jerárquicamente para
que los ejecutivos puedan ver cómo se alinean los procesos específicos para apoyar
los objetivos estratégicos de la organización, las medidas del proceso y qué
recursos se requieren para qué procesos y viceversa.
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.
La cadena de valor se denomina generalmente proceso de Nivel 0. Los principales
procesos operativos dentro de una cadena de valor suelen ser procesos como
Diseño de Nuevos Productos, Venta de Productos a Clientes y Creación y Entrega
de Productos a Clientes (es decir, Cadena de Suministro). Cualquiera de estos
procesos de Nivel 1 puede subdividirse en varios procesos de Nivel 2. Así, el marco
SCOR del Consejo de Cadena de Suministro divide el proceso de la Cadena de
Suministro Operacional de Nivel 2 en: Recursos, Producción, Entrega y Devolución.
El uso de términos como superproceso y subproceso depende de donde se
empiece. De cualquier proceso arbitrario, el proceso más grande que lo contiene es
su superproceso. Del mismo modo, los procesos contenidos en el proceso arbitrario
se denominan sus subprocesos.

No hay límite técnico para la subdivisión de procesos. Es común ver procesos
divididos en tres o cuatro niveles. Es raro ver un proceso dividido en más de siete u
ocho niveles. Para nuestros propósitos, el proceso más pequeño que se diagrama
se llama una actividad. Hacemos esto simplemente porque los estándares de
proceso como UML y BPMN definen arbitrariamente un proceso que consiste en
actividades. Dicho esto, es común tener subdivisiones que no se diagrama y se
definen por esquemas u otras definiciones textuales. Por lo tanto, usamos los
términos pasos, tareas y procedimientos de forma suelta, o para describir los
subelementos de una actividad.
Figura 4.2 Una descomposición jerárquica de una cadena de valor, que sugiere
cómo el
"nivel de análisis" corresponde al nivel de proceso.
Otros autores definen estos términos de maneras alternativas y no hay, por
supuesto, ninguna forma definitiva de nombrar los niveles de proceso. Lo importante
es simplemente tener en mente que los procesos pueden ser jerárquicamente
arreglados y que usted necesita saber, al considerar un proyecto, si va a estar
analizando un proceso relativamente grande, como una cadena de suministro; Un
proceso mediano, como solicitar un préstamo o devolver un artículo; O un proceso
pequeño, como obtener una aprobación de tarjeta de crédito, o revisar una solicitud
de préstamo para completar.
Definición de una Arquitectura de Proceso de Negocios
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.
Los pasos clave involucrados en la creación de una arquitectura de procesos de
negocio son los siguientes:
➢ Identificar una cadena de valor específica.
➢ Determinar los objetivos estratégicos específicos que la cadena de valor
debe alcanzar.
➢ Determine cómo va a medir si la cadena de valor logra sus objetivos o no.
➢ Subdividir la cadena de valor en sus procesos principales (procesos de
nivel 1). Subdividir los procesos principales (procesos de nivel 1) en sus
subprocesos (procesos de nivel 2). Si procede, subdividir los procesos del
Nivel 2 en sus subprocesos (procesos del Nivel 3).
➢ Utilice una hoja de cálculo. Para cada proceso de Nivel 1, determine cómo
el proceso de nivel 1 será moderado. Determinar quién será responsable
del proceso. Determinar qué recursos están vinculados a cada proceso de
Nivel 1.
 ➢ Repita este procedimiento, utilizando hojas de cálculo nuevas, para cada
proceso de Nivel 2, y así sucesivamente.
Figura 4.3 Ilustra el encabezado de una hoja de trabajo de análisis de arquitectura
e indica la información que debe incluirse.
Figura 4.3 Una hoja de trabajo de análisis de arquitectura de Nivel 1.
En el capítulo 3 terminamos describiendo una cadena de valor en términos de tres
subprocesos principales, como se muestra en la Figura 4.4
Figura 4.4 Un diagrama de organización que muestra los procesos principales en
una cadena de valor.
Una vez que comenzamos a tratar de analizar un gran número de procesos y
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.
Figura 4.5 Descomposición horizontal de una cadena de valor en tres niveles de
proceso
Existen diferentes maneras de desarrollar una descomposición integral de una
cadena de valor. Uno puede comenzar con una sala llena de altos ejecutivos y un
pizarrón blanco y simplemente preguntar: "OK, ¿cómo se producen los widgets?
¿Por dónde empiezas? ¿Qué sucede a continuación? "
Este es el enfoque tradicional y, aunque lleva mucho tiempo, es eficaz, ya menudo
se plantea una gran cantidad de preocupaciones sobre cómo se hacen cosas
específicas. En muchos casos, los ejecutivos no se dan cuenta, antes de sentarse
y tratar de describir lo confuso y redundante que algunos de sus procesos. A
menudo, cada uno sólo se ha centrado en una u otra parte del proceso y nunca trató
de crear un diagrama que mostró cómo encajan todos en una cadena de valor.

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.

A continuación, el grupo de arquitectura debe definir los procesos de Nivel 1 que

comprenden la cadena de valor. El truco es mantenerlos simples y generales y
limitarlos a unos tres o siete procesos. La mayoría de los marcos genéricos se
enfocan en tres procesos de nivel 1: un proceso de diseño, un proceso de desarrollo
/ entrega de productos / servicios y un proceso de ventas / marketing / servicio.

Procesos básicos, de soporte y de gestión

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
organización independiente, un centro de costos o una cadena de valor
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
y servicios que vende a los procesos centrales de la empresa matriz.
Independientemente de que su empresa externaliza IT o la mantiene en casa, si la
considera como su propia cadena de valor y crea una arquitectura de procesos de
negocio independiente para describir los procesos de núcleo, soporte y
administración de TI, verá que facilita todo.
Obviamente, la misma lógica puede aplicarse a los otros procesos principales de
apoyo, incluidos los recursos humanos, las instalaciones y la contabilidad. Si sigue
este enfoque, dejará los procesos de soporte de las hojas de trabajo de arquitectura
de procesos de negocio que crea para sus cadenas de valor fundamentales y
describirá cada proceso de soporte principal como una arquitectura independiente
con sus propias hojas de trabajo.
Manejar los procesos de gestión es más complicado, porque la idea de los procesos
de gestión no ha sido muy bien pensada. Para empezar, necesitamos discriminar
entre dos tipos básicos de "procesos de gestión". En un caso, tenemos los procesos
o actividades que realizan los individuos que realmente administran los procesos en
el día a día. Por lo tanto, si consideramos la Figura 4.7, hay un individuo que es
responsable de administrar el proceso de Relleno de la acción. Ese individuo
planea, organiza, comunica, monitorea y controla el proceso de llenar la orden del
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
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
central como un proceso separado. Cuando se busca rediseñar o mejorar el
proceso, es necesario considerar las actividades de los empleados asignados al
proceso y, simultáneamente, las actividades del gerente que se encarga del
proceso. En la medida en que es útil discriminar estos procesos cotidianos de
gestión de procesos, se hace para definir los procedimientos estándar o de mejores
prácticas que deben seguir los administradores de procesos. Consideraremos las
prácticas de gestión de procesos estándar más adelante, cuando consideremos la
gestión de procesos y el establecimiento de grupos de soporte de BPM. En este
punto, sin embargo, simplemente ignoraremos estos procesos de gestión
cotidianos. Están tan estrechamente asociados con los procesos centrales que no
necesitan una representación independiente en nuestra arquitectura de procesos
de negocio.
Siguen existiendo algunos procesos generales de gestión que realizan funciones de
planificación, organización, comunicación o supervisión de la empresa. En esencia,
si la organización tiene un grupo de reglas de negocio que trabaja para definir las
políticas de la empresa y dictar las reglas de negocio que los procesos específicos
deben implementar, ese grupo y los procesos que implementa constituyen una
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.
Estos son procesos de gestión verdaderos que son independientes de los procesos
centrales en una cadena de valor normal. Las empresas sofisticadas querrán
analizar estos procesos de gestión para asegurar que funcionen de la manera más
eficiente y eficaz posible. Por lo tanto, debemos definirlos y documentar cómo
funcionan. La cuestión es dónde incluirlas. A diferencia de los procesos de soporte
estándar, como TI y recursos humanos, es difícil pensar en estos "procesos de
gestión" como un centro de coste o una empresa independiente. Es más fácil pensar
simplemente en ellos como actividades emprendidas por los altos directivos. Por el
momento, probablemente es mejor pensar simplemente en todos los "procesos de
gestión" que son independientes de procesos operativos específicos como su
propia "cadena de valor de gestión" y documentarlos en sus propias hojas de
trabajo. No es una solución muy elegante, pero es probablemente mejor que tratar
de asociarlos con una cadena de valor convencional.
Alineación de gerentes, medidas y recursos
A medida que se identifican los procesos, el grupo puede determinar quién es
responsable de administrar ese proceso. Si la empresa está orientada
funcionalmente, en el nivel más alto será frecuente que no haya un gestor claro para
los procesos de nivel 1. En cambio, los procesos se dividirán entre múltiples
departamentos, sin que nadie sea responsable de la coordinación general. Vamos
a pasar por alto cualquier otra discusión de la gestión de procesos en este punto y
retrasarla hasta llegar al Capítulo 5. Baste decir que, si el equipo tiene problemas
para asignar los gerentes a los procesos, eso debería estimular una discusión sobre
cómo se manejan los procesos en la organización.
A continuación, el equipo debe definir el objetivo de cada proceso de Nivel 1 y
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
llegar al siguiente capítulo.
La columna final de la hoja de cálculo pide al equipo de arquitectura que enumere
los recursos necesarios para soportar cada proceso de Nivel 1. Esto hace hincapié
en que el desarrollo de una arquitectura de procesos de negocio es una empresa a
largo plazo. Obviamente, el equipo de arquitectura no pudo identificar los trabajos
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
alineación de recursos durante el primer paso, y dejarlo hasta que toda la
arquitectura se entienda mejor. A medida que pasa el tiempo, la organización y los
interesados en los procesos encontrarán que sería útil determinar cómo se alinean
los diferentes recursos, y luego procederán a capturar información sobre la
alineación de esos recursos. Muchas organizaciones crean una arquitectura y, a
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
caso, nadie se propone enumerar cada aplicación ERP que utiliza cada proceso,
pero a medida que se rediseñan los procesos, se captura la información sobre el
soporte ERP y se agrega a la base de datos de arquitectura.
Algunos de los tipos de recursos que las organizaciones podrían tratar de alinear
con el Nivel 1 o los procesos de Nivel 2 incluyen:
➢ Alineamiento con estrategias y metas corporativas. Algunas
organizaciones listan información sobre las estrategias específicas de nivel
1 y las partes interesadas observan cómo las estrategias específicas
apoyan las estrategias corporativas. Otros enumeran a todos los
interesados que están interesados en cada proceso específico del Nivel 1.
➢ Alineación con otros procesos. Hasta ahora hemos enfatizado procesos
básicos u operativos. Una vez que se definen los procesos operativos,
algunas empresas proceden a describir los procesos de gestión y soporte
e indican qué procesos básicos u operativos dependen de qué procesos
de gestión o soporte. Vamos a considerar esto en más detalle en el
próximo capítulo cuando hablamos de gestión. Muchas empresas están
interesadas en identificar subprocesos específicos o actividades que se
repiten en diferentes procesos de Nivel 1 o 2. Supongamos, por ejemplo,
que un proceso de nivel 1 incluye un subproceso de nivel 3 o 4 que se
denomina: Determinar crédito de cliente. Imaginemos, además, que la
determinación del crédito al cliente ocurrió en varios procesos de Nivel 1 y
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
al cliente, para que la actividad pudiera ser estandarizada y el mismo
software podría ser usado siempre que sea posible. Por lo tanto, la simple
enumeración de subprocesos y actividades que se producen en múltiples
procesos de Nivel 1 puede ser muy útil.
➢ Alineamiento con políticas y reglas. Muchas organizaciones enumeran
las políticas corporativas que se aplican a procesos específicos de Nivel 1
o 2. A medida que el análisis se hace más completo, las organizaciones
pueden enumerar las reglas de negocio específicas que se utilizan en
subprocesos específicos y, a continuación, comprobar que las políticas y
las reglas se aplican de forma coherente.
➢ Alineación con recursos de TI. Muchas organizaciones indican qué
aplicaciones de software o qué bases de datos se utilizan para estos
procesos. Si el esfuerzo por correlacionar los recursos de TI con procesos
empresariales específicos se vuelve muy elaborado, a menudo se
denomina arquitectura empresarial. Si una empresa utiliza aplicaciones
ERP, la arquitectura del proceso suele estar impulsada o soportada por
arquitecturas de procesos sugeridas por los proveedores de ERP.
➢ Alineación con recursos de recursos humanos. Muchas
organizaciones definen qué funciones o trabajos están asociados con los
procesos de Nivel 2 o 3. Si esto se lleva a cabo, se pueden definir las
descripciones de tareas asociadas con los procesos o definir las
competencias de los trabajos. Del mismo modo, algunas organizaciones
de la lista de los documentos de los empleados y los programas de
formación que se dan en apoyo en cada proceso específico.
➢ Alineación con Sarbanes-Oxley, ISO 9000 y diversos estándares de
gestión de riesgos. Las organizaciones son cada vez más responsables
de reunir y mantener información sobre las decisiones y los riesgos
involucrados en procesos específicos. Esta información puede colocarse
naturalmente en la base de datos de la arquitectura de procesos de
negocio. A medida que pasa el tiempo y se recopila más información, las
organizaciones con completas arquitecturas de procesos de negocios se
 encuentran invirtiendo el proceso y utilizando la base de datos de la
arquitectura para generar la información requerida por las agencias
externas.
Una arquitectura de procesos de negocio es una herramienta de gestión. Una vez
que se define y luego se rellena con datos actualizados, se puede utilizar, al igual
que otras bases de datos, para responder a preguntas ad hoc que los ejecutivos
necesitan respuesta. Puede ser utilizado para apoyar a aquellos involucrados en el
desarrollo de estrategias corporativas y puede ser utilizado por un grupo de BPM
para identificar procesos que no están cumpliendo sus objetivos y que necesitan
ser rediseñados. La información que se coloque en la base de datos de arquitectura
de procesos de negocio dependerá de cómo lo utilice la empresa. La mayoría de
las empresas que han creado arquitecturas encuentran que facilitan a los gerentes
la conceptualización de sus organizaciones en términos de procesos, lo que lleva a
solicitar más y más información sobre los procesos que soporta la empresa.
Definición de una arquitectura de procesos empresariales
Uno crea una arquitectura de proceso de negocio descomponiendo una cadena de
valor en procesos y subprocesos. Como señalamos anteriormente, los esfuerzos de
análisis de procesos son cada vez más de alto nivel y están siendo apoyados por
el uso de marcos de procesos. En este punto, queremos ver los marcos de proceso
en un poco más de detalle.
El Marco SCOR del Consejo de la Cadena de Suministro:
El Consejo de la Cadena de Suministro (SCC) fue establecido como un consorcio
sin fines de lucro en 1996. Hoy en día, es una organización mundial con más de
700 miembros. El Consejo realiza reuniones que permiten a las empresas reunirse
para discutir problemas y oportunidades en la cadena de suministro. Además, ha
estado trabajando en un marco estándar de la cadena de suministro o modelo de
referencia, SCOR.
Antes de considerar SCOR en sí, vamos a considerar por qué la membresía SCC
fue motivado para desarrollar el marco en el primer lugar. Cada vez más, las
empresas están creando sistemas de cadena de suministro que cruzan los límites
de la empresa. Por lo tanto, no es raro que diez o veinte compañías se sienten para
averiguar cómo sus empresas trabajarán juntas para trasladar los materiales a los
fabricantes y luego a los distribuidores y, en última instancia, a los clientes. Si cada
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
Consejo de la Cadena de Suministros decidió definir un conjunto de alto nivel de los
nombres de procesos de la cadena de suministro que todos podrían utilizar. Cada
empresa podría seguir utilizando los nombres de procesos particulares que eligiera,
pero en conversaciones con las otras empresas, cada una podría utilizar el
vocabulario estándar definido por SCOR. Posteriormente, el modelo SCOR se
amplió para que no sólo defina los procesos centrales, sino que también define
procesos de gestión y soporte y proporciona medidas de rendimiento definidas con
precisión para cada proceso. Utilizando la información de rendimiento, las empresas
pueden definir quién pasará qué a quién y cuándo, de una manera inequívoca. Una
vez que se estableció el sistema, los miembros de SCC procedieron a proporcionar
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
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
eficaces y se convirtió en una metodología general que se puede utilizar para definir
rápidamente una arquitectura de cadena de suministro completa con medidas de
referencia.
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
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
valor como Nivel 0. Luego nos referiremos a la cadena de suministro como un
proceso de Nivel 1. Para hacer las cosas aún más complejas, SCOR subdivide la
cadena de suministro en tres "niveles", pero, de hecho, uno de los niveles no es una
descomposición del nivel superior, sino que requiere que el modelador defina el
proceso de nivel superior en términos de Una de tres variaciones. El proceso de la
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
las cosas, siempre hablaremos de SCOR como de tres niveles. El nivel 1 es la
cadena de suministro. Nivel 2 consiste en los procesos de alto nivel que componen
una cadena de suministro, incluyendo Fuente, Marca, Entrega y Devolución. Plan
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
en la Figura 4.8.
Figura 4.8.Los tres niveles de una arquitectura SCOR.
El manual de referencia de SCOR define cada subproceso de Nivel 2 y Nivel 3 y
también indica qué procesos de planificación y soporte están típicamente
vinculados a cada proceso o subproceso. El SCC no define un cuarto nivel, dejando
la especificación de las actividades de Nivel 4 a empresas individuales. En otras
palabras, SCOR define una arquitectura de la cadena de suministro y todos los
procesos de alto nivel y deja la implementación técnica de los procesos de Nivel 4
a los miembros individuales.
Desarrollo de una arquitectura de cadena de suministro con SCOR
Con SCOR, una empresa puede caracterizar rápidamente su arquitectura de
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.9. Un mapa de la geografía como es de la cadena de suministro de una
empresa.
Una vez que la cadena de suministro se describe mediante un mapa, se vuelve a
dibujar utilizando
La convención de diagramación SCOR ilustrada en la figura 4.10. El SCC se refiere
a
El diagrama como un diagrama de hilo. En este diagrama, cada proceso de Nivel 2
en el suministro
Alimentando la cadena de suministro de la compañía Alpha. Las letras indican que
un proceso es un proceso Source (S), un proceso Make (M) o un proceso Deliver
(D). Los números indican la variación.
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.

Figura 4.11. Los atributos de rendimiento SCOR y las métricas de nivel 1.

Figura 4.10. Un diagrama de rosca de SCOR de un proceso simple de la cadena
Varias organizaciones que rastrean los puntos de referencia están trabajando con
de fuente.
el Consejo de la Cadena de Suministro y pueden proporcionar puntos de referencia
genéricos para las medidas de SCOR para industrias específicas. Si una empresa
El Consejo de la Cadena de Suministros ofrece a los miembros un manual de
desea datos de referencia específicos, necesita contratar con uno de los grupos de
referencia que define cada proceso y subproceso de la cadena de suministro.
evaluación comparativa.
Además, el manual describe medidas de rendimiento que son apropiadas para cada
En la figura 4.12, ilustramos lo que SCOR se refiere como SCORcard. Muestra los
proceso en cada nivel. El SCC divide todas las medidas de rendimiento en cinco
atributos de rendimiento, un conjunto de datos históricos y los datos de referencia
categorías generales, que luego se agrupan en métricas externas de cara al cliente
para la cadena de suministro hipotética de una empresa.
o métricas internas. La Figura 4.11 proporciona una visión general de alto nivel de
las medidas que se definen para la cadena de suministro en su conjunto (el proceso
En la columna de la derecha, el equipo ha hecho algunos "guestimates" sobre qué
de Nivel 1). Nos vamos a centrar en medidas aquí, pero basta con decir que se
clase de valor Alpha podría alcanzar, asumiendo que podría mover su proceso de
puede utilizar la métrica SCOR para generar rápidamente una lista de interconexión
la cadena de fuente más cercano al promedio para su industria. SCOR califica la
de métricas para toda una arquitectura de la cadena de suministro.
comparación del desempeño histórico real de la empresa con los puntos de
referencia para la industria de la compañía como un análisis de brecha y lo usa para
determinar si el rediseño o las mejoras en la cadena de suministro de As-Is
justificarán realmente una inversión.
Figura 4.12. Un SCORcard con datos reales y de referencia, con algunas conjeturas
sobre el valor que se podría lograr mediante el rediseño de la cadena de suministro
que se analiza
Una vez que el equipo de SCOR ha examinado los datos históricos de nivel 1 y, en
algunos casos, de nivel 2, tal y como están, está en condiciones de decidir si se
debe cambiar la cadena de suministro. De hecho, ahora está listo para revisar el
enfoque existente de la organización para su cadena de suministro y, si es
necesario, definir una nueva estrategia de cadena de suministro y establecer
objetivos, prioridades y un presupuesto para cualquier esfuerzo de rediseño. El uso
de la tarjeta SCOR proporciona una buena ilustración de la potencia del enfoque de
la arquitectura. Una vez que una empresa tiene una visión completa de todos sus
procesos y sólidos datos de desempeño, se posiciona para considerar cómo cada
uno de los procesos está realizando, compararlos con puntos de referencia y luego
decidir qué intervención posible produciría el resultado más significativo. Esto ilustra
el sentido en el que una arquitectura es una herramienta de gestión.
La extensión de SCOR
La siguiente parte de la historia de SCOR está estrechamente relacionada con
Joseph Francis y la fusión Hewlett-Packard-Compaq. La fusión de HP-Compaq fue
anunciada en septiembre de 2001. Los dos años anteriores habían atestiguado una
depresión importante en ventas, que había forzado muchas compañías de TI a
reevaluar sus estrategias. La fusión propuesta de dos empresas líderes de TI -la
mayor fusión de TI hasta la fecha- representó una importante iniciativa estratégica
por parte de los equipos directivos de ambas compañías para cambiar la dinámica
general del mercado de TI.
HP fue un líder en servidores de gama media, en PCs y portátiles, y en impresoras.
También fue un líder en servicios de integración y outsourcing y tuvo una reputación
mundial de tecnología de vanguardia. Al mismo tiempo, sin embargo, HP no era lo
suficientemente grande como para competir por los mayores contratos de servicios,
que normalmente iban a mayores competidores como IBM. Además, las proezas de
marketing de HP habían disminuido en los últimos años. En 2001, por ejemplo, HP
tenía unas 6.000 personas en marketing, mientras que los competidores de tamaño
similar manejaban con un tercio del total. Compaq era aún más fuerte que HP en
ventas de PC y portátiles, pero carecía de la fuerza de HP en todas las demás áreas.
Compaq había adquirido Tandem Computers and Digital Equipment a finales de los
años 90 en un esfuerzo por diversificar, pero nunca había logrado utilizar las
fortalezas de Tandem o Digital en computadoras, tecnología o consultoría de rango
medio para alcanzar la presencia en el mercado que esperaba obtener cuando Hizo
esas adquisiciones. Por otro lado, Compaq era conocido por sus agresivas
capacidades de marketing.
La fusión de las dos empresas daría lugar a una empresa significativamente mayor.
Juntos, HP y Compaq estarían en condiciones de dominar el mercado de las ventas
de PC, portátiles, servidores e impresoras. Al mismo tiempo, la empresa combinada
sería casi tan grande como IBM y, por lo tanto, estaría bien posicionada para
competir en igualdad de condiciones para los contratos de servicios y de
outsourcing más grandes. La nueva empresa también estaría en la posición de
exigir a los proveedores que le ofrezcan los mayores descuentos posibles. Además,
dado que había un considerable solapamiento en el área de PC, las dos compañías
esperaban sacar unos 2.500 millones de dólares en ahorros anuales, al tiempo que
creaban una organización más ágil y agresiva.
Desde el principio, la fusión propuesta era controvertida. Los argumentos acerca de
la sabiduría de la fusión y la lucha por poderes que siguieron han sido ampliamente
reportados en la prensa popular. En definitiva, de hecho, la fusión real fue más
suave de lo que se esperaba y dio lugar a mayores ahorros que los que planearon
la fusión esperaba. Como admitieron los más fuertes oponentes de la fusión, la
planificación que precedió a la fusión fue excelente.
Lo que nos interesa es el proceso de planificación que ayudó a que la fusión fuera
exitosa. Específicamente, queremos considerar las actividades del equipo de
planificación de la fusión que planificó la integración de los procesos de la cadena
de suministro de HP-Compaq. Tan pronto como la fusión se anunció formalmente,
se creó una nueva organización para planificar la fusión. Esta organización de fusión
en última instancia, incluyó a unos 1.000 empleados de las dos empresas. Los
empleados se reunieron en lo que se conoce como un ambiente de sala limpia. En
efecto, estaban separados del trabajo cotidiano de HP y Compaq, colocados en un
entorno aislado, proporcionaron información detallada sobre ambas compañías y
pidieron desarrollar un plan de fusión.
La organización de la fusión estaba encabezada por un comité ejecutivo que tomaba
decisiones estratégicas de alto nivel y, finalmente, aprobó todas las
recomendaciones detalladas de los equipos más especializados. Los informes al
comité ejecutivo fueron ocho equipos que se centraron en áreas específicas de
preocupación. Había equipos para infraestructura de TI, cadena de suministro,
ventas / órdenes, diseño de productos, comunicaciones / marketing, finanzas,
recursos humanos y servicios / soporte.
Algunos de los equipos carecían de un marco general y tenían que crear un nuevo
vocabulario común y una forma estándar de identificar los procesos existentes. Por
suerte, los gerentes de HP y Compaq que eran miembros del equipo de Supply
Chain estaban familiarizados con el trabajo del Consejo de la Cadena de Suministro
(SCC). El equipo de HP-Compaq Supply Chain se dio cuenta de que podía utilizar
SCOR para simplificar en gran medida su tarea. SCOR proporcionó un enfoque
estándar que podría utilizar para caracterizar y medir rápidamente los procesos de
la cadena de suministro tanto de HP como de Compaq.
Al acordar previamente el mapeo de los procesos de ambas compañías al modelo
SCOR y utilizar el vocabulario y las medidas estándar de SCOR, el equipo HP-
Compaq logró cumplir en un mes lo que de otro modo habría tardado muchos
meses.
La facilidad de uso de SCOR fue fundamental para el trabajo realizado por el equipo
de TI de Supply Chain durante la fusión. SCOR hizo posible que el equipo analizara
rápidamente todas las cadenas de suministro de HP y Compaq para todas las
regiones y líneas de productos. Este análisis, a su vez, hizo posible que el equipo
de TI de Supply Chain comparara con precisión un proceso de Compaq con un
proceso de HP para líneas de productos similares, para determinar lo que cada
proceso realmente logró.
El grupo HP-Compaq Supply Chain fue capaz de definir todas sus cadenas de
suministro rápidamente, basándose simplemente en las definiciones de nivel 1 de
SCOR. En efecto, todas las cadenas de suministro se dividieron rápidamente en
procesos de Sourcing, procesos de Fabricación y Entrega, así como algunos
procesos adicionales de planificación y habilitación. Una vez hecho esto, se
identificaron las aplicaciones de software de alto nivel que soportaban cada uno de
estos procesos.
SCOR proporciona un conjunto bien definido de medidas para cada uno de los
procesos de Nivel 1. Estas medidas están vinculadas a medidas financieras
establecidas que ambas empresas han seguido durante años. Así, en la mayoría
de los casos, se utilizó simplemente las medidas del Nivel 1 de SCOR para
comparar dos líneas regionales para determinar qué línea era la más eficiente y
rentable. Si una línea era claramente más eficiente que la otra, entonces el grupo
de TI de la Cadena de Suministro tendía a seleccionar simplemente las aplicaciones
que soportaban el proceso más eficiente.
Aquellos familiarizados con la manera en que los técnicos pueden discrepar sobre
las virtudes de las aplicaciones de software competidor pueden imaginar fácilmente
que el grupo de TI de la cadena de suministro podría haberse convertido en un
escenario de intensos argumentos entre los defensores de HP y Compaq de
aplicaciones de software alternativas. El equipo de TI de la Cadena de Suministros
sabía que si permitían que la discusión se concentrará en características técnicas
específicas nunca lograrían su tarea.
Además, una discusión técnica no aseguraría que la aplicación elegida estuviera
alineada con los objetivos corporativos. En su lugar, el grupo sabía que era
importante que su trabajo se centra en el valor que las diversas aplicaciones
entregadas a la empresa. En efecto, el grupo decidió seleccionar aquellas
aplicaciones que apoyaban los procesos más eficientes, sin tener en cuenta a qué
empresa apoyaba actualmente la aplicación, ni a qué departamentos estaban
involucrados.
Algunas de las medidas se centran en los resultados externos y algunos se centran
en la eficiencia interna. En cada caso, el CCS ha definido definiciones precisas de
las medidas. Ninguna organización desearía aplicar todas estas medidas a un
proceso o subproceso SCOR determinado. En cambio, el SCC tiene una
metodología que ayuda a los profesionales a alinear las medidas que consideran
con los objetivos estratégicos que la compañía está tratando de lograr con un
proceso determinado de la cadena de suministro. Considere el objetivo de una
determinada línea de productos. Si la empresa quería competir en el mercado de
esa línea de productos como proveedor de bajo costo, se centraría en mantener
una cantidad mínima de inventario, ya que el bajo inventario es una de las maneras
de mantener bajos los costos. Por otro lado, si la empresa estaba comprometida
con el servicio y quería asegurar que los clientes siempre pudieran obtener lo que
querían, tendría que aceptar mayores costos de inventario y se centraría, en
cambio, en satisfacer las solicitudes de los clientes. Diferentes estrategias requieren
diferentes medidas. El grupo empresarial Supply Chain tomó la mayoría de las
decisiones sobre estrategias de marketing para las líneas de productos combinados
y el grupo de TI de la cadena de suministro luego seleccionó las medidas
apropiadas y las utilizó para comparar el comportamiento de las líneas de productos
HP y Compaq existentes.
En algunos casos, dos líneas regionales competidoras parecen ser igualmente
eficientes y eficaces cuando se analizan con medidas de Nivel 1. En esos casos, el
equipo de TI de la Cadena de Suministro ampliará su esfuerzo y modelará los
procesos al Nivel 2 de SCOR o incluso, en muy pocos casos, al Nivel 3.
Aproximadamente el 20% del tiempo total utilizado por el equipo de la Cadena de
Suministro se utilizó en procesos de modelado, medición de ellos, aplicación de
criterios y juicios sobre qué aplicaciones ahorrar y qué descartar.
Una vez que el grupo de Cadena de Suministro había identificado líneas de
productos para mantener, modelar los procesos y luego evaluar y seleccionar
aplicaciones para mantener, fue posible retroceder de los procesos específicos de
la cadena de suministro que se está evaluando e identificar una arquitectura
genérica de cadena de suministro para la combinación empresa. En efecto, esta
arquitectura identificó los procesos de suministro comunes, derivados de SCOR, y
las aplicaciones comunes que la empresa fusionada podría eventualmente
estandarizar en, en todo el mundo. Las aplicaciones identificadas no eran nuevas
aplicaciones que adquiriría la empresa fusionada, sino aplicaciones que ya están
siendo utilizadas con líneas de productos exitosas que la compañía estandarizaría
y migraría para minimizar el número de aplicaciones que el nuevo HP necesitaría
soportar.
Al final de esta fase, el grupo de TI de Cadena de Suministro había identificado
todas las líneas de productos que debían ser soportadas en la empresa fusionada,
había identificado todas las aplicaciones que debían mantenerse y las que debían
ser retiradas e identificó un conjunto De los estándares arquitectónicos generales
que la compañía se movería hacia tan pronto como sea posible.
Otros equipos de HP-Compaq hicieron sus recomendaciones, pero las
recomendaciones del equipo de Supply Chain se destacaron porque se basaron en
un análisis de los procesos involucrados y números duros en el desempeño de los
procesos. Las recomendaciones del equipo de Supply Chain para utilizar
aplicaciones de software específicas se justificaron por el desempeño de los
procesos que habían utilizado esas aplicaciones. La lógica de negocio detrás del
trabajo del equipo de la Cadena de Suministro llevó al nombramiento del líder del
equipo, Joe Francis, al jefe del nuevo programa de la mejora del proceso del
negocio de HP.
La extensión de SCOR en HP
A Joe Francis le impresionó cómo el marco SCOR había facilitado su análisis de los
procesos existentes de la cadena de suministro. Dado que su nuevo trabajo
requería que mirara otros procesos en HP, montó un equipo y comenzó a desarrollar
marcos, como SCOR, para marketing, ventas, desarrollo de nuevos productos y
para varios procesos de soporte. En 2003, en parte debido al trabajo que había
hecho durante la fusión HP-Compaq, Joe Francis fue elegido presidente de la junta
de directores del SCC.
Hacia 2003 HP había desarrollado varios marcos. Sin embargo, a diferencia del
marco SCOR, estos nuevos marcos sólo habían sido desarrollados por el personal
de HP y no había puntos de referencia disponibles para usar con ellos. Para
remediar esto, Joe Francis persuadió a HP para que ofreciera los marcos que
habían desarrollado al SCC para alentar al SCC a expandirse más allá de su
enfoque en la cadena de suministro y eventualmente ofrecer un marco completo de
cadena de valor. Hoy en día, el SCC está avanzando más allá de SCOR y ha creado
estándares iniciales para un modelo DCOR (cadena de diseño) y un modelo CCOR
(cadena de clientes). Así, en el transcurso de los próximos años, a medida que los
miembros de SCC utilicen estos nuevos marcos e informen sobre sus resultados,
deberían estar disponibles puntos de referencia para todos los procesos básicos de
una cadena de suministro típica. Esto, a su vez, significa que será posible que una
empresa caracterice rápidamente toda una arquitectura utilizando procesos
estándares y comparados.
Otros enfoques
Al mismo tiempo que el SCC decidió lanzar su extensión de SCOR, un grupo
separado de ex miembros de SCC creó un nuevo grupo para extender SCOR en un
marco completo de la cadena de valor. Este grupo, el Value-Chain Council (VCC),
ha creado su propio modelo, el Value Reference Model (VRM) 1, que es similar al
SCOR pero en algunos aspectos mejor integrado. Obviamente, con SCOR tan bien
establecida, el esfuerzo del SCC se ha centrado en la adición de nuevos procesos
dejando intacto el actual modelo SCOR. El Consejo de la Cadena de Valor pudo
comenzar de cero y realizó algunos cambios en SCOR para simplificar el marco
general. La figura 4.13 ilustra el enfoque de VRM.
Figura 4.13. El marco de VRM del Consejo de Cadena de Valor.
Obsérvese que el modelo de VRM no discrimina la cadena de suministro como un
proceso: hemos demostrado dónde podría insertarse entre los niveles 1 y 2 de VRM,
sino que simplemente trata los cuatro procesos de Level 2 de SCOR. Fuente (Buy),
Make, Deliver (Fulfill) Y Retorno (Apoyo), como cuatro de los ocho procesos
principales. En el nivel superior, VRM discrimina entre los procesos de Planificación
(los denominaríamos procesos de Gestión), los procesos de Ejecución (los
llamaríamos Core) y los procesos de Gestión (que llamaríamos procesos de
soporte). Los detalles del modelo VRM en evolución no son demasiado importantes.
Lo importante es que VCC está trabajando en un marco de cadena de valor
completo. Así como SCOR tiene procesos y medidas, VRM incluye tanto un marco
de proceso como un esquema de medición de rendimiento.
La Figura 4.14 sugiere cómo los procesos Plan y Manage soportan el proceso de
ejecución básico.
Figura 4.14 Planificar y gestionar los procesos asociados con el proceso de
ejecución.
El SCC tiene 700 miembros, un presupuesto anual establecido, y mucho
dinamismo. Por otra parte, su membresía ha estado compuesta históricamente de
administradores de la cadena de suministro y muchos de esos miembros han
resistido los esfuerzos del SCC para expandirse a otras áreas del proceso. El VCC
es nuevo y tiene sólo unos pocos miembros. Tiene la ventaja de empezar desde
cero y aprovechar todo lo que el SCC ha aprendido, pero tiene el reto de reclutar
miembros y luego construir una base de datos de referencias fiables. Por el
momento, las dos organizaciones están compitiendo y cada una estimulando los
esfuerzos del otro. Con suerte, en unos pocos años se producirá una fusión y
resultará en un marco de la cadena de valor que combina lo mejor de los dos
enfoques.
arquitectura. Una de las principales ventajas de los sistemas de comercio
electrónico es que integran la gestión y las operaciones, y es importante que todos
tengan una visión general clara de todos los procesos si quieren ver cómo puede
producirse la integración.
La figura 4.15 muestra una versión de la estructura eTOM, reordenada para que
coincida con el formato que usamos en este libro. En efecto, giramos el diagrama
básico de eTOM 90 grados hacia la derecha. El cliente se movió a la derecha del
diagrama para que los procesos fluyan ahora de izquierda a derecha y las unidades

El marco del eTOM del Foro TeleManagement :

Otra aproximación a un marco completo de la cadena de valor es proporcionada por

el TeleManagement Forum, un consorcio de compañías de telecomunicaciones. Su
estructura está altamente adaptada a las necesidades de las empresas de
telecomunicaciones. Por lo tanto, no puede ser utilizado por las no-
telecomunicaciones, pero sí proporciona un enfoque integral para las empresas de
telecomunicaciones.

Un grupo del TeleManagement Forum ha dedicado varios años a desarrollar una

arquitectura de proceso para las empresas de telecomunicaciones. Se supone que
ninguna empresa específica tendrá exactamente los mismos procesos identificados
por el TeleManagement Forum, y que probablemente usará nombres diferentes
para los distintos procesos. Por lo tanto, se trata de una arquitectura de referencia
en lugar de una arquitectura de un negocio específico. Se supone que a medida
que pasa el tiempo, la mayoría de los miembros se moverán hacia esta arquitectura
de proceso y que, durante el mismo período, los vendedores adaptarán los
productos para implementar muchos de los procesos definidos por el modelo.

funcionales fluyan hacia abajo, como lo hacen típicamente los organigramas.

La arquitectura que describimos es la tercera iteración que el Foro de
TeleManagement ha desarrollado. Esta última iteración, llamada eBusiness
Telecom Operations Map (eTOM), se basa en trabajos anteriores que sólo
Figura 4.15. La arquitectura de referencia eTOM del TeleManagement Forum.
buscaban definir los procesos operativos dentro de las compañías de
telecomunicaciones. Sin embargo, a medida que las compañías empezaron a
La figura 4.15 proporciona una idea de cómo está organizada una compañía de
implementar aplicaciones de e-business, descubrieron que los procesos incluidos
telecomunicaciones. En esencia, una telecom vende tiempo en su red a los clientes.
en la administración general y de la empresa tenían que ser agregados a la
Dado que el tiempo se vende y se controla mediante computadoras que rastrean el
acceso telefónico, Servicio y Recurso son funciones importantes. Dado que casi
todas las llamadas de larga distancia cruzan múltiples redes, los acuerdos con otras
compañías de telecomunicaciones-socios-son muy importantes. Sospechamos que
las compañías telefónicas reales podrían subdividir sus departamentos de manera
algo diferente, colocando marketing y servicio en departamentos separados, pero
recuerde que la mayoría de las ventas de teléfonos y las solicitudes de servicio
llegan a través de un centro de llamadas común. En cualquier caso, la figura 4.15
proporciona una idea de cómo un grupo de gerentes de telecomunicaciones
consideró que podrían representar a sus organizaciones.
Al mirar la versión modificada del diagrama eTOM, está claro que los tres bloques
sombreados son grupos de procesos de negocio. Dentro de cada grupo, hay
subprocesos. Al dividir los procesos de la manera que tienen, no está claro si las
operaciones representan una cadena de valor o no. La clave sería si se pudieran
agregar los costos de todos los procesos dentro de la caja de Operaciones para
determinar el costo total y el margen de beneficio en una línea de productos, en
este caso, el servicio telefónico. Si pudiera, eso significaría que todo en las dos
cajas sombreadas inferiores podría agruparse como sobrecarga y asignarse a una
única cadena de valor-Operaciones telefónicas.
Lo importante no es la notación, sin embargo, pero el hecho de que la Figura 4.14
proporcionaría un comité de arquitectura de procesos de telecomunicaciones con
una visión general de la empresa. Cada comité de arquitectura de procesos
empresariales necesita algo similar a la figura 4.15 para tener una manera estándar
de describir los procesos de su empresa e identificar procesos que requieren
cambios cuando se anuncian nuevas estrategias y metas.
Observe que algunos subprocesos se producen dentro de varios procesos. Estos
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
gestión de portal de clientes- es compartido por los procesos de Cumplimiento,
Aseguramiento y Facturación. De manera similar, un subproceso de Gestión de
Interfaz Proveedor / Asociado es compartido por estos mismos procesos.
Si no es un ejecutivo de telecomunicaciones, es posible que no esté familiarizado
con algunos de los términos utilizados para describir los distintos subprocesos. Lo
importante es que esta arquitectura de procesos empresariales ilustra un marco
suficientemente detallado para que un comité de arquitectura de procesos de
telecomunicaciones que estuviera familiarizado con su propia organización pudiera
ser razonablemente eficiente para determinar qué procesos o subprocesos
necesitarían ser cambiados para lograr cambios específicos en Estrategia y
objetivos de la empresa. Uno podría imaginar fácilmente un documento de
acompañamiento que proporcionara descripciones escritas cortas de cada uno de
los subprocesos.
La figura 4.15 plantea dos cuestiones que consideraremos con más detalle más
adelante en este libro. En primer lugar, sugiere la posibilidad de un sistema de
gestión matricial. Alguien suele ser responsable de procesos completos como
Cumplimiento. Esa persona piensa en cómo todos los subprocesos de
Cumplimiento trabajan juntos para entregar servicios al cliente de una manera
suave y eficiente. Alguien más probablemente sea responsable de la Administración
y Operaciones del Servicio. Los empleados que trabajan en el subproceso de
configuración y activación de servicios probablemente informen al administrador de
servicios y gestión de operaciones. Por lo tanto, un gerente trabaja para asegurar
que el proceso completo funciona de manera eficiente.
Otro es responsable de los empleados que realizan algunos de los subprocesos
dentro del proceso de Cumplimiento y dentro de otros procesos también.
La otra cuestión que es obvia cuando empezamos a discutir un marco como eTOM
es cuántas veces aparece el proceso de la palabra. Cuando el gráfico es tan simple
como el de la figura 4.15, podemos vivir con grupos de procesos, procesos y
subprocesos. Ya hemos visto cómo el proceso final es una cadena de valor. La
mayoría de las organizaciones sólo tienen unas pocas cadenas de valor.
Sospechamos que todo el marco de eTOM realmente sólo representa una cadena
de valor que ofrece servicios de telecomunicaciones a los clientes.
Otros Marcos:
Apenas hemos considerado todos los marcos de arquitectura existentes
disponibles. El gobierno de los Estados Unidos tiene uno y varios organismos
gubernamentales que tienen otros. El consorcio de la industria de seguros, ACORD,
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
empresas que emprenden el desarrollo de una arquitectura de procesos de negocio
están hoy en condiciones de acelerar grandemente el proceso empezando con uno
de los marcos disponibles y luego adaptándolo a sus necesidades específicas.
De las declaraciones de estrategia a una arquitectura de procesos

Empezamos con una visión general de cómo se desarrolla una arquitectura de

procesos de negocio. Vimos que se podría utilizar una descripción de proceso para
organizar la recopilación y alineación de datos sobre los procesos. Luego
consideramos cómo un equipo de desarrollo de arquitectura de proceso real puede
utilizar un marco de proceso como SCOR, VRM o eTOM para acelerar el proceso
de desarrollo arquitectónico. Los marcos no proporcionan una estrategia de gestión,
ni sugieren alineaciones específicas, sino que proporcionan una descomposición
sistemática de los procesos de alto nivel y sugieren medidas de rendimiento que
pueden utilizarse para todos los procesos en una arquitectura. Uno puede utilizar
un marco para llenar rápidamente las hojas de trabajo o rellenar una base de datos
de procesos empresariales y luego adaptarlo y comenzar a alinear la información
del recurso. Así, en un tiempo muy corto, una empresa puede comenzar a
beneficiarse del tipo de análisis y priorización del proyecto que se puede derivar de
tener una arquitectura de proceso eficaz.