NIVELES Y ESTILOS DE MODELAMIENTO DE PROCESOS CON BPMN

Nuestra experiencia de modelamiento formal de procesos en cientos de proyectos del MBE nos ha llevado a identificar varios niveles de detalle de representación:

 

·      Un primer nivel  tiene que ver con la arquitectura de procesos de una empresa, la cual puede ser para todos los procesos de una empresa o una parte de ellos, que es relevante para la generación de un determinado producto o servicio.

·      El segundo nivel tiene que ver con el diseño de los procesos que conforman la arquitectura, con un énfasis en la determinación de los subprocesos y actividades que los componen y las relaciones por medio de flujos de información entre éstos que permiten un funcionamiento adecuado; este modelamiento no es procedural.

·      El tercer nivel que detalla, para las actividades más elementales del segundo nivel, la lógica  de ejecución de las mismas en interacción  con un apoyo computacional, incluyendo la posibilidad de que exista lógica compleja, por ejemplo de evaluación de riesgo en crédito, que se automatiza. Este nivel es procedural en el sentido de definir secuencias estrictas de procesamiento al estilo de lógica computacional.

 

Tal como se presenta en la Primera Parte del libro Ingeniería de Negocios, muchas empresas líderes en BPM en el mundo modelan los tres niveles recién definidos con metodologías y técnicas diversas, sin que necesariamente se asegure consistencia entre tales niveles. En el MBE hemos desarrollado un enfoque de modelamiento unificado de los tres niveles anteriores basado en BPMN como herramienta. Este enfoque distingue estilos de modelamiento como sigue.

 

Para representar los diseños de primer y segundo nivel utilizaremos una técnica de modelamiento que se nutre de varias propuestas de representación y de nuestra experiencia con diversos enfoques. La idea fundamental es que se requieren estilos diferentes, pero complementarios, de modelamiento, dependiendo del grado de detalle que se quiere expresar. Así, para expresar lo que es la arquitectura de procesos  y el diseño de los procesos de segundo nivel proponemos un estilo de modelamiento que enfatiza la estructura y el flujo, vale decir los componentes de un proceso y sus relaciones por medio de flujos de información, y que es no procedural. Ahora, para representar el detalle más técnico del diseño de procesos de tercer nivel, incluidos los apoyos computacionales, proponemos un estilo totalmente procedural que enfatiza secuencia de actividades y lógica de control. Veremos que estos estilos son totalmente complementarios, ya que el segundo tomará las representaciones del primero y las detallará en la dirección ya señalada.

 

El primer estilo no procedural modela según las convenciones de IDEF0, pero utilizando una herramienta de software para editar modelos BPMN. Ésta es una notación muy reciente que tiene una gran cantidad de elementos de representación. En esta parte, como ya lo indicamos, utilizaremos un estilo de modelamiento orientado al flujo del proceso, en el cual enfatizamos los componentes que participan y sus relaciones por medio de flujos de información. Dado que BPMN tiene una clara orientación a la secuencia y lógica de control, debemos usar en forma creativa algunos de sus elementos para representar flujos de información en el estilo IDEF0, lo cual se detalla en la Segunda y Tercera  Partes del libro Ingeniería de Negocios, las cuales están recién actualizadas.

 

 

El segundo estilo de modelamiento, que detalla los modelos del primer estilo, se utiliza cuando llegamos al diseño detallado de los procesos, incluyendo la lógica asociada a los apoyos computacionales; en él adoptaremos las convenciones de BPMN en su concepción de secuencia y lógica de control, lo cual sí lleva a sincronismo. Aquí definiremos dos subestilos: uno que no pretende la simulación y ejecución de los procesos y otro que sí  lo permitirá. La diferencia entre éstos es el grado de formalidad de la representación, ya que, en el segundo caso, deben respetarse convenciones estrictas de BPMN que hacen factible la simulación y ejecución. La ventaja de esta segunda variante  es que, bajo determinadas condiciones, los apoyos computacionales al proceso se pueden generar en forma automática, sin necesidad de diseño computacional ni escritura de código. Esto es factible debido a que BPMN fue diseñado para que las representaciones gráficas, que cumplan con ciertas condiciones, puedan ser convertidas a un lenguaje computacional llamado BPEL (Business Process Execution Language), el cual puede ser ejecutado en servidores apropiados. En la práctica, es difícil que todo un proceso detallado de acuerdo al estilo enunciado pueda ser llevado a una representación que permita ejecución. En muchos casos sólo será factible tomar una parte del proceso, típicamente aquélla que queremos que funcione en forma más automática, para modelamiento orientado a la ejecución. En las partes siguientes del libro mencionado se detallará el uso de este segundo estilo.

 

