Reglas de Negocio – Business Rules

Desde hace, al menos veinte años, existen artículos referidos a las Reglas de Negocio que las describen desde una perspectiva del “negocio” o con un enfoque de “sistemas”. En este artículo pretendo mostrar como incorporarlas en un proyecto de implementación de procesos de negocios, para ello incluiré algunas definiciones comúnmente aceptadas a objeto de tener un mismo entendimiento, presentaré un método de recopilación y una lista de los usos posibles de éstas.

En primer lugar, tenemos que entender que las Reglas de Negocio siempre han estado presentes, lo que ocurre que se han denominado de distintas maneras y se han tratado de manera parcializada. Es así como las tenemos en:

• Parámetros, por ejemplo tasas de impuestos, porcentajes de descuentos, listas de valores posibles, etc.
• Procedimientos, flujos, rangos de autorización, instrucciones, manejo de excepciones, etc.
• Datos, características del dato, clasificaciones, elementos que indican como tratarlo, p. ej: activo fijo, producto para la venta, materia prima, etc.

Al no estar presente el concepto de Reglas de Negocios en un proyecto de implementación tradicional de un ERP  se genera una dispersión de la información correspondiente a las Reglas de Negocio, y una dilución de la responsabilidad de su mantenimiento y documentación.

La dispersión de la información se genera porque al no considerar el concepto en cuestión, las reglas se tratan en distintos objetos como ser: herramientas para la parametrización de un sistema, programas (codificación en duro – hardcore), estructuras de datos, reglamentos, manuales de procedimientos, conocimiento de los usuarios, entre otros. A su vez la dilución de las responsabilidades se genera por el proceso de generación; que nos es sistemático  en cuanto a la recopilación, identificación de los responsables y a la forma de documentar. En resumen, se mezclan responsabilidades propias del Negocio con las de Informática.

Por tanto, propongo que en un proyecto de implementación de procesos de negocio  se incluya una tarea con un método  sistemático para la recopilación y documentación de las Reglas de Negocio, tal que tanto las áreas del negocio, de auditoría e informática cuenten con una fuente única y válida para estos efectos.

En otras palabras a las dimensiones básicas de un proceso de negocio: Transacciones (Software), Organización (Estructura y Roles) y Procedimientos (Gobernabilidad) estaremos agregando la 4ta D, es decir, las Reglas de Negocio [1].

Definiciones
En general, todo el mundo sabe que es una “Regla de Negocios”, literalmente, es aquello que usamos para operar un negocio. Son las guías que determinan como se lleva el día-a-día de las operaciones. Sin reglas se estaría en una situación en la que cada decisión se resuelve en el momento, eligiendo alternativas caso a cado o ad-hoc, Y, este modo de operar es muy lento, costoso y puede generar resultados inconsistentes [2].

Para el término “Regla de Negocio” se tiene que para un especialista en procesos de negocio puede significar un conjunto de requerimientos asociados con los procesos, que están o no formalizados en una gramática o taxonomía  por algún tipo de mecanismo. Para el especialista en Base de Datos, puede ser un requerimiento específico que se satisface mediante la definición de alguna característica de los datos, que expresará en los valores posibles de un determinado campo [3]. Y, para la gente del negocio no son más que la “manera de hacer las cosas”.

Una Regla de Negocio define o limita un aspecto del negocio con el objeto de establecer una estructura o un grado de influencia que condiciona el comportamiento de los actores del negocio. A menudo las Reglas de Negocio están focalizadas en el control, en la forma de realizar los cálculos, otras permiten establecer las políticas, y así se tienen en cualquier actividad del negocio, que requiera que la gente actúe de una forma pre-establecida [4].

Qué NO son las Reglas de Negocio
Las Reglas de Negocio no son software. Las Reglas de Negocio pueden ser implementadas en el software, pero esto a menudo representa sólo una parcialidad de sus definiciones, ya que partes importantes quedan expresadas en los Procedimientos Manuales. También existe la posibilidad, poco común por ahora, de habilitarlas mediante una Máquina de Reglas o un Sistema Experto. De modo que se debe entender que efectivamente las Reglas del Negocio, como su nombre lo indica, son parte del negocio y, no de alguna plataforma particular de hardware / software que pudiera soportarlas.

Las Reglas de Negocio de no son “Proceso”, de ninguna forma. Roger Burlton indica que: “Se debe separar el flujo del conocimiento”. Dónde las Reglas de Negocio representan la parte conocimiento que guía al flujo, de aquí  su nombre de Regla de Negocio [2].

Recopilación
Dado que las Reglas del Negocio son conocimiento, su formulación –la acción de explicitarlas por escrito- es un proceso de recopilación, entendiendo que están en la cabeza de los empleados, a diferencia del flujo que habitualmente se documenta en un manual de procedimiento o en un workflow.

Podemos, entonces, decir que las Reglas de Negocio corresponden a un conocimiento tácito, por consiguiente el proceso de recopilación consistirá en convertir este conocimiento que tienen las personas en conocimiento explícito [5].

Es necesario tener presente que el poseer el conocimiento de determinadas Reglas de Negocio es poder. Y, que por tanto su recopilación puede tener complicaciones.

Para proceder a la recopilación de las Reglas de negocios me parece un buen punto de partida tener en consideración los principios denominados  “The business rule approach” desarrollados por Ronald Ross [5], estos son:

• Deben ser explícitas y escritas.
• Expresadas en términos sencillos.
• Existen independientemente de los procedimientos y workflows (ej.: modelos).
• Se construyen a partir de hechos, éstos se definen a partir de conceptos, los que a su vez se representan por medio de términos (ej.: glosarios).
• Guían o influencian el comportamiento conforme a una forma pre-establecida.
• Son motivadas por factores de negocios identificables e importantes.
• Son accesibles a las partes autorizadas (ej.: tienen dueños).
• Están en una fuente única (ej.: repositorio de reglas).
• Son especificadas por las personas que tienen directa relación con ellas y que poseen el conocimiento relevante (ej.: los usuarios claves).
• Son gestionadas –administradas- (ej.: son parte de la Gobernabilidad de los Procesos de Negocios)

Una manera simple para recopilarlas es utilizar alguna herramienta para modelar, p. ej.: modelos EPC, al cual se le define un objeto denominado Regla de Negocio el que se enlaza con:

•  Una función, esta ligazón permite relacionarla con Roles, secuencias de eventos y facilita su inclusión en la generación de procedimientos a partir de los EPC.

