En el MBE se han utilizado con éxito, en cientos de proyectos, los patrones de procesos, los cuales permiten acelerar los proyectos de diseño de procesos y asegurar la calidad de tales diseños. La experiencia acumulada, que se ha documentado en el libro “Ingeniería de Negocios” y en múltiples proyectos incluidos en este blog, ha permitido una generalización a nivel de abstracción más alto que los patrones de procesos. En múltiples casos se ha encontrado que el diseño necesario va más allá de un proceso particular y debe incluir la estructura de todos los procesos que requiere una empresa para funcionar o una parte importante de ellos. Esto corresponde  a la idea de una arquitectura de procesos, la cual es parte de una arquitectura empresarial. Si bien hay varias propuestas de cómo diseñar tal estructura, en el MBE hemos desarrollado un enfoque original que construye sobre los macroprocesos 1 a 4 y que tiene como característica distintiva no solo enumerar procesos, como lo hacen todas las otras propuestas, sino que enfrenta explícitamente el diseño de las relaciones entre los procesos que constituyen la arquitectura, lo cual provee una solución verdaderamente operacional y sistémica.

Lo anterior ha dado lugar a la definición de patrones de arquitectura, con el mismo propósito de los patrones de procesos. Esto es tener arquitecturas genéricas predefinidas, con macroprocesos y sus relaciones, que sirvan como guía normativa al desarrollar una arquitectura particular evitando empezar desde cero. Hay varios tipos de arquitectura que se pueden formalizar, pero nosotros nos hemos concentrado en una que hemos encontrado de gran utilidad en la práctica: Arquitectura de Procesos Compartidos. Esta arquitectura la hemos aplicado en varios proyectos, siendo el caso más importante el de hospitales, para el cual se hecho una especialización del patrón general. Este diseño nos ha permitido establecer los procesos que debiera tener un hospital para hacer posible un manejo optimizado, lo cual también ha llevado a establecer los procesos en los cuales un rediseño tendría un impacto más significativo. Tales procesos se han sometido a un diseño detallado, incluyendo apoyos computacionales, los cuales se encuentran en funcionamiento en hospitales públicos seleccionados, como se señaló en la entrada anterior a ésta en  este blog. Este trabajo, que es innovador a nivel internacional, nos ha permitido publicar dos documentos en el sitio http://www.bptrends.com.

(Ver documentos en

Enterprise and Process Architecture Patterns(Barros 26Julio-final)

App Process Ent Arch Patterns Hospitals (Barros 26Julia-final)  )

 y también enviar un paper a publicación en el European Journal of Operacional Research.

(Ver paper en documentos de trabajo CEGES

Application of Enterprise And Process Architecture Patterns In Hospitals )

Un estudio reciente de McKinsey, reporteado en El Mercurio del 16/12/09, muestra que la productividad de las organizaciones nacionales es deplorable y que existe un potencial de mejora importante de ésta si se mejoran las prácticas empresariales, el cual McKinsey estima en 25 puntos porcentuales, desde un nivel actual de 34, tomando la productividad de EEUU como 100. Esto fue también corroborado en un estudio realizado en el DII en 2004, el cual estableció que las prácticas de gestión en nuestras empresas eran de muy baja calidad (www.obarros.cl).

El Magíster en Ingeniería de Negocios (Master in Business Engineering: MBE) del Departamento de Ingeniería Industrial (DII) de la Universidad de Chile se impuso, desde sus inicios en 2003,  que sus alumnos hicieran, como parte de sus proyectos de grado, trabajos significativos de innovación en la gestión de empresas e instituciones privadas y públicas con el fin de contribuir al incremento de la productividad y, por lo tanto, ayudar al cierre de la brecha identificada en el punto anterior. Estos trabajos parten de los planes estratégicos de una organización, tratan de mejorar su modelo de negocio, desarrollan una arquitectura de procesos de negocios que permita llevar a la práctica tal modelo, diseñan en detalle los procesos requeridos por la arquitectura, diseñan y construyen las aplicaciones computacionales de apoyo a tales procesos, a lo menos a un nivel de piloto, e implementan todo lo anterior para mostrar resultados tangibles de mejora del negocio, los cuales siempre están ligados a incrementos de productividad.

 Leer todo el documento aquí [ Casos de Exito MBE ]

