Capítulo Cuatro - Arquitectura Empresarial

19/9/2019 Capítulo cuatro - Arquitectura empresarial
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
Influencias ambientales generales:

Economías locales y globales, regulaciones gubernamentales,
y tendencias sociales
Tu organización
Captial Capital Gestionar Información y

Accionistas
dividendos
mercados organización
Crear nuevo Solicitudes de nuevos productos.

Personas
Labor
productos
mercados Mercados
Márketing
contactos
Clientes
Clientes
Comercializar y vender Contactos de ventas
Investigación Tecnología
productos Pedidos
comunidad
Productos y servicios
Hacer y entregar entregado
Vendedores productos Solicitudes de soporte
Materiales
Productos competitivos
Competencia
Figura 4.1 Un mapa de relaciones de una organización.
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
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
Gestión de recursos humanos
Desarrollo tecnológico
Margen
Actividades de apoyo Obtención
Entrante Saliente Márketing

Operaciones Servicio
logística logística y ventas
Actividades primarias
Figura 4.2 Una cadena de valor en un cuadro de organización.
O rganiz ación de Unisys
Cadena de valor: integración de sistemas
Cadena de valor: Outsourcing
Cadena de valor: servicios de red
Cadena de valor: servicios básicos
Cadena de valor: tecnología de servidor empresarial
Figura 4.3 Una organización con múltiples cadenas de valor.
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.
Corporación Miche lin
Cadena de valor: hacer y vender neumáticos
Crea nuevos tipos Solicitudes de nuevos productos.

de neumáticos Mercado de neumáticos
Márketing
contactos
Clientes
Contactos de ventas
Comercializar y vender neumáticos
Pedidos
Hacer
una y entregar
entregado
llantas
Solicitudes de soporte
Cadena de valor: investigar y publicar guías de restaurantes
Solicitudes de nuevos productos.

Crea nuevas guías
Mercado de guías
Márketing
contactos
Comercializar y vender Clientes
Contactos de ventas
guías
Pedidos
Hacer y entregar entregado
guías
Solicitudes de soporte
Figura 4.4 Una organización con dos cadenas de valor.
Página 4
Es común hablar de organizaciones que tienen una estrategia y objetivos corporativos. En

De hecho, si observa las declaraciones de estrategia y objetivos de las grandes organizaciones, usted
descubrirán que tienden a tener diferentes estrategias y objetivos para cada uno de sus principales valores
cadenas Por lo tanto, el objetivo de mejorar las ventas de neumáticos o reducir los costos de producción de neumáticos
probablemente el año sea bastante diferente al objetivo para mejorar las ventas de guías o reducirlas
costos de producción. En esencia, cada cadena de valor principal tiene su propio modelo de negocio. Cuando
uno está tratando de pensar ampliamente sobre una organización, es muy importante determinar si
la organización tiene una cadena de valor básica o tiene más de una. Si una organización tiene
más de una cadena de valor, entonces cada una debe considerarse de forma independiente, ya que los objetivos,
procesos, y los clientes variarán según la cadena de valor en la que se concentre.
La mayoría de los primeros trabajos de rediseño de procesos empresariales se centraron en los principales procesos que manejan
El departamento quería mejorar. Se contrataron consultores, en efecto, para hacer algo así
como "arreglar el proceso de ventas". En esas circunstancias, los consultores del proceso no querían
dedicar demasiado tiempo a la arquitectura, que las empresas no solían valorar, pero
quería obtener una buena visión general de la situación comercial antes de que comenzaran a enfocarse
demasiado estrecho en un proceso específico. En esas circunstancias, enfoques como los utilizados
por Rummler y Hammer tendieron a funcionar bien. Uno comenzó con una vista de alto nivel,
identificó media docena de procesos comerciales importantes y determinó cómo se relacionaban con
Se le pidió al proceso uno que lo rediseñara. En esencia, el trabajo de arquitectura establecido
un contexto para el trabajo de análisis de proceso más detallado que uno hizo cuando se centró en
el proceso específico se le pidió que mejorara. (Volveremos a arquitecturas simples
cuando consideramos cómo hacer el rediseño de procesos).
MARCO DE PUNTUACIÓN DEL CONSEJO DE LA CADENA DE SUMINISTRO