En resumen, dependiendo del nivel de detalle en que nos encontremos dentro del modelamiento y los objetivos de diseño que persigamos, utilizaremos estilos diferentes de representación, que se pueden definir como consistentes y complementarios. 

Graduación Primera Generación Magíster en Ingeniería de Negocios con TI 2008

Ver Noticia en Boletín Informativo FCFM

dsc_9338.JPG

dsc_9209.JPG

dsc_9315.JPG

dsc_9263.JPG

dsc_9213.JPG

dsc_9325.JPG

dsc_9260.JPG

dsc_9208.JPG

Ver Noticia en Boletín Informativo FCFM

Ver Galería de Fotos

Ingeniería de Negocios: Arquetipos del Inconsciente Organizacional (Andrés Bustamante V)

En el siguiente artículo trataremos de abordar como la Ingeniería de Negocios, desde su concepción epistemológica y metodológica se transforma en un acercamiento práctico y revolucionario para el diseño de arquitecturas empresariales e implementacióntecnológica.

 

“…es un gran error admitir que el alma del recién nacido es una tabula rasa y afirmar que en ella no hay absolutamente nada. Puesto que el niño llega al mundo con un cerebro predeterminado por la herencia y diferenciado, y por lo tanto también individualizado, no se enfrenta a los estímulos de los sentidos con cualquier disposición sino con una disposición especifica, que condiciona una selección y configuración peculiar (individual) a la percepción. (…) Su existencia estampa en el mundo del niño su sello antropomórfico. Son los arquetipos.”(Jung, 1954).

 

Para Gustav Jung, importante psicoanalista, discípulo de Freud y gran estudioso de la antropología y los símbolos, los arquetipos son como senderos característicos de lo estrictamente humano y que hacen el modo de vivir. Estos se encuentran en todos los pueblos y civilizaciones, donde los personajes mitológicos, las leyendas y cuentos frecuentemente señalan interpretaciones de los arquetipos existentes en el inconsciente.  Más allá de ser una explicación teórica a la gran vastedad de enigmas que existen en nuestro inconsciente, la idea de los arquetipos nace con Platón, quien habló en su momento de las “ideas puras”. Los arquetipos, serían como estas ideas puras del “ser” humano (“ser” empleado como verbo), que éste interpreta individualmente y debido a su propia vivencia y desarrollo. Si bien en los pueblos antiguos los arquetipos se proyectaban en dioses de altas cualidades humanas, hoy la separación del hombre frente al misticismo hace que estos arquetipos se guarden celosamente en el inconsciente y sean proyectados en el mundo sin permiso de la conciencia.

 

¿Qué tiene que ver esto con un enfoque de ingeniería? La primera relación entre los arquetipos del inconsciente colectivo  y la metodología de BE (Business Engineering), es evidente y se relaciona con el postulado de la existencia de patrones de procesos. Estas especificaciones, que incluyen niveles de detalle superiores a una mera descripción del proceso, están basadas en la experiencia con muchos casos de negocios, “destilando” lo medular de los procesos empresariales y entregando una suerte de “arquetipo”  o “plantilla” sobre el cual trabajar, que permite ahorros enormes en el proceso de implementación (o consultoría) tanto a nivel de modelamiento de la situación actual como de rediseño de procesos en virtud de que se cuenta con esta “carta de navegación”, que permite a la organización focalizarse en el desarrollo de sus “core competences” y capitalizar la experiencia de otras empresas para fortalecer y optimizar de la mejor manera aquellas que las apoyan.

 

Las implicancias prácticas de este enfoque son enormes tanto en términos de agilidad como de costos. Personalmente he utilizado este conocimiento de patrones en proyectos de alta complejidad y criticidad con resultados muy importantes tanto en el ámbito público como privado. Por ejemplo en la implementación de una de las redes de comunicaciones integradas más grandes de Latinoamérica (Ruta 5D del Ministerio de Salud), se utilizo el patrón de gestión de proyectos para el seguimiento y control de las obras y actividades de gestión del cambio, el patrón  de venta y atención de clientes, para la comunicación y apoyo a las contrapartes locales y el patrón de gestión de proveedores para el desarrollo de un sistema automatizado de gestión de incidencias y compras con el proveedor de comunicaciones. El uso de estos patrones permitió la construcción de sistemas de apoyo a los procesos de forma extremadamente ágil, utilizando plataformas colaborativas y herramientas RAD que apoyaran las diferentes actividades y relaciones (adaptadas al dominio en particular) que el patrón ya incluía. El resultado fue un sistema integral de gestión de proyectos, seguimiento de clientes internos e interacción con el proveedor que facilitó enormemente la gestión de la implementación  de un proyecto de alta complejidad.

 

