ARTÍCULOS

Propuesta de un espacio multidimensional para la gestión por procesos. Un estudio de caso

Proposal of a multidimensional space for process management. A case study

Proposta de um espaço multidimensional para a gestão por processos. Um estudo de caso

^aProfesora Asistente, Universidad de Medellín, Medellín, Colombia

Autor para correspondencia: Carrera 87 N◦30 – 65, Medellín, Colombia.Correo electrónico: mstabare@udem.edu.co (M.S. Tabares Betancur).

^bProfesor Asistente, Escuela de Ingeniería de Antioquia, Medellín, Colombia

Historia del artículo:
Recibido el 28 de junio de 2011
Aceptado el 30 de mayo de 2013
On-line el 18 de septiembre de 2013

Resumen

Palabras clave: Gestión por procesos, Espacio multidimensional, Arquitectura empresarial, Modelo de madurez, Gestión organizacional.

Códigos JEL: M15. M19. L86.

Abstract

This article proposes a multidimensional space to control manage processes by integrating different views of the organization. The methodology for the development of the proposal is based on a qualitative research design, which is characterized through three activities: the definition of the multidimensional space from the perspectives of the enterprise architecture, the maturity model, and the organizational management. A conceptual experimental case study for a credit application was then carried out, which showed possible inter-relationships between the defined scales and elements. Finally, it was concluded that it is possible to establish standard characteristics for process management that guide the organization from different points of view, when faced with complex transformations.

Keywords: Process management, Multidimensional space, Enterprise architecture, Maturity model, Management level.

JEL classification: M15. M19. L86.

Resumo

Este artigo tem como objectivo propor um espaço multidimensional para realizar a gestão dos processos de forma controlada, integrando diferentes vistas da organização. A metodologia utilizada para o desenvolvimento da proposta baseia-se num projecto de investigação qualitativo descrito a partir de três actividades: definição do espaço multidimensional do ponto de vista da arquitectura empresarial, o modelo de amadurecimento e gestão organizacional. Depois faz-se uma experiência conceptual a partir de um estudo de caso de um pedido de crédito, que mostra, como possíveis resultados, inter-relações entre as escalas e elementos definidos. Por fim conclui-se que é possível estabelecer características padrão de gestão de processos que orientem a organização a partir de diferentes vistas quando se enfrentam transformações complexas.

Palavras-chave: Gestão por processos, Espaço multidimensional, Arquitectura empresarial, Modelo de amadurecimento, Gestão organizacional.

1. Introducción

Los procesos de negocio y las tecnologías de información no son hechos separados en una organización. Por el contrario tienen una relación directa y una dependencia mutua, ya que gestionar los procesos de negocio (Business Process Management [BPM]) implica que las tecnologías de información se deban definir e implantar de acuerdo con las actividades definidas por los procesos (Object Management Group, 2008).

Como indica (Burlton, 2010), todo lo que pasa en una organización está interconectado, y un cambio en un área, proceso o componente de negocio o tecnologías de información puede afectar otras áreas. Sin embargo, no es fácil encontrar organizaciones que lleguen o se mantengan en este estado ideal. Es posible encontrar situaciones donde:

• Las empresas de larga trayectoria o gran magnitud no logran alinear fácilmente diferentes aspectos que las lleven a un buen nivel en la toma de decisiones.

• Las organizaciones se enfrentan a cambios de pensamiento y acción sin estar preparados de igual forma en todos los niveles.

• No se alcanza un nivel de madurez en la gestión de los procesos de la organización, de tal forma que sea coherente con los objetivos de esta.

• La arquitectura del negocio se concibe como un conjunto de prácticas independientes de la gestión de tecnologías de información que la soportan.

En este artículo se presenta la definición de un espacio multidimensional para realizar la gestión de procesos de forma controlada. El espacio está definido por 3 puntos de vista de la organización: la arquitectura empresarial, el modelo de madurez y la gestión organizacional. El objetivo es lograr una integración de estos diferentes puntos de vista en dicho espacio, cuando se motiva la gestión de los procesos por la ocurrencia de cambios en la organización. Esto permite que un analista de procesos o uno de software pueda conocer el impacto que causan los cambios en la organización para tomar acciones coherentes desde diferentes vistas.

Este artículo está organizado de la siguiente forma: la sección 2 describe la metodología de investigación utilizada. La sección 3 incluye los antecedentes que apoyan el desarrollo de la propuesta. La sección 4 describe el modelo del espacio multidimensional propuesto. La sección 5 aplica el modelo definido en un estudio de caso de crédito financiero. Finalmente, en la sección 6 se concluye y se describen los trabajos futuros alrededor de la propuesta presentada.