El primer trabajo sobre un concepto más moderno de una arquitectura empresarial fue un problema
iniciado hábilmente por el Supply Chain Council, una asociación de organizaciones que
se unieron para desarrollar estándares para el desarrollo de la cadena de suministro, a mediados de
1990s. Los gerentes de la cadena de suministro terminaron desarrollando una arquitectura estándar para
una cadena de suministro que las empresas podrían usar para definir sus propias cadenas de suministro y cómo
sus cadenas de suministro conectadas con otras cadenas de suministro. La figura 4.5 muestra una descripción general
el modelo básico de Referencia de Operaciones de la Cadena de Suministro (SCOR) que el SCC desarrolló
abierto En esencia, el equipo de estándares de SCC desarrolló un modelo de tres niveles. Trataron
la cadena de valor como nivel 0, y trató una cadena de suministro dada como nivel 1. Se subdividieron
una cadena de suministro en cuatro subprocesos principales: fuente, fabricación, entrega y devolución. En
Además, identificaron un proceso que denominaron Plan, que era necesario para
Cualquier otro proceso. En esencia, decían que cada cadena de suministro y cada
El proceso específico de hacer y devolver requería un proceso de gestión, al que llamaron
Planificar para controlarlo. Reconocieron tres variaciones en cada uno de esos subprocesos,
y definió un conjunto de subprocesos para cada una de las variaciones.
Página 5
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
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
Subprocesos de nivel 3 para un solo Regreso

Variación de nivel 2: S3
S3 Fuente del producto a pedido del motor
S3.1 S3.2 S3.3 S3.4 S3.5
Calendario Autorizar
Recibir Verificar Transferir
producto proveedor
producto producto producto
entregas pago
Figura 4.5 Los tres niveles del marco SCOR.
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
Cadena de suministro SCORcard Rendimiento vs Competitivo

Población
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%
Cumplimiento perfecto del pedido 0% 80% 85% 90% Ingresos de $ 30 millones
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
Flexibilidad de producción 45 días 30 dias 25 días 20 días
Costo Costo total de gestión de SCM 19% 13% 8% 3% Costo indirecto de $ 30 millones
Costo de la garantía N/ A N/ A N/ A N/ A N/ A
Valor agregado productividad del empleado N/ A $ 156K $ 306K $ 460K N/ A
Inventario de días de suministro 119 días 55 días 38 días 22 días N/ A

Bienes
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.6 Una tarjeta SCORcard con datos reales y de referencia.
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
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.
ARQUITECTURA EMPRESARIAL: EL ENFOQUE DE TI

Completamente independiente de los expertos en procesos de negocio como Rummler y
Hammer estaba haciendo, los expertos de TI estaban trabajando para definir arquitecturas que pudieran mostrar
cómo los sistemas de software encajan entre sí. Como las compañías habían desarrollado aplicaciones de software,
bases de datos, sistemas de comunicación y luego, luego, instalaron PC y desarrollaron
Internet, el mundo de la informática se había vuelto muy complejo. Grandes empresas a menudo
tuvo cientos de aplicaciones repartidas por todo el mundo, y ocasionalmente descubrió que
diferentes departamentos habían pagado diferentes precios por el mismo software que se estaba utilizando
en diferentes lugares Peor aún, a medida que el hardware y el software proliferaron, los proveedores introdujeron
estándares incompatibles, y se hizo cada vez más difícil ver cómo todo podría ser
unidos entre sí o podrían comunicarse de manera efectiva.
A fines de la década de 1980, las grandes empresas comenzaron a asignar personas, generalmente personas llamadas
Arquitectos empresariales: para crear modelos que muestren todos los activos de software y
organización tenía, y para imaginar cómo podría estar todo conectado. Como arquitectos empresariales
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
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)
Lista de procesos de negocios

Alcance/
(o cadenas de valor) el Lista de cosas que la empresa Lista de ubicaciones en las que
objetivos
apoyos de la empresa y la necesita hacer un seguimiento de la empresa opera
Nivel(Vista
1 del estadio)
objetivos para cada proceso
Empresa Base de datos de alto nivel

P rocesos de negocio
modelo modelos Mapa de unidades de negocio
diagramas
(Negocio (por ejemplo, relación de entidad (p. ej. red logística)
Nivel 2 (por ejemplo, diagramas de flujo de trabajo)
vista del propietario) modelos)
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)
Tecnología Arquitectura de sistemas

Objeto más detallado o Diseño de datos
modelo (por ejemplo, software del sistema,
diagramas de componentes (por ejemplo, segmentos, filas,
(Desarrollador hardware, línea
Nivel 4 (por ejemplo, objetos, mensajes) llaves, punteros)
ver) especificaciones)
Código de programa Red de arquitectura