En el caso de la implementación de la Reforma Previsional, el uso de patrones de procesos como Venta y atención de clientes, sumado a la experiencia anterior del equipo del INP en atención, concesión y pago de otros beneficios, facilitó enormemente su generalización al nuevo set de beneficios al entregar bases con bastante nivel de detalle para el modelamiento y documentación de los procesos. Por otra parte, la existencia de un patrón de relaciones entre procesos, facilitó el diseño del registro de la información del proceso de modo de generar indicadores para monitorear la calidad del proceso.

 

Casos similares pude vivir en la empresa privada con una importante empresa de combustibles y otra dedicada a los estudios de mercado, dos rubros que parecen completamente diferentes, pero en los cuales el patrón de gestión de proyectos, permitió optimizar las operaciones e implementar herramientas de software para control y seguimiento en un breve tiempo y con importantes resultados. En el caso de la empresa de estudios de mercado, así como una consultora en desarrollo organizacional, el uso del patrón de venta y atención de clientes, facilitó el diseño de una estrategia de gestión de relaciones con clientes y la implementación de un CRM.

 

En resumen, el uso de patrones para el diseño de procesos, presenta una ventaja decisiva en el modelamiento y rediseño de procesos de negocios, gestionando el conocimiento acumulado de diferentes industrias y presentándonos un conjunto de “Arquetipos del inconsciente empresarial”.

 

 

Estructurando la realidad

 

El segundo punto de unión entre una teoría de la organización de la realidad (desde el punto de vista del ser humano) y la Ingeniería de Negocios, es epistemológica y metodológica. Personalmente, creo que este enfoque va más  allá de una herramienta metodológica común, que incluye un conjunto de prácticas para lograr un objetivo (diseñar procesos o sistemas), presentándonos un modo de hacer las cosas, de ver la realidad y construirla. Esto último es de gran relevancia, ya que el mundo en que vivimos, se materializa en nuestra existencia (conciencia) en un formato “digital”, donde codificamos un estimulo biológico real, en una secuencia lingüística que le da significación y que en conjunto con la cultura y el contexto adquiere un determinado sentido para nosotros. Desde este punto de vista y siguiendo con la frase de Eisenberg, la realidad “tiende” a existir, en tanto seamos capaces de “nombrarla” y generar distinciones. Bateson dijo al respecto que “el mapa no es el territorio” dado que, efectivamente, lo que hacemos es “dibujar” unos límites o fronteras sobre algo dado y que por ende, puede ser afectado por la mirada del observador. Es así como, encontramos centenares de textos que muestran diferentes “modelos” de organización, que al  ser revisados en su contexto, parecen tener sentido todos y cada uno de ellos, dado que son delimitaciones diferentes sobre una misma realidad, en este caso, la realidad organizacional, cuyo único elemento realmente concreto es su competitividad.

 

Entonces, es necesario desde el punto de vista metodológico, contar con un metamodelo, que tenga la capacidad de explicar, al igual que en el estudio de los organismos vivos, cuál es el diseño óptimo que permite que el sistema mantenga su “homeostasis”, su identidad y funcionamiento optimo.

La BE soluciona este problema mediante la derivación de frameworks de los patrones de proceso que explicitan en modelos UML las unidades de información (células) y las formas de comunicación de la misma (interacciones, feedback), de modo de asegurar que las partes del sistema sean capaces de orquestar un funcionamiento adecuado que mantenga la estabilidad del sistema y al mismo tiempo la capacidad de autocorregirse en base a los indicadores clave definidos por el mismo sistema en base al contexto. De este modo, no solo provee el modelo para estructurar el proceso (patrón), sino que un modelo arquitectónico para generar los soportes de tecnológicos y de gestión de información relevante para sustentarlos.

 

Tomando los casos antes mencionados, podemos ver de forma concreta como la derivación de frameworks de software a partir de patrones de proceso y la metodología para hacerlo tiene efectos prácticos en la solución de proyectos complejos. A modo de ejemplo:

 