2. Metodología

La metodología utilizada para el desarrollo de la propuesta se basa en un diseño de investigación cualitativo, dado que esta facilita la exploración de diferentes características en campos que de forma conjunta no se han analizado, en beneficio de diferentes actores de la organización como es el área de gestión de procesos y tecnologías de información. La metodología se describe desde las siguientes actividades:

• Definición del espacio multidimensional.

• Experimentación conceptual desde un estudio de caso.

La definición del espacio se hace desde 3 vistas: la arquitectura empresarial, el modelo de madurez y el nivel de gestión. Inicialmente, cada una de estas vistas es conceptualizada con el fin de presentar los elementos básicos que las componen. Una vez establecidas las vistas y sus características, se analizan posibles hechos de integración entre los diferentes planos o capas del espacio de la gestión del proceso. Esto permite definir acciones que guían la gestión de los procesos por cada posible interrelación de las vistas.

3. Antecedentes

3.1. Gestión por procesos

(Smith y Fingar, 2006) tratan el concepto de proceso de negocio como un conjunto de actividades colaborativas y transaccionales que son coordinadas y entregan un valor agregado a los clientes como recipientes de la salida de un proceso. Según el Software Engineering Institute (SEI), los procesos facilitan la sinergia de 3 dimensiones críticas en las empresas: gente, procedimientos y métodos, y herramientas y equipos (Chrissis et al., 2003).

Administrar por procesos está orientado a gestionar la organización desde la mirada que el cliente tiene de la misma (Agudelo y Escobar Bolivar, 2007). Conceptos predecesores tales como la administración científica propuesta por (Taylor, 1997), la reingeniería (Hammer y Champy, 2003) y diferentes iniciativas para mejorar la calidad como la ISO-9000¹ NTC-ISO 9000 (ICONTEC, 2002) se han enfocado en los procesos para producir un producto o servicio.

La gestión por procesos conduce a la estandarización de los procesos de negocio. (Trkman, 2010) define Business Process Management (BPM) como ''todos los esfuerzos de una organización para analizar y mejorar continuamente las actividades fundamentales, tales como la fabricación, comercialización, comunicaciones y otros elementos importantes de las operaciones de la empresa'' (p. 125).

3.2. Arquitecturas empresariales

El término arquitectura está definido por la norma ISO/IEC 42010:2007, que lo describe como la organización fundamental de un sistema, reflejada en sus componentes, sus relaciones entre sí y con el entorno y los principios que rigen su diseño y evolución (The Open Group, 2009). (Zachman, 2009) define arquitectura empresarial como el conjunto de representaciones descriptivas relevantes para la descripción de una empresa y que constituye la línea de base para el cambio de la empresa una vez que se crea. Esto lleva a que esté relacionada básicamente con recursos tales como: estrategias, procesos de negocio, datos e informaciones, aplicaciones, sistemas o tecnologías (White House Office of Management and Budget, 2007). En otras palabras, la arquitectura empresarial describe la organización como una estructura coherente que mantiene una alineación continua de todas sus partes y facilita el control de los cambios que se realizan y que podrían afectar su estrategia organizacional (Spewak y Hill, 1992, Posada, 2009, The Open Group, 2009, Jensen et al., 2011).

Una arquitectura empresarial considera diferentes formas y finalidades de los aspectos de las organizaciones (Vogel et al., 2009). Así, se puede decir que esta establece el mapa de rutas o plan de trabajo para toda la organización con el objetivo de cumplir con su misión, objetivos y estrategias, a través de un rendimiento óptimo de sus principales procesos de negocio y en un entorno de tecnologías de información y comunicación (TIC) eficiente (Schekkerman, 2006). De esta forma, una arquitectura empresarial puede ''proporcionar mayor valor a través de la posibilidad de evitar los riesgos y al mismo tiempo aprovechar las oportunidades de beneficios, a medida que surjan'' (Giachetti, 2012, p. 148).

A continuación se describen cada una de estas arquitecturas.

• Arquitectura de negocio. Esta arquitectura contiene las estrategias de negocio, las métricas de rendimiento, los procesos de negocio y sus relaciones. De acuerdo con las estrategias, los procesos de negocio se ejecutan y evalúan con los parámetros de rendimiento de las estrategias (Kang et al., 2010). De esta forma se alinea con las otras arquitecturas, para identificar los requisitos de los sistemas de información que apoyan a las actividades del negocio (Sousa et al., 2005).