Detallado Descripciones de diseño de datos
(p. ej. componentes, (por ejemplo, direcciones de nodo y
representaciones (por ejemplo, campos y direcciones)
Nivel 5 aplicaciones) protocolos de enlace)
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
Figura 4.7 Marco de Zachman de 1987 para la arquitectura de sistemas de información.
Página 9
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
Preliminar:
Marco de referencia &
principios
UNA
Arquitectura
visión
H
si
Arquitectura
Negocio
cambio
archiecture
administración
C
sol
Información
Implementación Requisitos
sistema
gobernancia
arquitecturas
F re
Migración Tecnología
planificación arquitectura
mi
Oportunidades y
soluciones
Figura 4.8 El Marco de Arquitectura de Grupo Abierto (T OGAF).
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
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
Figura 4.9 El Marco Federal de Arquitectura Empresarial (FEAF).
¿ Qué? Archiecture empresarial ¿ Quien? Y

¿ dónde?
Clientes,
socios &
competidores
¿ 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?
Productos y Flujos de valor Iniciativas

¿ Qué?
servicios y proy ectos
¿ Cómo?
¿ Cómo?
Métricas y Decisiones
medidas & eventos
¿ Cuando?
¿ Que tan bien?
Figura 4.10 El modelo de arquitectura empresarial de BIZBOK.
Pagina 12
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.
ARQUITECTURA DE PROCESOS EMPRESARIALES

Baste decir que este libro está escrito por un defensor de procesos de negocios, que cree
que los procesos, y específicamente la idea de la cadena de valor, deberían desempeñar un papel importante en
Arquitectura empresarial. Por lo tanto, en el resto de este capítulo nos centraremos en cómo un
La organización crea y utiliza lo que llamaremos una arquitectura de proceso de negocio, para evitar
cualquier confusión
Para aclarar aún más, necesitamos discriminar entre el uso del término "arquitec-
ture "para referirse estrictamente a un modelo o diagrama de proceso, y al uso más amplio del término
eso incluye no solo el modelo de proceso, sino también un sistema de medición de proceso, un proceso
sistema de gestión o gobierno, y alguna forma de alinear el proceso de negocio con el apoyo
recursos portuarios. Trabajando en la tradición del Modelo de Madurez de Capacidades, sostenemos que
Las organizaciones maduras no solo saben cómo encajan sus procesos, sino que también saben
Si sus procesos funcionan correctamente, tienen personas responsables de asegurar que
Página 13
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
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.
Planificar y controlar Definir políticas y Administrar financiera Proporcionar legal

sociedad procedimientos respiros apoyo
proceso
administración
Recoger Entregar
paquetes paquetes
Procesos centrales
Proporcionar humano Proporcionar / mantener Mantener Proporcionar / mantener Proporcionarla

recursos camiones instalaciones aeronave recursos
Proceso de apoyo
Figura 4.11 Una arquitectura de proceso simple.
Página 14
Anunciar Gestionar Gestionar

pizzas-R-Us publicidad financiero
compaigns datos
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ó
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
Teneduría de libros Monitor

información presupuesto
Vender
widgets Orden
Entregar
widgets
Obtener Widgets
Crear widgets
partes Partes
Cerrar
Orden orden
Software
Empleados aplicaciones
Proporcionar Mantener
empleados ESO
Figura 4.13 Un proceso de tercer nivel que se muestra con sus relaciones con otros procesos de tercer nivel.
Crear un modelo de arquitectura de procesos de negocio

Esta sección guiará a los lectores a través del enfoque para desarrollar un
modelo de arquitectura de procesos de negocio que recomendamos. Este enfoque ha sido ampliamente
utilizado por BPTrends Associates en el desarrollo real de arquitecturas y mapas de carreteras,
y representa un enfoque práctico del problema. El enfoque supone que un cónsul
tant (interno o externo) está trabajando con un equipo de gerentes que representan a todo el
organización. En esencia, el consultor guía al equipo a través de una serie de pasos que
da como resultado un modelo de arquitectura y luego, posteriormente, una hoja de ruta para la organización
mejoramiento
Cada paso consta de dos partes. El primer paso comienza con una reunión inicial en la que
el consultor explica cómo se organizará todo el esfuerzo y expone el trabajo
para hacerse durante el primer paso. Después de la reunión, los miembros individuales del equipo trabajan
juntos para lograr los objetivos del primer paso.
El segundo paso comienza con una segunda reunión. En este punto, el consultor revisa
los resultados de la primera ronda, y el equipo discute y finaliza el trabajo que tienen
hecho. Luego, el consultor presenta el trabajo que se debe hacer a continuación, proporcionando cualquier fondo
conceptos que el equipo puede requerir. Una vez que termina la segunda reunión, el equipo una vez más
procede a realizar una tarea, y una vez que se realiza la tarea, una tercera reunión
está programado (ver Figura 4.14 ).
La Figura 4.14 solo muestra cuatro reuniones, las reuniones necesarias para definir el
modelo de arquitectura En un esfuerzo de arquitectura de procesos comerciales a gran escala, tendríamos
otras reuniones para definir un sistema de medición de procesos, un sistema de gestión de procesos
tem, discuta la alineación y defina una hoja de ruta para mejorar los procesos interrumpidos que
fueron identificados en el curso del desarrollo del modelo arquitectónico. Vamos a ignorar
esos pasos posteriores por el momento, dejándolos para capítulos posteriores en este
libro.
Página 16
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.
Figura 4.14 Descripción general de los pasos en un esfuerzo de desarrollo de arquitectura.
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.
Paso 1. Reunión de inicio