Este paper fue motivado por la columna “Punto de Vista”, publicada por Roger Burlton en BPTrends en Julio del 2009. Allí, el autor propone distintas perspectivas para el modelamiento de procesos –contexto, arquitectura, sus procesos y subprocesos- utilizando enfoques de modelamiento y herramientas diferentes para cada una de ellas. La propuesta de MBE concuerda con la existencia de estas perspectivas, que denomina niveles de diseño, pero utiliza un único enfoque y herramienta de modelamiento para integrar los niveles mencionados. Esto evita los serios problemas de consistencia y trazabilidad generados al pasar de una perspectiva a otra.

La experiencia de modelamiento formal de procesos en cientos de proyectos del MBE ha llevado a la identificación de tres niveles de detalle para la representación de procesos: la arquitectura, el diseño de sus procesos y, finalmente, las actividades más elementales que se coordinan para conformar los procesos del segundo nivel. Todos estos niveles pueden ser modelados usando BPMN.

Para lograr lo anterior se requieren diferentes, pero complementarios estilos de modelamiento: uno para representar la arquitectura y el diseño de sus procesos, que enfatice la estructura y el flujo de información; y otro estilo para representar el detalle de los procesos anteriores, que sea procedural y enfatice la secuencia de actividades y lógica de control. En este paper se muestra que estos estilos son totalmente compatibles, ya que el segundo tomará y detallará las representaciones del primero, manteniendo la consistencia y trazabilidad durante el modelamiento en todos los niveles. Más aún, la aplicabilidad de este enfoque es ejemplificada con el proyecto de hospitales públicos chilenos que se está desarrollando actualmente en el MBE.

La existencia de un enfoque integrador de los distintos niveles de diseño de procesos ha permitido modelar los patrones de arquitectura y de procesos desarrollados en este programa, a través de los cuales es posible generar rápidamente la estructura de procesos de cualquier empresa. La consistencia y trazabilidad de este enfoque permite plasmar la estrategia en una arquitectura de procesos, para luego diseñar tales procesos hasta el último detalle, incluyendo el apoyo computacional que los soportará. Es un enfoque totalmente sistémico. 

El paper completo publicado en BPTrends se encuentra en este link

El Panel estará compuesto por Paul van Doorne (Manager BPM, KPN Business Market), Grace Duffy (President, Management and Performance Systems) y Steven M. McCrystal (SVP, Managing Director, IS Transformation, Diageo Plc).

A continuación una breve descripción de los Temas principales y el enlace de la web de la conferecia para mayor información:

“There are lots of process improvement advocates in our organizations today espousing best practices to significantly or incrementally improve the performance of the work we do. Many of these practices, methodologies and techniques have a heritage such as industrial engineering, quality management, measurement, IT requirements and other precedents. Which is the best for you? Is it one of them such as six sigma? Is your organization enamoured with Toyota and Lean? Is BPM different from these? This panel will feature an examination of these questions and strive to find the similarities and differences among them. It will also aim to project the future of the approaches. Are they converging? What can we expect?

• The backdrop for analytic and design process approaches
• Why Lean?
• Why Six Sigma?
• Why BPM?
• Convergence or Divergence?

Web de la “Business Process Management Conference Europe 2009″

Leer más (Descargar pdf)

Esta idea de factorizar servicios comunes a varias líneas de negocios, centralizarlos, optimizarlos desde el punto de vista de procesos y  tecnología y, eventualmente, hasta externalizarlos es una idea muy potente dentro del diseño de Arquitectura Empresarial, pero requiere de una metodología apropiada para evaluar y diseñar bien. Este es el tema que se trata en detalle en la parte tercera del libro Ingeniería de Negocios ( link a doc) que estamos publicando en blog.obarros.cl. Todas estas ideas las estamos aplicando en un proyecto de desarrollo de una Arquitectura Empresarial para hospitales que tiene como propósito servir de marco de referencia para elaborar patrones de procesos en este dominio. Esto permitirá tener soluciones genéricas de procesos para hospitales que puedan reutilizarse en   proyectos de rediseño en ellos.

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. 

Ver Noticia en Boletín Informativo FCFM

Ver Galería de Fotos

“…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.