• Arquitectura de información. Describe qué necesita saber la organización para ejecutar los procesos descritos en la arquitectura de negocio. Es decir, especifica qué partes del proceso de negocio requieren información y dónde será almacenado y manejado cada tipo de dato.

• Arquitectura de las aplicaciones. Define la interacción entre las aplicaciones que soportan los procesos de negocio. En otras palabras, describe las aplicaciones o sistemas de información que son requeridos para apoyar los requerimientos del negocio y permitir la gestión de la información de una manera eficiente (Sousa et al., 2005).

• Arquitectura de la tecnología. Se refiere a la infraestructura de software y hardware que es necesaria para apoyar las aplicaciones o sistemas de información. Algunas de estas son bases de datos, sistemas middleware, arquitecturas orientadas a servicios, redes de datos, etc.

La falta de alineación entre estas 4 arquitecturas puede generar deficiencias en la alineación entre las TIC y las necesidades del negocio, lo cual trae como consecuencia el mal uso de recursos o activos de la organización.

Los modelos de madurez proponen buenas prácticas para identificar, evaluar (Trkman, 2010) y gestionar los procesos (Wierenga, 2012, Röglinger y Pöppelbuss, 2012). Son el punto de partida para que una organización determine su desempeño actual y su capacidad con respecto a la gestión de los procesos. Estos modelos describen los elementos básicos para lograr procesos eficaces en uno o varios dominios (Object Management Group, 2008) y proveen elementos para controlar cuantitativamente los procesos, lo cual es la base para el mejoramiento continuo de estos.

En este artículo se trabaja con 2 modelos de madurez el Business Process Maturity Model (BPMM) y el Capability Maturity Model Integration (CMMI). A continuación se describen estos modelos.

• Modelo CMMI. Define los siguientes niveles (Ahern et al., 2008): incompleto (0), donde un proceso todavía no está vinculado con un objetivo; ejecutado (1), donde los objetivos específicos de un proceso se cumplen; gestionado (2), donde un proceso ya está institucionalizado como un proceso gestionado, lo que significa que la organización tiene una política establecida que define cuál proceso se tiene que usar en una situación específica; definido (3), donde el proceso está institucionalizado como un proceso definido; en comparación con el nivel 2, que se enfoca en una instancia de un proceso individual, el nivel 3 busca estandarizar y desarrollar un proceso en toda la organización; cuantitativamente gestionado (4), donde un proceso está gestionado cuantitativamente, es decir, se aplican métodos estadísticos o cuantitativos para controlar un subproceso especifico (y todavía no todos los procesos de una organización); y optimizando (5), donde la optimización está basada en los resultados de la medición en el nivel anterior y en el análisis de tendencias y buenas prácticas para finalmente lograr una alineación con los requisitos del negocio (Ahern et al., 2008).

• Modelo BPMM. Define 5 niveles similares (Object Management Group, 2008), tales como: inicial (1), donde la gestión todavía es algo inconsistente; gestionado (2), donde se gestionan unidades de trabajo pero todavía falta la vista más holística que requiere la orientación por procesos; estandarizado (3), donde se gestionan procesos; predecible (4), donde se gestiona la capacidad de gestionar los procesos de una manera cuantitativa; e innovando u optimizado (5), donde la gestión del cambio (de los procesos) es una rutina y el mejoramiento continuo, una realidad. La madurez representa la capacidad de un proceso de lograr los objetivos del negocio.

El BPMM enumera 4 maneras diferentes de usar este estándar. Se puede usar (Object Management Group, 2008) para:

• Guiar programas de mejoramiento de los procesos de negocio.

• Evaluar el riesgo con respecto al desarrollo y la implementación de aplicaciones.

• Evaluar la capacidad de proveedores.

En el caso que una organización direccionada por el BPMM, por ejemplo del nivel 2, contrate una compañía de TIC para el desarrollo de software bajo la modalidad de outsourcing y esta se encuentre certificada en CMMI, también nivel 2, entonces es necesario medir el impacto que va a tener este proyecto en la organización contratante. Por esta razón se selecciona la medición del proceso como base de análisis en el nivel 2 de ambos modelos. Aquí es conveniente tomar como base el paralelo de las áreas de procesos en el nivel 2 propuesto por (Curtis, 2005). La Figura 2 ilustra dicho paralelo y resalta el área de proceso de medición y análisis.

La Tabla 1 muestra un paralelo de los objetivos y prácticas de estas áreas de procesos, que los participantes deben aplicar en el nivel 2.

Buglione y Dekkers, (2006) analizan el hecho de adoptar los modelos de madurez como parte de un rediseño de la estrategia corporativa con proyección a tener éxito de una forma simple y divertida.