Cualquier esfuerzo de arquitectura de procesos de negocio comienza definiendo el límite de la organización.
nización que vas a considerar. La organización en el ámbito puede ser un mundo
empresa, o el equipo de arquitectura puede limitar sus esfuerzos a una división dentro de una mayor
organización. Una vez que se ha identificado el alcance de la organización, se pregunta cuántos
cadenas de valor que la organización apoya. Determinar el número de cadenas de valor
la organización puede volverse compleja, pero el objetivo es asegurar que tenga un conjunto limpio de
cadenas de valor cuando haya terminado, para que luego pueda enfocar sus esfuerzos de análisis
en una cadena de valor a la vez. La figura 4.15 muestra a Michelin, una organización que tiene dos
cadenas de valor: Producir y vender neumáticos y Producir y vender guías de restaurantes. Los dos
Las líneas de negocio son más o menos independientes y deben analizarse independientemente.
La organización quiere una arquitectura integral de procesos de negocio, por lo que va
tener que modelar los procesos en ambas cadenas de valor. Para nuestros propósitos, asuma el equipo.
comienza con un esfuerzo por modelar los procesos en la cadena de valor Producir y vender neumáticos.
Paso 2. Alcance del proyecto

A continuación, el equipo analiza a las partes interesadas de la cadena de valor Producir y vender neumáticos.
Las partes interesadas, en este caso, pueden referirse a grupos internos o externos que tienen un
interés en si la cadena de valor tiene éxito o no. Ya hemos identificado
uno: los clientes de los neumáticos. Hay, sin embargo, otros. Por ejemplo, existe el
gestión de la organización. Están los accionistas de la organización. Ahí
Página 17
Organización
Clientes para
Cadena de valor: producir y vender neumáticos
llantas
Clientes para
Cadena de valor: producir y vender guías de restaurantes restaurante
guías
Figura 4.15 Una organización con dos cadenas de valor.
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
Proveedores y Clientes para

Cadena de valor: producir y vender neumáticos
socios llantas
Gobierno
Empleados
reguladores
Figura 4.16 Partes interesadas en la cadena de valor Producir y vender neumáticos.
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
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.
Paso 3. Definir procesos del ciclo de vida

Para simplificar las cosas, imagine que hay un importante proceso de negocio establecido dentro del
organización que está diseñada para apoyar a cada parte interesada. La figura 4.17 ilustra la situación.
ación que estamos imaginando. En esencia, cada uno de los bucles que se muestran en la Figura 4.17 es un valor
flujo (tal como lo define el instituto Lean Enterprise, un proceso que comienza con
una solicitud de una parte externa y finaliza cuando se satisface la solicitud). En la figura 4.17 , nosotros
manténgalo simple y suponga que cada parte interesada externa interactúa con la cadena de valor
de una manera.
En realidad, es más común que una parte interesada interactúe de múltiples maneras. Mirando
solo en la interacción cliente-cadena de valor entre un cliente bancario y un banco, por
Por ejemplo, llegamos a tres flujos de valor principales. Uno implica una solicitud por parte de un
cliente para abrir una nueva cuenta bancaria. Un segundo implica una solicitud del cliente para
un servicio específico, por ejemplo, cobrar un cheque en su nueva cuenta. Una tercera interacción
surge cuando el cliente solicita un servicio que el banco no ofrece actualmente, que
administración Accionistas
Administrar valor Gestionar

cadena accionistas
Gestionar Cadena de valor:

Proveedores y Crear y Clientes para
proveedores y producir y vender
socios neumáticos de mercado llantas
socios llantas
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
Cade na de valor: proporcionar se rvicios financie ros
Necesidad de nuevo
Necesidad de existir Servicio
Servicio
Flujo de valor
Cheque para cobrar
Desarrollar nuevo Vender Completar

Cliente
servicios servicios actas
Cheque cobrado
Se establece el servicio
Nuevo servicio disponible
Figura 4.18 Múltiples flujos de valor iniciados por un solo tipo de parte interesada.
Página 20
Cadena de valor: proporcionar servicios f inancieros Necesid ad d e u n n u ev o servicio.
Necesid ad de serv icio ex isten te
Des cribir Iniciar s es ión