Regla de Negocio conectada a una Función en diagrama EPC

 
• A un documento –texto, planilla, etc.- donde se incluye la descripción detallada, para este efecto recomiendo utilizar la formulación Rule Speak [6] , que la pueden solicitar en español en el enlace indicado. Si bien, es cierto que algunos expertos encuentran compleja la utilización de Rule Speak a mi parece que simplifican el proceso de documentación, dado que las definiciones se especifican en español, con un expresiones sin ambigüedades.

Ejemplo de especificación de una Regla de Negocios usando Rule Speak.

El proceso de recopilación puede ser apoyado técnicamente por Business Process Expert (BPX) [7] pero, la responsabilidad sobre el contenido y mantenimiento de la Regla de Negocio es del Dueño de Proceso de Negocio, quien puede obtener información detallada de las mismas por medio de los Usuarios Claves –Key Users.

La etapa del proyecto de implementación de procesos de negocios  en la cual me parece adecuado realizar la recopilación de las Reglas de Negocios es la de Diseño o Business Blueprint.

Usos
Entre otros, el disponer de las Reglas de Negocio en un repositorio y formalmente descritas –por ejemplo en ARIS, donde pueden ser un objeto  conectado a una función en un modelo EPC y a documentos -por ejemplo en SAP Solution Manager, con sus respectivas especificaciones– se logran los resultados siguientes:

• Visibilidad y transparencia de las definiciones de las Reglas de Negocio, tanto para la gente del negocio como para la de informática.
• Gobernabilidad para las Reglas de Negocio: procedimiento para su creación y mantenimiento sistemático con responsable único y del área de negocios.
• Mayor agilidad para abordar los cambios en el negocio.
• Facilitan las auditorías – recorridos- de los procesos de negocios.
• Lista de Reglas de Negocio por: Proceso, Responsable, Rol, Funciones.
• Clasificación por uso: Parametrización, Datos o Procedimientos.
• Documentación disponible centralizadamente.

Referencias
[1] http://msaffirio.wordpress.com/2008/07/26/dimensiones-de-un-proceso-de-negocio-%e2%80%93-business-process-dimension/
[2] http://www.brcommunity.com/b005.php
[3] http://www.dulcian.com/BRIM%20Documents/What%20Are%20Business%20Rules.htm
[4] http://www.agilemodeling.com/artifacts/businessRule.htm
[5] http://msaffirio.wordpress.com/2007/09/23/el-activo-conocimiento-de-informatica-knowledge-asset/
 [6] http://www.rulespeak.com/es/downloads.php

Localizaciones

Al implementar un ERP en una empresa que opera en varios países debido a las características y legislaciones de cada país implica la necesidad de incluir funciones específicas en los procesos de negocios para satisfacerlas. Por otra parte, en empresa con operaciones multinacionales se tiene que cada operación tiene usos y modos de trabajo que también demandan incorporar funciones adicionales a los procesos de negocios. Por consiguiente, al conjunto de funciones específicas que tanto la legislación, características del país, usos y modos de trabajo propios de una organización en dicho país, implican la generación de funciones adicionales o modificaciones en los procesos de negocios, a estas las denominaremos Localizaciones.

Por otra parte la RAE define Localización como:

1. 1.      f. Acción y efecto de localizar.

Como se puede observar la definición de la RAE no nos sirve para  establecer una definición técnica, ya que el origen de la palabra para nuestros efectos es el inglés: Localization y en este caso su traducción es:

Es el proceso de adaptar un producto a las peculiaridades del lenguaje de una comunidad-lingüística, terminológica, cultural o legal [1]

Luego, para mayor precisión podemos decir que Localización es el conjunto de funciones específicas para la operación de un proceso de negocios en una empresa, filial, subsidiara, etc. en un determinado país. Así tendremos, por ejemplo, las localizaciones para Chile, Argentina y Brasil para los procesos de negocios de una empresa que opera en estos tres países.

Por tanto, cuando planificamos generar procesos estandarizados para una empresa que opera en varios países,  tendremos varios conjuntos de funciones propias para la operación en cada uno de los países, más un conjunto de funciones comunes para todos ellos. La figura siguiente ilustra esta situación:

Proceso Estándar

Entenderemos por proceso estándar aquel que, de alguna manera, es aceptado por una organización para ser implementado y utilizado de acuerdo a sus criterios de diseño, roles, procedimientos, reglas de negocios, controles, etc. Y, que su ámbito de utilización será todo el conjunto de unidades organizativas que la conforman.

Los beneficios de un Proceso Estándar son: la disminución de los costos tanto de mantenimiento como de capacitación, ya que el mismo se distribuye por la cantidad de veces que está habilitado. Por la capacidad de mantener el conocimiento, ya que personas en las distintas filiales están entrenadas para operar con un determinado proceso. Y, también permite disponer de implementaciones de calidad superior ya que su instalación en varios lugares permite un mejor testing.

Así, por ejemplo, una empresa con filiales en Argentina, Chile, Colombia y Brasil decide que su modelo estándar para la Cadena de Suministro será SCOR [2]. Esto significa que en los cuatros países se implementará este modelo más las Localizaciones pertinentes a cada uno de ellos.

Template

El Template de una empresa es constituido por todos los Procesos Estándares, que se definen para satisfacer las necesidades de la empresa. Normalmente el conjunto de procesos estándares se define en el Mapa de Procesos de Negocios [3].

Para generar el Template es necesario establecer previamente una Arquitectura que incluya tanto los elementos estratégicos, que establecen las líneas generales de diseño, como los elementos tecnológicos, que modulan el cómo se implementarán los modelos estándares del template.

La generación de un Template tiene por propósito generar procesos optimizados  y alineados estratégicamente para toda la operación de la empresa, y no para un área en particular. Esto genera discusiones con la gerencias, ya que estas han estado por años optimizando su área, generando los denominados “silos”, que es uno de los elementos que el Template tiene que eliminar.

Ejemplo: Para una empresa que cuenta con tecnología SAP, la generación del template corresponde al Proyecto de Implementación, y la habilitación en las distintas unidades –países son los Roll-outs [4].

Tipos de Localizaciones

Una clasificación posible se basa en identificar el origen de la Localización, así tiene la LLL que significa:

L = Legal, Localización motivada por requerimientos legales o de regulaciones, por ejemplo: Impuestos, libros contables, facturas, nómina (cálculo de las remuneraciones), Sarbanes – Oxley, etc.