4. Espacio multidimensional para la gestión por procesos

(Burlton, 2010) resalta que todo lo que pasa en una organización está interconectado y un cambio en un área, proceso o componente de negocio o tecnología de información puede afectar otras áreas.

El espacio multidimensional es un modelo que orienta la gestión de procesos de forma controlada. Esto permite que el impacto que causan los cambios en la organización pueda ser analizado desde diferentes perspectivas.

El espacio se define a partir de 3 ejes: la arquitectura empresarial, el modelo de madurez y el nivel organizacional. El concepto y la importancia de las arquitecturas empresariales y de los modelos de madurez se describieron en la introducción. Adicionalmente, se agrega la dimensión del nivel organizacional porque los procesos y los cambios en estos pueden ocurrir en cualquier nivel jerárquico de la organización y deben ser alineados con la visión de la empresa.

Esta alineación se logra principalmente de arriba hacia abajo, es decir, a través de la conexión entre lo estratégico, lo táctico y lo operacional. La Figura 3 ilustra la forma como cada eje dispone de diferentes escalas, donde cada una de ellas aportará un conjunto de elementos para una evaluación más holística de los procesos, sobre todo en el caso de los cambios.

• Eje de la arquitectura empresarial. Establece cuatro sub arquitecturas como sus escalas de medida. Esto permite definir un conjunto de características que cada arquitectura aporta a los objetivos de la organización y que se deben tener en cuenta cuando se gestiona un proceso.

Por ejemplo, el procesamiento de una solicitud de crédito (ver descripción del estudio de caso en la sección 4.3) se refleja tanto a nivel de negocio como a nivel de la información, porque para procesar una solicitud de crédito se necesita información del cliente relacionada con su situación económica (capacidad de pago) y su comportamiento financiero. Este procesamiento de información se realiza a nivel de las aplicaciones de software apoyadas por tecnologías como base de datos e infraestructura.

De acuerdo con lo anterior, el objetivo es que las 4 arquitecturas son alineadas de la siguiente forma: la arquitectura de la información está alineada con la arquitectura del negocio si los empleados tienen toda la información necesaria para ejecutar los procesos de negocio. Es decir, toda la información debe estar a la mano, justo a tiempo y con el detalle requerido. En un escenario donde la relación entre la arquitectura de negocios y de las aplicaciones está completamente alineada, los empleados solo hacen trabajos que no son mecánicos y que una máquina o una aplicación no puede resolver tan fácilmente (Sousa et al., 2005).

• Eje del modelo de madurez. Hace referencia a la evaluación de un proceso tanto de negocio como de desarrollo de software y permite determinar su madurez, el desempeño y la capacidad de gestionarlo. La escala definida para este eje dependerá del modelo de madurez que usa la organización.

• Eje del nivel organizacional. Define 3 escalas -la estratégica, la táctica y la operativa-, las cuales reflejan diferentes niveles de gestión en una empresa, ya sea bajo la orientación de los objetivos o en la toma de decisiones en una organización.

En una organización se tratan problemas diferentes y se toman diferentes tipos de decisiones en cada uno de los 3 niveles. A nivel operativo, generalmente, los problemas son bien estructurados, se tratan problemas que son generalmente rutinarios y repetitivos para los cuales existe una solución que a menudo ya está documentada en manuales, etc., y en este sentido predefinida. Mientras a nivel estratégico la situación es menos organizada y los problemas son poco estructurados, generalmente se trata de problemas borrosos o difusos y complejos para los cuales no hay soluciones estereotipadas o prefabricadas, como por ejemplo en el caso de una fusión entre 2 organizaciones (Swenson, 2010).

Un nivel no puede existir sin los demás. El nivel estratégico se enfoca en la navegación de los procesos y de la organización, mientras el otro extremo, el nivel operacional, proporciona los instrumentos para poder lograrlo. En el nivel táctico, que se encuentra entre el nivel estratégico y el operacional, se emula un tablero que permite la observación de cada uno de los procesos para apoyar la toma de decisiones.

La Figura 3 ilustra que no es suficiente mirar cada dimensión por separado, sino que se requiere una perspectiva más integral y transversal de la organización.

4.2. Análisis de la integración de hechos

Una vez establecidos los ejes y sus características, se analizan posibles hechos de integración entre los diferentes planos o capas del espacio de gestión del proceso. Por cada posible interrelación se definen acciones que guían la gestión de los procesos.