Identificar
Servicio cheque
Es tablecer neces itar
Enviar cheque
Grupo de proyecto Verificar a
a FED / banco
Res ponder ser co brado
Prototipo
producto preguntas
L1 — Desarrollar L1 — Vender L1: completo

Cliente
nuevo servicio servicios transacción
Prueba
Completar
prototipo formas Regis tro
producto Ch equ e
Revis ar/ aprobado
aprobar nuevo trans acción cob rad o
Lanzamiento nuevo Es tablecer Actualizar
producto
producto Servicio cuentas
Co nfig uració n d e au torizació n d e servicio
Nu evo servicio d ispo nib le
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
Definir presupuesto para Establecer Rediseño /

Desarrollar estrategia Implementar Registro financiero Definir KM-BPM Monitorear KM-BPM
ocupaciones/ contabilidad mejorar
para la cadena de valor Plan estratégico eventos estrategia actuación
programas procedimientos procesos
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
Establecer objetivos de la cadena de valor Gestionar riesgos Administrar regulación

Determinar cómo
Definir objetivos para Desarrollar riesgo Desarrollar riesgo Identificar Establecer
Monitorear meta satisfacer
Procesos de gestionespecífico Definir proyectos
logro
administración administración conformidad conformidad conformidad
procesos estrategia programas requisitos programas
requisitos
Monitorear el riesgo Emprender Satisfacer Responder a Terminar

administración correctivo conformidad problemas o cumplimiento cuando
conformidad programas regulaciones quejas apropiado
Proporcionar servicios al consumidor.
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
Monitor Mantener / entregar Implementar y Implementar y Adquirir, desplegar

Outprocess Mantener
empleado Administrar proveedores bienes y mantener mantenlo & mantenlo
empleados datos empresariales
actuación servicios aplicaciones infraestructura hardware
Adquirir y mantener instalaciones Mantener la salud y la seguridad.
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
Paso 4. Organizar y consolidar los procesos de nivel 2

Usando el enfoque que hemos descrito, en el análisis bancario generalmente llegamos a algunos
100 procesos de nivel 2 que luego necesitábamos para organizar de manera más efectiva. Generando valor
los flujos para cada parte interesada tienen la ventaja de generar una lista bastante completa
de procesos. Tiene la desventaja de que el mismo proceso puede aparecer en más de uno
flujo de valor, y el mismo proceso puede recibir diferentes nombres, dependiendo de qué
grupo utiliza el proceso. Por lo tanto, después de completar el esfuerzo inicial y una lista completa
de los procesos generados, el equipo debe revisar todos los procesos de un determinado
cadena de valor y organizarlos en una lista coherente de procesos de nivel 1 y nivel 2 (ver
Figura 4.20)
El equipo tendrá una cierta cantidad de problemas para decidir qué procesos realizar
bine. Algunas organizaciones tienden a más procesos, y otras tienden a tratar de mantener
sus procesos de nivel 1 y 2 como mínimo. No existe una regla firme, pero es importante
ser coherente y mantener todos los procesos que defina son más o menos el mismo nivel de
granularidad La Figura 6 muestra los procesos de nivel 1 (gris) y nivel 2 que una organización
surgió Una cosa clave a tener en cuenta es que este modelo de arquitectura es más o
menos completo, en el sentido de que tiene un complemento completo de gestión y soporte
procesos, además de sus procesos centrales. Además, aunque no lo mostramos, en
En el proceso de llegar a la solución que se muestra en la Figura 4.20 , la mayoría de las organizaciones
ya tiene varios procesos de nivel 3 en cada uno de los rectángulos de nivel 2, procesos que
Originalmente llegaron cuando hicieron su análisis de flujo de valor, pero luego decidieron:
en reflexión, para combinar en un proceso de nivel 2 más universal. La otra cosa para
tenga en cuenta que no hay ningún esfuerzo para conectar ninguno de los procesos en un patrón de flujo
charranes Es cierto que los procesos centrales se organizan más o menos en el orden de flujo, pero
no se hace ningún esfuerzo para mostrar cómo se conecta un determinado soporte o proceso de gestión a
cualquier proceso central, o el uno al otro. Vincular procesos de nivel inferior en redes de flujo es
importar para rediseñar y mejorar procesos, pero es solo una distracción al crear
Modelos de arquitectura de nivel superior.
Como ya hemos sugerido, anteriormente, creamos una arquitectura de procesos de negocio para servir
como herramienta de administración, así como creamos una tabla de cuentas para servir como administración
herramienta. Los gerentes usan modelos de proceso en parte para comprender cómo funciona la organización,
pero principalmente para servir como una forma de monitorear el éxito o el fracaso de los procesos principales en
su organización y, por lo tanto, como una forma de identificar procesos que deben mejorarse.
Dicho esto, el enfoque actual en la arquitectura de procesos de negocio va más allá de la simple pro
cesa los esfuerzos de mejora y apoya el monitoreo, las estrategias de gestión de procesos y un
variedad de esfuerzos para externalizar o vincularse con socios en procesos que se extienden a través de múltiples
organizaciones tiples. Hasta hace poco, el enfoque de la arquitectura era relativamente primitivo,
pero los desarrollos en los últimos 5–10 años prometen transformar esta rama de BPM y
hacer que sea mucho más útil para las organizaciones que intentan centrarse en los procesos.
Página 23
DEFINIENDO UNA ARQUITECTURA MEDIANTE UN MARCO