El patrón de procesos de gestión de proyectos que hemos estado desarrollando en este magíster, permitió la derivación de un framework de apoyo tecnológico colaborativo para el seguimiento y control de los proyectos que permitió la construcción de software de apoyo para la gestión de proyectos de una empresa de estudios de mercado, la gerencia de operaciones de una empresa de combustibles, la gestión de la implementación de la Red de comunicaciones 5D del MINSAL y se está comenzando a implementar actualmente en un proyectos estratégico del gobierno. Por otra parte, el patrón de proceso y su derivación en frameworks orientados a servicios y atención de clientes, permitieron acelerar la implementación de software de apoyo a la atención, como el caso del pilar solidario, la gestión de contratistas en la implementación de la ruta 5D MINSAL, la gestión de clientes en diversas empresas consultoras de servicios profesionales y varias iniciativas actuales de gobierno en las que participo.

 

En todos estos casos, tanto la utilización de patrones y frameworks, como el uso de una metodología que pasa desde el diseño de procesos hasta el diseño de sistemas haciendo uso de IDEF0, BPMN y UML para un paso transparente del proceso al sistema, fueron factor clave para una implementación exitosa. Una demostración concreta de la importancia del paso de los procesos a modelos UML altamente etallados para la construcción de software, es que para la construcción del software de apoyo a la atención, concesión y pago de los beneficios del pilar solidario, se contrató a dos empresas de desarrollo independientes, a las que se les entregaron los mismos planos de diseño. Al término del plazo de menos de dos meses, ambas empresas habían desarrollado software similares y completamente funcionales al proceso modelado.

 

 

Gestionando la Homeostasis: El cuadro de mando

 

Tal como mencionamos anteriormente, la metodología de BE nos brinda herramientas para facilitar nuestra labor de diseño de negocios y generación de sistemas a apoyo al mismo, llevándonos incluso un poco más allá: El control de gestión o la homeostasis del sistema

Dado que los patrones y frameworks nos proveen tanto de las piezas funcionales (procesos) como de los mecanismos vinculantes (flujos e interacciones), nos permiten definir métricas de control, asociadas a reglas de negocio que quedan embebidas en el sistema y por lo tanto nos permiten saber la “salud” de este.

 

En virtud de esto, es que podemos guiar el diseño de indicadores basándonos en datos reales que sabemos que nuestro proceso / sistema será capaz de capturar en su ejecución, dado que tuvimos las herramientas para hacer un diseño integral. Esto no es menor, puesto que generalmente, cuando se realizan diseño de procesos sin esta mirada, cuando llega el momento de generar indicadores y sistemas de control, no se han previsto los mecanismos de registro de información necesario. Esto tiene grandes desventajas, puesto que para tener los datos que permiten el control, se opta por generar sistemas de autoreporte que, por un problema de agencia, carecen de confiabilidad y por ende no pueden ser utilizados como mecanismos de control efectivo. En el caso del diseño integral que propone la BE, es posible definir los puntos de información de necesarios y generar el máximo de automatización posible en el ingreso de información (incorporando las lógicas de negocio) y solucionando el problema de agencia, permitiendo un control descentralizado y centralizado a la vez.

Así, en todos los casos anteriormente descritos, pudimos desarrollar sistemas de cuadro de mando que permitían saber el estado de los proyectos, el estado de propuestas y oportunidades de negocio, el estado de las instalaciones de red a nivel nacional, el estado de los proyectos de construcción de estaciones de servicio, el estado de proyectos de estudios de mercado, el estado de las solicitudes del pilar solidario (por ubicación geográfica, sucursal, sexo, canal, etc.), los tiempos de atención y muchos más, que facilitaron el mejoramiento de los modelos implementados y la toma de decisiones estratégicas de negocio.

 

 

El factor humano: Gestionando lo impredecible

 

Finalmente, es imposible no reflexionar acerca de algo que me ha perseguido en cada implementación y para lo que aun no tengo una respuesta razonable: Las Personas.

Como alguien cuyos orígenes académicos están ligados al comportamiento organizacional, el tema de las personas siempre fue algo que tenía claro iba a ser un tema cada vez que quisiera implementar alguno de los tan bien diseñados procesos y sistemas de apoyo. Es así como efectivamente pude comprobar, que el diseño adecuado de un plan de gestión del cambio, así como un diseño de la gestión de RRHH sintonizado con el diseño de procesos, se transformaba en algo crucial para el éxito de una buena implementación.

 