Las organizaciones están sujetas a cambios en los procesos por diferentes motivos y agentes internos o externos. Por ejemplo, en el caso del otorgamiento de crédito (que se describe en la siguiente sección), los mercados pueden ocasionar que la entidad financiera decida generar nuevas actividades en dicho proceso para mejorar la información que se considera para calificar un solicitante, mediante un modelo de scoring que facilita la toma de decisiones sobre la aprobación o el rechazo de solicitudes de crédito.

En momentos como este es donde se hace necesario el análisis de los hechos involucrados en el cambio y que demandan la integración entre los ejes del modelo para la consecuente gestión del proceso. El análisis se guía por el siguiente método:

• Clasificación de cada uno de los elementos que serán impactados por el cambio.

• Definición de las posibles interrelaciones entre las escalas y los elementos definidos para cada uno de los ejes. Esta permite establecer características estándares que orienten la organización ante cambios programados y no programados.

• Gestión controlada del proceso. Esta se formaliza en términos de la función (1):

Dónde Gp_i es la gestión resultante cuando un proceso p_i cambia (i = 1...n), NO_g es el nivel organizacional g, AE es la arquitectura empresarial a, y MM es el nivel n en el modelo de madurez.

4.3. Estudio de caso

El estudio de caso se define desde un proceso de análisis de solicitud de crédito de consumo para una entidad financiera.

La compañía FastCash define el proceso análisis de una solicitud de crédito de consumo como se muestra en la Figura 4. Cuando un cliente presenta una solicitud de crédito de consumo, la entidad prestamista tiene que evaluar la capacidad del cliente para pagar.