Hasta ahora hemos discutido cómo se puede desarrollar un proceso de negocio integral.
arquitectura desde cero. De hecho, muchas organizaciones confían en los marcos publicados para
Proporcionar la estructura básica para sus esfuerzos arquitectónicos. Esto es especialmente popular si el
La industria en la que opera la empresa tiene un marco estándar, o si la organización
está interesado en crear un marco para un propósito especial. En este punto queremos mirar
en los marcos de procesos con un poco más de detalle.
MARCO DE PUNTUACIÓN DEL CONSEJO DE LA CADENA DE SUMINISTRO

El Supply Chain Council (SCC) se estableció como un consorcio sin fines de lucro en 1996.
Hoy, es una organización mundial con más de 900 miembros. El Consejo lleva a cabo reuniones
Ings que permiten a las empresas reunirse para discutir problemas y oportunidades de la cadena de suministro
nidades Además, ha estado trabajando en un marco de referencia o cadena de suministro estándar
modelo.
Antes de considerar SCOR en sí, consideremos por qué la membresía de SCC era
motivado para desarrollar el marco en primer lugar. Cada vez más, las empresas son
creando sistemas de cadena de suministro que cruzan los límites de la compañía. Por lo tanto, no es raro
de 10 a 20 empresas para sentarse a averiguar cómo funcionarán sus empresas
juntos para mover materiales a fabricantes y luego a distribuidores y, en última instancia,
A los consumidores. Si cada equipo tuviera que comenzar tratando de aclarar qué términos
utilizado para describir qué procesos, el esfuerzo llevaría mucho más tiempo. En cambio, el
El Supply Chain Council decidió definir un conjunto de procesos de alto nivel de la cadena de suministro
nombres que todos puedan usar. Cada compañía podría continuar usando cualquier par-
los nombres de proceso que eligen, pero en conversaciones con las otras compañías,
cada uno podría usar el vocabulario estándar definido por SCOR. Más tarde el modelo SCOR
se extendió para que no solo defina los procesos centrales, sino que también defina la gestión
y procesos de soporte y proporciona medidas de rendimiento definidas con precisión para cada
proceso. Usando la información de desempeño, las compañías pueden definir quién aprobará
qué a quién, cuándo, de manera inequívoca. Habiendo establecido una vez
sistema, los miembros de SCC luego procedieron a proporcionar información de rendimiento para
Una organización externa de evaluación comparativa que, a su vez, proporciona información general
en cambio. Por lo tanto, una empresa individual puede determinar cómo se procesan sus entregas
comparar con otros miembros del SCC o, más específicamente, con otros en el
misma industria Por lo tanto, SCOR comenzó como un esfuerzo para facilitar una comunicación eficiente
y modelado y evolucionado hacia una metodología general que puede usarse para
Definir una arquitectura de cadena de suministro completa con medidas comparativas.
Página 24
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
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.
DESARROLLO DE UNA ARQUITECTURA DE CADENA DE SUMINISTRO CON PUNTUACIÓN

Usando SCOR, una empresa puede caracterizar rápidamente su arquitectura de cadena de suministro
Ture. La figura 4.22 ilustra un mapa que los arquitectos SCOR suelen dibujar para mostrar dónde
los materiales se originan, cómo se mueven a los puntos de ensamblaje y luego se distribuyen a
clientes.
Una vez que la cadena de suministro se describe mediante un mapa, se vuelve a dibujar utilizando el
Convención de diagramación SCOR ilustrada en la figura 4.23 . El SCC se refiere al dia-
gramo como un diagrama de hilo. En este diagrama, cada proceso de nivel 2 en la cadena de suministro es
ilustrado con una pequeña punta de flecha. Las líneas en negrita separan a las compañías y la línea discontinua
separa las divisiones dentro de una empresa. Se da cuenta de que dos proveedores están alimentando a Alpha
Cadena de suministro de la empresa. Las letras indican que un proceso es un proceso de Fuente (S), un
Proceso de creación (M) o proceso de entrega (D). Los números indican la variación. Por lo tanto, un
S1 es un proceso fuente que se basa en productos almacenados continuamente, mientras que un M2 pro-
cess es un proceso de Make que se basa en proporcionar productos hechos a medida. (Referir
a la Figura 4.6 para las designaciones.) Un diagrama de subprocesos puede ser bastante más complejo
si la cadena de suministro involucra múltiples columnas de proveedores y columnas de distribuidores.
Página 25
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
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
Subprocesos de nivel 3 para un solo Regreso