De este modo, en implementaciones como la Ruta 5D MINSAL, el Pilar Solidario y las empresas de servicios profesionales, fue otro punto clave, el diseño e implementación de un plan de gestión del cambio que se hiciera cargo de las expectativas, los miedos y aprensiones de las personas, así como del entrenamiento y formación necesaria para abordar los nuevos desafíos que se imponían. En algunos casos, la falta de este plan obligó a generarlo de forma posterior para generar el impacto deseado, ya que la falta del mismo, si bien permitió implementar de manera parcial los procesos (dado que había partes automatizadas y se generaron los lineamientos directivos necesarios), éstos no eran ejecutados de forma integrada y precisa, generando ineficiencias o boicots inconscientes. De este modo, el plan de gestión del cambio debe ser diseñado en virtud de llevar de manera progresiva a la organización a un nuevo nivel de madurez de procesos, de modo que la explicitación de procesos les permita no solo alcanzar un nivel 2, sino que progresivamente de 3 a 5.

 

Sin embargo, la necesidad de diseñar un plan de gestión del cambio que incluya sensibilización, difusión y entrenamiento, nos lleva a la necesidad de hacer un diseño de Recursos Humanos que tome en cuenta los procesos diseñados y sea capaz de implementar un modelo de competencias adecuado a esos procesos en particular, que aseguren que el recurso humano que lo opera está en condiciones optimas de calificación, entrenamiento y satisfacción. Así, un modelo de competencias derivado del modelo de procesos, con métricas asociadas al desempeño de los mismos, evaluaciones de desempeño ad hoc, gestión de incentivos en torno a lo anterior, reclutamiento y selección basado en competencias, permite una implementación integral del modelo de procesos diseñado.

 

Queda entonces pendiente el diseño de un patrón de diseño de gestión de recursos humanos, un diccionario de competencias para patrones básicos como gestión de proyectos y atención de clientes y un patrón de diseño de estrategias de gestión del cambio basada en el modelo de madurez de procesos. La invitación está abierta.

MODELAMIENTO DE PROCESOS DE NEGOCIOS CON BPMN-01

Una encuesta reciente realizada por la Queenland University of Technology entrega antecedentes interesantes respecto al uso de BPMN en empresas de diversos tipos en varios países del mundo y, en particular, Chile.

 

BPMN (Business Process Modeling Notation) es un estándar que está siendo impulsado y perfeccionado por el OMG (Object Management Group), los mismos que están detrás de UML, BPEL y otros estándares.

 

La encuesta fue realizada durante cuatro meses de 2007 y fue distribuido a través de diversos canales, tales como ABPMP, BPTrends, BPM-Roundtable.com, BPM-Netzwerk, Tibco Community, Eclipse Newsgroup y otros. En total se recibieron 590 respuestas de más de treinta países. En la figura siguiente se muestra la distribución de respuestas por país y por continente.

 

uso de BPMN en empresas por origen

Hacemos notar la relativa importancia de Chile en las respuestas con un 2,7% del total y más usuarios respondiendo que países como India, Inglaterra y otros países europeos, Brasil y varios otros. Esto señalaría una relativamente alta penetración de BPMN en el país, lo cual también apuntaría a una creciente sofisticación en el diseño de procesos de negocios en nuestro medio. Esto podría estar explicado, en alguna medida, por el MBE (Master in Business Engineering) del Departamento de Ingeniería Industrial de la Universidad de Chile, que desde 2003 ha educado cientos de profesionales en el diseño de negocios y sus procesos, habiendo adoptado hace dos años BPMN como estándar de modelamiento.

 

Tanto profesionales de negocios (con un 51%) como de TI (con un 49%) son usuarios del referido lenguaje de modelamiento.

 

En cuanto al tipo de uso, 36% usan sólo los elementos más básicos de la notación, 37% usan una parte importante de las capacidades de la misma y un 27% usa todas las funcionalidades.

En relación a las herramientas utilizadas, en el siguiente cuadro se muestra la proporción de uso de diferentes opciones:

 

uso de BPMN en empresas

Las funcionalidades de las herramientas más usadas, tal como se muestra en el cuadro anterior, son el repositorio de modelos, el browser de modelos y otros que permiten facilitar la navegación en un conjunto complejo de modelos.

 