L = Lenguaje, para el caso de Sudamérica tenemos necesidad de contar con interfaces (pantallas, y documentación, al menos, en español y portugués.

L = Local, se refiere a características especificas de un lugar, que pueden corresponder a condiciones físicas (espacios, tipos de bodegas, patios, etc.), de disponibilidad de ciertas tecnologías (comunicaciones, WiFi, maquinaria, etc.) y, operación.

Efectos de las Localizaciones

Desde el punto de vista técnico cada Localización corresponde a una alteración en el Template, sea por cambios en la parametrización o por cambios o adiciones en el software (en el caso SAP implica generar programas Z), dado que estos cambios deben reflejarse en el modelo del proceso también se generaran modificaciones en los modelos (VAC, EPC, BPMN, etc.). Y, consecuencialmente cambios en los procedimientos.

Otro efecto, es en relación a los roles que participan en el proceso. Así se tiene que una localización afectará las funciones que realiza un rol determinado, con la consiguiente necesidad de actualizar la documentación del modelo.

Para mantener la coherencia del modelo las localizaciones deberán tratarse formalmente y un medio adecuado para tratarlas es utilizar el concepto de Variantes.

El siguiente gráfico muestra esta idea:

Y, el otro efecto importante es en los costos, ya que cada Localización implicará modificaciones a los modelos, desarrollos de software, nuevas parametrizaciones, cambios en los roles, testing, etc. Que deberán hacerlas los especialistas y, estas demandaran tiempo para su ejecución y presupuesto para contratarlas. En otras, palabras las Localizaciones llevan asociados costos significativos.

Criterios para Validar Localizaciones.

Según mi parecer las localizaciones del Tipo Legal y del tipo Lenguaje son necesario realizarlas, las primeras por respeto a la ley, y las segundas porque se necesita que el usuario común esté en condiciones de operar el proceso.

Para las localizaciones del tipo Local surge la necesidad de hacer una evaluación exhaustiva, ya que el primer punto a dilucidar es si ésta corresponde a una necesidad real o se trata de una modificación para mantener el estado actual de las cosas. Este último punto es muy común, ya que obedece a la necesidad de muchos usuarios de permanecer en su zona de confort, y se manifiesta con argumentos “técnicos”  o razones genéricas como: “somos muy diferentes” o “es una optimización para nuestra operación”, y un largo etcétera.

Debe tenerse en consideración que mediante la generación de este de localizaciones del tipo Local se puede romper el estándar del proceso de negocio imperceptiblemente, con los consiguientes daños para la empresa. En otras palabras es necesario estar advertido que mediante la habilitación de Localizaciones del tipo Local se puede llegar nuevamente a tener implementados “silos” en vez de los proceso estándares,.

Una vez establecida que la necesidad de la localización Local es real, es necesario evaluar su ámbito de aplicación; es decir, si se aplicará en una o más partes. Después se continua con la evaluación y especificación estándar para todo nuevo requerimiento funcional.

Otra forma de evaluar el efecto de las Localizaciones es medir el Grado de Adherencia, es decir medir del conjunto de las procesos implementados cual es el porcentaje de ellos que se ocupa tal cual se implemento en el Template y cuál es el porcentaje de Localizaciones correspondientes al país en cuestión. Por lo general se espera que el Grado de Adherencia sea del orden del 80%.

Referencias

[1] http://forum.wordreference.com/showthread.php?t=210813

[2] SCOR  [Supply Chain Operations Reference]

[3] http://msaffirio.wordpress.com/2008/05/22/mapa-de-negocios/

[4] http://help.sap.com/saphelp_46c/helpdata/en/eb/9424f6bb6411d29c820000e8a51c6e/frameset.htm

Modelos de Referencia – Reference Models

Este artículo es una introducción a los Modelos de Referencia, con el propósito de explicar su alcance y las razones de uso.
Para este efecto se muestran algunos modelos como TOGAF, utilizado para diseñar y especificar arquitecturas empresariales; COBIT, modelo de gobernabilidad para áreas de informática y SCOR, modelo para la cadena de suministro.
Y, a modo de ejemplo de aplicación se presentan modelos actualmente en uso en Embotelladora Andina S.A.: arquitectura empresarial y proyecto de implementación de proceso de negocios.

Definiciones Previas
A objeto de mejor entender los Modelos de Referencia y evitar confusiones, a continuación incluyo algunas definiciones que me parecen fundamentales.

Sistema

• “El Todo y las Partes”. u Hesíodo (siglo VIII a.C.) y Platón (siglo IV a.C.)
• “Sistema es una colección organizada de hombres, máquinas y métodos necesaria para cumplir un objetivo específico”.  u Estándar X3.12-1970 (ANSI), Estándar 2382/V, VI (ISO) Vocabulary for Information Processing .
• “Sistema es un todo integrado, aunque compuesto de estructuras diversas, interactuantes y especializadas. Cualquier sistema tiene un número de objetivos, y los pesos asignados a cada uno de ellos puede variar ampliamente de un sistema a otro. Un sistema ejecuta una función imposible de realizar por una cualquiera de las partes individuales. La complejidad de la combinación está implícita“. u IEEE Standard Dictionary of Electrical and Electronic Terms.

Proceso de Negocios

• “Un Proceso de Negocios es un sistema estructurado, con un conjunto específico de actividades diseñadas para producir una salida especifica ya sea para un cliente o un mercado particular.  Implica un énfasis fuerte en cómo el trabajo se hace dentro de una organización” u Davenport 1993.

Modelo

• Representación gráfica, matemática (simbólica) o verbal; o versión simplificada de un concepto, fenómeno, relación, estructura, sistema o algún aspecto del mundo real. [1]
• Los Procesos se representan –especifican– por medio de Modelos.
• Un modelo es una representación aproximada de una realidad.
• La disciplina que originalmente comenzó a estudiarlos es la Física y después la Teoría de Sistemas.
• Ítem original a partir del cual se hacen copias o duplicados. [1]

Framework
Según Wikipedia en español:

• La palabra inglesa framework define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular, que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.

Y, en la versión en inglés:
Framework se refiere:

• Software framework, es un conjunto de bibliotecas –librerías- o clases reusables para un sistema de software (o subsistema).

• Application framework, es un software framework usado para implementar la estructura estándar de una aplicación para un sistema operativo específico.
• Process framework algo como ITIL o Enhanced Telecom Operations Map.

Modelo de Referencia

Un Modelo de Referencia en ingeniería de sistemas y en ingeniería de software es un modelo de algo que contiene un objetivo o idea básica de algo, y que se puede establecer como una referencia para múltiples propósitos. [2]

Un Modelo de Referencia es un marco de referencia abstracto para entender el significado de las relaciones entre entidades de algún ambiente. Permite el desarrollo de referencias específicas o de arquitecturas por medio del uso de estándares o especificaciones que soportan el ambiente en cuestión. Un Modelo de Referencia consiste de un conjunto mínimo de conceptos, axiomas y relaciones propios de un dominio particular de problema, y es independiente de estándares específicos, tecnologías, implementaciones, o de cualquier otro detalle concreto. [3]

Características

Abstracto: Un modelo de referencia es abstracto. Los elementos descritos por él  no son las cosas en sí mismas, sino que son representaciones de ellas. Por consiguiente, cuando se describe la arquitectura de una casa –plano-, las paredes tienen dimensiones y materiales, pero el concepto pared es parte del modelo de referencia. De este modo para construir las paredes de una casa es necesario entender los planos, y esto significa entender el modelo de referencia en cuestión. [4]

Entidades y Relaciones: Un modelo de referencia contiene tanto entidades (las cosas que existen) como relaciones (como las cosas interactúan entre sí). La lista de entidades no es suficiente para describir completamente un modelo de relación.

Inserto en el ambiente: Un modelo de referencia no pretende describir “todas las cosas”. Se usa para clarificar “las cosas en un ambiente” o espacio de un determinado problema o tópico. Para que el modelo de referencia sea efectivamente útil debe incluir una descripción precisa del problema que pretende resolver, y de las preocupaciones de quienes necesitan resolver dicho problema.

Tecnológicamente agnóstico: Un modelo de referencia no es útil si incluye consideraciones tecnológicas o de alguna plataforma computacional en particular. Un modelo de referencia es un mecanismo para entender un determinado problema, no es su objetivo proveer la solución  propiamente tal. Tiene que ser independiente de la solución, de modo de entregar valor a quien usa el modelo.

Razones de Uso

La utilización de los modelos de referencia está motivada por distintas necesidades, como ser:

Estandarización: Por medio de la creación de estándares, el trabajo de los ingenieros y de los desarrolladores que tienen la tarea de crear objetos, que tengan un comportamiento adecuado al requerimiento, se facilita mediante el uso de una base común de conocimiento y de reglas sobre el “cómo hacer”, este es el estándar. En particular, la implementación de proyectos, el desarrollo de software, el mantenimiento de las aplicaciones, etc. Esta labor se facilita mucho si sus respectivas definiciones están soportadas por modelos de referencia.

Educación: Por medio de los modelos de referencia los líderes de un determinado proyecto, sea de implementación, mejoramiento o desarrollo de software pueden organizarlo por partes o fases, descomponiendo el problema en partes más simples que puedan ser realizadas por distintos equipos profesionales. Esto lleva a que un grupo de profesionales aprenda a trabajar conforme a una regla general, y esto redunda en una mayor eficiencia a la hora de integrar los distintos componentes del proyecto como asimismo en disponer de la capacidad de realizar partes de un proyecto en paralelo. Un ejemplo es el uso de modelos EPC para describir un determinado proceso de negocios.

Comunicaciones interpersonales: Un Modelo de Referencia descompone un problema en entidades, o en “cosas que existen por si mismas”. Esto es a menudo un reconocimiento declarado de conceptos que ya mucha gente comparte, pero que son expresados de una manera explícita. Un Modelo de Referencia es útil cuando permite definir cuando los conceptos difieren y/o se relacionan. Estas cualidades del Modelo de Relación facilitan la comunicación entre las personas.

Roles y responsabilidades: Por medio de la creación de un modelo de entidades con sus correspondientes relaciones, una organización puede asignar personas específicas o equipos, dándoles la responsabilidad para resolver los problemas concernientes a un determinado conjunto de entidades. Por ejemplo, si un Modelo de Referencia describe un conjunto de indicadores para medir el negocio (KPI), cada uno de ellos pude ser asignado al ejecutivo que corresponda.

Comparación: Un Modelo de Referencia sirve para comparar cosas diferentes. Por medio de la descomposición del problema en conceptos básicos, puede utilizarse para examinar dos soluciones distintas para el mismo problema.

Modelos de Uso General

Corresponden a modelos propuestos por distintas organizaciones para atender un determinado tópico o área de trabajo, éstos son posibles de ubicar en la WEB, y muchos de ellos están a disposición del público. A continuación incluyo los modelos TOGAF, SCORE y COBIT a modo de ejemplos, para mayor detalle sobre cada uno su título tiene un link a las páginas que los describren.

TOGAF [The Open Group Architecture Framework]

TOGAF es un modelo de referencia que puede ser utilizado libremente –sin costo- por cualquier organización que desee desarrollar su arquitectura de sistema de información.

TOGAF se ha desarrollado y ha evolucionado continua mente desde mediados de los 90 bajo el alero del Open Group´s Archiecture Forum, actualmente este modelo va en su versión 9. A continuación incluyo el diagrama general de este modelo:

SCOR  [Supply Chain Operations Reference]

Se compone de un conjunto de secciones específicas, y se encuentra organizado en cinco procesos de gestión primarios: Planificación, Abastecimiento, Producción, Despacho y Retorno.

El modelo SCOR provee un marco estándar que permite vincular procesos de negocios, métricas, mejores prácticas, y tecnologías.

La siguiente figura muestra como se relacionan los procesos de la cadena de abastecimiento de una empresa, y a la vez como los procesos de ésta se relacionan con su entorno.

COBIT [Control Objectives for Information and related Technology]

Es un marco de referencia para controlar la TI, que se ajusta  y sirve como soporte al Committee Of Sponsoring Organisations Of The Treadway Commission. Es el marco de referencia de control ampliamente aceptado para gobierno de la empresa y para la administración de riesgos, en lo que se refiere a las operaciones de un área informática.

La figura siguiente muestra los procesos del área informática que considera COBIT.

Modelos de Referencia en uso en Embotelladora Andina S.A.

A continuación se incluyen ejemplos de aplicación de los modelos de referencia para la arquitectura empresarial, los proyecto de implementación de proceso de negocios y el mapa de proceso de negocios que actualmente se utilizan en Embotelladora Andina.

AEA (Arquitectura Empresarial Andina)

Está basada en el modelo la Federal Enterprise Architecture (FEA). Su representanción se muestra en la figura siguiente:

La figura que sigue muestra como se aplica la arquitectura para incorporar una nueva tecnología a la operación de la empresa, en este caso se trata de la Apple iPad.

Modelo Proyectos de Implementación de Procesos de Negocios

Este modelo está diseñado para proveer la base conceptual para ejecutar proyectos de implementación desde la perspectiva de los procesos de negocios basados en la disciplina Business Proocess Management (BPM). Como se podrá observar el modelo trata, al menos, las dimensiones: Organizacional, Procedimental y Transaccional del proceso.

Otros Usos para los Modelos de Referencia

Los siguientes artículos que he publicado tratan sobre Modelos de Referencia y su aplicación en distintos ámbitos:
Mapa de Negocios

Escala de Madurez – Process Maturity Model

El Anteproyecto de una Implementación BPM

Referencias

[1] http://www.businessdictionary.com/definition/model.html

[2] http://en.wikipedia.org/wiki/Reference_model

[3] http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

[4] http://en.wikipedia.org/wiki/Reference_model

Nota: Este artículo se basa en material de la presentación que realicé el 27 de Octubre del 2010 al Club CPO, que organiza el Centro de Estudios de Tecnologías de Información, CETIUC, de la Universidad Católica de Santiago.

Las Brechas Comunicacionales Entre Usuarios, Consultores y Programadores.

De un tiempo a esta parte se hace evidente que la implementación de procesos de negocios, y por ende la incorporación de BPM, tiene su eslabón más débil en las comunicaciones entre las personas que participan del proyecto, y que posteriormente usaran o debieran usar el proceso implementado. Asunto que se evidencia en la dificultad de articular proyectos BPM en las empresas.

Para confirmar la existencia de esta brecha comunicacional esta tenemos la información provista por Office of Management and Budget (OMB) del Gobierno de los USA, que señala en la tabla siguiente la cantidad de proyectos en curso (lo más grandes) en la columna “Number of major federal IT projects”  y la cantidad de éstos en la Watch List. Esta es una lista que incluye todos los proyectos en curso que “tienen una o más debilidades en su planeamiento” [1], de modo que por extensión podemos decir “tienen fallas de comunicación en sus definiciones”.

De la tabla se desprende que para el año 2009 el 72% de los proyectos está en la “Wach List”, y están básicamente por razones de complejidad, política y duración.

Detrás de cada una de estas razones, sostengo, que existe un problema comunicacional, algo no quedó bien especificado o con un diseño insuficiente o con una evaluación técnica incompleta o con temas de poder no resueltos.

¿Están los Usuarios comunicándose con los Consultores?

No obstante que en los últimos diez años ha habido avances notables en el mejoramiento de la tecnología, no mucho ha cambiando en la manera de hacer las cosas en estos mismos diez años. La mayoría de los usuarios y los consultores (implementadores y desarrolladores) están de acuerdo que hay intentos por generar una vía de comunicación más adecuada entre ellos, pero los intentos a la fecha han resultado poco satisfactorios [2]. Por tanto cabe preguntarse:

• ¿La actividad de implementar y desarrollar sistemas es una actividad técnica solamente?
• ¿Están los usuarios definiendo sus necesidades?
• ¿Están los consultores escuchando?
• ¿Qué mecanismos debieran existir para promover una comunicación efectiva entre los usuarios  y los consultores?

¿La actividad de implementar y desarrollar sistemas es una actividad técnica?

Tradicionalmente el quehacer de, al menos, programar se ha considerado un trabajo técnico altamente especializado, y que es realizado por programadores que utilizan una jerga incomprensible para el profano. En mi experiencia, si nos remontamos a los años 70, esta aseveración reflejaba bastante bien la realidad. Cuarenta años después, si Ud. no es especialista y trata de comunicarse con un programador Java o de cualquier otro lenguaje sobre sus desarrollos, se encontrará con una situación bastante parecida. Esta realidad parece confirmar, por extensión, que la actividad de hacer sistemas, es una meramente técnica.

Sin embargo, salvo casos particulares, en las empresas los sistemas son solicitados por la gente del negocio a los informáticos, y esta acción de solicitar es un acto comunicacional, cualquiera sea el modo que se exprese: una conversación, una especificación o un diagrama. La partida es que alguien del área del negocio le “pide” al área de informática un sistema para que le resuelva algo.

Con esta simple constatación del día a día del quehacer de un Informático, podemos establecer que el meollo de un buen sistema es si éste interpreta bien lo que la gente del negocio “pidió”. Esta realidad da origen a cuestiones que al final se traducen en una permanente tensión en los proyectos de implementación, cuya solución burocrática es: Lo que no está escrito no vale. Y, de aquí en adelante en desencuentros entre las partes, que terminan reflejándose en un proceso o sistema pobremente implementado, desde la perspectiva del usuario.

Entonces aparece la necesidad de formalizar lo que la gente del negocio “pide”. Asunto que se traduce, fundamentalmente, en métodos que utilizan los Informáticos para estructurar en algún documento lo que “pide”, el ahora usuario. En el formalizar y construir esta documentación, muchas veces precaria, se parte de la base que el usuario tiene absoluta claridad de lo que necesita, y que el diseño es responsabilidad del Informático, quien conoce del tema planteado por la petición del usuario. Suposiciones que sabemos no se dan frecuentemente.

Hasta ahora, en este proceso, no han participado los programadores, lo han hecho los analistas de sistemas o los consultores. Esto lleva a que los programadores reciben una especificación del consultor, que se a su vez es una interpretación de lo que entendió del requerimiento del usuario, con el consiguiente error por pérdida de información.

Visto lo anterior, al menos podemos decir que si la petición está bien recopilada existe una buena posibilidad que el sistema cumpla con las necesidades de la gente del negocio. Caso contrario estamos en dificultades.

¿Están los usuarios definiendo bien sus necesidades?

“Los usuarios a menudo tiene dificultades para comunicar sus necesidades porque no saben que podría mejorar su trabajo o proceso – ellos no están enterados de las capacidades de las nuevas tecnologías y tienen muchas complicaciones para expresar sus requerimientos en un lenguaje tecnológico” [2].

Los usuarios expresan sus necesidades en términos de fallas o carencias, un determinado sistema  no resuelve una condición de la operación o la resuelve parcialmente. O, a la fecha tiene un conocimiento parcial de su proceso de negocios; asunto que queda en evidencia por la cantidad de órdenes de mantenimiento que generará una vez con el sistema en uso.

Por otra parte los métodos de levantamiento de requerimientos no siempre cuentan con la participación comprometida de los usuarios ni con consultores con la experiencia, métodos y herramientas necesarias.

¿Están los consultores escuchando?

Asumiré que efectivamente los consultores están escuchando, porque por metodología tienen que hacer los levantamientos de requerimientos, modelamiento, o business blueprint .  ¿Entonces por qué seguimos teniendo proyectos con problemas y sistemas que no responden a las expectativas de los usuarios?

Si un consultor, por ejemplo, utilizó diagramas VAC y EPC para modelar un sistema y después este no incluye toda la funcionalidad que el usuario espera. ¿Dónde está el error? La respuesta típica es “el usuario al momento del levantamiento no me mencionó estás funciones”. O, “el consultor no entendió lo que le explicamos”. Y, otra menos frecuente pero, honesta: “Es que recién nos percatamos”.

Mi conclusión, es que existiendo la conversación entre los usuarios y los consultores para establecer el alcance del requerimiento. Y, entendiendo que existen tanto las metodologías como las herramientas para especificar y diseñar un proceso de negocios; la dificultad está en la manera de hacer la conversación, en la dinámica de la interacción y en el sentido de propiedad con respecto al éxito de la implementación del sistema.

¿Qué mecanismos debieran existir para promover una comunicación efectiva entre los usuarios  y los consultores?

No pretendo aquí dar solución a este problema, pero me parece que hay un camino pragmático  y otro académico, para este efecto estoy partiendo del siguiente enunciado:

“Por medio de programas, los usuarios se comunican con otros usuarios, los diseñadores se comunican con los usuarios  y los programas se comunican entre sí … Son esencialmente mensajes, representaciones de los significados generados por usuarios y programadores” [3]

Entonces, desde un punto pragmático el tema es como, quienes tenemos responsabilidades con la Tecnología Informática, hacemos que los usuarios y los diseñadores (consultores y/o programadores) establezcan una nueva forma de conversar para generar significados –requerimientos- que efectivamente representen sus procesos de negocios. En términos prácticos:

• ¿Cómo motivamos a los usuarios a participar en el diseño de sus procesos de negocios?
• ¿Qué métodos necesitamos disponer para contar con la efectiva participación de los usuarios en diseño de sus procesos de negocios?
• ¿Cómo implementamos el co-diseño?
• ¿Cómo separamos lo permanente de lo temporal (métodos, modas, herramientas, buzzwords)?
• ¿Cómo incluimos en el currículo de la gente de negocios el conocimiento general para utilizar el diseño y mejoramiento de los procesos de negocios como una acción de Innovación?

En cuanto a la solución desde un punto de vista académico, es un tópico que le corresponde resolver a las universidades y centros de investigación. Y, en mi opinión necesita el trabajo multidisciplinario de los especialistas en Management, Psicólogos, Informáticos y expertos en BPM, entre otros.

Referencias

[1] http://www.zdnet.com/blog/projectfailures/shocking-govt-it-failure-statistics/10490?tag=mantle_skin;content

[2] http://maic.jmu.edu/journal/7.3/focus/townsend/townsend.htm

[3] Prof. Clarisse Sieckenius de Souza, Departamento de Informática, PUC-Rio

Estructura Organizacional para la Operación con BPM

Si en una empresa se toma la decisión de operar sobre la base de procesos de negocios end-to-end, es necesario generar una organización ad-hoc. En efecto, este tipo de operación requiere contar con una estructura que dé Gobernabilidad a los procesos de negocios: desde su diseño, implementación, operación y mejoramiento. Y, por consiguiente es necesario responder a las preguntas siguientes:

• ¿Quién o quiénes son responsables de la Gobernabilidad de los Procesos de Negocios?
• ¿Quiénes son los responsables de la implementación y mejoramiento de los Procesos de Negocios?
• ¿Quiénes tiene el accountability de los Procesos de Negocios?
• ¿Quiénes los ejecutan?

Y, finalmente cómo se organizan estos quiénes.

Este artículo está basado en el trabajo de Janne J. Korhonen [1] y en mi participación en la creación y operación del Comité Condominio que se encarga de crear las políticas y coordinaciones para la operación de los sistemas informáticos de Embotelladora Andina S.A. para sus empresas en Argentina, Brasil y Chile,

Gobernabilidad de los Procesos de Negocios

La Gobernabilidad de los Procesos de Negocios es un subconjunto de la Gobernabilidad Corporativa y está estrechamente relacionada con la Gobernabilidad de las Tecnologías de Información [2].

Con Gobernabilidad de los Procesos de Negocios nos referimos al conjunto de normas, prácticas y estructuras organizacionales que hacen que los Procesos de Negocios se diseñen, implementen, operen, midan y perfeccionen.

Por tanto de éste concepto de Gobernabilidad derivamos que es necesario establecer una estructura normada y operativa, que permita el progreso y operación eficiente de los procesos de negocios. Para estos efectos ya existen actores definidos:

• Dueño de Proceso de Negocios o Business Process Owner, responsable de un proceso de negocios y con accountability del mismo [3].
• Consultor Experto en Proceso de Negocios o Business Process Expert (BPX), experto en un determinado proceso de negocios y en Tecnologías de Información, en particular con conocimientos amplios en algún software (ERP, CRM, SCM, etc.) [4].
• Mapa de Procesos de Negocios, diagrama con la identificación de los procesos de negocios end-to-end de una empresa [5].

Luego, el tema pendiente por definir es como operan los Dueños de Procesos y los BPX con los procesos identificados en el Mapa de Procesos y las respectivas gerencias que los operan. Sabemos que los procesos por ser del tipo end-to-end “cruzan” la organización; es decir, requieren de la participación de varias unidades pertenecientes a gerencias distintas y, esto implica una estructura matricial en la organización. Establecer este tipo de estructura en una organización con tradición jerárquica es complejo por los costos políticos que significa. Por eso mí propuesta, basada en el trabajo de Janne J. Korhonen [1] y en mi experiencia en el Comité Condominio de Embotelladora Andina S.A., que opera de hecho como una sociocracia,  es generar una estructura basada en cuatro componentes:

• El Comité Corporativo de Procesos de Negocios,
• El Área de Consultores Expertos de Negocios,
• Las Iniciativas de Procesos, y
• La Ejecución de Proyectos de Implementación de Procesos de Negocios.

Definiciones Previas

De acuerdo con Maturana y Varela [6] un sistema consiste en una organización y una estructura. La organización define la identidad del sistema y corresponde a su configuración general. Mientras que su estructura muestra la forma de la interconexión –interacción- de las partes. Una empresa pueda ser vista como un sistema consistente en una organización y una estructura: las relaciones entre los agentes y las realizaciones específicas de los agentes. El sistema continuamente produce interacciones entre sus componentes, pero raramente en los componentes en sí.

Independientemente de la organización existen cuatro niveles para la toma de decisiones en una empresa: estratégico, táctico, operacional y tiempo-real. Los ejecutivos superiores están involucrados en la toma de decisiones estratégicas, que son esencialmente formulaciones conceptuales de los objetivos de largo plazo. En el nivel táctico, los ejecutivos medios implementan y soportan la ejecución de las estrategias de largo plazo, monitoreando la utilización de los recursos y del rendimiento de las unidades a su cargo, y realizan la planificación táctica. En el nivel operacional, las decisiones se refieren a asignar y ejecutar tareas específicas más la asignación de los recursos que requieren. Y, finalmente en el nivel tiempo-real se hacen, realizan o ejecutan las tareas. Son realizadas como parte de la operación, en línea con los planes operacionales, por medio de la automatización o por personas. Estos niveles se representan en la figura siguiente:

Para cada nivel existe un mecanismo de control:

• Estratégico <- Contrato, el Plan Estratégico es un contrato que especifica como la empresa se organiza para el logro de sus objetivos: identifica las unidades de trabajo para el negocio –core business-, asigna las responsabilidades para los distintos componentes de la organización –gerencias- que ejecutan los trabajos pertinentes, y especifica una visión global de los procesos de negocios que la organización debe ejecutar. Es en este nivel donde se generan los cambios organizacionales.
• Táctico <- Coordinación, el Plan Estratégico o Contrato es transformado en coordinaciones entre los distintos componentes de la organización. Las decisiones a nivel táctico corresponden a adaptaciones de la estructura a los cambios del negocio. Requiere de metas específicas, mecanismos para medir la performance, políticas y accountability para cada una de las estructuras existentes o para las nuevas.
• Operacional <- Control, las decisiones operacionales son realizadas por la estructura. Una unidad operacional tiene el control de los recursos en su estructura. La empresa puede cambiar su estructura por motivos operacionales, pero su organización se mantiene constante. El trabajo en este nivel es relativo al plan, trata con la asignación y control de las tareas de las personas.
• Tiempo-real <- Modelo, las decisiones en tiempo-real son parte integral del modus operandi de la empresa. Ellas no impactan a su estructura ni a su organización. El trabajo a este nivel consiste en tareas y actividades discretas que son ejecutadas tanto por las personas como por las máquinas. La manera de hacer las cosas puede representarse o especificarse por medio de un Modelo.

A partir de la apreciación que la utilización de la disciplina Business Process Management (BPM) implica generar estructuras matriciales y, estas son muy difíciles de establecer en organizaciones con una fuerte tradición jerárquica, es que la distinción entre Organización y Estructura permite postular a Korhonen [1] que se puede crear la estructura matricial, requerida por BPM, sin alterar la organización mediante la implementación de Círculos Organizacionales o Comités del tipo sociocrático, que es a fin de cuentas una nueva forma de interacción entre las distintas gerencias o áreas de la empresa.

Por otra parte, los distintos tipos de control permiten establecer los niveles en los cuales deberán operar los Comités y a la vez clarifica que el control a los “que hacen las cosas” es mediante Modelos.

Sociocracia – Superimposición de un Círculo Organizacional sobre la Jerarquía.

Es una estructura (forma de relacionarse) que se puede aplicar a todos los niveles de organización incluyendo a todos sus miembros. La gobernabilidad de esta estructura está basada en el Círculo Organizacional, que se establece superimponiéndolo a la jerarquía administrativa existente (organización). Un Círculo es una agrupación de personas con un objetivo de trabajo común y que se ocupa de generar las políticas -policies. En las reuniones del Círculo se formulan y actualizan los objetivos, se realizan las funciones relativas a la operación, medición de performance y direccionamiento (directrices). También mantiene la calidad de sus recursos por medio de una capacitación integral.

Dado que en la organización pueden existir varios Círculos que operan sobre un mismo tema pero, en distintos niveles organizacionales. Se da que en un Círculo participan gente de un nivel más gente del nivel inmediatamente superior, de manera de tener doblemente enlazados ambos niveles por medio de la participación de, al menos, dos personas. Una de ellas, el Líder Funcional, representa al nivel superior y tiene el accountability de los resultados sobre el tema  asignado al Círculo y que deben generar las personas del nivel inferior, y el  otro es un representante del nivel inferior, el Delegado, elegido por consentimiento por la gente de su nivel.

La mejor solución para un problema importante se genera a partir del conocimiento y sabiduría de aquellos que están más cercanos al problema, independiente de su posición jerárquica. Esto define que los participantes de un Círculo deben ser cercanos al tema.

Las decisiones en el Círculo se toman por Consentimiento, esto es cuando se da la ausencia de cualquier tipo de objeción. En el caso del Consenso la decisión se da cuando todos están de acuerdo, todos han dicho sí; en el esquema de Consentimiento la decisión se logra cuando nadie dice no. En la práctica las decisiones surgen, no se toman.

El principio del Consentimiento es también utilizado en las elecciones sociocráticas para elegir gente para que asuma determinadas funciones y responsabilidades. A diferencia de las democracias donde se vota secretamente y se gana por mayoría, en la sociocracia los votos son públicos, cada quien señala por quién vota y por qué. La gente puede cambiar su voto después de escuchar otros votantes y puede existir un facilitador para ayudar a generar el consentimiento del nominado. La elección finaliza cuando ya no hay más objeciones.

La operación de este modelo se representa en la figura siguiente:

El Comité Corporativo de Procesos de Negocios

El Comité Corporativo de Procesos de Negocios o Steering Committee representa el patrocinio del nivel gerencial superior y asegura el compromiso con los objetivos del negocio, especifica el contrato estratégico: el proceso colaborativo para establecer y desarrollar los procesos de negocios end-to-end. Los modelos establecidos son descriptivos, con especificaciones de los roles y los indicadores de performance (KPI). A este nivel los detalles no están definidos, pero el diseño está concentrado en la representación general de los procesos, siendo su objetivo principal comunicar el direccionamiento estratégico a los niveles operacionales.

De este modo el Comité de Procesos de Negocios articula la visión estratégica de la empresa en iniciativas que se alinean con las diseños de procesos de negocios (BPM) y con los objetivos del área Informática (TI). Este comité establece y prioriza las iniciativas de procesos de negocios, revisa y a prueba los portafolios de proyectos (roadmap), revisa y aprueba los proyectos presentados por el Centro de Excelencia o Área de Consultores Expertos en Procesos de Negocios, y asegura que proyectos aprobados tengan el debido patrocinio y presupuesto.

Específicamente, en este comité participa gente del Nivel Estratégico más la gente del Nivel Táctico. Por ejemplo en una corporación con divisiones nacionales o por países, el Nivel estratégico puede ser representado por el Chief Information Executive (CIO) y los niveles tácticos por los Gerentes de División.

El Área de Consultores Expertos en Procesos de Negocios o Centro de Excelencia (CdE).

El CdE coordina todos esfuerzos referidos a procesos de negocios en el nivel táctico y de acuerdo a los objetivos estratégicos. Lidera los proyectos de implementación o mejoramiento de los proceso de negocios auspiciados por el Comité de Procesos de Negocios. Entrena, capacita y facilita la ejecución de las iniciativas, construye las reglas de negocios y la arquitectura de procesos, desarrolla los estándares que facilitan la re-utilización y la interoperativilidad, favorece el uso de las best practices, documenta, implementa los requerimientos para satisfacer las exigencias legales y/o regulatorias. También apoya la generación de material de capacitación y la ejecución de la misma. El CdE tiene autoridad sobre los artefactos técnicos, tales como: modelos de arquitectura, modelos de procesos de negocios, reglas de negocios y servicios, metodologías de implementación, plataformas para diseño y desarrollo y protocolos de integración, convenciones de nombres y cualquier elemento que tenga relación con BPM.

Está área está conformada por los Expertos en Procesos de Negocios o Business Process Expert (BPX) y Consultores Funcionales. Y, en estricto rigor también puede ser un componente de la organización.

Iniciativas de Procesos de Negocios

También operan a nivel táctico. Tienen la propiedad de un proceso de negocio y coordinan los proyectos dentro de su ámbito de competencia. El dueño del proceso identifica las unidades que participan horizontalmente en el proceso end-to-end, designa las responsabilidades al nivel de ejecución de las tareas del proceso, descentraliza la ejecución del proceso al nivel operacional más pertinente. Planifica los proyectos y los prioriza de acuerdo con los criterios generales de la administración del Portafolio de Proyectos de la empresa.

Para los efectos prácticos las Iniciativas de Procesos de Negocios pueden estar a cargo de un Dueño de Procesos [2] o de un Comité del Proceso de Negocios XY, que tendrá una estructura similar al Comité Corporativo de Procesos de Negocios, pero referido al nivel Táctico y al Operacional.

La Ejecución de Proyectos de Implementación de Procesos de Negocios.

El Proyecto tiene el control sobre las implementación de una parte discreta del proceso de negocios, especificada por la Iniciativa de Proceso. Por lo general se realizan varios proyectos simultáneamente, cada proyecto estará alineado con las directivas del Portafolio de Proyectos.

La ejecución del Proyecto se podrá hacer conforme a la metodología de Implementación que la empresa tenga estandarizada, que por lo generar está organizada por fases, a modo de ejemplo se puede mencionar la ASAP de SAP.

Es una estructura temporal, se mantiene durante el período de ejecución del proyecto propiamente tal. En ella participan gente de las áreas Usuarias, del CdE y consultores externos a la empresa.

Interacciones

Las interacciones entre los entes que componen la gobernabilidad de los procesos de negocios se muestra en la figura siguiente:

Modelo de Operación de los Círculos

El Comité Corporativo de Procesos de Negocios provee al Centro de Excelencia y a la Iniciativa de Proceso con el marco necesario de directrices para que ellos puedan gobernar sus operaciones propias en sus respectivos Círculos. Basados en la visión y en la estrategia del Comité Corporativo de Procesos de Negocios, el CdE desarrolla los roadmaps y los planes de proyectos que incrementaran la productividad de la empresa y también entrega retroalimentación al Comité Corporativo. Por otra parte, cada Iniciativa de Proceso coordina con  el CdE los planes de proyectos teniendo como base los indicadores de performance requeridos por el Comité Corporativo. Tanto para el CdE como para la Iniciativa de Proceso los proyectos son gestionados mediante el Portafolio de Proyectos.

Luego, las implementaciones son realizadas mediante Proyectos, que son estructuras que se configuran en función del proceso en cuestión. La implementación se ejecuta conforme a los estándares y modelos definidos con por el CdE, quien también se hace cargo de mantener todos los artefactos técnicos generados por el proyecto.

Los miembros de cada Círculo se reúnen periódicamente para establecer políticas –policies-, responsabilidades –accountability- y roles. Los temas contingentes de los procesos no son tratados en los Círculos, sino que en la ejecución misma de los procesos (niveles Operacional y Tiempo-real). Así se tiene que el Comité Corporativo podrá reunirse mensualmente, por trimestre o según la necesidad. Las Iniciativas de Procesos podrán hacerlo quincenal o mensualmente. Y, los Proyectos semanalmente. El CdE se reúne regularmente o según demanda.

Los Círculos de la estructura de Gobernabilidad están doblemente enlazados, así se tiene:

• Participan además en el Comité Corporativo de Procesos de Negocios el gerente del CdE, su participación es permanente y, los Dueños de Procesos de Negocios de cada Iniciativa de Proceso, éstos participación según necesidad.
• El CdE tiene un representante en las reuniones de la Iniciativa de Procesos y viceversa.
• El Líder de Proyecto participa en las reuniones de la Iniciativa de Proyecto cuando corresponda.

Referencias:

[1] http://jannekorhonen.fi/rcs.pdf

[2] http://msaffirio.wordpress.com/2006/07/09/gobernabilidad-ti-it-governance/

[3] http://msaffirio.wordpress.com/2008/01/20/dueno-de-proceso-de-negocio-%E2%80%93-business-process-owner/

[4] http://msaffirio.wordpress.com/2008/09/30/business-process-expert-%E2%80%93-bpx/

[5] http://msaffirio.wordpress.com/2008/05/22/mapa-de-negocios/

[6] Maturana, H. & F. Varela (1980). “Autopoiesis and Cognition: The Realization of the Living”. Boston Studies in the Philosophy of Science, Vol. 42, Dordecht (Holland): D. Reidel Publishing Co.