Variación de nivel 2: S3
S3 Fuente del producto a pedido del motor
S3.1 S3.2 S3.3 S3.4 S3.5
Calendario Autorizar
Recibir Verificar Transferir
producto proveedor
producto producto producto
entregas pago
Figura 4.21 Los tres niveles de una arquitectura SCOR.
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
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
(S1, D1)
(SR1, DR1, DR3)
Fabricación
Almacén
(S1, S2, M1, D1)

(SR1, SR3, DR3)
Proveedor europeo
(S1)
(S1) (D2) (SR1, SR3)
(SR1, SR3) (DR1)
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)
Figura 4.22 Un mapa geográfico As-Is de la cadena de suministro de una empresa.
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
Figura 4.23 Un diagrama de hebra SCOR de un proceso simple de cadena de suministro.
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
Actuación De finición de atributo de re ndimie nto Nive l 1 mé trico

atributo
Cadena de suministro El rendimiento de la cadena de suministro en Rendimiento de entrega

confiabilidad de entrega entrega: el producto correcto, al correcto
colocar, en el momento correcto, en el estado correcto Tasas de llenado
atributos
y embalaje, en la cantidad correcta, con el
Cumplimiento perfecto del pedido
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
Productividad de valor agregado

Valor-
Garantía / procesamiento de devoluciones

costos
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
Figura 4.24 Atributos de rendimiento de SCOR y métricas de Nivel 1.
Cadena de suministro SCORcard Rendimiento vs competitivo

población
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%
Cumplimiento perfecto del pedido 0% 80% 85% 90% Ingresos de $ 30 millones
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
Flexibilidad de producción 45 días 30 dias 25 días 20 días
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
Valor agregado productividad del empleado N/ A $ 156K $ 306K $ 460K N/ A
Bienes Inventario de días de suministro 119 días 55 días 38 días 22 días N/ A
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
cadena de suministro de la empresa. En la columna de la derecha, el equipo ha hecho algunos "invitados-

compañeros "sobre qué tipo de valor podría lograr Alpha, suponiendo que pudiera mover su oferta
proceso en cadena más cercano al promedio de su industria. SCOR denomina la comparación de la
desempeño histórico real de la compañía con los puntos de referencia para la industria de la compañía
prueba como un análisis de brecha y lo usa para determinar si el rediseño o las mejoras en el As-Is
la cadena de suministro realmente justificará una inversión.
Una vez que el equipo SCOR ha examinado el Nivel 1, y en algunos casos el Nivel
2 Datos históricos tal cual, está en condiciones de decidir si la cadena de suministro debe ser
cambiado En efecto, 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 SCORcard proporciona
Una buena ilustración del poder del enfoque de la arquitectura. Una vez que una empresa tiene un
Resumen completo de todos sus procesos y datos sólidos de rendimiento, está posicionado para
considere cómo se desempeña cada uno de los procesos, compárelos con puntos de referencia,
y luego decidir qué posible intervención produciría la más significativa
resultado. Esto ilustra el sentido en que una arquitectura es una herramienta para la gestión.
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
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
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
Página 30
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
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
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
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
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 gestión empresarial.
Proveedor / socio Administracion de recursos Gestión De Servicios Mercado, producto y

relación y operaciones (IT) y operaciones relación con el cliente
administración administración
Estrategia, infraestructura y procesos de producto.
Procesos de operaciones
Proceso de cumplimiento Interfaz de cliente mang *

Compra S / P Aprovisionamiento de recursos y Configuración de servicio y
asignación al servicio Cumplimiento de marketing
activación
ejemplo respuesta
Orden de compra S / P
administración
Manejo de pedidos
Interfaz S / P * De venta
Retención y lealtad *
Proceso de aseguramiento Interfaz de cliente mang *

Informe de problemas S / P y Restauración de recursos Problema de servicio mang.
mang Manejo de problemas
Servicio de analisis de calidad
S / P rendimiento mang. acción e informes Cliente QoS / SLA mang.
Proveedores / Clientes
Interfaz S / P * Retención y lealtad *
socios
Proceso de facturación Interfaz de cliente mang *
S / P liquidaciones y facturación Recopilación de datos de recursos, Servicio y específico

