GESTIÓN DE PROCESOS DEL NEGOCIO CICLO 2018-I “Capítulo 4: Arquitectura de Procesos y Alineación Organizacional”
Capítulo 4
Arq uit ectu ra de Pr oc esos y Ali neami ento Organ izaci onal
La segunda fase de la metodología empresarial de BPTrends se centra en la creación de una arquitectura de procesos de negocio para la organización. Como ya hemos sugerido, creamos una arquitectura de empresa separada para cada cadena de valor, por lo cual, efectivamente, realmente estamos hablando de crear una arquitectura de procesos de negocio para una cadena de valor
Diferentes autores y diferentes empresas utilizan el término arquitectura de procesos empresariales de diversas maneras. En este libro, utilizaremos este término para referirnos a un conjunto de conocimientos sobre los procesos de negocio que forman parte de una cadena de valor. El conocimiento está organizado por una descomposición jerárquica de los procesos que conforman la cadena de valor. A su vez, los procesos organizan información sobre las medidas de rendimiento, los gestores de procesos y los recursos organizativos utilizados por los distintos procesos. Toda la arquitectura del proceso de negocio está organizada jerárquicamente para que los ejecutivos puedan ver cómo se alinean los procesos específicos para apoyar los objetivos estratégicos de la organización, las medidas del proceso y qué recursos se requieren para qué procesos y viceversa.
Jerarquía de Procesos
Una cadena de valor es el proceso más grande del que hablamos normalmente. Define un proceso que comienza cuando la empresa decide crear un nuevo producto o servicio, o cuando un cliente ordena un producto y concluye cuando el cliente tiene y está satisfecho con el producto o servicio. Hoy en día, algunas empresas hablan de cadenas de valor que se extienden a través de varias empresas, pero ese tipo de proceso multi-empresas todavía es relativamente raro. La cadena de valor s e denomina generalmente proceso de Nivel 0. Los principales procesos operativos dentro de una cadena de valor suelen ser procesos como Diseño de Nuevos Productos, Venta de Productos a Clientes y Creación y Entrega de Productos a Clientes (es decir, Cadena de Suministro). Cualquiera de estos procesos de Nivel 1 puede subdividirse en varios procesos de Nivel 2. Así, el marco SCOR del Consejo de Cadena de Suministro divide el proceso de la Cadena de Suministro Operacional de Nivel 2 en: Recursos, Producción, Entrega y Devolución.
Figura 4.1 Metodología empresarial de BPTrends
El uso de términos como superproceso y subproceso depende de donde se empiece. De cualquier proceso arbitrario, el proceso más grande que lo c ontiene es su superproceso. Del mismo modo, los procesos c ontenidos en el proceso arbitrario se denominan sus subprocesos.
Figura 4.2 Una descomposición jerárquica de una cadena de valor, que sugiere
No hay límite técnico para la subdivisión de procesos. Es común ver procesos divididos en tres o cuatro niveles. Es raro ver un proceso dividido en más de siete u ocho niveles. Para nuestros propósitos, el proceso más pequeño que se diagrama se llama una actividad. Hacemos esto simplemente porque los estándares de proceso como UML y BPMN definen arbitrariamente un proceso que consiste en actividades. Dicho esto, es común tener subdivisiones que no se diagrama y se definen por esquemas u otras definiciones textuales. Por lo tanto, usamos los términos pasos, tareas y procedimientos de forma suelta, o para describir los subelementos de una actividad.
cómo el "nivel de análisis" corresponde al nivel de proceso. Otros autores definen estos términos de maneras alternativas y no hay, por supuesto, ninguna forma definitiva de nombrar los niveles de proceso. Lo importante es simplemente tener en mente que los procesos pueden ser jerárquicamente arreglados y que usted necesita saber, al considerar un proyecto, si va a estar analizando un proceso relativamente grande, como una cadena de suministro; Un proceso mediano, como solicitar un préstamo o devolver un artículo; O un proceso pequeño, como obtener una aprobación de tarjeta de crédito, o revisar una solicitud de préstamo para completar. Definición de una Arquitectura de Proceso de Negocios Se puede crear una arquitectura de procesos de negocio en papel. Para ilustrar los conceptos básicos y las relaciones, usaremos hojas de trabajo para explicar el proceso. Cualquier gran empresa, sin embargo, querrá utilizar herramientas de software para crear y mantener su arquitectura de procesos de negocio. Las relaciones involucradas y la c antidad de datos involucrados rápidamente se vuelven tan complejas y extensas que se requiere una base de datos para administrar la arquitectura. Los pasos clave involucrados en la creación de una arquitectura de procesos de negocio son los siguientes: ➢ ➢
➢ ➢
➢
Identificar una cadena de valor específica. Determinar los objetivos estratégicos específicos que la cadena de valor debe alcanzar. Determine cómo va a medir si la cadena de valor logra sus objetivos o no. Subdividir la cadena de valor en sus procesos principales (procesos de nivel 1). Subdividir los procesos principales (procesos de nivel 1) en sus subprocesos (procesos de nivel 2). Si procede, subdividir los procesos del Nivel 2 en sus subprocesos (procesos del Nivel 3). Utilice una hoja de cálculo. Para cada proceso de Nivel 1, determine cómo el proceso de nivel 1 será moderado. Determinar quién será responsable del proceso. Determinar qué recursos están vinculados a cada proceso de Nivel 1.
Repita este procedimiento, utilizando hojas de cálculo nuevas, para cada proceso de Nivel 2, y así sucesivamente.
Figura 4.4 Un diagrama de organización que muestra los procesos principales en
Figura 4.3 Ilustra el encabezado de una hoja de trabajo de análisis de arquitectura e indica la información que debe incluirse.
Una vez que comenzamos a tratar de analizar un gran número de procesos y subprocesos, Es a menudo más fácil cambiar a un diagrama horizontal de la descomposición del proceso como el que se muestra en la Figura 4.5. En este caso hemos roto una Cadena de Valor de Widget en tres procesos principales, luego subdividimos cada uno de ellos en subprocesos y subdividimos uno de los procesos de nivel 2 en un conjunto adicional de subprocesos.
➢
una cadena de valor.
Figura 4.3 Una hoja de trabajo de análisis de arquitectura de Nivel 1.
En el capítulo 3 terminamos describiendo una cadena de valor en términos de tres subprocesos principales, como se muestra en la Figura 4.4
Figura 4.5 Descomposición horizontal de una cadena de valor en tres niveles de
proceso Existen diferentes maneras de desarrollar una descomposición integral de una cadena de valor. Uno puede comenzar con una sala llena de altos ejecutivos y un pizarrón blanco y simplemente preguntar: "OK, ¿cómo se producen los widgets? ¿Por dónde empiezas? ¿Qué sucede a continuación? "
Este es el enfoque tradicional y, aunque lleva mucho tiempo, es eficaz, ya menudo se plantea una gran cantidad de preocupaciones sobre cómo se hacen cosas específicas. En muchos casos, los ejecutivos no s e dan cuenta, antes de sentarse y tratar de describir lo confuso y redundante que algunos de sus procesos. A menudo, cada uno sólo se ha centrado en una u otra parte del proc eso y nunca trató de crear un diagrama que mostró c ómo encajan todos en una cadena de valor. Cada vez más hoy en día, los gerentes se acercan al análisis de arquitecturas de proceso de una manera diferente. Están utilizando marcos de procesos -modelos genéricos de todos los procesos en una cadena de valor o en una parte de una cadena de valor- para proporcionarles una descripción completa. Comenzando con un marco, los ejecutivos lo adaptan para proporcionar una descripción de su cadena de valor en particular. El enfoque basado en el proceso funciona porque, en los niveles 1 y 2, la mayoría de las empresas hacen las cosas de una manera muy similar, aunque utilizan palabras muy diferentes para describir sus procesos. Por lo tanto, cualquiera que sea su denominación, todo el mundo tiene algún tipo de nuevo proceso de desarrollo de productos / servicios, algún tipo de proceso de desarrollo de productos / servicios con un proceso de adquisición asociado y algún tipo de proceso de marketing y ventas.
Figura 4.6 Hojas de trabajo de análisis de arquitectura y una jerarquía de procesos. Completando una Hoja de Trabajo
Veremos los marcos de proceso más detalladamente en un momento; Mientras observa nuevamente el diagrama de descomposición de la cadena de valor horizontal representada en la Figura 4.5, puede ver cómo nos movemos de una descripción de proceso a hojas de trabajo. La Hoja de trabajo 1 proporciona un espacio para describir los atributos y recursos que soportan los procesos de Nivel 1 en una cadena de valor. Las diversas hojas de trabajo de nivel 2 permiten a los analistas profundizar en cada proceso específico de nivel 1 para identificar los atributos y recursos utilizados por los procesos de nivel 2.
Trabajando en la hoja de trabajo del Nivel 1 mostrada en la Figura 4.3, puede ver que la parte superior de la hoja de trabajo proporciona un espacio para el nombre de la cadena de valor y una descripción de cómo esa cadena de valor soporta la estrategia corporativa y cómo se medirá. En algunos casos esta discusión será breve. En otros casos, la disc usión llevará tiempo e involucrará a los altos directivos en discusiones muy serias sobre lo que la cadena de suministro debe procurar lograr. Algunos podrían ver la cadena de valor contribuyendo al beneficio de la empresa. Otros podrían sentir que la cadena de valor específica se estaba llevando a cabo para apoyar la imagen de la empresa o para generar ideas para futuras empresas. Los objetivos de la cadena de valor deben definirse concisamente y deben desarrollarse medidas que todos estén de acuerdo en reflejar con precisión el éxito o el fracaso de la cadena de valor. A continuación, el grupo de arquitectura debe definir los procesos de Nivel 1 que comprenden la cadena de valor. El truco es mantenerlos simples y generales y limitarlos a unos tres o siete procesos. La mayoría de los marcos genéricos se
enfocan en tres procesos de nivel 1: un proceso de diseño, un proceso de desar rollo / entrega de productos / servicios y un proceso de ventas / marketing / servicio. Procesos básicos, de soporte y de gestión
Hasta ahora, nos hemos centrado en los procesos básicos u operativos. Estos son procesos que agregan valor al producto o servicio que la organización está produciendo para sus clientes. Cuando Michael Porter definió la cadena de valor, distinguió entre el núcleo y los procesos de apoyo. Los procesos centrales generan productos o servicios. Los procesos de soporte no agregan valor, pero son necesarios para asegurar que los procesos centrales continúen funcionando. Así, en una organización manufacturera, la contabilidad es un proceso de apoyo. Mantenemos los libros para que la administración sepa cuánto cuesta la fabricación y para que puedan informar a los accionistas. Del mismo modo, IT es un proceso de soporte que genera y mantiene el software y los sistemas que la fabricación necesita para controlar su maquinaria de línea de producción. Hoy en día, es popular dividir los procesos de soporte entre los procesos que apoyan directamente los procesos centrales y los procesos de gestión más genéricos que planifican, organizan, comunican, monitorean y controlan las actividades de la organización. Los procesos de soporte a veces se llaman procesos habilitadores. Figura 4.7 Tres tipos de procesos: Centrales, Soporte y Gestión
La figur a 4.7 proporciona una forma de pensar acerca de la distinción. En este caso, tenemos un conjunto básico de procesos que genera un producto. Por separado, tenemos un proceso de soporte -el Proceso de reorganización de existencias- que repone un proceso de ensamblaje de núcleo. También tenemos un proceso de gestión que determina qué proveedores utilizará la empresa y establecerá y mantendrá relaciones con los proveedores. Obviamente, este proceso de gestión podría ser una actividad emprendida por la adquisición, pero también podría ser un proceso emprendido por las finanzas.
¿Deberíamos incluir procesos de soporte o habilitación en nuestra arquitectura de procesos de negocio y, en caso afirmativo, cómo los debemos representar? Un enfoque sería dividir todos los procesos de soporte y organizar los procesos de soporte bajo los procesos centrales que lo permiten. Esto es conceptualmente limpio, pero no es, de hecho, muy realista. En la mayoría de los casos, una empresa conceptualiza su grupo de TI como un departamento. En el mejor de los casos, el grupo de TI se gestiona como una organización matricial y cuenta con algunos gerentes responsables de funciones genéricas de TI, como el desarrollo de nuevos productos y mantenimiento de software en curso, y otros responsables del soporte de TI para la cadena de suministro y soporte de ventas y marketing. La clave aquí, sin embargo, es que la TI tiene un conjunto básico de funciones, como la red de la empresa y buenas prácticas de mantenimiento, que se aplican a todos los procesos o departamentos que soporta; Por lo tanto, hay un argumento muy fuerte para tratar la TI como un departamento independiente.
Un enfoque alternativo, cada vez más popular, es tratar a la TI como una organización independiente, un centro de costos o una cadena de valor independiente. Esto refleja lo que ocurre cuan do se externaliza la TI. En esencia, IT se convierte en una compañía separada, una cadena de valor que produce software y servicios que vende a los procesos centrales de la empresa matriz. Independientemente de que su empresa externaliza IT o la mantiene en casa, si la considera como su propia cadena de valor y crea una arquitectura de procesos de negocio independiente para describir los procesos de núcleo, soporte y administración de TI, verá que facilita todo. Obviamente, la misma lógica puede aplicarse a los otros procesos principales de apoyo, incluidos los recursos humanos, las instalaciones y la contabilidad. Si sigue este enfoque, dejará los procesos de soporte de las hojas de trabajo de arquitectura de procesos de negocio que crea para sus cadenas de valor fundamentales y describirá cada proceso de soporte principal como una arquitectura independiente con sus propias hojas de trabajo. Manejar los procesos de gestión es más complicado, porque la idea de los procesos de gestión no ha sido muy bien pensada. Para empezar, necesitamos discriminar entre dos tipos básicos de "procesos de gestión". En un caso, tenemos los procesos o actividades que realizan los individuos que realmente administran los procesos en el día a día. Por lo tanto, si consideramos la Figura 4.7, hay un individuo que es responsable de administrar el proceso de Relleno de la acción. Ese individuo planea, organiza, comunica, monitorea y controla el proceso de llenar la orden del archivo cada hora de cada día. Él o ella interactúan con los empleados que llevan a cabo las tareas que asociamos con el proceso de llenar orden del almacén, comunica nuevos objetivos a medida que ocurren y proporciona retroalimentación cuando los empleados hacen su trabajo de manera excepcional o inaceptable. No es útil tratar la gestión cotidiana del proceso directamente asociada con el proceso central como un proceso separado. Cuando se busca rediseñar o mejorar el proceso, es necesario considerar las actividades de los empleados asignados al proceso y, simultáneamente, las actividades del gerente que se encarga del proceso. En la medida en que es útil discriminar estos procesos cotidianos de gestión de procesos, se hace para definir los procedimientos estándar o de mejores prácticas que deben seguir los administradores de procesos. Consideraremos las prácticas de gestión de procesos es tándar más adelante, cuando consideremos la gestión de procesos y el establecimiento de grupos de soporte de BPM. En este punto, sin embargo, simplemente ignoraremos estos procesos de gestión cotidianos. Están tan estrechamente asociados con los procesos centrales que no
necesitan una representación independiente en nuestra arquitectura de procesos de negocio. Siguen existiendo algunos procesos generales de gestión que realizan funciones de planificación, organización, comunicación o supervisión de la empresa. En esencia, si la organización tiene un grupo de reglas de negocio que trabaja para definir las políticas de la empresa y dictar las reglas de negocio que los procesos específicos deben implementar, ese grupo y los procesos que implementa constituyen una especie de proceso de gestión. Del mismo modo, el equipo que define la estrategia corporativa sigue un proceso y el grupo BPM implementa un conjunto de procesos. Estos son procesos de gestión verdaderos que son independientes de los procesos centrales en una cadena de valor normal. Las empresas sofisticadas querrán analizar estos procesos de gestión para asegurar que funcionen de la manera más eficiente y eficaz posible. Por lo tanto, debemos definirlos y documentar cómo funcionan. La cuestión es dónde incluirlas. A diferencia de los procesos de soporte estándar, como TI y recursos humanos, es difícil pensar en estos "procesos de gestión" como un centro de coste o una empresa independiente. Es más fácil pensar simplemente en ellos como actividades emprendidas por los altos directivos. Por el momento, probablemente es mejor pensar simplemente en todos los "procesos de gestión" que son independientes de procesos operativos específicos como su propia "cadena de valor de gestión" y documentarlos en sus propias hojas de trabajo. No es una solución muy elegante, pero es probablemente mejor que tratar de asociarlos con una cadena de valor convencional.
Ali neaci ón d e geren tes, med idas y rec urs os
A medida que se identifican los procesos, el grupo puede determinar quién es responsable de administrar ese proceso. Si la empresa está orientada funcionalmente, en el nivel más alto será frecuente que no haya un gestor claro para los procesos de nivel 1. En cambio, los procesos se dividirán entre múltiples departamentos, sin que nadie sea responsable de la coordinación general. Vamos a pasar por alto cualquier otra discusión de la gestión de procesos en este punto y retrasarla hasta llegar al Capítulo 5. Baste decir que, si el equipo tiene problemas para asignar los gerentes a los procesos, eso debería estimular una discusión sobre cómo se manejan los procesos en la organización. A continuación, el equipo debe definir el objetivo de cada proceso de Nivel 1 y considerar cómo debe medirse el éxito de cada uno de los procesos de Nivel 1. Al
igual que con la administración, retrasaremos la discusión de la medición hasta llegar al siguiente capítulo. La columna final de la hoja de cálculo pide al equipo de arquitectura que enumere los recursos necesarios para soportar cada proceso de Nivel 1. Esto hace hincapié en que el desarrollo de una arquitectura de procesos de negocio es una empresa a largo plazo. Obviamente, el equipo de arquitectura no pudo identificar los trabajos o los sistemas de software asociados con cada proceso de Nivel 1 en el transcurso de un día o una semana. De hecho, la mayoría de las organizaciones omite la alineación de recursos durante el primer paso, y dejarlo hasta que toda la arquitectura se entienda mejor. A medida que pasa el tiempo, la organización y los interesados en los procesos encontrarán que sería útil determinar cómo se alinean los diferentes recursos, y luego procederán a capturar información sobre la alineación de esos recursos. Muchas organizaciones crean una arquitectura y, a continuación, le añaden información detallada de recursos a medida que la organización emprende proyectos de cambio de procesos empresariales. En este caso, nadie se propone enumerar cada aplicación ERP que utiliza cada proceso, pero a medida que se rediseñan los procesos, se captura la información sobre el soporte ERP y se agrega a la base de datos de arquitectura. Algunos de los tipos de recursos que las organizaciones podrían tratar de alinear con el Nivel 1 o los procesos de Nivel 2 incluyen: ➢
➢
con estr ategi as y metas co rpo rati vas. Algunas organizaciones listan información sobre las estrategias específicas de nivel 1 y las partes interesadas observan cómo las estrategias específicas apoyan las estrategias corporativas. Otros enumeran a todos los interesados que están interesados en cada proceso específico del Nivel 1.
determinación del crédito al cliente ocurrió en varios procesos de Nivel 1 y 2, y que en algunos casos lo hicieron los empleados y en otros casos se hizo con un módulo ERP. Ser ía bueno saber dónde se determinó el crédito al cliente, para que la actividad pudiera ser estandarizada y el mismo software podría ser usado siempre que sea posible. Por lo tanto, la simple enumeración de subprocesos y actividades que s e producen en múltiples procesos de Nivel 1 puede ser m uy útil. ➢
Ali neami ento con po lític as y regl as . Muchas organizaciones enumeran
las políticas corporativas que se aplican a procesos específicos de Nivel 1 o 2. A medida que el análisis se hace más completo, las organizaciones pueden enumerar las reglas de negocio específicas que se utilizan en subprocesos específicos y, a continuación, comprobar que las políticas y las reglas se aplican de forma coherente. ➢
Ali neac ión con recu rso s de TI. Muchas organizaciones indican qué
aplicaciones de software o qué bases de datos se utilizan para estos procesos. Si el esfuerzo por correlacionar los recursos de TI con procesos empresariales específicos se vuelve muy elaborado, a menudo se denomina arquitectura empresarial. Si una empresa utiliza aplicaciones ERP, la arquitectura del proceso suele estar impulsada o soportada por arquitecturas de procesos sugeridas por los proveedores de ERP.
Ali neami ento
Ali neac ión
➢
Ali neac ión co n Sarban es-Oxl ey, ISO 9000 y d iver so s están dares de gestión de riesgos . Las organizaciones son cada vez más responsables
Ali neac ión c on ot ros p roc esos . Hasta ahora hemos enfatizado procesos
básicos u operativos. Una vez que se definen los procesos operativos, algunas empresas proceden a describir los procesos de gestión y s oporte e indican qué procesos básicos u operativos dependen de qué procesos de gestión o soporte. Vamos a considerar esto en más detalle en el próximo capítulo cuando hablamos de gestión. Muchas empresas están interesadas en identificar subprocesos específicos o actividades que se repiten en diferentes procesos de Nivel 1 o 2. Supongamos, por ejemplo, que un proceso de nivel 1 incluye un subproceso de nivel 3 o 4 que se denomina: Determinar crédito de cliente. Imaginemos, además, que la
co n recu rso s de recu rso s hum anos . Muchas organizaciones definen qué funciones o trabajos están asociados con los procesos de Nivel 2 o 3. Si esto se lleva a cabo, se pueden definir las descripciones de tareas asociadas con los procesos o definir las competencias de los trabajos. Del mismo modo, algunas organizaciones de la lista de los documentos de los empleados y los programas de formación que se dan en apoyo en cada proceso específico.
➢
de reunir y mantener información sobre las decisiones y los riesgos involucrados en procesos específicos. Esta información puede colocarse naturalmente en la base de datos de la arquitectura de procesos de negocio. A medida que pasa el tiempo y se recopila más información, las organizaciones con completas arquitecturas de procesos de negocios se
encuentran invirtiendo el proceso y utilizando la base de datos de la arquitectura para generar la información requerida por las agencias externas. Una arquitectura de procesos de negocio es una herramienta de gestión. Una vez que se define y luego se rellena con datos actualizados, se puede utilizar, al igual que otras bases de datos, para responder a preguntas ad hoc que los ejecutivos necesitan respuesta. Puede ser utilizado para apoyar a aquellos involucrados en el desarrollo de estrategias corporativas y puede ser utilizado por un grupo de BPM para identificar procesos que no están cumpliendo sus objetivos y que necesitan ser rediseñados. La información que se coloque en la base de datos de arquitectura de procesos de negocio dependerá de cómo lo utilice la empresa. La mayoría de las empresas que han c reado arquitecturas encuentran que facilitan a los gerentes la conceptualización de sus organizaciones en términos de procesos, lo que lleva a solicitar más y más información sobre los procesos que soporta la empresa. Definición de una arquitectura de proc esos empresariales
Uno crea una arquitectura de proceso de negocio descomponiendo una cadena de valor en procesos y subprocesos. Como señalamos anteriormente, los esfuerzos de análisis de procesos son cada vez más de alto nivel y están siendo apoyados por el uso de marcos de procesos. En este punto, queremos ver los marcos de proceso en un poco más de detalle. El Marco SCOR del Consejo de la Cadena de Suministro:
El Consejo de la Cadena de Suministro (SCC) fue establecido como un consorcio sin fines de lucro en 1996. Hoy en día, es una organización mundial con más de 700 miembros. El Consejo realiza reuniones que permiten a las empresas reunirse para discutir problemas y oportunidades en la cadena de suministro. Además, ha estado trabajando en un marco estándar de la cadena de suministro o modelo de referencia, SCOR. Antes de considerar SCOR en sí, vamos a considerar por qué la membresía SCC fue motivado para desarrollar el marco en el primer lugar. Cada vez más, las empresas están creando sistemas de cadena de suministro que cruzan los límites de la empresa. Por lo tanto, no es raro que diez o veinte compañías se sienten para
averiguar cómo sus empresas trabajarán juntas para trasladar los materiales a los fabricantes y luego a los distribuidores y, en última instancia, a los clientes. Si cada equipo tuviera que empezar intentando corregir qué términos utilizaban para describir qué procesos, el esfuerzo llevaría mucho más tiempo. En cambio, el Consejo de la Cadena de Suministros decidió definir un conjunto de alto nivel de los nombres de procesos de la cadena de suministro que todos podrían utilizar. Cada empresa podría seguir utilizando los nombres de procesos particulares que eligiera, pero en conversaciones con las otras empresas, cada una podría utilizar el vocabulario estándar definido por SCOR. Posteriormente, el modelo SCOR se amplió para que no sólo defina los procesos centrales, sino que también define procesos de gestión y soporte y proporciona medidas de rendimiento definidas con precisión para cada proceso. Utilizando la información de rendimiento, las empresas pueden definir quién pasará qué a quién y cuándo, de una manera inequívoca. Una vez que se estableció el sistema, los miembros de SCC procedieron a proporcionar información sobre el desempeño a una organización externa de evaluación comparativa que proporciona información general a cambio. Así, una empresa individual puede determinar cómo sus procesos de entrega se comparan con otros miembros del SCC o, más específicamente, con otros en el mismo sector. Así, SCOR comenzó como un esfuerzo para facilitar la comunicación y el modelado eficaces y se convirtió en una met odología general que se puede utilizar para definir rápidamente una arquitectura de cadena de suministro completa con medidas de referencia. Empecemos con una mirada m ás detallada a la arquitectura SCOR. El SCC habla de SCOR como compuesto de tres niveles. Ignoran el hecho de que la cadena de suministro es sólo uno de los principales procesos empresariales que conforman toda la cadena de valor. Para aclarar esto, siempre nos referiremos a la cadena de valor como Nivel 0. Luego nos referiremos a la cadena de suministro como un proceso de Nivel 1. Para hacer las cosas aún más complejas, SCOR subdivide la cadena de suministro en tres "niveles", pero, de hecho, uno de los niveles no es una descomposición del nivel superior, sino que requiere que el modelador defina el proceso de nivel superior en términos de Una de tres variaciones. El proceso de la fuente de nivel 1 se refiere a los productos almacenados o se refiere a los productos hechos a la medida, o con los productos de la ingeniería a pedido. Para simplificar las cosas, siempre hablaremos de SCOR como de tres niveles. El nivel 1 es la cadena de suministro. Nivel 2 consiste en los procesos de alto nivel que componen una cadena de suministro, incluyendo Fuente, Marca, Entrega y Devolución. Plan es un proceso SCOR adicional que describe la planificación de la gestión. Estos
procesos de Nivel 2 se definen por primera vez. Luego se especifica su variación, y luego se descomponen en un conjunto de subprocesos de Nivel 3, como se ilustra en la Figura 4.8.
Con SCOR, una empresa puede caracterizar rápidamente su arquitectura de cadena de suministro. La figura 4.9 ilustra un mapa que los arquitectos de SCOR usualmente dibujan para mostrar dónde se originan los materiales y cómo se trasladan a los puntos de ensamblaje y luego s e distribuyen a los clientes.
Figura 4.9. Un mapa de la geografía como es de la cadena de suministro de una
empresa. Figura 4.8.Los tres niveles de una arquitectura SCOR.
El manual de referencia de SCOR define cada subproceso de Nivel 2 y Nivel 3 y también indica qué procesos de planificación y soporte están típicamente vinculados a cada proceso o subproceso. El SCC no define un cuarto nivel, dejando la especificación de las actividades de Nivel 4 a empresas individuales. En otras palabras, SCOR define una arquitectura de la cadena de suministro y todos los procesos de alto nivel y deja la implementación técnica de los procesos de Nivel 4 a los miembros individuales. Desarrollo de una arquitectura de cadena de suministro con SCOR
Una vez que la cadena de suministro se describe mediante un mapa, se vuelve a dibujar utilizando La convención de diagramación SCOR ilustrada en la figura 4.10. El SCC se refiere a El diagrama como un diagrama de hilo. En este diagrama, cada proceso de Nivel 2 en el suministro Alimentando la cadena de suministro de la compañía Alpha. Las letras indican que un proceso es un proceso Source (S), un proceso Make (M) o un proceso Deliver (D). Los números indican la variación.
Por lo tanto, un S1 es un proceso de origen que se basa en productos almacenados continuamente, mientras que un proceso de M2 es un proceso de fabricación que se basa en la prestación de productos que están hechos a la medida. (Consulte la Figura 4.6 para las designaciones). Un diagrama de hilos puede ser bastante más complejo si la cadena de suministro involucra múltiples columnas de proveedores y columnas de distribuidores. Del mismo modo, en los diagramas más completos, también se introducen los procesos del Plan. En efecto, como Plan se refiere a un esfuerzo de gestión de procesos. Para cada proceso básico que se muestra en e l diagrama de hilos, también hay un proceso Plan.
Figura 4.10. Un diagrama de rosca de SCOR de un proceso simple de la cadena
de fuente. El Consejo de la Cadena de Suministros ofrece a los miembros un manual de referencia que define cada proceso y subproceso de la cadena de suministro. Además, el manual describe medidas de rendimiento que son apropiadas para cada proceso en cada nivel. El SCC divide todas las medidas de rendimiento en cinco categorías generales, que luego se agrupan en métricas externas de cara al cliente o métricas internas. La Figura 4.11 proporciona una visión general de alto nivel de las medidas que se definen para la cadena de suministro en su conjunto (el proceso de Nivel 1). Nos vamos a centrar en medidas aquí, pero basta con decir que se puede utilizar la métrica SCOR para generar rápidamente una lista de interconexión de métricas para toda una arquitectura de la cadena de suministro.
Figura 4.11. Los atributos de rendimiento SCOR y las métricas de nivel 1.
Varias organizaciones que rastrean los puntos de referencia están trabajando con el Consejo de la Cadena de Suministro y pueden proporcionar puntos de referencia genéricos para las medidas de SCOR para industrias específicas. Si una empresa desea datos de referencia específicos, necesita contratar con uno de los grupos de evaluación comparativa. En la figura 4.12, ilustramos lo que SCOR se refiere como SCORcard. Muestra los atributos de rendimiento, un conjunto de datos históricos y los datos de referencia para la cadena de suministro hipotética de una empresa. En la columna de la derecha, el equipo ha hecho algunos "guestimates" sobre qué clase de valor Alpha podría alcanzar, asumiendo que podría mover su proceso de la cadena de fuente más cercano al promedio para su industria. SCOR califica la comparación del desempeño histórico real de la empresa con los puntos de
referencia para la industria de la compañía como un análisis de brecha y lo usa para determinar si el rediseño o las mejoras en la cadena de suministro de As-Is
La extensión de SCOR
La siguiente parte de la historia de SCOR está estrechamente relacionada con Joseph Francis y la fusión Hewlett-Packard-Compaq. La fusión de HP-Compaq fue anunciada en septiembre de 2001. Los dos años anteriores habían atestiguado una depresión importante en ventas, que había forzado muchas compañías de TI a reevaluar sus estrategias. La fusión propuesta de dos empresas líderes de TI -la mayor fusión de TI hasta la fecha- representó una importante iniciativa estratégica por parte de los equipos directivos de ambas compañías para cambiar la dinámica general del mercado de TI.
justificarán realmente una inversión. Figura 4.12. Un SCORcard con datos reales y de referencia, con algunas conjeturas
sobre el valor que se podría lograr mediante el rediseño de la cadena de suministro que se analiza Una vez que el equipo de SCOR ha examinado los datos históricos de nivel 1 y, en algunos casos, de nivel 2, tal y como están, está en condiciones de decidir si se debe cambiar la cadena de suministro. De hecho, ahora está listo para revisar el enfoque existente de la organización para su cadena de suministro y, si es necesario, definir una nueva estrategia de cadena de suministro y establecer objetivos, prioridades y un presupuesto para cualquier esfuerzo de re diseño. El uso de la tarjeta SCOR proporciona una buena ilustración de la potencia del enfoque de la arquitectura. Una vez que una empresa tiene una visión completa de todos sus procesos y sólidos datos de desempeño, se posiciona para considerar cómo cada uno de los procesos está realizando, compararlos con puntos de referencia y luego decidir qué intervención posible produciría el resultado más significativo. Esto ilustra el sentido en el que una arquitectura es una herramienta de gestión.
HP fue un líder en servidores de gama media, en PCs y portátiles, y en impresoras. También fue un líder en servicios de integración y outsourcing y tuvo una reputación mundial de tecnología de vanguardia. Al mismo tiempo, sin embargo, HP no era lo suficientemente grande como para competir por los m ayores contratos de servicios, que normalmente iban a mayores competidores como IBM. Además, las proezas de marketing de HP habían disminuido en los últimos años. En 2001, por ejemplo, HP tenía unas 6.000 personas en marketing, mientras que los competidores de tamaño similar manejaban con un tercio del total. Compaq era aún más fuerte que HP en ventas de PC y portátiles, pero carecía de la fuerza de HP en todas las demás áreas. Compaq había adquirido Tandem Computers and Digital Equipment a finales de los años 90 en un esfuerzo por diversificar, pero nunca había logrado utilizar las fortalezas de Tandem o Digital en computadoras, tecnología o consultoría de rango medio para alcanzar la presencia en el mercado que esperaba obtener cuando Hizo esas adquisiciones. Por otro lado, Compaq era conocido por sus agresivas capacidades de marketing. La fusión de las dos empresas daría lugar a una empresa significativamente mayor. Juntos, HP y Compaq estarían en c ondiciones de dominar el mercado de las ventas de PC, portátiles, servidores e impresoras. Al mismo tiempo, la empresa c ombinada sería casi tan grande como IBM y, por lo tanto, estaría bien posicionada para competir en igualdad de condiciones para los contratos de servicios y de outsourcing más grandes. La nueva empresa también estaría en la posición de exigir a los proveedores que le ofrezcan los mayores descuentos posibles. Además, dado que había un considerable solapamiento en el área de PC, las dos compañías
esperaban sacar unos 2.500 millones de dólares en ahorros anuales, al tiempo que creaban una organización más ágil y agresiva. Desde el principio, la fusión propuesta era c ontrovertida. Los argumentos acerca de la sabiduría de la fusión y la lucha por poderes que siguieron han sido ampliamente reportados en la prensa popular. En definitiva, de hecho, la fusión real fue más suave de lo que se esperaba y dio lugar a mayores ahorros que los que planearon la fusión esperaba. Como admitieron los más fuertes oponentes de la fusión, la planificación que precedió a la fusión fue excelente. Lo que nos interesa es el proceso de planificación que ayudó a que la fusión fuera exitosa. Específicamente, queremos considerar las actividades del equipo de planificación de la fusión que planificó la integración de los procesos de la cadena de suministro de HP-Compaq. Tan pronto c omo la fusión se anunció formalmente, se creó una nueva organización para planificar la fusión. Esta organización de fusión en última instancia, incluyó a unos 1.000 empleados de las dos empresas. Los empleados se reunieron en lo que se conoce como un ambiente de sala limpia. En efecto, estaban separados del trabajo cotidiano de HP y Compaq, colocados en un entorno aislado, proporcionaron información detallada sobre ambas compañías y pidieron desarrollar un plan de fusión. La organización de la fusión estaba encabezada por un comité ejecutivo que tomaba decisiones estratégicas de alto nivel y, finalmente, aprobó todas las recomendaciones detalladas de los equipos más especializados. Los informes al comité ejecutivo fueron ocho equipos que se centraron en áreas específicas de preocupación. Había equipos para infraestructura de TI, cadena de suministro, ventas / órdenes, diseño de productos, comunicaciones / marketing, finanzas, recursos humanos y servicios / soporte. Algunos de los equipos carecían de un marco general y tenían que crear un nuevo vocabulario común y una forma estándar de identificar los procesos existentes. Por suerte, los gerentes de HP y Compaq que eran miembros del equipo de Supply Chain estaban familiarizados con el trabajo del Consejo de la Cadena de Suministro (SCC). El equipo de HP- Compaq Supply Chain se dio cuenta de que podía utilizar SCOR para simplificar en gran medida su tarea. SCOR proporcionó un enfoque estándar que podría utilizar para caracterizar y medir rápidamente los procesos de la cadena de suministro tanto de HP c omo de Compaq. Al acordar previamente el mapeo de los procesos de ambas compañías al modelo SCOR y utilizar el vocabulario y las medidas estándar de SCOR, el equipo HP-
Compaq logró cumplir en un mes lo que de otro modo habría tardado muchos meses. La facilidad de uso de SCOR fue fundamental para el trabajo realizado por el equipo de TI de Supply Chain durante la fusión. SCOR hizo posible que el equipo analizara rápidamente todas las cadenas de suministro de HP y Compaq para todas las regiones y líneas de productos. Este análisis, a su vez, hizo posible que el equipo de TI de Supply Chain comparara con precisión un proceso de Compaq con un proceso de HP para líneas de productos similares, para determinar lo que cada proceso realmente logró. El grupo HP-Compaq Supply Chain fue capaz de definir todas sus cadenas de suministro rápidamente, basándose simplemente en las definiciones de nivel 1 de SCOR. En efecto, todas las cadenas de suministro se dividieron rápidamente en procesos de Sourcing, procesos de Fabricación y Entrega, así como algunos procesos adicionales de planificación y habilitación. Una vez hecho esto, se identificaron las aplicaciones de software de alto nivel que soportaban cada uno de estos procesos. SCOR proporciona un conjunto bien definido de medidas para cada uno de los procesos de Nivel 1. Estas medidas están vinculadas a medidas financieras establecidas que ambas empresas han seguido durante años. Así, en la mayoría de los casos, se utilizó simplemente las medidas del Nivel 1 de SCOR para comparar dos líneas regionales para determinar qué línea era la más eficiente y rentable. Si una línea era claramente más eficiente que la otra, entonces el grupo de TI de la Cadena de Suministro tendía a seleccionar simplemente las aplicaciones que soportaban el proceso más eficiente. Aquellos familiarizados con la manera en que los técnicos pueden discrepar sobre las virtudes de las aplicaciones de software competidor pueden imaginar fácilmente que el grupo de TI de la cadena de suministro podría haberse convertido en un escenario de intensos argumentos entre los defensores de HP y Compaq de aplicaciones de software alternativas. El equipo de TI de la Cadena de Suministros sabía que si permitían que la discusión se concentrará en características técnicas específicas nunca lograrían su tarea. Además, una discusión técnica no aseguraría que la aplicación elegida estuviera alineada con los objetivos corporativos. En su lugar, el grupo sabía que era importante que su trabajo se centra en el valor que las diversas aplicaciones entregadas a la empresa. En efecto, el grupo decidió seleccionar aquellas
aplicaciones que apoyaban los procesos más eficientes, sin tener en cuenta a qué empresa apoyaba actualmente la aplicación, ni a qué departamentos estaban involucrados. Algunas de las medidas se centran en los resultados externos y algunos se centran en la eficiencia interna. En cada caso, el CCS ha definido definiciones precisas de las medidas. Ninguna organización desearía aplicar todas estas medidas a un proceso o subproceso SCOR determinado. En cambio, el SCC tiene una metodología que ayuda a los profesionales a alinear las medidas que consideran con los objetivos estratégicos que la compañía está tratando de lograr con un proceso determinado de la cadena de suministro. Considere el objetivo de una determinada línea de productos. Si la empresa quería competir en el mercado de esa línea de productos como proveedor de bajo costo, se centraría en mantener una cantidad mínima de inventario, ya que el bajo inventario es una de las maneras de mantener bajos los costos. Por otro lado, si la empresa estaba comprometida con el servicio y quería asegurar que los clientes siempre pudieran obtener lo que querían, tendría que aceptar mayores costos de inventario y se centraría, en cambio, en satisfacer las solicitudes de los clientes. Diferentes estrategias requieren diferentes medidas. El grupo empresarial Supply Chain tomó la mayoría de las decisiones sobre estrategias de marketing para las líneas de productos combinados y el grupo de TI de la cadena de suministro luego seleccionó las medidas apropiadas y las utilizó para comparar el comportamiento de las líneas de productos HP y Compaq existentes.
las aplicaciones comunes que la empresa fusionada podría eventualmente estandarizar en, en todo el mundo. Las aplicaciones identificadas no eran nuevas aplicaciones que adquiriría la empresa fusionada, sino aplicaciones que ya están siendo utilizadas con líneas de productos exitosas que la compañía estandarizaría y migraría para minimizar el número de aplicaciones que el nuevo HP necesitaría soportar. Al final de esta fase, el grupo de TI de Cadena de Suministro había identificado todas las líneas de productos que debían ser soportadas en la empresa fusionada, había identificado todas las aplicaciones que debían m antenerse y las que debían ser retiradas e identificó un conjunto De los estándares arquitectónicos generales que la compañía se movería hacia tan pronto como sea posible. Otros equipos de HP-Compaq hicieron sus recomendaciones, pero las recomendaciones del equipo de Supply Chain se destacaron porque se basaron en un análisis de los procesos involucrados y números duros en el desempeño de los procesos. Las recomendaciones del equipo de Supply Chain para utilizar aplicaciones de software específicas se justificaron por el desempeño de los procesos que habían utilizado esas aplicaciones. La lógica de negocio detrás del trabajo del equipo de la Cadena de Suministro llevó al nombramiento del líder del equipo, Joe Francis, al jefe del nuevo programa de la mejora del proceso del negocio de HP. La extensi ón de SCOR en HP
En algunos casos, dos líneas regionales competidoras parecen ser igualmente eficientes y eficaces cuando se analizan con medidas de Nivel 1. En esos casos, el equipo de TI de la Cadena de Suministro ampliará su esfuerzo y modelará los procesos al Nivel 2 de SCOR o incluso, en muy pocos casos, al Nivel 3. Aproximadamente el 20% del tiempo total utilizado por el equipo de la Cadena de Suministro se utilizó en procesos de modelado, medición de ellos, aplicación de criterios y juicios sobre qué aplicaciones ahorrar y qué descartar. Una vez que el grupo de Cadena de Suministro había identificado líneas de productos para mantener, modelar los procesos y luego evaluar y seleccionar aplicaciones para mantener, fue posible retroceder de los procesos específicos de la cadena de suministro que se está evaluando e identificar una arquitectura genérica de cadena de suministro para la combinación empresa. En efecto, esta arquitectura identificó los procesos de suministro comunes, derivados de SCOR, y
A Joe Francis le impresionó cómo el marco S COR había facilitado su análisis de los procesos existentes de la cadena de suministro. Dado que su nuevo trabajo requería que mirara otros procesos en HP, montó un equipo y comenzó a desarrollar marcos, como SCOR, para marketing, ventas, desarrollo de nuevos productos y para varios procesos de soporte. En 2003, en parte debido al trabajo que había hecho durante la fusión HP-Compaq, Joe Francis fue elegido presidente de la junta de directores del SCC. Hacia 2003 HP había desarrollado varios marcos. Sin embargo, a diferencia del marco SCOR, estos nuevos marcos sólo habían sido desarrollados por el personal de HP y no había puntos de referencia disponibles para usar con ellos. Para remediar esto, Joe Francis persuadió a HP para que ofreciera los marcos que habían desarrollado al SCC para alentar al SCC a expandirse más allá de su
enfoque en la cadena de suministro y eventualmente ofrecer un marco completo de cadena de valor. Hoy en día, el SCC está avanzando más allá de SCOR y ha creado estándares iniciales para un modelo DCOR (cadena de diseño) y un modelo CCOR (cadena de clientes). Así, en el transcurso de los próximos años, a medida que los miembros de SCC utilicen estos nuevos marcos e informen sobre sus resultados, deberían estar disponibles puntos de referencia para todos los procesos básicos de una cadena de suministro típica. Esto, a su vez, significa que será posible que una empresa caracterice rápidamente toda una arquitectura utilizando procesos estándares y comparados. Otros enfoques
Al mismo tiempo que el SCC decidió lanzar su extensión de SCOR, un grupo separado de ex miembros de SCC creó un nuevo grupo para extender SCOR en un marco completo de la cadena de valor. Este grupo, el Value-Chain Council (VCC), ha creado su propio modelo, el Value Reference Model (VRM) 1, que es similar al SCOR pero en algunos aspectos mejor integrado. Obviamente, con SCOR tan bien establecida, el esfuerzo del SCC se ha centrado en la adición de nuevos procesos dejando intacto el actual modelo SCOR. El Consejo de la Cadena de Valor pudo comenzar de cero y realizó algunos cambios en SCOR para simplificar el marco general. La figura 4.13 ilustra el enfoque de VRM.
Figura 4.13. El marco de VRM del Consejo de Cadena de Valor.
Obsérvese que el modelo de VRM no discrimina la cadena de suministro como un proceso: hemos demostrado dónde podría insertarse entre los niveles 1 y 2 de VRM, sino que simplemente trata los cuatro procesos de Level 2 de SCOR. Fuente (Buy), Make, Deliver (Fulfill) Y Retorno (Apoyo), como cuatro de los ocho procesos principales. En el nivel superior, VRM disc rimina entre los procesos de Planificación (los denominaríamos procesos de Gestión), los procesos de Ejecución (los llamaríamos Core) y los procesos de Gestión (que llamaríamos procesos de soporte). Los detalles del modelo VRM en evolución no son demasiado importantes. Lo importante es que VCC está trabajando en un marco de cadena de valor completo. Así como SCOR tiene procesos y medidas, VRM incluye tanto un marco de proceso como un esquema de medición de rendimiento. La Figura 4.14 sugiere cómo los procesos Plan y Manage soportan el proceso de ejecución básico.
Figura 4.14 Planificar y gestionar los procesos asociados con el proceso de
ejecución.
El SCC tiene 700 miembros, un presupuesto anual establecido, y mucho dinamismo. Por otra parte, su membresía ha estado compuesta históricamente de administradores de la cadena de suministro y muchos de esos miembros han resistido los esfuerzos del SCC para expandirse a otras áreas del proceso. El VCC es nuevo y tiene sólo unos pocos miembros. Tiene la ventaja de empezar desde cero y aprovechar todo lo que el SCC ha aprendido, pero tiene el reto de reclutar miembros y luego construir una base de datos de referencias fiables. Por el momento, las dos organizaciones están compitiendo y cada una estimulando los esfuerzos del otro. Con suerte, en unos pocos años se producirá una fusión y resultará en un marco de la cadena de valor que combina lo mejor de los dos enfoques.
arquitectura. Una de las principales ventajas de los sistemas de comercio electrónico es que integran la gestión y las operaciones, y es importante que todos tengan una visión general clara de todos los procesos si quieren ver cómo puede producirse la integración. La figura 4.15 muestra una versión de la estructura eTOM, reordenada para que coincida con el formato que usamos en este libro. En efecto, giramos el diagrama básico de eTOM 90 grados hacia la derecha. El cliente se movió a la derecha del diagrama para que los procesos fluyan ahora de izquierda a derecha y las unidades
El marco del eTOM del Foro TeleManagement :
Otra aproximación a un marco completo de la cadena de valor es proporcionada por el TeleManagement Forum, un consorcio de compañías de telecomunicaciones. Su estructura está altamente adaptada a las necesidades de las empresas de telecomunicaciones. Por lo tanto, no puede ser utilizado por las notelecomunicaciones, pero sí proporciona un enfoque integral para las em presas de telecomunicaciones. Un grupo del TeleManagement Forum ha dedicado varios años a desarrollar una arquitectura de proceso para las empresas de telecomunicaciones. Se supone que ninguna empresa específica tendrá exactamente los mismos procesos identificados por el TeleManagement Forum, y que probablemente usará nombres diferentes para los distintos procesos. Por lo tanto, se trata de una arquitectura de referencia en lugar de una arquitectura de un negocio específico. Se supone que a medida que pasa el tiempo, la mayoría de los miembros se moverán hacia esta arquitectura de proceso y que, durante el mismo período, los vendedores adaptarán los productos para implementar muchos de los procesos definidos por el modelo. La arquitectura que describimos es la tercera iteración que el Foro de TeleManagement ha desarrollado. Esta última iteración, llamada eBusiness Telecom Operations Map (eTOM), se basa en trabajos anteriores que sólo buscaban definir los procesos operativos dentro de las compañías de telecomunicaciones. Sin embargo, a medida que las compañías empezaron a implementar aplicaciones de e-business, descubrieron que los procesos incluidos en la administración general y de la empresa tenían que ser agregados a la
funcionales fluyan hacia abajo, como lo hacen típicamente los organigramas. Figura 4.15. La arquitectura de referencia eTOM del TeleManagement Forum.
La figura 4.15 proporciona una idea de cómo está organizada una compañía de telecomunicaciones. En esencia, una telecom vende tiempo en su red a los clientes.
Dado que el tiempo se vende y se controla mediante computadoras que rastrean el acceso telefónico, Servicio y Recurso son funciones importantes. Dado que casi todas las llamadas de larga distancia cruzan múltiples redes, los acuerdos con otras compañías de telecomunicaciones-socios-son muy importantes. Sospechamos que las compañías telefónicas reales podrían subdividir sus departamentos de manera algo diferente, colocando marketing y servicio en departamentos separados, pero recuerde que la mayoría de las ventas de teléfonos y las solicitudes de servicio llegan a través de un centro de llamadas común. En cualquier caso, la figura 4.15 proporciona una idea de cómo un grupo de gerentes de telecomunicaciones consideró que podrían representar a sus organizaciones. Al mirar la versión modificada del diagrama eTOM, está claro que los tres bloques sombreados son grupos de procesos de negocio. Dentro de cada grupo, hay subprocesos. Al dividir los procesos de la manera que tienen, no está claro si las operaciones representan una cadena de valor o no. La clave sería si se pudieran agregar los costos de todos los procesos dentro de la caja de Operaciones para determinar el costo total y el margen de beneficio en una línea de productos, en este caso, el servicio telefónico. Si pudiera, eso significaría que todo en las dos cajas sombreadas inferiores podría agruparse como sobrecarga y as ignarse a una única cadena de valor-Operaciones telefónicas. Lo importante no es la notación, sin embargo, pero el hecho de que la Figura 4.14 proporcionaría un comité de arquitectura de procesos de telecomunicaciones con una visión general de la empresa. Cada comité de arquitectura de procesos empresariales necesita algo similar a la figura 4.15 para tener una manera estándar de describir los procesos de su empresa e identificar procesos que requieren cambios cuando se anuncian nuevas estrategias y m etas. Observe que algunos subprocesos se producen dentro de varios procesos. Estos subprocesos están marcados con un asterisco para resaltar el hecho. Por lo tanto, la Gestión de Interfaz de Cliente-presumiblemente un conjunto de actividades de gestión de portal de clientes- es compartido por los procesos de Cumplimiento, Aseguramiento y Facturación. De manera similar, un subproceso de Gestión de Interfaz Proveedor / Asociado es compartido por estos mismos procesos. Si no es un ejecutivo de telecomunicaciones, es posible que no esté familiarizado con algunos de los términos utilizados para describir los distintos subprocesos. Lo importante es que esta arquitectura de procesos empresariales ilustra un marco suficientemente detallado para que un comité de arquitectura de procesos de
telecomunicaciones que estuviera familiarizado con su propia organización pudiera ser razonablemente eficiente para determinar qué procesos o subprocesos necesitarían ser cambiados para lograr cambios específicos en Estrategia y objetivos de la empresa. Uno podría imaginar fácilmente un documento de acompañamiento que proporcionara descripciones escritas cortas de cada uno de los subprocesos. La figura 4.15 plantea dos cuestiones que consideraremos con más detalle más adelante en este libro. En primer lugar, sugiere la posibilidad de un sistema de gestión matricial. Alguien suele ser responsable de procesos completos como Cumplimiento. Esa persona piensa en cómo todos los subprocesos de Cumplimiento trabajan juntos para entregar servicios al cliente de una manera suave y eficiente. Alguien más probablemente sea responsable de la Administración y Operaciones del Servicio. Los empleados que trabajan en el subproceso de configuración y activación de servicios probablemente informen al administrador de servicios y gestión de operaciones. Por lo tanto, un gerente trabaja para asegurar que el proceso completo funciona de manera eficiente. Otro es responsable de los empleados que realizan algunos de los subprocesos dentro del proceso de Cumplimiento y dentro de otros procesos también. La otra cuestión que es obvia cuando empezamos a discutir un marco c omo eTOM es cuántas veces aparece el proceso de la palabra. Cuando el gráfico es tan s imple como el de la figura 4.15, podemos vivir con grupos de procesos, procesos y subprocesos. Ya hemos visto cómo el proceso final es una cadena de valor. La mayoría de las organizaciones sólo tienen unas pocas cadenas de valor. Sospechamos que todo el marco de eTOM realmente sólo representa una cadena de valor que ofrece servicios de telecomunicaciones a los clientes. Otros Marcos:
Apenas hemos considerado todos los marcos de arquitectura existentes disponibles. El gobierno de los Estados Unidos tiene uno y varios organismos gubernamentales que tienen otros. El consorcio de la industria de seguros, ACORD, está trabajando en un marco para la industria de seguros, y probablemente hay otros de los que aún no hemos oído hablar. El punto, sin embargo, es que las empresas que emprenden el desarrollo de una arquitectura de procesos de negocio están hoy en condiciones de acelerar grandemente el proceso empezando con uno de los marcos disponibles y luego adaptándolo a sus necesidades específicas.
De las declaraciones de estrategia a una arquitectura de procesos
Empezamos con una visión general de cómo se desarrolla una arquitectura de procesos de negocio. Vimos que se podría utilizar una descripción de proceso para organizar la recopilación y alineación de datos sobre los procesos. Luego consideramos cómo un equipo de desarrollo de arquitectura de proceso real puede utilizar un marco de proceso como SCOR, VRM o eTOM para acelerar el proceso de desarrollo arquitectónico. Los marcos no proporcionan una estrategia de gestión, ni sugieren alineaciones específicas, sino que proporcionan una descomposición sistemática de los procesos de alto nivel y sugieren medidas de rendimiento que pueden utilizarse para todos los procesos en una arquitectura. Uno puede utilizar un marco para llenar rápidamente las hojas de trabajo o rellenar una base de datos de procesos empresariales y luego adaptarlo y comenzar a alinear la información del recurso. Así, en un tiempo muy corto, una empresa puede comenzar a beneficiarse del tipo de análisis y priorización del proyecto que se puede derivar de tener una arquitectura de proceso eficaz.
