La visión tradicional¹ de una arquitectura de negocio en una organización (todas las organizaciones tienen una, conscientemente o no, diseñada o no) está dada por elementos como los procesos, las personas, las funciones requeridas para apoyar los procesos, la información, entre otros. Sin embargo, ¿Me permite saber cómo esta apoya a las diferentes áreas de la organización o a la estrategia planteada? ¿Cómo visualizo a través de los procesos las competencias clave que me distinguen de los demás competidores? ¿Cómo hago que las soluciones tecnológicas desarrolladas se ajusten lo más posible a la estrategia y en una base continua, dado lo vertiginoso del cambio en el ambiente actual? ¿Cómo puedo lograr una orientación a los servicios desde la construcción en el negocio? Para responder estas preguntas volveremos la vista al Modelado de Capacidades (Capability Modeling). En este artículo veremos los problemas que presenta ver a la arquitectura de negocio como un grupo de procesos relacionados, mencionaremos los diferentes componentes de un Modelo de Capacidades y así como algunas ventajas de su uso.

De las cadenas de valor a las redes de valor

Tradicionalmente en las cadenas de suplidores encontramos tres actores principales: el comprador, el suplidor y el proveedor de logística. Por lo general se presta particular atención al comprador dado que es el que crea (el Justo a Tiempo\Kanban de Lean Manufacturing) la demanda y mueve el engranaje de la producción hasta los suplidores.

Recientemente ha habido una discusión importante sobre la evolución de las cadenas de suplidores a redes de valor. Estas redes agrupan actores que colaboran para entregar el mayor valor posible al consumidor y donde cada actor es responsable del éxito o falla de la red. Esta definición trae consigo una redefinición de la organización, la que ahora empieza con el consumidor y termina con el suplidor. El concepto implica una dependencia mutua entre los actores, basada en una responsabilidad compartida en la acumulación de competencias clave y extraer las mejores habilidades de cada participante².

En línea con este pensamiento están Frits K. Pil y Matthias Holweg³ quienes nos dicen que hasta ahora la creación de valor ha sido algo lineal. La sola mención de “cadena de valor” trae a la mente una secuencia de actividades que incrementalmente agregan valor. Dada la dinámica de los tiempos actuales es necesario tener una visión multidireccional de la creación de valor. Aunque la solución de los autores está basada en la creación de una cuadrícula (grid) me gusta más la idea de ver estas interacciones como una red. De todas formas lo cierto es que en el mundo de negocios de hoy las empresas van más allá de sus límites buscando nuevas formas de colaborar con socios de negocio para satisfacer a sus clientes.

Arquitectura de negocio

Estos elementos nos hacen cuestionarnos la forma en la que vemos a las organizaciones. Este cuestionamiento va desde la manera como interactuamos con nuestros socios hasta los elementos que utilizamos para modelar la organización, particularmente a través de la Arquitectura de Negocios. Es necesario reflejar en los modelos la interacción con los socios y otros actores del ambiente a través de elementos más estables que los procesos y a la vez haciendo un énfasis en nuestras competencias.

Para empezar definamos qué es una Arquitectura de Negocios. El OpenGroup⁴; en su framework TOGAF⁵ de Arquitectura Empresarial define cuatro dominios arquitectónicos, uno de ellos el de negocio. En específico la Fase B de la Metodología de Desarrollo de Arquitecturas (ADM) se preocupa por el desarrollo de una Arquitectura de Negocio que contiene la estrategia, elementos de gobernabilidad y los procesos de negocio claves de la organización⁶. En TOGAF el modelado de negocio se realiza a través de varias técnicas y herramientas de modelado. A este respecto se utilizan herramientas como los diagramas de actividad de UML (o Diagramas de Procesos de Negocio y más recientemente expresados por medio de BPMN), diagramas de casos de uso, diagramas de clases, entre otros.