Para evaluar esta capacidad, la entidad financiera se basa tanto en información interna (datos de la solicitud e historia del solicitante en la entidad) como externa (información que manejan las centrales de riesgo, por ejemplo: Datacredito² o CIFIN³ en Colombia. La consulta de los datos externos se hace actualmente como una tarea manual donde el analista de crédito captura los datos observando la información de la página web de la central.

Específicamente, la aplicación modelo se trata desde un cambio en este proceso, el cual, de forma general, ampliará la base de datos de la organización para mejorar la toma de decisiones de otorgamiento del crédito.

Estas son las condiciones actuales de la organización FastCash y de la empresa contratada:

• BPMM nivel 2.

• Contratación de empresas de tecnologías de información certificada en CMMI nivel 2 (mínimamente).

• Aplicaciones que apoyan: aplicación para la evaluación de una solicitud de crédito basado en datos localizados en la base de datos corporativa; por ejemplo, un sistema de planificación de recursos empresariales (Enterprise Resource Planning [ERP]) y un sistema para la administración de la relación con los clientes (Customer Relationship Management [CRM]).

5. Aplicación del espacio propuesto

La aplicación del modelo propuesto se presenta desde la ocurrencia del cambio en el proceso de otorgamiento del crédito.

5.1. Definición del cambio solicitado

La central de riesgo almacena una variedad de datos que reportan las diferentes entidades financieras del país. A partir de este conjunto de datos la central calcula un puntaje (score) que califica un solicitante. Además, esta estima para cada persona una probabilidad de no pago y la probabilidad de entrar en mora. Estos 3 datos básicamente resumen todos los demás datos que posee la central acerca de un solicitante, y por lo tanto estos 3 se integrarán en la base de datos.

5.2. Análisis del cambio desde cada eje del espacio multidimensional

• Eje de arquitectura de negocio. En la Figura 5 se muestra el impacto que tiene el cambio sobre este proceso. El analista del proceso decide que el cambio implica mejorar el proceso por medio de una aplicación de software que permita importar la información del solicitante desde la central y sea almacenada en una base de datos de la institución para finalmente ser usada para calcular el score interno de la entidad con respecto al solicitante. Por esto la tarea ''Consultar Central de Riesgo'' pasa de ser manual a ser una tarea ejecutada desde una aplicación por un usuario y se agrega una nueva tarea al proceso, llamada ''Integrar datos a la Base de Datos'', la cual se encargará de capturar y almacenar la información. Esto permitirá ampliar la información del solicitante en la base de datos para mejorar la medición del riesgo crédito y la toma de una decisión.

Esta decisión puede tomar los siguientes estados: aprobación, rechazo, o un estudio más detallado de la solicitud de crédito en el instante de la otorgación. Según la descripción, este cambio a nivel de negocio impactará las demás sub-arquitecturas y requiere también cambios en estas. El conjunto de cambios provocados por el caso hipotético se analizarán cualitativamente, tomando los ejes que constituyen el espacio multidimensional propuesto como referencia y sus escalas como punto de partida para la medición del impacto. A continuación se detalla esta metodología.

Para gestionar el proceso, en primera instancia se identifica el nivel de madurez de la organización. Para este caso, la organización se encuentra en un nivel 2, tanto en el departamento de crédito de la entidad financiera como en la empresa de software de outsourcing que se va a contratar.

Como el proceso ya está definido, entonces es necesario, medir el impacto que va a tener este proyecto. Por consecuencia, a continuación se enfoca en la medición del proceso en ambos modelos.

• Análisis del cambio desde la arquitectura de aplicaciones. Cuando un cliente presenta una solicitud de crédito de consumo, los datos correspondientes se extraen de la base de datos de la central de riesgo mediante una consulta que transmite los datos en una estructura XML (interfaz XML que ofrece la central). Luego estos datos se almacenan en la base de datos de la entidad financiera y completan el registro de datos del solicitante, que se utiliza para calcular un score. La parte del desarrollo de la aplicación de software se contrata con una empresa externa.

6. Resultados

Con respecto al primer punto, se identificaron algunas dificultades con respecto al eje ''Nivel de madurez'':

• Las empresas son libres en la selección del modelo, ante lo cual pueden seleccionar el modelo de madurez que más se adapta a las necesidades de la empresa; en el caso presentado, el BPMM y el CMMI.

Ambos modelos tienen el objetivo de medir la capacidad que tiene una empresa o una parte de esta en la gestión de los procesos de negocio y en los procesos de desarrollo del software, respectivamente. Sin embargo, los modelos definen para cada uno de los niveles de madurez diferentes objetivos y prácticas (las prácticas se aplicarán para lograr los objetivos) dependiendo del área de proceso. Se considera que la tarea de definir los objetivos y prácticas para un proceso específico no es tan intuitiva, en particular si el ejercicio se realiza en una pyme en Colombia. El estándar BPMM y CMMI define qué se debe hacer pero no cómo. Por ejemplo, en el área de Monitoreo y Control de la Unidad de Trabajo surge el interrogante: ¿cómo la entidad financiera debe definir el objetivo (SG2) de que el rendimiento real y los resultados de una unidad de trabajo están comparados frente los requisitos, las estimaciones, los planes y los compromisos adquiridos para el caso dado del cambio en el proceso del análisis de una solicitud de crédito? ¿Cómo la entidad debe definir y aterrizar la práctica (SP7): las medidas, las cuales son definidas en los planes para una unidad de trabajo, se recogen, se analizan y se utilizan en la gestión del trabajo? Es decir, el inconveniente consiste en la necesitad de capacitar primero unos empleados en la utilización del modelo de madurez que seleccionó la empresa porque se puede asumir que faltan conocimientos y habilidades para realizar la tarea de definir los objetivos y prácticas según los requisitos del BPMM o CMMI.

• Como muestra el paralelo que realizó (Curtis, 2005), el mapeo entre el BPMM y el CMMI hace evidente que no siempre existe una relación uno a uno entre las áreas de procesos, los objetivos y las prácticas que definen los 2 modelos para el nivel 2. Sin embargo, los 2 modelos son compatibles, en el sentido de que ambos están estructurados de forma similar, definiendo áreas de procesos, objetivos y prácticas para cada uno de los 5 niveles de madurez.

• A partir del caso presentado se puede modificar el supuesto sobre el nivel de madurez de las 2 empresas; por ejemplo, cuando las 2 se encuentran en niveles diferentes, una en el nivel 3 (BPMM) y la contratada en el nivel 2 (CMMI). En este caso las 2 empresas persiguen diferentes objetivos y prácticas con respecto a la gestión de procesos. Esto significa que en una empresa en el nivel 3 los procesos ya están estandarizados y por consiguiente se pueden gestionar en este contexto. Esta empresa probablemente ya está trabajando para llegar al nivel 4 (predecible) y se aplican prácticas cuantitativas con el objetivo de lograr este mejoramiento. Mientras en la empresa contratada, que todavía está en el nivel 2 y en este sentido es menos madura, los procesos están apenas gestionados.

La consecuencia de esta disparidad entre las 2 empresas con respecto a su capacidad de gestionar sus procesos es que en la empresa contratada la falta de madurez se puede convertir en un riesgo con respecto a la calidad del producto final. Este riesgo crece si la diferencia entre los niveles de madurez en las 2 empresas es más significativa; por ejemplo, una empresa en el nivel 0 y otra en el nivel 5.

En el caso del cambio sobre el proceso del otorgamiento de crédito, la institución financiera quiere mejorar la base de información para reducir las pérdidas que resultan de una mala colocación de dinero en el proceso del otorgamiento de créditos. Este objetivo es probable que no se logre si la empresa contratada no tiene sus procesos del desarrollo de software completos, ejecutados, gestionados, etc., porque la falta de madurez generalmente hace a la empresa contratada más vulnerable para errores en sus procesos, y estos errores impactan directamente en la calidad del software que debe traer la información necesaria de la central de riesgo.

Esto significaría que la falta de capacidad en la gestión de los procesos de software tiene un impacto sobre los procesos de negocio, que en este caso particular se refiere a un efecto negativo en el proceso de otorgamiento de crédito. Es decir, faltaría la alineación entre las TIC y las necesidades del negocio.

Con respecto al segundo punto, la medición a través de la aplicación de las escalas de los ejes del espacio multidimensional resulta en la visualización de las posibles combinaciones entre las escalas y los elementos definidos en cada uno de los ejes. En el caso del cambio sobre el proceso de otorgamiento de crédito en empresas del nivel 2 de madurez, se trata de un proceso operativo que afecta la arquitectura del negocio (proceso de negocio) como la arquitectura de la información y de las aplicaciones (software) y también la arquitectura de la tecnología (debido a la ampliación de la base de datos). El resultado de la aplicación del modelo propuesto es que el espacio multidimensional puede facilitar la gestión de los procesos y la toma de decisiones cuando el impacto de los cambios genera transformaciones complejas en los servicios de tecnologías de información para la organización y para sus clientes.

Los resultados obtenidos en la aplicación de la propuesta permiten mostrar que durante la toma de decisiones se pueden establecer interdependencias cualitativas y cuantitativas entre elementos de los diferentes ejes. En la aplicación del modelo también se logra evidenciar que pueden surgir problemas de compatibilidades entre los elementos de los ejes.

En consecuencia, se tiene que constatar que la medición de la madurez de los procesos (dimensión nivel de madurez en sus diferentes escalas) es más fácil a nivel operativo, porque es un entorno más estructurado y estable que el nivel estratégico. Por lo tanto, es recomendable empezar con la medición de la madurez de los procesos a nivel operativo (Swenson, 2010).

7. Conclusiones

La propuesta presentada en este artículo provee una forma innovadora de gestión de procesos manejando el impacto de los cambios desde un espacio multidimensional. Si una organización optimiza sus procesos mediante la aplicación del espacio propuesto, evita el error de optimizar las partes (óptimo local), aunque no se optimiza el todo (óptimo general).

La propuesta permite identificar características básicas de las organizaciones en la gestión de sus procesos. La integración de los ejes facilita que esta se mantenga coherente y consistente con los objetivos de la organización.

Para adoptar esta propuesta se recomienda que la organización: a) evalúe la necesidad de tener un instrumento que le facilite mantener la coherencia entre las estrategias de negocio y la gestión controlada de los procesos; b) identifique claramente qué escalas de cada eje debe definir, implementar y mantener para generar información segura y confiable durante la gestión de los procesos; c) oriente la toma de decisiones de forma alineada con la gobernabilidad definida para su arquitectura empresarial, y d) analice la forma de mantener una consistencia entre los niveles de madurez de la organización, los clientes y los proveedores que interactúan con los procesos de la organización. Es decir, es importante profundizar en la forma en que los diferentes modelos de madurez son necesarios en el diseño o apoyo de la estrategia, de la administración y de la operación corporativa.