Los usuarios están satisfechos con el lenguaje, ya que se desempeña bien en proyectos de rediseño de procesos, tiene una buena facilidad de uso y el soporte de muchas herramientas. Sin embargo, se observan necesidades de mejora en varios aspectos, tales como el soporte de reglas de negocios, la posibilidad de modelamiento organizacional y la necesidad de simplificar diversos símbolos para gateways, conectores, groups y eventos.

 

Sería interesante conocer casos de usuarios de BPMN en Chile, más allá de las del MBE, para intercambiar experiencias respecto al uso del lenguaje y construir una base de conocimiento que permita promover su uso y que los nuevos usuarios del mismo se beneficien de tal experiencia.

 

Desde ya, este Blog queda abierto para los que quieran comunicar cualquier información de este tipo.

ARQUITECTURA EMPRESARIAL: LA ÚLTIMA FRONTERA DE LA INNOVACIÓN EN LOS NEGOCIOS

 

En la idea de innovar en los negocios con diseños de sus procesos que aseguren un desempeño alineado con los objetivos estratégicos de una empresa, hay una larga historia de propuestas al respecto. Primero fue la Calidad Total que se centró en el diseño de procesos aislados, con un enfoque continuo de medición, análisis y corrección gradual para llegar a un desempeño esperado. Después vino Lean Manufacturing, el cual privilegia el diseño de procesos productivos para eliminar el desperdicio. A continuación apareció la Reingeniería de Procesos de Negocios, que propugnaba, a diferencia de Calidad Total, un diseño integral con un cambio radical en los procesos de una empresa para generar mejoras fundamentales en su desempeño, pero que nunca proveyó la metodología para cumplir este objetivo y se convirtió en una disculpa para reducir  personal. Enseguida vino Six Sigma, un perfeccionamiento de Calidad Total, que mejoró los métodos de análisis de ésta, pero que siguió atacando problemas aislados dentro de una empresa. Luego llegó el BPM (Business Process Management), la reencarnación de la Reingeniería, que sí intentó proveer fundamentos conceptuales y metodológicos para diseñar los procesos de una empresa, pero sin una relación clara con el diseño de las aplicaciones TI de apoyo a los procesos y la estructura organizacional.

Como consecuencia natural de la evolución anterior, resumida en forma breve y simplificada en el párrafo precedente, se llegó a la necesidad de tener bases conceptuales sólidas para el diseño integral de un negocio, incluyendo su estrategia, modelo de negocio, arquitectura de procesos, estructura organizacional y arquitectura TI. Esta síntesis, que implica un enfoque sistémico de diseño de las empresas, es la que intenta proveer la Arquitectura Empresarial. Esta arquitectura, al igual que la arquitectura en obras civiles, intenta entregar una visión que enfatiza la “forma” que adoptará un diseño, la función de cada uno de sus elementos constituyentes y las interrelaciones que los ligan, sin entrar en los detalles de cómo se ejecutará tal diseño. Una maqueta, física o computacional, de un edificio, un puente, un auto o una ciudad es una materialización de la misma idea. La materialización de una Arquitectura Empresarial toma, habitualmente, la forma de un modelo gráfico que representa componentes y relaciones. Aquí conviene aclarar que hay propuestas de arquitectura que enfatizan los componentes TI, pero nuestro planteamiento es que deben predominar los procesos y la estructura organizacional, siendo los componentes TI una consecuencia de éstos.

Hay muchas empresas en el mundo que están enfrentando el desafío de diseñar sus Arquitecturas Empresariales, con casos famosos como los de Boeing, HP y FedEx. También el gobierno de los  EEUU está realizando un gran esfuerzo para definir su Arquitectura Empresarial por medio de la FEA (Federal Enterprise Architecture).

Nosotros ponemos el diseño de la Arquitectura Empresarial dentro del contexto de la Ingeniería de Negocios, como una manera de generar un diseño sistémico de una empresa para darle un marco de referencia al diseño detallado de todos sus elementos. Una primera propuesta de cómo proponemos se lleve a cabo el diseño de la arquitectura se entrega en la tercera parte del libro Ingeniería de Negocios: Diseño Integrado de Negocios, Procesos  y Aplicaciones TI,  el cual estamos publicando en este blog. Por supuesto, esta tercera parte, que estamos ahora incorporando, se funda en todo el aparato teórico conceptual que se ha desarrollado en las partes previas. Las ideas de este documento se están aplicando en una serie de casos prácticos que se publicarán, en al medida que no sean reservados, en el futuro en este mismo blog, como tesis del MBE.