análisis y control Facturaciones y colecciones
mang. calificación de instancia
mang.
Interfaz S / P *
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.
Operaciones S / PRM Disponibilidad de RM&O Disponibilidad de SM&O

Operaciones de CRM
preparación
preparación
Figura 4.26 Arquitectura de referencia eT OM del Foro TeleManagement.
34
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
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
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
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
Mi visión de Lean y, en particular, su uso del concepto de flujos de valor se debe

Una gran cantidad de conversaciones que he tenido con Steven Bell y el equipo al que se reunió
escriba Run , Grow , Transform : Integrating Business and Lean IT (Steven Bell, Editor. CRC
Press, 2013), que recomiendo encarecidamente a cualquier persona interesada en aplicar Leancon
conceptos en el área de TI.

Capítulo Cuatro - Arquitectura Empresarial

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Capítulo Cuatro - Arquitectura Empresarial

Încărcat de

Drepturi de autor:

Formate disponibile

19/9/2019 Capítulo cuatro - Arquitectura empresarial

Influencias ambientales generales:

Captial Capital Gestionar Información y

Crear nuevo Solicitudes de nuevos productos.

Figura 4.1 Un mapa de relaciones de una organización.

Gestión de recursos humanos

Entrante Saliente Márketing

Figura 4.2 Una cadena de valor en un cuadro de organización.

O rganiz ación de Unisys

Cadena de valor: integración de sistemas

Cadena de valor: Outsourcing

Cadena de valor: servicios de red

Cadena de valor: servicios básicos

Cadena de valor: tecnología de servidor empresarial

Figura 4.3 Una organización con múltiples cadenas de valor.

Corporación Miche lin

Cadena de valor: hacer y vender neumáticos

Crea nuevos tipos Solicitudes de nuevos productos.

Cadena de valor: investigar y publicar guías de restaurantes

Solicitudes de nuevos productos.

Figura 4.4 Una organización con dos cadenas de valor.

Es común hablar de organizaciones que tienen una estrategia y objetivos corporativos. En

MARCO DE PUNTUACIÓN DEL CONSEJO DE LA CADENA DE SUMINISTRO

Subprocesos de nivel 3 para un solo Regreso

S3 Fuente del producto a pedido del motor

S3.1 S3.2 S3.3 S3.4 S3.5

Figura 4.5 Los tres niveles del marco SCOR.

Cadena de suministro SCORcard Rendimiento vs Competitivo

Cumplimiento perfecto del pedido 0% 80% 85% 90% Ingresos de $ 30 millones

Flexibilidad de producción 45 días 30 dias 25 días 20 días

Valor agregado productividad del empleado N/ A $ 156K $ 306K $ 460K N/ A

Inventario de días de suministro 119 días 55 días 38 días 22 días N/ A

Figura 4.6 Una tarjeta SCORcard con datos reales y de referencia.

ARQUITECTURA EMPRESARIAL: EL ENFOQUE DE TI

Lista de procesos de negocios

Empresa Base de datos de alto nivel

Tecnología Arquitectura de sistemas

Código de programa Red de arquitectura

Figura 4.7 Marco de Zachman de 1987 para la arquitectura de sistemas de información.

Figura 4.8 El Marco de Arquitectura de Grupo Abierto (T OGAF).

Figura 4.9 El Marco Federal de Arquitectura Empresarial (FEAF).

¿ Qué? Archiecture empresarial ¿ Quien? Y

Productos y Flujos de valor Iniciativas

¿ Que tan bien?

Figura 4.10 El modelo de arquitectura empresarial de BIZBOK.

ARQUITECTURA DE PROCESOS EMPRESARIALES

Planificar y controlar Definir políticas y Administrar financiera Proporcionar legal

Proporcionar humano Proporcionar / mantener Mantener Proporcionar / mantener Proporcionarla

Figura 4.11 Una arquitectura de proceso simple.

Anunciar Gestionar Gestionar

Teneduría de libros Monitor

Crear un modelo de arquitectura de procesos de negocio

Figura 4.14 Descripción general de los pasos en un esfuerzo de desarrollo de arquitectura.

Paso 1. Reunión de inicio

Paso 2. Alcance del proyecto

Figura 4.15 Una organización con dos cadenas de valor.

Proveedores y Clientes para

Figura 4.16 Partes interesadas en la cadena de valor Producir y vender neumáticos.

Paso 3. Definir procesos del ciclo de vida

Administrar valor Gestionar

Gestionar Cadena de valor:

Cade na de valor: proporcionar se rvicios financie ros

Cheque para cobrar

Desarrollar nuevo Vender Completar