Como vemos en este enfoque la arquitectura de negocios representa la forma en la que opera una organización, documenta el cómo, no el qué. El lado malo de esto es que el frecuente cambio en los procesos tiene un impacto en los demás dominios arquitectónicos y es por esto que se deben desarrollar proyectos, por lo general largos y costosos, para mantener esta sincronía entre los dominios, entre TI y el negocio. Si queremos ser fieles al tema central de SOA, facilitar el cambio a través la agilidad, tal vez este no sea el camino correcto...

Como dije esta es la forma que tradicionalmente se han tomado las arquitecturas de negocio, sin embargo el modelado de capacidades provee una visión diferente. Se concentra en elementos más estables, menos cambiantes, lo que facilita este alineamiento que mencionaba y especialmente la adopción SOA ha probado ser particularmente eficiente en la resolución de problemas que no necesariamente eran enfrentados con otros enfoques.

Modelado de capacidades

El asidero teórico del modelado de capacidades yace en “The Core Competence of the Corporation”, aparecido en el Harvard Business Review⁷, donde Prahalad y Hamel nos pusieron a pensar sobre la visión que teníamos de las organizaciones en los años 90. En su escrito nos dijeron que la “fuente real de la ventaja (competitiva) se encuentra en la habilidad de la administración para consolidar las tecnologías corporativas y las habilidades de producción en competencias que empoderen a los negocios individuales en la adopción de rápidas oportunidades de negocio”. Sin el desarrollo de competencias clave (core) una corporación es solamente una colección de negocios discretos, independientes. Las competencias clave sirven como la goma que une a las diferentes oportunidades de negocio en un portafolio coherente. En general podemos decir que las competencias del negocio son el qué, sin importar cómo son logradas.

El modelado de capacidades es una técnica emergente para modelar y analizar el negocio en términos de sus competencias. En un modelo de este tipo encontramos a las capacidades (su propósito, los niveles de expectativa de los servicios, clientes y niveles de granularidad), las relaciones entre estas y los límites de contexto, dentro de los cuales se definen las capacidades. A continuación revisaremos cada uno los elementos de un modelo de capacidades.

Capacidad

Una capacidad de negocio modela lo que una función del negocio hace y no cómo lo hace (terreno del proceso). Describe su comportamiento externo (resultados y el nivel de desempeño esperado) para producir valor a los clientes. Dentro de una capacidad encontramos procesos, personas, sistemas, información y otros recursos interactuando para hacer posible el propósito específico de la capacidad. Ejemplos de estas son el “Pago a los Empleados”, el “Envío de Productos” y el “Procesamiento de Cheques”. Las capacidades tienen dueños y también clientes quienes esperan cierto nivel de desempeño. En definitiva, son los building blocks del negocio.

La vista de caja negra es una característica importante de las capacidades. En vez de describir cómo ayuda a la organización a alcanzar su misión, una capacidad esconde los detalles de implementación, exponiendo una interfaz a través de la cual interactua con el resto de capacidades en el ecosistema. Aquí está la similitud con los servicios en una SOA y es por esto que las capacidades son frecuentemente vistas como servicios a nivel de negocio (dicho sea de paso esta característica también las convierte en una entrada directa al diseño de servicios en la SOA). La interfaz provee conectores que transmiten mensajes incluso con información sobre la semántica de la comunicación, es decir no son tan simples.

Además, dado que se ven como proveedoras de servicio es factible medirlas a través de Acuerdos de Nivel de Servicio (SLA). La adopción del Monitoreo de Actividades de Negocio, el BAM que en algún momento mencionamos cuando hablamos de BPM, se facilita bajo este enfoque dado que tenemos indicadores reconocidos y estables a los cuales medir contra el desempeño esperado.

continua »

(1) http://www.opengroup.org/public/arch/p4/views/vus_bus.htm
(2) http://ebusiness.mit.edu/research/Bitran_SupplyChain.pdf
(3) http://sloanreview.mit.edu/smr/issue/2006/summer/14/
(4) http://www.opengroup.org/
(5) http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html
(6) http://en.wikipedia.org/wiki/TOGAF
(7) http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_detail.jhtml