Las futuras líneas de trabajo en esta investigación están orientadas a refinar el espacio multidimensional y definir un framework que provea las herramientas, los componentes y los conectores necesarios que estandaricen su uso en diferentes tipos de organizaciones.

Conflicto de intereses

Los autores declaran no tener ningún conflicto de intereses.

Notas

1 ISO 9000 es un conjunto de normas de calidad establecidas por la Organización Internacional de Normalización (ISO) (http://www.iso.org).

2 Ver la página web: http://www.datacredito.com.co

3 Ver la página web: http://cifin.asobancaria.com/cifin/index.jsp

Bibliografía

1. Agudelo LF, Escobar Bolivar J. Gestión por procesos. Bogotá: Instituto Colombiano de Normas Técnicas y Certificación, ICONTEC; 2007.         [ Links ]

2. Ahern DM, Clouse A, Turner R. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Boston, MA: Addison Wesley; 2008.         [ Links ]

3. Buglione, L., Dekkers, C. (2006). A murphological view on software measurement: A serious joke or a funny serious thing? Proceedings of 3rd Software Measurement European Forum-SMEF, 315-329. Roma. Disponible en: http://www.dpo.it/smef2006/papers/c08.pdf [consultado 12 Jun 2011]         [ Links ].

4. Burlton R. Delivering business strategy through process management. Handbook on Business Process Management. 2. Springer; 2010. 5-37.         [ Links ]

5. Chrissis MB, Konrad M, Shrum S. CMMI: Guidelines for Process Integration and Product Improvement. Boston, MA: Addison-Wesley; 2003.         [ Links ]

6. Curtis B (2005). Process maturity model. Association for software engineering excellence. Disponible en: http://www.dfw-asee.org/archive/0501meet.pdf [consultado 4 Ago 2011]         [ Links ].

7. Giachetti RE. A flexible approach to realize an enterprise architecture. Procedia Computer Science. 2012; 8:147-52.         [ Links ]

8. Hammer M, Champy J. Reengineering the Corporation: A Manifesto for Business Revolution. New York, NY: Harper Collins Publishers; 2003.         [ Links ]

9. ICONTEC (2002). Norma Técnica Colombiana. NTC-ISO 9000.         [ Links ]

10. Jensen T, Cline O, Owen M. (2011). Combining Business Process Management and Enterprise Architecture for Better Business Outcomes. IBM Redbooks. Disponible en: http://www.redbooks.ibm.com/redbooks/pdfs/sg247947.pdf [consultado 11 Jul 2011]         [ Links ].

11. Kang D, Lee J, Kim K. Alignment of Business Enterprise Architectures using fact-based ontologies. Expert Systems with Applications. 2010; 37(4):3274-83.         [ Links ]

12. Object Management Group (2008). Business Process Maturity Model v. 1.0. Disponible en: http://www.omg.org/spec/BPMM/1.0/PDF/ [consultado 7 Jul 2011]         [ Links ].

13. Posada D (2009). Arquitectura Empresarial para PYMES. Disponible en: http://aepyme.blogspot.com/2009/07/arquitectura-empresarial-como-modelo.html [consultado 6 Ago 2011]         [ Links ].

14. Röglinger M, Pöppelbuss JB. Maturity models in business process management. Business Process Management Journal. 2012; 18(2):328-46.         [ Links ]

15. Schekkerman J (2006). Extended Enterprise Architecture Maturity Model Support Guide (Version 2.0). Institute for Enterprise Architecture Developments. Disponible en: http://www.enterprise-architecture.info/Images/E2AF/Extended%20Enterprise%20Architecture%20Maturity%20Model%20Guide%20v2.pdf [consultado 20 Jul 2011]         [ Links ].

16. Smith H, Fingar P. Business Process Management: The Third Wave. Tampa: Meghan Kiffer Press; 2006.         [ Links ]

17. Sousa P, Marques C, Alves J (2005). Enterprise Architecture Alignment Heuristics. Microsoft Architect Journal. Disponible en: http://msdn.microsoft.com/en-us/library/aa480042 [consultado 5 Jul 2011]         [ Links ].

18. Spewak S, Hill S. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. New York, NY: Wiley-QED Publication; 1992.         [ Links ]

19. Swenson KD (2010). Knowledge Work and Unpredictable Processes. En: Fischer L. (2010) BPM and Workflow Handbook. Spotlight on Business Intelligence, 33-42. Future Strategies.         [ Links ]

20. Tabares MS, Lochmuller C. El Uso de las Tecnologías de Información y Telecomunicación en la Gestión por Procesos. Memorias Jornadas de Investigación EIA. 2009; 114-8.         [ Links ]

21. Taylor FW. The Principles of Scientific Management. New York, NY: Cosimo; 1997.         [ Links ]

22. The Open Group (2009). The Open Group Architecture Framework, TOGAF 9 - Evaluation Copy.         [ Links ]

23. Trkman P. The critical success factors of business process management. International Journal of Information Management. 2010; 30(2):125-34.         [ Links ]

24. Vogel O, Arnold I, Chughtai A, Kehrer T. Software Architecture - A Comprehensive Framework and Guide for Practitioners. Heidelberg: Springer; 2009.         [ Links ]

25. White House Office of Management and Budget (2007). FEA Practice Guide. Federal Enterprise Architecture Program. Disponible en: http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_Practice_Guidance_Nov_2007.pdf [consultado 28 Jul 2011]         [ Links ].

26. Wierenga, H. (2012). Towards BPM 2.0. Disponible en: http://www.bptrends.com/publicationfiles/04-03-2012-ART-BPM%202%200-Wierenga%20with%20Author%20%20info.pdf [consultado 28 Jul 2011]         [ Links ].

27. Zachman, J.P. (2009). The Zachman Framework Evolution. Disponible en: http://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution [consultado 1 Ago 2011]         [ Links ].