Página 1
CAPÍTULO CUATRO
Arquitectura empresarial
El término "arquitectura empresarial" puede ser muy confuso. A finales de la década de 1970, cuando Geary
Rummler comenzó a dar cursos sobre cómo mejorar el rendimiento corporativo, él
comenzaría un análisis de los problemas corporativos trabajando con un equipo de altos ejecutivos
agentes para crear lo que inicialmente llamó un "Mapa de relaciones". Este enfoque derivó
directamente de la insistencia de Rummler en la perspectiva de los sistemas. En esencia, una organización
ción era un sistema que tomaba entradas y generaba salidas. Hoy, podríamos llamarlo un
"Proceso" pero se trata de lo mismo. La Figura 4.1 ilustra una relación de organización
mapa, al igual que los que Rummler usa en su libro clásico, Mejorando el rendimiento .
En esencia, Rummler usó un Mapa de Relaciones para ayudar a los gerentes superiores a comprender
cómo los principales procesos en una organización se relacionan con entidades clave fuera de la organización
ción Quería que los gerentes tuvieran una visión general de cómo todo estaba conectado
a todo lo demás.
A principios de la década de 1990, Michael Hammer introdujo un enfoque ligeramente diferente, cuando
él escribió Business Process Reengineering . Hammer se basó en el trabajo de Michael Porter, un
Profesor de estrategia de Harvard Business School, y enfatizó la idea de una "cadena de valor".
En esencia, una cadena de valor es una colección de todos los procesos que una organización utiliza para
Tu organización
Productos y servicios
Hacer y entregar entregado
Vendedores productos Solicitudes de soporte
Materiales
Productos competitivos
Competencia
73
Página 2
74 Cambio de proceso de negocio
generar un producto o servicio que sea valorado por un grupo específico de clientes. Cada paso en el
La cadena se suma al valor final del producto o servicio. Hammer estaba principalmente preocupado
con discriminación entre el costo de realizar el trabajo del proceso y el margen creado
por los costos y precio de venta. La Figura 4.2 ilustra una cadena de valor, tal como la concibió Hammer, colocada
dentro de un marco organizativo para facilitar la comparación con el enfoque de Rummler.
https://translate.googleusercontent.com/translate_f 1/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Hammer comenzaría un compromiso con una organización preguntando cuántos
cadenas de valor que tenía la organización. Trabajaría con un equipo de gestión para crear un
diagrama como el que se muestra en Figura 4.3y luego pedirle a la organización que decida
Tu organiz ación
Infraestructura firme
Desarrollo tecnológico
Margen
Actividades de apoyo Obtención
Actividades primarias
Página 3
Arquitectura empresarial 75
en qué cadena de valor específica querían trabajar primero. En el caso de 4.3, vemos el
cadenas de valor en Unisys, c.2003.
Cada cadena de valor de Unisys proporciona un tipo diferente de producto o servicio, y cada
se dirige a un grupo diferente de clientes. Systems Integration vende desarrollo de software
servicios, mientras que Outsourcing gestiona la ejecución del software de otras empresas
aplicaciones, y así sucesivamente.
Obviamente, la principal diferencia entre los enfoques de Rummler y Hammer es
el hecho de que Rummler asumió que una organización tenía una cadena de valor, como la mayoría de las medianas
las organizaciones lo hacen, mientras que Hammer asumió que la organización podría tener más
de una cadena de valor, como lo hacen muchas organizaciones grandes. Los procesos representados en Ron-
El Mapa de Relaciones de mler fueron los procesos de nivel 1 que podrían constituir un solo valor
cadena, mientras que el diagrama de Hammer solo muestra cadenas de valor y no las subdivide
en subprocesos mayores. En cuanto a cómo uno representaba los procesos dentro de una cadena de valor,
La figura 4.4 sugiere una forma moderna de combinar los dos enfoques. Hemos simplificado
estos diagramas dejando de lado los procesos de gestión y soporte. Como notará, en un
alto nivel de abstracción, las dos cadenas de valor se ven bastante similares, aunque en la próxima
nivelar hacia abajo, los subprocesos se verían bastante diferentes.
https://translate.googleusercontent.com/translate_f 2/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
contactos
Clientes
Contactos de ventas
Comercializar y vender neumáticos
Pedidos
Productos y servicios
Hacer
una y entregar
entregado
llantas
Solicitudes de soporte
Productos y servicios
Hacer y entregar entregado
guías
Solicitudes de soporte
Página 4
76 Cambio de proceso de negocio
https://translate.googleusercontent.com/translate_f 3/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Página 5
Arquitectura empresarial 77
Negocio
nivel 0
Una cadena de valor
Cadena de valor: por ejemplo, diseñar, hacer y vender widgets
Distribuidor
Otro suministro
Cadena de suministro cadenas de suministro
cadenas
proceso o clientes
Nivel 1
Una cadena de suministro
Hacer Entregar
Plan Fuente
D1 entregar
Fuente S1 M1 a medida
productos almacenados
productos almacenados
D2 entregar
Fuente S2 M2 por encargo
Productos MTO
Nivel 2 Productos MTO
Procesos y
Fuente S3 D3 entregar
variaciones M3 ingeniero a pedido
ETO orgullosos Productos ETO
Calendario Autorizar
Recibir Verificar Transferir
producto proveedor
producto producto producto
entregas pago
También reconocieron que había un problema si intentaban ir por debajo del nivel 3, ya que
los flujos se volvieron demasiado complejos para modelar. En cambio, se conformaron con mostrar un nivel específico
3 subprocesos, y luego mostrar solo los otros procesos, personas u organizaciones que
el proceso específico del nivel 3 interactuó con. Al mismo tiempo, el equipo de SCC desarrolló
sus modelos básicos, también desarrollaron un enfoque básico para la evaluación del desempeño y
métricas para cada proceso para cada proceso y subproceso. Figura 4.6 imágenes en el conjunto de
métricas para una cadena de suministro (un proceso de nivel 1). Tenga en cuenta que las métricas están organizadas de modo que
algunos miden el desempeño de la cadena de suministro en relación con sus clientes, y el otro conjunto
reflejar el desempeño interno de la cadena de suministro.
Trabajando juntos, las organizaciones miembros de SCC, hay unos 900 miembros
hoy: estableció un servicio de evaluación comparativa. Había suficientes miembros para asegurar que
las compañías podrían obtener datos de referencia para cualquier industria en la que estuvieran, y comparar
el promedio y las mejores organizaciones para su propio desempeño específico. Esto a su vez,
permitió a un miembro de SCC determinar qué tan bien estaba funcionando su propia cadena de suministro.
Página 6
78 Cambio de proceso de negocio
Resumen de métricas Métricas de nivel 1 de SCOR Real Paridad Ventaja Superior Valor de las mejoras
Suministro
Rendimiento de entrega hasta la fecha de confirmación 50% 85% 90% 95%
cadena
fiabilidad
Tasas de llenado 63% 94% 96% 98%
Sensibilidad Cumplimiento de pedidos plazos de entrega 35 dias 7 días 5 dias 3 días Ingresos de $ 30 millones
Externo
Flexibilidad Tiempo de respuesta de la cadena de suministro 97 días 82 días 55 días 13 días Habilitador clave para costear y
mejoras de activos
Costo Costo total de gestión de SCM 19% 13% 8% 3% Costo indirecto de $ 30 millones
https://translate.googleusercontent.com/translate_f 4/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Costo de la garantía N/ A N/ A N/ A N/ A N/ A
Turnos de activos netos (capital de trabajo) 2.2 vueltas 8 turnos 12 turnos 19 turnos N/ A
Observe la sutil diferencia que ha tenido lugar. Grupos de procesos empresariales anteriores
arquitecturas de proceso de negocio definidas para ayudar en el rediseño de un negocio específico
ness proceso que se rompió. El SCC definió una arquitectura empresarial para permitir
empresas para definir rápidamente cómo funcionan sus cadenas de suministro, y luego asegurarse de que
podría obtener buenos datos sobre el rendimiento real de su cadena de suministro existente. Utilizando
A partir de los datos que obtuvieron, un miembro de SCC podría determinar cuáles de sus procesos funcionaban.
ing así como otros en su industria, y que eran superiores o de calidad inferior. Conocimiento
lo que la mayoría de las empresas pudieron lograr, una empresa determinada podría hacer un cálculo para
Determinar lo que podría costar y lo que finalmente podrían ahorrar si tuvieran que traer
un subproceso dado hasta el promedio de la industria, o mejorarlo para que sea tan bueno como el
El mejor en la industria. En otras palabras, los gerentes de la cadena de suministro estaban creando negocios
procesar arquitecturas para gestionar sus cadenas de suministro, planificar y estimar qué
los subprocesos pueden necesitar trabajo y hacer estimaciones sobre qué tipo de mejora
Puede ser razonable esperar si alcanzan ciertos puntos de referencia.
Hay varias cosas sobre SCOR que vale la pena señalar. Primero fue desarrollado
por gente de negocios, por gerentes de la cadena de suministro, no por personas de proceso como tales o por
personas de arquitectura de TI En segundo lugar, muestra por qué la gente de negocios puede querer un negocio
arquitectura ness. Su primera preocupación no era alinear las aplicaciones de software con
objetivos de negocio. Su primera preocupación era entender cómo eran los procesos que tenían.
realizando, identificando cómo los procesos de una empresa se vinculan con los de otra empresa
empresas y luego identificar qué procesos serían los más rentables para
fijación lateral. En la medida en que los profesionales de SCC han ampliado su modelo, ha sido
para incluir información sobre las mejores prácticas de los empleados, y no las mejores prácticas de software.
Página 7
Arquitectura empresarial 79
El trabajo del Consejo de la Cadena de Suministro, que comenzó a mediados de la década de 1990 y aún continúa.
ing, ha inspirado a otros grupos a desarrollar marcos de referencia de operaciones.
La industria de las telecomunicaciones, por ejemplo, tiene su propio modelo de referencia, el modelo eTOM que
fue desarrollado y mantenido por TeleManagement Forum. Cualquier persona de proceso
trabajar en una industria que ya tiene uno de estos modelos de referencia estaría bien
Se recomienda conocerlo y usarlo cuando sea posible.
Basándose en el trabajo inicial de Rummler y Hammer, y especialmente en algunos de
En los marcos de referencia de operaciones desarrollados en la última década, las organizaciones tienen
interesarse mucho más por desarrollar arquitecturas de negocios. Los primeros métodos
promovido por Hammer y Rummer ya no son suficientes por varias razones,
que discutiremos en un momento. Antes de hacerlo, sin embargo, vale la pena tomar un poco
desvío para ver por qué hay tanta confusión en el mercado actual de arquitectura empresarial.
https://translate.googleusercontent.com/translate_f 5/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
desarrollaron sus modelos, por lo general pagaron por el hecho de que todas las aplicaciones de TI
estaban destinados a apoyar las operaciones comerciales, que, a su vez, fueron diseñadas para implementar
Metas comerciales. Por lo tanto, Enterprise Architects imaginó una pirámide con operaciones comerciales
Aciones en la parte superior, y aplicaciones de TI, debajo, operaciones de soporte. Debajo de eso hay
eran redes de comunicaciones para unir las aplicaciones y las bases de datos, y así
adelante. En realidad, durante los primeros días del trabajo de arquitectura empresarial, pocos pagaban mucho
atención a la arquitectura empresarial. En su lugar, se centraron en definir la organización de
Recursos de TI, seguros de que las aplicaciones y bases de datos se han desarrollado para ayudar
portar las operaciones del negocio.
Un esfuerzo inicial para ayudar a los diseñadores de TI a pensar en una arquitectura empresarial fue
realizado por un investigador de IBM, John Zachman, quien creó un marco que intentó
para identificar los tipos de información que una arquitectura empresarial podría querer hablar
acerca de. En otras palabras, el modelo de Zachman era una forma de describir las categorías uno
Página 8
80 Cambio de proceso de negocio
podría crear en una base de datos que iba a realizar un seguimiento de todos los elementos incluidos en
un modelo de arquitectura empresarial (ver Figura 4.7)
En esencia, Zachman creó una matriz que identificó seis niveles y consideró tres
tipos de entidades: funciones, datos y redes. Más tarde, a medida que las personas de TI se volvieron más
interesado en la arquitectura, Zachman expandió su matriz y agregó tres filas más,
incluyendo: personas, tiempo y motivación. El marco de Zachman se ha vuelto popular
con arquitectos empresariales, que se centran en capturar información sobre los elementos y
La organización debe gestionar. Tenga en cuenta, sin embargo, que esto realmente no es una arquitectura, es solo una
lista de algunos de los términos que un arquitecto podría usar para discutir lo que sucede en un determinado
organización. Y ciertamente no pone mucho énfasis en el papel central del proceso
para determinar cómo encaja todo.
En la década de 1990, cuando las empresas comenzaron a tomarse en serio el proceso de reenganche a gran escala.
Al acercarse, mucha gente se interesó más en el trabajo de arquitectura. Carnegie Mellon's
Programa
Datos Red
(Función)
Arquitectura de la aplicación:
Inf ormación Sistemas distribuidos
objetos, componentes o Arquitectura de datos
modelo de sistema arquitectura
diagrama de flujo de datos (por ejemplo, entidades y
(Diseñador de TI (por ejemplo, componente o
Nivel 3 (por ejemplo, modelos de objetos, usuario relaciones)
ver) modelo de middleware)
interfaces)
Mensajes enviados
Marcha Datos reales que se crean
P rogramas que se ejecutan entre usuarios, programas,
sistema Y usado
Nivel 6 y bases de datos
https://translate.googleusercontent.com/translate_f 6/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Página 9
Arquitectura empresarial 81
El Instituto de Ingeniería de Software (SEI) creó un modelo de madurez para el Departamento de EE. UU.
de Defensa, para ayudarlos a evaluar la probabilidad de que las organizaciones se desempeñen eficazmente
software a tiempo y dentro del presupuesto. El modelo de madurez desarrollado por SEI describe
Cinco niveles de madurez. Las organizaciones de nivel 2 entendieron algunos de sus procesos, pero no
cómo encajan todos juntos. Las organizaciones de nivel 3 adoptaron una visión más amplia y, en esencia,
tuvo el comienzo de una arquitectura de proceso que mostraba cómo los procesos funcionaban juntos
para producir el resultado final deseado. Las organizaciones de nivel 4 eran aún más sofisticadas,
y tenía medidas para cada uno de sus procesos, y gerentes asignados para monitorear esos
medidas y tomar medidas correctivas para asegurar resultados. Como los resultados de la madurez SEI
El trabajo modelo se hizo más ampliamente conocido, concentró a muchas organizaciones en el hecho
que tal vez quieran desarrollar una arquitectura de procesos de negocio que les dé
ideas sobre cómo todo en la organización trabajó en conjunto.
Esto, a su vez, llevó a renovados esfuerzos para desarrollar empresas más sofisticadas.
Modelos de arquitectura. Un ejemplo de trabajo reciente es The Open Group's Architec-
Marco de trabajo (TOGAF). TOGAF se estableció inicialmente a principios de la década de 1990, y
ha desarrollado estándares para los tipos de información que podrían incluirse en un
Arquitectura empresarial integral. El modelo TOGAF de nivel superior se muestra en
Figura 4.8.
Tenga en cuenta que el modelo TOGAF incluye una arquitectura empresarial, aunque no lo es
significa el elemento más destacado de la arquitectura. En esencia, TOGAF sigue siendo muy
un marco diseñado por personas de TI para ayudarlos a administrar los recursos de TI de un
organización, y solo hace un guiño al hecho de que los recursos de TI existen para
apoyar las operaciones comerciales.
A fines de la década de 1990, el Congreso de los EE. UU. Aprobó una ley que exige a las agencias gubernamentales de los EE. UU.
para desarrollar arquitecturas empresariales. Esta iniciativa surgió como resultado del comité
audiencias que revelaron que algunos departamentos tenían muchas copias diferentes de la misma
Aplicaciones ERP que habían comprado a diferentes precios y que estaban manteniendo
a través de diferentes tipos de contratos. El Congreso quería que los departamentos crearan un alto nivel
descripción general de sus recursos de TI para evitar duplicaciones y desperdicio. Hay varios diferentes
versiones de las arquitecturas desarrolladas por los distintos departamentos gubernamentales. Uno,
El Marco Federal de Arquitectura Empresarial de EE. UU. (FEAF) se creó como un general
referencia en 2001 y se ilustra en la Figura 4.9.
Como puede ver al mirar Figura 4.9, hay un lugar para la arquitectura empresarial
en la parte superior de la pirámide, pero, de acuerdo con el énfasis en TI, la verdadera preocupación es
con la definición y vinculación de recursos de TI.
Un esfuerzo reciente de los expertos de TI para crear una arquitectura empresarial está siendo impulsado por un
grupo de personas en el OMG. El mismo grupo también tiene un grupo relacionado e independiente, el
Business Architecture Guild, que publica un estándar separado que tienen la intención de
vender, por lo que se vuelve un poco confuso si uno está hablando de un estándar OMG, o
El Cuerpo de Conocimiento de Arquitectura de Negocios del Gremio (BIZBOK). En esencia, el OMG
Página 10
82 Cambio de proceso de negocio
Preliminar:
Marco de referencia &
principios
UNA
Arquitectura
visión
H
si
Arquitectura
Negocio
cambio
archiecture
administración
https://translate.googleusercontent.com/translate_f 7/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
C
sol
Información
Implementación Requisitos
sistema
gobernancia
arquitecturas
F re
Migración Tecnología
planificación arquitectura
mi
Oportunidades y
soluciones
Task Force / Guild parece estar enfocado en elaborar lo que podría ir en el círculo único
en el modelo TOGAF etiquetado como Business Architecture. Su ruptura de la Busi-
El círculo de arquitectura ness se muestra en Figura 4.10 .
Hay un sentido en el que los profesionales del proceso estaban mejor, en retrospectiva, cuando
los arquitectos de TI simplemente ignoraron el cuadro de arquitectura empresarial en sus modelos, y sim-
ply asumió que de alguna manera sabían lo que la gente de negocios quería. El trabajo de los
OMG Business Architecture Guild es básicamente un esfuerzo de personal de TI para conceptualizar
cómo deben ser las operaciones comerciales. Comienzan dejando a un lado el proceso: definen
Es muy limitado como un conjunto de pasos: ignore las cadenas de valor y prefiera hablar de
Flujos de valor, que definen de una manera muy diferente a la definida por Lean
Página 11
Arquitectura empresarial 83
Tecnología
Normas
Aplicaciones
Datos
Seguridad
Actual
Arquitectura
Negocio
conductores
arquitectura
Objetivo
Negocio Datos
arquitectura Negocio Negocio
conductores
arquitectura arquitectura
Visión
Aplicaciones
Diseño
arquitectura Arquitectónico Datos
conductores Datos
segmentos arquitectura arquitectura
Estratégico
Tecnología
dirección
arquitectura
Aplicaciones Aplicaciones
Arquitectura arquitectura Principios
arquitectura
Inversión
revisión Tecnología Tecnología
arquitectura arquitectura
Segmento
coordinación
Arquitectura
Modelos arquitectonicos
Mercado
investigación
Activo
administración
Procesos transaccionales
¿ P or qué?
Visión,
Políticas, reglas
¿ P or qué? estrategias
regulaciones
Capacidades y tácticas
¿ Quien? Y
Organización Información ¿ Qué?
¿ dónde?
https://translate.googleusercontent.com/translate_f 8/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
¿ Cómo?
Métricas y Decisiones
medidas & eventos
¿ Cuando?
Pagina 12
84 Cambio de proceso de negocio
practicantes Ponen la mayor parte de su énfasis en las "capacidades", que nadie parece
para poder definir. En algunos casos, describen una capacidad como una habilidad, como en "Sé capaz
desarrollar aplicaciones basadas en la nube ". En otros casos, describen una capacidad
ity como actividad: “Desarrollar aplicaciones basadas en la nube”. En el primer caso, describen una
capacidad como algo que debería ser la preocupación de un departamento funcional, como
TI o finanzas. En otros casos, definen una capacidad como una actividad que debería ser
incluido en un proceso de negocio. En todos los casos, imaginan que una organización querría
para desarrollar una jerarquía de capacidades que una organización podría soportar.
Los que provienen de la tradición del proceso de negocios están en su mayoría horrorizados por BIZBOK
acercarse a, aproximarse. Desde Rummler hasta Hammer, las personas de proceso han estado tratando de conseguir organizaciones
para enfatizar los silos funcionales, y enfocarse, en cambio, en cómo se realiza realmente el trabajo. Si uno
enfocado en el proceso que genera valor, entonces uno puede determinar el valor de cualquier
actividad (o capacidad) determinando si contribuye a la creación de valor o no.
Imagine una organización cuyo departamento de TI decide que necesita la capacidad de generar nube
aplicaciones, y comienza a gastar dinero para adquirir dicha capacidad. Una mirada al negocio
Sin embargo, la arquitectura de procesos revela que la empresa no tiene ninguna aplicación que
requieren aplicaciones en la nube y no hay planes para desarrollar ninguna. En esencia, el grupo de TI se ha convertido
enfocado en una actividad que no agrega valor, y debe ser desafiado, no alentado. La capa-
El enfoque de modelado de las habilidades hace que las compañías hagan listas de cosas que hacen o quieren hacer que
puede o no estar agregando valor. Se acerca el desarrollo de la arquitectura al revés.
Con suerte, a medida que pase el tiempo, los diversos tipos de profesionales se reunirán y desarrollarán
Una visión más holística de lo que debe incluirse en una arquitectura empresarial. Mientras tanto, en
Esencialmente, tenemos dos grupos diferentes, aquellos con experiencia en procesos de negocios y aquellos
con experiencia en TI, cada uno ofrece su propia versión del tipo de arquitectura empresarial
necesita una organización, y la lucha resultante está causando bastante confusión.
Página 13
Arquitectura empresarial 85
están funcionando correctamente y tienen un sistema para asegurar que los recursos de apoyo sean
alineado a las necesidades de los procesos de negocio. Por lo tanto, en el resto de este capítulo vamos a
https://translate.googleusercontent.com/translate_f 9/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
centrarse en modelos de procesos de negocio; en capítulos posteriores nos centraremos en todo el negocio
medición de procesos, sobre gobernanza de procesos y sobre alineación.
Cuando hablamos antes de los orígenes de las arquitecturas de procesos en los escritos de
Rummler y Hammer, enfatizamos que no estaban haciendo tanto trabajo serio.
arquitecturas de todo el premio, ya que estaban estableciendo un contexto para un proyecto de rediseño de procesos
ect. Los esfuerzos recientes para ampliar estos enfoques iniciales han resultado en serios
problemas, y los enfoques actuales para el trabajo de desarrollo de arquitectura de procesos de negocios son
bastante diferente de esos esfuerzos anteriores.
La figura 4.11 ilustra una arquitectura simple como la que podríamos haber desarrollado cuando
intentamos rediseñar el proceso xx, que se muestra como uno de los procesos
se muestra en el diagrama. En esencia, este diagrama es simplemente una forma informal de tratar de
Identificar algunos de los principales procesos que probablemente interactúen con el proceso xx. Si tu
desarrollar un diagrama como el de Figura 4.11 , y luego decide trabajar en él para hacerlo
más detalladamente, te encuentras con dos obstáculos principales.
Primero, el enfoque está casi invariablemente diseñado en torno a un proceso central. Te muestra
los tipos de procesos que pueden administrar o admitir el proceso xx, pero no sugiere
qué procesos podría necesitar para apoyar a otras partes interesadas. Consideremos dos. los
Los altos directivos, propietarios o accionistas son partes interesadas con un gran interés en el
Éxito de la cadena de valor. Quieren información financiera que les diga qué
tipo de rendimiento que obtienen de su inversión. ¿Dónde se muestran esos procesos en
Figura q? Del mismo modo, ¿dónde están los procesos para apoyar a los empleados, subcontratistas, gobierno
agencias reguladoras o grupos comunitarios que pueden estar interesados en esta cadena de valor?
En otras palabras, las arquitecturas más antiguas tendían a modelar los procesos centrales del valor.
encadenar, pero no hacer mucho con los diversos tipos de procesos de gestión y soporte.
Recoger Entregar
paquetes paquetes
Procesos centrales
Proceso de apoyo
Página 14
86 Cambio de proceso de negocio
Montar Entregar
Cliente Tomar orden Cocinar pizza Caja de pizza Cliente
P izza P izza
Obtener
P roveedores
suministros
Gestionar
obtener Mantener
suministros empleado
base de datos
Alquiler
empleados
Figura 4.12 Un conjunto de procesos centrales con solo unos pocos procesos de administración y soporte.
Una de las principales razones por las cuales los arquitectos de procesos tempranos tendieron a evitar la construcción integral
los modelos intensivos se deben a que no sabían cómo manejar la administración y el soporte
procesos. Los modeladores de procesos habían caído en la costumbre de hablar sobre los procesos como si
siempre podría estar perfectamente descompuesto. Uno identificó la cadena de valor y luego se subdividió
https://translate.googleusercontent.com/translate_f 10/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
en sus principales procesos. Luego uno dividió esos procesos principales en sus subprocesos,
y así. Es una buena idea, y funciona razonablemente bien si te quedas con los procesos centrales
eso conforma la cadena de valor, pero no funciona muy bien cuando te enfocas en el soporte
procesos. Considere la figura 4.12. Aquí mostramos varios procesos centrales, con subprocesos.
También mostramos un proceso de gestión, Crear presupuesto anual y un proceso de soporte,
Contratar nuevos empleados. En el momento en que lo piensas, te das cuenta de que cada proceso en el
la organización necesitará, en algún momento u otro, contratar nuevos empleados. Por otra parte, cada
de los principales procesos estarán involucrados en la creación de presupuestos anuales. En otras palabras,
cuando comienza a tratar de mostrar las relaciones entre el núcleo, la administración y
admite procesos y profundiza dos o tres niveles, terminas con diagramas que son
demasiado complejo para leer o comprender (ver Figura 4.12 ). Toda la idea de una arquitectura.
era mejorar la comprensión de los gerentes, y los primeros diagramas de arquitectura a menudo
todo lo contrario
Una solución proviene del Supply Chain Council como resultado de su trabajo
en su marco de cadena de suministro. El SCC se dio cuenta desde el principio que no hizo
tiene sentido descomponer una arquitectura más de dos veces. En esencia, desarrollaron un
Nuevo tipo de diagrama que muestra un proceso de nivel 3 y todos los procesos que interactúan
con eso. En retrospectiva, esto es muy parecido a lo que BPTrends desarrolló de forma independiente, para un
propósito ligeramente diferente, y llamado un diagrama de alcance. La figura 4.13 muestra un nivel 3
Proceso SCOR.
Página 15
Arquitectura empresarial 87
Proporcionar Mantener
empleados ESO
Figura 4.13 Un proceso de tercer nivel que se muestra con sus relaciones con otros procesos de tercer nivel.
https://translate.googleusercontent.com/translate_f 11/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
esos pasos posteriores por el momento, dejándolos para capítulos posteriores en este
libro.
Página 16
88 Cambio de proceso de negocio
Semana 1
Identificar equipo
Reunión 1
ajustar
Patada inicial
asignaciones • Con solid ar to do el ciclo de v id a
pro cesos en p roceso s L2
• Definir objetivos d el proy ecto d e arq u itectu ra. Encuentro 2 Entrevista • Proceso s del gru po L2 en arq u itectura
• Id entificar participantes y resp o n sab ilid ad es. Proyecto de alcance partes interesadas cu ad rícu la p ara id en tificar p rocesos L1
• Defin ir cada pro ceso d e Niv el 2 :
In cluy end o d olo r, g anan cia y medid as
Encuentro 3 Refinar lista de
• Defin ir o b jetiv o s / estrateg ias o rg an izacio n ales (Use marcos p ara verificar
Definir ciclo de vida ciclo vital
• Defin ir o rg an izació n y cad en a (s) d e v alo r lo completo)
procesos procesos
• Id en tificar p artes in teresad as y v alo r
p ro p o sicio n es Encuentro 4 Defina cada
• Seleccion e u n a caden a d e valor p ara trab ajar
• Defin ir resu ltad o s estratég ico s.
• Id en tificar lo s ciclos de v ida d e las p artes interesadas. Definir nivel 1 Nivel 2
(Estrella d el No rte)
• Id en tificar lo s ciclos de v ida d el p ro d ucto / serv icio . & 2 procesos proceso
• Id en tificar lo s ciclos de v ida d el p ro ceso de activ os.
El enfoque que describimos generalmente toma de 1/2 a 2 años, dependiendo del tamaño de
la organización y el tiempo que los gerentes que participan en el equipo pueden asignar para hacer
obra de arquitectura. Al romper el esfuerzo y dar tiempo a los miembros del equipo para
realizar tareas específicas, una arquitectura integral que refleje adecuadamente
Los gerentes de la organización pueden desarrollar la flexibilidad de una organización real.
Describiremos cada paso del esfuerzo con un poco más de detalle, comenzando con el
Reunión de lanzamiento y la formación del equipo de gerentes. Para simplificar las cosas, nosotros
consulte los pasos mediante los nombres asignados a la reunión que comienza cada paso.
Página 17
Arquitectura empresarial 89
Organización
Clientes para
Cadena de valor: producir y vender neumáticos
llantas
https://translate.googleusercontent.com/translate_f 12/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Clientes para
Cadena de valor: producir y vender guías de restaurantes restaurante
guías
son agencias gubernamentales que regulan y tributan organizaciones, y hay socios que
vender suministros para la producción y venta de neumáticos, o quienes ayudan con la comercialización, distribuir
ción o venta de los neumáticos. También están los empleados que dependen de la cadena de valor para
trabajos. La figura 4.16 ilustra algunas de las partes interesadas que el equipo de arquitectura identificó
para la cadena de valor Producir y vender neumáticos.
administración Accionistas
Gobierno
Empleados
reguladores
Para tener éxito, la cadena de valor de Produce and Sell Tires tiene que apoyar a cada una de sus partes interesadas.
titulares. Obviamente, la compañía no tendrá éxito si no logra atraer clientes, pero lo hará
ir a la quiebra con la misma seguridad si no paga los impuestos o si no retiene a los empleados que necesita
por su exitosa operación. La organización necesita medidas para el éxito alcanzado.
con cada parte interesada Más concretamente, debe haber procesos para soportar cada uno de los
partes interesadas Así, por ejemplo, la organización debe tener un proceso para gestionar su
acciones, para proporcionar informes a los accionistas y para tratar los problemas de los accionistas.
Página 18
90 Cambio de proceso de negocio
Del mismo modo, la organización debe tener procesos para contratar nuevos empleados, para pagar
empleados existentes, para tratar los problemas de los empleados y para administrar pensiones para
empleados jubilados
Históricamente, los equipos de arquitectura de procesos han tendido a centrarse casi exclusivamente en
Los procesos centrales que generan productos y servicios para los clientes. Desarrollando un com
La arquitectura de procesos empresariales prensiva requiere una perspectiva más amplia.
administración Accionistas
https://translate.googleusercontent.com/translate_f 13/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Gestionar
Proporcionar
gobierno
empleados
reguladores
Gobierno
Empleados
reguladores
Figura 4.17 Procesos que proporcionan productos y servicios para las partes interesadas de la cadena de valor.
Página 19
Arquitectura empresarial 91 91
desencadena un nuevo proceso de diseño de servicios que eventualmente genera una nueva oferta bancaria. Todas
tres de estos flujos de valor están diagramados, en un nivel alto, en Figura 4.18 y más
nivel detallado en Figura 4.19 .
Estamos representando los muchos procesos necesarios para responder a las solicitudes de los clientes. Nosotros
tendrá que hacer este mismo tipo de análisis para cada una de las otras partes interesadas. Hombre-
la gestión, por ejemplo, necesita informes para que, a su vez, pueda generar informes para bancos y
accionistas, o eso puede iniciar cambios en los presupuestos o tomar decisiones sobre objetivos para
meses futuros Los empleados deben ser contratados, necesitan apoyo continuo (salarios, atención médica,
pensiones), y muchos necesitan medidas disciplinarias o incluso necesitan ser despedidos. En esencia,
necesitamos definir todos los procesos necesarios para responder a todas las solicitudes que interesan
los titulares pueden hacer de la cadena de valor. Este no es un proceso trivial y requerirá bastante
un poco de reflexión por parte del equipo que trabaja en modelado de arquitectura.
Supongamos que denominamos los grandes procesos que interactúan con los interesados Nivel 1
procesos y que llamamos los subprocesos identificados en la Figura 4.19 , Procesos de Nivel 2.
Sin entrar en más detalles, puede ver que nuestro análisis inicial de una cadena de valor es
va a generar una gran cantidad de procesos, algunos centrales y algunos administrativos o de apoyo
portando en la naturaleza. Procesos diseñados para proporcionar a los accionistas estados financieros
será de naturaleza administrativa, mientras que los procesos de contratación y los empleados de pensiones serán
procesos de soporte.
Hemos representado los procesos, de manera bastante clara, en la figura 4.20. De hecho, como lo hará el equipo
proceder a generar cientos de procesos, lo mejor es hacerlo en una pizarra o en un
hoja de papel grande con post-it que se puede modificar y mover fácilmente. Una llave,
en esta etapa es que todos los procesos son tentativos. Todavía no nos interesa determinar
ing el conjunto exacto de procesos, pero solo para asegurar que hemos identificado todo el nivel
dos procesos que serán necesarios
Necesidad de nuevo
Necesidad de existir Servicio
Servicio
Flujo de valor
Se establece el servicio
Figura 4.18 Múltiples flujos de valor iniciados por un solo tipo de parte interesada.
https://translate.googleusercontent.com/translate_f 14/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Página 20
Figura 4.19 Una mirada detallada a múltiples flujos de valor iniciados por un solo tipo de parte interesada.
Página 21
Gestión de la cadena de valor Administrar finanzas y contabilidad Gestionar los esfuerzos de KM-BPM
Mantener
Evaluar / monitorear Informar resultados a Definir incentivos Resumir Reporte
Desarrollar KM negocio
estratégico ejecutivo y evaluar emp. financiero financiero Gestionar cambio
programas proceso
actuación administración actuación eventos eventos
arquitectura
Gestionar
Definir nuevo Desarrollar Producto de mercado / Vender al consumidor Evaluar / aprobar
Servicio al Cliente
ofertas de servicio ofertas de servicio Servicio servicios Préstamos
operaciones
Procesos centrales
Proporcionar y mantener empleados Proporcionar suministros Proporcionar y mantener hardware, aplicaciones, datos e infraestructura.
Desarrollar &
Desarrollar / adquirir
Alquiler Mantener Definir suministros Adquiere y paga administrarlo Entregarlo
Planificar estrategia de TI necesario
empleados empleados necesario Buenos servicios cliente Servicios de apoyo
aplicaciones
relaciones
https://translate.googleusercontent.com/translate_f 15/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
actuación servicios aplicaciones infraestructura hardware
Procesos de apoyo
Definir propiedad Adquirir y
Administrar física
adquisición disponer de tierra Definir Desarrollar salud y
riesgo
estrategia & instalaciones ambiental programa de seguridad
Salud y Seguridad
Diseño &
construir Mantener las instalaciones Emprender
Monitorear la salud y
instalaciones remediación
cumplimiento de seguridad
proyectos
Figura 4.20 Una lista completa de los procesos de Nivel 1 y 2 para una organización.
Página 22
94 Cambio de proceso de negocio
Página 23
Arquitectura empresarial 95
https://translate.googleusercontent.com/translate_f 16/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Página 24
96 Cambio de proceso de negocio
Comencemos 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
solo uno de los principales procesos comerciales 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 oferta
Encadenamiento como un proceso de Nivel 1. Para hacer las cosas aún más complejas, SCOR subdividió el
Supply Chain en tres "niveles" pero, de hecho, uno de los niveles no es una descomposición de
el nivel superior, pero en cambio, requiere que el modelador defina el proceso de nivel superior en
términos de una de las tres variaciones. O bien el proceso de Fuente de Nivel 1 está relacionado con
Productos almacenados o se refiere a productos hechos a la medida, o con ingeniería
a pedido productos. Para simplificar las cosas, hablaremos constantemente de que SCOR tiene tres
niveles. El nivel 1 es la cadena de suministro. El nivel 2 son los procesos de alto nivel que conforman un
cadena de suministro, que incluye origen, fabricación, entrega y devolución. El plan es un SCOR adicional
proceso 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 Nivel 3
subprocesos como se muestra en la figura 4.21 .
El manual de referencia 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 uno de los procesos o
subproceso El SCC no define un cuarto nivel, dejando la especificación de nivel
https://translate.googleusercontent.com/translate_f 17/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
cuatro actividades para empresas individuales. En otras palabras, SCOR define una cadena de suministro
arquitectura y todos los procesos de alto nivel y deja la implementación técnica
de los procesos de nivel 3 a los miembros individuales.
Página 25
Arquitectura empresarial 97
Negocio
nivel 0
Una cadena de valor
Cadena de valor: por ejemplo, diseñar, hacer y vender widgets
Distribuidor
Otro suministro cadenas de suministro
Cadena de suministro
cadenas o clientes
proceso
Nivel 1
Una cadena de suministro
Hacer Entregar
Plan Fuente
D1 entregar
Fuente S1 M1 a medida
productos almacenados
productos almacenados
D2 entregar
Fuente S2 M2 por encargo
Productos MTO
Nivel 2 Productos MTO
procesos y
Fuente S3 D3 entregar
variaciones M3 ingeniero a pedido
ETO orgullosos Productos ETO
Calendario Autorizar
Recibir Verificar Transferir
producto proveedor
producto producto producto
entregas pago
De manera similar, en diagramas más completos, también se ingresan los procesos del Plan. En efecto, como
Plan se refiere a un esfuerzo de gestión de procesos, para cada proceso central que se muestra en el hilo
Diagrama también hay un proceso de Plan.
El Supply Chain Council proporciona a los miembros un Manual de referencia que define
todos los procesos y subprocesos de la cadena de suministro. Además, el manual describe el desempeño
Mida medidas que sean apropiadas para cada proceso en cada nivel. El SCC divide a todos
medidas de rendimiento en cinco categorías generales que luego se agrupan en
Métricas externas o de cara al cliente o métricas de cara interna. La figura 4.9 proporciona un
resumen de alto nivel de las medidas que se definen para la cadena de suministro en su conjunto (el
https://translate.googleusercontent.com/translate_f 18/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
proceso
puede de las
usar nivel 1). Aquídeno
métricas tomaremos
SCOR medidas,
para generar pero bastauna
rápidamente conlista
decir
de que
métricas entrelazadas para todo
arquitectura de la cadena de suministro (Figura 4.24 ).
Page 26
98 Cambio de proceso de negocio
(S1, D1)
(SR1, DR1, DR3)
Fabricación
Almacén
Almacén
Almacén
(S1, D1)
(S1, D1)
(SR1, DR1, DR3)
(SR1, DR1, DR3)
latinoamericano
Otros proveedores Proveedores
(D1) (D1)
Almacén (S1)
(S1)
(S1, D1) (SR1, SR3)
(SR1, SR3)
(SR1, DR1, DR3)
europeo
S2 M2 D2
Proveedor de RM
S2
M1 D1 S1 D1 S1
S1
Clave otro
S1 M1 D1
Proveedores de RM
Alfa
RM
Alfa regional Cliente
proveedores
almacén
Varias organizaciones que realizan un seguimiento de los puntos de referencia están trabajando con la cadena de suministro.
Consejo y puede proporcionar puntos de referencia genéricos para medidas SCOR para industrias específicas
intentos. Si una empresa desea datos de referencia específicos, debe contratar a uno de los
grupos de evaluación comparativa.
En Figura 4.25, ilustramos lo que SCOR se refiere como una SCORcard. Muestra el per-
atributos de forma, un conjunto de datos históricos y los datos de referencia para una hipótesis
Página 27
Arquitectura empresarial 99
https://translate.googleusercontent.com/translate_f 19/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
documentación correcta, al cliente correcto.
Cadena de suministro La velocidad a la que a la cual una cadena de suministro Cumplimiento de pedidos plazos de entrega
sensibilidad proporciona productos al cliente.
Cadena de suministro La agilidad de una cadena de suministro para responder a Tiempo de respuesta de la cadena de suministro
flexibilidad cambios en el mercado para ganar o mantener
ventaja competitiva. Flexibilidad de producción
Cliente f rente a un
Costos de la cadena de suministro Los costos asociados con la operación del suministro. Costo de los bienes vendidos
cadena.
Gestión total de la cadena de suministro.
costos
utes
rnal fActivo
rente de la cadena de suministro
a atrib La efectividad de una organización en la gestión Tiempo de ciclo de efectivo a efectivo
te administración activos para respaldar la satisfacción de la demanda. esta
En eficiencia incluye la gestión de todos los activos: fijos y Inventario de días de suministro
capital de trabajo.
Turnos de activos
Resumen de métricas Métricas de nivel 1 de SCOR Real Paridad Ventaja Superior Valor de las mejoras.
Suministro
Rendimiento de entrega hasta la fecha de confirmación 50% 85% 90% 95%
cadena
fiabilidad
Tasas de llenado 63% 94% 96% 98%
Sensibilidad Cumplimiento de pedidos plazos de entrega 35 dias syad7 syad5 syad3 Ingresos de $ 30 millones
Externo
Flexibilidad Tiempo de respuesta de la cadena de suministro 97 días 82 días 55 días 13 días Habilitador clave para costear y
mejoras de activos
Costo Costo total de gestión de SCM 19% 13% 8% 3% Costo indirecto de $ 30 millones
Costo de la garantía UN UN UN UN UN
Interno
Tiempo de ciclo de efectivo a efectivo 196 días 80 dias 46 dias 28 dias Cargo de capital de $ 7 millones
Turnos de activos netos (capital de trabajo) 2.2 vueltas 8 turnos 12 turnos 19 turnos N/ A
Figura 4.25 Una tarjeta SCORcard con datos reales y de referencia, y algunas conjeturas sobre el valor que
podría lograrse rediseñando la cadena de suministro que se analiza.
Página 28
100 Cambio de proceso de negocio
LA EXTENSIÓN DE PUNTUACIÓN
La siguiente parte de la historia de SCOR está estrechamente asociada con Joseph Francis (el
Director Ejecutivo actual del SCC) y la fusión Hewlett-Packard-Compaq. los
La fusión HP-Compaq se anunció en septiembre de 2001. Los 2 años anteriores habían
fue testigo de una caída importante en las ventas que obligó a muchas compañías de TI a reevaluar sus
https://translate.googleusercontent.com/translate_f 20/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
estrategias.
fecha: La fusión
representó una propuesta
importantede dos compañías
iniciativa de por
estratégica TI líderes:
parte dela los
fusión de TIdemás
equipos grande
gestión en
ambas compañías para cambiar la dinámica general del mercado de TI.
HP fue un jugador líder en servidores de gama media, en PC y portátiles, y en impresoras. Eso
también fue líder en servicios de integración y outsourcing, y tenía una reputación mundial
ción para tecnología de punta. Al mismo tiempo, sin embargo, HP no era lo suficientemente grande
para competir por los contratos de servicio más grandes que generalmente fueron para competidores más grandes
como IBM Además, la destreza de marketing de HP había disminuido en los últimos años. En 2001, por
Por ejemplo, HP tenía unas 6000 personas en marketing, mientras que competidores de tamaño similar
manejado con 1/3 como muchos. Compaq fue incluso 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 computadoras en tándem
y equipos digitales a fines de la década de 1990 en un esfuerzo por diversificar, pero nunca habían logrado
para utilizar las fortalezas de Tandem o Digital en computadoras de rango medio, tecnología o consulta-
Para lograr la presencia en el mercado que esperaba obtener cuando realizó esas adquisiciones
iones Por otro lado, Compaq era conocido por sus agresivas capacidades de marketing.
La fusión de las dos compañías daría como resultado una compañía significativamente más grande.
Juntos, HP y Compaq estarían en condiciones de dominar el mercado de PC, laptop,
Página 29
Arquitectura empresarial 101
servidor y venta de impresoras. Al mismo tiempo, la compañía combinada sería casi tan grande
como IBM y, por lo tanto, estaría bien posicionado para competir en igualdad de condiciones por el mayor
est contratos de servicio y outsourcing. La nueva compañía también estaría en condiciones de
exigir a los proveedores que le ofrezcan los mayores descuentos posibles. Además, dado que había considera-
traslapable en el área de PC, las dos compañías esperaban exprimir unos $ 2.5 mil millones
en ahorros anuales al tiempo que crea una organización más ágil y más agresiva.
Desde el principio, la fusión propuesta fue controvertida. Los argumentos sobre el
La sabiduría de la fusión, y la lucha de poder que siguió, han sido ampliamente reportadas en
en la prensa popular Finalmente, de hecho, la fusión real fue más fluida que la mayoría
anticipado, y resultó en mayores ahorros de los que habían planeado la fusión.
Como admitieron incluso los oponentes más fuertes 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 fusiones que planeó
para la integración de los procesos de la cadena de suministro de HP-Compaq. Tan pronto como la fusión fue
Anunciada formalmente, se creó una nueva organización para planificar la fusión. Esta fusión
La organización finalmente incluyó a unos 1000 empleados de las dos compañías.
Los empleados se reunieron en lo que se denominó ambiente de sala limpia. En efecto, ellos
se separaron del trabajo diario de HP y Compaq, se colocaron en un iso
configuración posterior, proporcionó información detallada sobre ambas compañías y solicitó desarrollar
Un plan de fusión.
La organización de fusión fue encabezada por un comité ejecutivo que hizo
nivel de decisiones estratégicas y, en última instancia, aprobó todas las recomendaciones detalladas de
Los equipos más especializados. Reportando al comité ejecutivo había ocho equipos que
enfocado en áreas específicas de preocupación. Había equipos para infraestructura de TI, suministro-
Cadena, Ventas / Pedidos, Diseño de producto, Comunicaciones / Marketing, Finanzas, Humanos
Recursos y Servicios / Soporte.
Algunos de los equipos carecían de un marco general y tuvieron que crear un nuevo y completo
mon vocabulario y una forma estándar de identificar procesos existentes. Afortunadamente, HP y
Los gerentes de Compaq que eran miembros del equipo de la cadena de suministro estaban familiarizados con
El trabajo del Supply Chain Council (SCC). El equipo de la cadena de suministro de HP-Compaq
se dieron cuenta de que podían usar SCOR para simplificar enormemente su tarea. SCOR proporcionó un estándar
enfoque que podrían usar para caracterizar y medir rápidamente la cadena de suministro
procesos tanto en HP como en Compaq.
Al acordar de antemano asignar los procesos de ambas compañías al modelo SCOR y
para utilizar el vocabulario y las medidas estándar de SCOR, el equipo de HP-Compaq pudo
lograr en un mes lo que de otro modo podría haber tomado muchos meses.
La facilidad de uso de SCOR fue fundamental para el trabajo realizado por el equipo de TI de la cadena de suministro.
durante la fusión SCOR hizo posible que el equipo analizara rápidamente todos los HP
y las cadenas de suministro de Compaq para todas las regiones y líneas de productos. Este análisis, a su vez, lo hizo
https://translate.googleusercontent.com/translate_f 21/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Página 30
102 Cambio de proceso de negocio
posible para el equipo de TI de la cadena de suministro comparar 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 pudo definir todas sus cadenas de suministro
rápidamente, simplemente confiando en las definiciones de nivel 1 de SCOR. En efecto, todas las cadenas de suministro eran
dividido rápidamente en Procesos de abastecimiento, Procesos de fabricación y Procesos de entrega, también
como algunos procesos adicionales de planificación y habilitación. Una vez hecho esto, el software de alto nivel
Se identificaron las aplicaciones de software que soportaban cada uno de estos procesos.
SCOR proporciona un conjunto bien definido de medidas para cada uno de los procesos de Nivel 1.
Esas medidas están vinculadas a medidas financieras establecidas que ambas compañías tienen
seguido por años. Por lo tanto, en la mayoría de los casos, uno simplemente utilizó las medidas SCOR Nivel 1
comparar dos líneas regionales para determinar cuál era la más eficiente y la más económica
eficaz. Si una línea era claramente más eficiente que la otra, entonces la cadena de suministro
El grupo de TI tendió a seleccionar simplemente las aplicaciones que admitían las más eficientes
proceso.
Aquellos familiarizados con la forma en que las personas técnicas pueden estar en desacuerdo sobre las virtudes de la competencia,
Las aplicaciones de software pueden imaginar fácilmente que el grupo de TI de la cadena de suministro podría tener
Conviértase en una arena para discusiones intensas entre los defensores de HP y Compaq
aplicaciones de software nativas El equipo de TI de la cadena de suministro sabía que si permitían
discusión para centrarse en las características técnicas específicas, nunca podrían
terminar su tarea. Además, una discusión técnica no aseguraría que la aplicación
La opción elegida estaría alineada con los objetivos corporativos. En cambio, el grupo sabía que era
importante que su trabajo se centre en el valor que las diversas aplicaciones entregan
a la compañia. En efecto, el grupo decidió seleccionar aquellas aplicaciones que admitían
los procesos más eficientes, independientemente de qué compañía apoye actualmente
aplicación, o qué departamentos estuvieron involucrados.
Algunas de estas medidas se centran en resultados externos y otras se centran en la eficiencia interna.
llora En cada caso, el SCC ha definido definiciones precisas para las medidas. Ninguna organización
La regió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
considerar con los objetivos estratégicos que la empresa está tratando de lograr con un determinado apoyo
proceso de cadena de capas. Considere el objetivo de una línea de productos dada. Si la empresa quisiera
competir, en el mercado de esa línea de productos, como proveedor de bajo costo, se enfocaría
para mantener una cantidad mínima de inventario, ya que un inventario bajo es una de las formas en que uno
mantiene bajos los costos. Por otro lado, si la empresa que estaba comprometida con el servicio y
quería asegurar que los clientes siempre pudieran obtener lo que querían, necesitaría
acepte 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 de la cadena de suministro hizo
La mayoría de las decisiones sobre estrategias de marketing para las líneas de productos combinadas y
El grupo de TI de la cadena de suministro seleccionó las medidas apropiadas y las usó para comparar
cómo se desempeñaron las líneas de productos existentes de HP y Compaq.
Page 31
Arquitectura empresarial 103
En algunos casos, dos líneas regionales en competencia parecerían ser igualmente eficientes y
eficaz cuando se analiza con medidas de Nivel 1. En esos casos, el equipo de TI de la cadena de suministro
expandiría su esfuerzo y modelaría los procesos a SCOR Nivel 2 o incluso, de una manera muy
pocos casos, al nivel 3.
Alrededor del 20% del tiempo total utilizado por el equipo de la cadena de suministro se utilizó en el modelado
procesos, midiéndolos, aplicando criterios y emitiendo juicios sobre qué aplicación
opciones para guardar y cuáles descartar.
Una vez que el grupo de la cadena de suministro identificó líneas de productos para mantener, modelar
los procesos, y luego las aplicaciones evaluadas y seleccionadas para mantener, fue posible
dar un paso atrás de los procesos específicos de la cadena de suministro que se evalúan e identificar un
https://translate.googleusercontent.com/translate_f 22/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
arquitectura genérica de la cadena de suministro para la empresa combinada. En efecto, esta arquitectura
procesos de suministro comunes identificados, derivados de SCOR, y aplicaciones comunes
que la compañía fusionada eventualmente podría estandarizar en todo el mundo. La aplicación
Las opciones identificadas no eran aplicaciones nuevas que la empresa fusionada adquiriría, pero
aplicaciones que ya se utilizan con líneas de productos exitosas que la compañía
estandarizar y migrar para minimizar la cantidad de aplicaciones que el nuevo
HP necesitaría soporte.
Al final de esta fase, el grupo de TI de la cadena de suministro había identificado todo el producto
las líneas que debían ser apoyadas en la compañía fusionada, habían identificado todas las aplicaciones
opciones que debían mantenerse y las que debían descartarse, e identificaron un conjunto de
estándares arquitectónicos hacia los cuales la compañía avanzaría lo antes posible.
Otros HP-Compaq hicieron sus recomendaciones, pero el equipo de Supply Chain
las recomendaciones se destacaron porque se basaron en un análisis de los procesos
números involucrados y duros sobre el desempeño de los procesos. La cadena de suministros
Las recomendaciones del equipo para utilizar aplicaciones de software específicas fueron justificadas por el
forma de los procesos que habían usado esas aplicaciones. La lógica de negocios detrás
El trabajo de los equipos de la cadena de suministro llevó al nombramiento del líder del equipo, Joe Francis,
a la cabeza del nuevo programa de mejora de Procesos de Negocio de HP.
OTRO ENFOQUE
Tele- ofrece otro enfoque para un marco completo de la cadena de valor.
Management Forum, un consorcio de empresas de telecomunicaciones. Su marco es altamente
adaptado a las necesidades de las empresas de telecomunicaciones. Por lo tanto, no puede ser utilizado por personas que no son telecom, pero
proporciona un enfoque integral para las empresas de telecomunicaciones.
Un grupo dentro del Foro TeleManagement ha pasado varios años desarrollando
Una arquitectura de procesos para empresas de telecomunicaciones. Se supone que ninguna empresa específica
tendrá exactamente los mismos procesos identificados por el TeleManagement Forum, y que
probablemente usarán diferentes nombres para los diversos procesos. Por lo tanto, esto es una referencia
arquitectura en lugar de una arquitectura de un negocio específico. Se asume a medida que pasa el tiempo
Página 32
104 Cambio de proceso de negocio
que la mayoría de los miembros se moverán hacia esta arquitectura de proceso y que, durante el mismo
período, los proveedores adaptarán los productos para implementar muchos de los procesos definidos por el
modelo.
La arquitectura que describimos es la tercera iteración que el Foro TeleManagement
Ha desarrollado. Esta última iteración, llamada eBusiness Telecom Operations Map
(eTOM), se basa en trabajos anteriores que solo buscaban definir los procesos operativos
dentro de las empresas de telecomunicaciones. A medida que las empresas comenzaron a implementar aplicaciones de comercio electrónico
cationes sin embargo, descubrieron que los procesos se incluyen en general y en empresas
la administración tuvo que ser agregada a la arquitectura. Una de las principales ventajas de
Los sistemas de comercio electrónico 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 se integra
puede ocurrir
La figura 4.26 muestra una versión del marco eTOM, reorganizada para que coincida
El formato que usamos en este libro. En efecto, giramos el diagrama básico de eTOM 90 °
a la derecha. Se movió al cliente al lado derecho del diagrama para que los procesos
ahora fluye de izquierda a derecha y las unidades funcionales fluyen hacia abajo, como organigramas
normalmente lo hacen.
La figura 4.26 proporciona una idea de cómo una empresa de telecomunicaciones es orgánica
Nized En esencia, una empresa de telecomunicaciones vende tiempo en su red a los clientes. Desde el tiempo
se vende y controla por medio de computadoras que rastrean el acceso telefónico, el Servicio y
Los recursos son funciones importantes. Dado que casi todas las llamadas telefónicas de larga distancia se cruzan
múltiples redes, los acuerdos con otras compañías de telecomunicaciones (socios) son muy
importante. Sospechamos que las compañías telefónicas reales podrían subdividir su departamento
mento algo diferente; colocando marketing y servicio en departamentos separados,
pero recuerde que la mayoría de las solicitudes de ventas y servicios telefónicos llegan a través de un
centro de llamadas, por lo que esta agrupación de alto nivel funciona razonablemente bien. En todo caso,Figura 4.26
proporciona una idea de cómo un grupo de gerentes de telecomunicaciones sintió que podría representar a sus
organizaciones.
La figura 4.26 proporcionaría un comité de arquitectura de procesos de telecomunicaciones con un
https://translate.googleusercontent.com/translate_f 23/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Vista de la empresa. Cada comité de arquitectura de procesos de negocio necesita algo
como estas cifras si van a tener una forma estándar de describir la pro de su empresa
identifica e identifica procesos que requieren cambios cuando se presentan nuevas estrategias y objetivos
Anunciado. De hecho, un comité de arquitectura de procesos probablemente querría algo
poco más detallado
Si no es un ejecutivo de telecomunicaciones, es posible que no esté familiarizado con algunos de los términos
Se utiliza para describir los distintos subprocesos. La clave es que este proceso de negocio
La arquitectura ilustra un marco lo suficientemente detallado como para que un proceso de telecomunicaciones archive
comité teórico que estaba familiarizado con su propia organización y que podría estar razonablemente
eficiente para determinar qué procesos o subprocesos necesitarían ser cambiados
para lograr cambios específicos en la estrategia y los objetivos de la empresa. Uno podría imaginar fácilmente un
Page 33
CEO
ejecutivo
comité
Procesos de operaciones
Retención y lealtad *
Proceso
Proceso
básico
básico
de soporte
de soporte
y preparación
y preparación
de operaciones
de operaciones
Soporte de operaciones CRM
& proceso mang.
Operaciones S / PRM Soporte de RM&O y Soporte SM&O y
Soporte y proceso de gestión. proceso mang. proceso mang.
Ventas y canal mang.
34
106 Cambio de proceso de negocio
documento adjunto que proporciona descripciones breves por escrito de cada uno de los sub
procesos.
La figura 4.26 plantea dos cuestiones que consideraremos con más detalle más adelante en este libro.
Primero, sugiere la posibilidad de un sistema de gestión matricial. Alguien es usualmente
responsable de procesos completos como el cumplimiento. Esa es la persona que piensa
cómo todos los subprocesos en Fulfillment trabajan juntos para brindar servicios al cliente
de manera suave y eficiente. Alguien más es probablemente responsable del Servicio
https://translate.googleusercontent.com/translate_f 24/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Gerencia y Operaciones. Los empleados que trabajan en la configuración del servicio.
y el subproceso de activación probablemente informará a la Administración y operaciones del servicio
gerente. Por lo tanto, un gerente trabaja para garantizar que el proceso completo funcione de manera eficiente.
Otro es responsable de los empleados que realizan algunos de los subprocesos dentro del
Proceso de cumplimiento, y también dentro de otros procesos.
El otro problema que es obvio cuando comenzamos a discutir un marco como eTOM
es cuántas veces aparece el proceso de palabras . Cuando el gráfico es tan simple como el de
Figura 4.26, podemos vivir con procesos, grupos de procesos y subprocesos. Tenemos
Ya he visto cómo el proceso final es una cadena de valor. La mayoría de las organizaciones solo tienen un
Pocas cadenas de valor. Sospechamos que todo el marco eTOM realmente solo muestra uno
cadena de valor: entregar servicios de telecomunicaciones.
Apenas hemos considerado todos los marcos de arquitectura existentes disponibles. los
El gobierno de los Estados Unidos tiene una y varias agencias gubernamentales (Australia, Canadá, Suecia,
y las ciudades de Dinamarca) tienen otros. El consorcio de la industria de seguros, ACORD,
está trabajando en un marco para la industria de seguros, y probablemente hay otros que
No he oído hablar todavía. El punto, sin embargo, es que las compañías que emprenden el desarrollo
Actualmente, la arquitectura de un proceso de negocio está en condiciones de acelerar en gran medida
proceso al comenzar con uno de los marcos disponibles y luego adaptarlo a su
necesidades específicas.
RESUMEN
Una arquitectura de proceso empresarial es una herramienta de gestión. Una vez que se define y luego
poblada con datos actualizados, puede usarse, como otras bases de datos, para responder ad hoc
preguntas que los ejecutivos necesitan ser respondidas. Se puede usar para apoyar a aquellos comprometidos
en el desarrollo de estrategias corporativas, y puede ser utilizado por un grupo BPM para identificar pro-
ceses que no están cumpliendo sus objetivos y que necesitan ser rediseñados. La información
colocado en la base de datos de Business Process Architecture dependerá de cómo la empresa
lo usa La mayoría de las empresas que han creado arquitecturas descubren que lo hacen más fácil para
gerentes para conceptualizar sus organizaciones en términos de procesos, y esto lleva a
solicita más y más información sobre los procesos que la empresa apoya.
Comenzamos con una descripción general de cómo se desarrolla un Proceso de Negocio
Arquitectura. Vimos que uno podría usar una descripción del proceso para organizar la colección y
Página 35
Arquitectura empresarial 107
alineación de datos sobre los procesos. Luego, consideramos cómo un proceso real archiva
El equipo de desarrollo de conferencias puede usar un marco de procesos como SCOR o eTOM para acelerar
El proceso de desarrollo arquitectónico. Los marcos no le proporcionan una gestión
ment estrategia, o sugerir alineaciones específicas, pero proporcionan una descomposición sistemática
de sus procesos de alto nivel y sugerir medidas de rendimiento que se pueden utilizar para todos
Los procesos en su arquitectura. Puede usar un marco para completar rápidamente hojas de trabajo o
llenar una base de datos de procesos de negocio y luego adaptarla y comenzar a alinear la información de recursos
ción Por lo tanto, en muy poco tiempo, su empresa puede comenzar a beneficiarse del tipo de análisis.
y priorización de proyectos que puede derivar de tener una arquitectura de proceso efectiva.
NOTAS Y REFERENCIAS
Una vez más, muchas de las ideas incorporadas en la metodología BPTrends son
derivado de conversaciones que hemos tenido Roger Burlton y yo, y el enfoque de BPTrends
descrito aquí es ofrecido como un curso de capacitación por www.bptrendsassociates.com.
Las figuras del diagrama de la organización derivan de figuras desarrolladas originalmente por Geary
Rummler
La discusión de la metodología SCOR del Supply Chain Council y algunos de
las cifras provienen del taller inicial de SCC sobre SCOR o de otro SCC
publicaciones. Más información sobre el SCC está disponible enwww.supply-chain.org.
Una buena descripción general de la metodología SCOR está disponible en www.bptrends.
com. Buscar: Harmon, una introducción a la metodología SCOR del Consejo de la cadena de suministro ,
Enero de 2003.
Bolstorff, Peter y Robert Rosenbaum, Supply Chain Excellence: A Handbook for Dra-
Mejora matemática utilizando el modelo SCOR , AMACOM, 2003. Un buen libro que presenta
https://translate.googleusercontent.com/translate_f 25/26
19/9/2019 Capítulo cuatro - Arquitectura empresarial
Un enfoque específico para implementar SCOR en una empresa.
Estoy particularmente en deuda con Joseph Francis por sus comentarios y opiniones sobre SCOR
y la evolución de SCOR + en Hewlett-Packard. Joe fue, por un tiempo, el hombre de BPM
ager en HP y actualmente es el CTO del Supply Chain Council. Él también corre el suyo
empresa de consultoría y ayuda a empresas con problemas de marco. Verwww.pcor.com .
El marco de John Zachman que se muestra en la Figura 4.7 se modificó después de una figura que
apareció en "Un marco para la arquitectura del sistema de información", de John Zachman.
IBM Systems Journal, vol. 26, Nº 3, 1987. Para la última versión del marco de Zachman:
trabajo, visite su sitio web: www.zachman.com .
La información sobre The Open Group y TOGAF está disponible en su sitio web:
www.opengroup.org/togaf .
La información sobre Federal Enterprise Architecture Framework está disponible en
su sitio web: www.whitehouse.gov/omb/e-gov/fea .
La información sobre el Business Architecture Guild y su modelo BIZBOK es
disponible en su sitio web: www.businessarchitectureguild.org.
Page 36
108 Cambio de proceso de negocio
https://translate.googleusercontent.com/translate_f 26/26